可能聊到功能安全，第一感觉就是一堆国外海归骗子在捞钱的，只说功能安全多么的重要，国内多么的落后，鄙视国内的人不懂，鄙视国家不出台政策，但是他们就是不谈怎么实现的细节，不聊怎么落地，好似你跟他不在一个level，你没资格听一样。最近接触了很多行业都是这么个德行，不鼓励写共享文档，口口相传，各种缩写黑话，一个师傅带一个徒弟，绝不外传，shit！中国人不骗中国人，对自己人没必要这么留后手吧，自有人去公开这些见不得人的高深技术，互联网时代资料这么多谁还不是抄的。笔者作为一个软件工程师，在功能安全的学习中尽量找到一些在芯片和软件上落地功能安全的方法跟大家分享一二。

本文围绕ISO26262（汽车电子功能安全的一个规范）的基础介绍，算是纲领，可能不好理解，可以先收藏，后续需要了再来详细看消化。另外本文介绍的很假大空，好像只是写文档做PPT用的，属于内功心法，后续再介绍具体软硬件能用到的安全技术及方案，进行落地，进入到我们广大程序员的代码里面，还是那句：Talk is cheap，show me the code。

0. 对于安全规范的认知

欧美的工业已经发展了几百年，我国很多东西解放后才刚刚起步，对于复杂性的机械及工程研究基本一片空白，而国外有几百年的传承，其中的精华就是规范文档，就像是中国的经书，越读越觉得博大精深，而且简练。

不同开发者的态度：

对于初学者，太过于“字字珠玑”以至于给人感觉太过于“概念化”、“笼统化”及“抽象化”，内容覆盖范围又宽泛，产品“从生到死”都得管，内容看下来既觉泛泛而谈又觉晦涩难懂让人“无法触碰”，导致时常能听到工程师们对标准中要求的“不屑”与“茫然”。

经验老道的工程师们拥有丰富的工程开发经验，当看到标准中某些通用的要求时往往会有“这不是明摆着的吗？”、“这不是废话吗？”诸如此类的不屑，当看到一些模棱两可、用词晦涩或太过抽象化的要求时通常又会感慨道：“这条需求想表达什么？”、“这和我目前实现的功能有什么关系？”、“此需求于我来讲如何实施？”或者干脆先直接跳过。

国内发展的早期，对于山寨抄袭的思路来说：短平快是工程师追求的目标，难于应对标准庞大而繁杂的要求。但是对于标准的研究必须要很多遍，而且耗费大量人力物力，俗话说：第一重“看山是山”，第二重“看山不是山”，第三重“看山还是山”。除了静下心来反复研读还需要做大量的延伸阅读来辅助理解，有了字面意义上的对理论部分的理解还需要通过实践来检验，只有实践了才会有更深层次的理解。

1 ISO26262简介

ISO26262就是这样一个规范，且特定于汽车电子领域，也就是说汽车上的电路软硬件，名为《道路车辆功能安全》，是功能安全的国际标准，是针对装设在量产道路车辆（非机动车除外）的电子电气系统，由国际标准化组织（ISO）在2011年发布第一版，在2018年更版。具体来说有ISO26262 有1-12共12个Part的pdf文件，后续的文章会给一个下载链接。

2 功能安全的必要性

消费者和政府期望：

从社会角度来讲，消费者和政府部门都对产品的安全具有极高的期望。

谁都不愿意看到事故发生在自己身上，政府也有极强的意愿来降低这方面是社会管理成本。

制造商和经销商的自我要求：

作为制造商和经销商，都想能制造和发布满足社会大众期望的产品；不然可能要召回，损失就大了。

OEM都在尽最大努力来避免由于自身产品的事故而招致社会的谴责以及名誉受损；

ECU功能的多样性： 随着汽车电子技术的高速发展，整车ECU数量越来越多，ECU的功能也越来越复杂，很多ECU都包含了安全相关的功能。整车具备的功能越来越丰富多样，势必导致整车电子电气架构越来越复杂，功能与功能之间的交互越来越密集，这些都将导致安全相关的功能越来越多也越来越复杂，涉及安全的模块越多功能越复杂那产品发生失效的风险就越高，这些都是地球世界的自然物理规律。整车复杂度增加实际会有什么隐患呢？

对于整车的复杂度，相应的软件也会更加的复杂，代码行数甚至过亿行，极其复杂，所以有必要对软件做系统基本的安全处理。

1. ISO26262第1部分基本术语

上图中部分收录了ISO26262标准中所有专业术语，共185个词条及定义，包括一些简写的定义。确保大家在一个世界里面，高效率的交流，我们需要使用术语，也是功能安全的入门券。

Safety： 不存在不合理的风险。不存在不合理的风险这一定义就将安全问题转化为风险问题了，这样一来安全就变得可控制了，因为风险是可控的。

Unreasonable risk: 按照现行的安全观念, 被判断为在某种环境下不可接受的风险。下图标识出了功能安全要在哪些方面做出努力来做到风险可接受。图中有两个词，“Acceptable risk” 和 “Tolerable risk”, 这两者有什么区别呢？

Unreasonable risk跟世界各地的社会道德绑定，当地的人认为什么是不可以接受的，会被大众批评的。例如在加油站旁边用打火机点烟，需要离加油站多远才能被接受

为了防范风险，也可以使用：“External measure”（外部措施）与“Other technology”（其他技术）的定义参考如下：

Risk: 伤害发生的概率及其严重度的组合。

Functional safety: 不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。

E/E system: 由电子和/或电子要素组成的系统，包括可编制电子要素。简单讲构成一个系统的三要素为：输入，处理，执行。如下图

Harm: 对人身造成的物理伤害或损坏。

Tips: 由于财产或环境的破坏而导致的直接或间接地对人体健康的损害或对人身的损伤。

Hazard: 由相关项的功能异常表现而导致的伤害的潜在来源。

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

Random hardware failure: 随机硬件失效, 在硬件要素的生命周期中, 非预期发生并服从概率分布的失效。

系统性失效是原因确定的失效，即只要导致原因发生的条件具备那失效就一定会发生，如软件bug。随机硬件失效顾名思义其失效是随机发生的，但其随机性服从一定的概率分布。

Fault tolerant time interval(FTTI): 故障容错时间间隔(FTTI)： 在安全机制（3.142）未被激活情况下，从相关项（3.84）内部故障（3.54）发生到可能发生危害事件（3.77）的最短时间间隔。

Automotive Safety Integrity Level (ASIL): 四个等级中的一个等级，用于定义相关项(3.84)或要素(3.41)需要满足的ISO26262中的要求和安全措施(3.141)，以避免不合理的风险(3.176)，其中，D代表最高严格等级，A代表最低严格等级。

safe state: 相关项（3.84）在失效（3.50）的情况下，没有不合理风险（3.128）的运行模式（3.102）。安全状态在失效发生后进入的一种运行模式，系统正常运行模式下虽然也是安全的状态，但安全状态考虑的是发生某种失效后进入的状态，故不把正常运行模式定义为安全状态。

相关项 Item ： 适用于GB/T 34590，实现整车层面功能或部分功能的系统（3.163）或系统组合。相关项即要开发的对象。功能安全国际标准为ISO 26262，对应国标为GB/T 34590。

单点故障 single-point fault： 要素(3.41)中直接导致违背安全目标(3.139)的硬件故障(3.54)，且该要素(3.41)中的故障(3.54)未被任何安全机制(3.142)覆盖。失效后能直接导致违反安全目标的故障且该失效没有相应措施来应对。如，VCU控制功能中，因加速踏板传感器故障导致踏板行程采样值错误(e.g. 过高/过低)导致输出扭矩过大/过小，将直接违反安全目标。

多点故障 multiple-point fault： 在未被探测且未被感知到的情况下，与其他独立故障（3.54）组合可能导致一个多点失效(3.96)的一个故障（3.54）。一个多点故障仅在识别出(例如，通过故障树的割集分析)多点失效(3.96)后才能被辨认出来。

潜伏故障 latent fault： 在多点故障探测时间间隔（3.98）内，未被安全机制（3.142）探测到且未被驾驶员感知到的多点故障（3.97）。

可用性 availability： 在特定时间或给定的期间内, 假设所需的外部资源是可用的, 在给定条件下, 产品处于执行所需功能的状态的能力。

Q: 可用性和功能安全性两者是什么关系？两者在具体实现层面会有什么差异？

Jet Note: 从定义来看可用性更多的是实现基本功能的一种能力，而安全关注的是如何控制功能实现过程中出现异常时引起的风险，两者虽属产品的两种不同属性，但在实现层面具有一定的依存关系。比如刹车这个功能，可用性强调踩下刹车踏板能起到预期的刹车效果即可，而功能安全考虑的是刹车这个功能出现故障时该怎么办。

基线 baseline： 在配置管理下，通过变更管理流程，作为进一步开发的基础的一组单一或多个工作成果、相关项或要素的版本。

错误 error： 计算的、观测的、测量的值或条件与真实的、规定的、理论上正确的值或条件之间的差异。

降级 degradation： 通过设计提供失效发生后的安全的策略。注: 降级可包含功能缩减，性能降低，或两者均降低。如跛行就是一种降级后的运行模式。

现场数据 field data： 从相关项或要素的使用中获得的数据，包含累加的运行时间、所有的失效和服务中的异常。

注: 现场数据通常来自客户的使用。

预期功能 intended functionality： 为相关项、系统或要素定义的不包含安全机制的行为。

Jet Note: 预期功能可以理解为使系统运转的基本功能，即使系统能够满足产品使用预期的最小功能组合。如一把能钉钉子和取钉子的锤子，那功能设计上就需要一头锤子一头夹的设计。

生命周期 lifecycle： 相关项从概念到报废的全部阶段。

2. ISO26262第2部分-功能安全管理

图片这个部分的主要内容：总体安全管理->概念及产品开发阶段的安全管理->相关项释放到生产之后的安全管理。

第2部分要求的关键输出物如下：

部分关于功能安全的管理的要求主要包括：

独立于项目的要求，比如公司层面的管理要求；项目开发过程中的要求及生产发布后的要求。

对整个生命周期及其裁剪，安全文化，能力管理，质量管理，角色，责任，安全档案，认可措施，功能安全评估的要求。

3. ISO26262第3部分-概念阶段

第3部分在标准总体框架中的视图如下：

这个部分的主要内容：相关项定义->启动安全生命周期->危害分析及风险评估->功能安全概念。

Part 3关键输出物：

Part 3与Part 8在输出物上的关联如下：

HARA分析是识别每个危害事件并为其确定汽车安全完整性等级(ASIL)， 并将ASIL分配给对应安全目标。

ASIL的评估参见下方矩阵表：

4. ISO26262第4部分-产品开发：系统层面

第4部分要求的关键输出物如下：

系统层面与第8部分和第9部分的关联

安全需求管理，验证，安全分析伴随着整个功能安全开发生命周期。

5. ISO26262第5部分-产品开发：硬件层面

硬件层面之关键输出物

硬件层面之硬件架构度量 硬件部分其中一个的非常重要的输出物是FMEDA，该输出物用于定量评估硬件架构的失效率是否满足对应ASIL的度量指标要求。硬件架构度量包含下方三大指标：

SPFM--单点故障度量；

LFM--潜伏故障度量；

PMHF--随机硬件故障度量；

这三个指标的计算方法参见下图，具体可详见标准第5部分。

硬件层面与第8部分和第9部分的关联

6. ISO26262第6部分-产品开发：软件层面

软件层面之关键输出物

这个V字模型算是传统的软件开发模型，周期还是比较长的。国内则引入了互联网敏捷开发还有传统软件公司的各种流程，例如华为的IPD流程，主打就是一个“快”，甚至敢没怎么测试就上车，赶鸭子上架，就是为了追赶超越。可能按常规思路出牌，按照老外给铺的路走，可能永远赶不上人家，冒险抄近路也是逼不得已，后来者必经之路。

软件层面与第8部分和第9部分的关联

7. ISO26262第7部分：生产和运行

生产和运行之关键输出物

功能安全在生产和运维阶段的相关可以由质量管理体系(IATF 16949)来支持，安全相关的需求须额外提出并体现在生产/控制计划里，确保生产相关的安全需求在生产过程中能够实现。

8. ISO26262第8部分：支持过程

支持过程之关键输出物

关于图上中提到的DIA(开发接口协议)这份输出物，从形式上来讲并非ISO26262所独有，其实对于分布式开发的非功能安全的项目也可以定义一份类似这样的明确双方开发责任的说明文件，具体叫什么可依据每家公司的流程进行自定义。

关于DIA的框架内容可参考下图：

9. ISO26262第9部分：以汽车安全完整性等级为导向和以安全为导向的分析

从第9部分的的框架视图可以看出安全分析伴随着整个功能安全开发生命周期。 以汽车安全完整性等级为导向和以安全为导向的分析之关键输出物

关于ASIL分解 ASIL分解成功与否的标准是分解后的需求/功能是否满足相互独立性要求，而这需要通过实施DFA(相关失效分析)来证明。下图给了个简要的ASIL分解示例，作为ASIL分解原则的示意性说明。

关于要素共存准则 分解后的需求将分配给不同的要素/组件，这些要素/组件能否“和谐共处”需要通过DFA(相关失效分析)来证明，如下所示：

关于安全分析 标准重点推荐了两类分析，分别是归纳分析和演绎分析。归纳分析的典型代表是FMEA，而演绎分析的典型代表为FTA，两种分析相辅相成各有所长。两者分析的形式可参考下方简化图例，具体分析方法将在后面结合实际案例以专题方式进行分享。

安全分析与其他活动之间的关系 从上面各部分与第9部分的关联关系描述可以看出，安全分析是一项横跨产品整个生命周期的活动，从概念阶段到报废其实都可以应用相关分析技术来提供活动实施依据。安全分析与其他活动之间的关系可参考下图：