Landwirtschaftliches BUS-System

ISOBUS ist der Markenname oder die Applikation eines Datenbusses für eine landtechnische oder kommunaltechnischen Anwendung die konform zu der Norm ISO 11783 ist. Die Norm definiert neben dem physikalischen Eigenschaften des Netzwerkes, wie Stecker und Leitungen, auch die Art der Teilnehmer, sowie Datenformate und Schnittstellen. Dabei sind wesentliche Teile des J1939- und des NMEA2000-Protokolls übernommen worden. Eine ISOBUS-Anwendung nutzt praktisch nie alle in der Norm definierten Möglichkeiten, sondern stellt immer eine begrenzte Menge daraus dar.

Anforderungen an moderne Landtechnik

ISOBUS muss im Zusammenhang mit einigen neuen Konzepten für die Landwirtschaft gesehen werden. Die passenden Stichwörter sind Precision Farming und „gläserne Produktion“.

Wenn es darum geht, die richtigen Dosierungen für Dünger und Pflanzenschutzmittel zu bestimmen, dann soll zukünftig berücksichtigt werden, welche Bedingungen auf dem jeweils zu bearbeitenden Flurstück vorgefunden werden. Beispielsweise soll auf einem Flurstück, auf dem besonders große Unkrautmengen festgestellt wurden, mehr Pflanzenschutzmittel verteilt werden als auf anderen (siehe Precision Farming). Zukünftig soll außerdem auch aufgezeichnet werden, welche Maßnahmen es bei der Bearbeitung bestimmter Flurstücke gegeben hat, sodass später nachvollzogen werden kann, unter welchen Bedingungen die Pflanzen gewachsen sind (gläserne Produktion). Diese modernen Formen der Landtechnik setzen voraus, dass Geräte zum Einsatz kommen, die imstande sind, ständig Daten untereinander auszutauschen. Mit ISOBUS wurden die Grundlagen für diese Art von Datenaustausch geschaffen.

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

Landwirte, die heutzutage ISOBUS-fähige Geräte einsetzen, können sich davon bisher vor allem eine verbesserte Übersichtlichkeit auf dem Traktor versprechen. Schon seit längerem sind Anbaugeräte im Einsatz, die vom Traktor her über ein Terminal gesteuert werden können. Bisher jedoch gab es für jedes Anbaugerät ein separates Terminal. Mit ISOBUS ist es möglich, Anbaugeräte verschiedener Art (und auch verschiedener Hersteller) über dasselbe Terminal zu steuern.

Zukünftig soll es möglich sein, dass Landwirte am Hof-PC festlegen, wie die flurstückspezifischen Dosierungen von Dünger und Pflanzenschutzmitteln aussehen sollen. Diese Angaben sollen dann auf ein Traktorsteuergerät übertragen werden und von dort an die Anbaugeräte weitergegeben werden. Ebenso soll es auch möglich werden, dass auf den Anbaugeräten Sensoren im Einsatz sind, die Daten über Bodenschaffenheit, Unkrautmengen und anderes ermitteln und die so gewonnenen Daten an das Traktorsteuergerät weitergeben, sodass sie von dort auf den Hof-PC übertragen werden können.

Der Vorläufer: Landwirtschaftliches BUS-System (LBS)

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. Zeitgleich zeichnete es sich auch ab, dass durch die Wahl eines CAN-Busses mit einem 11-Bit Identifier und den damit im Gegensatz zu einem 29-Bit-Identifier deutlich geringeren Adressraum, hier weniger auf die Teilnehmer als auf die mögliche Anzahl verschiedener PGNs 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 kommerzielle verfügbar war.

Entstehung und Organisation des ISOBUS

Trotz dieser Rückschläge blieb das Grundproblem bestehen. Auch war hierfür bei den Landmaschinenherstellern mittlwerweile 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 die einzelne Aspekte des Norm ausarbeiten und neue Abschnitte erarbeiten. Es finden von beiden Verbänden regelmäßig Treffen statt. Über das Steering Comitee 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, bzw. aktiv weiterentwickelt.

ISOBUS-Hardware

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.

Virtual Terminal

Das Virtual Terminal (VT) ist die Mensch-Maschine-Schnittstelle des ISOBUS. Es handelt sich dabei um ein Anzeige- und Bediengerät, das mit einem Bildschirm und mehreren Druck- bzw. Drehknöpfen ausgestattet ist. Es muss mindestens eine Auflösung von 200 × 200 Pixel 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.

Jedes Gerät, das an den Bus angeschlossen wird, 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 Internetseite vergleichbar. Es gibt standardisierte Objekte, wie Eingabefelder, Strings, Baragraphen 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.

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.

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.

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, 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 Graphik ist eine Beispielhafte Kommunikation zwischen einem VT und einer Implement ECU, hier z. B. eine Feldspritze, dargestellt. Die ECU nutz das VT als Anzeige und Bedienmodul.

Traktorsteuergerät

Das Traktorsteuergerät wird auch als Traktor-ECU bezeichnet, wobei „ECU“ für „Electronic Control Unit“ steht. Es handelt sich dabei um einen Jobrechner, der auf dem Traktor oder dem Trägerfahrzeug sitzt. Es stellt Informationen wie Fahrgeschwindigkeit, Zapfwellendrehzahl usw. im Bus im 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, bzw. 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äßt 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 Trakoreigene 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 Powermanagment. Wird die Zündung des Traktors ausgestellt, so sendet die Tractor ECU an die Implement ECU einen 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 enevtuell nach dem Abschalten des Traktormotors der Druck vom System abgelassen werden muss.

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

Jobrechner

Der Jobrechner, 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 bzw. die Umsetzung von Bedienereingaben. Aufgrund des Umfangs des Objectpools und vor allem des Netzwerkmanagements sind praktisch alle Jobrechner mindestens 16-Bit-Mikroprozessoren. Der C16x von Siemens ist hier sehr weit verbreitet. Bei Geräten mit sehr vielen Sensoren kommen vermehrt auch 32-Bit-Mikroprozessoren zum Einsatz, diese sind allerdings auch deutlich teurer als die 16-Bit-Variante.

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.

Problematisch ist, dass bei viele Realisationen 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 einfügen und hochzuladen.

Taskcontroller

Der Taskcontroller (TC) stellt die Schnittstelle zwischen dem Farm Management System und der Gerätesteuerung dar. Im einfachsten Fall dokumentiert er die ausgeführte Arbeit. Geplant ist, dass er anhand von Aufträgen die Steuerung des Anbaugerätes oder sogar 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 AB hat, 3 Teilbreiten und zwischen 100 und 1000 l/min ausbringen kann. Mit dieser Datei wird mit Hilfe einer Ackserschlagdatei, Positionsdaten und eventuell vorhanden 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 auf dem Feld mit der Spritze, kann der Taskcontroller nach Freigabe durch den Fahrer den Auftrag abarbeiten. Jenachdem wo der Fahrer fährt, wird den Daten entsprechen 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.

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 über Funknetzwerke basierend auf GSM oder WLAN zu beobachten.

GPS-Empfänger

Ein GPS-Empfänger kann Positionsdaten für Navigations- und Dokumentationszwecke im NMEA2000-Format bereitstellen. Es ist dafür ein spezielles Transportprotokoll vorhanden. Dieses ist Aufgrund der reltiv hohen Wiederholungsrate von 50 ms auf einen geringen Netzwerkoverhead ausgelegt. Die Daten werden dazu auf mehrer Can-Daten-Rahmen aufgeteilt und über ein Zählbyte logisch miteinander im 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 Power On 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 einen höhere Genauigkeit noch Korrekturen durchführen, bzw. 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.

Netzwerkmanagement

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 Adresse15 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 wie 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 bzw. 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 in der Lage sein, sich selbst einen neuen Namen zuweisen zu 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 Mikroprozessor 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.

Schnittstelle für den Anwender und Probleme des ISOBUS

Für den Anwender relevante Neuerungen sind die genormten Steckverbindungen für Signale und elektrische Energie zwischen Traktor und Anbaugerät. Diese sollten sowohl am Heck als auch an der Maschinenfront vorhanden sein. 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äßt. So wird ein Objectpool der auf dem einem 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 komplett 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.

Opensource und ISOBUS

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, 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 wird dort weiterhin als ISOAGLIB aktiv gepflegt. Sie steht unter einer GPL-compatiblen Lizenz frei zu Verfügung. OSB bietet gegen Bezahlung Support und Erweiterungen an. Grundsätzlich können so ISOBUS-Anwendungen allein mit Opensource-Werkzeugen erstellt werden. Eine gewisse Einschränkung besteht bei Crosscompilern für Jobrechner. Hier kommt herstellerseitig oft ein Tasking-Compiler zum Einsatz. Ein anderes Opensource Projekt stammt aus Finnland. Hier wurde ein Tool zur Maskenerstellung entwickelt. Es ist im Großen und Ganzen kompatibel zur Maskenbeschreibung der ISOAGLIB. Vorteil ist, dass man mit dem Tool sofort sieht, wie eine Maske aussieht. Bei der ISOAGLIB wird die Maske mit einer XML-Datei beschrieben (ähnlich wie HTML) und man kann das Ergebnis erst auf einem realen oder simulierten VT sehen.

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 DLG 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 statt. Sie sind wichtig, da es 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, 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.

Literatur

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

Weblinks

Basisinformationen zu LBS

• Landwirtschaftliches BUS-System (LBS) – Merkblatt der DLG, PDF-Datei
• Auf dem Weg zum Hightech-Produkt–Zeitschriftenartikel

Basisinformationen zu ISOBUS

• Seite eines Vereins zur Förderung und Forschung am und für den 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

• Anbieter einer kommerziellen ISOBUS-Bibliothek und von Entwicklungswerkzeugen
• Opensource ISOBUS-Bibliothek
• Kommerzielles Tool zur Objektpoolerstellung von den Entwicklern der Opensource ISOAGLIB
• Anbieter eines Tools zur Objectpoolerstellung
• Opensource Tool zur Objectpoolerstellung
• Video zum Thema ISOBUS