Referenz

Diplomarbeit

Thema:

Aufnahme des Baufortschritts in verteilter Umgebung

Bearbeiter:

Stefan Schweigel

Prüfer:

Jun. Prof. Dr.-Ing. Berthold Firmenich


Prof. Dr.-Ing. Karl Beucke

Betreuer:

Dipl.-Ing. Daniel G. Beer


Dipl.-Ing. Hermann Kreutzjans, HOCHTIEF Construction AG


Dipl.-Ing. Ulrich Hartmann, Nemetschek AG

Fach:

CAD in der Bauinformatik

Bearbeitungszeitraum:

14.06.2004 – 14.09.2004

Download:

Diplomarbeit S.Schweigel (PDF; 1,90Mb)

Zusammenfassung

Als Folge des hohen Termindrucks während des Bauablaufes, ist es besonders wichtig den Fortschritt eines Bauvorhabens zeitnah zu überwachen. Auf Großbaustellen kann die effektive Kontrolle nicht mehr ohne technische Hilfsmittel durchgeführt werden. Die Arbeit stellt verschiedene Szenarien für die verteilte Fortschrittserfassung vor und untersucht welche Anforderungen an ein System für die verteilte Erfassung gestellt werden. Dazu wird zuerst das bestehende CVS-System analysiert, um anschließend daraus ein Konzept für die Versionierung von Objekten und den automatischen Abgleich von Objektversionen zu entwickeln. Später wird gezeigt, wie dieses Konzept mit Hilfe von C# und dem Microsoft®-.NET-Framework umgesetzt werden kann.

Das Baufortschrittsmodell

Für einen optimierten Bauablauf und Ressourceneinsatz werden heutzutage sehr detaillierte Terminpläne aufgestellt. Da aber Vorgänge auf realen Baustellen nie exakt, wie auf dem Papier geplant, durchgeführt werden können und häufig unvorhergesehene Situationen eintreten, müssen diese kontrolliert werden, um rechtzeitig feststellen zu können, ob der Bau bereits im Verzug ist.

Auf kleineren Baustellen kann natürlich ein erfahrener Bauleiter erkennen, ob das Vorhaben zu dem vorgegebenen Zeitpunkt fertig gestellt wird. Jedoch auf Großbaustellen, z.B. Flughäfen, Autobahnbaustellen oder Industrieanlagen, kann die effektive Kontrolle nicht mehr ohne technische Hilfsmittel durchgeführt werden, da sonst schnell der Gesamtüberblick verloren geht. Zur zeitnahen Erzeugung einer Übersicht müssen dazu die Fortschrittsaufnahmen einzelner Benutzer an zentraler Stelle zusammengefügt werden.

algemeine Struktur der Terminplanung

Vereinfachend kann das System in drei Bereiche aufgeteilt werden:

  1. Das Terminplanungssystem, mit dem schon existierenden Terminplan. Es könnte sich hier beispielsweise um Microsoft® Project™ oder Asta® Powerproject™ handeln.

  2. Das Projekt, hierein werden die zu kontrollierenden Soll-Werte der Terminplanung importiert. Das Projekt enthält die Datenstrukturen und liegt an zentraler Stelle. Bei Bedarf werden die aktuell ermittelten Ist-Werte wieder in das Terminplanungssystem geschrieben.

  3. Der Arbeitsbereich des Benutzers: hier lädt ein Benutzer das Projekt, bearbeitet seine Daten und speichert diese wieder zurück in das Projekt.

Das Projekt besteht im wesentlichen aus einer Vorgangsmenge V, die aus dem Terminplanungssystem importiert wurde, aus einer Bauteilmenge B, die in Verbindung mit einer Konstruktionszeichnung des zu kontrollierenden Baus stehen kann, und eine Relation R, als Teilmenge aller möglichen Beziehungen zwischen V und B. An einem Relationselement hängen: ein Wichtungsfaktor w, ein Fortschrittswert f und eine Historie Gr, in der alle zu bestimmten Zeitpunkten aufgenommenen Wichtungen und Fortschrittswerte für die spätere Auswertung gespeichert werden.

Schema des Baufortschrittsmodells

Die Aufgabe eines Projektmanagers ist es nun, die Baumstruktur mit den Bauteilen zu erstellen, die Elemente der Relation zwischen den Vorgängen und Bauteilen herzustellen und diese mit Wichtungsfaktoren zu bewerten. Der Wichtungsfaktor soll dabei den Schwierigkeitsgrad bei der Durchführung eines bestimmten Vorganges an einem Bauteil bewerten.

Auf der Baustelle gibt dann ein Bearbeiter in regelmäßigen Intervallen den Baufortschritt ein. Später im Büro kann dann für jeden Vorgang, aus den zugehörigen Relationselementen zu den Bauteilen, eine Fortschrittskurve für den Soll-Ist-Vergleich generiert werden.

Terminplan mit Soll-Ist-Kurve

Das Versionsverwaltungssystem

Ganz Allgemein gibt es für die verteilte Erfassung mit mehreren Bearbeitern zwei prinzipielle Möglichkeiten der Umsetzung:

  1. alle Benutzer arbeiten gemeinsam auf einer Datenbasis,

  2. die Benutzer arbeiten getrennt auf ihrer lokalen Kopie der Datenbasis.

Das entwickelte System folgt dem Prinzip der „lokalen Kopie der Datenbasis“, funktioniert auf Objektebene und ist offen, um eventuell in ein anderes System integriert werden zu können. Folgende Komponenten charakterisieren das System: an zentraler Stelle, auf einem Server liegt ein Objektspeicher, in diesem werden alle Versionen aller versionierten Objekte, gespeichert. Auf diesen Speicher kann ein Versionsverwaltungssystem zugreifen, das auf dem Client-Computer liegt. Dieses System enthält einen Objekt-Pool in den das Erfassungsprogramm alle zu versionierenden Objekte legen muss, dort werden die einzelnen Objekte mit den Verwaltungsinformationen in einem Container abgelegt. Danach kann das Versionsverwaltungssystem veranlasst werden, einen Abgleich mit den Objekten, die auf dem Server liegen, durchzuführen. Nach erfolgreichem Abgleich muss dann das Erfassungsprogramm alle Objekte aus dem Pool laden und intern miteinander verknüpfen.

Schema des Versionsverwaltungssystems

Zuerst muss geklärt werden, was überhaupt ein zu versionierendes Objekt ist. Das heißt, welche Objekte sieht man im Programm als atomar an; also Objekte oder Objektstrukturen, die für sich eine Einheit bilden und nicht mehr sinnvoll in kleinere Strukturen aufgelöst werden können. Beim Speichern eines atomaren Objekts in den Objektspeicher, bekommt jedes einen eindeutigen persistenten Identifikator zugeordnet. Außerdem darf das Objekt keine Referenzen zu anderen atomaren Objekten besitzen, das heißt, beim Laden muss es für sich alleine existieren können. Alle Referenzen müssen vorher aufgelöst werden, indem einfach der persistente Identifikator eines anderen atomaren Objekts, intern gespeichert wird. Bei Bedarf muss das atomare Objekt die Referenz wieder herstellen können.

Es können somit fünf allgemeingültige Operationen identifiziert werden: Objekt neu erstellen, Objekt löschen, Inhalt des Objekts ändern, „nichts tun“ und Objekt nicht vorhanden. Andere Operationen sind nicht möglich, falls alle Referenzen der atomaren Objekte im Versionierungssystem korrekt aufgelöst wurden.

Abgleichmatrix

Diese elementaren Operationen können sowie serverseitig, als auch clientseitig durchgeführt werden. Um den Abgleich durchführen zu können, muss nun eine Aktion ermittelt werden, damit die Objekte auf dem Server und dem lokalen System den gleichen Inhalt bekommen. Die richtige Aktion kann ermittelt werden, indem alle Operationen in einer Matrix kombiniert werden. Dabei auftretende Konflikte werden automatisch vom System durch Regeln gelöst. Sollte keine Regel zutreffen, dann muss der Benutzer den Konflikt per Hand lösen.

Umsetzung

Als Programmiersprache für die Umsetzung wurde C# (lies: c-sharp) und das Microsoft® .NET-Framework (lies: dot net) verwendet.

Das Erfassungssystem besteht aus fünf Teilen, zwei davon sind Programme, das Erfassungsprogramm und der Versionsverwaltungsserver (Objekt-CVS-Server), die anderen drei Module sind Programmbiblioteken, dies wären: das Baufortschrittsmodell, das Versionsverwaltungssystem und eine Web-Anwendung zur Fortschrittserfassung.

Bild mit Programmaufbau

Das Erfassungsprogramm auf dem lokalen Client-Computer benutzt das Baufortschrittsmodell und das Versionsverwaltungssystem. Der Client-Computer hat die Möglichkeit sich mit dem Server-Computer, via Internet oder Netzwerk, zu verbinden.

Auf dem Server-Computer muss der Objekt-CVS-Server gestartet werden, dieser benutzt auch das Versionsverwaltungs-Modul, aber nur einen Teil davon, nämlich den Objektspeicher. Die Daten des Speichers werden lokal auf dem Server abgelegt. Das Versionsverwaltungsmodul des Client-Computers hat die Möglichkeit auf den Objektspeicher des Servers über die Netzwerkverbindung zuzugreifen.

Screenshot Webanwendung

Das dritte Programm, die Web-Anwendung, ist nicht durch den Benutzer startbar, sondern läuft im Kontext des IIS (Microsoft Internet Information Server). Diese ASP-.NET-Anwendung erzeugt dynamisch HTML-Code, anstatt eine grafische Nutzeroberfläche auf dem Bildschirm auszugeben. Somit wird es möglich, dass potentielle Benutzer des Fortschrittserfassungssystems nur einen Web-Browser zur Aufnahme neuer Werte benötigen. Die Benutzer müssen keine zusätzlichen Programme installieren, in Folge dessen kann die Aufnahme auch mit minimalen Hardwarevoraussetzungen durchgeführt werden, da die gesamte Anwendungslogik auf dem Webserver liegt.

Die Web-Anwendung kann auch als eine andere Form des verteilten Arbeitens angesehen werden. Der Webserver (IIS) erstellt für jeden Benutzer einen privaten Arbeitsbereich. Die Benutzer können nicht gegenseitig auf ihre Ressourcen zugreifen.

Beide Anwendungen, die Windows- und Web-Anwendung, benutzen das gleiche Objektmodell. Der Unterschied zwischen Beiden besteht lediglich in der unterschiedlichen Visualisierung der Daten, da sich das Programmiermodell von WinForms- und ASP-.NET-Anwendungen unterscheidet. Ein Nachteil der Web-Anwendung besteht darin, dass die Benutzer immer mit dem Webserver verbunden sein müssen, da für jede ausgeführte Aktion eine neue HTML-Seite generiert wird. Außerdem werden die Ressourcen des Benutzers nicht dauerhaft aufbewahrt, stattdessen werden sie nach längerer Inaktivität des Benutzers wieder freigegeben.

Screenshot Windowsanwendung

Die Programme enthalten keinerlei Logik des Baufortschrittsmodells und der Versionsverwaltung. Hier wird alleinig das Baufortschrittsmodell visualisiert und die Änderungen durch die Benutzer werden wieder zurück in das Modell übertragen.

Verbindung über das Netzwerk

Das Kommunizieren über verschiedene Systemgrenzen hinweg ist eine vielschichtige Problematik. Das .NET-Framework bietet aber mit der .NET-Remoting-Technologie einen einfachen Ansatz zur prozessübergreifenden Kommunikation.

Zur Erstellung einer verteilten Anwendung werden drei Dinge benötigt:

  1. ein remotefähiges Objekt,

  2. eine Host-Anwendung, die das Objekt verwaltet und

  3. eine Client-Anwendung, die das Objekt benutzen möchte.

Das remotefähige Objekt ist dabei die Kommunikationsschnittstelle zwischen Client und Server. Auf der Client-Seite wird das Objekt benutzt, als wäre es ein normales Objekt. Die .NET-Remoting-Infrastruktur kopiert automatisch den Objektinhalt zwischen den beiden Domänen hin und her oder ruft eine entfernte Methode des Objekts auf dem Server auf, wenn diese Methode auf dem Proxy-Objekt des Clients aufgerufen wird.

Mit der Hilfe von .NET-Remoting ist es im Vergleich zu älteren Techniken, wie zum Beispiel mit CORBA, sehr einfach möglich, hochgradig verteilte Anwendungen zu entwickeln.

 

 

(c) 2004 by S.Schweigel