Fahrzeugdiagnose – zum gewollten Muss (Teil 1) - Softing ...

42lAUTOMOTIVE 7-8.2011l ENGINEERING TOOLSOTX – das Austauschformatfür DiagnoseabläufeDer Standard beschreibt ein Austauschformat für Dia gnose-Testsequenzen. Auch hier waren – ähnlich wie bei ODX – dieMaschinenlesbarkeit und Langzeitverfügbarkeit die zentralenAnforderungen. Die Idee hinter dem Standard ist, eineMöglichkeit zu schaffen, bereits in der Spezifikationsphasegrundlegende Abläufe zwischen Testssystem und Steuergerätformal zu beschreiben. Im Prozess können dieseAbläufe weiterverwendet und spezialisiert werden, manmuss also nicht wieder bei Null anfangen und einen Grundablaufaus einer Papierspezifikation abschreiben. Durch dieMaschinenlesbarkeit wird darüber hinaus eine graphischeDarstellung der Abläufe z. B. als Flussdiagramme unterstützt,die den Ingenieuren in Entwicklung, Verifikation, Produktionund Service eine allgemeingültige Basis für ihreDiskussionen bietet. Der Standard OTX wird in mehrereBereiche unterteilt. Der Kern (Core) enthält eine Programmiersprachemit den typischen Elementen Variablen, Ausdrücken/Anweisungenund Operationen (Schleifen, Verzweigungen,Vergleiche,…). Er ist nicht diagnosebezogenund kann grundsätzlich für unterschiedliche Aufgaben angewendetwerden. Standardisierte Bibliotheken stehen fürspezielle Aufgaben zur Verfügung. Neben der Diagnosekommunikation(Anbindung an den D-Server) gehören dazuinsbesondere Stringoperationen, Größenhandling, Darstellungsfunktionen(HMI) und die Internationalisierung, um dieAusgaben von Abläufen für verschiedene Märkte in verschiedenenSprachen anbieten zu können. Die standardisiertenBibliotheken nutzen einen allgemeinen Erweiterungsmechanismus.Dieser kann auch für nicht-standardisierteErweiterungen verwendet werden, wodurch in denAblauf beliebige Testsysteme integrierbar sind. TypischeBeispiele sind HiL-System, Simulationen oder Messtechnik.OTX unterstützt den Entwick lungsprozess durch verschiedeneMechanismen. Zunächst ermöglicht es für frühe Prozessphaseneine reine Spezifikationssicht. Dabei wird dieIdee des Ablaufs beschrieben, ohne schon eine konkreteImplementierung des Ablaufs zu hinterlegen. Es kann somitbeispielsweise ohne echte ODX-Datei, in der dann reale Diagnosedienstebeschrieben sind, schon die Kommunikationmit einem Steuergerät skizziert werden. Dabei entstehtkeine ablauffähige OTX-Sequenz. Dies wird dann später inder Implementierung der Sequenz nachgeholt. Um auch dieVariantenvielfalt ähnlich wie in ODX zu unterstützen, ohneeine Sequenz jedes Mal vollständig neu freigeben zu müssen,wurden ebenfalls spezielle Mechanismen realisiert.Im Unterschied zu ODX existiert für OTX kein standardisiertesAPI für eine Ablaufmaschine. Als Austauschformat stehtes dem Toolhersteller frei, das Formatin einem Interpreter zu verarbeiten,es in ein Maschinenformatzu kompilieren oder es in bereitsexistierende Testsysteme zu importierenund dort weiter zu verarbeiten.Bild 3: DTS-Monaco von Softing ist ein Beispiel für einen Entwicklungstester. In Abhängigkeitvom verwendeten Interface können grundsätzlich beliebige Protokolle unterstütztwerden, solange ein Interface mit D-PDU API und entsprechende ODX-Daten existieren.Entwicklungstester – einBeispielDTS-Monaco ist ein Beispiel füreinen Entwicklungstester. Esbasiert auf den Standards D-PDUAPI, ODX, MCD-3D und OTX undbeherrscht damit die relevantenStandards (Bild 3). DTS-Monacobesteht aus einigen wenigenHauptkomponenten und kannanwendungsspezifisch erweitertwerden: Das Framework, die HMIcontrolsund die Run-times für die© automotive Standards OTX und ODX. ODX werdendurch den D-Server DTS-COSbearbeitet. Er stellt das standardisierte API entsprechendASAM MCD-3D zur Verfügung, bietet darüber hinaus abernoch einige Erweiterungen, die den Einsatz in Testautomatisierungenvereinfachen, und im Entwicklungstester überden Standard hinausgehende Funktionalitäten ermöglichen.Für OTX wurde ein Laufzeitinterpreter integriert.Das Framework stellt die Basisfunktionalitäten zur Verfügung,die für die Diagnose notwendig sind. Neben der Anbindungan die Laufzeitsysteme ist das vor allem die Werkzeugkonfiguration,die abgespeichert und wieder geladenwerden kann. Auch die Rollenverwaltung ist im Frameworkintegriert. Monaco unterstützt die Rollen „Adminstrator“und „Anwender“. Der Administrator kann Konfigurationenerstellen, abspeichern und sie dem Anwender zur Verfügungstellen. Dies betrifft sowohl Oberflächenkonfigurationen alsauch OTX-Abläufe. Diese können durch den Administratorim Tool erstellt und angepasst werden. Der Anwender kanndiese Vorkonfigurationen lediglich ins Tool laden und verwenden.Änderungen sind nur im geringen Umfang möglich.Dadurch ist sichergestellt, dass jeder Anwender nur dieFunktionen am Fahrzeug verwendet, für die er auch ausgebildetist. Innerhalb des Frameworks laufen als Komponentendie HMIcontrols. HMIcontrols übersetzen die Kommuni-