Arbeitspaktet 1: Bauontologiekern und Systemarchitektur

Das Arbeitspaket AP1 definiert und entwickelt den Rahmen der Gesamtplattform in Form grundlegender Datenmodelle und einem SOA-basierten System. Alle Datenstrukturen werden als Ontologie definiert, um eine hohe Flexibilität für die vertikale und horizontale Interoperabilität zu gewährleisten. Bereits vorhandene Standards (IFC, GAEB) werden intensiv genutzt und erweitert.

In den folgenden Abschnitten sind die wesentlichen Zwischenergebnisse aus dem Arbeitspaket AP1 im Hinblick auf die folgenden vier Projektphasen zusammengefasst:

Phase 4: Validierung und Demonstration

Die im Arbeitspaket AP1 entwickelten Datenspezifikationen und Softwarekomponenten wurden in allen Demonstrationsszenarien für die Erstellung von Planungs-, Analyse- und Controllingmodelle eingesetzt. Im Mittelpunkt der Untersuchungen standen zum einen die Definition detaillierter Anforderungen für die unterschiedlichen Multimodelle sowie die Festlegungen für die Attributierung ihrer Fachmodelle. Zum anderen wurden die entwickelten Softwaresysteme weiter optimiert, um die Multimodelle des Mefisto-Flughafens mit bis zu sieben verschiedenen Fachmodellen und insgesamt mehr als 200 MB effizient bearbeiten zu können.

Integrierte Bauwerks- und Baustellenmodelle des Mefisto-Flughafens in iTWO, Ed. Züblin AG

Softwarekomponenten für Multimodelle
Mit den entwickelten Softwarekomponenten wurden zahlreiche Multimodelle des „Mefisto-Hochhauses“ und des „Mefisto-Flugsteigs“ erstellt, z.B. für die Angebotsanfrage und Angebotsabgabe, für multimodell-basierte Bauverträge und –nachträge, zur Detail- und Fertigteilplanung, für die Baustellen-, Montage- und Logistikplanung und entsprechende Prozesssimulationen sowie für das Leistungs- und Fortschrittscontrolling und die Risikosimulation. Die Multimodelle des Mefisto-Flugsteigs umfassen dabei bis zu sieben verschiedene Fachmodelle mit insgesamt mehr als 200 MB. Um die großen und interdependenten Fachmodelle effizient lesen, bearbeiten und wieder konsistent exportieren zu können waren, zahlreiche Softwareoptimierungen und einige Fehlerkorrekturen notwendig. Darüber hinaus wurden weitere Verwaltungsfunktionen und Werkzeuge für die Visualisierung und Prüfung der Fach- und Linkmodelle entwickelt. Hierzu gehören insbesondere Komponenten für die Attribut- und Linkprüfung in den Systemen iTWO, GRANID und Multimodel-Filter-und-Analyse-Plattform (M2A2). Darüber hinaus wurde ein webbasierter MMC-Navigator realisiert, in dem sich die Fach- und Linkmodelle tabellarische darstellen und filtern lassen.

Modellvorlagen und Annotationsvokabulare
Für die in den Szenarien zu erstellenden Multimodelle wurden Multimodell-Vorlagen definiert, welche detailliert die Anforderungen an die Eingangsinformationen und Ergebnisse einzelner Teilaufgaben beschreiben. Hierbei konnten die Vokabulare zur Annotation der Fachmodelle nochmals vereinheitlicht und vereinfacht werden. Für die Szenarien „Leistungs- und Fortschrittscontrolling“ sowie „Nachtragserstellung und -controlling“ wurden darüber hinaus Erweiterungen am Schema der multimodell.xml vorgenommen, um Multimodelle zu einzelnen Abrechnungszeiträumen und Nachträgen mit Hilfe der Vorlagen automatisch filtern zu können. Der MMC-Editor zur Definition von Multimodell-Vorlagen und semantischer Auszeichnung für Multimodell-Containern wurde mit dem VO- und Workflow-Editor zu einem Platform Collaboration Manager (CoMa) zusammengefasst.

Spezifikation für Fachmodelle und Linkmodelle
Für die gezielte Nutzung der Fachmodelle wurden die Ontologien der Fachmodelle weiter präzisiert, indem bestehende Merkmalskataloge (z.B. IFCPropertySets) vereinbart und ergänzende Kataloge sowie weitere Objektvorlagen (Referenzmodule) für die Demonstrationsszenarien entwickelt wurden. Ein Schwerpunkt war dabei die Anpassung der Attributierungen bei der Generierung von Baugeräten und der Abfrage beliebiger Parameter auf allen Ebenen einer Baugruppenstruktur.
Darüber hinaus wurden kleinere Anpassungen an den entwickelten Fachmodellschemas vorgenommen sowie weitere Konfigurations- und Einsatzmöglichkeiten der Linkmodelle erarbeitet, z.B. für die Verknüpfung unterschiedlich detaillierter Fachmodelle und die Anbindung unstrukturierter Dokumente.

Standardisierung
Ein weiterer Schwerpunkt war weiterhin die Verankerung des allgemeingültigen Teils der Bauontologie in nationalen und internationalen Standards. Diese Arbeiten mit den Standardisierungsgremien wurden weitergeführt. Der Multimodell-Container wurde bei der GAEB AG13, der Organisation, welche sich mit der Standardisierung von Leistungsbeschreibungen beschäftigt. Ergebnisse von Mefisto, insbesondere die Verknüpfung von Bauwerksmodell, Vorgangsmodell und Mengengerüst sind in den internationalen Standard ISO16739 (IFC4) eingeflossen, der sich im Endstadium der Standardisierung befindet.

Phase 3: Systementwicklung und Tests

Das Arbeitspaket AP1 befindet sich zurzeit in der dritten Projektphase. Bisher wurden in dieser Phase verschiedene Softwarekomponenten für die Erstellung, die Bearbeitung, den Austausch und die Auswertung von Multi-Modellen implementiert. Parallel hierzu wurden die datentechnischen Spezifikationen für die Multi-Modelle überarbeitet und ergänzt sowie die Ontologien zur Annotation der Fachmodelle im Multi-Modell-Container weiter ausgearbeitet.

Oberfläche der M2A2-Plattform


Die obige Abbildung zeigt die Nutzeroberfläche der Multi-Model Assembly and Analyzing Platform (M2A2) zum Filtern, Verlinken und Analysieren der Fachmodelle aus den Multi-Modell-Containern. Das erste Fenster links, gibt zunächst einen Überblick über die im Con-tainer enthaltenen Fachmodelle und Linkmodelle. Die Inhalte und Metadaten dieser Modelle können daraufhin in verschiedenen fachmodellspezifischen Viewer-Fenstern (3D-Bauwerk-Viewer, Balkenplan-Viewer, Pert-Chart-Viewer, LV-Viewer etc.) angezeigt werden. Für die Analyse, Kombination und Weiterverwendung der Fachmodellinformationen werden zusätzlich verschiedene Filter-, Verlinkungs- und Analysefunktionen auf der Ebene der einzelnen Fachmodelle sowie des gesamten Multi-Modells angeboten.

Softwarekomponenten für Multi-Modelle
Für die Bearbeitung und den Austausch von Multi-Modellen wurden in der dritten Projektphase weitere Softwarekomponenten für kommerzielle Anwendungen, wie z. B. GRANID (gibGREINER GmbH), iTWO (RIB Information Technologies AG) und Plant Simulation (Tecnomatix) sowie für Forschungsprototypen, wie z. B. das Multi-Modell-Filter und –Analyse-Framework M2A2 (TU Dresden) und den SiteSimEditor (Ruhr-Universität Bochum) entwickelt. Zusätzlich zu den Komponenten für die Nutzung von Bauwerks-, LV- und Prozes-sinformationen wurden in der dritten Projektphase insbesondere Komponenten für die Men-gen- und Risikomodelle implementiert.
Für die Definition von Vorlagen sowie für die semantische Auszeichnung für Multi-Modell-Container wurde ein MMC-Editor implementiert. Parallel hierzu wurde eine zentrale Multi-Modell-Verwaltung umgesetzt, mit der die auf der Mefisto-Plattform verteilten MM-Container und die entsprechenden Container-Vorlagen zentral verwaltet werden können.

Modellvorlagen und Annotationsvokabulare
Mit der Erstellung weiterer Multi-Modelle für die Anwendungsszenarien in AP5 bis AP9 wurden auch die Projekt-Kollaborations-Ontologie und die Baukernontologie weiter detailliert. Für die Annotation der Kernobjekte in den Fachmodellen mit Typ-Informationen sowie der Fachmodelle mit semantischen Metadaten wurden verschiedene Klassifikationen untersucht und erste Vokabulare zusammengestellt. Mit Hilfe der Vokabulare wurden in den Anwen-dungsszenarien erste MMCs annotiert und MMC-Vorlagen zum Filtern und zur Referenzpro-zessmodellierung definiert. Darüber hinaus wurde ein Verfahren für die Generierung von semantischen polyhierarchischen Annotationsvokabularien aus mehreren Klassifikationen entwickelt und im Rahmen eines Softwareprototyps umgesetzt.

Spezifikation für Fachmodelle und Linkmodelle
Mit der Entwicklung der Softwarekomponenten und der weiteren Ausarbeitung der Anwen-dungsszenarien wurden auch die Spezifikationen für den Multi-Modell-Container weiter an-gepasst und neue Fachmodelle in den Container aufgenommen:
- Risiken: Für den Austausch von Risikoinformationen wurden zwei XML-Formate für einen Risikokatalog mit allgemeinen Risiken sowie für eine Risikoliste mit den Risiken eines be-stimmten Bauprojektes definiert. In den Katalogen und Listen können die Risiken mit entsprechenden Beschreibungen aufgeführt und mit verschiedenen Eintrittswahrschein-lichkeiten und Konsequenzen hinsichtlich der Kosten, Termine und Qualitäten des Projektes sowie möglichen Maßnahmen zur Beeinflussung der Risiken versehen werden.
- Prozesse:Für den Austausch von Terminplänen und erweiterten Prozessmodellen wurde das XML-basierte Format IfcProzess.xml als Alternative zum Activity.xml definiert. Die XML-Schema-Definition wurde mit Hilfe speziell entwickelter Filterverfahren (vgl. AP4) aus dem IFC Standard (ISO 16739) in der neuesten Version IFC 4 abgeleitet.
- Kalkulation: Für die Übergabe von Planungsinformationen aus der Kalkulation zur Monta-ge- und Logistiksimulation, wie beispielsweise die Ressourcenbedarfe und Aufwandswerte zu einzelnen LV-Positionen, wurde ein XML-basiertes Kalkulationsmodell des AN in den Multi-Modell-Container mit aufgenommen.
- Baustelle: Für den Austausch von Informationen über Baugeräte wurden zwei XML-Formate für allgemeine Baugerätekataloge sowie für projektspezifische Baugerätelisten definiert. Für die mit Hilfe der in AP 7 entwickelten SolidWorks-Komponenten konfigurier-ten Geräte können mit Hilfe dieser Formate die Geräteinformationen für die Kalkulation und die Simulation ausgetauscht werden.


Standardisierung
Die Entwicklungen zur Definition von Multi-Modellen wurden sowohl national bei buildingSMART und international als auch bei der Internationalen Standardisierungsorganisation ISO in den technischen Komitees ISO TC184/SC4 "Industrial Data" und ISO TC59 SC13 "Building Construction - Object-oriented structures" vorgestellt. Derzeit wird untersucht, ob weitere Teile, insbesondere die formale Abbildung von Subschemas und Teildatenmodellen interna-tional standardisiert werden können. Dies würde die in Mefisto mitentwickelte Technologie international absichern.

Phase 2: Ausarbeitung und Spezifikation

In der zweiten Projektphase wurden Spezifikationen für die einzelnen Fachmodelle und dar-aus zu erstellende Multi-Modell ausgearbeitet. Soweit als möglich wurden dabei standardi-sierte Formate für den Austausch der Fachmodelle wie z.B. für Bauwerkmodelle und Leis-tungsverzeichnisse eingesetzt, die durch neue Spezifikationen wie z.B. für Linkmodelle und Vorgangsmodelle ergänzt wurden.

Parallel zu den datentechnischen Spezifikationen wurden die Grundstrukturen von Fachmo-dellen und Multi-Modellen in einem hierarchischen Ontologie-Framework formalisiert. Die folgende Abbildung zeigt die Komponenten des Ontologie-Frameworks. Auf der obersten Ebene (Ebene 5) beschreibt die Projekt-Kollaborations-Ontologie die Nutzer, Softwarediens-te, Informationsprozesse auf der Mefisto-Plattform sowie die dabei verwendeten Multi-Modelle und ihre Visualisierungen. Die Multi-Modelle werden dabei durch die eingebettete Baukernontologie beschrieben, welche vier weitere Ebenen umfasst, auf denen die Elemente und Systeme in den einzelnen Fachmodellen (Ebenen 1 und 2), die Fachmodelle und Link-modelle einzelner Multi-Modelle (Ebene 3) und die durch die Fach- und Linkmodelle in einem Multi-Modell aufgezeigten Supersysteme (Ebene 4) repräsentiert werden können.

Prinzipieller Aufbau der hierarchischen Projekt-Kollaborations-Ontologie, Institut für Bauinformatik, Technische Universität Dresden


Neben den Spezifikationen für die Fachmodelle und Ontologien wurde einer Systemarchitek-tur für die Mefisto-Plattform ausgearbeitet und mit der Implementierung erste Software-komponenten zur Bearbeitung und Auswertung von Multi-Modellen begonnen.

Spezifikation für Multi-Modelle
Für den Austausch von Multi-Modellen wurde ein XML-basiertes Multi-Modell-Container-Format entwickelt, mit dem Fachmodelle in standardisierten oder marktüblichen Formaten zusammengefasst, durch Linkmodelle verbunden und durch semantische Metadaten ausge-zeichnet werden können. Für die in den Anwendungsszenarien verwendeten Fachmodelle und Linkmodelle wurden die inhaltlichen, technischen und funktionalen Anforderungen weiter untersucht sowie die horizontalen, vertikalen und longitudinalen Interdependenzen im Multi-Modellverbund systematisch aufgenommen. Für den Austausch der Fachmodelle Leis-tungsverzeichnis und Bauwerk wurden zunächst die Formate GAEB-XML und IFC 2x3 aus-gewählt. Darüber hinaus wurden Vorschläge für Formate zum Austausch der Fachmodelle Baustelle, Projektorganisation, Vorgangsmodell, Prozess- und Risikomodelle diskutiert, welche teilweise auf der Basis des IFC-Standards und proprietärer entwickelt wurden.

Systemarchitektur der Mefisto Plattform
Auf der Grundlage des Konzeptes für die Mefisto-Plattform wurde eine Systemarchitektur entwickelt, welche die unterschiedlichen Anwendungsdienste sowie die erforderlichen zen–tralen Plattformdienste aufzeigt. Für die unterschiedlichen Dienste wurden daraufhin einzelne Softwarekomponenten für die Erstellung, den Austausch und die Auswertung von Multi-Modellen und die Grundlagen für die Service-Kommunikation definiert.

Softwarekomponenten für Multi-Modelle
Von den Industriepartnern wurde mit der Ergänzung und Anpassung ihrer Softwaresysteme begonnen, um die entwickelten Multi-Modelle bearbeiten und entsprechende Mefisto-Container lesen und schreiben zu können. Von den Forschungspartnern wurde zusätzlich mit der Umsetzung eines neutralen Multi-Modell-Viewers (M2A2 – Multi-Model Analyse and Assembly Platform) zum Anzeigen und manuellen/semiautomatischen Verknüpfen von Ele-mentarmodellen begonnen. Als Viewer für IFC kamen die OpenIfcTools der Bauhaus-Universität Weimar zum Einsatz, für andere Fachmodelle wurden eigene Viewer entwickelt.

Hierarchisches Ontologie-Framework
Das hierarchische Ontologie-Framework definiert semantische Grundlagen für die Multi-Modelle sowie für deren partnerschaftliche Nutzung auf der Mefisto-Plattform. Wie in der obigen Abbildung gezeigt, gliedert es sich in die Baukernontologie und die Projekt-Kollaborations-Ontologie. Die Baukernontologie identifiziert zunächst wichtige Elementtypen in den unterschiedlichen Fachmodelldomänen (Kernelemente) sowie zugehörige Typen von Linkobjekten unabhängig von den jeweils verwendeten Datenformaten. Dieses semantische Vokabular ermöglicht die einheitliche Annotation der einzelnen Fach- und Linkmodelle durch welche das Filtern, die Transformation und das Prüfen sowie das Verlinken und Weiterver-wenden der Multi-Modell-Inhalte unterstützt wird.
Die Projekt-Kollaborations-Ontologie wiederum definiert Konzepte, um die Geschäftssyste-matik der Mefisto-Plattform zu beschreiben. Die formale Beschreibung dieser Systematik durch eine über die Web-Services verteilte Ontologie ermöglicht es, die erforderlichen Mo-dellierungs-, Transport-, Transformations- und Analyseprozesse für den Einsatz der Multi-Modelle aufzuzeigen und im Nachhinein zu dokumentieren.

Phase 1: Anforderungen und Konzeption

Im Arbeitspaket AP1 wurden in der ersten Projektphase die Anforderungen an das anvisierte Management-Führung-System für das partnerschaftliche Bauprojektmanagement von den Projektpartnern abgestimmt. Für die systematische Aufnahme der Anforderungen wurden verschiedene Szenarioanalysen durchgeführt und neue Konzepte für die Bearbeitung und den Austausch von Fachmodellen mit Planungs- und Controlling-Informationen entwickelt. Die folgende Abbildung zeigt die Domänen der herkömmlichen Fachmodelle mit wichtigen Informationen für das Bauprojektmanagement auf drei Ebenen (Ebenen 2 bis 4). Darunter werden die Modelldomänen dargestellt, in denen die Verlinkung der Projektinformationen (Ebene 1) und ihre weitere Verwendung (Ebenen 0) untersucht werden.

Fachmodell- und Anwendungsdomänen in Mefisto, Institut für Bauinformatik, Technische Universität Dresden


Darüber hinaus wurde in Zusammenarbeit mit dem Arbeitspaket AP9 eine verteilte Web-Service Plattform konzipiert, welche ein Management-Führungssystem umsetzt, indem es herkömmliche Bausoftwareanwendungen mit zentralen Plattformdiensten vernetzt.

Szenarioanalysen und Szenariomodellierung
Von den Forschungs- und Praxispartner wurden erste Szenarioanalysen durchgeführt, um erfolgskritische Arbeits- und Kommunikationsprozesse im Bauprojektmanagement bei AG und AN zu identifizieren, welche durch eine gezielte Neuorganisation und IT-Unterstützung verbessert werden können. Als repräsentative Anwendungsbereiche wurden dabei die Prozesse zur
- Ausschreibung, Angebotserstellung und Vergabe von Bauaufträgen,
- Durchführung von Ablaufsimulationen,
- Erstellung von Risikoprognosen,
- Ermittlung, Meldung und Kontrolle der Leistungserbringung,
- Nachträge durch eine Planungsänderung
ausgewählt.

Für die ausgewählten Anwendungsbereiche wurden im Arbeitspaket AP1 in Zusammenarbeit mit AP5, AP6, AP7, AP8 und AP9 konkrete Anwendungsszenarien für den Einsatz der Mefisto Plattform ausgearbeitet. Zum Einen wurden die einzelnen Arbeitsaufgaben von AG und AN weiter untersucht und zum Anderen die dabei erforderlichen Planungs- und Controlling-Informationen konkretisiert. In Zusammenarbeit mit den Arbeitspaketen AP2 und AP9 wurde hierfür ein Verfahren für die Szenariomodellierung mit „Szenariomatrizen“ auf der Grundlage der Szenariomatrix und der Information Delivery Manuals entwickelt mit dem nicht nur die jeweils erstellten Fachmodelle sondern auch ihre horizontalen, vertikale und longitudinalen Abhängigkeiten systematisch erfasst werden können.

Fachmodelle, Multi-Modelle und Multi-Modell-Container
Auf Basis der ersten Szenarioanalysen wurde untersucht, welches die wichtigsten Planungs- und Controlling-Informationen für das partnerschaftliche Bauprojektmanagement sowie für die Bauablauf- und Risikosimulation sind. Hierfür wurden zunächst eine Reihe Modelldomänen unterschieden, um die Fachmodelle mit unterschiedlichen Projektinformationen wie z.B. Bauwerksmodelle, Baustellenpläne, Leistungsverzeichnisse oder Terminpläne systematisch zu erfassen.
Für die Nutzung von Projektinformationen aus mehreren Fachmodellen gleicher oder unter-schiedlicher Domänen wurde das Konzept des Multi-Modells entwickelt. Ein Multi-Modell stellt einen Verbund eigenständiger Fachmodelle dar, die durch ein gesondertes Linkmodell verbunden werden. Multi-Modelle werden gezielt für bestimmte Anwendungsfälle erstellt, indem herkömmliche Fachmodelle kombiniert oder neue Fachmodelle auf der Basis beste-hender generiert werden. Für den Austausch der Multi-Modelle können die Fachmodelle ei-genständig in standardisierten oder nicht-standardisierten Formaten gespeichert und zu-sammen mit den entsprechenden Linkmodellen in einer Archivdatei – dem so genannten Multi-Modell-Container – ausgetauscht werden.
Als weitere Grundlage für die Kombination von Projektinformationen aus Fachmodellen un-terschiedlicher Domänen wurden drei Arten Modellinterdependenzen definiert: horizontale zwischen den Modellen unterschiedlicher Disziplinen und Formalisierungen, vertikale zwischen den Modellen gleichen Inhalts aber unterschiedlicher Abstraktionsstufe und longitudinale zwischen unterschiedlichen Versionen eines Modells.

Konzeption der Mefisto Plattform
Auf der Grundlage der Szenarioanalyse und des Multi-Modells wurde schließlich in Zusam-menarbeit mit dem Arbeitspaket AP9 eine Konzept für die Mefisto-Plattform entwickelt, bei dem herkömmliche Bausoftwareanwendungen, wie bspw. die Systeme der Projektpartner gibGreiner (GRANID), RIB (iTWO) und Solidpro (SolidWorks) durch Web-Service-Schnittstellen zu Anwendungsdiensten erweitert und über zentrale Plattformdienste vernetzt werde können. Im Folgenden wurde der erste Entwurf der Plattform insoweit verfeinert, als das die erforderlichen Funktionalitäten (1) für die Verwaltung der Plattformnutzer, Softwaredienste und Multi-Modelle (Informationslogistik), (2) für die Filterung und Transformation von Multi-Modellen (Multi-Modell-Management), (3) für die Visualisierung der Multi-Modelle sowie (4) für die Weiterverwendung der Multi-Modelle zur Simulation und Prozesssteuerung identifiziert und unterschiedlichen Anwendungs- und Plattformdiensten zugeordnet wurden.

Teilaufgaben des AP1

Anforderungen an das Gesamtsystem und Entwicklung der prinzipiellen Systemarchitektur

In der Anforderungsanalyse werden die grundlegenden Prozesse, Funktionen und Informationsinhalte aus Sicht der zwei kooperierenden Parteien Auftraggeber (Bauherr) und Auftragnehmer (Bauunternehmen als GU und NU) identifiziert, mit dem Ziel eine deutlich verbesserte Partnerschaft zu ermöglichen. Gemeinsam von den beteiligten Softwareherstellern, Bauunternehmen und Forschungspartnern werden die grundlegenden Anforderungen an die Datenstrukturen und Systemarchitektur definiert.

Bauontologiekern

Die erarbeiteten Anforderungen an die Metastruktur werden in einem Bauontologiekern modelliert und bezüglich der Umsetzbarkeit bzw. Erweiterbarkeit in vorhandenen praxisrelevanten Systemen überprüft und entsprechend angepasst. Der Ontologiekern muss dabei als Referenzmetamodell für alle domänenspezifische Metamodelle nutzbar sein, die grundlegenden Kern- und Metaobjektrelationen beinhalten sowie die Basis der Kommunikation im Gesamtsystem gewährleisten. Die Vielfalt der zu berücksichtigenden Informationen werden in dem Gesamtgeschäftsprozess auf höchster Ebene dargestellt, ohne dabei zu einem überfrachteten Globalmodell zu führen.

Hierarchisches Metamodellsystem

In dieser Teilaufgabe werden die prinzipiellen Modellierungsregeln und die Ontologiekonzepte für den hierarchischen Modellaufbau erarbeitet. Hauptaugenmerke liegen dabei auf der Spezifikation geeigneter Metakonstrukte als Grundlage für dynamische Modellübergänge sowie linguistischen Begriffsabgleichen.

Kernobjektmodelle

Es werden die Grundlagen für die im Projekt verwendeten spezifischen Kernobjektmodelle erarbeitet, die als Ontologien zu repräsentieren und möglichst modular aufzubauen sind. Die Modelle müssen voneinander unabhängig erweiterbar sein. Berücksichtigt wird die Anbindung an bestehende Bauwerksmodelle.

Implementierung des Mefisto-Kerns als SOA-System mit Basisservices

Die Implementierung des schlanken Kerns findet auf Basis des SOA-Konzepts statt. In Zusammenarbeit der Projektpartner werden die Schnittstellen der Komponenten spezifiziert und die zu entwickelnden Basisservices definiert. Die spezifizierten Schnittstellen-API dienen dabei als Implementierungsrichtlinie sowie als Integrationsgrundlage für die weiteren Entwicklungen, so dass die Realisierung des Gesamtprototypen reibungslos stattfinden kann. Das AP 1 bereitet somit den gemeinsamen Rahmen für alle weiteren Arbeiten in diesem Projekt.

AP-Leiter:

Logo RIB Information Technologies AG
RIB Information Technologies AG
Ein Unternehmen der RIB Gruppe
Kontakt:
Hans-Dieter Muntzinger
Vaihinger Str. 151
D-70567 Stuttgart

Tel.
+49 (0)711 787 32 46
Email:
Internet: