Bei der Entwicklung, Fehlersuche oder wissenschaftlichen Auswertung kann es notwendig sein, sich mit ISOBUS-Rohdaten auseinanderzusetzen. Rohdaten können beispielsweise mit CAN-Loggern, Entwicklungswerkzeugen oder direkt aus Logdateien von Maschinen aufgezeichnet werden.
In diesem Tutorial wird an zwei Beispielen aus der Praxis gezeigt, wie ISOBUS-Nachrichten aufgebaut sind und Schritt für Schritt decodiert werden können. Hierfür werden zuerst die notwendigen Grundlagen erläutert, bevor die vorgestellte Vorgehensweise auf zwei reale ISOBUS-Nachrichten angewendet wird.
Der ISOBUS wurde entwickelt, um eine gemeinsame Datenschnittstelle für Landmaschinen und Anbaugeräte unterschiedlicher Hersteller zu schaffen. Vor Einführung des ISOBUS konnte es beispielsweise notwendig sein, für jedes Anbaugerät ein eigenes Terminal auf der Maschine zu installieren. Der ISOBUS ermöglicht, Anbaugeräte verschiedener Hersteller mit nur einem Terminal zu nutzen. Ebenfalls können Maschinendaten, wie der Kraftstoffverbrauch, über eine standardisierte Stelle ausgelesen und gespeichert werden [1].
ISOBUS basiert auf dem CAN-Protokoll, welches ursprünglich für den Automobilbereich entwickelt wurde. Der ISOBUS ist in der Normenreihe ISO 11783 genormt. Hier sind sowohl die physikalischen, als auch die softwareseitigen Randdaten definiert.
Bei einem Bussystem werden alle Teilnehmer über zwei Leitungen verbunden (CAN-High und CAN-Low). Teilnehmer sind beispielsweise Steuergeräte für Motor oder Hydraulik, Anbaugeräten oder Terminals. Jeder Teilnehmer verfügt über eine eindeutige Adresse, über die er von anderen Teilnehmern identifiziert werden kann [2].
Die Nachrichten werden von allen Teilnehmern über die gleiche Leitung gesendet. Damit sich Nachrichten nicht überlagern, wird jede Nachricht mit einer Priorität versehen. Senden mehrere Teilnehmer gleichzeitig, setzt sich automatisch die Nachricht mit der höchsten Priorität durch. Teilnehmer mit niedrigerer Priorität unterbrechen ihre Übertragung und versuchen anschließend erneut zu senden [3].
Im weiteren Verlauf dieses Beitrags werden reale ISOBUS-Nachrichten Schritt für Schritt decodiert. Da diese Nachrichten üblicherweise im Hexadezimalsystem dargestellt werden, werden zunächst die hierfür notwendigen Grundlagen der Zahlensysteme erläutert.
ISOBUS-Nachrichten werden auf dem CAN-Bus als Folge von Einsen und Nullen übertragen. Für die Darstellung in Logdateien wird jedoch meist das Hexadezimalsystem verwendet. Dieses verwendet für die Zahlendarstellung die Ziffern 0-9 sowie die Buchstaben A – F. Die zusätzlichen Hexadezimalziffern A bis F entsprechen den Dezimalzahlen 10 bis 15 und sind in Tabelle 1 abgebildet [4].
Tabelle 1: Zusätzliche Ziffern im Hexadezimalsystem
|
Hexadezimal |
Dezimal |
|---|---|
|
A |
10 |
|
B |
11 |
|
C |
12 |
|
D |
13 |
|
E |
14 |
|
F |
15 |
Damit ersichtlich ist, in welchem Zahlensystem eine Zahl dargestellt wird, wird häufig ein Index verwendet. In Tabelle 2 ist die Zahl elf jeweils in Dezimal-, Binär- und Hexadezimalschreibweise mit dem entsprechenden Index dargestellt.
Tabelle 2: Darstellung der Zahl elf als Dezimal-, Binär- und Hexadezimalzahl
|
Dezimal |
Binär |
Hexadezimal |
|---|---|---|
|
1110 |
10112 |
B16 |
Für die Interpretation von ISOBUS-Nachrichten müssen Werte zwischen Binär-, Hexadezimal- und Dezimaldarstellung übertragen werden. Eine händische Umrechnung ist dabei in der Regel nicht erforderlich, da hierfür zahlreiche Online-Tools und Softwarelösungen zur Verfügung stehen [5, 6].
Für das Verständnis von ISOBUS-Nachrichten ist die Kenntnis der Begriffe Bit und Byte relevant. Ein Bit ist ein einzelnes übertragenes Zeichen, binär also eine Eins oder Null. Ein Byte hingegen besteht aus acht Bit.
Ein Hexadezimal-Zeichen entspricht vier Bit. Ein Byte besteht aus acht Bit und kann daher mit zwei Hexadezimalzeichen dargestellt werden [4].
Beispielsweise entspricht das Byte CE16 der Bitfolge:
Die folgenden Beispiele nutzen diese Schreibweisen regelmäßig, weshalb die grundlegenden Zusammenhänge zwischen Hexadezimalzahlen, Bits und Bytes bekannt sein sollten.
In Tabelle 3 ist eine ISOBUS-Nachricht im Hexadezimalsystem dargestellt. Eine ISOBUS-Nachricht besteht aus dem Header, in welchem allgemeine Informationen zur Nachricht gespeichert sind. Die tatsächlichen Daten werden im Payload übertragen [7].
Tabelle 3: Darstellung einer ISOBUS-Nachricht im Hexadezimalsystem
|
Header |
Payload |
|||||||||||
|
Byte 1 |
Byte 2 |
Byte 3 |
Byte 4 |
Byte 1 |
Byte 2 |
Byte 3 |
Byte 4 |
Byte 5 |
Byte 6 |
Byte 7 |
Byte 8 |
|
|
0 C |
F E |
4 8 |
F 0 |
# |
3 C |
0 5 |
B 8 |
0 A |
0 F |
0 1 |
0 2 |
F 5 |
Die ersten 3 Bits stellen die Priorität der Nachricht da. Diese sind in Byte 1 (0C16) codiert. Für die Identifikation der Priorität muss diese zuerst in das Binärsystem überführt werden:
0C16 = 0000 11002
Der Header einer ISOBUS-Nachricht besteht aus einem 29-Bit-Identifier. Zur Darstellung in Logdateien wird dieser häufig in einem 32-Bit-Wert gespeichert. Die drei höchstwertigen Bits der 32-Bit-Darstellung sind dabei ungenutzt und gehören nicht zum Identifier. Für die Priorität ergibt sich entsprechend folgendes:
0000 11002 = 0112 = 310
Die Beispielnachricht wurde somit mit der Priorität 310 gesendet. Dabei entspricht 010 der höchsten und 710 der niedrigsten Priorität. Für die nachfolgende Decodierung der Nachricht ist diese Information in der Regel nicht relevant [8].
Welche Daten der Payload enthält, wird in der Parameter Group Number (PGN) definiert. Relevant sind hierbei das erste und zweite Byte des Headers. Um die PGN zu bestimmen, wird zuerst das zweite Byte betrachtet. Ist der Wert größer oder gleich 24010, so wird die PGN aus Byte zwei und drei gebildet. Die Nachricht wird dadurch an alle Teilnehmer adressiert [8].
Ist Byte zwei hingegen kleiner als 24010, so bildet sich die PGN aus Byte 2, an das 0016 angehangen wird. Byte drei beschreibt in diesem Fall die Zieladresse der Nachricht (Destination Address, DA). Hierbei wird definiert, an welchen Teilnehmer die Nachricht gesendet wird [8].
Das vierte Byte des Headers definiert Absenderadresse (Source Address, SA) des Teilnehmers, welcher die Nachricht sendet. So kann beispielsweise nachvollzogen werden, welcher Teilnehmer die einzelne Nachricht gesendet hat [7].
Für den Inhalt des Payloads ist die Suspect Parameter Number (SPN) relevant. Diese gibt an, welcher Inhalt an welcher Stelle im Payload steht. Da ein Wert normalerweise nicht die gesamten acht Byte des Payloads benötigt, sind einer PGN normalerweise mehrere SPNs zugeordnet. Die Lage der SPN ist bei jeder Nachricht fest definiert, das heißt, dass zum Beispiel die Motordrehzahl immer an der gleichen Stelle im Payload steht [8].
Bei der Interpretation von Werten aus mehreren Bytes ist zu beachten, dass das niederwertigste Byte zuerst übertragen wird. Besteht ein Wert beispielsweise aus zwei Byte, so ist das zuerst gesendete Byte an niedrigster Stelle, das zuletzt gesendete Byte an höchster Stelle [8].
Einen Spezialfall stellt die „Process Data Message“ mit der PGN 51968 dar. Sie wird im zweiten Praxisbeispiel ausführlich vorgestellt.
|
In der Abbildung ist das Vorgehen zur Decodierung einer ISOBUS-Nachricht dargestellt. Der Inhalt standardisierter ISOBUS-Nachrichten ist in der ISO 11783-11 beschrieben und kann über die Datenbank auf www.isobus.net komfortabel durchsucht werden. Dort stehen Informationen zu vielen standardisierten PGNs, SPNs und DDIs zur Verfügung [9]. Einschränkungen bestehen bei herstellerspezifischen Nachrichten. Deren Header entspricht zwar dem ISOBUS-Standard, der Inhalt des Payloads kann jedoch vom jeweiligen Hersteller frei definiert werden [7]. |
 |
Das Vorgehen wird nun an einer realen ISOBUS-Nachricht durchgeführt. Hierfür ist folgende ISOBUS-Nachricht gegeben:
0C FE 48 F0 # 3C 05 B8 0A 0F 01 02 F5
Im ersten Schritt muss die PGN bestimmt werden. Zuerst wird hierfür das zweite Byte des Headers betrachtet und in das Dezimalsystem überführt:
0C FE 48 F0 # 3C 05 B8 0A 0F 01 02 F5
Da das zweite Byte größer als 24010 ist, ist das dritte Byte Teil der PGN. Somit gilt:
0C FE 48 F0 # 3C 05 B8 0A 0F 01 02 F5
| Die PGN können bei isobus.net nachgeschlagen werden. |
 |
 |
Hier kann nun nach der entsprechenden PGN gesucht werden. Über die Lupe können weitere Details zur PGN angezeigt werden. |
| Unter den Details zur PGN sind am Ende der Seite die zugehörigen SPNs aufgeführt. Über die Lupe kann eine Detailseite zu den einzelnen SPNs aufgerufen werden. |
 |
Die Informationen zu SPN sind in der nachfolgenden Tabelle 4 aufgeführt.
Tabelle 4: SPNs der PGN 65096
| SPN | SP Name | SP Position in PG |
SP Length |
Scaling | Offset |
| 1862 | Wheel-based machine speed | 1-2 |
16 bits |
0,001 m/s per bit | 0 |
| 1863 | Wheel-based machine distance | 3-6 |
32 bits |
0,001 m/bit | 0 |
| 1866 | Maximum Time of Tractor Power | 7 |
8 bits |
1 min/bit | 0 |
| 1864 | Wheel-based machine direction | 8.1 |
2 bits |
4 states/2 bit | 0 |
| 1865 | Key switch state | 8.3 |
2 bits |
4 states/2 bit | 0 |
| 5203 | Implement Start/Stop operations | 8.5 |
2 bits |
4 states/2 bit | 0 |
| 5244 | Operator direction reversed | 8.7 |
2 bits |
4 states/2 bit | 0 |
Soll beispielsweise die SPN 1862 (Wheel-based machine speed) ausgelesen werden, muss zuerst die Position im Payload bestimmt werden. Die SPN ist in Byte 1-2 des Payloads enthalten und insgesamt 16 Bit (2 Byte) lang.
0C FE 48 F0 # 3C 05 B8 0A 0F 01 02 F5
In diesem Fall besteht der Messwert aus zwei Bytes:
|
Byte 1 |
Byte 2 |
|---|---|
|
3C |
05 |
Mehrbyteige Messwerte werden im ISOBUS mit dem niederwertigsten Byte zuerst übertragen. Das zuerst gesendete Byte enthält somit den niederwertigen Teil des Messwerts und muss bei der Darstellung der Hexzahl rechts stehen. Der übertragene Wert lautet daher 053C₁₆.
Abschließend müssen noch der Skalierungsfaktor sowie der Offset betrachtet werden. Der Skalierungsfaktor beträgt 0,001 m/s per Bit, der Offset beträgt 0. Somit ergibt sich für den Wert:
Für die SPN 1864 (Wheel-based machine direction) ist als Position 8.1 und als Länge 2 bit angegeben. Das bedeutet, im achten Byte des Payloads beginnt die SPN beim ersten Bit und umfasst Bit eins und zwei.
0C FE 48 F0 # 3C 05 B8 0A 0F 01 02 F5
Das letzte Byte ist die Zahl F516. Hier ist zu beachten, dass das niedrigwertigste Bit ganz rechts steht. Das erste Bit ist also in der 516 enthalten. Die 516 muss nun in das binäre Format übertragen werden.
Die SPN 1864 umfasst die zwei rechten Bits, als 012. Aus der Definition für die SPN 1864 auf isobus.net lässt sich ableiten, dass der Zustand „Vorwärtsfahrt“ bedeutet.
Mit diesem Beispiel konnten sowohl ein klassischer numerischer Messwert als auch Bitfelder und damit typische Eigenschaften vieler ISOBUS-Nachrichten demonstriert werden. Im folgenden Beispiel wird der Spezialfall einer Process Data Message vorgestellt.
Die Process Data Message ist in der landwirtschaftlichen Praxis weit verbreitet und dient der Übertragung von Arbeitsdaten zwischen Anbaugerät und Task Controller. Folgende Nachricht ist gegeben:
0C CB F7 80 # 03 00 07 00 E7 0F 00 00
Im ersten Schritt wird wieder die PGN identifiziert. Für das zweite Byte gilt:
0C CB F7 80 # 03 00 07 00 E7 0F 00 00
In diesem Fall ist das zweite Byte kleiner als 240. Dementsprechend ist Byte 3 die Zieladresse der Nachricht und das zweite Byte der PGN wird 0016 gesetzt:
Hier kann analog zum ersten Beispiel vorgegangen werden. Die PGN 5196810 ist die Process Data Message.
Die „Process Data Message“ ist als Container aufgebaut. Die einzelnen SPNs beschreiben nicht direkt Messwerte, sondern enthalten Informationen darüber, welcher Parameter übertragen wird und welchen Wert dieser besitzt. Diese sind in Tabelle 5 aufgeführt.
Tabelle 5: Aufbau der Process Data Message
| SPN | Name | Beschreibung | Position | Länge |
|
5199 |
Process data command |
Beschreibt, welche Aktion ausgeführt werden soll, beispielsweise ein Messwert, Sollwert oder eine Anfrage |
1.1 |
4 bits |
|
5200 |
Process data element number |
Bezeichnet das angesprochene Element, zum Beispiel eine bestimmte Düse bei einem Düngerstreuer |
1.5 |
12 bits |
|
5201 |
Process data dictionary identifier |
Beschreibt, welche Information übertragen wird |
3-4 |
16 bits |
|
5202 |
Process data variable value |
Der eigentliche Wert der Variablen |
5-8 |
32 bits |
Im Gegensatz zu vielen anderen PGNs beschreibt die Process Data Message nicht direkt den übertragenen Parameter. Stattdessen wird die eigentliche Information erst innerhalb des Payloads über die DDI definiert.
Für die weitere Decodierung sind insbesondere die SPN 5201 und 5202 relevant. Während SPN 5201 die DDI und damit die Art des übertragenen Parameters beschreibt, enthält SPN 5202 den eigentlichen Messwert.
Hier gilt wieder, dass das hintere Byte zuerst gesendet wird. Dementsprechend gilt für die DDI:
0C CB F7 80 # 03 00 07 00 E7 0F 00 00
Das gleiche gilt für den Wert der Variablen. Im Vergleich zu den vorherigen Beispielen :
0C CB F7 80 # 03 00 07 00 E7 0F 00 00
| Die Identifikation der DDI erfolgt über isobus.net. Hierfür kann auf der Seite die DDI ausgewählt werden. |
 |
 |
Anschließend kann der Wert der entsprechenden DDI herausgesucht werden. |
Der DDI 710 ist der Parameter „Actual Mass Per Area Application Rate“ zugewiesen.
| Nun müssen noch die Auflösung sowie die Einheit identifiziert werden. Die Auflösung beträgt 1 Bit, die Einheit mg/m2 pro Bit. |
 |
Für den gesendeten Wert gilt:
Der Wert wurde von einem Güllefass aufgezeichnet und beschreibt die zum Messzeitpunkt ausgebrachte Güllemasse.
| Abkürzung | Zuordnung | Kurzbeschreibung |
|---|---|---|
| PGN | Parameter Group Number | Beschreibt den Inhalt des Datenpaketes (Payload) und steht im Header der Nachricht. Über die PGN kann beispielsweise bestimmt werden, an welcher Stelle welche Daten im Payload übertragen werden. |
| SPN | Suspect Parameter Number | Identifiziert den konkreten Einzelwert innerhalb einer PGN. und legt fest, an welcher Bit-Position, in welcher Länge und mit welcher Skalierung der Wert in der Payload steht. |
| DDI | Data Dictionary Identifier | Identifiziert den Inhalt einer Process Data Message. Steht im Datenpaket (Payload) der Nachricht. |
| SA | Source Adress | Die 8-Bit Adresse des Senders der Nachricht. |
Anhand der Praxisbeispiele wurde die grundlegende Vorgehensweise zur Decodierung von ISOBUS-Nachrichten demonstriert. In der praktischen Anwendung treten jedoch häufig ähnliche Fehler auf. Die folgenden Punkte sollten daher besonders beachtet werden:
In diesem Tutorial wurde gezeigt, wie sich ISOBUS-Nachrichten Schritt für Schritt decodieren lassen. Während viele Nachrichten direkt über ihre PGN und die zugehörigen SPNs interpretiert werden können, erfordern Process Data Messages zusätzlich die Auswertung der enthaltenen DDIs. Mit dem vorgestellten Vorgehen lassen sich bereits viele ISOBUS-Rohdaten eigenständig analysieren, sofern sie den Vorgaben der ISO 11783 entsprechen. Weiterführende Informationen und tiefergehende Details können den entsprechenden Teilen der Normenreihe ISO 11783 entnommen werden.
M.Sc. Lukas Lange, Wissenschaftlicher Mitarbeiter am Fachgebiet Konstruktion von Maschinensystemen der TU Berlin, Projekt DigiMix-PA