ISOBUS

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 den 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. Gleichzeitig 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 kommerziell verfügbar war.

Entstehung und Organisation des ISOBUS

Orga

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 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 oder 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.

ISOBUS Stecker

ISOBUS Breakaway Plug 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 spielen hier die Baureihe DT von der Firma Deutsch.

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- und eventuell 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, 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.

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 nutzt 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 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 Powermanagment. 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.

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.

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 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 einfach Fehlersuche bei verschiedenen Geräten mit einem standardisierten Tester durchzuführen.

Problematisch ist, dass bei vielen 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 einzufü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 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 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 mit der Spritze auf dem Feld, kann der Taskcontroller nach Freigabe durch den Fahrer den Auftrag abarbeiten. Jenachdem 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.

Fileserver

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

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, dem FPP vorhanden. Dieses ist aufgrund der relativ hohen Wiederholungsrate von 50 ms 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 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, 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.

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 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.

Transportprotokolle

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

Insgesamt werden hierfür 4 verschiedene Transportprotokolle genutzt:

CMDT

Connection Mode Data Transfer ist 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 zusenden oder eine Pause bei der Übertragung einzulegen.

BAM

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

ETP

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

FPP

Zum schnellen zyklischen Versenden von Daten, in der Regel GPS-Daten wurde aus der NMEA2000 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.

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 (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 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-kompatiblen Lizenz frei zu Verfügung. 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 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.

Literatur

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

Weblinks

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

• 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