Alle Fakten zur ISO 26262

Anbieter zum Thema

MicroConsult Academy GmbH

Heitec AG

ISH Ingenieursozietät GmbH

Robert Bosch GmbH

In Hinblick auf Automotive SPICE oder CMMI: Wo gibt es Berührungspunkte, wie grenzt die ISO 26262 sich ab?

Die Frage, inwieweit eine schon erfolgte Implementierung von CMMI oder Automotive SPICE für die Erfüllung der ISO 26262 ausreichend ist, wird regelmäßig gestellt. Eine konkrete Aussage ist nicht möglich, ohne detailliert die Implementierung in der entsprechend Organisation zu analysieren. Zum Beispiel stellt CMMI ein abstraktes Prozessmodell dar, das einem nur vorgibt, was man zu erfüllen hat, aber nicht wie. Der Interpretationsspielraum ist sehr groß. Ohne die konkrete Implementierung zu kennen kann man höchstens sagen, dass bestimmte Prozessgebiete einen Beitrag zur Erfüllung der ISO 26262 leisten. Ein Vorteil ist sicher, dass bereits Organisationsstrukturen zur Verfügung stehen, denen die Umsetzung abstrakter Modelle im Entwicklungsprozess bekannt sind.

Die ISO 26262 stellt eine Kombination eines Prozessmodells (Bände 2, 8 und 9) und eines Lebenszyklusmodells dar. Sowohl in Automotive SPICE als auch bei CMMI wird die Definition eines Lebenszyklus gefordert. Sollte es sich bei dem zu entwickelnden Produkt um eines mit Sicherheitsrelevanz handeln, dann muss der Sicherheitslebenszyklus, wie er in der ISO 26262 beschrieben ist, angewandt werden.

Können Sie Beispiele nennen, welche Bereiche der Band „Hardwareentwicklung“ der ISO 26262 regelt.

Im Band 5, der Vorgaben an die Hardwareentwicklung beschreibt, liegt der Schwerpunkt auf Metriken zur Designab-sicherung. Neben einer absoluten Metrik zur Ausfallwahrscheinlichkeit aller Hardwarekomponenten eines Systems finden sich auch relative Metriken, die auf dem Verhältnis von „sicherheitsrelevanten“ zu „guten“ Fehlern beruhen. Hier sehen sie auch gleich ein großes Problem dieser Metriken: Im Automobil gibt es keine „guten“ Fehler. Das Ziel einer qualitativ hochwertigen Entwicklung ist immer, alle Fehler zu minimieren. Wenn Sie jetzt aber die Anzahl ihrer „guten“ Fehler minimieren, auch wenn dies vorrrangig „nur“ dazu dient, die Zuverlässigkeit zu steigern, können Sie möglicherweise auch bei gleichzeitig weniger „sicherheitsrelevanten“ Fehlern die geforderte Zielzahl der Metrik nicht mehr nachweisen. In diesem Fall werden Sie dafür bestraft, ein in jedem Belang besseres Produkt entwickelt zu haben.

Band 8 der ISO 26262 regelt „Supporting Processes“. Darunter fallen Aspekte wie die Toolqualifikation. Welche Methoden stellen Sie sich vor?

Bei der Qualifizierung von Tools geht es darum, das Vertrauen in die eingesetzten Tools zu erhöhen. Betrachtet werden alle Tools, deren Funktionen in Software abgebildet sind, unabhängig davon, ob sie bei der Entwicklung von Hard-, Software oder in der Systementwicklung eingesetzt werden. Die Qualifizierung erfolgt in zwei Schritten. Zunächst ist eine Klassifizierung vorzunehmen. Aus diesem Ergebnis leitet sich ab, ob weitere Maßnahmen zur Qualifizierung erforderlich sind. Bei der Klassifizierung werden die Use-cases des Tools und deren potenzielle Fehlerfälle beschrieben.

Nach der Entscheidung, ob sich ein solcher Fehler im Endprodukt grundsätzlich sicherheitskritisch auswirken kann, wird die Wahrscheinlichkeit ermittelt, mit der dieser Fehler aufgedeckt werden kann. Dabei ist es egal, ob der Fehler durch vorgelagerte Prozessschritte verhindert oder innerhalb des Tools bzw. durch nachgelagerte Prozessschritte entdeckt wird. Aus der Entdeckungswahrscheinlichkeit leitet sich dann direkt der „Tool Confidence Level“ ab, der die Notwendigkeit von Qualifizierungsmaßnahmen bestimmt. Dabei handelt es sich beispielsweise um Nachweise des bei der Entwicklung des Tools angewandten Entwicklungsprozesses oder der Betriebsbewährtheit, aber möglicherweise auch um eine zusätzliche Validierung des Tools.

(ID:334424)