Like in many other domains in the construction industry, concepts and methods of Building Information Modeling (BIM) are becoming more and more important for the design of civil infrastructure assets. Although several data formats have been developed to capture domainspecific data, none of these schemas can be used for holistic communication and cross-domain data exchange. In this paper, we present approaches for mapping existing domain-specific data formats in a more generic schema like the Industry Foundation Classes (IFC). This offers the possibility to develop coordination models for seamless data exchange and improved communication between project stakeholders. Over the last years, the use of Building Information Modeling (BIM) related techniques has been established in the architecture, engineering and construction industry (AEC). A large number of software products is already available that helps engineers to create and validate digital models of buildings. Two critical aspects in BIM are the representation of geometric shapes and semantic attributes within a single data container as well as the seamless collaboration among several domains. Recent efforts have pushed forward the adoption of BIM methods also in the infrastructure sector. Particularly challenging, however, is the domain of railway design and operation (Bukhsh, Hartmann, & Stipanovic, 2016). Many disciplines are involved in the design process of a railway asset, e.g., alignment design, overhead electrification, railway equipment, noise barrier design and structural asset design like bridges and tunnels. The traditional paper-based working procedures have shown to be highly error-prone and inefficient as they do not provide appropriate means for handling the complexity involving a multitude of subdomains. BIMmethods can help to overcome these issues. However, for enabling an integrated design, data exchange is required across all these sub-domains. In recent years, a couple of data formats were developed to store, and exchange data of specific sub-domains involved in a railway design process, but they are often limited to one specific use case. An example of such a format is the data model PlanPro developed by German Railways for representing information about railway equipment components such as signal systems or switch controls (Maschek, Klaus, Gerke, Uminski, & Girke, 2012). For pre-design decisions as well as for maintenance and operation purposes, it is often not necessary to store an exact geometric representation of the railway equipment components. Thus, this exchange format was designed to transfer detailed semantic information and satisfies the specific needs of railway equipment design in Germany. However, there are use cases such as geometric clash detections or visualizations, which require at least a core geometric representation of each component in the three-dimensional space. From a BIM perspective, integrating and linking domain-limited data models is required to realize a higher quality of data exchange and reduce the error-prone and often manually re-
input of already generated data. This causes the need for domain-neutral and also vendor-neutral
data formats such as the Industry Foundation Classes (IFC). This format is well-established for
the exchange of building models. IFC can be used to merge data into a coordinated central
model, which can then be used to perform data validation or clash detection between the
components of federated submodels
In this paper, we show how domain-specific data formats can be translated into a more holistic and flexible IFC model. In detail, we compare the alignment description given in PlanPro with the available IFC classes to represent alignment axes an IFC model. Furthermore, we describe the opportunities how components can be placed in an IFC model. This paper also discusses the flexibility of IFC with respect to dynamic extensions by means of proxy objects and PropertySets without the need of an official schema extension for an individual domain. The paper is structured as follows. Section 1.1 gives an overview of related work and related approaches. We will focus on the PlanPro data model as one specific data model to describe a possible mapping process of a domain-specific data schema to a more generic data framework. Two possible approaches converting alignment information and related element placement are presented in Section 2. Those approaches and their successful implementation show that it is possible to utilize well-established domain-specific data-formats in a BIM process and hence prepare the data for further analyses and simulations. We investigate some relevant classes of the input data and explain approaches to transfer them into the IFC schema. However, the proposed transformation from PlanPro to an IFC model is limited in some aspects. These issues are discussed in Section 3 and should be addressed in future research.
In the last years, researchers and domain experts have developed a broad range of data models to carry information about civil infrastructure assets like roads and railways. These studies often put their focus on carrying semantic information and element descriptions.
Well-known data formats related to the field of railway infrastructure are PlanPro
Besides these separated approaches using IMs as exchange formats,
As shown before, IMs provide a solid base of semantic information about a specific asset.
However, it is not possible to use them for cross-domain communication and simulations.
Therefore, another well-established concept from the building sector can be adapted: Federated
models are used to coordinate domain-specific data during the complete lifecycle of a building.
This approach is already standardized by the British Standard PAS1192-2 as well as by the ISO
standard 19650.
Coordination and seamless data exchange are unavoidable between all project stakeholders to
optimize planning processes in the construction industry. Non-coordination of issues and design
data can lead to inconsistent data. Thus, a data structure should be chosen, which is capable of
all these aims. Model-based data structures for buildings are often led by a three-dimensional
geometric representation and a grid-based model orientation (axes and storeys in a building).
Contrary to buildings, civil infrastructure models are often line-oriented. The representation of
these alignment curves is typically split into a horizontal description in the -plane and its
corresponding gradient described by a parametric coordinate and the height
A line-oriented model orientation and product placements referencing relative to a given alignment.
Three-dimensional geometric component representations in any granularity.
The capacity to carry semantic information assigned to components.
IFC is capable of all these requirements. Therefore, we introduce mapping processes from pure
IMs into the IFC format to remedy the disadvantages of pure IMs. Especially, the strong linkage
between geometric and semantic information in an IFC model enables the user to formulate
complex queries against the generated model. Cross-domain problems benefit a lot from the
direct integration, e.g. by accessing semantic attributes of elements in a particular area or
volume
We developed a software prototype to examine the possibilities and limitations of mapping an IM into an IFC model. In the case study conducted, PlanPro was selected as origin format. The prototype supports the alignment description and the placement of signals as point-based objects along a track. Although the validation of the proposed concept is based solely on PlanPro and provides only the mapping of alignment data and signals, the strategies discussed in the next sections can also be applied for other components like switches, axle counters, or platforms.
As there is an increasing number of applications supporting IFC, several options exist to implement the proposed converter from IMs into IFC models. Currently, several IFC versions are in use. Thus, a short overview regarding IFC is provided.
The Industry Foundation Classes (IFC) are an open, vendor-neutral data format, which is intended to transfer information among different stakeholders across the lifecycle of a built facility. IFC is mainly focused on the building sector and has many classes to describe elements from different domains like architecture, structural analysis or HVAC. Although IFC is often related to data exchange in the planning and execution phase of a project, IFC models can also be used for operation and maintenance.
With version 4.1, the classes for describing alignments were added to the official schema. These
classes offer the possibility to store information about three-dimensional axes, which are the
base for line-based infrastructure assets e.g., roads, rails and their corresponding structures such
as bridges, tunnels or platforms. Extension projects are currently conducted by buildingSMART
to develop the necessary extensions of the IFC data model. This includes IfcBridge, IfcRoad,
and IfcRail
Although there is yet no standard defined for infrastructure assets in the IFC schema, many use
cases in an infrastructure planning process are already supported by IFC. The IFC data model
provides flexible extension mechanisms including proxy elements and user-defined property
sets, which enable the user to perform analyses and simulations on these models and allow data
exchange among different stakeholders. It is possible to use the generic
IfcBuildingElementProxy class to model components without a specific definition in the data
schema. IfcBuildingElementProxy is derived from the abstract class IfcProduct. Therefore, it is
capable of carrying a geometric representation as well as every other class derived from
IfcProduct. Classes derived from IfcProduct can be placed inside the model using subclasses
from the abstract class IfcObjectPlacement. A subclass of this class is the IfcLinearPlacement
class, which places components (derived from IfcProduct) relatively to a given curve
Since IFC version 4.1, specialized classes are available to describe typical alignment curves used for civil infrastructure assets. The IfcAlignment class is derived from IfcProduct and IfcCurve and is used to place elements along the described curve. Figure 4 shows the relevant IFC classes used in the implementation approaches.
An international standard for exchanging digital models will never be capable of all regional, local or project-specific features and requirements. To mitigate this problem, IFC provides the concept of property sets. There are many predefined attributes (e.g., for walls, windows or beams). Additionally, it is possible to create user-defined property sets and append them to components. Thus, it is possible to extend the IFC data schema for individual requirements, while at the time the model remains interpretable by any software product that has implemented IFC reading capababilities.
In both presented approaches, an additional property set was assigned to every positioned component in the IFC model, which contains relevant attributes from the given PlanPro file. Every component in PlanPro has an individual identifier, which is stored as one property within the PlanPro property set.
Several initiatives already tried to convert existing object-oriented data structures from or into
the IFC schema. Object-oriented schemas can be seen modeled as graph representations.
Therefore, the main task is finding correlations between both graphs. For identifying links
between IFC and CityGML entities
PlanPro Component Library *.rfa Type Number Name Sub-Components *.stl PreProcessing and Data Preparation *.SQLite
BIM Authoring Tool (Autodesk Revit)
XBIM 5 + Modules IfcAlignmentWriter (*.dll) IfcAlignmentWriter (*.dll) PlanProAlignmentExtractor (*.dll) PlanProElementExtractor (*.dll)
IFC 2x3 IFC 4 coordinate-based placement IFC 2x3 IFC 4 IFC 4x1 Coordinate-based Placement or Linear Placement
Existing BIM authoring tools offer much flexibility when creating new element groups and their respective geometry. Therefore, it is one option to use an existing application and extend it by a plugin that provides the required information in the modeling environment. For this case study, Autodesk Revit as a well-established BIM authoring application was selected. It has a powerful “family” editor to create new elements and can be extended using its Advanced Programming Interface (API).
A significant disadvantage of this approach is the overall dedication of BIM modeling tools for buildings and the limited support for linear infrastructure facilities. While applications like Revit organize their elements in grids and levels, civil infrastructure assets are mainly referenced to an alignment curve. Thus, Revit itself does not support the export of IfcAlignment Entities, but only positioning expressions in cartesian coordinate systems.
In the second approach, the framework XBim was selected to implement a stand-alone converter, which makes use of the IFC entities suitable to describe alignment curves. Additionally, the way of storing the placement of an individual component is addressed in detail. The next sub-sections provide an insight into the implementation process and limitations of the proposed concepts.
In the proposed concept, all available IMs are transformed into a 3D BIM representation to support coordination and informed decision making. Neither the components in RailML nor in PlanPro posses geometric descriptions in the form of Boundary Representations (BRep) or Constructive Solid Geometry (CSG). For some components, however, PlanPro refers to arrangement drawings. These drawings are independent of the manufacturer, and thus can be used for vendor-neutral tendering. Because of their generic character, a component library collects the geometric shape and parameterize these representations.
Every component has a certain drawing number and can have several types. All types have a slightly similar shape. Thus, it is possible to parameterize their geometric representation. Additionally, the arrangement drawings offer some additional semantic parameters like placement rules (e.g., the required distances to overhead electrification poles), which are covered by the library as well.
The generated family library establishes the base for both approaches. Due to restrictions on publishing and sharing these arrangement drawings, the component library is not big enough to cover all possible signal types. Hence, a cuboid is used as a geometric representation for a component if there is no reference to an arrangement drawing, or the arrangement drawing was not accessible.
Since Revit is not capable of any typical alignment format yet, a preprocessing tool was developed to prepare the required data of a PlanPro model for the use inside a Revit Project. Although Revit is not intended to be a modeler for railway equipment design, the family engine and the possibility to work with large property sets make it adequately generic and suitable for the proposed converter.
All coordinates of the alignment segments in a PlanPro file are described in a world coordinate
system (DB Ref as a specialized system of the well-known Gauss-Krüger-System). Since Revit
cannot handle large coordinate values, a preprocessing tool translates the given world
coordinates into a local project coordinate system1
After finishing the modeling process, the IFC export interface of Revit was used to create the
desired IFC model. Although the export interface offers the possibility to adjust some
preferences
The resulting IFC model in the versions 2x3 and 4 can be displayed in all common IFC viewer applications. 1 It must be noted that this local coordinate system is still a projected one with the respective distortions that must be taken into account.
As discussed above, the aim of mapping an existing IM into an IFC model can be solved with
the first approach using existing modeling software. The resulting model contains signals with
an individual geometric representation depending on the given arrangement drawings and
semantic attributes. The alignment is modeled with a volumetric boundary representation as
well. However, the plugin-approach leads to the loss of a direct relationship between the
alignment curve and the implicit placement indication (station and axis reference) of all
elements since cartesian coordinates now describe the position of any element.
The second approach remedies the disadvantage of using Cartesian Coordinates for every
individual element placement. Instead, each element’s position is described relative to an
alignment curve in the resulting IFC model. Once the alignment curve in the -plane is
modeled, it is possible to locate an element by a new coordinate system ( , ) in which
describes the stationing axis and the height at a specific station
To realize the second approach, we implement a direct mapping to IFC without using an existing BIM authoring tool in the toolchain anymore. Instead, the XBim Toolkit is employed to create the desired IFC model using IfcAlignment and the linear positioning concept along the alignment curve according to ISO 19148. XBim is an open-source framework for importing, editing and exporting IFC models and is licensed under the CDDL Open Source License (“xBIM Toolkit,” 2019).
The required methods are split up in several modules to make the code as reusable as possible. This concept enables the developers to extend the implemented prototype for further requirements or other applications, which need similar methods. The modules IfcAlignmentWriter and IfcElementWriter are entirely decoupled from the libraries extracting data from a given PlanPro model. The modules PlanProAlignmentExtractor and PlanProElementExtractor extract the necessary data and insert suitable IFC entities into a given IFC model. As shown in Figure 1, the created component library is used in both presented approaches. Since Revit families are stored in the proprietary *.rfa format, the contained geometric and semantic data are not accessible from applications outside the Autodesk product family. Thus, an export of the geometry into the open geometry format “STereoLithography” (STL) was required. STL stores a given body as a triangulated boundary representation and is, therefore, an explicit geometry representation. It can easily be converted into an IFC geometry representation like IfcTriangulatedFaceSet.
Model View Definitions (MVDs) are used to define a subset of the complete IFC schema and
add additional requirements such as geometric representation method or necessary attributes
The paper has presented two different approaches for integration domain-specific information models into a common model representing the overall railway project by means of the vendor neutral data format IFC. Both approaches presented the feasibility to convert domain-specific data models into an IFC model. By using the IfcAlignment classes as well as the IfcLinearPlacement concept, it is possible to set up an IFC model based in semantically powerful IMs, which uses alignment expressions for the overall project orientation. The concept of property sets enriches the data schema and provide the flexibility to adapt the model to specific needs. The presented approach of mapping semantically powerful but geometrically sparse IMs into IFC can be applied to many existing data concepts which are used for domainspecific exchange scenarios. By converting them into IFC models, it is now possible to coordinate elements and their related attributes across different domains. However, the translation and analysis of PlanPro have unveiled significant limitations: The geometric granularity of arrangement drawings can only provide an estimation of the component’s shape to be built in the real world. Thus, the modeled geometry can differ from real product shape in the built environment, and this must be considered when performing simulations based on the shown IFC models. In order to use the created models on site, refinements of the used geometric representations are inevitable. In conclusion, the proposed mapping process is possible and enriches the concept of seamless collaboration and communication along different domains in a project.
IMs often provide fictive components, which do not have any geometric representation but are of high importance for the design process. Such concepts cannot be directly covered by the IFC schema yet but are depictable in an IFC model. The use of placeholder geometries like cuboids or other simple geometries is one possible solution for such issues. The obligation that every class derived from IfcProduct must have a ProductRepresentation is restrictive in that point but solvable.
User-defined property sets enrich an IFC model due to project or domain-specific requirements. However, the possible data types for property values are limited to simple numeric or textual types and Booleans. An IM can have much more specialized subclasses, which structure relevant attributes and relationships better than a simple IfcPropertySet can do. Thus, use cases are conceivable that could be better served with the original IM. The focus of our research was the preparation of data for project-wide communication rather than supporting advanced and specialized use cases. Another option inside the IFC schema is the use of element assemblies, which should be addressed in future research.
Due to the yet missing standardization of railway components in IFC, it is complex to define filters or to process the models in subsequent simulations. It is possible to filter specific components by their names, but the defined filters are dependent on modifiable attributes. A better approach is the detection of elements by their element type. However, the necessary changes in the implementation described in Section 2 will not have a massive impact: most of the IFC classes representing railway equipment components will probably derive from IfcProduct.
In summary, the proposed conversion from IMs into the IFC format can be used to utilize domain-specific information in federated models and combine those in a coordination model. However, limitations exist with respect to the granularity and expressiveness of the converted data.
In this paper, we showed different approaches to convert domain-specific data formats into a more generic data model. These concepts offer much flexibility when querying data in a model and using it for in cross-domain simulations.
This study has been performed in the frame of the RIMcomb project. We gratefully acknowledge the support of the Bavarian Research Foundation for funding this project. cad.de/ xBIM Toolkit. (2019). Retrieved February 12, 2019, from http://docs.xbim.net/ Basis_Objekt Punkt_Objekt
Punkt_Objekt_TOP_Kante
Punkt_Objekt_Strecke ID_TOP_Kante Abstand Wirkrichtung Seitlicher Abstand ID_Signal_Befestigung ID_Regelzeichnung Befestigung_Art Hoehe_Fundamentoberkante Obere_Lichtpunkthoehe
Regelzeichnung IfcObjectDefinition IfcObject IfcElement Tag IfcBuildingElement IfcBuildingElementProxy PredefinedType
IfcProductRepresentation
IfcObjectPlacement IfcGridPlacement PlacementLocation PlacementRefDirection
IfcLinearPlacement
IfcLocalPlacement