Gebäudesystemtechnik
|
Hard- und Software
|
Elektrotechnik
BACnet und OPC - Widersacher oder Partner?
ep5/2003, 4 Seiten
1 Standards aus der Gebäude- und der industriellen Automation Der Nutzen von Kommunikationsstandards liegt auf der Hand: Können Systeme kombiniert werden, haben Bauherr und Betreiber den entscheidenden Vorteil, alle Subsysteme im Gebäude zusammenwirken zu lassen und mit einem einheitlichen „Look and Feel“ zu bedienen. 1995 wurde BACnet (Building Automation and Control Network) in den USA als ANSI-Norm aus der Taufe gehoben. Dieses Protokoll wurde auch Europäische Vornorm (EN V 1805-1) und ist als einziges Protokoll der Gebäudeautomation, unter Einbeziehung der EIB/KNX-Objekte, in die internationale Normung als ISO 16484-5 aufgenommen. Die Bedeutung dieser Norm wird zunehmen und es ist anzunehmen, dass auch kleinere Systeme und Geräte in Zukunft mit diesem Protokoll für die externe Kommunikation ausgerüstet sein werden. Auf der Seite der industriellen Prozessleitsysteme hat sich OPC - OLE (Object Linking and Embedding) for Process Control - zu einem Defacto-Standard für die Integration verschiedener Systeme in ein Managementsystem entwickelt. Auch in Gebäudeautomationssystemen wird OPC zunehmend für die Integration von Fremdsystemen verwendet. 2 Kommunikationsprotokoll BACnet BACnet ist ein Kommunikationsprotokoll und definiert, wie Systeme in der Gebäudeautomation miteinander Daten austauschen und Informationen verstehen können. Dazu braucht es Aussagen über die zu verwendenden Übertragungsmedien und Netze (Transportprotokolle) und eine Definition der Applikationsschicht mit Objekten und Diensten (Services). BACnet funktioniert nach dem Client-Server-Modell. Server sind Geräte oder Anwendungen, die Daten zur Verfügung stellen, Clients können diese Daten holen oder verändern. Ein Gerät kann auch beide Rollen einnehmen. Eine Managementstation ist zum Beispiel Client vieler Regler im Gebäude, kann aber auch als Server Daten zur Verfügung stellen. Übertragungsmedien. BACnet lässt heute die Verwendung von fünf Transportprotokollen zu: · Ethernet (direkt oder mit UDP/IP) · ARCNET · MS/TP (Master-Slave/Token-Passing) über RS485 · Lon Talk · PTP über RS232 (Punkt zu Punkt, für Modemverbindungen) Objekte. Bis heute sind 23 Standard-Objekte definiert. Es handelt sich dabei um eine Beschreibung des Interfaces von Funktionen, Geräten und Datenpunkten. Beispiele sind Analog Input, Schedule (Zeitschaltplan) oder Loop (PID-Regler). Die Objekte bestehen aus einer Sammlung von Eigenschaften oder Parametern, genannt Properties (Bild ). Diese Properties können mit Hilfe verschiedener Dienste gelesen oder z. T. geschrieben werden. Services. Die momentan 35 definierten Services beschreiben, wie auf die Daten zugegriffen werden kann. Sie können in fünf Gruppen eingeteilt werden: · Object Access · Alarm and Event · File Access · Remote Device Management · Virtual Terminal Beispiele: Mit dem Read Property Multiple-Dienst wird eine Liste von Eigenschaften eines Objektes gelesen; mit dem Subscribe-COV-Dienst kann man bei geeigneten Objekten eine spontane Benachrichtigung bei Wertänderungen (COV = Change OfValue) abonnieren. Proprietäre Erweiterungen. Sowohl Objekte als auch Properties können um firmenspezifische (proprietäre) Merkmale erweitert werden. Damit lassen sich Geräte herstellen, die zwar Interoperabilität bieten, sich aber doch von der Konkurrenz abheben. Auch auf proprietäre Objekte und Properties kann von Fremdsystemen zugegriffen werden, wenn das der Hersteller erlaubt, allerdings mit leicht erhöhtem Planungsaufwand (Austausch von Listen mit Adressen und Datentypen). Gebäudeautomation Elektropraktiker, Berlin 57 (2003) 5 389 BACnet und OPC - Widersacher oder Partner ? N. Degunda, Jürg P. Keller, Oensingen; R. Staub, Zürich Betreiber von großen Gebäudekomplexen machen sich schon länger für einen Kommunikationsstandard in der Gebäudeautomation stark. BACnet gilt - auch in der weltweiten Normierung - als aussichtsreicher Kandidat für diese Rolle. Oft wird in der Gebäudeautomation jedoch auch das aus der industriellen Leittechnik stammende OPC eingesetzt. Fälschlicherweise werden die beiden Technologien oft gegeneinander ausgespielt, dabei ergänzen sie sich heute bereits sehr gut. Niklaus Degunda, Jürg P. Keller, Fachhochschule Solothurn, Nordwestschweiz und Richard Staub, www.bus-house.ch, Zürich. Autoren Beispiel eines BACnet-Gerätes mit BACnet-Objekten Quelle: Siemens Vordefinierte Funktionsbausteine. BAC-net stellt eine sehr umfassende Sammlung an Bausteinen zur Verfügung, die selten alle von einer Anlage benötigt werden. Deshalb wurden sogenannte BACnet Interoperable Building Blocks BIBBs definiert. Diese stellen eine logische Zusammenfassung von BACnet-Diensten zu Funktionsgruppen/-bausteinen dar, mit denen die jeweils zur Verfügung stehenden Funktionen eindeutig definiert werden, um die Interoperabilität sicherzustellen. Dies ist vor allem bei Ausschreibungen sehr wichtig. 3 Eigenschaften von OPC Oft stellt sich das Problem, dass Daten von Steuergeräten (z. B. Speicherprogrammierbaren Steuerungen) in einem PC-basierten Netzwerk benötigt werden. Beispiele dafür sind Anlagenbedienungen und die Datenerfassung. Damit die Schnittstelle zu einem Steuergerät nicht für jede einzelne Applikation von neuem erstellt werden muss, sollen Server, so genannte OPC-Server, diese Daten über ein offenes Interface den interessierten OPC-Clients innerhalb der Microsoft-Welt zur Verfügung stellen. Der OPC-Standard definiert Objekte und Interfaces, die für die Übertragung von „Echtzeit“-Daten geeignet sind. Er ist kein Kommunikationsprotokoll, sondern eine Schnittstelle zwischen der klassischen Steuerungstechnik und der Informatik. Dazu bedient sich OPC der Microsoft-Komponenten-Technik mit COM/DCOM (Component Object Model / Distributed Component Object Model). Dadurch werden verschiedene Aufgaben wie z. B. Sicherheit, Server-Start und die Kommunikation zwischen verschiedenen PCs durch das Betriebssystem und den Netzwerkserver gelöst (Bild ). Objektmodell. Startet ein OPC-Client einen OPC-Server wird ein Serverobjekt gebildet. Das Serverobjekt lädt von einem Konfigurationsfile die Informationen aller ihm zur Verfügung stehenden Variablen. Der Client befiehlt nun dem Server, Gruppenobjekte zu bilden. Interessiert sich der Client für einen Messwert oder einen Variablenwert, so erzeugt er in einem Gruppenobjekt ein entsprechendes Itemobjekt. Kennt der Client den Itemnamen nicht, so stehen Browsefunktionen zur Verfügung. Es stellt sich die Frage, wieso die Itemobjekte in Gruppenobjekten und nicht direkt im Serverobjekt gebildet werden. Das Ziel der OPC-Gruppen ist es, Items zusammen zu fassen, die nach dem gleichen Datenfluss übertragen werden. Für jedes Gruppenobjekt muss also festgelegt werden, wie die Daten der Items übertragen werden. Dabei kann z. B. festgelegt werden, dass die Items einer Gruppe periodisch oder bei Wertänderung übertragen werden. 4 BACnet und OPC im Vergleich Die folgenden Ausführungen stützen sich auf das Kommunikationsmodell für Gebäudeautomation des CEN (Comitée Européen de Normalisation ). Bild zeigt die derzeit als Vornorm von CEN vorgeschlagenen Kommunikationsprotokolle. Die Frage „BACnet oder OPC?“ greift allerdings zu kurz. Je nach Sichtweise werden unterschiedliche Kriterien betrachtet. · der Planer wird fragen: Was muss ich ausschreiben, damit ein offenes System resultiert? Die Investition des Bauherrn soll möglichst lang geschützt bleiben. Und spätere Erweiterungen sollen kostengünstig möglich sein. · der Hersteller von Automations-Geräten muss sich entscheiden, welche Schnittstelle er in seinen Geräten im-Gebäudeautomation Elektropraktiker, Berlin 57 (2003) 5 390 Europäische Standardisierung in der Gebäudeautomation (CEN) Quelle: Siemens BACnet als Standard in der Sicherheitstechnik Quelle Siemens Beispiel einer OPC-Anwendung Gebäudeautomation plementiert, damit seine Marktchancen möglichst groß sind. Neben einem zukunftsträchtigen Systemkonzept ist er an geringen Entwicklungs- und Materialkosten interessiert. Er muss auch an die Wartbarkeit (Reparatur, Ersetzbarkeit während der Produktlebensdauer) denken. · der Systemintegrator will eine Lösung haben für eine gleichwertige Integration beider Systeme in seine Managementstation. Er will möglichst kleinen Engineering-Aufwand bei hoher Funktionalität. BACnet ist ein auf die Gebäudeautomation ausgerichtetes Standard-Protokoll und definiert Objekte, Dienste und Funktionen. Sein Einsatz ist zurzeit vor allem in Managementsystemen und Automationsgeräten für Heizung/Lüftung/Klima sinnvoll, wobei zunehmend auch Feldgeräte z. B. über MS/TP als natives BACnet eingebunden werden. OPC ist eine Interface-Definition und erlaubt einem Client, die Daten von den erreichbaren Servern zu holen. Es sind nur einfache Datentypen für die Items definiert. Sie bestehen aus dem Itemnamen, dem Wert, der Qualität und seinem Zeitstempel. Für jedes Item können statische Item-Eigenschaften festgelegt werden. Diese Information dienen einem Client bei dessen Konfiguration, so z. B. bei der Festlegung der zulässigen Wertebereiche und Engineering-Einheiten. Die Anwendung von OPC ist vor allem sinnvoll auf Managementebene, wenn vernetzte Workstations auf PC-Basis (mit Windows-Applikationen) eingesetzt werden. In Tafel sind die Eigenschaften von BACnet und OPC gegenübergestellt. Optimale Einsatzgebiete beider Technologien Im Zusammenhang mit gebäudetechnischen Automationsfunktionen weist BAC-net große Vorteile auf. Verteilte Funktionen wie z. B. Alarmierung mit Quittierung oder Zeitschaltprogramme können einfacher realisiert werden. Auch ein Datenaustausch der Geräte untereinander (peer to peer) ist realisierbar. Kurz: Für die funktionelle Automation empfiehlt sich BACnet. Zu beachten ist auch, dass bedeutende Hersteller von Sicherheitssystemen, z. B. Siemens Building Technologies, sich für BAC-net als Protokoll für die Integration von Sicherheitsanlagen in ein gesamtes technisches Gebäudemanagement erklärt haben (Bild ). Wenn es „nur“ um Datenaustausch für die Visualisierung oder Archivierung zwischen Anwendungen auf einem Rechner geht, oder wenn Daten mit IT-Systemen ausgetauscht werden müssen, ist OPC besser geeignet. OPC ist aber kein Protokoll. Zwischen verschiedenen Rechnern, die über ein Netz verbunden sind, kann OPC alleine keine Daten austauschen; OPC benötigt immer Kommunikationsprotokolle. Der Vorteil liegt darin, dass keine spezifischen Protokolle nötig sind (wie z. B. BACnet), sondern die ganz normalen IT-Protokolle ausreichen. OPC ist also geeignet, um auf Managementebene Daten verschiedener Subsysteme zu sammeln und auch an Microsoft-basierende Business-Applikationen weiterzugeben. Folgendes Beispiel zeigt den Vorteil von BACnet gegenüber OPC: Wenn ein Gerät A mit einem Gerät B Daten austauschen muss, z. B. Wärmeanforderung, Kältebedarf, Außentemperatur, Speicherstand, etc., kann dies direkt geschehen (peer to peer), wenn die Geräte über BACnet kommunizieren. Bei einem Gerät C, das über OPC eingebunden wird, muss die Information über die Managementstation oder einen andern OPC-Client laufen. Dies soll sich allerdings mit der Einführung der Spezifikation OPC DX (Data Exchange) ändern. Pilotanwendungen waren auf der Hannover Messe im vergangenen Jahr zu sehen. Im Allgemeinen wird heute von einer Managementstation ein OPC-Client angeboten. Es gibt auch auf OPC basiernde Managementsysteme, die Daten aus den angeschlossenen Systemen, also über einen (oder mehrere) OPC-Server, holen. Es existiert ein breites Angebot von OPC-Servern. Auch für BACnet gibt es einige. Zum Beispiel sind BACnet-Clients auf dem Markt, die als OPC-Server die BACnet-Daten via OPC einer Managementstation zur Verfügung stellen. Da nie alle Komponenten der Gebäudetechnik, die in ein Gesamtsystem zu integrieren sind, BACnet unterstützen werden (auch wenn BACnet zur weltweiten Norm wird), muss eine Managementstation andere Möglichkeiten der Integration vorweisen können. OPC ist hier die gute Ergänzung, die schon breit verfügbar ist. Zusammenfassung BACnet und OPC sind weniger Kontrahenten als Partner. Eine Integration von BACnet-Geräten in ein BACnet-System wird in Zukunft ohne Probleme von statten gehen. OPC kann aus Sicht der Gebäudeautomation dazu dienen, weitere Systeme einzubinden, die nicht über BACnet kom-Elektropraktiker, Berlin 57 (2003) 5 391 Anzeige munizieren, aber einen OPC-Server anbieten. Ebenso können mit einem OPC-Server Daten für andere Systeme zur Verfügung gestellt werden. Die Vorteile von BACnet dürften hauptsächlich in der horizontalen Integration liegen, wo BACnet-Geräte untereinander direkt (Peer-to-peer) kommunizieren können und auch ohne zusätzliche Gateways mit BACnet-Bedienstationen (Operator Work Station) bedienbar sind. OPC DX wird hier vermehrt Konkurrenz machen, hat aber immer noch den Nachteil, dass Gebäudetechnik-Funktionen und -Objekte nicht wie in BACnet unterstützt werden, sondern nachgebildet werden müssen. In Zukunft dürften auf der Automationsebene auch SOAP-Lösungen ins Gespräch kommen. SOAP steht für Simple Object Access Protocol und basiert auf XML (eXtensible Markup Language). Diese könnten sehr wohl auf BACnet aufbauen. Und für die Bedienung könnten sich vermehrt Webserver-Lösungen statt OPC-Integrationen durchsetzen. Wir leben also auch in der Gebäudeautomation mit einer unablässigen Weiterentwicklung von Kommunikations- und Informatik-Technologien. Umso wichtiger ist daher die internationale, firmenunabhängige Normierung von Objekten und Services für die spezifischen Bedürfnisse der Gebäudeautomation, wie dies BACnet verfolgt. Literatur [1] F. Iwanitz, J. Lange: OLE for Process Control, Grundlagen, Implementierung und Anwendung. Heidelberg: Hüthig-Verlag 2000. [2] Barelmann u. a.: OPC in der Praxis. Offenbach/Berlin: VDE-Verlag, 1999 Gebäudeautomation Elektropraktiker, Berlin 57 (2003) 5 392 Tafel Eigenschaften von BACnet und OPC Kriterium BACnet OPC Hersteller-Abhängigkeit internationaler Standard, unabhängig von Firmen-Standard, basiert auf Microsoft COM/DCOM. Betriebssystem und Hersteller Mit OPC-XML uneingeschränkte Internetfähigkeit, abhängig von der jeweiligen Betriebssystemversion! Einsatz verbindet Systeme u. Geräte in der Gebäudetechnik, verbindet Geräte und Steuerungen der Fertigungs-/ v. a. auf Automations- und Management-Ebene zum Verfahrenstechnik mit Bedien- und Beobachtungs-Zweck der Gebäude-Automation. systemen sowie mit Business-Applikationen Geschichte ANSI/ASHREA-Norm 1995 nach acht Jahren Entwicklung Taskforce 1995 (5 Hersteller) Kommunikationsmodell Client-Server, objektorientiert Client-Server, datenflussorientiert plug and play nein ja, falls Netzwerk und Netzwerksicherheit richtig konfiguriert Datentypen beliebig, auch strukuriert einfache, definiert Erweiterbarkeit ja: proprietäre Objekte, Properties, Dienste nein Interoperabilitäts- Data Sharing Data Access (DA) bereiche/Spezifikationen Alarm and Event Mgt. Alarm & Events (AE) Trending Historical Data Access Scheduling Batch Device and Network Mgt. OPC XML (uneingeschränkte Internetfähigkeit, Plattform-Unabhängigkeit), Data Exchange (DX, neu) Eignung für Management-Ebene ja ja für Automations-Ebene ja z. Zeit nein, teilweise auf Windows CE realisierbar für Peer-to-peer-Kommuniaktion ja nein für Feld-Ebene ja (in USA Haupteinsatzgebiet!) nein Datenaustausch mit nein; Business-Applikationen enthalten kaum ein Einfach, da DCOM-Schnittstelle in Microsoft-Welt Business-Applikationen BACnet-Interface verbreitet ist. HLKE ja, spezifische Objekte Programmierung erforderlich Sicherheitssysteme ja, spez. Objekte DCOM - Sicherheitssystem Netzwerk-Unterstützung 5 LAN-Typen, IP (ein BACnet-System mit Internet- MS, Internet (XML) Verbindungen ist möglich) Kosten keine Lizenzen Serverlizenzen Unabhängigkeit ja setzt üblicherweise Microsoft-Betriebssysteme voraus, Realisierungen auf LINUX und UNIX erhältlich. Alarm-Management integriert ja Zeitschalt-Management integriert muss in Client-Applikation programmiert werden Trend-Management integriert muss in Client-Applikation programmiert werden Dynamische Management- ja muss in Client-Applikation programmiert werden Funktionen (z. B. temporäres Aufzeichnen eines Wertes ohne Konfigurationsänderung) Konformitätssicherung Zertifizierung durch BTL (BACnet Test Lab.) ; im Aufbau Compliance Tests durch OPC Foundation Planung Absprachen nötig, standardisierte Datenpunktlisten Binding mit Hilfe der Browse-Funktionen von BIG-EU Tool firmenspezifisch firmenspezifisch Diagnose, Test VTS (Virtual Test Shell): kostenloses Tool; firmenspezifisch Tools oft vom Serveranbieter erhältlich Inbetriebsetzung Im Rahmen der Engineering- und Installationsphase Konfiguration von DCOM kann bei ungünstiger Netzwerkstruktur schwierig sein. Betriebssicherheit eher hoch hängt vom Umfeld des Systems ab Firewall ist eine Systemanforderung und unabhängig von dem Durchgängigkeit nicht gewährleistet (ausser mit XML) verwendeten Kommunikationsprotokoll Lebensdauer eher lang (Produkt-Lebensdauer, Serviceverpflichtung) Portierung auf neue MS-Betriebssysteme bis jetzt gewährleistet
Autor
- N. Degunda/ Jürg P. Keller/R. Staub
Downloads
Laden Sie diesen Artikel herunterTop Fachartikel
In den letzten 7 Tagen:
Sie haben eine Fachfrage?