Basiskonzepte
In OTX wurden verschiedene Basiskonzepte umgesetzt. Diese Konzepte widerspiegeln den Entwicklungsprozess von Prüfabläufen beim Automobilhersteller und dessen Zulieferern. Sie enthalten die jahrelang gewachsenen praktischen Erfahrungen mit Prüfabläufen und bilden neben den Erweiterungsbibliotheken den Domänen spezifischen Teil des Standards ab.
Ziel der Basiskonzepte: Reduzierung und Beherrschung der Komplexität |
Im nachfolgenden Abschnitt werden diese Konzepte aufgelistet und beschrieben:
Specification/Realisation Konzept
OTX unterstützt für die verteilte Entwicklung von Testsequenzen einen 3 stufigen Entwicklungsprozess. Beginnend mit einer abstrakten, allgemeinen Stufe werden die Abläufe immer weiter herunter gebrochen und detaillierter. In jeder Phase können die Abläufe mit Hilfe geeigneter Softwarewerkzeuge validiert, ausgetauscht und ausgeführt werden.
- 1. Stufe: Spezifikation (Spezifikationsphase)
- Die Spezifikationsphase dient der Beschreibung der Sequenzen (Spezifikation) in einer frühen Phase des Entwicklungsprozesses. Hier ist die allgemeine Ablauflogik zwar bekannt, jedoch die Details für eine ablauffähige Sequenz sind noch unklar, können aber in Prosa beschrieben werden. Der Ablauf wird aus einzelnen Aktivitäten zusammengesetzt, welche noch keine Realisierung haben. Das heißt, die Aktivitäten werden keiner konkreten Funktion zugeordnet. Ihnen wird lediglich ein Name und eine Beschreibung zugeordnet. Der Ablauf ist ausführbar. Da die Realisierung der Aktivitäten fehlt, werden sie mit Hilfe geeigneter Dialoge simuliert.
- 2. Stufe: Zwischenstufe (Realisierungsphase)
- In der Realisierungsphase implementiert ein Autor aus den Spezifikationen der Aktivitäten die einzelnen Realisierungen. Das heißt, er ordnet den Aktivitäten ohne Realisierung eine Funktion (Realisierung) zu und konfiguriert diese. Naturgemäß besteht der Ablauf in dieser Phase aus einer Mischung von Aktivitäten mit und ohne Realisierung. Auch hier ist der Ablauf ausführbar. Das Ablaufsystem führt die realisierten Aktivitäten aus. Es kann hier beispielsweise bereits eine Kommunikation mit einem Steuergerät stattfinden. Fehlende Realisierungen werden durch geeignete Dialoge „simuliert".
- 3. Stufe: Realisierung
- In der letzten Stufe gibt es für jede Spezifikation eine Realisierung. Die Sequenz ist voll ablauffähig. Es muss keine Aktivität simuliert werden.
Specification/Realisation-Konzept |
Kontext Konzept
Das Kontext Konzept ist praktisch ein Mapping-Mechanismus für Umgebungsparameter auf Ebene des OTX-Laufzeitsystems.
Die Laufzeitumgebung für OTX Abläufe ist in der Praxis sehr heterogen. Verschiedene innerhalb der OTX-Abläufe benötigte Informationen, die nicht aus den Steuergeräten ausgelesen werden können, müssen durch die Diagnoseanwendung bereitgestellt werden. Dies sind unter anderem:
- Fahrzeugdaten
- Fahrzeugmodell, Verkäufer, Identifikationsnummer, Motorisierung oder Sonderausstattungsdaten etc.
- Daten der Diagnoseapplikation (Tester)
- Name, Version, Verwendetes VCI, Anwendungseinstellungen etc.
- Benutzerdaten
- Benutzername, Benutzerrechte, Idle-Time etc.
- Umgebungsdaten
- Standort (z.B. Entwicklung, Produktion oder Service), Version des Betriebssystems etc.
OTX bietet dafür so genannte Kontextvariablen. Die Kontextvariablen werden durch den Autor einer OTX Sequenz definiert. Er kann sie dann innerhalb der Abläufe wie globale Konstanten verwenden. Die Variablen können nur gelesen und nicht geschrieben werden. Die OTX-Laufzeitumgebung (OTX Runtime) erkennt diese speziellen Variablen und fordert die Werte der Variablen von der Diagnoseapplikation an. Das Ablaufsystem unterstützt dazu ein Mapping-Interface, an welches sich die darüber liegende Anwendung einklinken kann.
OTX - Kontextvariablen zum Zugriff auf Umgebungsdaten |
Vorteile:
- Das Arbeiten mit Kontextvariablen ist gleich dem Arbeiten mit globalen Konstanten
- Für die Integration von OTX in bestehende Systeme kann die vorhandene Struktur weiterverwendet werden
- Beim Austausch der OTX Sequenzen mit anderen Laufzeitumgebungen, die ähnliche Information in ähnlicher Weise bereitstellen, muss nur der Mapping-Layer angepasst werden.
- Kontextvariablen können über eine spezielle Anwendung von extern simuliert werden.
Validity Konzept
Aufbauend auf dem zuvor beschriebenen Kontext Konzept unterstützt OTX ein so genannte Validity Konzept. Damit ist es möglich, Testsequenzen für unterschiedliche Umgebungsbedingungen zu konfigurieren. Innerhalb der Testsequenz kann über Validities entsprechend der jeweiligen Umgebung Teile der Sequenz aus- und einblenden.
Validities müssen auf Ebene eines OTX-Dokuments definiert werden. Sie bestehen entweder aus einer booleschen Kontextvariablen oder aus einem zusammengesetzten logischen Ausdruck (Validity-Term) vom Typ Boolean. Es können so mehrere Kontextvariablen verknüpft oder auch globale Konstanten verwendet werden. Aktivitäten, Sequenzen und Prozeduraufrufe werden über die ValidFor-Eigenschaft an eine Validity gebunden. Zur Laufzeit werden sie nur dann ausgeführt, wenn die Validity True ergibt. Sie sind somit nur im jeweiligen Umgebungskontext gültig.
Vorteile:
- Klare Abgrenzung zwischen Entscheidungen, die auf statischen, zur Entwicklungszeit bekannten Umgebungsdaten beruhen und Entscheidungen auf Basis dynamischer Werte.
- Validities steuern den Ablauf implizit über die Umgebungsdaten und nicht explizit über Verzweigungen (IfElse-Branch). Dadurch wird die Anzahl der Verzweigungen deutlich verringert und der Ablauf kompakter und leichter lesbar. Die eigentliche Testlogik wird besser sichtbar.
- Es ist möglich einen Satz häufig verwendeter Validities in einem separaten Dokument zu speichern und dies an einem zentralen Ort allen Autoren zugänglich zu machen. Damit werden Redundanzen vermieden und die Wartbarkeit wird erhöht.
- Eine OTX Autorenumgebung ist u.U. in der Lage, verschiedene Umgebungsszenarien darzustellen, indem es nicht verwendete Zweige ausblendet (Filterung).
- Ist die Basis für das Signatur-Konzept, siehe nächster Abschnitt.
Validity-Konzept |
Signatur Konzept
Das Signatur Konzept basiert auf dem Validity Konzept und ist diesem ähnlich. Validities beschreiben die Gültigkeit einzelner Aktivitäten. Über Signaturen kann die Gültigkeit einer Prozedur beschrieben werden. Eine Signatur beschreibt ein Interface oder Prototyp für eine Prozedur. Eine Signatur ist somit wie eine Prozedur ohne Implementierung. Signaturen besteht aus Namen, Ein- und Ausgabeparametern sowie einer Beschreibung. Prozeduren können über Signaturen indirekt aufgerufen werden. Der Aufrufer muss nur die Parameter und die Spezifikation aber keine Implementierungsdetails der Prozedur kennen. Signaturen erlauben das Erzeugen von generischen Sequenzen, die sich den jeweiligen Umgebungsbedingungen zur Laufzeit anpassen können.
Signatur-Konzept |
Vorteile:
- Sequenzen müssen nicht geändert müssen, wenn ein neuer Kontext hinzugefügt wird.
- Erhöht die Wartbarkeit bei der Langzeitverfügbarkeit von Testsequenzen.
- Ermöglicht die verteilte Entwicklung von Testsequenzen. Die Signatur dient dabei als formale Definition der Schnittstellen zwischen den einzelnen Partnern.
Basiskonzepte für das Variantenmanagement im Vergleich |
Siehe auch