本文目录如下：
1 解码来自ECU的CCP信号数据
1）解码CCP轮询数据
2）解码CCP DAQ数据
2 A2L - ECU 描述文件
3 种子和密钥授权
4 基于CAN总线的XCP协议
1）XCP 数据包
#1 XCP中的CAN ID
#3 XCP CTO CONNECT例子
#4 XCP轮询例子
2）XCP DTO，数据传输对象
5 小结
1 解码来自ECU的CCP信号数据
在 CCP 轮询/DAQ 中，实际上是使用特定的信号编码结构记录原始 CAN 帧。为了理解记录的数据，需要将其解码为人类可读的形式，即物理值。
与CAN总线报文相似，但有一些差异，CCP解码会更复杂些，下面对此进行解释：1）解码CCP轮询数据
先回顾下之前的CCP轮询请求/响应的数据，如下所示：主机向ECU请求两个不同的4字节信号值，即来自源地址0x12345678和 0xABCDEF00。在这两种情况下，ECU 都以CAN ID 0x702进行响应。
在大多数CAN总线解码场景中，只需查找响应CAN ID并找到给定信号的“起始位”和“位长”即可从有效负载中提取原始数据。然而在这是不可能的，因为ECU在两个不同的信号上使用相同的CAN ID，响应有效数据也不包含 ECU 源地址，这样导致无法直接根据CAN ID 来区分来自0x12345678 的信号和来自 0xABCDEF00 的信号。那要怎么办？
需要结合请求和响应报文中的信息，即通过“重新打包”有效载荷来解决，如下所示：
这里要查找的CAN ID是0x702，多路复用器位于第5-8个字节，而信号值位于第12-15个字节。现在可以指定两个单独的解码规则，相关规则取决于4字节多路复用器的值。可以看出DAQ-DTO报文具有预先指定的CAN ID（0x712）和有效载荷。其中第1个字节是ODT列表ID，又称ODT PID（0x07），无需“组合”DAQ-DTO响应帧来唯一地标识哪些帧包含哪些信号，可以通过CAN ID和ODT PID的组合直接识别。这样使得 DAQ-DTO 报文的解码比轮询消息更简单。实际上只要知道每个ODT列表的剩余字节中的信号编码，就可以直接创建具有多路复用的DBC文件。在大多数实际应用中，可以合理地假设已知这种信号编码，因为主机本身控制（通过初始化序列）如何将每个信号打包到DAQ和ODT列表中。这里举个例子：已知CAN ID为0x712且ODT PID为0x07的DAQ-DTO，在第2个字节中包含源地址为0x00001000的信号。然后可以从ECU描述文件中查看如何解释这个1字节信号值，比如该测量信号是以摄氏度为单位的温度，应将其乘以0.8倍，并将其偏移量乘以 20。综上不难理解，CCP轮询/DAQ可以在CAN总线帧解码的正常逻辑内处理，即使用DBC文件处理数据，但处理CCP数据的最常见选择是使用A2L文件。2 A2L - ECU 描述文件
ECU描述文件包含主机与ECU通信所需的一切信息，从数据测量的角度来看，应包括有关 CAN ID、可用信号、信号解码规则和DAQ/ODT等的信息。ASAP2描述格式 (*.A2L) 用于构造此信息。ASAM在ASAM MCD-2 MC中对ASAP2数据定义进行了标准化，第一个版本1.3.1于1999年6月15日发布，即CCP 2.1标准发布的同一年，该标准的最新版本 1.7.0 于 2015 年发布。![]()
https://pan.baidu.com/s/12luEJMiMH0AOSTaka2tngA?pwd=4y5s 提取码: 4y5s实际上，A2L文件用于“配置”主机，实现与ECU的通信。就如之前例子，使用CAN ID 0x701和0x702进行主机和ECU之间的CRO/DTO通信，这些ID会在A2L文件中指定。A2L 文件也描述了信号在ECU中的存储方式以及如何解码它们具体可以参考来自A2L示例文件的片段：这里与其他CAN协议和DBC文件中的信号编码逻辑进行比较：“MEASUREMENT”标签用于封装测量信号的描述。在本例中为 Airflow，它具有详细的描述和由下限/上限定义的最小值/最大值。该信号还有一个4字节源地址，即0x40000144。回顾下CCP轮询内容，这个源地址可以在SHORT_UP命令轮询序列中用于请求此特定ECU信号的原始值。同样，在 DAQ测量中，这个源地址将用于初始化过程。换句话说，工程师可以在A2L文件或A2L GUI工具中查找想要的信号（气流），并配置主机来请求此信号。假设我们已经记录了原始值的数据，需要解码这些信息。如前所述：第一步是从响应有效负载中提取原始字节，执行此操作的方法取决于使用的是轮询还是 DAQ测量。此外字节顺序不是由CCP协议指定的，而是在A2L文件中以全局或信号级别指定。一旦提取了信号字节并将其转换为十进制形式，我们就需要知道如何转换它们。在DBC文件上下文中，这始终以“线性”方程的形式完成，即y=ax+b，其中a等于比例因子，b等于偏移量，两者均在每个信号的 DBC 文件中指定。而A2L 文件允许更复杂的转换方法，从信号描述中可以明显看出，它指的是定义为“CompuMethod_6”的转换规则，我们可以在 A2L 文件的另一部分中查找这一点：此转换规则使用称为RAT_FUNC的转换类型，定义如下：y=(axx+bx+c)/(dxx+ex +f)具体来说，它支持5个系数，需要在计算方法中指定。这里它们分别设置为 0 1 0 0 0 1，这意味着函数简化为以下形式：y = x。在这个简单的情况下，与DBC文件中使用的函数一样。实际上A2L文件还支持另一种转换类型LINEAR，即y = ax + b，在 Airflow 信号的情况下，可以使用此类型。最后在测量细节中还指定了单位，这意味着可以绘制以 kg/s 为单位的气流物理值。格式字段为%6.2，应读作%Length.Layout，其中Length反映解码信号的总长度，Layout 反映小数位数。通常上述介绍，我们发现直接查看A2L不太容易，但这没关系，通常我们不会直接查看，而是将A2L 文件加载到标定工具中，比如CANape和INCA，也就是说工程师就算不了解A2L文件的结构和语法，也可以使用工具执行ECU相关的测量和标定工作。这就是关于A2L描述的简单介绍，更多内容可以自行下载A2L示例文件。3 种子和密钥授权
汽车ECU开发过程中，通常使用CCP/XCP协议进行ECU的测量和标定，在某些情况下，与 ECU通信只需要A2L文件和合适的CAN工具，也可以简单地提取A2L文件的子集来配置设备，比如用于测量特定的信号。但如果没有A2L文件，几乎不可能进行通信，因此许多 OEM除了锁定A2L文件外不需要任何其他安全措施，但有些用例需要额外的安全性。CCP通过称为“种子和密钥”授权的概念来支持这点，即主机从ECU接收种子并将其用作内部安全算法的输入来计算密钥，然后主机通过CAN将密钥发送到ECU，如果它与ECU内部计算的密钥匹配，则提供进一步通信的授权。具体过程如下所示：主机通过GET_SEED命令0x12请求种子，并在第3个字节中指定“资源掩码”0x02，资源掩码表示请求的访问级别，0x02仅表示DAQ 访问。ECU用一个帧进行响应，其中第4个字节为0x01，表示DAQ访问受到保护，ECU在剩余的 4个字节中提供请求的种子。根据种子主机计算密钥并通过UNLOCK命令0x13提供密钥，密钥长度为4个字节。ECU做出肯定响应，包括请求的资源掩码0x02，这意味着DAQ访问现已解锁。安全算法最常见的实现方式是通过*.dll文件，因为主机通常是带有GUI工具和CAN接口的 Windows PC，因此使用 *.dll文件还可以实现跨CCP工具的标准化，同时主机无需知道所使用的底层算法。当然在独立的CAN总线数据记录器和远程信息处理设备中使用 *.dll 文件具有挑战性（因为它们不运行 Windows），因此一些公司使用替代解决方案，比如更适合嵌入式设备的专有文件格式。4 基于CAN总线的XCP协议
了解了上述这些CCP的基础知识后，接下来了解基于CAN总线的XCP，重点关注帧结构。
1）XCP 数据包
为了理解基于CAN总线的XCP与CCP的结构变化，先比较以下CCP的CRO/DTO和XCP的CTO/DTO。XCP数据包包括XCP CTO（与CCP CRO和CRM-DTO的作用相似）和XCP DTO（与CCP DAQ-DTO的作用相似），如下所示：另一种说明CCP与XCP报文的方法是可以通过架构来比较，如下所示：1）XCP CTO，命令传输对象
在基于CAN总线的XCP中，CTO是用于传输控制命令的CAN帧，包括命令（CMD）、命令响应（RES）、错误（ERR）、事件（EV）和服务请求（SERV）。与CCP中的CRO不同，CTO由主机和ECU 同时使用，另外主机发出的CMD数据包必须由ECU以RES或ERR数据包进行应答，而其他数据包类型则异步发送。如果查看CTO的有效载荷，第1个字节反映的是数据包标识符 (PID)，其余7个字节由特定的CTO数据包类型的数据组成。如果将这个结构与CCP的CRO进行比较，它们是相似的，除了排除XCP中的命令计数器字节。XCP通信至少需要两个CAN ID：一个用于主机（0x551），一个用于ECU（ 0x552），如果主机需要通过XCP与多个 ECU 通信，则需要一组额外的ID。XCP和CCP之间的CMD字节的实际值也不同，比如CCP使用0x0 作为CONNECT命令，而XCP使用0xFF。CTO PID的分配取决于报文是主机发送还是从机发送，如下所示：下表比较了CCP与XCP CMD之间的CMD子集：
![]()
#3 XCP CTO CONNECT例子
基于CAN总线的XCP的CONNECT报文如下所示：注意此例不使用 0xAA 填充，因为基于CAN总线的XCP对此是可选的。主机向ECU发送 CONNECT CMD (0xFF)，并将通信模式设置为正常 (0x00)。这里与CCP不同，主机无需在CONNECT帧的有效负载中指定站地址，这是因为CAN ID已经唯一地标识了主机正在与哪个ECU通信。ECU用CAN帧进行响应，其中：第1个字节是正响应PID(RES)；
第2个字节是资源可用性，类似于CCP通信中的种子和密钥，0x04表示DAQ可用；
第3个字节与“通信模式”（此处为“可选”）有关；
第4个字节是最大CTO的大小（此处为8个字节）；
第5个和第6个字节是最大 DTO的大小（此处为 8 个字节）；
第7个和第8个字节分别是XCP协议层版本和传输层版本（在本例中均为 1）。
#4 XCP轮询例子
建立连接后，主站可以启动轮询，与CCP一样，这可以通过SHORT_UPLOAD命令完成：这里主机发送一个SHORT_UPLOAD CMD (PID 0xF4)，用于2个字节的数据，第3个字节是保留的，第4个字节是地址扩展（在本例中为0），其余4 个字节等于源地址0x12345678（intel字节顺序）。为了响应命令CTO，ECU发送一个响应CTO，其中包含2个字节数据的值。2）XCP DTO，数据传输对象
XCP DTO用于发送同步数据（类似于CCP中DAQ-DTO的作用），它还支持传输STIM数据和Bypass ECU内的正常算法。这里不详细介绍XCP DAQ测量，因为它的概念与CCP DAQ相似。关于XCP DAQ测量，它允许ECU将测量时间写入XCP DTO数据包中，这意味着主机能够利用ECU测量时间戳（而不是主机自己的内部时间戳）正确同步跨多个帧分割的ECU数据。XCP DTO 时间戳是可选的，并以递增计数器的形式实现，其递增逻辑在A2L文件中指定。如果要为特定DAQ列表包含时间戳，则该时间戳将写入第一个ODT列表（但如果同一 DAQ 列表中存在多个ODT 列表，则不会写入后续列表）。在DAQ DTO中打包DAQ列表#和ODT列表#信息的方法有多种，最简单的情况是“绝对 ODT 编号”，其中ODT列表#在所有DAQ列表中都是唯一的，PID（即ODT#）足以全局识别ODT列表。还有另一种方法，即在DAQ列表中使用相对ODT列表编号。比如可能有两个PID=0x00的ODT列表，这意味着它们无法唯一标识，因为CAN ID在两个DTO中是相同的。此时可以在CAN帧有效负载的第2到第3个字节中添加1或2字节DAQ列表标识符，这样就可以再次唯一地标识特定的ODT列表。A2L文件和ECU将提供有关所用方法的信息。在XCP DTO通信中，可以选择使用1字节计数器字段。如果在XCP DTO DAQ数据包中使用CTR字段，则从机将仅将CTR的值插入DAQ列表的第一帧中，即第一个ODT列表中。以上就简要介绍完了如何解析这些数据，A2L文件解析，种子与密钥授权，以及基于CAN总线的XCP基础等内容。关于CCP/XCP 还很多内容没在这里讨论，因为本文意图专注于与数据记录相关的基本主题和概念。不过如有兴趣，下面提供一些参考：- Vector's XCP Book v1.5 : A detailed overview of the XCP 1.5 protocol
- XCP (Wikipedia) : The basics on the XCP protocol
- ASAM MCD-1 XCP overview : Also provides a detailed overview of the XCP protocol
- ASAM ASAM MCD-2 MC overview : Provides an overview of the ECU description file standard
- Seed & key details (Vector) : A useful intro to the basics on authorization
汽车研发交流群，有兴趣的朋友请添加群主：prOmiseyes，备注：公司+职务入群。仅限汽车从业人员。
