Feature: Software and tools
MISRA C in practice: Software standards, tools and real-world
W
implementation lessons By Anthony Wall, Senior Engineer, ByteSnap Design The gap between functional code
hen you’re responsible for an embedded system controlling a vehicle
travelling at 70mph or more, simply saying “it works in testing” is nowhere near good enough. I learned this early in my career as a
technical engineer at ByteSnap Design. Over the past few years, our team has been heavily involved in automotive development projects for Tier 1 suppliers to manufacturers such as Ford and Toyota. Our work on infotainment systems, automotive ECUs and other safety-critical embedded software has shown what MISRA C compliance truly demands, and the high cost of getting it wrong.
30 March 2026
www.electronicsworld.co.uk
and certifiable code is wider than many developers expect. The MISRA C coding standard provides a bridge, but crossing it requires understanding not just the rules, but why they exist and how to apply them.
Three levels of compliance that nobody tells you about MISRA C compliance isn’t binary. There are three distinct levels: syntactic compliance, architectural compliance and demonstrable safety. Passing the first doesn’t guarantee the others. Syntactic compliance is the first
level and the easiest, using tools like Cppcheck, PC-Lint or Helix QAC to flag rule violations like unsafe pointer arithmetic, unchecked array bounds, or implicit type conversions that can
lead to undefined behaviour. Free versions handle basic checks reasonably well, but for safety-critical projects, we recommend premium tools like Cppcheck with its MISRA C plugin, typically costing £1,800 to £2,000. Premium tooling can help teams
produce more reliable C code in safety-critical environments such as automotive, whilst cost-effective options can still support smaller teams or early stages of adoption. The second level – architectural
compliance – goes deeper, involving design choices for safe software. You can pass syntactic checks yet still have unsound architecture that fails in real world scenarios. Demonstrable safety is the final
hurdle: proving the software is safe under all conditions. This is what certification
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48
