Integration von CAN-Bus, J1939 und ISOBUS in Landmaschinen

1. CAN-Bus-Anschluss und Nachrichtenbeschreibung unterscheiden

In der Schichtenbeschreibung von CiA werden die unteren CAN-Schichten von höheren Protokollen wie J1939 unterschieden. CAN-Leitung, Transceiver und Controller bilden die Infrastruktur der Datenkommunikation. Ob ein Byte innerhalb einer Nachricht eine Temperatur oder einen Zustand bezeichnet, ergibt sich aus der Anwendungsdefinition. Auf derselben physischen Schnittstelle können unterschiedliche Nachrichtenbeschreibungen verwendet werden. Deshalb genügt die Kenntnis der CAN-H- und CAN-L-Anschlüsse allein nicht, um die Maschinendaten zu interpretieren.

Bei der ersten Untersuchung bestimmen wir Steckerbelegung, Versorgung, Bitrate, Topologie, Terminierung und den zulässigen Anschlusspunkt. Die elektrische Belastung und der Leitungsabzweig des zusätzlich in das Maschinennetz eingebundenen Geräts werden bewertet. Auch die Unterstützung von CAN Classic und CAN FD darf zwischen Geräten nicht vorausgesetzt werden. Die Gateway-Hardware wird entsprechend den Bedingungen des betreffenden Busses ausgewählt. Eine kurze Leitung im Labor repräsentiert nicht automatisch die langen Leitungen und Störbedingungen an der Maschine.

2. PGN, SPN und Signalgültigkeit für J1939 festlegen

In J1939-Projekten bezeichnet die PGN (Parameter Group Number) eine Parametergruppe und die SPN (Suspect Parameter Number) einen definierten Parameter. Der J1939 Digital Annex von SAE gehört zu den offiziellen Quellen für diese Definitionen. Ein Signal zu decodieren bedeutet mehr, als nur seine Nummer zu kennen: Position und Länge im Datenfeld, Auflösung, Offset, Einheit und Kennzeichnungen ungültiger Werte müssen ebenfalls bekannt sein. Dokumentenstand und Zugriffslizenz werden zu Projektbeginn geprüft.

Es wird nicht vorausgesetzt, dass jede Maschine alle gewünschten Werte sendet. Für jedes benötigte Signal prüfen wir Sendefrequenz, Quelle und ob es auf Anfrage oder unaufgefordert übertragen wird. Änderungen der Quelladresse, Daten-Timeouts und Anforderungen an die Adressverwaltung werden in der Softwarearchitektur berücksichtigt. Bleibt eine erwartete Nachricht aus, wird ein Gültigkeitsstatus ausgegeben, statt den letzten Wert unbegrenzt als aktuell anzuzeigen. Für herstellerspezifische Nachrichten sind autorisierte Nachrichtenunterlagen oder Datendefinitionen mit entsprechenden Nutzungsrechten erforderlich.

3. Das ISOBUS-Ziel als Funktion statt nur als „kompatibel“ beschreiben

ISOBUS umfasst die Kommunikation landwirtschaftlicher Maschinen und Geräte auf Grundlage der Norm ISO 11783. Nach der Beschreibung der AEF bestimmen die von den Komponenten gemeinsam unterstützten Funktionen ihre Interoperabilität. Daher lässt sich aus der Bezeichnung ISOBUS auf zwei Produkten nicht ableiten, dass sämtliche Funktionen zusammenarbeiten. Im Projekt werden die Rollen von Traktor, Terminal und Anbaugerät sowie die Softwareversionen dokumentiert. Außerdem wird dargestellt, welche Komponente die gewünschte Funktion bereitstellt.

UT wird hinsichtlich der Gerätebedienoberfläche am Terminal betrachtet, TC-BAS hinsichtlich der Dokumentation von Auftragsdaten, TC-GEO hinsichtlich positionsbezogener Daten und variabler Ausbringmengen und TC-SC hinsichtlich der Teilbreitensteuerung. Diese Funktionen sind nicht austauschbar. Eine sichtbare Bedienoberfläche am Terminal bedeutet beispielsweise nicht, dass die automatische Teilbreitensteuerung umgesetzt ist. Je nach Ziel werden Protokollstack, Lizenzen, Object Pool und Testinfrastruktur geprüft. AEF-Konformität und Zertifizierung werden gesondert geplant. Ohne Prüfung werden weder Zertifikate noch Kompatibilität mit sämtlichen Marken zugesagt.

4. Reine Datenauslesung und Steuerbefehle als getrennte Arbeitspakete definieren

Ein Projekt zur reinen Datenüberwachung kann auf ein Gerät beschränkt sein, das freigegebene Signale liest und aufzeichnet. Bei passiver Überwachung prüfen wir, ob Hardware und Treiber tatsächlich einen Listen-only-Modus unterstützen; dieser darf nicht mit dem Bestätigungsverhalten eines regulär am CAN-Bus teilnehmenden Geräts verwechselt werden. Muss zum Empfang eines Signals eine Anfragenachricht gesendet werden, gehört auch dieser Vorgang zum festgelegten Datenzugriff. Die Aussage „Es soll nur mitlesen“ macht eine Untersuchung des Netzwerkverhaltens nicht überflüssig.

Bei einem System, das Steuerbefehle erzeugt, werden Bedienberechtigung, Befehlsgültigkeitsdauer, Rückmeldung und Verhalten bei Kommunikationsverlust festgelegt. Das Senden eines Befehls durch das Bedienterminal und die tatsächliche mechanische Ausführung sind unterschiedliche Ereignisse. Auch Fälle wie die erneute Ausführung eines veralteten Befehls nach Wiederverbindung werden bewertet. Zentrale Brems- oder Lenkfunktionen und die automatische Lenkung eines Traktors haben andere Risiken und Validierungsanforderungen als eine ergänzende Datenerfassung. Dieser Ratgeber erhebt keinen Anspruch auf Kompetenz für zertifizierte Lösungen in diesen Bereichen.

5. Zuständigkeiten von ECU, Sensor, HMI und Gateway darstellen

Bei einer Sämaschine kann eine Sensorplatine den Saatgutdurchgang erfassen, die Geräte-ECU die Arbeitslogik ausführen, die HMI den Zustand anzeigen und ein Gateway Aufzeichnungen an den Server übertragen. Ob diese Funktionen auf einer Platine oder in getrennten Einheiten umgesetzt werden, ist eine Projektentscheidung. Werden für jede Verbindung Datenverantwortlichkeit, Einheit, Aktualisierungsintervall und Fehlerverhalten festgelegt, sind die Systemgrenzen klar. Ob beispielsweise ein Internetausfall die lokale Steuerung anhalten darf, wird damit zu einer ausdrücklichen Anforderung.

Bei einer 4G/GNSS-Einheit können Messzeitpunkt und Eingangszeitpunkt auf dem Server getrennt gespeichert werden. Festgelegt werden die Kennzeichnung von Datensätzen bei ungültiger Position, die Kapazität des Offline-Speichers und das Verfahren zur erneuten Übertragung. Muss eine vorhandene Herstellerplattform angebunden werden, kann auch die Nutzung einer autorisierten API statt des physischen Maschinenbusses geprüft werden. Beim Beispiel der Geräteschnittstelle von Deere ist der Zugang an Organisation und Berechtigung gebunden. Daraus folgt nicht, dass andere Marken oder sämtliche Daten auf dieselbe Weise zugänglich sind.

6. Herstellerunterlagen, DBC und Datenrechte von Anfang an prüfen

Für das Projekt werden Anschluss- und Nachrichtenunterlagen des Maschinenherstellers, der Servicezugangsweg und der erlaubte Nutzungsumfang angefordert. Ist eine Signaldefinitionsdatei wie eine DBC vorhanden, werden Quelle, Version und Nutzungsrecht dokumentiert. Zugriff auf eine Datei bedeutet nicht automatisch, dass sie weiterverbreitet oder uneingeschränkt an Kunden übertragen werden darf. Auch rohe CAN-Aufzeichnungen können Kunden-, Maschinen- und Betriebsdaten enthalten; daher muss der Umfang ihrer Weitergabe festgelegt werden.

Ein NDA regelt als Teil der Zusammenarbeit den vertraulichen Austausch technischer Informationen. Zum Projektabschluss werden der von VOMRO entwickelte Quellcode, Schaltpläne und PCB-Designs, mechanische CAD-Daten und technische Unterlagen übergeben. Für Protokollstacks Dritter, Normdokumente oder herstellerspezifische Nachrichtenbeschreibungen werden die jeweiligen Lizenzbedingungen gesondert aufgeführt. Das Übergabepaket muss klar zeigen, welche Dateien zum Projekt gehören, wofür zusätzlicher Zugriff nötig ist und welche Umgebung für einen erneuten Build benötigt wird. Ein ungeklärter Datenzugriff gilt nicht als abgeschlossene Entwicklung.

7. Prüfstands-, Simulations- und Feldtests miteinander verknüpfen

Auf dem Prüfstand werden mit bekannten Signalen Decodierung, Einheitenumrechnung und Timeout-Verhalten getestet. Das Wiedergeben aufgezeichneter Nachrichten ermöglicht einen Vergleich zwischen normalen und unvollständigen Datensätzen, ersetzt jedoch nicht die elektrischen und mechanischen Bedingungen der realen Maschine. Simulierte Sensoren, reale Lasten und das Zielterminal sind unterschiedliche Testeingaben. Für jedes Ergebnis müssen Hardwarestand, Softwareversion, verwendete Nachrichtendefinition und Prüfbedingungen dokumentiert werden.

In der Pilotmaschine werden die erwarteten Ergebnisse bei Versorgungsschwankungen, Verbindungsunterbrechungen, ECU-Neustarts und erforderlichen Sensorfehlerszenarien überprüft. Bei ISOBUS-Anforderungen werden die vorgesehenen Terminal- und Gerätekombinationen getrennt getestet. Ein erforderliches Konformitätsverfahren wird gesondert durchgeführt. Es wird nachverfolgt, in welcher Softwareversion ein im Feld beobachteter Fehler behoben wurde. PCB-Muster und Bestückungsunterstützung von VOMRO sind ausschließlich innerhalb der selbst entwickelten Kundenprojekte Bestandteil dieses Prototypen- und Validierungsablaufs.

8. Das Lastenheft anhand eines konkreten Beispiels erstellen

Beispiel für einen Entwurf: „Am vom Kunden festgelegten Traktor und Pflanzenschutzgerät werden freigegebene Geschwindigkeitsdaten und ein separater Durchflusssensor ausgelesen. Auf dem Bedienterminal werden Soll- und Messwert angezeigt. Arbeitsdaten werden ohne Internet gespeichert und bei bestehender Verbindung an den Server übertragen.“ Dies ist keine Kundenreferenz, sondern ein Beispiel für die Formulierung eines Projektumfangs. Die Projektgrenze wird klar festgelegt, indem ausdrücklich angegeben wird, dass zunächst keine Steuerbefehle an die Maschine gesendet werden, beziehungsweise welche Steuerung hinzukommt.

Der Entwurf wird um Maschinenmarke, Modell und Baujahr, Terminal- und ECU-Versionen, Sensordatenblätter, Pinbelegung, Nachrichtenunterlagen und Zugriffsberechtigung ergänzt. Anschließend werden Abnahmekriterien eingetragen: Messbereich, zulässiger Fehler, Datenlatenz, Speicherkapazität und Verhalten bei Unterbrechungen. Zahlenwerte werden gemeinsam passend zum Einsatz festgelegt. Die Lieferliste umfasst Quellcode, PCB/CAD, Anschlussplan, Build-Informationen, Prüfbericht und eine Liste der Drittanbieterlizenzen. Damit lassen sich Angebote anhand derselben Funktion und derselben Validierungserwartung beurteilen.

• Benötigte Daten: Quelle, Einheit, Häufigkeit und Gültigkeit
• Maschinenumfang: Modell, Version, Terminal und autorisierte Unterlagen
• Abnahme: Messung, Latenz, Unterbrechung und Feldtest
• Übergabe: Quelldateien, Konstruktion, Anschlüsse, Tests und Lizenzliste