| 概述 
        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等技术领域的设计和测试咨询服务,积极研发和探索车载网络前沿技术的工程应用。通过多个项目的实践经验,已建立了高质量、本土化的设计与测试一体化解决方案,为整车网络架构提供可靠支持。
 
 |