Funktionale Sicherheit nach ISO 26262
ASIL-A, ASIL-B, ASIL-C und ASIL-D
Der ISO 26262 Standard ist die Adaption der IEC 61508 auf die spezifischen Bedürfnisse von elektrischen und elektronischen (E/E) Systemen in Straßenfahrzeugen.
Die Axivion Suite deckt perfekt Verifikations-Schritte in der ISO 26262:2018 mit Fokus auf statischen Prüfungen von Code und Entwurf ab.
Das Statische Codeanalyse (SCA) Package der Axivion Suite ist für den Einsatz bei der Entwicklung von Safety-Systemen nach ISO 26262 bis ASIL D von der SGS-TÜV Saar GmbH zertifiziert.
Abdeckung des Safety Cases
Der Entwicklungsprozess beeinflusst direkt, ob die geforderte funktionale Sicherheit erreicht wird (z.B. durch Aktivitäten wie Anforderungsspezifikation, Entwurf, Implementierung, Verifikation, Validierung und Konfiguration).
Jedes Projekt im Bereich ISO 26262 kommt mit individuellen Safety Goals. Die Axivion Suite wird integraler Bestandteil des Safety Case Ihres Projekts bezüglich statischer Codeanalyse und Architekturverifikation.
Lage im V-Modell
Die Axivion Suite unterstützt speziell die Konformität nach ISO 26262-6:2018 – product development at the software level. Im V-Modell findet sich das Anwendungsgebiet der Axivion Suite in den Bereichen Software Unit Verification, Software Integration, Verification and Testing of Embedded Software:
Je nach ASIL Einstufung des zu entwickelnden Produkts kann die Axivion Suite von QM über ASIL A bis ASIl D eingesetzt werden.
Unterstützung von Modelling and Coding Guidelines
Die Axivion Suite bietet Unterstützung, um die folgenden Aspekte sicherzustellen:
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.
Diese Anforderungen aus der ISO 26262-6:2018 (Table 1 — Topics to be covered by modelling and coding guidelines) werden durch die in der Axivion Suite enthaltenen Architektur-Analyse, Klon Management, Zyklenerkennung, das Erkennen nicht erreichbaren Codes, Metriken, Codierrichtlinien (MISRA C, MISRA C++, AUTOSAR C++14, CERT) und statische Codeanalyse erfüllt.
Analysen auf System-Ebene und für den täglichen Einsatz
Die Axivion Suite integriert sich in fast jedes CI-System. So lassen sich vergleichbare und wiederholbare Analyseergebnisse erzielen. Mittels des Delta-Mechanismus der Axivion Suite ist auf den gewonnenen Analysedaten aufbauend eine einfache Verfolgung von Veränderungen über die Zeit möglich. Zugleich kann die Axivion Suite lokale Analysen (z.B. integriert in die eingesetzte IDE) durchführen, wodurch schnelle Checks und kurze Round-Trip-Zeiten in der Entwicklung erreicht werden.
Architektur-Analysen
Die Architektur-Analyse der Axivion Suite kann Entwurfs- und Architekturbeschreibungen in informaler Notation (z.B. in Form von Box and Arrow Sketches) oder semi-formaler oder formaler Notation (z.B. in Form von UML-Modellen) nutzen, um die Implementierung in C oder C++ dagegen zu prüfen. Mittels des hypothesengetriebenen Ansatzes zur Architekturwiedergewinnung lassen sich auch Systeme mit einer prüfbaren Architektur versehen, deren gewollte Architektur nur in den Köpfen oder als natürlichsprachlicher Text vorliegt.
Wenn AUTOSAR und arxml ein Thema für Sie ist: Die Axivion Suite kann arxml-Definitionen importieren und diese – zusammen mit dem Quellcode – gegen die vorgegebene Architektur- und Design-Beschreibung prüfen (beispielsweise in Form von Rhapsody und Enterprise Architect UML-Modellen).
Freedom from Interference
Freedom from Interference (ISO 26262-1:2018 clause 3.65) ist ein wichtiges Ziel in Safety-Projekten. Die Architekturprüfung kann dabei helfen, potentielle programmatische Zusammenhänge auf Quellsprachebene zwischen als aufgrund von freedom of interference-Forderungen eigentlich als unabhängig vorauszusetzenden Komponenten bereits früh auf der Code-Ebene zu identifizieren. Dies geschieht, indem fehlgerichtete Aufrufe zwischen Komponenten mit mixed criticality ASIL (Automotive Safety Integrity Level) Einstufung bzw. zwischen ASIL- und QM-Partitionen aufgespürt werden. Dadurch kann die Häufigkeit von MMU/MPU-Exceptions in den späteren Entwicklungsphasen mit dynamischer Ausführung reduziert und damit Entwicklungszeit gespart werden.
Requirements Decomposition
Die Softwarearchitektur spielt auch eine entscheidende Rolle, wenn die in 26262-9:2018 section 5 definierte Requirements Decomposition (auch ASIL Dekomposition genannt) eingesetzt wird. Ein geeignetes Konzept kann hier zu großen Kosteneinsparungen führen. Allerdings muss sichergestellt werden, dass die Implementierung die in der Architektur aufgrund der heruntergebrochenen Anforderungen geforderte Unabhängigkeit tatsächlich umsetzt. Diese Prüfung ist bezogen auf den Source-Code mit der Architekturverifikation von Axivion möglich.
Tool Qualification
Abhängig vom Use Case des Kunden muss die Axivion Suite entsprechend dem erforderlichen TCL-Level qualifiziert werden. Zu diesem Zweck bietet Axivion das Tool Qualification Kit an.
Das Kit enthält eine Zusammenstellung von Codeverstößen gegen MISRA, CERT, and AUTOSAR C++14, um das Setup einer Analyse für beliebige ASIL-Level zu qualifizieren.
Eine Safety-Analyse mit der Axivion Suite kombiniert alle Stärken und Features wie die Architektur-Analyse, Klon Management, Metrikberechnung, Styleguide-Checks (MISRA, CERT, AUTOSAR C++14), Erkennung nicht erreichbaren Codes und Zyklus-Erkennung. Mit dem Tool Qualification Kit ist die Axivion Suite für die Anforderungen des jeweils benötigten TCL und für jedes ASIL-Level gerüstet.
Success Stories
Eine Auswahl unserer Success Stories zu ISO 26262
Wir haben mehrere Tools für die statische Analyse evaluiert, und die Axivion Suite ist in unseren Tests eindeutig herausgestochen. Das Tool hat hinsichtlich der Abdeckung von AUTOSAR C++ 14 am besten abgeschnitten und hat uns durch seine Benutzerfreundlichkeit, die Kontrollfluss- und Datenflussanalyse sowie die Reporterstellung überzeugt. Die Axivion Suite ist bereits ein fester Bestandteil in unserem Entwicklungsablauf und ein wertvoller Bestandteil unserer DevOps-Pipeline.
Dejan Pangercic, CTO und Mitbegründer, Apex.AI