前言
SOME/IP协议越来越多的用于汽车电子行业中，关于协议详细完全的中文资料却没有，所以我将结合工作经验并对照英文原版协议做一系列的文章。基本分三大块：
1. SOME/IP协议讲解
2. SOME/IP-SD协议讲解
3. python/C++举例调试讲解
5.1.4 Service Discovery Communication Behavior
[PRS_SOMEIPSD_00800]
Upstream requirements: RS_SOMEIPSD_00025
SOME/IP-SD协议为了使得消息数量减少 应该尽量多的把消息组合到一个包中发（<1400字节）--- 聚包发送
SOME/IP Service Discovery shall reduce the number of Service Discovery messages
by packing entries together, if they can be sent at the same time:
• Multiple entries of different service instances (e.g., all Offer Service entries)
• Multiple entries of different types. E.g.:
– Offer Service entries and Find Service entries
– Subscribe Eventgroup Ack Entries and Subscribe Eventgroup Nack entries
多个offer entries组合
或者多个不同类型的 entries组合: offer/find组合 suback/subNack组合
5.1.4.1 Startup Behavior --- 以下是针对单个服务实例实现的说明
[PRS_SOMEIPSD_00395]
Upstream requirements: RS_SOMEIPSD_00025
For each Service Instance the Service Discovery shall have at least these three
phases in regard to sending entries:
每个服务实例至少有这三个阶段的entries发送：
• Initial Wait Phase 初始化阶段 -- 实例程序初始化还没准备好 不能发送find/offer
• Repetition Phase 重复阶段 -- 一般是client在未收到offer报文时，会高频重复find报文
且按照一定的策略（后面讲）
• Main Phase 主阶段
这个阶段就是正常的重复阶段 ， TTL快超时时，server发送offer, client则等待server发送offer后sub订阅
Note:
An actual implemented state machine will need more than just states for these three
phases. E.g. local services can be still down and remote services can be already
known (no finds needed anymore).
实际情况可能比这三个阶段要复杂 -- 比如：本地服务已经下线 并且 对方已经知道这个服务的存在不会（对端之前发过Offer）不会再发送find，导致通信中断
[PRS_SOMEIPSD_00397]
Upstream requirements: RS_SOMEIPSD_00025, RS_SOMEIPSD_00012
The service discovery shall enter the Initial Wait Phase for a client service instance
when the link on the interface needed for this service instance is up and the client
service is requested by the application.
[PRS_SOMEIPSD_00133]
Upstream requirements: RS_SOMEIPSD_00025, RS_SOMEIPSD_00012
The service discovery shall enter the Initial Wait Phase for a server service instance
when the link on the interface needed for this service instance is up and the server
service is available.
Note:
It is possible that the link is up but the service instance is not yet available on server
side.
Service instances require the availability of the needed applications and possible external sensors and actuators as well. Basically the functionality needed by this service
instance has to be ready to offer a service and finding a service is applicable after
some application requires it.
不管是client/server端都是 开始要进入 初始化阶段的，而进入这个阶段是有条件的，
为什么要定义这些条件？
因为标准中对初始化阶段的时间做了规范限定，程序员设计的协议栈部署和启动服务的耗时时间不能超过这个时间，
所以 不能把系统的开机时间算进去 ，不能把等待网卡硬件链路
的建立时间算进去，不能把协议栈等待 上层应用发出使用这个服务通知的时间算进去。
初始化阶段 是对协议栈的属性描述，规定了协议栈初始化部署服务耗时的边界。
等部署好服务到准备发送find/offer 初始化阶段就结束了。
[PRS_SOMEIPSD_00399]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall wait based on the INITIAL_DELAY after entering the
Initial Wait Phase and before sending the first messages for the Service Instance.
INITIAL_DELAY -- 需要客户指定 ，定义了初始化阶段的最大耗时
[PRS_SOMEIPSD_00400]
Upstream requirements: RS_SOMEIPSD_00025
INITIAL_DELAY shall be defined as a minimum and a maximum delay.
[PRS_SOMEIPSD_00401]
Upstream requirements: RS_SOMEIPSD_00025
The wait time shall be determined by choosing a random value between the minimum
and maximum of INITIAL_DELAY.
INITIAL_DELAY 应该是个最大值和最小值 -- 实际耗时应该在这两个值之间。
[PRS_SOMEIPSD_00804]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall use the same random value, if ClientService and ServerService reference the same ClientServiceTimer and ServerServiceTimer, respectively, and if it its ensured that the referencing ClientService and ServerService, respectively, are requested and released in the same point in time.
[PRS_SOMEIPSD_00805]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall use different random values per ClientService and ServerService, if the ClientServices and ServerService referencing their own ClientServiceTimer and ServerServiceTimer, respectively. Thus, if a ClientService or ServerService enters the Initial Wait Phase, they shall use an individual calculated random value
within the Initial Wait Phase.
server端和client端的随机值 可以相同 或不同
[PRS_SOMEIPSD_00404]
Upstream requirements: RS_SOMEIPSD_00025
After sending the first message the Repetition Phase of this Service Instance/these
Service Instances is entered.
当发出第一条报文消息后就进入重复阶段了。
[PRS_SOMEIPSD_00405]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall wait in the Repetitions Phase based on REPETITIONS_BASE_DELAY.
重复阶段依赖 REPETITIONS_BASE_DELAY 变量的数值
[PRS_SOMEIPSD_00406]
Upstream requirements: RS_SOMEIPSD_00025
After each message sent in the Repetition Phase the delay is doubled.
重复阶段之间的消息间隔 是前一个的2倍
[PRS_SOMEIPSD_00407]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall send out only up to REPETITIONS_MAX entries during
the Repetition Phase.
REPETITIONS_MAX -- 需要客户指定
定义了重复阶段最多发送entries的次数
假设 REPETITIONS_BASE_DELAY 是 30ms REPETITIONS_MAX=3
find -- > 第一条报文 --》进去重复阶段
find -- > 第二条报文 --》和上条报文间隔30ms
find -- > 第三条报文 --》和上条报文间隔60ms
find -- > 第四条报文 --》和上条报文间隔120ms
[PRS_SOMEIPSD_00408]
Upstream requirements: RS_SOMEIPSD_00025
Sending Find entries shall be stopped after receiving the corresponding Offer entries
by jumping to the Main Phase in which no Find entries are sent.
client收到这个服务实例的 offer报文后，不能再发送这个服务实例的find报文，
要直接进入不会发送find报文的主阶段。
即一旦服务实例进入主阶段 就不能再发送find报文了。
[PRS_SOMEIPSD_00409]
Upstream requirements: RS_SOMEIPSD_00025
If REPETITIONS_MAX is set to 0, the Repetition Phase shall be skipped and the Main
Phase is entered for the Service Instance after the Initial Wait Phase.
REPETITIONS_MAX = 0 意味着没有重复阶段，退出初始化阶段后直接进入主阶段
[PRS_SOMEIPSD_00410]
Upstream requirements: RS_SOMEIPSD_00025
After the Repetition Phase the Main Phase is being entered for a Service Instance.
退出重复阶段 后 进入主阶段
[PRS_SOMEIPSD_00411]
Upstream requirements: RS_SOMEIPSD_00025
After entering the Main Phase, the provider shall wait 1*CYCLIC_OFFER_DELAY
before sending the first offer entry message.
CYCLIC_OFFER_DELAY -- 需要客户指定
进入主阶段后 要间隔 1*CYCLIC_OFFER_DELAY 时间发送offer报文
[PRS_SOMEIPSD_00412]
Upstream requirements: RS_SOMEIPSD_00025
In the Main Phase Offer Messages shall be sent cyclically if a
CYCLIC_OFFER_DELAY is configured.
CYCLIC_OFFER_DELAY 如果被客户指定设置
则主阶段的offer报文要按照这个时间间隔重复发送。
[PRS_SOMEIPSD_00413]
Upstream requirements: RS_SOMEIPSD_00025
After a message for a specific Service Instance the Service Discovery waits for
1*CYCLIC_OFFER_DELAY before sending the next message for this Service Instance.
[PRS_SOMEIPSD_00415]
Upstream requirements: RS_SOMEIPSD_00025
For Find entries (Find Service and Find Eventgroup) no cyclic messages are allowed
in Main Phase.
主阶段find报文不能发
[PRS_SOMEIPSD_00582]
Upstream requirements: RS_SOMEIPSD_00025
Subscribe EventGroup Entries shall be triggered by Offer entries, which are sent cyclically.
client每次收到server的循环offer消息后 都要订阅
[PRS_SOMEIPSD_00416]
Upstream requirements: RS_SOMEIPSD_00025
Example:
Initial Wait Phase:
• Wait for random_delay in Range(INITIAL_DELAY_MIN, _MAX)
• Send message (Find Service and Offer Service entries)
Repetition Phase (REPETITIONS_BASE_DELAY=100ms, REPETITIONS_MAX=2):
• Wait 2
2^0 * 100ms
• Send message (Find Service and Offer Service entries)
• Wait 2
2^1 * 100ms
• Send message (Find Service and Offer Service entries)
Main Phase:
• Server:
– as long message is active and CYCLIC_OFFER_DELAY is defined
∗ Wait CYCLIC_OFFER_DELAY
∗ Send message (Offer Service entries)
• Client:
– as long as offer service messages are received, Subscribe Eventgroup message is sent
举例说明比较容易理解
5.1.4.2 Server Answer Behavior 服务端应答行为
[PRS_SOMEIPSD_00417]
Upstream requirements: RS_SOMEIPSD_00025
The Service Discovery shall delay answers to entries that were received in multicast
SOME/IP-SD messages using the configuration item REQUEST_RESPONSE_DELAY.
This is valid for the following two cases:
• Offer entry (unicast or multicast) after received find entry (multicast)
• Subscribe entry (unicast) after received offer entry (multicast)
SD协议也规定了 应答延迟，分两种情况
收到offer 发送 sub
收到find 发送 offer
注意：此处不包含“收到sub 发送suback”的情况，也不包含上面两种情况采用 单播请求 对单播应答 的情况
[PRS_SOMEIPSD_00419]
Upstream requirements: RS_SOMEIPSD_00025
The REQUEST_RESPONSE_DELAY shall not apply if unicast messages are answered with unicast messages.
[PRS_SOMEIPSD_00420]
Upstream requirements: RS_SOMEIPSD_00025
REQUEST_RESPONSE_DELAY shall be specified by a minimum and a maximum.
REQUEST_RESPONSE_DELAY 要指定一个最大值和最小值，实际延时 再俩值中间
[PRS_SOMEIPSD_00421]
Upstream requirements: RS_SOMEIPSD_00025
The actual delay shall be randomly chosen between minimum and maximum of REQUEST_RESPONSE_DELAY.
[PRS_SOMEIPSD_00422]
Upstream requirements: RS_SOMEIPSD_00025
For basic implementations all Find Service entries shall be answered with Offer Service entries transported using unicast.
所有的回应find报文的 offer报文应该使用单播。
[PRS_SOMEIPSD_00423]
Upstream requirements: RS_SOMEIPSD_00025
For optimization purpose the following behaviors shall be supported as option:
• Find messages received with the Unicast Flag set to 1 in main phase, shall
be answered with a unicast response if the latest offer was sent less than 1/2
CYCLIC_OFFER_DELAY ago.
• Find messages received with the Unicast Flag set to 1 in main phase, shall
be answered with a multicast RESPONSE if the latest offer was sent 1/2
CYCLIC_OFFER_DELAY or longer ago.
Unicast Flag 设置为1 -- 需要客户指定
CYCLIC_OFFER_DELAY = 1s
offer发出 1秒后 再次发送下一包offer
如果 期间 新的client上线 发find包。
1》如果 时间过去了 小于 CYCLIC_OFFER_DELAY/2 ，即小于 0.5秒 ，则server回复需要用单播。
1》如果 时间过去了 大于等于 CYCLIC_OFFER_DELAY/2 ，即大于等于 0.5秒 ，则server回复需要用组播。
[PRS_SOMEIPSD_00843]
Upstream requirements: RS_SOMEIPSD_00025
Entries received with the unicast flag set to 0, shall not be answered with unicast but
ignored.
Unicast Flag 设置为0
server收到 find 用offer回复 不能用单播。或者 find包有问题选择忽略不回复。
5.1.4.3 Shutdown Behavior
[PRS_SOMEIPSD_00427]
Upstream requirements: RS_SOMEIPSD_00017, RS_SOMEIPSD_00012
When a server service instance of an ECU is in the Repetition and Main Phase and
is being stopped, a Stop Offer Service entry shall be sent out.
服务实例处于 重复、主阶段 --收到上层应用“停止服务”的请求后，需要发出 stop offer的报文
[PRS_SOMEIPSD_00751]
Upstream requirements: RS_SOMEIPSD_00017
When the link goes down for a server service instance in the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall enter the Down Phase and
reenter into Initial Wait Phase when the link is up again and the service is still available.
服务实例-- 服务端 工作期间 网络link 线路出现问题不通 到 后面又通 ，要重新走到 初始化阶段 继续
[PRS_SOMEIPSD_00752]
Upstream requirements: RS_SOMEIPSD_00017
When the link goes down for a client service instance in the Initial Wait Phase, Repetition Phase or Main Phase, the service discovery shall enter the Down Phase and
reenter into Initial Wait Phase when the link is up again and the service is still available..
服务实例-- 客户端 工作期间 网络link 线路出现问题不通 到 后面又通 ，要重新走到 初始化阶段 继续
[PRS_SOMEIPSD_00428]
Upstream requirements: RS_SOMEIPSD_00017
When a server sends out a Stop Offer Service entry all subscriptions for this service
instance shall be deleted on the server side.
服务端发起停止服务后 要清除已经订阅的所有客户端的列表信息 -- 编程指导
[PRS_SOMEIPSD_00429]
Upstream requirements: RS_SOMEIPSD_00017
When a client receives a Stop Offer Service entry all subscriptions for this service
instance shall be deleted on the client side.
客户端收到停止服务后 要清楚已经订阅的关系信息 -- 编程指导
[PRS_SOMEIPSD_00430]
Upstream requirements: RS_SOMEIPSD_00017
When a client receives a Stop Offer Service entry, the client shall not send out Find
Service entries but wait for Offer Service entry or change of status (application, network
management, Ethernet link, or similar).
当客户端收到停止服务报文后，不能再发送find报文，除非程序重启 网络link重启 或类似的状态重置。
[PRS_SOMEIPSD_00431]
Upstream requirements: RS_SOMEIPSD_00017
When a client service instance of an ECU is in the Main Phase and is being stopped
(i.e. the service instance is released), the SD shall send out Stop Subscribe Eventgroup entries for all subscribed Eventgroups.
如果client不再使用某个服务实例，则需要对已经订阅的server端发出停止订阅的报文。
[PRS_SOMEIPSD_00432]
Upstream requirements: RS_SOMEIPSD_00017
When the whole ECUs is being shut down Stop Offer Service entries shall be sent
out for all service entries and Stop Subscribe Eventgroup entries for Eventgroups.
当整个 ECU（Electronic Control Unit，电子控制单元） 关闭时，必须发送以下消息：
Stop Offer Service Entries：为所有服务实例发送 Stop Offer Service 消息。
Stop Subscribe Eventgroup Entries：为所有事件组（Eventgroup）发送 Stop Subscribe Eventgroup 消息。