季 高 張 峰 張士文

（上海交通大學(xué)電子信息與電氣工程學(xué)院，200240，上?！蔚谝蛔髡?，碩士研究生）

隨著現(xiàn)代城市軌道交通技術(shù)的不斷發(fā)展，列車上設(shè)備的種類越來越豐富，集成度越來越高，列車內(nèi)部通信的信息量也在不斷增大。IEC 61375-1標(biāo)準(zhǔn)［1］將列車通信網(wǎng)絡(luò)（TCN）分為兩個(gè)層次：上層為絞線式車輛總線（WTB），用于連接編組內(nèi)的各節(jié)車輛，實(shí)現(xiàn)列車級(jí)通信；下層為多功能車輛總線（MVB），用于連接車廂內(nèi)固定設(shè)備，實(shí)現(xiàn)車輛內(nèi)通信［2］。在城市軌道交通環(huán)境下，相較于其他的通用現(xiàn)場總線，MVB在實(shí)時(shí)性、可靠性、可管理性、介質(zhì)訪問控制方法、尋址方式及通信服務(wù)種類等方面具有一定優(yōu)勢(shì)［3］。

MVB上的數(shù)據(jù)包含各MVB設(shè)備與主控設(shè)備之間的通信數(shù)據(jù)，這些數(shù)據(jù)對(duì)監(jiān)測列車運(yùn)行狀態(tài)、對(duì)故障的實(shí)時(shí)處理有很重要的意義。目前新投入運(yùn)行的列車大都自帶數(shù)據(jù)監(jiān)測系統(tǒng)，可以將MVB上的數(shù)據(jù)實(shí)時(shí)上傳到遠(yuǎn)程數(shù)據(jù)庫；但是在舊款列車上，沒有相關(guān)的數(shù)據(jù)監(jiān)測系統(tǒng)。本文建立了一套針對(duì)舊款列車的遠(yuǎn)程MVB數(shù)據(jù)監(jiān)測系統(tǒng)，實(shí)現(xiàn)地鐵車輛關(guān)鍵數(shù)據(jù)的實(shí)時(shí)監(jiān)測和遠(yuǎn)程數(shù)據(jù)庫存儲(chǔ)。

1 系統(tǒng)整體設(shè)計(jì)

遠(yuǎn)程MVB數(shù)據(jù)監(jiān)測系統(tǒng)需要實(shí)現(xiàn)MVB上主從幀的解碼及上傳，根據(jù)設(shè)備信息定義文件解析出對(duì)應(yīng)MVB設(shè)備的運(yùn)行狀態(tài)，并在遠(yuǎn)程監(jiān)測平臺(tái)上實(shí)現(xiàn)數(shù)據(jù)的儲(chǔ)存及實(shí)時(shí)顯示。該系統(tǒng)按功能主要分為解碼系統(tǒng)、傳輸系統(tǒng)和監(jiān)測系統(tǒng)3個(gè)部分。系統(tǒng)的結(jié)構(gòu)框圖如圖1所示。

圖1 遠(yuǎn)程MVB數(shù)據(jù)監(jiān)測系統(tǒng)結(jié)構(gòu)框圖

解碼系統(tǒng)需要快速讀取MVB上的主從幀信息，因此采用FPGA（現(xiàn)場可編程門陣列）來實(shí)現(xiàn)，所選用的型號(hào)為EP4CE10F17C8。結(jié)合此芯片強(qiáng)大的數(shù)字電路邏輯資源，本文定制了一套MVB解碼及傳輸算法，實(shí)現(xiàn)了對(duì)MVB上數(shù)據(jù)信號(hào)的實(shí)時(shí)解碼；并結(jié)合SRAM（靜態(tài)隨機(jī)存取存儲(chǔ)器）進(jìn)行解碼信息的緩存，在緩存數(shù)據(jù)達(dá)到一定量時(shí)，通過SPI（同步串行外設(shè)接口）從機(jī)模塊實(shí)現(xiàn)數(shù)據(jù)導(dǎo)出到傳輸系統(tǒng)。

傳輸系統(tǒng)實(shí)現(xiàn)了SPI主機(jī)功能，從解碼系統(tǒng)獲取解碼信息，并通過Wi-Fi將解碼信息傳輸?shù)竭h(yuǎn)程服務(wù)器上。傳輸系統(tǒng)對(duì)可靠性、實(shí)時(shí)性有著較高的要求。本文中的傳輸系統(tǒng)是基于樹莓派3B開發(fā)板實(shí)現(xiàn)的。

監(jiān)測系統(tǒng)需要搭建數(shù)據(jù)庫來儲(chǔ)存MVB解碼數(shù)據(jù)，并通過Web服務(wù)器來實(shí)現(xiàn)人機(jī)交互獲取數(shù)據(jù)。用戶可以使用瀏覽器登錄網(wǎng)頁查看當(dāng)前和歷史MVB數(shù)據(jù)，為故障原因分析提供一定的依據(jù)。本文中的監(jiān)測系統(tǒng)數(shù)據(jù)庫采用的是Mysql，Web框架選用的是基于Python的Django，能夠較好地完成顯示功能，并為日后的功能拓展奠定基礎(chǔ)。

2 解碼系統(tǒng)設(shè)計(jì)

2.1MVB協(xié)議及幀格式

MVB上的數(shù)據(jù)傳輸速率為1.5 Mbit/s，采用曼徹斯特編碼，即通過電氣電平的高低變化來對(duì)“0”“1”信號(hào)進(jìn)行編碼，因此編碼后MVB上的波特率為3 Mbaud［5］。

MVB上的數(shù)據(jù)類型主要有兩種：一種為主幀，由MVB主設(shè)備發(fā)送，用以依次輪詢各從設(shè)備的運(yùn)行狀態(tài)；另一種為從幀，由從設(shè)備根據(jù)主幀內(nèi)容響應(yīng)發(fā)出，包含對(duì)應(yīng)設(shè)備的狀態(tài)信息［1］。MVB協(xié)議幀格式如圖2所示。

圖2 MVB協(xié)議幀格式

主幀和從幀各自具有固定的結(jié)構(gòu)。主幀由主幀起始分界符、F碼、地址、CRC（循環(huán)冗余校驗(yàn)）和終止分界符組成。其中，F(xiàn)碼限定了對(duì)應(yīng)從幀的數(shù)據(jù)位數(shù)，地址為對(duì)應(yīng)從設(shè)備的邏輯地址。從幀由從幀起始分界符、數(shù)據(jù)、CRC和終止分界符組成。其中，數(shù)據(jù)位數(shù)根據(jù)F碼來確定，數(shù)據(jù)內(nèi)容根據(jù)設(shè)備信息定義文件來解析。

2.2MVB解碼器設(shè)計(jì)

MVB解碼器是解碼系統(tǒng)的核心模塊，負(fù)責(zé)根據(jù)MVB協(xié)議將總線數(shù)據(jù)解碼并送入緩存區(qū)，其總體設(shè)計(jì)結(jié)構(gòu)框圖如圖3所示。解碼器包含主從幀幀頭識(shí)別、幀尾識(shí)別、曼徹斯特解碼、CRC校驗(yàn)和定時(shí)器等功能模塊，通過解碼控制單元來實(shí)現(xiàn)各功能模塊的使能、復(fù)位，控制解碼的流程［4］。數(shù)據(jù)輸入為經(jīng)MAX3292芯片電平轉(zhuǎn)換后的MVB數(shù)據(jù)信號(hào)；時(shí)鐘輸入為經(jīng)PLL（鎖相環(huán)）倍頻后產(chǎn)生的時(shí)鐘信號(hào)，解碼器內(nèi)所有模塊共用此時(shí)鐘信號(hào)。

圖3 MVB解碼器結(jié)構(gòu)框圖

幀頭識(shí)別和幀尾識(shí)別模塊采用有限狀態(tài)機(jī)實(shí)現(xiàn)，識(shí)別成功時(shí)會(huì)通知解碼流程控制單元，使其使能或復(fù)位曼切斯特解碼模塊。定時(shí)器模塊主要用于處理檢測出主幀但無從幀回復(fù)情況，設(shè)定一個(gè)超時(shí)時(shí)間，檢測在規(guī)定時(shí)間內(nèi)是否能識(shí)別到從幀幀頭?？偩€異常管理模塊用來處理實(shí)際中可能出現(xiàn)的各種解碼異常情況，包括CRC校驗(yàn)錯(cuò)誤、幀長度錯(cuò)誤、未定義F碼等，通過此模塊來進(jìn)行異常匯總并反饋給解碼控制單元。圖4為幀頭識(shí)別和幀尾識(shí)別模塊工作流程示意圖。

2.3 解碼信息緩存及輸出

由于MVB上的幀與幀之間的傳輸存在空隙，實(shí)際中解碼下來的數(shù)據(jù)量不高于100 kB/s。為了及時(shí)將數(shù)據(jù)上傳給樹莓派，本文采取SPI通信方式來進(jìn)行數(shù)據(jù)傳輸。SPI總線支持全雙工通信，傳輸速率可達(dá)到30 Mbit/s以上，足夠滿足系統(tǒng)需求。本文選取的傳輸速率為5 Mbit/s。

MVB上的幀長度不固定，解碼信息必須經(jīng)過緩存后再發(fā)出。本文以外置SRAM作為緩存器，芯片型號(hào)為IS61WV5128BLL，具有512 kB容量，足夠滿足設(shè)計(jì)要求。

解碼系統(tǒng)的緩存及輸出結(jié)構(gòu)框圖如圖5所示。SRAM寫入模塊將接收的串行解碼數(shù)據(jù)轉(zhuǎn)換為并行格式，并生成其在SRAM中的儲(chǔ)存地址，在地址達(dá)到65 536或65 536的整數(shù)倍時(shí)，生成讀信號(hào)給SRAM讀取模塊；SRAM讀取模塊得到讀取信號(hào)后生成目標(biāo)數(shù)據(jù)的SRAM地址，獲得數(shù)據(jù)并輸出給SPI從機(jī)模塊；SRAM控制模塊主要用于處理同時(shí)有讀寫請(qǐng)求的情況，生成SRAM儲(chǔ)存器的控制信號(hào)，保證系統(tǒng)可靠性；SPI從機(jī)模塊負(fù)責(zé)從SRAM讀取模塊獲取數(shù)據(jù)并發(fā)送給傳輸系統(tǒng)。

圖4 幀頭識(shí)別和幀尾識(shí)別模塊工作流程示意圖

圖5 解碼數(shù)據(jù)緩存及輸出結(jié)構(gòu)框圖

3 傳輸系統(tǒng)設(shè)計(jì)

基于地鐵中復(fù)雜的工作環(huán)境，如何將解碼信息有效無誤地傳輸?shù)竭h(yuǎn)程服務(wù)器上是一個(gè)較大的難題。本文傳輸系統(tǒng)采用樹莓派開發(fā)板，此開發(fā)板運(yùn)行Linux操作系統(tǒng)，搭載1.2 GHz的64 bit四核處理器，并且自帶無線網(wǎng)卡模塊，GPIO（通用型輸入/輸出端口）接口豐富，能夠較好地滿足功能需求［6］。依托地鐵線路上搭建的Wi-Fi網(wǎng)絡(luò)來進(jìn)行數(shù)據(jù)上傳，在網(wǎng)絡(luò)不可達(dá)時(shí)將數(shù)據(jù)暫時(shí)儲(chǔ)存在本地，確保解碼數(shù)據(jù)不丟失。

樹莓派首先需要完成與FPGA板之間的通信，完整地獲取解碼信息。本文考慮到通信速率和數(shù)據(jù)處理難度等因素，選取以樹莓派作為SPI主機(jī)、以FPGA板作為SPI從機(jī)的方式來進(jìn)行數(shù)據(jù)傳輸，圖6為樹莓派和FPGA板之間的連線圖。樹莓派通過rasp-config配置文件啟用SPI設(shè)備，并通過WiringPi庫函數(shù)來實(shí)現(xiàn)GPIO接口和SPI接口的控制。在傳輸過程中，樹莓派通過指定GPIO接口獲取傳輸請(qǐng)求，得到請(qǐng)求后回復(fù)同意傳輸信號(hào)；然后控制SPI接口接收固定大小數(shù)據(jù)并存入緩存區(qū)；接著將緩存的數(shù)據(jù)寫入文件，文件名以系統(tǒng)時(shí)間命名。

圖6 樹莓派與FPGA板連線圖

由于地鐵列車連續(xù)不間斷運(yùn)行，且MVB總線上數(shù)據(jù)較多，因此需要傳輸?shù)臄?shù)據(jù)量會(huì)比較大，一天下來解碼的數(shù)據(jù)會(huì)達(dá)到數(shù)GB以上。為了減少對(duì)地鐵線路Wi-Fi帶寬的占用，很有必要在上傳數(shù)據(jù)前對(duì)數(shù)據(jù)進(jìn)行壓縮操作。由于MVB幀具有重復(fù)數(shù)據(jù)多的特點(diǎn)，通過使用bzip2軟件壓縮，64 kB的原始解碼數(shù)據(jù)壓縮后通常只有5 kB左右。

考慮到實(shí)際需要連續(xù)上傳大量數(shù)據(jù)，地鐵Wi-Fi網(wǎng)絡(luò)又存在不穩(wěn)定的情況，因此本系統(tǒng)選用FTP（文件傳輸協(xié)議）來實(shí)現(xiàn)與遠(yuǎn)程服務(wù)器的數(shù)據(jù)傳輸。樹莓派上需要安裝vsftpd軟件，在開機(jī)后自動(dòng)啟動(dòng)FTP服務(wù)連接遠(yuǎn)程服務(wù)器，同時(shí)實(shí)時(shí)監(jiān)控指定文件夾下是否有待傳輸文件，如存在即嘗試傳輸，傳輸成功后刪除此本地文件。圖7為傳輸系統(tǒng)的任務(wù)流程圖。

圖7 傳輸系統(tǒng)任務(wù)流程圖

4 監(jiān)測系統(tǒng)設(shè)計(jì)

為了實(shí)現(xiàn)對(duì)MVB上數(shù)據(jù)信號(hào)的遠(yuǎn)程監(jiān)測，本文設(shè)計(jì)了一套基于Django框架的Web應(yīng)用，并將其部署在Linux的Apache服務(wù)器上。Django是一種遵循MVC（Model View Controller）開發(fā)模式的框架［7］，其模型組織結(jié)構(gòu)如圖8所示。根據(jù)其框架，Model.py實(shí)現(xiàn)數(shù)據(jù)庫的創(chuàng)建、數(shù)據(jù)的寫入，以及控制器與數(shù)據(jù)庫的連接；Templates文件夾下存放與前端相關(guān)的HTML、CSS、JavaScript等文件，定義網(wǎng)頁界面和結(jié)構(gòu)；控制器中的Urls.py指定項(xiàng)目中各種類的調(diào)用情況；View.py中定義各種處理函數(shù)包括數(shù)據(jù)的解析、刪除等。

圖8 Django模型組織結(jié)構(gòu)圖

實(shí)現(xiàn)網(wǎng)頁顯示數(shù)據(jù)的基礎(chǔ)是需要將傳輸系統(tǒng)上傳的數(shù)據(jù)進(jìn)行歸類解析。上傳數(shù)據(jù)的提取與解析流程圖如圖9所示。對(duì)主從幀對(duì)中的數(shù)據(jù)是否正常的判斷是通過幀格式以及CRC校驗(yàn)來實(shí)現(xiàn)的。

根據(jù)系統(tǒng)設(shè)計(jì)，在網(wǎng)絡(luò)通信順暢的情況下，地鐵列車MVB采集系統(tǒng)每次傳輸64 kB的MVB解碼數(shù)據(jù)到遠(yuǎn)程服務(wù)器，傳輸時(shí)間間隔為1 s左右。對(duì)FTP文件夾下文件的檢索通過使用django-crontab插件執(zhí)行定時(shí)任務(wù)的方式來完成。解析得到主從幀對(duì)后，服務(wù)器會(huì)以時(shí)間、車輛號(hào)、主幀號(hào)等為字段將數(shù)據(jù)存入數(shù)據(jù)庫。用戶可通過訪問網(wǎng)頁查詢數(shù)據(jù)庫得到解析后的MVB數(shù)據(jù)，通過數(shù)據(jù)的導(dǎo)出可以協(xié)助進(jìn)行故障情況分析以及故障預(yù)防。

圖9 數(shù)據(jù)提取與解析流程圖

5 系統(tǒng)功能測試

EDCU（車門控制單元）是一種典型的MVB設(shè)備，根據(jù)車輛的控制信號(hào)來執(zhí)行車門的開關(guān)動(dòng)作［8］。EDCU會(huì)收集自身以及外圍電路的運(yùn)行狀態(tài)信息，在接收到相應(yīng)主幀信號(hào)時(shí)，會(huì)將這些信息回復(fù)到MVB總線上。車門半實(shí)物仿真系統(tǒng)是基于Labview軟件和硬件電路搭建的仿真系統(tǒng)，通過模擬車門正常工作狀態(tài)給EDCU提供各種輸入信號(hào)，根據(jù)EDCU的輸出是否正常來判斷其性能。本文利用EDCU和車門半實(shí)物仿真系統(tǒng)進(jìn)行了MVB遠(yuǎn)程監(jiān)測系統(tǒng)的測試，測試結(jié)構(gòu)框圖如圖10所示。

本測試主要關(guān)注EDCU回復(fù)的關(guān)于門控單元狀態(tài)信息的幀，此幀問詢周期為128 ms，長度為256 bit。經(jīng)過分析MVB設(shè)備定義表，可知此幀僅有前2個(gè)字節(jié)即前16 bit表示了當(dāng)前門控器的狀態(tài)信息，因此在本測試中只需關(guān)注此從幀的前16 bit。圖11為監(jiān)測網(wǎng)頁查詢對(duì)應(yīng)端口號(hào)結(jié)果。通過測試系統(tǒng)對(duì)車門控制單元進(jìn)行開關(guān)門仿真，觀察到從幀的前16 bit也隨著測試過程產(chǎn)生變化。0x0F00表示門控器處于在開門過程中，0x8F00表示門控器已經(jīng)開門到位，數(shù)值與MVB設(shè)備定義表中的定義相符。

圖10 MVB遠(yuǎn)程監(jiān)測系統(tǒng)測試結(jié)構(gòu)框圖

圖11 MVB遠(yuǎn)程監(jiān)測系統(tǒng)查詢結(jié)果

6 結(jié)語

本文設(shè)計(jì)了一套基于MVB總線的地鐵車輛關(guān)鍵數(shù)據(jù)遠(yuǎn)程監(jiān)測系統(tǒng)。利用FPGA在高速信號(hào)處理中的優(yōu)勢(shì)設(shè)計(jì)了MVB解碼系統(tǒng)，結(jié)合樹莓派豐富的拓展接口和高效的處理能力實(shí)現(xiàn)了解碼數(shù)據(jù)的上傳，搭建了遠(yuǎn)程Web服務(wù)器來進(jìn)行人機(jī)交互和數(shù)據(jù)顯示，實(shí)現(xiàn)了低成本、高拓展性的展示系統(tǒng)。利用現(xiàn)有的車門半實(shí)物仿真平臺(tái)和EDCU進(jìn)行了系統(tǒng)功能的測試，驗(yàn)證了整個(gè)數(shù)據(jù)流程的完整性以及可行性。