车载以太网帧结构详解 | SOMEIP 格式解析 | 音视频传输 AVB vs RTP

admin管理员组

文章数量:1188026

注：本文为 “车载以太网帧结构详解 | SOME/IP | 音视频传输 AVB vs RTP” 的几篇文章合辑。

---

车载以太网帧结构详解

埃恪深科技 汽车电子与软件 2022年01月19日 07:00

身边的以太网

我们身边充满了以太网，不管是新势力还是传统的主机厂，都已经在准备或是在更上一层地去做以太网的一些升级，包括电子架构也会做车载以太网的一些规划。

当前，无论是我们的电脑，还是手机，还是我们访问的云端数据，还是看视频等，都是我们身边可以感知到的传统以太网。

未来，这些以太网技术都会逐渐运用在我们的汽车上，以太网在汽车上应用已势不可挡。汽车整个的一套以太网生态也在慢慢地构建，包括我们的车联网、V2X 通信、5G 车联网都已经慢慢加入进来。

但是现在我们整个汽车行业最多的可能还是在用 4G 的 T-Box 去做车联网，当然这一块也会随着汽车行业的一个生态、对一些带宽或是延时的一些需求，推动整个汽车供应链去做一些迭代更新。
其实在工业互联网上这一块已经慢慢的趋向于成熟了。

汽车为什么拥抱以太网

因为以太网本来不属于汽车行业的，既然要选择那肯定有它的一些优势。

从总线技术来说，现在车上的总线包括 CAN/FD、Flexray、MOST、LIN 等，然后现在又加入了新的成员以太网。

并不是说因为以太网的加入会导致其他的总线就能够彻底的去取消掉，因为这个涉及到原有的电子架构跟新的电子架构的融合，不可能把原先的整套全部舍弃掉。

我们需要用最简单、最低的成本去把架构一点一点的往上升级，所以就慢慢地引入了百兆、千兆，亦或是将来的万兆以太网。

以太网的相对优势如下图所示：

上图中，我们可以看到，以太网的优势在于：

• 带宽高、可扩展强

• 基于星型的拓扑结构

• 随着趋势的发展，成本会越来越低

• 当前主要应用于娱乐系统和 ADAS，主要用于音视频传输

当前，以太网的应用已不仅限于百兆以太网，随着汽车行业的高速发展越来越依赖高带宽，低延时，高算力的通信，而以太网便是高带宽、低延时、高算力通信的基础。

当前在 L3 + 自动驾驶域控制器中，会以太网为骨干网，AUTOSAR 和激光雷达作为标配，其中以太网是基础；

目前架构会随着 ECU 数目增加而改变，这也会造成分布计算资源的浪费，为了避免分布式资源的浪费，我们可以使用以太网，将原先分布式上的计算资源进行域融合，进而减少 ECU 的数量，节省资源线束重量，这样可以减少 80% 的车内连接成本，30% 的线束重量。

对于带宽要求高的各种传感器，特别是激光雷达和高分辨摄像头必须使用以太网传输数据，节省 LVDS 总线成本；

还有车云交互方面，4G/5G 以及 V2X 生态的逐渐成熟，远程代驾 / 泊车，哨兵等功能可以更完美落地。

汽车以太网 VS 工业以太网

首先从最底层的一些物理介质来看的话，汽车上使用的以太网分为两种，一个是车内 ECU 之间的通信，还有一个是车外 OBD 对外的通信，其实这两个通信它本身是不一致。
车内 ECU 通信用的是一对双绞线进行通信，沿用原先 CAN 的这种单对双绞线传输数据。但是带宽使用的是百兆以太网的技术。

OBD 对外通信是两对双绞线。在 ISO13400-3 中有一些描述，常规使用的是 3、11、12、13 这四个引脚，当然还要外加一个 8 引脚的激活（Activation）线。这是一个通过 OBD 的对外的 DoIP 的诊断。

总的来看就是，一个是对内的一对双绞线的 ECU 之间的通信， 一个是 OBD 对外的两对双绞线的通信。
回过来看一下我们的生活中，例如我们的电脑网线。

我们了解到它是八芯的，相当于四对双绞线。但是，其实工业的百兆以太网，只用到四芯，分别是 1、2、3、6 这四个引脚，其余是做预留的。

工业千兆以太网会用四芯去做千兆的信息传输，用四芯去做 POE（Power On Ethernet）供电，例如我们的摄像头、办公楼无线发射器。所以工业以太网四芯通信其实跟汽车 OBD 对外的通信的本质上是相同的，所以其实整个汽车上面就已经用到工业以太网了。

汽车的以太网分以下几种类型：

OBD 是 100BASE-TX，使用的是 2 对双绞线，速率是 100M，总线类型是星型。
ECU 之间的通信，一般通过 100BASE-T1 或 1000BASE-T1 两种技术，具体使用哪种看 ECU 对通信速率的需求。出于对 EMC 干扰的考虑，我们选择使用 1000BASE-T1 的时候，会选择使用一对屏蔽双绞线。

还有正在制定的 10BASE-T1S ，它是一种类似于 CAN 的总线型技术。主要是弥补百兆以下的车载以太网的空白，其目的是为了考虑未来是否可以统一车内的总线类型。当然，这是一个漫长的过程。
类似的还有 CAN XL 技术，它是在往上努力，最终 10M 技术花落谁家就看谁能从价格和落地上有更多的优势。

汽车以太网物理层以上的，例如它的拓布以及它的整个通信的原理，类似于下图的内部网络图：


以太网组网是一个星型的结构，是点对点的，不可能说一根线挂在那里，所有的节点挂上来就可以通信，必须是点对点的。

它必须得经过一个 Switch 进行二层的转发，或者经过一个 Router 进行三层的转发， 也就是说所有 ECU 的通信肯定是有一个汇聚点的，不可能一对一，这会导致车内网络变成 “蜘蛛网”，这就需要一个车内设备进行汇聚和转发。

以下，我们会详细介绍 Switch 和 Router 的转发原理。

以太网 OSI 模型

OSI（OpenSystem Interconnect），即开放式系统互联，由 ISO 组织发布。

为了方便大家理解以及去做一些更深层次的分析，OSI 参考模型分为七层模型，在工业以太网上其实它也叫 TCP/IP 五层模型，这两个其实本质上是没有区别的，无非是说把应用层更细分为三个层。
整个 OSI 模型每层各司其职。

第一层物理层
如之前我们提到的 100BASE-T1、1000BASE-T1、100BASE-Tx，这技术是由不同的物理层介质决定的。

第二层数据链路层
主要是提供一些链路建立以及一些转发策略。

第三层网络层
是指不在同一个局域网，或者对远端网络有访问需求的时候，都是通过 IP 寻址以及路由转发进行功能操作。

第四层传输层
我们车上会有很多协议例如 DoIP、SOME/IP、UDPNM 等一些协议，每个协议都会有它固定的一个 Server 端的端口号。
Server 端跟客户端会有一个 Client 到 Server 对应关系，多个 Client 要如何识别它要访问的是 DoIP 还是 SOME/IP 服务，它都是通过传输层来确定的，传输层会有一个包含源端口、目的端口、再加上网络源 IP、目的 IP 以及协议的组成一个通信五元组。

第五层会话层
当我们建立 DoIP 的会话，需要有会话管理，这个层次用来会话管理。

第六层表示层
表示层用于数据格式转换和数据加密，如 TLS 的加密方式，使通信双方进行协商，以防止数据的篡改，符合相关安全要求。

第七层应用层
就是我们所谓的 Payload

OSI 模型协议分布如下图：

以太网帧结构

下图是一张以太网帧的结构图。这个结构图很清晰地描述了整个以太网帧每个部分组成。

对我们来说能抓到的或者能看到的报文帧，基本上是在目标 MAC 地址到 IP 数据包。

上图中的前导码和帧开始符主要做一些底层的数据传输和编码流的二进制流，它们本身不会被网卡捕获，网卡一般抓包的时候就已经将前导码跟帧开始符解析掉了。

还有帧后面的校验码，其主要是通过 CRC 校验判断帧是否有效或者发生篡改或错误，当网卡能收到数据帧并通过抓包工具可以抓到的，就说明该帧没有问题，是有效的，当帧是有效的后，就说明 CRC 就已经解析掉了。

所以，在整个以太网帧中，能看到的就是目标 MAC 地址、源 MAC 地址、帧类型以及 IP 数据包，当然 IP 数据包中还会细分许多协议，每个帧之间也是跟 CAN 类似有，有一定的距离，不可能一帧挨着一帧传输的。

IP 数据包里面，有 46~1500 字节的长度约束。这不是由 ECU 决定的。在我们使用的设备中，会有一个最大传输单元（MTU）、MTU 一般默认是 1518 个字节，这就导致 IP 数据包最多只有 1500 个字节。

以太网单个最大帧：6（目的 MAC）+ 6（源 MAC）+ 2（帧类型）+ 1500（IP 数据包）+ 4（CRC 校验）=1518 字节，如果带 VLAN 就是 1522 字节（VLAN 会多出四个字节的帧类型描述）

以太网最小帧：6（目的 MAC）+6（源 MAC）+2（帧类型）+46（IP 数据包）+4（CRC 校验)=64 字节

常见的以太网帧类型：

• 0x0800：IPv4
• 0x0806：ARP
• 0x22F0：AVTP
• 0x8100：VLAN Tag（TPID）
• 0x86DD：IPv6
• 0x88F7：PTP /gPTP

下图是用工具抓的两个报文，以方便我们来理解以太网帧结构。上图报文以太网帧如果小于 64 字节，那么会填充 00。

当以太网帧如果大于 1518 字节，那么会分片，如下图所示。1008 字节 ICMP 报文分 2 帧传输。

接下来我们对以太网帧进行更详细的分析

从上图可以看到，当我们使用 SOME/IP 协议时，SOME/IP 报文是封装在 TCP、UDP 报文里，然后把它加一个报头，扔到 IP 层的 Payload 中，IP 层添加报头后，再分装到 IP 数据包中，一层一层分工。

当对方接收到后，相应的就是去除包头，解析 SOME/IP 中的 Payload。

✦✦

DoIP 帧结构

接下来我们看一个 DoIP 的报文。下图为用工具抓的一个 DoIP 报文。

上图整个 DoIP 报文整个一个帧是 69 个字节，其实还要再增加 4 个字节的 CRC，总共 73 个字节。只不过当网卡识别它是一个有效帧后，就把 CRC 解析掉了。

当然，图中也描述了它的源 MAC 地址（6 个字节）和目的 MAC 地址（6 个字节），再加上 2 个字节的帧类型，共 14 个字节。

然后再往后就是传输层，IP 层最小是 20 个字节。

然后再往后是 TCP，DoIP 报文是一个 UDS 的报文，而 UDS 报文都是通过 TCP 传输的，因此，会有个 TCP 的头部，包括 Src Port（源端口）：13400（这是 DoIP 的一个端口号）以及 Dst Port（目的端口）：50090。TCP 的长度是 20 个字节；

DoIP 协议头部是 8 个字节的长度；需要注意的是，DoIP 的头部并不包括源 DoIP 地址和目标 DoIP 地址这 4 个字节；

再往后的话就是我们的 Payload，3 个字节，

将上述加起来一共 69（14 + 20 + 20 + 8 + 4 + 3）个字节（一帧）。

✦✦
SOME/IP 帧结构

接下来，我们看一下 SOME/IP 帧结构。

这就跟 SOA 有些关系，SOA 本身是一个概念化的东西，它具体化的一个表现就是 SOME/IP 的报文，所有的以太网的 SOA 基本上都是标准化的一个 SOME/IP 的协议去做一个传输。

下图为 SOME/IP 报文的解析：

上图中，SOME/IP 的报文总共 62 个字节，以太网帧头部就不做赘述了。这里我们说一下 VLAN，我们有时会把一些业务进行一些区分，例如诊断、DoIP、SOME/IP、安全性更高的一般会通过 VLAN 区分，上面提到的 DoIP 协议报文是没有 VLAN 的，说明 DoIP 和 SOME/IP 的通信传输是隔离开的。
再往后，IP 层我们之前也说过了，这里就不做赘述了。

再往后，UDP 说明这里的 SOME/IP 是通过 UDP 进行传输的，它的源端口是 30602、目的端口是 30602。

再往后，我们看一下 SOME/IP 报文，它的头部是 16 个字节，这 16 个字节是固定的，包含 Service ID、Method ID、Length、Client ID、Session ID、Protocol Version、Interface Version、Message Type、Return Code。

当然这里是没有带 Payload，后期我们会进行一个相关的详细分享。

以太网的通信交互案例

✦✦
以太网通信交互案例 - 二层

下图所示为我们刚才提到的一个 Switch 的组网，Switch 上有四个 PHY 的接口，每个 PHY 的接口分别连了一个 ECU，每个 ECU 都有自己的 MAC 地址，如 AA:BB:CC:DD:EE:01 等。这四个 ECU 分成两个 VLAN，左边两个 ECU 在 VLAN1 中，右边两个 ECU 是在 VLAN2 中。

Switch 本身是一个二层转换的设备，它是严格按照要求进行交换的，也就是说，在同一个 VLAN（虚拟局域网）里面是可以进行二层通信的，不在同一个 VLAN 的主机是不能二层通信（如 EE:01 与 EE:02 是不能进行通信的），需要注意的是，二层通信本质上是跟 IP 地址没有关系的。

下图举例说明为什么二层通信跟 IP 地址没关系，因为二层的通信属于 MAC 寻址。无非是从一个 ECU 的 MAC 到另外一个 ECU 的 MAC 进行寻址。

如前面提到的 Switch 组网图中，EE:01 ECU 想要和 EE:03 进行通信，如果有寻到 03 的 MAC 地址或者配置了一些静态的 MAC 表项，那么他们可以直接通过 EE:01 连接的 PHY，再通过 EE:03 连接的 PHY 进行通信。

如果 EE:01 想和 EE:02 通信，这个时候 Switch 会查看下帧结构，在帧结构中会有一个 VLAN 的标签编号，如果识别到 VLAN 的编号不在 VLAN1 里面，报文就不会转发到 EE:02 的 PHY 上去。
当 ECU 的网卡、或者我们电脑的网卡，识别到目的 MAC 地址，不是自己的地址，或者不是组播，或者不是广播的时候，会直接将它丢弃，不会再往协议栈中发送。这也是为什么二层以太网无法跨 VLAN 进行通信。

✦✦
以太网通信交互案例 - 三层

接下来，我们说一下以太网的三层通信。
三层通信是指跨网或者跨 VLAN 进行通信时，需要通过路由器或者带有路由功能的设备实现 IP 报文转发。如下图所示为以太网三层通信的示例。

上图中，我们可以看到，左边两个 ECU 的 IP 地址分别是，192.168.1.10 和 192.168.1.20 。右边的是 192.168.2.10 和 192.168.2.20。上图中，并没有标注子网掩码，所以默认子网掩码是 255.255.255.0。

上述中，192.168.1.x 是一个网段 Network A ，192.168.2.x 是一个网段 Network B。这两个网段之间通过一个路由器进行路由转换。

如下图所示，当 192.168.1.10 与 192.168.1.20 进行通信时，是不需要经过路由器的，通过 Switch 就可以进行通信。他们本身就是在一个局域网里面的，不需要经过路由器进行三层转发，因为他们本身没有跨网段。

但是，当 192.168.1.10 （Network A 中的）与 192.168.2.10 （Network B 中的）进行通信时， 192.168.1.10 会将报文发送给它的缺省网关 192.168.1.1，192.168.1.1 收到报文后，它会识别其有一个直连的路由 192.168.2.1，然后便会知道需将报文发送给 Network B，这个时候这个报文就会送到 192.168.2.10 。返回来类似。


需要注意的是：不同网段主机无法物理直连进行 IP 通信，必须借助 Router。

✦✦
以太网通信交互案例 - 新浪上网

接下来，我们分享一下，我们的车内，或者电脑是如何上网的。

我们假定的环境是，我们的笔记本要访问新浪的网址。

具体的步骤如下：
第一步：连接 WIFI / 网口，获取 IP 地址，如下图所示。这是一个跨三层的远程通信。

上图中，我们可以读出以下信息：

• 网卡是 Intel 的 AC 8260 无线网卡。

• MAC 地址是：34-F6-4B-CB-0E-E9。

• 这个地址是通过 DHCP 获取的。

• 分配的 IP 地址是：192.168.20.60（这是我们电脑跟外界通信的唯一 IP，所有的 IP 报文里面都是封装的这个 IP 地址。）

• 子网掩码：255.255.255.0

• 租约时间是指，这个地址可以用多久

• 默认网关是指缺省网关，比如说，我不知道是访问新浪，还是百度的时候，路由的时候都是默认扔给这个网关。

• DHCP 服务是指，IP 地址（192.168.20.1）是谁分配的。

• DNS 服务器主要是做一些域名解析。114.114.114.114 是电信的 DNS，8.8.8.8 是谷歌公用的一个 DNS 服务器。

以上就是上网的第一步获取 IP 地址，获取到 IP 地址就决定了上网的一些必备的信息。

第二步：上网的时候，会输入新浪的网址，这个网址是一个 URL，这时，需要请求新浪网址 DNS 解析，将 URL 解析成 IP 地址。需要注意的是，一般大型服务器或者网址，都会对应多个 IP 地址。目的是为了缓冲服务器的压力，更好地为用户提供体验。

当我们在上述两个 DNS 服务器上查找新浪的网址时，都会给我们返回当前给我们分配到的新浪服务器的 IP 地址。

第三步：当拿到 DNS 解析后 IP 地址后，电脑就会向这个 IP 地址发起 http 或者 https 的请求。进而访问到新浪网页，并获取相应的资讯内容。

以太网与汽车结合之美

当前，随着以太网在汽车上的应用，车载以太网除了上述提到的物理层的区别以外，主要还有上层应用的一些区别。

当前，车载以太网主要有以下几种应用。


思考

上述，我们分享了很多车载以太网相关的内容，这里也抛出几个问题供大家思考一下。

刚分析的 DoIP 和 SOME/IP 的报文就是网卡实际发的帧吗，少了点什么？

答：缺少 CRC, 如果 CRC 校验失败，网卡会直接丢弃，能抓到的报文都是校验过的，已经剥离 CRC。

行业的 TC8 测试，主要测试哪些内容，意义何在？

答：主要验证 OSI 模型每个层次协议一致性，让各 ECU 的协议栈能够读懂对方的报文，给出正确响应。

100M 的文件使用 100M 的以太网传输理论需要几秒？

A:1 秒 B:8 秒 C:10 秒 D: 依情况而定

答：正确答案 D，理论时间还需要考虑每帧字节大小。

---

关于 SOME/IP 的理解

AgingMoon 于 2020-02-04 14:54:25 发布

1. 总体说明

如上图所示为标准的网络七层架构，SOME/IP ( Scalable service-Oriented MiddlewarE over IP)，即 “运行于 IP 之上的可伸缩的面向服务的中间件”。他在系统中其实就是一个中间件的存在，所谓 “Middleware 中间件” 是一种独立的系统软件或服务程序，分布式应用软件可借助 Middleware 在不同的技术之间共享资源。所谓的分布式应用软件，在这里指的就是 “服务”；不同的技术之间，在这里指的就是 “不同的平台或操作系统，比如 Adaptive AUTOSAR 系统等。

2. 服务说明

服务是 SOME/IP 的最核心概念。在一个服务中，定义了 Server 和 Client 两个角色：Server 提供服务，Client 调用服务。对于同一个服务，只能存在一个 Server，但可以同时存在多个 Client 调用服务。一个 Service 由 0~ 多个 Event/Method/Field 组成。与 CAN 相比，面向服务的通讯方式能够大大降低总线的负载率。

2.1 Method

调用或引用一个进程 / 函数 / 子程序，通常由 Client 发起，并由 Server 答复。Request 是最常见的一种 Method，由 Client 向 Server 请求数据；Response 是 Request 的结果，由 Server 答复 Client 的 Request。而 Method Fire & Forget 方式，只 Client 向 Server 发起，但 Server 对该请求不回复。

2.2 Event

一个单向的数据传输，只能是 on change 类型，用于 Server 主动向订阅（Subscribe）了相关服务的 Client 发布（Publish）信息。

2.3 Field

由以下三项内容构成：

Notifier：通知，Server 的 Client 订阅了服务后第一时间主动向其发送数据。

Getter：获取，由 Client 向 Server 请求数据。

Setter：设置，由 Client 修改 Server 的数据。

3. 解析 SOME/IP 格式

3.1 Message Type 说明

值	报文类型	说明                                                  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0x00	REQUEST	请求，需要回复
0x01	REQUEST_NO_RETURN	请求，不需要回复
0x02	NOTIFICATION	Notifier/Event，不需要回复
0x80	RESPONSE	回复
0x81	ERROR	带有错误信息的回复

3.2 Payload 说明

通常在传输数据时，为了使数据传输更可靠，要把原始数据分批传输，并且在每一批数据的头和尾都加上一定的辅助信息，比如数据量的大小、校验位等，这样就相当于给已经分批的原始数据加一些外套，这些外套起标示作用，使得原始数据不易丢失，一批数据加上 “外套” 就形成了传输通道的基本传输单元，叫做数据帧或数据包，而其中的原始数据就是 payload。

4. SOME/IP 服务发现 SD##

由于服务需要由 Server 和 Client 共同完成，因此在进行正常的数据传输之前，需要一系列的准备工作确认 Server 和 Client 之间是否已有网络连接。之后，Client 还要询问 Server 能否提供所需的服务，并对服务的 Event 进行订阅。这些工作都是通过 SOME/IP 服务发现（Service Discovery）实现的。

SOME/IP 服务发现用于定位服务实例、检查服务是否可用以及部署发布和订阅句柄。服务发现只能通过 UDP 实现。

服务发现的报文格式与一般的 SOME/IP 报文相同，但是其 Message ID 固定为 0xFFFF8100。

4.1 主要功能

定位服务实例

检测服务实例是否在运行（即服务实例的状态）

发布 / 订阅行为的管理

4.2 SD 报文解析

SOME/IP SD 报文也是一种 SOME/IP 报文，是在 SOME/IP 报文的基础上进行了扩展，增加了 Entry、Option 等字段；Entries 用于同步服务实例的状态和发布 / 订阅的管理，Options 用于传输 Entries 的附加信息。

SOME/IP SD 报文的 ServiceID（0xFFFF）、MethodID（0x8100）、Request ID（0x0000）、ProtocolVersion（0x01）、Interface Version（0x01）、MessageType（0x02）、ReturnCode（0x00）等属性都是固定值。

4.2.1 Entry

Entry 字段可以理解为服务实例的 “入口”，该入口包含服务实例以及需要订阅的事件组的信息。主要通过 Entry 实现提供服务、发现服务，以及订阅事件组的功能。

供服务用 Entries

供 EventGroup 用 Entries

报文中 Type 内容解释如下：

类型	值                                         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
FindService	0x00
OfferService	0x01
StopOfferService	0x01
SubscribeibeEventgroup	0x06
StopSubscribeibeEventgroup	0x06
SubscribeibeEventgroupAck	0x07
SubscribeibeEventgroupNAck	0x07

对于 Offer/ StopOfferService、Subscribe/ StopSubscribe 和 SubscribeAck/ Nack，每一组 Entries 都共用了相同的 Type 值，但通过 TTL 字段可以识别究竟是提供服务还是停止提供服务，是订阅事件还是取消订阅，是订阅成功应答还是订阅失败应答：当 TTL = 0 时，表示报文对应的服务实例不再有效，此时对应的 Type 类型分别就是停止提供服务、停止订阅事件以及订阅失败应答。

4.2.2 Options

每一个 Option 都是有一个 2 字节的 Length 字段、1 字节的 Type 字段和 1 字节的保留位开始的。Length 字段指示的长度是从保留位开始的。Options 的类型如下表所示：

4.3 SD 状态机

状态	服务端行为	客户端行为
Down	Service 不可用	服务未被应用请求，则停留在该状态； 收到 OfferService，启动 TTL 计时器，此时服务若被应用请求，进入 Main；
Init	进入条件： 当服务准备完毕 (Available) 后； During： 收到 Find Service 报文，服务端忽略此消息； 退出条件： 若服务不可用了，将进入 Down； INITIAL_DELAY，当计时器超时后，进入 Repetition。	进入条件： 服务被请求后，进入此阶段； During： 等待 INITIAL_DELAY 时间； 退出条件： 如果此时收到 Offer Service，则取消计时器，直接进入 Main； 如果服务请求被释放，进入 Down； 计时器超时后，发送第一个 find service，进入 Repetition。
Repetition	作用： 为了让客户端快速找到有哪些 Service , During: 如果收到某客户端的 FindService，延迟一定时间后，单独发送单播 OfferService 给服 务请求端； 如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器； 如果收到 StopSubscribeEventgroup 后， 停止此订阅 Entry 的 TTL 计时器； 退出条件： 如果服务不可用，离开此阶段进 入 Down，并发送 StopOfferService 通知所有客户端。	作用： 重复发送 Find service； 退出条件： 收到 Offer Service，停止发送计数和计时，立即进入 Main 触发发送 SubscribeEventgroup ; 如果服务请求被释放，进入 Down，若有订阅，则发送 StopSubscribeEventgroup。
Main	作用： 此阶段将周期性发送 OfferService ; During: 如果收到某客户端的 FindService，不影响发送计数，发送单播 OfferService 给服务请求端； 如果收到 SubscribeEventgroup 后，发送单播 Ack/Nack，启动此订阅 Entry 的 TTL 计时器； 收到 StopSubscribeEventgroup 后，停止此订阅 Entry 的 TTL 计时器； 退出条件： 如果服务不可用，离开此阶段进 入 Down，并发送 StopOfferService。	作用： 不再周期发送 Find Service，不必要负载； During: 收到 Offer Service，触发发送 SubscribeEventgroup ; 如果收到 StopOfferService，则停止所 有计时器； 退出条件： 如果服务请求被释放，进入 DownPhase； 若有订阅，则发送 StopSubscribeEventgroup。

5. SOME/IP 序列化

5.1 概念

序列化（Serialization）指的是将数据结构或对象依据事先定义的规则转换成二进制串的过程；反序列化（Deserialization）指的是将二进制串依据相同规则重新构建成数据结构或对象的过程。

5.2 说明

在 AUTOSAR 中是指数据在 PDU 中的表达形式，可以理解为来自应用层的真实数据转换成固定格式的字节序，以实现数据在网络上的传输。软件组件将数据从应用层传递到 RTE 层，在 RTE 层调用 SOME/IP Transformer，执行可配置的数据序列化（Serialize）或反序列化（Deserialize）。SOME/IP Serializer 将结构体形式的数据序列化为线性结构的数据；SOME/IP Deserializer 将线性结构数据再反序列化为结构体形式数据。在服务端，数据经过 SOME/IP Serializer 序列化后，被传输到服务层的 COM 模块；在客户端，数据从 COM 模块传递到 SOME/IP Deserializer 反序列化后再进入 RTE 层。如下图参考 Autosar Com 过程

5.3 举例

一个 unit32 类型数据（0x12345678）的序列化。

	Byte 0	Byte 1	Byte 2	Byte 3
大端（Big Endian）	12	34	56	78
小端（Little Endian）	78	56	34	21

---

基于车载以太网的音视频传输 AVB vs RTP

Life_I 于 2021-01-20 10:32:25 发布

背景

问：近些年，随着智能驾驶技术的发展和车内影音娱乐系统的丰富，越来越多的音视频数据需要在车内网络进行传输。现在车载以太网日渐成熟，那么，我们可以使用车载以太网在车内网络传输音视频数据吗？

王师傅：答案是肯定的。而且由于成本、传输带宽等方面的因素，在有些场景下，也许只有车载以太网才能满足我们的传输需求。

问：既能传输普通数据又能传输音视频数据，感觉很方便啊。那么，传输音视频数据和其他普通数据采用的传输协议相同吗？

王师傅：是不同的，网络上有专门适用音视频传输的协议。目前，在车载以太网中常用的方案有两个，分别是 RTP 和 AVB。

• RTP（Real-time Transport Protocol），实时传输协议，采用 RTP 和 RTCP（Real-time Transport Control Protocol，实时传输控制协议）两个子协议实现音视频数据的传输，遵循的标准为 RFC 3550。

• AVB（Audio Video Bridging），音视频桥接技术，采用 IEEE 1722，IEEE 802.1AS，IEEE 802.1Qav，IEEE 802.1Qat（802.1 Qav 和 802.1 Qat which have subsequently been incorporated into IEEE 802.1Q）等一系列 IEEE 标准，通过保证带宽、控制传输延时、精准时钟同步等功能和机制实现音视频数据在网络上的实时传输。

这里要注意的是，不管采用哪种技术，这里所传输的有效载荷数据（payload）是一样的，都是音视频媒体数据（e.g. H.264），不同的是所采用的传输方式。

方案选择

问：那么具体应该选择哪种方案呢，或者说什么时候用 RTP，什么时候用 AVB 呢？

王师傅：这个取决于网络架构，应用场景和成本等因素，需要具体问题具体分析。RTP 的机制相对比较简单，而 AVB 的机制会复杂一些。下面我们详细介绍一下。

下图是 OSI 网络模型，左边是 AVB 架构，右边是基于 TCP/IP 的传统架构。

RTP

我们可以看到 RTP 协议位于模型的 5 至 7 层，底层为传输层，在 RFC 3550 中推荐使用 UDP 为其底层传输协议，有的同学可能知道 IEEE 1733，（一份将 RTP 协议和 AVB 相关机制整合使用的标准），但由于过于小众，今天这里就不过多介绍了。RTP 协议本身没有连接的概念，为端到端的传输模式，无法保证数据的传输质量。我们知道在复杂的网络环境中，采用 UDP 传输的数据有可能出现丢包的情况，RTP 可以借助 RTCP 提供的传输质量反馈信息，调整数据发送行为，从而尽可能的保障传输服务。但是，如果车内网络环境简单，通过合理的设计，我们可以规避传输过程中有可能出现的种种问题，从而使用 RTP 在车内进行音视频数据传输。

比如下面的应用场景：

图 1

摄像头和显示屏直连，摄像头采集视频数据，通过以太网传输至显示屏，显示屏实时显示摄像头所捕获到的视频画面。类似这样一对一直连的网络拓扑，如果这条链路上的带宽充裕，可以直接使用 RTP 进行音视频传输。

问：感觉 RTP 很简单啊，是不是直连的网络拓扑，一般都可以使用 RTP 进行传输呢？

王师傅：是的，可以这么说。如果不是直连，但场景中 Switch 节点转发延时可控，在链路带宽充裕的情况下，RTP 一般也都可以满足传输需求。

AVB

问：了解了，那网络环境复杂就需要使用 AVB 吗？

王师傅：和 RTP 相比，在 OSI 模型中，我们可以看到 AVB 的一系列协议是直接基于数据链路层进行传输的，简单的层级架构，使数据的处理时间更加可控。AVB 共有四个子协议，分别是：

・IEEE1722，音视频传输协议 AVTP
・IEEE 802.1AS，精准时间同步协议 gPTP
・IEEE 802.1Qav，时间敏感数据转发和队列优化协议 FQTSS
・IEEE 802.1Qat，流预留协议 SRP

我们通过下面的场景具体介绍下 AVB 技术的应用情况：

图 2

如图所示，车内网络中摄像头、显示屏、ECU1 和 ECU2 通过 Switch 相互连接，同时，摄像头、ECU1 和 ECU2 均有与显示屏通信的需求。如果 ECU1 和 ECU2 有突发的数据需要发送至显示屏，那么 Switch 和显示屏之间的链路带宽就会被大量占用，导致摄像头的视频数据无法准确传输。其次，我们知道车载以太网传输路径上的延时主要来自于 Switch 的转发延时，如果有大量数据在 Switch 队列中等待，网络就会出现拥塞，导致延时，从而影响数据的传输质量。以上场景，想要实现实时视频传输，有两个问题需要解决：其一是保证链路的传输带宽；其二是要控制 Switch 的转发延时。

这种情况下，基于 UDP 的 RTP 传输就很难满足需求了，需要 AVB 技术来解决这些问题。首先要获取多流并发时各个数据流量的所需带宽并静态配置，其次再将数据划分出不同优先级，保证高优先级数据优先转发。AVB 中，FQTSS 可以通过基于信用的转发方式（CBS，credit-based shaper），在保证高优先级数据转发的同时，也可以转发其他低优先级数据。优先级可划分为 SR class A，SR class B 等级别，在这个场景中，如果视频数据的优先级较高，可以将其划分为 SR class A，在 7 跳之内，SR class A 数据默认的最大传输时间仅为毫秒级别，完全可以满足实时视频传输的需求。通过以上方法，场景中的带宽和延时问题都可以用 AVB 技术解决，进而就可以实现流畅的视频数据传输了。

结束语

通过以上应用实例，我们简单的介绍了 RTP 和 AVB 两种在车内网络传输音视频数据的方案。如果网络环境简单，有足够的传输带宽，那么基于 TCP/IP 架构的 RTP 可以直接满足端到端的音视频传输需求，简单方便，性价比高。但是如果车内音视频数据的传输路径上有一个或多个 Switch 节点，存在多流并发的场景，或者有时钟同步的需求，就需要借助 AVB 技术中的 gPTP，FQTSS，AVTP 等技术和机制才能实现稳定的实时音视频数据传输。具体使用哪种方案，是使用所有机制还是选择性使用，还需要根据车型和应用场景，具体案例具体分析，借助时间分析工具进行仿真优化，才能呈现出最优的传输效果。

---

via:

• 车载以太网帧结构详解 埃恪深科技 汽车电子与软件 2022 年 01 月 19 日 07:00
  https://mp.weixin.qq/s/yL8KzwoCZx2VdM7ONWaJkg

• 关于 SOME/IP 的理解_some ip-CSDN 博客AgingMoon 于 2020-02-04 14:54:25 发布
  https://blog.csdn/AgingMoon/article/details/104166715

• 基于车载以太网的音视频传输 AVB vs RTP_以太网传输视频信号-CSDN博客 Life_I 于 2021-01-20 10:32:25 发布
  https://blog.csdn/Life_I/article/details/112857873

本文标签： 以太网音视频详解结构格式