详解功能安全概念阶段

“当我们展望未来新技术的挑战时，采用统一的开发和应用标准至关重要。” — 通用汽车副总裁 Ken Kelzer， 2018。

在诸多的标准与规范中，ISO 26262（汽车功能安全标准），继承自 IEC 61508（通用电子电气功能安全标准），定义了针对汽车工业的安全（Safety）相关组件的国际标准。简单的说，ISO 26262通过指导与规范化的形式，对汽车电子产品，从概念阶段到最后的产品报废阶段，提出了标准化的要求。更进一步的是，ISO 26262细化了如何控制一个汽车电子产品或组件的人身伤害风险在可接受的范围，及文档化整个分析、设计、开发、测试及生产过程。

ISO 26262的历史可以追溯到2011年，第一版的ISO 26262标准发布。第一版标准包含10个部分:

Part 1: 词汇（Vocabulary）
Part 2: 功能安全管理（Management of functional safety）
Part 3: 概念阶段（Concept phase）
Part 4: 系统级的产品开发（Product development at system level）
Part 5: 硬件级的产品开发（Product development at hardware level）
Part 6: 软件级的产品开发（Product development at software level）
Part 7: 生产，运营（Production and operation）
Part 8: 支持过程（Supporting processes）
Part 9: 面向ASIL及面向安全的分析（Automotive Safety Integrity Level (ASIL)-oriented and safety-oriented analyes）
Part 10: ISO 26262指南（Guidelines on ISO 26262）

相对于2011版的ISO 26262，发布于2018年的第二版标准修改了Part 7的名字为：

Part 7: 生产，运营，维护及报废（Production, operation, service and decommissioning）

同时还增加了2个部分：

Part 11: 半导体厂商应用ISO 26262的指南（Guidelines on application of ISO 26262 to semiconductors）

Part 12: 适用于摩托车的ISO 26262（Adaptation of ISO 26262 for motorcycles）

在ISO 26262的Part 3中，介绍在产品开发的早期阶段的活动及用于保障功能安全的开发流程。这个部分包含了相关项的定义（Item Definition），危害分析与风险评估（Hazard Analysis and Risk Assessment）的内容。本文将从基本概念出发，介绍ISO 26262 : 2018 Part 3相关的流程，分析方法及相关技术。

1 基本概念

ISO 26262中的概念众多（2018版185个），无法在一篇文章中一一描述，所以在本节中，只针对Part 3中涉及到的重要概念进行解释说明。其中可以涉及到到的其它名词，都符上英文名词，便于在标准中查找。

1.1 相关项定义（Item Definition）

Part 3的第一个活动是相关项定义（Item Definition）。相关项定义对于应用ISO 26262到产品中非常重要，参与到产品开发人员和咨询人员需要对产品有深入的了解，而相关项定义则提供了理解产品所必需的信息。相关项（Item）在标准的Part 1中定义如下：

应用了ISO 26262开发标准，实现了整车级的某个功能或者某个功能的一部分的系统或者系统的组合（System or Combination of Systems）

而相关项定义（Item Definition）是为了描述清楚：

相关项（Item）的功能，依赖关系，与驾驶员、周围环境以及其它整车级相关项的交互关系

提供足够的信息用于理解相关项（Item），以便于后续过程中的活动能够执行

1.2 相关项的构成

一个相关项（Item）可以分解为1个或多个系统（System），并向外提供1个或多个功能（Function）。系统可以由多个子系统（Sub-system）构成，也可以分解为多个组件（Component）。构成一个系统或子系统的组件至少是3个：负责输入信号的传感器（Sensor），负责信号处理及逻辑控制的控制器（Controller）及负责输出的驱动器（Actuator）。一个组件（Component）可以由1个或多个软件单元（Software Unit）或1个或多个硬件（Hardware Part）构成。下图给出了这些概念的逻辑关系：

1.3 危害分析与风险识别（Hazard Analysis & Risk Assessment）

危害分析与风险识别（以下简称HA & RA）的主要目的在于以下2个方面：

识别危害与危害事件（Hazard and Hazardous Event），相关项的异常行为会导致这些危害事件

为预防与缓解识别出来的危害事件，推导出相应安全目标（Safety Goal）及其ASIL评级，来避免不合理的风险

ISO 26262:2011中，HA & RA的输入主要是相关项定义（Item Definition） 和 影响分析（Impact Analysis）。影响分析指出了2种可能的进入HA & RA的初始条件：

从产品的Idea和期望的功能开始，把相关项视为全新开发而进行HA & RA

由于产品本身的功能修改或者运行环境变化，从影响分析（Impact Analysis）开始进行HA & RA

从2018版开始，关于影响分析的部分被划分到Part 2 功能安全管理中，因此在2018版中，只有相关项定义作为HA & RA的输入。

相关项定义的过程中，已经考虑了产品的功能、性能及可能的失效带来的后果（如已知的失效模式），但并没有这些需求进行分类。通过HA & RA识别产品的安全目标，将这部分需求同产品自身功能区别开，纳入功能安全管理的流程（如下图所示）。因此，HA & RA对于产品的后续开发活动有重要的意义。

1.4 危害与危害事件（Hazard and Hazardous Event）

危害（Hazard） 是指由于产品功能的失效，作为潜在的原因，会导致发生人身伤害。但这种危害只是一种可能性，把危害和危害发生的场景（Operation Situation） 结合起来，形成危害事件（Hazardous Event），才能对其进行分级（如，可接受或不可接受）。对危害事件的分级主要考虑以下3个方面：严重度（Severity），暴露度（Exposure）和可控度（Controllability）。在HA & RA过程中，分别对这3个方面进行打分：严重度（0 - 3，伤害的严重程度逐渐增加），暴露度（0 - 4，暴露在危险环境中的程度逐渐增加），可控度（0 - 3，危害发生时的可控度逐渐降低）。这3个数值中，经过评估任一数值取值为0，或者相加后的数值小于7，则认为这个危害事件的风险可接受，即相关的功能开发按照QM管理即可；但如果相加的数值大于等于7，则认为风险不可接受，对这个危害事件要分配 ASIL（Automotive Safety Integrity Level） 等级。ASIL分为4个等级，分别对应相加数值的7，8，9和10。ASIL与严重度、暴露度和可控度的对应关系可以参考下表：

1.5 安全目标（Safety Goal）

对于识别出的危害事件，进行细致的分析，并制定安全目标（Safety Goal）。安全目标在功能安全产品开发中，处于最上层的需求。安全目标与危害事件之间，可以是1:N或N:1（N大于等于1）的关系。安全目标可以用自然语言的形式来描述，通常是如下的模式化形式：

避免（Avoid to），如，避免近光灯非预期的熄灭

阻止（Prevent to），如，阻止安全相关提示信息在2秒内关闭

应该（Should），如，收到胎压不足的警告信号后，胎压不足警告灯应该亮起

每个安全目标都有对应的ASIL评级，安全目标的ASIL等级取决于与之相关联的风险事件的最高ASIL等级。可以为每个安全目标分配故障响应时间间隔（Fault Tolerance Time Interval），用以规定检测违反安全目标的故障和安全机制响应时间的最大间隔。安全目标可以用如下的表格的形式表示：

1.6 功能安全需求（Functional Safety Requirement）

功能安全需求（Functional Safety Requirement，FSR）派生自安全目标，一个安全目标至少派生一条功能安全需求。派生出的功能安全需求有无歧义，可理解，无矛盾，可实现及可测试等要求。派生的过程中，功能安全需求独立于系统的技术架构，还要给功能安全需求分配唯一的ID，当前状态及对应ASIL等级属性。下面是一个表格形式的功能安全需求的例子：

1.7 功能安全概念（Functional Safety Concept）

功能安全概念（Functional Safety Concept）是Part 3的最后一个活动。虽然在产品开发尚未进入系统设计阶段（Part 4），但此时需要假设一个系统架构（System Architectural Design），因为功能安全概念需要在整车的架构上实现。功能安全概念阶段需要描述必要的功能安全需求，并分配这些安全需求到系统的功能要素（Element）上。在ISO 26262中，功能安全概念阶段要求达成以下目标：

指定与相关项安全目标相符功能行为（Functional Behavior）或者降级的功能行为（Degraded Functional Behavior）。系统功能的降级是指如果由于故障不能正确的运行，需要系统工作在一个功能或性能受限的状态。一般系统降级要设计降级的策略，如近光灯系统，降级策略要求至少有一个灯可以工作。

根据安全目标，指定针对合适的手段及时检测和控制相关的故障的限制条件

在相关项的层面上，设计策略或者措施用来达成要求的容错能力，或者基于相关项本身、驾驶员或者外部措施以减轻相关故障造成的影响

分配功能安全需求到系统架构或者外部措施上

验证功能安全概念并指定功能安全确认标准，这里的验证是指对设计过程的验证（Verification），主要是检查设计过程的正确性。

2 功能安全概念阶段相关技术

为保障功能安全概念阶段的活动能够正确实施，对应每个活动都有一系列的实施方法。本节对涉及到的一些重要技术手段进行介绍。

2.1 识别相关项（Identify Item）

为了识别出相关项（Item)及针对相关项（Item）任何的功能开发之前，无论这些涉及到的功能，是否是功能安全相关的，都需要一个合适的出发点。在这里，系统工程（System Engineering）的方法论可以给出一个很有价值的方案。系统工程方法论中，为描述系统对外提供的服务，有一个针对系统上下文（System Context）建模的过程。通过模型化的系统上下文，可以表达出一个系统针对周围环境直接的影响，还可以得到系统的输入与输出信息流（包括数据流与控制流）。在这个阶段，在外部与系统交互的是系统参与者（System Actor）。

通常系统工程中对系统建模采用SysML/UML，但系统上下文并没有作为独立概念在SysML/UML中存在，因此需要引入一种能够形象表达系统上下文的方法：SYSMOD。通过SYSMOD，我们就可以在SysML/UML中，以如下的方式定义一个车灯管理系统（Headlight Management System）的上下文：

2.2 明确相关项的边界

一个车载系统或相关项，必然要和周边系统或驾驶员产生交互，它的边界就是一个非常重要的信息：哪些组件属于系统元素，哪些位于系统之外？这些信息要在相关项定义这个过程中识别出来（至少是一部分，因为有时项目初期产品的需求并不十分明确）。明确相关项边界的第一个任务是要明确系统交互的参与者（System Actor）。系统参与者在概念阶段应该是清晰的，否则就会陷入一个怪圈：如果系统的开发者对于系统的使用者无法识别清楚，那么该如何正确的建立系统的概念和理解呢？下面有几个方法可以快速的帮助识别系统的参与者：

系统的参与者应该主要来自于需求分析

系统的参与者应该是使用系统提供的服务或接口，与系统有直接交互的人员

与正在开发的系统有交互的其它系统也应该被列为系统的参与者，并且进行分类，如，传感器，驱动器，外部系统，或者由于系统的运行，会受到影响的外部环境（光线、温度等），这些可以帮助我们更好的理解当前开发的系统，更容易的描述其提供的服务

识别出系统的参与者之后，第二个任务要识别出参与者与系统之间的信息流。通过SysML/UML，我们可以建立系统参与者和相关项之间的连接（如使用Connector将2者相连），这表示系统的参与者提供信息流给系统，或者接收从系统提供来的信息流（如从传感器来的车速信号，或者输出到屏幕的视频信号）。同系统的参与者一样，我们需要在系统开发的早期识别出这些信息流，并用建模的形式把它们识别出来（可以使用SysML中的Information Item来表示，参考系统上下文图中的黑色三角）。以下几个方法可以用来识别系统中的信息流：

哪些信息是系统参与者发送给相关项的，如系统上下文中的车辆信号、开关信号

这些信息是否与我们正在实现的系统密切相关

相关项如何集成到整车环境中，如与供电模块的连接

相关项发送哪些信息到系统的参与者

定义完系统的参与者与相应的信息流后，最后一个任务则是它们如何同相关项交互（包括输入及输出），即识别出系统的交互点（Interaction Point，系统上下文图中的带箭头的小正方形）。当我们使用Connector建立系统参与者与相关项之间的连接时，Connector与相关项的交点可以认为就是交互点。但这种识别方法不够精确，需要使用以下方法进行提炼：

相关项使用哪些途径与外界交换信息

已识别出的交互点是概念上的还是物理上的

是否有哪些交互的路径可以合并的

需要注意的是，在功能安全概念阶段，系统的交互点（Interaction Point）和系统接口（Interface）是不同的：系统交互点在这个阶段仍然是个抽象的概念，只用于识别相关项与外部环境之间存在交互；而接口则包含在交互点内，描述相关项对外要求或提供的服务，以及信息流的具体内容。接口的建模在系统设计过程中实施，如ASPICE流程中的SYS.2。

2.3 需求定义技术（Techniques for Specifying Requirements）

概念阶段的功能安全需求（Functional Safety Requirement）是后续功能安全开发活动的基础。产品开发的成功或失败依赖于功能安全需求的质量，大量的事故可以追溯到有缺陷的需求，如不完整的表述，错误的实现以及对不清晰的需求的错误理解。ISO 26262中需求可以分为4个等级（但不限于4个，可以根据需要再细分）：功能安全目标，功能安全需求，技术安全需求及硬件/软件安全需求。好的需求对于产品质量、成本/时间、功能安全的实现及测试都有重要的意义，因此本节对需求的定义技术做一些基本的描述。

需求定义通常由需求工程师进行。大多数成功的项目至少有2名资深的需求工程师，他们协同工作并相互检查对方的成果。需求开发过程中，最好也有其他的助理工程师加入，因为从组织的角度，需求开发过程中的知识积累需要传递给下游的工程活动，并且组织也需要培养更多的需求专家。需求开发要求的工程师技能要求一般包括以下几点：

需求开发的经验。没有什么比经验更重要，经过多个项目的磨练后，有经验的工程师可以判断出哪些该做，哪些不该做。即使没有成功项目的经验，那么那些从失败的错误中获取的经验也十分重要。

合作。需求工程师几乎和项目中的所有人员打交道，特别是在敏捷（Agile）开发团队中，还要和客户进行面对面的沟通。

倾听和观察的技巧。需求工程师应该擅长从系统工程师或客户处发现细微的线索，用于挖掘缺失的需求。

写作沟通能力。需求工程师的主要角色是将需求文档化，那就要求需求工程师能够清晰有组织的把需求表达出来，即使是一些复杂问题和想法。常用的手段包括图表化、数据流图、控制流图、用例图或状态图等。
领域知识。对于正在开发的产品，需求工程师要具备相应的领域知识，如导航工程师就不是十分适合开发刹车或者燃油系统的需求。

需求的表达方式除了采用MS Office系列（Word，Excel），还可以使用支持SysML的工具进行描述，除了具备直观的好处之外，还可以和后续的工程活动方便的追溯（见下节）。SysML中增加了需求图（Requirement Diagram）用于描述系统需求，如下图所示：

在工具中，每一个需求块（Block）会分配一个全局唯一的GUID，可以用于标识这个需求。但GUID通常与需求定义时分配的ID不一致且难于理解，因此针对需求块，SysML还提供了需求ID字段，用于与外部工具建立需求对应关系。另外，为方便在各个需求管理工具之间交换数据，通常会采用CSV格式的表格，通过导入/导出的形式进行数据传递。

2.4 追溯性相关技术（Techniques for Traceability）

作为消除系统性故障（Systematic Fault）的重要手段，可追溯性在功能安全相关设计的验证过程中是重点检查的内容。可追溯性在系统开发的不同阶段表现不同，如用例和需求之间，可以表现为实现关系（Realization）；用例和用例之间，可以表现为包含、扩展（Include, Extend）等关系。可追溯性的表现形式可以有多种：

基于ID的可追溯性

基于SysML/UML关系图的追溯

以及基于关系矩阵的追溯

下图是一个使用SysML/UML关系图建立追溯性的例子，在图中通过手工连接的方式把用例和需求连接起来，优点是图形比较直观：

追溯图的形式能够同时表达的追溯范围有限，如果需求和用例较多，追溯图由于图中的元素太多，就不容易使用（如，查找是否有需求的遗漏），在这种情况下使用追溯矩阵（Traceability Matrix）就更合适。追溯矩阵可以在工程的全路径的任意2个连续的环节（如，需求和用例）中间建立直观的关系矩阵。如下图所示，图的横纵坐标分别表示需求与用例，箭头则表示实现（Realization）的方向，高亮的行表示需求有遗漏的情况：

建立了双向追溯之后，需求或者设计发生了变更，就可以通过追溯判定变更的影响范围。支持baseline的SysML/UML工具，还可以基于baseline进行差分。基于baseline可以很容易的识别出需求和设计中发生了变更的部分，从发生了变更的部分出发，可以追溯到对应的上下游工程中，需要变更的内容，以确保一致性。

2.5 危害识别与分析技术（Techniques for Hazard Identification and Analysis）

常用的危害分析技术有20多种，几乎覆盖了包括了：概念，概要设计，详细设计，测试及运行在内的产品开发的各个阶段。从方法论上来说，危害分析技术可以分为2大类：内推法（Inductive）和外推法（Deductive）：

内推法从系统中某个组件的故障出发，自下而上的推导，在整车的级别上产生的影响是否违反功能安全目标

外推法从违反功能安全目标的失效开始，自上而下的推导可能产生这个影响的组件故障

在功能安全概念阶段，危害分析的主要目的是保障完整及正确的派生功能安全需求。在ISO 26262:2018, Part 3中提到了3种危害分析方法：FMEA (Failure Mode and Effects Analysis)，HAZOP (Hazard and Operability Analysis) 和FTA (Fault Tree Analysis)。这三种分析方法的分类见下图：

以下介绍一下FMEA的基本分析技巧。FMEA用于分析系统中的关键组件的失效是否会影响功能安全目标，影响功能安全目标的失效是否设计了安全机制，相应的安全机制可以作为功能安全需求而记载到对应的文档中。FMEA的主要成果物为FMEA Worksheet，下图是来自于Ford的FMEA Handbook，图中给出了FMEA的主要的分析过程：

FMEA的输入有多种，其中比较重要的是功能块图（Functional Block Diagram）和参数图（Parameter Diagram）。功能块图简化了系统设计和支持的服务，在功能安全概念阶段可以帮助快速建立对产品的理解。功能块图展示了子系统之间的关系和接口，同时也指示了系统所必须提供的功能。下图给出了系统的功能块图的例子：

对于功能块图中的任一功能，对其进行危害分析时，需要明确该功能的输入信号，运行环境，配置信息及期望的和错误的输出。把这些信息整合，可以如下图所示的参数图（Parameter Diagram）：

通过对这些参数的分析，可以得出导致某个功能出现故障的基本原因。在后续的分析过程中，针对故障原因，设计合理的检测和消除机制，可以有效的提升系统的安全性。

3 总结

本文从ISO 26262:2018，Part 3中的基本概念出发，介绍了该部分涉及到重要概念及开发过程中需要用到的基本技术。在ISO 26262流程中，概念阶段（包括功能安全概念和技术安全概念）是最重要的阶段，这个阶段出现的任何纰漏，都会影响后续的功能安全开发活动。由于ISO 26262采用的是V模型，概念阶段变更引起的工作量会十分巨大。本文希望通过一些重要概念的解释和实用技术的说明，理清功能安全概念的过程，帮助功能安全开发人员，实现正确的功能安全概念。