Recent advancements in the automotive industry include the development of autonomous driving systems, connectivity units, and digital cockpits and infotainment systems that improve the user experience. As the more advanced and complex software needed for such systems is developed in the automotive industry, the requirements for safe and secure software development are increasing.
Standards such as ISO 26262 for functional safety and the upcoming ISO/SAE 21434 for cyber security direct automotive organizations on how to incorporate safety and security during the engineering process. More specifically, for the software development activity itself, there are several coding guidelines that help developers improve code quality, safety, and security, such as MISRA C, MISRA C++, and AUTOSAR C++.
About MISRA and AUTOSAR coding guidelines
The Motor Industry Software Reliability Association (MISRA) provides a set of guidelines and directives for C/C++ software development focusing on safety-critical systems in domains such as automotive, defense, and avionics. These guidelines date back to the original release of MISRA C in 1998. MISRA-C:2012, including Amendment 1 and 2, is the latest version currently available. Safety-related systems are often required to follow these coding guidelines.
As software development shifted toward using C++ for the AUTOSAR Adaptive Platform, AUTomotive Open System ARchitecture (AUTOSAR) released a set of guidelines called AUTOSAR Coding Guidelines C++. These coding guidelines are viewed as an update to the MISRA-C++:2008 guidelines and are currently being revised by the MISRA C++ committee.
In 2016, MISRA published the MISRA Compliance:2016 document, which was further updated in 2020. This document serves as a formal guide for organizations on how to achieve MISRA compliance. For example, it defines deliverables for process compliance including a guideline enforcement plan and a guideline compliance summary. It’s important to note that MISRA compliance was previously optional, but MISRA C:2012 Amendment 2, released in February 2020, makes MISRA compliance mandatory.
Challenges for MISRA and AUTOSAR compliance
Software development for automotive systems in new areas such as digital cockpits, infotainment systems, and autonomous driving and connectivity units typically involve large software codebases. These codebases may contain software from a variety of sources including in-house developed code, third-party developed code, commercial software, autogenerated code, and open source software components. As such, trying to achieve coding compliance on the entire codebase is a major challenge since some software components may not have been developed following the MISRA or AUTOSAR coding guidelines.
Therefore, a naïve approach of scanning the entire codebase for compliance to MISRA or AUTOSAR coding guidelines typically results in an exceptionally large number of coding violations. More importantly, many of these findings may be irrelevant or considered low priority, which makes it challenging for organizations to identify the issues that need to be addressed first. Additionally, this challenge is often exacerbated by the fact that organizations may not have an established workflow or process in place to configure and perform MISRA and AUTOSAR coding guidelines checks, prioritize findings, track progress, and get an overview of the current status and top-priority issues.
Workflow steps to achieve compliance
It’s crucial for organizations to have a clear understanding of which parts of the codebase and which coding guideline violations have the highest priority so that they can be addressed appropriately. To accomplish this, the following workflows steps are suggested.
1. As a first step when analyzing the target software, where possible use results from the threat analysis and risk assessment (TARA) and hazard analysis and risk assessment (HARA) of the target system to help identify security-critical and safety-critical components in the codebase.
2. Based on the identified security-critical and safety-critical components, segment the codebase into components. For example:
- In-house-developed safety-critical components
- Autogenerated non-safety-critical components
- Third-party-developed security-critical components
- Open source non-safety-critical components
- Commercial non-safety-critical components
Figure 1 illustrates a simplified example of this code segmentation.
Figure 1: Code segmentation of the target system codebase
3. It’s imperative that an organization define policies on which MISRA or AUTOSAR coding guidelines are applicable to which components, based on their type and risk rating. For instance, certain coding guidelines should be a higher priority for safety- and security-critical components, and some coding guidelines may be less applicable to non-safety-critical and non-security-critical components.
4. A static code analysis tool should be configured based on the policies defined in Step 3, focusing on the guidelines that can be verified using this kind of tool. In the static application security testing (SAST) tool Coverity®, it’s possible to configure different priorities for different rules and different folders. For example, an open source software non-safety-critical component could be excluded using blocking policies. Or a rule for an in-house-developed safety-critical component could be assigned a higher priority, while the same rule for a third-party-developed security-critical component could be assigned a lower priority using scoring policies. This fine-tuning of applicable rules and assigning of scoring priority allows organizations to focus on top-priority findings. These configuration details can be documented in a spreadsheet; for example, the exclusion of certain folders, and scoring priority values (1–9). A threshold score value can be defined and used to filter out findings with lower score values. An example configuration is shown in Figure 2.
Figure 2: Example configuration of components and rules defined in a spreadsheet
5. The target software is then scanned by a SAST tool using the configuration from Step 4. It’s vital to use a SAST tool that provides a high coverage of the rules defined in the specific coding standards to achieve better results. Coverity provides support for MISRA and AUTOSAR coding standards. Using the configuration in Coverity when scanning the target software generates relevant findings with assigned scoring values according to the policies that, in turn, can be used to identify the high-priority findings.
6. To further assist an organization in processing the findings, it’s possible to use a data analytics tool to visualize the results. For example, the Logilica Insights tool provides analytics capabilities combined with visual representations.
7. Using the visualized results in Step 6, an organization can more easily analyze the results to determine an effective MISRA compliance strategy, such as identifying hotspots and defining a burn-down strategy. A visual representation of the MISRA findings generated by a SAST tool can be created using a technique called CodeCities, which creates 3D maps of software repositories. An example is shown in Figure 3. The height of the building indicates the file size, and the building color designates the MISRA defect density (findings per code size).
In Figure 3, the red building has a high defect density, which could guide an organization to further analyze this particular file with higher priority. Additionally, a visual representation can help an organization easily identify hotspots—particular code areas that contain large numbers of violations. Organizations can then further investigate what may be causing these hotspots.
Figure 3: MISRA defect density in the codebase, visualized in a 3D map
8. Last, an organization needs to follow the compliance strategy defined in Step 7 in order to identify the top violations and determine which to first address. Moreover, the analysis can also provide a better understanding of the location of common violations, such as which software components or specific files. By further analyzing the findings, it may be possible to go back to Steps 3 and 4 and update the policies or configuration to exclude or reduce the priority of certain rules or locations, for example.
Putting your compliance strategy into practice
As more advanced and complex automotive systems are developed, software compliance is naturally becoming a greater challenge. This is especially true given that such systems often include code developed in-house, code developed by third parties, commercial software, and open source software components. To overcome these challenges and put coding compliance into practice, it’s crucial that automotive organizations establish proper workflows and deploy appropriate technical solutions. Using SAST tools with configurations based on policies, and approaches that provide a visual representation of findings allows organizations to more effectively define and follow an appropriate strategy to achieve MISRA and AUTOSAR compliance.
Continue Reading
