阻止错误传播通过耦合因素或级联从一个元素到另一个。
由Shivakumar Chonnad、拉杜Iacob和弗拉基米尔Litovtchenko
由于增加了复杂性在安全至上的系统硬件,软件,和机电一体化,功能安全开发过程必须解决系统和随机硬件故障。许多安全活动期间执行安全至上的IP和SoC发展中,作为安全生命周期的一部分,从产品概念到退役。安全计划,包括日期、里程碑任务,交付,责任,和资源,是一个关键工作产品需要计划,管理和指导产品开发期间这些安全活动的执行。安全计划必须定义相关失效分析(DFA)[1],这是一个关键的活动。
DFA的主要目的是揭示潜在的依赖依赖失败造成的发起者(DFI) [1]。
本文解释了实现DFA的重要性在汽车IP和SoC发展周期和DFA如何帮助满足技术独立要素根据设计的安全要求。
级联失效(CF)[1]在几个IP组件或IP模块在一个SoC之间可能出现两个或两个以上的元素。失败在一个组件产生的根源,在(内在错误)或外块,可能会导致在相同的组件或不同的模块故障时,导致违反安全要求。另外,两个或两个以上的IP的失败组件或在一个SoC产生直接从一个特定的事件或根源,内部或外部所有这些元素,可能会导致失败的常见原因(CCF)[1],如图1所示[1]。元素B是免费的干扰元素的如果没有失败会导致元素B失败。元素A和B是独立的,如果没有干扰和常见故障根本原因存在。目的是分析评价结果通过耦合因素阻止故障传播或级联从一个元素到另一个地方。
图1:说明失败和级联故障的常见原因。
依赖失败有一个依赖关系链传播通过共同特征或受影响的模块之间的关系。传播链是由耦合因素,可以有利于信号之间的耦合,常见的元素,如电源和时钟网络,等。发展类金融机构是一个根本原因,导致多个元素失败,从而导致进一步通过耦合传播因素。受影响的模块的层次结构以及它们之间的时序功能行为形式的耦合因素。重要的是要注意,西南还可以依赖系统故障的来源,这是由给定的元素之间的交互,包括西南或HW元素,或者两者兼有,通过耦合因素,可能影响安全要求。
SoC或IP设计可以有不同的子块有或没有安全的相关性。每个区块开发按照所需的措施实现其最高适用的汽车安全完整性水平(ASIL) [1]。确定元素的ASIL时,级联故障分析可以提供一个理由免于干扰(FFI)[1],如图2中所描述的。FFI是没有级联故障可能导致违反安全要求,还用于考虑和证明共存的元素。
图2:从干扰技术独立和自由。
FFI可以通过合适的块划分,这样可以发现任何故障在一块和/或减轻避免级联到另一个块。独立块之间可以发生后才确认没有相关故障,可能导致违反安全要求。如果DFA揭示了相关故障的原因,然后适当的安全措施可以实施ASIL依照最初的安全要求。
确定技术独立,除了CCF分析级联故障分析必须执行。通过识别ccf或级联故障的潜在原因,DFA可以支持安全措施计划。如果有必要,这些额外的安全措施是实现西南和/或HW级或系统级实现足够的独立性。它可以有机会分配齐次函数具有不同安全临界在设计分区的步骤。
IP组件需要DFA为了分享潜在来源的依赖失败原因与SoC积分器或安全评估员。例子包括一个断层[1]影响任务逻辑和相应的安全机制[1],一个错误在共享资源或共享基础设施元素,如时钟树。方案中冗余逻辑的双核cpu锁定步骤(dcl)存在,系统误差会影响主和冗余的核心,导致失败的依赖。的另一个重要部分安全分析和报告的披露可能受点或潜在的接口
失败带来的西南和HW通过硬件软件之间的交互接口(HSI)。通过分析这些潜在原因或依赖失败发起者,合适的安全措施可以被定义为检测或缓解。归纳或演绎HW设计安全分析可以确定故障原因和影响。
在依赖的情况下失败,自顶向下的方法演绎分析功能,从顶级失败或违反安全目标,如图3所示[2]。因此,违反安全目标是进一步分解为具体的失效模式和随后的分析来识别潜在的风险相关的故障。例如,将安全目标分解违反包括任务功能,任务之间的功能和安全机制,和其他常见故障原因,如共享资源,共享输入等。
图3:演绎法用于相关的故障分析。
这种自上而下的分析通常表现在建筑层面,为设计实现决策和技术提供输入。演绎分析[1]应该继续沿着设计开发更多的设计数据变得可用。
设计架构进一步细化,执行一个归纳分析是很有用的使用自底向上的方法[1]。适当的分析进行归纳分析,如果一组给定的初始原因确定决定产生的后果。
设计实现细节,归纳数据驱动的分析可以从发起人实际常见原因,耦合因素,和故障传播路径。这种分析可能导致识别额外的失败可能没有被认为是在演绎分析。一般来说,演绎和归纳的方法都必须是采用一套完整的依赖失败。聚焦的演绎方法的好处时不受欢迎的事件进行分析归纳的方法保证了分析扩大到包括所有可能的场景。
DFA始于识别和分析所有的块或需要独立的区块。分析应用于FFI的水平或技术独立需求实现,例如在系统、HW或SW水平。顶级安全需求转化为详细的HW或SW安全要求实现由独立的元素。功能冗余的方法可以使用,这样两个独立的建筑元素允许监控和检测的缺点。这些元素足够独立,以确保:
然后元素的依赖DFI CCF确定允许进一步分析确定依赖的模块故障启动程序传播到级联故障根源。耦合因素传播依赖失败在这些街区进一步确认。使用结果数据,分析缩小所有可能的事件,执行错误,或故障元素之间的传播导致失败的因果链。
结果数据是用来识别可能的措施,减轻依赖发展类金融机构和耦合因素影响,防止失败。这样可以确保设计或层次结构提供了功能分离独立和安全措施需要监控共享资源依赖的失败。
结果,可以选择适当的安全措施,以防止或检测和控制故障有可能违反安全要求如图4所示。
图4:典型的步骤相关的失效分析流程。
安全分析相关的失败被应用在开发生命周期阶段。这些分析可以彼此相关。DFA可以开始早在建筑阶段,各种元素的模型和行为已经定义。一旦规范微架构水平或详细的硬件规格准备好了,界面行为和耦合因素,例如传播路径,是已知的。DFA在不同阶段的结果然后反馈到实现和验证阶段减轻失败由于评价结果。
图5:DFA相关活动在安全相关项目周期。
DFA可以确认组件之间的干扰或足够的独立自由。设计发展类金融机构基于DFA识别结果。验证活动,比如各种场景的仿真通过定向或随机刺激生成确认传播和/或级联故障的常见原因。验证方案可以确认是否安全机制的功能和效率监测或检测相关的故障。数据审核和实现后阶段充分解决相关识别断层和他们的安全措施。评论还确认独立和自由的实现水平相关的HW和/或SW元素之间的干扰。考虑附加安全等补充DFA分析故障树分析(FTA),一个结构化的方法演绎方法,和失效模式的影响和诊断分析(FMEDA),它提供了一种安全机制,可能会依赖列表错误关于他们监测任务功能。为安全元素的上下文(SEooC),外部措施依赖失败控制进一步的注解为假设使用安全手册中(险)。DFA是必要的结果输入设计验证报告/验证计划,旨在确定技术独立的成就或免于干扰所需的建筑规范和技术安全概念(TSC)。块之间的独立验证当DFA-related ccf解决,FFI实现。
所有上述的数据分析可以合并为一个DFA报告,包含DFA原理信息,基于FFI,所需共存的元素和ASIL分解,和技术独立,ccf另外考虑。这份报告还应该包括部分致力于发展类金融机构。作为分析的一部分,潜在耦合因素也检查了。类似于FMEDA, DFA分析所有可用的产品配置。DFA报告应进一步包括常见故障原因的分析总结,为避免或控制和缓解措施。DFA报告还应该包括级联故障分析总结和建议措施规避和控制。充分验证了这些措施的验证程序包含在产品的验证计划和DFA文档中引用。验证结果的证据提出了DFA的验证报告和总结报告。报告最后的剩余风险的评估依赖的失败。如果缓解措施不足,剩余风险存在,安全措施改进和效能评估是重复的。 A list of follow-up actions are presented in this final section of the report.
现代汽车产品开发需要专门的功能安全特性来避免或控制失败的风险。功能安全开发流程涉及到各种安全分析,包括DFA发起的项目的早期阶段,确保FFI或技术独立,如图6所示。
图6:DFA活动的总结。
发展类金融机构,如共享内部资源和共同的外部资源,必须分析适用。DFA表明FFI的要求和技术满足独立根据设计的安全要求。相关的安全措施验证失败以类似的方式到其他安全机制。如果剩余风险存在,这些措施改善和有效性评估是重复。DFA是一个重要的先决条件FMEDA给出错误的影响依赖安全机制诊断覆盖率。SEooC,外部缓解措施的注解为假设使用(AoU)安全手册。
DFA文档和DFA报告标准交付Synopsys对此汽车DesignWare IP ISO 26262合规为特色的产品。DFA确保独立性假设在技术安全概念(TSC)和FMEDA正确实现。生产Synopsys对此“DesignWare IP组合包括安全包,包括失效模式的影响和诊断分析(FMEDA)报告,安全手册,和认证报告加快安全评估和帮助设计师ASILs达到他们的目标。
引用:
拉杜Iacob Synopsys对此是一个质量和功能安全工程经理。
弗拉基米尔•Litovtchenko是功能的高级经理在Synopsys对此工程安全和质量。
|
|
|
|
|
|
|
|
留下一个回复