Loading...
墨滴

jasonj333

2021/10/08  阅读:20  主题:红绯

详解SOME/IP协议文档-3

这是详解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消息的验证和错误处理
SOME/IP消息的验证和错误处理

通信错误与处理

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

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

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

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

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

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

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

Interface Version兼容规则

Interface Version标识payload格式,payload格式受以下因素影响:

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

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

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

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


以上内容参考文档AUTOSAR_PRS_SOMEIPProtocol.pdf

jasonj333

2021/10/08  阅读:20  主题:红绯

作者介绍

jasonj333