2024年ISO26262 功能安全解决了什么问题 _iso26262以及iso13849对比

永久性故障是指发生并持续，直到被移除或修复的故障。也就是说永久性故障发生了必须采取相应的措施才能够使其恢复其正常运行。其中系统性故障一般表现为永久性故障。

非永久性故障可以分为间歇性故障和瞬态故障。间歇性故障是指故障一再的发生，然后消失。当一个组件处于损坏的边缘时，或者例如由于开关的电涌(电压的瞬态激烈变化)，间歇性故障可能会发生。某些系统性故障(例如时序混乱)也可能导致间歇性故障。

瞬态故障是指发生一次且随后消失的故障。瞬态故障可由电磁干扰引起，其可导致位翻转。比如由于单粒子翻转效应(SEU)和单粒子瞬态脉冲(SET)发生的软错误，均为瞬态故障。(单粒子翻转是宇宙中单个高能粒子射入半导体器件灵敏区，使器件逻辑状态翻转的现象。)

ISO 26262中定义的错误是指计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。错误可由未预见的工作条件引起或由所考虑的系统、子系统或组件的内部故障引起。故障可表现为所考虑要素内的错误，该错误可最终导致失效。

比如由于宇宙中单个高能粒子射入半导体器件灵敏区，使存储器逻辑状态翻转的单粒子翻转效应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) 中具体说明其诊断覆盖范围。

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

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

• 安全管理：包括团队组织架构，具体内容如：明确不同职位的定义和职责、打造安全文化、定义安全生命周期，定义功能安全支持级别。安全生命周期的设定包括制定一份成功计划，选择合适的开发工具，确保团队接受充分的培训。

写在最后

在结束之际，我想重申的是，学习并非如攀登险峻高峰，而是如滴水穿石般的持久累积。尤其当我们步入工作岗位之后，持之以恒的学习变得愈发不易，如同在茫茫大海中独自划舟，稍有松懈便可能被巨浪吞噬。然而，对于我们程序员而言，学习是生存之本，是我们在激烈市场竞争中立于不败之地的关键。一旦停止学习，我们便如同逆水行舟，不进则退，终将被时代的洪流所淘汰。因此，不断汲取新知识，不仅是对自己的提升，更是对自己的一份珍贵投资。让我们不断磨砺自己，与时代共同进步，书写属于我们的辉煌篇章。

需要完整版PDF学习资源私我

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以点击这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！