The original MISRA principles were created to be applied as code being developed.Even the document itself has a warning:
“…a project that checks for MISRA C compliance late in its cycle is likely to spend a considerable amount of time re-coding, re-reviewing and re-testing. It’s therefore expected that the software development process will require the early application of MISRA C principles.“
Because many organizations do need to re-use their legacy codebases for business reasons, the MISRA Compliance: 2016 guidance document was created in response to these challenges. In it, there is clear distinction between the new, native code that is developed in the scope of a current project, and the “adopted” code, which was developed outside of the scope of the project. In this post, I explain a practical approach to dealing with legacy code and MISRA C compliance.
Although it seems like it should be simple to understand what type of code you’re dealing with, the situation in many cases isn’t black and white. For example, an initial prototype that was developed without following MISRA guidelines is productized, and then management realizes that compliance is a requirement for the intended marketplace. Typically, the legacy codebase was never developed with any coding guidelines in mind. Therefore, a codebase cannot be automatically classified as “adopted code” if updates are required in the context of a new project. This can get complex.
All too often, initial scans of a large codebase via a static analysis tool with all MISRA C 2012 rules enabled, including Amendment 1, produces tens of thousands of violations. After the initial shock, teams begin to find “creative” ways of addressing the violations. It’s important for development teams not to be deterred – there is light at the end of the tunnel.
Over time, I’ve collected and identified best practices and approaches that development teams have used to make the code compliant while not interfering with the ongoing development velocity. In this post, I’m sharing some practical, balanced approaches to make existing codebases MISRA compliant.
MISRA C 2012 is a set of coding guidelines for the C programming language. The focus of the standard is increasing safety of software by preemptively preventing programmers from making coding mistakes that can lead to runtime failures (and possible safety concerns) by avoiding known problem constructs in the C language. Over the years, many developers of embedded systems were (and still are) complaining that MISRA C was too stringent of a standard and that the cost of writing fully compliant code was difficult to justify. Realistically, given that MISRA C is applied in safety-critical software, the value of applying the standard to a project depends on factors such as:
So programmers must find a practical middle ground that satisfies the spirit of the standard and still claim MISRA compliance without wasting effort on non-value-added activities.
In the document MISRA Compliance: 2016 the MISRA Consortium provides the response that was needed by the community, with a reasonably well-defined framework of what the statement “MISRA Compliant” truly means. The document is helping organization to use a common language articulating the compliance requirements by defining the following artifacts:
To focus on what to do with a legacy codebase, the key document is the Guideline Re-categorization plan. This document captures all directives and rules and identifies which categories have been re-categorized. For example, the following diagram shows part of a re-categorization plan:
First, for the “adopted” legacy code, the MISRA 2016: Compliance document suggests against re-categorizations from a less stringent to a more stringent classification. In addition, it’s possible to dis-apply Advisory rules all together after reviewing the types of violations with the team.
The requirement to document deviations is only necessary for all Required rules. Any violations in adopted code should be reviewed, and deviations need to clearly state that violations do not compromise safety and security. Regardless of re-categorization, if there is a finding that compromises the safety or security of the system, the issue must be fixed. Also, modifications to the legacy code may introduce other issues not clearly seen by the developer.
A key problem that developers of safety-critical software encounter is how to demonstrate and prove compliance at the end of the project. This can be a contentious issue resulting in wasted time and effort if the evaluation criteria are based on subjective opinions from the various stakeholders. This is a situation that the MISRA Compliance: 2016 document helped to clear up.
A recommended approach to improving the evaluation of compliance readiness is to use existing templates for both the final compliance and tool qualification report. There is also a tendency to add more information into the reports than is required. If the information is not required by the standard, avoid embellishment. Adding extra information is not only a waste of time, but also introduces a risk of delaying an audit process.
The required information that to include in the final report is provided by MISRA Compliance 2016:
The example below from Parasoft’s tool shows an HTML format, with links to appropriate sections:
In addition to the above recommendations, there are a few other important points to consider:
There are templates for these documents that commercial static analysis tool vendors, including Parasoft, provide to help organizations satisfy the MISRA 2016 Compliance framework.
Alhtough the initial scan of existing code by a static analysis tool tends to produce thousands of violations (particularly when using a default set of rules), it’s impractical to stop new development efforts to focus on fixing all these violations. In fact, I’ve seen cases where regressions were introduced when significant changes to the codebase were made to fix the static analysis violations. Therefore, it’s important to establish a workflow to fix the violations over time, without disrupting the development process and degrading the quality of the software.
Some key recommendations when using static analysis tools for the first time in a project are stated below:
For any of the approaches described above, it’s important for technical leads and management to constantly monitor the progress and project compliance status via a centralized dashboard. For example, Parasoft’s reporting hub provides the following pre-configured compliance status dashboard:
A less obvious component of MISRA compliance, often left till the end of the project, is the recognition that development tools used in the product need to be qualified (proven fit for purpose) for intended use. If a tool needs qualification, what level of validation needs to be performed?
While in many instances tool qualification is required, the method which is used to perform tool qualification varies depending on the risk associated with the tool malfunction and the software criticality level. Parasoft provides a qualification kit and certifications for specific safety standards and their requirements. In the absence of this efficient kit, software teams must consider tool qualification costs when evaluating commercial, free, and open source tools.
Some standards like ISO 26262 and DO-178B/C provide reasonable guidance on tool qualification requirements. Regardless of the method, the goal of the tool qualification process is to state that “Tool is valid for intended use” and provide a proof and rationale of how the team came to this conclusion.
Here are some recommended steps to follow for a tool qualification process:
Overlooking the tool qualification from the start might lead to project delays late in the cycle.
The expertise and training of development staff is another key factor overlooked by software organizations and frequently being identified by auditors as number one issue when evaluating the readiness of a product.
According to MISRA Guidelines, staff competency is an important part of the MISRA compliance. It’s best to conduct training in the beginning of the project and have a training date recorded with all the developers signed off that they received the training. At the end of the project the development team should be able to prove that:
In practice, training for an experienced team is relatively short, but a few days invested in the beginning of the project saves weeks of rework after a project deadline has been missed.
There is no silver bullet that makes achieving MISRA compliance of legacy code easy in safety-critical projects. However, along with the introduction of the MISRA Compliance 2016 framework, using the practical phased approach with a clearly defined end point in mind, as outlined in this post, software development teams can achieve compliance without significantly disrupting their development process. The bottom line is that there is still a fair amount of work to achieve compliance, but with intelligent planning and the right approach, a minimal and balanced set of tasks can be established to make both legacy and newly developed code safe and secure.
Andrey is a Senior Solution Architect at Parasoft, where he focuses on automated tools and methodologies, working with customers to identify best technical and business approaches for efficient testing of heterogeneous applications.