汽车以太网协议之 SOME/IP（上）

2011年，宝马集团开发设计了一套中间件，该中间件能够实现以服务为导向的通信方式，宝马将该面向服务的通信方式叫做 SOME/IP。由于其知名度逐渐被 AUTOSAR 接纳，并在2014年集成进 AUTOSAR 4.X 中（后文会对 AUTOSAR 做更详细的介绍）。 SOME/IP 的官网是 https://some-ip.com/index.shtml ，该网站的版权归 Lars Völker 博士所有，Lars Völker 博士 2010年加入宝马，一直从事汽车以太网相关的工作，他是 SOME/IP 和 SOME/IP-SD 规范的发明者和维护者。

SOME/IP是一种汽车中间件解决方案，其全称是Scalable Service-Oriented Middleware over IP，即位于 IP 协议层以上的一种面向服务的可扩展的中间件。全称有点拗口，下面通过拆解来说明。

“中间件”，该术语起源于复杂的软件系统开发，用以实现软件组件之间的数据交换，这种数据交换通常需要经由网络，中间件的任务就是确保需要交换数据的软件组件在网络中透明地传输数据。SOME/IP 作为一种中间件负责组织传输复杂数据（消息传递）并约定软件组件之间的函数调用（远程过程调用，RPC）。

如今汽车中的软件数目十分庞大，并且还会随着汽车内部功能和系统的分布扩张而不断增加。这些分布式功能可能使用到一个 ECU 中的不同进程，也可能扩展到不同 ECU 的各种进程中去，随着系统复杂度的增加，不可能仅仅将消息放入到网络中传输就完成功能的实现，还需要使用 RPC 来正确控制这些分布式功能；另外，不同 ECU 可能使用不同的软件架构以及操作系统，因此还需要中间件来桥接不同的便携式操作系统接口（如 Linux 或 QNX 和 AUTOSAR 系统之间的衔接）。

“可扩展”，表示 SOME/IP 能够实现不同硬件平台、不同操作系统或嵌入式固件以及不同应用软件的异构设备之间的可扩展性和互操作性。

“面向服务” ，面向服务通信的概念是与传统汽车电子行业中的面向信号通信相对应的一个概念，面向服务通信是仅当客户端请求或服务器通知特定订阅者时，才在客户端与服务器间交换数据。这确保了不会浪费带宽，并且仅在需要的时间进行数据通信。

高端信息娱乐系统最需要基于服务提供的复杂接口，如复杂的数据类型、对数据库的访问、列表的传输等。在其他使用车载网络的系统中，CAN  总线的使用仍占主导地位，信息在网络中传输，由接收器决定如何处理该信息。但是，在新型应用领域，如辅助驾驶领域，CAN 的通信方式越来越不适用。另外，在 CAN 中，数据长 8Byte，且没有大量的头信息，这些均限制了 RPC 或服务发现( Service Discovery , SD ）的使用。

 “位于 IP 协议层以上”，这表明了 SOME/IP 协议在汽车以太网协议栈中所处的位置，汽车以太网协议栈总共可划分为五层，分别为物理层、数据链路层、网络层、传输层、应用层，SOME/IP 协议是一种应用层协议。

SOME/IP 是一种汽车中间件解决方案。它从一开始就被设计为能够完美适配不同尺寸和不同操作系统的设备，像是小型 ECU 如摄像头、 AUTOSAR ECU、以及信息娱乐 ECU 如车载信息娱乐系统（Head Units），还有远程通信设备等，都可以使用 SOME/IP 协议有效地交换 ECU 间的消息。同时 SOME/IP 还支持信息娱乐领域的功能以及车辆中其他领域的功能，使 SOME/IP 能够用于 MOST 以及更传统 CAN 方案的替换方案。

SOME/IP 支持广泛的中间件功能：

【表格】

对于表中提到的服务发现再补充两句，SOME/IP-SD 是 SOME/IP 中的服务发现机制，通过 SOME/IP-SD，SOME/IP 可以确定服务是否可用，客户端可以通过 SOME/IP-SD 来查找服务的地址，判断服务的可用性，或者订阅事件组等。

3.1 面向服务的通信

区别于传统 CAN/LIN 等面向信号（Signal-Oriented）的通信方式，SOME/IP 提供面向服务（Service-Oriented）的通信方式。

比较一下，面向信号的通信，这种通信是为了将信号进行传输；面向服务的通信，这种通信是为了对服务的相关信息进行传输。

由于基于信号的通信解决方案中的软件和硬件紧密耦合，因此 ECU 之间的通信是静态定义的。 基于信号的通信是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。

而在面向服务的架构中，发送方仅在接收方需要时才发送数据。这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载，不过这仅仅是基于服务通信的一方面。当谈论到自动驾驶、ADAS、联网汽车等时，面向服务的架构 (SOA) 是必不可少的。在以太网和 SOME/IP 的支持下，SOA 将整个系统建模为 service interface，可以轻松地将新软件添加到系统中，而无需担心与其他软件的兼容性。

如上图所示：

SOME/IP 为应用程序提供抽象的面向服务的接口，因此，应用程序不需要处理 IP 地址和端口，而只需要处理服务。Server 端提供了一个实现服务接口的服务实例（服务接口，直白理解就是服务与外界通信的接口，也就是服务模块与外界沟通的基本出入口）。Client 端则通过SOME/IP 方式使用服务实例。

3.2 SOME/IP 通信机制

SOME/IP 支持的通信模式包含以下四种形式：

• Request & Response Method（双向方法）：客户端发送请求，服务端回复响应，是一种有问有答的对话方式。

• Fire & Forget Method（单向方法）：客户端发送请求，服务端不需要响应，是一种只问不答的对话方式。

• Event（事件）：客户端首先使用了 SOME/IP-SD 订阅（Subscribe）某一事件组（Event Group），当事件组中包含的事件发生之后，服务端就会自动给订阅了该事件的客户端发送相关的通知（Notification），Notification 消息不需要接收方进行回复。请注意，SOME/IP 协议中的 Event 总是分组在一个 Event Group 中,因此只能订阅 Event Group 而不是Event本身。

• Fields（字段）：Field 表示可以远程访问的“属性”，即客户端可以远程访问的服务端中的变量。

客户端可以通过远程调用 Getter 方法获取 Field 的值，也可以通过远程调用 Setter 方法设置 Field 的值。另外和 Event 相似，当客户端订阅了某个事件组，若Event Group中包含的 Field 发生变化，服务端会主动的通过 Notification 消息通知客户端；当然，用户也可以选择周期发送Notification 消息。

Field 和 Event 的区别是：Field 是一个持续存在的变量，比如多媒体音量、车速、环境温度等，这些可以在任何时刻获取；而 Event 指的是一个事件，事件没有发生就不存在，比如发生碰撞，出现故障等。

下面看一个实际的例子来对这些通信模式产生更具体的印象：

服务是由智能摄像头控制器提供的，可提供的具体服务之一是检测限速标志。ADAS（高级辅助驾驶系统） 需要摄像头提供的限速标志信息，因此 ADAS 控制器会作为客户端。

4 种通信模式的例子：

1. Request & Response Method：ADAS 控制器向摄像头控制器请求获取摄像头的状态，摄像头控制器将状态返回给 ADAS 控制器。

2. Fire & Forget Method：ADAS 控制器给摄像头控制器发送单向消息，告诉摄像头 ADAS 下线了。

3. Event：当摄像头检测到限速标志时，通知 ADAS。

4. Field：ADAS 通过远程调用 Getter 方法获取限速值、距离等。

3.3 SOME/IP 协议报文格式

SOME/IP 协议在 OSI 七层网络结构中位于应用层，从功能上讲，SOME/IP是一种将服务接口进行打包或解包的中间件：从应用层发送的数据按照 SOME/IP 的格式打包后，再传递到下层的 TCP/IP 或 UDP/IP层，再进行逐层打包和封装，最终通过物理层以比特流的形式进行传输；接收时则按照与打包相反的规则进行解包。

SOME/IP 报文由消息头（Header）和数据段（Payload）组成，报文结构如下：

3.3.1 Message ID [32 bit]

Message ID 用于唯一标识服务的 Method 或 Event，可区分不同的服务。Message ID 对于整个车辆系统来说必须是唯一的 。

Message ID 的结构：

Message ID 前 16 位是 Service ID，每个服务需要有一个唯一的服务 ID，由系统集成商进行标识。后 16 位是 Method ID。

对于 Method ，Message ID 的结构如下：

其中 Method ID 的第一个位（bit）是 0。使用 16 位的 Service-ID 和从 0 位开始的16位的 Method-ID (对于实际值，Method-ID中还剩下15位)，这将允许最多 65536个服务，每个服务最多 32768 个方法。

对于 Events 和 Notifications ，Message ID 的结构如下：

对于 Events 来说，Method ID 的第一个位（bit）是 1。这意味着每个服务最多可以有32768 个事件或通知。

可以看出，MethodID 的最高位可用来判断具体的通信方式，即采用的是 Method 还是Event 。

3.3.2 Length [32 bit]

Length 字段长度为 32位，包含从 Request ID 开始到 SOME/IP 消息结束的长度，长度是以字节为单位的。注意，Length 不包括 Message ID 和 Length 。

3.3.3 Request ID [32 bit]

Request ID 是客户端的唯一标识符，要能在响应到达前或超时前不被重用。

在生成响应消息时，服务器必须将 Request ID 从请求中复制到响应消息中去，这才使得客户端可以将响应对应到发出的请求上。

Request ID 前 16 位是 Client ID，用来区分特定的客户端，在整车系统中该值必须唯一；后 16 位是 SessioID，用来标识同一客户端的多次请求。

SessionID 主要用于 Request&Response 类型的多次调用，每调用一次，SessionID 增加 1。

如果会话不在活动状态，SessioID 设置为 0x00，当会话处于活动状态时，SessioID 设置为 [0x1, 0xFFFF] 范围内的值。当 Session ID 为 0x00 时，服务器并不会对这个请求作出反应。

3.3.4 Protocol Version [8 bit]

该字段存放 SOME/IP 协议的版本号，用来识别使用的 SOME/IP 头格式（不包括 payload 的格式）。目前固定为 1。

3.3.5  Interface Version [8 bit]

该字段存放服务接口的版本号，用来识别服务接口的主版本号。

3.3.6 Message Type [8 bit]

Message Type 字段用于区分不同类型的消息，包含如下值：

【表格2】

当没有错误发生时，常规请求 (Message Type 0x00) 应由响应 (Message Type 0x80) 响应。如果发生错误，将响应包含错误的消息 (Message Type 0x81)。

Message Type 的第三高位(=0x20=0b00100000) 被称为TP-Flag，设置为 1 表示当前的SOME/IP 消息是一个 segment。

3.3.7 Return Code [8 bit]

Return Code 用来表示请求是否被成功处理。为了简化 header 布局，每个消息中都会传输 Return Code 字段。

【表格3】

3.3.8 Payload [variable size]

Payload 由 Event 的数据元素或 Method 的参数组成，大小取决于所使用的传输层协议，对于UDP，payload 介于 0 到 1400个字节之间，由于 TCP 支持 payload 分段，所以支持更大的长度。

注意：SOME/IP 所有的 Header 字段必须以网络字节顺序(大端字节序)编码。Payload 内参数的字节顺序应由配置来定义。

3.4 SOME/IP 服务示例

下面来看一个场景示例，以 CD 播放器（CD_Player）服务为例。

通常使用接口描述语言（IDL）来定义服务的服务接口，如下所示：

在定义了上述接口之后，假设此时用户（ HU，车载主机 ）希望将 CD_player 设置为 Track number 10，那么 HU 将会向 CD 播放器（服务器）发送命令 CD_Player.track_number.set (10)。该服务的方法为 track _ number.set , set 值为10。此命令设置的通信方式为 request/response ，即该命令设置后希望接收到回应。

另一个场景：用户（ HU ）希望打开 CD 托盘，并反馈完成情况。那么，在上述命令中，用户将向 CD 播放器发送设置指令 CD_Play.open_tray()，且希望得到 CD 播放器的反馈（基于 request&response 的通信方式）。当 HU 接收到 CD_Player.open_tray() == OPEN 指令时，说明它发出的命令已经成功执行了。

在上述情境中，用户还可以向 CD 播放器发送 read (“get field ”）指令，接收 CD 播放器 track 状态的信息。它也可以订阅 CD 播放器 track 状态信息：每当 CD 播放器状态改变时都将自动向用户发送通知（“event”)。还有一条命令：“Subscribe.CD_Player.Eject()”，当 CD 托盘打开后，CD 播放器会向所有订阅用户发送此命令。

3.5 SOME/IP 协议报文格式

SOME/IP-SD 依赖于SOME/IP，SOME/IP 本身支持 TCP 和 UDP 通信，但 SOME/IP-SD只能通过 UDP 进行传输。

SOME/IP-SD 主要用于：

• 定位服务实例（service instance）

• 检测服务实例是否在运行

• 实现发布/订阅（Publish/Subscribe）

以上功能主要是通过 offer 消息来实现的，即每个设备广播(组播)的消息中包含该设备提供的所有服务。如果客户端应用程序需要某项服务，但目前没有服务器主动提供，那么客户端也可以发送 “find” 消息。

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

下图给出一个 SOME/IP-SD 报文示例：

可以看出，报文中存在两组 Entry Array，一个 SD 报文可能包含多个 Entry，每个 Entry大小都是 16 个字节，一个 Entry 可能包含 0-2个 Option。

下面来看具体每项的含义：

MessageID：

对于 SD，ServiceID 固定为 0xFFFF ，MethodID 固定为 0x8100。

Request ID：

ClientID 一般固定为 0x0000。SessionID 初始为 0x0001，每发送一次数据后便加 1。

Protocol Version：

固定为 0x01。

Interface Version：

固定为 0x01。

Message type：

固定为 0x02 (Notification)。

ReturnCode：

固定为 0x00 (E_OK)。

Flags：

SOME/IP-SD 报头以一个 8位的 Flags 字段开始，它用于标识全局 Service Discovery 信息。Flags = 重启标志(Reboot Flag) + 单播标志(Unicast Flag) ，如下图所示：

Unicast Flag 应设置为单播标志（即设置为 ‘1’），这意味着声明该 ECU 支持接收单播消息。

Flag 字段中的未定义位应静态设置为 ‘0’。

Reserved：

为空，当前不需要考虑；

Entries Array：

Entry 可以理解为“入口”，包含了服务实例以及需要订阅的事件组的信息，Entries Array 分为两类，针对服务的 Service Entry 和针对事件组的 Eventgroup Entry。

格式分别如下：

Service Entry：

Service Entry 用于服务发现。

Type：FindService (0x00)、OfferService (0x01)、StopOfferService (0x01)；

网络中未收到相关服务的 OfferService 或者暂未收到时，而客户端又需要访问该服务，那么客户端可以发出 FindService 去主动寻找服务，如果服务已经就绪，会回复 OfferService 报文；服务就绪后，会主动发出 OfferService，用以告知组播内其他节点，该服务已经启动，可以创建连接；当服务不可用时，会主动发送 StopOfferService 报文，用以告知组播内其他节点，该服务目前不可用，停止发送请求，并取消订阅。

Index First Option Run：Option Array 中第一个 Option 的索引；

Index Second Option Run：Option Array 中第二个 Option 的索引；

# of opt 1：第一个 Option 使用的选项数；

# of opt 2：第二个 Option 使用的选项数；

Service ID：表示该 Entry 所涉及的服务或服务实例的 Service ID；

Instance ID：表示该 Entry 涉及服务实例的 Instance ID，如果包含一个服务的所有服务实例，则设置为 0xFFFF；

Major Version：服务的主版本号；

TTL：Entry 的生命周期，单位为秒；

Minor Version：服务的次版本号。

Eventgroup Entry：用于事件订阅。

Type：SubscribeEventgroup（0x06）、StopSubscribeEventgroup（0x06）、  SubscribeEventgroupAck（0x07）、SubscribeEventgroupNack（0x07）；

当客户端收到服务 OfferService 之后，客户端可以发送 Subscribe 报文主动跟服务器订阅感兴趣的事件组；当客户端订阅某个事件组之后，如果后续发现不再需要该事件组的数据了，可以通过 StopSubscribe 报文来通知服务器，避免不必要的数据交互；当服务器收到客户端的 Subscribe 报文之后，需要先行判断是否符合可订阅的条件，如果该客户端满足事件组订阅条件，则返回 SubscribeAck ，告知客户端订阅成功，当事件组内的事件准备就绪之后，服务器会以某种约定好的形式发送相关事件给成功订阅的客户端，如果该客户端不符合事件组订阅条件，那服务器就会直接回复 SubscribeEventgroupNack，告知订阅失败。

Index First Option Run：Option Array 中第一个 Option 的索引；

Index Second Option Run：Option Array 中第二个 Option 的索引；

# of opt 1：第一个 Option 使用的选项数；

# of opt 2：第二个 Option 使用的选项数；

Service ID：表示该 Entry 所涉及的服务或服务实例的 Service ID；

Instance ID：表示该 Entry 涉及服务实例的 Instance ID，任何实例的 Instance ID 都不能设置为 0xFFFF（这一点和在 Service Entry 中的不同）；

Major Version：服务的主版本号；

TTL：Entry 的生命周期，单位为秒；

Reserved：应被设置为 0x000;

Counter：用于区分同一订阅者的订阅事件组。如果不使用，设置为0x0；

Eventgroup ID：事件组 ID。

Option Array：

主要存放 Entry 的附属选项信息，对于不同类型的消息，要配置的选项也不一样。

比如 Type=0x04 时，用于传输 IPv4 相关的参数，包括服务的 IP 地址、TCP 还是 UDP、端口号等：

更多的选项信息可参考 https://some-ip.com/standards.shtml 上提供的文档。

3.6 SOME/IP-SD 应用场景

这里参考《汽车以太网 Automotive Ethernet (原书第2版) 》，罗列 SOME/IP-SD 的几种应用场景。

3.6.1 汽车启动时

汽车启动是汽车系统设计中最复杂的任务之一。汽车中的每个 ECU 在启动时均有不同的行为。有些 ECU 启动速度快，有些则很慢。一些 ECU 即使在电压下降到 3.5V 的情况下，仍能正常启动，而可能对于一些 ECU 而言 8V 的启动电压都还不够。因此，汽车在启动时，各个功能就绪所需要花费的时间都不一样。如果不使用服务发现协议（ SD )，则需要规定一个确定所有功能就绪的时间点。这需要根据花费最长启动时间的功能或 ECU 来定义。如果使用 SD ，则每个功能/ECU 都可以在准备就绪时宣布其可用性，且通常可以提前提供用户功能。在启动过程中，SD 在交换式以太网网络中还具有另外一个优势：交换机可以直接通过 SD 消息建立地址表。

3.6.2 客户变更时

客户在购买汽车时，汽车厂商向客户提供了许多选择。作为一条经验法则，汽车越大，价格越高，可供选择的选件或功能就越多。大量的选择意味着汽车制造商根据特定客户的要求制造专属汽车。如果没有 SD ，每个 ECU 需要通过静态配置确定汽车中其他 ECU 功能的可用性。但是通过 SD , ECU 则可以自行建立车辆中可用的功能/ECU 列表，而不需要任何特定组合的预配置。这一方式显然更为可靠。因此，汽车越复杂，SD 的优势就越大。

3.6.3 事件传输失败时

在仅支持 Fire&Forget 通信方式的网络中，发送方很难察觉接收方消息的接收是否成功，没有接收到任何消息的接收 ECU 始终认为没有事件发生、或者没有参数变更。那么，如果 SD 在后台工作的话， ECU 会立即掌握服务器/另一个 ECU 何时不再提供某种功能。这样，更容易发现通信故障，并且可以在特定的时间范围内激活相应的故障模式。

3.6.4 局部网络保证能源效率时

随着车载网络规模的不断扩大和 ECU 数量的增加，能耗问题不容忽视。如果能够做到在特定时刻仅对使用的 ECU 进行100％供电那是最理想的。比如，客户已经抵达目的地且停放好车辆，但是希望通过内置的免提系统完成呼叫，那么汽车应该停用网络上不需要的其他 ECU ，包括发动机控制系统或传动系统等。这个例子表明，车载网络可能会动态变化。在变化的环境中，工作的 ECU 必须知道哪些功能仍然可用，哪些不可用。假如没有 SD ，也可以通过超时来实现上述目的。但是，在使用场景相同的情况下，使用超时方法的响应速度不如 SD 快。通过 SD 获取功能可用信息将更具有时效性。车载网络越复杂，就越能体现基于服务的通信方式和 SD 的优势。

汽车以太网聚焦于车内联网，即车内各种电子控制单元（ECU，Electronic Control Unit）之间的通信。

“随着消费者对车载连接和高级驾驶辅助 (ADAS) 的需求不断增长，汽车行业一直面临着这样一个挑战，即提供具有竞争力的创新功能，同时最大限度降低成本。汽车以太网技术允许多个车载系统通过一对非屏蔽双绞线（UTP）同时访问信息。通过消除繁琐的屏蔽布线，汽车制造商可以显著降低连接成本和布线重量。” 这段来自 OPEN Alliance Inc. 官网上的描述简单明了的介绍了汽车以太网技术发展的初衷。

2013年，采用博通 BroadR-Reach 技术的宝马 X5 量产，标志着汽车以太网技术的正式应用。紧接着，各种行业组织和国际标准组织也积极参与到汽车以太网技术的标准化工作中，推动了汽车以太网技术的发展。在汽车以太网标准化方面，下面 4 个标准化组织或联盟起到了主要的推动作用，它们是 IEEE 802.3 和 IEEE 802.1工作组、OPEN 联盟、汽车开放系统架构联盟 AUTOSAR、以及 AVnu 联盟。

4.1 IEEE

Institute of Electrical and Electronics Engineers，电气和电子工程师协会，他们根据汽车行业需求，对汽车以太网的物理层和上层通信协议进行标准化。

针对汽车以太网标准，IEEE 组织也对 IEEE 802.1 和 IEEE 802.3 标准进行了相应的补充和修订。具体为：

IEEE802.3bw ，指的是 100BASE-T1 的相关标准，是用一对双绞线传输的100Mbps 汽车以太网。这里区别于 100BASE-TX（标准民用100Mbps以太网）。

IEEE802.3bp ， 指的是 1000BASE-T1 的相关标准，是用一对双绞线传输的1000Mbps 汽车以太网。这里区别于 1000BASE-TX（标准民用 1000Mbps 以太网）。

4.2 OPEN Alliance (One-Pair Ether-Net) Inc.

是一个非盈利的、开放的行业联盟，主要由汽车行业和技术供应商参与合作，鼓励在汽车网络应用中广泛采用基于以太网的网络作为标准。

据 OPEN Alliance 官网发布的新闻显示，截至 2020 年 2 月， OPEN Alliance  共成立了 15个技术委员会（Technical Committees），专注于推动汽车以太网标准。他们的目标是创建和发布以太网领域各个方面的规范，比如：

• 为汽车千兆以太网 (TC12)、10 兆以太网 (TC14) 和多千兆以太网 (TC15) 创建一致性、互操作性和 EMC 测试规范。

• 为 ECUs (TC8)中的汽车以太网硬件组件和软件栈的集成创建验证试验。

• 定义汽车以太网通道 (TC9) 的布线和连接器要求。

• 为不同的速度等级（TC10）指定以太网睡眠和唤醒的功能和需求。

• 为以太网交换机 (TC11) 创建规范和资格测试要求。

OPEN Alliance 发布的 TC8 是目前行业内关于汽车以太网的标准测试规范之一，在 2.0 版本中加入了对 SOME/IP 协议的测试。

4.3 AUTOSAR 联盟

Automotive Open System Architecture，即汽车开放系统架构，是一家致力于制定汽车电子软件标准的联盟（参与者有全球各家汽车制造商、零部件供应商以及各种研究、服务机构）。

汽车行业里有众多的整车厂（OEM）和供应商。每家 OEM 会生产很多车型，对不同子系统和零部件会选择不止一家供应商，每家供应商也会向不止一家 OEM 供货。减少开发成本最有效的办法就是，尽可能让产品可重复利用，用数量来分摊开发成本。OEM 希望可以让同一套系统和部件用在不同的车型上,同一辆车上来自不同供应商的各个系统和部件可以相互兼容；供应商希望开发出来的部件和算法可以通过简单的软件调整就供给不同的 OEM。此外，各个供应商的开发进度往往是不同步的。OEM 希望可以在供应商开发的过程中就可以测试该部件是否与整车上的其它系统正确配合。因此，需要一种统一的、标准化的系统描述方法。

这便是 AUTOSAR 的初衷，即通过提升 OEM 以及供应商之间软件模块的可复用性和互换性来改进对复杂汽车电子电气架构的管理。

Classic AUTOSAR 从 4.0 版本开始支持汽车以太网通信，主要包括Ethernet驱动、Ethernet接口、TCP/IP、Socket Adaptor、DoIP、UDPNM、SOME/IP等软件模块。

SOME/IP 被 AUTOSAR 集成的几个关键发展节点如下：

• AUTOSAR 4.0 – 完成 SOME/IP 消息的初步集成；

• AUTOSAR 4.1 – 支持 SOME/IP-SD 及其发布/订阅功能；

• AUTOSAR 4.2 – 添加 transformer 用于序列化以及其他相关优化；

• AUTOSAR 4.3 – 修复一些 transformer bug ，同时添加针对大量 UDP 数据包的 SOME/IP-TP 协议以及其他 SOME/IP-SD 的优化工作。

4.4 Avnu 联盟

AVnu 联盟是由博通联合思科、哈曼和英特尔成立，致力于推广 IEEE 802.1 的 AVB 标准和时间同步网络（TSN）标准，建立认证体系，并解决诸如精确定时、实时同步、带宽预留以及流量整形等重要的技术和性能问题。

正是由于 IEEE组织、OPEN 联盟、 AUTOSAR 联盟、以及 AVnu 联盟的共同发展与合作，规范了汽车以太网符合 OSI 模型的整体架构。

图中蓝底色的部分为汽车以太网技术协议，灰底色的部分为传统以太网技术协议。

以太网提供了主干网，TCP 和 UDP 提供了传输层，但数据序列化、远程过程调用等还需要一个中间件，这也正是 SOME/IP 被创建的原因！

另外，上图中涉及的汽车以太网应用协议的基础特点以及应用场景罗列如下：

【表格4】

[1] 未来汽车的神经与血管 — 车载以太网 – 大大通

[2] 车载操作系统（五）：AUTOSAR规范

[3] Some/IP如何应用于面向服务架构SOA架构开发

[4] 汽车以太网标准化组织介绍_怿星科技的博客-CSDN博客

[5] COMMUNICATION PROTOCOLS FOR ETHERNET IN THE VEHICLE

[6] How SOME/IP Enables Service Oriented Architecture in ECU Network

[7] 【SOME/IP通信系列】(九)解读SOME/IP-SD服务发现协议

[8] SOME/IP-SD 深入浅出

[9] 汽车以太网协议知多少

[10] What is SOME/IP Protocol 

[11] 一文搞懂车载以太网之SOME/IP

[12] Open Alliance Open Alliance 官网

[13] 基于SOME/IP的残余总线仿真环境

[14] 一文搞懂车载以太网之SOME/IP 

[15] Classic Platform – AUTOSAR

[16] 一文入门车载以太网，吐血整理! 不看可惜！

[17] 什么是AUTOSAR？读这篇文章就够了

[18] 面向服务通信与面向信号通信

[19] SOME/IP有那么难吗？

[20] Adaptive AUTOSAR vs Classic AUTOSAR

[21] SOME/IP 如何在ECU网络中实现面向服务的架构_多源焦点

[22] Some/IP如何应用于面向服务架构SOA架构开发_Mode_Type_套接字

[23] How SOME/IP Enables Service Oriented Architecture in ECU Network

[24] 详解SOME/IP协议文档_aFakeProgramer的博客-CSDN博客_someip tp

[25] vsomeip – GENIVI的SOME/IP开源实现

[26] 车载以太网 | 测试之实锤-SOME/IP概述及TC8 SOME/IP 测试实践 – 知乎

[27] 《汽车以太网 Automotive Ethernet (原书第2版) 》