1 / 19

Forschungsschwerpunkt

Ein Kooperationsmodell für die Kontrolle divergierender Planungszustände Matthias Weise TU Dresden, Lst. Computeranwendung im Bauwesen. Forschungsschwerpunkt. Ziel Unterstützung der asynchronen parallelen Projektbearbeitung unter Verwendung unterschiedlicher Datenmodelle. Schwerpunkte

tuvya
Download Presentation

Forschungsschwerpunkt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Ein Kooperationsmodell für die Kontrolle divergierender PlanungszuständeMatthias WeiseTU Dresden, Lst. Computeranwendung im Bauwesen

  2. Forschungsschwerpunkt Ziel • Unterstützung der asynchronen parallelen Projektbearbeitung unter Verwendung unterschiedlicher Datenmodelle • Schwerpunkte • Modellsichten und Modelltransformationen • Änderungsmanagement und Modellvergleich • Zusammenführen divergierender Planungsstände

  3. Stand der Forschung und Entwicklung • 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, ...) Bisher: konzeptionelle Modelle + grundlegende Methoden Offen: Managementmethoden + Verknüpfung von Produkt und Prozess, Konzepte zur Datenverwaltung

  4. Stand 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

  5. Lösungsansatz Prozessphase Koordinationspunkt T2 T0 T1 TN Tragwerksplaner SOFiSTiK SlabDesigner Modell: IFC2x2 (ST-View) Partialmodell TW 2 Partialmodell TW 1 Nachrechnung der neuen Lasten Nutzungs-änderung für Raum 5.11 IFC2x2-Modell G2.1merged IFC2x2-Modell G2.2merged IFC2x2-Modell G1 T1 T2 Lüftungsdimensionierung TGA-Planer Olof Granlund RIUSKA Modell: IFC2.0 (HVAC-View) Partialmodell TGA 1 Partialmodell TGA 2 Planungsfortschritt     Teilmengenbildung/Modelltransformation   Modellvergleich Modellvereinigung

  6. Lösungsansatz - Verteilte Modelle Tragwerksplaner SOFiSTiK SlabDesigner Modell: IFC2x2 (Structural-View) Arbeitsbereich des Tragwerksplaners T1 T2 Arbeitsbereich des TGA-Planers TGA-Planer Olof Granlund RIUSKA Modell: IFC2.0 (HVAC-View) Datenverwaltung Projekt-DatenserverModell: IFC2x2 (Gesamtmodell)

  7. Lösungsansatz - Konsistenz Architekt Architekt TGA TGA Tragwerksplaner Tragwerksplaner ... IfcHeatTransferDevice L 5.8 IfcSpace R 5.11 S S S S S S W W WD WD 5.12 5.12 5.14 5.14 5.13 5.13 5.2 5.2 (L) (L) IfcStructuralPlanarAction IfcRelConnectsStructuralActivity D D R R L L 5.11 5.11 IfcStructuralFaceMember 4.3 4.3 5.8 5.8 IfcRelAssignsToStructuralMembers S S S S S S W W AD AD IfcSlab D 4.3 4.13 4.13 4.14 4.14 4.12 4.12 4.2 4.2 5.11 5.11 Abhängigkeiten auf Ingenieurontologie Verknüpfung der Datenstruktur • 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

  8. 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

  9. 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

  10. Zwischenergebnisse - Modellvergleich Teilmengen    Preprozessor GenerischerVergleich Deltavergleich Merging Plugin Pre- proz. IFC2x Objekt-ID=?... Anwendung Delta-IFC Konfigurieren • 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 Verwendung von Objekt- und Differenzmengen

  11. Teilmengenbildung GMSD Teilmengenspezifikation • Regeln für die Teilmengenbildung • Information für das Zusammenführen

  12. Struktureller Modellvergleich Vorgehensweise • 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) Objektvergleich b) Auffinden und Herstellen von Versionsbeziehungen • Bei unverknüpften Objektmengen:  Vergleich/Zuordnung auf Basis der Attributbelegung- über „flache“ und „tiefe“ Hashcodes

  13. Struktureller Modellvergleich IfcWall15 IfcWall15 IfcLocalPlacement IfcLocalPlacement IfcLocalPlacement IfcRectangle... IfcRectangle... IfcRectangle... IfcRectangle... IfcPolyline IfcRectangle... Problemstellungen: Objektevolution IfcWall14 IfcWallStandardCase14 Kardinalität von Versionsbeziehungen Zuordnung von Objektmengen Beschreibungsvielfalt

  14. Struktureller Modellvergleich Ausblick:  Stabilität und Optimierung der Qualität und Rechenzeit  Konfiguration von Vergleichsprozessen für Anwendungsbeispiele  modellabhängiger Preprozessor und inhaltlicher Vergleich (IFC2x) Erfahrungen: 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

  15. Ende

  16. Ausblick Anwendungsmöglichkeiten:  Modelltransformation zu einem Referenzmodell (Normalisierung)  Modelltransformation zu Ingenieurontologie um Objektselektion durchzuführen  Einsatz in einer Peer to Peer - Umgebung

  17. Partialmodellerzeugung

  18. Problematik: Mapping zu semantisch reicheren Modellen Prozessphase Koordinationspunkt T2 T0 T1 TN Partialmodell TW 1.0 Partialmodell TW 2 Partialmodell TW 1.1 IFC2x2-Modell G2merged IFC2x2-Modell G1 T1 T2 Planungsfortschritt

  19. Struktureller Modellvergleich Problemstellungen: • Zulässige Kardinalität einer Versionsbeziehung (object sharing) IfcPoint2 IfcPoint1 IfcPoint3 • Objektevolution IfcWall14 IfcWallStandardCase14 • Beschreibungsvielfalt rectangle = = polyline

More Related