Autosar 系列教程：小柴带你学 AutoSar 总目录

# 小柴带你学 AutoSar 系列三、标准和规范篇（5）CommunicationManagement

# 一、NetworkManagement

# 1 Scope of Document

This document specifies requirements on the AUTOSAR Network Management.

本文档指定了对 AUTOSAR 网络管理的要求。

The requirements apply on following functional entities:

• Network Management coordinating a particular Nm-cluster.
• Network Management bus specifics for a particular bus.
• Gateway and Interoperability of Network Management between Nm-clusters.

这些要求适用于下列职能实体:

• 网络管理，协调特定的 Nm 集群。
• 特定总线的网络管理总线具体信息。
• 网关与 Nm 集群间网络管理的互操作性。

The communication system where Nm is applicable has to support a “bus sleep” mode. That means that the transceiver of the communication system can switch to a low power mode and can be switched again to full power mode by (specific) bus traffic and/or application.

Nm 适用的通信系统必须支持 “总线睡眠” 模式，这意味着通信系统的收发器可以切换成低功率模式，并且可以通过 (特定的) 总线通信和 / 或应用程序再次切换成全功率模式。

# 4 Use Cases

# 5 Requirements Specification

# 5.1 Functional Requirements

# 5.1.1 Configuration

[RS_Nm_00150] Specific features of the Network Management shall be configurable

The following features of the Network Management shall be configurable:

• Detection of present nodes – [RS_Nm_00153]
• Notification that all other ECUs are (no more) ready to sleep (i.e. Remote Sleep Indication (Cancellation)) – [RS_Nm_00052], [RS_Nm_02509]
• Nm Coordination support – [RS_Nm_02514]
• User data support – [RS_Nm_02503], [RS_Nm_02504]
• Bus load reduction – [RS_Nm_00142]
• Sending node identifier – [RS_Nm_02505]
• Receiving node identifier – [RS_Nm_02506]
• Immediate Transmission Confirmation
• Configurable Role In Cluster Shutdown – [RS_Nm_02511]
• Bus Keep Awake Services – [RS_Nm_00047]
• Partial Networking extensions – [RS_Nm_02517]
• Dynamic PNC Mapping – [RS_Nm_02547]
• Synchronized PNC shutdown – [RS_Nm_02548]

这些是可配置的：

• 检测当前节点 -[RS_Nm_00153]
• 通知所有其他 ECU 已 (不再) 准备好进入睡眠状态 (即远程睡眠指示 (取消))-[RS_Nm00052]，[RS_Nm_02509]
• Nm 协调支持 -[RS_Nm02514]
• 用户数据支持 -[RS_Nm_02503]，[RS_Nm_02504]
• 总线负载减少 -[RSNm00142]
• 发送节点标识符 -[RSNm02505]
• 接收节点标识符 -[RS_Nm_02506]
• 即时传输确认
• 集群关闭中的可配置角色 -[RS_Nm_02511]
• 总线保持唤醒服务 -[RS_Nm_00047]
• 部分网络扩展 -[RSNm 02517]
• 动态 PNC 映射 -[RS Nm 02547]
• 同步 PNC 关机 -[RS_Nm_02548]

# 5.1.2 Initialization

[RS_Nm_00151] The Network Management algorithm shall allow any node to integrate into an already running Nm cluster

网络管理算法应允许任何节点集成到已经运行的 Nm 集群中

Integration of

a) Late nodes

b) nodes that have recovered from fault state

c) nodes that have been connected to a running vehicle network (e.g. by service)

[RS_Nm_00043] Nm shall not prohibit bus traffic with Nm not being initialized

不管有没有初始化都要允许总线通信

# 5.1.3 Normal Operation

[RS_Nm_00044] The Nm shall be applicable to different types of communication systems which are in the scope of AUTOSAR and support a bus sleep mode.

Network management mechanisms for each supported protocol shall be realized using a limited number of predefined Nm states and Nm transitions. The events triggering the transitions between states and the actions taken on these transitions may be protocol specific. A bus sleep mode shall be supported for each protocol. Nm shall be executable on asynchronous communication systems (e.g. CAN) as well as on synchronous communication systems (e.g. FlexRay), and also on any other types of communication systems which are in the scope of AUTOSAR

每个受支持协议的网络管理机制应使用有限数量的预定义 Nm 状态和 Nm 转换来实现。触发状态之间转换的事件以及对这些转换执行的操作可能是特定于协议的。每个协议都应支持总线休眠模式。Nm 应在异步通信系统（例如 CAN）和同步通信系统（例如 FlexRay）以及 AUTOSAR 范围内的任何其他类型的通信系统上执行

[RS_Nm_02515] Nm shall offer a generic possibility to run other Nms than the AUTOSAR-Nms

就是搞一些接口

[RS_Nm_00045] Nm shall provide services to coordinate shutdown of Nmclusters independently of each other

Nm 应提供服务以协调彼此独立的 Nm clusters NM 集群的关闭

In today’s cars, multiple different communication systems are implemented.

在当今的汽车中，实施了多种不同的通信系统。

Therefore, ECUs might be connected to multiple communication channels (e.g. 2 CAN clusters, 1 FlexRay cluster, etc.).

因此，ECU 可能连接到多个通信通道（例如 2 个 CAN 集群、1 个 FlexRay 集群等）。

Not in all cases all channels have to be in full power mode. Because of that, each channel has to be able to be started up or shut down separately.

并非在所有情况下，所有通道都必须处于全功率模式。因此，每个通道都必须能够单独启动或关闭。

[RS_Nm_02513] Nm shall provide functionality which enables upper layers to control the sleep mode.

给上层提供接口来控制睡眠 / 唤醒

[RS_Nm_00046] It shall be possible to trigger the startup of all Nodes at any Point in Time

任何时间点都可以触发所有节点的启动

At a specific point in time all nodes connected to Nm-cluster have to be started-up (e.g. if the car is started). Because of that Nm has to provide services to start up Nm of all nodes connected to a Nm-cluster at any point in time.

在特定时间点，所有连接到 Nm-cluster 的节点都必须启动（例如，如果汽车已启动）。因此，Nm 必须提供服务以在任何时间点启动连接到 Nm 集群的所有节点的 Nm。

The point in time can not be calculated offline, therefore this service has to be accessible at any time.

Note regarding FlexRay networks: Under certain circumstances, a shutdown may be required before a startup can occur. In this situation substantial delays may occur.

时间点无法离线计算，因此必须随时访问此服务。

关于 FlexRay 网络的注意事项：在某些情况下，可能需要先关闭才能启动。在这种情况下，可能会出现重大延误。

All nodes means all nodes connected to clamp 30 (nodes permanently connected to power supply). ECUs connected to clamp 15 (nodes power supplied through some power relay) have to be treated separately, due to the fact that they cannot be started-up at any point in time.

所有节点是指连接到 clamp 30 的所有节点（永久连接到电源的节点）。

连接到 clamp 15 的 ECU （节点通过某个功率继电器供电） 必须单独处理，因为它们无法在任意时间点启动。

Note: "Passive Nodes" are not able to initiate a start-up of a Nm-cluster, but they are able to be woken up if any other node initiates a start-up. Please refer [RS_Nm_02511]

注意：“被动节点” 无法启动 Nm 集群，但如果任何其他节点启动启动，它们可以被唤醒。请参考 [RS_Nm_02511]

[RS_Nm_00047] Nm shall provide a service to request to keep the bus awake and a service to cancel this request.

Nm 应提供请求保持总线唤醒的服务，并提供取消此请求的服务。

[RS_Nm_00048] Nm shall put the communication controller into sleep mode if there is no bus communication

如果没有总线通信，Nm 应将通信控制器置于睡眠模式

[RS_Nm_00050] The Nm shall provide the current state of Nm

应用程序应能够通过访问 Nm 的特定接口来获取 Nm 状态信息。Nm 状态反映了总线的状态。

[RS_Nm_00051] Nm shall inform application when Nm state changes occur.

Nm 应提供一个接口，应用程序可以使用该接口在发生特定 Nm 状态更改时获得通知。

[RS_Nm_00052] The Nm interface shall signal to the application that all other ECUs are ready to sleep.

Nm 接口应向应用程序发出信号，表明所有其他 ECU 都已准备好休眠。

[RS_Nm_02509] The Nm interface shall signal to the application that at least one ECU is not ready to sleep anymore.

Nm 接口应向应用程序发出信号，表明至少有一个 ECU 没准备好休眠。

[RS_Nm_02503] The Nm API shall optionally give the possibility to send user data

[RS_Nm_02504] The Nm API shall optionally give the possibility to get user data

Nm API 可以选择设置可以附加到总线上发送 / 获取的每条 Nm 消息的用户数据。Nm 应保证写入 / 读取操作的数据一致性。

[RS_Nm_00153] The Network Management shall optionally provide a possibility to detect present nodes

网络管理应选择性地提供检测当前节点的可能性

Rationale: For diagnostics purposes and configuration checks.

基本原理：用于诊断和配置检查。

[RS_Nm_02508] Every node shall have a node identifier associated with it that is unique in the Nm-cluster.

每个节点都应具有与之关联的节点标识符，该标识符在 Nm 集群中是唯一的。

[RS_Nm_02505] The Nm shall optionally set the local node identifier to the Nmmessage

Nm 可以选择性地将本地节点标识符设置为 Nm 消息

[RS_Nm_02506] The Nm API shall give the possibility to read the source node identifier of the sender

Nm API 将提供从最近收到的 Nm 消息中读取发送者的源节点标识符的可能性。

[RS_Nm_02511] It shall be possible to configure the Network Management of a node so that it does not contribute to the cluster shutdown decision.

应该可以配置节点的 Network Management，使其不会影响集群关闭决策。

Specifically, it shall be possible to configure some nodes of a cluster so that they are not able to broadcast the information used by other nodes to trigger shutdown, i.e., they have no Nm-related communication defined for the node.

具体来说，应该可以配置集群的某些节点，以便它们无法广播其他节点用于触发关闭的信息，即，它们没有为节点定义与 Nm 相关的通信。

Such nodes shall not be capable of keeping the bus awake, but they are required to shut down in a manner consistent with the others. See also [RS_Nm_00150].

此类节点不能使 bus 保持唤醒状态，但需要以与其他节点一致的方式关闭。另见 [RS_Nm_00150]。

[RS_Nm_02536] Nm shall provide functionality to start-up without requesting the network.

Nm 应在不请求网络的情况下提供启动功能。

A node has to participate to the network management without actively requesting communication.

节点必须参与网络管理，而无需主动请求通信。

[RS_Nm_02512] The Nm shall give the possibility to enable or disable the network management related communication configured for an active Nm node

Nm 可以启用或禁用为活动 Nm 节点配置的网络管理相关通信 Conformance to ISO 14229 CommunicationControl (28 hex) service

[RS_Nm_02573] Nm shall handle retransmission of NM-PDUs

<Bus>Nm 负责处理 NM-PDU 的重传

<Bus>Nm has to perform a retry transmission handling for NM-PDU in the context of the main function calls, if transmission of this NM-PDU was not accepted or not confirmed by the lower layer

<Bus> 如果此 NM-PDU 的传输未被下层接受或未确认，则 Nm 必须在主函数调用的上下文中对 NM-PDU 执行重试传输处理

# 5.1.4 Fault Operation

[RS_Nm_00137] Nm shall perform communication system error handling for errors that have impact on the Nm behavior.

Nm 应对影响 Nm 行为的错误执行通信系统错误处理。

Focus: bus errors, not protocol errors.

Example: loss of Nm message is handled.

重点：总线错误，而不是协议错误。

示例：处理 Nm 消息的丢失。

# 5.1.5 Nm Coordination

[RS_Nm_02514] It shall be possible to group networks into Nm Coordination Clusters

应该可以将网络分组到 Nm 协调集群中

It shall be possible to group networks into Nm Coordination Clusters. Each bus specific Nm shall, by configuration, be part of 0 or 1 Nm Coordination Cluster.

应该可以将网络分组到 Nm 协调集群中。根据配置，每个总线特定的 Nm 应是 0 或 1 Nm 协调集群的一部分。

Nm shall provide functionality (Nm Coordination) to coordinate the different Nm modes (especially sleep and keep awake) on all networks in an Nm Coordination Cluster, by performing a synchronized shutdown on all included networks.

Nm 应提供功能（Nm 协调），通过在包含的所有网络上执行同步关闭来协调 Nm 协调集群中所有网络上的不同 Nm 模式（尤其是睡眠和保持唤醒）。

The level of synchronization is determined by the configuration of the shutdown synchronization algorithm. Specifically, it shall be possible to perform Nm Coordination for each Nm Coordination Cluster separately and independently.

同步级别由 shutdown 同步算法的配置决定。具体来说，应该可以单独和独立地为每个 Nm 协调集群执行 Nm 协调。

It shall be possible to perform coordinated and/or synchronized shutdown of multiple Nm clusters independently.

应该可以独立执行多个 Nm 集群的协调和 / 或同步关闭。

[RS_Nm_02516] All AUTOSAR Nm instances shall support the Nm Coordinator functionality including Bus synchronization on demand

所有 AUTOSAR Nm 实例都应支持 Nm 协调器功能，包括按需总线同步

Bus Synchronization on demand allows for synchronization of an Nm-cluster at an arbitrary point in time, meaning the Nm-Timeout Timers in all nodes of the Nm-cluster are restarted simultaneously.

按需总线同步允许在任意时间点同步 Nm 集群，这意味着 Nm 集群所有节点中的 Nm-Timeout 计时器会同时重新启动。

[RS_Nm_02535] The Nm coordination shall support the coordination of nested sub-buses

Nm 协调应支持嵌套子总线的协调

[RS_Nm_02537] The Nm Coordinator shall be able to abort the coordinated shutdown

Nm 协调器应能够中止协调关闭

As long as the coordinated shutdown is not completed, a network request on one of the coordinated buses shall be forwarded to other buses of this Coordination cluster.

只要协调关闭未完成，其中一条协调总线上的网络请求就应转发到此协调集群的其他总线。

# 5.1.6 Partial Networking

RS_Nm_02549 Nm shall offer interfaces to Request and indicate Repeat Message Request (optional)

Nm 应提供 Request 接口并指示 Repeat Message Request（可选

One bit in the Nm Control Bit Vector shall be used to propagate the need for receiving nodes to enter NmRepeatMessage state.

Nm Control Bit Vector 中的一位用于传播接收节点进入 NmRepeatMessage 状态的需求。

There shall be an interface to set the value of this bit in the Nm and the Repeat Message Request bit and one to indicate the change of this bit during reception. This feature shall be statically configurable (available or not).

应有一个接口用于设置 Nm 中该位的值 <Bus> 和 Repeat Message Request 位，还有一个接口用于指示接收过程中该位的变化。此功能应是静态可配置的（可用或不可用）。

[RS_Nm_02517] CanNm shall support Partial Networking on CAN

[RS_Nm_02550] FrNm shall support Partial Networking on FlexRay

CanNm 应支持 CAN 上的部分联网

FrNm 应在 FlexRay 上支持 Partial Networking

The power consumption can be reduced by e.g

• Shutting down of seat control functions
• Shutting down of park assistant functions
• Hazard flashers
• Shutting down of Electric Park Brake (EPB)

可以通过以下方式降低功耗： 例如：

• 关闭座椅控制功能
• 关闭驻车辅助功能
• 危险闪光器
• 关闭电动驻车制动器 （EPB）

[RS_Nm_02546] UdpNm shall support Partial Networking on Ethernet

UdpNm 一样的

[RS_Nm_02519] The Nm Control Bit Vector shall contain a PNI (Partial Network Information) bit.

Nm 控制位向量应包含一个 PNI （部分网络信息） 位。

0: Nm message does not contain PN request information

1: Nm message contains PN request information (PNI)

0：Nm 消息不包含 PN 请求信息

1：Nm 消息包含 PN 请求信息 （PNI）

[RS_Nm_02527] Nm shall implement a filter algorithm dropping all Nm messages that are not relevant for the ECU

Nm 应实施过滤算法，删除所有与 ECU 无关的 Nm 消息

[RS_Nm_02528] Nm shall provide a service which allows for instantaneous sending of Nm messages.

Nm 应提供允许即时发送 Nm 消息的服务。

A PN request originating from the ECU needs to be sent out as fast as possible to avoid long latency

源自 ECU 的 PN 请求需要尽快发出，以避免长时间延迟

RS_Nm_02547 Nm shall be able to propagate and evaluate the need for Partial Networking Learning (optional)

{草稿}<Bus>Nm 应能够传播和评估部分网络学习的需求（可选）

One bit in the Nm Control Bit Vector shall be used to propagate the need for Partial Networking Learning.

Nm Control Bit Vector 中的一位应用于传播对 Partial Networking Learning 的需求。

There shall be an interface to set the value of this bit in the <Bus>Nm and the Repeat Message Request bit and one to indicate the change of this bit during reception.

应有一个接口用于设置 Nm 中该位的值 <Bus> 和 Repeat Message Request 位，还有一个接口用于指示接收过程中该位的变化。

This feature shall be statically configurable (available or not) (see [RS_Nm_00150])

此功能应是静态可配置的（无论是否可用）（参见 [RS_Nm_00150]）

Partial Network learning differs between:

• request Nm PDU, where the bit for partial networking learning and Repeat Message Request bit are both set,
• response Nm PDU, where only the bit for partial networking learning is set (but Repeat Message Request bit stays unset).

部分网络学习在以下方面有所不同：

• 请求 Nm PDU，其中部分网络学习的位和重复消息请求位都设置了，
• 响应 Nm PDU，其中仅设置了部分网络学习的位（但重复消息请求位保持未设置）。

RS_Nm_02548 Nm shall be able to propagate and evaluate the need for synchronized PNC shutdown in the role of a top-level PNC coordinator or intermediate PNC coordinator (optional)

{草稿}<Bus>Nm 应能够传播和评估作为顶级 PNC 协调器或中间 PNC 协调器（可选）的角色需要同步 PNC 关闭

One bit in the Nm Control Bit Vector shall be used to propagate the synchronized PNC shutdown.

Nm Control Bit Vector 中的一位应用于传播同步 PNC 关断。

There shall be an interface to set the value of this bit in the Nm and one to indicate the set bit during reception. This feature shall be statically configurable (available or not)(see [RS_Nm_00150]).

应有一个接口用于设置 Nm 中该位的值 <Bus>，还有一个接口用于指示接收过程中的设置位。此功能应是静态可配置的（可用或不可用）（参见 [RS_Nm_00150]）。

RS_Nm_02540 The Nm Control Bit Vector shall contain a PN shutdown request bit.

Nm 控制位向量应包含一个 PN 关断请求位。

The Nm Control Bit Vector shall contain a PN shutdown request bit with the following meaning:

• 0: Nm message does not contain synchronized Partial Network shutdown request
• 1: Nm message does contain synchronized Partial Network shutdown request for at least one PNC

Nm 控制位向量应包含具有以下含义的 PN 关机请求位：

• 0：Nm 消息不包含同步的部分网络关机请求
• 1：Nm 消息包含至少一个 PNC 的同步部分网络关机请求

This bit is used to indicate that a top-level PNC coordinator release at least one PNC. This bit is evaluated only by an intermediate PNC coordinator. A PNC leaf node ignore this bit.

此位用于指示顶级 PNC 协调器释放至少一个 PNC。此位仅由中间 PNC 协调器评估。PNC 叶节点忽略此位。

Use Case: Synchronized PNC shutdown of the PNC within the network

用例：网络内 PNC 的同步 PNC 关闭

RS_Nm_02542 The <Bus>Nm of the top-level PNC coordinator shall set the PN shutdown request bit if a least one PNC is released

{草稿}<Bus > 如果至少释放了一个 PNC，则顶级 PNC 协调器的 Nm 应设置 PN 关闭请求位

The <Bus>Nm of a top-level PNC coordinator shall transmit a PN shutdown message if at least one PNC was released.

<Bus> 如果至少释放了一个 PNC，则顶级 PNC 协调器的 Nm 应发送 PN 关闭消息。

A PN shutdown message set the PN shutdown request bit and the PNC bit of the released PNCs to 1.

PN shutdown 消息将 PN shutdown 请求位和释放的 PNC 的 PNC 位设置为 1。

Thus, only the released PNCs are considered in the PN shutdown message. The remaining PNC bits are set to 0.

因此，PN 关闭消息中仅考虑已释放的 PNC。其余的 PNC 位设置为 0。

[RS_Nm_02571] Nm shall handle requests for synchronized PNC shutdown

Nm 应处理同步 PNC 关闭的请求

The Nm of an ECU in role a top-level PNC coordinator or intermediate PNC coordinator shall handle requests for a synchronized PNC shutdown indicated by ComM.

担任顶级 PNC 协调器或中间 PNC 协调器角色的 ECU 的 Nm 应处理 ComM 指示的同步 PNC 关闭请求。

Therefore, all information of indicated PNCs which has to be released shall be stored per NM-Channel. The stored request for a synchronized PNC shutdown are transformed to a byte array, where each bit represents a particular PNC (PNC bit vector).

因此，必须发布的指示 PNC 的所有信息应按 NM 通道存储。存储的同步 PNC 关闭请求被转换为字节数组，其中每个位代表一个特定的 PNC （PNC 位向量）。

This PNC bit vector shall be provided per NM-Channel, if the Nm indicate to fetch and transmit the NM-PDU as PN shutdown message on the corresponding Nm-Channel.

如果 <Bus>Nm 指示在相应的 Nm 通道上获取 NM-PDU 并将其作为 PN 关闭消息发送，则应为每个 NM 通道提供此 PNC 位向量。

Requests for synchronized PNC shutdown shall be aggregated and provided as PNC bit vector to all affected NM-Channels, if the Nm indicate to transmit a NM-PDU.

如果 <Bus>Nm 表示传输 NM-PDU，则应汇总同步 PNC 关闭的请求，并将其作为 PNC 位向量提供给所有受影响的 NM 通道。

RS_Nm_02544 Nm shall forward the indication of a PN shutdown message

{草稿} Nm 应转发 PN 关闭消息的指示，充当中间 PNC 协调器的 ECU 的 Nm 应立即将收到的 PN 关闭消息的指示转发给 ComM

[RS_Nm_02572] Nm shall transmit requests for synchronized PNC shutdown as NM-PDU

<Bus>Nm 应将同步 PNC 关机请求作为 NM-PDU 传输

The Nm of an ECU in role a top-level PNC coordinator or intermediate PNC coordinator handle requests for a synchronized PNC shutdown.

担任顶级 PNC 协调器或中间 PNC 协调器角色的 ECU 的 Nm 处理同步 PNC 关闭的请求。

Therefore NM indicate to start or stop a PNC shutdown process. If a PNC shutdown process has been started for a particular NM-Channel, then the Nm fetch the aggregated requests for a synchronized PNC shutdown as PNC bit vector and transmit the NM-PDU as PN shutdown message on the corresponding NM-Channel.

因此 NM 表示启动或停止 PNC 关闭过程。如果已为特定 NM 通道启动了 PNC 关断过程，则 Nm 将同步 <Bus>PNC 关断的聚合请求作为 PNC 位向量获取，并在相应的 NM 通道上将 NM-PDU 作为 PN 关断消息传输。<Bus>Nm 表示已成功传输到 Nm。

The Nm indicate a successfully transmission to the Nm. Otherwise a re-transmission shall be performed if configured.

否则，如果已配置，则应执行重传

RS_Nm_02561 Nm shall support Partial Networking

{草稿} Nm 应支持部分联网

Nm maintain the PNC timer handling and indicate changes regarding internal and external PNC request to the upper layer

Nm 维护 PNC 定时器处理，并向上层指示内部和外部 PNC 请求的更改

[RS_Nm_02562] Nm shall support channel-specific storage of IRA

Nm 应支持 IRA 的特定通道存储

Nm stores the latest IRA (internal request array) which represents the internal PNC requests as PNC bit vector. The IRA is stored per given Nm-channel and provided to Nm to be transmitted within the Nm message.

Nm 存储最新的 IRA （内部请求数组），它将内部 PNC 请求表示为 PNC 位向量。IRA 按给定的 Nm 通道存储，并提供给 <Bus>Nm 以在 Nm 消息中传输。

[RS_Nm_02563] Nm shall calculate the combined partial network request status EIRA (External and Internal Requests Aggregated)

Nm 应计算合并的部分网络请求状态 EIRA

[RS_Nm_02564] Nm shall calculate the status of the external partial network requests ERA(External Requests Aggregated)

Nm 应计算外部部分网络请求 ERA 的状态

[RS_Nm_02565] Nm shall communicate EIRA and ERA requests to the upper layers using dedicated APIs

<Bus>Nm 应使用专用 API 将 EIRA 和 ERA 请求传达给上层

[RS_Nm_02566] Nm shall support channel-specific configuration for ERA

Nm 应支持 ERA 的通道特定配置

[RS_Nm_02567] Nm shall support a global configuration for EIRA over all channels

Nm 应支持所有通道上的 EIRA 的全局配置

[RS_Nm_02574] Nm shall provide a confirmation API to indicate the transmission state PNC bit vector

Nm 应提供确认 API 以指示传输状态 PNC 位向量

# 5.2 Non-Functional Requirements

# 5.2.1 Layout Requirements

[RS_Nm_02541] Nm shall define a common layout of Nm messages.

Nm 应定义 Nm 消息的常见布局。

# 5.2.2 Timing Requirements

[RS_Nm_00054] There shall be a deterministic time from the point where all nodes agree to go to bus sleep to the point where bus is switched off.

从所有 nodes 都同意进入 bus sleep 到 bus 关闭的那一刻，应该有一个确定的时间。

# 5.2.3 Resource Usage

[RS_Nm_00142] Nm shall provide a mechanism to limit its bus load.

Nm shall not exceed a specified upper limit of bus load. This bus load has to be specified. Example: 3% in normal operation, 6% Bus load peak.

Nm 应提供一种机制来限制其总线负载。

Nm 不得超过规定的总线负载上限。必须指定此总线负载。示例：正常运行时为 3%，总线负载峰值为 6%。

[RS_Nm_00144] Nm shall support communication clusters of up to 64 ECUs

Nm 应支持多达 64 个 ECU 的通信集群

[RS_Nm_00145] On a properly configured node, Nm shall tolerate a loss of a predefined number of Nm messages

在正确配置的节点上，Nm 应容忍预定义数量的 Nm 消息的丢失

[RS_Nm_00146] The Nm shall tolerate a time jitter of Nm messages in one or more ECUs

Nm 应容忍一个或多个 ECU 中 Nm 消息的时间抖动

[RS_Nm_00152] The specification and implementation shall be split-up into a communication system independent and communication system dependent parts.

规范和实现应分为独立于通信系统的部分和从属于通信系统的部分。

[RS_Nm_00149] The timing of Nm shall be configurable.

Nm 的时间应该是可配置的。

All timing parameters of the Nm shall be configurable. This includes timings defining sending of Nm messages, minimum send repetitions, staying awake until common shutdown etc.

Nm 的所有时序参数都是可配置的。这包括定义 Nm 消息发送的时间、最小发送重复次数、保持清醒直到共同关闭等。在所有节点都指示它们已准备好休眠后，直到网络关闭的时间。节点的两个连续状态指示之间的时间间隔，无论它是否准备好休眠。根据可配置的节点数量确定时序。

# 5.2.4 Hardware independency

[RS_Nm_00154] The Network Management API shall be independent from the communication bus

网络管理 API 应独立于通信总线

# 二、E2E

# 1 Scope of this document

This document specifies requirements on the E2E protocol. The E2E protocol defines abstract mechanisms to provide End-to-End communication protection according to requirements of ISO 26262:2018 (all parts) [1].

本文件规定了 E2E 协议的要求。E2E 协议根据 ISO 26262:2018 (all parts) 所有部分) 的要求定义了提供端对端通信保护的抽象机制 [11.

These mechanisms shall allow safe data transmission of safety-related data for all integrity levels defined by [1] over a non safety-related communication path. This document covers the protocol part only and therefore the End-to-End path just partly.

这些机制应允许在下列所有完整性级别上安全相关数据的安全数据传输:[1] 在与安全无关的通信路径上。本文仅涵盖协议部分，因此仅部分涵盖端到端路径。

These requirements shall be used as a basis for the specification of detailed E2E mechanisms and their usage in AUTOSAR implementations. Note: The document contains well known requirements from classic platform documents and brings in new requirements for the adaptive platform as far as foreseen.

这些要求应作为详细 E2E 机制及其在 AUTOSAR 实现中使用的规格的基础。注意：该文件包含来自经典平台文件的已知要求，并引入了对自适应平台的新要求。

Use cases for E2E protection in adaptive platform are under elaboration. More details on the relevant use cases will be added within next version of this document.

自适应平台中的 E2E 保护用例正在制定中，有关用例的更多细节将在本文档的下一个版本中添加。

This is a draft specification to indicate the intended scope and direction of discussion to the AUTOSAR development community. This specification has seen less quality measures, less discussions among partners and may, generally, be in a less maturestate.

这是一份规范草案，旨在向 AUTOSAR 开发社区指明讨论的范围和方向。该规范的质量指标较少，合作伙伴之间的讨论较少，总体上可能不太成熟。

# 4 Functional Overview

Safety-related automotive systems often use a safe data transmission to protect communication between components (as required by ISO 26262:2018 (all parts) [1]), which means that:

• Communication errors shall be prevented (e.g. by means of appropriate software architecture and by means of verification).
• If error prevention alone is insufficient (e.g. for inter-ECU communication), then
  • the errors shall be detected at runtime to a sufficient degree (cf. diagnostic coverage, safe failure fraction) and
  • the rate of undetected dangerous errors shall be below some allowed limit(cf. residual error rate, probability of dangerous failure per hour or probability of dangerous failure on demand).

与安全相关的汽车系统通常使用安全数据传输来保护组件之间的通信 (ISO 26262:2018 (all parts) [1])，这意味着:

• 应防止通信错误 (例如通过适当的软件架构和通过验证)
• 如果仅有错误预防是不够的 (例如对于 ECU 之间的通信)，那么
  • 在运行时应检测到足够程度的误差 (参见诊断覆盖率、安全故障分级) 和
  • 未发现的危险差错率应低于某些允许限度 (参见残留差错率、每小时发生危险故障的概率或按需发生危险故障的概率)。

# 4.1 Functional safety and communication

With respect to the exchange of information in safety-related systems, the mechanisms for the in-time detection of causes for faults, or effects of faults as listed below, can be used to design suitable safety concepts, e.g. to achieve freedom from interference between system elements sharing a common communication infrastructure (see ISO 26262-6:2018, annex D.2.4).

在安全相关系统的信息交换方面，可以使用以下列出的对故障原因或故障影响的及时检测机制来设计合适的安全概念，例如实现共享通信基础设施的系统元件之间不受干扰 (see ISO 26262-6:2018, annex D.2.4).

# 4.2 Sources of faults in E2E communication

E2E communication protection aims to detect and mitigate the causes for or effects of communication faults arising from:

E2E 通信保护旨在检测和减轻由以下原因引起的通信故障的原因或影响:

# 1.Software faults

Software like, communication stack modules and RTE, may contain faults, which are of a systematic nature.

像通信堆栈模块和 RTE 这样的软件可能包含系统性故障。

Systematic faults may occur in any stage of the system’s life cycle including specification, design, manufacturing, operation, and maintenance, and they will always appear when the circumstances (e.g. trigger conditions for the root cause) are the same.

系统性故障可能发生在系统生存周期的任何阶段，包括规范、设计、制造、操作和维护，并且它们总是在相同的情况下出现 (例如根本原因的触发条件)。

The consequences of software faults can be failures of the communication, like interruption of sending of data, overrun of the receiver (e.g. buffer overflow), or underrun of the sender (e.g. buffer empty).

软件故障的后果可能是通信故障，例如数据发送中断、接收器溢出 (例如缓冲区溢出) 或发送器空转 (例如缓冲区空转)

To prevent (or to handle) resulting failures the appropriate technical measures to detect and handle such faults (e.g. program flow monitoring or E2E supervision) have to be considered.

为了防止 (或处理) 由此导致的故障，必须考虑采取适当的技术措施来检测和处理此类故障 (如程序流程监控或 E2E 监督)。

# 2.Random hardware faults

A random hardware fault is typically the result of electrical overload, degradation, aging or exposure to external influences (e.g. environmental stress) of hardware parts.

随机硬件故障通常是硬件部件的电气过载、退化、老化或暴露于外部影响 (例如环境压力) 的结果。

A random hardware fault cannot be avoided completely, but its probability can be evaluated and appropriate technical measures can be implemented (e.g. diagnostics).

不能完全避免随机硬件故障，但可以对其概率进行评估，并实施适当的技术措施 (如诊断)

# 3.Transient faults

Transient faults typically result from external influences or environmental stress, this in cludes influences like EMI, ESD, humidity, corrosion, temperature or mechanical stress (e.g. vibration).

瞬态故障通常由外部影响或环境应力引起，这包括 EMI、ESD、湿度腐蚀、温度或机械应力 (例如振动)。

# 4.3 Safe End-to-End communication in AUTOSAR

To provide a safe End-to-End communication, a solution shall be integrated within the AUTOSAR methodology which does require no or a minimal amount of additional nonstandard code like wrappers.

为了提供安全的端到端通信，应在 AUTOSAR 方法中集成一个解决方案该解决方案确实不需要或只需要少量的额外非标准代码 (如封装器)

The functionality of End-to-End communication protection is to be supported by the E2E protocol.

E2E 协议将支持端到端通信保护的功能。

The E2E protocol provides

• Mechanisms to detect a subset of communication faults listed in 4.1. The relevant communication faults depend on the type of communication (e.g. periodic, non periodic, sender/receiver, etc.).
• The definition of profiles 1, 2, 4, 5, 6, 7, 11 and 22 including check and protect functions for one single data transfer. The appropriate profile is to be selected according to the used physical bus layer and the size of the transferred data.
• An optional state machine describing the logical algorithm of E2E monitoring and state handling for a number of data transfers between two dedicated communication partners independent of the used profile.

E2E 协议提供了

• 用于检测 4.1 中所列通信故障子集的机制。相关的通信故障取决于通信的类型 (如周期性、非周期性、发送方 / 接收方等)。
• 定义 1、2、4、5、6、7、11 和 22 的配置文件，包括单个数据传输的检查和保护功能。应根据使用的物理总线层和传输的数据大小选择适当的配置文件。
• 一个可选的状态机，描述了 E2E 监控和状态处理的逻辑算法，用于两个专用通信伙伴之间的一系列数据传输，而不考虑使用的配置文件。

Note: Additional architectural measures may be necessary to ensure safe operation of the E2E protocol implementation.

注：可能需要额外的架构措施来确保 E2E 协议实现的安全运行。

# 4.3.1 E2E protection concepts

An E2E protection concept is more than just adding adequate safety mechanisms to data elements (e.g. using E2E Profile 1 or 2).

E2E 保护概念不仅仅是为数据元素添加足够的安全机制 (例如使用 E2E Profile 1 或 2)

To ensure the integrity of a communication channel with the required safety integrity level acc. to ISO 26262 the E2E protection concept needs to consider the safety-related properties of the data transmitted via a bus network that requires protection.

为了确保与 ISO 26262 要求的安全完整性级别相对应的通信通道的完整性，E2E 保护概念需要考虑通过需要保护的总线网络传输的数据的安全相关属性。

Basic principles to implement an E2E protection concept that focuses on correctness, consistency, completeness, timeliness and the detection of non-availability of data are provided in this chapter.

本章提供了实现以正确性、一致性、完整性、及时性和检测数据不可用性为重点的 E2E 保护概念的基本原则。

Note: For an E2E protection concept that focuses on ensuring the availability of data, an implementation of the communication channel with a sufficient fault tolerance is needed (e.g. using independent redundant channels).

注：对于侧重于确保数据可用性的 E2E 保护概念，需要实现具有足够容错能力的通信信道 (例如，使用独立冗余信道)

Note: The usage of redundant communication channels may create a need for additional safety mechanisms (e.g. to ensure the consistency of the data streams when transmitted independently).

注：使用冗余通信信道可能需要额外的安全机制 (例如，在单独传输时确保数据流的一致性)。

Typical basic principles for effective E2E protection concepts are :

有效的 E2E 保护概念的典型基本原则是:

• The infrastructure used for data transmission (e.g. Buses, Gateways, etc.) is designed and implemented in such way that it cannot systematically interfere with the used E2E protection (e.g. by unpacking and changing protected data).

  用于数据传输的基础设施 (例如，总线、网关等) 的设计和实现方式不能系统性地干扰所使用的端到端保护 (例如，通过解包和更改受保护的数据)

• In case of an internal fault during provision of data, the provider (e.g. sender or client) ensures that it sends out either data explicitly labeled as invalid (i.e. only the specific data elements that are possibly affected by this internal fault) or else no data (i.e. fail-safe respectively fail-silent behavior of sender in case of a severe fault).

  在数据提供过程中发生内部故障的情况下，提供者 (例如发送方或客户端) 确保它发送出明确标记为无效的数据 (即，只有可能受到此内部故障影响的特定数据元素) 或者不发送任何数据 (即，严重故障情况下发送方的故障安全或故障静默行为)。

• In normal operation mode, 在正常运行模式下

  • the provider (e.g. sender or client) of the data

    数据的提供者 (例如发送者或客户端)

    • groups the data as pre- determined (e.g. to ensure consistency for a set of data) and protects the grouped data with suitable protection mechanisms prior to their transmission.

      将数据按预先确定的顺序分组 (例如，确保一组数据的一致性)，并在传输前用合适的保护机制保护分组的数据。

    • ensures that it sends out valid data, only. In this context valid data means:

      确保它仅发送有效数据。在此上下文中，有效数据意味着:

      • Data fully complying with their required safety-related properties

        数据完全符合其所要求的安全特性

      • Data complying with their required safety-related properties to the extent signaled by an additionally provided qualifier (i.e. signal qualifier)

        在额外提供的限定符 (即信号限定符) 所示的范围内，数据符合其所需的安全相关特性

      • Data explicitly labeled as invalid data (e.g. using a signal invalid value)

        明确标记为无效数据的数据 (例如使用信号无效值)

    • ensures in case of periodic/ mixed periodic communication that it sends out valid data on a regular basis (e.g. cyclic).

      在周期性 / 混合周期性通信情况下，确保它定期 (例如循环) 发送有效数据。

  • the consumer (e.g. receiver, client or server) of the data

    数据的消费者 (如接收器、客户端或服务器)

    • monitors whether new data has arrived on a regular basis (e.g. cyclic) independently from an external trigger condition coming from elements to which it wants to achieve freedom from interference (e.g. communication stack)

      监视新数据是否定期 (例如周期性地) 到达，而不受外部触发条件 (例如通信堆栈) 的影响。

    • is able to detect relevant communication faults within its determined time interval by evaluating the protection mechanisms of the received data and in case of periodic/ mixed periodic communication its internal timeout monitoring.

      通过评估接收数据的保护机制，并在周期性 / 混合周期性通信的情况下进行内部超时监控，能够在其确定的时间间隔内检测到相关的通信故障。

• In case a communication fault is detected 如果检测到通信故障

  • the consumer of the protected data (e.g. receiver, client or server) autonomously initiates the necessary reactions to mitigate the detected communication fault within its determined time interval in compliance with the functional safety concept of the system (i.e. fail-safe respectively fail-silent behavior of receiver).

    受保护数据的消费者 (例如接收器、客户端或服务器) 根据系统的功能安全概念 (即接收器的故障安全或故障沉默行为) 在确定的时间间隔内自主启动必要的反应，以减轻检测到的通信故障。

• Based on the ISO26262 the fault tolerance time interval (FTTI) of the respective safety-related system is the allowed time interval for fault detection and mitigationincluding the relevant data exchange part and the corresponding communication path.

  基于 ISO26262，各安全相关系统的容错时间间隔 (FTI) 是允许故障检测和缓解的时间间隔，包括相关数据交换部分和相应的通信路径。

  • The fault tolerance time interval concerning the whole system (absolute FTTI), the allowed time interval includes the allowed time interval for the detection and mitigation of faults at the provider of the date (e.g. sender), the time interval required for robustness of data transmission during normal operation (e.g. to compensate gateways) and the allowed time interval for the detection and mitigation of faults at the consumer of the data (e.g.receiver).

    关于整个系统的容错时间间隔 (绝对 FTTI)，允许的时间间隔包括在数据提供商检测和缓解故障的允许的时间间隔。(例如发送方)、在正常操作期间数据传输的稳健性所需的时间间隔 (例如补偿网关) 以及在数据的消费者 (例如接收方) 检测和缓解故障的允许时间间隔。

  • The fault tolerance time interval concerning the data exchange part and the corresponding communication path only (relative FTTI), corresponds to the maximum tolerated duration of erroneous data, and is thus the allowed time interval for the detection and mitigation of faults at the consumer of the data (e.g. receiver).

    仅涉及数据交换部分和相应通信路径的容错时间间隔相对 FTTI) 对应于错误数据的最大容忍持续时间，因此是检测和缓解数据使用者 (例如接收者) 故障的允许时间间隔。

# 4.3.2 Integrity of a communication channel

To determine the integrity of communication and to distinguish if the received data are valid the consumer of the data (e.g. receiver) can:

为了确定通信的完整性并区分所接收的数据是否有效，数据的消费者 (例如接收器可以:

• evaluate each received protected message separately and

  分别评估每个接收到的受保护消息，并

• monitor all evaluation results of a number of protected data received within a determined time interval for error detection and qualification t**EDQ up to the data received at last.

  监控在确定时间间隔内接收到的多个受保护数据的所有评估结果，以便检测错误并限定 tEDQ，直至最终接收到的数据。

To implement the monitoring function the consumer of the protected data (e.g. receiver) creates a history of the received data. Valid received data are stored with a history as follows:

为了实现监视功能，旁受保护数据的消费者 (例如接收器) 创建接收数据的历史记录。有效的接收数据用历史记录存储如下:

• Generation 0 is the latest (up to date) received valid data

  Generation 0 是最新 (截至日期) 收到的有效数据

• Generation 1 is the second-latest received valid data

  Generation 1 第二个最新收到的有效数据

• Generation 2 is the third-latest received valid data

  Generation 2 是第三个最新收到的有效数据

• etc.

To do so, each recently received valid message is stored as Generation 0 having a reference value indicating its age set to 0. Every time the consumer of the protected data (e.g. receiver) checks for reception of new data it increments the age of its already received data by 1.

为此，每个最近收到的有效消息都被存储为具有指示其年龄设置为 0 的参考值的第 0 代。每次受保护数据 (例如接收器) 的消费者检查新数据的接收情况时，它都会将其已接收数据的年龄增加 1。

Stored data can be used as basis for a safety related functionality provided by the consumer of the protected data (e.g. receiver) as long as its age reference value is less a determined boundary value N.

只要其年龄参考值小于确定的边界值 N，存储的数据就可以用作由受保护数据 (例如接收器) 的消费者提供的安全相关功能的基础。

The parameter N can be derived by dividing the determined time interval for error detection and qualification tEDQ with the cycle time used for its regular transmission (e.g. for a receiver having a tEDQ = 160ms and a regular cycle time of 20ms the value N = 160ms/20ms = 8).

参数 N 可以通过将确定的用于错误检测和确认的时间间隔 tEDO 除以用于其常规传输的周期时间 (例如，对于具有 tEDO=160ms 和常规周期时间为 20ms 的接收器，值 N=160ms/20ms=8) 来推导。

In case that sufficiently up to date data is no longer available, the consumer’s (e.g. receiver’s) application applies a safe reaction determined in the safety concept. Such reaction can be a degraded mode.

如果不再有足够的数据可用，则消费者 (例如接收器) 的应用程序将应用安全概念中确定的安全反应。这种反应可以是降级模式。

# 6 Requirements Specification

# 6.1 Functional Requirements

# Supported communication models and features

E2E protocol is defined to support different types of message-based communication.
Signal-based communication:

• periodic/mixed periodic sender/receiver communication

Service-oriented communication:

• periodic/mixed periodic event-based communication
• non-periodic method-based communication (client-server communication)

E2E 协议被定义为支持不同类型的基于消息的通信。基于信号的通信:

• 周期性 / 混合周期性发送方 / 接收方通信

面向服务的沟通:

• 基于周期 / 混合周期事件的通信
• 基于非周期方法的通信 (客户端 - 服务器通信)

[RS_E2E_08540] E2E protocol shall support protected periodic/mixed periodic communication

The E2E protocol shall support protected periodic communication.

This includes the following periodicity:

• periodic
• mixed periodic

E2E 协议应支持受保护的定期通信。

Use Case:

• Sender/receiver communication in CP, e.g. the following use cases
  • Receiver being invoked independently from sender
  • Receiver being invoked on arrival of data
  • Mixed: Receiver being invoked when data arrives and independently.)
• Events implement message-oriented communication in AP service interfaces.

CP 中的发送方 / 接收方通信，例如以下用例

• 接收器被调用，独立于发送器
• 数据到达时调用接收器
• 混合：在数据到达时单独调用接收器。

事件在 AP 服务接口中实现面向消息的通信。

[RS_E2E_08541] E2E protocol shall support protected non-periodic communication

[RS_E2E_08542] E2E protocol shall support dynamic restart of communication peers

[RS_E2E_08543] E2E protocol shall support variable length of transmitted data

# E2E detected faults

E2E protocol is defined to cover a number of faults described in 4.1. However, it depends on the type of communication which kind of faults can be detected, e.g. for non-periodic event-based communication loss of communication data cannot be detected by E2E protocol mechanisms.

E2E 协议被定义为涵盖 4.1 中描述的一些故障。然而，它取决于通信类型，哪种类型的故障可以被检测到，例如，对于基于非周期性事件的通信，通信数据的丢失不能被 E2E 协议机制检测到。

[RS_E2E_08544] E2E protocol shall provide a timeout detection mechanism

Note: A timeout detection mechanism to identify lost or delayed method responses in non-periodic method communication cannot be provided by an E2E protocol specification. This kind of mechanism has to be specified and implemented either by the application itself or as part of communication management functionality

注意：E2E 协议规范不能提供一种超时检测机制来识别非周期性方法通信中丢失或延迟的方法响应，这种机制必须由应用程序本身指定和实现，或者作为通信管理功能的一部分

[RS_E2E_08545] E2E protocol shall provide a detection mechanism for corrupted data

损坏数据检测机制

[RS_E2E_08546] E2E protocol shall provide a detection mechanism for masquerade or incorrect addressing

E2E 协议应提供伪装或地址错误的检测机制

[RS_E2E_08547] E2E protocol shall provide a detection mechanism for repetition, insertion or incorrect sequence of data

E2E 协议应提供对重复、插入或数据序列不正确的检测机制

# E2E Algorithms and Profiles

E2E protocol is defined to cover various sizes of exchanged data and different types of physical bus medium. Therefore, a number of E2E profiles are created. Each E2E profile provides a set of E2E measures as required in 6.1.2.

E2E 协议的定义涵盖了各种大小的交换数据和不同类型的物理总线介质，因此创建了许多 E2E 配置文件，每个 E2E 配置文件的 6.1.2 要求提供一组 E2E 措施。

[RS_E2E_08528] E2E protocol shall provide different E2E profiles

E2E protocol shall provide E2E profiles, where each E2E profile completely defines a particular safety protocol (including header structure, behavior as state machine, error handling etc).

E2E 协议应提供 E2E 配置文件，其中每个 E2E 分布文件完全定义了特定的安全协议 (包括头结构、状态机行为、错误处理等)。

Each E2E profile shall be an efficient solution for a particular communication stack used underneath (which are either FlexRay, CAN, CAN FD, LIN or Ethernet), used data length and data frequency, and the required integrity level (see [1]) of the exchanged data.

每个 E2E 配置文件都是针对特定通信堆栈 (FlexRay、CAN、CAN FD、LIN 或以太网) 使用的数据长度和数据频率以及所需完整性级别 (见 6.1.1) 的高效解决方案 [1]) 交换的数据。

Note: Each communication stack (e.g. FlexRay) has different BER, which depends on, for example:

注意：每个通信堆栈 (例如，FlexRay) 具有不同的 BER，这取决于，例如:

• Bit error rate on channel 信道比特出错率
• FIT values of HW 硬件的匹配值
• Number of ECUs ECU 数目
• Topology (e.g. CAN->Gateway->FR) 拓扑 (例如 CAN-> 网关 ->FR)
• Open/closed transmission system 开放式 / 闭式传动系统

The profiles are supposed to cover typical combinations of above factors.

概况应涵盖上述因素的典型组合。

# Use Case:

• E2E profile with 8-bit CRC for CAN/CAN FD
• E2E profile with 16-bit CRC for long FlexRay signals,
• E2E profile with 32/64-bit CRC for Ethernet.

[RS_E2E_08530] Each E2E profile shall define a set of protection mechanisms
and its behavior

Each E2E profile defined shall:

• Define precisely a set of mechanisms (e.g. CRC of a particular polynomial).
• 精确定义一组机制 (例如特定多项式的 CRC)
• Define its behavior in a semi-formal way (including state machines, error handling etc.).
• 以半形式化的方式定义其行为 (包括状态机、错误处理等)

Note: For CP the E2E profiles are provided within the E2E library

[RS_E2E_08549] Each E2E profile shall have a unique Profile ID

[RS_E2E_08529] Each E2E profile shall use an appropriate subset of specific protection mechanisms

Each of the defined E2E profiles shall use an appropriate subset of the following mechanisms:

每个定义的 E2E 简介应使用下列机制的适当子集:

• Sequence counter with different sizes (alternatively used as alive counter)

  不同大小的序列计数器 (可作为活计数器使用)

• CRC with different Bit length

  具有不同比特长度的 CRC

• IDs: Source ID, Destination ID, Data ID

  ID: 源 ID，目标 ID，数据 ID

• Timeout

• Length

In other words, mechanisms not listed shall not be used. In each E2E profile, the sequence counter and IDs, if used, should be all part of the transmitted data element. However, it is allowed that in a given profile, the sequence counter and/or IDs are “hidden” (not transmitted), but included in the checksum.

换句话说，不应使用未列出的机制。在每个 E2E 配置文件中，如果使用序列计数器和 ID，则它们应该是传输数据元素的一部分。但是，允许在给定的配置文件中 “隐藏”(不传输) 序列计数器和 / 或 ID，但将其包含在校验和中。

[RS_E2E_08533] CRC used in a E2E profile shall be different than the CRC used by the underlying physical communication protocol

CRC used in each E2E profile shall be different than the CRC used by the underlying communication protocols (FlexRay, CAN, CAN FD, LIN, Ethernet), for which the given profile is supposed to be used with.

每个 E2E 配置文件使用的 CRC 应与底层通信协议 (FlexRay、CAN、CAN FD、LIN、以太网) 使用的 CRC 不同，该配置文件应与之配合使用

Using the same polynomials twice (once in com stack and again in E2E) provides significantly lower joint detection rate than using two different polynomials.

与使用两个不同的多项式相比，两次使用相同的多项式 (一次在 com 栈中，- 次在 E2E 中) 的联合检测率要低得多。

[RS_E2E_08534] E2E protocol shall provide E2E Check status to the application

有个校验状态

RS_E2E_08548 E2E protocol shall provide E2E overall state to the application

有一个总体状态

[RS_E2E_08539] An E2E protection mechanism for inter-ECU communication of short to large data shall be provided

The E2E protocol shall support protection of short (ex. 8 bytes) and large (ex.4KB, up to 4MB, as application requires), composite data with dynamic-length over TCP/IP and over LIN/CAN/CAN TP/CAN FD/FlexRay/Ethernet.

E2E 协议应支持在 TCP/IP 和 LIN/CAN/CAN TP/CAN FD/FlexRay/ 以太网中保护短 (例如 8 字节) 和大 (例如 4KB，最多 4MB，根据应用程序要求) 的动态长度复合数据。

Note: The max length of protected data depends on the architecture and needs to be evaluated by quantitative analysis within the project using the E2E protocol profile.

注意：受保护数据的最大长度取决于架构，需要在项目中使用 E2E 协议简介进行定量分析来评估。

[RS_E2E_08550] The implementation of the E2E Supervision shall provide at least one of the E2E Profiles

# 6.2 Safety applicability and overall safety assumptions

[RS_E2E_08527] Implementation of E2E protocol shall fulfill ISO 26262

E2E communication protection is state-of-art in automotive safety-related series products.

E2E 通信保护是汽车安全相关系列产品中最先进的。

# 6.3 E2E Transformer

The E2E Transformer is invoked via RTE and it is placed between the RTE and E2E Library. It is responsible for the configuration and state management of the E2E protection.

E2E Transformer 是通过 RTE 调用的，它位于 RTE 和 E2E 库之间。它负责 E2E 保护的配置和状态管理。

[RS_E2E_08538] An E2E Transformer shall be provided

# 6.4 E2E Library

The E2E Library provides a set of safety protocols, in a form of library functions invoked by SW-Cs. It provides:

• E2E profiles 1, 2, 4, 5, 6, 7, 11, 22.
• E2E state machine

Note:

Each communication stack (e.g. FlexRay) has different error rates which depend on

for example:

• Bit error rate on channel
• FIT values of HW
• Number of ECUs
• Topology (e.g. CAN->Gateway->FR)
• Open/closed transmission system
• Frequency of safety related messages

The profiles, based on proven-in-use solutions, are supposed to cover typical combinations of above factors.

[RS_E2E_08531] E2E Library shall call the CRC routines of CRC library

[RS_E2E_08537] SW-Cs shall tolerate a number of invalid/corrupted received data elements

要允许接收一些无效 / 损坏的元素

SW-Cs shall tolerate a number of data elements that are invalid/corrupted but not detected by E2E as defined in architecture specific safety analysis for the used E2E protocol.

SW-C 应容忍许多无效 / 损坏但未被 E2E 检测到的数据元素，如所用 E2E 协议的架构特定安全分析中所定义。

Requiring that 100% errors are detected by E2E protocol has high impact on implementation of E2E library (e.g. requiring SW or/and HW redundancy) and suitability of applied E2E profile. Allowing at least one invalid signal (in a sequence of received signals) that is not detected by E2E mechanisms enables for instance the usage of profiles that contain shorter CRCs like E2E profiles 01, 11 and 02, 22.

要求 E2E 协议检测 100% 的错误会对 E2E 库的实现 (例如，要求 SW 或 / 和 HW 冗余) 和适用的 E2E 配置文件产生很大影响。允许至少一个无效信号 (在接收到的信号序列中) 未被 E2E 机制检测到，例如可以使用包含较短 CRC 的配置文件，如 E2E 配置文件的 01、11 和 02、22。

# 三、LogAndTrace

# 1 Scope of Document

This following specification defines the functional and non-functional requirements of Log and Trace (LT) for AUTOSAR.

The focus of this document is to specify the requirements for:

• The interface of LT to other CP:BSW modules / AP:Functional Clusters
• The interface to CP:RTE/VFB / AP:ARA Tracing
• The interface to CP:SWCs / AP:Applications
• The transmission and storage format of the log and trace messages
• The internal interface to the LT communication module
• The general configuration of LT

The document does NOT specify the requirements for:

• The transport layer of the communication over the LT communication module

以下规范定义了 AUTOSAR 的日志和跟踪 (LT) 的功能性和非功能性要求。
本文件的重点是明确以下方面的要求:

• LT 与其他 CP:BSW 模块 / AP: 功能集群的接口
• 与 CP:RTE/VFB/AP:ARA 的接口追踪
• 与 CP:SWCS/AP: 应用程序的接
• 日志和跟踪消息的传输和存储格
• LT 通信模块的内部接口
• LT 的一般配置

该文件没有为以下方面规定要求:

• LT 通信模块上的通信传输层

# 4 Requirements Specification

# 4.1 Functional Overview

LT provides a generic Logging and Tracing functionality for Applications and other modules.

LT 为应用程序和其他模块提供了通用的日志和追踪功能。

Generally, LT provides the following functionalities:

般来说，LT 提供以下功能:

• Logging

  • Logging of errors, warnings and info messages from AUTOSAR Applications, providing a standardized AUTOSAR interface

    记录来自 AUTOSAR 应用程序的错误、警告和信息消息，提供标准化的 AUTOSAR 接口

  • Gather all LT messages from all AUTOSAR Applications Level and Middleware Level software in a centralized AUTOSAR module (DLT).

    在一个集中的 AUTOSAR 模块 (DLI) 中，从所有的 AUTOSAR 应用层和中间件层软件中收集所有 LT 消息。

  • Log messages from DET[3], DEM[4] (Classic Platform)

    DET 发送的日志消息 [3],DEM4

• Tracing

  • Trace RTE/VFB ([5]) (Classic Platform)

    追踪 RTE/VFB ([5])(经典平台)

• Control

  • Enable/Disable individual LT messages

    启用 / 禁用单个 LT 消息

  • Control trace levels individually by back channel

    通过 back channel 单独控制 trace 级别

• Generic

  • LT available during debugging and production phase

    LT 可在调试和生产阶段使用

  • Access over standard diagnosis or platform specific test interface

    通过标准诊断或平台特定测试接口访问

  • Security mechanisms to prevent misuse in production phase

    防止生产阶段误用的安全机制

In addition, the following functionalities are provided for the Adaptive Platform:

• Timestamps

  • In case a timestamp is required, the LT module provides the possibility of time-stamping both the logging as well as the tracing messages.

    如果需要时间戳，LT 模块提供了对日志记录和跟踪消息进行时间戳的可能

  • Such timestamping is handled directly by the LT module, without any needed intervention from the application.

    此时间戳由 LT 模块直接处理，不需要应用程序进行任何必要的干预。

• Application communication tracing

  • The LT module is capable of handling the tracing of the communication flow between multiple Adaptive Applications without further interaction of the applications being necessary.

    LT 模块能够处理多个自适应应用程序之间的通信流的跟踪，而不需要应用程序的进一步交互。

# 4.2 Functional Requirements

# 4.2.1 Log and trace interfaces

Logging shall support initialization and registration.

Logging shall enable applications to provide meta information.

Logging shall enable applications to provide Logging Information.

Logging shall enable tracing of communication between applications.

Logging shall support grouping of Logging Information.

Logging shall allow to select the destination of logging information.

Logging shall provide early logging capabilities.

The LT shall transmit log and trace messages from several sources over a communication interface to a receiving external client.

All log and trace messages sent by an ECU shall have a standardized transmission format and a standardized storage format.

Interface for Applications

Applications shall have the possibility to send log or trace messages to the LT module.

Logging shall provide an interface for logging information.

Logging shall be able to handle raw buffer content as logging information.

Logging shall enable applications to check the current severity level.

Logging shall provide conversion functions for hexadecimal and binary values.

The LT shall provide the actual set of log levels and the trace status to an Application.

For each Application the interface to LT shall be configured.

DET trace interface

Trace events from errors generated by BSW and Applications shall be forwarded to the LT module.

DEM trace interface

The DEM shall forward error events to the LT module.

RTE/VFB trace interface

RTE shall provide an interface for LT to trace RTE/VFB calls.

The LT shall implement an interface to trace the RTE/VFB.

A global switch shall be defined to switch on and off the RTE tracing.

The LT shall implement the handling of the RTE/VFB trace events.

LT shall provide a solution to trace events linked to implicit communication mechanism.

# 4.2.2 Format of log and trace message

The transmitted data shall be packetized.

The transport format shall be binary

The format shall deal with Big and Little Endianess.

Each log and trace message shall contain a timestamp, which will be added to the message during reception of the message in the LT module.

A global message counter shall be implemented, to detect messages loss.

For each log message, a log level shall be provided.

The log and trace message shall contain a parameter, which represents the source of the log and trace message.

There shall be a logical grouping for log messages by using different identifiers.

Each ECU shall have its unique ECU ID.

The payload shall transport the parameters of a log and trace message.

It shall be possible to transmit the parameters in a raw format.

There shall be the possibility to transmit the parameters with additional information about themselves (self-description).

It shall be possible to transmit ASCII text in log or trace messages.

The data in non-verbose mode shall be described by an extra file

Each message in non-verbose mode shall have a unique Message ID significant for identifying the source of the tracing.

# 4.2.3 Transport interfaces

Generic

A control message shall be implemented to permit the external client to evaluate the round trip time.

A protection against unauthorized access in production phase shall be provided.

Logging shall be able to monitor and shape the amount of LT log and trace events.

The LT shall be configurable at runtime.

A protocol shall be implemented to be able to set and query the trace status and log levels of log and trace sources of each ECU.

A list of all log and trace sources of an ECU shall be accessible from the external client.

Communication interface

LT shall support a generic API for communicating over a LT communication module.

DCM transport interface

The DCM shall provide an interface for LT to transport log and trace messages over a diagnostic session.

# 4.2.4 Operational function

Initialization and shutdown

The LT shall provide a buffer for storing log and trace messages before initialization

Normal operation

There shall be a buffer to store log and trace message locally.

A mechanism shall be implemented to be able to set the trace status and log levels of registered Application IDs and context IDs of each Application.

The LT shall provide the possibility to store configuration data in a persistent way.

The LT component shall be able to filter log and trace messages.

AUTOSAR Log and Trace shall support harmonized logging.

# 4.3 Non-Functional Requirements

[RS_LT_00041] LT shall be a central software component for the log and trace functionality.

[RS_LT_00042] The Log and trace SW component shall be part of the system during production phase.

[RS_LT_00059] LT shall provide an interface for trace points.

[RS_LT_00060] LT shall send modeled trace messages

[RS_LT_00061] Tracing shall be configurable at compile time

[RS_LT_00062] LT shall be configurable to use ARTI to process the tracing information

# 四、TimeSensitiveNetworkFeatures

# 1 Introduction

# 1.1 Objectives

Time-Sensitive Networking (TSN) is a set of standards specified by [1, IEEE 802.1 TSN Task Group]. It provides end-to-end data transmission with extremely low latency and high reliability over Ethernet.

时间敏感网络 (TSN) 是由 [1, IEEE 802.1 TSN Task Group] 指定的一组标准，它通过以太网提供端到端数据传输，具有极低的延迟和高可靠性。

As a result, TSN is considered as one of the key enabler for deterministic communication on standard Ethernet, which can further be used to accurate timing and guarantee data delivery for automotive Ethernet.

因此，TSN 被认为是标准以太网确定性通信的关键使能器之一，可以进一步用于精确定时和保证汽车以太网的数据传输。

# 4 Time Sensitive Network in AUTOSAR

# 4.1 Constraints and Assumptions

AUTOSAR does not support the following TSN features:

• time aware shapers
• active stream identification
• frame replication

AUTOSAR assumes that all Ethernet switches in the network are VLAN-aware. VLAN unaware Ethernet switches are not supported.

AUTOSAR 假设网络中的所有以太网交换机都了解 VLAN，不支持不了解 VLAN 的以太网 Switch。

# 4.2 Overview

TSN is a set of IEEE 802 standards based on Ethernet. It specifies functions to ensure the transmission with bounded low latency and high availability for applications in automotive or industrial control facilities.

TSN 是基于以太网的一套 IEEE802 标准，它规定了功能，以确保汽车或工业控制设施中的应用程序具有有限低延迟和高可用性。

The deterministic transmission of time-critical frames may be achieved by using TSN features of high reliability, low delay, zero packet loss through traffic shaping, seamless redundant transmission, filtering, priority-based scheduling, ingress policing and rate limitation.

通过流量整形、无缝冗余传输、过滤、基于优先级的调度、入口保护和速率限制，可以实现时间关键帧的高可靠性、低延迟、零包丢失的确定性传输。

# 4.2.1 IEEE 802.1AS

The basis of TSN standards is global time synchronization. It specifies the clock synchronization mechanism with switches as key nodes based on the data link layer.

TSN 标准的基础是全球时间同步。它规定了基于数据链路层的以交换机为关键节点的时钟同步机制。

IEEE802.1AS [4, IEEE Std 802.1AS] was mainly extended from the simplified version of the IEEE 1588 (Precision Time Protocol) and it is more suitable for communication transmission scenarios that require high real-time precision in vehicle networks.

IEEE802.1AS [4, IEEE Std 802.1AS] 主要是从 IEEE 1588 (精确时间协议) 的简化版本扩展而来，更适合车辆网络中需要高实时精度的通信传输场景。

# 4.2.2 IEEE 802.1Qav

IEEE 802.1Qav [6, IEEE Std 802.Qav] can be used to ensure that traditional asynchronous Ethernet data traffic does not interfere with AVB’s real-time audio and video streams.

IEEE 802.1Qav [6, IEEE Std 802.Qav] 可以用来确保传统的异步以太网数据流量不干扰 AVB 的实时音频和视频流。

To avoid competition for network resources between ordinary data traffic and AVB traffic, the AVB switch differentiates time-sensitive audio and video streams from ordinary data streams, queues real-time frames and asynchronous frames separately, and assigns the highest priority to real-time frames.

为了避免普通数据流量和 AVB 流量对网络资源的竞争，AVB 交换机将时间敏感的音频和视频流与普通数据流区分开来，分别排队实时帧和异步帧，并将最高优先级分配给实时帧。

Therefore a so-called Credit Based Shaper (CBS) could be used for bandwidth limitation to convergence time-sensitive and time-insensitive traffic.

因此，所谓的信贷基于整形器 (CBS) 可以用于带宽限制收敛时间敏感和时间不敏感的流量。

# 4.2.3 IEEE 802.1Qbv

IEEE 802.1Qbv [7, IEEE Std 802.Qbv] specifies the feature of time-aware shaping, which allows the scheduling of the transmission of frames with different priorities in time-triggered windows.

IEEE 802.1Qbv [7, IEEE Std 802.Qbv] 指定了时间感知整形功能，该功能允许在时间触发窗口中调度具有不同优先级的帧的传输。

Time-aware shaping divides time into fixed windows, and schedules the transmission of frames within these windows based on their priority.

时间感知成形将时间划分为固定窗口，并根据这些窗口的优先级安排帧的传输。

Time-critical frames are normally given with higher priority and transmitted in a separate window, while lower priority frames are transmitted in the remaining time.

时间临界帧通常具有较高的优先级，在单独的窗口中传输，而低优先级的帧则在剩余时间中传输。

# 4.2.4 IEEE 802.1Qcc

Most networks need to be configured while the network is down, which is not suitable for applications such as in industrial control and automotive network communication.

大多数网络需要在网络关闭时进行配置，这不适用于工业控制和汽车网络通信等应用。

IEEE 802.1Qcc [8, IEEE Std 802.Qcc] can be used to introduce a Centralized Network Configuration (CNC) and a Centralized User Configuration (CUC) to implement dynamic network configuration, and flexibly configure new devices and data flows when the network is running.

IEEE 802.1Qcc [8, IEEE Std 802.Qcc] 可用于引入集中式网络配置 (CNC) 和集中式用户配置 (CUC)，以实现动态网络配置，并在网络运行时灵活配置新设备和数据流。

# 4.3 Usage of Shapers in the Network

# 4.3.1 Asynchronous Traffic Shaping

Overview

Asynchronous Traffic Shaping (ATS) is specified by [9, IEEE Std 802.1Qcr-2020] and provides a traffic shaping concept that can provide bounded latencies for data streams in a network.

异步流量整形 (ATS) 由 [9, IEEE Std 802.1Qcr-2020] 规定，并提供了一个流量整形概念，可以为网络中的数据流提供有界延迟。

It avoids bursts and provides a fair usage of the egress port for streams arriving on different ingress ports. This is a main difference between the Credit Based Shaper (CBS) and ATS, as CBS only considers a particular traffic class of an egress port.

它避免了突发，并为到达不同入站端口的流提供了出站端口的公平使用。这是基于信用的整形器 (CBS) 和 ATS 之间的主要区别，因为 CBS 仅考虑出站端口的特定流量类别。

The algorithm is loosely based on the token bucket algorithm and uses similar terminology for the configuration parameters.

该算法大体上基于令牌桶算法，并对配置参数使用类似的术语。

ATS is divided into two major functional blocks, one, the ”ATS Eligibility Time Assignment” situated on the ingress side of a bridge, operating on streams identified by the stream filters using the stream_handle and priority, includes the computational part of the shaping function.

ATS 分为两个主要功能块，一个 “ATS 资格时间分配” 位于桥梁的入口侧，使用流过滤器、流句柄和优先级对识别的流进行操作，包括整形函数的计算部分。

This means it calculates an eligibility time for every frame received based on the ATS algorithm. The eligibility time is the time when a frame is eligible for transmission on the egress port.

这意味着它根据 ATS 算法为接收到的每个帧计算合格时间，合格时间是指一个帧有资格在出口端口传输的时间。

The other functional block, the ”ATS transmission selection algorithm” is situated on the egress side and shapes the traffic according to the results calculated by the ”ATS Eligibility Time Assignment”.

另一个功能块，“ATS 传输选择算法” 位于出口侧，并根据 “ATS 资格时间分配” 计算的结果来形成流量。

As the eligibility times of frames of streams from different receive ports can be in non-decreasing order, ATS queues need to support non-FIFO queues.

Guidance on the configuration

之后再细化

# 4.3.2 Credit Based Shaper

Overview

The Credit Based Shaper (CBS) is specified by [6, IEEE Std 802.Qav] and provides a traffic shaping concept for high priority, high data rate streams.

基于信用整形器 (CBS) 是指定的 [6, IEEE Std 802.Qav] ，并提供了一个高优先级，高数据速率流的流量整形概念。

It was specified as part of the Audio Video Bridging (AVB) standards. The behavior is similar to ATS, but the CBS is operating only on Traffic Classes on the egress side of a bridge.

它被指定为音视频桥接 (AVB) 标准的一部分。其行为类似于 ATS 但 CBS 仅在桥梁出口侧的交通类别上运行。

Therefore, there is no differentiation between individual streams within the traffic class as well as different ingress ports.

因此，在交通类别的单个流以及不同的入境口岸之间没有区别。

As a consequence, the Credit Based Shaper is strictly operating on the order frames are received on all ports, there is no reordering of frames received on different ports.

因此，基于信用的整形器是严格操作在所有端口接收的顺序帧，没有在不同端口接收到的帧的重新排序。

The Credit Based Shaper minimizes bursts and therefore protects lower priority traffic from the high priority CBS shaped traffic.

基于信用的塑形器最小化突发事件，因此保护低优先级的流量从高优先级的 CBS 塑形流量。

The CBS only exists as one functional block (per traffic class) that is located on the egress side of a bridge port and makes frames available for transmission selection based on a credit value.

CBS 仅作为一个功能区块存在 (每种交通类别)，位于桥梁 port 出口侧，为基于信用值的传输选择提供框架。

If there is zero or positive credit, frames are available for transmission, in case there is negative credit, frames of the associated traffic class are not available for transmission selection.

如果信用为零或正信用，则可使用帧进行传输，如果信用是负的，则不可使用关联的通信类别的帧进行传输选择。

The idleSlope is the main parameter that defines the rates with which credit is accumulated and reduced, and thereby it directly controls the data rate of the assigned traffic class on a port.

空闲斜率是定义信用累积和减少速率的主要参数，因此它直接控制 port 上指定的交通类别的数据速率。

# 4.4 Ensure Accuracy of Time Synchronization

Recommendations to support accuracy in an Ethernet network

以太网中支持准确性的建议

Parts in Documents which Reflect Accuracy

In Time Synchronization Protocol Specification [10]:

Time Master and Time Slave shall work with a Time Base reference clock accuracy as defined in [4, IEEE 802.1 AS], ANNEX B.1.2 "Time measurement granularity".

时间同步协议规范 [10]:
时间主控器和时间从控器应使用 [4, IEEE 802.1 AS] 附件 B.1.2 “时间测量粒度” 中定义的时基基准时钟精度工作。

In Specification of Time Synchronization over Ethernet [11]:

Automotive systems requiring a common Time Base for ECUs regardless of which bus system the ECUs are connected to.

以太网时间同步规范 [111:
汽车系统要求 ECU 的通用时间基准，无论 ECU 连接到哪个总线系统。

System requirements

TSN uses gPTP protocol (IEEE 802.1AS) to get precise timestamps for the nodes in the Network. IEEE 802.1AS also targets at accuracy of +/-500ns between any two nodes over 7 hops for Audio Video Bridging using 100 Mb/s links.

TSN 使用 gPTP 协议 (IEEE802.1AS) 为网络中的节点获取精确的时间。IEEE 802.1AS 还针对使用 100Mb/s 链路进行音频视频桥接的任何两个节点之间的精度为 +/-500 ns。

That means, the hardware has to support the global time on Ethernet with an end to end accuracy of +/- 500ns, where end to end describes a network path from a data producer to a data consumer (e.g. from audio source to an audio sink).

这意味着，硬件必须支持以太网上的全局时间，端到端精度为士 500ns，其中端到端描述从数据生产者到数据消费者 (例如从音频源到音频汇) 的网络路径。

# 4.5 Measurement of the Time Synchronization Quality (Accuracy)

Overview

The quality of time synchronization needs to be measured in order to assess if devices meet requirements for gPTP recovered clock quality.

需要测量时间同步的质量，以评估设备是否满足 gPTP 恢复的时钟质量的要求。

The traditional approach to measure the accuracy of the clock synchronization is the 1 Pulse Per Second (1PPS) method.

测量时钟同步精度的传统方法是每秒 1 脉冲 (1PPS) 法。

The PPS signal must be driven by a hardware clock in all participating devices so that it generates a pulse every full second.

PPS 信号必须由所有参与设备的硬件时钟驱动，以便每整秒产生一个脉冲。

If this is done for multiple hardware clocks in a distributed system their synchronization accuracy can be checked on a measurement device like a scope by measuring the distance of PPS pulses originating from different devices.

如果在分布式系统中为多个硬件时钟执行此操作，则可以通过测量来自不同设备的 PPS 脉冲的距离来检查它们的同步准确性，例如示波器。

After their clocks have been correctly synchronized, the PPS pulses triggered every second should only have a marginal time distance in a successful scenario.

在它们的时钟正确同步之后，在成功的情况下，每秒触发的 PPS 脉冲应该只有边际时间距离。

However, the 1PPS method is not feasible for automotive environment, where using a separate output pin for generating the 1PPS signal on the ECU is considered costly.

然而，1PPS 方法在汽车环境中不可行，因为使用单独的输出引脚在 ECU 上产生 1PPS 信号被认为是昂贵的。

Furthermore, static offset in the internal clock of a slave may exist and can be canceled out by an opposite static offset in the logic that drives the 1PPS output.

此外，slave 内部时钟中的静态偏移可能存在，并且可以被驱动 1PPS 输出的逻辑中的相反的静态偏置抵消。

This will result in an error condition that cannot be observable by using 1PPS measurement method.

这将导致使用 1PPS 测量方法无法观察到的误差情况。

In order to mitigate the flaws from 1PPS measurement, Advance methods like Ingress Reporting Method and Reverse Sync Method may be considered for alternative measurement methods. More details for Ingress Reporting Method and Reverse Sync Method, please refer to [12, 802.1AS Recovered Clock Quality Testing].

为了减轻 1PPS 测量的缺陷，可以考虑使用 Ingress ReportingMethod 和 Reverse Sync Method 等先进的方法作为替代的测量方法。有关 IngressReporting Method 和反向同步方法的更多详细信息，请参见 [12, 802.1AS Recovered Clock Quality Testing]。

Usage of PPS

# 五、MACsec

# 1 Scope of Document

This document specifies requirements on MACsec protocols in the AUTOSAR Foundation.

The motivation is to specify the usage of:

• IEEE 802.1AE (also known as MACsec) protocol.
• MACsec Key Agreement protocol (standardized in IEEE 802.1X).

本文档指定了 AUTOSAR 基金会对 MACsec 协议的要求。目的是明确下列各项的用法:

• IEEE802.1AE (也称为 MACsec) 协议。
• MACsec 密钥协议协议 (在 IEEE802.1X 中标准化)。

# 4 Requirements Specification

# 4.1 Functional Overview

IEEE 802.1AE (also known as MACsec) is a network security standard that operates at the medium access control layer and defines connectionless data confidentiality and integrity for media access independent protocols.

IEEE 802.1AE (也称为 MACsec) 是一种在媒体访问控制层运行的网络安全标准，为媒体访问独立协议定义了无连接数据机密性和完整性。

The 802.1AE standard specifies the implementation of MAC Security Entities (SecY), which are part of the stations attached to the same LAN, providing secure MAC service to the client. The standard defines:

802.1AE 标准规定了 MAC 安全实体 (SecY) 的实现，它们是连接到同一局域网的站点的一部分，为客户端提供安全的 MAC 服务。该标准定义了:

• MACsec frame format, which is a valid Ethernet frame with a specific EtherType and includes the following additional fields:

  MACsec 帧格式，它是具有特定 EtherType 的有效以太网帧，并包括以下附加字段:

  • Security Tag, which is an extension of the EtherType.

    安全标签，它是 EtherType 的扩展。

  • Message authentication code (ICV).

    消息身份验证码 (ICV)

• Secure Connectivity Associations (CAs) that represent groups of stations connected via unidirectional Secure Channels.

  安全连接关联 (CAs)，表示通过单向安全通道连接的站组。

• Security Associations (SAs) within each Secure Channel. Each association uses its own key (SAK). More than one association is permitted within the channel for the purpose of key change without traffic interruption (standard requires devices to support at least two).

  每个安全通道中的安全关联 (SAs)。每个关联使用自己的密钥 (SAK)。通道中允许一个以上的关联，以便在不中断通信的情况下更改密钥 (标准要求设备至少支持两个)

• A default cipher suite of GCM-AES-128 (Galois/Counter Mode of Advanced Encryption Standard cipher with 128-bit key)

  一个默认的 GCM-AES-128 密码套件 (具有 128 位密钥的高级加密标准密码的 Galois/Counter 模式)

  • GCM-AES-256 using a 256-bit key is supported

MACsec allows unauthorized LAN connections to be identified and excluded from communication within the network. In common with IPsec and TLS, MACsec defines a security infrastructure to provide data confidentiality, data integrity, and data origin authentication.

MACsec 允许识别未经授权的 LAN 连接，并将其排除在网络内的通信之外。与 IPsec 和 TLS 一样，MACsec 定义了一个安全基础结构，可提供数据保密性、数据完整性和数据源身份验证。

By assuring that a frame comes from the station that claimed to send it (this might require additional mechanisms), MACsec can even mitigate attacks on Layer 2 protocols that cannot be protected otherwise. A scenario in which MACsec protects a layer 2 attack, is in case an intruder installs a device in the cable harness to launch a man-in-the-middle attack.

通过确保帧来自声称发送该帧的站 (这可能需要其他机制)，MACsec 甚至可以减轻无法以其他方式保护的 2 层协议的攻击。MACsec 保护 2 层攻击的情况是，如果入侵者在电缆线束中安装设备以发起中间人攻击。

In order to recognize participants belonging to the same Secure Connectivity Association (CAs), establish Secure Channels, and maintain them alive, the participants on the communication make use of the MACsec Key Agreement protocol (MKA). This protocol is described and specified in the IEEE 802.1X standard.

为了识别属于同一安全连接 (CAs) 的参与者、建立安全通道并使其保持活动状态，通信中的参与者使用 MACsec 密钥协议 (MKA)。该协议在 IEEE 802.1X 标准中进行了描述和指定。

# 4.1.1 Motivation

AUTOSAR supports actually several protocols to establish a secure communication channel which provide data confidentiality, data integrity and data origin authentication over Ethernet (e.g. IPsec, TLS, SecOC).

AUTOSAR 实际上支持几种协议，以建立安全通信通道，该通道在以太网 (例如 IPsec、TLS、SecOC) 上提供数据机密性、数据完整性和数据源身份验证。

The TLS protocol aims primarily to provide privacy and data integrity between two communication peers.

TLS 协议主要旨在提供两个通信同行之间的隐私和数据完整性。

If more than two communication peers need to exchange data in integrity protected way, for each peer connection an own TLS connection must be setup.

如果两个以上的通信对等方需要以受完整性保护的方式交换数据，则必须为每个对等方连接设置一个自己的 TLS 连接。

TLS is application protocol independent; higher-level protocols can layer on top of TLS transparently. TLS needs for each application-based session an own setup connection, which leads to a resource overhead.

TLS 是独立于应用程序协议的，更高级别的协议可以透明地叠加在 TLS 之上。TLS 需要为每个基于应用程序的会话设置自己的连接，从而导致资源开销。

Each session needs an own database entry for the negotiated key, the session status, and other organizational information.

每个会话都需要一个自己的数据库条目来存储商定的密钥、会话状态和其他组织信息。

To avoid the overhead introduced by the large number of required TLS connections it is possible to push the secure communication channel one level down, to the IP layer.

为了避免大量所需的 TLS 连接带来的开销，可以将安全通信通道向下推一级到 IP 层。

To secure the IP layer IPsec was introduced. IPsec includes protocols for establishing mutual authentication between hosts at the beginning of a session and negotiation of cryptographic keys to use during the session.

为了保证 IP 层的安全，引入了 IPsec 。IPsec 包括一些协议，用于在会话开始时在主机之间建立相互身份验证，以及谈判在会话期间使用的加密密钥。

IPsec can protect data flows between a pair of hosts (host-to-host), between a pair of security gateways (network-to-network), or between a security gateway and a host (network-to-host).

IPsec 可以保护一对主机 (主机对主机)、一对安全网关 (网络对网络) 或安全网关与主机 (网络对主机) 之间的数据流。

IPsec uses cryptographic security services to protect communications over Internet Protocol (IP) networks. It supports network-level peer authentication, data-origin authentication, data integrity, data confidentiality (encryption), and replay protection (RFC 4301).

IPsec 使用加密安全服务来保护 Internet 协议 (IP) 网络上的通信。它支持网络级对等认证、数据源认证、数据完整性、数据机密性 (加密) 和重播保护 (RFC4301)。

The advantage of IPsec, compared to TLS, is the reduced overhead, because IPsec combines all secure application channels to a single secure channel. However, IPsec has a negative impact in the typical automotive use case.

与 TLS 相比，IPsec 的优势在于减少了开销，因为 IPsec 将所有安全应用程序通道合并到一个安全通道中。然而，IPsec 在典型的汽车用例中会产生负面影响。

Since IPsec connects on a host-to-host level and in the automotive world it is sometimes not possible to use the Internet model, as the connectivity between hosts is higher.

由于 IPsec 是在主机对主机的级别上进行连接的，在汽车领域，由于主机之间的连接性较高，有时无法使用因特网模式。

Here, the numbers of connections will also increase the resources and key negotiations time by power of two when an additional peer joins the secure communication network.

在这里，当额外的同伴加入安全通信网络时，连接的数量也会增加资源和 key 协商时间的两倍。

Avoiding this overhead again is possible pushing the secure channel one level down, to the MAC layer. With security on the MAC layer, protocols not based on IP as well as protocols using multicast can be protected.

将安全通道向下推到 MAC 层可以再次避免这种开销。由于 MAC 层的安全性，不基于 IP 的协议以及使用组播的协议都可以得到保护。

The goal is to introduce the IEEE 802.1AE (MACsec) solution to reduce overhead in a meshed network layout and to reduce the timing issue during key negotiation by reducing the number of peers (peer per Ethernet port instead of peer per UDP/TCP port) and avoiding higher network stack layers.

目标是引入 IEEE 802.1AE (MACsec) 解决方案，以减少网状网络布局中的开销，并通过减少对等点数量 (每个以太网端口的对等点，而不是每个 UDP/TCP 端口的对等点) 和避免更高的网络堆栈层来减少密钥协商期间的时间问题。

Implementing the MACsec protocol in the AUTOSAR platform provides options to establish secure communication channels between network nodes with confidentiality and/or integrity.

在 AUTOSAR 平台中实现 MACsec 协议提供了在网络节点之间建立保密和 / 或完整的安全通信通道的选项。

This document deals with the realization of the functionality either in a MACsec aware hardware (PHY or specific controller) and MACsec software solution, and the interoperability of the different solutions with each other.

本文档涉及在 MACsec 意识硬件 (PHY 或特定控制器) 和 MACsec 软件解决方案中实现功能，以及不同解决方案之间的互操作性。

In the AUTOSAR Classic Platform an adaption of the MAC layer is needed to implement the IEEE 802.1AE solution.

在 AUTOSAR 经典平台中，需要对 MAC 层进行适配，以实现 IEEE 802.1AE 解决方案。

# 4.1.2 Functional elements

The standards related with MACsec ([3, IEEE-802.1AE-2018] and [4, IEEE-802.1X-2020]) define the following functional elements:

与 MACsec 相关的标准 ([3, IEEE-802.1AE-2018] 和 [4, IEEE-802.1X-2020]) 定义了以下功能元素:

• MAC Security Entities (SecYs): The SecY defines and identifies the authentic partners. A SecY implements the secure MAC Service to its clients. The MAC Security Entity is responsible of integrity protecting/validating and, if required, encrypt/decrypt to provide user data confidentiality. The SecY can be a SW or a HW implementation.

MAC 安全实体 (SeCYs):SecY 定义并识别真正的合作伙伴。SecY 向其客户端实现安全的 MAC 服务。MAC 安全实体负责完整性保护 / 验证，如果需要，加密 / 解密以提供用户数据的机密性。SecY 可以是软件或硬件实现。

• Port Access Entities (PAEs): The PAE provides mutual authentication of partici pants belonging to a secure Connectivity Association (CA), and agrees the cryptographic keys and related parameters to meet the requirements of the SecY.

端口接入实体 (PAEs):PAE 为属于安全连接 (CA) 的参与者提供相互认证，并同意满足 SecY 要求的加密密钥和相关参数。

• MAC Security Key Agreement Entities (KaYs): The KaY is the responsible for MKA within the PAE, it serves to setup a Secure Channel via a key agreement and monitors it during its life cycle.

MAC 安全密钥协议实体 (KaYs):KaY 是 PAE 中负责 MKA 的，它通过一个密钥协议建立一个安全信道，并在其生存周期内监视它。

• Secure Channel (SC): Stores various configuration parameters, such as whether to perform replay protection, or whether to enable encryption.

安全通道 (SC): 存储各种配置参数，如是否执行重播保护，或是否启用加密。

• Secure Association (SA): Security relationship under a Secure Channel. Each SA supports a different key. A Secure Channel supports several consecutive SAs to allow exchanging Keys without terminating the established Secure Channel.

安全关联 (SA): 安全通道下的安全关系。每个 SA 支持不同的密钥。安全通道支持多个连续的 SA，以允许在不终止已建立的 Secure Channel 的情况下交换密钥。

• MKPDU: MACsec Key Agreement Protocol Data Units.

MKPDU:MACsec 密钥协议数据单元。

• MACsec Protocol Data Units (MPDU): Defines the frame layout, which resides in the MAC layer (ISO/OSI layer 2).

MACsec 协议数据单元 (MPDU): 定义帧布局，它位于 MAC 层 (ISO/OSI 层 2)

The following terms identify roles within the protocol scenarios:

以下术语标识协议场景中的角色:

• Participant: The personification of a single KaY’s participation in a given MKA instance. It transmits and receives MKPDUs protected by keys derived from a single given CAK and identified by a Connectivity Association Key Name (CKN).

参与者：单个 KaY 参与给定 MKA 实例的拟人化。它发送和接收由单个给定 CAK 派生并由连接性关联密钥名称 (CKN) 标识的密钥保护的 MKPDUS。

• Key Server: Authenticated participant which generates and distributes the Secure Association Key to use in a Secure Channel. This participant decides the cipher suites to use.

密钥服务器：经过身份验证的参与者，生成并分发安全关联密钥，以便在安全通道中使用。该参与者决定使用密码套件。

• Peer: Authenticated participant which does not possess the Key Server role.

Peer: 不具有密钥服务器角色的经过身份验证的参与者。

The following keys are required for the MACsec and MKA communication:

MACsec 和 MKA 通信需要以下密钥:

• Secure Connectivity Association Key (CAK): Secret key possessed by members of a given CA. The CAK is identified by its respective secure Connectivity Association Key Name (CKN).

安全连接关联密钥 (CAK): 由给定 CA 成员所拥有的秘密密钥。CAK 由其各自的安全连接关联密匙名称 (CKN) 来识别。

• Integrity Check Value Key (ICK): Key derived from the respective CAK and used to transmit/validate Integrity protected MKPDUs.

完整性检查值密钥 (ICK): 源自相应 CAK 的密钥，用于传输 / 验证受完整性保护的 MKPDUs

• Key Encrypting Key (KEK): Key derived from the respective CAK and used to encrypt/decrypt a Secure Association Key (SAK).

密钥加密密钥 (KEK): 源自相应 CAK 的密钥，用于加密 / 解密安全关联密钥 (SAK)

• Secure Association Key (SAK): Key used by the MACsec Entity (SecY) to integrity protect/validate and/or encrypt/decrypt MPDUs belonging to an specific Secure Association. The SAK is generated by one MKA participant (Key Server) and distributed during the MKA sequence.

安全关联密钥 (SAK):MACsec 实体 (SecY) 用于完整性保护 / 验证和 / 或加密 / 解密特定安全关联的 MPDUs 的密钥。SAK 由 MKA 参与者 (密钥服务器) 生成，并在 MKA 序列中分发.

As depicted in Figure 4.2, the MKA protocol consists of three phases:

1. Authentication of participants. 身份验证
2. Session negotiation. 协商会话
3. Secure communication. 安全通信

Authentication of participants

During the first phase of the MKA sequence, the MKA Entity (KaY) identifies other participants belonging to its configured CA.

在 MKA 序列的第一阶段，MKA 实体 (KaY) 识别属于其配置的 CA 的其他参与者。

In the current version of this document, only pre shared keys authentication is supported and the participants possess fixed roles in the MKA sequence.

在本文档的当前版本中，只支持预共享密钥身份验证，参与者在 MKA 序列中拥有固定角色。

The participants of the MKA communication will identify and authenticate each other based on the CKN and ICV of the MKPDUs exchanged.

MKA 通信的参与者将根据所交换的 MKPDU 的 CKN 和 ICY 相互识别和认证。

Once a participant can successfully identify and authenticate another participant belonging to the same CA, the member identifier of the other participant is included in its transmitted “Potential Peer List”.

一旦参与者能够成功识别和验证属于同一 CA 的另一个参与者，另一个参与者的成员标识符将包含在其传输的 “潜在对等方列表” 中。

If a participant recognizes another one and it is listed in the others “Potential peer List”, it will mark it as Live participant. The Member Identifier of the other participant will be included in the transmitted “Live Peer List”.

如果参与者识别出另一个参与者并且它被列在 “潜在同行列表” 中，它将将其标记为 “现场参与者””。其他参与者的成员标识符将包含在传输的 “现场同行列表” 中。

Session negotiation

In the current version of this document, dynamic election of the Key Server member is not supported, and therefore each participant will currently configure in advance its role in the communication.

在本文档的当前版本中，不支持密钥服务器成员的动态选举，因此每个参与者将预先配置其在通信中的作用。

The participants can share the supported cipher suites by means of the “MACsec Cipher Suites Announcement”. The participant with the Key Server role will select a cipher suite and generate and distribute a Secure Association Key accordingly.

参与者可以通过 “MACsec 密码套件声明” 共享支持的密码套件。具有密钥服务器角色的参与者将选择密码套件，并相应地生成和分发安全关联密钥。

Both participants shall communicate the readiness to transmit and receive MACsec protected PDUs with the “MACsec SAK Use” parameter set.

双方参与者应通过 “MACsec SAK Use” 参数集通报发送和接收 MACsec 保护的 PDUs 的准备状态

During the Secure Channel life time, it is possible to distribute new SAKs (and therefore create a new SA) without a communication interruption. The participants can also detect if the communication partner is alive.

在安全通道有效期内，可以在不中断通信的情况下分发新的 SAKs (从而创建新的 SA)。参与者还可以检测通信伙伴是否存活。

In case a cipher suite with Extended Packet Number (XPN) is selected, additional parameter sets are exchanged during the Secure Channel life time to keep the channel information up-to-date.

如果选择了具有扩展数据包编号 (XPN) 的密码套件，则将在安全信道使用期内交换附加参数集，以保持信道信息的最新状态。

Secure communication

After the identification, mutual authentication, distribution of keys, and installation of keys, the secure communication can start based on the parameters exchanged in the previous phases.

在识别、相互认证、分配密钥和安装密钥之后，可以根据前几个阶段交换的参数开始安全通信。

# 4.2 Functional Requirements

# 4.2.1 Standards to support

[FO_RS_MACsec_00001] MACsec Protocol support

[FO_RS_MACsec_00002] MACsec Key Agreement Protocol support

# 4.2.2 Common Requirements

[FO_RS_MACsec_00003] Using MACsec on external communication links

[FO_RS_MACsec_00004] Configure which Ethernet ports use MACsec

[FO_RS_MACsec_00005] MACsec status control

[FO_RS_MACsec_00006] MACsec support for Adaptive AUTOSAR Platform

[FO_RS_MACsec_00007] Configuration of unprotected traffic (for Software-based MACsec)

[FO_RS_MACsec_00008] Configuration of unprotected traffic (for Hardware-based MACsec)

[FO_RS_MACsec_00009] MACsec Security Events

# 4.2.3 Requirements on MACsec Protocol

[FO_RS_MACsec_00010] Support of integrity and confidentiality

[FO_RS_MACsec_00011] MAC Security TAG

MACsec Entity (SW or HW) shall support MAC Security TAG (SecTAG) as defined in [3, IEEE-802.1AE-2018]. The SecTAG shall convey:

• TAG Control Information (TCI)
• Association Number (AN)
• Short Length (SL)
• Packet Number (PN)
• Secure Channel Identifier (SCI) - Optional

[FO_RS_MACsec_00012] MACsec EtherType

[FO_RS_MACsec_00017] Support of Extended Packet Number (XPN)

[FO_RS_MACsec_00018] Secure Channel Identifier (SCI)

[FO_RS_MACsec_00019] Secure Data

[FO_RS_MACsec_00020] Integrity Check Value (ICV)

[FO_RS_MACsec_00021] Protect function in software solution

[FO_RS_MACsec_00022] Validation function in software solution

# 4.2.4 Requirements on MKA Protocol

[FO_RS_MACsec_00023] Support of MKA Packets

[FO_RS_MACsec_00024] Pre-shared key support

[FO_RS_MACsec_00025] Key selection via CKN

# 4.2.5 Cryptography for MACsec and MKA

[FO_RS_MACsec_00026] GCM-based cipher support

[FO_RS_MACsec_00027] Support of AES ciphers with at least 128 bits of key length

[FO_RS_MACsec_00028] Support of AES ciphers with 256 bits of key length

[FO_RS_MACsec_00029] Support of Key Encryption Key (KEK)

[FO_RS_MACsec_00030] Support of Integrity Check Value Key (ICK)

[FO_RS_MACsec_00031] Support of Key Derivation Function (KDF)

[FO_RS_MACsec_00032] List of minimal supported cipher suites

[FO_RS_MACsec_00033] Validation function for ICVs

[FO_RS_MACsec_00034] Generation function for ICVs

[FO_RS_MACsec_00035]Key Handling with combined HSM and MACsec functionality

# 4.2.6 Requirements for MACsec capable hardware

[FO_RS_MACsec_00036] Interframe gap configuration of Ethernet controller

# 4.2.7 Additions to Standards

FO_RS_MACsec_00037 MACsec participants per link

[FO_RS_MACsec_00038] MKA SC establishment retry phase

[FO_RS_MACsec_00039] MKA rekey conditions

# 六、IEEE1722

# 4 Requirements Specification

This chapter describes all requirements driving the work to define the FO_RS_IEEE1722.

# 4.1 Functional Overview

IEEE specify a transport protocol for time-senstive applications in a bridged local area network (see [1, IEEE Std 1722-2016]). IEEE1722 streams transport data between stream data provider and 1 or multiple stream data consumers.

IEEE 为桥接局域网中的时间敏感应用程序指定了一种传输协议 (见 [1, IEEE Std 1722-2016])。IEEE1722 流在流数据提供者和 1 个或多个流数据消费者之间传输数据。

IEEE1722 streams carry among others a so-called "AVTP presentation time". The AVTP presentation time enables the possibilities to handle data synchronously across a local area network at several end nodes which receive the data via an IEEE1722 stream.

IEEE 1722 流包括所谓的 “AVTP 呈现时间”。AVTP 呈现时间使得在通过 IEEE 1722 流的几个端点接收数据的局域网中同步处理数据成为可能。

The IEEE1722 transport protocol support several AVTP subtypes to cover different use cases,e.g. :

• audio and video streaming
• distribution of a generated clock rate of a so-called media clock
• encapsulation of bus frames (e.g. CAN frames, LIN frames) and transport via a IEEE1722 stream across the network

IEEE1722 传输协议支持多个 AVTP 亚型以涵盖不同的用例，例如:

• 音频和视频流
• 分配所谓的媒体时钟生成的时钟速率
• 封装总线帧 (例如 CAN 帧、LIN 帧) 并通过 IEEE1722 流在网络上传输

This specification contains requirements to support handling of IEEE1722 streams in classic and adaptive platform.

此规范包含支持在经典平台和自适应平台中处理 IEEE1722 流的要求。

# 4.2 Functional Requirements

[FO_RS_IEEE1722_00001] IEEE1722Tp module APIs for IEEE1722 streams

[FO_RS_IEEE1722_00002] IEEE1722Tp module handling of IEEE1722 streams

[FO_RS_IEEE1722_00003] IEEE1722Tp module access to synchronized global time

[FO_RS_IEEE1722_00004] IEEE1722Tp module media clock handling

[FO_RS_IEEE1722_00005] IEEE1722Tp module stream activation and deactivation

[FO_RS_IEEE1722_00006] IEEE1722Tp module immediate and deferred transmission request

[FO_RS_IEEE1722_00007] IEEE1722Tp module immediate and deferred reception processing

[FO_RS_IEEE1722_00008] IEEE1722Tp module encaspulates bus frames

[FO_RS_IEEE1722_00009] IEEE1722Tp module collecting bus frames for transport

[FO_RS_IEEE1722_00011] IEEE1722Tp module bus frame forwarding

[FO_RS_IEEE1722_00012] IEEE1722Tp module bus frame filtering

# 4.3 Non-Functional Requirements

[FO_RS_IEEE1722_00013] IEEE1722Tp module definition of IEEE1722 streaming

[FO_RS_IEEE1722_00014] IEEE1722Tp module support of IEEE1722 stream properties

[FO_RS_IEEE1722_00015] IEEE1722Tp module support of IEEE1722 AVTP stream data subtypes

# 七、DebugTraceProfile

# 1 Scope of Document

Debugging and tracing enables efficient development, integration, optimization and verification of ECU software. For analyzing several aspects - especially timing aspects - it becomes essential to link the debugging and tracing data to the scheduling of an ECU.

调试和跟踪使 ECU 软件的开发、集成、优化和验证更加高效。为了分析几个方面 -- 特别是时间方面 -- 将调试和跟踪数据与 ECU 的调度联系起来变得至关重要。

Knowledge about tasks, interrupts and runnables, in other words: awareness of the operating system (“OS awareness”), is required.

对于任务、中断和可运行的知识，换言之：操作系统的意识 (“OS 意识”) 是必需的。

A good interaction of the tool chain provides complete round-trip engineering from model down to hardware and back - covering several software levels and several phases of the V-model.

工具链的良好交互性提供了从模型到硬件和返回的完整的往返工程 -- 涵盖 V 模型的多个软件级别和多个阶段。

The objective of ARTI (“AUTOSAR Run-Time Interface”) is an interface description, that allows debugging and tracing of AUTOSAR systems with a flexible awareness supporting different views, such as OS, BSW, RTE, model, user-data and user-defined.

ARTI (“AUTOSAR 运行时接口”) 的目标是接口描述，它允许对 AUTOSAR 系统进行调试和跟踪，具有灵活的意识支持不同的视图，例如 OS、BSW、RTE、模型、用户数据和用户定义。

In particular, the interface shall enable tools to perform:

• Debugging
• Tracing
• Timing Measurement
• Profiling

特别是，该接口应使工具能够执行:

• 调试
• 追踪
• 时间测量
• 概况介绍

The main focus of this requirements document is the format of the ARTI hooks and the exported ARTI description.

此需求文档的主要重点是 ARTI 钩子的格式和导出的 ARTI 描述。

# 4 Requirements Specification

This chapter describes all requirements driving the work to define ARTI.

本章描述了推动定义 ARTI 的工作的所有需求。

# 4.1 Functional Overview

The tools that generate AUTOSAR modules (e.g. OS, RTE, etc.) have to emit internal information about this module. The information shall allow to debug and trace the behavior of this module.

生成 AUTOSAR 模块的工具 (如 OS、RTE 等) 必须发出关于该模块的内部信息。该信息应允许调试和跟踪该模块的行为。

Additional tools will collect all ARTI information of an ECU and allow selecting specific items to trace and create tracing hook files for a specific trace channel (e.g. internal buffer, hardware trace buffers, etc.).

附加工具将收集 ECU 的所有 ARTI 信息，并允许选择特定项目进行跟踪，并为特定跟踪通道 (例如内部缓冲区、硬件跟踪缓冲区等) 创建跟踪挂钩文件。

The build environment creates the final application, which then can be used in the ECU. Debugging and tracing tools can read in the ARTI information and are “AUTOSAR” aware, giving additional debugging and tracing features to the developer.

构建环境创建最终应用程序，然后可以在 ECU 中使用。调试和跟踪工具可以读取 ARTI 信息，并且 “AUTOSAR” 意识，为开发人员提供额外的调试和跟踪功能。

ARTI is supposed to work with debug information created by the compilers. This means each module that supports ARTI needs to be compiled with debug information, and the ARTI information has to use the symbol names created by the compiler.

ARTI 应该与编译器生成的调试信息一起工作。这意味着每个支持 ARTI 的模块都需要使用调试信息编译，ARTI 信息必须使用编译器创建的符号名称。

ARTI introduces hooks. In order to use them, they shall be incorporated into the module’s code. Either they are put therein statically, or they have to be configured.

ARTI 引入了钩子。为了使用它们，它们应该被纳入到模块的代码中。它们可以静态地放在模块中，也可以被配置。

ARTI consists of these functional elements:

• ARTI module description
• The “ARTI Module Description” is emitted as an ARXML file, standardized by the ARTI Template.
• ARTI hook implementations
• The ARTI hooks are implemented within the AUTOSAR module’s source code.

ARTI 由以下功能要素组成:

• ARTI 模块描述
  “ARTI 模块描述” 作为一个 ARXML 文件发出，由 ARTI 模板标准化。
• ARTI 钩子实现
  ARTI 钩子是在 AUTOSAR 模块的源代码中实现的。

# 4.2 Functional Requirements on ARTI Template

The requirements in this section all concern how the ARTI template shall be defined.

本节中的要求都涉及如何定义 ARTI 模板。

[RS_ARTIFO_00001] The ARTI Description shall be the root for the whole ARTI information of an ECU

[RS_ARTIFO_00002] The ARTI Description shall support generic objects

[RS_ARTIFO_00003] The ARTI Description shall support a class definition of a generic object

[RS_ARTIFO_00004] The ARTI Description shall support an instance definition of a generic object

[RS_ARTIFO_00005] The ARTI Description shall support expressions to evaluate a parameter value

[RS_ARTIFO_00006] The ARTI Description shall support constants used by object parameters

[RS_ARTIFO_00007] The ARTI Description shall support parameter maps

# 4.3 Functional Requirements on ARTI Description

[RS_ARTIFO_00008] The ARTI description shall follow the ARTI Template.

[RS_ARTIFO_00009] The ARTI description shall include all class definitions of generic objects.

[RS_ARTIFO_00010] The ARTI description shall include all instance definitions of generic objects.

[RS_ARTIFO_00011] The ARTI description shall include all expression definitions to evaluate parameter values.

[RS_ARTIFO_00012] The ARTI description shall include all constant definitions used by parameters.

[RS_ARTIFO_00013] The ARTI description shall include all parameter maps used by parameters.

# 4.4 Functional Requirements on ARTI Hooks

[RS_ARTIFO_00014] ARTI Hooks shall be implemented with minimal intrusion

[RS_ARTIFO_00015] ARTI Hooks shall follow a fixed format

[RS_ARTIFO_00016] ARTI Hooks shall provide information about the calling context

[RS_ARTIFO_00017] ARTI Hooks shall provide the name of the class they belong to

[RS_ARTIFO_00018] ARTI Hooks shall provide the name of the event

[RS_ARTIFO_00019] ARTI Hooks shall provide parameters for the event

# 4.5 Non-Functional Requirements (Qualities)