目录
1.寻址方式
2.数据帧格式
3.特殊指令
4.使用实例
了解了 SOME/IP 之后,继续来看看车载以太网在汽车标定领域的应用。
在汽车标定领域 XCP 是非常重要的协议,咱们先来回顾下基础概念。
XCP 全称 Universal Measurement and Calibration Protocol,主要作用就是对 ECU 进行数据标定和数据采集,加速 ECU 的开发。
既然是通用协议,理论上使用任何物理总线进行数据传输都是可以的;此外,XCP 是由 CCP(CAN C alibration Protoco)V2.1 版本演变而来,因此 XCP 的"X"代表了多种传输层,例如 XCP on CAN、XCP on TCP/IP、XCP on UDP/IP、XCP on USB,如下图:
那么从这个逻辑出发,我们也能分析出,XCP 协议总体可分为两大部分:
- 基础通用协议,包括协议描述、A2L 接口描述、Seed&Key 接口描述、通信示例等等;
- 传输层协议,包括 XCP on CAN\Ethernet\SPI\USB 等等数据传输的描述。
基础通用协议我们前面已经聊得很多了,今天看看 XCP on Ethernet 的一些特点。
1.寻址方式
首先回顾下 XCP 的通信模型:
这张图很多人搞混淆,认为 Master 可以使用一个 ID 同时和不同Slave 节点通信,实则不然(瞬间打脸,例外:Master 通过 CAN\ETH 发送 GET_SLAVE_ID 获取在线的 Slave 等);
实际上,XCP 是标准 Single-Master/Single-Slave 的通信,即 Master 在建立通信连接时,是需要特定的 slave ID,进行点对点且连续的连接,此外关闭连接时也要通知 Slave。
但是,在上图中可以看到 XCP 它是允许同时建立多个 Single-Master/Single-Slave 通信,例如,Master 不同的 CAN ID,发送相同连接指令给到不同 Slave,如下:
这是最常见的 XCP on CAN 的寻址方式。
那么假设传输层使用以太网呢?这就需要 IP 地址和端口号(Port Number)。根据通信协议又可以分为 TCP/IP 和 UDP/IP。
- TCP/IP:Slave 一直处于监听状态,当然一次只能接受一个连接,由于该协议本身面向连接,且具备重传机制,因此可以防止数据丢失;
- UDP/IP:当 Slave 未连接时,接收到 CONNECT 命令时是向命令发送方给定的 IP 地址和端口发送回复进行相应,对于所有后续响应,它将继续响应此 IP 地址和端口。当连接时,即使使用另一个端口,它也只响应来自发送 CONNECT 命令的 IP 地址的信息。
2.数据帧格式
我们首先将 XCP 帧从车载以太网传输层(Layer4)解封装出来,如下:
根据标准,其中细节如下图所示:
与 XCP on CAN Message 相比,以太网帧多了一个 XCP Header,即以太网控制域。
以太网控制域参数包括 LEN、CTR,长度 WORD(XCP中2byte)。
LEN:表示 XCP Packet 的数据长度,单位为 Bytes;
CTR:用于检测丢包。TCP/IP 丢包后可重传,因此这个位域主要为 UDP/IP 服务,Master 在发送第一条消息时,CTR 进行自增;Slave 在本地维护同样的计数器,以相同方式响应,每发送一帧就增加自己的计数器。这和 SecOC 维护 FvM 比较类似,为了发挥 UDP/IP 本身的性能,一般用于数据采集,当然丢帧会产生测量间隙,如果确实影响了观测,建议使用 TCP/IP。
3.特殊指令
既然是基于以太网进行数据传输,在指令上也会有所变化,具体包括了如下几条指令:
- GET_SLAVE_ID
Master 发送该指令,用于探测 Slave 节点,因此只能用于UDP/IP。具体来讲,主机发送一条 IPv4 的多播消息,IPv4 地址固定为 239.255.0.0,端口号固定为 5556,无论 XCP Slave 是否已经与 Master 建立了连接,Slave 都必须处理请求并返回响应,响应的信息包括从机 IP 地址、端口号、Slave 自身是否可用、使用 TCP 还是 UDP 或者都全部使用等。
- GET_SLAVE_ID_EXTENDED
获取 slave 的额外信息,主要是 MAC 地址等;
- SET_SLAVE_IP_ADDRESS
该指令用于 Master 给 Slave 分配 IP 地址,当然这个 IP 地址就是自定义,不在标准范围。Slave 也需要进行响应,保证 IP 地址是否有效,是否需要手动激活 IP 地址等;
- GET_DAQ_CLOCK_MULTICAST
该指令主要是 Master 需要更好关联多个 Slave 的时间,因此需要同一传输总线的 Slave 在同一时刻返回一个时间戳。这个比较理想化,不仅需要每个 Slave 响应速度一致,还需要 Slave->Master 的传输延迟一致。
Master 下发指令后,Slave 会回复 EV_TIME_SYNC(该帧带有时间戳) ,如下所示:
EV_TIME_SYNC 报文格式如下:
4.使用实例
目前来看,XCP on Ethernet 主要用于高速测量和标定系统,通信速率可达 50MBytes/s,实现方法可以参考 Vector 的 POD 技术或者 ETAS 的 ETK 技术。
以 Vector VX1000 为例,它为 ECU 的 XCP on Ethernet 提供了可能。首先这个硬件盒子自带以太网端口,其次 Vector 针对主流车规 MCU 设计了 POD 硬件,该硬件可通过 Debug 接口(例如 DAP、JTAG、Nexus)等接口直接访问 ECU 的数据并返回给 VX1000 这个小盒子,换句话说,CANape 是上位机作为 Master,VX1000+POD 作为 Slave,因此理论上讲 ECU 内部就不需要再实现 XCP on Slave 的软件协议栈。如下图所示:
看到这里,不由得想到英飞凌 TC4xx 在 Trace 设计时特意数据传输路径给到 ETH,只需要 XCP Slave 的实现,就可以不用 POD。
看来从芯片的迭代和设计上也能看到芯片厂、Tier 1 、OEM 之间的博弈。
END
作者:快乐的肌肉
来源:汽车MCU软件设计
推荐阅读:
更多汽车电子干货请关注汽车电子与软件专栏。欢迎添加极术小姐姐微信(id:aijishu20)加入技术交流群,请备注研究方向。)