The MIRSA standards are well known and established programming guidelines for different flavours of the C and C language family. Its mission: "provide world-leading, best practice guidelines for the development of both embedded control systems and stand-alone software" (www.misra.org.uk). The guidelines are not limited to safety but also cover aspects of “static analysis security testing” (SAST). For more on this, read MISRA C and MISRA C - more than just safety by Dr. Stefan Staiger-Stöhr.
For a long time, MISRA C:2004 and MISRA C :2008 were the first of choice in many software development projects. As the programming languages evolved along with hardware, development paradigms, updates to the standards are required to ensure that new language features can safely and securely be used in modern development. With MISRA C:2012 and its amendments, updates to the C language were reflected. As for C the now “old” standard referred to C from 2003, and the long awaited new MISRA C guidelines support C 17 features.
Sample screenshot – MISRA C :2023 violations overview for an open source project in Axivion’s web frontend
Now that this new standard has been released and already has been implemented in Axivion Suite, we have started collecting experience “in the field”. The first feedback on aspects such as “decidability” (you probably know, just as a reminder, it means more rules try to be more clear and avoid the possibility of “uncertain” findings) and “practical relevance” (applicability in safety projects using modern C ) has been very positive. And I am sure there will be further optimizations in the upcoming months - both to the implementation as well as to the standard’s interpretation.
However, while MISRA rule sets are a great and necessary starting point, there are more aspects to consider, e.g.
- How do we migrate our “running” projects (e.g. with MISRA C :2008 or AUTOSAR C 14 rulesets)?
- How do we want to deal with “mixed sources” projects? Can we migrate step by step or in a “big bang”?
- What is the best way to deal with new findings in legacy projects?
- What set of metrics could and should be applied to migrations, overall project quality?
- How do we manage higher level project aspects such as “software architecture”, “freedom from interference”?
- To what extent can we combine static and dynamic testing to reduce workload (in particular for “undecidable” rules)?
There are no answers to these questions which work for all projects. The questions have to be addressed individually, taking into account the context of the specific development project. But have you actually ever considered any one or even all of these questions?
If not, I urge you to do so. You will be surprised how looking beyond “only” complying with the MISRA standard will drastically improve your code quality. We have the tools and also the experts to help you find the best answer to the above questions and switching to the new standards isn’t as complicated as you might think. In his blog post Dr. Sebastian Krings gives you a brief overview of what you need to keep in mind for a successful MISRA migration strategy.
And if you have thought about this, I would be very interested to hear your thoughts. What did you do and how? What was the most challenging part? Do you still have questions or concerns? I would love to hear from you and can help you take your project to the next level.
For more information about Axivion Static Code Analysis and Axivion Architecture Verification, please see Axivion.
To schedule an appointment for a free demo, please contact us.
Join Our Webinar and Learn More
Join our webinar on "MISRA C :2023 - Applying the new standard in C projects" and learn more about Axivion's MISRA checker.