18lickc新利
的意见

在失败操作架构中的互连突出

当自动驾驶汽车中的子系统需要重新启动时,如何管理?

受欢迎程度

当我们在半导体世界考虑安全时,我们会想到ISO 26262、FMEDA和安全机制,如冗余、ECC和锁步操作。一旦我们解决了这个问题,其他方面的安全就是别人的问题了,对吧?不幸的是,至少对我们来说不是。随着我们向更高级别的自动驾驶(SAE 3级及以上)迈进,我们正在将更多功能集成到soc中,其中许多功能涉及复杂的决策。这些复杂的系统会出现问题,无论是由于瞬时故障还是其他原因,并不是所有这些问题都可以通过我刚才提到的安全机制立即得到纠正。有时,你必须重新启动,就像你重新启动手机、电脑,甚至是最先进的电视一样。

但在自动驾驶或半自动驾驶汽车的系统中“重启”是一项严肃得多的工作。当没有驱动程序或名义上的驱动程序没有注意时,您不能关闭系统并重新启动它;在经济复苏之前,各种糟糕的事情都可能发生。必须隔离故障系统的部分,同时依靠其余部分继续处于紧急模式,同时重新启动这些隔离组件以纠正问题,或直到人类驾驶员接管。如果没有人类司机,或者司机不需要像3级自动化那样积极参与,那么车辆可以跛行到安全状态,比如在路边停下来。

紧急操作如何发挥作用当然是汽车(或可能是Tier 1)架构师的决定,但SoC架构必须支持他们的需求,包括检测故障、隔离功能块和支持重启这些功能块。检测机制看起来很熟悉,就像投票系统一样,但这种熟悉可能会产生一些误导。每一种都遵循某种形式M / N冗余(MooN),根源于工业自动化,其中最常见的从逻辑三模块冗余(TMR)的角度来看可能有点奇怪。1oo2D是一种常见选项,其中一个输入必须按诊断(1oo2D中的D)确定的那样正常工作,以便继续安全操作(或可能切换到紧急操作),或者2 oo2d两个输入必须正常工作,否则触发切换到紧急操作。2oo3是TMR,但同样,是在输入的正确性信号上,而不仅仅是在逻辑层面上。

这种需求从何而来?只要车里有一个复杂的,可能是人工智能支持的SoC。即使在今天装有ADAS的汽车上,也有很多地方——例如视频、雷达和超声波传感器。随着自动化水平的提高,将会有更多的传感器,每个传感器的数字逻辑都具有相当的复杂性,以“理解”现实世界的模拟输入。记住,在这些系统中用于识别的AI本质上是概率性的;在这个方向上已经取得了惊人的进展,但该方法本质上是不确定性的,我们知道它在现实环境中可能会被愚弄,特别是由于训练中未被识别的偏差和不完整性。我们如何训练一个系统在它可能看到的每一种可能的情况下做出适当和安全的反应?补偿这些系统的概率性质的一种方法是在不同数据集上训练的并行AI子系统之间建立冗余。在这些子系统中,仍然需要冗余/投票,并可能根据情况采取紧急备用行动。

最终,每个子系统都必须与中央融合和决策处理器通信。总之,这是许多潜在的故障点,因此许多半导体器件将需要支持故障安全操作。如果只有一个雷达传感器故障,中央大脑可能会根据该传感器的冗余策略,决定切换到紧急操作,首先警告附近的汽车给它一个更宽的泊位,然后减速并小心地移动到一个安全的地方,在那里它可以停下来。

SoC互连在帮助管理这一安全级别方面的相关性是什么?由于SoC中的所有子系统都通过片上网络(或可能不止一个NoC)连接,因此这种互连对于管理这种新的安全级别至关重要,包括连接到MooN-checking逻辑,观察和检查子系统交换的数据,以及在子系统出现故障并需要重新启动时隔离子系统。在上面的例子中,一个SoC可能支持基于视频、静态图像和雷达流的本地捕获和识别,在这种情况下,故障操作行为需要子系统冗余、智能故障检测和必要的选择性恢复。

新的ISO/PAS 21448标准,定义预期功能的安全性(SOTIF),超越了我们更熟悉的ISO 26262,涵盖了这些系统级考虑因素变得重要的领域。新标准的摘要指出,“它旨在应用于预期功能,其中适当的态势感知对安全至关重要,并且态势感知来自复杂的传感器和处理算法;特别是紧急干预系统(如紧急制动系统)和高级驾驶辅助系统(ADAS)……我们应该期待看到这些新的更高级别的要求,对汽车应用SoC设计的期望提出越来越高的要求。



留下回复


(注:此名称将公开显示)

Baidu