摘　要：采用基于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模块之间的调用接口。

[1] [2] [3]  下一页