发布日期：2024-11-04 09:34    点击次数：102

目录A 名词解释A.1 FSCA.2 TSCA.3 TSRA.4 SGA.5 SMA.6 安全确认A.7 DCA.8 FMEAA.9 FMEDAA.10 FTAA.11 DFAA.12 HILA.13 严重度（S）A.14 频度（O）A.15 探测度（D）A.16 风险顺序数（RPN）A.17 FaultA.18 ErrorA.19 FailureA.20 HSIA.21 FTTIA.22 FDTIA.23 FHTIA.24 FRTIA.25 DTTIA.26 EOTIA.27 EOTTIA.28 安全状态保持时间间隔A.29 多点故障探测时间间隔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 中系统开发流程1.3 技术安全需求TSR1.4 系统的设计及分析方法1.4.1 ASIL分解1.4.2 设计内容1.4.3 系统分析方法1.4.4 设计验证方法1.5 集成与测试1.5.1 ISO 26262 中系统集成测试和安全验证流程1.5.2 集成测试内容1.5 安全确认1.5.1 目的1.5.2 整车测试要点1.5.3 确认方法先导：本文是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 ，故障检测时间间隔，是指从故障发生到故障被识别的时间eg.制动失效，到仪表点亮故障指示灯A.23 FHTIFault handling time interval ，故障处理时间间隔，FHTI=FDTI+FRTIA.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的文档的差异性序号part20182011备注14：产品开发在系统层面“项目计划”、“安全计划”、“相关项集成和测试计划”、“验证计划”、“功能安全评估计划”移动合并到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-2018ISO 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）防止故障潜伏的措施a）故障探测、指示及控制措施①针对系统自身的故障，需要根据其失效模式设计相应的故障探测机制，包括所需的硬件和软件算法，故障报警及控制措施eg.油门踏板信号故障诊断，硬件采用双路信号输出且阈值和信号随踏板开度的变化率不同，以此用双路信号互校验来诊断踏板的失效：—信号丢失或对地短接—信号超过合理阈值区间—两路信号值不成比例等控制措施：发送机限功率运行，进入跛行回家模式故障报警：仪表点亮相应的故障灯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测试，评估安全机制和其DCstep2：系统集成●HIL测试或lab car测试，确认系统的安全机制及其他功能正常工作step3：整车测试●HIL测试或lab car测试或整车测试，确认相关项与车辆其他系统正确的交互（包括对其失效的容错处理）1.5 安全确认1.5.1 目的①检查假设条件是否正确：—可控性—容错时间—安全状态②确认其他假设的正确性（外部技术条件）③检查安全机制是否正常工作1.5.2 整车测试要点①各种工况下②各种驾驶场景下1.5.3 确认方法①车辆故障注入法②长期测试，如耐久③等等...————————————————————————参考资料：iso26262之2018版与2011版主要内容对比与分析…_汽车功能安全-商业新知EPB功能安全笔记 (11)：FTA定性分析示例hil测试是做什么_汽车测试技术__汽车测试网ISO26262功能安全核心思想及芯片安全设计实例_Part微信公众号：道道功能安全 本站仅提供存储服务，所有内容均由用户发布，如发现有害或侵权内容，请点击举报。