Lösungen für Ihre SAE J1939-Vernetzung
SAE J1939 ist der offene Standard für die Vernetzung und Kommunikation im Nutzfahrzeugbereich. Schwerpunkt der Anwendung ist die Vernetzung des Antriebsstrangs.
Charakteristisch für J1939 ist die Verwendung der CAN-Technologie zur Vernetzung und Kommunikation sowie eine herstellerübergreifende Interoperabilität. Das Protokoll J1939 stammt von der internationalen Society of Automotive Engineers (SAE) und arbeitet auf dem Physical Layer mit CAN-Highspeed nach ISO11898.
Steckbrief
- Benutzt den 29 Bit Extended CAN Identifier
- Standardisierte CAN-Baudraten von 250 kBit/s und 500 kBit/s
- Verfügt über Punkt-zu-Punkt-Adressierung (Knotenadressierung) und Globaler Adressierung (Botschaftsadressierung)
- Mit Multipaketnachrichten sind bis zu 1785 Bytes übertragbar
- Buszugriffskontrolle über eigenes Netzwerkmanagement
- Standardisierte Nachrichten für die gesamte Fahrzeugkommunikation
- Lässt herstellerspezifische Nachrichtendefinition zu
- Definiert eigene Diagnoseschnittstelle
SAE J1939 und CAN
Das SAE J1939-Protokoll verwendet CAN (Controller Area Network, ISO 11998-1 und ISO 11998-2) als physikalische Übertragungsschicht. Das CAN-Protokoll spielt in der Kraftfahrzeugvernetzung eine große Rolle und stellt eine gängige Methode zur bitseriellen Kommunikation zwischen Steuergeräten (Electronic Control Unit - ECU) dar. Typische Steuergeräte sind beispielsweise: Motor-, Getriebe-, oder das Bremssteuergerät aber auch das Kombiinstrument oder die Türsteuergeräte.
Konsortium und weitere Spezifikationen
Es existieren etliche Standards, welche vom SAE J1939-Standard abgeleitet sind. Diese Standards benutzen die Basisbeschreibung von J1939 und unterscheiden sich meist nur durch ihre unterschiedliche Datendefinition und ggf. durch Anpassungen des Physical Layers.
ISO 11783 – Tractors and machinery for agriculture and forestry – Serial control and communication
Definiert die Kommunikation in landwirtschaftlich genutzten Fahrzeugen. Ganz speziell hierbei zwischen Traktor und Anbaugerät, dem sogenannten Implement. Der ISO 11783-Standard spezifiziert Dienste auf Anwendungsebene, zum Beispiel die Steuerung eines Anbaugeräts über ein Virtual Terminal. Hierbei bringt das Anbaugerät selbst, alle für seine Steuerung notwendigen grafischen Elemente mit, welche das Virtual Terminal darstellen kann. Weitere Applikationskomponenten sind: Tractor ECU, Task Controller, File Server und Sequence Control. Der ISO 11783-Standard verfügt über eine Erweiterung des bei SAE J1939 definierten Multipaketprotokolls; ebenso wird der Working Set Mechanismus angewandt.
NMEA 2000® – Serial-data networking of marine electronic devices
Definiert die Steuergeräte-Kommunikation zwischen Fahrzeugen im maritimen Umfeld. Auch hier wird eine Erweiterung der Multipaketprotokolle verwendet, das sogenannte Fast Packet Protokoll.
ISO 11992 – Interchange of digital information between towing and towed vehicle
Spezifiziert den Nachrichtenaustausch von Straßenfahrzeugen zwischen Zugmaschine und Anhänger. ISO 11992 basiert auf dem Nachrichtenformat von J1939 nutzt jedoch eine andere Konfiguration des Physical Layer, nämlich nur 125 kBit/s.
FMS – Fleet Management System
Der FMS-Standard definiert ein Gateway zwischen einem J1939-Netzwerk und dem FMS.
Dokumentenstruktur J1939
Die komplette J1939-Spezifikation ist in verschiedene Dokumente und Kapitel unterteilt. Alle Dokumente können einzeln oder auch in konfektionierten Paketen von der SAE-Webseite heruntergeladen werden: www.sae.org.
Die einzelnen Kapitel der J1939-Spezifikation sind kostenpflichtig und daher nicht frei zugänglich. Die einzelnen Kapitel sind systematisch aufgebaut und grob an das ISO/OSI-Referenzmodel angelehnt. Angelehnt nur deshalb, weil es in der Dokumentenstruktur von J1939 eine Kapitelnummer 8 gibt, welche im OSI-Modell nicht definiert ist.
In der Tabelle rechts werden die aktuell existierenden Kapitel und Dokumente aufgeführt.
Physical Layer
Physical Layer Comparison
| Parameter | J1939-11 | J1939-15 | J1939-14 |
|---|---|---|---|
Twisted Pair Wire | Shielded | Unshielded | Shielded or Unshielded |
Bit Rate | 250 kbit/s | 250 kbit/s | 500 kbit/s |
| Number of ECUs | 30 | 10 | 30 |
Bus Length | Max: 40 m | Max: 40 m | Max: 40.0 m – 56.4 m |
ECU Distance | Min: 0.1 m | Max: 40 m | Min: 0.1 m | Max: 40 m | Min: 0.3 m | Max: 40.0 m – 56.4 m |
Stub Length | Max: 1 m | Max: 3 m | Max: 1,67 m |
Diagnostic Stub Length | Max: 0.66 m + 5 m | Max: 2.66 m + 5 m | Max: 1.67 m + 5 m |
Parametergruppe
Im Dokument J1939-21 ist definiert nach welchem Schema der 29-Bit-CAN-Identifier interpretiert werden muss. Ähnlich wie beim 8-Byte-Datenfeld einer CAN-Nachricht, in dem verschiedene Signale durch Startbit und Länge definiert werden, wird bei einer Parametergruppe der CAN-Identifier in verschiedene Segmente unterteilt. Dabei stellt nur ein Teil des Identifier die eigentliche PGN dar, der Rest wird als Quelladresse, Zieladresse, Priorität und Data Page (DP) interpretiert.
PGN Bereiche
Die beiden Bits „Data Page“ (DP) und „Extended Data Page“ (EDP) sind ebenfalls Bestandteil der PGN und werden als die beiden höchstwertigen Bits mitgezählt. Der Zahlenbereich wird dadurch in vier PGN Seiten eingeteilt, wobei für J1939 nur 3 genutzt werden.
Folgende Data Page Definitionen gibt es:
| Extended Data Page (EDP) | Data Page (DP) | Beschreibung |
|---|---|---|
| 0 | 0 | SAE J1939 und ISO 11783 |
| 0 | 1 | SAE J1939 NMEA 2000® |
| 1 | 0 | SAE J1939 – reserviert – |
| 1 | 1 | ISO 11992 Diagnose (Achtung: Kein J1939-Layout!) |
Transportprotokoll
Nachrichten mit einer Länge von mehr als 8 Bytes sind zu groß, um in einen einzigen CAN-Datenrahmen zu passen. Daher müssen sie vom Sender in einzelne Pakete aufgeteilt werden, die dann jeweils mit einer CAN-Nachricht gesendet werden können. Der Empfänger muss die einzelnen Fragmente wieder in der ursprünglichen Reihenfolge zusammensetzen. Dafür ist im J1939-Standard ein Regelwerk definiert: ein sogenanntes Transportprotokoll.
Es sind, den Kommunikationsarten entsprechend, zwei Transportprotokolle definiert.
Spezifische Kommunikation – Connection Mode Data Transfer (RTS/CTS)
Bei diesem Protokoll baut der Sender mit dem Empfänger eine Verbindung (Connection) auf. Der Empfänger hat die Möglichkeit die Flusskontrolle der einzelnen Datenpakete zu steuern und zu beeinflussen. Beide Seiten, Empfänger und Sender, können die Verbindung (z.B. im Fehlerfall) abbrechen.
Das Protokoll Connection Mode Data Transfer unterliegt keiner zeitlichen Limitierung. Alle Teilnehmer tauschen ihre Daten potentiell in der maximalen Geschwindigkeit ihrer Möglichkeiten untereinander aus.
Globale Kommunikation – Broadcast Announce Message (BAM)
Der Sender alleine steuert die Flusskontrolle. Die Nachricht wird immer an alle Knoten gesendet. Ein Empfänger kann nicht in die Kommunikation eingreifen. Wird eine Nachricht verpasst, kann der Empfänger dies nicht signalisieren. Er muss gegebenenfalls auf eine neue Nachricht warten.
Da beim BAM-Protokoll der Empfänger keine Möglichkeit hat, die Flusskontrolle zu steuern, muss der Sender einen zeitlichen Mindestabstand zwischen den einzelnen Paketen einräumen. Dieser beträgt 50-200 ms. Damit wird Rücksicht auf eventuell langsame Netzknoten genommen.
Diagnose
Die J1939-Diagnoseschnittstelle definiert einen Standard-Diagnosestecker so wie eine Sammlung von PGNs zur Abwicklung von unterschiedlichen Diagnosediensten. Die als Diagnostic Message (DM) bezeichneten PGNs erfüllen weitgehend den Funktionsumfang der UDS-Diagnose (Unified Diagnostic Service). Sie entspricht ebenso den Richtlinien der EU oder dem „California Code of Regulation“ für Onboard Diagnostics (OBD II), sowie HD OBD (Heavy Duty OBD) und WWH (World Wide Harmonized) OBD (ISO 27145).
Im Gegensatz zur UDS-Diagnose, bei der die Dienste aktiv über ein Softwarewerkzeug angestoßen werden müssen, senden J1939-ECUs auch selbständig Diagnosenachrichten während dem Standardbetrieb. Auftretende Fehler werden direkt im Netzwerk ausgewertet und gegebenenfalls optisch angezeigt. Parallel hierzu können sie mit einem Werkzeug über die Diagnosesteckdose ausgelesen werden. Einheitliche Fehlercodes, sogenannte Diagnostic Trouble Codes (DTC), beinhalten die fehlerhafte SPN, das Fehlerbild und die Häufigkeit des Auftretens eines Fehlers.
Diagnostic Trouble Code (DTC)
Ein DTC (Diagnostic Trouble Code) repräsentiert eine fehlerhafte Eigenschaft im System. Er repräsentiert in erster Linie eine SPN welche sich in einem abnormalen Zustand befindet. Dies kann unterschiedliche Ursachen haben. Über einen Indikator, der den Grund des Zustands angibt, wird versucht, die eigentliche Fehlerursache einzugrenzen. Ein DTC hat einen einheitlichen Aufbau und besteht aus den folgenden Elementen:
- Suspect Parameter Number (SPN)
Repräsentiert die fehlerbehaftete SPN. Jede definierte SPN kann in einem DTC verwendet werden. - Failure Mode Identifier (FMI)
Stellt die Art und den Typ eines aufgetretenen Fehlers dar, z.B. Über- oder Unterschreiten von Wertebereichen, Kurzschlüsse am Sensor, falsche Update-Rate oder Kalibrierungsfehler. - Occurrence Counter (OC)
Ein Zähler welcher das Auftreten des Fehlerzustands für jede SPN zählt und diese abspeichert, auch wenn der Fehler nicht mehr aktiv ist. - SPN Conversion Method (CM)
Definiert die Byte-Ausrichtung innerhalb des DTC. Dabei repräsentiert der Wert „0“ die in der Grafik „Aufbau eines DTC“ dargestellte Methode. Hat CM den Wert „1“, muss zwischen drei früher gültigen Methoden unterschieden werden; dies muss für das System bekannt sein.
J1939 Poster
J1939-Protokoll auf einen Blick
Mit dieser Schnellübersicht im DIN-Format A1 (841 mm x 594 mm) haben Sie die wichtigsten Grundlagen des J1939-Protokolls immer vor Augen. Bestellen Sie sich jetzt Ihren eigenen Spickzettel mit detaillierten Informationen zu folgenden Themengebieten:
Specification Documents | Physical Layer | Frame Structure | Transport Protocols | Request Handling | Diagnostic | Network Management
Vector - Der Spezialist für J1939
Vector Informatik ist Mitglied in SAE J1939-Ausschüssen und nimmt regelmäßig an den Arbeitstreffen teil. Durch das große Know-How und die langjährige Erfahrung von Vector im J1939-Umfeld profitieren Sie von leistungsstarken Produkten und Dienstleistungen, mit deren Hilfe Sie Ihre anspruchsvollen Aufgaben effizient, schnell und kostengünstig lösen.
Mit einer durchgängigen Werkzeugkette für alle J1939-Vorhaben hat Vector die für Sie passende Lösung:
- perfekt abgestimmte Software-Tools
- maßgeschneiderte Embedded-Software-Komponenten
- individuellen Service und speziell auf Ihre Bedürfnisse abgestimmte Schulungen
Vector Tools
Die folgenden Produkte von Vector unterstützen Sie bei Ihren J1939-Projekten:
Tools | ||
|---|---|---|
Modellbasierter Entwurf von E/E-Systemen nach den Anforderungen von SAE J1939 und ISOBUS 11783:
| ||
Simulation, Test und Entwicklung von J1939-Systemen:
| ||
Analyse von J1939-Systemen:
| ||
Embedded-Softwarekomponenten für J1939-Anwendungen | ||
Verwendung von Applikationen in CAN-, SAE J1939- und SAE J1708/J1587-Netzwerken | ||
Treibersoftware für DIAdem: unterstützt das J1939-Protokoll sowie NMEA2000 und ISOBUS (ISO11783) | ||
Schnell und äußerst einfach zu bedienender Diagnosetester für einzelne Steuergeräte oder das ganze Nutzfahrzeug | ||
Workshops zu den Grundlagen von SAE J1939 & Einführung in CANoe/CANalyzer .J1939 | ||
Zusätzliche Informationen
-
2014-11-03 Application NoteAN-AND-1-160 Introduction to Higher Level Protocols
-
2014-11-03 Application NoteAN-ION-1-3100 Introduction to J1939
-
2012-04-12 Application NoteAN-ION-1-0103 Protocol Selection Guide
-
2018-08-10 FachartikelTechnische Fachartikel zur Entwicklung von Embedded Electronics
-
2015-11-13 FachartikelNeue Chancen mit AUTOSAR
-
2013-10-11 FachartikelAUTOSAR im Nutzfahrzeug - Integration von J1939 in AUTOSAR
-
2013-06-06 FachartikelVom Ingenieur für den Ingenieur (Interview mit den Geschäftsführern der Vector Informatik GmbH)
-
2010-12-06 FachartikelQuo Vadis SAE J1939-Standardisierung
-
2010-09-06 FachartikelIntegration von J1939-Systemen in der Praxis
-
2008-09-12 FachartikelEntwickeln mit J1939 - Steuergeräte-Vernetzung in Nutzfahrzeugen
-
2008-09-12 FachartikelAktuelle Entwicklungstrends in der Nfz-Vernetzung - Erfolgsfaktoren bei der Elektronikentwicklung