[Practical Guide] How to make your old code base (legacy code) comply with MISRA C 2012 coding standards?

Reusing old code is a reality, but reusing old code in safety-critical software projects and achieving full MISRA C 2012 compliance is a difficult task.

The original MISRA principles were created to be applied when developing code, even the document itself has warnings:

"... A project that checks MISRA C compliance late in the project cycle may spend a lot of time recoding, re-reviewing, and re-testing. Therefore, it is expected that the software development process will require the early application of MISRA C principles."

Because many organizations do need to reuse their old code bases for business reasons, MISRA 2016 compliance guidelines documents were created to address these challenges. Among them, there is a clear difference between new native code developed within the scope of the current project and "adopted" code developed outside the scope of the project. In this article, I explained a practical way to deal with legacy code and MISRA C compliance.

Shades of gray following MISRA guidelines

Although it seems easy to understand the type of code to be processed, in many cases this is not the case. For example, commercialize an initial prototype developed that does not follow MISRA guidelines, and then management realizes that compliance is a requirement of the expected market. Generally, the development of legacy code bases has never considered any coding guidelines. Therefore, if an update is required in the context of a new project, the code base cannot be automatically classified as "adopted code". This will become very complicated.

Usually, the initial scan of a large code base through a static analysis tool with all MISRA C 2012 rules (including revision 1) enabled will generate tens of thousands of violations. After the initial shock, the team began to look for "creative" ways to resolve the conflict. It is important not to stop the development team-there is sunlight at the end of the tunnel.

Over time, I have collected and determined the best practices and methods that the development team uses to make the code compliant without affecting the speed of ongoing development. In this article, I will share some practical and balanced methods to make the existing code base MISRA compliant.

Use MISRA Compliance: 2016 framework

MISRA C 2012 is a set of coding guidelines for the C programming language. The focus of the standard is to improve the security of software by avoiding known problem structures in the C language, preventing programmers from making mistakes and causing runtime failures (and possible security issues). Over the years, many embedded system developers have been (and still) complain that MISRA C is too strict with the standard and the cost of writing fully compatible code is difficult to justify. In fact, given that MISRA C has been used in safety-critical software, the value of applying this standard to projects depends on the following factors:

• Risk of system failure due to software failure
• Losses caused by system failures
• Development tools and target platforms
• The level of expertise of developers
  Therefore, programmers must find a practical middle ground that conforms to the spirit of the standard, and still claim that they are MISRA compliant, without wasting energy on non-value-added activities.

In the MISRA Compliance: 2016 document, the MISRA Alliance provided the response needed by the community and provided a reasonably well-defined framework to illustrate the true meaning of the term "MISRA compliant". This document helps organizations use a common language that expresses compliance requirements by defining the following artifacts:

• Code Implementation Plan-Demonstrate how to verify each MISRA Code.
• Code reclassification plan-communicate the severity of each agreed rule in the code as part of the supplier/customer relationship.
• Deviation report-record violations of the code with reasonable grounds.
• Code compliance summary-is the main record of overall project compliance.
  In order to focus on dealing with the legacy code base, the key document is the guideline reclassification plan. This document contains all instructions and rules and determines which categories have been reclassified. For example, the following figure shows part of the reclassification plan:

First of all, for "adopted" old codes, the "MISRA 2016: Compliance" document recommends not to reclassify from a less strict classification to a more strict classification. In addition, after reviewing the types of violations with the team, the application of advisory rules can also be cancelled together.

Deviations need to be recorded only for all required rules. Any violations in the adopted specifications should be reviewed, and deviations must clearly show that the violations will not compromise safety. Regardless of the reclassification, if a problem is found that compromises the security of the system, the problem must be resolved. Similarly, modifications to the legacy code may introduce other problems that developers cannot clearly see.

Start with the end

The key issue encountered by safety-critical software developers is how to demonstrate and prove compliance at the end of the project. If the evaluation criteria are based on the subjective opinions of various stakeholders, then this may be a controversial issue, leading to a waste of time and energy. In this case, the MISRA Compliance: 2016 document was resolved.

The proposed method to improve the assessment of compliance readiness is to use the existing template for the final compliance and tool qualification report. There is also a trend to add more information to the report than needed. If the standard does not require this information, please avoid embellishment. Adding additional information not only wastes time, but also risks delaying the review process.

MISRA Compliance 2016 provides the necessary information to be included in the final report:

• Code implementation plan
• Summary of Code Compliance
• Details of all approved deviation permits
• The deviation record covers all violations of the guidelines and has been reclassified as required.
  The following example from the Parasoft tool shows the HTML format with links to the corresponding sections:

Establish the final goal early

In addition to the above suggestions, there are other important points to consider:

1. Was a GRP (Guideline Reclassification Plan) developed at the beginning of the project? According to the MISRA standard, you can negotiate with the acquirer, or you can create multiple GRPs for the adopted code. These codes can be used without any modification, while the native code is actively modified during the project.
2. For each incremental change, is there a remaining amount of work to fully comply with the regulations? This helps plan the work accordingly and establish the correct expectations with management.
3. At the beginning of the project, have the GPS (Guideline Compliance Summary) report templates reviewed with the purchaser, and are these templates accepted and complete?
   Commercial static analysis tool vendors (including Parasoft) provide templates of these documents to help organizations meet the MISRA 2016 compliance framework.

Phased implementation: divide and conquer

Although initial scans of existing code through static analysis tools often generate thousands of violations (especially when using the default rule set), it is impractical to stop new development work and concentrate on resolving all these violations of. In fact, I have seen the introduction of regressions when making major changes to the code base to fix static analysis violations. Therefore, it is important to establish a workflow to resolve violations over time without affecting the development process and software quality.

Here are some key suggestions when using static analysis tools for the first time in a project:

• Baseline. After the initial scan of the code, all initial violations are marked as "processed later" and set as a baseline. From then on, when updating existing code and/or developing new code, the "No new violations allowed" policy should be maintained. This strategy can be implemented through a code review process or continuous integration (CI) tools such as Jenkins or Bamboo. When developers have a few hours or days of free time, they can resolve the remaining violations flagged from the baseline. Organizations can give priority to this method based on the code currently being developed, the results of code reviews, or relying on metrics (such as complexity) to suggest the next violation to be resolved.
• Boundaries. The development determined a date, the "boundary". After this date, every translation unit (single source file) modified must resolve all violations. All unmodified translation units will automatically be included in the real "adopted" code definition in the MISRA compliance document.
• Priority based on severity. Developers will fix all mandatory discoveries of modules assigned to them. Over time, they will resolve all required violations as time permits based on the priority chosen by the team leader.
  For any of the above methods, it is essential for technical leaders and managers to continuously monitor progress and project compliance status through a centralized dashboard. For example, Parasoft’s Report Center provides the following pre-configured compliance status dashboards:

Tool qualification

A less obvious component of MISRA compliance (usually left until the end of the project) is the recognition that the development tools used in the product need to be qualified for the intended use (proven suitable for the purpose). If the tool requires authentication, what level of authentication needs to be performed?

Although tool qualification is required in many cases, the methods used to perform tool qualification vary depending on the risks associated with tool failure and software criticality levels. Parasoft provides certification kits and certifications for specific safety standards and their requirements. In the absence of this efficient toolkit, the software team must consider the cost of tool certification when evaluating commercial, free and open source tools.

Some standards (such as ISO 26262 and DO-178B/C) provide reasonable guidance on tool qualification requirements. Regardless of the method used, the goal of the tool identification process is to state that "the tool is effective for the intended use" and provide evidence and reasons for how the team came to this conclusion.

Here are some recommended steps for the tool qualification process:

• Specify tool requirements for intended use
• Identifies a subset of the functions used in the product. Simplify the authentication process to only use functions
• Outline eligibility plan
• A set of qualification verification steps that outline whether the verification tool meets the requirements (may include tests performed by the team)
• Automatically execute test cases that can be automated
• Provide a framework to enter the results of manual test steps
• Report templates to reduce the amount of text that developers need to enter.
• Review the report with stakeholders and sign it.
  Ignoring tool qualifications from the beginning can lead to delays in the project cycle.

Staff competence and training

The professional knowledge and training of developers is another key factor that software organizations ignore. When assessing the readiness of a product, auditors often regard it as the top issue.

According to the "MISRA Guidelines", employee competence is an important part of MISRA compliance. It is best to conduct training at the beginning of the project and record the date of training. All developers should sign and agree to receive training. At the end of the project, the development team should be able to demonstrate:

• Staff who approve deviations understand and receive training to recognize the risks associated with violations
• The personnel are trained to properly configure and use static analysis and development tools before use.
  In fact, training for experienced teams is relatively short, but after missing the project deadline, investing a few days at the beginning of the project can save weeks of rework.

to sum up

There are no shortcuts that make it easy for safety-critical projects to achieve MISRA compliance with legacy code. However, as outlined in this article, with the introduction of the MISRA Compliance 2016 framework, using a practical phased approach, and clearly defined endpoints (as described in this article), software development teams can achieve this without severely disrupting their development process Compliance. Most importantly, a lot of work is needed to achieve compliance, but through smart planning and correct methods, a minimal and balanced task set can be established to ensure the safety of old code and newly developed code.