使用功能指针方法进行状态机设计的三选二投票
2 out of 3 voting using function pointer approach for state machine design
我正在开发一个要求我实施 2oo3 投票的安全系统。
我大致有一个使用函数指针使用状态机实现它的想法。
假设有 3 个系统，A B C。
相对于A，C为左系，B为右系
对于B，A为左系，C为右系
关于C，B为左系，C为右系
对于系统做出的每一个决定，它应该使函数指针指向"exchange data with left system"函数。
数据发送到Left系统后，指向一个dummy function，等待Left系统回复。
当左系统回复并且它的决定（左系统）也同意系统（我的系统）的决定时，它会进入下一个状态。
如果不同意，则应重复 "exchange data with right system" 并继续。
我的疑问是因为我不想使用标志来实现状态转换控制，使用函数指针的实现是否可以，因为 MISRA 2004 之后的任何地方都没有说不使用函数指针？？
上面的 2oo3 实现方法是否可以，或者是否有其他需要注意的地方？
是否有任何其他方法来实现 2oo3 架构（没有外部比较器用于每个系统做出的决定。也就是说，每个 uC 应自行形成决定并与其他人协商其决定 2.It 不会将其决定放在外部比较器中（例如：共享内存、基于 fpga 的比较器等）以供其他 2 个系统访问和比较）??
如有错误请见谅。
我是这个的新手。
（注：3个系统只有微控制器）
更新：@Lundin 在此处添加了一些有用的要点 -
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?
不知道您的要求，谁也说不准。通常在设计这样的 safety-critical 系统（多数选民）时，您希望实际的 "vote" 位于 CPU 之外的硬件中，因为它的全部目的是防止子 [=53= 发生故障]. （"voter" 硬件本身可能会依次受到监督。）因此，您的方法存在一些问题：
主要问题：如果A轮询B，但A本身已经失控，那么它将"lie"关于B的投票。本质上，腐败节点A将获得2票整个系统的安全性将失效。冗余系统的全部目的是防止 processors/programs 失控。如果所涉及的 CPUs/sub 系统中的 none 永远不会失控，为什么您需要多数投票者开始？您试图保护自己免受的失败是什么？
如果A投票给B，B不回应，或者胡说八道，那怎么办？这种情况需要在您的规范中说明。超时、错误检测、错误行为等
还要考虑："majority voter" 是一些 80 年代的流行语技术。它可能有意义，也可能没有意义：它可能会提高安全性，也可能完全是胡说八道。注意在虚假安全中进行设计，并注意危险的 "safety" 标准盲目布道，以便在不知道系统细节的情况下使用多数选民。
盲目信任 "SIL" 61508/26262 标准可能特别危险，因为它们缺乏 rationale/modern 推荐来源 "majority voter"。例如，参见 IEC 61508-7 A.1.4，这完全是胡说八道：来源是 80 年代以来仅以德语提供的技术论文。笑还是哭？
运用常识比那些标准的内容重要得多！
为什么要在 safety-critical 系统中使用三选二？那是 33% 的系统出现故障，为什么您希望系统在这种情况下继续 运行？在许多系统中，33% 的系统故障将是灾难性的......同样，"diagnostic coverage" 的 66% 在许多系统中将被视为极差。
整个安全系统的设计实际上取决于什么被认为是安全状态以及在严重故障时该怎么做。是安全状态"stop everything"（典型工业应用）还是"keep running/limping as well as you are able"（典型automotive/medical应用）
同样，这一切都指向规范，这对于此类系统来说是非常重要的。
我正在开发一个要求我实施 2oo3 投票的安全系统。 我大致有一个使用函数指针使用状态机实现它的想法。 假设有 3 个系统，A B C。 相对于A，C为左系，B为右系 对于B，A为左系，C为右系 关于C，B为左系，C为右系
对于系统做出的每一个决定，它应该使函数指针指向"exchange data with left system"函数。 数据发送到Left系统后，指向一个dummy function，等待Left系统回复。
当左系统回复并且它的决定（左系统）也同意系统（我的系统）的决定时，它会进入下一个状态。 如果不同意，则应重复 "exchange data with right system" 并继续。
我的疑问是因为我不想使用标志来实现状态转换控制，使用函数指针的实现是否可以，因为 MISRA 2004 之后的任何地方都没有说不使用函数指针？？
上面的 2oo3 实现方法是否可以，或者是否有其他需要注意的地方？
是否有任何其他方法来实现 2oo3 架构（没有外部比较器用于每个系统做出的决定。也就是说，每个 uC 应自行形成决定并与其他人协商其决定 2.It 不会将其决定放在外部比较器中（例如：共享内存、基于 fpga 的比较器等）以供其他 2 个系统访问和比较）??
如有错误请见谅。 我是这个的新手。
（注：3个系统只有微控制器）
更新：@Lundin 在此处添加了一些有用的要点 -
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?
不知道您的要求，谁也说不准。通常在设计这样的 safety-critical 系统（多数选民）时，您希望实际的 "vote" 位于 CPU 之外的硬件中，因为它的全部目的是防止子 [=53= 发生故障]. （"voter" 硬件本身可能会依次受到监督。）因此，您的方法存在一些问题：
主要问题：如果A轮询B，但A本身已经失控，那么它将"lie"关于B的投票。本质上，腐败节点A将获得2票整个系统的安全性将失效。冗余系统的全部目的是防止 processors/programs 失控。如果所涉及的 CPUs/sub 系统中的 none 永远不会失控，为什么您需要多数投票者开始？您试图保护自己免受的失败是什么？
如果A投票给B，B不回应，或者胡说八道，那怎么办？这种情况需要在您的规范中说明。超时、错误检测、错误行为等
还要考虑："majority voter" 是一些 80 年代的流行语技术。它可能有意义，也可能没有意义：它可能会提高安全性，也可能完全是胡说八道。注意在虚假安全中进行设计，并注意危险的 "safety" 标准盲目布道，以便在不知道系统细节的情况下使用多数选民。
盲目信任 "SIL" 61508/26262 标准可能特别危险，因为它们缺乏 rationale/modern 推荐来源 "majority voter"。例如，参见 IEC 61508-7 A.1.4，这完全是胡说八道：来源是 80 年代以来仅以德语提供的技术论文。笑还是哭？
运用常识比那些标准的内容重要得多！
为什么要在 safety-critical 系统中使用三选二？那是 33% 的系统出现故障，为什么您希望系统在这种情况下继续 运行？在许多系统中，33% 的系统故障将是灾难性的......同样，"diagnostic coverage" 的 66% 在许多系统中将被视为极差。
整个安全系统的设计实际上取决于什么被认为是安全状态以及在严重故障时该怎么做。是安全状态"stop everything"（典型工业应用）还是"keep running/limping as well as you are able"（典型automotive/medical应用）
同样，这一切都指向规范，这对于此类系统来说是非常重要的。