基于全标定CAN的TCU通讯开发*

方晓颖

上海汽车变速器有限公司 软件工程师



基于全标定CAN的TCU通讯开发*

方晓颖

上海汽车变速器有限公司 软件工程师

全标定CAN是一种全新的TCU通讯开发方式。与传统通讯开发模式相比，全标定CAN软件在开发过程中TCU供应商只负责接收和发送报文，而报文信号的打包及解包由应用层开发者负责。在此基础上，应用层拥有CAN通讯参数配置权限。即底层将CAN通讯所涉及配置的参数以标定量的形式开放给应用层，使得在更新CAN矩阵时，只需应用层编写接口函数，匹配标定参数，而TCU供应商无需重新对底层软件进行更新，从而减少了整个软件的开发周期。

CAN通讯 变速箱控制单元 全标定CAN CAN矩阵

1 引言

CAN是控制器局域网络(Controller Area Network,CAN)的简称，是由研发和生产汽车电子产品著称的德国BOSCH公司开发，并最终成为国际标准(ISO 11898)，是汽车计算机控制系统和嵌入式工业控制局域网的标准总线。TCU与整车上其它节点的通讯都是通过CAN总线来实现的，如图1所示，因此CAN通讯开发是TCU软件开发中最基础的一部分。

在TCU软件开发过程中，通常会根据实际需求不断更新CAN Matrix。由于受目前TCU供应商底层软件平台的CAN sharing模式限制，CAN Matrix的每次更新，需要底层软件供应商来完成。无论CAN Matrix修改内容多少，底层都需要进行集成，测试，整个软件开发周期较长。

图1 TCU与整车通过CAN网络通讯

为了提高CAN matrix的灵活性，减少底层软件的开发工作量， 把CAN matrix的配置，集成工作转由应用层来完成，以此减少软件开发周期，实现CAN模块的一次性开发。

2 设计概念

全标定CAN设计概念：在开发过程中TCU供应商只负责接收和发送报文，而报文信号的打包及解包由应用层开发者负责。在此基础上，应用层拥有CAN通讯参数配置权限。即底层将CAN通讯所涉及配置的参数以标定量的形式开放给应用层，使得在更新CAN matrix时，只需应用层编写接口函数，重新标定参数，而无需重新对底层软件进行更新。

应用层负责报文信号打包解包及参数配置，其中包括：

报文handle、报文ID、报文方向、报文模式、中断使能、接收/发送周期、报文数据长度、接收超时时长、延时时长、接收掩码，各报文中信号的分布结构，信号值的计算。

3 与传统CAN通讯开发的区别

基于全标定的TCU CAN通讯开发与传统模式开发的主要区别在于以下几个方面：

3.1 信号接收发送方式

传统软件中TCU上层只需接收或发送具体信号，每个信号与传输CAN报文中的解包或打包过程则由负责底层开发的TCU供应商完成。而在全标定软件中，TCU应用层直接接收CAN报文，并在此基础上，完成信号的解包或打包工作。

3.2 CAN通讯参数配置

在CAN 通讯开发中涉及到很多参数的配置定义，如报文传送方向，是接受或发送。传统软件中，这些参数由TCU供应商定义。而全标定软件中，所有与CAN通讯相关的参数由应用层通过标定来配置。

3.3 Checksum及Alive counter处理

在CAN通讯中，重要报文的发送或接收需经过checksum和alive counter校验。Alive counter可监视报文是否按时正常发送或接收。Checksum可检验报文内容是否发送正确。传统软件中，这部分的校验由TCU供应商完成。而全标定软件中，这些校验由TCU应用层开发。

由于checksum和alive counter由应用层负责校验，所以在底层发送的CAN状态信号中不再包括这两部分的信息。

3.4 CAN通讯相关的故障码分配

由于全标定软件与CAN通讯相关的功能开发全部开放给应用层，因此报文与其故障码(如，帧丢失)的对应关系也由TCU应用层分配。

4 实现方法

全标定CAN通讯功能主要通过三个方面来开发实现。首先，开发报文接收发送接口函数。其次，通过Matlab建模实现报文解包打包。最后，离线配置CAN通讯参数，如图2所示。

图2 全标定CAN实现Fig.2 Realization of free calibration CAN

4.1 报文接收发送接口函数

TCU应用层与底层CAN通讯的所有交互过程均通过接口函数实现。其中包括，报文接收，报文状态接收以及报文发送。所有报文均以byte为单位被接收或发送。

4.1.1 报文接收

TCU应用层通过调用接收函数获取报文中某一byte信息。

4.1.2 报文状态接收

TCU应用层在接收报文的同时接收报文状态来判断该报文的当前周期通讯情况。

如果状态为1，表示通讯正常，接收的报文信息有效。如果状态为0，则表示当前周期TCU并没有建立与该报文的通讯，收到的报文信息并不可靠。此时，TCU应用层需要考虑以默认值代替接收到的报文信息作为一种帧丢失的后处理。

4.1.3 报文发送

同理，TCU应用层通过调用发送函数实时发送byte信息。

4.2 报文解包打包

应用层开发者通过Matlab建模实现报文的打包解包。一帧报文有8个byte，根据解读bdc得知信号与byte的关系分为三种情况。

·一个信号占一个byte

·一个byte包含几个信号

·一个信号占几个byte

报文解包即把一个CAN信号根据以上三种情况从报文中解析出来。而报文打包，可理解为报文解包的逆过程，也分这三种情况。

4.3 CAN通讯参数配置

CAN通讯功能的实现，除完成报文的解包打包过程外，还要需定义各类属性，如通讯方向，通讯周期等。在全标定CAN软件中， 所有与CAN通讯相关参数通过离线标定方式配置。参数配置的正确与否将直接影响TCU与整车网络的通讯。如图3所示：CAN通讯配置参数如下。

图3 CAN通讯配置参数Fig.3 Parameters of CAN communication

4.3.1 报文通讯方向

CAN通讯方向属性有“接收”，“发送”和“未使用”三种。全标定CAN软件中TCU输出报文定义为“发送”，EMS, ABS等输入报文定义为“接收”，其余则定义为“未使用”。

4.3.2 中断使能

中断使能是指CAN报文在通讯过程中是否允许被中断。根据传输特性和要求，TCU的发送报文定义为“使能中断”，否则会引起收发阻塞。而TCU接收报文定义为“禁止中断”。

4.3.3 报文ID

现代基于CAN总线的汽车开发过程中，OEM会给CAN网络上所有节点发送的报文分配一个ID号。通常情况下，ID号越是小表示该报文优先级越高，所加载的信号越重要。TCU应用层根据OEM的输入，给所有接收发送的报文配置ID号，保证传输报文在整车网络中的唯一性。

4.3.4 报文模式

CAN报文传输模式有常规模式，发送复用模式，接收复用模式主报文，接收复用模式从报文等。

4.3.5 报文掩码

在CAN接收发送处理过程中，通过设置掩码可以对ID进行筛选，把它们放置在不同的mailbox里。

4.3.6 报文DLC位数

CAN标准消息报文中，数据场的字节数目由数据长度码(data length code，简称DLC)决定。TCU应用层可以根据dbc定义分别设置发送报文和接收报文的DLC位数。位数范围：0-8。

4.3.7 报文周期及接收超时

在TCU 与整车CAN通讯过程中，所有报文都是以周期形式接收或发送的。通常加载重要信息(如扭矩，转速)的报文优先级较高，发送或接收的周期较短，以保证重要信息传输的实时性。TCU应用层根据dbc定义来配置所有报文的传输周期，eg. 10 ms，20 ms。

在配置报文接收周期的同时，需定义判断报文接收超时时间。软件中定义为连续n个周期未收到某一报文，则诊断为该报文接收超时。

4.3.8 报文监测使能

所有对报文的监测都是通过该报文的使能开关控制的。开关可设置成使能报文监测或抑制报文监测。根据诊断需求，所有报文定义使能监测。

5 开发案例及测试结果

以接收报文EMS1中的发动机损耗扭矩信号为例。首先，通过接口函数实现报文各个byte的输入：

EMS1_0=CanByte(3,0)。其中(3,0)分别是EMS1这帧的通讯编号及发动机损耗扭矩在该帧中的byte位。

其次，根据dbc中CAN Matrix定义，在模型中对EMS1的各个byte进行分解。因为发动机损耗扭矩占1个byte，所以整个接收该byte信号即可。

最后进行一系列CAN通讯参数配置。

报文通讯方向：EMS1帧是EMS节点发送帧，故TCU端定义为“接收”帧。

中断使能：EMS作为接收帧，定义为“禁止中断”。

报文ID：根据整车dbc文件，定义EMS1的ID与TCU通讯编号的对应关系，即把标号为3的通讯帧定义成EMS1的ID， 0x78。

报文模式：EMS1帧定义为“常规报文”。

报文掩码：eg.所以报文都定义成0xFF。

报文DLC位数：统一定义为8。

报文周期：EMS1为高速CAN上的关键帧，根据整车要求周期定义为“10 ms”，从而保证扭矩交互的实时性。

接收超时：根据通讯协议，定义成10倍的报文周期为该帧的接收超时。

报文监测使能：诊断需求定义为“监测使能”。

测试结果如图4所示。把CAN总线上传输的报文信号通过接口文件，模型输入，转化成了TCU实际需要使用的信号。其中，

3为硬件在环设备HIL模拟的发动机损耗扭矩。

1为CAN总线上传输报文信号，即

CAN报文信号=HIL模拟EMS损耗扭矩/ factor 。

2为实际TCU内部使用的发动机损耗扭矩，即

实际TCU使用EMS损耗扭矩=CAN报文信号*factor*HIL模拟EMS损耗扭矩/-最大扭矩

图4 发动机损耗扭矩输入Fig.4 Engine loss torque input

6 结论

基于全标定CAN软件的最大优势在于其开发的便利性。无论CAN矩阵有任何更新，都无需TCU供应商对底层软件做任何更改和测试，相反，TCU应用层开发者拥有最大程度上的开发权。

但由于该开发模式仍处于起步阶段，后续可能出现的问题仍然未知。除此之外，由于应用层开发工作量增加，为确保软件产品的质量，相应的测试任务也进一步加重。这样就对软件开发和测试人员的专业要求有所提高。

综上所述，TCU通讯采用全标定CAN的模式体现出显著的优势。该开发模式在减少了软件开发周期的同时也降低了开发成本，将成为今后其他项目开发沿用的趋势。

[1] Module Documentation 2055 CAN-Configuration

[2] Module Documentation 2062 CAN message monitoring

[3] Module Documentation 2055 CAN_IFC

[4] Free_Calibration_CAN_Instruction_20140304

[5] 罗 峰,孙泽昌.汽车CAN总线系统原理、设计与应用

The Development of TCU Communication Based on Free Calibration CAN

FangXiaoying

(ShanghaiAutomobileGearWorks,Shanghai201800,China)

Free calibration CAN is a new development mode of TCU communication. Compared with traditional mode, in this new development TCU supplier is only responsible for the transmission of CAN frame, while TCU application layer implement packing and unpacking of CAN frame. Besides, TCU application developer have the overall right to calibrate the parameter which related to the CAN communication. Moreover, When the CAN matrix is updated, TCU application developer just need to modify the interface, and calibrate the parameter. No platform software need to be changed by TCU supplier. Then considerable development time will be saved.

CAN communication TCU Free Calibration CAN CAN Matrix

1006-8244(2015)02-031-04

* 该项目得到了上海市科学技术委员会的资助，资助课题编号为“13DZ225044(上海市汽车变速器工程技术研究中心)”

文献标识码：