Startseite > Automotive > Verbesserung aktueller Praktiken für ISO 26262

Anforderungs-Management

Verbesserung aktueller Praktiken für ISO 26262

29. April 2011, 14:15 Uhr | Von Mark Pitchford und Bill St. Clair

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 3

Verschiedene Ebenen des Enwicklungsprozesses

Die High-Level-Anforderungen auf Ebene 1 können aus einer definitiven Aussage zum System bestehen, das entwickelt werden soll (z.B. ein ABS-Regelmodul), und den Funktionskriterien, die es erfüllen muss (d.h. keinen weiteren Bremsdruck auf ein Rad ausüben, das zu blockieren droht). Diese Ebene kann je nach Umfang und Komplexität des Systems weiter unterteilt sein.
Ebene 2 beschreibt das Design der in Ebene 1 beschriebenen Systemebene. Vor allem muss diese Ebene Verbindungen oder Nachvollziehbarkeit zu Ebene 1 erzeugen und mit dem Prozess der Erstellung der RTM beginnen. Dies beinhaltet die Erfassung von Low-Level-Anforderungen, die für den Entwurf und die Implementierung spezifisch sind und keinen Einfluss auf die Funktionskriterien des Systems haben. Bei unserem ABS-Beispiel könnte in den Low-Level-Anforderungen diskutiert werden, wie die angewendete Bremskraft variiert, aufbauend auf der Notwendigkeit dafür, die in Ebene 1 festgelegt wurde.
Die Implementierung auf Ebene 3 bezieht sich auf den Quell-/Assembler-Code, der in Übereinstimmung mit Ebene 2 entwickelt wird. Zu den Verifikationsaktivitäten zählen eine Prüfung der Code-Regeln und eine Qualitätsanalyse. Die Führung der RTM ist auf dieser Ebene mit vie-len Herausforderungen verbunden, da die Nachvollziehbarkeitsanforderungen zu den Quell-Code-Da-teien möglicherweise nicht spezifisch genug sind und Entwickler Verbindungen zu einzelnen Funktionen herstellen müssen. Es ist klar, dass mehrere Funktionen an der Regelung der Bremskraft in unserem Beispiel beteiligt sind. Die Nachvollziehbarkeit dieser Funktionen zurück auf Ebene-2-Anforderungen enthält Beziehungen von vielen Funktionen auf wenige Anforderungen. Eine oder mehrere dieser Beziehungen können leicht in einer manuell geführten Matrix übersehen werden.
In Ebene 4 beginnt die formale Verifikation mit der host-basierten Verifikation. Mittels einer Teststrategie, die von oben nach unten oder von unten nach oben verlaufen oder auch eine Kombination von beiden sein kann, tragen Software-Simulationstechniken dazu bei, nach Bedarf automatisierte Testrahmen und Testfallgeneratoren zu erzeugen. Testfälle sollten, falls erforderlich, auf Ebene 5 wiederholbar sein. In diesem Stadium wird bestätigt, dass die Beispiel-Software, die die Bremskraft regelt, in ihrer Entwicklungsumgebung wie beabsichtigt funktioniert, wobei es jedoch keine Garantie gibt, dass sie auch in ihrer Zielumgebung funktionieren wird. ISO 26262 berücksichtigt dies und fordert, dass die Testumgebung für alle ASIL-Stufen „so eng wie möglich der Zielumgebung entsprechen soll“. Durch zuerst in der Host-Umgebung durchgeführte Tests ist es jedoch möglich, dass der Zieltest lediglich zu bestätigen braucht, dass die Tests auch in der Zielumgebung stichhaltig bleiben. In unserem Beispiel wird also in der Host-Umgebung sichergestellt, dass mit dem ABS-System zusammenhängende Funktionsaufrufe an die Software in Übereinstimmung mit den Anforderungen, die sie erfüllen müssen, die von ihnen geforderten Werte liefern. Diese Information wird dann in der RTM aktualisiert.
Die zielbasierte Verifikation von Ebene 5 repräsentiert das zielbezogene Testelement der formalen Verifikation. Dies besteht häufig aus einer einfachen Bestätigung, dass die zuvor durchgeführte host-basierte Verifikation in der Zielumgebung dupliziert werden kann, obwohl es möglicherweise einige Tests gibt, die nur in der Umgebung selbst anwendbar sind. Das ABS-System ist jetzt in der Zielumgebung getestet, wobei darauf zu achten ist, dass die Testergebnisse mit den beim Host durchgeführten Tests übereinstimmen. Eine weitere RTM-Ebene zeigt diese Bestätigung der Tests an.

In der Luft- und Raumfahrtindustrie und bei Militärprojekten wird in der Regel ein Modell angewendet, bei dem die RTM solch eine stark sichtbare Rolle einnimmt. Da ISO 26262 ähnliche Anforderungen an in der Automobilentwicklung tätige Entwickler stellt, insbesondere in Hinblick auf die Sicherheitsanforderungen, lässt sich daraus ableiten, dass ein ähnliches Modell anzuwenden ist.