抱着“为ISO 26262及功能安全的初学者提供有价值参考”的初衷，《EPB系统功能安全笔记》系列文章来到了尾声。
受限于笔者的个人水平，初衷达到几何尚未可知，但是可以肯定两点：一是在更新这个系列文章的过程中，笔者在系统梳理对功能安全理解的同时也获得了不少新的认知；二是虽然在更新过程中尽可能严谨，但文章中不可避免地有值得讨论甚至是错误之处，还请有经验的读者谅解并甄别。
作为《EPB系统功能安全笔记》的收官，本文的目标是站在ISO 26262的全局视角对功能安全开发过程中的关键点做出串联和总结；与此同时，在智能驾驶迅猛发展、E/E系统架构快速迭代的今天，本文站在安全的角度指出ISO 26262在这一潮流中的局限并做出展望。
需要提前指出，功能安全开发活动是贯穿整个产品安全生命周期的（管理、开发、生产、运行、服务、报废），重点包括开发过程(包括需求规范、设计、实现、集成、验证、确认和配置)、生产过程、服务过程和管理过程的，而系列文章只聚焦于开发过程，因为本文的梳理也仅围绕开发过程展开。
Part 1: ISO 26262总结1.1.功能安全的目标ISO 26262中对“Functional Safety, 功能安全”的定义如下。
absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.（不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险）
针对这一定义需要进行一些补充方能获得更清晰的认识。
首先，对于定义中提到的“危害（hazard）”和“风险（risk）”，可以让人联想到很多理解，比如车祸造成人员受伤、造成维修财产损失、车主隐私泄露等等。功能安全里中将这两个词和“伤害（harm）”想关联，并给出了解释：
Harm: Physical injury or damage to the health of persons. （伤害：对人身健康的物理损害或破坏）
可见功能安全所期望避免的危害是指对驾驶员或者路人或周边车辆内人员（注意：不仅仅是驾驶员）造成的健康伤害。
其次，汽车是集成了机械、液压、化学、E/E等众多系统于一身的复杂产品，每个系统的故障都会威胁到驾驶员或周边车辆内人员的人身安全。比如化学电池自燃、制动管路泄露导致制动力丢失、碰撞时A柱刚性强度不达标、转向控制系统失效导致方向盘锁死等等。但这些并不全在功能安全的考虑范围内。功能安全的研究对象只有“E/E system（电子电器系统）”。从这个角度，产品或者车辆满足了功能安全的要求，仅代表车辆实现了E/E系统的安全，还需要其他系统满足相应的安全设计才能全方位地提高汽车的安全。
换个角度看，车辆实现了E/E系统的功能安全，是不是可以说E/E系统100%没有安全风险了呢？定义中“unreasonable，不合理的”一词给出了对这个问题的否定的回答。
就像世界上没有永动机一样，世界上也没有100%安全的系统，功能安全追求的是将风险控制在合理的范围内，或者说可被接受的范围内。如下图所示。
功能安全开发的目标（截图来自TUV培训资料）
1.2.量化功能安全的目标既然功能安全追求的是将风险控制在合理的范围内，那么必须首先对界定“合理性”给出量化的指标才能指导功能安全开发。量化功能安全的目标本质上分为两步：
1.2.1.确定不合理的风险
- 确定不合理的风险
- 定义将不合理的风险降低为合理风险的标准
对于如何确定不合理的风险，在EPB功能安全笔记(1)：危害分析与风险评估(理论篇)中给出了详细的说明。简单来说分为两步：
step1: 确定相关项所有功能异常所有行为可能导致的整车危害
在这一过程中需要注意：应以能在整车层面观察到的条件或行为来定义危害。那么既然是以整车层面观察到的行为来定义危害，首先需要了解车辆所有可能的运动行为。从整车动力学的角度，汽车所有的运动行为可以通过下图中的运动坐标系来准确描述。
车辆运动坐标系
而在每一个坐标系上，因为控制不当而可能产生的所有的整车表现也能被界定。思路如下图所示。
step2: 结合危害和场危害发生时刻车辆运行的场景来分析风险。
这一步骤对应“危害事件分类（Classification of hazardous events）”
举例来说，EPB系统（电子驻车系统，Electric Parking Brake）和制动相关，存在一个危害：卡钳错误拉起导致车辆产生非预期的制动。如果这个危害发生在高速公路上时，很可能造成人员伤亡；但是如果危害仅仅发生在车速低于10kph的停车场，则不会有造成人员伤亡的风险。
从这个角度，功能安全需要结合危害和危害发生时刻车辆运行的场景来综合分析危害所导致的风险是否在可接受的范围内。车辆的运行场景，可以理解为是下图各个因素的排列组合。简单来说，运行场景 = 道路场景 驾驶场景，比如“高速公路 直行加速”或者“高速公路 直线制动”等。
车辆运行场景
当列出了相关项的所有场景与危害的组合后，接下来就是对其进行分类和筛选，确定哪些风险是可接受的，哪些是不可接受的。ISO 26262从三个维度来进行分类和筛选：
1.S（severity 严重度）：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。
2.E（Exposure 曝光度）：运行场景在日常驾驶过程中发生的概率。
3.C（controllability 可控度）：驾驶员或其他涉险人员控制危害以避免伤害的概率。
通过这三个维度的综合评分确定汽车安全完整性等级（ ASIL, automotive safety integrity level），如下图所示。ASIL D代表最高严格等级，ASIL A 代表最低严格等级。QM（quality management）则意味着只要按照企业流程开发就可以满足ISO 26262要求，无其他特殊要求。
1.2.2.定义将不合理的风险降低为合理风险的标准
ISO 26262要求，应为具有ASIL等级的每个危害事件确定一个安全目标。
比如对于以下危害事件：
整车危害
场景
可能发生的风险
车辆非预期减速
两辆车运行在同一车道且速度相近
前车非预期减速，后车制动不及，追尾
S值
E值
C值
ASIL等级
碰撞速度超过40kph时，驾驶员有危及生命的危害
S3
场景发生概率与两车车距有关，能造成碰撞危害的场景暴露度中等
E3
驾驶员不可控
C3
C
我们可以定义一条安全目标：
EPB应避免错误建压而造成过高的减速度 → ASIL C
但是除了ASIL等级以外，安全目标还有其他属性，包括FTTI、safe state等。在EPB功能安全笔记(3)：如何定义一条完整的Safety Goal？中以案例的形式对如何确定安全目标的属性给出了具体的说明，确定这些属性的过程就是确定安全标准safety criteria的过程，而这个安全标准即为界定“合理性”的量化指标。
1.3.将安全目标转化成软硬件开发需求安全目标作为最高层级（整车层）的功能安全需求，它实际上是概念层的产物，因为安全目标是在不需要知道相关项系统架构的情况下被完整定义出来的，而最终安全目标的实现是需要依赖于系统架构以及架构中的要素（如软件、硬件）的。换句话说，要想实现安全目标，就必须结合系统架构将安全目标细化为更具体的功能安全需求并分配给系统架构中的要素（软件和硬件等），这一活动对应功能安全概念开发（Functional Safety Concept Development）和技术安全概念开发（Technical Safety Concept Development），最终得到软/硬件功能安全需求。
在《EPB功能安全笔记(7)——EPB safety concept分析示例》中对这一过程进行了详细的示例说明。
功能安全开发鸟瞰
另外，在对系统中的要素分配功能安全需求的过程中，经常会遇到以下类似的情况：
- 对某个要素的功能安全需求的ASIL等级为ASIL D或者ASIL C，而实际只能达到ASIL A或者ASIL B
ISO 26262开了个“后门”来合理地避免这类偏差影响功能安全开发，这个“后门”就是ASIL分解。ASIL分解是降低对功能安全需求的ASIL等级的裁剪方法，这一方法的核心点是通过将一条功能安全需求分解成两条相互独立的需求并分配到两个及两个以上相互独立的元素（如软件模块、硬件模块、输入信号等）上。正是由于这些参与分解的独立的元素之间构成了互为冗余关系，从整个系统的角度看，只有当这些元素同时发生失效时才会违背安全目标，这样一来对每个参与分解的相关元素的功能安全要求可以降低。
在《EPB功能安全笔记(16)——ASIL分解及其关键点》中对分解的要点进行了说明。
当软、硬件功能安全需求确认后，接下来就遵循“V模型”进行需求开发和验证，ISO 26262对软、硬件开发的功能安全要求体现在了“V模型”的各个环节，总的来说ASIL等级越高，各个环节的功能安全要求越高。
功能安全开发与“V模型”
1.4.安全分析前面提到，ISO 26262的目标是将E/E系统的功能异常表现引起的危害而导致不合理的风险降低到合理的范围之内，而E/E系统是由最基本的要素即软件和硬件组成的，E/E系统的功能异常必然是由软件和硬件的异常引起的。
另一方面，当E/E系统的功能安全的目标转换成软件和硬件的安全需求后，将系统的不合理的风险降低到合理的范围内，就意味着需要将软件和硬件的异常（失效）控制在合理的范围内才算满足了相应的安全需求。
系统与组成元素
软件和硬件的所有失效可以归为两类：
随机硬件失效(random hardware failure)：在硬件要素的生命周期中，非预期发生并服从概率分布的失效。
系统性失效（systematicfailure）：以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其他相关因素进行变更后才可能排除这种失效。（如软件bug，硬件开发手册）
根据上面对两类失效的定义，可以得出软件和硬件相对应的失效特点下：
- 软件：只有系统性失效
- 硬件：既存在系统性失效，又存在随机硬件失效
软/硬件功能安全需求中的ASIL等级的的不同本质上是对要素避免系统性失效和随机硬件失效的要求的严苛程度不同。而协助和证明软硬件避免失效的能力达到了安全需求需要借助安全分析。
简单来说，安全分析的目的就是借助分析方法去实现以下三点目标从而证明产品符合ISO 26262的要求：
- 失效被完整地识别
- 系统性失效被有效地规避
- 随机失效被控制在了可接受的范围内
ISO 26262推荐的分析系统性失效的方法为FMEA (Failure Mode and Effects Analysis)，在《EPB功能安全笔记(8)——FMEA方法论介绍》和《EPB功能安全笔记(9)——FMEA方法论的拓展——FMEA-MSR》中对FMEA进行了全方位的说明。
而ISO 26262对随机硬件失效分析推荐的方法为FTA (Fault Analysis Tree) 。对于电子元器件的失效率而言，业界有统一的设计规范和衡量指标，所以在对电子电器产品而言，FTA的优势明显，不仅可以进行定性分析，还能进行定量分析。这也是ISO 26262推荐FTA的重要原因。由于随机硬件失效的相关内容不易理解，因此系列中用了5篇文章对这一部分进行说明，详细内容请参考EPB功能安全笔记(10) —— EPB功能安全笔记(15)。
1.5.功能安全验证和确认根据“V模型”开发流程，软/硬件需求实现以后，需要进行验证，这一过程被称为功能安全验证（safety verification）和功能安全确认（safety validation）。
verification和validation的释义十分接近，功能安全国标GB/ T 34590中将这两个词分别翻译成“验证”和“确认”，实际上单看这两个词还是会让读者产生含义重合的印象。
维基百科上对这两个词的解释非常到位：
- Verification：Have we made what we were trying to make? （预期的事情有没有实现？）
- Validation: Are we trying to make the right thing? （做的事情是否正确？）
沿着这个思路理解功能按照开发中的概念，可以得到如下解释：
- Safety verification：验证功能安全需求有没有被实现？
- Safety validation: 确认功能安全需求提的对不对？即功能安全需求实现了是否确实能保证安全？
根据这样的解释可以发现功能安全验证（safety verification）和功能安全确认（safety validation）属于两个维度。
关于系统/硬件/软件三个层级的功能安全需求如何进行安全验证（safety verification）分别记录在标准中的第4/5/6部分。而安全确认的目的概括为：
- 提供符合安全目标的证据及功能安全概念适合相关项的功能安全的证据。
- 提供安全目标在整车层面上是正确的、完整的并得到完全实现的证据。
由此可以看出安全确认中的“确认”在于确认安全目标及安全目标对应的安全标准(safety criteria)是否被满足。
在《EPB功能安全笔记(18)——功能安全验证和确认》中对功能安全验证和确认的关键点进行了详细说明。
1.6.功能安全评估当一切功能安全开发活动完成后，在正式量产之前，需要对开发产物进行审核，审核通过后方能释放产品。“ISO 26262，part2，功能安全管理”中详细介绍了功能安全的审核流程和要求，对应的术语为“认可措施，Confirmation measures”。
安全管理流程图，截图来自ISO 26262-2018, part2
Confirmation measures的主要目的是对功能安全开发过程及产物进行评估，以确认是否满足ISO 26262的要求。而这一评估需要从三个维度来展开，如下图所示。
这三个维度的对象及目的如下：
Key points
Confirmation review
Functional safety audit
Functional safety assessment
待确认的对象
功能安全开发过程中的关键输出物(如H&R,safety plan, safety concept, safety case等)
功能安全所需流程的实施情况
相关项（即进行功能安全开发的产品）
确认的目的
审查是否已经充分且可信地实现了按照输出物在ISO 26262中对应章节的目的和要求
审查实施功能安全开发的过程是否满足流程要求 （如safety plan是否创建并跟上项目节点）
审查相关项定义的安全措施是否完整地被实现了；审查安全措施是否合理且有效
在《《EPB功能安全笔记(19)——功能安全的认可措施（Confirmation Measures）理解与辨析》中对以上三个维度的措施进行辨析和说明。
Part2: ISO 26262展望站在2021年看智能驾驶，无疑是一片琳琅满目的壮观景象：层出不穷的黑科技：超大的显示屏娱乐功能强大，智能座舱高度数字化， OTA远程升级几乎是新车型标配，ADAS辅助驾驶功能也越来越丰富和实用。至于智能驾驶的终极目标——自动驾驶，在市场的狂热逐渐退烧后，各大厂家重新制定了自动驾驶计划。智能汽车正在朝着便利和解放驾驶员的方向上狂奔。
但是，除了给驾驶员带来便利以外，智能汽车更核心的愿景是减少交通事故，为人类创造更美好的生活。如果解放了驾驶员的同时却不能保证驾驶员的安全，个人认为智能汽车上的黑科技更多的是锦上添花，而没有大规模推广的意义。
而支撑这些智能驾驶技术的是全新的E/E系统及组成E/E系统的软件和硬件。从这个角度，致力于避免E/E系统失效而造成不可接受的风险的功能安全就显得更加重要。
但是，实现了功能安全的E/E系统就足够安全吗？
我们不妨先来看两个召回的案例。
1.7.案例12020年3月19日，由于自动紧急制动系统（Autonomous Emergency Braking, AEB）存在故障，沃尔沃汽车宣布在全球范围内召回汽车近74万辆，共涉及9款在售车型。此次召回的原因，是因为一些场景下无法有效识别物体，导致AEB在该工作的时候不工作。一般AEB探测物体依赖传感器毫米波雷达和摄像头两个关键传感器的信息融合。因为多普勒效应，毫米波雷达不擅长识别静态物体；而摄像头在雾天或者光线不足等情况下探测度都会降低，这些因素都会导致在一些场景下无法正确识别物体从而激活AEB。
因此，这次召回不是因为系统故障导致的，而是传感器本身的功能局限导致的，不属于ISO 26262的范畴。为弥补功能安全的局限，预期功能安全SOTIF (Safety of the Intended Functionality)以及标准ISO 21448便诞生了。
简单来说，SOTIF强调的是避免因为预期的功能表现局限而导致不合理的风险。
因为SOTIF诞生的背景是智能驾驶的发展，所以如果按照智能驾驶的功能链：感知——决策——执行来归类，“功能表现局限”体现在3个方面：
1.传感器感知局限导致场景识别错误
2.深度学习不够导致决策算法判断场景错误
3.执行器功能局限导致与理想目标偏差
目前SOTIF的标准ISO 21448已经发布了draft版本，按照计划在2022年3月正式发布。
1.8.案例22015年7月，两名美国白帽黑客成功侵入一辆正在行驶的JEEP自由光SUV的CAN总线网络系统，向发动机、变速箱、制动、转向等系统发送错误指令，最终使这辆车开翻到马路边的斜坡下。这起案件导致吉普大规模召回。
吉普车遭到黑客攻击，图片来自网络
功能安全和SOTIF研究的对象是智能驾驶系统自身可能产生的失效，还有另一。
黑客攻击也是也是未来智能驾驶不可忽略的一类失效。为了应对这一种情况，已经在互联网领域发展很成熟的信息安全正在被运用到汽车开发中。智能驾驶的智能化程度越高，可能被黑客攻击的点就越多，对信息安全的需求量更大。
这里需要强调一点，功能安全和SOTIF以人身安全为核心，但是不是所有的信息安全问题都会导致人身安全。换句话说，信息安全除了要考虑人身安全以外，还需要考虑黑客攻击带来的其他风险，比如车辆被偷导致的财产损失以及隐私泄露风险。
信息安全的研究范围
2020年车辆信息安全标准ISO 21434，Road Vehicle - Cybersecurity Engineering标准正式发布，该标准是基于SAE J3061制定的、针对车辆整个生命周期的标准。主要涵盖安全管理、基于项目的网络安全管理、持续的网络安全活动、相关风险评估方法、以及道路车辆概念验证阶段，产品开发阶段和开发完成后阶段的网络安全。对于该标准如何落地，业界尚在摸索中。
1.9.展望可以预见，随着智能汽车的发展，E/E系统的安全问题将会得到更为广泛的重视。与此同时，ISO 26262在保证智能驾驶系统的安全上暴露出了短板，智能驾驶系统的安全必然是需要同时从以下三个方面入手:
- 功能安全（Functional Safety）
- 预期功能安全（Safety of the Intended Functionality）
- 信息安全（Cyber Security）
这三个方面不是完全独立的，而是相互影响。那么，作为最先落地、业界经验最丰富的功能安全，如何同预期功能安全和信息安全更好地融合，是业界正在考虑的问题，也是功能安全在未来发展的最重要的方向。
,
