哈密网站制作,网站开发技术包括哪些,盐城网站优化工作室,网站策划与设计(RPC协议规范
本章描述了SOME/IP的RPC协议。
传输协议绑定
为了传输不同传输协议的SOME/IP消息#xff0c;可以使用多种传输协议。SOME/IP目前支持UDP和TCP。它们的绑定在以下章节中进行了解释#xff0c;而第[SIP_RPC_450页#xff0c;第36页]节讨论了选择哪种传输协议。…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的语义和语法不应与本规范有所不同。
FireForget通信
没有响应消息的请求被称为FireForget通信。其实现与请求/响应基本相同但存在以下差异 没有响应消息。 消息类型设置为REQUEST_NO_RETURN即0x01。
FireForget消息不会返回错误。当需要时应用程序应实现错误处理和返回代码。
AUTOSAR 标准
FireForget应该使用发送者/接收者功能来实现。
通知
通知描述了一种常见的发布/订阅概念。通常服务器发布一个服务客户端订阅该服务。在特定事件发生时服务器将向客户端发送通知这可以是更新的值或已发生的事件之一。
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。返回代码的接收者应忽略最高的两个比特位的值。
系统不应为事件/通知返回错误消息。
当前定义了以下返回代码并应按照描述进行实现 ID Name Description 0x00 E_OK 未发生错误 0x01 E_NOT_OK 发生未指定的错误 0x02 E_UNKNOWN_SERVICE 请求的服务ID未知 0x03 E_UNKNOWN_METHOD 请求的方法ID未知。已知服务ID 0x04 E_NOT_READY 已知服务ID和方法ID。应用程序未运行 0x05 E_NOT_REACHABLE 无法访问运行该服务的系统仅限内部错误代码 0x06 E_TIMEOUT 发生超时仅限内部错误代码 0x07 E_WRONG_PROTOCOL_VERSION SOME/IP协议版本不受支持 0x08 E_WRONG_INTERFACE_VERSION 接口版本不匹配 0x09 E_MALFORMED_MESSAGE 反序列化错误例如长度或类型不正确 0x09-0x1f RESERVED 保留给通用SOME/IP错误。这些错误将在本文档的未来版本中指定 0x20-0x3f RESERVED 保留给特定服务和方法的错误。这些错误由接口规范指定
生成和处理返回码应该是可配置的。
在过渡期间某些实现例如基于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规范之内可以添加到接口定义中。
