Übersicht und Entwicklung von automotiven Bussystemen

Transkript

1 Seminar Sommersemester 2009 Automotive Konzepte und Techniken Prof. Dr. Dieter Zöbel, Universität Koblenz-Landau, FB Informatik Übersicht und Entwicklung von automotiven Bussystemen Jonas Hummes Eingereicht: / Fertiggestellt: Zusammenfassung Diese Arbeit gibt einen Überblick über die in Fahrzeugen zum Einsatz kommenden Datenbusse und Netzwerke. Sie erläutert die verschiedenen Bustypen und ihre Leistungsmerkmale. Sie befasst sich außerdem mit dem Aufbau von standardisierten Sysemen, im Bereich der Entwicklung, Applikation und Diagnose von Fahrzeugen. Dabei wird das, von einem Konsortium der Automobilhersteller erschaffene, ASAM-MCD-System in seiner Idee und Umsetzung näher betrachtet. Schlüsselwörter Netzwerke im Fahrzeug Bussysteme Übersicht ASAM ODX Diagnose Applikation Messen Kalibrieren Datenaustauschformate Standardisierung AML 1 Einführung In der Automobilindustrie gibt es eine Vielzahl von Bussystemen, um die in einem Fahrzeug verbauten Steuergeräte miteinander zu verbinden. Dadurch, dass jeder Hersteller bei der Umsetzung dieser Netze jedoch seine eigenen Methoden entwickelte, gibt es heute eine ebenso große Vielfalt an Systemen für die Applikation und Diagnose der unterschiedlichen Netze. Viele Hersteller und Zulieferer schließen sich daher zusammen, um ein einheitliches System zu entwerfen, welches die Kosten bei der Entwicklung senkt und den Datenaustausch vereinfacht. 2 Bussysteme und Netzwerke Seit den 1970er Jahren werden in Fahrzeugen zunehmend elektronische Komponenten verbaut. Anfangs zählte neben einfachen Kompfortelementen vor allem die elektronische Einspritzung dazu. Erst ab dem Jahr 1979 wurden dann auch komplexere Dieter Zöbel University Koblenz-Landau Tel.: Fax: zoebel@uni-koblenz.de

2 2 Tabelle 1 Anwendungsbereiche und Anforderungen an Bussysteme im KFZ [9] Anwendung Botschaftslänge Botschaftsrate Datenrate Latenz Fehlersicherheit Kosten On-board High-Speed- Steuerung Low-Speed- Kurz Hoch Hoch Sekr kurz Extrem hoch Mittel Kurz Niedrig Niedrig Mäßig Sehr Sehr hoch niedrig Mäßig Mäßig Hoch Steuerung Infotainment Lang Hoch Sehr hoch Off-Board Werkstattdiagnose Kurz Niedrig Niedrig Unwichtig Gering Niedrig Fertigungstest Sehr lang Niedrig Hoch Unwichtig Mäßig Unwichtig Applikation Kurz Mittelhochoch Mittel- Kurz Gering Unwichtig Car to X Mittel Mittel Mittel Hoch Mittel Hoch Aufgaben, wie die Steuerung des gesamten Motors und ABS, elektronisch realisiert. Diese recht überschaubare Menge an Steuergeräten (ECU) tauschte Daten über direkte Punkt-zu-Punkt Verbindungen aus. Das bedeutet, dass jedes Steuergerät eine direkte Leitung zu jedem anderen Steuergerät besaß. Da im Laufe der Zeit immer mehr Funktionen mit elektronischen Steuergeräte implementiert wurden, stieg die Zahl der im Fahrzeug verbauten ECUs rapide an und der Verkabelungsaufwand unter den einzelnen Geräten wurde unbeherrschbar. Aus diesem Grund entwickelte Bosch Anfang der 1990er mit CAN ein Bussystem zur einfachen Vernetzung der elektronischen Komponenten. Dabei wurden allerdings zunächst nur die Teilnehmeradressierung, der Buszugriff und die Bitübertragung geregelt. Die Implementierung von Transportprotokollen und Anwendungsdiensten musste jeder Fahrzeughersteller individuell vornehmen. Die Anforderungen an das Bussystem sind dabei je nach Steuergerät unterschiedlich hoch. Komplexe und zeitkritische Funktionen benötigen beispielsweise ein Bussystem mit hoher Geschwindigkeit und Ausfallsicherheit. Weil die elektonischen Komponenten zur Umsetzung dieser Anforderungen jedoch recht teuer sind, und bei der Massenproduktion von Fahrzeugen einen nicht unerheblichen Kostenfaktor bilden, sind weitere Bussysteme entwickelt worden. Diese hatten das Ziel, verschiedene Aufgabenbereiche im Fahrzeug möglichst günstig abzudecken [3]. 2.1 Allgemeine Übersicht In einem Auto der Oberklasse sind heute bis zu 80 Steuergeräte und bis zu 7 km Kabel verbaut [4]. Fast alle Funktionen, von der Motorsteuerung bis hin zum Verstellen der Sitzposition, können dabei elektronisch gesteuert werden. Die verwendeten Bussysteme sind in ihrer Geschwindigkeit und ihrem Datenaufkommen auf die jeweilige Aufgabe ausgelegt (siehe Tabelle 1). Man unterscheidet daher sechs Arten von Bussystemen. Im Fahrzeug befinden sich Highspeed-Systeme für zeitkritische und sicherheitsrelevante Bereiche, Lowspeed-Systeme für den Kompfortbereich, und Systeme mit hohem Datendurchsatz im Infotainmentbereich. Dazu kommen Busse für Offboard-Diagnoseaufgaben, Fertigungstests und Kalibrierungsdienste. Eine weitere

3 3 Tabelle 2 Klassifikation der Bussysteme nach der Bitrate [9] Klasse Bitrate Typische Vertreter Anwendung Diagnose bis 10Kbit/s ISO 9141-K-Line Werkstatt- und Abgastester A bis 25Kbit/s LIN Karosserieelektronik B Kbit/s CAN (Low-Speed) Karosserieelektronik C Kbit/s CAN (High-Speed) Antrieb, Fahrwerk, Diagnose D über 1Mbit/s FlexRay, TTP x-by-wire, Backbone-Netz Infotainment über 10Mbit/s MOST Multimedia Tabelle 3 OSI-Schichtenmodell für Bussysteme und Protokolle [9] Layer Aufgabe 7 Anwendung Dienste für den Anwender 6 Darstellung 5 Sitzung 4 Transport Aufteilung und Zusammensetzung mehrerer Botschaften 3 Vermittlung 2 Sicherung Botschaftsaufbau, Buszugriff, Fehlersicherung, Flusskontrolle 1 Bitübertragung Elektrische Signalpegel, Bitcodierung Unterteilung der Bussysteme basiert auf ihre Klassifizierung nach der Bitrate und damit ihrer Übertragungsgeschwindigkeit (siehe Tabelle 2). Sie werden nach den Klassen A bis D, der Diagnoseklasse sowie dem Infotainmentbereich unterschieden. Die Aufgaben der Bussysteme bei der Datenkommunikation im Fahrzeug können anhand des bekannten OSI-Schichtenmodells dargestellt werden (siehe Tabelle 3). Dabei kommen vor allem die Schichten für die Bitübertragung, Buszugriff und Transport zum Einsatz. Die Schichten 3, 5 und 6 haben im automotiven Bereich hingegen noch keine Bedeutung. 2.2 Verwendete Bussysteme Die in der Praxis eingesetzten Busse (siehe Tabelle 4) sind alle nach unterschiedlichen Verfahren implementiert. Die eigentlichen Übertragung der Daten geschieht entweder Zeichen- oder Bitstrombasiert. Die zeichenbasierte Übertragung kommt vor allem bei Bussen mit niedriger Bitrate zum Einsatz. Der Zugriff auf den Bus selbst erfolgt ebenfalls nach unterschiedlichen Methoden. Wenn er zeitgesteuert (TDMA) ist, erhält jeder Teilnehmer einen festen Zeitabschnitt pro Sendezyklus, in dem er seine Daten über den Bus senden darf. Beim ereignisbasierten (CSMA) Zugriff sendet ein Teilnehmer eine Nachricht sofort, wenn diese anfällt. Dabei kann es jedoch zu Kollisionen der einzelnen Nachrichten kommen, wenn mehrere Teilnehmer gleichzeitig senden wollen. Daher wird dieses Verfahren mit einer Methode zur Kollisionsvermeidung erweitert (CSMA/CA). Eine einfache Kollisionserkennung (CSMA/CD) wäre zwar auch möglich, jedoch ist das Bussystem dann nicht vorhersagbar und kann nicht für zeitkritische Aufgaben genutzt werden. Eine vor allem bei günstigen Bussen eingesetzte Zugriffsmethode ist das Master-Slave Verfahren, bei dem ein Busmaster die gesamte Kommunikation steuert und alle andere Teilnehmer nur auf Anfrage ihre Daten senden dürfen. Das mit Abstand meist genutzte Bussystem ist CAN. Es wird für fast alle wichtigen Aufgaben im Antriebs- und Fahrwerksbereich eingesetzt und dominiert den Markt der im Fahrzeug verbauten Busse. Das leistungsfähigere FlexRay wurde ebenfalls für diese

4 4 Tabelle 4 KFZ-Busse [9] Bus Anwendung EU-Standard US-Standard Zeichen-basiert K/L-Line Diagnose ISO9141 SAE J1708 Diagnose, SAE J1708 Klasse A On-board LIN Klasse A On-board Herstellerkonsortium SAR J2602 PWM-basiert SAE J1850 Diagnose, Klasse A/B On-board SAEJ1850 Bitstrom-basiert CAN Klasse B/C On-board ISO11898, ISO11992, ISO11783 TTCAN Klasse C+ On-board ISO FlexRay Klasse D On-board Herstellerkonsortium TTP Klasse D On-board Herstellerkonsortium MOST Infotainment Herstellerkonsortium SAE J2284, SAE J1939 Aufgaben entworfen, findet jedoch in der Praxis bisher nur wenig Anwendung. Der bekannteste Bus zur Steuerung von Karosserieelektronik und Kompfortelementen ist LIN. Für den Infotainment-Bereich wird häufig MOST eingesetzt. 2.3 Netzwerkaufbau Beim physischen Aufbau eines Bussystems kommen, neben der Busleitung selber, in der Regel nur wenige Komponenten zum Einsatz. Zur Anbindung eines Steuergerätes an den Bus verwendet dieses einen Transceiver, auch Bustreiber genannt (siehe Abb. 1). Dieser ist direkt mit dem Kommunikationskontroller des Steuergerätes verbunden und übernimmt selbstständig die gesamte Datenübertragung auf der Busleitung. Zur Verbindung mehrerer Bussysteme zu einem großen Netzwerk werden Gateways eingesetzt (siehe Abb. 2). Diese Komponenten unterstützten gleichzeitig mehrere Bustypen und können Nachrichten von einem Netz in ein anderes weiterleiten. Es gibt außerdem unterschiedliche Netzwerktopologien bei den verwendeten Bussystemen. Die meist genutzte Topologie ist dabei der Linien-Bus. Er besteht aus einer einzigen Leitung, an die alle Teilnehmer angeschlossen sind. Diese Topologie wird beispielsweise von CAN, LIN und FlexRay unterstützt. Ein FlexRay Bus kann alternativ aber auch als Stern realisiert werden. MOST Busse verwenden üblicherweise eine Ringtopologie. 3 Entwicklung und Wartung von Busnetzwerken Der Zusammenschluss mehrerer Busse zu einem Netzwerk dient hauptsächlich dem Datenaustausch zwischen den einzelnen Steuergeräten in einem Fahrzeug. Dies wird auch als Onboard-Kommunikation bezeichnet, da sie nur innerhalb des Fahrzeugs stattfindet. Allerdings benötigen auch die Entwicklungs- und Testabteilungen, sowie die Werkstatt Zugriff auf die einzelnen Geräte. Das Netzwerk muss daher diese

5 5 Abb. 1 Bus-Interface [9] Abb. 2 Aufbau eines Bussystems [9] zusätzlichen Möglichkeiten ebenfalls bereitstellen und nach außen hin Schnittstellen zu deren Nutzung bieten. Diese Funktionen gehören zur Offboard-Kommunikation, also dem Datenaustausch mit externen Systemen, wie Prüfstand- und Werkstattrechnern. 3.1 Messen, Kalibrieren, Diagnose im Netzwerk Ein Fahrzeug durchläuft während seiner Entwicklungs- sowie Produktionszeit mehrere Phasen. In jeder Phase ist der Zugriff auf die Steuergeräte und die darin gespeicherten Daten ein wichtiger Bestandteil. Während der Entwicklung muss die Kommunikation zwischen allen Steuergeräten überwacht und optimiert werden. Bei der Erprobung des Fahrzeugs und seiner Komponenten auf Prüfständen müssen Messwerte erfasst und gegebenenfalls funktionsrelevante Parameter angepasst werden. Am Ende der Produktionsphase muss die so entwickelte und optimierte Software schließlich in jedes Serienfahrzeug einprogrammiert werden. Dieser Vorgang wird auch als flashen bezeichnet. Anschließend benötigen Werkstätten für die Wartung, Fehlerdiagnose und Reparatur ebenfalls Zugriff auf die Daten eines Fahrzeugs. Um unbefugte Zugriffe auf die Geräte zu verhindern und die eigenen Entwicklungen zu schützen halten die Hersteller allerdings

6 6 Informationen über die Systeme und die darin implementierten Sicherheitsmaßnahmen geheim. Dieses Verhalten führte in der Vergangenheit dazu, dass jeder Fahrzeughersteller ein individuelles Busnetzwerk aufbaute, auf das nur er alleine Zugriff hatte. Die Zulieferbetriebe der Automobilindustrie mussten für jeden Kunden spezielle Bauteile entwickeln und eine eigene Produktlinie führen. Um die Kosten auf beiden Seiten zu reduzieren und die Qualität zu steigern, wurde daher damit begonnen möglichst viele Teile der Automobilelektronik zu standardisieren. Dazu gehören auf der Hardwareebene einheitliche Steuergeräte, Bussysteme und Steckverbinder. Aber auch Softwarekomponenten wie Transport- und Zugriffsprotokolle, sowie Datenaustauschformate werden zunehmend standardisiert. Bei einigen Funktionen gibt es neben der Kostenreduzierung allerdings noch weitere Gründe die den Prozess der Standardisierung vorantreiben. Der Gesetzgeber fordert immer öfter eine einheitliche Regelung für bestimmte Abläufe. Das bekannteste Beispiel dafür ist die On-Board-Diagnose (OBD), die vom Gesetzgeber aus Umweltschutzgründen in jedem neuen Fahrzeug vorgeschrieben ist [8]. Aber auch wegen des Diskriminierungsverbots von freien Werkstätten und Händlern werden den Herstellern solche offenen Standards und Formate von staatlicher Seite aus vorgeschrieben. Diese ermöglichen es, wie im Beispiel von OBD, dass Fahrzeugidentifikationsdaten und abgasrelevante Messwerte, unter anderem von Lamda-Sonden, Katalysator, Abgasrückführung, Zündung, Einspritzung und Tankentlüftung, an jedem Fahrzeug über fest definierte Diagnoseidentifikatoren ausgelesen werden können. Außerdem kann der Fehlerspeicher bei jedem Fahrzeug ausgelesen werden. Die abgasrelevanten Fehlercodes sind auch hier wieder fest vorgegeben. Die Vergabe von weiteren Fehlercodes ist jedem Hersteller frei überlassen. Darüber hinaus enthält der OBD-Standard die Möglichkeit bestimmte Dienste über einen Seed and Key -Mechanismus zu sichern. Die Freigabe dieser gesperrten Diensten erfolgt erst, wenn der Diagnosetester vom Steuergerät einen zufallsgenerierten Initialisierungswert (Seed) anfordert und anschließend einen daraus berechneten Schlüssel (Key) an das Gerät zurück schickt. Die Berechnung des Schlüssels erfolgt dabei mit Hilfe eines vom Hersteller festgelegten Algorithmus. 3.2 Propritäre Systeme Vor dem Aufkommen von standardisierten Systemen in der Entwicklung, Produktion und Diagnose von Fahrzeugen, verwendeten alle Automobilhersteller unterschiedliche Geräte für diese Aufgaben. Diese werden auch heute teilweise noch benutzt und sind inkompatibel mit den Geräten anderer Hersteller. Die Verbindung zum Fahrzeug wird über ein spezielles Hardware-Interface hergestellt. Dieses ermöglicht den Zugriff auf das Fahrzeug über eine proprietäre Schnittstelle oder über eine direkte Verbindung ins Bussystem wie CAN oder FlexRay. Die Nutzung des Interface erfolgt anschließend über einen Computer, auf dem eine spezielle Software des Fahrzeugherstellers installiert ist. In Verbindung mit den speziellen Konfigurationsdaten des angeschlossenen Fahrzeugtyps können auf diese Art alle nötigen Arbeitsschritte durchgeführt werden. Die verwendeten Konfigurationsdaten und Passwörter zum Umgehen der Sicherheitssysteme werden von jedem Hersteller streng unter Verschluss gehalten. Beispiele für solche proprietären Diagnosesysteme sind das BMW DIS (Diagnostic Information System), Mercedes-Benz SDS (Star Diagnosis System) und VW VAS [5].

7 7 3.3 Standards Aus genannten Gründen (siehe 3.1) wurden viele Geräte und Verfahren in der Entwicklung, Produktion und Diagnose von Fahrzeugen bereits von den Automobilherstellern und Zulieferern vereinheitlicht. Angefangen bei den Standards von Bussystemen und Teilen der Steuergeräte haben sich vor allem die Standards zur Diagnose und zum Datenaustausch am Markt etabliert. Die bereits erwähnte On-Board-Diagnose (siehe 3.1) ist beispielsweise seit 2001 für alle neuen Fahrzeuge in Europa verpflichtend und bietet über ein standardisiertes Interface Zugriff auf alle im Fahrzeug verbauten Steuergeräte. Über diese Diagnoseschnittstelle können Daten ausgelesen, Diagnosetests gestartet und neue Daten in die Steuergeräte geschrieben werden. (siehe 3.6.1) Im Bereich der Betriebssysteme für die Steuergeräte wird seit 1997 OSEK-OS eingesetzt, das gemeinsam von den größten deutschen Automobilherstellern eingeführt wurde. Um weitere Standards in der Softwarearchitektur von Fahrzeugen zu schaffen, arbeitet ein internationaler Verbund von Herstellern und Zulieferern an AUTOSAR, mit dem Ziel die Entwicklung von Software günstiger und flexibler zu machen. Standardisierte Datenmodelle wie beispielsweise ODX (siehe 3.6.1) FIBEX, CDF und MDX (siehe 3.5.1) ersetzen zunehmend die bisher eingesetzten, proprietären Formate zur Beschreibung von Busnetzwerken und für die Konfiguration von Testgeräten. Viele der verwendeten Standards in den Bereichen der Schnittstellen, Datenformaten und Protokollen kommen dabei von ASAM e.v. 3.4 ASAM ASAM (Association for Standardisation of Automation and Measuring Systems) ist eine Initiative der europäischen Automobilhersteller und ihrer Zulieferer, um die Applikation und den Test elektronischer Systeme in der Entwicklungs- und Fertigungsphase zu vereinfachen [2] Idee Das Ziel dieses Zusammenschlusses ist es, ein Gesamtsystem zu entwerfen, das aus einer Reihe von Standards besteht, um die Programmierung und Diagnose von Fahrzeugelektronik zu vereinfachen. Dazu gehören die Applikations- und Diagnoseschnittstellen der Steuergeräte, die Prüfstandkomponenten, Datenspeicherung und Messwertanalyse. Das Ergebnis im Bereich der Schnittstellen zu den Steuergeräten ist ASAM-MCD. Diese Middleware, häufig auch als Automotive Electronics (ASAM AE) bezeichnet, stellt eine Zwischenschicht dar, die auf der einen Seite die Steuergeräte und auf der anderen Seite die Test- und Diagnoseanwendungen miteinander verbindet. MCD steht dabei für Messen, Kalibrieren und Diagnose. Die Aufgabe des Systems ist es, den Softwareanwendungen eine einheitliche Schnittstelle zur Verfügung zu stellen, und sie somit von der Hardwarebasis unabhängig zu machen. Alle Umsetzungen von der Software auf eine beliebige Hardware übernimmt das System automatisch. Der Aufbau sowie die Fähigkeiten und Funktionen des verwendeten Bussystems sind dabei in einem herstellerunabhängigen Format in einer Datenbank beschrieben (siehe Abb. 3). Das MCD- System konfiguriert sich anhand dieser Daten selbstständig für das jeweilige Fahrzeug. Die einzigen Unterschiede zwischen den verschiedenen Automobilherstellern bestehen in diesem System somit nur noch aus den individuellen Konfigurationsdatensätzen

8 8 Abb. 3 ASAM MCD-Schnittstellen [9] in der Steuergerätedatenbank [9] [7]. Da das System am Anfang der Entwicklung lediglich auf den Applikationsbereich ausgelegt war, das bedeutet Messen und Kalibrieren, und die Diagnosefunktionen somit erst später integriert wurden, kam es jedoch zu Inkompatibilitäten innerhalb des Systems. Das führte dazu, dass heute praktisch für alle Schnittstellen des ASAM Systems jeweils zwei Ausführungen existieren. Jeweils eine für Mess- und Kalibrierfunktionen und eine für Diagnoseaufgaben Aufbau Der Aufbau eines ASAM-MCD Servers ist daher in zwei Gruppen unterteilt. Eine Funktionsgruppe für Mess- und Kalibrierungsaufgaben (MC) und eine Gruppe für Diagnosedienste (D). Ein ASAM Server muss allerdings nicht alle Funktionsgruppen unterstützen. Es gibt durchaus Systeme, in denen nur eine der beiden Gruppen enthalten ist. Jede Gruppe greift zur Konfiguration auf eine eigene Datenbank zurück (MCD 2MC & 2D), in der alle Informationen über die angeschlossenen Steuergeräte, den Aufbau des Netzwerks sowie der verwendeten Protokolle enthalten sind. Über die physische Schnittstelle des Servers zum Bussystem greifen beide Funktionsgruppen auf die angeschlossenen Steuergeräte zu (MCD 1). Die Kommunikation zwischen den Client-Programmen und dem Server (MCD3) kann mit verschiedenen Programmiersprachen implementiert werden. Dazu gehören Java RMI, Microsoft COM/DCOM (C,C++,C#), CORBA sowie das ASAM eigene GDI (siehe Abb. 4). Die gesamten ASAM Diagnosekonzepte sind mittlerweile als eigenständiges System von der ISO unter dem Begriff Modular Vehicle Communication Interface (MVCI) standardisiert worden (siehe 3.6). Dabei sind die MCD 2D und 3D Schnittstellen im Wesentlichen übernommen worden. Einzig die Schnittstelle zur Hardware (MCD 1) wurde neu konzipiert. In zukünftigen Versionen des ASAM-MCD-Servers soll diese neue Schnittstelle auch für die Mess- und Kalibrierungsgruppe eingesetzt werden und somit die bisherige MCD1-Schnittstelle ablösen.

9 9 Abb. 4 Aufbau eines ASAM-Systems [9] 3.5 Messen und Kalibrieren Die Funktionsgruppe für Mess- und Kalibrierungsaufgaben eines ASAM Servers wird hauptsächlich während der Entwicklung und Erprobung eines neuen Fahrzeugs benötigt, um Messwerte auszulesen und Funktionsparameter anzupassen. Ein ASAM Server konfiguriert sich dabei anhand der Beschreibungsdateien und Definitionen aus der angeschlossenen Datenbank selbstständig für das angeschlossene Busnetzwerk. Ein Client-Computer mit ASAM kompatibler Applikations- oder Diagnosesoftware kann anschließend mit dem Server verbunden werden. Diese Verbindung erfolgt über Ethernet, WLAN, USB, Bluetooth oder eine andere im Server implementierte Verbindung. Über die Clientsoftware hat ein Benutzer Zugriff auf alle Werte und Dienste, die in den Beschreibungsdateien als applizierbar angegeben sind. Die Funktionsgruppe Messen stellt dazu Collector-Dienste zur Verfügung, die von der Client-Software einmalig, periodisch oder eventgesteuert aktuelle Messwerte aus den Steuergeräten abfragen können. Alle geräteinternen Hexadezimalwerte werden dabei automatisch vom ASAM-Server, anhand der Umrechnungsformeln und Tabellen aus den entsprechenden Konfigurationsdateien, auf physikalische Werte umgerechnet, bevor sie der Client-Software über einen Puffer zur Verfügung gestellt werden. Die Funktionsgruppe für Kalibrierungsaufgaben erlaubt es dem Client hingegen auf geräteinterne Parameter der Steuergeräte zuzugreifen und diese zu verändern. Dazu zählen Kennlinien, Kennfelder und Konstanten. Da eine Modifizierung dieser Werte sich sofort auf die Funktion des Steuergerätes auswirkt, geschieht dies hauptsächlich während des Betriebs. So können Leistungsveränderungen durch neue Werte möglichst schnell festgestellt werden. Im Gegensatz zum Auslesen der Messwerte über einen Puffer, ist hier eine möglichst schnelle Umsetzung der Modifikationen wichtig. Daher kann das System für jeden in der Datenbank gespeicherten Wert ein dynamisches Laufzeitobjekt

10 10 Abb. 5 Struktur einer ASAM MCD 2MC Beschreibung [9] erstellen. Diese Objekte setzten jede vom Benutzer eingegebene Änderung umgehend im betroffenen Steuergerät um Datenformate beim Messen und Kalibrieren Als Datenformat für die Beschreibung von Steuergeräten und zur Konfiguration der Applikationssysteme für Mess- und Kalibrieraufgaben (ASAM 2MC) wurde, zusammen mit dem MCD-System, das ASAM2 Meta Language Format (AML) eingeführt. Diese textbasierten Konfigurationsdateien beschreiben die Parameter und Fähigkeiten eines Steuergerätes und erweitern so die eingesetzten Busprotokolle CCP (CAN Calibration Protocol) und XCP (Extended Calibration Protokol). Diese Busprotokolle definieren und regeln die gesamte verbindungsorientiere Kommunikation zwischen einem Steuergerät und einem Applikationssystem. Sie bieten Befehle zum Erstellen einer logischen Verbindung sowie zum Lesen und Schreiben von Speicheradressen. Es können darüber hinaus im Steuergerät integrierte Diagnosedienste gestartet und spezielle Funktionen für Kalibrierungen und Messwerterfassungen genutzt werden. Da die Steuergeräte normalerweise gegen unbefugten Zugriff gesperrt sind, unterstützen die Busprotokolle zusätzlich noch ein Seed and Key Verfahren zum Entsperren. Der dabei verwendete Algorithmus ist jedoch nicht Teil der Protokolle und muss daher zusammen mit der Beschreibung von Speicheradressen, Diensten und applizierbaren Parametern in den AML Datensätzen gespeichert sein (siehe Abb. 5 und 6). Weil das AML-Format jedoch keine Dokumentation von vorgenommenen Modifikationen erlaubt, wurde es nachträglich durch das, ebenfalls von ASAM stammende, CDF-Format (Calibration Data Format) erweitert. Dieses basiert jedoch nicht mehr auf einem Textformat, sondern auf dem zeitgemäßeren XML, wodurch die Verarbeitung und maschinelle Lesbarkeit verbessert wird. In diesem Format können allerdings weder die steuergeräteinternen Werte, die Umrechnungsformeln noch die Speicheradressen

11 Abb. 6 Auszug aus einer ASAM MCD 2MC Beschreibung [9] 11

12 12 Abb. 7 Grundstruktur und Hierarchie einer XML-basierten CDF-Beschreibungsdatei [9] abgelegt werden, so dass dieses Format lediglich als Erweiterung dient (siehe Abb. 7). In einem weiteren Schritt ist geplant, das CDF-Format durch das ebenfalls XML basierte MDX-Format (Meta Data Exchange Format) zu ergänzen. Dieses enthält dann wieder eine Beschreibung der Steuergerätesoftware und könnte dadurch das bisher vorherrschende AML-Format komplett ablösen. Für die Beschreibung des Aufbaus, des im Fahrzeug eingesetzten Busnetzwerks setzt ASAM ebenfalls auf ein eigenes Format namens FIBEX (Field Bus Exchange Format). Dieses XML-Format beschreibt die Kommunikation über die verschiedenen Bussysteme in einem Fahrzeug und soll die bisher eingesetzten, proprietären Formate wie CANdb, LIN Configuration Language und Node Capability File ersetzten (siehe Abb. 8). Es dient als Konfigurationsdatei für Test- und Simulationswerkzeuge und kann bei der Busanalyse eingesetzt werden. Aber auch während der Entwicklung eines Busnetzwerkes kommt das Format zum Einsatz, um anhand der Bustopoligie die Routinginformationen für Nachrichten zu erstellen und zu optimieren [1]. 3.6 Diagnose (MVCI) Wie bereits erwähnt, wurden die Diagnosefunktionen des ASAM-MCD-Systems als eigenständiges System unter dem Namen MVCI (Modular Vehicle Communication Interface) standardisiert. Ein solches System ist im Aufbau nahezu identisch mit dem Entwurf der Diagnosegruppe aus dem ASAM-System. Der einzige Unterschied ist, dass beim MVCI-Server die Schnittselle zum Bussystem (MCD1) durch ein modular aufgebautes Businterface ersetzt wurde (siehe Abb. 9). Dieses neue Hardwaremodul wird direkt mit dem Fahrzeug verbunden und beherrscht alle gängigen Diag-

13 13 Abb. 8 Hauptelemente einer FIBEX-Beschreibungsdatei [9] Abb. 9 Aufbau eines MVCI-Systems [9] noseprotokolle. Die Verbindung mit dem Diagnoseserver kann anschließend über eine beliebige Schnittstelle, wie z.b. USB oder Ethernet, erfolgen. Als Softwareschnittstelle zum neuen Hardwaremodul befindet sich auf dem Server die D-PDU API (Diagnostic Protocol Data Unit). Den Kern des Systems bildet der D-Server (Diagnostic Server), der dem ASAM MCD 3 System entspricht und somit auch die Schnittstelle zur Benutzersoftware ist. Der D-Server hat außerdem als einzige Komponente einen direkten Zugriff auf die ODX-Diagnosedatenbank, welche in ihrer Funktion der ASAM-MCD-2D Schicht entspricht. Der interne Aufbau des D-Servers ist unterteilt in vier Funktionsbereiche (siehe Abb. 10). Der Kommunikationsbereich erzeugt protokollunabhängige Nachrichten, die er an die D-PDU API weiterleitet. Der Datenprozessor ist die einzige

14 14 Abb. 10 Struktur der Diagnosegruppe [9] Verbindung zur Datenbank und darüber hinaus zuständig für die Umrechnung zwischen steuergeräteinternen und physikalischen Werten. Über den Jobprozessor können Funktionen ausgeführt werden. Diese Funktionen sind in Java geschrieben und werden ebenfalls in der Datenbank gespeichert, von wo aus sie dem Anwender zur Verfügung stehen. Sie erzeugen automatisch Sequenzen von mehreren Diagnosebotschaften und können die zurückgelieferten Ergebnisse auch direkt verarbeiten. Der letzte Funktionsbereich des D-Servers ist der Flash-Data-Processor. Dieser bildet das Laufzeitsystem für die Programmierung von Steuergeräten (Flashen). Diese Funktion arbeitet eng mit dem Jobprozessor zusammen und ermöglicht es, den Speicher eines Gerätes zu entsperren, zu löschen und anschließend mit den neuen Applikationen und Parameter zu füllen. Eine weitere Besonderheit des Systems ist die sogenannte Pass-Through- Programmierung. Dabei ist es der Clientanwendung möglich, den D-Server zu umgehen und direkt mit der D-PDU API zu kommunizieren. Dadurch kann ein direkter Zugriff auf das Bussystem erfolgen [9] Datenformat bei der Diagnose Als Datenmodel für den Austausch von diagnoserelevanten Daten eines Fahrzeugs kommt das von ASAM entwickelte, auf XML basierende ODX-Format (Open Diagnostic Data Exchange) zum Einsatz. Bei der Kommunikation mit den Steuergeräten nutzt das Diagnosesystem die verbreiteten Diagnoseprotokolle KWP2000, UDS und OBD. Diese definieren allerdings lediglich das Botschaftsformat von Diagnosediensten. Die darüber übertragenen Parameter unterscheiden sich bei jedem Gerät und müssen daher für jedes Fahrzeug bzw. Steuergerät extra gespeichert werden. Das ODX-Format speichert dazu Informationen über den Diagnosezugang eines Fahrzeugs, sowie dessen Identifikationsdaten. Daneben enthält es auch Informationen über den Busaufbau, soweit diese für die Diagnosezwecke erforderlich sind. Zur Konfiguration der Diagnoseprotokolle werden außerdem die Parameter wie Bustimings und Übertragungsgeschwindigkeiten gespeichert (siehe Abb. 11). Die bei jedem Steuergerät zur Verfügung stehenden Diagnosedienste, Protokolle und Java- Diagnoseabläufe sind ebenfalls in ODX-Dateien gespeichert. Jede dieser Informationen bildet einen ODX-Datensatz, der in einer eigenen ODX-Datei abgelegt wird. Um redundante Datenhaltung zu vermeiden, können diese ODX-Datensätze auf andere ODX- Dokumente referenzieren. Diese Form der Datenhaltung hat außerdem den Vorteil, dass einzelne Dokumente einfach ausgetauscht werden können, sobald sich etwas ändert. So werden Informationen über die in den Steuergeräten integrierten Dienste, in der Regel vom Hersteller des Steuergerätes herausgegeben, wohingegen Informationen über die Integration des Steuergerätes in das Fahrzeugnetzwerk vom Fahrzeughersteller stammen. Um Diagnoseaufgaben an einem Fahrzeug durchzuführen, ist es daher nicht unbe-

15 15 Abb. 11 Komponenten des ODX-Datenmodells [9] dingt nötig, alle ODX-Dokumente für ein Fahrzeug zu besitzen. Es reicht, wenn nur die nötigsten Informationen bereitgestellt werden. Dadurch ist außerdem sichergestellt, dass der unbefugte Zugriff auf die Steuergeräte unterbunden wird. Der Zugriff kann nur auf Dienste und Funktionen erfolgen, die in den ODX-Dateien beschrieben sind. 3.7 Einsatz in der Praxis Das von ASAM entworfene System für Messungen und Kalibrierungen sowie für Diagnoseaufgaben von Steuergeräten stellt ein leistungsfähiges und universelles System dar. In der Praxis erfolgt eine Umstellung von den proprietären Systemen auf das neue System jedoch nicht sofort. Die bestehenden Systeme sind zuverlässig und erprobt. Ein Umstieg ist außerdem mit zusätzlichen Kosten verbunden. Die Kosten für die Erhaltung und den Einsatz proprietärer Systeme übersteigen langfristig gesehen jedoch die Kosten für standardisierte Systeme, sodass ein Umstieg bei den Automobilherstellern langsam absehbar ist. Die Zulieferbetriebe und Softwareanbieter haben hingegen schon seit längerer Zeit ASAM kompatible Produkte im Angebot. Dabei sind gerade Diagnosesysteme auf Basis von MVCI verbreitet, da diese bereits eine ISO- Normierung besitzen und somit einen zukunftssicheren Standard darstellen. Solange die anderen Systeme jedoch noch keinen ISO Standard bilden, stehen die Hersteller diesen weiterhin zögernd gegenüber. Der Einsatz des einheitlichen Datenformats ODX für Diagnosedaten wird hingegen von allen großen Automobilherstellern fest geplant und teilweise auch schon durchgesetzt [6]. Bei neueren Netzen wie z.b. FlexRay erfolgt der Einsatz von einheitlichen System dagegen recht schnell, da für diese Systeme bisher keine anderen Lösungen entworfen wurden. 4 Fazit Bei der heute eingesetzten Vielfalt an Bussystemen und Softwarelösungen ist ein standardisiertes Managementsystem eine effektive Methode, um Kosten zu senken und den

16 16 Aufwand bei der Fahrzeugentwicklung enorm zu reduzieren. So etwas funktioniert jedoch nur, wenn die Mehrheit der Hersteller diese Systeme auch einsetzt. Im Gegensatz zum Diagnosesystem sind die Applikationsbereiche des ASAM Servers noch in der Entwicklung und haben daher noch keine endgültige Normierung. Der Einsatz der Systeme wird dadurch momentan verzögert, jedoch nicht aufgehalten. Im Bereich der Diagnose schreitet die Entwicklung hingegen schneller vorran. Durch die standardisierten Systeme ist es einfacher die gesetzlichen Anforderungen umzusetzten und die große Masse an Fahrzeugelektronik zu kontrollieren, ohne dabei den Überblick zu verlieren. Gleichzeitig ermöglichen es diese Systeme, den Herstellern auch weiterhin die eigene Entwicklung voranzutreiben, ohne der Konkurrenz dabei Einblicke in ihr System zu ermöglichen. Literatur 1. Thomas Barthel. Austauschformat der Zukunft. technik-know-how/uebersicht/l/bussysteme/austauschformat-der-zukunft/, ASAM e.v. About ASAM Original Marken Partner Lernsysteme. Geschichte der Bussysteme im Kraftfahrzeug Marco Rohe. Stilkunde für Software-Modelle mit automatisierten Reviews. AUTOMOBIL ELEKTRONIK, Hüthig Fachverlag, 2(2):26 27, Peter Subke. Standardisierung der Fahrzeug-Diagnose. 6. Internationales CAR- Symposium, Jochen Thym. Standardisierung der Diagnoseprozessketten in der Fahrzeugelektronik - Ein Statusbericht. ATZelektronik, GWV Fachverlage, 2, Frank Bohne und Jürgen Döring. Standards für die Automobilindustrie. ELEKTRONIK AUTOMOTIVE, WEKA FACHMEDIEN GmbH, 1, Christoph Marscholik und Peter Subke. Datenkommunikation im Automobil: Grundlagen, Bussysteme, Protokolle und Anwendungen. Hüthig Verlag, Heidelberg, Werner Zimmermann und Ralf Schmidgall. Bussysteme in der Fahrzeugtechnik. Vieweg+Teubner, Wiesbaden, 2008.