Bringing Existing Code into MISRA Compliance: Challenges and Solutions

Bringing an existing codebase into MISRA compliance is known to be a difficult, risky and time-consuming task. Yet, when a product needs a functional safety certification and rewriting the software is out of question, this is a necessity. Such an endeavor requires facing multiple tradeoffs and, consequently, lots of experience both on the codebase and on MISRA. The choices between deviating the guideline, and the (often, many) ways in which code may be changed and deviations may be formulated, are tough and with consequences that are not immediately evident. While, clearly, a project undertaking MISRA compliance at a late development stage is likely to rely on deviations more than other projects, one should take into account the interdependence among MISRA guidelines and that such deviations have to be rock-solid (as they will inevitably catch the assessors' attention). In this paper, we illustrate our experience and the several lessons learned while undertaking MISRA compliance work in several projects. This includes closed-source projects (which cannot be disclosed for confidentiality reasons) as well as open-source projects, most notably the Zephyr RTOS and the Xen hypervisor, both used in many embedded systems.