基于CCP协议利用CANape进行电控单元标定

分享到:

        采用基于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标定程序接口

继续阅读
恩智浦与华邦达成合作意向,新型Flash存储产品发挥重要作用

华邦和恩智浦成功达成合作,在3月11日和14日分别于深圳和上海举办的2019华邦-恩智浦Workshop上,恩智浦展示了一款集成了华邦2MB/4MB Flash的LPC54S018JxM系列MCU产品,该系列是LPC540xx系列MCU的扩展,主要针对物联网终端市场,便于用户快速将产品推向市场。该产品不仅提供片上SPI NOR Flash,而且其独特OTP功能可以灵活定制保护区块,其他闪存空间仍能保持正常擦写功能。

还要手动碎片整理?那已经过时了!

必须手动进行碎片整理(defrag)的年代已经过去了,因为现在都是自动执行的,而且,闪存(flash)并不会出现“档案碎片”(file fragmentation)问题。真是这样吗?

LPC546xx系列MCU简介

LPC546xx系列MCU基于Cortex-M4内核而构建,具有极高的灵活性和性能可扩展性,可提供高达180MH主频的性能,同时保持低达100uA/MHz的功率效率;其21个通信接口使其成为下一代IoT应用的HMI和连接需求的理想选择。

Flash技术将退役?新技术代替在即

Adobe与其合作伙伴苹果公司、微软、Alphabet旗下谷歌部门、Facebook和Mozilla称,在未来三年时间里,这些公司将分阶段停止为Flash提供技术支持。在2020年过后,Adobe将停止为Flash发布更新,网络浏览器将不再支持该技术。这些公司正在鼓励开发者为其软件改用现代编程标准。

车窗控制系统的LIN2.1协议应用

引言 LIN协会于1999年发布了第一版LIN协议,至今已有十几年了,在这十几年中,LIN总线不断发展,已经在以车身控制为主的许多场合得到了应用。LIN总线至今一共有7个版本,其中,LIN2.1协议

精彩活动