Funktionale Sicherheit über den SOP hinaus

Der Bereich der Funktionalen Sicherheit (ISO 26262) muss über den Start eines Produktes (SOP, Start of Production) hinaus betrachtet werden. Sonstige Modelle- und Entwicklungsvorgehen führen in der Regel bis zur Fertigstellung des Produktes und betrachten damit die Entwicklung. Danach geht das Produkt aus der Entwicklung in den Betrieb über und oft aus dem Fokus solcher Modelle.

Den Ernstfall in der Automobilbranche wünscht sich niemand. Plötzlich versagt ein sicherheitsrelevantes Teil im Auto. Hat der Hersteller – und natürlich der betroffene Fahrer – Glück, dann gibt es keinen Personen-, sondern lediglich “nur” Sachschaden. Doch auch dieser Umstand macht es für einen Autohersteller nicht besser. Bei solchen Schäden gilt die Beweislastumkehr. Daher muss der Hersteller nachweisen, dass er alles Mögliche nach dem Stand der Technik unternommen hat, um dieses Problem zu vermeiden. Über diese Thematik habe ich bereits einige Artikel unter dem ISO 26262 Tag veröffentlicht.

Solche kritischen Probleme treten selbstverständlich nie dann auf, wenn die Software entwickelt wird. Irgendwann findet der Eintritt eines solchen Problems plötzlich im Feld (also nach dem das Auto die Entwicklung verlassen hat) statt. Das kann bspw. nach 5 Jahren, in nur einem ganz bestimmten Zusammenspiel von Komponenten und externen Einflüssen der Fall sein, so will es Murphey’s Gesetz. Natürlich sind genau das die schwierigsten Fehler. An diesem Punkt nützt es Ihnen nicht alleine, dass Sie nach SPICE oder CMMI entwickelt haben. Dadurch haben Sie natürlich entsprechend gute und saubere Prozesse. Allerdings müssen Sie dann unter Umständen nachweisen, warum eine bestimmte Entscheidung in genau dieser Art und Weise getroffen worden ist, wie sie getroffen wurde. Spannend wird es dann, wenn Sie in der Lage sein müssen, die Entscheidungen zu rekonstruieren:

  • Wie können Entscheidungen im Prozess modelliert werden, dass Sie rekonstruierbar sind? Dabei sollten Sie sich überlegen, wie der Prozess zur Entscheidungsfindung auszusehen hat.
  • Können Entscheidungen mit einer Baseline versehen werden?
  • Wie lange können Entscheidungen rekonstruiert werden? Da die Funktionale Sicherheit durch die ISO 26262 im Bereich der Automobilbranche viele Jahre sichergestellt werden muss, ist der Punkt wichtig.
  • Können die Entscheidungsalternativen leicht dargestellt werden? Wenn Sie sich für die Methode A oder aber den Compiler C entschieden haben, wissen Sie eindeutig warum?
  • Anhand welcher Kriterien sind die Entscheidungen für oder gegen die Auswahl gefallen?

Wenn Sie dieser Fragestellung nachgehen, stellen Sie schnell fest, dass es einiges an Logistik und Infrastruktur benötigt um solche Fragestellungen zu betrachten. Optimal ist es, wenn Sie zu Beginn die Möglichkeit haben die ISO 26262 mit in Ihre Entwicklungsaktivitäten einzubeziehen. Denn gerade im Automobilbereich wird die Funktionale Sicherheit dieses Jahr (2011) relevant und als Norm entgültig veröffentlicht.

The do’s and don’ts

Dos …

Achten Sie auf die Nachverfolgbarkeit und das Baselining von Entscheidungen.
Beziehen Sie ISO 26262 Anforderungen mit in die Prozessdefinition mit ein.

…and don’ts

Ihre Aktivitäten zur Funktionalen Sicherheit (ISO 26262) dürfen nicht am SOP enden.
Unterschätzen Sie nicht die Wichtigkeit und den Aufwand der ISO26262.

Weitere Informationen zu ISO26262 und Automotive

Teilen und Kommunizieren

 
[p1 size='tall'] 

,