这是详解SOME/IP协议文档系列的最后一篇，需要你的转发支持

SOME/IP几种通信模式

Request/Response通信

请求/响应模式是最常见的通信模式之一，一个通信伙伴（客户端）发送请求消息，由另一个通信伙伴（服务器）应答

客户端发送的SOME/IP Request消息的Header和Payload必须符合如下要求：

构建Payload
根据客户端要调用的方法来设置Message ID
Length字段的值设置8个字节+Payload长度
将Request ID设置为对客户端来说唯一的编号
设置Protocol Version
根据接口定义设置Interface Version
设置Message Type为REQUEST（0x00）
设置Return Code为0x00

服务器发送的SOME/IP Response消息的Header和Payload必须符合如下要求：

构建Payload
把对应的Request消息的Message ID复制到Response消息的Message ID里
Length字段的值设置8个字节+Payload长度
把对应的Request消息的Request ID复制到Response消息的Request ID里
设置Message Type为RESPONSE（0x80）或ERROR（0x81）
Return Code应该为请求消息调用方法时返回的代码，或者是调用失败时的错误代码

服务器/客户端在接收到完整的请求/响应消息前，忽略新的请求/响应报文

Fire&Forget通信

没有响应消息的请求称为fire&forget

客户端发送的SOME/IP request-no-return消息的Header和Payload必须符合如下要求：

构建Payload
根据客户端要调用的方法来设置Message ID
Length字段的值设置8个字节+Payload长度
将Request ID设置为对客户端来说唯一的编号
设置Protocol Version
根据接口定义设置Interface Version
设置Message Type为REQUEST_NO_RETURN（0x01）
设置Return Code为0x00

Fire&Forget消息调用方法成功时服务器不会回复响应，发生错误时也不会返回错误，错误处理和返回码应在需要时由应用程序实现

Notification Events

通知事件描述了一般的发布/订阅概念，通常服务器发布客户端订阅的服务

在某些情况下，服务器会向客户端发送一个事件，例如更新的值或发生的事件

SOME/IP仅用于传输更新的值，而不用于发布和订阅机制，这些机制由SOME/IP-SD实现

也就是说，客户端发送SOME/IP-SD类型的消息来订阅服务，而服务器通过Notification消息发布客户端订阅的服务

服务器发送的SOME/IP Notification消息的Header和Payload必须符合如下要求：

构建Payload
根据服务器要发送的事件来设置Message ID
Length字段的值设置8个字节+Payload长度
设置Client ID（0x00）和Session ID
设置Protocol Version
根据接口定义设置Interface Version
设置Message Type为NOTIFICATION（0x02）
设置Return Code为0x00

发送Notification消息的策略

对于不同的用例，发送通知消息的策略可能不同，以下是常见的示例：

循环更新：以固定间隔发送更新值（例如，每100毫秒，对于Alive的安全相关消息）
改变时更新：一旦“值”发生改变（例如门打开），立即发送更新
满足差值时更新：仅当与最后一个值的差异大于某个值时才发送更新，这个概念可能是自适应的，即预测是基于历史的，因此，只有当预测值和当前值之间的差异大于某个值时，才会传输更新

Fields

一个字段表示一个状态，并具有有效值，订阅该字段的订阅者将字段值作为初始事件

字段是getter、setter和notification event的集合

没有setter、getter和notifier的字段不应该存在，该字段应至少包含一个getter、一个setter 或一个notifier

字段的getter应是Request/Response调用，在请求消息中payload为空，并且在响应消息的有效载荷中具有该字段的值

字段setter应是Request/Response调用，请求消息的payload中有需要设置的值，响应消息的payload中有设置的值

当客户端订阅该字段时，notifier应发送一个事件消息，将字段的值传输到客户端

从上面可以看出，请求/响应消息既可以远程调用方法，也可以调用字段的getter和setter

而Notification Event和Field notifer的区别，就是后者在订阅后会发送一个当前值

Error Handling

客户端不管是请求还是订阅，都有可能在服务器中遭遇失败，这也就意味着服务器需要具备错误处理的能力

错误处理可以在应用程序或下面的通信层中完成，因此，SOME/IP支持两种不同的处理错误的机制：

在响应消息中携带Return Code
显式的错误消息

具体用哪个，取决于配置情况

Return Code是将应用程序错误和方法的响应数据从服务器传输到客户端

请注意，从SOME/IP的角度来看，Request和Response方法的Return Code不会被视为错误，这意味着如果请求/响应方法以不等于0x00的返回码退出，则消息类型仍为0x80

什么意思

也就是说当Return Code不为0x00时，也可以用Response来反馈这个Error Code，而不是用Message Type为0x81的Error Message

显式错误消息将应用程序错误和响应数据或通用SOME/IP错误从服务器传输到客户端

如果需要传输更详细的错误信息，则错误消息（Message Type 0x81）的Payload应填充特定错误数据，例如异常字符串，应发送错误消息而不是响应消息

也就是说，如果服务器需要发送详细的错误信息给客户端，那么就使用错误消息而非响应消息，因为错误消息可以携带错误信息，而不是简单的Error Code

所有的消息都有Return Code字段，只有Response消息（Message Type 0x80）和Error消息（Message Type 0x81）使用Return Code字段承载Return Code值回复请求（Message Type 0x00），除0x80和0x81之外的所有其他消息都应将Return Code字段设置为0x00

Return Code

上面讲SOME/IP首部格式时讲过，这里不再细说

Error Message

SOME/IP消息的接收者不应对events/notifications回复错误消息

SOME/IP消息的接收者不应对fire&forget methods回复错误消息

如果events/notifications和fire&forget methods的Message Type字段被错误地设置成Request或Response，则SOME/IP消息的接收者不应回复错误消息

对于请求/响应方法，错误消息应复制请求/响应消息的SOME/IP首部的字段（例如Message ID、Request ID和Interface Version）而不是Payload，此外Message Type（0x81）和Return Code必须设置为适当的值

Error Processing Overview

对于通过UDP接收的SOME/IP消息，应检查UDP如下信息：

UDP数据报大小应至少为16字节（即SOME/IP消息的最小长度）
UDP首部中Length字段的值应小于或等于UDP payload字节数

SOME/IP消息的验证和错误处理

通信错误与处理

在考虑RPC消息的传输时，存在不同的可靠性语义：

可能：消息可能会到达通信伙伴
至少一次：消息至少到达通信伙伴一次
恰好一次：消息恰好到达通信伙伴一次

SOME/IP目前在使用UDP绑定时实现了“可能”的可靠性，而在使用TCP绑定时实现了“恰好一次”的可靠性,进一步的错误处理留给应用程序

对于“可能”的可靠性，当使用请求/响应通信结合UDP作为传输协议时，只需要一个超时

图4.22显示了“可能”可靠性的状态机，客户端的SOME/IP实现必须等待响应指定的超时时间

如果超时发生，SOME/IP应向客户端应用程序发送E_TIMEOUT信号

详解SOME/IP协议文档-3插图1

对于“恰好一次”的可靠性，可以使用TCP绑定，因为TCP被定义为允许可靠的通信

Interface Version兼容规则

Interface Version标识payload格式，payload格式受以下因素影响：

服务接口规范
序列化配置（例如，可变大小数组的使用、长度字段的大小、填充、TLV、SOME/IP-TP）

接口版本会受以下原因增加：

payload格式的不兼容变化
服务行为的不兼容变化
应用程序设计要求

接口版本不会因为payload格式的兼容变化而增加

以上内容参考文档AUTOSAR_PRS_SOMEIPProtocol.pdf

详解SOME/IP协议文档-3