ISOBUS ist der Markenname oder die Apllikation 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 NEMA2000-Protokolls übernommen worden. Eine IOSBUS Anwendung nutzt praktisch nie alle in der Norm definierten Mögllichkeiten sonder stellt immer eine begrenzte Menge daraus dar.
Inhaltsverzeichnis |
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 Datenaustauch 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.
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.
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.
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 Controler 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.
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/Drehknöpfen ausgestattet ist. Es muss mindestens eine Auflösung von 200x200 Pixel und 6 Druckknöpfe besitzen. Für jeden Knopf muss eine Softbuttondarstellungsfläche von mindestens 60x32 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 (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.
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 zur Verfügung.
Es gibt verschiedene Level. Je nach Level müssen unterschiedliche Funktionen unterstützt werden. In den höheren Leveln kann ein Anbaugerät auch auf den Traktor zugreifen und z. B. das Hubwerk ansteuern. Problematisch ist hier aber noch die Unfallsicherheit.
Der oder die Jobrechner sitzt 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 Mikroprozessor 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.
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.
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.
Ein GPS-Empfänger kann Positionsdaten für Navigations- und Dokumentationszwecke im NMEA2000 Format bereitstellen. Es ist dafür ein spezielles Transportprotokoll vorhanden.
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.
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.
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.
Schon zu LBS-Zeiten gab es aus dem Willen, die Verbreitung zu steigern, ein Forschungsvorhaben an der TU München, aus dem eine Opensource LBS-Library hervorgegangen ist. Diese wurde später so angepasst, dass sie ISOBUS-konform ist. 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-compatible 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.
Ein Plugfest ist ein Treffen von ISOBUS-Entwicklern auf dem die Kompatibilität der einzelnen Geräte untereinader 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.
Basisinformationen zu LBS
Basisinformationen zu ISOBUS
Weiterführendes