整车功能安全概念阶段开发

一、功能安全定义

1. ISO 26262-2018中对功能安全的定义是：

• “Absence of unreasonable risk due to hazards caused by malfunctioning behavior of E/E systems.”
• GB/T 34590-2017中给出的对应定义为：“不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。”    

    
2. 电子电气系统功能异常表现
    汽车操作安全中的各个方面均可能成为引发人身危害的危害源，即使将危害源限制在电子电气范畴，也会包括几种可能的危害源。针对这些不同的危害源，就出现了功能安全、预期功能安全和信息安全等多种安全技术体系其中功能安全针对的危害源就是“电子电气系统功能异常表现”，具体来说，包括两种类型：系统性失效和随机硬件失效。
    

    1). 系统性失效（systematic failure）

      指以确定的方式与某个原因相关的失效，只有对设计或生产流程、操作规程、文档或其它相关因素进行变更后才可能排除这种失效。即系统性失效可理解为因设计考虑不足造成的产品功能失效
      造成系统性失效的原因可能包括:

• 系统架构设计错误‒-系统易触发或不能避免安全危害保障；‒不能足够地检测和防护安全危害。
• 零部件功能设计和制造错误‒硬件设计偏离环境、边界条件和寿命要求；‒软件设计中的架构错误以及逻辑或数据处理错误。            
• 生产装配和维修中的错误            
• 可预料到的客户操作错误、滥用或非正常使用（非恶意使用）。‒例如，误触某功能键、插座错位、同时踩刹车和油门、玩弄开关等

    2). 随机硬件失效

      随机硬件失效（random hardware failure）指在硬件要素的生命周期中，非预期发生并服从概率分布的失效。即随机硬件失效可理解为因器件本身的设计寿命到了（如：器件退化或老化）造成的产品功能失效。随机硬件失效可以认为是硬件的可靠性问题，其深层原因是由物理原因导致的，比如腐蚀、热应力、老化等。因为这些原因的随机特性，导致硬件在何时发生失效时无法预测的，但是会遵循某种概率分布（比如指数分布）。

二、概念阶段开发流程

安全需求通用架构

1. 相关项定义

    目的：将整车中的对象定义为相关项
    概要：对由多个系统结合而成的相关项进行功能要求、非功能要求、边界、接口的定义
    内容定义：
         1) 整车层面功能定义
         2) 限制条件(其他item和环境要求)：启动条件，退出条件等
         3) 法规要求
         4) 性能、可用性定义
         5) 功能框图边界
         6) 已知失效模式和危害

 2. 危害分析和风险评估

    目的：识别相关项因故障而引起的危害并对危害进行归类，制定防止危害事件发生或减轻危害程度的安全目标，以避免不合理的风险
    总则：基于相关项定义，通过区分相关项为新的开发还是现有相关项修改启动安全生命周期。对现有相关项修改的情况，进行安全相关活动的剪裁

    要求和建议：
    1）危害分析和风险评估的启动

• 基于相关项的定义进行危害分析和风险评估
• 对不含安全机制的相关项进行评估

    2）场景分析及危害识别

• 对相关项的故障行为导致一个危害事件发生时所处的运行场景及运行模式进行描述
• 能在整车层面观察到的条件或行为来定义危害
• 危害事件应由运行场景和故障行为组合确定
• 应识别危害事件的后果

    3）危害事件分类

• 对于各危害事件严重度、暴露度、可控性评估

    4）ASIL等级和安全目标确认

• 基于S/E/C的结果定义ASIL等级
• 定义安全目标

    5）验证

• 场景和危害的完备性
• 与相关项定义的符合性
• 与相关危害分析和风险评估的一致性
• 对危害事件覆盖的完备性
• 所分配的ASIL等级与相关危害事件的一致性

  2-1、HAZOP分析的关键字

        HARA&HAZOP：HAZOP有助于对车辆内物品的运行进行结构化和系统的检查，可用于识别和评估可能导致对车辆乘客造成危害的危险物品的故障行为。

2-2、场景分析

    目的：运行场景和运行模式的描述

    概要：在整车层面通过运行场景和运行模式的组合来描述危害事件

2-3、HAZOP输出+场景组合

3. 功能安全概念

    目的：从安全目标中得出功能安全要求，并将其分配给相关项的初步架构要素或外部措施
    概要：为满足安全目标，功能安全概念包括安全措施(含安全机制)，这些安全措施将在相关项的架构要素中实现，并在功能安全要求中规定

    要求和建议：
    1）功能安全要求的导出

• 由安全目标和安全状态导出，并考虑初步架构设想
• 为每个安全目标定义至少一项功能安全要求
• 功能安全要求来定义：运行时间、故障容错时间间隔、安全状态、紧急运行时间间隔、功能冗余等
• 如果在可接受的时间间隔内不能过度到安全状态，应规定紧急运行
• 将报警和降级概念定义为功能安全要求

    2）功能安全要求的分配

• 功能安全要求应分配给初步架构设想中的要素
• 功能安全概念向其他技术要素的分配
• 功能安全概念向外部降低风险措施的分配

    3）功能安全状态及降级模式

- 功能受限时，提示驾驶员；使受限功能进入安全状态

- 无法进入安全状态时，可以进入紧急操作

4. 功能安全需求

1）安全目标

   安全目标是通过危害分析和风险评估得到的，下图新版国标GB 17675中定义的电动助力转向系统安全目标

   安全目标主要属性：

• 安全目标描述：针对整车层面危害的安全要求描述
• 安全目标标识：可由整车厂功能安全组织自行定义，但应保证在不同相关项的开发中，相同安全目标的标识一致性
• ASIL等级
• 安全状态：没有不合理风险的相关项的运行模式（示例：预期运行模式、降级运行模式、关闭模式）
• 故障容错时间间隔FTTI：安全机制未激活情况下，从相关项出现故障到危害事件发生的最小时间间隔
• 运行模式：来源于相关项定义，属于场景分析结果之一

2）安全需求分解

    目的：从安全目标分解出安全需求
    概要：

• 功能安全需求（FSR）的定义中明确是由“系统”所执行的安全要求；
• 技术安全需求（TSR）的定义中明确需考虑系统架构设计，也就是说技术安全需求需分配给系统架构要素；
• 对于单系统相关项，当不考虑外部措施时，安全目标（SG）无法分解，可直接由功能安全需求（FSR）继承，即“安全目标（SG）=功能安全需求（FSR）”。

系统组相关项的安全需求分解结构示例

三、安全分析方法

1. 安全分析方法    

     以上我们可知安全目标及安全需求的分解流程，那么怎么通过分析获取得到安全目标和安全概念的确认呢？

     ISO 26262标准中给出了两种安全分析方法的分类原则：定性分析与定量分析

• 定性分析方法识别失效，但不预测失效频率。常用定性分析方法包括：FMEA、定性FTA、HAZOP等。
• 定量安全分析是对定性安全分析的补充，可预测失效频率。可用于验证硬件设计是否符合已定义的硬件架构度量评估目标值和因随机硬件失效导致违背安全目标的评估目标值。定量安全分析还要求掌握硬件要素定量失效率的知识。常用定量分析方法包括：FMEDA、定量FTA等。
   

2. 归纳分析与演绎分析
     归纳分析是由下而上的方法，旨在从系统各元器件的失效原因推导出它们的失效对系统的影响。常用归纳分析方法包括：FMEA、HAZOP。

     演绎分析方法是由上而下的方法，旨在从非预期的系统行为推导出导致该行为的可能原因。常用的演绎分析方法为FTA。