Diagnostics
1. 文档范围¶
本文档规定 AUTOSAR 诊断（Diagnostics）的系统需求。它不依赖于任何特定实现，包含面向 AUTOSAR 经典平台与自适应平台的公共基础需求，以及经典平台和自适应平台各自特定的需求。
在经典平台章节中，应实现对法规 OBD 和增强诊断的处理。诊断基础软件元素集合应尽可能地由汽车软件模块的既有元素组成。只有在有充分理由时，有效的软件元素才应成为该集合的一部分。此时这些有效元素的定义不属于本工作包的范围。尽管如此，关于额外所需基础软件元素的信息应提供给相关工作组。
在自适应平台章节中，有几条与自适应环境相关的约束需要注意：
- 仅提供以太网作为物理通信基础设施的支持，1.0 版本不计划支持其他典型总线通信；因此，本规范未考虑引用其他总线协议标准（如 J1939、FlexRay、CAN 等）的所有经典 SRS 诊断需求
- 由于关于 AUTOSAR 自适应平台将适用的汽车域的信息不足，OBD 协议（标准化为 ISO 15031）也不属于本规范的对象
- AUTOSAR 自适应平台 1.0 版本计划作为未来开发的学习环境，因此其接口以 ICC1（接口符合类，Interface Conformance Class）粒度级别描述，即不规定内部的 DM 接口
2. 缩略语和缩写¶
CAN
控制器局域网（Controller Area Network，通信总线）
DEM
诊断事件管理器（Diagnostic Event Manager）
DID
诊断标识符（Diagnostic Identifier）
DM
诊断管理（Diagnostic Management）
DoIP
基于 IP 的诊断——标准化为 ISO 13400 的诊断服务传输协议
DTC
诊断故障码（Diagnostic Trouble Code）
ECU
电子控制单元（Electronic Control Unit）
IDL
接口描述语言（Interface Description Language）
OBD
车载诊断（标准化为 ISO 15031）
RTE
运行环境（Runtime Environment）
SA
源地址（测试仪的诊断地址）
SID
服务标识符（唯一标识 UDS 服务的十六进制数），0x22 为按标识符读取数据服务，0x2E 为写入非易失性存储器服务
SWC
软件组件（可指经典平台 SWC 或自适应平台 SWC）
TA
目标地址（ECU 的诊断地址）
UDS
统一诊断服务，标准化为 ISO 14229
3. 所用约定¶
在需求中使用了以下特定语义：
本文档中的关键词 'MUST'、'MUST NOT'、'REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'MAY' 和 'OPTIONAL' 应按如下方式解释。请注意，使用这些词语的文档的需求层级会修饰这些词语的强制力。
- SHALL：该词表示该定义是规范中的绝对要求。
- SHALL NOT：该短语表示该定义是规范中的绝对禁止。
- MUST：该词或术语 'REQUIRED' 或 'SHALL' 表示该定义是规范中的绝对要求。
- MUST NOT：该短语或短语 'SHALL NOT' 表示该定义是规范中的绝对禁止。
- SHOULD：该词或形容词 'RECOMMENDED' 表示，在特定情形下可能存在充分理由忽略某一事项，但在选择不同做法之前必须理解并仔细权衡其全部影响。
- SHOULD NOT：该短语或短语 'NOT RECOMMENDED' 表示，在特定情形下，某种特定行为是可接受的甚至有用的，但在实现以此标签描述的任何行为之前，应理解其全部影响并仔细权衡具体情况。
- MAY：该词或形容词 'OPTIONAL' 表示，某一事项是真正可选的。一个供应商可以选择包含该事项，因为特定市场需要它，或者因为该供应商认为它能增强产品；而另一个供应商可以省略同一事项。不包含某一特定选项的实现必须准备好与包含该选项的另一实现互操作（尽管功能可能有所减少）。同样，包含某一特定选项的实现必须准备好与不包含该选项的另一实现互操作（当然，该选项所提供的功能除外）。
4. 需求规范¶
4.1. 面向经典平台和自适应平台的通用诊断需求¶
支持事件组合
| 描述 | AUTOSAR 诊断应允许将若干单独的事件组合起来触发一个 DTC。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 改进事件/故障的聚类和判定。电子控制单元的若干内部硬件故障可以映射到单个「ECU 内部」失效上，以减少在维修车间向技术人员展示的故障码数量。 |
支持 ISO 14229-1 定义的主故障存储器
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1 定义的主故障存储器。 |
|---|---|
| 理由 | 为维修车间存储故障信息。 |
| 适用平台 | CP、AP |
| 依赖项 | 生产线、维修后的车间等。 |
| 用例 | 主故障存储器用于存储与车辆缺陷相关的故障信息，帮助维修车间识别故障并修复。 |
| 支撑材料 | - |
支持 ISO 14229-1 定义的用户自定义故障存储器
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1 定义的用户自定义故障存储器。 |
|---|---|
| 理由 | 故障信息的独立存储。 |
| 用例 | 用户自定义故障存储器由 OEM 和一级供应商在开发期间使用，或用于存储保修相关信息。如果用户自定义存储器中存储的信息对维修车辆有帮助（例如区分诸如未标定之类的缺陷性维护与明显故障），维修车间也可使用该信息。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
AUTOSAR 诊断应支持事件特定的去抖动计数器以在内部改善信号质量（依照 ISO 14229-1 附录 D）
| 描述 | 应支持以下类型的去抖动机制：AUTOSAR 诊断模块应提供配置去抖计数器跳变行为的能力，包括在事件报告预通过（pre-passed）或预失败（pre-failed）时的向上和向下跳变阈值。如果故障检测出现抖动（例如偶发性报告的预通过事件），故障检测不得被延迟或阻止。去抖计数器跳变行为的提供应确保故障检测时间，因为去抖总是从一个定义的起始点开始。此类计数器可以在内部或外部管理。 |
|---|---|
| 理由 | 高级故障分析。 |
| 用例 | 所有应用和系统模块都可以报告事件。诊断模块处理所有这些事件，并能够为事件分类和状态管理提供中央去抖行为。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
AUTOSAR 诊断应支持事件特定的基于时间的去抖计数器
| 描述 | AUTOSAR 诊断应支持事件特定的基于时间的去抖计数器。基于时间的去抖使用一个可配置的时间而不是计数器阈值。在最后一次监控结果/事件状态与之前不同后，该时间被重新装载并开始运行。时间超过后事件即完成判定。此类计数器可以在内部或外部管理。 |
|---|---|
| 理由 | 高级故障分析。 |
| 用例 | 所有应用和系统模块都可以报告事件。诊断模块处理所有这些事件，并能够为事件分类和状态管理提供中央去抖行为。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
作为 UDS 服务 ControlDTCSetting 一部分的可选参数 DTCSettingControlOptionRecord 应被限定为 GroupOfDTC
| 描述 | ISO 14229-1 未规定参数 DTCSettingControlOptionRecord 的使用方式。因此，该参数的使用应被限定为 GroupOfDTC。 |
|---|---|
| 理由 | 目前除用于 GroupOfDTC 之外，没有已知的参数 DTCSettingControlOptionRecord 的其他用例。 |
| 用例 | 针对一个特定 DTC 或所有 DTC 激活和停用故障存储。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
提供用于存储事件、状态信息和环境数据的可配置缓冲区大小
| 描述 | AUTOSAR 诊断应提供可配置的缓冲区大小，用于存储事件、状态信息和环境数据。由于资源限制，ECU 中只存储可能的事件相关数据中的一小部分。系统设计者应能够分配一定量的非易失性存储器用于故障存储器存储。 |
|---|---|
| 理由 | 由于所需内存的量，存储所有事件相关数据是不可行的。这些可配置的缓冲区大小允许独立于事件数量或事件相关数据大小来分配内存。 |
| 用例 | 在具有大量事件的大型系统中，应进行事件选择以满足较小处理器的 NVRAM/RAM 约束。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
将最终响应的结果告知外部服务处理器
| 描述 | 对于 AUTOSAR 诊断委托给应用处理的每项 UDS 服务，它应告知该应用响应是否已成功发出。 |
|---|---|
| 理由 | 对于将处理委托给自有工作线程的长时间运行的服务处理，异步回调模型更高效，而对于简单的服务处理器，严格的同步模型更易于实现。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
为 DTCSnapshotRecords 和 DTCExtendedDataRecords 提供可配置的记录编号和触发选项
| 描述 | AUTOSAR 诊断模块应提供为存储 DTCSnapshotRecords 和 DTCExtendedDataRecords 配置记录编号和触发选项的能力。 |
|---|---|
| 理由 | 高级故障分析。 |
| 用例 | DTCSnapshotRecords 和 DTCExtendedDataRecords 的灵活处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
自定义诊断服务
| 描述 | AUTOSAR 诊断应支持自定义诊断服务的配置。 |
|---|---|
| 理由 | 需要 ISO 14229-1 之外的服务。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_DEXT_00047 |
| 用例 | 修改既有服务的行为或为既有服务添加自定义行为（例如在诊断会话控制的肯定响应中不包含会话 P2 时序值），或将特定服务添加为「数据日志」服务。 |
时序参数的配置
| 描述 | 每个物理层都需要特定的时序参数值，因此有必要包含根据所使用网络配置时序约束的能力。时序参数在通信开始时被设置为默认值，并且应可在运行时变更。 |
|---|---|
| 理由 | 在不同网络上的可用性。 |
| 用例 | 诊断通信可以在不同的网络上进行（例如 CAN/LIN/FlexRay/以太网）。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
支持在扩展的且制造商特定的诊断会话中用于读取/写入 ECU 数据的上传/下载服务
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1:2013 支持 UDS 服务 RequestDownload、RequestUpload、TransferData、RequestTransferExit（0x34-0x37）。注意，在经典平台中这些服务通常也实现在 Bootloader 内部，这超出了本需求的范围。 |
|---|---|
| 理由 | 提供上传和下载数据块的手段。 |
| 用例 | 在下线（EOL）或开发期间下载配置或应用数据。另一个用例是从 ECU 上传数据块用于评估或验证目的。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
抑制对诊断工具请求的响应
| 描述 | AUTOSAR 诊断应支持 suppressPosRspMsgIndicationBit 以及 ISO 14229-1:2013 规定的行为。 |
|---|---|
| 理由 | 测试仪在某些情形下不关心肯定响应。它防止功能性请求引起的总线突发。 |
| 用例 | 在大多数情况下，肯定响应与将车辆设置为某种状态的功能性请求无关。这可以是在重编程期间的 0x85、0x28 和功能性 0x3E 服务序列，以使车辆保持「静默」状态，即正常总线通信被关闭且 DTC 设置被关闭。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
按照所分配的诊断会话处理诊断服务的执行
| 描述 | 如果发生诊断会话转换（由 UDS 服务 0x10 发起），AUTOSAR 诊断应只在新会话支持且未被安全访问禁止时，才维持活动的诊断功能。 |
|---|---|
| 理由 | 不中断诊断功能。 |
| 用例 | 在 ECU 重编程期间停用故障管理和正常通信。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
通过发送否定响应 0x78 支持「忙处理」
| 描述 | AUTOSAR 诊断应提供否定响应 0x78 的发送，以获得更多时间来构建最终的肯定或否定响应。 |
|---|---|
| 理由 | 确保稳定且安全的通信链路，并保证规定的时序条件。 |
| 用例 | 当应用无法在协议规定的时间内提供响应时。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
管理会话处理
| 描述 | AUTOSAR 诊断应支持从默认会话到任何其他会话的转换，以及返回默认会话。（诊断会话启用一组特定的诊断服务和/或功能。） |
|---|---|
| 理由 | 必须拥有关于当前会话的信息，并且连接到非默认会话的任何服务都不应在默认会话中被处理。 |
| 用例 | 减少网络上的通信流量，以获得更多的通信资源。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04005（SecurityAccess 级别处理） |
| 支撑材料 | - |
管理安全访问级别处理
| 描述 | AUTOSAR 诊断应管理 UDS 服务 0x27（SecurityAccess）的处理以及安全级别处理。应检查当前安全级别下服务（服务标识符）的可访问性。 |
|---|---|
| 理由 | 某些诊断服务依赖于安全访问级别。因此，必须拥有关于当前级别的信息，并且受安全限制的任何服务都不得在未经授权的情况下被处理。 |
| 用例 | 并非所有诊断服务在每个安全级别中都被允许。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
支持 UDS 服务 $38（RequestFileTransfer）
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x38（"RequestFileTransfer"）。 |
|---|---|
| 理由 | 该服务支持从客户端到服务器或从服务器进行文件传输（下载或上传）。此外，该服务还具有相应的能力。 |
| 用例 | 文件的上传（例如数据文件、图形、导航数据等）。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04059（时序参数的配置） |
| 支撑材料 | ISO 14229-1 v.2013 |
与标准 Bootloader 交互
| 描述 | 将标准 Bootloader 集成到 AUTOSAR 架构中。• 如果 AUTOSAR 诊断被请求切换到编程会话（$1002），它应要么先发送最终响应再激活 Bootloader，要么不发送最终响应而激活 Bootloader，由 Bootloader 激活自身并发送最终响应（依照 HIS [FL-504]）。 |
|---|---|
| 理由 | Bootloader 概念必须在 AUTOSAR 内标准化。 |
| 用例 | 使用「现成的」Bootloader。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
通过 UDS 服务 0x85 控制 DTC 存储
| 描述 | AUTOSAR 诊断应支持通过 UDS 服务 0x85 控制 DTC 存储。 |
|---|---|
| 理由 | 防止在特定情形（如重编程）期间记录 DTC。 |
| 用例 | 在 ECU 重编程期间停用 DTC 存储。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
DTC 与相关数据的报告
| 描述 | AUTOSAR 诊断应提供 DTC 及相关数据的报告。 |
|---|---|
| 理由 | 将故障存储器数据报告给请求方。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 所有报告故障存储器数据的服务。 |
| 支撑材料 | - |
支持 DTCFunctionalUnit
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 DTCFunctionalUnit。 |
|---|---|
| 理由 | 符合 ISO 14229-1。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | DTC 的 OEM 特定使用。 |
| 支撑材料 | - |
使用持久化模块提供的标准机制
| 描述 | -。 |
|---|---|
| 理由 | 非易失性数据存储。 |
| 用例 | 在正常 ECU 运行期间触发数据存储，以避免易失性数据/事件信息的丢失。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
一致的事件管理机制
| 描述 | 所有存储位置应使用相同的事件管理机制。 |
|---|---|
| 理由 | 确保相同的事件管理行为。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
DTC 删除的可配置行为
| 描述 | 通常只有 ClearAllDTCs 用于 DTC 的删除。因此，提供一个可配置的行为，可选地将 DTC 的删除限定为 ClearAllDTCs。 |
|---|---|
| 理由 | OEM 特定的行为。 |
| 用例 | 只允许 ClearAllDTCs，从而优化 ClearDTC 行为。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
提供防御性行为
| 描述 | 对于安全相关应用，AUTOSAR 诊断应确保存储在非易失性存储器中的故障信息的数据完整性。 |
|---|---|
| 理由 | 安全相关应用需要故障存储器的错误保护。 |
| 用例 | 故障存储器可能已被破坏。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 使用 AUTOSAR 持久化模块为存储的故障存储块提供的可选 CRC 和冗余能力。只有分配给高严重性错误事件的块可以被保护。这些块可以在错误事件被确认时（在 ECU 关机之前）存储到非易失性存储器中。 |
事件存储器管理
| 描述 | AUTOSAR 诊断应能够处理有效事件、更新既有的事件存储器条目，或在事件存储器已满时替换事件。处理由外部触发（例如由报告的事件状态）或取决于内部信息（例如去抖计数器值、计时器、出现计数器等）。 |
|---|---|
| 理由 | 支持故障存储和分析。 |
| 用例 | 支持故障存储和分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
关于有效冻结帧数据向应用的通知
| 描述 | AUTOSAR 诊断应能够向其他应用（或系统模块）通知有效的冻结帧数据（例如时间戳）。如果为某个事件配置了该功能，则每次有效的冻结帧被存储到事件存储器时都应执行该功能。 |
|---|---|
| 理由 | 该信息由诸如特殊的「诊断主动响应处理器」之类的模块需要。此外，该功能提供了一种将这些数据提供给其他模块的简单方式。 |
| 用例 | 该功能提供的信息是诸如「诊断主动响应处理器」之类的模块所需要的。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
事件状态处理
| 描述 | 诊断应支持事件状态处理。 |
|---|---|
| 理由 | 支持 OEM 特定的事件状态处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 评估监控结果并从中导出相应的动作。 |
| 支撑材料 | - |
按照事件定义的重要性（如优先级和/或严重性）处理事件
| 描述 | 事件应被排序或被分配一个表示其重要性的特定优先级（例如严重性掩码——ISO 14229-1 v.2013 附录 D3），例如： * 已愈合的事件可以被覆写； * 当事件缓冲区已被较低优先级的事件填满时的特权存储。 |
|---|---|
| 理由 | ISO 14229-1 v.2013。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 改进事件的聚类和判定。 |
事件去抖计数器应是可配置的
| 描述 | 当事件的至少一个使能条件被置为「未满足」或 ControlDTCSetting 被置为「禁用」时，去抖计数器应被冻结还是复位，应是可配置的。在使能条件被切换为「已满足」的情形下，需要通知监控器重启事件检测。在 ControlDTCSetting 被切换为「重新启用」的情形下，需要通知监控器重启事件检测。 |
|---|---|
| 理由 | 内部去抖的灵活使用。 |
| 用例 | - |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
可配置的「已确认」阈值
| 描述 | AUTOSAR 诊断应支持下线后（postbuild）可配置的「已确认（confirmed）」阈值。 |
|---|---|
| 理由 | 灵活适用本地法规要求。 |
| 用例 | 对于美国市场，MIL 和 ConfirmedDTC 在 2 个 DCY（驾驶循环）之后激活。对于欧洲市场，MIL 和 ConfirmedDTC 在 3 个 DCY（驾驶循环）之后激活。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
UDS 状态位「confirmedDTC」和「testFailedSinceLastClear」的老化
| 描述 | AUTOSAR 诊断应提供在达到可配置的老化循环数之后使 confirmedDTC 位和 testFailedSinceLastClear 位两者的老化的能力。两者被老化的值可以不同。 |
|---|---|
| 理由 | -。 |
| 用例 | -。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
客户端证书中的访问权限
| 描述 | 客户端证书扩展应包含带有诊断访问权限的、定义良好的数据。应提供以下访问权限类型： * 基于角色的访问权限 * 动态访问权限 对于基于角色的访问权限，ECU 维护关于在测试仪已获得该角色的认证时允许执行哪些诊断服务的信息。有效的客户端证书将测试仪置入该角色。证书可以包含同时处于活动状态的多个角色。对于动态访问权限，证书包含允许执行的诊断服务的白名单。白名单访问应允许 PDU 级别的通配符。两种访问权限类型可以在任何时间点处于活动状态，并且应应用逻辑「或」运算。证书访问权限内容的结构化数据布局应由 AUTOSAR 规定。 |
|---|---|
| 理由 | AUTOSAR 诊断只应接受定义良好的客户端证书，从而允许对证书及其内容进行标准化处理和评估。 |
| 用例 | OEM PKI 为维修车间颁发一份带有基于角色的或针对诊断服务的个人访问权限的证书。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
诊断服务的访问粒度
| 描述 | 证书提供基于角色的和个人的访问权限定义。AUTOSAR 诊断应通过按以下顺序评估待执行服务的属性来提供诊断服务访问权限： * 服务 ID（SID） * 服务 ID 和子功能（SF） * 数据标识符（DID） * 例程标识符（RID）。 如果上述任何属性属于该角色或当前动态访问权限（白名单），则可以执行该服务。 |
|---|---|
| 理由 | 需要一个关于如何标识要执行的诊断服务的定义。特别是粒度级别对于将资源消耗降到最低非常重要。SID 检查非常粗略但高效，对于带子功能的服务可以考虑子功能。此外，带 DID 和 RID 的服务仅通过该标识符来识别。 |
| 用例 | 一个认证状态允许执行任何 ECU 复位服务、被限制在扩展会话中、允许执行 5 个 DID 和一个 RID。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
个人访问白名单的二进制兼容性
| 描述 | AUTOSAR 诊断应规定白名单的二进制布局。该布局应对所有 ECU 兼容，与所处字节序无关。 |
|---|---|
| 理由 | 需要一个关于白名单应当如何构造的定义，使它可以被下载到任何 ECU 软件中，而与所使用的实现无关。 |
| 用例 | 白名单的某个二进制布局应定义一组被允许执行的、定义良好的诊断服务。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
客户端证书有效期
| 描述 | AUTOSAR 诊断应评估客户端证书的有效期，并拒绝已过期或尚未生效的证书。 |
|---|---|
| 理由 | 控制证书的生命周期，并限制过时证书的潜在风险。 |
| 用例 | OEM PKI 为维修车间颁发一份在规定期限内的证书。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
客户端证书目标识别
| 描述 | AUTOSAR 诊断应提供用于目标识别的标准化手段。目标可以由 OEM 定义的标准来识别，例如 VIN、车型或 ECU 类型。 |
|---|---|
| 理由 | 只在定义的目标上控制证书的有效性。 |
| 用例 | OEM PKI 为具有某一 VIN 的车辆颁发证书，或仅为一种 ECU 类型颁发证书。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
客户端证书评估
| 描述 | AUTOSAR 诊断应使用诊断策略管理器来评估来自服务 0x29 请求的客户端证书。证书评估的结果是关于证书是否有效以及允许执行哪些诊断服务的判定。基于活动证书，它为所接收的诊断请求授予访问权。 |
|---|---|
| 理由 | AUTOSAR 应为证书载荷定义语义。这样可以标准化地检查证书有效期并评估所包含的访问权限。 |
| 用例 | 维修车间诊断测试仪通过发送其证书发起认证。认证之后，一组诊断服务对该诊断测试仪可用。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
记录证书评估日志
| 描述 | 每当一份证书被提交评估时，诊断策略管理器应报告一个安全事件。事件数据应至少包含证书评估的结果。 |
|---|---|
| 理由 | 取证分析和相关方需要关于向诊断测试仪请求并授予了何种访问的信息。 |
| 用例 | 诊断测试仪提供了一份具有扩展访问权限的证书。一个安全事件提供关于该特定证书被提供给 ECU 的信息。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
去认证状态下的诊断服务
| 描述 | AUTOSAR 诊断应具有允许在去认证状态下执行特定诊断服务的配置。 |
|---|---|
| 理由 | 至少用于认证测试仪的那些服务应在所有状态下都可用。 |
| 用例 | 在去认证状态下发送服务 0x29 以达到某个认证状态。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
基于应用的身份认证
| 描述 | AUTOSAR 诊断应向应用提供改变未认证连接的认证状态的手段。 |
|---|---|
| 理由 | 对车辆中的每台 ECU 分别认证可能对某些应用而言耗时过长。 |
| 用例 | 需要基于应用的集中式认证广播来获得对一组诊断服务的访问。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | 概念 636 "Security Extensions" |
事件存储器条目的老化
| 描述 | AUTOSAR 诊断应支持事件存储器条目的老化，以从事件存储器中移除在特定数量的运行循环内未发生失效的条目。 |
|---|---|
| 理由 | 从故障存储器中移除与维修动作无关的信息。 |
| 用例 | 已被检测到但不再处于活动状态的网络超时故障。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
为每条监控路径处理一个专用的事件标识符，以支持不同事件/故障的自主处理
| 描述 | 对于内部管理，AUTOSAR 诊断需要每条监控路径的唯一标识。该标识应通过一个事件 ID 值（整数）来处理。 |
|---|---|
| 理由 | 每条监控路径应由其唯一的事件 ID 值唯一标识。 |
| 用例 | 可用于增强调试的唯一故障识别。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
提供向应用告知诊断数据变化的能力
| 描述 | AUTOSAR 诊断模块应提供向应用告知诊断数据变化的能力。这些能力应涵盖为数据元素及其关联触发器提供相应的接口和配置选项。 |
|---|---|
| 理由 | 应用需要关于数据变化的信息。 |
| 用例 | 应用需要被告知某个 DTC 的状态变化，以便能够对该 DTC 状态作出反应。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
应用中的去中心化和模块化诊断配置
| 描述 | 应用可以提供诊断信息。AUTOSAR 诊断模块应能够生成可连接到这些应用的端口，以访问这些诊断数据。 |
|---|---|
| 理由 | 由于去中心化的配置和接口需求，每个应用应提供并实现诊断接口，以允许代码生成和端口连接。 |
| 用例 | 用例示例： * 如今，功能及其关联诊断由多方开发。因此，对于每个功能及其监控应用（例如发动机控制器中的扭矩管理），诊断能力被分别定义，并且在开发期间不必然被协调。 * 系统集成以及通过 AUTOSAR 诊断组合诊断以实现可访问性，要求各个功能和诊断特性被连接起来，编译为一个完整的诊断系统（这在 OBD2 认证中是相关的）。 用例总结：1. 在不与其他应用开发者持续交互的情况下开发去中心化的模块化软件及其诊断。2. 组合模块并提取模块特定的诊断数据。3. 将来自应用的诊断数据链接到 AUTOSAR 诊断。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
按照 ISO 14229-1 提供诊断状态信息
| 描述 | AUTOSAR 诊断应按照 DTCStatusMask（ISO 14229-1 v.2013，参见 DTC 状态掩码）附录 D5 提供诊断状态信息。 |
|---|---|
| 理由 | 高级故障分析。 |
| 用例 | 改进故障和事件的跟踪与分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 |
为监控应用提供接口。
| 描述 | AUTOSAR 诊断应为监控应用提供一个用于报告和处理监控结果的接口。所报告的结果应通过一个 EventID 唯一地标识。 |
|---|---|
| 理由 | 事件结果在内部处理。AUTOSAR 诊断与监控应用之间的交互通过该接口完成。 |
| 用例 | 监控应用在有效结果可用时立即使用所提供的接口报告测试结果。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
按照 ISO 14229-1 支持运行循环
| 描述 | AUTOSAR 诊断应提供一组可配置的系统循环，这些循环可以以附加的方式对事件进行判定。 |
|---|---|
| 理由 | 运行循环是事件状态管理的关键。 |
| 用例 | 运行循环的启动会触发许多类型的系统反应。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 v.2013 和 ISO 15031-5 |
支持将特定事件分配给客户特定 DTC 的配置
| 描述 | 将事件分配给客户特定的或标准化的 DTC。 |
|---|---|
| 理由 | 事件请求仅在 AUTOSAR 诊断内部使用。外部请求的是一个被分配给一个或多个事件/监控器的 DTC 编号。 |
| 用例 | 内部扫描工具的监控结果（例如驾驶员可感知的结果）是可观测的，从而支持外部故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
在内部处理与 ISO 14229-1 诊断故障存储器相关的所有 UDS 服务
| 描述 | 与故障存储器相关的所有 UDS 服务的服务实现应在 AUTOSAR 诊断内部实现，而不将处理或部分处理委托给外部模块。 |
|---|---|
| 理由 | 由于 AUTOSAR 诊断也负责故障存储器管理，所有与故障存储器相关的 UDS 服务都必须在内部处理。 |
| 用例 | 像 0x85、0x14、0x19 这样的故障存储器处理必须在内部处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 14229-1 |
提供一个应用接口以变更运行循环的状态
| 描述 | 由 AUTOSAR 诊断处理的运行循环可以由应用重启。 |
|---|---|
| 理由 | 运行循环管理的状态转换是按照 ISO 14229-1 的事件状态的触发条件。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04178 |
| 用例 | 应用重启某个运行循环。这会触发相关事件的一些状态变化以便监控。 |
向相关方通知事件状态变化
| 描述 | 事件状态变化报告应对订阅该通知的应用可用。 |
|---|---|
| 理由 | 事件特定的状态信息在 AUTOSAR 诊断内部处理，状态的变化可能与监控或其他应用相关。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 应用被告知相关的事件状态变化。 |
| 支撑材料 | - |
向应用通知事件的清除
| 描述 | 相关的监控应用应被告知事件状态信息和事件相关数据的清除。 |
|---|---|
| 理由 | 监控器的重新初始化可以由清除通知触发。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在事件状态被清除之后，AUTOSAR 诊断通知相关的监控应用，该应用可以被重新初始化。 |
| 支撑材料 | - |
向应用通知运行循环的启动或重启
| 描述 | 相关的监控应用应被告知运行循环的启动或重启。 |
|---|---|
| 理由 | 监控器的重新初始化可以由运行循环的启动触发。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在 AUTOSAR 诊断将相关运行循环的启动告知监控应用之后，该监控应用被初始化。 |
| 支撑材料 | - |
提供每个警告指示器的当前状态。
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 从被分配的事件导出当前警告指示器的状态。warningIndicatorRequested 位应按照 ISO 14229-1 设置。 |
|---|---|
| 理由 | 警告指示器是向驾驶员指示特定失效的一种手段，例如灯、文本消息或蜂鸣。该状态在 AUTOSAR 诊断中计算。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 向驾驶员指示某些故障（例如故障指示器 MIL）。 |
| 支撑材料 | - |
支持 SnapshotRecords
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 SnapshotRecords。每个 DTC 可以可选地拥有一个或多个 SnapshotDataRecords。支持的记录编号应是可配置的。只应支持整个记录的原子更新。存储触发器应按快照记录编号可配置。该可配置的触发器基于以下 DTC 状态位转换：TestFailed_Set；Confirmed_Set；Pending_Set；FaultDetectionCounterThreshold_Reached。环境数据应从外部应用采集。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在故障发生时采集系统内部的数据。 |
| 支撑材料 | ISO 14229-1 |
支持 ExtendedDataRecords
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 ExtendedDataRecords。每个 DTC 可以可选地拥有一个或多个 ExtendedDataRecords。记录编号应是可配置的。只应支持整个记录的原子更新。存储触发器应按扩展数据编号可配置。该可配置的触发器基于以下 DTC 状态位转换：TestFailed_Set；Confirmed_Set；Pending_Set；FaultDetectionCounterThreshold_Reached。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 提供分配给某个 DTC 的系统内部统计信息。 |
| 支撑材料 | ISO 14229-1 |
为 SnapshotRecords 和 ExtendedDataRecords 提供细粒度的配置
| 描述 | AUTOSAR 诊断应能够处理事件相关数据的细粒度布局配置。数据元素可以从不同的应用采集，并被合并到不同的 DID 或 ExtendedDataRecords 中。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 为特定用例定制事件相关数据的布局。 |
| 支撑材料 | - |
在 SnapshotRecords 和 ExtendedDataRecords 中使用内部数据元素
| 描述 | 应可以将 AUTOSAR 诊断的内部数据元素（如运行循环计数器、故障检测计数器（FDC）和出现计数器）分配给 Snapshot- 和 ExtendedDataRecords。在读取 Snapshot- 或 ExtendedDataRecord 时，应报告 AUTOSAR 诊断内部数据元素的当前值。 |
|---|---|
| 理由 | AUTOSAR 诊断内部生成的一些数据对象可以通过 UDS 服务 0x19 ReadDTCInformation 获取。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04205 |
| 用例 | 读取运行循环计数器、故障检测计数器和出现计数器。 |
提供处理事件特定使能条件的能力
| 描述 | AUTOSAR 诊断应支持每个事件的使能条件。如果事件特定的使能条件未满足，则所报告的事件状态不被处理。 |
|---|---|
| 理由 | 提供在特定 ECU 条件下避免大量事件存储器条目的机制。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在某些车辆条件（如发动机起动）下，应在一定时间内避免评估某个监控应用的结果。 |
| 支撑材料 | - |
提供处理事件特定存储条件的能力
| 描述 | AUTOSAR 诊断应支持每个事件的存储条件。存储条件用于阻止事件相关数据（例如快照记录）的存储过程，因为该数据在这种情形下没有意义，且没有必要为这些事件相关数据花费非易失性存储器。如果事件特定的存储条件未满足且发生了存储事件相关数据的触发，则不采集任何事件相关数据，且 UDS 状态位 2（pendingDTC）和 3（confirmedDTC）不被置为 1。 |
|---|---|
| 理由 | 提供在事件相关数据没有意义的情形下避免事件存储器条目的机制。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 对于某些事件，只导出安全相关信息（例如通过 Fim），但由于另一个根因处于活动状态且只为该根因存储事件相关数据，可以跳过进一步的处理。 |
| 支撑材料 | - |
ClearDTC 应对应用可访问
| 描述 | AUTOSAR 诊断提供的服务 ClearDTC 支持清除指定存储来源的 DTC 的功能。该服务不仅应在 AUTOSAR 诊断内部可用，还应对应用可用。 |
|---|---|
| 理由 | UDS 任务 0x14 ClearDiagnosticInformation 只支持清除主存储器。用户自定义存储来源的清除通常由应用处理，这就是为什么应提供 ClearDTC 服务。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 一个例程控制 UDS 任务激活应用，该应用使用 AUTOSAR 诊断中的 ClearDTC 服务清除用户自定义存储器中的 DTC。 |
| 支撑材料 | - |
所配置事件存储器中 DTC 的按时间顺序的报告顺序
| 描述 | AUTOSAR 诊断应能够处理事件出现的顺序（例如由时间戳或里程表值表示）。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在处理 0x19 UDS 任务时，DTC 按时间顺序返回。 |
| 支撑材料 | - |
DTC 状态和环境数据的持久化存储
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1 所要求的事件状态和环境数据参数的非易失性存储。 |
|---|---|
| 理由 | 根据 ISO 14229-1 UDS 规范，一组状态信息和环境数据应被非易失性地存储。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 状态信息跨电源周期被非易失性地存储。 |
| 支撑材料 | ISO 14229-1 附录 D |
支持 DTC 抑制
| 描述 | AUTOSAR 诊断应提供在诊断服务中抑制 DTC 使其不可见的可能性。被抑制的 DTC 应在内部可用并像任何其他 DTC 一样被处理。 |
|---|---|
| 理由 | 在某些条件下（例如特定市场）需要隐藏 DTC。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在特定市场中隐藏 DTC。 |
| 支撑材料 | - |
针对 ISO 14229-2 中定义的所有诊断服务的 UDS 服务处理
| 描述 | AUTOSAR 诊断应实现 ISO 14229-2 中定义的所有 UDS 服务的协议处理。 |
|---|---|
| 理由 | AUTOSAR 诊断应是 UDS 诊断的中央服务处理器。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在以太网上与符合 UDS 的测试仪交互。 |
| 支撑材料 | ISO 14229 |
对所有支持的 UDS 服务请求的公共检查
| 描述 | 对于 UDS 服务，诊断模块应检查所请求的 SID 是否受支持。如果服务 ID 有效，并且取决于该服务 ID，则应检查潜在的子功能标识符是否受诊断模块支持。 |
|---|---|
| 理由 | AUTOSAR 诊断应符合 UDS，并应在 UDS 协议层面集中执行可以完成的公共检查，无论该服务是在内部处理还是由应用作为服务处理器在外部处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 必须验证所请求的服务是否受支持（例如 ClearDTC 等）。 |
| 支撑材料 | ISO 14229 |
诊断会话检查
| 描述 | 对于 UDS 服务，诊断模块应检查诊断会话的支持。 |
|---|---|
| 理由 | AUTOSAR 诊断应符合 UDS，并应在 UDS 协议层面集中执行可以完成的公共检查，无论该服务是在内部处理还是由应用作为服务处理器在外部处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 会话变更应只允许规定的变更。 |
| 支撑材料 | ISO 14229 |
安全访问的公共检查
| 描述 | 对于 UDS 服务，诊断模块应检查诊断安全级别的支持。 |
|---|---|
| 理由 | AUTOSAR 诊断应符合 UDS，并应在 UDS 协议层面集中执行可以完成的公共检查，无论该服务是在内部处理还是由应用作为服务处理器在外部处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 保护服务不被未授权用户访问。 |
| 支撑材料 | ISO 14229 |
消息长度的公共检查
| 描述 | 对于 UDS 服务，诊断模块应检查消息长度的支持。 |
|---|---|
| 理由 | AUTOSAR 诊断应符合 UDS，并应在 UDS 协议层面集中执行可以完成的公共检查，无论该服务是在内部处理还是由应用作为服务处理器在外部处理。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 必须检查消息长度，如果它不遵守预定义的范围，则所请求的服务将被拒绝。 |
| 支撑材料 | ISO 14229 |
用户自定义故障存储器的清除
| 描述 | 用户自定义故障存储器的清除应可以通过诊断请求完成，遵循 ISO 14229 草案文档：'02_ISO_14229-1_Comments-Summary_2016-09-13.docx'。 |
|---|---|
| 理由 | 提供清除用户自定义故障存储器的标准化方式。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 使用用户自定义故障存储器的 OEM 和一级供应商需要清除用户自定义存储器。一种标准化的方式使 OEM 或一级供应商特定的（彼此不兼容的）解决方案变得不再必要。 |
| 支撑材料 | ISO 14229-1 |
在内部处理与 ISO 14229 会话和安全管理相关的所有 UDS 服务
| 描述 | 与会话和安全管理相关的所有 UDS 服务（来自「诊断和通信管理功能单元」的 DiagnosticSessionControl、SecurityAccess 和 TesterPresent）的服务实现应在 AUTOSAR 诊断内部实现，而不将处理或部分处理委托给外部模块。这并不排除 AUTOSAR 诊断调用外部应用（例如获取/检查某些安全密钥）。但状态机/协议由 AUTOSAR 诊断在内部处理。 |
|---|---|
| 理由 | 会话和安全管理是通用 UDS 服务处理的组成部分，因此必须在内部实现。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 通用的诊断协议处理。 |
| 支撑材料 | ISO 14229 |
提供一个可在运行时判定是否处理 UDS 请求的可配置 UDS 服务执行机制
| 描述 | AUTOSAR 诊断应支持查询已配置的应用：所接收的 UDS 服务请求应被处理还是被拒绝。 |
|---|---|
| 理由 | 基础设施/OEM 特定的监控组件基于 ECU/车辆状态决定服务的执行。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 仅在一定的车辆状态下允许执行某些服务（例如不在二级存储器中记录 DTC）。 |
| 支撑材料 | ISO 14229 |
在每个测试仪连接上向应用告知诊断会话和诊断安全级别的变化。
| 描述 | 在某个测试仪会话上当前活动的 UDS 会话或安全级别发生变化的情形下，AUTOSAR 诊断应为应用提供一种通知机制，向应用告知新的会话或安全级别以及受影响的测试仪连接。 |
|---|---|
| 理由 | 会话变化相对于服务处理器实现是异步发生的。但存在需要针对会话变化作出反应的功能。 |
| 适用平台 | CP、AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
| 支撑材料 | - |
支持 UDS 服务 0x2F InputOutputControlByIDentifier
| 描述 | 诊断管理应支持 ISO 14229-1 服务 0x2F InputOutputControlByIDentifier。 |
|---|---|
| 理由 | 允许模拟输入值并控制输出值。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在车间或生产检查中需要对 ECU 的输入和输出通道进行操作。 |
| 支撑材料 | ISO 14229-1 |
清除 DTC 状态与系统降级的独立性
| 描述 | 清除 DTC 状态与系统降级相互独立。 |
|---|---|
| 理由 | 清除 DTC 不得影响系统降级。否则，在清除后系统将进入正常运行并引发严重的功能问题（例如错误的执行器动作）。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在系统降级的情形下，事件应可以在 Clear 调用时保持状态不变。不过，被系统降级影响的 DTC 的状态字节仍会被处理。 |
| 支撑材料 | ISO 14229-1 |
按照 ISO 14229-1 支持 UDS 服务 0x31（RoutineControl）
| 描述 | AUTOSAR 诊断应支持带所有子功能的 ISO 14229-1 服务 0x31 RoutineControl。 |
|---|---|
| 理由 | RoutineControl 是 ISO 14229-1 的组成部分，并在大多数 ECU 中用于由诊断服务触发的客户特定动作。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 诊断测试仪在服务器中启动一个例程。 |
| 支撑材料 | ISO 14229-1 |
DoIP 模块应支持车辆内部测试仪。
| 描述 | 除外部测试仪之外，DoIP 模块应支持车辆内部测试仪，并为此引用 ISO 标准 13400-2。 |
|---|---|
| 理由 | 支持车内 DoIP 通信。 |
| 用例 | DoIP 测试仪不仅驻留在车辆网络之外，也可能驻留在车辆网络之内。支持车内 DoIP 通信。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 13400-2, Road vehicles - Diagnostic communication over Internet Protocol (DoIP) - Part 2: Transport protocol and network layer services；ISO 13400-2 带内部测试仪概念的扩展。 |
与传输层通信以接收和发送诊断数据
| 描述 | AUTOSAR 诊断应与传输层模块通信以接收和发送诊断数据。 |
|---|---|
| 理由 | 确保诊断通信。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 支持多种传输协议（ISO-15765-2 等）。 |
| 支撑材料 | - |
支持 UDS 服务 0x19 的子功能 0x04。
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x19 的子功能 0x04，以检索为 DTC 存储的快照记录。 |
|---|---|
| 理由 | 提供检索快照记录的手段。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在系统中发生故障的各个时间点采集数据。 |
| 支撑材料 | ISO 14229-1 |
支持 UDS 服务 0x19 的子功能 0x06。
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x19 的子功能 0x06，以检索为 DTC 存储的扩展数据记录。 |
|---|---|
| 理由 | 提供检索统计数据的手段。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 提供分配给某个 DTC 的系统内部统计信息。 |
| 支撑材料 | ISO 14229-1 |
访问不同事件存储器的能力
| 描述 | AUTOSAR 诊断应支持诊断服务，以分别读取或移除所配置事件存储器中的事件条目。 |
|---|---|
| 理由 | 高级故障分析。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | OEM 和供应商的开发部门需要尽可能深入的故障/事件分析，尽管维修人员可能已删除故障、或不需要知道某个事件或故障是否存在更详细的根因。 |
| 支撑材料 | - |
按照 ISO 14229-1 的 ResponseOnEvent
| 描述 | 诊断应按照 ISO 14229-1 支持 ResponseOnEvent。 |
|---|---|
| 理由 | 故障分析和故障存储器跟踪需要。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 将某些运行时条件告知诊断工具。 |
| 支撑材料 | - |
提供一个接口以检索事件存储器条目的数量
| 描述 | AUTOSAR 诊断应提供一个接口，向应用检索当前存储在主存储器和用户自定义存储器中的事件存储器条目的数量。此外，应提供相应的客户端-服务器接口。 |
|---|---|
| 理由 | 应用需要该接口来检查事件存储器中是否存在影响 ECU 行为的事件存储器条目。 |
| 用例 | 存在这样一种应用消息：一旦事件被存储到事件存储器中，就必须置位某个状态位。因此，应用需要知道存在多少事件存储器条目。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
支持 UDS 服务 DynamicallyDefineDataIdentifier（0x2C）的子功能 0x01（defineByIdentifier）
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 UDS 服务 DynamicallyDefineDataIdentifier（0x2C）的子功能 0x01（defineByIdentifier）。 |
|---|---|
| 理由 | UDS 定义该服务以允许客户端在稍后的时间点动态定义一个数据标识符。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 通过 UDS 服务 0x22/0x2A，对由既有数据标识符的部分或全部内容构建的定制数据标识符执行读取操作。 |
| 支撑材料 | - |
支持 UDS 服务 ReadDataByPeriodicIdentifier（0x2A）
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 UDS 服务 ReadDataByPeriodicIdentifier（0x2A）及其所有受支持的子功能。 |
|---|---|
| 理由 | 相比于通过 ReadDataByIdentifier 重新请求相同数据的频繁轮询，该服务降低了总线负载。此外，可以达到更高的更新率。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 通过诊断随时间监控测量值。 |
| 支撑材料 | - |
支持会话控制服务
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x10（SessionControl）及其所有强制子功能，并允许定义车辆制造商特定和系统供应商特定的子功能。 |
|---|---|
| 理由 | 会话是控制「存在活动的测试仪连接」并将某些服务限制为只在特定会话中执行的关键手段。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 只在时序受保护的会话中执行某些诊断服务；回退到默认会话将停止该会话中已启动的所有诊断活动。 |
| 支撑材料 | - |
支持会话层服务
| 描述 | AUTOSAR 诊断应支持 ISO 14229-2 定义的会话层服务。 |
|---|---|
| 理由 | 符合 OSI 的网络适配。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 在异构网络系统中组织诊断通信（例如保活逻辑）。 |
| 支撑材料 | - |
存储器溢出指示
| 描述 | 对于每个事件存储器，应指示相关的事件存储器（例如主存储器和用户自定义存储器）是否已满且下一个待存储的事件将无法存入该事件存储器。 |
|---|---|
| 理由 | 事件存储器溢出已发生的信息对故障分析非常重要。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | * 触发进一步的内部行为（例如置换策略） * 将该信息链接到一个专门的扩展数据记录 * 供应商特定的 UDS 服务 |
| 支撑材料 | - |
可选地支持事件置换
| 描述 | AUTOSAR 诊断应可选地支持事件置换。以下不同置换标准的顺序是可能的：1. 优先级；2. 活动/被动状态（可选）；3. 出现次数。 |
|---|---|
| 理由 | ECU 中有限的硬件（存储器资源）。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 错误存储器已满且一个有效事件被报告给 AUTOSAR 诊断。 |
| 支撑材料 | - |
支持预定义的 AddressAndLengthFormatIdentifier
| 描述 | AUTOSAR 诊断应为 UDS 服务 0x23（ReadMemoryByAddress）、UDS 服务 0x2C（DynamicallyDefineDataIdentifier（仅 CP），子服务 DefineByMemoryAddress）、UDS 服务 0x3D（WriteMemoryByAddress）、UDS 服务 0x34（RequestDownload）和 UDS 服务 0x35（RequestUpload）支持一个预定义的 AddressAndLengthFormatIdentifier。 |
|---|---|
| 理由 | AddressAndLengthFormatIdentifier 定义一次，之后在相应的 UDS 服务中使用。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | AddressAndLengthFormatIdentifier 的静态配置。 |
| 支撑材料 | ISO 14229-1 v.2013 |
将当前去抖计数器值非易失性地存储以跨越断电周期
| 描述 | AUTOSAR 诊断应能够将当前去抖计数器值非易失性地存储，以跨越断电周期。 |
|---|---|
| 理由 | 支持跨越多个电源周期的 DTC 去抖。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 虽然典型的 DTC 运行循环是从上电开始到断电结束，但也存在特定的 DTC 必须将其运行循环定义为跨越多个 ECU 上电/断电周期的情形。在这种情形下，FDC 需要被存储到 NVM 中，因为它可能在单个上电周期内永远达不到 127。 |
| 支撑材料 | - |
向应用通知使能条件的变化
| 描述 | 当被分配给事件的使能条件的状态发生变化时，应通知相关的监控应用。 |
|---|---|
| 理由 | 让应用知道当前读取的事件状态是否为当前值，以及事件报告是否未被禁用的事件处理所阻塞。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 事件处理被禁用，例如针对某些监控器。关于当前被分配的使能条件的信息对于评估当前事件状态处理是否被禁用以及事件报告是否被阻塞至关重要。 |
| 支撑材料 | - |
支持 Transmit Certificate
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1:2020 服务 0x29 "Authentication" 的子功能 "TransmitCertificate"，它允许客户端针对不同的用例向服务器写入证书。其中一些用例可以在 AUTOSAR 模块内部直接处理，而另一些则需要在应用范围内实现。 |
|---|---|
| 理由 | 将证书上传到服务器的可能性。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 用例有： * 安全变体编码 * 安全时间更新 |
| 支撑材料 | - |
支持安全数据编码
| 描述 | AUTOSAR 诊断应支持经认证数据的安全编码。一份由制造商签名、包含公钥的证书，后接一个或多个写数据请求，可确保数据的完整性。只有与证书内的签名相匹配的数据才被接受。 |
|---|---|
| 理由 | 安全编码数据已在几乎所有 ECU 中使用，AUTOSAR 应提供一种保护和认证数据写入的标准化机制。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 通过诊断存储经认证的变体编码或其他参数。 |
| 支撑材料 | 概念 646 'Security Extensions Harmonized' - ISO 14229-1 - Authentication Service 0x29 |
按照 ISO 的伪并行客户端交互
| 描述 | AUTOSAR 诊断应支持 ISO 规定的并行性，即伪并行概念，其定义见 ISO 14229-1 图 J.2。 |
|---|---|
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 支持这样的场景：只有处于默认会话时才允许并行使用测试仪。 |
| 支撑材料 | ISO 14229-1 |
4.2. 经典平台的诊断需求¶
4.2.1. 功能需求¶
DEM 模块应支持 SAE J1939 规定的 DTC
| 描述 | DEM 模块应支持 SAE J1939-73 规定的 DTC。 |
|---|---|
| 理由 | 支持 SAE J1939-73。 |
| 用例 | 重型车辆（HDV）、HD-OBD 中的诊断。 |
| 适用平台 | CP |
| 依赖项 | DEM、J1939DCM |
| 支撑材料 | - |
支持 UDS 服务 0x19 的子功能 0x42
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x19 的子功能 0x42，以检索与所请求的 DTC 状态掩码和严重性掩码记录相匹配的 WWH-OBD 特定 DTC。 |
|---|---|
| 理由 | 支持 WWH-OBD。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 改进故障和事件的跟踪与分析。 |
| 支撑材料 | 支持 WWH-OBD。 |
提供 OBD 特定的配置能力
| 描述 | AUTOSAR 诊断应提供以下配置能力： * OBD- ECU 类型 1：ECU 充当 OBD 主 ECU（Master 或 Primary ECU） * OBD- ECU 类型 2：ECU 充当 OBD 从 ECU（Dependent / Secondary ECU） * OBD- ECU 类型 3：ECU 充当非 OBD ECU AUTOSAR 诊断应提供相应的配置参数以开启/关闭模块特定的 OBD 功能。根据所配置的用例，应提供相应的应用接口，以便在应用层面（通过总线通信）连接不同的 OBD-ECU 类型。 |
|---|---|
| 理由 | 用例特定的模块配置。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 优化 RAM/ROM 消耗。 |
| 支撑材料 | - |
OBD 与 UDS 的并行处理
| 描述 | 诊断应支持 OBD 与 UDS 协议的并行处理。 |
|---|---|
| 理由 | 车辆可能装备有在任何任意时间点发送诊断请求的车载测试仪。法规 OBD 请求需要独立于来自车载测试仪的 UDS 请求而被处理。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 来自多个测试仪的诊断请求的并行接收。 |
| 支撑材料 | - |
提供对 ASMIP 算法的支持
| 描述 | AUTOSAR 诊断应按照加利福尼亚州法规 13 CCR 第 1968.2 节考虑 ASMIP 算法（Alternative Statistical MIL Illumination Protocol）。 |
|---|---|
| 理由 | 支持 OBD 用例。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 动态阈值修改。 |
| 支撑材料 | - |
支持 UDS 服务 0x29（Authentication）
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1:2020 服务 0x29 Authentication 的子功能「Authentication with PKI Certificate Exchange（APCE）」，以授予对诊断服务的访问权。该服务应作为内部服务（在 BSW 中）实现，而无需通过中间件与应用交互。 |
|---|---|
| 理由 | 认证服务提供了一种标准化的方式来认证测试仪和 ECU，并根据证书内容授予对诊断服务的访问权。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 维修车间诊断测试仪与一台 ECU 认证，以获得对明确允许维修车间执行的诊断服务的访问。 |
| 支撑材料 | 概念 636 "Security Extensions" - C5，ISO 14229-1:2020 Authentication Service 0x29 |
4.2.2. 故障存储器管理¶
诊断事件（故障）管理应被建立为基础软件模块
| 描述 | 诊断事件（错误）管理应是诊断工作包中描述的一个基础软件模块。诊断事件（错误）管理不属于模式管理的范围。 |
|---|---|
| 理由 | 软件架构。 |
| 用例 | 为售后服务、装配线、OBD-SCAN-Tool 改进故障和事件的跟踪与分析。 |
| 适用平台 | CP |
| 依赖项 | - |
| 支撑材料 | - |
面向量产、OBD 和专家用途的事件分类
| 描述 | AUTOSAR 诊断应支持以下类型事件的分类： * 为维修站的错误分析定义的事件应存储在主事件存储器中。 * 为售后部门的专家详细错误分析定义的事件存储在次级错误存储器中。开发过程中出现的错误应报告给调试模块。为此，应使用调试模块 API（它们不由 AUTOSAR 诊断提供）。 |
|---|---|
| 理由 | 售后分析。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 区分维修站相关事件与售后相关事件。 |
| 支撑材料 | - |
统一的驾驶/暖机循环
| 描述 | AUTOSAR 诊断应支持统一的驾驶/暖机循环。驾驶/暖机循环的计算基于法规要求。 |
|---|---|
| 理由 | OBD 认证要求在集中式 OBD 主 ECU 中基于统一的驾驶/暖机循环进行车辆一致的计算。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | OBD 相关 DTC 的判定。 |
| 支撑材料 | - |
事件的可配置抑制
| 描述 | AUTOSAR 诊断应为每个事件提供下线后/可加载的布尔配置选项。如果该配置被设置为 true，则该事件的行为与通过 API 调用抑制它的行为相同。通过配置抑制的事件无法通过 API 调用激活。 |
|---|---|
| 理由 | 故障存储器的用例特定配置，只有需要的事件在 ECU 中可见和可用。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 变体编码。 |
| 支撑材料 | - |
SAE J1939 灯状态
| 描述 | 应支持以下灯的组合灯状态和 DTC 特定灯状态：故障指示灯（Malfunction Indicator Lamp）、红色停车灯（Red Stop Lamp）、琥珀色警告灯（Amber Warning Lamp）和保护灯（Protect Lamp）。 |
|---|---|
| 理由 | 支持 SAE J1939-73。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 重型车辆（HDV）、HD-OBD 中的诊断。 |
| 支撑材料 | - |
SAE J1939 扩展冻结帧
| 描述 | 应支持以下灯的组合灯状态和 DTC 特定灯状态：故障指示灯（Malfunction Indicator Lamp）、红色停车灯（Red Stop Lamp）、琥珀色警告灯（Amber Warning Lamp）和保护灯（Protect Lamp）。 |
|---|---|
| 理由 | 支持 SAE J1939-73。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 重型车辆（HDV）、HD-OBD 中的诊断。 |
| 支撑材料 | - |
支持一组 SAE J1939 DM 消息
| 描述 | 应支持以下 DM 消息（名称 / 描述）： * DM01 — 活动诊断故障码 * DM02 — 先前活动的诊断故障码 * DM03 — 针对先前活动 DTC 的诊断数据清除/复位 * DM04 — 冻结帧参数 * DM05 — 诊断就绪 1 * DM06 — 排放相关待定 DTC * DM11 — 针对活动 DTC 的诊断数据清除/复位 * DM12 — 排放相关活动 DTC * DM13 — 停止启动广播 * DM19 — 标定信息 * DM20 — 监控性能比（SAE J1939-73 Revised SEP2006） * DM21 — 诊断就绪 2 * DM23 — 先前活动的排放相关故障 * DM24 — SPN 支持 * DM25 — 扩展冻结帧 * DM26 — 诊断就绪 3 * DM28 — 永久 DTC * DM29 — 受管 DTC 计数（Pending、Permanent、MIL-On、PMIL-On） * DM31 — DTC 与灯的关联 * DM35 — 立即故障状态 * DM53 — 仅活动服务 DTC * DM54 — 先前活动的仅服务 DTC * DM55 — 所有仅服务 DTC 的诊断数据清除/复位 |
|---|---|
| 理由 | 支持 SAE J1939-73。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 重型车辆（HDV）、HD-OBD 中的诊断。 |
| 支撑材料 | - |
支持未列出的 SAE J1939 DM 消息
| 描述 | 未在 RS_Diag_04113 中列出的所有 DM 消息应由一个通用服务支持。 |
|---|---|
| 理由 | 应用应能够处理不由诊断模块的实现直接处理的 DM 消息。 |
| 适用平台 | CP |
| 依赖项 | RS_Diag_04113 |
| 用例 | 存储器访问或例程控制的处理。 |
| 支撑材料 | SAE J1939-73+ |
替代失效的定义
| 描述 | 在通过中央条件（存储条件）过滤失效报告的存储时，应可以定义并存储一个替代失效信息，随后可将其存储到事件存储器中。该替代失效将表示实际的失效原因。 |
|---|---|
| 理由 | 改进失效分析。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | -。 |
| 支撑材料 | - |
向应用和 BSW 模块通知事件相关数据的更新
| 描述 | AUTOSAR 诊断应向其他应用/ BSW 模块通知事件存储器中事件相关数据的更新。 |
|---|---|
| 理由 | 事件相关数据的变更在评估从监控应用传入的事件信息时在内部完成。对事件相关数据变化感兴趣的第三方需要得到通知。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 允许 OEM 特定的对事件相关数据更新的反应。 |
| 支撑材料 | - |
将与特定故障事件/DTC 相关的灯状态（以 DemInternalDataClass 提供）按照 DM31 的相同格式编码
| 描述 | 当一个故障事件存储器条目产生时，相关的冻结帧包括相关 DTC 的灯状态以及每种灯的 SPN 编号。事实上，该数据的格式也应符合 DM31 的内容，使用相同的编码/格式和 SPN 标识。换言之，该方案确保用户能够检索相关的灯状态，因为它已成为一个存储器条目，即使 DM31 请求没有在同一时刻完成。 |
|---|---|
| 理由 | 售后分析。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 向诊断测试仪提供每个 DTC 的灯状态。 |
| 支撑材料 | - |
报告主事件时触发多个事件
| 描述 | AUTOSAR 诊断应提供在一个事件被报告时触发多个事件的能力。 |
|---|---|
| 理由 | 从一个唯一的故障源应能导出多个事件，每个导出的事件可以触发自己的 DTC 和事件存储器条目。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 在不更改和重新编译报告软件的情况下，将来自一个唯一源的 DTC 存储到不同的故障存储器中。给定的软件可以报告事件状态信息，并且根据配置，可以将多个 DTC 和事件相关数据存储到不同的故障存储器中。 |
| 支撑材料 | - |
在事件状态变化时通知功能禁止管理器（FIM）以便其按照软件组件依赖关系处理
| 描述 | 基于以下禁止条件对软件组件的功能进行控制（启用/禁用）： - 故障 |
|---|---|
| 理由 | 用于功能禁止的事件状态信息。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 将事件状态信息用于功能禁止。 |
| 支撑材料 | - |
In-Use-Monitor 性能比表示 OBD 系统监控特定组件的频率与车辆运行量的对比
| 描述 | AUTOSAR 诊断应提供一种手段来表示 OBD 系统监控特定组件的频率与车辆运行量的对比。这通过 In-Use-Monitor Performance Ratio（IUMPR）完成。它定义为可能发现故障的次数（=分子）除以车辆运行条件被满足的次数（=分母），如相应 OBD 法规所定义。 |
|---|---|
| 理由 | 支持 OBD 用例。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 为法规要求计算 IUMPR。 |
| 支撑材料 | - |
支持快照记录数据预存储
| 描述 | AUTOSAR 诊断应向应用提供立即触发采集快照记录数据的手段。所采集的数据应在稍后的时间点触发条件满足时被存储到快照记录中。 |
|---|---|
| 理由 | 快照记录数据总是携带触发发生那一刻的数据值，这可能太晚，因为环境数据自首次故障出现以来已经发生了变化。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 在故障第一次发生时采集快照记录数据。 |
| 支撑材料 | - |
支持 UDS 服务 0x19 的子功能 0x1A 和 0x56
| 描述 | AUTOSAR 诊断应支持 UDS 服务 0x19 的子功能 0x1A 和 0x56，以检索排放相关 DTC 的信息和受支持的 ECU 数据。 |
|---|---|
| 理由 | 满足 SAE J1979-2 和增强诊断所必需。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 支持法规诊断需求和增强诊断支持。 |
| 支撑材料 | - |
支持 SAE J1979-2
| 描述 | AUTOSAR 应支持按照 SAE J1979-2 的 OBD 服务。 |
|---|---|
| 理由 | 法规要求车辆制造商通过诊断报告排放相关信息。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 使用 AUTOSAR 开发排放相关的 ECU。 |
| 支撑材料 | - |
基于 J1979-2 的 UDS 与 OBD 的分离 DTC
| 描述 | 基于 SAE J1979-2 的 UDS 通信应报告与基于非 J1979-2 的 UDS 通信不同的 3 字节 DTC 编号。 |
|---|---|
| 理由 | 需要另一组 3 字节 DTC，以避免与 UDS 增强诊断冲突。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 一些制造商不希望完全转向带 UDS 的 SAE J1979-2 支持，而只在 J1979-2 定义的受限 UDS 子集上支持 J1979-2 功能。 |
| 支撑材料 | - |
独立的 CP 软件集群开发
| 描述 | AUTOSAR 诊断应支持在应用软件集群中灵活地实现诊断能力。因此，适用于应用软件集群的广泛使用的接口应避免预编译期可配置性。适应应用相关行为的配置参数应为下线后（post-build）可配置。广泛使用的接口涉及： * UDS 服务 - 0x22 ReadDataByIdentifier - 0x24 ReadScalingDataByIdentifier - 0x2E WriteDataByIdentifier - 0x2F InputOutputControlByIdentifier - 0x31 RoutineControl * OBD 服务 - $01 Request Current Powertrain Diagnostic Data - $09 Request Vehicle Information * 诊断监控器 |
|---|---|
| 理由 | -。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 在不重建宿主软件集群的情况下变更应用软件集群中与诊断相关的功能。 |
| 支撑材料 | - |
4.2.2.1. DTC 与事件相关数据¶
并行故障存储器访问
| 描述 | AUTOSAR 诊断应向多个客户端提供对故障存储器的并行访问。每个客户端应能够独立于其他客户端访问故障存储器。并行访问共享资源期间发生的冲突应被解决。 |
|---|---|
| 理由 | OEM 要求对诊断的并行访问。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | * OBD 与 UDS 的并行支持 * 与 OBD 中的二级 ECU 交互的软件 * 访问事件存储器数据的软件组件 |
| 支撑材料 | - |
为多个诊断服务器实例（虚拟 ECU）提供独立的事件存储器
| 描述 | AUTOSAR 诊断应提供多组相互独立的事件存储器，它们可以彼此独立地存储信息。 |
|---|---|
| 理由 | 将故障存储器单独分配给专门的诊断服务器。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 共同的故障需要存储在每个虚拟 ECU 中，且故障条目的清除对存储在其他虚拟 ECU 中的信息没有或几乎没有副作用。该用例假定存储存储器条目的代价是可以接受的，因为共享存储会带来上述副作用。 |
| 支撑材料 | - |
4.2.3. 诊断通信¶
并行处理不同的诊断会话
| 描述 | 并行处理已建立的诊断通信和一个并行的诊断访问请求。这是必要的，以便以高优先级打开一个诊断访问，并以受控的方式关闭已建立的低优先级诊断访问。 |
|---|---|
| 理由 | 以区分不同诊断协议的处理优先级，例如 OBD 与作为 UDS 的普通诊断通信。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 一个内部车辆诊断测试仪通信被 OBD 诊断访问请求中断。 |
| 支撑材料 | - |
不同的诊断地址应由多个（物理）通道支持
| 描述 | 现代 ECU 包含多于一个的功能（例如车载计算机、仪表盘）。每个功能应能够由诊断工具以不同的诊断地址寻址。这并不意味着这些多个请求被允许并行处理。 |
|---|---|
| 理由 | 面向应用寻址的高灵活性和粒度。 |
| 适用平台 | CP |
| 依赖项 | RS_Diag_04021（切换诊断通信访问） |
| 用例 | 在服务站（车间），故障症状基于某个功能。服务只想寻址该功能。 |
| 支撑材料 | - |
在外部扫描工具请求时访问并处理特定的数据元素和数据元素组
| 描述 | AUTOSAR 诊断应为应用提供访问诊断数据和处理诊断服务的接口。诊断数据元素的大小由接口导出，或作为 API 调用本身的属性提供。 |
|---|---|
| 理由 | 优化资源的使用。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 传输 AUTOSAR 诊断的环境/冻结帧数据。 |
| 支撑材料 | - |
在向应用发送诊断响应之后提供确认
| 描述 | AUTOSAR 诊断应向应用通知诊断响应发送的成功或失败。 |
|---|---|
| 理由 | 为应用提供获得传输结果通知的手段。某些操作应只在传输之后启动。没有该通知，应用将不知道何时启动一个依赖于先前传输的操作。服务响应确认由 ISO 14229-1 v.2013 定义。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 例如复位功能。只有当肯定响应已在总线上发出后，ECU 才应复位。 |
| 支撑材料 | ISO 14229-1 v.2013 |
按照 ISO 14229-1 提供服务 DynamicallyDefineDataIdentifier 的处理
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 v.2013 提供服务 DynamicallyDefineDataIdentifier 的处理。 |
|---|---|
| 理由 | 标准化的 ISO 14229-1 v.2013 行为。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | -。 |
| 支撑材料 | ISO 14229-1 v.2013 |
支持通用连接
| 描述 | 诊断应支持通用连接。寻址信息此时使用元数据（MetaData）。 |
|---|---|
| 理由 | 通过各层优化通道和连接配置。 |
| 适用平台 | CP |
| 依赖项 | 按照 ISO 15765-2 使用正常固定或混合 29 位寻址格式的 CAN 诊断支持通用连接。根据 CAN ID 的实际布局，通用连接也可用于扩展或正常及混合 11 位寻址格式。 |
| 用例 | 由于车辆或 ECU 状态/条件而限制请求的执行。 |
| 支撑材料 | - |
向应用提供诊断状态信息
| 描述 | 应用需要了解实际的会话和安全状态，因为无法预测这些信息是否会导致不同的功能诊断行为。 |
|---|---|
| 理由 | 功能需求。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 在车间使用的诊断会话中，允许在不同的参数集之间切换。在可用于开发的增强型诊断会话及相应的安全级别下，允许更改参数集内的数据。 |
| 支撑材料 | - |
网络无关的设计
| 描述 | 所有网络（CAN、LIN、FlexRay、MOST、以太网）相关的部分应在 AUTOSAR 诊断之外完成。这意味着到传输协议模块的所有接口都应是网络无关的。 |
|---|---|
| 理由 | 网络的行为不在本规范的范围内。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | AUTOSAR 诊断必须与网络无关。到传输协议的接口应是网络无关的。 |
| 支撑材料 | - |
通过诊断更新常量参数
| 描述 | 几乎恒定的参数应可以通过诊断更新。对这些参数的读取和写入应避免数据的 RAM 副本。 |
|---|---|
| 理由 | 编码参数的大小正在急剧增长。当前的 FEE 概念在概念上要求数据的一个 RAM 副本。应避免这种 RAM 副本。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 编码参数。 |
| 支撑材料 | - |
支持 UDS 服务 DynamicallyDefineDataIdentifier（0x2C）的子功能 0x02（defineByMemoryAddress）
| 描述 | AUTOSAR 诊断应按照 ISO 14229-1 支持 UDS 服务 DynamicallyDefineDataIdentifier（0x2C）的子功能 0x02（defineByMemoryAddress）。 |
|---|---|
| 理由 | UDS 定义该服务以允许客户端在稍后的时间点基于已知的单个内存地址动态定义一个数据标识符。 |
| 适用平台 | CP |
| 依赖项 | - |
| 用例 | 通过 UDS 服务 0x22/0x2A，对由既有数据标识符的部分或全部内容构建的定制数据标识符执行读取操作。 |
| 支撑材料 | - |
按照 ISO 14229-2 的时序处理
| 描述 | ISO 14229-2 中描述了物理和功能通信以及错误反应的时序处理。AUTOSAR 诊断应按照该规范工作。时序参数应是可配置的（参见依赖项）。 |
|---|---|
| 理由 | 确保稳定且安全的通信链路，并保证规定的时序条件。 |
| 适用平台 | CP |
| 依赖项 | RS_Diag_04059（时序参数的配置） |
| 用例 | 在重编程期间优化时序以获得高性能。 |
| 支撑材料 | ISO 14229-2 |
4.2.4. 功能禁止管理器（FIM）¶
功能禁止管理器的软件需求规范不属于本规范的一部分。详情请参见 AUTOSAR_FIM_SRS。
4.3. 自适应平台的诊断需求¶
多个并行且被分配优先级的测试仪会话
| 描述 | AUTOSAR 诊断应总体上支持可配置数量的并行测试仪会话/连接。对于每个测试仪连接，应可配置一个优先级。该优先级被分配给测试仪地址（UDS 请求的 SA），后者标识该连接。 |
|---|---|
| 理由 | 自适应平台中的 ECU 通常拥有足够的资源来并行处理多个测试仪会话。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 支持车辆内部和外部测试仪的并行使用，它们无法被轻易同步。 |
| 支撑材料 | ISO 14229-1 |
会话抢占/中止
| 描述 | AUTOSAR 诊断应总体上支持测试仪会话的抢占：当所有已配置的测试仪连接当前都处于活动状态，并且一个新的具有比现有连接更高优先级的测试仪连接到来时，应中止最低优先级的会话并接受新的连接/会话。 |
|---|---|
| 理由 | 一台 ECU 用于并行处理诊断请求的资源有限，且不同的请求具有不同的优先级，因此需要中止。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 支持车辆内部和外部测试仪的并行使用，它们无法被轻易同步。 |
| 支撑材料 | ISO 14229-1 |
添加用户自定义的传输层
| 描述 | AUTOSAR 诊断应支持添加用户自定义的传输层。 |
|---|---|
| 理由 | 尽管自适应平台从以太网支持起步，但应为将来向其他网络（CAN、FlexRay）的扩展做好准备。此外，至少有一家 OEM 拥有自己的 DoIP 实现，它与 ISO 13400 不同。应以可管理的代价/成本集成该 DoIP 实现。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | UDS 传输层的可插拔性，以支持不同的网络。 |
| 支撑材料 | - |
为外部 UDS 服务处理器提供一个接口。
| 描述 | 对于所有不由 AUTOSAR 诊断在内部处理/实现（或通过配置、或通常不受内部支持），而由外部服务处理器处理的 UDS 服务，AUTOSAR 诊断必须将处理委托给外部应用。 |
|---|---|
| 理由 | 大多数诊断服务由应用实现，AUTOSAR 诊断必须将服务处理委托给它。 |
| 适用平台 | AP |
| 依赖项 | RS_Diag_04097 |
| 用例 | 由软件组件进行的服务处理。 |
| 支撑材料 | ISO 14229-1 |
向外部服务处理器提供连接特定的元信息
| 描述 | AUTOSAR 诊断应向正在处理 UDS 服务请求的外部服务处理器提供连接特定的元信息。至少应支持 DoIP，并且元信息应包含该请求的源 IP 地址/端口和目标 IP 地址/端口。元信息的设计应使其将来可以容易地扩展到也覆盖其他网络技术（如 CAN、FlexRay）的连接信息。 |
|---|---|
| 理由 | 有时服务处理器实现对某个 UDS 请求的反应取决于测试仪的连接属性。 |
| 适用平台 | AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
| 支撑材料 | - |
与外部服务处理器的同步和异步交互
| 描述 | AUTOSAR 诊断应支持两种类型的交互： * 同步调用服务处理器，即一个阻塞调用，直到服务处理器返回最终结果（肯定/否定响应、可选的输出参数）。 * 异步调用服务处理器，即调用服务处理器后，服务处理器返回任务尚未完成，并在稍后通过一个单独的回调向 AUTOSAR 诊断报告服务处理已完成。 |
|---|---|
| 理由 | 对于将处理委托给自有工作线程的长时间运行的服务处理，异步回调模型更高效，而对于简单的服务处理器，严格的同步模型更易于实现。 |
| 适用平台 | AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
| 支撑材料 | - |
将 UDS 服务的处理委托给应用时的不同签名类型
| 描述 | 在将 UDS 服务的处理委托给应用时，AUTOSAR 诊断应支持以下签名： * 非类型化接口，其中包含 SID 和子服务在内的整个载荷以字节数组的形式提供给服务处理器 * 每个 SID、子服务和数据元素的类型化接口，其中从 UDS 参数/数据流到数据类型的映射在配置中描述。 |
|---|---|
| 理由 | 根据用例/复杂度，某些方式比其他方式高效得多。另一方面，也存在这样的用例：从 UDS 数据流到接口类型的映射描述带来这样的好处，即服务处理器的映射描述可以更容易地被理解和验证。 |
| 适用平台 | AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
| 支撑材料 | - |
向外部服务处理器提供 SA 和 TA
| 描述 | AUTOSAR 诊断应向正在处理 UDS 服务请求的外部服务处理器提供源地址和目标地址。 |
|---|---|
| 理由 | 有时服务处理器实现对某个 UDS 请求的反应取决于测试仪（SA）或目标。 |
| 适用平台 | AP |
| 依赖项 | RS_Diag_04169 |
| 用例 | 服务处理器实现的灵活性。 |
| 支撑材料 | - |
支持多个诊断服务器实例
| 描述 | AUTOSAR 诊断应能够处理多个诊断服务器实例。每个诊断服务器实例应可通过其自己的目标地址集合寻址，并且它们应彼此几乎独立。像 EcuReset 这样的例外需要在服务器实例之间协调。 |
|---|---|
| 理由 | AP 上的软件被分组在所谓的软件集群（SoftwareCluster）中，每个集群应被单独诊断。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 多个软件集群部署在单个 AP 上，每个软件集群被单独诊断。 |
| 支撑材料 | - |
支持 UDS 服务 0x29（Authentication）
| 描述 | AUTOSAR 诊断应支持 ISO 14229-1:2020 服务 0x29 Authentication 的子功能「Authentication with PKI Certificate Exchange（APCE）」，以授予对诊断服务的访问权。 |
|---|---|
| 理由 | 认证服务提供了一种标准化的方式来认证测试仪和 ECU，并根据证书内容授予对诊断服务的访问权。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 维修车间诊断测试仪与一台 ECU 认证，以获得对明确允许维修车间执行的诊断服务的访问。 |
| 支撑材料 | - |
支持 SOVD
| 描述 | AUTOSAR 内的诊断应按照 ASAM 规范「SOVD - Service Oriented Vehicle Diagnostics V1.0.0」支持一个 SOVD 端点。 |
|---|---|
| 理由 | 为后端提供车辆访问。 |
| 适用平台 | AP |
| 依赖项 | ISO 14229-1 |
| 用例 | 汽车行业现代化的诊断方式。 |
| 支撑材料 | - |
能力描述
| 描述 | AUTOSAR 内的诊断应支持「用于访问能力描述内容的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | SOVD 是一个自描述的协议。 |
| 支撑材料 | - |
实体和资源的发现
| 描述 | AUTOSAR 内的诊断应支持「用于发现实体和资源的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 客户端遍历拓扑以查明哪些方法可用于哪些资源。 |
| 支撑材料 | - |
故障存储器访问
| 描述 | AUTOSAR 内的诊断应支持「用于故障处理的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 提供故障存储器数据。 |
| 支撑材料 | - |
读/写访问
| 描述 | AUTOSAR 内的诊断应支持「用于数据资源读/写访问的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 读取和写入各种类型的数据。 |
| 支撑材料 | - |
配置访问
| 描述 | AUTOSAR 内的诊断应支持「用于配置的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 组件和应用需要被配置到特定的环境中，例如车辆装备、国家、客户需求、变体编码等。 |
| 支撑材料 | - |
操作的控制
| 描述 | AUTOSAR 内的诊断应支持「用于操作控制的 API 方法」。与 SOVD 方法相关的操作能力有以下限制：由于 UDS 的 I/O 控制服务尚不受支持，自适应平台的 SOVD 服务器不支持 I/O 控制调整。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 远程过程调用和值的调整。 |
| 支撑材料 | - |
支持目标模式
| 描述 | AUTOSAR 内的诊断应支持「用于支持目标模式的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 控制和准备目标实体的状态/模式。 |
| 支撑材料 | - |
SOVD 特定的锁定/信号量机制
| 描述 | AUTOSAR 内的诊断应支持「用于锁定的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 为单个客户端获得对特定资源的独占访问。 |
| 支撑材料 | - |
软件更新
| 描述 | AUTOSAR 内的诊断应支持「用于软件更新的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的可选部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | SOVD 更新软件的方式。 |
| 支撑材料 | - |
批量数据
| 描述 | AUTOSAR 内的诊断应支持「用于处理批量数据的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的可选部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 处理较大的批量数据，例如内核转储文件。 |
| 支撑材料 | - |
日志记录
| 描述 | AUTOSAR 内的诊断应支持「用于日志记录的 API 方法」。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 日志信息的聚合。 |
| 支撑材料 | - |
身份认证
| 描述 | AUTOSAR 内的诊断应支持「SOVD 客户端的身份认证」。AUTOSAR 应强制采用基于 OAuth 的信息安全解决方案，如「SOVD 客户端的身份认证」第 6.15 章所定义。与 AUTOSAR 不同，SOVD 并不强制该解决方案，因为该章仅是资料性的。 |
|---|---|
| 理由 | SOVD 协议的基本组成部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 启用授权和验证过程，以保护车辆中任何可访问实体的资源不被滥用。 |
| 支撑材料 | - |
SOVD 到 UDS 的适配器
| 描述 | AUTOSAR 内的诊断应支持「经典诊断适配器」。 |
|---|---|
| 理由 | SOVD 协议的可选部分。 |
| 适用平台 | AP |
| 依赖项 | - |
| 用例 | 通过 SOVD 访问基于 UDS 的 ECU 的适配器。 |
| 支撑材料 | - |
5. 参考文献¶
5.1. AUTOSAR 交付物¶
- General Requirements of Basic Software Modules: AUTOSAR_SRS_BSWGeneral.pdf
- Specification of the Virtual Functional Bus: AUTOSAR_EXP_VFB.pdf
- Software Standardization Template: AUTOSAR_TPS_StandardizationTemplate.pdf
5.2. 相关标准和规范¶
5.2.1. ITEA-EAST¶
- D1.5-General Architecture; ITEAEAST-EEA, Version 1.0; chapter 3, page 72 et seq.
- D2.1-Embedded Basic Software Structure Requirements; ITEAEAST-EEA, Version 1.0 or higher
- D2.2-Description of existing solutions; ITEA/EAST-EEA, Version 1.0 or higher.
5.2.2. ISO¶
- ISO 14229-1 Unified diagnostic services (UDS) Part 1: Specification and Requirements (v.2013)
- ISO 15031-5 Communication between vehicle and external equipment for emissions related diagnostics Part 5: Emissions related diagnostic services (2005-0113)
- ISO 15765-3 Diagnostics on controller area network (CAN) Part 3: Implementation of unified diagnostic services (UDS on CAN) (2004-10-06)
- ISO 15765-4 Diagnostics on controller area network (CAN) Part 4: Requirements for emissions-related systems (2005-01-04)
A. AUTOSAR 可追溯项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的可追溯项。这些可追溯项在文档中不作为超链接出现。
A.1. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.1.1. R23-11 中新增的需求¶
表A.1：R23-11 中新增的需求
| 标题 |
|---|
| 向应用通知使能条件的变化 |
| 支持 Transmit Certificate |
| 支持安全数据编码 |
A.1.2. R23-11 中变更的需求¶
无。
A.1.3. R23-11 中删除的需求¶
无。