目录
A.31 ISO 26262-2018与 ISO 26262-2011在part4的文档的差异性
A.32 ISO 26262-2018与 ISO 26262-2011在part4的工作成果差异性
1.5.1 ISO 26262 中系统集成测试和安全验证流程
先导:本文是ISO 26262系列文章中的第三篇—系统开发,对系统开发的流程、分析方法、集成测试做了总结。
A 名词解释
A.1 FSC
Functional Safety Concept,功能安全概念
A.2 TSC
Technical Safety Concept,技术安全概念
A.3 TSR
Technical Safety Requirement,技术安全需求规范
A.4 SG
Safety Goal,安全目标
A.5 SM
safety mechanism,安全机制,为了达到或保持某种安全状态,由E/E功能或要素或通过其他技术来实现的技术解决方案,以检测故障或控制失效
A.6 安全确认
safety validation,检查假设是否正确,验证所有外部的其他假设的正确性,检查安全机制是否正常工作
A.7 DC
Diagnostic Coverage,诊断覆盖率,高安全性反映在硬件设计上即代表安全机制需要非常高的故障诊断覆盖率DC,DC值在ISO 26262中可分为high(99%)、medium(90%)、与low(60%)三种等级
A.8 FMEA
failure mode and effects analysis,失效模式及后果分析,一种自下而上的归纳分析方法,通过识别部件的失效模式来追溯失效影响,包含DFMEA(设计FMEA)和PFMEA(过程FMEA),FMEA适用于系统、软件、硬件层次
A.9 FMEDA
failure mode,effect and diagnostic analysis,失效模式影响及诊断分析,一种自下而上的归纳分析方法,在FMEA上对随机硬件失效率的计算,FMEDA适用于硬件层次,考虑独立的故障,工具相对简单
A.10 FTA
fault tree analysis,故障树分析,一种自上而下的演绎分析方法,通过危害事件来追溯失效原因,同时可反向计算顶部事件的失效率,FTA适用于系统、软件、硬件层次,考虑多个故障,需要专业的工具
A.11 DFA
dependent failure analysis,分析不同功能或设计中的独立性,识别从属故障,找出系统中的共因以及级联失效,DFA适用于系统、软件、硬件层次
A.12 HIL
Hardware-in-the-Loop Testing,硬件在环测试,它将实际的硬件(如ECU、传感器、执行器等)与模拟器件(如模型、仿真器等)通过接口连接起来,模拟实际的操作环境,通过对实时运行的系统进行测试和评估,以确保汽车电子控制系统的性能和稳定性。
A.13 严重度(S)
指某一给定失效模式最严重的影响后果的级别。严重度是单一的FMEA范围内的相对定级结果,分级1-10级,S的降低只有通过改变设计
A.14 频度(O)
指某一特定的失效起因/机理在设计寿命内出现的可能性,分级1-10级,通过设计更改来预防或控制失效模式的起因/机理是可能影响频度数降低的唯一途径
A.15 探测度(D)
指与设计控制中所列的最佳探测控制相关联的定级数。探测度是一个在某一FMEA范围内的相对级别。分级1-10级,为了获得较低的探测度数定级,通常计划的设计控制(如:预防、确认和/或验证等活动)必须予以不断地改进
A.16 风险顺序数(RPN)
指严重度数(S)、频度数(O)及探测度数(D)三项数字之乘积。RPN值在1—1000范围内,RPN越低越好
RPN≥100和/或严重度≧8的项目,必须制定纠正/预防措施,并努力减小该值
应首先针对高严重度、高RPN值和小组指定的其它项目进行预防/纠正措施的工程评价。任何建议措施的意图都是要依以下顺序降低其风险级别:严重度、频度、探测度
A.17 Fault
故障,引起元素或相关项失效的非正常条件
A.18 Error
错误,计算、观察、测量的值或条件与真实的、指定的、理论的正确值或条件之间的差异。
A.19 Failure
失效,元素或者相关项执行所要求功能能力的终止。
fault、error、failure三者关系举例:
A.20 HSI
hardware-software interface,软硬件接口
A.21 FTTI
fault tolerant time interval,故障容错时间间隔,是指在安全机制未被激活的情况下,从相关项内部故障发生到可能发生危害事件的最短时间间隔
eg.制动失效开始到汽车发生碰撞的时间。
eg.电池充电过程中发生过流故障,到BMS检测到过流故障并且将电池置入安全状态(切断继电器,停止充电)的时间。
A.22 FDTI
Fault detection time interval ,故障检测时间间隔,是指从故障发生到故障被识别的时间
eg.制动失效,到仪表点亮故障指示灯
A.23 FHTI
Fault handling time interval ,故障处理时间间隔,FHTI=FDTI+FRTI
A.24 FRTI
Fault reaction time interval ,故障反应时间间隔,是指从故障被识别到安全状态或紧急运行模式的时间
eg.系统检测到制动失效到安全停车
A.25 DTTI
Diagnostic test time interval,诊断测试时间间隔,是指安全机制进行在线诊断测试的时间间隔,包含诊断测试的时间
eg.制动系统每10ms进行一次在线诊断
A.26 EOTI
Emergency operation time interval,紧急运行时间间隔,是指如果识别到失效后,无法直接进入安全状态,则需要通过紧急运行模式来过渡,紧急运行开始到安全状态的时间称为紧急运行时间间隔
eg.识别到制动失效后,车辆进入跛行模式,EOTI则是跛行模式开始到安全停车的时间。
A.27 EOTTI
Emergency operation tolerance time interval ,紧急运行容错时间间隔,是指紧急运行模式开始到可能导致的危害发生的时间
A.28 安全状态保持时间间隔
maximum time to repair time interval:失效发生进入安全状态,到保持到维修完成的最大时间间隔。
A.29 多点故障探测时间间隔
multiple-point fault detection time interval,在导致一个多点失效前,将多点故障探测出来的时间间隔
A.30 图示
A.31 ISO 26262-2018与 ISO 26262-2011在part4的文档的差异性
序号 | part | 2018 | 2011 | 备注 |
1 | 4:产品开发在系统层面 | “项目计划”、“安全计划”、“相关项集成和测试计划”、“验证计划”、“功能安全评估计划”移动合并到2-6里 | 4-5 工作成功包括:“项目计划”、“安全计划”、“相关项集成和测试计划”、“验证计划”、“功能安全评估计划” | 移动 |
2 | 将2011:4-6和2011:4-7合并为2018:4-6“技术安全概念” | 4-6:“技术安全要求的定义” 4-7:“系统设计” | 合并 | |
3 | “确认计划”位于2018:2-6“依赖于项目的安全管理” | “确认计划”位于2011:4-9“安全确认” | 移动 |
A.32 ISO 26262-2018与 ISO 26262-2011在part4的工作成果差异性
ISO 26262-2018 | ISO 26262-2011 | 分析 | ||||
part4:产品开发在系统层面 | part4:产品开发在系统层面 | |||||
章节 | 名称 | 具体内容 | 章节 | 名称 | 具体内容 | |
4-5 | 系统级产品开发概览 | / | 4-5 | 启动系统层面产品开发 | 5.5.1项目计划 5.5.2安全计划 5.5.3相关项集成和测试计划 5.5.4确认计划 5.5.5功能安全评估计划 | 删除旧版工作成果 |
4-6 | 技术安全概念 | / | 4-6 | 技术安全要求的定义 | 6.5.2系统验证报告 | ①旧版第6,7章内容合并到第6章 ②删除旧版3项工作成果 ③新增1项工作成果 |
/ | 6.5.3确认计划 | |||||
6.5.6系统架构设计,软硬件接口规范、生产、运行、服务和报废的需求规范和技术安全概念的验证报告 | 4-7 | 系统设计 | 7.5.5系统验证报告 | |||
4-7 | 系统与相关项的集成与测试 | 无 | 4-8 | 相关项集成和测试 | 8.5.1相关项集成和测试计划 | 删除旧版的集成和测试计划成果 |
4-8 | 安全确认 | 8.5.1包括安全确认环境描述的安全确认规范 | 4-9 | 安全确认 | 9.5.1确认计划 | ①旧版第9、10章内容合并到新版第8章 ②删除旧版第11章 ③删除旧版确认计划 ④新版新增1项确认规范成果 |
9.5.2确认报告 | ||||||
8.5.2安全确认报告 | 4-10 | 功能安全评估 | 10.5.1功能安全评估报告 | |||
/ | 4-11 | 生产发布 | 11.5.1生产发布报告 |
1 系统层开发
1.1 需要了解的要点
①系统级开发的主要流程
②技术安全需求
③系统的设计及分析方法
④集成与测试
1.2 系统级开发的主要流程
1.2.1 系统开发模型
1.2.2 系统开发示例
1.2.3 ISO 26262 中系统开发流程
●安全分析报告:针对ASIL C和ASIL D,必须要FTA、FMEA,具体见系统分析方法
●若在系统阶段实施ASIL分解,则还需要DFA,来证明分解后的系统满足独立性要求
1.3 技术安全需求TSR
目的 | ①制定技术安全需求,验证需求 ②将安全概念,变为技术实现 ③考虑系统的实现方法,从输入到逻辑到输出整个逻辑链 ④一般为OEM和supplier的接口 ⑤OEM创建功能安全概念,supplier通过技术手段实现 | ||
设计思路 | ①TSR根据功能安全概念、相关项的初步架构设想来确定,需要考虑: —外部接口(如通讯、用户接口) —限制条件(如环境条件或功能限制等) —系统配置要求 ②如需要,进行ASIL分解 ③避免潜伏故障 ③考虑生产、运行、维护、报废相关的因素 ④进行需求的验证工作 | ||
安全机制 | ①应定义系统或要素对于影响实现安全目标的激励的响应,包括失效和相关的激励组合,并与每个相关运行模式及规定的系统状态进行组合 eg.ACC从制动系统接收到车辆稳定性控制功能不可用的通知,则关闭ACC功能(关闭ACC就是安全机制) ②安全状态定义:没有不合理风险的相关项的运行模式,安全状态有如预期运行模式、降级运行模式、关闭模式 eg1.EPS发生控制器失效时,系统控制助力电机处于断电状态,避免锁止转向柱或输出非预期转向助力,从而避免非预期转向或无法转向导致不合理的风险 eg2.当检测到油门踏板故障或发动机故障,则整车会降功率运行 ③注意项: —注意1:在相关项种实施SM是为了预防故障,即从导致单点失效或减少剩余失效,并防止潜在故障; —注意2:向安全状态的过渡,包括对执行器的控制要求 —注意3:FTTI,整车测试和试验能够用于确定FTTI —注意4:如果不能立即进入安全状态时的EOTI(关闭系统可以是一种紧急操作) —注意5:维持安全状态的措施(如一个依赖于电源的线控制动应用的安全机制,可以定义备用电源或储能设备的容量、启动和运行时间等) ④安全机制的具体内容总结: a)与系统自身故障相关的探测、指示和控制措施 b)涉及探测、指示和控制与本身系统有相互影响的外部设备中所发生故障的措施 c)使系统实现或维持在安全状态下的措施 d)细化和执行报警和降级概念的措施 e)防止故障潜伏的措施
|
1.4 系统的设计及分析方法
1.4.1 ASIL分解
①该分解方法位于ISO 26262-9中figure 2
②如ASIL D分解为ASIL B+ASIL B那么后面要有(D),代表从ASIL D等级做的分解,变为ASIL B(D)+ASIL B(D)
③分解方法和要点
分解原则 | ①ASIL等级来自于危害分析和风险评估; ②若多个功能安全要求分配给同一架构要素,且初步架构中无法证明这些要求是相互独立或免于干涉,则该架构要素应按最高ASIL开发; ③若相关项包括多个系统,则应根据初步架构的设想定义各个系统以及系统之间接口的功能安全要求,这些功能安全要求应分配给各个系统; ④当ASIL进行分解时,需要具有冗余性和独立性,即要分配给独立的架构要素,如果架构不独立,则冗余要求和架构要素继承初始的ASIL等级 ⑤要素共存准则: —安全相关的子要素与没有分配ASIL等级的子要素; —分配了不同ASIL等级的安全相关子要素。 eg1.冗余通路: 分解前: 分解后: eg2.分析安全目标和相应功能链路,改变设计 分解前: 分解后:单独加个ASIC来实现安全目标 |
DFA | 系统进行ASIL分解后,必须进行DFA分析,找出系统中的共因以及级联失效 ①级联失效定义:任一失效,系统都会失效 ②共因失效定义:失效后,冗余措施不起作用 ③分析角度: ●系统分析:系统架构、系统边界、系统人员、系统环境、系统开发生产维护等过程 ●硬件分析:硬件架构、硬件选型、硬件人员、供电电源 ●软件分析:CPU共享资源、软件架构、软件人员、软件工具、算法方案等 |
1.4.2 设计内容
①定义系统布局(如ECU架构)
②定义系统的冗余路径
③定义组件(或子系统)间的接口
④定义组件间的交互信号
⑤定义硬件和软件的接口规范(HSI)
⑥通过安全分析,避免系统失效(FMEA、FTA)
1.4.3 系统分析方法
①说明:⚪不作要求;+推荐要求;++强制要求。
②FMEA分析
●用于识别系统失效、失效原因及失效影响
eg.对于S、O、D的评级标准,各个主机厂都有自己的规范文件
③FTA分析
●用于识别失效原因和失效间的关系
●顶事件往往受到多个低级别事件的综合影响
●FTA分析不考虑驾驶场景
eg.
1.4.4 设计验证方法
1.5 集成与测试
1.5.1 ISO 26262 中系统集成测试和安全验证流程
1.5.2 集成测试内容
目的 | 验证系统设计满足功能和技术安全需求 |
原则 | ●每个安全需求都要验证 ●选择基于ASIL等级的测试方法 ●制定硬件、软件、系统、整车的集成测试计划 ●根据集成测试规范,最后生成集成测试报告 |
测试内容 | ●需求实现正确性测试 ●安全机制性能测试 ●内外部接口测试 ●诊断覆盖度测试 ●鲁棒性测试 |
测试步骤 (3个步骤) | step1:HW/SW集成 ●HIL测试,评估安全机制和其DC step2:系统集成 ●HIL测试或lab car测试,确认系统的安全机制及其他功能正常工作 step3:整车测试 ●HIL测试或lab car测试或整车测试,确认相关项与车辆其他系统正确的交互(包括对其失效的容错处理) |
1.5 安全确认
1.5.1 目的
①检查假设条件是否正确:
—可控性
—容错时间
—安全状态
②确认其他假设的正确性(外部技术条件)
③检查安全机制是否正常工作
1.5.2 整车测试要点
①各种工况下
②各种驾驶场景下
1.5.3 确认方法
①车辆故障注入法
②长期测试,如耐久
③等等...
————————————————————————
参考资料:
iso26262之2018版与2011版主要内容对比与分析…_汽车功能安全-商业新知
ISO26262功能安全核心思想及芯片安全设计实例_Part
微信公众号:道道功能安全