Introduction:
Building
Information Modelling is, in the field of the construction industry, an
approach to build semantically-rich 3-dimensional digital models instead of
“plain old” CAD models to fulfill different needs of different stakeholders.
The
most widely used standard for exchanging BIM models in the industry is defined by the
Industry Foundation Classes (IFC). IFC is a standardized data model developed
by different domain experts to enable interoperability within the Architecture, Engineering,
Construction and Facility Management industries.
Problem Description:
Using IFC
software products in research as well as in real projects presents certain challenges – it’s complex, hard to understand for the users and has some
consistency issues during import and export of real-world building data.
Many of
above mentioned issues can be addressed by transforming this IFC metamodel
into a smaller, easier to understand and use model, as an instance of a common
linguistic meta-model, such as Ecore. The advantage of an Ecore model is not
only a new class diagram, but rather the ability to use a very broad set of
Ecore functionalities, such as code, entity and api generation, as well as the
ability to check models regarding their syntactical and semantical correctness.
Our project,
the transformation to the Ecore Model is a part (step 2) of the bigger picture shown below
The bigger pictur |
We used the Atlas Transformation Language (ATL) for this transformation.
IFC Structure:
In general, the IFC specification consists of four different Declaration types:
- Type Declarations
- Entity Declarations
- Function Declarations
- Rule Declarations
We focused on the transformation of Type and Entity Declarations and handled the rest as simple EClass “name-only” stubs.
- an Enumeration
- a primitive (String, Integer, Real, Boolean) - aka Concrete Type
- a selector of entites of types - aka Select Types
Entity Declarations are similar to the term "class", and describe data structures. They are built in the following way (in the express notation)
ENTITY (*Name*)
ABSTRACT SUPERTYPE OF (*Classes*);
SUBTYPE OF (*Classes*);
(*Declarations*);
END_ENTITY;
Methodology:
The transformation will be shown using the example of the "IFCActuator" entity. The result of this transformation to Ecore looks the following:
IFCActuator |
Type Declarations
In this section we transform the three different types of Type Declarations.
As you can see on the upper left side, the IFC Actuator contains some enumerations of type "IFCActuatorTypeEnum". Basically they are transformed to an EEnum using the following rule:
In Ecore an EEnum needs a name, which we transform by adding the corresponding IFC!Enum's classname, aswell as a value, which is incremented by 1 for every added Enumeration.
Concrete Types:
Simple Types (for example String) are needed to be converted very often and are realized via helper functions.
Select Types:
Select Types are converted to eClasses with eAttributes or eReferences, or both, depending on the types declared in the "select_list.named_types", as shown below:
Select Type Transformation Rule |
Entity Declarations:
Entities (for example the upper middle IFCActuator entity) are transformed to an EClass, containing a name, some eStructuralFeatures (for example attributes) aswell as an eSuperType for inheritance.
Entity Transformation Rule |
There are many different rules for transforming eStructuralFeatures, depending on the complexity of the underlying type, but in the most simple case, like in the IFCActuator the "PredefinedType", which is an IFC!AttributeSimple, the transformation rule looks the follwoing:
Relations & Aggregations:
Relations between entities (for example between IFCElement and IFCIdentifier), as well as aggregations are realized with the EReference class - below there is a transformation rule for a simple case:
Relations and Aggregation Transformation Rule |
OCL-Annotations:
In IFC some parts that cannot be transformed to ECore. For example, there is a type declaration called IFCGloballyUniqueId, containing a String with a length that of exactly 22 characters.
TYPE IfcGloballyUniqueId = STRING(22) FIXED;
END_TYPE;
END_TYPE;
We handle this logic using additional OCL Annotations.
|
Results:
The transformation of the Express DML metamodell into the Ecore model is successful. The transformation of the whole IFC4.isoexpall model takes between 0.5 and 2 seconds. There are no missing entities and no errors or warnings in ATL. The resulting target model is a syntactical valid Ecore model.
Next Steps:
Even if the target model has no errors it’s not guaranteed that the model to model transformation is actually valid - ATL doesn’t offer this kind of checking-feature. Therefore the validity of the transformation still needed to be proven.
No comments:
Post a Comment