Einheitlicher Diagnosezugang für den Fall der Fälle
Neben der ständigen Verfeinerung und Erweiterung der Testfälle des Konformitätstests im Rahmen der Standardisierungsarbeiten wurde mit dem Teil 12 des Norm-Entwurfs ISO 1178 [4] eine gemeinsame Diagnoseschnittstelle geschaffen. Sie basiert auf der SAEJ1939-73-Diagnose [5]. Teil 12 der ISO-Norm definiert im bereits veröffentlichten Teil, der Basisdiagnose, einen offenen Diagnosezugang. Dieser stellt grundlegende Funktionen zur Verfügung und soll eine Systemübersicht ermöglichen. Dazu gehört die eindeutige Identifikation der Steuergeräte am Bus sowie Informationen zu Software-Version, Herstellerteilenummer und zu durchgeführten Konformitätstests. Jedes Steuergerät kann aktuelle Fehler berichten, und nach Aufforderung durch das Diagnosewerkzeug auch zurückliegende Fehler. Diese Informationen sollen ein schnelles und sicheres Einkreisen der Ursachen ermöglichen. Das ist besonders dann von Vorteil, wenn das Netzwerk aus Komponenten verschiedener Hersteller besteht. So kann z.B. der Service-Techniker eines Traktorherstellers mit seinem ISO-11783-12-kompatiblen Diagnosewerkzeug auch Probleme feststellen, die im Zusammenhang mit einem Anbaugerät eines anderen Herstellers auftreten. Das Problem lässt sich damit nicht zwangläufig beheben, aber eine klare Identifikation der Ursache ist möglich. Liegt die Ursache beim Anbaugerät, kann der fälschlicherweise gerufene Service-Techniker des Traktorherstellers somit wertvolle Informationen wie Fehler-Codes oder Teilenummern der betroffenen Komponenten ermitteln und so den Service-Techniker des Anbaugeräteherstellers vorab informieren. Dies reduziert die Ausfallzeiten auf ein Minimum und führt so beim Kunden zu einer höheren Akzeptanz von Arbeitsmaschinen mit Isobus.
Aktuelle Bestrebungen zur Erweiterung des Teils 12 des Norm-Entwurfs ISO 11783 gehen dahin, dass es ein standardisiertes Beschreibungsformat für die Diagnose gibt. Damit kann jeder Hersteller individuell für jedes Steuergerät den Diagnoseumfang beschreiben. Eine darauf vorbereitete Diagnoseanwendung kann mit Hilfe dieser Beschreibung unabhängig vom Steuergerätehersteller das Steuergerät diagnostizieren. Die Diagnose-Beschreibungsdatei wird vom Steuergerät selbst oder über das Internet heruntergeladen. Hersteller mit eigenem, firmenspezifischem Diagnosewerkzeug integrieren so die ISO-11783-Diagnose in ihr bestehendes und eingeführtes Werkzeug. Hersteller ohne eigene spezialisierte Werkzeuge können künftig standardisierte Diagnosewerkzeuge benutzen. Der praktische Nutzen liegt unter anderem darin, dass ein Service-Techniker mit einem Werkzeug eine systemweite Diagnosemöglichkeit hat. Damit lassen sich die wirklichen Ursachen effizient und sicher lokalisieren und bestenfalls auch gleich beseitigen.
Automatisierte Tests während der Entwicklungsphase
Die Einführung eines einheitlichen Diagnosezugangs hilft, ein Problem vor Ort schnell zu erkennen und das defekte Teil eventuell auszutauschen. Im Falle einer Inkompatibilität sieht das jedoch meist anders aus: Ein Tausch der Elektronik hilft nicht weiter, da damit die Ursache des Problems nicht beseitigt wird. In einem solchen Fall wird eine korrigierte Steuergeräte-Software benötigt. Diese zu erstellen und zu testen, erfordert jedoch Zeit. Zudem ist die Verteilung der Software häufig kostspielig, da teilweise bereits ausgelieferte Geräte zurückgeholt werden müssen. Solchen Kompatibilitätsproblemen kann man durch geeignete Maßnahmen im Vorfeld begegnen.
Eine Möglichkeit ist der Konformitätstest, der aber den Nachteil hat, dass die Anwendung selbst nicht Teil des Tests ist. Der Fokus beim Konformitätstest liegt auf der Prüfung der Konformität zum Standard. Zudem ist die Anwendung des Konformitätstests während der Entwicklung aufwendig oder nicht möglich, da nicht immer am Anfang der Entwicklung von einer hundertprozentigen Kompatibilität ausgegangen werden kann. Oftmals möchte man nur punktuell einen einzelnen Aspekt prüfen, z.B. das Transportprotokoll. Solche, die Entwicklung begleitenden Prüfungen werden erfahrungsgemäß sehr häufig wiederholt, haben eine Vielzahl von alternativen Abläufen und müssen flexibel konfigurierbar sein. Daher sollten solche Prüfungen automatisierbar sein. Treten während des Tests Probleme auf, sind umfangreiche Analysemöglichkeiten gefragt.