汽车功能安全(ISO 26262)系列: 概念阶段开发

本篇属于汽车功能安全专题系列第03篇内容，我们接着聊功能安全概念开发阶段剩余内容。

ISO 26262 基于V模型，汽车功能安全开发活动始于概念阶段，该阶段主要包含以下内容:

相关项定义(Item Definition)，即定义研究对象

危害分析和风险评估(HARA)，即导出安全目标及ASIL等级

功能安全方案开发(FSC)，即形成系统化概念阶段工作方案输出

在上一篇文章''02 - 汽车功能安全系列之概念阶段开发 - Item Definition & HARA''(我是链接)中，我们聊到了前两部分内容，定义了功能安全研究的对象，即相关项，通过HARA过程，对相关项的功能进行系统级别安全分析，导出了危害事件并量化其风险(ASIL)，最终得到功能安全目标(SG)及其ASIL等级，作为整个功能安全研究最初的安全需求。

今天主要聊聊功能安全概念阶段第三个部分内容(强烈建议先看前面几篇文章)，具体包括:

什么是功能安全需求(FSR)

什么是功能安全方案(FSC)

怎么从安全目标(SG)得到功能安全需求(FSR)

FSR分配至系统架构

01

什么是FSR

功能安全需求(Functional Safety Requirements, FSR)是我们在概念阶段最常听到的概念之一，那什么是FSR呢？

功能安全目标(SG)属于基于车辆或系统级别的安全需求，过于抽象，我们需要将其进行细化，得到为满足安全目标，基于组件级别的相对比较具体的，但依旧还是基于功能层面的逻辑功能需求，这个就是FSR。

大家可能好奇，为什么非要搞得这么麻烦，直接细化到技术层面，信号层面不好吗?

是的，不好！一方面，研究分析工作需要循序渐进，一口吃不成大胖子，对于简单或者非常熟悉的研究对象，在大牛加持下可能可以直接从安全目标导出技术层面的安全需求，但对于大部分系统或者大部分工程师而言，这个很难做到，很容易出现错误或缺失。另外一方面，没有中间工作产物，功能安全评审也过不了。

那么我们应该从哪些方面去定义组件层面的功能安全需求或者功能安全需求应该解决哪些问题呢？根据ISO 26262-3-2018，功能安全需求应该针对以下几个方面，提出相应功能级别的解决方案，作为FSR: 

故障预防

故障探测，控制故障或功能异常

过渡到安全状态

容错机制

发生错误时功能的降级及与驾驶员预警的相互配合

将风险暴露时间减少到可接受的持续时间所必需的驾驶员预警

驾驶员预警，以增加驾驶员对车辆的可控性

车辆级别时间相关要求，即故障容错时间间隔，故障处理时间间隔，和

仲裁逻辑，从不同功能同时生成的多种请求中选择最合适的控制请求。

如何理解呢？通俗的讲，FSR无非就是基于以下两个角度定义安全需求: 

事前预防: 从设计的角度出发，为尽可能避免系统中软件和硬件相关的失效，系统中的组件应该实现或具备哪些功能。

事后补救: 如果系统还是发生了失效，及时探测，显示，控制故障。尽早给驾驶员警示故障，让驾驶员有效干预，或控制车辆系统进入一个安全状态，防止或减轻伤害产生。

此外，针对FSR，还需要注意以下几点:  

1

FSR本质是需求，一般是甲方(主机厂)对供应商提出的安全要求，只考虑为满足安全目标及ASIL等级，系统应该怎么正常工作，不涉及具体的技术实现方式。

2

针对每个SG，应该至少导出一个FSR。

3

FSR应该继承对应安全目标的ASIL等级。如果存在ASIL等级分解，则需要遵循ISO 26262-9:2018中独立性(Independence)要求。(注意独立性和免于干扰(FFI)的区别)

4

如果FSR涉及事后补救措施，则该FSR需要定义相应的安全状态，故障容错时间间隔(如果安全状态需要过渡，还需定义紧急运行时间间隔)。很多朋友搞不清楚到底这些东西属不属于安全需求。

5

FSR需要分配至系统架构，并作为FSC的组成部分，这个我们后续详细介绍。  

例如，功能安全需求示例: 制动踏板开度必须正确反映驾驶员制动意图(ASIL D)。至于应该采用什么传感器，具体怎么反应意图都不是功能层面考虑的问题。

02

什么是FSC

Functional Safety Concept(FSC)一般翻译为功能安全方案或概念，个人觉得功能安全方案更合理些，FSC本质上是概念阶段所有开发工作进行系统化汇总后形成的工作输出产物。   ISO 26262 对FSC定义比较模糊，即为了满足安全目标，FSC包括安全措施(含安全机制)。   那到底什么是安全措施(Safety measure)呢? 它和安全机制(Safety mechanism)有什么区别，这里给朋友们做个辨析: 

1

安全措施: 事前预防+事后补救，较为广泛，一切用以避免或控制系统性失效、随机硬件失效的技术解决方案的统称。

2

安全机制: 事后补救部分，只是安全措施的一部分，针对系统功能出现异常后，为探测，显示，控制故障的所采取的措施。一般涉及具体技术手段，在概念阶段不做具体要求，在系统阶段进行定义。

所以理论上讲，只要是为保证相关项功能安全，所有在功能层面采取的解决方案都属于功能安全方案。一般来讲，一个完整的FSC应该包含以下主要内容:  

其中，安全状态主要包括: 关闭功能，功能降级，安全运行模式，Limp Home等Fail to safe策略，目前Fail to operational，如冗余运行等策略相对较少。

系统一旦违反安全目标，安全机制必须在容错时间间隔(FTTI)将系统转移到安全状态。

这里简单说说怎么确定故障容错时间间隔(FTTI): 

一般可以根据安全目标所对应的代表性危害事件(一般是ASIL等级最高的危害事件)，通过对应运行场景定量或定性评估得到，包括历史数据，仿真计算，实际测试等。

在实际操作中，如果难以计算确定，可以根据经验对其进行预设，然后对代表性危害事件进行实车运行场景模拟，最后根据测试数据和安全确认指标(Validation criteria)确定假设合理性。

对于ASIL等级较高的安全需求，理论上都应该进行车辆测试确认。

最后聊聊，FSR和FSC形式和书写工具问题: 

首先，FSR一般都是直接包含在FSC之中，多采用需求管理或者文本工具，如Doors，Word进行书写和管理，方便进行版本管理和评审。

其次，FSC内容没有统一的结构要求，将所需内容合理组织形成输出结果且保证分析结果可追溯性即可。

03

怎么从SG得到FSR

和安全目标(SG)导出，即HARA过程相比，从安全目标(SG)到功能安全需求(FSR)，也需要进行安全分析，其区别在于:

安全分析的对象基于组件层次，非车辆或系统级别。

除了归纳分析法(Inductive analysis)，还可采取演绎(Deductive analysis)分析方法。

其中，FMEA(Failure Mode and Effects Analysis, 即失效模式与影响分析)和FTA(Fault Tree Analysis, 即故障树分析)是归纳和演绎最具代表性的分析方法，也是功能安全开发最常用的安全分析方法。   接下来我们简单地聊聊它们的特点和区别:  

FMEA

典型的归纳分析法: 是从多个个别的事物中获得普遍的规则。

定性分析。

自下而上，从原因到结果，即从可能的故障原因，分析可能的危害结果。

FTA

典型的演绎分析方法: 从已知的定律经过逻辑推演得到新的定律的方法。

定性和定量分析，概念和系统阶段多定性分析，硬件度量分析多定量分析。

自上而下，从结构到原因，即从危害结果或事件，分析可能导致其产生的原因。

从SG到FSR，多采用FTA分析方法进行分析，主要原因在于:

首先，FMEA在设计阶段一般指DFMEA，即Design FMEA。FMEA一般用于产品设计或工艺在真正实现之前，对其进行安全分析发现产品弱点，并优化改进。所以FMEA意味着事件发生之前的行为，尽可能避免危害产生，只包括事前预防，这一点和功能安全安全机制需求完全不同，事后补救是功能安全重要的保证安全的措施。

其次，FTA自上而下，从结果到原因的分析方法和从SG到FSR的导出方向一致，操作更为便捷，更容易完整地识别故障原因和影响。

那接下来我们一起看看FTA操作步骤: 步骤一: 确定分析边界，包括分析对象，范围，抽象级别。 步骤二: 选择分析的故障，即顶部事件，通常将违反的安全目标(SG)作为FTA顶层事件。 步骤三: 根据顶层事件，确认直接，必要和充分导致故障产生的原因，建立故障树，直至分析的最低抽象级别，即底层基本事件(对于FSR，一般为组件级别，如传感器，执行器，控制单元等) 。 步骤四: 根据底层基本事件，采取安全措施以消除相关故障路径，制定相应的FSR。

(感兴趣的朋友可以私信我，我再考虑后续是否有必要出一篇安全分析文章)

04

FSR分配至系统架构

根据ISO 26262-3-2018要求，FSR必须分配至系统架构，作为FSC的重要组成部分。其主要目的在于:  

将不同安全目标对应的安全需求及ASIL落实到架构中具体的软件或硬件组件当中去，进而确定不同组件开发对应的所有安全需求及最高ASIL等级要求，以便于后续系统，软件和硬件的进一步开发。

架构作为需求和具体软/硬件实现之间的桥梁，是基于模型的系统工程开发(MBSE)重要内容，能有效改善基于文本或文档开发的弊端，实现模型统一的管理，维护，及需求和测试的可追溯性，可验证性。

一般来讲，系统架构一般采用通用化建模语言UML或SysML在相关架构开发软件，如Enterprise Architect， Cameo等，进行开发，作为功能安全概念开发的输入内容。但可惜的是，目前大部分车企都没有完整的系统架构或多基于PowerPoint等形式的简单架构描述。这就导致一方面安全分析没有办法依据架构开展，另一方面，没有办法将安全需求分配至系统架构。   架构是门艺术，是当前软件定义汽车大背景下，解决系统及软件复杂度一大利器，我后续单独给朋友们聊聊架构这个话题。  

审核编辑 ：李倩