目的

功能安全是一种系统特性，从AUTOSAR Adaptive平台开发之初就被考虑在内，因为它可能会影响系统和软件架构设计决策。因此，AUTOSAR 自适应平台规范包括与功能安全相关的要求。系统设计的复杂性等方面对于实现汽车行业的功能安全至关重要。

软件是影响系统级别复杂性的一个参数。可使用软件开发的新技术和新概念，最大限度地降低复杂性并简化功能安全的实现。AUTOSAR自适应平台通过提供安全措施和机制来支持安全相关系统的开发。

但是，AUTOSAR 自适应平台并不是一个完整的安全解决方案。此安全概述的目标是从顶级安全目标和假定的用例或方案中派生安全需求，并将其分配给项目的架构元素或任何外部度量。使用 AUTOSAR 自适应平台并不意味着符合 ISO 26262-10 标准。使用AUTOSAR自适应平台安全措施和机制构建不安全的系统仍然是可能的。在最好的情况下，AUTOSAR自适应平台的架构只能被认为是SEooC。

有关 AUTOSAR 自适应平台功能安全机制和措施的信息目前分布在引用的文档中。除非人们知道如何支持功能安全机制以及特定位置的必要信息，否则很难评估如何使用AUTOSAR有效地实施与安全相关的系统。本解释性文件总结了AUTOSAR中与功能安全相关的要点，并解释了如何使用功能安全机制和措施。

范围

本文档应具有解释性，并帮助功能安全工程师在 AUTOSAR 自适应平台中识别与功能安全相关的主题。本文档的内容分为以下几章：

AUTOSAR 自适应平台目标、用例和场景

系统定义、系统上下文和假设

危害分析

安全目标

功能安全概念映射到ISO 26262中的以下章节，图1.1：

[3-5] 项目定义

[3-6] 危害分析和风险评估

[3-7] 功能安全概念

如图 1.2 所示。根据 ISO 21434，安全需求按层次结构进行分层结构，并从危险到安全目标到功能需求和工件进行分配或引用。开发过程和组织主题不是本概述的一部分，没有进行风险评估（参见已知限制一章），本文档中的每个系统描述，场景或用例都只是解释性的，仅供参考。系统设计不在本文讨论范围！

图 1.1：ISO 26262 的考虑章节，ISO 26262 系列标准概述，图 1 - ISO 26262-1 [1]

图 1.2：安全需求的结构以及本文档的映射，基于ISO 26262 [1]

目标受众

本文档应概述AUTOSAR自适应平台的功能安全措施和机制，以及它们对参与安全相关（ECU）系统开发的人员的实施。因此，本文档适用于 AUTOSAR 自适应平台的用户，包括参与安全分析的人员。AUTOSAR 特定词汇表和功能安全相关词汇表术语由 AUTOSAR 词汇表 [3] 或 ISO 26262 [1] 本身涵盖，如果不需要与本文档相关的其他信息或解释提示，则不会复制这些术语。

AUTOSAR自适应平台的使用假设和目标

使用假设

AUTOSAR自适应平台的使用假设特别包括但不限于来自以下领域的汽车级电子控制单元：

自动驾驶：从驾驶员辅助到全自动驾驶，包括 AD，ADAS和/或Sensor-ECU的生态系统（如适用）

网关

车身域控制器

信息娱乐系统等

为了满足对更高处理能力的要求，例如传感器数据处理（图像，雷达），多传感器数据融合或机器学习以及增强的多媒体功能，如2D / 3D图形加速，视频和音频处理，AUTOSAR自适应平台应支持高性能计算单元和加速器，通常通过专用和专有的硬件组件和软件接口实现。

设计目标

AUTOSAR自适应平台的整体设计目标与众所周知且已建立的AUTOSAR经典平台相似，因此描述了电子控制单元的汽车软件的抽象层，接口和一些常见行为。AUTOSAR Adaptive Platform仍然为软件开发人员提供抽象层，例如AUTOSAR Runtime for Adaptive Applications（ARA），因此AUTOSAR Adaptive Platform应用可以在ECU之间交换或轻松移植。从系统的角度来看，这类似于 AUTOSAR 经典平台 BSW 和 VFB 层 - 如 AUTOSAR 经典平台架构文档 [4] [5] 中所述。

第二个主要目标是允许动态软件升级，并在现场车辆内更灵活地开发和部署应用和服务。

第三个目标，也是功能安全工程师最重要的目标，是能够在一个分区内执行从QM到ASIL D的混合关键性的应用，同时保持免干扰性。如果系统包含多个分区，甚至可能根本不符合ISO 26262标准（或最大QM），就像信息娱乐系统一样，仍然需要免干扰性，但不在AUTOSAR自适应平台架构和标准的范围内。

有关 AUTOSAR 目标（尤其是 AUTOSAR 自适应平台）的更多详细信息，请查看 AUTOSAR 简介演示文稿 [6] 和解释性 AUTOSAR 自适应平台设计文档 [7]。

场景

示例场景：HAD

选择高度自动驾驶（HAD）场景来研究AUTOSAR自适应平台的安全功能。此方案不仅满足了高性能计算和动态软件更新的要求，还涵盖了相应的最高安全用例：符合 ISO 26262 [1] 的 ASIL D。假设车辆级别的系统设计包含多个传感器，直接连接到传感器或传感器 - ECU（例如雷达，激光雷达，视觉，INS，GNSS）。预计该车辆将至少有一个ADAS-ECU用于自动驾驶功能，其中AUTOSAR自适应平台可以集成，不仅在ADAS-ECU上，而且在Sensor-ECU或任何其他前面提到的域控制器上。

示例场景：仪表盘

不像HAD那样安全关键，但可以使用ASIL评级的例子是仪表板。虽然仪表板不像HAD那样对安全需求至关重要，但它也不像信息娱乐系统那样微不足道。

让我们考虑一个用例，其中车速表的速度错误，驾驶员驾驶速度远高于限速，从而可能出现个人和其他交通参与者的风险。当故障指示未打开时，可能会发生另一种关键情况，例如制动失效，安全气囊失效或发动机失效。

随着汽车行业技术的进步，仪表板将需要高性能。在 AUTOSAR 自适应平台上集成仪表板自然是有意义的，可以满足高性能要求。反过来， AUTOSAR自适应平台应确保功能安全需求。

顶级功能需求或用例

根据最初的利益相关者分析和 AUTOSAR 联盟伙伴要求，已根据 AUTOSAR 自适应平台的预期用途和范围确定了以下功能需求：

[SUC-01] 为多个混合关键性应用提供灵活的执行时间和资源。

[SUC-02] 为多个混合关键性应用提供动态可配置、可更新和可升级的运行时。

[SUC-03]在多个混合关键性应用之间提供信息交换。

[SUC-04] 在混合关键性应用与车辆内部的传感器、执行器或ECU等其他外部组件之间提供信息交换。

[SUC-05]在混合关键性应用和车辆外部的其他外部组件之间提供信息交换。

[SUC-06] 在驾驶周期内保持正确的配置并监控正确的运行

系统描述

研究元素

本解释性文档中正在研究的元素是在第 3 章中大致描述的系统上下文中运行的 AUTOSAR 自适应平台架构。AUTOSAR Adaptive Platform架构最终将成为软件组件的基础，根据ISO 26262-1和ISO 26262-10，它可以被视为一个元素和SEooC。

AUTOSAR自适应平台旨在独立于解决方案，除了它是为汽车工业和根据第2章中描述的目标开发的。尽管如此，它将要执行的平台也需要进行调查，以便得出一些危险和安全需求。其中一些最终将由AUTOSAR自适应平台架构中描述和定义的软件功能满足，另一些将分别由OEM或其供应商满足。现代ECU包含高度模块化的嵌入式软件，可以由非安全相关和安全相关软件组件组成，这些组件以不同的ASIL等级执行功能。根据ISO26262，如果嵌入式软件由具有不同ASIL等级的软件组件组成，则必须根据最高ASIL等级开发整个软件，或者对于具有较高ASIL等级的软件组件，应确保具有较高ASIL等级的软件组件与具有较低或相同ASIL等级的元件的独立性，即使或尤其是如果从较高ASIL的功能分解得到例如 2×ASIL B（D）。

假定的系统上下文

以下系统上下文描述只是有根据的猜测和假设，是推导和解释安全需求所必需的。

车辆上下文

在最初定义AUTOSAR自适应基准高性能处理单元时，作为SEooC开发的高性能处理单元本身并不总是达到ASIL D的安全等级，因此已经认为一些简单的系统设计能够通过适当的分解达到ASIL B或ASIL D。AUTOSAR自适应平台架构只能支持实际的系统或硬件开发人员实现特定的安全目标。

图3.1：示范性简化车辆系统

图3.3：使用安全检查器分解

车辆系统设计不是 AUTOSAR自适应平台规范的一部分，仍然任何一个选项（3.2 和 3.3）都可以是有效的系统设置。最终产品开发人员和安全工程师应选择适当的系统设计和分解策略，以实现特定的安全目标并满足特定的安全需求。

电子控制单元上下文

在典型的符合安全标准的 ECU 中，可以假设除了微处理器（uP 或SoC）动态和永久存储器外，它还将配备电源管理集成电路（PMIC），看门狗和一些板载传感器或驱动器以及多个输入输出通道，例如数字、模拟或通过以太网等车辆总线进行通信， CAN或 FlexRay。

图3.4：简单ECU设计的示例性草案

一些简单的板上安全措施是：

稳压和受控电源管理

电源监控（电压和电流）

温度监控

活监测（看门狗）

输入/输出控制

如果控制器或正在运行的软件不再可信，例如如果电压电平不稳定或看门狗已触发，则 line 驱动程序和收发器可能被禁用，从而在没有软件交互的情况下实现故障静默行为。

微处理器上下文

微处理器或 SoC 设计可能如图 3.5 所示。

图 3.5：简单 MCU 设计的示例性草案

适用于 AUTOSAR 自适应平台的典型微处理器可能包含多个性能处理内核（uP）、一个硬件安全模块（HSM），在某些情况下还包含一个外设微控制器内核（uC）。HSM 和 uC 可以是典型的通用控制器，并且是用户可编程的，或者配备了供应商提供的固件。AUTOSAR 自适应平台的主要目标是性能处理器。外围设备可以通过uP访问，也可能不可以通过uP访问，外围设备访问在AUTOSAR自适应平台中与AUTOSAR经典平台中的级别相同。AUTOSAR自适应平台的唯一硬件要求是通过运行系统间接定义的，运行系统应提供多进程支持或隔离应用，因此需要根据[8][9]的内存管理单元（MMU）。如果 ECU 应与其他 ECU 通信，则通过 SOME/IP 协议支持以太网。外部flash和RAM不是直接需要的，而是实际硬件设计中的常见做法（截至2018年）。

硬件加速器

AUTOSAR 自适应平台架构中遵循硬件加速器和并行处理。有关此主题的详细信息，请阅读“在自适应平台上使用并行处理技术的设计指南 [10]”。硬件加速器的软件开发过程和所需的软件机制与典型的微处理器基本相同。应有机制来检查软件例程是否正确调度，计算是否正确，控制流是否可监控。

软件上下文

动态内存分配

自适应平台供应商和自适应应用开发人员可以在安全相关代码（包括 ASIL D）中使用动态内存分配，前提是他们确保在分配失效时正确处理和清理错误，并且在运行安全相关代码时，内存分配和解除分配功能（例如 malloc 和 free， new 和 delete）具有确定性性能，这意味着它们的最差执行/阻塞时间是已知值，或者应用专用的安全机制（如看门狗）来处理时序违规。

一般硬件和软件故障注意事项

硬件不是AUTOSAR自适应平台架构的一部分，仍然有必要着重硬件来定义最终安全需求的来源。本节将被视为一般的先验知识，并收集和描述典型的硬件和软件故障以及可能直接影响自适应平台的安全措施。最有可能的是所有硬件和软件故障都将在这里描述，但并非所有影响都得到充分的分析。因此，必须根据相关行业标准，对基于 AUTOSAR 自适应 Platform 构建的每个安全关键型应用执行全面的安全评估。

潜伏的硬件故障和安全措施

具有混合关键性的多个应用的错误执行可能是由于系统故障（例如处理器设计中的错误）或随机硬件故障。自然现象，如电离辐射（例如高能粒子撞击）、电磁顺应性、振动、老化效应或外部环境条件，都可能导致此类故障。在单个平台上集成具有不同关键特性的应用可能非常棘手。可应用硬件级别的分区机制来隔离这些应用[11]。基于 AUTOSAR 自适应平台应用的安全关键性的硬件分区可确保与软件或逻辑分区相比，单点故障的影响更小，因为一个硬件分区中的错误对其他分区没有影响。但是，当不同硬件分区上的两个应用需要通信时，硬件分区技术可能会有损性能。

我们可将硬件故障分为三个不同的类别：瞬时性、间歇性和永久性。瞬态故障可能发生一次，并且不可重现（例如，单粒子扰动）。另一方面，间歇性故障时不时发生，但通常以不规则的时间间隔发生（例如，由于温度或湿度等环境条件而发生的故障）。顾名思义，永久性故障每次都是可重现的，除非未更换故障组件（例如，单粒子锁定），否则将持续存在。

以下是为了检测/避免上述硬件故障可以采取的典型措施列表：

周期配置测试

周期硬件部件测试（使用已知的硬件阵列）

关机路径测试（“能否达到安全状态？

内存漫游测试（例如，可写性测试）

时钟监控、电源监控、时序监控（由于此类系统固有的复杂性，高性能微处理器中的时序预测可能非常不准确）

合理性检查（但仅适用于检查比要监视的功能更容易计算的情况）

外部看门狗

端到端保护

硬件锁步 CPU 内核（尽管在高性能微处理器中可能并不总是存在这种情况）

ECC 存储器（数据和地址链接的错误检测）

冗余执行 （2oo2， 2oo2D， 2oo3）

正确的硬件设计（由于硬件架构的复杂性，高性能微处理器的选择可能非常有限，并可能导致共因故障）

正确的通信总线

适当的屏蔽

适当的电磁兼容性（EMC）

潜伏的软件故障和安全措施

硬件故障可能会直接或间接影响软件。直接影响的示例可能包括算术误算（尽管程序的控制流可能是正确的）或错误的控制流导致地址跳转会导致未定义的行为，无限循环或过早结束执行。间接影响的例子可能包括：影响其他 CPU 内核（运行系统、缓存、内存、外设过载或跨核中断泛滥或一个内核的强烈发热导致抖动）、通过软件导致内存损坏以及运行系统、平台服务或外设配置错误（运行系统调度表损坏或意外执行“禁用中断”指令或实时时钟配置错误）。

以下是为了检测/避免上述软件故障可采取的一系列典型措施：

冗余执行（2oo2， 2oo2D， 2oo3）

程序流控制（“软件是否以正确的顺序传递已知点”）

校验

仲裁

冲突检测

签名

软件锁步

并行执行

安全检查器

强大的安全措施之一是通过AUTOSAR自适应平台中的软件检测和防止故障传播。故障传播可以通过执行合理性检查的软件监视器来检测。使用双模块化冗余（DMR），可以检测到故障。此外，通过三重模块化冗余（TMR）和投票机制，甚至可以纠正故障。因此，冗余执行有助于检测是否未更正故障传播。安全策略的实施可以帮助检测访问冲突，例如用户进程访问它没有访问权限的资源。

为了避免故障传播，需对访问权限进行必要限制。在用户模式下应减少权限。如果用户进程执行特权运行，则运行系统应在授予权限之前运行合理性检查。但是运行系统和驱动程序可能在特权模式下运行，并成为共因失效的原因。平台配置（如 BIOS 设置和特殊寄存器）在运行时应为只读，在引导运行系统之前应为只读写。只应为CPU计算能力、内存和外设以及运行时分配合理的带宽，以避免因模块/组件故障而影响整个系统。防止故障传播的另一种措施是通过硬件或运行系统对特定资源（如flash、外围设备等）强制实施互斥。

AUTOSAR 自适应平台架构概述

AUTOSAR 自适应平台功能

HAD 场景和生成的 HAD 应用需要以下功能，如下图 2.2 所示，AUTOSAR 自适应平台基础库和服务（当然，请参考专用 HAD 应用）：

安全可靠的启动

应用的执行

应用调度

应用状态管理：启动、停止、停止等

运行时行为监控：处理时间、总线负载、内存消耗等

访问应用数据

持久数据存储

配置 ECU 和应用数据

已部署应用的更新

部署新应用

系统监控

通过车辆网络发送和接收消息：例如 CAN，CAN-FD， FlexRay，以太网

该功能列表不仅与上述 HAD 场景相关，还可以应用于其他特定领域的 ECU，到目前为止，尚未对这些主题进行任何进一步的深入应用和安全分析。

AUTOSAR 自适应平台架构

AUTOSAR 自适应平台的分层架构如图 3.6 所示，可分为图 2.2 中所述的三个主要部分

AUTOSAR 自适应平台基础库

AUTOSAR 自适应平台服务

用户应用（自适应应用和非平台服务）

图 3.6：AUTOSAR 自适应平台功能模块

运行系统（OS）本身不是架构的直接组成部分，但AUTOSAR Adaptive Platform对运行系统[9]有几个要求，比如为POSIX PSE51兼容的运行系统[12][13]。

AUTOSAR 自适应平台功能集群

基础库的 AUTOSAR 自适应平台功能集群 [14] 是：

ara：：core Core Types （core） [15]

ara：：exec Execution Management （em） [9]

ara：：com Communication Management （com） [16] ara：：diag Diagnostics （diag） [17]

ara：:per Persistency （per）[18]

ara：：phm Platform Health Management （phm） [19] ara：：iam Identity and Access Management （iam） [20] ara：：idsm 入侵检测系统管理器（idsm）

ara：：tsync 时间同步（tsync） [21]

ara：：log Log and Trace （log） [22]

ara：：crypto Cryptography （crypto） [23]

基础服务的功能集群是：

ara：：sm 状态管理（sm） [24]

ara：：nm 网络管理（nm） [25]

ara：：ucm 更新和配置管理（ucm） [26]

AUTOSAR Adaptive 平台功能集群的详细说明可在相应的专业文档中找到。摘要也是“自适应平台设计解释[7]”的一部分。

在 AUTOSAR 中配置 ASIL

本规范旨在支持 ISO 26262 [1] 的汽车安全集成度等级（ASIL）。其他安全完整性级别将不予考虑，也不在本文档的讨论范围之内。根据ISO 26262-3，ASIL在概念阶段被确定为HARA的一部分，并分配给每个安全目标。系统元素、软件元素或硬件元素将通过系统层次结构将安全需求分配到安全目标，将此 ASIL 作为属性继承。

ASIL 存储为 AdminData，其中包含属性为 gid=“SAFEX”的 Sdg 数据元素。此元素的内容应包含属性为 gid=“ASIL”的 Sd 元素。

此属性的有效值为：

QM

A

B

C

D

QM（A）

QM（B）

QM（C）

QM（D）

A（B）

A（C）

A（D）

B（B）

B（C）

B（D）

C（C）

C（D）

D（D）

请注意，括号表示法用于表示分解的安全需求。在本规范中，我们将原始 ASIL（即括号中的值）称为分解前的上下文 ASIL，因为它属于安全目标的上下文。

清单 5.1：元素处 ASIL 属性的 AUTOSAR XML 表示形式示例

<!-- Example AUTOSAR element with ASIL -->

<APPLICATION-SW-COMPONENT-TYPE>

<SHORT-NAME>MyComponent</SHORT-NAME>

<ADMIN-DATA>

<SDGS>

<SDG GID="SAFEX">

<SD GID="ASIL">B</SD>

</SDGS>

</ADMIN-DATA>

<PORTS>

危害分析

介绍

任何违反安全目标的故障或失效都被认为是危险的。

最常见的安全相关失效或故障是

MCU及其外设的CPU，RAM，Flash或总线中的硬件错误

软件中任何系统性和与安全相关的错误（包括等级较低的ASIL或QM错误，如果违反免干扰性）

通信线路上的电磁干扰

通信硬件组件中的硬件错误

通信驱动程序中的软件错误，导致消息损坏、延迟、丢失、重复、重新排序、插入或伪装（取自 ISO 26262-6 条款 D2.4）

基于第3.3章中最初的硬件软件故障考虑因素，上述故障源和安全目标，以及ISO 26262，其中提供了导致软件组件之间干扰的故障示例，故障可以分为以下几类：

内存

定时

执行

信息交流

应用和服务的身份验证

权限管理

顶级失效

AUTOSAR平台的顶级安全相关失效被认为是

[TLF_01] 意外、不及时和/或不正确地执行应用

[TLF_02] 应用配置、更新和升级的意外、不及时和/或不正确

[TL F_03] 应用之间意外、不及时和/或不正确的信息交换

[TLF_04] 应用与车内外部组件之间意外、不及时和/或不正确的信息交换

[TLF_05]应用与车外外部组件之间意外、不及时和/或不正确的信息交换

[TLF_06] 配置损坏

安全目标

顶级安全需求

AUTOSAR平台只是“较大”项目定义的一部分，如前几章所述，架构最终将成为真实软件组件的基础，对应于SEooC的元素定义[1]。

[RS_SAF_0 0001] 安全执行:

AUTOSAR应提供支持机制，以监控控制流程并管理具有混合安全关键性的多个应用的执行顺序。

[RS_SAF_00002]安全配置：

AUTOSAR应提供机制，以便在车辆的整个驾驶周期内提供正确的配置。

[RS_SAF_00003]安全更新或安全升级：

AUTOSAR应提供机制，以支持正确更新和升级具有不同程度的多个平台和非平台应用。

[RS_SAF_00004]安全交换信息：

AUTOSAR应提供机制，支持安全关键应用之间信息的安全交换（传输和接收）。

[RS_SAF_00005]检测数据损坏：

AUTOSAR应提供机制，以便在处理数据、与其他系统或系统元件通信时检测故障和故障。

[RS_SAF_00006]安全存储：

AUTOSAR应提供机制，支持应用的安全存储。

所有顶级安全需求应达到ASIL D．ASIL D 故障运行 5.1 质量应是可以实现的，即使其中一个顶级安全目标在适用的情况下被违反。

潜伏的产品安全评级或指标

表5.2：用例、失效以及派生的安全需求

(1)AUTOSAR 不对主机应用的安全完整性负责

功能安全概念

派生的 AUTOSAR 平台功能安全需求

从前面的第4章和第5章中的架构安全目标（5.1）和潜伏危险（4.2）中，并着重一般的硬件和软件故障考虑因素（3.3），通过走过ECU的典型生命周期和简单类别，可得出以下功能需求：安全执行，安全通信，安全存储以及安全配置和更新。

安全执行

从初始化过程开始：

需要考虑安全初始化 [RS_SAF_10001]

检查应用和服务的完整性 [RS_SAF_10002]

信息：安全启动本身根据分层架构，位于AUTOSAR平台层之下，因此不属于AUTOSAR平台架构设计和此安全相关调查的范围。警惕的安全工程师仍应意识到，在启动相应的分区之前，需要验证完整性。

根据最终产品及其环境的架构决策，上述任务的安全影响很难评估。考虑到 AUTOSAR 自适应应用的动态部署可能性，可能需要在初始化期间执行这些安全功能，以便在支持同一分区上部署的混合关键性应用动态配置的环境中保持安全。如果只允许以安全的方式将预先验证的配置上载到系统，则在启动期间只需要进行完整性检查，以确保应用未被更改。

如果已通过所有这些启动检查，则需要提供以下运行时功能：

安全的资源管理，实现免干扰性 [RS_SAF_10008]

应用和服务的可靠调度 [RS_SAF_10028]

安全程序执行 [RS_SAF_10030]

定义的程序执行时间 [RS_SAF_10031]

应用和服务分离 [RS_SAF_10008]

保护应用和服务 [RS_SAF_10008]

安全关闭应用和服务 [RS_SAF_10005]

应用/服务生命周期中状态的安全转换 [RS_SAF_10006]

信息：如果底层硬件具有与软件相同的ASIL等级，则似乎需要进行安全计算，并且仅当硬件的ASIL级别低于功能的要求时才需要进行调查。可组合几种 AUTOSAR 自适应平台机制来实现这些目标，例如，重复或冗余执行与某种自检库和控制流监控相结合。AUTOSAR Adaptive Platform 可能直接支持具有特定接口或描述的此功能，但如果从一开始就知道这一点，则特定客户的实现可以简单的方式遵守此行为，在某些情况下甚至可能对应用透明。

安全通信

在运行时，应用和服务需要相互通信，不仅在同一分区上，而且通过不同的分区、不同的控制器、ECU边界，甚至与板外通信。此外，动态部署需要对通信伙伴进行身份验证，因此：

•为应用或服务提供接口，以实现安全通信 [RS_SAF_10014]

如果不满足依赖关系，则该应用可能处于非完全正常运行状态，基于整体安全策略，整体的ECU最终被视为不完全运行状态。

安全存储

应用和服务还需要在非易失性存储器单元中持久加载和存储数据，因此：

防止数据意外更改 [RS_SAF_10037]

检测数据的意外更改 [RS_SAF_10002]

防止数据或存储访问延迟 [RS_SAF_10008]

AUTOSAR自适应平台特此仅为应用和服务提供接口。硬件特定机制是特定平台实现的一部分，例如，如NVM是具有磨损均衡功能的eMMC NAND Flash、 EEPROM、NAND、NOR-flash或FRAM等。

安全配置和更新

外部测试人员在不与应用本身交互的情况下修改NvM的可能性只是安全配置和更新的一部分。AUTOSAR 自适应平台的目标是提供一种手段，即应用可以部署在现场，而不仅仅是在车间或生产过程中。为了防止第一现场部署错误的应用，需执行以下任务来维护正确的配置：

验证是否允许在车辆上部署应用

验证是否允许在 ECU 上部署应用

验证是否允许在专用资源上部署应用

这种验证的一部分确实是检查是否满足本地和全局依赖关系，机器/分区的ASIL评级是否具有正确的分类等。最后，所有确保安全初始化和执行的检查都需要在部署之前运行，否则在初始化之后，系统可能最终处于故障模式。因此，建议仅在安全状态下执行安全关键应用的更新：

确保安全相关软件在不会导致危险情况的状态下更新/升级 [RS_SAF_10038]

如果应用只是配置项，则影响可能不大，因为应用可能只是未计划。如果应用是更新，则：

缓解或防止对有效配置的未参与或不正确更改 [RS_SAF_10002]

缓解或防止丢失有效配置 [RS_SAF_10027]

动态部署功能对每个基础模块或服务都有很大的影响，有助于满足上述大致描述的安全需求。每个基础应用或服务都需要从清单中获取配置数据的可能性，并在初始化、激活新应用期间动态解释此数据，或者供应商需要将计算机更新配置作为从基础开始受影响的应用和服务的附件。特定客户的行为的特定实现取决于集成平台的设计开放程度，以及供应商是否希望并且能够在现场跟踪每辆车的每个配置。

AUTOSAR 自适应平台的安全工件

根据危害分析、安全目标和功能安全需求，确定 AUTOSAR 自适应平台的以下工件：

确保具有混合关键性的多个应用的正确计算、执行和执行顺序

[RS_SAF_00001]

EM

PHM

SM

信息：信息架构元素 EM、SM 和 PHM 具有高度安全相关性；安全执行和安全运行状态管理是自适应应用安全运行的基础。EM、PHM、SM 元件相互依赖，并协调其活动，以确保 AUTOSAR 自适应平台内的功能安全。

AUTOSAR应确保在平台的整个生命周期内进行正确的配置[RS_SAF_00002]

EM

PHM

UCM

PER

AUTOSAR应确保正确更新和升级具有混合关键性的多个平台和非平台应用

[RS_SAF_00003]

UCM

PHM

CM[E2E]

PER

SM

AUTOSAR应确保信息的正确交换（传输和接收）

[RS_SAF_00004]

CM

PHM

AUTOSAR应在处理数据，与其他系统或系统元素通信时检测故障和故障

[RS_SAF_00005]

CM[E2E]

PHM

PER

已知限制

本解释性文档可能包含假设、示例性项目如参考模型、用例、场景和/或对示例性技术解决方案、设备、流程或软件的引用。本文档中包含的任何此类假设或示例性项目仅用于说明目的。这些假设不是AUTOSAR标准的一部分。无论是它们在此类规范中的存在，还是任何实际实施此类示例性项目的AUTOSAR一致性产品的后续文档，都并不意味着涵盖此类项目或假设的知识产权是根据适用于AUTOSAR标准的相同规则许可的。

章节：

技术安全概念

安全需求验证、安全分析和示例性用例计划在以后发布。

没有ASIL评级

AUTOSAR联盟，特别是AUTOSAR自适应平台工作组仅提供架构定义，功能模块的分解和概念验证实现，不可能在此范围内为每个架构项目添加ASIL评级。只能给读者一些关于如何在他自己非常特定的上下文中组合架构项目以实现安全架构的提示：考虑底层硬件，产品安全目标和指标以及开发过程。

符合 ISO26262 第 10 部分的 SEooC 标准

如果根据ISO 26262，AUTOSAR自适应平台架构定义本身可以被视为SEooC，则第10部分仍未解决且尚未验证。根据ISO 26262第1部分中对相关项，元素或架构的定义，架构（在本例中为软件架构）是相关项或元素结构的表示形式，元素可以是系统，软件组件或软件单元，最终也可能是SEooC。无论哪种方式，将ISO 26262第10部分SEooC定义作为本文档的指南，以创建可重复使用的内容以及与适当的“安全手册”的相似之处，都可以被视为一个共同的起点。尽管如此，AUTOSAR Adaptive Platform架构仍将最终成为软件组件的基础，根据ISO 26262第10部分，该软件组件可以被视为一个元素和SEooC。AUTOSAR 自适应平台架构的目标是启用和支持高达 ASIL D 的系统。

图 1：相关项、系统、组件、硬件部件和软件单元的关系图3 - ISO 26262-10 [1]

网络安全

对于自动驾驶的网络安全，预计将产生比过去更大的影响。不仅需要对通信渠道和通信伙伴进行身份验证和验证，还需要确保安全。AUTOSAR 自适应平台的安全概念和功能可在说明性文档 [2] 中找到。本解释性文件仅包含安全主题。相应的项目团队有责任决定是否通过最先进的网络安全措施实现其特定的安全目标。一些与安全相关的安全功能可能是：

安全启动

对车辆网络内以及车外界的通信伙伴进行身份验证

安全密钥交换

安全密钥存储

...

加密，解密和签名等安全特定算法不直接被视为与安全相关，它们仍然需要根据ISO 26262以及网络安全指南和标准进行开发和集成，例如

ISO 21434.

完整性

本文档可能未涵盖可以使用 AUTOSAR 自适应平台的所有可能方案。与安全相关的要求来自一些特定的用例，并得到了AUTOSAR自适应平台工作组所有成员、贡献者和审阅者的最佳选择。

A 缩写

表A.1：缩略语清单

BGlossary

本文档中使用的所有技术术语（此处列出的术语除外）都可以在官方 AUTOSAR 词汇表 [3] 或 ISO 26262 [1] 中找到。

表 B.1：词汇表