IT zur Gebäudesteuerung

Der Einsatz von IT zur Steuerung von Gebäuden ist unerlässlich geworden. Wie bei den Anfängen der IT-Industrie haben Anbieter von „Building Management“-Systemen (BMS) zunächst hochproprietäre Lösungen angeboten, welche nur von ihnen selbst installiert und gewartet werden konnten. Mit der Weiterentwicklung der Technologie wurde auch die Software zur Programmierung der erforderlichen Steuerungslogistik vereinfacht. Infolgedessen konnte ein breiterer Personenkreis das Engineering übernehmen. Unterdessen führte der Druck von Endanwendern, die während der gesamten Lebensdauer des Gebäudes bzw. Campus nicht nur an einen Hersteller gebunden sein wollten, zur Entwicklung offener Protokollstandards. Dies ermöglichte auch die Kommunikation zwischen den unterschiedlichen Systemen.

Die technische Ausstattung von Gebäuden erfordert nicht nur eine Reihe Gewerken, das Problem liegt darin, dass alle Teilbereiche ihre eigenen Standards und Steuerungsinstrumente aufweisen. Das Ergebnis ist eine Vielzahl von „Standard“-Protokollen, die von den verschiedenen Subsystemen in einem Gebäude verwendet werden: BACnet für HLK-Systeme, DALI und KNX für die Beleuchtung, Modbus und M-Bus für Verbrauchsmessung sowie Zählermanagement usw. Einige Protokolle wie LonWorks schafften es eine Weile mit ihren gewerkeübergreifenden Funktionen an Fahrt zu gewinnen, jedoch ist die Akzeptanz in den letzten Jahren wieder gesunken. Obwohl die TGA-Branche immer noch davon träumt, dass es „einen Standard für alle gibt“, ist die Realität noch chaotisch. Die Herausforderung, dass alle Systeme miteinander kommunizieren können, ist größer denn je.

Zugegeben, die weit verbreiteten Spezifikationen und die Adaption der oben aufgeführten offenen Standards hat den BMS-Ingenieuren das Leben bereits erheblich erleichtert, aber die Standardisierung der Kommunikation löst nur einen Teil des Problems. Wann immer zwei Systeme versuchen zu interagieren, ist ein erheblicher Zeitaufwand erforderlich, um sicherzustellen, dass die Daten des einen Systems von dem anderen richtig verstanden und korrekt an die übergeordnete Software übertragen werden. Die übergeordnete Software dient im Allgemeinen als Überblick und Überwachung der Gebäudeleistung, zeigt Grundrisse, Anlagenschemata, Dashboards sowie Berichte an.

Vernetzte Automation zwischen Systemen

Wünschenswert wäre eine solche Kommunikation zwischen den Systemen, die automatisch und ohne manuellen Eingriff erfolgt und in der alle Gebäudedaten mit relativ geringem Engineering-Aufwand im erforderlichen Format visualisiert werden können.

Der Schlüssel besteht darin, einen Kontext für die Daten zu schaffen, der zwischen den Systemen übertragen wird – heute allgemein als „Tagging“ bezeichnet. Hierzu gab es verschiedene Ansätze. So haben einige der Protokollstandards wie LonWorks und BACnet das Konzept der Profile entwickelt, die einen Großteil der Metadaten definieren, welche mit einem realen Datenpunkt verbunden sind. Leider waren diese Profilansätze für Computer nicht ausreichend, um die Vernetzung von Systemen vollständig zu automatisieren. 

In den letzten Jahren hat eine „Open Source“-Initiative namens „Project Haystack“ versucht, diese Tagging-Anforderungen für Gebäude endgültig zu lösen. Das Projekt „Haystack“ gewinnt nun weltweit an Bedeutung und befindet sich im Gespräch mit dem US-Fachverband ASHRAE (auch Initiator des BACnet-Standards) und Brick (einer jüngeren, von der IT inspirierten Initiative), um herauszufinden, wie ein gemeinsamer Ansatz vereinbart werden kann. In Systemen, in denen alle Daten mit Tags versehen sind, ist es dann möglich, die Erstellung von Anlagenplänen, Grundrissen, Dashboards, Alarmierung und Energieberichten nahezu vollständig zu automatisieren sowie Fehler- und Leistungsanalysen in Echtzeit durchzuführen.

Vorteile offener Frameworks

Und genau deshalb sind offene Frameworks wichtig. Gegenwärtig sieht die Realität bei BMS-, Beleuchtungs-, Brandmelde- und anderen Herstellern von Steuerungs- und Überwachungssystemen für Gebäude jedoch noch anders aus. Sie haben weder eine Software für ihre proprietären Systeme entwickelt, die ein solches Tagging von Haus aus ermöglicht, noch bieten sie eine Möglichkeit, die Verwaltung der Daten aus mehreren Systemquellen zu automatisieren. Offene Frameworks sind von Grund auf so konzipiert, dass sie Daten aus verschiedenen Quellen und Protokollen verarbeiten können, was den Prozess der Entwicklung integrierter Systeme mit gemeinsamer Visualisierung erheblich vereinfacht. Die zunehmende Nutzung und Spezifikation des „Niagara“-Frameworks von Tridium und seinen Partnern zeugt vom Erfolg des Open-Framework-Ansatzes. Kürzlich hat Tridium auch eine Tagging-Funktion mit spezifischer Unterstützung für den „Haystack“-Standard hinzugefügt. 

Inzwischen geht das „FIN“-Framework von J2 Innovations noch einige Schritte weiter, da es vollständig auf dem Konzept des Taggings mit „Haystack“ entwickelt wurde. Damit ist erstmals die Automatisierung der Grafikerstellung, Alarmierung, Dashboards und Reports Realität geworden. Dies bietet nicht nur eine deutliche Zeitersparnis bei der Planung der BMS und der zugehörigen Gebäudesysteme, sondern schafft auch das Potential für neue Funktionalität und Diagnosen.

Zu Beginn des Tagging und des „Haystack“-Standards wurde die Message-Definition durch das verwendete Protokoll definiert, das spezifisch für den Bereich der Gebäudetechnik ist. Jetzt ist eine offene Framework-Software wie „FIN“ in der Lage, Daten von jedem System – unabhängig vom Protokoll – zu „lesen“. Voraussetzung hierfür ist, dass die Daten über IP unter Verwendung eines Übertragungsverfahrens wie MQTT, JSON oder einer REST-API gesendet werden – alles Standards, die von IT-Systemen in vielen anderen Branchen verwendet werden. Mit zunehmendem Einsatz von „Haystack“ wird sich der Anwendungsbereich der vereinbarten Tags weit über die Gebäudetechnik hinaus erstrecken und auch Business-Software für beispielsweise die Buchung eines Konferenzraums oder Arbeitsplatzes, CAFM/CMMS, Asset-Management, Parkplätze usw. umfassen.

Da Gebäude mehr als Jahrzehnte überdauern und die darin installierten elektronischen Systeme eine Lebensdauer von mindestens 10 bis 15 Jahren haben, ist es nicht verwunderlich, dass die BMS-Industrie etwas langsamer auf Veränderungen reagiert wie die schnelllebige IT-Welt. Seit vielen Jahren wird Computersoftware durch den Einsatz gängiger Betriebssysteme wie „Windows“, „Unix“ und „Linux“ von der Hardware abgekoppelt, wobei JVM (Java Virtual Machines) bei der Portierbarkeit von Software auf embedded-Hardware-Plattformen helfen. Dieser Trend hat zu einer Beschleunigung der Innovationen und zu weitaus mehr Flexibilität sowie Wettbewerb auf dem Markt geführt.

Im Bereich der Gebäudeleittechnik sind wir jedoch noch weit davon entfernt, diese Entkopplung zu akzeptieren, die vor allem Randprodukte (primär Datenerfassungs- und/oder Kontrollgeräte) betrifft. Und das, obwohl auf globaler Controller-Ebene sowohl Niagara als auch FIN von verschiedenen OEM-Partnern portiert wurden. „FIN“-Framework kann auf einer JVM auf sehr kleinen, kostengünstigen Plattformen wie „Raspberry Pi“ oder „Beaglebone“, die nur wenige Euro kosten, laufen. Eine neue Version, die im nächsten Jahr auf den Markt kommt, wird den Prozessor- und Speicherbedarf weiter reduzieren und ist somit für noch kleinere Hardwareplattformen geeignet. Offensichtlich ist die Technologie vorhanden, wenn die Hersteller von Geräten und Steuerungen sie wollen.

Fazit

Es besteht heute kein Zweifel mehr, dass die Zukunft für den Gebäudesektor offene Systeme mit einem Tagging-Standard sein werden, der über IP-Netzwerke und IT-basierte Übertragungsstandards verbunden ist. Die Hardware ist dabei weitgehend unabhängig von der Software verfügbar, die die Anwendung bereitstellt. Das aktuelle Paradigma, das von den großen Steuerungskonzernen wie Siemens, Honeywell und Schneider vorgeschlagen wird, verwendet eigene Hard- und Software, die ein intensives System-Engineering erfordern und Kunden bindet – bei der Wartung und bei Upgrades. Dieser Ansatz wird Systemen weichen, die mit offener Framework-Software mehrere Geräte und Systeme mit weitgehend automatisierten Konfigurationsprozessen miteinander vernetzen.