参考链接

术语

基础概念

术语（中文）	术语（英文）	缩写	定义/描述
功能安全	Functional Safety	FS	系统或设备在执行功能时避免不可接受风险的能力。
安全完整性	Safety Integrity	SI	系统执行安全功能的可靠性水平。
风险	Risk	无	危害发生概率与严重性的组合。
危害	Hazard	无	可能导致伤害或损害的潜在事件。
可接受风险	Acceptable Risk	无	被认为可以容忍的风险水平。
残余风险	Residual Risk	RR	实施安全措施后剩余的风险。
安全状态	Safe State	无	系统失效时不会造成危害的状态。

安全等级与标准

术语（中文）	术语（英文）	缩写	定义/描述
安全完整性等级	Safety Integrity Level	SIL	衡量安全功能可靠性的等级（SIL 1-4）。
汽车安全完整性等级	Automotive Safety Integrity Level	ASIL	汽车行业安全等级（QM 至 ASIL D）。
安全目标	Safety Goal	SG	为避免危害设定的顶层安全要求。
安全需求	Safety Requirement	SR	实现安全目标的具体要求。

失效与故障

术语（中文）	术语（英文）	缩写	定义/描述
失效模式	Failure Mode	FM	系统或组件可能失效的方式（如短路）。
单点故障	Single Point Failure	SPF	一个故障导致安全功能失效。
系统性失效	Systematic Failure	无	人为错误（如设计失误）导致的失效。
随机硬件失效	Random Hardware Failure	RHF	硬件老化或不可预测因素导致的失效。
危险失效	Dangerous Failure	DF	可能导致危害的失效。
安全失效	Safe Failure	SF	不导致危害的失效。
共因失效	Common Cause Failure	CCF	多个组件因同一原因同时失效。
独立失效	Independent Failure	无	无关联的单独失效事件。
失效概率	Probability of Failure	PoF	系统或组件失效的统计概率。
失效频率	Failure Rate	FR	单位时间内失效的频率。

安全机制与设计

术语（中文）	术语（英文）	缩写	定义/描述
安全功能	Safety Function	SF	为降低风险而设计的功能（如紧急停机）。
容错	Fault Tolerance	FT	系统在故障时仍能执行安全功能的能力。
失效保护	Fail-Safe	FS	系统失效时进入安全状态的设计特性。
冗余	Redundancy	无	添加额外组件以提高可靠性。
安全机制	Safety Mechanism	SM	用于检测或控制失效的措施。
失效检测	Failure Detection	FD	识别系统故障的过程或技术。
失效缓解	Failure Mitigation	无	减少失效后果的措施。
硬件故障裕度	Hardware Fault Tolerance	HFT	系统容忍硬件故障的能力。

系统与评估

术语（中文）	术语（英文）	缩写	定义/描述
安全相关系统	Safety-Related System	SRS	与安全功能执行直接相关的系统。
非安全相关系统	Non-Safety-Related System	NSRS	不直接影响安全功能的系统。
诊断覆盖率	Diagnostic Coverage	DC	系统检测潜在故障的能力（百分比）。
平均无故障时间	Mean Time Between Failures	MTBF	系统平均连续无故障运行时间。
平均失效前时间	Mean Time To Failure	MTTF	系统从开始运行到首次失效的平均时间。
危害分析与风险评估	Hazard Analysis and Risk Assessment	HARA	识别危害和评估风险的方法。
失效模式与影响分析	Failure Mode and Effects Analysis	FMEA	分析失效模式及其影响的方法。
故障树分析	Fault Tree Analysis	FTA	用树形图分析失效原因的方法。
事件树分析	Event Tree Analysis	ETA	分析事件后果的逻辑方法。

管理与过程

术语（中文）	术语（英文）	缩写	定义/描述
安全生命周期	Safety Lifecycle	SLC	从设计到退役的整个安全过程。
功能安全管理	Functional Safety Management	FSM	确保功能安全的过程和组织措施。
安全计划	Safety Plan	SP	实施功能安全的详细计划。
安全案例	Safety Case	SC	证明系统安全的论证和证据集合。
配置管理	Configuration Management	CM	管理设计和开发中的变更。
工具认证	Tool Qualification	TQ	验证开发工具的适用性和可靠性。
验证	Verification	无	确认系统是否按设计正确构建。
确认	Validation	无	确认系统是否满足安全需求。
安全审计	Safety Audit	SA	检查安全过程和系统的独立评估。
安全文化	Safety Culture	无	组织对安全的重视和行为模式。
可追溯性	Traceability	无	需求、设计和验证之间的可追踪关系。
安全测试	Safety Testing	ST	验证安全功能的测试活动。

概述

为什么需要功能安全？

在这个世界上，人和物都不是完美的。(愿望很美好，现实很残酷）

人不是完美的 => 系统性失效

汽车开发工程师在汽车E/E系统开发中，包括软件和控制器硬件，不可避免地存在人为疏忽或错误，引起系统功能功能失效，进而导致故障并产生危害。这部分人为疏忽导致的失效为系统性失效。(注: 硬件也有系统失效)
物不是完美的 => 随机硬件失效

制器硬件，由于自身老化，外部环境因素等引发功能失效，导致相应故障并产生危害。硬件失效带有随机性，符合一定概率分布，因此称为硬件随机失效。

为了避免上述两种失效，功能安全由此诞生。

功能安全在解决什么问题？

除通常质量管理(QM)外，对汽车E/E系统软硬件全生命周期安全开发流程，方法等进行约束和规范(主要是通过ASIL)，尽可能降低人为结构性的系统失效
对控制器硬件部分进行概率化度量，尽可能降低随机硬件失效
除过程约束外，设定安全状态，一旦系统发生故障，在故障容错时间内将系统导入安全状态，避免对人身、财产造成伤害

汽车功能安全法规

ISO 26262: 2018版，属于第二版

下载链接: ISO 26262-2018
中文国标: GB/T 34590，于2017年发布，属于ISO 26262第一版的中文版，英文不是太好的朋友可以先看中文版，但和 ISO 26262: 2018最新版存在一定差异

下载链接: GBT-34590

ISO 26262属于方法论模型，抽象又具体:

抽象在于: 除了个别开发流程方法外，其他过程并没明确如何具体操作，这导致功能安全开发相对难以落地，不同开发商对功能安全理解也不近相同，不同企业产品功能安全无法直接横向对比。

具体在于: 开发大的流程及工作输出产物明确，和ASPICE过程参考模型相比还是具体很多。

可能是其魅力吧！通过抽象又具体的方法论，一方面对功能安全开发大的流程和方法提供了指南，另一方面，考虑了不同企业技术及Know How差异，为技术施行多样性提供了可能。

汽车功能安全特点

汽车功能安全特点包括:

旨在尽可能避免由系统功能异常导致的危害，不是为了提高系统原有功能或非安全性能(如动力性)或避免系统本身功能不足导致的危害(属预期功能安全)
不关注本质安全(即通过消除危险的原因确保安全的方式)
既基于系统功能实现(基于现有功能进行危害分析和风险评估，定义目标及安全需求并采取安全措施)，又有所区别(一般独立开发，ASIL要求贯穿全过程，直接决定功能安全开发工作量和内容)
系统，软件，硬件开发遵寻各自V模型，都是从需求，到架构，再到设计实现，最后验证及系统确认(确认只有在系统层面)。为了加速迭代过程，可以和敏捷过程相结合(后续细聊)

功能安全真的有必要吗？

虽然目前大部分开发商对功能安全越来越重视，但对很多企业而言，功能安全难以落地，投入产出比不高，项目进度受阻等等。因此，也有一些质疑的声音，如：

为了覆盖极少数可能发生的安全问题，功能安全是否在浪费项目开发时间和资源？
标准化的安全规范ISO 26262是否必须执行？

针对以上相关问题，以下仅谈谈我个人看法：

安全问题重视程度取决于企业价值排序。个人觉得，安全第一，须竭尽全力保障汽车产品安全，先发布再以牺牲用户利益为代价的市场测试，至少有违道德
条条道路通罗马，ISO 26262只是其中一条，非强制执行。只要企业安全文化到位，产品开发流程有效覆盖功能安全问题，也能走出自己的一条功能安全之路
规范的存在既是门槛，也是为了让普通工程师在规范的约束下，有可能开发出一流的符合功能安全的产品(我这么说不要打我，我也是普通工程师)
功能安全不是形式主义，不为死抠标准，不为通过评审而做，不会短期见效，却能避免企业陷入重大安全召回
系统优化企业组织架构和交流接口，优化开发流程，将功能安全融入企业各自开发流程中，实现不同平台，项目间的最大化复用，是功能安全实施的关键之一

概念阶段

ISO 26262 基于V模型，汽车功能安全开发活动始于概念阶段，该阶段主要包含以下内容:

相关项定义(Item Definition)，即定义研究对象
危害分析和风险评估(HARA)，即导出安全目标及ASIL等级
功能安全方案开发(FSC)，即形成系统化概念阶段工作方案输出

什么是概念阶段开发？

很多朋友可能疑惑，为啥它叫概念阶段，听着好像很不专业，接下来我们来看它的本质。

汽车产品开发基于需求，需求是产品开发的基础。好的需求一定程度直接决定产品性能和质量，对汽车功能安全开发也不例外。

我们所熟知的功能实现的需求多源于用户需求，而功能安全开发的需求源于功能实现部分。

在不同开发阶段，需求根据其细化程度可分为:

功能层面的需求: 相对抽象的逻辑功能需求(就是大爷大妈们也能看得懂)，需细化至技术需求
技术层面的需求: 技术可实施的需求，可直接转化为软硬件开发

功能安全概念阶段开发本质就是，在相对抽象的逻辑功能层面，通过安全分析提出功能安全开发最初的安全需求。因此，被称为概念阶段。

具体而言，就是通过对相关相所实现的功能进行危害分析和风险评估(HARA)，导出功能安全开发最初安全目标(Safety Goal)以及功能安全需求(FSR)。

HARA

简单来说，HARA(Hazard Analysis and Risk Assessment)是在概念阶段为导出功能安全目标及其ASIL等级的系统安全分析方法。

具体而言，根据相关项定义的功能，分析其功能异常表现，识别其可能的潜在危害(Hazard)及危害事件(Hazard Event)，并对其风险进行量化(即确定ASIL等级)，导出功能安全目标(Safety Goal)和ASIL等级，以此作为功能安全开发最初最顶层的安全需求。

HARA流程

话不多说，直接上图:

HARA流程

危害分析

==目的==

利用安全分析方法(例如FMEA，HAZOP)，对相关项定义的功能进行分析识别危害和危害事件。

==方法==

FMEA故障识别部分和HAZOP(Hazard and operability analysis)无本质区别，流程基本类似。

一般来说，HAZOP操作更为简单，多用于功能安全概念阶段识别相关项功能存在的潜在危害及危害事件。步骤如下：

利用HAZOP分析相关项所定义的系统层面功能异常表现(非组件层面，功能安全需求分析才基于具体组件功能)

HAZOP基于定义的功能，使用以下规定的引导词，分析每个功能的异常表现：
- 功能丧失: 在有需求时，不提供功能；(如车辆非预期加速)
- 在有需求时，提供错误的功能：
  - 错误的功能: 多于预期； (如车辆加速大于驾驶员需求)
  - 错误的功能: 少于预期； (如车辆加速小于驾驶员需求)
  - 错误的功能: 方向相反；(如驾驶员要求加速，车辆出现减速)
- 非预期的功能: 无需求时，提供功能；(如驾驶员无加速需求，车辆提供加速度)
- 输出卡滞在固定值上: 功能不能按照需求更新。(如驾驶员需先加速后减速，车辆一直提供加速)
[!note]

对每个功能分析不一定会用到所有引导词，可对其进行裁剪。

功能异常分析举例:

针对车辆转向系统转向功能，根据HAZOP引导词分析，其功能异常表现有: 非预期转向，转向不足，过度转向等。
步骤二: 将危害和运行场景结合，形成危害事件
$$
危害 + 运行场景 = 危害事件
$$
- 危害是抽象的可能性，不可量化，需结合不同运行场，形成具体的危害事件
- 运行场景即车辆运行环境，包括道路场景(例如道路类型，路面附着情况等)和驾驶场景(运行状态，车速等)。J2980提供了场景分类参考，分析中需确保危害最大化化的运行场景。
- 同一危害在不同的运行场景下，形成危害事件的严重性，出现的频率及对其危险的可控性不同，即ASIL等级不同
例如: 车辆非预期转向这一危害，在不同车速下和道路环境下，可能和周边基础设施或人发生碰撞，可能和迎面驶来汽车碰撞，也可能发生侧翻等等，造成的伤害是不一样的，这也是为什么需要将危害量化为危害事件的重要原因。

危害分析注意事项及约束:

危害和危害事件定义必须基于整车层面，例如危害:非预期的车辆加速
只考虑将定义的相关项功能造成的危害并假设其他相关项正常工作
不应考虑将要实施或已经在前代相关项中实施的安全机制，例如功能监控，硬件冗余等
需考虑相关项外部措施，例如其他相关项内的ESP，ASB或安全气囊，灭火器等
功能失效和相应的危害之间的关系: 多对一，一对多
需要考虑合理的误操作造成的危害，例如驾驶安全距离保持不够

ASIL等级

评价危害事件的风险，即ASIL等级。首先，通过以下三个参数，对其进行赋值，对危害事件的风险进行量化评估：

严重度（Severity）
暴露度（Exposure）
可控度（Controllability）

具体定义和取值见ISO 26262-3:2018，其中：

严重度主要根据AIS分级，关注对人造成伤害的严重程度(非对物体的伤害)。不仅需考虑车内驾驶员乘客伤害，还需考虑外部环境中的人员，包括行人，其他车辆人员伤害等
暴露度可基于持续运行时间占比或发生频率确定，不应考虑装备该相关项的车辆数量或占比
可控度可控性受多种因素影响，需驾驶员进行合理假设(例如健康，有驾照)，相对比较难量化，对于C2及C3基于一定样本的用户测试决定
三个参数一般根据ISO 26262-3:2018附录并结合经验，统计数据，仿真，测试等确定。如果存在不确定性，可以适当考虑取较大的值
不同企业对同一危害事件的风险量化，即三个参数数值确定，可能不尽相同，审核的重点在于有理有据，合理即可

然后，根据ISO 26262-3:2018，Table 4 ‒ ASIL determination得到每个危害事件的安全等级ASIL。ASIL等级定义了对相关项功能安全开发必要的要求和安全措施，其中，D代表最高严格等级，A代表最低严格等级。QM属于一般质量管理。

为了免去查表的麻烦，这里分享个简单的ASIL等级计算公式：

$$
S + E + C =10 => ASIL D\
S + E + C = 9 => ASIL C\
S + E + C = 8 => ASIL B\
S + E + C = 7 => ASIL A\
S + E + C < 7 => QM
$$

安全目标

危害事件的反面即为安全目标，其中:

可以对相似的危害事件进行组合和分类，再导出安全目标，以此降低分析工作量
针对分类后的每一个危害事件导出对应的安全目标
若导出的安全目标存在相似，可对其进行合并，并继承其中最高的ASIL等级

FSR&FSC

什么是FSR

功能安全需求(Functional Safety Requirements, FSR)是我们在概念阶段最常听到的概念之一，那什么是FSR呢？

功能安全目标(SG)属于基于车辆或系统级别的安全需求，过于抽象，我们需要将其进行细化，得到为满足安全目标，基于组件级别的相对比较具体的，但依旧还是基于功能层面的逻辑功能需求，这个就是FSR。

大家可能好奇，为什么非要搞得这么麻烦，直接细化到技术层面，信号层面不好吗?

是的，不好！一方面，研究分析工作需要循序渐进，一口吃不成大胖子，对于简单或者非常熟悉的研究对象，在大牛加持下可能可以直接从安全目标导出技术层面的安全需求，但对于大部分系统或者大部分工程师而言，这个很难做到，很容易出现错误或缺失。另外一方面，没有中间工作产物，功能安全评审也过不了。

那么我们应该从哪些方面去定义组件层面的功能安全需求或者功能安全需求应该解决哪些问题呢？根据ISO 26262-3-2018，功能安全需求应该针对以下几个方面，提出相应功能级别的解决方案，作为FSR:

故障预防
故障探测，控制故障或功能异常
过渡到安全状态
容错机制
发生错误时功能的降级及与驾驶员预警的相互配合
将风险暴露时间减少到可接受的持续时间所必需的驾驶员预警
驾驶员预警，以增加驾驶员对车辆的可控性
车辆级别时间相关要求，即故障容错时间间隔，故障处理时间间隔，和仲裁逻辑，从不同功能同时生成的多种请求中选择最合适的控制请求。

如何理解呢？通俗的讲，FSR无非就是基于以下两个角度定义安全需求:

事前预防: 从设计的角度出发，为尽可能避免系统中软件和硬件相关的失效，系统中的组件应该实现或具备哪些功能。
事后补救: 如果系统还是发生了失效，及时探测，显示，控制故障。尽早给驾驶员警示故障，让驾驶员有效干预，或控制车辆系统进入一个安全状态，防止或减轻伤害产生。

此外，针对FSR，还需要注意以下几点:

FSR本质是需求，一般是甲方(主机厂)对供应商提出的安全要求，只考虑为满足安全目标及ASIL等级，系统应该怎么正常工作，不涉及具体的技术实现方式。
针对每个SG，应该至少导出一个FSR。
FSR应该继承对应安全目标的ASIL等级。如果存在ASIL等级分解，则需要遵循ISO 26262-9:2018中独立性(Independence)要求。(注意独立性和免于干扰(FFI)的区别)
如果FSR涉及事后补救措施，则该FSR需要定义相应的安全状态，故障容错时间间隔(如果安全状态需要过渡，还需定义紧急运行时间间隔)。很多朋友搞不清楚到底这些东西属不属于安全需求。
FSR需要分配至系统架构，并作为FSC的组成部分，这个我们后续详细介绍。

例如，功能安全需求示例: 制动踏板开度必须正确反映驾驶员制动意图(ASIL D)。至于应该采用什么传感器，具体怎么反应意图都不是功能层面考虑的问题。

什么是FSC

Functional Safety Concept(FSC)一般翻译为功能安全方案或概念，个人觉得功能安全方案更合理些，FSC本质上是概念阶段所有开发工作进行系统化汇总后形成的工作输出产物。

ISO 26262 对FSC定义比较模糊，即为了满足安全目标，FSC包括安全措施(含安全机制)。

那到底什么是安全措施(Safety measure)呢? 它和安全机制(Safety mechanism)有什么区别，这里给朋友们做个辨析:

安全措施: 事前预防+事后补救，较为广泛，一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称。
安全机制: 事后补救部分，只是安全措施的一部分，针对系统功能出现异常后，为探测，显示，控制故障的所采取的措施。一般涉及具体技术手段，在概念阶段不做具体要求，在系统阶段进行定义。

所以理论上讲，只要是为保证相关项功能安全，所有在功能层面采取的解决方案都属于功能安全方案。一般来讲，一个完整的FSC应该包含以下主要内容:

FSC概念

其中，安全状态主要包括: 关闭功能，功能降级，安全运行模式，Limp Home等Fail to safe策略，目前Fail to operational，如冗余运行等策略相对较少。

系统一旦违反安全目标，安全机制必须在容错时间间隔(FTTI)将系统转移到安全状态。

这里简单说说怎么确定故障容错时间间隔(FTTI):

一般可以根据安全目标所对应的代表性危害事件(一般是ASIL等级最高的危害事件)，通过对应运行场景定量或定性评估得到，包括历史数据，仿真计算，实际测试等。

在实际操作中，如果难以计算确定，可以根据经验对其进行预设，然后对代表性危害事件进行实车运行场景模拟，最后根据测试数据和安全确认指标(Validation criteria)确定假设合理性。

对于ASIL等级较高的安全需求，理论上都应该进行车辆测试确认。

最后聊聊，FSR和FSC形式和书写工具问题:

FSR一般都是直接包含在FSC之中，多采用需求管理或者文本工具，如Doors，Word进行书写和管理，方便进行版本管理和评审。
FSC内容没有统一的结构要求，将所需内容合理组织形成输出结果且保证分析结果可追溯性即可。

怎么从SG得到FSR

和安全目标(SG)导出，即HARA过程相比，从安全目标(SG)到功能安全需求(FSR)，也需要进行安全分析，其区别在于:

安全分析的对象基于组件层次，非车辆或系统级别。
除了归纳分析法(Inductive analysis)，还可采取演绎(Deductive analysis)分析方法。

其中，FMEA(Failure Mode and Effects Analysis, 即失效模式与影响分析)和FTA(Fault Tree Analysis, 即故障树分析)是归纳和演绎最具代表性的分析方法，也是功能安全开发最常用的安全分析方法。

==FMEA==

典型的归纳分析法: 是从多个个别的事物中获得普遍的规则。
定性分析。
自下而上，从原因到结果，即从可能的故障原因，分析可能的危害结果。

==FTA==

典型的演绎分析方法: 从已知的定律经过逻辑推演得到新的定律的方法。
定性和定量分析，概念和系统阶段多定性分析，硬件度量分析多定量分析。
自上而下，从结构到原因，即从危害结果或事件，分析可能导致其产生的原因。

从SG到FSR，多采用FTA分析方法进行分析，主要原因在于:

首先，FMEA在设计阶段一般指DFMEA，即Design FMEA。FMEA一般用于产品设计或工艺在真正实现之前，对其进行安全分析发现产品弱点，并优化改进。所以FMEA意味着事件发生之前的行为，尽可能避免危害产生，只包括事前预防，这一点和功能安全安全机制需求完全不同，事后补救是功能安全重要的保证安全的措施。
其次，FTA自上而下，从结果到原因的分析方法和从SG到FSR的导出方向一致，操作更为便捷，更容易完整地识别故障原因和影响。

那接下来我们一起看看FTA操作步骤:

步骤一: 确定分析边界，包括分析对象，范围，抽象级别。
步骤二: 选择分析的故障，即顶部事件，通常将违反的安全目标(SG)作为FTA顶层事件。
步骤三: 根据顶层事件，确认直接，必要和充分导致故障产生的原因，建立故障树，直至分析的最低抽象级别，即底层基本事件(对于FSR，一般为组件级别，如传感器，执行器，控制单元等) 。
步骤四: 根据底层基本事件，采取安全措施以消除相关故障路径，制定相应的FSR。

FSR分配至系统架构

根据ISO 26262-3-2018要求，FSR必须分配至系统架构，作为FSC的重要组成部分。其主要目的在于:

将不同安全目标对应的安全需求及ASIL落实到架构中具体的软件或硬件组件当中去，进而确定不同组件开发对应的所有安全需求及最高ASIL等级要求，以便于后续系统，软件和硬件的进一步开发。
架构作为需求和具体软/硬件实现之间的桥梁，是基于模型的系统工程开发(MBSE)重要内容，能有效改善基于文本或文档开发的弊端，实现模型统一的管理，维护，及需求和测试的可追溯性，可验证性。

一般来讲，系统架构一般采用通用化建模语言UML或SysML在相关架构开发软件，如Enterprise Architect， Cameo等，进行开发，作为功能安全概念开发的输入内容。但可惜的是，目前大部分车企都没有完整的系统架构或多基于PowerPoint等形式的简单架构描述。这就导致一方面安全分析没有办法依据架构开展，另一方面，没有办法将安全需求分配至系统架构。

架构是门艺术，是当前软件定义汽车大背景下，解决系统及软件复杂度一大利器。

系统阶段

技术安全需求(TSR)及安全机制

我们在概念开发阶段，通过组件层别的安全分析(FTA, FMEA)对功能安全开发最初的安全需求，即安全目标(SG)，进行细化，得到了组件级别的功能安全需求(FSR)和方案(FSC)。

但FSR本质上还是属于功能层面的逻辑安全需求，属于"需要做什么"的层次，无法具体实施，所以需要将FSR进一步细化为技术层面的安全需求(TSR)，即"怎么做"，为后续的软件和硬件的安全开发奠定技术需求基础。

根据ISO 26262，功能安全系统阶段开发内容可以分为两大部分:

技术安全需求及方案开发及验证
系统集成测试及安全确认(Validation)

它们在开发过程中并不连续，分别隶属于系统开发V模型的左边和右边，中间穿插了硬件和软件开发。系统阶段技术安全需求(TSR)和方案(TSC)开发和概念阶段功能安全需求(FSR)和方案(FSC)一脉相承，和概念开发开发紧密衔接。只有硬件和软件开发完成，才能进行系统层面集成测试和需求确认。

针对第一个大的部分，即技术安全需求(TSR)和方案(TSC)，我们主要聊以下内容:

什么是技术安全需求TSR
安全机制的本质
怎么从FSR到TSR
什么是技术安全方案TSC
系统安全架构设计
安全分析
技术安全需求分配至系统架构

什么是TSR

总体而言，技术安全需求(TSR: Technical Safety Requirement)是为满足安全目标SG或功能安全需求(FSR)，由功能安全需求(FSR)在技术层面派生出的可实施的安全需求。

那到底什么是由FSR派生出的技术安全需求呢？

根据ISO 26262的定义，技术安全要求(TSR)应该明确功能安全需求在各自层级的技术实现; 考虑相关项定义和系统架构设计，解决潜在故障的检测、故障避免、安全完整性(即满足ASIL等级)以及产品生产和服务方面的必要安全问题。

公式如下：
$$
技术安全需求(TSR) = 由FSR技术化的安全需求 + 安全机制 + Stakeholder需求
$$
==由FSR技术化的安全需求==

将FSR进一步技术化，得到可以实施的技术安全需求，是TSR的重要来源，但它只是TSR其中一个组成部分。

所谓FSR技术化的安全需求就是，基于系统架构中组件分配得到的FSR，根据该组件内部以及对外的依赖关系和限制条件，将FSR定义的逻辑功能需求进行技术性转化和体现。

这部分技术需求属于相对基础的TSR，不涉及深层次的探测，显示，控制或减轻系统出现故障的安全措施，所以并不能保证系统功能安全。它的主要的目的是为后续相关安全机制的开发或者需求的提出奠定技术基础。

例如，由FSR技术化的安全需求包括，定义逻辑功能需求中所涉及的软件组件，硬件组件(传感器，控制单元，执行单元)，组件接口技术信息(如信号名称，来源等)，传输方式(CAN总线等)，计算周期，软件组件不同平台复用配置需要的标定数据，硬件组件指标要求等。

==安全机制==

安全机制(Safety Mechanism)目的在于探测，显示和控制故障，属于功能安全事后补救措施，是TSR非常重要的组成部分，是实现功能安全，防止安全目标SG或者功能安全需求FSR违反的重要技术实现手段之一。

安全机制应该包含：

检测系统性及随机硬件故障的措施。例如，针对系统I/O，总线信号范围检查，冗余校验，有效性检测，逻辑计算单元数据流及程序流监控，控制器硬件底层软件监控等。
显示故障。例如，对驾驶员进行声音，不同类型及颜色的指示灯，提示文字等预警，增加驾驶员对车辆的可控性。
控制故障的措施。例如，Fail to safe: 将系统在指定的故障容错时间间隔(FTTI)导入安全状态，包括降级，故障仲裁，故障记录等。如果不能，还需要定义紧急运行时间间隔及运行状态。或者Fail to operational，通过并行冗余系统，当一个系统失效后，进入另外一个并行系统继续提供全部或部分功能。少。

==Stakeholder需求==

Stakerholder需求主要包括车辆使用，法律法规，生产和服务方面相关的安全需求。一般都是以具体技术细节直接进行呈现，所以会直接并入TSR之中。

例如，车辆发生碰撞后，相关项应该采取的哪些应对措施，可能是转矩输出非使能，高压系统断电等。

此外，针对TSR，还需要注意以下几点:

技术安全要求和非安全要求不能互相矛盾。
对于使相关项达到或保持安全状态的每个安全机制，应指定以下内容: 切换到安全状态的条件，时间间隔(FTTI)，必要的话，紧急运行状态及时间间隔。
对于ASIL(A)、(B)、C 和 D 等级的技术安全需求，应该制定防止故障潜伏安全机制。
对于 ASIL(A)、(B)、C和 D 等级的TSR: 用于防止双点故障变成潜伏故障的安全机制的开发应符合以下ASIL安全等级要求:
- ASILB(对于分配为ASILD的技术安全要求);
- ASILA(对于分配为ASILB和ASILC的技术安全要求);
- QM(对于分配 ASILA的技术安全要求)。

这个就是安全机制的安全机制ASIL等级的约束，该约束的本质是对TSR对应ASIL等级的分解，主要是为防止由安全机制失效导致的双点故障潜伏。

安全机制的本质

接下我们聊聊困惑很多朋友的一个问题: 安全机制到底是什么，它和TSR到底有什么区别?

在ISO 26262-4:2018中，TSR和安全机制这两部分内容独立成章节，并没有合在一起进行阐述，这给很多朋友造成一种误解，认为安全机制和TSR好像是不一样的存在，它们之类的区别也不够清楚。下面我从三个方面来阐述一下安全机制的本质:

安全机制属于更深层次的TSR

安全机制是为防止SG或FSR的违反，基于由FSR技术化的安全需求，提出的更深层次的事后补救技术安全措施，它包括:
- 由FSR技术化得到的TSR的安全机制，主要是防止系统性故障，或硬件单点故障潜伏提出的技术安全需求。
- 以及安全机制的安全机制。例如针某TSR提出了已经有了安全机制A，但由于该TSR的ASIL等级较高(C或D)，安全机制A本身也可能失效，此时如果原有功能正常，系统不会违反安全目标SG，但安全机制A的失效就会潜伏，变成双点故障，所以需要对安全机制A的功能安全进行监控，提出针对安全机制A的相应的技术安全需求，防止安全机制A的故障潜伏。
一般来讲，考虑到系统实现的成本和复杂度，安全机制不超过两层。根据ISO 26262，三点及以上故障就可以认为安全故障，否则就会出现无穷的安全机制嵌套。
安全机制是实现相应ASIL等级的关键之一

除ISO 26262对不同开发过程的约束(包括方法，验证等)外，在系统，软件和硬件开发阶段，不同ASIL等级直接决定了应该采取哪些安全措施，以及安全措施的类型(或高级层度)。

越高的ASIL等级对应的安全措施，在数量和质量的要求越高。例如，对于ASILB的系统，可能具有单独时间Base的Watchdog可能就够了，但是对ASILD系统而言，可能需要上程序流逻辑监控才能满足。

当然不同的安全机制在实施难度和成本上都有所不同，这部分内容我会在后续的专题里一步步讲解。
安全机制多和系统安全架构设计相关，一定程度上决定了系统安全架构

安全机制是保证系统功能安全的非常重要的技术手段，而这些技术手段，例如，硬件冗余，输入输出有效性检验，安全状态导入，或我们常见的控制器3层安全监控架构等等，这些都直接决定了我们系统的安全架构，会在架构设计中进行考虑，直接融入架构设计之中。这个也是为什么在功能安全在系统阶段开发过程中，花很大的篇幅来讲安全机制和架构设计的重要原因之一。

为了方便理解安全机制，我们一起来看个关于加速踏板开度采集的例子:

左边属于由FSR技术化的安全需求，主要是明确加速踏板技术信息，包括采用什么样传感器，输出信号有哪些，类型，采样周期等。

在实际系统开发过程中，为实现相应的ASIL等级，控制系统一般进行分层设计，功能安全拥有独立的软件层和硬件层，开发过程相对独立，甚至独立的开发团队。

为实现后续安全监控，需要将安全相关的应用层功能在监控层进行多样化设计复现，所以这部分TSR和我们正常的系统应用层功能开发需求有点类似，但不是完全复制，而是多样化，差异化的设计实现，所以这些信息或者需求会和应用层功能实现存在一定关联。

右边是安全机制，是更深层次技术安全需求，这些都是保证系统功能安全的关键技术手段。

怎么从FSR到TSR

上面我们聊到TSR的具体组成部分，包括由FSR技术化的TSR，安全机制和Stakeholder需求。

前两部分TSR的导出，和概念阶段聊到的SG到FSR类似，都是通过安全分析(即FTA，FMEA分析方法)完成。

以FTA分析为例，主要是将违反的FSR作为顶层分析事件，进行原因分析，安全分析的具体细节我在这里就不重复了。

实际操作过程中，对于比较简单的FSR，即涉及的组件功能的比较简单，完全可以依据经验直接导出，对于相对比较复杂的FSR则需要进行完整的安全分析。

对于Stakeholder需求，一般需要根据Item Definition中定义的法律法规及之前项目经验进一步细化，一般情况下，该部分需求可以在不同项目中可以复用。

技术安全方案TSC及安全分析

什么是TSC

一般来讲，一个完整的TSC应该包含以下主要内容:

TSC概念

除此TSR之外，系统安全架构也是TSC不可或缺的重要内容，需要对系统架构功能安全部分内容进行开发，得到系统安全架构，作为系统阶段TSC的重要内容。

对于FSC:

FSC属于概念开发阶段主要工作输出产物，除技术文档基本的格式外(包括作者，版本记录，输入，适用范围，缩写等)，主要包含三大部分内容:

相关项定义内容进行描述。
安全目标SG和技术安全需求FSR: 一般是按照安全目标SG进行结构组织，分别罗列每个安全目标SG下，对应的功能安全需求FSR。
安全状态: 一般针对每个或者多个安全目标SG设定系统安全运行状态。

对于TSC:

TSC主要是描述由FSR导出的技术安全需求和安全机制。

由于FSR数目众多，所以TSC不太可能直接按照FSR进行罗列对应的TSR，并且考虑到后续需要将TSR分配至系统架构，所以TSC更多的是按照系统组件或功能集合进行结构组织，阐述每个组件或功能集合下，对应的TSR，并区分该需求由软件，硬件或二者共同实现。

关于书写工具，TSC和FSC类似，可以采用Word等基本文本工具，或采用相对比较专业的需求管理软件，例如Doors等。对于TSC最好可以结合架构设计工具，例如Enterprise Architect等，将需求和架构关联起来。

此外，在TSC中需要将TSR分配至系统架构，还需要保证TSR和FSR之间的关联，这样就可以形成了SG，FSR以及TSR之间完整的Traceability。还可以进一步将系统级别测试用例和TSR关联，这样就形成了不同类型需求之间完整的可追溯性和可验证性，这个在功能安全评审过程中非常重要。

安全分析

安全分析是功能安全最重要的内容之一，它伴随功能安全整个开发过程，是所有安全开发工作的基础，但在每个开发阶段侧重点有所不同。

在概念阶段，安全分析侧重整车功能分析，首先采用系统或者整车级别安全分析方法HAZOP导出SG，然后利用FMEA或FTA安全分析方法，由SG导出FSR。

在系统阶段，安全分析，除了由FSR导出TSR以外，侧重点在于对系统架构的分析，主要有以下两个目的:

对系统安全架构进行分析，提供系统设计适合性的证据，确保系统架构可以实现安全相关的需求和属性，以及对应ASIL等级。
对系统进行复查，识别以系统架构没有覆盖的故障原因和风险。对于新识别出危害，必须重新按照HARA过程进行分析和更新，并对FSR和TSR和架构进行完善。

对于安全分析方法而言，不管在哪个开发阶段(包括概念，系统，软件，硬件)，无非就以下两种:

归纳分析法(Inductive analysis): FMEA(Failure Mode and Effects Analysis，即失效模式与影响分析)，定性分析。
演绎分析法(Deductive analysis): FTA(Fault Tree Analysis, 即故障树分析)，可定性和定量分析。定量分析多用于硬件指标计算。

概念阶段HAZOP也属于归纳分析法，其本质和FMEA一致，可以认为是整车级别简化的FMEA。

其实安全分析方法和过程都很明确，简单的说:

FMEA就是从系统实现功能去分析它们可能存在的潜在失效情况和故障。
FTA正好反过来，如果出现这种失效或者故障，可能是由系统哪些部件或功能导致。

很多朋友过于强化安全分析工具的作用，寄希望于通过特定安全分析工具来实现不同阶段的安全分析，认为有了分析工具就搞定了一切。

但这些分析工具只是支持手段，把我们安全分析的思路和过程记录下来而已，很多大企业目前还是采用Excel照样做安全分析。重点在于我们对系统的了解和认知程度，这些直接决定了安全分析的结果的可靠性和全面性，这个也是安全分析的难点。

当然，世面上也有些把车辆失效和故障情况集成到安全分析工具中，实现快速安全分析。但这样的分析工具很难和我们具体研究对象一致，可靠性也难以评估，也没有必要。安全分析是功能安全工作的基础，基础没有亲自去完成，做到充分了解，那后面工作很难开展。

所以，还是多花点时间去认识研究对象，安全分析自然水到渠成，这个才是核心。

TSR分配至系统架构

根据ISO 26262-4-2018要求，TSR必须分配至系统架构，作为TSC的重要组成部分。

这样做的主要目的在于，通过将TSR及对应ASIL落实到架构中具体的软件或硬件组件当中去，就可以明确系统中不同组件后续开发需要的所有安全需求及对应的ASIL等级，为后续软件和硬件的开发提供需求基础。

那具体如果确定一个组件的ASIL等级呢？

系统架构中的组件的ASIL等级源于分配到组件的TSR的ASIL等级，具体来讲，应该满足以下约束:

组件应该继承分配给它的所有TSR中的最高的ASIL等级，作为系统组件开发ASIL等级。
如果一个组件由多个子部件构成，且分配给子部件的TSR对应的ASIL等级(包括QM)不同，则每个子部件应该按照以下两个原则之一进行开发:

所有子部件分别按照所有TSR中最高的ASIL等级。
如果各子部件满足要素共存或免于干扰原则，即FFI(Freedom From Interference)，则各子部件按各自ASIL等级开发。

这里需要注意免于干扰(FFI) 和ASIL等级分解独立性原则(Independence)区别: FFI和ASIL

FFI: 要避免在两个或者更多要素之间由于级联失效而导致的违反功能安全要求。

ASIL等级分解独立性: 除保证无级联失效外，还需要保证无共因失效问题。所以独立性要求更为广泛，需要通过相关失效分析(DFA)证明。

[!note]

那为什么FFI只要求避免级联失效，而ASIL分解独立性要求，除避免级联失效外，还要求避免共因失效呢？

二者需要解决的问题不同:

FFI旨在解决不同ASIL等级(包括QM)组件共存的问题，需要对不同ASIL等级组件进行有效隔离，防止低ASIL等级组件故障蔓延或者影响到其他高ASIL等级组件，即防止串联失效，这属于级联关系的失效。

ASIL分解旨在，在保证原有安全性的情况下，将高ASIL等级需求分解成两个独立的低ASIL等级需求，一般这两个低ASIL等级需求会分配至两个不同组件，由此降低组件开发难度。

共因失效，即共同外部因素错误导致的组件失效，可以简单理解为并联失效。不管组件之间是否进行了隔离，只要有共同的外部错误输入，涉及的组件一定会出现故障，所以共因失效和FFI无关。

那怎么才能用低ASIL等级实现原有安全需求呢？

独立性，说白了是强调不一起发生故障，两个组件只有即不发生串联失效，也不发生并联失效的情况下，才可以保证不一起出现故障。

FFI是后续软件功能安全开发重要的内容，和控制器基础软件相关，ISO 26262中定义了以下几种要素干扰情况:

执行和时序(Timing &Execution)干扰
内存(Memory)干扰
信息交换(Exchange of information)干扰

系统安全架构

系统架构作用

架构是一门艺术，在整车汽车系统，软/硬件开发过程中非常重要，尤其在基于模型的系统开发(MBSE)中，架构是整个开发过程的核心之一。

一般来讲，系统架构一般采用通用化建模语言UML或SysML在相关架构开发软件，如Enterprise Architect， Cameo等，进行开发。但可惜的是，目前大部分车企都没有完整的系统架构或多基于PowerPoint等形式的简单架构描述。

在功能安全第三部分概念开发和第四部分系统开发过程中，都需要系统架构作为输入条件，借助系统架构进行安全分析，导出功能安全需求(FSR)和技术安全需求(TSR)，并将相应的安全需求分配至系统架构。

但在系统开发阶段，我们还需要对系统架构进行功能安全相关内容进一步开发，将架构相关的安全机制融入系统架构当中，形成系统安全架构(Safety Architecture)，以此勾勒出实现系统技术安全需求所需要的核心技术框架，为后续软件和硬件架构的详细设计提供基础。

系统架构相关安全机制

很多朋友一直有个疑问，对于不同的ASIL等级应该具体采取哪些安全机制呢?

这是个很好的问题，一般来说ASIL等级越高，需要采取的安全机制数目及质量要求越高。

但ISO 26262并没有，其实也没有办法明确哪个ASIL等级应该具体采取哪些安全机制，只有对硬件部分，不同覆盖率(中，高，低)对应的安全机制的推荐。

主要原因在于:

虽然有一些通用的安全机制，但研究对象不同，采用的安全机制也不尽相同。
为功能安全技术实施多样性提供更多空间和选择，便于不同企业根据自身技术积累和开发条件进行实施。
为技术更新换代提供可能性。随技术发展，很多新的安全机制得以实现或得以在汽车行业应用。
如果ASIL等级和安全机制一一挂钩，强制执行，可能很多车企的车都没办法上市了(你懂的🤣)。

我们先看看不含安全机制的系统架构长什么样?

系统架构旨在描述相关项组成和相互作用和约束。根据ISO 26262定义，相关项由一到多个系统构成，而一个系统应该至少包括一个传感器，一个控制单元，一个执行器。当然，一个系统也可以包含多个子系统。

所以一个最简单的系统架构如下:

系统架构相关安全机制

那有哪些系统层面的安全机制可以融入系统架构，进而形成系统安全架构呢？

既然一个最简单的系统由三个部分构成，那么系统级别和架构相关的安全机制肯定也是和这三个部分以及三者之间的通讯安全相关。

下面我们一起看看系统层面和架构相关的常见的安全机制:

传感器
- 传感器硬件冗
- 独立供电
- 多通道冗余采集
- 信号质量检测
控制单元
- 在线诊断
- 比较器
- 多数投票器
执行器
- 执行器硬件冗余
- 执行器控制信号质量检测
通讯
- 冗余发送
- 信息冗余(CRC)
- 时间监控
- 问答机制

需要注意的是，系统阶段的安全机制主要作用是勾勒出实现系统功能安全所需的核心技术框架，明确应该采取哪些技术手段实现相应的安全目标，不会涉及具体的实施细节，这个会在后续软件和硬件开发阶段进一步明确。

从上述安全机制可以看出，虽然安全机制的种类有很多，但无非都源于以下三个角度:

冗余性: 使用相同的功能组件(多指硬件)降低硬件随机失效，增加功能安全的可靠性，例如传感器，执行器冗余等。
多重性: 多用于故障关闭路径，使用多个关闭路径或保护设备，提供了防止单个设备失效的保护。
多样性: 使用不同类型的设备或者软件多样化设计，降低共因失效的可能性。

系统安全架构设计

了解系统架构相关的安全机制，接下来我们就将这些安全机制融入原有的系统架构，分别看看系统不同组成部分，融入安全机制后形成的系统安全架构长什么样？

传感器部分

首先，我们在系统中融入传感器部分安全机制，需要注意的是，此处的传感器代表广义的输入信息，可以是具体传感器信号，也可以是其他类型通讯信息，例如CAN，SENT等。

传感器的硬件冗余(当然传感器必须独立供电)多适用于对于ASIL等级要求非常高的信号，如ASIL C, D，尤其是D，其主要目的是为避免传感器硬件随机失效，通过信号相互校验，增加系统输入信息可靠性。

这里的传感器硬件冗余采集，可以是利用相同的两个传感器，对同一信号进行重复采集(例如，踏板信号)，也可以是利用不同类型传感器，对强相关的两个信号分别进行采集(例如，制动踏板位置和压力信息等)。

当然，传感器输入冗余信息，在控制单元中，必须进行多路采集，除传感器本身提供诊断信息外，还需要对其信号有效性进行检验，包括数值有效范围检测，在线监控，Test Pattern，输入对比，相关性，合理性检测等。

控制单元

控制单元属于整个系统中最重要的部分，控制单元相关的安全机制其实很大程度上决定了系统安全架构和系统复杂程度。

提到控制单元相关的安全机制，很多朋友第一反应是，控制器软件分层，控制器硬件冗余(双控制器，Dual Core Lock Step双核锁步等)，看门狗，程序流监控等。

虽然这些都是控制单元常用的安全机制，但从系统角度而言，它们相对过于具体，只是针对某一类故障而设计的软件或硬件安全机制，需要在系统安全架构基础上具体明确。
接下来我们从系统角度，先看看系统级别安全架构，后续无非就是将具体的软件和硬件安全机制逐步应用于系统架构当中去。

一般来说，所有的安全机制本质上都服务于两类安全架构:

Fail to safe
Fail to operational

执行器

执行器属于系统功能实现终端，执行器冗余会极大增加系统成本，一般在Fail to operational 安全架构中才会采用。例如EPS系统，制动系统等，除电动执行单元外，还必须保留机械执行路径。这也是目前自动驾驶系统，为什么还必须保留驾驶员自主驾驶所需要的全部执行输入(例如，踏板，方向盘)的根本原因。

通信安全

系统组件之间以及组件内部的通信安全，也是系统功能安全的重要内容，一般都采用信息冗余(CRC)，时间监控，问答机制等安全保护机制，主要应用就是AUTOSAR中的E2E保护，利用数据控制信息，保证信息通讯安全。

Fail to safe

Fail to safe是目前汽车行业应用最广泛的安全架构，最典型的应用就是在线监控，将整个控制单元分为功能实现和在线监控两部分，即所谓的的1oo1D类型系统，具体如下图所示:

Fail to safe

其中:

功能实现部分一般按正常开发流程就行开发，主要实现系统的功能性需求，不需要考虑功能安全需求(也就是全部QM)。

监控单元用于实现系统功能安全相关的需求，主要目的在于对功能实现部分进行安全监控，在线监测功能实现部分是否按照预期运行。一旦发现问题，就将系统导入安全状态，停止提供系统原有功能或者维持最必要的功能。

需要注意的是，监控单元非功能层全部功能的多样化复现，不能独立于功能实现部分单独存在，ASIL等级则直接决定了监控单元的硬件及软件复杂度。

对于ASIL等级要求较高的系统，监控单元软件一般独立于功能层。为实现有效监控，在监控单元不仅需要对功能层中，和功能安全相关的输入和输出进行诊断，还需要对功能安全相关的计算逻辑进行监控，计算执行器关键控制信号的安全输出范围，并和功能层计算结果进行对比，甚至需要对控制器硬件进行额外的硬件监控。

如下图所示，发动机控制单元最常见的E-Gas三层安全架构就属于典型的1oo1D的应用，包括功能应用层，功能监控层，控制器监控层。

1oo1D框架示例

E-Gas三层安全架构，虽然是针对发动机控制单元，但属于非常经典安全架构，广泛应用于传统控制系统(例如传动，整车控制)当中，三层分层架构本质为原有ASIL等级的分解，即QM (ASILD)+ X(ASILX):

功能层: 功能实现部分，使得较为复杂的功能实现部分得以按照QM开发，无需考虑功能安全需求，专注于复杂功能软件的开发和复用。
功能监控层: 按照原有ASIL等级进行独立开发，对功能层中功能安全相关部分进行监控，包括输入输出诊断，逻辑监控，故障分类及故障优先级仲裁等。
控制器监控层: 对功能控制器，尤其是功能监控层控制器硬件进行监控，一般采用独立的监控单元(一般采用ASIC基础芯片)对功能控制器中内存，CPU，通讯，定时器等进行监测和保护。

当然，分层安全架构只是1oo1D其中一种实现方式，对于ASIL等级要求不高或者功能简单的控制系统，不一定非得采用分层架构，监控层也可以相应简化。

Fail to operational

Fail to operational 属于相对高级的安全架构，比较器和多数投票器都属于这类安全架构，整个系统由相对独立的两条或多条功能链路构成，每条功能链路都有拥有自己独立的传感器，控制单元，甚至执行器。当其中一条功能链路出现异常，控制系统可以切换到其他功能链路，保证系统继续正常工作或者降级运行。

独立功能链路的实现需要大量的硬件冗余和多样化的软件设计，直接提高了系统成本，所以Fail to operational在汽车产品一般最多有两个独立功能链路，主要应用在对功能安全要求极高或者功能极为复杂的系统，例如自动驾驶。其中最典型的是1oo2架构，如果每个功能链路拥有独立的诊断单元(和在线监控类似)，则可以实现1oo2D安全架构，如下图所示:

1oo2架构例子

其中:

两条功能链路功能可以保持一致，通过多样化软件设计保证系统安全，或者形成主副功能链路，主功能链路利用高性能计算单元实现复杂的功能计算，副功能链路对控制器硬件安全性及可靠性要求高，承担系统功能安全任务，只实现系统功能安全相关的功能，一旦主功能链路出现故障，则系统切换至副功能链路。

硬件阶段

安全需求，安全设计及安全机制

正式聊之前，为便于理解，先说明以下几点:

功能安全研究范围为电子电气系统，即E/E系统，所以这里的硬件特指控制器硬件，包括控制器I/O接口，控制器芯片等，非传统的机械硬件。
硬件同样存在系统失效，即由于人为设计疏忽导致的失效，需要对设计过程进行相应约束，包括开发流程，方法，测试验证等，保证硬件安全。
ISO 26262中基于概率论的定量危害分析仅限适用于硬件部分，因为只有硬件存在随机失效，并符合概率分布原理。
硬件开发和系统，软件开发一样，都基于V模型，但有两个过程区分于传统V模型开发流程，即概率论定量分析，包括硬件架构度量和随机硬件失效的评估。

什么是硬件安全需求？

功能安全硬件开发始于需求，即硬件安全需求(Hardware Safety Requirement, HWSR)，而HWSR源于分配至硬件组件的TSR，是硬件相关的TSR在硬件层面的进一步细化。

HWSR包括哪些内容呢？一般来讲:
$$
硬件安全需求HWSR = 安全机制无关的硬件安全需求 + 硬件安全机制
$$
==安全机制无关的硬件安全需求==

硬件架构度量及随机硬件失效目标值要求，一般根据可以直接查表即可确定。例如: SPFM，LFM，PMHF等，这部分会在硬件架构度量及失效评估中阐述。
为避免特定行为的硬件安全要求。例如:一个特定传感器不应有不稳定输出。
分配给硬件的预期功能要求。例如: 控制器必须能够外部reset。
定义线束或接插件的设计措施的要求。例如: 线束或插件最大电流需求。

==硬件安全机制==

针对内部硬件要素(包括传感器，控制器和执行器)失效的安全机制。例如: 看门狗，比较器，双核锁步 (dual-core lockstep)，传感及执行器诊断等。
针对外部相关要素失效的容忍能力的安全机制。例如: ECU 的输入开路时，要求 ECU 应具备的功能表现。
针对内外部要素失效对应安全机制的响应特性需求。例如: 安全机制中定义的硬件元器件的故障响应时间要符合ISO 26262-4:2018, 6.4.2中要求的故障容错时间间隔以及多点故障探测时间间隔。

怎么从TSR得到HSR呢？

HWSR属于由硬件相关的TSR细化得到硬件层面安全需求，只要在系统开发阶段有效识别出硬件相关的TSR，HWSR导出相对比较容易。

具体来说，根据硬件相关TSR，对其进行安全分析或直接根据经验，分别针对组成HWSR的三个部分进行分析：

为避免硬件内部失效措施
为避免外部相关失效对应的内部措施
为避免硬件随机失效的概率度量要求

将其作为HWSR即可，具体见下图:

TSR转换为HWSR

硬件安全设计

硬件安全设计主要包括两个方面:

硬件安全架构设计
硬件安全详细设计

硬件安全架构和详细设计均基于HWSR，硬件安全架构的设计旨在描述硬件组件以及其彼此的相互关系，更重要的是将硬件架构相关的HWSR，尤其是安全机制应用于硬件架构，为后续硬件详细设计提供基础。

硬件安全机制是硬件安全设计中最核心的内容。除此之外，ISO 26262-5:2018第7部分还对硬件安全架构和详细实现设计提出了相关约束，主要包括:

对硬件安全架构设计而言:

硬件架构应能够承载HWSR。
HWSR应该被分配至硬件架构中的组件。
不同或非ASIL等级硬件组件开发需满足以下原则之一:
- 按最高ASIL等级
- 要素共存FFI
对硬件安全要求和实施之间的可追溯性。
为避免系统失效, 硬件架构应具有下述特性:
- 模块化;
- 适当的粒度水平;
- 简单性。
在硬件架构设计时，应考虑安全相关硬件组件失效的非功能性原因，例如: 温度、振动、水、灰尘、电磁干扰、来自硬件架构的其他硬件组件或其所在环境的串扰。

对硬件详细实现设计而言:

为了避免常见的设计缺陷, 可运用相关的经验总结。
在硬件详细设计时, 应考虑安全相关硬件元器件失效的非功能性原因, 可包括以下的影响因素:温度、振动、水、灰尘、电磁干扰、噪声因素、来自硬件组件的其他硬件元器件或其所在环境的串扰。
硬件详细设计中, 硬件元器件的运行条件应符合它们的环境和运行限制规范。
应考虑鲁棒性设计原则。

硬件安全机制

硬件相关安全机制是组成HWSR最重要组成部分，是硬件安全设计最重要的体现，也是功能安全ISO 26262中最晦涩难懂的内容之一。

ISO 26262-5:2018附录D中列出了控制器硬件可能存在的故障，对应的安全措施及覆盖率，为后续硬件概率度量提供了基础，基本上涵盖了硬件通用的安全机制，强烈建议多看几遍。

一般来讲，一个E/E系统中硬件主要包括: 传感器(D.9)，继电器/连接件(D.3)，Digital输入/输出(D.5)，Analog输入/输出(D.5)，总线(D.6)，处理器(D.4)，时钟(D.8)，执行器(D.10)，具体如下图所示:

E/E系统中硬件组成

由于内容过多，我们接下来以其中最重要的硬件之一，即处理器(D.4)为例，介绍处理器相关的硬件安全机制。

处理器(CPU)是微控制器(MCU)的核心，是负责读取指令，对指令译码并执行指令的核心部件，ISO 26262-5:2018附录D中，处理器相关的安全机制及诊断覆盖率如下所示:

处理器相关安全机制及诊断覆盖率

CPU主要由运算器，控制器，寄存器组成，所以针对处理器的安全机制也主要针对这三大部分。由于表格里的处理器相关安全机制分类存在一定重叠，且不是很好理解，个人将其进行总结分类如下:

自检
硬件冗余
看门狗
程序流监控

自检

根据自检方法，自检安全机制一般可以分为:

软件自检：对安全相关路径中的使用到的指令，利用预先设置好或自动生成的数据或代码，对物理存储(例如，数据和地址寄存器)或运算器及控制器(例如，指令解码器)，或者它们两者进行检测。
硬件自检：在控制单元内部集成专用自检硬件，最常见的就是内建自测试(BIST)，通过在芯片设计中加入额外自测试电路，测试时从外部施加控制信号，运行内部自测试硬件和软件，检查电路缺陷或故障，是防止故障潜伏的重要安全机制。

BIST一般仅在处理单元初始化或者下电时运行，所以不能覆盖瞬态故障，根据其自检时间一般可以分为:

Online Self-test: 在车辆启动时间限制内尽可能多地进行测试。
Offline Self-test: 车辆停机或诊断测试，最大的测试覆盖率，车辆断电时没有时间限制。
Periodic Self-test: 车辆在正常操作模式下，进行的诊断测试。

而根据其自检的内容，BIST又可以分为:

MBIST(Memory Built-In Self Test): 对memory，包括RAM或ROM，进行读写测试操作，判断Memory是否有制造缺陷，属于内存相关的安全机制。
LBIST(Logic Built-In Self Test): 对芯片内逻辑电路进行自检，属于处理器相关安全机制。

其中，LBIST是硬件自检非常重要的安全机制，其工作原理如下图所示:

具体来讲，首先利用测试生成器，生成测试向量，然后将测试向量输入被测试电路，最后BIST控制器将测试电路输出结果和预存的结果进行对比，一旦二者存在差异，则表明被测试电路存在故障。

硬件冗余

硬件冗余是处理器或控制器最重要的安全机制之一，根据硬件冗余的形式，控制器硬件冗余一般可以分为以下两大类:

双(多)MCU硬件冗余

使用两个相同或不同类型的MCU，进行硬件冗余，二者相互独立，构成主，副功能链路，其中一个MCU负责功能实现，另外一个对功能安全要求较高的MCU负责功能安全需求实现，二者输出结果进行相互比较并控制安全输出。

优点在于: 物理复制安全相关和非安全相关的功能与特性，避免相关失效鲁棒性高，可以实现Fail Operational 系统架构，当其中一个MCU失效后，另外一个MCU可以实现全部或部分功能，维持系统继续运行，多用于高级辅助和自动驾驶控制系统。

缺点在于: 配置复杂，成本高，再加上软件同步及PCB空间增加等因素，会给带来巨大的挑战和障碍。

示例: 双控制单元EPS控制系统。
单MCU硬件冗余

单MCU硬件冗余一般采用CPU冗余，形成双(多)核MCU，并采用双核锁步技术(Dual Core Lock Step)。

双核: 两个相同的核镜像，90°旋转，隔离设计，间距100um。

锁步: 两个核运行相同程序并严格同步，一个输入延迟，另外一个输出延迟，延迟时间一般为2-3个时钟周期，计算结果利用比较逻辑模块进行比较，检测到任何不一致时，就会发现其中一个核存在故障，但不会确定是哪个核故障。

双核锁步是一种综合性的硬件安全机制，可以有效覆盖CPU执行指令，设计电路等相关失效，具体如下图所示:

在E-Gas三层功能安全架构中，第二层，即功能监控层可以采用双核锁步安全机制，并且功能安全相关和非相关的软件可以进行分区，使用不同的硬件资源(例如,不同的 RAM、ROM 存储范围)可提高诊断覆盖率。

示例: 双核锁步(Dual core Look step)EPS控制系统。

其中，MCU采取双核锁步模式，并且存在独立的监控单元，工作于低功耗模式，对双核MCU进行电源管理和安全监控。

看门狗

看门狗定时器 (WDT) 是一种定时器，用于监视微控制器 (MCU)程序，查看它们是否失控或停止运行，充当监视MCU 操作的“看门狗”。

MCU正常工作的时候，每隔一段时间输出一个信号到喂狗端，给WDT清零，如果超过规定的时间不喂狗，WDT就会给出一个复位信号到MCU，使MCU复位。

看门狗基本类型及主要特点如下图所示:

看门狗

对于功能安全而言，主要采用硬件看门狗作为安全机制。根据其实现复杂度，它可以工作于不同模式:

计时模式(Time out mode)
时间窗模式(Window mode)
问答模式(Q&A mode)

从上往下，其可靠度和复杂度依次上升。

除此之外，还必须注意以下几点:

看门狗必须在系统初始化中进行测试，避免看门狗自身故障。
看门狗输入为喂狗(kicking the dog/service the dog)，必须在特定的时间或时间窗内喂狗，否则会触发相应Reset端或功能降级。

程序流监控

程序流监控的实现的本质是看门狗，用于检查程序是否按照预期的执行顺序执行。如果监控实体以不正确的顺序执行，或在规定的截止时间或时间窗内没有被执行就出现不正确的程序流。

具体应用过程中，可以在功能安全相关的一个或多个监测实体中按照程序预期的执行顺序设置一个或多个Checkpoint，如果在特定的时间限制内，Checkpoint没有被依次执行，则会触发相应的复位或错误处理机制。

需要注意的是:

在ISO 26262-5:2018附录D中，将看门狗和程序流监控这部分安全机制归为时钟(D.8)故障的安全机制，但它们还是主要应用于处理器(D.4)，所以本文将其归类到处理器相关的硬件安全机制。
实际应用中，程序流监控一般直接包含于看门狗安全机制，例如AUTOSAR中看门狗管理器WdgM，可以实现周期性，非周期性以及逻辑监控。
硬件相关安全机制很多并不是单独存在的，例如，看门狗安全机制可以和其他硬件安全机制相互结合使用，利用看门狗问答模式(Q&A mode)可以将程序流监控和功能安全相关的CPU指令测试安全机制相结合，对监控单元提出的问题各自提供部分答案，实现对功能安全控制硬件的有效监控。

硬件随机失效概率化评估

硬件随机故障基本类型

为方便理解，在具体谈硬件概率化度量前，我们先来看看硬件随机失效的基本模式:

硬件随机失效的基本模式

由上图可知，ISO 26262将硬件随机故障失效模式，按照发生故障的数目，是否可以被探测以及感知进行了分类，其主要特点总结如下:

单点故障
- 某个器件单独导致功能失效的故障。
- 单点故障可直接导致违背安全目标。
- 单点故障意味着没有任何安全机制，否则不能归类为单点故障。
残余故障
- 安全机制无法覆盖的那部分故障(没有100%覆盖率的安全机制，如果一个安全机制覆盖率为90%，那剩余的10%则属于残余故障)。
- 残余故障可直接导致违背安全目标。
- 残余故障至少存在一个安全机制。
潜在故障
- 既不被安全机制所探测，又不被驾驶员感知的故障。
- 系统保持正常工作至所有独立故障发生。
- 潜在故障可直接导致违背安全目标。
可探测的故障
- 通过安全机制可探测到的那部分故障。
- 通过安全机制探测到故障并进行显示。
可感知的故障
- 可以被驾驶员感知的故障。
- 可以有或者无安全机制进行探测。
双点故障

两个独立的故障同时发生才会违背安全目标，则这两独立的故障属于双点故障。
某故障和其对应的安全机制失效属于常见的双点故障。
双点故障又细分为可探测的双点故障、可感知的双点故障以及潜伏的双点故障。

安全故障

不会导致违背安全目标的故障，例如某指示灯显示故障，但不影响其正常功能。
三点及以上的故障通常也被认为是安全故障(一般发生概率较低且所对应的安全机制过于复杂，所以归类为安全故障)。

更多详细介绍可以直接参考ISO 26262-10:2018第8部分。

硬件随机失效率

为了对硬件随机失效进行量化，引入了硬件随机失效率λ，其定义为:失效率是指元器件在单位时间内发生失效的概率，记为λ，一般以小时(h)作为时间计量单位，所以其单位为: 次/h。

考虑到电子元器件失效率极低，所以一般采用FIT (Failures In Time) 来计量，$1 FIT=1次失效/10^9 h$。

例如: 某电阻失效率λ=2 FIT，即该电阻在$10^9 $h时间内存在两次失效。

不知道朋友们有没有想过，既然电子元器件的失效和自身老化相关，那它的失效率为什么是常数，而不是随时间变化的?

为了回答这个问题，我们先来看看电子元器件的生命周期特性。电子元器件的生命周期非常符合浴盆曲线(Bathtub Curve)，如下图所示:

电子元件的生命周期

由图可知，电子元器件整个生命周期大致可以分为三个阶段:

第一阶段: 早期故障期，即磨合期，该阶段故障多属于系统性故障，和设计，制造相关，故障率相对较高。
第二阶段: 偶然故障期，即有用寿命期，该阶段是电子元器件正常使用周期，持续时间长，失效率低且较稳定，设计无法消除，属于随机硬件故障，ISO26262 中硬件量化指标就是针对该阶段失效率的评估。
第三阶段: 耗损故障期，上随着电子元器件使用寿命到期，故障率随之上升。

因此，在ISO 26262中查到的是恒定值，而不是一个时间函数。

那么怎么获取电子元器件的失效率呢？一般来讲可以通过以下三种方式获得:

历史数据: 根据已有或相似产品，预估新产品的失效率，但全新的产品没有历史数据可参考。
测试: 属于最真实和最准确的数据来源。但测试周期长，成本高。
行业公认的标准: 根据SN29500, IEC 62380等行业公认的标准和指南中提供的可靠性预估算法计算。

硬件的架构度量

硬件架构的度量, 用于评估相关项架构应对单独类型的随机硬件失效的有效性。由于硬件随机故障中，单点故障、残余故障和潜伏故障会直接导致安全目标的违背或实现有显著影响，所以硬件架构概率度量包含以下两个方面:

单点故障度量(single-point fault metric)
1. 单点故障度量反映硬件安全机制或设计对单点和残余故障的覆盖是否足够。
2. 高单点故障度量值表示相关项硬件单点和残余故障所占比例低，系统可靠性高。
计算公式为
$$
{SPFM=1-\frac{\sum (\lambda_{SPF}+\lambda_{RF,est})}{\sum\lambda}}\
\lambda_{RF,est}=\lambda\times\left(1-\frac{K_{DC,RF}}{100}\right)
$$

其中:
- $λ_{SPF}$ 是单点故障失效率
- $λ_{RF,est}$是估算的残余故障的失效率
- $λ_{DC,RF}$:是残余故障的诊断覆盖率。
- 求和是只和硬件安全相关的参数的求和
[!note]
$$
SPFM=1 - \frac{(单点故障总和+残余故障总和)}{(所有和安全相关失效率总和)}
$$
潜伏故障度量(latent-fault metric-LFM)
1. 潜伏故障度量反映硬件安全机制和设计对潜伏故障的覆盖是否足够。
2. 高潜伏故障度量值表示硬件潜伏故障所占比例低，系统可靠性高。
计算公式:
$$
LFM=1-\frac{\sum\lambda_{MPF,L,est}}{\sum(\lambda-\lambda_{SPF}-\lambda_{RF})}\
\lambda_{MPF,L,est}=\lambda\times\left(1-\frac{K_{DC,MPF,L}}{100}\right)
$$
其中:
- $λ_{MPF,L,est}$: 潜伏故障的估算的失效率
- $λ_{DC,MPF,L}$: 潜伏故障的诊断覆盖率。
- 由于$λ=λ_{SPF}+λ_{RF} +λ_{MPF} +λ_{S}$，所以残余故障多为双点或多点故障MPF。
[!Note]
$$
LFM=1 - \frac{(所有潜伏故障总和)}{(所有和安全相关失效率总和 - 单点故障总和 - 残余故障总和)}
$$

此外，硬件架构度量取决于相关项的整体硬件，都应符合规定的硬件架构度量的目标值:

针对ASIL (B)、C或D的安全目标，对于每一个安全目标，“单点故障度量”的定量目标值应基于下列参考目标值来源之一:

	ASIL B	ASIL C	ASIL D
单点故障率	≥90 %	≥97%	≥99 %

针对ASIL (B)、©或‍D的安全目标，对于每一个安全目标，“潜伏故障度量”的定量目标值应基于下列参考目标值来源之一:

	ASILB	ASILC	ASILD
潜在故障率	≥60 %	≥80 %	≥90 %

需要注意的是:

硬件架构的度量是针对于相关项的整体硬件，非一个单独的硬件部件，需要考虑所有相关硬件的失效率。
度量指标，即SPFM和LFM，均属于相对值，即百分值%。

硬件随机失效的评估

随机硬件失效的评估旨在从硬件整体设计的角度，即综合考虑不同类型硬件随机失效，确保硬件系统安全机制和设计的有效性。ISO 26262对这一评估推荐了两个方法：

方法一: 使用概率的绝对值的度量, 即随机硬件失效概率度量(probabilistic metric for random hardware failures, PMHF)，通过使用定量分析方法计算PMHF，其结果与目标值相比较的方法，评估是否违背所考虑的安全目标。
方法二: 独立评估每个单点和残余故障及每个双点故障是否导致违背所考虑的安全目标。

一般在实际应用中都采用第一种方法，即PMHF。关于PMHF计算公式网上有很多误解，在ISO 26262-10:2018，第8.3章节增加了有关PMHF计算的进一步解释。一般来讲，PMHF通用化计算公式如下：

$$
PMHF=∑λ_{SPF} + ∑λ_{RF} + ∑λ_{DPF_{det}} × λ_{DPF_{latent}} × T_{Lifetime}
$$
其中:

$λ_{SPF}$: 单点故障的失效率
$λ_{RF}$: 残余故障的失效率
$λ_{DPF_{det}}$: 双点故障的可探测失效率
$λ_{DPF_{latent}}$: 双点故障的潜伏失效率
$ T_{Lifetime}$: 车辆生命周期。

需要注意的是:

PMHF表示在汽车运行周期中每小时平均失效概率，包括了对单点失效，残余失效，可探测的以及残余的双点失效的综合量化衡量。
PMHF单位为FIT，属于失效率绝对值度量，而硬件架构度量指标SPFM，LFM单位为%，属于相对值度量。
除基本硬件随机基本故障的失效率以外，PMHF还需要考虑车辆生命周期(T Lifetime)。
对于双点故障(A,B)，最常见的组合是功能故障A和对应的安全机制B，当故障A发生且不被安全机制B探测，并不会立刻违背安全目标；但如果安全机制B也发生故障，将违背安全目标。

很对朋友搞不清楚为什么双点故障失效率计算是$λ_{DPF_{det}}$, $λ_{DPF_{latent}}$, $T_{Lifetime}$这三个因素的乘积?

其实该公式已经属于简化后的计算公式，在ISO 26262-10:2018对典型的双点故障不同的失效模式进行了分析，一共包含了4个Patterns，功能发生故障A且对应的安全机制B潜伏这种Pattern下，双点故障会在整个车辆生命周期永久潜伏，影响最大，因此故障A和故障B组合违背安全目标的每小时平均失效概率为$λ_{DPF_{det}}$, $λ_{DPF_{latent}}$, TLifetime这三个因素的乘积，双点故障失效计算因此也简化为该Pattern下的失效率，具体见ISO 26262-10:2018。

如果这部分数值较小，则可忽略，这也是为什么在很多计算中没有考虑这部分的原因。

此外，虽然失效率λ和PMHF单位均为FIT，属于绝对值度量，但二者意义完全不同，主要体现在以下几点:

针对级别不同
- 失效率: 单个硬件组件。
- PMHF: 整个相关项硬件。
代表意义不同
- 失效率: 表示单位时间内单个硬件组件或零部件发生故障的次数或概率。
- PMHF: 用于衡量硬件安全设计是否足够有效。具体来讲就是，相对于指定的ASIL等级要求，由于相关项的随机硬件故障而导致的安全目标被破坏的风险是否足够低。PMHF并不显示随机硬件故障发生的频率。即便一个硬件组件的故障率很高，但由于良好的硬件架构，包括安全机制，整体的PMHF也可能较低。

此外，随机硬件失效度量取决于相关项整体硬件，需要分析计算不同安全目标对应的PMHF值，并且符合规定的随机硬件失效率度量目标值:

针对ASIL (B)、C或D的安全目标，必须为随机硬件失效导致违背每个安全目标的最大可能性定义定量目标值，其使用来源包括以下:

来自下表
来自值得信赖的相似设计原则的现场数据
来自应用于值得信赖的相似设计原则中的定量分析技术。

ASIL	Random hardware failure target values
D	<$10^{-8} h^{-1}$
C	<$10^{-7} h^{-1}$
B	$<10^{-7}h^{-1}$

此处需要注意的是:

表提供的PMHF定量目标值只是一种可能性，并不是唯一的依据。
这些来源的定量目标值没有任何绝对的意义，仅有助于将一个新的设计与已有设计相比较。其目的是生成硬件可靠性设计指导，并获得设计符合安全目标的可用证据。
当没有其他来源可以确定随机硬件故障失效目标值，通常会选择上表提供的目标数据。

随机硬件失效量化FMEDA

FMEDA步骤

FMEDA(Failure Modes Effects and Diagnostic Analysis) 是一种评估系统安全架构和实施的强大方法，多用于硬件定量分析。

和FMEA定性分析不同，FMEDA在FMEA 自下而上的方法论基础上增加了对硬件故障定量化的评估内容，包括模式失效率(Failure rate)、故障模式占比(Failure mode distribution)和对应的安全机制诊断覆盖率(Diagnostic coverage)，对FMEA进行扩展从而可以完成定量分析，是计算硬件概率化度量指标的有效手段，其具体流程如下图所示：

FMEDA步骤

计算失效率

首先，需要根据系统硬件架构，罗列所有硬件单元，为了方便分析和计算，可以对硬件单元按照类型进行分组。

然后，根据行业公认的标准(SN29500, IEC 62380)，历史或测试数据，查询各硬件单元失效模式以及对应的失效率分布。此过程可以采用手动模式，或者采用利用相关软件，输入系统硬件单元，进行自动化查询及计算。

例如，控制器硬件ALU算术逻辑单元：

它的失效率λ=0.348 FIT，即该电阻在$10^9 $h内平均存在0.348次失效。
它存在三种失效模式: FM1, FM2, FM3。
三种失效模式对应的失效分布比例：FM1->25%，FM2->25%，FM3->50%。

三种失效模式

识别故障模式

对步骤1中列出的硬件单元进行安全分析，根据故障分析流程图，确定其故障模式是否和功能安全相关以及故障的类型：

识别故障模式

如果和功能安全无关，则为安全无关的安全故障。
如果和功能安全相关，则需要进一步分析，确定其故障的类型，包括单点故障或双点故障等(和功能安全相关的三点及以上的故障也属于安全故障)，以及是否存在相应的安全机制。

不是所有硬件单元的故障都会导致安全目标的违背，为了方便有效识地识别和功能安全相关的故障以及故障类型，可以采用FTA安全分析方法，对不同安全目标SG进行自上而下的安全分析，识别出违反安全目标的底层事件，根据不同底层事件和安全目标之间的关系，即’‘与门’‘和’‘或门’'，就可以基本识别出不同故障类型。

例如，进行最小割集分析，级数为1的最小割集对应的底层事件就是单点故障，级数为2则为双点故障等等，可以由软件直接得到。

当然，也可以将步骤1得到硬件组件的失效率作为FTA底层事件失效数据的输入，利用FTA分析工具，进行故障的识别和后续硬件失效相关的度量计算。

计算诊断覆盖率

根据识别得到的硬件单元实施的安全机制，确定诊断覆盖率数值，在ISO 26262-5:2018附录D中，提供了硬件系统不同组件，包括传感器，连接器，模拟输入输出，控制单元等常见的安全机制以及对应的诊断覆盖率。

一般安全机制诊断覆盖率可以根据相应的公式进行计算，但过程相对比较复杂，所以多采取保守估算方式。

对于给定要素的典型安全机制的有效性，ISO 26262-5:2018附录D按照它们对所列举的故障覆盖能力进行了分类，分别为低、中或高诊断覆盖率。这些低、中或高的诊断覆盖率被分别定义为60%、90%或99%的典型覆盖水平。

计算诊断覆盖率

继续以ALU为例：

针对故障模式FM2和FM3，在硬件设计中存在相应的安全机制SM1和SM2，其对应的诊断覆盖率分别为90%和60%。

以此方式，计算所有硬件单元的安全机制的诊断覆盖率。

计算量化指标

根据硬件架构度量指标SPFM，LFM以及随机硬件失效评估PMHF计算公式，计算相应的指标。
$$
SPFM=1-\frac{\sum(\lambda_{SPF}+\lambda_{RF,est})}{\sum\lambda}\
\lambda_{RF,est}=\lambda\times\left(1-\frac{K_{DC,RF}}{100}\right),
$$

$$
LFM=1-\frac{\sum{\lambda_{MPF,L,est}}}{\sum{\lambda - \lambda_{SPF} - \lambda_{RF}}}\
\lambda_{MPF,L,est}=\lambda\times\left(1-\frac{K_{DC,MPF,L}}{100}\right)
$$

$$
PMHF=\sum \lambda_{SPF} + \sum \lambda_{RF} + \sum \lambda_{DPF_{det}} \times \lambda_{DPF_{latent}} \times TLifetime
$$

优化设计

根据步骤4计算结果，对硬件设计可靠性进行综合评估，判定是否满足指定的ASIL等级要求，如果满足则分析结束，否则需要根据计算结果，优化硬件设计，增加新的安全机制或者采用更高诊断覆盖率的安全机制，然后再次进行计算，直至满足安全需求为止。

FMEDA计算实例

虽然在ISO 26262-5:2018附录中已经添加了有关硬件架构度量和随机失效率评估的实例，但由于其过程介绍相对简单，导致很多朋友仍然搞不清楚计算过程，接下来就以其中一个实例为例，介绍如何利用FMEDA进行硬件概率化度量指标的计算过程。

下图为某ECU硬件设计图，针对其安全目标: ‘‘当速度超过 10km/h 时关闭阀1的时间不得长于20 ms’’。安全目标被分配为 ASIL C 等级。安全状态为：阀1打开(I61控制阀1)。

优化设计举例图

针对该安全目标，罗列所有硬件组件，如下表所示，根据FMEDA步骤1至4，分别查询硬件组件失效率，失效模式及分布比例，并计算相应的硬件度量指标。

安全目标定量

例如，对于控制芯片uc而言，其失效率为100 FIT，存在两种失效模式，其分布比例各占50%，只有第一种失效模式和安全相关，第二种失效模式则无需考虑。

由于安全机制SM4的存在，对该硬件组件第一种故障的诊断覆盖率为90%，该硬件组件

单点或残余故障失效率为：
$$
\lambda_{SPF/RF}=100 \times 50% \times (1-90%)=5FIT
$$
由于安全机制SM4还能够对该故障进行探测，防止其成为潜伏故障，其诊断覆盖率为100%，则该硬件组件的双点潜伏故障失效率为：
$$
\lambda_{DPF_{latent}}=0FIT
$$
除单点故障，残余故障及双(多)点潜伏故障，剩余的则是可探测双点潜伏故障，则硬件组件的双(多)点故障的可探测失效率为：
$$
\lambda_{DPF_{det}}=100 \times 50% - \lambda_{SPF/RF} - \lambda_{DPF_{latent}}=50 - 5 = 45FIT
$$
依此计算所有硬件组件的相关故障失效率，并进行如下统计：

故障失效率	数值
单点或残余故障总和	$\sum{\lambda_{SPF}}+\sum{\lambda_{RF}}=5.48FIT$
双(多)点故障潜伏失效率总和	$\sum{\lambda_{DPF_{latent}}}=12.8FIT$
双(多)点故障可探测失效率总和	$\sum{\lambda_{DPF_{det}}}=69.822FIT$
车辆生命周期	TLifetime=10000h

则该ECU硬件整体概率化度量指标计算如下：
$$
SPFM=1-\frac{5.48}{157}=96.5%\
LFM=1-\frac{12.8}{157-5.48}=91.6%\
PMHF=\sum \lambda_{SPF}+\sum \lambda_{RF}+\sum \lambda_{DPF_{latent}}\times \lambda_{DPF_{det}} \times TLifetime\
=5.48(FIT)+12.80(FIT)x69.822(FIT)×10000(h)\
=5.489FIT
$$
根据该安全目标ASIL C，判断其可知，除SPFM没有>=97%外，其他指标均满足相应安全要求，所以该硬件设计基本满足安全目标ASIL C等级需求。当然，也可以对硬件设计进行进一步优化，提高SPFM架构度量值。

软件阶段

软件开发模型及安全需求

软件安全需求

功能安全软件开发始于需求开发，即软件安全需求(Software Safety Requirement, SWSR)，而SWSR源于分配至软件组件的TSR，是软件相关的TSR在软件层面的进一步细化。

SWSR定义相对比较简单，但需要注意的是，很多朋友认为只要定义软件相关安全机制就足够了，其实除此之外，SWSR还包含和安全机制无关的SWSR，它是保证功能安全的基础或支持内容，SWSR一般来讲:
$$
软件安全需求SWSR = 安全机制无关的软件安全需求 + 软件安全机制
$$
安全机制无关的软件安全需求包括:

使标称功能可以安全执行的功能等。例如: 软件安全运行相关基础软件，包括操作系统，时钟，运行模式等。
在生产、运行、服务和报废过程中与车载测试和非车载测试相关的功能。例如: 车载通信、密钥管理或闪存数据安全检测等，或OBD II相关内容，包括故障存储，读取，清除等。
允许在生产和服务过程中对软件进行修改的功能。例如: 可配置性数据或标定数据，以满足多车型软件复用或者升级。
软硬件接口规范要求。例如: I/O接口，通讯等信号安全需求。
对软件功能和特性的要求，包括对错误输入的鲁棒性、不同功能之间的独立性或免于干扰、或软件的容错能力。例如: FFI中软件分区。

软件安全机制包括：

与应用软件本身、基础软件或操作系统失效探测、指示和减轻有关的自检或监控功能。例如: 应用层软件程序流监控，输入，输出合理性检测等; 基础软件自检等。
与安全相关硬件要素故障探测、指示和减轻相关的功能。例如: 涉及基础软件相关安全机制，包括控制单元电源，时钟，内存等硬件要素故障信息探测，指示和控制。
使系统达到或维持安全状态或降级状态的功能。例如: 错误管理，安全状态等。

TSR->SWSR

SWSR属于由软件相关的TSR细化得到软件层面安全需求，只要在系统开发阶段有效识别出软件相关的TSR，SWSR导出相对比较容易。

具体来说，根据分配至软件组件的TSR，对其进行进一步安全分析或直接根据经验，导出更为详细的SWSR，需要注意的是:

在实际操作中，除安全机制相关的SWSR外，还需要根据适用性，充分考虑上述提到的非安全机制相关SWSR，尤其是软硬件接口规范和FFI免于干扰的安全需求，它们是保证软件功能安全重要内容。
FFI免于干扰的安全需求多和基础软件相关，部分属于安全机制。在实际操作中，一般会将SWSR分为应用层软件安全相关和基础软件相关的安全需求，便于后续独立开发。

软件需求书写实践原则

软件需求作为后续软件开发的重要输入，其质量很大程度上决定了软件开发质量，所以写好需求是门技术，需要对系统及Stakeholder需求有充分的理解，这也是为什么近几年需求的定义和管理越来越受到企业重视的原因。

鉴于此，接下来我们聊一下软件需求书写实践原则，具体包括以下内容：

层次化。
需求不可分解，不要将两个要求合二为一，保持需求细化。
应该使每个要求表述尽可能完整和准确，无歧义，无冗余，不要输入可能使开发人员感到困惑的不合理的额外信息
除了需求本身，可以添加规则或示例、范围陈述或目标进行补充。
需求定义软件该做什么，而不是不该做什么。
有必要在文档中记录所有假设。
需求可验证性。
需求可追溯性。

软件架构安全设计

软件架构安全设计任务

软件安全架构旨在刻画出实现软件功能安全基本的软件框架，需要在系统架构的基础上，对其软件部分进行进一步细化，开发满足软件功能安全要求的软件架构设计。

一般来讲，软件架构设计需要同时考虑安全相关和非安全相关的软件要求，安全相关的需求甚至很大程度上决定了软件架构的形式，例如，是否需要分层设计，软件分区等。

对于分层式软件架构设计，功能安全架构部分可以相对独立进行设计。但不管安全或非安全相关软件架构的设计，其任务都在于描述：

软件架构要素的静态设计方面，包括：
- 分级层次的软件结构；
- 数据类型和它们的特征参数；
- 软件组件的外部接口；
- 嵌入式软件的外部接口；
- 全局变量；
- 包括架构的范围和外部依赖的约束。
- CPU的负载率、ROM、RAM等使用率
软件架构要素的动态设计方面，包括：
- 事件和行为的功能链；
- 数据处理的逻辑顺序；
- 控制流和并发进程；
  - 状态机
  - 中断
  - 看门狗
  - 任务
  - 调度
- 通过接口和全局变量传递的数据流；
- 时间的限制。

所以，不管系统还是软件架构，都包含静态和动态特性，这两方面特性描述越全面，越利于后续软件详细设计，在实际应用中可根据需要选择。

软件架构开发常见视图

为了描述软件架构静态和动态特性，ISO 26262对软件架构设计的标记法进行明确规定，包括: 自然语言，非半形式，半形式(伪代码，UML,SysML，Simulink等)，形式记法(可运行代码)，其中对于ASIL等级C和D软件安全需求对应的架构设计强烈推荐采用半形式法进行。

在实际架构设计过程中，一般采用通用化建模语言UML或SysML，目前大部分架构设计软件都支持这两种设计语言，如Enterprise Architect， Cameo等。

此外，这些架构设计语言及软件和后续软件设计一脉相承，可以将相应的软件架构视图直接导入AUTOSAR或SIMULINK等软件开发工具，以此为基础直接用于软件详细设计。当然，也可以直接采用AUTOSAR等软件开发工具链进行，进行软件架构设计，形成ARXML描述文件，其图形化设计语言也属于半形式标记法。

为了刻画软件架构静态和动态特性，往往需要采用不同的软件视图，即从不同的角度，描述软件架构的行为。

UML或SysML为描述架构静态和动态特性，分别引入了两大类视图：

结构视图: 描述架构静态结构和接口。常见的结构视图包括，类图，组件图，复合结构图，包图等。
行为视图: 描述架构动态行为，例如数据流，控制流，不同状态切换等。常见的行为视图包括，用例图，活动图，时序图，状态图，交互纵览图等。

一般来讲，UML和SysML视图类型存在部分重叠，也存在一定差异，例如需求及参数视图属于SysML独有。二者在视图语言规则类似，UML多用于软件架构设计，而SysML多用于系统设计，二者可以混合使用。

[!tip]

疑问解答: 在软件定义汽车，为应对不断增加的软件复杂度，架构的重要性毋庸置疑，但很多朋友可能会好奇，为什么非要采取UML/SysML等半形式标记法描述架构，真的有必要吗?

图比传统语言，代码更清晰，易懂。

ISO 26262 对架构设计标记法明确，对于ASIL C和D的系统，强烈推荐使用半形式标记法，即UML或SysML。

图可以描述复杂系统或者过程，统一建模语言及视图统一了各种方法对不同类型的系统、不同开发阶段以及不同内部概念的不同观点，从而有效的消除了各种建模语言之间不必要的差异。

为基于AUTOSAR的系统设计阶段提供输入和后续软件详细设计提供基础。

软件架构安全设计

软件架构安全的设计的本质是将和架构相关的软件安全需求SWSR应用于软件架构设计，初步确定软件功能安全实现的基本框架和方式，为后续软件详细设计提供基础。

除经典AUTOSAR的软件架构，将软件整体分为应用层，TRE通讯层，基础软件层外，为实现软件功能安全，还会将功能安全和非功能安全软件进行分层设计。例如E-Gas三层架构，将软件整体分为功能层，功能监控层和控制器监控层，其中功能层和功能监控层均属于AUTOSAR中应用软件层，控制器监控层为基础软件层，二者相互统一，并不矛盾。

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

功能监控层安全设计
基础软件安全设计

功能监控层安全设计

对于软件监控层架构安全设计而言，主要是将软件架构相关的SWSR，即错误探测和错误处理安全机制，应用于软件监控层的架构设计。

功能监控层属于独立于软件功能实现的功能安全开发内容，一般按照相应ASIL等级进行独立开发，对功能层中功能安全相关部分进行监控，包括输入输出诊断，逻辑监控，故障分类及故障优先级仲裁等。

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

用于错误探测的安全机制包括：
- 输入输出数据的范围检查；
- 合理性检查(例如，使用期望行为参考模型、断言检查、或不同来源信号比较)；
- 数据错误探测（例如，检错码和多重数据存储）；
- 外部要素监控程序执行，例如，通过专用集成电路（ASIC）或者其他软件要素来执行看门狗功能。监控可以是逻辑监控或时间监控，或者两者的结合；
- 程序执行的时间监控；
- 设计中的异构冗余；或在软件或硬件中实施的访问冲突控制机制，与授权访问或拒绝访问安全相关共享资源有关。
用于错误处理的安全机制可能包括：
- 为了达到和维持安全状态的功能关闭；
- 静态恢复机制（例如，恢复块、后向恢复、前向恢复以及通过重试来恢复）；
- 通过划分功能优先级进行平稳降级，从而最小化潜在失效对功能安全的不利影响；
- 设计中同构冗余，主要侧重于控制运行相似软件的硬件中瞬态故障或随机故障的影响(例如，软件在时间上的冗余执行)；

具体来讲，在功能监控层架构设计过程中，可以根据具体监控的功能，进行相应的异构冗余计算，对其输入，输出，进行范围及合理性检查，异构冗余计算程序执行过程进行时内部或外部要素的时间或逻辑监控，一旦发现错误，通过错误处理机制，将系统导入安全状态。

实例：以整车控制器加速踏板信号为例，其ASIL等级要求一般为D，为了实现该安全需求，需要从软件和硬件两个方面着手: 硬件安全方面主要是加速度传感器本身冗余及双路冗余采样等。软件安全方面主要是以上述安全机制的具体应用，例如，两路加速踏板传感器信号自身故障诊断，信号电压范围是否在有效范围内，和制动踏板信号之间的合理性检验，双路信号是否同步等等。

同样，在软件开发过程中，ISO 26262并没有也没办法明确哪个ASIL等级应该采取哪些软件安全机制，根据个人经验，一般存在以下两种方式可以进行参考：

ISO 26262第5部分硬件开发附件中对不同类型安全机制诊断覆盖率进行高中低分类，可以依据安全机制覆盖率的中高低分别应用于ASIL D，C，B类型的安全需求。

依靠以往开发经验，一般对于ASIL D或C的安全需求，需要根据适用性采取目前State of Art的所有或大部分安全机制，对于ASIL B或A的安全需求，则没有明确要求。

方法	==	ASIL等级	==	==	==
:	==	A	B	C	D
1a	软件组件的适当分层结构	++	++	++	++
1b	限制软件组件的规模和复杂度	++	++	++	++
1c	限制接口规模	+	+	+	++
1d	每个组件内强内聚	+	++	++	++
le	软件组件间松耦合	+	++	++	++
1f	恰当调度的特性	++	++	++	++
1g	限制中断的使用	+	+	+	++
1h	软件组件的适当空间隔离	+	+	+	++
1i	共享资源的适当管理	++	++	++	++

基础软件安全设计

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

在经典的AUTOSAR软件平台，为实现独立于控制器硬件，多平台软件复用，采用了RTE层和基础软件层，通过标准化接口规范，逐级对硬件进行抽象，对上提供统一访问接口，以此实现软硬件分离。

对于基础软件安全设计而言，主要是对基础软件提出的更高的功能安全方面的需求，从ISO 26262角度而言，依据非或不同ASIL等级要素共存原则，基础软件开发存在两种方式：

全部依据最高ASIL等级开发

以AUTOSAR为例，全部基础软件，包括OS，内存分配，通讯等均统一按照最高ASIL等级开发。

优点: 安全性能高，软件主体为功能安全组件，之间无需额外安全机制保护，运行效率高。

缺点: 底层模块需按ASIL等级开发，成本高，但随着软件复杂度不断提高，为降低开发复杂度和增加软件可靠性，逐渐成为趋势。

ATUOSAR框架图

采用Partition、免于干扰(FFI)、要素共存措施

为降低开发成本，目前基于功能安全和非功能安全的Partition类型开发也尤为常见。为了实现非或不同ASIL等级要素共存，除了在功能监控层对其开发进行区别对待外，还需要在基础软件部分采用相应的安全措施，避免高ASIL等级软件受到低ASIL等级或QM软件的干扰，进而破坏安全需求，具体如下图所示:

Partition设计

==FFI干扰类型==

ISO 26262共定义以下三种类型的干扰:

执行和时序(Timing &Execution)干扰

软件在执行和调度过程中出现的组件间的干扰主要包括:
- 执行阻塞 (blocking of execution): 一个任务有CPU控制，阻塞了另外一个任务。
- 死锁 (dead locks): 每一个处于等待状态的任务相互等待释放已经被锁定的资源。
- 活锁 (live locks) : 进程状态不断变化，但仍相互依赖，永远无法完成它们的任务。
- 执行时间的不正确分配 (incorrect allocation of execution time)。
- 软件要素间的不正确同步 (incorrect synchronization between software elements)。
其对应的安全机制包括:
- 内外部看门狗(Internal/External Watchdog)
- 程序监控(Program Flow Monitor)
内存(Memory)干扰

软件组件内存干扰类型主要包括:
- 内容损坏(corruption of content)
- 数据不一致(inconsistent data (e.g. due to update during data fetch))
- 堆栈溢出或下溢(stack overflow or underflow)
- 对已分配给其他软件要素的内存进行读写访问(read or write access to memory allocated to another software element)
其对应的安全机制包括:
- 内存分区，使用内存保护单元(Memory Protection Unit , MPU)来实现软件分区。
信息交换(Exchange of information)干扰

发送方(Sender)和接收方(Receiver)之间的数据交换对系统的功能安全造成影响:
- 信息重复 (repetition of information)
- 信息丢失 (loss of information)
- 信息延迟 (delay of information)
- 信息插入 (insertion of information)
- 信息次序不正确 (incorrect sequence of information)
- 信息伪装或不正确寻址(masquerade or incorrect addressing of information)
- 信息损坏 (corruption of information)
- 从发送方传送到多个接收方的信息不对称(asymmetric information sent from a sender to multiple receivers)
- 发送方发送的信息只能被部分接收方接收(information from a sender received by only a subset of the receivers)
- 通信信道阻塞(blocking access to a communication channel)。
其对应的安全机制包括:
- 循环冗余校验(cyclic redundancy check)
- E2E保护 (End2End Protection)

==要素共存(FFI)解决方案==

看完这些FFI干扰类型，大家先不要慌，基础软件多标准化开发，在不同软件平台直接采用开发工具链配置即可。

例如，Vector提供AUTOSAR的ECU解决方案，包括源代码MICROSAR和DaVinci系列配置工具，其中和功能安全相关的软件模块 MICROSAR Safe.

针对FFI不同干扰类型以及安全机制，分别对应相应的基础软件安全模块，包括:

Safe OS，Safe RTE， Safe WDG，Safe E2E等等，具体使用需要根据相应开发工具链进行配置就可，但相对成本也较高。

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

软件架构细致程度应能够承载SWSR。
软件架构设计原则，包括: 适当分层，限制软件组件规模和复杂度，限制接口规模，组内高内聚，组间低耦合，限制中断使用等。
软件架构设计验证方法，包括: 设计走查，设计检查，控制流，数据流分析，仿真，快速原型等。
HWSR应被分配至软件架构中的组件。
不同或非ASIL等级软件组件开发需满足以下原则之一:
- 按最高ASIL等级。
- 要素共存FFI，例如软件分区。
对SWSR和具体实施之间的可追溯性。

软件详细设计

功能安全软件详细设计或者软件单元设计主要任务就是基于软件安全架构，对软件安全需求进行进一步实现。和非功能安全软件详细设计相比，功能安全软件详细设计，除了实现软件安全需求外，最主要的区别就是需要考虑由软件安全需求ASIL等级带来的开发约束，其主要包括:

建模和编码指南约束
不同ASIL等级软件单元设计语言或标记约束
软件单元设计原则的约束

此外，目前汽车软件开发多基于模型开发，即MBD，同样也适用于汽车功能安全软件开发，其开发流程，开发工具等均和正常的应用层软件开发一致，多采用SIMULINK，ASCET或AUTOSAR开发工具链等图形化开发语言进行，再通过RTE技术自动代码生成，这部分内容大家应该都比较熟悉，在此不再赘述。

以AUTOSAR开发工具链为例，MBD开发流程如下图所示：

MBD开发流程

软件安全测试内容及方法

根据软件开发V模型，软件安全详细设计完成之后，需要进行相应的软件验证，集成及测试等内容，即V模型右边内容，具体包括，软件单元验证(Software Unit Verification)，软件集成和验证(Software Integration and Verification)，软件测试(Testing of the embedded Software)，具体如下图所示:

软件测试开发v模型

验证VS确认

细心的朋友可能已经发现了，软件单元，集成后的软件组件用的都是Verification，即验证，非Validation，即确认。最后一部分嵌入式软件用的Testing，即测试，其实也属于验证。

验证(Verification): 提供客观证据，证明开发过程满足规定要求，

旨在回答: Are we building the product right？

简单说就是，关注实现过程，不看结果，即整个开发过程是不是按照规定的要求去做，工作输出物是否完整，至于输出结果是否满足客户预期功能或需求，不属于验证的范畴。
确认(Validation): 提供客观的证据，证明开发结果满足客户预期的功能或需求。

旨在回答: Are we building the right product？

简单说就是，关注结果，不关心过程，即不管开发过程，关心最终输出结果是否满足客户预期需要功能或需求。

例如: 对于把大象装进冰箱里这个需求，规定的要求是：

打开冰箱门

把大象放进冰箱

关上冰箱门。

验证需要做的是，检查你是不是按照这三个规定的步骤做的，如果你漏掉其中某个步骤或执行顺序有问题等等，验证就无法通过。

而确认需要做的是，不管你到底先开的冰箱门还是什么，重点是大象是否被装进了冰箱。有可能验证全部通过，但大象自己又从冰箱里走出来了，最后确认还是没办法通过🤣。

需要注意的是，确认(Validation)多发生在验证(Verification)之后，更多在系统或产品阶段，所以在ISO 26262中，软件，硬件开发V模型右边对应的测试均为验证过程，只有在系统阶段，系统集成后的对应的测试属于确认过程。

软件安全验证方法

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

软件单元验证方法

软件集成验证方法

嵌入式软件的测试方法

看到这里，很多朋友其实已经发现，虽然它们属于软件开发V模型不同测试层级，但很多测试方法是共通的，例如基于需求测试，接口测试，错误注入测试等等。

为更好地理解，我们可以从测试类型的角度，将以上测试方法分为:

静态分析(Static Analysis)
动态分析(Dynamic Analysis)

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

单元验证: 静态分析 + 动态分析，静态为主
集成验证: 静态分析 + 动态分析，动态为主
嵌入式软件验证: 动态分析

静态分析

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

软件/代码是否满足相关质量标准?

走查，结对编程，检查
控制流分析
数据流分析
静态代码分析

除不同类型的人为分析检查外，静态分析最最要内容为静态代码分析，主要目的是检查代码编写是否符合特定的编程规则。对于大部分车辆控制器代码而言，静态代码分析，即C代码静态分析(如果基于模型开发，则是自动生成的代码)，主要是保证代码满足MISRA C(Motor Industry Software Reliability Association, 汽车工业软件可靠性协会)相关的要求。

静态代码分析一般可以直接采用自动化检测软件，例如SIMULINK, Model Advisor; Vector, Vector CAST; Perforce, Helix QAC等，通过配置代码检测规则，然后导入源文件进行自动化分析，如果不满足相关要求，则需要对代码进行修改直至满足为止。

动态分析

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

软件/代码是否做了它应该做的?
- 基于需求测试
- 接口测试
- Back-to-Back测试
软件/代码是否做了它不应该做的?
- 鲁棒性测试
软件/代码是否足够?
- 结构覆盖性测试

重要的动态测试包括:

基于需求测试
- 基于分配的安全需求和测试环境，制定安全测试用例，测试用例一般包括5个关键参数，即: 初始状态或前提条件，数据设置，输入，预期输出，实际输出。
- 需管理需求和测试用例及结果的可追溯性，进行覆盖率解析。
接口测试
- 不同软件层次接口，包括信号名称，数目，数据类型，范围测试。
错误注入测试
- 即鲁棒性测试，故障注入测试主要目的是验证系统设计、软件设计过程所提出安全机制或安全措施的有效性，通过在特定位置注入错误，包括错误的数值，方向，频率等，对系统功能安全机制响应时间、诊断覆盖等内容进行验证。
Back-to-Back测试
- 基于模型设计的测试，验证模型和生成的代码的一致性，即采用相同的测试用例，同时输入模型和生成的代码进行执行，对二者输出结果进行比较，一致则通过，否则存在不一致。

除基本测试方法外，ISO 26262-6:2018对不同阶段的软件安全测试环境也有相应的要求:

单元验证及集成验证: 基于开发环境的软件测试，包括模型在环，软件在环，处理器在环，硬件在环。
嵌入式软件验证: 硬件在环或车辆

软件安全测试用例导出

静态测试多自动化完成，多不需要测试用例，相对比较简单，而动态测试基本上都需要用到测试用例，那如何导出测试用例，用尽可能少的测试用例，覆盖尽可能多的测试场景，这是个很重要的问题。

在ISO 26262-6:2018中，根据不用ASIL等级，对于软件单元，集成测试，嵌入式软件这三个层次的用测试用例导出方法基本类似，包括:

需求分析
等价类的生成和分析
边界值分析
基于经验的错误猜想
功能相关性分析
操作用例的分析

其中，等价类的生成和分析，可以基于划分输入输出来识别等价类，为每个等价类选择一个有代表性的测试值，这样可以有效降低测试用例数目，降低测试成本和时间。

函数覆盖率 vs. 调用覆盖率

例如，对于测试对象:

1
2
3

if A==1, then f1, f2, 
else if (0), then f3,
else, then f4,end

其中，f1，f2，f4均被定义，f3定义不存在。

该情况下，由于else if (0), 函数f3永远不会被执行，所以函数调用覆盖率为3/4=75%，但所有定义的函数均被执行，所以函数覆盖率为100%。所以，函数覆盖率多用于检测未被调用的多余函数，而调用覆盖率用于检测死代码。

MC/DC(修改条件/判定覆盖率)

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

在一个程序中每一种所有可能的输入和输出至少出现一次。
每一个判定中的每一个条件必须能够独立影响判定输出，即在其他条件不变的前提下，仅改变条件中一个值，而使判定结果改变。

什么意思呢，我们来看个实例。例如，对于测试对象:

1
2
3

if A and (B or C)， then⋯ 
else，⋯
end

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

MC/DC判定

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

为保证软件安全测试完整性，ISO 26262-6:2018还对软件单元，集成软件的测试覆盖率进行相应要求，具体包括:

软件单元层面结构覆盖率

软件架构层级的结构覆盖率

可以看出，软件单元层面结构覆盖率多基于语句，分支等最基本的代码组成部分测试，而集成后的软件架构层级的结构覆盖率多基于函数，其层级更高。二者逐步递进，可以有效评估软件安全测试的完整性和充分性。

需要注意的是:

结构覆盖率不需要一味追求100%，高结构覆盖率并不完全说明代码已经进行高质量充分测试，它只说明哪些代码没有被测试用例有效执行。
结构覆盖率测试可以帮我们反推前期测试用例设计是否充分，是否存在盲点，哪些地方需要进行补充，增加测试完整性。
结构覆盖率测试并不能解决软件事先没有考虑到的情形及功能不足。

软件安全分析FMEA

软件的Bug究竟源于什么？

总体而言，和系统和硬件失效相比，软件失效或Bug属于系统性失效，也就是由人为设计疏忽，错误等原因导致的确定性的失效问题，这些失效都必须通过相应的修改和调整才能消除。

但具体而言，软件的系统性失效或Bug，根据所处的软件层级不同，呈现出不同的特性:

软件单元或函数层级:

示例: 函数语句语法错误，变量错误，计算逻辑错误，死循环，函数漏写，漏定义等。

特点: 确定性强，易复现，易排除，多呈现静态特性。
软件架构层级:

示例: 执行时序错误，数据流错误，接口错误，资源抢占等。

特点: 不易复现，难排除，和FFI(Free from Interference)相关，本质上源于硬件随机失效问题，只是具体在软件层面的结果体现，多呈现动态特性，甚至不可或很难复现。

软件安全分析真的有必要做吗？

针对软件系统性失效问题，ISO 26262 一般通过安全开发流程的约束，即严格的开发流程要求及测试完备性要求，尽可能降低系统性失效的可能性。

所以，理论上来讲，即便没有软件安全分析过程，通过严格的安全开发流程约束(ASIL等级越高，安全开发流程约束越严格)，软件的系统性失效问题已经得到有效控制，这也是有些朋友认为专门的软件安全分析没有必要的原因。

但这个结论其实并不完全正确，或者至少在实际操作中，软件安全分析还是有其必要性，个人觉得主要原因在于:

随着汽车软件复杂性不断提高，软件组件的开发涉及多个开发团队的协同工作，软件组件之类的交互以及动态属性也愈加复杂，单纯的软件安全开发流程约束，很难完全覆盖软件失效问题。
系统架构层面的软件失效多具有动态过程，很难通过软件安全开发流程约束识别出来。
在ISO 26262 Part 6专门明确了软件安全分析的要求，这个也是2018版本新增的内容之一。
机器学习(AI)等非白盒模型的应用，使得软件可解释性降低，失效可能性增加，基于架构的安全分析虽然并不能使得非白盒模型完全可解释，但有助于从逻辑层面分析潜在失效问题。

综上所述，软件安全分析还是非常有必要，尤其是适用于比较复杂的或动态特性比较高的软件系统。

软件安全分析到底在分析什么？

在前面第一个问题"软件Bug到底源于什么?"中，我们聊到了软件系统性失效多存在于两个层级，即软件单元和软件架构层级。

由于软件单元层级的失效多带有静态特性，基本上可以通过流程约束覆盖。此外，针对软件单元层级的安全分析工作量巨大，实际操作可行性也不大，而架构层面的失效多涉及运行时序，数据流问题等，具有明显的动态特性，复杂度高，软件安全开发流程约束不容易检出，需要进一步通过安全分析进行识别，并制定相应的安全措施，对软件安全需求进行补充，执行，此次进行迭代，最终改善软件安全问题！

软件安全分析

所以，软件的安全分析的对象是软件架构，重点在于分析架构动态特性可能带来的功能安全问题，非具体的软件单元层面代码级别的语法，逻辑等错误，这样的软件安全分析才更有意义和实操性。

而对于软件动态特性而言，最常见且重要的的失效问题就是不同ASIL等级，或者安全和非安全相关软件共存，出现的避免要素之间的干扰问题(FFI, Free From Inteference)，即:

时序和执行;
内存；
信息交换。

所以在软件安全分析过程中，需要着重针对以上问题进行相应的软件安全分析。

那么紧接着的问题是，软件架构本身颗粒度也不同，我们应该分析到哪个颗粒度？

这个问题在ISO 26262中并没有规定，个人觉得可以从两个角度考虑这个问题:

根据软件架构的复杂度，选择一个在项目周期内可实施的颗粒度，但为了保证分析的有效性和完整性，颗粒度不可过大。
可以考虑以软件调度层级进行软件架构分析。

此外，需要特别注意的是，软件架构级别的安全分析不区分不同的ASIL等级，所有ASIL等级都必须执行！

软件安全分析究竟用FTA还是FMEA

在ISO 26262, Part 6附录E中，提到可以采用归纳或演绎的方法，识别可引发因果链而导致违反安全要求的设计缺陷、条件、故障或失效。

在实际操作中，比较推荐采用归纳分析方法，即FMEA(或STPA)，主要原因在于:

FMEA由原因到结果的分析过程，更适合软件安全分析的需求，即以软件架构为分析基础，识别潜在软件失效可能性。
在软件层面不存在类似于安全目标这样的顶层失效目标，软件安全分析不是将安全需求进行细化分解的过程，而是补充检查原有设计的不足。

软件安全分析怎么做?

前面聊到软件安全分析，多采用归纳分析方法，以FMEA为例，基本的安全分析步骤还是保持一致，只是会省略一些步骤，具体执行过程中也存在一定的差异:

分析范围及对象的确定

确定分析的对象，范围，以软件架构输入作为安全分析的基础，选择合适的软件架构颗粒度。

软件架构需要描述相关软件的静态方面(例如,显示功能要素及其接口/关系的框图表示)以及动态方面(例如,顺序图、时序图、调度图或状态图表示)。

软件架构的安全分析和相关失效分析可以遵循功能和/或处理链，同时考虑静态和动态方面。
软件模块结构分析

罗列分析对象对应的软件架构中所有的软件模块，并初步区分是否和安全相关。

这里需要注意的是，这里涉及的软件模块，不仅仅包括已经分配了软件安全需求的模块，还包括在分析范围内的正常功能软件模块！
失效模式分析

逐个分析软件模块的失效模式，这里可以使用引导词生成问题去检查架构要素的特定功能或特性。当使用引导词时，使用引导词重复执行每个设计要素的特定功能或特性的安全导向分析，直到预定的引导词都被检查过。

针对执行，调度或通信相关的引导词以及对应的可能的失效示例如下图所示:

以步骤一中的软件架构中的功能O为例，应用上述表格中的引导词，可以得到如下的软件故障:

以此为例，分析所有软件模块可能存在的失效情况，这一步也是整个软件安全分析过程中最耗时的部分。
制定安全改进措施

根据上一步骤所识别出的失效模式，制定相应的安全改进措施，如有必要，导出相应的软件安全需求，并进行软件架构更新。重复以上步骤，直至软件失效可能性足够低！

功能安全管理

功能安全管理属于ISO 26262-2:2018内容，主要是对功能安全的产品全生命周期的开发活动进行管理，如下图所示:

功能安全管理

功能安全管理涉及安全生命周期内所有安全活动的管理，其关键的安全管理任务是计划、协调和追踪与功能安全相关的活动，具体包括:

整体安全管理
在概念阶段及在系统、硬件和软件层面产品开发阶段的项目相关的安全管理
生产、运行、服务和报废的安全管理

安全管理和项目管理类似，只不过考虑到产品功能安全的重要性，一般由独立的安全经理负责对ISO 26262规定的各个开发及生产运行等阶段对应活动进行计划，管理，追踪。当然，在很多公司，为了降低人员成本，安全经理直接由项目经理兼任。

对大部分工程师而言，并不涉及生产、运行、服务和报废这些安全活动，所以接下来我们主要聊前两部分安全管理内容。

整体安全管理

所谓的整体安全管理，即独立于具体项目外的基本功能安全管理内容，旨在结合企业文化，建立起功能安全相关组织，流程等，创造安全活动实施环境，为具体项目的功能安全实施提供基基本条件，具体包括：

建立并维护功能安全文化;
建立并维护安全异常管理的流程；
对参与人员能力管理;

安全文化

安全文化是个很广泛的概念，也是企业文化重要组成部分，体现了企业对功能安全相关活动的重视程度，为此所创造的安全开发环境及在企业层面采取的应对措施。

虽然近几年大部分车企对功能安全重视程度不断提高，也有ISO 26262作为实施指导，但各车企对功能安全实施情况各不相同，很多企业还是处于探索阶段，甚至都没有专门的功能安全组织架构，功能安全多是空口号，为快速占有市场，企业更在意用户可以直观感受到的的动力性能，外观，内饰是否豪华，显示屏幕是否够大等。

功能安全问题虽然是相对小范围事件，但当大批量汽车产品暴露在各种各样的驾驶环境和习惯下，安全问题就更容易暴露出来，由此带来消费者信任危机，从而导致销量下降，严重的可能会导致重大召回事件，对汽车形象和利润也会产生很大的负面影响。

企业如何建立安全文化呢？可以从以下几个方面着手:

企业应建立安全相关的组织架构，保证有相应的人力和物力资源实施功能安全相关活动。
企业应建立专门规章和流程，以实现且维护功能安全并符合ISO 26262要求。
组织应创造，培育并保持一种安全文化，以支持并鼓励有效实现功能安全。
组织应建立并维护功能安全、预期功能安全、信息安全及与实现功能安全相关的其他领域之间的有效沟通渠道。

安全文化的建立，并不是空口号，尤其是组织架构和研发流程的建立非一朝一夕，需要和企业内部研发流程相结合并持续优化:

对小公司来讲，生存是首要任务，功能安全实施耗时耗力，安全文化很难落地，更多的只能依靠优秀个体或团队的经验，对产品可能存在的较大的风险重点把控，展开相应的功能安全开发活动。
对于大公司而言，随着业务增加，组织复杂化，安全文化建立必不可缺，需要将安全文化融入自身组织架构及研发流程当中，不为流程而做，合理规划安全开发活动，优化开发流程，走出自己的一条功能安全路线。

功能安全异常管理

在整个产品生命周期，在产品功能安全活动实施过程中，难免会需要一些异常情况，例如，某活动阶段工作输出结果缺失或错误，或供应商临时更换等等，这就需要相应的异常管理机制，对功能安全相关的异常情况进行有效识别，管理，解决及关闭，具体包括：

有异常沟通，传达渠道
异常建立，维护，解决，关闭流程

只有通过充分安全措施解决了异常情况，并得到有效验证，或者异常不构成不合理风险才能够关闭异常。

能力管理

人作为功能安全活动的执行者，其专业及技术能力直接决定了产品功能安全落地效果，所以企业有义务对其能力进行管理，包括内外部培训，招聘有经验的功能安全工程师，项目咨询等，确保执行安全生命周期活动的人员具有与其职责相匹配的技能水平、能力和资质。

项目相关安全管理

整体安全管理是基础，而项目相关的安全管理涉及项目具体操作，主要是用于指导整个项目运行过程中不同阶段安全活动的开展。

根据ISO 26262-2:2018，项目相关的安全管理主要包括以下几个方面内容:

安全活动管理角色和任务分配
相关项层面的影响分析
现有要素的复用
安全活动的裁剪
安全计划指定，协调，追踪
安全档案
认可措施
认可评审
功能安全审核
功能安全评估

这个分类相对比较琐碎，为了更好理解，我们可以将这些内容可以归为四类：

安全活动管理角色和任务分配

这个比较好理解，在每个相关项产品开发的启动阶段应指定一名项目经理或者安全经理，负责整个安全活动的计划，协调和任务分配。

安全活动影响分析

现有汽车产品开发大多不是零基础开发，多可以复用以往项目内容和经验，以此来降低项目成本和周期，这同样也适用于功能安全开发。

安全活动影响分析本质就是根据现有项目的安全需求，通过影响分析手段，识别以往哪些项目内容或在多大程度上可以进行复用。

一般来讲，安全活动影响分析分为两个层面:

相关项层面的影响分析:

安全生命周期开始，主要是针对相关项层面的影响分析，以确定相关项是全新开发，或是对现有相关项修改，还是对现有相关项的使用环境进1行修改。即从整体的角度，确定项目开发类型，大体判断以往哪些项目开发内容可以复用以及修改措施。
有要素复用:

发生在相关项层面影响分析之后，属于相关项内部要素层面的影响分析，包括软件要素复用，硬件要素复用，需要具体分析是否需要对复用要素进行修改以及如何修改。

对于现有要素复用影响分析还需要进一步提供以下复用证明:
- 满足软件组件的鉴定，具体见ISO 26262-8:2018第12章；
- 满足硬件要素的评估，具体见ISO 26262-8:2018第13章；
- 满足在用证明，具体见ISO 26262-8:2018第14章和ISO 26262-10:2018第10章；
- 独立于环境的安全要素(SEooC)，具体见ISO 26262-10:2018第9章。

2.3 安全计划

安全计划用于计划和协调组织所参与的功能安全活动，无非就是在项目之初，系统地计划什么人在什么时间节点应该做什么事，主要输出结果有哪些，应该满足什么要求，并和整个项目计划相匹配。

具体而言，安全计划主要包括以下内容：

将独立于项目的安全活动应用到项目特定的安全管理中；
安全活动裁剪；
符合ISO 26262-3、ISO 26262-4、ISO 26262-5、ISO 26262-6要求的安全活动；
支持过程计划；
符合ISO 26262-3、ISO 26262-4、ISO 26262-5、ISO 26262-6和ISO 26262-8第9章要求的集成和验证活动计划，及根据ISO 26262-4第8章的安全确认活动计划；
认可措施安排；
符合ISO 26262-3、ISO 26262-4、ISO 26262-5、ISO 26262-6、安ISO 26262-9第7章及第8章要求的相关失效分析、安全分析计划；
如果适用，提供候选项的在用证明；
如果适用，提供所使用软件工具的置信度。

安全计划一般由安全经理完成，ISO 26262并没有给出具体的安全计划模板，在实际操作中，可结合上述标准内容及项目实际情况，确定其内容和结构。

需要注意的是，安全计划需要充分考虑安全活动影响分析的结果，根据实际情况对参考的生命周期中规定的安全活动进行裁剪，省略或者修改某一安全安全活动，并应给出理由说明为什么剪裁对于实现功能安全来说是恰当且充分的。

安全认可措施(Confirmation measures)

为了保证功能安全开发活动的有效性，需要对安全活动各阶段重要的工作成果及流程进行安全认可，提供充足并令人信服的证据，证明其对实现功能安全的贡献，这就是所谓的安全认可措施(Confirmation Measures)。

根据ISO 26262-2:2018，安全认可措施(Confirmation Measures)包括三个维度:

认可评审(Confirmation Review)
功能安全审核(Functional Safety Audit)
功能安全评估(Functional Safety Assessment)

很多朋友搞不清它们之间的区别，甚至误认为认可措施就是认可评审，它们三者主要区别为:

安全认可措施

总言之:

认可评审(Confirmation Review)和功能安全审核(Functional Safety Audit)分别是工作输出成果和流程的检查，和Verification类似，判断其是否满足ISO 26262规范要求，并不关心所实施的安全措施是否能够保证产品功能安全。
功能安全评估(Functional Safety Assessment)则是对结果有效性的检查，和Validation类似，只不过是通过评审的方式进行，判断通过相应安全措施的实施，最初定义的功能安全目标在相关项层面是否能够满足。
功能安全评估(Functional Safety Assessment)需要考虑认可评审(Confirmation Review)和功能安全审核(Functional Safety Audit)输出结果，进行综合判断。

除此之外，ISO 26262-2:2018还有认可措施的独立性有所要求，ASIL等级越高，所对应的认可执行者的独立性要求越高(包括I0 - I3)，认可措施部分内容如下表所示:

要求认可措施

其中:

I0：宜执行认可措施；但如果执行，应由与负责创建工作成果的人员不同的人员执行。
I1：认可措施应由与负责创建工作成果的人员不同的人员执行；
I2：认可措施应由独立于负责创建工作成果的团队的人员执行，即由不向同一个直接上级报告的人员执行；
I3：认可措施应由在管理、资源和发布权限方面与负责创建对应工作产品的部门独立的人员执行。

外部措施

在功能安全分析过程中，很多朋友搞不清:

到底什么是外部措施？
外部措施可以降低ASIL等级吗？
外部措施为什么能够降低ASIL等级？

到底什么是外部措施?

所谓外部措施是指在相关项边界外减少或减轻相关项故障行为造成的潜在危害的措施。

关于外部措施定义需要注意以下几点:

外部措施必须存在于所定义的相关项外部，这也是"外部"一词的体现。
外部措施可以是车内车载装置，如车辆稳定控制系统或防爆轮胎，安全气囊等，也可以是车外装置，如防撞护栏或隧道消防系统等。
外部措施是相对的，会随相关项定义不同发生变化，如对于传动系统而言，ESP属于外部措施，但对制动系统则不是。

需要注意外部措施和在HARA评估过程中潜在处于风险中人员的合理假设的区别。

例如假设驾驶员处于正常的状态（例如，驾驶员不疲劳），接受了恰当的驾驶员培训（驾驶员有驾驶执照）并且遵守所有适用的法律法规，包括应有的谨慎以避免为其他交通参与者带来风险。这些都属于正常假设，非外部措施，不会因相关项定义不同而发生变化，也不会减少或减轻相关项故障行为造成的潜在危害。

外部措施可以降低ASIL等级吗？

外部措施可以在危害分析和风险评估过程中，降低危害事件的ASIL等级，进而降低安全目标的ASIL等级。

但需要注意的是，外部措施必须独立于相关项实施的功能，独立性是应用外部措施的基本要求，否则不能在HARA中考虑。

例如，车辆发生非预期移动时，相关项定义为传动系统，此时自动变速器驻车功能，或者档位和离合器的结合，可以有效防止车辆移动，但这些措施都和传动系统直接相关，属于相关项内容，不符合独立性要求，不可作为外部措施。

外部措施为什么能够降低ASIL等级？

这个问题可以从两个角度回答:

从ASIL等级评估过程中讲:

严重性(S), 暴露度(E), 可控性©这三个参数直接决定了ASIL等级，外部措施降低ASIL等级无非就是降低危害事件风险评估中S, E, C这三个参数中某个或某些的取值，一般来说外部措施对S和C值影响较大，E值多和运行场景相关，外部措施基本很难改变。

例如，路边防碰撞栏杆，安全气囊的的存在可以降低车辆发生碰撞时对驾驶员和乘客的伤害程度，因此降低了S值。

由于车辆稳定系统的存在，可以有效增加车辆发生非预期加速或减速时的驾驶员对车辆的可控制，因此降低了C值。

从外部措施应用的本质上讲:

外部措施降低安全目标ASIL等级的本质是ASIL等级分解，这也是应用外部措施时对其独立性要求的原因。

通过ASIL等级分解，将一个高的ASIL等级降级分配给相关项内部和独立于相关项的外部的两个安全需求。

那既然这样，外部措施应用除了独立性外，还有外部存在这个要求呢？

主要原因在于外部措施多用于降低安全目标ASIL等级的假设，只有外部存在的独立措施的不会在后续安全分析中再次被作为降低风险的措施，而内部安全措施是实现ASIL等级的必要条件，不能被重复考虑。

实施外部措施在后续功能安全开发中需要注意什么？

如在危害分析和风险评估过程中的考虑了外部措施(如降低安全目标的ASIL等级)，则在后续安全分析中不能再次认为此外部措施是一个减少风险的途径。
在后续功能和技术安全方案中，需要明确外部措施的功能和技术需求，包括接口，功能特性等。
外部措施作为一种降低ASIL的技术假设，在安全确认活动期间需要提供证据证明外部措施的充分和可靠性。