It would be easy to rush to reference the MISRA C standard, especially given that test tools are designed to highlight MISRA violations in C code. But whilst identifying and addressing violations flagged by an analysis tool may well be a significant challenge for individual developers, it represents only one part of the compliance process for the development team as a whole and it is vitally important to get the foundations right.

Stepping back from the detailed analysis of violations, it is easy to see bigger questions about the overall process. With MISRA’s document MISRA Compliance 2016 being updated in 2020 and also being made mandatory for MISRA C compliant developments, it is important to understand how the information highlighted by static analysis relates to the bigger picture of a MISRA compliant application.

Examples of MISRA Compliance principlesThe following five examples typify the principles outlined in the MISRA Compliance document itself, which reflect a little technical wisdom and a lot of common sense.

MISRA Compliance requires a documented software development processMISRA Guidelines are intended for use within the framework of a formal software development process. Such a process will ensure complete, unambiguous and correct software requirements, and that all and only those requirements are reflected by the artefacts created at each phase of the development lifecycle (Figure 1).

Figure 1: Structured development lifecycle is essential to MISRA compliance, as illustrated by the “Uniview” in the TBmanager component of the LDRA tool suite.

Not all MISRA Guidelines can be checked by analysis toolsEach MISRA Guideline is classified as either a rule or a directive. Typically, rules are sufficiently well defined to be checked by an automated tool, whereas directives are likely to be a little more subjective. For example. Directive 1.1 of MISRA C:2012 requires that “Any implementation-defined behaviour on which the output of the program depends shall be documented and understood”.

Some rules are labelled “Undecidable,” meaning that it is fundamentally impossible to have a method that can, in general, say for sure whether a violation is present or not. A tool might warn of the potential for a problem, or it may not. Either way, some level of manual intervention is required.It is also important to note that not all tools are the same. Some will claim more coverage of the rules than others, and some will be incapable of more subtle infringements. A tool showing “no violations” may really be saying “no violations, except the ones I’ve not spotted!” Tools help – they don’t do the job for you.

Guidelines are only useful if there is a plan for their enforcementFor most guidelines, the easiest, most reliable, and most cost-effective means for enforcement is to use a static analysis tool, the compiler, or a combination of the two. It is important to ensure that any tool to be used has been proven to be appropriate, and that its type and version are specified and fixed.There must also be enforcement plans in place for those guidelines that require some manual verification.“Deviation” is not a dirty wordFor any real-life embedded application, it is very likely that some violations will be unavoidable. The management of these violations must be authorized through a clearly defined process and supported by appropriate “deviation record” documentation if any claim of compliance for the resulting application is to be credible.

These deviation records need to include the guideline(s) violated, the justification for this/these violation(s), the circumstances under which the deviation applies, and where in the code base it applies.

Adopted code can’t be ignoredMuch of the documentation and many of the standards relating to functionally safe and secure embedded software starts from an assumption of a “green field” project. In real life, developers will be required to leverage in-house legacy code or third-party code such as device drivers, mathematical libraries, or graphical libraries.

Although it is usually impractical to retrospectively apply MISRA guidelines to such code, for MISRA compliance to be claimed it is important to ensure that this co-called “adopted code” cannot compromise the safety and security of the system as a whole.