基于AUTOSAＲ的电动汽车中央控制单元CAN通信软件开发

　　摘要: 随着人们对于汽车安全性和舒适性要求的日益提高，汽车电子技术不断发展，日益复杂的汽车功能需求使得汽车 ECU 软件代码量急剧增加。软件与硬件之间的高度耦合使得开发工作大量重复且复用性低，极大增加了企业研发和维护成本。以 AUTOSAR 架构为基础，进行以电动汽车中央控制单元为硬件平台的 CAN 通信模块软件开发，提升软件的复用性和开发效率，降低软件更新和硬件升级的研发成本。

　　董碧成; 石春; 吴刚， 仪表技术 发表时间：2021-08-05

　　关键词: 汽车电子; AUTOSAR 架构; 中央控制单元; CAN 通信软件

　　0 引言

　　随着汽车电子技术的发展，其应用取代了大部分传统的机械部件，逐步深入到汽车的各个角落，成为驱动汽车执行动作的核心。日益复杂的功能需求，使得汽车 ECU ( Electronic Control Unit) 数 量 逐 渐 增 加。 ECU 的软件代码量也随着功能的增加日趋庞大，软件维护和管理工作繁重。与此同时，每当硬件升级或更换硬件平台时，软件需要进行大量地修改甚至重新设计，使得软件开发周期延长，开发成本大大提高[1]。

　　在此背景下，全球最大规模的几家汽车企业、零部件供应商以及电子、半导体、软件系统公司，于 2003 年联合成立了一个汽车开放系统架构联盟———AUTOSAR( AUTomotive Open Source ARchitecture) 联盟，并推出了一个开放化、标准化的汽车嵌入式系统软件架构———AUTOSAR 规范。其主要目标涵盖了软件升级更新、开发可重用软件、加快软件开发维护以及优化可扩展系统成本等多个方面，较好地解决了 ECU 软件开发过程中的突出问题[2]。

　　1 AUTOSAR 介绍

　　AUTOSAR 采用模块化的分层软件设计，从软件架构视图角度可分为应用层、运行时环境和基础软件层，如图 1 所示。应用层由软件组件单元构成，包含与硬件无关的应用软件组件、传感器软件组件和执行器软件组件等。运行时环境为系统提供基础的通信服务，支持应用层软件组件之间的通信，以及应用层软件组件到下层基础软件层之间的通信，运行时环境将应用层软件与下层基础软件层分割开来。基础软件层主要提供基础软件服务、标准化系统功能和应用接口，由服务层、ECU 抽象层、微控制器抽象层和复杂驱动组成[3]。

　　AUTOSAR 架构通过将硬件层进行抽象，得到微控制器抽象层，隐藏了硬件接口细节，达到将硬件与上层软件分离的效果，实现水平层解耦。当 ECU 硬件平台进行更新换代时，只需要将微控制器抽象层接口函数进行修改，上层代码可以实现复用，大大减少了开发时间和成本，提升了软件的复用性。

　　2 CAN 通信模块设计分析

　　2. 1 CAN 通信模块软件架构

　　CAN 通信模块包括了 AUTOSAR COM、PDU Router、CAN Interface 和 CAN Driver 几个模块。根据 AUTOSAR 分层设计思想和 AUTOSAR 规范对 CAN 通信模块设计的要求，设计出如图 2 所示的软件框架。OSEK OS 是个静态的实时操作系统，主要为应用层软件提供服务，在 CAN 通信中为需要周期执行的函数提供服务。 OSEK OS 位于系统服务层，操作系统需要直接操作下层硬件，贯穿了 ECU 抽象层和微控制器抽象层。

　　AUTOSAR COM 模块主要起到信号接口和数据网关的作用，负责发送上层传递的信号和信号组，解析从底层接收的数据并通知上层。上层只需要传递数据和接收数据，无需关心传输和接收的具体过程[4]。

　　PDU Router 简称 PDUR，PDUR 模块主要是起一个过渡兼容的作用，对上提供统一的接口，屏蔽下层网络细节，对下层兼容多种车载总线，如 CAN、LIN 和 FlexRay 等。PDUR 模块提供 I-PDU 的网关功能，使得不同的总线之间可以进行通信[5]。CAN Interface 简称 CAN IF，CAN IF 模块主要是处理上层模块和底层驱动之间的 PDU 数据流传递，为上层模块提供统一接口，并通过特定的接口函数来管理 CAN 硬件[6]。

　　CAN Driver 模块为 CAN 通信软件的最底层，是直接访问 CAN 通信相关硬件的模块，通过对硬件抽象，向上层 CAN IF 模块提供与硬件无关的函数接口[7]。

　　2. 2 CAN 通信模块开发步骤

　　CAN 通信模块各层软件开发步骤如图 3 所示。通过 AUTOSAR 规范中对分层架构设计和对 CAN 模块开发的要求，确定基础数据类型和定义数据结构，规范各文件主要作用并确定相互包含结构，设计相应的通知机制和错误处理机制。

　　3 软件设计

　　3. 1 AUTOSAR COM 模块设计

　　COM 模块从上层接收到的数据称为信号或信号组，信号组由复杂的或者功能类似需要同步发送的信号组合而成。COM 模块的信号类型如表 1 所示。

　　COM 模块为上层需要传递的信号和信号组确定唯一的编号信息，并为类型相同的信号集中定义运行时缓冲区，用来存储信号值的最新数据。信号和信号组在 COM 模块都会被封装在交互层数据协议单元( IPDU) 之中，进而完成数据向下层模块传递。COM 模块为信号定义了 5 种传输属性，一个 I-PDU 可以包含多个信号，每个信号可以选择一种传输属性，这个传输属性定义了在信号写访问时触发包含此信号 I-PDU 的传输情况。信号的传输属性如表 2 所示。

　　I-PDU 有 4 种传输模式，各传输模式的含义如表 3 所示。

　　在 COM 模块的数据处理过程中，涉及到很多数据类型，这些数据类型包装在结构体中进行使用。COM 模块使用的数据结构体包括: COM 模块配置参数结构体、发送信号结构体、接收信号结构体、发送 I-PDU 结构体、接收 I-PDU 结构体、发送信号组结构体和接收信号组结构体等。

　　发送信号结构体类型 Com_TxSignalType 的设计及部分成员的含义:

　　问触发 I-PDU 传输的几种模式* / const PduIdType ComIpduRefIndex; /* 所属的 I-PDU 的索引* / P2CONST( Com _ FilterType，AUTOMATIC，COM _ APPL _ CONST) ComFilter; /* 信号的过滤配置参数，在发送端用于确定传输模式条件 TMC* / …/* 省略部分参数* / } Com_TxSignalType;

　　结构体 Com_TxSignalType 中所包含的成员较多，进行了部分省略。发送信号主要包含用于在信号发送时的各项参数以及跟信号相关的回调函数。定义的 ComErrorNotification 是一个函数指针类型，主要用于在信号发送时，如果包含信号的 I-PDU 没有激活，就会调用这个回调函数通知错误。ComNotification 则用于信号成功发送到总线上时通知上层使用。ComFilter 是一个指向过滤参数的结构体指针，在接收信号时用于接收过滤，在发送信号时用于计算判断传输模式条件 TMC。TMC 的值会影响 I-PDU 发送模式选择 TMS 的值。

　　发送的信号最后会封装在 I-PDU 之中进行传输，发送 I-PDU 结构体类型 Com_TxIPduType 的设计及部分成员的含义:

　　typedef struct { const uint16 ComIPduHandleId; /* I-PDU 的标识 ID* / const Com_IPduSignalProcessingType ComIPduSignalProcessing; /* 信号的确认和指示的处理模式，直接模式和延迟模式* / const Com_IPduType ComIPduType; /* I-PDU 类型* / const Com_SignalIdType ComIPduSignalsRefNumber; /* I-PDU 所有包含信号的数量* / P2CONST( Com_SignalIdType，AUTOMATIC，COM_APPL_CONST) ComIPduSignalsRef; /* 指向此 I-PDU 所包含的信号的指针* / const uint16 ComPduIdRef; /* 底层 PDU 标识 ID* / P2CONST( Com_TxModeType，AUTOMATIC，COM_APPL_CONST) ComTxModeTrue; /* I-PDU 发送方式 TRUE 的结构体指针* / P2CONST( Com_TxModeType，AUTOMATIC，COM_APPL_CONST) ComTxModeFalse; /* I-PDU 发送方式 FALSE 的结构体指针* / …/* 省略部分参数* / } Com_TxIPduType;

　　结构体 Com_TxIPduType 定义了发送 I-PDU 传输中的参 数，其 中 ComTxModeTrue 和 ComTxModeFalse 是 COM 模块为 I-PDU 定义的两种发送方式，这两种发送方式的参数需要静态配置，根据 I-PDU 所有包含信号的 TMC 值来确定 I-PDU 发送模式选择 TMS。两种发送方式都可以定义 I-PDU 在传输时所需要的时间参数。

　　COM 模块发送信号的流程如图 4 所示。

　　通过调用 Com_SendSignal( ) 函数不会立即触发 IPDU 的传输，只是更新存储在 I-PDU 缓冲区中的信号数据，I-PDU 的发送通过 OSEK OS 实时操作系统的任务调用 Com_MainFunctionTx( ) 函数进行处理。Com_ MainFunctionTx( ) 函数会对所有需要发送的 I-PDU 进行循环判断，结合 I-PDU 的传输模式和发送中需要满足的 时 间 参 数 综 合 判 断 是 否 需 要 调 用 PduR _ ComTransmit( ) 函数传输该 I-PDU 到下层。

　　在接收数据时，下层会调用 Com_RxIndication( ) 回调函数通知 COM 模块接收到 I-PDU 数据，并将接收到的 PDU 数据信息复制到 COM 模块定义的 I-PDU 缓冲区中，更新相关的 I-PDU 属性参数。

　　上层通过 Com_ReceiveSignal( ) 函数获取存储在 COM 模块的信号缓冲区中的数据，图 5 为软件执行流程。

　　3. 2 PDU Router 模块设计

　　PDU Router( 简称 PDUR) 模块位于通信软件中间，拥有多个上层和多个下层，在 CAN 通信软件中， PDUR 模块上层为 COM 模块，下层为 CAN Interface 模块。PDUR 模块主要包括两个部分，PDU 路由表和 PDU 路由引擎。PDU 路由表静态定义了每个 I-PDU 的路由路径，根据路由表来确定 I-PDU 的上下层模块信息; PDU 路由引擎是根据 PDU 路由表进行操作的实际代码，实现 I-PDU 信息的路由传递。

　　COM 模 块 通 过 调 用 PduR _ ComTransmit ( ) 将 I-PDU传递到 PDUR 模块，PDUR 模块根据静态定义的路由表，查找 I-PDU 的目的模块，然后调用相关下层 CanIf_Transmit( ) 函数实现传输。在完成传输之后，下层调用 PduR_CanIfTxConfirmation( ) 函数通知 PDUR模块，PDUR 模块根据路由表查找上层模块信息，进而完成通知上层，此过程如图 6 所示。下层在接收到 IPDU 数据时，操作过程与发送完成的确认过程类似。

　　3. 3 CAN Interface 模块设计

　　CAN Interface( 简称 CAN IF) 模块位于 CAN Driver 层之上，提供特定的接口函数来管理 CAN 硬件。CAN IF 模块对 CAN 控制器邮箱结构进行抽象，得到硬件对象句柄( HOH) 、硬件发送句柄( HTH) 和硬件接收句柄( HRH) 。邮 箱 结 构 是 CAN 硬 件 缓 冲 区，包 含 了 CAN 帧的 ID、长度和数据等信息。HOH 定义为一个常数，表示可用的 CAN 控制器邮箱编号，定义为发送使用的是 HTH，定义为接收使用是 HRH。

　　CAN IF 模 块 CanIf _ Transmit ( ) 函 数 接 收 来 自 PDUR 模块的 I-PDU，根据传入的 I-PDU ID 获取静态配置的底层 CAN 帧信息，组包合成 CAN 协议数据单元，同硬件发送句柄 HTH 一起传递给下层发送函数进行发送，发送流程如图 7 所示。

　　当下层 Can_Write( ) 返回 CAN_BUSY 时，表明指定的硬件缓冲区没有空间，此时 CAN IF 模块将发送失败的数据存储在 CAN IF 模块定义的缓冲区，等待 CAN 硬件缓冲区空闲时进行发送。当 CAN Driver 模块成功发送报文时，会在 CAN 发送中断中调用 CanIf_ TxConfirmation( ) 通知 CAN IF 模块，此函数再调用上层回调函数通知上层发送完成，并查询 CAN IF 缓冲区是否有待发送数据，如果存在待发送数据就会请求底层传输。

　　在底层 CAN 接收中断中，会调用 CAN IF 层 CanIf _RxIndication( ) 通知 CAN IF 层接收到了数据，此函数会判断接收的数据是否需要软件过滤，并检查数据长度，然后判断是否调用上层回调函数通知上层接收到新数据。

　　3. 4 CAN Driver 模块设计

　　CAN Driver 模块是最底层的硬件驱动模块，通过操作硬件寄存器实现对硬件的控制。Can_Write( ) 是 CAN Driver 模块的发送函数，具体流程如图 8 所示。

　　当硬件邮箱空闲时正常完成发送，当在被占用情况下会返回 CAN_BUSY，CAN IF 模块会根据返回值存储没能完成发送的数据信息。

　　在 CAN 中断处理函数中，会根据中断标志位判断出现的是发送中断还是接收中断，然后调用不同的上层回调函数，完成发送确认和接收指示操作，具体流程如图 9 所示。

　　4 软件测试

　　软件测试是软件开发的重要一环，在软件设计时，需要进行功能测试和系统测试。在各模块的函数功能设计中，为函数设置不同的输入输出测试用例，来完成函数功能测试，测试结果可在编译软件中调试查看。

　　系统测试采用中央控制单元作为硬件平台。中央控制单元作为电动汽车整车控制系统的核心，兼具整车控制与远程监控功能。中央控制单元主控芯片选用了 恩 智 浦 公 司 的 ARM 内 核 32 位 微 控 制 器 MK60DN512VLQ10。测试 工 具 包 括 12 V 电 源、USB CAN 分析仪、上位机软件和 JLINK 调试工具等，软件环境为 μVision V5. 24. 2. 0。

　　在测试过程中通过在应用层定义信号，在各层配置文件中进行参数配置，并定义信号所属的 I-PDU 以及发送和接收信号的 CAN 报文 ID、帧类型、帧格式和长度等。将 PC 机与 USB CAN 分析仪和 JLINK 调试工具连接， CAN 总线波特率配置为250 kbit/s，使用编译器软件将编译好的程序下载至中央控制单元。通过 USB CAN 分析仪进行报文数据的解析，由 ECANTools 上位机软件进行显示。图10 为 ECANTools 软件 CAN 通信测试数据接收和发送界面，帧 ID 为 0x18FFFFFF 和0x18FFFFFA 是中央控制单元发出的报文，帧 ID 为 0x18FFFF0A 是 ECANTools 软件模拟其他 ECU 发送给中央控制单元的报文。经过测试验证，中央控制单元可以正常收发 CAN 报文，且数据信息和报文格式都符合预期。

　　5 结束语

　　本文根据 AUTOSAR 规范要求，完成了 AUTOSAR CAN 通信模块软件的开发，并在中央控制单元硬件平台进行测试应用。软件开发按照分层和模块化的设计思想，层与层之间隐藏设计细节，实现了解耦，能够较好提升软件复用性，为后续软件开发减少时间和成本，提高开发效率。