Debug Trace Profile
1. 文档范围¶
调试与跟踪能够实现 ECU 软件的高效开发、集成、优化和验证。为了分析多个方面——尤其是时序方面——将调试和跟踪数据与 ECU 的调度关联起来变得至关重要。这需要关于任务、中断和可运行实体（Runnable）的知识，换句话说，需要对操作系统的感知（「OS 感知」（OS awareness））。
工具链的良好交互提供了从模型到硬件再返回的完整双向工程——覆盖多个软件层级和 V 模型的多个阶段。
ARTI（「AUTOSAR Run-Time Interface」，AUTOSAR 运行时接口）的目标是一种接口描述，它允许以支持不同视图（例如 OS、BSW、RTE、模型、用户数据和用户自定义视图）的灵活感知方式调试和跟踪 AUTOSAR 系统。
具体而言，该接口应使工具能够执行：
- 调试
- 跟踪
- 时序测量
- 剖析
本需求文档的主要关注点是 ARTI 钩子（ARTI hooks）的格式以及导出的 ARTI 描述。
2. 所用约定¶
2.1. 文档约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章（[1]）。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章（[1]）。
2.2. 需求指南¶
暂不适用，包括其子章节：
- 2.2.1 需求质量
- 2.2.2 需求标识
- 2.2.3 需求状态
3. 缩略语和缩写¶
以下收录与 RS_ARTI 相关、且未被 AUTOSAR 术语表 [2] 收录的缩略语和缩写。
ARTI
AUTOSAR 运行时接口（AUTOSAR Run Time Interface）
OS
操作系统（Operating System）
4. 需求规格¶
本章描述驱动 ARTI 定义工作的全部需求。
4.1. 功能概述¶
生成 AUTOSAR 模块的工具（例如 OS、RTE 等）必须输出关于该模块的内部信息。该信息应允许调试和跟踪该模块的行为。其他工具将收集一个 ECU 的全部 ARTI 信息，并允许选择要跟踪的特定条目，以及为特定跟踪通道（例如内部缓冲区、硬件跟踪缓冲区等）创建跟踪钩子文件。构建环境创建最终的应用程序，然后可在 ECU 中使用。调试和跟踪工具可以读入 ARTI 信息并具备「AUTOSAR 感知」，为开发者提供额外的调试和跟踪特性。
ARTI 应能与编译器创建的调试信息协同工作。这意味着每个支持 ARTI 的模块都需要在编译时带有调试信息，并且 ARTI 信息必须使用编译器创建的符号名称。
ARTI 引入钩子。为了使用它们，必须将其并入模块代码中——或者静态地放入其中，或者必须对它们进行配置。
ARTI 由以下功能元素组成：
- ARTI 模块描述——「ARTI 模块描述」（ARTI Module Description）以 ARXML 文件的形式输出，由 ARTI 模板标准化。
- ARTI 钩子实现——ARTI 钩子在 AUTOSAR 模块的源代码中实现。
4.2. 面向 ARTI 模板的功能需求¶
本节中的需求均涉及 ARTI 模板应如何定义。
4.2.1. ARTI 描述应为 ECU 全部 ARTI 信息的根¶
| 描述 | ARTI 模板应是特定 ECU 全部 ARTI 相关信息的骨干。 |
|---|---|
| 理由 | 为访问 ECU 的运行时信息，工具需要有一个可供查找信息的引用。所有进一步的详细信息可通过跟随该引用的内容找到。注意，本需求并不意味着将所有相关信息复制到模板中。可以包含对其他模板中元素的引用，以避免模型中出现冗余元素。 |
| 依赖项 | ARTI 工具还需要能够读取其他模板（特别是 ECU 模板），如果 ARTI 描述引用了它们。 |
| 用例 | ARTI 模板包含关于如何对通用类和实例建模的规范，无需修改模板即可指定对 ECU 任意对象的访问。模板包含对其他模板和组件的引用，以便也能使用这些信息。 |
| 支撑材料 | - |
4.2.2. ARTI 描述应支持通用对象¶
| 描述 | 通用对象定义任意对象。 |
|---|---|
| 理由 | 通用对象是不属于另一个模块的任意对象。该定义应能够定义对象（「类」）的布局以及特定实例的值。 |
| 依赖项 | - |
| 用例 | 通用对象定义定义了任意对象在调试器中或跟踪时的呈现方式。 |
| 支撑材料 | - |
4.2.3. ARTI 描述应支持通用对象的类定义¶
| 描述 | 通用对象的类定义定义任意对象的布局。 |
|---|---|
| 理由 | 不属于另一个 AUTOSAR 模块的对象必须向 ARTI 消费工具定义。ARTI 模板应提供一种机制，用其名称、描述和参数定义对象布局（「类」）。 |
| 依赖项 | - |
| 用例 | 通用对象定义定义了任意对象在调试器中或跟踪时的呈现方式。 |
| 支撑材料 | - |
4.2.4. ARTI 描述应支持通用对象的实例定义¶
| 描述 | 通用对象的实例定义定义任意对象实例的值。 |
|---|---|
| 理由 | ARTI 模板应定义 ARTI 消费工具如何评估对象实例的参数。 |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
4.2.5. ARTI 描述应支持评估参数值的表达式¶
| 描述 | 表达式定义如何在目标上访问参数的特定值。 |
|---|---|
| 理由 | 表达式通常表示为 C 表达式。 |
| 依赖项 | - |
| 用例 | 表达式和值被调试器用于显示应用的当前状态。 |
| 支撑材料 | - |
4.2.6. ARTI 描述应支持对象参数使用的常量¶
| 描述 | 常量定义对象参数的值。 |
|---|---|
| 理由 | 对象参数可以是常量。该定义应提供常量的容器。 |
| 依赖项 | - |
| 用例 | 对象参数可以引用表达式或常量。这是常量参数的定义。 |
| 支撑材料 | - |
4.2.7. ARTI 描述应支持参数映射¶
| 描述 | 参数映射将参数的值转换为要显示的字符串。 |
|---|---|
| 理由 | 参数值可以指代特定含义（例如「状态」）。参数映射允许将该值转换为（人类可读的）字符串。 |
| 依赖项 | - |
| 用例 | ARTI 消费工具使用参数映射以有意义的方式显示参数值。 |
| 支撑材料 | - |
4.3. 面向 ARTI 描述的功能需求¶
本节中的需求均涉及 ARTI 描述应如何定义。
4.3.1. ARTI 描述应遵循 ARTI 模板¶
| 描述 | 所有与 ARTI 相关的信息都应按照 ARTI 模板收集在 ARTI 描述中。 |
|---|---|
| 理由 | 为访问 ECU 的运行时信息，工具需要知道如何读取该信息。通过严格遵循模板，工具无需进一步的用户交互即可提取所有必要信息。 |
| 依赖项 | ARTI 工具需要能够读取并理解 ARTI 模板以及可能的其他模板（例如 ECU 模板）。 |
| 用例 | 使用 ARTI 描述，ARTI 工具能够检测、可视化和测量 ECU 的任意对象。 |
| 支撑材料 | - |
4.3.2. ARTI 描述应包含通用对象的全部类定义¶
| 描述 | 应由 ARTI 消费工具处理的所有通用（任意）对象都应按照 ARTI 模板在类定义中定义。 |
|---|---|
| 理由 | ARTI 消费工具需要知道模块使用的所有通用对象的布局。 |
| 依赖项 | - |
| 用例 | 评估通用对象的显示形式。 |
| 支撑材料 | - |
4.3.3. ARTI 描述应包含通用对象的全部实例定义¶
| 描述 | 应由 ARTI 消费工具处理的所有通用（任意）对象实例都应按照 ARTI 模板在实例定义中定义。 |
|---|---|
| 理由 | ARTI 消费工具需要知道如何获取通用对象参数的值。 |
| 依赖项 | - |
| 用例 | 评估通用对象要显示的值。 |
| 支撑材料 | - |
4.3.4. ARTI 描述应包含评估参数值的全部表达式定义¶
| 描述 | 用于评估参数值的所有表达式都应按照 ARTI 模板定义。 |
|---|---|
| 理由 | ARTI 消费工具需要知道如何从目标读取参数的值。表达式通常表示为 C 表达式。 |
| 依赖项 | - |
| 用例 | 评估对象参数要显示的值。 |
| 支撑材料 | - |
4.3.5. ARTI 描述应包含参数使用的全部常量定义¶
| 描述 | 参数使用的所有常量都应按照 ARTI 模板定义。 |
|---|---|
| 理由 | 对象参数可以是常量。ARTI 消费工具需要知道哪个参数是常量以及要显示哪个值。 |
| 依赖项 | - |
| 用例 | 评估对象参数要显示的值。 |
| 支撑材料 | - |
4.3.6. ARTI 描述应包含参数使用的全部参数映射¶
| 描述 | 参数使用的所有参数映射都应按照 ARTI 模板定义。 |
|---|---|
| 理由 | 参数值可以指代特定含义（例如「状态」）。参数映射将特定参数的值转换为（人类可读的）字符串。 |
| 依赖项 | - |
| 用例 | ARTI 消费工具使用参数映射以有意义的方式显示参数值。 |
| 支撑材料 | - |
4.4. 面向 ARTI 钩子的功能需求¶
本节中的需求均涉及 ARTI 钩子应如何使用和定义。
4.4.1. ARTI 钩子应以最小侵入实现¶
| 描述 | ARTI 钩子应在源代码中以尽可能小的侵入实现。 |
|---|---|
| 理由 | ARTI 钩子将由 ARTI 消费工具扩展，可能加入影响应用运行时的额外代码。该侵入应保持尽可能小，例如通过使用 C 宏实现 ARTI 钩子。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 钩子可以实现为 C 宏。这使宏能够轻松展开为「空」，从而完全不产生侵入或副作用。ARTI 消费工具可以选择扩展该宏，以向该工具提供信息。 |
| 支撑材料 | - |
4.4.2. ARTI 钩子应遵循固定格式¶
| 描述 | ARTI 钩子应遵循固定格式。 |
|---|---|
| 理由 | 为使 ARTI 消费工具能够展开 ARTI 钩子，这些钩子遵循统一格式是有益的。 |
| 适用平台 | CP |
| 依赖项 | §4.4.1 |
| 用例 | 钩子可以实现为 C 宏。这使宏能够轻松展开为「空」，从而完全不产生侵入或副作用。ARTI 消费工具可以选择扩展该宏，以向该工具提供信息。 |
| 支撑材料 | - |
4.4.3. ARTI 钩子应提供关于调用上下文的信息¶
| 描述 | ARTI 钩子应提供关于调用上下文的信息。 |
|---|---|
| 理由 | 为确保 ARTI 钩子实现产生尽可能小的开销，ARTI 消费工具需要知道调用上下文。 |
| 依赖项 | §4.4.1 |
| 用例 | ARTI 消费工具可以选择扩展该宏，以在当前上下文中向该工具提供信息。这主要涉及特权级别以及中断是否被锁定。 |
| 支撑材料 | - |
4.4.4. ARTI 钩子应提供其所属类的名称¶
| 描述 | ARTI 钩子应提供其所属类的名称。 |
|---|---|
| 理由 | 钩子应按相似功能（事件）分组为类 |
| 依赖项 | §4.4.1 |
| 用例 | 为了提供钩子与 ARTI 消费工具之间更好的模块化，事件应分组为类（例如调度器事件或通信事件）。具体的类名在相应的平台文档中规定。 |
| 支撑材料 | - |
4.4.5. ARTI 钩子应提供事件的名称¶
| 描述 | ARTI 钩子应提供事件的名称。这些事件应分组为类。 |
|---|---|
| 理由 | |
| 依赖项 | §4.4.1 |
| 用例 | 事件名被 ARTI 消费工具用于标识特定事件。事件名在相应的平台文档中规定。 |
| 支撑材料 | - |
4.4.6. ARTI 钩子应提供事件的参数¶
| 描述 | ARTI 钩子应提供事件的参数。参数的数量由相应的事件规范规定。 |
|---|---|
| 理由 | |
| 依赖项 | §4.4.1 |
| 用例 | ARTI 消费工具可能需要额外的参数来标识属于某个事件的特定对象（例如调度器实体、发送方/接收方 ID）。 |
| 支撑材料 | - |
5. 参考文献¶
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
AUTOSAR_FO_RS_Main
A. AUTOSAR 可追溯项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的需求项。这些需求项在文档中不作为超链接出现。
A.1. 本文档依据 AUTOSAR 版本 R22-11 的可追溯项变更历史¶
A.1.1. R22-11 中新增的需求¶
无
A.1.2. R22-11 中变更的需求¶
表A.1：R22-11 中变更的需求
| 标题 |
|---|
| ARTI 钩子应以最小侵入实现 |
| ARTI 钩子应遵循固定格式 |
| ARTI 钩子应提供关于调用上下文的信息 |
| ARTI 钩子应提供其所属类的名称 |
| ARTI 钩子应提供事件的名称 |
| ARTI 钩子应提供事件的参数 |
A.1.3. R22-11 中删除的需求¶
无
A.2. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.2.1. R23-11 中新增的需求¶
无
A.2.2. R23-11 中变更的需求¶
表A.2：R23-11 中变更的需求
| 标题 |
|---|
| ARTI 钩子应以最小侵入实现 |
| ARTI 钩子应遵循固定格式 |
| ARTI 钩子应提供关于调用上下文的信息 |
| ARTI 钩子应提供其所属类的名称 |
| ARTI 钩子应提供事件的名称 |
| ARTI 钩子应提供事件的参数 |
A.2.3. R23-11 中删除的需求¶
无