Das „CANoe Test Feature Set“ umfasst CAPL-Testmodule, XML-Testmodule und .NET-Testmodule. Je nach Komplexität der Testaufgabe lassen sich damit die Herausforderungen von einfachen bis schwierigen Testfällen abdecken. Während die Cähnliche Skriptsprache CAPL zum Erstellen umfangreicher Testszenarien prädestiniert ist, stehen bei XML eine einfache Parametrierung von Testpattern und eine einfache Generierung von Testabläufen im Vordergrund. Das bietet die Möglichkeit, anwendungsspezifische Testmodule (Funktionsbibliotheken) in CAPL zu implementieren und anschließend die Teststeuerung individuell passend zur Konfiguration des Steuergeräts generieren zu lassen. Die J1939-spezifischen Erweiterungen in den Test Service Libraries ermöglichen dem System die Reaktion auf Parameter Groups (PG) anstatt der typischen CAN-Identifier, außerdem bieten sie Testmuster für J1939-Protokoll-Funktionen und Checks (Hintergrundüberwachungen) auf Protokollverletzungen. Somit lässt sich beispielsweise prüfen, ob das Steuergerät bei hoher Buslast in der Lage ist, alle Parameter Groups mit der konfigurierten Zykluszeit zu senden. Ferner können die Transportprotokolle BAM (Broadcast Announce Message) und CMDT (Connection Mode Data Transfer) für Testzwecke auch fehlerhaft gesendet werden.
Zur Erstellung der Testmodule ist neben dem J1939 Test Module Manager und dem komfortablen Test Automation Editor die Option „DiVa“ nützlich. Sie schafft eine Verbindung zwischen CANoe und dem Diagnosespezifikations-Tool „CANdelaStudio“, so dass dort erstellte Spezifikationen für steuergerätespezifische Diagnose-Tests weiterverwendbar sind.
Zu den weiteren Funktionen des Test Feature Sets gehören eine Testablaufsteuerung und die automatische Reportgenerierung einschließlich statistischer Informationen im XMLoder HTML-Format nach individuellen Vorgaben. Weitergehende Optionen zur Automatisierung der Testvorgänge eröffnet die COM-Schnittstelle, zum Beispiel hinsichtlich Ablaufsteuerung, Parameteränderungen oder Statusabfragen. Die CANoe-Option J1939 stellt für Diagnose-Zwecke auch Trace-Fenster, einen J1939-Diagnose-Monitor und den J1939-Diagnose-Speicherzugriff bereit. Der Diagnose-Monitor unterstützt die verschiedenen J1939-Diagnose-Messages, wie beispielsweise DM1 und DM2, und dient zur Anzeige und zum Löschen von aktiven Fehlern. Möglich ist darüber hinaus ein Zugriff auf Speicherbereiche, Objekte und Parameter sowie eine zyklische Objektaktualisierung für Monitoring-Zwecke.
Matlab/Simulink-Modelle in J1939-Netzwerk-Simulationen einbinden
Normalerweise werden während der verschiedenen Nutzfahrzeug-Entwicklungsphasen verschiedene Funktionsmodelle für mechanische Komponenten wie Getriebe, Antriebsstrang oder sogar das komplette Fahrzeug erstellt. Steuergeräte-Architekturen bildet man zunächst in virtuellen Funktionsmodellen ab und realisiert sie Schritt für Schritt auf der endgültigen Hardware-Zielplattform. CANoe.J1939 integriert auch Matlab/ Simulink-Modelle in die Steuergeräte- und Netzwerk-Simulationen (Bild 5). Hierzu erzeugt der Anwender mit dem Real-Time Workshop von Mathworks eine *.DLL für CANoe, so dass Variablen-Namen und Units kompatibel sind.
Aus Sicht des ISO/OSI-Schichtmodells baut J1939 im Wesentlichen auf dem Application Layer (Schicht 7), dem Network Layer (Schicht 3), dem Data Link Layer (Schicht 2) und dem Physical Layer (Schicht 1) auf (Bild 1). Dies erlaubt den Entwicklern, nur mit Signalsequenzen arbeiten zu können, ohne sich auf Applikationsebene um Details der Kommunikation wie beispielsweise die Transportprotokolle kümmern zu müssen. Auch die Dokumentation/ Definition von J1939 orientiert sich an den einzelnen Schichten, was sich in der Bezeichnung der insgesamt 14 Werke des Standards ausdrückt. So behandeln die Dokumente des 7er-Nummernkreises wie z.B. J1939/71 den Application Layer, das Dokument 21 den Data Link Layer usw. (einige Details hierzu im Kasten).
Das CAN-Botschaftsformat bei J1939
J1939 nutzt zwar normale 29-bit-CAN-Botschaften mit bis zu 8 byte Daten, jedoch wird über den CAN-Identifier quasi die Maske eines einheitlichen J1939-Schemas gelegt (Bild 2). Dies ist aufgrund der Plug-and-Play-Eigenschaften notwendig. So enthält der CAN-Identifier neben der Identifizierung der Nutzdaten mit Hilfe der Parameter Group Number (PGN) auch die J1939-Steuergeräte-Adressen des Senders und gegebenenfalls auch des Empfängers. Außerdem sind die drei höchstwertigen Bits des CAN-Identifier als Prioritätsfeld reserviert, die zwar nicht die im CAN-Protokoll implizite Priorität ersetzen, jedoch die Zuordnung der Parameter Groups in bis zu acht J1939-spezifische Prioritätsstufen ermöglichen. Mit Hilfe dieser Prioritäten kann zum Zeitpunkt der Übertragung der Parameter Group oder während einer optionalen Konfigurationsphase des Steuergeräts die Priorität an die aktuellen Anforderungen der Anwendung angepasst werden. Dies ermöglicht eine feine Abstimmung der Kommunikation auf die Anwendung, ohne dass die SAE zum Zeitpunkt der Definition der Parameter Group die Priorität festlegt.
J1939 definiert Gerätenamen, die jeweils durch eine 64-bit-Zahl repräsentiert sind. Schaltet man ein Steuergerät im Plug-and-Play-Netzwerk aktiv, dient der Gerätename zur Identifikation des Geräts und seiner Funktion. Der Gerätename unterteilt sich in verschiedene Elemente, zwischen denen teilweise Abhängigkeiten bestehen. Zu den unabhängigen Feldern gehören unter anderem die Industry Group und der Manufacturer Code. Über die Industriegruppe legt man die im Netzwerk benötigten Funktionen fest, da das J1939-Protokoll nicht nur in herkömmlichen Nutzfahrzeugen zum Einsatz kommt, sondern auch in der Landtechnik oder im Maritim-Bereich. Jedes Steuergerät trägt einen von der SAE zugewiesenen Hersteller-Code, der dort zu beantragen ist. Da jedes Gerät zusätzlich eine Seriennummer hat, ist der gesamte Name weltweit eindeutig: Es kommen keine Überschneidungen vor.
Da die Adressierbarkeit der Geräte über den 64 bit langen Gerätenamen in der Praxis mit CAN ineffizient ist, sind den einzelnen Fahrzeugkomponenten im Nutzfahrzeug-Umfeld durch die SAE feste 8-bit-Adressen zugewiesen; diese ändern sich in der Regel zur Laufzeit nie. Für die Landtechnik und den Maritim-Bereich trifft dies nicht zu, dort werden die Adressen beim Start unter Berücksichtigung des Gerätenamens dynamisch ausgehandelt. Die Adressen 0 bis 127 sind den gängigsten Steuergeräten wie Motor, Getriebe, Retarder, Bremsen usw. zugeordnet, während der Bereich von 128 bis 247 für Landtechnik, Schifffahrt, Baumaschinen usw. reserviert ist. Werkstatt-Tools, OBD-Scanner usw. belegen die Adressen von 248 bis 253. Übrig bleiben als Sonderadressen die 254, mit der man Geräte kennzeichnet, die keine eigene Adresse haben, sowie die 255 als globale Adresse zur Adressierung von Broadcast Messages.