目前基于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)模式。查询模式下,主设备与从设备间的每一次通信都由主设备发送命令来起始,从设备收到主设备的命令后,执行相应的操作并反馈一帧报文。这种工作模式由于需要主机与从机之间进行“一问一答”的信息交互www.cechina.cn,工作效率不高www.cechina.cn,但实现简单,而且占用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