nicbald venedyct giovanni

0 views

Skip to first unread message

Tabita Knezevic

unread,

Aug 2, 2024, 8:03:37 PM8/2/24

to rielesdina

MISRA C:2012 is the third edition of MISRA C, published in 2012. It was written for C99 and C90 to provide better rationales for the guidelines and more precise descriptions. There are 143 rules, including:

MISRA C 2012 Amendment 3 was released in 2022 and adds guidance for C11 and C18 new features previously prevented by Rule 1.4. It adds 24 new rules and 1 new directive. This makes a total of 182 rules and 18 directives, for a total of 200 guidelines.

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]

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.

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:

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.

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:

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]

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.

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.

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.

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.

The MISRA C and MISRA C++ standards are a set of coding guidelines for the C and C++ programing languages that promote safety, security, and reliability in embedded system software. These guidelines are published by the Motor Industry Software Reliability Association (MISRA), a collaboration between vehicle manufacturers, component suppliers, and engineering consultancies. MISRA C guidelines, which originally targeted only the automotive industry, are now widely accepted and used in other industries such as aerospace and defense, industrial automation, and medical devices.

Most engineering organizations originally applied MISRA C and C++ standards to their hand-written C and C++ code. The MISRA standards have since been refined to accommodate the use of code generated from tools such as MATLAB and Simulink.

The C programming language is one of the most popular languages for embedded systems because of its intrinsic capabilities, such as performance, portability across hardware, and direct control on memory. However, certain C language constructs can lead to programming errors, undefined behavior, or implementation-defined behavior.

For example, C99 allows the use of initializer lists with expressions that can be evaluated only at run-time. However, the order in which the elements of the list are evaluated is not defined. Take this simple case:

The first edition of MISRA C was published in 1998. MISRA has since published two more editions, MISRA C:2004 and MISRA C:2012, and two amendments to MISRA C:2012. With each publication, MISRA has added new guidelines and provided more direction on how to achieve MISRA C compliance.

To address the growing use of modeling and automatic code generation tools such as Simulink, Stateflow, and Embedded Coder, MISRA published MISRA AC AGC in November of 2007. This document contains guidance on how to apply the MISRA-C:2004 rules in a code generation tool. This guidance was recently incorporated into MISRA C:2012.

Each project should create a compliance matrix that documents all guidelines and the corresponding enforcement methods. Manual review is required for guidelines that cannot be fully enforced using a tool such as a static code analyzer.

MISRA allows deviations from guidelines in situations where those guidelines might be impractical or unreasonable to follow. All such deviations must be documented and authorized. The documentation should include the guideline, situation, rationale for deviation, and risk analysis.

Code generation simplifies the MISRA C compliance process. Automatic code generators list guidelines that will not be violated by the generated code. To generate code that is MISRA-compliant, the engineer must use appropriate modeling patterns and code generation options. MISRA C:2012 provides guidance on which rules are less applicable for generated code. For example, rules that focus on readability are less important since generated code is not supposed to be modified by humans.

The MISRA C rules can be checked manually, but looking at hundreds of thousands, or sometimes millions of lines of code for rule violations is not practical. Therefore, MISRA C recommends the use of static code analysis tools to ensure compliance. MISRA C also recommends that software developers check for compliance as soon as code is written and before code review or unit testing. Addressing violations earlier in the development lifecycle is much less expensive and far more efficient than delaying until later stages.

To assist users further in their efforts to achieve MISRA C compliance, MathWorks maintains a feasibility analysis package and recommendations for generating MISRA C code when using Embedded Coder with Simulink and Stateflow models. The MISRA C analysis package includes:

The MISRA consortium consists of a group of likeminded individuals. As a collective, they provide guidelines for developing embedded software associated with safety- and security-related electronic systems, and standalone software. Compliance with MISRA Guidelines helps developers to produce code that is robust, maintainable, and more portable.

Working group members are now drawn from industries and consultants across the safety-related embedded systems world, including the automotive sector. LDRA have active representatives on several of those working groups, including the chairpersons of MISRA C and MISRA C++ working groups.

That tradition continues up until today. Andrew Banks is a Technical Specialist with LDRA and a long standing member of the MISRA working groups. He has been involved with MISRA since 2007 and has been Chairman of the MISRA C Working Group since early 2013.

March 2023 saw the introduction of MISRA C:2012 Amendment 4 (AMD4). It specifies rules and directives for multithreading and atomic types as well as clarifications on existing guidance to better align with how developers use the C language today.

It also saw the announcement of MISRA C:2023 which consolidates the previous versions of the Guidelines, amendments (including AMD4), and addenda into a single, comprehensive edition to facilitate compliance.

The number of rules and directives for each language varies in each edition. As an example, MISRA C:2012 (Third Edition, First Revision) included 175 rules of which 16 are classified as Mandatory, 120 are Required, and 39 are Advisory.

There are many rules in the MISRA Guidelines. In theory it might be possible to check by inspection that they have all been implemented, but that would be a highly skilled, labour-intensive, and error-prone job. MISRA checkers such as those provided by LDRA automate that process by means of static analysis.

Static analysis can be used to ensure MISRA compliance as code is developed, and automatically applied during unit, system, or integration test to ensure that compliance achieved at the outset is not compromised throughout the development processes associated with the software development life cycle. All versions of the MISRA rules are completely integrated into LDRA tools for efficient MISRA checking within a familiar embedded software development environment.