TESTING NEXT GENERATION
Prüflogik in beliebigen Zielsystemen ausführen und zu gleichen Ergebnissen kommen
NEU OTX Runtime API
Die zweite Generation der OTX-Runtime API ist eine Programmierschnittstelle zur einfachen Ausführung von OTX-Abläufen in eigenen Anwendungen. Die API liegt in den drei Technologien C++, DotNet und Java vor und ist somit innerhalb der meisten existierenden Technologien unter Windows oder Linux einsetzbar. Sie verfügt über umfangreiche Möglichkeiten zur nahtlosen Integration in bestehende Systeme und Infrastrukturen.
Die OTX-Runtime API läuft in vielen tausend produktiven Umgebungen von Automobilherstellern in Entwicklung, Produktion, Kundendienst und innerhalb des Fahrzeugs unter Windows, Linux und in eingebetteten Systemen. Die Anwendungsgebiete der OTX-Runtime API reichen dort von der Steuergeräte-Inbetriebnahme, dem Flashen und Kodieren, der Bauszustandsdokumentation und Prüfstandssteuerung bis hin zur subjektiven Beurteilung in der Produktion. Potentielle Einsatzgebiete in zukünftige Bereichen sind beispielsweise die Service orientierte Diagnose (SOVD) oder das Szenario-basierte Testen im Umfeld des autonomen Fahrens.
Aufbau und Schnittstellen
Um OTX auszuführen, muss die API der OTX-Runtime in eine Anwendung integriert werden. Über die API können OTX-Projekte (PTX-Dateien) geladen, deren Datenstruktur ermittelt (Browsing) und Prozeduren gestartet werden. Die OTX-Runtime API liegt in den drei Technologien C++, DotNet und Java vor und ist somit praktisch innerhalb jeder existierenden Technologie einsetzbar. Beim Starten einer Prozedur wird ein Runtime-Kontext erzeugt. Er ist das Herzstück der Laufzeitumgebung. Dort findet die eigentliche Ausführung von OTX statt. Er und alle darunter liegenden Schichten sind in nativem C++ geschrieben und somit performant und Ressourcen schonend in beliebige Zielarchitekturen z.B. Desktop, Web oder Embedded einsetzbar.
Austauschbarkeit auf allen Ebenen
Für die Diagnose-Kommunikation arbeitet die OTX-Runtime auf dem auch stand-alone verfügbaren DiagManager. Er hat die Aufgabe, alle Diagnose relevanten OTX-Befehle in Befehle eines spezifischen Diagnose-Laufzeitsystems zu übersetzen. Dabei kann er als Server arbeiten, so dass eine parallele Diagnose aus mehreren Prozessen oder Anwendungen möglich ist. Der Server serialisiert die Befehle der Clients und leitet sie an den CommandProcessor weiter. Der CommandProcessor optimiert und zu priorisiert die Diagnosebefehle. Beispielsweise findet im hier die Verwaltung der Diagnosekanäle statt. Der CommandProcessor ist durch den Anwender austauschbar. Der CommandProcessor sendet seine Befehle an das DiagRuntimeSystem. Im DiagRuntimeSystem findet die eigentliche Übersetzung von OTX auf spezifische Methoden eines Diagnose-Laufzeitsystems statt, z.B. nach ISO 22900-3 (MVCI). Auch diese Schicht ist austauschbar. Der Anwender kann hier selbständig eine Anbindung an sein eigenes proprietäres Diagnose-Laufzeitsystem vornehmen.
Die Funktionalität zur Anbindung an andere externe Systeme (z.B. GUI, Prüfstand, Messdatenerfassung) befindet sich nicht innerhalb der OTX-Runtime sondern in einer externen Bibliothek, der so genannten Custom-Implementierung. Hierfür werden an der OTX-Runtime API Schnittstellen bereitgestellt, die der Anwender selbst implementieren kann. EMOTIVE liefert für diese Schnittstellen Standard-Implementierungen aus. Es ist somit möglich, OTX in beliebige Zielsysteme nahtlos zu integrieren und auszuführen. Derselbe OTX-Ablauf kann innerhalb einer Web-Applikation mit einer HTML-Screen Anbindung ausgeführt werden oder embedded im Fahrzeug mit einer Anbindung an einen Screen im Infotainmentsystem.
Technische Daten
Kontaktieren Sie uns für weitere Informationen!