ISO26262 功能安全解决了什么问题 _iso26262以及iso13849对比(1)_系统性失效随机硬件失效相关性失效

作者：木道寻08 | 2024-07-23 04:19:41

踩

系统性失效随机硬件失效相关性失效

比如由于宇宙中单个高能粒子射入半导体器件灵敏区，使存储器逻辑状态翻转的单粒子翻转效应SEU，使得软件中某个bit位从0到1或者从1变成0是属于一个软错误(硬件没有损害)。

从上可以看出故障，错误和失效的大概关系是故障可引起错误，错误再导致失效。下文会再做详细说明。

失效，按照ISO26262的定义是要素按要求执行功能的能力的终止。(英文：terminationof the ability of an element to perform a function as required)

注：不正确的规范是失效的来源之一。

在这里失效针对的是功能的丧失或者终止。比如对于电机控制器来说，其主要的功能之一是根据整车控制器VCU的扭矩请求，对电机进行转矩和转速的控制，因此无论输出的扭矩非预期的偏大或者偏小都是一种失效。

在功能安全中依据失效的原因可以将失效分为两种：系统性失效和随机硬件失效。而功能安全的主要目的就是尽可能的将由于这两类失效导致的整车层面安全风险降低到一个可以接受的水平。

(1)系统性失效(systematic failure)

以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其它相关因素进行变更后才可能排除这种失效。

系统性失效存在三个特征：

A- 仅仅进行正确维护而不加修改的情况下，无法消除故障。

B-通过模拟失效原因可以使其重复出现。

C-是人为错误引起，失效原因比如：安全要求规范的错误；硬件的设计，制造，安装，操作的错误；软件的设计和实现的错误等。

软件故障和部分的硬件故障是属于系统性故障。比如coding的时候没有考虑使用数据类型的错误，某变量(比如精度为1，offset为0)本应该使用U16的，结果用成了U8，使得计算的最大数值只能到255。这里的软件bug是属于系统性失效。

(2)随机硬件失效(random hardware failure)

按照ISO 26262的定义，随机硬件失效是在硬件要素的生命周期中，非预期发生并服从概率分布的失效。并且可在合理的精度范围内进行预测。

非预期发生的含义是尽管硬件的设计是正确的，比如电子元器件的选型，电阻值，电容值，电路设计等都是正确的，且器件是符合质量标准的。但是却无法预知在哪里发生，以怎样的形式发生的失效。

服从概率分布的含义是失效可以在合理的精度范围内进行预测。比如通过可靠性或者分析得到失效率。

随机硬件失效的起因是由于物理过程，比如疲劳、物理退化或环境应力等。比如上面提到的位翻转，比如电阻的开路，短路，阻值漂移等等。

2．相关失效和非相关失效

此外功能安全中还定义了相关失效和非相关失效。

相关失效是指失效同时或相继发生的概率不能表示为每个失效无条件发生概率的简单乘积。比如当失效A和失效B同时发生的概率不等于两个失效概率的乘机，用数学关系式表示为Pab =Pa*Pb，失效A和B可被定义为相关失效。反之非相关失效可以表示为每个失效无条件发生概率的简单乘积。

相关失效可以分为共因失效和级联失效。

共因失效是指在相关项中，有一个单一特定事件或根源引起的两个或多个要素的失效。如下图所示。我们无法避免随机故障的发生，因此，功能安全在系统中构建安全监控和缓解机制，从而解决随机故障。功能安全机制可持续监控汽车中的制动信号，从而检查它是否偏离预期范围。如果确实偏离了预期范围，安全机制会标记出可能出现的问题并需要对其进行检查。

级联失效

公因失效

故障，错误和失效之间的关系如下图所示。图中从三个不同类型的原因(系统性软件问题、随机硬件问题和系统性硬件问题)描述了故障到错误并从错误到失效的发展过程。

系统性故障起因于设计和规范的问题；软件故障和部分硬件故障是系统性的。

随机硬件故障起因于物理过程，比如疲劳、物理退化或环境应力。

在组件层面，每个不同类型的故障会导致不同的失效。然而，组件层面的失效是相关项层面的故障。

功能安全中描述的问题其实也会经常出现在我们日常的家庭和工作场所。如果您曾经注意到，你的手机因为长时间放在阳光下而自动关机，这是因为手机实时的在监控手机的温度，一点温度上升到危险阈值，手机就会自动关机防止电池过温起火，这就是一个典型的功能安全机制在起作用。

功能安全无法避免随机硬件故障的发生，但是功能安全可以在系统中构建安全监控以及对应的安全机制，更好的应对随机故障，降低安全风险。例如，功能安全机制可持续监控汽车中的某个传感器的信号，从而检查它是否偏离预期范围。一旦发现偏离了预期范围，安全机制就会被触发，将系统带入到预先定义好的一种工作状态当中，这这种预定义的状态下，对应功能不会产生安全风险。

为了预测这些潜在的危险，系统层面的功能安全工程师必须了解这些电路层面危险故障的所有可能原因、发生的可能性以及如何设计对应的软硬件实现对故障的及时&准确的诊断。实现了功能安全的集成电路可以将风险降低到可接受的水平，并在失效模式、影响和诊断分析 (FMEDA) 中具体说明其诊断覆盖范围。

然而，要确保产品满足功能安全要求，为应对随机硬件失效做好充足准备只是其中之一。另一个风险来源是开发过程本身的系统失效。因为无论诊断覆盖率多高，打造功能安全应用的时候都必须遵循合适的流程才能有效避免人为因素引入的失效（系统性失效）——这也是标准体系最大的益处。无论功能安全措施设计得如何完善，严格的质量管理流程都是实现功能安全的前提条件之一。

开展功能安全活动的时候，“循规蹈矩”非常重要。这个过程必须从一开始就将安全纳入考虑，而且还必须营造支持安全的文化。完整的开发流程必须包含以下几个重要方面：

安全管理：包括团队组织架构，具体内容如：明确不同职位的定义和职责、打造安全文化、定义安全生命周期，定义功能安全支持级别。安全生命周期的设定包括制定一份成功计划，选择合适的开发工具，确保团队接受充分的培训。
需求管理和故障检测及控制措施（功能安全需求）的可追溯性。为精确实现需求追溯，需求本身定义必须要明确，精准，且具备唯一性。追溯等级取决于完整性的要求，文件可以高等级；产品则需要从故障检测到验证等各个环节面面俱到——计划过程不得空穴来风，必须经过详细验证。
文档管理和问题管理。勘误表必须得到妥善管理和使用。为实现文档的精确管控，文档本身版本信息和识别ID必须要明确，精准，且具备唯一性，文档变更的记录也需要保证完整性。产品在开发过程中对于设计和验证阶段所出现的所有功能安全相关的问题，从问题出现->关闭的整个过程必须经过详细记录和验证。

最后，我们再来强调一下功能安全标准中对功能安全的定义“避免由系统功能性故障导致的不可接受的风险”。

标准的描述从来都是严谨而晦涩，简单来说，就是一个功能在它的使用过程中如果出现故障了会带来伤害，这个功能就是功能安全相关的。因此Functional Safety翻译为“功能的安全”更为贴切。举个略显不恰当的例子：如一把椅子（不使用标准里说的E/ E，是因为这些产品和系统比较复杂，功能比较多不如椅子这种描述的直观）。椅子之所以成为椅子，其中核心的一点就是其设计、生产和使用的目的是让人坐在上面。“让人坐”是一把椅子的核心功能。一把不能坐的椅子不能称其为椅子。明晰了椅子“功能”后，我们可以将椅子的“功能安全”描述为：一把椅子在人坐的时候应该是没有危险的，不会倒、不会扎到人等，即人坐到椅子上的时候不会产生伤害。

安全，按一般的概念是没有危险，不受威胁，不出事故。按照这样的概念，安全是不可控制的。因为这是一个绝对安全的概念，而绝对安全是不存在的。但是在ISO 26262中将安全定义为“不存在不可接受的风险”，这样就将绝对化的安全转化为相对化的风险控制，使得可以通过控制风险的手段来解决安全问题，为安全的实现提供了可供遵循的路径—“功能的安全的本质就是控制风险”。

功能安全是一个复杂而庞大的体系，涉及的内容多而繁杂，而要更好地理解功能安全的端到端、全系统和全生命周期的科学理论与方法，了解和掌握就是功能安全的基本概念非常必要的且重要的。

先自我介绍一下，小编浙江大学毕业，去过华为、字节跳动等大厂，目前阿里P7

深知大多数程序员，想要提升技能，往往是自己摸索成长，但自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年最新网络安全全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友。