基于CAN的混合协议解析软件设计与实现

2022-08-23潍柴动力股份有限公司王怀宽刘月美高国樑

数字技术与应用 2022年8期

潍柴动力股份有限公司王怀宽刘月美高国樑

串行通讯协议CAN在汽车电子中有着广泛应用，基于CAN总线的上层协议也非常多。随着人们对汽车的要求的提升，控制策略也变得愈发复杂，外部工具要实现对ECU的访问，需要使用多种协议才能完成。而对通信协议进行解析通常存在耗费时间长、错误率较高等问题。为解决这些问题，解析出工程师更易于理解的序列说明，本文设计并实现了基于CAN的混合协议解析软件。软件实时接收CAN报文序列，并进行实时的解析，同时能够根据自定义关注点数据库，自动匹配目标序列。经测试，该软件可以准确解析出协议内容，满足实际的应用需求。

当今时代，人们对汽车的要求越来越高，这大大推动了汽车电子技术的发展，使得汽车电子逐步成为汽车各方面性能提升和功能扩展的关键技术支撑。在汽车电子中，CAN （Controller Area Network，控制器局域网）总线有着广泛的应用，但是CAN本身并不完整，它只定义了物理层和数据链路层，而没有定义应用层，因此出现了许多基于CAN总线的上层协议，如常见的XCP（Universal Measurement and Calibration Protocol，通用测量标定协议）、CCP（CAN Calibration Protocol，CAN标定协议）、UDSonCAN（Unified Diagnostic Services on CAN，统一诊断协议在CAN上的实现）以及SAE J1939（美国汽车工程协会规定的整车通讯协议）等。

随着功能需求的不断增加，发动机策略变得日益复杂，外部工具对汽车电子控制系统的核心ECU的访问往往需要使用多种通信协议才能实现。而对协议进行解析，需要耗费大量的时间并且错误率较高。

为了解决上述的问题，提升工程师的工作效率，本文设计实现了基于CAN的混合协议解析软件CANHPA（CAN Hybrid Protocol Analysis）。该软件可用于对外部工具进行监控，按照时间序列、上层类型对ECU所做的所有处理进行解析。

1 CAN总线协议概述

CAN为串行通讯协议，能够有效地支持具有很高安全等级的分布式实时控制。如图1所示，根据ISO/OSI参考模型，CAN被分为物理层和数据链路层两个层级，其中数据链路层又被细分为逻辑链路控制子层（LLC）和媒体访问控制子层（MAC）。各个层的主要作用如下。

图1 CAN结构Fig.1 CAN structure

（1）逻辑链路控制子层：报文滤波、过载通知、恢复管理；

（2）媒体访问控制子层：报文分帧、仲裁、应答、错误检测和标定；

（3）物理层：在不同节点之间根据所有的电气属性进行位的实际传输。

CAN报文的传输涉及四种不同的帧类型，分别是数据帧、远程帧、错误帧以及过载帧。

2 需求分析

软件的需求分析关乎软件开发的成败甚至是最终的产品质量，是开发工作的基础。根据实际的业务需求，分析出基于CAN的混合协议解析软件应具备协议接收、协议存储、协议解析等功能。此外，软件还需要满足一定的非功能性需求，如安全性、鲁棒性、可扩展性等。

CANHPA的基本流程图如图2所示。软件首先初始化各个数据库。点击启动后，软件开始接收报文并将接收到的原始报文存储在数据库中以备后续使用。在存储报文的同时，软件根据CAN ID得出报文的协议类型，对于CANPHA不支持的协议类型，直接以原始报文的形式的呈现给用户；对于软件所支持的协议类型，CANPHA将该协议依据对应的描述文件解析出物理含义。接下来CANPHA读取高级翻译数据库对类型受支持的协议进行更进一步的解析。若设置了自定义关注数据库，则根据设置匹配总线报文，若匹配成功，则输出匹配一致。

图2 CANPHA基本流程图Fig.2 CANPHA basic flow diagram

3 软件设计与实现

3.1 总体设计

CANHPA使用分层模式，软件整体由数据层、业务层和展示层构成。软件的架构图如图3所示。

图3 CANHPA架构图Fig.3 CANHPA architecture diagram

（1）数据层：数据层负责存储实际业务数据以及软件接收到的原始报文数据，同时还提供ECU中程序描述文件的存储服务，例如CCP/XCP对应的A2L文件、UDS对应的ODX文件、SAE J1939对应的DBC文件等。

（2）业务层：业务层实现软件具体的业务逻辑。CANHPA预先加载对应ECU中程序的各种数据库文件，当CAN总线打开时，软件接收报文序列，然后与预设的内容进行匹配，若匹配成功，则输出经过解析的报文；若匹配失败，则以原始报文数据的形式输出。

（3）展示层：展示层用于将解析后的报文信息展示给软件用户，该层主要依托HTML、JavaScript、CSS等技术进行实现。用户根据具体场景，可选择按照协议类型或者接收时间显示解析结果。

3.2 主要功能详细设计与实现

在软件的开发过程中，选用Spring Boot框架实现CANPHA的具体业务功能。Spring Boot 继承了Spring 框架的优点，并且能够根据项目依赖进行自动配置，可以在很大程度上简化软件的开发过程。

CANPHA使用Packet这一核心类来定义协议的数据包，它包含ID、Length、Data等属性。CCPPacket、UDS Packet等描述已知类型的协议的类通过继承Packet得到。CANHPA主要功能如图4所示。

图4 CANHPA主要功能Fig.4 CANHPA main functions

ASAM MCD-2 MC定义了用于测量和标定的内部ECU变量的描述格式，A2L文件是ASAM MCD-2 MC标准的表现形式。测量和标定系统需要A2L描述文件调整ECU软件的标量常数、曲线和映射，并在实时测试期间通过测量变量记录系统的响应。该描述包含ECU变量的数据类型、维度，布局和存储位置的信息，并进一步描述了如何将变量值转换为易于理解的物理量，从而可以在MC系统中直观地显示。

DBC文件描述了单个CAN网络的通信。这些信息可以用来监视以及分析网络，也可以用来模拟CAN节点，此外，DBC文件还可用于开发电控单元的通信软件。描述CAN网络基本通信的DBC文件包含bit_timing、Nodes和Messages等部分，其中bit_timing是必须的但通常留空，CAN网络的波特率和BTR寄存器设置在此部分定义；Nodes也是必须的，该部分用于定义网络节点，节点名需唯一；Messages用于定义消息和信号。

ODX（Open Diagnostic Data Exchange）标准定义了一个数据模型，用于描述ECU从开发、测试、生产到售后和服务的整个生命周期所需的诊断能力。ODX将诊断数据存储在一个中心位置，ODX以XML格式将数据进行序列化。该标准统一了诊断文件的格式，使得ECU所有开发阶段的诊断数据可以完全复用，例如诊断通信的设计、ECU内核和应用软件的开发、诊断测试设备的配置以及车辆诊断文档的生成，促进了开发过程中合作伙伴之间的诊断信息交换。

AcquisitionService类的getMessage方法实现了CAN总线上报文的实时接收。报文输入到软件中时，调用AnalysisService类的Analyse方法对报文进行初步解析，该方法返回协议的类型，如果该协议是CANHPA暂不支持的类型，则使用WebSocket协议将原始报文推送给前端进行显示；如果该协议是CANHPA支持的类型，则调用对应的解析方法对协议继续进行解析，并将最终的解析结果反馈给软件前端界面。