Oracle XML DB in der Praxis bei Lamborghini

KONFERENZ
Mittwoch, 10. November 2004
14h00, Variohalle 5
Oracle XML DB in der Praxis
bei Lamborghini
Andreas Hege
RA Consulting GmbH, Bruchsal
Schlüsselworte:
Oracle XML-Datenbank, RA Consulting, Lamborghini Gallardo, XML-Dokumente, Browserbasierte Web-Anwendung
Zusammenfassung
Die Stückzahlen und die gesteigerte Anzahl von Elektronikkomponenten des
neuen Lamborghini-Sportwagens L140 (Gallardo) erforderten die Einführung
eines neuen Systems zur automatischen Inbetriebnahme der Fahrzeuge am
Bandende der Produktion.
In Abhängigkeit von der Teileliste müssen entsprechende Setup-Prozeduren
durchgeführt werden, die über einen Java-Konfigurator spezifisch für dieses
Fahrzeug zusammengestellt werden. Am Ende steht das Programmieren der
Steuergeräte mit mobilen Endgeräten in einem finalen Setup und das Archivieren der dabei gewonnenen Ergebnisse. Lamborghini wählte dafür eine
speziell angepasste Version des RA Consulting Produkts DiagRA, das auf mobilen Endgeräten ausgeführt wird, und über Wireless-LAN mit dem Backend verbunden ist.
Dort kommt eine Oracle Datenbank Release 9.2 zum Einsatz. Deren XML-Technologie erlaubt es, die beim Setup des Fahrzeugs anfallenden XML-Dokumente
direkt per FTP in die Datenbank zu laden. Einmal in der Datenbank erfüllen die
Dokumente sämtliche Anforderungen hinsichtlich Archivierung, Zugriffsicherheit und Verfügbarkeit. Der Zugang zu den Dokumenten erfolgt entweder
direkt über eine XSL-Tranformation im browserbasierten Control-Center, oder
über SQL-Abfragen, die Auswertungen auf den XML-Dokumenten zulassen. Die
Ressourcen der Anwendung, FTP-Verzeichnisse, URLs und Datenbanktabellen,
werden den einzelnen Datenbank-Benutzern bzw. den Rollen per Access-Control-Lists (ACL) zugewiesen. Dadurch entfällt eine Unterscheidung zwischen
den Benutzern der Datenbank, der Web-Anwendung und des FTP-Dienstes.
Bei der Einhaltung des vorgegebenen Zeitrahmens von drei Monaten, von der
Planung bis zur Produktion der Serie, zeichnete sich die XML-Datenbank vor
allem durch ihre Schlankheit aus. Die Installation und die Integration von FTPServer, Datenbank und HTTP-Server entfällt zu Gunsten der Systemadministration nur einer Komponente, der Oracle XML-Datenbank.
Ausgangssituation
90°-V-Motor mit 5 Litern Hubraum, 10 Zylindern, je zwei oben liegenden
Nockenwellen (DOHC), 500 PS und einem Drehmoment von 510 Nm. So
bietet die 1963 gegründete Lamborghini Automobili S.p.A. ihren Gallardo seit
dem letzten Jahr an. Die Entwicklung dieses Boliden stellt nicht nur im Blickpunkt auf den Motor, sondern auch hinsichtlich der Fahrzeugelektronik einen
Meilenstein in diesem Segment dar. Während das flügeltürige Flagschiff des
Autobauers, der Murcielago, noch sehr sparsam mit Elektronik bestückt ist,
sollte der Gallardo sich am aktuellen Standard orientieren. Dazu gehören
neben Klimatronic, vor allem Navigation und Sicherheitssysteme. Ein ehrgeiziges Ziel dieser Art stellte erhöhte Anforderungen an Entwicklung, Produktion,
Qualitätssicherung und After Sales.
Im modernen Fahrzeug bilden die vernetzten Steuergeräte das Rückgrat der
Elektronik. Sie bieten nicht nur Funktionalität, sondern auch die Möglichkeiten der Fahrzeug-Diagnose; ein wichtiges Hilfsmittel, sowohl bei der produktionsnahen Qualitätskontrolle, als auch beim Service im After-Sales Bereich.
Diagnose-Tester bieten sowohl die Möglichkeit, Parameter im Steuergerät einzustellen, als auch Bauzustände und Fehlerkonstellationen zu dokumentieren.
Qualitätssicherung, Service und nicht zuletzt der Gesetzgeber fordern die dauerhafte Speicherung dieser Ergebnisse, die zum festen Teil des Lebenszyklus
eines Fahrzeugs werden.
Abb. 1: Der Lamborghini Gallardo
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
Projektanforderungen
Aus der gemeinsamen Tätigkeit mit der Lamborghini-Entwicklung wurden
zusammen mit dem Produktionsleiter im Bereich der Elektronik die Anforderungen für das Projekt LaRA End-Of-Line (LaRA-EOL) definiert.
Funktionalität. Der Konfigurationsprozess am Bandende muss vom ersten Produktionstag stabil funktionieren. Abstriche an der Funktionalität und manuelles Eingreifen in den automatisierten Prozess geht zu Lasten der Qualität und
verstoßen im Extremfall gegen die vom Gesetzgeber vorgegebene Dokumentationspflicht. Die Folgen können Verweigerung der Zulassung in bestimmten
Ländern oder Rückrufaktionen sein.
Integration. Das System wird in die bestehende IT-Struktur bei Lamborghini eingebunden. Information vom Bestellsystem, von Prüfständen und anderen
Systemen sind zu berücksichtigen. Möglichst standardisierte Austauschformate
und Protokolle werden für die Integration verwendet.
Time-To-Market. Der enge Zeitrahmen von drei Monaten verlangt eine sehr
robuste schlanke Lösung, möglichst ein Off-The-Shelf Produkt im BackendBereich, das einfach konfigurierbar ist.
Flexibilität, Robustheit. Aufgrund des Quantensprungs in der Fahrzeugelektronik
bei Lamborghini kann nur begrenzt auf bereits erprobte Prozesse zurückgegriffen werden. Ziel der Umsetzung ist es damit, Änderungen in den Anforderungen möglichst schnell und sauber in das System einzubringen. Ein zentrales Logging-System soll zudem den Prozess von Fremdsystemen abgrenzen
und robuster machen.
Finanzieller Rahmen. Vergleichbare Systeme fanden bis dahin nur für größere
Absatzzahlen ihren Einsatz. Die Kosten sind auf die geplanten Produktionszahlen anzupassen, so dass der finanzielle Rahmen im niedrigen, einstelligen
Prozentbereich herkömmlicher Systeme liegt.
Mobilität. Die Setup-Prozedur wird mit mobilen Geräten am Fahrzeug durchgeführt. Dieses Gerät ist über WLAN mit dem Backend verbunden. Durch die
hohe Anfälligkeit von WLAN muss der Prozess mit sporadischen Verbindungen
auskommen. Eine dauerhafte Verbindung kann nicht gewährleistet werden.
Hohe Ausfallsicherheit. Da der Prozess unmittelbar der Produktion zugeordnet
ist, deren Ausfall letztendlich immense finanzielle Auswirkungen hat, ist eine
hohe Ausfallsicherheit vorzusehen. Bei Ausfall des Netzwerks oder der Datenbank, sollen die mobilen Endgeräte trotzdem in der Lage sein, die Fahrzeuge
noch bis zu 24 Stunden zu parametrisieren. Zusätzlich wird eine möglichst
kurze Recovery-Zeit der Datenbank geplant.
Wartbarkeit. Die Anzahl der Komponenten des Systems wird minimiert.
Dadurch sind weniger Schnittstellen zu warten. Ein Benutzer soll das System
möglichst als eine Komponente wahrnehmen (Nur ein Benutzer/Passwort für
das System). Ein Backup-Konzept erfasst das System ganzheitlich.
Neben dem Quantensprung in der Elektronik forderte die gesteigerte Stückzah
im Vergleich zum Murcielago unter anderem einen höheren Grad an Automation, Logistik oder Kundenbetreuung.
Wahl der Oracle XML-Datenbank
Während als Diagnose-Tool das modifizierte Standard-Tool DiagRA von RA
Consulting zum Einsatz kam, wählte man im Backend-Bereich eine Oracle
Datenbank. Ab Release 9.2 ist diese bereits in der Standard-Edition mit der
XML-Funktionalität ausgestattet. Die Wahl fiel nach den oben genannten
Kriterien.
Die Dokumentationspflicht, die der Gesetzgeber vorschreibt, führte von
Anfang an zu einer Oracle-Datenbank. Die Verfügbarkeit von DBA-Resourcen,
das Abstimmen der Backup-Strategie mit Lamborghini und die Verwaltung der
Server-Hardware stellen dabei die Dauerhaftigkeit der Dokumentenarchive
sicher und ermöglichten eine geordnete Übergabe der Datenbank.
Das folgende Bild zeigt eine Übersicht über die verwendeten Protokolle und das
System als Black-Box. Die Reduktion auf die Standards FTP und HTTP wurden
hier hervorgehoben.
Abb. 2: Protokolle: Das LaRA-EOL System als Blackbox.
Genauso, wie bei den Protokollen auf Standardisierung geachtet wurde, so
wählte man für den Datenaustausch ein möglichst einheitliches Format. Das
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
folgende Bild zeigt, dass als Austauschformat, bis auf eine Ausnahme, XML
bzw. HTML verwendet wurde.
Abb. 3: Austasuchformate Das LaRA-EOL-System als Blackbox.
Durch die Standardisierung der Protokolle und Austauschformate konnte das
System praktisch ohne Änderung angebundener Systeme realisiert werden, ein
wesentlicher Punkt um den Zeitrahmen einzuhalten. Die bisher gezeigten
Anforderungen sind zwar nicht ungewöhnlich für ein Integrationsprojekt, mit
einer herkömmlichen Lösung würde man aber bei einem recht heterogenen
System landen. Schnittstellen müssen nicht nur hinsichtlich des Datenaustauschs definiert und dokumentiert werden, sondern auch mit Blickpunkt auf
die Zugriffsrechte. Das folgende Bild zeigt ein solches heterogenes System, die
Blockpfeile stellen dabei die Schnittstellen dar.
Abb. 4: Heterogene Systemlösung für LaRA EOL.
Die Oracle XML DB bietet nun für diese Problemstellung eine einheitliche
Lösung, die nächste Abbildung zeigt ihren Einsatz.
Abb. 5: Oracle XML-DB als Off the Shelf Integration
Schnittstellen werden nicht programmiert, sondern lediglich konfiguriert.
Datenaustauschformate werden durch XML Schema-Definitionen parametriert. Diese sind sowohl der Datenbank als auch dem Fremdsystem bekannt,
das mit der XML DB kommuniziert. Zugriffsrechte werden mit Access-ControlLists (ACL) definiert, die für Datenbankbenutzer bzw. für Datenbankrollen die
Zugriffsrechte auf Resourcen wie HTTP-Seiten, FTP-Verzeichnisse regeln. Da die
XML-Dokumente in der Datenbank in objektrelationalen Tabellen gespeichert
sind, kann auch mit Datenbank-Views per SQL auf die Daten zugegriffen werden. In diesem Fall werden die Zugriffsrechte mit Grants auf die DatenbankViews geregelt.
Schnittstellen zum Benutzer werden mit XSL-Stylesheets realisiert. Mit ihnen
können XML-Dokumente in der Datenbank ohne Umwege als HTML angezeigt
werden.
Auf diese Weise stellt die XML DB eine Systemkomponente dar, die von den
verschiedenen Benutzergruppen unterschiedlich wahrgenommen wird:
• Der DBA sieht die Oracle XML DB als Datenbank-Instanz. Er kann sie mit den
vertrauten Oracle-Tools verwalten und sichern. Im Falle eine Crashs gibt es
genau ein System, das wiederhergestellt wird.
• Eine integrierte Fremdapplikation nimmt sie als FTP-Server wahr. Ein FTPBenutzer kann – je nach Berechtigung – die Verzeichnisse sehen oder Dateien
hochladen.
Database
17. Deutsche ORACLE-Anwenderkonferenz
KONFERENZ
• Der HTTP-Benutzer sieht die Oracle XML DB als Web-Server, an den er seine
HTTP-Requests sendet und HTML als Ergebnis zurückbekommt.
Die Parametrisierung unterstützt dabei die Flexibilität des Systems. Ändern sich
die Anforderungen, so muss nur selten Programmcode angepasst werden. Die
Änderung der Schema-Definitionen oder der ACLs genügen meistens, um das
System anzupassen.
Anwendungsfall für die Aufnahme eines neuen Dokumententyps in der
Datenbank.
Hier wird ein neuer Dokumententyp in der XML DB registriert, und die Zugriffrechte darauf definiert. Dann werden die Dateien in die Datenbank hochgeladen und die Information per XSL-Stylesheet zur Anzeige bebracht. Die einzelnen Schritte sind:
1.
2.
3.
4.
Definition des Dokumententypes in einem W3C XML Schema.
Registrieren des Dokumententyps in der XML Datenbank.
Anpassen der Zugriffsrechte auf FTP- und HTTP-Resourcen per ACL.
Hochladen einer XML-Datei des neuen Dokumententyps mit einem herkömmlichen FTP-Client.
5. Definieren eines XSL-Stylesheets zur Anzeige des Dokumententyps.
6. Betrachten des Dokumentes mit einem herkömmlichen Browser.
Ausblick
Durch die leicht zu verwendenden Standards FTP und XML konnten zahlreiche
Folgeprojekte realisiert werden, bei denen zunehmend Daten von Fremdsystemen in der XML DB archiviert werden. Dazu gehören Prüfstandsdaten, Produktionsdaten, Daten zur Qualitätssicherung und andere.
Der XML DB, die im Moment nur im Intranet verfügbar ist, wird ein Händlerprotal vorgeschaltet, das den Service im After-Sales Bereich an die XML-Datenbank anbindet.
Die Fülle an Information, die durch die Produktionsdaten und durch die
zusätzlichen Daten von Fremdsystemen in der XML DB vorhanden sind,
wecken den Wunsch, ein Datawarehouse zu realiseren, in dem die Produktiondaten nach betriebswirtschaftlichen und qualitässichernden Aspekten ausgewertet werden.
Obwohl die Murcielago-Baureihe weder der elektronische Komplexität, noch
den Absatzzahlen des Gallardo nahe kommt, wird im Moment ein Projekt definiert, um den Produktionsprozess des Murcielago in die Archivierung aufzunehmen.
Kontaktadresse:
Andreas Hege
RA Consulting GmbH
Zeiloch 6A
D-76646 Bruchsal
Telefon:
Fax:
E-Mail:
Internet:
+49(0)7251-386228
+49(0) 7251-386211
[email protected]
www.rac.de
Database
17. Deutsche ORACLE-Anwenderkonferenz