Safety
1. 文档范围¶
本文档基于通过 AUTOSAR_FO_RS_Main [1] 提供的项目目标和高层安全需求，规定对 AUTOSAR 平台的安全需求。它使用了以下文档中所描述的预期功能：
- AUTOSAR_AP_EXP_PlatformDesign [2]
- AUTOSAR_CP_EXP_LayeredSoftwareArchitecture [3]
- AUTOSAR_AP_EXP_SWArchitecture [4]。
功能安全需求由 AUTOSAR_EXP_SafetyOverview [5] 中提到的顶层安全需求和危害导出。
本文档包含对 AUTOSAR 功能集群、服务和 AUTOSAR 基础软件模块的技术安全需求视图。这些需求从各自的目标需求规范中提取并包含在本文档中，以便读者在一篇文档中获得完整概览。
无 ASIL 等级¶
AUTOSAR 联盟，特别是 AUTOSAR 自适应平台工作组，仅提供架构定义、功能块描述和概念验证实现，因此如 ISO 26262 [6] 中所述，无法为该范围内的任何需求添加 ASIL 等级。
2. 如何阅读本文档¶
本文档包含通用的功能安全需求，不提及 AUTOSAR 的具体解决方案/组件。技术安全需求随后从功能安全需求导出，并指明 AUTOSAR 组件的具体职责。每条需求都有其唯一标识符，以前缀 RS_SAF_（表示 "Safety Requirement"）开头。
技术安全需求部分提取自各目标组件需求规范，因此不带 RS_SAF_ 前缀。并非所有技术需求都已完成整合，目标是让所有技术需求成为目标需求规范的一部分，此处收录它们只是为了形成一个完整的安全需求目录。
2.1. 文档约定¶
AUTOSAR 文档中需求的呈现遵循 TPS_STDT_00078 中规定的表格，参见标准化模板（Standardization Template）的「可追溯性支持（Support for Traceability）」章节（[7]）。
应使用 TPS_STDT_00053 中规定的表达义务的言语形式来表示需求，参见标准化模板的「可追溯性支持」章节（[7]）。
2.2. 所用约定¶
本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按如下方式解释。
请注意，使用这些词语的文档的需求层级会修饰这些词语的强制力。
- MUST：该词或形容词 "LEGALLY REQUIRED" 表示，由于法律问题，该定义是规范中的绝对要求。
- MUST NOT：该短语表示，由于法律问题，该定义是规范中的绝对禁止。
- SHALL：该短语或形容词 "REQUIRED" 表示，该定义是规范中的绝对要求。
- SHALL NOT：该短语表示，该定义是规范中的绝对禁止。
- SHOULD：该词或形容词 "RECOMMENDED" 表示，在特定情形下可能存在充分理由忽略某一事项，但在选择不同做法之前必须理解并仔细权衡其全部影响。
- SHOULD NOT：该短语或短语 "NOT RECOMMENDED" 表示，在特定情形下，某种特定行为是可接受的甚至有用的，但在实现以此标签描述的任何行为之前，应理解其全部影响并仔细权衡具体情况。
- MAY：该词或形容词 "OPTIONAL" 表示，某一事项是真正可选的。一个供应商可以选择包含该事项，因为特定市场需要它，或者因为该供应商认为它能增强产品；而另一个供应商可以省略同一事项。
不包含某一特定选项的实现，应准备好与包含该选项的另一实现互操作（尽管功能可能有所减少）。同样，包含某一特定选项的实现，应准备好与不包含该选项的另一实现互操作（当然，该选项所提供的功能除外）。
2.2.1. 需求标识符编码¶
安全需求的唯一标识符应由以下部分组成：
- 一个文档标识符
- 一个区分功能安全需求和技术安全需求的标识符
- 一个标识目标组件的标识符（AUTOSAR 自适应平台中的功能集群，或 AUTOSAR 经典平台中的基础软件组件）
- 一个需求编号
本需求规范中使用的编码模式为 RS_SAF_<Z><YY><XX>，其中
- Z 是一位数字，描述该需求是：
- 0：安全目标或顶层安全需求，其中 YY 保留，XX 为两位数字
- 1：AUTOSAR 自适应平台的功能安全需求，其中 YY 保留，XX 为两位数字
- 2：AUTOSAR 自适应平台的技术安全需求，其中 YY 是两位数字，描述需求所针对的对象：
- 00：保留
- 11：平台健康监控（PHM）
- 12：执行管理（EM）
- 13：状态管理（SM）
- 14：操作系统（OS）
- 15：持久化（PER）
- 16：通信管理（CM）
- 17：更新和配置管理（UCM）
- 3：AUTOSAR 经典平台的技术安全需求，其中 YY 是两位数字，描述需求所针对的对象：
- 00：保留
- 11：看门狗管理器（WDGM）
- 12：操作系统（OS）
- 13：E2E 保护（E2E）
- 4–9：保留供将来使用
3. 缩略语和缩写¶
以下收录与 RS_Safety 相关、且未被 AUTOSAR 术语表 [8] 收录的缩略语和缩写。
EM
执行管理（Execution Management）
SM
状态管理（State Management）
PER
持久化（Persistency）
CM
通信管理（Communication Management）
UCM
更新和配置管理（Update and Configuration Management）
S2S
信号到服务（Signal to Service）
SG
安全目标（Safety Goal）
TLSR
顶层安全需求（Top Level Safety Requirement）
WDG
看门狗（Watchdog）
4. 需求规范¶
本章在 4.1 中包含 AUTOSAR 的顶层安全需求。4.2 中的功能安全需求由这些需求导出。4.3 子章包含由功能安全需求导出的技术安全需求。
4.1. 顶层安全需求¶
4.1.1. 安全执行¶
| 描述 | AUTOSAR 应提供支持机制，以监控控制流并管理具有混合安全关键性的多个应用的执行顺序。 |
|---|---|
| 理由 | 为了确保在时序 [6] 和数据处理方面的免受干扰。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.2. 安全配置¶
| 描述 | AUTOSAR 应提供支持在车辆整个驾驶周期内正确配置的机制。 |
|---|---|
| 理由 | AUTOSAR 需要提供措施和机制，以便在车辆的整个驾驶周期内保持配置的一致性。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.3. 安全更新或安全升级¶
| 描述 | AUTOSAR 应提供支持以正确更新和升级多个具有混合关键性的平台及非平台应用的机制。 |
|---|---|
| 理由 | AUTOSAR 支持在机器生命周期内的可更新性，因此平台有责任确保这些更新正确且安全地执行。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.4. 信息的安全交换¶
| 描述 | AUTOSAR 应提供支持在安全关键应用之间安全交换（发送和接收）信息的机制。 |
|---|---|
| 理由 | 在车辆中，多个 ECU 上的多个软件组件相互协作以实现某一目标或功能。AUTOSAR 提供标准化的接口和机制来实现这些组件之间的安全通信。与车辆外部元素的安全通信也在范围内。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.5. 数据损坏的检测¶
| 描述 | AUTOSAR 应提供在处理数据、与其他系统或系统元素通信时检测故障的机制。 |
|---|---|
| 理由 | 需要检测故障的机制来实现更高的安全等级并提高产品质量。潜在故障列表在 EXP_SafetyOverview [5] 和 ISO 26262 [6] 中描述。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.6. 安全存储¶
| 描述 | AUTOSAR 应提供支持应用安全存储的机制。 |
|---|---|
| 理由 | 许多应用需要从易失性或非易失性/持久化存储器中存储和检索数据。如果应用是安全关键的，则需要正确识别数据元素，并且应检查数据本身以确保其未被更改。 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.1.7. 故障后的恢复¶
| 描述 | AUTOSAR 应监控、检测并提供对可检测故障作出反应的手段。 |
|---|---|
| 理由 | AUTOSAR 应具备以下能力： * 在发生故障时重启应用 * 在发生故障时重启机器/ECU * 在更新失败时恢复最后已知的配置 |
| 适用平台 | FO |
| 支撑材料 | ISO 26262 [6] |
4.2. 功能安全需求¶
4.2.1. AUTOSAR 应提供支持软件组件安全初始化的机制¶
| 描述 | AUTOSAR 应提供支持软件组件安全初始化的机制。 |
|---|---|
| 理由 | 需要对底层硬件和 AUTOSAR 平台的基础软件模块、功能集群、服务以及应用软件进行安全初始化，以确保预期的功能。 |
| 用例 | SUC_02 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.2. AUTOSAR 应提供支持对平台基础软件模块、功能集群、软件组件、应用、服务及其各自配置数据进行安全验证的机制¶
| 描述 | AUTOSAR 应提供支持对平台基础软件模块、功能集群、软件组件、应用、服务及其各自配置数据进行安全验证的机制。 |
|---|---|
| 理由 | 由于存储器单元中的随机硬件失效，需要对数据完整性进行验证，以确保在运行、待机或断电期间数据没有随时间丢失且未被篡改。 注意： 与网络安全无关。 |
| 用例 | SUC_02、SUC_06 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.3. AUTOSAR 应提供支持应用、软件组件、基础软件模块和服务安全关闭与终止的机制¶
| 描述 | AUTOSAR 应提供支持应用、软件组件、基础软件模块和服务安全关闭与终止的机制。 |
|---|---|
| 理由 | 在终止应用和服务和/或关闭 AUTOSAR 平台或整个 ECU 之前，必须以正确的顺序正确终止相互依赖的应用，以防止冲突、失效或意外行为。确保安全降级、故障排除和故障遏制。 |
| 用例 | SUC_01、SUC_06 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.4. AUTOSAR 应提供支持基础软件模块、软件组件、应用或服务生命周期中状态安全转换的机制¶
| 描述 | AUTOSAR 应提供支持基础软件模块、软件组件、应用或服务生命周期中状态安全转换的机制。 |
|---|---|
| 理由 | AUTOSAR 平台负责管理和监控应用的内部状态。 |
| 用例 | SUC_01、SUC_06 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.5. AUTOSAR 应提供支持对 AUTOSAR 自适应平台功能集群、应用和服务以及 AUTOSAR 经典平台基础软件模块和软件组件进行安全资源管理的机制¶
| 描述 | AUTOSAR 应提供支持对 AUTOSAR 自适应平台功能集群、应用和服务以及 AUTOSAR 经典平台基础软件模块和软件组件进行安全资源管理的机制。 |
|---|---|
| 理由 | 应确保 AUTOSAR 平台的基础软件模块、功能集群、服务和应用在预期时间内以充分的免受干扰性获得足够的资源及对该资源的可用性。任何意外或未处理的异常不得阻止或延迟对所需的、经过妥善管理和授权的资源的访问。资源包括（除其他外）CPU、运行时间、内存消耗、网络带宽、外设（如 ADC、DAC、定时器）等。 |
| 用例 | SUC_01 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.6. AUTOSAR 应提供一个接口，以支持基础软件模块、软件组件、应用或服务的安全通信¶
| 描述 | AUTOSAR 应提供一个接口，以支持基础软件模块、软件组件、应用或服务的安全通信。 |
|---|---|
| 理由 | 在车辆中，多个 ECU 上的多个软件组件相互协作以实现某一目标或功能。AUTOSAR 平台提供标准化的接口和机制来实现这些组件之间的安全通信。与车辆外部元素的安全通信也在范围内。 |
| 用例 | SUC_03、SUC_04、SUC_05 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.7. AUTOSAR 应提供防止有效配置丢失的机制¶
| 描述 | AUTOSAR 应提供防止机器级别或车辆级别的有效配置丢失的机制。 |
|---|---|
| 理由 | AUTOSAR 平台应提供切换回最近一次正常工作配置的机制。 |
| 用例 | SUC_02、SUC_06 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
4.2.8. AUTOSAR 应提供支持对 AUTOSAR 自适应平台功能集群、应用和服务以及 AUTOSAR 经典平台基础软件模块和软件组件进行可靠调度的机制¶
| 描述 | AUTOSAR 应提供支持对 AUTOSAR 自适应平台功能集群、应用和服务以及 AUTOSAR 经典平台基础软件模块和软件组件进行可靠调度的机制。 |
|---|---|
| 理由 | 需要可靠的调度来为所有可用的 * 功能集群、服务和应用， * 基础软件模块和软件组件 确保适当的时间分配。 |
| 用例 | SUC_01 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.9. AUTOSAR 应提供支持安全程序执行的机制¶
| 描述 | AUTOSAR 应提供支持安全程序执行的机制。 |
|---|---|
| 理由 | AUTOSAR 平台应提供流监控机制，以检测并确保功能集群和服务以及用户应用和用户服务的预期程序流不被违反。 |
| 用例 | SUC_01 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.10. AUTOSAR 应提供检测程序执行时间违规的机制¶
| 描述 | AUTOSAR 应提供检测程序执行时间违规的机制。 |
|---|---|
| 理由 | 基础软件模块、功能集群、服务和应用的所有时序约束都需要得到监督和监控。 |
| 用例 | SUC_01、SUC_06 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.11. AUTOSAR 应提供防止数据被意外更改的机制¶
| 描述 | AUTOSAR 应提供防止数据被意外更改的机制。 |
|---|---|
| 理由 | 为了在运行具有混合安全关键性应用的系统中实现免受干扰，需要保护数据免受意外更改。 |
| 用例 | SUC_06 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.12. AUTOSAR 应提供支持安全相关软件仅在不会导致危险情况的状态下进行更新/升级的机制¶
| 描述 | AUTOSAR 应提供支持安全相关软件仅在不会导致危险情况的状态下进行更新/升级的机制。 |
|---|---|
| 理由 | 安全关键应用的更新应在车辆静止且处于安全位置（例如停车库）时进行。 |
| 用例 | SUC_02 |
| 适用平台 | FO |
| 依赖项 | - |
| 支撑材料 | - |
4.2.13. AUTOSAR 应支持检测数据被意外更改的机制¶
| 描述 | 应有一个检测通信错误的安全机制。该机制应完全内置于 AUTOSAR 中（包括 AUTOSAR 配置和相应的 AUTOSAR 基础软件模块）。应支持所有当前受支持的通信栈（CAN、LIN、FlexRay、Ethernet）。 |
|---|---|
| 理由 | 为了确保软件组件之间的安全数据交换符合 ISO 26262-6:2018 D.2.4 的要求，同时使用 QM 通信栈。D.2.4 定义了信息交换的以下失效模式： * 信息重复 * 信息丢失 * 信息延迟 * 信息插入 * 信息伪装或寻址错误 * 信息序列错误 * 信息损坏 * 发送方发送给多个接收方的信息不对称 * 发送方的信息只被接收方的一个子集接收到 * 阻塞对通信信道的访问 |
| 用例 | 不同 ECU、机器或分区上的 SW-C 或自适应应用使用 QM 通信栈交换安全相关数据 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 26262-6:2018 D.2.4 [6] |
4.2.14. AUTOSAR 应支持数据恢复机制¶
| 描述 | AUTOSAR 应支持数据恢复机制。 |
|---|---|
| 理由 | 应用希望恢复被更改的数据。 |
| 用例 | SUC_06 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | ISO 26262 [6] |
4.2.15. AUTOSAR 应允许集成者选择和配置用于检测通信故障的安全机制集¶
| 描述 | 基于各自的安全概念，AUTOSAR 集成者需要单独配置所需的安全机制以满足安全需求。 |
|---|---|
| 理由 | AUTOSAR 平台设计用于各种应用。对于特定应用，某一特定类型的故障可能不会发生。因此，具有可配置性是合理的，这样集成者就可以自由选择要部署的机制集。 |
| 用例 | 高层设计变更或新信息需要不同的通信保护机制。集成者可以通过更改清单（manifest）或描述文件来选择适当的保护。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
4.2.16. AUTOSAR 应提供检测时间同步违规的机制¶
| 描述 | AUTOSAR 应提供检测时间同步违规的机制。 |
|---|---|
| 理由 | 时间同步是分布式系统的关键功能，在分布式系统中，功能部署在网络上各种机器中并以异步方式采集数据，这些机器必须协同工作。 |
| 用例 | 发送方在关键消息中添加时间戳，而接收方「运行滞后」，如果时间同步工作不正常，则无法检测到消息延迟。来自传感器的重要信息需要加上时间戳，以便该信息能够被处理并与时间域内的其他数据源融合。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 支撑材料 | - |
4.3. 技术安全需求¶
以下部分需求提取自各目标需求规范，提取的需求不以 RS_SAF 命名。源文档在相应章节中注明。名为 RS_SAF 的需求将与相应的目标规范合并，以便在后续版本中本章不再包含任何自有需求。
4.3.1. AUTOSAR Foundation（AUTOSAR 基础）¶
4.3.1.1. 健康监控（HM）¶
健康监控应提供存活监督（Alive Supervision）
| 描述 | 健康监控应检查到达受监督实体（Supervised Entity）中给定检查点（Checkpoint）的频率是否与规定的限值相匹配。 |
|---|---|
| 理由 | 用于检测某个周期执行的函数是否按照规范/设计周期性地执行。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 一个带存活监督的安全关键应用在执行过程中的某一时刻卡住。HM 检测到受监督的应用不再存活。 |
| 支撑材料 | - |
健康监控应提供逻辑监督（Logical Supervision）
| 描述 | 健康监控应检查受监督实体在运行时检查点的序列是否与规定的序列相同。这应包括： * if/else 分支的开始（决策节点）：应恰好进入其中一个代码分支，具体选择取决于运行时的逻辑条件 * if/else 分支的结束（合并节点）：应恰好到达其中一个分支，以便执行汇合 * 流分叉为并发执行（分叉节点）：应进入所有并发分支 * 并发执行流的汇合（汇合节点）：应到达所有并发分支，以便执行汇合。 |
|---|---|
| 理由 | 用于检测执行中的序列是否与规定/设计的序列相同。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 对任何软件组件的监督：应用软件组件或平台组件（例如执行管理器、状态管理器）。 |
| 支撑材料 | - |
健康监控应提供截止期限监督（Deadline Supervision）
| 描述 | 健康监控应检查两个检查点之间经过的时间是否在规定的最小和最大限值之内，包括检测第二个检查点永不到达的情形。 |
|---|---|
| 理由 | 用于检测超时或失去截止期限。 |
| 适用平台 | CP、AP |
| 依赖项 | - |
| 用例 | 一个安全关键应用被开发为在规定的时间窗口内到达特定的检查点，但突然行为不符合预期。PHM 检测到该违规。 |
| 支撑材料 | - |
4.3.2. AUTOSAR AdaptivePlatform（AUTOSAR 自适应平台）¶
4.3.2.1. 功能集群：平台健康监控（PHM）¶
如果状态管理的监督失败，则平台健康监控应触发看门狗复位
| 理由 | 状态管理是自适应 AUTOSAR 的基础功能集群，如果它发生失效，则平台健康监控（控制看门狗的一方）应触发复位，这是唯一合理的安全措施。 |
|---|---|
| 依赖项 | SM |
| 用例 | SM 正在管理一个安全关键应用。SM 的监督失败并被 PHM 检测到。PHM 应触发看门狗复位。 |
如果执行管理的监督失败，则平台健康监控应触发看门狗复位
| 理由 | 执行管理是自适应 AUTOSAR 的基础功能集群，如果它发生失效，则平台健康监控（控制看门狗的一方）应触发复位，这是唯一合理的安全措施。 |
|---|---|
| 依赖项 | EM |
| 用例 | EM 正在管理安全关键应用，EM 的监督失败并被 PHM 检测到。PHM 应触发看门狗复位。 |
如果 AUTOSAR 自适应平台的功能集群、应用或服务（执行管理和状态管理除外）发生故障，平台健康监控应通知状态管理
| 描述 | 如果 AUTOSAR 自适应平台的功能集群、应用或服务（执行管理和状态管理除外）发生故障，平台健康监控应通知状态管理。 |
|---|---|
| 理由 | 恢复动作在 SM 中协调，故障应上报给 SM，除非 SM 或 EM 自身发生故障。 |
| 依赖项 | - |
| 用例 | PHM 监督一个安全关键应用。该应用发生失效。PHM 检测到该问题并上报给 SM。 |
PHM 应只处理由对应进程上报的检查点
| 描述 | PHM 应只处理由对应进程上报的检查点。 |
|---|---|
| 理由 | 只有当检查点是由对应的已配置进程上报时，才能认为它是有效的。 |
| 适用平台 | AP |
| 依赖项 | RS_IAM_00002, RS_IAM_00010 |
| 用例 | - |
| 支撑材料 | - |
如果检查点由非对应进程上报，则应引发安全事件
| 描述 | 如果检查点由非对应进程上报，则应引发安全事件。 |
|---|---|
| 理由 | 恶意软件可能试图通过上报与其他进程对应的检查点来强制产生误报或漏报。 |
| 适用平台 | AP |
| 依赖项 | RS_IAM_00002, RS_IAM_00010, RS_Ids_00810 |
| 用例 | - |
| 支撑材料 | - |
4.3.2.2. 功能集群：执行管理（EM）¶
执行管理应为每个建模进程（Modelled Process）的执行建立一个进程
| 描述 | 对于每个可执行文件（Executable）实例，执行管理应分配一个 POSIX 进程。此外，应基于执行清单（Execution Manifest）分配进程特定的属性（如优先级、调度策略和访问权限）。 |
|---|---|
| 理由 | 将可执行文件实例彼此隔离。 |
| 依赖项 | - |
| 用例 | 安全和信息安全相关应用需要隔离。 |
| 支撑材料 | - |
执行管理应支持为进程和进程组配置 OS 资源预算
| 描述 | 执行管理应基于执行清单为进程分配 OS 资源。分配应可针对单个进程和进程组进行。 |
|---|---|
| 理由 | 应定义实时保证。 |
| 依赖项 | - |
| 用例 | 类似于 cgroups（基于包含一个或多个进程的容器）和 ulimit。 |
| 支撑材料 | - |
执行管理应支持将给定进程的所有线程绑定到指定的处理器核心集合
| 描述 | 执行管理应允许基于执行清单中的配置将线程绑定到特定的处理器核心集合。绑定粒度应为进程级别。 |
|---|---|
| 理由 | 影响负载均衡、反应时间和延迟的机制。 |
| 依赖项 | - |
| 用例 | 可以将一个进程分配到指定的核心，以限制线程在机器（Machine）上可用核心之间的迁移。 |
| 支撑材料 | - |
执行管理应控制其启动的每个进程创建子进程的权限
| 描述 | 执行管理负责启动子进程，并应防止这些子进程直接启动其他进程，除非另有配置。 |
|---|---|
| 理由 | 执行管理需要对应用启动的完全控制，以确保时间和空间属性的必要隔离。然而，现有软件可能需要创建子进程的权限，为配合 AUTOSAR 自适应平台使用而修改它可能并不现实。因此，执行管理允许选定的进程创建子进程，但这必须由集成者配置，并且不是默认授予的权限。 |
| 依赖项 | - |
| 用例 | 具有不同安全和/或信息安全属性的应用之间的隔离。 |
| 支撑材料 | - |
执行管理应执行机器范围内的进程协调
| 描述 | 执行管理应提供一个 API，供进程注册其活动，以便能够协调它们的执行。 |
|---|---|
| 理由 | 跨可执行文件（Executable）协调活动的调度。 |
| 依赖项 | - |
| 用例 | 运行中的进程内的计算资源使用应在机器范围内进行管理，以确保活动能够跨进程协调。注册使执行管理能够形成协调所需的机器范围视图。 |
| 支撑材料 | - |
执行管理应提供 API 以支持进程的确定性冗余执行
| 描述 | 执行管理应提供 API 以支持进程的确定性冗余执行。 |
|---|---|
| 理由 | 高 ASIL 系统要求在非车规级微处理器上实现软件锁步（software lockstep）之类的安全机制。冗余执行应保证确定性的、即可复现的结果。 |
| 依赖项 | - |
| 用例 | 以冗余执行活动的方式实现软件锁步。 |
| 支撑材料 | - |
执行管理应支持时间触发的执行
| 描述 | 执行管理应促进时间触发的周期性执行。 |
|---|---|
| 理由 | 进程中的算法可以是时间触发的。OS 需要提供允许应用时间触发执行的机制。触发器至少需要包含外部定时器，但不限于此。 |
| 依赖项 | - |
| 用例 | 以冗余执行活动的方式实现软件锁步。 |
| 支撑材料 | - |
执行管理的实现至少应达到平台所支持的任何进程的最高安全完整性等级
| 描述 | 执行管理的实现至少应达到平台所支持的任何进程的最高安全完整性等级。 |
|---|---|
| 理由 | 执行管理管理所有进程的实例化和终止，因此需要按照与系统中由执行管理所管理的最高等级安全应用相同的安全标准来开发和执行。 |
| 适用平台 | AP |
| 依赖项 | EM |
| 用例 | 一个 ASIL C、B 和 QM 应用运行在 AUTOSAR 自适应平台上。执行管理应执行 ASIL C、B 和 QM 应用，因此执行管理应以 ASIL C 实现。 |
| 支撑材料 | - |
4.3.2.3. 功能集群：状态管理（SM）¶
状态管理的实现至少应达到状态管理所管理的任何进程的最高安全完整性等级
| 描述 | 状态管理的实现至少应达到状态管理所管理的任何进程的最高安全完整性等级。 |
|---|---|
| 理由 | SM 管理所有进程的状态变更和恢复动作，因此需要按照与系统中由 SM 管理的最高等级安全应用相同的安全标准来开发和执行。 |
| 适用平台 | AP |
| 依赖项 | SM |
| 用例 | 一个 ASIL C、B 和 QM 应用运行在自适应平台上。SM 应管理 ASIL C、B 和 QM 应用，因此 SM 应以 ASIL C 实现。 |
| 支撑材料 | - |
状态管理应协调恢复动作
| 描述 | 状态管理应协调恢复动作。 |
|---|---|
| 理由 | 状态管理是平台健康监控上报监督失败的中心功能集群，由状态管理决定应触发哪个恢复动作（例如功能组状态变更、向安全应用通知，甚至 ECU 复位）。 |
| 适用平台 | AP |
| 依赖项 | SM、PHM |
| 用例 | PHM 监督一个安全关键应用。该应用发生失效。PHM 检测到该问题并上报给 SM。SM 协调错误恢复动作。 |
| 支撑材料 | - |
4.3.2.4. 操作系统接口（OSI）¶
操作系统应提供系统内存预算机制
| 描述 | 操作系统应提供为每个进程或进程组配置内存预算的机制。 |
|---|---|
| 理由 | 为了在多进程系统环境中确保资源可用性，系统集成者/架构师可能需要一组工具来为每个进程或进程组配置内存预算。 |
| 依赖项 | - |
| 用例 | 信息安全——防范 DoS 攻击——资源匮乏类型。 |
| 支撑材料 | - |
操作系统应提供 CPU 时间预算机制
| 描述 | 操作系统应提供为每个进程或进程组按 CPU 时间配置资源预算的机制。 |
|---|---|
| 理由 | 为了在多进程系统环境中确保可调度性，系统集成者/架构师可能需要一组工具来为每个进程或进程组配置分配的 CPU 时间。 |
| 依赖项 | - |
| 用例 | 信息安全——防范 DoS 攻击——资源匮乏类型。 |
| 支撑材料 | - |
操作系统宜提供将进程绑定到 CPU 核心的机制
| 描述 | 操作系统宜提供将单个进程或进程组绑定到 CPU 核心的机制。 |
|---|---|
| 理由 | 为了确保正确的任务可调度性，系统集成者可能需要一组工具来配置进程的 CPU 亲和性。在多核系统中，确保某些进程只能在某些 CPU 核心上运行可能是相关的，以便让其他受限制较少或限制方式不同的进程并发推进。 |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
操作系统应提供多进程支持以隔离应用
| 描述 | 操作系统应提供让多个进程彼此隔离运行的机制。 |
|---|---|
| 理由 | 每个进程可能具有不同的健壮性、安全性和信息安全等级。因此，一个进程执行中的错误内存访问不得导致另一个进程内存的损坏，除非数据区域被显式共享。此外，一个进程不得在没有显式数据共享的情况下访问或读取另一个进程的数据。 |
| 依赖项 | - |
| 用例 | - |
| 支撑材料 | - |
4.3.2.5. 功能集群：持久化（PER）¶
数据损坏的检测
| 描述 | 持久化应能够检测持久化存储器中的数据损坏。补充信息：损坏可能由系统性或随机性失效引起。为了能够检测到损坏的数据，需要某种冗余，可以是校验和到完整副本之间的任何形式。此外，自适应应用可以注册以接收关于数据损坏的信息。用于确保数据一致性的实际机制由配置决定。 |
|---|---|
已损坏数据的恢复
| 描述 | 持久化应能够恢复已损坏的数据。补充信息：为了能够恢复损坏的数据，需要数据的一个冗余副本。此外，自适应应用可以注册以接收关于数据恢复的信息。实际的冗余机制和粒度由配置决定。 |
|---|---|
4.3.2.6. 功能集群：通信管理（CM）¶
通信管理应使用 E2E 协议保护事件的传输。E2E 保护必须在事件 API 之后执行
| 描述 | 应用开发者应能够获得受 E2E 保护的事件式通信，而无论使用哪种总线。 |
|---|---|
| 理由 | 应确保通信总线引入的、E2E 协议可检测的通信失效模式（在受 E2E 保护的序列化数据上）由通信管理检测到。注意： 取决于所使用的通信类型（周期性/非周期性）和应用，需要检测哪些失效模式。 |
| 依赖项 | - |
| 用例 | 应用 "A" 接收受 E2E 保护的速度信号（作为事件的一部分）。在发生损坏或丢失时，通过应用的周期性轮询和 E2E 检查（CRC 和卡滞计数器）检测到该情形，并由通信管理通过 E2E 结果上报。因此，应用可以使其功能进入安全状态，例如拒绝打开尾门。 |
| 支撑材料 | [9] |
通信管理应将所接收事件的 E2E 信息提供给应用
| 描述 | 通信管理应将所接收事件的 E2E 信息提供给应用。 |
|---|---|
| 理由 | 在接收到无效的 E2E 检查结果时，应用应能够执行适当的错误处理。安全相关数据和非安全相关数据对事件数据的访问是相同的。 |
| 依赖项 | - |
| 用例 | 应用 "A" 轮询并获得无效的 E2E 检查结果，作为结果，它切换到安全状态。 |
| 支撑材料 | 对于队列中的每个事件，提供的 E2E 信息应为：E2E 状态（E2E status）、E2E 状态机状态（E2E state）和采样值。注意，在应用被触发的情形下，可能需要应用级超时检测。这是因为在延迟或丢失的情形下，事件不会到达，也不会执行 E2E 检查。 |
通信管理应使用 E2E 协议保护方法的传输
| 描述 | 通信管理应对应用透明地使用 E2E 协议保护方法的传输。 |
|---|---|
| 理由 | 应确保通信总线引入的、E2E 协议可检测的通信失效模式（在受 E2E 保护的序列化请求数据或响应数据上）在客户端侧由通信管理检测到。注意： 取决于所使用的通信类型（周期性/非周期性）和应用，需要检测哪些失效模式。 |
| 依赖项 | - |
| 用例 | 客户端-服务器式通信中受 E2E 保护的方法调用 |
| 支撑材料 | [9] |
通信管理应将所接收方法调用的 E2E 信息提供给应用
| 描述 | 通信管理应将所接收方法调用的 E2E 信息提供给应用。 |
|---|---|
| 理由 | 在接收到无效的 E2E 检查结果时，应用应能够将检测到的 E2E 失效模式传播到提供给客户端的响应数据中。安全相关数据和非安全相关数据对请求数据的访问是相同的。 |
| 依赖项 | - |
| 用例 | 应用 "B" 提供一个方法，该方法被应用 "A" 调用，并在请求中接收到无效的 E2E 检查结果，作为结果，相同的无效 E2E 数据被添加到响应数据中 |
| 支撑材料 | 提供的 E2E 信息应为 E2E 状态、E2E 状态机状态和对象数据。 |
通信管理应提供一个接口，通过监督预定义的响应截止期限，在客户端侧检测 E2E 受保护服务响应的延迟
| 描述 | 通信管理应提供一个接口，通过监督预定义的响应截止期限，在客户端侧检测延迟的服务响应。 |
|---|---|
| 理由 | 应检测到延迟的响应，应用可以采取安全相关的错误反应。 |
| 依赖项 | - |
| 用例 | 客户端发送一个方法调用。客户端等待响应在 300ms 内到达。到达截止期限后，故障在客户端侧被检测到。 |
| 支撑材料 | - |
通信管理应将方法响应的 E2E 信息提供给应用
| 描述 | 通信管理应将方法响应的 E2E 信息提供给应用。 |
|---|---|
| 理由 | 在接收到无效的 E2E 检查结果时，应用应能够执行适当的错误处理。安全相关数据和非安全相关数据对响应数据的访问是相同的。 |
| 依赖项 | - |
| 用例 | 应用 "A" 请求一个方法调用，并在响应中接收到无效的 E2E 检查结果，作为结果，它切换到安全状态。 |
| 支撑材料 | 注意，可能需要应用级监督截止期限以停止等待响应。 |
4.3.2.7. 功能集群：更新和配置管理（UCM）¶
UCM 应支持激活失败情况下的恢复机制
| 描述 | UCM 应确保在更新过程失败的情形下，系统将恢复到更新过程开始之前的状态。 |
|---|---|
| 理由 | 更新失败不得导致 AUTOSAR 自适应平台期望功能的丢失。 |
| 依赖项 | RS_UCM_00021 |
| 用例 | 远程更新失败后，AUTOSAR 自适应平台恢复到之前的系统状态。 |
| 支撑材料 | - |
UCM 应检查所传输软件包（Software Package）的一致性
| 描述 | UCM 应检查所接收软件包的一致性。 |
|---|---|
| 理由 | AUTOSAR 自适应平台应确保软件包可以被安全地安装。 |
| 依赖项 | - |
| 用例 | 为了检测在创建软件包期间可能发生的错误，UCM 应检查所提供的软件包元数据与内容是否匹配。 |
| 支撑材料 | - |
UCM 应能够从意外中断中安全恢复
| 描述 | 在启动时，UCM 应能够识别某个动作是否被中断并以不受控的方式退出，需要被回退或完成，以将软件恢复到之前的状态。 |
|---|---|
| 理由 | UCM 应确保软件不会启动到不一致且不可更新的状态。 |
| 依赖项 | - |
| 用例 | 在意外复位或崩溃后，UCM 应识别出在某动作正在执行时发生了中断，UCM 应通过回退或完成未完成的动作来处理该情形。 |
| 支撑材料 | - |
UCM 应能够在激活期间验证已更新的软件
| 描述 | UCM 应要求已更新的软件被执行并验证通过之后，才宣告软件已成功激活。 |
|---|---|
| 理由 | UCM 只有在检测到执行管理能够成功执行该软件之后，才应宣告激活成功。 |
| 依赖项 | - |
| 用例 | 确保安全关键应用能够被执行，从而能够被平台健康管理器（Platform Health Manager）监控。 |
| 支撑材料 | - |
4.3.3. AUTOSAR ClassicPlatform（AUTOSAR 经典平台）¶
4.3.3.1. 基础软件：看门狗管理器（WDGM）¶
看门狗管理器从软件组件继承最高安全完整性等级
| 描述 | 看门狗管理器应至少从平台上运行的任何软件组件继承最高的安全完整性等级。 |
|---|---|
| 理由 | 看门狗管理器负责确保安全相关软件组件/应用安全执行的一部分，它至少应以与被监督的软件组件/应用相同的最高 ASIL 开发。 |
| 用例 | 一个 ASIL C、B 和 QM 应用运行在经典平台上。WdgM 应监督 ASIL C 和 B 应用，因此 WdgM 应以 ASIL C 实现。 |
| 适用平台 | CP |
| 依赖项 | WdgIf、Wdg Drv |
| 支撑材料 | - |
看门狗管理器监控存活状态
| 描述 | 看门狗管理器应监控安全相关软件组件/应用和模块的存活状态。 |
|---|---|
| 理由 | 存活监督是看门狗管理器监控安全相关软件组件/应用和模块的机制之一。 |
| 用例 | 一个带存活监督的安全关键功能在执行过程中的某一时刻卡住。WdgM 检测到受监督的应用不再存活。 |
| 适用平台 | CP |
| 依赖项 | WdgIf、Wdg Drv |
| 支撑材料 | - |
看门狗管理器监控控制流
| 描述 | 看门狗管理器应监控安全相关软件组件/应用和模块的控制流。 |
|---|---|
| 理由 | 逻辑监督是看门狗管理器监控安全相关软件组件/应用和模块的机制之一。 |
| 用例 | 一个安全相关功能被开发为遵循特定的控制流，但突然不遵循预期的序列。看门狗管理器检测到控制流违规。 |
| 适用平台 | CP |
| 依赖项 | WdgIf、Wdg Drv |
| 支撑材料 | - |
看门狗管理器监控截止期限
| 描述 | 看门狗管理器应监控安全相关软件组件/应用和模块的检查点之间的持续时间是否在配置的最小和最大时间限值之内。 |
|---|---|
| 理由 | 截止期限监督是看门狗管理器监控安全相关功能的机制之一。 |
| 用例 | 一个安全关键应用被开发为在规定的时间窗口内到达特定的检查点，但突然行为不符合预期。WdgM 检测到该违规。 |
| 适用平台 | CP |
| 依赖项 | WdgIf、Wdg Drv |
| 支撑材料 | - |
4.3.3.2. 基础软件：操作系统（OS）¶
应用的内存保护
| 描述 | 操作系统应阻止应用在其分配的内存区域之外执行写访问。 |
|---|---|
| 理由 | 为了实现免受干扰，必须阻止应用对其他应用产生不利影响。为应用保留的私有内存的访问应受到保护，免受来自其他应用的未授权写访问。 |
| 用例 | 一个 QM 应用和一个 ASIL 应用在同一台机器上执行。OS 阻止 QM 应用更改分配给安全关键应用的内存。 |
| 适用平台 | CP |
| 依赖项 | OSEK OS |
| 支撑材料 | - |
应用的时序保护
| 描述 | 操作系统不得允许任何应用中的时序故障传播。时序故障可能由以下原因引起： * 超出静态/预运行规定的执行时间预算 * 超出静态/预运行规定的阻塞时间预算 * 超出静态/预运行规定的到达速率 |
|---|---|
| 理由 | 一个应用中的时序故障可能触发一系列时序故障，必须防止这种情况。 |
| 用例 | 一个 QM 应用和一个 ASIL 应用在同一台机器上执行。OS 阻止 QM 应用将其延迟传播到安全关键应用。 |
| 适用平台 | CP |
| 依赖项 | OSEK OS |
| 支撑材料 | - |
4.3.3.3. E2E 保护¶
使用 E2E 转换器和 E2E 库的 E2E 保护
| 描述 | 通信服务、E2E 转换器和 E2E 库应通过考虑 ISO 标准中列出的所有故障（ISO 26262:6-2018 D.2.4），提供检测软件组件之间信息交换期间错误的机制。E2E 检查的结果需要发布给应用。如果使用 E2E 转换器，则需要按照与被转换的应用和数据相同的 ASIL 等级来开发 RTE 接口。 |
|---|---|
| 理由 | 创建此需求最初是为了通过提供安全措施和机制来实现 AUTOSAR 支持安全相关系统开发的目标。由于用户可能构建项目特定的应用，AUTOSAR 只能提供信息的安全交换。提及并应遵循 ISO 26262，因为它是汽车 E/E 系统功能安全的国际标准。 |
| 用例 | 不同控制设备上的两个 ASIL 等级应用应通过一个较低 ASIL 等级的组件（HW 或 SW）交换信息。E2E 转换器和 E2E 库应支持计数器、校验和时间戳等安全机制，使 ASIL 应用或 E2E 转换器和 E2E 库的实现能够检测并确保信息已被正确、及时且按序传输。 |
| 适用平台 | CP |
| 依赖项 | E2E Library、E2E Transformer、RTE、SWC |
| 支撑材料 | - |
允许集成者配置用于检测通信故障的安全机制
| 描述 | 基于各自的安全概念，通信服务、E2E 转换器和 E2E 库应允许集成者选择和配置用于检测通信故障的安全机制集。 |
|---|---|
| 理由 | 不同的通信总线和数据信息可能需要 E2E 提供不同程度的保护。因此，具有可配置性（部署前）是合理的，这样集成者就可以自由选择要部署的机制集。 |
| 用例 | 高层设计变更或新信息需要不同的通信保护机制。集成者可以通过更改清单（Manifest）来选择适当的保护。 |
| 适用平台 | CP |
| 依赖项 | E2E Library、E2E Transformer、RTE、SWC |
| 支撑材料 | - |
5. 参考文献¶
AUTOSAR_FO_RS_Main
[2] Explanation of Adaptive Platform Design
AUTOSAR_AP_EXP_PlatformDesign
[3] Layered Software Architecture
AUTOSAR_CP_EXP_LayeredSoftwareArchitecture
[4] Explanation of Adaptive Platform Software Architecture
AUTOSAR_AP_EXP_SWArchitecture
[5] Explanation of Safety Overview
AUTOSAR_FO_EXP_SafetyOverview
[6] ISO 26262:2018（所有部分）——道路车辆——功能安全
https://www.iso.org
AUTOSAR_FO_TPS_StandardizationTemplate
AUTOSAR_FO_TR_Glossary
AUTOSAR_FO_RS_E2E
A. AUTOSAR 可追溯项变更历史¶
请注意，本章中的列表还包括在后续版本中已从规范中移除的可追溯项。这些可追溯项在文档中不作为超链接出现。
由于本批次决议整体省略需求项 ID，本附录源文档中的纯 ID 枚举列表以数量形式呈现——运行决策，请用户在确认关核验。
A.1. 本文档依据 AUTOSAR 版本 R22-11 的可追溯项变更历史¶
A.1.1. R22-11 中新增的需求¶
新增 5 项。
A.1.2. R22-11 中变更的需求¶
变更 14 项。
A.1.3. R22-11 中删除的需求¶
删除 19 项。
A.2. 本文档依据 AUTOSAR 版本 R23-11 的可追溯项变更历史¶
A.2.1. R23-11 中新增的需求¶
无。
A.2.2. R23-11 中变更的需求¶
变更 14 项。
A.2.3. R23-11 中删除的需求¶
删除 3 项。