李凱凱
深圳市地鐵集團有限公司 運營總部 廣東 深圳 518055
地鐵乘客資訊(信息)系統簡稱PIS系統是重要的地鐵通信系統之一,它的主要功能是通過設置在車站和列車上的各種顯示終端,為乘客提供以運營信息為主、商業廣告為輔的多媒體綜合信息顯示平臺。另外在緊急情況下,乘客資訊還可以迅速、直觀、優先播放緊急疏散和防災等文本和圖像信息,以便預先告之和引導乘客,起到輔助防災、救災的作用。因此PIS系統緊急信息的正常顯示功能對突發事件的應急處置效率十分重要。
自2017年以來,在全國上下各層級對消防安全、反恐等工作等十分重視,因此地鐵作為公共交通運營單位,提供在突發事件方面的應急處置效率顯得尤為重要[1]。在2017年,深圳地鐵3號線PIS系統配合深圳市公安局公交分局的各系統消防聯動功能測試中,出現了緊急信息聯動顯示不穩定、不響應等問題,隨后我們組織技術人員一起對此問題進行了研究攻關,后續本文也將重點將圍繞如何提高3號線PIS系統緊急信息聯動顯示的穩定性進行論述,以介紹本次攻關的成果。
緊急信息顯示是指在發生突發事件時,在各地鐵車站PIS系統終端顯示屏進行推送顯示的信息,能對乘客提高提醒告知作用的媒體信息。目前3號線PIS系統的緊急信息顯示功能的觸發方式,主要可以分為人工觸發和聯動觸發兩種。
人工觸發是指可以通過各類操作人員操作臺進行觸發,可以進行操作的人員主要有調度、車站人員、維護人員等。操作人員可以操作PIS系統網管工作站、后備PIS工作站、AIS工作站等操作終端進行顯示。
就3號線PIS系統而言,聯動觸發是通過PIS系統與3號線自動化集成系統(簡稱AIS系統)進行接口連接,可以實現當觸發FAS系統、AIS工作站的聯動模式時,由FAS系統、AIS工作站自動觸發PIS系統顯示緊急信息。
關于3號線PIS系統緊急信息的聯動顯示,簡而言之就是通過與自動化集成系統AIS系統的接口,實現通過AIS系統觸發PIS系統顯示緊急信息的功能。
3號線PIS系統是通過TCP/IP與自動化集成系統的前置機進行連接,在雙方通過MOBUS接口協議的方式進行通信,在PIS系統側的每個車站服務器安裝了ISCSInterface接口軟件進行接收和解析信息。當某個車站發生火災等緊急情況并觸發車站聯動模式時,AIS系統的前置機會通過接口軟件向PIS系統的車站服務器發生顯示進行信息的指令,由PIS車站服務接收后進行解析,解析出需要顯示的區域、顯示的方式、顯示內容等信息,再轉發至對應的PDP或LED控制器,由控制器觸發播表中的緊急模塊,推送緊急信息進行顯示。
3號線緊急信息顯示的通信接口采用MOBUS接口協議,Modbus協議是目前廣泛應用于電子控制器上的一種通用語言。它可以使控制器相互之間、控制器經由網絡和其他設備之間可以通信。此協議的報文格式由報頭+功能碼+數據三部分組成。報頭的信息主要包含AIS系統前置機和PIS車站服務器之間的接收和應答方式的信息,即規定是讀取還是發生數據。功能碼用于定于寄存器地址和類型,數據則代表需要傳送的數據。
在AIS前置機與PIS車站服務器的接口之間,一共只有3個寄存器起作用來控制緊急信息的顯示,分別是在對應點表中的第36位、39位和40位寄存器。第36位寄存器定義為是否選擇向進行全站信息發送。第39位定義為信息的優先級和顯示模式,即正常或緊急模式。在PIS系統車站服務器中,對應的緊急模式的解析是將信息優先最上層顯示,并進行全屏方式進行顯示。第40為寄存器定義為要發送的緊急信息ID,將對應的ID號發送至PIS車站服務器,有車站服務器選擇對應ID的信息進行顯示,且寄存器定義為開關量信號,即以0和1來分別判別不同的模式。下圖3即為3號線AIS系統與PIS系統接口的寄存器點表。
當車站發送緊急情況,并由車站值班員在AIS工作站上確認啟動聯動模式后,此時AIS系統前置機會向PIS系統車站服務器依次發送這3個寄存器的信息,依次是選擇為全站顯示方式、顯示模式為緊急模式、顯示信息ID號為20的信息,由此當PIS車站服務器依次接收到此信息后,解析并轉發至PDP/LED控制器,在對應的播表軟件上實現進行信息的顯示。
目前3號線相關設備維護人員對PIS系統的緊急信息聯動顯示的測試中,發現實際運行過程中,當通過AIS聯動觸發顯示緊急信息的時候不時會出現PIS系統緊急信息顯示不成功的問題[2]。而且此類問題偶發性高,具體即表現為設備顯示不出問題。以單個站點為例,若進行此項聯動顯示多次測試,顯示成功率最高僅為85%,某些站點的顯示成功率也僅為50%左右。在2017年3號線配合公交分局開展消防聯動功能測試工作中,此問題暴露尤為突出,因此此問題急需研究解決。
進行深入分析,我們發現主要原因出現在PIS系統與AIS系統接口信息上。具體表現為當聯動模式觸發后,雖然從AIS前置機上依次按照順序將信息進行發送,但是當PIS車站服務接收解析是會出現信息顛倒,順序出錯的問題,由于PIS系統的信息顯示機制已經設定一定要按照全站顯示方式、顯示模式、顯示信息ID號這3個信息進行接收,方能送達顯示終端正常顯示,因此接收信息的順序問題,導致了本聯動顯示功能的問題。經統計,緊急信息在聯動顯示不成功的案例中,此類問題的故障率高達到90%左右,5%為軟件權限設置不合理問題,5%為PIS系統運行軟件崩潰無法顯示的問題。因此我們必須找到以上故障原因的解決方案,方能解決PIS系統緊急信息聯動顯示不穩定的問題。
經過對比分析,我們發現大多數故障AIS前置機是有將信息依次按照順序將信息進行發送,但是到接收側的PIS系統就會出現接收信息順序出錯的問題。從接口協議上分析,并沒有進行順序轉變的控制,AIS前置機依次發送,PIS車站服務器也依次接收。然而當在AIS系統前置機將進行按照全站顯示方式、顯示緊急模式、顯示信息ID號的順序進行發送后,到PIS側接收有時會先接收到顯示信息ID號,在接收到全站顯示方式、顯示緊急模式的內容,而且此類問題具有偶發性,時而正常時而異常。
對此我們的第一種解決方案是在每個寄存器的信息發送程序之間加延時子程序,AIS系統的前置機即在發送第一個寄存器信息后,程序上延時后在發送第二個寄存器信息,依次類推完成三個寄存器信息的順序發送。經過測試,各寄存器信息發送之間加入延時,可以基本解決順序發送的問題。
雖然在我們的第一種方案中基本可以解決信息接收順序不穩定的問題,但是其也存在缺陷,即是延長整體程序的總執行時間。因為我們加入延時的程序為AIS系統中執行的一段子程序,目前3號線AIS系統其他所有程序的執行都需要先調用這個子程序,用于判別是否啟動緊急聯動模式。若反復調用該子程序,那么加入延時就會使AIS系統整體的程序執行時間過長,導致影響AIS系統其他功能的正常運行。如在3號線加大行車密度時,導致列車的報站信息計算時間過長,影響報站顯示功能。
為了解決這個問題,我們從3號線的聯動緊急信息內容入手進行分析。我們分析發現3號線從AIS系統的緊急信息聯動顯示無論在車站火災、車站疏散等模式時有有以下特點[3]:①是每次的緊急信息顯示都是向全站進行推送顯示;②每次都是全屏覆蓋顯示固定的文字信息。因此我們完全可以用一個寄存器實現攜帶所有的信息,以解決信息接收順序的問題。隨后我們通過修改AIS系統與PIS系統之間接口軟件,定義一個寄存器的標志位,通過這個標志位置0和1來區分不同的模式,當車站發送火災、恐怖事件等緊急情況且觸發聯動模式時,將此標志為置1,表示已經觸發緊急模式,當PIS車站服務器接收到1的標志信息后,將預置的固定緊急信息進行全站全屏信息推送顯示。此方案PIS系統與AIS系統雙方要修改軟件的部分內容較少,較容易實現。當然其也有缺點,即不能選擇發送信息的內容和模式為全屏信息還是滾動信息顯示。但從3號線目前緊急信息顯示內容和方式的實際情況來看,此方案是當前最能夠解決信息接收順序問題的最佳方案。經過測試成功率達100%。
在緊急信息聯動出現不成功的故障中,我們還分析出有5%的故障為軟件權限設置不合理問題而導致的問題,
我們發現目前權限設置的情況是將OCC調度的PIS工作站權限設置為最高,AIS工作站其次,當出現PDP屏發送滾動條信息,由OCC信息調度下發的滾動條緊急信息是,由于其權限大于了火災模式的權限,當車站發生緊急情況需啟動聯動模式時,此時車站的緊急信息由于權限問題是無法覆蓋OCC調度發送的信息,因此在軟件上就會出現發送錯誤的代碼。

表1 修改前權限設置(數值越大代表權限越高)
我們要研究解決權限優先級問題的方案,我們也有從前面優化發送順序的兩種方案入手。由于第一種方案只是增加了延時,并沒有改變緊急信息聯動觸發的方式,因此從根本上也無法解決權限問題。第二種方案可以將緊急信息的聯動觸發顯示方式獨立設置,設置單個寄存器進行觸發,因此可以從權限上進行優化,因此我們對權限做了以下調整。

表2 優化修改后權限設置(數值越大代表權限越高)
通過調整權限值,我們進行權限優化后,使得緊急聯動觸發方式為本站的較高權限,此權限高于OCC工作站的權限,可以解決無法覆蓋OCC信息的問題,因為當車站發送緊急情況時,當站的緊急信息時尤為重要的。另外,將維護人員的權限設置為最低至最高可調,可以實現在不同情況下含故障情況時的維護使用,保證不會出現顯示信息無法撤銷的問題。因此,我們通過實施方案二后再進行權限的修改,基本上就可以解決以上緊急信息聯動顯示的不穩定問題。
為解決3號線存在的緊急信息顯示問題,可以從前面的論述看到我們開展了大量的研究對比的工作。目前從3號線聯動緊急信息顯示的方式來看,目前優化為采用設置單獨寄存器進行觸發的方式為最佳方案,且配合我們進行的權限優化,基本上是可以解決目前3號線PIS系統存在的緊急信息聯動顯示不穩定的問題。通過對此類問題的攻關,總結出最佳的方案和經驗,這樣也可以為我們后續線路的建設積累豐富經驗。