智慧運維系統中的全節點動態鏈路圖的技術實現

劉偉東 楊俊康

（作者單位：紫金電視調頻轉播臺）

廣播電視是引導全社會樹立正確價值觀，弘揚社會主旋律、傳播正能量、推動科學文化傳播和社會發展的重要媒介[1]，也是黨和政府傳播意識形態、鞏固黨和人民共同思想基礎的有效途徑[2]。

在如今的數字化時代，媒體融合發展是傳統廣電創新轉型的趨勢，也是國家戰略。要實現媒體融合，就需要在智慧廣電建設的路徑下去推動，媒體融合是方向，智慧廣電是實踐路徑。國家廣播電視總局也在2018年11月印發《關于促進智慧廣電發展的指導意見》，為智慧廣電的發展指明了要點，推動智慧廣電建設[3]。

在智慧廣電建設中，智慧運維又是重要環節。它通過數字化、網絡化、智慧化的方式助力廣播電視安全播出，是保障廣電視聽安全的重要舉措[4]。

發射臺智慧運維一般過程是數據采集、存儲管理、處理分析、智能控制、可視化呈現、異態報警通知，涉及物聯網、流媒體、數據存儲、專用算法、萬維網（World Wide Web, Web）、移動開發等技術?？蓪崿F節傳設備、發射機、信源/節目、動力環境等的智能監管。但他們都是獨立的業務模塊，需要一個將分散業務整合起來的功能，這就需要提到本次介紹的全節點動態鏈路圖。

1 全節點動態鏈路圖的定義與意義

1.1 全節點動態鏈路圖定義

鏈路圖是一種圖形化表示系統內組件間邏輯關系的展示方式。在鏈路圖中，通常通過節點或符號來表示一個組件，以組件之間的連線或者箭頭來表示組件間的邏輯關系。

發射臺的全節點動態鏈路圖（見圖1）能夠實現對眾多節傳設備、發射機實時工況監測、信源狀態監測、節目播出情況監測。同時，展示頻點發射鏈路中信號的流向，即從衛星、光纖、微波接收信號開始，到發射塔發射結束的全鏈路監控展示。

1.2 全節點動態鏈路圖的意義

全節點動態鏈路圖是發射臺智慧運維系統的重要組成部分，它在全鏈路監測環節具有如下三點重要作用：

（1）直觀展示廣電傳輸網絡的結構和連接關系，使信號傳輸過程的監測和管理變得更加方便。

（2）展示系統內各設備節點的實時工況、信源/節目情況，幫助值班人員更簡單、清晰地了解整個系統的運行狀態。

（3）當發生故障時，可以協助值班人員快速定位故障點，使故障能夠得到及時處理。

總而言之，全節點動態鏈路圖可以滿足全鏈路集中監管需求，提高值班人員監管效率，助力整套發射系統穩定運行，在一定程度上降低了播出風險。

2 全節點動態鏈路圖的實現

2.1 總體設計

系統總體為瀏覽器/服務器模式（Browser/Server,B/S）架構。其中，瀏覽器作為全節點動態鏈路圖的用戶顯示前端，擺脫了固定在應用程序（Application,App）上使用的限制，打開手機、平板或是計算機中的瀏覽器，使用局域網，即可訪問全節點動態鏈路圖頁面，隨時隨地進行監測監管。

全節點動態鏈路圖整合了節傳設備、發射機、信源節目等對象，每一個對象都擁有一個管理層，管理層獲取對象的實時工況信息、判斷報警，并與全節點動態鏈路圖共享數據、實時聯動。

2.2 節傳設備接入

節傳設備在通信網絡中，一般充當服務器的角色。也就是說，通信另一方的客戶端需要知道設備的網絡IP地址，然后才能進行鏈接并通信。發射臺里節傳設備眾多，如果是手動管理地址，那么需要逐個設置每個節傳設備的IP地址，這是一件相當煩瑣、重復性高，且容易出錯的事情。

更加方便快捷，并且更不易出錯的IP地址管理方式應該是啟用動態主機配置協議（Dynamic Host Configuration Protocol, DHCP），讓DHCP服務器動態分配IP地址給每個設備。但IP動態分配后，設備管理端又無法直接獲取設備的IP地址，這時就需要通過設備發現來獲取。

IP地址動態分配后，局域網內每臺設備的IP地址就是變化的，設備就需要一種方式將自己的IP地址通知給管理端。傳輸控制協議（Transmission Control Protocol, TCP）只能在知道目標IP端口的情況下，點對點通信，所以選擇用戶數據報協議（User Datagram Protocol, UDP）下的廣播或組播進行一對多通信。將自己的IP按一定協議封裝后，“喊”給局域網內的所有通信對象“聽”，客戶端“聽到”后按預先約定協議解析后便能得到對方的IP地址。

由于廣播傳播數據時，會把同一數據包復制給網絡中的所有主機，浪費了一定的帶寬，特定條件還可能造成廣播風暴，引起網絡癱瘓。反觀組播，其數據只傳遞給加入該組的成員主機，傳播過程中只有一份數據，在臨近成員主機的組播路由器時才復制并分發數據給成員主機，節省了網絡帶寬。選擇UDP組播方式傳遞IP地址給客戶端是最佳方案。

但UDP不提供傳輸可靠性，消息存在丟失的可能，需要在通信協議上確保通信的可靠性。因此，需學習TCP協議底層通信機制，即通過確認應答來相互確認已收到對方發送的消息，同時聯合超時重傳機制，確保設備發現過程的可靠性。

最后，在數據通信時采用面向鏈接的、可靠傳輸的TCP協議，以便及時發現節傳設備損壞、斷電、斷網等突然“下線”的情況，發現流程如下：

2.2.1 設備端發現流程

（1）設備接入網絡并獲取DHCP動態分配的網絡IP地址。

（2）空閑時主動發送UDP組播消息，通告自己上線。

（3）利用定時器中斷的觸發時間，等待管理端回復上線確認。

（4）如果中斷觸發前仍未收到管理端上線確認消息，再次通告上線消息。

（5）否則，向管理端進行UDP點對點回復上線完成消息，并關閉該中斷。

（6）開啟TCP服務等待管理端鏈接。

2.2.2 管理端發現流程

（1）管理端接入網絡并獲取分配的網絡IP地址。

（2）加入同一組播地址，接收設備上線通知。

（3）收到設備上線消息后，針對該設備進行UDP點對點回復上線確認消息。

（4）利用定時器，等待設備上線完成消息。

（5）如果超時前收到上線完成消息，以TCP客戶端身份鏈接設備端。

（6）否則，再次進行UDP點對點回復上線確認。

2.3 發射機接入

發射機廠家繁多，同一廠家的發射機協議版本也多，需要想辦法封裝發射機協議細節，解耦通信上下游的協議依賴，將添加或改變協議的影響控制在最小范圍。

最終選擇在管理層與發射機之間添加嵌入式層來封裝協議細節，嵌入式層對接發射機，將各種各樣的發射機協議轉換為統一的協議后發送給管理層。

嵌入式層與管理端序列化協議設計如下：

（1）報頭/報尾：確定協議的開始/結束。

（2）消息ID：表示消息號，是單調遞增的數字，具有唯一性、有序性的特點，讓消息具有冪等性。

（3）模塊類型/模塊地址：用來區分功能模塊，將采集、控制、設置、空中下載（Over-the-Air,OTA）等劃分為獨立模塊，并通過模塊地址尋址。

（4）命令代碼：表示操作指令，用來區分協議類型。

（5）數據長度：描述數據段的長度（字節）。

（6）數據段區域承載通信的內容。

（7）檢驗和：保證通信內容的完整性、準確性，通信的兩端均以消息相同部分作為計算參數，使用相同的算法進行計算，如果接收端計算的結果與校驗和不同，則表明傳輸過程出現了差錯[5]。

數據段為參數列表，其為封裝發射機協議細節的關鍵。

一個參數由參數代碼、參數長度、參數內容組成，參數列表表示多個參數的集合。

（1）參數代碼：描述參數值的類型。

（2）參數長度：描述參數值占用字節數。

（3）參數值：表示參數的內容。

通過列表化發射機屬性后，管理層以及后續層級看不到各式各樣發射機協議上發射機屬性的差異，只需統一以列表的方式識別參數，通過參數代碼判斷參數類型，隨后進行相應邏輯處理即可。也就達成了封裝發射機協議細節，解耦通信上下游的協議依賴的目的。

對比參數列表方案與常用方案，通過結構體方式描述協議（在數據段填“普通舊數據”類型結構體）。假設發射機生產廠家數為M，每個廠家有N種發射機，通信鏈路有K層：

（1）結構體方案：K層通信鏈路，序列化反序列化次數之和為2（K-1），接入全部N×M種協議。因為每種協議發射機屬性不同，所以數據段承載的結構體也必然不同，而每種結構體都需要獨立的序列化與反序列化代碼。最終，序列化與反序列化代碼一共需要增加（N×M）×2（K-1）處。

（2）參數列表方案：K層通信鏈路，序列化反序列化次數之和為2（K-1），接入全部N×M種協議。由于以同樣的結構傳遞N×M協議，所以反序列化處代碼可通用，僅需增加1處即可；序列化處需要將N×M種協議轉換為參數列表，需要增加（N×M）處代碼。最終，序列化與反序列化代碼一共需增加N×M+1處代碼。

參數列表化方案比常用方案減少了（N×M）×2（K-1）-N×M+1處代碼，提高了編碼效率，也減少了產生程序錯誤的可能。

2.4 節目接入

節目來自組播信源流，一個信源流內包含多套節目。為了達到實時播放的目的，需要實現流媒體服務器推送視頻/音頻流，網頁前端播放器在下載的同時進行播放。

國內主流的直播流媒體協議有動態碼率自適應技術（HTTP Live Streaming, HLS）、實時消息傳輸協議（Real Time Messaging Protocol, RTMP）、HTTP-FLV（即將音視頻數據封裝成FLV，然后通過HTTP協議傳輸給客戶端）。

HLS通過超文本傳輸協議（Hypertext Transfer Protocol, HTTP）傳輸，優點是能夠避免防火墻攔截，自帶動態碼率自適應，支持平臺多。其缺點是播放時會不停獲取視頻切片，延遲較高。

RTMP通過TCP傳輸，延遲低，長時間播放穩定，計算機平臺普遍可播放，但不支持HTML5（構建Web內容的一種語言描述方式），也存在被防火墻攔截的可能。

HTTP-FLV通過HTTP傳輸，能夠避免防火墻攔截，播放時沒有復雜交互，延遲較低，支持HTML5。

對比之后，最終選擇HTTP-FLV方式實現流媒體服務器的推流。

流媒體服務器運行流程如圖2所示：

圖2 流媒體服務器運行流程

2.5 鏈路圖整合

由于發射臺性質的差異，各臺站的節傳設備種類、節目類型、信號傳輸拓撲結構均有所差異，為了適應這種差異化，真實布局臺站的實際傳輸鏈路，全節點動態鏈路圖需要做到可編輯。

編輯主要涉及兩點：一是管理鏈路與節點基本屬性，同時負責管理鏈路與節點間的歸屬關系、節點與具體節傳設備/發射機/節目的對應關系；二是可拖拽式布局，主要負責節點在鏈路中的布局，反映鏈路節點的上下游關系。經過編輯后，真實鏈路布局便以邏輯關系的形式映射在鏈路圖中。

在全節點動態鏈路圖中的每個設備節點、發射機節點、節目節點均有全局唯一的ID，數據在節傳設備、發射機管理層、流媒體服務器與全節點動態鏈路圖Web服務器間流轉時，通過ID來將每個節點進行區分。每當節點對應設備工況發生變化或報警發生時，網頁前端根據唯一ID精準顯示。

3 結語

全節點動態鏈路圖接入并聯動了節傳設備、發射機、信源節目，將智慧運維系統分散、獨立的業務模塊整合起來，直觀、實時地展示鏈路內各節點設備的工況信息，實現全鏈路的集中監管，使智慧運維系統更加完善，定位排障更加容易，監管更加高效，系統更加穩定。