邓 健

（株洲中车时代电气股份有限公司，湖南 株洲 412001）

0 引言

随着互联网+、大数据、云计算等信息技术的快速发展及其在城市轨道交通建设中的不断应用，自动化、信息化、数字化、智能化将成为地铁车辆运维的重要发展方向［1］。车辆各终端设备采集的数据将被打包发送至地面数据中心，在进行状态分析和应用展示前需要对采集到的特定信号点位值进行解析处理。为了提升数据的传输效率、增加数据内容的机密性，车地实时数据采用二进制编码［2‐4］，地面信息系统需根据数据协议将原始二进制数据解析成具有具体含义的信号值。目前数据报文点位解析一般采用编写解析代码［5‐6］或配置可扩展标记语言（extensible markup language，XML）文件定义解析逻辑［7］等方法。采用编写解析代码法处理会存在编码工作量巨大、编写易出错的问题；且由于不同车型的设备数据和信号点位差异性大，无法做到数据解析代码的跨项目复用。而XML文件结构内嵌层次复杂［8］，不能直观展示信号点位属性，且需要专业人士才能对XML 文件进行配置，或者需要配合第三方专用XML 文件解析模块［9］，不方便项目交付人员现场调试和校准信号点位解析逻辑，存在调试工作量大、数据校准难等问题。为此，本文设计了一种车辆实时数据自动解析模块，其利用关系型数据表保存信号点位信息，数据解析引擎根据信号点位表解析数据，具备信号点位表字段清楚、结构简单、易维护以及数据解析引擎逻辑确定、方法可复用等特点，能快速、准确地实现不同车型车辆的实时数据解析。

1 车辆数据自动解析模块

车辆数据自动解析模块以数据解析引擎为核心，通过加载数据库中的信号点位表将原始二进制数据解析成具有特殊意义的信号值，达到仅需项目开发人员配置和维护信号点位表，无需修改解析代码的目的。

1.1 总体结构

车辆数据自动解析模块从总体结构上可以分为信号点位表和数据自动解析引擎［10］。信号点位表用于描述每个信号的基本属性，如信号的编码类型、位置偏移、数据长度、换算逻辑等。数据自动解析引擎为包含相应数据编码解析和换算方法的程序代码，其可根据信号点位表中的信号点位描述信息，将原始二进制数据包解析成具有特殊意义的键-值对（Key‐Value）信号点位数据，具体架构如图1所示。

1.2 信号点位表

为能够清楚描述信号点位基本属性的关系型数据库表，信号点位表定义了信号所在的数据包类型、位置偏移、数据长度、编码方式、大小端以及换算方法等属性。数据自动解析引擎可以根据信号点位表中的记录完成信号的解析和换算操作。信号点位表所涉及的主要字段内容如表1所示。

表1 信号点位表主要字段Tab.1 Main fields of signal point table

表1中序号2~4用于确定信号所属的数据报文（即报文标识符），数据解析引擎根据收到的数据报文标识，能够从信号点位表中获取该数据报文所包含的信号点位集合；序号5~11 为数据解析核心字段，数据解析引擎可以根据该字段确定信号类型、偏移位置、数据长度、编码方式，从而实现信号点位基本解析；序号12和序号13定义解析出来的数据换算关系，根据换算符和换算参数进行信号点位的单位换算；序号16为信号的标识符，给解析出来的值赋予唯一的信号标识名；序号17为设定的一个信号有效开关，用于过滤暂时预留或无效的信号点位。

1.3 数据自动解析引擎

数据自动解析引擎根据信号点位表中的各信号描述信息，将原始的二进制报文信息按照数据类型、编码格式、换算关系解析成具备特定含义的数字值。

1.3.1 数据自动解析步骤

数据自动解析具体步骤如下：

第1步，根据要解析的数据报文，提取报文标识符（即数据包所属的line_name、vehicle_type、package_type）。

第2 步，根据报文标识符查找缓存中是否已经存在该数据报文信号点位集合，如果存在，直接从缓存中获取；否则，根据line_name、vehicle_type、package_type字段从数据库点位表中查询该报文对应的信号点位集合，同时保存到缓存中。

第3步，对数据报文信号点位集合中的每个信号点位按照数据解析核心字段（signal_type、endian、coding_type、byte_offset、byte_length、bit_length）从二进制报文中解析出信号点位数字值，根据convert_operator、convert_parameter 字段对需要做特殊换算的信号点位数据转化处理得到最终的解析值，并将解析结果以Key‐Value的结构保存到解析后的Map（一种数据结构，由一组键值对组成的抽象数据结构，并且键只会出现一次）对象中，其中Key 为信号点位的signal_code，Value为解析值。

第4 步，将报文解析后的Map 对象返回给上层调用模块，完成整个数据自动解析。

具体数据自动解析引擎流程如图2所示。

图2 数据自动解析引擎流程Fig.2 Engine process of data automatic analysis

1.3.2 信号点位数字值解析方法

在整个数据自动解析过程中，对每个信号点位的信号值解析为最核心的处理逻辑。根据信号点位的byte_offset 和byte_length 从二进制报文中获取该信号对应的字节数据内容，通过signal_type 和coding_type字段调用对应的数据解析方法得到信号解析值：

（1）若signal_type 为模拟量，根据具体coding_type将字节数据内容转换成相应的数字值；

（2）若signal_type 为数字量，则根据bit_offset 和bit_length 字段从字节数据中获取以位为单位的数字值。

具体信号解析逻辑如图3 所示。例如，信号“空调总开关”点位，信号类型为数字量，编码类型为Bit（按位编码），字节偏移为261，字节长度为1，位偏移为0，位长度为1，根据该点位的描述信息，从数据报文中提取261 字节的数据内容，并获取该字节中的bit 0 的内容，得到信号解析值为0。同理，信号“障碍监测次数”点位，信号类型为模拟量，编码类型为UINT8，字节偏移为721，字节长度为1，根据该点位的描述信息，从数据报文中提取721字节的数据内容，按照无符号8位编码模式（UINT8）解析处理方法，得到信号解析值为178。

图3 信号点位数字值解析Fig.3 Analysis of signal point digital value

1.3.3 主要数据编码类型

数据解析引擎内置通用信号点位的编码类型（如Bit、INT8、UINT8、INT16、UINT16、INT32、UINT32 和UINT64等），并且能够根据项目需要，通过在数据解析引擎内增加特殊的编码类型处理方法，实现解析模块的编码类型逐步扩充的需求。

2 实验测试验证

为验证数据自动解析模块的功能和效率，编写测试程序调用数据自动解析模块对不同报文数量和不同信号点位的报文类型进行测试，结合项目验证解析结果的正确性，并纵向对比数据解析时间效率。

2.1 测试验证环境

测试软硬件环境为：台式工作站（Intel i7‐7820HQ处理器，4 核2.90 GHz，16 GB 内存，500 GB SSD 硬盘），Windows10 操 作 系 统，JDK1.8 运 行 环 境，mysql5.7.23数据库。

2.2 测试验证方法

实验a：编写测试程序读取1 条要解析的报文记录，输出解析结果，并将解析结果与项目具体案例对比，核对其解析的正确性。

实验b：编写测试程序分别读取1 条、100 条、10 000条和1 000 000条报文记录文件，测试解析不同数量的报文记录所消耗的时间，不输出和保存解析结果。

实验c：选取包含不同信号点位的信号报文记录文件，测试其解析10 000条记录所消耗的时间，不输出和保存解析结果。

2.3 测试验证结果

实验a 结果，按照配置的协议点位表测试输出的解析结果与项目案例真实点位值完全一致，数据解析正确率100%。

实验b 结果，解析不同数量的相同报文类型所用的时间如表2所示，该报文包含2 124个信号点位。

表2 不同数量的相同报文解析耗时Tab.2 Time‐consuming of parsing of different numbers of the same packets

实验c 结果，解析相同数量（10 000 条）的不同信号点位报文类型所用的时间如表3所示。

表3 相同数量的不同报文解析耗时Tab.3 Time‐consuming of parsing of the same number of different packets

2.4 测试验证结论及分析

实验a 结果表明，车辆数据自动解析模块能够根据信号点位表完全正确地解析出数据报文中的信号点位数字值。

实验b结果表明，数据解析时间和报文数量存在正相关性，由于模块第一次接收到数据报文后需要从数据库中查询该报文的信号点位集合，而后面的数据报文处理则直接从缓存中获取点位集合，因此验证解析1条报文耗时较多，除去获取数据库中报文点位集合外，数据解析的时间消耗随着数据报文条目增加而线性增长。

实验c 结果表明，数据解析的耗时与报文的信号点位数量存在正相关性，即数据报文包含的信号点位越多则数据解析的时间消耗越多。

3 车辆数据自动解析模块应用

数据解析作为车辆运营监视和运维评估的基础前提，是车辆实时展示、状态分析的上游数据处理过程，其准确性和开发效率直接影响项目的交付周期和投入成本。本文设计的车辆数据自动解析模块，具备准确率高、信号点位表结构清晰、解析开发效率高等特点，其已经在车辆智能运维系统、车辆调度系统及相关衍生产品中推广应用，在车辆智能运维系统中的具体应用模式如图4所示。

前期上海13 号线智能运维项目采用javolution 方法编写数据解析代码来解析数据报文中的信号点位，需要开发人员为每一个信号点位编写一个结构变量，并在程序里为该变量指定解析方法，存在解析代码开发工作量巨大并且容易出错等问题。而对于本文设计的车辆数据协议自动解析模块，采用数据库表作为信号点位关系描述载体，项目交付人员只需要生成和维护好信号点位表，相比采用javolution 和文献［5‐6］编写解析代码模式，其具有无需修改数据解析引擎代码、简化开发成本、提高解析准确性的优势；相比文献［7］采用XML 配置文件方式，其具有信号点位表可直观展示、易维护等优势。通过车辆智能运维特定项目开发对比，在解析2 124 个信号点位情况下，采用javolution编码解析需要2人花2周时间完成，出现6处解析代码编写错误；采用本文设计的数据自动解析模块仅需1 人3 天完成，出现1 处解析协议配置错误。因此，采用车辆数据协议自动解析模块后项目开发由原来的20人天减少到3人天，效率提升5.6倍，且信号点位解析正确率提升了0.24%。目前，该模块在产品推广中得到高度认可，已成为车辆智能运维系统、车辆调度系统等产品的标准数据处理模块。

4 结语

本文设计了一种车辆数据自动解析模块，其采用数据解析引擎和信号点位配置表分离的模式，实现了车辆数据报文信号点位可直观配置以及数据报文所包含的信号点位自动解析的功能。通过实验测试和现场应用验证，该模块能够支撑车辆智能运维、车辆调度以及其他衍生产品的数据解析功能，可减少数据报文解析开发和调试时间，缩短项目开发周期，具备很好的应用前景和推广价值。

由于目前该模块只能将信号点位解析成数字值，无法将点位解析后的数字值与其真实表达的含义关联，后续将优化数据解析模块，完善该部分功能，实现信号点位的量纲含义的完全解析。