I'm working on a safety system that requires me to implement 2oo3 voting. I roughly have an idea of implementing this using state machines using function pointers. Assume there are 3 systems, A B C. With respect to A, C is left system and B is right system With respect to B, A is left system and C is right system With respect to C, B is left system and C is right system
For every decision that a system takes,it shall cause the function pointer to point to the "exchange data with left system" function. After data is sent to the Left system it shall point to a dummy function and wait for the Left system to reply.
When the Left system replies and its decision(left system) also agrees with decision made by the system(my system),it shall proceed to the next state. If it disagrees it shall repeat the same with "exchange data with right system" and proceed.
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??
Is the approach to a 2oo3 implementation as above ok or is there something else to be taken care of?
Are there any other approaches to implementing a 2oo3 architecture(No external comparator for decisions made by each system. That is, each uC shall form a decision itself and consult its decision with the other 2.It will not place its decision in an external comparator(ex:shared memory, fpga based comparator etc) for access and comparison by the other 2 systems)??
Please forgive me if i have approached it wrongly. Im a newbie to this.
(Note:The 3 systems have only microcontrollers)
UPDATE: Some Useful points were added by @Lundin here - State Machine design with no function pointers
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??
Where did you get that idea from? There is nothing in any MISRA-C standard that forbids the use of function pointers. MISRA-C barely mentions function pointers at all. The only thing MISRA-C does not allow is wild casts between function pointers and regular pointers, since that invokes undefined behavior.
The de facto standard way of implementing state machines is usually with a state variable, such as an enum, which points out the index in an array of function pointers. Here is a typical example, which at a brief glance seems to be 100% MISRA compliant.
Is the approach to a 2oo3 implementation as above ok or is there something else to be taken care of?
Nobody can tell without knowing your requirements. Usually when designing such safety-critical systems (majority voter), you want the actual "vote" to be located in hardware outside the CPUs though, since the whole purpose of it is to protect against malfunctioning sub systems/CPUs. (The "voter" hardware itself may be supervised in turn.) Therefore, there are some issues with your approach:
Main issue: if A polls B, but A itself has gone haywire, it will then "lie" about the vote cast by B. Essentially the corrupt node A would then gain 2 votes and the whole safety of the system will fail. The whole purpose of redundancy systems is to protect against processors/programs going haywire. If none of the involved CPUs/sub systems will never go haywire, why would you need the majority voter to begin with? What is the failure you are trying to protect yourself from?
If A polls B for some vote and B never responds, or responds with nonsense, then what? This scenario needs to be stated in your specification. Timeouts, error detection, behavior upon error etc etc.
Also consider: "majority voter" is some old 80s buzzword technique. It may or may not make sense: it may improve safety or it may be complete nonsense. Be aware of designing in false safety and be aware of dangerous "safety" standards blinding preaching to use majority voter without knowing the specifics of your system.
The "SIL" 61508/26262 standards might be particularly dangerous to blindly trust here, as they lack rationale/modern sources for recommending "majority voter". See for example IEC 61508-7 A.1.4, it's complete nonsense: sources are technical papers only available in German, from the 80s. Laugh or cry?
Applying common sense is much more important than the contents of those standards!
Why would you ever want to use 2 out of 3 in a safety-critical system? That's 33% of the system failing, why would you wish the system to continue running in such a scenario? In many systems 33% of the system failing would be rather catastrophic... Similarly, a "diagnostic coverage" of 66% would be considered extremely poor in many systems.
The whole safety system design really depends on what is considered as the safe state and what to do upon critical failure. Is the safe state "stop everything" (typical industrial application) or is it "keep running/limping as well as you are able" (typical automotive/medical application).
Again, it all points back at the specification, which is extremely important to get right for these kind of systems.