OPC in der Gebäudeautomation

OPC in der Gebäudeautomation

Steigende Energiekosten und striktere Umweltauflagen rücken die Gebäudeautomation immer stärker in den Fokus von Bauplanern und Architekten. Doch für die Ingenieure und Facherrichter ist es eine Herausforderung, die Komponenten verschiedener Hersteller zu integrieren. Noch mehr Aufwand verursacht es, die Software für die Gebäudeautomation selbst anzupassen und Komponenten in Gebäudeverwaltungssysteme einzubinden. Dies sind zwei wichtige Gründe, warum der OPC-Standard auch in der Gebäudeautomation immer mehr Anhänger findet.
Der Markt für Gebäudeautomation wird von einigen Herstellern dominiert. In ihren Lösungen verwenden sie auch proprietäre Entwicklungen zur Gerätekommunikation. Dies kann zum Beispiel eine Software sein, um Geräte auszulesen oder Protokolle zur Verbindungherstellung. So gelingt es, die Anwender an ihr System zu binden. Wenn Änderungen nötig sind, kann es teuer werden. Den Ingenieuren und Facherrichtern bleibt ohne Einsatz von OPC nur der Weg zum Anbieter, der eventuell nicht einmal eine optimale Lösung für das Problem anbieten kann, oder die Eigenentwicklung von entsprechenden eigenen Kommunikationsschnittstellen. Das wird umso häufiger auftreten, je mehr Geräte miteinander verbunden, ausgelesen und gesteuert werden müssen. Genau das ist aber nötig, um Gebäudeleitsysteme auf Energieeffizienz zu trimmen. Um zu verstehen, warum der offene OPC-Standard auch die Gebäudeautomation effizienter gestalten kann und mehr Flexibilität verschafft, genügt ein Blick auf die Grundlagen des Konzepts: OPC ist ein Standard, um Daten zwischen Geräten, Controllern und Anwendungen auszutauschen, der auf dem Client-Server-Prinzip beruht. Das OPC-Konzept beseitigt Treiberprobleme, indem die OPC-Komponenten zwischen der Datenquelle und dem Datenempfänger angesiedelt werden. Die Kommunikation zwischen Geräten, Controllern und Anwendungen wird dadurch unabhängig von den Standards der verschiedenen Geräte-, Controller- und Softwareanbieter.

Schluss mit dem Turm zu Babel

Die OPC-Kommunikation stützt sich auf zwei Komponenten, die zwischen Datenquelle und Datenempfänger eingebaut werden: ein OPC-Client und ein OPC-Server. Der OPC-Server sitzt bei der Datenquelle und übersetzt die native Sprache des Geräts oder Controllers in die Sprache des OPC-Standards. Diese OPC-Server unterstützen die nativen Protokolle des Geräts, ohne Gerätetreiber des Anbieters dazwischen, die nur eine zusätzliche Fehlerquelle schaffen würden. Der OPC-Server liefert die vom OPC-Client angeforderten Daten. Dieser Client ist auf der Anwendungsseite angesiedelt. Er empfängt die Daten des Servers und reicht sie an die Anwendung weiter, für die der Client entwickelt worden ist. Die Kommunikation läuft in beide Richtungen. Die Anwendung liest die Daten vom Gerät und kann dieses ebenfalls steuern. Der Charme dieses Konzept liegt darin, dass nicht für jede neue Anwendung, die mit der vorhandenen Steuerung kommunizieren will, ein neuer individueller OPC-Server benötigt wird. Die Anwendung benötigt lediglich einen standardkonformen OPC-Client zur Kommunikation. Damit werden Treiberprobleme auf Geräteseite weitgehend eliminiert. Das funktioniert natürlich auch andersherum: Werden Geräte anderer Anbieter nachgerüstet, muss nur der dazu passende OPC-Server verwendet werden, um die Verbindung zur Anwendung herzustellen – ohne zusätzlichen Anpassungsaufwand.

Einfacher Planen – mehr Zukunftssicherheit

Es gibt für nahezu jedes gängige Gerät und jede gängige Anwendung in der Gebäudeautomation eine passende OPC-Komponente, die fertig zum Einsatz ist. So gibt es von MatrikonOPC z.B. seit Kurzem den Wonderware ArchestrA Universal Building Automation Server. Dieser Server ermöglicht die native Kommunikation von Wonderware-Anwendungen wie InTouch und InFusion mit den geläufigsten Gebäudeautomationsprotokollen. Mit InTouch lässt sich der Zustand eines Gesamtsystems oder einzelner Komponenten am Arbeitsplatz oder auf mobilen Endgeräten visualisieren. Dabei sind die Anwender wegen der OPC-Integration nicht auf anbieterabhängige Treiber angewiesen. Mit der Entwicklungsumgebung lassen sich auch komplexe Gebäudeautomationssysteme planen. Dadurch, dass eine OPC-Basis benutzt werden kann, können sich die Planer auf das System konzentrieren, ohne sich über anbieterspezifische Geräteeigenschaften Gedanken machen zu müssen. Warum dieser Weg auch zukunftssicherer ist, zeigt ein Blick auf die derzeitige Landschaft an Protokollen, die aus der Gebäudeautomationsindustrie kommen. Die Anbieter in der Gebäudeautomation haben Geräte und Protokolle mit dem Ziel entwickelt, die Konnektivität auf einer breiteren Basis zu ermöglichen. Einer der anbieterübergreifenden Standards ist zum Beispiel BACnet. Die Anwender können mit BACnet die Kommunikation mit einer großen Zahl von Geräten über ein allgemeines und gut definiertes Protokoll herstellen. Mit dem Erfolg von BACnet sind aber auch neue Protokolle aufgetaucht, die dem Vereinheitlichungsansatz zuwider laufen. Dazu zählt mitunter das von Anbieterseite entwickelte LonWorks, das nicht kompatibel mit BACnet ist. Solche Entwicklungen stellen die Anwender und Entwickler integrierter Lösungen vor ein Dilemma, denn sie müssen eine Plattformentscheidung treffen, die sie an bestimmte Anbieter bindet. Das ist das Gegenteil von Zukunftssicherheit.

Gebäudemanagement komplett

Mehr Flexibilität und Planungssicherheit erhalten Anwender mit dem OPC-Standard, der von einer unabhängigen Plattform entwickelt wird. So gibt es OPC-Server unter anderem für KNX, Modbus, BACnet, LonWorks und Johnson Controls. Auch anwendungsseitig ist die Auswahl groß – es gibt HMIs, Visualisierungs- und Reportinganwendungen mit passenden OPC-Clients. Hinzu kommen OPC-fähige Anwendungen, die bei der Einhaltung von Wartungszyklen unterstützen. Außerdem gibt es Anwendungen für die Heizung, Lüftung, Klimatechnik (HLK), die Beleuchtungssteuerung und Sicherheitstechnik. Diese Auswahl zeigt, dass der OPC-Standard sehr gut geeignet ist, verschiedene Systeme der Gebäudeautomation mit einem einheitlichen Konnektivitäts-Standard zu vernetzen. Alle Komponenten können mit einer einzigen HMI-Anwendung überwacht und gesteuert werden. Die möglichen Anwendungen sind vielfältig. Die Beleuchtung kann gebäudeweit oder auch über Liegenschaften hinweg energiesparend geregelt werden. Auch eine Überwachung der Abgaswerte der Heizung ist möglich oder die Zuschaltung von Notstromaggregaten im Bedarfsfall. Dank OPC ist dies alles über ein einheitliches Gebäudemanagementsystem möglich. Für Anwender ist es wichtig zu verstehen, was der OPC-Standard ist. Er ist kein weiterer Standard, der die Verbindung auf Geräteebene herstellt wie BACnet oder LonWorks. Es handelt sich vielmehr um eine zusätzliche Schicht, die darüber liegt. Diese Zwischenschicht dient als Vermittler, damit verschiedene Anwendungen Gerätedaten abrufen können, ohne auf den Anbieter der Geräte bzw. das verwendete Geräteprotokoll angewiesen zu sein. So spart OPC den Ingenieuren und Facherrichtern Zeit bei der Umsetzung der Kommunikation zwischen Geräten und Anwendungen. Sie können sich mehr auf ihre Kernkompetenz konzentrieren und für ihre Kunden energiesparende und umweltgerechte Gebäudeautomationssysteme entwickeln.

www.matrikonopc.de

Das könnte Sie auch Interessieren