目录
-
功能安全的定义:
- ISO26262避免的风险: 汽车电子/电气系统的失效行为所产生的潜在风险
- 安全要求的源头和规范:Automotive Safety Integrity Level。 在达到要求的情况下,应尽量避免过度验证和重复工作; 安全范畴内的竞争压力
- 随机失效: 硬件安全完整性要求(例如:PMHF硬件随机失效率, Probabilistic Metric for random Hardware Failures, SPFM单点失效率Single Point Falut Metric, LFM潜在故障指标Latent Fault Metric)
- 系统失效:系统性安全完整性要求(安全生命周期…)
- 功能安全的覆盖度:
- 产品的整个生命周期: 研发,生产,运行/维护,报废回收
- 覆盖所有责任方:供应商,车厂,用户
- 功能安全的目的:使系统安全工作(为系统安全工作提供担保)
- 功能安全的覆盖范围:安全
- 功能安全可能加强,也可能减弱:可靠性,可用性,可维护性
- 功能安全应该是可重复的,可验证的,植入的,从最开始阶段安全设计的
- 功能安全不仅仅是技术问题。技术系统越复杂,必须达到的管理要求越严格:
- 管理架构+安全文化==》安全管理。安全管理+安全技术==》适宜的安全性。 在此基础上进行安全性验证,得到可接受的安全
- ISO26262在多个方面对企业带来影响:采购,工程技术,商业关系,市场销售,IT支持,法律
- ISO26262避免的风险: 汽车电子/电气系统的失效行为所产生的潜在风险
-
汽车功能安全的发展背景:
- 是IEC61508通用原则下对汽车行业的功能安全标准
- 欧洲主要制造商已经有功能安全的运用方面有十年以上的经验
- 国际OEM巨头已经全面导入ISO26262标准的产品
- 欧洲政府已经将ISO26262标准正式纳入法规
- ISO26262将成为与ISO/TS16949相类似的汽车行业核心标准
-
ISO26262法规介绍
- 适用范围: 与车辆安全相关的系统;包含一个或多个电子电气系统并且安装在重量不找过3.5吨的乘用车上。关注在与安全相关的电子电气系统,出现故障可能引起的危险灾害
- 不适用特殊用途车辆上的电子电气系统,例如残疾人专用车辆
- 2011年11月以前投产使用的产品,系统或零部件不受ISO26262法规要求。但是此时间之后,上述产品如果进行深度开发或改进,则改动设计的部分需要满足ISO26262的要求
- 应用方向:安全气囊(Airbag),发动机管理系统(EMS),电池管理系统(BMS),电子控制单元(ECU),汽车防抱死制动系统(ABS),整车控制系统硬件及软件(EV/HEV),制动辅助系统(BAS),胎压监测系统(TPMS),车身稳定控制系统(ESP),电子刹车力分配系统(EBD),自适应照明系统(AFS)等等
-
安全生命周期
- 概念阶段: 项目定义==>安全生命周期初始化==》危害分析和风险评估==》功能安全概念 到研发阶段
- 研发阶段: 产品系统级开发(硬件+软件)==》生产计划,运行计划 到生产阶段
- 生产阶段: 批量生产,运行服务及报废
-
功能安全管理的重点:
- 建立,培养和维护企业的安全文化
- 定义安全管理人员的角色和职责
- 确保执行安全管理人员的能力和资格
- 符合标准的质量管理体系:ISO/TS16949, ISO9001
-
项目定义:
- 安全生命周期内的首要任务就是安全相关产品的项目定义。即对开发项目的具体描述和充分理解。具体考虑如下内容:
- 设计的用途
- 功能要求
- 工作环境和使用条件
- 相关国家,国际法规要求
- 产品的已知危害
- 与其他系统或不见的兼容性
- 安全生命周期内的首要任务就是安全相关产品的项目定义。即对开发项目的具体描述和充分理解。具体考虑如下内容:
-
安全生命周期的初始化(Initiation of the safety lifecycle)
- 基于产品的项目定义,需要明确是否属于:
- 新项目开发
- 或者现有项目上的改进。如果是现有项目上的改进,则需要进行改动的影响分析,依据分析结果将生命周期进行适当调整
- 基于产品的项目定义,需要明确是否属于:
-
为实现安全目标,设定的具体的功能安全要求:
- 能进行故障检测,降低失效的可能性
- 使潜在危险状态过渡到安全状态
- 故障容错机制(不会违背安全目标,保持车辆在一个安全状态下)
- 能够进行故障报警(如发动机故障指示灯,ABS故障指示灯)
- 不同的功能同时发出多个执行请求时,选择最合适的优判逻辑(软件执行)
- 举例:在正常驾驶车辆过程中,安全气囊意外弹出,造成车辆失控(安全性等级为D级)
- 安全目标:除非车辆发生碰撞,否则在任何情况下,安全气囊不能意外弹出
- 功能安全概念:设计一个冗余功能,用来检测车辆是否发生碰撞
- 技术安全概念:设定两个不同轴向的独立加速传感器和两个对应的独立点火电路。如果发生碰撞,2个点火电路闭合,引爆内部雷管,是安全气囊弹出
-
危险分析及风险评估(HARA):
- 整体流程可自上而下分为: 3-7 危险分析和风险评估==》3-7 安全目标&安全等级==》3-8 功能安全概念(具体功能安全要求)==》4-6 技术安全概念(具体技术安全要求)==》包括5-6 硬件安全要求(具体硬件安全要求)和6-6软件安全要求(具体软件安全要求)
- 危害分析和风险评估:通过对可能发生的危险事件进行分析,评估事件可能造成伤害程度,依据判断的结果,我们需要:
- 设定项目的安全目标(Safety Goal),以预防危害发生或降低危害到可接受范围内
- 确定车辆安全完整性等级(ASIL)
- 车辆安全性等级ASIL:
- ISO26262根据安全风险程度,对系统或系统部件确定划分由A到D的安全需求等级
- HARA==》Safety Goal==》QM, ASIL-A~ASIL-D
- ASIL由三部分决定:S&E&C
- 严重性Severity: 潜在伤害的严重程度
- 分为S0~S3四个等级:
S0
S1
S2
S3
无伤害
轻微和中度伤害
严重和危及生命的伤害
(存活概率较高)
危及生命的伤害(存活概率不确定)
致命的伤害
- 所有参与道路交通者均需要被考虑进去(例如驾驶员,乘客,行人等)
- 如果是S0等级,则无需再进行风险评估
- 分为S0~S3四个等级:
- 暴露的可能性probabililty of Exposure: 暴露于危险中的可能性
- 考虑具体的工作环境和使用条件
- 由以下方面决定: (设定条件下)事件发生的频率或者(设定条件下)使用持续的时间
- 分为5个等级(E0~E4)
暴露于危险中的可能性 等级
E0
E1
E2
E3
E4
描述
几乎不会发生
非常低的概率
低概率
中等概率
高概率
频率定义
绝大部分车辆不会遇到
对大部分驾驶员来说,
发生的概率少于1年1次
对大部分驾驶员来说,
一年发生几次
对普通驾驶员来说,
可能一个月发生1次或更多
对于每次驾驶都有可能发生
时间定义
-
-
<1%的平均使用时间
1%-10% 的平均使用时间
>10%的平均使用时间
- 可控性Controllability: 对危险时间的控制能力,即躲避危险的可能性
- 评估驾驶员对车辆的控制能力,和处于危险的人员对危险事件的躲避能力
- 分为4个等级(C0~C3)
等级
C0
C1
C2
C3
描述
总体可控
简单可控
一般可控
很难控制或不可控
定义
总的来说,所有正常人都可以控制
>99%的驾驶员和交通参与者
都能避免伤害
通常,>90%的驾驶员和交通参与者
都能避免伤害
通常,<90%的驾驶员和交通参与者
能避免伤害
- 每一个危险事件,都应确定对应的安全目标和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
- 案例分析: 近光前照灯
- 系统功能: 天黑时,作为道路照明使用
- 受影响的部件:开关,光线传感器,微处理单元,车辆前大灯,车载通信网络,。。。
- 故障识别:设想可能会出现哪些故障。 车灯无法点亮?灯光太暗?灯光太亮?车灯一直闪烁?车灯故障自己熄灭?车灯故障自己点亮? 等等。识别故障类型:系统硬件失效?软件失效?可预见的误操作?
- 危险条件定义,即哪些条件下会比较危险? 考虑驾驶状况(正常行驶,停车,倒车等),车辆的动态(高速或低速行驶),交通状况(堵车,穿过十字路口,乡村道路,高速公路等),环境条件(夜间,高温天气,下雨,冰雪路面等),乘员状态,其他因素
- 危险事件分析:分为不同场景。
- 场景1:在夜间乡村公路上,车灯错误的自己熄灭==》可能偏航,撞向路边的树木
- 场景2:在夜间乡村公路上,车灯错误的自己熄灭,迎面有车辆驶来==》自己的车辆可能不被发现,有正面碰撞的可能。==》S3,E3,C2==》ASIL-B
- 场景3:在夜间乡村公路上,灯光不停闪烁。==》驾驶视野受限制,可能引起驾驶员情绪不稳定。
- 等等更多场景
- 系统功能: 天黑时,作为道路照明使用
- 严重性Severity: 潜在伤害的严重程度
-
产品开发--硬件架构指标评估--随机失效
ASIL-B
ASIL-C
ASIL-D
单点故障指标SPFM
≥ 90%
≥ 97%
≥ 99%
潜在故障指标
≥ 60%
≥ 80%
≥ 90%
- 随机失效的评估:
- 硬件架构指标评估:
- 对硬件随机失效而违反安全目标的评估(PMHF)
- 系统失效分解:为了确保更好地符合安全目标,可以将ASIL等级进行适当分解,以提高项目实际开发时的可靠性和可操作性。利用冗余方案保障安全要求,潜在地降低ASIL等级。ASIL-D可以分为ASIL-C+ASIL-A;或者两个ASIL-B,或者ASIL-D+QM
- ASIL分解不能影响随即硬件失效的故障指标,不能违背设定的安全目标
- ASIL分解关注于系统性的失效
- ASIL分解可用于项目或系统在功能,设计,软件和硬件方面的安全要求
- ASIL分解后,执行原设计功能对应的部件,必须保持充分的独立性