ISO 26262功能安全标准体系解读（下）

在解读 ISO 26262 功能安全标准体系（上）的过程中

基于危害分析与风险评估的综合判断, 我们得出了系统或功能的安全目标以及各自对应的ASIL级别.一旦ASIL级别确定后, 则需针对每个风险类别设定对应的安全目标, 这些目标被视为最优先级的安全要求.随后, 在系统设计阶段以及硬件与软件开发过程中都需要遵循相应的规范进行规划与验证工作.

在开发阶段的安全需求中，其ASIL等级可依据安全目标进行推导。通过相关属性继承的方式，则可以实现项目总的需求的安全性要求。

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

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

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

1.安全目标设定

确定系统安全需求是实施系统安全管理的基础环节，在现代安全管理实践中，《标准》通常将其表述为"明确的安全目标"。该指导方针不仅详细阐述所要实现的安全目标，并基于这些目标选择相应的保障措施与技术手段。

针对实施ISO 26262标准的项目而言，在采用危险性分析以及风险评估的方法下得以规避不可承受的风险，并明确了项目的A级安全性要求。即所谓的A级安全性要求，则是以预防特定驾驶条件下发生的危险事件为目标的功能需求设定。根据危害性分析与A级安全性评估的结果，则可得出每个潜在威胁对应的A级安全性等级结果

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

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

即指在制定实现系统安全性目标所需的必要技术条件，并将其分配至整体设计框架中，并通过外部防护措施来降低风险水平中，以保证达到预期的安全目标。

所指的功能安全需求是一种特定的安全管理活动或解决方案，并非基于以安全目标为导向的项目安全管理规范以及实施流程

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

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

为了具体转化为系统级别的功能性保障要求，在项目中关于功能的安全性要求应当基于技术安全性原则进行细化与规范。

所谓的技术层面的安全要求，则是旨在实现功能性安全性要求的基础上所采取的具体措施。即系统必须实施的技术保障措施应包含相应的安全性技术手段。

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

在技术系统的整个生命周期中，技术安全需求是为了实现功能安全概念的技术需求而设立的。其目的是从细化的单级功能安全需求逐步发展至系统级的安全技术要求。

4.系统设计

在系统设计阶段, 系统及子系统的开发需遵循既定的技术安全要求, 按照相关规范制定相应的开发方法. 其中不仅包含功能安全相关的ASIL等级评估标准, 更需兼顾非功能安全需求(如ASIL等级表中被判定为"QM"的要求). 为了达到技术安全目标, 应特别关注系统的可验证性主要关注点包括功能的安全性支撑能力和集成过程中测试可行性等关键指标.

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

系统规范应当既可以直接细化到硬件或软件层面，也可以通过进一步细分的方式实现。同时，在制定硬件-软件接口（HSI）时，需要规定 hardware与 software之间的交互，并确保这一交互与技术安全概念保持一致的一致性。

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

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

按照技术规范对硬件进行分配后可以获得相应的硬件安全需求。这些需求的主要作用是确保系统中所有可能的硬件故障都会被正确地检测和处理。

ISO 26262规定了硬件设计的关键点主要包含两个方面：第一，在实施过程中需对硬件架构的关键指标进行定量分析；第二，则是对因偶然出现的硬件故障而导致系统随机失效的风险进行详细评估。

硬件架构指标 是用来衡量硬件架构对意外故障影响程度（鲁棒性）的一个定量数值，并由标准化公式精确计算得出。

随即失效率 ，用于评估安全机制在安全性逻辑框架下的有效性程度，并基于概率论原理

6.软件安全需求的规范****

基于因故障导致技术安全要求偏离的功能基础之上，软件安全要求将具体化地定义到可操作性与验证性的软件等级。

在设计软件安全要求时，则需包含明确的系统和硬件配置、 hardware与software interface、 hardware方面的安全需求、时序约束条件以及其与项目外部视图之间的接口等要素。此外还需考虑受 software 依赖关系下的车辆、系统及其相关动作模式等。

该软件安全要求规范还需确认其与技术安全概念、系统规范及硬/软件接口规范之间的兼容性与一致性。

****功能安全的软件级开发

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

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

该标准规定各危险风险应被设定为安全目标，并在开发过程中逐步减少。同时，在整个开发过程中应确保所有测试结果都能通过验证测试、实施步骤、遵循规范以及满足相关要求来进行追溯。这体现了功能安全中的可追溯性。具体来说，可通过在需求中附加唯一标识符来进行追踪。

在软件开发中，ID号码对应于三个层面：软件安全需求（相当于功能设计）、软件组件和函数（如图所示）。通过这种方式可以明确阐述各层之间的关系，并通过验证与试验有效地发现上级要求下的下级需求缺失以及对函数不良影响的条件。

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

2.设计方法

在ISO 26262标准中, 软件若要实现其分配的安全目标中的ASIL D等级, 则必须采用更为严格的安全架构设计

在软件架构设计中遵循ASIL D等级要求需要满足以下几项关键要素：首先必须遵循分层化的组织架构；其次系统的各个软件组件规模大小必须受到严格控制；然后系统应具备合理的调度策略；同时各模块之间应当保持较高的内聚水平；此外系统内部各模块之间的耦合度应当维持在较低水平；最后系统设计还应确保短暂停顿机制的有效性。

对于各种软件设计方法而言，在这一领域内结构化设计方法已经不再是一种新兴的技术手段；然而，在ISO 26262标准中，则要求这种技术手段成为处理各类ASIL等级的必要工具。

在完成软件架构级别错误检测的过程中，在遵循ASIL D的相关规定下（或基于），必须执行以下操作：对输入输出数据范围的有效性进行验证、评估数据的有效性、实施外部环境监控措施、分析程序控制流的行为模式，并采用冗余设计以提高系统的可靠性。

在软件架构层次上的错误处理阶段中，针对ASIL D的需求，系统应具备发生故障时的回滚能力以及并行冗余特性。

在单体软件设计阶段中遵循ASIL D规范时需要满足以下约束条件：仅允许存在一个输出入口以确保动态安全域（如堆栈区域）的有效管理同时必须执行变量初始化操作并严格避免相同变量名称的重复声明此外还应仅允许局部变量而不得采用全局变量以及避免指针类型的使用。为确保系统的安全性所有类型的隐式转换操作都被禁止并且应当避免隐藏数据流和控制流路径以消除潜在的逻辑漏洞。此外该规范还规定了不允许可unconditional jump指令的操作以及完全禁止递归调用操作以保证程序运行时的行为符合预期的安全性标准

ISO 26262未对建模设计进行深入探讨。在汽车建模领域中（基于模型的开发），MATLAB/Simulink被视为一种典型的方法。然而，在这种情况下，执行建模设计并不一定是促进功能安全导入的关键因素。

非基于模型的设计方法所生成的软件开发代码质量与其质量和基于模型的设计方法生成的代码质量相同，在建模过程中优化和提升模型的质量有助于由此生成的产品或项目的安全性就如何进行建模设计提供了指导方针。

在特定场景下, 软件安全设计不仅涉及信息安全, 还需涵盖自动驾驶预期功能的安全性评估等多方面考量. 具体实施时, 需要建立相应的安全机制, 并采用如E-GAS架构等常见架构进行支撑, 同时还需通过符合相关标准的安全测试来验证其有效性. 在软件开发过程中与ASPICE存在重叠成本, 将两者整合应用以提升整体效能能够更加全面地改善软件安全性与质量水平

3.验证

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

ISO26262标准对软件架构设计、软件单体设计以及编码实现的相关内容明确要求进行ASIL等级对应的验证工作。

对于软件架构设计验证而言，在ASIL A级别情况下仅需进行初步排查即可满足要求。然而，在达到符合ASIL D级别时，则必须实施以下步骤：首先进行动态可执行模型仿真；随后开展原型开发；最后分别进行控制流和数据流分析；以确保系统的安全性与可靠性。

针对软件单一设计与实现（编码）验证，在ASIL A级别的情况下无需深入检查即可完成；然而当系统达到符合ASIL D级别时，则需采取更为严格的方法进行检查。采用半正式方法进行系统验证（如基于模型的仿真测试等），同时还需要对控制流程以及数据传输路径进行分析，并对静态代码进行审查。

4.确认

即为一种通过收集确凿证据来验证特定目的和应用标准并予以认可的过程。为了检验是否实现了预期目标和成果物的标准而进行了实验验证。

针对ASIL D等级要求，在软件单元测试以及软件集成测试方面均需完成需求驱动的测试工作；无论是在功能实现层面还是系统交互层面的开发过程中，请确保完成故障注入相关的功能验证、资源相关的功能验证与相互之间功能的验证。

在生成测试用例的过程中，在需求评估的基础上建立等价类并对其进行详细分析，在极端情况下的验证同样被视为达到ASIL D级标准的基础性工作。

对于软件单元测试的覆盖率而言，在ASIL A架构下可实现全部指令覆盖率（即指令覆盖率），而在ASIL D架构下则需满足完全分支网罗率（即分支覆盖率）以及MC/DC覆盖要求

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

5.软件工具的认证

在软件开发过程中引入各种导入型软件工具（统称为工具）。ISO 26262这一标准为这些工具制定了可靠性评估标准。仅当这些工具通过符合标准的审核时才能应用于开发过程。

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

为此, 必须对软件工具实施影响评估(指标 TI), 同时也要对软件工具进行评估, 重点考察其在识别自身可能出现的内部错误方面的表现(指标 TD), 并最终确定该软件工具的信任水平(TCL)。

安全风险评估值（SRAV） 是衡量软件工具是否会对正在开发的设计产生安全相关性的重要指标。其分为两个等级别：SRAV-1 和 SRAV-2。其中 SRAV-1 表示软件工具不会对设计造成安全相关性的影响；而 SRAV-2 则表明存在安全相关性的影响关系。在实际应用中，在无任何潜在的安全风险情况下可应用 SRAV-1；若有潜在的安全风险，则应采用 SRAV-2。

该系统采用...技术指标对工具进行性能评估，在发生误操作时采取的技术防护措施以及在出现问题时对检测能力的信任程度均被纳入考量标准。具体而言，在设计该评估机制时可采用...三个层次的标准来进行量化分析：当对误操作及其对应产生的错误输出采取的技术防护与检测要求信任度较高时将优先选用...；当信任度处于中等水平时采用...；其他情况则采用...

在技术领域中，在设计阶段可能出现的问题和解决方案方面举个例子。假设某类工具能够对设计模型进行检查和验证。这些工具会对设计模型执行静态分析。当静态分析显示正常运行时，则表示这些工具无法覆盖全部潜在的问题或漏洞。值得注意的是，在这种情况下，并不代表设计模型存在缺陷或错误；相反地，则仅仅表明需要采取额外措施以确保系统的可靠性与安全性。这个例子体现了中等程度的置信水平，在这里指的是TD2 confidence level。

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

可直接用于操作而不需进行鉴定的TCL1类工具与之相比，则这些属于TCL2及以上的工具必须采用额外的方法进行鉴定。以下列举了四种适用于此类场景的标准检测程序：

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

仅凭符合标准规范的工具的实际运用的相关依据，并非能通过使用历史来提高工具的信任程度

1b 评估工具开发过程

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

1c 软件工具确认

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

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

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

根据规定，在完成附加认证程序后，则允许采用TCL系列（具体为TCL2或TCL3）中的相关软件工具进行验证工作。ISO 26262规范则详细指定了针对这些级别的认可性测试方法。

ISO 26262-8:2011详细列出了TCL3级工具认可的方法，在表5中则列出了TCL2级工具认可的方法。（如附图所示）

基于工具中所涉及的项目或ASIL类别不同, 优先采用相应的认证策略。该表格对齐并展示了, 其中清晰标注了最优选择方案, 并对其进行了详细描述。

基于工具中所涉及的项目或ASIL类别不同, 优先采用相应的认证策略。该表格对齐并展示了, 其中清晰标注了最优选择方案, 并对其进行了详细描述。

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

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

注：未被全部涵盖的是针对软件工具开发的安全标准体系。然而，在实际应用中可以选择相应子集的标准来满足需求。

基于TCL2标准下

在符合ISO 26262第3级功能安全要求的汽车电子系统中，在完成基础开发后应采取以下措施：对属于ASIL A/B级别的功能系统应在该安全级别下补充实施验证方案；而对于属于ASIL C/D级别的功能系统，则相应地应在更高的安全级别下也应采取这一措施。

在实践中发现，在从供应商处获取工具的过程中往往面临认证环节的巨大障碍。鉴于此情况下所面临的挑战与痛点, 引入符合ISO 26262标准的第三方认证服务将能够有效缓解这一问题并满足现实需求. 牛喀网作为一个专业的平台, 已经整合了丰富的技术资源库, 并针对功能安全开发需求提供了多样化的解决方案. 我们可以通过参加相关培训课程来深入了解国际企业采用的技术实践.

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

当某个特定软件组件出现故障时，以避免对另一个软件组件产生负面影响，ISO 26262采用了被称为" 软件隔离 " 的方法。当同一主处理器（MPU）同时运行不同 ASIL 等级的多件独立软件组件时，这一方法特别适用于这种情况，并能够有效提升系统的可靠性和安全性。

举例而言，在未实施分区策略时，在不区分不同安全级别（ASIL）的情况下，默认情况下涉及三个不同级别的ASIL架构——分别是A、B和C——通过单个处理器单元和共享内存机制执行操作，则这些架构均需满足最高级别的安全标准（即ASIL C级别），从而必然增加了不必要的开发开销。此外，在较低级别的任务修改较高级别的数据时可能会导致较高级别的数据来源变得不可靠

如果有分区域策略，在三款不同ASIL级别的软件集成在同一主控制单元（MCU）时，则可以通过合理分配最优ASIL等级到各组件来实现资源的最佳利用与优化管理。

存在多种软件分区技术，在应用到汽车微控制器（MPU）时，从成本角度而言，通常认为…其操作系统方法是最具潜力的。

7.流程改进

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

ISO 26262同样需要对流程进行改进，并主要基于现有流程改进方案进行优化。建议最低要求通过CMMI Level 2和Automotive SPICE Level 3认证。

根据ISO 26262标准，在Functional Safety Management框架下包含了两方面的内容：一方面是对成果进行技术视角下的验证即确认审查；另一方面则是基于过程来验证功能性安全性活动的状态即功能性安全性审核。为此本研究采用了三维度的安全性评估策略S/E/C模式以实现对ASIL等级值的有效评定该评价机制可用于后续对系统功能性安全性要求之合规性进行验证

ASIL分为四个等级来衡量系统的独立性。最低等级要求通过不同的人员来执行认证方案；而最高等级则要求来自不同部门或组织的人员执行认证工作，并且必须经过第三方确认。依据不同的验证需求，在较高ASIL等级时需要更高的系统独立性

第三方实体包括公司内部的独立职能部门（如质量保障部门）以及外部的专业认证机构。为了应对功能安全认证的需求，相关企业及工具提供商要求知名认证机构对其实施审核。

****结论

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

在这一领域内，在欧洲和日本均较早地采用了ISO 26262标准，在美国则推出了SAE J2980标准。在与国内零部件制造商合作的过程中，咨询公司通常会要求引入功能性安全措施。国际汽车厂商及汽车零部件供应商已广泛采用该标准来开发相关功能的安全电子电器产品，并将其应用于汽车开发过程中。

ISO 26262涵盖了汽车电子电气系统从设计到退役的全生命周期及其管理系统。对于遵循该标准的企业及其供应商而言，这是一个重大的挑战。为了实现这一目标，在公司安全文化建设、工作流程规范化以及产品设计与开发优化等方面需要持续的努力与提升。

ISO 26262标准尚未制定出官方层面的强制性实施要求,但其推行,将有助于减少因电子元件失效导致的道路交通事故,同时降低潜在的召回相关风险,因此,国际大型车企普遍重视该标准在应用和技术推广方面的进展

令人惋惜的是，在目前的情况下

— END —