Zurück

Inhalte

Bewertungssystem Nachhaltiges Bauen - Konzeptentwicklung für ein EDV-gestütztes Bewertungs- und Dokumentationsinstrument (eBNB)

Projektbeschreibung

Projektbeteiligte

Eckdaten

Bewertungssystem Nachhaltiges Bauen - Konzeptentwicklung für ein EDV-gestütztes Bewertungs- und Dokumentationsinstrument (eBNB)


Projektnummer
Projektbeginn
09.2012
Projektende
02.2013
Projektstatus
abgeschlossen ohne Bericht

Ziel des Forschungsprojekts war die Erstellung eines Grobkonzepts für ein EDV-gestütztes internet- oder intranetbasiertes Bewertungs- und Dokumentationsinstrument (eBNB). Mit dem eBNB soll eine Vereinheitlichung und Vereinfachung der planungs- und baubegleitenden Anwendung des Bewertungssystems Nachhaltiges Bauen (BNB) erreicht werden.Projektlaufzeit: September 2012 - Februar 2013

Ausgangslage

Das vom BMVBS eingeführte "Bewertungssystem Nachhaltiges Bauen (BNB)" ist ein ganzheitliches quantitatives Bewertungsverfahren für die Nachhaltigkeit von Bauvorhaben. Es arbeitet aktuell auf der Basis von MS-Word- und MS-Excel-Dateien und besteht aus einer Vielzahl von IT-Modulen. Informationen müssen über diese Dateien mehrmals manuell erfasst und ausgewertet werden. Eine prozessbegleitende Nachhaltigkeitsbewertung ist damit aufwendig und fehleranfällig.

Zielstellung

Mit dem eBNB soll ein neues EDV-gestütztes Bewertungs- und Dokumentationsinstrument geschaffen werden. Es soll sowohl die Qualitätsbewertung und -dokumentation als auch die Steuerung der Zielfindungs-, Planungs-, Bau-, Inbetriebnahme- und Nutzungsprozesse unterstützen. Mit dem Bewertungsinstrument soll ein prozessbegleitendes Controlling möglich sein. Hierzu wird eine Abschätzung und Berechnung von Zwischenergebnissen der BNB-Bewertung in verschiedenen Phasen (z.B. ES-Bau), in Bereichen (Teilkriterien) und Teilprojekten (BNB-Module) möglich sein. Folgende Aufgaben sollen lösbar sein:

  • Bewertung von Gebäuden und Außenanlagen nach BNB
  • Festlegung von Qualitätszielen und Verfolgung des Zielerreichungsgrades
  • Integration der BNB-Dokumentation und -Nachweisführung in den Informationsfluss der Bundesbauverwaltung
  • Vergleich von Bewertungsergebnissen auf Phasen-, Bereichs- und Teilprojektebene
  • Verwaltung bewerteter Projekte in einer Datenbank
  • Generierung von Kennwerten für Folgeprojekte und die BNB-Systementwicklung

Auftragnehmer war die Hitabis GmbH in Zusammenarbeit mit der Steinbeis-Hochschule-Berlin GmbH.

Konzept

Zu Projektbeginn erfolgte die Erhebung von baufachlichen und EDV-technischen Anforderungen an das geplante Dokumentations- und Bewertungsinstrument. Zu diesem Arbeitspaket wurden erfahrene Bauchfachleute und IT-Spezialisten als Begleitkreis hinzugezogen. In Vorbereitung auf die Workshops wurden Materialien und Präsentationen als Basis für die fachlichen Diskussionen verfasst.

Die Workshops fanden mit folgenden Schwerpunkten statt:

  • Workshop 1: Anforderungserhebung
  • Workshop 2: Anforderungskonsolidierung, EDV-technische Architekturentwürfe
  • Workshop 3: EDV-technische Grobkonzepte und Prototyp

Eine zentrale Rolle in den Workshops spielte die korrekte Definition von Fachbegriffen, die für ein einheitliches Verständnis der Spezialisten verschiedener Fachrichtungen Voraussetzung für eine gemeinsame Fachdiskussion war. Im Ergebnis der Projektarbeit wurden im Wesentlichen die folgenden eBNB-relevanten Begriffe definiert:

  • eBNB-Bewertungsinstrument bestehend aus eBNB-Frontend und eBNB-Backend
  • BNB-Systemvariante, BNB-Modul
  • Intelligentes Formular, z.B. Steckbriefe und RBBau-Muster
  • eBNB-Metamodell, Versionen von eBNB-Metamodellen
  • Bauprojekt, Varianten vom Bauprojekt, Phasenabschluss des Bauprojekts
  • Eingangsdaten, Bewertungsergebnisse, Nachweisdokumente

Die Definitionen der Begriffe sind in das Anforderungsdokument und in die EDV-technischen Grobkonzeptionen eingeflossen.

Von der Steinbeis-Hochschule-Berlin (SHB) wurde im Rahmen der Workshops ein formalisiertes Metamodell des BNB-Moduls "Neubau" der BNB-Systemvariante "Büro- und Verwaltungsgebäude" vorgelegt. Das Metamodell spiegelt die entsprechenden Kriteriensteckbriefe und zugehörigen Eingangs- und Ergebnisdaten wider. Außerdem wurde ein Excel-basierter Prototyp für das BNB-Bewertungssystem für das BNB-Modul "Neubau" der BNB-Systemvariante "Büro- und Verwaltungsgebäude" entwickelt und ein Mustergebäude damit exemplarisch bewertet.

Zudem wurden verschiedene IT-Architekturen unter Berücksichtigung der vorhandenen IT-Infrastruktur im BBR diskutiert. Folgende Ansätze wurden geprüft:

  • Vollständige Online-Lösung mit BBR-Backend, zwischengeschalteter DMZ (Demilitarized Zone) und Online-Clients im Internet
  • Vollständige Offline-Lösung mit BBR-Backend und autonomen Frontends, die auf Excel oder einer lokalen Datenbank basieren
  • Mischvarianten aus Offline- und Online-Lösung

Im Rahmen der Anforderungserhebung wurde außerdem gewünscht, dass Datenverwaltung, Benutzeroberflächen und BNB-Regelwerk weitgehend dynamisch konfigurierbar umgesetzt werden, damit Änderungen an den Daten oder dem Regelwerk ohne Softwareänderung ausgeführt werden können. Der Wunsch nach einer voll flexiblen Lösung führte zur weiteren Differenzierung zwischen statischen und dynamischen Implementierungsvarianten, die sich hinsichtlich der Implementierungskosten erheblich unterscheiden.

Während der Architekturuntersuchungen kristallisierten sich die folgenden Komponenten heraus, die innerhalb der EDV-technischen Konzeptionen betrachtet und bewertet wurden:

  • Backend mit Oracle-Datenbank und lokalen Administrationsmasken
  • Frontend: Bedienoberflächen zum Erfassen von Daten und Anzeigen von Ergebnissen
  • DMZ (Demilitarized Zone): Schutzbereich zwischen Internet und Backend bei Online-Lösungen

Ergebnisse

EDV-technische Lösungsansätze

Für die EDV-technischen Konzeptionen wurden folgenden Daten- und Benutzermengen abgeschätzt:

  • Für ca. 50 Bauprojekte mit mittlerer Laufzeit von 15 Jahren und einer Aufbewahrungsdauer von 30 Jahren nach Projektabschluss müssen ca. 450 Gigabyte Daten im eBNB-Backend permanent verwaltet werden.
  • Unter den genannten Annahmen ist mit 100 bis 500 Benutzern zu rechnen, davon ca. 10 bis 50 Benutzer, die gleichzeitig konkurrierend auf das eBNB zugreifen.
  • Grundsätzlich wurde das eBNB-Bewertungsinstrument in zwei Subsysteme gegliedert: das eBNB-Backend und das eBNB-Frontend.
  • Das eBNB-Backend umfasst die zentrale Ablage der Bewertungsdaten und bildet damit die Grundlage für die Auswertungen dieser Daten durch wissenschaftliche Mitarbeiter der BNB-Systempflege. Weiterhin werden im Backend die Bewertungsgrundlagen und -regeln abgelegt und gepflegt. Das eBNB-Backend umfasst die folgenden Komponenten:
  • eBNB-Datenbank mit Projektdaten
  • eBNB-Datenbank mit Parameter- und Regeldaten aus den intelligenten Formularen (Regel-Repository)
  • Applikationsserver für den Betrieb der Anwendungen
  • Arbeitsplätze für wissenschaftliche Mitarbeiter
  • Arbeitsplätze für Systemadministratoren

Bei der Pflege des Regel-Repository kann zwischen statisch und dynamisch hinterlegten Regeln unterschieden werden. In der statischen Variante werden bei Regeländerungen Eingriffe in den Programmcode nötig, bei dynamischer bzw. generischer Regelverwaltung sind im Allgemeinen nur Anpassungen an Konfigurationsdaten nötig. Die statische Variante ist deutlich einfacher und kostengünstiger zu implementieren.

Das eBNB-Frontend stellt alle Funktionen für die dezentralen Endbenutzer des eBNB-Bewertungsinstrumentes zur Verfügung, die für die Erfassung, Pflege und Prüfung von Daten zu Bauprojekten verantwortlich sind. Für das Frontend gibt es verschiedene Lösungsansätze, wobei die Online-Lösungen wie beim Backend jeweils als statische oder dynamische (generisch konfigurierbaren) Varianten implementiert werden können. Folgende Ansätze wurden geprüft:

1. Konsequente

Das eBNB-Frontend wird als Internet-Lösung angelegt, d.h. die Frontend-Software wird auf einem Applikationsserver betrieben und alle Benutzer greifen über einen Web-Browser auf diese Software zu. Die gesamte für das Frontend relevante Geschäftslogik, von der Erfassung und Pflege der Projektdaten über Plausibilitätsprüfungen bis hin zur Phasenbildung sowie zu Nachhaltigkeitsbewertung und -prüfung läuft zentral auf dem Applikationsserver. Die Online-Lösung setzt einen permanenten Zugriff auf das Internet voraus.

2. Online-Lösung mit temporärer Offline-Datenerfassung

Diese Variante ist als Erweiterung gegenüber der konsequenten Online-Lösung anzusehen. Sie setzt die zusätzliche Anforderung um, dass Arbeitsplätze im Frontend unter Umständen keinen permanenten Internetzugang haben. Grundsätzlich sind alle Arbeitsplätze allerdings in der Lage, zeitweise (z.B. im Büro) auf das Internet zuzugreifen. Bei bestehender Internetverbindung wird auf Software und Daten des eBNB-Backends zugegriffen.

3. Insellösung

Im Gegensatz zum zentralen Backend wird in dieser Variante das eBNB-Bewertungsinstrument isoliert betrieben. Dies kann aus folgenden Gründen sinnvoll sein:

  • Vorgaben der IT-Sicherheit lassen keine Anbindung über Internet zu.
  • Objektive Beschränkungen der IT-Infrastruktur verhindern einen zentralen Datenaustausch.
  • Das eBNB-Bewertungsinstrument wird als Kernsystem für BNB-ähnliche Aufgabenstellungen eingesetzt.

Die Insellösung wird isoliert in einem LAN betrieben. Deshalb können die Maßnahmen zur Gewährleistung der Sicherheit im Internet entfallen. In dieser Variante sind optionale Schnittstellen zum Offline-Datenaustausch mit der Bewertungsdatenbank und dem Regel-Repository des zentralen eBNB-Bewertungsinstrumentes beim BBR vorzusehen.

4.

Das eBNB-Frontend wird hier als lokale Excel-Anwendung auf jedem beteiligten Arbeitsplatz betrieben. Der Datenaustausch zwischen Frontend-Rechnern und dem Backend erfolgt über Dateien, die per E-Mail oder Datenträger ausgetauscht werden. Die Excel-Dateien können auf der Grundlage des vorhandenen BNB-Prototyps entwickelt und vom BBSR z.B. über das Internetportal www.nachhaltigesbauen.de zur Verfügung gestellt werden. Die Benutzergruppen im Frontend können die Daten eines Projektes in genau einer Excel-Datei erfassen und mit dieser Datei auch eine Nachhaltigkeitsbewertung lokal im Excel vornehmen.

5. Offline-Lösung auf Basis einer lokalen Datenbank

Das Frontend setzt dabei auf einer lokalen Desktop-Datenbank auf. In dieser Datenbank werden die Strukturen zur Erfassung der Projektdaten, die Daten des Metamodells sowie die Masken zur Datenerfassung und -pflege hinterlegt. Die Datenbank wird vom BBSR gepflegt und bereitgestellt. Auch bei dieser Lösung gilt, dass die Daten eines Projektes jeweils in genau einer lokalen Datenbank erfasst und gepflegt werden können. Der Datenaustausch mit dem Backend erfolgt über XML-Export der Projektdaten im Frontend und Import der XML-Dateien im Backend.

Die dritte Komponente eBNB-DMZ wird benötigt, um bei den Lösungen mit Internet-basierten Frontends (1 und 2) das Backend vor direkten Internetzugriffen zu schützen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt dafür in seinen IT-Grundschutzhandbüchern ein Konzept bestehend aus einer inneren und einer äußeren Firewall. Innerhalb der DMZ wird in diesem Fall ein Applikationsserver betrieben auf dem die Software für die Frontend-Arbeitsplätze bereitgestellt wird. Außerdem befindet sich in der DMZ eine Datenbank für die Zwischenablage der Projektdaten und des Regel-Repository. Die Objekte in der DMZ-Datenbank können weitgehend mit den Objekten der Datenbank und im Backend übereinstimmen. Datenbankinhalte, die sich aus dem Metamodell ergeben, werden im Backend gepflegt und von dort aus in der DMZ bereitgestellt. Die Bauprojektdaten werden von den Frontend-Arbeitsplätzen an die DMZ-Datenbank geliefert und durch das Backend aus der DMZ übernommen.

Die genannten Komponenten können wie folgt geordnet werden:

Komponente

Variante

Beschreibung

1 Backend

1a

Backend statisch - mit Regel-Repository, ohne Möglichkeit zur Entgegennahme von Projektdaten, statische Masken und Regeln, keine Pflege der Regeln über APEX

1b

Backend dynamisch - mit Regel-Repository, ohne Möglichkeit zur Entgegennahme von Projektdaten, dynamische Masken und Regeln und APEX

2 Online-Frontend

2a

Online-Frontend statisch, LAN - für Eingabe der Projektdaten mit direkter Netzverbindung zum Backend (lokales Netz ohne DMZ), BNB-Berechnungen über Backend

2b

Online-Frontend statisch, WWW - für Eingabe der Projektdaten mit Internetverbindung zum Backend abgesichert über DMZ, BNB-Berechnungen über Backend

2c

Online-Frontend dynamisch, WWW - für Eingabe der Projektdaten mit Internetverbindung zum Backend abgesichert über DMZ, BNB-Berechnungen über Backend, dynamische Masken und Regeln

3 Offline-Excel-Frontent

3

Offline-Frontend XLS - für Eingabe der Projektdaten dient der angepasste Prototyp (Excel), Import ins Backend über Upload-Masken, BNB-Berechnung im Frontend und Backend

4 Offline-Frontend mit lokaler DB

4

Offline-Frontend DB - für Eingabe der Projektdaten dient eine neue Anwendung mit lokaler Datenbank, Import ins Backend über Upload-Masken, BNB-Berechnung im Frontend und Backend

Bewertung der EDV-Konzepte

Auf Basis der genannten Komponenten wurden die folgenden sinnvollen Lösungskombinationen zusammengestellt und anhand der Anforderungen und Kosten bewertet:

1a+2a 

statisches Backend online im LAN (minimale Netzwerk-Lösung)

1a+2a+3

statisches Backend online im LAN, Zulieferung von Excel-Dateien

1a+2a+4

statisches Backend online im LAN, Zulieferung von XML aus lokaler DB

1b+2c

dynamisch Backend online im Web über DMZ, dynamische Browser-Masken

1a+2b

statisches Backend online im Web über DMZ, statische Browser-Masken

1a+3

statisches Backend, keine Projektmasken, Zulieferung von Excel-Dateien

1a+4

statisches Backend, keine Projektmasken, XML-Dateien aus lokaler DB

Erfüllte eine Kombination nicht alle Muss-Anforderungen aus den Expertenworkshops, so wurde sie von der weiteren Betrachtung ausgeschlossen. Damit fielen die Varianten 1a+2a sowie 1a+3 aus der weiteren Betrachtung heraus.

Die restlichen Implementierungsvarianten wurden nach folgenden Kriterien bewertet:

  • Portabilität
  • Skalierbarkeit
  • Zukunftssicherheit
  • Funktionalität
  • Zuverlässigkeit
  • Benutzbarkeit
  • Effizienz
  • Wartbarkeit
  • Übertragbarkeit
  • Sicherheit
  • Investitionskosten und Nutzungskosten

Bezüglich der zu erwartenden Implementierungskosten wurde die teuerste Lösung mit 0 Punkten wertet, die preiswerteste Lösung erhielt die Höchstpunktzahl. Insgesamt ergab sich damit die folgende Rangfolge:

1. 1a + 2b (74,6 Punkte)
2. 1a + 4 (73,4 Punkte)
3. 1b + 2c (70,3 Punkte, abgewertet wegen sehr hoher Kosten)

Empfehlungen zur Implementierung

Anhand der Bewertung der Anforderungen unter Berücksichtigung der geschätzten Implementierungskosten wird empfohlen, die Kombination aus statischem Backend, einer DMZ zum Schutz des Backend vor unbefugten Zugriffen aus dem Internet und Web-Masken zum Zugriff auf die eBNB-Daten (1a + 2b) zu implementieren.

Diese Lösung ist offen für zukünftige Weiterentwicklungen und für XML-Schnittstellen zu anderen baufachlichen IT-Systemen (z.B. LAGUNO, PLAKODA). Sie wird Planer und Architekten bei der frühzeitigen Bewertung von Bauprojekten in den verschiedenen Phasen unterstützen und ihnen unter anderem die Mehrfacheingabe von Basisdaten ersparen. Mit dem eBNB erarbeiten sich die Projektmitarbeiter parallel zum Projektfortschritt eine zentrale, sichere und elektronisch auswertbare Dokumentation des Bauprojekts inklusive Varianten und Phasenabschlüsse.

Die Online-Variante benötigt für die Bearbeitung von Eingangsdaten und die Berechnung von Bewertungen durch Baufachleute einen Internetzugriff. Diese Anforderung ist gegenwärtig fast überall in Deutschland erfüllt und stellt somit keine Einschränkung für das Projekt dar.

Für die wissenschaftlichen Mitarbeiter des BBR/BBSR besteht mit dem internetbasierten eBNB die Möglichkeit, Auswertungen über laufende und abgeschlossene Projekte durchzuführen. Über APEX-Masken können durch erfahrene Mitarbeiter eigene Auswertungen konfiguriert werden.

Projektbeteiligte
Eckdaten
Schlagworte zum Projekt : Nachhaltiges Bauen, BNB, EDV, eBNB
Projekt auf der Webseite des BBSR : https://www.bbsr.bund.de/BBSR/DE/forschung/programme/zb/Auftragsforschung/2NachhaltigesBauenBauqualitaet/2012/eBNBKonzept/01_start