车载以太网 - SOME/IP简介
SOME/IP (Scalable service-Oriented MiddlewarE over IP) 是车载以太网通信引入的一个概念，位于OSI 7层模型的层4(传输层)之上。
- 在以CAN总线为主的车载网络中，通信过程是面向信号的（除了诊断通信之外），这是一种根据发送者需求实现的通信过程，当发送者发现信号的值变化了，或者发送周期到了，就会发送信息，而不考虑接收者是否有需求。
- 而SOME/IP则不同，它是在接收方有需求的时候才发送，这种方法的优点在于总线上不会出现过多不必要的数据，从而降低负载。
- 在车载网络中，某个ECU有时会需要调用实现在其他ECU上的个服务，这个时候它俩就分别扮演了client和server的角色，而SOME/IP就是实现这种远程服务调用的接口，如下图所示。
服务的远程调用
SOME/IP数据在以太网报文中的位置
从上面这个图可以看出来，SOME/IP其实是构架在传输层之上的应用层通信协议，它的内容虽然很多很杂，
但本质上也就是定义了SOME/IP 包头和数据的内容而已。
SOME/IP 数据的格式
上图是SOME/IP数据的格式，除了最下面的Payload之外都属于SOME/IP的header，这里面的字段不一一介绍，只提一下Message Type [8 Bit]，它有以下几种取值：
- REQUEST （期待响应的请求）
- REQUEST_NO_RETURN（不期待响应的请求）
- NOTIFICATION（事件通知）
- RESPONSE（响应消息）
- ERROR（报错消息）
REQUEST，REQUEST_NO_RETURN，RESPONSE属于同一类远程过程调用方法，当client有需求的时候，发送一个request消息，server根据这个消息类型（REQUEST或REQUEST_NO_RETURN）来决定是否发送response消息。过程如下图所示。
方法调用过程（图片来源vector网站）
NOTIFICATION属于事件通知类的服务，首先由client向server订阅服务内容，然后server向client自动发布服务内容。
Event Notification（图片来源vector网站）
Field Notification（图片来源vector网站）
NOTIFICATION又分为Event和Field 两类，这两类通知都需要首先使用SOME/IP-SD(Service Discovery)来进行服务订阅，然后才能发布通知。
区别在于，Event是某一时刻的快照，只是事件通知，而Field除了事件通知之外，还具有Getter和Setter的功能，即对信息进行读写的操作。
SOME/IP-Service Discovery
SOME/IP-SD可以被当作SOME/IP的一种特殊服务，前面提到过，client可以远程调用server提供的服务，或者订阅server发布的内容，那么client是怎么知道server提供哪些服务呢，就是通过SOME/IP-SD来实现服务发现过程的。
SOME/IP-SD的报文格式
从上图可见，SOME/IP-SD是一种特殊的SOME/IP格式，它对SOME/IP-SD报文中的Payload进行了定义和实现。而Message ID字段则是固定的0xFF FF 81 00。
SOME/IP-SD提供了两种动态发现服务的机制。
- 一种是Offer Service ，由server向网络上的小伙伴告知它所提供的服务。
- 另一种是Find Service ，由client向别人请求可用的服务。
本文只是简要介绍，不对通信过程和协议内容做过多分析。
如果大家对此部分内容感兴趣，可以参考下面这个网站，http://www.some-ip.com/
这上面有与SOME/IP相关的全部详细信息。
SOME/IP的功能
1、数据的序列化和反序列化
将网络中的对象，比如结构体或者字符串转换成二进制流进行传输的过程。娱乐信息的控制器可以支持8Byte对齐，所有的ECU应至少支持4Byte对齐序列化要求字节对齐，提高CPU的访问效率。
2、RPC远程调用机制
远程调用机制包括以下几种：
- 请求/响应（R/R）通信
客户端发送一条Request消息，该消息由服务端Response。（带返回值的函数调用）
▲ 图3：请求/响应（R/R）通信
- 焚烧 & 忘记（F & F）通信
客户端向服务器调用方法，无需服务器响应消息的请求称为fire＆forget。（空函数调用）
▲ 图4：焚烧&忘记（F/F）通信
- 通知事件（Notification Event）
与CAN报文类似，当客户端订阅Event Group后，当发生某些特定事件时（周期更新、值发生改变或值改变了ε），服务器就会给客户端发送Event报文。（应用数据转换）
▲ 图5：Notification Event通信
- 域（Field）
Field是Getter、Setter和Notifier的组合。Getter是一个请求/回应调用，请求报文的payload为空，Field的值置于响应报文的payload中。同样Setter也是一个请求/回应调用，将要设置的Field的值置于请求报文的payload中，响应报文的payload也要放置Field设置的值。Notifier同Event类似，Field中的事件报文在Field值更新时会发送出来，但遵循事件发送规则。
▲ 图6：Notification Event通信
AP AUTOSAR
1、ara::com---通讯管理接口
其可实现应用之间的函数调用和事件发送
服务请求：双向数据流，即发送请求者会收到服务端的反馈，可支持多对1的服务请求，即单个服务可被不同客户端调用，客户端可串行或并行进行反馈，具体流程如下：
事件发送：由客户端发起，单向数据流。即数据只可从服务端向客户端流动，支持单个服务向多个客户端的事件发送，流程如下：
3、管理整个网络中服务的状态
- 通信机制
SOME/IP通过以太网提供面向服务的通讯，采用SOME/IP-Service Discovery定位服务实例，并检测服务的运行状态，同时发布订阅处理功能。
▲ 图7：Service Discovery的作用
客户端收到需要的服务，会发送订阅报文，服务端给出订阅ACK后，开始发送Event。所有需要Event或NotificationEvent的客户端必须在运行时间中利用SOME/IP-SD在某个server上注册。
▲ 图8：订阅与Event发送（源自SOME/IP Service Discovery ProtocolSpecification）
1.服务发现通信行为
对每一个服务实例或事件组，服务发现在发送条目时必须至少包含初始等待阶段、重复阶段和主阶段。
2.初始等待阶段
随机等待一段时间后发送报文（发现服务和提供服务条目）。
3.重复阶段
服务发现实现时必须在重复阶段等待一段时间，且发送的条目数量有限制。如果发送的条目数量设置为0，则必须跳过重复阶段。在初始等待阶段之后服务实例进入主阶段。
4.主阶段
在进入主阶段之后，必须等待一段时间后发送第一条报文，循环发送提供服务报文。
当某ECU的服务实例停止服务时，必须发送停止提供服务条目。服务端的状态机如下图所示：
▲ 图9：服务端的状态机（源自SOME/IP Service Discovery Protocol Specification）
客户端在Down阶段如收到提供服务条目，可内部调用服务请求；如未收到提供服务条目，则进入初始等待阶段等待一段时间后进入重复阶段发送报文，接收到提供服务条目，进入主阶段。当收到服务实例停止服务时，服务停止，仍停留在主阶段。客户端的状态机如下图所示：
▲ 图10：客户端的状态机（源自SOME/IP Service Discovery Protocol Specification）
SOME/IP与AUTOSAR
在AUTOSAR架构中，SOME/IP-SD模块位于AUTOSAR BSW Mode Manager module（BswM）和AUTOSAR Socket Adaptor module (SoAd)之间，如图11所示。BswM模块提供了通用模式请求和服务请求之间的连接。SoAd模块则处理以太网堆栈和Sd模块之间的服务请求。通过配置SoAd中的SocketConnection表，可以接收其他ECU的Sd模块发来的单播和多播报文。
▲ 图11：AUTOSAR SOME/IP-SD模块交互（源自Specification of Service Discovery）