设计师如何量化电子系统的安全性

通过一个或多个表格，称为故障模式影响和诊断分析 - FMEDA。事实上，FMEDA 不一定是表格；它也可以用脚本或其他形式表现出来，但表格是考虑这些信息的最简单方法。可以将 FMEDA 视为 IP，因为这个概念很容易扩展到系统级芯片(SoC)中。在FMEDA表格中，将 IP 专家能够想到的可能导致严重安全问题的每一种故障模式都列出来，每种故障模式占一行。

在每种故障模式的辨识信息之后，是对其所产生影响的描述 - 即它可能导致的安全问题。通过故障模拟，安全工程师分析确定产生这种故障的根源问题的可能性。如果这种可能性很大，设计人员将提供一种缓解技术，例如用奇偶校验来检测问题，或用纠错码 (ECC) 检查来纠正问题。最后，完整的 FMEDA 就代表该 IP 的综合安全质量文档，SoC 集成商在确定整个设计的 FMEDA 时可以使用该描述表征。

图1给出创建FMEDA面临的多重挑战。

可扩展性

这种方法存在一个问题。在这种情况下，FMEDA是 IP 安全性的基本表征，如果所有的 IP 都是严格定义的，这可能是可以接受的。在表征 IP 的其他方面时，设计人员可以继续添加该 FMEDA的内容，并将其存储在 IP中，然后在 SoC 表征中使用该表。

如今，大多数 IP 都是可配置的，例如片上网络 (NoC)。没有一个 FMEDA 可以用来处理所有情况。SoC 开发人员必须为将要使用的配置在 FMEDA中继续添加内容。虽然 IP 供应商可以提供帮助和提示，但是集成商必须进行所有分析。如果在设计期间配置发生变化，则必须重新构建FMEDA中相应的内容。

直觉上这是一种浪费。我们再来看看 NoC IP的情况。虽然 NoC 的实例化拓扑可能会随着设计的发展而改变，但它很可能不会发生根本性的变化。而这些变化对 FMEDA 的影响将更加有限。在每次重新配置时，从头开始重新构建 FMEDA 会略过未更改的大部分内容。

对于更改的情况，与之前的结果相比，变化是可预测的。重新分析每一次重新配置是可行的，但是随着设计规模的增长，这会带来可扩展性问题。在一个无法很好扩展的过程中，可能会遗漏一些步骤，安全性也会受到影响。对于集成商来说，在已经很满的设计时间表里，重建 FMEDA 是一项巨大的工作。努力减少这个工作量可以让他们更轻松。

通过建模重复使用

Arteris 撰写了一份关于如何通过重复使用来解决这个问题的前瞻性白皮书。在 IP 供应商基于对 IP 架构和详细特征的理解而开发的安全模型中，FMEDA 的重要方面可以得到体现。然后，基于这些模型和 IP RTL，集成商可以使用编译器来构建完全配置的 IP 的 FMEDA。

对于集成商来说，这应该是一件容易得多的任务。SoC 安全团队仍然可以在签核之前运行完整的 FMEDA 作为双重检查；每次重新配置都不需要分析。

图2 给出建议的FMEDA的生成过程。

编译器可以为集成商构建传统的 FMEDA 表格，或者将脚本传递给脚本驱动工具，用于 SoC FMEDA 生成。今天，这种程度的集成似乎主要在大型汽车半导体公司内部进行。通常，此脚本将 IP 级别表格与 FMEDA 聚合在一起，用于集成结构、电源和控制。设计人员将上下文需求和使用假设应用到抽象的故障模式中，创建了一个感兴趣的用例。

现在是需要将FMEDA的组织结构标准化，这样可以简化来自多个 IP 供应商的此类输入的汇总。正在开发中的提案 IEEE P2851 应该能够促成这项工作。它还可以帮助定义聚合和抽象的标准。这将鼓励商业工具的开发，以便使从 IP 的 FMEDA 开发到 SoC 的 FMEDA 开发的流程完全自动化。

自动化的另一个考虑因素是可追溯性。安全需求是汽车电子系统需求的关键组成部分，应该与设计和测试一起纳入可追溯性基础结构。增加可追溯性自动化将完成开发和跟踪安全特性的一个强大系统。

审核编辑：刘清