Erfahrungen mit CANopen-Lift Netzwerken

von Holger Zeltwanger, CAN in Automation (www.can-cia.org/lift)

CiA 417-basierendes System steuert drei Aufzüge

Moderne Aufzüge benutzen zunehmend dezentralisierte und verteilte Steuerungssysteme. Diese Steuerungssysteme erfordern Kommunikationsnetzwerke, welche die Steuerungen mit den „intelligenten“ Sensoren und die Aktoren verbindet. Der Grad der Kompatibilität ist ein wichtiger Kernpunkt, wenn Sie Standardprodukte kaufen und verwenden wollen.

Der IEC T(echnical) R(eport) 62390 definiert den Grad der Kompatibilität für Netzwerkschnittstellen. Speziell für „low volume” Applikationen ist es notwendig hoch kompatible Netzwerkschnittstellen zu verwenden, um den Aufwand bei der Installation zu minimieren und so Kosten zu sparen.

Dagegen spricht jedoch der Umstand, dass Standardisierung die Weiterentwicklung der Technologie hemmen kann. Um flexibel und zukunftsgerecht zu sein, sollte es möglich sein, die Definitionen der Schnittstellen auszuweiten und zu verstärken. Flexibilität ist einer der Schlüssel einer Netzwerktechnologie, die in Applikationen für Aufzugsteuerung verwendet werden.

Netzwerktechnologie

Das Controller Area Network (CAN), ist eine vielfach bewährte Netzwerktechnologie. Mit dem standardisierten Physical Layer (ISO 11898-2) und dem standardisierten Data Link Layer (ISO 11898-1) sind Millionen CAN-Knoten im Einsatz zum Beispiel in PKWs, aber auch in anderen Steuerungssystemen, einschließlich der vieler Maschinensteuerungen, medizinischer Elektronik, Schienenfahrzeugen und vielen anderen Anwendungen.

CAN-Transceiver und CAN-Controller werden von über 50 Firmen weltweit angeboten. Die CAN-Controller sind gewöhnlich in die Microcontroller integriert, was die Hardwaregestaltung vereinfacht. Das CAN Data Link Layer Protokoll (EN 50325-4) wurde ursprünglich für integrierte Maschinensteuerungen entwickelt. In 2004 wurden bereits ca. 1 Millionen CANopen-Geräte verkauft, die in Anwendungen wie „off-highway“ Fahrzeugen, elektronisch gesteuerten Gebäudetüren und eingebettete Steuerungssysteme eingesetzt werden.

Der CANopen-Application-Layer sorgt für den Kommunikationsservice der Datenübertragung in Echtzeit, für Laden und Schreiben der Geräteparameter und Diagnoseinformationen, so wie für Fehlernachrichten. Diese standardisierten Kommunikationsdienste verwenden standardisierte Protokolle, z. B. das PDO (process data object) Protokoll, SDO (service data object) Protokoll oder EMCY (emergency) Protokoll.

Das CANopen-Kommunikationsprofil (EN 50325-4) definiert ein CANopen-Objektverzeichnis. Dieses Verzeichnis ist adressierbar mittels eines 16-bit Indexes und eines 8-bit Sub-Indexes. Dieses 24-bit Adressierschema löst die Beschränkung durch den 11-bit CAN-Identifierer (2,048 adressierbare Objekte) ab. Das Verzeichnis ist das “Herz” jedes CANopen-Gerätes.

Das Objektverzeichnis stellt die Verbindung zwischen dem CANopen-Protokoll-Stack und der Anwendungssoftware her. Es ist zugänglich von beiden Seiten: Sie können in ein Objekt über das CAN-Netzwerk schreiben und die Anwendungssoftware kann es lesen, oder umgekehrt. Im Bereich des Kommunikationsprofils eines CANopen-Objektverzeichnisses befinden sich alle Objekte, die das Verhalten des Netzwerkes definieren. Ein CANopen-Gerät ist so gestaltet, dass es bis zu acht logische Anwendungen versorgt, die als Applikation 1 bis Applikation 8 bezeichnet werden könnten. Im Falle des Applikationsprofils Lift Control repräsentiert jede der acht Applikationen einen einzelnen Aufzug. Dies wird durch die Struktur des CANopen-Profils im Bereich der Objekte 6000h bis 9FFFh erkennbar. Sie ist virtuell aufgeteilt in acht Sektionen von je 800h Indices. Somit lässt sich die Anwendung einer 8er-Gruppe von Aufzügen über einen durchgängigen Adressraum abbilden.

Im Applikationsprofil repräsentieren virtuellen Geräte die Geräteschnittstellen. Bei Aufzügen kann dies zum Beispiel ein Tableau, eine Kabinentürsteuerung, ein Sensor oder eine Rufsteuerung sein. Nur die Anzahl der Objekte reguliert die Anzahl der virtuellen Geräte. Insgesamt stehen 1.280 Objekte für alle virtuellen Geräte zur Verfügung und jedes einzelne Objekt kann bis zu 254 Sub-Objekte haben, wenn der Objekttyp vom Typ »Array« oder »Record« ist.

Benutzt man dieses Modell, kann man auch für den Nutzer transparente Knoten beschreiben. Diese Knoten können CANopen-zu-CANopen-Gateways oder CANopen-Gateways zu anderen Netzwerktechnologien sein. Mit diesem Konzept können auch herstellerspezifische Bussysteme angebunden werden.

Applikationsprofil

Kompatibilitätsgrade basierend auf IEC TR 62390

Compatibility levels based on IEC TR 62390

Das CANopen-Lift Applikationsprofil (CiA-417) basiert auf diesem Konzept von logischen und virtuellen Geräten.

Eines der wichtigsten herausfordernden Zielen bei der Systemgestaltung ist die Zuordnung und Verteilung von CAN- Identifier zu den CANopen-Kommunikationsobjekten (COB). Das Format des Grundrahmens des CAN-Data-Link-Layer-Protokolls verwendet einen 11-bit Identifier, der einzig an die übertragene Nachricht vergeben werden muss. Dieser Identifier definiert den Inhalt der Daten und seine Priorität im Netzwerk. Das CANopen-Lift Applikationsprofil definiert alle COBs vor. Der CANopen Application Layer definiert die CAN-Identifier, die für die SDOs verwendet werden, für Fehlernachrichten, NMT (network management) Kommandos, Heartbeat und Boot-Up-Nachrichten. Sie leiten die Knoten-IDs von dem physikalischen CANopen-Gerät ab, welche einzig von dem Systemdesigner zugeordnet werden.

Process Data Object (PDO) assignment to virtual devices

Die CAN-Identifier für die PDOs, welche die Daten in Echtzeit übertragen, sind durch den CiA 417-3 Standard definiert. Jedes physikalische Gerät, das konform mit diesem Applikationsprofil ist, liefert ein MPDO im Destination Address Mode zur Broadcast-Übertragung (addr = 0) und bis zu 127 MPDOs zum Empfangen. Abhängig vom Multiplexort (ensprechend dem Index und Sub-Index des CANopen-Objektverzeichnisses) werden die empfangenen MPDOs übernommen und die empfangenen Daten in das Objektverzeichnis geschrieben oder sie werden ignoriert. Standardmäßig überträgt der Versender der MPDOs (der Producer) alle Objekte des physikalischen Gerätes automatisch, für die das Attribut »PDO-Mapping« gesetzt ist. Zusätzlich können MPDOs genutzt werden, um die Anwendungsbedingten PDO-Mapping Attribute mit den möglichen Werten zu übertragen.

Process Data Object (PDO) Zuordnung zu virtuellen Geräten

Einige virtuelle Geräte unterstützen zusätzlich PDOs mit vordefinierten Mappings und vordefinierten CAN-Identifiern. Andere virtuelle Geräte unterstützen PDOs mit vordefinierten Mappings und CAN-Identifiern in Abhängigkeit von der zugeteilten Knoten-ID. Eintragungsindexe im Objektverzeichnis für Kommunikationsparameter und PDO-Mapping-Parameter, die in diesem Teil des Applikationsprofils gegeben wurden, sind zwingend. Das kann einige Kombinationen von virtuellen Geräten in einem physikalischen Gerät ausschließen. Der Systemdesigner kann andere Eintragungsindexe im Objektverzeichnis für die Kommunikationsparameter und PDO-Mapping Parameter verwenden. Hinweis: In diesem Fall ist aber der Systemdesigner für die Richtigkeit der PDO-Parameter verantwortlich.

Erste Erfahrungen

Gerätemodell basierend auf IEC TR 62390

Device model based on IEC TR 62390

Aufzugsteuerungssysteme, die auf CiA 417 basieren, wurden seit Anfang 2004 eingesetzt. Diese Steuerungssysteme benutzten anfänglich nur eine Teilmenge der Schnittstellen der definierten virtuellen Geräte. In einer dieser Anwendungen sind die Ruftableaus, die Kabinenelektronik und das absolute Positonierungssystem per CANopen-Netzwerk an die Steuerung angebunden. Die anderen Geräte wurden noch über nicht standardisierte Schnittstellen angesteuert. In Genf/Schweiz wurde eine 3er-Gruppe von Aufzügen realisiert, die über CANopen miteinander vernetzt sind. Die Knoten zwischen den verschiedenen Teilnetzwerken sind Anwendertransparent, was bedeutet, dass das gesamte Netzwerksystem logisch ein Netzwerk ist. Bei einem anderen Projekt am Lehrter Bahnhof in Berlin/Deutschland, basieren 36 Einzelaufzüge und 2er Gruppen auf dem CANopen-Lift Applikationsprofil. Insgesamt wurden seit 2004 schon über 1.300 auf CiA 417 basierende Aufzüge montiert. Bei all diesen Systemen kam es bisher nur einmal bei einem Aufzug zu sporadischen Fehlermeldungen, auf Grund eines falsch angeschlossen Terminierungswiderstands.

Verfügbarkeit von CiA-Produkten

Die Anzahl der verfügbaren Produkte, die konform sind mit CiA 417, ist noch gering. Insbesondere kompatible Antriebe, Kabinentüren und Notrufgeräte sind noch nicht serienmäßig verfügbar. Jedoch sind sie in Entwicklung. Das CANopen-Lift Applikationsprofil ermöglicht den Aufbau von Systemen mit bis zu acht Aufzügen, die jeweils bis zu 254 Etagen bedienen können. Das Konzept der logischen und virtuellen Geräte sowie nutzertransparenter Knoten vereinfachen die CAN- Identifier-Zuweisung und Verteilung. Die Erfahrungen, die bei den ersten Installationen gemacht wurden zeigen, dass das Konzept die Erfordernisse abdeckt. Zusätzliche Funktionen (wie Notrufe), die nicht in der ersten Version der CANopen-Spezifikation definiert waren, werden in die nächste Version des Applikationsprofils aufgenommen.

Quelle: CAN Newsletter Special Lift 2005 (www.can-cia.org/newsletter)