MISRA C

Last updated

MISRA C is a set of software development guidelines for the C programming language developed by The MISRA Consortium. Its aims are to facilitate code safety, security, portability and reliability in the context of embedded systems, specifically those systems programmed in ISO C / C90 / C99. [1]

Contents

There is also a set of guidelines for MISRA C++ not covered by this article.

History

For the first two editions of MISRA-C (1998 and 2004) all Guidelines were considered as Rules. With the publication of MISRA C:2012 a new category of Guideline was introduced - the Directive whose compliance is more open to interpretation, or relates to process or procedural matters.

Adoption

Although originally specifically targeted at the automotive industry, MISRA C has evolved as a widely accepted model for best practices by leading developers in sectors including automotive, aerospace, telecom, medical devices, defense, railway, and others. For example:

Guideline classification and categorization

When a new software project is started, the latest MISRA standard should be used. Previous standards are still available for use with legacy software projects that need to refer to it. [9]

Classification

Each Guideline is classified [10] as Mandatory (new for MISRA C:2012), Required or Advisory. Furthermore, the MISRA Compliance document permits Advisory guidelines to be Disapplied.

Categorization

The rules can be divided logically into a number of categories:

Scope

MISRA C:2012 separately classifies each guideline as either Single Translation Unit or System. [10]

Decidability

MISRA C:2012 classifies the rules (but not the directives) as Decidable or Undecidable.

Achieving compliance

MISRA compliance

MISRA published documents to provide additional guidance to understand and achieve MISRA compliance.

Compliance

In order for a piece of software to claim to be compliant to the MISRA C Guidelines, all mandatory rules shall be met and all required rules and directives shall either be met or subject to a formal deviation. Advisory rules may be disapplied without a formal deviation, but this should still be recorded in the project documentation.

Note: For compliance purposes, there is no distinction between rules and directives.

Deviations

Many MISRA C rules can be characterized as guidelines because under certain condition software engineers may deviate from rules and still be considered compliant with the standard. Deviations must be documented either in the code or in a file. In addition; proof must be provided that the software engineer has considered the safety of the system and that deviating from the rule will not have a negative impact, requirements for deviations also include:

Published documents

MISRA C:1998

The first edition of MISRA C, "Guidelines for the use of the C language in vehicle based software", which was published in 1998 and is officially known as MISRA-C:1998. [14]

MISRA-C:1998 has 127 rules, of which 93 are required and 34 are advisory; the rules are numbered in sequence from 1 to 127.

MISRA C:2004

In 2004, a second edition "Guidelines for the use of the C language in critical systems", or MISRA-C:2004 was produced, with many substantial changes to the guidelines, including a complete renumbering of the rules.

MISRA-C:2004 contains 142 rules, of which 122 are "required" and 20 are "advisory"; they are divided into 21 topical categories, from "Environment" to "Run-time failures".

MISRA C:2012

Main document

In 2013, the third edition, MISRA C:2012, was published. MISRA C:2012 extends support to the C99 version of the C language (while maintaining guidelines for C90), in addition to including a number of improvements that can reduce the cost and complexity of compliance, whilst aiding consistent, safe use of C in critical systems. [15]

MISRA-C:2012 contains 143 rules and 16 "directives" (that is, rules whose compliance is more open to interpretation, or relates to process or procedural matters); each of which is classified as mandatory, required, or advisory. They are separately classified as either Single Translation Unit or System. Additionally, the rules are classified as Decidable or Undecidable.

Amendment 1

In April 2016, MISRA published (as a free download) MISRA C:2012 - Amendment 1: Additional Security Guidelines [16] which added fourteen new security guidelines.

Amendment 2

In February 2020, MISRA published (as a free download) MISRA C:2012 - Amendment 2: Updates for ISO/IEC 9899:2011/18 Core functionality [17] which adds mapping for the undefined, unspecified and implementation defined behaviours within C11/C18.

Supporting documents

MISRA have published the following addenda to support MISRA C:2012:

  • MISRA C:2012 - Addendum 1: Rule Mappings, [18] which contains bi-directional rule mappings between MISRA C:2004 and the new version. It is intended to assist users in migration.
  • MISRA C:2012 - Addendum 2: Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 "C Secure" [19]
  • MISRA C:2012 - Addendum 3: Coverage of MISRA C:2012 against CERT C [20]

MISRA C:2023

In May 2023 MISRA published MISRA C:2023 (MISRA C Third edition, Second revision) which incorporates Amendments 2 – 4 (AMD2, AMD3, AMD4) and Technical Corrigendum 2 (TC2) and incorporates support for C11 and C18 language features. [21]

Example suite

An exemplar suite (for MISRA-C:2004 and MISRA C:2012) is available from the MISRA GitLab [22] repository (login required). This allows tool-users to evaluate and compare the checking support provided by the various MISRA tools; additionally, it gives tool-implementers some guidance as to the intent of the MISRA Guidelines.

Tools

While there exist many software tools that claim to check code for "MISRA conformance", there is no MISRA certification process. [23]

Most of the guidelines can be checked using tools that perform static code analysis. The remaining guidelines require the use of dynamic code analysis.

Tools that check code for MISRA conformance include:

C/C++ compilers that support MISRA conformance include:

Criticism

Some research results question the effectiveness of MISRA C 2004.

In a paper that compares earlier work on MISRA C:1998 with MISRA C:2004, Les Hatton comes to the conclusion that: [30]

In view of the apparent widening influence of the MISRA C standard, this paper attempts to assess whether important deficiencies in the original standard have been addressed satisfactorily. Unfortunately, they have not and the important real to false positive ratio is not much better in MISRA C 2004 than it was in MISRA C 1998 and it is unacceptably low in both.

He goes on to state: [30]

In its present form, the only people to benefit from the MISRA C 2004 update would appear to be tool vendors and it is to be hoped that steps will be taken both to simplify the wording and to reduce the false positive ratio in future revisions by taking a little more notice of published experimental data and being less tempted to invent rules on the basis that they seem a good idea.

A study at the TU Delft, by Cathal Boogerd and Leon Moonen, empirically assesses the value of MISRA C:2004. It comes to similar results: [31]

From the data obtained, we can make the following key observations. First, there are 9 out of 72 rules for which violations were observed that perform significantly better (α = 0.05) than a random predictor at locating fault-related lines. The true positive rates for these rules range from 24-100%. Second, we observed a negative correlation between MISRA rule violations and observed faults. In addition, 29 out of 72 rules had a zero true positive rate. Taken together with Adams' observation that all modifications have a non-zero probability of introducing a fault, this makes it possible that adherence to the MISRA standard as a whole would have made the software less reliable.

See also

Related Research Articles

In computer science, static program analysis is the analysis of computer programs performed without executing them, in contrast with dynamic program analysis, which is performed on programs during their execution.

OSEK is a standards body that has produced specifications for an embedded operating system, a communications stack, and a network management protocol for automotive embedded systems. It has produced related specifications, namely AUTOSAR. OSEK was designed to provide a reliable standard software architecture for the various electronic control units (ECUs) throughout a car.

AUTomotive Open System ARchitecture (AUTOSAR) is a development partnership of automotive interested parties founded in 2003. It is focused on creating and establishing an open and standardized software architecture for automotive electronic control units (ECUs). Goals include the scalability to different vehicle and platform variants, transferability of software, the consideration of availability and safety requirements, a collaboration between various partners, sustainable use of natural resources, and maintainability during the product lifecycle.

IEC 61508 is an international standard published by the International Electrotechnical Commission (IEC) consisting of methods on how to apply, design, deploy and maintain automatic protection systems called safety-related systems. It is titled Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems.

IAR Systems is a Swedish computer software company that offers development tools for embedded systems. IAR Systems was founded in 1983, and is listed on Nasdaq Nordic in Stockholm. IAR is an abbreviation of Ingenjörsfirma Anders Rundgren, which means Anders Rundgren Engineering Company.

Helix QAC, formerly QA·C is a commercial static code analysis software tool produced by Minneapolis, Minnesota-based software vendor Perforce Software. QAC means Quality Assurance and Control. The software was originally developed in 1986 by UK-based Programming Research Limited (PRQA) for the C language. Perforce acquired PRQA in May 2018.

The Motor Industry Software Reliability Association (MISRA) is an organization that produces guidelines for the software developed for electronic components used in the automotive industry. It is a collaboration between vehicle manufacturers, component suppliers and engineering consultancies. In 2021, the loose consortium restructured as The MISRA Consortium Limited.

Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe). The automatic protection system should be designed to properly handle likely human errors, systematic errors, hardware failures and operational/environmental stress.

Parasoft DTP is a development testing and software testing analytics solution from Parasoft that acts as a centralized hub for managing software quality and application security. DTP provides traditional software reports from normal software development activities and is also able to aggregate data from various software testing practices to present an overview of the state of the codebase.

ISO 14971Medical devices — Application of risk management to medical devices is a voluntary standard for the application of risk management to medical devices. "Voluntary standards do not replace national laws, with which standards' users are understood to comply and which take precedence" over voluntary standards such as ISO 13485 and ISO 14971. The ISO Technical Committee responsible for the maintenance of this standard is ISO/ TC 210 working with IEC/SC62A through Joint Working Group one (JWG1). This standard is the culmination of the work starting in ISO/IEC Guide 51, and ISO/IEC Guide 63. The third edition of ISO 14971 was published in December 2019 and supersedes the second edition of ISO 14971.

<span class="mw-page-title-main">LDRA</span> Software companies of the United Kingdom

LDRA is a provider of software analysis, test, and requirements traceability tools for the Public and Private sectors. It is a pioneer in static and dynamic software analysis.

ISO 26262, titled "Road vehicles – Functional safety", is an international standard for functional safety of electrical and/or electronic systems that are installed in serial production road vehicles, defined by the International Organization for Standardization (ISO) in 2011, and revised in 2018.

TargetLink is a software for automatic code generation, based on a subset of Simulink/Stateflow models, produced by dSPACE GmbH. TargetLink requires an existing MATLAB/Simulink model to work on. TargetLink generates both ANSI-C and production code optimized for specific processors. It also supports the generation of AUTOSAR-compliant code for software components for the automotive sector. The management of all relevant information for code generation takes place in a central data container, called the Data Dictionary.

DO-178C, Software Considerations in Airborne Systems and Equipment Certification is the primary document by which the certification authorities such as FAA, EASA and Transport Canada approve all commercial software-based aerospace systems. The document is published by RTCA, Incorporated, in a joint effort with EUROC and replaces DO-178B. The new document is called DO-178C/ED-12C and was completed in November 2011 and approved by the RTCA in December 2011. It became available for sale and use in January 2012.

<span class="mw-page-title-main">Parasoft C/C++test</span> Integrated set of tools

Parasoft C/C++test is an integrated set of tools for testing C and C++ source code that software developers use to analyze, test, find defects, and measure the quality and security of their applications. It supports software development practices that are part of development testing, including static code analysis, dynamic code analysis, unit test case generation and execution, code coverage analysis, regression testing, runtime error detection, requirements traceability, and code review. It's a commercial tool that supports operation on Linux, Windows, and Solaris platforms as well as support for on-target embedded testing and cross compilers.

AbsInt is a software-development tools vendor based in Saarbrücken, Germany. The company was founded in 1998 as a technology spin-off from the Department of Programming Languages and Compiler Construction of Prof. Reinhard Wilhelm at Saarland University. AbsInt specializes in software-verification tools based on abstract interpretation. Its tools are used worldwide by Fortune 500 companies, educational institutions, government agencies and startups.

High Integrity C++ is a software coding standard for the C++ programming language developed by Programming Research Limited, now part of Perforce Software. HIC++ was first published in October 2003. The latest revision, version 4.0, was released in October 2013 and documents 155 rules that restrict the use of ISO C++ language to improve software maintenance and reliability in high reliability or safety critical applications.

Automotive Safety Integrity Level (ASIL) is a risk classification scheme defined by the ISO 26262 - Functional Safety for Road Vehicles standard. This is an adaptation of the Safety Integrity Level (SIL) used in IEC 61508 for the automotive industry. This classification helps defining the safety requirements necessary to be in line with the ISO 26262 standard. The ASIL is established by performing a risk analysis of a potential hazard by looking at the Severity, Exposure and Controllability of the vehicle operating scenario. The safety goal for that hazard in turn carries the ASIL requirements.

<span class="mw-page-title-main">Enterprise Architect (software)</span> Visual modeling and design tool

Sparx Systems Enterprise Architect is a visual modeling and design tool based on the OMG UML. The platform supports: the design and construction of software systems; modeling business processes; and modeling industry based domains. It is used by businesses and organizations to not only model the architecture of their systems, but to process the implementation of these models across the full application development life-cycle.

CodeSonar is a static code analysis tool from CodeSecure, Inc. CodeSonar is used to find and fix bugs and security vulnerabilities in source and binary code. It performs whole-program, inter-procedural analysis with abstract interpretation on C, C++, C#, Java, as well as x86 and ARM binary executables and libraries. CodeSonar is typically used by teams developing or assessing software to track their quality or security weaknesses. CodeSonar supports Linux, BSD, FreeBSD, NetBSD, MacOS and Windows hosts and embedded operating systems and compilers.

References

  1. ↑ "MISRA clarifies safe and secure uses of the C language". www.misra.org.uk. Archived from the original on 2020-08-04. Retrieved 2019-10-09.
  2. ↑ In spring 1997 software engineers at the Austin Rover Group (ARG) sent a draft C coding standard to Programming Research Ltd (PRL) for review. The review was performed by PRL's then senior consultant, David Blyth, who proposed replacing the draft with an appreciably stronger set of coding rules. Those rules, with minor changes, formed the basis of the first edition of MISRA C.
  3. ↑ "Joint Strike Fighter Air Vehicle C++ Coding Standards" (PDF). Retrieved 2019-07-16.
  4. ↑ "JPL Institutional Coding Standard for the C Programming Language" (PDF). Retrieved 2019-07-16.
  5. ↑ "ISO 26262-6:2011 Road vehicles -- Functional safety -- Part 6: Product development at the software level". iso.org. ISO. Retrieved 2019-07-16.
  6. ↑ "ISO 26262-6:2018 Road vehicles -- Functional safety -- Part 6: Product development at the software level". iso.org. ISO. Retrieved 2019-07-16.
  7. ↑ "AUTOSAR 4.2 General Software Specification" (PDF). autosar.org. Retrieved 2019-07-16.
  8. ↑ "AUTOSAR 4.3 General Specification of Basic Software Modules" (PDF). autosar.org. AutoSAR. 2016-11-30. Retrieved 2019-07-16.
  9. ↑ MISRA publications
  10. 1 2 "Fact Sheet: MISRA C:2012 (PDF)" (PDF). programmingresearch.com. Retrieved 10 June 2013.
  11. ↑ "MISRA Compliance:2016 (PDF)". MISRA. Retrieved 22 July 2016.
  12. ↑ "MISRA Compliance:2020 (PDF)" (PDF). MISRA. Retrieved 8 April 2020.
  13. ↑ "Achieving MISRA C:2012 Compliance". Parasoft. Retrieved May 29, 2017.
  14. ↑ "A brief history of MISRA C". MISRA. 2013-03-18. Retrieved 2014-06-30.
  15. ↑ "MISRA C:2012 release date announced". MISRA. 26 February 2013. Retrieved 10 June 2013.
  16. ↑ "MISRA C:2012 - Amendment 1 (PDF)". MISRA. April 2016. Retrieved 31 October 2019.
  17. ↑ "MISRA C:2012 - Amendment 2 (PDF)". MISRA. February 2020. Retrieved 6 January 2021.
  18. ↑ "MISRA C:2012 - Addendum 1: Rule Mapping (PDF)".
  19. ↑ "MISRA C:2012 - Addendum 2: Coverage of MISRA C:2012 against ISO/IEC TS 17961:2013 "C Secure" (PDF)".
  20. ↑ "MISRA C:2012 - Addendum 3: Coverage of MISRA C:2012 against CERT C (PDF)".
  21. ↑ "MISRA".
  22. ↑ MISRA GitLab repository
  23. ↑ "MISRA C FAQ list." MISRA Consortium
  24. ↑ "Helix QAC for C and C++ | Perforce".
  25. ↑ "Clearlake Capital-Backed Perforce Software to Acquire Rogue Wave Software | Perforce".
  26. ↑ "Klocwork for C, C++, C#, Java, and JavaScript | Perforce".
  27. ↑ "C/C++ Built-in Test Configurations". Parasoft. 17 October 2022. Retrieved 9 March 2023.
  28. ↑ MISRA conformance checking, PC-lint/FlexeLint, Gimpel Software.
  29. ↑ Languages and Standards; iar.com
  30. 1 2 Language subsetting in an industrial context: a comparison of MISRA C 1998 and MISRA C; Les Hatton; University of Kingston; 2004.
  31. ↑ Assessing the Value of Coding Standards: An Empirical Study; C.J. Boogerd and L. Moonen; Delft University of Technology; 2008.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.