Zeitleiste

• 1970 Erster Einsatz von elektronischen Anzeigen in Traktoren
• 1975 Erste elektronische Regelungen in Traktoren
• 1991 Start der Standardisierung des LBS in Deutschland DIN9684
• 1991 Start der Standardisierung in den USA und Kanada ISO11783
• 1994 Erste geobasierende Funktionalitäten
• 1996 Demonstration der Interoperabilität von LBS-Geräten
• 2001 Entscheidung, den LBS in den ISOBUS zu überführen
• 2001 Gründung der IGI
• 2002 Gründung NAIITF
• 2004 Gründung FTI in Brasilien
• 2008 Gründung AEF als Ablösung für IGI, NAIITF, FTI

ISOBUS Stecker

Mit der Einführung einigte man sich auf einen einheitlichen Stecker für den Anschluss von Anbaugeräten. Dieser stellt nicht nur die Datenleitungen zur Verfügung, sondern auch Anschlüsse über die elektrische Leistung entnommen werden kann. Zusätzlich ist vorgesehen, dass eine Schaltung enthalten ist, die, wenn notwendig, den CANBUS aktiv terminiert. Dies ist notwendig, da der BUS ja sowohl mit als auch ohne Gerät, bzw. im Extremfall auch mit mehreren Anbaugeräten betrieben werden kann. Der Stecker ist für den landwirtschaftlichen Einsatz ausgelegt und verfügt über eine Funktionalität, die ein in der Regel schadenfreies Abreißen ermöglicht, falls z. B. beim Abbau des Anbaugerätes vergessen worden ist, den Stecker zu trennen. Teilweise haben einige Landmaschinenhersteller den Stecker auch für nicht ISOBUS Anwendungen genutzt. Ferner sind für Anwendungen in der Kabine noch andere Steckverbindungen vorgesehen. Eine große Rolle spielt hier die Baureihe DT von der Firma Deutsch. Neben dem InCab Connector (9-poliger Tyco-CPC-Stecker) zum Anschluss von Terminals und AUX-Hardware findet teilweise noch ein Diagnosestecker Verwendung.

Kabel

Die Norm sieht spezifische Kabeleigenschaften vor. So ist zum Beispiel die eigentliche Busverbindung innerhalb der Maschine über vieradrige verdrillte Leitungen in den Farben Grün, Gelb, Schwarz und Rot auszuführen.

Rechner

Alle angeschlossenen Teilnehmer sind eigenständige Rechner. Die Bezeichnung für diese ist ECU (Electronic Control Unit). Je nach Aufgabe wird dieser Name manchmal zur besseren Beschreibung erweitert (z. B. TECU, Implement ECU …). Die Anzahl ist auf 30 begrenzt.

Jobrechner

Der Jobrechner (JR), auch Implement-ECU genannt, sitzt in der Regel auf dem Anbaugerät. Er übernimmt sowohl die Steuerung der Maschine als auch die Anzeige von Daten und die Umsetzung von Bedienereingaben. Aufgrund des Umfangs des Objectpools und vor allem des Netzwerkmanagements sind praktisch alle Jobrechner mindestens 16-Bit-Mikrocontroller. Der C16x von Siemens ist hier sehr weit verbreitet. Bei Geräten mit sehr vielen Sensoren kommen vermehrt auch 32-Bit-Mikrocontroller zum Einsatz, diese sind allerdings auch deutlich teurer als die 16-Bit-Variante. Die Rechner werden in der Regel in C programmiert, einige auch schon in C++. Eine weitere wichtige Eigenschaft der Jobrechner ist die hohe Schutzklasse, die es ermöglicht, die Geräte direkt auf dem Anbaugerät einzusetzen, ohne diese in einen besonders dichten Schaltschrank etc. zu verbauen.

Sind mehr als ein Jobrechner auf dem Anbaugerät, so werden diese zu einem Workingset mit einem Workingsetmaster zusammengefasst. Nur der Master hat die Aufgabe, auf das VT einen Objectpool zu laden.

In der Regel besitzt ein Jobrechner auch noch eine I/O-Schnittstelle. Hier stehen Strom und Spannungseingänge für Sensoren zur Verfügung, bzw. digitale oder auch stromgeregelte Analogausgänge für z. B. Hydraulikventile oder Stellmotoren. Diese Ein- und Ausgänge sind oft diagnosefähig ausgeführt, können also erkennen, ob z. B. ein Kabelbruch oder Kurzschluss vorliegt. Es ist auch geplant, dass der ISOBUS eine Diagnoseschnittstelle bekommt, um eine einfache Fehlersuche bei verschiedenen Geräten mit einem standardisierten Tester durchzuführen.

Problematisch ist, dass bei vielen Realisierungen für jede Benutzersprache (Englisch, Deutsch etc.) ein eigener Objectpool erstellt werden muss. Dies belegt viel Speicherplatz. Es gibt Ansätze, den Objectpool zur Laufzeit anzupassen, also Strings in Englisch und Deutsch zu hinterlegen und je nach Anforderung durch das VT die passenden in den Objectpool einzufügen und hochzuladen. Andere Hersteller setzen fast ausschließlich auf Grafiken. Dies reduziert den Aufwand für Übersetzungen und macht die Bedienung bei geschickter Gestaltung intuitiver.

GPS/GNSS-Empfänger

Ein GPS-Empfänger kann Positionsdaten für Navigations- und Dokumentationszwecke im NMEA 2000-Format bereitstellen. Es ist dafür ein spezielles Transportprotokoll (FPP) vorhanden. Dieses ist aufgrund der relativ hohen Wiederholrate von 20 Hz auf einen geringen Netzwerkoverhead ausgelegt. Die Daten werden dazu auf mehrere CAN-Daten-Rahmen aufgeteilt und über ein Zählbyte logisch miteinander in Zusammenhang gesetzt. Es kann daher sein, dass ein Empfänger einige Nachrichten abwarten muss, bis er eine Position bestimmen kann, da er warten muss, bis das Zählbyte in einem neuen Zyklus wieder zurückgesetzt wird. Dies ist allerdings nur nach einem Systemneustart oder einer Störung der Kommunikation notwendig und tritt demnach vergleichsweise selten auf. Automatische Lenksysteme verwenden oftmals noch ihre eigenen Antennen und Empfänger, da sie für eine höhere Genauigkeit noch Korrekturen durchführen, oder mehrere GPS-Empfänger auf Maschine und Gerät nutzen. Grundsätzlich wäre es aber auch möglich, für eine automatische Lenkung die GPS-Daten über den ISOBUS zu übertragen.

Virtual Terminal

Das Virtual Terminal (VT) oder auch Universal Terminal (UT) genannt, ist die Mensch-Maschine-Schnittstelle des ISOBUS. Im Wesentlichen ist sie ähnlich einem Webbrowser, welche Zugriff auf Daten eines entfernten Rechners gewährt. Es handelt sich dabei um ein Anzeige- und Bediengerät, das mit einem Bildschirm und mehreren Druck- und eventuell Drehknöpfen ausgestattet ist. Es muss mindestens eine Auflösung von 200 × 200 Pixeln und 6 Druckknöpfe besitzen. Für jeden Knopf muss eine Softbuttondarstellungsfläche von mindestens 60 × 32 Pixeln vorhanden sein. Daher werden die Knöpfe in der Regel um die Anzeige herum angeordnet und Teile der Anzeige dienen als Softbuttonbereich. In der Regel sind mehr Druckknöpfe und mindestens ein Drehencoder vorhanden. Teilweise kommen Touchscreens und numerische Eingabefelder zum Einsatz. Die Anzeige kann sowohl in SW als auch in Farbe (16 oder 256 Farben) erfolgen. 2015 sind eine Auflösung von 480 × 480 Pixeln, mehr als 10 Softkeys und Multitouchbedienung Standard. Es gibt verschiedene UT-Versionen, die im ISOBUS definiert sind und jeweils einen größeren Funktionsumfang bieten. Bei der Anmeldung eines neuen Gerätes am UT wird unter den Kommunikationspartnern ausgehandelt, welche Version genutzt werden soll. So ist ein UT mit der Version 4 in der Lage, auch den Pool eines JR, der maximal UT Version 3 unterstützt, anzuzeigen. Andersherum müsste der JR im Zweifel einen weiteren „Not“-Pool bereithalten, der von einem älteren UT unterstützt wird.

Jedes Gerät, das an den Bus angeschlossen wird und eine Benutzerschnittstelle benötigt, meldet sich beim VT an und lädt den sogenannten Objectpool auf das VT. Der Objectpool besteht aus einer oder mehreren Masken. Eine Maske ist mit einer Webseite vergleichbar. Es gibt standardisierte Objekte, wie Eingabefelder, Strings, Bargraphen etc., die Inhalt einer Maske sein können. Die Attribute der einzelnen Objekte können zur Laufzeit durch entsprechende Kontrollbotschaften verändert werden. Es kann also z. B. der Wert eines Outputstrings verändert werden. Auch ist es möglich, den Inhalt eines Outputs mit einer Variablen zu belegen und somit selbst auf einen weiteren Teilpool zu referenzieren, um z. B. über das Nachladen von Teil-Pools eine andere Sprache darstellen zu können.

Grundsätzlich ist es möglich, dass verschiedene Anbaugeräte das VT nutzen. Dazu kann über einen Navigationsknopf zwischen den einzelnen Geräten gewechselt werden. Teilweise können bei entsprechenden Displaygrößen auch mehrere Geräte parallel, oder aber zumindest die wichtigsten Infos als sogenannter Miniview zeitgleich dargestellt werden.

Um auf besondere Ereignisse, z. B. „Spritztank leer“, reagieren zu können, gibt es sogenannte Alarmmasken. Wenn ein Alarmevent ausgelöst wird, erscheint die zugehörige Alarmmaske, bis diese vom Nutzer quittiert wird.

Teilweise ist es etwas problematisch, dass eine Maske nicht auf jedem VT gleich aussieht. Dies liegt daran, dass z. B. die Auflösung unterschiedlich ist oder die Farben falsch gewählt wurden. Auch existieren mittlerweile mehrere Ausbaustufen eines UTs, so dass z. B. nicht alle Terminals VT3 oder höhere Objekte unterstützen.

Ein weiteres Problem ist, dass das VT in der Regel an der rechten Seite der Kabine montiert ist. Bei Aufgaben, bei denen man zur linken Seite herausschauen muss, hat man die Anzeige und Kontrolle der Maschine im Rücken. Teilweise kann dies mit einer Auxiliary control umgangen werden. Das sind Bedienelemente wie ein Joystick oder Schalter, die über einen Incab-Connector an den Bus angeschlossen werden können und somit relativ frei positionierbar sind.

In der Grafik ist eine beispielhafte Kommunikation zwischen einem VT und einer Implement-ECU, hier z. B. eine Feldspritze, dargestellt. Die ECU nutzt das VT als Anzeige und Bedienmodul.

Das VT handhabt nur Objekte. Deren Bedeutung ist irrelevant für das VT. Bei entsprechenden Interaktionen des Nutzers werden diese an die Geräte-ECU weitergegeben. Alle daraus notwendigen Schritte kennt nur diese ECU.

Missverständnisse über die verfügbaren Möglichkeiten können auch durch die parallele Verwendung der Begriffe VT und UT entstehen. Beide bezeichnen die gleiche Funktion. Aber ein UT1 entspricht in seinen Fähigkeiten dem VT2, ein UT2 dem VT3. Gleichzeitig hat das VT4 keine Entsprechung im UT.

AUX-Geräte

Einige Bedienabläufe sind nur schwer über die Softkeys, gerade wenn diese als Element auf einem Touchscreen ausgeführt sind, realisierbar. Um dem Nutzer ein haptisches Feedback liefern zu können, bzw. z. B. eine Bedienung im schwankenden Traktor überhaupt zu ermöglichen, besteht die Möglichkeit sogenannte Auxcontrolls einzusetzen. Hierbei handelt es sich um Bediengeräte wie Joysticks, Schalterboxen oder Drehgeber, die die Eingabewerte als Nachricht auf den ISOBUS legen. Sie nehmen als regulärer Teilnehmer am ISOBUS-Netzwerk teil. Die Verwaltung der AUX-Funktionen erfolgt durch das VT mit der Nummer 1 (Function Instance 0). Die Bedienfunktionen werden von der Geräte-ECU zur Verfügung gestellt. Es wird zwischen AUX-old und AUX-new unterscheiden. Alle beteiligten Geräte müssen die gleiche Variante verwenden. Ein Mix aus AUX-O und AUX-N ist nicht möglich. Bei AUX-new Geräten muss/kann der Nutzer die Tastenbelegung seinen Bedürfnissen nach zuweisen. Bei AUX-old Geräten existiert eine feste Zuweisung im Jobrechner des Anbaugerätes oder es wird eine proprietäre frei Zuweisung durch den Jobrechner des Anbaugerätes unterstützt. In der Regel können heute die Fahrhebel von Traktoren als AUX-new Device genutzt werden. Zum Teil wird hier von den Anbaugeräten eine sinnvolle Vorbelegung der gängigsten Traktorfabrikate bereitgestellt. Eine zugewiesene Belegung kann in der ECU des Arbeitsgerätes gespeichert und bei der nächsten Nutzung wieder geladen werden. Eine erneute Zuweisung ist dann nicht notwendig.

Ein Anschluss des AUX-Device erfolgt in aller Regel mit einem Y-Kabel über den InCab-Stecker.

Traktorsteuergerät

Das Traktorsteuergerät wird auch als Traktor-ECU bezeichnet. Es handelt sich dabei um einen Jobrechner, der auf dem Traktor oder dem Trägerfahrzeug sitzt. In der Regel ist dies ein Rechner der einerseits am ISOBUS, andererseits am CAN-BUS des Traktors angeschlossen ist. Er übernimmt Daten vom Traktor CAN stellt diese Informationen wie Fahrgeschwindigkeit, Zapfwellendrehzahl usw. im ISOBUS in Form von Nachrichten mit der entsprechenden, in der Norm definierten, SPN zur Verfügung. Um eine einfache Möglichkeit für Nachrüstlösungen zu bieten, oder auch Lowcost-Lösungen für Neumaschinen, sind verschiedene Umfänge der Informationen definiert, die die Tractor-ECU sendet. Im einfachsten Fall sind dies z. B. nur Fahrgeschwindigkeit, Zapfwellendrehzahl und Dreipunktposition. Für höhere Level kommen dann noch Informationen wie wahre Fahrgeschwindigkeit, Hydraulikdrücke, Ventilstellungen, ob das Licht eingeschaltet ist und ähnliche Daten hinzu. Die Tractor-ECU stellt also die Funktion einer Bridge zwischen dem ISOBUS und dem Traktorbus dar. Die höchste Ausbaustufe lässt in gewissen Grenzen auch eine Kontrolle des Traktors durch die Implement-Elektronik zu. Diese kann z. B. auf Traktor-Hydraulikventile zugreifen oder sogar auf die Lenkung. So kann z. B. ein GPS-Lenksystem über den ISOBUS auf den traktoreigenen GPS-Empfänger zugreifen, die Positionsdaten zu einem Lenksignal verrechnen und diese dann über den ISOBUS an den Traktor weitergeben. Kritisch ist hier noch, dass gewisse Sicherheitsbestimmungen seitens des Steuergerätes notwendig sind. Ferner ist auch die Haftungsfrage zu klären, wer bei Schäden zahlen muss, die z. B. durch automatisierte Fehlbedingungen entstehen könnten.

Eine weitere Aufgabe der Traktor-ECU ist auch das Powermanagement. Wird die Zündung des Traktors ausgestellt, so sendet die Tractor-ECU an die Implement-ECU eine Nachricht, dass in zwei Sekunden die Stromversorgung ausgestellt wird. Die Implement-ECU kann nun mit einer Nachricht für weitere zwei Sekunden die Stromversorgung verlängern, bis eine neue Warnung durch die Traktor-ECU kommt. Dies lässt sich beliebig lange fortsetzen. Sinnvoll kann dies sein, wenn an dem Gerät z. B. noch elektrisch angetriebene Verriegelungsvorgänge ausgeführt werden, die nicht unterbrochen werden dürfen, oder eventuell nach dem Abschalten des Traktormotors der Druck vom System abgelassen werden muss. Ebenso ermöglicht dies ein sicheres Abspeichern der Daten und Herunterfahren.

Teilweise nutzt die Traktor-ECU auch das VT, um dem Fahrer Statusinformationen des Traktors anzuzeigen. Es verhält sich also teilweise analog zu einer Implement-ECU.

Selbst im Jahr 2016 werden bei weitem nicht alle Schlepper mit einer Tractor ECU ausgeliefert. Hier ist dann oft die Tractor ECU in dem VT als logisches Steuergerät mit implementiert. Die notwendigen Signale vom Schlepper werden über eine standardisierte Signalsteckdose abgegriffen oder aber von nachgerüsteten Sensoren geliefert.

Andere Low-cost-Lösungen verzichten ganz auf die Verbindung zum Traktor. Die allermeisten Geräte benötigen nur die Fahrgeschwindigkeit. Da diese vom Traktor selbst ohnehin nur mit Schlupf verfügbar ist, stellt diese einen großen Fehlerfaktor dar. Um die wahre Geschwindigkeit zu ermitteln kann ein Radargerät genutzt werden. Da in der Regel auch ein GNSS-Empfänger angeschlossen ist kann stattdessen auf die dort ermittelte wahre Geschwindigkeit zurückgegriffen werden. In diesem Fall wird nur diese Funktion der TECU emuliert. Weitere Daten wie Zapfwellendrehzahl stehen dann nicht zur Verfügung. Andererseits werden diese meist am Gerät selbst überwacht.

Taskcontroller

Der Taskcontroller (TC) stellt die Schnittstelle zwischen dem Farm Management System und der Gerätesteuerung dar.

Fileserver

Der Fileserver (FS) stellt allen an den ISOBUS angebundenen Geräten Speicherplatz für Konfigurations- oder Informationsdaten zur Verfügung. Es werden rudimentäre Befehle eines Dateisystems zur Verfügung gestellt. Dies war einmal auf einem internen Speicher möglich, aber auch für die Synchronisation mit der Ackerschlagkartei auf dem Hof-PC über einen portablen Speicher. Während die Speicherung Anfangs noch auf Disketten vollzogen wurde und später oftmals auf CF-Cards, so ist heute ein klarer Trend Richtung USB-Sticks oder gar zu Funknetzwerken basierend auf GSM oder WLAN zu beobachten.

Transportprotokolle

Eine Besonderheit des ISOBUS ist, dass für einen Feldbus ungewöhnlich große Datenmengen durchaus im MB-Bereich zwischen den einzelnen Teilnehmer transportiert werden müssen. Der CANBUS ist erst einmal nur für Datenmengen bis 8 Byte geeignet. Für größere Datenmengen müssen diese in mit einer CAN-Botschaft transportierbare Teile aufgeteilt werden. Typische Daten, die übertragen werden, sind z. B. ein Objectpool für das VT, Auftragsdaten für den TM oder aber auch GPS-Positionsdaten.

Insgesamt werden hierfür 4 verschiedene Transportprotokolle genutzt:

AEF-Test

Bei dem AEF-Test handelt es sich um eine automatisierten Abfolge von Tests, deren Ziel es ist, sicherzustellen, dass die in der ISO 11783 spezifizierten Eigenschaften eingehalten werden. Es wird sowohl die Hardware als auch die Funktion der Software getestet. Ziel ist, dass zwei getestete Komponenten, die somit Normkonform sind, problemlos zusammenarbeiten. Die Testzusammenstellung unterscheidet sich zum Teil abhängig vom Typ des zu testenden Gerätes. So wird zum Beispiel bei einem Jobrechner die Funktionalität des Sectioncontrol Servers getestet, während bei einem Terminal mit SC Funktion die Client Funktionalität getestet wird. Die Umfänge der Tests werden in Arbeitsgruppen der AEF festgelegt und dann sukzessive in den Testumfang eingepflegt. Die Tests können direkt vom Hersteller durchgeführt werden. Für einen Eintrag in die AEF-Datenbank und Erlaubnis einen entsprechenden Aufkleber nutzen zu dürfen, muss der Test allerdings von einem zertifizierten Prüflabor durchgeführt werden. Bei jeder neuen Softwareversion die von einem Gerät veröffentlicht wird, muss der Test wiederholt werden. Basierend auf den Testergebnissen kann mit einer Datenbank vor dem Kauf eines Gerätes oder Traktors die Kompatibilität vom Landmaschinenhandel bzw. vom Käufer vorab geprüft werden. Hinzu kommt, dass die AEF bei Problemen mit Geräten verschiedener Hersteller eine Vermittlerrolle einnimmt und den Kontakt zwischen den Beteiligten herstellt. Dazu kann auf der AEF Webseite ein Ticket erstellt werden, worauf die beteiligten Hersteller innerhalb einer vereinbarten Zeit das Problem analysieren müssen und wenn möglich lösen.

Plugfest

Ein Plugfest ist ein Treffen von ISOBUS-Entwicklern, bei dem die Kompatibilität der einzelnen Geräte untereinander getestet wird. Die einzelnen Entwickler der Firmen bringen ihre Jobrechner und VTs mit und schauen, ob Anzeige und Funktion korrekt sind. Die Plugfeste werden regelmäßig von der AEF veranstaltet. Es gibt aber auch in anderen europäischen Ländern, Amerika, Japan und Südamerika Plugfeste. Sie finden meist in Verbindung mit einer Sitzung der Arbeitsgruppe für die Norm, bzw. eine AEF Arbeitsgruppe statt. Sie sind wichtig, da zwar ein Simulator für die verschiedenen VTs existiert, dieser aber nie alle Eigenheiten eines VTs abbilden kann. Es ist ein wesentlich größerer Aufwand, den Objectpool so zu gestalten, dass er kompatibel zu möglichst vielen VTs ist, als die eigentliche Gerätesteuerung auf der ECU zu implementieren. Oft werden Object Pools auch für ein, oft herstellereigenes, VT optimiert und nur eine grundlegende Kompatibilität zu den anderen VTs gewahrt. Hersteller von VTs nutzen das Plugfest auch, um Bugs in ihren VTs aufzuspüren. Die Teilnahme an einem Plugfest ist für kommerzielle Anwender in der Regel kostenpflichtig. Teilweise finden Vorträge oder Firmenpräsentationen zu Aspekten des ISOBUS statt. In der Regel wird jedes Jahr jeweils ein Plugfest in Europa und eines in den USA an oftmals wechselnden Orten veranstaltet. Es sind bis zu 250 Teilnehmer von über 80 Firmen anwesend.