VDI Vortrag - Getriebe in mobilen Arbeitsmaschinen 2011 ... · PDF fileJ1939 und haben zum...

Referent: Dipl.-Ing. (FH) Bruno Klöpper MBA | Vortrag: Netzwerk-Design

1

Netzwerk-Design

SAE J1939, ISO 11783 (ISOBUS) und ISO 14229 (UDS Diagnose) im Antriebsstrang

landwirtschaftlicher Arbeitsmaschinen

Network-Design

SAE J1939, ISO 11783 (ISOBUS) and ISO 14229 (UDS diagnostic) in the power train

of agricultural machinery

Dipl.-Ing. (FH) Bruno Klöpper MBA Maschinenfabrik Bernard Krone GmbH Heinrich-Krone-Straße 10 48480 Spelle, Germany


2

Abstract In order to guarantee a manufacturer-spanning, standardised implement communication, for example between tractor and accessory, the agricultural machinery industry is able to access to documents, which have steadily been developed according to ISO 11783 for a few years. These documents serve as implementation rule for ISOBUS applications. All well-known agricultural machinery manufacturers including KRONE have suitable products with ISOBUS in their product portfolio and this number steadily increases. However, not only the number of ISOBUS devices in the market increases, but also their complexity. The visualization of implement information on, and the operation of implements with the tractor terminal (VT = Virtual Terminal) formed the focus in the recent years, whereas other ISOBUS functions become the focus of developments today. Keywords in this context are for example terms like Task-Controller (TC), Section-Control (SC), Parallel-Tracking (PT) or Tractor-Implement-Management (TIM). If this complexity, which will surely increase even more in the next few years, and the diversity of variants of agricultural machines should be controlled cost-effectively and with high standard of quality over the entire product-life-cycle, from development via production up to the service, the utilization of standard tools and uniform standards for communication and diagnostics is indispensable. This includes not only the manufacturer-spanning implement bus, called ISOBUS, but also the internal tractor bus. At this point it should also be considered that more internal networks can be available, as well and that the term tractor is according to ISO 11783 a synonymous for each kind of a self-propelled, agricultural machine. In the following, the characteristic features and functions of Standard SAE J1939 and ISO 11783, which is based on the communication principles of J1939, will be shown. Furthermore, an overview of the diagnostics standard 14229 UDS (Unified Diagnostic Services) will be given. Different integration options and applicabilities of UDS in an ISOBUS network (implement bus and tractor bus) will be pointed out, as well.

Zusammenfassung Für eine herstellerübergreifende, standardisierte Gerätekommunikation z.B. zwischen Traktor und Anbaugerät stehen der Landmaschinenindustrie nun schon seit einigen Jahren die stetig weiterentwickelten Dokumente gemäß ISO11783 als Implementierungsvorschrift für ISOBUS Applikationen zur Verfügung. Alle namhaften Landmaschinenhersteller inklusiev KRONE haben entsprechende Produkte mit ISOBUS im Programm und ihre Anzahl nimmt stetig zu. Aber nicht nur die Anzahl der ISOBUS Geräte im Markt nimmt zu. Auch die Komplexität der ISOBUS Geräte nimmt zu. Ging es in den vergangenen Jahren bei den ISOBUS Applikationen vor allem um die Visualisierung von Geräteinformationen auf-, bzw. um die Bedienung von Anbaugeräten mit dem Traktor-Terminal (VT=Virtual Terminal), so rücken heute immer stärker andere ISOBUS Funktionen in den Fokus der Entwicklungen. Schlagworte in diesem Zusammenhang sind hier z.B. Begriffe wie Task-Controller (TC), Section-Control (SC), Parallel-Tracking (PT) oder Tractor-Implement-Management (TIM).


3

Will man diese, in den nächsten Jahren sicher noch weiter steigende Komplexität und Variantenvielfalt von landwirtschaftlichen Maschinen über den gesamten Produktlebenszyklus, von Entwicklung über Produktion bis hin zum Service qualitativ hochwertig und kostengünstig beherrschen, so kommt man um die Verwendung von Standard-Tools und einheitlichen Standards für die Kommunikation und Diagnose von Steuergeräten nicht herum. Auch begrenzt sich dies nicht nur auf den herstellerübergreifenden, und als ISOBUS bezeichneten Geräte-Bus, sondern bezieht auch den internen Traktor-Bus mit ein. Wobei es sicherlich auch mehrere interne Netzwerke sein können und der Begriff Traktor gemäß ISO 11783 als Synonym für jede Art von selbstfahrende, landwirtschaftliche Arbeitsmaschine steht. In folgenden Ausführungen werden die charakteristischen Eigenschaften und Funktionen vom Standard SAE J1939 und ISO 11783, der auf den Kommunikationsprinzipien von J1939 beruht, aufgezeigt. Des Weiteren wird ein Überblick über den Diagnose-Standard 14229 UDS (Unified Diagnostic Services) gegeben und verschiedene Integrations- wie auch Anwendungsmöglichkeiten von UDS in einem ISOBUS-Netzwerk (sowohl Geräte- wie auch Traktor-Bus) aufgezeigt.

1 SAE J1939, ISO11783 (ISOBUS)

1.1 SAE J1939 Das von der „Society of Automotive Engineers“ (SAE) standardisierte CAN-Bus (Controller Area Network) Protokoll J1939 wurde ursprünglich für den Nutzfahrzeugbereich entwickelt, um elektronische Signale und Steuerungs-Informationen zwischen Fahrzeugkomponenten auszutauschen. Doch das hat sich im letzten Jahrzehnt verändert. Auch andere Branchen nutzen J1939 und haben zum Teil J1939 basierende Protokolle abgeleitet, die sich die grundlegenden Kommunikationsmechanismen von J1939 zu Nutze machen [7]. J1939 basierte Protokolle werden verwendet in [7]:

• Diesel-Power-Train Anwendungen • Internen Fahrzeug-Netzwerken von Lkws und Bussen • Land- und Forstwirtschaftlichen Maschinen (ISO 11783 dem sogenannten ISOBUS) • Truck-Trailer Verbindungen • Militärfahrzeugen (MiLCAN) • Fleet-Management Systemen • Wohnmobilen • Marine Navigationssystemen (NMEA2000)

Der bekannteste Anwendungsfall für J1939 ist sicherlich die elektronische Diesel-Motor Ansteuerung, die heute in den meisten schweren Nutzfahrzeugen, wie auch mobilen Arbeitsmaschinen zu finden ist. Die verschiedenen Dokumente von SAE J1939 beschreiben z.B. die physikalischen Eigenschaften, die Kommunikationsmechanismen oder auch die Signale, die für eine standardisierte, CAN-Bus (Controller Area Network) basierte Kommunikation zwischen einzelnen Steuergeräten in einem J1939 Netzwerk nötig sind. Ein schematisches Beispiel für ein solches J1939 CAN-Netzwerk zeigt Abbildung 1.


4

Abbildung 1: SAE J1939/31:2010 – Netzwerk Beispiel für den Lkw und Bus Anwendungsbereich [2]

Einige typische Eigenschaften eines J1939 Netzwerkes sind:

• CAN-Bus mit einer Standard Baudrate von 250kBit/s • 2-aderige, abgeschirmte und verdrillte Verbindungsleitung • Max. Buslänge von 40m • Max. 30 ECUs (Electronic Control Unit) pro Netzwerksegment (physikalische ECUs) • Max. 254 CA (Controller Applications; logische ECUs, wobei eine physikalische ECU

mehrere logische ECUs so genannte „Controller Applications“ beinhalten kann) • Multi-Master-Netzwerk • Peer-to-Peer und Broadcast Kommunikation möglich • …

1.1.1 CAN Identifier Die CAN-Bus Spezifikation ISO11898, auf der J1939 als „Higher Level“ Protokoll aufbaut, definiert für den Austausch von Informationen zwischen einzelnen CAN-Bus Teilnehmern 2 unterschiedliche Formate von CAN-Bus Nachrichten:

1. Standard-Frame-Format mit 11 Bit CAN Identifier 2. Extended-Frame-Format mit 29 Bit CAN Identifier

Abbildung 2 zeigt der Vollständigkeit halber den gesamten Telegramm-Aufbau beider Formate.

Abbildung 2: Standard CAN-Frame (oben) und Extended CAN-Frame (unten) [7]


5

Für die weiteren Betrachtungen sind aber lediglich die CAN-ID und das Data-Field von Interesse. Nur diese können von höheren Protokollschichten verändert, und gemäß ihrer Spezifikation genutzt werden. Die restlichen Bit- und Byte-Felder sind CAN-Basisprotokoll, das auf der untersten Hardware-Ebene, direkt vom CAN-Controller abgewickelt wird. Daher wird bei den weiteren Ausführungen nur noch der idealisierte CAN-Frame, bestehend aus CAN-ID und Daten-Feld betrachtet (vgl. Abbildung 3).

Abbildung 3: Idealisierter CAN-Frame

1.1.2 Adressierung SAE J1939 nutz ausschließlich das 29 Bit Identifier Format und unterteilt den CAN Identifier in unterschiedliche Felder, mit denen die Informationen zur Adressierung und zum Botschaftsinhalt (Data Field) übertragen werden. Die detaillierte Aufteilung eines J1939 CAN-Identifier zeigt Abbildung 4.

Abbildung 4: 29 Bit SAE J1939 CAN-Identifier [4]

Über die obersten 3 Bit des CAN-Identifier wird die Priorität der Botschaft codiert. Die unteren 8 Bit des CAN-Identifier geben die logische Adresse des Senders (Source Address SA) an. Den größten Teil des CAN-Identifier nimmt die sogenannte Parameter Group Number (PGN) ein. Sie bestimmt auch, welche Signale, oder allgemein Daten im Datenfeld übertragen werden. Der wichtigste Teil einer PGN ist das 8 Bit große PDU Format (PF) Feld, das zwischen einer verbindungsorientierten und einer nachrichtenorientierten Datenübertragung unterscheidet. Bei verbindungsorientierten, spezifischen Übertragungen (PDU 1 Format, 0-239) ist das Ziel der Botschaft ein einzelnes Steuergerät, dessen 8 Bit große Zieladresse (Destination Address DA) dann innerhalb des PDU-Specific Feldes übertragen wird. Bei nachrichtenorientierten, globalen Übertragungen (PDU 2 Format, 240-255) wird dagegen im Feld PDU Specific ein 8 Bit Wert (Group Extension GE) übertragen, der den Inhalt der Nutzdaten auf der Anwendungsebene Kennzeichnet [8]. Dieser Zusammenhang wird nochmals in Abbildung 5 dargestellt.


6

Abbildung 5: Aufbau der SAE J1939 CAN ID [8]

Mit den beiden Bits 24 und 25 steht eine Erweiterung für das Feld „PDU Format“ zur Verfügung, um so die Anzahl der möglichen Botschaften zu erhöhen. Bislang ist durch den Standard nur die Data Page 0 und 1 belegt (siehe Tabelle 1). Page 2 ist für zukünftige Entwicklungen im J1939 reserviert.

Tabelle 1: SAE J1939 Definition von Extended Data Page und Data Page [2]

Besondere Bedeutung kommt dem Fall zu, wenn Bit 24 und 25 mit 1 belegt sind (Page 3). In diesem Fall handelt es sich nicht um eine J1939 Nachricht, sondern um eine CAN Nachricht nach ISO 15765-3. Dazu aber später mehr.


7

Beispiel 1: Abbildung 6 zeigt ein praktisches Beispiel einer Nachricht im PDU 1 Format (Peer-to-Peer), wie sie in J1939 definiert ist.

Abbildung 6: Beispiel: PDU 1 Format – Peer-to-Peer (Destination Specific) Botschaft

Hinweis: Auch eine PDU 1 (Destination Specific) Nachricht kann man mit einer Übertragung an alle Teilnehmer versenden. Dafür ist die globale Adresse 255 reserviert. Beispiel 2: Abbildung 7 zeigt eine J1939 Nachricht im PDU 2 Format (Broadcast).

Abbildung 7: Beispiel: PDU 2 Format – Broadcast (Global) Botschaft

Auch wenn SAE J1939 nur CAN-Nachrichten mit 29 Bit Identifier verwendet, so ist trotzdem eine parallele Verwendung von 11 Bit denkbar und technisch machbar. 11 und 29 Bit Identifier


8

beeinflussen sich nicht. Um aber Interferenzen zwischen verschiedenen Geräten auch mit 11 Bit Identifier Kommunikation im J1939 Netzwerk zu vermeiden, gibt es im Dokument J1939/21 eine grundlegende Definition für den Aufbau des 11 Bit CAN-Identifier. Wie beim 29 Bit Identifier sind die oberen 3 Bit für die Priorität, und die unteren 8 Bit für die Source Address (SA) der sendenden Controller Application (CA) zu verwenden (siehe Abbildung 8)

Abbildung 8: SAE J1939 Definition von 11 Bit CAN-Identifier im Vergleich zur 29-Bit Definition

1.1.3 Transportprotokolle Wie in Abbildung 2 zu sehen, können mit einer einzelnen CAN-Botschaft maximal 8 Byte Nutz-Daten übertragen werden. Mit einem sogenannten Transportprotokoll ist es aber möglich, auch Datenblöcke zu übertragen, die größer als 8 Daten-Byte sind. Durch entsprechende, in SAE J1939 beschriebene Mechanismen, kann ein zu übertragender Datenblock von einem Sender aufgeteilt (Segmentierung), und als einzelne CAN-Botschaften gesendet werden. Der gewünschte Empfänger auf der anderen Seite empfängt diese einzelnen CAN-Botschaften und kann sie dann, durch Kenntnis der Transportprotokoll-Mechanismen, wieder zu einem Datenblock zusammensetzen und verwenden. SAE J1939 sieht bestimmte PGNs vor, mit denen diese segmentierte Datenübertragung abgebildet werden kann. Der Standard SAE J1939 definiert folgenden 2 Transportprotokolle:

• BAM (Broadcast Announce Message) für eine Broadcast Übertragung (nachrichtenorientiert an alle Busteilnehmer)

• CMDT (Connection Mode Data Transfer) für eine Peer-to-Peer Übertragung (verbindungsorientiert an einen Busteilnehmer)

Ein typisches Beispiel für die Anwendung eines Transportprotokolls ist z.B. die Übertragung von ganzen Parametersätzen oder Textinformationen wie z.B. der Soft- und Hardware-Version eines Steuergerätes.

1.1.4 Network Management Wird eine J1939 Nachricht von einer Controller Application auf dem CAN-Bus gesendet, so ist eine eindeutige Source Address fester Bestandteil des 29 Bit Identifier. Doch eine feste Adressvergabe ist gerade in herstellerübergreifenden oder flexiblen Netzwerken nicht immer sicherzustellen und kann daher zu Adresskonflikten führen. Den Sachverhalt soll ein kleines Beispiel veranschaulichen, in dem alle Controller Application eine feste Adresse haben.


9

Wird an den in Abbildung 9 gezeigten Lkw der Trailer 1 angehängt, so bilden die 2 Controller Application Engine und Transmission des Lkw mit der CA Brakes vom Trailer 1 ein gemeinsames Netzwerk, in dem jede Adresse nur einmal vorkommt. � Netzwerk ohne Adresskonflikt. Wird jetzt zusätzlich noch der zu Trailer 1 baugleiche Trailer 2 angehängt, so kommt es durch identische Adressen der Controller Application Brakes zum Adresskonflikt. Eine eindeutige Nachrichten-Kommunikation ist nicht mehr möglich. � Netzwerk mit Adresskonflikt

Abbildung 9: Vereinfachtes SAE J1939 Netzwerkbeispiel mit Adresskonflikt

Abhilfe bei einem solchen Adresskonflikt schafft das im J1939 standardisierte Network Management. Mit dem, auch als Address Claim Prozedur bezeichneten Verfahren ist es einer Controller Application durch dynamische Adressvergabe möglich, evtl. vorhandene Adresskonflikte zu lösen. Da die 8 Bit große (256 theoretisch mögliche Adressen), feste Adresse zur eindeutigen Kennzeichnung einer Controller Application nicht ausreicht, definiert J1939 für jede Controller Application einen 8 Byte langen, weltweit eindeutigen NAME.

Abbildung 10: J1939 NAME Felder der Address Claim PGN 60928 (0x00EE00) [7]

Wollen nun, wie in Abbildung 9 zu sehen 2 Controller Application die gleiche Adresse verwenden, tauschen sie zuvor dem gesamten Netzwerk ihren J1939 NAME und die gewünschte Adresse mit. Das Address Claim „gewinnt“ grundsätzlich die Controller Application, die den kleinsten NAME Wert besitzt. Dies CA kann seine gewünschte Adresse verwenden. Die andere, „unterlegene“ Controller Application muss durch ein erneutes Address Claim versuchen eine andere, noch freie Address zu finden. Ist das Address Claim abgeschlossen, kennt jede CA im Netzwerk alle anderen CA anhand der gesendeten NAME Informationen und weiß welche Adressen sie verwenden. Eine eindeutige, störungsfreie Kommunikation ist dann wieder möglich. Mögliche Adressen einer Controller Application:

• 0-253 Adressbereich für Controller Applications • 254 NULL Adresse einer Controller Application während des Anmeldeprozesses • 255 Broadcast Adresse; Peer-to-Peer Nachrichten, die an diese Adresse gesendet werden,

werden von allen CA im Netzwerk empfangen

Referent: Dipl.-Ing. (FH) Bruno Klöpper MBA

1.2 ISO 11783 (ISOBUS) Genau wie SAE J1939 ist auch ISO 11783, Protokoll. Wie schon gesagt ist es ein CANKommunikationsmechanismen von SAE J1939Netzwerkaufbau aus ISO11783-2.

Abbildung 11: ISO 11783-2:2002 Netzwerk

Auch hier, analog zu J1939, gibt es einen TractorAntriebsstrang), und für die herstellerübergreifende Kommunikation zwischen Traktor und Gerät den Implement-Bus. Dieser Zusammenhang zwischen TractorAbbildung 12 nochmal verdeutlicht.

Abbildung 12: ISOBUS Netzwerk Beispiel 1

Bruno Klöpper MBA | Vortrag: Netzwerk-Design

Genau wie SAE J1939 ist auch ISO 11783, man spricht auch vom ISOBUS, ein HighWie schon gesagt ist es ein CAN-Bus Protokoll

Kommunikationsmechanismen von SAE J1939. Abbildung 11 zeigt den grundlegende2.

2:2002 Netzwerk [3]

gibt es einen Tractor-Bus für die interne Kommunikation (z.B. erstellerübergreifende Kommunikation zwischen Traktor und Gerät

Dieser Zusammenhang zwischen Tractor-Bus und Implementnochmal verdeutlicht.

: ISOBUS Netzwerk Beispiel 1 – Tractor-Implement Kombination

10

ISOBUS, ein Higher-Level Bus Protokoll und nutzt die

zeigt den grundlegenden

Bus für die interne Kommunikation (z.B. erstellerübergreifende Kommunikation zwischen Traktor und Gerät

und Implement-Bus wird in


11

1.2.1 ISOBUS Applikationen (die verschieden Parts) Zusätzliche zu den aus SAE J1939 stammenden, und in die Normteile IOS11783-1 bis -5 übernommenen Kommunikationsmechanismen standardisiert ISOBUS eine Reihe weiterer Funktionen/Applikationen. Diese sind:

• VT Virtual Terminal (ISO11783-6) • TECU Tractor ECU (ISO 11783-7/8/9) • TC Task-Controller (ISO11783-10/11) • Diagnostic Diagnose (ISO 11783-12) • FS File-Server (ISO11783-13)

Virtual Terminal

Ein Virtual Terminal ist eine universelle Anzeige mit definierten Eigenschaften im Netzwerk. Ein im Netzwerk befindliches Steuergerät, z.B. vom Ladewagen aus Abbildung 12, kann zur Laufzeit alle die für die Bedienung der Maschinen nötigen grafischen Masken auf das vorhandenen VT hochladen. Über am Terminal vorhandene Softkeys ist dann auch eine Bedienung der Maschine möglich TECU

Die Tractor ECU stellt das Gateway zwischen dem herstellerübergreifenden Implement-Bus und dem internen Tractor-Bus dar. Die Funktionalität einer TECU wird durch den Standard in 3 Klassen unterteilt. Jede dieser Klassen definiert einen mindest Funktionsumfang. Je höher die Klasse einer TECU, desto mehr Informationen muss sie auf dem Implement-Bus zur Verfügung stellen. Ist es bei einer Klasse 1 TECU z.B. die Fahrgeschwindigkeit, so kommt bei einer Klasse 2 TECU noch die gefahrene Distanz und die Fahrtrichtung als Zusatzinformation hinzu. Handelt es sich um eine Klasse 3 TECU, so ist es mit entsprechenden CAN-Botschaften sogar möglich, vom Anbaugerät aus Einfluss auf Traktoraggregate wie z.B. der Hydraulik zu nehmen. Task-Controller

Die von Steuergeräten im Netzwerk zur Verfügung stehenden (Prozess-) Daten können vom TC auftragsbezogen geloggt und in einem durch ISO 11783-10 definiertem XML-Format abgelegt werden. Diese XML Dateien können dann nach Auftragsende z.B. auf einen USB-Stick übertragen, und mit einem standardkonformen Farm-Management-System zur Rechnungserstellung weiterverarbeitet werden. Doch der Datenstrom funktioniert auch in die andere Richtung. So ist es durch die Nutzung von GPS auch möglich, abhängig von der Position Einfluss auf die angeschlossenen Maschinen zu nehmen. Typisches Beispiel ist hier die Funktion Section-Control. Hat eine Maschine eine Teilfläche einer Arbeitsfläche bereits bearbeitet und fährt wieder in eine dieser Flächenbereiche ein, so können automatisch vom Task-Controller gesteuert einzelne Arbeitsvorgänge beendet, oder Arbeitsaggregate ausgehoben oder abgeschaltet werden (z.B. die einzelnen Düsen einer Feldspritze). Diagnostic

Im Part 12 von ISO11783 werden die Diagnose-Informationen und Diagnose-Funktionen beschrieben. Von SAE J1939/73 wurden bislang nur einfache Diagnose-Informationen, zum Teil leicht abgeändert übernommen und zusätzlich einige Neue hinzugefügt.


12

Die Bezeichnungen für die entsprechenden PGNs sind [3]: • ECU identification information • ECU software identification • ISOBUS certification • ECU ISO 11783 NAME • ECU diagnostic protocol • Active diagnostic trouble codes (DM1) • Previously active diagnostic trouble codes (DM2) • Diagnostic data clear/reset previously active DTCs (DM3)

Ein Off-Board Diagnose-Tool könnte an dem in ISO 11783-2 standardisierten Diagnose-Stecker (vgl. 19 in Abbildung 11) angeschlossen werden und die genannten Informationen für Diagnosezwecke aus den angeschlossenen Steuergeräten auslesen. File-Server

Der File-Server ist vergleichbar mit einer Netzwerkfestplatte in der EDV. Auch auf dem File-Server können in einer Ordnerstruktur Dateien in beliebigen Formaten abgelegt werden. Transportmedium ist hier nicht wie z.B. in der EDV das Ethernet, sondern der ISOBUS.

1.2.2 Transportprotokolle Zusätzlich zu den aus J1939 bekannten Transportprotokollen BAM und CMDT gibt es in ISO 11783 zwei zusätzliche Transportprotokolle:

• Extended Transport Protocol (ETP) für die Peer-to-Peer Übertragung (verbindungsorientiert an einen Busteilnehmer) von größeren Datenmengen

• Fast Packed Protokoll (NMEA 2000) für eine Broadcast Übertragung (nachrichtenorientiert an alle Busteilnehmer) von GPS Informationen.

Das ETP wurde entwickelt, um größere Datenmengen (z.B. Grafikinformationen) zum Virtual Terminal zu übertragen. Es wird aber auch für andere Anwendungszwecke benutzt, z.B. für die Datenübertragung an einen File-Server. Das „Fast Packed Protokoll“ wird für die Übertragung der aus dem maritimen NMEA 2000 Standard stammenden GPS Informationen verwendet.

2 ISO14229 (UDS) UDS (Unified Diagnostic Services) ist die konsequente Weiterentwicklung des K-Line basierten Diagnose-Protokolls KWP2000 (ISO 14230 Keyword Protocol 2000) und beschreibt den heute in der Fahrzeugtechnik aktuellen Stand der Diagnose-Kommunikation. Bei der Definition der UDS-Norm wurde großer Wert auf die Unabhängigkeit der Norm vom verwendeten Physical-Layer gelegt [9]. Es gibt entsprechende Zusatzdokumente, die die Anwendung von UDS auf dem jeweiligen Physical-Layer beschreiben. Im Fall von CAN als Physical-Layer sind dies die Dokumente von ISO 15765 „Diagnostic on Controller Area Network (CAN)“. Es gibt aber schon weitere Adaptionen, wie z.B. die in Zukunft immer wichtiger werdende Adaption von UDS auf Ethernet. Die entsprechenden Dokumente sind zurzeit noch bei der ISO in Bearbeitung. Der aktuelle Stand ist hier ISO/DIS 13400 „Diagnostic communication over Internet Protocol“ (DIS = Draft International Standard).


13

2.1 UDS Services Herzstück der Norm bilden die sogenannten Services. Jeder dieser UDS Service hat einen eindeutigen Wert (eine Art Multiplexer Wert), dem sogenannten Service Identifier (SID; 1 Byte). Er ist den optionalen Datenparametern einer Service-Anfrage vom Tester (Client) an ein Steuergerät (Server) in der Diagnose-Nachricht vorangestellt (vgl. Abbildung 13). Da die meisten Services nach dem Request-Response-Verfahren arbeiten, antwortet das Steuergerät im Response auf gleiche Art und Weise mit dem Wert SID + 40h im 1. Byte, gefolgt von den evtl. angefragten Datenparametern. Exemplarisch sind in Tabelle 2 einige typische UDS Service und ihre Verwendung aufgeführt. Es soll dazu dienen, einen kleinen Einblick in die Möglichkeiten von UDS zu geben.

Tabelle 2: Auswahl an UDS Services [8]

Service (ID) Verwendung

WriteDataByIdentifier (0x2E) Für das Schreiben von Werten (Einzel oder Datensätze) in den Speicher einer ECU.

ReadDataByIdentifier (0x22) Für das Auslesen von Werten (Einzel oder Datensätze) aus dem Speicher einer ECU

InputOutputControlByIdentifier (0x2F) Für das Überschreiben eines Steuergeräte-Eingangs oder Direktansteuerung eines Steuergeräte-Ausgangs.

ReadScalingDataByIdentifier (0x24) Für das Auslesen von Skalierungs- und Normierungsinformationen von Einzelwerten oder Datensätzen (vgl. Read-/Write-DataByIdentifier oder InputOutputControlByIdentifier)

RequestDownload (0x34) Für die Initialisierung der Übertragung von größeren Datenblöcken vom Diagnose-Tester zur ECU

TransferData (0x36) Für die eigentliche Übertragung der Datenblöcke DiagnosticSessionControl (0x10) Für das Starten einer Diagnosesitzung, z.B. Default Session,

Programming Session, Extended Diagnostic Session, … SecurityAccess (0x27) Für die Freischaltung geschützter Funktionen bzw. Services TesterPresent (0x3E) Für die Aufrechterhaltung einer Diagnose-Session, Diagnose-Tester

Life-Signal …

2.2 Transportprotokoll ISO TP Ist eine Diagnose-Botschaft länger als 7 Byte (z.B. beim Schreiben eines Datensatzes mit WriteDataByIdentifier), so passt diese nicht mehr in einen einzelnen CAN-Frame. Es kommt dann, wie bei SAE J1939 oder ISO 11783 Nachrichten ein Transportprotokoll zum Einsatz. Für UDS Botschaften ist es das sogenannte ISO TP, das in ISO 15765 beschrieben ist. Der Unterschied zu den aus SAE J1939 und ISO 11783 bekannten Transport-Protollen ist aber, dass es für ISO TP keine speziellen CAN Identifier gibt. Die evtl. nötige Transportprotokollsteuerung erfolgt durch das 1-3 Byte lange PCI-Feld (PCI=Protocol Control Information), das jeder Diagnose-Botschaft vorangestellt ist. Das PCI-Feld ist wie die Diagnose-Botschaft selbst, fester Bestandteil des Daten-Feldes eines UDS CAN-Frames. Den schematischen Aufbau zeigt Abbildung 13.


14

Abbildung 13: Diagnose-Nachricht im CAN-Frame [9]

2.3 Adressierung Wie bei J1939/ISO11783 gibt es auch bei der Diagnose-Kommunikation eine eigene Möglichkeit eine Nachricht an alle (Broadcast) oder nur an einen bestimmten Busteilnehmer zu senden. Unter

• Funktionale-Adressierung wird die Übertragung einer Diagnose-Botschaft an alle Busteilnehmer (Broadcast oder nachrichtenorientiert) bezeichnet, und unter

• Physikalische-Adressierung wird die zielgerichtete Übertragung einer Diagnose-Botschaft an einen einzelnen Busteilnehmer (Peer-to-Peer oder verbindungsorientiert) bezeichnet

2.4 Identifier Prinzipiell lässt sich UDS in einem J1939 oder ISO11783 Netzwerk auf 3 unterschiedliche Art und Weisen realisieren. Alle haben Auswirkung auf den zu verwendenden CAN-Identifier.

1. UDS mit 29 Bit CAN Identifier a. UDS im J1939/ISO11783 über dafür definierte PGNs b. UDS parallel zum J1939/ISO11783 mit eigenem Adressraum

2. UDS mit 11 Bit CAN Identifier

2.4.1 UDS mit 29 Bit CAN Identifier – Im J1939/ISO11783 Adressraum Die Integration von UDS im Adressraum vom J1939/ISO11783 stellt die idealste Form dar, da auch hier, die für eine herstellerübergreifende Lösung nötige, dynamische Adressvergabe zur Verfügung steht. Für die Integration von UDS, bzw. ISO15765 im J1939/ISO11783 Adressraum sind entsprechende PGNs der Data Page 0 fest reserviert. Dies ist für

• Functional-Addressing (Broadcast) die PGN 0x00DB00 (55809) und für • Physical-Addressing (Peer-to-Peer) die PGN 0x00DA00 (55808).

Die Aufteilung des CAN-Identifier entspricht der aus Abbildung 4. Mit den beiden gezeigten PGNs ist das sogenannte „Normal-fixed-Addressing“ realisierbar, bei dem die gesamte Adressinformation im CAN-Identifier abgebildet wird. Diese Methode wird in den meisten Fällen sicherlich auch ausreichend sein. Theoretisch könnte man auch die „Mixed-Addressing“ Methode anwenden, bei der das 1. Byte vom Daten-Feld der CAN-Nachricht zusätzliche Adressierungsmöglichkeiten bieten würde. Auch für diese Art der Realisierung sind eigene PGNs definiert. Weitere Informationen dazu finden sich in ISO15765-2.

2.4.2 UDS mit 29 Bit CAN Identifier – Parallel zum J1939/ISO11783 im eigenen

Adressraum Will man UDS mit 29 Bit CAN Identifier, aber nicht im J1939/ISO11783 Adressbereich realisieren, so steht hierfür eine 2. Möglichkeit zur Verfügung. ISO15765-3 definiert hier eine


15

eigene Adressierungsmethode, die zur J1939/ISO11783-Methode an Hand der zwei Bits „ExtendedDataPage“ und „DataPage“ unterschieden werden kann. Beide Bits sind bei der Realisierung gemäß ISO 15765-3 mit 1 gesetzt (vgl. Tabelle 1). Die detaillierte Aufteilung des 29 Bit CAN Identifier zeigt Abbildung 14.

Abbildung 14: UDS mit 29 Bit CAN Identifier – Parallel zu J1939/ISO11783 im eigenen Adressraum [4]

Mit dieser Art der Realisierung verliert man aber den durch J1939 oder ISO11783 gewonnenen Vorteil der herstellerübergreifenden, dynamischen Adressvergabe. Auf Grund möglicher Adresskonflikte sollte zumindest in herstellerübergreifenden Netzwerken, wie z.B. dem ISOBUS, auf eine derartige Realisierung verzichtet werden. Näherer Information finden sich in ISO 15765-3.

2.4.3 UDS mit 11 Bit CAN Identifier Als 3. Möglichkeit der UDS Realisierung in einem J1939/ISO11783 Netzwerk bleibt die Realisierung mit 11 Bit CAN-Identifier, da bekanntermaßen CAN-Bus Nachrichten mit 11 und 29 Bit Identifier sich in ein und demselben Netzwerk gegenseitig nicht beeinflussen. Es müssen nur die in Abschnitt 1.1.1 schon benannten Designrichtlinien für 11 Bit CAN-Identifier im J1939/ISO 11783 Netzwerk beachtet werden. Da im 11 Bit CAN-Identifier nur die 3 Bit für die Priorität, sowie die 8 Bit der Source-Address (SA) abgebildet werden können, muss für die Realisierung der UDS Diagnose die Mixed-Addressing-Methode angewendet werden. Mit dieser Methode ist es dann möglich, die für eine eindeutige Adressierung einer Diagnose-Nachricht nötige Destination-Address (DA) im 1. Byte des Daten-Feldes abzubilden. Eine schematische Aufteilung des CAN-Frames kann Abbildung 15 entnommen werden.

Abbildung 15: UDS mit 11 Bit CAN Identifier – Parallel zu J1939/ISO11783 im eigenen Adressraum [9]

Für die Diagnose-Kommunikation im ISOBUS Netzwerk ist aber auch diese Methode wenig geeignet. Auch bei dieser Methode ist eine herstellerübergreifende ID-Vergabe bzw. Verwendung nicht eindeutig geregelt. Ein weiterer zu beachtender Punkt ist, dass bei dieser Art der Realisierung der 11 Bit Identifier einer Controller Application (CA) dann ausschließlich für die Diagnose Kommunikation vergeben ist und anderweitig nicht mehr genutzt werden kann.


3 Zusammenfassung – Potential und Möglichkeiten

3.1 Zusammenspiel der NormenWie in den vorangegangenen Abschnitten gezeigt, bauen die Standards aufeinanderwie SAE J1939 und ISO 1178Mechanismen. Dies wird durch Abbildung

Abbildung 16: UDS und J1939 / ISO 11783

Jedes der gezeigten Protokolle hat ein oder mehrere Transportprotolle, die für die verschiedenen Anwendungsfälle zur Verfügung stehen um NachrichtDie zu übertragende Nachricht wird segmentiert und auf entsprechend vielBotschaften aufgeteilt. Eine Zusammenfassung aller durch J1939, ISO11783 und ISO14229 (ISO15765) zur Verfügung stehenden Standard

Tabelle 3: Standard Transportprotokolle

Transportprotokoll

BAM Broadcast Announce Message CMDT Connection Mode Data TransferETP Extended Transport Protocol Fast Packed Protokoll ISO TP

Auch wenn sich alle Transportprotokolle unterscheidenAlle können den gleichen, durch den 29 Bit CANverwenden. Und das mit der Möglichkeitzwingende Voraussetzung für eine störungsfreie, herstellerübergreifende Kommunikation


Potential und Möglichkeiten

Zusammenspiel der Normen Wie in den vorangegangenen Abschnitten gezeigt, bauen die Standards aufeinanderwie SAE J1939 und ISO 11783 harmonisiert und nutzen die gleichen Kommunikations

Abbildung 16 nochmals verdeutlicht.

UDS und J1939 / ISO 11783 – Die verschiedenen, aufeinander aufbauenden Norm

der gezeigten Protokolle hat ein oder mehrere Transportprotolle, die für die verschiedenen Anwendungsfälle zur Verfügung stehen um Nachrichten mit mehr als 8 Nutzdaten zu übertragen.Die zu übertragende Nachricht wird segmentiert und auf entsprechend viel

Eine Zusammenfassung aller durch J1939, ISO11783 und ISO14229 (ISO15765) zur Verfügung stehenden Standard-Transportprotokolle findet sich in

: Standard Transportprotokolle

SAE J1939 NMEA2000 ISO 11783 (ISO 14229)

X X Connection Mode Data Transfer X X

X X X

Auch wenn sich alle Transportprotokolle unterscheiden, so haben sie dennoch einsgleichen, durch den 29 Bit CAN-Identifier gegebenen Adressierungsmechanism

Möglichkeit einer dynamischen Adressvergabe. zwingende Voraussetzung für eine störungsfreie, herstellerübergreifende Kommunikation

16

Wie in den vorangegangenen Abschnitten gezeigt, bauen die Standards aufeinander auf, oder sind 3 harmonisiert und nutzen die gleichen Kommunikations-

Norm-Teile

der gezeigten Protokolle hat ein oder mehrere Transportprotolle, die für die verschiedenen mehr als 8 Nutzdaten zu übertragen.

Die zu übertragende Nachricht wird segmentiert und auf entsprechend viele, einzelne CAN-Eine Zusammenfassung aller durch J1939, ISO11783 und ISO14229

Transportprotokolle findet sich in Tabelle 3.

ISO 15765

(ISO 14229)

X

haben sie dennoch eins gemeinsam. Adressierungsmechanismus

Adressvergabe. Gerade dies ist zwingende Voraussetzung für eine störungsfreie, herstellerübergreifende Kommunikation, wie sie


z.B. im ISOBUS nötig ist. Dies sondern auch die erweiterte, möglicheTester und einzelnen Steuergeräten im Netzwerk

3.2 ISOBUS auch im AntriebsstrangDie beispielhafte Traktor-Gerähäufigsten Anwendungsfall von ISOBUS.störungsfreie, herstellerübergreifende Kommunikation zwischen den Gerätedem Virtual Terminal von Hersteller A Doch auch die Norm geht hier schon einen Schritt weiter. Zwar ist auch nach Norm das

Netzwerkdesign des internen TraktorMaschinenherstellers und muss nicht den Anforderungen aus ISO11783 genügeempfohlen auch hier die gleichen Kommunikationsmechanismen zu verwendensich die Verwendung von ISOBUS nicht nur auf den internen Bus eines Begriff Traktor, gemäß ISO 11783landwirtschaftliche ArbeitsmaschineFeldhäckslers (vgl. Abbildung 17Es sprechen viele Argumente für die Verwendung der aber auch einige dagegen. Im Folgenden seien mal einige Vor Pro

++++ Über die letzten Jahre immer weiter ausgereifte Technologie++++ Kommunikations-Stacks ++++ Qualitätssicherung auch durch externe Zertifizierungsstelle(n) möglich++++ Einheitliche Kommunikatio++++ Geringere Einarbeitungszeit für neue Mitarbeiter++++ Einheitlicher Diagnose-Tool

Abbildung 17: ISOBUS Netzwerk Beispiel 2


ies betrifft nicht nur die Normal-Kommunikation gemäß ISO11783, , mögliche UDS Diagnose-Kommunikation zwischen

ten im Netzwerk.

im Antriebsstrang Geräte-Kombination aus Abbildung 12 zeigt

Anwendungsfall von ISOBUS. Die Definitionen aus ISO 11783 sind hier nötig, um eine störungsfreie, herstellerübergreifende Kommunikation zwischen den Geräte

von Hersteller A und dem Anbaugerät von Hersteller BDoch auch die Norm geht hier schon einen Schritt weiter. Zwar ist auch nach Norm das

Netzwerkdesign des internen Traktor-Busses in der alleinigen Maschinenherstellers und muss nicht den Anforderungen aus ISO11783 genüge

auch hier die gleichen Kommunikationsmechanismen zu verwendensich die Verwendung von ISOBUS nicht nur auf den internen Bus eines

gemäß ISO 11783, steht ebenfalls als Synonym für jede Art von selbstfahrende, landwirtschaftliche Arbeitsmaschine. Damit sind also z.B. auch die internen CAN

17) gemeint. für die Verwendung der ISO11783 Kommunikationsmechanismen

Im Folgenden seien mal einige Vor- und Nachteile aufgeführt:

Über die letzten Jahre immer weiter ausgereifte Technologie sind von verschiedene Anbietern am Mark verfügbardurch externe Zertifizierungsstelle(n) möglich

Einheitliche Kommunikationstechnologie auf allen Netzwerken Geringere Einarbeitungszeit für neue Mitarbeiter

Tool Einsatz auf Implement- und Tractor-Bus

Beispiel 2 – Selbstfahrende Arbeitsmaschine BiG X

17

ation gemäß ISO11783, Kommunikation zwischen einem Diagnose-

zeigt sicherlich den heute Die Definitionen aus ISO 11783 sind hier nötig, um eine

störungsfreie, herstellerübergreifende Kommunikation zwischen den Geräten, wie z.B. zwischen dem Anbaugerät von Hersteller B zu gewährleisten.

Doch auch die Norm geht hier schon einen Schritt weiter. Zwar ist auch nach Norm das

alleinigen Verantwortung des Maschinenherstellers und muss nicht den Anforderungen aus ISO11783 genügen, es wird aber

auch hier die gleichen Kommunikationsmechanismen zu verwenden [3]. Auch begrenzt sich die Verwendung von ISOBUS nicht nur auf den internen Bus eines Traktors alleine. Der

als Synonym für jede Art von selbstfahrende, . Damit sind also z.B. auch die internen CAN-Netzwerke eines

Kommunikationsmechanismen, Nachteile aufgeführt:

n am Mark verfügbar durch externe Zertifizierungsstelle(n) möglich


18

++++ Langfristige Investitionssicherheit durch die Verwendung von Standards ++++ Die in ISO11783 schon definierten und zukünftigen neuen Applikationen/Funktionen (wie

z.B. File-Server) können auch in den internen Netzwerken genutzt werden ++++ Geringerer Implementierungsaufwand bei Systemlieferanten, da eine nötige Anpassung auf

proprietäre Kommunikationsmechanismen der Kunden entfällt ++++ Vereinfacht/steigert die Kooperationsmöglichkeit bei der Entwicklung von

Systemkomponenten (z.B. Lenksystem, Antrieb, …) ++++ Erhöht die Austauschbarkeit von Systemkomponenten ++++ …

Kontra

−−−− 29 Bit Identifier Kommunikation erzeugt im Vergleich zur 11 Bit Kommunikation etwas höhere Bus-Last auf Grund von Protokoll Overhead

−−−− Erhöhter Migrationsaufwand für bestehende Applikationen/Steuergeräte, die bislang noch keine J1939 bzw. ISOBUS Kommunikationsmechanismen nutzen

−−−− … Wie man sieht gibt es einige bedeutende Vorteile. Daher macht es bei Neuentwicklungen auf jeden Fall Sinn, bei der Festlegung der Normal-Kommunikation auch über die durchgängige Verwendung der J1939 bzw. ISOBUS Kommunikationsmechanismen in den internen Fahrzeug-Bussen, wie z.B. dem Antriebsstrang nachzudenken.

3.3 ISO 14229 (UDS) im ISOBUS Netzwerk Die Normal-Kommunikation und einfache Onboard-Diagnose können heute mit ISO11783 abgebildet werden. Geht es aber um erweiterte Diagnose-Funktionalitäten, z.B. für die Re-Programmierung und Konfiguration von Steuergeräten, so benötigt man zusätzliche Mechanismen. ISO 14229-1 (UDS) oder SAE J1939/73 beschreiben entsprechende, erweiterte Diagnose-Mechanismen, die im herstellerübergreifenden ISOBUS oder in den internen Netzwerken verwendet werden können. Zwar bietet SAE J1939 prinzipiell sehr ähnliche Funktionalitäten wie UDS, doch es sprechen viele Argumente für die Verwendung von UDS. Erst recht dann, wenn erweiterte J1939 Diagnose-Funktionalität bisher auch noch nicht zur Verfügung stehen oder verwendet werden. Pro

++++ UDS ist im Vergleich zu SAE J1939 der umfangreichere und detailliertere Standard (z.B. Re-Programmierung von Steuergeräten)

++++ UDS ist Physical-Layer unabhängig; daher beim Wechsel des Bussystems (z.B. in Zukunft Ethernet) Wiederverwendung der UDS-Anteile in der Tester- und ECU-Software möglich

++++ ISO 27145 World-Wide Harmonized On- Board Diagnostics (WWH-OBD) referenziert UDS als Diagnose-Protokoll

++++ Die Beschreibung des UDS-Protokolls ist im Datenaustauschformat ODX möglich ++++ Auch UDS wird heute schon in ISO 11783-12 referenziert ++++ UDS Technologie ist auf Diagnose-Tester Seite schon oft vorhanden (z.B. für die Diagnose

von Diesel-Motoren) ++++ UDS wird von am Markt befindlichen Entwicklungswerkzeugen komfortabel unterstützt ++++ Systematische Trennung von Normal- und Diagnose-Kommunikation ++++ …


19

Kontra

−−−− Einführung eines zusätzlichen Transportprotokolls (ISO TP) −−−− …

Die gezeigten Normen greifen wie die Zahnräder eines Getriebes ineinander und bieten ein kraftvolles Gesamtpaket nützlicher Funktionen. Und dies nicht nur im herstellerübergreifenden Implement-Bus, sondern auch auf internen Netzwerken, wie z.B. dem Antriebsstrang. Sowohl Hersteller von mobilen Arbeitsmaschinen, wie auch Systemlieferanten können von den Vorteilen der zur Verfügung stehenden Normen langfristig profitieren. Sie müssen nur umgesetzt werden!

Abbildung 18: Die Normen greifen wie Zahnräder eines Getriebes ineinander


20

Literaturverzeichnis [1] ISO 11898: Road vehicles – Controller area network (CAN) [2] SAE J1939: Surface vehicle recommended practice [3] ISO 11783: Tractors and machinery for agriculture and forestry – Serial control and

communications data network [4] ISO 15765: Road vehicles – Diagnostics on Controller Area Networks (CAN) [5] ISO 14229: Road vehicles – Unified diagnostic services (UDS) [6] ISO 27145: Road vehicles – Implementation of World-Wide Harmonized On-Board

Diagnostics (WWH-OBD) communication requirements [7] Voss, W.: »A Comprehensible Guide to J1939«, Massachusetts (US): Copperhill Media

Corporation, 2008 [8] Zimmermann W., Schmidgall R.: »Bussysteme in der Fahrzeugtechnik«, Wiesbaden:

Vieweg+Teubner 2008 [9] Marscholik Chr., Subke P.: »Datenkommunikation im Automobil«, Heidelberg: Hüthig

Verlag 2007

VDI Vortrag - Getriebe in mobilen Arbeitsmaschinen 2011 ... · PDF fileJ1939 und haben zum...

Documents

Transcript of VDI Vortrag - Getriebe in mobilen Arbeitsmaschinen 2011 ... · PDF fileJ1939 und haben zum...