SOME/IP-SD
1. 文档范围¶
服务发现（Service Discovery）的主要任务是管理车载通信中功能实体（称为服务（Service））的可用性（查找/提供），以及管理向网络发送事件消息的需求。这使得只向需要事件消息的接收者发送事件消息成为可能（发布/订阅）。
借助服务发现，不同的 ECU 可以提供服务实例（Service Instance）并在车辆网络中查找可用的服务实例。服务实例是由其服务接口定义的服务的一个具体实现。ECU 可以停止提供其之前提供的服务实例。之后对这类服务实例的查找将不再得到应答。在 AUTOSAR 上下文中，查找（find）是识别可用服务实例及其位置的操作。
本文档包含 SOME/IP 服务发现协议基于底层 SOME/IP 通信机制提供该功能所应满足的需求。
1.1. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[1]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[1]）。
2. 缩略语和缩写¶
以下收录与 SOME/IP 规范相关、且未被 [2, AUTOSAR glossary] 收录的缩略语和缩写。
Client
在本服务实例的上下文中，使用服务器的服务实例的 ECU 称为客户端（Client）。
Event
事件（Event）：仅在变化时或周期性调用的单向数据传输，从数据的生产者发送给消费者。
Eventgroup
事件组（Eventgroup）：服务内的事件以及字段的通知事件的逻辑分组，以允许订阅。
Field
字段（Field）：字段表示一种状态，因此在任意时刻都持有一个有效值，getter、setter 和 notifier 作用于其上。
Finding a service instance
查找服务实例（Finding a service instance）：发送 SOME/IP-SD 消息以找到所需的服务实例。
Getter
读取器（Getter）：允许对字段进行读访问的请求/响应调用。
Method
方法（Method）：被调用/调用的方法、过程、函数或子例程。
Notification Event
通知事件（Notification Event）：字段的通知器（Notifier）发出的事件消息。
Notifier
通知器（Notifier）：在字段的值发生变化时，发送带有新值的事件消息。
Offering a service instance
提供服务实例（Offering a service instance）：ECU 实现服务的一个实例，并通过 SOME/IP-SD 告知其他 ECU 可以使用它。
Server
在本服务实例的上下文中，提供服务实例的 ECU 称为服务器（Server）。
Service
服务（Service）：零个或多个方法、零个或多个事件以及零个或多个字段的逻辑组合。
Service Instance
服务实例（Service Instance）：服务的实现，可以在车辆中出现多次，也可以在一个 ECU 上出现多次。
Setter
写入器（Setter）：允许对字段进行写访问的请求/响应调用。
TTL
生存时间（Time-to-Live）
3. 需求¶
3.1. 通用¶
3.1.1. SOME/IP 服务发现协议应提供服务发现功能¶
SOME/IP 服务发现协议应提供服务发现功能。
| 描述 | SOME/IP 服务发现协议应提供在运行时发现服务和通信路径的功能。 |
|---|---|
| 理由 | 服务发现与基于服务的通信相结合，允许一种在系统设计阶段未预先定义的通信方式。 |
| 用例 | 合作伙伴之间的通信不在系统设计阶段静态定义。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.2. SOME/IP 服务发现协议应使用于 SOME/IP 协议之上¶
SOME/IP 服务发现协议应使用于 SOME/IP 协议之上。
| 描述 | SOME/IP 服务发现协议应使用于 SOME/IP 协议之上，以序列化并通信服务发现相关的消息。 |
|---|---|
| 理由 | SOME/IP 服务发现专注于基于 SOME/IP 的通信，公共功能只需设计和实现一次。 |
| 用例 | SOME/IP 服务的服务发现。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.3. SOME/IP 服务发现协议应支持单播消息¶
SOME/IP 服务发现协议应支持单播消息。
| 描述 | SOME/IP 服务发现协议应支持发送给恰好一个接收者的单播服务发现消息。 |
|---|---|
| 理由 | 单播消息是一种对某些接收者隐藏数据的机制，这些接收者无需为接收不需要的数据耗费处理资源。此外，在不包含任何接收者的交换网络分段中，带宽占用也会降低。 |
| 用例 | 提供服务的 SD 消息作为对查找消息的应答，发送给恰好一个接收者。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.4. SOME/IP 服务发现协议应支持多播消息¶
SOME/IP 服务发现协议应支持多播消息。
| 描述 | SOME/IP 服务发现协议应支持从一个发送者发送给多个接收者的多播服务发现消息。 |
|---|---|
| 理由 | 与单播相比带宽占用更低，因为当多个接收者应接收相同数据时，多播可以节省数据传输。 |
| 用例 | 提供服务的 SD 消息经由 IP 多播发送。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.5. SOME/IP 服务发现协议应支持 SOME/IP 和非 SOME/IP 服务¶
SOME/IP 服务发现协议应支持 SOME/IP 和非 SOME/IP 服务。
| 描述 | SOME/IP 服务发现协议应支持发布和订阅属于 SOME/IP 服务和非 SOME/IP 服务的数据。非 SOME/IP 服务可以使用 SOME/IP SD 发现和订阅，但之后在不使用 SOME/IP 的情况下使用。 |
|---|---|
| 理由 | 车辆中的所有服务都可以由同一服务发现协议协调。 |
| 用例 | 将服务发现用于既有通信和新通信 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.6. SOME/IP 服务发现协议应支持同一服务的不同版本¶
SOME/IP 服务发现协议应支持同一服务的不同版本。
| 描述 | SOME/IP 服务发现协议应支持同一服务具有不同功能等级的不同版本。 |
|---|---|
| 理由 | 新的 ECU 可以理解服务的多个版本，从而可以在较旧的车辆中复用。 |
| 用例 | 新 ECU 在较旧车辆中的复用。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.7. SOME/IP 服务发现协议应定义服务发现消息的格式¶
SOME/IP 服务发现协议应定义服务发现消息的格式。
| 描述 | SOME/IP 服务发现协议应定义服务发现报头和载荷的格式。 |
|---|---|
| 理由 | 需要定义报头和载荷，以使不同参与方之间能够进行服务发现通信。 |
| 用例 | 不同参与方之间的服务发现。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.8. SOME/IP 服务发现协议应为实现的合规性定义有序的特性集¶
SOME/IP 服务发现协议应为实现的合规性定义有序的特性集。
| 描述 | SOME/IP 服务发现协议应为提供不同功能等级的实现的合规性定义有序的特性集。最低等级应受到每个实现的支持。 |
|---|---|
| 理由 | 使资源较少的小型 ECU 能够以基本特性集参与服务发现。 |
| 用例 | 小型 ECU 实现的特性可以少于资源丰富的大型 ECU。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.9. SOME/IP 服务发现应以分布式方式运行¶
SOME/IP 服务发现应以分布式方式运行。
| 描述 | SOME/IP 服务发现应以分布式方式运行，没有集中式的服务目录。 |
|---|---|
| 理由 | 集中式服务目录会带来单一故障点，并可能成为性能瓶颈。 |
| 用例 | 单个 ECU 失效时的鲁棒性。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.10. SOME/IP 服务发现应支持可配置的时序¶
SOME/IP 服务发现应支持可配置的时序。
| 描述 | SOME/IP 服务发现应支持可配置的时序，以便在经过特定时间后启用状态变更。 |
|---|---|
| 理由 | 时间需要可配置，以满足不同的车载网络需求。 |
| 用例 | 周期性提供的周期的配置 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.1.11. SOMEIPSD 应按照 SOMEIP 协议对事件进行分组¶
SOMEIPSD 应按照 SOMEIP 协议对事件进行分组。
| 描述 | 将事件分组到 SOMEIPSD 事件组中应按照 SOMEIP 协议实现。 |
|---|---|
| 理由 | 服务发现基于 SOME/IP。 |
| 用例 | - |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2. 服务提供与查找¶
3.2.1. SOME/IP 服务发现协议应支持查找服务实例的位置¶
SOME/IP 服务发现协议应支持查找服务实例的位置。
| 描述 | SOME/IP 服务发现协议应支持在本地网络内查找服务实例的位置。 |
|---|---|
| 理由 | 通信伙伴需要知道服务的位置。 |
| 用例 | 与一个位置对另一方未知的服务实例通信。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.2. SOME/IP 服务发现消息应包含如何联系通信伙伴的信息¶
SOME/IP 服务发现消息应包含如何联系通信伙伴的信息。
| 描述 | SOME/IP 服务发现消息应包含如何联系通信伙伴的信息。该如何与通信伙伴交谈的信息应感知底层传输协议。 |
|---|---|
| 理由 | 为与远程伙伴建立通信，需要端点信息，这些信息取决于所使用的传输协议。 |
| 用例 | 并行支持 IPv4 和 IPv6。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.3. SOME/IP 服务发现协议应支持传输基于文本的服务名称¶
SOME/IP 服务发现协议应支持传输基于文本的服务名称。
| 描述 | SOME/IP 服务发现协议应在唯一标识符之外，支持传输（人类可读的）基于文本的服务名称。 |
|---|---|
| 理由 | 在调试期间，基于文本的名称更易于理解。 |
| 用例 | 调试期间对服务的人类可读标识。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.4. SOME/IP 服务发现协议应提供传输可选数据的支持¶
SOME/IP 服务发现协议应提供传输可选数据的支持。
| 描述 | SOME/IP 服务发现协议应提供在标准化数据之外传输可选数据的支持。 |
|---|---|
| 理由 | 在服务发现期间，可能需要额外的非标准化数据。 |
| 用例 | 基于附加条件的实例选择 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.5. SOME/IP 服务发现协议应提供负载均衡支持¶
SOME/IP 服务发现协议应提供负载均衡支持。
| 描述 | SOME/IP 服务发现协议应提供负载均衡支持，以均匀分布服务订阅。 |
|---|---|
| 理由 | 如果负载在系统设计阶段尚未完全明确，负载均衡可能是必要的。 |
| 用例 | 多个提供者向订阅者提供相同服务。负载应均匀均衡。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.6. SOME/IP 服务发现协议应支持检测服务实例是否活动¶
SOME/IP 服务发现协议应支持检测服务实例是否活动。
| 描述 | SOME/IP 服务发现协议应支持检测已发布的服务实例是活动的还是已终止的，并通知订阅者。 |
|---|---|
| 理由 | 服务可能非正常关闭；某些应用希望检测到这一点。 |
| 用例 | 非正常关闭的检测。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.7. SOME/IP 服务发现协议应支持提供已发布的服务¶
SOME/IP 服务发现协议应支持提供已发布的服务。
| 描述 | SOME/IP 服务发现协议应支持向本地网络内的其他通信伙伴主动提供已发布的服务。 |
|---|---|
| 理由 | 服务的主动传播。 |
| 用例 | 无需周期性查找消息即可检测可用服务 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.2.8. SOME/IP 服务发现协议应支持停止提供服务¶
SOME/IP 服务发现协议应支持停止提供服务。
| 描述 | SOME/IP 服务发现协议应支持主动停止提供服务以通知其他参与方。 |
|---|---|
| 理由 | 当已发布的服务正常终止时，有必要告知其他参与方该服务不再可用。 |
| 用例 | 已发布服务的正常终止 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3. 事件订阅¶
3.3.1. SOME/IP 服务发现协议应支持订阅事件¶
SOME/IP 服务发现协议应支持订阅事件。
| 描述 | SOME/IP 服务发现协议应支持订阅由服务实例提供的事件。 |
|---|---|
| 理由 | 基于服务的事件通信基于发布/订阅模式来控制通信。 |
| 用例 | 事件的接收 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.2. SOME/IP 服务发现协议应支持拒绝订阅¶
SOME/IP 服务发现协议应支持拒绝订阅。
| 描述 | SOME/IP 服务发现协议应支持主动拒绝请求的事件订阅。 |
|---|---|
| 理由 | 如果发布者无法向请求者提供所请求的事件，有必要将拒绝告知订阅者。 |
| 用例 | 防止发布者过载 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.3.3. SOME/IP 服务发现协议应支持停止对事件的订阅¶
SOME/IP 服务发现协议应支持停止对事件的订阅。
| 描述 | SOME/IP 服务发现协议应支持主动停止对已订阅事件的订阅。 |
|---|---|
| 理由 | 当接收方不再需要某个事件的数据时，需要停止该通信。 |
| 用例 | 另一方提供的事件不再被使用。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.4. 错误处理¶
3.4.1. SOME/IP 服务发现协议应支持服务提供者的重启检测¶
SOME/IP 服务发现协议应支持服务提供者的重启检测。
| 描述 | SOME/IP 服务发现协议应支持检测服务提供者是否被重启。 |
|---|---|
| 理由 | ECU 重启可能导致服务提供者丢失内部状态，进而导致数据不符合订阅者的预期。 |
| 用例 | ECU 重启的检测 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.4.2. SOME/IP 服务发现协议应标准化错误处理¶
SOME/IP 服务发现协议应标准化错误处理。
| 描述 | SOME/IP 服务发现协议应在出现意外情况时标准化错误处理。 |
|---|---|
| 理由 | 出现意外情况时需要优雅的错误处理。协议需要支持这一点，使应用能够对其作出反应。 |
| 用例 | 对错误的反应。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
3.4.3. SOME/IP 服务发现协议应支持 TTL¶
SOME/IP 服务发现协议应支持 TTL。
| 描述 | SOME/IP 服务发现协议应为可能随时间过期的服务发现功能（例如服务提供）支持 TTL。 |
|---|---|
| 理由 | TTL 可防止服务发现状态（例如某服务被提供）在状态更新（例如停止服务提供）因错误的实现、配置或系统中的其他错误而被遗漏时无休止地持续存在。 |
| 用例 | 将服务发现的错误状态限制在最长一段时间内。 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4. 参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
A. AUTOSAR 可追溯项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的可追溯项。这些可追溯项在文档中不作为超链接出现。
A.1. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.1.1. R23-11 中新增的需求¶
无
A.1.2. R23-11 中变更的需求¶
无
A.1.3. R23-11 中删除的需求¶
无