SOME/IP 协议介绍（四）RPC协议规范

RPC协议规范

本章描述了SOME/IP的RPC协议。

传输协议绑定

为了传输不同传输协议的SOME/IP消息，可以使用多种传输协议。SOME/IP目前支持UDP和TCP。它们的绑定在以下章节中进行了解释，而第[SIP_RPC_450页，第36页]节讨论了选择哪种传输协议。

UDP绑定

SOME/IP的UDP绑定通过在UDP数据包中传输SOME/IP消息来实现。SOME/IP消息不应该被分段。因此，应当注意确保SOME/IP消息不要太大，即SOME/IP有效负载最多为1400字节。具有更大负载的消息不应该通过UDP传输，而应该使用TCP等其他方式。
头格式允许在单个UDP数据包中传输多个SOME/IP消息。通过SOME/IP长度字段，SOME/IP实现可以轻松地识别SOME/IP消息的结束。根据UDP长度字段，SOME/IP可以确定UDP数据包中是否存在其他SOME/IP消息。

每个SOME/IP有效负载都应具有自己的SOME/IP头。
作为优化，SOME/IP的UDP绑定可以使用确认消息，特别是用于触发服务器端长时间运行操作的请求/响应通信，在发送结果（传输或处理确认）之前必须完成。确认消息是具有完全相同头字段但更改了消息类型且没有有效负载的SOME/IP消息。这些额外的确认消息的使用应由接口规范进行配置。
另一种方法是设计一种具有返回代码或输出参数的方法，指定“操作仍在进行中”，以便请求的ECU可以在一定时间后再次询问。

AUTOSAR 标准

基于Socket适配器概念，AUTOSAR可以将传入的UDP数据包分割为不同的i-PDU。然而，并非所有的AUTOSAR实现目前都能够将不同的i-PDU组合起来并发送一个包含多个SOME/IP消息的UDP数据包。

TCP绑定

SOME/IP的TCP绑定在很大程度上基于UDP绑定。与UDP绑定不同，TCP绑定允许更大的SOME/IP消息以及连续传输的SOME/IP消息（流水线传输）。
每个SOME/IP有效负载都应具有自己的SOME/IP头。
为了降低延迟和响应时间，应关闭Nagle算法（TCP_NODELAY）。
当TCP连接丢失时，未完成的请求应被处理为超时。由于TCP处理可靠性，不需要额外的可靠性手段。错误处理在[SIP_RPC_364页，第31页]中进行了详细讨论。

使用Magic Cookies允许对TCP流进行重新同步

为了在测试和集成场景中允许对SOME/IP over TCP进行重新同步，应在SOME/IP消息之间使用SOME/IP Magic Cookie消息（图1）。
在第一个在TCP段中传输的SOME/IP消息之前，应包括SOME/IP Magic Cookie消息。
实现应每个TCP段只包含最多一个SOME/IP Magic Cookie消息。

如果实现没有适当的访问消息分段机制，因此无法满足[SIP_RPC_591页26]和[SIP_RPC_592页26]的要求，实现应根据以下启发式规则包括SOME/IP Magic Cookie消息：
只要在该TCP连接上传输消息，每隔10秒向TCP连接添加一次SOME/IP Magic Cookie消息。
Magic Cookie消息的布局基于SOME/IP。字段设置如下：
• 服务ID = 0xFFFF
• 方法ID = 0x0000（客户端到服务器方向）
• 方法ID = 0x8000（服务器到客户端方向）
• 长度 = 0x0000 0008
• 客户端ID = 0xDEAD
• 会话ID = 0xBEEF
• 协议版本如上所述
• 接口版本 = 0x01
• 消息类型 = 0x01（客户端到服务器通信）或0x02（服务器到客户端通信）
• 返回码 = 0x00
Magic Cookie消息的布局如图1所示。

多个服务实例

虽然不同的服务可以共享相同的端口号，但单个ECU上的多个服务实例应每个实例监听不同的端口。不同ECU上的实例通过不同的实例ID进行识别。这些实例ID用于服务发现，但不包含在SOME/IP头中。

通过服务ID与套接字（即IP地址、传输协议（UDP/TCP）和端口号）的组合可以识别服务实例。建议实例在UDP和TCP上使用相同的端口号。如果一个服务实例使用UDP端口x，则只有该服务的这个实例，而不是同一服务的另一个实例，应该使用准确的TCP端口x提供其服务。

请求/响应通信

请求/响应模式是最常见的通信模式之一。一方（以下称为客户端）发送一个请求消息，由另一方（服务器）进行回答。
ID: SIP_RPC_329
在SOME/IP头中，客户端在请求消息中必须执行以下操作：

• 构建有效载荷

• 根据客户端要调用的方法设置消息ID

• 将长度字段设置为8个字节（用于SOME/IP头的第二部分）+序列化有效载荷的长度

• 可选地将请求ID设置为唯一的数字（仅对客户端而言应唯一）

• 根据[SIP_RPC_89页14]设置协议版本。

• 根据接口定义设置接口版本

• 将消息类型设置为请求（即0x00）

• 将返回码设置为0x00

服务器根据客户端的头构建自己的头，并额外执行以下操作：
• 构建有效载荷
• 将长度设置为8个字节 + 新有效载荷的大小
• 将消息类型设置为响应（即0x80）或错误（即0x81）
• 设置返回码。

AUTOSAR 标准

AUTOSAR应通过客户端/服务器功能来实现请求-响应。对于中间实现，可能需要通过发送者/接收者功能来实现ECU间的通信。在这种情况下，PDU的语义和语法不应与本规范有所不同。

Fire&Forget通信

没有响应消息的请求被称为Fire&Forget通信。其实现与请求/响应基本相同，但存在以下差异：

• 没有响应消息。

• 消息类型设置为REQUEST_NO_RETURN（即0x01）。

Fire&Forget消息不会返回错误。当需要时，应用程序应实现错误处理和返回代码。

AUTOSAR 标准

Fire&Forget应该使用发送者/接收者功能来实现。

通知

通知描述了一种常见的发布/订阅概念。通常，服务器发布一个服务，客户端订阅该服务。在特定事件发生时，服务器将向客户端发送通知，这可以是更新的值或已发生的事件之一。

SOME/IP仅用于传输更新的值，而不用于发布和订阅机制。这些机制由SOME/IP-SD实现，并在第[SIP_RPC_360页31]节中进行了解释。

当同一ECU上存在多个订阅的客户端时，系统应处理通知的复制，以节省在通信介质上的传输。这在使用组播消息传输通知时尤为重要。

发送通知的策略

对于不同的用例，可以使用不同的发送通知策略，并应在服务接口中定义。以下是常见的示例：

• 周期性更新 - 在固定间隔（例如每10毫秒）发送更新后的值。

• 改变时更新 - 当“值”发生变化时立即发送更新（例如门打开）。

• Epsilon变化 - 仅在与上一个值的差异大于某个特定的epsilon时发送更新。此概念可能是自适应的，即预测基于历史记录; 因此，仅当预测与当前值之间的差异大于epsilon时才传输更新。

发布/订阅处理

发布/订阅处理应根据第[SIP_SD_137第72页]节进行实现。

AUTOSAR标准

通知使用AUTOSAR发送者/接收者功能进行传输。如果在一个ECU内存在不同的通知接收者，可以在RTE中进行通知消息的复制。这意味着一个事件/通知消息应仅发送一次给具有多个接收者的ECU。

字段（field)

字段应该是可选的getter、可选的setter和可选的通知事件的组合。

字段至少应该有1个getter或1个setter或1个通知事件。

字段的getter应该是一个请求/响应调用，请求消息中应该有一个空负载，响应消息的负载中应该是字段的值。

字段的setter应该是一个请求/响应调用，请求消息的负载中应该包含字段的期望值，响应消息的负载中应该包含被设置到字段的值。

通知器应该是一个事件，在字段发生变化时传输字段的值，并遵循事件的规则。

错误处理

错误处理可以在应用程序中或下面的通信层中完成。因此，存在不同的可能机制。

传输应用程序错误码和异常

对于错误处理，支持两种不同的机制。所有消息都有一个返回代码字段来携带返回代码。但是，只有响应消息（消息类型0x80和0x81）使用此字段将返回代码传递给它们回答的请求消息（消息类型0x00）。所有其他消息将此字段设置为0x00（请参见第2.3.7节）。对于更详细的错误，错误消息的布局（消息类型0x81）可以携带特定的错误处理字段，例如异常字符串。错误消息将被发送而不是响应消息。

这可以用于处理服务器中可能发生的所有不同应用程序错误。此外，可能会出现与通信介质或中间组件（例如交换机）相关的问题，这些问题必须通过可靠传输等方式进行处理。

返回码

错误处理基于AUTOSAR的8位Std_returnType。最高的两个比特位被保留，应设置为0。返回代码的接收者应忽略最高的两个比特位的值。

系统不应为事件/通知返回错误消息。

当前定义了以下返回代码，并应按照描述进行实现：

生成和处理返回码应该是可配置的。

在过渡期间，某些实现（例如基于AUTOSAR的实现）可能不需要实现返回码的要求。请咨询系统部门。

错误消息格式

为了更灵活的错误处理，SOME/IP允许用户指定一个特定于错误的消息布局，而不是使用响应消息的消息布局。这由接口规范定义，并可用于传输高级编程语言的异常。

建议的异常消息布局如下：

• 特定异常的联合体。至少需要存在一个没有字段的通用异常。

• 动态长度字符串用于异常描述。

联合体提供了以类型安全的方式在将来添加新异常的灵活性。字符串用于传输可读的异常描述，以便于测试和调试。

通信错误和通信错误处理

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

• 可能性（Maybe）- 消息可能会到达通信伙伴

• 至少一次（At least once）- 消息至少会到达通信伙伴一次

• 确定一次（Exactly once）- 消息确切地到达通信伙伴一次

在涉及请求/响应时，这些术语适用于两个消息（即请求、响应或错误）。

虽然不同的实现可能采用不同的方法，但当前使用UDP绑定时，SOME/IP实现了"可能性"的可靠性，使用TCP绑定时实现了"确定一次"的可靠性。其他错误处理留给应用程序处理。

对于"可能性"的可靠性，当使用UDP作为传输协议的请求/响应通信时，只需要一个超时。图2显示了"可能性"可靠性的状态机。客户端的SOME/IP实现必须等待指定超时时间以获取响应。如果超时发生，SOME/IP应向客户端发出E_TIMEOUT信号。

对于"确定一次"的可靠性，可以使用TCP绑定，因为TCP被定义为允许可靠的通信。

可以在应用程序或SOME/IP实现中实现其他机制以实现更高的可靠性。请记住，通信不必实现这些功能。下一节[SIP_RPC_440第35页]描述了这些可选的可靠性机制。

基于应用程序的错误处理

应用程序可以通过使用幂等操作（即可以多次执行而不会产生副作用的操作）和使用简单的超时机制轻松实现“至少一次”可靠性。图3显示了使用隐式确认的“至少一次”可靠性的状态机。当客户端发送请求时，它会启动一个计时器，计时器的超时时间为特定方法指定的时间。如果在计时器到期之前（在顶部的圆形转换处）未收到响应，则客户端将重试该操作。典型的重试次数为2，因此会发送3个请求。

重试次数、超时值和超时行为（常量或指数回退）不在SOME/IP规范之内，可以添加到接口定义中。