Log and Trace
1. 文档范围¶
以下规范定义 AUTOSAR 日志与跟踪（Log and Trace，LT）的功能和非功能需求。
本文档的焦点是规定以下内容的需求：
- LT 到其他 CP:BSW 模块 / AP:功能集群的接口
- 到 CP:RTE/VFB / AP:ARA 跟踪的接口
- 到 CP:SWC / AP:应用的接口
- 日志和跟踪消息的传输与存储格式
- 到 LT 通信模块的内部接口
- LT 的通用配置
本文档不规定以下内容的需求：
- 通过 LT 通信模块进行通信的传输层
2. 所用约定¶
AUTOSAR 文档中需求的呈现遵循 TPS_STDT_00078 中规定的表格，参见 AUTOSAR 标准化模板 [1] 的「可追溯性支持（Support for Traceability）」章节。
应使用 TPS_STDT_00053 中规定的表达义务的言语形式来表示需求，参见 AUTOSAR 标准化模板 [1] 的「可追溯性支持」章节。
3. 缩略语和缩写¶
以下词汇表包含与诊断日志和跟踪（Diagnostic Log and Trace）模块相关、且未包含在 [2] 中的缩略语、缩写和定义。
Log and trace message
日志和跟踪消息包含在软件中指定一个日志和跟踪事件所需的全部数据和选项。
User
LT 的用户是使用 LT API 生成日志和跟踪消息的软件程序员。
Log
用户按需生成日志消息。每当用户想展示关于状态变化或值变化的某些信息时，他就向 LT 添加一个 API 调用。
Trace
跟踪消息可以通过对代码插桩生成（例如 VFB 跟踪）。被插桩的代码调用 LT 的 API。
ECU ID
ECU ID 是每个 ECU 的名称。
Session ID
会话 ID 是一个日志或跟踪会话的标识编号。如果一个应用被多次实例化，则日志会话会获得一个新的会话 ID。一个应用可以拥有多个日志或跟踪会话。一个 BSW 模块使用模块编号作为会话 ID。
Application ID
应用 ID 是应用/BSW 模块的短名称。它在日志和跟踪消息中标识该应用/BSW 模块。
Context ID
上下文 ID 是用户定义的 ID，用于将由一个应用/BSW 模块产生的日志和跟踪消息分组，以区分不同的功能。每个应用 ID 可以拥有多个上下文 ID。上下文 ID 按应用 ID 分组。上下文 ID 在一个应用 ID 内应当唯一。日志和跟踪消息来源的识别通过一对应用 ID 和上下文 ID 完成。
Message ID
消息 ID 是用于刻画消息自身所携带信息的 ID。一个消息 ID 唯一地标识一条日志或跟踪消息。它可用于识别消息的来源（在源代码中），也可用于刻画消息的载荷。
Log and trace level
日志级别为日志消息的严重程度定义了一个分类。跟踪状态提供是否应发送跟踪消息的信息。
Time
每条日志和跟踪消息都可以包含一个时间属性。该时间属性是一个自由定义的时间值。它是自 ECU 启动以来的时间。
External client
外部客户端是一种工具，它可以运行在 PC 或另一台 ECU 上，并通过 DCM 或 LT 通信模块连接到 LT。
4. 需求规范¶
本章描述驱动在 AUTOSAR 中定义日志与跟踪（Log and Trace）工作的所有需求。
4.1. 功能概述¶
LT 为应用和其他模块提供通用的日志与跟踪功能。
总体上，LT 提供以下功能：
- 日志
- 对来自 AUTOSAR 应用的错误、警告和信息消息进行日志记录，提供一个标准化的 AUTOSAR 接口
- 将来自所有 AUTOSAR 应用层级和中间件层级的全部 LT 消息汇集到一个集中式的 AUTOSAR 模块（DLT）中。
- 来自 DET [3]、DEM [4] 的日志消息（经典平台）
- 跟踪
- 跟踪 RTE/VFB（[5]）（经典平台）
- 控制
- 启用/禁用单条 LT 消息
- 通过反向通道逐个控制跟踪级别
- 通用性
- LT 在调试阶段和生产阶段均可用
- 通过标准诊断或平台特定的测试接口访问
- 防止在生产阶段被滥用的信息安全机制
此外，为自适应平台提供以下功能：
- 时间戳
- 如果需要时间戳，LT 模块提供对日志消息和跟踪消息都加时间戳的可能性。
- 这种加时间戳由 LT 模块直接处理，无需应用的任何干预。
- 应用通信跟踪
- LT 模块能够处理多个自适应应用之间通信流的跟踪，而无需被跟踪应用做进一步的交互。
4.2. 功能需求¶
4.2.1. 日志和跟踪接口¶
4.2.1.1. 通用¶
日志应支持初始化和注册
| 描述 | 日志应支持初始化日志框架并注册日志信息的来源。 |
|---|---|
| 理由 | 为了能够过滤日志信息并将其与来源关联，应用必须在日志框架处注册自身。 |
| 适用平台 | CP、AP |
| 用例 | 将日志信息与来源关联、应用过滤设置并提供附加信息。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应使应用能够提供元信息
| 描述 | 日志应使应用能够提供关于其自身的附加信息。 |
|---|---|
| 理由 | 能够识别所生成日志信息的来源。 |
| 适用平台 | CP、AP |
| 用例 | 对接收到的日志信息进行排序、过滤和关联。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应使应用能够提供日志信息
| 描述 | 日志应使应用能够提供日志信息。日志信息应包含关于其严重程度的信息。 |
|---|---|
| 理由 | 在开发应用时，获得应用内部正在发生什么的附加信息非常重要。 |
| 适用平台 | CP、AP |
| 用例 | 获取应用的内部信息，例如：变量值、状态机的当前内部状态以及其他信息。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应支持应用之间通信的跟踪
| 描述 | 应可以跟踪应用之间的通信。 |
|---|---|
| 理由 | 越来越多的应用被集成到一台 ECU 上。因此，应用之间的通信在本地完成，而不经过 CAN 之类可被外部跟踪的总线。 |
| 适用平台 | CP、AP |
| 用例 | 跟踪应用之间的通信。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应支持日志信息的分组
| 描述 | 日志应支持对日志信息进行逻辑分组。 |
|---|---|
| 理由 | 将逻辑上属于一起的日志信息聚成簇。 |
| 适用平台 | CP、AP |
| 用例 | 关联或过滤所有属于一起的日志信息。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应允许选择日志信息的目的地
| 描述 | 日志应允许选择所提供日志信息的目的地。 |
|---|---|
| 理由 | 日志信息可以被存储到不同的位置。 |
| 适用平台 | CP、AP |
| 用例 | 将日志信息转发到控制台、文件系统，或通过通信总线发送。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应提供早期日志能力
| 描述 | 日志框架应提供早期日志的可能性。API 应能够在日志后端的主要初始化阶段完成之前，处理日志消息请求以及创建新的日志上下文实例。 |
|---|---|
| 理由 | 最早调用初始化过程是在程序代码于主事件循环中执行时才可能的。在此之前，应用可能创建全局/静态对象，其构造函数可能已经在记录有用的信息。由于全局/静态对象在主事件循环进入之前被实例化，日志框架必须支持对其所有接口的调用而不崩溃。理想情况下，它应缓冲日志请求（数量不限）和静态创建的日志上下文实例，并在初始化阶段之后尽快处理它们。 |
| 适用平台 | CP、AP |
| 用例 | 在日志后端的初始化阶段完成之前创建日志上下文和/或发起日志消息。 |
| 依赖项 | - |
| 支撑材料 | - |
LT 应通过通信接口将来自多个来源的日志和跟踪消息传输给接收方外部客户端
| 描述 | LT 模块应是一个 BSW 模块。它应从多个来源（如应用、某些 BSW 模块和 RTE）接收日志和跟踪消息。这些消息可以通过通信接口传输给外部客户端。日志和跟踪是很多 ECU 需要的调试机制。日志和跟踪模块应提供一种从多个来源汇集日志和跟踪消息的机制。日志和跟踪模块在必要时缓冲日志和跟踪条目，并且应具有到外部客户端的连接。 |
|---|---|
| 理由 | 每个一级供应商都使用自己的机制来提供这样的日志接口，使用某些内部或外部调试接口。日志内容的格式也因 ECU 而异。在测试多台 ECU 时，需要许多不同的工具和解析器才能从日志中提取正确的信息。一个带有标准化日志内容的标准诊断日志组件可能有助于减少测试工作量并启用新的自动化测试机制。此外，标准的日志内容和协议也可以减少工具的数量。 |
| 适用平台 | CP、AP |
| 用例 | * 开发支持 * 功能测试 * 测试自动化 * 针对模型的测试 * 驾驶员密集型测试 * 高级诊断跟踪，可选地通过远程信息处理服务 |
| 依赖项 | - |
| 支撑材料 | - |
ECU 发送的所有日志和跟踪消息应具有标准化的传输格式和标准化的存储格式
| 描述 | 应定义一种规定的格式，覆盖日志和跟踪的所有需求。日志或跟踪消息中存储的信息的一些示例是消息的来源、上下文和时间戳，以便能够过滤日志和跟踪消息。 |
|---|---|
| 理由 | 由于日志和跟踪是可测试性和产品质量证明的重要机制，有必要对传输和存储的数据格式进行标准化。这对日志或跟踪消息的存档、比较和分析非常重要。此外，还可以构建通用的工具来解释传入的数据。 |
| 适用平台 | CP、AP |
| 用例 | * LT 通过接口将消息发送给一个存储数据的外部客户端 * 不同 ECU 的存储数据由外部客户端解释 * 可以合并来自不同 ECU 的日志和跟踪消息，以理解分布式功能行为之间的关系 |
| 依赖项 | - |
| 支撑材料 | - |
4.2.1.2. 应用接口¶
应用应能够向 LT 模块发送日志或跟踪消息
| 描述 | LT 应提供一个独立于日志和跟踪消息类型的通用应用接口。 |
|---|---|
| 理由 | 为了减少接口的数量，可以实现一个通用且与消息无关的接口。 |
| 适用平台 | AP、CP |
| 用例 | * 跟踪或记录来自应用的日志或跟踪消息 |
| 依赖项 | - |
| 支撑材料 | - |
日志应提供一个用于记录信息的接口
| 描述 | 日志应为应用提供转发其日志信息（包括关联的严重级别）的接口。 |
|---|---|
| 理由 | 将日志信息转发给日志框架。 |
| 适用平台 | CP、AP |
| 用例 | 将日志信息转发给日志框架做进一步处理（在本地存储或转发到通信总线）。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应能够处理原始缓冲区内容作为日志信息
| 描述 | 日志应支持提供原始缓冲区的内容作为日志信息。 |
|---|---|
| 理由 | 缓冲区的原始内容可能对开发目的有价值。 |
| 适用平台 | CP、AP |
| 用例 | 获取位于内存中的确切原始数据。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应使应用能够检查当前的严重级别
| 描述 | 日志应为应用提供检查当前活动严重级别的可能性。 |
|---|---|
| 理由 | 为了避免生成日志信息所需的不必要的 CPU 和/或内存消耗，应用应能够首先检查其创建的日志信息是否反正会被底层日志框架过滤掉。 |
| 适用平台 | CP、AP |
| 用例 | 避免不必要的 CPU 和/或内存消耗。 |
| 依赖项 | - |
| 支撑材料 | - |
日志应提供十六进制和二进制值的转换函数
| 描述 | 日志应为应用提供将十进制值转换为十六进制或二进制系统的可能性。 |
|---|---|
| 理由 | 以十六进制或二进制值而不是十进制值的形式提供某些调试信息。 |
| 适用平台 | CP、AP |
| 用例 | 以十六进制值或二进制值的形式提供日志信息。 |
| 依赖项 | - |
| 支撑材料 | - |
LT 应向应用提供实际的日志级别集合和跟踪状态
| 描述 | 应用应了解其日志级别和跟踪状态，以便不生成不必要的日志和跟踪消息。应用应在发送消息之前检查日志级别和跟踪状态。 |
|---|---|
| 理由 | 必须避免对通信接口和系统产生不必要的负载。LT 应提供关于实际配置的信息。 |
| 适用平台 | CP、AP |
| 用例 | * 日志级别和跟踪状态的控制 |
| 依赖项 | - |
| 支撑材料 | - |
对于每个应用，都应配置到 LT 的接口
| 描述 | 每个应用的 LT 接口的生成应通过配置来启用。 |
|---|---|
| 理由 | 只应生成到使用日志和跟踪的应用的、已配置的接口。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
4.2.1.3. DET 跟踪接口¶
BSW 和应用产生的错误的跟踪事件应转发给 LT 模块
| 描述 | DET 在调试期间接收来自 BSW 和应用产生的错误的跟踪事件。这些事件可以转发给 LT 模块。 |
|---|---|
| 理由 | 为了总览所有日志、跟踪和错误消息并将它们置于正确的上下文中，将所有这些消息和事件放入一个列表非常重要。此外，使用多于一种机制向外部客户端报告错误、日志和跟踪并不可行。因此，所有这些来源都可以转发给 LT 模块。 |
| 适用平台 | CP |
| 用例 | 在调试场景中，一个应用或 BSW 模块使用 DET 接口跟踪一个错误。该错误由 DET 模块转发给 LT 模块。LT 将这些事件转换为一条日志消息并发送给外部客户端。 |
| 依赖项 | - |
| 支撑材料 | - |
4.2.1.4. DEM 跟踪接口¶
DEM 应将错误事件转发给 LT 模块
| 描述 | DEM 可以将错误事件转发给 LT 模块。 |
|---|---|
| 理由 | 可以总览一台 ECU 中的所有错误消息。可以结合 DEM 报告的错误事件将它们置于正确的上下文中。这使得对报告错误的分析更高效，并给出失效情形的正确图景。 |
| 适用平台 | CP |
| 用例 | 一个应用或 BSW 模块在 DEM 中设置一个 DTC。DEM 将该事件转发给 LT。LT 将这些事件转换为 LT 格式，并通过通信接口发送给 LT 外部客户端。 |
| 依赖项 | - |
| 支撑材料 | - |
4.2.1.5. RTE/VFB 跟踪接口¶
RTE 应为 LT 提供跟踪 RTE/VFB 调用的接口
| 描述 | RTE 应提供跟踪 VFB 的可能性。 |
|---|---|
| 理由 | 未来越来越多的应用将被集成到一台 ECU 中。因此，应用之间的通信在本地完成，而不经过 CAN 或 FlexRay 之类可被外部跟踪的总线。跟踪 RTE/VFB 上的内部通信非常重要。 |
| 适用平台 | CP |
| 用例 | * VFB 接口的跟踪 * 为高级诊断服务访问 VFB |
| 依赖项 | - |
| 支撑材料 | - |
LT 应实现跟踪 RTE/VFB 的接口
| 描述 | VFB 跟踪应提供给 RTE 生成系统。LT 模块应实现 RTE/VFB 跟踪事件的处理。 |
|---|---|
| 理由 | 为了理解应用之间的通信，跟踪所有到应用的函数调用（RTE 系统函数调用除外）非常重要。 |
| 适用平台 | CP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
应定义一个全局开关来打开和关闭 RTE 跟踪
| 描述 | 应有一个全局开关，在配置时和运行时打开和关闭 LT 的 RTE 跟踪。 |
|---|---|
| 理由 | 为了对所有 RTE 跟踪消息有一个高级别的激活手段，需要一个全局开关。 |
| 适用平台 | CP |
| 用例 | 打开/关闭 LT 的所有跟踪事件 |
| 依赖项 | - |
| 支撑材料 | - |
LT 应实现 RTE/VFB 跟踪事件的处理
| 描述 | LT 可以实现 RTE/VFB 跟踪事件的处理。可以在配置时配置这些组，并且事件可以被分配到某一个组。在运行时，每个组的日志级别可以被单独设置。 |
|---|---|
| 理由 | 为了理解应用之间的通信，跟踪一个应用的函数调用非常重要。 |
| 适用平台 | CP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
LT 应提供跟踪与隐式通信机制关联的事件的解决方案
| 描述 | LT 可以提供一种跟踪与隐式通信机制关联的事件的解决方案。隐式通信可以在可运行体（runnable）调用和终止时被跟踪。 |
|---|---|
| 理由 | 从应用的角度看，使用隐式发送/接收时，没有用于接收或发送信号（发送方-接收方通信）的额外例程被调用。 RTE 管理调用之前和退出之后的数据复制。 |
| 适用平台 | CP |
| 用例 | 跟踪应用的隐式通信 |
| 依赖项 | - |
| 支撑材料 | - |
4.2.2. 日志和跟踪消息的格式¶
传输的数据应被打包
| 描述 | 日志和跟踪消息应是面向数据包的。每个数据包应具有一个或多个报头和一个载荷。报头可用于识别、过滤和分类日志和跟踪消息。载荷应包含来自应用或 BSW 的参数。 |
|---|---|
| 理由 | LT 不应关心底层的传输协议。LT 应定义日志或跟踪消息格式。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
传输格式应为二进制
| 描述 | 日志和跟踪消息应为二进制格式。这对于减少带宽和 CPU 消耗是必要的。 |
|---|---|
| 理由 | LT 组件的目标是在不扰动 ECU 行为的情况下记录和跟踪事件。通过对协议使用二进制格式，可以减少 CPU 消耗和带宽占用。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
格式应处理大端和小端
| 描述 | 消息规范中应考虑字节序（Endian）格式。消息应指示实际使用的字节序模式。 |
|---|---|
| 理由 | 数据表示的大端和小端字节序在汽车 ECU 中混合存在。消息格式应能够处理两者。为了降低 CPU 负载，应能够以对应 ECU 的格式传输数据。 |
| 适用平台 | CP、AP |
| 用例 | 格式标记 |
| 依赖项 | - |
| 支撑材料 | - |
每条日志和跟踪消息应包含一个时间戳，该时间戳在 LT 模块接收消息时被添加到消息中
| 描述 | 每条日志和跟踪消息可以包含一个时间戳，该时间戳应在 LT 模块接收消息时被添加到消息中。 |
|---|---|
| 理由 | 对于复杂系统的比较和分析，时间戳非常重要。时间应具有规定的粒度。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
应实现一个全局消息计数器，以检测消息丢失
| 描述 | 每当 LT 模块或其他软件模块收到来自应用的消息时，它应递增其全局消息计数器并将该计数器设置到消息中。 |
|---|---|
| 理由 | 了解消息是否丢失非常重要。接收方外部客户端随后可以检测消息是否丢失（例如由于 LT 中的缓冲区溢出或网络丢失）。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
对于每条日志消息，应提供一个日志级别
| 描述 | 日志级别例如为错误（error）、致命（fatal）、调试（debug）、信息（information）或详细（verbose）。 |
|---|---|
| 理由 | 日志工具的标准 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
日志和跟踪消息应包含一个参数，该参数表示日志和跟踪消息的来源
| 描述 | 日志和跟踪消息可以包含一个参数，该参数表示日志和跟踪消息的来源。 |
|---|---|
| 理由 | 来源可以通过用于将消息从应用发送到 LT 的端口接口的会话 ID（端口定义的参数值）来识别。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
应通过使用不同的标识符为日志消息提供逻辑分组
| 描述 | 应有描述日志和跟踪消息所属组的附加参数。 |
|---|---|
| 理由 | 识别日志和跟踪的某些逻辑组，以便在外部客户端上定义某些过滤动作。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
每个 ECU 应有其唯一的 ECU ID
| 描述 | 每个 ECU 可以有其唯一的 ECU ID，该 ID 可以是每条日志和跟踪消息的一个参数。 |
|---|---|
| 理由 | 外部客户端接收来自不同 ECU 的跟踪，因此了解来源非常重要。 |
| 适用平台 | CP、AP |
| 用例 | 区分来自不同 ECU 的跟踪 |
| 依赖项 | - |
| 支撑材料 | - |
载荷应传输日志和跟踪消息的参数
| 描述 | 载荷中应传输来自应用的每条日志和跟踪消息的参数。可以传输多于一个参数。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
应能够以原始格式传输参数
| 描述 | 在大多数情况下，参数应以原始格式传输。这意味着应提供一个单独的文件，包含关于所传输参数的信息。 |
|---|---|
| 理由 | 非详细模式（non-verbose mode）用于节省内存和带宽，因为在 ECU 上只应存储日志和跟踪消息的 ID。 |
| 适用平台 | CP、AP |
| 用例 | 解释二进制数据 |
| 依赖项 | - |
| 支撑材料 | - |
应能够传输带有参数自身附加信息（自描述）的参数
| 描述 | 在详细模式（verbose mode）下，日志和跟踪消息应包含参数的描述。在这种情形下不需要提供附加的描述文件。 |
|---|---|
| 理由 | 在详细模式下，载荷中的所有参数都包含其自身类型（例如整数/浮点、位长）的自描述以及一些附加信息（例如变量名、单位等）。 |
| 适用平台 | CP、AP |
| 用例 | 解释二进制数据 |
| 依赖项 | - |
| 支撑材料 | - |
应能够在日志或跟踪消息中传输 ASCII 文本
| 描述 | 由于日志和跟踪消息通常由文本组成，应有可能传输文本字符串。可以将给定的文本替换为一个 ID，该 ID 可以在外部客户端中被替换回文本（比较详细模式与非详细模式）。 |
|---|---|
| 理由 | 在小型 ECU 中，由于内存占用，字符串无法被存储。出于这些原因，这些字符串可以被替换为一个消息 ID。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
非详细模式下的数据应由一个额外的文件描述
| 描述 | 非详细模式下的数据需要由一个额外的文件描述。该文件可以是 ARXML 格式。 |
|---|---|
| 理由 | 在小型 ECU 中内存非常有限，因此临时缓冲的数据应非常小。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
非详细模式下的每条消息应有一个唯一的消息 ID，该 ID 对识别跟踪的来源有意义
| 描述 | 每条消息可以有一个唯一的标识符，该标识符对识别跟踪的来源有意义。特定消息的 ID 在整个开发阶段应保持不变，并且对于给定的 ECU 应是唯一的。 |
|---|---|
| 理由 | 在日志和跟踪消息中轻松识别正确的信息非常重要。唯一的消息 ID 有助于做到这一点。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
4.2.3. 传输接口¶
4.2.3.1. 通用¶
应实现一种控制消息，使外部客户端能够评估往返时间
| 描述 | 应实现一种控制消息，使外部客户端能够评估往返时间（round trip time）。外部客户端应使用该消息来同步来自不同 ECU 的各条日志和跟踪消息。 |
|---|---|
| 理由 | 日志和跟踪的时间信息可以使用户理解：如果所记录的事件之间存在关联，究竟发生了什么。能够将所有被记录的事件参照到一个绝对时间尺度上非常重要。 |
| 适用平台 | CP、AP |
| 用例 | * 为每台 ECU 进行一次往返时间计算 |
| 依赖项 | - |
| 支撑材料 | - |
应提供生产阶段防未授权访问的保护
| 描述 | 在生产阶段，通信模块（参见 RS_LT_00034）应默认被禁用。在生产阶段，LT 应使用 DCM 提供的信息安全机制来处理对日志和跟踪消息的访问。应实现一种机制，在测试阶段永久地启用该通信模块。 |
|---|---|
| 理由 | 在生产阶段只允许对 LT 的授权访问，以避免滥用。 |
| 适用平台 | CP、AP |
| 用例 | 避免 LT 被滥用 |
| 依赖项 | - |
| 支撑材料 | - |
日志应能够监控并塑造 LT 日志和跟踪事件的数量
| 描述 | LT 可以根据使用哪个传输接口进行通信来塑造流量带宽。流量塑造应在运行时完成。 |
|---|---|
| 理由 | 由于 LT 也应在生产阶段使用，LT 组件产生的流量不应对网络造成过载并占用 ECU 资源，这一点非常重要。 |
| 适用平台 | CP、AP |
| 用例 | * 带宽占用必须被控制 * 必须允许带宽配置 |
| 依赖项 | - |
| 支撑材料 | - |
LT 应可在运行时配置
| 描述 | LT 应可在运行时配置。为此，LT 应具有运行时可配置的变量，这些变量以相应的配置参数初始化。应可以查询 LT 的运行时配置。配置变量应可通过某种远程触发的控制机制进行写入和读取。 |
|---|---|
| 理由 | 为了将 LT 的行为适配到 ECU 和网络资源，具备配置它的能力非常重要。 |
| 适用平台 | CP、AP |
| 用例 | * 变更默认级别并存储到 NVRAM * 查询 LT 状态 |
| 依赖项 | - |
| 支撑材料 | - |
应实现一种协议，能够设置和查询每台 ECU 的日志和跟踪来源的跟踪状态和日志级别
| 描述 | LT 应支持控制消息，用于设置每台 ECU 的每个来源的跟踪状态和日志级别。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | * 在不同级别上启用/禁用跟踪和日志消息。 * 设置每台 ECU 的不同来源所生成的日志消息的级别。 |
| 依赖项 | - |
| 支撑材料 | - |
ECU 的所有日志和跟踪来源的列表应可从外部客户端访问
| 描述 | 应可以获得注册到 LT 模块的所有应用 ID 和上下文 ID 及其对应的跟踪状态和日志级别的列表。每个想要产生跟踪或日志消息的应用或 BSW 模块都应注册到 LT 模块。 |
|---|---|
| 理由 | 用户需要了解哪些信息可以被跟踪或记录，以便监控 ECU 的活动。 |
| 适用平台 | CP、AP |
| 用例 | * 可以合并来自不同 ECU 的日志消息，以理解分布式应用行为之间的关系。 * 设置每台 ECU 不同来源所生成的跟踪的级别。 |
| 依赖项 | - |
| 支撑材料 | - |
4.2.3.2. 通信接口¶
LT 应支持通过 LT 通信模块进行通信的通用 API
| 描述 | 在调试阶段，需要一个高带宽的通信接口。该通信接口不在 AUTOSAR 规范的范围之内。为了将 LT 与该通信接口一起使用，应定义一个通用 API。用户应能够实现一个板级特定的通信模块，通过板级特定的通信接口进行通信。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
4.2.3.3. DCM 传输接口¶
DCM 应为 LT 提供通过诊断会话传输日志和跟踪消息的接口
| 描述 | DCM 应为 LT 提供一个通过诊断服务发送和接收数据的接口。日志和跟踪消息通过该服务发送，并且接收 LT 的控制消息。由于日志和跟踪消息是事件触发的且 ECU 上的存储有限，这些消息应在发生时被发送。由于诊断服务只能发送少量数据，数据量应受到限制，参见 RS_LT_00030。 |
|---|---|
| 理由 | LT 需要一个接口将日志和跟踪消息发送出 ECU。DCM 通过标准化的诊断提供对 ECU 的总线无关访问。它在生产阶段可用，并提供受保护的会话控制。 由于诊断服务只能发送少量数据，数据量应受到限制，参见 RS_LT_00030。对于更高的带宽，应使用通信模块，参见 RS_LT_00034。 |
| 适用平台 | CP |
| 用例 | * 在诊断会话期间传输日志和跟踪消息 * 高级诊断跟踪，可选地通过远程信息处理服务 |
| 依赖项 | RS_LT_00030, RS_LT_00034 |
| 支撑材料 | - |
4.2.4. 运行功能¶
4.2.4.1. 初始化和关闭¶
LT 应提供一个用于在初始化之前存储日志和跟踪消息的缓冲区
| 描述 | LT 可以提供一个用于存储日志和跟踪消息的缓冲区。它可以是一个标准的 C 语言初始化的缓冲区，应在 LT 初始化之后被读出。 |
|---|---|
| 理由 | 该需求应保证 LT 模块在所有 BSW 模块完全初始化之前也能向其他 BSW 模块提供服务。 |
| 适用平台 | CP、AP |
| 用例 | 启动阶段即可用日志记录 |
| 依赖项 | RS_LT_00052 |
| 支撑材料 | - |
4.2.4.2. 正常运行¶
应有一个缓冲区在本地存储日志和跟踪消息
| 描述 | 如果通信模块未被启用，或者没有外部客户端连接用于转储日志和跟踪消息，日志和跟踪消息应在本地存储到一个内存缓冲区中。缓冲区的大小应在配置时设置。 |
|---|---|
| 理由 | 为了防止通信缺失（例如在启动时或没有外部客户端连接时），LT 应存储一些消息，以便在通信通道可用时尽快转储。 |
| 适用平台 | CP、AP |
| 用例 | * ECU 启动 * 没有可用的通信 |
| 依赖项 | - |
| 支撑材料 | - |
应实现一种机制，能够设置每个应用已注册的应用 ID 和上下文 ID 的跟踪状态和日志级别
| 描述 | LT 应允许在运行时关闭或打开已注册应用 ID 和上下文 ID 的跟踪，或设置它们的日志级别。 |
|---|---|
| 理由 | 为了提高带宽和 ECU 资源使用的效率，应提供一种机制来调整从应用到 LT 的传输。 LT 模块应提供一些控制变量，它们表示应用和上下文的实际日志级别和跟踪状态。 |
| 适用平台 | CP、AP |
| 用例 | 启用/禁用跟踪状态和日志级别。 |
| 依赖项 | - |
| 支撑材料 | - |
LT 应提供以持久化方式存储配置数据的可能性
| 描述 | 日志和跟踪配置应被持久化存储。 |
|---|---|
| 理由 | LT 可以在运行时被配置。日志与跟踪配置数据必须被存储，以保证每次启动时的配置都相同。 |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
LT 组件应能够过滤日志和跟踪消息
| 描述 | 为了将网络流量适配到可用的带宽，LT 组件可以过滤日志和跟踪消息。应定义一种策略，按不同的日志和跟踪级别区分消息。过滤级别的配置对于临时存储日志和跟踪消息、以及通过 DCM 或 LT 通信模块的通信可以是不同的。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
AUTOSAR 日志和跟踪应支持统一化的日志记录
| 描述 | AUTOSAR 应定义可全局使用、带有唯一 ID 的日志消息，供所有软件部分（系统软件、AUTOSAR 功能集群和其他基础软件、应用）使用。这应通过使用一个强制的扩展报头（Extension Header）来启用，该报头带有为每个 AUTOSAR 功能集群预留的预定义消息 ID 和上下文 ID。 |
|---|---|
| 理由 | 确保相似的事物以相似的方式被记录。 |
| 适用平台 | CP、AP |
| 用例 | 应用和例如 UCM 可能都在使用 ara::com 报告某个通信问题。 |
| 依赖项 | - |
| 支撑材料 | - |
4.3. 非功能需求¶
4.3.1. LT 应成为日志和跟踪功能的中央软件组件¶
| 描述 | 每台 ECU 只应有一个软件模块集中汇集日志和跟踪消息。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 依赖项 | - |
| 支撑材料 | - |
4.3.2. 日志和跟踪软件组件在生产阶段应成为系统的一部分¶
| 描述 | 日志和跟踪软件组件在生产阶段应成为系统的一部分。试驾和远程诊断之类的用例需要它。 |
|---|---|
| 理由 | - |
| 适用平台 | CP、AP |
| 用例 | * 高级远程诊断 |
| 依赖项 | - |
| 支撑材料 | - |
4.3.3. LT 应提供跟踪点的接口¶
| 描述 | 日志应为应用软件和系统软件层面源代码中的跟踪点（trace point）提供一个接口。 |
|---|---|
| 理由 | 在软件开发和集成中，了解时序行为是必要且重要的。定义和收集由跟踪点发出的事件的可能性，是确定这种时序行为的基本特性。 |
| 适用平台 | AP |
| 用例 | * 跟踪系统级软件和应用级软件的动态状态 * 在源代码中提供跟踪点的 API 调用 |
| 依赖项 | - |
| 支撑材料 | - |
4.3.4. LT 应发送建模的跟踪消息¶
| 描述 | 跟踪消息应通过建模的消息发送。 |
|---|---|
| 理由 | 在分布式系统中，经常需要确定跨多台 ECU 的分布式功能的时序行为。此外，能够比较不同的实现也很重要。使用建模的消息，可以使用可比较的格式，并以更少的开销（没有静态的、描述性的信息）发送跟踪信息。 |
| 适用平台 | AP |
| 用例 | 高效且标准化的跟踪格式 |
| 依赖项 | RS_LT_00002 |
| 支撑材料 | - |
4.3.5. 跟踪应在编译时可配置¶
| 描述 | 应可以通过配置为整个系统以及选定的应用启用和禁用跟踪。 |
|---|---|
| 理由 | 跟踪通常只在开发和集成期间需要。因此必须能够禁用它。在开发期间，可能只有若干应用值得关注。 |
| 适用平台 | AP |
| 用例 | 选择要跟踪的系统级和应用 |
| 依赖项 | RS_LT_00010, RS_LT_00005 |
| 支撑材料 | - |
4.3.6. LT 应可配置为使用 ARTI 处理跟踪信息¶
| 描述 | 对于建模的跟踪消息，应可以配置定义 ARTI 来处理跟踪信息。 |
|---|---|
| 理由 | 通过使用 ARTI Trace API，可以将跟踪的开销降到最低。由于 OS 也使用 ARTI 进行跟踪，因此可以同时跟踪 OS、系统和应用层级。 |
| 适用平台 | AP |
| 用例 | 依赖整个平台的时序 |
| 依赖项 | RS_LT_00051 |
| 支撑材料 | - |
5. 参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
[3] Specification of Default Error Tracer
AUTOSAR_CP_SWS_DefaultErrorTracer
[4] Specification of Diagnostic Event Manager
AUTOSAR_CP_SWS_DiagnosticEventManager
[5] Specification of RTE Software
AUTOSAR_CP_SWS_RTE
AUTOSAR_FO_RS_Main
A. 变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的约束和规范项。这些约束和规范项在文档中不作为超链接出现。
由于本批次决议整体省略需求项 ID，本附录变更表的 Number 列省略。
A.1. 本文档依据 AUTOSAR 版本 R23-11 的变更历史¶
A.1.1. R23-11 中新增的需求¶
新增 58 项。源文档转换中该表有 54 行的标题列为空，按批次决议以数量呈现；带标题的 4 项如下：
| 标题 |
|---|
| LT 应成为日志和跟踪功能的中央软件组件 |
| 日志和跟踪软件组件在生产阶段应成为系统的一部分 |
| LT 应提供跟踪点的接口 |
| LT 应发送建模的跟踪消息 |
A.1.2. R23-11 中变更的需求¶
无。
A.1.3. R23-11 中删除的需求¶
无。