ISOBUS

ISOBUS steht im Zusammenhang mit neueren Konzepten für die Land-, Forst- und Kommunalwirtschaft. Ziele sind Precision Farming und „gläserne Produktion“.

Um die notwendigen Dosierungen für Dünger und Pflanzenschutzmittel zu bestimmen, soll berücksichtigt werden, welche Bedingungen auf dem jeweiligen Feldstück vorgefunden werden. Beispielsweise soll auf einem stärker verunkrauteten Acker mehr Pflanzenschutzmittel verteilt werden als auf anderen (siehe Precision Farming). Es soll auch aufgezeichnet werden, welche Maßnahmen es bei der Bearbeitung der einzelnen Äcker gegeben hat, sodass nachvollzogen werden kann, unter welchen Bedingungen die Pflanzen gewachsen sind (gläserne Produktion). Diese modernen Formen der Landtechnik setzen voraus, dass Geräte eingesetzt werden, die laufend Daten untereinander austauschen können. ISOBUS ist mittlerweile der weltweit gängige Standard für diesen Austausch und hat diverse herstellerspezifische Lösungen und seinen Vorläufer LBS abgelöst.

Man strebt außerdem danach, Arbeitsvorgänge in der Landwirtschaft zu automatisieren. Dabei sollen die Geräte auf dem Acker ihre Arbeit verrichten, ohne dass menschliche Eingriffe nötig sind. Solch ein roboterartiges Verhalten wird es nur geben, wenn vorher programmiert werden kann, welche Maßnahmen jeweils vollzogen werden sollen. Auch dies setzt eine reibungslose Kommunikation der Geräte untereinander voraus.

Durch den Einsatz von ISOBUS-fähigen Geräten können Landwirte eine bessere Übersichtlichkeit auf dem Traktor gewinnen. Schon seit längerem sind Anbaugeräte im Einsatz, die vom Traktor her über ein Terminal gesteuert werden. Bisher jedoch gab es für jedes Gerät ein separates Terminal. Mit ISOBUS ist es möglich, Anbaugeräte verschiedener Art (und auch verschiedener Hersteller) über dasselbe Terminal zu steuern.

Mittlerweile können Landwirte am PC auf dem Hof auch georeferenziert festlegen, wie viel Dünger und Pflanzenschutzmittel ausgebracht werden sollen. Diese Applikationskarten oder Dosisvorgaben werden dann auf ein Traktorsteuergerät übertragen und von dort an die Anbaugeräte weitergegeben. Ebenso können Sensoren auf den Anbaugeräten Daten über Bodenbeschaffenheit, Unkrautmengen und anderes ermitteln und diese Daten an das Traktorsteuergerät weitergeben, sodass sie dort georeferenziert zwischengespeichert und auf den Hof-PC oder in die Cloud übertragen werden.

Das Landwirtschaftliche BUS-System wurde an der TU München unter der Leitung von Hermann Auernhammer entwickelt.

Man orientierte sich an dem OSI-Referenzmodell. Es mussten allerdings nur die Schichten 1, 2 und 7 berücksichtigt werden. Schon früh fiel die Entscheidung für den CAN-Bus. Dadurch ist ein großer Teil der Schichten 1 und 2 abgedeckt.

Obwohl das LBS durch das DIN genormt wurde (DIN 9684), konnte es sich nicht durchsetzen. Es gab bei den Herstellern von Landmaschinen lange Zeit eine große Skepsis bei der Frage, ob man sich auf gemeinsame Standards würde einigen können. Gleichzeitig zeichnete es sich auch ab, dass durch die Wahl eines CAN-Busses mit einem 11-Bit Identifier und dem damit im Gegensatz zu einem 29-Bit-Identifier deutlich geringeren Adressraum, hier weniger auf die Teilnehmer als auf die mögliche Anzahl verschiedener PGNs (Parameter Group Number) bezogen, und einer Datenrate von 125 kBit/s ein wenig ausbaufähiges System geschaffen worden war.

Allerdings gab es schon zu der Zeit für Forschungszwecke weit automatisierte Anwendungen, die von der Funktion weiter waren als alles, was bis etwa Mitte 2008 kommerziell verfügbar war.

Trotz dieser Rückschläge blieb das Grundproblem bestehen. Auch war hierfür bei den Landmaschinenherstellern mittlerweile erkannt worden, dass ein Bussystem unumgänglich sein würde. Unter diesen Voraussetzungen kam es zu einem internationalen Zusammenschluss. Viele Grundideen des LBS wurden beibehalten. Allerdings wurde das Konzept leistungsfähiger und ausbaufähiger gestaltet. Aus dem LBS entwickelte sich der ISOBUS. Dieser wird mittlerweile von allen wichtigen Landmaschinenherstellern, sowohl den Herstellern von Traktoren als auch den Herstellern von Anbaugeräten, unterstützt. Die Norm wird von der AEM (NAIITF) in Nordamerika und von dem VDMA in Deutschland betreut. Eine Taskforce für Südamerika wird angestrebt.

WG steht für die einzelnen Working Groups (dt. Arbeitsgruppen) die einzelne Aspekte der Norm ausarbeiten und neue Abschnitte erarbeiten. Es finden von beiden Verbänden regelmäßig Treffen statt. Über das Steering Committee findet auch ein Austausch zwischen den beiden Gruppen statt. Mittlerweile ist die Entwicklung eindeutig von den Hochschulen in die Industrie übergegangen. Im Rahmen des Sterbens der agrartechnischen Hochschulen wird dieses Thema nur noch von sehr wenigen Universitäten und Fachhochschulen behandelt oder aktiv weiterentwickelt.

• 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

Die AEF (Agricultural Industry Electronics Foundation) ist ein Zusammenschluss von Unternehmen, die sich im Bereich Elektrik und Elektronik in der Landwirtschaft engagieren. Einer der Arbeitsschwerpunkte liegt in der Weiterentwicklung des ISOBUS. Neben Administrativen Aufgaben zur Koordination und Abstimmung mit den Normungsgruppen existieren auch zahlreiche Arbeitsgruppen, die sich z. B. um High Speed ISOBUS, Wireless Infield Communication, Kompatibilitätstests, TIM und Schnittstellen zu FMIS kümmern. Hierbei sind die Arbeitsgruppen herstellerübergreifend international besetzt. Ziel ist es abgeschlossene Projekte in die Norm zu überführen. Ein weiteres Tätigkeitsfeld ist durch Marketing Aktivitäten die Verbreitung des ISOBUS zu fördern.

Die AEF veröffentlicht in der AEF-ISOBUS-DATABASE die Kompatibilität der getesteten Geräte.

Bei einem voll ausgebauten ISOBUS-System kommen eine Reihe von Geräten zum Einsatz, die alle wie kleine Computer funktionieren. Teilweise werden Geräte wie das Virtual Terminal, Task Controller und Fileserver in einem Gerät und sogar auf einer CPU zusammengefasst. Auch ist es nicht ungewöhnlich, dass mehrere logische Anbaugerätesteuerungen auf einer CPU zusammengefasst werden, wie z. B. bei einer Feldspritze, bei der jede Teilbreite eine eigene logische ECU hat.

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.

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

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.

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.

Die Norm sieht eine ganze Reihe an unterschiedlichen Funktionalitäten vor. Diese können zum Teil innerhalb derselben ECU realisiert sein. So enthalten Terminals in der Regel ein „Virtual Terminal“ und einen „Task Controller“.

Um mehrere Einheiten der gleichen Funktionalität zu realisieren, muss durch Zuweisung der Function Instance eine eindeutige Zuordnung erfolgen. Zu beachten ist, dass die Function Instance um 1 niedriger ist als die zugeteilte Nummer. Ein VT mit der Function Instance 0 identifiziert sich somit als VT Nummer 1. Da manche Hersteller die Nummer, andere die Function Instance angeben kann es zu Verwirrungen führen. Jede Nummer bzw. Function Instance darf nur einmal vergeben werden. Diese Zuordnung zur Identifikation sollte nicht mit den weiter unten erwähnten Stufen verwechselt werden.

Nicht jeder Hersteller ermöglicht es die Function Instance zu definieren. Andere lassen diese zwar verstellen, aber verklausulieren dies hinter anderen Einträgen (z. B. Zuweisung der AUX Belegung, diese erfolgt immer durch das primäre VT).

Eine neu an den ISOBUS angeschlossene ECU verbindet sich zuerst mit der niedrigsten Nummer. Sie lädt also ihren Object pool auf das VT Nummer 1. Dort kann der Bediener in einer der Masken der ECU die Anweisung geben ihre Masken auf einem anderen VT darzustellen, sofern diese ECU das unterstützt. Beim VT kann dies sogar mitten in der Arbeit erfolgen. Der Bediener kann also Anzeigen von einem Terminal zu einem anderen verschieben. Im Extremfall kann dieses sogar ganz anders ausgelegt sein (Bildschirmgröße, Sprache, Tastenanzahl …). Ein Rücktransfer ist ebenso einfach.

Die meisten dieser Funktionalitäten arbeiten nach einem Server/Client-Verfahren. Als Beispiel sei hier ein Task-Controller genannt, der als Server im Terminal zur Verfügung steht. Die Geräte, die sich dort anmelden, arbeiten dann als Clients. Die Verwendung mehrerer Server oder Clients ist möglich.

Die meisten Funktionalitäten sind in unterschiedliche (Evolutions-)Stufen unterteilt. In der Regel schließen höhere Stufen niedrigere mit ein und erweitern diese. Eine solche Abwärtskompatibilität ermöglicht auch Geräte verschiedener Generationen gemeinsam zu nutzen.

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.

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.

Unter „Netzwerkmanagement“ versteht man die Art und Weise, wie die Zugriffsmöglichkeiten auf den Bus geregelt werden (Wer darf wann an wen Daten senden?). Es handelt sich dabei um Vorgänge, von denen der Nutzer üblicherweise nichts merkt – jedenfalls solange nicht, wie es beim Zugriff der unterschiedlichen Geräte auf den Bus nicht zu Konflikten kommt.

In einem ISOBUS-System können Geräte während der Laufzeit an den Bus angebunden und auch wieder abgetrennt werden. Dies ist nur möglich, weil es eine dynamische Adressvergabe gibt. Der sogenannte adress claim sorgt dafür, dass jeder Teilnehmer einen eindeutigen Namen erhält. Auch muss jeder Teilnehmer eine Liste pflegen in der festgehalten wird, wer welchen Namen zur Zeit innehat und welche Botschaften der Teilnehmer bekommen muss. Dies ist der Grund, warum eine Hardware-Identifier-Filterung wie z. B. mit Messageobjects im Grunde unmöglich ist.

  Die ECU 1 sendet ein Address Claimed mit ihrem Namen als Broadcast-Nachricht. Die anderen ECUs, die online sind, melden sich darauf hin mit ihrer Adresse und ihrem Namen. Danach weiß die ECU 1, dass sie die Adresse 15 belegen darf, da ihr Name eine höhere Priorität hat als der der ECU 2, die die Adresse 15 bis jetzt belegt hat. Dies tut sie mit einem Adress Claimed mit der Adresse 15 kund. Darauf sendet die ECU 2 ein Cannot Claim Address und erhält die Adresse Null. Als Nächstes muss die ECU 2 sich entweder selbstständig eine neue Adresse suchen, oder mit einem Command Address eine neue Adresse von einem anderen Teilnehmer zugewiesen bekommen. Dieser Vorgang findet jedes Mal nach einem Power Up statt oder wenn ein neuer Teilnehmer hinzukommt, z. B. wenn bei einem ISOBUS-Netzwerk ein Implement angeschlossen wird. Mechanismen, die z. B. beim Profibus, einem anderen Feldbus, vorgesehen sind um am Anfang eine Überlast auf dem Bus zu vermeiden, indem die einzelnen Teilnehmer eine von ihrer Seriennummer abhängige Zeit warten, sind nicht implementiert. Beim J1939 und ISOBUS findet in einer solchen Situation eine Arbitrierung statt, da er ja als Layer7 auf die CAN-Layer aufsetzt. Ein Address Claimed kann auch als P2P-Botschaft an einen einzelnen Teilnehmer gesendet werden. Dies kann sinnvoll sein, um aus den Namen auf die Funktion zu schließen. Ein ISOBUS-Teilnehmer sollte sich selbst einen neuen Namen zuweisen können für den Fall, dass er seinen Namen während eines Adressclaim abgeben muss. Dies ist ein großer Unterschied zu einem J1939-Netzwerk, bei dem diese Fähigkeit weit weniger wichtig ist.

Der Mikrocontroller wird durch das Netzwerkmanagement stark belastet, denn jede ankommende Nachricht löst einen Interrupt aus und es muss geprüft werden, ob sie für den Teilnehmer von Bedeutung ist. Die Norm ist hier so gehalten, dass auch sehr unwahrscheinliche Fälle abgedeckt werden. Dies ist teilweise kaum umzusetzen, im Grunde ist keine angebotene Softwarelösung somit wirklich normkonform. In der Regel hat dies aber keine Auswirkung auf das Betriebsverhalten. Problematisch sind Situationen, bei denen Empfänger oder Sender während eines Datentransports mit einem Transportprotokoll ihren Namen wechseln. Dies führt in der Regel zum Abbruch der Datenübertragung.

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.

Für den Anwender relevante Neuerungen sind die genormten Steckverbindungen für Signale und elektrische Energie zwischen Traktor und Anbaugerät (die sowohl am Heck als auch an der Maschinenfront vorhanden sein sollten), dem Virtual Terminal (VT) sowie dem Task Controller (TC), der aber auch in das VT integriert sein kann. Problematisch bei dem ISOBUS ist, dass die Norm dem Entwickler doch relativ viele Freiheiten lässt. So wird ein Objectpool, der auf dem einen VT super aussieht, auf einem anderen so schlecht dargestellt, dass sogar die Bedienbarkeit darunter leiden kann. Hier ist der Entwickler gefordert, eine für möglichst alle VT geeignete Darstellung zu finden. Teilweise sind die Geräte auch nicht ganz ISOBUS-konform, so dass der Bus unter ungünstigen Umständen nicht funktioniert. Mit der zunehmenden Verbreitung ISOBUS-tauglicher Schlepper wird es aber auch kostenmäßig für Anbaugerätehersteller immer interessanter, ihre Geräte ISOBUS-tauglich auszurüsten. Aus diesem Grund ist damit zu rechnen, dass diese Probleme dauerhaft eher abnehmen.

An der TU München erkannte man bereits zu den Zeiten von LBS, dass man dem System zu mehr Verbreitung verhelfen kann, wenn man eine Opensource LBS-Library schafft. Es entstand eine Library unter einer GPL-konformen Lizenz, die später so angepasst werden konnte, dass sie ISOBUS-konform war. Mit dem Auslaufen des Forschungsvorhabens wurde die Library von der OSB AG übernommen und dort einige Zeit gepflegt. Grundsätzlich können so ISOBUS-Anwendungen allein mit Opensource-Werkzeugen erstellt werden, jedoch haben sich heutzutage kommerzielle Lösungen weitgehend durchgesetzt. Gründe dafür sind unter anderem die aufwendig laufende Softwarepflege, der notwendige professionelle Support und die Integration für unterschiedlichste Hardware-Plattformen.

In einem weiteren Opensource Projekt aus Finnland wurde ein Tool zur Maskenerstellung entwickelt, jedoch nicht weiterverfolgt. Auch bei den Tools zur Maskenerstellung haben sich im Markt heute kommerzielle Tools durchgesetzt.

Bei der Entwicklung von elektronischen Systemen, die in der Landtechnik eingesetzt werden, sollte die ISO25119 beachtet werden. In der Norm werden Anforderungen und Prozesse definiert, die erforderlich sind, um ein System in den Markt zu bringen, bei dem elektrische Funktionen sicherheitsrelevante Funktionen kontrollieren. Kommt dabei der ISOBUS zum Einsatz, in der Regel als sogenanntes Input-System, so sind ISOBUS-Komponenten möglicherweise im sicherheitskritischen Pfad. Hierzu sind von der AEF Richtlinien erarbeitet worden, welche Anforderungen an ISOBUS-Komponenten gestellt werden müssen, um sie in einem Anwendungsfall verwenden zu können, bei dem sie Teil eines safety-relevanten Systems sind. Mit der ISOAgLib Safety Edition gibt es derzeit einen im Markt verfügbaren, kommerziellen, nach ISO 25119-SRL 2 zertifizierten ISOBUS-Stack.

Um hinsichtlich der obengenannten Probleme eine Kompatibilität der JR, Terminals, TC usw. sicherzustellen, sind folgende Ansätze etabliert worden.

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.

• ISO 11783, Beuth Verlag
• Reibungslose Kommunikation zwischen Traktor und Anbaugeräten, in: ElectronicAutomotiv 12, 2003

Basisinformationen zu LBS:

• Auf dem Weg zum Hightech-Produkt–Zeitschriftenartikel

Basisinformationen zu ISOBUS:

• Agricultural Industry Electronics Foundation e. V.(AEF), unabhängige, internationale Branchenorganisation zur Förderung der Elektronik mit Schwerpunkt ISOBUS
• Competence Center ISOBUS e. V.: Verein zur Förderung des ISOBUS
• ISOBUS-Informationen der Landwirtschaftskammer Nordrhein-Westfalen
• Offizielle ISOBUS Informationsseite
• Traktoren: Auf dem Weg zum Hightech-Produkt–Zeitschriftenartikel
• Informationen der Bundesanstalt für Landtechnik

Weiterführendes:

• AEF-ISOBUS-DATABASE
• Kommerzielle Entwicklungswerkzeuge und Software-Komponenten von Vector Informatik
• Opensource ISOBUS-Bibliothek
• Kommerzielles Tool zur Objektpoolerstellung von den Entwicklern der Opensource ISOAGLIB
• Kommerzielles Tool zur grafischen Erstellung und Bearbeitung von IOP-Dateien
• Anbieter eines Tools zur Objectpoolerstellung
• Opensource Tool zur Objectpoolerstellung
• Video zum Thema ISOBUS auf YouTube

1. ↑ ^{a b} Beuth Verlag (Hrsg.): ISO 11783 Part 6. Part 6. 
2. ↑ Beuth Verlag (Hrsg.): ISO11783 Part 9. Teil 9. 
3. ↑ ISO11783-Part10
4. ↑ ISOBUS Data Dictionary – DDEntity. Abgerufen am 25. Januar 2018 (englisch). 
5. ↑ ISO11783-Part5