Synchronise your safety-critical standards compliance
The development of QA-MISRA took place in close cooperation with experts in the MISRA committee. How can reported MISRA violations understood and improved? A comprehensive knowledge base is available to developers with extensive sample code sets, helping you to comply with the MISRA standard.
MISRA Compliance with QA-MISRA
MISRA C
MISRA C was originally developed to fulfil the need for a “restricted subset of a standardized programming language” identified in the 1994 “Development guidelines for vehicle based software” and against the background of the emerging use of C for developing embedded software in automotive applications. Once MISRA C was published its relevance to other applications was quickly noted and subsequent revisions of the standard have involved a number of experts from different industries and from tool vendors. Today MISRA C is the de facto standard for developing software in C where safety, security and code quality are important. Future developments of MISRA C will continue to extend support for newer versions of the language, and additional language features.
MISRA C++
MISRA C++ was originally published in June 2008 recognizing the growing use of C++ in critical applications. More recently work has commenced on a revision, and in 2017 it was announced that MISRA will integrate the AUTOSAR C++ guidelines in the new version of MISRA C++. The MISRA guidelines will incorporate the latest version of C++ language – C++17 – and, when available, its successor C++20.
A safer C / C++ language subset
All programming languages (including the ISO C and C++ language standards) contain uses which are incompletely specified or defined in a way that different compiler implementations can exhibit different behaviour for the same language construct. For safety-related or safety-critical systems, the MISRA ‘advisory’ and ‘required’ rules define a safer subset of grammar for the C and C++ languages to improve the portability, safety and security aspects of programs. These sub-sets are simply a restricted version of the full language, so standard commercial off the shelf too chains can be used with them, while providing safer programs which run as the programmer expected on different environments.
AUTOSAR Compliance with QA-MISRA
AUTOSAR ‘Adaptive Platform’ for Autonomous and Connected Vehicle Technologies
Connected and autonomous driving technologies are evolving at a rapid pace. These changes require completely new development requirements for both new and existing ECU software platforms.
The new ‘Adaptive Platform’ standard developed by AUTOSAR for highly autonomous and internet-connected driving technologies, helps to meet these rapidly growing market needs.
Some of the technologies driving the adaptive platform standard include:
CERT C, CERT C++ Compliance with QA-MISRA
Implement a disciplined, repeatable, and security-focused development process by incorporating application security measures into your design and coding processes. Our automated static analysis tool help you:
What is a software vulnerability?
CERT describes a vulnerability as a software defect that affects security when it is present in information systems.
The defect may be minor, in that it does not affect the performance or results produced by the software, but nevertheless may be exploited by an attack that results in a significant breach of security.
CERT estimates that up to 90% of reported security incidents result from the exploitation of defects in software code or design.
CWE Compliance with QA-MISRA
(Common Weakness Enumeration)
CWE provides a comprehensive repository of known weaknesses, while the CERT® C Secure Coding standard identifies insecure coding constructs that may expose a weakness in the software.
Not all CERT® C coding guidelines map directly to weaknesses in the CWE, because some coding errors can manifest themselves in various ways that do not directly correlate to any given weakness. Similarly, not all weaknesses identified by CWE are present in the coding standard as some are related to high level design.
CWE is made up of a series of views, such as the dictionary view and the development view. The CWE-734 view enumerates weaknesses addressed by the CERT® C Secure Coding Standard and includes 103 out of the 799 total CWEs. Developers can fully or partially prevent the weaknesses identified in CWE-734 if they adhere to the CERT® coding standard.
