网站整合营销推广,网站右下角代码,网站建设最好公司,建设一个百度百科类网站前言 SOME/IP协议越来越多的用于汽车电子行业中#xff0c;关于协议详细完全的中文资料却没有#xff0c;所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块#xff1a;
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C举例调试讲解 4.1 Speci…前言 SOME/IP协议越来越多的用于汽车电子行业中关于协议详细完全的中文资料却没有所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C举例调试讲解 4.1 Specification of SOME/IP Message Format (Serialization)
SOME/IP消息格式规范--序列化
Serialization describes the way data is represented in protocol data units (PDUs) as payload of either UDP or TCP messages, transported over an IP-based automotive in-vehicle network.
序列化描述了基于UDP/TCP传输层的 的发送、接收的数据包的数据组织方式。简单的理解我们用UDP/TCP发送、接收我们的自定义数据。不过现在是把这个自定义数据 替换成SOME/IP定义好的格式。用SOME/IP定义数据的方式 组织 数据的过程 就称为序列化。
4.1.1 Limitation
Reordering of out-of-order segments of a SOME/IP message is not supported.
SOME/IP由于网络差或干扰数据乱序这种乱序SOME/IP协议本身是不支持恢复的
也就是说SOME/IP协议本身不负责 传输数据的 稳定完整性。
简单理解需要数据传输可靠则选择TCP传输协议否则可选择UDP协议具体怎么选择后面章节有专门讲解
4.1.2 Header -- 消息头的数据格式 -- 后面有详解 [PRS_SOMEIP_00030] Upstream requirements: RS_SOMEIP_00027 [The structure of header layout shall consist of -- 消息头结构的布局内存布局组成 • Message ID (Service ID/Method ID) [32 Bits] • Length [32 Bits] • Request ID (Client ID/Session ID) [32 Bits] • Protocol Version [8Bits] • Interface Version [8 Bits] • Message Type [8 Bits] • Return Code [8 Bits] ] [PRS_SOMEIP_00941] Upstream requirements: RS_SOMEIP_00027 In case of E2E communication protection being applied, the E2E header is placed after Return Code, depending on the chosen Offset value for the E2E header. The default Offset value is 64 bit, which puts the E2E header exactly between Return Code and Payload E2E保护 是一种数据校验E2E的header的大小 和 配置有关具体参见AUTOSAR_FO_PRS_E2EProtocol.pdf 此专题不做讨论。
[PRS_SOMEIP_00031] Upstream requirements: RS_SOMEIP_00027 For interoperability reasons the header layout shall be identical for all implementations of SOME/IP. The fields are presented in transmission order i.e. the fields on the top left are transmitted first
头部布局的互操作性要求 互操作性原因 为了实现互操作性SOME/IP 的头部布局在所有实现中必须保持一致。 字段传输顺序 字段按照 传输顺序 描述 位于左上角的字段 最先被传输。网络字节序依次向右下角的字段传输。
这确保了不同系统之间在使用 SOME/IP 协议时能够正确解析和处理数据包头部。
4.1.2.1 Message ID [32 Bit] [PRS_SOMEIP_00034] Upstream requirements: RS_SOMEIP_00021, RS_SOMEIP_00022, RS_SOMEIP_00023, RS_- SOMEIP_00027 The Message ID shall be a 32 Bit identifier that is used to identify • the RPC call to a method of an application • or to identify an event. Note: The assignment of the Message ID is up to the user / system designer. However, the Message ID is assumed be unique for the whole system (i.e. the vehicle).
消息 ID 的定义和用途
消息 IDMessage ID 是一个 32 位标识符用于以下目的 标识应用程序中 方法的 RPC 调用。标识一个 事件。
注意事项
消息 ID 的分配由用户或系统设计者决定。系统范围内唯一性 消息 ID 应在整个系统中如车辆范围内保持唯一。 4.1.2.2 Method ID [16 Bit] [PRS_SOMEIP_00245] Upstream requirements: RS_SOMEIP_00016, RS_SOMEIP_00027 The Message ID header field shall be structured into a 16 Bit Service ID header field (to distinguish up to 2^16 services) and a 16 bit Method ID header field to distinguish up to 2^16 service elements (namely methods and/or events). This structuring of the Message ID header field is illustrated as shown in [PRS_SOMEIP_00755]. Note: It is common practise and recommended to split the ID space of the Method ID between Methods and Events/Notifications. Methods would be in the range 0x0000- 0x7FFF (first bit of Method-ID is 0) and Events/Notifications would use the range 0x8000-0x8FFF (first bit of the Method-ID is 1).
Message ID 的结构 Message ID 的头部字段由以下两个部分组成 16 位服务 IDService ID 用于区分多达 2162^{16}216 个服务。 16 位方法 IDMethod ID 用于区分多达 2162^{16}216 个服务元素包括方法和/或事件。 Message ID 的结构示例可以参考 [PRS_SOMEIP_00755]。
推荐的 Method ID 分配规则
分配方法这个是建议的通用做法如果有人自己定制规则区分方法和事件也是可以的 方法Methods使用范围 0x0000 - 0x7FFF即 Method ID 的第一位为 0。事件/通知Events/Notifications使用范围 0x8000 - 0x8FFF即 Method ID 的第一位为 1。
备注
推荐做法将 方法Methods 和 事件/通知Events/Notifications 的 ID 空间分开管理。
[PRS_SOMEIP_00755] Message ID header field Eventgroup is a logical grouping of events and notification events of fields inside a service in order to allow subscription.
Eventgroup 是服务内部的一种逻辑分组用于将以下内容组织在一起
事件Events字段的通知事件Notification Events of Fields
目的
Eventgroup 的设计是为了便于 订阅Subscription。
事件有 事件ID 事件组有组ID后面会讲
简而言之Eventgroup 是一种机制用来将服务内相关的事件和通知逻辑地组织起来以便客户端可以通过订阅 Eventgroup 来获取这些事件的更新或通知。因此订阅是以组来订阅的
下面截图 是订阅报文解析的截图 [PRS_SOMEIP_00365]
A SOME/IP Eventgroup shall at least contain one event.
事件组不能为空至少要包含一个事件。
[PRS_SOMEIP_00366]
Events as well as field notifiers shall be mapped to at least one SOME/IP Eventgroup
事件必须要绑定在一个 或 多个事件组上。
4.1.2.3 Length [32 Bit] -- 长度字段 [PRS_SOMEIP_00042] Upstream requirements: RS_SOMEIP_00027, RS_SOMEIP_00040 Length field shall contain the length in Byte starting from Request ID/Client ID until the end of the SOME/IP message
解释了length从哪里开始计算 -- 从后一个字段Request ID/Client ID)到整条消息的最后。 4.1.2.4 Request ID [32 Bit] The Request ID allows a server and client to differentiate multiple parallel uses of the same method, getter or setter.
给同一个client标记请求的顺序的。 client给server发送的requestID 是多少server就得回复多少。 client并发发送多个同样的请求但是携带的参数不通则需要通过这个requestID 来区分
仅用于method/getter/setter
[PRS_SOMEIP_00043] Upstream requirements: RS_SOMEIP_00025, RS_SOMEIP_00027 [The Request ID shall be unique for a request-response pair to differentiate between multiple calls of the same method.]证明了回复和请求的requestID 是相同的
[PRS_SOMEIP_00704] Upstream requirements: RS_SOMEIP_00027 When generating a response message, the provider shall copy the Request ID from the request to the response message.证明了请求和回复的requestID 相同
服务端不需要关系RequestID的合理性 只需要拷贝回复就行如果不合理则需要client端自己负责。 Note: This allows the client to map a response to the issued request even with more than one request outstanding.
规则说明
在生成响应消息时提供方Provider 应该将请求消息中的 Request ID 复制到响应消息中。
注意事项
这种机制的意义在于 即使客户端同时发出了多个请求也能通过 Request ID 将响应消息与对应的请求进行正确匹配。
总结
这种设计确保了在 并发请求 场景下客户端能够可靠地识别和处理每个响应消息避免数据混淆或误匹配问题。
[PRS_SOMEIP_00044] Upstream requirements: RS_SOMEIP_00025 Request IDs must not be reused until the response has arrived or is not expected to arrive anymore (timeout).
保证并发时的唯一性 在未收到回复之前或者认为回复超时之前Request ID 不能重复。 收到回复了 可以重复 -- 由client 负责。 0voice · GitHub
