目录
1 引言
事件一：在意大利米兰北部的一个小镇塞维索（Seveso），制药巨头霍夫曼·拉·罗氏（Hoffman-La Roche）的子公司ICMESA拥有多年以前在Meda建造的一家当地化工厂。1976年7月10日，正处于周末，工厂的一部分处于关闭状态。当天下午，一个罐体由于制冷措施被关闭，温度达到了临界值，一个压力释放阀被自动打开，导致了约6吨重的有毒气体被释放到大气中。由此产生的在塞维索地区漂流的气体云估计含有一公斤的 TCDD，二恶英的一种。二恶英是普遍公认的致癌物质，在 ICMESA 设施气体释放后的几个小时内，塞维索地区各地 37 000 多人接触到前所未有的二恶英水平。然而，人们并没有第一时间撤离，即使是几天后纷纷出现症状，而其中最早遭受苦难的是该地区的动物：根据《时代》杂志报道，一个当地的农民看到他的猫倒在他面前，当农民想去捡起它时，发现猫的尾巴从身体上脱落了下来；2天后，当局挖出猫的尸体准备调查时，发现只剩下了猫的头骨。由于二恶英能够在动物体内积累，为了防止人们吃到被污染的动物，接下来的时间里约80000只动物被扑杀。而对人体受到的影响的研究仍然在继续，2008-2009年的研究报告发现，事故发生时出生的婴儿的甲状腺疾病及癌症的发病率均高于其他婴儿。
事件二：1984年在印度的中央邦城市博帕尔（Bhopal），发生了历史上最严重的化学泄漏。当年的2月3日，约45吨危险气体甲基异氰酸酯从美国联合碳化物公司印度子公司拥有的杀虫剂厂中泄漏出来。气体漂过人口稠密的街区，立即造成数千人死亡并造成恐慌，成千上万人企图逃离博帕尔。最后的死亡人数估计在 15 000 至 20 000 人之间。大约 50 万幸存者因接触有毒气体而遭受呼吸系统疾病、眼睛刺激或失明以及其他疾病；许多幸存者仅仅获得数百美元的赔偿。后来的调查表明，人员不足的工厂的操作和安全程序不合标准导致了这场灾难。1998 年，原工厂的工地移交给了中央邦。
历史上并非没有与人身安全（Safety）相关的标准。VDI /VDE 准则 2180《通过过过程控制工程手段保护工业过程设备》（Safeguarding of industrial process plants by means of process control engineering）从1966年就已开始实施，这个准则是与功能安全（Functional Safety）相关的第一套规则和法规，并导致了解决功能安全相关问题的IEC 61508（工业功能安全标准）和ISO 26262（汽车功能安全标准）的诞生。但VDI/VDE 准则 2108仅仅关注到了如何在工业设施中建立一个安全环境的过程。1984 年，该准则增加了操作安全和安全设备以及监控和保障设备之间的区别。此后，DIN VDE 31000—《设计技术设备以满足安全要求的一般指南》（General guide for designing of technical equipment to satisfy safety requirements）发布，详细阐述了风险、安全和危险之间的相关性，并引入了可承受的风险的概念。当时禁止使用微控制器进行安全应用的机械标准仍然很普遍。然而，已经存在着与安全有关的控制系统的既定市场。不同的规则和标准确定了这些系统的考试, 认证和设计要求的基础。
这篇文章想从系统开发的角度，聊聊汽车功能安全相关的话题。汽车目前几乎是我们社会中部署最广泛的和最复杂的系统。然而实际上，驾驶员的培训往往只是驾驶过程中可能遇到的各种情况的最小集合，而汽车却变的愈发的复杂。目前，随着互联及自动驾驶车辆的部署，这些对驾驶员及人身安全相关系统提出了进一步的挑战。在这篇文章中，想讨论几个问题：
- 汽车的功能安全指的是什么，它由什么构成？
- 与功能安全相关的人员的日常工作内容是什么？
- 开发功能安全相关产品的基础活动与考虑的内容有哪些？
- 开发功能安全相关产品，哪些成果物是非常重要的？
2 什么是汽车功能安全
与其它行业相比，功能安全概念在汽车行业起到显著影响多花了不少时间。一个主要的原因是汽车行业一直都是机械工程占主导地位，早期开发的安全机制主要靠机械手段实现，比如，基于冗余方式设计的液压或者气动系统。随着消费者、OEM和销售网络对汽车的功能提出了更多要求，自动化及电气化的系统成为了汽车功能的核心，也是实现更高性能和动态化的唯一途径。从最早的线控转向（steer-by-wire ）和线控刹车（brake-by-wire），到现在的自动驾驶，不可避免的在软件设计过程中，考虑更多的安全机制设计。
功能安全通常可以描述为在一个预先定义的场景中和给定的外部输入，与安全相关的系统能够做出正确的响应（这与自动驾驶领域的SOTIF有区别）。ISO 26262定义了汽车功能安全为“不存在由于 E/E 系统运行故障造成的危险造成的不合理风险（Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems）”。这里的危害（Hazard）指的是人身伤害，包括了驾乘人员、周边（车外）人员在内，而无论汽车系统故障产生了多大的经济和财产损失，这些是不在ISO 26262考虑范围内的。不合理的风险（Unreasonable risk）判定主要是在特定的情况下通过社会普遍适用的道德准则来进行，而ISO 26262的另外一个潜在的要求是在技术层面上要做到 “State-of-the-art”，这就使用产品开发时可用的最先进的技术。这2个方面就导致了对于功能安全产品开发的Know-how只会在一段特定的时间内有效，因为无论是道德准则和技术方案都随着社会的进步和技术的发展而变化，因此ISO 26262只是当时产品开发这个时间点对于产品本身的最低要求。
3 产品的安全生命周期
每个产品都有自己的生命周期，但产品功能安全生命周期根据产品的不同而不同。比如核电站，先从一开始规划、设计和建造，然后增加相关的安全机制（Safety Mechanism）用于消除风险和确保人身安全，最后开始运行。而对于汽车功能安全产品来说，生命周期则是另外一个过程：不同的汽车电子产品业务逻辑不同，因为从概念（Concept）层面上就开始有区分。而产品在概念阶段（ISO 26262:2018, Part 3)，就必须要能够证明它是安全（Safe）的。一旦初始的产品安全概念建立起来之后，则开始实施系统层面的产品开发（ISO 26262:2018, Part 4）。系统设计的过程中，除了要考虑到产品本身的各种限制（性能，安装，外部环境等等），还要考虑功能安全要求，需要将功能安全相关的措施落实到设计中，使得设计本身是安全的。系统层面的设计完成后，进入产品硬件层面的开发（ISO 26262:2018, Part 5）和产品软件层面的开发（ISO 26262:2018, Part 6）。系统设计并不意味着产品被正确的实现出来，硬件的元器件本身的失效率，元器件在PCB上的放置及连接，软件的代码基于不同的开发方法被生成、编译及与硬件集成，这些涉及到各种各样的开发技术，而这些技术及实施过程是否正确都可能会对产品最后的安全目标（Safety Goal）的达成造成影响。为了保障汽车电子产品能够安全的使用，必然要经历生产、维修和保养及拆解的过程（ISO 26262:2018, Part 7），直到最后报废。
4 安全概念
安全概念（Safety Concept）是整个计划实施的功能安全措施的基础。它包括了计划要在功能安全相关产品中实施的安全机制（Safety Mechanism）及，对于常规汽车电子产品开发流程中（如，ASPICE），需要追加的工程活动。通常来说，安全概念主要是解决一个问题，就是哪些目标需要在产品开发过程中达成，从而使产品的人身伤害的风险可以达到可接受的程度，即将具有ASIL（A - D）等级的风险降低到QM的程度。安全概念分为2个部分：功能安全概念（Functional Safety Concept）和技术安全概念（Technical Safety Concept），分别在ISO 26262:2018的Part 3和Part 4部分进行描述。
4.1 功能安全概念
功能安全概念中，对系统可能存在的风险进行等级的评定。评定过程在Part 3的危害分析和风险评估（Hazard Analysis and Risk Assessment）过程中进行。危害分析和风险评估针对的是系统功能（System Function），只有功能的失效在特定的场景中导致了整车的行为异常，并且这些异常导致了人身伤害发生，才可以给这些功能分配ASIL评级。系统功能派生自Part 3中的相关项定义（Item Definition）活动，相关项定义描述了系统需要支持的功能要求，性能要求，法律法规要求及系统的边界与外部接口、依赖关系等。
为了确定系统功能可能的失效模式，功能安全概念中采用了安全分析（Safety Analysis）技术。安全分析技术可以归纳为2类：内推法（Inductive）和外推法（Deductive）。内推法代表的技术为FMEA（Failure Mode and Effects Analysis）和HAZOP（Hazard and Operability Analysis）；外推法代表的技术为FTA（Fault Tree Analysis）。系统中功能失效导致的危害可以使用HAZOP方法有效的识别：针对系统中的功能，使用HAZOP中的关键字（如，输出过高，输出过低，无输出，反向输出等）一一进行失效模式匹配，匹配出的危害与驾驶场景库（如，雨雪天气，高速/隧道，城市/农村道路等，通常OEM有较全的场景模式）中的场景结合，识别出危害事件（Hazardous Event）。通过对危害事件的严重性（Severity），暴露度（Exposure）和可控度（Controllability）进行分析和计算，可以得出危害事件的ASIL评级。对于ASIL评级高于QM的危害事件，需要通过安全目标（Safety Goal）进行覆盖，安全目标的ASIL评级应与覆盖到的所有危害事件中最高的ASIL评级一致。
安全目标是功能安全开发中的最高级别需求，识别出来安全目标之后，后续针对安全目标的开发都要按照功能安全开发的流程来进行。安全目标的ASIL评级不同，所执行的流程中涉及的活动和要求的标准也不同（ASIL A最低，D最高）。识别的安全目标也不能过多，因为每一个安全目标都对应着大量的工作成果物，从成本角度需要尽可能的将安全目标合并。
功能安全需求（Functional Safety Requirement）派生自安全目标。因为在相关项定义过程中，系统已经有了一个初始的功能架构，因此，在Part 3中，将功能安全需求分配到系统的功能架构上，就得到了系统的功能安全概念（Functional Safety Concept）。在分配的过程中，可以根据限定条件，对系统的初始功能架构进行更新，如，系统中存在冗余部分（双路CAN输入），进行ASIL分解（ASIL Decomposition），或者系统中缺失实现功能安全需求的组件，相应的需要进行追加等。对于分配到功能安全需求的各个组件，相应的要分配ASIL评级，ASIL评级的高低取决于分配到该功能组件的功能安全需求的最高ASIL评级。
4.2 技术安全概念
技术安全概念阶段（Part 4）要将功能安全需求进一步派生为技术安全需求（Technical Safety Requirement）并落实到系统的物理架构上。这里的物理架构，指的是系统中实际存在的要素，如CPU、电源、输入输出（I/O）等，用于实现系统的基本需求。技术安全需求的派生，需要基于这些物理要素的依赖关系和限制条件进行，同时对于物理架构也提出设计修改的要求，如，设计一个方向盘锁，在车速大于10公里/小时的情况下，需要对方向盘锁进行断电，因此，在架构设计上，需要追加一个可控开关。另外，对于系统的接口，如，接插件（Connector），也要派生相应的技术安全需求。如果系统使用了支持配置（标定）的可重用组件，那么对于配置或标定数据，也要派生技术安全需求。安全分析的结果，也会导致系统架构的变化和技术安全需求的增加，如，基于硬件的故障检测电路与被检电路的独立性要求（依赖失效分析，DFA），需要系统架构中，能够为负责诊断的电路提供独立的电源。
技术安全需求中还需要描述清楚系统中采用的安全机制（Safety Mechanism），对于系统中产生的可能影响功能安全需求的故障或者失效要进行检测，阻止或减弱其影响，比如系统内部寄存器，总线或者逻辑计算单元，系统外部总线、I/O等。安全机制还包括如何引导系统进入及保持安全状态（Safe State）的方法，复杂一点的系统还需要采用软硬件结合的形式实现状态管理，如外部电源的状态和内部状态机系统的配合。对于不能在指定的故障容忍时间（Fault Tolerance Time Interval）内进入安全状态的场景，安全机制要定义警告及降级策略（Warning and Degradation Strategy），引起驾驶员注意系统目前的工作状态不处于安全状态。最后还要考虑针对安全机制的监控，避免故障潜伏，比如针对电源的检测机制，寄存器的检测机制如果失效，可能会导致潜伏故障（Latent Fault），造成多点失效。
技术安全概念要求将技术安全需求分配到系统的架构上，作为实现手段，这些需求应该分配到具体的软件和硬件上。这些软件和硬件的要素ASIL评级继承自分配到自身的技术安全需求的最高ASIL评级。不同ASIL评级的组件，开发的流程和成本不同。但由于一个复杂系统，会存在由不同ASIL评级的组件构成的情况，低ASIL评级的组件会影响到高ASIL评级组件安全目标的达成。所以，在不满足共存原则（Criteria of Coexistence）的情况下，所以的ASIL相关组件都要按照最高ASIL评级开发。共存原则要在系统设计层面、硬件和软件架构设计层面考虑，通过依赖失效分析（Dependent Failure Analysis），判断出可能存在相互影响因素，并采取隔离措施，包括但不限于，硬件的分区（如，单独的电源供给，单独的Clock等），软件的分区（如，CPU资源的预分配、内存空间的分配与保护，及执行逻辑的监控等）。
5 功能安全设计
功能安全设计可以分为系统设计阶段，硬件设计阶段和软件设计阶段。ISO 26262中，并没有给出如何进行如系统设计，硬件设计和软件设计的方法，只是在标准的各个部分中，提出了从功能安全的角度，架构师在开发这些设计时应考虑到哪些内容及达到哪些标准（如，硬件的SPFM和LFM，软件针对不同的ASIL组件，需要采用哪些设计、开发及测试手段等）。这与汽车电子产品开发过程中所涉及到的概念并不冲突，如产品开发中的过程模型（Process Model）（如，CMMI，ASPICE），主要用来解决做什么成果物及为什么做这些成果物的问题，标准（Standard）则告诉我们成果物的最低质量要求是什么，而对于设计阶段涉及到的怎么做的问题，则是由方法论（Methodology）来解决。ISO 26262属于过程模型和标准的范畴，因此需要找到合适的进行功能安全设计的方法论。
5.1 系统架构设计阶段
技术安全概念阶段要求系统的架构设计作为输入之一（Part 4，Clause 6），这个系统的架构设计标准中明确说明来自于外部。系统的架构设计体现了系统如何实现系统的基本功能（客户需求），但系统的架构并不完全取决于系统所要实现的功能，很多情况下，系统架构取决于针对所要实现的系统的限制条件。在功能安全的系统架构设计阶段，可以理解为将功能安全相关的限制条件加入到系统架构中。
在传统的系统架构设计过程中，有大量的针对系统架构的自然语言描述，以及非形式化的图形（如，Microsoft的Visio图形）。这些系统设计的记载方式，由于其缺少语法/语义的一致性（相对于半形式化与形式化的语言），在产品开发过程的上下游之间传递设计数据时，必然会引起歧义，导致工程过程出现追溯性（Traceability）及一致性（Consistency）的问题。而追溯性与一致性是消除产品开发过程中的系统性失效（Systematic Failure）的重要手段，因此引入模型化的系统设计方法（Model-Based System Engineering，以下简称MBSE）就成为功能安全产品系统设计的必然趋势。MBSE基于SysML（UML的变种，因为UML过于“软件化”）语言，通过模型的形式表达系统架构中的要素。模型化表达的好处很多，包括但不限于：精确的工程数据（如，需求，组件，时序及追溯关系等），各工程阶段的一致性（如，通过引用的方式在多个场景中使用相同的架构要素），可视化的架构易于理解，便于管理、维护及后期验证。
5.2 功能安全软件设计阶段
在功能安全软件架构设计中，最重要的参考模型就是AUTOSAR模型。AUTOSAR定义了汽车电子软件设计的参考模型和方法论，并且提供了一种元模型（Meta-Model）用于在不同的工具中交换设计数据。在应用层，AUTOSAR指定了软件组件（Software Component， SWC）的架构要求：Runnable, Task及Interface；在中间件层，AUTOSAR指定了包含各种服务的基础软件（Basic Software, BSW）；针对驱动层，AUTOSAR提出MCAL（Microcontroller Abstraction Layer）概念，用于建立一个与硬件平台无关的上层软件架构。为了解决ISO 26262中不同ASIL评级组件的共存准则的问题，基于Part 6中提出的避免干扰（Freedom from Interference，FFI）概念。AUTOSAR提供了相关的几种安全措施用于实现FFI：针对内存数据的保护，可以采用OS-Application的形式，建立软件分区，隔离不同ASIL评级的软件组件；对于CPU资源，使用通过OS进行CPU资源预算的限制，防止低ASIL评级的软件耗尽CPU资源；针对软件的执行逻辑，AUTOSAR提供了Watchdog Manager组件，用于监控程序逻辑是否正常（如，心跳或控制逻辑）；最后，对于不同的ECU上及不同ASIL评级的软件组件之间的通信失效，AUTOSAR提供了端到端保护（End-2-End Protection, E2e）。在软件设计过程中，基于安全分析，针对可能存在的失效场景，用于这些安全措施控制或减弱相关的风险。但需要注意的是，并不是应用了这些安全措施，系统就能达到指定的ASIL评级，还需要配合其它的安全机制。
在ISO 26262的Part 6中，多次提到基于模型化开发（Model-Based Development，MBD）的方法论。对于受认可的模型化开发工具，对于软件单元（Software Unit）的验证只需在模型层次上进行即可，这简化了对软件源代码的验证要求，如，静态代码分析（编码规则，复杂度等），单元测试等。MBD开发工具目前业内事实上的标准是Mathworks的MATLAB/Simulink工具，Simulink通过提供大量的图形化的组件和功能实现对信号处理的仿真。针对软件单元的验证，Simulink提供了自动化的模型检查工具（Model Advisor），测试用例生成工具（Design Verifier），测试工具（Simulink Test）等简化软件的验证过程。
5.3 功能安全硬件设计阶段
ISO 26262针对软件部分提出的需求主要是针对产品开发过程中可能存在的系统性失效，如需求不可追溯，导致需求未实现或过多实现，或者由于测试不充分，导致系统存在影响安全目标的软件Bug。这些潜在问题如果随着产品发布流入到市场中，必然会造成品牌形象的损害，并导致高额的召回成本。因此，系统性失效是务必要借助流程的优化进行消除的。功能安全的硬件设计同样存在系统性失效的风险，因此层次化设计，精确的接口设计，避免复杂的接口和组件设计及可测试性就成了消除硬件功能安全设计中系统性失效的重要手段。同时，硬件设计也需要基于安全分析（如，FMEA或FTA等）手段，分析硬件设计中可能存在的故障及其影响，并根据分析的结果决定是否需要增加安全机制并更新硬件设计。
在硬件架构设计过程中，需要考虑的另一个核心概念是针对随机硬件失效（Random Hardware Failure）的处理。由于元器件自身的原因，必然存在失效，其失效率的变化曲线可以参考经典的浴盆曲线。硬件设计对于随机硬件失效的处理能力是通过量化指标的方式来计算和评估的。其中，单点故障指标（Single-Point Fault Metric，SPFM）和潜伏故障指标（Latent-Fault Metric）用于评估硬件在架构层次上应对随机硬件失效的能力；而PMHF（Probabilistic Metric for Random Hardware Failures）和EEC（Evaluation of Each Cause）用来分析系统中残余风险（Residual Risk）对于系统安全目标的影响是否足够低。
硬件设计中，另一个重要的概念是诊断覆盖率（Diagnostic Coverage，DC）。诊断覆盖率用来评估硬件要素（或，硬件要素的某个失效模式）的失效被安全机制诊断到或者控制的百分比。同时，诊断覆盖率也是计算SPFM和LFM的重要输入。硬件元器件的失效模式及对应的失效率可以通过一些公认的估算手册查寻（如，IEC/TR 62380, IEC 61709等）。不同的估算手册数据可能会有差异，对于一家公司来说，参考的估算手册最好是其中一本，不能因为其它手册中某项计算结果符合指标要求而进行结合使用。不同的安全机制提供了不同的诊断覆盖率，如对于总线上的数据传输，奇偶校验对于数据传输过程中失效的覆盖率一定低于CRC校验，因此在ISO 26262:2018, Part 5的附录D中，给出了系统中关键组件的失效模式及各种安全机制的覆盖率估算数据。
6 生产、维护和拆解
生产过程中的功能安全主要是指要建立保障安全相关组件正确工作的生产流程，并且提供给用户必要的操作、维修和保养及拆解的相关信息（比如，用户手册等）。为保证相关的功能安全需求能正确的识别，消除可能产生的系统性失效，需要使用Design FMEA和Process FMEA等技术手段。DFMEA用于发现控制产品生产过程的关键因素；PFMEA用于发现哪些过程错误可能会影响功能安全，并制定相应的需求。与生产相关的功能安全需求需要记录在案并与实际的生产过程建立追溯关系，这些需求可以包括，软件的配置，设备的标定，软件的烧写等等。
在产品的维修和保养过程中的功能安全中，用户手册和维修手册需要一并考虑。为了使驾驶员能够正确的使用功能安全相关的产品，避免错误使用方法要体现到用户手册中，如，天气原因对自适应驾驶（ACC）的限制，需要让驾驶员对产品功能有正确的理解。在维修过程中，错误的安装方法可能会造成人身伤害，因此在维修手册中，也要给出考虑到安全方面的安装说明，如维修时针对软件的重新烧写，传感器的标定，针对产品的标签管理等。
产品的拆解是产品生命周期的最后一个环节，拆解过程中要遵守用户手册和维修手册中的内容。比如，对于安全气囊的拆解，需要按照指定的过程先停用安全气囊的功能，否则在整车的拆解过程中，可能会触发安全气囊造成人身伤害。另外，如果某些安全相关系统还可以被再次使用，则需要加入相关的需求，避免错误的安装导致的风险。
7 总结
这篇文章简要介绍了一下功能安全产品开发中涉及到的几个重要概念及相关的分析、设计和开发的活动及它们之间的关系。功能安全的主要目的是控制产品的风险在可接受的范围内，而不是彻底消除风险。由于可接受风险这个定义是与时俱进的，因此产品的功能安全相关需求也会随着技术与标准的进步而变化。产品的功能安全设计是否足够安全无法从绝对的意义上来证明，所以在开发过程中，所有过程与设计相关的工作产品（Work Product）就成为评估过程中的重要证据。公司的功能安全文化，符合标准要求的流程体系与人员能力评估及培养体系，是应对日益变化的功能安全产品需求的重要基础。