01. 前言

电脑已经是大家日常生活中不可或缺重要工具，我们使用电脑来浏览网站、收发邮件、编辑照片和视频、浏览社交媒体以及在线会议。在使用电脑的过程中或多或少会遇到系统崩溃，卡顿，软件不响应等等问题。那为何手机经常卡顿/司机？可能是因为部件老化或过热，又或是电脑芯片的一个关键组件失效或者内部接插件接触不良，又或者是软件的BUG从而导致整个系统随机重启。

多亏这是安装在电脑中的处理器，最糟糕的结果也只是因为数据的丢失而片刻的沮丧。如果这款处理器安装在您汽车的某个控制系统中，例如转向/制动/智能驾驶，那么后果可能会更严重。

所有电子元件都会在某个时间点失效，这是无法更改的事实。而如今，我们发现在我们汽车上越来越多的执行关键功能的电子元件越来越多，涉及转向、制动、智能辅助驾驶等方面。既然电子元件必然会随着时间的流逝出现各种问题， 并且我们的电子电气工程师无法阻止时间的流逝，我们该如何帮助使用我们元件的系统设计人员来避免此类随机事件危及车辆驾乘人员以及其他交通参与者的生命安全？

答案就是：功能安全。

02. 什么是功能安全

“功能安全”是指避免由系统功能性故障导致的不可接受的风险。功能安全关注系统故障后的行为，而不是系统的原有功能或性能。

在现代工业控制领域中，可编程电子硬件、软件系统的大量使用，大大提升了自动化程度。但由于设备设计中的缺失，以及开发制造中风险管理意识的不足，这些存在设计缺陷的产品大量流入相关行业的安全控制系统中，已经造成了大量的人身安全、财产损失和环境危害事故。为此，世界各国历来对石化过程安全控制系统、电厂安全控制系统、核电安全控制系全领域的产品安全性设计技术非常重视，并且将电子、电气及可编程电子安全控制系统相关的技术发展为一套成熟的产品安全设计技术，即“功能安全”技术。

欧美已经颁布了成套的功能安全相关产品指令和设计标准，并深入到各个领域，如：汽车（ISO26262）轨道控制（EN 5012X）、核电(EN 61513)、工业装备及机器控制（EN 62601, EN ISO 13849-1/2）、过程控制(EN 61511)等，国际上，IEC形成的 IEC 61508，IEC 61511 等系列标准已经逐步成为各国家、行业广泛认可的基本功能安全标准，中国也仿效并形成了的相应国家标准，其他行业性功能安全标准也在参照并将逐步形成为国家行业性标准。

ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准，国内对应的标准即为GB/T 34590。

随着系统复杂性的提高，软件和机电设备的应用，来自系统失效和随机硬件失效的风险也日益增加，制定ISO 26262标准的目的是使得人们对安全相关功能有一个更好的理解，并尽可能明确地对它们进行解释，同时为避免这些风险提供了可行性的要求和流程。

ISO 26262为汽车安全提供了一个生命周期（管理、开发、生产、经营、服务、报废）理念，并在这些生命周期阶段中提供必要的支持。该标准涵盖功能性安全方面的整体开发过程（包括需求规划、设计、实施、集成、验证、确认和配置）。

ISO 26262标准根据安全风险程度对系统或系统某组成部分确定划分由A到D的安全需求等级（Automotive Safety Integrity Level 汽车安全完整性等级ASIL），其中D级为最高等级，需要最苛刻的安全需求。伴随着ASIL等级的增加，针对系统硬件和软件开发流程的要求也随之增强。对系统供应商而言，除了需要满足现有的质量要求外还必须满足这些因为功能安全等级增加而提出的更高的要求。

整车主要模块/功能的功能安全等级

03. 故障-错误-失效

故障

功能安全中定义的故障是指可引起要素或相关项失效的异常情况。

故障可以分为永久故障和非永久故障，其分类如下图所示。

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

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

瞬态故障是指发生一次且随后消失的故障。瞬态故障可由电磁干扰引起，其可导致位翻转。比如由于单粒子翻转效应(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.系统性失效和随机硬件失效

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

(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可被定义为相关失效。反之非相关失效可以表示为每个失效无条件发生概率的简单乘积。

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

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

级联失效

公因失效

故障，错误和失效之间的关系

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

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

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

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

04. 为一切可能性做好准备

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

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

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

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

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

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

需求管理和故障检测及控制措施（功能安全需求）的可追溯性。为精确实现需求追溯，需求本身定义必须要明确，精准，且具备唯一性。追溯等级取决于完整性的要求，文件可以高等级；产品则需要从故障检测到验证等各个环节面面俱到——计划过程不得空穴来风，必须经过详细验证。

文档管理和问题管理。勘误表必须得到妥善管理和使用。为实现文档的精确管控，文档本身版本信息和识别ID必须要明确，精准，且具备唯一性，文档变更的记录也需要保证完整性。产品在开发过程中对于设计和验证阶段所出现的所有功能安全相关的问题，从问题出现->关闭的整个过程必须经过详细记录和验证。

05. 总结

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

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

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

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