利用CANape进行基于CCP的汽车控制器的匹配标定的设计

摘　要：采用基于CAN总线的匹配标定协议,对汽车控制器局域网络中的电子控制单元进行匹配标定。分析了CCP协议用于标定的工作机理,讨论了利用CANape进行基于CCP标定的实现方法,阐述了如何生成CANape与控制器底层程序的软件接口及具体标定流程。实际应用结果表明,这种方法可以快速有效地实现对汽车网络中各控制器的匹配标定。

目前基于CAN(Controller Area Network)总线的分布式系统在汽车电子领域得到广泛应用,电子控制单元的标定已成为汽车电子控制装置开发的一个重要环节。CCP(CAN Calibration Protocol)是一种基于CAN总线的ECU(Electronic Control Unit)标定协议[1],已经在许多欧美汽车厂商得到应用,采用CCP协议可以快速而有效地实现对汽车电控单元的标定。

然而基于CCP协议的标定,需要在ECU内部实现支持CCP协议的驱动程序(CCP driver)。目前大多数应用都采用Vector提供的free CCP driver[2]。考虑到ECU底层程序与CAN驱动程序的实现各不相同,将CCP驱动程序结合到ECU中[3]并不是一件一蹴而就的事,这需要对CCP协议本身、标定工具及标定工具与ECU之间的通信有详细和深入的了解。在整个标定系统的开发过程中,大量时间被耗费在前期CCP驱动程序与ECU结合上。本文在简单介绍CCP协议的基础上,提供了一个通用的ECU与CCP驱动程序结合的实例,以帮助缩短整个标定开发周期。

CANape[4]是一款ECU标定和测试工具。与CCP协议相结合,不仅能完成对ECU的标定,同时还能在ECU运行期间直接访问内存并进行操作。这使得CANape不仅是一款功能强大的标定工具,也是一款电控单元开发的得力助手。然而在使用方面,CANape的前期配置比较繁琐,目前国内的相关资料较少。本文将介绍CANape,并着眼于如何基于CCP协议使用CANape完成ECU的标定。

1 CCP协议及工作原理

CCP协议是ASAP(Arbeitskreis zur Standardisierung von Applikationssystemen)标志的有机组成部分。ASAP作为一个应用系统标准化工作小组,其目的在于提供通用软、硬件接口标准,以解决由于不同制造商提供的控制器存在的接口不匹配问题。

1.1 CCP通信方式

基于CCP协议的ECU标定采用主-从通信方式,如图1。主设备通过CAN总线与多个从设备相连,其中主设备是测量标定系统MCS(Measurement Calibration System),从设备是需要标定的ECU,在汽车电子中即为车载控制器。

图1 CCP通信方式

根据CCP协议,主设备首先与其中一个从设备建立逻辑链接,然后通过主设备向从设备发送命令来起始两者间的数据通信。当主设备要访问另一个从设备时,首先断开与当前从设备的逻辑连接,与下一个从设备建立新的逻辑连接后再开始通信。

1.2 CCP协议的工作模式

CCP定义了两种工作模式:Polling(查询)模式及DAQ(Data Acquisition Command)模式。查询模式下,主设备与从设备间的每一次通信都由主设备发送命令来起始,从设备收到主设备的命令后,执行相应的操作并反馈一帧报文。这种工作模式由于需要主机与从机之间进行“一问一答”的信息交互,工作效率不高,但实现简单,而且占用ECU内存资源较小。 DAQ模式使从设备可以脱离主设备的命令控制按一定周期自动向主设备上传数据。DAQ模式下,主设备首先发送一条请求DAQ的命令,从设备收到后,按命令中的参数自行配置并组织需要上传的数据,然后按一定周期自主向主设备上传数据。这种模式由于不需要主机通过命令逐步控制,工作效率高,但实现较复杂,如果需要上传的数据量很大,会占用大量ECU内存空间。

1.3 CCP报文帧结构

基于CCP协议的标定只占用两帧CAN报文,分别是命令接收对象CRO(Command Receive Object)和数据传输对象DTO(Data Transmission Object),如图2所示。CRO由主设备发给从设备,DTO是从设备反馈的报文。两者分别通过一个自己的ID标识符进行标识(CRO_ID与DTO_ID)。

图2 CCP协议主、从设备通信

CRO与DTO的ID标识符由通信协议自行定义,CCP协议只对CRO及DTO的数据场做了详细定义。按照CCP协议,CRO数据场的第1个字节为命令代码CMD(Command Code),CCP协议共规定了28条命令[1]。从设备通过CMD代码判断主设备请求的是哪条命令。数据场的第2个字节是命令计数器CTR(Command Counter)。剩余6个字节均为命令参数,每条命令有各自对应的命令参数。

从设备反馈的报文称为DTO。按CCP协议,DTO又细分为三类:

·命令返回消息CRM(Command Return Message):由从设备发送,针对CRO的反馈报文。

·事件消息(Event Message):当从设备检测到内部发生错误机制时,由从设备自行向主设备发送,报告其当前的运行状态,并请求主设备暂停当前工作进程以处理发生的错误。

·DAQ-DTO(Data Acquisition-DTO):用在DAQ模式中,由从设备组织,定期向主设备发送。

DTO报文的第1个字节PID(Packet ID)定义了DTO的类型,255代表CRM, 254代表事件消息。第2个字节为命令返回/错误代码ERR(Command Return-/Error Code)。对于CRM,主设备由该字节获知命令的执行情况;对于事件消息,主设备由该位获知从设备内部发生了哪种错误。第3字节CTR是命令计数器,该位数值与其对应的CRO的CTR值相对应。剩余5个字节是数据场,存放主设备请求的数据或信息。

2 基于CCP协议的接口程序实现

基于CCP协议进行标定,需要MCS与ECU的应用程序都能够支持CCP协议,这部分应用程序称为CCP driver。本文采用Vector提供的free CCP driver[2]。由于CCP协议基于CAN总线,因此CCP driver与ECU的结合主要分为与CAN driver及与其他应用程序两方面。

CCP driver与CAN driver的结合如图3,主要分为以下两方面:

图3 CCP标定程序接口

·发送端:DTO通过CAN driver的发送子函数以CAN报文的格式上传给MCS。

·接收端:主设备发送的命令以CAN报文的格式首先进入CAN driver的接收子函数,由其判断为CRO后,进一步交给命令处理器处理。

命令处理器作为CCP driver的一个主要组成部分,负责将接收到的CRO,通过其CRM代码进行命令解释,执行相应操作,组织反馈数据并调用CAN发送子函数。DAQ处理器支持DAQ工作模式,当命令处理器判断收到的命令为DAQ请求后,进一步将数据传给DAQ处理器,由DAQ处理器组织数据并直接调用CAN 发送子函数,以DAQ-DTO的形式定期向主设备上传。

基于CCP协议的基本CAN通信流程如图4所示。ECU接收到报文后,转入CAN接收子函数,在常规接收流程后,对报文的ID标识符进行判断,如为CRO_ID,则将CCP标志位(Ccp_indicator)置位。由于采用中断方式接收报文,为了避免占用过多中断时间而影响其他函数或中断级别较低的程序运行,在对ID标识符进行判断后,并不直接在函数中调用CCP driver的命令处理器。命令处理器的调用会在主函数中进行。

图4 接口程序基本流程图

主函数通过判断标志位的状态,调用CCP driver的ccpCommand()子函数。该函数是命令处理器的主要组成部分,也是命令处理器与CAN driver的接口函数,它负责解释并执行收到的CRO命令,调用CCP driver中的其他函数,进行数据处理并组织需要反馈的数据。

ccpCommand()通过调用CAN driver中的CCP发送子函数ccpSend()发送一帧DTO。ccpSend()须在CAN driver中实现,由CCP driver调用。按实际情况,将CAN发送子函数直接以ccpSend()的形式实现,或在保留原有发送子函数的基础上添加一个ccpSend()子函数,在其中调用CAN发送子函数,以完成DTO的发送。

CCP协议为确保主设备与ECU之间正常通信,每次发送后,程序必须通过调用CCP driver中的ccpSendCallback()子函数检查刚才的DTO是否已经发送,否则不能发送下一帧报文。针对不同的CAN driver实现,该函数调用的位置不同。最后主函数将CCP标志位清空,等待下一条CRO命令。

一个完整的CCP driver 接口还包括与ECU其他应用程序的接口。每次单片机初始化后,主函数调用一次CCP driver的CCP初始化子函数ccpInit(),将上次标定残留在ECU内存中的数据清空,为下次标定与测量做准备。

CCP协议共定义了28条命令,每条命令在CCP driver中都对应一组相应的子函数,代表不同的功能,如EEPROM标定、DAQ工作模式等。用户可根据实际需要,选择实现其中部分或全部功能。每增加一个新的功能,必须在底层程序中添加开放该项功能的程序接口[3]。如对EEPROM标定,首先ECU应用程序中应包含EEPROM模块子函数,同时还需实现命令处理器与EEPROM模块之间的调用接口。

3 利用CANape实现基于CCP的标定

CANape[4]是德国Vector公司出品的一款基于ASAP标准的ECU测试和标定工具。它通过一个控制器硬件接口与ECU相连,两者之间常用的物理连接是基于CCP协议的CAN总线。只有控制器的底层程序中有支持CCP协议的程序接口, CANape才能与控制器通信。

CANape提供了多种功能:在线数据评估、离线评估、数据管理、FLASH编程、参数标定及ASAP2数据编辑器等。此外,测试过程中由CAN总线上传的数据还可以通过CANape在计算机显示和保存,以进行离线标定和数据评估。

3.1 ASAP2控制器描述文件及ASAP2编辑器

CANape与控制器间的通信需要一个描述文件支持,这个文件称为ASAP2控制器描述文件[4]。CANape对控制器的参数标定和数据测量都是基于这个文件,该文件记录了控制器中各参数的详细信息,如标定参数和测量变量在控制器中的存储地址、存储结构、数据类型和转换公式等。在CANape中,每个标定参数和测量数据都会有一个变量名,如发动机温度、冷却水温度。当CANape需要访问某个变量,就在ASAP2描述文件中根据变量名,找到该变量在控制器中的存储地址、数据长度等信息,然后进行操作,如图5。

图5 ASAP2控制器描述文件

为了方便用户对ASAP2文件进行维护和修改,CANape集成了一个ASAP2数据库编辑器,用以生成和修改ASAP2控制器描述文件。所有的信息都能通过对话框的形式进行设置和修改。该数据库编辑器还能工作在独立模式下,以生成一个ASAP2格式的控制器描述文件。

当ECU底层程序修改后,一些标定参数和测量数据的内存地址可能发生变动,CANape虽然仍能进行标定,但修改的已不是原来需要标定的参数,而是程序变动后原先地址下当前存放的某个新的未知数据。为了简化手工修改地址的繁琐,防止因为随意修改某个数据而破坏程序的正常运行,CANape支持通过linker map文件自动更新ASAP2文件里的信息。Map文件是ECU底层程序在编译时由编译器生成的一种映射文件,通过Map文件可以自动更新ASAP2文件。

3.2 CANape使用配置

每个需要标定的ECU都要在CANape中进行配置。

CANape共定义了28条命令,用以实现不同的功能,在配置页面里均有复选框与其对应。控制器的配置必须与CCP Driver在ECU底层程序的具体实现相匹配,只有对某个功能的程序接口已经开放,才能在CANape中选择使用该项功能[2][5]。

3.3 CANape中的参数标定

在CANape中,需要标定的变量称为标定参数,CANape将标定定义为修改驻扎在ECU内存中的变量的内容。CANape支持多种标定方法。这里标定方法指如何对标定参数所在的内存区域进行初始化、数据改写及保存。根据标定参数所在不同地址空间(ROM、FLASH或EEPROM),CANape规定了不同的标定方法。

当标定参数需要存放在FLASH或ROM中时,在ECU上电初始化后,程序首先将标定参数的初始值复制到RAM中,在CANape中该段用来存放标定参数的RAM称为Calibration RAM。标定过程中,CANape修改Calibration RAM中的参数值。标定全部结束后,再将该段RAM中的内容复制回FLASH或ROM中。

当标定参数存放在EEPROM中,有两种标定方法。第一种与上述方法相同,首先将标定参数复制到RAM中,标定结束后再将RAM中的数据覆盖到EEPROM。此外,也可对EEPROM中的参数直接进行改写,实现这种方法需要对EEPROM进行频繁擦写操作,但不占用额外的RAM空间。

由于汽车电子网络系统已开始得到广泛的使用,基于网络连接的电子控制单元的匹配标定和传统的匹配标定方法已有了很大的不同,特别是基于CAN总线的匹配标定技术,目前已成为研究和应用的重点。

采用CANape进行基于CCP的匹配标定,实现了标定工具和内容的统一。根据这种方法能够快速有效地进行汽车电子控制单元的匹配标定,在实际开发应用中取得了良好的效果。