1. 什么是功能安全？

1.1 安全三剑客

下图表示了整个汽车操作安全技术体系，可以看到功能安全属于汽车操作安全体系的一部分，除此之外，汽车操作安全中还包括可用性、可靠性、预期功能安全、用户使用安全和信息安全。

可用性 可用性指的是评估特定的用户在特定条件下使用系统、产品或服务以达到特定目标时的有效性、效率和满意度。可用性尤其在侧重人机交互的系统中是一项非常重要的属性。

可靠性 可靠性指的是元件、产品、系统在一定时间内、在一定条件下无故障地执行指定功能的能力或可能性。可靠性同时适用于机械和电子电气系统。

人身安全 人身安全指的是规避汽车操作对驾驶员或者路人或周边车辆内人员（注意不仅是驾驶员）的人身危害。人身安全中包括了功能安全、预期功能安全和用户使用安全。

功能安全，简称FuSa 功能安全指的是不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。功能安全是在汽车电子电气技术基础上发展而来的一项安全技术，对应的标准为ISO 26262。

预期功能安全，简称SOTIF 预期功能安全指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于智能网联汽车技术的一部分，对应的标准为ISO 21448。

用户使用安全 规避由于用户误操作而造成的不合理风险。

信息安全 指的是规避重要信息泄露、被篡改、盗窃或遗失。信息安全同样属于智能网联汽车技术的一部分，对应的标准为ISO/SAE 21434和SAE J3061。

以上安全体系中，功能安全、预期功能安全、信息安全这三者是和IT技术（或者说EE）有关的。这三项安全技术也一起并成为智能网联汽车操作安全性的“安全三剑客”。

三者关系：

功能安全 和信息安全的联系

来自车辆外部的信息安全威胁同样可能会造成人身危害，因此可以将信息安全威胁纳入功能安全的危害源头进行协同分析。

功能安全和预期功能安全的关系

随着智能网联汽车技术的发展，人们发现并不是所有的车辆安全问题都源于系统错误和失效，而是很多时候来源于环境影响或系统本身的功能/性能不足。因系统功能不满足预期而导致的安全风险就是预期功能安全要解决的问题。

功能安全用于解决电子电气失效对人造成的危害，而预期功能安全用于解决系统非故障原因对人造成的危害。ISO 26262标准中对电子电气系统的标称功能及性能没有要求，预期功能安全的存在弥补了这部分遗憾。

1.2 功能安全如何解决问题：

除通常质量管理（QM）外，对汽车E/E系统软硬件全生命周期安全开发流程，方法等进行约束和规范（主要是通过ASIL），尽可能降低人为结构性的系统失效

对控制器硬件部分进行概率化度量，尽可能降低随机硬件失效

除过程约束外，设定安全状态，一旦系统发生故障，在故障容错时间内将系统导入安全状态，避免对人身、财产造成伤害

基于上述三点提出了汽车功能安全法规ISO 26262，属于方法论模型。其定义了部分开发流程、明确了各阶段工作输出产物并给出了一些常用的分析方法。总体上并没明确如何具体操作，这导致功能安全开发相对难以落地，不同开发商对功能安全理解也不尽相同，不同企业产品功能安全无法直接横向对比。

针对一个功能异常，分析出其风险等级，设计出合理的安全措施，实施并验证。

其解决问题的思路：

识别危害 先定义研究对象，找到研究对象实现了哪些系统级别的功能（如加速、减速等），识别这些功能失效时存在的潜在危害（如车辆突然不受控加速，减速等）

评估风险 将功能失效与不同用车场景结合产生危害事件，对其进行风险评估，量化危害（即设定ASIL等级）。危害无法完全避免，ASIL风险越高，重视程度就应该越高。

使用系统工程方式降低风险 利用系统工程学的方法将风险降低到一个可以接受的范围内。方法包含对汽车软件和控制器硬件开发流程进行约束，在可能出现危害的薄弱环节制定相应的安全措施等。ASIL等级越高，约束程度或者安全措施要求越高。

一方面，从设计的角度出发，尽可能避免失效。

另一方面，如果发生了失效，尽早发觉故障，给驾驶员警示故障，让驾驶员可以进行有效干预，或控制车辆系统进入一个安全状态，防止伤害最终产生。

2. ISO26262说人话版本

ISO26262对应的GB_T 34590里面主要就是这个V字模型，主要由概念阶段、产品开发阶段、生产与运行阶段组成。

3-5 相关项

先将汽车功能进行拆分，拆分出的相关项（item）成为后续功能安全分析的对象。相关项定义的本质为确定功能安全研究的对象，相关项 = 结构 + 功能描述 + 对象属性特征

结构: 研究对象是什么，由哪些系统及组件构成

功能描述: 研究对象实现了哪些系统级别的功能，是后续危害分析和风险评估（HARA）基础。

对象属性特征: 对象预期的功能危险，内部以及对外依赖关系（以接口体现），相关法律法规。

对于相关项的拆分，硬件可以按IP拆分，软件则可以按功能或者可被测试的最小单元函数进行拆分，然后定安全目标。

澄清功能安全流程中对于需求的四层管理模型：

3-7 危害分析和风险评估

危害分析与风险识别（Hazard Analysis & Risk Assessment，缩写HA&RA），根据相关项定义的功能，分析其功能异常表现，识别其可能的潜在危害（Hazard）及危害事件（Hazard Event），并对其风险进行量化（即确定ASIL等级），导出功能安全目标（Safety Goal）和ASIL等级，以此作为功能安全开发最初最顶层的安全需求。

相关方法论： 故障模式与影响分析（FMEA）、危险与可操作性分析（HAZOP）、SCE ASIL定级。

危害事件 = 危害 + 运行场景

分析相关项功能异常导致的整车危害（车辆纵向加速、纵向减速、旋转等，或是灯光不够亮、无法加速、无法刹车等）；

将该整车危害放在不同的运行场景中（白天、晚上、高速、低速、上坡、下坡等），组合出危害事件（hazardous event）；

对危害事件进行风险评估，给出风险的量化分析结果，即功能安全等级ASIL-A/B/C/D；

为该相关项输出安全目标，每条安全目标都包含了ASIL安全等级的信息。

危害分析时可以采用HAZOP（Hazard and operability analysis）方法论，使用下图模板

3-8 功能安全

方案

基于安全目标，用系统工程学方法得到功能安全需求与初步的架构假设。过程为从安全目标推导出功能安全要求FSR，将FSR分配至系统架构形成功能安全方案FSC，并将这些功能安全要求分配到项目的要素中。FSR（功能安全要求）基于两个角度定义需求——事前预防 + 事后补救。FSC（功能安全方案）重点是列出为了满足安全目标，需要做的安全措施（一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称）。

相关方法论： 归纳分析法（Inductive analysis）、演绎法（Deductive analysis）、故障模式与影响分析（FMEA）、故障树分析（FTA）

4-5 系统层面

需要将FSR进一步细化为技术层面的安全需求（TSR），即"怎么做"，为后续的软件和硬件的安全开发奠定技术需求基础。安全系统阶段开发内容可以分为两大部分：技术安全需求及方案开发及验证 + 系统集成测试及安全确认（Validation）。系统级产品开发之后，系统分成了硬件与软件两部分。

相关方法论： Fail to safe 安全架构、Fail to operational 安全架构。

技术安全需求（ TSR ） = 由 FSR 技术化的安全需求 + 安全机制 + Stakeholder需求（车辆使用，法律法规，生产和服务方面相关的安全需求）

将技术安全需求描述的功能模块用框图的形式表示出来，即为每一条需求的技术解决方案以框图形式表达。框图的输入、输出接口就是功能模块的输入、输出接口，所有的框图组合在一起形成系统架构图。不同ASIL等级下的设计要求：

安全分析和相关性失效分析 在系统阶段的安全分析需要用到两种分析方法——FMEA、FTA。FMEA和FTA都是以识别系统性失效的原因和系统性故障影响的工具，FTA是演绎分析法，从上往下分析导出安全目标违背的根本原因；FMEA是归纳分析法，从下往上采用故障模型（可采用HAZOP关键字）对可能导致安全目标违背的所有失效模式进行分析。

安全机制应该包含：

检测系统性及随机硬件故障的措施。例如，针对系统I/O，总线信号范围检查，冗余校验，有效性检测，逻辑计算单元数据流及程序流监控，控制器硬件底层软件监控等。

显示故障。例如，对驾驶员进行声音，不同类型及颜色的指示灯，提示文字等预警，增加驾驶员对车辆的可控性。

控制故障的措施。例如，Fail to safe: 将系统在指定的故障容错时间间隔（FTTI）导入安全状态，包括降级，故障仲裁，故障记录等。如果不能，还需要定义紧急运行时间间隔及运行状态。或者Fail to operational，通过并行冗余系统，当一个系统失效后，进入另外一个并行系统继续提供全部或部分功能。

常见的安全机制:

传感器

传感器硬件冗余

独立供电

多通道冗余采集

信号质量检测

控制单元

在线诊断

比较器

多数投票器

执行器

执行器硬件冗余

执行器控制信号质量检测

通讯

冗余发送

信息冗余（CRC）

时间监控

问答机制

传感器与执行器的安全设计

对于传感器与执行器，通常采用硬件冗余机制实现高级别的ASIL要求。

传感器硬件冗余采集，可以是利用相同的两个传感器，对同一信号进行重复采集，也可以是利用不同类型传感器，对强相关的两个信号分别进行采集

执行器属于系统功能实现终端，执行器冗余会极大增加系统成本，一般在Fail to operational 安全架构中才会采用。

控制单元安全设计

在系统级产品开发阶段，对控制单元的安全设计主要在 Fail to safe 与 Fail to operational 两类安全架构上。而不是控制器硬件冗余、CPU Dual Core LockStep、看门狗、程序流监控等（这些都是后续流程中的软件或硬件安全机制）。

Fail to safe最典型的应用就是在线监控，将整个控制单元分为功能实现和在线监控两部分，即所谓的的1oo1D类型系统，具体如下图所示:

特点是一旦发现问题，就将系统导入安全状态，停止提供系统原有功能或者维持最必要的功能。

Fail to operational 属于相对高级的安全架构，比较器和多数投票器都属于这类安全架构，整个系统由相对独立的两条或多条功能链路构成，每条功能链路都拥有自己独立的传感器，控制单元，甚至执行器。可以实现1oo2D安全架构，如下图所示:

特点是当其中一条功能链路出现异常，控制系统可以切换到其他功能链路，保证系统继续正常工作或者降级运行。

5-5 硬件级产品开发

基于系统设计规范，硬件开发过程以v模型概念为基础，左侧为硬件需求说明、硬件设计与实现，右侧为硬件集成与验证。核心在于分析并实现硬件安全机制。 相关方法论： FMEDA（ISO 26262中基于概率论的定量危害分析仅限适用于硬件部分，因为只有硬件存在随机失效，并符合概率分布原理。）

6-5 软件层面

根据系统设计规范，软件开发过程以v模型的概念为基础，软件需求规范和软件架构设计与实现在左侧，软件集成与验证在右侧。核心在于分析并实现软件安全机制。

相关方法论： 半形式法架构设计、FFI免干扰设计

上面的只是一个开发流程，在正规的软件公司里面基本也是按照这个方法开发软件的。

软件安全机制包括:

与应用软件本身、基础软件或操作系统失效探测、指示和减轻有关的自检或监控功能。

例如: 应用层软件程序流监控，输入，输出合理性检测等; 基础软件自检等。

与安全相关硬件要素故障探测、指示和减轻相关的功能。

例如: 涉及基础软件相关安全机制，包括控制单元电源，时钟，内存等硬件要素故障信息探测，指示和控制。

使系统达到或维持安全状态或降级状态的功能。

例如: 错误管理，安全状态等。

6-6 软件架构安全设计要求

根据不同的软件分层，软件架构安全设计基本分为两大部分：

功能监控层安全设计

基础软件安全设计

功能监控层安全设计

在功能监控层软件架构设计，主要是将和架构相关的错误探测和错误处理等安全机制，应用于功能监控层架构设计。虽然根据不同类型的控制器，其安全机制具体实施有所差别，但总体而言，主要包含以下安全机制：

用于错误探测的安全机制包括：

输入输出数据的范围检查；

合理性检查（例如，使用期望行为参考模型、断言检查、或不同来源信号比较）；

数据错误探测（例如，检错码和多重数据存储）；

外部要素监控程序执行，例如，通过专用集成电路（ASIC）或者其他软件要素来执行看门狗功能。监控可以是逻辑监控或时间监控，或者两者的结合；

程序执行的时间监控；

设计中的异构冗余；

—在软件或硬件中实施的访问冲突控制机制，与授权访问或拒绝访问安全相关共享资源有关。

用于错误处理的安全机制可能包括：

为了达到和维持安全状态的功能关闭；

静态恢复机制（例如，恢复块、后向恢复、前向恢复以及通过重试来恢复）；

通过划分功能优先级进行平稳降级，从而最小化潜在失效对功能安全的不利影响；

设计中同构冗余，主要侧重于控制运行相似软件的硬件中瞬态故障或随机故障的影响（例如，软件在时间上的冗余执行）；

基础软件安全设计

基础软件多和控制器硬件相关，是保证上层软件（应用层，功能监控层）正常运行基本条件。

整个基础软件全部依据最高ASIL等级开发成本过高，通常采用Partition分区方式，使用免于干扰（FFI）分析法，是不同ASIL等级的要素共存。

为了实现非或不同ASIL等级要素共存，需要在基础软件部分采用相应的安全措施，避免高ASIL等级软件受到低ASIL等级或QM软件的干扰，进而破坏安全需求，具体如下图所示:

以MCU的系统软件为例，研究FFI干扰类型与对应的安全机制：

执行和时序（Timing &Execution）干扰 如执行阻塞 （blocking of execution）、死锁 （deadlocks）、活锁 （livelocks） 等 对应的安全机制有内外部看门狗（Internal/External Watchdog）、程序监控（Program Flow Monitor）等

内存（Memory）干扰 如内容损坏（corruption of content）、堆栈溢出或下溢（stack overflow or underflow）等 对应的安全机制有使用内存保护单元（Memory Protection Unit , MPU）来实现内存分区等

信息交换（Exchange of information）干扰 如信息重复 （repetition of information）、 信息丢失 （loss of information）、信息损坏 （corruption of information）等 循环冗余校验（cyclic redundancy check）、E2E保护 （End2End Protection）等

避免软件要素间的相互干扰，软件要素间干扰的形式主要有两类：

时序干扰

空间干扰

时序干扰可能存在以下几种形式：

执行阻塞 （blocking of execution）

死锁 （deadlocks）

活锁 （livelocks）

执行时间的不正确分配 （incorrect allocation of execution time）

软件要素间的不正确同步 （incorrect synchronization between software elements）

空间干扰包括内存存储干扰以及信息交换干扰，常见的形式为：

内容损坏 （corruption of content）

对已分配给其他软件要素的内存进行读写访问 （read or write access to memory allocated to another software element）

信息重复 （repetition of information）

信息丢失 （loss of information）

信息延迟 （delay of information）

信息插入 （insertion of information）

信息伪装或信息的不正确寻址 （masquerade or incorrect addressing of information）

信息次序不正确 （incorrect sequence of information）

信息损坏 （corruption of information）

对于空间干扰，常见的措施是使用内存保护单元（Memory Protection Unit , MPU）来实现软件分区。

MPU是微控制器上的一个特殊硬件，它可以限制和监视对存储器映射表某些地址范围的访问。当MPU检测到对保护区的任何写入或执行访问时，该访问将被阻止，并进入相应的安全状态。

MPU实现软件分区应满足如下要求：

一个软件分区内的任务彼此之间不能免于干扰。

一个软件分区不能改变其他软件分区的代码或数据，也不能控制其他软件分区的非共享资源。

一个软件分区从共享资源获取的服务不能被另一个软件分区影响。这包括相关资源的性能，以及对资源调度访问的使用率、延迟、抖动和持续时间。

ECU的内存由以下三部分组成：

ROM （Read Only Memory）程序存储器

RAM （Random Access Memory）随机访问存储器

EEROM（Electrically Erasable Programmable Read-Only Memory）电可擦编程只读存储器，或者称为Flash

由于ROM不会被修改，因此MPU对内存分区主要运用于RAM和Flash。

6-7 设计行为规范

ISO 26262对功能安全相关的软件架构设计，还根据不同ASIL等级提出了其他相关约束，包括:

软件架构细致程度应能够承载SWSR。

软件架构设计原则，包括: 适当分层，限制软件组件规模和复杂度，限制接口规模，组内高内聚，组间低耦合，限制中断使用等。

软件架构设计验证方法，包括: 设计走查，设计检查，控制流，数据流分析，仿真，快速原型等。

HWSR应被分配至软件架构中的组件。

不同或非ASIL等级软件组件开发需满足以下原则之一:

按最高ASIL等级。

要素共存FFI，例如软件分区。

对SWSR和具体实施之间的可追溯性。

软件架构包含静态和动态方面的，静态方面的主要和不同软件单元之间的接口：1）软件结构包括其分级层次；

2） 数据处理的逻辑顺序；

3） 数据类型和它们的特征参数；

4） 软件组件的外部接口；

5）软件的外部接口及 约束（包括架构的范围和外部依赖）。

动态方面的涉及：

1）功能和行为；

2）控制流和并发进程；

3） 软件组件间的数据流；

4） 对外接口的数据流时间的限制。

6-8 单元设计和实现的要求

软件单元的实现包含源代码生成和转换为目标代码。

6-11 安全验证与测试

ISO 26262-6:2018针对软件单元验证，集成验证，嵌入式软件验证这三部分内容分别进行了阐述，并根据不同的ASIL等级对其验证方法进行推荐，具体见下面三个表格:

测试方法，可以从测试类型的角度，将以上测试方法分为:

静态分析（Static Analysis）

动态分析（Dynamic Analysis）

对于功能安全软件安全测试，软件单元验证，集成验证，嵌入式软件验证对应测试类型如下:

单元验证: 静态分析 + 动态分析，静态为主

集成验证: 静态分析 + 动态分析，动态为主

嵌入式软件验证: 动态分析

静态分析

静态测试属于最基本的测试，是指不用执行程序的测试，它主要采取代码走查、技术评审、代码审查等方法对软件产品进行测试，它主要包括：

─ 走查，结对编程，检查

─ 控制流分析

─ 数据流分析

─ 静态代码分析

动态分析

动态分析是指实际运行程序，并通过观察程序运行的实际结果来发现错误的软件测试技术，它包括了以下几个方面：

软件/代码是否做了它应该做的?

基于需求测试

接口测试

Back-to-Back测试

软件/代码是否做了它不应该做的?

鲁棒性测试

软件/代码是否足够?

结构覆盖性测试

覆盖率，功能安全规范中多次提到了各种覆盖率的概念，这里做一个汇总。

为了评估验证的完整性并提供证据证明已有测试用例已充分实现相应测试目标，必须对测试完整性进行评估，这里就得提到覆盖率这个概念。覆盖率用于度量我们设计的测试用例在多大程度上可以覆盖我们的代码，包括代码的语句，函数，分支等等。因此覆盖率又可以进一步分为:

语句覆盖率: 用于统计每个代码语句被测试用例执行的比例

分支覆盖率: 用于统计每个判定分支（即If...else等）被测试用例执行的比例

函数覆盖率: 用于统计代码中所有函数被测试用例执行的比例

调用覆盖率: 用于统计每个函数调用端被测试用例执行的比例

MC/DC（修改条件/判定覆盖率） : 这个比较复杂，单独来讲

MC/DC是分支测试的进一步补充，适用于判定类代码覆盖检测，它要求较为复杂:

在一个程序中每一种所有可能的输入和输出至少出现一次。

每一个判定中的每一个条件必须能够独立影响判定输出，即在其他条件不变的前提下，仅改变条件中一个值，而使判定结果改变。

看个实例。例如，对于测试对象:

理论上，对于三个输入判定条件（A, B, C），一共存在8种测试Case，为实现MC/DC全覆盖，其实只需要以下4个测试用例，即Case1 - 4，就能使得A，B，C输入和判定输出结果true和false都出现一次，且只要A，B，C一个条件值发生改变，就会最终判定结果发生变化。

所以，MC/DC较复杂，但错误检出率高，适合那些大型的并且要求测试非常精确的软件测试。

7-6 运行、服务与报废

这一阶段涉及确保产品或元件在生产、操作、服务和退役方面的功能安全的过程、手段和指示。考虑了与安全有关的特殊特性以及项目或元件的生产、运行、服务（维护和维修）和退役的说明书的制定和管理。

后记：

本文用中文的表述让大家更加明白功能安全ISO26262到底该怎么做，原则和方法及流程是什么。

当我们去审视我们的软硬件的时候就会去思考哪里会出问题，怎么样才能更安全，然后用这些原则和方法去制定特定的技术方案，下一节会继续讲具体的软硬件设计的时候该注意什么，当然在工作中我们可能只负责一个小模块，那也不妨碍我们有功能安全的思维去审视我们的设计，尽管可能仅仅做了一个故障上报处理或者故障纠错的功能，形成合力可以助力我们过ASIL-D。