如果我们真的想自主车辆,安全标准景观通过/失败清单之外的需要发展。
我参加了几个会议在手臂TechCon,今年的第一个安全如何演变的基于平台的体系结构与safety-aware IP和第二个教训安全,尤其是行业和标准是如何适应的更大的挑战在无人驾驶,这显然超出了纯粹的ISO 26262的功能安全的目的。这里我想进入一些细节在这个范围的标准,因为我们需要了解更多关于这些自动驾驶汽车的如果我们要认真对待。
让我们先从一些进化功能安全的要求,由ISO 26262的主题。标准本身不指定应该使用安全机制,但它需要(在ISO 26262 - 2),您需要提供可靠的证据表明,您提供的安全机制是充分的。这是一个小小的转折——负担在你(和你的客户和供应商)来演示功能安全不管你的设计可能会变得多么复杂。
他们变得更加复杂。我们现在有在安全至上的系统设计(ASIL D)中,并不是所有的IP组件单独见面,期望和不能被合理预期将达到这一水平。如何在ASIL D如果系统部分ASIL水平较低,甚至可能是安全漠不关心(QM) ?答案在于能够隔离并定期测试这些组件,如果他们没能达到预期,让他们孤立。这也导致一个完全的概念ASIL D安全岛可以启动测试和报告等问题回到命令枢纽在车里,能够支持操作失败的反应。
这个诊断框架的另一个机制是检测错误通过超时请求确认在公共汽车上。相当合理,这是一个很好的方法来寻找错误的组件。ISO 26262 - 1和图5描述了故障处理时间间隔(FHTI),通常在检测故障,当然没有指定应该如何完成,这就像不指定隔离和安全机制。这些都是设计反应记录需求。
在Arteris IP弹性包我们支持所有这些功能。梦想芯片技术在早前面板谈论用我们的NoC技术构建一个安全岛,IPs自然之间提供网络和管理IP网络隔离和独立测试。他们还计划和测试超时请求/响应通过我们的NoC / IP安全特性。
到目前为止,这是纯粹的功能安全。ISO / PAS 21448”应有的安全功能(SOTIF)”是ISO 26262的后续的目标定义在系统级别应该发生什么时,除了系统或发起者发生随机错误——考虑软件和ML当然,而且滥用或环境因素。安全问题在这里不一定是由系统故障;他们可以由场景,没有考虑自主驾驶系统的设计。一个简单的例子可能是行驶在一个冰冷的道路;SOTIF要求这些条件包括威胁建模和降低风险。
SOTIF当然是一个正确的方向开始,但我的感觉是,目前太哲学在工程设计和验证可行的做法。在后续的版本中我们将看看会发生什么。
另一个非常有趣的标准,由美国保险商实验室(UL)是UL 4600。我喜欢这个,因为它定义了一个标准的照顾一个自治车辆的设计,专注于开发和维护深思熟虑下套管安全。这些必须面对非常有条理的文档:
UL 4600不提供一个简单的通过/失败清单并没有绝对的标准应考虑安全或什么样的测试应该运行,但它坚持安全情况下目标的全面列表和索赔必须证明证据所支持。和一个可能的例外列表/例不测试必须包括(进化)。至少这是非常可审计的。我认为这是一个重要的步骤。
ISO 26262、ISO / PAS 24148 (SOTIF)和UL 4600是三个主要的标准,我认为今天自主驾驶很重要。对于半导体工程师,ISO 26262今天仍然是最可行的。正在取得进展在系统级别虽然仍有很多工作要做更准确确定我们应该如何定义安全自主车辆,那么我们应该如何实施和评估安全。
|
|
|
|
|
|
|
|
谢谢你这广泛的话题的简短的摘要。很说明问题。完全同意。