ISO 26262 ASIL Dekomposition – Chancen und Risiken!
ISO 26262 ASIL Dekomposition: Der Teil 9 der ISO 26262 definiert das Schema, wenn man ein Requirement mit einem bestimmten ASIL Level in zwei Requirements mit niedrigeren ASIL Level aufteilen will. Im nachfolgenden Beitrage beschäftige ich mich mit der Frage wann die ASIL Dekomposition in der Praxis angewendet werden kann und welche Vorteile sich dann ergeben. Gleichzeitig wird aber auch manche Praxis in den Projekten bezüglich der ASIL Dekomposition kritisch hinterfragt.
Eine ganz wichtige Voraussetzung einer sinnvollen Anwendung der ASIL Dekomposition ist die Rückwirkungsfreiheit. Mehr zu diesem Thema finden Sie im Blogbeitrag ISO 26262 – Rückwirkungsfreiheit – Was ist das?
ISO 26262 ASIL Dekomposition in der Norm
Die ISO 26262 legt im Teil 9 in Kapitel 5.2 folgendes fest:
ASIL decomposition is a method of ASIL tailoring during the concept and development phases. During the safety requirements allocation process, benefit can be obtained from architectural decisions including the existence of sufficient independent architectural elements. This offers the opportunity
- To implement safety requirements redundantly by these independent architectural elements, and
- To assign a potentially lower ASIL to (some of) these decomposed safety requirements.
If the architectural elements are not sufficiently independent, then the redundant requirements and the architectural elements inherit the initial ASIL.
Chancen die sich durch die ASIL Dekomposition ergeben
Der technische Vorteil liegt in der Chance die Architektur des Systems, durch das Hinzufügen von Redundanz sicherer zu machen. Dies gilt allerdings nur, wenn Common Cause Fehler verhindert werden und die Rückwirkungsfreiheit sichergestellt wird.
Ein wirtschaftlicher Vorteil ergibt sich durch die Senkung der Entwicklungskosten. Die Erfahrung zeigt dass hier signifikante Kosteneinsparungen realisiert werden können. Dazu muss es gelingen, die ASIL Dekomposition so zu gestalten, dass der Großteil der Software als QM bzw. ASIL A/B statt ASIL C oder D eingestuft werden kann. Der Vorteil vergrößert sich weiter, wenn auch der Teil der Software der häufigen Änderungen unterliegt QM bzw. ASIL A/B Software wird.
Gute Sicherheitsarchitekturen zeichnen dadurch aus, dass nur ein kleiner und wenig änderungsanfälliger Teil der Software nach hohen ASIL Leveln entwickelt werden muss.
Fehler bei der ASIL Dekomposition
Der häufigste Fehler ergibt sich daraus, dass eine ASIL Dekomposition isoliert für einzelne Requirements durchgeführt wird, ohne die Software Architektur zu berücksichtigen.
In diesem Fall tritt dann keine Verbesserung der Architektur ein. Ebenso kann kein Kostenvorteil realisiert werden, da am Ende dann oft alle Requirements nach dem jeweils höchsten ASIL Level entwickelt werden müssen.
Ein weiterer Nachteil, der sich hier oft ergibt, ist dass bei einem solchen Vorgehen, das Entwicklungsteam den Sicherheitsprozess nicht mehr nachvollziehen kann und dann häufig die Akzeptanz für die ISO26262 Verfahren und Maßnahmen nicht mehr gewährleistet ist. Dies ist ein sehr schwerwiegender Nachteil, weil sich daraus viele weitere negativen Konsequenzen ergeben.
Ihre individuellen Fragen zur praktischen Umsetzung der ISO 26262 beantworten wir gerne in einem ersten, kostenlosen 30min Beratungsgespräch!
Vereinbaren Sie gleich einen Termin: Eine kurze Mail an info[at]heicon-ulm.de genügt, oder greifen Sie gleich zum Telefonhörer: +49 (0) 7353 981 781 (Mo bis Fr 08:00 – 18:00Uhr).
