Entwicklungsstandards Von den Diagnose- Anforderungen zur Kommunikation

In den letzten Jahren sind mehrere voneinander unabhängige Standards entstanden, die sich alle auf die Prozesse und Werkzeuge der Diagnose-Entwicklung auswirken - vor allem ODX und AUTOSAR.
In den letzten Jahren sind mehrere voneinander unabhängige Standards entstanden, die sich alle auf die Prozesse und Werkzeuge der Diagnose-Entwicklung auswirken - vor allem ODX und AUTOSAR.

In der Elektronik-Entwicklung der Automobilindustrie setzt man immer mehr auf Standards mit dem Ziel, sich auf die Entwicklung und Wiederverwendung innovativer und differenzierender Funktionen zu fokussieren. In den letzten Jahren sind mehrere voneinander unabhängige Standards entstanden, die sich alle auf die Prozesse und Werkzeuge der Diagnose-Entwicklung auswirken - vor allem ODX und AUTOSAR. Gleichzeitig setzt sich die systematische Erfassung, Verwaltung und Verfolgung von Requirements durch, was sich ebenfalls stark auf die Prozesse, Methoden und Werkzeuge auswirkt. Kann man nicht auf den einen oder anderen Standard verzichten - gibt es den Über-Standard? Oder können die Standards und Methoden -effektiv und effizient miteinander kombiniert werden?

Am Anfang der Entwicklung eines Systems stehen die Anforderungen (Requirements) aus Anwendersicht. Die Erfassung von Anforderungen ist der Beginn eines iterativen Prozesses (Bild 1), in dem Anforderungen an ein System sukzessive konkretisiert und präzisiert werden. Ist der Lösungsraum für die Erfüllung von Anforderungen noch groß, so beschreibt die spätere Spezifikation einzelne Subsysteme exakt und ohne Mehrdeutigkeiten.

In der Praxis sind Anforderungen unterschiedlich konkret und präzise. Textuelle Requirements beschreiben eine zu erfüllende Systemeigenschaft in Textform, meist unvollständig und bewusst unscharf, ausformuliert oder stichwortartig, also informal. Spezifikations-Requirements hingegen sind präzise und beschreiben nicht nur die Anforderung an sich, sondern enthalten gleichzeitig bereits die Lösung und lassen nur noch wenig Gestaltungsspielraum für die Spezifikation. Zur Beschreibung kommen oft formale Sprachen zum Einsatz, die in Dateien an textuelle Anforderungen angehängt werden. Referenzanforderungen enthalten einen Verweis auf eine Spezifikation, zum Beispiel „wie beim Vorgängersystem“. Technisch verweisen diese Referenz-Requirements meist tatsächlich auf andere Datenbanken oder Datenverwaltungssysteme (teilweise auch Spezifikationen).
Im Idealfall sind Requirements von Beginn an so präzise wie möglich, aber auch nur so konkret wie nötig. Unklare oder mehrdeutige Anforderungen führen im weiteren Entwicklungsprozess zu erheblichem Zusatzaufwand. Eine Klärung bedeutet einen zusätzlichen Abstimmungsbedarf, hat oft eine Spezifikationsänderung zur Folge, und im ungünstigsten Fall muss sogar die Implementierung des Systems angepasst werden. Andererseits verbauen unnötig konkrete Requirements oft den Weg zur schnellsten und kostengünstigsten Lösung. Werden bereits Aspekte eines Lösungswegs mit Anforderungen vermischt, so verkleinert sich der Lösungsraum unnötig. Nicht selten nimmt man sich dadurch die Möglichkeit einer Wiederverwendung. Gerade wenn sich Anforderungen im Laufe der Entwicklung ändern, ist es wichtig, die substanziellen Anforderungen von früheren Lösungsansätzen zu trennen.
Während der Entwicklung gibt die Gesamtheit des Umsetzungsfortschritts aller Anforderungen einen guten Überblick über den Umsetzungsfortschritt des Gesamtsystems oder eines Subsystems (Reifegradverfolgung).
Um die Vorteile eines Requirements-getriebenen Prozesses durchgängig zu nutzen, muss der oben skizzierte Prozess durchgängig und in allen Subsystemen Anwendung finden, auch bei unterschiedlichen und eigentlich unabhängigen Disziplinen der Entwicklung. Das gilt auch für die Diagnose.
Zur Verwaltung der Anforderungen kommen heute in der Regel tabellen-orientierte Werkzeuge und Datenbanken zum Einsatz, in denen Requirements nicht oder nur teilweise formal beschrieben sind. Diese Werkzeuge müssen so flexibel sein, dass sämtliche Anforderungen - auch die unscharfen - erfasst und verfolgt werden können.
Auf der Spezifikationsseite sind in den verschiedenen Disziplinen andere Werkzeuge etabliert, zum Beispiel Modellierungs- oder Autorenwerkzeuge, die in der Regel eine formale Spezifikation erzeugen. Im Gegensatz zu den Anwender-Requirements steht hier die inhaltliche Präzision und nicht die Flexibilität im Vordergrund. Dieser Unterschied resultiert in anderen spezifischen Werkzeugen. Folglich lassen sich die klassischen Werkzeuge für das Requirements-Management nur bis zu einem bestimmten Detaillierungsgrad sinnvoll einsetzen. Das gilt auch für die Diagnose.
Standardisierte Austauschformate sind spezifisch für eine bestimmte Disziplin. So spezifiziert ODX [1] beispielsweise die für Diagnose-Tester relevanten Daten. Üblicherweise nutzen Austauschformate ein formales Datenmodell, das eine konsistente und im Detail vollständige Spezifikation sicherstellt. Andererseits sind diese Formate für die Formulierung unscharfer Anforderungen zu restriktiv. Für die Beschreibung textueller Diagnose-Requirements sind die klassischen Werkzeuge für das Anforderungs-Management gut geeignet. Das standardisierte Datenaustauschformat ODX wiederum wäre ungeeignet für die Beschreibung und den Austausch dieser textuellen Anforderungen, weil es zu formal und zu präzise ist.