Liftsteuerungen Schindler
Aufzugsbereich
Bussysteme in der Aufzugstechnik sind nichts Neues – bisher waren Komponenten aber an herstellerspezifische Protokolle gebunden und liessen sich nicht frei zu einem Gesamtsystem kombinieren. CANopen Lift (CiA 417) vereinheitlicht diese Kommunikation auf Basis von CANopen. Für Janzhoff Aufzüge entwickelte ich die komplette Gerätesoftware eines Steuergeräts an diesem Bus – von der Bootware über die Firmware bis zur Gerätebeschreibung.
Das Gerät musste sich als CiA-417-Gerät in eine Liftsteuerung einfügen, die von einem anderen Hersteller stammt – Interoperabilität war keine Zugabe, sondern die Grundbedingung. Dazu kamen die Randbedingungen eines eingebetteten Systems: ein 16-Bit-Mikrocontroller ohne Betriebssystem, knapper Arbeitsspeicher und feste Zeitvorgaben in der Hauptschleife.
Zwei Anforderungen prägten die Architektur besonders. Erstens musste die Software im Feld aktualisierbar sein, ohne dass ein Servicetechniker ein Programmiergerät an das Gerät anschliesst. Zweitens musste im Servicefall nachvollziehbar sein, was auf dem Bus und im Gerät passiert ist – über Wochen hinweg und über Gerätegrenzen hinaus.
Zweistufige Softwarearchitektur. Bootware und Firmware sind getrennte Programme mit eigenen Versionskennungen in getrennten Flash-Bereichen. Die Bootware bringt einen selbst geschriebenen, minimalen CANopen-Slave mit – nur so viel, wie für die Netzwerkverwaltung und den SDO-Transfer nötig ist. Sie empfängt die neue Firmware im segmentierten SDO-Transfer über den CAN-Bus, prüft sie auf Gültigkeit und springt erst dann hinein. Ein Update braucht damit weder Programmiergerät noch Gehäuseöffnung.
CANopen Lift in der Firmware. Die Applikation meldet sich über Objekt 1000h als Gerät des Lift-Profils CiA 417 an. Prozessdaten, Mapping und Gerätekennung sind in einer EDS-Datei nach CiA 306 beschrieben, die zugleich als Schnittstellendokument gegenüber dem Steuerungshersteller dient. Auf der Kommunikationsschicht kam ein kommerzieller CANopen-Slave-Stack zum Einsatz, ergänzt um Heartbeat-Überwachung in beide Richtungen.
Durchgängige Zeitbasis. Die Echtzeituhr des Geräts synchronisiert sich auf den Zeitstempel, den die Liftsteuerung auf den Bus legt. Damit sind Logeinträge verschiedener Geräte derselben Anlage vergleichbar – die Voraussetzung dafür, einen sporadischen Fehler überhaupt eingrenzen zu können.
Diagnose ab Werk. Ereignisse werden mit Zeitstempel auf eine SD-Karte im FAT-Dateisystem geschrieben und lassen sich am Schreibtisch auswerten. Über die serielle Schnittstelle steht zusätzlich ein Test- und Diagnosemenü zur Verfügung, das Zustände, Ein- und Ausgänge sowie die gemessene Zykluszeit der Hauptschleife live anzeigt.
Systematischer Entwurf. Das Verhalten der einzelnen Funktionsblöcke wurde vorab als Zustandsautomat modelliert und dokumentiert, bevor eine Zeile Code entstand. Die zustandsbehafteten Teile sind durch Unit-Tests abgedeckt.
Aufzugskomponenten verschiedener Hersteller lassen sich seither frei kombinieren, statt an einen proprietären Bus gebunden zu sein. Die Konfiguration liegt auf dem Modul, Jumper entfallen, und Software-Updates laufen über den CAN-Bus — das verkürzt Inbetriebnahme und Service spürbar.
Weil jedes Gerät seine Ereignisse zeitsynchron protokolliert, lassen sich Störungen im Nachhinein über die gesamte Anlage hinweg rekonstruieren, statt sie vor Ort reproduzieren zu müssen.
Die Erfahrung aus diesem Projekt ist in CANoopEn eingeflossen – unseren quelloffenen CANopen-Stack in modernem C++, der neben CiA 301 auch das Lift-Applikationsprofil CiA 417 unterstützt.
