CCP(中文).doc
《CCP(中文).doc》由会员分享,可在线阅读,更多相关《CCP(中文).doc(8页珍藏版)》请在冰点文库上搜索。
1导言
1.1ASAP
ASAP规则(校准系统标准化规则)成立于AudiAG,BWMAG,Mercedes-BenzAG,PorscheAG和VolkswagenAG公司。
欧洲的汽车工业测试与改进系统的汽车制造商和电子控制制造商都已经加入了这个标准。
世界汽车技术已经进入了复杂电子系统结构来满足不断增加的排气限制、环境污染保护,安全系统,驾驶性能和车身设备选择的法律规定要求。
一些汽车制造商通过网络使用了车辆分配控制系统。
为了改进这个新的电子汽车时代,高新的复杂软件,标定、测量与诊断仪器已经被运用。
但此刻,对于这些设备几乎已经没有一个软件接口的标准了,每家公司都有自己独立的系统和接口来支持这些高新的构造。
因此,ASAP的任务是要实现共同的协议和标准在:
¨所有用于测量,标定和诊断的设备的自动控制,模块化和兼容性。
¨管理一个消耗合理的,可预测的设备供应市场。
1.2CAN标定协议(CCP)
控制器局域网CAN是RobertBoschGmbH与Intel公司的共同的成果。
CAN用于许多汽车控制系统如发动机控制,以及工业控制系统。
各半导体制造商都有能力提供CAN控制芯片。
CAN标定协议时ASAP标准的一部分。
它被IngenieurburoHelmutKleinknecht(一个标定系统的制作者)改进和引用。
它被用于汽车工业的一些应用程序之中。
ASAP工作组采纳CCP并扩展其可选的功能。
2、应用范围和领域
这文件根据包含ASAP在内的工作小组的定义,详细说明CCP协议。
CCP定义了带有主设备的控制器的通信协议采用CAN2.0B(11-bit和29-bit标示符),它包含了2.0A(11-bit标示符),来进行:
1.从控制器获得数据
2.存储器转移和控制其用于标定的功能程序
提供这些功能的CCP可以用于这些领域
¨改进ECU
¨ECU的功能和外围测试的系统
¨控制设备的系统测试和持久性测试。
¨汽车在线测试和测量系统
¨任何基于CAN的电子分配控制系统的非汽车应用程序
3、相关文件
Intel公司的说明文件和数据表
82527系列的通信控制器数据(Intel#272250)
82527系列的通信控制器构架概述(Intel#272410)
控制器局域网协议导论(Intel#270962)
4、修正记录
修订
日期
更改项
注释
1.0
30-09-1992
从IngenieurburoHelmutKleinknecht最初建立
1.01b
07-12-1995
工作草稿,增加以下可选指令
-EXCHANGE_ID
-GET_SEED
-UNLOCK
-GET_DAQ_SIZE
-SET_DAQ_PTR
-WRITE_DAQ
-ACTION_SERVICE
还有返回/错误代码
-Keyrequset
-Sessionstatusrequset
-Coldstartrequest
-Cal.Dataint.request
-DAQlistinit.Request
-codeupdaterequest
-accesslocked
ASAP工作小组
1.02
26-04-1996
-解释DAQ表
-扩展描述incl.例子
-增加MOVE指令
-增加PROGRAM指令
ASAP工作小组讨论起草
2.0
14-06-1996
-删除STORE_CYCLE指令
-增加DNLOAD_6指令
-增加PROGRAM_6指令
-增加BUILD_CHKSUM里的块大小
-增加CLEAR_MEMORY的存储器大小
-返回信息GET_DAQ_SIZE
-BUILD_CHKSUM的超时
ASAP工作小组会议结果。
文件状态:
发布
Prop.2.01
16-03-1998
指令修改
EXCHANGE_ID
GET_SEED
START_STOP:
Evt.Chnl,Prescaler
BUILD_CHECKSUM:
size
指令增加
TEST
GET_CCP_VERSION
GET_ACT_CAL_PAGE
START_STOP_ALL
删除项:
WCOWakeUp/ConnectObject
ASAP工作小组讨论起草
文件状态:
草稿
Draft2.1
23-06-1998
增加Versionmechanism章节
增加Versioncompatibility章节
DOWNLOAD6可选
SHORTUP可选
增加MatrixofErrorCodes附录
ASAP工作小组会议结果。
文件状态:
草稿
2.1
18-02-1999
Prop.201和Draft2.1的所有修改有效
文件状态:
发布/出版
5、定义和缩写
CAN
ControllerAreaNetwork:
RobertBoschGmbH所改进和持有的通信协议(ISO/OSI模型等级1+2)。
这协议是设计来管理多CPU间的多元化通信。
它控制信息的方向,使用不可破坏的位结构来确定哪个节点拥有总线并且拥有一个基于与每个消息一起发送的标示符值的消息发送优先级分配器。
CCP
CANCalibrationProtocol:
IngenieurburoHelmutKleinknecht改进和ASAP采用的作为数据获取和标定的标准协议。
CRO
CommandReceiveObject:
消息从主设备发送到从设备
CRM
CommandReturnMessage:
一种由从设备发送给主设备的信息,它包含命令/错误代码和命令计数器
DAQ
DataAcquistion:
一个程序和为了从ECU快速获取数据,由从设备发送给主设备的消息的定义。
DTO
DataTransmissionObject:
从从设备发送给主设备的消息(命令返回消息或事件消息或数据获取消息)
ECU
ElectronicControlUnit:
一个带有中央处理器,使用其外围电路执行给定的功能函数的电子设备。
MessageObject
在CAN总线上传输的消息,它从一个发送ECU发送到接收/监听ECU。
接收ECU知道接收信息中包含的数据编码。
一个信息体的数据可为0到8字节。
MessageFrame
MssageFrame在最新的关于CAN文献中与MessageObject相同。
Masterandslavedevices
一组通过CAN交换信息体的控制器。
另外,外部的连接网络的控制器,它与1个或多个控制器通信并且向它们发送数据,这里被称为主设备。
在网络中接收命令的控制器被称为从设备。
ODT
ObjectDescriptorTable:
元素(变量)表,用来组成数据获取。
6、协议定义
用来进行标定和数据获取的CCP协议时一个主从型的通信协议。
一个主设备在CAN总线上连接1个或多个从设备。
主从设备结构
主设备是一个标定设备或一个诊断/监控设备或是一个测量系统,通过发送命令到从设备,初始化在CAN总线上传输的数据。
CCP的执行支持命令来控制存储器的数据转移和读取。
这通信协议的双方是独立的,并且可以不同步的运行,这由从设备控制器中的执行器决定。
双方的消息以嵌套的方式传输时可能的。
6.1一般控制指令
指令是用来执行从设备中的功能函数。
为了达到这一目的,建立了在主从设备之间的一个持续的逻辑连接。
这个逻辑连接直到其他从设备被选中或当前从设备明确的发出断开连接指令是才断开连接。
完成初始化逻辑连接之后,主从设备间的数据传输由主设备来控制。
所有主设备发出的指令都必须得到从设备返回的握手信息(命令返回代码或错误代码)。
6.2数据获取指令
这协议指令是用来持续的从从设备中获取数据。
每个CAN节点都可以周期的发送根据主设备命令而制作的响应表所对应的数据。
数据传输由主设备开始,从设备执行,按照一个预定的采样频率或是事件触发。
7消息帧
7.1消息帧组成
根据CAN协议的定义,所有要传输的信息和数据都要封装为消息帧,它包括8字节的数据。
消息帧是从一个CAN节点到另一个CAN节点。
CCP要求至少有两个消息帧,每个传输方向一个:
1)指令接收帧CRO
2)数据传输帧DTO
CRO是用来给接收方接收指令代码和传递参数来执行内部的功能函数或与逻辑连接的CAN设备之间进行数据传输。
指令的接收方要用数据传输帧格式来回应握手消息,在这情况下,DTO被称为指令返回消息。
DTO消息返回的代码是用来判断相应的指令是否成功完成。
功能图表:
在CCP主从设备间的传输流
上文描述的消息标识符的分配是在从设备描述文件中定义的,它是用来配置主设备。
建议认真考虑消息帧的总线优先级,避免破坏其他总线上的实时通信。
而且,CRO应该拥有比DTO更高的优先级。
对于所有用CCP传输的数据,字节顺序在CCP协议本身是没有定义。
因为数据结构是倚靠ECU的CPU决定的,字节顺序是在从设备的描述文件中定义。
但在TEST,CONNECT和DISCONNECT指令中的站地址时例外的。
7.2消息帧描述
7.2.1指令接收帧CRO
CRO是从主设备发送给从设备。
从设备以含有指令返回消息CRM的数据传输帧DTO来应答。
帧结构:
类型
只读
大小
8个消息区字节
目的
从设备接收指令
消息域的参数
位置
类型
描述
0
Byte
指令代码
1
Byte
指令计数器
2…..7
Byte
指令相关的参数和数据区
CRO的数据代码长度必须是8。
在指令描述区,不用的字节标注为无关字节,,它可以为任意值。
7.2.2数据传输帧DTO
DTO必须以数据流的形式承载所有的从设备的消息和数据。
数据流第一个字节(DTO的第一个字节位)用来作为存放数据流的ID。
DTO:
¨命令返回消息CRM,如果DTO是作为从主设备的CRO的回应。
¨事件消息如果DTO反应从设备内部状态变化,为了调用错误恢复或其他服务
¨数据获取消息如果存放数据流的ID是指向一个相应的帧描述表,它描述数据获取元素是包含在数据流的剩下7个数据字节上。
ODT是通过协议指令来初始化和改变的
帧结构
类型
Tx(和远程发送请求接收)
Size
8个消息区字节
目的
指令返回消息或事件消息或数据获取消息
消息域的参数
位置
类型
描述
0
Byte
数据流ID=PID
1
Byte
数据流
PID的含义
PID
解释
注意
0xFF
DOT包含指令返回消息
0xFE
DOT包含事件消息
CTR不起作用
0<=n<=0xFD
DOT包含与ODTn相关的数据获取消息
参阅章节“指令描述”
指令返回和消息返回用以下格式:
EER:
指令返回-/错误代码
CTR:
指令计数器,与最近的接收的CRO指令中的相同
CRM的数据代码长度必须是8。
在指令描述区,不用的字节标注为无关字节,,它可以为任意值。
数据获取信息格式如下:
PID=n;DOT包含与ODTn表(参考“指令描述”)相关的数据获取消息
DTO的数据长度的代码可设为真实值。
7.3数据获取结构
主设备可以从从设备接进行数据获取收初始化,它以在DAQ-DTOs中所定义的数据作为返回。
这个数据元素的结构如下:
位于ECU的存储器中的数据元素被分配到一个叫帧描述表。
这个表包含了地址,地址扩展名和每个元素的长度字节。
ODT可以包含最多为7个元素
在ODT中定义的每个元素的内容必须转化为DAQMessageDTO来发送给主设备。
为了节省ECU内的存储器资源,地址扩展和长度都是可选的。
ECU对元素的采样必须保持一致性。
如果一个ECU不支持一个大小大于1位的元素,主设备要将多字节分成几个单字节。
在这情况下,ECU必须保证在一个ODT中所有元素的连贯性。
PID是分配给ODT的序号(0<=n<=0xFD)。
典型的,几个ODT是为了向从设备获取数据而定义。
CCP允许建立许多许多个DAQ表,他们可以同时被激活。
在ECU中,每个DAQ表的DTO的的采样和发送是被独立的事件触发的。
请看START_STOP命令的描述。
当一个DAQ表被触发时,一个或多个ODT(由ECU执行所决定)的数据会被以相同的速率采样。
ECU需要一些时间来发送采好样的DTO消息到总线上。
当在前一个事件周期的发送任务完成之前一个新的事件周期被触发,ECU会有2种可能反应
1)前一个周期的发送任务被跳过
优点:
有一些DAQ表的ODT会丢失,工具会显示这信息给用户
问题:
如果这些丢失频繁发生,会有一些信号无法测量。
2)新周期的发送任务被跳过
优点:
收到的样品总是完整的,使得获得光栅减少。
问题:
在事件触发采样的情况下,这个工具不能检验接收率是否合理。
另外,ECU可能会发送一个”DAQ处理器过载”的消息来通知主设备。
ECU必须小心不能用这个额外的消息来超出另一个周期。
当在ECU内定义了测试的成分,开发者须小心,已采样的数据可以通过CAN发送。
对过载响应的机器描述,不应该在标准状态下使用。
一个典型的对一个ODT的设置是:
1.清楚当前ECU的列表,让ECU发送GET_DAQ_SIZE指令来为一个DAQ分配内存。
根据GET_DAQ_SIZE指令,ECU向当前DAQ表中的ODTs汇报可用内存。
2.在发送环节
SET_DAQ_PTR包含参数有:
DAQ表数目,ODT数目,ODT中元素的数目
WRITE_DAQ包含参数有:
元素大小,扩展地址,32位基地址直到ODT完成和为以后的ODTs重复操作
为了初始化DAQ-DTOs发送,发布了START_STOP指令。