汽车功能安全标准于2011年作为ISO标准正式颁布，此后，汽车业界开始采纳应用该标准。

虽然标准的采纳是自愿的，但在这样的背景和趋势之下，无论是汽车厂商还是零部件供应商，为了满足ISO 26262的要求，要尽快调整体制，完善规章制度，构筑基于规格的生产流程，并由负责ISO 26262认证的第三方机构进行认证。

一、功能安全

什么是功能安全？所谓的“功能安全”，就是通过安全功能和安全措施来避免不可容许的功能风险的技术总称。功能安全（Function Safety）的“功能”指的是监控受控对象和控制器的安全装置起的作用。通常我们将计算机作为安全装置，如果控制器发生故障，则该计算机将会关闭受控对象，并向用户发出危险警告。安全装置所实现的这种安全性作用，被称为“功能安全”。功能安全可以说是通过使用计算机等的安全装置所设计出的安全措施。

但是，在这里不得不提醒大家，安全本身并不是通过增加某种电子安全设备来保证的，而是通过“去除”导致危险发生的设计或机械故障的安全机制来保证。这种安全机制被称为“本质安全”。

举个栗子，这是一个非常经典的例子：

比如在铁路道口，我们常常有这样的危险顾虑，就是有人或者车辆进入到了铁道入口，和火车相撞，导致死亡。“本质安全”就是从根本上避免危险的措施，把危险源直接“除掉”，方法是可以把这个铁道道口改为立交桥。但是在某些情况或某些制约下，不能把铁道道口“除掉”，自然就会想到附加一个安全设施，这就是功能安全。因为某些制约，不得不设置铁路道口，但大家还要想避免这样的交通事故，那怎么办呢？这是功能安全。

欧美已经颁布了成套的功能安全相关产品指令和设计标准，并深入到各个领域，在核电行业、石油、化工、电厂等过程工业，工业机器、电梯扶梯、智能电网、家电软件评估、汽车行业、医疗软件评估领域广泛应用。

这里，我们只谈汽车功能安全。

二、功能安全制定的历程

功能安全标准化的运动起源于20世纪90年代。

上世纪70年代开始，随着各种现代化及其的使用，以及工业生产过程的自动化程度越来越高，以电气、电子、可编程电子产品的大量应用为标志的现代化控制系统越来越多的渗透到各个领域，参与着各种控制过程。

但是，工业文明在给人类带来利益的同时，也带来了灾难。由于系统设计不合理、设备元器件故障或失效、软件系统的故障导致的事故、人身伤害、环境污染，越来越频繁的危及着我们的生命安全和赖以生存的环境。

人们开始认识到，必须采取措施，用标准和法规来规范领域内安全相关系统的使用，使技术在安全的框架内发展，使人类既能尽可能享受新技术带来的安全和舒适，同时又能掌控危险。功能安全标准研究从此展开。

然而，安全控制系统或设备执行安全功能时的可靠性问题，限制了用户使用新技术的积极性。由于没有公认的评价体系，制造商很难说服用户使用新技术，尤其在关系人身财产安全的重要领域使用新技术。另外，不同行业对安全要求的不同，也限制了安全设备的产业化生产规模。制造商迫切需要一个公认的标准来建立一个与用户对接的公共平台。

于是，2000年5月，国际电工委员会正式发布了IEC61508标准，名为《电气/电子/可编程电子安全相关系统的功能安全》。

IEC61508中，系统中的安全设备（减少风险的手段）由中继控制器或PLC（Programmable logic控制器）等设备构成，我们把安全设备将实现其安全功能的可靠性的概率称为安全完整性水平，即SIL（Safety Integrity Level）。换句话说，基于这个等级标准，即，如果与构成安全系统的部件的故障率低，则由此构成的整个安全系统的故障率也是低的。

但是，有一种观点认为，在SIL定义中加入概率因素并不合适的。为什么不合适呢？那是因为功能安全标准不仅涉及了硬件部分，还涉及了软件部分。仅论硬件故障发生的概率，除了初始故障和损耗故障以外，偶发故障基本是随机发生的，如果把设计错误分开，那么加入概率因素是非常合适的。与此相对的软件故障可不是随机的了，所以软件故障(bug)是很难去计算其发生的概率的。例如，如果软件的设计中混入了bug，只要其发生路径和条件具备，那么故障的发生概率就是百分百！

针对这个问题，对IEC 61508重新修订制定了ISO 26262标准。2011年11月，ISO 26262正式颁布。

ISO 26262 不同于 IEC 61508，它“不是一个可靠性标准”，它并没有为可接受失效概率设定准确的数字。ISO 26262基于概率论的定量危害分析仅限适用于硬件，其次，基于目标产品的使用条件和使用方法，针对整个系统进行危害分析和风险评估，识别出系统危害并对危害的风险等级——ASIL等级（Automotive Safety Integration Level，汽车安全完整性等级）进行评估。IEC 61508定义了安全完整性等级 (SIL)，而 ISO 26262 则定义了汽车安全完整性等级 (ASIL)。

ASIL有四个等级，分别为A，B，C，D，其中A是最低的等级，D是最高的等级。然后，针对每种危害确定至少一个安全目标，安全目标是系统的最高级别的安全需求，由安全目标导出系统级别的安全需求，再将安全需求分配到硬件和软件。ASIL等级决定了对系统安全性的要求，ASIL等级越高，对系统的安全性要求越高，为实现安全付出的代价越高，意味着硬件的诊断覆盖率越高，开发流程越严格，相应的开发成本增加、开发周期延长，技术要求严格。

三、ISO 26262是什么

ISO 26262是针对汽车电子的功能安全标准。

车载电子系统，即车辆所搭载的电子设备和计算机(包括软件)，是ISO 26262的直接认证目标对象。在今年颁布的第二版ISO 26262中，车辆对象范围还扩大到了到巴士、卡车、两轮车辆。

ISO 26262的目的是确保“安全”，为了实现这个目的，不仅要考虑ISO26262直接针对的电子系统，还要考虑构成电子系统的其他元件是否安全。此外，还必须明确ISO 26262的应用场景，从整体上确保车载电子系统的安全性。

图1为ISO 26262的体系结构

ISO 26262的内容包括：

Part 1：定义术语

Part 2：功能安全管理

Part 3：概念阶段

Part 4：产品开发：系统层面

Part 5：产品开发：硬件层面

Part 6：产品开发：软件层面

Part 7：生产、运行、服务和报废

Part 8：支持过程

Part 9：基于ASIL和安全的分析

Part 10：ISO 26262导则

Part 11：半导体应用指南

Part 1是定义标准中使用的术语的词汇表。

Part 2中的功能安全管理定义了涉及安全相关系统开发的组织和人员应满足的要求。

在Part 3概念阶段，ISO 26262给出去了灾害分析和风险评估的要求。主要做三件事：项目定义、安全生命周期初始化、灾害分析和风险评估。

在Part 3中获得的安全需求，将在技术安全中详细说明，并分解在Part 4系统层面的安全设计中。然后，根据硬件和软件层面的开发安全要求（Part 5和6）进行系统集成，最后对系统级功能安全进行测试验证。

在开发阶段，完成系统级产品设计后，将技术安全需求规范分解到相应的软硬件技术安全需求规范里，进而开展软硬件级产品设计，而在硬件层面（Part 5），必要的活动和产品开发过程包括技术安全概念的硬件实现、潜在的硬件故障及影响分析、与软件开发的协调。

在Part6的软件层面开发中，通过V字模型流程，遵循技术安全概念，实施软件安全要求的导出、软件架构设计、软件单体设计和细化。并在此基础上实施编码，完成编码后，进行软件单元测试，软件集成（模块组合）和集成测试，以及软件安全要求的验证。

Part 7规定了直到废弃前的批量生产、服务、市场监管的安全要求。

Part 8规定了对供应商的开发委托要求，所要支持的系统过程（安全要求的管理、配置管理、变更管理、验证、书面化），以及软件工具认证、软件组件认证、硬件组件规定与认证有关的要求，对多个过程进行横向参与。

Part 9提供了关于ASIL认定和技术分析方法的指导，并且与第8部分一样，涉及多个流程。

Part 10是作为Part1～9的补充，对特定项目的解说及事例的指南。

尽管对于 Part 5对于硬件层面已经有相关说明，但是关于半导体层面的要求还是有限的。

四、ASIL

在ISO 26262中，ASIL是危害的风险等级的指标。

依据ISO 26262标准进行功能安全设计时，首先对系统的功能进行逐个分析，识别系统所有的危害，然后依据三个因子（S\E\C）来评估危害的风险级别。

严重度（Severity）

严重度是指一旦风险成为现实，对驾驶员、乘员、或者行人等涉险人员的伤害程度。比如电子锁故障就比刹车故障的严重程度低。

严重性用SX表示，X取值可以是0/1/2/3，级别从低到高，级别越高，伤害越严重。S0无伤害；S1轻微或有限伤害；S2严重或危及生命的伤害（可生还）；S3危及生命的伤害（有死亡可能）或致命伤害；

风险S0S1S2S3内容没有伤害轻度或中度伤害重度或危及生命（还有生存的可能性）威胁生命安全（几乎没有生还的可能）

暴露率（Exposure）

暴露率，描述风险出现时，人员暴露在系统的失效能够造成危害的场景中的概率。基于目标危险事件的情景，根据道路环境、天气、车辆周六的情况、失去等等来判断该指标。比如底盘出现异响比乘员座椅故障暴露率低。

暴露率，用EX表示， X取值从0至4，共5个等级。E0是几乎不肯能暴露于危险中，E4是可能性极高。

风险E0E1E2E3E4内容没有可能可能性非常低可能性低有一半的可能可能性高

可控性（Controllability）

可控性，描述风险出现时，驾驶员或其他涉险人员能够避免事故或伤害的可能性。比如，轮胎缓慢漏气比刹车失灵可控性高。

可控性，用CX表示，最低C0可控，最高C3几乎不可控，共4个级别。

风险C0C1C2C3内容可控简单可控、一般可控、几乎不可控

ASIL等级的确定基于S、E、C这三个影响因子，下表中给出了ASIL的确定方法，其中D代表最高等级，A代表最低等级，QM表示质量管理（Quality Management），表示按照质量管理体系开发系统或功能就足够了，不用考虑任何安全相关的设计。确定了危害的ASIL等级后，为每个危害确定至少一个安全目标，作为功能和技术安全需求的基础。

通过危害分析和风险评估，我们得出系统或功能的安全目标和相应的ASIL等级。当ASIL等级确定之后，就需要对每个评定的风险确定安全目标，安全目标是最高级别的安全需求。安全目标确定之后，就需要在系统设计、硬件、软件等方面进行设计、实施和验证。

从安全目标可以推导出开发阶段的安全需求，安全需求继承安全目标的ASIL等级。那么，要如何继承项目的安全需求呢？

接下来我们将先为大家说明如何继承安全需求。

五、产品开发阶段中功能安全需求的继承

下图为功能安全需求继承的流程图：

1.安全目标设定

如何提出系统安全需求是系统安全设计的第一步，系统安全需求的指导方针在现代安全法规中通常被表述为“安全目标设定”，它描述了所需实现的系统安全目标，并根据系统安全目标选择相应的实现方法和途径。

对所实施ISO 26262的项目，应用危险分析和风险评定以及评估ASIL等级，来避免不可接受的风险，并确定项目的安全目标。所谓的安全目标，就是为了防止在特定驾驶状态下发生危险事件而采取的功能需求。通过危害分析和风险评估，为每一个风险确定一个ASIL等级，而安全目标就是为了每一个风险而设定的。

2.功能安全需求的设定（功能安全概念）

为了符合功能安全目标，在功能安全概念中规定了项目的功能安全需求。

所谓的功能安全概念，是指得出实现安全目标所需的功能安全要求，并将他们分配到初步的设计架构，或者外部减少危险的措施当中去，以确保满足相关的功能安全。

所谓的功能安全需求，是一种安全措施（减少有害影响的活动或解决方案），且该安全措施不依赖于以安全目标为基础的项目安全行为规范和实施。

安全目标和功能安全需求之间的关系是分层的，如下图所示。

3.技术安全需求的设定（技术安全概念）

为了在项目中实现功能安全需求，必须根据技术安全概念，将项目级别的功能安全需求细化为系统级别所需要的技术安全需求。

所谓的技术安全需求，是为了实现功能安全需求，系统应具备的技术性安全措施。

所谓的技术安全概念，是说明如何实现技术安全需求规范。

在整个开发生命周期，技术安全需求是要落实功能安全概念的技术需求，其用意是从细节的单级功能安全需求到系统级安全技术需求。

4.系统设计

在系统设计阶段，系统及子系统需要按上面所定义的贯彻技术安全要求，设计出符合系统规范的开发方法。这里，不仅考虑安全需求，还考虑非安全需求(ASIL等级表中被判定为“QM”的要求)。为了实现技术安全要求，必须考虑到系统设计的可验证性，实现功能安全的技术能力以及系统集成期间的测试可行性。

将实施所需规范中的技术安全要求集合，即为系统规范样式。

系统规范应直接或通过进一步细化到硬件，软件或两者兼有。此外，设计硬件 - 软件接口（HSI），规定硬件和软件的交互，并应与技术安全的概念一致。

另外，系统规范必须验证对技术安全概念的符合性和完整性。

5.硬件安全需求和功能安全的硬件开发

根据分配给硬件的技术安全要求，可以获得硬件安全需求。硬件安全需求主要用于保证控制器内部硬件故障的安全机制的安全要求。

ISO 26262所要求的硬件设计的要点，一是定量地实施对硬件架构指标的评估，二是由于偶发硬件故障而导致的随机失效率的评估。

硬件架构指标，是用于评估硬件架构对硬件的偶然故障的影响（鲁棒性）的指标，且为定量数值，由标准定义的公式来确定。

随即失效率，是基于概率论，用来评价安全机制在安全性的逻辑支持之下的有效性。

6.软件安全需求的规范

软件安全要求以因故障引起技术安全要求偏离的功能为对象，并将其细化定义至可实施/验证软件的等级。

在软件安全要求的设计方面，需要考虑指定的系统和硬件配置，硬件/软件接口，硬件安全要求，时间限制，与项目外部视图的接口，受软件影响的车辆，系统以及硬件涉及的各个动作模式。

软件安全要求规范还必须验证与技术安全概念、系统规范、硬/软件接口规范的兼容性和一贯性。

六、功能安全的软件级开发

符合功能安全的软件开发有什么不一样的吗？

1.软件安全要求的可追溯性

ISO 26262要求将各危险风险降低设定为安全目标，并且在整个开发过程中，保证测试结果都可以通过其验证测试、实施、规范和要求来追溯。这就是功能安全的可追溯性。可追溯性可通过给需求添加ID号码来识别。

在软件开发中，ID号码用于关联软件安全需求标准的软件安全需求（相当于软件功能设计）、软件架构设计标准的软件组件以及软件单元设计标准的函数（如下图）。 这使得安全需求的关系明确，并且通过验证和试验，可以有效地发现对于上级要求来说的下级要求存在的遗漏，以及对函数不良影响的条件的影响等。

关于需求的可追溯性管理，可使用软件开发中的需求管理工具来实现。

2.设计方法

在ISO 26262中，软件想要达到系统所分配的更高安全目标的ASIL D等级，就需要更加严谨的软件架构。

在软件架构设计中，如果想要达到符合ASIL D等级，就必须满足软件组件的分层化、软件组件大小的限制、适当的调度、软件组件的内聚、耦合限制和中断限制。

在各种软件设计的方法中，结构化设计方法已经不是什么新鲜的方法了。但在ISO 26262中，显然，该方法是处理应对ASIL相应等级的必须手段。

在软件架构级别的错误检测阶段中，对于ASIL D的要求，必须进行输入输出数据的范围检查、数据有效性检查、外部监控、控制流监视和软件冗余设计。

在软件架构级别的错误处理阶段中，对于ASIL D的要求，必须具有发生错误时的缩退功能以及并行的冗余。

在单体软件设计阶段中，对于ASIL D的要求，相关函数只能有1个出入口，限制动态安全对象（例如堆栈区域），执行变量初始化，禁止相同变量名称，限制使用全局变量，限制指针使用，禁止隐式类型转换，禁止隐藏数据流/控制流，禁止无条件跳转，禁止递归调，ISO 26262没有深入涉及建模设计。关于汽车建模设计（基于模型的开发），MATLAB / Simlink被认为是典型方法，尽管如此，执行建模设计并不一定有助于导入功能安全。

不基于模型设计的软件开发代码质量，与基于模型设计的软件开发代码质量是相同的。在建模设计中提高模型的质量，也有助于由此产生的产品（项目）的安全性。关于设计模型时的指南，ISO 26262结合编码指南定义了设计指南的要求。

3.验证

所谓“验证”，就是确认已“正确”完成产品开发。

在ISO26262中，关于软件架构设计、软件单体设计和实现(编码)，规定需要完成与ASIL等级相对应的验证。

对于软件架构设计验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，则必须进行检查，动态（可执行模型）仿真，原型设计，控制流/数据流分析。

对于软件单一设计和实现（编码）验证，如果是ASIL A级别，只要排查就足够了。但如果是达到符合ASIL D级别，就必须进行检查，半正式验证（使用基于模型的仿真验证等），控制流/数据流分析，静态代码分析。

4.确认

所谓“确认”，就是通过提供客观证据对特定的预期用途或应用要求已得到满足的认定。通过试验来确认是否产生了满足要求的成果物。

对于ASIL D等级要求，无论是软件单元测试还是软件集成测试，都必须进行基于需求的测试、接口测试、故障注入测试、资源测试和背靠背测试。

在测试用例的导出方法中，需求分析，等价类的创建和分析以及边界值分析是对于符合ASIL D等级的基本要求。

对于软件单元测试的覆盖率，ASIL A可以执行100％的C0覆盖（指令覆盖率），而ASIL D则要求100%实施C1覆盖(分支网罗率)及MC/DC(Modified Condition/Decision Coverrage) 。

对于软件集成测试，ASIL D要求100%实施功能覆盖和调用覆盖。

5.软件工具的认证

为了软件开发而使用导入的各种软件工具（以下简称为工具），ISO 26262为它们设定了可靠性评估指标，只有被认定为符合指标的工具才能够用于开发。

所以，首先第一步，我们需要看看工具是否符合ISO 26262的认证标准。

为此，我们需要验证软件工具对于安全功能的影响（TI），也要同时考评软件工具，针对自身可能出现的内部错误的诊断能力（TD），并最终生成该软件工具的置信等级（TCL）。

TI是对软件工具是否对正在开发的设计产生直接的安全相关影响的评估。TI分为两个级别，TI1和TI2。TI1意味着对设计没有直接影响，而TI2则表示对设计有直接影响。当软件工具故障对项目或者组件完全没有影响时，可选择TI1。其他情况则选择TI2。

TD指对工具由于误操作而引起错误输出防护手段，以及工具发生错误时候检测能力的信赖性，,用TD1，TD2，TD3三个等级来评价。当对于误动作以及对应的误输出的防护和检测手段信赖性要求比较高时候，选择TD1；信赖度要求处于中等程度的时候选择TD2，其他情况选择TD3。

例如，假设某工具用于检测设计模型的错误。该工具对模型执行静态分析。当静态分析良好时，该工具不能检测模型中的所有可能违规行为。还有一点值得注意的是，这并不一定意味着该模型是错误的，而仅仅表明需要额外的测试。该例是一种中等程度的置信水平，即TD2。

根据TI和TD，我们可以通过以下矩形表格来确定TCL

判定为TCL1的工具无需认证即可使用，而判定为TCL2和TCL3的工具则需要附加鉴定方法，以下为适用的四种认证方法：

1a 信赖度通过使用而增强

只有提供了标准规定的工具实际应用的有关证据，才能基于使用历史，提升工具的信赖度。

1b 评估工具开发过程

该工具开发的开发过程是否开发流程，开发标准。

1c 软件工具确认确认

确认满足标准所判定的指标的方法。

1d 按照安全标准进行开发

工具开发是否符合ISO26262，IEC61508和RTCA DO-178（航空系统和设备的安全标准）等标准。

事实上，只要执行了附加认证，就可以使用TCL2或TCL3中评估的软件工具。ISO 26262也列出了关于TCL2和TCL3级工具可接受的认证方法。

ISO 26262-8:2011表4列出了对TCL3级工具可接受的认证方法，表5列出了对TCL2级工具可接受的认证方法。（如图）

根据工具中开发的项目或ASIL类别的不同，优先选择应用不同的认证方法。下图为合并的表格，其中突出显示了优选方法并且进行了说明。

++表示该方法被强烈建议用于所对应的ASIL

+表示该方法被建议用于所对应的ASIL

注：*没有如何安全标准完全适用于软件工具的开发。但可以选择安全标准的相关子集要求。

在TCL2的情况下，ASIL A/B/C需要附加验证方法1a和1b，ASIL D需要附加验证方法1c和1d。

在TCL3的情况下，ASIL A/B 需要附加验证方法1a和1b，ASIL C/D需要附加验证方法1c和1d。

实际上，从供应商处购买工具时，用户很难执行认证。因此，引入符合ISO 26262的第三方认证工具是非常符合现实需求的。

6.通过保护功能防止故障的传播

在特定软件组件发生故障时，为了防止对另一软件组件造成不良影响，ISO 26262一个名为“软件隔离”的结构技术。当多个不同ASIL等级的软件组件在同一个MPU上共存时，该技术非常适用。

举个例子：在没有分区的情况下，假设有ASIL A，ASIL B和ASIL C三个不同等级的软件，使用一个MPU和一个资源（共享内存）进行操作，则三个软件必须符合最高的ASIL等级要求（即ASIL C），导致必须承担高于必要的开发成本。同时，低等级的任务修改高等级的数据，会造成高等级使用了不可信的数据，影响安全功能。

如果有分区，即使三个不同ASIL等级的软件在一个MPU上，也可以将最佳的ASIL等级应用于各个软件组件，可以避免浪费的开发成本。

软件分区技术有很多，将软件分区应用于汽车MPU时，从成本方面考虑，一般认为，利用MPU的存储器保护单元的OS方法是最有希望的。

7.流程改进

在嵌入式软件领域，要求不断改进过程标准，如CMMI和Automotive SPICE。

ISO 26262也需要流程改进，但基本上是对现有流程改进的延伸。建议至少通过CMMI Level 2和Automotive SPICE Level 3认证。

在ISO26262中，Part2功能安全的管理规定了确认审查（从技术的观点验证成果）和功能安全审核（从过程的角度确认功能安全活动的实施状态）。通过结合三点功能安全评估的验证策略（S/E/C）实现独立评估ASIL等级，该评估项目可评估功能安全的合规性。

ASIL的独立性被定义为4个级别，最轻的级别是“认证方案应由不同的人实施”，最重的级别是“来自不同部门或组织的人员实施认证”（即并且必须由第三方实施）。根据认证的内容，较高的ASIL级别需要更高的独立性。

第三方组织可以是公司内的独立部门，例如质量保证部门，或是外部第三方认证机构。为应对功能安全认证的市场需求，有许多供应商和工具供应商要求知名第三方认证机构进行审核。

七、结论

2011年11月15日，ISO 26262 标准正式颁布。2018年，ISO 26262正式上路。

在这一领域，欧洲、日本应用ISO 26262要早于国内，美国则推出SAE J2980标准。技术咨询公司在和国内OEM合作时会要求引入功能安全。国际汽车厂商（宝马、通用、福特等）、汽车零部件供应商（博世、德尔福等）早已采用该标准开发安全相关的电子电器产品，应用在汽车的开发。

ISO 26262涉及汽车电子电气系统的整个安全生命周期及其管理过程，满足该标准对汽车企业及供应商来说必将是巨大的挑战。为满足ISO 26262，必须在公司安全文化、工作流程制定、产品设计与开发等方面进行持续的改进。

ISO26262标准暂时没有出现官方层面的强制执行要求，但该标准的执行，将减少因为电子器件失效造成的交通事故和降低潜在召回风险，所以目前国际大型车企非常重视ISO26262标准的应用和推广。

▲文章来源于：知乎   牛喀学城

返回