内容提要：本文详细介绍了汽车电子设计的流程特征和度量指标。

汽车以及其他车辆自动化的无限可能性吸引了设计师，他们意识到电子内容比任何其他因素更能推动差异化。在任何一种车辆中，电子件都占物料成本的很大一部分。但这场革命也发出了一个警告：在其他产品中，电子设备问题可以通过关机或重新启动来解决，这对汽车并不适用。汽车电子设备的不当行为可能导致事故，甚至死亡。

为了解决这个真正的问题，ISO 26262标准制定了汽车电子安全指南。本文详细介绍了汽车电子设计的流程特征和度量指标。标准中最重要的分析之一是每个组件的失效模式、影响和诊断分析(FMEDA)。它列出了对系统安全产生相应影响的潜在失效模式，以及减轻此类失效的方法。FMEDA报告在IP到汽车OEM的价值链中传递安全特性，如图1所示。

图1.FMEDA安全特性传递链

每个SoC的FMEDA生成，都需要付出巨大的努力，而当这些器件可配置时，这项任务就会变得更加复杂。这增加了集成商的负担，因为只有设计人员才知道需要哪些配置。更复杂的是，标准只定义了这些分析报告的意图，而不是详细的格式。这些格式的不一致会抑制价值链上游安全分析的生产力。显然，这种情况是不可扩展的，需要更多的标准化和智能化。

当前流程中的问题

图2.创建FMEDA的多重挑战

安全评估从失效模式和影响分析(FMEA)开始，该分析基于系统设计经验，了解系统可能发生失效的潜在方式、原因和影响。这是系统化FMEDA分析的起点。每种失效模式都列出了其对系统安全的潜在影响，以及预防、检测和纠正此类失效的方法。特别值得关注的是，随机失效可能是由宇宙辐射的电离触发的。该分析基于对失效的长时间仿真，确定这些失效行为如何或是否会通过电路传播。

给定设计级别的FMEDA展示了详细的失效模式和测试的严格性。而进入系统设计的下一层级，FMEDA通常被抽象到更高级别。这种抽象将失效模式缩减为与系统级分析相关的失效模式，同时确保安全分析覆盖范围。此外，每个用例都涉及性能，需要在系统级分析时构建不同的抽象。

在SoC设计中，该过程在三个重要方面存在可扩展性问题，如图2所示。它的设计不能有效应对高度可配置的IP。片上网络NoC(network-on-chip)是一个典型案例。每个NoC对于其连接的终端IP中的特定SoC、服务质量和功率目标都有唯一的配置。由于设计在流片之前改变，因此NoC也必须改变。显然，每个实例都需要由了解NoC配置的SoC集成商来进行独立分析。

一个很容易想到的问题：是否可以在不同的配置之间重复使用其中的一些分析。显然，重用已经成功地加速了SoC设计，并在功能验证中发挥了重要作用。相比之下，FMEDA是相对较新的补充设计，尚未发展出重用的策略。若一个级别的每个分析都必须从头开始，会导致耗费大量时间和资源。如果有可用的解决方案，重用可以对设计计划产生巨大影响并避免错误。

FMEDA缺乏标准格式也是一种效率消耗。SoC集成商使用来自多个供应商的IP，必须面对不同的格式、需求和用例假设，包括其他方法做的抽象。现在，这些错位是在集成商和供应商之间手动解决的，但这个过程是不可扩展的。这中间有太多可能发生错误的点。

重用使FMEDA一致

以重用为中心的方法不能基于每个阶段的平面分析。可配置IP的基本失效模式不会因配置而异。这些在RTL的参数化实例中可以解释，并可以为特定布线生成FMEDA。在这个过程中，失效模式和安全轻减将以模型为导向，而不是以报告为导向。基于模型的方法可以生成和交付IP的FMEDA模型。这样SoC集成商不再需要在设计开发期间，对每个配置更改进行一次完整的分析。

图3.建议的FMEDA生成过程

下一个合乎逻辑的改进是将此功能扩展到SoC FMEDA构建中。用于SoC级分析的生成工具可以读取IP的传统FMEDA报告，并应用到上下文需求和使用假设中。这就把细节优化到与每个IP的用途相关的一些基本失效模式。然后，生成工具可以根据该输入，为其使用模型构建适当的SoC FMEDA。如果为一组不同的假设生成新的分析，只需要导入这些新参数并重新运行生成工具即可。由于所使用的工具已通过ISO 26262认证，因此在流片之前无需进行额外分析，因为合规性已经内置。图3说明了完整的建议流程，从IP级别的FMEDA生成，再到SoC级别的FMEDA生成。

即使只有一个IP供应商认可基于模型的功能，这样的方法也可以极大地简化SoC开发团队的安全分析。如果每个IP供应商都支持安全数据交换标准，例如目前正在开发的IEEE P2851标准，那么对SoC安全分析团队的价值将进一步放大。推动使用工具为SoC聚合和抽象IP模型，可能更多地取决于IEEE P2851的完成和采用。然而，鉴于一些汽车SoC供应商已经有这种性质的解决方案，一部分半导体公司正在使用基于模型的安全分析工具REANA进行半导体的安全设计，该类工具可以实现不同级别的元素建模，以及不同级别的FMEDA自动化传递，从而帮助芯片集成商快速导入供应商的设计和安全模型，所以，这个目标是可以实现的。

可追溯性和FMEDA

当集成商和供应商之间必须交换需求时，可追溯性就变得至关重要。如FMEDA中所述，汽车应用设计中最重要的要求是安全性。需求、实施、测试和FMEDA密切相关。如果要保持整个过程的完整性，则必须正确跟踪其中任何一个的变化，如下面的图4所示。

图4.需求、实施、测试和FMEDA之间的可追溯性是紧密耦合的

这里还有另一个令人信服的理由来考虑可追溯性。在每个集成级别上，FMEDA从详细的结构级失效模式抽象为数量少得多的系统级失效模式。这种抽象是基于用例和系统设计经验执行的。错误可以通过从系统失效模式到组件失效抽象再到更详细的器件分析的追溯性来减少。

可追溯性对于针对不同用例的问题诊断和抽象支持很有价值。集成商可能会针对一个用例决定某些失效模式比其他失效模式更重要。而在另一种用例下，该决定可能会改变。鉴于能够检查全套失效模式，集成商可以选择优先考虑和忽略的内容。如前一节所述，在生成工具的支持下，集成商将享有更大的灵活性去挖掘可选项。

行动号召

重用FMEDA实践的举措似乎既合乎逻辑又不可避免。重用实践已经在设计和验证中得到充分证明。显然，现在是时候将安全分析提升到这一水平了。当这些接口开始出现时，将这些接口与计划中的IEEE P2851标准保持一致，也是很自然的。与此同时，高度可配置的IP供应商应制定解决方案，以更好地为集成商客户服务。用于聚合和抽象的汽车半导体解决方案有助于在SoC级别定义更完整的解决方案。这种方法必须认识到通过FMEDA进行可追溯性的必要性。

只有通过这种实质性的进步，才有可能跨过安全分析可扩展性方面迫在眉睫的问题，如果您有兴趣加入IP安全数据标准化讨论，欢迎添加牛小喀微信：NewCarRen，加入SCCM半导体安全技术工作组。

作者：牛喀网专栏作者
牛喀网文章，未经授权不得转载！