A Practical Guide to Accelerate MISRA C 2023 Compliance With Test Automation

Introduction

The challenges of building embedded software applications continue to increase. Demands to incorporate competencies in network connectivity, artificial intelligence (AI), and other performance improvements have increased code complexity and, in turn, heightened the risk of security vulnerabilities and safety hazards. To help mitigate these challenges, many organizations look to the Motor Industry Software Reliability Association (MISRA) coding guidelines.

MISRA C 2023 guidelines for the use of the C language in critical systems is a definition of a subset of the C language designed to minimize potential errors, security vulnerabilities, and mistakes that cause program failure or serious errors. Although initially created for automotive systems, the guidelines have been adopted by many other industries for safety-critical applications. In all cases, determining compliance, which is increasingly required in vendor/client relationships, can be complex and time-consuming if it’s not automated.

There are many tools on the market that report errors indicating when code is violating a guideline. However, few tools simplify the reporting and documentation process required for demonstrating compliance—never mind implementing the guidelines into your software development process!

Test verification and validation solutions like Parasoft’s make reaching MISRA compliance quicker and with less cost. The solution streamlines the entire process of achieving, documenting, and maintaining MISRA compliance throughout the product life cycle. It also streamlines other automated testing methods like unit, regression, integration, system, structural code coverage, and more.

Reuse of code is a reality for every project. However, reusing legacy code in a safety-critical software project and achieving full MISRA C 2023 compliance is a daunting task.

The original MISRA principles were created to be applied as code being developed. Even the standard itself provides 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 reuse their legacy codebases for business reasons, the MISRA Compliance: 2020 guidance document was created in response to these challenges. In it, there’s a clear distinction between the new, native code that’s developed in the scope of a current project and the adopted code that’s developed outside of the scope of the project. Let’s dive into a practical approach to 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 adding to the complexity of the situation.

All too often, initial scans of a large codebase via a static analysis tool with all MISRA C 2023 rules enabled, including the latest amendments to the standard, 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, we’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 paper, we share some practical, balanced approaches to make existing codebases MISRA compliant.

MISRA C 2023 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. However, MISRA continues to publish amendments to its latest MISRA C 2023 coding guidelines to mitigate the growing risk of cyber security coding vulnerabilities.

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- and security- critical software, the value of applying the standard to a project depends on factors like the following.

• Risk of a system malfunction because of a software failure.
• Risk of system exploit because of a software vulnerability.
• Cost of a system failure to the business.
• Development tools and target platform.
• Level of developer’s expertise.

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: 2020, the MISRA Consortium provides the response that was needed by the community, with a reasonably well-defined framework of what the phrase “MISRA compliant” truly means.

To claim MISRA compliance, it’s required to establish:

• Use of a disciplined software development process.
• Exactly which guidelines are being applied.
• The effectiveness of the enforcement methods.
• The extent of any deviations from the guidelines.
• The status of any software components developed outside of the project.

A key problem that developers of safety-critical software encounter is how to demonstrate and prove compliance at the end of the project. There’s a tendency to add more information into the reports than is required. It can become a contentious issue, resulting in wasted time and effort if the evaluation criteria are based on subjective opinions from the various stakeholders.

A recommended approach to improving the evaluation of compliance readiness is to use existing templates for both the final compliance and tool qualification report. If the information is not required by the standard, avoid adding it. Combining extra information is not only a waste of time, but also introduces a risk of delaying an audit process. Having the documentation auto generated, as Parasoft does, is the ultimate solution.

The MISRA Compliance: 2020 document is also helping organizations to use a common language articulating the compliance requirements by defining the following artifacts.

• Guidelines compliance summary
• Guideline enforcement plan
• Deviations report
• Guideline recategorization plan

The following screenshots show auto-generated reports with links to other records and/or expansion of information on the page.

Parasoft’s Guidelines Compliance Report summary is the primary record of overall project compliance.

Parasoft’s Guideline Enforcement Plan demonstrates how each MISRA guideline is verified.

Parasoft’s Deviation Report documents all approved deviation permits.

Parasoft’s Guideline Re-categorization Plan communicates how the guidelines are to be applied as part of the stakeholder/supplier relationship.

Today, development teams employ coding standards as a method to define, manage, and utilize a group of coding practices, with the prime objective being consistency and ensuring a baseline for code quality. The main aim of a coding rule is to limit use of the language so it prevents the developer from doing things that are “wrong” and can be potentially dangerous. Developers can avoid many defects in software by adopting sensible language-use restrictions. This results in style uniformity, which is valuable as a discipline in software projects.

The versatility aspect of the C++ and C languages allows developers to write code that can be unintentionally incorrect and possibly dangerous. It’s easy for him or her to write code that adheres to the requirements of the language’s standard but this, nonetheless, can result in undesirable behavior and program crashes. These include, for example, code that accesses memory beyond the parameters of an arithmetic process or of an array that results in memory or boundary violations.

It’s obviously important to identify these potential problems. But the aim of MISRA is to prevent problems, not simply identify them. A compiler can detect some, but using a dedicated analysis tool is more effective.

The MISRA standard emphasizes that adhering to coding rules is only one component to developing software successfully. Developers must integrate each programming project into a disciplined engineering setting that includes methodical development workflows and apply proven in-use validation tools.

The expertise and training of the development staff are key factors often overlooked by software organizations and frequently identified by auditors as the 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 at the beginning of the project and have a training date recorded with all the developers signing off that they received the training. At the end of the project, the development team should be able to prove the following.

• Staff that approves deviations understands and has been trained to recognize the risks associated with the violation.
• Staff has been trained to properly configure and use the static analysis and development tools prior to their use.

In practice, training for an experienced team is relatively short. A few days invested in the beginning of the project saves weeks of rework, quality issues down the road and missed project deadlines.

A less obvious component of MISRA compliance, often left until the end of the project, is the qualification of the development tools used in the product, and proving they’re fit for purpose according to the pertinent safety standard. If a tool needs qualification, what level of validation needs to be performed?

Tool qualification needs to start with tool selection, ensuring you’re using a development tool that’s certified by an organization, such as TÜV SÜD. This will significantly reduce the effort when it comes to tool qualification.

Parasoft C/C++test is certified by TÜV SÜD for functional safety according to IEC 61508, ISO 26262, and IEC 62304 standards for both host based and embedded target applications, paving the way for a streamlined qualification of static analysis, unit testing, and coverage requirements for the safety-critical standards.

While in many instances tool qualification is required, the method 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 DO-178C provide reasonable guidance on tool qualification requirements. Regardless of the method, the goal of the tool qualification process is to state that “the tool is valid for its intended use” and provide a proof and rationale for how the team came to this conclusion.

There’s no silver bullet that makes achieving MISRA compliance easy in safety-critical projects. However, by introducing the MISRA Compliance 2020 framework and using a practical, phased approach with a clearly defined end point in mind, software development teams can achieve compliance without significantly disrupting their development process. The bottom line is that there’s still a fair amount of work to achieve compliance, but automation goes a long way to reducing the tedious manual processes.

“MISRA”, “MISRA C” and the triangle logo are registered trademarks of The MISRA Consortium Limited. ©The MISRA Consortium Limited, 2021. All rights reserved.