Win-win-Situation für Hersteller und Planer

Funktionale Beschreibung im Datenstandard Eclass

Bild 1: Mittig findet sich, weiß unterlegt, die ­Bezeichnung der eigentlichen Funktionalität, z.B. ‘Lichtsteuerung über Raumnutzungsarten’. – Bild: Amperesoft GmbH

Welche Geräte von welchem Hersteller eignen sich für welche Gebäudeautomation? Dies ist die zentrale Frage, die Planer von Smart-City-Konzepten umtreibt. Mit einzubeziehen sind dabei nicht nur Bauherrenwünsche, sondern vor allem Normen und Vorschriften, z.B. zum Brandschutz. Um eine optimale Entscheidung treffen zu können, ist eine genaue Information sowohl über die physikalischen Eigenschaften eines Produktes als auch die Funktionalitäten und Anwendungsfälle unumgänglich. Dafür gilt es zumeist in Handbüchern nachzuschlagen, um ein Verständnis für jedes Gerät zu entwickeln und auf dieser Grundlage das Produkt auszuwählen, das im Anwendungsfall die beste Performance verspricht.

Hohe Komplexität

Bei zunehmendem Fachkräftemangel und einer zugleich wachsenden Zahl von Gebäudeautomationsprojekten fehlt oftmals die Zeit zur Information über unbekannte Produkte. Hinzu kommt, dass Smart-Building-Projekte und deren Anforderungen immer umfangreicher werden und die Zahl der zu beachtenden Normen steigt. Die Komplexität der Planung wird in den nächsten Jahren weiter zunehmen. Das bedeutet eine Flut an Informationen, die im Planungsprozess von Akteur zu Akteur weitergegeben werden müssen. Kein Wunder, dass hier schnell etwas verloren geht. Dadurch entstehen Probleme oder fehlerhafte Planungen, die wiederum wertvolle Zeit kosten.

ServiceFlow startet Lösungssuche

Genau diese Problematik war es, die zur Gründung eines Konsortiums führte, zu dem neben der TU Dresden und Amperesoft auch F:Data und Kieback & Peter zählen. Ziel war es, eine Infrastruktur für Services und Dienstleistungen zu entwickeln, um den softwaregestützten Planungsprozess zu optimieren. Zudem sollten Standards für Gebäudeautomatisierungsprojekte im Rahmen von Smart-City-Konzepten festgesetzt werden, die für eine Verbesserung des Informationsflusses in der Planung sorgen sollte. Mit Projektstart wurde vor allem eines klar: Bei der Gebäudeplanung gibt es nicht den einen korrekten Ablauf, der zum Ziel führt. Vielmehr verfolgen die Experten verschiedene Ansätze, was zu unterschiedlichen Abläufen führt. Um die Planungsschritte der anderen Projektpartner und die Anforderungen, die einzelnen Aspekten zu Grunde lagen, dennoch nachvollziehen zu können, braucht es demnach eine Art Logbuch. In diesem Systemgedächtnis in Form einer Datenbank werden alle Planungsinformationen zu einem Gebäudeautomationsprojekt abgelegt. Über den Automatisierungsprozess hinweg wächst der Datenbestand an und es entstehen Verknüpfungen einzelner Informationen. Verlorene oder fehlerhafte Daten gehören somit der Vergangenheit an. Damit ist das Systemgedächtnis eine Ergänzung zum Building Information Modeling, das sich auf die Materialien und Geometrien bei der Planung und Errichtung des Bauwerkskörpers bezieht, die Gebäudeautomation jedoch nicht beachtet. Das Systemgedächtnis hingegen enthält Informationen über Wirkmechanismen, Datenflüsse sowie die Funktionalitäten der Geräte.

Bild 2: Um den Informationsfluss innerhalb des Gerätes abzubilden, finden sich auf der linken Seite Schnittstellen, über die Informationen in das Gerät gelangen
Bild 2: Um den Informationsfluss innerhalb des Gerätes abzubilden, finden sich auf der linken Seite Schnittstellen, über die Informationen in das Gerät gelangen Bild: Amperesoft GmbH

Verknüpfung über Standardisierung

Über die Entwicklung des Systemgedächtnisses hinaus ist die zentrale Leistung des Konsortiums das Vorantreiben der Standardisierung des Planungsprozesses, etwa durch die Entwicklung einer DIN Vornorm für Ausschreibungen. Auch die Beschreibung von Automationskomponenten muss vereinheitlicht sein, wobei nicht nur deren physikalischen Eigenschaften, sondern auch den Funktionalitäten Bedeutung zukommt. Für diese enge Verzahnung ist der Eclass-Standard ein geeignetes Vehikel. So ist eine Zeitersparnis möglich, wenn die Produktdaten nicht länger manuell für jedes Gerät einzeln herausgesucht werden müssen, sondern standardisiert und gesammelt zur Verfügung stehen. In einem Workshop entwickelten die Mitglieder des Eclass-Arbeitskreises und die Teilnehmer des ServiceFlow-Projektes das Konzept für funktionale Beschreibungen im Eclass-Standard, das in der aktuellen Eclass-Version umgesetzt ist.

Funktionalität bedeutet Verarbeitung

Eine Funktionalität lässt sich als eine Handlung definieren, die durch Informationsverarbeitung ausgelöst wird. Ein Beispiel ist ein Gerät zur Lichtsteuerung. Wird der Lichtschalter betätigt, sendet dieser an die Lampe das Signal ‚Licht an‘. In Eclass gilt es nun zu beschreiben, wo dieses Signal in welcher Form ankommt und wie es in der Lampe verarbeitet wird, sodass schließlich das Licht angeht. Gibt es zusätzlich die Möglichkeit, das Licht zu dimmen, bedeutet dies eine weitere Informationsverarbeitung im Gerät. Komplexer wird dies bei Produkten, die mehr als eine Funktionalität abdecken, also z.B. die Lichtsteuerung, die Organisation der Raumtemperatur und darüber hinaus der Nutzung des Tageslichts. Die funktionale Beschreibung in Eclass modelliert nun die Informationsflüsse und Funktionalitäten der Geräte. Sie lässt sich als eine anschauliche grafische Darstellung begreifen, die am Ende in das maschinenlesbare Eclass-Modell übertragen wird (Bild 1). Mittig findet sich, weiß unterlegt, die Bezeichnung der eigentlichen Funktionalität, z.B. ‚Lichtsteuerung über Raumnutzungsarten‘. Das hier verwendete Vokabular folgt der VDI-Richtlinie 3813 zu den Grundlagen der Raumautomation. Die Funktionalität ist entscheidend, um die Anforderungen der Bauherren zu erfüllen. Doch da Funktionalität und Informationsverarbeitung Hand in Hand gehen, muss auch der Fluss der Informationen betrachtet werden. Um den Informationsfluss innerhalb des Gerätes abzubilden, finden sich auf der linken Seite Schnittstellen, über die Informationen in das Gerät gelangen (Bild 2). Dabei wird genau festgelegt, welcher Art die bei einer bestimmten Schnittstelle erwartete Information ist. Wird also z.B. eine Szenennummer erwartet, so ist dies aus der Grafik ebenso ersichtlich, wie die zugehörigen Tags. Entsprechend findet sich auf der rechten Seite eine Darstellung des Informationsausgangs, also letztlich des verarbeiteten Befehls an die Lampe, der zur Handlung führt.

Spürbare Mehrwerte für Planer

Die Vorteile, die sich aus einer funktionalen Beschreibung eines Geräts mit Eclass ergeben, sind vielfältig. Für die Planung wird zumeist eine Software genutzt, in der Anforderungen abgelegt werden und die dann aufzeigt, welche Geräte geeignet sind, um diese zu erfüllen. Je komplexer die Anforderungen und zu beachtenden Normen, desto schwerer fällt auch die Wahl des optimalen Gerätes. Um Zeit zu sparen, beschränken sich Planer häufig auf die ihnen bekannte Produkte. Geeignetere Geräte, die eine bessere Performance im speziellen Anwendungsfall bieten, bleiben so ungenutzt. Noch größere Auswirkungen entstehen, wenn ein noch unbekanntes Gerät Funktionen bietet, die bislang durch die Kombination von Geräten realisiert werden müssen. Aus Unkenntnis wird es nicht in Betracht gezogen und stattdessen mehrere Geräte zeitaufwändig miteinander verschaltet. Haben diese zudem unterschiedliche Liefertermine, kommt es zu Verzögerungen. Mit der funktionalen Beschreibung in Eclass gehören derartige Situationen der Vergangenheit an. Denn durch die standardisierte funktionale Beschreibung erkennt der Planer schnell und einfach, was ein Gerät in welcher Weise und mit welchem Informationsfluss kann.

Bild 3
Bild 3Bild: Amperesoft GmbH

Weil es sich lohnt

Voraussetzung dafür ist jedoch, dass Hersteller handeln und neben der schriftlichen Dokumentation ihrer Produkte auch eine Beschreibung in Eclass vornehmen. Wichtige Aspekte einer Beschreibung sind u.a. die Struktur des Geräts, die vorhandenen Schnittstellen und die Konfigurationsmöglichkeiten. Bei Letzteren werden die prägnantesten Gesamtkonfigurationen gewählt. Sie erhält einen Namen, den sogenannten Betriebsmodus. Für jeden Betriebsmodus wird anschließend ein Funktionsmodell als Eclass-Struktur erstellt (Bild 3). Unzureichend oder gar nicht in Eclass beschriebene Produkte werden künftig bei der softwaregestützten Planung nicht zur Auswahl gestellt. Entscheidend ist nicht länger nur der Preis. Vielmehr werden die bestmögliche Performance und die optimal zu den Anforderungen passenden Funktionalitäten in den Mittelpunkt gerückt. Das am besten für einen speziellen Anwendungsfall geeignete Produkt gewinnt: jedoch nur, wenn es bekannt ist und klar ist, was es leisten kann. Ein weiterer Aspekt ist der Markteintritt neuer Lösungen. Bisher mussten die Produkte Planern bekannt gemacht und dann darauf vertraut werden, dass diese das Handbuch lesen und die Lösung in ihr Repertoire aufnehmen. Ist die funktionale Beschreibung in Eclass vorhanden, wird die Nutzung zum Selbstläufer, da das neue Gerät in allen passenden Projekten vorgeschlagen wird.