ISO26262 功能安全(1)--概览学习_功能安全 生产阶段主要包括

目录

功能安全的定义

汽车功能安全的发展背景

ISO26262法规介绍

安全生命周期

功能安全管理

项目定义

安全生命周期的初始化

为实现安全目标，设定的具体的功能安全要求

危险分析及风险评估（HARA）

产品开发--硬件架构指标评估--随机失效

1. 功能安全的定义：

   1. ISO26262避免的风险： 汽车电子/电气系统的失效行为所产生的潜在风险
      1. 安全要求的源头和规范：Automotive Safety Integrity Level。 在达到要求的情况下，应尽量避免过度验证和重复工作； 安全范畴内的竞争压力
      2. 随机失效： 硬件安全完整性要求（例如：PMHF硬件随机失效率， Probabilistic Metric for random Hardware Failures, SPFM单点失效率Single Point Falut Metric, LFM潜在故障指标Latent Fault Metric）
      3. 系统失效：系统性安全完整性要求（安全生命周期…）
   2. 功能安全的覆盖度：
      1. 产品的整个生命周期： 研发，生产，运行/维护，报废回收
      2. 覆盖所有责任方：供应商，车厂，用户
   3. 功能安全的目的：使系统安全工作（为系统安全工作提供担保）
   4. 功能安全的覆盖范围：安全
   5. 功能安全可能加强，也可能减弱：可靠性，可用性，可维护性
   6. 功能安全应该是可重复的，可验证的，植入的，从最开始阶段安全设计的
   7. 功能安全不仅仅是技术问题。技术系统越复杂，必须达到的管理要求越严格：
      1. 管理架构+安全文化==》安全管理。安全管理+安全技术==》适宜的安全性。 在此基础上进行安全性验证，得到可接受的安全
   8. ISO26262在多个方面对企业带来影响：采购，工程技术，商业关系，市场销售，IT支持，法律

2. 汽车功能安全的发展背景：

   1. 是IEC61508通用原则下对汽车行业的功能安全标准
   2. 欧洲主要制造商已经有功能安全的运用方面有十年以上的经验
   3. 国际OEM巨头已经全面导入ISO26262标准的产品
   4. 欧洲政府已经将ISO26262标准正式纳入法规
   5. ISO26262将成为与ISO/TS16949相类似的汽车行业核心标准

3. ISO26262法规介绍

   1. 适用范围: 与车辆安全相关的系统；包含一个或多个电子电气系统并且安装在重量不找过3.5吨的乘用车上。关注在与安全相关的电子电气系统，出现故障可能引起的危险灾害
   2. 不适用特殊用途车辆上的电子电气系统，例如残疾人专用车辆
   3. 2011年11月以前投产使用的产品，系统或零部件不受ISO26262法规要求。但是此时间之后，上述产品如果进行深度开发或改进，则改动设计的部分需要满足ISO26262的要求
   4. 应用方向：安全气囊（Airbag）,发动机管理系统（EMS），电池管理系统（BMS），电子控制单元（ECU），汽车防抱死制动系统（ABS），整车控制系统硬件及软件（EV/HEV），制动辅助系统（BAS），胎压监测系统（TPMS），车身稳定控制系统（ESP），电子刹车力分配系统（EBD），自适应照明系统（AFS）等等

4. 安全生命周期

   1. 概念阶段： 项目定义==>安全生命周期初始化==》危害分析和风险评估==》功能安全概念 到研发阶段
   2. 研发阶段： 产品系统级开发（硬件+软件）==》生产计划，运行计划  到生产阶段
   3. 生产阶段： 批量生产，运行服务及报废

5. 功能安全管理的重点：

   1. 建立，培养和维护企业的安全文化
   2. 定义安全管理人员的角色和职责
   3. 确保执行安全管理人员的能力和资格
   4. 符合标准的质量管理体系：ISO/TS16949, ISO9001

6. 项目定义：

   1. 安全生命周期内的首要任务就是安全相关产品的项目定义。即对开发项目的具体描述和充分理解。具体考虑如下内容：
      1. 设计的用途
      2. 功能要求
      3. 工作环境和使用条件
      4. 相关国家，国际法规要求
      5. 产品的已知危害
      6. 与其他系统或不见的兼容性

7. 安全生命周期的初始化（Initiation of the safety lifecycle）

   1. 基于产品的项目定义，需要明确是否属于：
      1. 新项目开发
      2. 或者现有项目上的改进。如果是现有项目上的改进，则需要进行改动的影响分析，依据分析结果将生命周期进行适当调整

8. 为实现安全目标，设定的具体的功能安全要求：

   1. 能进行故障检测，降低失效的可能性
   2. 使潜在危险状态过渡到安全状态
   3. 故障容错机制（不会违背安全目标，保持车辆在一个安全状态下）
   4. 能够进行故障报警（如发动机故障指示灯，ABS故障指示灯）
   5. 不同的功能同时发出多个执行请求时，选择最合适的优判逻辑（软件执行）
   6. 举例：在正常驾驶车辆过程中，安全气囊意外弹出，造成车辆失控（安全性等级为D级）
      1. 安全目标：除非车辆发生碰撞，否则在任何情况下，安全气囊不能意外弹出
      2. 功能安全概念：设计一个冗余功能，用来检测车辆是否发生碰撞
      3. 技术安全概念：设定两个不同轴向的独立加速传感器和两个对应的独立点火电路。如果发生碰撞，2个点火电路闭合，引爆内部雷管，是安全气囊弹出

9. 危险分析及风险评估（HARA）：

   1. 整体流程可自上而下分为： 3-7 危险分析和风险评估==》3-7 安全目标&安全等级==》3-8 功能安全概念（具体功能安全要求）==》4-6 技术安全概念（具体技术安全要求）==》包括5-6 硬件安全要求（具体硬件安全要求）和6-6软件安全要求（具体软件安全要求）
   2. 危害分析和风险评估：通过对可能发生的危险事件进行分析，评估事件可能造成伤害程度，依据判断的结果，我们需要：
      1. 设定项目的安全目标（Safety Goal），以预防危害发生或降低危害到可接受范围内
      2. 确定车辆安全完整性等级（ASIL）
   3. 车辆安全性等级ASIL：
      1. ISO26262根据安全风险程度，对系统或系统部件确定划分由A到D的安全需求等级
      2. HARA==》Safety Goal==》QM, ASIL-A~ASIL-D
      3. ASIL由三部分决定：S&E&C
         1. 严重性Severity: 潜在伤害的严重程度
            1. 分为S0~S3四个等级：

               S0	S1	S2	S3
               无伤害	轻微和中度伤害	严重和危及生命的伤害 （存活概率较高）	危及生命的伤害（存活概率不确定） 致命的伤害

            2. 所有参与道路交通者均需要被考虑进去（例如驾驶员，乘客，行人等）
            3. 如果是S0等级，则无需再进行风险评估
         2. 暴露的可能性probabililty of Exposure: 暴露于危险中的可能性
            1. 考虑具体的工作环境和使用条件
            2. 由以下方面决定： （设定条件下）事件发生的频率或者（设定条件下）使用持续的时间
            3. 分为5个等级（E0~E4）

               暴露于危险中的可能性

               等级	E0	E1	E2	E3	E4
               描述	几乎不会发生	非常低的概率	低概率	中等概率	高概率
               频率定义	绝大部分车辆不会遇到	对大部分驾驶员来说， 发生的概率少于1年1次	对大部分驾驶员来说， 一年发生几次	对普通驾驶员来说， 可能一个月发生1次或更多	对于每次驾驶都有可能发生
               时间定义	-	-	<1%的平均使用时间	1%-10% 的平均使用时间	>10%的平均使用时间

         3. 可控性Controllability: 对危险时间的控制能力，即躲避危险的可能性
            1. 评估驾驶员对车辆的控制能力，和处于危险的人员对危险事件的躲避能力
            2. 分为4个等级（C0~C3）

               等级	C0	C1	C2	C3
               描述	总体可控	简单可控	一般可控	很难控制或不可控
               定义	总的来说，所有正常人都可以控制	>99%的驾驶员和交通参与者 都能避免伤害	通常，>90%的驾驶员和交通参与者 都能避免伤害	通常，<90%的驾驶员和交通参与者 能避免伤害

         4. 每一个危险事件，都应确定对应的安全目标和ASIL等级

            ASIL等级

            		C1	C2	C3
            S1	E1	QM	QM	QM
            	E2	QM	QM	QM
            	E3	QM	QM	A
            	E4	QM	A	B
            S2	E1	QM	QM	QM
            	E2	QM	QM	A
            	E3	QM	A	B
            	E4	A	B	C
            S3	E1	QM	QM	A
            	E2	QM	A	B
            	E3	A	B	C
            	E4	B	C	D

         5. 案例分析： 近光前照灯
            1. 系统功能： 天黑时，作为道路照明使用
               1. 受影响的部件：开关，光线传感器，微处理单元，车辆前大灯，车载通信网络，。。。
            2. 故障识别：设想可能会出现哪些故障。 车灯无法点亮？灯光太暗？灯光太亮？车灯一直闪烁？车灯故障自己熄灭？车灯故障自己点亮？ 等等。识别故障类型：系统硬件失效？软件失效？可预见的误操作？
            3. 危险条件定义，即哪些条件下会比较危险？ 考虑驾驶状况（正常行驶，停车，倒车等），车辆的动态（高速或低速行驶），交通状况（堵车，穿过十字路口，乡村道路，高速公路等），环境条件（夜间，高温天气，下雨，冰雪路面等），乘员状态，其他因素
            4. 危险事件分析：分为不同场景。
               1. 场景1：在夜间乡村公路上，车灯错误的自己熄灭==》可能偏航，撞向路边的树木
               2. 场景2：在夜间乡村公路上，车灯错误的自己熄灭，迎面有车辆驶来==》自己的车辆可能不被发现，有正面碰撞的可能。==》S3，E3,C2==》ASIL-B
               3. 场景3：在夜间乡村公路上，灯光不停闪烁。==》驾驶视野受限制，可能引起驾驶员情绪不稳定。
               4. 等等更多场景

10. 产品开发--硬件架构指标评估--随机失效

    	ASIL-B	ASIL-C	ASIL-D
    单点故障指标SPFM	≥ 90%	≥ 97%	≥ 99%
    潜在故障指标	≥ 60%	≥ 80%	≥ 90%

    1. 随机失效的评估：
    2. 硬件架构指标评估：
    3. 对硬件随机失效而违反安全目标的评估（PMHF）
    4. 系统失效分解：为了确保更好地符合安全目标，可以将ASIL等级进行适当分解，以提高项目实际开发时的可靠性和可操作性。利用冗余方案保障安全要求，潜在地降低ASIL等级。ASIL-D可以分为ASIL-C+ASIL-A；或者两个ASIL-B，或者ASIL-D+QM
       1. ASIL分解不能影响随即硬件失效的故障指标，不能违背设定的安全目标
       2. ASIL分解关注于系统性的失效
       3. ASIL分解可用于项目或系统在功能，设计，软件和硬件方面的安全要求
       4. ASIL分解后，执行原设计功能对应的部件，必须保持充分的独立性