張國振，吳詩宇

(1.工業(yè)和信息化部裝備工業(yè)發(fā)展中心，北京 100846；2.重慶車輛檢測研究院 國家客車質(zhì)量監(jiān)督檢驗中心，重慶 401122)

GB 17691—2018《重型柴油車污染物排放限值及測量方法(中國第六階段)》[1]于2019年開始逐步執(zhí)行，其中附錄Q要求車載終端上傳OBD、發(fā)動機、整車、驅(qū)動電機、車輛位置、極值、報警、電池電壓/溫度等數(shù)據(jù)。為了保證所傳OBD數(shù)據(jù)、發(fā)動機數(shù)據(jù)格式滿足GB 17691—2018[1]，通信協(xié)議和其他數(shù)據(jù)格式滿足GB/T 32960.3—2016《電動汽車遠程服務與管理系統(tǒng)技術規(guī)范 第 3 部分:通信協(xié)議及數(shù)據(jù)格式》[2]，需要對遠程排放管理車載終端所傳輸?shù)臄?shù)據(jù)格式和協(xié)議一致性進行檢測。

目前，行業(yè)中針對GB 17691—2018[1]的商業(yè)檢測系統(tǒng)主要對象是排放，而對附錄Q的車載終端，需要自主開發(fā)一套軟件來完成數(shù)據(jù)格式和協(xié)議一致性的檢測，為此筆者開發(fā)了此檢測軟件。本測試軟件采用流行的軟件框架，實現(xiàn)了軟件的模塊化，具有輕便性、可維護性和可擴展性。

1 軟件主體結(jié)構(gòu)和構(gòu)架

1.1 主體結(jié)構(gòu)

移動互聯(lián)網(wǎng)發(fā)展到今天，手機APP已成為炙手可熱的信息接收媒介。軟件主體結(jié)構(gòu)采用手機APP負責信息展示；后臺服務器負責數(shù)據(jù)庫操作、數(shù)據(jù)包接收和解析；Web端作為服務器管理人員操作的工具和界面。

由于報文數(shù)據(jù)本身對時間的同步性要求高，而手機APP、電腦Web端與后臺服務器屬于3種不同的設備，為了讓不同設備在同步的時鐘下顯示和操作，需要用到長連接來保持同步。此處長連接采用了異步非堵塞Netty框架[3]。后臺服務器與車載終端之間根據(jù)GB 17691—2018的數(shù)據(jù)格式和通信協(xié)議，采用Socket框架的長連接。軟件框架相當于通用化的軟件模板，可在此基礎上進行個性化修改，使得軟件滿足使用要求，提高軟件開發(fā)效率。主體結(jié)構(gòu)系統(tǒng)圖如圖1所示。

圖1 測試軟件主體結(jié)構(gòu)及應用

異步非堵塞Netty框架配置了嚴格的加密和解密算法，保證了數(shù)據(jù)的安全性，并且實現(xiàn)了高性能，吞吐量更高，延遲更低；減少資源消耗；最小化不必要的內(nèi)存復制。

GB 17691—2018中規(guī)定了通信的數(shù)據(jù)格式和協(xié)議，本軟件采用未進行封裝的Socket進行數(shù)據(jù)操作[4]。Socket框架相比異步非堵塞Netty框架較為底層，可以按照國標實現(xiàn)通信協(xié)議，實現(xiàn)車載終端與后臺服務器的長連接。

長連接是為了保持不同設備時鐘和數(shù)據(jù)的同步。連接后，不用每次數(shù)據(jù)傳輸交換都進行握手，提高了通信效率。而手機APP、電腦Web端作為數(shù)據(jù)展示端和交互界面，調(diào)用服務器對其數(shù)據(jù)庫進行操作，不需要較好的實時性，而需要較好的數(shù)據(jù)完整性和安全性，故采用更為成熟的Http協(xié)議進行數(shù)據(jù)交互[5]。

Http協(xié)議包括請求和響應，大多數(shù)情況都是APP或Web端把請求信息按JSON格式打包成請求體，發(fā)給后臺服務器。服務器根據(jù)請求內(nèi)容，進行數(shù)據(jù)庫操作，完成之后把數(shù)據(jù)按JSON格式打包成響應體，發(fā)給APP或Web端。

1.2 軟件構(gòu)架

現(xiàn)代軟件技術為了實現(xiàn)軟件的可讀性、輕便性和可維護性，需要把業(yè)務邏輯、數(shù)據(jù)和界面相分離。這樣做的好處是，比如按車輛VIN號和型號查找報文列表，都是查詢數(shù)據(jù)庫的操作，只是查詢條件的數(shù)據(jù)不一樣，業(yè)務邏輯和界面都相差不大。只要實現(xiàn)了業(yè)務邏輯、數(shù)據(jù)和界面相分離，就可以實現(xiàn)最大限度的軟件復用和輕便性[6-7]。維護起來也相對簡單，功能一致的用一個模塊實現(xiàn)，每次修改只需要修改數(shù)據(jù)或界面即可，實現(xiàn)了較好的可維護性。這樣的軟件構(gòu)架也是目前最為流行的MVC(Model、View、Controller)構(gòu)架[8-10]。在APP、Web和后臺服務器程序的每一個地方都體現(xiàn)了MVC的理念，APP中的Activity頁面的構(gòu)架如圖2所示。

圖2 APP軟件中的Activity頁面構(gòu)架示意圖

后臺服務器的軟件構(gòu)架相對來說復雜一點，主要是因為涉及數(shù)據(jù)庫的操作、報文數(shù)據(jù)的接收和解析，為APP和Web端提供服務。作為較為底層的程序，ODB持久層程序只負責與關系數(shù)據(jù)庫的操作。在其上，有Server層，實現(xiàn)具體的功能，如注冊用戶、用戶登錄、報文顯示、終端信息管理、長連接等功能塊。Server層之上為Controller層，相當于總調(diào)度中心。如果手機APP發(fā)送了一個請求，Controller去調(diào)用一些Server功能塊，完成某個操作，Server返回了一些響應數(shù)據(jù)，再通過Controller返回給手機APP用于顯示。一種手機APP的一種請求對應一個Controller調(diào)度令，Controller調(diào)度令的數(shù)量多于Server功能塊。Controller調(diào)度令和Server功能塊一起組成了MVC中的C，Model相當于ODB持久層和關系數(shù)據(jù)庫，View相當于數(shù)據(jù)提供的手機APP和電腦Web端。這樣也可以將后臺服務器的軟件構(gòu)架看成MVC結(jié)構(gòu)，只是稍微變形而已，如圖3所示。

圖3 后臺服務器軟件構(gòu)架圖

其他軟件功能塊，如用戶登錄、用戶注冊、車載終端信息管理、檢測流程等，與以上結(jié)構(gòu)和構(gòu)架類似，本文不詳細論述。

2 測試軟件的應用

2.1 接收并保存國六終端報文

后臺服務器調(diào)用CountrySixStandard功能塊開啟長連接線程，開啟一個端口用于接收終端發(fā)來的數(shù)據(jù)，然后把全部數(shù)據(jù)放入entity中，再放入數(shù)據(jù)包對象ReceiveMessages里面。根據(jù)通信協(xié)議中的數(shù)據(jù)格式，取出數(shù)據(jù)包體。

對不同的報文類型，從數(shù)據(jù)包體(含包頭、數(shù)據(jù)體、校驗位)中取出數(shù)據(jù)體，將其組合成不同類型的JSON數(shù)據(jù)格式(以登錄數(shù)據(jù)包為例)，保存到數(shù)據(jù)庫中。

2.2 解析國六終端報文

以OBD和發(fā)動機數(shù)據(jù)格式的定義進行每一位的解析。格式定義見表1和表2。測試軟件按OBD和發(fā)動機數(shù)據(jù)進行解析，需要解析的OBD數(shù)據(jù)和發(fā)動機數(shù)據(jù)見表1和表2。

表1 OBD數(shù)據(jù)(詳見GB 17691—2018附錄Q)

表2 發(fā)動機部分數(shù)據(jù)(詳見GB 17691—2018附錄Q)

2.3 傳輸報文給APP或Web端

本文以APP為例說明，Web端不詳述。APP調(diào)用Controller調(diào)度令，取出請求體中的內(nèi)容，放入wrapper中，執(zhí)行數(shù)據(jù)庫的條件查詢，查到的結(jié)果放入ResultHelper中，返回給APP。

2.4 測試軟件測試結(jié)果

本文以測試軟件中的APP為例說明，Web端不用詳述。測試軟件的APP實現(xiàn)了車載終端報文數(shù)據(jù)解析和顯示，測試軟件測得的結(jié)果如圖4所示。

圖4 APP數(shù)據(jù)解析頁

3 結(jié)束語

本文開發(fā)的測試軟件可用于GB 17691—2018附錄Q中遠程排放管理系統(tǒng)車載終端的軟件符合性檢測，也可用于發(fā)動機及OBD數(shù)據(jù)的監(jiān)控。后續(xù)動作準備把數(shù)據(jù)進行采集后，根據(jù)數(shù)據(jù)辨識得出此車輛的數(shù)學模型，并根據(jù)數(shù)學模型監(jiān)測以后運行中的發(fā)動機和OBD數(shù)據(jù)，監(jiān)測發(fā)動機排放的劣化程度和數(shù)據(jù)真實性等指標。