汽车功能安全仿真

作为设计师，我们都希望我们的设计能够正常工作。我们以拥有者为荣。因此，我们疯狂地验证以确保我们做得很好。但是验证需要时间，而且项目有截止日期，否则他们就不会赚钱。所以，我们尽我们所能，用良好的验证工具提供帮助，总的来说，我们做得很好。

但对于所有设计，失败的后果并不相同。如果您的笔记本电脑或游戏机无法工作，可能会令人沮丧，甚至可能会花费您一些钱，但不会威胁到生命。另一方面，如果系统故障会使人员或重大财产面临风险，那么我们就进入了功能安全领域。

这曾经是军用或民用飞机小批量、高成本项目的唯一领域。你上次旅行时乘坐的飞机上的所有电子设备？他们必须工作；失败不是一种选择。你的生活取决于它。

但时代在变：安全至上的不再只是坦克、导弹和飞机。所有的电子产品都被设计到汽车中，包括驱动的和无人驾驶的。这将功能安全从稀有的军事/航空航天领域带入了为消费者制造的汽车的喧嚣。安全关键芯片的数量应该会飙升。

故障模式

从广义上讲，有两类失败：

系统性故障：这些是由于原始设计规范或规范实施中的错误而引起的问题。这就是传统验证的解决方案。

随机故障：这些是由不可控制的力量引起的任何其他类型的故障。这包括电磁影响、所谓的“单粒子扰动”（如 α 粒子）以及任何其他此类影响。这些事件可以改变至少一个触发器（任何触发器）的状态，并且随着电路尺寸的缩小，单个事件甚至可能影响多个触发器，因为它们非常靠近。

随机故障域是设计中更难解释的域。有些技术多年来一直用于小容量系统——比如三模块冗余。但对于面向消费者的汽车来说，它们太贵了。

因此，目标从确保一切都不会出错（实际上来说）转变为安排任何遇到故障的系统自然地进入安全状态。这并不意味着系统会像什么都没发生一样继续工作，但这确实意味着系统不会进入某些可能对周围或内部人员构成危险的不可预测的状态。

作为设计师，您的任务就是尽量减少可能的故障数量，然后防止那些仍然存在的故障。未检测到的故障——那些没有传播到系统，因此对任何输出都没有明显影响或没有导致非法内部状态的故障——不是问题，也不需要保护设计。另一方面，确实传播到系统的可检测故障依赖于额外的电路进行保护。目前，一旦您知道关键故障在哪里，这些电路都是手动设计的。

识别和防止故障

那么如何发现这些故障呢？这是一项工作……我们将使用广义上的“模拟”一词，尽管正如我们将看到的，EDA 模拟器无法胜任这项任务。这个想法是在注入故障的同时模拟系统，以了解哪些故障会导致不希望的状态。并且有很多可能的故障——理论上，每个触发器有多个故障。ISO 26262 建议在门级进行故障注入，与基于 RTL 的设计相比，验证系统的潜在故障活动成为一项更大的任务。

这里有几个挑战使这项任务比看起来更加困难。首先，有几种故障需要测试。最常用的模型是固定故障、瞬态故障和桥接故障。并且此类故障通常一次注入和测试一个，因为这降低了测试的复杂性。

此外，完成设计的故障活动所需的故障列表可能非常大。例如，单独测试一个微处理器可能需要一个包含 100，000 个故障的列表，因此完整的 SoC 故障活动将扩展某些技术的限制，例如模拟。

所谓的故障修剪可以帮助减少故障列表的长度，这是 Mentor 积极参与的一个积极研究领域。但是，说实话，即使在修剪之后，你仍然会有很长的清单。

如果您使用传统的 EDA 模拟器来完成这项工作，这将是一个巨大的项目。仅 100，000 门处理器就可能需要 11 天的时间，使完整的 SoC 遥不可及。这使得这成为一项仿真工作，Mentor 为 Veloce 仿真器系列提供了一个故障应用程序。

您首先提供必须注入的故障列表，Veloce Fault App 系统地处理该列表，记录所有结果。这仍然需要时间，但是在任何给定的运行中，一旦检测到意外状态，该特定运行就会停止并被记录下来（换句话说，最慢的故障是不会提前结束的不可观察的故障）。

您不必绝对列出设备中的每个网络，因为很可能有些区域显然不会引起关注。但其他一切都应该被代表

完成后，您将获得一份故障输出列表、未检测到的故障以及设计的整体故障覆盖率——所有这些都有助于您强化设备以满足功能安全要求。

毫无疑问，提供功能安全需要额外的工作。但这比召回部件或车辆后的重新设计要少得多——而且成本要低得多！配备 Veloce Fault App 的 Veloce 仿真器可以处理任务中繁琐的部分，为您的设计技能留下更有趣的保护设计。

审核编辑：郭婷