车载以太网中 AVTP 与 CAN over AVTP 技术详解
AVTP 简介：AVTP（Audio Video Transport Protocol）是 IEEE 1722 标准定义的一种面向时间敏感网络（TSN）的链路层传输协议，用于在以太网上承载音频、视频以及控制数据等流媒体通信。它最初是汽车和专业音视频领域为了满足同步、低时延、高可靠性传输需求而提出的。AVTP 起源于 IEEE Audio/Video Bridging (AVB) 框架，是 AVB 标准家族中的关键组成：AVB 技术组合了 IEEE 802.1AS（精准时钟同步，gPTP）、802.1Qav（队列整形，FQTSS）、802.1Qat（流预定协议，SRP）以及 IEEE 1722（AVTP）等标准，实现了交换式以太网上端到端的同步低延迟音视频传输。2012 年起，AVB 工作组扩展为 TSN 工作组，范围从多媒体拓展到更广泛的工业与汽车实时通信。因此 IEEE 1722 的地位也从单纯的音视频传输协议，演进为TSN 网络中的通用时间敏感数据传输协议，能够统一承载同步音频、视频以及各种控制流。
为何引入 ACF-CAN：随着车载以太网在整车中的采用，传统车载总线（如 CAN、LIN 等）的数据需要在以太网背骨网上传输，从而实现分区/域控制架构下各 ECU 之间的互联。这促使 IEEE 1722 在 2016 年修订版中引入了 AVTP Control Format (ACF) 控制格式，以封装 CAN、LIN 等遗留总线的信息。换言之，ACF 的出现使 AVTP 不仅能传送音视频流，还能桥接传统车载网络数据（如 CAN 报文）至 TSN 以太网。相比直接在应用层使用 UDP 或 SOME/IP 转发 CAN 数据，采用 AVTP 的 ACF 格式具有更低的开销和确定性：它在链路层直接封装，多报文打包传输减少开销，并利用 TSN 的时间同步和调度机制保障实时性。这正是引入 ACF-CAN 的原因——为汽车以太网提供统一且高效的控制数据隧道，方便各 ECU 透明地传输 CAN/LIN 信息，逐步融合传统总线和以太网网络。IEEE 1722-2016 标准定义了 ACF 的具体格式和机制（详见下文），为 CAN 报文 over Ethernet 提供了标准方案。
标准演进：IEEE 1722 标准最初发布于 2011 年（AVTP 1.0），主要支持音视频流格式（如 IEC 61883-6 音频、MPEG-TS 视频等）。2016 年发布的修订版 (IEEE 1722-2016) 扩展了大量新功能，特别是加入了 ACF 控制格式子类型，用于汽车控制类通信。此外还新增/完善了AAF（AVTP 音频格式，用于原生音频帧传输）、CVF（压缩视频格式，例如 H.264）、CRF（时钟参考格式）等，以适应专业视音频和汽车领域的新需求。与此同时，与 AVTP 配套的1722.1 (AVDECC) 标准也在完善，用于设备发现和控制。总的来说，IEEE 1722 标准的发展体现了从面向多媒体的 AVB，到面向综合数据流的 TSN 转变的历程。在汽车领域，AVTP/1722 正迅速成为车载以太网传输不可或缺的部分——它提供了统一承载音视频与控制流的框架，满足下一代车辆对于大带宽、多业务融合、确定性通信的需求。
AVTP 协议核心机制详解
AVTP 概述：AVTP 在以太网数据链路层直接承载流媒体数据，其以太网 EtherType 为 0x22F0（IEEE 1722）。AVTP 数据包（AVTPDU）遵循类型-长度-值（TLV）编码结构，由通用报头和负载组成。报头的核心字段之一是 Subtype（子类型），用于指示负载所承载的协议/数据格式。例如，0x00表示 IEC 61883/IIDC 媒体流，0x02表示 MMA（MIDI 等）负载，0x6A表示 AAF 音频格式，0x78表示 CVF 视频格式，0x7D保留，0x7E对应 MAAP 地址分配协议，0x7F为实验类型等。Subtype 决定了后续 AVTPDU 的报文格式解析方式。除了 subtype 外，AVTP 通用报头还包含协议版本、指示流 ID 是否有效的标志位 (SV)、表示时间戳有效性的标志位 (TV) 等，以及序列号、时间戳、流 ID等字段。对于流媒体子类型（音频、视频等），报头中包含一个AVTP 演示时间戳 (Presentation Time) 和有效负载长度等，用于同步和缓冲控制；而对于控制子类型（如 NTSCF）则可能采用精简报头格式（后述）。整体而言，AVTP 报头提供了统一且可扩展的元信息，使接收端能依据 subtype 正确解析负载并按时间同步播放或处理。
时间戳与同步机制：AVTP 的一大特色是引入演示时间 (Presentation Time)概念，用于实现跨设备的媒体同步。对于音视频流或时间敏感控制流 (TSCF)，每个 AVTPDU 帧都携带一个基于全局时间的演示时间戳，表示帧中数据应在接收端呈现/生效的时间点。该时间戳采用与 gPTP (802.1AS) 精准时钟同步协议相同的时基（通常是国际原子时，纳秒计时），从而确保所有网络节点理解一致的绝对时间。AVTP 发送端（Talker）在发送帧时，会获取当前同步时间（通过 AUTOSAR 的时间服务模块 StbM 或 Ethernet Interface 提供的当前时间），并加上一个最大传输延迟 (Max Transit Time)后填入演示时间戳。Max Transit Time通常由网络中最大传播延迟和缓冲时间决定（例如 AVB Class A默认2ms），用以确保帧在该时间之前能够到达接收端。接收端（Listener）收到帧后，将比较帧内时间戳与本地同步时间：若帧提前到达（当前时间尚未达到演示时间），Listener 将缓存该帧至时间届满再交付上层，从而实现多流同步播放；若帧滞后到达（已错过时间戳），则可能丢弃或视为延迟帧处理。在控制流场景下，这意味着例如多个ECU可基于全局时间同时触发动作。总之，借助 gPTP 提供的亚微秒级精度时间基准，AVTP 的时间戳机制可以实现跨节点的严格同步和延迟控制。
多播地址与 MAAP：AVTP 流通常使用以太网多播地址进行传输，每一路 AVTP流分配一个唯一的多播目的MAC地址。使用多播有两个好处：一是便于一对多（广播/组播）场景，多个 Listener 可订阅同一流；二是不干扰传统单播 MAC 地址，从交换机角度可隔离流量。IEEE 1722 标准为 AVTP 流保留了一段专用的多播 MAC 地址范围。根据标准：91-E0-F0-00-00-00 至 91-E0-F0-00-FD-FF 范围属于 MAAP 动态分配池，供协议运行时动态选择地址；而 91-E0-F0-00-FE-00 至 91-E0-F0-00-FE-FF 则留作 本地管理池（可用于静态配置）。通常，每个AVTP Talker设备在启动流时，会使用 MAAP (Media Address Allocation Protocol) 来获取一个空闲的多播地址。MAAP 是 IEEE 1722a 定义的简单协议：Talker 在动态地址池中随机挑选一个候选多播地址，发送 Probe 报文探测是否冲突，若无人应答则宣布使用该地址。如果冲突，则可重试其他地址或协商解决。通过 MAAP，设备无需手工配置每条流的 MAC 地址，避免多个流间地址冲突问题。需要静态配置时，也应从保留池 (FE:00-FE:FF) 中选取，并确保网络中唯一。Stream ID：此外，每条 AVTP流还有一个全局唯一的 Stream ID（64位），通常由 Talker 的 MAC 地址（48位）与一个 16位的流唯一编号拼合而成。Stream ID 在AVTPDU报头中携带，用于区分不同流的数据，也用于Listener过滤识别流。在有 Stream Reservation Protocol (SRP) 的网络中，Listener 会根据期望的 Stream ID 和多播地址订阅流量。简而言之，AVTP通过多播MAC+Stream ID机制实现了对不同媒体流的区分和管理：多播 MAC 定位流的传输地址，Stream ID 则保证从报文级别唯一标识流。开发者应确保每条流MAC和ID配置正确唯一，以免出现冲突（详细讨论见调试陷阱部分）。
报文结构与类型扩展：不同 subtype 的 AVTPDU 在通用报头后有各自特定的 header 和 payload 格式。例如音频流 (AAF) 和视频流 (CVF) 都有固定长度的通用流头，包含序号、时间戳、格式信息等；而非时间敏感控制格式 (NTSCF) 等则使用备用头，去除了时间戳等字段以精简长度。AVTP 协议设计非常灵活，可通过 subtype 拓展新的格式类型而不影响现有实现。比如 1722-2016 就扩展了多个子类型：AAF 用于未压缩音频（PCM、AES3 等）的传输；CVF 用于压缩视频（如 H.264、MJPEG）帧的传输；CRF 用于传递时钟参考（例如音频采样计数），帮助接收端锁相本地时钟；以及下节将详述的ACF 控制格式等。值得注意的是，AVTP 不包含发现、连接管理或流控制等功能——这些由 IEEE 1722.1 (AVDECC) 和 802.1Q 等其他协议负责。AVTP 专注于高效承载数据，因此也被形容为“batteries not included”（不带电池）协议。综合而言，AVTP 提供了一个轻量级且高度同步的传输层，把 TSN 网络在链路层的能力充分利用起来：精确定时（Presentation Time）、带宽预留（SRP/Qav）、多播分发和统一格式，使得音视频和控制数据都能以统一格式在汽车以太网上可靠传输。
CAN over AVTP：封装结构、时间同步与报文类型
AVTP 控制格式 (ACF)： 在 IEEE 1722-2016 中新增的 AVTP Control Format (ACF)，专门用于封装各类控制总线数据（汽车控制通信）。ACF 被设计为 AVTP 的一个 流数据子类型，实际包含了两种具体格式：时间敏感控制格式 (TSCF) 和 非时间敏感控制格式 (NTSCF)。这两者可以理解为 ACF 的两个子类流类型，对应是否携带全局时间戳。ACF 流 (ACF-stream)指的就是 subtype 为 TSCF 或 NTSCF 的 AVTP 流，其负载中承载一个或多个ACF 消息 (ACF-message)。每个 ACF 消息对应一帧封装的总线报文（如 CAN 帧或 LIN 帧），带有自己的类型标识和长度信息。多个 ACF 消息可以级联封装在一个 AVTP 帧的有效载荷中，从而实现将多条总线报文批量打包通过一个以太网帧发送。这种批处理机制降低了协议开销，对于 CAN 这类小数据帧非常有利。ACF 消息头使用 16 位字段，其中 7 位标识消息类型（如 CAN、CAN_BRIEF、LIN 等），9 位表示该消息负载长度。通过这个机制，1722Tp 可以在发送时动态将多条 CAN 消息组成一个 ACF 有效载荷，提高带宽利用率。
ACF 消息类型： IEEE 1722 定义了若干种 ACF 消息类型，涵盖常见车辆总线：
ACF_CAN： 标准 CAN/CAN FD 帧封装格式。包含完整的 CAN 标识符、帧数据和附加的时间戳字段。ACF_CAN 消息头和负载总长度较长，用以携带精确时间信息（下述）。适合需要时间同步的场景。
ACF_CAN_BRIEF： 精简的 CAN/CAN FD 帧封装格式。与 ACF_CAN 不同，不含单独的消息时间戳字段，因此消息头开销更小。适合不需要逐帧精确时间标记的场景。使用 ACF_CAN_BRIEF 可以进一步压缩数据量。据统计，对于传统 CAN 帧，使用 CAN_BRIEF 封装每帧可比完整封装节省约 8 字节（NTSCF 头12字节 vs TSCF头24字节）。
ACF_LIN： LIN 帧封装格式，用于传输 LIN 总线的数据。LIN 帧通常8字节数据，ACF_LIN 类似 CAN_BRIEF，也是不带额外时间戳的简洁封装。
此外，ACF 设计可扩展，未来还可加入其他总线类型（例如有提案增加 I2C、SPI 等 ACF 类型以远程访问外围设备）。ACF_CAN 与 ACF_CAN_BRIEF 区别在于是否携带时间戳字段：ACF_CAN 在其消息头中包含一个独立的 message_timestamp 字段，用于标记该 CAN 帧的事件时间；而 ACF_CAN_BRIEF 明确无时间戳。在实际应用中，如果需要保留每条 CAN 消息发生的精确时间（例如为了在接收端重构原始时间顺序，或实现分布式控制的时序一致性），应使用 ACF_CAN + TSCF 模式传输，以利用时间戳；反之，如果对单帧时间要求不高且希望减少开销，可以使用 ACF_CAN_BRIEF + NTSCF 模式。
TSCF vs NTSCF：TSCF（Time-Sensitive Control Format）和 NTSCF（Non-Time-Sensitive Control Format）是 ACF 流的两种模式。TSCF 模式的 ACF 流在 AVTPDU 的头部采用与音视频流相同的通用流报头格式，其中包含 AVTP 演示时间戳等字段。因此，一个 TSCF 类型的 AVTP 帧除了封装多个 ACF 消息外，还带有该帧整体的演示时间，表示这些控制消息在全局时间轴上的参考时间点。更重要的是，每条 ACF_CAN 消息内部也包含各自的时间戳，常用于更高精度的时间标记（如在帧内不同 CAN 消息的细粒度时间）。总体来说，TSCF 提供了时间同步保障：Talker 会基于当前 gPTP 时间戳计算并设置演示时间，Listener 收到后若当前时间尚未达到演示时间，将缓存等待，从而确保多个控制节点对这些消息的处理同步进行。相反，NTSCF 模式则不携带全局时间戳。NTSCF 类型的 AVTPDU 采用简化的备用报头格式，将时间戳字段移除，使头部开销减半（12 字节）。NTSCF 模式下，封装的 ACF_CAN_BRIEF 消息也无逐条时间戳。这样 Listener 收到帧后可以立即交付消息，不做延时同步。因此 NTSCF 适用于无需严格时间对齐的控制通信，例如一般状态量或诊断信息广播，在节省带宽的同时容忍少许时序偏差。
与 gPTP 的协同机制：无论 TSCF 还是 NTSCF，都运行在 gPTP 提供的网络时间基础上，只不过 TSCF 会显式利用时间同步信息。对于 TSCF 流，1722Tp 模块在发送每个帧时都调用时间同步服务获取当前同步时间，并在帧头填入相应时间戳。这些时间戳使接收端能够结合 gPTP 时钟，将不同ECU发来的控制指令对齐到统一时间基准执行。例如，在线控底盘场景中，多ECU通过 TSCF 发布转向/制动指令，各指令的演示时间基于全局时钟一致，接收端（执行机构ECU）据此可确保动作同时发生。对于 NTSCF，没有帧级时间戳，控制消息按到达顺序即时处理，时延仅取决于网络传输和调度本身。需要强调，如果网络中时钟同步不稳定或偏差过大，TSCF 帧可能会出现 Listener 无法正确对时的问题（例如帧标记时间落在Listener当前时间过去很久以前或远未来，Listener可能丢弃该帧）。因此在使用 TSCF 模式时，必须确保网络中 gPTP 同步正常，所有节点处于同一时间域且误差在限定范围内（通常亚微秒级）。ACF 另一与同步相关的点是传输调度：1722Tp 在发送 TSCF 帧时，会根据Max Transit Time将演示时间设置为当前时间略微偏后。这意味着 Listener 常常提前收到该帧，于是会缓存等待到时间再释放。如果由于网络拥塞帧迟到了，Listener超过演示时间收到帧，则可能报废。因此，为了减少迟到风险，一方面要求 TSN 网络保障最大延迟（例如使用信用状形器保证不拥塞），另一方面 Sender 往往会留有余量设置 Max Transit Time。总之，1722Tp 与 gPTP 的协同使 CAN 等控制报文在 TSN 以太网上具有准确定时特性，这在以统一时间尺度来控制车辆分布式部件时非常关键。
封装结构示意： 下图展示了两个 ECU 通过 AVTP ACF 实现 CAN 报文的传输过程，其中 ECU A 将本地 CAN 总线收到的一帧报文封装发送，ECU B 解封后注入其本地 CAN 总线：
图 1：1722Tp 模块桥接两段 CAN 总线示意流程。1722Tp 可将多条 CAN 报文打包进一帧发送，提高带宽利用率。接收端按需缓存等待同步时间，再输出到CAN。
在 AUTOSAR CP 中，这种跨网络路由由 PduR/LSduR 完成：ECU A 的 PduR 将特定 CAN PDU 路由至 1722Tp（而非传统 CanIf），1722Tp 封装经 EthIf 发出；ECU B 侧 EthIf 收到帧后，1722Tp 解封得到 CAN PDU，通过 PduR (或 LSduR) 调用 CanIf 将其注入 CAN 网络。整个过程对高层应用而言透明，从而实现 CAN 网络的虚拟延伸和融合。
AUTOSAR CP R24-11 中的 1722Tp 模块解析
AUTOSAR Classic 平台在最新的 R24-11 版本中正式引入了 IEEE1722 传输协议模块（1722Tp）。该模块作为 AUTOSAR COM 栈中新的传输层，实现 AVTP 协议以及 ACF 控制流的处理。下面从模块职责、接口集成、配置方法等方面进行解析。
模块职责与功能概览
1722Tp 模块的核心职责是：处理 IEEE1722 相关流的发送请求和接收指示，并将 AVTP 报文头信息和有效载荷据需转发到正确的目标模块。简单来说，它充当在AUTOSAR各上下层之间的枢纽，保证符合1722标准的封装和解封装。具体包括：
流媒体数据转发： 对于配置的 AVTP 音视频流（子类型 AAF、61883_IIDC、RVF 等），1722Tp 接收来自上层“流数据生产者”（可能是音频或视频应用）的传输请求，将其封装成1722帧发送；同时接受来自下层的收包通知，将帧解封后转交本地的“流数据消费者”处理。这覆盖了传统 AVB 中音频、摄像头视频流的发送和接收工作流程。
时钟同步数据转发： 对于 CRF 时钟参考流（Clock Reference Format），1722Tp 支持从“媒体时钟提供者”获取CRF数据帧发送，以及将收到的CRF帧交给本地“媒体时钟使用者”以同步本地时钟。CRF 流通常由播放设备产生，用于校准各节点音频采样率等。
总线报文隧道：1722Tp 最重要的新功能是在AUTOSAR中隧道传输 CAN/LIN 等总线帧。具体而言，对于来自下层总线（如 CAN）的L-SDU数据，1722Tp 模块通过 LSduR 接收到传输请求，将其封装成对应类型的 ACF 消息（ACF_CAN/BRIEF 或 ACF_LIN），加入已配置的 ACF 流，按配置的触发条件发送。反过来，对于收到的 AVTP ACF 控制流帧，1722Tp 会检查帧头、解析其中的 ACF 有效载荷，拆解出各独立的 ACF 消息（可能包含多条 CAN/LIN 报文）。然后根据配置，1722Tp 可将这些解封的L-SDU通过 LSduR 排队，转发给对应的目标模块——比如，CAN 报文就转发给本地产生该ID的上层或相应的 CanIf。通过这种机制，1722Tp 起到了不同通信栈之间的桥梁作用：它让汽车以太网能够透明地承载各类传统总线通信。
概括来说，1722Tp 模块支持五种AVTP流：音频 (AAF)、视频 (IIDC/RVF/CVF)、时钟 (CRF)、控制 (ACF)。它既能充当纯粹的流媒体转发层，也能封装/解封控制消息，完成协议间的数据搬运。AUTOSAR SWS 明确指出1722Tp 可将不同协议的数据通过 ACF 消息隧道传输——例如在一个 ACF 流中串行化多条 CAN/LIN 报文。这对于域控制器中需要汇聚多个 CAN/LIN 网络的场景十分关键。
通信接口与 LSduR 集成
1722Tp 模块位于 AUTOSAR 通信栈中间，与上下层通过接口函数交互（类似于 CanTp、FrTp 等传输协议模块）。但与传统 TP 不同的是，1722Tp 涉及多个不同类型的通信层：上层可能是 PduR（来自 COM 或其他应用的数据单元），下层是 EthIf（Ethernet Interface），还有横向与各总线接口的联系。为此，AUTOSAR R24-11 引入了一个新的LSduR（大 SDU 路由）模块，将1722Tp的通信接口纳入其中统一处理。LSduR 可以理解为一个通用的Pdu Router，专门处理大数据单元或跨总线路由需求。1722Tp 通过调用 LSduR 提供的服务，与其他模块解耦：
当上层希望发送一个1722流的数据时（例如音频帧或 CAN PDU），会通过 LSduR 将该请求交给1722Tp 处理。1722Tp 决定将其封装到哪个1722流，并可能暂存队列或立即处理（见下节），然后再通过 LSduR 请求下层 EthIf 发送。
当下层（EthIf）收到一个以太网帧时，识别出 EtherType 0x22F0 并通过 LSduR 通知1722Tp 收到相应的 Rx PDU。1722Tp 检查帧内容：如果是普通媒体流，就根据 Stream ID 将数据交给相应的本地消费者；如果是 ACF 控制流，就提取内部的 CAN/LIN 报文，并通过 LSduR 调用上层或侧向模块。例如，针对每条封装的 CAN 报文，1722Tp 可调用 LSduR 提供的 LSduR_IEEE1722TpRxIndication，将该 PDU 转交给 PduR/CanIf 进行本地处理。
借助 LSduR，1722Tp 模块无须直接依赖 PduR、EthIf、CanIf 等具体接口，而是通过统一的 LSduR 接口完成Tx确认、Rx指示和缓冲释放等动作。这使配置上更灵活，也降低模块间耦合度。例如，当1722Tp 发送完一个帧后，会调用 LSduR_IEEE1722TpTxConfirmation 通知上层该PDU已发送完成；当1722Tp 需要释放接收缓冲时，则调用 LSduR_IEEE1722TpReleaseRxBuffer 等。
特别对于 ACF 场景，1722Tp 和 LSduR 的联动体现为：CAN/LIN 报文统一由 LSduR 在1722Tp与总线接口间传递。AUTOSAR 要求配置时，如果1722Tp的某流配置为 ACF，则不得直接配置 Upper Layer PduPool给1722Tp——换言之，上层CAN PDUs不直接挂给1722Tp，而应通过LSduR转交。这保证了CAN消息到1722Tp、再从1722Tp到CanIf的路径可灵活路由。例如，可以基于CAN ID或“Bus Id”实现路由：1722Tp 解析出ACF CAN消息后，通过LSduR查找其Bus Id对应的目标（某CanIf或PduR路径）并转发。
接口集成如上图1所示：ECU A 的 CAN Interface 将消息上报 PduR，PduR 经 LSduR 路由给1722Tp；1722Tp 封装后，通过 LSduR 请求 EthIf 立即发送。ECU B 收帧后1722Tp 解封，通过 LSduR 通知 PduR/CanIf 投递CAN消息。可以看到，LSduR 扮演了消息路由交换机的角色，极大简化了1722Tp模块与多种上下层的连接。
流配置与参数（1722Tp ECUC 配置）
配置1722Tp模块需要在 AUTOSAR ECU 配置描述（ECUC）中添加相应容器，并根据所需流类型设置参数。R24-11标准定义了1722Tp的配置模式：
1722Tp 全局配置 (IEEE1722TpConfig)：包含全局开关（如开发错误检测）、MainFunction周期等。
1722Tp 流配置 (IEEE1722TpStream)：可配置多个1722流，每个以一个 IEEE1722TpStream 容器表示。一个 Stream 通常对应一条特定的 AVTP 流（由唯一的 Stream ID 标识）。关键配置项包括：
StreamID：由两个参数给出：StreamIdMacAddress（17字节串，填写16进制MAC地址）和 StreamIdUniquePart（0~65535的整数）。这两者共同组成64位的 Stream ID，需确保在整车范围唯一（通常用本ECU MAC加一个局部流号即可）。MAC部分也用于决定多播地址（可与目的MAC一致）。
方向 (Direction)：指明该流是发送 (Tx) 还是接收 (Rx)。通常同一条流在不同ECU上方向相反，一个Talker配置为Tx，其余Listener配置为Rx。1722Tp通过方向避免重复初始化队列等。
Subtype 子类型选择：IEEE1722TpStreamSubtype 是一个多选一的容器，必须选择配置流的类型。可选值包括：IEEE1722TpStreamAAF（音频流）、...IIDC（61883/IIDC流）、...RVF（Raw Video流）、...CVF（Compressed Video流，若标准已有应增加，但AUTOSAR当前spec未列出CVF可能疏漏）、以及 IEEE1722TpStreamACF（控制流） 等。
LowerLayer PduPool：每个流需要关联一个下层PDU池（Tx或Rx）。配置项 StreamLowerLayerPduPoolRef 引用一个 IEEE1722TpLowerLayerPduPool 容器。在LowerLayerPduPool中，会配置具体的EthIf PDU ID 或引用。例如，为一个Tx流可以创建一个LowerLayer Tx PduPool，里面有一个Tx Pdu Entry，指定 LowerLayerTxPduRef 引用某EthIf内已经定义的Tx Pdu（具有目地MAC=流多播地址、EtherType=0x22F0等）；并赋予一个 LowerLayerTxPduId 句柄。Rx 类似。1722Tp 发送时会从池中获取空闲PDU缓冲填充发送。
MaxTransitTime 最大传输时间：可为每个流配置一个浮点数（单位秒），用于1722Tp计算AVTP演示时间戳。通常根据网络拓扑延迟设定，如Class A流2ms。
TxQueue/RxQueue（可选）：可在流下添加 StreamTxQueue 或 StreamRxQueue 容器各一个，配置其队列长度 QueueSize（0~255）。TxQueue激活时，该流的发送请求将先进队列，再由1722Tp主函数批量发送；若未配置TxQueue则发送请求直接同步处理。RxQueue类似地用于接收缓存，启用后1722Tp可在主循环中再逐个交付上层，而不直接在ISR中处理所有帧。这在高流量或需要平滑抖动时有用。需注意，ACF流在Rx方向一般不配置上层Rx队列，而是用内部机制作暂存同步（见后）。
UpperLayer PduPool（选配）：1722Tp支持配置上层PDU池，用于直接与PduR交换PDU。但正如前述，对于ACF流通常禁用该项，CAN/LIN报文通过LSduR路由而非静态绑定。因此 UpperLayerTxPduPoolEntry 和 UpperLayerRxPduPoolEntry 主要用于AAF/AV流场景，在ACF配置中若存在会被拒绝。
ACF 扩展配置：当选择 StreamSubtype=ACF 时，会出现附加的 ACF 参数容器：
StreamACF：ACF流通用配置，包含 AcfHeaderType（TIME_SYNCHRONOUS 或 NON_TIME_SYNCHRONOUS）用于选择 TSCF/NTSCF 模式。还包括 AcfCollectionTimeout 和 AcfCollectionThreshold 等参数，用于消息收集（bundling）策略配置。CollectionThreshold是阈值（字节或消息数）配置，当内部累计消息字节数超过此值将触发立即发送；CollectionTimeout是在队列有消息等待时的超时（秒），到时未达阈值也触发发送。这两个参数配合允许在延迟和带宽间折中：阈值小/超时短则延迟低但开销稍高，反之可提高效率但增加抖动。
StreamAcfCan / StreamAcfLin：根据需要添加，用于定义具体要封装的 CAN 或 LIN 消息类型及过滤。同一个ACF流可以封装多个ID，但出于性能考虑可按需分组。配置项包含：
BusId：标识该ACF配置对应的源总线编号（一个整车范围内约定的ID）。发送时1722Tp会在ACF消息中带上该 BusId；接收时通过BusId判断来自哪个总线。这样多路CAN可共享一个1722流而仍可区分。
CanMessageType：枚举，选择 CAN 或 CAN_BRIEF（LIN类似）。用于指示封装时用哪种ACF消息类型。若选 CAN_BRIEF 则不记录时间戳。
CanId/CanIdMask/CanIdRange：用于过滤特定 CAN 报文。如果希望只有某个ID或某范围ID通过此流隧穿，可配置过滤掩码或范围。例如，配置CanId=0x100且Mask=0x7FF则只转发11位ID=0x100的帧；配置Range则可指定起止ID段。若不配置过滤，则默认此 BusId 下所有CAN帧都封装进该流。配置规则要求：若配置了Id过滤，就不能再配置单一Id（两者互斥）；若封装的是带MetaData PDU的情况也不能使用Id（如上层已经区分）。实际配置可根据需要多个StreamAcfCan容器：例如可为不同ID范围分别配置不同ACF队列，以实现更细粒度的打包和优先级控制。
MetaData：1722TpStreamAcfCan下还可关联上层Pdu引用，但通常经LSduR实现，不直接用此配置（相应配置限制已在规范注明）。
通过上述配置，工程师可以灵活地定义1722传输流：对于音视频，可设置帧长度、发送周期、优先级队列等；对于控制流，可定义哪些CAN/LIN消息通过1722传输以及如何打包。需要注意保证每条流的多播地址和StreamID在全网唯一，以及协调好VLAN PCP优先级以符合TSN QoS（下一章节详述）。
ACF 报文收发机制与内部队列
1722Tp 模块在运行时对 ACF 控制流采取了一些特殊处理，以确保准确和高效。以下分发送和接收两方面说明其机制：
发送方向 (Talker)：当上层通过 LSduR 提交一个 L-SDU（例如CAN帧）给1722Tp后，模块会先确定该帧属于哪个已配置的 ACF 流（根据BusId和ID匹配找到对应的 StreamAcfCan 配置项）。如果该帧通过过滤条件，1722Tp 将把它封装成 ACF 消息，存入该流内部的ACF发送队列。1722Tp 针对每个 ACF流维护一个内部队列用于暂存待发送的 ACF消息（区别于上节配置的TxQueue，这是ACF自身的队列概念）。触发发送有两种条件：其一，当队列中的累计数据长度达到 AcfCollectionThreshold 时，立即封装成AVTP帧发送；其二，如果自上次发送超过了 AcfCollectionTimeout 时间，则即使未达到阈值也发送。这样设计确保在低负载时不会无限等待，也避免高负载时消息过多。发送AVTP帧时，1722Tp 会从 LowerLayerPduPool 获取空闲缓冲，按AVTP格式拼装：写入公共头（包括演示时间、序列号等，如果是TSCF模式就填当前时间+MaxTransitTime，否则NTSCF头省略时间戳）、在AVTP负载中依次写入队列里的一个或多个ACF消息，每个消息前都有自己的9-bit长度字段。需要注意，若使用 TSCF 模式且 AcfHeaderType=TIME_SYNCHRONOUS，1722Tp 给该帧赋予演示时间戳，同时也会在每个 ACF_CAN 消息内填入 message_timestamp 字段。但如果消息类型是 CAN_BRIEF，则跳过填充时间戳。1722Tp 发送完成后，会清空相应的队列（或已发送的部分），并可以继续接收新的L-SDU进入队列。默认情况下，1722Tp 不重发已发送的帧（无重传机制）——ACF应用场景多为周期性或事件广播，要求有上层应用确定可靠性策略。
接收方向 (Listener)：当1722Tp 收到一个AVTP帧（通过 LSduR 调用 RxIndication）时，会首先根据帧的 subtype 判断处理流程。如果 subtype 是 ACF (0x05 或 0x82)，则进入控制流处理。1722Tp 检查帧头以确定是 TSCF 还是 NTSCF，并据此决定是否需要使用备用头格式解析。如果是 NTSCF，说明帧无全局演示时间，1722Tp 可直接处理负载；如果是 TSCF，1722Tp 需要从帧头提取AVTP演示时间，并与本地时间比较。AUTOSAR 规范指出，对于 TSCF 模式，1722Tp 必须考虑帧内时间戳：如果帧到达时本地同步时间尚未达到帧的演示时间，则1722Tp 应将该帧的负载暂存在内部接收暂存区，等待到时再进一步处理。1722Tp 可以利用 StreamRxQueue 或内部机制来延迟交付以确保同步（实现上可能是1722Tp_MainFunctionRx周期检查时间戳）。一旦时间满足或对于NTSCF帧则立即，1722Tp 开始解析AVTP负载中的多个ACF消息：它逐个读取ACF消息头（7位类型+9位长度）以确定消息边界和类型，然后提取消息的有效载荷（如CAN报文的数据）。对于每条提取的消息，1722Tp 尝试匹配本地配置的 StreamAcfCan/StreamAcfLin 容器：匹配依据是 BusId 和消息类型（CAN/CAN_BRIEF 或 LIN）。如果找到对应配置且消息ID通过了过滤条件（或未配置过滤），则认为此消息有效；否则，1722Tp 将丢弃该消息并报告运行时错误（如 E_DROPPED_RX_CAN_FRAME）。对于通过匹配的消息，1722Tp 按配置决定下一步去向：若配置了UpperLayerRxPduPool（理论上ACF不会有），则会把消息放入上层Pdu缓冲并通知上层；但正常ACF场景，1722Tp 会调用 LSduR 的 LSduR_IEEE1722TpRxIndication 接口，传入相应的RxPduId和PduInfo，将该CAN/LIN PDU 转发给 LSduR。LSduR 根据 PduId 决定路由：比如如果该PduId映射到某CAN If 模块，则CAN If 收到一个Rx指示，就像来自本地CAN Controller一样处理（可以继续给 PduR->Com 上报信号）。如果1722Tp 的接收暂存队列满或者处理不及时，也会报告相应错误码（如 E_RX_QUEUE_OVERRUN）。但只要配置合理并发不超限，1722Tp 将可靠地将所有 ACF消息逐一交付。
概括而言，1722Tp 在收发ACF流时通过内部队列和平滑机制，既保证了时间同步（TSCF缓存等待）、又提高了传输效率（聚合多帧、批量转发）。开发者在调优时，可调整 CollectionThreshold/Timeout 控制打包程度，以及决定是否启用RxQueue来应对峰值。1722Tp 不会对控制消息重试或拆分重组（不像CanTp具备分段），因为CAN帧本身很小且丢失后上层应有更高层策略（如信号容错或周期刷新）。
调度与 Tx/Rx 队列机制
正如上节提到的，1722Tp 支持发送队列 (StreamTxQueue) 和**接收队列 (StreamRxQueue)**配置，用于流量的调度和平滑。这些队列在模块运行时的行为如下：
发送队列 (TxQueue)：如果一个1722流配置了TxQueue（QueueSize > 0），当上层请求发送时，1722Tp 模块不会立刻处理该请求并调用EthIf发送，而是将该发送请求（包含PDU数据和ID）存入流的TxQueue中。随后，在1722Tp_MainFunctionTx里，模块会遍历所有流的TxQueue，将其中排队的发送请求依次取出进行实际发送。这样一来，上层发送调用不会被阻塞过久，而且如果上层在一个调度周期内发出了多次请求，它们会在主函数中被批量处理。TxQueue 的主要用途有两个：其一是配合时间戳同步发送，例如音频流通常每隔固定周期发送帧，通过队列可以在正确的时间间隔送出每帧而避免抖动；其二是应对上层突发，防止瞬时过量帧淤积在EthIf。若未配置TxQueue（QueueSize=0），1722Tp对Tx请求采用即时处理策略：调用即封装发送，不做排队延迟。需要注意TxQueue并非无限：若队列已满，新请求将被拒绝并报错（1722Tp也会通知上层TxConfirmation失败）。因此 QueueSize 应根据可能的突发程度配置。对ACF流而言，由于模块内部已有Collection Queue机制，通常不再额外使用TxQueue，以免重复排队浪费资源。
接收队列 (RxQueue)：类似地，RxQueue配置后，1722Tp在收包后不会立即调用LSduR上报，而是将该帧暂存队列。然后在1722Tp_MainFunctionRx中，再逐个处理队列里的帧并上报上层。一方面这减轻了中断环境下的处理负荷，避免在EthIf的ISR中做大量解析工作；另一方面RxQueue也能提供一定的缓冲作用，应对突发的帧风暴。如果网络抖动导致多帧同时到达而上层一时处理不及，有了队列可以稍作缓存平滑输出。特别在TSCF模式下，1722Tp常需要等待演示时间才能交付帧，此时RxQueue就扮演了同步缓冲区的角色：帧按时间顺序排队，时间一到再从队首取出处理。若RxQueue满，新的帧将被丢弃并报错。因此应根据流量和上层处理能力选择合适的队列大小。一般音视频Listener会使用RxQueue来实现在播放点缓存数帧的数据，从而实现如AVB里Class A流2ms缓冲等需求。而对于ACF控制流，1722Tp虽然未必使用显式RxQueue配置，但其时间同步等待逻辑本质上形成了一种“队列”——因为可能暂存多个未来生效的控制消息。在AUTOSAR配置中，不允许对ACF Rx流配置 UpperLayerRxPduPoolEntry，就是因为其转发是异步按时间点发生的，上层很可能通过LSduR统一收取，不需要静态绑定多个缓冲。
通过TxQueue和RxQueue机制，1722Tp 能在不依赖更复杂协议的情况下实现简单的流量整形：避免因为应用层执行的不均匀或总线调度抖动，造成以太网发送的抖动；也避免短暂拥塞导致上层无法及时处理而丢包。需要指出，TxQueue和RxQueue更多是对同一流内部的平滑，对于不同流之间的调度（如音频流与CAN流竞争），则更多依赖VLAN PCP和网络调度（见后文TSN QoS部分）。
工程实用指南
以上介绍了 AVTP 协议和 AUTOSAR 1722Tp 模块的原理，下面从工程实践角度，给出在经典 AUTOSAR 平台下配置和调试 AVTP/CAN over AVTP 的方法和技巧，供车载系统开发者参考。
在 Vector DaVinci Configurator 中的配置步骤
添加1722Tp模块： 在 ECU 项目的基础软件配置中，引入 IEEE1722TransportProtocol 模块（有的配置工具可能简称1722Tp）。确保已经添加了 EthIf、Ethernet Driver 等以太网通信栈模块，并使能了所需的 TSN 协议（如PTP时间同步模块StbM/TimeSync）。
Ethernet PDU 设置： 在 EthIf（以太网接口）配置中，为 AVTP 帧定义专用的 PDU 通道。具体做法是新增一个 Ethernet If 的 PDU 配置项，EtherType 设置为 0x22F0（IEEE1722），帧类型选择 数据帧，并填入目的MAC地址（如果采用静态多播地址，可直接填如91:E0:F0:00:FE:00等，或留空待运行时配置）。一般将 VLAN 标签也在此处配置：建议开启 VLAN Tag，并设置 VLAN Priority (PCP) 对应TSN优先级（如 PCP=3 或 2，见后）。这样 EthIf 收到 0x22F0 帧后才能正确识别并上报给1722Tp。
配置 LSduR 路由： 由于1722Tp通过LSduR与其上下模块通信，需要在 LSduR（LargeSduRouter）配置中添加路由规则。典型规则包括：
Ethernet -> 1722Tp： 将 EthIf 刚添加的 PDU（Rx方向）的 上层模块 指定为 1722Tp 模块。这通常通过 LSduR 的 Pdu 路由表实现：匹配 EtherType 0x22F0 的帧调用1722Tp的RxIndication。很多配置工具可能自动处理 EtherType到模块的绑定，但也可能需要手工指明。
1722Tp -> Ethernet： 为 1722Tp 发出的帧添加路由，指定1722Tp对应的 Tx Pdu Id 交给哪个 EthIf Pdu 发送。由于前面EthIf已经配置了Tx Pdu用于1722帧，这里应将1722Tp的 LowerLayerTxPduPoolEntry 引用到那个 EthIf Tx Pdu。配置工具若无图形界面支持，可通过手工在1722Tp Stream里设置 LowerLayerPduPoolRef 指向事先在EthIf定义的Pdu。
1722Tp <-> PduR/CanIf： 对于 ACF 类型流，需要设置路由使1722Tp解封的CAN帧交给本地CAN网络，以及本地CAN帧交给1722Tp。通常做法是在 LSduR 或 PduR 中增加条目：当来自某CAN网络的特定消息（或整个CAN网）需要通过1722Tp发送时，将其目标模块设为1722Tp；反之，当1722Tp输出一个CAN Pdu（标识可用LSduR PduId或Bus Id），将其目标设为相应的CAN Interface模块。比如，配置 “BusMirroring” 功能：在 PduR的网关表中，把CAN1消息0x123路由到1722Tp；在1722Tp模块配置中，StreamAcfCan.BusId=1用于标记CAN1来源；在另一ECU的1722Tp配置中，StreamAcfCan.BusId=1且CanIf指向CAN1接口，这样消息会从1722Tp导入CAN1总线。这部分配置较复杂，因工具而异，可参考Vector提供的arxml schema设定。简化起见，如果希望“透明”转发整个CAN总线，可以将1722Tp StreamAcfCan的过滤去掉，使其接受/发送所有ID，然后在LSduR里配置一个Catch-all路由：把BusId=N的所有CAN帧都发往1722Tp，及1722Tp来的BusId=N帧全部喂给CAN N接口。
- 1722Tp Stream 配置： 根据需求添加一个或多个 IEEE1722TpStream 容器。
对于音视频流：选择Subtype为AAF或RVF/CVF等，配置Tx或Rx属性。如果是Tx还需配置定期传输参数，如每帧字节数、发送间隔（有些参数可能通过1722TpStreamAAF子容器下属性，如样本数、通道数等来推算发送频率）。设置 StreamId（MAC通常填本ECU MAC，Unique字段填流号）。关联LowerLayerPduPoolRef到Ethernet的PDU。可选地启用TxQueue/RxQueue调节缓冲。Class A音频建议开启RxQueue大小为2-3帧缓冲。
对于控制流（CAN over AVTP）：选择 Subtype = ACF，并进一步展开：
方向： 在Gateway发送节点配置为Tx，在目的接收节点配置为Rx。若需要双向控制通信（两端都发），可以配置两条流或配置双向的逻辑，各自有Stream。
HeaderType： 根据是否需要同步选择 TIME_SYNCHRONOUS（TSCF）或 NON_TIME_SYNCHRONOUS（NTSCF）。例如关键控制信号希望严格同步则用TSCF。
AcfCan/Lin 容器： 添加 StreamAcfCan 子容器（或Lin）。配置 BusId 为相应总线编号（可自定义一个ID，例如前桥CAN=1，底盘CAN=2等，保证发送接收两端约定一致）。选择 MessageType：如果想带时间戳则选 CAN，否则选 CAN_BRIEF。设置过滤：如需只隧道部分ID，填写Id或Mask；若隧道全部，则留空不过滤。特别地，如果CAN FD帧也在其中，不需要额外配置，1722Tp 会依据CAN帧报文IDE/BRS等标志自动封装，ACF_CAN支持CAN2.0和CAN FD两类格式。注：MessageType的CAN/CAN_BRIEF并不区分FD或标准帧，而只是指是否携带时间戳。
集合参数： 设置 AcfCollectionThreshold（字节）和 AcfCollectionTimeout（秒）。例如可以设阈值为最大单帧负载（例如 1500 字节），超时为 1 毫秒，表示尽可能多攒消息但每1ms一定发送一次，确保延迟上限。这些值需依据应用对延迟和带宽的权衡来定。若不确定，可先采用AUTOSAR默认或经验值（如阈值64字节、超时1ms）。
LowerLayer/UpperLayer： 将 StreamLowerLayerPduPoolRef 指向前面Ethernet PDU池。ACF流一般不配置 UpperLayerTx/RxPduPool，保持默认（配置工具可能不提供该选项以免违规）。
启用时间同步： 确保在 ECU 上启用了 IEEE 802.1AS 时间同步。Classic Platform一般通过 SoAd + Ptp模块或通过一个专用Eth SM模块实现。Vector DaVinci里需要将网络管理配置为含时间同步或使用协同的 Time Service。1722Tp会调用 StbM 或 EthIf 的 GetCurrentTime 接口，因此需要有一个全局时间基准。时间同步Domain要与对端ECU一致（通常domain 0）。
生成代码并检查 Hook： DaVinci 生成配置代码后，检查1722Tp模块的 callback 表里是否正确连接了 LSduR 和 EthIf 的钩子，如 1722Tp_RxIndication 是否在 EthIf 的上层Rx指针中，1722Tp_TxConfirmation 是否被 EthIf调用等。以及 LSduR 是否将 CAN If 和1722Tp之间绑定。调整配置直到这些接口连通（很多情况下Vector工具自动完成，需人工检查验证）。
编译下载后，即可在 ECU 中运行1722Tp模块。调试时可在1722Tp的Init返回值、MainFunction运行等打断点，观察流状态变化（1722Tp维护每个流的状态 ACTIVATED/DEACTIVATED）。必要时可以开启1722Tp的开发错误上报和调试日志，以获取误用信息（如配置冲突会通过Det报错）。
总之，在配置1722Tp时，要理清数据路径：CAN -> 1722Tp -> Ethernet，以及Ethernet -> 1722Tp -> CAN，各环节均需配置恰当的参数和路由。另外配置过程中可能遇到一些限制（如一个ACF Stream不能同时有UpperLayer和LSduR路由，不能TxRx混用等），要根据AUTOSAR SWS提示调整。建议逐步配置、分段测试：例如先配置纯AVTP音频流，看能否在Wireshark捕获，再加入ACF流测试CAN透传。
Wireshark 抓包与协议分析
使用 Wireshark 对 AVTP 和 CAN over AVTP 进行抓包分析，是定位通信问题的有效手段。以下是要点：
启用解析器：Wireshark 2.x 以上版本已内置对 IEEE 1722 (AVBTP) 的解析器。确保在协议首选项中启用了 Ethernet II 的 0x22F0 dissector。如果没有，可升级Wireshark到3.x版本以获得更完整的AVTP解析支持。3.2.0 之后的版本甚至增加了对 ACF_CAN、ACF_LIN 子消息的解析字段。
过滤条件： 可以使用显示过滤器快速筛选 AVTP 流量。例如：
eth.type == 0x22f0：过滤出所有IEEE1722帧。
avtp：过滤AVTP协议的帧（Wireshark将1722帧标识为AVTP）。
按子类型过滤：avtp.subtype == 0x02（AAF音频），avtp.subtype == 0x81（CVF视频，根据标准CVF值应为0x81，但具体以Wireshark版本为准），avtp.subtype == 0x05（TSCF控制），avtp.subtype == 0x82（NTSCF控制）。注意Wireshark对0x82解析为0x02? 可能存在，但一般可以通过字段名过滤ACF。
针对ACF子消息，Wireshark提供了**“acf-can”和“acf-lin”**的过滤字段。例如 acf-can 可以匹配包含CAN控制消息的1722帧；你也可以使用 acf-can.id == 0x123 来过滤特定CAN ID（取决于Wireshark dissector是否将ACF CAN的ID映射为字段）。Wireshark 3.2+ 的Display Filter Reference已经列出了ACF CAN有19个字段可以过滤。
示例： 使用过滤器 avtp && acf-can 可以只显示1722控制帧中的CAN报文。
解析内容： Wireshark 会将 AVTP 帧解码展示：包括 AVTP通用头各字段（subtype、sv、tv、序列号、streamID前缀等），以及子类型特定的信息。例如对于 TSCF 帧，会显示 Presentation Time 字段（以UTC时间或hex表示的ns）；对于 ACF_CAN 消息，会进一步解析出 CAN ID、DLC、数据字节，甚至标注消息类型（数据帧/远程帧）和帧标志位（EFF、BRS等）。由于 Wireshark 已支持把 ACF CAN 子消息交由 socketCAN dissector 处理，因此在详细视图中，它可能直接以“CAN Frame (ACF)”的形式列出，下面展开显示 CAN ID、Data 等，就像分析CAN日志一样方便。
时间轴分析： 利用 Wireshark 的 “Chronological” 顺序查看，可以检查 AVTP帧之间的间隔是否符合预期（如音频帧是否每125µs一帧，CAN over AVTP帧的发送周期等）。还可以对比 Arrival Time 和 Presentation Time：两者差值反映帧提前/滞后的情况。如果发现某帧到达时本地时间已超过其演示时间较多，说明可能存在同步问题或网络延迟过大，可作为诊断依据。
多流区分： 通过 Wireshark 可以很方便地区分不同 StreamID 的流。它会将 StreamID 分拆为底层MAC（Talker MAC）和ID字段显示。确认不同多播地址/StreamID的帧没有混杂。如果需要跟踪单条流，可根据StreamID或MAC地址添加过滤。
TSN 元信息： 若使用了802.1Q VLAN标签，Wireshark也会显示 PCP优先级和VID。检查 PCP值是否与配置一致（如AVB ClassA是否标记优先级3）。另外，如果抓取了PTP报文（EtherType 0x88F7），也可看同步是否正常（Follow_Up间隔，GM状态等）。
抓包环境： 由于AVTP使用多播地址，确保使用的交换机支持镜像或在终端节点抓取原始帧（使用带有抓包功能的以太网PHY或测试PC直连）。在带TSN交换机的网络中，记得关闭未授权流量的过滤，否则测试PC可能收不到保留多播地址帧。必要时在交换机上将 AVTP多播地址加入监听。
通过Wireshark详尽的解析，开发者可以直观地验证1722Tp模块行为是否符合预期，如：ACF帧是否按配置打包（看每帧包含几条CAN消息）、演示时间是否正确递增、序列号是否连续、有无丢帧、CAN数据内容正确等。一旦发现偏差，可结合模块日志定位问题根源。
VLAN 优先级 (PCP) 与带宽配置建议
在车载以太网中混合传输音视频和控制流，合理设置 VLAN PCP 优先级和带宽至关重要。以下是一些建议：
启用 VLAN Tagging： 建议对所有 AVTP 流使用 IEEE 802.1Q VLAN 标签封装，即使只存在一个虚拟LAN。这使能 PCP 优先级字段，用于TSN交换机的流量分类和调度。各节点和交换机需要支持 VLAN tagging/untagging。
划分优先级等级：根据流的重要性和实时性要求，分配不同 PCP 值（0~7）。典型配置遵循双等级 AVB 模式：将最高优先级3（或有些配置用7，见下）赋给 Class A 流（高度实时，例如关键控制或主动降噪音频）；次高优先级2赋给 Class B 流（一般实时，如娱乐音频、视频）。具体建议：
控制流 (ACF-CAN)：若涉及安全关键或高优先级控制（如线控转向制动），可将其设为Class A，PCP=3。这样可确保它获得网络最高调度优先级，典型端到端延迟<2ms。
音频/视频流：可设为Class B，PCP=2。这对大多数娱乐/信息流足够，而且避免与控制流竞争最高优先级队列。
PTP同步报文：802.1AS要求PTP事件报文使用最高优先级传输。一般PTP包不打标签（缺省视为优先级1）。若网络支持，可将PTP在交换机内部映射到专用队列。但也有配置将PTP设为PCP=7 最高。具体视项目要求，通常PTP带宽很小且对抖动敏感，给高优先级有助于同步精度。
其他流：如SOME/IP、普通以太流量，可赋较低PCP（例如4或5），以免抢占TSN流资源。调试和非关键数据可用PCP=0或1最低优先。
交换机队列映射： 确保交换机将 PCP 映射到合理的流量类。例如某推荐映射：PCP3 -> Traffic Class 7（最高），PCP2 -> TC6，PCP7->TC5，PCP6->TC4，PCP5->TC3 等。特别注意一些设备默认PCP7最高，但在AVB推荐下3才用于SR ClassA。应统一配置，避免误将非TSN流挤到最高队列。
带宽预留 (idleSlope)：使用 802.1Qav 信贷式整形时，需要为每个SR类分配 idleSlope（带宽权重）。根据经验，所有 AVB/TSN 保留流总共不应超过链路速率的75%。IEEE 802.1Q-2018推荐预留<=75%，留25%给BE流，防止拥塞。如果只有Class A和Class B两类，可按最高75%划分，如ClassA占预约50%，ClassB 25%。具体值应考虑最差同步偏差导致的整形误差。配置 idleSlope 时，也要考虑设备发送口和交换机的时钟误差，通常多给出几%的余量。
警戒不良配置： 避免过多流共用同一优先级且超额预留带宽。例如若ClassA流量配置不当超过75%，会导致交换机因信用耗尽而产生队列过载或增加抖动。要使用网络计算工具或遵循AUTOSAR通信数据库（CDD）设计的参数来确保每条流的带宽、报文周期等在总量范围内。
抖动控制： 除了网络整形，1722Tp本身的TxQueue/CollectionTimeout也可影响抖动。若对某控制帧要求尽可能小的时延抖动，应该：
将CollectionThreshold 设低（如1帧），Timeout 设为单周期或略高。这样每帧尽快发出，不因等待别的帧而推迟过久。
关闭TxQueue直接发送，以免应用层波动引入排队抖动（特别是控制流一般不用TxQueue，由1722Tp内部自管）。
确保时间同步稳定，减少因gPTP时钟漂移补偿带来的Period调整抖动。
必要时，可采用802.1Qbv（时间触发调度）进一步严格控制发送时间，在网内为关键流设置独占时隙，从源头消除抖动。不过这需要更复杂的配置（详见附加章节）。
MTU与碎片： 1722Tp不会对上层数据片段化，因此要注意控制负载大小。以太网典型MTU 1500字节，如果打包消息过多导致AVTP帧>1500字节，将无法发送。在配置CollectionThreshold时应小于 MTU-开销（如假设以太网+VLAN头18字节+1722头32字节，则负载阈值最好 <=1450）。AUTOSAR SWS可能会在配置验证中检查这一点。一般CAN帧每条最多17字节封装，打包80条左右已接近MTU，此值可作上限参考。
流ID规划：如前述，每条流的StreamID要唯一。如果项目中多个1722Tp设备MAC类似，建议通过配置工具或脚本自动分配UniqueID，避免人工重复。StreamID冲突会导致接收端无法分辨流，出现丢包或乱序（详见调试章节）。
带宽与延迟控制示例：
假设有一条500Hz的转向控制CAN信号需经以太网从ECU A发送到ECU B，要求端到端延迟<5ms抖动<1ms；同时还有一路高清摄像头视频（H.264码流，带宽8Mbps）从ECU B传回ECU A用于显示，允许100ms延迟。可考虑配置：
将转向控制流设为 PCP=3，ClassA，idleSlope给4Mbps带宽（足够容纳500Hz CAN流约0.05Mbps裕量充足）。
将视频流设为 PCP=2，ClassB，idleSlope给10Mbps带宽。
交换机总预留14Mbps < 千兆75%OK。
1722Tp上控制流AcfCollectionTimeout=0.5ms，Threshold=最大1帧（确保每个CAN随来随发），TSCF模式确保同步。视频流TxQueue可开，确保每帧按帧率周期发送。
PTP设置domain0，确保A、B时钟同步在1µs内。
这样控制帧理论延迟 ~ 2传输周期(2ms) + 调度排队(<0.1ms) + 少量交换机延迟，总<3ms且抖动微小；视频帧则走ClassB队列，会在不影响控制的前提下自由通过，数帧缓冲，100ms延迟完全满足。
上述只是示意，实际配置还要考虑更多细节。但可以看到，通过 VLAN PCP 区分和TSN调度，每种流都能获得其所需服务质量。
示例：1722Tp 与 PduR/CanIf 联动
我们以一个简单的网关场景说明1722Tp和PduR/CanIf如何配合：ECU X 和 ECU Y 通过以太网相连，ECU X上某应用需要将一条来自CAN1总线的消息0x200发送到ECU Y，并在ECU Y上将其发布到CAN2总线。
在 ECU X（发送端）： 这条CAN1消息（ID=0x200）原本会经 CanIf -> PduR -> 应用。现在配置了网关路由，使 PduR 检测到ID 0x200需要经1722Tp发送，于是调用 LSduR_IEEE1722TpTransmit（或TxConfirmation形式）将该PDU交给1722Tp。1722Tp 查找本地配置，发现StreamAcfCan.BusId=1匹配CAN1且未过滤0x200，则接受该PDU，将其排入 ACF发送队列。假设配置超时0.5ms，那1722Tp很快会封装这单条CAN为AVTP帧发送（或可能攒另一帧一起，但不超过0.5ms）。之后1722Tp调用 LSduR_ReleaseRxBuffer 释放CAN1 Pdu缓存，并通过 LSduR_TxConfirmation 通知 PduR 发送完成。对于应用而言，这类似CAN消息已发上总线。
在 ECU Y（接收端）：ECU Y的1722Tp配置了一个Rx流，StreamAcfCan.BusId=2用于CAN2。1722Tp 收到ECU X发来的1722帧后，通过LSduR调用（RxIndication）通知自己收到一个PDU。1722Tp 解析帧内ACF消息，取出ID0x200，BusId=1。它在本地配置中查找BusId=1的ACF配置，如果有则对应某路由，否则若无（典型情况，因为ECU Y上BusId=1或许没意义），那么1722Tp会继续查有没有BusId通配（例如配置BusId=ANY接收所有）。若找不到直接匹配，会报告Dropt错误并丢弃。正确的配置是要在ECU Y 1722Tp上也配BusId=1的AcfCan项，尽管ECU Y并不真正有CAN1，但我们可以这样指示1722Tp：“凡收到BusId1消息，就映射到BusId2输出”。如果配置支持，可将ECU Y 1722Tp StreamAcfCan.BusId设为1，MessageType=CAN，并设置UpperLayerRxPduPoolEntry关联一个PduR Pdu（目标CAN2）。这样1722Tp在解析到BusId1消息时会匹配这个配置并调用LSduR_RxIndication把PDU传给PduR。PduR 查路由表，将此PDU交给CAN2 CanIf发送到CAN2网络。这样，ECU Y 就把ECU X来的消息0x200发到了本地CAN2上，实现跨网关传输。
上述过程可见1722Tp对BusId和配置的利用：如果配置不完善，可能造成消息漏转。因此在设计时应清晰规划BusId映射关系。例如，可全局约定：每个物理CAN网络都有唯一BusId，1722Tp网关两端使用源BusId标识源网络，并配置在目标端一个对应BusId的接收映射到目标总线。或更简单，一条1722流对应一个总线对：如“CAN1_to_CAN2_ACF流”，BusId=1表示源，接收端遇BusId=1就输出到CAN2。需要根据AUTOSAR路由配置灵活实现。在Vector DaVinci中，可以借助PduR Gateway功能配置Complex Routing实现类似效果，把CAN1 PDU经某传输协议（1722Tp）发送，再恢复到CAN2。1722Tp模块本身不感知这些高层逻辑，它只根据配置进行匹配转发。
调试陷阱与边界条件
在实践中，可能遇到一些特殊问题，以下列举常见陷阱及诊断建议：
时钟同步不稳定： 如果 gPTP 时间同步质量不佳，会直接影响 TSCF 模式AVTP帧的呈现时序。例如，两ECU初始时钟差异过大，Listener可能收到的帧演示时间早于自身当前时间很多，从而认为帧已过期而丢弃。这表现为视音频不同步、控制指令跳变。诊断方法：抓取双方 PTP 报文，检查 Announce 和 Follow_Up 中 GM 时间差；在 Wireshark 查看 AVTP帧的 Presentation Time vs Arrival Time 差值，是否为负值很大。如发现，同步问题明显。解决：确保网络只有一个 PTP主时钟，Domain 设置一致；检查有无 ECU静态配置不同步；必要时增大 MaxTransitTime 以提供裕度。【提示】AUTOSAR 中 StbM 模块可提供时间偏差信息，可用于监控。
Stream ID 冲突： 若两条流意外使用了相同的StreamID（尤其是MAC和ID都相同），会导致 Listener 混淆帧归属。症状包括：Wireshark中看到一条流的序列号乱序（因为实际上是两源交替发送），甚至1722Tp模块会无法正确匹配流配置而丢弃帧。避免方法是在配置时严格保证StreamID唯一，可采用设备MAC+流序号生成。调试中若怀疑冲突，可检查抓包中不同Talker MAC是否用了相同ID，或Listener日志报 stream activation error 等。解决办法：更改其中一设备的UniqueID，并重启流。
多播地址冲突/未订阅： 若多个流静态配置使用了同一个多播MAC地址，而StreamID不同，交换机层面会将该地址的帧广播给所有订阅端口。Listener虽然可用StreamID区分帧归属，但仍无谓接收了不需要的流量，占用带宽。更糟的是，一些简单实现可能并未针对StreamID做严格过滤，从而干扰。诊断：Wireshark观察无关流也出现在端口上；或1722Tp模块上报未配置的Stream的Rx（可能有防御性检查报错）。解决：确保每个AVTP流选取不同多播地址（MAAP算法避免冲突）。如果必须共用地址，也应通过SRP或静态过滤让无关Listener不接收（静态配置Listeners的MAC组播过滤）。
gPTP域不匹配： 802.1AS允许不同“域”（domain）同时存在。如果一部分ECU使用Domain0同步，另一部分误用了Domain1，那么双方的时间基准各自独立，会导致演示时间理解不一致。表现为：Listener收到帧后始终认为时间戳无效或过期，可能丢弃所有带时间戳帧。排查方法：检查ECU的PTP配置，确保domain一致。Wireshark中可以看到Pdelay消息里的 domain 字段。若发现不一致，需要统一配置。例如某相机控制子网曾要求domain1同步，但网关未配置，结果网关转发过来的1722帧时间域不同步。解决：令所有相关1722设备使用相同domain。
发送/接收队列溢出： 如果1722Tp配置的TxQueue或RxQueue过小，而瞬时流量超过其容量，会造成队列溢出，1722Tp据规范需丢弃帧并报告错误。这种情况可能发生在：应用突然发送了多个大帧填满TxQueue，或者Listener因CPU调度暂缓处理导致RxQueue堆积。症状：Det报错IEEE1722TP_E_TX_QUEUE_OVERRUN或RX_QUEUE_OVERRUN，通信出现间歇性丢包。解决：增加QueueSize，或优化应用发送模式，使发送更平滑。例如对于视频流，尽量保证均匀发送而非帧间隔不均。对于Rx，如在高负载情况下一直溢出，只能提升处理性能或降低发送端速率。
丢帧与序号： AVTP对每条流有序列号(SN)0-255循环。1722Tp并不会重传，但Listener可以利用序号检测丢帧。如果丢包严重（序号经常跳增），需检查带宽/延迟。Wireshark可帮忙统计帧间隔和序列跳变。常见原因：带宽超出保留（交换机开始丢弃），或发送端未遵守整形规则突发发送导致交换机缓冲溢出。对策：重新校准idleSlope，降低流量，或在发送端实现软件整形（AVB设备应遵守802.1Qav规约，不超速发送以免引起交换机丢帧）。
调试信息不足： 目前多数AUTOSAR实现对1722Tp支持还新，可能缺少丰富的日志。建议充分利用Wireshark和总线分析仪，多方取证。1722Tp模块通常有一些统计计数器（比如丢弃帧计数），可在RTE或调试接口读取。如果怀疑1722Tp内部逻辑错误导致某帧未发送/未转发，也可加入Hook监视LSduR接口调用频率来判断环节。
总之，调试1722Tp相关问题要从链路层到应用层整体考虑：既要看以太网流量（是否符合TSN期望），也要关注AUTOSAR内部路由。常见问题大多源于配置不一致或网络限制，定位后往往通过调整配置即可解决。
支持的协议子类型与扩展格式
IEEE 1722（AVTP）协议设计为支持多种媒体和数据格式，除了本文重点讨论的 ACF 控制格式（CAN/LIN），还包括：
AAF (AVTP Audio Format)： 用于未压缩数字音频流的传输格式。AAF 定义了音频帧的封装（典型如每帧包括若干音频采样）。1722a标准Clause 8详述了AAF格式：包含采样率、通道数、样本位宽等字段，以及音频帧序列号。AAF 支持PCM原始音频和AES3等格式，可用于车载麦克风阵列、主动降噪等高品质音频传输。常见配置是基于48kHz采样率，每帧1或2个采样周期，使帧周期为125µs或250µs，对应AVB ClassA或ClassB。AAF通过AVTP演示时间实现跨扬声器的相位同步，满足<1µs同步精度的要求。
CRF (Clock Reference Format)： 用于传输时钟参考信息的格式。CRF通常承载周期性计时标记，如音频采样计数、摄像机帧计数等，帮助接收端校准其本地时钟到发送端节奏。1722a Clause 11定义了CRF，例如 Pro Audio场景下48KHz Audio Sample CRF：Talker每隔一定周期发送包含采样序号和时间戳的CRF包，Listener据此调整本地PLL，确保多设备播放无漂移。CRF 是AVTP同步机制的重要补充，因为AVTP音频流虽然有演示时间，但长期播放仍需校时防止缓冲溢出欠载。CRF流本身很小，优先级通常和对应音频流相同或更高。
CVF (Compressed Video Format)： 用于封装压缩视频帧（或分片）的格式。1722a扩展了对视频的直接承载支持，CVF可以传输例如MJPEG帧、H.264 NALU等。CVF帧头包括视频格式子类型（如定义H264、MJPEG等）、帧序号、时间戳等字段。以H.264为例，CVF可将Annex B的NAL单元打包，每AVTP帧可容纳一个或多个NAL并指示分片关系。CVF允许视频帧与音频流对齐同步（通过演示时间实现AV同步）。车载中，如环视摄像头、驾驶员监控摄像头可以用CVF在TSN上发送以获得低延迟和同步保证。需要注意CVF帧可能较大，一般会启用紧凑IPG或802.3br帧抢占来保障延迟。1722Tp模块对CVF的支持需满足较高吞吐，目前AUTOSAR规范中提到RVF/raw video但未明确CVF配置，实际实现可能需要扩展。
RVF (Raw Video Format)： 用于未压缩视频流（原始像素）传输的格式。RVF并非1722-2011所含，但在1722a提及有提案。RVF头包含帧分辨率、像素格式（RGB/YUV）等字段。由于未压缩视频数据量巨大（例如720p60原始约1.6Gbps），RVF 通常配合更高带宽以太网或压缩混合方案使用。当前车载应用很少直接用RVF，大多使用压缩CVF代替。AUTOSAR 1722Tp提到了RVF参数结构，说明原则上支持此格式。
61883/IIDC： 这些是为兼容 IEEE 1394 (FireWire) 设备而设的封装子类型，用于过去一些音视频格式（如DV、MPEG2-TS 等）。IEEE 1722-2011 中 subtype=0x00 就对应 IEC 61883/IIDC over AVTP。例如 61883-6（音频）和61883-4（MPEG2-TS）都有定义。这些格式主要用于专业音视频设备互联。车载领域较少直接用，但某些MOST替代方案中曾考虑MPEG-TS。1722Tp模块如需支持，可配置StreamSubtype=IIDC，对应处理比较特殊的数据单元，一般会通过Adaptive或者用户自定义上层消费。目前AUTOSAR规范列出了61883_IIDC可配，但如何使用需参考AVB技术文档。
MAAP (MAC Address Acquisition Protocol)： 尽管MAAP不是AVTP的媒体流格式，但在1722协议里是一个特殊子类型 (0x7E) 控制报文。它定义了Probe/Defend/Announce 三类消息，用于多播地址动态分配。1722Tp模块通常不直接处理MAAP —— MAAP的实现多在协议栈初始化阶段由系统服务完成。然而在抓包时会看到MAAP报文（目的MAC一般是 IEEE 1722保留的地址范围末尾，源为申请者MAC）。调试时如发现多个1722设备选中了相同多播地址，会看到MAAP Defend报文相互冲突。这提醒需要调整MAAP实现或改用静态地址避免冲突。
1722.1 AVDECC： 这是独立于1722的上层协议，但提及是因为它与1722配合实现设备控制。1722.1定义了Discovery、Enumeration、Connection等一系列命令，运行在UDP/IP层，端口17221，使用1722流ID标识AVTP终端等。车载暂未广泛采用AVDECC，大多通过静态配置流，没有动态建立与拆除。但未来高级应用（如车载音频设备即插即用）可能引入AVDECC。因此当看到1722.1报文时（EtherType不是0x22F0而是UDP上17221端口），要知道那是AVTP设备管理协议。
自定义/供应商扩展：IEEE 1722 预留了一些 subtype 值供厂商实验用途 (0x7F)。部分公司可能定义自己专有的数据封装格式通过1722Tp传输，例如某厂商定义雷达点云格式等。这需要在1722Tp模块上做定制扩展，AUTOSAR并无直接配置项，只能走厂商扩展模块或使用1722Tp作为pass-through未经解析传输。这种情况下调试需厂商提供解析插件。
总的来说，1722Tp模块理论上支持上述多种子类型的数据传输，但实现上可能视供应商而定。AUTOSAR R24-11提供了通用配置结构，但具体子类型如CVF、MPEG2TS等是否在生成代码中支持，要看BSW实现。如果项目中有这些需求，应与基础软件供应商确认支持情况。对于CAN/LIN来说，ACF已经明确支持且AUTOSAR实现，开发者可以放心使用；而新的格式比如I2C ACF、RVF可能仍在标准讨论中。
附加章节：结合 TSN QoS 架构的音视频 + 控制混合流设计
现代车载以太网架构中，往往需要同时传输高吞吐量的多媒体流（如摄像头视频、音频）和高优先级的控制流（如ADAS传感器数据、执行指令）。TSN 提供的一系列 QoS 机制使这种异构流合路成为可能。以下探讨如何构建音视频+控制的混合流架构：
1. TSN 策略综述： TSN（Time-Sensitive Networking）除上述802.1AS和Qav外，还包含其他关键标准，如802.1Qbv（Time-Aware Shaper）、802.1Qbu/802.3br（Frame Preemption帧抢占）、802.1CB（Frame Replication and Elimination冗余）、802.1Qci（流量监管）等。这些可视作工具箱，分别解决不同问题：
时间触发调度 (Qbv)：通过Gate Control List在交换机端口实现基于时间的开窗，确保在指定时间段只允许特定流发送。应用在汽车上，可以给控制流预留极短且固定的发送窗口（比如每隔1ms开窗100µs，只传控制帧），保证控制帧确定性延迟且不被任何其他帧干扰。音视频流则在其余时间发送，稍有延迟抖动也无碍用户体验。
帧抢占 (Qbu/802.3br)：允许高优先级的短帧中断低优先级长帧的发送。典型场景：千兆以太上一帧1.5kB视频帧耗时约12µs，100Mbps上则约120µs，如果不抢占，控制帧可能排队等待这个时间。启用抢占后，控制帧可在发到一半的视频帧中间抢先发完，极大降低最坏等待时间。车载一般在100Mbps网络上采用帧抢占来满足严苛实时性，同时保证带宽利用。
流量监管 (Qci) 和 帧复制 (CB)： 在安全相关场景，为防止异常节点超量发送或包丢失，Qci可设置每流的带宽和突发上限，超出即丢弃，从而保护其他流不受影响。802.1CB允许关键流走两条路径并在接收端去重，提供容错。这两者在构建冗余以太网和处理不可靠链路时很有用，典型如制动指令可能通过双以太网发双份。
2. 混合流架构设计： 结合1722Tp，我们可以这样设计网络：利用 VLAN PCP 和 Qav 将流按优先级分类，再叠加 Qbv/Qbu 等保证时序：
优先级/带宽规划： 如前述，将控制类流设为最高优先级队列，音视频次之，普通数据更次。为每类预留适当带宽份额。例如一条千兆链路上，也许20%带宽给控制（大量冗余），60%给视频，20%留作裕量。这样即便视频流满载，控制帧仍有独立带宽，不会排队太久。
时间分隔： 在时钟精确同步的前提下，配置交换机Time-Aware Scheduler：例如每1ms周期，把前100µs窗口只开放给优先级3队列（控制流），接下来900µs开放给优先级2（视频等）。这样控制帧无论何时到达，最迟等下一个1ms窗口就能发送，延迟上界100µs +网络传播。音视频则可能在窗口边界稍等，但对其毫无察觉（1ms抖动在视频帧时间中）。
帧预emption： 如设备不支持Qbv，退而求其次可用帧抢占(Qbu)。开启后，一个大帧正发送时，如有高优帧来了，MAC会暂停大帧送出小帧，再续发大帧尾部。这也能达到类似效果。前提是ECU网卡和交换机支持frame preemption，需要配置Express和Preemptable队列门控。
冗余网络： 对于线控等超级关键流，可以利用802.1CB送两份沿不同路径（如车内双以太网骨干），在接收端1722Tp上实现简单的冗余帧过滤（可通过序列号识别重复）。1722Tp本身不支持CB逻辑，需要上层或自定义处理，但可以通过配置两个Listener流实例（不同网口来源）将同一控制PDU传给同一个目标，实现冗余接收。
3. 实例应用： 比如一台自动驾驶车辆：有8路摄像头视频（CVF流，每路5Mbps以上）发往域控制器，还有数十个雷达/激光雷达点云数据帧，和来自中央决策的控制指令广播到各执行器。传统上这些不同性质流量需不同总线或网络，而通过TSN+1722：
摄像头视频：配置为Class B PCP2，采用信用整形保证带宽，每帧打时间戳确保多摄像头同步（1722Tp CVF TSCF模式）。
雷达/LiDAR点云：可能使用1722的自定义格式或切成以太帧直接发，也作为Class B或更低优先传输，因为带宽大但延迟相对可宽松（几十毫秒）。
控制指令（如转向/加速）：通过ACF-CAN TSCF广播，以Class A PCP3传输，每周期几个字节，但绝对优先，Qbv给固定时隙保证<1ms延迟。
同步信息：802.1AS保持全网时钟同步在微秒级，1722Tp保证各类数据统一在这个时基下标记时间。视频在接收制动指令时可追溯其拍摄时间，做时空融合。
AUTOSAR 配置方面：对于上述架构，大部分工作在通信矩阵规划阶段完成——例如在AUTOSAR ECU Extract里定义好每个信号属于哪个以太网流、优先级。1722Tp配置则根据矩阵自动生成流实例。更多的TSN调度细节（如Qbv GCL）当前Classic无法配置，只能静态烧录进交换机或由车厂工具配置交换机。因此在设计上要简化：例如采用Qav和frame preemption即可满足大多数需求，尽量避免必须Qbv，否则需引入像TSN配置中心等架构（Adaptive AUTOSAR或车云协调）。
性能和验证：混合架构完成后，需验证各类流的 QoS：使用测试仪模拟满负载视频，看控制帧延迟分布；引入抖动扰动，看同步是否依旧；使用网络分析仪验证75%带宽规则未被破坏。Milan（AVnu的新规范）等提出了一些混合关键流概念，也即1722标准在继续演进以支持这些场景。比如“Mixed Criticality”要求专业音频和控制共网零干扰，正是类似思路。
总体而言，借助 TSN 的多队列调度、时间同步、带宽控制能力，我们可以在一张以太网上安心地跑音视频，又可靠地跑控制信号。1722Tp模块提供了应用层的便利，让开发者用熟悉的CAN接口收发控制数据，同时享受TSN网络带来的高带宽和实时保证。这种融合架构将是未来软件定义汽车的中坚：统一网络降低线束和网关复杂度，多种数据流协同提升系统响应速度。在具体实现中，需要硬件设备（交换机、PHY）完整支持TSN特性，软件配置精细调优，并经过充分的测试验证。但可以预见，随着AUTOSAR对1722/TSN的支持逐步完善，以及车载以太网带宽升级（如10Gbps以太网引入），音视频和控制混合流的架构将日趋成熟，真正实现车辆内部的“网络大同”，即One network to rule them all。