Berichtskolloquium Herrsching, Mai 2003 TU Dresden, Inst. für Computeranwendung im Bauwesen Weise, Katranuschkov 09. Mai 2003 Ein Kooperationsmodell für

Berichtskolloquium Herrsching, Mai 2003

TU Dresden, Inst. für Computeranwendung im Bauwesen Weise, Katranuschkov 09. Mai 2003

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Ein Kooperationsmodell Ein Kooperationsmodell für die Kontrolle divergierender für die Kontrolle divergierender

PlanungszuständePlanungszustände

Matthias WeiseMatthias WeiseTU Dresden, Lst. Computeranwendung im BauwesenTU Dresden, Lst. Computeranwendung im Bauwesen



ForschungsschwerpunktForschungsschwerpunkt

Ziel

• Unterstützung der asynchronen parallelen Projektbearbeitung unter Verwendung unterschiedlicher Datenmodelle

Schwerpunkte

• Modellsichten und Modelltransformationen

• Änderungsmanagement und Modellvergleich

• Zusammenführen divergierender Planungsstände



Forschungsarbeiten und Entwicklungen

• Verschiedene Projekte zum Themenkomplex des SPPs (Combi, Combine 2, ToCEE, Blis, GLOBEMEN, ...)

• STEP/IFC + Modellverwaltungssysteme (EDM, Eurostep, STEP Tools, Ecco Toolkit, IFC-Server, ...)

• Theorien/Methoden zu objektorientierten Modellen (deep compare, Syntaxbaumvergleich, ...)

Stand der Forschung und EntwicklungStand der Forschung und Entwicklung

Bisher: konzeptionelle Modelle + grundlegende Methoden

Offen: Managementmethoden + Verknüpfung von Produkt und Prozess, Konzepte zur Datenverwaltung



Stand der Forschung und EntwicklungStand der Forschung und Entwicklung

Spezielle Probleme

• Datenmodelle der „Wirklichkeit“ sind i.d.R. nicht auf Erfordernisse der Datenverwaltung optimiert

• Durchgehende Datenhaltung bei Zulassung temporär divergierender Datensätze (Merging)

• Skalierbarkeit der Lösungen - Modellierungskonzept- Modellgröße- Datenumfang



LösungsansatzLösungsansatz

T2T1

Planungsfortschritt

Koordinationspunkt

T0 T1 TN

Prozessphase

T2

IFC2x2-Modell G 2.2merged

IFC2x2-Modell G 1

Nutzungs-änderung für Raum 5.11

Tragwerksplaner SOFiSTiK SlabDesigner Modell: IFC2x2 (ST-View)

TGA-Planer Olof Granlund RIUSKA Modell: IFC2.0 (HVAC-View)

IFC2x2-Modell G 2.1merged

Partialmodell TW 2

Nachrechnung der neuen Lasten

Partialmodell TGA 2

Lüftungsdimensionierung

Teilmengenbildung/Teilmengenbildung/

ModelltransformationModelltransformation

ModellvergleichModellvergleich

ModellvereinigungModellvereinigung

Partialmodell TGA 1

Partialmodell TW 1



T2T1

Arbeitsbereich des TGA-Planers

TGA-Planer Olof Granlund RIUSKA Modell: IFC2.0

(HVAC-View)

Lösungsansatz - Verteilte Modelle Lösungsansatz - Verteilte Modelle

Arbeitsbereich des Tragwerksplaners

Tragwerksplaner SOFiSTiK SlabDesigner Modell: IFC2x2

(Structural-View)

Datenverwaltung Projekt-DatenserverModell: IFC2x2

(Gesamtmodell)



...

IfcStructuralPlanarAction

Lösungsansatz - Konsistenz Lösungsansatz - Konsistenz

Konsistenzsicherung:• Syntaktische + semantische Konsistenz auf der Basis der

Modell-Definition durch Datenverwaltung

• Semantik + Inhalt durch Werkzeuge zur Modellverifikation (Solibri Model Checker, CORENET project, ...)

• Änderungszustimmung durch anderer Fachplaner

W4.2

S4.12

S4.13

S4.14

Tragwerksplaner Architekt TGA

WD(L)

R5.11

W5.2

S5.14

S5.13

S5.12

D4.3

AD5.11

L5.8

W4.2

S4.12

S4.13

S4.14

Tragwerksplaner Architekt TGA

WD(L)

R5.11

W5.2

S5.14

S5.13

S5.12

D4.3

AD5.11

L5.8

Abhängigkeiten auf Ingenieurontologie

Abhängigkeiten auf Ingenieurontologie

IfcStructuralFaceMember

IfcRelAssignsToStructuralMembers

IfcRelConnectsStructuralActivity

IfcSlab D 4.3

IfcSpace R 5.11 IfcHeatTransferDevice L 5.8

Verknüpfung der Datenstruktur

Verknüpfung der Datenstruktur



Lösungsansatz - Produktmodell Lösungsansatz - Produktmodell

Datenmodell - IFC-Modell als Anwendungsziel • Harmonisiertes Projektmodell für das Bauwesen

- "wesentliche" Daten unterschiedlicher Fachbereiche sind abbildbar Verwendung als "Kernmodell", das zu unterschiedlichen Fachmodellen

transformiert werden kann • Für Datenverwaltung nicht optimal geeignet

- Beschreibungsvielfalt- nicht jedes Objekt besitzt eine Objekt-ID

Modellbeschreibungssprache - EXPRESS

• Standardisierte Modellbeschreibungssprache, die zur Abbildung unterschiedlicher Datenmodelle genutzt wird



Lösungsansatz - kooperative Bearbeitung Lösungsansatz - kooperative Bearbeitung

Kooperationsstrategie

• Optimistische Kooperationsstrategie auf der Basis einer Versionsverwaltung (keine Einbringsperren)

• Eingebrachte Änderungen (Vorschläge) werden durch die Zustimmung von "Verantwortlichen" (rechts-)wirksam asynchroner Vorschlag-Zustimmungs-Zyklus

• Steuerung der Vorgänge erfolgt über Prozesskoordinierunga) Projektsteuererb) Ableitung der Verantwortlichkeit aus der Entstehungsgeschichte



Zwischenergebnisse - ModellvergleichZwischenergebnisse - Modellvergleich

Konzeptionelle Trennung in:• Generischer Modellvergleich auf Basis der

Datenstruktur

• Inhaltlicher Vergleich der strukturellen Differenzen

• Aufbereitung der Ergebnisse für das Zusammenführen Konfiguration der Teillösungen zu einem modellabhängigen Vergleichsprozess

PMV1

PMV2 Preprozessor Deltavergleich

GenerischerVergleich

Merging

Objekt-ID=?...

Plugin Pre-proz. IFC2x

Anwendung Delta-IFC

KonfigurierenVerwendung von

Objekt- und Differenzmengen

Verwendung von Objekt- und

Differenzmengen

?

Teilmengen



TeilmengenbildungTeilmengenbildung

Teilmengenspezifikation

• Regeln für die Teilmengenbildung

• Information für das Zusammenführen

DefinesFeatureSubset S[1:?]

PartialModelQuery

SelectedObjectSets S [1:?]

QuerySetSelect ViewDefinitionSelect

. . . . . .

1

2

‘al l -em b racin g’p rod u ct d ata

m od el

sel ectedd ata ob jects

w i th referen cesto u n n eed edd ata ob jects

red u ced conten t w i th al l n ecessary d ata

1 2S electi on of d ata ob jects u sin g a recu rsiv e u ti l i z ab l e Q uery SetSelect

A d j u st th e d ata con ten t o f th e sel ected ob j ects

1 2

GMSD



Struktureller ModellvergleichStruktureller Modellvergleich

• Bei partiell vorhandenen Objekt-IDs: Idee des „Syntax(baum)vergleichs“ + Deep Compare - über Wichtung der Strukturinformationen (1:1, 1:n -> List, Set, Bag)

und der Baumtiefe heuristische Regeln - kombinierter inkrementeller Algorithmus bestehend aus:

a) Objektvergleichb) Auffinden und Herstellen von Versionsbeziehungen

Vorgehensweise

• Bei unverknüpften Objektmengen: Vergleich/Zuordnung auf Basis der Attributbelegung- über „flache“ und „tiefe“ Hashcodes



IfcRectangle...

IfcRectangle...IfcRectangle...

IfcRectangle...

IfcWall15

IfcWall15

IfcLocalPlacement

IfcLocalPlacement

IfcLocalPlacement


Problemstellungen:

IfcWall14 IfcWallStandardCase14

IfcRectangle... IfcPolyline

Objektevolution Objektevolution

Kardinalität von Versionsbeziehungen

Kardinalität von Versionsbeziehungen

BeschreibungsvielfaltBeschreibungsvielfalt

Zuordnung von Objektmengen

Zuordnung von Objektmengen




Tests mit IFC 1.5.1 (ca. 10000 Datenobjekte)(ca. 50% der IFC-Entities besitzen laut Definition eine Objekt-ID

ca. 20% der Instanzen eines konkreten Modells)

vollständige Erkennung der Versionsbeziehungen und Differenzen

Probleme hinsichtlich Erkennung, Stabilität und Skalierbarkeit bei großen Objektmengen

Erfahrungen:

Ausblick: Stabilität und Optimierung der Qualität und Rechenzeit

Konfiguration von Vergleichsprozessen für Anwendungsbeispiele

modellabhängiger Preprozessor und inhaltlicher Vergleich (IFC2x)

Berichtskolloquium Herrsching, Mai 2003



EndeEnde



AusblickAusblick

Anwendungsmöglichkeiten: Modelltransformation zu einem Referenzmodell (Normalisierung)

Modelltransformation zu Ingenieurontologie um Objektselektion

durchzuführen

Einsatz in einer Peer to Peer - Umgebung



PartialmodellerzeugungPartialmodellerzeugung



Problematik: Mapping zu semantisch reicheren ModellenProblematik: Mapping zu semantisch reicheren Modellen

T2T1

Planungsfortschritt

Koordinationspunkt

T0 T1 TN

Prozessphase

T2

IFC2x2-Modell G 2merged

Partialmodell TW 2

Partialmodell TW 1.1

IFC2x2-Modell G 1

Partialmodell TW 1.0




• Zulässige Kardinalität einer Versionsbeziehung (object sharing)

Problemstellungen:

IfcPoint1

IfcPoint2

IfcPoint3

• Objektevolution IfcWall14 IfcWallStandardCase14

• Beschreibungsvielfalt

rectangle = = polyline

Documents

Berichtskolloquium Herrsching, Mai 2003 TU Dresden, Inst. für Computeranwendung im Bauwesen Weise, Katranuschkov 09. Mai 2003 Ein Kooperationsmodell für