Keywords

1 Introduction

Building Information Modelling (BIM) originates from product models. Charles Eastman, who is considered as the “father of BIM”, put forward the concept “Building Product Model” in 1999, which finally led to what is today known as BIM [1]. The definition of BIM which has been widely accepted is proposed by International Organisation for Standardisation (ISO). According to the ISO, BIM is defined as “shared digital representation of physical and functional characteristics of any built object which forms a reliable basis for decisions” [2]. In recent years, BIM attracts increasing attention of both academia and industry due to many benefits and resource savings during design, planning and construction of new building [3].

BIM derived from the building domain; however, it is currently on the rise in other fields. The German Federal Ministry of Transport and Digital Infrastructure states that BIM will become an integral part of future governmental infrastructure projects [4]. This trend shows that the dimension of infrastructure project has been taken into consideration by BIM. Moreover, some elements closely related to the Product Lifecycle Management (PLM), such as change management, maturity assessment, business process, etc., have been integrated into BIM. The above introduction indicates that the scope of application of BIM becomes increasingly large; however, in the domain of railway infrastructure BIM is not advanced enough for effective use due to the lack of the railway specific requirements.

The RailTopoModel, initiated by the International Union of Railway (UIC), is one typical model and standard of railway infrastructure [5]. The RailTopoModel will be firstly presented in details in the paper. However, the RailTopoModel is a model and not a language, so it is not design for exchanging data. In order to fulfil the data exchange among different stakeholders of one infrastructure project, the railML is proposed to define a standard data exchange format based on the RailTopoModel [6]. One case study will be then provided to demonstrate the application of the RailTopoModel and the railML for describing the infrastructure of a railway network. Finally, the paper discusses the new dimension for the further development of RailTopoModel in the context of Product Lifecycle Management (PLM). The details of RailTopoModel will be presented in next section.

2 RailTopoModel

The RailTopoModel project, led by the UIC with contributions from several industrial and academic partners in railway infrastructure, aims to define a universal description of railways business objects, independent of usages, structured in layers (topology, referencing, infrastructure, signalling, project lifecycle…) and open to future developments [5]. The modelling principles of the RailTopoModel will be firstly introduced hereafter.

2.1 Modelling Principles

The generic description of the railway topology is considered as the basic part of the RailTopoModel. Based on such generic description, two modelling principles are applied in RailTopoModel: topology of railway network and multilevel architecture.

Topology of railway network principle indicates that the RailTopoModel only describes the logical parts of the railway network and therefore independent of any physical or technical items used to represent it. According to this principle, all resources of the railway network are represented by nodes, and only nodes; edges represent relations between nodes, and only relations.

Multilevel architecture principle adopted by the RailTopoModel indicates that the structure of one railway network can be described in different levels of details [7]. Three detail levels of the railway network are proposed by the RailTopoModel: micro level, meso level and macro level. Switch or buffer stops that are connected by tracks can be represented in micro level; meso level can be used to represent the operating points that are connected by one or more tracks; while operating points connected with each other via single connections can be found in macro level (Fig. 1).

Fig. 1.
figure 1

(adapted from [5])

Three detail levels of railway network represented by RailTopoModel

Full size image

The RailTopoModel, describing the structure and the topology of the railway network with different levels of details, is represented by the Unified Modelling Language (UML). Based on the language UML, the RailTopoModel defines a universal description of railway business objects. The following section details the RailTopoModel by explaining each package and class represented by the UML class diagram.

2.2 Global View of RailTopoModel

UML is a general-purpose, developmental, modelling language that is intended to provide a standard way to visualise the design of a system [8]. A package may contain classes, objects, use cases, components, nodes, node instances and even other package, thus providing a global view of model to stakeholders [9].

Figure 2 presents the global view of RailTopoModel represented by UML package diagram. The RailTopoModel intends to include all the domains related to the railway infrastructure. Different domains are studied and developed by different working groups of RailTopoModel project. Figure 2 shows the domains proposed by RailTopoModel of current version. These domains are represented by seven packages: Base, PositionningSystem, Topology, Location, NetEntity, Infrastructure and Project. Every package contains the classes and the relationships between them. The following section chose the Topology package as an example to introduce the classes and their relationships in package.

Fig. 2.
figure 2

Global view of RailTopoModel represented by UML diagram (Color figure online)

Full size image

2.3 Topology Package of RailTopoModel

The RailTopoModel is proposed based on the generic description of the railway topology. Therefore the Topology package is considered as the basic part of the RailTopoModel and is chosen to introduce the details of the RailTopoModel.

Considering the topology of railway network principle presented in Sect. 2.1, nodes are conceptually embodied by NetElement class, and edges by Relation class in the Topology package. By applying the multilevel architecture principle, the CompositionNetElement class is derived from the NetElement class, which allows the assembly of nodes into bigger nodes, and zooming in and out from one level to another.

The PositioningNetElement class is derived from the CompoistionNetElement class, which indicates that a net element requires at least one positioning system.

The AssociatedNetElement class define topological structures and location information in relation between “NetElement” instances or between one “NetElement” instance and location information for “NetEntity” instances. The AssociatedNetElement has three attributes, intrinsicCoordBegin, intrinsicCoordEnd and keepOrientation. The intrinsicCoordBegin and intrinsicCoordEnd attributes are used to represent the start and end locations of the “NetEntity” instance in relation to the “PositioningNetElement” which is used for positioning within the network. The keepOrientation attribute is represent by a Boolean data type, which is used to present whether the child LinearElement keeps the same orientation as parent LinearElement.

The LinearElement class is derived from “PositioningNetElement”. It can be used to represent two different situations. The first situation is the uninterrupted track between two adjacent switches, or between a switch and an adjacent buffer stop. “Uninterrupted” means that there are no other switches in that connection (i.e., micro level structure). The second situation is the line section between two adjacent Operational Points, would be an important class of nodes to be used at macro level.

The NonLinearElement class is also derived from “PositioningNetElement”. It is used to present the operational point and net extremity in the railway network at macro level.

The ElementPartCollection class defines the collection of net elements to be aggregated into the higher level net element. Two classes, OrderedCollection and UnorderedCollection are derived from the ElementPartCollection class, dedicated to ordered net elements (required to build a route) and unordered net element (bulk list without need for routes).

The Relation class defines the connexity relation between two net elements in the connexity graph of the network. In a functional railway network, each instance of “Relation” typically brings together two “NetElement” instances. In other words, “Relation” can be seen as the base class to define edges in the topology of railway network principle.

The PositionedRelation class is derived from Relation class, which defines an oriented relation between exactly two “PositioningNetElements” instances. Three attributes, navigability, positionOnA and PositionOnB, using the enumeration type, are presented in the PositionedRelation class.

A compartment listing the attributes (AB, BA, Both and None) for the enumeration is placed to indicate the Navigability of the PositionedRelation class. If one connected “NetElement” instance is designated code “A”, the other connected “NetElement” instance is designated code “B”, the attribute “AB” (or “BA”) indicates that it is possible to move a train from NetElement A (or B) to NetElement B (or A). The Attribute Both (or None) indicates that it is (not) possible to move a train from A to B as well as from B to A.

A compartment listing the attributes (0 and 1) for the enumeration is placed to indicate the usage of the PositionedRelation class. If the value of positionOnA is 0, the “Relation” is using the start of NetElement A, while if the value of positionOnA is 1, the “Relation” is using the end of NetElement A.

The Topology package is chosen to introduce the details of the RailTopoModel in this section. Above introduction on the Topology package indicates that the global objective of RailTopoModel is to provide a model, capable of supporting simulations for railway systems. However, RailTopoModel is a model and not a language, so it is not designed for exchanging data. Based on the RailTopoModel, the railML is proposed to define a standard data exchange format. In other words, the railML revolutionises the sharing of information structured by RailTopoModel in the railway industry. Next section will present the details of railML (Fig. 3).

Fig. 3.
figure 3

Topology package

Full size image

2.4 Data Exchange Format for RailTopoModel: railML

The railML is an XML-based exchange format dedicated to the rail domain and its multiple business. People use railML as the data exchange format. Since 2002, the railML.org initiative is dedicated to developing and enhancing a standardised open-source data exchange format [10]. Originally initiated from German and Swiss industry parties, it today consists of a diverse community from all over Europe. Currently railML 2.3 is the official version, and three different subschemas: Timetable, Rolling Stock and Infrastructure are presented in this version. The subschemas such as MetaData and Interlocking, are under construction and to be published with the railML 3.0 which will be released in September 2017 [11].

In order to show the application of RailTopoModel/railML for representing the railway infrastructure, a case study of one railway network will be presented in next section.

3 Case Study

The provided case study is the railway network adapted from [6], which is presented in Fig. 4. The topological structure can be represented by instantiating the Topology package of the RailTopoModel. For the sake of clarity, a part of the railway network is chosen (the part in the blue box in Fig. 2) to present the application of RailTopoModel in representing the railway network’s topological structure. In order to provide a standard data exchange format to all stakeholders, this RailTopoModel instance can be described by the railML.

Fig. 4.
figure 4

(adapted from [6])

Railway network example

Full size image

The object diagram in Fig. 5 presents the instance of the Topology package of RailTopoModel to represent the topological structure of the railway network. The text next to each object in Fig. 5 shows the data set represented by railML, which provides a standard data exchange format of the RailTopoModel instance to all stakeholders.

Fig. 5.
figure 5

Instance of RailTopoModel & railML for topological structure of railway network

Full size image

In this section, the RailTopoModel is firstly presented in details in this section. The railML is then presented because it can provide a standard data exchange format for the RailTopoModel. One case study based on a railway network is chosen to demonstrate the application of the RailTopoModel and the railML for describing the infrastructure of a railway network.

As presented in Sect. 1, currently BIM not only requires the infrastructure information, it intends to integrate the data closely related to the PLM as well.

The RailTopoModel aims to define a universal description of railways infrastructure objects to facilitate the collaboration of different work group and eventually to reduce the collaborative project; however, compared with BIM, the elements related to the PLM has not been fully integrated into the RailTopoModel of current version.

Nowadays, the RailTopoModel is still under continuous development. Next section will discuss the new dimension of RailTopoModel for PLM.

4 New Dimension of RailTopoModel for PLM

PLM is a “systematic, controlled concept for managing and developing products and related information”. It ensures “the management and the control of product process (product development, production and product marketing)” and provides “the order-delivery process, the control of product related information throughout the product life cycle, from the initial idea to the scrap yard” [12]. By considering the PLM dimension in the domain of railway network, the elements related to the PLM can be generally divided into two parts: PLM Infrastructure (Infra) and PLM Rolling Stock (RS). The two parts of the PLM dimension for the RailTopoModel will be discussed hereafter.

4.1 PLM Infrastructure

The RailTopoModel is considered as one typical model and standard of railway infrastructure, so the geometrical and locational information of basic parts existing in the railway network, such as switch point, crossing, train detection element, train protection element, derailer, signal and level crossing, can be described and integrated into the RailTopoModel’s Infrastructure package. However, the data related to the PLM Infra mean more than that. The data describing the PLM Infra can be generally divided into four categories: (1) infrastructure layout data, (2) logical data, (3) manufactured equipment data and (4) project management data.

Infrastructure layout data ensure the physical integration between the equipment and buildings along the track, including the topographic information - these data have already been covered by the RailTopoModel of current version. Logical data describe the functional breakdown structure of the railway system and other system engineering data, such as the behaviour of the system. Manufactured equipment data describe thinly the geometry of the equipment for manufacturing, installing or maintenance purposes. Project management data correspond to an infrastructure project itself, which relies on the descriptive data.

The comparison result between the data represented by the RailTopoModel and the data required by the PLM Infra indicates that the data required by the PLM Infra have been partially represented by the RailTopoModel.

As to the logical data, functional structure and behaviour for all the net entities of the railway system have not been represented by the RailTopoModel. The functional structure and behaviour for the net entities should be further developed.

The third category of data required by the PLM Infra is the manufactured equipment data. On the one hand, the geometry of the net entities has been described by the net entities represented in Infrastructure package; on the other hand, the position of net elements is described in a very precise way by the Location package.

The last category of data is the project management data. The Projects package has been partially presented in the current version of RailTopoModel to represent the information related to the collaborative project. However, the relationship between the Projects package and the Infrastructure package has not been presented in current version, so the project corresponding to an infrastructure cannot be synergistically described.

4.2 PLM Rolling Stock

The term “rolling stock” in the considered context refers to building and operating a train. The PLM RS covers the following categories: (1) requirement specification data, (2) design & industrialisation data, (3) logistic data, (4) change management data and (5) maintenance data.

Requirement specification data supports the train constructors and the equipment providers in exchanging requirements through dedicated computer-aided means. Design & industrialisation data supports the model-based data exchange among different disciplines during the design and industrialisation process. Logistic data ensures the consistency of logistic data from the constructors to the customers (or vice versa). Change management data ensure the continuity between the constructor’s information system and the change management tool of their suppliers or customers. Maintenance data refers to the data related to maintenance information of rolling stocks.

However, the data related to the rolling stock cannot be described by the current version of RailTopoModel. In order to describe the data related PLM RS, the RailTopoModel should be further developed. New packages which can represent the above categories of data should be integrated into the current version of RailTopoModel.

5 Conclusion

In the context of BIM for railway infrastructure, the paper firstly introduces the RailTopoModel, one typical model and standard of railway infrastructure. The standard data exchange format based on the RailTopoModel - railML, fulfilling the data exchange among different stakeholders of one infrastructure project, is then presented. One case study of a railway network is provided to demonstrate the application of the RailTopoModel and the railML for describing the infrastructure of a railway network. Finally, the paper discusses the new dimension for the further development of RailTopoModel in the context of Product Lifecycle Management (PLM).

The future work will focus on the PLM numerical platform in which the RailTopoModel and its new PLM dimension can be implemented. Nowadays, various PLM platforms have been developed. Many of them prove to be successful in developing not only industrial tools but also exchange and collaboration standards around the digital processes throughout the whole lifecycle in different domains. The RailTopoModel is now under continuous development in aligning with the PLM numerical platform. It is believed that, by implementing the RailTopoModel into the PLM numerical platform, different stakeholders of one project can achieve a multidisciplinary collaboration during the whole lifecycle of the railway infrastructure and eventually reduce the development cost and leading-time.