Assessment der Funktionalen Sicherheit gemäß ISO 26262:2018

Die ISO 26262 empfiehlt, das Assessment der funktionalen Sicherheit stufenweise (progressively) parallel zur Entwicklung durchzuführen. Dies ist ein sehr wichtiger Ratschlag, den Sie unbedingt umsetzen sollten. Aber wie?

Dazu möchte ich verschiedene Fälle unterscheiden.

Neuentwicklung des Produkts

Dem Fahrzeughersteller würde ich empfehlen, das erste Zwischenassessment nach der Gefährdungs- und Risikoanalyse und der Erstellung des Sicherheitsplans zu machen. Das erste Zwischenassessment eines Zulieferers würde ich nach der ersten Version seines Sicherheitsplans machen. Eine Alternative dazu wären auch Bestätigungsreviews der Gefährdungs- und Risikoanalyse und des Sicherheitsplans. Ein zweites Zwischenassessment wäre nach der Erstellung des Sicherheitskonzepts sinnvoll, um hier nicht später einen komplett anderen Ansatz wählen zu müssen. Ein drittes Zwischenassessment empfehle ich zu einem Zeitpunkt, wo die Steuergeräte bereits in Vorserienfahrzeugen verbaut werden, was typischerweise einem Assessment des C-Musters entspricht. Das abschließende Assessment bewertet das Produkt, so wie es in Serie gefertigt werden soll, also vor der Produktionsfreigabe.

Funktionale Weiterentwicklung eines bestehenden Produkts:

Wenn dabei das Sicherheitskonzept unverändert bleibt, dann genügen ein oder zwei Zwischenassessments und ein abschließendes Assessment.

Einfaches Projekt (beispielsweise wird lediglich die Kalibrierung eines Produkts auf ein neues Fahrzeug vorgenommen):

Hier genügt ein einziges abschließendes Assessment.

Was lernen wir daraus?

Die Assessmentplanung ist stark von der Neuheit des Produkts abhängig. Überlegen Sie sich genau, wie hoch das Risiko ist, wenn Sie den Assessor nicht früher, sondern später einbinden und weniger Zwischenassessments machen.

Führen Sie ein Zwischenassessment durch, wenn eine spätere Assessorenkritik Ihnen hohe Kosten verursachen würde.

Was ist bei der Beauftragung eines Assessments der funktionalen Sicherheit zu beachten?

Ein Ziel muss erreicht werden, bevor ein Assessment als fest vereinbart zwischen Auftraggeber und Assessor gilt: Beide Parteien müssen ein gemeinsames Verständnis über das Assessment haben.

Dieses Verständnis erreicht man in aller Regel aber nicht durch eine simple Abfolge von Ausschreibung, Angebot und Assessment-Beauftragung. Fehlt eine gemeinsame Klärung einer Reihe von Themen, so ist das kein Modell für eine erfolgversprechende Durchführung zur Zufriedenheit beider Parteien. Interaktion muss stattfinden. Insbesondere müssen folgende Fragestellungen geklärt sein:

• Auch wenn der Auftraggeber nach einem Assessment der funktionalen Sicherheit fragt, ist nicht sicher, dass er auch das meint, was der Assessor darunter versteht. Klären Sie als Assessor, ob eine Gap Analyse, ein Prozessaudit, ein oder mehrere Bestätigungsreviews von Arbeitsprodukten, ein Zwischenassessment, ein abschließendes Assessment oder irgendeine Kombination dieser Dinge gemeint ist. Ich habe es oft erlebt, dass eine Anfrage anders gemeint war, als sie schriftlich gestellt wurde.
• Klären Sie die wichtigsten Stakeholder, insbesondere bei internationalen Konstellationen.
• Was ist die Erwartungshaltung aus Sicht des Auftraggebers? Soll abschließend die funktionale Sicherheit bestätigt werden? Oder sollen noch bestehende Defizite aufgezeigt werden? Oder sollen nur bestimme Teilergebnisse begutachtet werden?
• In welcher Projektphase befindet sich das Projekt?
• Zur Festlegung, gegen welche Teile und Klauseln der ISO geprüft werden muss, ist es essenziell zu wissen, wieviel Übernahme, Modifikation oder Neuentwicklung hier stattfindet. Welche Technologie im Verantwortungsbereich des Auftraggebers liegt. Ich bezeichne dies als den technischen Umfang (technical scope) der Entwicklung.
• Als Assessor müssen Sie beispielsweise entscheiden, ob Sie gegen die Klausel „Change management“ prüfen, oder ob eine Impact Analyse vorliegt, die das Durchlaufen großer Teile der ISO 26262 erfordert. Um richtig zu planen, müssen Sie den ISO Scope kennen.
• Sie sollten den höchster ASIL der Anforderungen kennen.
• Versuchen Sie einen groben Überblick über die Evidenzen, die man Ihnen vorlegen wird, zu erhalten. Und in welchem Status sich diese befinden. Zum Beispiel, ist der Sicherheitsnachweis erst im Entwurf, bereits fertig gereviewt oder bereits durch eine unabhängige Person bestätigt?
• Nach welchem Assessmentprozess soll das Assessment ablaufen? Nach demjenigen des Auftraggebers oder nach dem Prozess des Assessors?
• Wie sieht die Durchführung aus? Gibt es vorab Dokumente? An welchen Standorten muss geprüft werden? Wie viele Tage vor Ort sind notwendig? Welche Meilensteine gibt es?
• Was soll vorab geliefert und geprüft werden?
• Kommerziell sollten sich Auftraggeber und Assessor über den Preis und die Kriterien für die Bezahlung einig sein. Jedenfalls darf die Bezahlung nicht von einem positiven Assessmentbericht abhängen.
• Klären Sie, ob eine Nachprüfung nach kleineren Korrekturen in der Beauftragung und dem Preis enthalten sind.

Ich rate Ihnen, sich ein Template mit all diesen Fragen zu erstellen. Optional: Machen Sie die ausgefüllte Fragenliste zu einem Anhang des kommerziellen Vertrags.

Zunächst rate ich Ihnen, den Assessmentprozess aufzuschreiben. Er könnte beispielsweise so strukturiert sein, wie Sie in der folgenden Grafik sehen.

Der Prozess unterscheidet zwischen der Vorbereitungsphase (preparation phase), der Durchführung (implementation), dem Bericht (reporting) und einer optionalen Korrektur (correction). Die Details der Grafik zu erläutern, würde an dieser Stelle jedoch zu weit führen.

Ich empfehle Ihnen, zum Prozess eine Reihe von nützlichen Templates und Checklisten zu schaffen. Dazu könnten zum Beispiel die folgenden gehören:

• Da ist zunächst der Assessmentprozess selbst, zusammen mit seinen Regeln zum Tailoring.
• Ein Template, mit all den Fragen zur Beauftragung (order)
• Eine Readiness-Checkliste für Assessments
• Ein Template für die Zeitplanung
• Ein Template zur Einladung von Stakeholdern zum Assessment
• Ein Tool mit den Kriterien für das Assessment zur Sammlung von Evidenzen
• Ein Template mit Hinweisen zum Briefing des Assessmentteams beim Einsatz von Assistenten
• Ein Template für eine Kick-Off Präsentation
• Ein Template für eine Abschlusspräsentation
• Ein Template für den Assessmentbericht
• Streng genommen gibt es so etwas wie ein Zertifikat als Ergebnis eines Assessments nicht. Man kann aber ein Template vorhalten und die wichtigsten Parameter und Ergebnisse des Assessmentberichts auf einer Seite dokumentieren, und dies als Zertifikat bezeichnen.
• Ein Lessons Learned Template unterstützt dabei, für zukünftige Assessments zu lernen.
• Schließlich noch ein Werkzeug, um Assessmentfindings systematisch zu adressieren. Ich will das einmal als „Tool for managing corrective actions“ bezeichnen.

So nun zur Frage, wie das Assessment praktisch ablaufen kann.

Ich empfehle, Schlüsselarbeitsprodukte offline vor einer Onsite-Phase zu prüfen. Dazu würde ich den Sicherheitsplan, Development Interface Agreements, Impact Analysen, das Sicherheitskonzept und den Sicherheitsnachweis (safety case) zählen.

Für die Onsite-Phase empfehle ich Ihnen eine Serie von Interviews zu den einzelnen Teilen der ISO 26262. Im Interview lässt der Assessor sich erläutern, wie die ISO 26262 erfüllt wurde. Dabei werden Nachweise durchgesprochen. Als Assessor muss ich die für die Beurteilung relevanten Stellen interaktiv mit den beteiligten Personen herausarbeiten. Werden Defizite erkannt, so hält man diese idealerweise gemeinsam fest. Das schafft Akzeptanz für das Assessmentergebnis. Gegebenenfalls nimmt man sich als Assessor aber auch außerhalb des Interviews Zeit, Dokumente detailliert zu prüfen.

Als Vorgehensweise für ein abschließendes Assessment möchte ich empfehlen, den Sicherheitsnachweis sukzessive durchzusprechen. Denn zu diesem Zeitpunkt muss der Sicherheitsnachweis ja vorliegen. Die Aufgabe des Assessors ist es zu verstehen, wie die Entwickler die Sicherheit begründen. Beachten Sie, dass es eben genau nicht die Aufgabe des Assessors ist, die Argumente für die Sicherheit zu liefern. Das ist Aufgabe der Entwicklung. Aufgabe des Assessors ist es, die Argumentation zu bewerten.

Der wesentlichste Unterschied zwischen einem Audit der funktionalen Sicherheit und einem Assessment der funktionalen Sicherheit besteht für mich darin, dass beim Assessment die technische Lösung zum Umgang mit systematischen Fehlern und zufälligen Hardwarefehlern vom Assessor verstanden und bewertet werden muss. Idealerweise liegen zum abschließenden Assessment die Bestätigungsreviews (confirmation reviews) der Schlüssel-Arbeitsprodukte und der Auditbericht zu den Prozessen vor, so dass der Assessor diese nur noch formal prüft und sich ansonsten aber auf die Sicherheitsmaßnahmen konzentrieren kann. Durchaus üblich sind aber auch Assessments, bei denen der Assessor auch Bestätigungsreviews durchführt, da er die notwendige Unabhängigkeit hat. Dann muss entsprechend mehr Zeit eingeplant werden.

Über eines müssen sich alle Beteiligten im Klaren sein. Ein Assessor kann Arbeitsprodukte und Software nicht so intensiv nach allen Kriterien prüfen, wie es durch die Reviews und Tests im Laufe der Entwicklung erfolgen muss. Er ist nicht der Spezialist für das Produkt und kann in einem Assessment auch nicht die Qualitätssicherung der Entwicklung ersetzen.

Wichtig ist es, den Status der gelieferten Nachweise (evidences) zu verstehen. Wird ein Dokument nur im Status ‘Entwurf‘ vorgelegt? Was sind dessen Inhalte dann wert? Ist es gereviewt und freigegeben? Gibt es Reviewdokumentation? Sind die richtigen Reviewkriterien angewendet worden? Waren notwendige Rollen intensiv genug eingebunden? Gibt es vielleicht sogar ein Bestätigungsreview einer unabhängigen Person?

Große Probleme haben Firmen häufig mit einem sauberen Versions- und Konfigurationsmanagement. Für ein abschließendes Assessment zur Produktionsfreigabe müssen Sie als Assessor prüfen, dass Versionen konsistent sind.

Bezieht sich das vorgelegte Bestätigungsreview tatsächlich auf die freigegebene Version des Sicherheitsnachweises? Beziehen sich die positiven Testergebnisse tatsächlich auf die Software und die Kalibrierungsdaten, die in der Baseline für die Produktionsfreigabe enthalten sind?

Wenn es zum Beispiel aufgrund von Reisebeschränkungen nicht möglich ist, vor Ort bei der Entwicklung zu assessieren, dann kommen als Ersatz auch Video-Sessions in Frage. Planen Sie dann aber ganz anders: Kürzere Interviews, längere Pausen. Insgesamt wird das Assessment länger dauern.

Im Bericht sollte stehen, wie Sie als Assessor vorgegangen sind. Die Bewertungskriterien sollten erläutern sein. Beschreiben Sie, was Sie geprüft haben. Welche Dokumente Ihnen in welcher Version vorgelegt wurden? Damit wird klar, worauf Ihre Bewertung basiert.

Sie müssen die wesentlichen Aussagen zu den einzelnen Kriterien der ISO 26262 ausformulieren. Für den Leser des Berichts muss klar sein, ob ein Punkt ein Kommentar, eine Übereinstimmung oder eine Abweichung vom Kriterium ist.

Der abschließende Assessmentbericht muss eine von drei möglichen Beurteilungen enthalten:

• Wenn die Zielsetzungen der ISO 26262 bedingungslos erfüllt sind, dann spricht der Bericht eine „Empfehlung zur Annahme der funktionalen Sicherheit“ (recommendation for acceptance of functional safety) aus.
• Wenn der Assessor davon überzeugt ist, dass das Produkt funktional sicher ist, er oder sie aber noch die ein oder andere konkret benannte Bedingung aufstellt, dann spricht er bzw. sie eine „bedingte Empfehlung zur Annahme“ (recommendation for conditional acceptance) aus.

• Wenn der Assessor dagegen von der Sicherheit nicht überzeugt ist, dann wird das Assessmentergebnis eine Zurückweisung (rejection) sein. Die entwickelnde Organisation ist dann aufgefordert zu korrigieren und das Assessment zu wiederholen.