Standardisierte Vernetzung von Aufzugskomponenten auf der Grundlage der CiA-417 Lift Control
von Jörg Hellmich, Böhnke + Partner GmbH (http://www.boehnkepartner.de)
Kurzfassung
Allgemein werden technische System immer komplexer. Immer mehr elektronische Systeme bringen neue Funktionen, erhöhen den Komfort oder verbessern die Sicherheit eines Systems. Meist sind diese elektronischen System mit kleinen embedded Mikroprozessoren ausgerüstet. In Abhängigkeit von Signalen die Sensoren oder Eingänge zur Verfügung stellen, bestimmen diese Prozessoren nach den Algorithmen der internen Firmware die Funktionalität der Baugruppe. Je mehr Informationen über das System zur Verfügung stehen, um so breiter ist die Basis auf der Entscheidungen gefällt werden können.
Damit die elektronischen Baugruppen in einem System zusammen arbeiten und interne Informationen oder Kommandos austauschen können, müssen Sie über einen Feldbus miteinander vernetzt werden.
In der Automatisierungsindustrie finden verschieden Feldbusse mit unterschiedlichen Eigenschaften Anwendung.
In der Aufzugsindustrie kommen verschiedene proprietäre Busse und der standardisierte Feldbus CANopen-Lift (CiA-417).
Dieser Artikel stellt den grundsätzlichen Aufbau, die Eigenschaften und Vorteile gegenüber proprietären Systemen vor und gibt einen Einblick in die Organisationsstrukturen der Entwicklergemeinde, die hinter den System steht.
Abschließend werden Funktionen beschrieben, die nur Aufgrund der offenen Vernetzung der Komponenten verschiedener Hersteller möglich sind und es wird ein Ausblick auf kommende Entwicklungen gegeben.
Hintergrund
Aufzüge werden immer komplexer. Immer mehr elektronische Geräte werden in Aufzügen verbaut, um die steigenden Ansprüche an Funktionalität, aktuelles Normenwerk und Sicherheitsanforderungen erfüllen zu können.
In den elektronischen Geräten arbeiten meist embedded Mikroprozessoren, die in Abhängigkeit ihrer Eingangssignale oder von Sensordaten, Ausgangssignale bzw. Nachrichten erzeugen. Art und Zeitpunkt der Signale werden auf Grund von Algorithmen der internen Firmware erzeugt und bestimmen somit die Funktionalität der Baugruppe. Je mehr Informationen über das Gesamtsystem zur Verfügung stehen, um so breiter ist die Basis auf der Entscheidungen gefällt werden können.
Damit die elektronischen Baugruppen in einem System zusammen arbeiten und interne Informationen oder Kommandos austauschen können, müssen Sie über einen Feldbus miteinander vernetzt werden. Mit der Einführung der EN81 steht bei allen neu errichteten bzw. modernisierten Aufzügen ein Telefonanschluss für den Notruf zur Verfügung. Dieser kann jedoch meist exklusiv durch das Notrufgerät verwendet werden. Somit kann zum Beispiel ein Türsteuergerät den vorhandenen Telefonanschluss nicht benutzen, um Störungsmeldungen bzw. Wartungsinformationen abzusetzen. Das Notrufgerät könnte zwar Kommunizieren, es weiß jedoch nichts von dem internen Fehler des Türsteuergerätes.
Ein Monteur erfährt von dem gestörten Gerät erst durch den Anruf eines sich beschwerenden oder gar eingeschlossenen Benutzers und muss sich zur Fehlerdiagnose unverzüglich zum Aufzug begeben.
Um dies zu verbessern, müssten das Türsteuergerät und das Notrufgerät miteinander kommunizieren können.
Definition
Kommunikation [latein: communicare]
teilen, mitteilen, teilnehmen lassen, gemeinsam machen, vereinigen
Störungen einer Kommunikation
Bei einer Kommunikation wird eine codierte Nachricht mit einem definierten Zeichensatz über ein bestimmtes Medium von einem Sender zu einem Empfänger transportiert und es gibt eine codierte Rückmeldung an den Sender. Die Kommunikation findet in einem bestimmten Kontext statt.
Durch verschiedene äußere Einflüsse kann eine Kommunikation gestört werden. Es werden Mechanismen benötigt, um eine gestörte Nachricht zu erkennen und gegebenenfalls erneut zu senden.
Elemente der Kommunikation
Um miteinander kommunizieren zu können, benötigt man:
- eine Sprache/Protokoll verbal/nonverbal
- ein Übertragungsmedium/Nachrichtenkanal
- Regeln für die Kommunikation
- eventuell einen Gesprächsleiter/Moderator/Master
Arten der Kommunikation
An Abhängigkeit der Anzahl der teilnehmenden Elemente an einer Kommunikation, unterscheidet man die folgenden Kommunikationsarten.
Monolog
Ein Teilnehmer sendet Nachrichten und mindestens ein Teilnehmer empfängt die Nachrichten und gibt eine Rückmeldung.
Dialog
Zwei Teilnehmer senden sich gegenseitig codierte Nachrichten
Multimaster Kommunikation
Viele Teilnehmer senden sich gegenseitig Nachrichten.
In der menschlichen Kommunikation hat sich diese Kommunikationsart als unpraktisch erwiesen, da zu viele Nachrichten gestört werden. In technischen Systemen ist eine Multimaster-Kommunikation möglich, ohne das Nachrichten zerstört werden. Hier wird z. B. das Prinzip der priorisierten Nachrichten angewendet.
Bei dieser Art der Kommunikation können mehrere Sender über ein Übertragungsmedium gleichzeitig beginnen eine Nachricht zu senden. Durch einen der Nachricht vorangestellten Identifier wird bestimmt, welche Nachricht die höchste Priorität hat. Nach dem Identifier wird die Nachricht mit der höchsten Priorität ohne Verzögerung gesendet und Nachrichten mit niedrigeren Prioritäten zeitlich zurück gestellt.
Durch dieses Verfahren werden keine Nachricht zerstört. Eine Echtzeitkommunikation ist möglich.
Technik im Aufzug
Übersicht verschiedene Bussysteme
Damit die elektronischen Geräte eines Aufzugs miteinander kommunizieren können, müssen Sie über einen Feldbus miteinander verbunden werden.
Aktuell gibt es mehrere in der Industrie verbreitete Feldbussysteme mit unterschiedlichen technischen Eigenschaften. So gibt es zum Beispiel Systeme die mit geringer Bandbreite nur wenige Nachrichten über sehr große Entfernungen übertragen können und andere, die mit hoher Bandbreite große Datenmengen über kurze Distanzen übertragen können. Je nach Anforderung des Systems, in dem ein Feldbussystem zum Einsatz kommen soll, wählt man den Feldbus, mit den für den jeweiligen Einsatzbereich besten Eigenschaften aus.
| Bezeichnung | Einsatzbereich |
| Bacnet | Gebäudeautomation |
| CAN | Fahrzeuge, Roboter, Maschinen |
| EIB | Gebäudeautomation |
| Ethernet | Internet, Gebäudeautomation, Produktionsanlagen |
| Interbus | Produktionsanlagen |
| LON | Gebäudeautomation |
| Profibus | Produktionsanlagen |
| RS485 | proprietäre Systeme |
Vorteile und Nachteile
Nach einer ausführlichen Analyse der einzelnen Systeme haben sich viele europäische Komponentenhersteller für den CAN-Bus als Feldbus für den Aufzug entschieden.
Hauptkriterien sind die Echtzeitfähigkeit, Sicherheit, Geschwindigkeit sowie die Lizenzfreiheit, Herstellerunabhängigkeit, Preis und Verbreitung.
Basierend auf dem CAN-Bus wurde für die standardisierte Kommunikation eine gemeinsame Sprache entwickelt mit der Bezeichnung CANopen-Lift bzw. CANopen CiA-417.
Das Applikationsprofil CANopen-Lift
Mit der Arbeit am Applikationsprofil wurde 2001 begonnen. Im Sommer 2003 wurde die Version 1.0 verabschiedet und im Oktober des gleichen Jahres waren die Prototypen der ersten Produkte auf der Interlift zu sehen.
Das Applikationsprofil hat die Bezeichnung CANopen-Lift bzw. CiA 417 V2.0.
Das Profil beschreibt eine Anwendung (Applikation) mit dem folgenden Umfang:
- eine Achtergruppe von Aufzügen,
- mit 254 Haltestellen
- und 4 Türen je Kabine.
Weiterhin wurden alle Geräte als 'virtuelle Geräte' definiert, die innerhalb dieser Applikation verwendet werden können. Danach wurden die Funktionen der 'virtuellen Geräte' beschrieben und alle Nachrichten, die diese Geräte produzieren bzw. empfangen können. Zu dem Profil gibt es verschiedene Vorschriften und zusätzliche Empfehlungen. So sind zum Beispiel verschiedene Steckverbinder empfohlen, die für Aufzugskomponenten verwendet werden sollten. Die Steckerbelegung der jeweiligen Steckverbinder ist jedoch vorgeschrieben. Weiter wird empfohlen, dass die Schnittstelle der Geräte mit einer Status-LED ausgestattet werden sollte. Ist eine LED vorhanden, ist das Blinken der LED für verschieden Statusmeldungen genormt.
So gibt es weiterhin Empfehlungen für die Kabelfarben der Busleitungen, den Aufbau der Topologie zur Vernetzung der Komponenten, die Vergabe von NodeIDs, die Baudrate bzw. Autobaud-Funktionen, Verfahren für ein Softwareupdate in den Komponenten und vieles weitere mehr.
Somit wird zum einen gewährt, dass die Komponenten am Bus möglichst kompatibel sind und das ein Maximum an Plug-and-Play erreicht wird und zum anderen jedoch bleibt den Komponentenherstellern und dem Aufzugbauer eine sehr große Flexibilität für individuelle Alleinstellungsmerkmale. Die Normung bezieht sich ausschließlich auf die Kommunikation der Komponenten auf dem Systembus. Sie beschreibt nicht die Funktionalität des Gerätes. Dies bleibt weiterhin das Know How des Herstellers.
Prinzip der virtuellen Geräte
Virtuelle Geräte sind abstrakte Softwareobjekte, die ein reelles Gerät repräsentieren (z. B. einen Absolutwertgeber oder ein Türsteuergerät). Das Konzept der virtuellen Geräte wird verwendet, um verschiedene Gerätetypen der gleichen Geräteklasse auf ein gemeinsames Interface abzubilden.
In Applikationsprofilen gibt es in der Regel keine Master/Slave-Kommunikation bezüglich der Prozessdatenobjekte. Im CANopen-Applikationsprofil für Aufzugsteuerungen CiA-417 sind beispielsweise direkt PDO-Verbindungen zwischen der Lifttür und der Türsteuerung definiert.
Bei Applikationsprofilen werden meistens nur virtuelle Geräte spezifiziert. Dadurch kann der Gerätehersteller entscheiden, welche virtuellen Geräte er in ein physikalisches Gerät implementiert.
Um das Prinzip der virtuellen Geräte näher zu betrachten, hier ein kleines Beispiel. Zwei Hersteller von Positionierungssensoren statten ihre Geräte im einer CANopen-Lift-Schnittstelle aus. Das System des einen Herstellers ist ein rotatorischer Encoder, der eine Winkeländerung inkrementel auflöst. Kennt man den Umfang des antreibenden Zahnrads, kann man die Positionsänderung berechnen. Der zweite Hersteller entwickelt einen linearen Encoder, bei dem die Laufzeit eines Impulses direkt die Entfernung zu einem Referenzpunkt bestimmt.
Beide Hersteller implementieren in ihren Encoder das virtuelle Gerät 'position unit' und somit stellen nun beide Geräte am Bus die gleichen Informationen zur Verfügung die Position der Kabine, die Geschwindigkeit der Kabine und optional auch die Beschleunigung der Kabine.
Für das Gesamtsystem Aufzug ist es nicht von Belang, auf welche Weise die Position bestimmt wird. Die Steuerung, der Frequenzumrichter, Diagnosetools und Displays benötigen nur die Positions- und Geschwindigkeitswerte der Kabine. Durch das Prinzip der virtuellen Geräte ergeben sich eine Reihe von Vorteilen. Zum einen kann zum Beispiel der lineare Encoder durch einen rotatorischen Encoder ersetzt werden, wenn dieser nicht lieferbar sein sollte, oder technische Gegebenheiten es verlangen. Weiterhin müssen andere Geräte nichts über die Art oder technische Eigenschaften der Encoder wissen, um auf die Positionsinformation zugreifen zu können. Ein Hersteller eines Displays zum Beispiel programmiert sein Display so, dass die Positionsinformation eines virtuellen Gerätes 'position unit' dargestellt wird. Ist nun ein solches Gerät in dem Aufzug vorhanden, wird die Positionsangabe dargestellt, ohne dass der Displayhersteller den Encoder jemals gesehen haben muss.
Dies gestattet den Aufbau von sehr unterschiedlichen Systemen, deren Topologie nicht vom Applikationsprofil determiniert ist, da man sehr einfach Bridges und Gateways entwickeln kann. So kann der Aufzugshersteller zum Beispiel getrennte CANopen-Netzwerke für die Kabinensteuerung und für die Bedientableaus im Schacht benutzen.
Diagnose
Ein großes Problem bei Bussystemen war in der Vergangenheit die Diagnosefähigkeit. Hier bieten sich durch das Applikationsprofil vielfältige Möglichkeiten.
Erstens kann man natürlich an jedem Gerät eine Status-LED oder ein Display anbringen, wie es bei konventionellen Systemen üblich. Dies hat jedoch den Nachteil, dass ein integriertes Display zum einen mit Kosten verbunden ist und zum anderen muss man an dem Gerät sein, um den Displayinhalt zu lesen.
Weiterhin kann man die 'virtuelle Konsole' nutzen, die in CANopen-Lift definiert ist. Die virtuelle Konsole definiert ein Verfahren, wie ein Gerät den Inhalt des eigenen Displays auf dem Systembus zur Verfügung stellt und wie dieser von anderen Geräten dargestellt werden kann. Weiterhin ist es mit Hilfe von Steuerungskommandos von anderen Geräten aus möglich, durch das Menü zu navigieren. Damit kann nicht nur der Displayinhalt des Frequenzumrichters in der Steuerung dargestellt werden, wie es bei dem DCP-Protokoll möglich ist, sondern es kann das Menü eines jeden Gerätes auf jedem anderen Gerät dargestellt werden, das über ein Display verfügt. Dies muss keine Aufzugskomponente sein. Mit dieser Technik ist es auch möglich, das Menü auf einem Handy darzustellen, das zum Beispiel per Bluetooth auf den CAN-Bus zugreift oder mit einem Diagnosetool von einem Laptop aus.
Ist der Techniker mit einem Laptop ausgestattet, ergeben sich noch weitaus bessere Möglichkeiten der Diagnose. Da die Parametersätze genormt sind, können alle an den Bus angeschlossenen Geräte mit einem einheitlichen Tool parametriert werden.
Diagnose mit Laptop
Steht für die Diagnose und Konfiguration einer Anlage ein Laptop zur Verfügung, ergeben sich viele sehr komfortable Möglichkeiten. Dadurch, dass die Kommunikation und die Parametersätze aller Geräte standardisiert sind, ist es möglich, mit einer einzigen Software alle Geräte eines Aufzugs zu Parametrieren. Ein solches universelles Konfigurationstool ist die Software 'CANwizard®', die schon von mehreren Herstellern eingesetzt wird.
Parametrieren
Nachdem das Laptop mit Hilfe eines frei am Markt erhältlichen Adapters mit dem Systembus verbunden ist, scannt der CANwizard® den Bus und liest die Parameter aller angeschlossenen Geräte aus. Hat man die entsprechende Berechtigung, kann man die Parameter ändern und in das Gerät zurückschreiben.
Weiterhin kann das gesamte Abbild des Aufzugs mit allen Parameter archiviert werden. Die gespeicherten Parametersätze können für die Konfiguration ähnlich aufgebauter Anlagen verwendet werden, oder für die einfache Konfiguration eines Austauschteils. Weiterhin dienen die Parametersätze dem Betreiber einer Anlage oder der ZÜS zur Kontrolle der Manipulation von Parametern. Auf einfache Weise kann festgestellt werden, ob nach einer Abnahme relevante Parameter verändert worden sind.
Firmwareupdate
Software ist nie frei von Fehlern und die Funktionalität einer Baugruppe wird heute durch die interne Firmware bestimmt. Somit ergibt sich häufig die Notwendigkeit, in eine Baugruppe ein Softwareupdate einzuspielen.
Der CANwizard® ermöglicht es, über ein standardisiertes Verfahren bei einer oder mehreren Baugruppen herstellerunabhängig ein Softwareupdate durchzuführen. Dieses Verfahren kann beispielsweise eingesetzt werden, um mit wenigen Klicks die Darstellung auf modernen LCD-Anzeigen den aktuellen Bedürfnissen anzupassen, oder Sound-Dateien in Sprachansagemodulen zu aktualisieren.
Echtzeitmonitoring
Ein Hauptproblem technischer Anlagen, die über ein proprietäres Bussystem vernetzt sind, ist die Diagnosefähigkeit. Der Techniker vor Ort muss sich auf die Statusmeldungen einiger weniger Baugruppen verlassen.
Durch die Standardisierung der Prozess- und Fehlernachrichten auf dem Bus kann mit einem einzigen Tool die Diagnose aller Baugruppen und des gesamten Systems durchgeführt werden. Alle Prozessnachrichten, wie zum Beispiel 'niedrig priorisierter Außenruf in Etage 8 an der Tür A für Aufzug 1' oder 'Endschalter Tür A Aufzug 1 offen' oder 'Position 18,2356 m, Geschwindigkeit 0,832 m/s, Beschleunigung 0 m/s' können im Klartext in Echtzeit dargestellt und mit einem Zeitcode in einer Logdatei archiviert werden. Damit ist der Techniker von einem Ort aus über den Zustand aller Geräte und des gesamten Prozessabbildes informiert. Zeitlich aufeinander folgende Funktionen einer Anlage können im Klartext oder visuell nachvollzogen werden. Dies ist eine Möglichkeit, die ohne ein standardisiertes Verfahren nicht möglich wäre.
Verwaltungsfunktionen für EDS-Dateien
Zu jedem CANopen-Geräte gehört ein elektronisches Datenblatt (Electronic Datasheet), das in sogenannten EDS-Dateien beschrieben ist. Diese Dateien beschreiben in einem standardisierten Textformat sowohl die wichtigsten Parameter eines Gerätes als auch physikalische Parameter wie z. B. die unterstützten Baudraten. Konfigurationstools können EDS-Dateien einlesen und mit ihrer Hilfe auch mit zuvor unbekannten Geräten kommunizieren und es gegebenenfalls parametrieren.
Der CANwizard® beinhaltet eine EDS-Bibliothek mit den EDS-Dateien aller bekannten CANopen-Lift-Geräte. Über eine Importfunktion können weitere Geräte hinzugefügt werden.
'Erweiterbarkeit
Eine Software allein kann niemals alle denkbaren Funktionen enthalten und gerade bei einer herstellerübergreifenden Software ist es für manche Funktionen nicht gewünscht, dass Wettbewerber internes Know How bereitgestellt bekommen.
Daher ist es heute üblich, Programme mit Schnittstellen auszustatten, über die Erweiterungen (Add-ons) angebunden werden können, die die Funktionalität des Programms erweitern.
Der CANwizard® wurde mit einer solchen Schnittstelle ausgestattet und erlaubt es jedem Hersteller eigene Erweiterungen zu schreiben, um die eigenen Geräte zu Parametrieren.
Aktualität
Für ein Diagnosetool ist es sehr wichtig, dass sein Funktionsumfang ständig an aktuelle Normen und den Funktionsumfang der am Markt befindlichen Geräte angepasst wird. Um dies sicherzustellen unterliegt der CANwizard® einem kontinuierlichen Entwicklungsprozess. Über eine Onlineupdate-Funktion können die Anwender die Software setzt auf dem aktuellen Stand halten.
Zu jeder Veröffentlichung einer neuen Version der Norm erscheint auch ein Major-Release der Software, die den neuen Umfang der Norm abdeckt.
Offenheit
Zur Vertrauensbildung gehört, dass Entwickler von herstellerübergreifenden Tools offen mit ihren Anwendern kommunizieren. Dazu gehört eine stets aktuelle Historie der Software, die jedem Anwender zugänglich ist und über Funktionserweiterungen und Fehlerbehebungen informiert.
Herstellerübergreifend
Der CANwizard® steht jeden Techniker und Entwickler von CANopen-Geräten zur Verfügung und wird auch von Universitäten und Herstellern im Produktionsprozess eingesetzt.
Ferndiagnose
In Zeiten in denen das Internet omnipräsent ist, bietet es sich natürlich an, die Funktionalität nicht nur vor Ort an der Anlage anzubieten, sondern auch aus der Ferne.
Ist der Aufzug über ein Gateway mit dem Internet verbunden, können alle Funktionen nach der Überprüfung der Berechtigung auch aus der Ferne durchgeführt werden, sobald der PC mit dem Internet verbunden ist.
Normierung
Zu Beginn der Normierungsarbeiten waren einige organisatorische Fragen zu klären. Ziel war es, einen weltweit gültigen Standard zu definieren, der allen offen steht und durch keinen Hersteller bzw. Verband dominiert werden kann. Weiterhin sollte das Gremium sich durch einen aktive Normungsarbeit und Erfahrung auszeichnen und bei der Arbeit Unterstützung leisten können.
All diese Bedingungen wurden durch die Organisation CAN in Automation (CiA) erfüllt. Die herstellerunabhängige Non-Profit-Organisation hat in Nürnberg ihr Headoffice und weltweit auf den wichtigsten Märkten Niederlassungen.
Die CiA übernimmt die Normungsarbeit, organisiert Schulungen rund um das Thema CANopen, zertifiziert Geräte, Informiert auf Messen und vieles mehr.
Die Arbeit für Aufzüge findet bei der CiA in zwei Bereichen statt. Die 'Spezial Interest Group Lift' (SIG Lift) besteht aus Entwicklern, die neue Funktionen definieren, das Protokoll ausarbeiten und Geräte testen oder zertifizieren.
Die 'Marketing Group Lift' (SMG Lift) informiert über das Protokoll und die am Markt vorhandenen Geräte. Im Rahmen der SMG Lift wurde ein Demonstrator gebaut, der die Funktionalität des Profils und der Baugruppen zeigt. Weiterhin arbeitet die SMG Lift Informationsbroschüren und Flyer aus und organisiert Messeauftritte und Roadshows.
Um in der heutigen schnelllebigen Zeit ein herstellerunabhängiges Protokoll zu normieren, dass stets auf dem aktuellen Stand gehalten wird, müssen für die Normierungsarbeit die folgenden Bedingungen erfüllt werden.
- Geschwindigkeit
- Nachvollziehbarkeit
- Offenheit
Um dies zu erreichen, stehen verschiedene Plattformen im Internet zur Verfügung. Zum einen stellt die CiA ein Content Management System auf ihrer Webseite zur Verfügung, auf dem die Mitglieder intern und extern Informationen austauschen können. Zum anderen steht auf der Webseite www.CANopen-Lift.org ein offenes Wiki zur Verfügung, auf dem Empfehlungen für neue Produkte, Application Notes und neue Funktionen diskutiert werden.
Zwei mal jährlich treffen sich die Mitglieder der SIG Lift zur Erweiterung der Spezifikation und besprechen in einem meist regem Informationsaustausch neue Funktionen, die zukünftig in diese einfließen sollen.
PlugFeste
Soviel zur Theorie bei der Erstellung einer Norm, doch irgendwann müssen auch die entsprechenden Geräte entwickelt werden und die Interoperabilität überprüft werden.
Zur Überprüfung der Interoperabilität der Geräte finden im Rahmen der SIG Lift regelmäßige Treffen (PlugFeste) statt, bei denen an Hand von Checklisten die Kompatibilität der Geräte gegenüber der Norm und die Funktionalität untereinander überprüft werden. Wurden durch ein Gerät alle Punkte einer Checkliste erfolgreich erfüllt, so gilt dies gewissermaßen als Zertifikat für den zu diesem Zeitpunkt geltenden Stand der Norm.
Weiterhin werden bei den PlugFesten auch Stresstests durchgeführt, zum Beispiel das Verhalten der Geräte bei maximal zulässigen Buslängen oder bei maximaler Buslast. Diese Test sind sehr aufwendig und könnte von einem einzelnen Hersteller nur sehr schwer durchgeführt werden.
Die PlugFests finden zwar mehrmals im Jahr statt, aber um eine neue Softwareversion mit einer geringfügigen Änderung auf den Markt zu bringen, will man nicht bis zum nächsten FlugFest warten.
Daher wurden von Böhnke + Partner mehrere Steuerungssysteme über ein Gateway mit dem Internet verbunden. Nach der Installation eines Treibers kann jeder Hersteller sein CANopen-Lift-Gerät über das Internet mit diesen Steuerungen verbinden und die Funktionalität seiner Baugruppen überprüfen.
Aussichten
Wohin wird uns diese standardisierte Spezifikation für die Kommunikation der Komponenten eines Aufzugs führen? Wir denken, dass zukünftig alle Geräte über standardisierte Busanschlüsse verfügen werden. Diese Geräte können mit universellen Diagnosetools analysiert und parametriert werden.
Durch die standardisierte Vernetzung des Aufzugs ist auch eine einfache Anbindung an die Gebäudeleitebene und Ferndiagnose über das Internet möglich.
Durch die Möglichkeit auf viele interne Parameter der einzelnen Geräte zugreifen zu können, ergeben sich viele neue Funktionen, die ohne diesen Standard nur sehr aufwändig oder gar nicht realisierbar wären.
Weiterhin erhöht sich die Sicherheit der Aufzüge, da Redundanzen entstehen und Geräte sich gegenseitig überwachen können. Seit 2005 ist PESSRAL Anhang der EN81 1 / 2. Bei PESSRAL werden die sicherheitsrelevanten Sensoren und Endschalter durch elektronische Baugruppen ersetzt, die eine wesentlich höhere Funktionalität bieten und den Aufzug somit sicher machen. Sollen diese Systeme untereinander Informationen austauschen müssen sie über einen herstellerunabhängigen sicheren Bus miteinander vernetzt werden. Dafür steht mit 'CANopen Safety' ein weltweit verbreiteter Standard zur Verfügung.
Immer wieder einmal erscheinen neue Feldbussystem auf dem Markt und andere verschwinden wieder. Zukünftig werden vielleicht Glasfaser oder auf Funktechnologien basierende Systeme auf den Markt kommen. Zurzeit gibt es von einigen großen Herstellern Bemühungen, auf Ethernet-basierende Systeme echtzeitfähig zu machen und als Feldbussystem zu etablieren. Diese Systeme sind untereinander nicht kompatibel und werden meist jeweils nur durch einen starken Hersteller in den Markt gedrückt. Das offenste System ist Powerlink, dass unter anderem mit Standard-Ethernet-Hardware arbeitet, aber auch hier sind viele Probleme noch nicht gelöst. Sind bei den Ethernet-basierenden Systemen die Hardware und die Transportschichten für Nachrichten geklärt, müssen immer noch die Parametersätze für Geräte bzw. Anwendungen definiert werden. Hier besteht zwischen Powerlink und der 'CAN in Automation' eine Vereinbarung, dass die in CANopen definierten Objektverzeichnisse für Geräte und Applikationen auch für Powerlink verwendet werden dürfen. Wer also heute bereits CANopen-Lift einsetzt, ist für die Zukunft bestens gerüstet.
Eine weitere Vereinfachung entsteht durch die Standardisierung praktisch nebenher. Viele Hersteller von Aufzügen und Komponenten verwenden für die gleichen Dinge unterschiedliche Bezeichnungen. Durch die Festlegung der Nachrichten und Parametersätze verbreiten sich auch einheitlichere Begriffe. Bedienebenen und Menüführungen von Geräten unterschiedlicher Hersteller passen sich einander an. Der Servicetechniker vor Ort und auch die Mitarbeiter der ZÜS können somit einfacher unterschiedliche Systeme handhaben.
Quellen
Hier finden Sie eine kleine Auflistung von Quellen, die es Ihnen ermöglichen, tiefer in das Thema einzusteigen.
| BÖHNKE + PARTNER GmbH | http://www.boehnkepartner.de |
| Organisation CAN in Automation | http://www.can-cia.org |
| CANopen-Lift-Wiki | http://www.CANopen-Lift.org |
| Konfigurationssoftware | http://www.CANwizard.de |
| Informationen zu Powerlink | http://de.wikipedia.org/wiki/Ethernet_Powerlink |