Steuerungstechnik
|
Elektrotechnik
CANopen-Netzwerke in Gebäudeaufzügen
ep3/2009, 3 Seiten
Von CAN zu CANopen Seit den 1990er Jahren gingen Hersteller von Steuerungssystemen für Aufzugsanwendungen dazu über, die einzelnen Sensoren und Antriebe über serielle Bussysteme mit der Steuerung zu verknüpfen. Verglichen mit der herkömmlichen direkten Verdrahtung konnte durch dieses Vorgehen der Verdrahtungsaufwand erheblich gesenkt werden. Zum einen konnten somit die Verkabelungskosten verringert werden. Zum anderen führte die übersichtliche Architektur zu einer geringeren Zahl von Verdrahtungsfehlern. Des Weiteren können Systeme, die auf einem seriellen Bussystem basieren, verhältnismäßig einfach um weitere Funktionalität erweitert werden und bieten komfortable Diagnosemöglichkeiten. Das für den Einsatz in Automobilen entwickelte serielle Bussystem CAN (Controller Area Network) wird in Anwendungen zur Aufzugssteuerung bereits seit einigen Jahren eingesetzt. Um den Aufwand für Systemintegration und -wartung so gering wie möglich zu halten, müssen jedoch Vereinbarungen getroffen werden, die weit über die der CAN-Spezifikation hinausgehen. Mit dem höheren CAN-basierenden Protokoll CANopen werden standardisierte Kommunikationsdienste eingeführt, die einheitliches Netzwerkmanagement sowie eine einheitliche Übertragung von Applikationsdaten ermöglichen. Um einen gewissen Grad an „plug and play“- Funktionalität von Geräten im System zu erzielen, ist es jedoch nicht ausreichend, die Kommunikation zu standardisieren. Es muss ebenfalls die Geräte-interne Verwaltung der applikationsspezifischen Daten beschrieben werden. Dieser Grad der Standardisierung wird mit CANopen Applikationsprofilen erreicht. Das CANopen Profil CiA 301 In modular aufgebauten Steuerungssystemen wird CANopen häufig auf der Hierarchieebene der eingebetteten oder tief eingebetteten Netzwerke eingesetzt. CANopen ist ein standardisiertes höheres Protokoll (EN 50325-4), dass auf CAN basiert. CAN wurde Anfang der 80er Jahre für Anwendungen im Automobil entwickelt und ist ein sehr robustes und flexibles Steuernetzwerk. Des Weiteren sind auf Grund der von der Automobilindustrie benötigten hohen Stückzahlen CAN-Bausteine zu relativ niedrigen Kosten verfügbar. Diese Eigenschaften machten den CAN-Bus auch für viele andere Anwendungsgebiete attraktiv. Da CAN die Schichten 1 und 2 des OSI Referenz-Modells umfasst, ist die Entwicklung eines standardisierten, höheren Protokolls erforderlich. Anfang der 90er Jahre wurde das höhere Protokoll CANopen mit Blick auf den modularen Maschinenbau entwickelt. Da CANopen Netzwerke sehr flexibel konfigurierbar sind, findet man sie heute in den verschiedensten Anwendungsbereichen (z. B. in medizinischen Geräten, öffentlichen Verkehrsmitteln, Eisenbahnanwendungen, Gebäudeautomatisierung, etc.). Ein CANopen Gerät verwaltet seine Kommunikations- und Applikationsparameter im CANopen Objektverzeichnis (Bild ). Das Objektverzeichnis repräsentiert die Schnittstelle zwischen Protokoll-Einheit und Applikation (Bild ). 2.1 Kommunikationsobjekte CANopen bietet standardisierte Kommunikationsobjekte für die Übertragung von Prozessdaten (process data object, PDO) und Konfigurationsdaten (service data object, SDO). Ein synchrones Netzwerkverhalten kann durch den Einsatz des SYNC-Objektes erzielt werden. Zusammen mit weiteren Kommunikationsobjekten, wie dem Zeitstempel, dem Emergency Objekt oder den Error Control Nachrichten, erlaubt CANopen eine sehr flexible und exakt auf die jeweilige Anwendung abgestimmte Konfiguration des Netzwerks. Elektropraktiker, Berlin 63 (2009) 3 224 FÜR DIE PRAXIS Steuerungstechnik CANopen-Netzwerke in Gebäudeaufzügen R. Zitzmann, Nürnberg Das für den Einsatz in Automobilen entwickelte serielle Bussystem CAN (Controller Area Network) wird in Anwendungen zur Aufzugssteuerung bereits seit einigen Jahren erfolgreich eingesetzt. Mit dem höheren CAN-basierenden Protokoll CANopen werden standardisierte Kommunikationsdienste eingeführt, die einheitliches Netzwerkmanagement sowie eine einheitliche Übertragung von Applikationsdaten ermöglichen. Der Beitrag geht auf Grundlagen von CANopen sowie insbesondere auf das CANopen Applikationsprofil CiA 417 für die Aufzugssteuerung ein. Autor Dipl.-Ing. (Univ.) Reiner Zitzmann ist Leiter der technischen Abteilung der internationalen Nutzer- und Herstellervereinigung CAN in Automation (CiA) in Nürnberg. Indexbereich Beschreibung 0000h Reserved 0001h to 025Fh Data types 0260h to 0FFFh Reserved 1000h to 1FFFh Communication profile area 2000h to 5FFFh Manufacturer-specific profile area 6000h to 9FFFh Standardized profile area A000h to AFFFh Network variables B000h to BFFFh System variables C000h to FFFFh Reserved Die allgemeine interne CANopen Gerätearchitektur - das Objektverzeichnis als Schnittstelle zwischen Kommunikations- und Applikationseinheit Das CANopen Objektverzeichnis - jede zu kommunizierende Information ist via Index und Subindex eindeutig adressiert 2.2. Netzwerkmanagement Zusätzlich ist in CANopen eine Statusmaschine definiert, die Netzwerkmanagement ermöglicht (NMT state machine). Zu Zwecken der Konfiguration, Herstellung der Betriebsbereitschaft oder des logischen Abkoppelns vom Netzwerkbetrieb können Netzwerkteilnehmer mit Hilfe der NMT Nachrichten in bestimmte Netzwerkmanagement-Zustände geschalten werden. 2.3 CANopen Geräte-und Applikationsprofile Um einen gewissen Grad an „plug and play“- Funktionalität von Geräten im System zu erzielen und die Systemintegration weiter zu vereinfachen, müssen Vereinbarungen getroffen werden, die über jene der CANopen Spezifikation hinausgehen. Je weiter die Standardisierung z. B. mittels CANopen Geräte- und Applikationsprofilen vorangetrieben wird, desto geringer wird der Aufwand für die Systemintegration. 2.3.1 Geräteprofile CANopen-basierende Geräteprofile legen exakt fest, welche Kommunikationsobjekte und Applikationsparameter unterstützt werden müssen und wie sich die Prozessdaten zusammensetzen. Darüber hinaus wird in CANopen Geräteprofilen ein Standardverhalten des Gerätes festgelegt. Auf der Basis dieses Standardverhaltens bieten die CANopen Geräte- und Applikationsprofile noch Platz für die Implementierung eines herstellerspezifischen Geräteverhaltens. 2.3.2 Applikationsprofile CANopen Applikationsprofile definieren, zusätzlich zu den Geräteprofilen, noch die Prozessdatenkommunikation innerhalb des Netzwerks. Dies hat zur Folge, dass die einzelnen Geräte einfach an das Steuernetzwerk angeschlossen werden können. Eine aufwändige Einrichtung der Querkommunikation durch den Systemintegrator entfällt. Das Applikationsprofil CiA 417 für Aufzugssteuerung Die internationale Nutzer- und Herstellervereinigung CAN in Automation (CiA) hat zusammen mit ihren Mitgliedern das CANopen Applikationsprofil für Aufzugssteuerungssysteme (CiA 417) entwickelt. Dieses auf dem höheren Protokoll CANopen basierende Applikationsprofil ermöglicht die Beschreibung von kompletten Aufzugssystemen auf standardisierte Art und Weise. Von dem standardisierten Profil profitieren sowohl Zulieferer von Aufzugskomponenten als auch die Hersteller der Aufzugssysteme. Die Standardisierung führt zu einer Reduktion der Variantenvielfalt und somit zu steigenden Stückzahlen. Für die Aufzugshersteller ergibt sich daraus im Allgemeinen ein besseres Preis/Leistungsverhältnis. Des Weiteren sind CANopen konforme Geräte nach einem Minimum an Konfigurationsaufwand zum Einsatz im Aufzugssystem bereit. Das Applikationsprofil für Aufzugssteuerungsanwendungen CiA 417, welches auch unter dem Namen CANopen-Liftprofil bekannt ist, spezifiziert die Kommunikation eines Aufzugssteuerungssystems mit bis zu acht Aufzügen für bis zu 254 Stockwerke. Es bietet auch Freiraum, die Standardkommunikation so zu konfigurieren, dass anwenderspezifische Funktionen implementiert werden können. 3.1 Virtuelle Geräte Grundlage des Profils ist die Definition von Funktionsblöcken; so genannten „virtuellen Geräten“ (Bild ). Die folgenden virtuellen Geräte wurden definiert: · Antriebssteuerung, · Rufsteuerung, · Display-Steuerung, · Kabinentürsteuerung, · elektrische Antriebseinheit, · Kabinenpositionierungs-Einheit, · Kabinentür, · Lichtschranke, · Kabinen-Panel, Elektropraktiker, Berlin 63 (2009) 3 225 Index Beschreibung 6000h to 60FFh Physical device 6100h to 67FFh Lift 1 6800h to 68FFh Reserved 6900h to 6FFFh Lift 2 ... 9800h to 98FFh Reserved 9900h to 9FFFh Lift 8 Index Beschreibung 6100h to 61FFh Panel input unit 6200h to 62FFh Panel output unit 6300h to 630Fh Car acor unit 6310h Light barrier unit 6311h to 637Fh Reserved 6380h to 63FFh Car position unit 6400h to 647Fh Car drive unit 6480h to 64FFh Load measuring unit 6500h to 657Fh Sensor unit 6580h to 67FFh Reserved Die virtuellen Geräte nach CiA 417 - gemäß Adressierungsschema kann ein Steuerungssystem für bis zu 8 Aufzüge realisiert werden Jetzt bestellen! Mit Sachverstand verantwortungsbewusst Handeln Ich bestelle zur Lieferung gegen Rechnung zzgl. Versandspesen zu den mir bekannten Geschäftsbedingungen beim huss-shop, HUSS-MEDIEN Gmb H, 10400 Berlin Expl. Bestell-Nr. Titel /Stück 3-341-01526-1 Pester, Explosionsschutz elektrischer Anlagen 48,00 KUNDEN-NR. (siehe Adressaufkleber oder letzte Warenrechnung) Firma/Name, Vorname Branche/Position/z. Hd. Telefon/Fax E-Mail Straße, Nr./Postfach Land/PLZ/Ort Datum/Unterschrift ep0903 Preisänderungen und Liefer möglichkeiten vorbehalten NEU 10 % Preisvorteil für ep-Abonnenten HUSS-MEDIEN Gmb H 10400 Berlin Direkt-Bestell-Service: Tel. 030 42151-325 · Fax 030 42151-468 E-Mail: bestellung@huss-shop.de www.huss-shop.de Wer als Elektrofachkraft für explosionsgefährdete Betriebsanlagen Verantwortung zu übernehmen hat, ob als Planer, Errichter oder in der Instandhaltung, braucht kritischen Sachverstand. Wichtig sind Kenntnisse der Methoden und Maßnahmen des Explosionsschutzes, der Rechtsnormen, Regeln und technischen Normen sowie eine richtige Einschätzung der eigenen Kompetenz. Durch die thematisch geordnete Übersicht aller Fragen im Inhaltsverzeichnis finden Sie schnell die gesuchten Antworten. Pester, Explosionsschutz elektrischer Anlagen, 3., aktual. Aufl. 2008, 398 S., 122 Abb., Broschur, Bestell-Nr. 3-341-01526-1, 48,00 Elektropraktiker, Berlin 63 (2009) 3 226 FÜR DIE PRAXIS Steuerungstechnik · Kabinen-Display, · Sensor-Einheit, · Lastenmess-Einheit, · Eingabe-Panel, · Ausgabe-Panel. Jedes der aufgelisteten virtuellen Geräte hat spezifische Funktionen. Manche dieser Funktionen sind optional, andere verpflichtend zu unterstützen. Die Funktion der virtuellen Geräte vom Typ Eingabe-Panel ist es beispielsweise, den Ruf von Fahrgästen in jedem Stockwerk oder in der Aufzugskabine entgegenzunehmen und diesen via CANopen an die Rufsteuerung zu übertragen. Diese Übertragung enthält Informationen über den Ausgangsort des Rufes (z. B. von welchem Stockwerk) sowie über die Art des Rufes (normaler Gebrauch, Notfall, Feuer, usw.). Die Funktion der Rufsteuerung ist es dann, die empfangenen Informationen zu bearbeiten und den Empfang der Informationen mit einer CANopen-Nachricht an die (Ausgabe-) Panels zu bestätigen. Somit leuchtet der gedrückte Knopf des Panels auf und gibt dem Fahrgast die Information, dass sein Ruf akzeptiert ist und bearbeitet wird. Ebenfalls wird via CANopen ein entsprechendes, vordefiniertes Signal an die Kabinenantriebssteuerung und die Türsteuerung der Kabine gesendet. Der Aufzug setzt sich gemäß dem Fahrtwunsch in Bewegung. 3.2 Querkommunikation Die für das eben beschriebene Szenario erforderliche Querkommunikation zwischen den einzelnen Netzwerkteilnehmern basiert hauptsächlich auf dem Prozessdatenobjekt (PDO). Für jedes virtuelle Gerät sind die PDOs fest vordefiniert. Dies erlaubt es Zulieferern, Geräte anzubieten, die fast ohne weitere Konfiguration in Systemen nach CiA 417 in Betrieb genommen werden können. Eine Übersicht der vordefinierten PDOs ist in Bild dargestellt. Darüber hinaus wird von jedem CANopen-Gerät im CANopen-Lift-Netzwerk das multiplex PDO (MPDO) unterstützt. Diese Sonderform des herkömmlichen PDOs ermöglicht es den Geräten untereinander, beliebige Prozessdaten mit einer maximalen Größe von 32 bit auszutauschen. Somit ist eine PDO-Totalvermaschung gewährleistet. Über die standardisierte PDO-Vermaschung hinaus ist sogar noch beliebige Querkommunikation zwischen den Netzwerkteilnehmern realisierbar. 3.3 Datenverwaltung Da die geräteinterne Verwaltung der Daten ebenfalls exakt definiert ist, vereinfacht sich die Wartung von Aufzugssystemen nach CiA 417 erheblich. Ein Servicetechniker muss nur einmal lernen, wo welche Geräte welche Information in ihrem Objektverzeichnis ablegen. Dieses Wissen kann er dann in allen Liftsteuerungssystemen anwenden, die nach CiA 417 ausgelegt sind. Für jedes virtuelle Gerät wird exakt festgelegt, wo diese Information im Objektverzeichis verwaltet wird (Index/Subindex), und wie diese Daten zu interpretieren sind. Zum Beispiel stellt die Kabinentürsteuerung die Steuerbefehle zum Öffnen und Schließen der bis zu vier Kabinentüren in Objekt 6300h bereit. Im Gegenzug informieren die Kabinentüren über ihren aktuellen Status im Objektverzeichniseintrag 6301h 01h bis 04h. Somit kann im Bedarfsfall jeder Zeit der Status jeder Tür mittels SDO abgefragt werden. Ein aufwändige Suche im Nutzerhandbuch entfällt. Die Definitionen der virtuellen Geräte Kabinenposition und Antriebseinheit wurden entsprechend der CANopen Geräteprofile CiA 406 (Encoder) bzw. CiA 402 (elektrische Antriebe) vorgenommen. Das heißt, die Spezifikationen der Prozessdaten und der Konfigurationsparameter sind nicht in CiA 417 enthalten. Das Lift-Profil referenziert auf die entsprechenden Geräteprofile. Wenn auch die Applikationsdaten an anderer Stelle im Objektverzeichnis verwaltet werden (anderer Index/Sub-index), sind dennoch die Objektbeschreibungen äquivalent. Um möglichst komplexe Aufzugssteuerungssysteme gemäß dem Profil CiA 417 abbilden zu können, wurde der Profilbereich des Objektverzeichnisses (Index 6000h bis 9FFFh) in acht Teilbereiche mit jeweils einem Offset von 800h aufgeteilt (siehe Bild ). Jeder Teilbereich wurde einem Aufzugsschacht zugeordnet. Mit dem Applikationsprofil kann man also Systeme mit bis zu acht Aufzugsschächten beschreiben, wie sie gegebenenfalls für moderne Krankenhäuser oder Bürokomplexe benötigt werden. Das Profil CAN-open-Lift spezifiziert sämtliche PDOs für alle acht Aufzüge. Zusammenfassung Im Jahr 2004 wurde damit begonnen, Aufzugssteuerungsanwendungen gemäß CiA 417 zu installieren. Allerdings nutzten diese Anwendungen erst einen Teil der im Profil CiA 417 beschriebenen Funktionalität. So wurden beispielsweise Ruf- und Kabinensteuerung in einer zentralen Steuerung integriert. Die Ansteuerung der Panels sowie die Anbindung der Kabinenpositionierungs-Einheit wurden mittels generischer CANopen-Netzwerke realisiert. In der Zwischenzeit basieren einige Anwendungen zur Steuerung von Aufzügen auf dem Liftprofil. Alleine im neuen Berliner Hauptbahnhof wurden 36 entsprechende, CiA 417 basierende, Aufzugssteuerungsanwendungen installiert. Anbieter von Aufzugssteuerungskonzepten entscheiden sich für CANopen-Netzwerke, da CANopen zum einen sehr flexibel an die Anforderungen der jeweiligen Applikation anpassbar ist. Andererseits zeigen sich CAN-open-Netzwerke robust gegenüber Störeinflüssen und die erforderlichen Hardware-Bausteine (CAN controller/transceiver) sind preiswert verfügbar, da sie in hoher Stückzahl für die Automobilindustrie benötigt werden. CANopen-konforme Geräte können von verschiedenen Herstellern gekauft werden und sind mit einem Minimum an Konfigurationsaufwand untereinander betriebsbereit. Somit kann viel Zeit und Geld bei Systemintegration und Diagnose gespart werden. Informationen zu CANopen sowie zu Firmen, die Geräte nach dem Lift-Profil entwickeln, sind unter www.can-cia.org erhältlich. PDO Beschreibung PDO1 Not used PDO2 to PDO128 MPDO PDO129 Not used PDO130 to PDO256 Virtual input PDO257 to PDO272 Lift 1 PDO273 to PDO288 Lift 2 ... PDO369 to PDO384 Lift 8 PDO385 Not used PDO386 to PDO512 Sensor input PDO Beschreibung PDO257 Virtual output PDO258 Not used PDO259 Load measuring PDO260 Not used PDO261 to PDO264 Car drive control and status PDO265 to PDO268 Car position sensor 1 to 4 PDO269 to PDO270 Car door control and status PDO271 Light barrier PDO272 Car door position Vordefinierte Prozessdatenobjekte (PDOs) nach CiA 417 für bis zu 8 Aufzüge Quelle: CAN in Automation (CiA) megacom ist ein deutscher Hersteller für Ortungssysteme zum Auffinden verunfallter Personen, zu einem hervorragenden Preis-Leistungs-Verhältnis. Nähere Infos unter Telefon 04191 90850 oder www.megacom-gmbh.de Anzeige
Autor
- R. Zitzmann
Downloads
Laden Sie diesen Artikel herunterTop Fachartikel
In den letzten 7 Tagen:
Sie haben eine Fachfrage?