J1939 Implementation Made Easy

Steuergeräteanwendungen mit einer CAN-Kommunikationsschicht, basierend auf dem SAE J1939-Protokoll, finden immer mehr Verbreitung. Viele Steuergeräteanbieter müssen sich der Herausforderung stellen, ihre Anwendungen auf eine J1939-Kommunikation umzustellen. Die typische Vorgehensweise ist dabei, eine J1939-Protokollsoftware bei einem der Protokollspezialisten zu beziehen und in die eigene Anwendung zu integrieren. Dabei wird von der Protokollsoftware verlangt, dass diese sich problemlos zur eigenen Applikation hinzufügen und mit wenigen Funktionsaufrufen einbinden lässt. Trotzdem darf die Protokollsoftware nur wenige CPU- und Speicherressourcen benötigen, da es sich hier ja nur um \“Beiwerk\“ handelt. Durch die große Bandbreite von J1939-Anwendungen werden die Lieferanten einer Protokollsoftware daher vor große Herausforderungen gestellt. Zum einen existiert eine Vielzahl von Hardwareplattformen, die als Basis für die Steuergeräteimplementierungen genutzt werden. Die Bandbreite reicht hier von Zielsystemen mit 8 Bit- Mikrocontroller ohne Betriebssys­tem und mit stark begrenzten RAM-Ressourcen und geht bis zu 32 Bit-Systemen mit (Echtzeit-) Betriebssystem. Zum anderen variieren auch die J1939-Anwendungen sehr stark. Dies beginnt bei Systemen mit nur wenigen Nachrichten mit bis zu acht Datenbytes Länge und fester Geräteadresse (kein Netzwerkmanagement) und geht bis zu Systemen mit dynamischer Geräteadressenvergabe, mit Anforderungen an die Übertragung von großen Datenpaketen (multi packets) und umfangreichen Diagnosefunktionen nach [J1939/73]. All diese Anforderungen müssen beim Einsatz einer Protokollsoftware \“von der Stange\“ berücksichtigt werden. Interface zwischen Anwendung und Protokoll-Software Primär soll eine J1939-Protokollsoftware das Senden und Empfangen von J1939-Nachrichten ermöglichen. Hier findet man in der Praxis als Schnittstelle zwischen Applikation und Protokollsoftware zwei unterschiedliche Mechanismen vor: 1. Übergabe der Daten über eine Datenschnittstelle als Shared Memory zwischen Applikation und Protokollsoftware. Damit sind Anwendung und Kommunikation zeitlich weitgehend entkoppelt. Die Anwendung kann damit ihren eigenen Verarbeitungszyklus fahren und nutzt die Datenschnittstelle zum Senden und Lesen empfangener Daten nur bei Bedarf. 2. Übergabe der Daten über eine Funktionsschnittstelle. Hier existiert eine Sendefunktion, der typischerweise eine komplette Sendenachricht zum Versenden übergeben wird. Empfangene Nachrichten werden entweder unverzögert über eine Callback-Funktion von der Protokollsoftware an die Applikation übergeben oder in einem Ringspeicher zwischengespeichert, so dass die Nachrichten von der Applikation über eine Lesefunktion aus dem Ringspeicher entnommen werden können. Dadurch entsteht eine enge Kopplung zwischen Applikation und Protokollsoftware. Werden bei der Funktionsschnittstelle typischerweise komplette J1939-Nachrichten ausgetauscht, so findet man dagegen bei einer Datenschnittstelle in der Regel eine Variablen oder Prozessgrößen orientierte Verarbeitung vor. Aber auch bei der Funktionsschnittstelle steht der Anwender vor der Aufgabe, einzelne Variablen zu einer Sende­nachricht zusammenzustellen bzw. eine Empfangsnachricht auszupacken. Da bei J1939 die Nachrichtenzusammenstellung bereits per Nachrichtenkatalog festgelegt und nicht zur Laufzeit konfigurierbar ist, besteht die Möglichkeit, pack()- bzw. unpack()-Funktionen für alle definierten Nachrichten bereits durch die Protokollsoftware bereitzustellen. Darüber hinaus findet man in J1939-Netzwerken auch viele herstellerspezifische Nachrichten. J1939 lässt hier den Freiraum, so genannte proprietäre Nachrichten auszutauschen. Die Zusammenstellung von Variablen zu proprietären Nachrichten kann von der Protokollsoftware daher nur durchgeführt werden, wenn eine Konfiguration der Protokollsoftware in Bezug auf proprietäre Nachrichten in irgendeiner Art und Weise möglich ist. Neben dem Austausch von Daten muss die Protokollsoftware zyklisch ausgeführt werden, so dass z.B. Timeouts überwacht und Übertragungsprotokolle abgewickelt werden können. Hier ist in der Regel der zyklische Aufruf einer process()-Funktion notwendig, welche bei Systemen ohne Betriebssystem normalerweise aus der Programmhauptschleife aufgerufen wird. Die Aufruffrequenz ist damit direkt von der Durchlaufzeit der Programmhauptschleife (main loop) abhängig. Bei Systemen mit Betriebssystem bietet sich hier eine eigene Task an, welche zyklisch ausgeführt wird und bei jedem Durchlauf die process()-Funktion aufruft. Bei dieser Variante muss aber darauf geachtet werden, dass keine Probleme bei der Nutzung des Stacks über die Funktionsschnittstelle auftauchen, wenn unabhängig davon die process()-Funktion aus einer zweiten Task aufgerufen wird. Auch sollte die Nutzung der Funktionsschnittstelle von mehreren Tasks möglich sein. Die Protokollsoftware muss hierfür ausgelegt sein, sollen keine unerwünschten Effekte auftauchen. Beispiel einer Implementierung Die Firma Ixxat als Kommunikationsspezialist bietet seit vielen Jahren Protokollsoftware für verschiedene Feldbusse an. Die zweite Generation der J1939-Protokollsoftware-Implementierung berücksichtigt speziell die oben aufgeführten Probleme und bietet somit Komfort für den Anwender. Um die Bandbreite der Zielsysteme abdecken zu können, bietet das Unternehmen zwei Varianten der J1939-Protokollsoftware an: 1. die Standard-Version für Zielsysteme mit freiem Datenspeicher >2KByte 2. die Micro-Version für Systeme mit freiem Datenspeicher ab ca. 200 Bytes Die Standard-Version erlaubt die dynamische Konfiguration der SAE J1939-Software über die Funktionsschnittstelle und damit zur Laufzeit. Damit kann z.B. die Filterung von Empfangsnachrichten zur Laufzeit verändert werden. Diese Variante unterstützt auch mehrere Softwareinstanzen (CAN­Kanäle) und ist durch eine speziell dafür vorgesehene Abstraktionsschicht für den Einsatz unter einem (Echtzeit-) Betriebssystem vorbereitet. Die Software kann aber ebenso in einer Anwendung ohne Betriebssystem eingesetzt werden. Die Micro-Variante ist für den Einsatz auf 8/16 Bit-CPUs mit stark begrenzten Datenspeicher-Ressourcen optimiert. Hier erfolgt die Konfiguration der Software komplett statisch über durch ein Konfigurationswerkzeug generierte C-Files. Da dadurch die komplette Konfiguration im Code fixiert ist, wird die Konfiguration komplett im Flash-Speicher abgelegt und reduziert damit den RAM-Bedarf erheblich. Zusätzlich ist die Protokollsoftware intern auf begrenzte Datenspeicher-Ressourcen hin optimiert, was sich auch auf die Anwenderschnittstelle auswirkt. Im J1939-spezifischen Funktionsumfang unterscheidet sich die Micro-Variante aber nicht von der Standard-Variante. Beide Varianten besitzen eine Funktionsschnittstelle zum Senden und Empfangen von Nachrichten und arbeiten hierbei nachrichtenorientiert. In der Standard-Variante ist die Funktionsschnittstelle so ausgelegt, dass diese aus mehreren Tasks genutzt werden kann. Diese kann damit als \“thread safe\“ bezeichnet werden. Zusätzlich existiert ein so genanntes Cycle-Modul, das die Protokollsoftware um eine Datenschnittstelle erweitert. Dabei hat die Applikation über generierte Makros direkten Zugriff auf die Daten. Das zyklische Senden sowie die Überwachung zyklisch zu empfangender Nachrichten wird durch das Cycle-Modul bereitgestellt. Ob über die Funktionsschnittstelle oder die Datenschnittstelle gearbeitet werden soll, kann pro Nachricht festgelegt werden. Konfigurationstool für die Protokollsoftware Wie schon erwähnt, spielt bei der Konfektionierung und Konfiguration der Micro-Variante ein grafisches Konfigurationswerkzeug eine große Rolle. Dieses erlaubt neben der Einstellung von Standardparametern wie Gerätenamen oder Dimensionen von Ringspeichern auch die Auswahl von Standardnachrichten aus einem Katalog. Basierend auf diesen Einstellungen werden die Filter und Verteilerfunktionen innerhalb der Protokollsoftware konfiguriert sowie Zugriffsmakros für den Anwender generiert. Diese Zugriffsmakros erlauben, auf Prozessgrößen innerhalb von empfangenen Nachrichten einfach zuzugreifen. Über entsprechende Makros für Sendenachrichten können Variablen zu einer J1939-Nachricht zusammengestellt und an die Sendefunktion der API übergeben werden. Damit auch proprietäre Nachrichten berücksichtigt werden können, erlaubt das Konfigurationswerkzeug auch die Definition von anwenderspezifischen Nachrichten. Der Vorteil der Konfiguration über ein Werkzeug liegt dabei nicht nur im Komfort für den Anwender; die vollständige Konfiguration aus einem Werkzeug heraus erlaubt auch eine Konsistenzprüfung aller eingestellten Parameter. So können z.B. falsche Dimensionierungen von Ringspeichern vermieden werden. Zusätzlich erlaubt eine Druckfunktion, die komplette Konfiguration für Dokumentationszwecke festzuhalten. Auf Wunsch kann durch das Konfigurationswerkzeug auch ein Rahmencode für eine Applikation generiert werden. Dieses C-File muss vom Anwender vervollständigt und zusammen mit der Protokollsoftware übersetzt werden. Dies ist vor allem für \“erste Gehversuche\“ mit J1939 sinnvoll und erlaubt einen sehr schnellen Einstieg in die J1939-Kommunikation. Beispielapplikation Die folgenden Codezeilen zeigen die Initialisierung sowie den Betrieb der J1939-Protokollsoftware, wobei in diesem Beispiel ein übertragener Parameter gelesen werden soll. Dazu muss die Nachricht mit dem gewünschten Parameter (engine oil pressure, SPN100) im Konfigurationswerkzeug als Empfangsnachricht konfiguriert werden. Durch die komplette Konfiguration der Protokollsoftware über das Konfigurationswerkzeug entfallen alle Konfigurationsparameter bei APL_Init(). An die Protokollsoftware muss jeweils nur die aktuelle Zeit im Millisekunden übergeben werden. void main(void) { // Initialize the J1939 // protocol software APL_Init(time()); while(1) { // Keep the J1939 protocol // software running APL_Main(time()); do_other_tasks(); } } Über das Cycle-Modul wird der Empfang der Nachricht überwacht und die empfangenen Daten in einem vom Konfigurationswerkzeug dafür generierten Puffer abgelegt. Über das ebenfalls generierte Makro UNPACK_EFL_P1_SPN100() kann der Parameter durch die Applikation gelesen werden, wobei der Wert über das Makro aus dem 8Byte Datenstrom der empfangenen Nachricht ausgepackt wird. // read SPN100 (engine oil pressure) // from PGN65263 (EFL/P1) val = UNPACK_EFL_P1_SPN100();