Functional safety according to ISO 26262
ASIL-A, ASIL-B, ASIL-C and ASIL-D
The ISO 26262 standard is the adaptation of IEC 61508 to the specific needs of electrical and electronic (E/E) systems in road vehicles. Axivion Suite perfectly covers verification steps in ISO 26262:2018 with a focus on static code and design checks.
Covering the safety case / Safety Case Cover
The development process directly influences whether the required functional safety is achieved (e.g. through activities such as requirements specification, design, implementation, verification, validation, and configuration).
Every project in the field of ISO 26262 comes with individual Safety Goals. Axivion Suite becomes an integral part of your project’s safety case in terms of static code analysis and architecture verification.
Position in the V-model
Axivion Suite specifically supports compliance with ISO 26262-6:2018 – product development at the software level. In the V-Modell, Axivion Suite is used in the areas of software unit verification, software integration, verification, and testing of embedded software.
Depending on the ASIL classification of the product to be developed, Axivion Suite can be used from QM through ASIL-A to ASIl-D.
Support for Modelling and Coding Guidelines
Axivion Suite provides support to ensure the following aspects:
Enforce low complexity, use well trusted design principles, use of unambiguous graphical representation, use of language subset, enforcement of strong typing, use of defensive implementation techniques, use of style guides, use of naming conventions, and concurrency aspects.
These requirements from ISO 26262-6:2018 (Table 1 – Topics to be covered by modelling and coding guidelines) are met by the architecture analysis, clone management, cycle detection, detection of unreachable code, metrics, coding guidelines (MISRA C, MISRA C++, AUTOSAR C++14, CERT), and static code analysis included in Axivion Suite.
Analyses at system level and for day-to-day use
Axivion Suite integrates with almost any CI system. This allows comparable and repeatable analysis results to be achieved. By means of the delta mechanism of Axivion Suite, it is possible to easily track changes over time based on the obtained analysis data. At the same time, Axivion Suite can carry out local analyses (e.g. integrated into the IDE used), thus achieving fast checks and short round-trip times in development.
The architecture analysis of Axivion Suite can use design and architecture descriptions in informal notation (e.g. in the form of Box and Arrow Sketches) or semi-formal or formal notation (e.g. in the form of UML models) to check the implementation in C or C++ against them. By means of the hypothesis-driven approach to architecture recovery, even systems whose intended architecture exists only in the mind or as natural language text can be provided with a testable architecture.
If AUTOSAR and arxml is a topic for you: Axivion Suite can import arxml definitions and check them – together with the source code – against the given architecture and design description (for example in the form of Rhapsody and Enterprise Architect UML models).
Freedom from Interference
Freedom from Interference (ISO 26262-1:2018 clause 3.65) is an important goal in safety projects. The architecture check can help to identify potential programmatic interrelationships at source language level between components that are supposed to be independent due to freedom of interference requirements early on at code level. This is done by detecting misdirected calls between components with mixed criticality ASIL (Automotive Safety Integrity Level) classification or between ASIL and QM partitions. In this way, the frequency of MMU/MPU exceptions in the later development phases with dynamic execution are reduced and, thus saving development time.
The software architecture also plays a decisive role when using requirements decomposition (also called ASIL decomposition) as defined in 26262-9:2018 section 5. A suitable concept can lead to major cost savings here. However, it must be ensured that the implementation actually implements the independence required in the architecture due to the broken down requirements. This check is possible in relation to the source code with Axivion’s architecture verification.
Depending on the customer’s use case, the Axivion Suite must be qualified according to the required TCL level. For this purpose, Axivion offers a Tool Qualification Kit.
The kit contains a set of code violations against MISRA, CERT, and AUTOSAR C++14 to qualify the setup of an analysis for any ASIL level.
A safety analysis with Axivion Suite combines all strengths and features such as architecture analysis, clone management, metrics calculation, style guide checks (MISRA, CERT, AUTOSAR C++14), detection of dead code and cycle detection. With the Tool Qualification Kit, the Axivion Suite is equipped for the requirements of the TCL needed in each case and for each ASIL level.
A selection of Success Stories about ISO 26262
We have evaluated several static analysis tools, and Axivion Suite clearly stood out in our tests. The tool performed best in terms of AUTOSAR C++14 coverage and convinced us through its ease of use, control flow, and data analysis, and report generation. Axivion Suite has already become a mainstay component in our development workflow and a valuable component of our DevOps pipeline.
Dejan Pangercic, CTO and Co-Founder of Apex.AI