CCP标定协议

一.ASAP标准及ASAM标准组织
-1.1.ASAP标准概述
-1.2.ASAM标准组织及其规范
二.CCP协议介绍
-2.1.CCP通信方式
-2.2.CCP消息格式
-2.3.DAQ模式下的数据通信
-2.4.CCP命令代码简介
-2.5.ERR代码列表
-2.6.预期运行性能
三.CCP基础命令
-3.1.连接命令(CONNECT)
-3.2.获取CCP协议版本
-3.3.交换站标识符
-3.4.设置MTA地址(SET_MTA)
-3.5.数据下载(DNLOAD)
-3.6.数据上传(UPLOAD)
-3.7.获取DAQ列表大小
-3.8.设置DAQ列表指针
-3.9.写入DAQ列表
-3.10.开始/终止数据上传
-3.11.断开(DISCONNECT)
四.CCP可选命令
五.CCP应用示例
-5.1.一个简单的CCP通信示例
-5.2.如何深入理解CCP
六.CCP驱动代码结构
回到顶部

# CCP标定协议

在嵌入式电控与工业自动化领域中，电子控制单元（Electronic Control Unit，ECU）得到了广泛的应用。为了保证ECU的稳定运行，在研发以及生产阶段会对ECU进行测量与标定，根据控制策略要求，监控ECU内部参数，调整数值观测运行结果，直到将参数调整至最优状态。

在早期行业内并未存在标定协议的标准规范，ECU制造商为自家设备自定义设计了标定与测量设备的规范。即便各个ECU都会在出厂前进行测量标定，但是在整车调试中，仍旧需要修改部分ECU的内部参数，使运行结果达到最佳状态。然而，在标定过程中需要与该ECU的供应商的电子设备匹配接口和通信，再进行标定，过多的ECU导致现场存在着几种甚至数十种标定设备，极度混乱。

在1991年，几家德国汽车制造商联手一些著名的汽车电子设备制造商成立了ASAP标准组织，ASAP标准使得汽车电子设备在研发过程中的相关测量、标定、诊断方法以及使用的标定设备和接口能够兼容并互换。

## 一.ASAP标准及ASAM标准组织<a name="ASAP标准及ASAM标准组织"></a>

### 1.1.ASAP标准概述<a name="ASAP标准概述"></a>

ASAP标准由三个部分组成，分别是ASAP1、ASAP2和ASAP3，如图1.1-1所示。

![](images/2022-11-28-09-02-35.png)

<center>图1.1-1 ASAP标准</center>

- ASAP3是应用系统，即测量、标定、诊断系统MCD（Measurement，Calibration，Diagnostic）到自动化系统的接口规范。

- ASAP2又称为ASAP描述文件，是ECU内部数据描述文件的规范。用来具体描述ECU内部的数据信息，包括数据存储的地址，数据长度、数据类型等。

- ASAP1是ECU到MCD系统的接口规范，又可细分为ASAP1b与ASAP1a。

- ASAP1b接口包括一个符合ASAP标准的驱动程序、硬件接口及ECU，该接口规范保证了MCD与ECU之间的通信，不受所选通信媒介及不同ECU供应商的限制，如图1.1-2所示。

- ASAP1a是到ECU端的数据通信的物理及逻辑接口规范，例如通过CAN总线对ECU进行标定的协议规范。

![](images/2022-11-28-09-14-51.png)

### 1.2.ASAM标准组织及其规范<a name="ASAM标准组织及其规范"></a>

1998年ASAM小组成立，其英文全称是Association for Standardization of Automation
and Measuring System（自动化及测量系统标准化小组）。

ASAM标准是ASAP标准的扩展和衍生，在新的ASAM标准中，ASAP标准变名为ASAM MCD（ASAM Measurement, Calibration ,  Diagnosis），原来的ASAP1、ASAP2、ASPA3规范在新的标准下分别为ASAM-MCD1MC、ASAM-MCD2MC及ASAM-MCD3MC。

## 二.CCP协议介绍<a name="CCP协议介绍"></a>

CCP的全称是CAN Calibration Protocol（CAN标定协议），属于ASAP1a规范标准，基于CAN总线的ECU标定协议规范。CCP协议遵从CAN2.0B通信规范，支持标准帧与扩展帧。

### 2.1.CCP通信方式<a name="CCP通信方式"></a>

CCP协议采用主从通信方式，如图2.1-1所示，其中主设备是ASAP标准中的MCD系统，从设备是需要标定的ECU。根据CCP协议，一个主设备可通过CAN总线与多个从设备相连，每个从设备均有其特定地址。主设备通过每个ECU的地址，与其建立一对一的关系，在某一时刻只能有一个从设备能与主设备建立连接并进行通信。

![](images/2022-11-28-09-20-30.png)

<center>
图2.1-1 CCP通信方式
</center>

如图2.1-1所示，当主设备需要与从设备3进行通信时，主设备需要按照ECU3的地址与其建立一对一的逻辑连接，随后才能开始通信，此后主设备发出的每一条命令只有从设备3会响应。当主设备需要结束通信，或者与另一个ECU进行通信时，必须先断开与ECU3的逻辑连接，再与下一个从设备建立逻辑连接，开始通信。

CCP协议中MCD与ECU的通信又可具体分为Polling模式和DAQ模式。

1. Polling模式

该模式可以理解成一问一答的通信方式，主设备发问，从设备回答，以此来实现主从设备间的通信与数据交互。在该模式下，当主设备与某个从设备建立逻辑连接后，主从设备之间的每次通信都是由主设备首先发送一帧报文作为请求命令，从设备收到命令后，执行相应操作，或者读取某个参数值，并且返回一帧报文，向主设备提供数据或者命令执行的情况。这种通信方式实现起来比较简单，占用ECU内存资源少，但效率较低。

2. DAQ模式

其英文全称为Data Acquisition Mode。不同于Polling模式的一问一答机制，DAQ模式下从设备将按设定好的通信周期自主向主设备上传数据。这种方式数据上传效率高，但实现起来比较复杂，尤其需要上传大量数据时，会占用ECU较多RAM空间。

### 2.2.CCP消息格式<a name="CCP消息格式"></a>

CCP协议是基于CAN2.0B开发的，因此基于CCP的通信都是以CAN报文的形式来实现。CCP消息统一采用8个字节的数据场，所有命令参数及监测数据都被打包在8个字节数据场中。CCP支持11位ID的标准帧或29位ID的扩展帧。
CCP协议的实现只依赖两则CAN消息：命令接收对象CRO(Command Receive Object)和数据传输对象DTO(Data Transmission Object)，如图2.2-1所示。

![](images/2022-11-28-09-24-59.png)

<center>
图2.2-1 CCP消息对象
</center>

**命令接收对象CRO**

命令接收对象(CRO)是主设备向ECU发送的消息对象，数据场长度固定为8个字节，包括命令代码及命令参数，CRO消息对象的结构。

| 位置     | 字节0      | 字节1      | 字节2~7 |
| ------ | -------- | -------- | ----- |
| **定义** | 命令代码=CMD | 命令序号=CTR | 命令参数域 |

- 命令代码(Command Code，CMD)，CCP协议共规定了28条命令，从设备接收到CRO后，通过相应CMD代码解释收到的命令并执行。

- 命令序号(Command Counter，CTR)，CRO命令发送的序号，按发送的先后顺序排序01，02，03，依次类推。

- 命令参数域，包含了不同命令代码所需的命令参数。

CTR序号是CCP协议的一种通信保护机制，在Polling模式中，每条CRO消息与其对应的反馈DTO消息，两者的CTR序号相同，保证主，从设备一问一答的对应关系。

**数据传输对象DTO**

数据传输对象(DTO)是从设备反馈给主设备的消息。按DTO的不同用途，DTO又分为命令返回消息、事件消息、DAQ-DTO三类：

1. 命令返回消息CRM-DTO(Command Return Message)

该命令发生在Polling通信模式下，当主设备发送一则CRO消息后，从设备必须反馈一则DTO，称为CRM-DTO，数据结构与事件消息相同。

2. 事件消息(Event Message-DTO):

不需要实现收到主设备的CRO，ECU内部一旦发生错误，将自动向主设备发送一则事件消息，报告内部发生的情况，请求主设备暂停当前工作并进行处理。数据结构如下所示。

| 位置     | 字节0     | 字节1      | 字节2      | 字节3~7 |
   | ------ | ------- | -------- | -------- | ----- |
   | **定义** | 标识符=PID | 错误代码=ERR | 命令序号=CTR | 参数数据域 |

- PID：用来标识DTO的类型，0xFF表示CRM-DTO，0xFE表示事件消息，0x00~0xFD表示DAQ-DTO。

- EER：在CRM-DTO中表示CRO命令的执行情况，其中0x00表示正确，在事件消息，ERR代码的数值表示ECU内部发生了哪种错误。

- CTR：存放命令序号，在CRM-DTO中从0开始顺序按发送的先后顺序排序01、02依次类推。

- 命令参数域：包含了不同命令代码所需的命令参数。

3. DAQ-DTO (Data Acquisition-DTO)

一种高效的数据上传模式，它可以使从设备脱离主设备，自主地按一定周期向主设备上传数据，数据结构如下所示。

| 位置     | 字节0     | 字节1~7 |
   | ------ | ------- | ----- |
   | **定义** | 标识符=PID | 参数数据域 |

- PID，取值范围在0x00~0xFD之间，表明该类DTO是DAQ-DTO。这类DTO只用于DAQ通信模型。

- 命令参数域，包含了不同命令代码所需的命令参数。

### 2.3.DAQ模式下的数据通信<a name="DAQ模式下的数据通信"></a>

DAQ是一种高效的数据上传模式，自主地按一定周期向主设备上传数据。DAQ通信的实现需要借助DAQ列表，ODT列表及DAQ-DTO，如图2.3-1所示。

- DAQ列表

按照不同的上传周期分为多个DAQ列表，例如按照ECU内部要求分为10ms、20ms、50ms三种上传周期，分别上传不同的数据，则会分出DAQ List#0,DAQ List#1,DAQ List#2三个列表。

- ODT列表

ODT列表中存放具体需要上传的数据变量的信息，包括数据变量的存放地址，数据长度及其偏移地址。每个ODT的最大元素数目为7，可存放7个单字节数据变量的信息，当同一个周期需要发送的数据超过7个字节时将增加ODT列表的数量，故一个DAQ列表可以包含多个ODT列表。

- DAQ-DTO

ODT列表将转换DAQ-DTO向主设备发送消息，每个ODT都拥有一个绝对编号和相对编号，DAQ-DTO中的PID对应ODT的绝对编号，相对编号则表示该ODT在DAQ列表中的位置，ODT总数不能超过254。

![](images/2022-12-29-16-49-25.png)

<center>
图2.3-1 CCP协议DAQ与ODT列表结构
</center>

例如：

10ms周期DAQ List#0中拥有3个ODT列表，相对编号分别是ODT#0，ODT#1，ODT#2，绝对编号也是#0，#1，#2。

20ms周期DAQ List#1中拥有2个ODT列表，相对编号分别是ODT#0，ODT#1，绝对编号将按照DAQ List#0中已经定义的顺序向下排列，即绝对编号为#03，#04。

50ms周期DAQ List#2中拥有2个ODT列表，相对编号分别是ODT#0，ODT#1，绝对编号将按照DAQ List#1中已经定义的顺序向下排列，即绝对编号为#05，#06。

### 2.4.CCP命令代码简介<a name="CCP命令代码简介"></a>

CCP协议共规定了28条命令，其中11条为基础命令，17条为可选命令。CCP协议相对开放，只需要实现其中的一部分命令，也可以达成测量与标定的目的。每条命令在CCP协议中拥有对应的CMD代码，从设备将解析主设备发来的CRO中的CMD代码执行相应操作，如表2.4-1所示。

| 命令                  | CMD代码 | 定义            | 应答时间  | 备注  |
| ------------------- | ----- | ------------- | ----- | --- |
| CONNECT             | 0x01  | 连接            | 25ms  |     |
| GET_CCP_VERSION     | 0x1B  | 获取CCP协议版本     | 25ms  |     |
| EXCHANGE_ID         | 0x17  | 交换站标识符        | 25ms  |     |
| GET_SEED            | 0x12  | 申请密钥          | 25ms  | 可选  |
| UNLOCK              | 0x13  | 解除保护          | 25ms  | 可选  |
| SET_MTA             | 0x02  | 设置MTA地址       | 25ms  |     |
| DNLOAD              | 0x03  | 数据下载          | 25ms  |     |
| DNLOAD_6            | 0x23  | 6字节数据下载       | 25ms  | 可选  |
| UPLOAD              | 0x04  | 数据上传          | 25ms  |     |
| SHORT_UP            | 0x0F  | 数据短上传         | 25ms  | 可选  |
| SELECT_CAL_PAGE     | 0x11  | 选择标定数据页       | 25ms  | 可选  |
| GET_DAQ_SIZE        | 0x14  | 获取DAQ列表大小     | 25ms  |     |
| SET_DAQ_PTR         | 0x15  | 设置DAQ列表指针     | 25ms  |     |
| WRITE_DAQ           | 0x16  | 写入DAQ列表       | 25ms  |     |
| START_STOP          | 0x06  | 开始/终止数据上传     | 25ms  |     |
| DISCONNECT          | 0x07  | 断开            | 25ms  |     |
| SET_S_STATUS        | 0x0C  | 设置当前通信状态      | 25ms  | 可选  |
| GET_S_STATUS        | 0x0D  | 获取当前通信状态      | 25ms  | 可选  |
| BUILD_CHECKSUM      | 0x0E  | 建立checksum表   | 30s   | 可选  |
| CLEAR_MEMORY        | 0x10  | 清空内存          | 30s   | 可选  |
| PROGRAM             | 0x18  | 编程            | 100ms | 可选  |
| PROGRAM_6           | 0x22  | 6字节数据编程       | 100ms | 可选  |
| MOVE                | 0x19  | 内存转移          | 30s   | 可选  |
| TEST                | 0x05  | 连接测试          | 25ms  | 可选  |
| GET_ACTIVE_CAL PAGE | 0x09  | 获取处于激活状态下的标定页 | 25ms  | 可选  |
| START_STOP_ALL      | 0x08  | 开始/停止同步数据传输   | 25ms  | 可选  |
| DIAG_SERVICE        | 0x20  | 诊断服务          | 500ms | 可选  |
| ACTION_SERVICE      | 0x21  | 操作服务          | 5s    | 可选  |

<center>表2.4-1 CCP命令代码页</center>

注：

- 如果ECU内部不支持DAQ通信模式，以下4条有关DAQ的指令也成为可选项：

GET_DAQ_SIZE、SET_DAQ_SIZE、WRITE_DAQ、START_STOP。

- 如果使用了SELECT_CAL_PAGE指令，则GET_ACTIVE_CAL_PAGE指令也必须使用。

### 2.5.ERR代码列表<a name="ERR代码列表"></a>

CRM-DTO的ERR代码指示了CRO命令的执行情况，事件消息中的ERR代码表示ECU内部发生的错误类型，CCP协议定义了对应的ERR代码表，如表2.5-1所示。

| 代码   | 描述         | 错误等级 | 备注              |
| ---- | ---------- | ---- | --------------- |
| 0x00 | 确认/无错误     | -    |                 |
| 0x01 | DAQ处理器超载   | C0   | 无（等待直到ACK或时间溢出） |
| 0x10 | 指令处理器忙     | C1   | 无（等待直到ACK或时间溢出） |
| 0x11 | DAQ处理器忙    | C1   | 无（等待直到ACK或时间溢出） |
| 0x12 | 内部超时       | C1   | 无（等待直到ACK或时间溢出） |
| 0x18 | 请求密钥       | C1   | 无（等待直到ACK或时间溢出） |
| 0x19 | 阶段状态请求     | C1   | 无（等待直到ACK或时间溢出） |
| 0x20 | 冷启动请求      | C2   | 冷启动             |
| 0x21 | 标定数据初始化请求  | C2   | 标定数据初始化         |
| 0x22 | DAQ列表初始化请求 | C2   | DAQ列表初始化        |
| 0x23 | 更新代码请求     | C2   | (冷启动)           |
| 0x30 | 未知指令       | C3   | (错误)            |
| 0x31 | 指令句法错误     | C3   | 错误              |
| 0x32 | 参数超出许可范围   | C3   | 错误              |
| 0x33 | 访问被拒绝      | C3   | 错误              |
| 0x34 | 超载         | C3   | 错误              |
| 0x35 | 访问锁止保护     | C3   | 错误              |
| 0x36 | 资源/功能暂不可用  | C3   | 错误              |

<center>
表2.5-1 ERR代码列表
</center>

对于CRM-DTO而言，ERR代码代表当前命令执行状态，0x00表示正确执行命令，其他代码表示执行异常。

在ECU没有收到CRO命令时，如果发生内部错误，会发送事件消息以及错误代码，请求主设备进行响应的错误处理，CCP协议中定义了各个错误等级的应对措施，如表2.5-2所示。

| 级别  | 描述             | 措施         | 重试次数 |
| --- | -------------- | ---------- | ---- |
| 超时  | 无握手信号          | 重试         | 2    |
| C0  | 警告             | —          | —    |
| C1  | 伪错误(comm错误，忙…) | 等待(ACK或超时) | 2    |
| C2  | 可修复的（温度，掉电…）   | 初始化        | 1    |
| C3  | 不可修复的（重启，超载…）  | 终止         | —    |

<center>
表2.5-2 错误等级应对方案
</center>

### 2.6.预期运行性能<a name="预期运行性能"></a>

在实际运行过程中CCP协议的运行性能与一下几点相关：

- ECU的响应延迟时间

- 总线波特率

- 总线负载

- CRO与DTO的在总线网络中的优先级

由于在某一时间段内能够传输的内存区域有限，在需要传输大量数据时，节点的响应延迟成为了影响CCP协议传输的最主要影响因素。

假设波特率为500kb/s，总线上为一般负载率情况下，Polling模式的传输速率约为4~6kb/s，DAQ模式的平均传输速率约为20kb/s。

## 三.CCP基础命令<a name="CCP基础命令"></a>

CCP协议支持Motorola或Intel的数据格式，在本章节中以Motolora格式为例，特殊情况会另外注明，命令序列仅为序号编号，实际应用中请根据需求排序。

本章介绍CCP的11条基础命令。

### 3.1.连接命令(CONNECT)<a name="连接命令"></a>

首先需要使主设备与总线上的某个从设备建立逻辑连接，才能与其开始通信。

主设备发送CONNECT命令即0x01，通过ECU地址与总线上对应的从设备建立逻辑连接，之后主设备发出的所有命令都是针对与其建立连接的从设备，直到连接断开，或者其他ECU与其建立新的连接。

如果主设备使用CONNECT命令连接一个新的ECU，则与当前ECU的连接会暂时断开。

如果使用CONNECT命令连接一个已处于连接状态的ECU，则该ECU返回一个确认信息。只有当某个ECU被正确连接后，该ECU才会对主设备发出的CRO命令做出响应。

但CONNECT命令中的ECU站地址必须采用Intel格式，CONNECT命令的CRO数据场结构如下所示。

| 位置    | 定义                   |
| ----- | -------------------- |
| 字节0   | 命令代码=0x01(CONNECT)   |
| 字节1   | 命令序号=CTR             |
| 字节2~3 | ECU地址（Intel格式，低字节在前） |
| 字节4~7 | 无效                   |

针对CONNECT命令反馈DTO数据场结构，如下所示。

| 位置    | 定义             |
| ----- | -------------- |
| 字节0   | Packet ID:0xFF |
| 字节1   | 命令返回代码=ERR     |
| 字节2   | 命令序号=CTR       |
| 字节3~7 | 无效             |

例如，主设备需要与某个从设备建立逻辑连接，ECU地址=0x0001，CTR=1，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4~7         |
| --- | ---- | ---- | ---- | ---- | ------------- |
| 数据  | 0x01 | 0x01 | 0x01 | 0x00 | ------------- |

从设备收到该指令后，且正确执行，返回一条DTO，如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7         |
| --- | ---- | ---- | ---- | ------------- |
| 数据  | 0xFF | 0x00 | 0x01 | ------------- |

### 3.2.获取CCP协议版本(GET_CCP_VERSION)<a name="获取CCP协议版本"></a>

该条命令用于统一主、从设备所使用的CCP协议版本，在EXCHANGE_ID
命令之前执行。

GET_CCP_VERSION命令的CRO数据场结构如下所示：

| 位置    | 定义                         |
| ----- | -------------------------- |
| 字节0   | 命令代码=0x1B(GET_CCP_VERSION) |
| 字节1   | 命令序号=CTR                   |
| 字节2   | 协议主版本号（期望值）                |
| 字节3   | 协议副版本号（期望值）                |
| 字节4~7 | 无效                         |

针对GET_CCP_VERSION命令返回DTO的数据场结构如下所示：

| 位置    | 定义             |
| ----- | -------------- |
| 字节0   | Packet ID:0xFF |
| 字节1   | 命令返回代码=ERR     |
| 字节2   | 命令序号=CTR       |
| 字节3   | 从设备所使用的协议主版本号  |
| 字节4   | 从设备所使用的协议副版本号  |
| 字节5~7 | 无效             |

例如，主设备向从设备发送GET_CCP_VERSION命令，CTR=0x02，希望的协议版本号为2.1，即主版本号为2，副版本号为1，主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4~7         |
| --- | ---- | ---- | ---- | ---- | ------------- |
| 数据  | 0x1B | 0x02 | 0x02 | 0x01 | ------------- |

从设备收到该指令后，返回自身的协议主版本号，假设与主设备期待的版本号相同，返回一条DTO，如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5~7         |
| --- | ---- | ---- | ---- | ---- | ---- | ------------- |
| 数据  | 0xFF | 0x00 | 0x02 | 0x02 | 0x01 | ------------- |

### 3.3.交换站标识符(EXCHANGE_ID)<a name="交换站标识符"></a>

EXCHANGE_ID在ASAP标准中，MCD系统与ECU的通信需要ASAP2描述文件的支持，通过该条命令，自动化系统可由DTO返回的ID标识符自动为ECU分配一个ASAP描述文件。

EXCHANGE_ID命令的CRO数据场结构如下所示：

| 位置  | 定义                        |
| --- | ------------------------- |
| 字节0 | 命令代码=0x17(EXCHANGE_ID)    |
| 字节1 | 命令序号=CTR                  |
| 字节2 | CCP主设备ID信息（可选，根据实际应用情况而定） |

针对EXCHANGE_ID命令反馈的DTO数据场结构如下所示：

| 位置  | 定义                      |
| --- | ----------------------- |
| 字节0 | Packet ID:0xFF          |
| 字节1 | 命令返回代码=ERR              |
| 字节2 | 命令序号=CTR                |
| 字节3 | 从设备ID标识符的长度（字节数）        |
| 字节4 | 从设备ID数据类型（可选字节，视实际应用而定） |
| 字节5 | 资源可用状态字节                |
| 字节6 | 资源保护状态字节                |
| 字节7 | 无效                      |

从设备收到该命令后，会自动将地址指针定义到存放ID标识符的起始地址，主设备随后就以该起始地址使用UPLOAD指令上传ID信息（另见SET_MTA及UPLOAD命令）。

CCP协议在基本通信的基础上定义了一些其他功能，如非易失性内存烧写等。为了防止可能对ECU进行的误操作，在ECU程序实现时，可以对某些功能通过密钥进行保护（见GET_SEED及UNLOCK命令）。资源可用状态及资源保护状态两个字节反映了这些特殊功能当前是否处于保护状态，字节5、6的结构定义如下所示。

| 位   | 位7  | 位6  | 位5~2 | 位1  | 位0  |
| --- | --- | --- | ---- | --- | --- |
| 数据  | X   | PGM | X    | DAQ | CAL |

功能定义如下

| 功能  | 定义        |
| --- | --------- |
| CAL | 标定        |
| DAQ | DAQ通信模式   |
| PGM | 非易失性内存烧写  |
| X   | 暂时无效，日后扩展 |

对于资源可用状态字节，如某位值为“真（1）”，则表明当前该项功能未受保护，可以启用；如果某位值为“假（0）”，则表明当前该项功能受保护，不可以启用。

对于资源保护状态字节，如某位值为“真（1）”，则表明该项功能当前受密钥保护，需要权限才能访问（具体见GET_SEED及UNLOCK指令）；如某位值为“假（0）”，则表明该项功能当前未受密钥保护，可以直接访问。

例如，主设备向从设备发送EXCHANGE_ID命令，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2~7         |
| --- | ---- | ---- | ------------- |
| 数据  | 0x17 | 0x03 | ------------- |

假设所有功能均处于保护状态，从设备返回DTO,如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7       |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | --------- |
| 数据  | 0xFF | 0x00 | 0x03 | 0x04 | 0x02 | 0x00 | 0xFF | --------- |

由返回DTO可知，从设备ID号长度为4个字节，数据类型编码为2，资源可用状态字节为0x00，资源保护状态字节也是0xFF。

### 3.4.设置MTA地址(SET_MTA)<a name="设置MTA地址"></a>

MTA地址的英文全称是Memory Transfer Address，相当于一个地址指针的概念。SET_MTA命令就用于设置一个初始地址（32位基地址与地址偏移)，许多CCP命令都需要根据该地址对内存进行读取或擦写。

地址偏移量取决于ECU本身的实现形式，可以指向内存中的一个页或其中某一块区域。

CCP协议定义了两个MTA地址：MTA0与MTA1，分别针对不同的命令。

- 以下指令使用MTA0：

DNLOAD、UPLOAD、DNLOAD6、SELECT CAL PAGE、CLEAR MEMORY、PROGRAM、PROGRAM6

- 以下指令使用MTA1：

MOVE

SET_MTA命令CRO的数据场结构，如下所示：

| 位置    | 定义                 |
| ----- | ------------------ |
| 字节0   | 命令代码=0x02(SET_MTA) |
| 字节1   | 命令序号=CTR           |
| 字节2   | MTA序号(0或1)         |
| 字节3   | 地址偏移               |
| 字节4~7 | 地址（无符号长整型）         |

针对SET_MTA命令返回DTO的数据场结构，如下所示。

例如，主设备向从设备发送SET_MTA命令，地址偏移为0x00，基地址为0x20 00 00 16，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 数据  | 0x02 | 0x04 | 0x00 | 0x00 | 0x20 | 0x00 | 0x00 | 0x16 |

从设备返回DTO，如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7 |
| --- | ---- | ---- | ---- | ----- |
| 数据  | 0xFF | 0x00 | 0x04 | —     |

### 3.5.数据下载(DNLOAD)<a name="数据下载"></a>

DNLOAD指令负责将CRO中的数据下载到ECU中，以先前设定的MTA0为起始地址，开始擦写数据，下载完成后MTA0指针偏移至MTA0加上下载数据的字节数。

DNLOAD命令的CRO数据场结构，如下所示：

| 位置    | 定义                |
| ----- | ----------------- |
| 字节0   | 命令代码=0x03(DNLOAD) |
| 字节1   | 命令序号=CTR          |
| 字节2   | 下载数据大小（字节数）       |
| 字节3~7 | 下载数据（最多为5个字节）     |

针对DNLOAD命令返回DTO的数据场结构，如下所示。

| 位置    | 定义                  |
| ----- | ------------------- |
| 字节0   | Packet ID:0xFF      |
| 字节1   | 命令返回代码=ERR          |
| 字节2   | 命令序号=CTR            |
| 字节3   | MTA0偏移量（自增后)        |
| 字节4~7 | MTA0地址（自增后）（无符号长整型） |

例如，主设备向从设备发送DNLOAD命令，数据大小5字节，下载数据为0x10 11 12 13 14，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 数据  | 0x03 | 0x05 | 0x05 | 0x10 | 0x11 | 0x12 | 0x13 | 0x14 |

从设备返回DTO，如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 数据  | 0xFF | 0x00 | 0x05 | 0x00 | 0x20 | 0x00 | 0x00 | 0x21 |

先前设定MTA0为0x20 00 00 16，执行命令后MTA0自动增加5个字节。

### 3.6.数据上传(UPLOAD)<a name="数据上传"></a>

主设备通过UPLOAD命令，请求从设备以MTA0为起始地址，开始读取命令中规定的字节数，并且将数据上传至主设备，随后MTA0指针自动增加上传数据的字节数，但是不会向主设备汇报增加后的MTA0。

UPLOAD命令的CRO数据场结构，如下所示：

| 位置    | 定义                |
| ----- | ----------------- |
| 字节0   | 命令代码=0x04(UPLOAD) |
| 字节1   | 命令序号=CTR          |
| 字节2   | 请求上传的数据大小（字节数）    |
| 字节3~7 | 无效                |

针对UPLOAD命令返回DTO的数据场结构，如下所示。

| 位置    | 定义             |
| ----- | -------------- |
| 字节0   | Packet ID:0xFF |
| 字节1   | 命令返回代码=ERR     |
| 字节2   | 命令序号=CTR       |
| 字节3~7 | 所请求的数据         |

例如，主设备向从设备发送UPLOAD命令，请求以MTA0为起始地址，上传4个字节的数据，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7         |
| --- | ---- | ---- | ---- | ------------- |
| 数据  | 0x04 | 0x07 | 0x04 | ------------- |

从设备返回DTO，如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7          |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ------------ |
| 数据  | 0xFF | 0x00 | 0x07 | 0x10 | 0x11 | 0x12 | 0x13 | ------------ |

### 3.7.获取DAQ列表大小(GET_DAQ_SIZE)<a name="获取DAQ列表大小"></a>

如果ECU内部不支持DAQ通信模式，则本命令为可选命令！

本命令用来获取某个特定DAQ列表的大小，即其中ODT列表的个数，并清空当前DAQ列表内的数据，为下次DAQ通信做准备。

如果GET_DAQ_SIZE命令选定的DAQ列表不存在或者不使用，从设备返回的ODT列表个数则为0。同时该命令还对DAQ列表进行初始化并中止该DAQ列表当前的通信。

当要同时对多个ECU进行DAQ操作时，可以在字节4~7发送对应的DTO_ID，该项为可选功能，如果给出的ID号不存在，则返回一个错误代码。

GET_DAQ_SIZE命令的CRO数据场结构如下所示：

| 位置    | 定义                                |
| ----- | --------------------------------- |
| 字节0   | 命令代码=0x14(GET_DAQ_SIZE)           |
| 字节1   | 命令序号=CTR                          |
| 字节2   | DAQ列表序号(#0，#1…)                   |
| 字节3   | 无效                                |
| 字节4~7 | 该DAQ列表，其所对应的DTO的CAN ID标识符（无符号长整型） |

针对GET_DAQ_SIZE命令返回DTO的数据场结构如下所示。

| 位置    | 定义              |
| ----- | --------------- |
| 字节0   | Packet ID:0xFF  |
| 字节1   | 命令返回代码=ERR      |
| 字节2   | 命令序号=CTR        |
| 字节3   | DAQ列表大小（ODT列表数） |
| 字节4   | DAQ列表的第一个PID号   |
| 字节5~7 | 无效              |

DAQ列表中某个ODT的PID号=DAQ列表中的第一个PID号+ODT数目。

例如，主设备先向从设备发送GET_DAQ_SIZE命令，DAQ列表的序号为0x03，CAN ID为0x00 00 02 01，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3      | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | -------- | ---- | ---- | ---- | ---- |
| 数据  | 0x14 | 0x23 | 0x03 | -------- | 0x00 | 0x00 | 0x02 | 0x01 |

从设备返回DTO，DAQ列表的第一个PID号(0x08)，总共有10个ODT，每个ODT 为7个字节，如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5~7        |
| --- | ---- | ---- | ---- | ---- | ---- | ------------ |
| 数据  | 0xFF | 0x00 | 0x23 | 0x0A | 0x08 | ------------ |

### 3.8.设置DAQ列表指针(SET_DAQ_PTR)<a name="设置DAQ列表指针"></a>

如果ECU内部不支持DAQ通信模式，则本命令为可选命令！

在进行DAQ模式通信前，必须先对DAQ列表进行配置，将数据写入到相应DAQ列表的ODT元素中。SET_DAQ_PTR命令用来为写入DAQ列表数据设置入口地址指针。
SET_DAQ_PTR命令的CRO数据场结构如下所示：

| 位置    | 定义                     |
| ----- | ---------------------- |
| 字节0   | 命令代码=0x15(SET_DAQ_PTR) |
| 字节1   | 命令序号=CTR               |
| 字节2   | DAQ列表序号(0，1…)          |
| 字节3   | ODT序号(0,1…)            |
| 字节4   | 该ODT中的第几个元素(0,1…)      |
| 字节5~7 | 无效                     |

针对SET_DAQ_PTR命令返回DTO的数据场结构，如下所示。

例如，主设备先向从设备发送SET_DAQ_PTR命令，DAQ列表的序号为0x01，ODT序号为0x03，将指针设置到该ODT中的第2个元素，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5~7         |
| --- | ---- | ---- | ---- | ---- | ---- | ------------- |
| 数据  | 0x15 | 0x24 | 0x01 | 0x03 | 0x02 | ------------- |

从设备返回DTO，下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7         |
| --- | ---- | ---- | ---- | ------------- |
| 数据  | 0xFF | 0x00 | 0x24 | ------------- |

在该命令执行后，可使用WRITE_DAQ指令将数据写入到选中的ODT中。

### 3.9.写入DAQ列表(WRITE_DAQ)<a name="写入DAQ列表"></a>

如果ECU内部不支持DAQ通信模式，则本命令为可选命令！

在DAQ通信前，需要对DAQ列表进行配置，将所需上传的数据事先写入DAQ列表的ODT列表中，该命令的功能就是将数据写入DAQ列表，先前由SET_DAQ_PTR命令所定义的地址为该命令的数据写入地址。在WRITE_DAQ命令中，一次写入的数据称为一个DAQ元素。写入的DAQ元素大小可为：1字节(BYTE)、2字节(DWORD)、4字节（Long int/Float)。由于一个ODT列表最多只能存储7字节的数据，因此对于长整形或浮点数，ECU必须保证上传时DAQ列表中数据的完整性与连贯性。

WRITE_DAQ命令的CRO数据场结构如下所示。

| 位置    | 定义                   |
| ----- | -------------------- |
| 字节0   | 命令代码=0x16(WRITE_DAQ) |
| 字节1   | 命令序号=CTR             |
| 字节2   | DAQ元素的大小（可为1,2,4字节）  |
| 字节3   | DAQ元素的地址偏移           |
| 字节4~7 | DAQ元素的地址（无符号长整型）     |

针对WRITE_DAQ命令返回DTO的数据场结构如下所示。

例如，主设备向从设备发送WRITE_DAQ命令，写入DAQ元素的大小为2字节，写入元素的地址偏移为0x00，地址为0x02 00 20 00，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 数据  | 0x16 | 0x25 | 0x02 | 0x00 | 0x02 | 0x00 | 0x20 | 0x00 |

从设备返回DTO，如下所示。

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7         |
| --- | ---- | ---- | ---- | ------------- |
| 数据  | 0xFF | 0x00 | 0x25 | ------------- |

### 3.10.开始/终止数据上传(START_STOP)<a name="开始/终止数据上传"></a>

如果ECU内部不支持DAQ通信模式，则本命令为可选命令！

该命令用于DAQ通信模式，其作用是开始或终止某个DAQ列表的数据上传。
START_STOP命令的CRO数据场结构如下所示：

| 位置    | 定义                    |
| ----- | --------------------- |
| 字节0   | 命令代码=0x06(START_STOP) |
| 字节1   | 命令序号=CTR              |
| 字节2   | 模式：开始/终止准备数据传输        |
| 字节3   | DAQ列表序号               |
| 字节4   | 最后一个ODT序号             |
| 字节5   | 事件通道号                 |
| 字节6~7 | 传输速率预分频值              |

该条命令对于不同的模式有不同的含义：

- 模式=0x00：终止某DAQ列表的数据传输；

- 模式=0x01：开始某DAQ列表的数据传输；

- 模式=0x02：为开始同步传输做准备。

该命令用于开始或终止某个特定DAQ列表的数据上传，由命令中的DAQ列表序号决定，命令该DAQ列表的ODT开始上传。

事件通道号对应该DAQ列表上传的周期，通过预分频值可延长上传周期，预分频值必须≥1。
如果命令中的模式为0x02，主设备将对特定DAQ列表进行参数标识，当所有需要上传的列表都完成标识以后，主设备会利用START_STOP_ALL命令将所有进行过参数标识的DAQ列表同步上传。

针对START_STOP命令返回DTO的数据场结构如下所示：

例如，主设备向从设备发送START_STOP命令，命令模式为0x01(开始上传DAQ列表数据)，DAQ列表序号为0x01，最后一个ODT序号为0x05，事件通道为0x02，预分频值为1，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3  | 字节4  | 字节5  | 字节6  | 字节7  |
| --- | ---- | ---- | ---- | ---- | ---- | ---- | ---- | ---- |
| 数据  | 0x06 | 0x26 | 0x01 | 0x01 | 0x05 | 0x02 | 0x00 | 0x01 |

从设备返回DTO，如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7         |
| --- | ---- | ---- | ---- | ------------- |
| 数据  | 0xFF | 0x00 | 0x26 | ------------- |

之后，从设备将按主设备的请求开始上传DAQ列表#01中从第0个ODT列表到第5个ODT列表内的数据。

### 3.11.断开(DISCONNECT)<a name="断开"></a>

当主设备需要结束与当前ECU的通信或者准备与下一个ECU通信时，需要使用DISCONNECT断开与当前ECU的逻辑连接，根据命令参数设置可以暂时将设备设置为离线状态，也可以彻底终止与当前ECU的通信。
彻底断开会使先前对ECU状态的所有设置变成无效，并使ECU内部各项功能的保护状态恢复到初始状态。
暂时断开不会终止与当前ECU的DAQ通信，也不会影响先前对DAQ列表、ECU通信状态、各项功能的保护状态及MTA地址值的设置。
该命令中的ECU地址必须采用Intel格式，低位在前。DISCONNECT命令的CRO数据场结构如下所示：

| 位置    | 定义                     |
| ----- | ---------------------- |
| 字节0   | 命令代码=0x07(DISCONNECT)  |
| 字节1   | 命令序号=CTR               |
| 字节2   | 命令参数：0x00:暂时断开，0x01:终止 |
| 字节3   | 无效                     |
| 字节4~5 | ECU地址(Intel格式，低位在前)    |
| 字节6~7 | 无效                     |

针对DISCONNECT命令返回DTO的数据场结构，如下所示：

例如，主设备向从设备发送DISCONNECT命令，命令代码=0x00(暂时将ECU设为“离线”状态)，ECU地址=0x0001，则主设备发送的CRO如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3          | 字节4  | 字节5  | 字节6~7        |
| --- | ---- | ---- | ---- | ------------ | ---- | ---- | ------------ |
| 数据  | 0x07 | 0x09 | 0x00 | ------------ | 0x01 | 0x00 | ------------ |

从设备返回DTO，如下所示：

| 字节  | 字节0  | 字节1  | 字节2  | 字节3~7        |
| --- | ---- | ---- | ---- | ------------ |
| 数据  | 0xFF | 0x00 | 0x09 | ------------ |

## 四.CCP可选命令<a name="CCP可选命令"></a>

CCP的17条可选命令请参考本站《[CCP/XCP指令参考表](./ccpcmd.html)》。

## 五.CCP应用示例<a name="CCP应用示例"></a>

### 5.1.一个简单的CCP通信示例<a name="一个简单的CCP通信示例"></a>

想要实现一个CCP功能，往往需要执行多条不同的CCP命令，以Polling模式为例，列出实现CCP协议的典型步骤。

注：以下所举实例仅针对CCP协议。状态字节各位的设置如下：(01xxxx1x)中x表示该位保持不变。0/1表示将该位设置成0/1。

假设通信数据格式为Motorola，ECU地址为0，CRO-ID=0x100，DTO-ID=0x101，未使用的字节全部填充0。

**1.主/从设备建立逻辑连接**

当主设备需要与某个ECU进行通信时，首先需要与其建立逻辑连接，使用CONNECT命令进行连接，假设该ECU的地址为0。

主设备发送CRO：ID=0x100，Data=0x01 01 00 00 00 00 00 00。

从设备正确执行后返回DTO：ID=0x101，Data=0xFF 00 01 00 00 00 00 00。

获取CCP协议版本与交换站标识符视情况而定，并非必须使用，本次案例不使用。

**2.设置MTA0地址**

主设备对从设备执行上传或下载命令前需要先设定MTA0地址，即需要数据存放的起始地址，向从设备发送SET_MTA指令，假设该变量地址为0x20 00 00 16，地址偏移量为0。

主设备发送CRO：ID=0x100，Data=0x02 04 00 00 20 00 00 16。

从设备正确执行后返回DTO：ID=0x101，Data=0xFF 00 04 00 00 00 00 00。

**3.数据下载**
当主设备需要对ECU中的某个变量进行标定时，需要先设定MTA0，之后向从设备发送DNLOAD指令，假设数据大小5字节，数据为0x10 11 12 13 14。

主设备发送CRO：ID=0x100，Data=0x03 05 05 10 11 12 13 14。

从设备正确执行后返回DTO：ID=0x101，Data=0xFF 00 05 00 20 00 00 21。

若ECU段实现了DNLOAD_6指令，也可以使用该指令进行数据下载。

**4.数据上传**
当主设备需要读取ECU内部某个变量时，假设数据变量地址为0x20 00 00 16，设定好MTA0后，需要向从设备发送UPLOAD命令，读取4个字节。

主设备发送CRO：ID=0x100，Data=0x04 07 04 00 00 00 00 00。

从设备正确执行后返回DTO：ID=0x101，Data=0xFF 00 07 10 11 12 13 00。

若ECU段实现了SHORT_UPLOAD，也可以使用该指令进行数据上传。

**5.断开连接**

主设备对从设备的测量标定结束后，应断开与该从设备的逻辑连接，需要向从设备发送DISCONNECT命令。

主设备发送CRO：ID=0x100，Data=0x07 08 01 00 00 00 00 00。

从设备正确执行后返回DTO：ID=0x101，Data=0xFF 00 08 00 00 00 00 00。

### 5.2.如何深入理解CCP<a name="如何深入理解CCP"></a>

上述示例仅仅是一个简化的CCP应用示例，用户如果想要比较深入地理解CCP，最好的方法是分析实际的CCP通信过程CAN报文。比如使用RapidECU-U34控制器（其它型号控制器类似）与MeCa软件构成一套完成的标定系统进行实际的测量标定。同时在标定CAN总线上并联一个CAN卡采集标定过程中的CAN报文，之后通过分析采集到的CAN报文可以形成对标定过程的比较全面的认识。

MeCa软件默认的CCP通信参数如下图所示：

![](images/2023-09-03-20-08-28-image.png)

以上CCP通信参数与RapidECU系列控制器完全匹配，当使用MeCa软件标定其它控制器时，请按上述参数设置控制器的CCP通信参数。当使用其它标定软件（比如CANape）标定RapidECU系列控制器时，请按上述参数设置标定软件的CCP通信参数。

## 六.CCP驱动代码结构<a name="CCP驱动代码结构"></a>

CCP协议是基于CAN总线的标定协议，需要在ECU内部实现基于CAN总线的CCP协议，才能对ECU进行标定与测量。ECU通过解析收到的CRO，分析CMD代码的指令需求，执行对应的操作并向主设备返回DTO报文，如图6-1所示，实现该功能需要以下3块内容：

- 收发CAN报文的CAN驱动

- 接收CMD指令的CCP驱动

- 对接CAN驱动与CCP驱动的接口程序

为了节省开发时间，提高效率，可以使用Vector公司提供的ECU侧的开源CCP驱动代码，其CCP驱动代码包含两个处理模块，同时还提供了驱动代码移植的说明文档。

1. 命令处理模块：

命令处理模块是CCP驱动代码的核心组成部分。根据CCP协议，MCD与ECU之间的通信遵循严格的命令应答机制。当ECU接收到MCD的CRO命令后，由命令处理模块负责解释并执行收到的命令，并且组织CRM-DTO消息对CRO进行应答。

2. DAQ处理模块：

该模块用于DAQ数据采集模式。该模式下MCD与ECU之间通信是单向的，即只有ECU发给MCD的DAQ-DTO。当命令处理模块收到的请求DAQ通信的CRO后，就将CRO数据进一步转给DAQ处理模块。由DAQ处理模块对DAQ列表进行配置，组织DAQ-DTO向MCD上传。

![](images/2023-01-04-15-41-21.png)

<center>
 图6-1 CCP驱动代码结构
</center>