Warum muss ich nach ISO 26262 entwickeln?

Bei Projektmanagern oder Softwareentwicklern schleicht sich aktuell eventuell schon das ein oder andere Mal der Gedanke oder die Frage ein, warum die ISO 26262 eigentlich jetzt „plötzlich“ anzuwenden ist. Die Anwendung bedeutet offensichtlich Mehraufwand in der Entwicklung. Die bestehenden Prozesse müssen in den meisten Fällen angepasst oder erweitert werden und es muss nun viel mehr dokumentiert werden als in der Vergangenheit. So zumindest die Annahmen...   

Ist die Anwendung der ISO 26262 gesetzlich vorgeschrieben? 

Der Gesetzgeber zwingt den Unternehmen nicht direkt auf, dass die ISO 26262 bei der Fahrzeugentwicklung anzuwenden ist. Dennoch sind die Hersteller dafür verantwortlich, dass ihr Produkt den Sicherheitsanforderungen entspricht.  Das Produkthaftungsgesetz (ProdHaftG) schreibt hier vor, dass immer nach dem aktuellen „Stand der Wissenschaft und Technik“ entwickelt werden muss. Normen gelten im Allgemeinen ab ihrer Veröffentlichung und sollen genau diesen Stand abbilden. Kommt es also zu einem Schadensfall, muss der Entwickler nachweisen, dass er nach Vorgaben und Standards (FuSi hier mit eingeschlossen) entwickelt hat, die zu genau der Zeit des Inverkehrbringens auch gültig waren. Die ISO 26262 ist in der Automobilindustrie als genau ein solcher Standard etabliert. Da der Bereich der Haftbarkeit bis hin zur persönlichen Haftung, bei grober Fahrlässigkeit, reichen kann, sollten Entwicklungen von E/E-Systemen immer nach zugrundeliegenden  Norm erfolgen. Im Nachhinein lassen sich Verfehlungen in Fragen der Haftung ohne Dokumentation schwer bis gar nicht nachweisen. Das Thema Haftung ist daher häufig der wichtigste Grund für die Entwicklung nach ISO 26262 in Unternehmen.  

In der Vergangenheit gab es immer wieder eine hohe Anzahl an Rückrufaktionen von verschiedenen Automobilherstellern, da nach Auslieferung der Fahrzeuge erhebliche Fehler in wichtigen, sicherheitsrelevanten Bauteilen festgestellt wurden. Ein gutes Management der Funktionalen Sicherheit (Functional Safety Management), wie es die ISO 26262 fordert, unterstützt dabei, potenzielle Fehler in Bauteilen bereits im Vorfeld zu entdecken und zu vermeiden. Dazu gehören alle Umfänge und Maßnahmen, die einen Einfluss auf die sichere Funktionsweise des Bauteils haben. Wird zum Beispiel ein zusätzlicher Qualitätscheck bei der Entwicklung einer Software eines sicherheitsrelevanten Bauteils eingeführt, können Fehler hier prophylaktisch und damit sehr früh erkannt werden. Diese Teile gelangen dann gar nicht erst in den Verkehr und werden nicht verbaut oder ausgeliefert. Durch solche Maßnahmen lassen sich für den Hersteller teure und für den Kunden nervige Rückrufaktionen vermeiden.  Und insgesamt steigt dann auch die Produktqualität.  

Viele Automobilhersteller fordern inzwischen von ihren Zulieferern, dass die ISO-Norm in der Entwicklung angewendet wird. Andernfalls kommt ein Auftrag meist gar nicht erst zustande. Man kann hier durchaus von einer Markteintrittsbarriere sprechen.  

Durch Anforderungen ein sicheres Produkt entwickeln? Wie geht das? 

Die Argumente für eine ISO-konforme Produktentwicklung sind also sehr überzeugend. Aber können die zugrundeliegenden Anforderungen wirklich helfen, ein sicheres Produkt zu entwickeln? Strenge Vorgaben während der Entwicklung und Produktion fordern bereits im Produktentstehungsprozess genaue Planung und Dokumentation. Am Anfang passt das wahrscheinlich für die meisten nicht zusammen. Bei eingehender Betrachtung aber stellt man fest, dass durch eine Anwendung viele Aspekte schneller klar und verständlich werden und Missverständnissen gezielt vorgebeugt wird.  

Ein Beispiel hierzu sind die Sicherheitsanforderungen: Zu Beginn der Entwicklung nach ISO 26262 müssen sowohl die benötigten Funktionen, als auch die Sicherheitsziele klar definiert werden. Einem Softwareentwickler hilft diese Definition später, weil er basierend auf dieser genau weiß, welche Sicherheitsziele durch seine Software auf keinen Fall verletzt werden dürfen und welche Funktionen erforderlich sind. Die Entwicklung weiterer Funktionen ist an dieser Stelle nicht gewünscht. Dadurch wird in zweiter Instanz auch ein sogenanntes „overengineering“ vermieden, bei dem die Vielschichtigkeit der Software unnötig erhöht werden würde. Ein extrem komplexes Softwaresystem birgt in den meisten Fällen wiederum Sicherheitsrisiken, die unbedingt ausgeschlossen werden müssen.  

Muss ich jetzt alles ändern? 

Neben diesen Gründen für eine Anwendung gibt es sicherlich noch viele weitere. Zunächst stellt sich dem Manager allerdings vermutlich die Frage: Muss ich jetzt meine gesamte Entwicklung anders gestalten als vorher? Darauf ist die Antwort ganz klar: Nein! Wie du die ISO 26262 schrittweise in deinem Unternehmen einführen kannst und was dabei zu beachten ist, erfährst du im Laufe meiner nächsten Beiträge.