Steuerungstechnik in vernetzten Umgebungen

Der Begriff Steuerungstechnik steht schon lange nicht mehr nur für lokale technische Systeme, die sich autonom oder teilautonom verhalten und aus einer Kombination von Regelkreisen und Ablaufketten bestehen. Neben der Eingabe von Informationen und Befehlen durch den Menschen, im einfachsten Fall zum Beispiel ein Innenruf, nimmt die Kommunikation von Maschine zu Maschine mehr und mehr Raum ein. Am Beispiel einer, unter Verwendung modernster Automatisierungskomponenten neu erstellten, Krankenhauslösung, soll dieser Artikel beispielhaft erläutern, wie das System „Aufzug“, in ein übergeordnetes System „Krankenhaus“ mit seinen, an den Zweck des Gebäude, gebundenen Regeln, integriert wurde. Die Aufgabenstellung für das Amsterdam Medical Center, kurz AMC, umfasste dabei die Integration eines Zugangssystems mit Transponderkarten für das Reanimationsteam, das Pflegepersonal, den Wachdienst und die Kollegen der Technik, die sich alle die Ressource Aufzug im Gebäude teilen müssen. Dazu mussten Steuerungsaufgaben bewältigt werden, die über die Funktion eines Aufzuges im klassischen Sinn hinausgingen und eine gebäudeübergreifende Vernetzung erforderten.

Betrachtet man den Informationsfluss innerhalb einer Aufzuganlage, so werden neben dem klassischen Schaltsignal, Bussysteme eingesetzt, die durch vorhersagbares Zeitverhalten und klare Zugriffsregeln, gekennzeichnet sind. Darauf aufbauend werden dann die höheren Protokollschichten realisiert, die zweckgebunden unterschiedliche Kommunikationsmodelle, wie das in Abbildung 1 schematisierte Producer-Consumer-Modell oder das in Abbildung 2 vereinfachte Server-Client-Modell realisieren und dabei zweckbestimmt priorisiert werden. Ein typisches Beispiel ist die Kombination des CAN-Busses mit CANopen als genormte höhere Protokollimplementierung, mit der dann Prozessdatenobjekte (PDO), Servicedatenobjekte (SDO) und Funktionen des Netzwerkmanagment (NMT) realisiert werden.

Um nun die Interaktion von Komponenten verschiedener Hersteller zu gewährleisten, wurde darauf aufbauend ein Anwendungsprofil (CiA 417) gesetzt. Dieses bestimmt vereinfacht ausgedrückt, in welchen Datenobjekten, sich welche Information in welcher physikalischen Einheit befindet. Da solche Bussysteme, die „nah“ an den Steuerungskomponenten agieren, wegen ihrem Zeitverhalten und dem unbedingten Determinismus, wenig geeignet sind, um zu großen gebäudeumspannenden Netzwerken zusammengeschlossen zu werden, bietet sich ein anderes Modell an, das in mehrere Ebenen zerlegt werden kann. Dazu wird zunächst ein umfassendes Prozessabbild vereinbart, welches in Variablenform alle relevanten Daten, wie Position, Betriebszustand, Türsignale und Schachtsignale beinhaltet. Dieses wird von der Steuerung selber, mit festem Zeitintervall oder wie in diesem Beispiel, ereignisorientiert aktualisiert. Zusammen mit einem Satz an Zugriffsmethoden zum Lesen der Variablen und der Übertragung von Kommandos, wie "Lösche Innenrufe" oder "Setze Prioritätsruf", wird so eine Schnittstelle geschaffen, auf die ein System auf einer höheren Ebene zugreifen kann. Im Beispiel der Krankenhauslösung für AMC, übernimmt ein Embedded-Device-Server (EPC), diese Aufgabe. Dieser wurde in einem Gehäuse für Hutschienenmontage untergebracht und konnte so, bequem in den Steuerschrank eines Gruppenaufzuges integriert werden. Die Prozessabbilder der einzelnen Gruppenteilnehmer werden, über den gemeinsamen CAN-Bus, unter Verwendung von CANopen und dem Anwendungsprofil 417, vom EPC zentral erfasst. Diese Baugruppe, ausgestattet mit CAN- und Ethernetanschluss, bildet nun die Schnittstelle zum Gebäudenetzwerk, unter vorrangiger Verwendung von TCP/IP. Im vorgestellten Anwendungsfall wird µCLinux als Betriebssystem im EPC eingesetzt und damit neben einem bewährten TCP/IP-Stack auch andere Unix-typische Fähigkeiten, wie Multitasking und die Unterstützung gängiger Dateisysteme genutzt. Da es sich um eine industriegerechte Lösung handelt, die über Jahre sicher und störungsarm arbeiten soll, wurden keine Festplatte und keine aktive Kühlung eingesetzt. Stattdessen wurde durch konsequente Verwendung von echten „embedded” Komponenten - Flash-Speicher und leistungsfähige Mikrocontrollern - ein Maximum an Dauerlebigkeit erreicht. Der EPC bewältigt nun folgende Aufgaben, von denen er einige als Dienst der Außenwelt per TCP/IP im Netzwerk bereitstellt.

• Implementierung und Anwendung der krankenhausspezifischen Kartenregeln für das Reanimationsteam, den Wachdienst, das Pflegepersonal und die Kollegen der Technik.
• Zugriff auf das Prozessabbild per DFÜ300-Stack, um WinMOS^®300 Monitoring auf der übergeordneten Serverebene netzwerkbasierend einsetzen zu können.
• Lokale Kopie der Kartendatenbank (ausgeteilte Karten), um auch bei Ausfall des Netzwerkes weiter betriebsfähig bleiben zu können.
• Aktualisierung der lokalen Kartendatenbank im laufenden Betrieb von der übergeordneten Serverebene aus, ohne dabei den Betrieb zu unterbrechen.
• Aufzeichnung von Laufzeitinformation, wie z. B. der über den Tag verwendeten Karten.

Auf diese Weise kann jede Aufzugsgruppe autark für sich arbeiten und bleibt auch bei Ausfall des gebäudeübergreifenden Netzwerkes weiter betriebsfähig. Im folgenden Schritt wurde nun die nächste höhere Server-Ebene geschaffen, die die Prozessabbilder, welche an dieser Stelle bereits um die kundenspezifischen Kartendaten erweitert wurden, zusammenfasst. Bei diesem Vorgang, werden diese Daten auch gleich statistisch ausgewertet. Da als Übertragungsmedium Ethernet zum Einsatz kommt und dieses, unter Verwendung von IP als Netzwerkschicht und TCP als Transportschicht, kein vorhersagbares Zeitverhalten aufweist, werden hier nun keine direkten Steuerungsaufgaben realisiert. Der angebundene WinMOS^®300 Server hat vielmehr die Aufgabe, Störungs- und Wartungsinformation zu sammeln, die aktuellen Prozessabbilder zwischenzuspeichern und die Daten zur Visualisierung den Arbeitsplatzrechnern (Clients) zur Verfügung zu stellen. Außerdem nimmt er deren Kommandos entgegen und leitet sie an die darunter liegende Ebene weiter. Die folgende Abbildung soll dies verdeutlichen:

Die Arbeitsplatz-PCs (Clients) stellen folgende Funktionen dem Anwender bereit:

• Etagen sperren, Rufe geben, Fern ein/aus
• Aktivierung der Sonderpriorität Hubschrauber, die nur über vereinbarte Karten oder nach Ablauf einer einstellbaren Bereitstellzeit, zurückgesetzt werden kann.
• Änderung von Sonderhaltestellen (Brandfall, Feuerwehr, Notstrom)
• Zugriff auf das Servicemenü jeder Steuerung.
• Visualisierung von Kabinenposition, Geschwindigkeit, Bündigkeit und aller relevanten Signale einschließlich des Sicherheitskreises.
• Darstellung der verwendeten Transponderkarten sowie weitere Betriebsdaten.

Die ausgegebenen Transponderkarten werden in einer MySQL-Datenbank auf der Server-Ebene 2 verwaltet, und in Dateiform auf die Ebene 1 (EPC im Maschinenraum) der Aufzugsgruppen übertragen. Dies geschieht entweder auf Befehl des Anwenders am Arbeitsplatz-PC (Client) oder automatisch beim Neustart eines EPC. Dadurch ist gewährleistet, dass alle Änderungen (z. B. Kartentypen, Benutzername/Personalnummer und die Maske zugewiesener Aufzüge) in einem Vorgang übertragen werden und alle EPCs damit auf dem gleichen aktuellen Stand bleiben. Neben der bereits angesprochenen MySQL-Datenbank läuft auf der Server-Ebene 2 auch der WinMOS^®300 Monitoring-Server als NT-Dienst und ein Apache-Webserver, der ausgewählten Clients ein erweitertes Web-Front-End zur Datenbankwartung bereitstellt. Ansonsten erfolgt der Zugriff auf die Kartendaten durch eine Java-Server-Anwendung auf der Server-Ebene 2, die wiederum ihre Befehle von den Client-Anwendungen auf den Arbeitsplatz-PCs erhält. Die Client-Anwendung bietet Dialoge zum Bearbeiten von angelegten Karten, Kartentypen und zugewiesene Aufzügen. Die folgende Abbildung zeigt die Oberfläche, die dem Anwender zum Bearbeiten von Kartendaten bereitgestellt wird.

Um neue Karten anzulegen oder aufgefundene Karten zuzuordnen, sind die Arbeitsplätze (Clients) außerdem mit einem Tischlesegerät ausgestattet. Auf den Arbeitsplatzrechnern läuft ebenfalls WinMOS®300 Monitoring, das alle Daten von der Server-Ebene 2 erhält und für die Visualisierung der laufenden Anlagen verantwortlich ist. Unterstützt wird es dabei vom Statistikmodul zur Darstellung von Rufwartezeit, Haltverzugszeit und Türbewegungen sowie dem Übersichtsmodul zur lagerichtigen Darstellung der Anlagen und ihrer Betriebszustände. Dazu gehört unter anderem der Brandfall-, Notstrom- und Feuerwehrbetrieb. Der Zugriffsschutz auf das System erfolgt durch Benutzername/Passwort-Authentifizierung und IP-Adressen-Liste. Innerhalb der WinMOS^®300-Anwendung können Datenbankbenutzer und Monitoring Benutzer eingerichtet werden, um diesen unterschiedliche Benutzerrechte zuweisen zu können.

In der praktischen Umsetzung sind natürlich auch Änderungen an dem eigentlichen Steuerungsprogramm der Aufzuganlagen erforderlich. Dazu gehört die Implementierung von Sonderprioritäten, Bereitstellzeiten und Parametern. Damit können verbundene Eigenschaften im realen Betrieb angepasst werden - in diesem konkreten Beispiel unter anderem die Bereitstellzeit des Hubschrauberrufes.

Die Unterteilung der Aufgaben auf mehrere Ebenen, macht den Einsatz von angepassten Bussystemen und Komponenten möglich und erleichtert auch die Verteilung der Aufgaben innerhalb des Entwicklerteams. Unbedingt erforderlich sind dazu die genaue Schnittstellenvereinbarung und die Verwendung von genormten und bereits existierenden Protokollen, deren Entwicklungsaufwand, wie bei CANopen CiA 417, von einer Interessengemeinschaft getragen wird. Auch die Benennung und Einbeziehung von verantwortlichen Personen beim Endkunden ist von enormer Bedeutung, denn spätestens die Server-Ebene 2 wird nicht mehr vom Wartungsunternehmen der Aufzuganlagen, sondern von der IT-Abteilung des Endkunden unterhalten. Vorherige Absprachen und Vereinbarungen über administrative Rechte, Eigenschaften der zu entwickelnden Software und Bereitstellung von Netzwerkzugängen, sind so früh wie möglich zu beginnen. Um dem Kunden die Möglichkeit zu geben, die von ihm definierten Karten- und Sonderregeln zu prüfen, wurde im konkreten Projekt noch einen Schritt weiter gegangen. Am Modell einer 4-er Gruppe und einem lokalen Netzwerk mit vereinfachter Server-Ebene 1 und 2 sowie zwei Arbeitsplatz-PCs (Clients), wurden Szenarien mit dem Kunden zusammen „durchgespielt“ und dabei auftretende Konflikte von Ereignissen des realen Betriebes, besprochen und Änderungen der Dokumentation und Implementierung durchgeführt. Dies alles bevor die Umsetzung in die Praxis erfolgte, die wie jeder weiß, immer genug Unwägbarkeiten bereithält.