这篇文章是自动驾驶汽车:技术和趋势系列在汽车我们的话题库:系列文章．
你将学习:
- 什么是软件测试库?
- 诊断覆盖率在描述安全机制有效性方面的关键作用。
- 如何接近目标值。
今天令人惊叹的汽车系统背后的魔力，取决于一个复杂的设计挑战——功能安全。在2020年的一项调查中，41%的人手臂生态系统受访者认为，功能安全是实现大规模部署4级自动驾驶汽车的最大挑战。
如果功能安全仅限于少数尖端的汽车设计，那是一回事，但情况越来越不一样了。对于许多汽车应用而言，满足安全标准对于解决供应链中各种复杂程度的安全部署问题至关重要。
根据经验，临界度越高，司机对应用程序的控制越少，固有风险和相关的汽车安全完整性等级(ASIL)就越高。行业标准ISO 26262定义了四个ASIL级别，从最低的完整性级别到最高的完整性级别:ASIL A、ASIL B、ASIL C和ASIL D。
安全应用程序的驱动程序通常有更多的控制车辆,如车道监控和自适应头灯系统,或故障的后果并不严重,完整性需求往往更低(例如,ASIL B)。这是很多汽车系统设计主要是今天。
很多关于功能安全的讨论都集中在硬件设计和架构上，但是软件扮演着越来越重要的角色。事实上，随着硬件性能和效率的不断提高，越来越多的汽车设计将利用软件定义的概念。
适应这种不同软件概念的能力的关键是一个可靠的中间件或包含软件测试库(stl)的低级软件。这些测试集可以在系统启动时或运行期间运行，以检查底层硬件是否正确执行。
让我们简要地介绍一下stl以及利用它们实现与汽车安全相关的设计的方法。
定义和解决安全要求
stl用于测试硬件功能逻辑内的永久性硬件故障，IC或IP供应商可以将其开发为脱离上下文的软件安全元素(SW SEooC)。这些组件的开发没有考虑特定的目标车辆，而是基于使用假设。
在开发STL时，设计者必须考虑在一个或多个元素中发生的系统故障和随机硬件故障(rhf)。对于随机硬件故障，ISO 26262和其他功能安全标准为每个定义的完整性级别定义了几个硬件体系结构指标的推荐目标值。
必须实现硬件体系结构指标的这些目标，以合理的信心和定量的方式确认与安全相关的系统能够处理随机的硬件永久故障，而不会导致导致危险情况的系统故障。我们已经读过这样的例子，从电动滑板车因为软件故障而在没有任何警告的情况下突然刹车，到ADAS系统忽视识别道路上的自行车，导致碰撞。
评估诊断覆盖率
诊断覆盖率(DC)是用来表征检测和控制故障的安全机制的有效性的一个指标。这个指标是由安全机制检测和控制的硬件元件的故障率或失效模式的百分比。安全机制的数据中心直接影响硬件体系结构指标。STL的开发有四个步骤:
- 探索(对指标有最大影响的CPU安全相关领域)。
- 测试编写生成伪随机测试。
- 故障模拟来验证测试的质量。
- 签字(在整个CPU上运行完整的测试集，以证明实现了目标覆盖)。
在STL开发的最后，验证了范围定义的实现，并对STL的实际DC进行了测量或评估。
(设计)道路上的颠簸
这听起来相当简单;但是，有一个问题:硬件体系结构指标的目标值是在系统级定义的，必须为系统的整个硬件实现它们。如果你只是开发一个IC或IP核心，而这只是整个系统的一部分，那么ISO 26262对于如何接近目标值提供了很少的指导。设计者必须为IC或IP核指定他们的目标。
在为IP核或IC的安全部分设计安全机制时，设计者需要考虑，除其他事项外，安全机制应该覆盖哪些硬件块，以及该机制应该覆盖所有或只覆盖某些故障模式。基于软件定义的概念，即使使用相同的硬件，这些块和故障模式也可能不同。
如果使用stl作为一种安全机制，设计师可以将其分解，只应用stl的部分来测试与特定应用相关的块和失效模式。与其他基于硬件的解决方案相比，stl提高了系统的灵活性和效率，确保系统的调度能力最大化，以更高的整体性能执行其功能。
结论
随着自动驾驶电动汽车在全球范围内的发展，设计低功耗、高性能解决方案的竞赛也开始了。但如果不考虑功能安全性，不遵守适用的标准和方法(如ISO 26262)，这场竞赛就无法获胜。正如他们所说的，魔鬼就在细节中，而且通常围绕着这些标准的应用存在着困惑和误解。这白皮书有助于澄清并详细说明设计师在考虑和实现与安全相关的stl时应该采取的步骤。
更多信息请参阅自动驾驶汽车:技术和趋势系列在汽车我们的话题库:系列文章．
