Anzeige
Was bringt die neue CANopen FD Spezifikation?

CANopen FD in der Cloud

Die neue CANopen FD Spezifikation CiA 1301 ist seit September 2017 verfügbar. Ein Vorzug zum klassischen CAN: es können jetzt bis zu 64Datenbyte in einem PDO übertragen werden. Das neue USDO erlaubt IoT-Gateways dynamisch jeden Datenpunkt zu erreichen.

Vergleich eines CAN Datentelegramms im klassischen und FD Format (Bild: CAN in Automation (CiA) GmbH)

Vergleich eines CAN Datentelegramms im klassischen und FD Format (Bild: CAN in Automation (CiA) GmbH)

Die von der CiA Arbeitsgruppe ‘SIG application layer’ vorgenommene Anpassung von CANopen auf CAN FD erfolgte unter der Prämisse, möglichst viel bewährte CANopen-Funktionalität konstant zu halten. Insofern stand am Anfang die Analyse, welcher CANopen-Dienst überhaupt von einer Anpassung auf CAN FD profitieren würden. Dabei kristalisierte sich heraus, dass ausschließlich die Datentransport-orientierten CANopen Dienste SDO und PDO durch das klassische CAN Datentelegramm, in ihrer Effizienz limitiert werden. Somit konnten alle anderen Dienste unverändert übernommen werden; mit Ausnahme des ‘EMCY write’-Dienstes. Die SIG application layer hat die Gelegenheit der Überarbeitung von CANopen genutzt, um einen verbesserten Satz an Diagnosedaten, im Rahmen eines erweiterten ‘EMCY write’-Dienstes bereitzustellen. Im klassischen CANopen wird ein PDO durch zwei Parametersätze beschrieben; die Kommunikationsparameter und die ‘Mapping-Parameter’. Die Kommunikationsparameter beschreiben, welcher CAN-Identifier für das PDO genutzt wird und wann die Steuerdaten zuverlässig kommuniziert werden. Diese Parameter sind unabhängig vom Format des genutzten CAN Telegramms und bedürfen keiner Anpassung.

Ähnlich verhält es sich bei den sogenannten ‘Mapping-Parametern’. Die ‘Mapping-Parameter’ beschreiben, als Referenz auf das lokale Objektverzeichnis, welche Daten übertragen werden. Im klassischen CANopen erlauben 64 Einträge das referenzieren von bis zu 64 Informationen aus dem lokalen Objektverzeichnis. Das klassische CAN-Telegramm beschränkt die Datenbreite der insgesamt referenzierten Informationen auf 8Byte. Diese Grenze wird mit CANopen FD auf 64Byte angehoben. Somit ist außer der Anpassung der Summe, der maximal übertragbaren Datenbyte, keine weitere Änderung erforderlich. Die bestehenden, maximal 64 Mappingeinträge sind für den Einsatz von CAN FD ausreichend und können unverändert weiter genutzt werden. Dies gilt vor allem unter der Berücksichtigung, das CANopen FD nur noch Informationen im Objektverzeichnis verwaltet, die auf ein ganzzahliges Vielfaches von einem Byte abgebildet werden.

Generelle Struktur des USDO Protokolls (Bild: CAN in Automation (CiA) GmbH)

Warum das neue Protokoll

Im Gegensatz zum PDO war es deutlich komplexer, das für Diagnose und Konfiguration genutzte SDO, auf den Einsatz in CAN FD-basierenden Systemen, vorzubereiten. Eine einfache Erweiterung des SDO Protokolls war nicht möglich. An Stelle einer schlecht handhabbaren, umständlichen Erweiterung des ohnehin schon komplexen SDO-Protokolls bevorzugte die SIG application layer einen neuen Dienst einzuführen. Dieser Dienst soll den Anforderungen zukünftiger, in Cloud-Anwendungen integrierter, eingebetteter Netzwerke, Rechnung tragen. Das Ergebnis war das Universal Service Data Object (USDO). Im Gegensatz zum klassischen SDO, ermöglicht das USDO, den dynamischen Aufbau von Kommunikationsquerverbindungen, zur Systemlaufzeit, bei gleichzeitiger Abwesenheit jeglicher Manager-/ Masterfunktionalität. Das USDO erlaubt die Kommunikation in unicast und broadcast und kann dabei jede Datengröße transferieren. Das ermöglicht z. B. einem Telematikmodul, jeden gewünschten Datenpunkt im ‘embedded-Netzwerk’ zu erreichen, auch wenn ein Systemintegrator bei initialem Systemstart, keine Kommunikationsverbindung zwischen Gateway und Datenquelle eingerichtet hatte. Darüber hinaus ist das USDO inhärent Routing-fähig. Durch das Codieren von Quell- und Zieladresse, kann mittels USDO, in einer auf CANopen FD-Netzwerken basierenden Anwendung, über Netzwerkgrenzen hinweg kommuniziert werden.

Einfacher in die Cloud

Das CANopen FD PDO, macht den durch CAN FD angebotenen, erhöhten Datendurchsatz, nutzbar. Cloud-basierten Anwendungen kann somit eine größere Datenbasis generiert werden. Das 64-Byte Datenfeld der PDOs, erleichtert das erfüllen von Security-Anforderungen in CAN-basierten Anwendungen erheblich. Das USDO profitiert nicht nur vom CAN FD Datendurchsatz. Die Ausgestaltung des USDOs und der damit einhergehende Funktionsumfang erlauben es, dynamisch Kommunikationsbeziehungen zwischen beliebigen Netzwerkteilnehmern aufzubauen. Somit stellt CANopen FD ein geeignetes Stilmittel für Aufgaben der Fernwartung und –steuerung bereit. Abgeleitet vom Prinzip der Betriebsmittelkennzeichnung hat die CiA Arbeitsgruppe SIG CANopenIoT für CANopen, das Prinzip der Referenzdesignatoren eingeführt. Diese erlauben es in heterogenen Steuerungsarchitekturen, Geräte und -parameter systemweit eindeutig zu kennzeichnen. Diese anwendungsspezifische Kennzeichnung kann wiederum als Adresse für eine logische Adressierung dienen. Im Dokument CiA 309-5, wird diese logische Adressierung für den Zugriff auf CANopen-Netzwerke definiert. Ein weiterer Schritt für CANopen FD wird darin bestehen, das Prinzip der logischen Adressierung im USDO-Protokoll abzubilden. Das Entbinden des Anwenders von tiefer Kenntnis der im ‘eingebetteten Netzwerk’ verwendeten Technologie, wird die Integration von CANopen FD in ‘Cloud-basierte’ Anwendungen weiter vereinfachen.

Zusammenfassung

Eine wesentliche Erweiterung gegenüber dem klassischen CANopen ist das USDO Protokoll. Als Multifunktionswerkzeug zukünftiger CANopen FD-Netzwerke unterstützt es unter anderem eine dynamisch aufgebaute Kommunikation in unicast und broadcast; in lokalen oder über Router angebundenen ‘Remote-Netzen’. Der Zugriff auf mehrere Sub-indices mittels eines einzigen USDO Lese- oder Schreibzugriff, befindet sich genauso in der Spezifikationsarbeit wie die Umsetzung der Anforderung nach der logischen Adressierung. ‘Cloud-basierende’ Anwendungen wie ‘Condition monitoring’ oder ‘Predictive maintenance’ werden von dem erhöhten Prozessdatendurchsatz profitieren. Die verlängerten CAN FD Datentelegramme ermöglichen das Nutzen von einheitlichen ‘Safety’- und ‘Security’-Lösungen, welche sich ebenfalls aktuell im CiA in der Erarbeitung befinden.

Autor: Reiner Zitzmann,
CAN in Automation (CiA) GmbH
www.can-cia.org

CANopen FD in der Cloud
Bild: CAN in Automation (CiA) GmbH


Das könnte Sie auch interessieren

Mit dem SimpleLink Bluetooth Low Energy Modul CC2650MODA ist es für Sie einfacher als je zuvor, Ihr Produkt mit modernen Eigenschaften auszustatten.‣ weiterlesen

Vor dem Hintergrund des voranschreitenden Fachkräftemangels, bietet die Job and Career at Cebit in Halle 27 Arbeitgebern und Arbeitnehmern eine Plattform, die der Rekrutierung, dem Employer Branding und der Karriereplanung dient. 

Cisco erweitert sein Intent-based Networking-Portfolio, Cisco DNA, mit drei Lösungen. Damit können Unternehmen die sich ständig verändernden IoT-Netzwerke besser verwalten und von den Vorteilen des Intent-based Networking auch im IoT profitieren.

RS Components hat ab jetzt den MPLab PICkit 4 In-Circuit Debugger/Programmierer von Microchip im Programm. Das MPLab PICkit ermöglicht das schnelle und einfache Debugging und Programmieren von PIC-Mikrocontrollern und dsPIC-DSCs mit der integrierten Entwicklungsumgebung MPLab X .

Huawei, Telefónica Deutschland und der IoT-Anbieter Q-loud haben gemeinsam ein auf NarrowBand-Internet of Things (NB-IoT) basierendes Smart Metering-Pilotprojekt gestartet. 

Das HL7802-Modul für weltweite Cat-M1-/NB1-Netzwerke mit 2G-Fallback ist vollständig kompatibel mit dem 3GPP Release-13-Standard.

Anzeige
Anzeige
Anzeige
Anzeige
Anzeige
Anzeige