Die Umgebung wurde erstellt, um die folgenden Bedingungen zu erfüllen:

• Handhabung von verschiedensten Fahrzeugbaureihen, jede mit Duzenden von Modulspezifikationen und Skripten.
• Stapelübersetzung von XML Modulspezifikationen , handgeschriebenen Skripten und anderen Vorlagen in einem einzigen Schritt
• Automatische Verschlüsselung der erzeugten Skripte, falls gewünscht

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:

• Unix achtet auf Gross- und Kleinschreibung, deshalb muss alles immer korrekt geschrieben werden.
• Die Basikommandos sind unterschiedlich zu denen, die Du von DOS/Windows her kennst. Eine gute Einführung in die Thematik kann unter http://mally.stanford.edu/~sr/computing/basic-unix.html gefunden werden
• Unix benutzt in diesem speziellen Bereich keine Backslashes \ in Pfaden, es benutzt anstelle dessen einen normalen slash /
• Unix kennt keine Laufwerksbuchstaben wie C:\. Anstelle jedes Laufwerkes und Verzeichnisses gibt es einen Unterordner unter dem globalen Wurzelverzeichnis “root” /cygdrive. So wird aus dem Laufwerk C:\ dann /cygdrive/c/, dein Desktopverzeichnis wird dann /cygrive/c/Users/yourusername/Desktop heissen (Achte auf die Gross- und Kleinschreibung!)
• mit den Pfeiltasten kannst Du in der Historie der eingegebenen Kommandos blättern. Sehr hilfreich kann auch ohne dass komplette Abtippen des Kommandos die
• TAB Taste sein mit der Kommandos und Dateinamen automatisch komplettiert werden.
• Sehr wichtig! Unix Textdateien haben einen anderen Ende-der-Zeile Kennzeichner als Windows. Deshalb stelle bitte immer sicher, wenn Du Dateien ertellst oder editierst, das alle die Dateien im “Unix Line feed UTF8 without BOM” Format abgespeichert werden.

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:

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.

1. make clean: dies entfernt alle älteren Ergebnisse und temporären Dateien.
2. make: Dies konvertiert alle Modul-xml Dateien , alle anderen Templates und alle *.lua Dateien in Lua Quelldateien mit der Endung .luasource. Obwohl normale *.lua Dateien damit kopiert werden, ist diese Namensänderung notwendig, um nicht ungewollt einige handgeschriebenen *.lua Dateien beim Aufruf von “make clean” zu löschen.
3. make scripts: Dies startet den eigentlichen Übersetzungsprozess, in dem der lua-Übersetzer alle luasource Daten nimmt und sie in vorübersetzte Binärdateien übersetzt.(*.lbc). Hinweis: Während der Übersetzung eines Skripts, werden alle include Dateien mit einer temporären Datei zusammengefasst und unter lua.tmp abgelegt.Wenn der Übersetzer mit einer Fehlernachricht abbricht, ist dies die richtige Datei um nachzuschauen woran der Übersetzer gescheitert ist.
4. make pack: Wenn dies konfiguriert und eingeschaltet ist im local.make wird es die übersetzten *.lbc Dateien nehmen und in Abhängigeit des Verzeichnisses, in dem Sie sich befinden, verschlüsseln, eine Ordnerstruktur im Zielverzeichnis erstellen, wie sie in local.make konfiguriert worden ist und dann die Ergebnisse dorthin kopieren.

Danach kann das Ergebnis in dem konfigurierten Zielverzeichnis gefunden werden und ist nun bereit zur Verteilung.