羅星屏

【摘要】在播出系統(tǒng)中，基于安全和穩(wěn)定要求，核心設(shè)備均是通過串口實現(xiàn)控制。本文介紹了虛擬串口在播出中的新應(yīng)用，解決了多個技術(shù)問題，并對未來的播出控制架構(gòu)作了探索性研究，與同行分享。

引言

虛擬串口，不是指虛擬機上的串口，而是指通過USB、IP等擴展得到的邏輯串口資源，在操作系統(tǒng)里看到的是端口（COM和LPT）資源，這種擴展在物理機和虛擬機中都可實現(xiàn)。虛擬串口存在的形式多樣，有近端的、遠(yuǎn)端的，有硬件的、邏輯的，接口方式有RS485、RS422、RS232等。在實際使用中，虛擬串口并不局限于上述范疇，本文探討更加廣義的虛擬串口技術(shù)應(yīng)用。隨著IP技術(shù)的發(fā)展和普及，基于IP協(xié)議的虛擬串口軟、硬件產(chǎn)品可選擇性較多，這類技術(shù)可統(tǒng)稱Serial over IP。

播出系統(tǒng)是全臺安全要求最高的系統(tǒng)，基于這個要求，核心設(shè)備如切換臺、視頻服務(wù)器等都只支持串口控制，對應(yīng)的串口控制協(xié)議分別是Automation、VDCP。這是國際上電視播出的通常做法，事實證明串口控制是穩(wěn)定、安全、實用的。

本文主要探討虛擬串口在遠(yuǎn)程上載控制、播控軟件重大BUG排除、安全隔離、播出主備并行控制等方面的創(chuàng)新應(yīng)用。

一.虛擬串口在遠(yuǎn)程上載控制中的應(yīng)用

我臺新聞中心搬遷到新址大樓后，新聞頻道的機構(gòu)、人員、節(jié)目生產(chǎn)系統(tǒng)與當(dāng)時的播出系統(tǒng)分別位于嘉陵江的兩岸，直線距離14公里。按照廣告管理職責(zé)要求，新聞頻道廣告送播人員每天需要對時段廣告進(jìn)行上載更新，這項操作是在播出系統(tǒng)完成。另外，新聞頻道廣告送播人員還要負(fù)責(zé)新聞欄目插播廣告的更新及片段合成，這項操作在節(jié)目生產(chǎn)系統(tǒng)里完成。由于節(jié)目生產(chǎn)系統(tǒng)和播出系統(tǒng)距離遠(yuǎn)，靠人員來回奔波顯然是不現(xiàn)實的。那么，如何才能解決新聞頻道的廣告上載問題呢？

新聞中心搬遷時，我臺現(xiàn)址的播出網(wǎng)絡(luò)已延伸到新址，用于新聞頻道節(jié)目、字幕編排，并且在兩地也有HD SDI鏈路互傳信號。我們采用的方案是將上載工作站部署到新聞制作機房，讓該頻道廣告送播人員遠(yuǎn)程上載廣告到現(xiàn)址的播出網(wǎng)里。解決本次遠(yuǎn)程上載的主要難點是視頻服務(wù)器的遠(yuǎn)程控制，如果采用傳統(tǒng)的方法，除需購買特殊的設(shè)備，還要占用城域光纖資源，可行性較差。因此，我們采用基于網(wǎng)絡(luò)的虛擬串口技術(shù)，解決遠(yuǎn)程控制問題，如圖1。

本方案中，虛擬串口采用MOXA Nport5430，該設(shè)備有4個串口，滿足本次應(yīng)用。首先給5430分配一個IP地址，制作好RS422電纜、網(wǎng)線等。各設(shè)備離線開機，確保IP正確后，插上網(wǎng)線，調(diào)整各設(shè)備參數(shù)。登錄Nport5430 WEB 管理， 把所有port的運行模式Operation mode調(diào)整為實時串口realcom，并把串口參數(shù)設(shè)為VDCP常規(guī)參數(shù)：38400、8、1、O、n。在上載工作站上安裝MOXA驅(qū)動管理軟件，得到4個串口資源，在上載軟件的配置、操作習(xí)慣上，與本地上載沒有區(qū)別。上線調(diào)試成功，運行穩(wěn)定，直到2017年4月播出也搬遷到新址后，該遠(yuǎn)程上載停止使用。

需要注意的是，虛擬串口的通信參數(shù)的設(shè)置必須在串口盒子上操作，因為本地得到的串口資源是TCP/IP虛擬的，如果被控設(shè)備的參數(shù)有變化，也需要在串口盒子上修改。

二.虛擬串口在排除播出控制軟件BUG中的應(yīng)用

我臺全頻道高清播總控于2016年底建成，2017年4月完成所有頻道向新播控系統(tǒng)的轉(zhuǎn)移，按照播控系統(tǒng)的運行規(guī)律，投入使用后的一年半時間內(nèi)，都屬觀察期，出現(xiàn)BUG可能性較大。2018年初，值班人員在播出控制工作站上進(jìn)行主備“接管”操作中，系統(tǒng)意外的停止了正在播出的節(jié)目，轉(zhuǎn)而播出下一條節(jié)目的現(xiàn)象，在播出中，這個叫“觸發(fā)”。最嚴(yán)重的是有一天，在間隔13分鐘的時間內(nèi)，故障出現(xiàn)了兩次，這個BUG無疑是致命的。本次排除BUG的過程細(xì)節(jié)較多，但限于篇幅，本節(jié)只交流實驗原理，不作過多的配圖。

播出控制系統(tǒng)如圖2，主備控制工作站經(jīng)過兩個RS422倒換器連接主備切換臺、主備視頻服務(wù)器、特殊功能面板、字幕系統(tǒng)。我臺的播出控制模式是主、備完全控制，即在某時刻，由一臺工作站控制該頻道的所有設(shè)備，當(dāng)在線工作站宕機后，自動倒換到另一臺工作站控制所有設(shè)備。在日常維護(hù)、處理播表時，也可以手動操作倒換，這個操作通過鼠標(biāo)點擊“接管”按鈕或在特殊功能面板上按鍵執(zhí)行。

經(jīng)過詢問值班人員、調(diào)取監(jiān)控等，發(fā)現(xiàn)無人為因素、無操作失誤等情況，我們把相關(guān)的編排和日志發(fā)給廠家，但廠家也未能定位原因。于是播控部成立專門的小組，組織力量攻克這個難題。

在對故障發(fā)生時的現(xiàn)象進(jìn)行多次梳理后，發(fā)現(xiàn)了一個極其重要的突破點。在播出軟件用鼠標(biāo)“觸發(fā)”時，在點擊“觸發(fā)”按鈕后，會彈出一個確認(rèn)界面，確認(rèn)后才會生效執(zhí)行。但根據(jù)當(dāng)班值班人員的描述和監(jiān)控拍到的工作站屏幕，并沒有出現(xiàn)這類界面。在對系統(tǒng)的進(jìn)一步實驗中，發(fā)現(xiàn)在特殊功能面板上執(zhí)行“觸發(fā)”時，不需要確認(rèn)。因此，我們認(rèn)為，在進(jìn)行“接管”操作時，特殊功能面板發(fā)送了“觸發(fā)”指令。這個假設(shè)看似荒謬，但有理有據(jù)，值得進(jìn)一步驗證。

接下來的第一步，便是設(shè)法捕捉特殊功能面板發(fā)出的“觸發(fā)”指令。要捕捉特殊功能面板發(fā)出的“觸發(fā)”指令實屬不易，但方法總是有的，經(jīng)過各種嘗試，我們采用最簡單的軟件方法，不改造線路，實施簡單、速度快。我們找到了一款串口監(jiān)測軟件-Commonitor，可以非常簡單的捕捉串口數(shù)據(jù)，希望捕捉到“觸發(fā)”指令。Commonitor的操作非常簡單，只需注意，要先啟動端口監(jiān)測，再打開播出軟件。于是開啟該軟件，對特殊功能面板對應(yīng)的串口com7進(jìn)行監(jiān)測，手動操作“接管”按鈕，爭取盡早捕獲到“觸發(fā)”指令。在正常工作狀態(tài)和接管操作過程中，Commonitor捕捉到的是播出軟件與特殊功能面板每秒一次的握手信息，分別是16進(jìn)制23、24。由于該事故的發(fā)生率為千分之一（事后總結(jié)的概率）很低，幾天后仍沒捕獲到。我們采用鼠標(biāo)自動點擊軟件，在主備工作站上模擬人工操作。果然方法得當(dāng)，效果不一樣，不到半天就出現(xiàn)了“觸發(fā)”節(jié)目的現(xiàn)象，并成功捕獲了一個“觸發(fā)”疑似指令：01 45 52 30 30 31 37 04。

接下來，將對疑似指令進(jìn)行驗證。經(jīng)過分析，仍然采用純軟件，用虛擬串口的方法。驗證要用到三款軟件，分別是TCP/UDP Debug、USERCOM、串口網(wǎng)絡(luò)通道轉(zhuǎn)發(fā)工具。采用TCP/IP協(xié)議虛擬串口，用TCP Server的多連接，在正常的通訊鏈路中，插入疑似指令，看是否觸發(fā)，如圖3。

系統(tǒng)中，用USER-COM虛擬一個串口——TCP Client管道，串口端為com20，供播出軟件調(diào)用，TCP Client則用于連接串口網(wǎng)絡(luò)轉(zhuǎn)發(fā)的TCP Server端。串口轉(zhuǎn)發(fā)工具是TCP Server---串口調(diào)用管道，TCP Server端與前一個管道的TCP Client連接，串口調(diào)用端則調(diào)用com7。這樣，播出軟件就能與特殊功能面板正常通訊。圖3的關(guān)鍵是串口轉(zhuǎn)發(fā)工具的TCP Server端，它接受多連接，TCP/UDP Debug聯(lián)上之后，便能向鏈路插入疑似指令。通過驗證，證實了01 45 52 30 30 31 37 04的確能觸發(fā)節(jié)目。但進(jìn)一步的測試發(fā)現(xiàn)，真正的人工觸發(fā)，面板發(fā)出的指令是：01 54 4B 30 30 31 46 04。于是對特殊功能面板的8個按鍵依次測試，發(fā)現(xiàn)播出軟件只是識別面板的第4字節(jié)，來實現(xiàn)各種功能，巧的是疑似指令的第4字節(jié)與觸發(fā)指令的對應(yīng)字節(jié)相同，“觸發(fā)”事故就發(fā)生了。

由于該面板實際使用中很少用，斷電即可解決這個問題。但實驗不能就此為止，為何會在倒換的時候發(fā)出“觸發(fā)指令”，這個指令是在工作站端口捕獲到的，在面板和工作站之間還有RS422倒換器。那到底是某個設(shè)備單獨導(dǎo)致的，還是有更加復(fù)雜的機理導(dǎo)致的呢？通過分析，發(fā)現(xiàn)RS422倒換器是簡單的繼電器倒換，原理和電路很簡單，沒什么可分析測試的，于是把重點放在特殊功能面板上。用閑置的特殊功能面板，與測試電腦搭建系統(tǒng)，模擬工作站與特殊功能面板的握手/應(yīng)答，并用特殊的方法模擬RS422倒換器的通斷，就是用導(dǎo)線摩擦拉絲鋼板，利用拉絲鋼板的凹凸制造頻繁的通斷，同樣用commonitor捕獲“觸發(fā)指令”。因為通信速率低，捕捉很難。于是在串口收發(fā)數(shù)據(jù)的軟件上，提高握手頻率至每秒100次，很快便捕獲了“觸發(fā)指令”。通過仔細(xì)分析捕獲的數(shù)據(jù)，發(fā)現(xiàn)，是由于線路的通斷，切斷了字節(jié)，在切斷時，特殊功能面板沒有發(fā)出異常數(shù)據(jù)，但在后續(xù)數(shù)據(jù)恢復(fù)正常時，特殊功能面板會發(fā)出一個通訊恢復(fù)正常的消息。這個通訊恢復(fù)正常的消息，正式前面得到驗證的“觸發(fā)”指令。從上面的實驗看出，播出軟件、特殊功能面板、RS422倒換器三者共同作用，產(chǎn)生了“接管”變“觸發(fā)”的BUG。

事到如此，整個事故機理真相大白，與軟件廠商溝通后，得到進(jìn)一步確認(rèn)。廠家同意修改軟件，按全字段匹配來識別特殊功能面板。由于特殊功能面板實際很少使用，并且播出軟件運行穩(wěn)定，因此我們對特殊功能面板直接斷電停用，而軟件不作更新，“接管”導(dǎo)致“觸發(fā)”節(jié)目的故障此后沒有再次發(fā)生。

三.虛擬串口在安全隔離中的應(yīng)用

由于安全的要求，播出系統(tǒng)與其它網(wǎng)絡(luò)不能直接連接。然而，與其它業(yè)務(wù)系統(tǒng)連接的需求仍然存在，本節(jié)主要介紹，用虛擬串口模擬網(wǎng)閘功能，從辦公網(wǎng)獲取NTP時間，作為播出網(wǎng)的備用NTP服務(wù)授時，如圖4。

在大多數(shù)情況下，虛擬串口都當(dāng)做實時串口使用REAL COM，但實際上，虛擬串口設(shè)備的工作模式較多。在本案例中，用了兩個虛擬串口服務(wù)器，分別以UDP服務(wù)器和UDP客戶機的方式出現(xiàn)。UDP客戶機的網(wǎng)口連接辦公網(wǎng)，在NPort5430 的web頁面設(shè)置目標(biāo)NTP服務(wù)器的地址是阿里云120.25.115.20，端口設(shè)為123（NTP專用端口），并將串口設(shè)為缺省設(shè)置9600、8、1、n、n。UDP服務(wù)器的網(wǎng)口連接播出網(wǎng)，在NPort5430的web頁面設(shè)置監(jiān)聽端口為123，該通道就變?yōu)镹TP 服務(wù)器，同時也將串口設(shè)為缺省設(shè)置9600、8、1、n、n。用RS422交叉線將兩個盒子對應(yīng)的RS422連接，上線測試，成功。

在本應(yīng)用中，播出網(wǎng)和辦公網(wǎng)之間采用RS422連接，沒有網(wǎng)絡(luò)及TCP/ IP連接，黑客和病毒沒有入侵和傳播路徑。需要注意的是，NPort5430作為NTP Server授時，連接的終端數(shù)只有4個，需要用服務(wù)器二次授時，該方案實際使用中，穩(wěn)定可靠。

四.虛擬串口技術(shù)在主備并行控制中的應(yīng)用

根據(jù)國家廣電總局62令規(guī)定，省級臺的電視播出系統(tǒng)必須是雙鏈路，包括電源、視頻服務(wù)器、切換臺、控制工作站，不能有任何單點。在現(xiàn)實的情況下，播出系統(tǒng)的重要設(shè)備如切換臺、視頻服務(wù)器等都只支持串口控制，并且只允許一個串口控制。在以往的系統(tǒng)中，出現(xiàn)過三種控制模式，主備獨立控制、主備完全控制、主備混合控制。主備獨立控制模式中，主工作站控制主切換臺、主視頻服務(wù)器，備工作站控制備切換臺、備視頻服務(wù)器。該方式結(jié)構(gòu)清晰，沒有倒換操作，缺點是一臺工作站宕機后，一半的設(shè)備失控。為了規(guī)避這個問題，廠商推出主備完全控制模式，主備切換臺、主備視頻服務(wù)器由一臺工作站控制，一臺工作站宕機后，自動倒換到另外一臺工作站，該模式規(guī)避了獨立控制模式的設(shè)備失控問題。但是，倒換操作如果發(fā)生在短節(jié)目時，可能會有丟失指令，而導(dǎo)致不切換、不播素材的現(xiàn)象。另外一個不容忽視的問題是，如果在線的工作站處于假死狀態(tài)，則不會自動倒換，就會主備全部停播，導(dǎo)致事故?；旌现鱾淠Ｊ绞窃谥鱾渫耆刂频幕A(chǔ)上，把備RS422倒換器設(shè)定為手動倒換。正常工作時，主工作站控制主視頻服務(wù)器、主切換臺，當(dāng)主工作站宕機后，自動倒換到備工作站。而備工作站，控制備切換臺、備視頻服務(wù)器，當(dāng)備機宕機時，RS422不會自動倒換到主機，只能手動倒換。該控制模式中，主備工作站都能執(zhí)行素材到位確認(rèn)，并且任何一臺工作站假死時，都不會出現(xiàn)主備完全停播的情況。該模式的缺點是，結(jié)構(gòu)不清晰，值班員判斷和執(zhí)行倒換的時機不易把握，應(yīng)急處置時，需要對信號切換和控制切換聯(lián)動操作。

主備播出并行控制模式，是我們一直在探討的課題，也是本文的重點，該模式如能成功推向應(yīng)用，將改變RS422倒換器在播出控制中的歷史。該模式的主要思路是，用虛擬串口匯集主備工作站的控制指令，實現(xiàn)主備播出工作站對主備切換臺、主備視頻服務(wù)器的并行控制。該模式有兩個技術(shù)依據(jù)，第一是基于IP的虛擬串口對主備工作站的指令匯集作用。第二是，切換臺、視頻服務(wù)器對兩個時間緊挨著的、相同指令的正確響應(yīng)。并行控制模式避免了工作站假死、倒換丟失指令、人工操作延誤時機等缺點，是完全無感知的主備并行控制模式，如圖5。該方案中，只需要對主備工作站添加相同的虛擬串口，如圖中com3，IP地址指向同一個Nport5430的同一個串口單元即可。由于Nport5430內(nèi)沒有運行任何軟件，只需簡單的配置即可，因此，如果后期損壞，直接更換或替換別的產(chǎn)品即可。

我臺高清播總控系統(tǒng)建設(shè)中，我們對該模式進(jìn)行了在線測試，證明是可行的，與軟件廠商進(jìn)行了勾通，準(zhǔn)備推向?qū)嵱谩Ｔ趯崪y中，也發(fā)現(xiàn)些問題需要改進(jìn)，比如由于軟件頻繁查詢視頻服務(wù)器，致使播短節(jié)目如5秒廣告時，播出會出現(xiàn)自動墊片的現(xiàn)象，需要優(yōu)化代碼才能消除此類現(xiàn)象。另外、主備工作站的指令要同時到達(dá)切換臺、視頻服務(wù)器，對系統(tǒng)的授時精度、主備軟件的響應(yīng)速度要求極高，否則會造成指令交叉，致使設(shè)備誤動作。

由于當(dāng)時高清播出上線時間緊，所以沒有采納該模式。目前，我臺正在規(guī)劃4k播出頻道，播出工作站的控制模式又被提上議題。改進(jìn)上述缺陷后，如能有效提高安全性、可靠性，就可在4k播出系統(tǒng)中推進(jìn)應(yīng)用。B&P