吳艷春

（福州地鐵建設(shè)有限公司，福建 福州 350000）

1 前言

城市軌道交通的全自動運行系統(tǒng)是基于現(xiàn)代計算機、通信、控制和系統(tǒng)集成等技術(shù)，由信號、車輛、綜合監(jiān)控、通信、站臺門等系統(tǒng)設(shè)備組成，實現(xiàn)列車運行全過程自動化的系統(tǒng)。其中，綜合監(jiān)控在全自動運行系統(tǒng)中承擔(dān)著“眼睛”的職能，尤其是對于控制中心的調(diào)度人員來說，需要全面地掌控列車的全部運行信息，以便于更加精準(zhǔn)地根據(jù)各種工況做出及時、合理的判斷和指揮。

《城市軌道交通全自動運行系統(tǒng)技術(shù)指南(試行)》中提出：“全自動運行系統(tǒng)控制中心應(yīng)具備車輛監(jiān)控功能、乘客服務(wù)功能。車輛監(jiān)控功能宜納入信號系統(tǒng)，乘客服務(wù)功能宜納入綜合監(jiān)控系統(tǒng)。”但由于如今車輛系統(tǒng)需上傳至中心的數(shù)據(jù)量較大，超過了LTE 綜合承載的帶寬限制，車輛監(jiān)控功能不能完整地納入信號系統(tǒng)，因此，通過綜合監(jiān)控系統(tǒng)在OCC 完整地顯示車輛全部運行狀態(tài)數(shù)據(jù)，正越來越多地被應(yīng)用在各城市軌道交通的全自動運行線路建設(shè)中。本文通過分析調(diào)度人員對于車輛數(shù)據(jù)的使用需求，并調(diào)研各地的實現(xiàn)方案，歸納得出目前綜合監(jiān)控與車輛的接口方案存在3 種方式，通過各方案優(yōu)缺點的比較，提出合理的方案，供各地建設(shè)方、運營方、設(shè)計方、集成商參考。

2 運營需求

全自動線路OCC 對于車輛的監(jiān)控需求可分為與行車直接相關(guān)（如進路觸發(fā)、停車發(fā)車、車門開關(guān)、休眠喚醒、工況執(zhí)行、FAM 授權(quán)、制動及緩解等），以及與非行車直接相關(guān)（如車廂CCTV 聯(lián)動信息、司機室監(jiān)控面板在OCC 的復(fù)現(xiàn)、車輛維護診斷數(shù)據(jù)展示、車載PIS 下發(fā)、車載CCTV 調(diào)用）兩類。對于與行車直接相關(guān)的車輛數(shù)據(jù)，均可通過信號ATS 系統(tǒng)顯示，此類數(shù)據(jù)的相關(guān)接入方案較為成熟，不在本文討論范圍之內(nèi)；而與非行車直接相關(guān)的數(shù)據(jù)，需要在綜合監(jiān)控的中心調(diào)度員界面中進行展示，此類數(shù)據(jù)可進一步分為監(jiān)視信息和控制命令。

2.1 監(jiān)視信息

即綜合監(jiān)控從車輛獲得相應(yīng)的信息點位，進行分析處理后，在人機界面中進行顯示，并根據(jù)用戶要求作為執(zhí)行后續(xù)動作的判斷，內(nèi)容如下。

（1）聯(lián)動車載CCTV 所需的關(guān)鍵報警信息。當(dāng)綜合監(jiān)控接收到需聯(lián)動車廂內(nèi)CCTV 的報警時（如如車廂火災(zāi)報警、司機室蓋板打開、障礙物觸發(fā)、滅火器移動、乘客緊急對講觸發(fā)等），將聯(lián)動調(diào)取對應(yīng)位置的CCTV攝像頭視頻圖像至OCC 終端，供調(diào)度人員掌握車廂內(nèi)緊急事件情況，以便決定是否采取進一步處置措施使用。

（2）列車司機室內(nèi)司機室顯示屏（即DDU）在OCC調(diào)度席位上的復(fù)現(xiàn)。全自動運行模式下，調(diào)度人員需要全面地掌握列車的實時運行狀況，故DDU 上的所有信息需要在OCC 進行復(fù)現(xiàn)，顯示風(fēng)格應(yīng)盡可能與車載DDU 界面保持一致。

（3）車輛維護數(shù)據(jù)展示。全自動運行模式下，調(diào)度人員除了需要掌握列車的實時運行狀況外，還需要掌握與列車維護相關(guān)的數(shù)據(jù)，以便于更好地向維修部門下發(fā)相應(yīng)的維修工單，縮短故障修復(fù)時間。

以某市軌道交通2 號線為例，一列4 節(jié)編組的C 型車，上述三類數(shù)據(jù)共占用約8000 個信息點。

2.2 控制命令

即綜合監(jiān)控需要向列車下發(fā)某些控制命令，主要包括調(diào)度車載CCTV 攝像頭以及向車載PIS 下發(fā)文本信息兩類。

3 綜合監(jiān)控系統(tǒng)與車輛系統(tǒng)的接口方案

3.1 方案一：少部分關(guān)鍵數(shù)據(jù)通過數(shù)據(jù)接口傳輸至綜合監(jiān)控，全量數(shù)據(jù)通過界面嵌入方式集成至綜合監(jiān)控人機界面

如圖1 所示，司機室監(jiān)控面板在OCC 的復(fù)現(xiàn)、車輛維護數(shù)據(jù)通過界面嵌入的方式，由ISCS 提供界面集成接口，以瀏覽器的形式顯示車輛相應(yīng)數(shù)據(jù)的頁面，即這部分?jǐn)?shù)據(jù)不通過接口傳輸給綜合監(jiān)控系統(tǒng)。

圖1 綜合監(jiān)控系統(tǒng)與車輛接口方案一示意圖（車輛直接接口）

如圖2 所示，車廂CCTV 聯(lián)動信息（如車廂火災(zāi)報警、司機室蓋板打開、障礙物觸發(fā)、滅火器移動、乘客緊急對講觸發(fā)等）、通過車輛-PIS-ISCS 三方接口實現(xiàn)，上述數(shù)據(jù)需通過此三方接口傳輸給綜合監(jiān)控，由綜合監(jiān)控進行相應(yīng)的展示。

圖2 綜合監(jiān)控系統(tǒng)與車輛接口方案一示意圖（PIS 轉(zhuǎn)發(fā)接口）

采用本方案時，車輛與綜合監(jiān)控的接口功能如表1所示。

表1 綜合監(jiān)控系統(tǒng)與車輛接口方案一接口功能表

3.2 方案二：綜合監(jiān)控在地面接收車輛全量信息，自行開發(fā)所有界面

如圖3 所示，需在綜合監(jiān)控中展示的所有車輛相關(guān)數(shù)據(jù)均通過車輛專業(yè)在控制中心設(shè)置的地面服務(wù)器落地，并傳輸給綜合監(jiān)控系統(tǒng)，包括車輛運行狀態(tài)、車載設(shè)備工作狀態(tài)、故障報警信息、故障報警處置流程信息、車輛自檢信息、司控臺儀器儀表按鈕指示燈信息等。

圖3 綜合監(jiān)控系統(tǒng)與車輛接口方案二示意圖

采用本方案時，車輛與綜合監(jiān)控的接口功能如表2所示。

表2 綜合監(jiān)控系統(tǒng)與車輛接口方案二接口功能表

3.3 方案三：綜合監(jiān)控在列車上部署車載綜合監(jiān)控系統(tǒng)（TISCS），通過TISCS 與列車完成數(shù)據(jù)交互

如圖4 所示，該方案通過TISCS 實現(xiàn)車輛數(shù)據(jù)的采集與轉(zhuǎn)發(fā)，車載功能作為ISCS 的一部分，集成在ISCS 內(nèi)。TISCS 主要由車頭/尾各1 臺車載ISCS 服務(wù)器、車載交換機、中繼器等設(shè)備組成。車載ISCS 服務(wù)器與TCMS、車載PIS、車載CCTV 等進行通訊，實現(xiàn)以下功能：（1）建立ISCS 與TCMS 的通信連接（MVB 接口），實現(xiàn)車輛運行信息上傳。（2）建立ISCS 與車載CCTV 的通信連接（以太網(wǎng)接口），實現(xiàn)ISCS 對車載CCTV 實時圖像/錄像調(diào)用，在應(yīng)急情況下，調(diào)用車載CCTV 選取的應(yīng)急視頻。（3）建立ISCS 與車載PIS 的通信連接（以太網(wǎng)接口），實現(xiàn)ISCS 向車載PIS 轉(zhuǎn)發(fā)OCC 下發(fā)的文字信息，與車載CCTV 共享接口物理鏈路。（4）建立ISCS 與車輛運行信息系統(tǒng)的通信鏈接（以太網(wǎng)接口），按照約定的格式，實現(xiàn)車輛維護數(shù)據(jù)的上傳與接收。

圖4 綜合監(jiān)控系統(tǒng)與車輛接口方案三示意圖

兩套TISCS 服務(wù)器熱備冗余，正常情況下均處于激活狀態(tài)，且由主端（可定義）承載業(yè)務(wù)。當(dāng)主端故障時，從端自動獲得承載業(yè)務(wù)權(quán)限。

采用本方案時，車輛與綜合監(jiān)控的接口功能如表3所示。

表3 綜合監(jiān)控系統(tǒng)與車輛接口方案三接口功能表

4 方案比較

方案一：具有車輛與綜合監(jiān)控交互數(shù)據(jù)量少，僅需傳輸部分關(guān)鍵報警數(shù)據(jù)并在人機界面中進行展示，而全量數(shù)據(jù)仍由車輛專業(yè)自身處理，通過界面嵌入的方式實現(xiàn)在一個綜合監(jiān)控工作站上展示不同業(yè)務(wù)需求的數(shù)據(jù)，對于綜合監(jiān)控集成商的開發(fā)要求較低，適用于工程經(jīng)驗較少，但工程開通節(jié)點緊迫的線路。此方案的弊端也相當(dāng)明顯，綜合監(jiān)控僅接入少部分車輛數(shù)據(jù)，不利于系統(tǒng)集成范圍的擴展，后續(xù)若需要在綜合監(jiān)控的基礎(chǔ)上進一步進行開發(fā)數(shù)據(jù)挖掘等智能化深度功能時，需要調(diào)整接口；此外，當(dāng)調(diào)度員需要獲知詳細車輛信息時，需要另行點擊頁面查閱，影響操作便捷性。

方案二：在方案一的基礎(chǔ)上，加強了全自動運行模式下對車輛的深度管控，有助于中央調(diào)度員實時知曉當(dāng)前全線車輛狀態(tài)，通過綜合分析、場景聯(lián)動、輔助決策等功能降低調(diào)度管控難度。尤其是應(yīng)急和故障場景下，使中心調(diào)度員可以及時獲取全部車輛相關(guān)信息，通過可靠的輔助決策和高效的聯(lián)動功能，提高車輛調(diào)度的管控效率和質(zhì)量。此方案需要綜合監(jiān)控集成商具有豐富的車輛專業(yè)知識，且數(shù)據(jù)點位的增多將對系統(tǒng)平臺的穩(wěn)定性、可靠性提出更高的要求，開發(fā)周期較方案一也更長。

方案三：通過在列車上直接部署TISCS，在TISCS架構(gòu)下，整個綜合監(jiān)控除了具有方案二的優(yōu)勢外，還可通過TISCS 實現(xiàn)對車地傳輸?shù)臄?shù)據(jù)內(nèi)容統(tǒng)一整合管理、帶寬控制等功能，每一列車對于綜合監(jiān)控來說都可看作一個移動的車站，車輛數(shù)據(jù)與綜合監(jiān)控系統(tǒng)的接入可靠性更高。但此方案需要在列車上部署綜合監(jiān)控設(shè)備并組建TISCS 網(wǎng)絡(luò)，對綜合監(jiān)控系統(tǒng)集成商的能力要求更高，接口數(shù)量顯著增多。

綜合比較，方案二和方案三均接入了全量的車輛信息，都可根據(jù)用戶需求對非行車相關(guān)設(shè)備進行監(jiān)控，完成車載設(shè)備監(jiān)控、車廂監(jiān)視、乘客溝通、應(yīng)急指揮功能；也可統(tǒng)一調(diào)度員工作站操作方式、界面風(fēng)格，方便調(diào)度使用，均可作為未來全自動運行線路車輛與綜合監(jiān)控的接口方案。相比較而言，方案三應(yīng)用案例較少，對綜合監(jiān)控集成商與車輛供應(yīng)商的接口配合要求最高，對業(yè)主的協(xié)調(diào)工作量也較大，是否選擇該方案取決于建設(shè)方對綜合監(jiān)控的定位以及潛在供應(yīng)商的能力。

5 結(jié)語

全自動運行是軌道交通未來的主流發(fā)展趨勢，采用此模式時，綜合監(jiān)控對車輛的監(jiān)控需求明顯高于非全自動線路，目前，各個城市的不同線路針對綜合監(jiān)控對車輛的監(jiān)控方案各有千秋。通過對比分析，可以得出方案二和方案三均可滿足全自動運行的調(diào)度需求，可作為各地建設(shè)全自動運行線路時的備選方案使用。