multicore - 是否有支持锁步处理器的标准？

Question

想问一下在SW级支持Lock-step(锁步，lock-step)处理器

据我所知，在 AUTOSAR-ASILD 中，锁步处理器用于容错系统如下场景。

1. 一个处理器的输入信号被复制到另一个处理器(它的锁步对)。

2. 比较来自两个不同处理器的输出信号。

3. 如果两个输出信号不同，则产生陷阱。

我认为如果有生成的陷阱，那么这个生成的陷阱应该在SW级别的某个地方处理。但是，我找不到此处理的任何标准。我已经阅读了 AUTOSAR 中指定的 SW 主题中的一些错误处理，但我找不到任何令人满意的答案。

所以，我的问题总结如下。

• 在 AUTOSAR 或其他标准中，处理锁步陷阱(SW-C 或 RTE 或 BSW)的正确位置在哪里？
• 在 AUTOSAR 或其他标准中，处理锁步陷阱(RESET 或 ABORT)的正确操作是什么？

谢谢。

Answer 1

这里涉及多个概念，来源不同。

ASIL 级别由 ISO 26262 定义。ASIL-D 是最高级别，使用锁步 CPU 是整个系统实现 ASIL-D 合规性的常用方法之一。 Autosar 没有定义如何达到 ASIL-D 或任何 ASIL 级别。从 Autosar 的角度来看，锁步将是 MCU 驱动程序的一个实现细节，而 Autosar 不需要 MCU 支持锁步。特定锁步实现的工作方式(是否在每条指令后比较输出等)取决于硬件，因此您可以在相应的硬件手册中找到这些答案。

相应地，一些决定必须由系统工作人员做出，包括功能安全专家。在锁步失败时如何处理的决定就是这样一个决定——你如何应对锁步陷阱应该在系统级别定义。这也不是由 Autosar 定义的，尽管最合理的选择是在保存一些有关错误的信息后重置您的微 Controller 。

至于陷阱应该在 Autosar 堆栈中的什么位置处理，这也是一个实现决定，尽管合理的选择是在 MCAL 级别发生这种情况——在某种程度上，在这里讨论级别甚至是有意义的，因为陷阱将在中断/陷阱上下文中运行，而不是在正常的操作系统任务上下文中运行。通常，陷阱的优先级高于任何中断，而且通常不可能在软件中禁用陷阱。陷阱将由一些例程处理，这些例程由操作系统以与注册 ISR 相同的方式注册，因此您希望在用于操作系统配置的任何工具中配置陷阱处理程序。锁步陷阱可能(再次，取决于硬件)被认为是不可恢复的陷阱，这意味着陷阱处理程序最终应该触发重置。调用标准 ShutdownOS() 函数可能是合理的。