Members can download this article in PDF format.
What you’ll learn:
- Practical challenges for applying MISRA and AUTOSAR coding requirements.
- The importance of the right development and tooling approaches.
- The key ideas behind MISRA Compliance, where the same thought process can be applied to AUTOSAR.
Modern automotive software has increasingly stringent requirements on safe and secure development. Besides development ECUs in classical domains such as powertrain, chassis, and body electronics, more advanced new systems are being developed such as digital cockpits, infotainment systems, autonomous driving systems, and connectivity units.
Standards such as ISO 262621 and ISO/SAE 214342 provide guidance to automotive organizations on a higher level regarding how to consider safety and security. However, more specifically for coding and considering source-code quality, safety, and security, there are specific coding guidelines such as MISRA3,4 and AUTOSAR coding guidelines.5
What is MISRA and AUTOSAR?
The Motor Industry Software Reliability Association (MISRA) defines a set of guidelines and directives for C/C++ software development mostly applied to safety critical systems in domains such as automotive, defense, and avionics.
MISRA-C:20123 including Amendment 16 and 2,7 which is the latest version currently available, defines 175 development guidelines split into 158 rules and 17 directives, and further categorizes each rule into mandatory, required and advisory. Moreover, to assist organizations on how to validate the guidelines, each guideline is defined as decidable or undecidable. Decidable guidelines can be verified using a static-analysis tool; however, for the undecidable guidelines, static analysis can only generate an incomplete picture, thus producing potential false positives/negatives.
In addition, AUTomotive Open System ARchitecture (AUTOSAR) defines a set of guidelines called AUTOSAR Coding Guidelines C++.5 These are considered as an update of the MISRA-C++:20084 standard and are currently being revised by the MISRA C++ committee.
Furthermore, in 2016, MISRA published the MISRA Compliance:2016 document,8 which serves as a guide for organizations on how to achieve MISRA compliance. This document was updated in 20209 and serves as the formal guide for the compliance process. It defines deliverables for process compliance, including a Guideline Enforcement Plan, a Guideline Reclassification Plan, and a Compliance Summary.
Those deliveries are supported by optional Deviation Records and Deviation Permits. Specifically, it’s worth mentioning that rules categorized as advisory may be reclassified as disapplied in Guideline Reclassification Plan, meaning that those rules would not be applicable to the specific project.
In addition, the MISRA Compliance document defines rules and constraints around what compliance means, under which constraints guidelines can be reclassified, and under which circumstances deviations from the guidelines are permitted. On top of that, guidance is given on how to deal with so-called Adopted Code, such as third-party binaries or open-source software.
Although the MISRA Compliance document provides guidance, many organizations seem to be struggling by often just applying vendor tools with MISRA or AUTOSAR coding checkers enabled. They’re not well-aware of the compliance definitions and the freedom within the compliance process.
Challenges
While on the surface it may seem straightforward to achieve compliance by following some coding guidelines during development, in practice there are multiple challenges. First, software in new systems such as digital cockpits, infotainment systems, autonomous driving systems, and connectivity units often consists of code from various sources, including own-developed code, third-party-developed code, commercial software, auto-generated code, and open-source software.
Trying to achieve coding compliance on the entire code base is a major challenge since some parts of the software may not have been developed with the MISRA or AUTOSAR coding guidelines in mind. Thus, scanning the entire code base for coding compliance to MISRA or AUTOSAR would typically generate an exceptionally large number of coding violations, which is unfeasible for an organization to realistically process.
More importantly, many of these findings may have low priority based on the specific guideline type, or the type of software component that’s perhaps deemed not relevant to safety or security. The large number of findings make it challenging for an organization to identify the top priority issues that must be addressed first. This challenge is further exacerbated by the fact that code bases contain increasingly growing amounts of software from various sources.
Overview of the Solution
It’s crucial for organizations to have a clear understanding of the parts of the code base and the coding guidelines with the highest priority so that violations are efficiently handled. As mentioned, a naïve approach is to scan the entire code base using a static-code-analysis tool with all coding guideline checkers enabled, which generates numerous findings. To address this challenge, a solution based on a two-step process is described as follows.
As a first step, organizations need to identify relevant coding guidelines for relevant parts in the code base and create an appropriate configuration for the software of the target system. It may be possible to apply results from a hazard analysis and risk assessment (HARA) or threat analysis and risk assessment (TARA) to more accurately identify safety- and security-relevant software components in the code base.
That code base can then be segmented into various components, e.g., own-developed safety-critical component, auto-generated non-safety critical component, third-party developed security-critical component, open-source software non-safety critical component, commercial non-safety critical component etc. A simplified example is depicted in Figure 1.
Furthermore, the organization can determine which coding guidelines are appropriate for which parts of the code base. For example, certain rules may be more applicable to safety- and security-critical components, and less applicable to non-safety- and non-security-critical components. Then a static-code-analysis tool is configured accordingly. It can be used to scan the code base regularly to only check for certain coding guidelines relevant to the specific software components to achieve more efficient scanning.
It’s important to note that an organization should use a static-code-analysis tool with a broad coverage of coding guideline checkers to achieve better results.10,11 Examples of MISRA findings identified by a static-code-analysis tool called Coverity12 is shown in Figure 2.
The static-code-analysis tool generates results that are processed by a data-analytics tool in the second step. The objective is to explore the result set of potentially still thousands if not hundreds of thousands of findings and create a customer burn-down strategy.
The Logilica Insights tool13 provides analytics capabilities similar to those found in Business Intelligence solutions and combines them with visual representations. These allow an organization to explore the findings and gain insights more easily into the relevant MISRA Compliance strategy for the code base.
Besides common charting and visualization techniques, Logilica employs so-called CodeCities,14 which are 3D maps of software repositories. Each file is displayed as a building and folders are displayed as platforms. Metrics can be overlayed to determine the size and color of the buildings. An example of MISRA findings generated by a static-code-analysis tool using this technique is illustrated in Figure 3.
The height of the building reflects the size of the file and the color of the building indicates the MISRA defect density (findings per code size). For example, the building colored in red in the figure has a high defect density and may indicate that this is something an organization should look at first with higher priority. Moreover, this visual representation can help identify hotspots, i.e., particular code areas that contain large numbers of violations. Organizations can then further investigate what may be causing these hotspots.
Benefits
This solution has a number of benefits. For instance, it can help organizations better identify the top offending rules. Furthermore, it can provide an understanding of the location of these violations—i.e., which components and which files—and help define a compliance strategy.
In the first step, it’s imperative to get the tooling and processes right. The static-analysis tool is configured using the specific configuration of relevant coding guidelines for the target software to allow for more efficient scanning that enables the scan to be performed regularly (e.g., daily). In the second step, it’s possible for developers and engineering management to gain clear insights into the current status of the project using the data-analytics tool. For instance, it would be possible for an organization to easily identify whether a large number of findings are detected in adopted code (e.g., an open-source software component), or if certain specific rules generate a significant number of findings.
Based on those insights, the organization can define an appropriate compliance strategy, perhaps to start burn-down in non-adopted code or exclude advisory rules. For example, as shown in Figure 4, among the top offending rules for an example project is Rule 15.5 with 13,820 findings. This rule is categorized as advisory and for this project could be reclassified as disapplied, meaning that it would be possible to ignore these 13,820 findings. These strategies help organizations to prioritize and allow software developers to focus on working on the right areas.
As automotive systems continue to advance and contain more complex software, including software from various sources such as own-developed code, third-party developed code, commercial software, and open-source software components, software compliance is naturally becoming a greater challenge. To overcome these challenges and put coding compliance into practice, automotive organizations need to establish proper workflows and adopt appropriate technical solutions.15
References
1. ISO, “ISO 26262 - Road vehicles—Functional safety,” 2018.
2. ISO/SAE International, “ISO/SAE DIS 21434 - Road Vehicles—Cybersecurity engineering,” 2020.
3. MISRA, “MISRA C:2012 Guidelines for the use of the C language in critical systems,” 2013.
4. MISRA, “MISRA C++:2008 Guidelines for the Use of the C++ Language in Critical Systems,” 2008.
5. AUTOSAR, "Guidelines for the use of the C++14 language in critical and safety-related systems," 2019.
6. MISRA, “MISRA C:2012 Amendment 1 - Additional security guidelines for MISRA C:2012,” 2016.
7. MISRA, “MISRA C:2012 Amendment 2 - Updates for ISO/IEC 9899:2011 Core functionality,” 2020.
8. MISRA, “MISRA Compliance:2016 - Achieving compliance with MISRA Coding Guidelines,” 2016.
9. MISRA, “MISRA Compliance:2020 - Achieving compliance with MISRA Coding Guidelines,” 2020.
10. Synopsys, “Coverity Support for MISRA Coding Standards,” 2020.
11. Synopsys, “Coverity Support for AUTOSAR Coding Standards,” 2020.
12. Synopsys, “Coverity Static Application Security Testing,” https://www.synopsys.com/software-integrity/security-testing/static-analysis-sast.html.
13. Logilica Insights, https://logilica.com.
14. R. Wettel, and M. Lanza, “CodeCity: 3D visualization of large-scale software” Proceedings - International Conference on Software Engineering, 2008. 921-922. 10.1145/1370175.1370188.
15. D. K. Oka, and R. Huuck, “How to Put MISRA and AUTOSAR Coding Compliance into Practice,” Embedded World, 2021