精品译文 | 软件核心自检是ASIL计划的强制性要求吗？

卫斯理

发布于 2023-11-6 14:08

浏览

0收藏

精品译文 | 软件核心自检是ASIL计划的强制性要求吗？-汽车开发者社区

译文软件核心自检是ASIL计划的强制性要求吗？

原文 : Is Software Core self-test mandatory for an ASIL program

译文审核：刘辉

➡本文主要内容分为5个部分（约8556字，20分钟阅读）

这是汽车安全领域的一个常见问题，特别是对于ASIL B级别的项目。即使在安全行业专家中，对这个问题也有相互矛盾的答案，每个答案都基于自己的理由。在这篇文章中，我们提供了一个背景、什么是核心自检以及为什么从功能安全的角度需要它。

背景

通常情况下，当我们开发一个需要符合ASIL标准的项目时，选择符合ISO 26262标准的微控制器是最先进的。通过ASIL认证的微控制器是按照ISO26262规定的硬件开发流程开发的。它们还采用安全机制来检测、纠正或防止（如果可能的话）系统性和随机性故障。这些安全机制提供了足够的故障诊断覆盖率，并使微控制器能够实现足够低的FIT率，以便集成它的项目可以满足其所需的FIT。通常，控制器提供ECC、奇偶校验、CRC、内存保护单元、写保护寄存器、外设锁、时钟监督、电压监督、外设自检等诊断机制。为了检测CPU内核中的故障，ASIL D微控制器广泛使用双Lockstep处理来实现最大的诊断覆盖率。然而，对于ASIL B控制器，广泛使用的方法是依靠软件来检测CPU核心中的故障。因此，在ASIL B控制器的安全手册中，供应商通常对项目开发人员提出要求，即必须在程序中集成Software Core自检。

什么是软件核心自检？

软件核心自测试(SoftwareCore，简称SBST)是半导体行业中被广泛称为的一种安全机制，用于检查CPU内核的正确运行。它检查处理器各个组件的正确功能。处理器的各种组件包括：

● 功能计算组件——对数据执行特定的算术和逻辑操作——如算术和逻辑单元（ALU）、浮点单元（FPU）、乘法器、移位器、除法器等

● 其他功能部件，如存储器保护单元，中断控制器等

● 互连组件——互连各种处理器组件并使数据流通过处理器——如多路复用器

● 控制组件——控制处理器核心内的指令/数据流，如处理器控制单元，或实现指令获取和内存握手的内存和数据控制器

● 内部处理器寄存器（系统寄存器、通用寄存器）

隐藏组件——在处理器架构中可用以提高其性能，如流水线逻辑、分支预测组件、指令和数据缓存

核心自检的目的是检测处理器核心的结构固定故障。这是一种非侵入性的测试CPU的方法，目的是在项目操作期间连续运行，以及项目的主要功能。也就是说，如果你正在为一个项目设计软件，你会把核心自我测试作为一个SW组件，它会在后台任务中循环运行。从半导体行业的角度来看，SBST是一个伟大的低功耗，低成本，高度灵活和有效的替代其他传统的处理器IC测试方法，因此，人们对如何充分利用它来降低制造和现场测试的成本和时间越来越感兴趣。

在Core自检软件中，执行各种测试模式来测试CPU的不同组件。测试模式不过是来自CPU指令集体系结构的一系列指令。对于每个测试模式，响应都以签名的形式计算。将这些计算的签名与在开发时预先计算并存储在ROM中的预期签名进行比较。如果存在签名不匹配，则将其视为使用测试模式测试的CPU特定组件出现故障的指示。由于故障是不可修复的，必须采取安全状态。

简单来说，Software Core自测使用各种数据处理指令（逻辑、移位、比较、算术、浮点运算等）执行详尽的计算，以确保ALU和FPU正常工作。它执行分支指令、加载/存储指令等，以确保寄存器的正确运行。它执行与中断相关的指令，以确保中断控制器的正确运作。

由于软件必须对指令集进行详尽的处理，核心自测试软件被开发为汇编语言例程。它最好是由CPU核心供应商自己开发，因为他们对Core有最好的了解。当然，没有人会像他们一样了解核心。几家微控制器供应商提供自己的自我测试库。ARM还提供了自己的测试库来验证其核心。

由于Core自测试是在运行时循环执行的，因此它被设计为一系列小的测试模式或模块，可以单独或作为一个小组执行，以便具有最小的性能开销。

在决定这些测试模式方面，CPU供应商使用许多不同的策略进行自测设计。指令根据其特性（例如算术指令、逻辑指令）、测试的CPU组件、两者的组合或其他可能的方式进行分组。关键问题是“如何有效地测试处理器内的各种组件、控制路径和数据路径，以便在尽可能小的自测代码中实现尽可能大的诊断覆盖率？”

如何确定程序中是否需要软件核心自检？

从“安全”的角度来看——如果软件核心自检为CPU故障模式提供的诊断覆盖率对降低CPU核心的FIT率有显著贡献，则需要进行软件核心自检，因此，微观的匹配率，这最终导致能够实现该项目所需的匹配。

换句话说，如果软件核心自检对改善微观的FIT的贡献足够显著，以提高项目的整体FIT，并使其达到所需的数字，则需要进行测试。

如果项目已经能够通过技术安全要求中定义的现有安全机制满足其FIT目标，我们认为将软件核心自检集成到项目中不是强制性的。

或者，如果SoftwareCore自我测试的诊断覆盖率很低，在某种意义上，它没有足够地减少FIT(例如，对于100 FIT的FIT目标，它只会减少<2%，~2 FIT)，那么您可能需要考虑其他方面，比如工程工作量、成本等等，以决定是否要继续下去。

有些情况下，微型供应商不提供软件核心自我测试。或者核心测试解决方案可用，但其对CPU故障的诊断覆盖率不可用或不能明确确定。例如，让我们假设自测解决方案不是由微型供应商开发的，而是由一级或二级组织中的SW团队开发的。在这种情况下，不可能确定诊断覆盖率，因为第1/2层没有CPU核心故障模式或指令集架构的知识。这样的解决方案不应该与任何声称它降低了产品的FIT的说法结合在一起。

从“软件”的角度来看，必须考虑的方面是自测试解决方案对整个系统的约束及其集成需求。例如，组件需要多少RAM、ROM？需要花费多少CPU时间？自检的执行是否会以任何方式干扰或限制正常的应用程序？通常情况下，自测解决方案保持RAM ROM占用空间和CPU运行时间非常低。

最先进的论证

最先进的技术是指在某一特定时间点达到的最高发展水平（即技术解决方案、流程等）。Software Core自测试被认为是ASIL B的最先进技术，因为它已经在几个ASIL B甚至ASIL A项目中部署和运行。根据德国法律，汽车生产商一般对产品故障造成的人身损害承担赔偿责任。如果故障无法通过现有技术检测出来，则排除责任。（德国关于产品责任的法律，资料来源：https://iclg.com/practice-areas/product-liability-laws-and-regulations/germa-ny）中选择所需的构件。因此，一些安全行业专家强烈要求为ASIL波段甚至ASIL-A项目提供核心的自测试SW，而不管OEM是否要求HW度量标准。