Industrie 4.0 CANopen im Internet der Dinge

Das Internet der Dinge ist ebenso wie Industrie 4.0 in aller Munde. Aber jeder versteht darunter etwas anderes. Stichworte wie Cloud, Big-Data, Digitalisierung und so weiter werden munter aneinander gereiht und überall wird ein 4.0 an einen Begriff gehängt. Stecker 4.0 ist sicherlich die Spitze des Eisberges der absurden Beispiele. OPC UA oder Automation-ML werden oft noch dazu gemischt. Es scheint alles nur Marketing zu sein. Das stimmt so aber nicht: Es gibt schon erste globale Modelle und Referenzarchitekturen für Industrie 4.0. Und jeder Webserver und jedes Ethernet-Gateway einschließlich WLAN-Schnittstellen kann ein Ding im Internet sein.

Sensoren und Stellglieder

In Fertigung und Produktion sind Sensoren und Aktuatoren an der vordersten Front. Sie sind direkt am Geschehen. Sie müssen Schmutz, Hitze und Kälte ertragen, müssen möglichst klein sein und ihre Erkenntnisse zuverlässig an die nächsthöhere Instanz kommunizieren. Kosten sollen sie übrigens auch nicht viel. Das ursprünglich für die Fahrzeug-interne Vernetzung entwickelte CAN-Protokoll ist dafür optimal geeignet und hat sich in vielen Branchen einschließlich der Industrieautomatisierung gut etabliert. Die jährlich weit über 1,5 Milliarden verbauten CAN-Controller sprechen für sich. Dabei ist die CAN-Hardware nicht nur robust, sondern auch zuverlässig. Seit über 20 Jahren ist in der Industrieautomatisierung CANopen als höheres Protokoll weit verbreitet. Es verbindet auf flexible Art und Weise Sensoren und Aktuatoren nicht nur mit einer zentralen Steuerung, sondern erlaubt auch eine von der Steuerung unabhängige Querkommunikation zwischen den einzelnen Geräten. Wäre es nun möglich, die in den Sensoren und den Aktuatoren vorhandenen Daten in die „Wolke“ zu bringen, könnte aus den gesammelten Informationen mit „Big-Data“-Methoden neue Erkenntnisse gewonnen werden. Es wäre auch möglich, mit Web-basierten Tools erstellte Konfigurationen per Internet in die einzelnen Geräte zu laden.

Wie aber bekommt der Anlagenbauer ein CANopen-Sensor ins Internet? Wie wird ein CANopen-Antrieb ein Ding im Internet? Er nimmt einfach einige der bereits seit Jahren veröffentlichten CiA-Dokumente (CAN in Automation), zum Beispiel CiA 309, und erweitert sie, sodass er von der „Wolke“ über ein CANopen-Gateway auf die Geräte lesend oder schreibend zugreifen kann. Selbstverständlich muss er dazu irgendwo CANopen-Kenntnisse haben. Je nach Anwendung kann dieses Know-how sich in der Cloud, im Gateway oder sogar in jedem CANopen-Gerät befinden. Dies ist keine technische Frage, sondern eine „politische“.

Um die isolierten Steuerungsinseln zu vernetzen, sind Gateways zu überlagerten Netzwerken nötig, die eine fabrik- oder unternehmensweite Kommunikation ermöglichen. In CANopen gibt es diese Gateway-Standards schon lange; 2004 wurde die Spezifikationsreihe CiA 309 – CANopen-Gateway für TCP-basierte Netzwerke – veröffentlicht.

Jeder CANopen-Knoten lässt sich über CiA-309-Dienste adressieren. Die dazu erforderlichen Dienste sind im ersten Teil der Spezifikationsreihe definiert. Teil 2 beschreibt die zugehörigen Protokolle für Modbus-TCP und Teil 3 ein entsprechendes ASCII-Protokoll. Im Teil 4 wurden gemeinsam mit der PNO (Profibus Nutzerorganisation) Protokolle für ProfinetIO spezifiziert.

Für die Anbindung an das Internet und die direkte Adressierung aus der „Wolke“ wird die Spezifikation CiA 309-5 entwickelt. Sie beschreibt den Zugriff auf CANopen-Dienste mit Hilfe des HTTP-Protokolls. Ein SDO-Upload-Kommando (Servicedatenobjekte) „lesen einer Variablen“ sieht beispielsweise so aus: http://localhost/CiA309_5?001&14&r&6200&01&u8. Localhost ist dabei die Adresse des Webservers, der in dem Gateway oder im CANopen-Gerät mit Gateway-Funktionen implementiert ist. Die erste Zahl nach dem Fragezeichen ist die Sequenznummer.

Die folgenden durch &-Zeichen getrennten Werte bezeichnen die CANopen-Knotennummer (14), den Befehl (r = SDO upload/read), Index (6200h), Subindex (01h) und den Datentyp (u8 = UNSIGNED8). Das ganze lässt sich auch in XML beschreiben, entsprechende Mappings sind ebenfalls in CiA 309-5 spezifiziert.

CANopen verstecken und funktional adressieren

Selbst wenn über das Internet jedes Datum in einem Sensor oder Aktuator adressiert werden kann, sind die wirklichen Probleme noch nicht gelöst. An den Schnittstellen wird immer noch zu viel Wissen über die Kommunikationsdetails benötigt.

Es stellt sich immer die Frage, wo muss das kommunikations-spezifische Wissen vorhanden sein. Nutzt der Systementwickler generische Geräteprofile, muss er keine CANopen-Kenntnisse wie Netzwerk-ID oder Variablen-Adresse haben. Er kann funktional adressieren: Lese den Status des Hauptschalters der Wasserpumpe. Selbstverständlich muss dann die funktionale Adresse irgendwo aufgelöst werden – Node-ID = 14, Index/Subindex = 6000 01h. Dies kann in der Cloud erfolgen, dann kann der Entwickler von dort mit den CiA 309-5-Diensten transparent über das CANopen-Gateway auf das Ein-/Ausgabe-Gerät lesend zugreifen.

Eine funktionale Adressierung klappt auch: http://localhost/CiA309_5?001&water-pump&r&main-switch. Die Auflösung der funktionalen Adresse (Hauptschalter der Wasserpumpe) muss dann im CANopen-Gateway oder im CANopen-Gerät erfolgen. Bei komplexeren Gateways muss eventuell noch die Port-Nummer sowie bei kaskadierten CANopen-Netzwerksystemen die Netzwerk-ID aufgelöst werden.

Für den Transport von Konfigurationsdateien und Diagnosedateien ist derzeit OPC UA eine viel diskutierte Option. CiA hat mit der OPC Foundation ein „Memorandum of Understanding“ unterzeichnet, um die OPC-UA-Dienste auf CANopen abzubilden. Dies erlaubt beispielsweise das transparente Herunter- und Heraufladen von Dateien. Aber auch hier gilt: Es wäre wünschenswert, wenn die Geräteprofile bus- und netzwerk-unabhängig wären. Es gibt solche bereits für Hydraulikkomponenten vom VDMA (Verband Deutscher Maschinen- und Anlagenbau), die auch auf CANopen abgebildet sind – CiA 408. Einige industrielle Ethernet-Protokolle wie Ethercat und Powerlink verwenden das CANopen-Objektverzeichnis (Datenmodell und Adressierung) sowie die CANopen-Profile. So kann eine Abbildung auf unterschiedliche Kommunikationssysteme vereinfacht werden, weil nur die netzwerk-spezifischen Parameter angepasst werden müssen. Aus der Anwendungssicht gibt es keine Notwendigkeit, die Parameter abzubilden.

CiA hat weit über 20.000 DIN-A4-Seiten mit CANopen-Geräteprofilen veröffentlicht, die teilweise auch von anderen Kommunikationssystemen genutzt werden. Sind die CiA-Geräteprofile festgelegt, müssen nur noch die kommunikationstechnik-spezifischen Parameter in den Gateways umgesetzt werden. Dies würde eine Systemintegration vereinfachen.

Hinter dem CANopen-Gateway gibt es bereits alle erforderlichen Komponenten für die Echtzeit-Verarbeitung von Prozessdaten und Emergency-Daten. Für die Konfiguration und allgemeine Diagnose über das Internet, bieten OPC-UA-Dienste die erforderlichen Mechanismen entsprechende Dateien zu transportieren. Dies können auch Funktionsblöcke nach IEC 61131-3 sein. CiA wird auch andere APIs (Application Programming Interfaces) unterstützen, zum Beispiel das in CiA 318 und CiA 460 spezifizierte Interface für Serviceroboter. Ein entsprechendes Normungsvorhaben beginnt in der IEC (International Electrotechnical Commission) noch in diesem Jahr. Selbstverständlich können diese Dateien auch die eben beschriebenen http-Protokolle in Form von ausführbaren XML-Dateinen enthalten. Ein entsprechendes XML-Schema ist entsprechend der Spezifikation CiA 311 bereits seit längerem vorhanden.

Einfach konfigurieren und diagnostizieren

Mit den oben beschriebenen Spezifikationen kann der Anwender die an vorderster Front installierten Geräte konfigurieren und diagnostizieren, ohne detaillierte Kenntnisse von den verwendeten Kommunikationstechniken zu haben. Dazu kann er auch Apps auf mobilen Endgeräten verwenden.

Der Nutzer kann auch aus den erfassten Daten im Sinne von „Big Data“ neue Informationen generieren. Wo die jeweilige Umsetzung erfolgt, liegt in der Entscheidung des Systementwicklers. Bus-und Netzwerk-unabhängige Profile würden das Mapping in den Geräten mit Gateway-Funktionalität vereinfachen.