Funktionale API

Die Funktionale API im Sinne einer service-orientierten Architektur erlaubt es, typische Diagnosefunktionen als geschlossene Abläufe vollständig durch die Softing SDE ausführen zu lassen. Dadurch ist eine Verwendung in Remote-Anwendungen unabhängig von der Verbindungsqualität möglich. Die „sprechenden“ Namen ermöglichen es, ohne großen Lernaufwand Diagnose in eigene Anwendungen zu integrieren.

Kurze Entwicklungszeit dank funktionalem API-Zugriff 

Mit Hilfe der reduzierten und daher sehr einfach zu verwendenden Smart Diagnostic API (SDA), lassen sich Diagnosefunktionen äußerst effizient in jegliche Testsysteme integrieren. Die SDA kapselt intelligent mehrere Aufrufe von Diagnosediensten oder ganzen Abläufen in eigene Funktionen und reduziert dadurch die Komplexität des eigentlichen Tests erheblich. Vollumfängliches Wissen über die Diagnoseimplementierung ist nicht mehr notwendig, was lange Einarbeitungszeiten verhindert. Gleichzeitig wird mit der durchgängig identischen Bezeichnung der Diagnosefunktionen die Fehleranfälligkeit stark reduziert. Zusätzlich wird die Wartung des Tests erheblich günstiger, da für neue Steuergeräte oder Varianten der Test nicht geändert werden muss.

Remotefähigkeit durch serviceorientierten Ansatz

Diagnosefunktionen sind bei Verwendung der SDA vollständig in der Softing SDE gekapselt und laufen unabhängig von der Applikation ab. Dies ist Voraussetzung für einen Remote oder Cloud-Betrieb, weil nur dadurch eine Unabhängigkeit von der Netzwerkverbindung gewährleistet ist – in Bezug auf Latenzen bei vielen einzelnen Funktionsaufrufen, aber insbesondere bezüglich der Verfügbarkeit des Netzwerks, die bei länger laufenden Funktionen kaum gewährleistet werden kann. Die Umsetzung der Diagnosefunktionen kann auf unterschiedliche Weise erfolgen, sei es als ODX-Dienst, als OTX-Ablauf, in Java oder als C++-Code direkt in der SDE. Dies ist auch steuergeräte- oder variantenabhängig möglich, sodass jederzeit die größtmögliche Flexibilität gewährleitet ist.    

Automatisiert Diagnoseabläufe und Tests mit OTX (ISO 13209)

OTX nach ISO 13209 ist fester Bestandteil des Softing Diagnose-Grundsystems und der Smart Diagnostic Engine. Mit der Softing SDE als Laufzeitumgebung lassen sich auch komplexe OTX-Abläufe sehr effizient ausführen. Die SDE ist dabei sowohl für komplexe Diagnosen als auch für generische Testfälle in Testsystemen geeignet. Softing-spezifische Erweiterungen vereinfachen daneben die Handhabung von Methoden und die Verwendung von Diagnoseabläufen.
Beim Einsatz in automatisierten Testumgebungen (z.B. Hardware in the Loop – HiL), ist aber nicht immer ein voller Zugriff auf die API notwendig. Hierzu lässt sich die SDE auch per Zugriff über die Kommandozeile effizient und punktgenau ansteuern.

Implementierung

Die genaue Ausgestaltung der Funktion ist in der Regel herstellerspezifisch, in manchen Fällen sogar Steuergeräte- oder Varianten-spezifisch. Daher stehen mehrere Möglichkeiten der Implementierung zur Verfügung. Die größte Implementierungsvarianz liegt in einer Implementierung in C++ oder JAVA, die durch Softing erfolgen muss. In diesem Fall ist der Ablauf in der Softing SDE integriert. Daneben kann auch eine Implementierung in OTX oder als ODX-Dienst erfolgen. Hier kann der Anwender selbst eingreifen.

Über Application Guide Lines (AGL) erfolgt eine Festlegung, wie die Diagnosefunktion umgesetzt ist. Diese Definition kann global erfolgen, aber auch für ein Fahrzeug, ein Steuergerät oder eine Steuergerätevariante überschrieben werden.

Remote

Die Umsetzung von Diagnosefunktionen in der Softing SDE hat nicht nur Effizienzvorteile. Im Remote-Fall kann man die Softing SDE dicht am Fahrzeug halten – in einer TCU, einem Datenlogger, einem VCI – und dadurch die Abhängigkeit von der Qualität der Verbindung fast vollständig entkoppeln: Die Anwendung setz eine Anforderung ab, diese wird durch die Softing SDE völlig autark abgearbeitet, Ergebnisse werden durch die Anwendung abgeholt, wenn die Verbindung ausreichend gut ist.