本文首发于知乎专栏《功能安全工程师的笔记》，专栏旨在持续分享作者的工作总结及行业动态，欢迎关注交流。受限于作者个人经验，如果同行朋友们有不同的想法和见解，欢迎在留言中分享交流。
ISO 26262：absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.GB/T 34590：不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。既然是“避免风险”，那么首先要做的就是“识别风险”，专业术语为“危害分析与风险评估”。在ISO 26262的第3部分对识别风险的方法论做了细致的阐述，同时也定义了很多贯穿ISO 26262始终的关键概念。但是，当密密麻麻的定义和概念同时摆在眼前时，很难做到全部吸收，要么是理解时出现一些偏差，要么是忽略了一些细节。本文试图根据经验总结和梳理危害分析与风险评估的要点和常见误区，为后续文章的展开铺路。
相关项定义（Item Definition）
在对某个产品展开功能安全分析与开发之前，需要先明确产品的功能以及产品的边界。这一活动被称为“相关项定义”。为了方便后续说明，选取一个电子电器系统作为相关项。德国汽车工业协会（German Association of the Automotive Industry ，VDA）发布的《VDA Recommendation 360 Interface ESC eBooster V1.0》中对ESC和eBooster的功能有系统的介绍。相比较ESC来说，eBooster的功能更加简单易懂，且VDA360对eBooster的对外接口有详细的定义，更重要的是，里面还包含功能安全的指导性章节，个人认为这是一个很好的素材。所以，这个系列的文章将会以eBooster为研究对象来展开。eBooster作为取代传统真空助力器的电控系统，其工作原理可简要概括为：当驾驶员踩下制动踏板时，推动输入推杆产生位移，踏板行程传感器记录输入推杆位移，将其发送至eBooster ECU，ECU根据位移计算并控制助力电机产生力矩推动制动主缸推杆，使得主缸释放液压到轮缸以实现液压制动。工作过程可以缩略为：踩制动踏板→产生位移信号→电机转动提供助力→实现制动。目前市场上主流的eBooster产品是博世的i-Booster，如下图所示。驾驶员制动时提供制动助力
制动过程中点制动灯
反馈eBooster状态信息给HMI系统
危害分析与风险识别（Hazard analysis and risk assessment）
总的来说，危害分析、风险识别和ASIL等级评定都是为了定义研究对象（item）的安全目标（Safety Goal），而所有活动都是基于相关项定义的功能和接口来展开，识别并评估相关项的可能失效导致的危害和风险。针对这一活动，有3点需要强调。要点1（摘自GB T-34590 part3, 7.4.2.2.2）：要点2（摘自GB T-34590 part3, 7.4.1.2）：要点3（摘自GB T-34590 part3, 7.4.2.2.2注1）：既然是以整车层面观察到的行为来定义危害，那么，从整车动力学的角度，汽车的运动轨迹可以被下图中的运动坐标系完全包含。
而在每一个坐标系上，因为控制不当而可能产生的所有的整车表现也能被界定。思路如下图所示。
因此，在进行危害分析和风险评估时，不需要明确研究对象的具体设计，只要明确研究对象的功能和接口会影响整车哪个坐标系上的控制，就可以将研究对象的功能失效可能导致的危害与该坐标系上对应的整车危害链接起来。当然这里要补充一点，所有运动坐标系上可能的危害并不能包括整车能产生的所有的危害。比如，人机交互界面的设计越来越受重视，当系统失效后，如果HMI系统能够及时把故障报告给驾驶员请求驾驶员接管甚至指导驾驶员接下来如何操作，可以避免危害。所以对于HMI系统也有相应的功能安全需求，相应的，也需要对其进行危害分析与风险识别。以eBooster为例，其功能之一为：在驾驶员制动时提供制动助力。所以该功能有车辆纵向控制的接口，那么，如果eBooster功能失效，可能在驾驶员没踩制动时产生非预期的过大制动力。到这里，已经地识别出了eBooster相关的一个危害。在这个过程中，无需去细究危害是eBooster的软件bug还是传感器出了问题导致的，更不能考虑因为eBooster内部已经有故障监控模块可以及时避免这个危害的产生。换句话说，是先识别出了危害，再考虑对这个危害进行相应的安全措施设计（如监控模块设计），这是后面功能安全概念（Functional Safety Concept）设计需要考虑的内容，在后续的文章中会详细展开。虽然在危害分析与风险识别中不能考虑研究对象的内部安全措施，但是，外部措施（external measures）是可以被考虑的。怎么理解呢？比如装备eBooster的车辆同时也装备了ESC（Electronic Stability System, 车身稳定控制系统），那么对于eBooster在驾驶员没踩制动时产生非预期的过大制动力的危害，由于有ESC的存在，所以对eBooster进行危害分析时，无需考虑制动力过大而导致车辆失稳这种危害。（摘自GB T-34590 part3, 6.4.1.2注1）：在对相关项进行评估过程中,可用的且充分独立的外部措施是有益的。
（摘自GB T-34590 part3, 6.4.2.3注2）：仅考虑与相关项自身相关的危害,假设其他充分独立的系统(外部措施)均正确工作。
最后再补充一个容易让人疑惑的点。ISO 26262中指出，危害分析与风险识别不仅考虑车辆正常使用中功能失效，还要考虑车辆误用时的功能失效。这难免让人产生疑惑：既然超出了功能设计的使用范围，还要考虑它干嘛？个人认为这个定义是合理的。首先，抛开功能安全，一款产品的设计或多或少都会考虑到一些可能被误用的场景并加入防错设计，考虑的程度取决于加防错设计的成本。比如现在流行的EPB电子手刹，按钮设计成往上掰才激活而不是按压激活，就是因为考虑到在实际使用过程中按钮可能会错误地被按压，比如放水杯时按到或者把手提包放在上面。
但是，这样一来另一个问题产生了：“功能误用”的边界在哪里？如果考虑的话危害分析岂不是穷举不尽？可能ISO 26262的制定者可能也考虑到了这一顾虑，因此在ISO 26262第二版中对定义进行了更新，加了一个关键词“reasonably ”。我想，“unreasonably ”的场景应该是在SOTIF中考虑。The operational situations and operating modes in which an item's malfunctioning behavior will result in a hazardous event shall be described, both for cases when the vehicle is correctly used and when it is incorrectly used in a foreseeable way.The operational situations and operating modes in which an item's malfunctioning behavior will result in a hazardous event shall be described; both when the vehicle is correctly used and when it is incorrectly used in a reasonably foreseeable way.
危害事件分类（Classification of hazardous events）
不是。接着上面的例子，eBooster有导致车辆非预期制动的危害，但是当危害发生在高速公路上时，很可能造成人员伤亡；而当危害发生在自家的车库时，几乎没有人员伤亡的风险，顶多就是驾驶员被吓一跳然后开始骂娘。也就是说，危害识别出来后，我们还要结合危害时刻车辆运行的场景，来对危害所能造成的风险进行评估。而车辆的运行场景，可以理解为是下图各个因素的排列组合。
ISO 26262定义了危害事件分类的方法，综合场景与危害，将筛选指标分为三个维度：S（severity 严重度）：危害发生对驾驶员或乘客或路人或周边车辆中人员会造成的伤害等级。评分表：
E（Exposure 曝光度）：运行场景在日常驾驶过程中发生的概率。评分表：
C（controllability 可控度）：驾驶员或其他涉险人员控制危害以避免伤害的概率。评分表：
基于这三个维度的评分，确定ASIL等级即汽车安全完整性等级（ automotive safety integrity level）。ASIL一共分为四个等级，D代表最高严格等级，即风险最高，A 代表最低严格等级，即风险最低。
补充一点，实际上还有一个等级QM，表示只要按照企业流程开发就可以满足ISO 26262要求，ISO 26262开发无需考虑。ASIL等级评定方法和指标，概括起来很简单，但是实际上操作起来却有很多困难。虽然在ISO 26262 part3的附录中对S/E/C的评分做了一些补充说明和示例，但是个人觉得这些补充还是太宽泛。以S值为例，表格中提到的“非常低的速度”、“中速”等词太过模糊，对实际分析作用不大。
换个角度想，ISO 26262那么多专家坐在一起也只能定性到这样一个模糊的程度，说明实际上这些值的评定会受很多因素的影响，比如具体的车辆设计参数、不同国家的驾驶情况不同等等，所以无法得出一个统一的标准。或者说，即使得出了统一的标准，也会因为要同时涵盖太多的因素而导致评定结果保守严苛，不利于功能安全开发。SAE J2980标准基于ISO 26262的既有定义，在评分方面做了更详细的说明，以期提供给车企企业做参考。于此同时，不同的车企也会基于已有的事故数据，结合整车仿真模拟和实车测试来细化自己的评判标准。对S值来说，企业最终形成的评分标准大体上会细分成类似SAE J2980推荐表格的形式，如下图所示，只是车速范围上有些许差别：
对C值来说，车企则会定义一系列的Controllability study测试。针对识别出来的可能存在风险的场景，设计故障注入测试，并（尽量）随机选择驾驶员进行实际道路实验。最终综合驾驶员主观评价和整车动态表现的客观参数来评定出安全边界，为后续功能设计提供边界参考，保证功能失效后仍在大多数驾驶员的可控范围内。值得一提的是，这种Controllability study成本非常高，且从测试用例设计到测试结果评价都处处体现了企业的know-how，属于企业的核心机密。对S值和C值的评定，不同企业可以根据已有的事故数据达成基本的共识，如果出现分歧，也基本上可以通过仿真和实车测试的结果来验证以消除。但是对场景暴露度E值的评估则不同，因为定性分析的成分很大，且不同国家的驾驶场景有区别，面对分歧双方又很难提供有说服力的数据，所以，相比S值和C值，E值的评定往往争议性比较大，各个车企之间分歧比较多。有一个例子最能说明E值评定的难度。德国汽车工业协会（German Association of the Automotive Industry ，VDA）曾经把德国车企巨头召集起来，试图对E值的评定形成一个行业统一的指导标准，虽然最后释放了一版标准VDA 702，但是就连这些参与制定的车企最后都没有完全遵守，更别说其他国家的车企使用了，因此这份标准至今仍然只有德文版。虽然不同车企对E值的评定有着不同的理解和标准，但是至少都以ISO 26262中的定义为共识。在ISO 26262的定义中，有以下两点需要特别注意。1. 当预估暴露概率时,不应考虑装备该相关项的车辆数量。举个例子：对于AVP（自动代客泊车，Automatic Valet Parking）功能，因为功能在使用过程中驾驶员是不在车内的，属于自动驾驶功能，如果车辆在泊车过程中没有识别到行人，由于驾驶员无法接管，会导致撞人甚至碾压风险。针对这一危害的ASIL等级，以下分析是否正确呢？
搭载AVP功能的车辆只在XX城市销售，且只在XX区域的停车场才能运行，所以运行过程遇到行人的E值比较低......
这显然是违背了ISO 26262的定义，搭载该功能的车辆的数量低，并不意味着“车辆在泊车过程中没有识别到行人造成碾压风险”的概率会降低。试想，假设有一个人正好住在这个停车场附近，每天都能使用这个停车场和AVP功能呢？换句话说，暴露概率的评估是基于假设每个车辆都配备有该相关项进行的。这意味着“因为该相关项未装备在每个车辆上(只有一些车辆装备该相关项)，所以暴露概率会降低”的观点是不成立的。在进行危害事件分类时，理论上如果场景划分得越细，越容易对S值和C值做出准确的评定。但是，场景划分过细可能导致E值降低，从而评定出一个不合适的偏低的ASIL等级。场景：车辆停在坡道上，驾驶员离开后驻车系统失效，导致车辆后溜。- S值：如果坡道够长，碰撞时车速较高，甚至有碰撞后的碾压危险，S3
- C值：驾驶员不在车内，行人可能在下坡无法注意到车辆从而无法躲避，C3
- S值：如果坡道够长，碰撞时车速较高，甚至有碰撞后的碾压危险，S3
- C值：驾驶员不在车内，行人可能在下坡无法注意到车辆从而无法躲避，C3
- S值：如果坡道够长，碰撞时车速较高，甚至有碰撞后的碾压危险，S3
- C值：驾驶员不在车内，行人可能在下坡无法注意到车辆从而无法躲避，C3
显然对于这一风险，ASIL B更加合理，但是场景过于细分后评成了ASIL A。针对这一问题，不免有这样一个疑问：怎么把握场景细分的度呢？个人认为，没有标准答案，合理性取决于企业和工程师的经验。最后强调一点，写作的目的是为了和同行朋友们交流探讨，相互学习。个人理解肯定会有不当之处，欢迎各位同行朋友们指出错误，我会持续对文章进行更新保证准确性。
关于危害分析与风险评估的要点和误区就记录到这里。但是，得出ASIL等级就能进行接下来的功能安全开发了吗？还远远不够。下集将仍然以eBooster为例，详细说明：
- 除了ASIL等级，一条完整的功能安全需求需要具备哪些属性？
