A Generic Approach to the Mapping Problems in Cooperative Design

1. Presentation at ICE 2001Bremen, Germany, June 2001 A Generic Approach to the Mapping Problems in Cooperative Design U. Wagner, Dr. P. Katranuschkov, Prof. Dr. R. J. SchererTU Dresden, Germany

2. Overview • The Problem Domain • The Model Mapping Approach • The Mapping System • Mapping language • Mapping language parser • Implementation of the mapping engine • Example • Conclusion

3. The Problem Domain • There are several differences b/n Building Construction and other industries : • Lower profits, lower IT investment • Lack of large key organisations as technology drivers • Complex supply and communication chains • Therefore:Concurrent engineering & cooperative design have to deal withcomplex model transformations in a distributed non homogeneous model world • Such transformations may be needed e.g. for: • Data exchange between major CAD-Applications • Generation of views (presentation, documentation, pre- and post-processing) • Coordinated change management • Extracting of management information for control and monitoring etc.

4. The Problem Domain Architect Architect CivilEngineer StructuralEngineer CivilEngineer StructuralEngineer SHAREDPROJECTMODEL BuildingOwner HVACEngineer BuildingOwner HVACEngineer FacilitiesManager ControlsEngineer FacilitiesManager ControlsEngineer Constr.Manager Constr.Manager The IAI Vision of Interoperability Not fully sufficient Not fully sufficient are also all known database integration approaches

5. The Model Mapping Approach Background: • Underlying product modelling framework (IFC) • Non fully harmonised domain / application models • Distributed, a-priori non coordinated data • Distributed C/S architecture with underlying shared data repository Note: Mapping is an alternative to full harmonisation/integration methods But: Model mapping supports and does not contradict to integration! Principal approach:  Consolidation of the project data only at discrete co-ordination points

6. The Model Mapping Approach process phase coordination point T0 T1 TN design changes Arch. Model A1 MAPPING MAPPING models are semantically equivalent models are diff. T1 T0 design changes Struct. Model S1local Merging Matching Arch. Model A0 S1map(A1) Struct. Model S1merged Struct. Model S 0map(A0)

7. The Mapping System • A mapping language - CSML • A generic parser - MaLaPaG • Explicit public operations enabling distributed C/S realisations • A set of implementation methods comprising the interoperability engine(server-side object-oriented methods based on set theory)

8. Characteristics of CSML • Declarative language • Mapping of two (full or partial) models • Context-free grammar • Recursively specified  the rules are directly realizable • Predefined mapping patterns for typical problemson class, instance and attribute level • Better suited to real-time distributed systems than EXPRESS-X • Less suited for model evolution and model migration • Still under development …

9. The Generic Parser (MaLaPaG) • Basically, instead of developing parsing rules for all language constructs, the language itself is used as input in the parser • More difficult to realize than a static parser • But: applicable for a class of similar languages • Easy to modify by changes in the language specification • Static vs. Generic Parser: • Static Parser: • statically integrated rules • designed for a specific language • low development effort • high maintenance effort • Generic Parser: • rules are externally stored • suitable for different languages • high development effort • low maintenance effort

10. Hashing the Rule Map

11. Implementation of the Mapping Engine • Input data sets: • The source and target schemas in EXPRESS • The source model data • The CSML specification providing the mapping rules for the translation of the source model data into the target model data • Processing: • Parsing of the EXPRESS schemas • Parsing of the CSML specification • Recursive generation of the source & target data sets • Compressing the target data by eliminating redundancies • Output data set: • The target model data e.g. in the form of a STEP exchange file or as a XML document (see ifcXML)

12. Example Mapping Specification: (MAP local_model FROM shared_model CLASSES ( MAP CLASS circ FROM circle ATTRIBUTES (SAME centre) (MAKE diameter FROM radius APPLY (LAMBDA (X) (* X 2.0)))) DEPENDENT-CLASSES (MAP CLASS point FROM point ATTRIBUTES (SAME x_coord y_coord z_coord AS x y z) ) )

13. Parser Tree for the Example MAP : local_model FROM : shared_model DEPENDENT- CLASSES CLASSES MAP CLASS: circ MAP CLASS: point FROM : circle FROM : point ATTRIBUTES ATTRIBUTES SAME : x_coord y_coord z_coord MAKE : diameter SAME: centre AS x y z FROM : radius APPLY : (LAMBDA (X) (* X 2.0)) Schema mapping Class mapping Leaf nodesAttr. mappings

14. Conclusions • The modular mapping system provides greatest freedom for independent, parallel design work • The integration of a generic parser provides a high level of flexibility enabling easy re-adjustment of the environment • As a whole, the presented approach fulfils major interoperability requirements of a concurrent engineering environment in building design