基于分布式微服務架構的重型車污染物排放監管平臺①

錢 楓, 劉夢杰, 王明達, 王 潔, 楊 棟, 胡 蝶, 夏 俊, 程書瑾

1(武漢科技大學, 武漢 430081)

2(中國環境科學研究院, 北京 100012)

《中國移動源環境管理年報(2020)》顯示2019年全國機動車保有量達到3.48 億輛, 重型車尾氣污染物中氮氧化物、顆粒物排放占比明顯高于其他車型.國家生態環境部《重型柴油車污染物排放限值及測量方法(中國第六階段)》對重型車氮氧化物、顆粒物排放標準要求進一步提高, 同時明確規定國六車型必須加裝遠程監控車載終端[1].

遠程監控車載終端主要功能是采集車輛CAN 總線信息, 并將信息上傳至大數據平臺[2]. 通過對十余個地市環保局重型車遠程監控平臺對比分析發現, 大部分平臺只對排放數據進行簡單的處理, 然后對單臺車污染物排放超標進行判斷, 缺乏對指定區域內污染物排放總量進行統計和分析[3].

針對當前重型車遠程監控平臺對各子區域內污染物排放總量統計的不足, 本文基于分布式微服務架構設計了具備污染物分區統計功能的監管平臺, 并進行了實地部署驗證.

1 平臺功能簡介

1.1 平臺基礎功能

本平臺基礎功能包括對車輛信息、用戶信息、排放狀況進行管理并且輸出報表, 進行大屏展示, 具體技術方案如表1.

表1 平臺基礎功能

1.2 污染物排放量計算

為實現定量分析, 需將車載終端上傳的氮氧化物、顆粒物排放數據轉化為質量濃度. 表2 為部分車載CAN 網絡報文信息, 平臺通過發動機進氣量Qin(單位: k g/h) 和燃油流量Qfuel(單位: k g/h)可近似計算出發動機排氣流量(單位: k g/h). 然后根據報文上報時間間隔t(單位: s ) 、氮氧化物排放濃度Cnox(單位: p pm)或顆粒物光吸收系數K(單位: m-1)計算出氮氧化物排放總量Mnox[4]或顆粒物排放量Mpm[5]. 相關計算公式如式(1)-式(5).

表2 車載CAN 報文

1.3 污染物所屬行政區判斷算法

為直觀的展示各監管行政區內氮氧化物、顆粒物排放情況, 通過車輛實時坐標對污染物排放所屬行政區進行判斷, 并將排放量累加至所屬行政區污染物排放總量中.

將車輛坐標點作為點Q, 行政區作為多邊形S, 判斷車輛坐標點是否在行政區內可轉換為求解點Q是否在不規則多邊形S內. 該問題常用 “射線法”求解, 即以點Q作為起點向多邊形S內某一點B做射線QB, 當射線QB與多邊形S的交點個數為奇數時, 點Q在多邊形S內[6]. “射線法”存在以下幾種特殊情況需進行提前判斷: 點Q與點B重合、點Q位與多邊形S的某一頂點重合、射線QB經過多邊形S的頂點.

由于行政區邊界復雜, 在采用“射線法”求解時特殊情況和多邊形S邊的個數多, 使得計算量龐大, 不利于平臺對數據進行實時處理. 為控制服務器硬件成本、提高平臺性能, 本文提出如下方法對 “射線法”進行了優化, 降低其計算量.

在多邊形S中取一點O作為原點, 向水平方向做射線OX. 以射線OX為起點, 按固定角度α 轉動做射線, 當α足夠小時, 可將相鄰射線與多邊形S所構成的圖像近似看作扇形. 若扇形中心線與多邊形S的交點為點B, 則扇形半徑取點O和點B之間的距離lOB. 當車輛坐標點Q位于某一扇形內, 則認為Q在多邊形S內, 否則認為點Q在多邊形S外, 其原理如圖1、圖2 所示.

圖1 “射線法”優化原理圖

圖2 “射線法”優化原理圖局部放大圖

采用優化的“射線法”求解時, 首先將多邊形S以 α為圓心角分割為多個扇形區域, 以各扇形中心線與邊界線交點的極坐標(ln, αn)(n∈(0, 1,…, (2 π/α-1))構建參照表. 若點Q極坐標為(lOQ, β), 當參照表中某一極坐標(l′, α′)滿足(α′-α/2)≤β ＜(α′+α/2)時, 則此坐標為點Q在參照表中的對應坐標. 當lOQ小于或等于l′時 , 點Q在多邊形S內, 反之在多邊形外.

當多邊形S出現如圖3 所示的情況時, 即扇形內部存在部分區域不在多邊形S內的情況時. 滿足lOQ≤lOA、lOB≤lOQ且lOQ≤lOC兩條件之一則認為點Q在多邊形S中.

圖3 多交點原理圖

對傳統的“射線法”進行優化后, 減少了大量特殊情況和邊界交點的計算, 算法的空間、時間復雜度上均具有明顯優勢. 以淄博市臨淄區為例, 其行政區邊界由775 個坐標點構成, 傳統“射線法”在極端情況下, 需進行775 次比較點與頂點重合判斷、775 次射線過頂點判斷、775 次射線與邊界線交點個數判斷, 共2 325次計算. 而優化“射線法”計算待比較點坐標后, 只需一次查表和一次比較即可完成. 優化“射線法”較傳統“射線法”計算量大大減小. 優化“射線法”在劃分扇形區域時, 其邊界部位會產生一定的誤差, 但誤差區域在整個行政區中占比不高, 且車輛流動性強, 故在誤差區域的排放量可忽略不計.

1.4 行政區分級遍歷

車輛坐標所屬行政區判斷中, 通過遍歷所有行政區邊界進行逐個排除, 直至獲得最終結果. 由于行政區分布和車輛行駛軌跡變化均存在空間連貫性, 故可對行政區遍歷順序按空間連貫性進行動態調整. 車輛相鄰兩個時間點上報坐標所屬行政區大概率為同一或相鄰行政區, 據此在行政區遍歷順序上, 可根據行政區相鄰關系進行分級排列, 以減少計算量, 提高數據處理效率.

以山東省淄博市為例, 該市共包含淄川區、張店區、博山區、臨淄區、周村區、桓臺縣、高青縣、沂源縣8 個行政區. 表3 為淄博市各行政區空間關系.

表3 淄博市行政區空間關系表

當車輛上報位置信息化, 平臺按任意順序遍歷各行政區, 進行所屬行政區判斷, 并記錄所屬行政區作為下次上報的第1 優先級行政區, 優先進行判斷, 其余行政區按表2 對應優先級由高到底進行遍歷. 例如當前所屬行政區為淄川區, 則下一次判斷時第1 優先級為淄川區, 根據表2 可知第2 優先級為張店區、博山區、臨淄區、周村區, 第3 優先級為桓臺縣、高青縣、沂源縣. 按照第1 優先級、第2 優先級、第3 優先級順序進行遍歷, 同優先級內可按任意順序遍歷, 快速鎖定車輛所屬行政區.

2 平臺實現

2.1 通訊協議

監管平臺與車載終端以TCP/IP 網路控制協議作為底層通訊協議. 參考《GB17691-2018 重型柴油車污染物排放限值及測量方法(中國第六階段)》中附錄Q 規定的有關“遠程排放管理車載終端的技術要求及通信數據格式”進行應用層協議設計. 通訊協議數據包結構和定義如表4 所示.

表4 數據包結構和定義

上電后由車載終端主動向平臺發起TCP 連接, 連接成功后終端和平臺遵循圖4 通訊流程圖進行通訊.首先, 終端通過備案請求(命令單元編碼: 0x07)上傳終端密鑰、終端信息和車輛基礎信息至平臺. 平臺對上傳信息進行校驗后核查終端信息和車輛基礎信息是否已在平臺提前錄入. 處理結果通過備案應答(命令單元編碼: 0x08)返回終端.

圖4 通訊流程圖

終端對備案響應狀態進行判斷, 若響應狀態為“正確”(備案正常), 終端繼續進行登入操作. 若備案響應狀態為“錯誤”(備案異常)則查驗、修改相關信息后重新發起備案請求. 備案流程只需在終端首次上電時進行, 非首次上電跳過備案流程, 直接進入登入流程即可.

終端完成備案后再發出登入請求(命令單元編碼:0x81). 平臺核查登入信息, 若設備已完成備案流程, 則分配密鑰對, 公鑰通過登入應答(命令單元編碼: 0x80)返回終端, 私鑰存儲至數據庫. 平臺核查登入信息有誤則發出“錯誤”應答. 終端接收登入響應應答為“正確”(登入正常)后進入實時信息上報流程, 反之終端重新發起登入請求.

實時信息上報流程中, 終端首先對車輛信息進行組包、加密(采用登入流程中平臺回復公鑰進行加密)、生成校驗碼后再上傳平臺(命令單元編碼: 0x01).平臺對上傳信息進行解密、解析, 對數據正常報文做出“正確”應答(命令單元編碼: 0xF0).

終端根據平臺響應狀態判斷是否進行補發, 響應結果為“正確”即可結束本次上報流程, 其他狀態(響應失敗、無響應等)則需進行信息補發(命令單元編碼:0x03).

當車輛停止運行時終端上報登出指令(命令單元編碼: 0x04), 平臺對設備做離線處理.

2.2 平臺架構設計

平臺并發量高, 采用分布式微服務[7,8]及前后端分離技術進行架構設計, 可有效提高平臺魯棒性、擴展性. 平臺共分為1 個前端服務模塊和5 個后端微服務模塊, 如表5 所示. 前端主要實現人機交互、數據展示,后端主要完成平臺通訊、數據處理.

表5 平臺服務構成表

圖5 為平臺架構圖, 終端通過主服務器IP 及開放端口號連接平臺“platform”模塊. “platform”將終端上報原始報文推送至“dataParser”進行報文解析. “dataParser”對原始報文進行解析后, 生成平臺響應報文, 并將終端上報實時信息寫入數據庫. “area”模塊將實時數據中的位置信息與數據庫中預存的行政區信息進行比較, 判斷所屬行政區. “schedule” 模塊進行污染物統計分析,生成相關統計信息.

圖5 平臺架構圖

2.3 平臺后端實現

后端基于SpringCloud 框架[9]進行搭建. SpringCloud是一系列框架、組件的有序集合, 擁有功能完善的、輕量級的微服務實現組件, 其豐富的外部開發資源使其具備極高的開發效率. 平臺采用Docker 作為應用容器, Docker 是一個跨平臺、可移植且易用的容器解決方案[10,11], 性能開銷低, 可實現平臺的快速部署. 后端不同服務之間數據傳輸通過Kafka (一種分布式發布訂閱消息系統)實現, 將每個服務作為一個消費節點, 從而完成平臺內部數據的快速交互. 基于Netty 實現多線程、高并發的平臺外部通訊服務[12].

數據存儲采用MySQL 和ElasticSearch 的雙數據庫組合方案. ElasticSearch 數據庫主要具有如下特點:分布式, 處理方式靈活, 實現了實時檢索, 對百億級的數據查詢做到秒級響應, 可以線性擴展集群并且支持插件機制[13,14]. ElasticSearch 數據庫比其他主流數據庫(MySQL、Oracle、MongoDB 等)更適合海量車輛歷史數據存儲、查詢. MySQL 數據庫則用于平臺少量的基礎信息存儲.

2.4 平臺前端設計

前端網頁基于VUE 框架搭建, 采用螞蟻金服推出的Ant Design 和Echart 前端組件庫進行開發. 實時監控、電子圍欄及可視化大屏地圖展示采用高德地圖開發者平臺提供的Web 端接口實現. 圖6-圖9 為部分前端網頁效果圖.

圖6 實時監測界面

圖7 車輛列表界面

圖9 報表界面

圖8 禁行區界面

3 平臺部署驗證

平臺部署于山東省淄博市. 圖10、圖11 為24 h內各行政區每小時累計氮氧化物、顆粒物的排放量.可看出兩種污染物在當日上午8 點至當日下午7 點排放量明顯高于前一日晚上9 點至當日早上8 點, 桓臺縣、臨淄區排放量明顯高于其他區縣.

圖10 淄博各區氮氧化物排放量對比

圖11 淄博各區顆粒物排放量對比

平臺還可查看行政區歷史排放量變化, 圖12、圖13為一個月內臨淄區氮氧化物、顆粒物每日的排放總量.此外平臺還支持污染物超標車輛統計、單車超標次數、選定區域超標次數、單車排放總量統計. 通過污染物排放情況統計, 環保部門可充分了解各行政區域內重型車氮氧化物、顆粒物排放情況, 對嚴重超標車輛進行精準治理.

圖12 臨淄區氮氧化物排放總量統計

圖13 臨淄區顆粒物排放總量統計

4 結論

本文設計的重型車污染物排放監管平臺對重型車主要污染物氮氧化物和顆粒物進行定量分析, 并按行政區域對污染物的排放總量進行統計和展示. 為快速判斷車輛所屬行政區, 本文對“射線法”進行了優化, 對行政區遍歷順序按空間關系進行升級, 大大降低了平臺計算量, 提高了平臺的運行效率.

通過對淄博市氮氧化物、顆粒物排放情況分區統計發現: 全天不同時段排放量差異較大; 在所有行政區中桓臺縣、臨淄區排放量明顯高出其他區縣. 據此, 監管部門可針對排放污染嚴重區域及高排放時間段進行治理, 有效提高監管精準性.