|
目录 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 FSCFunctional Safety Concept，功能安全概念 A.2 TSCTechnical Safety Concept，技术安全概念 A.3 TSRTechnical Safety Requirement，技术安全需求规范 A.4 SGSafety Goal，安全目标 A.5 SMsafety mechanism，安全机制，为了达到或保持某种安全状态，由E/E功能或要素或通过其他技术来实现的技术解决方案，以检测故障或控制失效 A.6 安全确认safety validation，检查假设是否正确，验证所有外部的其他假设的正确性，检查安全机制是否正常工作 A.7 DCDiagnostic Coverage，诊断覆盖率，高安全性反映在硬件设计上即代表安全机制需要非常高的故障诊断覆盖率DC，DC值在ISO 26262中可分为high（99%）、medium（90%）、与low（60%）三种等级 A.8 FMEAfailure mode and effects analysis，失效模式及后果分析，一种自下而上的归纳分析方法，通过识别部件的失效模式来追溯失效影响，包含DFMEA（设计FMEA）和PFMEA（过程FMEA），FMEA适用于系统、软件、硬件层次 A.9 FMEDAfailure mode，effect and diagnostic analysis，失效模式影响及诊断分析，一种自下而上的归纳分析方法，在FMEA上对随机硬件失效率的计算，FMEDA适用于硬件层次，考虑独立的故障，工具相对简单 A.10 FTAfault tree analysis，故障树分析，一种自上而下的演绎分析方法，通过危害事件来追溯失效原因，同时可反向计算顶部事件的失效率，FTA适用于系统、软件、硬件层次，考虑多个故障，需要专业的工具 A.11 DFAdependent failure analysis，分析不同功能或设计中的独立性，识别从属故障，找出系统中的共因以及级联失效，DFA适用于系统、软件、硬件层次 A.12 HILHardware-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 HSIhardware-software interface，软硬件接口 A.21 FTTIfault tolerant time interval，故障容错时间间隔，是指在安全机制未被激活的情况下，从相关项内部故障发生到可能发生危害事件的最短时间间隔 eg.制动失效开始到汽车发生碰撞的时间。 eg.电池充电过程中发生过流故障，到BMS检测到过流故障并且将电池置入安全状态（切断继电器，停止充电）的时间。 A.22 FDTIFault detection time interval ，故障检测时间间隔，是指从故障发生到故障被识别的时间 A.23 FHTIFault handling time interval ，故障处理时间间隔，FHTI=FDTI+FRTI A.24 FRTIFault reaction time interval ，故障反应时间间隔，是指从故障被识别到安全状态或紧急运行模式的时间 eg.系统检测到制动失效到安全停车 A.25 DTTIDiagnostic test time interval，诊断测试时间间隔，是指安全机制进行在线诊断测试的时间间隔，包含诊断测试的时间 eg.制动系统每10ms进行一次在线诊断 A.26 EOTIEmergency operation time interval，紧急运行时间间隔，是指如果识别到失效后，无法直接进入安全状态，则需要通过紧急运行模式来过渡，紧急运行开始到安全状态的时间称为紧急运行时间间隔 eg.识别到制动失效后，车辆进入跛行模式，EOTI则是跛行模式开始到安全停车的时间。 A.27 EOTTIEmergency 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的文档的差异性
A.32 ISO 26262-2018与 ISO 26262-2011在part4的工作成果差异性
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
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）
③分解方法和要点
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 集成测试内容
1.5 安全确认1.5.1 目的①检查假设条件是否正确： —可控性 —容错时间 —安全状态 ②确认其他假设的正确性（外部技术条件） ③检查安全机制是否正常工作 1.5.2 整车测试要点①各种工况下 ②各种驾驶场景下 1.5.3 确认方法①车辆故障注入法 ②长期测试，如耐久 ③等等... ———————————————————————— 参考资料： iso26262之2018版与2011版主要内容对比与分析…_汽车功能安全-商业新知 ISO26262功能安全核心思想及芯片安全设计实例_Part 微信公众号：道道功能安全 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
