https://blog.csdn.net/Aliven888/article/details/123333466之前系列文章中提到，关于自适应 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 位Service ID。与服务的IP地址和端口一起，可以清楚地识别服务。
功能相同的服务的多个实例是有可能的，并且由 16 位(ServiceInstanceID)服务实例 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 序列化，并且需要支持之前介绍的通信类型即可。
https://mp.weixin.qq.com/s/tc7LDnMmlNP-5CBFh0Ivpg基于SOME/ IP可扩展面向服务的中间件
事件驱动的 SOA：事件与服务相遇
PDU 路由组管理需要管理启用到禁用的套接字PDU 路由，SOME/IP - 套接字适配器 [SoAD] - AUTOSAR 模型构建块，可用于通用上层支持SOME/IP中的服务发现。
SOME/IP SD报文也是一种SOME/IP的数据报文，是在SOME/IP数据报文的前提上进行了扩展需求，增加了Entry、Option等字段；
Entries 用于同步服务实例的状态和发布/订阅的管理
Options 用于传输Entries的附加信息
Type = 0x00 encodes “FindService”
Type = 0x01 encodes “OfferService” And“StopOfferService”
Type = 0x06 encodes “SubscribeEventGroup”And “StopSubscribeEventGroup”
Type = 0x07 encodes“SubscribeEventGroupAck” And “StopSubscribeEventGroupNack”
Type = 0x02, 0x03, 0x04, 0x05 not defined
SOME/IP SD数据报文的这些属性都是一个固定值。
- ServiceID（0xFFFF）
- MethodID（0x8100）
- Request ID（0x0000）
- ProtocolVersion（0x01）
- Interface Version（0x01）
- MessageType（0x02）
- ReturnCode（0x00）
SOME/IP协议格式
从启用禁用到整个套接字的 PDU 路由，SOME/IP消息由报头header和有效负载Payload组成。
消息ID：服务ID和事件/方法ID的组合
长度Length：包含从请求ID到SOME/IP消息结束的长度（以字节为单位）
请求ID：允许提供者和订阅者区分同一方法、事件、getter或setter的多个并行使用
协议版本：包含SOME/IP协议版本的8位字段
接口版本：包含服务接口主要版本的8位字段
消息类型：用于区分消息类型
返回码：用于指示请求是否已成功处理。
AP平台的方法论作为CP平台的扩展，其引入了新的概念，AP平台软件的实例是在进程的上下文中执行。
AP平台引入了“机器”(Machine)的概念，“机器”是虚拟化的ECU一个可以部署软件的实体。
在AUTOSAR架构中，SOME/IP-SD模块位于AUTOSAR BSW Mode Managermodule（BswM）和AUTOSAR SocketAdaptor module (SoAd)之间。
BswM模块提供了通用模式请求和服务请求之间的连接。
SoAd模块则处理以太网堆栈和Sd模块之间的服务请求。通过配置SoAd中的SocketConnection表，可以接收其他ECU的Sd模块发来的单播和多播报文。用于 SOME/IP 的套接字适配器、COM 和 RTE，而SD则拥有自己的模块。
SoAd 层支持通过 TCP/IP 网络进行基于 PDU 的通信。AUTOSAR I-PDU 映射到由 SoAd 配置和维护的套接字连接。要为多个 I-PDU 使用套接字连接，可以在每个 I-PDU 前面添加 SoAd PDU 标头。
SOME/IP的三个原始接口服务
AP平台是一个面向服务的软件架构(SOA)，基于AP平台的软件开发首先需要进行服务接口的设计。服务接口可以由事件(Events)、方法(Methods)和字段(Fields)组成是生成软件组件头文件的基础。
1、方法(Methods)
调用或引用一个进程/函数/子程序，通常由Client发起，并由Server答复。Request是最常见的一种Method，由Client向Server请求数据；Response是Request的结果，由Server答复Client的Request。而Method Fire & Forget方式，只Client向Server发起，但Server对该请求不回复。
2、事件(Events)
一个单向的数据传输，只能是on change类型，用于Server主动向订阅（Subscribe）了相关服务的Client发布（Publish）信息。
3、字段(Fields)
由以下三项内容构成：
Notifier：通知，Server的Client订阅了服务后第一时间主动向其发送数据。
Getter：获取，由Client向Server请求数据。
Setter：设置，由Client修改Server的数据。
这里需要注意，NOTIFICATION分为Event和Field 两类，
这两类通知都需要首先使用SOME/IP-SD(Service Discovery)来进行服务订阅，然后才能发布通知。
client可以通过SOME/IP-SD来实现服务发现过程，从而得以远程调用server提供的服务，或者订阅server发布的内容。
区别在于，Event是某一时刻的快照，只是事件通知，而Field除了事件通知之外，还具有Getter和Setter的功能，即对信息进行读写的操作。
高级自动驾驶架构下的SOME/IP的通信机制
如下图显示了一种面向服务中典型的基于SOME/IP进行有效通信的连接架构，就智能驾驶来讲，各ECU端均通过交换机Switch向相关联的端口发送相应的请求端口号及服务内容。
这里我们举一个例子，假如需要实现自车安全停车（Safe Stop）逻辑，同时通过抬头显示单元进行显示。
这里假如车辆控制单元VDC进行车辆前端感知、融合及后端规控，那么整个控制过程则需要首先由自动驾驶域控制器作为客户端，则需要首先由请求端Vehicle Contol通过SOME/IP封装的相应的服务端口及地址。
中央控制器单元通过采用定义三种不服务接口
（其中Event Group包含垂直方向数据，Fields包含障碍物类型数据，Methods包含通知/获取/设置等相关内容信息）
向对应的端口Port(如摄像头端口Port=30501，雷达端口Port=30501，通常传感器使用相同的端口，通过不同的IP地址加以区分)和IP地址（IP=192.168.10.100，IP=192.168.10.101）发起请求传感器检测的目标数据服务Provided ServiceInterface。
传感器作为服务端接收到该请求后，将带有Event Group属性的信息
（比如Distance_Data、Object_Event_Grp_1）
和Fields属性的信息（比如Front_Distance（Notifier_1）、Rear_Distance（Notifier_2）、Object_New_Position、Object_New_Blurred）回传给域控制器。
另一个例子，比如订阅机制中，高精地图Server向外提供高精地图数据（Offer Service），ADAS控制单元想要订阅其车道线相关信息（Subscribe EventGroup），高精地图Server同意其订阅请求（Subscribe EventGroup Ack），而后Server开始发布高精地图的车道线数据给ADAS控制单元。
再如，请求与响应机制，HU想要获取DVR内存信息，此时DVR是Server，HU是Client，由HU向DVR发出request，DVR收到请求后，根据自身当前状态，回复Response。
SOME/IP作为站在以太网顶端的一种优化协议，应用于SOA的服务通信开发实践，有较多值得被关注的点需要说明，如下罗列了一些典型的被人们所关注的SOME/IP相关的问题项，对于帮助工程师建立更加全面的认知可以起到很好的作用。
1. Some/IP协议的Header报头各位数的含义表示什么？SD的数据通信是如何实现的？
Some/Ip协议Header主要包括MessageID（32bit）、Length（32bit）、RequestID（32bit）、ProtocolVersion（8bit）、InterfaceVersion（8bit）、MessageType（8bit）、ReturnCode（8bit）。
MessageID（32bit）＝ ServiceID（16bit）＋ MethodID（16bit）
MessageID用于区分不同的服务和服务接口。
其中分为
ServiceID：16bit，服务的ID，标识出一个服务；
MethodID: 16bit，方法的ID，表示出一个方法；
其中MethodID最高位为0表示的是Event
MethodID最高位为１表示的是Notifier
在Someip中由于可以支持多种不同的数据通信，因此可以通过MethodID的最高位来判断具体的通信方式；
Length：报文长度，32bit，标识从request ID到报文结束的总长度；
Protocol Version ：协议的版本号，固定值为x01;
Interface Version：服务接口版本；
Message Type ：报文类型，在AUTOSAR中，总共包含五种，包括REQUEST，REQUEST_NO_RETURN，NOTIFICATION，RESPONSE，ERROR；
Return Code ：返回码，包括四种，REQUEST，REQUEST_NO_RETURN，NOTIFICATION，RESPONSE；
Payload ：数据段，用于放置需要传输的数据。
RequestID（32bit）＝ Client ID（16bit） + Session ID（16bit）
Request ID(Client ID) ：客户端ID，16bit。区分不同的客户端；
Request ID(Session ID) ：会话ID，区分同一个客户端的多次调用；
对于特定的Header，SD明确定义MessageID固定为0xFFFFF8100；
MessgeType固定为0x02。
Length（32bit）表示RequestID至Payload的字节长度；
长度字段描述了 SOME/IP 消息的总长度。这是特别必要的，因为可以将多个 SOME/IP 消息连接到同一个收件人以提高传输速率。
接收器可以通过将标头中指定的长度与帧的实际长度进行比较来区分这些。如果这大于指定的值，则会出现另一个 SOME/IP 帧。SOME/IP 有效负载Playload的长度受到底层传输协议（UDP 或 TCP）和以太网分段的限制，应避免这种情况。
RequestID（32bit）＝ Client ID（16bit） + Session ID（16bit）
RequestID（32bit）用来响应特定的数据请求和发送，主要包括ClientID用来区分特定的车载ECU的客户端，因此，对于ClientID来说在整车系统中该值必须是唯一的；
SessionID（初始值设置为0x0001）主要用于Request和Response类型的通信协议多次调用，每调用一次，SessionID增加1，在其他类型的数据通信中可以根据需要进行选择性使用；
SomeIP用ProtocolVersion表明协议版本类型；
ReturnCode则主要用来知名通信中的相关错误信息。
对于Some/IP所定义的服务接口来说，一般是采用跨系统通信的重要组成，并且参照自己特有的一套序列化原则，系统设计阶段需要基于Some/IP提供的数据类型，统一设计服务接口描述。
对于SD的数据通信一般分为发现服务、订阅事件组、接收事件，其中发现服务和订阅事件组需要SD完成，接收或通知事件由SomeIP直接完成。
对于SD模块中，需要定义对应节点是作为Client还是Server端使用，在SD中主要的配置选项包含SD基础配置、SD服务端配置、SD客户端配置。
可参照如下图进行：
2. Method/Event/Field/Eventgroups都是用的Provider和Consumer接口吗？相互之间的工作机制区别有哪些？
Method方法：有响应（请求/响应）和无响应（Fire&Forget）。
Event事件：发生某事时从服务器到客户端的消息。
Fields字段：属性/状态的获取器/设置器/通知器。
Eventgroups事件组：用于发布/订阅处理的事件和字段的逻辑组。
对于每个SOA来说，至少得有一个Provider和若干个Consumer接口，一个服务接口需要满足SOME/IP协议的组成规则，里面包含Method/Event/Field三部分。
因此，可以说以上三部分内容都是采用的Provider和Consumer接口。
比如以雷达所表示的一个通信接口举例说明相应的接口描述。
其中，服务接口Fields可主要用于提供雷达的刷新频率UpdateRate（Unit32）
Events可主要用于当检测到雷达目标后，提供制动时间或停车事件BrakeEvent（RadarObjects）和parkingBrakeEvent（RadarObjects）
Methods可主要用于数据矫正Adjust和标定Calibrate。
其中数据矫正包括位置目标输入，是否矫正成功的标志输出，位置有效性输出。
标定则是包括相关的数据配置，标定结果标志位输出。
下面来具体说明下如上服务接口的定义方式区别和通信机制。比如Event和Field两者就存在如下区别：
Event仅在发生某些事情时发生，事件没有初始值，未定义事件的生命周期。基于状态的元素应建模为字段，Event 和 Field 的事件消息是相同的，区别在于初始事件仅存在于字段。通常将事件用于时间有限的观察，将字段用于状态等数据。
3. SOA在一定程度上就是SOME/IP的基础实现么？基于SOMEIP的SOA中sender/receiver接口类型是怎样定义的？
SOA实现重点在于服务通信标准化，即面向服务的通信（SOC,Service-Oriented Communication）。
并以服务重用、灵活重用为目的进行服务划分，即基于服务的服用共享式进行设计（SORS，Service-Oriented Reuse-Shared Design）。
用于承载和适配SOC和SORS的软件实现是基于服务的软件架构（SOS，Service-Oriented Software Architecture）。所以，整体来说简单的将SOA简单的等效为SOME/IP是不合理的。
但是，SOA作为一种面向服务的架构标准，可以将其与SOME/IP基础协议所定义的内容进行实现，SOME/IP 则允许SOA中的应用程序进行通信，数据包格式由服务规范自动确定。所以可以说SOA的服务架构是SOME/IP实现有效通信的载体。SOME/IP在包括涉及系统、软件、硬件的架构所定义的软硬件模块中发挥具体作用。
服务器提供实现服务接口的实例化
客户使用 SOME/IP的服务实例化。
SOME/IP位于应用层，提供面向服务的通信接口。其通信方式为AUTOSAR中提到的CS接口的概念，就是客户端(client)和服务端(Server)，当有请求发出时，SOME/IP才会发出数据，否则不发送数据，类似于COM模块的Direct模式，这样总线上就没有不必要的数据，降低总线负载。
4. SOA中服务仲裁有何价值？多个消费方消费同一个service时，怎么做仲裁，仲裁逻辑怎么设计？
仲裁能力是任何 SOA 的关键益处之一。
仲裁并不是所有服务都必须的，但是“它是被设计交付可组合性（即业务敏捷性）的面向服务架构所必需的。几乎所有有价值的长运行事务都必须能够仲裁，这是为了让它们可以被组合、被再组合，以及被编排，共享消息的语义需要依赖仲裁功能。
仲裁要求并鼓励消息携带更多的上下文信息，除了请求 - 响应和发布 - 订阅，仲裁使消息交换模式极大地复杂化。
多个消费方使用同一个Service时，仲裁过程要求仲裁系统对于它所拦截的消息的语义有较好的理解，根据理解的语义判定消费方对于具体服务的需求紧急度和重要度，从而Server通过Notification推送给Client已订阅的服务内容。
SOME/IP 可以看作是一种基于对象的面向服务的体系结构。信息通过实例化服务对象提供给系统，这些由客户端应用程序访问，客户端应用程序为他们想要访问的每个服务实例化相应的Proxy“代理”对象。被判定为高优先级的客户端应用程序通过将代理对象附加到服务对象并使用它来监视Event事件和Field字段从而获取getter或Setter更改来订阅信息。也可以调用服务对象上的操作来执行远程调用或读/写特定字段。
5. v-SOA中instance和machine什么关系？AP 里面的每个子模块的设计实现都是用采用SOA设计思想吗？
从外看，我们可以将机器Machine看作一个抽象的硬件+软件平台和通讯接口。
硬件包括一个N核CPU，软件平台可以定义为具体OS。
每个Machine可以有N个进程，每个进程都会对应可执行文件。
对于服务实例ServiceInstance来说，主要定义SOA通讯怎么映射和部署到transport传输层协议（如SomeIp）。即定义一个服务是提供方还是消费方，服务提供的具体功能，服务具体类型，服务接口，服务实例ID等内容。最终实际的将服务实例映射到目标硬件层面，可以说这个硬件层面就是由Machine配置的虚拟机软件承接。
如上图所示基于SOA的Autosar相应的开发流程如下：
1）首先是定义服务：输出ServiceInterface，这个过程一般属于OEM工作范围，通常由OEM定义相应的ARXML接口文件实现；
2）生成Machine Manifest用来描述目标硬件和软件平台环境，并使用Autosar工具链将应用映射到进程Process;
3）使用Autosar供应商工具链，生成基于Skeleton/Proxy的类，其中proxy(代理)是skeleton(server端)的对外接口;
4）实现SWC和使用目标软件平台工具链在可执行环境中将对应的目标文件编译为可执行文件Executables；
与SOA有着强绑定关系的Autosar来说，其开发过程往往离不开整个服务接口定义、服务通信定义，以及实现整个Autosar的各类中间件。
对于v-对于SOA来说，SOC可以实现通信标准化，动态建立通信关系，连接信息孤岛。
SOME/IP就是基于SOA思想定义的通信中间件，也是对车载环境定义的一套通信协议，出自AP Autosar，可以达到屏蔽系统异构性，实现互操作的目的。
所以，就AP的每个子模块中实现SOC而言，可以完全依赖于SOME/IP，采用SOA设计思想来完成（当然，针对不同的前提条件，其他传输协议如DDS也可以使用来作为通信协议端）。
但是，在AP Autosar的开发架构下用于 SOME/IP 的套接字适配器、COM 和 RTE、服务发现所定义的单独的模块，这些过程实现也是具备极大的挑战性的。
这里需要注意的是Client ≠ AUTOSAR Client/Server。
6、DDS和someip在arxml建模的区别？
SOME/IP 是一种汽车中间件解决方案，可用于控制消息。SOME/IP 专为汽车行业设计。SOME/IP 是作为 AUTOSAR 的一部分开发的规范集合，描述了其序列化协议、服务发现以及与 Classic AUTOSAR 集成的转换器。
DDS（数据分发服务） 也是用于通信的汽车中间件，针对更广泛的工业物联网领域。它是由对象管理组 (OMG) 发布的一系列开放标准。SOME/IP 和 DDS 都允许分布式应用程序使用发布/订阅模式和服务请求/回复模式 (RPC) 进行通信。但也存在如下显着差异：
1）通信模式不同
DDS 和 SOME/IP 之间的一个显着区别在于，使用 DDS，应用程序不需要绑定到服务的特定实现。它简单地引用主题和服务，并且可以完全透明地进行一对一或一对多的通信，而无需对应用程序代码进行任何更改。它确实需要跟踪单独对等点的存在或管理任何新对象以响应对等点的加入或离开。这一切都是自动处理的。从这个意义上说，它比 SOME/IP 更具动态性。
2）应用程序编程接口（API）
SOME/IP 没有定义标准 API，实现通常提供 C++ API，但它们不能跨实现移植。
DDS 具有适用于多种语言的标准 API。对于 C++ 和 Java，这些都包含在 DDS-PSM-JAVA 和 DDS-PSM-CXX 规范中。因此，通常可以移植 DDS 应用程序并在 DDS 实现之间切换。
3）网络传输
SOME/IP 支持 UDP 和 TCP 进行数据传输。对于可靠的通信，SOME/IP 回退到 TCP。使用 DDS支持RTPS（实时发布订阅）的有线协议，实现了与传输无关的可靠性和分段协议，该协议运行在任何传输之上，包括带有多播的 UDP。可以通过多播 UDP 处理大数据和可靠数据。Some/IP 无法做到这一点。
此外，许多 DDS 实现提供了“自定义传输”SDK，因此可以在您自己的自定义传输上运行 DDS，而不会牺牲任何功能和 QoS。这对于 SOME/IP 是不可能的，因为某些特性（如可靠性和分段）必须由传输实现。
4）信息安全能力不同
一般来说，SOME/IP 也依赖于传输来保证安全。因此，要安全地使用它，就需要在 TLS 或 DTLS 上运行。对于 DDS，最好使用 DDS 安全规范中定义的机制，这些机制与传输无关。DDS 安全性还提供了对安全性的更细粒度的控制以及用于访问控制的语言，因此可以分别保护 DDS 域和主题，并区分对主题的读取和写入权限。此外，由于 DDS 安全性与传输无关，因此它可以与任何传输一起使用，包括共享内存、多播或自定义应用程序定义的传输。
5）服务质量实现不同
SOME/IP 仅提供一种用于选择 UDP 与 TCP 的“可靠性”Qos 设置。DDS 提供了许多 QoS 策略，使用户能够以声明方式指定发布者和订阅者之间如何交换信息。我们开发SOA的服务架构中，通常dds通常重点在于传输数据类通信（比如传感器数据），SOMEIP更多是传输控制类信号通信（如加减速控制信号、车门车窗控制信号）。
总结
本文就基于SomeIp协议开发过程中可能出现的典型问题进行了比较详细的分析和解读，可以帮助读者或工程实践者进行部分问题规避，但是SomeIp协议的复杂度和可能出现的踩坑远不止于此，比如由于当前的 SOME/IP 协议不提供任何安全措施，如何提升Someip的信息安全能力，免受黑客攻击，就是业内比较关注的话题。协议制定过程中如果能够保留56 字节用户数据明确用于可能的安全扩展。只要安全协议每帧传输的附加数据不超过这 56 个字节，就可以在不更改标准和兼容实现的情况下保护 SOME/IP 通信。这一系列操作都有助于对Someip的能力扩展，当然这里无法穷举，希望后续可以通过抛砖引玉的方式在后续开发过程中获得更多的输入。
1685
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
