可伸缩性:安全分析的迫在眉睫的问题

自动化的无限的可能性在汽车和其他车辆迷住了设计师,电子内容现在是一个分化的司机比任何其他因素。它占了很大的一部分材料成本在任何这些车辆。但是这种汽车技术革命有一个警告。在其他应用程序中,一个电子问题可以纠正关机或重新启动。同样的决议,但是,并不适合汽车。电子的不正当性行为会导致事故,甚至死亡。

为了解决这个真正关心,ISO 26262标准精心制定汽车电子安全指南。这种背景下的细节描述和测量在汽车电子设计。最重要的一个标准是失效模式分析,效果和诊断分析(FMEDA)为每个组件。它列出了潜在失效模式与相应的影响系统的安全性和减少此类故障的方法。这些报告交流安全特性通过价值链,从IPs汽车oem,如图1所示。

图1:FMEDA供应链流程的一个例子。

生成FMEDA每汽车芯片系统(SoC),需要重大的努力,任务是复合当这些部分是可配置的。这一责任增加了积分器的负担而不是供应商因为只有设计师才能知道需要哪些配置。作为进一步的并发症,这些分析报告的标准只定义的意图,没有详细的格式。在这些格式不一致阻碍生产力安全分析价值链。这种情况不是可伸缩的和需要更多的标准化和情报。

当前过程中的问题

安全性评价始于一个失效模式与效应分析(FMEA)基于系统设计经验在潜力方面,原因,影响系统可能会失败。这是系统的起点FMEDA捕捉到每个组件的设计报告。上市对于每个失效模式的潜在影响对系统的安全以及防止的方法,检测和纠正这些故障。随机故障,也许通过宇宙辐射电离引起的,是特别关注的。故障的分析是基于长期的模拟,确定如何通过电路或如果这些故障行为传播。

图2:创建FMEDAs的多重挑战。

FMEDA在给定水平的设计展示了严谨的计划和测试失效模式在一个详细的水平。移动到下一个级别的系统设计、FMEDAs通常是抽象聚合到更高的水平。抽象修剪下的失效模式相关的系统分析,同时保留安全分析报道。每个用例驱动在系统级的性能和可能需要建立不同的抽象分析。

在SoC设计,这个过程在三个重要方面存在可伸缩性问题,如图2中突出显示。它不是被设计来有效地处理高度可配置的IP。network-on-chip (NoC)提供了一个明显的例子。每个NoC配置是独一无二的端点指定SoC的ip连接的服务质量和能力的目标。随着设计的变化tapeout之前,所以必须NoC。每个实例都需要一个独立的分析执行的SoC积分器谁知道所需的NoC配置。

至少一个自然的问题是一些不同配置之间的这种分析可以被再利用。重用已经成功在加速SoC设计和功能验证中起着重要作用。相比之下,FMEDA是相对近期的设计要求和尚未发展重用策略。每分析一个给定的水平必须从零开始,消耗大量的时间和资源。重用策略可以使一个巨大的差异来设计安排,避免错误,如果一个解决方案是可用的。

缺乏一个标准格式FMEDA也是一个效率流失。SoC集成商使用来自多个供应商的IPs必须面对不同的格式,要求,和假设例兼容性,因此,其他方法来获得抽象。今天,这些断开手动集成商和供应商之间解决,但是这个过程不是可伸缩。有太多的点可能会发生错误。

将FMEDA与重用

reuse-centric方法不能基于平面分析在每个阶段。一个可配置的IP的基本失效模式不不同的配置。这些应该在RTL的参数实例化,可允许的一代FMEDA特定布局。在这个流、失效模式和安全缓解将面向模型的而不是report-oriented。基于模型的方法允许生成并交付一个IP FMEDA模型。重要的获得是SoC积分器不再需要运行一个完整的平面分析设计开发期间为每个配置更改。

图3:提出FMEDA生成过程。

下一个合乎逻辑的推进将扩展此功能的SoC FMEDA构建。SoC-level分析可以读传统的发电机FMEDA报告IPs和应用语境需求和使用的假设。这将优化细节到几每IP基本失效模式相关的目的。发电机可以建立适当的SoC FMEDA从这个输入使用模型。生成一个新的分析一组不同的假设比拨号就不需要更多的努力在这些新参数,并重新运行该生成器。由于所使用的工具是ISO 26262认证,额外分析tapeout之前是不必要的,因为合规已经内置。图3展示了完整的提出了流,从FMEDA代IP水平FMEDA代在SoC水平。

这种方法可以极大地简化安全分析的SoC开发团队,即使只有一个IP供应商支持基于模型的能力。如果每个IP供应商支持安全数据交换标准,例如IEEE P2851标准目前在发展,价值SoC安全分析团队将进一步被放大。鼓励工具聚合和抽象的IP为SoC模型可能更依赖的完成和采用IEEE P2851。然而,鉴于已经有这种性质的解决方案在某些汽车SoC供应商,这个目标看起来很可行的。

可跟踪性和FMEDA

每当需求必须集成商和供应商之间交换,可追溯性就变得非常重要了。最重要的要求设计为汽车应用程序安全,FMEDA作为记录。需求、实现、测试和FMEDAs是紧密相连的。这些变化必须正确跟踪别人如果整个过程的完整性维护,如下图4所示。

图4:需求之间的可跟踪性,实现,测试和FMEDA紧密耦合。

这里要考虑的另一个令人信服的理由可追溯性。在每个级别的集成,FMEDAs从详细的结构层次上失效模式抽象到一个小得多的系统故障模式。这种抽象的执行是基于用例和系统设计经验。错误是可能的,但可以减轻通过仔细追溯从系统故障模式下通过组件失败抽象组件更详细的分析。

可追溯性是有价值的问题诊断和抽象支持对不同的用例。一个积分器可以决定一个用例,确定失效模式比其他人更重要。而在另一种情况,这一决定可能会改变。鉴于检查全套失效模式的能力,一个积分器可以选择优先和忽视。与发电机的支持,如前一节所述,一个积分器将享受更多的灵活性来探索选项。

一个行动呼吁

为了重用实践FMEDA似乎合乎逻辑的和不可避免的。重用实践已经充分证明在设计和验证。现在是时候为安全分析将达到这一水平。是自然也使这些接口与IEEE P2851标准计划,开始出现。同时,高度可配置的IP供应商应该更好地服务集成商客户工艺解决方案。聚合和抽象汽车半导体解决方案可以帮助定义一个更完整的解决方案在SoC的水平。这种方法通过FMEDA必须认识到需要的可追溯性。

只有通过这种性质的进展有可能跳过去安全分析可伸缩性的迫在眉睫的问题。

关于FMEDA的更多信息,请点击在这里。