SOME/IP-SD -- 协议英文原文讲解7

embedded/2025/3/1 11:38:59/

前言
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 消息。
 


http://www.ppmy.cn/embedded/169042.html

相关文章

Qt关于平滑滚动的使用QScroller及QScrollerProperties类说明

一、触控时代的滚动工具&#xff1a;QScroller类设计介绍 1.1 从机械滚轮到数字惯性 在触控设备普及前&#xff0c;滚动操作如同老式打字机的滚轴&#xff0c;只能通过鼠标滚轮或滚动条进行离散式控制。QScroller的出现如同给数字界面装上了"惯性飞轮"&#xff0c;…

软件高级架构师 - 设计模式

六大原则 1. 单一职责原则 一个类只负责一项职责。 案例 餐厅中的厨师和服务员&#xff1a; 厨师的职责是做饭&#xff0c;服务员的职责是上菜。 如果让厨师同时负责做饭和上菜&#xff0c;会导致职责混乱&#xff0c;效率降低。 2. 开放-封闭原则&#xff08;OCP&#xff09…

配置Spring Boot中的Jackson序列化

配置Spring Boot中的Jackson序列化 在开发基于Spring Boot的应用程序时&#xff0c;Jackson是默认的JSON序列化和反序列化工具。它提供了强大的功能&#xff0c;可以灵活地处理JSON数据。然而&#xff0c;Jackson的默认行为可能无法完全满足我们的需求。例如&#xff0c;日期格…

React antd的datePicker自定义,封装成组件

一、antd的datePicker自定义 需求&#xff1a;用户需要为日期选择器的每个日期单元格添加一个Tooltip&#xff0c;当鼠标悬停时显示日期、可兑换流量余额和本公会可兑流量。这些数据需要从接口获取。我需要结合之前的代码&#xff0c;确保Tooltip正确显示&#xff0c;并且数据…

【Prometheus】prometheus服务发现与relabel原理解析与应用实战

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯,先赞后看哦~🎈🎈 🏆 作者简介:景天科技苑 🏆《头衔》:大厂架构师,华为云开发者社区专家博主,阿里云开发者社区专家博主,CSDN全栈领域优质创作者,掘金优秀博主,51CTO博客专家等。 🏆《博客》:Python全…

Android实现漂亮的波纹动画

Android实现漂亮的波纹动画 本文章讲述如何使用二维画布canvas和camera、矩阵实现二、三维波纹动画效果&#xff08;波纹大小变化、画笔透明度变化、画笔粗细变化&#xff09; 一、UI界面 界面主要分为三部分 第一部分&#xff1a;输入框&#xff0c;根据输入x轴、Y轴、Z轴倾…

【MySQL】数据库开发技术:内外连接与表的索引穿透深度解析

**前言:**本节内容主要讲解表的内连和外连以及索引的一部分。 注意&#xff1a; 索引是很重要的知识点。务必学习&#xff01;&#xff01;本节将会主要谈一谈什么是索引&#xff0c;如何理解索引。 以及怎么理解MySQL与磁盘的关系。 下面友友们开始学习吧&#xff01; ps&…

【北京迅为】iTOP-RK3568OpenHarmony系统南向驱动开发-第2章 内核HDF驱动框架架构

瑞芯微RK3568芯片是一款定位中高端的通用型SOC&#xff0c;采用22nm制程工艺&#xff0c;搭载一颗四核Cortex-A55处理器和Mali G52 2EE 图形处理器。RK3568 支持4K 解码和 1080P 编码&#xff0c;支持SATA/PCIE/USB3.0 外围接口。RK3568内置独立NPU&#xff0c;可用于轻量级人工…