SOME/IP-SD -- 协议英文原文讲解2
前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C++举例调试讲解
5.1.2.2 SOME/IP-SD Header
[PRS_SOMEIPSD_00252]
Upstream requirements: RS_SOMEIPSD_00001
SOME/IP-SD shall be transported using SOME/IP.
SD报文 是基于SOME/IP协议头传输的在其基础上继续叠加SD头
[PRS_SOMEIPSD_00252] can be seen in Figure 5.2.
[PRS_SOMEIPSD_00253]
Upstream requirements: RS_SOMEIPSD_00006
The SOME/IP-SD Header shall start with an 8 Bit field called flags.
See a representation of Flags in Figure 5.3.
SD header 最开始是个8位的flags
如果仅Reboot Flag是 1 则flag字节的值是0x80.
rebootFlag 为 1 表示新的一段 订阅关系的开始
[PRS_SOMEIPSD_00254]
Upstream requirements: RS_SOMEIPSD_00006
The first flag of the SOME/IP-SD Flags field (highest order bit) shall be called Reboot
Flag.
For flags see Figure 5.3.
[PRS_SOMEIPSD_00255]
Upstream requirements: RS_SOMEIPSD_00006
The Reboot Flag of the SOME/IP-SD Header shall be set to one for all messages
after reboot until the Session-ID in the SOME/IP-Header wraps around and thus starts
with 1 again. After this wrap around the Reboot Flag is set to 0.
reboot_flag sessionID
1 1 --->开机
0 2
0 3
0 4
... ...
... ...
... ...
0 0xffff
1 1 --> sessionID 绕回
0 2
0 3
0 4
... ...
... ...
[PRS_SOMEIPSD_00256]
Upstream requirements: RS_SOMEIPSD_00002, RS_SOMEIPSD_00003
The information for the reboot flag and the Session ID shall be kept for multicast and
unicast separately.
（reboot flag and the Session ID ）的值 多播和 单播的情况要分开
[PRS_SOMEIPSD_00631]
Upstream requirements: RS_SOMEIPSD_00002, RS_SOMEIPSD_00003
The information for the reboot flag and the Session ID shall be kept for every senderreceiver relation (i.e. source address and destination address) separately.
不通的发送-接收 关系 要分开使用 （reboot flag and the Session ID）
Note:
This means there shall be separate counters for sending and receiving.
Sending
client / server的sessionID 没联系，各自管理，
比如 client sub server的sessionID 和 server suback client的sessionID 不相关。
• There shall be a counter for multicast.（对于发送端来说 多播只配一路）
• There shall be a separate counter for each peer for unicast.
Receiving
• There shall be a counter for each peer for multicast.
• There shall be a counter for each peer for unicast.
[PRS_SOMEIPSD_00258]
Upstream requirements: RS_SOMEIPSD_00006
The detection of a reboot shall be done as follows (with the new values of the current
packet from the communication partner and old the last value received before):
if old.reboot==0 and new.reboot==1 then Reboot detected
OR
if old.reboot==1 and new.reboot==1 and old.session_id>=new.session_id then Reboot
detected
reboot_flag sessionID
1 1 --->开机 reboot
0 2
0 3
0 4
... ...
... ...
0 999
1 1000
1 1001 ---> 主动发起reboot （old.reboot==1 and new.reboot==1 and old.session_id>=new.session_id）
0 1002
... ...
... ...
0 0xffff
1 1 --> sessionID 绕回 -- reboot
0 2
0 3
0 4
... ...
... ...
[PRS_SOMEIPSD_00259]
Upstream requirements: RS_SOMEIPSD_00002
The second flag of the SOME/IP-SD Flags (second highest order bit) shall be called
Unicast Flag.
Flag第二高位 表示 单播标志
For flags see Figure 5.3.
[PRS_SOMEIPSD_00540]
Upstream requirements: RS_SOMEIPSD_00002
The Unicast Flag of the SOME/IP-SD Header shall be set to Unicast (that means 1)
for all SD Messages since this means that receiving using unicast is supported.
Note:
The Unicast Flag is left over from historical SOME/IP versions and is only kept for
compatibility reasons. Its use besides this is very limited.
此标志设置为1 表示支持单播接收 -- 目前都是单播接收 -- 而没移除的原因是 历史版本的兼容保留了下来
For flags see Figure 5.3.
[PRS_SOMEIPSD_00702]
Upstream requirements: RS_SOMEIPSD_00002
Undefined bits within the Flag field shall be set to ’0’ when sending and ignored on
receiving.
发送端flag的其他位要设置为0，接收端要忽略这些位。
[PRS_SOMEIPSD_00261]
Upstream requirements: RS_SOMEIPSD_00006
After the Flags the SOME/IP-SD Header shall have a field of 24 bits called Reserved.
Flag剩下的24位保留 设置为0
[PRS_SOMEIPSD_00262]
Upstream requirements: RS_SOMEIPSD_00006
After the SOME/IP-SD Header the Entries Array（条目数组：提供、订阅的 事件组们） shall follow.
[PRS_SOMEIPSD_00263]
Upstream requirements: RS_SOMEIPSD_00006
The entries shall be processed exactly in the order they arrive.接收端 按接收的顺序 解析处理。
[PRS_SOMEIPSD_00264]
Upstream requirements: RS_SOMEIPSD_00006
After the Entries Array in the SOME/IP-SD Header an Option Array shall follow.
配置组：和上面的 事件组一一对应，是事件组的详细配置 下面有讲
[PRS_SOMEIPSD_00265]
Upstream requirements: RS_SOMEIPSD_00006
The Entries Array and the Options Array of the SOME/IP-SD message shall start with
a length field as uint32 that counts the number of bytes of the following data; i.e. the
entries or the options.
事件组 和 配置组 前都有 4个字节的长度段，描述对应数组的字节数（不包含长度段本身的4个字节）
5.1.2.3 Entry Format
[PRS_SOMEIPSD_00266]
Upstream requirements: RS_SOMEIPSD_00006
The service discovery shall support multiple entries that are combined in one service
discovery message.
一条SD报文中可以有多条 事件组描述 -- 称为聚包。
Note:
The entries are used to synchronize the state of services instances and the Publish/-
Subscribe handling.
这些条目 体现了 发布 和 订阅的实例状态
[PRS_SOMEIPSD_00267]
Upstream requirements: RS_SOMEIPSD_00006
Two types of entries exist: A Service Entry Type for Services and an Eventgroup Entry
Type for Eventgroups.
分两类条目：find/offer/stopoffer是一类条目格式
Subscribe (0x06), StopSubscribeEventgroup (0x06), SubscribeAck (0x07) and SubscribeEventgroupNack (0x07) 是一类条目格式
[PRS_SOMEIPSD_00268]
Upstream requirements: RS_SOMEIPSD_00006
A Service Entry Type shall be 16 Bytes of size and include the following fields in this
order:
• Type Field [uint8]: encodes FindService (0x00), OfferService (0x01) and StopOfferService (0x01)
offer 和 stopOffer 都是 0x01 -->TTL为0时表示停止订阅 ，>0 为提供服务
48页 有对find 报文的详解
50页 有对offer报文的详解
• Index First Option Run [uint8]: Index of this runs first option in the option array.
• Index Second Option Run [uint8]: Index of this runs second option in the option
array.
• Number of Options 1 [uint4]: Describes the number of options the first option run
uses.
• Number of Options 2 [uint4]: Describes the number of options the second option
run uses.
833条有解释 作用
5.1.2.4.1节解释了 为啥一条entry可以有多个配置
因为一个服务可以既有ipv4 又有ipv6 ,既有UDP又有TCP，既有ipv4多播又有ipv6多播，还可能有key-value(下面介绍）或者还有负载均衡选项（下面有介绍）
52页有介绍不同类型SD报文 可以使用哪些端点配置。
Option 0: Load Balancing Option
Option 1: IPv4 Endpoint Option
Option 2: IPv6 Endpoint Option
Option 3: Configuration Option
某 Entry 的字段值为：
Index First Option Run: 1
Number of Options 1: 2
Index Second Option Run: 3
Number of Options 2: 1
解析：
第一个 Option Run：
起始位置：Index First Option Run = 1（指向 Option 1）
选项数量：Number of Options 1 = 2（包含 Option 1 和 Option 2）
包含选项：[Option 1, Option 2]（IPv4 和 IPv6 Endpoint Option）
第二个 Option Run：
起始位置：Index Second Option Run = 3（指向 Option 3）
选项数量：Number of Options 2 = 1（包含 Option 3）
包含选项：[Option 3]（Configuration Option）
4. 重点总结
Index First Option Run 和 Index Second Option Run：
指向选项数组中的起始位置。
用于关联具体的选项数据。
Number of Options 1 和 Number of Options 2：
描述从起始位置开始的连续选项数量。
用于定义关联的 Option Run 长度。
关联关系：
通过这些字段，Entry 和 Option 数组之间建立了灵活的映射。
支持每个 Entry 使用多个不连续的 Option Run。
实际应用：
这套机制允许在服务发现协议中以高效和结构化的方式携带附加信息
• Service ID [uint16]: Describes the Service ID of the Service or Service Instance
this entry is concerned with.
提供 或 需要 的serviceID
• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance
this entry is concerned with or is set to 0xFFFF if all service instances of a service
are meant.
offer报文中需要指定具体的 instanceID < 0xffff
sub报文中 可指定 订阅具体的instanceID 或者用0xffff 通配订阅所有的instance。
suback报文 响应 具体的instanceID
• Major Version [uint8]: Encodes the major version of the service (instance).
此服务id的 主版本号 -- 表示已有的接口有重大变化，表示不兼容的变化 --- client对比不一致 会拒绝订阅。
另外：一般客户在矩阵表服务更新时，为了减少工作量 不会改变这个版本号，因为会把矩阵表同步更新释放到 所有ECU供应商
• TTL [uint24]: Describes the lifetime of the entry in seconds.
服务的生存周期 单位是秒
为0的含义：停止offer
推荐值
低频更新场景：
推荐 TTL：60 ~ 120 秒。
应用于较低频的场景，如不频繁变动的配置类服务。
高频实时场景：
推荐 TTL：10 ~ 30 秒。
适用于需要快速检测失效的场景，如实时数据订阅（状态或传感器数据）。
测试或调试场景：
推荐 TTL：5 ~ 15 秒。
短 TTL 用于快速观察服务和订阅行为的变化。
实际设置的考虑
网络延迟：
如果网络延迟较大，应设置较高的 TTL 值，以避免误判服务失效。
服务的动态性：
对动态性较高的服务，TTL 可以短一些，以确保订阅列表保持更新。
4. 如何处理 TTL 到期
客户端：
客户端需要在 TTL 到期前主动续订（发送新的订阅请求）。
续订的时间间隔一般可以略小于 TTL 值，例如 TTL 的 80%。
服务端：
服务端在 TTL 到期后清除对应订阅信息，节省资源。
不会主动通知客户端失效，需要客户端自行维护续订逻辑。
• Minor Version [uint32]: Encodes the minor version of the service
服务id的次版本号 -- 是向后兼容的变化 --- 表示新增了接口 不影响之前的接口使用 -- 可兼容 -- client对比不一致 打印报警信息 可继续订阅
另外：一般客户在矩阵表服务更新时，为了减少工作量 不会改变这个版本号，因为会把矩阵表同步更新释放到 所有ECU供应商
[PRS_SOMEIPSD_00270]
Upstream requirements: RS_SOMEIPSD_00006
dAn Eventgroup Entry (Type 2) shall be 16 Bytes of size and include the following fields
in this order:
• Type Field [uint8]: encodes Subscribe (0x06), StopSubscribeEventgroup (0x06),
SubscribeAck (0x07) and SubscribeEventgroupNack (0x07).
• Index of first option run [uint8]: Index of this runs first option in the option array.
• Index of second option run [uint8]: Index of this runs second option in the option
array.
• Number of Options 1 [uint4]: Describes the number of options the first option run
uses.
• Number of Options 2 [uint4]: Describes the number of options the second option
run uses.
• Service-ID [uint16]: Describes the Service ID of the Service or Service Instance
this entry is concerned with.
这 5 个 字段的含义 同 268条
• Instance ID [uint16]: Describes the Service Instance ID of the Service Instance
this entry is concerned with. The Service Instance ID shall not be set to 0xFFFF
for any Instance.
订阅、订阅回复的 具体instanceID ,不能用0xffff通配
• Major Version [uint8]: Encodes the major version of the service instance this
eventgroup is part of.
• TTL [uint24]: Descibes the lifetime of the entry in seconds.
• Reserved [uint12]: Shall be set to 0x000.
这几个的含义 同 268条
• Counter [uint4]: Is used to differentiate identical Subscribe Eventgroups of the
same subscriber. Set to 0x0 if not used.
最大到15
为0表示不使用。
client发送 1-15 递增表示更新TTL 或是groupID , 或是由于网络问题 导致重发，server端发现counter值未变化 则表示已订阅过 不做处理。
• Eventgroup ID [uint16]: Transports the ID of an Eventgroup.
订阅的serviceID所在的事件组。
[PRS_SOMEIPSD_00845]
Upstream requirements: RS_SOMEIPSD_00006
The Major Version of an entry (according to [PRS_SOMEIPSD_00268] and
[PRS_SOMEIPSD_00270]) shall match the version of the corresponding Service Interface
主版本号要做一致性检查
Note: While SOME/IP-SD defines the Major and Minor version of a service interface,
SOME/IP messages themselves only use the major version in the interface version
field of the SOME/IP header.
sub 仅对比 Major版本号
5.1.2.3.1 Referencing Options from Entries
[PRS_SOMEIPSD_00833]
Upstream requirements: RS_SOMEIPSD_00025
Using the following fields of the entries, options are referenced by the entries:
• Index First Option Run: Index into array of options for first option run. Index 0
means first option of this SOME/IP-SD message.
配置项1 位于队列的起始位置 （0表示第一个）
• Index Second Option Run: Index into array of options for second option run. Index
0 means first option of this SOME/IP-SD message.
配置项2 位于队列的起始位置
• Number of Options 1: Length of first option run. Length 0 means no option in
option run.
配置项1 起始位置连续多少项对应全是配置项1 的配置（一般只有 1 项）
• Number of Options 2: Length of second option run. Length 0 means no option in
option run.
配置项2 起始位置连续多少项对应全是配置项2 的配置
Two different option runs exist: First Option Run and Second Option Run.
Rationale for the support of two option runs: Two different types of options are expected: options common between multiple SOME/IP-SD entries and options different
for each SOME/IP-SD entry. Supporting two different options runs is the most efficient
way to support these two types of options, while keeping the wire format highly efficient.
意思这中 位置 加 长度的设计 对序列化来说比较灵活高效
[PRS_SOMEIPSD_00341]
Upstream requirements: RS_SOMEIPSD_00025
Each option run shall reference the first option and the number of options for this run.
每个选项的应用是 从它起始位置起连续 number of options 个
[PRS_SOMEIPSD_00342]
Upstream requirements: RS_SOMEIPSD_00025
If the number of options is set to zero, the option run is considered empty.
如果options的数量设置为0 则option的 index引用可以认为是无效的
[PRS_SOMEIPSD_00343]
Upstream requirements: RS_SOMEIPSD_00025
For empty runs the Index (i.e. Index First Option Run and/or Index Second Option
Run) shall be set to zero.
如果 options number是0 表示无效 则index也需要设置为0
[PRS_SOMEIPSD_00834]
Upstream requirements: RS_SOMEIPSD_00025
Implementations shall accept and process incoming SD messages with option run
length set to zero and option index not set to zero by ignoring this option run
接收端 看到无效的option则可忽略 不要“大惊小怪”报错