[Building Information Modeling] IFC to Ecore Transformation

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. 

Type Declarations are similar to "typedef" or "value type" in common programming languages, and refer to a basic information construct, derived from: 

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

Enumerations:

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. 

Enumeration Transformation Rule

Concrete Types:

Simple Types (for example String) are needed to be converted very often and are realized via helper functions. 

Simple Type Transformation Rule

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: 

Simple Attribute Transformation Rule

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;

We handle this logic using additional OCL Annotations.

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.