车载以太网协议栈总共可划分为五层，分别为物理层，数据链路层，网络层，传输层，应用层，其中今天所要介绍的内容SOME/IP就是一种应用层协议。
SOME/IP协议内容按照AUTOSAR中的描述，我们可以更进一步的拆分为三类子协议：应用层的SOME/IP标准协议，SOME/IP-SD协议以及TP层的SOME/IP-TP协议。
SOME/IP协议特点
| 特点 | 描述 |
| Serialization(序列化) | 在ECU内部进行序列化及反序列化以实现信息的高效传输 |
| Remote Procedure Calls(远程调用) | 该协议可以传递消息(作为字段发送)以及方法的远程调用(实现过程/函数调用) |
| Service Discovery(服务发现) | SOME/IP协议的数据通信发生在客户端-服务器模型中,同时服务器提供客户端可以订阅的许多不同服务。该协议允许客户端动态查找服务、订阅服务并配置对服务的访问。 |
| Publish/Subscribe(发布与订阅) | SOME/IP中的数据通信通过发布/订阅进行。客户端可以订阅服务器提供的服务,服务器可以向活跃的订阅者发布通知。 |
| Segementation of UDP message | 每当服务器必须向活动订阅者发送通知时，他们是通过UDP协议发送的。SOME/IP能够在不需要任何分段的情况下传送大型UDP消息。 |
SOME/IP协议解析
如果应用了 E2E 通信保护，则 E2E 报头将放置在 Return Code 之后，具体取决于为 E2E 报头选择的偏移值。默认偏移值为 64 位，这将 E2E 报头恰好放置在 Return Code 和 Payload 之间。
SOME/IP协议Header包含Message ID，Request ID, Protocal Version 以及Interface Version。
各字段解释如下：
| Item | Description |
| Message ID | 前2个字节为Service ID，后2个字节为Method ID（每个服务仅定义一个唯一的Service ID，Method ID的最高位为0即为方法（包括Method Filed.Getter及Filed.Setter），最高位为1就为事件（包括Event和Filed.Notify）） |
| Length | 标识从Request ID开始至SOME/IP报文结束的长度 |
| Request ID | 前2个字节为Client ID，用来识别一个客户端；后2个字节为Session ID，用来识别同一个客户端的多次请求。（其中Client ID可通过配置前缀或者固定值来实现唯一性，可不进行Session处理，如果需要，则Session ID需根据各自的用例从0x0001递增） |
| Protocol Version | 协议版本号，目前固定为1 |
| Interface Version | 用来识别服务接口的主版本号，由用户定义 |
| Message Type | 用来识别不同的消息类型，Message Type（8Bits）的Bit5标识TP-Flag，当TP-Flag=1时，标识一个TP类型的Message Type (当SOME/IP下层通信协议为UDP，且SOME/IP传输大数据（>1452Bytes）时，将使用SomeIpTp进行分段） |
| Return Code | 用来指示Message是否被成功处理了，或针对请求中的错误内容进行反馈 |
| E2E Header | 可选是否使能，并且可变长度（默认长度是8Bytes），可选使用一种E2E profile（常用E2E Profile4） |
| Payload | 有效载荷，序列化和反序列化定义了 PDU 中所有数据结构的确切位置，并且考虑了内存对齐 |
Message Type
用来识别不同的消息类型，目前存在的类型如下所示，其中TP表示分包的报文,按照AUTOSAR标准(R21-11)定义如下：
| ID | Name | Description |
| 0x00 | REQUEST | A request expecting a response 请求并期待响应 |
| 0x01 | REQUEST_NO_RETURN | A fire&forget request 请求但不期待响应 |
| 0x02 | NOTIFICATION | A request for a notification expecting no response 通知/事件回调的请求，不期待有响应 |
| 0x40 | REQUEST_ACK | Acknowledgment for REQUEST (optional) REQUEST的ACK确认 |
| 0x41 | REQUEST_NO_RETURN_ACK | Acknowledgment for REQUEST_NO_RETURN (informational) REQUEST_NO_RETURN的ACK确认 |
| 0x42 | NOTIFICATION_ACK | Acknowledgment for NOTIFICATION (informational) NOTIFICATION的ACK确认 |
| 0x80 | RESPONSE | The response message 响应 |
| 0x81 | ERROR | The response containing an error 响应中包含的错误 |
| 0x20 | TP_REQUEST | TP segment of a Request Message for methods TP请求并期待响应 |
| 0x21 | TP_REQUEST_NO_RETURN | TP segment of a Request Message for Fire & Forget methods TP请求但不期待响应 |
| 0x22 | TP_NOTIFICATION | TP segment of an Event (Notification) Message TP通知/事件回调的请求，不期待有响应 |
| 0xA0 | TP_RESPONSE | TP segment of a Response Message for methods TP响应 |
| 0xA1 | TP_ERROR | TP segment of an Error Message for methods TP响应中包含的错误 |
Return Code
用来指示Message是否被成功处理了，或针对请求中的错误内容进行反馈，如下为AUTOSAR(R21-11)中定义的Return Code类型：
| ID | Name | Description |
| 0x00 | E_OK | 没有错误发生 |
| 0x01 | E_NOT_OK | 发生了未定义的错误 |
| 0x02 | SOMEIPXF_E_UNKNOWN_SERVICE | 未知的服务ID |
| 0x03 | SOMEIPXF_E_UNKNOWN_METHOD | 未知的Method ID |
| 0x04 | SOMEIPXF_E_NOT_READY | 应用程序未就绪 |
| 0x05 | SOMEIPXF_E_NOT_REACHABLE | 运行该服务的系统不可用 |
| 0x06 | SOMEIPXF_E_TIMEOUT | 发生超时 |
| 0x07 | SOMEIPXF_E_WRONG_PROTOCOL_VERSION | SOME/IP协议版本不支持 |
| 0x08 | SOMEIPXF_E_WRONG_INTERFACE_VERSION | 接口版本不匹配 |
| 0x09 | SOMEIPXF_E_MALFORMED_MESSAGE | 反序列化错误 |
| 0x0A | SOMEIPXF_E_WRONG_MESSAGE_TYPE | 接收到不符合预期的消息类型 |
| 0x0B | E_E2E_REPEATED | E2E重复错误 |
| 0x0C | E_E2E_WRONG_SEQUENCE | E2E错误的时序 |
| 0x0D | E_E2E | 没有进一步的E2E错误 |
| 0x0E | E_E2E_NOT_AVAILABLE | E2E不可用 |
| 0x0F | E_E2E_NO_NEW_DATA | 没有E2E计算的新数据 |
| 0x10-0x1F | RESERVED | 预留给到SOME/IP一般性错误 |
| 0x20-0x5E | RESERVED | 预留给到服务及方法的特定错误 |
Payload的序列化与反序列化
SOME/IP报文收发的过程中，上层应用所定义的Method、Event、Field参数都是面向用户的struct，string等，序列化就是将这些输出参数转换为字节流的过程；而反序列化的过程正好相反，就是将字节流反向解析成struct、string等具体的参数。
大小端：
SOME/IP报文的payload(负载)大小端(字节序)指的是数据在内存中的存储和传输顺序。在计算机系统中,数据的存储和传输顺序主要有两种标准:大端字节序(Big-Endian)和小端字节序(Little-Endian)。
-大端字节序(Big-Endian):是指数据的高位字节存放在低地址处,而低位字节存放在高地址处。也就是说,从内存的起始位置开始,第一个字节是最高位字节。
-小端字节序(Little-Endian):是指数据的低位字节存放在低地址处,而高位字节存放在高地址处。在这个模式下,内存起始位置存放的是最低位字节。
SOME/IP报文的payload部分可以采用上述两种字节序中的任何一种,这取决于数据交换双方的协议约定或者通信端点的实现。在网格协议中,端字节序通常由协议规范明确指出。开发者在处理SOME/IPP报文时,必须确保发送方和接收方在端字节序上保持一致,以避免数据解析错误。
SOME/IP通信机制
服务发现(Service Discovery)
服务发现的通信机制是通过SOME/IP-SD协议实现的，主要是为了实现在车载以太网中告知客户端当前服务实例的可用性及访问方式，可通过Find Service 和Offer Service来实现。
SOME/IP 服务发现流程可以分为以下三大基本步骤：
Client通过发送Find Service的报文去寻找车载网络中可用的服务实例；
Server接收到Client的Find Server后通过UDP发送Offer Service响应；
Client通过发送Subcribe Event Group去订阅相关Event；
Server检查是否满足Client是否满足订阅条件，如果满足回复ACK，如果不满足，则回复NACK；
Client成功订阅相关事件后，Server会按照事件本身属性来实现对已订阅该事件的Client的发布；
远程进程调用(RPC)
远程进程调用主要可分为四种通信模式：
Request/Response通信模式
可归纳为Method中的一种；其基本通信模型如下图所示：
Request-Response模型作为一种最为常见的通信方式，其主要任务就是客户端发送请求信息，服务端接收到请求，进行相关处理之后进行相应的响应。
Fire&Forget通信模式
可归纳为Method中的一种；
该通信模型的主要任务就是客户端向服务端发送请求，服务端无需进行任何响应，有点类似诊断服务中的抑制正响应。
Notification Event通信模式
该通信模式主要描述了发布 /订阅消息内容，主要任务就是为了实现客户端向服务端订阅相关的事件组，当服务端的事件组发生或者值发生变化时，就需要向已订阅该事件组的客户端发布更新的内容。
远程进程控制(Field)
访问进程通信机制主要是为了实现针对对应用程序的数据获取与更改，主要任务就是实现客户端通过Getter获取Server的值，通过Setter设置Server的值。
Field就可理解为一个Service的基本属性，可包含Getter，Setter，Notifier三种方式。其中Getter就是读取Field中某个值的方法，Setter就是一种改变Field值的方法，而Notifier则是一种当Field中的值发生变化的触发事件，发生变化时就通知Client。
错误处理机制
AUTOSAR为了更为高效的定位到通讯过程中的问题所在，制定了一套检查SOME/IP协议格式内容的错误处理机制。比如版本信息检查，服务ID等，其他故障信息可以在Payload中进行详细定义。目前SOME/IP支持以下两种错误处理机制，这两种uowu处理机制可以根据配置进行选择。
-消息类型0x80，Response信息，即可以通过Response Message中的Return Code来定位到问题所在；
-消息类型0x81，显式的错误信息；
主要是校验协议首部结构，对Message Type和Return code进行赋值，通知对端。
参考：
AUTOSAR SOME/IP Protocol Specification：https://www.autosar.org/fileadmin/standards/R19-11/FO/AUTOSAR_PRS_SOMEIPProtocol.pdf
智猩猩
