鄭 斌，李小勇，閆迷軍，孔 元，李洋濤，

(1 北京縱橫機(jī)電科技有限公司，北京 100094；2 中國鐵道科學(xué)研究院集團(tuán)有限公司 機(jī)車車輛研究所，北京 100081)

近年來，隨著信息化、智能化、網(wǎng)絡(luò)化的發(fā)展，嵌入式系統(tǒng)已經(jīng)應(yīng)用到社會公共服務(wù)的各個領(lǐng)域，軌道交通行業(yè)也不例外。在動車組上，幾乎所有的車載設(shè)備都是單獨(dú)的嵌入式系統(tǒng)，例如機(jī)車車輛上核心的嵌入式設(shè)備包括CCU、BCU、TCU、ACU、DCU、PIS等。這些車載設(shè)備的嵌入式軟件除了要實(shí)現(xiàn)關(guān)鍵的控車邏輯，維護(hù)軟件的功能也是必不可少的，通常維護(hù)軟件的功能主要包括：固件上傳、日志下載、故障記錄下載、車輛數(shù)據(jù)狀態(tài)的監(jiān)視、車輛數(shù)據(jù)的設(shè)置、執(zhí)行相關(guān)命令并返回結(jié)果等。

傳統(tǒng)的車載嵌入式設(shè)備實(shí)現(xiàn)維護(hù)功能的方案主要有下面幾種:

(1)完全基于串口命令行方式，車輛數(shù)據(jù)的獲取，設(shè)置和展示都在命令行窗口實(shí)現(xiàn)；

(2)CS(Client-Server，簡稱CS)架構(gòu)方式，客戶端采用傳統(tǒng)上位機(jī)圖形化編程技術(shù)，例如MFC，QT，CSHARP等；

(3)基于MPA模式(Multi-Page-Application，簡稱MPA)設(shè)計的BS架構(gòu)。

第1種方式的缺點(diǎn)很明顯，即用戶體驗(yàn)較差。第2種方式客戶端和服務(wù)器之間需要約定私有的網(wǎng)絡(luò)傳輸協(xié)議，通常定義成基于TCP的二進(jìn)制傳輸協(xié)議，不利于維護(hù)軟件的擴(kuò)展和兼容。而且客戶端軟件的技術(shù)實(shí)現(xiàn)很難滿足跨平臺的需求，實(shí)際項目中維護(hù)軟件通常只開發(fā)PC端的版本，無法滿足移動端的使用需求。第3種方式是傳統(tǒng)的桌面級web應(yīng)用的設(shè)計方式，相比于SPA(Single-Page-Application，簡稱SPA)應(yīng)用，MPA需要設(shè)計多個前端頁面，用戶的交互會導(dǎo)致頁面跳轉(zhuǎn)，頁面跳轉(zhuǎn)一方面會影響到用戶體驗(yàn)，另一方面會增加和服務(wù)器的交互頻率，增大網(wǎng)絡(luò)帶寬占用，不適合車載設(shè)備低網(wǎng)絡(luò)帶寬占用的應(yīng)用需求和場景。

針對上述傳統(tǒng)實(shí)現(xiàn)方案的缺陷，提出了一種前端采用SPA[1]方式、后端采用Mongoose的BS架構(gòu)設(shè)計方案，整個設(shè)計方案采用MVC(Model-View-Controller)模式開發(fā)構(gòu)建，該方案只需開發(fā)一套前端頁面即可滿足全平臺的使用需求。方案如圖1所示：

圖1 一種基于SPA車載嵌入式系統(tǒng)維護(hù)軟件BS架構(gòu)方案

1 前端頁面設(shè)計

車載嵌入式設(shè)備的硬件性能比桌面級計算機(jī)有較大的差距，因此前端頁面的設(shè)計盡可能減少與后端服務(wù)器的交互。采用SPA方案進(jìn)行前端頁面的設(shè)計，每次功能頁面的跳轉(zhuǎn)只在本地進(jìn)行，不與服務(wù)器進(jìn)行http交互，同時為了兼容跨平臺的用戶體驗(yàn)，采用響應(yīng)式布局，以保證在PC、平板、手機(jī)等不同級別的硬件平臺上都能有較好的用戶操作體驗(yàn)。

隨著近幾年互聯(lián)網(wǎng)技術(shù)的迅猛發(fā)展，前端技術(shù)的發(fā)展也在不斷的革新。尤其是以Vue、Angular、React 3大前端框架的出現(xiàn)將web前端帶入組件化開發(fā)時代。

選用當(dāng)下最流行的Vue作為項目前端模板，它是一種用于構(gòu)建用戶界面的漸進(jìn)式框架，采用MVVM的設(shè)計理念，實(shí)現(xiàn)數(shù)據(jù)和UI的雙向綁定。Vue簡單易用，且可以靈活的和第3方庫進(jìn)行整合，非常適合構(gòu)建SPA應(yīng)用。

文中給出一種簡約清晰的單頁前端響應(yīng)式布局方案，可同時適配電腦視圖和手機(jī)視圖，如圖2所示。

圖2 前端頁面模板

如圖2所示，左側(cè)為功能菜單導(dǎo)航區(qū)，用戶點(diǎn)擊對應(yīng)的功能菜單，則高亮選中的菜單，同時右側(cè)區(qū)域展示對應(yīng)的功能視圖。由于Vue.js采用了組件化開發(fā)的設(shè)計理念，每一個組件均需要實(shí)現(xiàn)3部分功能：頁面模板、js邏輯、css樣式。本項目的前端設(shè)計也采用組件化方式進(jìn)行設(shè)計開發(fā)。前端頁面的根組件包含3個子組件,即頭部組件、左側(cè)導(dǎo)航組件、右側(cè)內(nèi)容展示組件。其中右側(cè)內(nèi)容展示組件隨左側(cè)導(dǎo)航菜單動態(tài)切換，需要為左側(cè)導(dǎo)航菜單的每一個菜單項設(shè)計對應(yīng)的組件，所有這些菜單功能組件共用右側(cè)展示局域，具有排他性。整個前端的頁面邏輯如圖3所示。

圖3 前端頁面邏輯

傳統(tǒng)單頁面局部視圖切換采用控制樣式來實(shí)現(xiàn)視圖的顯示和隱藏，而且通常是將所有的視圖和js邏輯寫在一起，這種設(shè)計方式在模塊化和擴(kuò)展性方面都較差。使用了Vue提供的前端哈希路由機(jī)制配合組件化思路來實(shí)現(xiàn)局部視圖的切換。核心思想是為每個功能菜單設(shè)計對應(yīng)的哈希路由url，同時將該url與對應(yīng)的組件相關(guān)聯(lián)，最終會形成一張前端路由url和組件的對應(yīng)關(guān)系表,當(dāng)用戶點(diǎn)擊對應(yīng)的左側(cè)功能菜單，會觸發(fā)前端路由url跳轉(zhuǎn)(瀏覽器地址欄會有相應(yīng)的顯示，但是此時沒有與后端服務(wù)器進(jìn)行交互)，結(jié)合前端路由表，Vue會自動實(shí)現(xiàn)對應(yīng)組件的展示。

業(yè)務(wù)數(shù)據(jù)監(jiān)視功能組件的主要功能是實(shí)時顯示業(yè)務(wù)數(shù)據(jù)，實(shí)現(xiàn)方式采用主流的AJAX方式(一種和后端服務(wù)器異步交互，當(dāng)前頁面無跳轉(zhuǎn)且局部刷新的技術(shù))，周期性調(diào)用API接口，獲取對應(yīng)的回復(fù)數(shù)據(jù)后，刷新該組件上的視圖信息。由于Vue采用了MVVM(Model-View-ViewModel)的設(shè)計模式，因此只需在組件展示時，將整個組件上的所有動態(tài)數(shù)據(jù)和相關(guān)的UI元素做綁定，每次得到AJAX的回復(fù)數(shù)據(jù)后，Vue會自動實(shí)現(xiàn)界面元素的刷新。

2 前后端交互接口設(shè)計

前后端交互接口的設(shè)計采用Restful API[2]方式,如表1所示。Rest是一種軟件設(shè)計風(fēng)格，由Roy Thomas Fielding博士于2000年提出，現(xiàn)已廣泛應(yīng)用于各種桌面級web應(yīng)用中。其核心思想是約定不同的ID來表示不同的資源或者后臺服務(wù)，結(jié)合http協(xié)議，通常ID表示請求url，http請求方法包括post，get，put等。請求url的命名定義應(yīng)能直觀反應(yīng)API的功能行為。請求url的命名和服務(wù)器端資源的訪問路徑無直接關(guān)系，具體映射關(guān)系由后端服務(wù)器的路由分發(fā)請求決定。

表1 前后端交互接口API

除下載接口，其余所有接口的返回均以Json格式數(shù)據(jù)返回。Json格式數(shù)據(jù)是當(dāng)下桌面級web應(yīng)用前后端交互的最主流格式，前端頁面通過AJAX請求得到的Json格式數(shù)據(jù)可以轉(zhuǎn)化成一個JS對象，從而可以完成與頁面模板中的模板數(shù)據(jù)對應(yīng)，實(shí)現(xiàn)當(dāng)前頁面數(shù)據(jù)的自動刷新。

3 后端設(shè)計

傳統(tǒng)桌面級服務(wù)器領(lǐng)域的后端部署通常采用Apache、Nginx或者NodeJS,同時實(shí)現(xiàn)動態(tài)網(wǎng)頁技術(shù)還需要PHP、JAVA、Python等至少一種語言的支持。然而大部分的車載嵌入式設(shè)備的操作系統(tǒng)都是按需裁剪的，僅保留自身業(yè)務(wù)功能需要的組件，以保證整個系統(tǒng)的輕量化，因此通常均不具有這些桌面級服務(wù)器領(lǐng)域的軟件資源和環(huán)境。

嵌入式領(lǐng)域的web服務(wù)器有很多開源的實(shí)現(xiàn)方案，例如lighthttpd、boa等，但這些web服務(wù)器均不支持任意自定義的Restful API方式，要實(shí)現(xiàn)動態(tài)網(wǎng)頁必須通過CGI技術(shù)，每個CGI均要對應(yīng)一個服務(wù)器端的程序或者腳本，而且不夠輕量，在跨平臺移植方面的支持也不友好。

選擇Mongoose[3]來構(gòu)建后端的http服務(wù)。Mongoose是一個開源的網(wǎng)絡(luò)通信服務(wù)庫，流行度非常高。它的實(shí)現(xiàn)極其輕量，僅包含一個.c源文件和一個.h頭文件，因此可快速的集成到用戶的開發(fā)環(huán)境中來。因前端的tcp處理采用了異步事件poll方式，同時具有較好的性能，最重要的是它支持Restful API。通過封裝它提供的API接口可以快速地創(chuàng)建http服務(wù)。用戶只需定義和配置路由分發(fā)接口，并完成相應(yīng)接口的回調(diào)實(shí)現(xiàn)。整個后端的處理流程如圖4所示。后端主進(jìn)程先進(jìn)行Mongoose http服務(wù)器的初始化配置工作，然后初始化路由請求分發(fā)表，表中每一項對應(yīng)一個請求url字符串和一個對應(yīng)的處理函數(shù)，采用哈希表實(shí)現(xiàn)。然后啟動對應(yīng)端口監(jiān)聽的http服務(wù)，此時主進(jìn)程會進(jìn)入休眠等待狀態(tài)，直到客戶端瀏覽器發(fā)起了一個http請求，主進(jìn)程會立即被喚醒，讀取相應(yīng)套接字上的數(shù)據(jù)流，然后進(jìn)行http協(xié)議的解析，最終進(jìn)入鉤子函數(shù)，函數(shù)入口會傳入一個http_message 結(jié)構(gòu)的引用，內(nèi)部的相關(guān)成員已經(jīng)全部被解析和填充，可以獲取對應(yīng)的url字符串和get/post參數(shù)。

圖4 后端處理流程

為了便于接口的維護(hù)和提高可擴(kuò)展性，設(shè)計了路由分發(fā)層，在初始化的路由請求分發(fā)表中存儲了所有的請求url和對應(yīng)處理函數(shù)的鍵值關(guān)系，在ev_handler函數(shù)中將解析得到的url字符串進(jìn)行哈希查找，然后調(diào)用對應(yīng)的回調(diào)函數(shù)。每當(dāng)需要增加一個新的接口，只需要在路由分發(fā)表中加入一項新接口的url字符串和對應(yīng)的處理函數(shù)，然后補(bǔ)充對應(yīng)處理函數(shù)的實(shí)現(xiàn)，完全不會影響既有的路由請求接口功能。結(jié)合表1列出的全部接口，只需在后端添加對應(yīng)的路由分發(fā)表，然后給出具體的業(yè)務(wù)實(shí)現(xiàn)。

對于獲取和設(shè)置業(yè)務(wù)進(jìn)程的相關(guān)狀態(tài)數(shù)據(jù)的接口功能實(shí)現(xiàn)，每當(dāng)收到相關(guān)的路由請求，可以對相應(yīng)的業(yè)務(wù)進(jìn)程發(fā)起跨進(jìn)程間通信，并制定相應(yīng)的通信協(xié)議，進(jìn)程間通信可采用文件socket、消息隊列、或者管道等方式，讓所有的業(yè)務(wù)進(jìn)程提供相關(guān)狀態(tài)信息的獲取和設(shè)置接口，返回對應(yīng)的數(shù)據(jù)。

對于固件上傳功能的實(shí)現(xiàn)，HTTP_STREAMING_MULTIPART是標(biāo)準(zhǔn)的基于http的上傳協(xié)議，Mongoose提供了處理HTTP_STREAMING_MULTIPART協(xié)議的API,只要在ev_handler函數(shù)內(nèi)部判斷請求類型為HTTP_STREAMING_MULTIPART，然后調(diào)用該協(xié)議的處理函數(shù)。Mongoose提供的上傳處理函數(shù)只能處理單個文件的上傳，而車載嵌入式系統(tǒng)的軟件資源通常是一個集合，包括腳本、可執(zhí)行程序、配置文件、動態(tài)鏈接庫、web相關(guān)的靜態(tài)資源等，最終以壓縮包的形式提供，因此需要優(yōu)化Mongoose提供的上傳處理函數(shù)，在最終協(xié)議結(jié)束的狀態(tài)入口加入對上傳文件類型的判斷，如果是固件壓縮包則進(jìn)行解壓縮處理，再將解壓得到的各種資源按照項目需求拷貝到對應(yīng)的目錄結(jié)構(gòu)中。

4 結(jié) 論

針對車載嵌入式設(shè)備維護(hù)軟件的設(shè)計需求，提出一種基于SPA前端技術(shù)和Mongoose服務(wù)器技術(shù)相結(jié)合的通用設(shè)計方案。通過響應(yīng)式頁面的前端設(shè)計可以實(shí)現(xiàn)非常美觀和友好的人機(jī)界面，并且兼容各種平臺的終端(包括PC端和手機(jī)移動端)，從而無需為各種不同的終端編寫不同的客戶端軟件,在節(jié)約開發(fā)成本的同時極大的提高了用戶體驗(yàn)。由于整個方案前端采用組件化設(shè)計，后端采用模塊化設(shè)計，因此，對于不同的項目只需針對不同的業(yè)務(wù)需求更改相應(yīng)的前端組件展示和后端路由分發(fā)處理模塊即可快速移植。該方案已在動車組輔助駕駛裝置、動車組應(yīng)急牽引裝置等多個項目中部署實(shí)施，能夠滿足現(xiàn)場維護(hù)人員的功能需求，可作為車載嵌入式系統(tǒng)維護(hù)軟件的通用設(shè)計方案加以推廣應(yīng)用。