基于分布式微服务架构的重型车污染物排放监管平台①

时间：2024-05-04

钱枫, 刘梦杰, 王明达, 王洁, 杨栋, 胡蝶, 夏俊, 程书瑾

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 临淄区颗粒物排放总量统计