3 ms·

Picking up one of these safety critical guidelines with the intent to raise your own quality standards as an engineer or team is certainly a great idea. There i

Picking up one of these safety critical guidelines with the intent to raise your own quality standards as an engineer or team is certainly a great idea. There is a lot of thought put into these documents and it's likely there are at least a few things you haven't thought about or perhaps you discount too quickly. That being said, this isn't a spec for good software. It's more of a spec for auditing software that has to work in a predictable way. The main consumers for this are, yes, software engineers and managers, but it's especially useful for framing quality assurance efforts. It's entirely possible to check all the boxes while still cranking out swill. For instance, I'd be surprised if the Volkswagen software that famously assisted in cheating on emissions tests was properly MISRA reviewed since a lot of the guidelines have to do with making sure the code does exactly what is intended, no more or no less. A full review with someone who could read code would either require the reviewer to ask "this is the code that cheats on the test, right?" or to be oblivious as to the full purpose for the code.

ChrisRR 7y ago
I agree with this point. The MISRA standard is mainly there to discourage use of the parts of C that most often cause faults. You can comply to MISRA C while ignoring some of the rules if you determine the risk to be justifiable. Ideally, these un-safe methods would be removed from the C language, but then that would be removing the low level ability from C that it is very suited for. So these guidelines exist to note the most dangerous parts of C, but it is still up to the developer to determine how to use it safely.
gmueckl 7y ago
Interesting point about MISRA and malicious rules hidden in the code. Something like the test stand discovery heuristic would be a state in a high level state machine somewhere if done properly (hopefully, this is an explicit state machine...). If it were, it would become obvious when trying to trace that state to requirements. However, modern engine control units have such complex requirements that complete verification against all of them is very unlikely in practice, especially in a third party audit.

ChrisRR 7y ago

I agree with this point. The MISRA standard is mainly there to discourage use of the parts of C that most often cause faults. You can comply to MISRA C while ignoring some of the rules if you determine the risk to be justifiable. Ideally, these un-safe methods would be removed from the C language, but then that would be removing the low level ability from C that it is very suited for. So these guidelines exist to note the most dangerous parts of C, but it is still up to the developer to determine how to use it safely.

gmueckl 7y ago

Interesting point about MISRA and malicious rules hidden in the code. Something like the test stand discovery heuristic would be a state in a high level state machine somewhere if done properly (hopefully, this is an explicit state machine...). If it were, it would become obvious when trying to trace that state to requirements. However, modern engine control units have such complex requirements that complete verification against all of them is very unlikely in practice, especially in a third party audit.