Von den Diagnose-Anforderungen zur Kommunikation

Von den DiagnoseAnforderungen zur Kommunikation
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?
Von Dr. Klaus Beiter und Christoph Rätz
A
m 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 Subsys38
Elektronik automotive 11.2013
teme 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 An-
forderung 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 ReferenzRequirements 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ösungs-
(Bild: Vector Informatik GmbH)
entwicklungsstandards
entwicklungsstandards
mat ODX wiederum wäre ungeeignet
für die Beschreibung und den Austausch
dieser textuellen Anforderungen, weil
es zu formal und zu präzise ist.
Aufgaben der Steuergeräte-­
Software
Die AUTomotive Open System ARchitecture (AUTOSAR) [2], [3] ist heute die Referenzarchitektur für Steuergeräte-Software in der Automobilindustrie [4], [5].
Diese standardisiert die Beschreibung
einzelner Teil- oder Fahrzeugfunktionen
sowie des Gesamtsystems.
Die Diagnose-Software in AUTOSAR
besteht aus den Basis-Software-Modulen
➜➜Diagnostic Communication Manager
(DCM),
➜➜Diagnostic Event Manager (DEM)
und
➜➜Function Inhibition Manager (FIM).
Der DCM realisiert die Diagnosekommunikation nach UDS [6] und OBDII.
Der DEM erstellt einen Fehlerspeicher
und verwaltet den Status sowie Zusatzinformationen zu Fehlersymptomen.
Review
raum 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 Requirementsgetriebenen 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 Datenaustauschfor-
TesterBedatung
Tester
Anforderungen
Spezifikation
SteuergeräteKonfiguration
Diagnosekommunikation
Steuergerät
Bild 1. Iterativer Entwicklungsprozess.
(alle Bilder: Vector Informatik GmbH)
Der FIM unterbindet im Fall aktiver Fehler die Ausführung bestimmter Funktionen und unterdrückt Folgefehler.
DCM, DEM und FIM werden durch die
ECU Configuration Description (ECUC)
konfiguriert. Ihr Inhalt ist am besten zu
verstehen, wenn man sich die Anforderungen an die Konfiguration von Software-Komponenten vor Augen führt.
Mehrdeutigkeiten und Flexibilität,
die bei der Anforderungserfassung von
Vorteil sind, sind bei der Konfiguration
der Steuergeräte-Software zu vermeiden. Die Software muss für alle auftretenden Betriebsbedingungen exakt
und eindeutig beschrieben sein.
Wesentliche Inhalte der für die Software-Konfiguration relevanten Diagnosedaten sind die von einem externen
Diagnosetester aufrufbaren DiagnoseElektronik automotive 11.2013
39
entwicklungsstandards
dienste mit Request/Response und ihren Parametern (Service Identifier, Subfunktionen und Datenparametern). Für
alle Datenparameter sind die Länge und
der Datentyp relevant, für konstante
Parameter zusätzlich der konstante
Wert. Der Zugriff auf bestimmte Datenpakete lässt sich in UDS auf ausgewählte Sessions oder Security Levels einschränken. Auch diese Information ist in
Konfigurationsdaten enthalten, damit
die Software die Einhaltung der vorgegebenen Regeln sicherstellen kann.
Die Anbindung der Diagnose-Software an die Applikation ist der zweite
rade im Service ist es erforderlich, dass
viele Fahrzeuge, Modelle und Varianten
unterschiedlicher Baujahre mit einem
einzigen Tester diagnostiziert werden.
Die daraus resultierende Datenmenge
verlangt nach effizienten Mechanismen, um Redundanz zu vermeiden und
die erforderlichen Daten kompakt zu
speichern.
Der für die Konfiguration geforderte
Spezifikationscharakter ist für die Parametrierung von Testern nicht erforderlich. Im Gegenteil, es kann sogar von
Vorteil sein, wenn eine Bedatung mehrere gleichwertige Alternativen enthält.
So können zur Laufzeit
die passenden Daten
DaVinci
automatisch ausgeConfigurator
wählt werden. Beim AnPro
schließen eines DiagnoSteuergeräte-Software
setesters an ein FahrCANoe
zeug ist oft nicht klar,
CANape
welche SteuergerätevaIndigo
IBM DOORS Import CANdelaStudio Export ODX
rianten und SoftwareDiagnosetester
CDD
Anforderungen
Spezifikation
Stände in dem unterAndere Tester
suchten Fahrzeug verbaut sind.
CANoe.DiVa
Inhaltlich unterscheiden
Validierung
sich die DiagnosetesterBild 2. Werkzeugkette der Diagnoseentwicklung.
von den Konfigurationsdaten dadurch, dass die
wichtige Bestandteil der SoftwareUmrechnungsinformation essenzieller
Konfigurationsdaten: Die durch die DiBestandteil ist. Die kompakt kodierten
agnosedienste übertragenen ParameBusbotschaften und ihre Bestandteile
ter lassen sich mit Variablen oder Funkwerden am Tester als physikalische
tionen der Applikations-Software verWerte mit Einheiten angezeigt. Beispieknüpfen. Daraus können Softwarele für etablierte Datenformate zur ParaGeneratoren die entsprechenden Aufmetrierung von Diagnosetestern sind
rufe generieren.
das cdd-Format aus dem Hause Vector
Weil die AUTOSAR-Diagnose auf die
sowie das in der ISO standardisierte
Protokolle UDS und OBDII beschränkt
ODX-Format.
ist, wird der Aufbau der Diagnosedienste dieser Protokolle implizit vorausgeBeispiel für eine Tool-Kette
setzt und nicht explizit in den ECUCDaten beschrieben. Die ECUC-Daten
Während der Diagnoseentwicklung
werden in einem standardisierten XMLgibt es folgenden Aufgaben, die durch
Format abgelegt und lassen sich somit
die in Bild 2 dargestellte Werkzeugketin Code-Generatoren verarbeiten.
te unterstützt werden.
➜➜Anforderungen definieren, sammeln
Datenversorgung von Diagnose­
und abstimmen: testern
IBM Doors ist als Werkzeug für Erfassung und Management von AnforDiagnosedaten zur Parametrierung gederungen bei Automobilherstellern
nerischer Tester müssen alle für das
weit verbreitet.
Fahrzeug und seine Steuergeräte rele➜➜Spezifikation erstellen und abstimvanten Informationen aus Sicht der
men:
Diagnosekommunikation enthalten. Ein
Hier lässt sich CANdelaStudio als Auwesentlicher Unterschied zu den oben
torenwerkzeug zur Spezifikation der
beschriebenen Konfigurationsdaten ist
Steuergerätediagnose nahtlos in die
der typischerweise auf das Fahrzeug
anforderungsgetriebene Prozessketausgedehnte Betrachtungsbereich. Gete integrieren, denn das Tool unter40
Elektronik automotive 11.2013
stützt die Erfassung und den Import/
Export von Requirements. Aus den
Anforderungen, die bereits formal
beschrieben sind, werden auf Knopfdruck Diagnoseobjekte (Diagnosedienste, Datenobjekte, DTCs) erzeugt,
die jeweils mit dem ursprünglichen
Requirement verknüpft sind. So kann
der Anwender die importierten Requirements automatisiert mit den
aktualisierten Requirements abgleichen, synchronisieren sowie gegebenenfalls die Spezifikation anpassen.
Diese enge Verknüpfung zwischen
Anforderungen und Spezifikation ist
in dem typischerweise iterativen Prozess sehr vorteilhaft, weil ein Mehrfachaufwand für die Erstellung und
den wiederholten Abgleich der Spezifikationsdaten vermieden wird. Die
fertiggestellte Diagnosespezifikation
ist der Input für die weitere Prozesskette. CANdelaStudio speichert die
native Diagnosespezifikation im cddFormat, auf Knopfdruck lässt sich
auch ODX exportieren.
➜➜Steuergeräte-Software integrieren: DaVinci Configurator Pro ist ein
Werkzeug für die Konfiguration und
Erzeugung der AUTOSAR-Basis-Software sowie der RTE eines Steuergeräts. Der Anwender importiert eine
Diagnosespezifikation wie ODX oder
cdd und erstellt daraus eine initiale
ECUC-Konfiguration. Danach ergänzt
und konkretisiert er sukzessive die
Konfiguration für das Steuergerät.
Gibt es eine neue Version der Diagnosespezifikation, so kann diese einfach erneut importiert werden, die
Inhalte werden automatisch mit der
zuvor erstellten Konfiguration verschmolzen. Die Diagnose-Software
für das Steuergerät wird auf Basis der
erstellten Konfiguration generiert.
➜➜Steuergeräte-Diagnose-Software
testen: Zum Test der Diagnose-Implementierung im Steuergerät kommt sowohl
beim Zulieferer als auch beim OEM
CANoe.DiVa [7] zum Einsatz. CANoe.
DiVa generiert umfangreiche Steuergeräte-spezifische Testfälle auf Basis
der Steuergeräte-Beschreibungen im
ODX- oder cdd-Format, die dann automatisiert in CANoe ausgeführt werden. Testergebnisse werden detailliert dargestellt, der Anwender kann
Testfälle beliebig kommentieren,
gruppieren und nach verschiedenen
Kriterien sortieren und filtern.
entwicklungsstandards
ECUC
Req.
ODX
Bild 3. Inhaltliche Gemeinsamkeiten und Unterschiede der verschiedenen Beschreibungsmodelle.
➜➜Steuergeräte-Diagnose nutzen: Als Diagnosetester werden je nach
Einsatzgebiet CANoe, CANape oder
Indigo genutzt. Weil die Testerparametrierung und die Steuergerätekonfiguration ihren gemeinsamen
Ursprung in der CANdelaStudioSpezifikation haben, ist sichergestellt, dass Tester und SteuergeräteSoftware zueinander passen.
Ausblick und Einsatzgebiet
Die in den letzten Jahren in der Diagnose entstandenen Standards AUTOSAR und ODX ergänzen sich gut und
sind nach wie vor und auch zukünftig
zielführend. Sie decken zwar verwand-
te Inhalte ab, haben aber ganz andere
Schwerpunkte und überschneiden sich
nur wenig (Bild 3). Das Einsatzgebiet
des einen Standards kann nicht durch
einen anderen mit abgedeckt werden.
Die AUTOSAR-Methode verträgt sich
auch mit ODX.
In der Praxis steht man jedoch vor
der Herausforderung, die Konsistenz
der in den unterschiedlichen Standards
beschriebenen Daten im verteilten und
üblicherweise iterativen Entwicklungsprozess sicherzustellen. Dies wiederum
kann durch einen wohldefinierten Prozess, eine gezielte Datenübernahme
und die Unterstützung durch bereits
heute am Markt verfügbare Werkzeuge
erreicht werden.
eck
Literatur
[1]ISO 22901: Road vehicles – Open
diagnostic data exchange (ODX)
[2]www.autosar.org
[3]Klaus Beiter, Oliver Garnatz, Christoph
Rätz: Diagnose, Autosar und ODX,
Diagnose in mechatronischen Fahrzeugsystemen IV S. 92 ff., Expert-Verlag 2011.
[4]Pascale Morizur, Matthias Wernicke,
Justus Maier: Neue Wege zur Steuergerä-
te-Software Teil 1, Elektronik automo­
tive 11.2009.
[5]Pascale Morizur, Matthias Wernicke,
Justus Maier: Neue Wege zur Steuergeräte-Software Teil 2, Elektronik automo­
tive 12.2009.
[6]ISO 14229: Road vehicles – Unified
diagnostic services (UDS).
[7]Simon Müller, Christoph Rätz: Erfahrungsbericht: Automatische Validierung
der Diagnose, Diagnose in mechatronischen Fahrzeugsystemen II S. 32 ff.,
Expert-Verlag 2009.
Dr. Klaus Beiter
leitet ein Entwicklungsteam in
der Produktlinie Kfz-Diagnose
bei der Firma Vector Informatik
GmbH. Er ist Mitglied in der
ASAM/ISO-ODX-Arbeitsgruppe.
Christoph Rätz
leitet die Produktlinie Kfz-­
Diagnose bei der Firma Vector
Informatik GmbH.