SAE J1939

Produkte und Dienstleistungen für Ihr SAE J1939 Projekt.


HMS Produkte und Dienstleistungen ermöglichen...

  • die flexible und einfache Implementierung von SAE J1939 in Ihre Geräte – entweder unter Einsatz von fertigen Modulen oder mittels Protokollsoftware 
  • die Verbindung Ihrer SAE J1939 Geräte und Systeme mit jedem beliebigen industriellen Netzwerk
  • die Anbindung Ihres PCs an SAE J1939, für die PC-basierte Steuerung, Konfiguration und Analyse
  • die Analyse und die Wartung Ihres Systems

SAE J1939 Technologieeinführung
SAE J1939 Produkte und Dienstleistungen
Protokollsoftware
 

Implementieren Sie SAE J1939 in Ihre Geräte

Die SAE J1939 Protokollsoftware ermöglicht eine einfache und schnelle Entwicklung von SAE J1939 Geräten. Alle in der SAE J1939 Spezifikation definierten Kommunikationsmechanismen sind vorhanden, wodurch sich der Entwickler voll und ganz auf seine Applikation konzentrieren kann.

  • Verfügbar für verschiedenste Mikrocontrollersysteme und Compiler

emtas J1939 Stack

 
PC Interfaces
 

Verbinden Sie Ihren PC mit SAE J1939

IXXAT PC CAN Interfaces ermöglichen die einfache Anbindung von PC-basierten Anwendungen an SAE J1939 Systeme.

  • Verfügbar in verschiedenen Formfaktoren und für eine Vielzahl von unterschiedlichen PC-Schnittstellenstandards
  • Windows APIs für kundenspezifische PC-basierte SAE J1939 Anwendungen   

PC CAN Interfaces für SAE J1939
SAE J1939 API für Windows

 
CAN Tools
 

Analyse und Konfiguration

Wir bieten eine breite Palette an SAE J1939 Tools für die Entwicklung, die Inbetriebnahme und die Fehlersuche an.

  • canAnalyser – einfache Analyse, Übertragung und Aufzeichnung von SAE J1939 Nachrichten und Signalen
  • emtas J1939 DeviceDesigner – Editor und Code-Generator für den emtas SAE J1939 Stack
  • SAE J1939 Fehlersuche – Leistungsstarke PC- oder mobile Hand-held-Tools

canAnalyser mit CANopen Erweiterung
emtas J1939 DeviceDesigner
CANopen Diagnosis and Trouble-Shooting


SAE J1939 Know-How

HMS bietet eine umfangreiche und preisgünstige Produktpalette für SAE J1939 Anwendungen an – von der Protokollsoftware über Analyse- und Konfigurationstools bis hin zu Windows-APIs für PC-basierte Testgeräte.
 
  • Zentrale Definition aller relevanten Parameter für die komplette Tool-Kette via SAE J1939 Desinger
  • Deutliche Erhöhung der Entwicklungsgeschwindigkeit durch Vermeidung von Fehlern verursacht durch inkonsistente Daten
  • Reduzierung der Entwicklungsrisiken, Verringerung der Entwicklungskosten und kürzeres Time-to-Market

SAE J1939 – eine kurze Einführung

Im Nutzfahrzeugbereich kommen seit längerem standardisierte serielle Protokolle für die Kommunikation zwischen den einzelnen elektronischen Steuereinheiten (ECUs) und Komponenten des Antriebsstranges zur Anwendung. Mit der Nutzung eines standardisierten, seriellen Protokolls verbinden sich die folgenden Vorteile:

  • Hersteller von Komponenten müssen nur ein Protokoll implementieren; dies ist vor allem im Nutzfahrzeugbereich wegen der geringen Stückzahlen von Bedeutung.
  • Hersteller von Nutzfahrzeugen können auf Komponenten verschiedener Zulieferer zurückgreifen.
  • Die Interoperabilität zwischen den einzelnen Komponenten ist gewährleistet, d.h. die Komponenten verschiedener Hersteller arbeiten ohne Anpassungen zusammen.

 

Das von der internationalen Society of Automotive Engineers (SAE) definierte SAE J1939 Protokoll ersetzt die SAE Standards J1587/J1708 und arbeitet auf dem Physical Layer mit CAN-High-Speed nach ISO 11898.

SAE J1939 kommt im Bereich schwerer Nutzfahrzeuge sowohl „On-Road“ (Truck & Trailer) als auch „Off-Road“ (Baumaschinen, Kräne, etc.) zum Einsatz. Im Bereich der Land- und Forstmaschinen findet der ISOBUS nach ISO11784 Anwendung, im maritimen Umfeld das Protokoll NMEA2000 und im Militärbereich MilCAN – alle diese Protokolle basieren auf J1939.

Auf Grund der geforderten Kompatibilität zum bereits vorhandenen J1708/J1587-Protokoll waren für J1939 eine Erweiterung des CAN-Nachrichtenidentifiers von 11- auf 29-Bit und die Entwicklung von CAN-Bausteinen bzw. Protokollimplementierungen zur Unterstützung dieses Nachrichtenformats erforderlich.

Über J1939 ist man in der Lage, sowohl Messwerte und Steuerdaten zu übertragen als auch Komponenten zu konfigurieren. Außerdem besteht z. B. die Möglichkeit, Diagnosedaten einzelner Komponenten zu lesen oder zu löschen sowie eine Kalibrierung einzelner Steuerungen vorzunehmen.

Im J1939-Protokoll wird nicht nur die Art der Übertragung, der Aufbau von Nachrichten sowie deren Segmentierung, Flusskontrolle usw. spezifiziert, sondern auch der Inhalt der Nachrichten selbst genau festgelegt. 

 

 

SAE J1939 im ISO/OSI-Schichtenmodell

SAE J1939 ist entsprechend dem OSI-Schichtenmodell in mehrere Dokumente aufgeteilt, wobei die Dokumentennummer jeweils auf die zugeordnete Schicht im Schichtenmodell Bezug nimmt. Analog zu praktisch allen Feldbusprotokollen werden auch bei SAE J1939 die Schichten 5 und 6 nicht benötigt und sind daher nicht spezifiziert.

 

J1939-Technology-ISO-OSI-Layers

Bild: SAE J1939 im ISO/OSI-Schichtenmodell

 

Physikalische Schicht (Physical Layer)

Das SAE J1939-Protokoll setzt auf den CAN-Bus auf und verwendet diesen als physikalische Übertragungsschicht (Controller Area Network, ISO 11998-1 und ISO 11998-2). Es existieren die folgenden Spezifikationen:

  • SAE J1939/11 definiert eine CAN High-Speed Busankopplung nach ISO/DIS 11898 mit differenziell ausgeführtem, geschirmten Zweidrahtbus mit Masse. Die Datenübertragungsrate beträgt 250 kBit/s, die maximale Anzahl der Knoten ist 30, die maximale Leitungslänge beträgt 40 Meter.
  • SAE J1939/12 beschreibt eine Variante mit Vierdrahtleitung und aktivem Bus-abschluss. Dies erlaubt den Verzicht auf Schirmung und damit den Einsatz eines kostengünstigen Kabels.
  • Die Spezifikation SAE J1939/14 verdoppelt die Datenübertragungsrate von 250 kbit/s auf 500 kbit/s.
  • SAE J1939/15 erlaubt die Verwendung einer ungeschirmten Zweidrahtleitung, wobei dann hier nicht mehr als 10 ECUs pro Netzwerk erlaubt sind. 

 

Data Link Layer

SAE J1939/21 beschreibt die Datenkommunikation über CAN auf Basis der Spezifikation CAN 2.0B. Für diese Kommunikation wird ausschließlich das "Extended Format" genutzt; das "Standard-Format" kommt nur für herstellerspezifische Anwendungen zum Einsatz. Die Spezifikation bestimmt daher, wie der 11-Bit-Identifier verwendet werden muss, damit Identifierkollisionen zwischen den verschiedenen, herstellerspezifischen Nachrichten ausgeschlossen werden.

Außer der Aufteilung und Nutzung des 29-Bit-Identifiers beschreibt die Spezifikation im Wesentlichen die verschiedenen Netzwerkdienste für Nachrichtenanforderungsbetrieb, bestätigte Übertragung sowie die fragmentierte Übertragung großer Datenblöcke.

 

Network Layer

SAE J1939/31 beschreibt im Wesentlichen die Funktionalität einer Bridge zur Übertragung von Nachrichten zwischen zwei Netzwerksegmenten. Durch die in der Bridge vorhandene Nachrichtenfilterfunktion dient diese in erster Linie zur Reduktion des Nachrichtenverkehrs in den einzelnen Segmenten, z. B. zwischen Zugmaschine und Anhänger.

 

Application Layer

Die Applikationsschicht mit dem Dokument SAE J1939/71 beschreibt die eigentlichen Daten (Parameter oder Netzwerkvariablen mit Wertebereich, Auflösung, physikalischer Einheit sowie die Art der Übertragung). Jede Nachricht wird hierbei über eine Nummer (Parameter Group Number: PGN) eindeutig referenziert.

 

Netzwerk Management

Bei J1939 ist das Netzwerkmanagement dezentral organisiert, d.h. jedes Steuergerät muss eine Mindestfunktionalität implementieren. Die Funktionen des Netzwerk-Managements werden im Dokument SAE J1939/81 beschrieben. Da das Netzwerk-Management als separate Einheit betrachtet werden kann, welche bis auf die Hardware (Schicht 1) durchgreift, wird sie im Bild als eigenständiger Funktionsblock auf der rechten Seite dargestellt.

 

 

Gerätenamen, Nachrichtenaufbau,
Address Claiming (J1939/81)

 

Geräteadressen

 

Die Software einer Elektronischen Kontrolleinheit (ECU) ist die Kontroller-Applikation (CA). Eine ECU kann eine oder mehrere CA’s beinhalten. Jede CA hat eine eindeutige Adresse und einen assoziierten Gerätenamen. Jede Nachricht, die von einer CA gesendet wird enthält diese Quelladresse.

 

J1939-Technology-device-address

Im Adressraum der J1939 Geräteadressen gibt es 256 mögliche Adressen:

  • 0..127 – Verwendet für CA‘s mit bevorzugten Adressen und definierten Funktionen 
  • 128..247 – Verfügbar für alle CA’s
  • 248..253 – Verwendet für CA‘s mit bevorzugten Adressen und definierten Funktionen 
  • 254 – Null
  • 255 – Global

Die meisten CA‘s wie Motor, Getriebe, usw. haben eine bevorzugte Adresse. 

 

Gerätenamen

J1939 definiert Gerätenamen, die jeweils durch ein 64-Bit (8 Byte) langes Label repräsentiert sind und zur Identifikation des Geräts und seiner Funktion dienen. Der Gerätename unterteilt sich in verschiedene Elemente, zwischen denen teilweise Abhängigkeiten bestehen. Zu den unabhängigen Feldern gehören unter anderem die „Industriegruppe“ und der „Hersteller-Code“.

 

J1939-Technology-device-name

Bild: Aufbau des Gerätenamens

  • Über die Industriegruppe werden die im Netzwerk benötigte Funktionen festgelegt, da das J1939-Protokoll nicht nur in herkömmlichen Nutzfahrzeugen sondern auch in der Landmaschinentechnik oder im maritimen Bereich zum Einsatz kommt.
  • Der Hersteller-Code muss bei der SAE beantragt und von dieser zugewiesenen werden. Mit diesem Hersteller-Code und der zusätzlichen Identity Number (z. B. Seriennummer) ist der gesamte Name eines Gerätes weltweit eindeutig.
  • Die Function-Instanz wird benötigt, wenn mehrere CA’s dieselbe Funktion haben

 

CAN Identifier

 

J1939-Nachrichten sind auf der CAN 2.0B Spezifikation aufgebaut und machen gezielt Gebrauch von „Extended Frames“. Diese verwenden einen 29-Bit-Identifier anstelle des gebräuchlichen 11-Bit-Identifiers. J1939-21 definiert die Felder innerhalb dieses 29-Bit-Identifier, wie unten gezeigt.

J1939-Technology-Identifier 

Bild: Aufbau Parameter Group

 

  • Die ersten drei Bit (Prioritätsfeld: P) definieren die Priorität der Nachricht auf dem Netzwerk und stellen sicher, dass Nachrichten mit höherer Wichtigkeit vor denen mit niedrigerer Priorität gesendet werden. Der Wert Null hat die höchste Priorität.
  • Mit dem Extended Data Page Bit (EDP) und dem Data Page Bit (DP) können vier verschiedene Speicherseiten (“Data pages”) für J1939 Nachrichten (Parameter Group) ausgewählt werden:

    EDP        DP            Beschreibung
    0              0              SAE J1939 Parameter Groups
    0              1              NMEA2000 defined
    1              0              SAE J1939 reserved
    1              1              ISO 15765-3 defined

  • Das PDU Format Feld (Protocol Data Unit Format, PDU F) definiert, ob die Nachricht für ein bestimmtes Gerät im Netzwerk oder für das gesamte Netzwerk bestimmt ist. Ist der Wert von PDU F < 240, soll ein bestimmtes Gerät angesprochen werden, ist der Wert >= 240, ist die Nachricht für alle Geräte gedacht.
  • Die Definition des PDU Specific (PDU S) Feldes basiert auf dem Wert des PDU F Feld.

    a.) Ist die Nachricht für ein bestimmtes Gerät gedacht (PDU F < 239), wird PDU S als die Adresse jenes Gerätes interpretiert. In diesem Fall wird das PDU S-Feld das Zieladressenfeld genannt (PDU 1).

    b.) Ist die Nachricht für alle Geräte bestimmt (PDU F >= 240), wird PDU S als Gruppenerweiterungsfeld (Group Extension Field) interpretiert. Diese Gruppenerweiterung (PDU 2) wird verwendet, um die Anzahl der möglichen Broadcast-Nachrichten zu erhöhen.

  • Die letzten acht Bits des CAN Identifiers identifizieren die Adresse des Geräts, das die aktuelle Nachricht übermittelt = Quelladressfeld.

 

Address Claiming

Bevor eine CA eine Adresse benutzt, muss sie diese im Netzwerk für sich beanspruchen; diese Prozedur wird „Address Claiming“ (ACL) genannt. Dabei dient der eindeutige Gerätename zur Auflösung von Konflikten bei der Adressvergabe: je kleiner der numerische Wert ist, desto höher ist die Priorität.

Die CA sendet bei ihrem Start eine “Address Claim PGN” (ACL, PGN 00EE00h) und wartet eine festgelegte Zeit auf Antwort. Wenn innerhalb dieser Zeit keine andere CA diese Adresse für sich beansprucht, kann sie mit der normalen Kommunikation starten.

J1939-Technology-Address-Claiming 

Bild: Address Claiming Prozedur

 

Verwendet eine andere CA im Netzwerk bereits dieselbe Adresse, entsteht ein Adressenkonflikt. Die CA mit der höheren Priorität im Gerätenamen erhält dann die Adresse. Es hängt von der “Adress-fähigkeit” (address capability) der CA ab, wie weiter verfahren wird:

Hat die CA lediglich die Adressfähigkeit „nicht selbst konfigurierbar“, muss sie eine „Cannot Claim Address“ PGN mit der Quelladresse (Source Address) Null (254) senden. Ansonsten kann sie eine neue Adresse aus dem dem Adresspool für freie Adressen (128-247) für sich beanspruchen.

 J1939-Technology-Address-Claiming-Conflict

Bild: Address Claiming Prozedur mit Adressenkonflikt

 

Beispiel einer J1939-Nachricht (Parameter Group)

 

Name: Engine temperature
- PG number: 65262 (FEEE Hex)
- PDU format: 254 (FE Hex)
- PDU specific: 238 (EE Hex)
- Default priority: 6
- Transmission rate: 1 s
- Data lenght: 8 Byte

Description of data
Byte 1: Engine coolant temperature
Byte 2: Fuel temperature
Byte 3,4: Engine oil temperature
Byte 5,6: Turbo oil temperature
Byte 7: Engine intercooler temperature
Byte 8: Not defined

 

 

Fragmentierte Übertragung großer Datenblöcke

Bei SAE J1939 werden Nachrichten mit mehr als 8 Datenbytes fragmentiert übertragen. Dabei wird zwischen teilnehmerorientierter (Peer-to-Peer) und globaler (Broadcast) Nachrichtenübertragung unterschieden.

 

Peer-to-Peer

 

Bei der teilnehmerorientierten Nachrichtenübertragung (Peer-to-Peer) wird die Zieladresse (Destination Address) spezifiziert. Die Daten sind an einen bestimmten Teilnehmer gerichtet und werden bestätigt übertragen:

  • Eine Peer-to-Peer Kommunikation wird durch den Empfänger mittels dessen “Clear to send” (CTS) Nachricht kontrolliert
  • Der Sender darf nur die Anzahl von Datensegmenten übertragen, die im CTS definiert sind (0-255)
  • Der Empfänger kann den Nachrichtenfluss über eine “Hold”-Funktion verzögern (CTS mit Null Datensegmenten)
  • Die Übertragung ist erfolgreich abgeschlossen, wenn der Sender die „End of Message“ (EOM) Nachricht erhalten hat
  • Peer-to-Peer Nachrichten
    - Request To Send (RTS)
    - Clear To Send (CTS)
    - Connection Abort (CA)
    - End of Message Acknowledgement (EOM)
    - Data Transfer Message (DTM)

J1939-Technology-Peer-to-Peer

 Bild: Peer-to-Peer Nachrichten

 

Broadcast

 

Bei globalen Übertragungen (Broadcast) handelt es sich um eine Kommunikation ohne Bestätigung (Keine Ablaufsteuerung). Dem Sender sind dabei die Empfänger der Nachricht nicht bekannt. Hier wird folgendes Verfahren angewendet:

  • Der Beginn einer Übertragung wird über die "Broadcast Announce Message" (BAM) angekündigt. Diese Nachricht beinhaltet die Anzahl der Bytes, die Anzahl der Segmente sowie die Nummer der Parametergruppe des zu sendenden Datenblockes.
  • Um allen potentiellen Empfängern Zeit zu geben, den Empfang des angekündigten Datenblockes vorzubereiten, darf erst 50 ms nach der BAM-Nachricht mit der Übertragung des ersten Datensegments begonnen werden. Auch zwischen den einzelnen Datensegmenten muss die Warte-zeit von 50 ms eingehalten werden.
  • Tritt bei einem Empfänger ein Problem auf, darf er die laufende Übertragung nicht über "Connection Abort" abbrechen, da er im Allgemeinen nicht der einzige Empfänger ist.
  • Broadcast Messages
    - Broadcast Announce Message (BAM)
    - Data Transfer Message (DTM)

J1939-Technology-Broadcast

Bild: Broadcast-Nachrichten