2
Diagnoseprozesskette Vergangenheit 3 Systemlieferant Entwicklung Produktion Diagnosesystemlieferant Service Die herkömmliche Diagnoseprozesskette war gekennzeichnet durch einen heterogenen Austausch diagnoserelevanter Informationen
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
ODX, MCD 2 (ISO 22901-1) 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 22900-3) Modular VCI Runtime System (MVCI, ISO 22900) D-PDU API, MCD 1 (ISO 22900-2) Vehicle Communication Interface VCI ECU ECU ECU OTX ODX
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
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
Schnittstellen & Erweiterungen 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)
OTX Timeline 9 V 0.9.4 V 0.9.3 (Sommerrain) V 0.9.2 (Aachen) V 0.9.1 (Wolfsburg) V 0.9 (Schwabing) ISO/DIS 13209 (V 0.9.5) Wichtig: Erst ab ISO/DIS Release (V 0.9.5) kann Datensicherheit gewährleistet werden! 19.12.2008 25.02.2011 13.04.2011 28.06.2011 Einreichung des New Work Item Proposals in die ISO DIS-Ballot (Draft International Standard) DIS-Ballot (Draft International Standard) DIS-Release (Draft International Standard) Core only Libraries only Core only Milestone Heute (10/2011)
Vorteile & Nutzen 10 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
11
Basiskonzepte 12 Basiskonzepte, repräsentieren die Erfahrungen bei Erstellung und Anwendung von Prüfsequenzen. Ziel: Reduzierung und Beherrschung der Komplexität Specification/Realisation-Konzept Prozessmanagement Kontext-Konzept Validity-Konzept Variantenmanagement Signatur-Konzept
Specification/Realisation-Konzept 13 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!
Specification/Realisation-Konzept II 14 Specification Stage Intermediate Stage Realisation
Kontext-Konzept I 15 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
Mapping (OTX-Runtime) Kontext-Konzept II 16 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
Validity-Konzept 17 Basiert auf 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)
Validity-Konzept 18 Mit Verzweigung Mit Validities
Signatur-Konzept 19 Ä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
Signatur-Konzept 20 Mit Validities Mit Signaturen ValidFor: isvintagemodel ValidFor: ismodernmodel Das Laufzeitsystem ruft entsprechend der Validity eine der beiden Prozeduren auf
Konzepte im Vergleich 21 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
22
Open Diagnostic Workflow Übersicht 23 Diagnosedatenbank Bereitstellung eines standardisierten Austauschformats für Diagnosedaten ODX ISO 22901-1 Diagnoseabläufe Bereitstellung eines standardisierten Austauschformats für Diagnoseabläufe OTX ISO 13209 Diagnoselaufzeitsystem Bereitstellung einer standardisierten Programmierschnittstelle zur Kommunikation mit dem Steuergerät MVCI-Server ISO 22900-3
Highlights Basiskonzepte Open Diagnostic Framework Demonstration Datengetriebene Lösung für die gesamte Diagnoseprozesskette Einfach auf nahezu jeder Ebene benutzerspezifisch erweiterbar Benutzergruppen-Adaption Flexible Bereitstellung: Stand-Alone oder SDK Open Diagnostic Workflow On-the-fly OTX-Checker (Validierung) On-the-fly Code-Erzeugung (C#, kein Ablaufinterpreter!) 24 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!) OTX
Open Diagnostic Workflow Prinzipieller Aufbau 25 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
Open Diagnostic Workflow Laufzeitumgebung 26 OTX-Ablaufumgebung Datenverarbeitung OTX XML-DB XQuery OTX-API ODF- Runtime C# Compiler DLL OTX- Runtime Datenbankmodul ODF-Runtime Platzbedarf auf der Festplatte ca. 20 MB ca. 3 MB Datenbereitstellung im OTX-Format Datenbereitstellung im Binär-Format
Open Diagnostic Workflow Standards, Hardware & Systemvoraussetzungen 27 Unterstützte Diagnosestandards: MVCI Server API (ISO 22900-3, ASAM MCD-3D Server) ODX (ISO 22901-1, ASAM MCD-2D) OTX Beta Version (ISO 13209) D-PDU-API (ISO 22900-2) CAN (ISO 11898) K-Line (ISO 9141) UDS (ISO 14229) ISOTP (KWP 2000 on CAN, ISO/DIS 15765-3) KWP 2000 (ISO 14230) Unterstützte Hardware (Vehicle Communication Interface): Bosch MDI DSA MDI-G samtec HSX, HS+, HSlight Vector CANCardXL, CANCaseXL, CANBoardXL Weitere Interfaces mit standardisierter D-PDU-API Schnittstelle Systemvoraussetzungen PC mit Windows XP SP-2 oder höher (32 und 64 Bit).NET Framework 4.0
28
Open Diagnostic Workflow Stand-Alone Anwendung 29
Danke für Ihre Aufmerksamkeit! 30 Sprechen Sie mit uns! Wir helfen Ihnen gern. Besuchen Sie uns in der Fachausstellung! Weitere Informationen finden Sie auf unserer Website unter www.emotive.de