Friday, June 30, 2017

Building IFC metamodel

by Benjamin KIRINDI-HENTSCHEL, Berwan YILDIZ, and Ünzüle KIRINDI-HENTSCHEL

Introduction and problem description

At the beginning of a construction project, the architect's design is based on the wishes of the client as well as on existing laws and regulations. The technical construction and design drawings required for the execution are produced with the aid of CAD systems. The necessary construction work, the bill of quantities and the cost estimations are subsequently determined based on those.
If there are changes in the design, the drawings and calculations concerning, for example, the structural design or the MEP (mechanical, electrical, plumbing) and HVAC (heating, ventilation, air conditioning) - have to be adjusted. In classical building design such adjustments cause a great deal of work and coordination overhead. The stated goal of Building Information Modeling (BIM) is to reduce the above mentioned workload.

The Industry Foundation Classes (IFC) are the implementation specification for the Building Information Modeling standard. They enable data exchange between different software applications of multiple stakeholders in the architecture, engineering and construction (AEC) industries working together throughout the life cycle of a building.

However, since the IFC-Standard is developed by many different domain experts with varying objectives, the standard has grown in complexity over the years, which places restrictions on its extensibility. For these reasons implementations of the standard are time-consuming and not always round-trip-capable in different existing software.

The aim of this project is to build a meta-model for a simplified and more object oriented approach of IFC, which enables extensibility and flexibility. Our model structure should allow an efficient integration of new knowledge and new products in the standard.

Methodology

In this section we will discuss the steps necessary to create a representative meta-model of the IFC standard using the Eclipse Modeling Framework (EMF).
For the first step (building the meta-model) we chose a small subset of types from the Shared Building Elements module for the definition of a closed space (e.g. a room). The chosen subset of the standard is a good representation of the concepts typical of IFC, because the IfcWall type is a complete product model as well as a fundamental part of a building and has most common functionality and properties of a building element.
  • IFC Documentation - Research
    To ensure that the existing technology is utilized to its fullest potential its purpose and usage have to be analyzed and compared to other existing standards.

  • Development of a Class diagram
    The complexity of IFC made the creation of a representative class diagram necessary before starting with the meta-model development. The class diagram provides a graphical representation of entities, abstract classes, their relationships and attributes. The main purpose of the class diagram was to aid in the selection of relevant entities and references for the type IfcWall and to determine which ones are insignificant enough to ignore.

  • Object oriented approach
    The next step is one of the most important steps in the object oriented approach. The fact that IFC is mainly developed by stakeholders such as building and mechanical engineers leaves a software engineer a lot of space for structuring the complex system with a more comprehensive abstraction.

    This means that typical paradigms like classification and inheritance are used to reduce redundancy and duplication of data and attributes, but also for re-usability and extensibility.

    In modeling technology it is common to use design patterns. IFC has utilized multiple design patterns in its specification, some of them producing sub-optimal artefacts. These were analyzed and alternative implementations were designed. One of them is the Type-Object Pattern. This pattern allows an object to be associated with a dynamic object type and, consequently, an object instance to be linked with a particular object type instance. This approach leads to lack of static type safety.

    For this reason the pattern was redesigned using classification. This results in the following structure: The common properties associated with the type IfcWall (residing in the domain type layer) can be made binding by the fact that it is an instance of IfcWallType in the domain meta-type layer. IfcWallType can be seen in the following figure. As the type of both IfcWallStandardCase and IfcWallCollapsibleCase it can enforce the presence of any desired attributes.

Figure 1. on the right: the type-object pattern, on the left: its redesign

  • Development of the meta-model
    Through the process of analysis and simplification five main concepts were selected as basis for the meta-model of type IfcWall:
    – Geometry
    – Material Layer
    – Path Connectivity
    – Local Placement
    – Properties and Quantities

    The next figure shows the root diagram of the meta-model, where the IfcWallType has references to all maintained concepts described above. IfcWallType is the type of IfcWall. Consequently it enforces the references to all types that describe the concepts defining a IfcWall.

Figure 2. The class diagram of the domain meta-types relevant for IfcWall.

  • Testing
    The domain classes such as IfcWall from the Shared Layer of IFC can now simply be instantiated from the newly developed domain meta-classes. As proof of the semantic equivalence of the generated model and the IFC model of IfcWall serves the comparison between the instances they produce. Those are based on an example contained in the IFC documentation on the buildingSmart website. Both semantic and quantitative metrics were used (e.g. number of objects and links).

Results

The comparison between the instances of the new model instantiated from our meta-model and the IFC standard model in the Testing section shows that instances of IfcWall differ in number of objects and links. However, semantically both instances are effectively the same.

The meta-model has the following advantages and improvements over the IFC standard:
  • Readability and Comprehensibility
    The replacement of complex design patterns with classification resulted in fewer associations and reduction of attributes in the instantiated model. This makes it easier to read and comprehend than the standard IFC model. The reduction in complexity is also facilitated by the redesign of the objectified relationships typical of the standard.
  • Extensibility
    The redesign of the type-object pattern allows the definition of type properties in the domain meta-type layer. An immediate consequence of that is that the number of available wall types can be extended. As demonstrated in the Figure 1, a new type of wall (not present in the current IFC standard) can be created in the domain type layer: The IfcCollapsableWall type represents a wall that can be collapsed. The definition of properties which describe the collapsing behavior is enforced by the type-instance relationship.
  • Type-Safety
    The IFC standard is not type-safe because of type-to-object linking at instance level, as shown on the right side of Figure 1. The multi-level modeling paradigm removes this weakness by using the instantiating capabilities of the object-oriented development approach.

Thursday, June 29, 2017

SysML2Python Code Generation

By Markus Schäffer and Matthias Bauer

Introduction

The Object Management Group's (OMG) Systems Modelling Language (OMG SysML) can be used to describe various kind of systems. After modelling a system, one scenario is that software engineers use these models to write any form of software. For example, software experts may write code for a system that has to be developed. Another scenario is that one wants to simulate the system, e.g., to learn something about its implications. When starting to write code, soon the problem arises how to reuse the work done in the modelling phase. One possible way are Model-to-Text transformations. Model-to-Text transformations, as a part of Model Driven Software Engineering (MDSE), enable to generate code from models. Thus one can save time in the development phase, since software engineers do not have to start writing code from scratch.
Hence, to address the problem of reusing SysML models for further work, a model driven code generation approach was used in this work. In particular, a code generator is proposed to translate different SysML diagram kinds into respective Python code. This code generator relies on the Eclipse Modelling Framework (EMF) and the SysML implementation of the UML and SysML modelling tool Papyrus. In order to show the practical usage of the code generator an example of a coffee machine serves as an input for our SysML2Python code generator. As a result with the SysML2Python code generator, we were able to successfully generate Python code out of our supported SysML diagram types. These supported diagram types are the Block Definition Diagram (BDD), Internal Block Diagram (IBD) and Parametric Diagram (PAR).

SysML Diagram Types (dark blue: Supported by SysML2Python Code Generator)

   Used Technology

  • Python, which is an universally applicable, object-oriented interpreter for high-level programming
  • Object Management Group (OMG) Systems Modelling Language (OMG SysML), which is a general-purpose language for systems engineering applications
  • Xtend, which is a programming language and was used to write the SysML2Python code generator
  • Papyrus, which is a tool for graphical modelling of UML, SysML and other modelling languages

Implementation

Our SysML2Python code generator takes an .uml file as input file, which holds the SysML Features attached with Stereotypes in form of a tree, and generates one Python module as output file.
In Papyrus, the information of the modelled system is represented in a single file, regardless of the number of actual modelled diagrams. For example, in case of an Internal Block Diagram the information of its own and its base the Block Definition diagram is stored in a single .uml. This file serves as input for the code generator.
The code generator generates one output file (the Python module of the .uml file). The main reason for a single file is that the generated code can easily be imported by another Python program. For each element in the .uml file the type of the element is queried first (via use of the instanceof operator). Then, the corresponding method is invoked, which holds the individual structure for each type. The next code snippet shows this structure. The polymorphic generateElement method invokes the corresponding method of the type of the actual element (see line 5 in the next code snippet).

fsa.generateFile('''<<ModelName>>.py''', '''
"""GENERATED BLOCKS"""
<<FOR EObject obj : root.eContents>>
    <<IF obj instanceof org.eclipse.uml2.uml.Class>>
        <<generateElement(obj)>>
    <<ENDIF>>
<<ENDFOR>>
''')

Conclusion and Future Work

The objective of this project was to generate Python code from SysML Block Definition-, Internal Block- and Parametric Diagrams. The proposed solution called 'SysML2Python Code Generator', which uses the Eclipse Modelling Framework, Xtend and Papyrus. allows to generate code from .uml files that contain a SysML model. The generated code can easily be imported by other Python applications and has great potential to be used as a basis for further programs. A specially interesting application would be to use the generated code as a base for simulations of SysML models. Nevertheless, further study on generating code from SysML equations is needed to address the issue of using more complex equations in parametric diagrams (e.g. to have built-in functionality to simulate the behaviour of the system over time).

Visual Profiling of Entity Models

Intro
Using models is a powerful strategy for understanding concepts, that would otherwise be hard to grasp. With models, it is possible to provide an intuitive level of abstraction for a magnitude of engineering tasks. For this reason, in Model Driven Engineering, models are even seen as an integral approach to creating systems, not only to understanding them. However, the adoption of MDE both in educational and professional environments has been slower than expected. One survey conducted among professional software developers suggests, that the majority of developers does not rely on modeling tools for their work.

Empirical studies suggest that the lack of modern tools and tedious installation processes are among the reasons for the slow adoption. Using web technologies rather than traditional modeling frameworks for creating modeling tools may be one approach to solve these problems. In this work, we provide a small example for such a web-based modeling approach.

The example application provides an interactive visualization of entity models and their dynamic (growth) behavior over time, as systems typically manipulate its underlying data during runtime.
By including various runtime aspects of entity models, we combine design time and runtime information into a single visual representation. Traditionally, this incorporation has been difficult. This is mostly due to the technological limits of EMF, which is why our approach will use the Javascript libraries D3.js and emf-json.

Architecture

The architecture of our software consists of several steps to ensure an identical visual representation inside the web browser.

  • The architecture pipeline starts with concrete models, in our case entity models, that describe a running system or a database.
  • Snapshots are generated over time to collect data about the behavior and changes made within the system. They provide information which can be the decrease in classes in general, deletion of relationships between those classes or an increase in attribute values.
  • These snapshots, including the model, are transformed from their EMF representation, which is an XMI file, to corresponding JSON representations. This transformation is done via the emfjson-jackson framework. For our purposes, ten snapshots are provided for the final visualization.
This serialized JSON object is an example on how such a transformed entity looks like after this step has been done.
  • After the previous step we now have ten snapshots and a model that contains information on how the entities relate to each other. To be able to visualize these snapshots inside a web browser with the help of D3.js, a custom mapper was implemented that helps with transforming the JSON data in valid D3.js data. The mapper builds JSON representations consisting of nodes and links.
  • With the help of ecore.js we can parse our JSON Ecore models and create a corresponding structure that can be visualized accordingly.
This is an example of how a node looks like. It has an ID to be referenced when creating links and various information about the entity itself. The group describes membership of the entity, e.g. if it is part of a containment or a supertype relationship.
A link contains source and target nodes and the type of relationship they reference.
  • The last step consists of the actual interface we needed to implement to be able to interact and view the transformed graph inside a web browser.

Visualization

The idea behind the visualization by a D3 force graph is to get a visual representation of different aspects like containment, inheritance, references and others. The graph objects and forces are easy to adapt with custom functions, and therefore, are suitable for representing information about instances of a model.

For the calculation of the distance metric the radii of the objects serve as the initial value, which means that a link can never be shorter than the combined radii of two connected nodes. To this we add a “base distance” which is the same for all links. This base is multiplied by a variable, which is selected, based on the link type.
The formula for the length of a link is defined as:
where is the length of the link, is the radius of a certain node , is the base distance  and is the link type based multiplier.


We provide the functionality to filter out certain link types, to make it feasible to focus only on some links, which may be helpful to analyze a particular aspect of the input data.

In addition to the graph representation of the Entity Model, we provide a list of all basic attribute values. This list is displayed when selecting a specific node and consists of a set of descriptive statistics for all numeric and enumerative values.  Statistics for numeric values include the value range (min, max) and average value. For enumeration types, we provide the distribution of values within the model. This information helps to quickly grasp the types of data contained in the selected class and provides further evidence about unexpected outliers and other anomalies, which might indicate an unintended system behavior (e.g.,  system failure).


Conclusion

The evaluation provides an indication of the usefulness of our approach by making a case for a number of important visualization aspects and by providing a mid-sized modeling example. Along this key result, our main contribution was not a new way of visualizing entity models. It was the many benefits that can be gained by using web technologies. On the user-perspective, benefits include the disappearance of an installation or manual update process, as well as creating inherently intuitive and clean visualizations. For the development perspective, which is crucial for the modeling community, we experienced a high rapidness of prototyping and developing for this modeling application mostly attributed to JavaScript, ecore.js and D3.js.

Future Work

The field of modeling and graph visualization offers many opportunities in adapting software solutions to web based approaches, in order to achieve the benefits that were described above. The proposed visual profiler for entity models only touches the surface of what is possible with modern web technologies. It is extensible in a number of ways.

Minor improvements

One minor improvement could be to introduce zooming as another mode of interaction, allowing for larger diagrams to be drawn and different levels of granularity (e.g. package level - class level - object level). Another improvement lies in the extension of considered attributes. Apart from numeric and enumerative attributes, all primitive data types may be considered.

Major improvements


The proposed minor improvements however do not capture the bigger picture of web based modeling development in the future. The key benefit of web technologies is interaction. Hence, one possible major improvement of the framework could be to add the functionality of interactively changing the diagram, e.g. by adding new classes or references. This is feasible with ecore.js, which allows the modification of Ecore models in the web browser and could be a promising alternative for some use cases to replace traditional editing environments like Eclipse (at least for non-experts).