MISRA C/C++ and adopted code: 5 ingredients for success
Modern embedded software projects tend to be complex and involve functionality that is expensive to develop in-house. As a consequence, there is increasing reliance on the use or reuse of “exogenous code” (i.e., code originating from outside the scope of the current project). If such code is meant to be reworked in the current project, then it must be treated as native code, i.e., code developed within the scope of the project.
In many cases, though, it is desirable and possible to reuse externally-developed code as is because, in its present form, it is fit for purpose and no changes are needed. In MISRA parlance, such code is called adopted code, to distinguish it from native code (both “adopted code” and “native code” are terms defined by MISRA). Of course, for the development of critical systems, it must be ensured that adopted code has been developed to a verifiable adequate level of safety and security. MISRA compliance of the overall project, along with all other software V&V activities, is one way in which this can be achieved.
Providing a defensible argument of MISRA compliance in the presence of adopted code, while often advantageous, comes with a number of challenges. Leveraging on several years of consultancy work, we are in position to provide you with 5 key ingredients for you to be successful in this endeavor.
1. Stick to MISRA Compliance:2020
Compliance to the MISRA guidelines is only marginally a matter of opinion: the applicable notions are defined in rather precise terms in the "MISRA Compliance:2020” document. Do not assume “exogenous code” and adopted code are synonyms: they are not. Moreover, adopted code cannot just be ignored or neglected in MISRA compliance.
2. Do not blindly trust adopted code providers
There is enough malpractice out there to justify a clear and unambiguous warning. You will find providers that are not able to provide any usable documentation regarding the compliance of their code to the MISRA guidelines. We have seen a case where, in the face of a "MISRA compliant" claim for their code, the suppliers could not even state which edition of the MISRA guidelines they referred to, let alone provide further documentation. You will find vendors that simply recommend disabling the MISRA checkers for all of their source code files, on the grounds that checking their files is unnecessary as the check was already done by them. It is clear that such vendors do not really understand what MISRA compliance is. In addition, and this is well known, you will find code generators that are dubbed "MISRA compliant" and yet generate code violating important MISRA guidelines: do not fall into the trap of believing that automatically-generated code can be assumed to comply until you have made the check yourself in the context of your project.
In general, our advice is to demand you get what you are paying for: if a claim with the word "MISRA" is made for software you are considering for inclusion, do make sure the claim is substantiated in conformity with the “MISRA Compliance:2020” document. If you cannot receive a satisfactory answer, look elsewhere.
3. Use multiple Guideline Re-categorization Plans and Deviation Permits
Code that can be legitimately considered as adopted, can indeed be subject to a simplified MISRA compliance process. For this we recommend using separate Guideline Re-categorization Plans (see MISRA Compliance:2020 for details): one for the native code, and one or more for different parts of the adopted code. In addition, a set of carefully-designed deviation permits, either originated from MISRA or developed in-house, can greatly simplify the job. Make sure you do not overlook the "MISRA C:2012 Permits” document, especially when working with automatically-generated code.
4. Use a high-quality static analysis tool
"Switching checkers off" or "excluding source files from the MISRA check" is a kind of nonsense that, unfortunately, is heard far too often. A MISRA violation may arise from the interaction between several code areas, some of which may be in adopted code while others may be in native code. Properly dealing with these situations requires sophisticated reporting features and flexible configuration mechanisms that only high-quality static analysis tools possess.
5. Have an expert consultant ready on call
If you are following MISRA Compliance:2020 (in particular Section 7.1 on "Staff competence") your personnel will have received proper, formal MISRA training. Nonetheless, as mentioned earlier, dealing with adopted code — including choosing among the offerings of different providers — is challenging. Investing in qualified consultancy services immediately and invariably pays off.
In conclusion, let us quote MISRA Compliance:2020: "The impact of adopted code on the integrity of a system must never be overlooked or assumed to be benign." We have seen examples in the industry where it was claimed that you could simply neglect any sort of MISRA compliance or alternative process on all exogenous code (whether used in modified or unmodified form). This certainly may save a lot of time, but if you work in a critical sector, the consequences are potentially catastrophic, for your company and for you personally. Our advice is, as usual: do the right thing, make sure, for all your projects, you have a rigorous argument for MISRA compliance and sleep well at night.
Book a free MISRA strategy call
Are you managing a project with a MISRA compliance requirement and where the presence of adopted code is substantial? Book a free strategy talk with our experts!
Join our LinkedIn community to keep up to date with all our news. Roberto Bagnara, PhD is CTO of BUGSENG, a leading provider of solutions and services for static code analysis. He is also a member of the ISO/IEC JTC1/SC22/WG14 - C Standardization Working Group and the MISRA C Working Group.