ISOBUS

• 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 Breakaway Plug (IBBP) Anbaugeräteseitig

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.

z. B. Deutsch HD34-24-91PE und HDB36-24-91SE

Zur Erweiterung zum Anbaugerät. Ohne Anbaugerät endet der ISOBUS im IBBC (ISOBUS BUS Breakaway Connector) und wird dort terminiert. Da eine Geräte ECU in der Regel mehr als 1 m vom IBBC entfernt ist, muss der BUS dorthin verlängert werden. Damit muss aber auch die Terminierung bei der Arbeitsgeräte-ECU erfolgen. Um den Terminator im IBBC zu deaktivieren ist im Gerätestecker Pin 4 mit 5 gebrückt. Sobald das Arbeitsgerät eingesteckt ist, wird so ein Schaltelement im IBBC aktiviert und trennt den Terminator. In der Regel werden alle Anschlüsse benutzt.

• Pin 1 GND
• Pin 2 ECU_GND
• Pin 3 PWR
• Pin 4 ECU_PWR
• Pin 5 TBC_DIS
• Pin 6 TBC_PWR
• Pin 7 TBC_GND
• Pin 8 CAN_H
• Pin 9 CAN_L

Bei selbstfahrenden Maschinen wird oft auf diese Verbindung verzichtet, da ein Wechsel des Arbeitsgerätes nicht notwendig ist. Teilweise wird statt eines vollen IBBC nur eine einfache und günstigere Steckverbindung ohne interne Schaltung verbaut. Dann ist ein Wechsel des Arbeitsgerätes möglich, jedoch der BUS unvollständig wenn kein Arbeitsgerät angebaut ist.

In der Regel speist der an der Rückseite des Traktors angebrachte IBBC die Signale TBC_PWR und TBC_GND aus ECU_PWR und ECU_GND. Da dies immer nur einmal möglich ist, wird in einer eventuell verbauten Frontsteckdose ein IBBC verwendet der die TBC-Schaltung nicht selbst versorgt.

z. B. Deutsch DT04-04PE und Deutsch DT06-04SE

in der Regel ist dieser Stecker zumindest an der Rückseite des IBBC (IBRC ISOBUS – Breakaway Rear Connector) zu finden. Alle Anschlüsse müssen verwendet werden.

• Pin 1 TBC_PWR

• Pin 2 CAN_H
• Pin 3 TBC_GND
• Pin 4 CAN_L

z. B. Deutsch HD10-9-1939PE (traktorseitig) und HD16-9-1939SE (zum Diagnosetool)

Für die reine ISOBUS Diagnose reichen die Anschlüsse H und J aus. Einige Maschinen verwenden auch weitere Pins, z. B. Stromversorgung über A und B.

• Pin A nicht belegt
• Pin B nicht belegt
• Pin C CAN2_H_Traktorbus
• Pin D CAN2_L_Traktorbus
• Pin E nicht belegt
• Pin F nicht belegt
• Pin G nicht belegt
• Pin H CAN1_H_ISOBUS
• Pin J CAN1_L_ISOBUS

Dieser Stecker wird zum Anschluss von Terminatoren außerhalb von Steuergeräten verwendet. Je nach Aufbau des ISOBUS werden Pin A und C nicht verwendet, wenn doch, dann meist wenn kein IBBC angeschlossen ist. In dem Fall wird an einem Terminator die ECU Versorgung für die Speisung des TBC genutzt.

z. B. 6 poliger MetriPak 150 Stecker

• Pin A ECU_PWR
• Pin B TBC_PWR
• Pin C ECU_GND
• Pin D TBC_RTN
• Pin E CAN_H
• Pin F CAN_L

Hier werden Terminals und Eingabegeräte angeschlossen. Bei der Belegung gibt es verschiedene Varianten.

inCab als einfacher Seitenzweig

Manche stellen nur eine Verbindung als Seitenzweig. Hier ist die maximale Länge bis zum angeschlossenen Gerät auf 1 m begrenzt.

inCab als offener ISOBUS, benötigt einen Loop-Stecker

Andere stellen einen offenen ISOBUS dar. Dann benötigt man einen Loop-Stecker der die beiden Enden der BUS-Leitungen wieder verbindet. Fehlt dieser Stecker, dann ist der Bus hier unterbrochen.

Vollwertige inCab, kann vom angeschlossenen Gerät umgeschaltet werden, benötigt keinen Loop-Stecker

Mittlerweile werden aber viele inCab-Stecker komplett ausgestattet und sind im Neutralzustand geschlossen. Dies entspricht dem ersten hier genannten Fall. Wird ein Gerät angeschlossen, darf dies nur 1 m entfernt sein. Braucht ein Gerät eine längere Zuleitung, dann kann im Stecker ECU_PWR auf Pin 1 gelegt werden. Dies öffnet den BUS, das Anschlusskabel kann diesen zum Gerät und an der anderen Seite zurück führen. Ein Loop-Stecker wird nicht mehr benötigt, da der BUS nur geöffnet ist, wenn ein Gerät angeschlossen ist.

z. B. Tyco/AMP 206705-1 und 206708-01

• Pin 1 – (geräteseitig auf Pin 7 gebrückt)
• Pin 2 CAN_L in
• Pin 3 CAN_L out
• Pin 4 CAN_H in
• Pin 5 CAN_H out
• Pin 6 TBC_PWR
• Pin 7 ECU_PWR
• Pin 8 TBC_GND
• Pin 9 ECU_GND

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.

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.

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.

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.

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.[1]

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.[1]

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.

Kommunikation eines VTs mit einer Implement ECU

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.

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.

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.[2]

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.

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

Im einfachsten Fall dokumentiert er als TC-BAS die ausgeführte Arbeit.

Als TC-GEO kann er Auftragsdaten zum Arbeitsgerät übermitteln. Hier werden alle Daten geführt die ortsspezifisch sind. Dazu gehören Karten wo bereits gearbeitet wurde, wie viel ausgebracht werden sollte, was tatsächlich ausgebracht wurde ebenso, wie Feldgrenzen und Leitspuren.

Geplant ist, dass er sogar die Steuerung des Traktors übernimmt. Zum Beispiel kann er die Ausbringmenge von Pflanzenschutzmitteln abhängig von der Position festlegen. Dazu besitzt ein ISOBUS-fähiges Gerät eine Beschreibungsdatei, in der z. B. steht, dass die Feldspritze 18 m Arbeitsbreite und 3 Teilbreiten hat und zwischen 100 und 1000 l/min ausbringen kann. Mit dieser Datei wird mit Hilfe einer Ackerschlagkartei, Positionsdaten und eventuell vorhandenen teilschlagspezifischen Daten zum Schädlingsdruck des zu bearbeitenden Feldes ein Arbeitsauftrag erstellt. Dieser wird in digitaler Form an den Taskcontroller auf dem Schlepper übermittelt. Steht nun der Fahrer mit der Spritze auf dem Feld, kann der Taskcontroller nach Freigabe durch den Fahrer den Auftrag abarbeiten. Je nachdem, wo der Fahrer fährt, wird den Daten entsprechend mehr oder weniger Pflanzenschutzmittel ausgebracht. Gleichzeitig werden die Ausbringmengen und Positionen für die Qualitätssicherung und Dokumentation gespeichert und später in die Ackerschlagkartei eingepflegt. Diese, auch Variable Rate Control genannte Funktion, kann auch für mehrere Produkte, die gleichzeitig ausgebracht werden, genutzt werden. Also kann z. B. Die Ausbringmenge von Saatgut, Unterfußdüngung und Mikrogranulat zeitgleich auf Basis verschiedener Sollwertkarten positionsabhängig angepasst werden.[3]

Dazu muss die Implement-ECU dem Task-Conroller nur die Gerätebeschreibung mit den entsprechenden Regelkanälen übermitteln. Für verschiedene Ausbringtechniken werden über sogenannte DDI in der Auftragsdatei unterschiedliche Referenzen verwendet um z. B. feste und flüssige Applikation zu unterscheiden. Die verwendeten Einheiten sind definiert, um Konversationsprobleme wie t/ha statt kg/ha zu vermeiden.[4]

Die Aufträge werden als XML Dateien übergeben. Als Zugriffspunkt für den Taskcontroller und beim Rücklesen für die Ackerschlagkartei dient die Datei „TASKDATA.XML“. Diese kann auf weitere XML-Dateien und Applikationskarten in zwei verschiedenen Binärformaten verweisen. Applikationskarten können direkt in der XML-Datei oder diesen binären Grid-daten zur Verfügung gestellt werden. Beim Gridtyp 1 werden die Applikationsmengen in der XML-Datei definiert und in der Binärdatei nur über ein einzelnes Byte referenziert. Beim Gridtyp 2 stehen 4 Byte für einen realen Applikationswert zur Verfügung. Eine Referenz in der XML ist dann nur für zusätzliche Angaben wie Applikationsmenge außerhalb des Feldes oder bei Verlust der Position notwendig. Weiterhin kann eine Applikationskarte auch in Form von Polygonen innerhalb der XML-Datei erfolgen.

Kann das Anbaugerät Teilbreiten seiner Arbeitsbreite schalten, z. B. Düsenabschnitte an einer Feldspritze oder Wurfweite bei einem Kunstdüngerstreuer, kann deren Ansteuerung abhängig von Position und schon bearbeiteter Fläche automatisiert werden. So wird bei einer Feldspritze die schon behandelte Fläche aufgezeichnet und bei erneuter Überfahrt oder teilweiser Überlappung die entsprechenden Abschnitte der Arbeitsbreite abgestellt. Dies führt zu einer höheren Genauigkeit und merklichen Entlastung des Fahrers und kann daher erhebliche Mengen an Dünger bzw. Pflanzenschutzmittel einsparen. Zur Realisierung der Funktion lädt der JR eine Maschinenbeschreibung auf das Terminal, die dort vom TC/SC gelesen wird. Abhängig von den verfügbaren Teilbreiten und Einstellungen zu Überlappungsgrad und Verzugszeiten kann nun das Terminal Steuerbefehle für die Teilbreiten basierend auf der aktuellen Position generieren. Diese Funktionalität wird ebenfalls vom Task-Controller als TC-SC zur Verfügung gestellt.

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.

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.[5]

Insgesamt werden hierfür 4 verschiedene Transportprotokolle genutzt:

Connection Mode Data Transfer ist ein aus dem J1939 übernommenes Protokoll zur P2P Kommunikation zwischen Steuergeräten. Es können je Session maximal 1785 Bytes übertragen werden. Das Protokoll bietet Möglichkeiten, bestimmte Teile der Datenmenge erneut zu senden oder eine Pause bei der Übertragung einzulegen.

Die Broadcast Announce Message ist das globale Äquivalent zum CMDT, allerdings prinzipbedingt ohne dessen Steuermöglichkeiten.

Das Extended Transfer Protokoll ist eine ISOBUS-spezifische Erweiterung des CMDT, um mit einem Zeigerkonzept Datenmengen bis zu 117.440,512 kB übertragen zu können. Dies ist insbesondere bei graphisch aufwendig gestalteten Objectpools von Nutzen. Die Definition findet im PART 3 (ab Version 2014, vorher Part 6) der ISO 11783 statt.

Zum schnellen zyklischen Versenden von Daten, in der Regel GPS-Daten wurde aus der NMEA 2000 das Fast Packet Protokoll übernommen. Es besitzt im Gegensatz zu den anderen Transportprotokollen einen sehr geringen Overhead und sorgt so für eine möglichst geringe Belastung des Busses.

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.

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.