車載PIS服務器的設計與實現

康進赟

乘客信息系統 （PIS）是融合了多媒體網絡和計算機信息技術，通過地面站臺和車載媒體終端向乘客提供媒體信息服務的系統。目前，北京、上海、廣州、深圳、香港和天津地鐵都已開通了乘客信息系統，且在北京、廣州和深圳等已開通車載實時傳輸乘客信息服務系統。國內地鐵PIS系統普遍采用 “中心－地面－車輛”的媒體信息管理方式。車載PIS的終端直接面向乘客，對其播放的實時性和連續性有較高的用戶體驗要求。車載PIS服務器是車載PIS系統的媒體來源，通過轉發車站子系統下發的媒體信息，向車載子系統的播放終端提供媒體資源和消息服務，為車－地媒體的統一管理提供了有效的途徑。本文提出一種車載PIS服務器的設計方案，根據地面PIS系統提供的接口協議，設計服務器軟件的整體架構。

1 服務器功能需求分析

PIS系統從網絡結構上可分為3個子系統：控制中心子系統、地面車站子系統和車載子系統。地面PIS系統通過車載子系統向地鐵車輛內提供媒體服務，實現車－地信息統一發布管理。車載PIS服務器接收和管理地面PIS下發的媒體信息，通過車載交換機組傳給車載媒體終端在LCD顯示屏上播放，向乘客提供信息服務。地面PIS子系統通過車－地無線網絡向車載PIS子系統傳輸媒體信息，包括直播流媒體、墊播計劃、墊播媒體文件、滾動消息和緊急消息等。由車載PIS服務器負責接收并進行數據緩存和轉發。車載PIS的列車視頻監控（CCTV）上載也通過同一路徑傳輸至地面PIS子系統，地面CCTV在控制中心進行解碼播放。車－地PIS系統通信如圖1所示。

圖1 車－地PIS系統通信示意圖

車載PIS服務器需要實現以下功能。

1．直播模式。列車運行中，車載設備要實時接收來自地面運營中心的節目，包括媒體新聞、賽事直播和廣告等實時動態的多媒體信息，并在列車車廂的車載媒體終端上播出。地面PIS通過TS流下發直播流媒體，車載PIS服務器接收地面PIS下發的視頻流，以組播的方式實時轉發給車輛PIS系統。

2．墊播模式。根據系統提出的播放冗余控制需求，為防止客室顯示屏出現黑屏，需要在直播的基礎上加入墊播模式。若視頻源或車－地無線網絡出現故障，導致車載PIS系統接收不到直播視頻，車載PIS服務器將服務器硬盤中存儲的墊播視頻文件下發到列車以太網中，供客室服務器進行播放。

3．消息轉發。正常情況下，地面PIS系統向車輛提供乘車須知、服務時間、列車到發時間、列車時刻表、管理者公告、政府公告等滾動消息；在火災、阻塞及恐怖襲擊等非正常情況下，提供動態緊急消息提示。車載PIS服務器周期輪詢地面PIS的發送滾動消息和緊急消息，并將消息通過組播方式轉發到車輛PIS系統中。

4．列車視頻監控 （CCTV）上傳。視頻流通過列車以太網絡發送至車載PIS服務器；車載PIS服務器接收到錄像視頻流通過車載CCTV處理模塊將錄像視頻存儲到本地硬盤中，經轉發模塊將錄像視頻通過車－地無線網絡轉發至地面控制中心。

2 軟件整體框架設計

由于車載服務器各功能之間相對獨立，因此參考地面PIS系統提供的接口通信協議，按照功能分塊的模式，建立多個執行線程，完成數據轉發和文件存儲的任務。以下主要對直播模塊、墊播模塊和消息轉發模塊的設計進行介紹。軟件整體設計架構如圖2所示。

地面PIS系統向車載PIS系統以UDP組播的方式發送實時TS流，并通過補包機制盡量保證視頻流穩定可靠到達車載PIS服務器。當車輛系統由于網絡不穩定造成直播流數據丟包時，車載PIS服務器通過單播方式向地面PIS系統進行單播補包請求。確保數據包無誤后，車載PIS服務器再通過UDP組播方式下發視頻流到客室內的車載播放控制器。

圖2 車載服務器軟件架構示意圖

墊播模塊的工作機制是根據地面PIS系統下發的墊播播放計劃文件，通過FTP網絡協議從地面PIS服務器下載計劃文件中包含的墊播媒體文件。為了達到媒體文件周期更新的效果，每N分鐘從地面PIS服務器獲取新的計劃文件。計劃文件采用XML格式編碼，在本地服務器經過解析版本號等有效信息之后，比較本地新舊計劃文件，判斷是否需要更新計劃。若計劃更新，則從地面服務器下載新的媒體文件。

直播模塊實現了客室媒體播放的實時性和穩定性，采用補包機制確保了視頻流播放的連續性。墊播模塊是在直播服務中斷或車－地網絡故障的情況下提供的冗余服務，由客室媒體播放器自行切換，避免了在終端媒體播放器出現黑屏的情況，優化乘客的媒體信息服務體驗。

地面PIS系統提供數據訪問Web服務，車載PIS服務器通過http協議，以GET方式獲取地面PIS下發的滾動消息和緊急消息。對消息簡單解析和數據包分片操作之后，以組播的形式發送至各客室的播放控制服務器。

3 轉發過程關鍵接口技術的實現

3．1 UDP組播技術

在車－地PIS系統通信的過程中，地面TS流的下發和車載PIS服務器發往客室的實時消息都是通過UDP組播方式完成的。UDP組播采用的是無連接、數據報的連接方式，相比TCP協議，UDP是不可靠的連接，數據到達接收端的順序都不能保證。但是，在UDP傳輸過程中，所有數據的傳送速度很快，保證了在局域網條件下視頻和消息傳輸的實時性。

車載PIS服務器位于車輛司機控制室，采用雙網卡的物理結構，實現車載網絡與地面網絡隔離，避免網絡風暴等故障發生。外網網卡通過無線AP接入車－地無線網絡；內網網卡與車載交換機相連，接入車載PIS局域網。故在創建UDP連接后，需綁定要接收或發送數據的網卡。具體流程如下。

1．創建數據報式 （SOCK＿DGRAM）套接字，提供UDP服務。

2．通過setsockopt（）函數的SO＿BINDTO－DEVICE選項綁定網卡。

3．加入協議規定的UDP組播地址。

4．通過sendto或recvfrom進行數據的收發。

5．關閉套接字。

3．2 直播過程中的補包技術

地面PIS系統與車輛PIS之間通過WLAN網絡連接。PIS系統向車輛系統以UDP組播方式發送實時H．264／TS流。數據以分包的方式傳輸到車載PIS服務器，到達的數據包需要根據其序號檢測該段數據的完整性。當車載PIS系統由于網絡不穩定造成直播流數據丟包時，通過單播方式向地面PIS系統進行單播補包請求，地面PIS系統將H．264／TS流以UDP單播方式對車載PIS系統進行數據包重傳。

地面PIS系統向車載PIS系統發送的報文格式如圖3所示。一個報文分為包頭部分和數據部分。包頭部分包括序號、時間戳和數據校驗三個字段。

圖3 地面PIS發往車載PIS的報文結構

用8字節整數標識報文序號，車載PIS系統可根據該序號檢測是否丟包。用4字節整數標識地面PIS服務器從啟動至發送該報文的毫秒數。包頭的校驗部分采用CRC16CCITT方式對 “數據”域做CRC校驗。數據部分即為符合H．264／TS標準的流數據。

補包過程中，車載PIS系統向地面PIS系統發送UDP單播指令報文，請求需要重傳的數據包。發送的報文格式如圖4所示，它分為命令字段、最小包序號字段和最大包序號字段。

4 車載PIS向地面PIS發送的指令報文結構

報文首個字節標識車載PIS系統向地面PIS系統發送的命令請求。最小包序號表示申請重傳的最小包序號，最大包序號表示申請重傳的最大包序號。命令字段取值說明如表1所示。

表1 請求命令取值說明

結合各項請求命令，簡要分析在補包過程中的通信規則。地面PIS系統與車載PIS系統之間的補包通信過程如圖5所示。

圖5 補包通信過程

1．數據發送。地面PIS系統以UDP組播方式向網絡中不停地發送實時H．264／TS流。

2．開始接收 （START）。當某列車的車載PIS系統設備開始接收實時視頻流時，應向地面PIS系統發送START命令。

3．保活 （KEEP＿LIVE）。每列車的車載PIS系統設備固定時間間隔向地面PIS系統發送KEEP＿LIVE命令，告知地面PIS系統，車載設備處于在線狀態。

4．重傳 （RESEND）。當某列車的車載PIS系統設備檢測到丟包時，向地面PIS系統發送RESEND命令，地面PIS系統將向該車以UDP單播的方式重新發送最小包序號 （含該包）至最大包序號 （含該包）之間的所有包。如果列車的車載PIS系統設備在1s內沒有收到中心重傳的包，則重發RESEND命令。

5．停止接收 （STOP）。當某列車的車載PIS系統設備停止接收實時視頻流時，應向PIS系統發送STOP命令。

3．3 基于XML格式的計劃解析

為了統一播放計劃的數據結構，采用XML格式編碼播放計劃文件。服務器軟件采用QT類庫中的QDomDocument類，實現XML解析功能。QDomDocument類代表整個的XML文件，是文檔樹的根節點，并提供了文檔數據的基本訪問方法。

計劃文件解析過程如圖6所示。首先通過QFile打開文檔，新建QDomDocument對象，使用setContent方法設置文檔的全部內容，該函數解析傳入的XML文檔字符串并創建代表文檔的DOM樹。根節點可以使用documentElement（）得到，方法childNodes將根節點下一級的所有子節點初始化為一個NodeList，即節點數組。通過遍歷所有子節點，同時判斷節點標簽是否符合約定的XML標簽名稱。

若合法的節點沒有有效的子節點，則通過QDomNode將其實例化后，調用nodeName方法獲取其標簽內容，存入對應的共享變量中。若節點下仍存在需要解析的子節點，則再進行同上所述的解析操作，直到整個文檔有效內容提取結束為止。

圖6 計劃文件解析過程

4 程序運行流程分析

車載PIS服務器搭建于基于ARM架構的嵌入式主板上，操作系統采用嵌入式Linux。考慮到嵌入式主板資源有限，開發任務在PC平臺完成。通過交叉編譯后將執行文件部署至服務器。

程序功能主要由QT實現，QT是具有跨平臺特性的C＋＋開發框架。在嵌入式環境下運行程序，需配置相應的QT依賴庫運行環境。

官方提供的開源運行庫是面向各個平臺的，需將源代碼包通過編譯后得到arm－linux平臺下的QtEmbedded版本庫。將編譯好的lib目錄拷貝至目 標 機，即 ARM 主 板 的／opt／local／Trolltech／QtEmbedded－4．x．x／目錄下，即可運行 PC工程目錄下交叉編譯好的執行文件。

程序運行流程如圖7所示。在程序啟動之后，依次啟動直播服務線程、消息服務線程和墊播服務線程。

圖7 程序運行流程

直播線程開啟之后，初始化UDP套接字，綁定接入車－地網絡的網卡、本地IP和端口，然后加入UDP組播地址，開始接收來自地面PIS系統的TS流數據包。檢查數據包及補包過程在此不再贅述。將數據包存入緩存區后，檢測向下組播的套接字是否打開，若未開啟，則創建套接字，綁定到連接車載PIS網絡的網卡，加入組播地址后，向下發送直播數據包。

消息線程通過訪問地面數據Web服務，從地面服務器獲取消息。分析獲取之后的數據判斷類型，滾動和緊急消息經過分片處理后通過UDP組播的方式下發到客室服務器。若收到消息為空則為異常，丟棄該數據不作處理，重新獲取消息。

墊播線程是通過FTP定期下載播放計劃的方式更新本地媒體文件。程序初始化后開始定時，當更新定時到達時，執行FTP下載任務。下載的計劃文件經過XML解析后，與本地的原有計劃進行對比，若計劃沒有發生變化，則重新定時，等待下次更新計劃。若新的計劃發生變化，根據計劃解析出媒體列表下載新的媒體文件。

5 結論

車載PIS服務器是車載PIS系統面向地面PIS系統的通信接口，一方面實時轉發地面PIS系統下發的媒體流和文本信息，另一方面向客室播放器提供備用的墊播服務。在確保車載媒體終端的播放內容具有實時性和連續性的同時，讓乘客得到更豐富多彩的媒體信息服務體驗。

［1］ 汪曉臣，于鑫，闞庭明，孫同慶．基于數字媒體技術的乘客信息系統軟件框架設計［J］．鐵 路 計 算 機 應用，2012，21（4）．

［2］ 馬奇志．城市軌道交通乘客信息系統［J］．電視 技 術，2013，37（19）．

［3］ 曾金，毛燕琴，沈蘇彬．嵌入式流媒體服務器的設計與實現［J］．計算機技術與發展，2011，21（7）．