Was ist OTX? Der generische Tester Demonstration Praktische Anwendung

Transkript

1

2 2

3 Diagnoseprozesskette Vergangenheit 3 Systemlieferant Entwicklung Produktion Diagnosesystemlieferant Service Die herkömmliche Diagnoseprozesskette ist gekennzeichnet durch einen heterogenen Austausch von diagnoserelevanten Informationen

4 Diagnoseprozesskette Zukunft: OTX/ODX 4 Systemlieferant Entwicklung Produktion Diagnosesystemlieferant Service Lieferanten Diagnose Datenbank Hersteller Diagnose Datenbank Hersteller Diagnose Datenbank Internet OTX ODX OTX ODX OTX ODX OTX ODX Austausch von standardisierten Diagnosedaten über alle Phasen des Fahrzeuglebenszyklus Grundprinzip: Single Source

5 ODX, MCD 2 (ISO ) OTX Open Diagnostic Test sequence exchange 5 OTX = Open Test sequence exchange (ISO 13209) Domänen spezifische Sprache auf hoher Abstraktionsebene Ziel: Formale, graphische Beschreibung von Diagnosesequenzen Plattform und Tester unabhängiges Austauschformat Enthält leistungsfähige Konzepte zur Komplexitätsreduzierung Prozesssichere Alternative für die Java-Jobs in ODX Anwendungsbereiche: Fahrzeugdiagnose, Testautomatisierung, HIL-Simulation etc. Initiale Anwendung: Austauschformat für ODX basierte Diagnosesequenzen Erst mit OTX/ODX liegt eine vollständige, datengetriebene Lösung für die gesamte Diagnoseprozesskette vor Test- und Diagnoseanwendungen Test- und OTX Diagnoseanwendungen (ISO 13209) API D-Server API, MCD 3 (ISO ) Modular VCI Runtime System (MVCI, ISO 22900) D-PDU API, MCD 1 (ISO ) Vehicle Communication Interface VCI ECU ECU ECU OTX ODX

6 Diagnosesequenz in Zusammenspiel mit Nutzer- und Fahrzeuginteraktion 6 Off-Board Kommunikation A Request/Response x? Steuergeräte y? z? B C C D GUI ShowScreen E E Rekursiver Funktionsaufruf Prüfsequenz OTX Externe Sensoren & Aktoren Diagnosetester in Entwicklung, Produktion & Service

7 Anwendung in der Diagnoseprozesskette 7 OTX Steuergeräte Hersteller Entwicklung Diagnosefunktionen HIL-Tests Diagnose in der Produktion After-Sales Diagnose Diagnose Doku (GVO, Euro 5, Hotline ) Entwicklung Produktion Service Ziel: Austausch und Archivierung von verifizierten, praxiserprobten Diagnosesequenzen

8 8 Diagnostic Tester Application DateTime Logging EventHandling I18n StringUtil Math Quantities OTX OTX Core Processing System HMI DiagCom Job/Flash Measure HMI Device (e.g. Keyboard, Mouse, Screen ) Diagnostic Runtime System (e.g. MVCI Server, D-Server, ) Measurement Data Acquisition Other Device (e.g. HIL-API, ASAM GDI)

9 Basiskonzepte 9 Basiskonzepte, repräsentieren die Erfahrungen bei Erstellung von Diagnoseabläufen. Ziel: Reduzierung und Beherrschung der Komplexität Specification/Realisation-Konzept Prozessmanagement Kontext-Konzept Validity-Konzept Variantenmanagement Signatur-Konzept

10 Specification/Realisation-Konzept I 10 OTX unterstützt einen 3 stufigen Entwicklungsprozess: 1. Spezifikationsphase Zur Spezifikation von Sequenzen in einer frühen Phase des Entwicklungsprozesses Die allgemeine Ablauflogik ist bekannt Details für eine ablauffähige Sequenz sind noch unbekannt, können aber in Prosa beschrieben werden 2. Zwischenphase Eine Mischung aus Spezifikations- und Realisierungsphase Der Ablaufersteller implementiert aus der Spezifikation die einzelnen Realisierungen Der Ablauf ist bereits ausführbar! Fehlende Realisierungen werden durch geeignete Dialoge simuliert. 3. Realisierungsphase Für jede Spezifikation wurde auch eine Realisierung implementiert Die Sequenz ist voll ablauffähig Wichtig: In jeder der 3 Phasen ist der Ablauf validierbar, speicher- und austauschbar!

11 Specification/Realisation-Konzept II 11 Specification Stage Intermediate Stage Realisation

12 Kontext-Konzept I 12 Mapping-Mechanismus auf Ebene des Ablaufsystems für Umgebungsparameter : Fahrzeugdaten (z.b.: Modell, Verkäufer, Identifikationsnummer, Motorisierung etc.) Daten der Diagnoseapplikation (z.b.: Name, Version, Verwendetes VCI etc.) Benutzerdaten (z.b.: Benutzername, Benutzerrechte, Idle-Time etc.) Umgebungsdaten (z.b.: Standort, Version des Betriebssystems etc.) Realisierung über globale Kontextvariablen Jede Kontextvariable wird zur Laufzeit an eine Identifikationsroutine gebunden, welche den Wert der Variablen ermittelt Die Identifikationsroutinen können anwendungsspezifisch (proprietär) oder OTX-Prozeduren sein Vorteile: Arbeiten wie mit globalen Konstanten Weiterverwendung der vorhandene Struktur mit optionaler Migration durch schrittweises Mapping an OTX-Prozeduren Beim Austausch mit anderen Laufzeitumgebungen muss nur der Mapping-Layer angepasst werden Kontextvariablen können einfach extern simuliert werden

13 Mapping (OTX-Runtime) Kontext-Konzept II 13 OTX Sequence Diagnostic Application VIN Typ: String, Default: MODEL Typ: String, Default: STEERING Typ: String, Default: left MANUFACTORING Typ: Boolean, Default: False GetVIN(); GetModelNumber(); GetSteeringType(); n.a. SERVICE Typ: Boolean, Default: True DEBUG_MODE Typ: Boolean, Default: False n.a. n.a. Context variables used as global constants Internal Routines of the diagnostic application

14 Validity-Konzept 14 Basieren auf dem Kontext-Konzept Zur Anpassung der Abläufe an verschiedene Umgebungsbedingungen zur Laufzeit Es werden global so genannte Validities definiert. Eine Validity ist entweder eine boolesche Kontextvariable oder ein zusammengesetzter logischer Ausdruck, z.b.: aus mehreren Kontextvariablen. Knoten können über die ValidFor-Eigenschaft an eine Validity gebunden werden und werden nur ausgeführt, wenn die Validity TRUE ergibt Ein Action-Knoten kann mehrere Realisierungen enthalten Es können so kontextabhängig Teile einer Sequenz aktiviert oder deaktiviert werden Vorteile Klare Abgrenzung zwischen statischen und dynamischen Entscheidungen Verringerung der Anzahl der Verzweigungen, da implizite Steuerung über Umgebungsdaten und nicht explizit über Verzweigungen Kompakterer, lesbarerer Ablauf, der die eigentliche Testlogik besser sichtbar macht Vermeidung von Redundanzen durch Speicherung häufig verwendeter Validities an einem zentralen Ort Darstellung verschiedener Umgebungsszenarien durch ein und Ausschalten von Validities (Filterung)

15 Validity-Konzept 15 Mit Verzweigung Mit Validities

16 Signatur-Konzept 16 Ähnlich dem Validity-Konzept nur auf Prozedur-Ebene Eine Signatur beschreibt ein Interface für eine Prozedur (Prototyp) Eine Signatur ist wie eine Prozedur ohne Realisierung Eine Signatur besteht aus Namen, Spezifikation und einem Satz von Ein- und Ausgabeparametern 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. 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. Vermeidung von Redundanzen durch Speicherung häufig verwendeter Signaturen an einem zentralen Ort

17 Signatur-Konzept 17 Mit Validities Mit Signaturen ValidFor: isvintagemodel ValidFor: ismodernmodel Das Laufzeitsystem ruft entsprechend der Validity eine der beiden Prozeduren auf

18 Konzepte im Vergleich 18 Mit Verzweigungen Mit Validities Mit Signaturen Normaler Ablauf 11 Aktivitäten 22 Aktivitäten 13 Aktivitäten Vorteile: Vermeidung von Verzweigungen Reduzierung der Darstellung auf die eigentliche Testlogik (11 Aktivitäten) Bessere Wartbarkeit und Langzeitverfügbarkeit Vermeidung von Redundanzen Möglichkeit der verteilten Entwicklung von Testsequenzen

19 Einfache OTX-Sequenz 19 <otx name="odfproject1" package="package1" version="0.9.4" timestamp=" t09:34:08"> <validities> <validity name="validity1"> <realisation xsi:type="booleanliteral" value="true" /> </validity> </validities> <procedures> <procedure name="workflow1"> <realisation> <declarations> <variable name="variable1"> <realisation> <datatype xsi:type="integer" /> </realisation> </variable> </declarations> <flow> <action name="setcontextdataactivity1" id="setcontextdataactivity1"> <specification>umgebungsvariable setzen...</specification> <realisation xsi:type="env:setcontextdata"> <env:identifier xsi:type="stringliteral" value="data1" /> <env:term xsi:type="stringliteral" value="abc" /> </realisation> </action> </flow> </realisation> </procedure> </procedures> </otx>

20 OTX Timeline 20 V V (Sommerrain) V (Aachen) V (Wolfsburg) V 0.9 (Schwabing) V (DIS) V 1.0 (ISO 13209) Einreichung des New Work Item Proposals in die ISO Release of ISO & ISO Core only 02/2012 Release of ISO Libraries Meilenstein Heute

21 Vorteile & Nutzen 21 Wiederverwendbarkeit (Single-Source) Erhöhung der Sicherheit, durch weniger Prozessschritte Einfache und schnelle Verifizierbarkeit Verbesserung der Wartbarkeit Maschinen- und Menschenlesbarkeit (XML Format) Herstellerunabhängigkeit Erweiterbarkeit um anwendungsspezifische Bibliotheken Verfügbarkeit von Tools zur Konfiguration, Dokumentenerstellung, Kode-Erzeugung etc. Generische Erstellung von Diagnoseapplikationen Ziel: Austausch und Archivierung von verifizierten, praxiserprobten Diagnosesequenzen

22 22

23 Generischer Tester 23 Generisch (lat. genus: Art, Gattung, Geschlecht ) = allgemeingültig Ein generischer Tester ist ein universeller Diagnosetester Ziel ist die schnelle und prozesssichere Erzeugung von datengetriebenen Testern ohne Schreiben von Programmcode Ansatz: Generative Programmierung (Automatische Erzeugung von Programmcode) Generierter Diagnosetester Diagnosedaten ODX.NET Binary JAVA Ablauflogik OTX Codegenerator Windows Linux Konfiguration externer I/O s Config Androit Embedded Config

24 Vorteile & Nutzen 24 Deutliche Steigerung der Produktivität Erhöhung der Prozesssicherheit und Stabilität Plattformunabhängigkeit Write Once Run Anywhere Vermeidung Syntax- und Laufzeitfehlern Flexibel für verschiedene Anwendungsszenarien skalierbar Vereinfachtes Änderungsmanagement Aber: Komplexe Datenstrukturen Softwarewerkzeuge müssen die Komplexität der Daten benutzerfreundlich repräsentieren

25 DeviceSignature ScreenSignature Generische Einbindung externer Geräte 25 OTX-Runtime HMI-Device OpenScreen OTX-Activitiy Mapping GenericScreen WPF.NET Java Swing Layout Measurement-Device ExecuteDeviceService OTX-Activitiy Mapping National Instruments Hewlett-Packard Agilent Texas Instruments Configuration

26 Beispiel: HMI-Bibliothek 26 Diagnostic Tester Application DateTime Logging EventHandling I18n StringUtil Math Quantities OTX Core Processing System HMI DiagCom Job/Flash Measure HMI Device (e.g. Keyboard, Mouse, Screen ) Diagnostic Runtime System (e.g. MVCI Server, D-Server, ) Measurement Data Acquisition Other Device (e.g. HIL-API, ASAM GDI)

27 HMI Mensch-Maschine Schnittstelle 27 Die HMI Bibliothek erweitert den OTX-Core um Funktionen für die Interaktion mit dem Anwender über verschiedene Ein- und Ausgabegeräte, z.b.: Monitor, Tastatur, Punkt-Matrix-Display, LEDs etc. Es wird nur die Schnittstelle der Ein-und Ausgabe beschrieben Es werden keine Layout-Informationen abgebildet Da nicht jedes Zielsystem über ein Display verfügt, gibt es für die Ein und Ausgabe zwei Wege: BasicScreens Für elementare Anwendungen: Anzeigen einer Warnung, Anfrage einer einfachen Eingabe, z.b. Ja/Nein Sind immer modal, d.h. der Ablauf wird solange angehalten, bis der Screen bestätigt wird. Müssen durch jedes Ablaufsystem unterstützt werden CustomScreens Definieren eine Schnittstelle zu einer außerhalb von OTX erzeugten Oberfläche Entkopplung der Bildschirmdarstellung von der Testsequenz. Funktion und Layout werden nicht in OTX beschrieben. Können auch nichtmodal sein, d.h. Ablauf läuft weiter, wenn der Screen dargestellt wird.

28 28

29 Open Diagnostic Workflow Open Diagnostic Framework 29

30 30

31 Highlights Der generische Tester Demonstration Praktische Anwendung Datengetriebene Lösung für die gesamte Diagnoseprozesskette Einfach auf nahezu jeder Ebene benutzerspezifisch erweiterbar Konzepte zur Komplexitätsreduzierung Benutzergruppen -Adaption Open Diagnostic Workflow Flexible Bereitstellung: Stand-Alone oder SDK On-the-fly Code-Erzeugung (C#, kein Ablaufinterpreter!) 31 Spezifikation, Realisierung, Validierung, Dokumentation & Test von OTX-Sequenzen Unabhängig vom Diagnoselaufzeitsystem Komplette Neuentwicklung Anbindung und Generierung GUI/HMI Performante Verarbeitung auch sehr großer OTXDatenbanken Natives und direktes Arbeiten auf OTX-Daten (kein Im-/Export!) Was ist OTX?

32 Open Diagnostic Workflow Prinzipieller Aufbau 32 ODF - Open Diagnostic Framework Database-Modul OTX-Designer Forms-Designer * Test-Environment OTX OTX-API Project-Explorer Control-Library Debugger XML-DB Activity-Library Data-Binding Unit-Tests OTX Runtime Environment ODX MVCI-Server + PDU-Simulation Standardized Diagnostic RT-Systems SDX * D-PDU API Legacy RT-Systems Simulation Proprietary Diagnostic RT-Systems VCI - Vehicle Communication Interface ECU s * SDX = Simple Diagnostic Data Exchange Format by emotive to support proprietary Diagnostic Runtime Systems

33 Danke für Ihre Aufmerksamkeit! 33 Sprechen Sie mit uns! Wir helfen Ihnen gern. Besuchen Sie uns in der Fachausstellung! Weitere Informationen finden Sie auf unserer Website unter