面向初学者的XCP——XCP协议的通信的构造和功能

刺骨的言语ヽ痛彻心扉 2022-05-19 09:25 228阅读 0赞

原文链接：[はじめてのXCP][XCP]

## 面向初学者的XCP ##

### 测量/校准协议XCP入门 ###

###  ###

### 第二章、XCP协议的通信的构造和功能 ###

接下来，将会说明“通用校准协议（XCP：Universal Calibration Protocol）”协议具体是如何通信的，以及XCP的功能和协议内容。

### 主从方式 ###

在XCP中，测量/校准的工具侧是“XCP主结点”，被测量的ECU侧是“XCP从结点”，采用所谓的“主从通信方式”。这种通信方式中，必定是从主结点发送命令来开始，从结点在接收到后，再向主结点发送应答，以这样的顺序进行通信。如图7所示，1个网络上主结点必定只有一个，而从结点可以有多个。

![20171220193731012][]

图7：使用XCP的网络示例

在这个情况下，主结点向每个从结点发送命令，并接收从结点返回的应答（图8）。

![20171220193757869][]

图8：一主多从的通信示例

通过这种通讯方式，车载网络上连接一个测量/校准工具（= XCP主结点）后，可以通过XCP协议访问作为测量对象的各个ECU（= XCP从结点）。

### 网络和传输方式 ###

在网络上，只要能区分“从主结点发送到从结点”和“从从结点发送到主结点”，这两种类型的通信，就能够使用XCP。在“XCP on CAN”的情况下，是通过用两个CAN ID，“从主结点发送到从结点的ID”和“从结点发送到主结点的ID”进行区分。在网络上使用区分的通信并传输一些内容时，XCP使用了三种传输模式（图9）。

![20171220193835468][]

图9：XCP的传输模式

对于传输模式而言，可以在主结点侧和从结点侧，分别决定使用哪种模式。例如，主结点为“块传输模式”，从结点为“标准模式”，这样的使用方式也是可行的。因此，尽管主结点的工具侧的性能强大，但是当从结点的ECU只能使用有限的资源时，也可以实现简化的传输模式。

### CTO/DTO ###

在XCP中，除了主结点和从结点之间的传输方向的差异之外，要传输的内容还被分为“与XCP本身的控制相关的通信”和“与数据相关的通信”两种类型，以及定义在每个网络上传输的报文的格式。作为对比，前者被称为“命令传送对象（CTO：Command Transfer Object）”，后者被称为“数据传送对象（DTO：Data Transfer Object）”。

CTO：Command Transfer Object的缩写

CTO是与XCP自身的控制命令和应答等相关的对象。控制命令从主结点发送，对命令的应答是从从结点发送。

DTO：Data Transfer Object的缩写

DTO是与同步从结点（ECU）获取数据测量结果以及进行数据变更相关联的对象。同步数据变更被称为“激励（Stimulation）”，但由于是测量/校准以外的功能，因此省略详细说明（详情请参照XCP标准文件）。

图10展示了，从XCP标准文件的“Part2 1.1.1 The XCP Packet Types”章节中，抽取的XCP主结点与从结点之间的CTO和DTO的关系。

![20171220193956217][]

图10：XCP主结点/从结点间的对象

###  ###

### 报文格式和PID ###

如上所述，CTO和DTO是不同报文格式（图11），可以分别设置主从设备的最大报文长度。

MAX\_CTO：CTO的最大报文长度（字节）

MAX\_DTO：DTO的最大报文长度（字节）

![20171220194034842][]

图11：CTO和DTO的报文结构

所有的XCP报文都在这个最大报文长度内，命令和响应等内容都在一个报文中完成的。而且在报文格式中，每个字段按两种类型分配给CTO和DTO报文。此外，报文的第一个字节是被称为“PID”的标识符，是被用来区分是怎样的报文。

主结点对从结点进行XCP控制时使用“命令（CMD）”，此时的PID在“0xC0”到“0xFF”的范围内。从结点对这个命令返回肯定应答的情况下，使用“应答（RES）”，此时PID变为“0xFF”（图12）。

![20171220194142287][]

图12：报文的标识符（PID）

除了测量/校准的同步数据交换之外，所有其它的都是通过主结点发送命令，从结点将返回肯定应答来完成的。在此，以XCP on CAN为例来说明，其中主结点发送到从结点的CAN ID是“1”，从结点发送到主结点的CAN ID是“2”。在这种情况下，XCP通信按以下顺序执行。

1.  主结点发送的CAN ID为“1”，其中第一个字节指定为“0xFF”，第二个字节指定为“命令参数”。
2.  从结点接收第1行的连接命令，并通过PID识别该命令。
3.  从结点发送的CAN ID为“2”，其中第一个字节指定为“0xFF”，第二个字节开始指定为“应答值”。
4.  主结点接收第3行的应答命令。

图13显示了实际通信的跟踪结果。第1行的“0xFF”是命令“CONNECT”，从而在主结点和从结点之间建立逻辑连接，并接收后续命令。

![20171220194229706][]

图13：CONNECT命令和应答

###  ###

### 访问测量/校准对象 ###

XCP的测量/校准，是通过对ECU内部的软件的访问来实现的。具体而言，针对要测量/校准的对象的内存区间，通过指定对应的“XCP地址”的方式进行访问。

XCP地址与普通的微控制器中的地址几乎相同，但XCP使用了32位的XCP地址和8位的扩展地址。也就是说，主结点对从结点的访问，可以有32 + 8 = 40位的地址空间。这个地址与XCP的实际ECU内存不需要完全匹配，其字节序（Endian）也可以针对每个从结点来选择。因此，在车载网络上可以连接到多个ECU，即使存在不同的地址空间（16位，32位），或者不同的地址字节序，主结点都可以经过适当处理，使得所有的都可以测量/校准。

### 异步测量 ###

XCP除了同步测量，还可以做异步测量。异步测量是使用主结点发送的命令，通过指定的XCP地址来提取从结点的ECU内部的数据，并通过从结点的应答将该数据传送给主结点，如此循环往复来实现的。为了取出数据，使用PID为“0xF4”的命令“SHORT\_UPLOAD”。这个命令和应答的格式如下所述。

SHORT\_UPLOAD命令：

CTO 0字节位置，指定为PID“0xF4”  
CTO 1字节位置，指定为取出字节数。最大为MAX\_CTO – 1字节  
CTO 2字节位置，保留字段  
CTO 3字节位置，指定为要读出的8位扩展地址  
CTO 4~7字节位置，指定为要读出的32位地址

SHORT\_UPLOAD应答：

CTO 0字节位置，指定为PID“0xFF”  
CTO 1~MAX\_CTO字节位置，指定为取出的数据

图14是主结点使用“SHORT\_UPLOAD”，在XCP扩展地址为“0”、XCP地址为“0x00124A5C”的位置，每100ms取出4字节的过程的跟踪结果。

![20171220194405042][]

图14：通过SHORT\_UPLOAD命令的测量

###  ###

### 同步测量 ###

在上述异步测量的情况下，主结点决定了测量时间。为了使测量与ECU的控制相匹配，有必要由ECU确定测量时机，并在数据取出来后由从结点发送到主结点。这种数据通信是通过DTO来完成的。

主结点在进行同步测量之前，通过命令指定要取出的数据的XCP地址，从结点在等到同步测量开始命令后，使用DTO发送到主结点。因此，在同步测量的情况下，不是通过命令和应答的组合，而是通过测量周期或事件，由从结点发送DTO报文到主结点。

图15展示了，由“START\_STOP\_SYNCH”命令开始的测量同步，从结点持续地将测量数据通过DTO报文发出，直到收到“START\_STOP\_SYNCH”命令才停止的实际的跟踪结果。

![20171220194610101][]

图15：同步测量的开始和停止

以下是对同期测量中，对ECU的控制应用程序的测量时机，主结点和从结点的任务分割的说明。

ECU的控制应用程序：

当到达测量的控制周期，或者事件发生时，进行处理并通知到XCP从结点。

主结点：

确定要同步测量的内存及其测量周期，指定同步测量的XCP地址，并使用命令启动和停止同步测量。

从结点：

它管理从主结点指定的同步测量的XCP地址。然后，从检测的开始同步测量后，直到停止之前，会根据上述ECU的控制应用程序传达的被管理的XCP地址，从取出内存值并发送DTO报文。

### XCP与同步测量相关的术语和概念 ###

关于同步测量，在XCP标准文档中使用了各种术语。这里我们解释一下主要的术语和概念。

元素（Element）：

通过XCP地址来指定的一个测量对象的内存。

对象描述表（ODT：Object Description Table）：

归并元素的测量内存，在一个DTO报文中聚集最多的可发送的内存的表。

ODT条目（Entry）：

为创建ODT的元素的测量对象的XCP地址。

DAQ列表（List）：

这是一个ODT的集合。这决定了在一个同步测量的周期或者事件触发时要测量的内存数量。ODT与一个DTO报文相关联，由MAX\_DTO - PID决定了最大的大小，但由于实际测量的内存可能会大于此值，因此分为了ODT和DAQ列表。

事件通道（Event Channel）：

在同步测量的控制周期和事件触发的通道，也即是“种类”的意思。同步测量的时序都是基于这个事件通道的。

### 同步测量的处理 ###

下面将说明，在同步测量中，ECU的控制应用程序向从结点发送测量的时机，将执行怎样的处理。

（1）控制应用程序要通知从结点测量时机。这个通知通常是将事件通道作为参数，来调用从结点的驱动过程来实现的。  
（2）针对主结点以ODT条目来指定的测量对象的内存地址，从结点使用缓冲区来管理，在每次被控制应用程序调用时，都会根据该缓冲区来读取指定地址的内存。  
（3）读取的内存以ODT为单位合并，并以DAQ列表来生成DTO报文。

图16展示了，元素和ODT条目、DAQ列表和ECU控制应用程序之间的关系。当ECU的控制应用程序集成了Vector的从结点驱动程序后，调用C语言函数“XcpEvent(事件通道)”，就会根据ODT条目的缓冲区，从ECU内存中读出元素的值来创建出DTO报文。

![20171220195018849][]

图16：XCP和控制应用程序的关系

###  ###

### 测量对象和DTO报文 ###

图17展示了，作为测量对象的元素从在ECU内存，到在网络上传输的DTO报文之间的关系。

![20171220195101794][]

图17：元素和DTO报文的关系

在图17中，是根据ODT条目测量的七个元素的结果，取出的“0x19”“0x6C”“0xF0”“0xBF”“0xC0”“0xA9”“0x02”，作为一个ODT的DTO报文就创建好了。在这个DTO报文中，PID包含在第一个字节，测量时元素的内容被包括从第二个开始的字节中。像这样的，PID的值是从“0”到“0xFB”的DTO报文被称为“DAQ”。

就像这样，从作为测量对象的ECU内存、管理测量对象的ODT的DAQ列表、决定测量时机的控制应用应用程序和用于区分测量时机的事件通道开始，到最后使用DTO报文将测量数据发送到主结点，就实现了同步测量。

### 同步测量的选项 ###

除了上面描述的那些之外，根据测量的规模和用途，还有XCP同步测量的各种使用形式。下面将介绍这些使用形式中比较典型的例子。

动态DAQ：

通过增加管理测量目标的DAQ列表中的ODT及其条目的数量，可以增加测量的测量点的数量。而且通过维持与要测量的事件通道数量一样多的DAQ列表，可以对ECU的所有测量时机进行测量。但是这些数量的增加会增大ECU中的管理缓冲区，因此会消耗ECU的内存。

而且如果ECU具有10ms和25ms的控制周期，有的10ms的控制周期中测量的测量点的数量很大，别的25ms的控制周期中测量的测量点的数量也很大，根据测量的场景不同，测量点的数量会有不同。对于这样的应用程序，有一种称为“动态DAQ”的功能，可以允许从结点动态更改每次测量的DAQ列表、ODT和ODT条目的数量。相反的，如果在集成XCP驱动程序时，这些数量是预先确定的，则称为“静态DAQ”。一个从结点将具有静态或动态DAQ功能。

带时间戳的DAQ：

在主从结点间的通信中，如果因为加入网关而造成时间差，又或者因为使用无线通信，使得通信时间出现波动的情况下，同步测量中的测量时间对于主结点来说是“不确定”的。为了防止这种情况，要使用“带时间戳的DAQ”。在从结点侧，包含测量时间的时间戳的DAQ，通过DTO报文传送给主结点。而收到这个报文的主结点，可以读出所添加的时间戳来知道正确的测量时间。

### 校准 ###

校准是为了重写ECU内部软件中的参数，而从主结点发送指定XCP地址的命令和重写数据的命令，从结点会对应的导出适当的参数地址、执行重写，并返回一个应答。图18显示了，根据XCP主结点发送的XCP扩张地址“0”、XCP地址“0x0041D5C8”，将该地址开始的2字节的参数，重写为“0x0064”的示例的跟踪结果。

![20171220195219673][]

图18：通过DOWNLOAD命令的校准

###    其它的XCP功能 ###

XCP仅在测量/校准方面就还有很多的功能。除了这次我们介绍的之外，还包括诸如对ECU中的闪存之类的非易失性存储器的访问功能、对ECU的访问保护的功能等许多功能。

到这里，已经详细解释了XCP协议通信的机制和功能。接下来将介绍“[XCP趋势和应用实例][XCP 1]”。

[XCP]: http://download.vector-japan.co.jp/portal/medien/cmc/beginners/For_Beginners_XCP.pdf
[20171220193731012]: /images/20220519/54a2c29abde04533992f456e495a6c35.png
[20171220193757869]: /images/20220519/446f877286ca46aeaf7f5439e0a28593.png
[20171220193835468]: /images/20220519/a21410badb1244ca9979e06e3692813f.png
[20171220193956217]: /images/20220519/25a05d30f66b4280a6741552a20b853a.png
[20171220194034842]: /images/20220519/ccc56796cbb449ebb7aaf0ab2f2fc35b.png
[20171220194142287]: /images/20220519/b1926d0f2839472897f78114b2e8b76d.png
[20171220194229706]: /images/20220519/b5d72617bee5469bbea5bc653875441f.png
[20171220194405042]: /images/20220519/b25dc90a1f344c8d912ced57172fc4bb.png
[20171220194610101]: /images/20220519/2488a3f6d9944fe7b4de7043ea4fe9e8.png
[20171220195018849]: /images/20220519/039d73cb864e4810906d2e1eb0183ccf.png
[20171220195101794]: /images/20220519/f807dac616c34f759cd8e04054a8f379.png
[20171220195219673]: /images/20220519/770f47af18b94f809dfdde454b3b770b.png
[XCP 1]: http://blog.csdn.net/nibiewuxuanze/article/details/78882760