11
Arbeitgruppentreffen Weimar, März 2004 TU Dresden, Institut für Bauinformatik Weise 18. März 2004 Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände Ein Kooperationsmodell Ein Kooperationsmodell für die Kontrolle divergierender für die Kontrolle divergierender Planungszustände Planungszustände − Strukturelle und inhaltliche − Strukturelle und inhaltliche Vergleichsmethoden – Vergleichsmethoden – Matthias Weise Matthias Weise TU Dresden, Institut für Bauinformatik TU Dresden, Institut für Bauinformatik

Lösungsansatz (idealisiert)

  • Upload
    kaden

  • View
    20

  • Download
    0

Embed Size (px)

DESCRIPTION

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände − Strukturelle und inhaltliche Vergleichsmethoden – Matthias Weise TU Dresden, Institut für Bauinformatik. Lösungsansatz (idealisiert). Prozessphase. Koordinationspunkt. T 2. T 0. T 1. T N. - PowerPoint PPT Presentation

Citation preview

Page 1: Lösungsansatz (idealisiert)

Arbeitgruppentreffen Weimar, März 2004

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

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

− Strukturelle und inhaltliche Vergleichsmethoden –− Strukturelle und inhaltliche Vergleichsmethoden –

Matthias WeiseMatthias WeiseTU Dresden, Institut für BauinformatikTU Dresden, Institut für Bauinformatik

Page 2: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Lösungsansatz (idealisiert)Lösungsansatz (idealisiert)

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

Page 3: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Lösungsansatz - VariationenLösungsansatz - Variationen

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

Page 4: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Grundlagen:

• Modellbeschreibungssprache EXPRESS

• Nutzung vorhandener Produktdatenmodelle (IFC, PSS, OKSTRA, STEP-CDS, CIMSTEEL, ...)

• Validierung der Konzepte an verfügbaren Implementierungen (ArchiCAD, Allplan, ADT, ...)

LösungsansatzLösungsansatz

Ziel:

• Wiederverwendbare, generische Methoden zur Unterstützung sinnvoller Szenarien

Page 5: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

ModellvergleichModellvergleich

Ansatz:• Auswertung der Objektbeziehungen zur Bestimmung von

Objektversionen -> struktureller Vergleichsalgorithmus

• Arbeit mit einer definierten Objekt- und Attributmenge -> Generalised Model Subset Definition Schema (GMSD)

• Ergänzung um modellabhängigen Präpozessor (Mapping)

• Nutzerinteraktion zur Bewertung von Änderungen

Probleme:

• Objektidentifizierung

• Datenverlust durch Anwendungen

• Beschreibungsvielfalt

Page 6: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

ModellvergleichModellvergleich

Umsetzung:

L ad en einer T ei lm engefü r d ie B earbeitu n g

Bearbeitu n g d er T ei lm en ge

Z u sam m en fü h renz u ein em G esam tm od ell

321

C .1P.1

1 3

=

2P.2

C .3

+

G M S D Fi l ter S p ez ifi k ati on

P o stp ro zessor

+

G M S D Fi l ter S p ez ifi k ati on

P rep ro z essor

+

Problem der Objektzuordnung

Problem der Objektzuordnung

Problem der Konsistenz

Problem der Konsistenz

Page 7: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Modellvergleich - ErgebnisseModellvergleich - Ergebnisse

Ergebnis:• Qualität abhängig von strukturellen Veränderungen

(sehr gute Erkennungsrate bei geringen Differenzen)

• Vergleich gut skalierbar

Validierung für:

• IFC2x- Modellgröße bis 230000 Datenobjekte- Kombination mit GMSD-Filter für ArchiCAD- ID-Anteil: zwischen 5 und 0,1%

• Produktschnittstelle Stahlbau- 225 Objekte, ID-Anteil zwischen 28 und 7%

Page 8: Lösungsansatz (idealisiert)

Arbeitgruppentreffen Weimar, März 2004

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

EndeEnde

Page 9: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

AusblickAusblick

Anwendungsmöglichkeiten: Modelltransformation zu einem Referenzmodell (Normalisierung)

Modelltransformation zu Ingenieurontologie um Objektselektion

durchzuführen

Page 10: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

PartialmodellerzeugungPartialmodellerzeugung

Page 11: Lösungsansatz (idealisiert)

TU Dresden, Institut für Bauinformatik Weise 18. März 2004

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände

Struktureller ModellvergleichStruktureller Modellvergleich

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

Problemstellungen:

IfcPoint1

IfcPoint2

IfcPoint3

• Objektevolution IfcWall14 IfcWallStandardCase14

• Beschreibungsvielfalt

rectangle = = polyline