Durchgängiges und modellbasiertes Engineering von ......Durchgängiges und modellbasiertes Engineering von Gebäudeautomationssystemen Von der Fakultät für Maschinenbau der Helmut-Schmidt-Universität

Durchgängiges und modellbasiertes Engineering von

Gebäudeautomationssystemen

Von der Fakultät für Maschinenbau der Helmut-Schmidt-Universität / Universität der

Bundeswehr Hamburg zur Erlangung des akademischen Grades eines Doktor-

Ingenieurs (Dr.-Ing.) genehmigte

Dissertation

von

Dipl.-Ing. Michelle Günther

aus Bergedorf

Hamburg 2018

Gutachter: Univ.-Prof. Dr.-Ing. Alexander Fay

Univ.-Prof. Dr.-Ing. Wolfgang Kastner

Vorsitzender: Univ.-Prof. Dr.-Ing. habil. Thomas Klassen

Tag der mündlichen Prüfung: 12.10.2018

Danksagung

Die vorliegende Arbeit entstand während meiner Zeit als externe wissenschaftliche

Mitarbeiterin an der Professur für Automatisierungstechnik der Helmut-Schmidt-Universität /

Universität der Bundeswehr Hamburg.

Ich möchte im Nachfolgenden allen Menschen meinen Dank aussprechen, die maßgeblich

zum Entstehen dieser Arbeit beigetragen haben.

Mein besonderer Dank gilt Herrn Prof. Dr.-Ing. Alexander Fay, welcher mir die Möglichkeit zur

Promotion überhaupt erst ermöglicht hat. Als Doktorvater hat er mich zu jederzeit unterstützt

und stand mit Rat und Tat zur Seite. Durch ihn habe ich in dieser Zeit die Bedeutung des

wissenschaftlichen Diskurses und die immer wiederkehrende Hinterfragung der eigenen

Ansätze sehr zu schätzen gelernt und dafür bin ich ebenfalls sehr dankbar.

Ebenfalls möchte ich mich bei Herrn Prof. Dr.-Ing. Wolfgang Kastner von der Technischen

Universität Wien für sein Interesse an meiner Arbeit bedanken, welcher freundlicherweise als

Zweitgutachter für diese Arbeit zur Verfügung stand.

Den gesamten Mitarbeitern des Instituts und auch den weiteren „externen“ Mitstreitern möchte

ich für ihre durchweg positive und konsequente Unterstützung in allen Belangen dieser Arbeit

danken. Namentlich möchte ich an dieser Stelle Herrn Dr. Philipp Puntel-Schmidt, Herrn Dr.

Maik Riedel und Herrn Dr. André Scholz hervorheben, welche im besonderen Maße durch den

häufigen gedanklichen Austausch zum Gelingen dieser Arbeit beigetragen haben.

Meiner Familie und meinen Freunden möchte ich danken für die großartige Unterstützung und

ihr Verständnis in den letzten Jahren. Die fortwährende Motivation und auch der Glaube an

mich haben mich dabei sehr bestärkt. Mein besonderer Dank gilt meinem Lebensgefährten

Mario Haas, welcher in dieser Zeit nicht nur eine wunderbare Stütze war, sondern mir bei der

Durchsicht meiner Arbeit wertvolle Ratschläge gegeben hat. Meiner Freundin Sabri danke ich

für die wunderbare Zeit und die großartige Inspiration, die sie mir mit auf meinen Weg geben

konnte.

Nörvenich, im Oktober 2018 Michelle Günther

VI

VII

Inhaltsverzeichnis

Abkürzungsverzeichnis ......................................................................................................... XI

Abbildungsverzeichnis ........................................................................................................ XIII

Tabellenverzeichnis ............................................................................................................. XV

1 Einleitung ........................................................................................................................1

1.1 Motivation und Problemstellung ..............................................................................1

1.2 Aufbau der Arbeit ....................................................................................................3

2 Grundlagen eines Gebäudeautomationssystems ............................................................5

2.1 Begriffsbestimmungen in der Gebäudeautomation ..................................................5

2.2 Raumautomationsfunktionen ...................................................................................7

2.3 Gruppierung und Aufbau der Funktionen ................................................................8

2.3.1 Die Funktionsstruktur ..........................................................................................9

2.4 Der Lebenszyklus von Gebäudeautomationssystemen .........................................12

3 Anforderungen an das Engineering von Gebäudeautomationssystemen ......................15

3.1 Marktanalyse vorhandener Gebäudeautomationssysteme ....................................15

3.1.1 Zentrale Systeme ..............................................................................................16

3.1.2 Dezentrale Systeme ..........................................................................................17

3.1.3 Subsysteme und Protokolle ...............................................................................18

3.1.4 Heimsysteme ....................................................................................................18

3.1.5 Systemeingrenzung ..........................................................................................19

3.2 Das Anforderungsportfolio der Gebäudeautomation..............................................20

3.2.1 Motivation Wirtschaftlichkeit ..............................................................................20

3.2.2 Motivation Funktionalität ....................................................................................21

3.2.3 Rahmenbedingung Qualitätssicherung ..............................................................21

3.2.4 Rahmenbedingung Bauprozess ........................................................................22

3.2.4.1 Gewerkegetrennte GA-Planung .................................................................24

3.2.4.2 Integrierte GA-Planung gemäß DIN EN ISO 16484 ...................................24

3.2.5 Zusammenfassung des Anforderungsportfolios.................................................25

3.3 Forschungsarbeiten auf dem Gebiet der Gebäudeautomation ..............................26

3.3.1 Die Wirtschaftlichkeit .........................................................................................26

3.3.2 Die Funktionalität ..............................................................................................27

3.3.3 Die Qualitätssicherung ......................................................................................28

3.3.4 Der Bauprozess ................................................................................................29

3.3.5 Ableitungen aus den Forschungsansätzen zur GA ............................................31

3.4 Abgeleitete Anforderungen an das Engineering von GA-Systemen .......................32

VIII

4 Handlungsbedarf für das Engineering der Gebäudeautomation ....................................34

4.1 Vorstellung relevanter Forschungsansätze ...........................................................34

4.1.1 Das Projekt AUTEG ..........................................................................................34

4.1.2 Das Projekt AUDRAGA .....................................................................................37

4.1.3 Das Projekt SCUBA ..........................................................................................38

4.1.4 Das Projekt TOPAs ...........................................................................................40

4.1.5 Ansatz einer GA-Toolkette ................................................................................40

4.1.6 Bewertung der vorgestellten Ansätze ................................................................40

4.2 Toolgestützte Lösungsansätze ..............................................................................41

4.3 Handlungsbedarf hinsichtlich eines durchgängigen Engineeringansatzes .............44

4.4 Vorstellung des durchgängigen, modellbasierten Engineeringansatzes ................47

5 Methode der Infrastruktursegmentierung ......................................................................50

5.1 Infrastrukturdaten als Basis der Planung ...............................................................50

5.1.1 Das Schalenmodell ...........................................................................................50

5.1.2 Überführung des Gebäudeplans in die Ortsstruktur ...........................................52

5.2 Analyse von Infrastrukturdaten ..............................................................................56

5.2.1 Die AutoCAD-Austauschdateien .......................................................................57

5.2.2 BIM-Datenaustauschdateien .............................................................................58

5.2.3 Aufbau der IFC-Datei ........................................................................................58

5.2.4 Umsetzung der automatischen Infrastruktursegmentierung ...............................64

6 Erstellung des GA-System-Modells ..............................................................................65

6.1 Methodik der GA-Anforderungserhebung ..............................................................65

6.2 Umsetzung in AutomationML ................................................................................66

6.2.1 Vorstellung des Engineering-Werkzeugs ...........................................................68

6.2.1.1 Bibliothek der Ortselemente ......................................................................68

6.2.1.2 Funktionsbibliothek ....................................................................................68

6.2.1.3 Bibliothek der Templates ...........................................................................68

6.2.2 Das Engineering-Modell eines GA-Systems ......................................................69

6.2.3 Die Benutzeroberfläche zur Anforderungserhebung der GA ..............................70

6.3 Automatische Generierung der Ortsstruktur ..........................................................73

6.4 Die Produktstruktur ...............................................................................................75

6.5 Simulation und Parametrierung des GA-Systems .................................................78

6.5.1 Möglichkeiten zur Simulation .............................................................................78

6.5.2 Konfiguration und Parametrierung des GA-Systems .........................................79

7 Teilmodellerstellung aus dem GA-System-Modell .........................................................80

IX

7.1 Vorstellung Ansatz TLT-Modell .............................................................................80

7.2 Methodik der Teilsystemerzeugung für die GA ......................................................81

7.3 Teilmodellerstellung eines GA-System-Modells ....................................................83

7.3.1 Ortsstrukturelle Teilmodellerstellung .................................................................84

7.3.2 Funktionale Teilmodellerstellung .......................................................................89

7.3.3 Teilmodellerstellung der Produktstruktur ...........................................................91

7.4 Erstellung von Funktionslisten ...............................................................................94

8 Aus- und Bewertung der Ergebnisse.............................................................................98

8.1 Erfahrungen im Rahmen eines Bauprojektes ........................................................98

8.1.1 Struktursegmentierung ......................................................................................98

8.1.2 Anforderungserhebung.................................................................................... 100

8.1.3 Erstellung von Funktionslisten ......................................................................... 101

8.2 Befragung von Experten ..................................................................................... 102

8.2.1 Auswahl der Experten ..................................................................................... 102

8.2.2 Experten auf dem Gebiet der GA .................................................................... 103

8.2.3 Experten aus dem Bereich der Bauherren....................................................... 105

8.2.4 Experten aus der Architektur von Gebäuden und Objektplanung .................... 106

8.3 Aus- und Bewertung der Ergebnisse ................................................................... 107

8.4 Bewertung in Hinblick auf den Anforderungskatalog ........................................... 108

8.4.1 Beschränkungen des Engineeringansatzes ..................................................... 110

8.4.2 Übertragbarkeit des Engineeringansatzes ....................................................... 112

9 Zusammenfassung und Ausblick ................................................................................ 113

9.1 Zusammenfassung ............................................................................................. 113

9.2 Ausblick .............................................................................................................. 114

Anhang A ........................................................................................................................... 116

Anhang B ........................................................................................................................... 117

Anhang C ........................................................................................................................... 118

Anhang D ........................................................................................................................... 119

Anhang E ........................................................................................................................... 120

Anhang F............................................................................................................................ 121

Anhang G ........................................................................................................................... 122

Anhang H ........................................................................................................................... 123

Anhang I ............................................................................................................................. 128

Anhang J ............................................................................................................................ 130

Anhang K ........................................................................................................................... 133

Anhang L ............................................................................................................................ 135

X

Anhang M ........................................................................................................................... 137

Literaturverzeichnis ............................................................................................................ 139

Normen- und Richtlinienverzeichnis ................................................................................... 146

Verzeichnis verwendeter Internet-Quellen und erwähnter Software.................................... 146

Verzeichnis der Veröffentlichungen des Verfassers ............................................................ 148

Verzeichnis der betreuten studentischen Arbeiten .............................................................. 151

Lebenslauf .......................................................................................................................... 152

XI

Abkürzungsverzeichnis

AA ............................................................................................................. Anlagenautomation

AAL .................................................................................................... Ambient Assisted Living

ANSI ............................................................................. American National Standards Institute

ASCII ..................................................... American Standard Code for Information Interchange

ASHRAE ............. American Society of Heating, Refrigerating and Air-Conditioning Engineers

AUDRAGA ................. Automatische Installation drahtloser Systeme der Gebäudeautomation

AUTEG .................................................... Automatisierter Entwurf für die Gebäudeautomation

BIM ........................................................................................... Building Information Modelling

CAD/ CAAD ................................................................. Computer Aided (Architectural) Design

CAEX ........................................................................ Computer Aided Engineering eXchange

DALI .............................................................................. Digital Addressable Lighting Interface

dwg ...................................................................................... DraWinG (Dateiformat AutoCAD)

dxf ............................................................ Drawing eXchange Format (Dateiformat AutoCAD)

EEPROM............................................. Electrically erasable programmable read-only memory

ELT ................................................................................................................... Elektrotechnik

ERM ................................................................................................Entity-Relationship-Modell

ERR ......................................................................................................... Einzelraumregelung

GA ............................................................................................................Gebäudeautomation

GAM ................................................................................. Gebäudeautomations-Management

GA-System .................................................................................. Gebäudeautomationssystem

HLK .................................................................................................... Heizung/ Lüftung/ Klima

HOAI .............................................................. Honorarordnung für Architekten und Ingenieure

ID ............................................................................................................................... Identifier

LR ...................................................................................................................... Lichtregelung

MSR ............................................................................. Mess-, Steuer- und Regelungstechnik

OPC .......................................................................................Open Platform Communications

OWL ................................................................................................. Web Ontology Language

PLC ......................................................................................... Programmable Logic Controller

RA ................................................................................................................. Raumautomation

RAMS .................................................................Reliability, Availability, Maintainability, Safety

SCUBA .................................... Self-organising, Cooperative, and robUst Building Automation

SIEMoD .............................................. Semantic Interoperability Evaluation Model for Devices

SOA ........................................................................................... Serviceorientierte Architektur

SoS ................................................................................................... Sonnenschutzsteuerung

SPS ............................................................................... Speicherprogrammierbare Steuerung

XII

TGA .......................................................................................Technische Gebäudeausrüstung

TLT .......................................................................................................... Top-Level-Topologie

TOPAs .................................................... Tools for cOntinuous building Performance Auditing

XML ............................................................................................ Extensible Markup Language

XIII

Abbildungsverzeichnis

Abbildung 1: Schematische Darstellung eines GA-Systems nach [VDI-RICHTLINIE 3814-1

ENTWURF]......................................................................................................6

Abbildung 2: Einordnung der GA in die Automatisierungspyramide ........................................7

Abbildung 3: Anwendungsfunktionen der Beleuchtung ...........................................................9

Abbildung 4: Funktionsverknüpfungen aus [VDI-RICHTLINIE 3813-2] .................................10

Abbildung 5: Beispiel 6-Funktionen-Raum nach [GDS+16B] ................................................11

Abbildung 6: Lebenszyklusphasen eines Gebäudes nach [HEG16].......................................12

Abbildung 7: Kosten im Lebenszyklus nach [IG 16@] ............................................................13

Abbildung 8: Zusammenhang Gebäude und GA-System .....................................................13

Abbildung 9: Der konventionelle Bauprozess aus [BEKN16, S. 8] .........................................23

Abbildung 10: Übersicht des Anforderungsportfolios der GA ................................................26

Abbildung 11: Optimierter Bauprozess aus [BEKN16, S. 10] .................................................29

Abbildung 12: Der Engineeringansatz für die GA ..................................................................47

Abbildung 13: Schalenmodell der [VDI-RICHTLINIE 3813-1]................................................50

Abbildung 14: Vereinfachte Darstellung der Ortsstruktur ......................................................51

Abbildung 15: Vollständige Ortsstruktur ................................................................................52

Abbildung 16: Ober- und Untergeschoss des Beispielgebäudes ..........................................54

Abbildung 17: Struktursegmentierung des Beispielgebäudes ...............................................55

Abbildung 18: IfcProjekt und seine Verweise ........................................................................59

Abbildung 19: IfcSite, IfcBuilding und IfcBuildingstorey .........................................................59

Abbildung 20: IfcSpace des Untergeschosses ......................................................................60

Abbildung 21: IfcSpace des Obergeschosses ......................................................................60

Abbildung 22: Hierarchische Struktur der Gebäudeentitäten einer IFC-Datei .......................60

Abbildung 23: Vergleich IFC-Strukturmodell und Schalenmodell ..........................................61

Abbildung 24: Der Zusammenhang über IfcRelAggregates ..................................................62

Abbildung 25: Gebäudestruktur des Beispielgebäudes aus der zugehörigen IFC-Datei .......63

Abbildung 26: Erstellung eines Modells des GA-Systems .....................................................65

Abbildung 27: Das Engineeringmodell der GA als ERM .......................................................66

Abbildung 28: Grafische Abbildung einer Funktion in AutomationML ....................................68

Abbildung 29: Template eines Büroraumes ..........................................................................69

Abbildung 30: Schematischer Aufbau der AutomationML-Datei ............................................70

Abbildung 31: Bedienoberfläche des erstellten Werkzeuges ................................................71

Abbildung 32: Verbindung von zwei Funktionen ...................................................................72

XIV

Abbildung 33: Teilautomatisierter Prozess der GA-Planung .................................................72

Abbildung 34: XML-Ansicht der Ortsstruktur in der AutomationML-Datei ..............................74

Abbildung 35: Verbindungen der Funktionsstruktur und der Produktstruktur ........................75

Abbildung 36: InstanceHierarchy (links) und InternalLinks (rechts) mit den Verbindungen der

Funktions- und Produktstruktur ....................................................................76

Abbildung 37: Beispiel für die Teilmodellerstellung ...............................................................83

Abbildung 38: Teilmodell Gebäude ohne enthaltene Ortselemente ......................................85

Abbildung 39: InstanceHierarchy des Beispiels ....................................................................85

Abbildung 40: Zwei Varianten für das Teilmodell Bereich (oben ohne enthaltene Ortselemente

und unten mit enthaltenden Ortselementen) ................................................86

Abbildung 41: Zwei Varianten für das Teilmodell Raum (oben ohne enthaltene Ortselemente

und unten mit enthaltenden Ortselementen) ................................................88

Abbildung 42: Teilmodell eines Segments ............................................................................89

Abbildung 43: Funktionale Teilmodellerstellung (oben gesamter Funktionsstrang; unten

Betrachtung einer einzelnen Funktion) ........................................................90

Abbildung 44: Produktbasierte Teilmodellerstellung .............................................................92

Abbildung 45: Darstellung der ERM Beziehungen zwischen den Datensätzen .....................94

Abbildung 46: Auszug Textdatei (links) und Access-Tabelle (rechts) ....................................96

Abbildung 47: Auszug aus der Access-Tabelle der Funktionen ............................................96

Abbildung 48: Abfrage in Access nach Funktionszusammenhängen ....................................97

Abbildung 49: Sortierung nach Gewerken und Nachfolgefunktion ........................................97

Abbildung 50: Struktursegmentierung des Hallen-Büro-Komplexes ......................................99

Abbildung 51: Ortsstruktur des Hallen-Büro-Komplexes in AutomationML .......................... 100

Abbildung 52: Ausschnitt aus dem GA-System-Modell des Hallen-Büro-Komplexes .......... 101

Abbildung 53: Funktionsliste der Halle Tributech ................................................................ 102

XV

Tabellenverzeichnis

Tabelle 1: Kostengruppen der RA und deren übergeordnete Kostengruppe ...........................8

Tabelle 2: Übersicht über verschiedene GA-Systeme...........................................................16

Tabelle 3: Übersicht der bestehenden Engineeringansätze ..................................................44

Tabelle 4: CAD-Software für Architekten ..............................................................................56

Tabelle 5: Aufsplittung der Zeilen einer IFC-Datei ................................................................73

Tabelle 6: Abstrakte XML-Ansicht der InstanceHierarchy der AutomamationML-Datei .........74

Tabelle 7: Erfüllung der gestellten Anforderungen durch den vorgestellten Ansatz ............. 109

XVI

1

1 Einleitung

1.1 Motivation und Problemstellung

In der heutigen Zeit werden der Bau von neuen Gebäuden und die Sanierung alter Gebäude

stets komplexer und unübersichtlicher. Nutzer, Bauherren und Investoren haben immer

vielfältigere Ansprüche, bei denen es schon lange nicht mehr nur auf rein architektonische und

gestalterische Gesichtspunkte ankommt, sondern auch technische, organisatorische,

ökonomische, ökologische und soziale Aspekte in einem Bauprojekt vereint werden müssen.

Nutzer erwarten durch ihren alltäglichen Kontakt mit neuester Technik, wie in Smartphones,

Tablets, Autos und sogar Zahnbürsten, dass auch in Gebäuden teils komplexe

Funktionalitäten zur Verfügung stehen. "Gebäude passen sich dem Wertewandel der

Gesellschaft an" [KRA13, S. 5]. Der Nutzer soll durch Gebäudefunktionalitäten in seinem

Handeln unterstützt und sein Wohlbehagen gesteigert werden. Dabei sind die

Nutzerakzeptanz und das Komfortgefühl wichtig, um eine optimale (Arbeits-) Umgebung zu

schaffen. Dieses auch „produktive Wohlbefinden“ kann für den jeweiligen Investor höhere

Mieteinnahmen bei Wohngebäuden oder eine höhere Leistungsbereitschaft bei Mitarbeitern

erbringen, vgl. [BAL12].

Neben diesem funktionalen Aspekt soll ein Gebäude auch aus ökologischer und ökonomischer

Sicht effizient sein. Vor allem bei den Bauherren und Investoren ist der Aspekt der

Energieeffizienz von großem Interesse. Bei ständig steigenden Rohstoffpreisen und damit

auch Betriebskosten sollen die Kosten eines Gebäudes nicht nur beim Bau, sondern auch im

Betrieb so gering wie möglich gehalten werden. Bezogen auf den Endenergieverbrauch sind

Gebäude mit ca. 35% Großverbraucher und bieten damit ein großes Einsparpotenzial für

Energie, vgl. [BUN15A, S. 5]. Laut [SEI12] bietet die Beleuchtung mit bis zu 58% das größte

Energie-Einsparpotenzial, gefolgt von der Lüftung (zwischen 20% und 45%) und dem

Sonnenschutz (zwischen 9% und 32%).

Der Erwartungshaltung bezüglich funktionaler Unterstützung und Komfort als auch

Energieeinsparungen kann durch den richtigen Einsatz von Gebäudeautomation (GA)

entsprochen werden. Dabei führt „eine sinnvoll geplante und installierte Gebäudeautomation

zur Senkung von Betriebskosten (Personal, Energie, Wartung, Instandhaltung etc.), optimiert

den Nutzen (Komfort, Wohlbefinden, Produktivität, Sicherheit etc.) und steigert die

Wertschöpfung durch z. B. bessere Vermietbarkeit oder höhere Wiederverkaufserlöse“ [VDI-

RICHTLINIE 3813-1]. Die GA ist die Schnittstelle zwischen dem Gebäudemanagement, der

Anlagentechnik und dem Nutzer, vgl. [SEI12]. Die GA umfasst dabei alle Aufgaben und

Funktionalitäten einer gewerkeübergreifenden Automation, wie beispielsweise Heizen,

Kühlen, Verschatten oder Beleuchtung. Diese Aufgaben werden durch einzelne Funktionen,

wie Sensor-, Aktor- oder Steuerungsfunktionen, wahrgenommen und sind über ein großes

Netzwerk zu einem Gebäudeautomationssystem (GA-System) miteinander verbunden. Durch

die Forderungen nach immer vielfältigeren Aufgaben und umfangreicheren,

systemübergreifenden Funktionen entsteht eine hohe Komplexität, denn "die

Gebäudeautomation vernetzt in der heutigen Zeit alle in einem Gebäude vorhandenen

technischen Systeme und optimiert das Zusammenspiel im Hinblick auf die Energieeffizienz"

[BAL12, S. 4].

2

1 Einleitung

Die gesamte Baubranche ist mit einem Gesamtumsatz von ca. 230 Mrd. Euro im Jahr 2015

eine der stärksten Branchen in Deutschland und sie hat ein Wachstum von 2% gegenüber

dem Vorjahr erreichen können [BUN15B@]. Der Markt für GA umfasst neben bereits

bestehenden Gebäuden vor allem Neubauten und Sanierungen. Der Gebäudebestand in

Deutschland beträgt ca. 18 Mio. Wohngebäude und 1,5 Mio. Nichtwohngebäude, vgl.

[BUN14@]. Im Jahr 2015 wurden laut Statistischem Bundesamt [STA16] weitere 195.400

Gebäude gefertigt oder saniert, wovon die Menge an Nichtwohngebäuden über 25.000

Gebäuden umfasst und ca. 1.680 davon auf Büro- und Verwaltungsgebäude entfallen. Weitere

große Baumaßnahmen in Deutschland beliefen sich 2015 auf 92 Krankenhäuser, 202 Schulen

und 318 Gebäude für Bildung, Wissenschaft und Forschung. Der vorhandene Markt für GA-

Systeme ist demnach sehr groß und vielfältig, wie die unterschiedlichsten Bauvorhaben

gerade größerer Gebäude zeigen. Denn je größer ein Gebäude ist, desto mehr

Einsparpotenzial ergibt sich dafür.

Dabei ist die Komplexität gerade von großen Gebäuden eine besondere Herausforderung für

die Realisierung eines GA-Systems, da die umfangreichen und vielfältigen Funktionen

miteinander zu einem GA-System verbunden, aufeinander abgestimmt und für das

Gesamtsystem optimal ausgelegt werden müssen. Hinzu kommt, dass sich die große

Bandbreite an Funktionsmöglichkeiten nicht mehr in die einzelnen Gewerke der Technischen

Gebäudeausrüstung (TGA) trennen lässt. In der Praxis planen und installieren die Gewerke

zurzeit einzeln und unabhängig voneinander, „z.B. ein Automationssystem für die

Beleuchtungsregelung/ -steuerung, eines für die Sonnenschutzregelung/ -steuerung und eines

für die Temperaturregelung/-steuerung“ [HEI14, S. 23]. Dabei planen und installieren die

Gewerke der Kostengruppe 440 „Starkstromanlagen“ nach [HEI14] häufig die Automation des

Sonnenschutzes und der Beleuchtung mit, während die Gewerke der Kostengruppe 420

„Wärmeversorgunganlagen“ die Temperaturregelung planen und installieren (Kostengruppen

gemäß DIN 276-1). Die Automationssysteme der Beleuchtung, des Sonnenschutzes und der

Temperatur können sich aber auch gegenseitig beeinflußen, wenn beispielsweise das System

für den Sonnenschutz die Blendung im Raum reduziert und die Temperaturregelung durch

Anschalten der Heizung nachsteuern muss, um die durch den Lichteinfall erzeugte Wärme zu

ersetzen, bzw. die Beleuchtungsregelung das Licht anschalten muss, um die optimale

Ausleuchtung des Arbeitsplatzes zu halten. Bei getrennter Planung und Installation sind die

möglichen Folgen schwerwiegende Planungsfehler, wie beispielsweise fehlende

Verbindungen zwischen Funktionen (beispielsweise fehlt der Sonnenschutzregelung der

Zugriff auf die Daten der Temperaturregelung) oder mehrfache Auslegungen von Funktionen

(beispielsweise wenn sowohl für die Sonnenschutz-, wie auch für die Temperaturregelung

jeweils eigene Temperatursensoren in einem Raum installiert werden). Diese Planungsfehler

führen zu teuren Nachbesserungen und Umplanungen oder Einschränkungen in der

Funktionalität oder der Effizienz eines GA-Systems. Weitere Mängel treten bei der inkorrekten

und zu schnellen Inbetriebnahme und ungenügenden Überprüfung der Systeme auf, vgl.

[WUK+14@]. Laut einer aktuellen Studie der RWTH Aachen unter Herstellern, Planern,

Errichtern und Nutzern sehen die Befragten die Ursachen für die Mängel von GA-Systemen

zu 40% im Planungs- und Realisierungsprozess in Form von Planungsfehlern im Entwurf oder

mangelnder Kommunikation zwischen den Beteiligten. Ausdrücklich wurde dabei auf fehlende

Kenntnisse der Fachplaner hingewiesen. Weitere ca. 30% beurteilen Ausführungsfehler als

hauptursächlich für die Mängel. Diese Ausführungsfehler sind auf unzureichende oder

fehlerhafte Inbetriebnahmen oder Einregulierungen bzw. Parametrierungen zurückzuführen,

vgl. [FSM17@]

3

1.2 Aufbau der Arbeit

Um diesen Herausforderungen in der Planung zu begegnen, wird eine Methode benötigt, die

als Ziel ein optimal funktionierendes, kostengünstiges und energieeffizientes GA-System hat.

Die Grundlagen dieser Methode müssen zum einen die äußeren, durch den Bauprozess

bestimmten Rahmenbedingungen und zum anderen die vielfältigen Zusammenhänge und

Verknüpfungen innerhalb des GA-Systems berücksichtigen.

Eine Methode stellt dabei das durchgängige und modellbasierte Engineering dar, dass das

gesamte GA-System mit seinen Informationen über die Funktions-, Produktstrukturen und die

zugehörigen Infrastrukturdaten in einem übergreifenden Modell abbildet. Dazu müssen die

Infrastrukturdaten in einem ersten Schritt in eine Ortsstruktur gebracht, mit den GA-Funktionen

verbunden und damit zu einem Engineering-Modell des GA-Systems vereint werden. Durch

Hinzufügen der Produktstruktur als dritte Topologie, welche nach der gewerkegetrennten

Feinausplanung ergänzt wird, wird aus dem Engineering-Modell das GA-System-Modell. Da

die Ausführung im heutigen Bauprozess auch nach wie vor in den Gewerken getrennt erfolgt,

muss es möglich sein, Teilmodelle aus dem Gesamtmodell zu erzeugen, um beispielsweise

Funktionslisten für die einzelnen Gewerke zu erstellen. Des Weiteren kann die

Teilmodellerstellung zur Betrachtung fokussierter Bereiche des GA-Systems verwendet

werden, beispielsweise im Rahmen der Fehlersuche im laufenden Betrieb. Weiter kann das

GA-System-Modell dann, ähnlich wie bei einer „Virtuellen Inbetriebnahme“ [VDI/VDE-

RICHTLINIE 3693-1], in einer Simulation auf Planungs- und Auslegungsfehler untersucht und

entsprechend nachgebessert werden. Nach einer erfolgreichen Planung und Simulation kann

eine automatische Parametrierung die Realisierung des GA-Systems unterstützen. Durch

dieses durchgängige und modellbasierte Engineering, welches die GA in einem

Gesamtsystem betrachtet, sind von der Planung über die Installation bis zum Betrieb Zeit und

Kosten einzusparen und die genannten Fehlerquellen zu vermeiden.

1.2 Aufbau der Arbeit

Im Kapitel 2 werden die Grundlagen zur GA vorgestellt. Darunter fallen die Begriffsdefinitionen

und die Beschreibung der funktionalen Zusammenhänge. Darauf aufbauend wird der

Zusammenhang zwischen der GA und dem Bauwesen erläutert.

Im Kapitel 3 wird zunächst eine Marktanalyse der GA-Systeme durchgeführt und eine

Systemeingrenzung für diese Arbeit getroffen. Weiterhin werden die Anforderungen an ein

GA-System aufgezeigt und im Rahmen eines Anforderungsportfolios zusammengestellt.

Anschließend werden die aktuellen Forschungsarbeiten in jedem Bereich des Portfolios

betrachtet und relevante Aspekte das Engineering von GA-Systemen betreffend

herausgearbeitet. Gemeinsam mit den allgemeinen Anforderungen an das Engineering von

GA-Systemen aus bestehenden Normen wird daraus der Anforderungskatalog an das

Enginnering von GA-Systemen zusammengefasst.

Im Kapitel 4 werden bestehende Engineering-Ansätze vorgestellt und in Hinblick auf den

Anforderungskatalog bewertet und verglichen. Aus dem daraus abgeleiteten bestehenden

Handlungsbedarf wird die Methode zum modellbasierten Engineering der Gebäudeautomation

entwickelt.

Zu Beginn des Engineeringprozesses bestehen die Anfangsinformationen über das

auszurüstende Gebäude in Form von Infrastrukturdaten. Diese werden in Kapitel 5 für den

modellbasierten Engineeringansatz im Rahmen der Infrastruktursegmentierung zu einer

Ortsstruktur vorbereitet und in den Engineeringansatz integriert.

4

1 Einleitung

Um die Anforderungserhebung im Planungsprozess des GA-Systems zu unterstützen, wurde

ein Engineering-Werkzeug entwickelt, das in Kapitel 6 vorgestellt wird. Dieses Tool verknüpft

die GA-Funktionen mit der zuvor hergestellten Ortsstruktur und erstellt daraus teil-

automatisiert ein Engineering-Modell. Durch Hinzufügen der Herstellerinformationen, in Form

der Produktstruktur, wird das Engineering-Modell zu einem GA-System-Modell. Weiterhin wird

in Kapitel 6 die Vorgehensweise zur Überprüfung des Modells durch Simulation und der

automatischen Parametrierung anhand des durch die Firma IQST hergestellten „Pi-Tool“ zur

Simulation und dem GA-System „SmallCAN“ kurz vorgestellt.

In Kapitel 7 wird ein Ansatz zur Erstellung von Teilmodellen aus dem vorgestellten GA-

System-Modell vorgestellt. Diese Methode zeigt auf, wie Teilmodelle aus einem GA-System-

Modell erstellt werden können, indem basierend auf der Orts-, Funktions- und Produktstruktur

Teilmodellschnitte erstellt werden. Diese Teilmodelle können zur Erstellung von

gewerkespezifischen Funktionslisten dienen, die im Rahmen der Ausschreibung und auch der

Installation verwendet werden können, um Schnittstellen zu anderen Funktionen bzw.

Gewerken aufzuzeigen.

In Kapitel 8 wird die Evaluierung des Ansatzes beschrieben. Dazu wurde zum einen eine reale

Struktursegmentierung, Anforderungserhebung und Teilmodellerstellung für ein neues

Bauprojekt, in dem ein GA-System ausgeplant wurde, durchgeführt. Zusätzlich wurden

Experten aus den Branchen Architekturplanung, Bauherren und GA zur Validierung des

Ansatzes befragt und das Ergebnis zusammenfassend vorgestellt. Im Rahmen der kritischen

Auseinandersetzung wird der vorgestellte Ansatz dem in Kapitel 3 aufgestellten

Anforderungskatalog gegenübergestellt und die formulierten Einschränkungen der

vorgestellten Methode werden in Hinblick auf die Praxis untersucht und bewertet.

Den Abschluss der Arbeit stellt die zusammenfassende Darstellung des Ansatzes des

durchgängigen und modellbasierten Engineerings dar. Zudem wird ein Ausblick für

Anknüpfungspunkte zukünftiger Forschungsvorhaben gegeben.

5

2.1 Begriffsbestimmungen in der Gebäudeautomation

2 Grundlagen eines Gebäudeautomationssystems

Im Folgenden werden die Begrifflichkeiten der GA und deren Abhängigkeiten definiert. Auf

dieser Basis werden die Funktionen und die Funktionsstrukturen innerhalb eines GA-Systems

näher beschrieben und anhand eines Beispiels erläutert. In Abschnitt 2.3 wird anhand des

Lebenslaufzyklus des GA-Systems der Zusammenhang zum Bauwesen aufgezeigt.

2.1 Begriffsbestimmungen in der Gebäudeautomation

Die Gebäudeautomation ist aus der zunehmenden Automatisierung in der TGA entstanden

und hatte bereits 1975 in der ersten Version der VDI 3814 eine Regel für die Technik der GA.

Diese wurde in den Folgejahren zur Richtlinienreihe VDI 3814 erweitert und ist vorrangig im

deutschsprachigen Raum etabliert. In der Richtlinienreihe VDI 3814 sind die allgemeinen

Grundlagen, Hilfsmittel und Hinweise für die GA beschrieben und enthalten u.a. die

Systemgrundlagen (Blatt 1), Gesetze, Verordnungen und technische Regeln (Blatt 2) und

Hinweise für das Betreiben (Blatt 3).

Gemäß [VDI-RICHTLINIE 3814-1] wird GA definiert als: „Bezeichnung der Einrichtungen,

Software und Dienstleistungen für automatische Steuerung und Regelung, Überwachung und

Optimierung sowie für Bedienung und Management zum energieeffizienten, wirtschaftlichen

und sicheren Betrieb der Technischen Gebäudeausrüstung“. Ein GA-System ist demnach ein

System aus allen Produkten und Dienstleistungen der GA und stellt damit die technische

Realisierung der GA dar. Es besteht aus „Feldgeräten, Automationseinrichtungen,

Schaltgerätekombinationen, Verkabelung, Netzwerk-, Kommunikations- und

Recheneinrichtungen und Systemsoftware“. Darüber hinaus wird der Begriff GA sowohl für

das Gewerk wie auch als Bezeichnung für die Branche verwendet.

Das Gewerk der GA besteht seit 1993 offiziell durch die Aufnahme der Kostengruppe 480 in

die Baukostennorm DIN 276. Im Jahr 2002 wurde die GA in dieser Konsequenz auch dem

Standardleistungsbuch für das Bauwesen, das dem Beschreiben von Bauleistungen dient, als

Leistungsbereich 070 hinzugefügt [BUN02]. 2004 erschien dann die erste weltweit geltende

Norm für die GA: ISO 16484, die auf den wesentlichen Elementen der Richtlinienreihe VDI

3814 beruht. Die ISO 16484 enthält ebenfalls Systemgrundlagen und darüber hinaus

projektspezifische Anforderungen an die Errichtung einer GA-Anlage, die die Hersteller,

Systemintegratoren, Elektroinstallateure oder HLK-(Heizung-/Lüftung-/Klima)

Anlagenerrichter unterstützen sollen, vgl. [DIN EN ISO 16484-1]. Die generische

Beschreibung des Planungs- und Ausführungsprozesses wird im weiteren Verlauf dieser

Arbeit als Teil des Anforderungskataloges beschrieben.

Die TGA bezeichnet alle „im Gebäude installierten und verteilten Infrastruktureinrichtungen,

z. B. für Elektrizität, Gas, Heizung, Wasser und Kommunikation“ [BAL12, S. 12;

DIN EN ISO 16484-2]. Für den deutschen Sprachgebrauch wird diese Definition noch weiter

spezifiziert und bezeichnet alle im Bauwerk eingebauten und damit fest verbundenen

technischen Einrichtungen und nutzungsspezifischen Einrichtungen, die weiter in der

[DIN 276-1] spezifiziert sind.

In der GA-Branche verwenden Hersteller häufig den Begriff GA, auch wenn das System keinen

oder nur einen sehr bedingten Einfluss auf die TGA hat und damit eher der Raumautomation,

als einem Teil der GA, zuzuordnen ist. Dies führt in der Praxis häufig zu einer ungenauen

6


Verwendung des Begriffs GA. Im Entwurf der neuen VDI-Richtlinie 3814 wird seit 2016

aufgrund dieser bisher teils unscharfen Begrifflichkeiten [KRA16] ein neues einheitliches

Begriffsmodell eingeführt, siehe Abbildung 1. In diesem Entwurf wird unterschieden zwischen

dem GA-System als Bezeichnung für das Gesamtsystem und den Bestandteilen des Systems,

vgl. [VDI-RICHTLINIE 3814-1 ENTWURF]:

Gebäudeautomations-Management (GAM), Raumautomation (RA) und Anlagenautomation

(AA).

Abbildung 1: Schematische Darstellung eines GA-Systems nach [VDI-RICHTLINIE 3814-1

ENTWURF]

Das GAM umfasst alle Funktionen zum Überwachen, Bedienen und Beobachten des

gesamten GA-Systems und dient damit als Kontrollinstrument und Hauptschaltzentrale eines

Gebäudes. Das GAM ist der Kostengruppe 483 der DIN 276 zugeordnet, siehe [DIN 276-1].

Die RA umfasst alle Sensor-/ Aktor- und Anwendungsfunktionen aus dem Funktionsbereich

der Beleuchtungstechnik, der Sonnenschutztechnik und der Raumklimatechnik und ist unter

der Kostengruppe 484 zusammengefasst. Die RA-Funktionen sind Bestandteil des GA-

System-Netzwerks, über das seine Funktionalitäten miteinander verbunden sind. Im

Gegenzug dazu beschreibt die AA alle Eingangs-/ Ausgangs- und Anwendungsfunktionen der

zentralen Heizungstechnik, Kältetechnik und der Lüftungs- und Klimatechnik, wie sie in

Technikzentralen in Gebäuden installiert werden“ [VDI-RICHTLINIE 3814-1 ENTWURF, S. 6].

Die AA hat keine eigene Kostengruppe, und erstreckt sich daher über die weiteren

Kostengruppen der übergeordneten Kostengruppe 480. Sowohl in der RA wie auch in der AA

sind für die jeweiligen Bereiche auch Service-, Diagnose, Bedien- und Anzeigefunktionen

eingefasst, um das jeweilige Teilsystem für Nutzer individuell bedienbar zu machen.

So wie in der Prozessautomatisierung üblich, kann auch die GA in der

Automatisierungspyramide eingeordnet werden, vgl. [MPM17@]. Die GA besteht gemäß

[DIN EN ISO 16484-1] aus drei Ebenen: Management- oder Leitebene, Automations- oder

Steuerungsebene und Feldebene, siehe Abbildung 2. Die im Rahmen der

Prozessautomatisierung weitergehenden Ebenen Betriebs- und Unternehmensebene werden

für die GA nicht berücksichtigt, da die Leitebene als oberste Ebene mit der Schnittstelle zum

Nutzer ausreichend ist.

In der Leitebene sind über das GA-Managementnetzwerk alle Bedienstationen,

Beobachtungseinheiten und weitere Überwachungseinheiten miteinander verbunden. Diese

Ebene befasst sich auch mit der Visualisierung des Gebäudes und wird im Facility-

Management umgesetzt.

7

2.2 Raumautomationsfunktionen

Abbildung 2: Einordnung der GA in die Automatisierungspyramide

Die Steuerungsebene befasst sich mit den Komponenten, die zur Steuerung, Regelung und

zum Aufbau einer Logik benötigt werden. Diese sind über das Automatisierungsnetzwerk

miteinander verbunden und treffen Entscheidungen, die an die Feldebene weitergegeben

werden müssen. In der Feldebene befinden sich alle Sensoren und Aktoren, die über das

Feldnetzwerk miteinander kommunizieren können. Die Sensoren erfassen physikalische

Größen oder Zustände und können diese der Steuerungsebene zur Verarbeitung übertragen.

Die Aktoren führen Stellbewegungen aus und bekommen ihre Signale über das Feldnetzwerk

von höheren Ebenen oder auch durch lokale Systemkomponenten (Beispiel:

Beleuchtungssteuerung schalten), vgl. [ASC14].

Im Rahmen dieser Arbeit wird die RA als Teil der GA behandelt. Gemeint ist

damit die funktionale Umsetzung der GA in den einzelnen Räumen. Diese werden in den RA-

Funktionen beschrieben, die in ihrer allgemeinen Form in der [VDI-RICHTLINIE 3813-1; VDI-

RICHTLINIE 3813-2] definiert sind. Da der Begriff des „Raumautomations-Systems“ derzeit

nicht in den Richtlinien und Normen definiert ist, wird zur Bezeichnung des Systems aus

Funktionen der RA weiterhin der Begriff GA-System verwendet. Dieser wird jedoch in seiner

Begriffsdefinition für diese Arbeit auf die RA eingeschränkt.

2.2 Raumautomationsfunktionen

Die Umsetzung eines GA-Systems auf der Ebene der RA wird über RA-Funktionen

sichergestellt. Eine Funktion ist definiert als „spezifische Wirkung eines Programms oder einer

Schaltung, nach der Eingangs- und Ausgangsgrößen entsprechend einer vorgegebenen

Aufgabenstellung miteinander verknüpft werden“ [VDI-RICHTLINIE 3814-1].

Die Richtlinienreihe VDI 3813 ist auf die RA fokussiert. Sie behandelt Grundlagen,

Begrifflichkeiten und definiert RA-Funktionen technologieunabhängig und als

herstellerneutrale Anforderung an eine technische Lösung. Auf der Basis dieser

Funktionsbeschreibungen können Funktionen zu RA-Schemata zusammengefügt werden und

bilden damit eine wichtige Grundlage für die Planung von GA-Systemen. Die RA betrifft

8


vorallem die Gewerke, welche durch die Kostengruppen und deren übergeordnete

Kostengruppen gemäß [DIN 276-1] in der Tabelle 1 aufgelistet sind.

Kostengruppe Nummer

Kostengruppe

Übergeordnete

Kostengruppe

Nummer

übergeordnete

Kostengruppe

Sonnenschutz 338 Außenwände 330

Innentüren und Fenster 344 Innenwände 340

Raumheizflächen 423 Wärmeversorgungsanlagen 420

Klimaanlagen 433 Lufttechnische Anlagen 430

Beleuchtungsanlagen 445 Starkstromanlagen 440

Raumautomationssysteme 484 Gebäudeautomation 480

Tabelle 1: Kostengruppen der RA und deren übergeordnete Kostengruppe

Die RA-Funktionen werden in der [VDI-RICHTLINIE 3813-1] als „standardisierte kleinste

Programmeinheit für die RA“ spezifiziert und sind durch interne Zustandsgrößen, Eingänge

und Ausgänge gekennzeichnet.

Im Folgenden werden der Aufbau der Gruppierung der RA-Funktionen und deren Verbindung

zu logischen Funktionsstrukturen beschrieben.

2.3 Gruppierung und Aufbau der Funktionen

Die RA-Funktionen eines GA-Systems sind in der [VDI-RICHTLINIE 3813-2] unterteilt in

Sensor-, Aktor, Kommunikations-, Bedien- und Anwendungsfunktionen, die in Anlage A dieser

Arbeit aufgeführt sind. Sensorfunktionen messen physikalische Größen und wandeln sie in

elektrische Signale, wie z. B. Temperatursensor oder Präsenzdetektor. Die Aktorfunktionen

wandeln die elektrischen Eingabeinformationen, die sie über Anwendungsfunktionen oder

Bedienfunktionen erhalten, in physikalische Größen, wie z. B eine mechanische Bewegung,

um. Die Kommunikationsfunktionen dienen dem Signalaustausch zwischen Funktionen. Um

dem Nutzer Zugriffsmöglichkeiten auf das GA-System zu geben, sind Bedien- und

Anzeigefunktionen notwendig. Diese bilden die physikalische Schnittstelle zum Benutzer, wie

beispielsweise ein Thermostat. Die Anwendungsfunktionen bilden das Herz eines GA-

Systems, da sie die eigentlichen Steuer- und Regelfunktionen enthalten. Als Eingangswerte

dieser Funktionen dienen in der Regel Werte von Sensorfunktionen oder Bedienfunktionen.

Nach erfolgter Regelung in Abhängigkeit von der jeweiligen Einstellung werden Stellwerte als

Ausgangsgröße an Aktorfunktionen gesendet. Die jeweiligen Aus- und Eingangssignale

müssen bei der Funktionsverbindung kompatibel sein.

9


Abbildung 3: Anwendungsfunktionen der Beleuchtung

Innerhalb der Anwendungsfunktionen bauen die Funktionen teilweise aufeinander auf, wobei

die Funktionen jeweils um gewisse Funktionalitäten erweitert sind. Am Beispiel der

Beleuchtungsfunktionen lässt sich dieses in der Abbildung 3 verdeutlichen. Das Automatiklicht

schaltet das Licht an, wenn eine Anwesenheit über einen Präsenzdetektor ermittelt oder ein

Taster betätigt wird. Die Tageslichtautomatik ist um einen Helligkeitssensor erweitert und

schaltet das Licht zusätzlich in Abhängigkeit von der Helligkeit innerhalb des Raumes. Die

Konstantlichtregelung ist die Erweiterung der Tageslichtautomatik um eine Dimmfunktion und

die Dämmerungsschaltung wiederum schaltet in Abhängigkeit von der Außenhelligkeit.

Dieser schematische Aufbau der Anwendungsfunktionen macht deutlich, dass die mehrfache

Auswahl dieser Funktionen innerhalb einer Regelstrecke nicht sinnvoll ist, sondern lediglich

eine Funktion ausreicht, um die jeweils gewünschten Funktionalitäten bereitzustellen. Bei

Verwendung von mehrfachen Anwendungsfunktionen innerhalb einer kurzen Steuer- und

Regelstrecke (z. B. innerhalb eines Raumes) ist andernfalls eine Prioritätensteuerung

zwischen den Anwendungsfunktionen notwendig.

2.3.1 Die Funktionsstruktur

Um ein GA-System zu erstellen, müssen mehrere Funktionen zu einer logischen Verbindung

miteinander verknüpft werden. Dafür sind alle Funktionen als Funktionsblöcke mit Eingängen,

Ausgängen, Parametern und der jeweiligen Schaltfunktion in der [VDI-RICHTLINIE 3813-2]

definiert und können über die jeweils passenden Ein- und Ausgänge miteinander verbunden

werden, siehe Abbildung 4. Die Parameter sind individuelle Einstellmöglichkeiten, wie

beispielsweise Kalibrierungseinstellungen oder Sollwertbegrenzungen, wie die minimale oder

maximale Temperatur.

10


Abbildung 4: Funktionsverknüpfungen aus [VDI-RICHTLINIE 3813-2]

Abbildung 4 ist eine Prinzipdarstellung der Funktionsverknüpfung aus der [VDI-

RICHTLINIE 3813-2]. Eine Funktionsverknüpfung beginnt in der Regel mit einer

Sensorfunktion. Diese nimmt über eine Sensorik Signale und Daten auf und gibt diese Daten

an eine Anwendungsfunktion weiter. Die Anwendungsfunktion verarbeitet alle Input-

Informationen und besteht aus einer Steuer-/Regelfunktion, die z. B. bei Über- oder

Unterschreitung der durch die Parameter eingestellten Werte ein Signal an eine Aktorfunktion

übermittelt. Die Aktorfunktion führt das Signal der Anwendungsfunktion aus. Die Bedien-/

Anzeigefunktion bezeichnet eine Funktion, die durch den Nutzer bedient wird. Dies kann z. B.

die Eingabe eines Sollwertes oder die Betätigung eines Tasters sein, der ebenfalls ein Input-

Signal für die Anwendungsfunktion liefert. Ein Beispiel für eine solche Funktionskette kann

eine einfache Klimaanlage sein. Durch einen Temperatursensor wird die aktuelle Temperatur

ermittelt. Die Häufigkeit der Messung wird durch die Parameter im Sensor gesteuert. In der

Anwendungsfunktion sind Schwellwerte für das Einschalten der Klimaanlage hinterlegt und

sobald ein ankommendes Signal vom Temperatursensor oberhalb/unterhalb des

Schwellenwertes liegt, wird die Klimaanlage durch die Aktorfunktion angesteuert. Sollte der

Nutzer der Klimaanlage bereits ab einer geringeren/höheren als der eingestellten

Schwellenwert-Temperatur die Raumtemperatur ändern wollen, kann er dies über eine

Anzeige- und Bedienfunktion machen. Er übersteuert dann den in der Anwendungsfunktion

eingestellten Schwellenwert und das Signal zur Ansteuerung der Klimaanlage wird an die

Aktorfunktion übertragen.

Um den Aufbau einer Funktionsstruktur zu erklären, wird ein Beispielraum vorgestellt:

6-Funktionen-Büroraum

Als Beispiel wird ein Büroraum mit einem einfachen GA-System bestehend aus sechs

Funktionen beschrieben:

• Präsenzerkennung

• Präsenz melden

• Zeitprogramm

• Fensterüberwachung

• Belegungsauswertung

• Energieauswahl

11


Abbildung 5: Beispiel 6-Funktionen-Raum nach [GDS+16B]

In der Abbildung 5 ist der Beispielraum in einem RA-Schema gemäß [VDI-RICHTLINIE 3813-

2] dargestellt. Dabei ist die Abbildung schematisch zwischen den Anlagen (oben) und den

Funktionen (unten) unterteilt. Die Anlagen bestehen aus einem Taster für die

Präsenzmeldung, einem Präsenzerkennungssensor und einem Sensor zur Feststellung, ob

das Fenster geöffnet oder geschlossen ist (für die Fensterüberwachung). Sowohl der Taster

als auch der Präsenzerkennungssensor führen zu einem Signal an die Belegungsauswertung,

dass aktuell eine Präsenz im Raum erkannt wurde. Die Funktionen Fensterüberwachung und

Belegungsauswertung leiten ihren Output – „Zustand des Fensters offen oder geschlossen“ –

und – „Präsenz im Raum oder nicht“ – an die Funktion Energieauswahl weiter. Zusätzlich

sendet die Funktion Zeitprogramm, die durch ein vorprogrammiertes Zeitprogramm

Anwesenheitszeiten oder Nutzungszeiten definiert hat (z. B. Arbeitsbeginn um 06:00 Uhr,

Arbeitsende um 17:00 Uhr), ein entsprechendes Signal an die Energieauswahl.

Innerhalb dieser Energieauswahl wählt diese Funktion aus vorher festgelegten

Energiemustern das entsprechend den eingehenden Signalen passende aus und steuert die

Heizungen des Raumes an. So kann über die Zeitprogramm-Funktion gesteuert werden, dass

außerhalb der regulären Arbeitszeit die Heizung abgeschaltet bzw. reduziert wird, um die

Räume nicht unnötig zu heizen. Ab 06:00 Uhr geht die Heizung in einen Standby-Modus und

hält die Raumtemperatur bei 18°C. Kommt der Arbeitnehmer um 07:00 Uhr zum Dienst,

braucht die Heizung nicht lange, um bei erkannter Präsenz auf 20°C Arbeitsplatztemperatur

zu heizen. Öffnet der Nutzer das Fenster, senkt sich die Heizung gleichzeitig wieder auf den

Standby-Modus ab und heizt erst nach Schließung des Fensters wieder auf. Wenn der Nutzer

länger als die voreingestellte Zeit von 17:00 Uhr im Büro bleibt, übersteuert der Präsenzmelder

das Zeitprogramm und die Heizung bleibt weiterhin an. Mit diesem einfachen GA-System-

Beispiel werden die Wünsche eines Büroraumnutzers nach einer geeigneten Raumtemperatur

am Arbeitsplatz und den Vorgaben der Gebäudeverantwortlichen nach Energieeinsparung

erfüllt.

12


2.4 Der Lebenszyklus von Gebäudeautomationssystemen

Definitionsgemäß ist ein GA-System eng mit dem dazugehörigen Gebäude verbunden. Bei

einem bereits bestehenden Gebäude ohne ein GA-System muss das GA-System neu geplant

und auf die bestehende Infrastruktur ausgelegt werden. Ist bereits ein GA-System vorhanden

und soll modernisiert werden, muss dieses erweitert oder komplett ausgetauscht werden. Bei

einem Gebäudeneubau kann die Neuplanung des GA-Systems in den Bauplanungsprozess

integriert werden. Für die Planung und Auslegung eines GA-Systems besteht daher die

Notwendigkeit, dass diese Tätigkeiten sowohl auf ein bestehendes Gebäude zutreffen müssen

als sich auch leicht in den Bauprozess eines Gebäudes integrieren lassen sollten. Die

Möglichkeiten der Integration lassen sich am Produktlebenszyklus von Gebäuden und GA-

Systemen zeigen.

Der Lebenszyklus eines Gebäudes ist in vielen verschiedenen Quellen leicht abweichend in

den Bezeichnungen beschrieben, vgl. [PEL06; NEN99] oder auch [IG 16@]. Im „Leitfaden für

Nachhaltiges Bauen“ [HEG16], herausgegeben vom Bundesministerium für Umwelt,

Naturschutz, Bau und Reaktorsicherheit, ist der Lebenszyklus von Gebäuden gemäß

Abbildung 6 vereinfacht durch sechs Phasen dargestellt: Planungsphase, Bauphase,

Nutzungsphase, Modernisierungsphase, Nutzungsphase und Rückbauphase.

Abbildung 6: Lebenszyklusphasen eines Gebäudes nach [HEG16]

In der Planungsphase finden die Konzepterstellung und die gesamte Planung des Gebäudes

statt. Die Bauphase beschreibt die Zeit von der Grundsteinlegung bis zur Inbetriebnahme

eines Gebäudes. Dann erstreckt sich die Nutzungsphase so lange, bis eine Modernisierung

erforderlich ist. Die Modernisierung enthält gegebenenfalls wieder eine Planungs- und

Bauphase und geht nach erneuter Inbetriebnahme wieder in die Nutzungsphase über. Wenn

ein Gebäude nicht mehr verwendet werden soll, geht es in die Rückbauphase, in der das

Gebäude verwertet bzw. entsorgt wird.

Innerhalb der vorgestellten Lebenszyklusphasen gibt es unterschiedliche Entwicklungen der

Kosten. Wie in der Abbildung 7 dargestellt, entsteht der Großteil der Kosten (bis zu 80-85%

der Gesamtkosten) kontinuierlich in der Phase der Nutzung bis zum Abbruch des Gebäudes,

vgl. [IG 16@]. Die lineare Steigung während der Nutzungsphasen zeigt, dass die

Betriebskosten des Gebäudes über die Nutzungsdauer nahezu gleichbleibend sind. Die

Beeinflussbarkeit der Kosten ist dagegen eine fallende Kurve und macht deutlich, dass vor

allem die Planungsphase entscheidend ist für die Kosten, die über die gesamte

Nutzungsdauer entstehen. Die GA kann einen entscheidenden Beitrag dazu leisten, Kosten

13

2.4 Der Lebenszyklus von Gebäudeautomationssystemen

während der Nutzungsphase einzusparen, vgl. [WID13]. Dies kann jedoch nur gelingen, wenn

das GA-System für das entsprechende Gebäude optimal ausgelegt ist.

Abbildung 7: Kosten im Lebenszyklus nach [IG 16@]

Die Anknüpfungspunkte für die GA sind die jeweiligen Planungsphasen beim Neubau,

nachdem ein Gebäudekonzept durch den Architekten erstellt wurde, und in der

Modernisierungsphase. Die Realisierung eines GA-Systems erstreckt sich über die

Planungsphase, Ausschreibungsphase, Ausführungsphase, Inbetriebnahmephase und die

Abnahme [VDI-RICHTLINIE 3814-1]. Vereinfacht können diese in den Phasen Planung und

Installation zusammengefasst werden. Der Begriff Engineering von GA-Systemen umfasst im

Folgenden die Phasen Planung, Installation und Nutzung eines GA-Systems. Der

Zusammenhang zwischen den Lebenszyklusphasen des Gebäudes und eines GA-Systems

ist in Abbildung 8 dargestellt.

Abbildung 8: Zusammenhang Gebäude und GA-System

Die Planungsphase des GA-Systems kann nur mit zeitlichem Verzug zur Planung eines

Gebäudes beginnen, da zunächst das Gebäudekonzept bestehen muss, um ein GA-System

in das Gebäude einzuplanen. Dazu gehören z. B. die Raumaufteilung und die Anzahl der

Etagen, welche die grundsätzliche Gebäudestruktur bilden. Die Installation ist daher ebenfalls

zeitlich versetzt zum Baubeginn, da zunächst der Rohbau erstellt werden muss, bevor Anlagen

oder Geräte installiert werden können. Im Anschluss an die Geräteinstallation müssen die

Geräte noch parametriert werden, indem die notwendigen Parameter eingestellt und die

Geräte über ein Netzwerk miteinander verbunden werden. Mit der Gebäudeübergabe wird

14


auch das GA-System vollständig und funktionierend übergeben und deshalb finden die

Nutzungsphasen zeitlich synchron statt.

Da der Bauprozess des Gebäudes die Realisierung des GA-Systems umschließt, wirken sich

Herausforderungen aus diesem Bauprozess zusätzlich auf die Anforderungen an das GA-

System aus. Während einer Modernisierungsphase bleibt das Gebäude an sich grundsätzlich

erhalten, daher ist diese Phase bezüglich des GA-Systems weniger aufwendig als die

Planungs- und Bauphase. Deshalb wird in dieser Arbeit von dem aufwändigeren Bauprozess

inklusive der Realisierung der GA ausgegangen.

15

3.1 Marktanalyse vorhandener Gebäudeautomationssysteme

3 Anforderungen an das Engineering von Gebäudeautomations-

systemen

In diesem Kapitel wird zunächst eine Marktanalyse der GA-Systeme durchgeführt, die größten

Hersteller und Systeme auf dem Gebiet der GA werden vorgestellt, und eine

Systemeingrenzung für diese Arbeit wird vorgenommen. Anschließend wird die GA aus vier

verschiedenen Blickwinkeln, der Wirtschaftlichkeit und Funktionalität als Motivation, der

Qualitätssicherung und dem Bauprozess als Rahmenbedingungen, betrachtet, und die

allgemeinen Anforderungen und Herausforderungen an ein GA-System-Engineering werden

beschrieben. Im Weiteren werden in diesen vier Bereichen bereits existierende einzelne

Lösungsansätze betrachtet und daraus die Anforderungen an ein übergreifendes Engineering

für GA-Systeme abgeleitet. Gemeinsam mit dem grundsätzlichen, generischen

Engineeringansatz der [DIN EN ISO 16484-1] als Anhalt werden diese Anforderungen zu

einem Anforderungskatalog an das Engineering der GA zusammengefasst. Mit diesem

Anforderungskatalog werden dann in Kapitel 4 bestehende übergreifende Engineeringansätze

verglichen und der resultierende Handlungsbedarf abgeleitet.


Um die dargestellten Funktionszusammenhänge in einem Gebäude zu ermöglichen, haben

sich verschiedene GA-Systeme am Markt etabliert. Diese unterscheiden sich zum einen durch

ihre Komplexität und ihren Funktionsumfang und zum anderen durch verschiedene

Datenübertragungsmedien, Standardisierung und natürlich die Kosten.

Dieser Abschnitt basiert auf den grundsätzlichen Systembeschreibungen, wie Aschendorf sie

in [ASC14] zusammengestellt hat, und weiteren Informationen über aktuelle GA-Systeme.

Aschendorf unterscheidet die GA-Systeme nach zentralen, dezentralen und Mischformen, den

halbdezentralen Systemen. Systeme wie KNX oder LON gelten als Systeme mit verteilter

Steuerung als vollständig dezentrale Systeme, da der Eindruck erweckt wird, dass keine

zentrale Steuerung notwendig ist. In der Realität kommen aber auch diese dezentralen

Systeme nicht ohne einzelne zentrale Steuerungsfunktionen (Controller,

Verknüpfungsbausteine und Logikmodule) aus.

Demgegenüber stehen die speicherprogrammierbaren Steuerungen (SPS), die zu den

zentralen Systemen zählen, da diese zunächst keine dezentralen Komponenten hatten,

sondern zentral gesteuert wurden. Im Laufe der Zeit sind diese Systeme jedoch

zusammengewachsen und haben sich daher unter den Begriffen halbdezentral oder

halbzentral gesammelt.

Darüber hinaus müssen an dieser Stelle auch Subsysteme und Protokolle betrachtet werden,

da diese mittlerweile einen gewissen Standard gerade in großen GA-Systemen einnehmen.

Diese Systeme stellen jedoch keine eigenständigen GA-Systeme dar, sondern lediglich

Subsysteme, die auf einzelne Bereiche spezialisiert sind.

Einen davon weitgehend unabhängigen Teilbereich der GA-Systeme stellen die sogenannten

Heimsysteme (engl.: Smart Home) dar. Diese stellen Raumfunktionalitäten zur Verfügung, die

über kabellose Netzwerke oder auch das Stromnetz interagieren können und durch Nutzer

einfach selbst zu installieren und zu betreiben sind. Diese stellen jedoch keine eigenständigen

16

3 Anforderungen an das Engineering von Gebäudeautomationssystemen

GA-Systeme im eigentlichen Sinne dar, sondern haben als Ziel die Nachrüstung von

Wohngebäuden mit gewissen RA-Funktionalitäten.

Einen Überblick über verschiedene am Markt übliche GA-Systeme und deren Einordnung gibt

Tabelle 2.

Systemart Anbieter/Produkte Quelle Beschreibung

Zentrale

Systeme

WAGO [WAG18@]

Kommunikation über

Automatisierungsebene/Leitebene,

zentrale Steuerung

Beckhoff [BEC18@]

Siemens [SIE15@]

Dezentrale

Systeme

LON [LON17@]

Kommunikation und Funktionen

innerhalb der Feldebene, Steuerung

über dezentrale Steuergeräte

KNX [KNX16B@]

LCN [ISS17@]

SmallCAN [IQS14B@]

Subsysteme,

Protokolle

DALI [ZEN17@] Insellösungen und Protokolle, welche

die dezentralen und zentralen GA-

Systeme ergänzen können ZigBee [ZIG17@]

Heimsysteme RWE S-H [INN17@] Lifestyle-Produkte

Tabelle 2: Übersicht über verschiedene GA-Systeme

3.1.1 Zentrale Systeme

Unter zentralen Systemen werden laut [ASC14] Systeme verstanden, die eine zentrale

Steuerung und Regelung besitzen. Innerhalb dieser Zentrale werden Signale der Sensoren

anhand der hinterlegten Funktionslogik ausgewertet und dann die entsprechenden

Aktorfunktionen angesprochen. Die Vorteile eines solchen zentralen Systems liegen in der

Mächtigkeit der Zentrale, da diese über alle Informationen des gesamten Systems verfügt und

alle Zustände kennt. Des Weiteren sind die einzelnen Verbindungen zur Zentrale unabhängig

voneinander und der Ausfall einer einzelnen Verbindung führt nur zur Abtrennung der daran

hängenden Funktion. Auf der anderen Seite führt genau diese Mächtigkeit der zentralen

Steuerung und Regelung dazu, dass der Ausfall der Zentrale gleichbedeutend mit einem

totalen Systemausfall ist. Durch redundante Komponenten kann diesem Risiko

entgegengewirkt werden. Die zentralen Systeme sind vor allem in der Industrieautomation

verbreitet, dazu zählen auch die SPS bzw. Programmable Logic Controller (PLC). Zu den

bekanntesten Herstellern der zentralen Systeme gehören WAGO, Beckhoff und Siemens.

Als ein Beispiel wird hier die Firma WAGO vorgestellt. Diese ist ein Anbieter von Industrie- und

Energieautomation und bietet stabile und preiswerte SPS-Lösungen an. Durch die Erweiterung

der Schnittstellen können diese Systeme kostengünstig mit anderen GA-Systemen verbunden

werden. Zentrales Element ist ein programmierbarer Feldbus-Controller, der mehrere

17


Programme nahezu gleichzeitig ausführen kann. Dazu können Steuerungskomponenten über

Mehrdrahtleitungen oder Ethernetleitungen flexibel und raumnah verteilt werden. In der

Zentrale werden sämtliche Eingangssignale der Sensoren zusammengeführt. Die

Ausgangssignale an die Aktoren können entweder direkt an diese ausgegeben oder an die

übergeordnete Steuerung übertragen werden. Zur Anbindung wird das WAGO-

Busklemmensystem verwendet. Dieses besitzt ein offenes System und besteht aus einem

Buskoppler und elektronischen Reihenklemmen. Über diese Busklemmen kann das GA-

System auch mit anderen GA-Systemen verbunden werden. Eigens installiert wurde ein

Anschluss für den KNX-Bus. Der Nachteil des Systems ist die aufwendige Nachrüstung, da

zwingend Leitungsverlegungen notwendig werden, um Schalter, Kontakte oder Verbraucher

anzuschließen. Dieser Nachteil trifft auf alle kabelgebundenen zentralen Systeme zu.

3.1.2 Dezentrale Systeme

Dezentrale Systeme haben im Gegensatz zu zentralen Systemen keine grundsätzliche

Zentrale, über die alle Signale laufen, sondern verfügen über verteilte Steuer- und

Regelungseinheiten. Jeder Teilnehmer des GA-Systems verfügt über einen oder mehrere

Controller, der die Kommunikation mit dem Netzwerk realisiert und die Funktionalität steuert.

Die Vorteile von dezentralen Systemen liegen in der einfachen Nachrüstung der Systeme, da

einzelne Geräte samt Controller lediglich mit dem Bussystem verbunden werden müssen.

Darüber hinaus sind die meisten Geräte bereits vorgefertigt und müssen nur noch parametriert

und konfiguriert werden, d.h., die Funktionalität muss durch die Einstellung entsprechender

Parameter ergänzt und die Funktionslogik bzw. die Verbindung zu anderen

Netzwerkteilnehmern eingegeben werden. Bei Ausfall einzelner Steuer- und

Regelungseinheiten bzw. Controllern ist nicht das gesamte GA-System betroffen wie bei

zentralen Systemen. Ein weiterer Vorteil liegt in der einfachen Änderung von

Zusammenhängen zwischen den Teilnehmern, da diese Informationen über die

Parametrierung und Konfiguration erst geladen werden. Die Nachteile der dezentralen

Systeme liegen in den höheren Anschaffungskosten durch hochwertige Controller inklusive

teils proprietärer Programmierung. Des Weiteren ist bei Ausfall des

Datenübertragungsmediums, beispielsweise durch Beschädigung, gleichzeitig ein Ausfall des

gesamten GA-Systems möglich, sofern keine Redundanzen geschaffen wurden. Zur

Vermeidung von Systemausfällen und auch Problemen in der Programmierung komplizierter

Funktionsabläufe kommen auch bei dezentralen Systemen „zentralisierte“ Controller zum

Einsatz, weshalb es Mischsysteme gibt, die als halbzentral oder halbdezentral bezeichnet

werden. Aktuelle dezentrale GA-Systeme sind beispielsweise KNX/EIB, LON und LCN.

KNX gehört zu den bekanntesten GA-Systemen am Markt und ist mittlerweile als Quasi-

Standard anerkannt. Gegründet wurde KNX von vielen bekannten Firmen, wie GIRA, Merten,

Siemens etc., um einen Standard in den Markt einzuführen. Mittlerweile sind mehr als 120

Hersteller über KNX lizensiert und haben sich diesem Quasi-Standard angeschlossen,

[KNX17@]. Dies garantiert eine große Geräte- und Funktionsauswahl über verschiedene

Hersteller. Nachteilig an dem System ist, dass eine vollständige Austauschbarkeit der

Produkte nicht gewährleistet werden kann, da nur Buskoppler desselben Herstellers, wie das

vorhandene Gerät, in Bauform und Anschluss in das System passen [ASC14]. KNX bietet

verschiedene Datenübertragungsmedien, wie Zweidrahtleitungen, Powerline (Stromnetz),

Ethernet- Netzwerk oder funkbasiert, an. Allerdings werden diese GA-Systeme nur

geschlossen über lizensierte Partner (Systemintegratoren) vertrieben und auch installiert.

Über das KNX-spezifische Softwareprogramm ETS können die Systeme geplant und

18


parametriert werden. Ein Vergleich der Software ETS mit weiteren Planungsprogrammen für

die GA wird im Abschnitt 4.2 vorgestellt.

Ein Nischenprodukt in diesem Segment ist das System „SmallCAN“ der Firma iQST, welches

durch Nutzung eines offenen Standards herstellerunabhängige Geräte verwendet und daher

die Kosten für das GA-System gering halten kann, vgl. [IQS14B@]. Näheres zu diesem GA-

System wird im Rahmen der praktischen Umsetzung im Abschnitt 7.2 erläutert.

3.1.3 Subsysteme und Protokolle

Subsysteme und Protokolle sind Systeme, die entweder Insellösungen oder lediglich

Protokolle für die Netzwerke der GA darstellen, aber kein eigenständiges

gewerkeübergreifendes GA-System sind.

Ein Beispiel für ein Subsystem stellt „DALI“ (Digital Addressable Lighting Interface) dar, vgl.

[ZEN17@]. DALI ist ein Lichtbus, der auf die Ansteuerung von Leuchtmitteln spezialisiert wurde

und mit einfachen Dimmfunktionen angefangen hat. Übergreifende GA-Systeme haben die

Problematik, dass aufgrund der großen Vielfalt an Beleuchtungsmitteln und den

dazugehörigen Geräten spezifische Lösungen für die Dimmfunktionen entwickelt und in das

System integriert werden müssen. Dies bedeutet einen erhöhten Entwicklungsaufwand für die

GA-System-Hersteller. DALI löst dieses Problem, indem die Beleuchtungsfunktionalitäten auf

einen eigenen Lichtbus ausgelagert und als Subsystem in größere GA-Systeme integriert

werden können. Darüber hinaus kann DALI auch allein als ausgelagerte Lösung für die

Steuerung der Beleuchtung funktionieren.

In [BFD+12] wird ein darüber hinausgehender Forschungsansatz vorgestellt, der das

Subsystem DALI auch für drahtlose Netzwerke und GA-Systeme nutzbar macht.

Weitere Beispiele für ähnliche Insellösungen sind in den Forschungsarbeiten für dezentral

geregelte Lichtsysteme in [AFMI16] oder Heizungssysteme [KIAH15] dargestellt.

Als Beispiel für ein Protokoll sei an dieser Stelle „ZigBee“ genannt, dieses ist speziell für

drahtlose Netzwerke mit geringem Datenverkehr und kurzer Reichweite (10 bis 100 Meter)

ausgelegt, vgl. [ZIG17@].

3.1.4 Heimsysteme

Die einfachsten zu installierenden GA-Systeme sind die sogenannten Heimsysteme. Dazu

zählen Produkte, die unter dem modernen Überbegriff „SmartHome“ zusammengefasst sind

und einzelne Funktionalitäten der RA bereitstellen.

Zu diesen Heimsystemen zählen auch die sogenannten „Assistenzsysteme zum Wohnen“, die

in der [VDI-RICHTLINIE 3812-1] behandelt werden. Diese Assistenzsysteme sind auf

Wohnbereiche spezialisiert und lassen sich in den Funktionalitäten nach folgenden Gruppen

einteilen:

• Energie- und Wassereinsparung,

• Sicherheit,

• Komfort,

• Bedienungsvereinfachung und

• Technische Barrierefreiheit.

19


Die in dieser Richtlinie behandelten Funktionalitäten stellen weder ein eigenständiges GA-

System dar, noch sind diese mit den in der [VDI-RICHTLINIE 3813-2] vorgestellten RA-

Funktionen vergleichbar. Ziel der Assistenzsysteme ist die Unterstützung der Bewohner eines

Hauses in den oben genannten Themen.

In der Ausführung beinhalten die Heimsysteme nur einzelne Sensoren und

Informationsdisplays, die z. B. den aktuellen Energieverbrauch anzeigen und vergleichen

können. Aber auch ausführlichere Systeme, die mehrere Geräte vernetzen können und

beispielsweise über Smartphones bedient werden, fallen unter diese Begrifflichkeit, vgl.

[WUK+14@].

Ein Beispiel dazu ist die vom Energiekonzern RWE angebotene „SmartHome“-Serie „innogy“

[INN17@]. Diese Serie besteht aus einzelnen Adaptern und Bauteilen, die über das hauseigene

Funknetzwerk mit dem Internet verbunden und dann per Applikation auf dem Smartphone oder

Tablet auch von unterwegs aus gesteuert werden können. Der Nutzer kann sich aus dieser

Serie die für ihn passenden Geräte, z. B. Stromadapter, Heizungsthermostate oder

Fenstersensoren, heraussuchen und diese selbst im Haushalt anschließen. Der Vorteil dieser

Produkte ist die unkomplizierte eigene Einrichtung im Haushalt. Ziel des Systems ist die

Nachrüstung von beispielsweise Mietwohnungen. Die zentrale Systemkomponente des

Systems ist die RWE-SmartHome-Zentrale. Um den vollen Funktionsumfang nutzen zu

können, muss diese Zentrale ständig mit dem Internet verbunden sein. Das Portfolio an

Sensoren umfasst neben Tastern und Fernbedienungen Raumthermostate, Rauchmelder,

Tür-/ Fensterkontakte, Bewegungsmelder, Dimmer und Jalousieschalter sowie kombinierte

Sensor-/ Aktor-Systeme. Eine komplette Elektroinstallation kann mit diesem System nicht

ersetzt werden, dafür reicht das Portfolio für eine umfangreiche Nachrüstung. Im Bereich der

Aktoren werden Zwischenstecker angeboten, die mit Dimmfunktion einzelne Lampen

ansteuern können. Ebenfalls sind Stellantriebe für Heizkörper (in Kombination mit Thermostat)

und Jalousien verfügbar. Nachteilig ist, dass das Internet-Heimnetzwerk durch die

Komponenten belastet wird und bei Ausfall des Internets viele Funktionen nicht zur Verfügung

stehen. Zielgruppen dieser Systeme sind einzelne Haushalte, da die Anzahl der Teilnehmer

netzwerkseitig begrenzt ist und durch die fehlende übergeordnete Regelung die Ausstattung

eines großen Bürogebäudes mit vielen Nutzern unzweckmäßig ist.

Aktuelle Forschungsansätze auf dem Gebiet der Heimsysteme, wie in [LCH+16],

spezialisieren sich darauf, Cloud-basierte Services in bestehende Netzwerke zu integrieren

und die Vernetzung möglichst vieler Funktionalitäten in einem Heimnetzwerk zu gewährleisten.

3.1.5 Systemeingrenzung

Die Marktanalyse hat das breite Spektrum an GA-Systemen von einzelnen Komponenten zum

Nachrüsten bis hin zu großen, umfassenden GA-System-Anlagen aufgezeigt. Die

verschiedenen Systeme können in Anlehnung an die grobe Unterteilung von [ASC14]

grundsätzlich in zentrale und dezentrale Systeme unterteilt werden. Hinzu kommt die

Erweiterung um die Betrachtung der Subsysteme und Heimsysteme als eigenständige

Kategorien.

Im Rahmen dieser Arbeit steht die RA als Teil der GA im Fokus. Die RA stellt die funktionale

Umsetzung der GA in den einzelnen Räumen dar und daher werden in dieser Arbeit die in der

[VDI-RICHTLINIE 3813-2] beschriebenen lösungsneutralen RA-Funktionen betrachtet.

20


Zentrale und dezentrale GA-Systeme nach dieser Einteilung lassen sich in ihren Funktionen

bezogen auf die RA auf die betrachteten Funktionen der [VDI-RICHTLINIE 3813-2] aufteilen

und unterscheiden sich lediglich durch die Art und das Medium der Vernetzung.

Die Subsysteme können sich in Teilen durchaus auf die allgemeinen Funktionen aufteilen

lassen, jedoch sind diese Systeme proprietär erstellt und haben damit auch systemeigene

Funktionen und Geräte, die nicht durch die lösungsneutralen Funktionen abgedeckt werden

können.

Die vorgestellten Heimsysteme umfassen lediglich einzelne Komponenten, die eigenständig

ohne weitere Komponenten ihrer Funktion nachkommen können. Auch diese lassen sich nur

in Teilen auf die allgemeinen Funktionen der [VDI-RICHTLINIE 3813-2] aufteilen.

Im Rahmen dieser Arbeit stehen zentrale und dezentrale GA-Systeme in Bezug auf die RA im

Fokus. Die Subsysteme und Heimsysteme werden aufgrund ihrer jeweiligen Spezialisierung

nicht gesondert betrachtet und lassen sich, sofern sie sich auf die lösungsneutralen RA-

Funktionen der [VDI-RICHTLINIE 3813-2] aufteilen lassen, gleichartig behandeln.

3.2 Das Anforderungsportfolio der Gebäudeautomation

Auch bei der Realisierung eines GA-Systems werden Bauherren vor das Optimierungsproblem

des aus dem Projektmanagement bekannten „magischen Dreiecks“ aus Zeit, Kosten und

Qualität gestellt [SGS14]. Dabei soll ein GA-System grundsätzlich die Grundmotivation nach

einem funktionierenden, kostengünstigen und zeitlich zügig realisierbaren System erfüllen.

Relevant ist dabei aber auch, dass die eigentliche Motivation für die Realisierung eines GA-

Systems aus den beiden Faktoren Wirtschaftlichkeit und Funktionalität besteht. Um ein optimal

ausgelegtes GA-System zu erstellen, müssen diese beiden Faktoren beim Engineering

berücksichtigt werden, um nicht nur die Anschaffungskosten, sondern auch die Betriebskosten

gering zu halten und die eigentlich gewünschten Funktionalitäten bereitzustellen. Darüber

hinaus ist eine entsprechende Qualitätssicherung zur Erfüllung der Anforderungen an GA-

Systeme unerlässlich und es muss darüber hinaus beachtet werden, dass auch der

Bauprozess Einfluss auf das Engineering von GA-Systemen nimmt. Im Folgenden werden die

vier Aspekte Wirtschaftlichkeit, Funktionalität, Qualitätssicherung und der Bauprozess

genauer betrachtet und die Herausforderungen herausgearbeitet. Im Abschnitt 3.3 werden

aktuelle Forschungsarbeiten in diesen Teilaspekten beschrieben und die Anforderungen an

ein übergeordnetes Engineering der GA abgeleitet.

3.2.1 Motivation Wirtschaftlichkeit

Der wirtschaftliche Aspekt ist meist die Hauptmotivation für den Einbau eines GA-Systems.

Unter diesem Aspekt werden Beiträge zur effizienteren Nutzung von Energie verstanden, die

in Zeiten von steigenden Energie- und Rohstoffpreisen von großer Bedeutung für

Endverbraucher sind. Von 2000 bis 2016 ist der Preis von Heizöl um ca. 20% gestiegen, von

Strom sogar um ca. 83%, vgl. [STA17]. Da Gebäude mit ca. 35% die größten

Energieverbraucher weltweit sind, kommt den Energieeinsparungen durch GA eine große

Bedeutung zu [BUN14@]. Weitere wichtige Aspekte beim Thema Wirtschaftlichkeit sind neben

dem Umgang mit Ressourcen und einer langen Lebensdauer auch die Austauschbarkeit von

Geräten, deren Instandhaltung und Wartung. Weiterhin gehört auch die Erweiterbarkeit eines

GA-Systems zu den Aspekten der Wirtschaftlichkeit, damit ein bereits vorhandenes System

bei Bedarf um weitere Funktionen ergänzt werden kann. In diesem Zuge muss auch eine

21


nachträgliche Nutzungsänderung berücksichtigt werden, wenn beispielsweise Gebäude oder

Räume anders genutzt werden sollen, als mit dem bisherigen System ausgeplant wurde.

Dadurch kann auch eine Änderung beispielsweise von Schalterbelegungen notwendig

werden.

Zur effizienten Nutzung von Energie in Gebäuden allgemein gibt es bereits Methoden und

Konzepte, die einen Anhalt zur Energieeinsparung und dessen Messung liefern, vgl.

[VWM+16]. Einen erheblichen Beitrag, um Energie einzusparen, können vor allem heutige GA-

Systeme leisten. Sie bedürfen dafür jedoch einer optimalen und vor allem fehlerfreien

Auslegung, siehe [WID13].

3.2.2 Motivation Funktionalität

Der funktionale Aspekt eines GA-Systems greift durch die Integration von energiesparenden

Funktionen den wirtschaftlichen Aspekt auf und dient zudem dem Komfort des Nutzers. Dieser

soll in seinem Handeln unterstützt werden, indem entsprechende Funktionen beispielsweise

automatisch für eine angenehme Raumklimatisierung oder genügend Licht am Arbeitsplatz

sorgen. Dazu entwickeln Hersteller ständig neue Funktionalitäten, die die Menge an

Möglichkeiten von GA-Systemen erweitern. Viele Hersteller arbeiten in diesem Bereich jedoch

proprietär, weshalb die Nutzung des gesamten möglichen Funktionsumfanges durch die

Interoperabilität zwischen den verschiedenen Herstellersystemen bedingt wird. Auch die

Bedienbarkeit gehört zum funktionalen Aspekt. Gemäß der Studie der RWTH Aachen zur GA

in der Praxis gehören Bedienfehler mit 16% zu den Hauptursachen für Mängel am GA-System.

Zu den Bedienfehlern gehören falsche oder unverständliche Einstellungen und

Parametrierungen, die im Betrieb durch die Betreiber oder Nutzer verstellt werden [FSM17@].

Eng damit verbunden ist auch die Stabilität eines GA-Systems. Gemeint ist damit die

fehlerfreie Funktionalität des Systems, die durch unterschiedliche Ursachen gefährdet sein

kann, so zum einen durch Bedienfehler, zum anderen aber auch durch Qualitätsmängel im

gesamten GA-System. Daher stellt die Funktionalität neben der wirtschaftlichen Forderung

nach Energieeinsparungen weitere Forderungen, bestehend aus Komfort, Bedienbarkeit,

Stabilität und Interoperabilität, an GA-Systeme.

3.2.3 Rahmenbedingung Qualitätssicherung

Um die beiden Grundmotivationen Wirtschaftlichkeit und Funktionalität zu befriedigen, müssen

nicht nur die richtigen Funktionalitäten in einem GA-System vorhanden sein, diese müssen

gleichzeitig auch effizient arbeiten. Beide Faktoren können nur durch ein fehlerfreies und

wirtschaftlich ausgelegtes GA-System als ein effektiver und effizienter Systemverbund wirken.

Daher ist eine zweckmäßige Qualitätssicherung für GA-Systeme unumgänglich.

Ein weiterer nicht zu vernachlässigender Aspekt der Qualitätssicherung ist die Resilienz gegen

mögliche Angriffe auf ein GA-System. Durch die angestrebte Vernetzung aller Anlagen eines

Gebäudes zu einem Gesamtsystem werden auch sensible Bereiche, wie Fenster oder

Schließanlagen, eingebunden und stellen ein Sicherheitsrisiko dar, das durch eine

entsprechende Qualitätssicherung verringert werden muss. Auch die RA betreffend kann ein

Eindringen in das GA-System sehr negative Folgen haben, wenn beispielsweise die Heizungs-

oder Klimaanlage bei entsprechenden Witterungen verändert wird, um ein Arbeiten im Büro

unmöglich zu machen. Die Betrachtung des Aspekts der Resilienz ist nicht Bestandteil dieser

Arbeit und es gibt bereits einige Lösungsansätze auf diesem Gebiet, siehe [GPK10; MUWI16;

NOGE10]. Die Autoren beschäftigen sich in diesen Ansätzen damit, wie ein GA-System durch

22


ungewollten Zugriff von außen geschützt werden kann und müssen dies mit dem genau

entgegengesetzten Trend der vollständigen Vernetzung und Offenheit von Daten vereinbaren,

vgl. auch [KKJ+14].

3.2.4 Rahmenbedingung Bauprozess

Aufgrund der Tatsache, dass ein GA-System grundsätzlich untrennbar mit einem Gebäude

verbunden ist, müssen grundlegende Rahmenbedingungen des Bauwesens Einfluss auf die

GA haben. Dazu gehört auch der Bauprozess, der die Realisierung des GA-Systems

einschließt.

In [BeKn16] wird auf der Grundlage des Lebenszyklus der konventionelle Bauprozess

erläutert, siehe Abbildung 9. In diesem tritt der Bauherr mit seinen Vorstellungen und

Wünschen von einem Gebäude an einen Objektplaner/Architekten heran und verfasst mit

diesem ein Lastenheft bzw. Auftragsbuch. Dieser Schritt ist die sogenannte

Anforderungserhebung, in der die Spezifikationen des Gebäudes genau beschrieben werden.

Dazu gehören auch die Vorstellungen zur GA. Der Objektplaner übernimmt dann im Weiteren

die Kommunikation und Planung mit den Fachplanern. Diese arbeiten in ihren jeweiligen

Gewerken getrennt und liefern dem Objektplaner zeitlich und meist mit heterogenen

Datenquellen ihre Ausplanungen. Es werden derzeit gemäß dem Standardleistungsbuch für

das Bauwesen vom Bundesministerium für Umwelt, Naturschutz, Bau und Reaktorsicherheit

77 einzelne Gewerke beschrieben, siehe [BUN17], die in den Bauprozess integriert werden

können bzw. müssen. In der Bauphase werden Installationen durch Firmen übernommen.

Dabei müssen die Planungsdokumente, u.a. Schalt-, Installationspläne oder Standorte der

Geräte und Bedieneinrichtungen, mit übergeben werden. Dazu gehören ebenfalls u.a.

Funktionsablaufpläne und Parameterlisten, die sich spezifisch auf die GA beziehen, vgl. [VDI-

RICHTLINIE 3814-1]. Für die Ausführungsphase bedeutet die Vergabe von Aufträgen an

Baufirmen, dass zu jedem einzelnen Fachplaner weitere Auftragnehmer und sogar

Subauftragnehmer hinzukommen, die alle an einem Bauprojekt arbeiten, sich abstimmen und

in einen Gesamtplan aufgenommen werden müssen. Aufgrund der heterogenen Datenquellen

und der Vielzahl an Bauteilnehmern kann ein Bauprojekt daher sehr komplex werden. Am

Ende des Bauprozesses findet dann die Inbetriebnahme statt, in der das Gebäude an den

Bauherrn übergeben wird. Dieser hat je nach Gebäudeart verschiedene Nutzer während der

Nutzungsphase, wie z. B. Mieter oder Mitarbeiter. Erst wenn eine Modernisierung stattfindet,

muss der Bauherr je nach Art und Umfang der Maßnahmen die Fachplaner wieder hinzuziehen

und bekommt am Ende der Modernisierung erneut das Gebäude übergeben.

Hauptprobleme beim Bau von Gebäuden sind, wie in [LKH14] beschrieben, die

Subunternehmerkultur, die starren Grenzen der Bauvorschriften und der Honorarordnung für

Architekten und Ingenieure (HOAI) [HOAI 2013] sowie die Fehleinschätzungen der Kosten.

Unter dem Stichwort der Subunternehmerkultur verbirgt sich die Weitergabe von Aufträgen an

viele kleine Unternehmen, die jeweils für ihren einzelnen Auftrag das günstigste Angebot

gemacht haben. Der Vorteil liegt dabei ganz klar in einer möglichen Kostenreduzierung, jedoch

birgt die Aufteilung eines Gebäudes auf viele kleine Subunternehmer das Risiko, dass der

Gesamtüberblick verloren geht und dass die Schnittstellen zwischen den Subunternehmungen

nicht vollständig abgesprochen sind oder nicht berücksichtigt werden.

Hinzu kommt, dass die Vertragserfüllung erst bei Fertigstellung und Erfüllung der Leistung

gemäß Leistungsvereinbarung gegeben ist. Bei Mängeln in der Fertigstellung kann der

Auftraggeber auf der sogenannten Nacherfüllung bestehen und den Auftragnehmer

23


verpflichten, die Mängel auf seine Kosten zu beseitigen, vgl. [BGB §439; VOB-B]. Daher haben

auch ausführende Fachleute ein großes Interesse daran, dass keine Schnittstellenprobleme

oder Planungsfehler entstehen.

Abbildung 9: Der konventionelle Bauprozess aus [BEKN16, S. 8]

24


Bezogen auf die GA gibt es derzeit zwei Varianten bei der Planung von GA-Systemen:

Die gewerkegetrennte GA-Planung und die integrierte GA-Planung gemäß

[DIN EN ISO 16484-1].

3.2.4.1 Gewerkegetrennte GA-Planung

Bei der Planung und dem Bau eines Gebäudes wird der konventionelle Bauprozess

angewendet. In diesem kommt die GA häufig nicht als eigenständiges Gewerk vor, sondern

ist innerhalb der unterschiedlichen Kostengruppen, wie in Tabelle 1 aufgeführt, verborgen. Die

eigentliche Leistung eines GA-Systems, viele verschiedene Funktionen, die vorher eindeutig

einzelnen Gewerken zuzuordnen waren, zu vernetzen und dadurch effizienter zu gestalten,

wird nicht direkt wahrgenommen.

Die GA wird auch deshalb nicht als eigenständiges Gewerk wahrgenommen, weil die

Zusammenhänge zwischen den Funktionen und die gegenseitige Beeinflußung, wie in Kapitel

1 aufgeführt nicht direkt ersichtlich sind und daher moderne übergreifende Steuer- und

Regelungsanlagen, wie von Heizungen oder Stromanlagen, als Innovationen in den einzelnen

Gewerken beworben und entsprechend registriert werden. Die Folge ist, dass der GA-

Fachplaner nicht einbezogen und mit der Errichtung einer übergreifenden GA beauftragt wird,

da kein eigenständiges und proprietäres GA-System eines Herstellers eingeplant wird,

sondern lediglich die neusten Innovationen in den einzelnen Gewerken.

Die Forderungen nach RA und in Teilen auch nach GA werden im konventionellen Bauprozess

an den Architekten abgegeben, welcher die Forderungen auf die Gewerke aufteilt. Dadurch

sind viele verschiedene Gewerke an der GA-Planung beteiligt und die Planung erfolgt daher

sowohl zeitlich als auch für die Gewerke getrennt. Die Folgen sind Schnittstellenprobleme,

Verbindungsfehler oder falsche Auslegungen. Die Kommunikation zwischen Bauherrn,

Architekt und Fachleuten findet darüber hinaus über verschiedene Datenmedien und Software

statt, was neben Kommunikationsproblemen und fehlenden Schnittstellenabsprachen auch zu

Dateninkonsistenzen führen kann, vgl. [DRA10].

3.2.4.2 Integrierte GA-Planung gemäß DIN EN ISO 16484

Die zweite Variante ist die Integrierte GA-Planung gemäß [DIN EN ISO 16484-1]. In der

internationalen Norm [DIN EN ISO 16484-1] werden grundsätzliche Leitsätze zur

Projektplanung und -ausführung von GA-Systemen festgelegt. Dazu verweist die Norm auf die

„funktionale Integration als gemeinsame Aufgabe aller an der Entwicklung einer integrierten

gewerkeübergreifenden Anlage Beteiligten“ und stellt die Systemintegration in den

Vordergrund. Systemintegratoren sind Fachplaner der GA, welche in der Regel zentrale und

dezentrale GA-Systeme proprietär ausplanen. Dabei können Fachplaner sich für einzelne

Hersteller als lizensierte Partner zur Verfügung stellen, wie beispielsweise als KNX-Partner

nachdem Sie eine entsprechende Schulung durchlaufen haben [KNX16A@]. Die GA-

Fachplaner werden dann von Kunden beauftragt, wenn bereits in der Planungsphase feststeht,

dass ein GA-System, meist eines spezifischen Herstellers, installiert werden soll.

Die Zielgruppe der DIN EN ISO 16484 sind Hersteller, Systemintegratoren,

Elektroinstallateure und HLK-Anlagenerrichter. Da die Norm davon ausgeht, dass ein GA-

Projekt erst beginnt, nachdem der Kunde einen GA-System-Berater oder -Lieferanten

aufgesucht hat, erfolgt die GA-Planung in diesen Fällen integriert durch einen GA-Fachplaner.

25


Die erforderlichen Phasen zur Realisierung eines GA-Systems legt die Norm folgendermaßen

fest [DIN EN ISO 16484-1, S. 5]:

• „Planung: Bestimmung der Projektanforderungen und Erstellen von

Auslegungsdokumenten einschließlich technischer Spezifikationen;

• Technische Bearbeitung: detaillierte Planung der Funktionen und der Hardware;

• Installation: Montage und Inbetriebnahme des GA-Systems;

• Abschluss: Übergabe, Abnahme und Fertigstellung.“

Die Norm fordert auch eine Systemüberprüfung vor und nach der Installation

[DIN EN ISO 16484-1, S. 22–24] mit dem Ziel der Qualitätssicherung. Dazu soll das System

darauf überprüft werden, ob es die betrieblichen Anforderungen erfüllt. Überprüft werden u.a.

die Automationsstrategie und GA-Funktionen, Interoperabilität und die Gebrauchstauglichkeit

(Mensch-Maschine-Schnittstelle).

Zur gesamten projektspezifischen Dokumentation gehören u.a. auch Bedien- und

Instandhaltungsdokumente mit der Forderung nach einer Anlagendokumentation, die die

Netzwerktopologie, Funktionsablaufdiagramme und die GA-Funktionslisten enthält. Dazu

gehört auch die Forderung nach einer konsistenten Datennutzung.

3.2.5 Zusammenfassung des Anforderungsportfolios

Die aufgezeigten Aspekte der Anforderungen an das Engineering von GA-Systemen sind

zusammenfassend als Anforderungsportfolio der GA in Abbildung 10 dargestellt:

Das Portfolio umfasst vier Bereiche, welche sich in die Motivationen (Abbildung 10, oben) und

die Rahmenbedingungen (Abbildung 10, unten) aufteilen lassen und nachfolgende Aspekte

beinhalten.

Motivationen:

• Die Funktionalität mit den Forderungen nach Komfort, Bedienbarkeit, Interoperabilität,

Stabilität und den verschiedenen Verbindungsarten.

• Die Wirtschaftlichkeit mit den Forderungen nach einer langen Lebensdauer der Geräte,

Energieeffizienz, Energieeinsparungen, Qualität, Erweiterbarkeit und

Austauschbarkeit.

Rahmenbedingungen:

• Die Qualitätssicherung mit den Forderungen nach einem fehlerfreien und wirtschaftlich

ausgelegten GA-System und der Resilienz gegen Angriffe auf die IT- Sicherheit und

physische Infrastruktur.

• Der Bauprozess als Rahmenbedingung mit den Herausforderungen der nach

Gewerken getrennten Planung und Ausführung, unterschiedlichen Datenquellen und

vielen Schnittstellen zwischen den Baubeteiligten.

Im Folgenden wird untersucht, welche Forschungsansätze in Bezug auf die dargestellte

Problematik innerhalb dieser Bereiche existieren und welche Anforderungen sich bezüglich

einer ganzheitlichen Betrachtung des GA-System-Engineerings daraus ableiten lassen.

26


Abbildung 10: Übersicht des Anforderungsportfolios der GA

3.3 Forschungsarbeiten auf dem Gebiet der Gebäudeautomation

In diesem Unterkapitel sollen relevante Forschungsansätze der GA kurz vorgestellt und in den

Kontext dieser Arbeit integriert werden. Dies dient der Darstellung der Gesamtsituation, in der

sich heutige Engineeringansätze der GA befinden. Die Forschungsansätze, die sich mit den

allgemeinen Herausforderungen an GA-Systeme beschäftigen, werden anhand des

Anforderungsportfolios eingeordnet und verwendete Methoden auf eine Anwendbarkeit zur

Erfüllung des Anforderungsportfolios überprüft. Forschungsansätze, die bereits Lösungen für

ein Engineering der GA enthalten, werden in Kapitel 4 vorgestellt, miteinander verglichen, und

der bestehende Handlungsbedarf wird daraus abgeleitet.

3.3.1 Die Wirtschaftlichkeit

Hauptaugenmerk des Bereichs Wirtschaftlichkeit liegt in der Energieeffizienz und deren

Bedeutung für die GA. Nur Systeme, die sich selbst nach wenigen Jahren amortisieren,

werden sich dauerhaft innerhalb des eigenen Marktsegmentes durchsetzen können. Das

bedingt, dass die Gebäudeautomation auch die versprochene Nachhaltigkeit für Gebäude und

deren Energiewirtschaft, wie in [ASC14] und [HEI13] beschrieben, erbringen kann.

Die reinen Funktionalitäten eines GA-Systems können bereits viel Energie im Vergleich zur

Nichtverwendung von geregelten Systemen einsparen. Dies wird auch in [FEL17] als Beitrag

der GA zum energieeffizienten Betrieb von Gebäuden aufgezeigt. Die Einsparung kann jedoch

27


durch geschicktes Energiemanagement noch weiter deutlich gesteigert und verbessert

werden. Ansätze dazu beschreiben den Einsatz von künstlicher Intelligenz im Rahmen des

Energiemanagements. In [MWA+16] wird aufgezeigt, wie mittels der Integration von

Gebäuden in das „Smart Grid“, das intelligente Stromnetz, Energie eingespart werden kann.

Dabei soll das Stromnetz durch Umverteilungen Energie dahin liefern, wo sie gerade

gebraucht wird, und so die Energienachfrage und das Energieangebot bestmöglich

kombinieren. Durch die wechselnden Phasen der Energienachfrage über den Tagesverlauf

kann das Energiesystem sehr dynamisch werden und durch die Anpassung der

Energienachfrage durch ein Energiemanagementsystem eines GA-Systems optimiert werden.

Auch in [SLJ+13] wird ein Energiemanagementsystem vorgestellt, das in ein GA-System

integriert wird und durch stochastische, dynamische Programmierung das

Optimierungsproblem der optimalen Energieausnutzung angeht. Für ein solches

Energiemanagement wurde in [WEHA13] weiter ein Ansatz zur Simulation des

Energieverbrauchs von GA-Systemen entwickelt. In diesem können die Energiekosten durch

Vermeidung von Energienutzung zu Spitzenlastzeiten gesenkt werden, da die Simulation den

optimalen Zeitpunkt für die Nutzung von Energie errechnet. Ein ähnlicher Ansatz wurde in

[HXS+14] auf der Basis einer Simulation in Modelica vorgestellt und soll ebenfalls den

Energieverbrauch eines GA-Systems steuern.

3.3.2 Die Funktionalität

Die Anforderungen an die Funktionalität eines GA-Systems sind sehr vielseitig und reichen

von verschiedenen Arten von GA-Systemen über deren Verbindungen, neuartige Funktionen

und Funktionszusammenhänge bis hin zur Standardisierung von GA-Systemen, deren

Stabilität und Interoperabilität, vgl. [BDH+14]. In [SSK+11] werden einige Trends in der GA

aufgezeigt. Darunter zählt auch die zunehmende Modularisierung. Das bedeutet, dass

Funktionen als einzelne Module angeboten werden, die entweder im Bereich „SmartHome“

oder auch für umfangreichere, dezentrale GA-Systeme zur Verfügung stehen. Vorteil der

Modularisierung ist die einfache Konfiguration durch eine Art „Plug-and-Play“. Ein weiterer

großer Schwerpunkt im Bereich der Funktionalität ist die Steuerung und Regelung von GA-

Systemen, die durch Ansätze der „Umgebungsintelligenz“ bzw. „Ambient Intelligence“ über die

klassische Regelung von automatisierten Systemen hinausgehen, indem sie versuchen, die

menschlichen Handlungsweisen zu interpretieren oder vorauszuahnen und den Nutzern

dadurch mehr Komfort und Arbeitserleichterungen im Alltag anzubieten. Diese

Forschungsansätze versprechen eine deutliche Zunahme von GA-System-Funktionen, die mit

dem Menschen besser interagieren und präziser auf dessen Bedürfnisse reagieren können,

indem die Umgebung des Menschen möglichst vollständig miteinander vernetzt wird, vgl.

[RSS+11] und [RSL+14]. Für die Heimnetzwerke stellt [ASK+10] die Ziele der Vernetzung vor,

die deutlich über die RA-Funktionen hinausgehen und ihre Funktionalität als „Ambient Assisted

Living“ (DE: Umgebungsunterstütztes Leben) anbieten. Zielgruppe dieser Idee sind vor allem

ältere oder benachteiligte Menschen, die durch diese Funktionalitäten in ihrem Alltag

situationsabhängig und unaufdringlich unterstützt werden sollen. Mit der Verschmelzung von

künstlicher Intelligenz und der „Ambient Intelligence“ wird in [SLP+12] durch ein neuartiges

Kontrollsystem den Herausforderungen an die Verarbeitung von Sensorsignalen und

zugehörigen Regelungen begegnet.

Die Forschungsarbeiten auf dem Gebiet der „Serviceorientierten Architektur“ (SOA) versuchen

die GA-Systeme weiter zu verbessern, indem die an Geschäftsprozessen orientierte Struktur

28


auf die GA übertragen wird, um so die limitierten Ressourcen des GA-Systems effizienter zu

nutzen, vgl. [HLC14; SLMO11].

Zwei weitere Handlungsfelder der GA sind die Integration von webbasierten Services

[CKG+07] zur Erweiterung des Funktionsumfanges und das Routing innerhalb von

Netzwerken, zur Verbesserung der Stabilität von GA-Systemen, vgl. [PML+15]. Auch die sich

drastisch erhöhende Menge von Daten von GA-Systemen, die mit zunehmender

Automatisierung einhergehen, kann die Stabilität des Systems beeinflussen. In [NKG+16]

wurde dazu ein Konzept zur Strukturierung, Organisation und Vereinheitlichung der Daten von

GA-Systemen vorgestellt.

Bezüglich der Interoperabilität wollen Forschungsansätze die proprietären GA-Systeme

miteinander mittels offener Standards wie „Open Platform Communications“ (OPC) und „OPC

Unified Architecture“ verbinden, vgl. [GRKA12; RGP+08]. Weiter wird in [KRA13] das durch

ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers)

[ASHRAE STANDARD 135-2004], ANSI (American National Standards Institute) und

ISO 16484-5 standardisierte Netzwerkprotokoll „BACnet“ beschrieben. Dieses Protokoll wurde

speziell für die GA entwickelt und kann verschiedene Feldbusse miteinander verbinden. Eine

weitere neuartige Struktur für GA-Systeme wird im modellbasierten Entwicklungsansatz von

[BGN+14] vorgestellt. Ziel ist ein serviceorientierter Ansatz zur Verknüpfung von

unterschiedlichen GA-Systemen. Dies wird durch eine gemeinsame Kommunikationsstruktur,

kompatible Datenmodelle zur gemeinsamen Datennutzung, einheitliche semantische Struktur

und Werkzeuge zur Einbindung von veralteter Hard- und Software erreicht. In dieser Struktur

sollen per semantischem Adapter auch bestehende GA-Systeme miteinander verbunden

werden. Der Leitgedanke dieser Forschungsarbeit steht unter dem Begriff „Building as a

Service“ und beschreibt die Weiterentwicklung von gängigen GA-Systemen durch Nutzung

von Standards in Software und Protokollen. In diesem Rahmen wurde in [GTP+15] auch ein

GA-System auf der Grundlage eines Android-Betriebssystems und einer Bluetooth-

Verbindung der Geräte entwickelt.

Die dargestellten aktuellen Ansätze beschreiben, getreu dem Trend des „Internet of Things“,

die zunehmende Vernetzung aller Bereiche in einem GA-System zu einem großen Netzwerk.

Einher geht dieser Trend mit der ständigen Erweiterung des Funktionsumfangs bei GA-

Systemen. Folgen dieser Vernetzung sind viele Daten, viele verschiedene Verbindungen und

größere Systeme, welche die Stabilität von GA-Systemen gefährden. Die aufgezeigten

Konzepte zur Stabilität und Datenstrukturierung können diesen Herausforderungen begegnen.

Die Forschungsansätze zur Interoperabilität zeigen den Bedarf an der Nutzung des gesamten

Funktionsumfangs auf und versuchen, die proprietären Grenzen zu überwinden.

3.3.3 Die Qualitätssicherung

Qualitätssicherung ist ein oft erst im Betrieb bedachtes Themenfeld, da Fehler in diesem

Bereich oftmals erst nach Realisierung des GA-Systems auffallen. In der Phase des Betriebs

stellt das Online-Monitoring eine Methode der Qualitätssicherung dar, die genutzt werden

kann, um Fehler im laufenden Betrieb zu finden. Dazu wird in [DISC13] ein Ansatz vorgestellt,

der auch für große dezentrale GA-Systeme ausgelegt ist und sich auf die Verifizierung der

Nachrichten auf dem Bussystem fokussiert. Dieser Ansatz basiert auf einer Petrinetz-

Modellierung des Kommunikationssystems und überwacht das Ankommen bzw. den Verlust

von Telegrammen auf dem Bus. Für das Engineering von GA-Systemen kann dieses

Verfahren auch zum Test von Verbindungen erweitert werden. Es bedarf dazu noch einer

29


Überprüfungsmethode, die auch schon in der Phase der Planung und der Installation

verwendet werden kann.

3.3.4 Der Bauprozess

Es gibt verschiedene Ansätze, den aktuellen konventionellen Bauprozess zu optimieren. Die

Tatsache, dass die GA immer noch nicht als eigenständiges Gewerk adäquat im Bauprozess

berücksichtigt wird [HEI14; SEI12], kann sich in der Praxis nicht schnell und einfach beheben

lassen. So wie der Bauprozess über Jahrzehnte hinweg immer wieder angepasst und

weiterentwickelt wurde, so wird sich die Forderung nach einer eigenständigen GA auch erst

mit erhöhtem Druck durch Bauherren umsetzen lassen. Als Empfehlung für eine Verbesserung

dieses Umstandes wird in [BEKN16] ein optimierter Bauprozess beschrieben, siehe

Abbildung 11.

Abbildung 11: Optimierter Bauprozess aus [BEKN16, S. 10]

In diesem wird die GA als eigenständiges Gewerk berücksichtigt und GA-Fachplaner werden

schon frühzeitig und übergreifend in den Planungsprozess eingebunden. Im Unterschied zu

den beiden GA-Planungsprozessen in Absatz 3.2.4, dem gewerkegetrennten und integrierten

GA-Planungsprozess, soll in jedem Fall ein GA-Fachplaner beauftragt werden, um die immer

weiter wachsenden Forderungen nach Funktionalität in Gebäuden adäquat zu

berücksichtigen. Dadurch können Schnittstellenabsprachen schon in frühen Phasen zwischen

Gewerken getroffen und entsprechend ausgeplant werden. Dieser Prozess erleichtert die

Realisierung eines GA-Systems im Vergleich zum konventionellen Bauprozess erheblich, da

30


ein Fachplaner für die GA das GA-System übergeordnet in direkter Absprache mit den

anderen Fachplanern und Gewerken entwerfen kann.

Weitere Verbesserungsansätze für das Bauwesen sind die Optimierung vom Gebäude-

Lebenszyklus [SEY11] und von den dazugehörigen Lebenszykluskosten [PEL06]. Dabei wird

vorrangig versucht, im Rahmen der phasenübergreifenden Betrachtung Schnittstellenfehler

auszubessern und Optimierungspotenziale zu finden. Auch die Betrachtung der

Qualitätssicherung über den gesamten Gebäudelebenszyklus ist ein Ansatz den Bauprozess

betreffend, der in [PAK+15] anschaulich erläutert wird. Aus diesen Forschungsarbeiten wird

ersichtlich, dass die durchgängige Betrachtung von Gebäuden als notwendig erachtet wird,

um mangelhafte Entwürfe und Bauausführungen zu verbessern.

Während die Prozesse beim Gebäudebau sehr langsamen Innovationszyklen unterliegen,

haben computergestützte Technologien den gleich schnellen Innovationszyklus wie die IT

selbst, vgl. [KRA13].

Als eine computergestützte Unterstützung des Bauprozesses gibt es seit 1995 die „Building

Information Modelling“ (BIM) -Methode. Unter BIM wird die Betrachtung eines Gebäudes im

gesamten Lebenszyklus vom ersten Entwurf über die Fertigung und den Bau bis hin zum

Betrieb und zur Instandsetzung verstanden. Ziel der BIM-Methode ist es, die aufwendigen

unterschiedlichen Planungstools einzelner Gewerke zu vereinheitlichen und eine zentrale

Datenaustauschdatei zur Verfügung zu stellen. In der Umsetzung vernetzt das BIM alle

relevanten Daten über ein Gebäude miteinander, um die Probleme der bisherigen

heterogenen Datenquellen zu lösen. Dies soll Fehler beim Austausch der Planungsstände

verhindern und einen kompletten Gebäudeentwurf ermöglichen. Diese Form der

Datenmodellierung wurde von der Industrieallianz für Interoperabilität e.V. (IAI) entwickelt und

wird heute unter der Organisation „BuildingSMART e.V.“ [BUI17@] weiterentwickelt.

Aufgrund von mangelnden Definitionen, intransparentem Datenmanagement und unklaren

Schnittstellen und Zuständigkeiten wird die Nutzung von BIM aktuell erschwert [JAN17]. Um

diese Erschwernisse zu lösen, sind und werden Informationen zu BIM, wie u.a. Begriffe und

Definitionen (Blatt 2), Modellinhalte, Datenaustausch (Blatt 4), Prozesse (Blatt 7) und

Datenmanagement (Blatt 5), im Entwurf der neuen [VDI-RICHTLINIE 2552 ENTWURF] aktuell

zusammengefasst.

Da die BIM-Methode noch nicht weit verbreitet und noch lange nicht als Standard in der

Baubranche anerkannt ist, gibt es verschiedene aktuelle Forschungsprojekte in diesem

Bereich. Ein bekanntes Forschungsprojekt ist „BIMiD – BIM-Referenzobjekt in Deutschland“,

das durch das Bundesministerium für Wirtschaft und Energie gefördert wird. Ziel dieses

Projektes ist es, den Bekanntheitsgrad der BIM-Methode durch konkrete Bauprojekte zu

steigern und durch die gewonnenen Erfahrungswerte mit der Methode

Weiterbildungskonzepte zu generieren [BIM17@]. Die BIM-Methode ist auch in Bezug auf die

GA ein guter Ansatzpunkt, da die Durchgängigkeit in der Betrachtung nicht nur über die

Planungsphasen und Gewerke hinweg Anwendung findet, vgl. [DELI06], sondern auch über

die verschiedenen Lebenszyklusphasen bis in den Betrieb hinein. In [VER+16] wird dieses

Vorgehen für das Facility Management beschrieben und nachgewiesen, dass die Verwendung

der BIM-Methode auch im Betrieb zu einer Optimierung der Arbeitsabläufe führt, indem die

digitale Gesamtdokumentation konsequent genutzt wird. In [FEKA16] ist dazu auch ein

wissensbasierter Ansatz beschrieben, der die semantische Integration von Informationen aus

BIM-Modellen mit Informationen zu GA-Systemen in einem wissensbasierten

Gebäudemanagementsystem zusammenfasst. Ziel dieser vorgestellten Konzepte ist in erster

31


Linie das Gebäudemanagement im Betrieb und nicht das Engineering von GA-Systemen. Die

Ansätze verdeutlichen jedoch, dass die BIM-Methode auch in Bezug auf das Engineering von

GA berücksichtigt werden sollte.

3.3.5 Ableitungen aus den Forschungsansätzen zur GA

Die Forschungsansätze aus dem Bereich der Wirtschaftlichkeit deuten auf eine durch den

Einsatz von künstlicher Intelligenz wachsende Komplexität von GA-Systemen hin. Neue

Energiemanagement-Funktionen erweitern zusätzlich den Funktionsumfang. Die Aspekte

Qualität und Lebensdauer der Geräte und die Messung bzw. Optimierung des

Energieverbrauchs haben auch einen Einfluss auf das Engineering von GA-Systemen. Die

Gerätelebensdauer und der Innovationszyklus von neuen Geräten stellen weitere

Forderungen an ein Engineering von GA-Systemen nach Austauschbarkeit bzw.

Erweiterbarkeit von Geräten und Systemen.

Die Betrachtung der Energieeffizienz und des Energiemanagements fordert Methoden, die

eine zuverlässige Vorhersage über Energieverbräuche und Einsparpotenzial liefern können.

Sie werden durch die Entwicklung neuer Funktionen und Geräte auch den Funktionsumfang

erweitern.

Die Forschungsansätze aus dem Bereich Funktionalität zeigen den Trend zur Zunahme des

Funktionsumfanges auf, was bezogen auf das Engineering von GA-Systemen eine hohe

Relevanz hat. Das bedeutet, dass das Engineering so offen entwickelt werden muss, dass

neue Funktionen jederzeit hinzugefügt werden können. Der anzustrebende Zustand der

Interoperabilität erweitert den Funktionsumfang zusätzlich, was für das Engineering von GA-

Systemen bedeutet, dass eine herstellerunabhängige und lösungsneutrale Vorgehensweise

unerlässlich ist.

Die Qualitätssicherung braucht weiterhin Methoden, die eine Überprüfung des GA-Systems in

allen Phasen der Realisierung ermöglichen. Dazu gehört eine Überprüfungsmethode sowohl

vor wie nach der Installation des GA-Systems. Diese Überprüfungsmethoden müssen

unabhängig von proprietären Systemen und damit allgemein für GA-Systeme ausgelegt sein.

Für die Sicherheit von GA-Systemen wurden in den vorgestellten Ansätzen Methoden

aufgezeigt, die parallel zu einem Engineering der GA verwendet werden können, aber nicht

Bestandteil dieser Arbeit sind.

Der optimierte Bauprozess und die Forschungsarbeiten auf diesem Gebiet deuten an, dass

sich der Bauprozess erst durch Erfahrungswerte und Weiterbildungen ändern wird. Für das

Engineering der GA sollte daher auf dem derzeit aktuellen und konventionellen Bauprozess

aufgebaut werden, um die Lücke bis zur Umsetzung der Optimierungen zu schließen.

Für die integrierte GA-Planung wird ein GA-Fachplaner bzw. Systemintegrator benötigt,

weshalb dieser Planungsprozess durch die übergreifende Planung weniger fehleranfällig ist,

als der gewerkegetrennte GA-Planungsprozess und bereits die Entwicklung zum optimierten

Bauprozess hin erkennbar ist.

Der gewerkegetrennte GA-Planungsprozess findet in der Praxis jedoch häufiger seine

Anwendung, da Bauherren und Architekten derzeit die GA noch nicht als eigenständiges und

notwendiges Gewerk betrachten und die Fachplaner meistens nur proprietäre Systeme

anbieten. Daher versuchen Bauherren und Architekten die Forderungen nach RA und in Teilen

nach GA aus Kostengründen in der gewerkegetrennten Planung zu erfüllen.

32


Den angesprochenen Herausforderungen des gewerkegetrennten GA-Planungsprozesses

kann durch zwei Methoden begegnet werden. Zum einen kann der Prozess der

Anforderungserhebung, in dem Bauherr und Architekt ein Raumbuch als Lastenheft für das

Gebäude erstellen, in Hinblick auf die GA verbessert werden. Es sollte eine Möglichkeit geben,

wie im Rahmen dieser Anforderungserhebung alle Vorstellungen des Bauherren in Bezug auf

ein GA-System zusammengefasst werden können. Da gewisse Facharbeiten nur durch

spezialisiertes Personal auszuführen sind, kann die Systemintegration dabei nur in Teilen

gewerkeübergreifend betrachtet werden und es ist unerlässlich zu berücksichtigen, dass die

Detailausplanungen und Ausführungen weiterhin in den Gewerken getrennt stattfinden. Die

gute Anwendbarkeit der BIM-Methode sollte für eine durchgängige Methode zur Verbesserung

des Engineerings Berücksichtigung finden.

3.4 Abgeleitete Anforderungen an das Engineering von GA-Systemen

Die Planung und Auslegung eines GA-Systems brauchen einen Engineeringansatz, der das

GA-System als Ganzes betrachtet, um die genannten Fehlerquellen zu vermeiden und als Ziel

ein optimal funktionierendes, wirtschaftliches und qualitätsgesichertes GA-System hat. Das

bedeutet, dass die Planung nicht erst in den einzelnen Gewerken stattfindet und in einem

zweiten Schritt bei der Installation erst nach und nach zusammengeführt wird, sondern von

Anfang an in einer Gesamtbetrachtung des Systems erfolgen muss.

Die Marktanalyse hat das breite Spektrum an GA-Systemen aufgezeigt. Aufgrund dessen,

dass im Rahmen dieser Arbeit die RA im Fokus steht, wird die Systembetrachtung auf die

zentralen und dezentralen GA-Systeme eingegrenzt.

Die Forschungsansätze zur Interoperabilität, ihre Weiterentwicklung und die Verbreitung des

BACnet-Standards lassen die Annahme zu, dass GA-Systeme grundsätzlich interoperabel

sind. Damit geht die Forderung einher, dass ein Engineering lösungsneutral, also losgelöst

von konkreten Herstellern und Geräten, sein muss, um den größtmöglichen Funktionsumfang

in das Engineering zu integrieren.

Darüber hinaus muss ein Engineering der GA folgende Anforderungen unterstützten:

➢ Unterstützung der Anforderungserhebung

➢ Beachtung der Datenkonsistenz

➢ Systemüberprüfung in Planung/ Installation/ Betrieb

➢ Möglichkeit der Berechnung der Energieeffizienz (-Klasse)

➢ Möglichkeit der Bestandsdokumentation

➢ Unterstützung der gewerkegetrennten GA-Planung

Im Gegensatz zur Norm [DIN EN ISO 16484-1] fängt das Engineering von GA-Systemen im

gewerkegetrennten GA-Planungsprozess in der Planungsphase bei der

Anforderungserhebung zwischen Bauherr und Objektplaner und ohne Fachplaner der GA an.

Bauherr und Objektplaner müssen im Rahmen der Anforderungserhebung unterstützt werden,

33

3.4 Abgeleitete Anforderungen an das Engineering von GA-Systemen

um auf Grundlage der Infrastrukturdaten in Form von Gebäudeplänen zu bestimmen, wo die

Funktionen ausgeplant werden sollen.

Der Ansicht der [DIN EN ISO 16484-1] folgend ist ein einheitliches Kommunikations- und

Datenkonzept notwendig, um Informationsverlust in Form von Schnittstellenfehlern oder

Dateninkonsistenz zu vermeiden. Die Anforderungen beziehen sich auf verschiedene Phasen

des Gebäude-/ GA-System-Lebenszyklus. Das bedeutet, dass unterschiedliche Akteure zu

unterschiedlichen Zeitpunkten an der Realisierung des GA-Systems mitwirken, und fordert,

dass die Übergaben zwischen den einzelnen Phasen aufeinander abgestimmt sein müssen,

um dem einheitlichen Kommunikations- und Datenkonzept zu entsprechen. Somit braucht es

einen Lösungsansatz, der durchgängig von der Idee über die Planung, Installation und

Nutzung bis zum Ersatz des GA-Systems, über das gesamte Engineering von GA, funktioniert.

Weiter braucht das Engineering von GA-Systemen eine Überprüfungsmöglichkeit, um Fehler

schnellstmöglich in den einzelnen Phasen Planung, Installation und Betrieb aufzuzeigen.

Diese Überprüfungsmöglichkeit muss alle vorhandenen Informationen verwenden, sollte

Fehler im System, wie fehlende Verbindungen, aufzeigen und in ihrem Ergebnis eine Basis für

eine Auswahlentscheidung zwischen verschiedenen Systemvarianten bilden können.

Um der Forderung an ein wirtschaftliches GA-System zu genügen sind die Angaben der

Energieeffizienzklasse und das Energieeinsparpotenzial nach [DIN EN 15232] bereits im

Planungsprozess interessant, um bereits während dem Engineering Kosten-Nutzen-

Abschätzungen treffen zu können.

Die Forderungen nach einer Bestandsdokumentation werden nicht nur in der

[DIN EN ISO 16484-1], sondern auch in der [VDI-RICHTLINIE 3814-1] deutlich beschrieben.

Dazu gehören u.a. Funktionsbeschreibungen und Funktionslisten.

Die Forderung der Unterstützung der gewerkegetrennten GA-Planung setzt voraus, dass

vorhandene Engineeringansätze darauf hin überprüft werden müssen, ob die Ansätze auf

einem gewerkegetrennten oder integrierten GA-Planungsprozess aufbauen. Ein Anhalt zur

Überprüfung dieser Forderung ist die beschriebene Ausgangslage und die Zielgruppe der

vorhandenen Engineeringansätze. Die Anforderung an einen Engineeringprozess den

gewerkegetrennten GA-Planungsprozess zu unterstützen setzt ebenfalls voraus, dass kein

GA-Fachplaner oder Systemintgrator für die Planung notwendig ist.

Die aufgezeigten vielfältigen Herausforderungen in der Realisierung eines GA-Systems

müssen durch eine gewerkeübergreifende, integrale und durchgängige Betrachtung

angegangen werden. Im Folgenden werden bereits bestehende Engineering-Ansätze auf

diese Anforderungen hin überprüft und der weiter bestehende Handlungsbedarf abgeleitet.

34

4 Handlungsbedarf für das Engineering der Gebäudeautomation


In diesem Kapitel werden die relevanten Engineeringansätze der Gebäudeautomation anhand

der in Kapitel 3 vorgestellten Anforderungen an das Engineering bewertet und miteinander

verglichen. Daraus wird der Handlungsbedarf hinsichtlich eines integralen und durchgängigen

Engineerings der GA abgeleitet.

4.1 Vorstellung relevanter Forschungsansätze

Den wohl größten Fokus auf die Weiterentwicklung von Ansätzen zur Verbesserung des

Engineerings von GA legte die Technische Universität Dresden (TU Dresden) mit der

Professur für Technische Informationssysteme unter der Leitung von Herrn Prof. Dr.

Kabitzsch. Im Rahmen von vielen Forschungsprojekten zur Thematik wurden verschiedene

Aspekte bei der Planung von GA aufgegriffen, die im Folgenden vorgestellt werden. Ein

zusammenfassendes Ergebnis des Forschungsansatzes von Herrn Prof. Dr. Kabitzsch ist die

Software „AUTERAS“, die in Abschnitt 4.2 mit weiteren toolgestützten Lösungen verglichen

wird.

Darüber hinaus wird in Abschnitt 4.1.5 ein weiterer davon unabhängiger Ansatz zum

Engineering von GA-Systemen vorgestellt. Aufgrund der vielfältigen Verflechtungen der

vorgestellten Ansätze erfolgt die Bewertung und Einordnung der Ansätze in Abschnitt 4.1.6.

4.1.1 Das Projekt AUTEG

Von 2007 bis 2009 wurde das Projekt AUTEG (Automatisierter Entwurf für die

Gebäudeautomation) als Forschungskooperation zwischen u.a. der TU Dresden und der

Helmut-Schmidt-Universität Hamburg (HSU) durchgeführt. Weiterhin waren viele deutsche

Firmen aus der GA-Branche, wie beispielsweise ABB AG, Gesellschaft für Regelungstechnik

und Energieeinsparung mbH oder MSR Elektronik, als Kooperationspartner am Projekt

[DKR+07; WAG16C@] beteiligt.

Das Ziel des Projektes AUTEG war es, eine automatisierte Vorgehensweise für den Entwurf,

die Errichtung und die Inbetriebnahme von GA-Systemen zu entwickeln, um eine deutliche

Reduzierung der Engineering-Kosten bzw. der Gesamtkosten der Anlage bei optimaler

Funktionalität zu erreichen [DKR+07; DPK10]. Methodisch wird in der vorgeschlagenen

Reihenfolge in drei Phasen vorgegangen: Anforderungserhebung, plattformneutraler

Grobentwurf und plattformspezifischer Detailentwurf.

Die Anforderungserhebung beginnt mit Abschluss der Planungsarbeiten der anderen

Gewerke, vor allem vom Baukörper, dem Innenausbau und der HLK, da sie bei der Planung

der GA Berücksichtigung finden müssen. Dazu werden zunächst Schnittstellen zu den

Planungsergebnissen der Vorgänger-Gewerke, wie beispielsweise zu IFC-Dateien, aus denen

die Elemente des Gebäudes sowie Informationen über die Ausrichtung der Fenster und

Fassaden entnommen werden, erstellt und die Planungsergebnisse analysiert. Durch die

Analyse aufgedeckte Planungslücken werden durch eine dialogbasierte Ergänzung mit den

Planern ausgefüllt. Daraus werden insgesamt die Anforderungen an die Funktionen der GA

abgeleitet und in einem Requirements-Repository (Sammlung der Anforderungen) abgelegt.

Im plattformneutralen Grobentwurf, auch als „Abstract Design“ bezeichnet, werden aus den

Anforderungen Grobentwürfe. Diese bestehen aus Platzhaltern in Form von Funktionsblöcken,

35


die durch Verbindung der Ein- und Ausgänge mit Signalflüssen ergänzt werden. Damit wird

die funktionale Abhängigkeit abgebildet. Im plattformspezifischen Detailentwurf, auch

„Detailed Design“ genannt, werden die Platzhalter dann durch verfügbare reale Komponenten

ersetzt. Dies geschieht durch einen evolutionären Algorithmus [ODK09].

Der Ansatz bezieht sich auf die Raumautomation und soll die RA-Funktionen von

verschiedenen Herstellern zu einem Entwurf mit hoher Qualität kombinieren. Die

Anforderungen werden dazu in einem ersten Schritt durch ein wissensbasiertes Tool durch

den Systemintegrator für die GA erhoben [RDF+09]. Die erarbeiteten Herausforderungen bei

der Anforderungserhebung werden als Ausgangssituation für den Ansatz beschrieben und

beinhalten das unterschiedliche Vokabular und Verständnis zwischen dem Systemintegrator

und dem Bauherrn, die Vielfältigkeit der Möglichkeiten, die das Projekt komplex gestalten, und

die bisher geringe Unterstützung durch Software.

Im Rahmen der Kooperation hat Runde einen Lösungsansatz mit wissensbasiertem

Engineering erarbeitet, den er in [RUN10] veröffentlichte. In diesem setzt er das

wissensbasierte Engineering für die Planung eines GA-Systems im Rahmen der

Anforderungserhebung um. Dieses System nutzt dazu eine anwendungsabhängige

Wissensbasis und eine anwendungsunabhängige Wissensverarbeitungskomponente.

Bezogen auf ein GA-System wurde in diesem Ansatz in der Wissensbasis das Wissen über

die Entscheidungen des Bauherrn abgebildet. Das Wissen wird dabei in Klassen-, Fakten- und

Regelwissen unterschieden.

Unter dem Klassenwissen werden die Funktionen eingeordnet. Diese werden mit ihren

Attributen (Parameter, Einbauart etc.) näher beschrieben und können durch Kausalitäten

zwischen den Funktionen weiter definiert werden.

Als Ableitung aus diesem Klassenwissen kann das Faktenwissen verstanden werden. Dieses

dient der Beschreibung projektspezifischer und konkreter Planungen.

Das Regelwissen wird auf das Faktenwissen angewendet und beschreibt einen Prozess, der

eine Wirkung oder Handlung zur Folge hat. Mittels dieser Wissensklassen kann in einer eigens

dafür erstellten Software, vgl. [RUFA11], mit der raumorientierten Planung begonnen werden.

Raum für Raum kann mit einem regelbasierten Vorschlagstool ausgeplant und abgespeichert

werden. Durch eine Vorlagenfunktionalität können Räume auch mehrfach verwendet werden.

Diese vorgestellte Methode des wissensbasierten Engineerings in der GA konnte an einem

Referenzprojekt verifiziert werden und trug dazu bei, dass Inkonsistenzen, Redundanzen und

Kommunikationsprobleme verringert werden konnten. In diesem Zuge floss auch der durch

Herrn Prof. Heidemann entwickelte integrale Planungsansatz in den Gesamtansatz ein, vgl.

[RHF+09; HESC12]. In seinem Ansatz ist der Integrationsplaner bzw. der Systemintegrator

Partner des Objektplaners und erhält die Rolle des „technischen Architekten“. In diesem

Konzept ist der Integrationsplaner nicht nur für die GA, sondern für die gesamte TGA

verantwortlich und kann so aus einer Hand die übergreifende Planung durchführen, vgl. auch

[RFH+10]. Die Software hat daher auch Fachplaner zur Zielgruppe und muss von diesen

bedient und die Wissensbasis entsprechend gepflegt werden.

Um im Rahmen des im Projektes AUTEG entwickelten Entwurfsprozesses von der

Anforderungserhebung zum plattformneutralen Grobentwurf zu kommen, ist es notwendig,

eine Ontologie zu entwickeln. Mit ihrer Hilfe werden die Anforderungen an die Funktionalitäten

hinterlegt, um im Rahmen der Planung den automatisierten Entwurf von GA-Systemen auf der

Ebene der RA zu unterstützen [RDF+09]. Durch die Verwendung von OWL (Web Ontology

36


Language) ist es möglich, das gesammelte Faktenwissen über mögliche Anforderungen,

kausale Abhängigkeiten u. a. mit den spezifischen Anforderungen an ein GA-System zu

verbinden, da diese Sprache maschineninterpretierbares Wissen bereitstellen kann. So kann

aus der Anforderungserhebung ein RA-Schema erstellt werden, das als abstrakter Entwurf zu

verstehen ist. Das RA-Schema besteht aus miteinander verbundenen Funktionsblöcken, die

auf Basis der Funktionsbeschreibungen der [VDI-RICHTLINIE 3813-2] zu einem funktionalen

Entwurf kombiniert werden.

In diesem Zusammenhang hat Dibowski zum Thema „Semantischer Gerätebeschreibungssatz

für einen automatisierten Entwurf von Raumautomationssystemen“ gearbeitet, [DIB13]. Er

verfolgt damit das Ziel, eine ontologiebasierte Gerätebeschreibung zu entwickeln, die formale,

vereinheitlichte und erweiterbare Spezifikationen von GA-Geräten und -Komponenten enthält.

Diese dient damit der Vergleichbarkeit, zur Überprüfung der Interoperabilität und der Auswahl

der Komponenten für einen GA-Systementwurf. Die Anforderungen an diese Methode sind

nachfolgend aufgeführt:

• Formales, erweiterbares, herstellerunabhängiges und maschinenlesbares Format für

Spezifikationen,

• Vergleichbare Spezifikationen der Hardware und Software von Geräten, inklusive ihrer

Funktionalität und Interoperabilitäts-Möglichkeiten,

• Vereinheitlichung der anforderungskonformen Geräte,

• Unterstützung der effizienten und konsistenten Datenbanktechnologien für große

Gerätedatenbanken.

In seiner Ontologie-Architektur beschreibt Dibowski dazu vier Level, um diese Anforderungen

zu erfüllen. In Level 1 wird domänenspezifisches Vokabular, wie Funktionen und

Funktionsblöcke, verwendet. In Level 2 kommen vordefinierte plattformspezifische Daten, wie

Standards und Hardwareinformationen der Hersteller, hinzu. Im dritten Level werden plattform-

und herstellerspezifische Typen, wie Parameter, und in Level 4 die plattform- und

herstellerspezifischen Gerätebeschreibungen ergänzt, vgl. auch [DIKA11].

Der Ansatz von [ODK09] nutzt diese Methodik und setzt bei einer fertigen

Anforderungserhebung durch einen Systemintegrator auf, der die RA durch die

Toolunterstützung bereits durch Funktionsblöcke zu einem RA-Schema kombiniert hat, und

beschreibt den evolutionären Algorithmus zum Überführen des abstrakten RA-Schemas in den

detaillierten Entwurf. Das soll geschehen, indem die Menge an Geräten verschiedener

Hersteller funktionalen Profilen zugeordnet wird. Diese können den einzelnen

Funktionsblöcken, die der [VDI-RICHTLINIE 3813-2] entnommen sind, zugewiesen werden.

Der Algorithmus sucht die beste Auslegung der herstellerspezifischen Geräte, indem er die

Menge an Lösungsmöglichkeiten nach voreingestellten Kriterien überprüft und dabei die nicht

passenden Lösungsmöglichkeiten aussortiert. Das bedeutet, dass bei jedem Durchgang, als

eine Generation bezeichnet, die Lösungsmöglichkeiten nach guten und schlechten aufgeteilt

werden und nur die guten in die nächste Generation überführt werden. Die Aussortierung

endet, wenn eines der Endkriterien – vorgegebene Sortierdauer, Anzahl an Durchgängen oder

zu geringe Auswahl an Lösungsmöglichkeiten – erreicht wurde.

In [DIB17B] beschreibt Dibowski auf der Basis des Ontologie-Modells auch einen Ansatz, der

zur automatischen Konfiguration von Fehlererkennungs- und Diagnoseverfahren dient. In

[DIB17A] entwickelt Dibowski seinen Ontologie-Ansatz weiter und stellt ein semantisches

Modell zur Evaluation von Interoperabilität von GA-Systemen vor. Dieses Modell „Semantic

37


Interoperability Evaluation Model for Devices“ (SIEMoD) verwendet sechs Level der

Interoperabilität, die von Level 0, keine Interoperabilität, über technische, syntaktische,

semantische, konzeptionelle bis zur experimentellen Interoperabilität (Level 5) reichen. Durch

dieses Modell kann das Auswahlverfahren für Geräte beim Entwurf von GA-Systemen weiter

verbessert werden.

4.1.2 Das Projekt AUDRAGA

Das Projekt AUDRAGA (Automatische Installation drahtloser Systeme der

Gebäudeautomation) wurde von 2009 bis 2011 ebenfalls unter der Beteiligung der TU Dresden

als Nachfolgeprojekt von AUTEG durchgeführt. Sein Ziel ist die Erforschung von neuen

Methoden zur automatisierten Integration und Installation autonomer vernetzter

Sensorsysteme innerhalb großer GA-Systeme [ELE17@; WAG16A@].

Die Veröffentlichung [PDR+11] stellt die Toolkette des Projekts AUDRAGA vor, die einen

ganzheitlichen Ansatz zum Entwurf von drahtlosen GA-Systemen liefert. Ziel des Ansatzes ist

es, die Effektivität des Systems zu verbessern und die Kosten gering zu halten. Das Problem

der Interoperabilität zwischen Geräten verschiedener Hersteller soll ebenso adressiert werden

wie die spezifischen Belange von Signalübertragungen in kabellosen Systemen. Bestandteil

sollen weiterhin die Überprüfung und Sicherstellung der Qualität des Netzwerkes und die

Integration in den Entwurfsprozess zu einem ganzheitlichen Planungsansatz mit

entsprechender Toolunterstützung sein. Der ganzheitliche Ansatz und die Toolkette beginnen

in der Planung mit einem Systemintegrator für die GA, der in der Anforderungserhebung mit

dem Bauherrn und weiteren Fachplanern die Systemanforderungen feststellt. Diese werden,

wie bereits im AUTEG-Projekt vorgestellt, über einen plattformunabhängigen Grobentwurf zu

einem plattformspezifischen Detailentwurf ausgeplant. Bei der Geräte-Stationierung wird die

Toolkette um Signalübertragungs-Simulationen ergänzt, die dem Planer die optimalen

Standorte für Geräte bzw. die Forderung nach Signalverstärkern aufzeigen. Dies wird um die

Analyse der Übertragungsqualität ergänzt, die außerdem die Konnektivität und den

Energieverbrauch bestimmen und im besten Fall optimieren soll. Im letzten Schritt stehen die

Kommissionierung und die Diagnose des Systems im Betrieb.

In [OPK10] wird der Ansatz, das Optimierungsproblem bei der Suche nach geeigneten

Komponenten eines GA-Systems zu lösen, weiterentwickelt. Der Ansatz ist auch Bestandteil

des AUDRAGA-Projektes und basiert auf derselben Vorgehensweise wie im AUTEG-Projekt:

Anforderungserhebung, plattformunabhängiger Grobentwurf und plattformspezifischer

Grobentwurf. Untersucht wurde im Ansatz die Optimierung bei der Erstellung des

Detailentwurfes, in dem die neutralen Funktionsblöcke durch konkrete Komponenten ersetzt

werden. Diese Komponenten sind mit den verfügbaren funktionalen und nicht-funktionalen

Spezifikationen in einer Bibliothek (Component-Repository) zusammengefasst und lassen sich

den neutralen Funktionsblöcken zuordnen. Durch einen evolutionären Algorithmus soll dabei

eine optimale Kombination für ein vorgegebenes Funktionsblock-Schema gefunden werden.

Der Algorithmus hat die Ziele: die gestellten funktionalen und nicht-funktionalen

Anforderungen des vorgegebenen Schemas zu erfüllen, valide, angemessene und

verlässliche Lösungen zu finden, die optimal auch bezüglich der Feldbuskapazität sind. Valide

bedeutet in diesem Fall, dass alle Funktionsblöcke durch entsprechende konkrete

Komponenten ersetzt werden können. Die Übersetzung erfolgt durch die Verwendung von

funktionalen Profilen. Darüber hinaus müssen alle Eingänge auch verbunden sein.

Angemessen in diesem Sinne bedeutet, dass versucht wird, die Gerätekosten gering zu

38


halten, möglichst wenige Verbindungen zu schaffen (durch Nutzung von kombinierten

Geräten, die mehrere Funktionen bereitstellen) und möglichst wenige Hersteller

einzubeziehen, um den Konfigurationsaufwand zwischen Systemen verschiedener Hersteller

zu verringern.

4.1.3 Das Projekt SCUBA

Das SCUBA-Projekt (Self-organising, Cooperative, and robUst Building Automation) ist ein

internationales, durch die EU gefördertes Forschungsprojekt unter der Leitung des irischen

CORK Institute of Technology von 2011 bis 2014. Auch in diesem Projekt war u.a. die TU

Dresden beteiligt. Ziel des Projektes ist die Entwicklung von semantischen Modellen und

neuen Engineeringmethoden für robuste, selbstorganisierende und kooperierende Monitoring-

und Kontrollsysteme, um den Herausforderungen der Heterogenität und Interoperabilität zu

begegnen. Im Fokus stehen dabei verteilte und komplexe Systeme, die sich selbst

standardisieren, konfigurieren und von Fehlern befreien sollen, vgl. [EU 11@; WAG16B@]

In [GRL+13] wird die im SCUBA-Projekt entwickelte Werkzeugkette vorgestellt. Der Ansatz

beschreibt die Realisierung der GA in den Phasen Entwurf, Abnahme und Betrieb und

beinhaltet die Entwicklung einer Methode zur Ableitung von Systemspezifikationen mit

interoperablen Komponenten aus den Systemanforderungen. Hierzu werden eine Technik zur

optimalen Verteilung der Geräte für kabellose Systeme und die Selbstorganisation der Geräte

zur Erleichterung der Inbetriebnahme vorgestellt. Im SCUBA-Workflow werden in der

Entwurfsphase die Tools Systematic Engineering Tool, Wireless-Deployment-Tool und der

Coordination-Scheme-Editor genutzt. Im Betrieb werden dann eine Coordination Middleware

und ein Strategy Manager verwendet. Das Systematic-Engineering-Tool ermöglicht die

Spezifikation von Systemanforderungen für verschiedene Raumtypen und kreiert

verschiedene Entwürfe. Diese Entwürfe spezifizieren, welche Geräte in jedem Raum bzw.

jeder Gebäudezone installiert werden sollen. Auf der Grundlage dieser Informationen

unterstützt das Wireless-Deployment-Planning-Tool den Nutzer bei der Erstellung einer

robusten Kommunikation zwischen den Geräten und ergänzt die Systemspezifikationen um

die optimalen Einbaupositionen. Diese Information dient dann als Grundlage für den

Coordination-Scheme-Editor, der die Regeln für die Selbstorganisation (Parameter,

Kommunikationsaufbau), verwaltet und weitere Koordinations- oder

Kooperationsfunktionalitäten hinzufügt, wenn beispielsweise verschiedene

Herstellerkomponenten kommunizieren müssen. Die Coordination Middleware ist dann im

Betrieb dafür verantwortlich, dass die Selbstorganisation nicht nur in der ersten

Inbetriebnahme, sondern auch bei laufenden Veränderungen funktioniert. Im Strategy-

Manager ist für den Betrieb abschließend eine Überwachungsplattform bereitgestellt, die das

System in Echtzeit überwacht und zusätzliche Informationen, wie den Energieverbrauch,

sammelt.

In [PDR+13] wird die vorgestellte Werkzeugkette des SCUBA-Projektes detaillierter

beschrieben. Der Ansatz kombiniert den automatischen Entwurfsansatz der vorangegangenen

Projekte mit Methoden der Signalausbreitung und Bewertung der Leistung in den Entwürfen.

Der Ausgangspunkt und die Phasen der Realisierung sind mit denen aus [PDR+11] identisch.

Der erste Schritt ist die Analyse der funktionalen und nicht-funktionalen Anforderungen an das

GA-System. In der Anforderungsanalyse wird der Planer durch ein Tool unterstützt, das eine

detaillierte Ausarbeitung der Entwurfsplanung ermöglicht. Die Anforderungen sind

technologie- und herstellerunabhängig und basieren auf den Funktionen der Raumautomation.

39


Durch die Verwendung von Templates können Vorlagen schnell und effizient zu einem

Gesamtentwurf kombiniert werden. Regelbasiert wird der Planer durch die automatische

Empfehlung oder Ausblendung von Funktionen durch den Entwurf geführt. Gleichzeitig ist

jeder ausgewählten Funktion auch eine Energieeffizienzklasse zugewiesen, die dem Planer

angezeigt wird. Die ausgewählten Funktionen werden durch einen generativen Ansatz

automatisch in ein Automationsschema gemäß [VDI-RICHTLINIE 3813-2] überführt. Ziel der

Anforderungsanalyse ist eine fast vollständige Ausschreibung. Auf dieser Basis wird aus den

eingehenden Angeboten eine Firma entsprechend ausgesucht. Durch den bereits in [DPK10]

vorgestellten evolutionären Optimierungsansatz können die Geräte und Komponenten

ausgewählt und zu einem detaillierten, plattformspezifischen Entwurf zusammengestellt

werden. Ergänzt wird die Auswahl der Komponenten um die Montageplanung. Aufgrund der

drahtlosen Verbindung kommt der Montage eine besondere Bedeutung zu. Durch die

Verwendung von Simulatoren, die die Signalausbreitung analysieren können, und auf der

Basis der Gebäudeinformationen (Wände, Decken etc.) von IFC-Dateien wird ein weiteres

Optimierungsproblem aufgestellt. Durch die Verwendung von Zonen der Geräte, wie in

[OEKA13] beschrieben, werden Geräte so platziert, dass die bestmögliche Konnektivität

erreicht wird. Auch hier wird ein evolutionärer Algorithmus verwendet. Zur Sicherstellung der

Qualität des Netzwerkes wird die Toolkette um eine Qualitätsbewertung ergänzt, die die

Leistungsfähigkeit des Netzwerkes auf der Grundlage der Informationen aus der

Signalausbreitungsanalyse misst. Zur Inbetriebnahme unterstützt der Ansatz die Anbindung

an Datenbanken, um den Entwurf zu kommissionieren. Weiter können die vorliegenden

Informationen auch zur Diagnose des gesamten Systems im Betrieb verwendet werden

[PDR+13].

Der in [OEKA13] beschriebene Ansatz hat als Ziel die optimale Verteilung von kabellosen GA-

Geräten in einem Netzwerk. Dazu werden den einzelnen Geräten in einem Zone-Assignment-

Tool Einbauzonen zugewiesen. Diese Zonen können unterschiedliche Ausmaße haben. Eine

Punktzone ist eine bereits fest definierte Position, wie beispielsweise ein Heizungsventil. Eine

Zone in Form einer Linie kann beispielsweise einer Leiste Schalter oder Panels in einem

begrenzten Raum, beispielsweise neben der Tür in Armhöhe, zuweisen. Für die Montierung

von Lampen oder Präsenzmeldern an Decken wird eine rechteckige Zone verwendet. Den

größten Spielraum haben Geräte, die einer Zonenbox zugewiesen werden, wie beispielsweise

Repeater oder Gateways in einem Flur. Durch Verwendung des Zone-Assignment-Tools

können die Geräte den Zonen zugewiesen und mit dem Bauobjekt, in Form von BIM-Dateien,

kombiniert werden. Die Informationen über Wände, Decken und die eingeteilten Gerätezonen

werden dann in einem Simulator zur Simulation der Signalübertragungen getestet. Da es

bereits einige Simulatoren dafür gibt, werden eine generische Oberfläche und

Konvertierungsmöglichkeiten entwickelt, die den Einsatz mehrerer Simulatoren erlauben. Die

Optimierung erfolgt anhand der bereits in [OPK10] vorgestellten Methode. Hinzu kommt die

Konnektivität als weiterer Optimierungsfaktor speziell für kabellose GA-Systeme. Dazu werden

die Signalstärken in drei Entfernungszonen eingeteilt: gut, schlecht und keine Konnektivität.

Die minimale Konnektivität stellt eine Konnektivitätsbeziehung zwischen zwei Komponenten

her, die dann als Kommunikationspaar bezeichnet werden. Kommunikationspaare mit

gemeinsamen Komponenten werden als Kommunikationsgruppe gebündelt. So können

einzelne Kommunikationsgruppen unabhängig voneinander in ihren jeweiligen Gerätezonen

optimiert werden [OEKA13].

40


4.1.4 Das Projekt TOPAs

TOPAs (Tools for cOntinuous building Performance Auditing) begann 2015 als

Nachfolgeprojekt von SCUBA und läuft noch bis Oktober 2018. Es ist ebenfalls von der EU

gefördert und wird durch MOTOROLA SOLUTIONS ISRAEL LTD international, auch unter

Beteiligung der TU Dresden, koordiniert [EU 15@; KAN15@]. Ziel des Projektes ist die

Leistungsüberprüfung von Gebäuden in Bezug auf ihre Energieeinsparungen. Es soll im

Prinzip eine kontinuierliche Leistungsüberwachung für den Energieverbrauch und die Nutzung

von Energie in Gebäuden entwickelt werden, die toolgestützt durch ganzheitliche Ansätze die

Lücke zwischen vorhergesagtem und aktuellem Energieverbrauch schließt [WAG16D@].

In diesem Zusammenhang wird in [LAT+17] eine Analyse der Planungsfehler in der Praxis

beschrieben und es werden die fehlende Datenkonsistenz, fehlende oder schlecht definierte

System- und Prozessdokumentationen und fehlender Informationsaustausch zwischen

Beteiligten der Planung von GA als Hauptansatzpunkte herausgestellt. Um diesen Problemen

in der Planung zu begegnen, wird in diesem Ansatz eine generische Plattformlösung

vorgestellt, die eine zentrale Datenspeicherung besitzt. Diese integriert Informationen über die

Systemanforderungen, Informationen aus anderen Planungstools, Herstellerinformationen

über Geräte, BIM-Informationen über das Gebäude und Informationen aus Tools des Facility-

Managements für den Betrieb von Gebäuden. In dem vorgestellten Ansatz können diese

Informationen auf einer Plattform gesammelt, gespeichert und ausgetauscht werden.

Ein Teil des Projektes TOPAs wird in [KML+17] vorgestellt: eine toolgestützte Unterstützung

der integralen Herangehensweise in der Planung von GA-Systemen mit der Folge einer

Verbesserung des Tools AUTERAS. Deren Ziele waren: einfachere Handhabung durch

wissensbasierte Algorithmen im Hintergrund, sichtbare Kopplung aller Funktionen,

vorausschauende Aussage über künftige Planungsergebnisse, funktionale Planung

unabhängig von Plattform und Hersteller und schnelle Entwurfserstellung in wenigen Minuten.

4.1.5 Ansatz einer GA-Toolkette

Neben den charakterisierten Ansätzen um die vier großen Projekte gibt es einen weiteren

Ansatz, der in [YZM+12] vorgestellt wird. Sein Ziel ist es, die Lücke zwischen Design-Tools,

wie Simulink oder Modelica, und plattformspezifischen Systemtools zu schließen. Der Fokus

dieses Ansatzes liegt darin, die heterogenen Datenquellen als Ein- und Ausgang zu nutzen

und einen automatisierten Übergang zwischen der Toolkette ohne Informationsverlust zu

gewährleisten. Der Entwurfs-Workflow wird in ein Front-End und ein Back-End geteilt. Das

Front-End wird genutzt, um das GA-System inklusive der Kontrollalgorithmen und des

Umgebungsverhaltens in Tools, wie Simulink oder Modelica, zu modellieren. Das Back-End

beinhaltet ein Toolset, das mit den Regelfunktionen und einer Auswahl an vorhandenen

Ressourcen automatisch die optimale Implementation herausfiltert. Zum Austausch zwischen

Front- und Back-End wurde ein Austauschformat entwickelt. Das Modell wird im Front-End

eingelesen, ins Austauschformat transformiert und dort durch das Back-End in die

entsprechende Plattformsprache übertragen. Dabei stehen die Regelfunktionen im

Vordergrund.

4.1.6 Bewertung der vorgestellten Ansätze

Im Rahmen des Forschungsprojektes AUTEG wurden sehr viele Aspekte der Planung und

Realisierung von GA-Systemen betrachtet und entwickelt und daher haben die

41

4.2 Toolgestützte Lösungsansätze

Forschungsergebnisse dieses Projektes eine hohe Relevanz bezüglich dieser Arbeit. Die

dargestellten Ansätze erfüllen ein breites Spektrum der aufgeführten Anforderungen und

können durch den erfolgreichen Einsatz, wie in einem Referenzprojekt bei Runde oder der

verfügbaren Software „AUTERAS“ von Herrn Prof. Dr. Kabitzsch und seinem Institut der TU

Dresden, auch untermauert werden. Den Ansätzen ist die Anforderungserhebung gemein, die

in der Hauptsache in die Forschungsarbeiten von Runde fällt. Durch die konsequente Nutzung

innerhalb eines Tools ist auch die Datenkonsistenz durchgängig gegeben, weiterhin sind

Möglichkeiten zur Überprüfung der Wissensbasis auf Inkonsistenzen und Redundanzen

beschrieben. Die Ansätze decken den Planungsprozess, angefangen beim Systemintegrator

bzw. Fachplaner der GA über das Ausschreibungsverfahren bis hin zur Auswahl der

Komponenten verschiedener Hersteller unter Berücksichtigung der Interoperabilität, ab. Die

Ansätze sind dem integrierten GA-Planungsprozess zuzuordnen, da sie einen Fachplaner für

die GA und einen Systemintegrator zur Pflege und Wartung der aufwendigen Wissensbasis

benötigen, vgl. [DKR+07]. Die Energieeffizienz ist nur durch die Angabe der

Energieeffizienzklassen bei den einzelnen Funktionen der RA am Rande thematisiert, Die

Bestandsdokumentation entspricht im Wesentlichen den Vorgaben aus der Norm

[DIN EN ISO 16484-1].

Die Projekte AUDRAGA, SCUBA und TOPAs bauen grundsätzlich auf dem gleichen Verfahren

wie das AUTEG-Projekt auf und verbessern den Ansatz gerade aus Sicht der

Selektierungsalgorithmen und aufgrund der Erweiterung der Toolketten um die Bedarfe der

drahtlosen Komponenten. Ganz deutlich wird dabei auch der Fokus der eigenständigen bzw.

vereinfachten Parametrierung des Systems. Im Rahmen dieser Projekte hat sich die

Ausgangslage, dass der integrierte GA-Planungsprozess inklusive der Notwendigkeit von

Systemintegratoren und GA-Fachplanern als Grundlage genommen wird, nicht verändert.

Auch die Erkenntnisse dieser Projekte sind in die Software „AUTERAS“ integriert worden, die

im folgenden Kapitel mit weiteren toolgestützten Lösungsansätzen verglichen wird.

Der von den Projekten unabhängige Ansatz in [YZM+12] verbindet verschiedene

Planungstools und legt den Fokus auf die richtige Überführung der Regelfunktionen vom

Planungstool zu einem Auswahltool für die Komponenten. Eine Abgrenzung zu den Arbeiten

aus dem AUTEG-Projekt besteht leider nicht. Der Ansatz geht ebenfalls vom integrierten GA-

Planungsprozess aus, da die Entwurfstools Fachplaner als Zielgruppe haben. Bezüglich der

Datenkonsistenz werden die wesentlichen Informationen aus den Entwurfstools übernommen

und weiterverwendet. Die Energieeffizienz und auch die Bestandsdokumentation sind keine

Bestandteile dieses Ansatzes und es wird lediglich die Phase der Planung berücksichtigt.

Im Folgenden wird die Software „AUTERAS“, als gemeinsame Forschungsleistung der

aufgezeigten Projekte, mit weiteren toolgestützten Lösungsansätzen in Hinblick auf den

Anforderungskatalog verglichen.


Die aufgezeigten vielfältigen Anforderungen an die Planung, Auslegung und den Betrieb von

GA-Systemen bieten ein großes Feld für vor allem softwareseitige Unterstützung. Im

Folgenden werden die bisherigen Hauptlösungssysteme vorgestellt und in Tabelle 3

miteinander verglichen.

a) AUTERAS

42


Die Software AUTERAS ist das Ergebnis der Forschungsarbeit von Herrn Prof. Kabitzsch und

seinem Forschungsteam, vgl. [KAB14]. Mit diesem Tool ist es möglich, RA-Funktionen

regelbasiert zusammenzustellen und Räumen im Gebäude zuzuweisen. Hersteller haben die

Möglichkeit, ihre Geräte in einer Herstellerdatenbank zu hinterlegen, damit Kunden mit der

Software auf diese Daten zugreifen können und die Software Vorschläge zu Geräten

unterbreiten kann. Zudem kann diese Software die Energieeffizienzklasse der einzelnen

Funktionen bzw. des GA-Systems ermitteln [KAB16@; KAB17@], eine Berechnung des

Einsparpotenzials ist jedoch nicht möglich. Aufgrund der konsequenten Nutzung der

verschiedenen Optionen innerhalb des Tools ist die Datenkonsistenz gewährleistet. Inwiefern

eine Inbetriebnahme und Parametrierung auf der Grundlage der vorhandenen Informationen

möglich sind, bleibt offen. Die Software ist grundsätzlich für LON- und ENOcean Systeme

ausgelegt und die Hauptnutzergruppe sind Fachplaner, Systemintegratoren und

Gerätehersteller. Damit gehen die Software wie auch die Forschungskonzepte von einem

bereits etablierten Fachplaner der GA aus. Die Software basiert somit auch auf dem

integrierten GA-Planungsprozess. Eine Überprüfungsmethode innerhalb der Software ist nicht

gegeben. Im Rahmen der Anforderungserhebung ist diese Software für die Übersetzung der

Wünsche und Anforderungen eines Bauherrn an den Architekten im Rahmen der

Anforderungserhebung eher ungeeignet, da sie die Fachkompetenz eines GA-Fachplaners

erfordert.

b) KNX ETS

Das KNX ETS Tool ist ein systembegleitendes Installationswerkzeug, vgl. [KNX16C@;

KNX16D@]. ETS steht für Engineering Tool Software und dient der Planung und Konfiguration

intelligenter Haus- und Gebäudesystemtechnik mit dem KNX-System. Der Nutzer kann ein

Gebäude bis auf Raumebene zusammenstellen und Geräte aus dem Herstellerkatalog

einfügen. In diesem Katalog können Hersteller ihre Geräte auflisten und mit wichtigen

Installationsparametern hinterlegen. Der Nutzer kann dann die gewählten Geräte miteinander

verbinden und – sofern es sich um ein KNX-System handelt – dieses dann zur Parametrierung

des realen GA-Systems nutzen. Solange die Planung innerhalb des KNX-Systems bleibt, ist

dieses Planungstool gut geeignet, ein Gebäude mit einem GA-System auszulegen. Auch die

Datenkonsistenz ist grundsätzlich garantiert, da zur Planung fast keine weiteren Tools

notwendig sind. Die Herstellerneutralität ist nur bedingt gegeben, da der Funktionsumfang nur

für Geräte des KNX-Systems vollständig gewährleistet ist, vgl. [KNX17@]. Die Interoperabilität

der einzelnen Funktionen und Geräte ist über das KNX-System festgelegt. Bezüglich der

Energieeffizienz kann weder eine Einsparung berechnet noch die Energieeffizienzklasse

angegeben werden. Auch dieses Tool geht von einem integrierten GA-Planungsprozess aus

und bedarf der Unterstützung von Fachplanern.

c) TRIC

TRIC MSR Software ist ein Softwarewerkzeug zur Planung, Ausführung und Dokumentation

von Mess-, Steuer- und Regelungstechnik (MSR) [MER16@]. Es dient zur Erzeugung von

Automationsschemata und Funktionslisten nach [VDI-RICHTLINIE 3814-1] bzw.

[DIN EN ISO 16484-1]. Die Zielgruppe dieser Software sind Fachplaner, die mit dieser

Software Unterstützung bei der Schaltplan- oder Automationsschema-Erstellung erhalten. Für

die Nutzung ist eine entsprechende Fachausbildung notwendig. Bezüglich der

43


Bestandsdokumentation ist dieses Tool geeignet, die entsprechenden Funktionsschemata und

Funktionslisten zu generieren. Eine Angabe der Energieeffizienzklasse oder eine Berechnung

der Energieeinsparungen durch die geplante GA ist nicht möglich. Die TRIC MSR Software ist

ein reines Fachanwendungsprogramm und kann nur für die Planung eines GA-Systems

verwendet werden. Diese Software unterstützt GA-Fachplaner im integrierten GA-

Planungsprozess.

d) BACS Planning and Design Tool

Das von der polnischen AGH University entwickelte Werkzeug „BACS Planning and Design

Tool“ dient in erster Linie dazu, die Energieeffizienz eines Gebäudes durch Hinzufügen

diverser GA-Funktionen bereits in der Planungsphase zu bestimmen, vgl. [GROŻ16]. Weiterhin

soll das "Functional-Utility-Program" mit den GA-Funktionen befüllt werden und damit Zeit und

Kosten bei der Planung einsparen, indem nur die minimal benötigten Anforderungen zum

Erreichen der gewollten Energieeffizienzklasse gefunden werden können.

Die Anforderungserhebung ist auf Gebäudebesitzer, Architekten, Ingenieure, Designer und die

Öffentliche Verwaltung zugeschnitten und soll von diesen bedient werden. Dazu ist das

Werkzeug mit HTML 5 und PHP Standard programmiert worden und soll den Bediener mit

einem "Projekt Wizard" durch die Planung führen. Anhand der ausgewählten Funktionen soll

dann eine Berechnung der Energieeffizienzklasse automatisch erfolgen. In einer durch

"andere Softwarewerkzeuge" durchgeführten Simulation der Energieeffizienz wird dem

Bediener ggf. ein verbesserter Vorschlag für andere GA-Funktionen unterbreitet. Der "Projekt-

Wizard" ist eine regelbasierte Abfrage von Funktionen und deren Parametern.

Aufgabe des vorgestellten Werkzeugs ist die Bestimmung der Energieeffizienz eines

Gebäudes. Das Werkzeug verwendet die Zuordnung von Funktionslisten und

Energieeffizienzklassen, um eine Energieeffizienzklasse des Gebäudes zu generieren, und

soll ebenfalls das Einsparpotenzial der GA bezogen auf die Nutzung des Gebäudes ohne GA

gemäß GA-Faktorverfahren berechnen. Das GA-Faktorverfahren gemäß der [DIN EN 15232]

geht davon aus, dass der Typ eines Gebäudes grundsätzlich klar ist und auch der

Energieverbrauch des Gebäudes berechnet werden kann. Das GA-Faktorverfahren berechnet

dann eine Bezugsgröße, die das relative Einsparpotenzial bestimmt. Dazu ist jedoch die

Bestimmung des Gebäudetyps eine notwendige Grundlage, da das Nutzerverhalten gemäß

dieser Methode nur verallgemeinert auf Erfahrungswerten beruht und nicht manuell

simulierbar ist.

Das Werkzeug ist auf die Ermittlung der Energieeffizienzklasse eines Gebäudes ausgelegt

und daher nicht zur Planung von GA-Systemen geeignet. Weiter sind keine

Dokumentationsmöglichkeiten sowie die Möglichkeiten der Überprüfung des Gesamtsystems

hinterlegt.

Anforderungen AUTERAS KNX

ETS TRIC BACS

Anforderungserhebung

unterstützen X X - -

Bestands-Dokumentation

erzeugen X X X -

44


Datenkonsistenz

sicherstellen X X - -

Überprüfung der Qualität in

Planung/Installation/Betrieb - / - / - - / X / X - / - / - - / - / -

Angabe der

Energieeffizienz-Klasse/-

Berechnung

X / - - / - - / - X / X

Unterstützter GA-

Planungsprozess

Integrierter GA-Planungsprozess

mit GA-Fachplaner Gewerkegetrennter

GA-Planungsprozess

X = Anforderung erfüllt

- = Anforderung nicht erfüllt

Tabelle 3: Übersicht der bestehenden Engineeringansätze

Im nächsten Abschnitt wird der bestehende Handlungsbedarf an einen Engineeringansatz, der

durchgängig und integral den konventionellen Bauprozess mit dem gewerkegetrennten GA-

Planungsprozess unterstützt, abgeleitet und ein Lösungsansatz, der diesem Handlungsbedarf

begegnet, vorgestellt.

4.3 Handlungsbedarf hinsichtlich eines durchgängigen Engineeringansatzes

Wie anhand der Tabelle 3 zu erkennen ist, ist eine vollständige Erfüllung der Anforderungen

an einen Lösungsansatz für das Engineering eines GA-Systems durch die aufgeführten

Lösungsansätze nicht gewährleistet. Die hauptsächliche Lücke (Tabelle 3, grau hinterlegt) in

den bestehenden Lösungsansätzen besteht darin, dass bei fast allen Ansätzen nur der

integrierte GA-Planungsprozess, und damit einhergehend die Notwendigkeit eines GA-

Fachplaners, und nicht der gewerkegetrennte GA-Planungsprozess, Berücksichtigung findet.

Die Fachplaner der GA konnten sich nach [BEKN16] bisher in der Praxis noch nicht als

eigenständiges Gewerk etablieren und somit findet die softwareseitige Unterstützung eines

Fachplaners für GA und dem damit verbundenen integrierten GA-Planungsprozess wenig

Anwender. Es besteht daher Handlungsbedarf in der Phase der Planung beim

gewerkegetrennten GA-Planungsprozess und in dem Schritt der Anforderungserhebung beim

Bauherrn, wenn also die Wünsche des Bauherrn in die Planung konkreter Geräte und Anlagen

übersetzt werden müssen. Daher sind die vorgestellten Ansätze zwar für die Seite der

Fachplaner und den integrierten GA-Planungsprozess sehr gut ausgearbeitet, doch

überfordert die umfangreiche Wissensbasis den Bauherrn und Architekten im

gewerkegetrennten GA-Planungsprozess, die keine eigene Fachkompetenz auf diesem

Gebiet haben. Auch berücksichtigen die angesprochenen Ansätze nicht, dass die Ausführung

und Installation gewerkegetrennt erfolgt. Weiterhin fehlt häufig eine Überprüfungsmöglichkeit,

um Fehler im System, wie beispielsweise Redundanzen oder fehlende Verbindungen, zu

erkennen. Auch die Möglichkeit, verschiedene Varianten von GA-System-Auslegungen

einzeln zu betrachten und zu analysieren, fehlt. Auf den Forschungsarbeiten von Runde auf

dem Gebiet der Anforderungserhebung kann grundsätzlich weiter aufgebaut werden.

45

4.3 Handlungsbedarf hinsichtlich eines durchgängigen Engineeringansatzes

Das „BACS Planning and Design Tool“ aus [GROŻ16] kann zwar den gewerkegetrennten GA-

Planungsprozess unterstützen, stellt aber kein durchgängiges Planungswerkzeug für GA-

Systeme zur Verfügung. Der Ansatz bietet jedoch bereits eine gute Lösungsmöglichkeit zur

Energieeffizienzberechnung, welcher für weitere Lösungsmöglichkeiten verwendet werden

kann. Daher ist der Punkt der Energieeffizienz hinsichtlich des Anforderungskataloges erfüllt

und wird im Rahmen dieser Arbeit nicht weiter betrachtet.

Um den weiteren Anforderungskatalog zu erfüllen, ist grundsätzlich zu fordern, dass das

Engineering über alle Phasen des Lebenszyklus durchgängig ist, ähnlich wie es in [JCS+13]

für automatisierte industrielle Anlagen beschrieben wird.

Die große Herausforderung bei GA-Systemen liegt in den komplexen Zusammenhängen

zwischen Funktionen und ihrer Funktionslogik, die auf eine Infrastruktur, bestehend aus

unterschiedlichsten Gebäudearten und -formen, unter Berücksichtigung des physikalischen

Verbindungsaufbaus ausgelegt werden müssen. Die Abbildung dieser komplexen

Zusammenhänge in einem sehr hohen Detaillierungsgrad ist grundsätzlich in einem

gemeinsamen Modell möglich, ähnlich wie [ERZ14] dies in der modellbasierten

Produktentwicklung aufzeigt. Die Produktentwicklung ist ebenfalls von verschiedenen

Disziplinen (Mechanik, Elektronik, Software etc.), föderierten und dislozierten Unternehmen

einer Lieferkette und einer integralen Betrachtung des Produktlebenszyklus geprägt. Die

Ausgangslage ist vergleichbar, da die Kundenanforderungen die Produktkomplexität durch

zunehmende Diversifikation und Variation steigen lassen.

Auf die Frage, was ein Modell ist, hat der deutsche Philosoph Herbert Stachowiak in [STA73]

1973 eine bis heute grundlegende Modelltheorie entwickelt. Auf eine exakte

Begriffsbestimmung verzichtet er dabei, da der Begriff „Modell“ sehr stark abstraktionsfähig ist

und eine Begriffserklärung derart allgemein sein müsste, dass der „zu gewinnende

allgemeinste Modellbegriff […] der inhaltsärmste sein“ würde [STA73, S. 130]. Daher definiert

Stachowiak stattdessen die Merkmale eines Modells und fasst diese unter drei

Hauptmerkmalen zusammen: das Abbildungsmerkmal, das Verkürzungsmerkmal und das

pragmatische Merkmal:

• Das Abbildungsmerkmal schreibt einem Modell die Eigenschaft zu, dass es stets

Modell von etwas (Abbildungen, Repräsentationen natürlicher oder künstlicher

Originale etc.) ist.

• Das Verkürzungsmerkmal enthält das Theorem, dass ein Modell nicht alle

Eigenschaften und Attribute eines Originals enthält, sondern lediglich diejenigen, die

dem Nutzen des Modells dienen.

• Das pragmatische Merkmal ordnet Modellen nicht per se ihren Originalen zu, sondern

erklärt, dass Modelle ihre Ersetzungsfunktion für bestimmte Subjekte, innerhalb einer

bestimmten Zeit und unter Einschränkung bezogen auf die Nutzung des Modells

erfüllen. Dieses Merkmal berücksichtigt also die Frage, für wen, wann und wozu ein

Modell bezüglich seiner spezifischen Funktionen gedacht ist.

In den deutschen Richtlinien ist diese Modelltheorie zu einer allgemeinen Definition

zusammengefasst: Ein Modell ist die „Abbildung eines Systems oder Prozesses in ein anderes

begriffliches oder gegenständliches System, das auf Grund der Anwendung bekannter

Gesetzmäßigkeiten, einer Identifikation oder auch getroffener Annahmen gewonnen wird und

das System oder den Prozess bezüglich ausgewählter Fragestellungen hinreichend genau

abbildet“ [VDI/VDE-RICHTLINIE 3681, S. 4].

46


Modellbasiertes Engineering ist aufgrund dieser Merkmale auch kein neuer Begriff, sondern

wurde vornehmlich im Softwareengineering entwickelt [POH12] und hat auch in der

produzierenden Industrie Einzug gehalten, vgl. [SAB17]. Die Vorteile des modellbasierten

Engineerings sind die Abbildungs- und Vereinfachungsfunktionalitäten, die auch sehr

komplexe Zusammenhänge in einem Modell darstellen können. Das Modell kann auf das

Wesentliche in Bezug auf eine Fragestellung reduziert werden, wodurch gleichzeitig der

Aufwand der Modellerstellung reduziert wird. Im Engineering werden daher sehr häufig

Modelle verwendet, um Fragestellungen genauer zu beleuchten. Christiansen und Hoernicke

haben sich daher intensiver mit Modellen im Rahmen der Automatisierung beschäftigt und

festgestellt, dass die Erstellung von mehreren Modellen zu einer Anlage das Potenzial für

Synergieeffekte hat, indem anstelle der Erarbeitung von mehreren Teilmodellen ein

übergeordnetes Gesamtmodell erstellt wird. Dieser Ansatz wird als das Top-Level-Topologie

(TLT)-Modell in [CHF14A] beschrieben und lässt sich ebenso wie das modellbasierte

Engineering auf das Engineering von GA-Systemen übertragen.

Im Sinne der vorliegender Arbeit wird der Begriff „modellbasiert“ und „Modell“ als Abbild eines

realen (noch zu planenden) GA-Systems verstanden. Es enthält die Eigenschaften eines GA-

Systems und seiner Funktionen, die notwendig sind, um damit den Anforderungen an den

Engineering-Prozess gerecht zu werden, und kann durch eine gemeinsame Datenbasis über

mehrere Phasen hinweg verwendet werden. Ein modellbasierter Lösungsansatz gewährleistet

die Handhabung der Komplexität und kann auch entsprechend heterogene Datenquellen (wie

beispielsweise Infrastrukturdaten) berücksichtigen. Weiterhin können durch die durchgängige

Verwendung eines Modells Datenkonsistenz und Datenvollständigkeit sichergestellt werden,

da alle Informationen in einem Modell abgebildet werden können. Das Modell kann nach der

Erstellung als Grundlage für die Überprüfung und auch die Dokumentation dienen. Vorgabe

an das Modell muss dafür sein, dass die Informationen in diesem Modell vollständig hinterlegt

werden und bei Verwendung des Modells keine Informationen verloren gehen können. Als

Grundlage für den Aufbau des Modells müssen die Anforderungserhebung zwischen Bauherrn

und Objektplaner und die Gebäudedaten dienen, da sie die Basis der weiteren Planung und

späteren Realisierung sind.

47

4.4 Vorstellung des durchgängigen, modellbasierten Engineeringansatzes


Um ein optimal wirtschaftliches, funktionales und qualitätsgesichertes GA-System zu erstellen,

müssen die Wünsche des Bauherrn an das GA-System mit den komplexen und vielfältigen

Funktionen verknüpft und unter Berücksichtung des gewerkegetrennten GA-

Planungsprozesses auf das auszustattende Gebäude ausgelegt werden.

Der Engineeringansatz ist in einem Workflow in Abbildung 12 dargestellt.

Abbildung 12: Der Engineeringansatz für die GA

Die anfänglichen Informationen zu Beginn des GA-Planungsprozesses bestehen aus den

Infrastrukturdaten in Form von einem Grundriss des auszurüstenden Gebäudes und den

Wünschen des Bauherrn bezüglich der GA- und RA-Funktionen, welche installiert werden

sollen. Um die Anforderungserhebung zwischen Bauherrn und dem Objektplaner zu

unterstützen, muss in einem ersten Schritt (Abbildung 12, 1.) eine Strukturierung der

Gebäudedaten vorgenommen werden, um diese innerhalb eines Modells verwenden zu

können. In Kapitel 5 wird die Methode zur Infrastruktursegmentierung vorgestellt. Das Ziel der

Struktursegmentierung ist eine Ortsstruktur, welche die Gebäudestruktur hierarchisch

abbildet.

48


Im Rahmen der GA-Anforderungserhebung (Abbildung 12, 2.) müssen die Funktionen zu

Funktionsstrukturen, wie in Absatz 2.3.1 vorgestellt, verknüpft werden und mit der Ortsstruktur

anhand der Wünsche des Bauherrn miteinander zu einem Engineering-Modell verbunden

werden. Die automatische Erstellung von Modellen stellt dabei ein aufwendiges und sich

wiederholendes Verfahren dar. Dazu ist in [PUN15] für den Steuerungscode von Anlagen eine

Methode beschrieben, die als Ziel eine automatische Simulationsmodellerstellung hat. Dieses

Vorgehen wurde auf das durch die Helmut-Schmidt-Universität (HSU) entwickelte

Engineering-Werkzeug zur Unterstützung der Anforderungserhebung übertragen und wird in

Kapitel 6 vorgestellt. Ziel dieses Werkzeugs ist ein Engineering-Modell, welches das GA-

System durch seine Orts- und Funktionsstruktur abbildet. Die automatische Überführung der

Ortsstruktur in das Engineering-Werkzeug wird in Abschnitt 6.3 erläutert.

Ziel des Engineeringansatzes ist, die Unterstützung des gewerkegetrennten GA-

Planungsprozesses. Daher muss das Engineering-Modell zunächst wieder in Teilmodelle

(Abbildung 12, 3.) zerlegt werden können, um die Ausschreibung und Feinausplanung in den

Gewerken getrennt zu ermöglichen. Dazu wird in Kapitel 7 beschrieben, wie aus dem

Gesamtmodell des GA-Systems Teilmodelle, wie bei Christiansen in [CHF14A] aufgezeigt

wurde, erzeugt werden, um Funktionslisten für die einzelnen Gewerke zu erstellen.

Erst nach der gewerkegetrennten Ausschreibung und Feinausplanung durch die Gewerke

(Abbildung 12, 4.) stehen die zu installierenden Produkte des GA-Systems fest. Eine weitere

wichtige Information für das GA-System ist die Produktstruktur. Die Produktstruktur legt die

physikalische Verbindung der Funktionen fest. Im Gegensatz dazu beschreibt die

Funktionsstruktur nur die logischen Verbindungen der Funktionen. Zur Produktstruktur gehört

auch die Information, welche Funktionen eventuell gemeinsam in einem Gerät verbaut sind.

Die Erweiterung des Engineering-Modells um die Produktstruktur zu einem GA-System-

Modell, (Abbildung 12, 5.), wird in Absatz 6.4 beschrieben. Dieses GA-System-Modell enthält

dann alle Informationen zum GA-System und wird durch seine Orts-, Funktions- und

Produktstruktur beschrieben. Aus diesem GA-System-Modell können dann wiederum

Teilmodelle erstellt werden (Abbildung 12, 6.), um diese inklusive der Produktinformationen in

einer Simulation (Abbildung 12, 7.) zu überprüfen. Dazu können Analysen von einzelnen

Elementen der Ortsstruktur, der Funktionsstruktur oder der Produktstruktur eine Auskunft über

die Leistungsfähigkeit des GA-Systems geben. Weiterhin ist die Teilmodellerstellung für die

gewerkegetrennte Installation und Inbetriebnahme nützlich, um Informationen nicht nur zu den

zu installierenden Geräten und Verbindungen, sondern auch zu den Schnittstellen zu anderen

Gewerken bereit zu stellen.

Eine Simulation ist eine Methode zur Überprüfung von Systemen, um wie bei einer virtuellen

Inbetriebnahme ein System vorab auf Fehler zu untersuchen. Puntel-Schmidt zeigt in [PUN17]

auf, wie durch die Simulation der Steuerungscode von Fertigungsanlagen vorab getestet

werden kann, um Fehler bereits vor der Inbetriebnahme festzustellen. Wenn der Bauherr

verschiedene Varianten von GA-System-Auslegungen erwägt, können diese durch die

automatische Modellerzeugung und die Simulation getestet werden. Die Ergebnisse der

Simulation können dann als Entscheidungsgrundlage für den Bauherrn dienen. Neben der

Fehlersuche und der Überprüfung kann eine Simulation auch dazu dienen, ineffiziente

Überdimensionierungen zu verhindern, vgl. [KRA13, S. 10].

Weiterhin kann das GA-System-Modell nach der gewerkegetrennten Installation auch als

Grundlage für eine automatische Parametrierung (Abbildung 12, 8.) dienen, um den

aufwendigen Prozess der einzelnen Programmierung der Buscontroller zu erleichtern und Zeit

49


einzusparen. Dazu ist die vorhergehende Simulation nicht zwingend erforderlich, aber nützlich.

Sollte eine Korrektur des realen GA-Systems notwendig werden, z.B. durch den Austausch

von Geräten oder die Änderung von Funktionen, beispielsweise eines Schalters, kann im GA-

System-Modell diese Änderung vorgenommen und durch erneute Parametrierung am realen

GA-System umgesetzt werden.

Die Simulation und die Parametrierung wurden durch die Firma iQST entwickelt, sind nicht

Werk der Autorin und werden in Absatz 6.5 zur Komplettierung der Beschreibung des

Engineeringprozesses beschrieben. Im Rahmen des gemeinsam mit der HSU durchgeführten

Projektes „Gebäude besser vernetzen“ konnte das an der HSU unter Beteiligung der Autorin

entwickelte Engineering-Werkzeug zur Unterstützung der Anforderungserhebung gemeinsam

mit der Simulation und der Parametrierung erfolgreich getestet werden, siehe [GDS+16B].

Im laufenden Betrieb des GA-Systems kann auf der Grundlage des Systemmodells auch die

laufende Fehlerüberwachung stattfinden, um Fehler im System schnell zu identifizieren. Dies

ist ebenfalls durch die Verwendung von nach Räumen oder Bereichen getrennten

Teilmodellen möglich, in denen eine fokussierte Betrachtung des GA-Systems erfolgt. Dies

kann als Grundlage der Fehlereingrenzung bei großen Systemen im Betrieb dienen.

Dieser skizzierte Workflow ermöglicht einen durchgängigen und ganzheitlichen

Engineeringsansatz, der den gewerkegetrennten GA-Planungsprozess unterstützt.

Die These, dass für das Engineering von GA ein integrales, durchgängiges und

modellbasiertes Engineering zur Unterstützung der Planung, Installation und Nutzung eines

GA-Systems einen verbesserten Lösungsansatz darstellt, wird im weiteren Verlauf dieser

Arbeit untersucht.

50

5 Methode der Infrastruktursegmentierung


In diesem Kapitel wird eine Methode zur Infrastruktursegmentierung vorgestellt, die als

Planungsgrundlage für die Anforderungserhebung dient. Dazu werden zunächst das

Schalenmodell und die Methode vorgestellt. Anschließend werden die vorhandenen digitalen

Datenaustauschformate von Gebäuden analysiert und auf Umsetzung bezüglich der Methode

untersucht. Zum Schluss wird eine Möglichkeit zur Nutzung der digitalen Gebäudedaten als

Eingangsgröße des Engineering-Werkzeugs, das in Kapitel 6 vorgestellt wird, aufgezeigt.

5.1 Infrastrukturdaten als Basis der Planung

Zu Beginn eines Bauprozesses tritt der Bauherr mit seinen Wünschen und Vorstellungen vom

Gebäude an den Objektplaner heran und erstellt gemeinsam mit diesem zuerst einen

Grundriss des Gebäudes. Der Grundriss eines Gebäudes ist damit die Grundlage, auf der das

Gebäude in den Gewerken weiter ausgeplant wird.

Die Aufteilung des Gebäudes in Räume, Flure usw. ist die Grundlage, auf der ein GA-System

auf ein Gebäude ausgelegt wird. Grundsätzlich können Gebäude als Unikate verstanden

werden, die nach den Wünschen jedes Bauherrn und den architektonischen Umsetzungen der

Architekten geplant werden. Die Herausforderung besteht darin, dass frei gestaltbare

Gebäude die Planungsgrundlage für einen allgemeingültigen Engineeringansatz darstellen

sollen. Um dieser Anforderung gerecht zu werden, braucht es eine Methode, die Informationen

über ein Gebäude, egal welchen Ausmaßes, zu einer allgemeingültigen Ortsstruktur

überführen kann. Eine Ortsstruktur strukturiert ein Gebäude durch die Aufteilung des

Gebäudes in kleinere Elemente. Ziel ist es, diese Ortsstruktur als Basis für die

Anforderungserhebung zu nutzen.

5.1.1 Das Schalenmodell

Um die Ortsstruktur eines beliebigen Gebäudes nach einer allgemeingültigen Vorgehensweise

zu erstellen, wurde in der [VDI-RICHTLINIE 3813-1] ein solches Vorgehen anhand des

Schalenmodells beschrieben. Das Schalenmodell ist in Abbildung 13 dargestellt und

strukturiert Gebäude nach Segmenten, Räumen, Bereichen, Gebäude, Liegenschaft und

Liegenschaftsportfolio.

Abbildung 13: Schalenmodell der [VDI-RICHTLINIE 3813-1]

51


Das kleinste Strukturelement eines Gebäudes stellt das Segment dar. Das Segment ist Teil

eines Raumes und kann mit anderen Segmenten einen Raum bilden. Beispiele für Segmente

können einzelne Arbeitsplätze in Doppel- oder Großraumbüros sein. Häufig wird in Neubauten

auch von einem sogenannten Raster- oder Achsensegment gesprochen. Diese

Segmenteinteilung orientiert sich dabei am Fensterraster. Grundsätzlich ist das Segment

jedoch frei einteilbar. Das Segment ist die kleinste strukturelle Einheit, in der die Zuordnung

von RA-Funktionen möglich ist. Dabei benötigen Segmente keine räumliche Trennung durch

Wände, sondern können innerhalb eines Raumes flexibel nebeneinander eingeplant werden.

Dies ermöglicht eine wirtschaftliche und flexible Nutzung der GA, da diese gerade in großen

Räumen nur da geplant werden muss, wo sie auch gebraucht wird.

Ein Raum kann aus einem oder mehreren Segmenten bestehen und ist meist mit

Umschließungsflächen, wie beispielsweise Wänden oder Decken, umgeben. Auch

organisatorisch können Räume voneinander getrennt werden, beispielsweise in einem

Großraumbüro. So können mehrere Arbeitsplatzsegmente zu einem Teilraum

zusammengefasst werden und sich damit organisatorisch von anderen Teilräumen

abgrenzen. Eine grundlegende Definition eines Raumes findet sich jedoch nicht in einer Norm.

Die nächstgrößere Schale bildet der Bereich. Dieser ist ebenso wie der Raum nicht näher

definiert und kann sowohl funktional als auch organisatorisch oder örtlich mindestens einen

oder mehrere Räume zusammenfassen. Beispiele dafür können Etagen, Gebäudetrakte oder

Abteilungen sein.

Der Definitionsspielraum dient dazu, dass den Objektplanern und Architekten die

größtmögliche kreative Freiheit gelassen wird und jede Bauwerkstruktur trotzdem in das

Schalenmodell überführt werden kann.

Die nächste Schale, das Gebäude an sich, umschließt die Bereiche und bildet ein

abgeschlossenes Bauwerk, das sich durch mehrere Gebäude zu einer Liegenschaft verbinden

lässt. Mehrere Liegenschaften bilden zum Abschluss das Liegenschafts-Portfolio, das in der

Praxis eine ganze Stadtteilplanung sein kann.

Zur Vereinfachung der Beschreibung wird die Granularität für diese Arbeit auf das Gebäude

als äußerste Schale begrenzt. Die meisten Anwendungsfälle der GA werden mit dieser

Auswahl abgedeckt.

Abbildung 14: Vereinfachte Darstellung der Ortsstruktur

Durch die Aufteilung eines Gebäudes nach diesem Schalenmodell wird die Ortsstruktur des

Gebäudes gebildet. Werden die Beziehungszusammenhänge dieser Ortsstruktur in ein Entity-

Relationship-Modell (ERM; DE: Objektbeziehungsmodell) nach Chen [CHE02] bzw. erweitert

nach [ELNA02] überführt, wie in der Abbildung 14 dargestellt, wird die hierarchische Struktur

des Schalenmodells deutlich. Die Beziehungen zwischen den Elementen der Ortsstruktur

bestehen jeweils aus einer 1:n-Beziehung, d.h., jedem Segment ist ein Raum zugeordnet und

jeder Raum kann eine unterschiedliche Anzahl von Segmenten haben. Dabei steht das n für

eine, keine oder beliebig viele Entitäten. Die Beziehungen zwischen den verschiedenen

Entitäten stehen für sich alleine, daher ist das n in der Beziehung zwischen Gebäude und

Bereich nicht das Gleiche wie zwischen Bereich und Raum.

52


Der Vollständigkeit halber sei angemerkt, dass es darüber hinaus weitere Beziehungen

zwischen den Entitäten des Schalenmodells geben kann, indem grundsätzlich auch Schalen

übersprungen werden können. Das bedeutet, dass ein Gebäude nicht vollständig in Bereiche

aufgeteilt werden muss, sondern auch neben eingeteilten Bereichen Räume oder Segmente

einzeln existieren können. Die Erweiterung des Schalenmodells um diese Beziehungen führen

zu weiteren Verbindungen im ERM. Ein Beispiel, wann eine solche Ortsstruktur sinnvoll sein

kann, ist ein Gebäude, dessen Stirnseite nach Norden zeigt und in dem eine

sonnenstandsabhängige Verschattung installiert werden soll. Aufgrund der Aufteilung ist jede

Etage ein eigener Bereich. Da bei den Büros, welche die Fenster nach Norden ausgerichtet

haben, keine sonnenstandsabhängige Verschattung notwendig ist, macht es Sinn, diese aus

dem Bereich der Ortsstruktur zu extrahieren und direkt als einzelne Elemente dem Gebäude

zuzuordnen. Diese Sonderstrukturen, die von der grundsätzlichen Ortsstruktur abweichen,

werden im Folgenden unter der Möglichkeit des Customizings der Ortsstruktur verstanden.

Das ERM muss daher um die weiteren Möglichkeiten der Beziehungen zwischen den Entitäten

der Ortsstruktur ergänzt werden und ist in der Abbildung 15 dargestellt. Aufgrund der

Beziehungsrelationen ist es notwendig, zwischen den Ortselementen eine c:m-Beziehung zu

beschreiben. Die Kardinalität c entspricht dabei genau 0 oder 1 und m steht für jede beliebige

Zahl. Diese Kardinalitäten eröffnen damit die Möglichkeit, die Ortsstruktur um diese

Beziehungen zu erweitern. Dies entspricht dem Grundsatz der planerischen Freiheit der

Architekten und Objektplaner.

Abbildung 15: Vollständige Ortsstruktur

Um eine einheitliche Vorgehensweise bei der Erstellung einer Ortsstruktur sicherzustellen und

keine Überschneidungen zu modellieren, werden zwei Grundsätze definiert:

• Jede Entität, bis auf die Entität Gebäude, hat exakt ein übergeordnetes Element.

Dieser Grundsatz ist durch die 1:n-Beziehung im einfachen ERM definiert und

produziert dadurch die vorgegebene hierarchische Struktur der Ortsstruktur. Dieser

Grundsatz verhindert Überschneidungen der hierarchischen Struktur bei der

vollständigen Ortsstruktur.

• Jede Entität der Ortsstruktur kann als eigenständiges System betrachtet werden, das

Schnittstellen zu anderen Entitäten aufweist und mit diesen in Wechselwirkung steht.

Dies ist vor allem im Hinblick auf die GA eine wichtige Eigenschaft, die berücksichtigt

werden muss.

Mit diesen Definitionen kann ein Gebäudeplan nun in die Ortsstruktur überführt werden, die

den Ausgangspunkt für die weitere Planung von GA-Systemen darstellt.

5.1.2 Überführung des Gebäudeplans in die Ortsstruktur

Grundlage für die Gebäudestrukturierung ist zunächst ein Gebäude bzw. der Plan von einem

Gebäude, das mit dem GA-System ausgestattet werden soll. Um die Informationen des

Grundrisses in ein Modell zu bringen, ist die Strukturierung gemäß der vorgestellten

53


Ortsstruktur sinnvoll. Die Ortsstruktur ist so definiert, dass es auf jedes Gebäude Anwendung

finden und durch die Strukturierung des Gebäudes eine einfache Hierarchie seiner Elemente

(Bereiche, Räume, Segmente) erstellt werden kann. Diese Ortsstruktur erlaubt es später,

Funktionen eines GA-Systems den entsprechenden Entitäten zuzuordnen.

Als Beispiel ist die Bedienfunktion für die Temperatureinstellung sowohl für ein ganzes

Bürogebäude, als auch für jeden Bereich, jeden Raum oder auch jedes Segment in Form

einzelner Thermostate am Heizkörper einsetzbar. Da nicht alle Nutzer des Bürogebäudes die

gleiche Temperatur beim Arbeiten benötigen, führt eine einheitliche Temperatursteuerung

über das ganze Gebäude oder seine Bereiche unweigerlich zum Unwohlsein der Mitarbeiter,

die es lieber kälter oder wärmer haben möchten. Wenn jeder Mitarbeiter in seinem Einzelbüro

zwei Heizkörper hat, die individuell geregelt werden können, muss dieser bei gewünschter

Temperaturänderung beide Heizkörper einzeln einstellen. Die bessere Option ist hier eine

Regelung der Temperatur in jedem Raum.

Im Gegensatz dazu ist der Sensor für die Messung des Sonnenstands, um die

sonnenstandsabhängige Verschattung zu steuern, keine Funktion, die in jedem Raum benötigt

wird, sondern sinnvollerweise auf dem Dach des Gebäudes ausgeplant wird. Diese Beispiele

zeigen, dass es notwendig ist, dass die Funktionen dort ausgeplant werden müssen, wo sie in

der Ortsstruktur benötigt werden. Mangels exakter Definitionen vor allem von Segmenten,

Räumen oder Bereichen ist die automatische Erstellung der Ortsstruktur aus den

Infrastrukturdaten nicht trivial und wird anhand des Beispiels eines Bürogebäudes verdeutlicht.

Wenn ein Gebäude strukturiert werden soll, wird der Grundriss des Gebäudes in die

entsprechenden Entitäten eingeteilt. Dazu wird zunächst festgelegt, wie der Bereich für dieses

Gebäude definiert werden soll. Die einfachste Variante ist die Festlegung der Etage als ein

Bereich. Bei der Festlegung der Räume wurden zusammenhängende und durch Wände

umgebende Flächen als einzelne Räume bestimmt, wie beispielsweise ein Büro oder auch der

gesamte Flur. Bei zweckmäßigen Unterteilungen der Räume werden Segmente eingefügt, wie

beispielsweise bei einem Flur die Einteilung in Flursegmente. In der Abbildung 16 sind die

beiden Etagen eines Beispielgebäudes dargestellt und bereits in Bereiche, Räume und

Segmente eingeteilt.

54


Abbildung 16: Ober- und Untergeschoss des Beispielgebäudes

In der Abbildung 17 ist die Strukturierung der Etage 1 des Bürogebäudes in die vier Entitäten

der Ortsstruktur dargestellt. Diese Strukturierung ist aufgrund der in Absatz 5.1.1

beschriebenen Erläuterungen zum Schalenmodell beliebig und es gibt daher auch keine

„falsche“ Strukturierung, sofern die zuvor erläuterten Grundsätze eingehalten werden. In den

meisten Grundrissen sind die Etagen und die Räume bereits anhand der Bedürfnisse des

Bauherrn ausgeplant und daher vorgegeben. Inwiefern die Zusammenstellung eines Bereichs

oder die Einteilung eines Raumes in mehrere Segmente sinnvoll ist oder nicht, ist individuell

und hängt von den weiteren Bedürfnissen des Bauherrn ab.

55


Die Eingabe dieser Struktur in das Engineering-Werkzeug zur Unterstützung der

Anforderungserhebung ist jedoch je nach Größe des Gebäudes eine mühsame und sich häufig

wiederholende Prozedur. Das Ziel der automatischen Struktursegmentierung ist es, diesen

Prozess zu verkürzen, indem ausgehend von den digitalen Grundrissen eine automatische

Erzeugung der grundsätzlichen Ortsstruktur und deren Überführung in das Engineering-

Werkzeug zur Unterstützung der Anforderungserhebung erfolgen. Diese grundsätzliche

Ortsstruktur ist als ein Vorschlag zu verstehen, welcher durch das angesprochene

Customizing in der Absprache zwischen Bauherr und Objektplaner veränderbar ist. Durch

einen Filter können einzelne Strukturelemente in einer digitalen Datenaustauschdatei

gefunden und nach den Entitäten sortiert werden. Sie stehen als Modell der Ortsstruktur für

die GA-Planung zur Verfügung. Dazu werden zunächst die zur Verfügung stehenden

Datenaustauschformate ermittelt und auf Durchführbarkeit dieser Methode untersucht.

Abbildung 17: Struktursegmentierung des Beispielgebäudes

SegmentRaumBereichGebäude

Gebäude

Etage 1

6x Büro

4x Doppelbüro

Flur

2x Flur außen

Flur mitte

Flur EingangDruckerraum

Küche

Treppenhaus

2x WC-Raum

2x WC-Kabine

2x VorraumEtage 2

...

56


5.2 Analyse von Infrastrukturdaten

Die folgende Analyse der Infrastrukturdaten wurde grundsätzlich im Rahmen einer betreuten

Masterarbeit [PHR16] durchgeführt und anschließend im Kontext dieser Arbeit erweitert und

bewertet.

Die wohl bekanntesten Programme zur Erstellung von Gebäude-Grafiken werden unter dem

Begriff CAD (oder CAAD) verstanden. CAD steht für Computer Aided (Architectural) Design

und beschreibt “the use of computers to aid in design layout and analysis. May include

modeling, analysis, simulation, or optimization of designs for production.” [INS87]

Tabelle 4: CAD-Software für Architekten

Die Nutzung gerade von CAD-Systemen in der Mechanik erstreckt sich über viele Bereiche

vom Bauwesen über den Maschinenbau bis hin zum Produktdesign. Für die Architektur gibt

Tabelle 4 eine Übersicht über die häufigsten verwendeten CAD-Programme von Architekten

in Europa, vgl. [RAL12@], inklusive der Hersteller und möglichen Datenschnittstellen.

Diese Planungsprogramme für die Architektur lassen sich grundsätzlich in zwei Gruppen

einteilen: diejenigen, die mit den älteren AutoCAD Datenformaten .dwg und .dxf arbeiten, und

Programmname Hersteller Branchen Datenmodell Exportformate/ Schnittstellen

Auto CAD Autodesk Architektur, Maschinenbau und GIS

2D/3D dwg, dxf, dxb, dwf, plt, dgn V8, dgn V7, sat, iges, igs, step

Auto CAD LT Autodesk Architektur, Maschinenbau und GIS

2D dwg, dxf, dxb, dwf, plt, dgn V8, dgn V7, sat, iges, igs, step

ArchiCAD GRAPHISOFT

Architektur, Innenarchitektur, Städtebau und Messebau

2D/3D (BIM)

atl, 3ds, c4d, dgn, dwg, dxf, epx, fact, pdf, plt, ifc, sgi, u3d, wrl

Allplan Allplan/ Nemetschek AG

Architektur und Bauingenieurwesen

2D/3D (BIM)

dwg, dxf, dgn, ifc, pdf, 3D-pdf, svg, c4d, 3ds, Collada, kmz, rhino, Sketchup, vrml, u3d, plt, hpgl, bvbs

Revit Autodesk

Architektur, Innenarchitektur, Ingenieurbau, Statik und Haustechnik

3D (BIM) rvt, dwg, dwf, dxf, 3ds, ifc, dgn, sat, gbXML

SPIRIT SOFTTECH

Architektur, Innenarchitektur, Bau-Ingenieurwesen, Statik und Holzbau

2D/3D dwg, dxf, dwf, sfm, o2c, vrml, ifc, collada(dae), skp

57


die neueren BIM-fähigen Programme, die mit dem Datenformat .ifc arbeiten können. Die

anderen aufgelisteten Schnittstellenformate sind weniger von Bedeutung, da sie nur für

spezielle, teils proprietäre Anwendungen entwickelt wurden und häufig nicht alle Informationen

der Datei enthalten.

5.2.1 Die AutoCAD-Austauschdateien

Mit dem Architekturprogramm AutoCAD von der Firma Autodesk arbeiten heutzutage die

meisten Architekturfirmen in Europa in den eigens dafür entwickelten Dateiformaten .dwg und

.dxf. Daher werden diese beiden Dateiformate zunächst darauf untersucht, ob aus diesen

Formaten die Gebäudestruktur eines Grundrisses zu entnehmen ist, um sie als Import für das

Werkzeug zur Unterstützung der Anforderungserhebung zu verwenden.

Das Dateiformat .dwg steht für die Abkürzung von „DraWinG“ und ist das interne

Zeichenformat von Autodesk [AUT17@]. Es beschreibt eine geometrische Zeichnung im 2D-

Format. Die .dwg-Dateien enthalten u.a. die grundlegenden Bausteine, wie Punkte und Linien

in unterschiedlicher Form, Skizzen, Schraffuren, Texte und Symbole. Für das Format .dwg

stellt [OPE13] eine ausführliche Dokumentation für die Beschreibung vom Format und von

dessen Bestandteilen zur Verfügung.

Das Format .dxf (Drawing eXchange Format) bezeichnet ein Datenformat zum Austausch

einer Vektordatei und wurde für das Programm AutoCAD von der Firma Autodesk als offene

Schnittstelle entwickelt [AUT15@]. Heutzutage wird dieses Dateiformat daher in mehreren

Architekturprogrammen auch von anderen Firmen verwendet. Auch dieses Format enthält die

grundlegenden Bausteine der grafischen Zeichnung und kann darüber hinaus weitere

Entitäten und Objekte, wie beispielsweise Texte, enthalten. Der Aufbau der Dateistruktur und

weitere Informationen zum .dxf-Format sind in [RSW00] beschrieben.

Im Rahmen der Untersuchung wurden die Quellcodes der beiden Dateiformate daraufhin

überprüft, ob die Gebäudestruktur darin ersichtlich ist und daraus extrahiert werden kann.

Dazu wurde das Beispiel des Bürogebäudes aus Abbildung 16 in den beiden Dateiformaten

erstellt und die Dateien mittels Editor geöffnet. Die Texteditordatei der .dxf Datei ist im Anhang

B dargestellt. Die Datenstruktur besteht aus fünf Teilen: Header, Table, Block, Entitäten und

erweiterte Entitäten. Die Dateien sind in ASCII beschrieben und beinhalten jeweils eine

Gruppe von zwei bis drei Zeilen. Die erste Zeile beinhaltet die Gruppenkennzahl (integer code)

und die zweite Zeile beschreibt die Eigenschaft. Jedoch kann aus diesem Quellcode nicht

ohne weiteres eine Gebäudestruktur oder überhaupt eine Zuordnung extrahiert werden.

Die .dwg-Datei ist in Anhang C mittels eines Hexeditors dargestellt, da ein normaler Texteditor

nicht ausreicht, in der Datei lesbare Elemente zu finden. Mittels des Hexeditors können die

Bytes der Datei als Folge von Hexadezimalzahlen analysiert werden. Im linken Teil des

Ausschnitts sind die Hexadezimalzahlen im Format 8 Byte dargestellt und rechts der

übersetzte Text dazu. Auch durch diese Darstellung ist nicht ohne Weiteres eine

Gebäudestruktur oder eine Zuordnung von grafischen Bestandteilen sichtbar.

Das grundsätzliche Problem der beiden Dateiformate ist, dass beim Abspeichern in diesen

Formaten die Objektinformationen verloren gehen bzw. durch die proprietäre Verarbeitung der

Daten nur durch entsprechende Software entschlüsselt werden können, siehe auch [HAA93].

Die Austauschdateien im Format .dxf und .dwg sind daher nicht geeignet, die Ortsstruktur ohne

weiteren Aufwand aus der Datei zu entnehmen. Die Interpretation dieser

Datenaustauschdateien ist sehr kompliziert, da zusammenhängende Elemente der

58


Konstruktion nicht gemeinsam abgespeichert werden. Daher ist nicht erkennbar, welche Linie

zu welcher Fläche gehört, und damit ist der Versuch, durch einen Filter die Gebäudestruktur

herauszufiltern, für diese Dateien nicht gelungen. Daher ist bei Vorliegen dieser Dateiformate

entweder eine Konvertierung oder die manuelle Strukturierung wie in Abschnitt 5.1.2

beschrieben notwendig.

5.2.2 BIM-Datenaustauschdateien

Im Rahmen der Entwicklung von BIM wurde das Dateiformat .ifc (Industry Foundation Classes)

[ISO 16739] im Jahr 2000 entwickelt, das als gemeinsame Datenbasis fungieren kann. Ziel

dieses Dateiformates ist es, dass sämtliche Planungen, die ein Bauobjekt betreffen, darin

hinterlegt werden können. Damit kann der Architekt die grundsätzliche Baustruktur planen und

dann können die Fachplaner der Gewerke ihre Planungen in dieselbe Datei integrieren, siehe

[DELI06; IAI08@]. Durch die dreidimensionale Ansicht können Planungsfehler schnell entdeckt

und ausgebessert werden, und durch die Verwendung von nur einer Datei ist gewährleistet,

dass jeder Bearbeiter immer auf dem aktuellen Planungsstand der anderen

Planungsteilnehmer ist.

Das Format .ifc befindet sich seit 2008 in der praktischen Anwendung in der Version IFC 2x3

und die aktuelle Version seit 2014 ist IFC 4. In der Norm [ISO 16739] sind das Dateiformat und

das Datenschema beschrieben: „Das konzeptionelle Datenschema ist in der

Datenbeschreibungssprache EXPRESS definiert. Das Standarddateiformat für den Austausch

und das Teilen von Daten nach dem konzeptionellen Schema verwendet die Klartext-

Codierung der Austauschstruktur.“ Zusätzlich zum Format .ifc gibt es das Format .ifcXML, das

als XML-basiertes (Extensible Markup Language) Austauschformat dient. Dieses

Datenaustauschformat ist daher von den grundsätzlichen Vorausetzungen besser geeignet,

eine einfache Struktursegmentierung durchzuführen, als die proprietären Dateiformate .dwg

und .dxf.

Im Folgenden wird die Dateistruktur, die die Gebäudestruktur innerhalb der .ifc-Datei

wiedergibt, beschrieben.

5.2.3 Aufbau der IFC-Datei

Die .ifc-Datei ist in zwei Abschnitte geteilt, die Kopfzeile (Header) und den

Datenabschnitt (Data). Im Anhang D sind Ausschnitte der beiden Dateiteile dargestellt.

Die Kopfzeile enthält die Versionsdaten des Projekts inklusive Erstellungsdaten und -zeiten

sowie Daten zur Lizenz.

Der Datenabschnitt enthält die wesentlichen Daten des Gebäudes. Jede Zeile beginnt mit

einem Rauten-Symbol „#“ und der dazugehörigen Zeilennummer. Dahinter steht das Objekt

selbst und in Klammern seine Attribute oder Verweise auf Zeilennummern, mit denen diese

Entität in Verbindung steht. Mit dem Symbol „$“ gekennzeichnete Attribute wurden beim

Erstellen der Beispieldatei nicht befüllt und sind daher leer. Attribute stehen an fest definierten

Stellen innerhalb der Klammer und sind durch Kommas getrennt. Ein Beispiele für Attribute

sind die Global-ID, eine Buchstaben-Zahlen-Kombination zur Identifizierung des Objektes oder

der Name des Objektes.

Insgesamt gibt es 653 verschiedene Entitäten innerhalb der Datenstruktur, die in den

technischen Dokumentationen [BUI16@; LIE07@] alle einzeln beschrieben und deren

59


Beziehungen zueinander dargestellt sind. Die für die Struktur des Gebäudes relevanten

Entitäten werden im Folgenden anhand einer Beispieldatei näher erläutert. Die Beispieldatei

ist das in Abschnitt 5.1.2 eingeführte Beispielgebäude (Abbildung 16), welches im Rahmen

der Masterarbeit [PHR16] im Programm REVIT von Autodesk erstellt wurde.

Die oberste Hierarchieebene stellt das Projekt in IfcProject dar. Unter diesem Projektnamen

wird die Struktur des Gebäudes aufgebaut.

Abbildung 18: IfcProjekt und seine Verweise

In der Abbildung 18 ist dargestellt, dass die Zeile #94 in ihrer Beschreibung auf weitere Zeilen

verweist. Zudem sind in der Beschreibung Platzhalter für Projekt-Nummer, -Name und -Status

angegeben. Die weiteren Zeilen #41 (Besitzerhistorie), #78 (Einheitenbeschreibung) und #83

und #91 (Geometrische Daten) geben nähere Informationen zum Projekt und enthalten

grundsätzliche Daten, die für das gesamte Projekt gelten. Auch in diesen Zeilen wird wieder

auf weitere Zeilen mit mehr Informationen verwiesen.

Die Entitäten von IfcSite beinhalten die Informationen über die geografische Lage und die

genauen Bruchlinien (Survey Points) der Liegenschaft. Auf die Lage wird durch den Ausdruck

IfcLocalplacement verwiesen.

Das Gebäude selber wird durch IfcBuilding dargestellt. Das Gebäude befindet sich

hierarchisch unter der Liegenschaft und kann weitere Informationen, wie beispielsweise die

Lage zum Meeresspiegel oder Gelände, enthalten. Weiter kann hier die Adresse durch den

Verweis auf eine postalische Anschrift spezifiziert werden. Die Lage des Gebäudes verweist

in Zeile #32 durch IfcLocalplacement auf die Zeile #19454, welche die Lage der IfcSite ist.

Durch diesen Verweis wird die Beziehung zwischen den beiden Entitäten deutlich.

Abbildung 19: IfcSite, IfcBuilding und IfcBuildingstorey

60


Die nächste Hierarchieebene stellt IfcBuildingStorey dar, welches eine Etage eines Gebäudes

darstellt, mehrere Räume umfassen kann und mit der Entität IfcBuilding verbunden ist. Die

Beziehung der Entität IfcBuildingStorey wird auch hier durch das Element IfcLocalPlacement

deutlich, siehe Abbildung 19. Dieses verweist in Zeile #111 auf die Zeile #32, die die Lage des

Gebäudes angibt. Zusätzlich hat das Element IfcBuildingStorey an dritter Stelle in der Klammer

auch einen Namen, in diesem Fall „Level 1“. Dies erleichtert die Zuordnung der Elemente und

ein Zurechtfinden während der Planung. Auch die zweite Etage des Beispielgebäudes verweist

in seiner IfcLocalPlacement-Zeile #118 auf das Gebäude in Zeile #32 und hat als Namen

„Level 2“, siehe Abbildung 19.

Das Element IfcSpace bezeichnet eine begrenzte Fläche in einem Gebäude und ist mit der

Entität IfcBuildingStorey verbunden. Weitere Eigenschaften des Raumes können hier

ebenfalls abgelegt werden. Diese können Bezeichnungen (8. Element in der Klammer),

Beschreibungen, Raumtypen oder Raumfunktionen sein. Weiter werden im Dateiformat auch

die geometrischen Daten, wie Volumen oder Fläche, gespeichert, siehe Abbildung 20.

Abbildung 20: IfcSpace des Untergeschosses

Auch bei der Entität IfcSpace (Abbildung 20) wird neben der Produktdefinition

(IfcProduktdefinitionshape) sowohl auf die Zeile #41 zur Besitzerhistorie verwiesen als auch

auf mit IfcLocalPlacement auf die Zeilen #32 und #110. Dies entspricht den gleichen

Verweisen wie die Etage „Level 1“ aus Zeile #113 bzw. #111 (Abbildung 19). Damit gehört

dieser Raum eindeutig zum Untergeschoss des Beispielgebäudes.

Im Vergleich dazu hat ein Raum des Obergeschosses in seinem IfcLocalPlacement den

Verweis auf Zeile #118, siehe Abbildung 21.

Abbildung 21: IfcSpace des Obergeschosses

Die Entitäten der Gebäudestruktur einer IFC-Datei sind durch ihre hierarchische Verbindung

in Abbildung 22 dargestellt. Die Beziehungen zwischen diesen Entitäten entsprechen 1:n –

Verbindungen. Das bedeutet, dass jede Entität genau eine übergeordnete Entität hat.

Abbildung 22: Hierarchische Struktur der Gebäudeentitäten einer IFC-Datei

61


Die aufgezeigte gesamte Struktur an Gebäudeentitäten entspricht im Grunde der Aufteilung

gemäß dem Schalenmodell und ist in der Abbildung 23 diesem gegenübergestellt.

Eine Korrelation zwischen diesen beiden Modellen konnte in der Literatur nicht nachgewiesen

werden. Die Beziehungsrelationen in der IFC-Datei sind durch den objektorientierten Aufbau

und dessen Programmierung entstanden. Daher sind alle Teile eines Gebäudes von einzelnen

Streben bis hin zum ganzen Dach durch Beziehungsrelationen miteinander verknüpft. Die

beschriebenen Gebäudestruktur-Entitäten stehen miteinander durch eine Aggregation in

Zusammenhang. Eine Aggregation bedeutet, dass ein Element vollständig Teil eines anderen

Elementes ist, vgl. dazu [BKK+15].

Die Frage, ob die hierarchische Struktur durchbrochen werden kann, indem ein Raum direkt

dem Gebäude untergeordnet wird, wird durch die technische Dokumentation nicht direkt

beantwortet. In [BKK+15] wird dazu geschrieben:

„Das Datenmodell selbst legt nicht fest, welche Hierarchieebenen mit welchen anderen

Hierarchieebenen über die Aggregationsbeziehungen verknüpft werden dürfen. Es gelten

jedoch einige informelle Regeln, darunter, dass der entstehende Graph azyklisch sein

muss und Elemente einer niedrigeren Stufe keine Objekte einer höheren Stufe aufnehmen

können. Für die Korrektheit und Konsistenz der angelegten Informationen ist das

implementierende Programm verantwortlich.“ [BKK+15, S. 95].

Abbildung 23: Vergleich IFC-Strukturmodell und Schalenmodell

Das bedeutet, dass Verbindungen, wie in der vollständigen Ortsstruktur (vergleiche Absatz

5.1.1), auch in der IFC-Struktur grundsätzlich möglich sind, jedoch sind in der technischen

Dokumentation [BUI16@] lediglich die 1:n-Verbindungen beschrieben.

Die Unterschiede zwischen dem Schalenmodell und dem IFC-Strukturmodell liegen zum einen

in der Definition vom Bereich im Vergleich zur Etage. Ein Bereich gemäß dem Schalenmodell

ist nicht auf die Etage beschränkt und kann auch Räume organisatorisch oder durch vertikale

Verknüpfung (beispielsweise ein Südtrakt) über mehrere Etagen hinweg zusammenfassen.

Eine Etage ist dagegen eine horizontale Zusammenfassung von Räumen einer Ebene. Ein

weiterer Unterschied zwischen den beiden Strukturmodellen ist das Fehlen der strukturellen

Einheit Segment in der IFC-Struktur. Das hat zur Folge, dass die Entität IFCSpace sowohl für

Räume, als auch für Segmente genutzt werden kann. Gemäß der oben beschriebenen

62


informellen Regel, dass Elemente einer niedrigeren Stufe keine Objekte einer höheren Stufe

aufnehmen können, ist die Aufnahme von gleichstufigen Objekten gestattet.

Der Gesamtzusammenhang der unterschiedlichen Entitäten und ihre hierarchische Struktur

innerhalb der IFC-Struktur ist über die Bezeichnung IfcRelAggregrates zu finden. Diese

Beziehungsrelation zwischen den Entitäten der Gebäudestruktur aggregiert die verschiedenen

Entitäten und deren Elemente. Mit dieser Bezeichnung finden sich in der Dateistruktur des

Beispielgebäudes die in der Abbildung 24 aufgelisteten Zeilen.

Abbildung 24: Der Zusammenhang über IfcRelAggregates

Die Beziehrungsrelation IFCRelAggregates hat folgenden Aufbau:

#[Zeilennummer]=IFCRelAggregates([1], [2], [3], [4], [5], [6])

[1] = Globale Identifizierungsnummer

[2] = Verweis auf Besitzerhistorie

[3] = Name (in der Beispieldatei nicht vergeben, daher $)

[4] = Beschreibung (in der Beispieldatei nicht vergeben, daher $)

[5] = betreffendes Objekt

[6] = zugeordnete / untergeordnete Objekte in Klammern dargestellt

Durch die Beziehungszusammenhänge in [5] und [6] wird eine hierarchische Verbindung

zwischen den Objekten erzeugt, da der Kontainer [6] dem Objekt in Kontainer [5]

untergeordnet wird. Am Beispiel verweist die Zeile #19702 auf Zeile #94 mit dem IfcProject

und in Klammern auf die Zeile #19455, welche die IfcSite-Zeile ist, und stellt damit den

Zusammenhang zwischen diesen beiden Entitäten her. Die nächste Zeile #19706 führt die

IfcSite- und IfcBuilding-Zeilen zusammen. In den Zeilen #19710 für das Untergeschoss und

#19732 für das Obergeschoss sind alle IfcSpace-Entitäten getrennt nach den beiden Etagen

aufgeführt. Die Etagen stehen wiederum in der Zeile #19754 und sind dem Gebäude in Zeile

#104 untergeordnet.

Die räumliche Struktur und der Zusammenhang zwischen den Gebäudeelementen sind in

Abbildung 25 zusammenfassend für das Beispielgebäude dargestellt.

63


Abbildung 25: Gebäudestruktur des Beispielgebäudes aus der zugehörigen IFC-Datei

64


5.2.4 Umsetzung der automatischen Infrastruktursegmentierung

Die manuelle Erstellung einer Orststruktur aus einem Grundriss ist eine mühseliges Verfahren.

Bei Vorliegen von digitalen Grundrissen im Dateiformat IFC kann, wie anhand der im vorigen

Abschnitt 5.2.3 identifizierten Entitäten und deren hierarchischen Zusammenhänge, eine

automatische Struktursegmentierung aus der Datei erfolgen.

Dazu erfolgt zunächst das Einlesen der Gebäudestrukturdatei im .ifc-Format.

Da die IFC-Datei grundsätzlich zeilenweise ausgelegt ist, wird sie auch zeilenweise eingelesen

und daraufhin überprüft, ob sie einen der folgenden Ausdrücke enthält:

• IFCBuilding,

• IFCBuildingStorey,

• IFCSpace,

• IFCRelAggregates.

Die Umsetzung für die Filterung in einer C-Programmierung ist in Anhang E und ihr

Ausführungsergebnis in Anhang F aufgeführt.

Durch diese Filterung entsteht im Ergebnis eine Liste an Objekten, welche durch ihre

hierarchischen Beziehungen in den IFCRelAggregates-Entitäten zu einer Baumstruktur/

Objektstruktur zusammengesetzt werden können. Eine Erläuterung, wie die Gebäudestruktur

als Eingangsinformation für das Engineering-Werkzeug dient, wird in Abschnitt 6.3

beschrieben.

Diese Liste der Entitäten der Ortsstruktur ist bewusst mit den kompletten Zeilen und ihren

Informationen erstellt, da in diesen, wie in Abschnitt 5.2.3 erwähnt, bereits Bezeichnungen der

Segmente, Räume oder Bereiche vorhanden sein können. Das Ortsmodell kann als Import in

das Engineering-Werkzeug zur Unterstützung der Anforderungserhebung geladen werden

und dort nach den Wünschen des Bauherrn mit den Funktionen der GA zu einem Engineering-

Modell der GA erstellt werden. Das Engineering-Werkzeug zur Unterstützung der

Anforderungserhebung wird im folgenden Kapitel erläutert.

Liegt keine IFC-Datei oder ein Format, welches in das .ifc-Format konvertiert werden kann vor,

müssen die Informationen manuell aus den Grundrissen übertragen werden. Dazu gibt es

gerade bei Sanierungen älterer Gebäude eine Alternative, welche die Verwendung des

Grundrisses als Papierdokument erlaubt. Dazu wurde in Forschungsarbeiten, wie in [ARR17;

HAF16], ein Ansatz zur automatischen Analyse und Erkennung von grafischen Inhalten aus

Engineering-Dokumenten erläutert, die grundsätzlich auch für Grundrisse verwendbar, jedoch

nicht Bestandteil dieser Arbeit sind.

65

6.1 Methodik der GA-Anforderungserhebung

6 Erstellung des GA-System-Modells

Die GA-Anforderungserhebung ist der für die Planung der GA entscheidende Prozess, der die

Ideen des Bauherrn aufnehmen und in der Planung umsetzen muss. Der Bauherr hat eine

Vorstellung von den Funktionalitäten in seinem Gebäude und diese müssen in ein

Engineering-Modell, ohne Informationsverlust überführt werden, siehe Abbildung 26. Dazu

wird die Ortsstruktur mit der Funktionsstruktur verknüpft. Die Produktstruktur kann erst nach

der Ausschreibung und Ausplanung durch die Gewerke hinzugefügt werden, siehe Prozess

Abbildung 12. Gemeinsam mit der Produktstruktur wird das GA-System-Modell erzeugt. Im

folgenden Kapitel werden das diesen Prozess unterstützende Werkzeug und die Erzeugung

eines Engineering-Modells und GA-System-Modells erläutert.

Abbildung 26: Erstellung eines Modells des GA-Systems

6.1 Methodik der GA-Anforderungserhebung

Methodisch werden die Entitäten der Ortsstruktur mit denen der logischen Funktionsstruktur

über die Kardinalität 1:n verknüpft.

Das bedeutet, dass jeder Entität der Funktionsstruktur genau eine Entität der Ortsstruktur

zugeordnet werden kann. Dagegen kann jede Entität der Ortsstruktur beliebig viele oder keine

Entitäten der Funktionsstruktur enthalten. Diese Ordnung bewirkt, dass eine einzelne Funktion

jeweils nur einmal ausgeplant wird und nicht ausversehen doppelt. Funktionen vom gleichen

Typ können jeweils unterschiedlichen Ortselementen zugeordnet werden.

Die Entitäten der Ortsstruktur wurden in Kapitel 5 bereits erläutert und definiert. Gleiches muss

nun auch mit den Entitäten der Funktionsstruktur erfolgen.

66


Die Entitäten der Funktionsstruktur sind grundsätzlich die in Abschnitt 2.3.1 genannten

Funktionen eines GA-Systems, welche sich, wie erläutert, zu Funktionsstrukturen verbinden

lassen.

Alle Funktionen sind über Eingänge und/oder Ausgänge mit weiteren Funktionen verbunden

und haben demzufolge mindestens einen Vorgänger und/oder Nachfolger. Dabei ist es

möglich, dass Funktionen mehrere Vorgänger oder Nachfolger haben. Die Kardinalität

zwischen den Entitäten der Funktionsstruktur ist daher eine n:m-Beziehung.

Um ein Engineeringmodell des GA-Systems zu erstellen, müssen die Ortsstruktur und die

Funktionsstruktur miteinander verbunden werden. Dabei wird für dieses Modell nicht nur die

Zuordnung von GA/RA-Funktionen zu Räumen zugelassen, sondern die Funktionen können

in beliebiger Anzahl allen Schalen der Ortsstruktur zugeordnet werden. Die Ortsstruktur lässt

sich in die vier Entitätengruppen Gebäude, Bereich, Raum und Segment aufteilen und jeder

Entität in diesen Entitätengruppen lassen sich somit n Funktionen zuordnen. Die auf die

Schalen aufgeteilten Funktionen lassen sich daher ebenfalls in vier eigenen Entitätengruppen

gliedern (Funktionen Gebäude, Funktionen Bereich, Funktionen Raum und Funktionen

Segment). In Verbindung mit der einfachen Ortsstruktur (Customizing in der Abbildung nicht

berücksichtigt) und den aufgestellten Verbindungsdefinitionen ergibt sich das folgende

Engineering-Modell der GA, siehe Abbildung 27. Im Folgenden wird die Umsetzung des

Engineering-Werkzeugs zur Unterstützung der Anforderungserhebung beschrieben, in dem

die Ortstruktur und die Funktionen miteinander, wie dargestellt, verknüpft werden.

Abbildung 27: Das Engineeringmodell der GA als ERM

67

6.2 Umsetzung in AutomationML


Um den Prozess der Anforderungserhebung zu unterstützen, wird ein Werkzeug benötigt, das

ein Modell erzeugen kann, eine einfache Bedienung und Handhabbarkeit aufweist und

möglichst viele Informationen über das GA-System, inklusive der vielschichtigen

Verbindungsmöglichkeiten und Parameter, wie im ERM in Abbildung 27 dargestellt,

aufnehmen kann.

In verschiedenen Forschungsarbeiten hat sich AutomationML als zuverlässige Grundlage zur

Modellerstellung bereits mehrfach bewiesen, vgl. [GLFA15]. So konnte Puntel-Schmidt in

[PFR+14] zeigen, dass im Rahmen der virtuellen Inbetriebnahme von Steuercodes,

AutomationML als Basis der Modellerstellung dienen kann. Ebenfalls hat Runde in [RUN10]

AutomationML als Grundlage der wissensbasierten Methode zur Unterstützung bei der

Planung von GA-Systemen erfolgreich genutzt.

AutomationML ist ein Datenaustauschformat, das zur Verknüpfung von Werkzeugen des

Engineerings gedacht und für verschiedene Disziplinen der Anlagenplanung oder des

Prozessengineerings etc. ausgelegt ist. AutomationML arbeitet objektorientiert und erlaubt die

Modellierung von physikalischen oder logischen Anlagenkomponenten und den Austausch

dieser Daten. Es ist ein herstellerneutrales und XML-basiertes Datenformat, vgl. [GADR11@].

AutomationML nutzt im Kern das Metamodell CAEX (Computer Aided Engineering eXchange)

entsprechend der [DIN EN 62424] zur Abbildung hierarchischer Strukturen.

Die Bibliotheken von AutomationML werden im Folgenden nach [DRA10] kurz vorgestellt:

• InstanceHierarchy,

• SystemUnitClassLibrary,

• RoleClassLibrary,

• InterfaceClassLibrary.

In der InstanceHierarchy werden die bestehenden oder geplanten Anlagen abgebildet. Sie

besteht aus einzelnen InternalElements, welche die einzelnen Teile der Anlage oder des

Gebäudes darstellen und über InternalLinks miteinander verbunden sein können.

In der SystemUnitClassLibrary sind SystemUnitClasses in einer Bibliothek zusammengefasst.

Diese SystemUnitClasses beschreiben konkrete physikalische oder logische Objekte oder

Bauteile. Durch Attribute können diese Objekte mit konkreten Herstellerangaben ihrer

technischen Realisierung versehen werden. Weiterhin ist es durch die SystemUnitClass

möglich, Verbindungen zwischen Objekten herzustellen und interne Elemente

(InternalElements) zu speichern. Durch diese InternalElements können hierarchische

Strukturen innerhalb eines Objektes dargestellt werden. Die Rolle einer SystemUnitClass wird

durch die RoleClass definiert. In der SystemUnitClass-Bibliothek sind die verschiedenen

SystemUnit-Klassen katalogähnlich hinterlegt.

Die RoleClassLibrary ist eine Bibliothek, die sogenannte Rollenklassen beinhaltet. Eine

Rollenklasse beschreibt physikalische oder logische Anlagenobjekte sehr abstrakt und

unabhängig von einer tatsächlichen Realisierung. Rollenklassen sind allgemeine und

grundsätzliche Funktionalitäten oder Beschreibungen, die nicht mit Attributen oder

Herstellerdaten hinterlegt sind.

68


Die InterfaceClassLibrary stellt die Bibliothek der Schnittstellen (Interface) von Objekten dar.

Auch diese Schnittstellen können mit Attributen weiter spezifiziert werden. Über InternalLinks

können die Schnittstellen von Objekten miteinander verbunden werden.

Durch Instanziieren einer SystemUnitClass wird in der InstanceHierarchy ein InternalElement

der entsprechenden SystemUnitClass erzeugt.

6.2.1 Vorstellung des Engineering-Werkzeugs

Auf der Basis der erläuterten Grundfunktionen von AutomationML werden im Folgenden die

Anwendung auf die Anforderungserhebung der GA und ihre Funktionsweise erläutert. Das

Engineering-Werkzeug wurde im Rahmen des Forschungsprojektes „Gebäude besser

vernetzen“ unter Mitwirkung der Autorin an der HSU entwickelt, siehe auch [GSP+16A;

GSP+16B]. Die Integration der Ortsstruktur (Abschnitt 6.3) und teilweise die Integration der

Produktstruktur (Abschnitt 6.4) in das Engineering-Werkzeug ist Arbeit der Autorin.

6.2.1.1 Bibliothek der Ortselemente

Um das in Kapitel 5 eingeführte Schalenmodell und die darauf basierende Hierarchie der

Ortselemente aus der Struktursegmentierung in ein Modell zu überführen, ist eine Bibliothek

der Ortselemente notwendig. Aus den Grundfunktionen von AutomationML bietet sich dazu

die RoleClassLibrary an, da diese Bibliothek Rollen zur allgemeinen Beschreibung verwendet.

In dieser werden die Ortselemente Liegenschaft, Gebäude, Bereich, Raum und Segment als

Elemente der hierarchischen Ortsstruktur gebildet. Diese beschreiben die Rolle, die ein

InternalElement grundsätzlich erhält, um es in der Gesamtmodellhierarchie zuzuordnen. Das

bedeutet, dass mithilfe dieser Rollen die Ortsstruktur des Gebäudes abgebildet werden kann.

6.2.1.2 Funktionsbibliothek

Des Weiteren ist es notwendig, dass die Funktionen der GA in das Modell überführt werden.

Dazu wird eine SystemUnitClassLibrary genutzt, da diese konkrete logische Objekte enthalten

kann. Als Grundfunktionen werden dazu die Funktionen der [VDI-RICHTLINIE 3813-2]

abgebildet, die damit die Grundfunktionen der GA darstellen.

Den verschiedenen Funktionen können über die InterfaceClassLibrary Schnittstellen

hinzugefügt werden. Das sind Ein- und Ausgänge jeder Funktion, um diese mit anderen

Funktionen über InternalLinks zu verbinden.

Des Weiteren können über Attribute die Parameter einer Funktion gespeichert werden

Durch die InternalLink-Interfaces können verschiedene Verbindungsarten (Kabellängen,

Kabeldurchmesser etc.) unter dem Unterpunkt Attribute Type und vor allem auch die

Signalrichtungen unter dem Unterpunkt Attribute Direction definiert werden.

Um die Möglichkeit zu bieten, weitere spezielle Informationen über Funktionen von

spezifischen GA-Systemen zu hinterlegen, können alternative Bibliotheken in einer weiteren

SystemUnitClass-Bibliothek erstellt werden.

6.2.1.3 Bibliothek der Templates

Um bei der Erstellung des GA-System-Modells mehr Effizienz zu erzielen, wurde die

Möglichkeit der Template-Erstellung integriert und durch eine weitere SystemUnitClass-

Bibliothek abgebildet. Diese kann projektspezifisch oder allgemein angelegt und genutzt

69


werden. Dazu werden Ortselemente in der SystemUnitClass-Bibliothek erstellt und darin alle

Funktionen, die darin realisiert werden sollen, als InternalElements (entnommen aus der

Bibliothek der GA-Funktionen) eingefügt. Dies ist in der Abbildung 29 beispielhaft an einem

Template für den 6-Funktionen-Raum („Office_Room_small“) aus Abbildung 5 dargestellt.

Bereits hier können die Verbindungen zwischen den Funktionen über InternalLinks realisiert

werden. Das hat den Vorteil, dass diese Tätigkeit pro Template nur einmal durchgeführt

werden muss, da die InternalLinks beim Instanziieren der SystemUnitClass in der

InstanceHierarchy mit übernommen werden. Diese Templates können nun in der notwendigen

Anzahl in die entsprechende hierarchische Struktur des Gebäudes, abgebildet in der

InstanceHierarchy, instanziiert werden. Es können ebenfalls Templates angelegt werden,

welche mehrere Ortselemente beinhalten (beispielsweise ein Raum mit seinen Segmenten).

Abbildung 29: Template eines Büroraumes

6.2.2 Das Engineering-Modell eines GA-Systems

Durch Instanziieren der Elemente aus der Orts- und Funktionsbibliothek in die

InstanceHierarchy kann das GA-System als Engineering-Modell abgebildet werden. Beim

Instanziieren erhält jedes InternalElement eine eigene ID (IDentifier), das sind Buchstaben-

Zahlen-Kombinationen, mit welchen die Elemente identifizierbar sind. Diese ID wird durch die

AutomationML-Engine erzeugt.

Die Funktionen werden als InternalElements der Ortsstruktur in der InstanceHierarchy, wie im

ERM in Abbildung 27 dargestellt, hinzugefügt. Dabei entstehen die vier Entitätengruppen der

Funktionen aus Absatz 6.1. Nach Befüllen der Ortsstruktur mit den Funktionen und deren

Verbindungen ist das Engineering-Modell erzeugt und die InstanceHierarchy der XML-Sicht

der AutomationML-Datei ist dann folgendermaßen aufgebaut:

Die eigentlichen Informationen zum erstellten Engineering-Modell beginnen mit der Auflistung

der InstanceHierarchy, welche mit dem Projektnamen und dem Gebäudenamen anfängt. Dann

wird der erste Bereich und darin der erste Raum benannt. Hat der Raum ein Segment, so folgt

danach direkt der Name des Segments und anschließend die Auflistung der enthaltenen

Funktionen in diesem Segment, deren Attribute und Verbindungen. Dann folgt das nächste

70


Segment dieses Raumes. Sind alle Segmente des Raumes aufgelistet, werden aus dem

aktuellen Raum die Funktionen, Attribute der Funktionen und die Verbindungen des Raumes

aufgelistet. Dann geht die Auflistung weiter zum nächsten Raum und listet zunächst den

Raumnamen und dann das erste darin enthaltene Segment auf. In dieser Systematik werden

die gesamten Informationen in der Reihenfolge der jeweiligen Verästelungen aufgelistet, siehe

Abbildung 30. Verbindungen zwischen Funktionen verschiedener Schalen werden nur bei dem

jeweils hierarchisch höher liegenden Element aufgelistet.

Abbildung 30: Schematischer Aufbau der AutomationML-Datei

6.2.3 Die Benutzeroberfläche zur Anforderungserhebung der GA

Da das Zusammenstellen des Engineeringmodells händisch sehr mühsam ist, wurde eine

Benutzeroberfläche im Rahmen des Forschungsprojektes entwickelt, welche teilautomatisiert

die InstanceHierarchy erstellt.

In der Abbildung 31 ist die Benutzeroberfläche dargestellt. Oben links ist die InstanceHierarchy

(Ortsansicht) und unten links die RoleClassLibrary (Orts-Bibliothek verortet. Die

SystemUnitClassLibrary wurde in zwei Teile getrennt: die Funktionen-Bibliothek rechts und die

Template-Bibliothek in der Mitte unten. Des Weiteren wurde ein Eigenschaften-Feld (Mitte

oben) kreiert, das die Schnittstellen der Funktionen und die Möglichkeiten ihrer Verbindbarkeit

zu anderen Schnittstellen anzeigt.

71


Um ein Gebäude mit GA zu planen, kann zunächst auf der Bedienoberfläche ein neues Projekt

erstellt (Abbildung 31, Nr. 1) und ausgewählt werden, mit welcher Funktionsbibliothek (sofern

mehr als die der VDI 3813-2 angelegt wurde) dieses erstellt werden soll. In einem zweiten

Schritt soll die Gebäudestruktur in der InstanceHierarchy abgebildet werden. Dazu fügt der

Planer der InstanceHierarchy die entsprechenden Elemente aus der Bibliothek der

Ortselemente hinzu (Abbildung 31, Nr. 2). Alternativ kann hier die automatische

Struktursegmentierung für einen Grundriss das Zusammenstellen der Gebäudehierarchie

übernehmen, siehe Abschnitt 6.3.

Abbildung 31: Bedienoberfläche des erstellten Werkzeuges

Um das Instanziieren der einzelnen Räume und Segmente zu erleichtern, kann der Nutzer aus

der Bibliothek der Ortselemente ein Element in die Template-Bibliothek ziehen (beispielsweise

einen Raum, um ein Raum-Template zu erstellen, siehe Abbildung 31, Nr. 3) und dieses dort

durch Hinzufügen von Funktionen aus der Funktionsbibliothek (Abbildung 31, Nr. 4) per „Drag

& Drop“ befüllen. Dann werden die einzelnen Funktionen ebenfalls per „Drag & Drop“

miteinander verbunden. Dazu werden dem Nutzer über ein weiteres Fenster die zu

verbindenden Elemente in zwei Hierarchien (Abbildung 32, links und rechts) dargestellt sowie

die Interfaces der Funktionen angezeigt (Abbildung 32, Mitte). Die Interfaces können nun per

„Drag & Drop“ (Abbildung 32, durch Pfeil dargestellt) miteinander verbunden werden. Dem

Planer werden dabei bereits verbundene Interfaces angezeigt. Ein Tooltip gibt Informationen

zum Verbindungspartner des Interfaces. Im Hintergrund dieser Benutzeroberfläche wird ein

InterLink zwischen den InternalInterfaces der Funktionen erstellt.

72


Abbildung 32: Verbindung von zwei Funktionen

Die erstellten Templates können in der notwendigen Anzahl in die entsprechende

hierarchische Struktur des Gebäudes in der InstanceHierarchy instanziiert werden

(Abbildung 31, Nr. 5). Vorteilhaft ist dabei, dass die InternalLinks beim Instanziieren der

SystemUnitClass in der InstanceHierarchy mit übernommen werden. Durch die

Benutzeroberfläche konnte der Prozess der Erstellung des Engineering-Modells vereinfacht

und teilautomatisiert werden, siehe Abbildung 33. Durch die Templateauswahl müssen nur

noch die Anzahl und das Template aus einem „Dropdown“- Menü ausgewählt werden und

diese werden dann automatisch in die InstanceHierarchy instanziiert.

Abbildung 33: Teilautomatisierter Prozess der GA-Planung

Als Ergebnis für den Export zu den nachfolgend anzuwendenden Tools steht die

AutomationML-Datei zur Verfügung. Diese enthält nach erfolgtem Entwurf des GA-Systems

eine Gebäudestruktur und die darin abgebildeten Funktionen. Aufgrund dessen, dass dieses

Modell herstellerunabhängig und das Datenaustauschformat XML-basiert ist, kann dieses nun

als Ausgangsbasis für die Durchführung von Simulationen und auch die Auslegung des realen

GA-Systems verwendet werden.

73

6.3 Automatische Generierung der Ortsstruktur

6.3 Automatische Generierung der Ortsstruktur

In Absatz 5.2.3 wird erläutert, wie durch die Filterung der IFC-Datei die entsprechend

relevanten Informationen über die Ortsstruktur extrahiert werden können. Diese Informationen

müssen nun zu einem objektorientierten Format, wie das der AutomationML-Datei, konvertiert

werden. Die relevanten Zeilen der IFC-Datei haben die in der Tabelle 5 dargestellte Form. Die

Attribute können als Kontainer verstanden werden, welche Bezeichnungen oder Verweise

durch Zeilennummern enthalten.

Zeilennummer Bezeichnung Attribute (Kontainer)

[#Zeilennummer]= IFCBuilding ([1], …, [12])

[#Zeilennummer]= IFCBuildingStorey ([1], … , [10])

[#Zeilennummer]= IFCSpace ([1], … , [11])

[#Zeilennummer]= IFCRelAggregates ([1], … , [6])

Tabelle 5: Aufsplittung der Zeilen einer IFC-Datei

Die Namen der jeweiligen Ortselemente sind in Kontainer [8] der jeweiligen Attribute von den

Ortselementen IFC-Building, -BuildingStorey und -Space enthalten. Die Beziehungsrelationen

des Objekts IFCRelAggregates stehen in den Kontainern [5] und [6].

Zur automatischen Generierung der Ortsstruktur muss die Listenform in ein objektorientiertes

Format gebracht werden und die Baumstruktur der Ortsstruktur erstellt werden. Dazu wird mit

der Erzeugung des Gebäudes angefangen. Der Name des Gebäudes [G] und seine

Zeilennummer werden aus der Zeile IFCBuilding herausgelesen und als InternalElement mit

der Rolle Gebäude erstellt. Dann wird die Zeile von IFCRelAggregates gesucht, welche die

Zeilennummer des Gebäudes in Kontainer [5] hat und aus dieser werden die Zeilennummern

in Kontainer [6] genommen und in entsprechender Anzahl als InternalElements mit der Rolle

Bereich erstellt. Der Name jeden Bereiches [B1-n] wird durch Suchen der entsprechenden

Zeilennummern in Kontainer [8] des Objektes IFCBuildingStorey gefunden. Dann wird

nacheinander jedes Objekt IFCRelAggregates gesucht, welches die Zeilennummer eines

Bereichs in Kontainer [5] hat und die entsprechenden Kind-Elemente in Kontainer [6] als

InternalElements zu dem jeweiligen Bereich als weiteres InternalElement hinzugefügt. In den

Zeilennummern von Kontainer [6] stehen Objekte der Bezeichnung IFCSpace und diese haben

Namen [R1-n] in ihrem jeweiligen Attributkontainer [8], welche an entsprechender Stelle

hinzugefügt werden.

74


Tabelle 6: Abstrakte XML-Ansicht der InstanceHierarchy der AutomamationML-Datei

Die jeweiligen herausgefilterten Elemente werden mit entsprechendem Subtext in einer

AutomationML-Datei abgespeichert und stehen dort als Ortsstruktur zur Verfügung, siehe

Tabelle 6. Jedes erstellte InternalElement hat eine Schlusszeile, welche anhand der

abstrakten Darstellung am Ende des jeweiligen Elementes steht. Die ID ist eine beliebige

Buchstaben-Zahlen-Kombination in der Form [8-4-4-4-12-Zeichen], beispielsweise [d0cc8377-

dd3d-4fce-88f8-0ce8e9b4877d] und wird durch die AutomationML-Engine erzeugt.

In XML sieht die Ortsstruktur in der InstanceHierarchy des „Projekt 1“ dann wie in Abbildung 34

aus. Dargestellt sind hier ein Gebäude mit einem „Bereich 1“ und zwei Räumen „Raum 1“ und

„Raum 2“.

Abbildung 34: XML-Ansicht der Ortsstruktur in der AutomationML-Datei

75

6.4 Die Produktstruktur


Das Engineering-Modell hat bereits die Informationen aus der Ortsstruktur und der logischen

Funktionsstruktur. Zur Vervollständigung des Modells des GA-Systems sind weitere

Informationen notwendig, die im Gegensatz zur logischen Verknüpfung der Funktionen die

tatsächlich physische Verbindung der Funktionen beinhalten. Die tatsächliche physische

Verbindung der Funktionen ist die Produktstruktur. Die Produktstruktur kann bezogen auf den

Engineering-Prozess aus Abbildung 12 erst nach der Ausplanung der einzelnen Gewerke

erfolgen, da für die Produktstruktur die konkreten Geräte- und deren

Verbindungsinformationen notwendig sind. Die Produktstruktur ist die dritte Topologie, die in

einem GA-System-Modell berücksichtigt werden muss.

Abbildung 35: Verbindungen der Funktionsstruktur und der Produktstruktur

In Abbildung 35 sind anhand eines Beispiels der Lichtregelung die Verbindungen der

Funktions- und der Produktstruktur aufgetragen. Die durchgängigen Pfeile verbinden alle

Funktionen in ihrer logischen Folge. Die physikalischen Verbindungen sind abhängig von den

tatsächlichen Geräten und Anlagen, welche die Funktionen des GA-Systems bereitstellen.

Dabei können mehrere Funktionen innerhalb eines Gerätes verbaut sein, siehe Abbildung 35.

Daher kann es in der Produktstruktur externe (Abbildung 35, gepunktete Pfeile) und interne

Verbindungen innerhalb der Geräte geben (Abbildung 35, gestrichelte Pfeile).

Die Verbindungsarten können, wie bereits im Kapitel 3 erläutert, über unterschiedliche Medien

verbunden werden. Wie in vielen Bereichen, wie der Automatisierungs- oder Prozesstechnik,

sind Bussysteme eine häufige Verbindung auch in GA-Systemen. Dazu gehören Bussysteme

der dezentralen GA-Systeme oder auch die zentralen kabelgebundenen Steuerungen von GA-

Systemen. Weitere Möglichkeiten können Stromleitungen oder kabellose Verbindungen über

das WLAN sein. Die Topologie der Verbindung kann neben unterschiedlichen Medien auch

unterschiedliche Formen haben. Die klassischen Netzwerktopologien sind: Ring, Stern,

(voll)vermaschtes Netz, Linie/Reihe, Baum oder Bus, vgl. [HAU15; TAWE12]. Weitere

Grundlagen zu Bussystemen finden sich vor allem in der industriellen Kommunikation, siehe

[SCWI08].

In der GA können die zentralen GA-Systeme einer Stern-Topologie zugeordnet werden und

die dezentralen GA-Systeme einem Feldbus. Die Teilnehmer eines Feldbusses werden auch

als (Bus-)Knoten bezeichnet und kommunizieren über Telegramme untereinander. Um den

76


Kommunikationsablauf auf einem Feldbus zu koordinieren und Datenverluste zu vermeiden,

gibt es Knoten, die initiativ eine Kommunikation mit anderen Teilnehmern starten dürfen. Diese

werden als Master oder aktive Knoten bezeichnet, alle anderen Knoten als passive Knoten

oder als Slave. Bussysteme können mehr als einen Master haben, diese werden dann als

Multimaster-Bus bezeichnet.

Um die Produktstruktur in das Engineering-Modell zu integrieren gibt es mehere Möglichkeiten.

AutomationML bietet die Möglichkeit mehrere Verbindungsarten (InternalLink-Interfaces)

darzustellen und darüber beispielsweise interne und externe Verbindungen abzubilden.

Abbildung 36: InstanceHierarchy (links) und InternalLinks (rechts) mit den Verbindungen der

Funktions- und Produktstruktur

In Abbildung 36 sind die InstanceHierarchy (links) und die InternalLinks (rechts) des Beispiels

aus Abbildung 35 und ihre Verbindungen dargestellt. Für die Produktstruktur können in

AutomationML eigene SystemUnitClass-Librarys erstellt werden, welche anhand der

Herstellerinformationen die geräteinternen Verbindungen zwischen Funktionen bereits

abspeichern können. Weiter können diese Herstellerbibliotheken auch eigene

herstellerspezifische Funktionsparameter enthalten.

Eine weitere Möglichkeit die Produktstruktur im Modell abzubilden stellt das Hinzufügen eines

Feldbusses als InternalElement dar. Mit diesem können die entsprechenden Funktionen oder

77


ggf. die Geräte gemäß einer eigenen Herstellerbibliothek, mit dem Feldbus verbunden werden

und darüber die Topologie eines dezentralen GA-Systems abbilden.

Im Forschungsprojekt „Gebäude besser vernetzen“ wurde eine dritte Möglichkeit angewendet,

indem eine eigene Herstellerbibliothek für das GA-System „SmallCAN“ erstellt wurde, in

welcher die Funktionen mit herstellerspezifischen Parametern, wie beispielsweise welche

Funktion auf welchem Busknoten ist, in den den Attributen der Funktionen hinterlegt und nicht

als eigene Verbindungen dargestellt wurde, siehe auch [GDS+16A].

Das Erstellen von eigenen Herstellerbibliotheken, welche bereits interne Verbindungen

innerhalb von Geräten hinterlegt haben, bietet weiterhin den Vorteil, dass bei Instanziierung

die Verbindungen in Form von InternalLinks mit übernommen werden.

Ein automatisiertes Erstellen der Produktstruktur kann durch den Abgleich der

herstellerneutralen Funktionen, mit den Funktionen in den Herstellerbibliotheken erfolgen.

Sofern eine Funktion in der Herstellerbibliothek genau einer herstellerneutralen Funktion

entspricht, kann die herstellerneutrale Funktion durch die Funktion mit den

Herstellerparametern und deren Verbindungen ersetzt werden. Die Produktbibliotheken

müssen für diesen Prozess nur einmal erstellt werden und können dann für beliebig viele

Modelle wiederverwendet werden.

Durch Hinzufügen der Informationen aus der Produktstruktur wird das Engineering-Modell zu

einem GA-System-Modell, welches alle Engineeringinformationen zum GA-System enthält.

Dieses Modell steht dann für die weitere Nutzung, beispielsweise zur Simulation,

Parametrierung oder Teilmodellerstellung zur Verfügung.

78


6.5 Simulation und Parametrierung des GA-Systems

Das GA-System-Modell wurde durch das Engineering-Werkzeug, das die

Anforderungserhebung unterstützt, erstellt. Es enthält alle wichtigen Informationen zu den

Funktionen und deren Verbindung, zu Parametern und zur Ortshierarchie. Dieses Modell kann

durch eine Simulation virtuell, ähnlich wie im Ansatz von [PUFA15], vor der Installation getestet

werden.

Die Simulationen und die Parametrierung eines GA-Systems sind nicht Bestandteil dieser

Arbeit und sollen lediglich den Engineeringprozess der GA vervollständigen. Die Simulation

mittels „Pi-Tool“ [IQS14A@] und die Parametrierung des GA-Systems „SmallCAN“ [IQS14B@]

konnten anhand des Projektes „Gebäude besser vernetzten“ getestet werden und wurden

durch die Firma „iQST“ bereitgestellt.

6.5.1 Möglichkeiten zur Simulation

Die Möglichkeiten, ein solches Modell zu testen und auf Fehler zu überprüfen, sind sehr

umfangreich. Als ein Beispiel für eine Simulationsmöglichkeit dient das „Pi-Tool“ der Firma

„iQST“ , siehe [IQS14A@]. Das „Pi-Tool“ basiert auf stochastischen Petrinetzen und wurde für

die Durchführung von RAMS (Reliability, Availability, Maintainability, Safety, DE:

Zuverlässigkeit, Verfügbarkeit, Instandhaltbarkeit, Sicherheit) – Analysen entwickelt. Ziel des

„Pi-Tools“ ist es, eine rechnergestützte und übersichtliche Petrinetzmodellierung realer

Systeme mit der Analyse der nicht funktionalen Eigenschaften, wie Sicherheit, Zuverlässigkeit,

Verfügbarkeit und Instandhaltbarkeit, zu gewährleisten. Weiterhin soll das „Pi-Tool“ die

Simulation des modellierten Systems ermöglichen. Weitere Informationen zur

Simulationsumgebung, siehe [QBS14; IQS13@]. Mittels Monte-Carlo Simulation lassen sich

z. B. das Wiedereintrittsverhalten oder die Verweildauern in Zuständen analysieren. Zur

Bewertung von Simulationsmodellen mittels „Pi-Tool“ siehe auch [QBS14; DISC14; DISC15].

Die Datenaustauschdatei des GA-System-Modells auf der Basis von AutomationML muss in

das „Pi-Tool“ überführt werden. Dazu werden die Funktionen in einem Modellkatalog im „Pi-

Tool“ als Entwurf gemäß den Funktionsdefinitionen der [VDI-RICHTLINIE 3813-2] hinterlegt.

Durch einen Konverter wird die AutomationML-Datei mit den Informationen des GA-System-

Modells eingelesen und für jede Funktion die jeweils passende Funktion aus dem

Modellkatalog in das „Pi-Tool“ geladen. Im Modellkatalog werden die Funktionen bereits mit

den Gerätespezifikationen hinterlegt. Die InternalLinks werden ebenfalls als

Kommunikationsstruktur aus dem Modellkatalog übernommen. Die Gerätespezifikationen

wurden für das GA-System „SmallCAN“ modelliert. Weitere Parameter, welche durch das GA-

System-Modell in der AutomationML-Datei hinterlegt sind, werden als Parameter in den

Funktionen aus dem Modellkatalog übernommen. Durch den Konverter wird das

Simulationsmodell im „Pi-Tool“ automatisch aus der AutomationML-Datei erzeugt und kann

anschließend analysiert werden.

Die Produktstruktur wurde im Rahmen des Projektes nicht mit eigenen InternalLink-Interfaces

modelliert, sondern als Attribute in den Funktionen hinterlegt. Da „SmallCAN“ ein dezentrales

Feldbus-System ist, wurde eine eigene „SmallCAN“- SystemUnitClass-Library angelegt und in

diesen Funktionen wurden die Busknoten in den Attributen hinterlegt, siehe [DBD+16;

DDB+16; GDS+16B]

Eine Alternative zum „Pi-Tool“ wird in [HRR00] mit einem Simulator für große GA-Systeme

vorgestellt. In dieser Überprüfungsmöglichkeit wird eine ereignisorientierte Simulation

79

6.5 Simulation und Parametrierung des GA-Systems

verwendet, um die Leistungsfähigkeit eines Netzwerks mit vielen Knoten zu bestimmen. Dabei

werden u.a. Antwortzeitverhalten und Paketverlustraten ermittelt, indem stochastisches

Nutzerverhalten angenommen wird. Um gerade große GA-Systeme zu simulieren, wird das

Systemverhalten in einem teilbaren Gesamtmodell abgebildet und in Teilsystemen

nacheinander simuliert. Praktisch durchgeführt wurde das Simulationstool für ein LonWorks-

System. Dieser Ansatz und andere Simulationsmöglichkeiten können je nach Fragestellung

eine sinnvolle Ergänzung zum bereits getesteten „Pi-Tool“ sein.

6.5.2 Konfiguration und Parametrierung des GA-Systems

Nach der gewerkegetrennten Installation des GA-Systems ist es weiterhin notwendig, dieses

schnellstmöglich auf Funktionsfähigkeit zu prüfen und für den Betrieb entsprechend zu

parametrieren. Im Rahmen der Installation kann das zwar fehlerfrei geplante GA-System

trotzdem fehlerbehaftet eingebaut werden, indem Geräte nicht richtig in das GA-System

integriert wurden. Da viele Arbeiten an großen GA-Systemen deutlich vor Übergabe des

Gebäudes stattfinden, ist eine schnelle Parametrierung und Überprüfung der Funktionalitäten

sinnvoll, um Änderungen und Fehlerbehebungen aufwandarm vornehmen zu können.

Bei großen Gebäuden kommen grundsätzlich nur zentrale oder dezentrale GA-Systeme in

Betracht. Beim zentralen GA-System müssen alle Geräte mit einer Zentrale verbunden

werden. Diese Zentrale steuert dann das GA-System. Das bedeutet, dass alle Geräte einzeln

über Kabel mit der zentralen Steuereinrichtung verbunden werden müssen. Beim dezentralen

GA-System werden einzelne Geräte über Buscontroller zum nächstgelegenen Zugangspunkt

eines Bussystems verlegt. In beiden Fällen ist eine Parametrierung der Geräte notwendig. Das

bedeutet, dass den Buscontrollern bzw. der zentralen Steuerungseinrichtung die logischen

Verbindungen der Geräte und ihre Parameter eingegeben werden müssen.

„SmallCAN“ ist ein dezentrales GA-System, welches das günstige Preissegment anstrebt und

eine möglichst hohe Integrität von Funktionalitäten bereitstellen möchte. Über ein offenes,

herstellerunabhängiges Feldbussystem sind die Geräte miteinander verbunden. Zur

Anknüpfung an den Feldbus werden Buscontroller als Busknoten verwendet. Bei der

Parametrierung müssen diese Busknoten entsprechend ihrer Funktionalität programmiert

werden.

Die dazu notwendigen Informationen über die zugehörigen Busknoten wurden in Attributen

den Funktionen der Funktionsbibliothek hinterlegt und automatisch in das GA-System-Modell

übernommen. Anhand dieser Informationen können aus dem GA-System-Modell die

Parameter der Funktionen auf die Buskontroller übertragen werden. Dieses Verfahren wurde

im Rahmen der Projektarbeit mit der Firma „iQST“ über einen weiteren Konverter realisiert,

der die Informationen aus der AutomationML-Datei, wie bei der Simulation (Absatz 6.5.1),

ausliest und in EEPROM-Daten (Electrically erasable programmable read-only memory, DE:

elektrisch löschbarer, programmierbarer nur-Lese-Speicher) umgewandelt hat. Im Anschluss

wurde diese auf das reale GA-System übertragen. Durch diese Möglichkeit konnte gezeigt

werden, dass auch eine Änderung der Funktionen durch Überschreiben im laufenden Betrieb

möglich ist. Beispielhaft konnten dazu die Funktionalitäten zweier Schalter eines

Demonstrators getauscht werden. Dies zeigt, dass auch eine Nutzungsänderung oder das

Hinzufügen von neuen Funktionen durch Änderung des GA-System-Modells einfach möglich

ist. Siehe hierzu auch [DBD+16; GDS+16B].

80

7 Teilmodellerstellung aus dem GA-System-Modell


Die gewerkeübergreifende Betrachtung eines GA-Systems ist eine hilfreiche Methode, um in

den Phasen Planung und Betrieb das gesamte System zu berücksichtigen und

Schnittstellenfehler durch bspw. Dateninkonsistenzen zu vermeiden. Die Ausgangssituation

im konventionellen Bauprozess ist jedoch unverändert gewerkegetrennt. Daher muss für die

Planung und die Installation eine aufwandarme Aufteilung des gesamten GA-System-Modells

in Teilsysteme erfolgen können. Des Weiteren kann die Abstraktion eines Modells zur

Betrachtung fokussierter Bereiche des GA-Systems verwendet werden, beispielsweise zur

Analyse einzelner Teilbereiche des GA-Systems auf Leistungsfähigkeit oder das Antwort-

Zeitverhalten. Durch die semi-automatische Erstellung von Funktionslisten aus dem GA-

System-(Teil)-Modell kann die gewerkegetrennte Ausschreibung, Feinausplanung und

Installation erleichtert werden.

7.1 Vorstellung Ansatz TLT-Modell

Im Top-Level-Topologie-Ansatz von Christiansen wurde eine Methode vorgestellt, mit der

Anlagentopologien auf der Basis von AutomationML in Teilsysteme aufgeteilt werden konnten,

siehe [CHF14B]. Dieser Ansatz von Christiansen zeigt, dass die Erzeugung eines großen,

übergreifenden Modells, aus dem sich mehrere Teilmodelle erzeugen lassen, im Gegensatz

zur Erstellung von Einzelmodellen Synergieeffekte bietet. Dazu wurde ein allgemeines

Topologiemodell einer zu projektierenden Anlage als Basis verwendet und davon wurden

spezifische Teilmodelle erzeugt. Durch dieses Vorgehen können alle Informationen zur

Verfügung gestellt und durchgängig im Engineering und Betrieb verwendet werden. Bei der

automatischen Teilmodellerstellung werden für einen bestimmten Anwendungsfall die

benötigten Informationen identifiziert und dann aus dem Gesamtmodell in ein spezifisches

Teilmodell abgeleitet.

Eine einfache Abstraktion eines Gesamtmodells lässt sich durch das Ausschließen von

Modellteilen erreichen. Diese Vorgehensweise würde jedoch dazu führen, dass an den

Teilsystemgrenzen unklare Beziehungen vorherrschen. Daher müssen die Grenzen der

Teilmodelle bestimmt und entsprechend modelliert werden. Bei Christiansen werden die

Informationen an den Teilsystemgrenzen durch das Hinzufügen von Quellen oder Senken für

Input- bzw. Outputsignale, um die Richtungslogik in den Verbindungen aufrechtzuerhalten,

übergeben. Der in [CHF14B] vorgestellte Ansatz nutzt eine regelbasierte Erzeugung der

Teilmodelle. In der ersten Abfrage wird dazu der Verbindungstyp (Bsp. Masse, Energie oder

Information) abgefragt und eine entsprechende Schnittstelle erzeugt. In der zweiten Regel

werden dann ein Terminierungsobjekt (Quelle oder Senke) und eine Verbindung zwischen der

Schnittstelle und dem Terminierungsobjekt erzeugt. In der dritten Regel wird abschließend die

Objektinformation integriert, indem spezifische Informationen und Eigenschaften als Attribute

des jeweiligen Objekts Quelle/Senke hinzugefügt werden. Durch dieses Vorgehen können alle

notwendigen Informationen aus einem übergeordneten Modell an den Schnittstellen zu einem

Teilmodell übergeben werden. In [CHF14C] wird die Entwicklung eines Modellverbinders

vorgestellt, der Inkonsistenzen zwischen den unterschiedlichen Topologiemodellen vermeiden

soll. Durch dieses Konzept wird eine durchgängige Beschreibung logischer

Modellzusammenhänge innerhalb des Gesamtmodells oder zwischen Teilmodellen

ermöglicht. Der vorgestellte Ansatz lässt sich aufgrund derselben Datenbasis grundsätzlich

auch auf die Gebäudeautomation anwenden. Dazu müssen aufgrund der Unterschiede

81

7.2 Methodik der Teilsystemerzeugung für die GA

zwischen der Anlagentopologie und dem Aufbau eines GA-Systems einige Erweiterungen und

Veränderungen in der Vorgehensweise definiert werden.

7.2 Methodik der Teilsystemerzeugung für die GA

Gemäß der Grundidee eines modellbasierten Vorgehens, wie in Abschnitt 4.4 erläutert, hat

auch jedes Teilmodell einen Zweck oder eine Fragestellung, welche mit diesem Teilmodell

beantwortet werden kann. Nicht jedes Teilmodell ist daher für jede Fragestellung gleich gut

geeignet. Ziel einer Teilmodellerstellung ist daher immer die Beantwortung einer konkreten

Fragestellung zum Gesamtmodell, welche alle notwendigen Informationen in einem Teilmodell

bündelt und zur Verfügung stellt. Dazu muss das Teilmodell folgenden Anforderungen

genügen:

• die Modellgrenzen müssen definiert werden,

• physikalische oder informationstechnische Verbindungen die an den Modellgrenzen

getrennt werden, müssen durch Objekte ersetzt werden, die die Informationen an den

Schnittstellen übergeben und

• Teilmodelle müssen verschiedene gewerkeorientierte Sichtweisen ermöglichen.

Während eine Anlage in der Regel aus einer funktionalen Verkettung von Bauteilen, die

gewisse Funktionalitäten bereitstellen, besteht, sind bei der GA auch die Verteilung der

Funktionen in Form von Geräten und Anlagen innerhalb eines Gebäudes und die physikalische

Verbindung vorhanden. Insgesamt existieren also drei verschiedene Topologien, die

Ortsstruktur, die Funktionsstruktur und die Produktstruktur, welche sinngemäß den drei

Hauptaspekten zur Strukturierung von Informationen über Systeme gemäß [DIN EN 81346-

TEIL 1] entsprechen. Alle drei Topologien stehen miteinander in Beziehung und haben

ihrerseits Einfluss auf das GA-System-Modell, das in Bezug auf das TLT-Modell als

Gesamtmodell zu verstehen ist. Aus den drei genannten Topologien ergeben sich daher auch

drei verschiedene grundsätzliche Möglichkeiten, das Gesamtmodell aufzuteilen oder zu

betrachten:

• strukturell anhand der Ortselemente (Beispiel: Betrachtung eines einzelnen Raumes),

• funktional (Beispiel: alle Funktionen zur Beleuchtung, eines Gewerkes oder

Betrachtung einer einzelnen Funktion und deren Verbindungen zu anderen

Funktionen),

• produktstrukturbasiert (Beispiel: alle Funktionen auf einem Bus oder Busknoten).

Bei der Erstellung von Teilmodellen entstehen ebenso, wie in [CHF14B] aufgezeigt,

Teilsystemgrenzen, welche definiert und modelliert werden müssen, um die notwendigen

Informationen bereit zu stellen. Die Informationen des Gesamtmodells sind in den drei

Topologien vorhanden und stehen folgendermaßen untereinander und miteinander in

Beziehung:

• hierarchische Verbindung der Entitäten der einfachen (1:n) bzw. vollständigen (c:m)

Ortsstruktur,

• Entitäten der Funktionsstruktur untereinander (n:m),

• Entitäten der Produktstruktur untereinander, Master – Slave (1:n) bzw. beim

Multimaster-Bus (n:m),

• Verbindung der Entitäten der Ortsstruktur und der Funktionsstruktur (1:n),

• Verbindung der Entitäten der Ortsstruktur und der Produkstruktur (1:n).

82


Die Aufschlüsselung der verschiedenen Verbindungen des GA-System-Modells ist notwendig,

um die entsprechenden Schnittstellen der Teilmodelle zu ermitteln. Die Schnittmöglichkeiten

müssen die Zusammenhänge aus den drei Topologien inklusive ihrer

Beziehungsmöglichkeiten berücksichtigen. Alle Informationen des Gesamtmodells liegen in

der AutomationML-Datei, wie in Kapitel 6 erläutert, vor und können innerhalb des Modells zu

Teilmodellen erstellt werden.

Um die Teilmodelle zu erstellen, müssen für die GA-System-Modelle die Regeln für das

Erstellen von Schnittstellen aus [CHF14B] angepasst werden.

Zuerst müssen die Schnittstellen ermittelt werden. Die Schnittstellen hängen von dem

ausgewählten Teilmodell ab, daher muss die Regel 1 für die drei Erstellungen der Teilmodelle

entsprechend angepasst werden. Für die ortsstrukturelle Teilmodellerstellung kann sowohl

das Ortselement selber, wie auch weitere hierarchisch untergeordnete Ortselemente,

Funktionsverbindungen nach außen haben, daher müssen alle Verbindungen geprüft werden.

Regel 1 Einrichtung der Schnittstellen:

WENN: Eine Verbindung von Funktionen innerhalb des ausgewählten Teilmodelles zu

einer Funktion außerhalb des ausgewählten Teilmodelles existiert,

DANN: überprüfe Typ der Verbindung (Verbindung der Funktionsstruktur oder

externe/interne Verbindung der Produktstruktur),

UND: erzeuge eine Schnittstelle vom entsprechenden Typ.

In einem zweiten Schritt muss der Schnittstelle eine Richtung zugewiesen werden.

Regel 2 Festlegen der einzufügenden Objektart:

WENN: Das InternalLink-Interface der Funktion im Ortselement als Attribute Direction

Value IN hat,

DANN: erzeuge eine Quelle.

ELSE: erzeuge eine Senke.

Regel 3: Erzeugen einer Verbindung:

WENN: Regel 1 und 2 zutreffend,

DANN: erzeuge Verbindung (=InternalLink) zwischen den Schnittstellen der

Quelle/Senke und der geschnittenen Funktion.

Zum Schluss müssen die notwendigen Informationen aus den Attributen übergeben werden.

Regel 4: Integration von Objektinformationen:

WENN: Objekttyp Quelle/Senke instanziiert und Verbindungen vorhanden,

DANN: integriere die Attribute der geschnittenen Funktion außerhalb des Teilmodells

als Attribute des erzeugten Objekts Quelle/Senke, um die Parameter der

Funktion zu übergeben.

83

7.3 Teilmodellerstellung eines GA-System-Modells

Aus dem gesamten Modell werden im Folgenden die drei angesprochenen Möglichkeiten der

Teilmodellerstellung (ortsstrukturell, funktional und produktstrukturbasiert) vorgestellt.


Zur Teilmodellerstellung aus einem GA-System-Modell wird zunächst ein Beispiel in

Abbildung 37 eingeführt und erläutert. In der Abbildung ist ein Ausschnitt eines Gebäudes

dargestellt. In diesem Ausschnitt ist ein Teil des Bereichs 1 mit den Räumen 1 und 2 sichtbar.

Der Raum 2 hat zwei Segmente (1 und 2). Es sind Funktionen auf der Hierarchieebene des

Gebäudes, des Bereichs, des Raumes und des Segmentes vorhanden, welche gemäß

Abbildung 37 miteinander verbunden sind.

Abbildung 37: Beispiel für die Teilmodellerstellung

Am Gebäude sind zwei Sensoren angebracht, ein Helligkeitssensor und ein Sensor zur

Sonnenstandsberechnung. Der Bereich 1 hat die Funktion Energieniveau mit Optimierung,

welche sich auf alle Räume und Segmente im Bereich 1 auswirkt. In den Räumen ist jeweils

eine Dämmerungsschaltung verplant, welche anhand der Informationen durch den

Helligkeitssensor des Gebäudes die Lichtstärke im Raum regelt und zusätzlich durch einen

Taster auch manuell bedient werden kann. Im Raum 2 sind die Lichtaktoren und Lichttaster

auf Ebene des Segmentes ausgeplant, damit in jedem Segment das Licht bedient werden

kann. Beide Räume verfügen zudem über eine Verschattungskorrektur, welche die Jalousie

abhängig vom Sonnenstand stellt, damit keine Blendung im Raum entsteht. Diese kann

ebenfalls durch einen Taster manuell bedient werden. Die Funktion Temperaturregelung

Heizen ist im Raum 1 und den beiden Segmenten von Raum 2 ausgeplant und bekommt die

aktuelle Raum-/ Segment-Temperatur durch jeweils einen Sensor zur

Lufttemperaturmessung. Durch das Raumbediengerät im Raum 1 beziehungsweise in

Segment 1 und 2 können Nutzer Sollvorgaben für die Raumtemperatur eingeben. Die Funktion

84


Energieniveau mit Optimierung beinhaltet Sollvorgaben für beide Räume und deren

Segmente, welche z.B. die Absenkung der Temperatur über Nacht enthalten können.

In der Abbildung 37 sind der Übersichtlichkeit halber nicht alle Verbindungen als Pfeile

eingezeichnet, die gleichfarbigen Blöcke untereinander werden in diesem Beispiel als

funktionierend miteinander verbunden angenommen.

7.3.1 Ortsstrukturelle Teilmodellerstellung

Unter dem ortsstrukturellen Teilmodell kann die Aufteilung eines Gebäudes in Teilmodelle

gemäß dem eingeführten Ortsmodell verstanden werden. Dazu muss zunächst festgelegt

werden, welcher Teil des Gebäudes betrachtet werden soll, um einer Fragestellung bzw.

Untersuchung gerecht zu werden. Aufgrund der beschränkten Granularität von der Schale

Segment bis zur Schale Gebäude, ergeben sich damit sieben verschiedene Möglichkeiten der

ortsstrukturellen Teilmodellerstellung:

• das Gebäude in der Gesamtbetrachtung (entspricht dem Gesamtmodell),

• die Schale Gebäude ohne enthaltene Ortselemente,

• ein gesamter Bereich,

• die Schale Bereich ohne enthaltene Ortselemente,

• ein gesamter Raum,

• die Schale Raum ohne enthaltene Ortselemente,

• und ein Segment.

Im Folgenden werden diese verschiedenen Möglichkeiten und ihre Ziele der jeweiligen

Teilmodellerstellung erläutert. Das Gesamtmodell besteht bereits und bildet daher die

Ausgangslage für die Teilmodellerstellung. Wird ein Element einer Ortsstruktur betrachtet, so

gibt es zwei Varianten. Entweder das Element wird inklusive seiner beinhalteten, in der

Ortshierarchie niedrigeren Elemente, betrachtet (am Beispiel in Abbildung 37: Raum 2

inklusive der Segmente 1 und 2) oder ohne diese Elemente (Raum 2 ohne Betrachtung der

Segmente). Hat ein Ortselement keine weiteren Ortselemente, so entfällt diese

Unterscheidung (siehe Raum 1 in Abbildung 37).

In Abbildung 38 wird das Teilmodell des Gebäudes aus dem Beispiel in Abbildung 37 ohne die

enthaltenen Ortselemente (gelbe Umrandung) betrachtet. Ziel dieser Teilmodellerstellung ist

das Erkennen von Funktionen, welche Gebäudeübergreifend benötigt werden und welche

Schnittstellen diese Funktionen haben. In diesem Beispiel haben der Helligkeitssensor und die

Sonnenstandsberechnung jeweils zwei Schnittstellen zu den zwei Dämmerungsschaltungen

und Verschattungskorrekturen in Raum 1 und Raum 2. Da alle InternalLink-Interface Attribute

die Direction Value OUT haben, müssen diese Schnittstellen als Senken definiert werden. In

der Abbildung 38 sind daher vier Senken (roter Kreis mit S in der Mitte) dargestellt, welche die

Schnittstellen an den Grenzen des Teilmodells markieren.

85


Abbildung 38: Teilmodell Gebäude ohne enthaltene Ortselemente

In Abbildung 39 ist die InstanceHierarchy dieses Beispiels auf den hier relevanten Bereich

zusammengefasst. Da die Funktionen, welche auf der Ortshierarchieebene des Gebäudes

ausgeplant sind, am Ende der InstanceHierarchy stehen, wird für diese Teilmodellerstellung

der Bereich 1 und darin enthaltenen Informationen ausgeklammert. Relevant für ein Teilmodell

des Gebäudes sind die InternalLinks und deren –Interfaces der Schale Gebäude, welche

gemäß Abbildung 30 am Ende der Auflistung der Modellinformationen innerhalb der

AutomationML- Datei stehen.

Abbildung 39: InstanceHierarchy des Beispiels

In Abbildung 40 sind die beiden Möglichkeiten der Teilmodellerstellung für den Bereich 1 aus

dem vorgestellten Beispiel zu sehen. Oben wird ein Teilmodell ohne die enthaltenen

Ortselemente erstellt und unten mit den enthaltenen Ortselementen und deren Funktionen.

Ziel der oberen Darstellung ist das Erkennen der Funktionen, die der Schale „Bereich“

zugeordnet sind und deren Auswirkungen auf innenliegende Schalen, ggf. Auswirkungen von

der Schale Gebäude auf Funktionen, welche nur dem Bereich zugeordnet sind (nicht

dargestellt). In diesem Fall hat die Funktion Energieniveau mit Optimierung drei InternalLinks,

welche geschnitten und durch drei Senken ersetzt werden.

86


Abbildung 40: Zwei Varianten für das Teilmodell Bereich (oben ohne enthaltene Ortselemente

und unten mit enthaltenden Ortselementen)

87


In der unteren Darstellung wird das Teilmodell Bereich inklusive seiner integrierten Elemente

betrachtet. Aufgrund dessen, dass das Beispiel nur einen Bereich hat, ist dieses Beispiel der

Gegenpart zum Teilmodell aus Abbildung 38. Ziel dieser Teilmodellerstellung kann es sein,

die Auswirkungen der Funktionen des Gebäudes auf den Bereich zu erkennen und eine eigene

Performanceanalyse eines Bereichs durchzuführen.

Weiter wird in Abbildung 41 die vergleichbare Darstellung für die zwei Varianten der

Teilmodellerstellung des Raumes 2 vorgestellt. Im oberen Teil des Bildes ist der Raum ohne

seine Segmente und im unteren Teil mit seinen Segmenten als Teilmodell ausgeschnitten.

Dies führt dazu, dass im oberen Bild zwei Quellen und zwei Senken erstellt werden müssen.

Im unteren Bild werden diese beiden Senken nicht dargestellt, da die Funktion

Dämmerungsschaltung zwei Verbindungen zu den Lichtaktoren in jedem Segment hat. Bei

Betrachtung des Raumes als Ganzes, inklusive der Segmente, gibt es bei dieser Funktion

daher keine Schnittstelle. Stattdessen wird jedoch die Schnittstelle der Funktion Energieniveau

mit Optimierung mit zwei Schnittstellen zu der Funktion Temperaturregelung Heizen als Quelle

deutlich. Ziel der oberen Variante ist es, die Funktionen, die der Schale Raum zugeordnet sind

und Auswirkungen von äußeren/ inneren Schalen zu erkennen. Auch bei einem Teilmodell

eines Raumes (mit oder ohne Segmente) kann die Leistungsfähigkeit der Funktionen durch

eine Simulation analysiert werden. Die Betrachtung des Raumes 1 hat in der ortsstrukturellen

Teilmodellerstellung keine zweite Variante, da dieser im Beispiel keine Segmente hat.

In Abbildung 42 ist das Teilmodell des Segmentes 2 dargestellt. Da das Segment die kleinste

Einheit innerhalb der Ortselemente ist, kann es auch hier jeweils nur eine Variante des

Teilmodells geben. In diesem Fall werden zwei Quellen benötigt, um das Teilmodell zu

erstellen. Ziel dieser Teilmodellerstellung ist ebenfalls das Erkennen der Auswirkungen von

äußeren Schalen und deren Funktionen auf das Segment und auch dieses Segment kann als

Teilmodell analysiert werden.

Für alle Teilmodelle der ortsstrukturellen Teilmodellerstellung kann ein weiteres Ziel die

Auflistung von Funktionen des ausgewählten Ortselementes sein. Durch die Erstellung der

Schnittstellen, können diese als eine Grundlage für Absprachen zwischen den Gewerken oder

Firmen dienen.

88


Abbildung 41: Zwei Varianten für das Teilmodell Raum (oben ohne enthaltene Ortselemente und

unten mit enthaltenden Ortselementen)

89


Abbildung 42: Teilmodell eines Segments

7.3.2 Funktionale Teilmodellerstellung

Eine zweite Art der Teilmodellerstellung kann auf der Grundlage der funktionalen Struktur

erfolgen. Diese basiert auf einzelnen Funktionszusammenhängen und ist nicht an die Grenzen

der Ortsmodelle gebunden. Dadurch können gebäudeübergreifend Funktionsketten betrachtet

werden.

Die funktionale Teilmodellerstellung kann, je nach Fragestellung, sowohl die Funktionsstruktur

als auch die Produktstruktur berücksichtigen. In der Abbildung 43 ist die funktionale

Teilmodellerstellung mit zwei Varianten anhand des in Absatz 7.3.1 eingeführten Beispiels

dargestellt. Im oberen Teil der Abbildung 43 ist die Funktionskette der Heizungsregelung in rot

hervorgehoben und ist hier als geschlossener Funktionsverbund dargestellt. Daher ist in

diesem Beispiel keine Schnittstelle vorhanden. Eine Schnittstelle würde dann auftauchen,

wenn wiederum nur ein Teil dieser Funktionskette betrachtet werden soll. Anhand der

Abbildung 43, unten ist eine Variante dargestellt, welche im kleinsten Teilmodell nur eine

einzelne Funktion betrachtet. Ziel der Betrachtung einer einzelnen Funktion, ist beispielsweise

die Funktionsüberprüfung dieser Funktion, das Erkennen von Verbindungen und Schnittstellen

dieser Funktion bei der Parametrierung oder dem Austausch eines Gerätes oder die Analyse

der Auswirkungen dieser Funktion auf eine Funktionskette. Ziel der Betrachtung der gesamten

Funktionskette ist die Betrachtung einer gesamten Regelstrecke, eine Analyse der

Leistungsfähigkeit der gesamten betrachteten Regelstrecke beispielsweise durch Simulation

oder die Erstellung einer Funktionsliste für ein Gewerk oder eine Firma. Bei der funktionalen

Teilmodellerstellung sind auch Teilmodelle zwischen diesen beiden Beispielen von einer

Funktion bis hin zur ganzen Regelstrecke möglich.

90


Abbildung 43: Funktionale Teilmodellerstellung (oben gesamter Funktionsstrang; unten

Betrachtung einer einzelnen Funktion)

91


Wird eine Funktion oder eine Funktionsstruktur aus dem GA-System-Modell

herausgeschnitten, entstehen folgende Schnittstellen in der Funktionsstruktur:

• zu Funktionen des gleichen Ortselementes,

• zu Funktionen von übergeordneten Ortselementen,

• zu Funktionen von integrierten Ortselementen.

Natürlich bleibt die Beziehung einer Funktion zu einem Ortselement erhalten, die Grenzen der

Ortselemente werden jedoch nicht betrachtet.

Zur Ermittlung der Schnittstellen wird die erste Regel umgewandelt:

WENN: Eine Verbindung der betrachteten Funktion zu anderen Funktionen besteht,

UND: diese Funktionen nicht mehr Bestandteil des Teilmodells sind,

DANN: überprüfe Typ der Verbindung (Verbindung der Funktionsstruktur oder

externe/interne Verbindung der Produktstruktur),


Regel 2 bis Regel 4 bleiben erhalten, um das Teilmodell entsprechend zu vervollständigen.

Im vorliegenden Beispiel kann aus dem Teilmodell eine Liste an Funktionsverbindungen

generiert werden, die beim Einbau berücksichtigt werden müssen. Nach derselben Methode

können zusammengehörende Funktionsstrukturen, wie beispielsweise die gesamte

Lichtschaltung des Gebäudes, betrachtet werden, um diese zur Ausschreibung und/oder

Installation durch eine Ausführungsfirma vorzubereiten.

7.3.3 Teilmodellerstellung der Produktstruktur

Die produktbasierte Teilmodellerstellung ist per Definition von der entsprechenden

Produktstruktur und deren Implementierung im Modell abhängig, siehe Abschnitt 6.4.

Ist die Produktstruktur in einem GA-System-Modell durch interne und externe Verbindungen

abgebildet, so kann die Betrachtung der Produktstruktur wie im vorherigen Abschnitt 7.3.2

dargestellt erfolgen indem die Einschränkung gemacht wird, dass nur die Verbindungen der

Produktstruktur betrachtet werden.

Bei einem dezentralen GA-System, welches über einen Feldbus kommuniziert, kann ein

Teilmodell der Produktstruktur erstellt werden, indem alle Verbindungen der Funktionen zu

dem integrierten Feldbus- InternalElement betrachtet werden. Hat ein dezentrales GA-System

mehrere einzelne Feldbusse, beispielsweise bei der Verwendung von Subsystemen, wie dem

DALI-Lichtbus, müssen diese auch entsprechend abgebildet werden. Auch bei sehr großen

Gebäuden kann die Einrichtung eines dezentralen GA-Systems über nur einen Feldbus zu

sehr langen Antwortzeiten führen. Diese können durch eine Simulation zuvor ermittelt werden

und dann eine Zergliederung des Feldbusses (zu einem Multimaster-Bus) in unabhängige

Subsysteme zur Folge haben. Weiterhin berücksichtigt die Produktstruktur die

Gerätekonfiguration, welches dann erheblich wird, wenn mehrere Funktionen in einem Gerät

integriert sind. Ziel der Teilmodellerstellung anhand der Produktstruktur ist die Analyse der

tatsächlichen, physikalischen Verbindungen. In Abbildung 44 wurden die Funktionen des

Beispiels auf einen Feldbus (grün) und einen eigenen Lichtbus (orange) ausgeplant. Durch die

92


Teilmodellerstellung kann jeder Feldbus getrennt betrachtet und analysiert werden, um

beispielsweise die Auslastungen durch eine entsprechende Simulation zu erkennen.

Wird nur ein Teil eines Feldbusses betrachtet, entstehen erneut Schnittstellen, welche

entsprechent erzeugt und verbunden werden müssen.

In diesem Fall wird die Regel 1 folgendermaßen umgewandelt:

WENN: Eine Verbindung einer Funktion des betrachteten Produktstrukturausschnitts zu

einer Funktion außerhalb dessen existiert,

DANN: überprüfe Typ der Verbindung,


Da auf einem Feldbus die Informationen in beide Richtungen fließen, ist ein neutrales

Terminierungsobjekt notwendig, welchem die Informationen über die abgeschnittene Funktion

übergeben werden.

Regel 2 Festlegen der einzufügenden Objektart:

WENN: Das InternalLink-Interface der Funktion im betrachteten

Produktstrukturausschnitt als Attribute Direction Value IN and OUT hat,

DANN: erzeuge ein neutrales Terminierungsobjekt.

Die Regel 3 und Regel 4 bleiben auch in diesem Fall unverändert.

Abbildung 44: Produktbasierte Teilmodellerstellung

93


Für das aufgeführte Beispiel können die Funktionsverbindungen der logischen

Funktionsstruktur vernachlässigt werden, wenn nur die reine Produktstruktur relevant ist. Die

Informationen zu der logischen Funktionsstruktur kann aber je nach Fragestellung durchaus

interessant sein, gerade wenn beispielsweise die Thematik der Prioritätssteuerung auf einem

Feldbus betrachtet werden soll. Können bei zu hoher Busauslastung nicht alle Telegramme

auf einem Feldbus übertragen werden, können niederpriore Telegramme eventuell erst durch

mehrfache Sendeversuche übertragen werden. Durch die aufgezeigte Möglichkeit der

Simulation können solche Charakteristiken eines Feldbusses identifiziert und entsprechend

überprüft werden. Durch eine Anpassung der Prioritätssteuerung muss sichergestellt werden,

dass wichtigere Informationen vor unwichtigeren Informationen übertragen werden.

94


7.4 Erstellung von Funktionslisten

Im Rahmen der gewerkegetrennten Ausschreibung, Feinausplanung und der späteren

Installation ist die Erstellung von Funktionslisten eine weitere Möglichkeit auf die Bedürfnisse

des gewerkegetrennten GA-Planungsprozesses einzugehen. Diese Funktionslisten können

entweder aus dem GA-System-Modell als Ganzes oder aus spezifischen Teilmodellen erstellt

werden. Gerade bei der Verwendung von großen GA-Systemen mit vielen Funktionen kann

das händische Erstellen von Funktionslisten eine mühsame Arbeit sein. Durch das

herstellerneutrale und XML-basierte Datenformat von AutomationML ist es möglich

Funktionslisten und weitere Abfragemöglichkeiten durch den Import in relationale

Datenbanksysteme zu vereinfachen.

Relationale Datenbanksysteme können Beziehungen aus beispielsweise einem ERM

berücksichtigen und über diese Beziehungen die unterschiedlichen Zusammenhänge

zwischen Datenbankeinträgen darstellen. Bezogen aus das GA-System-Modell bestehen die

Zusammenhänge zwischen Ortselementen, Funktionen und deren verschiedenen

Verbindungen zueinander (Funktions- und Produkstruktur). Das ERM dazu ist in Abbildung 27

dargestellt. Für eine einfachere Darstellung werden die Entitäten zu drei Datensätzen

zusammengefasst: die Ortselemente, die Funktionen und die Verbindungen zwischen den

Funktionen. Das komplexe ERM, inklusive der Attribute, kann durch Erstellen von einzelnen

Datensätzen für jede dargestellte Entitätengruppe erweitert werden. Für die Prinzipdarstellung

wird hier die vereinfachte Form mit drei Datensätzen am Beispiel der relationalen Datenbank

Access von Microsoft, siehe Abbildung 45, dargestellt.

Abbildung 45: Darstellung der ERM Beziehungen zwischen den Datensätzen

Die Datensätze der Ortsstruktur bestehen aus einer ID Ort, welches die laufende Nummer des

Datensatzes ist, dem Ortselement, als Bezeichnung und dem übergeordneten Ortselement,

welches auf das übergeordnete Ortselement gemäß der 1:n Beziehung der Ortsstruktur

verweist. Da die 1:n Beziehung nicht mit dem gleichen Kontainer verbunden werden kann,

muss der Kontainer der Datensätze kopiert werden und als Hilfskontainer Ortsstruktur_1

verbunden werden. Statt 1:n verwendet Access 1:∞ als Symbolik.

95


Jedem Ortselement können mehrere Funktionen zugeordnet werden. Diese 1:n Beziehung

wird zu einem weiteren Datensatzkontainer der Funktionen hergestellt. Die Datensätze der

Funktionen enthalten die ID (laufende Nummer), den Funktionsnamen, die ID AML (Global ID,

welche AutomationML vergibt), die ID Ort (aus der Ortsstruktur) und zusätzlich das

zugeordnete Gewerk. Um die n:m Beziehung zwischen den Funktionen darzustellen, wird ein

weiterer Datensatzkontainer der Verbindungen gebraucht, da Access lediglich 1:n

Verbindungen verarbeiten kann. In den Datensätzen der Verbindungen stehen die ID

(laufende Nummer), ID AML A und ID AML B, welche die Global IDs aus Automation ML sind

von den beiden Funktionen, die miteinander über einen InternalLink verbunden sind. Daneben

wird ein weiterer Hilfskontainer benötigt, welcher eine Kopie der Datensätze der Funktionen

ist (Funktionen_1). Die n:m Beziehung wird aufgelöst indem jeder ID AML aus den

Datensätzen der Funktionen mehrere Datensätze im Kontainer der Verbindungen ID AML A

zugeordnet werden können. Umgekehrt ist jedem Datensatz der ID AML A genau ein

Datensatz aus den Datensätzen der Funktionen zugeordet. Ebenso ist jedem Datensatz aus

ID AML B (also der verbundenen Funktion) genau ein Datensatz aus dem Hilfskontainer der

Funktionen zugeordnet. Durch diese beiden 1:n Beziehungen wird die eigentliche n:m

Beziehung aufgeschlüsselt. Dabei muss die Entität, welche die einfache Beziehungsrelation

hat, als Primärschlüssel festgelegt werden. Das bedeutet, dass innerhalb dieses Kontainers

jeder Datensatz nur einmal mit dem ausgewählten Primärschlüssel vorkommt. Für die Liste

der Funktionen kommt jede Funktion mit der entsprechenden ID von AutomationML genau

einmal vor. Die Funktionsbezeichnungen hingegen können häufiger in der Liste vorkommen.

Um die Datensätze aus AutomationML in die entsprechenden Kontainer in Access zu

importieren, können die Daten aus AutomationML in eigene Textdateien abgelegt und dann

von Access importiert werden. Die dazu benötigten Informationen stehen für die Ortsstruktur

bereits in Tabelle 6 und müssen um das Element Segment und die Darstellung der Funktionen

und Verbindungen in Automation ML erweitert werden.

Segment:

<InternalElement Name=„[S1-n]“ ID=„[IDS]“>

Das Segment ist als InternalElement genauso aufgebaut, wie die anderen Ortselemente. Die

Bezeichnung in den eckigen Klammern sind entsprechend variabel.

Funktion:

<InternalElement Name=„[F1-n]“ RefBaseSystemUnitPath=„[Pfad]" ID=„[IDF1-n]“>

Die Funktion ist ebenfalls als InternalElement innerhalb der AutomationML-Datei beschrieben,

diese hat jedoch nach dem Namen erst den Pfad der SystemUnitClass stehen und dann folgt

die Global ID von AutomatioML.

Verbindung:

<InternalLink Name=„[IL1-n]" RefPartnerSideA=„[IDF1-n]:[F1-n]“

RefPartnerSideB=„[IDF1-n]:[F1-n]“>

Die Verbindungen zwischen den Funktionen sind als InternalLinks dargestellt. Diese enthalten

erst die Bezeichnung des Links und dann kommt erst die eine Seite der Funktion

RefPartnerSideA mit der ID der entsprechenden Funktion und hinter dem Doppelpunkt der

Name der Funktion und dann die RefPartnerSideB, welche den Partner der Verbindung liefert,

ebenfalls mit der ID und dem Namen.

96


Um die Datensätze zu befüllen muss die AutomationML-Datei entsprechend ausgelesen

werden. In einem ersten Schritt werden die Datensätze der Ortselemente zusammengestellt.

Dazu wird mit dem InternalElement mit der RoleClass „Gebäude“ begonnen und anschließend

die jeweiligen integrierten Elemente mit der jeweiligen laufenden Nummer und seiner

Bezeichnung in Anführungszeichen aufgelistet. Dabei wird das übergeordnete Element durch

seine bereits vergebene laufende Nummer hinzugefügt. Als Trennung zwischen den

Elementen wird ein Komma verwendet und der Datensatz wird anschließend in Access, wie in

Abbildung 46 dargestellt, importiert. Als Beispiel wurde die AutomationML-Datei des bereits

erläuterten Beispiels aus Abbildung 37 verwendet.

1,"Gebäude",

2,"Bereich 1",1

3,"Raum 1",2

4,"Raum 2",2

5,"Segment 1",4

6,"Segment 2",4

Abbildung 46: Auszug Textdatei (links) und Access-Tabelle (rechts)

Die Funktionen werden mit ihrer Bezeichnung, der Global ID und dem zugehörigen

Ortselement übernommen und als eigene Textdatei abgespeichert. In Abbildung 47 ist ein

Auszug aus der Beispieldatei bereits in Access dargestellt. Jeder Funktionsbezeichnung kann

zusätzlich ein Gewerk oder auch eine Ausführungsfirma zugewiesen werden. Diese

Informationen sind jedoch nicht in AutomationML hinterlegt und bedürfen einer separaten

Zuordnung zwischen allgemeinen Funktionsbezeichnungen und den Gewerken oder Firmen,

welche einmal händisch als Quelle erstellt werden muss und dann wiederverwendet werden

kann.

Abbildung 47: Auszug aus der Access-Tabelle der Funktionen

Die InternalLinks werden mit einer laufenden Nummer und nur der Global ID von

Verbindungspartner A und der Global ID von Verbindungspartner B übernommen.

Durch die Trennung der Bezeichnungen und Nummern mit dem Komma, kann Access die drei

Tabellen automatisch importieren und als neue Datensätze hinzufügen. Durch die bereits

hergestellten Beziehungen zwischen den Kontainern der Datensätze können im Anschluss

Abfragen der Funktionslisten erstellt werden.

97


Abbildung 48: Abfrage in Access nach Funktionszusammenhängen

In Abbildung 48 ist ein Auszug aus einer Abfrage nach den Funktionszusammenhängen

gestellt worden. In der dritten Spalte steht die Funktion und ihr zugehöriges Ortselement. In

der ersten und zweite Spalte stehen die jeweiligen Vorgängerfunktionen mit Ortselement und

in den Spalten fünf und sechs stehen die Nachfolgefunktionen mit ihren Ortselementen. Die

leeren Tabellenplätze bedeuten, dass es keine weitere Nachfolgefunktion gibt.

Eine weitere Abfrage des Beispiels ist auszugsweise in Abbildung 49 dargestellt. Hier werden

Funktionen mit ihrem zugeordneten Gewerk angezeigt in Spalte eins und zwei und die damit

verbundenen Funktionen mit ihren zugeordneten Gewerken in Spalte drei und vier. In der

dritten Zeile ist hier zu sehen, dass die Funktions Brightness_Measurement

(Helligkeitsmessung) eine Verbindung zur Funktion Twilight_Control (Dämmerungsschaltung)

hat, welche jedoch unterschiedliche Gewerke betreffen. Aus einer solchen Abfrage können

Schnittstellen zwischen den Gewerken ersichtlich werden, welche dann zur Absprache der

Schnittstellen genutzt werden können.

Weitere Abfragen bezüglich der Funktionen, ihrer Ortselemente oder Verbindungen sind

vielfältig möglich. Beispielsweise ist das Erstellen einer Liste aller Lichtaktoren oder einer Liste

aller Funktionen eines Bereichs, inklusive seiner integrierten Ortselemente und deren

Funktionen über entsprechende Abfragen möglich.

Abbildung 49: Sortierung nach Gewerken und Nachfolgefunktion

Durch einen weiteren Konverter können die angesprochenen Informationen des GA-System-

(Teil)-Modells aus der Datenaustauschdatei von AutomationML automatisch ausgelesen, in

einer Textdatei zwischengespeichert und dann in eine relationale Datenbank, wie

beispielsweise Access überführt werden, um Funktionslisten u.a. Abfragen zur Unterstützung

des gewerkegetrennten GA-Planungs- und Installationsprozesses zu erstellen.

98

8 Aus- und Bewertung der Ergebnisse


Um den Nutzen des vorgestellten durchgängigen und modellbasierten Engineerings zu

untersuchen, ist eine Validierung notwendig. Diese soll zeigen, dass die vorgestellte Methode

im Vergleich zu anderen Ansätzen oder praktischen Umsetzungen und trotz des

Mehraufwandes einen Mehrwert bringt. Zur Validierung dieses Ansatzes wurde zum einen die

Planung eines Bauprojektes mit der Ausstattung von RA begleitet. Aufgrund dessen, dass ein

einzelnes Bauprojekt im Rahmen einer Validierung zu wenig Aussagekraft besitzt, wurde

weiterhin eine Befragung unter Experten aus der GA, den Architekten und den Bauherren

durchgeführt. Weiterhin wird der vorgestellte Ansatz durch den Anforderungskatalog aus

Kapitel 3 auf die Erfüllung der Anforderungen überprüft. Abschließend werden die

Einschränkungen des Ansatzes in Hinblick auf die Konsequenzen für die Praxis bewertet und

eine mögliche Übertragbarkeit des Ansatzes vorgestellt.

8.1 Erfahrungen im Rahmen eines Bauprojektes

Die Firma Tributech GmbH ist eine kleine, mittelständische Vertriebsfirma, die Schmierstoffe,

Öle, Fette und Festschmierstoffe vertreibt. Zur Erweiterung ihres Portfolios wurde eine neue

Lagerhalle mit Bürokomplex benötigt. Das neue Gebäude wurde aus Fertighausmodulen in

Leichtbauweise erstellt, und sowohl der Hallenteil als auch der Bürokomplex sollten mit RA-

Funktionen ausgestattet werden. Im Rahmen der Validierung dieses Ansatzes wurden der

Bauherr und der Objektplaner durch den Planungsprozess begleitet.

8.1.1 Struktursegmentierung

In einem ersten Schritt ist die Struktursegmentierung des kombinierten Hallen- und

Bürokomplexes notwendig. Dazu wurde der Grundriss des Gebäudes genommen und in

Bereiche, Räume und Segmente eingeteilt. Aufgrund der Größe der Halle wurden 13

Achsensegmente zur Unterteilung der Halle verwendet und dem Bereich Halle untergeordnet,

siehe Abbildung 50. Der angrenzende Bürokomplex besteht aus zwei Etagen. Jeder Etage

wurde ein eigener Bereich zugeordnet, der jeweils acht Räume umfasst.

99


Abbildung 50: Struktursegmentierung des Hallen-Büro-Komplexes

100


Daraus ergibt sich folgende Ortsstruktur für den Hallen-Büro-Komplex (Abbildung 51):

Abbildung 51: Ortsstruktur des Hallen-Büro-Komplexes in AutomationML

Die Segmente der Ortsstruktur wurden durch die Customizing-Funktion der Ortsstruktur

hinzugefügt. Diese Ortstruktur kann nun als Ausgangsbasis für die Anforderungserhebung

dienen.

8.1.2 Anforderungserhebung

Die Segmente der Halle sollen hauptsächlich der Einteilung der Lichtleisten dienen, um die

Halle entsprechend auszuleuchten. Dazu wurde in jedem Segment eine einzelne

Automatiklicht-Funktion ausgeplant, die über Präsenzdetektoren aktiviert wird. Da die Halle

hauptsächlich als Lagerhalle konzipiert ist, werden nicht immer alle Hallenteile gleichzeitig

benötigt, sondern nur diejenigen, an denen Regale befüllt bzw. Produkte entnommen werden.

Gerade die äußeren Hallensegmente werden dadurch erheblich zur Energieeinsparung

beitragen, weil der Hauptumschlag in den mittleren Regalen stattfinden und überall die

Beleuchtung nur bei tatsächlichem Betrieb eingeschaltet wird.

Der Bürokomplex mit den zwei Etagen ist grundsätzlich ähnlich zueinander aufgebaut.

Ausgehend vom Treppenhaus dient ein schmaler Flur zur Verbindung der einzelnen Büros

und Besprechungsräume. Im Treppenhaus befinden sich auch die Toiletten. Im Flur und im

Treppenhaus werden ebenfalls Automatiklicht-Funktionen eingeplant, um die Beleuchtung bei

Nichtverwendung zu schonen. In den Büroräumen wurde ähnlich wie beim 6-Funktionen-

Raum auch eine Energieauswahl-Funktion geplant, die mit Fenstersensoren verbunden ist.

Ebenfalls ist auch hier das Automatiklicht geplant. Die Energieauswahl-Funktion soll die

Heizung ansteuern, durch das Zeitprogramm die hauptsächlichen Arbeitszeiten in den Büros

abdecken und außerhalb der Nutzungszeiten die Heizungsenergie einsparen.

Nach diesen Vorstellungen des Bauherrn wurde gemeinsam mit dem Engineering-Werkzeug

zur Unterstützung der Anforderungserhebung das Engineering-Modell des Hallen-Büro-

Komplexes erstellt.

101


Abbildung 52: Ausschnitt aus dem GA-System-Modell des Hallen-Büro-Komplexes

In Abbildung 52 ist ein Ausschnitt aus dem Engineering-Werkzeug mit dem geplanten GA-

System-Modell dargestellt. Im oberen Teil sind die drei Funktionen zur Umsetzung der

Beleuchtung in den Achsensegmenten der Halle zu sehen. Exemplarisch sind in der Mitte der

Flur mit den gleichen Funktionselementen und ein Büro, das die zusätzlich ausgeplanten

Funktionen enthält, zu sehen.

8.1.3 Erstellung von Funktionslisten

Da sich der Bauprozess über die Bearbeitungszeit dieser Arbeit hinaus verzögert, sind eine

tatsächliche Umsetzung und Begleitung während des Bauprozesses nicht möglich. Zur

Vorbereitung der Ausführung wurden der Bauherr und der Objektplaner durch die Erstellung

von Funktionslisten und Teilmodellen in Hinblick auf die Ausschreibung der Aufträge

unterstützt. Auch wenn die grundsätzlichen Funktionen für die Automatiklicht-Steuerung in der

Halle und den Bürobereichen die gleichen sind, wurde in der Ausschreibung darauf geachtet,

dass spezialisierte Firmen die sehr großen Beleuchtungseinheiten der Hallensegmente

übernehmen. Dazu wurde der Hallenbereich einzeln als Teilmodell betrachtet und in Form

einer Funktionsliste zusammengestellt. Das Gleiche wurde für die beiden Bürobereiche

durchgeführt.

In Abbildung 53 ist ein Auszug aus der Funktionsliste der Halle von Tributech dargestellt. In

diesem Fall wurden die Funktionen, ihr Gewerk und ihr zugehöriger Ort mit der jeweils

verbundenen Funktion, ihrem Gewerk und Ort dargestellt. Über eine solche Tabelle konnten

die Schnittstellen, wie in der Abbildung markiert, zwischen den handelnden Gewerken erkannt

und überwacht werden. In diesem Falle war zu berücksichtigen, dass die Firma, welche die

Fenster mit Fenstersensoren einbaut, und die Firma, welche für die Energieniveau-Auswahl

zuständig war, sich über die Schnittstellen abgestimmt haben.

102


Abbildung 53: Funktionsliste der Halle Tributech

Da die Funktionslisten aus dem Modell heraus erzeugt werden konnten, hatten Bauherr und

Objektplaner den Vorteil, dass damit schnell grobe Kostenkalkulationen bei den Anbietern

möglich waren und der Überblick im Rahmen der Bauvorbereitungen nicht verloren ging. Somit

konnte sehr verzugslos mit der konkreten Beauftragung von Firmen begonnen werden.

8.2 Befragung von Experten

Zur Validierung des vorgestellten Ansatzes zum durchgängigen und modellbasierten

Engineering der Gebäudeautomation wurden in einem zweiten Schritt auch Experten befragt.

Im Rahmen dieser Expertenbefragung wurden Fachmeinungen aus den verschiedenen

Themenbereichen der GA und der Baubranche eingeholt. Ziel der Expertenbefragung war eine

Validierung des Ansatzes.

8.2.1 Auswahl der Experten

So wie verschiedene Sichtweisen bei der Planung und dem Bau von Gebäuden existieren, soll

durch die Auswahl der Experten eine einseitige Sichtweise auf dieses komplexe Themenfeld

vermieden werden. Daher ist es hilfreich, aus mehreren Blickwinkeln den vorgestellten Ansatz

zu bewerten.

Bei der Auswahl der Experten wurde der Fokus auf die alltägliche Praxis mit der GA gelegt.

Daher wurden Experten auf dem Gebiet der GA, Architekten und Objektplaner und Bauherren

großer Gebäude befragt. Dabei wurden sowohl Experten, welche den gewerkegetrennten und

auch Experten, die den integrierten GA-Planungsprozess befürworten, befragt.

In der Vorgehensweise wurden die Experten in einer ersten Kontaktaufnahme befragt, ob sie

sich für die Expertenmeinung zur Verfügung stellen würden. Die Befragungen der Experten

fanden entweder in einem Interview persönlich oder über Emailkorrespondenz statt. Für die

Interviews wurden ein Vortrag mit der Herleitung, Abgrenzung und Darstellung des Ansatzes

103


gehalten und im Anschluss standardisierte Fragen gemäß Anhang G gestellt. In den

persönlichen Gesprächen wurden die Antworten aufgenommen und anschließend

zusammengefasst. Die zusammengefassten Antworten wurden im Anschluss den

Teilnehmern noch einmal zur Mitprüfung vorgelegt und durch diese entsprechend auf

Richtigkeit der Angaben überprüft. Dieses Vorgehen soll einer Beeinflussung bei der

Beantwortung der Fragen und Missverständnissen vorbeugen. Des Weiteren konnten durch

diese Methode auch sprachliche Ungenauigkeiten oder falsche Zitationen verhindert werden.

Für die Befragung über die Emailkorrespondenz ergaben sich diese Fehlerquellen nicht, da

die Befragten Experten eine Stellungnahme zum vorgestellten Ansatz geschrieben haben. Der

Ansatz wurde in einer Zusammenfassung dieser Arbeit vorgestellt und durch die Anlage des

Vortrages ergänzt.

Die Ergebnisse aus den Expertenbefragungen werden anhand der Fragen des Fragebogens

in vier Abschnitte gegliedert:

a. Handlungsbedarf bei der Planung, Installation und dem Betrieb von GA-Systemen

(Frage 1),

b. Anforderungen an eine Methode um dem Handlungsbedarf zu begegnen (Frage 2),

c. Erfüllung der Anforderungen durch das durchgängige und modellbasierte Engineering

von GA-Systemen (Frage 3+4),

d. Verbesserung des Engineerings von GA-Systemen in Bezug auf Zeit, Kosten und

Qualität (Frage 5).

Darüber hinaus hatten alle Experten unter der Frage 6 die Möglichkeit, ein allgemeines

Feedback zum Ansatz zu geben. Dieses wurde für die Auswertung auf die entsprechenden

Fragen verteilt, um eine Vergleichbarkeit der Expertenmeinungen zu gewährleisten.

Im Folgenden werden die verschiedenen Experten kurz vorgestellt und ihr Bezug zur GA

erläutert. Im Weiteren werden anhand der vorgestellten Vorgehensweise die Ergebnisse

zunächst getrennt betrachtet und anschließend zusammenfassend bewertet.

8.2.2 Experten auf dem Gebiet der GA

Zu den führenden Experten auf dem Gebiet der GA zählt Hans R. Kranz. Herr Kranz hat

mittlerweile über 50 Jahre Berufserfahrung auf dem Gebiet der TGA und GA und hat damit die

GA in Deutschland maßgeblich mitentwickelt. Er war unter anderem als Projektleiter für

Europas erstes programmierbares GA-System (Honeywell-DELTA 2000) und zahlreiche

weitere Tätigkeiten als Projektmanager in der Branche aktiv. Seit 2004 ist er im Ruhestand

und nur noch ehrenamtlich aktiv. Das große Credo seiner langjährigen Erfahrung mit GA-

Systemen sind die Interoperabilität und die Standardisierung. Mit der Entwicklung von BACnet

[KRA13], als mittlerweile Quasi-Standard anerkannt, hat Herr Kranz ein internationales

Protokoll geschaffen, welches durch viele Kooperationen ständig weiterentwickelt wird.

Expertenmeinung von Herrn Kranz befindet sich in Anhang H.

Zu a) Herausforderungen bei der Planung, Installation und Betrieb von GA-Systemen

Herr Kranz sieht die Herausforderungen im Rahmen von GA-Systemen nicht nur bezogen auf

die Planung, Installation und den Betrieb. Darüber hinaus werden die Ausschreibung, die

Entwicklung und der Vertrieb ebenfalls als Herausforderungen benannt. Die Hauptprobleme

sieht Herr Kranz in der fehlenden Standardisierung, bzw. dem eigenen und bewusst nicht

kompatiblen Engineering der GA-Hersteller. Die im Ansatz genannten Herausforderungen

kann Herr Kranz bestätigen. Hinzu kommt, dass der Wettbewerb unter den GA-System-

104


Herstellern sehr groß ist und dass die Kostenfrage oftmals entscheidend ist. Bei den Kosten

hat gerade der unterschiedliche Engineering-Aufwand einen großen Einfluss.

Zu b) Anforderungen an die Methode

Um den Herausforderungen zu begegnen sollten auf standardisierten, EDV-fähigen

Funktionen und Modellen beruhende Konzepte verwendet werden. Die Standardisierung

gerade auch in Bezug auf die Interoperabilität sollte weiter ausgebaut werden. Hier kann

BACnet das passende Verbindungselement liefern, um gerade in der Verwendung mehrerer

GA-Systeme ein einheitliches Kommunikationsmodell zu verwenden.

Zu c) Erfüllung der Anforderungen durch die vorgestellte Methode

Den vorgestellten Ansatz befürwortet Herr Kranz. Das durchgängige, kompetente und alle

Gewerke umfassende Engineering mit der Unterstützung der gewerkegetrennten Ausführung

und Installation ist der richtige Ansatz zur Lösung der bestehenden Herausforderungen.

Da nur die Raumautomation im Rahmen des Ansatzes berücksichtigt ist, fehlt dem Ansatz

noch die Erweiterung um die Anlagenautomation und die Gebäudemanagement-Funktionen.

In der neuen VDI Richtlinie 3814 werden die laufenden Entwicklungen im Bereich der GA

angepasst und so wird die VDI Richtlinie 3813 in die neue VDI 3814 überführt, um ein

komplettes Standardwerk für die GA zu schaffen. Er empfiehlt den Ansatz um die GA-

Funktionen zu erweitern, auch bzw. gerade, weil die Anlagenautomation deutlich komplexer

als die Raumautomation ist.

Darüber hinaus wird gerade durch den VDI ein „Arbeitsblatt zur Bedarfserhebung“ für die

gesamte GA (inklusive AA und GAM) erarbeitet. Dieses wäre ebenfalls eine sinnvolle

Ergänzung zur Anforderungserhebung. Bezogen auf die Verwendung des Modells, hält Herr

Kranz eine Einbindung in BIM für aussichtsreich, auch wenn von Seiten der BIM dieses

Vorgehen noch nicht unterstützt wird. Dies liegt daran, dass das Datenformat .ifc noch keine

Beschreibungsstrukturen für die GA-Produkte und Funktionen hinterlegt hat und auch hier von

Seiten der Industrie keine vollumfängliche Unterstützung kommt. Das Schalenmodell ist für die

Raumautomation eine sinnvolle Einteilung der Gebäudestruktur. Bezogen auf einen

umfänglicheren Ansatz die ganze GA betreffend, reicht das Schalenmodell nicht aus. Statt

diesem hält Herr Kranz den Ansatz der „Structured View“-Idee von BACnet für denkbar, da es

aus seiner Sicht keine GA mehr gibt, die nicht mit BACnet kommuniziert.

Bezogen auf die Durchgängigkeit des Ansatzes hält Herr Kranz es für möglich, dass dadurch

Planungsfehler vermieden werden können, auch wenn dies sicherlich nicht gleichbedeutend

damit ist, dass trotz einer durchgängigen Planungsweise keine Fehler mehr passieren. Des

Weiteren bestätigt er eine leichtere Realisierung von GA-Systemen durch eine integrale

Betrachtung über alle Engineering-Phasen hinweg. Jedoch gibt er an dieser Stelle zu

bedenken, dass auf Seiten der Hersteller ebendiese Betrachtungsweise derzeit noch nicht

gewünscht ist und eher verhindert wird.

Zu d) Verbesserung in Bezug auf Zeit, Kosten und Qualität

Neben den bereits genannten Punkten zum Ansatz spart der vorgestellte Ansatz in jedem Fall

durch seine Rationalisierung Zeit und Kosten, vor allem durch die Vermeidung von Fehlern.

105


8.2.3 Experten aus dem Bereich der Bauherren

Bei der Auswahl der Experten als Vertreter der Bauherren war die Erfahrung beim Bau von

Nichtwohngebäuden wichtig. Des Weiteren sollten Erfahrungen mit GA-Systemen vorhanden

sein. Die Experten sind zum einen der Bauherr des Büro-Hallen Komplexes der Firma

Tributech, Herrn Reiff (Anhang I) und zum anderen Vertreter des Bundesamtes für

Infrastruktur, Umweltschutz und Dienstleistungen der Bundeswehr (BAIUDBw), welche als

Bauherren für die Bundeswehr Bauprojekte durchführen (Herrn Barnscheidt, Anhang J und

Herrn Pötzsch Anhang K).

Das BAIUDBw gehört zum Geschäftsbereich des Bundesministeriums der Verteidigung und

ist für die bundesweite Koordinierung der Dienstleistungen für die Bundeswehr zuständig.

Darunter fällt auch die Aufgabe, Infrastrukturmaßnahmen durchzuführen und dabei als

Ansprechpartner gegenüber den Baubeteiligten zu fungieren. Sie nehmen die Rolle des

Bauherrn für die Bundeswehr wahr und sind u.a. für die Erstellung und Prüfung von

Bauunterlagen zuständig.

Im Folgenden werden die Antworten der Experten zusammengefasst als Expertenmeinung

der Bauherren.


Konsens in den Expertenmeinungen besteht eindeutig darin, dass der Planungsaufwand durch

die Größe und Komplexität von Gebäuden und deren TGA und GA bestimmt wird und die

größte Herausforderung darin besteht, die gesammelten Anforderungen an ein Gebäude und

auch deren Risiken zu bestimmen.

In Hinblick auf die weiteren Herausforderungen gehen die Expertenmeinungen durch die

verschiedenen Blickwinkel auseinander.

Ein kleines und mittelständisches Unternehmen hat als Bauherr keine vorhandenen Expertisen

auf dem Gebiet der Bauplanung bzw. der Planung von GA. Daher ist das Unternehmen auf

Unterstützung durch externe Partner angewiesen. Für ein solches Unternehmen besteht die

große Herausforderung, Entscheidungen für ein Bauvorhaben zu treffen, obwohl sie die

Konsequenzen nicht alleine beurteilen können. Daher ist für das Unternehmen das

Architekturbüro bzw. der Objektplaner als zentrale Koordinierungsstelle wichtig, um zwischen

den Fachplanern und dem Bauherrn zu vermitteln. Ein großer Faktor für das Unternehmen

sind die Kosten, welche möglichst gering gehalten werden sollen.

Als Bundesbehörde hat das BAIUDBw eigene Experten und Vorschriften für den Bau von

Gebäuden und deren Ausrüstung. Häufig werden proprietäre GA-Systeme als homogene

Systeme in Form von Rahmenverträgen im integrierten GA-Planungsprozess realisiert. Die

Systeme werden von der Planung über die Installation bis hin zum Betrieb und der

Instandhaltung durch einen Ansprechpartner eines Herstellers betrieben und erleichtern damit

den Umgang mit den Systemen erheblich. Das Vorgehen, wie im gewerkegetrennten GA-

Planungsprozess beschrieben, kommt lediglich bei weniger aufwendigen Baumaßnahmen,

wie beispielsweise Unterkunftsgebäuden, vor. Eine wichtige Herausforderung für das

BAIUDBw ist die Überwachung der Maßnahmen und die Einhaltung der Vorgaben und

Standards. Abweichungen von den Vorgaben und Standards führen oft zu Nacharbeit,

Zeitverzug, höheren Kosten und gegebenenfalls auch Einschränkungen im Betrieb.

106



Konsens der Experten ist, dass der integrierte GA-Planungsprozess mit einem

verantwortlichen GA-Fachplaner zu bevorzugen ist, wonach der GA-Fachplaner die Planung,

Installation und den Betrieb eines GA-Systems übernimmt. Für den gewerkegetrennten GA-

Planungsprozess ist dageben die Verwendung eines Gesamtplanes wichtig. Weiterhin soll

eine Methode zielführend, handhabbar und anerkannt sein, um für alle Beteiligten die

Realisierung des Bauvorhabens zu unterstützen. Die Wahl der Methode und auch die Wahl

des Vorgehens im Bauprozess ist zu Beginn der Planung durch den Bauherrn oder

Objektplaner maßgebend für den weiteren Verlauf des Bauprozesses.


Alle Experten sind der Meinung, dass der vorgestellte Ansatz zielführend und schlüssig ist, um

die Realisierung der GA zu unterstützen. Durch die Verwendung des Modells und des

einheitlichen Datenkonzeptes können Planungsfehler vermieden werden.

Die wichtigen Punkte bei der Methode sind die Anforderungserhebung und die Aufteilung des

Modells auf die Gewerke. Hierbei sollte der Ansatz erweitert werden, um die Planungen der

Gewerke außerhalb der GA (siehe Abbildung 9, der konventionelle Bauprozess) mit den

Planungen der GA zu synchronisieren. Eine Integration des vorgestellten Ansatzes in die BIM-

Methode ist eine sinnvolle Einbettung.

Ein weiterer wichtiger Aspekt zur Beurteilung des Ansatzes ist die Verhältnismäßigkeit

zwischen dem Aufwand/ Kosten und dem Ergebnis. Der Aufwand und die Kosten des

Engineerings müssen durch die Einsparungen an Zeit und Kosten in der Realisierung und

durch Energieeinsparungen amortisiert werden.


Die Vermeidung von Fehlern führt dazu, dass auch Nacharbeit, Zeitverzug und höhere Kosten

vermieden werden. Die Überprüfungsmethode kann dabei helfen, die Konsequenzen aus

Fehlern geringer zu halten, da sie früher entdeckt werden können.

Die Ausführungsfehler können durch diesen Ansatz nicht vermieden werden und auch die

Einbindung der Planungen der TGA ist nicht berücksichtigt, daher ist der Ansatz im realen

Bauen nur bedingt einsetzbar. Weitere sinnvolle Erweiterungen wären die grafische

Aufbereitung der Planungen und die Gegenrechnung zwischen Einsparpotenzial der GA und

den aufzubringenden Kosten für die GA.

8.2.4 Experten aus der Architektur von Gebäuden und Objektplanung

Für die Branche der Architekten und Objektplaner wurden als Experten zum einen der

Objektplaner des Hallen-Büro-Komplexes der Firma Tributech (Herr Bonsels, Anhang L) und

zum anderen das Architekturbüro Immo Bau Peger Immobilien Planungs- und

Entwicklungsgesellschaft mbH (Frau Mehrwald, Anhang M) aus Kerpen interviewt und befragt.

Das Architekturbüro Immo Bau Peger arbeitet im privaten Wohnungsbausektor und hat viele

kombinierte Wohn- und Gewerbeimmobilien in der Rhein-Erft-Region realisiert.


Konsens der Expertenmeinungen auf diesem Gebiet ist die Herausforderung einer

Gesamtkonzeption des Gebäudes inklusive der GA vor Beginn der Bauphase, da mit

Einbindung der Fachplaner der Gewerke der Koordinationsaufwand zwischen den

107

8.3 Aus- und Bewertung der Ergebnisse

Baubeteiligten erhöht wird. Die Objektplaner und Architekten sehen sich dabei als zentrale

Ansprechstelle zwischen allen Baubeteiligten.

Die Einbindung des GA-Fachplaners, wie im integrierten GA-Planungsprozess dargestellt, ist

meist nicht die erste Wahl zu Beginn der Planungsphase, da sich viele Bauherren diese Kosten

sparen wollen. Erst im Laufe des Prozesses und oft auch erst deutlich nach Baubeginn stehen

die Ausplanungen von Seiten der Bauherren und der gewerkegetrennten Planungen bezüglich

des GA-Systems fest, was zu Verzögerungen in der Bauphase und zu Mehrkosten führt.


Der Bauprozess, so wie er heute ist, ist unübersichtlich und wird sich nur mühsam und langsam

von alleine ändern lassen. Eine Reformierung der gültigen Vorschriften und Regelungen und

vor allem eine Entfrachtung dieser wären dringend notwendig. Die stärkere Rolle der GA

innerhalb des Bauprozesses ist davon eine notwendige Änderung.

Die Anforderungen an das Gebäude müssen vor Baubeginn feststehen und sollten in allen

Gewerken durch ein einheitliches Datenkonzept vorhanden sein, um Schnittstellenproblemen

und Informationsverlusten vorzubeugen.


Der vorgestellte Ansatz bietet laut den Expertenmeinungen einen guten Mittelweg zwischen

dem Einschalten eines GA-Fachplaners und der Planung in den Gewerken. Die Strukturierung

des Gebäudes ist eine sinnvolle Methode, um alle Planungsvarianten einheitlich strukturieren

zu können und bei Bedarf zu erweitern.

Die Überprüfungsmethode wird als grundsätzlich positiv bewertet, jedoch werden die

Möglichkeiten verschiedene Szenarien zu testen als unnötig angesehen. Die

Anforderungserhebung ist dagegen deutlich wichtiger, da diese den Bauherrn dazu bewegt,

die Gedanken über das Gebäude zu konzentrieren und gemeinsam mit dem Objektplaner

einen Gebäudeplan zu erarbeiten.


Die Experten sehen in dem Ansatz Potenzial zur Verbesserung des Planungs- und

Ausführungsprozesses und der Kostenreduktion. Die Berücksichtigung der GA in den frühen

Planungsphasen kann Planungsfehler vermeiden und durch die gemeinsame Datenbasis

auch Schnittstellenfehler verringern.

Der Zeitgewinn durch diesen Ansatz wird nicht sehr hoch eingeschätzt, jedoch kann er die

zeitraubenden Planungs- und Ausführungsfehler verhindern und damit den Zeitverlust

verhindern.

Insgesamt wird der Ansatz aus Sicht der Experten der Architektur und Gebäudeplanung als

guter Mittelweg aus einer vollständigen Fachplanung der GA und der eher rudimentären GA-

System-Planung in den einzelnen Gewerken bewertet.

8.3 Aus- und Bewertung der Ergebnisse

Sowohl die Begleitung des Bauvorhabens des Hallen-Büro-Komplexes als auch die Befragung

der Experten haben dem Ansatz des durchgängigen und modellbasierten Engineerings ein

grundsätzlich positives Verbesserungspotenzial in Hinblick auf den konventionellen

Bauprozess und die gewerkegetrennte Realisierung von GA-Systemen bescheinigt. Gerade

die Vermeidung von Fehlern durch die standardisierte und integrale Betrachtung der GA als

108


ein Gesamtsystem und die Möglichkeit der Aufteilung dieses Gesamtsystems auf die

gewerkegetrennte Ausschreibung, Feinausplanung und Installation in Kombination mit der

Überprüfungsmöglichkeit stellen aus Sicht der Experten eine Verbesserung zum derzeitigen

Realiserungsvorgehen für GA-Systeme dar. Die Lücke, welche der konventionelle Bauprozess

im Vergleich zum optimierten Bauprozess lässt, kann durch den vorgestellten Ansatz in Teilen

geschlossen werden. Die Beschränkungen des Ansatzes werden in der Praxis zu weiteren

Herausforderungen führen, gerade was die Annahme der Interoperabilität angeht, da diese zu

einem hohen Integrationsaufwand führen wird, welcher ohne die Fachkenntnis eines

Systemintegrators nicht zu bewerkstelligen sein wird. Auch die Synchronisation mit den

weiteren Planungen der Gewerke außerhalb der GA und die Anbindung an die TGA werden

in der Praxis zu Herausforderungen.

Eine Integration der Toolkette in die vorhandene BIM-Methode und die entsprechende

Software stellt eine vermarktbare Realisierung des vorgestellten Ansatzes dar und ist aufgrund

der offenen und herstellerunabhängigen Auslegung auch denkbar.

Herr Kranz und Herr Barnscheidt kritisieren, dass die Betrachtung der Raumautomation nur

einen Teil der GA abdeckt und dass die wesentliche Herausforderung, die proprietäre

Einstellung der Hersteller, durch den bestehenden Ansatz nicht weiter betrachtet wird. Da dem

vorgestellten Ansatz eine solide Grundlage bescheinigt wird, sollte dieser Ansatz zukünftig auf

die AA und das GAM erweitert werden. Die Hinweise bezüglich der neuen Entwicklungen in

den Richtlinienreihen und dem BACnet sollten in weitergehenden Ansätzen dabei

Berücksichtigung finden.

8.4 Bewertung in Hinblick auf den Anforderungskatalog

Der in Kapitel 3 als Maßstab genommene Anforderungskatalog zur Abgrenzung und

Bewertung der bisher verfügbaren Engineeringmethoden für die GA muss nun abschließend

auch gegen den entwickelten Ansatz des durchgängigen und modellbasierten Engineerings

der GA gehalten werden, siehe Tabelle 7.

Der vorgestellte Ansatz baut auf der Lücke auf, die der konventionelle Bauprozess mit dem

gewerkegetrennten GA-Planungsprozess zum planerischen Vorgehen der DIN EN ISO 16484

und dem integrierten GA-Planungsprozess lässt. Das lösungsorientierte Vorgehen der Norm

setzt voraus, dass der Kunde sich bereits für einen spezifischen Hersteller eines GA-Systems

entschieden hat oder zu einem expliziten GA-Fachplaner kommt. Wie auch der Experte Herr

Kranz bestätigt hat, findet dieser erste Schritt in der Praxis wenig Anwendung.

Im gewerkegetrennten GA-Planungsprozess wird eine Methode benötigt, welche Bauherr und

Architekt durch eine toolgestützte Lösung darin unterstützen, im Rahmen der

Anforderungserhebung festzustellen, welche Funktionen eines GA-Systems durch den

Bauherrn gewünscht werden.

Um die Datenkonsistenz zu gewährleisten, beginnt der Prozess des GA-System-Engineerings

mit dem erstellten Grundriss als Planungsgrundlage. Durch die Struktursegmentierung wird

die hierarchische Struktur der Entitäten eines Gebäudes in ein Ortsmodell überführt. Dieses

dient im Rahmen der Anforderungserhebung als Grundlage zur Strukturierung des Modells,

welches durch Hinzufügen der RA-Funktionen zum Engineering-Modell wird. Dieses Vorgehen

unterstützt die Anforderung, dass beachtet wird, die Daten konsistent weiterzuverwenden.

Durchgängiges und modellbasiertes Engineering

109


Tabelle 7: Erfüllung der gestellten Anforderungen durch den vorgestellten Ansatz

Durch die Verwendung dieses Modells wiederum als Grundlage für die anschließende

Simulation und Parametrierung wird weiterhin die konsistente Datennutzung gewährleistet und

eine Überprüfungsmöglichkeit vor und nach der Installation und im Betrieb ermöglicht.

Die Bestandsdokumentation ist aus den Informationen im GA-(Teil-)-System-Modell heraus in

Teilen erstellbar. Dabei können die in der DIN EN ISO 16484 geforderten Funktionslisten und

die Funktionslogik aus dem Gesamtmodell heraus erstellt werden. Die

Herstellerdokumentation und die Einbaudokumentation können nur durch die im Rahmen des

Unterstützung der

Anforderungs-

Erhebung

Auf Basis der Grundrissdatei und den lösungsneutralen

Funktionen der VDI Richtlinie 3813 Blatt 2 werden Bauherr

und Architekt/Objektplaner toolgestützt unterstützt

Möglichkeit der

Bestands-

Dokumentation

Die vollständige Bestandsdokumentation kann aufgrund des

lösungsneutralen Ansatzes nicht komplett aus dem

dargestellten Ansatz heraus erfolgen. Die Funktionslisten und

auch die Funktionslogiken können jedoch aus dem GA-

System-Modell extrahiert werden.

Beachtung der

Datenkonsistenz

Aufgrund der durchgängigen Betrachtung, werden im Rahmen

der Anforderungserhebung alle vorhandenen Informationen

über das zu planende GA-System im Modell abgebildet und

aus diesem einen Modell auch wieder abgerufen.

Systemüberprüfung

in

Planung/Installation/

Betrieb

Die Überprüfungsmethode wird durch die Toolkette in

Zusammenarbeit mit dem Simulationstool Pi-Tool und der

Parametrierung des realen Systems „SmallCAN“ von der

Firma iQST bereitgestellt.

Möglichkeit der

Berechnung der

Energieeffizienz

(-Klasse)

Kein Bestandteil des vorgestellten Ansatzes, jedoch

Integration des „BACS Planning and Design Tool“ von

[GROŻ16] in die bestehende Toolkette des vorgestellten

Ansatzes grundsätzlich möglich.

Unterstützung des

gewerkegetrennten

GA-

Planungsprozesses

Der vorgestellte Ansatz baut auf der Lücke auf, die der

konventionelle Bauprozess mit dem gewerkegetrennten GA-

Planungsprozess zum planerischen Vorgehen der DIN EN ISO

16484 und dem integrierten GA-Planungsprozess lässt.

110


Modells abgelegten Informationen in Teilen ersetzt werden. Der vorgestellte Ansatz kann

lediglich die Bestandsdokumentation in Bezug auf die Funktionslisten unterstützen.

Die Energieeffizienzberechnung und die Angabe der Energieeffizienzklasse wurden in dieser

Arbeit nicht weiter betrachtet. Der Ansatz des „BACS Planning and Design“-Tools der

polnischen Universität Krakau in [GROŻ16] bietet dazu eine gut durchdachte Lösung. Das

vorgestellte Tool ist für die grundsätzliche Planung eines GA-Systems zwar nicht geeignet,

kann aber aufgrund der EN 15232 konformen Berechnungsmethode als sinnvolle Ergänzung

zum vorgestellten Ansatz dienen und könnte sicherlich in die Toolkette, beispielsweise nach

der Erstellung des Engineering-Modells, integriert werden. Das XML-basierte

Datenaustauschformat bietet die Möglichkeit die Informationen über einen Konverter dem

„BACS Planning and Design“-Tool zugänglich zu machen.

Im Fazit bleibt festzuhalten, dass der Ansatz trotz des unterschiedlichen Startpunktes in Bezug

auf das Engineering von GA-Systemen, die internationale Norm DIN EN ISO 16484

unterstützt. Sowohl die grundsätzlichen Phasen des Engineerings, wie auch die in der Norm

geforderten Überprüfungen, das Parametrieren der Anlage und die Bestandsdokumentation

werden im Rahmen des vorgestellten Ansatzes berücksichtigt. Weiterhin wird die

grundsätzliche Betrachtung des GA-Systems als ein System und unabhängig von der

gewerkegetrennten Betrachtung im Sinne der Norm übernommen und um die fehlenden

Anteile der aus der Praxis heraus entstandenen Lücke der verschiedenen Startpunkte ergänzt.

8.4.1 Beschränkungen des Engineeringansatzes

Der vorgestellte Ansatz des durchgängigen und modellbasierten Engineerings für GA-

Systeme unterliegt den gesetzten Einschränkungen, welche im Folgenden auf den

Praxisbezug hin untersucht und bewertet werden.

Im Rahmen der Begriffsbestimmungen dieser Arbeit wird die RA als Teil der GA behandelt

und meint damit die funktionale Umsetzung der GA in den einzelnen Räumen und bezieht sich

auf die RA-Funktionen, welche in ihrer allgemeinen Form in der VDI 3813 geregelt sind. Die in

Kapitel 2 aufgezeigten Vermischungen in den Begrifflichkeiten zwischen GA und RA werden

in der neuen VDI Richtlinienreihe 3814 durch klare und abgegrenzte Begriffsdefinitionen

ersetzt. Die Gültigkeit der bisherigen Begriffsbestimmungen führt jedoch dazu, dass die

Auswertung der Literatur auf den älteren, nicht eindeutigen Begriffen erfolgt und demzufolge

ein eindeutiges Verständnis und die Trennung von RA bzw. GA nicht gegeben ist.

Grundsätzlich wird die verwendete Literatur trotz der nicht eindeutigen Begrifflichkeiten vor

dem Hintergrund der RA als behandelter Teil der GA im Rahmen dieser Arbeit interpretiert und

verwendet.

Die Ausdehnung der RA auf die vollständige GA inklusive der GAM und AA wird einen

erheblichen Mehraufwand bedeuten. Diese Ausdehnung kann vor dem Hintergrund der sich

aktuell anpassenden Richtlinienlage erst mit der Ergänzung der Funktionen, um die GA-

Funktionen erfolgen. In der Praxis bedeutet diese Einschränkung, dass GA-Systeme, welche

vollständig mit der TGA verschmelzen, bezüglich des GAM und der AA nicht Bestandteil der

Toolkette sind und daher durch entsprechendes Fachwissen der Fachplaner ergänzt werden

müssen. Auch Teile des Ansatzes, wie u.a. das Schalenmodell als Segmentierung der

Infrastrukturdaten, sind lediglich auf die RA ausgelegt und müssten für die vollständige GA

entsprechend ergänzt werden. Eine entsprechende Alternative für die GA wird aktuell mit dem

Ansatz des Structured View des BACnet [KRA16] entwickelt.

111


Die weitere Einschränkung betrifft die GA-Systeme in ihrer Vielfältigkeit. Hier wurden aufgrund

der Spezialisierungen und proprietären Systeme die Heimsysteme und die Subsysteme nicht

betrachtet. Im Rahmen der Verwendung von lösungsneutralen Funktionen können auch diese

Arten von GA-Systemen durch den vorgestellten Ansatz geplant und ausgelegt werden.

Gerade bei den Heimsystemen ist der Aufwand der Planung jedoch unverhältnismäßig zum

Einsatz der einzelnen Geräte. Da diese Geräte als Nachrüstung lediglich eine Alternative zum

aufwendigen Aufbau von großen GA-Systemen sind, kann von einer richtigen Auslegung in

diesem Fall keine Rede sein. Bei den Subsystemen würde sich der Aufwand durch

Verwendung des vorgestellten Engineeringansatzes sicherlich verringern, dies müsste jedoch

durch eine eigene Studie erst bewiesen werden.

Eine weitere Voraussetzung für die vollständige Nutzung des vorhandenen Funktionsumfangs

ist die Herstellerneutralität und die Interoperabilität der Geräte und Anlagen. Die

Interoperabilität ist, wie aufgezeigt, ein sehr großes Forschungsgebiet der GA und wird durch

die weiterhin proprietären Entwicklungen der Hersteller auch nach wie vor ein Thema bleiben.

Die Ansätze des BACnet zur Standardisierung der Kommunikationssprache von GA-

Systemen stellt eine praxisnahe und gute Lösung bereit. Inwiefern sich dieses als tatsächlicher

Standard durchsetzen wird, bleibt abzuwarten. Für den vorgestellten Ansatz bedeutet die

angenommene Interoperabilität, dass derzeit nicht alle Funktionen von beliebigen Herstellern

miteinander zu einem funktionierenden GA-System verbunden werden können. Die vielfältigen

Forschungsarbeiten und auch die Weiterentwicklung des BACnet weisen zwar auf eine

wachsende Interoperabilität zwischen Geräten verschiedener Hersteller in der Theorie hin,

bedeuten aber für die Praxis eine sehr aufwendige Integration in den Planungsprozess, welche

in ihrer Komplexität nur durch das Fachwissen eines Systemintegrators der GA realisierbar ist.

An dieser Stelle liegt die Grenze, an welcher der integrierte GA-Planungsprozess die besseren

Voraussetzungen bietet, das GA-System vollständig zu konzipieren und zu realisieren.

Ebenfalls zu den Einschränkungen gehören die Fehlerquellen der Expertenbefragung. Auch

wenn durch die Expertenbefragung Meinungen zum Ansatz aus den Fachbereichen der GA,

der Baubranche und auch von Bauherren eingeholt wurden, so sind diese Meinungen

grundsätzlich Einzelmeinungen und können durch Fehlinterpretationen in beide Richtungen

beeinflusst sein. Eine vollumfängliche Befragung von Mehrheiten aus den jeweiligen

Fachgebieten ist jedoch zeitlich schwer realisierbar und unverhältnismäßig. Die

Anwendbarkeit des Ansatzes wurde durch die Struktursegmentierung, die

Anforderungserhebung und die Teilmodellerstellung der Beispiele und des realen

Bauprojektes der Halle gezeigt und durch positive Auswertung der Expertenbefragung

ergänzt, um eine Validierung des Ansatzes zu ermöglichen.

Die Einschränkungen lassen erkennen, dass der Ansatz nur in Bezug auf die RA validiert

werden konnte und eine einfache Ausweitung des Ansatzes auf die vollständige GA inklusive

GAM und AA nicht ohne erheblichen Mehraufwand realisierbar ist. Auch die Annahme der

Interoperabilität ist nur über Aussagen in Forschungsarbeiten und dem

Kommunikationsstandard BACnet gegeben. In der Praxis bedeutet diese Annahme, dass bei

Verwendung von Geräten und Anlagen verschiedener Hersteller ein erheblicher Aufwand zur

Systemintegration folgt, welcher in der Realität nur von tatsächlichen Fachleuten, den

Systemintegratoren, erfolgen kann. Die Geräte von Herstellern, die den BACnet-Standard

derzeit nicht verwenden, sind weiterhin schwer bis gar nicht in andere GA-Systeme

integrierbar.

112


8.4.2 Übertragbarkeit des Engineeringansatzes

Das durchgängige und modellbasierte Engineering führt ein komplexes Gefüge mit

verschiedenen Topologien zu einem gemeinsamen Modell zusammen, um dieses Modell für

Überprüfungsmethoden zu verwenden und die Möglichkeit zu bieten, verschiedene

Teilmodelle und Sichten des Komplexes zu entwerfen.

Die vorgestellte Methode baut auf der Lücke auf, die der optimierte Bauprozess mit einem

zentralen GA-Fachplaner und dem bis dahin integrierten GA-Planungsprozess zum

konventionellen Bauprozess mit der gewerkegetrennten GA-Planung lässt. Für die integrierte

GA-Planung gibt es, wie in Kapitel 4 dargestellt bereits vielfältige Lösungsansätze. Trotzdem

muss an dieser Stelle auch diskutiert werden, inwiefern der vorgestellte Ansatz des

durchgängigen und modellbasierten Engineerings auch den integrierten GA-Planungsprozess

unterstützen kann.

Die Möglichkeit im Rahmen der Anforderungserhebung zunächst allgemeine Funktionsblöcke

auszuplanen, welche im späteren Verlauf durch der Planung durch konkrete Geräte und

Anlagen ersetzt werden ist sowohl in den proprietären Planungssystemen, wie ETS, wie auch

im AUTEG-Projekt und dem Softwarewerkzeug „Auteras“ möglich. Die Ausplanung in allen

Schalen der Ortsstruktur gemäß dem Schalenmodell ist dort nicht möglich, da die Programme

raumbasiert ausgelegt sind. Auch für den integrierten GA-Planungsprozess kann es für den

Fachplaner von Bedeutung sein, Funktionen in einer Ortsstruktur sortiert auszuplanen und

miteinander zu verbinden.

Die Teilmodellerstellung für die spezifischen Belange der gewerkegetrennten Fein- und

Ausplanung ist im integrierten GA-Planungsprozess nicht so sehr relevant, wie im

gewerkegetrennten, da der Fachplaner die Gesamtplanung übernimmt und Schnittstellen

dadurch nicht zwischen den Gewerken selbst vorkommen oder nicht in dem gleichen Maße.

Trotzdem ist die Teilmodellerstellung auch für den GA-Fachplaner für spezifische Analysen

und Betrachtungen von GA-System-Teilen in Bezug auf beispielsweise die

Leistungsparameter, wie Antwort-Zeit-Verhalten, interessant. Weiterhin kann es trotz des

integrierten Planungsprozesses vorkommen, dass verschiedene Firmen jeweils Teile des

Gesamtauftrages zur Installation eines GA-Systems bekommen. In diesen Fällen ist die

Teilmodellerstellung in Bezug auf die Schnittstellenabsprache durchaus relevant.

Grundsätzlich ist die vorgestellte Methode auch im integrierten GA-Planungsprozess mit

einem GA-Fachplaner ebenfalls durchführbar und möglich. Die aufgezeigten Möglichkeiten

der Nutzung der gesamten Ortsstruktur und der Teilmodellerstellung können auch im

integrieten GA-Planungsprozess für mehr Flexibilität in der Gestaltung und er späteren

Ausschreibung oder Analyse sorgen.

113

9.1 Zusammenfassung

9 Zusammenfassung und Ausblick

9.1 Zusammenfassung

Bauherren und Nutzer erwarten in der heutigen Zeit die neueste Technik auch in Gebäuden.

Dazu gehören Funktionalitäten, die Gebäudenutzer im Handeln unterstützen und den Komfort

sowohl in Wohn- wie auch in Nicht-Wohngebäuden erhöhen. Gerade die Bauherren erwarten

von der neuesten Technik in Zeiten von steigenden Rohstoffpreisen auch Funktionalitäten, die

zu Energieeinsparungen und einem wirtschaftlichen Umgang mit Ressourcen führen, um die

Betriebskosten eines Gebäudes gering zu halten.

Diese Anforderungen an Gebäude können durch ein optimal funktionierendes,

kostengünstiges und energieeffizientes GA-System erfüllt werden. Die GA umfasst dabei alle

Aufgaben und Funktionalitäten einer gewerkeübergreifenden Automation, wie beispielsweise

Heizen, Kühlen, Verschatten oder Beleuchtung. Diese Aufgaben werden durch einzelne

Funktionen, wie Sensor-, Aktor- oder Steuerungsfunktionen, wahrgenommen und sind über

ein großes Netzwerk zu einem Gebäudeautomationssystem (GA-System) miteinander

verbunden. Ein GA-System ist ein Verbund von Funktionen zum energieeffizienten,

wirtschaftlichen und sicheren Betrieb der technischen Gebäudeausrüstung.

Die Herausforderungen bei der Realisierung eines GA-Systems sind vielfältig und basieren

vor allem auf der gewerkegetrennten Planung in der Praxis des konventionellen

Bauprozesses. Die Funktionen eines GA-Systems lassen sich nicht durch ein einzelnes

Gewerk realisieren, sondern sind durch den Systemverbund gewerkeübergreifend. Die

getrennte Planung in den einzelnen Gewerken führt dabei zu fehlenden

Schnittstellenabsprachen durch mangelnde Kommunikation und die Nutzung von heterogenen

Datenquellen. In der Realisierung entstehen dabei in allen Phasen des Engineerings von GA-

Systemen (Planung, Installation und Betrieb) Fehler, wie die mehrfache Auslegung von

Funktionen oder fehlende Verbindungen zwischen den Funktionen.

Es braucht daher eine Methode, die auf Basis der integralen und durchgängigen Betrachtung

eines GA-Systems den dargestellten Herausforderungen begegnet und die Forderungen nach

einem optimal funktionierenden, kostengünstigen und energieeffizienten GA-System erfüllt.

Die aufgezeigte Methode des modellbasierten Engineerings der GA kann Infrastrukturdaten

über ein auszurüstendes Gebäude in eine Ortsstruktur überführen und diese Ortsstruktur mit

GA-Funktionen ausplanen und in Verbindung mit den Informationen über die Produktstruktur

ein GA-System-Modell erstellen, welches die drei Topologien der Ortsstruktur, der

Funktionsstruktur und der Produktstruktur miteinander verbindet. Aus diesem Modell als

Gesamtmodell können Teilmodelle nach verschiedenen Fragestellungen erstellt werden und

damit als Ausgangsbasis für weitere Analysen, wie beispielsweise Simulationen oder die

Parametrierung des realen GA-Systems dienen.

Die Ortsstruktur stellt die Grundlage der Planung eines GA-Systems dar. Diese kann im

Rahmen der Infrastruktursegmentierung automatisch aus digitalen Grundrissdateien im

Format .ifc extrahiert werden, da die Strukturierung des Gebäudes auf Basis des

Schalenmodells der [VDI-RICHTLINIE 3813-1] mit der Struktur des Gebäudemodells (BIM)

vergleichbar ist. Das Ergebnis der Infrastruktursegmentierung ist eine hierarchische

Ortsstruktur, welche ein Gebäude in Bereiche, Räume und Segmente einteilt.

114

9 Zusammenfassung und Ausblick

Diese Ortsstruktur wird durch das Engineering-Werkzeug zur Unterstützung der

Anforderungserhebung in Zusammenarbeit zwischen Bauherr und Objektplaner um die

Funktionsstruktur des GA-Systems ergänzt. Die Funktionsstruktur besteht aus miteinander

verbundenen Funktionen der [VDI-RICHTLINIE 3813-2] und bildet die logische Struktur. Durch

die effektive Nutzung der Template-Funktionalität, sind die sonst häufig manuell zu

bearbeitenden Schritte der Ausplanung deutlich schneller und bedienerfreundlicher innerhalb

des Engineering-Werkzeugs zu gestalten. Durch den geringen Aufwand des

Planungsprozesses ist es möglich, mehrere Entwurfsvarianten zu entwerfen und anschließend

durch die Simulation zu analysieren und miteinander zu vergleichen. Die Simulation dient

dabei der Qualitätssicherung des GA-Systems und entdeckt fehlende Verbindungen oder kann

im Rahmen der Performanceanalyse u.a. bestimmen, wie hoch die Auslastung auf dem

Kommunikationsbus ist.

Im Rahmen der Installation des GA-Systems können aus dem GA-System-Modell

verschiedene Teilmodelle erstellt werden. Dies kann dazu dienen, Funktionslisten nach

verschiedenen Eigenschaften zu generieren, beispielsweise bezogen auf einen Raum oder

eine Etage. Weiterhin können Schnittstellen zu anderen Gewerken aufgezeigt werden, welche

im Rahmen der Ausführung der Absprache bedürfen. Die Teilsystem-Erstellung stellt weiter

die Basis für eine Überprüfung oder Anlayse eines spezifischen Teils des GA-System-Modells

oder die Überwachung des GA-Systems im Betrieb dar.

Die Methode des durchgängigen und modellbasierten Engineerings kann bei der Planung,

Installation und dem Betrieb von GA-Systemen auf Basis der RA-Funktionen Zeit und Kosten

einsparen und dazu führen, dass weniger Planungsfehler entstehen bzw. Fehler frühzeitig

entdeckt werden. Auch im Rahmen der Schnittstellenabsprache zwischen den ausführenden

Gewerken ist die Methode durch ihre grundsätzliche Ausrichtung auf den konventionellen

Bauprozess mit einem gewerkegetrennten GA-Planungsprozess geeignet, die

gewerkegetrennte Ausführung zu unterstützen. Durch den prototypischen Entwurf der

Toolkette ist noch weiterer Verbesserungsbedarf in Hinblick auf Benutzerfreundlichkeit und

den Übergängen zwischen den Tools vorhanden. Ebenso fehlt die Komponente der

Berechnung der Energieeinsparung oder die Bestimmung der Energieeffizienzklasse, welche

nicht Bestandteil dieser Arbeit sind.

9.2 Ausblick

Auf weitere Sicht und in Hinblick auf die Neugestaltung der [VDI-RICHTLINIE 3814-1

ENTWURF] sollte die vorgestellte Methode auf die AA und die GAM zu vollständigen GA-

Systemen erweitert werden. Die Annahme der vollständigen Interoperabilität im Rahmen des

vorgestellten Ansatzes ist grundsätzlich berechtigt und möglich, jedoch ist diese Annahme in

der Praxis mit einem erheblichen Integrationsaufwand verbunden. Die von Herrn Kranz in

seinen Hinweisen kommunizierte proprietäre Grundhaltung der GA-System-Hersteller stellt in

diesem Zusammenhang eine große Herausforderung dar. Erste Ansätze zur verbesserten

Interoperabilität werden im Rahmen der Weiterentwicklung der Richtlinien und des BACnet-

Standards aktuell entwickelt. Grundsätzlich bietet der vorgestellte Ansatz des durchgängigen

und modellbasierten Engineerings eine solide Grundlage, dieses Konzept auch den

zukünftigen Entwicklungen anzupassen und auf die AA und die GAM-Funktionen zu erweitern.

Auch die in der Eingrenzung der Systembetrachtung getroffene Auswahl kann auf Basis der

vorgestellten Methode grundsätzlich auf Subsysteme und Heimsysteme erweitert werden.

115

9.2 Ausblick

Eine weitere Anwendung der Teilmodellerstellung des GA-System-Modells ist die

Überwachung des GA-Systems im laufenden Betrieb. Bei einer Überwachung von vor allem

großen Systemen stellt die Masse an kontinuierlichen Datenflüssen, welche auf Kennzahlen

an einzelnen Datenpunkten überwacht werden müssen, eine große Herausforderung dar.

Durch die Möglichkeit aus dem GA-System-Modell Teilmodelle zu erstellen, besteht auch die

Möglichkeit Kennzahlen anhand der gezeigten Topologien zu spezifizieren und lediglich diese

Kennzahlen zu überwachen.

Zukünftig ist es denkbar, die vorgestellte Methode innerhalb der BIM-Modellierung zu

integrieren. Diese Integration würde einen konsistenten Datensatz innerhalb eines Programms

ermöglichen und der Datensatz könnte durch Informationen, wie z. B. die exakten Grundriss-

und Positionsdaten ergänzt werden. Durch die Ergänzung der Ortsstruktur um diese

Informationen, wäre eine genauere Simulation und auch Kostenabschätzung möglich, da

dadurch beispielsweise die Kabellängen genau ermittelt werden könnten. Ein

dreidimensionales Bild des geplanten Gebäudes mit den jeweiligen Komponenten der

einzelnen Gewerke wäre eine hilfreiche Darstellung sowohl für Architekten und Fachplaner,

als auch für den Bauherrn/ Nutzer. In diesem Zusammenhang wäre eine gewerkegemeinsame

Planung und Auslegung der Systeme sinnvoll und im Idealfall wäre auch eine Simulation aller

Anlagenkomponenten eines Gebäudes möglich, wie beispielsweise die elektrische

Verschaltung, das Licht- oder Wärmekonzept. Die Integration der Berechnung von

Energieverbräuchen und Energieeinsparungen durch GA-Systeme würde den durchgängigen

Planungsansatz vervollständigen. Die Vorgehensweise des TLT- Ansatzes wäre dabei auch

für alle Gewerke denkbar, um gerade bei sehr großen Bauvorhaben oder bestehenden

Gebäuden die geforderten Funktionalitäten zu überprüfen, dazu gehört auch die

Brandschutzanlage oder die Wasserversorgung. Im laufenden Betrieb könnte eine

Verknüpfung der Infrastrukturdaten mit dem modellbasierten Engineering auch bei der

Fehlersuche und der Lokalisation des Fehlers helfen, um diesen schneller und effizienter zu

beheben. Dies könnte erreicht werden, wenn beispielsweise bei der Fehlermeldung oder

Brandmeldung direkt eine Position und das betroffene Gerät oder der Teilbereich integriert

wären.

Insgesamt bleibt noch viel Handlungsspielraum für zukünftige Entwicklungen und

Forschungen im Bereich des modellbasierten Engineerings in der Bau- und GA-Branche. Der

vorgestellte Ansatz des durchgängigen und modellbasierten Engineerings liefert gerade in

Hinblick auf eine mögliche Kombination mit dem BIM-Ansatz einen wertvollen Grundstein,

welcher zukünftig noch weiter ausgebaut werden sollte.

116

Anhang A

Anhang A

Liste der GA/ RA-Funktionen der [VDI-RICHTLINIE 3813-2]

Sensor-Funktionen

Präsenzerkennung

Anw

endungsfu

nktionen

Basis

Belegungsauswertung

Fensterüberwachung Steuerung über Raumnutzung

Taupunktüberwachung Zeitprogramm

Lufttemperaturmessung Trennwandsteuerung

Helligkeitsmessung

Beleuchtung

Lichtschaltung

Luftqualitätsmessung Treppenlichtschaltung

Windgeschwindigkeitsmessung Automatiklicht

Niederschlagserkennung Tageslichtschaltung

Aktor-Funktionen

Lichtaktor Konstantlichtregelung

Sonnenschutzaktor Dämmerungsschaltung

Stellantriebsaktor

Sonnenschutz

Prioritätssteuerung

Komm-E/A-Fkt Gem. komm. Eingabefunktion Dämmerungsautomatik

Gem. komm. Ausgabefunktion Sonnenautomatik

Bedien-/Anzeige-

Funktionen

Licht stellen Lamellennachführung

Sonnenschutz stellen Verschattungskorrektur

Antrieb stellen Thermoautomatik

Temperatursollwert stellen Witterungsschutz

Raumnutzungsart wählen

Raumklima

Energieniveauwahl

Präsenz melden Energieniveauwahl mit Start

Sollwertermittlung

Funktionswahl

Temperaturregelung

(Heiz./Kühl.)

Raum-Zuluftkaskadenregelung

Ventilatorsteuerung

Sequenzsteuerung

Stellwertbegrenzung

Luftqualitätssteuerung/-regelung

Nachtkühlung

Volumenstromregelung

117

Anhang B

Anhang B

DXF-Datei im Quellcode (Ausschnitt)

Zeile Code Zeile Code Zeile Code

1 0 30 $EXTMIN 59 70

2 SECTION 31 10 60 1

3 2 32 1.775.691.843.652.610 61 9

4 HEADER 33 20 62 $REGENMODE

5 9 34 -924.418.976.923.769 63 70

6 $ACADVER 35 30 64 1

7 1 36 0.0 65 9

8 AC1024 37 9 66 $FILLMODE

9 9 38 $EXTMAX 67 70

10 $ACADMAINTVER 39 10 68 1

11 70 40 178.931.035.008.697 69 9

12 155 41 20 70 $QTEXTMODE

13 9 42 -9.223.982.283.763.090 71 70

14 $DWGCODEPAGE 43 30 72 0

15 3 44 0.0 73 9

16 ANSI_1252 45 9 74 $MIRRTEXT

17 9 46 $LIMMIN 75 70

18 $LASTSAVEDBY 47 10 76 0

19 1 48 0.0 77 9

20 Earno 49 20 78 $LTSCALE

21 9 50 0.0 79 40

22 $INSBASE 51 9 80 1.0

23 10 52 $LIMMAX 81 9

24 0.0 53 10 82 $ATTMODE

25 20 54 12.0 83 70

26 0.0 55 20 84 1

27 30 56 9.0 85 9

28 0.0 57 9

29 9 58 $ORTHOMODE

118

Anhang C

Anhang C

DWG-Datei mit Hex-Editor und 8 Bytes (Ausschnitt)

119

Anhang D

Anhang D

Das IFC- Dateiformat (Ausschnitt)

ISO-10303-21;

HEADER;

/**************************************************************************

****************

* STEP Physical File produced by: The EXPRESS Data Manager Version

5.02.0100.07 : 28 Aug 2013

* Module: EDMstepFileFactory/EDMstandAlone

* Creation date: Wed Oct 14 14:05:17 2015

* Host: IFAPC-13

* Database:

C:\Users\PHROMP~1\AppData\Local\Temp\{C39E168D-1926-4AFE-A820-

90435B5580A0}\ifc

* Database version: 5507

* Database creation date: Wed Oct 14 14:05:12 2015

* Schema: IFC2X3

* Model: DataRepository.ifc

* Model creation date: Wed Oct 14 14:05:12 2015

* Header model: DataRepository.ifc_HeaderModel

* Header model creation date: Wed Oct 14 14:05:12 2015

* EDMuser: sdai-user

* EDMgroup: sdai-group

* License ID and type: 5605 : Permanent license. Expiry date:

* EDMstepFileFactory options: 020000

***************************************************************************

***************/

FILE_DESCRIPTION(('ViewDefinition [CoordinationView]'),'2;1');

FILE_NAME('Project Number','2015-10-14T14:05:17',(''),(''),'The EXPRESS

Data Manager Version

5.02.0100.07 : 28 Aug 2013','20150220_1215(x64) - Exporter 16.0.428.0 -

Default UI','');

FILE_SCHEMA(('IFC2X3'));

ENDSEC;

DATA;

#1= IFCORGANIZATION($,'Autodesk Revit 2016 (DEU)',$,$,$);

#5= IFCAPPLICATION(#1,'2016','Autodesk Revit 2016 (DEU)','Revit');

#6= IFCCARTESIANPOINT((0.,0.,0.));

#9= IFCCARTESIANPOINT((0.,0.));

#11= IFCDIRECTION((1.,0.,0.));

#13= IFCDIRECTION((-1.,0.,0.));


#17= IFCDIRECTION((0.,-1.,0.));


#21= IFCDIRECTION((0.,0.,-1.));

#23= IFCDIRECTION((1.,0.));

#25= IFCDIRECTION((-1.,0.));

#27= IFCDIRECTION((0.,1.));

#29= IFCDIRECTION((0.,-1.));

#31= IFCAXIS2PLACEMENT3D(#6,$,$);

120

Anhang E

Anhang E

Die Umsetzung der automatischen Struktursegmentierung in C

#include <stdlib.h>

#include <string.h>

#define BUF 255

const char trennzeichen[] = ".;,:\"\' ";

int main(void) {

FILE *f, *kopie;

char searchstring[BUF];

char puffer[BUF], puffer_bak[BUF];

int counter=1;

char *wort;

// Namen der IFC Datei eingeben:

f=fopen("IFC_Buero.ifc","r");

if(f == NULL) {

printf("Fehler bei fopen()...");

return EXIT_FAILURE;

}

// Name der Ausgangsdatei eingeben:

kopie = fopen("structure_4.txt", "w");

if(kopie == NULL) {

printf("Fehler bei fopen()...");

return EXIT_FAILURE;

}

while( fgets(puffer, BUF, f) != NULL ) {

if(strstr(puffer,"IFCBUILDING") != 0 ||

strstr(puffer,"IFCBUILDINGSTOREY") !=0 || strstr(puffer,"IFCSPACE") !=0 ||

strstr(puffer,"IFCRELAGGREGATES") !=0)

//fputs(puffer, kopie);

printf("Zeile %d : %s",counter,puffer) & fputs(puffer, kopie);

counter++;

}

fclose(f);

fclose(kopie);

printf("Suche Abgeschlossen und %d Zeilen gefunden\n" , counter);

return EXIT_SUCCESS;

}

121

Anhang F

Anhang F

Ergebnis der automatischen Struktursegmentierung

#104= IFCBUILDING('01v4YJYBPB6fBCZsyAZONL',#41,'',$,$,#32,$,'',.ELEMENT.,$,$,#100);

#113= IFCBUILDINGSTOREY('01v4YJYBPB6fBCZs$rSdj7',#41,'Level 1',$,$,#111,$,'Level 1',.ELEMENT.,0.);

#119= IFCBUILDINGSTOREY('01v4YJYBPB6fBCZs$rSd0B',#41,'Level 2',$,$,#118,$,'Level 2',.ELEMENT.,3650.);

#139= IFCSPACE('3tHW_jGZbFSuZfIY99TX5P',#41,'2',$,$,#125,#135,'Einzelbuero 1',.ELEMENT.,.INTERNAL.,$);

#201= IFCSPACE('3tHW_jGZbFSuZfIY99TX5S',#41,'3',$,$,#190,#199,'Doppelbuero 1',.ELEMENT.,.INTERNAL.,$);

#255= IFCSPACE('3tHW_jGZbFSuZfIY99TX5V',#41,'4',$,$,#244,#253,'Doppelbuero 3',.ELEMENT.,.INTERNAL.,$);

#308= IFCSPACE('3tHW_jGZbFSuZfIY99TX5Y',#41,'5',$,$,#297,#306,'Einzelbuero 5',.ELEMENT.,.INTERNAL.,$);

#360= IFCSPACE('3tHW_jGZbFSuZfIY99TX5b',#41,'6',$,$,#349,#358,'Einzelbuero 6',.ELEMENT.,.INTERNAL.,$);

#414= IFCSPACE('3tHW_jGZbFSuZfIY99TX5e',#41,'7',$,$,#403,#412,'Doppelbuero 4',.ELEMENT.,.INTERNAL.,$);

#466= IFCSPACE('3tHW_jGZbFSuZfIY99TX5h',#41,'8',$,$,#455,#464,'Einzelbuero 4',.ELEMENT.,.INTERNAL.,$);

#520= IFCSPACE('3tHW_jGZbFSuZfIY99TX5k',#41,'9',$,$,#509,#518,'Eingang',.ELEMENT.,.INTERNAL.,$);

#574= IFCSPACE('3tHW_jGZbFSuZfIY99TX5n',#41,'10',$,$,#563,#572,'Einzelbuero 3',.ELEMENT.,.INTERNAL.,$);

#626= IFCSPACE('3tHW_jGZbFSuZfIY99TX5q',#41,'11',$,$,#615,#624,'Doppelbuero 2',.ELEMENT.,.INTERNAL.,$);

#679= IFCSPACE('3tHW_jGZbFSuZfIY99TX5t',#41,'12',$,$,#668,#677,'Einzelbuero 2',.ELEMENT.,.INTERNAL.,$);

#733= IFCSPACE('3tHW_jGZbFSuZfIY99TX5w',#41,'13',$,$,#722,#731,'WC 1',.ELEMENT.,.INTERNAL.,$);

#787= IFCSPACE('3tHW_jGZbFSuZfIY99TX5z',#41,'14',$,$,#776,#785,'WC 2',.ELEMENT.,.INTERNAL.,$);

#841= IFCSPACE('3tHW_jGZbFSuZfIY99TX60',#41,'15',$,$,#830,#839,'VorraumWC 1',.ELEMENT.,.INTERNAL.,$);

#893= IFCSPACE('3tHW_jGZbFSuZfIY99TX63',#41,'16',$,$,#882,#891,'VorraumWC 2',.ELEMENT.,.INTERNAL.,$);

#945= IFCSPACE('3tHW_jGZbFSuZfIY99TX66',#41,'17',$,$,#934,#943,'TeeK 1',.ELEMENT.,.INTERNAL.,$);

#998= IFCSPACE('3tHW_jGZbFSuZfIY99TX69',#41,'18',$,$,#987,#996,'TeeK 2',.ELEMENT.,.INTERNAL.,$);

#1050= IFCSPACE('3tHW_jGZbFSuZfIY99TX6C',#41,'19',$,$,#1039,#1048,'TreppenH 1',.ELEMENT.,.INTERNAL.,$);

#1103= IFCSPACE('3tHW_jGZbFSuZfIY99TX6F',#41,'20',$,$,#1092,#1101,'Flur',.ELEMENT.,.INTERNAL.,$);

#1157= IFCSPACE('3tHW_jGZbFSuZfIY99TX6c',#41,'21',$,$,#1145,#1155,'Flur 2',.ELEMENT.,.INTERNAL.,$);

#1211= IFCSPACE('3tHW_jGZbFSuZfIY99TX6_',#41,'22',$,$,#1200,#1209,'Einzelbuero 7',.ELEMENT.,.INTERNAL.,$);

#1263= IFCSPACE('3tHW_jGZbFSuZfIY99TX71',#41,'23',$,$,#1252,#1261,'Doppelbuero 5',.ELEMENT.,.INTERNAL.,$);

#1316= IFCSPACE('3tHW_jGZbFSuZfIY99TX74',#41,'24',$,$,#1305,#1314,'Doppelbuero 7',.ELEMENT.,.INTERNAL.,$);

#1370= IFCSPACE('3tHW_jGZbFSuZfIY99TX77',#41,'25',$,$,#1359,#1368,'Einzelbuero 12',.ELEMENT.,.INTERNAL.,$);

#1423= IFCSPACE('3tHW_jGZbFSuZfIY99TX7A',#41,'26',$,$,#1412,#1421,'Einzelbuero 13',.ELEMENT.,.INTERNAL.,$);

#1476= IFCSPACE('3tHW_jGZbFSuZfIY99TX7D',#41,'27',$,$,#1465,#1474,'Doppelbuero 8',.ELEMENT.,.INTERNAL.,$);

#1528= IFCSPACE('3tHW_jGZbFSuZfIY99TX7G',#41,'28',$,$,#1517,#1526,'Einzelbuero 11',.ELEMENT.,.INTERNAL.,$);

#1582= IFCSPACE('3tHW_jGZbFSuZfIY99TX7J',#41,'29',$,$,#1571,#1580,'Einzelbuero 10',.ELEMENT.,.INTERNAL.,$);

#1635= IFCSPACE('3tHW_jGZbFSuZfIY99TX7M',#41,'30',$,$,#1624,#1633,'Einzelbuero 9',.ELEMENT.,.INTERNAL.,$);

#1689= IFCSPACE('3tHW_jGZbFSuZfIY99TX7P',#41,'31',$,$,#1678,#1687,'Doppelbuero 6',.ELEMENT.,.INTERNAL.,$);

#1742= IFCSPACE('3tHW_jGZbFSuZfIY99TX7S',#41,'32',$,$,#1731,#1740,'Einzelbuero 8',.ELEMENT.,.INTERNAL.,$);

#1796= IFCSPACE('3tHW_jGZbFSuZfIY99TX7V',#41,'33',$,$,#1785,#1794,'WC 3',.ELEMENT.,.INTERNAL.,$);

#1850= IFCSPACE('3tHW_jGZbFSuZfIY99TX7Y',#41,'34',$,$,#1839,#1848,'WC 4',.ELEMENT.,.INTERNAL.,$);

#1903= IFCSPACE('3tHW_jGZbFSuZfIY99TX7b',#41,'35',$,$,#1892,#1901,'VorraumWC 3',.ELEMENT.,.INTERNAL.,$);

#1956= IFCSPACE('3tHW_jGZbFSuZfIY99TX7e',#41,'36',$,$,#1945,#1954,'VorraumWC 4',.ELEMENT.,.INTERNAL.,$);

#2009= IFCSPACE('3tHW_jGZbFSuZfIY99TX7h',#41,'37',$,$,#1998,#2007,'TeeK 3',.ELEMENT.,.INTERNAL.,$);

#2062= IFCSPACE('3tHW_jGZbFSuZfIY99TX7k',#41,'38',$,$,#2051,#2060,'TeeK 4',.ELEMENT.,.INTERNAL.,$);

#2115= IFCSPACE('3tHW_jGZbFSuZfIY99TX7n',#41,'39',$,$,#2104,#2113,'TreppenH 2',.ELEMENT.,.INTERNAL.,$);

#19441=

IFCRELAGGREGATES('3vuP2C2Uj6lvNbmkeX_w1B',#41,$,$,#10783,(#10384,#10513,#10530,#10558,#10737,#10754,#10780,

#16363,#19191));

#19702= IFCRELAGGREGATES('0nFduKqJr6e8S68bo_mqoh',#41,$,$,#94,(#19455));

#19706= IFCRELAGGREGATES('19cCTqrCLD0giuRE2vAY_Q',#41,$,$,#19455,(#104));

#19710=

IFCRELAGGREGATES('3Aw$FV5MbAufEo59xkoNgA',#41,$,$,#113,(#139,#201,#255,#308,#360,#414,#466,#520,#574,#626,#

679,#733,#787,#841,#893,#945,#998,#1050,#1103));

#19732=

IFCRELAGGREGATES('3kSL0VGKv3gxJCujWqtuJj',#41,$,$,#119,(#1157,#1211,#1263,#1316,#1370,#1423,#1476,#1528,#15

82,#1635,#1689,#1742,#1796,#1850,#1903,#1956,#2009,#2062,#2115));

#19754= IFCRELAGGREGATES('0bEVwXRmbBleAvzFSJirAn',#41,$,$,#104,(#113,#119));

122

Anhang G

Anhang G

Fragebogen für die Expertenbefragungen

Ich möchte Sie nun bitten, ein paar Fragen zum vorgestellten Ansatz zu beantworten.

Darüber hinaus würde mir ein ausführliches Feedback zu meinem Engineeringansatz

ebenfalls sehr weiterhelfen.

1. Wo sehen Sie Handlungsbedarf bei der Planung, der Installation und dem Betrieb,

kurz beim Engineering von Gebäudeautomationssystemen?

2. Welche Anforderungen an eine Methode müssen erfüllt werden, um diesem

Handlungsbedarf wirksam zu begegnen?

3. In welchem Maße erfüllt der vorgestellte Ansatz des durchgängigen und

modellbasierten Engineerings von Gebäudeautomationssystemen diese

Anforderungen?

4. Bezogen auf die Einzelabschnitte des Ansatzes:

a. Glauben Sie, dass der Ansatz die Anforderungserhebung erleichtert?

b. Glauben Sie, dass durch ein Modell des GA-Systems die Planung effektiver

wird?

c. Glauben Sie, dass die Durchgängigkeit des Ansatzes Planungsfehler

vermeiden kann?

d. Glauben Sie, dass die integrale Betrachtung des GA-Systems über alle

Engineering-Phasen die Realisierung von GA-Systemen erleichtert?

5. Inwiefern kann der vorgestellte Ansatz das Engineering von

Gebäudeautomationssystemen in Bezug auf Zeit, Kosten und Qualität verbessern?

6. Allgemeines Feedback zum Ansatz:

123

Anhang H

Anhang H

Antwort zur Expertenbefragung von Herrn R. Kranz, am 13.10.2017, per E-Mail. Private Worte

und Links wurden durch […] ersetzt.

Sehr geehrte Frau Günther,

[…]

Als Erstes ist mir aufgefallen, dass einige für die GA-Leute ungewöhnliche Ausdrucksweisen

vorkommen,

z. B. Parametrisieren. Die Branche spricht von Parametrieren - siehe Auszug sus der GA-

Weltnorm [Zitat ISO 16484]

ANMERKUNG 1 Managementfunktionen bilden einen Abschnitt der GA-Funktionsliste und

sind in DIN EN ISO 16484-3, in Kapitel 5.5 sowie im Anhang A (normativ) festgelegt und im

Anhang B beispielhaft (informativ) dargestellt.

ANMERKUNG 2 Die für Managementfunktionen zu übertragenden Daten werden als

Kommunikationsfunktionen in zwei Spalten der GA-Funktionsliste aufgeführt, die sich

hinsichtlich Komplexität der Daten und Anwendung unterscheiden.

ANMERKUNG 3 Die Kommunikationsfunktionen sind angelehnt an die Objekte und Dienste

des BACnet Protokolls nach DIN EN ISO 16484-5.

ERLÄUTERUNG

Die für eine Systemintegration von GA-Systemen mit Gefahrenmelde- und Alarmsystemen

erforderlichen Planungsinformationen können ebenfalls mittels der GA-FL dargestellt und

dokumentiert werden.

Schauen wir zunächst auf Ihren Foliensatz:

Folie 5:

im Beispiel für "Management, Optimierung" ist das Wort "Management" nicht angebracht - die

Beispiele sind ganz "normale" Anlagen-Anwendungs-Funktionen, die über einfache Steuerung

und Regelung hinausgehen, daher bei VDI 3814 unter Rechnen / Optimieren einsortiert

wurden.

Folie 7:

Wie kommt hier der Aspekt "Zentrale Systeme" hinein? Das ist eine vorgeprägte falsche Sicht

auf die Technik. Auch bei LON und KNX gibt es übergeordnete Controller, und eine

"Leitebene" wenn die Sensoren und Aktoren selber nicht "schlau" genug sind. (Siehe die

Systeme von TA, Regulex, Loytech, auch die (alte) Raumautomation von Siemens musste

"Controller" einsetzen, etc.). Aber auch bei DDC (ob mit oder ohne BACnet) gibt es

kommunikationsfähige Feldgeräte mit eigenständigen Funktionen, Siehe auch die kleinen

Controller von Elesta (Cylon) mit bis zu 8 EAs. DDC (eine alte Bezeichnung für die digital

arbeitenden Regelgeräte - im Gegensatz zu SPS ("Steuergeräte"), also die "echte,

professionelle" GA wird von Systemhäusern, Systemintegratoren oder direkt von Herstellern

"gebaut", die sich den "Anlagenerrichtern" zuordnen - nicht Handwerkern.

Das aus der Verkehrs-/ Automobiltechnik kommende "SmallCAN" (Fa Bosch) kann sich

maximal als Exot im Homeautomation-Bereich (vielleicht) etablieren. Ich denke, die iQST

124

Anhang H

steckt dahinter - um den Markt-Anwendungsbereich auszuweiten - was vorher (in den letzten

30 Jahren nach meiner Sammlung bereits über 100 unterschiedliche Bus-Entwickler versucht

haben). "Jeder Bus ist (vermeintlich) auch für Häusle brauchbar". Bei allen Betrachtungen

wäre die Tiefe der erreichbaren Interoperabilität heute das entscheidende Kriterium! Bei den

"Subsystemen" ist die Eigenschaft "nicht gewerkeübergreifend" nicht korrekt. Sowohl Modbus

als auch ENOcean, CAN, und insbesondere die Übertragungstechnik RS485 (ohne

"Protokoll") werden sehr wohl gewerkeübergreifend eingesetzt - es fehlt auch OPC UA.

Folie 11:

siehe "Parametrierung" - es fehlt die Interoperabilität als wesentliche Anforderung.

Folie 14: Statt BACS wäre (deutsch) "GA" hier passender.

Das zeigt nur, dass jeder GA-Hersteller sein "eigenes" und bewusst nicht kompatibles

Engineering System hat - IEC 61131 wird gemieden wie die Pest. Bei Raumautomation wird

diese Haltung etwas aufgeweicht (dank KNX). AUTERAS beschränkt sich derzeit auf

Raumfunktionen - die GA wäre aus heutiger Sicht zu umfangreich und zu komplex. (Aber nicht

unlösbar). Die Funktionsblöcke der neuen VDI 3814-3.1(2017) könnten den Anstoß für eine

Entwicklung in Ihre Richtung geben.

Folie 19:

Leider haben wir für die GA (noch) kein Schalenmodell wie für die RA entwickeln können. Sie

sollten im Weiteren besser zwischen Raumautomation, Anlagenautomation und umfassend

"GA" unterscheiden. Aus meiner Sicht befassen Sie sich eher (nur) mit Raumautomation.

Folie 20:

in der Praxis spricht man am häufigsten vom "Achsensegment" (das der Architekt oft bezogen

auf die Fensterachsen festlegt). Ein Büro kann z.B. aus 2 Achsensegmenten bestehen - das

ist für die Struktur der RA wichtig.

Folie 21:

Was in der GA / RA fehlt ist eine strukturierte, computerlesbare Methode, die GA/RA-

Funktionen zu beschreiben. Einen Anfang machte das BACnet Structured View Object. Derzeit

ist bei ASHRAE die BACnet-Truppe (SSPC 135) dabei so etwas zu entwickeln (Stichworte

CSML, JASON, RESTFUL)

Folie 33:

Die VDI 3814-6 zeigt "Zustandsgraphen" als prüfbare Möglichkeit der Beschreibung von

Funktionsabläufen (DIN EN 60848)

Nun zum Dokument.

Vorwort:

Die VDI 3813 befasst sich mit Raumautomation (ein Teilbereich der Gebäudeautomation) -

eher noch mit Homeautomation (VDI 3812).

Das gilt wohl auch für Ihre Arbeit?

Auch in der Einleitung ist die verbale Vermischung von GA (gemeint Anlagenautomation) und

RA zu finden. Die Heimautomation (Hausautomation) auf die Ihr Ansatz am ehesten passen

würde, ist nicht erwähnt. Die Aussagen dazu sind jedoch alle richtig.

125

Anhang H

Die im e. Absatz erwähnte Herausforderung betrifft in erster Linie den Planer. Oft jedoch

werden (zu) oft die AA und RA vom Rohr- und Blechplaner nebenher "mitgeplant", d. h. das

Honorar wird mitgenommen, die Arbeit machen als "branchenübliche Verkehrssitte" (Begriff

nach VOB) die Hersteller-Spezis des Planers. Die erwähnten schwerwiegenden Fehler

entstehen dadurch. Integrale Planung durch einen Fachmann für Gebäudeautomation findet

kaum statt (Ich kann diese Experten in Deutschland an beiden Händen abzählen)! Dabei gibt

es um die 5000 TGA-Planer.

Der letzte Satz mit der "fehlenden Methode" ist falsch. Die Planungsmethode mit

standardisierten Funktionen wurde bereits 1993 beim VDI eingeführt und bis zur Weltnorm für

GA durchgetragen (alle ISO-Länder weltweit haben diese anerkannt).

Weil ein Rohrplaner sich nicht mit so "komplexem Zeugs" befassen will, wird das zu wenig

angewandt. Auch wird das darauf aufbauende Standardleistungsbuch mit fadenscheinigen

Argumenten ignoriert - obwohl die entsprechende Planung gem. Bauvertrag (VOB/C)

vorgeschrieben ist. So ist Ihr letzter Absatz der Einleitung seit ca 30 Jahren bekannt und einige

wenige haben versucht, die Verkehrssitte aufzubrechen.

Zu 2. Anforderungen an das Engineering...

Unter Engineering versteht die Branche die Tätigkeit des Projektingenieurs bei der

ausführenden Firma. Dennoch wäre durchgängiges, kompetentes, alle Gewerke umfassendes

"Engineering" im ursprünglichen Sinne der richtige Ansatz - wir beschrieben. Die weiteren

Absätze sind richtig, es fehlt der Aspekt der Bedienbarkeit durch Nicht-Fachleute (Betreiben

der GA ist i. d. R. die letzte Karrierestufe des Hoffegers - leider).

Auf Seite 5:

Mit den Jahreszahlen hat das BMVBW sicher nicht ordentlich recherchiert: Die GA ist seit 1993

ein eigenständiges Gewerk, nämlich mit Aufnahme der Kostengruppe 480 in die

Baukostennorm DIN 276, es folgte 1995 die "eigene" ATV VOB/C DIN 18386 als Bauvertrags-

Grundlage für GA und 2000 war das STLB-Bau 070 für GA amtlich eingeführt worden. Die VDI

3814 (GA) wurde laufend den Entwicklungen angepasst, nun wird auch die VDI 3813 (RA) in

eine neue VDI 3814 GA bestehend auch AA+RA+GAM überführt. […]

Man kann also nicht sagen, "die GA ist in der Baubranche nicht etabliert" - sie ist "da" wird

aber sowohl von den großen Rohr- und Blech- Anlagenbaufirmen und den TGA-Planern

mißbraucht um den eigenen Umsatz zu optimieren - ohne die Kompetenz zu haben.

zu2.1:

AUTERAS bezieht sich ausdrücklich nur auf die RA, nicht GA (mit AA+GAM).

KNX: richtig: ETS ist ein Installationswerkzeug für den Elektro-Handwerker.

Diese Berufsgruppe ist jedoch nicht geeignet für komplexere Raumautomation und das

Zusammenspiel von Raumlufttechnik und Fassade.

Ein Elektro-Planer benutzt ETS nicht!

Die Aussage über die Herstellerneutralität ist einfach falsch! Mit der ETS und KNX kann der

Anwender aus hunderten unterschiedlichen (zertifizierten) Produkten beliebiger Hersteller

auswählen!

TRIC

126

Anhang H

Softwarewerkzeug zur Rationalisierung der Erstellung von Automationsschemata und der

Funktionsliste, sowie weiterer Listen (Feldgeräte etc). Für AA und RA (die RA wurde nicht

erwähnt!) Das hat nichts mit Ausführung zu tun aber auch nicht nur mit MSR, denn auch

Managementfunktionen können dokumentiert werden. (Auch wenn Fa. Mervisoft das irgendwo

so geschrieben hatte. Die erwähnten Schaltpläne können weitergehend nur mit dem Tool

WSCAD BA generiert werden, das dann auch besser für die Ausführung geeignet ist. Die

TRIC-Software wird auch von GA-Herstellern im Vertrieb verwendet, um die o.g.

Planerunterstützung leisten zu können... Trotzdem kommt es dann bei der Ausführung zum

Systembruch! Mit TRIC und BACeye von Fa. MBS kann heute schon ein (teilweises) "reverse

Engineering" einer GA mit BACnet durchgeführt werden - wenn die Dokumentation fehlt.

BACS Tool (aha - jetzt verstehe ich das englische Acronym in der Folie)

Dazu möchte ich nichts sagen, nur dass die Ansätze von Prof. Michael Krödel, FH Rosenheim

da wohl schon bessere Dienste leisten - aber mit den gleichen Schwächen.

zu 2.2:

die Idee ist auch schon 25 Jahre alt - auch TRIC lag dieser Idee mal zu Grunde - die

Entwicklungsabteilungen bei allen Herstellern haben dann genau das Gegenteil gemacht und

sogar vorhandene Ansätze (zB bei Siemens) verworfen. Um die Idee durchzsetzen, muss ein

"neuer" Hersteller damit erfolgreich sein (ich sehe hier Beckhoff, WAGO oder Phoenix

Contact, vielleicht auch DEOS als Kandidaten).

zu 3.

Ansätze alle gut!

3.1.1 Das Schalenmodell gilt nur für die RA! nicht GA als Ganzes.

3.1.2 Auczh .ifc ist für Automation nicht ausreichend - ifc geht gerade noch für graphische und

räumliche Daten. Auch hier sind zu viele Bremser am Werk! Es fehlen

Beschreibungsstrukturen die die GA-Produkte und die Softwarefunktionen. Für die GA

Hardware wird das derzeit bei VDI 3805 versucht. (Siehe auch oben: ASHRAE!)

3.2

Der Ansatz lohnt sich, ihn weiter zu verfolgen! Vielleicht sogar aufbohren auf die neuen VDI

3814-3.1 Funktionen! Statt Schalenmodell wäre für die AA der Ansatz der "Structured View"

Idee von BACnet denkbar (es gibt heute keine GA mehr, die nicht mit BACnet kommuniziert!)

3.3

Ob der Ansatz mit iQST zielführend (bzw. nachhaltig) ist, möchte ich nicht beurteilen. Ein

Konzept, das für die Kommunikation auf BACnet beruht wäre sicher erfolgreicher. Vielleicht

kann man die Pi-Tool dafür verwenden?

Die RA wird nicht im "Rohbau" installiert! Da muss sowohl der Ausbau als auch HLK und

Elektrik installiert sein! RA und AA sind immer "die Letzten".

"Zentrale GA-Systeme" gibt es eigentlich seit den 80er Jahren des letzten Jahrhunderts nicht

mehr. Gemeint sind vielleicht Automationseinrichtungen (Stationen) (AS), an die pro Anlage

alle zugehörigen Sensoren und Aktoren angeschlossen sind, die ASen sind untereinander und

mit einem Bedien-/Managementsystem vernetzt - da nennt man nicht "Zentral"! In den 60er

und 70er Jahren gab es noch die "Zentrale Leittechnik" mit einem Prozeßrechner - aber die

Zeiten sind vorbei. Ich selbst habe bei IBM schon ab 1982 dezentrale GA-Systeme eingebaut

127

Anhang H

(natürlich mit ASen) und habe 1983 mit der herstellerneutralen Kommunikation begonnen!

(Protokoll FACN).

Wenn Sie aber die Raumautomation meinen, ist es etwas Anderes. Diese kam von der

Einzelraumregelung (ein Controller für HLK pro Raum), Licht und Sonnenschutz waren

getrennt installiert (kaum automatisiert) - ASen hatte man kaum für Einzelraumregelung

benutzt (Exoten ausgenommen), weil zu teuer und zu unpraktisch.

Daher ist ihre Einteilung in der Branche nicht üblich. Den Begriff "Raumautomation" habe ich

im Sept. 1996 geprägt - suchen Sie mal nach Büchern darüber!.

Zum IQST SmallCAN: Das Businessmodell würde mich schon mal interessieren. Der

Wettbewerb ist schon sehr groß und er wird größer durch den Markteintritt von Samsung.

Kostengünstig sind alle - nur unterschiedlich Engineering-Aufwändig - das wäre der eigentliche

Erfolgsfaktor.

Aber auch die Durchgängigkeit zu einem GA-Gesamtsystem - und das geht heute nur noch

mit BACnet!!!

3.4 Es geht nur um Raumfunktionen.

Zum letzten Absatz: Wenn man sich an die Vorgaben der Hersteller bei der Topologie des

Kommunikationssystems hält, kann das mit den Antwortzeiten nicht passieren.

Letzter Absatz: Eine IEC 15232 gibt es nicht (zum Glück nicht bei den Elektrikern!) es ist leider

"nur" eine EN 15232 für die Energieeffizienz durch GA, aber ich habe bei "meiner" Weltnorm

DIN EN ISO 16484 den Teil 7 schon 2010 dafür vorgesehen, die 15232 angepasst

einzubringen (wie schon bei der DIN V 18599-11 - er EnEV-Norm). […]

Zum Fragebogen:

1. Ja - bei der Durchgängigkeit von Planung - Ausschreibung - Engineering - Commissioning

- Betrieb - sehr - und ich sorge bei der Regelsetzung dafür, dass die Grundlagen.

2. Auf Standardisierten, edv-fähigen Funktionen und Modellen beruhende Konzepte.

3. Da nur die Raum- oder eher Hausautomation berücksichtigt ist, fehlt noch sehr viel.

Anlagenautomation ist weitaus komplexer als Raumautomation.

4. a, Für die Anforderungserhebung hat der VDI ein Arbeitsblatt zur Bedarfsermittlung

erarbeitet. Das wird bald erscheinen.

4. b, Wenn in BIM eingebunden möglicherweise ja - jedoch die "Verkehrssitte" spricht

dagegen.

4. c, Vielleicht - nicht zu 100 %

4. d, JA - aber die Hersteller wünschen das (noch) nicht.

5. Rationalisierung spart immer Zeit und Kosten - und Fehler

6. Sie haben noch viel Arbeit vor sich! Und ein Blick in die Praxis würde nicht schaden.

128

Anhang I

Anhang I

Interview Herr Reiff, Geschäftsführer Tributech GmbH vom 25.09.2017

Fragebogen zur Auswertung im Interview

Ich möchte Sie nun bitten, ein paar standardisierte Fragen zum vorgestellten Ansatz zu

beantworten. Darüber hinaus haben Sie die Möglichkeit, im Freitext ein ausführliches

Feedback zu meinem Engineeringansatz zu geben.


kurz beim Engineering, von Gebäudeautomationssystemen?

Als Unternehmer, der nicht aus dem Baugewerbe kommt, ist die Errichtung eines

Firmengebäudes ein quasi einmaliges Großprojekt, welches weit außerhalb des eigenen

Erfahrungshorizontes liegt. Wer nicht zufällig vorher schon einmal Erfahrungen im eigenen

Hausbau sammeln durfte, wird von der Flut an Aufgaben, Vorschriften und Regelungen

überhäuft. Gut ist es, wenn man einen verlässlichen Partner im Planungsprozess an seiner

Seite hat, der durch die verschiedenen Instanzen führt. Für mich ist dieser Ansprechpartner in

erster Linie das Architekturbüro. Dieses ist für mich verantwortlich dafür, dass die Planungen

stimmen und das Gebäude im Rahmen vom Zeit- und Kosten-Plan steht und bezugsfertig ist.

Jede Verzögerung am Bauprozess bedeutet für mein Unternehmen ein Verlust, da das

Gebäude gebraucht wird, sonst würde es nicht gebaut. Weder ich, noch mein Unternehmen

haben die Expertise und die Zeit sich neben dem eigentlichen Kernauftrag mit dem neuen

Gebäude und den Problemen damit zu beschäftigen. Dafür habe ich einen Fachmann

eingestellt, den Architekten, der mit seinem Team das Großprojekt erstellen soll. Für mich

stellen die vielen verschiedenen Fachfirmen aus den verschiedenen Gewerken, welche

wiederum nach unterschiedlichen Vorschriften und unterschiedlichen Methoden arbeiten

müssen, ein großes Problem dar. Ich bin kein Fachmann und kann es nicht erkennen, wenn

mir Pläne vorgelegt werden, ob diese kollidieren. Ich übergebe meine Vorstellungen an das

Architekturbüro und möchte von diesem kontaktiert werden, wenn Dinge zu entscheiden sind.

Die sollten aus meiner Sicht auch den Überblick haben, was am Bau gerade passiert. Gerade

in Bezug auf die Gebäudeautomatisierung und die Anlagen sehe ich den Grad der Komplexität

und die unterschiedlichen Planungsmethoden der vielen Firmen als

sehr problematisch. Die besten Funktionen nützen nichts, wenn sie nicht anständig verbaut

und geplant sind.



Grundsätzlich sollten alle Beteiligten wissen, wovon sie sprechen und eine einheitliche

Sprache sprechen. Ich denke, ein gemeinsamer Plan, welcher durch ein Architekturbüro oder

bei Sanierungen auch durch eine zentrale Ansprechstelle, gesteuert wird, wäre sehr hilfreich.

Eine Firma, die die gesamte Geräte- und GA-System-Installation alleine kann, wäre eine

geschickte Lösung. Aber es ist fraglich, ob die Expertise in allen Bereichen so ausgeprägt

wäre, wie bei Fachfirmen der Gewerke. Im gesamten Konzept ist für mich wichtig, dass es

funktioniert und keine unvorhergesehenen Umplanungen oder Probleme auftreten. Diese

kosten in aller erster Linie Zeit und Zeit ist in der Geschäftswelt Geld.



Anforderungen?

129

Anhang I

Ich finde die Idee grundsätzlich gut, dass die Bauherren nur mit dem Architekten und dem

Anforderungstool arbeiten können. Die Bedienung sieht leicht verständlich aus. Den Grundriss

als Basis zu nehmen finde ich konsequent, so ist auch nur ein grundsätzlicher Plan im Umlauf

und kann für die Ausführung auf die Fachfirmen wieder geteilt werden. Diese kennen dann

ihre Schnittstellenpartner und wissen, mit wem sie darüber sprechen müssen, um

Planungsfehler zu vermeiden. Auch die Möglichkeit, verschiedene Versionen vorab zu testen,

ist sehr hilfreich, gerade wenn es um die Kosten des Systems geht. Die Frage ist ja letztlich,

wann sich die Mehrausgaben für ein GA-System amortisiert haben. Insgesamt denke ich, dass

der Ansatz helfen kann, den Einbau und die Realisierung für GA-Systeme zu erleichtern.



Ich denke, der Ansatz ist in der Theorie gut geeignet, Kosten beim Einbau von GA-Systemen

in den planerischen Maßen zu halten. Die große Gefahr beim Bau von Gebäuden und auch

dem Einbau der Anlagen und Geräte besteht bei Fehlplanungen oder falschen Einbauten,

welche die Kosten explodieren lassen. Gegen das falsche Einbauen kann der Ansatz auch

keine Verbesserung bewirken. Durch die Überprüfung kann das eventuell schneller festgestellt

werden. Ich denke, die Chancen, dass das GA-System durch die Betrachtung als ein System,

weitestgehend ohne Planungsfehler geplant werden kann, sind sehr gut und das Vorgehen

spart sicherlich Zeit und damit auch Kosten. Die Qualität des Systems ist grundsätzlich von

den verwendeten Komponenten abhängig. Die Möglichkeit die Funktionslogik vorab zu testen,

ist stellt dabei nur eine Mindestqualität sicher. Es wäre aber wünschenswert, dass diese

Vorgehensweise von vornherein im CAD-Programm hinterlegt würde, so dass dort alle

Informationen zusammen sind. Weiterhin wäre es schön, eine Art „Wizard“ zu haben, der durch

das Programm führt und die Simulation sollte anschaulicher in der Grafik sein. Schön wäre es,

wenn man das Gebäude im Betrieb grafisch simulieren könnte. Für mich wäre die Ergänzung

um die Berechnung der Kosten und der Einsparmöglichkeiten eine wichtige und sinnvolle

Ergänzung. So kann ich als Unternehmer abschätzen, wann sich das GA-System amortisiert

hat und sich die Investition gelohnt hat. Für diese Erweiterung bietet der Ansatz sicherlich ein

solides Fundament.

130

Anhang J

Anhang J

TROAR Peter Barnscheidt, AK GA BW beim BAIUDBw KompZBauMgmt Wi K3

Sehr geehrte Frau Günther,

zuerst einmal möchte ich das Aufgabengebiet der Gebäudeautomation in der Infrastruktur der

Bundeswehr kurz vorstellen damit sie Verständnis für meine Sichtweise auf ihr beschriebenes

Modell haben.

Grundlage für das Bauen des Bundes ist die „Richtlinie für die Durchführung von Bauaufgaben

des Bundes“ (RBBau). Hierin beschrieben ist die Organisation und Aufgaben, die

Eingliederung der Bauausgaben in den Bundeshaushaltsplan und die Bewirtschaftung der

Mittel, das Verfahren von kleinen und großen Baumaßnahmen, die Bauausführung, die

Übergabe und Bestandsdokumentation sowie fachliche Einzelgebiete wie u.a.

Projektmanagement und Wirtschaftlichkeitsuntersuchungen.

Der Bund baut nicht etwa selbst sondern beauftragt in der Regel zum Bauen die

Landesbauverwaltungen der Bundesländer. Eigentümer der Bundesliegen-schaften ist

wiederum die Bundesanstalt für Imobilienaufgaben (BIMA) und nicht das jeweilige Ressort z.B.

bei Kasernen die Bundeswehr.

Zur Planung, Ausführung und Betrieb von Anlagen der Gebäudeautomation hat die

Bundeswehr eine baufachliche Richtlinie erlassen. Diese ist auch für die BIMA und die

staatlichen Bauverwaltungen bindend. Sie erscheint als Zentralvorschrift Gebäudeautomation

A1-1810/0-6503 mit der Anlage 5.2 „Handbuch Gebäudeautomation“.

Im Handbuch Gebäudeautomation wird in Anlehnung an die VDI 3814 bzw DIN EN ISO 16484

die Planung, Ausführung und Betrieb von Anlagen der Gebäudeautomation in der Bw

beschrieben.



Zu Beginn einer Bauplanung muss sich der Planungsverantwortliche erst einmal über die

verschiedenen Faktoren die seine Bauplanung beeinflussen könnten im Klaren sein. Aufgrund

seiner daraus gewonnenen Erkenntnisse wird er entscheiden mit welchen Methoden und

Maßnahmen und in welchem Umfang er die Planung der Gebäudeautomation betreibt. Je

größer, komplexer und risikobehafteter eine Baumaßnahme im Bereich der Techn.

Gebäudeausrüstung ist desto mehr Aufwand wird er betreiben müssen um die Ziele

Funktionalität und Wirtschaftlichkeit zu erreichen.

Eine überschaubare Baumaßnahme z.B. Unterkunftsgebäude der Bw kann durchaus nach

konventionellem Bauprozess (Gewerke getrennte Planung und Ausführung aber mit

koordinierender und integrativer Gebäudeautomation erfolgreich geplant und gebaut werden.

Hierbei sind die Standardplanungen z.B. HB GA Bw und Standardvorgaben anzuwenden

deren Einhaltung durch die Verantwortlichen aber konsequent einzufordern und zu überprüfen

sind.

Bei komplexeren Baumaßnahmen z.B. Flugsimulator Gebäude besteht durchaus die

Notwendigkeit einen durchgängigen und ganzheitlichen Planungsansatz im Sinne ihrer

Methodenbeschreibung zu wählen. Hier ist der GA Fachplaner gefordert der die GA im Sinne

eines eigenständiges Gewerk nach DIN 276 plant.

131

Anhang J

Ihrer These (Seite 4, 3.Absatz, letzter Satz) kann ich nur bedingt zustimmen. Die GA Hersteller

bieten alle Funktionen nach VDI 3813 und 3814 an. Eine herstellerunabhängige

Vorgehensweise bei der Planung von GA Systemen erfordert in der Regel einen höheren

Aufwand an Planung und Koordinierung der vom Aufwand her auch gerechtfertigt sein muss.

Bei überschaubaren Baumaßnahmen, z.B. Erweiterungen der vorhandenen GA, ist eine

herstellergebundene Planung durchaus sinnvoll und geboten zumal viele GA Firmen mit

eigenen Planungstools arbeiten. Z.B. WEBProjekt von GFR oder CASE Suite von Sauter.

Damit haben sie dann nicht nur ihre Anlage geplant sondern bekommen auch gleichzeitig eine

homogene in sich abgestimmte Gebäudeautomation aus einer Hand.

Im Bereich der Bw werden grundsätzlich Inselbereiche (i.d.R. Kasernen) im Rahmen von

Erstausschreibungen mit homogenen GA Systemen

(Managementebene, Automationsebene, Feldebene) eines Herstellers installiert. Die GA

Systeme der Hersteller werden im Rahmen einer Qualifizierung/Zertifizierung durch den

Arbeitskreis Gebäudeautomation der Bw auf Übereinstimmung mit den Funktionen und

Forderungen des Handbuchs Gebäudeautomation geprüft. Diese proprietären Systeme eines

GA Herstellers werden im Betrieb durch geschultes Bw Personal (Bw) eigenständig betrieben.

Die Unterstützungsleistung der GA Firma im Rahmen der Instandhaltung ist die Ausnahme.

Um entstehende Abhängigkeiten von den GA Firmen zu minimieren werden im Rahmen der

Erstausschreibungen Rahmenverträge zu den im Wettbewerb erzielten Preisen für die Dauer

von 4 bzw. 8 Jahren abgeschlossen.

Probleme mit Baumaßnahmen gibt es meist dann wenn Planer oder ausführende Firmen von

den eigentlich bekannten Vorgaben/Standards bewusst oder unbewusst abweichen. Diese

Abweichungen führen dann oft zu Nacharbeit, Zeitverzug und höheren Kosten. Nicht selten

resultieren hieraus Einschränkungen, erhöhte Aufwände und Probleme im anschließenden

Betrieb.

Hier sehe ich den eigentlichen Handlungsbedarf, die vorgegebenen Strukturen und Standards

durch Bauverwaltung und Firmen umzusetzen und deren Einhaltung aus Bauherrn und

Betreiber Sicht konsequent einzufordern. Leider gelingt uns dies nicht immer.

Ein weiteres Problem stellen die internen Regelungen verschiedenster Betriebstechnischer

Anlagen (z.B Anlagen der Wasserhygiene, der Lüftung, der Wärmeerzeugung u.s.w) diverser

Hersteller dar. Hier wir die Gebäudeautomation mittlerweile zu einem System der

Visualisierung, des Störmeldemanagements und des Schnittstellenmanagements reduziert.

Die Bw hat hierauf reagiert und hat Standardschnittstellen im Bereich der kommunikativen

Feldbussysteme definiert bzw. festgelegt. Unikatlösungen wie Gateways werden abgelehnt.

Wir fordern für die Anlagen die in den GA Funktionslisten festgelegten Datenpunkte nach HB

GA Bw ein die dann analog, digital oder kommunikativ zur Verfügung gestellt werden müssen.



Allgemein muss eine gute Methode zielführend, handhabbar, allgemein anerkannt, der

Aufgabe angemessen, kostengünstig und im zeitlichen Rahmen zum Ziel führen.

Wie bereits zu 1. erwähnt hat der Planungsverantwortliche eine der Aufgabe angemessene

Methode auszuwählen.

132



Anforderungen?

Ihr vorgestellter Ansatz ist theoretisch und abstrakt, berücksichtigt leider nur die

Raumautomation und nicht die Gebäudeautomation, ist in der zeitlichen Folge schlüssig und

inhaltlich richtig, aber wahrscheinlich nur bedingt im realen Bauen bei kleinen und mittleren

Gebäuden umsetzbar, wird aber zukünftig u.a. in BIM GA grundsätzlich eingesetzt werden.

In dem Kap. 3.2 beschreiben sie den Aufbau des Tools und Umsetzung in AutomationML

sowie die Nutzung von diversen Bibliotheken und die Erstellung von Tempates. Dies haben

sie in der PP Präsentation visualisiert aber aus meiner Sicht viel zu kurz erklärt und

beschrieben. Auch fehlt mir vollkommen das Konzept und die Darstellung für die funktionale

Umsetzung von der Raumautomation zur Gebäudeautomation.

4. Bezogen auf die Einzelabschnitte des Ansatzes:

a. Glauben Sie, dass der Ansatz die Anforderungserhebung erleichtert?

Ja, wenn es gelingt dass Planer und Bauherr die gleiche Sprache sprechen.

b. Glauben Sie, dass durch ein Modell des GA-Systems die Planung effektiver wird?

Ja, mit Sicherheit, denn das Ergebnis der Planung wird weniger fehlerbehaftet sein.

c. Glauben Sie, dass die Durchgängigkeit des Ansatzes Planungsfehler vermeiden

kann?

Durch ein funktionierendes GA Systemmodell hat man ja immer noch nicht die Planer der

anderen Gewerke „eingefangen“. Die Reduzierung von Planungsfehlern im Gewerk

Gebäudeautomation ist erst der erste Schritt. Hier muss eine planerische Schnittstelle

geschaffen werden die Planungen der Betriebstechn. Anlagen der Gewerke und die der

Gebäudeautomation synchronisiert.

d. Glauben Sie, dass die integrale Betrachtung des GA-Systems über alle Engineering-

Phasen die Realisierung von GA-Systemen erleichtert?

Ja wenn das Tool praktikabel und durchgängig zur Verfügung steht und der Aufwand dem

Ergebnis angemessen ist.



Die Leistungen eines Planers (Architekt/Ingenieur) sind in Deutschland nach der

Honorarordnung (HOAI) in Leistungsphasen gegliedert. Wie wird ihr durchgängiger

Engineeringansatz sich auf die Phasen 1 bis 5 der HOAI umlegen lassen? Nicht selten werden

die Leistungsphasen bei der GA nicht durchgängig beauftragt.


Siehe Vorbemerkungen.

133

Anhang K

Anhang K

Interview Herr Pötzsch, Bundesamt für Infrastruktur, Umweltschutz und Dienstleistungen der

Bundeswehr (BAIUDBw) vom 27.09.2017


kurz beim Engineering, von Gebäudeautomationssystemen (GA-Systeme)?

Planung:

Der Architekt ist meist der „Designer“ und Koordinator eines Bauprojektes. Sein Wissen ist

jedoch auf Grund seiner akademischen Ausbildung meist sporadisch im Fachgebiet der Statik.

Bei Nachweisen muss eine zusätzliche Fachexpertise eingeholt werden. Diese Expertise wird

grundsätzlich durch Bauingenieure geleistet. Äquivalent sollte es auch bei GA-System sein.

Ein GA-Ingenieur, der als Bindeglied zwischen den Heizungs-, Elektrik- und Wasser- bzw.

Abwassersystemen sowie dem Architekten fungiert. Die benötigte Fachexpertise ist auf Grund

der Vielseitigkeit an technischen Systemen sehr umfangreich.

Ohne eine umfangreiche Standardisierung im Bereich der GA-Systeme sollte ein separater

GA-Ingenieur den Anteil übernehmen. Allerdings je höher die Standardisierung der GA-

Systeme voranschreitet, je geringer ist auch die Notwendigkeit eines GA-Ingenieurs. Mit

steigender Komplexität und eines Projektes steigt auch die Notwendigkeit eines GA-

Ingenieurs.

Installation:

Hier ist die Überwachung und die ganzheitliche Betrachtung essentiell für den fehlerfreien

Aufbau der Elemente in Verbindung mit dem GA-System. Eine Überwachung bzw. die

Betreuung der Gewerke und die Koordinierung von einem

fachkundigen Experten für GA-Systeme stellt einen reibungslosen Fortschritt des Projektes

bei der Automatisierung sicher.

Betrieb:

Beim Betrieb sind zum einen bekannte Systeme für das „Monitoring“ einzubauen aber auch

besonders Sensoren zur Überwachung, sodass Techniker mögliche Warnungen erhält und

Analysen aus der Ferne durchführen kann. Der Bauunterhalt als auch die Überwachung der

Systeme ist sicherlich ein ganz besonderer Faktor, der hinsichtlich bei der Planung und der

Kostenaufstellung zu berücksichtigen ist und durch zu installierende GA-Systeme amortisiert

werden muss.

Aus eigener Erfahrung mit GA-Systemen müssen diese gerade für den Bauunterhalt leicht zu

handhaben und robust sein, da sich sonst über die Zeit der Zustand schneller verschlechtert

und Investitionen früher notwendig sind.



„Die Spinne im Netz“ ist der Schlüssel zum Erfolg.

Der GA-Ingenieur bzw. der Fachplaner für GA-Systeme, der den Architekten und die Gewerke

betreut, führt die „Fäden“ zusammen.

134



Anforderungen?

Das Schalenmodell ist die hierarchische Strukturierung und sollte auch ein

geeignetes Mittel sein, um der Problematik zu begegnen.

Das Schalenmodell sollte aber auch hinsichtlich der Modifikation (Neuer Stand der Technik)

und hinsichtlich der Erweiterbarkeit auf neue Bereich (Räume, Liegenschaften u.ä.) anpassbar

sein.

Die durchgängige Betrachtung und die Überprüfungsmöglichkeiten sind sinnvolle

Erweiterungen in der Planung von GA-Systemen. Auch die Teilmodellerstellung macht in

Teilen Sinn.

Der Ausgangspunkt des konventionellen Bauprozesses nutzt jedoch nicht die Expertise des

GA-Fachplaners bzw. GA-Ingenieurs. Dies kann, gerade vor dem Hinblick der komplizierten

Systemintegration gerade von Systemen verschiedener Hersteller in der Praxis zu

schwerwiegenden Fehlern führen, da die Interoperabilität und die Standardisierung in der GA-

Branche noch nicht weit fortgeschritten ist.



Sofern die Beauftragung eines GA-Fachplaners aus Kostengründen vermieden wird, kann der

Ansatz eine Verbesserung zu der rein Gewerke getrennten Planung erreichen.


Die Folge des Ansatzes muss eine Reduktion der benötigten Fachexpertise für GA-Systeme

und bzw. oder für Kosten beim Bauunterhalt sowie der Überwachung herbeiführen. Des

Weiteren ist zwangsläufig zu beachten, dass bei einer höheren Interoperabilität der GA-

Teilsysteme voraussichtlich mit steigenden Integrationskosten zu rechnen ist, die auch über

das Investment und über die Nutzungsdauer, als auch den Restwert von Gebäuden mit zu

berücksichtigen sind.

135

Anhang L

Anhang L

Interview mit Herr Bonsels, Objektplaner Halle Tributech, 27.09.2017

Fragebogen zur Auswertung im Interview

Ich möchte Sie nun bitten ein paar standardisierte Fragen zum vorgestellten Ansatz zu

beantworten. Darüber hinaus haben Sie die Möglichkeit im Freitext ein ausführliches Feedback

zu meinem Engineeringansatz zu geben.



GA-Systeme sind immer einzelne Gesamtsysteme, welche auf jedes Objekt zugeschnitten

werden müssen. Ein großes Handlungsfeld sehe ich in der grundsätzlichen Debatte, wo macht

es Sinn von den Arbeiten in den Gewerken zu sprechen und ab welcher Größe sprechen wir

von einem GA-System? Kann die Steuerung zwischen Heizung und Klimaanlage schon ein

GA-System sein? Ein weiteres Problem sehe ich schon bei der Konzeption von Gebäuden.

Die Anforderungen an ein Gebäude nehmen immer weiter zu, auch während dem Bauprozess.

Zu Beginn der Konzepterstellung haben Bauherrn mittlerweile eine gute Vorstellung davon,

wie Ihr Bauwerk aussehen soll und welche Raumfunktionalitäten in welchen Größen

abgebildet werden müssen. Die „Grundausstattung“ mit Heizung, Wasser- und

Stromversorgung wird bei vielen Bauherren überhaupt nicht als „Extra“ sondern als

selbstverständlich wahrgenommen. Das führt dazu, dass sich Viele die Gedanken über die

heutigen Möglichkeiten erst im Rahmen des Planungsprozesses machen und so durch

Planänderungen zwangsläufig das Projekt in die Länge treiben. Daher ist die Einbindung eines

speziellen Fachplaners meist nicht die erste Wahl zu Beginn der Planungsphasen. Erst durch

immer mehr Änderungen werden aus einfachen, eigenständigen Anlagen und Geräten, GA-

Systeme. Das bedeutet die Gedanken, dass ein Fachplaner von Nöten ist, kommt meist zu

spät, da auch dieser Geld kostet. Erst im Laufe des Prozesses und oft auch erst deutlich nach

Baubeginn stehen die Ausplanungen auch von Seiten der Bauherren fest. Die Fachplaner

kennen sich auf ihren Gebieten enorm aus, aber auch diese sind an einem vollständigen

Auftrag interessiert und führen diesen auch aus. Die Mehrarbeit über eventuelle Schnittstellen

zu anderen Gewerken nachzudenken oder diese

abzustimmen findet nur in dem dafür notwendigen Maße statt. Wenn durch ein solches GA-

System plötzlich mehr Gewerke und damit Schnittstellen als üblich da sind, machen die

meisten aus Gewohnheit das, was sie sonst auch tun. Da aber jede Firma nur dann bezahlt

wird, wenn sie auftragsgemäß ihrer Leistung nachgekommen sind, wird jede Firma zunächst

diesen Auftrag ausführen ohne über eventuelle Fehlplanungen oder Unsinnigkeiten

nachzudenken. An dieser Stelle sind unsere Bürokratie und unser verfahrener Bauprozess

eine Großbaustelle.



Ich denke der Bauprozess, so wie er heute ist, wird sich nur mühsam und langsam von alleine

ändern lassen. Eine Reformierung der gültigen Vorschriften und Regelungen und vor allem

eine Entfrachtung dieser wären dringend notwendig. Dies muss aber von Seiten der

Erlasshalter kommen.

136

Anhang L

Die frühere Einbindung eines GA-Fachplaners in den Bauprozess wäre ebenfalls denkbar, um

die GA als ganzes System zu betrachten, wie gesagt wird die Notwendigkeit vor dem

Hintergrund der zusätzlich Kosten oft unterschätzt.

Davon unabhängig wäre es hilfreich, wenn die Anforderungen an ein Gebäude am Anfang des

Bauprozesses einmal definiert werden und diese dann sukzessive abgearbeitet werden. Im

besten Fall geschieht dies aus einer Hand und ohne Informationsverluste.



Anforderungen?

Der Ansatz sieht zunächst sehr durchdacht aus und hat das Problem der unterschiedlichen

Planungsvorgänge erfasst. Er bietet damit einen guten Mittelweg zwischen dem Einschalten

eines GA-Fachplaners und der Planung in den Gewerken. Die Überprüfungsmethode ist eine

gute Möglichkeit mehrere Szenarien durchzutesten, jedoch bezweifle ich, dass es viele

Szenarien davon geben wird. Wichtiger ist die Erkenntnis, dass der Bauherr sich frühzeitig

über die Funktionalitäten seines Gebäudes im Klaren wird und sich darüber Gedanken

macht. Noch lieber wäre es mir persönlich, wenn diese Gedanken bereits vor der Grundriss-,

und damit Raumbuchplanung, erfolgen.



Dieser Ansatz hat durchaus das Potenzial bezüglich der GA zu einer Verbesserung des

Planungs- und Ausführungsprozesses zu führen, sofern er konsequent auch von den

handelnden Personen durchgeführt wird. Bezüglich der Zeit glaube ich nicht, dass er viel Zeit

einsparen kann, sofern der gesamte Planungsprozess auch ohne diesen Ansatz vernünftig

läuft. Bei komplexen Systemen sehe ich aber auch hier den Zeitgewinn durch die

Verhinderung von Planungsfehlern und dem damit einhergehenden Zeitverlust. Das Gleiche

gilt im Grunde für die Kosten. Die Geräte selber werden durch diese Methode nicht günstiger.

Wenn ich aber die freie Wahl habe zwischen verschiedenen Herstellern und nicht per

Entscheidung auf einen Hersteller angewiesen bin, wird sich der Markt durch den

aufkommenden Konkurrenzdruck über die Zeit anpassen. Die dargestellten Programme sind

noch sehr rudimentär und sehen noch nicht sehr benutzerfreundlich aus. Schön wäre zudem

eine konkrete Kostenabschätzung am Ende der Planung. Aufgrund der vielen Gerätepreise

und auch den Unterschieden bei den Ausführungsfirmen, wird das ohne weiteres nicht möglich

sein. Letztlich werden gerade bei großen Bauten die einzelnen Tätigkeiten ausgeschrieben

und bei diesen Ausschreibungen kommen teilweise sehr große Preisunterschiede heraus.

Also insgesamt halte ich den Ansatz für den Mittelweg aus einer vollständigen Fachplanung

der GA und der eher rudimentären GA-System-Planung in den einzelnen Gewerken.

137

Anhang M

Anhang M

138

Anhang M

139

Literaturverzeichnis


[AfMi16] S. Afshari, S. Mishra: A Plug-and-Play Realization of Decentralized Feedback

Control for Smart Lighting Systems. In: IEEE Transactions on Control Systems

Technology, vol. 24, no. 4, S. 1317–1327, 2016.

[Arr17] E.E. Arroyo: Capturing and Exploiting Plant Topology and Process Information as

a Basis to Support Engineering and Operational Activities in Process Plants.

Hamburg, Helmut-Schmidt-Universität / Universität der Bundeswehr Hamburg,

Institut für Automatisierungstechnik. Dissertation, 2017.

[Asc14] B. Aschendorf: Energiemanagement durch Gebäudeautomation. Wiesbaden:

Springer Vieweg, 2014.

[ASK+10] A. Andrushevich, M. Staub, R. Kistler, A. Klapproth: Towards Semantic Buildings:

Goal-driven approach for building automation service allocation and control. In:

IEEE 15th International Conference on Emerging Technologies and Factory

Automation (ETFA), September 13-16, 2010.

[Bal12] J. Balow: Systeme der Gebäudeautomation: Ein Handbuch zum Planen,

Errichten, Nutzen. 1. Aufl. Karlsruhe: cci Dialog, 2012 (Grundlagen beraten +

planen).

[BDH+14] D. Bruckner, T. Dillon, S. Hu, P. Palensky, T. Wei: Guest Editorial Special

Section on Building Automation, Smart Homes, and Communities. In: IEEE

Transactions on Industrial Informatics, vol. 10, no. 1, S. 676–679, 2014.

[BeKn16] M. Becker, P. Knoll: Nachhaltiges Planen, Bauen und Betreiben durch Einsatz

von Gebäudeautomation: Hochschule Biberach, 2016.

[BFD+12] F.J. Bellido-Outeirino, J.M. Flores-Arias, F. Domingo-Perez, A. Gil-de-Castro, A.

Moreno-Munoz: Building lighting automation through the integration of DALI with

wireless sensor networks. In: IEEE Transactions on Consumer Electronics, vol.

58, no. 1, S. 47–52, 2012.

[BGN+14] B. Butzin, F. Golatowski, C. Niedermeier, N. Vicari, E. Wuchner: A model based

development approach for building automation systems. 2014 IEEE [International

Conference on] Emerging Technologies and Factory Automation (ETFA 2014):

Barcelona, Spain, 16 - 19 September 2014, 2014.

[BKK+15] A. Borrmann, M. König, C. Koch, J. Beetz: Building Information Modeling.

Wiesbaden: Springer Fachmedien Wiesbaden, 2015.

[Bun15a] Bundesministerium für Wirtschaft und Energie: Energieeffizienzstrategie für

Gebäude: Wege zu einem nahezu klimaneutralen Gebäudebestand. München:

PRpetuum GmbH, 2015.

[Bun17] Bundesministerium für Umwelt, Naturschutz, Bau und Reaktorsicherheit:

Standardleistungsbuch für das Bauwesen des Gemeinsamen Ausschusses

Elektronik im Bauwesen, 2017.

[Che02] P.P.-S. Chen: The Entity Relationship Model — Toward a Unified View of Data.

In: Broy, Denert (Hrsg.): Software Pioneers: Contributions to Software

Engineering. Berlin, Heidelberg: Springer Berlin Heidelberg, S. 311–339, 2002.

140


[CHF14A] L. Christiansen, M. Hoernicke, A. Fay: Modellgestütztes Engineering: Basis für

die Automatisierung der Automatisierung. In: atp-edition /

Automatisierungstechnische Praxis, Vol. 3, 2014.

[CHF14B] L. Christiansen, M. Hoernicke, A. Fay: Regelbasierte Erstellung von Topologie-

Modellen im Kontext der „Automatisierung der Automatisierung“. In: Entwurf

komplexer Automatisierungssysteme (EKA), 2014.

[CHF14C] L. Christiansen, M. Hoernicke, A. Fay: Entwicklung eines Modellverbinders zur

Vermeidung von Inkonsistenzen zwischen Modellen im Kontext des

modellbasierten Engineerings. In: Automation 2014, 2014.

[CKG+07] K.J. Charatsis, A.P. Kalogeras, M. Georgoudakis, G. Papadopoulos: Integration

of Semantic Web Services and Ontologies into the Industrial and Building

Automation Layer. In: EUROCON 2007 The International Conference on

“Computer as a Tool”, S. 478–483, 2007.

[DeLi06] M. Degen, T. Liebich: IFC-Austauschformat für die TGA. In: IHKS

Industrieverband Heizungs-, Klima- und Sanitärtechnik Bayern, Sachsen und

Thüringen e.V. (Hrsg.): Fach.Journal, 2006/2007.

[Dib13] H. Dibowski: Semantischer Gerätebeschreibungsansatz für einen automatisierten

Entwurf von Raumautomationssystemen. Dresden, Technische Universität

Dresden, Informatik. Dissertation, 2013.

[Dib17A] H. Dibowski: Semantic Interoperability Evaluation Model for Devices in

Automation Systems. In: IEEE 22nd International Conference on Emerging

Technologies and Factory, 2017.

[Dib17B] H. Dibowski: Automatically enabled analytics in buildings and smart homes. at -

Automatisierungstechnik, Vol. 65 (9), 2017.

[DiKa11] H. Dibowski, K. Kabitzsch: Ontology-Based Device Descriptions and Device

Repository forBuilding Automation Devices. EURASIP Journal on Embedded

Systems, 2011.

[DiSc13] P. Diekhake, E. Schnieder: Online Monitoring of a Distributed Building

Automation System to Verify Large Sequences of Bus Messages by Causal Petri

Net Models. In: 39th Annual Conference of the IEEE Industrial Electronics

Society, S. 3651–3655, 2013.

[DiSc14] P. Diekhake, E. Schnieder: Analyse und Überwachung des Zeitverhaltens von

Funktionsabläufen in einem verteilten Automatisierungssystem. In: Entwurf

komplexer Automatisierungssysteme (EKA), 2014.

[DiSc15] P. Diekhake, E. Schnieder: Strukturierte Modellierung, Simulation und

Überwachung verteilter Automatisierungssysteme. at - Automatisierungstechnik,

Vol. 63 (2), 2015.

[DKR+07] H. Dibowski, K. Kabitzsch, S. Runde, A. Fay: Ein Konzept zur

gewerkeübergreifenden Automatisierung von Engineering-Aufgaben in

Gebäudeautomatisierungssystemen. In: GMA-Kongress 2007 - Automation im

gesamten Lebenszyklus, Baden-Baden.

141


[DPK10] H. Dibowski, J. Ploennigs, K. Kabitzsch: Automated Design of Building

Automation Systems. In: IEEE Transactions on Industrial Electronics, vol. 57, no.

11, S. 3606–3613, 2010.

[Dra10] R. Drath: Datenaustausch in der Anlagenplanung mit AutomationML: Integration

von CAEX, PLCopen XML und COLLADA. Berlin, Heidelberg: Springer-Verlag,

2010 (VDI-Buch).

[ElNa02] R. Elmasri, S.B. Navathe: Grundlagen von Datenbanksystemen. München:

Pearson Studium, 2002.

[ERZ14] M. Eigner, D. Roubanov, R. Zafirov (Hrsg.): Modellbasierte virtuelle

Produktentwicklung. Aufl. 2014. Berlin, Heidelberg: Springer Berlin Heidelberg,

2014.

[FeKa16] A. Fernbach, W. Kastner: Gebäudemanagement durch wissensbasierte

Systeme. In: Hochschule Ostwestfalen-Lippe, Institut für Automation und

Kommunikation e.V. Magdeburg et al. 2016 – 7. Jahreskolloquium

Kommunikation.

[Fel17] C. Felsmann: Der Beitrag der Gebäudeautomation zum energieeffizienten

Gebäudebetrieb. at - Automatisierungstechnik, Vol. 65 (9), 2017.

[GlFa15] M. Glawe, A. Fay: Wissensbasiertes Engineering automatisierter Anlagen unter

Verwendung von AutomationML und OWL. at - Automatisierungstechnik, Vol. 63

(3), 2015, S. 186–198.

[GPK10] W. Granzer, F. Praus, W. Kastner: Security in Building Automation Systems. In:

IEEE Transactions on Industrial Electronics, vol. 57, no. 11, S. 3622–3630, 2010.

[GrKa12] W. Granzer, W. Kastner: Information Modeling in Heterogeneous Building

Automation Systems. In: IEEE International Workshop on Factory

Communication Systems proceedings, 2012.

[GRL+13] A.M. Gibney, S. Rea, M. Lehmann, S. Thior, S. Lesecq, M. Hendriks, C.

Gardeux, L.T. Mai, F. Pacull, J. Ploennigs, T. Basten, D. Pesch: A systematic

engineering tool chain approach for self-organizing building automation systems.

In: IECON 2013 - 39th Annual Conference of the IEEE Industrial Electronics

Society, S. 7696–7701, 2013.

[GrOż16] J. Grela, A. Ożadowicz: Building Automation Planning and Design Tool

Implementing EN 15 232 BACS Efficiency Classes. Piscataway, NJ: IEEE

International Conference on Emerging Technologies and Factory, 2016.

[GTP+15] S. Gökceli, H.B. Tugrel, S. Pisirgen, G.K. Kurt, B. Örs: A Building

Automation System Demonstration. In: IEEE 9th International Conference on

Electrical and Electronics Engineering (ELECO), 2015.

[Haa93] W. Haas: CAD-Datenaustausch-Knigge: STEP-2DBS für Architekten und

Bauingenieure. Berlin, Heidelberg: Springer Berlin Heidelberg, 1993.

[HAF16] X.L. Hoang, E. Arroyo, A. Fay: Automatische Analyse und Erkennung

graphischer Inhalte von SVG-basierten Engineering-Dokumenten.

Automatisierungstechnik, Vol. 64 (2), 2016, S. 133–146.

142


[Hau15] B.J. Hauser: Fachwissen Netzwerktechnik: Modelle - Geräte - Protokolle. 2.

Auflage. Haan-Gruiten: Verlag Europa-Lehrmittel, 2015 (Bibliothek des

technischen Wissens).

[Heg16] H.-D. Hegner: Leitfaden Nachhaltiges Bauen: Zukunftsfähiges Planen, Bauen

und Betreiben von Gebäuden. 2. Aufl., Berlin. 2016.

[Hei13] A. Heidemann: Nachhaltigkeit durch Gebäudeautomation: Auswirkungen von

Gebäudeautomation auf die Nachhaltigkeit von Gebäuden im Lebenszyklus. 1.

Aufl. Stockach: TGA-Verl., 2013.

[Hei14] A. Heidemann: Integrale Planung der TGA. In: Heidemann, Kistemann et al.

(Hrsg.): Integrale Planung der Gebäudetechnik. Berlin, Heidelberg: Springer

Vieweg, S. 7–99, 2014.

[HeSc12] A. Heidemann, P. Schmidt: Raumfunktionen: Ganzheitliche Konzeption und

Integrationsplanung zeitgemäßer Gebäude. 1. Aufl. Stockach: TGA-Verl., 2012.

[HLC14] S.N. Han, G.M. Lee, N. Crespi: Semantic Context-Aware Service Composition for

Building Automation System. In: IEEE Transactions on Industrial Informatics, vol.

10, no. 1, S. 752–761, 2014.

[HRR00] R. Hunstock, S. Rüping, U. Rückert: A Distributed Simulator for Large Networks

Used in Building Automation Systems. In: IEEE International Workshop on

Factory Communication Systems, 2000.

[HXS+14] D. He, Q. Xiong, W. Shi, X. Shi, J. Zhang: Building energy and control system

modeling and simulation using Modelica. In: The 26th Chinese Control and

Decision Conference (2014 CCDC), S. 2794–2797, 2014.

[Ins87] Institute of Electrical and Electronics Engineers: IEEE Standard Glossary of

Computer Applications Terminology, 1987.

[Jan17] F. Jansen: VDI-Agenda Building Information Modelling (BIM): VDI-Richtlinien zur

Zielerreichung. 4. Aufl., Januar 2017.

[JCS+13] T. Jäger, L. Christiansen, M. Strube, A. Fay: Durchgängiges Engineering von der

Anforderungserhebung bis zur Anlagenstrukturbeschreibung. In: at –

Automatisierungstechnik, Vol. 61, S. 92–101, 2013.

[Kab14] K. Kabitzsch: Automatischer Entwurf interoperabler Raumautomation nach VDI

3813. Technische Universität Dresden, Technische Universität Dresden, Vortrag

am 25.09.2014.

[KiAh15] B.Y. Kim, H.S. Ahn: Consensus-Based Coordination and Control for Building

Automation Systems. In: IEEE Transactions on Control Systems Technology, vol.

23, no. 1, S. 364–371, 2015.

[KKJ+14] W. Kastner, M. Kofler, M. Jung, G. Gridling, J. Weidinger: Building Automation

Systems Integration into the Internet of Things: The IoT6 approach, its realization

and validation. In: IEEE 19th International Conference on Emerging Technologies

and Factory Automation (ETFA), 2014.

[KML+17] K. Kabitzsch, T.L. Mai, M. Lehmann, B. Wollschlaeger, H. Engelien, E.

Eichenberg: Vorausschau in frühen Planungsphasen der Gebäudeautomation. at

- Automatisierungstechnik, Vol. 65 (9), 2017.

143


[Kra13] H. Kranz: BACnet Gebäudeautomation 1.12. 3. Aufl. Karlsruhe: cci Dialog GmbH,

2013.

[Kra16] H. Kranz: Agenda Gebäudeautomation (VDI Automationskongress), Baden

Baden. 08.06.2016.

[LAT+17] M. Lehmann, J. Andreas, L.M. Tuan, K. Kabitzsch: Towards a comprehensive life

cycle approach of building automation systems. In: Industrial Electronics (ISIE),

2017 IEEE 26th International Symposium on, 2017.

[LCH+16] Y.t. Lee, S.c.T. Chou, C.m. Huang, W.h. Hsiao: An integrated cloud-based smart

home management system with community hierarchy. In: IEEE Transactions on

Consumer Electronics, vol. 62, no. 1, S. 1–9, 2016.

[LKH14] J. Lauber, H. Kranz, B. Hanke: BauWesen | BauUnwesen: Warum Bauen in

Deutschland schief geht? Courgevaux: Lauber, Jürgen, 2014.

[MuWi16] T. Mundt, P. Wickboldt: Security in building automation systems - A first analysis.

In: International Conference On Cyber Security And Protection Of Digital

Services (Cyber Security), 2016.

[MWA+16] M. Manic, D. Wijayasekara, K. Amarasinghe, J.J. Rodriguez-Andina: Building

Energy Management Systems: The Age of Intelligent and Adaptive Buildings. In:

IEEE Industrial Electronics Magazine (vol. 10, no. 1), vol. 10, no. 1, S. 25–39,

2016.

[Nen99] B. Nentwig (Hrsg.): Baumanagement im Lebenszyklus von Gebäuden: [vom

Bauentwurf bis zum Abbruch]. Weimar: Universitätsverl. (Schriften der Bauhaus-

Universität Weimar, 110), 1999.

[NKG+16] T. Nesztler, D. Kasper, M. Georgescu, S. Loire, I. Mezic: Uniformization,

organization, association and use of metadata from multiple content providers

and manufacturers: A close look at the Building Automation System (BAS)

sector. In: IEEE International Conference on Big Data 2016, 2016.

[NoGe10] T. Novak, A. Gerstinger: Safety- and Security-Critical Services in Building

Automation and Control Systems. In: IEEE Transactions on Industrial Electronics,

vol. 57, no. 11, S. 3614–3621, 2010.

[ODK09] A.C. Oezluek, H. Dibowski, K. Kabitzsch: Automated design of room automation

systems by using an evolutionary optimization method. In: 2009 IEEE

Conference on Emerging Technologies & Factory Automation, S. 1–8, 2009.

[OeKa13] A.C. Oezluek, K. Kabitzsch: Optimal Device Placement Planning for Wireless

Building Automation Systems. In: IEEE 18th International Conference on

Emerging Technologies & Factory Automation (ETFA), 2013.

[Ope13] Open Design Alliance: Open Design Specification for .dwg files. Version 5.3.

USA, 2013.

[OPK10] A.C. Oezluek, J. Ploennigs, K. Kabitzsch: Designing building automation systems

using evolutionary algorithms with semi-directed variations. In: 2010 IEEE

International Conference on Systems, Man and Cybernetics, S. 2328–2335,

2010.

144


[PAK+15] S. Plesser, L. Altendorf, M. Koch, A.-K. Mühlbach, T. Wilken, M.N. Fisch:

Entwicklung einer Methodik zur Integralen Qualitätssicherung über den gesamten

Gebäude-Lebenszyklus auf Basis der DIN V 18599. Stuttgart: Fraunhofer IRB

Verlag, 2015 (Forschungsinitiative ZukunftBau, 2973).

[PDR+11] J. Ploennigs, H. Dibowski, U. Ryssel, K. Kabitzsch: Holistic design of wireless

building automation systems. In: IEEE 16th International Conference on

Emerging Technologies and Factory Automation (ETFA), S. 1–9, 2011.

[PDR+13] J. Ploennigs, H. Dibowski, U. Ryssel, K. Kabitzsch: Ganzheitlicher, automatischer

Entwurf drahtloser Gebäudeautomationssysteme. In: at –

Automatisierungstechnik, Vol. 61, S. 393–402, 2013.

[Pel06] A. Pelzeter: Lebenszykluskosten von Immobilien. In: Schulte, Bone-Winkel

(Hrsg.): Schriften zur Immobilienökonomie. Köln: Rudolf Müller (36), Vol. 36,

2006.

[PFR+14] P. Puntel Schmidt, A. Fay, W. Riediger, T. Schulte, F. Köslin, S. Diehl:

Validierung von Steuerungscode fertigungstechnischer Anlagen mit Hilfe

automatisch generierter Simulationsmodelle. In: Entwurf komplexer

Automatisierungssysteme (EKA), 2014.

[PML+15] A. Puggelli, M.M.R. Mozumdar, L. Lavagno, A.L. Sangiovanni-Vincentelli:

Routing-Aware Design of Indoor Wireless Sensor Networks Using an Interactive

Tool. In: IEEE Systems Journal, vol. 9, no. 3, S. 714–727, 2015.

[Poh12] K. Pohl: Model-based engineering of embedded systems: The SPES 2020

methodology. Heidelberg [u.a.]: Springer, 2012.

[PuFa15] P. Puntel Schmidt, A. Fay: Konsistente Simulationsmodelle für die virtuelle

Inbetriebnahme fertigungstechnischer Anlagen mit Hilfe regelbasierter

Modellverbinder. In: Markus Rabe & Uwe Clausen (eds.) (Hrsg.): Simulation in

Production and Logistics. Stuttgart: Fraunhofer IRB Verlag, S. 177–186, 2015.

[Pun15] P. Puntel Schmidt: Validierung von Steuerungscode mit Hilfe automatisch

generierter Simulationsmodelle. at - Automatisierungstechnik, Vol. 63, 2015,

S. 111–120.

[Pun17] P. Puntel Schmidt: Methoden zur simulationsbasierten Absicherung von

Steuerungscode fertigungstechnischer Anlagen. Hamburg, Helmut-Schmidt-

Universität / Universität der Bundeswehr Hamburg, Institut für

Automatisierungstechnik. Dissertation, 2017.

[QBS14] L.M. Quiroga, U. Becker, E. Schnieder: Das Petrinetz Modellierungs- und -

analysetool Π-Tool. In: at – Automatisierungstechnik, Vol. 62, S. 436–445, 2014.

[RDF+09] S. Runde, H. Dibowski, A. Fay, K. Kabitzsch: A semantic requirement ontology

for the engineering of building automation systems by means of OWL. In: IEEE

Conference on Emerging Technologies & Factory Automation, 2009. Piscataway,

NJ: IEEE, 2009.

[RFH+10] S. Runde, A. Fay, A. Heidemann, P. Schmidt: Engineering der Automationim

Kontext der Bauplanung. at - Automatisierungstechnik, Vol. 10, 2010, 36-47.

145


[RGP+08] C. Reinisch, W. Granzer, F. Praus, W. Kastner: Integration of Heterogeneous

Building Automation Systems using Ontologies. In: 34th Annual Conference of

IEEE Industrial Electronics, S. 2736–2741, 2008.

[RHF+09] S. Runde, A. Heidemann, A. Fay, P. Schmidt: Engineering of building automation

systems - state-of-the-art, deficits, approaches. In: IEEE Conference on

Emerging Technologies and Factory Automation (ETFA), 2010. Piscataway, NJ:

IEEE, 2009.

[RSL+14] M. Ruta, F. Scioscia, G. Loseto, E.D. Sciascio: Semantic-Based Resource

Discovery and Orchestration in Home and Building Automation: A Multi-Agent

Approach. In: IEEE Transactions on Industrial Informatics, vol. 10, no. 1, S. 730–

741, 2014.

[RSS+11] M. Ruta, F. Scioscia, E.D. Sciascio, G. Loseto: Semantic-Based Enhancement of

ISO/IEC 14543-3 EIB/KNX Standard for Building Automation. In: IEEE

Transactions on Industrial Informatics, vol. 7, no. 4, S. 731–739, 2011.

[RSW00] D. Rudolph, T. Stürznickel, L. Weissenberger: DXF intern: Das

Zeichnungsaustauschformat DXF vollständig dokumentiert. 3. Aufl. Essen:

CR/LF, 2000.

[RuFa11] S. Runde, A. Fay: Software Support for Building AutomationRequirements

Engineering: An Application ofSemantic Web Technologies in Automation. In:

IEEE Transactions on Industrial Electronics, Vol. 7, 723–730, 2011.

[Run10] S. Runde: Wissensbasierte Engineeringunterstützung in der

Automatisierungstechnik am Beispiel der Gebäudeautomation. Düsseldorf: VDI

Verlag, 2010 (Fortschritt-Berichte VDI Reihe 20 Nr. 434: Rechnerunterstützte

Verfahren).

[SAB17] H. Scherer, A. Albers, N. Bursac: Model Based Requirements Engineering for the

Development of Modular Kits. Procedia CIRP, Vol. 60, 2017, S. 145–150.

[ScWi08] G. Schnell, B. Wiedemann (Hrsg.): Bussysteme in der Automatisierungs- und

Prozesstechnik: Grundlagen, Systeme und Trends der industriellen

Kommunikation. 7., überarb. und erw. Aufl. Wiesbaden: Vieweg + Teubner

(Praxis), 2008.

[Sei12] R. Seifert: Zukünftige Herausforderungen der Gebäudeautomation im Kontext

neuer energetischer Rahmenbedingungen. In: Servatius, Schneidewind, Rohlfing

(Hrsg.): Smart Energy. Wandel zu einem nachhaltigen Energiesystem. Berlin,

Heidelberg: Springer-Verlag, S. 261–273, 2012.

[Sey11] S. Seyffert: Optimierungspotenziale im Lebenszyklus eines Gebäudes:

Entwicklung und Nachweis eines Modells zur Anwendung der Radio-Frequenz-

Identifikation im Bauwesen. 1. Aufl. Wiesbaden: Vieweg + Teubner, 2011

(Wissenschaft).

[SGS14] G. Schneider, I.K. Geiger, J. Scheuring: Prozess- und Qualitätsmanagement:

Grundlagen der Prozessgestaltung und Qualitätsverbesserung mit zahlreichen

Beispielen, Repetitionsfragen und Antworten. 2., überarbeitete Aufl. Zürich:

Compendio Bildungsmedien, 2014 (Betriebswirtschaftslehre).

146

Normen- und Richtlinienverzeichnis

[SLJ+13] B. Sun, P.B. Luh, Q.-S. Jia, Z. Jiang, F. Wang, C. Song: Building Energy

Management: Integrated Control of Active and Passive Heating, Cooling,

Lighting, Shading, and Ventilation Systems. In: IEEE Transactions on Automation

Science and Engineering, Vol. 10, no. 3, S. 588–602, 2013.

[SlMo11] A. Sleman, R. Moeller: SOA distributed operating system for managing

embedded devices in home and building automation. In: IEEE Transactions on

Consumer Electronics, vol. 57, no. 2, S. 945–952, 2011.

[SLP+12] D. Stein, M. Lehmann, J. Ploennigs, K. Kabitzsch: Sensors, models and platform

for ambient control. In: IECON 2012 - 38th Annual Conference on IEEE Industrial

Electronics Society, S. 4853–4859, 2012.

[SSK+11] T. Sauter, S. Soucek, W. Kastner, D. Dietrich: The Evolution of Factory and

Building Automation. In: IEEE Industrial Electronics Magazine, vol. 5, no. 3,

S. 35–48, 2011.

[Sta16] Statistisches Bundesamt (Hrsg.): Bautätigkeit und Wohnungen: Bautätigkeit.

Wiesbaden, 2016.

[Sta17] Statistisches Bundesamt (Hrsg.): Preise: Daten zur Energiepreisentwicklung,

2017.

[Sta73] H. Stachowiak: Allgemeine Modelltheorie. Wien, New York: Springer, 1973.

[TaWe12] A.S. Tanenbaum, D.J. Wetherall: Computernetzwerke. 5., aktualisierte Auflage.

München, Harlow, Amsterdam, Madrid, Boston, San Francisco, Don Mills, Mexico

City, Sydney: Pearson Higher Education, 2012 (it - Informatik, 4137).

[vER+16] C. van Treeck, R. Elixmann, K. Rudat, S. Hiller, S. Herkel, M. Berger:

Gebäude.Technik.Digital: Building Information Modeling. Berlin, Heidelberg:

Springer Vieweg, 2016 (VDI-Buch).

[VWM+16] K. Voss, A. Wagner et al. (Hrsg.): Performance von Gebäuden: Kriterien,

Konzepte und Erfahrungen. Stuttgart: Fraunhofer IRB Verlag, 2016.

[WeHa13] J. Wenninger, J. Haase: Efficient Building Automation Simulation Using System

on ChipSimulation Techniques. In: 26th International Conference on Architecture

of Computing Systems, 2013.

[Wid13] M. Wider: Gebäudeautomation - der Schlüssel zur Nachhaltigkeit. Zürich: FDM-

Verl., 2013.

[YZM+12] Y. Yang, Q. Zhu, M. Maasoumy, A. Sangiovanni-Vincentelli: Development of

Building Automation and Control Systems. In: IEEE Design & Test of Computers,

vol. 29, no. 4, S. 45–55, 2012.


[ASHRAE Standard 135-2004] ASHRAE Standard 135-2004, ISSN 1041-2336. BACnet

A Data Communication Protocol for Buildung Automation

and Control Networks, 30.06.2006.

147


[BGB §439] BGB. Bürgerliches Gesetzbuch in der Fassung der

Bekanntmachung vom 2. Januar 2002 (BGBl. I S. 42,

2909; 2003 I S. 738), das zuletzt durch Artikel 1 des

Gesetzes vom 20. Juli 2017 (BGBl. I S. 2787) geändert

worden ist.

[Bun02] Standardleistungsbuch für das Bauwesen des

Gemeinsamen Ausschusses Elektronik im Bauwesen,

April 2002.

[DIN EN 62424] DIN EN 62424. Darstellung von Aufgaben der

Prozessleittechnik; Fließbilder und Datenaustausch

zwischen EDV-Werkzeugen zur Fließbilderstellung und

CAE-Systemen, 2010-01.

[DIN 276-1] DIN 276-1. Kosten im Bauwesen, Teil 1: Hochbau,

August 2012.

[DIN EN 15232] DIN EN 15232. Energieeffizienz von Gebäuden- Einfluss

von Gebäudeautomation und Gebäudemanagement,

September 2012.

[DIN EN 81346-Teil 1] DIN EN 81346-Teil 1. Industrielle Systeme, Anlagen und

Ausrüstungen und Industrieprodukte -

Strukturierungsprinzipien und Referenzkennzeichnung -

Teil 1: Allgemeine Regeln, 2010-05.

[DIN EN ISO 16484-1] DIN EN ISO 16484-1. Systeme der Gebäudeautomation

(GA) - Teil 1: Projektplanung und -ausführung, März

2011.

[DIN EN ISO 16484-2] DIN EN ISO 16484-2. Systeme der

Gebäudeautomation, Teil 2: Hardware, März 2006.

[HOAI 2013] HOAI 2013. Verordnung über die Honorare für

Architekten- und Ingenieurleistungen (Honorarordnung

für Architekten und Ingenieure), 2013.

[ISO 16739] ISO 16739, 1. ed., 2013-04-01. Industry Foundation

Classes (IFC) for data sharing in the construction and

facility management industries.

[VDI/VDE-Richtlinie 3681] VDI/VDE-Richtlinie 3681. Einordnung und Bewertung

von Beschreibungsmitteln aus der

Automatisierungstechnik, August 2012.

[VDI/VDE-Richtlinie 3693-1] VDI/VDE-Richtlinie 3693-1. Virtuelle Inbetriebnahme

Modellarten und Glossar, September 2016.

[VDI-Richtlinie 2552 Entwurf] VDI-Richtlinie 2552 Entwurf. Building Information

Modeling, Entwurf Oktober 2017.

[VDI-Richtlinie 3812-1] VDI-Richtlinie 3812-1. Assistenzfunktionen zum

Wohnen, November 2016.

148

Verzeichnis verwendeter Internet-Quellen und erwähnter Software

[VDI-Richtlinie 3813-1] VDI-Richtlinie 3813-1. Gebäudeautomation (GA)

Grundlagen der Raumautomation, August 2012.


Raumtomationsfunktionen, August 2012.

[VDI-Richtlinie 3814-1 Entwurf] VDI-Richtlinie 3814-1 Entwurf. Gebäudeautomation (GA)

Grundlagen Entwurf, Entwurf Juli 2017.


Systemgrundlagen, Mai 2005.

[VOB-B] VOB-B. Vergabe- und Vertragsordnung für

Bauleistungen Teil B: Allgemeine Vertragsbedingungen

für die Ausführung von Bauleistungen, 2016.


[Aut15@] Autodesk: Allgeimeine Struktur der DXF-Dateien (DXF).

https://knowledge.autodesk.com/de/search-

result/caas/CloudHelp/cloudhelp/2016/DEU/AutoCAD-DXF/files/GUID-

D939EA11-0CEC-4636-91A8-756640A031D3-htm.html [Abruf: 2017-07-29]

[Aut17@] Autodesk: What is DWG. https://www.autodesk.com/products/dwg

[Abruf: 2017-07-29]

[Bec18@] Beckhoff Automation GmbH & Co. KG: Beckhoff Building Automation.

https://www.beckhoff.de/building [Stand: 2018-04-04] [Abruf: 2018-04-14]

[BIM17@] BIMiD: Projekt BIMiD. http://www.bimid.de/projekt-bimid [Abruf: 2017-02-24]

[bui16@] buildingSMART International Limited: Industrie Foundation Classes: Version 4

- Addendum 2. http://www.buildingsmart-tech.org/ifc/IFC4/Add2/html/ [Abruf:

2018-04-21]

[bui17@] buildingSMART: International home of openBIM. http://www.buildingsmart.org

[Abruf: 2017-07-29]

[Bun14@] Bundesministerium für Wirtschaft und Energie: Energiewende direkt: Hoher

Energieverbrauch des Gebäudesektors. http://www.bmwi-energiewende.de/

[Abruf: 2017-07-29]

[Bun15b@] Bundesvereinigung Bauwirtschaft: 2015: Gebäudetechnik wächst um 2,5%.

http://www.tga-fachplaner.de/Archiv/News-Archiv/ [Abruf: 2017-02-05]

[Ele17@] ElektraSoft: Projekt AUDRAGA. http://www.elektrasoft.de/forschung-

entwicklung.php [Abruf: 2017-10-31]

[EU 11@] EU Publications Office: SCUBA.

http://cordis.europa.eu/project/rcn/100756_en.html

[Stand: 2017-04-22] [Abruf: 2017-10-31]

[EU 15@] EU Publications Office: TOPAs.

http://cordis.europa.eu/project/rcn/198342_en.html

[Stand: 2017-08-04] [Abruf: 2017-10-31]

149


[FSM17@] J. Fütterer; T. Schild; D. Müller: Gebäudeautomationssysteme in der Praxis:

Whitepaper RWTH-EBC 2017-001. http://dx.doi.org/10.18154/RWTH-2017-

05671 [Abruf: 2017-09-23]

[GaDr11@] A.A. Garcia; R. Drath: AutomationML verbindet Werkzeuge der

Fertigungsplanung- Hintergründe und Ziele.

https://www.automationml.org/o.red/uploads/dateien/1314344567-

automationml_whitepaper.pdf [Abruf: 2017-08-03]

[IAI08@] IAI Industrieallianz für Interoperabilität: Anwenderhandbuch Datenaustausch

BIM/IFC.http://www.dds-cad.de/fileadmin/redaktion/PDF-

Dateien/buildingSMART_Anwenderhandbuch_Version2.0.pdf

[Abruf: 2017-07-30]

[IG 16@] IG Lebenszyklus Bau: Phasen und Modelle. http://www.ig-

lebenszyklus.at/vorgehen/phasen.html [Abruf: 2017-02-05]

[inn17@] innogy SE: SmartHome wird simpel. Energie wird innogy.

https://www.innogy.com/web/cms/de/3105000/fuer-zuhause/bequem-und-

sicher-leben-mit-smarthome/ [Abruf: 2017-09-23]

[iQS13@] iQST GmbH: The Petri net modelling and analysis Tool Pi-Tool: User Guide.

www.iqst.de [Abruf: 2017-09-23]

[iQS14a@] iQST GmbH: SmallCAN. http://www.iqst.de/?page_id=28 [Abruf: 2017-08-03]

[iQS14b@] iQST GmbH: Pi-Tool. http://www.iqst.de/?page_id=24 [Abruf: 2017-08-03]

[Iss17@] Issendorf KG: LCN. http://www.lcn.eu/leistung/das-staerkste-system/

[Stand: 2017] [Abruf: 2018-04-14]

[Kab16@] K. Kabitzsch: Auteras. www.auteras.de [Abruf: 2016-09-29]

[Kab17@] K. Kabitzsch: AUTERAS Tutorial. www.ga-entwurf.de [Abruf: 2017-09-23]

[Kan15@] B. Kantsepolsky: TOPAs. https://www.topas-eeb.eu/ [Abruf: 2017-10-31]

[KNX16a@] KNX Association: Was ist KNX? https://knx.org/knx-de/knx/association/was-ist-

knx/index.php [Abruf: 2016-09-29]

[KNX16b@] KNX Association: KNX vor Ort. http://www.knx.de/knx-de/knx-vor-ort/index.php

[Stand: 2016] [Abruf: 2018-04-14]

[KNX16c@] KNX Association: Was ist ETS? www.knx.org [Abruf: 2016-09-29]

[KNX16d@] KNX Association: Eigenschaften der ETS 5 und Verbesserungen

[Stand: 2016] [Abruf: 2016-09-29]

[KNX17@] KNX Association: KNX Grundlagenwissen.

http://www.knx.org/media/docs/Flyers/KNX-Basics/KNX-Basics_de.pdf [Abruf:

2017-10-22]

[Lie07@] T. Liebich: IFC2x Edition 3 Technical Corrigendum. http://www.buildingsmart-

tech.org/ifc/IFC2x3/TC1/html/index.htm

[Lon17@] LonMark: Sieben Gründe für Lon.

http://www.lonmark.de/fileadmin/templates/pdf/140624_LonMark_7_Gruende-

Fuer_LON.pdf [Abruf: 2017-09-23]

150


[Mer16@] Mervisoft GmbH: TRIC V 7: MSR Software [Abruf: 2016-09-29]

[MPM17@] T. Meudt; M. Pohl; J. Metternich: Die Automatisierungspyramide: Ein

Literaturüberblick. http://tuprints.ulb.tu-darmstadt.de/6298/1/2017 [Abruf: 2017-

10-22]

[Ral12@] Ralitsa Russeva: AutoCAD bei europäischen Architekten die beliebteste CAD-

Software [Abruf: 2017-07-29]

[Sie15@] Siemens Switzerland Ltd Building Technologies Division: Building automation

and control systems: System Catalog 2016.

www.siemens.com/buildingautomation [Stand: 2015]

[Wag16a@] T. Wagner: TOPAs. http://www.inf.tu-

dresden.de/index.php?node_id=3712&ln=de

[Stand: 2016-01-14] [Abruf: 2017-10-31]

[Wag16b@] T. Wagner: AUTEG. http://www.inf.tu-


[Stand: 2016-01-14] [Abruf: 2017-11-02]

[Wag16c@] T. Wagner: AUDRAGA. http://www.inf.tu-


[Stand: 2016-01-14] [Abruf: 2017-10-31]

[Wag16d@] T. Wagner: SCUBA. http://www.inf.tu-


[Stand: 2016-01-14] [Abruf: 2017-10-31]

[WAG18@] WAGO Kontakttechnik GmbH & Co. KG: WAGO Gebäudetechnik.

https://www.wago.com/de/gebaeudetechnik [Abruf: 2018-04-14]

[WUK+14@] P. Waide, et al.: The scope for energy and CO2 savings in the EU through the

use of building automation technology.

http://www.buildup.eu/en/practices/publications/building-automation-scope-

energy-and-co2-savings-eu

[Zen17@] Zentralverband Elektrotechnik- und Elektronikindustrie e.V.: DALI.

http://www.dali-ag.org/ [Abruf: 2017-10-29]

[Zig17@] Zigbee Alliance: What is Zigbee. http://www.zigbee.org/what-is-zigbee/

[Abruf: 2017-09-23]

151

Verzeichnis der Veröffentlichungen des Verfassers

Verzeichnis der Veröffentlichungen des Verfassers

[GDS+16A] M. Günther, P. Diekhake, A. Scholz, D. Diaz, P. Puntel Schmidt, U. Becker, A.

Fay: Unterstützung bei der Planung und Auslegung einer Gebäudeautomation.

In: Automation 2016. Baden Baden, 2016.

[GDS+16B] M. Günther, P. Diekhake, A. Scholz, P. Puntel Schmidt, U. Becker, A. Fay:

Durchgängiges modellbasiertes Engineering von

Gebäudeautomationssystemen: Von der Anforderung über die Simulation zur

Installation. at - Automatisierungstechnik, Vol. 64 (6), 2016, S. 490–499.

[GSP+16A] M. Günther, A. Scholz, P. Puntel Schmidt, P. Diekhake, D. Diaz, A. Fay:

Anforderungserhebung und -modellierung in der Gebäudeautomation. In:

Entwurf komplexer Automatisierungssysteme (EKA). Magdeburg, 2016.

[GSP+16B] M. Günther, A. Scholz, P. Puntel Schmidt, A. Fay, P. Diekhake, D. Diaz, U.

Becker: Requirements engineering and modelling for Building automation

systems. In: IEEE 21th International Conference on Emerging Technologies &

Factory Automation (ETFA). Berlin, 2016.

[DBD+16] D.E. Diaz, U. Becker, P. Diekhake, M. Günther, A. Scholz, P.P. Schmidt, A.

Fay: Evaluation and simulation of building automation systems based on their

AutomationML description. In: IEEE 21th International Conference on

Emerging Technologies & Factory Automation (ETFA). Berlin, 2016.

[DDB+16] P. Diekhake, D. Diaz, U. Becker, M. Günther, A. Scholz, P. Puntel Schmidt, A.

Fay: Bewertung verteilter Gebäudeautomatisierungssysteme auf Basis ihrer

Beschreibung mittels AutomationML und ihrer Simulation unter Anwendung

automatisiert erzeugter Petrinetze. In: Entwurf komplexer

Automatisierungssysteme (EKA). Magdeburg, 2016.

Verzeichnis der betreuten studentischen Arbeiten

[Phr16] C. Phrompradit: Analyse und Implementierung von Gebäudedaten zur

automatischen Struktursegmentierung. Magdeburg, Hochschule Magdeburg-

Stendal, Institut für Elektrotechnik, Februar 2016.

152

Lebenslauf

Lebenslauf

Michelle Günther

geboren am 19.11.1985 in Bergedorf

Allgemeine Hochschulreife: Gymnasium der Stadt Hückelhoven Juni 2005, Note 2,4

Beruflicher Werdegang:

07/2005 – 09/2006 Eintritt in die Bundeswehr, Grundausbildung und Offizierausbildung

09/2006 – 09/2009 Studium Luft- und Raumfahrttechnik,

Universität der Bundeswehr München,

Vertiefungsrichtung: Technik Autonomer Systeme

Abschluss: Diplom, Gesamtnote 2,16

10/2009 – 05/2013 Luftfahrzeugtechnischer Offizier Wartungsstaffel,

Jagdbombergeschwader 31 „Boelcke“, Nörvenich

05/2013 – 06/2014 Leiter Einsatzsteuerung,

Taktische Luftwaffengruppe 71 „Richthofen“, Wittmund

06/2014 – 06/2016 Mitarbeiterin,

Helmut-Schmidt-Universität/ Universität der Bundeswehr Hamburg

seit 07/2016 Einsatzoffizier Prozessmanagement und Controlling,

Kommando Luftwaffe, Köln

Documents

Durchgängiges und modellbasiertes Engineering von ......Durchgängiges und modellbasiertes Engineering von Gebäudeautomationssystemen Von der Fakultät für Maschinenbau der Helmut-Schmidt-Universität