Die Umgebung wurde erstellt, um die folgenden Bedingungen zu erfüllen:
Um dies zu unterstützen, wird die gleiche Art der Arbeitsumgebung benutzt, wie sie in der Softwareentwicklung weitläufig bekannt ist: Eine Kommandozeilen basierte Schnittstelle, in der die verschiedenen Arbeitsschritte gestartet werden und durch sogenannte Makefiles, Skripte und andere eingebauten Werkzeuge kontrollliert werden können.
Das bedeutet das alle Schritte, durch das Tippen des entsprechenden Kommandos und seiner Parameter in die Kommandozeile, gestartet werden können.
Um die wesentlich mächtigere UNIX Umgebung zu nutzen, anstelle einer sehr einfachen DOS Kommandozeile, musst Du zunächst das CygWin Runtime Environment installieren. Um dies zu tun, folge bitte den CygWin Installationsinstruktionen
Nach dem Installieren und Starten von CygWin, wird Dir eine DOS ähnliche Kommandozeile dargeboten, mit einigen Unterschieden zu dieser:
Sobald mehrere Skripte beibehalten werden müssen oder mehr als eine Person auf den Skripten arbeiten, ist es sehr empfehlenswert, ein zentrales Skript-Repository zu verwenden, wie wir es hier in unserem Beispiel mit einem zentralen Subversion Server tun. Die Nutzung von Subversion als solches fällt nicht in den Anwendungsbereich dieses Dokuments, aber Du wirst Tonnen von Unterlagen im Internet zu diesem Thema finden. Bitte lies einige Basis-Tutorials durch die Dir ein grundlegendes Verständnis über Subversion vermitteln.
Um sich mit dem sogenannten “Repository” zu verbinden nehme bitte Kontakt mit dem Repositoryadministrator (S.K.) auf. Von Ihm erhältst Du die sogenannte Repository-URL, deinen Nutzernamen und dein Passwort.
Als nächstes erzeuge ein leeres Verzeichnis, in dem Du deine Skripte z.B auf dem Desktop speichern möchtest
cd /cygdrive/c/Nutzer/deinNutzername/Desktop mkdir OOBD-Script-Repository cd OOBD-Script-Repository
als nächstes erzeuge eine sogenannte “lokale Arbeitskopie” des Repositorys mit dem Kommando
svn checkout Repository-URL
Du wirst nach deinem Nutzernamen und deinem Passwort gefragt und dann transferiert SVN (die Abkürzung für Subversion) das komplette Repository in dein Arbeitsverzeichnis.
Du wirst später vielleicht feststellen das eine Menge von .svn Verzeichnisse erzeugt worden sind. In diesen speichert Subversion Metadaten für die Wartung. Bitte lösche oder verändere diese Verzeichnisse nicht!
Um die verfügbaren Werkzeuge für OOBD zu nutzen, ist es wesentlich das Du die Datenstruktur so beläßt wie sie ist, weil die Werkzeugeinstellungen darauf beruhen.
Nach dem Beenden des initialen Auscheckens, findest Du einen Verzeichnis- und Datenstruktur wie folgt vor:
. +-- ... +-- lua +-- mdx_pool +-- oobd_groups.pub +-- oobd_groups.pub.sig +-- tools
So, wofür ist dies nun alles gut?
Das mdx_pool ist das Verzeichnis, in dem alle XML Module abgespeichert werden können, immer nach der Bezeichnung FahrzeugBaureihe_ModellJahr_Modulkurzname
Das tools Verzeichnis beinhaltet alle Programme und Skripte die für OOBD notwendig sind. Der erfahrene Nutzer möchte vielleicht wissen das einige der Unterverzeichnisse als sogenannte “svn:external” zu anderen Repositorys verbunden sind.
Das oobd_groups.pub ist ein pgp Schlüsselbund welcher die öffentlichen Schlüssel der Arbeitsgruppen enthält , mit denen die Ausführungsrechte überprüft werden.
Letztlich gibt es noch das lua Verzeichnis, welches die Lua Skripte und noch jede Menge anderes Zeug enthält:
. +-- car1_my99_r ¦ +-- mdx_pool_reference ¦ +-- car1_my99_carcheck.carcheck ¦ +-- car1_my99_sw_versions.lua ¦ +-- lua_reference ¦ +-- files.inc ¦ +-- makefile ¦ +-- presets.rtd ¦ +-- ABC.seccode +-- car1_my99_s ¦ +-- ... +-- car1_my99_t ¦ +-- ... +-- car1_my99_w ¦ +-- ... +-- carcheck.footer +-- carcheck.header +-- carcheck.xslt +-- db ¦ +-- oem.oodb ¦ +-- VehInfo_Stylesheet.xsl +-- generic.make +-- Healthfiles ¦ +-- OOBD-xmlfile.xml +-- lib_lua ¦ +-- ... +-- lib_protocol ¦ +-- ... +-- local.make +-- local_template.make +-- makefile
Innerhalb des lua Verzeichnisses wird alles komplettiert. All diese Dateien haben verschiedene Bedeutungen:
Diese Verzeichnisse enthalten die Fahrzeugreihe und Modelljahr spezifischen Inhalte. Aber auch jedes Verzeichnis repräsentiert eine so genannte Arbeitsgruppe, welche benutzt wird wenn du die verschlüsselten Skripte benutzen möchtest. Wenn Du das tust, ermöglichst du den Nutzerzugriff für jede Arbeitsgruppe einzelnd, das bedeutet Du erlaubst den Nutzer das zu nutzen was Du in diesem Verzeichnis übersetzt.
Um eine klare Trennung zwischen den verschiedenen Niveaus der Risiken, was ein Benutzer mit Hilfe eines Skripts falsch machen kann zu etablieren, verwenden wir die Verzeichnisnamen um Erweiterungen zu definieren, in welchem Verzeichnis ein Skript gespeichert werden muss. Dies geschieht um Missbrauch zu vermeiden. Die Erweiterungen sind ihre Bedeutung sind:
| Erweiterung | Bedeutung |
|---|---|
| _r | Nur lesenden Zugriff - Kein Risiko einer nicht sachgemäßen Benutzung (sollte als Grundeinstellung für jeden nicht erfahrenen Erstnutzer erlaubt werden) |
| _t | Zeitlich begrenzte Veränderungen - wie z.B. das Aktivieren von Ausgaben, die aber wieder in den Grundzustand versetzt werden, wenn die Diagnosesession endet. Geringes Risiko durch z.B Bewegen von Scheibenwischern (Ratschlag für Nutzer) |
| _s | Service - Zum Starten von Testsequenzen, ändern von z.B dem Faktorymode des Fahrzeugs oder anderes (für Servicepersonal und andere Personen, die sich im Reparaturbereich eines Automobilbauers befinden) |
| _w | Schreibenden Zugriff: Volle Kontrolle über das System Auto (nur für erfahrene Spezialisten) |
Wann immer Du eine Modulspezifikation aus dem Modulpool für diese bestimmte Fahrzeugbaureihe und Zugriffsebene kompilieren möchtest, listest Du den Namen der betroffenen Moduldateien in dieser mdx_pool_reference- Datei. Mit dieser Referenz, muß die Modulspezifikation nur in dem Pool-Verzeichnis gespeichert werden und es kann von verschiedenen anderen Orten darauf verwiesen werden.
Wann immer der Bauprozess ein *.carcheck Skript findet, nimmt es eine Liste von Modulen von dieser Fahrzeugbaureihe aus der mdx_pool_referenz und baut daraus eine Art von Summationskript auf, welches alle Module in sich aufnimmt und damit einen schnellen Überblick über das komplette Fahrzeug ermöglicht. Durch das Hinzufügen von Inhalt in dieses *.carcheck Skript, können ein paar Fahrzeugbaureihenspezifische Ausgaben zu dem generischen Inhalt der Fahrzeugauflistung hinzugefügt werden. “Inhalt”
Im Gegensatz zu all den anderen automatisch erzeugten Ausgaben ist dies ein rein manuell hergestelltes Skript. Wenn der Bauprozess ein *.lua Skript findet, übersetzt er es.
In Verbindung mit den “seccode” Dateien (siehe weiter unten) kannst Du das gleiche Skript für verschiedene Sicherheitsebenen übersetzen. Mit der lua_referenz Datei kannst Du das Original Skript in einem anderen Verzeichnis, auf es referenzieren und es in dem aktuellen Verzeichnis mit einem anderen Sicherheitlevel zu übersetzen.
Durch ein Abkommen muss das originale Skript in einem Arbeitsgruppenverzeichnis mit seinem geringsten Sicherheitslevel abgelegt werden und der höhere Sicherheitslevel muss darauf referenzieren.
*.seccode Dateien enthalten einen Teil des Lua Kodes, welcher den Sicherheitszugriffskode der Module definiert.
In den Luaskripten selbst kann dann das Pseudo Kommando – optinclude(“ABC.seccode”), in denen der seccode nur enthalten ist wenn das Skript existiert. Es erzeugt aber keine Fehlernachricht wenn das Skript nicht existiert.
Aus Geheimhaltungsgründen sind diese *.seccode Dateien in dem Softwarerepository nicht eingebunden. Es ist ausserdem verboten diese oder andere Formate von Sicherheitskodes in das Repository hochzuladen. Deshalb hat jeder Entwickler sein Wissen über über Sicherheitskodes lokal für sich zu behalten und darf es nicht im Repository publizieren.
Jede andere Datei, welche später vom Skript benötigt wird und welche nun nicht Teil des Übersetzungsprozess ist, wie z.B. DTC Datenbasen, kann in files.inc aufgelistet werden. Dadurch wird sie verschlüsselt und auch in das Ausgabeverzeichnis kopiert.
Dieses Makefile muss nicht editiert werden. Es wird nur für den Bauprozess benötigt.
für spätere Erweiterungen.
Diese sind Vorlagen für die carcheck Skripte
Die hierin enthaltene Datenbasendateien (*.oodb) werden gespeichert um zu files.inc zu referenzieren, aber auch das stylesheet (VehInfo_Stylesheet.xsl) für einen Vehicle Health Report wird hier gespeichert.
Diese Datei kontrolliert den gesammten Bauprozess und darf aus sehr guten Gründen nicht verändert werden…
Wenn ein Fahrzeugreport erstellt wird durch die Benutzung des Skripts Carcheck, sollten die dabei entstandenen XML Dateien hier gespeichert werden. Wenn diese Datei in einem Webbrouser geöffnet wird, zeigt diese automatisch auf VehInfo_Stylesheet.xsl in dem db Verzeichnis und präsentiert die Daten mit dem richtigen Stylesheet.
In dieser findest du einige Lua Bibliotheksskripte für generische Funktionen
In dieser hier findest du einige Lua Bibliotheksskripte für diagnosebezogene Funktionen
local.make enthält deine persönlichen Einstellungen. Es ist nicht Teil des Repositorys, weil es für jeden Benutzer unterschiedlich ist. Um die eigenen Einstellungen zu erzeugen, kopiere die Templatedatei lokal template.make und mache deine Einstellungen in local.make
cp local_template.make local.make
Auch in dem lua Basisverzeichnis wird das Makefile für den Bauprozess benötigt. Ändere es einfach nicht.
Im Gegensatz zu dem komplizierten Setup und den obigen Erklärungen, ist der eigentliche Bauprozess sehr einfach:
Bearbeite oder füge Dateien hinzu wie Du es benötigst. Für einen guten Start, wähle eins der existierenden *.lua Dateien, kopiere es wohin du es benötigst und gib Ihm einen eindeutigen Namen. Stelle sicher das die Fähigkeiten des Skriptes, nicht die Sicherheitsrechte des Arbeitsgruppenordners überschreiten in dem es abgelegt ist.
Tippe dann die cygwin Kommandozeilenbefehle in das Cygwinterminalfenster, eins nach dem anderen ein. Wenn Du dies in einem Arbeitsgruppenordner machst, werden nur die Dateien in diesem Ordner bearbeitet. Wenn Du die Kommandos in in einem Lua-Wurzelverzeichnis zur Ausführung bringst, werden alle Arbeitsverzeichnisse, welche Du in local.make eingetragen hast, ausgeführt.
Danach kann das Ergebnis in dem konfigurierten Zielverzeichnis gefunden werden und ist nun bereit zur Verteilung.