当今惊人的汽车系统背后的是各种复杂的设计挑战，其中功能安全性至关重要。在2020年的一项调查中，41％的Arm生态系统受访者将功能安全视为实现大规模部署L4自动驾驶汽车的最大挑战。
如果功能安全性仅限于一些尖端的汽车设计，那是另外一回事，但事实并非如此。对于许多汽车应用而言，遵守安全标准对于解决在复杂程度不同的整个供应链中高效，一致地部署安全性问题至关重要。
根据经验，关键程度越高，驾驶员控制得越少，固有风险和相关的汽车安全完整性等级（ASIL）越高。行业标准ISO 26262定义了四个ASIL级别，从最低完整性级别到最高完整性级别：ASIL A，ASIL B，ASIL C和ASILD。
对于通常需要驾驶员对车辆进行更多控制的安全应用（例如车道监控和自适应大灯系统）或故障后果不严重的情况下，完整性要求通常会较低（例如ASIL B）。今天，这仍然是许多汽车系统设计的重点。
关于功能安全性的许多讨论都集中在硬件设计和体系结构上，但是软件扮演着越来越重要的角色。实际上，随着硬件性能和效率的不断提高，越来越多汽车设计将利用软件定义的概念。
容纳这种多样的软件概念的能力关键是可靠的中间件或包含软件测试库（STL）的低级软件。这些测试集可以在系统启动或运行期间运行，以检查基础硬件是否正确执行。
让我们简要浏览一下STL和利用它们的方法，以实现汽车中与安全相关的设计。
定义和解决安全要求
STL用于测试硬件功能逻辑中的永久性硬件故障，并且可以由IC或IP供应商开发为独立的软件安全元素（SW SEooC）。这些组件的开发无需考虑特定的目标车辆，并且基于使用的假设。
在开发STL时，设计人员必须考虑在一个或多个元素中发生的系统性故障和随机硬件故障（RHWF）。对于随机的硬件故障，ISO 26262和其他功能安全标准定义了几个硬件体系结构指标，并为每个定义的完整性级别建议了目标值。
必须实现这些硬件体系结构指标的目标，以合理的信心和定量的方式确认与安全相关的系统可以应对随机的硬件永久性故障，而不会引起导致危险情况的系统故障。我们读过许多示例，从电动踏板车突然由于软件故障而无预警制动到ADAS系统忽略了识别道路上骑自行车的人而导致碰撞等。
评估诊断范围
诊断覆盖率（DC）是用于表征安全机制检测和控制故障的有效性的一种度量标准。此度量标准是由安全机制检测和控制的硬件元素或故障模式的故障率的百分比。安全机制的DC直接影响硬件体系结构指标。
STL开发涉及四个步骤：
探索（对度量标准影响最大的CPU安全相关区域）。
测试编写以生成伪随机测试。
故障仿真以验证测试质量。
签名（在整个CPU上运行全套测试，以证明达到了目标覆盖范围）。
在STL开发的最后，验证范围定义的实现，并测量或评估STL的实际DC。
曲折的道路
这听起来相当简单。但是，还有一个折衷：硬件体系结构指标的目标值是在系统级别定义的，必须为系统的整个硬件实现。如果仅开发仅构成整个系统一部分的IC或IP内核，ISO 26262几乎没有提供有关如何达到目标值的指导。设计人员必须以IC或IP内核指定目标。
在设计用于IP核或IC的安全部分的安全机制时，设计人员需要考虑安全机制应覆盖哪些硬件模块，以及该机制是否应覆盖全部或仅某些故障模式。基于软件定义的概念，即使使用相同的硬件，这些模块和故障模式也可能会有所不同。
如果将STL用作安全机制，则设计人员可以将它们拆分开，而仅应用STL的一部分测试与特定应用相关的模块和故障模式。 与其他基于硬件的解决方案相比，STL提高了系统的灵活性和效率，从而确保了最大化的调度能力，使系统能够以更高的整体性能执行其功能。
结论
在全球范围内实现自动驾驶电动汽车之旅的过程中，设计可提供低功率，高性能解决方案是关键。 但是，如果不考虑功能安全性并遵守适用的标准和方法（例如ISO 26262），就无法赢得这场竞赛。正如他们所说，魔鬼在细节中，围绕这些标准的应用常常会造成混乱和误解。