ISO 17215-2-2014

第 2 部分：服务发现与控制

道路车辆 — 摄像头视频通信接口（VCIC）

1 范围


本文档规定了如何发现及控制服务。此功能主要位于 OSI 模型的第 5 层。发现及控制均通过使用可裁剪的 IP 上的面向服务的中间件 (SOME/IP) 实现。图 1 显示了这些方面及其与本国际标准的其他部分的关系。


Figure 1 — Overview of ISO 17215

在 ISO 17215-1 中被定义的通用术语也适用于本文档。

2 规范性引用


下列文件在本文中被引用，其部分或全部内容构成本文件的要求。凡是注日期的引用文件，仅其版本适用。凡是不注日期的引用文件，其最新版本（包括所有的修改）适用于本文件。

ISO 7498-1, Information processing systems — Open Systems Interconnection — Basic Reference Model: The Basic Model — Part 1 

ISO/IEC 10731, Information technology — Open Systems Interconnection — Basic Reference Model — Conventions for the definition of OSI services

ISO 17215 (all parts), Road vehicles — Video communication interface for cameras (VCIC) 

注意

本文档使用在 IETF RFC 2119 中被定义的关键字 shall、should 等来表示需求级别。这些关键字无需大写。

如果本文档引用的 RFC 已被一个或多个 RFC 更新，则该更新完全适用于本文档的实现。前提是该更新文档所描述的实现与本文档引用的文档所描述的实现兼容。

如果本文档引用的 RFC 已发布一个或多个勘误表，则所有这些勘误表均适用于本文档的实现。

应假定本文档的未来实现将引用 RFC 的最新版本，并保持与现有实现的（向后）兼容性。

3 术语、定义和缩写词


3.1 术语和定义

就本文档而言，ISO 17215-1 中的术语和定义及以下定义均适用。

3.1.1 AUTOSAR 

由汽车制造商、供应商和工具开发商共同开发的开放式标准化汽车软件架构。

3.1.2 客户端

使用服务实例（例如，对方法进行调用）的软件组件。

3.1.3 事件

被循环地触发，或当（状态）发生变化时被触发的即发即弃（fire and forget）消息，由服务器发送至客户端。

3.1.4 事件组

服务内部的对于事件或通知的逻辑分组，便于订阅。

3.1.5 字段（field）

表示一个远程属性，该属性最多可以包含一个 getter、一个 setter 和一个 notifier。

注意

getter/setter 是对字段值进行获取/设置的方法（method）。

3.1.6 即发即弃（fire and forget）通信

对 RPC 的调用仅包含请求消息。

3.1.7 接口

服务接口的具体规范（例如，采用 IDL 或 PDU 表示法）。

注意

对于 ISO 17215，对接口的定义被包含在 ISO 17215-3 中。

3.1.8 方法（method）

客户端可以调用的过程、函数或子程序。

3.1.9 通知

事件或字段（field）的 notifier 会循环地发送，或当（状态）发生变化时发送即发即弃（fire and forget）消息。

注意

无法对字段（field）消息或事件消息进行区分。因此，当提及事件消息时，也应包括（由 notifier 发出）字段（field）消息。

3.1.10 参数

方法（method）的输入参数、输出参数或输入/输出参数。

3.1.11 远程过程调用

通过消息在两个进程之间被传递的对方法（method）的调用。

3.1.12 请求

客户端向服务器发送的消息（对方法（method）的调用请求）。

3.1.13 请求/响应通信 

RPC 由请求和响应组成。

3.1.14 响应

服务器向客户端发送的消息（对方法（method）的调用请求的处理结果）。

3.1.15 服务器

提供服务实例（例如，提供方法（method））的软件组件。

3.1.16 服务

零个或多个方法（method）、零个或多个字段（field）以及零个或多个事件的逻辑组合。

3.1.17 服务实例

服务接口的实例，在车辆或 ECU 中可以存在多个实例。

3.1.18 服务接口

对服务的抽象描述，包括其方法（method）、事件及字段（field）。

3.1.19 联合体

能被动态地假定为不同数据类型的数据结构（也被称为变体）。

3.2 缩写词

Term
  • 描述
OSI
  • 开放式系统互连
PDU
  • 协议数据单元
RPC
  • 远程过程调用
ECU
  • 电子控制单元
IDL
  • 接口描述语言
AUTOSAR
  • 汽车开放式系统架构

4 约定


ISO 17215 基于 OSI 服务约定（ISO/IEC 10731）中规定的约定，适用于物理层、协议层、网络层和传输协议层以及诊断服务层。

5 概述


5.1 一般信息

ISO 17215 的制定旨在为车载摄像头实现标准化的视频通信接口。

ISO 17215 的重点在于利用现有的协议。

图 1 说明了 ISO 17215 与其他标准之间的关系。

图 2 说明了 ISO 17215 与现有的协议之间的关系。

5.2 文档概述和结构

本国际标准由四个子文件组成，并提供了所有参考资料和需求，以支持根据本标准实现的摄像头的视频通信接口。
  • ISO 17215-1：该文档概述了文档集和结构，以及用例的定义和一组供所有后续文档使用的通用资源（定义、引用文档）。
  • ISO 17215-2：该文档规定了对由 VCIC 摄像头提供的服务的发现和控制。
  • ISO 17215-3：该文档规定了 VCIC 摄像头使用的标准化摄像头消息和数据类型（OSI 第 7 层）。
  • ISO 17215-4：该文档规定了标准化底层通信（物理层、数据链路层、网络层和传输层（OSI 第 1 层至第 4 层）的实现）的需求。

5.3 开放式系统互连（OSI）模型

ISO 17215 基于在 ISO/IEC 7498 中被规定的开放式系统互连 (OSI) 基本参考模型，该模型将通信系统结构化为七层。

ISO 17215 的所有部分均遵循在 ISO/IEC 10731 中被规定的 OSI 服务约定，但仅限于适用于诊断服务的部分。这些约定通过服务原语定义了服务用户和服务提供者之间的交互。

本子条款旨在概述 OSI 模型，并说明如何将其作为本文档的指导原则。此外，本子条款还说明了 OSI 服务约定如何被应用于 ISO 17215。

OSI 模型将数据通信结构化为七层，从上到下依次为：应用层（第 7 层）、表示层、会话层、传输层、网络层、数据链路层和物理层（第 1 层）。ISO 17215 使用了这些层的子集。

每一层的目的都是向上一层提供服务。在 OSI 模型中，每一层的被激活的部分（软件、硬件或软硬件结合的实现）被称为实体。通信发生在同一层的实体（不同节点上）之间。同一层中相互通信的实体被称为对端实体。

可通过某一层的服务接入点 (SAP) 获取该层提供的服务。上层可以通过交换数据参数使用这些服务。

ISO 17215 对某一层向其上层提供的服务，以及该层中被用于在其中的对端实体之间传输消息的协议进行区分。目的是为了使服务（尤其是应用层和传输层的服务）能够被重用于除摄像头视频通信接口之外的其他类型的网络。这样，协议对于服务用户而言是隐藏的，并且根据特定的系统需求可以对其进行更改。

5.4 文档引用（根据 OSI 模型）

图 2 展示了引用的参考文档。


Figure 2 — Video communication interface for camera’s document reference according to OSI model

6 SOME/IP


6.1 一般信息

服务发现以及命令和控制均通过可裁剪的 IP 上的面向服务的中间件 (SOME/IP) 实现。SOME/IP 是一种轻量级 RPC 协议，它定义了一种与 AUTOSAR 兼容的方法，被用于描述接口以及在汽车以太网和 IP 网络上编组数据。AUTOSAR 已支持 SOME/IP 的有线格式的基本功能集。这使得 AUTOSAR 能够解析 RPC PDU 并将信号传输至应用程序。

6.2 报头

本子条款定义了报头结构。

出于互操作性的考虑，所有 SOME/IP 的实现的报头布局应相同，如图 3 所示。
  • 报头字段按传输顺序排列，即，左上角的报头字段首先被传输。以下各节将描述不同的报头字段及其用途。
  • 所有 RPC 报头字段均应使用网络字节序（大端序）[IETF RFC 791]。


Figure 3 — General SOME/IP header layout

6.2.1 消息 ID [32 位]

消息 ID 是一个 32 位（bit）的标识符，被用于将 RPC 调用分配给具体的应用程序的方法（method）以及对事件进行标识。

对消息 ID 的分配由用户决定。下一节将介绍如何构建消息 ID 以简化对其的组织。
  • 消息 ID 标识的方法（method）或事件及与其关联的 PDU 的格式应唯一。

为了组织不同的方法（method）和事件，它们被包含在服务中。服务包含一组方法（method）和事件，以及一个服务 ID，该 ID 仅被用于该服务。事件将被进一步地包含在事件组中，从而简化对多个事件进行订阅。
  • RPC 调用的消息 ID 由一个 16 位（bit）的服务 ID（高位字节）和一个 16 位（bit）的方法（method）ID（低位字节）组成。
  • 服务 ID 和方法（method）ID 应在接口规范中被指定。
  • 事件 ID 的最高位（bit）应始终为 1。

此方案最多支持 65536 个服务，每个服务最多支持 32767 个方法（method）和 32767 个事件。
  • 事件的消息 ID 由一个 16 位（bit）的服务 ID（高位字节）和一个 16 位（bit）的通知 ID（低位字节）组成。
  • 事件组 ID 和事件 ID 应在接口规范中被指定。
  • 事件组 ID 的最高位（bit）应始终为 1。

6.2.2 数据长度 [32 位]

数据长度字段为 32 位（bit），包含有效负载的数据长度（以字节为单位），有效负载的范围为，从请求 ID（客户端 ID/会话 ID）开始，到 SOME/IP 消息的末尾结束（数据长度不是整个消息的长度）。

6.2.3 请求 ID [32 位]

请求 ID 允许客户端对同一方法（method）的多次调用进行区分。
  • 对于单个客户端和单个服务器之间的通信，请求 ID 必须是唯一的。
  • 生成响应消息时，服务器应将请求中的请求 ID 复制到响应消息中。这样，即使存在多个未完成的请求，客户端也能对响应消息进行区分（与请求进行对应）。

请求 ID 需要被重新地构建。
  • 请求 ID 由 16 位（bit）客户端 ID（高位字节）和 16 位（bit）会话 ID（低位字节）组成。

客户端 ID 是 ECU 内部的发起请求的客户端的唯一标识符。会话 ID 是客户端为每次调用选择的唯一标识符。
  • 每个 ECU 中（发起请求的客户端）的客户端 ID 由制造商配置。
  • 如果预期不会收到响应消息（例如，对于事件或通知），则会话 ID 应被设置为 0x0000。
  • 如果预期会收到响应消息，则在同一生命周期内，每次对方法进行调用的会话 ID 都应递增（从 0x0001 开始，即使在被封包之后也是如此）。
  • 如有必要，客户端应负责取消对已过期的请求进行响应。

6.2.4 协议版本号 [8 位]

协议版本号字段为 8 位（bit），包含 SOME/IP 协议版本。
  • 协议版本号应被设置为 0x01。

6.2.5 接口主版本号 [8 位]

接口主版本号字段为 8 位（bit），包含服务接口的主版本号。这被用于检测服务定义中的不匹配的情况，并允许调试工具识别所使用的服务接口（参见 ISO 17215-3）。

6.2.6 消息类型 [8 位]

消息类型字段被用于区分不同类型的消息。
  • 消息类型应被设置为在表 2 中被列出的值之一。
  • 如果未发生错误，则对 REQUEST 消息的响应应为 RESPONSE 消息。
  • 如果发生错误，则对 REQUEST 消息的响应应为 ERROR 消息。
  • REQUEST_NO_RETURN 消息、NOTIFICATION 消息或任何 ACK 消息均不会被响应。


Table 2 — SOME/IP Message types

当传输协议（例如，UDP）无法确认消息是否被送达时，可以使用确认消息 (ACK)。

所有确认消息 (ACK) 都是可选的，并非强制实现。

6.2.7 返回码 [8 位]

返回码被用于指示请求是否已被成功地处理。为了简化报头布局，所有消息都会传输此字段，无论其是否适用。
  • 响应消息（消息类型 0x80）应通过返回码字段对请求进行响应。
  • 错误消息（消息类型 0x81）应通过返回码字段对请求进行响应，但不得使用返回码 0x00。
  • 确认消息应复用其响应的消息的返回码。
  • 所有其他消息应将返回码字段设置为 0x00。
  • 返回码基于 AUTOSAR 的 Std_ReturnType（8 位（bit））。最高两位为保留位，应被设置为零 (0)。返回码的接收方应忽略返回码的保留位（最高两位）。
  • 当前被定义的返回码在表 3 中被列出，并应按上述方式进行实现。


Table 3 — SOME/IP return codes

6.2.8 负载数据 [动态长度] 

负载数据字段中包含参数。对参数进行序列化的机制将在下一节中被详细地说明。

6.3 有线格式

有线格式描述了通过基于 IP 的汽车车载网络被传输的 PDU 中的数据表示。

6.3.1 传输

SOME/IP 直接支持互联网上两种最常用的传输协议：UDP（用户数据报协议）和 TCP（传输控制协议）。UDP 是一种非常精简的传输协议，仅支持其中最重要的功能（多路复用和通过校验和实现的错误检测），而 TCP 则添加了其他功能以实现可靠的通信。
  • SOME/IP 服务的端口号应由原始设备制造商 (OEM) 指定。
  • 如果对在错误发生时进行的延时有严格的要求（< 100 毫秒），则应使用 UDP。
  • 仅当需要传输大量的数据（> 1 KB）且对在错误发生时进行的延时没有严格的要求时，才应使用 TCP。
  • 接口规范中应记录每个方法（method）所使用的传输协议。
  • 方法（method）、事件和字段不应同时对多个传输协议进行支持。

与常规以太网结合使用时，IPv4 和 UDP 最多可以传输 1472 字节的数据而无需对数据进行分包。IPv6 报头需要额外的 20 字节。在小型系统中，应避免对数据进行分包，因此 SOME/IP 报头和负载数据的长度应受到限制。对安全协议的使用进一步地限制了 SOME/IP 消息的最大大小。TCP 允许对负载数据进行分包，但 AUTOSAR 目前对消息的大小限制为 4095 字节。

当其他传输机制（例如，网络文件系统、IEEE 1722 等）更适合特定的用例时，也可以使用它们。在这种情况下，SOME/IP 仅被用于对文件句柄或类似的信息进行传输。

6.3.1.1 UDP 绑定

车内许多应用所需的超时时间较短（以实现快速响应）。使用 UDP 更能满足这些需求，因为应用本身可以灵活地处理极少发生的错误，而无需对数据包进行分包，因此只能传输少量数据。
  • 通过 UDP 传输的 SOME/IP 消息最多可以使用 1416 字节的 SOME/IP 报头和负载数据。
  • 报头格式允许在单个 UDP 数据包中传输多个 SOME/IP 消息。SOME/IP 的实现应通过 SOME/IP 数据长度字段标识 SOME/IP 消息的结束位置。SOME/IP 应根据 UDP 数据长度字段判断 UDP 数据包中是否还存在其他 SOME/IP 消息。SOME/IP 消息可以不进行字节对齐。
  • 每个 SOME/IP 负载数据都应有自己的 SOME/IP 报头。
  • 如果在接口定义中存在相关的指定信息，SOME/IP 应在需要较长时间的处理结果可用之前发送确认消息（对处理的确认）。

6.3.1.2 TCP 绑定

SOME/IP 的 TCP 绑定很大程度上基于 UDP 绑定。与 UDP 绑定相比，TCP 绑定允许更大的 SOME/IP 消息，并支持批量传输大量 SOME/IP 消息（流水线）。TCP 不仅可以处理位（bit）错误，还可以处理分包、丢包、数据重复、重排序和网络拥塞。
  • 基于 TCP 传输的 SOME/IP 消息（包括 SOME/IP 头部）不得超过 4095 字节。
  • 每个 SOME/IP 负载数据都必须有自己的 SOME/IP 头部。
  • 为了降低延迟和响应时间，应禁用 Nagle 算法（TCP_NODELAY）。
  • 当 TCP 连接断开时，未完成的请求将被视为超时。否则，TCP 应保证数据包已被送达，因此无需采取额外的鲁棒性措施。
  • 当客户端首次传输对方法的调用或尝试接收首个通知时（取决于具体出现的情况），客户端应建立 TCP 连接。
  • 为了在测试和集成场景中通过 TCP 实现 SOME/IP 协议中的重新同步，需要在基于 TCP 传输的 SOME/IP 消息之间使用 SOME/IP Magic Cookie 消息（图 4）。
  • Magic Cookie 消息的服务 ID 为 0xFFFF，方法 ID 分别为 0x0000（客户端至服务器）和 0x8000（服务器至客户端）。
  • Magic Cookie 消息的长度为 8 字节，客户端 ID 被固定为 0xDEAD，会话 ID 被固定为 0xBEEF。协议版本号为 0x01，接口主版本号为 0x01，消息类型分别为 0x01（客户端至服务器）和 0x02（服务器至客户端），返回码为 0x00。
  • 在传输首个基于 TCP 传输的 SOME/IP 消息之前，必须包含 SOME/IP Magic Cookie 消息。
  • 每个 TCP 分包最多只能包含一个 SOME/IP Magic Cookie 消息。
  • 如果具体实现无法适当地处理消息分包机制（因此无法满足前两个要求），则具体实现就应每 10 秒在通过此 TCP 连接被传输的消息中包含 SOME/IP Magic Cookie 消息。


Figure 4 — SOME/IP magic cookie

6.3.2 IP 地址和端口的映射

对于响应消息和错误消息，所使用的传输协议的 IP 地址和端口号必须与请求消息匹配。具体而言，这意味着：
  • 响应消息的源 IP 地址必须与对应的请求消息的目标 IP 地址一致。
  • 响应消息的目标 IP 地址必须与对应的请求消息的源 IP 地址一致。
  • 响应消息的源端口必须与对应的请求消息的目标端口一致。
  • 响应消息的目标端口必须与对应的请求消息的源端口一致。

6.4 参数序列化

序列化过程的一个重要方面是参数的内存对齐（字节对齐）。这意味着不同数据类型的存储地址的值应该是其数据大小（字节）的整数倍，例如，float32 参数的存储地址的值应该能被 4 整除（float32 参数的数据大小为 4 字节）。
  • 序列化过程不应尝试自动地对参数进行内存对齐（字节对齐），而应按照接口规范中的规定进行对齐。
  • 如果 SOME/IP 的具体实现遇到导致 PDU 无法被正确地对齐的接口规范（例如，由于未对结构体进行对齐），则 SOME/IP 的具体实现应发出结构体未被对齐的警告，但不应导致代码生成失败。
  • 应在接口规范中将参数标记为 IN、OUT 或 INOUT。
  • 对于客户端至服务器的消息，序列化/反序列化的过程应跳过 OUT 参数。
  • 对于服务器至客户端的消息，序列化/反序列化的过程应跳过 IN 参数。
  • 每个参数的字节序应由接口定义指定。应尽可能地使用网络字节序（大端序）。

6.4.1 基本数据类型

应对以下基本数据类型进行支持：


Table 4 — SOME/IP data types

6.4.2 结构化数据类型

对结构体的序列化基于其内存布局。对于结构体而言，内存对齐尤为重要。如有必要应进行对齐，可在接口定义中插入填充元素。图 5 给出了一个示例。
  • 接口规范可以在结构体前面添加一个 8 位（bit）、16 位（bit）或 32 位（bit）的数据长度字段。
  • 数据长度字段描述了要传输的字节数。如果接口定义中指定的结构体大小小于由数据长度字段指定的长度，则在反序列化时应跳过末尾的额外字节。这样做是为了方便接口的移植。
  • 如果未指定数据长度字段的数据长度，则应假定其数据长度为 0，并且在消息中不应包含数据长度字段。


Figure 5 — Serialization of structures

6.4.3 数组

数组应被视为重复的元素。应支持多维数组。SOME/IP 同时支持固定长度的数组和动态长度的数组。固定长度的数组灵活性较差，但效率更高，并且在早期版本的 AUTOSAR 中被更好地支持。

注意

对多维数组的序列化应遵循 C 语言中多维数组的内存布局（行优先顺序）。

6.4.3.1 固定长度的数组

固定长度的数组的大小（以字节为单位）应由接口定义指定。图 6 展示了一个二维数组的示例布局。


Figure 6 — Fixed-size multidimensional array memory layout

6.4.3.2 动态长度的数组

动态长度的数组的布局与固定长度的数组的相同，只是多了显式的数据长度字段。
  • 为了确定数组的长度，序列化过程会在数据前面添加一个 8 位（bit）、16 位（bit）或 32 位（bit）的数据长度字段，被用于计算数组的总字节数。
  • 数组的长度不包括数据长度字段。
  • 每一行都有自己的数据长度字段。
  • 除非接口规范中另有规定，否则数据长度字段的数据大小应为 32 位（bit）。
  • 接口定义应定义每个维度的最大长度，以便对静态缓冲区进行分配。

因此，当传输一个不包含元素的数组时，其长度将被设置为零。动态长度的数组的内存布局如图 7 所示。


Figure 7 — Dynamic-size multidimensional array memory layout 

6.4.3.2.1 可选字段

可选字段应在接口定义中被指定为动态长度的数组。其长度将为 0 或 1，具体取决于参数是否存在。

6.4.3.2.2 映射/字典

映射或字典应被描述为动态长度的数组（元素类型为键值对）。表 5 给出了这种重要数据结构的一个示例。


Table 5 — Serialized dictionary example

6.4.4 字符串

字符串本质上是采用 UTF-8 编码的一维数组（元素类型为字节）。由于这种编码方式的每个字符占用的字节数是可变的，因此字符串的数据长度（字节）与字符数并不相等。最坏的情况下，UTF-8 编码的字符串的数据长度（字节）可能是其字符数的三倍，再加上结尾的“\0”和字节序标记 (BOM)（4 字节）。所有字符串都必须以字节序标记 (BOM) 开头。

6.4.4.1 字符串（固定长度）

以下规则适用于固定长度的字符串。
  • 字符串应使用 UTF-8、UTF-16 BE 或 UTF-16 LE 编码，并以空字符 (NULL) 结尾。
  • 字符串的数据长度（包括终止符）应在接口定义中被指定（以字节为单位）。
  • 未被使用的空间应被填充空字符 (NULL) 字符。

6.4.4.2 字符串（动态长度）

以下规则适用于动态长度的字符串。
  • 动态长度的字符串应以数据长度字段开头。
  • 数据长度字段的数据长度可以是 8 位（bit）、16 位（bit）或 32 位（bit）。固定长度的字符串的数据长度字段的数据长度可被视为 0 位（bit）。
  • 除非接口规范中另有规定，否则数据长度字段的数据长度为 32 位（bit）。
  • 字符串应使用 UTF-8、UTF-16 BE 或 UTF-16 LE 编码，并以空字符 (NULL) 结尾。
  • 数据长度字段应被设置为字符串（包括终止符）的数据长度（以字节为单位）。
  • 字符串（包括终止符）的最大数据长度（以字节为单位）应在接口定义中被指定。

6.4.5 联合体/变体

联合体（也被称为变体）是一种参数，其内容可以被解释为不同的数据格式。
  • 联合体的序列化布局应包含数据长度字段、数据类型字段以及参数占用的存储空间。
  • 数据长度字段对参数占用的存储空间的大小（包括偏移填充）进行定义（以字节为单位），但不包括数据长度字段和数据类型字段。
  • 数据类型字段指定参数的类型。数据类型字段的可能的值由接口规范为每个联合体单独地定义。对不同类型的数据的编码方式与接口规范中的编码方式相同，从数据类型字段为 1 的数据开始按升序排列（数据类型字段由小到大）。数据类型字段的值 0 被保留给 NULL 类型，即空联合体。接口定义应允许使用 NULL 值。
  • 数据长度字段的数据长度由接口规范定义，可以是 32 位（bit）、16 位（bit）、8 位（bit）或 0 位（bit）。
  • 数据长度字段的值由接口规范定义。该值应足够大，以容纳可能的最大数据类型。
  • 数据长度字段的数据长度为 0 位（bit）表示不应向 PDU 写入任何数据长度字段。在这种情况下，联合体中的所有数据类型的数据长度必须相同。
  • 如果接口规范未指定联合体的数据长度字段的数据长度，则数据长度字段的数据长度应为 32 位（bit）。
  • 数据类型字段的数据长度应由接口规范定义，且必须为 32 位（bit）、16 位（bit）或 8 位（bit）。
  • 如果接口规范未指定联合体的数据类型字段的数据长度，则数据类型字段的数据长度应为 32 位（bit）。
  • 如果遇到无效的数据类型字段，则应上报 E_MALFORMED_MESSAGE 错误。
  • 应根据参数的数据类型对其进行序列化/反序列化。
  • 序列化处理应根据数据长度字段对数据类型字段进行设置，并在必要时在元素后添加偏移填充。
  • 如果给定的长度大于该类型的数据长度字段，则反序列化处理应跳过剩余的（多出）字节。

以下示例展示了联合体（uint8 或 uint16）的组织方式，按 32 位（bit）进行偏移填充。接口规范定义了 uint8 和 uint16 的联合体类型，两者都按 32 位（bit）进行偏移填充（数据长度字段为 4）。


Table 6 — Serialization of a uint8 (type 0 is the undefined union)


Table 7 — Serialization of a uint16

6.4.6 枚举

接口定义应指定基于无符号整数的数据类型（uint8、uint16、uint32、uint64）的枚举。

7 Service discovery protocol specification 


7.1 General 

In the closed environment of the vehicle, the implemented services and their location are already known a-priori; thus, the service discovery is not used for discovering the location of a service, but its availability. This can be used to communicate whether an Electronic Control Unit (ECU) is running and a service is ready. In addition, the service discovery enables service migration, a feature that can prove valuable for handling optional equipment and implementing power saving strategies. 

7.2 Definitions

Offering a service instance shall mean that one ECU implements an instance of a service and tells other ECUs using SOME/IP-SD that they can use it. 

Finding a service instance shall mean to send a SOME/IP-SD message in order to find a needed service instance 

Requiring a service instance shall mean to send a SOME/IP-SD message to the ECU implementing the required service instance to signal that this service instance is needed by the other ECU. In case the service is not running, the receiving ECU should start it. 

Releasing a service instance shall mean to send a SOME/IP-SD message to the ECU hosting this service instances, with the meaning that the service instance is no longer needed. 

Publishing an eventgroup shall mean to offer an eventgroup of a service instance to other ECUs using a SOME/IP-SD message. 

Subscribing an eventgroup shall mean to require an eventgroup of a service instance using a SOME/IP-SD message. 

A service status of up shall mean that a service instance is available; thus, it can be accessed using the communication method specified and is able to fulfil its specified function. 

A service status of down shall mean the opposite of the service status up. 

A service status of required shall mean that service instance is needed by at least one other software component in the system to function. 

A service status of released shall mean the opposite of the service status required.

7.3 General requirements 

It is assumed that IP addresses for all devices have already been assigned at this stage. See ISO 17215-4 for details on the address assignment process. Dynamic address assignment is done via DHCP. Special emphasis is placed on keeping the start-up time of the system as short as possible.
  • Service discovery messages shall be supported over UDP.
  • Service discovery messages shall use the Service ID of 0xFFFF.
  • Service discovery messages shall use the Method ID of 0x8100.
  • Service discovery messages shall have a Client ID and handle it based on SOME/IP rules.
  • Service discovery messages shall have a Session ID and handle it based on SOME/IP rules.
  • Service discovery messages shall have a protocol version of 0x01 and an interface version of 0x01.
  • Service discovery messages shall use the message type notification (0x02) and the corresponding return code 0x00.
  • Different instances of the same service within the same vehicle shall have different Instance IDs.
  • Instance IDs shall be 16-bit unsigned integers (uint16). For further details, see 8.2.3.
  • Instance ID 0x0000 shall not be used
  • Instance ID 0xFFFF shall mean “All service instances”.
  • An event group shall be identified using the Eventgroup ID.
  • Eventgroup IDs shall be 16-bit unsigned integers (uint16).
  • Different event groups within the same service shall have different Eventgroup IDs.

Event groups are logical groupings of zero or more events. There are only relevant for SOME/IP-SD to allow easy subscription of multiple events. However, in the actual notifications sent later, only the EventID is present. 

Sequence charts for an example use cases can be seen in Figure 8 and Figure 19.


Figure 8 — Service call example

7.4 Service discovery ECU-internal interface 

Inside each SOME/IP-SD capable ECU, one SOME/IP-SD implementation shall be running and provide certain functionality to local services.
  • The service discovery interface shall inform local software components about the status of remote services (up/down).
  • The service discovery interface shall offer the option to local software component to require or release a remote service instance (and then send the required SOME/IP-SD messages).
  • The service discovery interface shall inform local software components of the require/release status of local services.
  • The service discovery interface shall offer the option to local software component to set a local service status (up/down).
  • Eventgroup status shall be defined in the same way the service status is defined.
  • In addition to the operations of the services the eventgroups shall start sending events on being required.
  • The service discovery shall be informed of link-up and link-down events of logical, virtual, and physical communication interfaces that the service discovery is bound to.
  • The service discovery of an ECU shall keep the current state of the service instances this ECU offers as well as of the service instances other ECU offer as well as service instance it needs from other ECUs.
  • As optimization, the service discovery shall support keeping only state of service instances that are configured and/or dynamically signalled inside the local ECU.

7.5 Packet format 

Service discovery is performed with help of RPC requests to a reserved SOME/IP message ID in conjunction with an extended SOME/IP header including entries and options. This extended header is shown in Figure 9, the entry layout in Figure 11, and example option layouts in Figure 12.


Figure 9 — SOME/IP service discovery packet format

For service discovery, the standard SOME/IP header is followed by the SOME/IP-SD header.
  • The SOME/IP-SD header shall begin with an 8-bit field called flags. Only the two highest bits are currently used.
    • Bit 7 of the flag field is the reboot bit. It shall be 1 when the ECU boots and 0 once the Session ID has wrapped around.
    • Bit 6 of the flag field is the unicast bit. It indicates that it is acceptable to reply with a unicast message (see 8.2.1 for further details).
  • The unicast flag shall be set to 1 for request messages, subscribe messages, and SubscribeEventgroupAck messages.
  • After the flags, the SOME/IP-SD header shall contain 24 reserved bits.
  • The SOME/IP-SD header shall be followed by the entries array and the options array.
  • The entries array and the options array shall be encoded like SOME/IP arrays, and thus, start with length fields as uint32.
  • The length field shall be encoded as the array length field, counting the number of bytes of the array without the length field itself.

7.5.1 Entry records 

One SOME/IP service discovery message can contain multiple entries. Each entry record can reference up to two option arrays. The first run is meant to be used for options common to multiple entries, while the second run is meant to be used for options that are only relevant for this one entry. Multiple options can, for example, be used to announce IPv4 and IPv6 addresses simultaneously, or to include additional configuration data with an announcement.

  • Every entry of the array shall be of type A (concerning services) (see Figure 10) or type B (concerning eventgroups) (see Figure 11).
  • A type A entry shall be 16 bytes in size and include the following fields in this order:
    • Type field [uint8]: Encodes FindService (0x00),OfferService (0x01) and RequestService (0x02).
    • Index first option run [uint8]: Index of the first option of the first option run in the option array.
    • Index second option run [uint8]: Index of the first option of the second option run in the option array.
    • Number of options 1 [uint4]: Describes the number of options the first option run uses. Zero means no options (empty run).
    • Number of options 2 [uint4]: Describes the number of options the second option run uses. Zero means no options (empty run).
    • If the first option run is empty, the second option run shall be empty as well.
    • If an option run is empty, the index of the first option can be non-zero.
    • Service ID [uint16]
    • Instance ID [uint16]
    • Major version [uint8]
    • TTL [uint24]: Describes the lifetime of the entry in seconds.
    • Minor version [uint32]
  • A type B entry shall be 16 bytes in size and include the following fields in this order:
    • Type field [uint8]: Encodes FindEventgroup (0x04), Publish (0x05), SubscribeEventgroup (0x06), SubscribeEventgroupAck (0x07).
    • Index first option run [uint8]: Index of the first option of the first option run in the option array.
    • Index second option run [uint8]: Index of the first option of the second option run in the option array.
    • Number of options 1 [uint4]: Describes the number of options the first option run uses. Zero means no options (empty run).
    • Number of options 2 [uint4]: Describes the number of options the second option run uses. Zero means no options (empty run).
    • If the first option run is empty, the second option run shall be empty as well.
    • If an option run is empty, the index of the first option can be non-zero.
    • Service ID [uint16]
    • Instance ID [uint16]
    • Major version [uint8]: Encodes the major version of the service instance this eventgroup is part of.
    • TTL [uint24]: Describes the lifetime of the entry in seconds.
    • Reserved [uint16]: Shall be set to 0x0000.
    • Eventgroup ID [uint16]


Figure 10 — SOME/IP SD entry layout type A


Figure 11 — SOME/IP SD entry layout type B

7.5.1.1 FindService and StopFindService (optional) 

The Find Service entry type shall be used for finding service instances and shall only be sent if the current state of a service is unknown (no current service offer was received and is still being valid). If the service in question is not available, there is no response.
  • Type shall be set to 0x00 (FindService).
  • Service ID shall be set to the Service ID of the service that shall be found.
  • Instance ID shall set to 0xFFFF, if all service instances shall be returned. If set to the Instance ID of a specific service instance, just this single service instance shall be returned.
  • Major version shall be set to 0xFF. That means that services with any version shall be returned. If set to value different than 0xFF, services with this specific major version shall be returned only.
  • Minor version shall be set to 0xFFFF FFFF. That means that services with any version shall be returned. If set to a value different to 0xFFFF FFFF, services with this specific minor version shall be returned only.
  • TTL shall be set to the lifetime of the find service entry. After this lifetime, the find service entry shall be considered as not existing.
  • If set to 0xFFFFFF, the find service entry shall be considered valid for ever.
  • The StopFindService feature is optional.
  • The Stop Find Service entry type shall be used to stop finding service instances.
  • Stop find service entries shall be used in communication with service directories.
  •  Stop find service entries shall set the header fields exactly like the find service entry they are stopping, except that TTL shall be set to 0x000000.

7.5.1.2 OfferService and StopOfferService 

The Offer Service entry type shall be used to offer a service to other communication partners.
  • Type shall be set to 0x01 (OfferService).
  • Service ID shall be set to the Service ID of the service instance offered.
  • Instance ID shall be set to the Instance ID of the service instance offered.
  • Major version shall be set to the major version of the service instance offered.
  • Minor version shall be set to the minor version of the service instance offered.
  • TTL shall be set to the lifetime of the service instance. After this lifetime, the service instance shall be considered as not offered.
  • If set to 0xFFFFFF, the Offer Service entry shall be considered valid forever.
  • The Stop Offer Service entry type shall be used to stop offering service instances.
  • Stop Offer Service entries shall set the header fields exactly like the Offer Service entry they are stopping, except that TTL shall be set to 0x000000.

7.5.1.3 RequestService (optional) and StopRequestService (optional) 

The Request Service entry type shall be used to indicate that a service instance is required.
  • The RequestService and the StopRequestService features are optional.
  • An ECU shall consider a Request Service entry as a reason to start the specified service instance if configured to do so.
  • Type shall be set to 0x02 (RequestService).
  • Service ID shall be set to the Service ID of the service instance requested.
  • Instance ID shall be set to the Instance ID of the service instance requested.
  • Major version shall be set to 0xFF (any version).
  • Minor version shall be set to 0xFFFF FFFF (any version).
  • TTL shall be set to the lifetime of the request. After this lifetime, the service request shall be considered non-existing. This can lead to an ECU shutting down a service previously requested.
  • If set to 0xFFFFFF, the Request Service entry shall be considered valid for ever.
  • The Stop Request Service entry type shall be used to stop requests.
  • Stop Offer Request entries shall set the header fields exactly like the Request Service entry they are stopping, except that TTL shall be set to 0x000000.

7.5.1.4 FindEventgroup (optional) and StopFindEventgroup (optional) 

The Find Eventgroup entry type shall be used for finding eventgroups
  • The FindEventgroup and the StopFindEventgroup features are optional.
  • Type shall be set to 0x04 (FindEventgroup).
  • Service ID shall be set to the Service ID of the service that includes the eventgroup that shall be found.
  • Instance ID shall set to 0xFFFF, if eventgroups of all service instances shall be returned. It shall be set to the Instance ID of a specific service instance, if just the eventgroup of a single service instance shall be returned.
  • Major version shall be set to 0xFF, meaning that eventgroups of services with any version shall be returned. If set to value different than 0xFF, eventgroups of services with this specific major version shall be returned only.
  • Minor version shall be set to 0xFFFF FFFF, meaning that eventgroups of services with any version shall be returned. If set to a value different to 0xFFFF FFFF, eventgroups of services with this specific minor version shall be returned only.
  • TTL shall be set to the lifetime of the Find Eventgroup entry. After this lifetime, the Find Eventgroup entry shall be considered as not existing.
  • If set to 0xFFFFFF, the FindEventgroup entry shall be considered valid for ever.
  • Eventgroup ID shall set to the ID of the eventgroup that is being looked for. Setting the Eventgroup ID to 0xFFFF (all eventgroups) is currently not recommended, but when receiving an Eventgroup ID of all, the ECU shall answer for all Eventgroups.
  • The Stop Find Eventgroup entry type shall be used to stop finding eventgroups.
  • Stop Find Eventgroup entries shall be used in communication with service directories.
  • Stop Find Eventgroup entries shall set the header fields exactly like the Find Eventgroup entry they are stopping, except that TTL shall be set to 0x000000.

7.5.1.5 PublishEventgroup (optional) and StopPublishEventgroup (optional) 

The Publish Eventgroup entry type shall be used to offer a eventgroup to other communication partners.
  • The PublishEventgroup and the StopPublishEventgroup features are optional.
  • Type shall be set to 0x05 (PublishEventgroup).
  • Service ID shall be set to the Service ID of the service instance that includes the eventgroup published.
  • Instance ID shall be set to the Instance ID of the service instance that includes the eventgroup published.
  • Major version shall be set to the major version of the service instance that includes the eventgroup published.
  • Minor version shall be set to the minor version of the service instance that includes the eventgroup published.
  • TTL shall be set to the lifetime of the eventgroup. After this lifetime, the eventgroup shall considered not been published.
  • In most use cases, eventgroups will have the same lifetime as the service instance they are part of. A longer lifetime of the eventgroup than the lifetime of the service instance it is part of shall not be allowed.
  • If set to 0xFFFFFF, the Publish Eventgroup entry shall be considered valid for ever.
  • Eventgroup ID shall be set to the ID of the eventgroup.
  • The Stop Publish Eventgroup entry type shall be used to stop publishing eventgroups.
  •  Stop Publish Eventgroup entries shall set the header fields exactly like the Publish Eventgroup entry they are stopping except that TTL shall be set to 0x000000.

7.5.1.6 SubscribeEventgroup and StopSubscribeEventgroup 

The Subscribe Eventgroup entry type shall be used to subscribe to an eventgroup. This can be considered comparable to the Request Service entry type. Subscribe Eventgroup entries shall reference one or two IPv4 and/or one or two IPv6 endpoint options (one for UDP, one for TCP).
  • Type shall be set to 0x06 (SubscribeEventgroup).
  • Service ID shall be set to the Service ID of the service instance that includes the subscribed eventgroup.
  • Instance ID shall be set to the Instance ID of the service instance that includes the subscribed eventgroup.
  • Major version shall be set to the major version of the service instance that includes the subscribed eventgroup.
  • Minor version shall be set to the minor version of the service instance that includes the subscribed eventgroup.
  • TTL shall be set to the lifetime of the subscription. After this lifetime, the eventgroup shall be considered not subscribed.
  • If set to 0xFFFFFF, the SubscribeEventgroup entry shall be considered valid for ever.
  • Eventgroup ID shall be set to the Eventgroup ID of the eventgroup subscribed to.
  • The Stop Subscribe Eventgroup entry type shall be used to stop subscribing to eventgroups.
  • Stop Subscribe Eventgroup entries shall set the header fields exactly like the Subscribe Eventgroup entry they are stopping, except that TTL shall be set to 0x000000.

7.5.1.7 SubscribeEventgroupAck and SubscribeEventgroupNack 

The Subscribe Eventgroup Acknowledgement entry type shall be used to indicate that SubscribeEventgroup was accepted.
  • Type shall be set to 0x07 (SubscribeEventgroupAck).
  • Service ID, Instance ID, major version, minor version, and TTL shall be the same value as in the subscription that is being answered.
  • The Subscribe Eventgroup Negative Acknowledgement entry shall be used to indicate that a SubscribeEventgroup entry was not accepted.
  • SubscribeEventgroupNack entries shall set the header fields exactly like SubscribeEventgroupAck entries, except that TTL shall be set to 0x000000.

7.5.2 Option records 

Option records have a different layout depending on their type. Options are used to transport additional information to the entries. There are options for text-based configuration parameters and IPv4/IPv6 endpoints. In order to identify the option type, every option shall start with:
  • Length [uint16]: Specifies the length of the option in bytes.
  • Type [uint8]: Specifying the type of the option.
  • Based on the SOME/IP Union format, the length field shall not cover the size of the length field and type field.

7.5.2.1 Configuration option 

The configuration option specifies a set of key-value pairs. The format of the configuration option shall be as follows:
  • Length [uint16]: Shall be set to the total number of bytes occupied by the configuration option, excluding the 16-bit length field and the 8-bit type flag.
  • Type [uint8]: Shall be set to 0x01.
  • Reserved [uint8]: Shall be set to 0x00.
  • Each key-value pair shall start with an 8-bit length field that contains the number of bytes occupied by the pair (maximum length for a single pair is thus 255 bytes).
  • After each byte sequence, another length field and following byte sequence are expected until a length field is set to 0x00.
  • A byte sequence shall encode a key and optionally value.
  • The separator between the name and value shall be the equal sign (“=”, 0x3D).
  • The key shall consist of only printable ASCII characters (0x20 to 0x7F). It shall not include an equal sign and shall contain at least one non-whitespace character.
  • For a byte sequence without an ‘ = ‘ sign, that key shall be interpreted as present.
  • For a byte sequence ending on an ‘ = ‘ sign, that key shall be interpreted as present with empty value.
  • The individual key-value pairs shall not be zero-terminated (but the complete configuration string is).

The configuration option shall also be used to provide a hostname, servicename, and an instancename (if needed).


Figure 12 — SOME/IP SD configuration option layout

7.5.2.2 IPv4 endpoint option 

If IPv4 is required for the service, the IPv4 endpoint option shall be used by a SOME/IP-SD instance to signal the relevant endpoint(s). Endpoints include the local IP address, the transport layer protocol (UDP or TCP), and the port number of the sender. 

These ports shall be used for the events and notification events as well. When using UDP, the server uses the announced port as source port; and with TCP, the client needs to open a connection to this port before subscription, so that the server can use this TCP connection.

The format of the IPv4 endpoint option shall be as follows.
  • Length [uint16]: Shall be set to 9.
  • Type [uint8]: Shall be set to 0x04.
  • Reserved [uint8]: Shall be set to 0x00.
  • IPv4-address [uint32]: Shall transport the IP address as 4 bytes.
  • Reserved [uint8]: Shall be set to 0x00.
  • L4-Proto [uint8]: Shall be set to the relevant layer 4 protocol based on the IANA/IETF protocol numbers (6: TCP, 17:UDP).
  • L4-Port [uint16]: Shall be set to the port of the layer 4 protocol.


Figure 13 — SOME/IP SD IPv4 endpoint option layout

7.5.2.3 IPv6 endpoint option 

The IPv6 endpoint option shall be used by a SOME/IP-SD instance to signal the relevant endpoint(s). Endpoints include the local IP address, the transport layer protocol (e.g. UDP or TCP), and the port number of the sender. 

These ports shall be used for the events and notification events as well. When using UDP, the server uses the announced port as source port; and with TCP, the client needs to open a connection to this port before subscription, so that the server can use this TCP connection. 

The format of the IPv6 endpoint option shall be as follows.
  • Length [uint16]: Shall be set to 21.
  • Type [uint8]: Shall be set to 0x06.
  • Reserved [uint8]: Shall be set to 0x00.
  • IPv6 address [uint128]: Shall transport the IP address as 16 bytes.
  • Reserved [uint8]: Shall be set to 0x00.
  • L4-Proto [uint8]: Shall be set to the relevant layer 4 protocol based on the IANA/IETF protocol numbers (6: TCP, 17:UDP).
  • L4-Port [uint16]: Shall be set to the port of the layer 4 protocol.


Figure 14 — SOME/IP SD IPv6 endpoint option layout

7.5.2.4 IPv4 multicast option 

The IPv4 multicast option is used by the server to announce the IPv4 multicast address, the transport layer protocol (ISO/OSI layer 4), and the port number the multicast events and multicast notification events are sent to. As transport layer protocol, currently, only UDP is supported. 

The format of the IPv4 multicast option shall be as follows.
  • Length [uint16]: Shall be set to 0x0009.
  • The IPv4 multicast option shall use the type 20.
  • Reserved [uint8]: Shall be set to 0x00.
  • IPv4 address [uint32]: Shall transport the multicast IP address as 4 bytes.
  • L4-Proto [uint8]: Shall be set to the transport layer protocol (ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).
  • L4-Port [uint16]: Shall be set to the port of the layer 4 protocol.

The IPv6 multicast option and not the IPv6 endpoint option shall be referenced by SubscribeEventgroupAck messages.


Figure 15 — SOME/IP SD IPv4 Multicast option layout

7.5.2.5 IPv6 multicast option 

The IPv4 multicast option is used by the server to announce the IPv6 multicast address, the transport layer protocol (ISO/OSI layer 4), and the port number the multicast events and multicast notification events are sent to. As transport layer protocol, currently, only UDP is supported.

The format of the IPv6 multicast option shall be as follows.
  • Length [uint16]: Shall be set to 0x0021.
  • The IPv4 multicast option shall use the type 22.
  • Reserved [uint8]: Shall be set to 0x00.
  • IPv6 address [uint32]: Shall transport the multicast IP address as 16 bytes.
  • L4-Proto [uint8]: Shall be set to the transport layer protocol (ISO/OSI layer 4) based on the IANA/IETF types (0x11: UDP).
  • L4-Port [uint16]: Shall be set to the port of the layer 4 protocol.

The IPv4 multicast option and not the IPv4 endpoint option shall be referenced by SubscribeEventgroupAck messages.


Figure 16 — SOME/IP SD IPv4 Multicast option layout

7.5.3 Example PDU 

Figure 17 shows an example service discovery packet containing two entries and one option. The IP header and the UDP header are only shown in abstract form.


Figure 17 — Example SOME/IP SD PDU

8 Runtime behaviour 


8.1 General

This clause describes the runtime behaviour of SOME/IP and SOME/IP-SD.

8.2 SD communication 

8.2.1 General

  • Whenever possible, the implementation shall combine multiple operations (e.g. FindService, OfferService, Publish, Subscribe) into one packet to reduce network load.
  • All delay values used below shall be specified as a minimum and maximum delay. Each service instance shall randomly choose a concrete delay value from the interval.
  • The delay and timeout values shall be chosen by the system integrator. Generally, timeout values should be below 2 s to avoid lengthy “hangs”.
  • Caching can be implemented. The service discovery implementation can temporarily store information locally to reduce the amount of network queries. To allow for cleanup of stale client registrations (to avoid that the list of listeners fills over time), a cleanup mechanism might be required.
  • Query for Service ID shall produce a result (the answers can come from different hosts), the result being a list of records for all service instances, which have the given Service ID.
  • Query for the combination (Instance ID and Service ID) shall produce a result (the answers can come from different hosts), the result being a list of records for all service instances, which have the requested (Instance ID and Service ID) in common.
  • The server shall delay the answer to FindService and FindEventgroup messages transported by multicast/broadcast for a delay based on REQUEST_RESPONSE_DELAY. This is to avoid flooding the network. The server shall not delay unicast messages that are answered with unicast messages.
  • RequestService, SubscribeEventgroup, SubscribeEventgroupAck, and SubscribeEventgroupNack messages shall be sent as unicast.
  • FindService, OfferService, FindEventgroup, and PublishEventgroup messages should be sent as multicast.
  • FindService/FindEventgroup (respectively RequestService, SubscibeEventgroup) messages received with the unicast flag set to 1, shall be answered with a unicast response if the last announcement was sent less than 1/2 CYCLIC_OFFER_DELAY (respectively 1/2 CYCLIC_REQUEST_DELAY) ago.
  • FindService/FindEventgroup (respectively RequestService, SubscibeEventgroup) messages received with the unicast flag set to 1, shall be answered with a multicast response if the last announcement was 1/2 CYCLIC_OFFER_DELAY (respectively 1/2 CYCLIC_REQUEST_DELAY) or more ago.
  • FindService/FindEventgroup messages received with unicast flag set to 0 (multicast), shall be answered with a multicast response.

8.2.2 Startup 

The startup behaviour of the particular service instances or Eventgroups has three phases: initial, repetition, and main. The phases are illustrated in Figure 18.
  • After the network link has been established, the service discovery implementation shall be in the initial phase and do nothing for INITIAL_DELAY milliseconds.

NOTE 

After sending the first message, the system enters the repetition phase.

  • The service discovery shall send out up to REPETITIONS_MAX announcements during the repetitions phase with a delay of REPETITIONS_BASE_DELAY*2N, where N is increasing from 0 to (REPETITIONS_MAX-1).
  • 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.

NOTE 

After the repetitions phase, the main phase is entered.

  • In the main phase, offer messages shall be sent periodically if a CYCLIC_OFFER_DELAY is configured.
  • After entering the main phase, CYCLIC_OFFER_DELAY is waited before sending the first message.
  • After a message for a specific service instance, the service discovery waits for CYCLIC_OFFER_DELAY before sending the next message for this service instance.
  • For requests/subscriptions, the same cyclic behaviour as for the offers shall be implemented with the parameter CYCLIC_REQUEST_DELAY instead of CYCLIC_OFFER_DELAY.
  • For find entries (Find Service and Find Eventgroup) no cyclic messages shall be sent in the main phase.


Figure 18 — Startup behaviour

8.2.3 Multiple service instances 

Instances of the same service are identified through different Instance IDs. Multiple service instances can reside on different ECUs and also multiple service instances of one or more services can reside on one single ECU. The Instance IDs are used for service discovery, but are not contained in the RPC header. Multiple instances of the same service on a single ECU shall listen on different ports. A service instance can be identified through the socket (i.e. the combination of IP address, transport protocol, and port number). It is recommended that instances use the same port number for UDP and TCP.
  • The Instance ID shall be chosen so that it is guaranteed to be unique in the local network (in combination with the Service ID).
  • The Service Instance IDs of 0x0000 and 0xFFFF shall not be used for a service, since 0x0000 is reserved and 0xFFFF is used to describe all service instances.
  • If a service instance uses UDP port x, exactly this instance should use exactly TCP port x for its services.

Possibilities to obtain unique Instance IDs include computing them from the unique IP address directly, or using a lookup table mapping IP addresses to Instance IDs. This table has to be flashed into the camera but it can support multiple instances per IP address. 

To avoid confusion, the following paragraphs highlight some of the differences between the ClientID and the InstanceID fields. 

The Client ID is configured by the ECU manufacturer. It is unique within each ECU (independent of the Service ID) and used in every SOME/IP header. Its purpose is to allow SOME/IP to relay incoming PDUs to the correct process, as the socket information has been stripped away by AUTOSAR at this point. 

The Instance ID is configured by the OEM. In combination with the Service ID, it is unique within the vehicle and it is used in SOME/IP-SD messages only. It is needed for SOME/IP-SD to differentiate between multiple instances of the same service.

8.2.4 Subscription handling 

If a client wishes to subscribe to an Eventgroup, it shall send a SubscribeEventgroup message to the server offering the Eventgroup.
  • Upon receiving a subscription message, the server shall reply with a SubscribeEventgroupAck if it accepts the subscription.
  • Upon receiving a subscription message, the server shall reply with a SubscribeEventgroupNack if it does not accept the subscription, e.g. because the eventgroup is not available or resources are exhausted.
  • Upon receiving a subscription message, the server offering the notifications shall send “initial value” notifications for all relevant events.
  • If a client wishes to subscribe to an Eventgroup but does not know which servers offer it, it shall send a FindService message.
  • A server shall stop the publishing of notifications by sending a StopOfferService message for the corresponding Eventgroup.
  • A client shall unsubscribe from a notification by sending a StopSubscribe message for the corresponding Eventgroup.
  • The SOME/IP-SD on the server shall cancel the subscription if a relevant SOME/IP error is received after sending a notification.
  • If the server loses its Ethernet link, it shall delete all the registered subscriptions.
  • If the Ethernet link of the server comes up again, it shall trigger a SOME/IP-SD OfferService message.
  • If the notification client does not receive the expected notification message for a certain time, it shall send out a new SubscribeEventgroup to the server. This timeout is to be specified in the interface definition for each eventgroup.
  • A link-up event on the clients Ethernet link shall trigger a SOME/IP-SD SubscribeEventgroup message.

An example sequence chart can be seen in Figure 19.


Figure 19 — Notification subscription

8.2.5 Endpoint handling 

This section describes how the endpoints encoded in the endpoint and multicast options shall be set and used. The service discovery shall overwrite IP addresses and port numbers with those transported in endpoint and multicast options if the statically configured values are different from those in these options. 

8.2.5.1 Service endpoints

  • Offer service entries shall reference up to one UDP endpoint option and up to one TCP endpoint option. Both shall be of the same version Internet Protocol (IPv4 or IPv6).
  • The referenced endpoint options of the offer service entries denote the IP address and port numbers the service instance can be reached at the server.
  • The referenced endpoint options of the offer service entries also denote the IP address and port numbers the service instance sends the events from. Events of this service instance shall be sent only from this IP address and ports.
  • If an ECU offers multiple service instances, SOME/IP messages of these service instances shall be differentiated by the information transported in the endpoint options referenced by the offer service entries. Therefore, transporting an Instance ID in the SOME/IP header is not required.

8.2.5.2 Eventgroup endpoints

  • Subscribe Eventgroup entries shall reference up to one UDP endpoint option and up to one TCP endpoint option for the Internet Protocol used (IPv4 or IPv6).
  • The endpoint options referenced in the subscribe eventgroup entries is used to send unicast UDP or TCP SOME/IP events for this service instance to, i.e. the IP address and the port numbers on the client side.
  • TCP events are transported using the TCP connection the client has opened to the server before sending the Subscribe Eventgroup entry.
  • The initial events shall be transported using unicast from server to client.
  • Subscribe Eventgroup Ack entries shall reference up to one multicast option for the Internet Protocol used (IPv4 or IPv6).
  • The multicast option shall be set to UDP as transport protocol.

If the server has to send multicast events very shortly (<5 ms) after sending the Subscribe Eventgroup Ack entry, the server shall try to delay these events, so that the client is not missing it. If this event was sent as initial event anyhow, the server can send this event using unicast as well. 

Figure 20 below shows an example for the usage of eventgroup endpoints for the subscription.


Figure 20 — Publish/Subscribe example for endpoint options and the usage of ports

8.2.6 Announcing non-SOME/IP protocols with SOME/IP-SD 

Besides SOME/IP, other communication protocols are used within the vehicle; e.g. for network management, diagnosis, or flash updates. Such communications protocols might need to communicate a service instance or have eventgroups as well. For non-SOME/IP protocols, a special Service ID shall be used and further information shall be added using the configuration option.
  • Service ID for non-SOME/IP services shall be set to 0xFFFE (reserved).
  • Instance ID shall be used as described for SOME/IP services and eventgroups.
  • The configuration option shall be added and shall contain at least an entry with key “otherserv” and a configurable non-empty value that is determined by the system integrator.
  • SOME/IP services shall not use the otherserv-string in the configuration option.

8.2.7 Conflict resolution 

Theoretically, there can be conflicts over IP addresses, Instance IDs, or even Service IDs. This is a sign of a misconfigured vehicle and should not occur in the field.
  • In case of a conflict, the server shall announce that its service is being removed (TTL = 0 in a normal announcement message).
  • The reason for the removal of a service shall be accessible to developers and system integrators by inspection of the local error log.

8.3 RPC communication 

8.3.1 Request/Response communication 

One of the most common communication patterns is the request/response pattern. One party (the client) sends a request message, which is answered by another party (the server). To construct the SOME/IP header of the request message, the client has to perform the following steps:
  • construct the payload;
  • set the Message ID based on the method the client wants to call;
  • set the length field to 8 bytes + length of the serialized payload;
  • optionally, set the Request ID to a unique number (shall be unique for client only);
  • set the protocol version to 0x01;
  • set the interface version according to the interface definition;
  • set the message type to 0x00 (REQUEST);
  • set the return code to 0x00 (reserved).

For the reply, the server has to
  • construct the payload,
  • set the Message ID to the value received in the client's request,
  • set the length to the 8 Bytes + new payload size,
  • set the Request ID to the value received in the client's request,
  • set the protocol version to 0x01,
  • set the interface version according to the interface definition,
  • set the message type to 0x80 (RESPONSE) or 0x81 (ERROR), and
  • set the return code (see Table 4 for possible values).

8.3.2 Fire and forget communication 

Requests without response message are called fire and forget. The implementation is basically the same as a request/response with the following differences:
  • The message type is set to 0x01 (REQUEST_NO_RETURN).
  • There is no response message

Fire and forget messages do no return an error. Error handling and return codes shall be implemented by the application when needed.

8.3.3 Notifications 

Notifications describe a general Publish/Subscribe concept. Usually, the server publishes a service to which a client subscribes (using SOME/IP-SD). On certain events, the server will send the client an event, which could be, for instance, an updated value or an event that occurred.
  • No responses shall be sent upon receiving notification messages.
  • The frequency with which updates will be sent shall be specified in the interface definition. Different modes are possible, e.g. periodic update or update on change/delta change.

When more than one subscribed client on the same ECU exists, the system should handle the replication of notifications in order to save transmissions on the bus. This is especially important when notifications are transported using multicast messages. 

8.3.4 Fields 

A field is a representation of a remote property, which has up to one getter, up to one setter, and up to one notifier. A field does represent a status, and thus, has a valid value at all times on which getter, setter, and notfier can act upon. The getter is a request/response call that allows read access to a field. The setter is a request/response call that allows write access to a field. Thus, the field mechanism is a combination of methods to get/set this property value and a notification for this property.
  • A field shall be a combination of an optional getter, an optional setter, and an optional notification event.
  • A field shall have at least one getter, or one setter, or one notification event.
  • The getter of a field shall be a request/response call that has an empty payload in the request message and the value of the field in the payload of the response message.
  • The setter of a field shall be a request/response call that has the desired value of the field in the payload of the request message and the value that was set to field in the payload of the response message.
  • The notifier shall send an event message that transports the value of a field on change and follows the rules for events.

8.3.5 Error message format

  • The error message (type 0x81) shall be used to carry specific fields for error handling, e.g. an exception string.
  • The return code shall be set to the value that best describes the error condition (see Table 3).
  • Error message shall copy over the fields of the SOME/IP header (i.e. Message ID, Request ID, protocol version, and interface version) but not the payload.
  • Error messages are sent instead of response messages.

For more flexible error handling, SOME/IP allows the user to specify a message layout specific for errors instead of using the message layout for response messages. This is defined by the API specification and can be used to transport exceptions of higher level programming languages. The layout of the exception message shall contain at least 
  • a union of specific exceptions. At least one generic exception without fields shall be defined (this comes automatically with the default union type 0), and
  • a dynamic-length string for exception description.

The union gives the flexibility to add new exceptions in the future in a type-safe manner. 

8.3.6 Communication errors 

If an application is waiting for a response to a message, but does not receive it within a certain amount of time, it can try to resend the message. The number of retries, the timeout value, and the timeout behaviour (constant or exponential back off) are outside of the SOME/IP specification and can be added to the interface definition.

Bibliography


[1] IEEE 754-2008, IEEE Standard for Binary Floating-Point Arithmetic

评论

发表评论

此博客中的热门博文

AUTOSAR_SWS_CANDriver

图片
AUTOSAR_SWS_ CAN Driver 简介和功能概述 该规范指定了 AUTOSAR 基础软件模块 CAN 驱动程序（在本文档中称为“Can 模块”）的功能、 API 和配置。 CAN 模块属于最低层，执行硬件访问并向上层提供独立于 硬件 的 API 。 唯一可以访问  CAN  模块的上层是 Can If 模块（另请参阅  SRS _ SPAL _12092）。 CAN  模块提供启动传输的服务，并调用  Can If  模块的回调函数来通知 事件 ，独立于 硬件 。 此外，它还提供控制属于同一 CAN 硬件 单元的 CAN 控制器 的行为和状态的 服务 。 只要属于同一个 CAN 硬件 单元， 多 个 CAN 控制器 就可以由单个 CAN 模块控制。 有关 CAN 控制器 和 CAN 硬件 单元的详细描述，请参见首字母缩略词和缩写章节以及[5]中的图表。 首字母缩略词和缩写 优先级反转 如果只使用单个传输 缓冲区 ，则可能会发生内部 优先级 反转。 由于 优先级 较低，存储在 缓冲区 中的 消息 会等待，直到“总线上的流量平静下来”。 在等待期间，此 消息 可能会阻止同一微控制器生成通过总线传输的更高 优先级 的 消息 。 外部 优先级 反转问题可能出现在某些 CAN 实现中。 假设 CAN 节点希望传输一组具有高 优先级 的连续 消息 ，这些 消息 存储在不同的 消息 缓冲区 中。如果 CAN 网络上这些 消息 之间的 帧间空间 大于 CAN 标准定义的 最小 空间，则第 二 个节点能够开始传输较低 优先级 的 消息 。 最小 帧间空间 由 间歇字段 确定，该字段由 3 个隐性 bit 组成。 之前由于另一条 消息 的传输而处于待处理阶段的 消息 ，将在总线空闲期间开始被传输，最快可紧随 间歇字段 之后，从 间歇字 段 之后的第 一 个 bit 开始。 例外情况是，具有待传输的 消息 的节点会将 间歇字段 的第三个 bit 解释为显性 bit ，并以此 bit 作为帧的起始位，开始传输帧的第一个标识符位，而无需先传输 SOF 位。 CAN 模块的内部处理时间必须足够 短 ，以发送具有最小 帧间空间 的连续 消息 ，以避免在上述所有情况下出现外部 优先...
Read more »

Linux Driver Char Device 笔记

图片
1.打開設備 设备节点           本质上和文件节点相同，为操作驱动的基本单位 文件节点          只用来做文件操作 打开设备文件的步骤：           chrdev_open完成的主要工作是：首先根据设备号找到添加在内核中代表字符设备的cdev （cdev是放在cdev_map散列表中的，驱动加载时会构造相应的cdev并添加到这个散列表中，并且在构造这个cdev时还实现了一个操作方法集合，由cdev的ops成员指向它），找到对应的cdev对象后，用cdev关联的操作方法集合替代之前构造的file结构中的操作方法集合，然后调用cdev所关联的操作方法集合中的打开函数，完成设备真正的打开操作，这也标志着do_filp_open函数基本结束。 使用的时候是先用inode找到对应的cdev，然后cdev对象包含对应的操作集file_operations。 并且在以下情况时，驱动程序会根据入口函数 static int cdev_open ( struct inode* inodp, struct file* filp ) 将 和具体设备 相关的 驱动数据 与 file 结构建立关联： 打开代表设备的inode 初始化要作为file来操作的设备 这样 file 结构就包含对驱动操作的 操作集 及 与具体设备挂钩的 驱动私有数据 了，这样就能对 file 进行操作进而 控制相关设备 了。 打开一个 cdev 的步骤： 打开对应 inode 通过 indoe 找到对应 cdev 将与 cdev 相关的 设备数据 及 驱动操作集 与 要作为文件操作的代表驱动的 file 结构 相挂钩 2.IOCTL ioctl 命令编码规则 31 30 ----------(2 Byte) 00 00     -     命令不带参数 00 01     -     向驱动传递参数，写入 01 00     -     从 驱动获取数据，读出 01 01   ...
Read more »

AUTOSAR_SWS_PWMDriver

图片
AUTOSAR_SWS_ PWM Driver 简介和功能概述 该规范指定了 AUTOSAR 基础软件模块 PWM 驱动程序的功能、 API 和配置。 每个  PWM  通道都链接到微控制器的硬件 PWM 。 PWM  信号的类型（例如居中对齐、左对齐等）未在本规范中定义，而由实现决定。 驱动程序提供微控制器内部  PWM  层（脉冲宽度调制）的初始化和控制功能。 PWM  模块生成具有可变脉冲宽度的脉冲。它允许选择 占空比 和信号 周期 时间。 首字母缩略词和缩写 具有本地范围的首字母缩略词和缩写词不包含在 AUTOSAR 词汇表中。这些必须出现在本地词汇表中。 约束和假设 限制 [ SWS _ Pwm _00001] [ SRS _ Pwm _12386] PWM SWS 不涵盖通用 I/O 上的 PWM 仿真。 仅当 MCAL 驱动程序拥有完整的底层硬件外设（即，其他 MCAL 模块无法访问硬件外设）时，才可实现电源状态控制 API 。 对其他模块的依赖 PWM  依赖于系统 时钟 。因此，系统 时钟 的变化（例如 PLL 开启 -> PLL 关闭）也会影响 PWM 硬件的 时钟 设置。 PWM  驱动器依赖于以下模块： Port 驱动程序： 设置端口 引脚 功能。（PWM141） MCU 驱动程序： 设置预分频器、系统 时钟 和 PLL 。（PWM142） DET ： 开发模式下的默认 错误 跟踪器。（PWM 143） 文档 087_ AUTOSAR _ ECU _ Configuration 包含第4.6章 时钟 树配置，其中详细介绍了向外围设备传送参考 时钟 信号的机制。 代码文件结构 [ SWS _ Pwm _00065] [SRS _ BSW _00346] [SRS _ BSW _00314] PWM SWS 不应定义代码文件结构。 头文件结构 [ SWS _ Pwm _50075] [ ] Pwm . c 应包括 Pwm . h 、 Det . h 和 。 [ SWS _ Pwm _70075] [ ] Pwm _ Irq . c 应包括 Pwm . h 。 需求可追溯性 功能规格 一般行为 [ SWS _ Pwm _0008...
Read more »

AUTOSAR_SWS_PortDriver

图片
AUTOSAR_SWS_ Port Driver 简介和功能概述 本规范规定了 AUTOSAR  基础软件模块 Port  驱动程序的： 功能 API 配置 本驱动程序规范适用于片上： 端口 端口 引脚 该模块应提供 初始化 微控制器整个  Port  结构的服务。 许多 端口 和端口 引脚 可分配给各种 功能 ，例如： General purpose I/O ADC SPI SCI PWM CAN LIN 其他 因此，应对 端口 结构进行 整体 配置和初始化。 这些端口 引脚 的 配置 和 模式 取决于微控制器和 ECU 。 应尽可能高效地将 端口 初始化数据写入每个 端口 。 Port  驱动程序模块应完成在  Dio 驱动程序模块中使用的 端口 结构的整体配置和初始化。 因此， Dio  驱动程序在由  Port  驱动程序配置的 引脚 和 端口 上工作。 在使用  Dio  功能之前，应初始化  Port  驱动程序。 否则， Dio  功能将表现出 未 定义的行为。 下图标识了  Port  驱动程序功能以及 MCAL 软件层中的  Port  驱动程序和  Dio  驱动程序的结构 [1]。 首字母缩略词和缩写 下表总结了  Port  驱动程序中使用的表达式。 约束和假设 Port  驱动程序的限制如下： 用户有责任确保同一系统中的 不 同实体 不 会并行访问同 一 端口 /端口 引脚 ，例如： 两 个任务配置同 一 端口 。 两 个任务配置同 一 引脚。 两 个任务配置同 一 端口 上的 不 同 引脚 。 对其他模块的依赖 其他驱动程序模块可能依赖于  Port  驱动程序，具体取决于 MCU 上各个端口 引脚 的可用功能。例如， MCU   引脚 可能可配置为  Dio  或 SPI   引脚 。因此， Dio  和/或  SPI  驱动程序模块可能依赖于  Port  模块来配置 引脚 以实现所...
Read more »

AUTOSAR_SWS_ECUStateManager

图片
Specification of ECU State Manager 简介和功能概述 Ecu M  模块（如本文档中所述）是一个基本软件模块（参见  AUTOSAR _ TR _ BSW ModuleList.pdf），用于管理 ECU 状态 的常见方面。具体来说， ECU 管理器 模块： 初始化和取消初始化 OS 、 Sch M 和 Bsw M 以及一些基本软件驱动模块 根据请求将 ECU 配置为 休眠 和 关机 管理 ECU 上的所有 唤醒 事件 ECU 管理器模块提供 唤醒 验证协议来区分 “ 真实 ” 唤醒 事件 “ 不稳定 ” 唤醒 事件 此外： 部分 或 快速 启动 其中 ECU 以有限的功能 启动 。 然后根据应用程序的决定，继续逐步 启动 。 交错 启动 ECU 以最低限度 启动 ，然后 启动   RTE 以尽快执行 软件 组件 中的功能。 然后它继续 启动 其他 BSW 和 软件 组件 ，从而交错 BSW 和应用程序功能。 多个 运行 状态 其中 ECU 具有多个 运行 状态。 除其他外，这改进了从 休眠 状态到 运行 状态的频谱概念。 现在可以有一系列 运行 状态，从 经典 运行 （完全 运行 ）到 最深 的 休眠 （处理器 停止 ）。 多核 ECU 启动 、 关机 、 休眠 和 唤醒 在 ECU 的所有核心上协调。 灵活的 ECU 管理采用以下模块提供的通用模式管理设施： RTE  和  BSW  的调度模块（参见   AUTOSAR _ SWS _ RTE .pdf）现在合并为一个模块： 该模块支持自由配置的  BSW  和应用程序模式以及切换模式功能。 BSW  模式管理器模块（参见   AUTOSAR _ SWS _ BSW ModeManager.pdf）： 该模块实现可配置规则和操作列表，以评估切换  ECU  模式的条件并实施必要的操作。 因此，通过灵活的  ECU   管理 ，大多数  ECU   状态 不再在 ECU 管理器 模块中被实现。通常，只有当通用模式 管理 设施在以下情况下不可用时， ECU 管理器 模块才会接管控制...
Read more »

EB - MCAL - MCU

图片
EB  - MCAL MCU MCU （微控制器单元）模块的 配置 。 General 此选项卡为  MCU  模块的 通用 配置 。 Config   Variant ： VariantPreCompile： 仅 预编译 时配置参数。 只有 一 组参数。 VariantPostBuild： 预编译 和 构建 后 时间配置 参数的混合。 只有 一 组参数。 VariantPostBuildSelectable： 预编译 和 构建 后 时间配置 参数的混合。 更多组参数。 General - McuGeneralConfiguration MCU   通用 配置 的 容器。 DevErrorDetect： 预处理器 开关，用于启用默认 错误 检测并向 Det  报告。 开关 DevErrorDetect 将打开或关闭默认 错误 跟踪器 ( Det ) 检测和通知。 默认 错误 的检测可在 预编译 时配置 (ON/OFF)。 #define MCU_DEV_ERROR_DETECT (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 MultiCoreSupport： 此参数全局使能了支持 多核 的可能性。 如果启用此参数，则至少需要定义一个 EcucPartition （在所有变体中）。 McuGetRamStateAPI： 预处理器 开关用于启用/禁用 API Mcu_GetRamState 。 #define MCU_GET_RAM_STATE_API (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 McuInitClockAPI： 如果将此参数设置为 FALSE ，则必须从 MCU 驱动程序禁用 时钟 初始化。 此概念适用于存在一些 一次性 写入 时钟 寄存器且存在 引导加载 程序的情况。 如果将此参数设置为 TRUE ，则 MCU 驱动程序负责 时钟 初始化。 #define MCU_INIT_CLOCK (STD_ON)/(STD_OFF) 将在 Mcu_Cfg .h 文件中生成。 McuNoPLL： 如果 H/W 没有 PLL 或 PLL 电路在开机后无需 S/W 干预即可启用，则此参数应设置为 True 。 在这种情...
Read more »

AUTOSAR_SWS_ICUDriver

图片
AUTOSAR_SWS_ ICU Driver 简介和功能概述 本规范规定了 AUTOSAR 基础软件模块 ICU 驱动程序的功能、 API 和配置。 ICU  驱动程序是一个使用输入捕获单元 ( ICU ) 来解调 PWM 信号、计数脉冲、测量频率和占空比、生成简单中断以及唤醒中断的模块。 ICU  驱动程序提供的服务： 信号 边缘 通知 控制唤醒中断 周期 性信号时间测量 边缘 时间戳，可用于获取非 周期 性信号 边缘 计数 首字母缩略词和缩写 对其他模块的依赖 模块 DET （默认 错误 追踪器） 检测到的 错误 的详细描述可以在第 7.2 章和第 8 章中找到。 模块 MCU ICU 驱动程序依赖于系统 时钟 、预分频器和 PLL 。因此， ICU 定时器刻度的长度取决于模块 MCU 中的 时钟 设置。 ICU 驱动程序不会负责在其 Init 函数中设置配置全局 时钟 、全局 预分频 器和 PLL 的寄存器。这必须由 MCU 模块完成。 ICU 驱动程序仅配置本地（ ICU 外设特定的）时钟、 预分频 器等。 OS （操作系统） ICU 驱动程序使用 中断 ，因此依赖于配置 中断 源的操作系统。它仅提供回调函数。 ICU 驱动程序不会在其 Init 函数中设置 中断 关联的寄存器。 中断 系统的整体分配和激活由操作系统完成。 模块 Port Port 驱动程序负责配置 ICU 用作输入的端口 引脚 。因此，在使用 ICU 功能之前必须初始化  Port  驱动程序。否则 ICU 功能将表现出未定义的行为。 模块 EcuM [ SWS _ Icu _00244] [ ] ICU 驱动程序将向 EcuM 报告唤醒中断。 需求可追溯性 功能规格 背景与理由 为了确保数据一致性，应提供可重入代码。 需求 [ SWS _ Icu _00050] [ ] 不同通道号的  ICU  模块功能应可重入，但以下情况除外： Icu _ Init () Icu _ De Init () Icu _Set Mode () Icu _Get Version Info () [ SWS _ Icu _00149] [ ] 如果在运行时在 不 同的任务或 ISR 中使用了对同一 ICU...
Read more »

EB - MCAL - PWM

图片
EB  - MCAL PWM PWM （脉冲宽度调制）模块的配置。 General 此选项卡为  PWM （脉冲宽度调制）模块的 通用 配置 。 Config Variant： VariantPreCompile：仅 预编译 时配置参数。只有一组参数。 VariantPostBuild：混合 预编译 和 构建后 配置参数。只有一组参数。 General - PwmConfigurationOfOptApiServices PwmConfigurationOfOptApiServices 容器用于存储所有可选 API 的配置。 PwmDeInitApi： 从代码中添加/删除服务 Pwm_DeInit ()。 PwmGetOutputState： 从代码中添加/删除服务 Pwm_GetOutputState ()。 PwmSetDutyCycle： 从代码中添加/删除服务 Pwm_SetDutyCycle ()。 PwmSetOutputToIdle： 从代码中添加/删除服务 Pwm_SetOutputToIdle ()。 PwmSetPeriodAndDuty： 从代码中添加/删除服务 Pwm_SetPeriodAndDuty ()。 PwmVersionInfoApi： 勾选以指示支持  Pwm_GetVersionInfo 。 PwmGetChannelStateApi： 勾选以指示支持  Pwm_GetChannelState 。 PwmEnableTriggerOut： 从代码中添加/删除服务： Pwm_EnableTriggerOut () Pwm_EnableTriggerOut () General - PwmGeneral PwmGeneral 容器用于存储  PWM  的通用配置。 Pwm Multi-Core Enable： 切换启用/禁用 多核 功能。 启用该功能时，需要在 PwmChannelEcucPartitionRef 容器中配置至少一个  ECUC  分区，并且  PwmChannel  容器中的每个  PWM  通道也需要配置至少 一 个  ECUC  分区。 PwmDev...
Read more »