之前系列文章中提到，关于自适应 AUTOSAR （AP Autosar）平台是基于面向服务SOA的通信，以实现对底层硬件和其他软件组件的更大独立性。而在经典AUTOSAR（Classic Autosar）中，ECU提取和 SWC 描述本地静态存储在相关 ECU 上的 ROM 组件中。这些共同定义了整个系统内ECU的行为，不能随意交换。

另一方面，在新平台中，每个应用程序都有一个所谓的清单文件Manifest，该文件描述了应用程序提供和需要的所有接口、方法和服务。Manifest与应用程序的机器代码一起，这形成了一个可以在任何自适应 AUTOSAR ECU 上执行的单元。清单和应用程序代码都被持久存储并加载到正在执行的 ECU 的 RAM 中执行，每个应用程序都在单独的虚拟地址空间中执行，以排除应用程序之间的交互。

底层平台是（至少符合 PSE51 的）POSIX 操作系统，这意味着任何兼容的应用程序都可以在现有的 ECU 上运行。应用程序作为单独的进程执行，并且可以使用标准化库和接口 访问操作系统和抽象硬件的功能。

从应用程序的角度来看，与其他应用程序或进程的通信是局部透明的，即与远程 ECU 上的应用程序的通信在同一 ECU 上运行的应用程序的连接是相同的。因此，应用程序之间的通信路径可以在运行时确定——这可以实现应用程序的动态（重新）分配，而不会对其他应用程序的功能产生负面影响。为了实现这一点功能，SOME/IP 协议可用作中间件。

基于Some IP的ADAS系统架构

下图显示了一种通用的车辆架构，其中使用了经典和自适应 AUTOSAR ECU。由于对于安全相关组件的实时要求和绝对稳健性要求，该架构保留 CAN 总线控制的 AUTOSAR 经典 ECU 用于动力总成集群（例如发动机控制、制动系统、安全气囊）。此外，与复杂的 ADAS 系统（例如车道偏离警告或停车辅助系统）和传感器系统（例如雷达或摄像头）相比，这些组件只需要相对较低的数据速率就能实现其功能。平台之间的连接由中央网关（也称为主机）建立。因此，消息可以在基于经典AUTOSAR架构的CAN信号下，将总线结合与面向服务的通信中实现相应的功能及信号输出。

下面使用一个简化模型对整体的通信过程对如上示例进行详细的说明。其中，实线连接表示基于以太网的 SOME/IP 网络。虚线表示无线接口，虚线表示有线连接（通过CAN总线）。

上图中的模型由五个通信节点组成，其中包含Π 网关、Π ADAS、Π 连接性器、Π HMI 和Π 传感器。每个节点代表一个物理上独立的 ECU，节点之间的所有通信都通过 SOME/IP 进行。描述了分布在这些节点上的许多自适应 AUTOSAR 应用程序。对系统重要的其他车载网络或无线电通信的接口显示为抽象云。

SOME/IP 协议旨在为车辆内基于 IP 的通信定义统一的中间件。该协议基于现有的 TCP/UDP 堆栈，因此通过创建局部透明性为应用程序之间的通信创建了更高级别的抽象。该属性表示应用程序不需要知道哪个网络节点提供了所需的功能或寻求的信息。如果这是在同一个 ECU 上，则通过本地通信通道（例如共享内存、进程间通信、管理程序接口）提供信息。另一方面，如果信息在另一个（已知）网络节点上可用，则中间件执行必要的网络通信，然后将数据传输到应用程序。

SOA服务中如何使用SOME/IP

根据面向服务的范式，所谓的服务构成了 SOME/IP 协议的中心元素。服务被定义为以下各项的逻辑组合提供给其他服务的方法Method、数据字段Field和事件Event。Event事件表示服务状态的抽象变化，并允许有效实现类似于 CAN 协议的面向信号的通信。

例如，可以通过相应字段Field的通知方法来定义何时触发此类事件。一个服务Service的一个或多个事件可以组合成一个所谓的事件组。客户端订阅一个服务中的一个或多个事件组以接收订阅组中包含的事件通知。使用多播可以有效地传递事件实施，订阅客户的数量应该增加。

SOME/IP 支持三种基本版本的 Notifier 方法。最简单的形式 Update-on-Change 会在相应字段的值发生更改时立即发送通知。如果只有显着的值更改会触发事件，则可以配置所谓的ε更改通知器。为此，为该字段定义了一个 ε 值。一旦发送的最后一个值的变化超过定义的 ϵ，就会触发通知。第三个选项是 Cyclecic 更新。为此，字段Field的当前值会以指定的时间间隔发送，而不管值可能发生变化。

辅助驾驶中的SOA服务通信原理

在下文中，如上示例架构被扩展为包括合适的应用程序（由它们的服务、事件组和方法表示）。它们具有许多相互依赖关系，可用于阐明协议的工作原理。

下图显示了 ECU 级别的依赖关系。

从上图所表示，基础的连接架构上看，主要包括如下几个模块：

ADAS/ADS，此应用程序代表驾驶员辅助系统/自动驾驶系统的集合。该服务包括许多配置方法（config）和一个事件组（警告），在识别出的危险事件中发送警告消息。为了提供这些功能，ADAS/ADS应用程序需要大量传感器数据，这些数据由事件组（SensorData 和 CANread）提供。

adSensor，此服务捆绑了许多高级传感器，并通过 sensorData 事件组EventGroup将它们的数据提供给其他服务。除了纯粹的被动传感器操作外，C2X 系统尤其还允许传输消息，例如警告后面的车辆交通拥堵或紧急制动。该服务为此功能提供传输方法。

如果检测到的危险超过阈值，应用程序也会独立做出反应以防止事故发生（例如通过启动紧急制动）。为此，ADAS 应用程序必须能够触发某些 CAN 消息，这可以使用 CANwrite 方法实现。此外，可能需要通过无线电接口（例如 C2X）传输警告消息，这就是为什么还需要 adSensor 服务的传输方法的原因。

Bridge网桥，网关服务提供基于以太网的 SOME/IP 网络和 CAN 总线之间的接口，以实现基本的车辆功能。CANread 事件组将某些 CAN 消息作为事件提供，而 CANwrite 方法允许对 CAN 总线进行受控写访问。

IProxy代理服务器，网关还提供了使用车辆手机接口访问互联网的代理服务。使用服务可以使用 iRequest 方法注册并接收必要的访问信息作为响应。

Multimedia多媒体，该服务使用 iRequest 方法允许多媒体应用程序（例如导航系统或在线搜索请求）访问 Internet。此外，这会访问来自 adSensor 服务的某些传感器数据。这是必要的，例如，显示倒车摄像头的视频流或根据行驶速度自动调整播放音量。

Settings设置，这是一个控制界面，将驱动程序所做的各种设置转发给系统。为此需要受影响服务的相应设置方法，例如 config 和特殊的 CANwrite 方法。

Dashboard仪表板，此服务在车辆驾驶舱中以易于访问的形式显示所有重要的车辆信息和警告。为此，该服务需要大量的信息源，特别是事件组警告、sensorData 和 CANread 是令人感兴趣的。

Blackbox黑匣子，从本质上讲，黑匣子服务是内部通信的纯粹被动观察者，它收集数据以在发生事故时进行后续诊断或用于诊断目的。为此，该服务订阅系统中的所有事件组，并提供 logMe 方法。其他服务可以调用此方法来启用从他们自己的服务传输的所有消息的日志记录。例如，对于允许（部分）自动驾驶的服务来说，这很有趣。如果发生事故，整个记录的通信可以提供有关事故原因的信息。例如，可以使用 iRequest 方法的 Internet 连接将诊断数据从服务传输（匿名）到制造商。

一组示例性 SOME/IP 服务及其依赖关系的概述，SOME/IP 标准定义了四个中心通信概念。

RPC 远程过程调用，分为 Fire&Forget 和 Request-Response。在第一个变体中，客户端调用服务器提供的方法，但不期望返回值。Fire&Forget 请求因此特别适用于控制命令。请求-响应变体是远程方法调用的经典形式，调用客户端会收到包含返回码和包含任何返回值。

Field字段，客户端可以使用 get 或 set 方法读取和更改服务的数据字段。此外，每个字段都可以有一个 Notifier 方法，将字段的当前值传输给感兴趣的客户端。

Publish-Subscrib发布-订阅，一项服务可以提供一个或多个事件组，感兴趣的客户可以订阅这些事件组。一旦属于事件组的字段的状态以定义的方式发生变化，服务就会向所有订阅客户端发送一个带有新状态的通知帧（事件），这种机制允许有效地实现面向信号的通信。

SOA服务具有系统内唯一的 16 位服务 ID。与服务的IP地址和端口一起，可以清楚地识别服务。功能相同的服务的多个实例是有可能的，并且由 16 位服务实例 ID 唯一标识，保留实例 ID 0xFFFF 允许对所有实例进行寻址。为了使 SOME/IP 帧头尽可能小，仅在其中指定服务 ID。服务实例 ID 仅在 SOME/IP 服务发现期间使用。因此，位于同一 ECU 上的两个服务实例不得在同一TCP/UDP 端口上接收和发送，以防止错误寻址。服务提供的每个方法和事件通知也有一个 16 位的方法 ID，它唯一地标识服务上下文中的方法。按照惯例，最高有效位 (MSB) 是事件的“1”和方法的“0”。另一方面，事件组具有在整个系统中唯一的 16 位 ID。服务 ID 和方法 ID 的串联唯一标识了 SOME/IP 消息的接收者，因此称为消息 ID。消息 ID（连同 IP 地址和端口号）足以将消息发送到正确的服务器。

ADAS/ADS系统中的服务发现

客户端和服务器之间需要某种形式的会话处理来区分不同的客户端请求。SOME/IP 提供了请求 ID 的使用，它由两个 16 位字段客户端 ID 和会话 ID 组成。客户端 ID 此标识符唯一地指定 ECU 内的客户端应用程序。ID 到应用程序的分配可以由 ECU 自由管理。会话 ID 在最简单的情况下，此标识符是一个简单的计数器，它随着来自客户端的每个新请求而递增，以区分每个先前的请求。SOME/IP 标准规定，对于从客户端到服务器的第一条消息，会话 ID 的值为 0x01假设会话处理对于带有响应的 RPC 是强制性的，对于“Fire&Forget” 的远距离进程通信RPC 和Event事件是可选的。

SOME/IP 中间件的先决条件是了解所提供的服务、它们在智驾系统中的当前状态和位置。对于这个中心任务，SOME/IP 定义了服务发现 (SD) 协议。服务是使用 ECU（比如高阶域控制器HPC） 的 SOME/IP-SD 进程发现的，并分为本地（针对在同一HPC上运行的所有服务）和系统范围（针对网络内 ECU （如座舱域控制器CSC、底盘域控制器VDC、车身域控制器PDC）上可用的服务）提供发现服务的能力。一旦 ECU 完成本地服务发现，它就会将组合的 SOME/IP-SD 消息作为 IP 多播发送到所有其他 ECU。这样的消息包含一个或多个 offerService 和 findService 子消息。offerService 消息描述了 ECU 的本地服务（比如雷达/摄像头探测目标的服务Objects）及其所有相关选项（如需要该传感器发送的具体哪个目标信息）。此类消息的所有接收者都可以使用 SOME/IP 以这种方式提供的服务。如果本地无法解决服务的依赖关系，则发送相应的 findService 消息。读取此类部分消息的接收者然后检查其本地服务是否匹配。如果找到，则接收者回复另一条 SOME/IP-SD 消息，其中包含所寻求服务的 offerService 条目。

下图显示了一个示例服务发现的过程。

系统启动均发生在 SOME/IP-SD 进程启动后，它会经历三个阶段：初始等待、重复和进入主程序。

Initial Wait初始等待 系统启动后，进程在实际服务发现开始之前进入等待阶段。此等待期用于完成本地服务发现，也使慢速系统能够启动，然后参与 SOME/IP-SD 协议。在最好的情况下，网络中的所有 SOME/IP-SD 进程都已准备就绪，并且每个 ECU 交换单个 SOME/IP-SD 消息集（Message Set）就足以发现网络中的所有服务。

Repetition重复多播 等待阶段结束后，SOME/IP-SD 进程开始通过 IP 多播将组合消息发送到预先配置的多播地址（参见上面子图 a），且这个过程会定期重复。该阶段的间隔和总长度是系统参数，可以任意选择。这些参数的典型选择是例如总持续时间为 40 毫秒，间隔长度为 10 毫秒。

Main主程序 重复阶段之后是主阶段，一直持续到 ECU 运行时间结束。在此阶段，如果发现至少一个本地服务对应于请求中的条目，SD 进程将响应传入的 findService 请求（请参阅c 和d 图）。此外，可以定期发送 SOME/IP-SD 消息的循环更新，例如更新所提供服务的有效时间、生存时间及延迟时间等。

要创建 SOME/IP-SD 消息，该过程必须具有有关在 ECU 本地运行的所有服务的准确信息。创建消息的 offerService 和 findService 条目需要充分掌握SOME/IP 标准信息定义。

总结

SOME/IP 可以看作是一种基于对象的面向服务的体系结构。信息通过实例化服务对象提供给系统，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例实例化相应的“代理”对象。客户端应用程序通过将代理对象附加到服务对象，并使用它来监视事件Event和字段Field，从而得以有效的订阅信息。他们还可以调用服务对象上的操作来执行远程过程调用RPC或读/写特定字段。

SOME/IP特别注重协议的可扩展性，使低性能ECU和功能强大的ECU都可以使用相同的协议进行通信，为了实现可扩展性，SOME/IP的几个可互操作版本是可能的。对于最小版本，整个 SOME/IP-SD 协议可以被一个静态配置文件替换，其中包含所有必要的信息。另外，可以省略 TCP 的实现。为了与更复杂的实现互操作，只需需要 SOME/IP 序列化，并且需要支持之前介绍的通信类型即可。