RS Health Monitoring
1. 文档范围¶
本文档规定健康监控（Health Monitoring）的需求。
对于本版本，本文档仅适用于自适应平台：与经典平台的对齐将在后续版本中完成。第 5 章中的「适用平台」字段应忽略。与经典平台的对齐将在后续版本中完成。
健康监控被 [1] 所要求（以控制流监控（control flow monitoring）、外部监控设施（external monitoring facility）、看门狗（watchdog）、逻辑监控（logical monitoring）、时序监控（temporal monitoring）、程序序列监控（program sequence monitoring）等术语），本规范旨在涵盖该标准中所有相关需求。
健康监控具有以下错误检测功能：
- 存活监督（Alive supervision）——检查检查点（Checkpoint）是否以正确的频率发生
- 期限监督（Deadline supervision）——检查两个检查点之间的时间差
- 逻辑监督（Logical supervision）——检查检查点的执行序列是否正确
- 健康状态监督（Health status supervision）——检查健康状态（Health Status）信息是否有效
健康监控还提供可配置的错误处理机制，以便从前述监督函数检测到的错误中恢复。
健康监督（Health Supervision）应由 AUTOSAR 经典平台和 AUTOSAR 自适应平台实现。它也可以由其他平台实现。
健康监督本身在 [2]（ASWS Health Monitoring）中规定，该文档规定了四个监督函数的实现无关行为/算法。系统健康监控允许跨多个 AP/CP 或非 AUTOSAR 平台聚合和转发健康信息。规范见 [2, ASWS Health Monitoring]，使用示例见 [3, EXP System Health Monitoring]。
2. 如何阅读本文档¶
2.1. 所用约定¶
AUTOSAR 文档中需求的表述遵循约束 TPS_STDT_00078 规定的表格，见 Standardization Template 的「Support for Traceability」章 [4]。
需求的表达应使用约束 TPS_STDT_00053 规定的义务表达动词形式，见 Standardization Template 的「Support for Traceability」章 [4]。
3. 缩略语和缩写¶
以下收录与健康监控的规范或实现相关、且未被 [5, AUTOSAR glossary] 收录的缩略语和缩写。
CM
AUTOSAR 自适应通信管理（AUTOSAR Adaptive Communication Management）
DM
AUTOSAR 自适应诊断管理（AUTOSAR Adaptive Diagnostic Management）
PHM
平台健康管理（Platform Health Management）
SE
受监督实体（Supervised Entity）
SHM
系统健康监控器（System Health Monitor）
Alive Counter
存活计数器：检查点上下文中用于跟踪和处理其存活指示（Alive Indication）数量的独立数据资源。
Alive Indication
存活指示：受监督实体通过调用用于存活监督的检查点来表明其存活的指示。
Alive Supervision
存活监督：检查周期性受监督实体的时序约束是否处于所配置的最小和最大限值内的机制。
Checkpoint
检查点：受监督实体的控制流中报告活动的一个点。
Deadline End Checkpoint
期限结束检查点：配置了期限监督、并且是特定迁移的结束点的检查点。如果期限监督串联，一个检查点可以既是期限开始检查点又是期限结束检查点。
Deadline Start Checkpoint
期限开始检查点：配置了期限监督、并且是特定迁移的起始点的检查点。
Deadline Supervision
期限监督：检查从期限开始检查点到相应期限结束检查点的迁移执行时序约束是否处于所配置的最小和最大限值内的机制。
Elementary Supervision Status
基本监督状态：基于监督的评估结果（正确/不正确）表示存活监督、期限监督或逻辑监督当前状态的状态。
Expired Supervision Cycle
过期监督周期：存活监督未能通过其两个升级步骤的监督周期（存活计数器未通过预期存活指示数量（含容差）的次数超过允许的失败参考周期数）。
Failed Supervision Reference Cycle
失败监督参考周期：以存活计数器与预期存活指示数量之间检测到的偏差（含容差）结束的监督参考周期。
Global Supervision Status
全局监督状态：累计监督状态。在经典平台中，它汇总所有受监督实体的局部监督状态。在自适应平台中，它基于单个功能组（Function Group）内的一组基本监督状态计算得出。
Graph
图：通过迁移连接的一组检查点，其中至少一个检查点是初始检查点，并且图中任意两个检查点之间存在（经由迁移的）路径。
Health Channel
健康信道：提供（子）系统健康状态信息的信道。这可以是某个应用的全局监督状态、任何测试例程的结果，或（子）系统报告的状态（例如电压监控、OS 内核、ECU 状态等）。
Health Channel Supervision
健康信道监督：检查受监督软件注册的健康指示是否处于容差/限值内的监督类型。
Health Monitoring
健康监控：针对正确时序和序列的软件行为监督。
Health Status
健康状态：与受监督软件相关的一组状态（例如应用的全局监督状态、电压状态、应用状态、RAM 监控算法的结果）。
Logical Supervision
逻辑监督：检查软件（受监督实体或受监督实体集合）是否按程序员（所开发的代码）定义的序列执行的在线监督类型。
Local Supervision Status
局部监督状态：表示单个受监督实体的存活监督、期限监督和逻辑监督当前结果的状态。
Platform Health Management
平台健康管理：自适应平台的健康监控。
Supervised Entity
受监督实体：纳入监督的软件组件类型的整体或一部分。受监督实体表示相应软件组件类型内检查点的集合。一个软件组件类型可以包含零个、一个或多个受监督实体。受监督实体可以被多次实例化，此时每个实例被独立监督。
Supervised Entity Identifier
受监督实体标识符：在某个应用内唯一标识一个受监督实体的标识符。
Supervision Counter
监督计数器：受监督实体上下文中在每个监督周期内更新的独立数据资源，存活监督算法用它执行对已计数存活指示的检查。
Supervision Cycle
监督周期：执行周期性存活监督的时间段。
Supervision Mode
监督模式：微控制器或虚拟机的整体状态，或功能组的状态（自适应平台情形）。模式互斥。模式例如可以是 Startup、Shutdown、Low-power。
Supervision Reference Cycle
监督参考周期：存活监督用作参考以执行已计数存活指示检查（对每个受监督实体单独进行）的监督周期数量。
Local Health Monitor
局部健康监控器：收集其部署平台健康信息的局部健康监控器。
4. 功能概述¶
健康监控旨在监督受监督实体的执行：涉及时序约束（存活监督和期限监督）、涉及所需的执行序列（逻辑监督）以及涉及其健康（健康监督）。
健康监控可以对受监督实体执行，受监督实体可以是任何软件组件、软件组件组或自适应应用。
监督结果以及其他监控器（例如电压监控器）的输出可用于创建健康指标（HealthIndicator），为特性或子系统给出整体健康状态。
健康监控提供以下特性：
- 对位于微处理器或虚拟机上、具有独立监督约束的多个单独受监督实体的监督。
- 支持受监督实体的并行与并发执行以及多重实例化。
- 支持不同的运行模式，软件组件的行为因模式而异。
- 支持多个硬件看门狗。
- 支持多种错误处理机制。
5. 需求规格¶
5.1. 功能需求¶
5.1.1. 监督函数¶
5.1.1.1. 健康监控应提供逻辑监督¶
| 描述 | 健康监控应检查运行时受监督实体中检查点的序列是否与所指定的相同。这应包括： * if/else 分支的开始（决策节点）：应恰好进入一个代码分支，选择取决于逻辑条件、因运行时而异 * if/else 分支的结束（合并节点）：应恰好到达一个分支以执行汇合 * 流向并发执行的分支（分支节点）：应进入所有并发分支 * 并发执行流的汇合（汇合节点）：应到达所有并发分支以执行汇合 |
|---|---|
| 理由 | 检测执行中的序列是否与所指定/所设计的相同。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 对任何软件组件的监督：应用软件组件或平台组件（例如执行管理器、状态管理器）。 |
| 支撑材料 | - |
5.1.1.2. 健康监控应提供存活监督¶
| 描述 | 健康监控应检查到达受监督实体中给定检查点的频率是否匹配规定的限值。 |
|---|---|
| 理由 | 检测周期函数是否按规范/设计周期性地执行。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 带存活监督的安全关键应用在执行期间的某个时刻卡住。HM 检测到受监督应用不再存活。 |
| 支撑材料 | - |
5.1.1.3. 健康监控应提供期限监督¶
| 描述 | 健康监控应检查两个检查点之间经过的时间是否处于规定的最小和最大限值内，包括检测第二个检查点永不到达的情形。 |
|---|---|
| 理由 | 检测超时或期限丢失。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 一个安全关键应用被开发为在规定的时间窗口内到达特定检查点，但突然不再按预期表现。PHM 检测到该违例。 |
| 支撑材料 | - |
5.1.2. 到受监督实体的接口¶
5.1.2.1. 健康监控应提供向受监督实体上报当前到达检查点的接口¶
| 描述 | 健康监控应提供向受监督实体上报当前由受监督实体到达的检查点的接口，同时考虑到给定的代码位置可以从不同的进程、线程到达，或在不同的核上执行。 |
|---|---|
| 理由 | 这是应用上报其进度的唯一方式。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 支撑材料 | - |
5.1.2.2. 健康监控应提供向受监督实体告知其监督状态的接口¶
| 描述 | 健康监控应提供告知监督状态的接口，包括： * 哪个受监督实体失败 * 每个受监督实体当前的局部监督状态 * 微控制器或虚拟机当前的全局监督状态 * 上次执行错误反应的原因 * 即将发生的微控制器或虚拟机复位 这应通过通知和轮询两种方式提供。 |
|---|---|
| 理由 | 一些应用需要知道其健康/状态。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 向受监督实体上报 OK/Failed。 |
| 支撑材料 | - |
5.1.3. 与监督函数相关的特性¶
5.1.3.1. 健康监控应支持受监督实体的模式相关行为¶
| 描述 | 健康监控应支持受监督实体的监督模式，其中 * 受监督实体在每个监督模式中可能具有不同的行为。 * 在经典平台情形下，监督模式跨所有受监督实体共享。 * 在自适应平台情形下，监督模式跨多个受监督实体实例共享。 * 监督模式被定义为扁平或分层状态机。 |
|---|---|
| 理由 | 在不同模式中，受监督实体可以有不同的行为，例如不同的执行路径、不同的时序。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 在「init」模式中，函数 init() 按与「init」模式相关的检查点监督。在「run」模式中，函数 run() 按与「run」模式相关的检查点监督。在 AP 中，监督模式从功能组状态派生。 |
| 支撑材料 | - |
5.1.3.2. 健康监控应支持运行时数量可变的受监督实体实例¶
| 描述 | 健康监控应支持运行时数量变化的受监督实体实例。 |
|---|---|
| 理由 | 活跃受监督实体实例的数量可以根据活跃模式或进程变化。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 模式或配置可以在运行时变化，相应地活跃进程和受监督实体的数量发生变化。 |
| 支撑材料 | - |
5.1.3.3. 健康监控应支持受监督实体内部和跨受监督实体的监督¶
| 描述 | 健康监控应支持单个受监督实体内部以及跨不同受监督实体的监督（逻辑、存活和期限监督）。 |
|---|---|
| 理由 | 一个应用可以包含多个受监督实体，全局监督状态由它们计算得出。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 跨多个活动的活动链，其中不同活动属于同一个或不同的进程。 |
| 支撑材料 | - |
5.1.3.4. 健康监控应支持并发和并行受监督实体的监督¶
| 描述 | 健康监控应支持以下受监督实体的监督： * 并行/并发执行 * 被其他受监督实体或任何其他软件抢占 * 在多个核或 CPU 上执行 |
|---|---|
| 理由 | 健康监控也应适用于具有并行和并发执行的系统。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 在多核处理器上并行执行的系统。 |
| 支撑材料 | - |
5.1.3.5. 健康监控应为检测到的错误提供可配置的容差，并为错误反应提供可配置的延迟¶
| 描述 | 健康监控应为检测到的错误提供可配置的容差。 |
|---|---|
| 理由 | 在存活监督的情形下，单个失败无需触发错误反应。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 支撑材料 | - |
5.1.4. 与看门狗支持相关的特性¶
本节规定看门狗支持的需求。看门狗通常是一个简单的硬件实体，它在规定的时间段内期望某种简单的特定信息。它也可以由更复杂的系统实现，例如由另一个微控制器实现。
5.1.4.1. 健康监控应支持超时看门狗¶
| 描述 | 健康监控应支持简单的超时看门狗，即要求在规定的超时时间内写入特定值的一个或多个看门狗。 |
|---|---|
| 理由 | 此类硬件看门狗广泛可用。此外，还存在应用多个看门狗作为冗余措施的系统（带一个简单超时看门狗和一个复杂问答看门狗）。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 支撑材料 | - |
5.1.4.2. 健康监控应支持窗口看门狗¶
| 描述 | 健康监控应支持窗口看门狗，即看门狗要求在规定的最小/最大时间窗口内写入正确的值。 |
|---|---|
| 理由 | 窗口看门狗在汽车系统中广泛使用。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 使用窗口看门狗的系统 |
| 支撑材料 | - |
5.1.4.3. 健康监控应支持问答看门狗¶
| 描述 | 健康监控应支持问答看门狗，即提供给看门狗的响应取决于来自看门狗的问题以及当前的健康监控结果。 |
|---|---|
| 理由 | 使用带此类看门狗的系统。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 问答看门狗提供一个随机值作为问题，该值用作健康监控的种子。监督的结果——签名——作为答案返回给外部看门狗。只有当答案按时发送并与期望的响应匹配时，外部看门狗才被正确服务并发出下一个问题。 |
| 支撑材料 | - |
5.1.4.4. 健康监控应支持硬件看门狗的模式¶
| 描述 | 健康监控应支持硬件看门狗模式，其中硬件看门狗模式指已定义的硬件选项集合，例如当前超时值。 |
|---|---|
| 理由 | 看门狗可以提供诸如 normal、low、off、sleep 等模式。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 支撑材料 | - |
5.1.4.5. 健康监控应支持不同的看门狗实现¶
| 描述 | 健康监控应支持不同的看门狗实现，包括但不限于： * 内部硬件看门狗（在微控制器中） * 外部硬件看门狗 * 单独的专用芯片（ASIC） * 单独微控制器上的一个应用 |
|---|---|
| 理由 | 不同的看门狗实现已经存在于市场上。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | - |
| 支撑材料 | - |
5.1.4.6. 健康监控应支持多个看门狗¶
| 描述 | 健康监控应支持多个看门狗，它们类型相同或不同，配置相同或不同。 |
|---|---|
| 理由 | 有些微处理器同时包含内部和外部看门狗用于监控，作为冗余机制。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 如果内部看门狗与 CPU 使用相同的时钟，那么由于使用相同的时钟，内部看门狗无法识别系统的「挂起」。为获得更高的鲁棒性，还需使用外部看门狗。 |
| 支撑材料 | - |
5.1.5. 支持的错误处理机制¶
5.1.5.1. 健康监控应能够上报监督错误¶
| 描述 | 作为可能的错误反应，健康监控应上报监督错误，提供检测到何种错误的信息。 |
|---|---|
| 理由 | 需要上报错误，以便对其进行记录和分析，或以便进行集中式错误反应。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 上报某个受监督实体违反了其存活监督但仍在限值内。上报整个微控制器处于需要复位的糟糕状态。由其他方处理健康监控上报的错误。 |
| 支撑材料 | - |
5.1.5.2. 健康监控应能够错误地触发受服务的看门狗¶
| 描述 | 作为可能的错误反应，健康监控应能够错误地触发受服务的看门狗。 |
|---|---|
| 理由 | 为了提供微处理器的快速复位。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 微处理器。典型的看门狗错误触发包括： * 立即生成对问题的答案（问答看门狗情形） * 立即生成对看门狗的错误触发/通知（超时看门狗和窗口看门狗） * 不生成答案（超时看门狗和窗口看门狗） |
| 支撑材料 | - |
5.1.5.3. 健康监控应能够触发微控制器复位¶
| 描述 | 作为可能的错误反应，健康监控应触发微控制器复位，包括但不限于： * 干净的微控制器复位（例如关闭所有服务、关闭套接字） * 快速微控制器复位 |
|---|---|
| 理由 | 除错误触发看门狗外，这是健康监控可用于从故障系统状态恢复的第二种主要反应。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 健康管理器请求机器状态管理器执行复位。 |
| 支撑材料 | - |
5.1.6. 与系统健康监控相关的特性¶
5.1.6.1. 系统健康监控器应将健康指标作为标准化服务事件传输¶
| 描述 | 健康指标的传输应以标准化的方式、作为标准化服务事件的一部分完成。 |
|---|---|
| 理由 | 健康指标应以平台无关的标准化方式、作为服务/子系统的健康度提供给其他模块/平台，以便它们在平台级用于错误恢复/降级。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 例如特性 HAD 分布在多个平台（AP、CP 和非 AUTOSAR）上。SHM 确定健康指标，并经由标准化的健康指标事件将其传输给使用特性 HAD 的组件。 |
| 支撑材料 |
5.1.6.2. SHM 应从局部健康监控器接收相关健康信息¶
| 描述 | SHM 应提供一个接口，通过各种通信机制接收健康指标和健康信息。 |
|---|---|
| 理由 | 接收到的信息用于确定系统级健康指标，SHM 需要支持信息接收。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 特性 HAD 分布在多个平台（AP、CP 和非 AUTOSAR）上。SHM 需要这些平台的健康信息用于健康指标确定。健康信息例如可以包括由平台健康管理确定的监督状态。 |
| 支撑材料 |
5.1.6.3. SHM 与局部健康监控器之间的通信应受 E2E 保护¶
| 描述 | SHM 与局部健康监控器之间的通信应受 E2E 保护，从而是可靠的。 |
|---|---|
| 理由 | 交换的数据将用于安全关键决策，应受到保护以免受通信错误影响。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 健康信息的不可靠传输可能触发不必要的降级策略。 |
| 支撑材料 |
5.1.6.4. SHM 实例之间的通信应受 E2E 保护¶
| 描述 | SHM 实例之间的通信应受 E2E 保护，从而是可靠的。 |
|---|---|
| 理由 | 交换的数据将用于安全关键决策，应受到保护以免受通信错误影响。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 健康信息的不可靠传输可能触发不必要的降级策略。 |
| 支撑材料 |
5.1.6.5. SHM 与局部健康监控器之间的周期性通信应用于存活检查¶
| 描述 | 局部健康监控器与 SHM 之间的周期性交换对于存活判定是必要的。 |
|---|---|
| 理由 | 检测失效的平台或 SHM 实例很重要。如果通信配置有固定的周期时间，接收方可以通过将定期交换的健康信息用作心跳信号来检测失效的发送方。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | |
| 支撑材料 |
5.1.6.6. SHM 实例之间的周期性通信应用于存活检查¶
| 描述 | SHM 实例之间的周期性交换对于存活判定是必要的。 |
|---|---|
| 理由 | 检测失效的平台或 SHM 实例很重要。如果通信配置有固定的周期时间，接收方可以通过将定期交换的健康信息用作心跳信号来检测失效的发送方。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | |
| 支撑材料 |
5.1.6.7. SHM 应与平台无关¶
| 描述 | SHM 应可实现在 AP、CP 和非 AUTOSAR 平台上。 |
|---|---|
| 理由 | SHM 的集成是项目特定的，应提供关于在哪里部署 SHM 的最大灵活性，因为不同的安全考虑（例如 ASIL 等级）可能影响该决策。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 多个 SHM 实例部署在 E/E 系统中。根据安全需要（ASIL 等级），它们可以部署在 CP、AP 和非 AUTOSAR 平台上。 |
| 支撑材料 |
5.1.6.8. SHM 应确定健康指标¶
| 描述 | SHM 应确定健康指标，即描述是否满足系统标称性能以及系统降级是否可能的指标。 |
|---|---|
| 理由 | 系统级健康指标是降级失效（fail-degraded）系统所需要的。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 自动驾驶系统具有冗余信道。健康指标可由平台用于在一条信道失效时通过激活冗余信道作出反应。 |
| 支撑材料 |
5.1.6.9. SHM 应支持冗余概念¶
| 描述 | SHM 应以冗余机制实现。 |
|---|---|
| 理由 | 对于高度安全关键的功能，SHM 是单一故障点，因此应以冗余方式实现。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 用于失效可运行（fail-operational）行为的多个 SHM 实例 |
| 支撑材料 |
5.1.6.10. SHM 应能够与非 AUTOSAR 软件平台交互¶
| 描述 | 需要与非 AUTOSAR 平台交换信息，以接收和提供健康指标。 |
|---|---|
| 理由 | 从系统健康的角度来看，没有理由将其仅限制于 AUTOSAR 平台，纳入例如来自 GENIVI 平台的健康信息可能是安全相关的。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 自动驾驶系统使用非 AUTOSAR 平台实现从 L3 切换到 L2 功能的用户反馈。用户反馈是安全相关的，是系统健康分析所需要的。 |
| 支撑材料 |
5.1.6.11. SHM 应可在抽象平台描述信息内配置¶
| 描述 | SHM 可以使用抽象平台描述（Abstract Platform Description）提供的抽象接口描述。 |
|---|---|
| 理由 | 使用 SHM 的抽象描述是用 AP 和 CP 对平台无关行为建模的好方法。 |
| 依赖项 | - |
| 适用平台 | FO、CP、AP |
| 用例 | 使用不同平台的 E/E 系统。 |
| 支撑材料 |
5.2. 非功能需求¶
5.2.1. 健康监控应支持构建安全相关系统¶
| 描述 | 健康监控应支持构建符合 ISO 26262 的安全相关系统。 |
|---|---|
| 理由 | 健康监控不应阻碍而应促进符合 ISO 26262 的安全系统的实现。 |
| 依赖项 | - |
| 适用平台 | CP、AP |
| 用例 | 构建驾驶辅助系统。 |
| 支撑材料 | [1, ISO 26262] |
6. 参考文献¶
[1] ISO 26262:2018（所有部分）——道路车辆——功能安全
https://www.iso.org
[2] Specification of Health Monitoring
AUTOSAR_FO_ASWS_HealthMonitoring
[3] Explanation of System Health Monitoring
AUTOSAR_FO_EXP_SystemHealthMonitoring
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
AUTOSAR_FO_RS_Main
A. 约束与规范项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的约束和规范项。这些约束和规范项在文档中不作为超链接出现。
A.1. 本文档依据 AUTOSAR 版本 R23-11 的变更历史¶
A.1.1. R23-11 中新增的需求¶
无
A.1.2. R23-11 中变更的需求¶
无
A.1.3. R23-11 中删除的需求¶
无
A.1.4. R23-11 中新增的约束¶
无
A.1.5. R23-11 中变更的约束¶
无
A.1.6. R23-11 中删除的约束¶
无
A.2. 本文档依据 AUTOSAR 版本 R22-11 的变更历史¶
A.2.1. R22-11 中新增的需求¶
无
A.2.2. R22-11 中变更的需求¶
表A.1：R22-11 中变更的需求
| 标题 |
|---|
| 健康监控应提供存活监督 |
| 健康监控应能够触发微控制器复位 |
| 健康监控应提供逻辑监督 |
| 健康监控应能够错误地触发受服务的看门狗 |
| 健康监控应提供期限监督 |
| 健康监控应支持构建安全相关系统 |
| 系统健康监控器应将健康指标作为标准化服务事件传输 |
| SHM 应与平台无关 |
A.2.3. R22-11 中删除的需求¶
无
A.2.4. R22-11 中新增的约束¶
无
A.2.5. R22-11 中变更的约束¶
无
A.2.6. R22-11 中删除的约束¶
无