列車TCMS一體化軟件開發及驗證平臺研究

梅櫻

（中國鐵道科學研究院機車車輛研究所，北京100081）

列車網絡控制系統（Train Control and Management System，TCMS）是現代化智能列車的中樞控制系統，主要實現對列車牽引、制動、輔助、空調、車門等幾乎所有智能電氣設備的綜合協同管理控制，同時還承擔對列車的監視、診斷及故障導向安全等任務[1]。

TCMS是一個涉及多個子系統的復雜綜合系統[2]，其控制軟件的開發和驗證是整個TCMS系統的核心工作，直接影響了其可用性和可靠性。由于開發與測試驗證分屬于軟件生命周期的不同階段，由不同人員獨立執行，因此目前國內外針對TCMS系統的開發[3]和驗證[4]均采用了不同的平臺。然而不同的平臺帶來了很多附加工作，如TCMS集成商需要不同人員維護2個或多個平臺、從開發到驗證需要協調管理不同平臺間復雜的接口等等。而這些附加工作最終也導致了TCMS系統開發和維護成本高、開發和驗證周期長、維護困難等問題。

文中將研究列車TCMS一體化軟件開發及驗證平臺，使TCMS軟件的開發和驗證能在同一平臺上實現。

1 軟件開發及驗證平臺一體化實現策略研究

列車TCMS軟件開發平臺及驗證平臺一體化可定義為：在同一平臺上既能開發TCMS應用軟件，同時也能開發對應用軟件進行驗證的仿真測試軟件。實現列車TCMS軟件開發平臺及驗證平臺的一體化可以通過以下兩種策略：

1）以已有的TCMS軟件開發平臺為基礎，在其之上開發仿真驗證功能。

2）以已有的仿真及驗證軟件為基礎，在其之上實現TCMS軟件開發功能。

1.1 策略1分析

TCMS是一個大型、復雜、高度集成化的系統，其軟件涉及對幾乎整個列車電氣設備的管理及邏輯控制。因此采用一種可視化、模塊化的編程方式[5]對系統的應用軟件進行開發，是對TCMS進行安全、可靠、高效集成的重要保證。

目前國際上幾乎所有TCMS集成商，均具有自主的滿足IEC61131-3[6]標準的軟件開發平臺，如西門子的SIBAS G平臺[7]、龐巴迪的MITRAC平臺等，此外還有一些商業化的模塊化編程的平臺，如CoDeSys[8]、ISaGRAF[9]等。但這些開發平臺都具有如下特點：由于專業性導致其可選范圍小、平臺內部高度封裝而無法改變平臺的執行行為、無法獲取接口信息而導致很難實現平臺的二次開發等。

因此，在已有的TCMS軟件開發平臺或滿足IEC61131-3標準的開發平臺上開發仿真驗證功能將十分困難。

1.2 策略2分析

目前，很多商業化的成熟仿真軟件，如matlab[10]等，它們大部分都具有：支持模塊化編程、外部接口開放、以及支持源碼生成等特點。

在這些平臺上，用戶能夠針對不同的硬件平臺和不同專業的特殊需求進行驅動或服務的二次開發。同時由于軟件支持源碼生成功能，使用戶將開發的應用部署到不同的嵌入式操作系統或硬件平臺上成為可能。

1.3 研究策略

文中將采用策略2對列車TCMS一體化軟件開發及驗證平臺進行研究：首先選取一款適合進行TCMS系統測試驗證的仿真軟件；然后在此軟件基礎上研究實現其作為TCMS軟件開發平臺所需的功能；同時研究實現此軟件作為TCMS軟件驗證平臺所需的功能；最后對上述研究的軟件開發平臺及驗證平臺的一體化實現進行了研究。

2 列車TCMS軟件開發平臺研究

2.1 列車TCMS軟件開發平臺需求

文中選擇了一款商業化仿真軟件，該軟件可支持IEC61131-3的所有編程語言、支持低壓電氣圖及各類編程語言程序的仿真等。由于所選取的仿真軟件為通用軟件，不具備作為TCMS應用軟件開發平臺特性，因此需對該仿真軟件進行二次開發，使其滿足對列車TCMS應用軟件開發的特殊需求。

圖1 列車TCMS軟件開發平臺功能

圖1列出了需對仿真軟件進行二次開發的內容：

功能庫：仿真軟件本身可為用戶提供模塊化編程環境進行應用程序的編寫，但是其本身缺少適用于搭建TCMS應用控制程序的功能模塊，因此需要在仿真軟件中建立所需的基本功能模塊庫，如算法庫、控制庫、邏輯庫、通信庫等；

驅動：仿真軟件本身并不具備任何硬件驅動，為使在本平臺上開發的TCMS應用軟件運行于目標機設備，需針對不同的硬件和功能開發相關驅動，其中包括通信驅動[11]、硬件驅動和診斷驅動[12]。通信驅動是針對列車總線[13]通信網卡的驅動，實現列車總線通信功能，是整個TCMS系統的核心功能；硬件驅動是針對目標機本地硬件的驅動控制，如電源管理、硬件保護、數字量輸入采集、數字量輸出控制等；診斷驅動是針對TCMS故障存儲及維護需求實現的功能。

服務：仿真軟件本身并不具備任何目標機服務，因此需根據TCMS系統特點開發相關功能，其中包括調度服務和人機接口服務。調度服務是針對系統應用、驅動等任務的調度管理和運行監控服務，是TCMS系統正確運行的重要保障；人機接口服務是目標機與上層PC間交互的服務功能，主要滿足TCMS的調試、維護需求。

插件工具：仿真軟件本身不具備變量屬性管理、目標機代碼編譯下載等功能，為使仿真軟件成為產品化的開發平臺，需對其開發相應功能的完整工具鏈，主要包括變量管理工具、配置工具、編譯工具和監控工具。變量管理工具通過仿真軟件的外部接口文件，將應用程序變量與通信及硬件相關變量數據進行屬性關聯；配置工具向用戶提供TCMS診斷配置接口；編譯工具將應用、驅動、服務等源碼按照配置編譯生成系統可執行文件；監控工具通過與開發的人機接口服務相配合，實現行變量監控、程序下載，診斷分析等在線調試功能。

插件工具是仿真軟件和二次開發的驅動、服務等軟件之間的橋梁。它利用仿真軟件的外部接口文件和用戶配置文件，將在仿真軟件中開發應用程序中的變量數據與驅動、服務軟件數據進行交互管理，達到應用程序與底層驅動和服務軟件間的數據相融合和無縫連接。從而使仿真軟件成為一個具有完整工具鏈的、能滿足列車TCMS特定需求的軟件開發平臺。

2.2 列車TCMS軟件開發平臺軟件結構

列車TCMS軟件開發平臺（以下簡稱：開發平臺）的實現，需要驅動、服務等軟件通過插件工具與原仿真軟件進行數據接口。因此，本文采用了分層方法對開發平臺軟件結構進行研究，如圖2所示。

圖2 列車TCMS軟件開發平臺軟件結構

按照各層次間的數據接口關系，本文將開發平臺軟件按從上到下分為三層結構：應用層、操作系統層、硬件/功能驅動層和操作系統層。

應用層為軟件結構頂層，可針對不同TCMS項目需求搭建相關邏輯控制功能，如牽引邏輯控制、制動邏輯控制、門邏輯控制、空調邏輯控制、自動導向安全邏輯等。硬件/功能驅動層為軟件結構中間層，可根據項目配置文件自動生成TCMS硬件/功能驅動，如通信驅動、硬件控制驅動、診斷存儲驅動、系統調度、系統服務等。操作系統層為軟件結構底層，為開發平臺提供了操作系統的底層服務，同時提供了嵌入式操作系統的底層板級支持包BSP，是整個開發平臺與硬件接口的底層支持軟件。

硬件/功能驅動層中的數據交互管理接口是開發平臺的關鍵核心，它將應用與驅動的接口數據通過地址方式進行映射，從而實現應用與驅動間的數據交互。同時，驅動亦通過操作系統層對相應的目標機板卡或介質等硬件進行直接操作，從而完成對硬件的控制，達到開發平臺軟/硬件系統的結合。

圖3 列車TCMS軟件開發平臺實現

2.3 列車TCMS軟件開發平臺實現

本研究的列車TCMS軟件開發平臺實現機制如圖3所示。

由于開發平臺并不針對特定的目標機硬件，因此本文在平臺實現時設計了對硬件信息的處理方式：目標機硬件信息輸入文件。如圖3所示，開發平臺輸入數據文件，文件以一定格式描述了目標機硬件相關信息及列車總線數據相關信息。變量管理工具解析數據文件，并通過仿真軟件的外部接口文件，以一定規則，將應用邏輯中變量與硬件及總線通信相關變量通過地址方式進行關聯，生成變量相關配置文件。配置工具則根據應用邏輯的診斷配置需求，生成診斷相關配置文件。因此，通過這些配置文件生成的通信、硬件、診斷等驅動，具有與應用邏輯相關的數據及地址信息，通過目標機的數據交互管理機制，完成與應用任務的信息交互。

為使開發平臺能夠自動編譯生成目標機可執行代碼，本文在平臺實現時開發了編譯工具，其工作原理如下：編譯工具首先解析項目配置文件，并根據TCMS開發平臺驅動模板自動生成與配置文件相匹配的驅動源碼，然后編譯工具分別將由仿真軟件生成的應用邏輯源碼和驅動源碼，編譯成為可運行于指定目標機硬件和操作系統的可執行代碼，下載到目標機運行。

為使對目標機進行監控及維護，本文在平臺實現時開發了監控工具及與之配套的目標機系統服務程序，如圖3所示。監控工具運行于PC機，系統服務程序以進程方式在目標機上運行。系統服務進程不參與控制，只通過數據交互管理接口將系統變量、運行狀態、診斷數據等通過以太網發送給監控工具進行分析。

TCMS系統的應用邏輯會根據項目需求配置為不同任務，主要包括周期類任務、中斷類任務等。因此本文在平臺實現時針對TCMS各類任務執行特點開發了調度服務。調度服務以任務進程方式對所有任務進行統一調度管理，如圖3所示任務1～任務n。調度服務包括了：調度前任務完整性檢查、任務啟動順序管理、周期類任務超時管理等等。通過調度服務及相關機制保證應用任務運行的實時性和可靠性。

驅動在目標機中以進程方式運行，包括了通信驅動進程、硬件驅動進程、診斷驅動進程等。如圖3所示，驅動進程與應用邏輯任務進程間通過數據交互管理接口交互數據。驅動進程通過數據交互管理接口采集應用任務進程數據進行驅動處理，并將處理數據發送到硬件或列車總線上對TCMS系統進行控制；同時驅動進程采集TCMS系統硬件及列車總線數據，通過數據交互管理接口將相關數據發送到應用任務進程，實現應用邏輯控制。

通過上述對工具、調度、驅動及數據交互管理機制等內容的開發，使所選用仿真軟件成為了一個具有完整工具鏈的、能滿足列車TCMS特定需求的軟件開發平臺。本開發平臺只需通過改變輸入數據文件的相關描述，即可針對不同的目標機硬件，自動生成硬件、通信和診斷相關的驅動，因此具有很好的易用性和適用性。

3 TCMS驗證平臺研究

列車TCMS驗證平臺（以下簡稱：驗證平臺）是為TCMS系統功能測試提供搭建仿真模型環境的軟件平臺。通過驗證平臺可搭建列車控制模型，模擬列車實際運行工況，因此在地面即可完成對TCMS相關功能的驗證的工作，如列車網絡通信協議的驗證、TCMS邏輯控制算法的驗證、TCMS系統性能的驗證和故障診斷策略的驗證等等，從而大大降低系統調試和驗證的成本和周期，增加系統可靠性。

為達到列車TCMS軟件開發和驗證平臺的一體化，兩平臺需采用統一的軟件作為基礎進行開發，因此針對TCMS驗證平臺的開發本文也采用了本文開發平臺所選取的仿真軟件進行研究。

3.1 TCMS驗證平臺仿真模型研究

TCMS主控系統主要與列車上具有總線接口的電氣系統通信，并對這些系統進行整車管理控制。因此，為了模擬TCMS實際運行工況及相關環境，需要對列車主要控制系統及其相關的列車控制電路按照實際功能進行仿真建模，如圖4所示。

圖4 TCMS驗證平臺仿真軟件構架

一般TCMS驗證仿真軟件[14]采用模塊化結構設計，如圖4所示，按照列車控制系統將模型劃分為子系統1～子系統n等模塊，主要包括：TCMS中央控制、牽引、制動、高壓、輔助、門、空調等。這種模塊化的設計既有利于仿真過程中各個子系統的仿真模型的協同開發，分系統調試測試，也便于快速實現仿真模塊的裁剪。

子系統模型由2部分組成：子系統的控制模型、與子系統相關的控制電路模型。在本文研究的驗證平臺中，采用C、ST及FBD等語言搭建控制模型，用于描述控制邏輯、性能及接口；采用低壓電氣圖搭建車輛電路模型，用于描述與子系統相關的車輛電路的開關、設備、連線、性能、行為及接口。

各個子系統的仿真模型，與其他子系統模型具有2類接口：通過列車總線傳輸的數據接口、通過輸入輸出控制的硬線數據接口。在驗證平臺中，所有子系統的列車總線數據和硬線數據，分別通過列車數據管理和硬線數據管理數據庫統一維護。通過2個數據庫，各子系統模型間的控制或反饋信號可實現數據交互，使各子系統的仿真性能相互作用，從而實現對列車實際工況的模擬，達到可對TCMS進行驗證的目的。

3.2 TCMS驗證平臺實現

在TCMS驗證平臺中，各個受控子系統的功能均在仿真軟件中實現，當驗證TCMS中央控制功能時，TCMS應用軟件將在TCMS主控設備中運行，其他子系統將運行于1個或多個仿真工控機中，那么TCMS主控設備與子系統仿真模型之間需要通過列車總線和部分硬線，才能實現對列車網絡控制系統的驗證。如圖5所示。

圖5 列車TCMS軟件驗證平臺驅動開發

在列車TCMS軟件驗證平臺中開發的各子系統仿真模型將部署到工控機中，驗證平臺中的配置管理機將列車數據管理和硬線數據管理數據庫，生成工控機的數據管理中心，管理該子系統的仿真模型的相關接口。由于仿真工控機需要通過列車總線和部分硬線與TCMS主控設備交互數據，而本文選取的仿真軟件作為通用仿真軟件，自身并沒有具備相關接口，因此需進行二次開發實現相關驅動。如圖5所示，除列車總線驅動已在開發平臺中實現外，還需要針對驗證平臺開發硬線接口服務。

針對仿真工控機與TCMS主控設備及列車輸入輸出設備間的硬線交互問題，本文采用了與PLC電氣柜連接方式解決，即仿真系統和控制電氣硬線之間的輸入輸出信號轉換通過PLC站完成。

由于PLC與TCMS仿真驗證系統之間的接口信號眾多，文中選用OPC[15]（Object Linking and Embedding（OLE）for Process Control）通訊方式解決了在仿真模型的數據管理中心與PLC輸入輸出通道間高效、方便地建立對應關系的問題。OPC對通訊和信息管理進行了標準化，而無需處理特定協議的尋址問題，OPC客戶端可以通過一個標準、開放的多供應商接口，與OPC服務器進行通訊。

因此，文中利用PLC內置軟件建立了OPC服務器[16]，仿真系統運行的工控機作為OPC客戶端，在工控機中完成仿真信號與PLC通道間對應關系的配置管理。仿真系統運行時，工控機中的OPC客戶端從數據控制中心讀取仿真數據，并通過一個標準化的COM/DOM接口發送請求給OPC服務器，控制PLC通道輸出；或者OPC客戶端通過標準化的COM/DOM接口[17]發送請求給OPC服務器，采集PLC通道輸入，并將采集數據寫入數據控制中心用于仿真，從而實現仿真系統對PLC[18-19]電氣柜的控制。

4 列車TCMS軟件及驗證平臺一體化實現

通過對選取的通用仿真軟件進行二次開發，使本文研究的平臺不僅可以作為開發平臺對TCMS應用系統進行開發，同時也可作為驗證平臺對TCMS仿真驗證系統進行開發。

圖6 列車TCMS軟件開發及驗證平臺一體化實現

如圖6所示，在研究的TCMS一體化軟件開發及驗證平臺（以下簡稱：一體化平臺）上，可同時開發TCMS應用控制邏輯及TCMS仿真驗證模型，并通過任務部署方式，將控制邏輯應用和仿真驗證模型部署到不同目標機上。

一體化不僅體現在可同時工作在同一平臺上，同時體現在開發和驗證工作的可交互性。在一體化平臺中可同時開發應用邏輯程序及與之對應的仿真驗證模型，并共用統一的變量。當不同任務部署到不同目標機上時，各任務間通過統一生成的數據管理接口及各自驅動實現實際的數據交互，同時完成TCMS開發和驗證工作。

如圖6所示，以變量s和變量r為例，變量s為TCMS應用邏輯中需要輸出的信號，變量r為TCMS應用邏輯中需要輸入的信號，這些信號可以為列車總線、以太網和硬線等信號等。在開發階段，變量s和變量r分別為應用邏輯的輸出和輸入變量，在同一軟件層次中，變量s和變量r分別為仿真驗證模型的輸入和輸出變量。在一體化平臺上，應用控制邏輯和仿真驗證模型間對變量s和變量r具有實際連線進行連接，從而保證系統的一致性和完整性。

當應用邏輯程序和仿真驗證模型開發完成，在一體化平臺中，將其部署到不同目標機后，由一體化平臺的數據接口管理機制，對不同目標機的接口統一管理。此時，變量s和變量r在數據接口管理中存在相匹配的2份管理接口文件。2份數據文件不同在于：變量輸入輸出方向不同，變量s和變量r分別為應用邏輯的輸出和輸入，同時為仿真驗證模型的輸入和輸出；同時接口變量（如變量s）在應用邏輯和仿真模型程序中的變量地址不同。而2份數據文件相同之處在于：對于列車總線通信或硬件信號的描述一致，包括變量在車總線的端口、硬件端口、偏移、變量類型等，這也是最終2個目標機能進行通信或數據交互的本質。

數據接口管理由此分別生成應用邏輯和仿真模型相關的接口配置文件。應用邏輯程序結合本文開發平臺研究的二次開發驅動、工具，使用接口配置文件，自動生成TCMS應用邏輯功能軟件，并下載到TCMS主控設備中運行，完成TCMS邏輯控制功能；而仿真驗證模型采用本文驗證平臺研究的建模方法及驅動，使用配置文件，生成TCMS仿真模型軟件，并下載到仿真工控機設備中運行，完成TCMS仿真驗證功能。

上述過程中對變量s和變量r的接口控制驅動也自動生成，如圖6所示。系統最終運行時，TCMS主控設備根據應用邏輯算法輸出控制信號s，仿真工控機通過實際連接線路（列車總線、以太網、硬線）接收該信號，并用于仿真功能運行；當仿真模型輸出系統信號r，TCMS主控設備通過實際連接線路（列車總線、以太網、硬線）接收該信號，并用于應用邏輯運算。

5 結論

本文研究的列車一體化軟件開發及驗證平臺目前已在包括某型動車組在內的多個實際項目中成功應用。其中某型動車組項目在本文研究的一體化平臺上開發了TCMS應用邏輯和仿真驗證模型，實現了完成對該型動車組從開發到驗證的一體化設計。對TCMS系統驗證的過程中，針對TCMS各控制邏輯及系統功能進行了逐項詳細測試，測試結果表明采用本文研制的一體化平臺所開發的動車組TCMS系統能夠按照既定功能穩定的運行，證明了本平臺的可用性和正確性。

本文研究的列車TCMS一體化軟件開發及驗證平臺，首次將TCMS的應用邏輯的開發和仿真驗證模型建立融合到同一平臺中，并為TCMS集成設計提供了可視化、模塊化的開發環境和完整工具鏈，從而使TCMS系統集成商從傳統的需要維護不同開發和仿真軟件、接口一致性維護、開發及驗證階段文件系統管理等復雜繁重的工作中解脫出來，只需專心于設計階段的TCMS應用邏輯和驗證階段的仿真模型開發。

列車TCMS一體化軟件開發及驗證平臺的使用大大縮短了TCMS系統開發和驗證周期、節約大量開發和維護成本、提高了系統可靠性，適合在軌道交通領域廣泛推廣，具有很好的發展前景。

[1]高楓，趙紅衛，黃志平，等.高速動車組列車網絡控制系統自主化研制及應用[J].鐵路技術創新，2015（2）:77-82.

[2]孫寧，李照星，楊潤棟，等.城市軌道交通車輛應用技術[M].北京:中國鐵道出版社，2014.

[3]梅櫻，趙紅衛，黃楓，等.基于ControlBuild的TCMS集成軟件開發平臺設計[J].鐵道機車車輛，2016，36（1）:20-23.

[4]黃根生，趙紅衛，王欣，等.CRH_3動車組半實物仿真測試臺通信的設計與實現[J].鐵道機車車輛，2014，34（2）:5-9.

[5]趙勇，李翔，趙希驥.模塊化編程在鋁電解多功能機組控制系統中的應用[J].起重運輸機械，2013（12）:63-66.

[6]IEC61131-3 Programming Industrial Automation Systems[S].2000.

[7]陳帝水.深圳地鐵羅寶線列車限速30km/h故障原因及對策[J].技術與市場，2013，20（3）:21-22.

[8]申超，龍辛，黃波，等.基于CoDeSys的軟PLC標準數據接口研究與實現[J].機械工程與自動化，2014（1）:7-9.

[9]楊春瑜.基于ISaGRAF的PN300型分散控制器設計[J].華電技術，2015，37（7）:4-8.

[10]嚴震宇，張茂青，許海麗，等.DSP2812基于MATLAB模塊化編程的SPWM調制實現[J].蘇州大學學報：工科版，2012，32（5）:56-60.

[11]萬海，孫雷，王恬，等.列車通信網絡WTB鏈路層攻擊方法研究[J].清華大學學報：自然科學版，2016，56（1）:42-50.

[12]黃文燦.廣州地鐵3號線列車網絡控制系統及其故障診斷分析[J].機車電傳動，2012（6）:54-56.

[13]IEC.IEC 61375-1.Electric railway equipment-Train bus-Part 1:Train communication network[S].Switzerland:IEC，1999.

[14]王欣.城軌列車半實物仿真測試臺的設計與實現[J].鐵道機車車輛，2016（2）:101-106.

[15]王帥，胡毅，何平，等.基于OPC技術實現西門子數控系統的數據采集[J].組合機床與自動化加工技術，2016（4）:69-71.

[16]蔡曉霞，錢新標.PLC控制系統中OPC技術應用效率研究[J].電氣自動化，2016，38（4）:110-112.

[17]唐海林.OPC標準化方法在系統集成中的應用研究與開發[D].北京：機械科學研究總院，2014.

[18]羅義釗，俞煌，嚴琦.基于HomePlug技術的寬帶PLC采集系統應用研究[J].電力信息與通信技術，2015，13（2）:80-86.

[19]楊盛泉，荊心，楊洪波，等.工業石灰窯MVC架構的PLC控制系統[J].西安工業大學學報，2015，35（11）:877-882.