CANopen-Lift in der Praxis - Referenzaufzug an der Hochschule Heilbronn

Quelle: Prof. Dr.-Ing. Ansgar Meroth, Hochschule Heilbronn

Dieser Artikel wurde in Originalfassung bei den "Heilbronner Aufzugstagen 2013" veröffentlicht und vorgestellt.

Kurzfassung

Die Vernetzung von realen Aufzugskomponenten mit CANopen eröffnet neue Möglichkeiten bei der Systemintegration und der Kommunikation mit Drittkomponenten. Bei der Systemintegration und der Entwicklung neuer Komponenten ist ein Referenzmodell hilfreich, gegen das die Komponenten getestet werden. Dieses kann durch Restbussimulation und durch eine reale Anlage umgesetzt werden. In diesem Aufsatz werden beide Möglichkeiten vorgestellt und neue Wege der Systemintegration diskutiert.

Entwicklungsprozesse

Aufzüge sind komplexe Systeme, deren Funktion jederzeit sicher und beherrschbar dargestellt werden muss, sie unterliegen deshalb den Forderungen der Normenfamilie um IEC/EN 61508 [1]. Diese Forderungen betreffen auch den Entwicklungsprozess, der sich in diesem Umfeld bevorzugt an das bekannte V-Modell anlehnt.

Bild 1 zeigt einzelne Stationen aus dem V-Modell (s. z.B. [2]). Eine wichtige Eigenschaft des Prozesses ist, dass das Systemkonzept und die Sicherheitsbewertung weitgehend abgeschlossen werden müssen bevor die Systemspezifikation, also die Sammlung aller Anforderungen festgelegt werden kann, die zur Spezifikation der Teilsysteme und letztlich der Komponenten führt. Auf dem umgekehrten Weg werden die Komponenten einzeln getestet, zum Subsystem integriert und diese nach den bestandenen Tests zum Gesamtsystem integriert und in Betrieb genommen. Nachträgliche Änderungen führen dazu, dass der Ablauf in Teilen nochmals durchlaufen werden muss, insbesondere, wenn sicherheitskritische Funktionen betroffen sind. An den Schnittstellen der Geräte erfolgt die Trennung zwischen der funktionalen Spezifikation, die die Funktionsgruppen und ihre Interaktion beschreibt, und der technischen Spezifikation, die die realen Subsysteme und Komponenten mit ihren Schnittstellen beschreibt. Häufig werden dabei Funktionen auf einer Komponente zusammengefasst oder über mehrere Komponenten verteilt, so dass zusätzliche Schnittstellen entstehen. Darüber hinaus erfordert die Realisierung einer physischen Komponente („Gerät“) zusätzliche Schnittstellen, die nicht die Systemfunktionalität, sondern den Zugriff auf das Gerät selbst betreffen, z.B. Parametrierungs-, Diagnose- und Energiemanagementfunktionen.

Mit der Entscheidung für einen Standard, den z.B. CANOpen mit sich bringt, werden Teile des beschriebenen Prozesses ausgelagert bzw. parallelisiert, da bereits eine generische Schnittstellenstruktur vorgegeben ist, hier z.B. durch die CiA 417. Damit ist es möglich, einzelne Komponenten bereits vor der Gesamtsystemplanung zu beschreiben und zu realisieren. Bekanntermaßen müssen in diesem Fall die technischen Schnittstellen und das Verhalten an den Schnittstellen sehr sorgfältig geplant und gegen den Standard getestet werden. Da dies beim Lieferanten oder einer neutralen Zertifizierungsstelle erfolgen kann, bleiben dem Systemhersteller im Entwicklungsprozess „nur“ der Integrationstest und die Inbetriebnahme.

Vor diesem Hintergrund erscheint es sinnvoll, dem Hersteller von Komponenten eine Umgebung zum Systemtest anzubieten und gleichzeitig eine Plattform für die Erprobung neuer, innovativer Konzepte zu schaffen.

Referenzmodell

Allgemeines

Das an der Hochschule Heilbronn entstehende Referenzmodell wurde von Jörg Hellmich, damals bei Böhnke + Partner GmbH Steuerungssysteme, heute Geschäftsführer der ELFIN GmbH, angeregt [3]. Es besteht aus einer funktionsfähigen Aufzugsanlage, die aus Gründen der Handhabbarkeit auf den Maßstab 1:10 skaliert wurde. Bis auf die Antriebe und den mechanischen Aufbau wurden ausschließlich Originalkomponenten verwendet, die dank der großzügigen Unterstützung von verschiedenen Firmen, insbesondere Böhnke + Partner, der SCHAEFER GmbH integriert werden konnten. Eine Beschreibung zum aktuellen Zustand des Modells und einer Liste der beitragenden Firmen ist auf der Webseite der CANOpenLift Community zu finden [4].

Neben der Aufzugsanlage wurde mit dem Aufbau einer Restbussimulation begonnen, die es langfristig ermöglichen soll, Komponenten gegen eine statische und eine dynamische Spezifikation im Labor testen zu können, bevor diese in ein Referenzsystem eingebunden werden.

Elektromechanischer Aufbau

Das Modell ist in einen Rahmen aus Aluminium Strangpressprofilen aufgebaut. Darin sind zwei Schächte mit je vier Stockwerken und einem Fahrkorb mit Gegengewicht pro Schacht realisiert. Der nachzubildende Funktionsumfang soll in der letzten Ausbaustufe, soweit möglich, dem tatsächlichen Funktionsumfang realer Aufzüge entsprechen. Allerdings sind auf Grund der Miniaturisierung und der besseren Bedienbarkeit sämtliche Original Ruf- und Stockwerkwahlpanels nicht direkt am Modell angebracht, sondern getrennt auf separaten Schalttafeln. Da ein Einsatz dieses Modells auf Messen erwünscht ist, wurden möglichst viele Bauteile transparent oder mit Fenstern versehen, um einen besseren Einblick zu ermöglichen. Das Modell kann mit einem PKW transportiert werden.

Die Kabinen besitzen angetriebene Türen, die über Mitnehmer die Schachttüren mitöffnen. Sie sind mit SICK Lichtvorhängen abgesichert. Die Türantriebe werden durch Kleinmotoren der Firma ebm papst angetrieben, die Liftantriebe sind 24V-Motoren aus der Nutzfahrzeugtechnik. Als Sicherheitsfeatures wurden redundante Seile, Schürzen, Puffer und Türverriegelungen mit entsprechender Sensorik eingebaut, im Aufbau befindet sich eine Gewichtsüberwachung an der Seilaufhängung. In den durch realitätsnahe, einstellbare Rollenlager geführten Kabinen (siehe Bild 5) befinden sich schaltbare Lüfter (ebm papst Kleinlüfter) und Lampen aus der Aufzugstechnik (Henning). Die Hardware für eine Kabinenelektronik wurde in der Hochschule ebenfalls als Prototyp realisiert, diese besitzt eine CAN-Schnittstelle, eine H-Brücke für die Ansteuerung der Türantriebe sowie weitere Leistungstreiber für die Beleuchtung und Lüftung. Zudem soll sie die Sicherheitskreislogik aufnehmen. Über eine Schleppkette werden die notwendigen Signal- und Versorgungskabel aus der Kabine an die Steuerung geführt. Zur Positionsbestimmung der Kabine sind zwei Absolutwertgeber (AWG) von Böhnke + Partner im Modell integriert.

Vernetzung

Die Anlage wird von zwei Steuerungen vom Typ bp 308 von Böhnke + Partner betrieben. Neben den Stockwerks- und Kabinentableaus von Schaefer sind auch zwei Notrufpanels der Firma Safeline sowie Absolutwertgeber, Rückholsteuerung und Relaisplatinen von Böhnke + Partner integriert. Normgemäß sind die Sicherheitskreise unabhängig vom Bussystem aufgebaut und so ausgelegt, dass der Wegfall einer Überwachungseinrichtung die Anlage stillsetzt.

Restbussimulation

Die Restbussimulation dient dazu, Komponenten einer Anlage, die physisch nicht vorhanden sind, durch virtuelle Komponenten auf dem Rechner zu ersetzen. Für die Restbussimulation wurden zwei Ansätze gewählt. Zum einen wird das statische Verhalten an der Schnittstelle durch die im Automobilbereich weit verbreitete Software CANOe der Firma Vector Informatik GmbH in der Ausbaustufe CANOpen. Das Applikationsprofil CiA 417 wurde soweit in dieser Ausbaustufe notwendig in die Datenbank des Werkzeugs eingegeben. Jedes Signal des Applikationsprofils steht dann zur weiteren Verwendung zur Verfügung. Der Anwender kann nun entscheiden, ob das Signal über den realen Bus und die Schnittstelle CANCaseXL von einer physisch vorhandenen Komponente gesendet wird oder simuliert werden soll. Für eine quasidynamische Simulation, d.h. den zeitlichen Abläufen sind keine oder nur schwache physikalische Modelle hinterlegt kann die C-ähnliche Programmiersprache CAPL benutzt werden, die die Software zur Verfügung stellt. Hiermit sind vielfältige Integrationsversuche möglich.

Soll dynamisches Verhalten realer mechatronischer Komponenten genau nachgebildet werden, z.B. die Ausgabe einer Positionssensorik unter Berücksichtigung der Fahrkorbdynamik, die sich aus den Antriebskräften, der Seilelastizität und den Trägheitsmomenten der bewegten Teile ergibt, genügt diese Methode nicht mehr. Hier bietet sich das in der Simulationstechnik weithin verwendete Matlab/Simulink von mathworks an. Matlab/Simulink bietet eine CAN-Schnittstelle an, die in nahezu Echtzeit betrieben werden kann. Bildet man die CANOpen Botschaften direkt auf CAN-Botschaften ab, können so genaue dynamische Untersuchungen an der simulierten Anlage erfolgen. Erste Tests der Integration dieser Umgebung verliefen erfolgreich, hierbei wurden Kabinenrufe aus Matlab/Simulink nachgebildet.

Neue Konzepte

Mit den vorgestellten Werkzeugen und Methoden lassen sich neben der Möglichkeit des Integrationstests noch weitere interessante Anwendungen realisieren und an der Anlage testen. Diese Konzepte betreffen vor allem die Diagnose- und die Bedientechnik. Hierbei macht man sich zunutze, dass das CANOpen Protokoll auf der OSI-Sicherungsschicht dem CAN Protokoll nach ISO 11898 entspricht. Jede Botschaft auf dieser Ebene besteht aus bis zu acht Datenbytes. Es existieren zahlreiche Lösungen, davon auch eine vom Autor entwickelte, die diese Botschaften in UDP-Pakete des TCP/IP Protokolls übersetzen. Damit hat man die Möglichkeit, über Netze hinweg (im Internet) mit der Anlage zu kommunizieren. Ein Echtzeitbetrieb mit hohen Anforderungen an die Latenzzeiten ist damit zwar nicht möglich, da die Datenpakete im Internet nicht mit garantierten Latenzzeiten ausgeliefert werden können, jedoch eignet sich dieses Vorgehen z.B. für die Komponentenfernüberwachung oder eine Kopplung mit einer Bluetooth®-Schnittstelle für die Bedienung über ein Smartphone. Auch hierzu wurden aus dem Automobilumfeld bereits Musterimplementierungen in der Arbeitsgruppe des Autors erarbeitet. Für Anwendungen in der Aufzugstechnik sei auf den Beitrag von J. Hellmich auf dieser Konferenz verwiesen.

Zusammenfassung

Mit der Inbetriebnahme der Anlage konnte gezeigt werden, dass auch im Modellmaßstab eine realistische Nachbildung der Anforderungen eines Aufzugs mit hohem Detaillierungsgrad möglich ist. Die Anlage steht künftig für gemeinsame Forschungs- und Entwicklungsprojekte und im Rahmen der Transportmöglichkeiten auch für Demonstrationszwecke zur Verfügung. Mit der Restbussimulation lassen sich im Vorfeld der Integration bereits wesentliche Fragestellungen des Schnittstellenverhaltens klären. Diese muss nun im Rahmen eines Forschungsprojektes vollständig ausgebaut werden. Literatur

[1] K. H. Gutmann, Funktionale Sicherheit (SIL) in der Anlagensicherung, 2010.

[2] J. Schäuffele und T. Zurawka, Automotive Software Engineering, 4. Auflage Hrsg., Wiesbaden: Vieweg und Teubner, 2010.

[3] A. Meroth und andere, „Komponentenintegration im Modellmaßstab,“ Lift Journal, 3 2012.

[4] J. Hellmich und andere, „Referenzaufzug für CANOpen Lift,“ [Online]. Available: http://www.canopen-lift.org/wiki/Referenzaufzug. [Zugriff am 31 Jan. 2013].

[5] N. Englisch, D. Iwertowski, M. Traub und M. Etüs, „Konstruktion und Aufbau einer Modellaufzugsanlage für die Demonstration offener Automatisierungsschnittstellen,“ Hochschule Heilbronn - Masterprojekt, Heilbronn, 2012.

[6] S. Lang, M. Melzer und R. Brandner, „Inbetriebnahme und Optimierung einer Modellaufzugsanlage mit offenen Schnittstellen,“ Hochschule Heilbronn - Masterprojekt, Heilbronn, 2013.

Der Autor

Prof. Dr.-Ing. Ansgar Meroth lehrt im Studiengang Automotive Systems Engineering an der Hochschule Heilbronn schwerpunktmäßig Grundlagen der Informatik, Entwicklungsprozesse, Netzwerke und Mensch-Maschine Schnittstellen. Nach dem Studium der Elektrotechnik an der Universität Karlsruhe (Heute KIT) promovierte er dort und begann 1997 als Trainee für Forschung und Vorausentwicklung bei der Robert Bosch GmbH. Weitere Stationen führten ihn in die Produktentwicklung im Bereich Car Multimedia und Anzeigesysteme, wo er an der Entwicklung vernetzter Multimediasysteme und von graphischen Anzeigesystemen beteiligt war, und in die Zentralstelle Human Ressouces Development, wo er sich mit Entwicklungsprozessen befasste. Seit 2003 ist er an der Hochschule Heilbronn und war dort u.a. Prodekan der Fakultät Mechanik und Elektronik, sowie Prorektor für Forschung und Vernetzung.