01.简介

功能安全是工程学的一个分支，涉及使用电气、电子和可编程电子(E/E/PE)技术的安全系统。功能安全是IEC 61508系列标准内容的核心。ISO 26262系列标准是对IEC 61508的改编，以满足汽车特定需求。该标准适用于安装在车辆上的由硬件和软件组件组成的电气和电子系统。ISO 26262定义了系统、流程、方法和工具安全必须满足的需求。它还确保在整个车辆生命周期内达到并保持足够的安全水平。

首先，重要的是给出一些有助于理解本文主题的定义。

      • SAFETY （安全）=没有不合理的风险。系统的残余风险永远不会等于0，但必须尽可能降低，直到达到可接受的值。必须告知最终用户最终的残余风险和要采取的措施；

      • RISK（风险） = 危害发生概率与事故严重程度的乘积；

      • HAZARD（危害） = 对某物或某人造成潜在损害、伤害或不利健康影响的任何来源；

      • SAFETY RELEVANT SYSTEM（安全相关系统） = 其失效可能导致人员受伤或死亡的系统；

      • ITEM （项目）= 在车辆级别实现功能的系统或系统阵列。

ISO 26262标准由12个部分组成，每个部分都涉及项目的特定领域。该规范包含在项目整个生命周期内要执行的活动，以获得可定义为符合ISO标准的产品。该标准基于V模型的假设，作为产品开发不同阶段的参考（图1）。

图1：ISO 26262系列标准概述

此V模型还代表了ISO 26262-3、ISO 26262-4、ISO 26262-5、ISO 26262-6和ISO 26262-7之间的互连。V模型将开发流程分为两部分。V的左臂包括项目设计，而右臂则专注于部件的集成及其验证。这两个分支相互作用。硬件和软件部分遵循两个独立的V循环，然后合并到涉及整个系统的循环中。

本文的目的是根据ISO 26262为概念、系统和硬件部分实施生命周期，以指出安全流程如何影响汽车项目的E/EE部分。为该项目选择的汽车项目是汽车尾灯及其停车、转弯和尾随功能。

这项工作还包括定量和定性安全分析，以评估系统的稳健性。由于所应用的分析和需求是在数学和模型层面进行验证的，无法在实际系统（汽车）中实施，因此V循环结果已完成并确认用于验证（测试台、模型级……）。

验证（车载测试）超出了这项工作的范围。

这项工作的结构基于上面讨论的V模型，特别是它参考了ISO 26262的第3、4和5章。然后从“概念阶段”开始，在此阶段定义处理的项目和与每个功能相关的安全目标。从安全目标中，可以得出功能安全需求，从而结束概念阶段部分。

之后是“系统级产品开发部分”阶段，在此阶段，提供技术安全概念的编写，该文档包含与项目相关的所有最重要的安全信息。在此阶段，将开发从FSR派生的系统架构和技术安全需求。

一旦定义了系统架构，我们就开始在底层处理硬件部分。因此，我们制定了比TSR更具体的硬件需求，然后进行实际的硬件设计。一旦定义了硬件设计，我们就会进入验证部分，这是安全分析的核心。

该项目的目的是证明在项目中使用功能安全首先会使最终产品更安全，同时也确保项目的开发部分得到优化。

02.ISO 26262- 3：概念阶段

2.1 项目定义

项目是一组实现车辆功能的系统。ISO 26262描述了汽车项目安全开发的最佳实践。本部分定义了项目并描述了其功能，以便充分理解项目。

在这个项目中，涉及的车辆功能是“汽车后灯”。实现它的子功能是：

      • 刹车灯；

      • 尾灯；

      • 转向灯。

在这个特定的开发阶段，定义并大致设计了前面提到的功能。当驾驶员需要刹车时，刹车灯必须打开。另一方面，当驾驶员需要右转或左转时，转向灯必须打开。相反，当日间行车灯打开以发出车辆存在信号时，尾灯必须打开。这些功能之一出现问题可能会导致交通事故。

2.2 安全目标

为了确定安全目标，必须进行危害分析和风险评估(HARA)。对于危害分析中评估的每个危害事件，应制定安全目标和顶级安全需求。在分析结束时，通过对危害事件进行系统评估，为每个安全目标分配一个特定的ASIL（汽车安全完整性等级）。此分配仅基于项目的功能行为，因此无需了解项目的详细设计。ASIL是通过考虑三个特定参数来确定的：严重性(S)、暴露概率(E)和可控性(C)。每个参数都对应ISO 26262上的一个特定表格，该表格在分配期间提供指导。

图 2：严重程度等级

图3：运行情况下的暴露概率等级

图4：可控性等级

一旦分配了这些参数，就可以根据下表（图5）确定ASIL级别。

特定危害的安全目标带有ASIL需求。ASIL D级代表最高程度的汽车危害，而ASIL A级代表最低程度的汽车危害。相反，ASIL QM不规定任何安全需求。

通常在项目中，客户会将安全目标及其分配的ASIL提供给开发人员和安全分析师。根据市场上车辆的相关技术文档，已分配了该项目的安全目标并在TSC上报告。因此，根据ISO 26262给出的说明，在分配的ASIL基础上构建了分析。

2.3 功能安全需求

功能安全需求(FSR)包含在功能安全概念中，它们源自考虑系统架构设计的安全目标。它们描述了在功能层面上要实施的措施，以防止违反安全目标。对于每个安全目标，必须指定至少一个FSR，尽管一个FSR可以涵盖多个安全目标。此外，每个FSR都从相关的安全目标继承了最高ASIL级别。因此，下面解释一种分层方法。

与项目相关的FSR在TSC文件中进行了报告，它们参考了前面讨论过的安全目标。它们包含有关项目系统架构（图8）的信息，这些信息是通过考虑安全状态的实现和同一文件中指定的假设得出的。特别是，FSR更深入地描述了系统功能的触发信号、要遵守的发光强度值范围以及关闭功能的条件。但是，所有这些信息都停留在系统级别，因此没有给出要实施的硬件和软件的精确指示。该选择取决于硬件和软件开发人员。

03. ISO 26262- 4：系统级产品开发

系统级产品开发流程可以图示如下。

图7：安全相关项目开发的阶段模型

从客户需求开始，定义安全目标及其各自的ASIL等级。从SG派生而来，首先将有关系统架构的更具体信息包含在FSR中。此时将创建TSC文档。它更深入地研究了定义实现相关功能的宏块的系统架构。然后，同时定义特定的硬件和软件需求和架构。一旦系统在软件和硬件级别实现，就可以继续进行测试。

3.1 技术安全概念(TSC)

技术安全概念是技术安全需求和相应系统架构设计的集合，它提供了系统架构设计为何适合满足ISO 26262-3中描述的活动（考虑非安全需求）和设计约束所产生的安全需求的理由。

该项目的TSC结构如下：

      • 文档最新情况（版本、状态……）

      • 参考文档列表

      • 术语和缩写

      • 一般信息（简要系统描述）

      • 安全概念

            – 安全目标

            – 安全状态

            – 假设

            – 功能安全需求

      • 技术安全需求

            – TSR

            – 外部需求

            – 外部安全机制

            – 退出策略

      • 系统架构（以及组成子系统的每个块的说明）

      • 安全措施列表

总而言之，该文件在安全领域非常重要，因为它跟踪与项目有关的主要信息。首先，它包含用于项目的所有参考资料，并跟踪对文档本身所做的所有更改。它还解释了项目的目标是什么（SG）以及如何在系统级别实现这些目标。

3.2 技术安全需求

技术安全需求(TSR)在技术层面上翻译FSR。这意味着它们提供了有关构成系统架构的模块之间交互的更多细节，也提供了有关影响安全需求实现的系统刺激响应的细节。TSR包含在TSC中，并符合标准需求的FSR。它们还指定是否在软件或硬件级别处理需求，从而将给定问题分配给能够解决它的能力领域。参考这个特定的项目，只有HW需求得到了处理并指定到另一个名为硬件安全概念(HWSC)的文档中。

3.3 系统架构设计

图8显示了与该项目相关的系统架构。它的结构如下：有一个代表每个功能的宏块（FZ BR、FZ TL、FZ TN），所有这三个都位于代表项目项（LH REARLAMP）的块内。后者与管理每个功能开启和关闭的微控制器接口。每个功能包括：

      • 电源管理模块，用于管理电源并使其适应其他模块

      • 灯光管理模块，用于处理尾灯的光强度

      • 诊断模块，用于检测功能中的任何问题并将其传达给MCU，然后MCU将停用该功能本身

从下图中可以看出，每个模块都包含标准需求的相应ASIL级别。为了清晰起见，仅开发了左尾灯的图表，但右尾灯的开发完全相同。

图8：系统架构

04.ISO 26262- 5：硬件部分

4.1 硬件需求

从分配给硬件的TSR开始，得出硬件安全需求(HWSR)。它们包含项目硬件元素的规范，应包括：

      • 控制元素硬件内部/外部失效的安全机制；

      • 安全机制的需求和相关属性，既要符合其他元素的安全需求，又要检测和发出内部或外部失效信号；

      • 未指定安全机制的硬件安全需求，例如：为避免随机失效而需要满足的目标值、避免功能特定行为或实现预期功能的需求、指定电缆线束或连接器设计措施的需求。

项目的HWSR收集在硬件安全概念(HWSC)中，该文档以TSC的形式组织，但更详细地介绍了如何在硬件级别实现系统的功能。HWSR包含要施加到系统上并因此强制执行的特定值，例如电压/电流值、要使用的LED数量以及配置... 根据ISO的需求，映射到硬件上的TSR与HWSR之间存在直接对应关系。

4.2 设计HW

硬件级设计的主要重点是构建一个HW架构：

      • 支持面向安全的分析并考虑其结果；

      • 满足硬件安全需求和硬件软件接口(HSI)规范；

      • 与系统架构设计规范一致并满足所需的硬件设计属性。

创建单个硬件设计来满足安全和非安全需求，因此只需一个开发流程即可处理两者。

项目的HWSC仅包括硬件架构设计；硬件详细设计包含在FMEDA分析文件中。前者代表所有硬件宏组件及其相互作用。后者处于电气/电子层面，即实际原理图，表示实现硬件组件的硬件部件之间的互连。

在ISO 26262第5章第7.4.1段中，设计必须遵守一些规则，因此基于这些规则创建了功能的硬件设计。下面是与组成该项目的功能有关的硬件架构设计。

图9：制动功能硬件架构设计

图10：尾部功能硬件架构设计

图11：转向功能硬件架构设计

4.3 硬件设计验证

需要进行硬件设计验证以确保所开发的硬件符合硬件安全需求。为了完成此任务，应采用以下测试方法：

      • 功能测试：旨在验证项目指定的特性是否已实现，即正确的输入和输出、系统的功能……；

      • 故障注入测试：旨在模拟故障或一定数量的故障，以评估安全机制的诊断覆盖率，或更一般地说，评估对系统的损害；

      • 电气测试：旨在验证在指定电压范围内（超出项目内容）是否符合硬件安全需求。

4.4 硬件级安全分析

硬件设计安全分析旨在确定失效原因以及可能影响系统的故障影响。为了执行此搜索，可以使用两种可能的方法：演绎分析或归纳分析。

对于每个安全相关硬件组件或部件，安全分析应针对所考虑的安全目标确定以下内容：

      a. 安全故障

      b. 单点故障或残余故障(SPF或RF)

      c. 多点故障(MPF)

关于分配给每个安全目标的ASIL级别，ISO 26262给出了必须进行哪些类型分析的指南。对于该项目，由于安全目标均为ASIL B级别，因此已进行定性(FTA)和定量(FMEDA)分析。前者采用演绎方法（自上而下），从不良系统行为开始，并找出导致此行为的原因。后者采用归纳方法（自下而上），直接考虑各个故障的影响。

4.4.1 FTA

如前所述，故障树分析(FTA)是一种使用演绎方法的安全分析，这意味着它从最高级别到最低级别。具体来说，这种分析从与系统不良行为（安全目标违规）相对应的“顶级事件”开始，被视为逻辑树的根，并继续分析可能导致此事件的所有可能原因。通过这种类型的分析，可以更容易地找到所有多点失效(MPF)，即所有那些如果发生就会导致违反安全目标的失效的集合。因此，这种分析的优点可以概括如下：

      • 自上而下的方法：从违反安全目标的宏观灾难性事件开始，直至微观原因；

      • 可视化分析：由于它是一种由逻辑门连接的块构建的分析，因此很容易看出哪些路径是危险和薄弱的。通过查看图表，可以直观地看到整个结构的问题；

      • 在高层次上：它允许修改结构，添加或删除分支，插入安全机制(SM)，从而查看某种设计在安全性方面是否优于另一种设计；

      • 最小割集计算：通过使用软件工具，可以查看哪些是最关键的事件，即从树的末端到顶部事件的路径最短的事件；

      • 适用于复杂系统：由于它是一种可视化分析，因此在高层次上，只需几个块就可以完全定义系统的功能并找到其最薄弱的环节。而在复杂系统上使用FMEDA分析意味着要分析数千个组件，试图在高层次上了解它们的影响，因此需要更多时间。

作为定性分析，它不引入数值评估，而只引入树结构的创建。

为了执行FTA分析，第一步是决定它应该在哪个抽象级别停止。有四个抽象级别：

      a. 功能级别：通常用于非常复杂的系统，仅限于系统的功能知识，即系统如何工作，而不定义哪些组件将组成设备；

      b. 系统级别：在此级别，系统需求已经是草案，因此提供了更详细的方案。还可以知道硬件级别和软件级别存在什么；

      c. 硬件级别：这是FTA的推荐级别，因为它进入系统块级别，即它考虑宏观组件而不是单个电气组件，例如电阻器、电容器……

      d. 组件级别：调查负面事件的可能原因，深入组件的各个失效模式。这是一个非常深的抽象级别，不建议用于包含大量组件的复杂系统。

一旦选择了抽象级别，下一步就是确定通常被确定为违反安全目标的顶级事件。然后，通过演绎分析，找出导致违规的原因，进而找出违规的原因。如此按顺序进行，就会找到事件本身的主要原因，这些原因位于故障树的底部。从树结构中可以识别不同的割集。割集定义为一组事件，如果发生，则会导致违反安全目标。在分析结束时，将识别所有最小割集，从而了解系统的安全性。

对于项目而言，选择了系统级抽象，以免获得太大的树结构。项目的故障树包含在文档“FTA 报告”中，该文档是借助Isograph Reliability Workbench工具制作的。下图显示了FTA分析报告中的一小段摘录（图12）。

图12：FTA文档报告摘要

从图中可以看出，这种分析具有一定的典型符号学。在故障树的顶部，有一个以首字母缩略词“TP”命名的顶级事件，后面跟着一个唯一标识该特定事件的数字。以首字母缩略词“EV”标识的其他块是事件。它们可以是主要事件或中间事件。前者是树底部的事件，即无法进一步发展的事件。后者是位于顶级事件和主要事件之间的事件，它们以首字母缩略词“GT”标识，代表“门”。门是输出和相应输入事件之间的链接，可以是以下类型之一：逻辑AND、逻辑OR或优先级AND（仅当输入事件按从左到右的顺序发生时，才会发生输出事件）。

借助用于树结构的相同工具，对与每个SG相关的所有最小割集进行了搜索和分析。此分析包含在文档“FTA割集分析”中。每个割集都有一个关联的顺序，该顺序对应于与路径关联的事件数。顺序等于1的割集被视为单点失效，它们是最危险的。因此，为了使系统具有良好的安全性，最好尽可能限制1阶割集。

4.4.2 FMEDA

FMEDA的首字母缩略词代表“失效模式、影响和诊断分析”。如前所述，这种特殊类型的分析使用归纳方法，即从最低级别到最高级别。可以注意到，这种方法与FTA所用的方法相辅相成。FTA和FMEDA可以结合起来，为安全分析提供自上而下和自下而上方法的适当平衡，而不会出现冗余或重复工作。

借助FMEDA，可以更详细地研究被调查系统的失效可能诊断及其有效性。该分析可以估计系统能够检测到多少失效。为了实现这一点，需要计算三个特定参数：

      • SPFM（单点故障度量）

      • LFM（潜在故障度量）

      • PMHF（随机硬件失效概率度量）

为了达到可接受的安全级别，这些参数的值必须在标准规定的特定范围内。

表1：ISO 26262规定的SPFM、LFM和PMHF的范围值

FMEDA分析组件级别的随机硬件失效。它为每个组件失效模式分配一个失效率和分布。应计算硬件架构指标（单点故障指标和潜在故障指标），并通过应用诊断覆盖率来减少这些指标。范围是根据安全目标ASIL实现ISO 26262需求的最低目标。为了为每个组件分配正确的失效率和分布值， 请参考以下文档：SN 29500和IEC 62380 （添加阿法猿微信： AlphaApe  免费领取 ）。这些文档提供了计算已安装电子元件失效率的元素，特别是它们涉及无源元件（电阻器、电感器和电容器）。

与该项目相关的FMEDA已设置了一个名为“FMEDA”的Excel文档，其中包含一个包含分析所需的所有信息的表格。系统中的每个组件都分配了一个从上述文档中获取的失效率值。失效率定义为某项产品在指定时间段内发生失效的次数，其值表示产品的可靠性。它用符号λ表示，并用FIT的测量单位量化。FIT定义为10 9 工作小时内的失效次数。

从失效率开始，计算失效率分数时要考虑特定组件的各个失效模式及其分布。然后，对每个组件的每个失效模式进行分析，以评估在发生失效的情况下是否会违反安全目标。如果特定组件的失效模式直接违反安全目标，则该特定失效率的值被视为SPF（单点失效率）。所有与组件相关的SPF值都用于通过以下公式计算SPFM：

其中λ SPF 是所有SPF的总和，λ RF 是所有残余失效率的总和，λ tot 是所有失效率的总和。参数λ RF 的权重取决于所应用安全机制的诊断覆盖率。根据所应用安全机制的覆盖率百分比，失效的影响会发生变化。安全机制可以具有：

      • 高覆盖率(99%)

      • 中等覆盖率(90%)

      • 低覆盖率(60%)

因此，基于这些覆盖率水平，相对于每个组件的参数λ RF 可能会以1%、10%或40%的比率影响计算。

同样，评估该组件的损坏与其他组件的其他故障相结合是否违反了安全目标。在这种情况下，相应的失效率应被视为LF（潜在故障），并使用以下公式计算LFM：

其中λ LF 是所有LF的总和，λ SPF 是所有SPF的总和，λ tot 是所有失效率的总和。

计算出这些参数后，需要检查它们是否在ISO规定的安全值范围内。参考这个特定项目，计算出的值符合规定的值，因此无需对项目进行任何设计更改。如果这些值不符合标准规定的值，则需要插入安全机制以提高系统检测故障的能力。

计算SPFM和LFM后，使用以下公式计算PMHF：

其中：

      • λ SPF + λ RF = 与单点失效相关的所有失效率总和

      • λ DPFdet = 与具有故障覆盖的多点失效相关的所有失效率总和

      • λ DPFlat = 与无故障覆盖的多点失效相关的所有失效率总和

      • T lifetime = 10'000工作小时

同样在这种情况下，参考项目，PMHF的值在ISO规定的范围内。

05.结论

谈到功能安全时，必须明确指出，这并不意味着没有故障风险，而是指由于电气和电子系统的错误行为导致的危害不存在不可接受的风险。汽车功能安全是实施保护措施以消除或减轻由车辆级系统失效或意外行为引起的危害。

本项目的主要目的是展示功能安全对汽车项目在安全性和开发流程优化方面的影响有多大。正如本文所述，功能安全涉及产品开发流程的所有阶段，这些阶段构成了简介中提到的V循环。通过在产品的设计和开发、验证和确认、生产、运行和处置流程中进行干预，功能安全可以保证最终产品能够避免或减轻由于车载电气系统电子设备故障而可能带来的风险。因此，第一个经过验证的结果是根据认证标准为用户提供安全的产品。功能安全的另一个基本方面体现在产品开发流程的优化上。如本文所述，在开发和设计阶段应用安全分析可以限制需要对产品架构进行的更改次数，从而避免代价高昂的产品召回。它还确保组件级别没有不必要的冗余，从而避免对功能安全没有影响的组件进行“过度设计”。

目前，ISO 26262不是认证标准，因此不包含管理认证的条款。从标准的角度来看，没有认证系统、组件或流程的义务。该领域的专家在实施ISO 26262标准方面的经验表明，大多数实施该标准的情况都获得了有效的外部评估和认证。这些检查的内容目前正在由相关认证机构定义。从监管的角度来看，ISO 26262不会直接改变型式批准的法律状况。事实上，有关缺陷产品责任的规定仍然适用。必须在技术层面达成明确的协议，特别是在安全目标、安全目标分类和要实施的安全措施等方面。开发接口协议(DIA)的目的是详细说明参与E/E系统或组件开发的公司之间的明确协议。该文件对于保证产品开发符合销售目标以外的安全需求是必要的。然而，关于ISO 26262需要考虑：ISO26262术语可能会导致误解，这尤其会影响需求的编写。最佳解决方案在于使标准尽可能客观，然后使其在汽车生产流程中具有强制性。