Delivering safe, secure and reliable code is the definitive challenge for modern automotive software development. With the explosive growth in connected vehicles and autonomous functions, not to mention breaking new ground in EV technologies, automotive OEMs are squeezing more features onto their processors and forcing more data through their peripherals.

The MISRA C standard is adapting to these technological forces. Long the guiding force behind automotive software development, the MISRA C Working Group has taken years of real-world research and development to address modern software complexities in updates to the standard. With new guidance on multithreading and atomic types in support of C11 and C18 (MISRA C:2012 Amendment 4, known as AMD4) and the consolidation of previous versions of the guidelines into MISRA C:2023, developers get essential guidance for their efforts to reduce the occurrence of unexpected and undefined behaviors in their automotive code.

Why C programmers need MISRA

Software safety, security and reliability are critical goals in developing automotive systems. Engine control units must behave only in ways the manufacturer intends and connected infotainment systems must be hardened against malicious threat actors seeking to exploit cybersecurity holes.

While immensely popular among embedded development teams, the C language allows developers to control application behavior and memory in ways that could compromise their code. The ISO standards that define the language (ISO/IEC 9899:2011 and 2018, colloquially known as “C11” and “C18”) do not provide a complete specification of runtime intention, leaving some aspects up to the implementation to decide.

As a result, there are non-deterministic components to the C language that give functional freedom to developers in ways that could pose risks to the system:

• Undefined behavior – the C standard does not specify a requirement
• Unspecified behavior – the C standard allows for two or more possibilities and does not specify requirements for which one(s) is used
• Implementation defined – the compiler and runtime are free to define their own behaviors and must document the behaviors themselves

Developers are proficient at exploiting such behaviors to extract higher performance from their applications. One example is leaving variables of large array types uninitialized to avoid incurring the processor cost of the memset() function to zero-initialize storage (while undefined in the C standard, many compilers and static analyzers will flag this).

It’s the unpredictable consequences of these loopholes that the MISRA C Guidelines aim to eliminate. For example:

• Writing to a file stream opened as read-only, leading to potentially undesirable behavior
• Using recursive functions, leading to a potential stack overflow
• Accessing memory outside the bounds of a data structure, which could lead to a potential attack surface for hackers

The philosophy behind MISRA C

The MISRA C Guidelines restrict the C language to a predictable subset to meet the needs of safety- and security-critical systems. The intention of the rules and directives in the standard is to minimize or eliminate coding practices known to be hazardous and insecure.

A MISRA C rule is a source code requirement that is complete, objective and unambiguous. The guidelines further classify rules as decidable if they can be conclusively verified through techniques like static analysis and undecidable if no verification guarantee is possible. An example rule is:

“The value of an object with automatic storage duration shall not be read before it has been set.” (MISRA C:2012 Rule 9.1)

A MISRA C directive is a guideline that may be satisfied through code, processes, documentation or functional requirement. Directives can be subject to interpretation, and analysis tools may be able to assist in checking compliance. An example directive is:

“Any implementation-defined behavior on which the output of the program depends shall be documented and understood.” (MISRA C:2012 Directive 1.1)

MISRA C:2023 addresses the growing use of concurrency

With today’s automotive applications relying more on multiprocessor systems and multithreaded architectures, the MISRA Working Group released new guidelines in AMD4 and consolidated all prior editions in the MISRA C:2023 edition. Focused on the growing use of concurrency in embedded systems, AMD4 supports many new features introduced by the C11 and C18 standards.

Guidance on multithreading

AMD4 addresses concurrency issues not covered by the C standard by adding new rules and directives to restrict multithreading features to a safe subset. These guidelines cover critical elements of thread usage, such as:

• Restricting dynamic thread creation to foster more deterministic approaches to concurrency
• Ensuring threads are created before mutexes are linked to them
• Minimizing the risk of deadlocks and data races in the system
• Managing the safe use of thread objects and thread identifiers

Guidance on C atomic types

C11 introduced atomic types and operations that enabled automotive developers to manipulate data objects indivisibly, or without risk of interference by another thread, to avoid the chance of data races in multithreaded applications. AMD4 adds new rules and modifies some existing rules to address undefined behaviors in the C language that may compromise atomicity in the system:

• Ensuring the correct configuration of atomic types
• Preventing the unintended removal of atomicity when referencing atomic types through pointers
• Restricting the use of multiple atomic types in the same statement

MISRA C for the modern automotive software development

The AMD4 additions include other types of rules that restrict C language features known as problematic and minor updates to clarify existing rules and directives. These include restricting the use of small integer macros and certain use cases of designated initializers.

The most significant change from a process perspective is the consolidation of earlier MISRA C editions and the recent AMD4 enhancements into a single, comprehensive baseline. In one document, MISRA C: 2023 simplifies compliance and configuration management for existing users of MISRA C and eases entry for automotive software teams starting new projects.

By understanding and adopting the MISRA C Guidelines, automotive developers can improve the safety, security and reliability of their code while demonstrating a commitment to core business objectives. Such teams will find it valuable to deploy static analysis tools that rapidly and comprehensively check code for any deviations against the MISRA guidelines.

Article written by Mark Pitchford – LDRA Technical specialist
Published 18th January – Vehicle electronics

Read Published article here – Vehicle electronics