什么，以太网能传CAN报文？

概述

IEEE 1722（AVB/TSN协议族中的核心协议）不仅定义了基于以太网的音视频流传输格式（AVTP-AAF），还包含了一套关键的控制协议—AVTP Control Format（后文简称ACF），为控制指令在车内网络不同控制节点间的传输提供了新的选择。

通俗来讲，ACF就是将目前较为成熟的控制协议（如CAN、LIN、FlexRay甚至是RS232串口指令等）进行封装，使这些控制指令能基于以太网进行传输。这样部分控制器既能保留原有协议实现，又能利用以太网TSN 时间同步、流预留等实现，保证控制指令精确执行。

ACF报文按“时效性”分为两类，报文格式有所区别，分别适应不同控制场景需求。具体为：
? NTSCF（Non-Time-Synchronous Control Format）:此类控制报文无时间戳字段，不携带时间戳信息，适用于对时间要求不敏感、轻量化的控制指令。
? TSCF（Time-Synchronous Control Format）: 此类控制报文携带“展示时间戳”信息，适用于需要多执行器协同控制的时间敏感场景（应用示例如下图所示）。

ACF TSCF 应用示例图

报文格式

ACF 报文和AVTP音视频报文一样，基于以太网二层进行传输，其报文在整个以太网帧中的结构如下图所示。

ACF 以太网帧结构示意图

从图中可以看出，对于NTSCF和TSCF这两种报文，是通过不同的ACF AVTPDU Header来区分的，其携带的ACF Msg在报文格式上是没有区别的。接下来分别介绍ACF NTSCF Header、TSCF Header和ACF Message 这三部分的报文格式。

ACF NTSCF Header

NTSCF Header报文结构示意图

? subtype
表征当前AVTP报文的类型。在NTSCF Header中，该字段固定为0x82；在TSCF Header中，该字段固定为0x05。
? sv (stream_id valid)
该字段用来表征当前报文的stream_id是否为有效流预留id。当sv=1时，即说明该stream_id对应的数据流已通过TSN的流预留协议分配了网络带宽资源。
? version
版本号，和其他所有AVTP报文一致，固定为0。
? r (reserved)
预留字段。
? ntscf_data_length
表征当前报文携带的所有acf_payload的总字节数，该字段的取值范围取决于当前网络的MTU（最大传输单元，Maximum Transmission Unit）。
? sequence_num
表征当前ACF 报文在同一个stream中的序列号，listener端可以通过该字段检测丢帧和乱序。
? stream_id
用来做流识别的报文流ID，同一个流的ACF报文stream id需保持一致。

ACF TSCF Header
ACF TSFC Header中携带时间戳信息，报头格式为通用流报头（common stream header），各字段含义已经在上一篇AAF介绍的文章中进行介绍。我们这次只关注和时间相关的avtp_timestamp字段。

TSCF Header报文结构示意图

? avtp_timestamp
当tv=1时，该字段的值为有效时间戳信息，含义为talker指示listener执行该控制指令的精确时间。

ACF Message
ACF Message是承载具体控制语义的核心内容，紧跟在前面介绍的两种Header后面。一帧AVTP报文中可以携带一个或多个ACF Message。而每一个ACF Message报文也可以拆成ACF Message Header和ACF payload两部分。如图所示。

ACF Message 结构示意图

ACF Message Header包括acf_msg_type和acf_msg_length两个字段：
? acf_msg_type
该字段描述了ACF Message的类型，ACF Message可以封装不同类型的控制报文格式，例如常见的CAN、LIN、MOST等，目前协议支持的类型见下表。

? acf_msg_length
因为ACF AVTPDU中可以携带多个ACF Message，通过该字段可以得知当前ACF message的长度，便于listener端解析，需要注意的是，该字段的单位为4bytes。
acf_msg_payload也包含了多个字段，报文格式根据其封装的控制报文类型有所不同，但是和原控制协议基本保持一致。本文则以目前常见的CAN(FD)协议为例，介绍ACF_CAN的payload报文格式。

ACF_CAN message 的payload如下图所示。

ACF_CAN message payload结构示意图

? pad
表示填充长度，单位bytes，目的是保证整个ACF_CAN Message的整体长度 为4字节对齐。
? mtv
message_timestamp_valid，表征当前报文是否携带有效报文时间戳。
? rtr
remote_transmission_request，表征当前报文是否为远程帧。
? eff
extended_frame_format，表征当前报文是否为扩展帧。
? brs
bit_rate_switch，比特率开关。
? fdf
CAN flexible data-rate format，表征当前报文是否为CANFD报文。
? esi
error_state_indicator，表征当前是否存在错误帧。
? can_bus_id
网段ID，由OEM指定，若不指定，默认为0。
? message_timestamp
报文时间戳，当mtv=1时，该时间戳有效，为当前控制指令被接收/生成的时间，需要和TSCF Header中的avtp_timestamp区分。
? can_identifier
can报文id，11bit标准帧或者29位扩展帧。
? can_msg_payload
携带具体的控制信号（CAN协议：0~8字节；CANFD协议：0~64字节，均需要4字节对齐）。

总结

本文主要介绍了IEEE 1722协议中的ACF部分，分别介绍了时间不敏感的NTSCF和时间敏感的TSCF两类报文，并讲述了如何在以太网报文中传输传统控制指令，希望读者能对ACF的应用以及报文格式有个基本概念。

经纬恒润作为OPEN联盟会员和AUTOSAR联盟的高级合作伙伴，长期为国内外各大OEM和供应商提供涵盖TCP/IP、SOME/IP、DoIP、AVB、TSN、DDS等技术领域的设计和测试咨询服务，积极研发和探索车载网络前沿技术的工程应用。通过多个项目的实践经验，已建立了高质量、本土化的设计与测试一体化解决方案，为整车网络架构提供可靠支持。