Entwicklung einer generischen Kommunikationsplattform

INSTITUT FÜR BAUBETRIEB, BAUWIRTSCHAFT UND BAUMANAGEMENT
Baufakultät (Bauingenieurwesen und Architektur)
Vorstand: Univ. Prof. Dipl.-Ing. Dr.techn. Arnold Tautschnig
Technikerstrasse 13
A – 6020 Innsbruck
http://baubetrieb.uibk.ac.at
Bereich Baumanagement
Tel.: (+43 512) 507 - 6521
Fax: (+43 512) 507 - 2991
email: baubetrieb@uibk.ac.at
PUBLIKATION
A.Tautschnig, R.Feik, A.Blindow, M.Leitner
ENTWICKLUNG EINER GENERISCHEN
KOMMUNIKATIONSPLATTFORM
Seminarband ICC4 des i3b
Univ.-Ass. Dipl.-Ing. Roland Feik ● Tel: (+43 512) 507 6530 ● Fax: (+43 512) 507 2991 ● Email: Roland.Feik@uibk.ac.at

Entwicklung einer generischen Kommunikationsplattform
Forschungsprojekt, gefördert vom FFF (Forschungsförderungsfonds der
gewerblichen Wirtschaft), bearbeitet durch Blindow&Partner Consulting
GmbH, Innsbruck (BPC) und dem Institut für Baubetrieb, Bauwirtschaft
und Baumanagement, Universität Innsbruck (i3b)
Abstract
Durch die Entwicklungspartner BPC und i3b wurde ein Tool entwickelt, das es ermöglicht,
einen systematisierten Dokumentenaustausch zwischen verschiedenen
Dokumentenmanagementsystemen und/oder Kommunikationsplattformen durchzuführen.
Das Tool wird als „generische Kommunikationsplattform (GKP)“ bezeichnet.
Die Anwendung ist auch nicht auf Großprojekte beschränkt sondern kann überall dort
eingesetzt werden, wo verschiedene Projektpartner unterschiedliche elektronische
Dokumentenmanagementsysteme (DMS) bei einem Projekt verwenden.
1. Systembeschreibung
1.1. Technische Ziele
Technisches Ziel des Projektes war die Umsetzung einer XML-basierten Kommunikationsplattform,
die bei der Abwicklung von Großbauvorhaben über Unternehmensgrenzen
hinweg den automatisierten Dokumenten- und Datenaustausch zwischen
Projektbeteiligten ermöglicht. Über die Kommunikationsplattform sollten die unterschiedlichen,
bei den Projektpartnern vorhandenen Dokumentenmanagement- und
Workflowsysteme regelbasiert Dokumente und Daten austauschen können.
Dabei sollte ein Publish- und Subscribe-Verfahren zum Einsatz kommen. Dies bedeutet,
dass von einem System an die Kommunikationsplattform übermittelte Daten
von dieser registriert/publiziert werden und danach den anderen Projektbeteiligten
über Subscribe-Verfahren („Buchen“ von regelmäßiger Informationsbereitstellung)
zum automatisierten Download zur Verfügung stehen.
Die Plattform selbst stellt kein zentrales Dokumentenmanagementsystem (DMS) dar,
auf das die Projektbeteiligten gemeinsamen Zugriff haben, sondern dient vielmehr
als zentrale Austausch- und Übersetzungsebene für jene Informationen, die aus den
unterschiedlichen Systemen heraus zur Verfügung gestellt werden. Der automatisierte
Daten- und Dokumentenaustausch erfolgt über projektspezifische Metadatenstrukturen.
Die Konvertierung der aus den firmenspezifischen Systemen exportierten Daten
in die Metadatenstruktur der Projekt-Kommunikationsplattform und zurück für den
Import in das Zielsystem übernehmen Schnittstellenprogramme (Connectoren), die in
der Regel ohne Programmierung durch dialoggesteuerte Konfiguration an die
Schnittstellenformate der angeschlossenen Systeme angepasst werden könnnen.
Die Metadatenstrukturen müssen alle Daten beinhalten, die es ermöglichen, ein Dokument
zusammen mit wesentlichen projektspezifischen Strukturinformationen au-
1/10

tomatisiert beim Empfängersystem zu registrieren, d.h. ohne dass der Empfänger
das Dokument manuell verschlagworten muss. Bei der Übertragung können die Metadaten
über Regeln erweitert, transformiert und gemappt werden.
1.2. Die Konzeption
Die Einzelarbeiten zur Entwicklung der Kommunikationsplattform wurden großteils
nach einem bereits bei Freigabe durch den FFF vorliegenden Projektplan durchgeführt,
Abb. 1.1 .
Teil Tätigkeit
Projekt: Kommunikationsplattform Dokumentenaustausch
START: Kick-Off-Meeting
Projektsteuerung/Administration
XML-Datenstrukturen für die Datenaustausch-Objekte
Projektstammdaten
Bauspartentypische Katalogisierung
Server
Abschnitt 1
Abschnitt 2
Softwaremodul "Kommunikationsplattform"
Dokumentenmanagementsysteme
Smart-Document-Exchange-Client (SDEC)
DMS-Connectoren (Export/Import)
Prototyp-Beispielprojekt
Projektendbericht
Endveranstaltung mit Projektreview
Abb. 1.1: Einzelarbeiten aus Projektplan
Das Projekt wurde in mehrere Module aufgeteilt, die zeitlich parallel und relativ unabhängig
voneinander entwickelt werden konnten. Dies erlaubte es, nach dem gerade
vorhandenen Wissensstand in den Einzelaufgabengebieten, einige Schritte vorzuziehen
bzw. später zu bearbeiten. Folgende Schritte bzw. Module wurden bearbeitet:
a) Recherche und Grundkonzept
Zunächst wurde eine umfassende Recherche von DMS-Systemen und Plattformen
für den Bausektor durchgeführt. Das aktualisierte und anonymisierte Ergebnis ist unter
http://baubetrieb.uibk.ac.at – Forschung – Publikationen im Internet abrufbar. Auf
Basis dieser Ergebnisse und der dabei gewonnenen Erkenntnisse wurde das Gesamtkonzept
der XML-basierten Kommunikationsplattform erarbeitet, mit der die Daten
und Dokumente zusammen mit standardisierten Registrationsinformationen (Metadaten)
automatisiert zwischen unterschiedlichen Dokumentenmanagementsystemen
(DMS) ausgetauscht werden können, Abb. 1.2.
Es wurde weit mehr Zeit in die Recherche und Konzeption investiert als ursprünglich
veranschlagt. Speziell das Studium der aktuellen Weiterentwicklungen der internationalen
XML-Standards war sehr wichtig, da die Thematik immer mehr Perspektiven
und Umsetzungmöglichkeiten für die Plattform bot. Aufgrund dieser neuen Erkenntnisse
und des Feedbacks von potenziellen Kunden, haben sich die Projektpartner
2/10

dazu entschlossen, das Projekt auszuweiten und zwei verschiedene Arten der Plattform
umzusetzen:
• Eine rein internetbasierende Lösung, die als Erweiterung einer bereits bestehenden
Projektplattform den Datenaustausch regelt (Internetmodul). Diese
Lösung könnte in Zukunft auf Mietbasis in unterschiedlichen Projektplattformen
zum Einsatz kommen, die bei einem Projekt zusammengeschaltet werden
müssen (ASP-Variante).
• Die zweite Umsetzungsart ist die ursprünglich konzipierte Form der Kommunikationsplattform,
mit herkömmlicher Client-Server Architektur.
Beide Varianten sind auch beliebig kombinierbar.
Abb. 1.2: Konzept der Funktionsweise der Kommunikationsplattform
b) XML-Datenstrukturen für die Datenaustausch-Objekte
Um den Austausch von bauprojektspezifischen Dokumenten und Daten geregelt ermöglichen
zu können, musste eine generelle XML-Datenstruktur (Metastruktur) ausgearbeitet
werden. Diese universelle Plattformstruktur muss als eine Art Relaisstation
funktionieren, um Dokumente aus einer DMS-Ablagestruktur in die Struktur anderer
Ablagesysteme überführen zu können.
Die Metastruktur ist integraler Bestandteil bei der Anwendung der GKP bei einem
Projekt geworden. Sie dient als kleinstes gemeinsames Vielfaches der zu verbindenden
Strukturen und kann flexibel abänderbar folgende Informationen enthalten:
• Routinginformationen (Absender/Empfängerinformationen, Aufbewahrungsfristen,
etc.)
• Objektklassifizierung (Dokumenttyp),
3/10

• Prozessinformationen (zur Weiterverarbeitung in Workflowsystemen und Prozessen)
und
• Katalogisierungsinformationen (Zuordnung zu einer vereinbarten Ablageordnung,
um die Objekte am Zielort automatisch, d.h. ohne manuelle Verschlagwortung
wieder in die Zielsysteme einlagern zu können.)
c) Bauspartentypische Katalogisierung
Vor Beginn eines Projektes müssen sich die beteiligten Projektpartner auf die Dokumenttypen
und die mit ihnen zu übertragenen Katalogisierungsinformationen einigen.
Es war eine der Arbeiten dieses Projektes, solche Empfehlungen für Katalogisierungen
zu erarbeiten.
Die mit den Dokumenten und Daten mitzuliefernden Metadaten (Katalogisierungs-
Informationen) enthalten Angaben zur Einordnung in die jeweilige Projektstruktur -
hängen jedoch stark vom jeweiligen Projekttyp ab.
Nach langer Entwicklungsarbeit und vielen Diskussionen wurde schließlich die Idee
der standardisierten Struktur fallengelassen und eine projektbezogene Katalogisierung
als gemeinsamer Rahmen weiterverfolgt und ausgearbeitet.
Diese Struktur besteht aus 3 Hauptebenen, die mit den üblichen Ablagestrukturen,
meist Papierablagen, nicht mehr viel zu tun hat. Man bedient sich bei diesem Ansatz
mit den Hauptebenen “Projektphase” (aus der HOPS), “Vertragsleistung/Rolle”, und
“Dokumentenart”. Diese Zuordnungen genügen, um ein Dokument eineindeutig ablegen
zu können. Zusätzlich zu dieser Hauptstruktur können nach Bedarf weitere Metainformationen
zum Dokument hinzugefügt werden, um zum Beispiel Bearbeitungsinformationen,
Beziehungen zu anderen Dokumenten, Organisationen, Personen,
etc. zu hinterlegen.
Abb. 1.3: Schematische Darstellung projektbezogenen Katalogisierung
4/10

Phasen:
Projektvorbereitung (PV),
Planung (PL),
Ausführungsvorbereitung (AV),
Ausführung (AF) und
Projektabschluß (PA)
Vertragsleistungen:
Kategorie = „Vertragsleistung“ = virtueller „Ablageplatz“ des Dokuments
Vertragsleistungen sind klar umgrenzte Arbeitspakete (Work-pakages), die
von einer bestimmten Arbeitsgruppe erbracht werden müssen.
Rollen:
Die Ersteller eines Dokuments werden verschiedenen „Rollen“ zugewiesen,
die sich aus der Vertragsleistung ableiten. Diese Rollen können in der Regel
auch dazu verwendet werden, um den Projektbeteiligten Rechte auf die Daten
zuzuweisen. Die Tiefe der Rollen kann/muß je nach Gebrauch des Systems
unterschiedlich sein.
Projektabschluß
Gewerke
Bauherr
Amtsunterlagen
…….
Abb. 1.4: Beispielhafte XML-Datei mit den gewählten Metadaten aus Abbildung 1.3
Nach obigem Konzept der projektbezogenen Katalogisierung wurden beispielhaft
Katalogisierungsempfehlungen für ein Hochbau- und ein Tiefbauprojekt erarbeitet,
die auch als Vorgabe für besondere Technische Vertragsbedingungen (BTV) in Ausschreibungen
herangezogen werden können.
d) Plattformprogrammierung (DXS)
Die Plattformprogrammierung besteht aus der Integration folgender Einzelkomponenten
• Softwaremodul „Kommunikationsplattform“
• Plattform-Connector
• Offline-Client (SDEC=Smart Document Exchange Client)
Ein spezielles Add-On zum Connector erlaubt es auch normale Dateiablagen (Verzeichnisbäume)
und auch E-Mailsysteme als Vorsysteme zur Plattform zu verwenden.
Dabei werden die Metainformationen aus den Verzeichnis- und den Dateinamen
bzw. den E-Mail-informationen extrahiert. Genauso können bei einem Export von
Dokumenten aus der Plattform eine Detailablage für Verzeichnis- und Dateinamen
aus den Metainformationen generiert werden.
5/10

Abb. 1.5: Beispielhafte Funktionsweise zweier Connectoren
6/10

Das Modul „Kommunikationsplattform“ (DXS) verwaltet die Zugriffsberechtigungen,
die Objekttypen und steuert die Publish/Suscribe-Möglichkeiten mittels eines
Messaging-Queue-Servers oder eines FTP bzw. HTTP-Moduls.
Im „Plattform-Connector“ können die Schnittstellen zwischen den einzelnen DMS
und der Plattform generisch erzeugt bzw. geändert werden. So wird ein automatisches
Konvertieren der Daten zwischen dem Exportformat eines beliebigen DMS,
oder auch einer Dateiablage und der Metastruktur der Plattform möglich. Siehe
Abb.1.5.
„Offline-Client“: Projektbeteiligten Personen, die nicht über ein DMS oder über Programme
mit entsprechenden Schnittstellen verfügen, erlaubt es das SDEC-Modul
einerseits, Datenobjekte der Kommunikationsplattform zu öffnen und die in ihnen
hinterlegten Informationen anzuzeigen und andererseits Datenobjekte im Format der
Plattform zu erzeugen.
Damit kann z.B. ein externer Gutachter ein Dokument inklusive Projektstrukturinformationen,
die über einen entsprechenden Dialog erfasst werden, per Knopfdruck in
ein Datenaustauschobjekt der Kommunikationsplattform konvertieren und das Objekt
dann z.B. per e-Mail an die Plattform oder direkt an ein empfangendes System senden.
1.3. Ergebnisse
Die Umsetzung der internetbasierenden Lösung ist abgeschlossen. Die einzelnen
Module der Kommunikationsplattform sind einsatzbereit und laufen in den Testumgebungen
bisher sehr zufrieden stellend. Derzeit wird an der Erstellung der Connectoren
für Beispiel-EDM-Systeme gearbeitet.
Eine Präsentation und Live-Demonstration der Funktionalität der Kommunikationsplattform
findet im Rahmen des alljährlichen Kongresses International Consulting &
Construction am 21. November in Innsbruck/Igls statt.
Der geregelte Austausch von XML-basierenden Formularen (im neuen XForms Format)
ist bei einigen Kunden auf sehr großes Interesse gestoßen. Der Markt für auf
XForms-Technologie basierende Informationssysteme scheint den Projektpartnern
Erfolg versprechend genug, um ein weiteres Forschungsprojekt zu initiieren, welches
teilweise auf Funktionen der Kommunikationsplattform aufsetzt.
1.4. Schwierigkeiten
Bei der Erstellung der XML-Strukturen der Plattform war zunächst geplant, auf bereits
bestehende, eventuell sogar praxiserprobte Strukturen zurückzugreifen. Solche
Strukturen wurden z.B. durch die IAI (International Alliance for Interoperability) entwickelt,
u.zw. die sog. inzwischen XML-basierte „ifc-Struktur“ (IndustryFoundationClasses),
die anfangs auf den CAD-Datenaustausch ausgerichtet war und derzeit um
weitere Anwendungsgebiete erweitert wird.
Das XML-Schema (ifcXML) ist seit Ende 2002 allgemein gültiger ISO-Standard. Es
wurde untersucht, inwieweit ein Aufbau der generischen Plattform-Struktur auf Basis
von ifcXML möglich und praktikabel ist. Die Schwierigkeit war, die auf digitale Gebäudemodelle
und den Hochbau ausgerichtete ifc-Struktur sinnvoll für die gegenständlichen,
allgemein gültigen Strukturanforderung zu adaptieren.
Nach eingehender Überprüfung kamen die Projektpartner letztendlich zum Schluss,
dass der Vorteil des Einsatzes der standardisierten Struktur für die geplanten Anfor-
7/10

derungen die Nachteile wegen der großen, hier nicht erforderlichen Komplexität und
Strukturtiefe der ifcXML nicht aufwiegt. Auch andere Standards wie aecXML oder
bcXML wurden untersucht, jedoch mit dem gleichen Ergebnis. Mit dem gewonnenen
Knowhow wurde eine für die generischen Plattformanforderungen optimierte, eigene
XML-Struktur entwickelt.
1.5. Einsatz in Projekten - Resumee
Mit der vorliegenden Lösung konnte eine generische Konzeption umgesetzt werden,
die die Verknüpfung unterschiedlichster DMS-Systeme von verschiedenen Projektpartnern
ermöglicht. Auftraggeber, die immer wieder (Bau-) Projekte initiieren, werden
weiterhin ihr System verwenden und dieses den Auftragnehmern zur Verwendung
vorschreiben.
Diese wiederum müssen ihr firmenintern verwendetes System, das mit der Software
und der Ablagestruktur des Auftraggebers in der Regel nicht identisch sein wird, nicht
wechseln, sondern können durch Integration des durch die Projektpartner entwickelten
„generischen Plug-In’s“ in ihr DMS und durch die spezifischen Connectoren mit
dem System des Auftraggebers problemlos kommunizieren.
Darüber hinaus ergeben sich weitere Perspektiven für den Einsatz der generischen
Plattform durch Anwendung der X-Forms-Technologie, die bereits zur Antragstellung
eines weiteren Forschungsprojektes geführt haben.
Innsbruck, im November 2003
Für das Projektteam:
DI Mag. A.Blindow DI M.Leitner
Univ.Prof.DI Dr. A.Tautschnig Univ.-Ass. DI R.Feik
8/10

Die Autoren:
Dipl.-Ing. (ETH), lic. oec. (HSG) Axel Blindow
Ausbildung:
1981 bis 1985 Studium des Bauingenieurwesens an der Eidgenössischen Technischen Hochschule
Zürich (ETH) mit den Vertiefungsrich-tungen Konstruktion/Statik und Grund- und Felsbau
1987 bis 1989 Studium der Betriebswirtschaft an der Hochschule St.Gallen (HSG), mit Vertiefungsrichtung
Wirtschaftsinformatik
Beruflicher Werdegang:
1986 bis 1993 Konzeption und Entwicklung eines EDV-Programmes für tagesaktuelles, operatives
Controlling (Mengen, Kosten, Termine) für Tunnelbaustellen
Neben dem Studium der Betriebswirtschaft Betreuung verschiedener Projekteinsätze
des Controlling-Programmes
Softwareentwicklung mit relationalen DBMS, Unix-, MIS und OLAP-Systemen
Weiterentwicklung des Controlling-Programmes und verschiedene Projekteinsätze
1994 Ausbildung zum Fachauditor Bau nach DIN/ISO Normenreihe 9000ff
Seit 1994 Geschäftsführender Gesellschafter und Projektleiter bei Tunnel Consult Blindow &
Partner GmbH, Innsbruck,
(seit 2001: Blindow & Partner Consulting GmbH)
Schwerpunkte: Qualitätsmanagement nach ISO 9000, Baubetriebliche Controllingsysteme,
Firmen-Informationssysteme
Seit 2000 Geschäftsführender Gesellschafter bei StratOz GmbH, Schwerte und Innsbruck, die
sich als Systemintegrator schwerpunktmäßig mit der Unterstützung und Automatisierung
von Geschäftsprozessen im Bereich Belegerfassung, Formular- und Dokumentenmanagement
sowie Workflow befasst.
Dipl.-Ing. Marko J. Leitner
Ausbildung:
1990 Reifeprüfung (AHS)
1991 bis 1992 Ausbildung zur Milizoffizier beim österreichischen Bundesheer (Dienstgrad: Leutnant)
1991 bis 2000 Studium des Wirtschaftsingenieurwesens/Bauwesen an der Technischen Universität
Graz
1999 Diplomarbeit: „Improving On-Site Labor Productivity“ an der University of Calgary / CA
Department of Civil Engineering – Project Management Specialization
Beruflicher Werdegang:
2000 Eintritt als Projektingenieur bei Tunnel Consult Blindow & Partner GmbH –
seit 2001 BLINDOW & PARTNER Consulting GmbH
seit 2000 Unterstützung der Projektleitung und der GF in den Bereichen Projekt-, Qualitäts und
Risikomanagement bei div. Projekten
Umsetzen der projektspezifischen Lösungen mit entsprechenden EDV-Programmen
Mitarbeit bei der Entwicklung „easy9000“, einer Software zur (QM-spezifischen) Dokumentenverwaltung
im Intra-/Internet
2001 Entwicklung eines Controlling Tools zur raschen Standortbestimmung von Tunnelvortriebsarbeiten
auf Excel Basis
04/05 2002 Lehrgang Qualitätsmanagement (ÖQS)
Lehrgang Qualitätsmanagement in der Anwendung (ÖQS)
Prüfung zum Qualitätsbeauftragten (ÖQS)
2002 Entwicklung eines Risikomanagement Tools zur Analyse, Beurteilung und Steuerung
von projektbezogenen Risiken und Chancen auf Excel Basis
Veröffentlichung: Beitrag „Baubetriebliches Controlling im Tunnelbau“ im Wirth Fachbuch
„Controlling in der Baupraxis“
Projekttleiter des FFF-Forschungsprojekts „Entwicklung einer generischen Kommunikationsplattform
für Großprojekte“
9/10

Univ.Prof. Dipl.-Ing. Dr. Arnold Tautschnig
Ausbildung:
- 2. Staatsprüfung, TU Graz (Bauwesen)
- 2. Staatsprüfung, TU Graz (Wirtschaftsingenieurwesen - Bauwesen)
- Promotion zum Dr. techn. s.a.p.
- Konzessionsprüfung für Unternehmensberater
- Konzessionsprüfung für das Baumeistergewerbe
- Zivilingenieur für Bauwesen und Wirtschaftingenieurwesen
Beruflicher Werdegang:
1977 - 1981 Studienassistent und Assistent an der TU Graz / Institut für Mechanik
1981 – 1984 Assistent an der Universität Innsbruck / Institut für Stahlbau
seit 1984 Achammer-Tritthart & Partner, Innsbruck, Gruppenleiter für Projektmanagement
seit 1992 Assoziierter Partner bei Achammer-Tritthart & Partner, Innsbruck
seit 01.01.1995 Gesellschafter und Geschäftsführer der ATP Achammer-Tritthart & Partner, Innsbruck,
ZT GmbH
seit 22.11.1999 Vorstand und Aktionär der ATP Achammer-Tritthart & Partner, Innsbruck,
ZT-Aktiengesellschaft
bis 31.12.2001 Geschäftsführer der ATP Achammer-Tritthart & Partner Planungs-GmbH,Innsbruck
seit 1.10.2001 Univ.Prof. für Projektplanung und Projektsteuerung am IBBB
Univ.-Ass. Dipl.-Ing. Roland Feik
Ausbildung:
1994 Reifeprüfung (AHS)
1994 bis 1995 Wehrdienst beim JgR4 Ebelsberg
1995 bis 2003 Studium Bauingenieurswesen mit Vertieferrichtung Baubetrieb und Bauwirtschaft an
der Universität Innsbruck, TU Wien und NTNU (Norges teknisk-naturvitenskapelige
universitet) Trondheim / Norwegen
Diplomarbeit:
Informationslogistik in Bau-Projektorganisationen – Ist-Analyse und Sollkonzept der Informationslogistik
bei baunahen Dienstleistern
Beruflicher Werdegang:
seit 2003 Doktoratsstudium der technischen Wissenschaften
02/2003 Vertragsassistent am IBBB
seit 01.03.2003 Univ.-Ass. am IBBB (Bereich Baumanagement)
Projektleiter Stv. für das FFF Projekt „GKP“
10/10