馬 駿,張春光,毛 俊,陳秉智
(1 大連交通大學 機械工程學院,遼寧大連 116028;2 大連交通大學 電氣信息工程學院,遼寧大連 116028;3 大連科技學院 交通運輸學院,遼寧大連 116052)
高速列車的調試工作一直是高鐵制造商重點關心的環節。目前,各級制造商仍采用傳統的紙質調試作業流程,需要將調試作業文件逐級下發,最終交付到調試現場才能開展調試工作。在調試過程中,可能會因為文件遺失、調試作業不嚴謹、測量結果記錄不準確等原因造成調試工作完整性和準確性難以滿足出廠要求,影響列車后續動調與交付工作。為此,在制造商已有的網絡架構基礎上,設計研發基于SSM框架技術的列車智能調試平臺,實現從文件下發到調試完畢,全程無紙化操作,在有效地提高調試工作效率的同時,也保證了調試過程留痕記錄,方便日后統計與分析。
基于對某高鐵制造商現有的網絡架構分析研究,針對調試作業現場的工業級網絡結構進行研究設計。在已有的辦公網結構中,增加企業級工業網,并搭建工業網虛擬服務器,從而實現調試流程全程無紙化作業。辦公網中MOM(Manufacturing Operation Management,制造運營管理系統)負責向工業網虛擬服務器推送訂單信息和完工信息。工業網中的虛擬服務器負責接收MOM推送的訂單信息并生成數字化調試文件,利用列車智能調試平臺對調試文件進行操作,并將調試過程及結果實時上傳至工業網虛擬服務器中。為了防止外部網絡通過工業網直接訪問辦公網,使辦公網遭受網絡攻擊。在辦公網中架設1臺列車調試辦公網虛擬服務器,用于對調試作業過程中生成的重要數據及調試結果進行存儲備份,在辦公網需要時,可以從中獲取有效信息。
列車智能調試平臺的網絡架構如圖1所示[1]。企業管理部門對MOM系統服務器的IP地址進行統一管理,MOM系統向列車智能調試平臺開放一個WebService接口,用于對訂單和完工信息的發送,同時,調試平臺也為MOM端預留WebService接口,主要用于調試結果的實時上傳。

圖1 列車智能調試平臺的網絡架構
通過上述網絡結構的設計,可以滿足高速列車無紙化列調的基本條件,對于高速列車的靜態列調還需要帶有MVB通信模塊的數采設備配合使用,靜態列調網絡架構如圖2所示。由于高速列車8編組的設計,考慮到網絡結構的合理性以及數據傳輸的局限性。將按照每4節車為1個調試單元,采用2臺數采設備完成對列車MVB網絡數據的采集,并通過列車智能調試平臺進行查看,將采集內容上傳至工業網中的虛擬服務器中。

圖2 靜態列調網絡架構
在列車智能調試平臺中需要實現訂單的接收、數字化調試、自動提取數據、完工信息更新等操作。在MOM系統和列車智能調試平臺中通過應用接口實現互聯互通。調試平臺軟件執行路線如圖3所示。MOM系統通過調用該接口的ReceiveOrderInfo的方法向列車智能調試平臺派發訂單信息,訂單信息的數據采用JSON格式。在數字化調試階段,用戶通過多終端平板設備登陸到調試平臺中,從數據庫中讀取該用戶對應的訂單信息到內存,形成工序一覽表,調試平臺在后臺建立數據緩沖區,業務層啟動一個線程,專門和數采設備進行通信,數采設備將列車MVB網絡數據實時發送到列車智能調試平臺的數據緩沖區中,平臺通過變量名查找MVB變量表,提取端口號、字偏和位偏信息,從數據緩沖區中提取數據信息顯示到平臺實時數據列中,并將該數據與調試文件中對應的上下限信息進行比較分析,用戶將對已完成的工步進行確認,同時完成信息實時傳送給MOM系統。當MOM系統確認接收數據正確時,平臺將確認的信息存入數據庫中,并對該調試工步進行關閉。若MOM回應所接收信息不正確時,調試平臺將不存儲此次調試過程。

圖3 軟件執行路線框圖
2.2.1前端技術
在LayUI框架源生代碼的基礎上,利用JS+HTML+CSS前端技術優化平臺各功能模塊,完成人性化、多樣化的人機交互界面。
2.2.2后端技術
隨著Java技術在服務器端的不斷發展與應用,列車智能調試平臺基于SSM框架實現服務器端的軟件設計。框架結構如圖4所示。

圖4 框架結構
SpringMVC框架是Spring基于MVC模型的實現,SpringMVC使用DispatcherServlet做前端控制器實現基于方法級的攔截,并調用對應Controller層中相應的方法,然后通過視圖解析器在Web應用中查找視圖對象,并將渲染后的結果視圖返回給用戶[2]。
Spring框架是開源的Java平臺,Spring的核心思想主要有:反轉控制(Inverse of Control,IOC)和切 面 編 程(Aspect-Oriented Programming,AOP)。反轉控制是基于降低系統模塊耦合性的設計思想,上下層接口直接依賴,通過一定的策略實現上級管理下級模塊被調用。系統只有在使用到類時才實例化對象,由此提升系統性能,增強系統擴展性。切面編程是基于代理的設計思想,在保持原業務流程不變的基礎上增加一些附加功能,如日志管理、異常處理等,實現對事務的處理、回滾,實現業務邏輯隔離,提高系統的重用性和開發效率[3]。
MyBatis是持久層框架,通過.xml或注解實現對象到數據庫的映射,減少了大量JDBC冗余代碼,利用易于操作的SQL語句,實現數據訪問與業務邏輯的分離,方便后期系統修改和維護[4]。
通過Web.xml,ApplicationContext.xml,Config.xml 3個配置文件實現SSM框架間的融合。
平臺啟動后,運行容器(Tomcat)中的Web項目讀取Web.xml配置文件,在Web.xml中聲明了ApplicationContext.xml和Config.xml這2個文件以及文件所在路徑,通過
ApplicationContext.xml中配置組件掃描器,使用注解的方式進行開發,自動加載控制業務邏輯。還要配置視圖解析器,處理從Controller中返回ModelAndView的視圖[6]。
Config.xml文件中配置:數據源、SqlSessionFactory和Mapper掃描器,數據源配置為平臺使用的MySQL數據庫,通過配置信息與數據庫建立連接。SqlSessionFactory可以被認為是一個數據庫連接池,用于創建SqlSession接口對象,實現在一個事務里面執行多條SQL。由于在設計中使用了Spring和MyBatis的整合包對Mapper進行掃描,因此不需要對Mapper進行單獨配置[7]。
按照調試需求將平臺劃分為5大功能模塊:工序一欄、數據分析、缺陷管理、試驗管理、維護與幫助。
3.2.1工序一欄
用戶登陸平臺自動從數據庫中讀取該用戶的訂單信息,形成工序一欄表,用戶進入工序調試界面,可以查看訂單中的每一條工序,然后通過數采設備采集列車MVB網絡數據,并將采集到的數據與訂單中要求的標準范圍進行運算對比,如果檢測結果在范圍內,則表示測試通過,反之需要用戶到相應的調試點進行故障排查,完成某一條工序后,需要用戶簽名確認,整個過程將被完整的記錄在后臺數據庫中,工序一欄界面如圖5所示。

圖5 工序一欄界面
3.2.2數據分析
當完成某個訂單的所有工序后,用戶可以對調試設備的狀態進行綜合分析,前端利用Echarts圖表庫生成柱狀圖、餅狀圖等統計圖表,使數據分析更加直觀、高效。火災報警系統周故障報警數統計如圖6所示。調試平臺將數采設備采集的火警網絡數據進行存儲,根據故障編號對故障等級嚴重程度進行劃分,紅色表示嚴重故障,橙色表示輕微故障,黃色表示警告。圖6中表示在調試周期一周內,每天調試火災報警系統所產生的故障數。

圖6 火災報警系統周故障報警數統計
3.2.3缺陷管理
在用戶調試過程中,未通過的工序則被平臺標記為缺陷記錄,存儲在缺陷管理模塊中,用戶可以進入該模塊,對未完成調試的工序重新進行調試,直到調試通過后自動從該模塊中刪除。
3.2.4試驗管理
由于高速列車的調試過程非常重要,因此,某些未在工序一欄中的調試項需要用戶手動將調試內容補錄在列車智能調試平臺中,從而實現補充調試,不斷優化調試進程。
3.2.5維護與幫助
維護與幫助模塊對用戶來說起到了至關重要的作用,用戶可以在該模塊中修改自己的用戶密碼,對于不清楚的調試項點,用戶可以通過該模塊進行查找學習,不斷提升自己的調試作業能力。
利用列車智能調試平臺對250 km/h標準動車組進行聯調測試,MOM系統向調試工位推送訂單,工位長將訂單分配給指定調試作業人員,調試人員進入列車智能調試平臺查看自己的訂單信息,并開始調試作業。訂單信息如圖7所示。
調試人員通過平板遠程訪問和控制數采設備,如圖8所示。數采設備將采集到的網絡數據實時發送給列車智能調試平臺,并填入對應工步的實時值中,由于在MOM推送的訂單信息中,對每個工步對應的上限值、下限值或者標準值進行了填寫,因此列車智能調試平臺將自動判斷實測值是否為有效值,得到測試結果,如圖9所示。調試人員可以對訂單中的每一個工步進行簽名、確認、提交,提交內容將實時傳送給MOM系統。

圖8 平板遠程連接數采設備

圖9 工序一欄調試界面
通過對調試現場工業網的設計,并基于SSM框架以及前端網頁框架技術,設計出專用于列車調試的智能平臺,經過現場聯網聯調,該平臺基本可以滿足現場調試作業的需求,并且因為較高的存儲性能、快速地數據分析能力、易于操作等優點,已經可以替代傳統的調試作業流程,為高效、準確的調試作業提供了技術支持。