Page 42 - BP_202008

载没有区别。上线调试成功，运行稳 护、处理播表时，也可以手动操作倒 单的捕捉串口数据，希望捕捉到“触
定，直到2017年4月播出也搬迁到新址 换，这个操作通过鼠标点击“接管” 发”指令。Commonitor的操作非
后，该远程上载停止使用。 按钮或在特殊功能面板上按键执行。 常简单，只需注意，要先启动端口监
需要注意的是，虚拟串口的通信 经过询问值班人员、调取监控 测，再打开播出软件。于是开启该软
参数的设置必须在串口盒子上操作， 等，发现无人为因素、无操作失误等 件，对特殊功能面板对应的串口com7
因为本地得到的串口资源是TCP/IP虚 情况，我们把相关的编排和日志发给 进行监测，手动操作“接管”按钮，
拟的，如果被控设备的参数有变化， 厂家，但厂家也未能定位原因。于是 争取尽早捕获到“触发”指令。在
也需要在串口盒子上修改。 播控部成立专门的小组，组织力量攻 正常工作状态和接管操作过程中，
克这个难题。 Commonitor捕捉到的是播出软件与
二．虚拟串口在排除播出控制软件 在对故障发生时的现象进行多次 特殊功能面板每秒一次的握手信息，
BUG中的应用 梳理后，发现了一个极其重要的突破 分别是16进制23、24。由于该事故的
我台全频道高清播总控于2016年 点。在播出软件用鼠标“触发”时， 发生率为千分之一(事后总结的概率)很
底建成，2017年4月完成所有频道向 在点击“触发”按钮后，会弹出一个 低，几天后仍没捕获到。我们采用鼠标
新播控系统的转移，按照播控系统的 确认界面，确认后才会生效执行。但 自动点击软件，在主备工作站上模拟人
运行规律，投入使用后的一年半时间 根据当班值班人员的描述和监控拍到 工操作。果然方法得当，效果不一样，
内，都属观察期，出现BUG可能性较 的工作站屏幕，并没有出现这类界 不到半天就出现了“触发”节目的现
大。2018年初，值班人员在播出控制 面。在对系统的进一步实验中，发现 象，并成功捕获了一个“触发”疑似指
工作站上进行主备“接管”操作中， 在特殊功能面板上执行“触发”时， 令：01 45 52 30 30 31 37 04。
系统意外的停止了正在播出的节目， 不需要确认。因此，我们认为，在进 接下来，将对疑似指令进行验
行“接管”操作 证。经过分析，仍然采用纯软件，用
时，特殊功能面 虚拟串口的方法。验证要用到三款软
板发送了“触 件，分别是TCP/UDP Debug、USER-
发”指令。这个 COM、串口网络通道转发工具。采用
假设看似荒谬， TCP/IP协议虚拟串口，用TCP Server
但有理有据，值 的多连接，在正常的通讯链路中，插
得进一步验证。 入疑似指令，看是否触发，如图3。
接下来的 系统中，用USER-COM虚拟一
第一步，便是 个串口——TCP Client管道，串口端
设法捕捉特殊 为com20，供播出软件调用，TCP
功能面板发出 C l i e n t则用于连接串口网络转发的
图2 播出控制系统图
的“触发”指 TCP Server端。串口转发工具是TCP
转而播出下一条节目的现象，在播出 令。要捕捉特殊功能面板发出的“触 Server---串口调用管道，TCP Server
中，这个叫“触发”。最严重的是有 发”指令实属不易，但方法总是有 端与前一个管道的TCP Client连接，
一天，在间隔13分钟的时间内，故障 的，经过各种尝试，我们采用最简单 串口调用端则调用com7。这样，播
出现了两次，这个BUG无疑是致命 的软件方法，不改造线路，实施简 出软件就能与特殊功能面板正常通
的。本次排除BUG的过程细节较多， 单、速度快。我们找到了一款串口监 讯。图3的关键是串口转发工具的TCP
但限于篇幅，本节只交流实验原理， 测软件-Commonitor，可以非常简 Server端，它接受多连接，TCP/UDP
不作过多的配图。
播出控制系统如图2，主备控制工
作站经过两个RS422倒换器连接主备切
换台、主备视频服务器、特殊功能面
板、字幕系统。我台的播出控制模式
是主、备完全控制，即在某时刻，由
一台工作站控制该频道的所有设备，
当在线工作站宕机后，自动倒换到另
一台工作站控制所有设备。在日常维
图3 疑似指令验证系统

42