c - 使用功能指针方法进行状态机设计的三选二投票

Question

我正在开发一个要求我实现 2oo3 投票的安全系统。我大致有一个使用函数指针使用状态机实现它的想法。假设有 3 个系统，A B C。相对于A，C为左系，B为右系对于B，A为左系，C为右系对于C，B为左系，C为右系

对于系统做出的每一个决定，它应该使函数指针指向“与左系统交换数据”函数。数据发送给Left系统后，指向一个dummy function，等待Left系统回复。

当左系统回复并且它的决定(左系统)也同意系统(我的系统)做出的决定时，它将进入下一个状态。如果不同意，则应重复“与正确的系统交换数据”并继续。

我的疑问是因为我不想使用标志来实现状态转换控制，使用函数指针的实现是否可以，因为 MISRA 2004 之后的任何地方都没有说不使用函数指针？

上述 2oo3 实现的方法是否可行，还是有其他需要注意的地方？

是否有任何其他方法来实现 2oo3 架构(每个系统做出的决策没有外部比较器。也就是说，每个 uC 应自己形成一个决策并与其他 2.它不会将其决策放在一个外部比较器(例如:共享内存、基于 fpga 的比较器等)，供其他 2 个系统访问和比较)??

如有错误请见谅。我是这个的新手。

(注:3个系统只有微 Controller )

更新:@Lundin 在此处添加了一些有用的要点 - State Machine design with no function pointers

Answer 1

My doubt here is since i dont want to implement using Flags for state transition control,is implementation using function pointers ok cause nowhere does MISRA 2004 onwards say not to use function pointers??

你从哪里得到这个想法的？任何 MISRA-C 标准中都没有禁止使用函数指针的内容。 MISRA-C 几乎没有提到函数指针。 MISRA-C 唯一不允许的是函数指针和常规指针之间的野外转换，因为这会调用未定义的行为。

实现状态机的事实上的标准方法通常是使用状态变量，例如枚举，它指出函数指针数组中的索引。 Here是一个典型的例子，乍一看似乎 100% MISRA 兼容。

Is the approach to a 2oo3 implementation as above ok or is there something else to be taken care of?

没有人知道您的要求。通常在设计此类安全关键系统(多数投票者)时，您希望实际的“投票”位于 CPU 之外的硬件中，因为它的全部目的是防止子系统/CPU 发生故障。 (“选民”硬件本身可能会依次受到监督。)因此，您的方法存在一些问题:

• 主要问题:如果 A 投票给 B，但 A 本身已经失控，那么它就会对 B 的投票“撒谎”。从本质上讲，腐败的节点 A 将获得 2 票，并且整个节点的安全系统将失败。冗余系统的全部目的是防止处理器/程序失控。如果所涉及的 CPU/子系统中没有一个永远不会失控，为什么你需要多数投票者开始呢？您试图保护自己免受的失败是什么？

• 如果 A 投票给 B，而 B 从不回应，或者回应无意义，那怎么办？这种情况需要在您的规范中说明。超时、错误检测、错误时的行为等。

另请考虑:“多数选民”是一些 80 年代的流行语技巧。它可能有意义，也可能没有意义:它可能会提高安全性，也可能完全是胡说八道。注意在虚假安全中进行设计，并注意危险的“安全”标准，在不了解系统细节的情况下盲目宣扬使用多数选民。

“SIL”61508/26262 标准在这里盲目信任可能特别危险，因为它们缺乏推荐“多数选民”的理由/现代资源。例如，参见 IEC 61508-7 A.1.4，这完全是胡说八道:来源是 80 年代以来仅以德语提供的技术论文。笑还是哭？

应用常识比那些标准的内容重要得多!

为什么您会想要在安全关键系统中使用三分之二？那是 33% 的系统出现故障，您为什么希望系统在这种情况下继续运行？在许多系统中，33% 的系统故障将是灾难性的……同样，在许多系统中，66% 的“诊断覆盖率”将被视为极差。

整个安全系统设计实际上取决于什么被认为是安全状态以及在严重故障时该怎么做。安全状态是“停止一切”(典型的工业应用)还是“尽可能保持运行/跛行”(典型的汽车/医疗应用)。

同样，这一切都指向规范，这对于正确使用此类系统极为重要。