BIM-Based Description of Intelligent Transportation Systems for Roads

Abstract

Intelligent transportation systems (ITS) provide safer, greener, and more convenient mobility, while reducing the impact on the environment. In recent years, simulation platforms have been employed to study ITS applications, mostly focusing on traffic-related simulations. Despite several research studies on ITS applications and simulation platforms, formal semantic descriptions of intelligent transportation systems have not been addressed yet. In this paper, a semantic model describing intelligent transportation systems for roads is proposed. The semantic model is devised to provide a basis for designing ITS simulation platforms. Building upon the semantic model, an extension to an open building information modeling (BIM) standard, i.e., the Industry Foundation Classes (IFC) schema, is presented. The IFC schema extension is verified and validated using a BIM-based simulation scenario of ITS for roads. It is shown that the proposed IFC-compliant description of ITS for roads provides a formal basis for generating BIM-based simulations and hence facilitates ITS infrastructure modeling in BIM projects. It is concluded that the present work represents a cornerstone for designing BIM-based ITS simulation platforms. In future endeavors, potential standardization and formalization efforts may be discussed.

1. Introduction

Constituting key elements of smart cities, intelligent transportation systems offer safer commutes, efficient mobility, and reduced environmental impacts, while increasing convenience and quality of life. An intelligent transportation system (ITS) is a coupled application consisting of several vehicular cyber-physical systems (VCPS). Intelligent transportation systems represent vehicles as smart components of vehicular cyber-physical systems with on-board sensing/actuating, computing, and communication capabilities [1]. Intelligent transportation systems are applicable for all modes of transport, e.g., road, aviation, maritime, and railway transport.

Intelligent transportation systems for roads refer to land-based systems that use roads as travel routes. Traffic management and public transportation control, road safety, and hazard management are among the most important applications of intelligent transportation systems for roads [2]. An ITS for roads comprises different data-sharing processes with intermittent connections and various applications, entailing a complex, heterogeneous system [3,4]. Therefore, it is vital to design simulation platforms for monitoring, evaluating, and optimizing the performance of ITS for roads. ITS simulation platforms essentially integrate computational models, aiming to investigate ITS capabilities, design flaws, potential improvements, and future mobility demands [5,6].

In the last decade, ITS simulation platforms have been employed to study ITS structures pertinent to specific use cases, e.g., traffic management applications or public transportation systems. Boschian et al. (2011) have proposed a reference framework of intermodal transportation systems with an information management layer between different modes of transport [7]. The reference framework integrates a simulation module and forms a platform for operational processes. Ghariani et al. (2014) have presented a comparative analysis framework for performance assessment of existing simulation platforms used for public transport control systems [8]. A model-driven engineering framework for implementing ITS simulations for roads has been proposed in [9]. The framework comprises ITS data models for traffic simulations and sensor network components, as well as guidelines on how to use the data models for different simulations, such as traffic lights control. Datta et al. (2016) have presented a semantics-based framework addressing ITS building blocks and different operational phases of ITS software elements, obtained to describe interconnected vehicles in the Internet of Things (IoT) ecosystem [10].

Research on ITS simulation platforms has mostly focused on improving simulations of traffic-related applications [11,12]. Although BIM for infrastructure is a matter of recent research [13,14,15,16], formal descriptions of ITS for roads that provide a basis for simulation platform designs have received little attention [17]. Standardized formal descriptions, e.g., based on open building information modeling (OpenBIM), may be used for describing infrastructure information for physical components in ITS for roads. OpenBIM data models, i.e., the Industry Foundation Classes (IFC) schema maintained by buildingSMART International (bSI), provide neutral non-proprietary data models for collaborative descriptions of infrastructure in the architecture, engineering, and construction (AEC) industry [18].

The current official IFC schema, standardized in ISO 16739-1:2018, includes several IFC entities that may be used to describe road infrastructure, such as the IfcAlignment entity, which defines reference systems for locating infrastructure elements [19]. Furthermore, within collaborative projects, researchers and organizations have been developing extensions to IFC entities that may be obtained to define physical and spatial elements of road infrastructure, with the potential of becoming candidate entities of official IFC schemas [20,21,22]. The IFC Road project, conducted by bSI, aimed to create a candidate standard, which extends the IFC schema for roads, e.g., developing data models for geometry, road body shape, earthwork, and semantic information for roads, and integrating use cases relevant to the road life cycle. With all deliverables of the IFC Road being published, the project was finalized in 2020 [23].

Moreover, several studies have been conducted to integrate further infrastructure elements into the IFC schema. For example, Lee and Kim (2011) have proposed an IFC extension for road structure, defining infrastructure segments in terms of IFC entities, such as IfcPavementLayer, IfcBridgePier, IfcTunnelLining, and IfcInspectionLadder [24]. The authors have used an example of a road section with combined bridge and tunnel segments to validate the proposed IFC extension, illustrating entities that define longitudinal and curvilinear sections of road infrastructure. Amann et al. (2015) have shown the extendibility of IFC Alignment when introducing the IfcCrossSections entity, which defines static and dynamic cross sections for junction-free roads [25]. A comparative study between the IFC schema and spatial elements required for tunnel design is presented in [26]. The authors later introduced an extension that defines entities for main components in tunnel structures, such as IfcShotcrete, IfcSteelRib, IfcRockBolt, and IfcConcreteLining, and have validated the extension using a real tunnel construction, which has been compared with an IFC-based BIM model. Park et al. (2018) have defined additional elements for semantic information management of steel box girder bridges using Industry Foundation Classes, Version 4 (IFC4), with user-defined property sets for spatial arrangement of the structure and physical structural components during planning and design phases [27].

Despite the extensive capabilities to describe infrastructure information for physical road components, the IFC schema provides just a few entities that may be used for describing the “cyber” components of ITS for roads. For example, IfcSensor provides a sensor description for predefined objects, such as temperature sensors, and may partially be employed to define sensing units of ITS intelligent infrastructure. The IFC entity IfcCommunicationsApplicance may specify communication units of ITS intelligent infrastructure using predefined property sets [28]. Although not specifically designed for describing ITS, studies have been conducted aiming to fill the gap in data models for cyber-physical components, such as actuators and sensor networks. Smarsly et al. (2017) have presented an IFC extension that defines entities related to cyber-physical systems deployed for monitoring and control applications [29]. The authors have defined IfcSensorNode, IfcSensorNetwork, and IfcMonitoringControlSystem as CPS-related new IFC entities to describe sensor nodes, sensor networks, and structural health monitoring (SHM) and control systems, respectively. Later, Theiler and Smarsly (2018) defined IFC Monitor, an IFC extension for describing monitoring-related information, adding enumeration entities IfcNetworkTopologyEnum and IfcSensorTypeEnum for predefined network topologies and additional sensor types, respectively [30].

From the information stated above, it is concluded that the existing capabilities of the IFC schema for describing intelligent transportation systems are limited to a few IFC entities for describing infrastructure information for physical road components. To this end, an extension to the IFC schema is required to fill the gap with respect to entities devised for describing the “cyber” components of ITS for roads, i.e., entities not yet available in the IFC schema but relevant to BIM-based modeling of ITS for roads. In this paper, for creating a formal description of ITS for roads facilitating BIM-based simulations, a semantic model for ITS for roads is proposed. The remainder of the paper is structured as follows: In Section 2, sources that provide knowledge relevant to semantic descriptions of ITS for roads are analyzed. Section 3 presents the semantic model and an illustrative example devised to validate and verify the proposed model. Then, in Section 4, an IFC schema extension is presented and validated to map the semantic model into BIM data models. Section 5 summarizes the present work and concludes with an outlook on potential future work.

2. Knowledge Sources for Semantic Modeling of ITS

Defining a formal basis for ITS simulation platforms requires full consideration of physical, computing, and networking subsystems of intelligent transportation systems. In this section, focusing on road transport, ITS components and relationships between components, as well as standards and protocols that ensure sound ITS operations (hereinafter termed “knowledge sources”), are categorized and analyzed to be adequately reflected in the semantic model. The knowledge sources are divided into four categories, ITS architecture, applications, intelligent infrastructure, and communications, which are illuminated in the following subsections. Figure 1 shows a taxonomy of the knowledge sources along with respective concepts and terms relevant to each knowledge source.

2.1. ITS Architecture

Vehicular ad-hoc networks are the central paradigm relevant to ITS architectures. A vehicular ad-hoc network (VANET) is a self-forming network based on wireless vehicle-to-vehicle (V2V) and vehicle-to-infrastructure (V2I) communications. Nodes of a VANET comprise vehicles and infrastructure equipped with networking devices, connected through VANET communications [31]. The architecture of vehicular ad-hoc networks may be categorized into pure cellular or wireless local area networks, pure ad hoc networks, and hybrid networks [32]. However, intermittent and autonomous connections between network nodes may cause frequent changes in VANET topologies. Varying traffic densities, heterogeneous vehicle paths in urban areas, and limited wireless transmission ranges and channel bandwidths pose challenges to VANET communications [33]. Thus, different routing protocols and security standards are employed for vehicular ad-hoc networks to guarantee sound data packet transmissions and secure communications [34].

Combining the VANET paradigm with the IoT in vehicular environments, i.e., the Internet of Vehicles, has led to the vehicular cloud concept, an efficient ecosystem for ITS networks [35]. The term “autonomous vehicular cloud” has been coined to denote a group of autonomous vehicles that share on-board resources and services with other authorized network nodes using vehicle-to-anything (V2X) communications. Therefore, by renting under-utilized vehicle resources and decentralizing data processing, vehicular clouds broaden ITS applications to non-safety location-specific applications [36].

Vehicular cloud computing and information-centric networking are the key attributes of vehicular clouds, facilitating robust resource-sharing processes. The automotive industry continuously produces vehicles with powerful on-board resources, enabling vehicles to sense and to store data from the environment, to process the data, and to react appropriately to the data. Thus, vehicles, recording data that are locally relevant, are enabled to efficiently manage time-sensitive operations. However, the potential of computing and communication capabilities of vehicles has not been fully exploited [37]. Vehicular cloud computing (VCC) is a mechanism that combines underutilized vehicular cyber-physical system resources to perform ITS applications. In other words, VCC eliminates the need for centralized data-processing infrastructure by distributing the computing load on network nodes [38]. Information-centric networking (ICN) is a data-networking paradigm that puts emphasis on the content of data packets by decoupling the packets from node addresses [39]. Several ICN architectures and messaging protocols exist that specify standardized, machine-readable naming and beacon exchange between network nodes [40,41].

An example of vehicular cloud formation is shown in Figure 2, where V2X and infrastructure-to-infrastructure (I2I) communications facilitate data packet transmissions between network nodes in the corresponding vehicular clouds. Using VCC under normal conditions on the road, vehicles driving in the same direction may form vehicular clouds to process computing tasks, disseminate the information to neighboring nodes, or store and later share data packets to ITS users. ICN is of specific importance in hazardous situations, e.g., in case of accidents, where vehicles approaching a hazardous section and/or road furniture, such as traffic cameras, form intermittent vehicular clouds, disseminating alert messages and notifying traffic to avoid congestion, chain accidents, and probable casualties.

Built upon VANET and taking advantage of VCC and ICN, vehicular clouds constitute both static clouds (e.g., in parking lots) and dynamic clouds (en route applications), hence covering a wide range of applications of ITS for roads. Consequently, in this study, vehicular clouds are considered the basic network architecture to be reflected in the semantic model.

2.2. ITS Applications

Different implementation strategies and design requirements have led to a plethora of ITS applications, the second category of knowledge sources relevant to the semantic model. Designing frameworks that focus on traffic information generation and urban mobility demands has been frequently addressed in the past decade [42,43]. Therefore, ITS applications are often solely regarded as traffic-related applications, such as traffic lights monitoring systems and public transportation control systems [44]. However, with the advent of vehicular clouds, cloud-based services and applications have been introduced [45].

As for the variety of existing applications, many application categories have been proposed with respect to different aspects of ITS architecture. For example, regarding ITS communication networks, the European Telecommunications Standards Institute (ETSI) groups ITS applications into the categories cooperative traffic efficiency, active road safety, cooperative local services, and global Internet services [46]. Cooperative traffic efficiency aims at improving the traffic flow and is further categorized into speed management and cooperative navigation applications. Active road safety comprises driving assistance applications and warning scenarios, aiming to increase cooperative awareness to prevent hazardous situations. Cooperative local services include applications for location-based services, such as point-of-interest notifications and media downloading. Last, but not least, global Internet services comprise applications for community services and life-cycle management of ITS infrastructure, such as insurance and financial services and infrastructure software provisioning and update. In this study, a categorization of ITS applications is defined as follows:

• Traffic management, granting optimized commutes and efficient mobility by reducing travel duration and fuel consumption, offers alternative routes in case of emergency and traffic flow control. Urban mobility controls, such as traffic lights control systems and public transportation control systems, are also included in this category.
• Maintenance management comprises continuous monitoring and assessment of intelligent road infrastructure and road conditions using real-time data exchange. In-time alerting for detours in case of disasters or accidents, road services such as winter road maintenance, and structural damage detection and reconstruction process management are typical examples of applications in this category.
• Telematics, combining telecommunications and informatics, represent on-board applications that monitor the performance of vehicle on-board functional processes (“intra-vehicle monitoring”) and provide driving assistance services. Autonomous driving is one of the most important applications in this category.
• Infotainment, merging information and entertainment, offers Internet-based services (such as online media platforms and on-demand information) to passengers for increasing the en route comfort.

While emphasis is put on traffic management and maintenance management scenarios, the semantic model presented in this study must be able to describe all the above-mentioned application categories. Traffic efficiency and safety messages are prioritized to be included in the ITS semantics for roads. In the following subsection, ITS intelligent infrastructure, representing a crucial element when implementing ITS applications, is discussed.

2.3. ITS Intelligent Infrastructure

The facilities underlying road intelligent transportation systems enable sensing of the vehicular environment, supporting physical and computational processes, and controlling ITS applications. Therefore, it is vital to determine ITS infrastructure capabilities and resources to be reflected in the semantic model. ITS infrastructure is composed of (i) physical and spatial structural elements, i.e., road infrastructure, as well as (ii) a set of functional elements that together build the ITS architecture, the latter hereinafter termed “ITS stations”.

Regarding road intelligent transportation systems, ITS stations, whether fixed or mobile, are the core elements that add intelligence to roads. ITS stations, according to [47], may further be categorized into the following:

• Vehicle ITS stations (mobile), i.e., vehicular cyber-physical systems that comprise all vehicle types in vehicular environments, e.g., cars, trucks, and motorbikes;
• Roadside ITS stations (fixed) that represent traffic shields and cameras, poles, and gantries;
• Personal ITS stations (mobile), i.e., smart devices, such as cellphones and tablets; and
• Central ITS stations (fixed), also known as “control centers”.

Different technologies enable ITS stations to interact with the vehicular environment. Regardless of underlying technologies, ITS stations are equipped with four main on-board resources, (i) sensing unit, (ii) computing unit, (iii) communication unit, and (iv) power unit. The sensing unit implements sensor networks and technologies, such as traffic detection systems and environmental-changes detectors. Micro-electro-mechanical systems (MEMS), inductive loops, radio-frequency identification (RFID), light detection and ranging (LiDAR) sensors, and automatic license plate recognition cameras are widely used components of traffic detection systems. Wheel speed sensors, rear object laser radars, and blind spot detection sensors are part of on-board sensing units in vehicle ITS stations. The main processing board and storage device that controls the computational processes constitute the computing unit. Communication devices, e.g., beacons, transceivers and routers, are represented by the communication unit, while the power unit comprises power-supply means, e.g., photovoltaic panels, piezoelectric transducers, or the electrical grid. In addition to the four main units, dedicated ITS stations may include actuating and control devices to comply with traffic and safety demands, to prevent hazardous situations, or to change the behavior of ITS stations.

Summarizing the information stated above, ITS stations are decent candidates for describing ITS intelligent infrastructure on a technology-independent semantic basis. Therefore, in this paper, ITS intelligent infrastructure is reflected in the semantic model in terms of vehicle, roadside, personal, and central ITS stations with on-board sensing, computing, communication, and power units. In the following subsection, connections between ITS station on-board resources, as well as communications between ITS stations that facilitate data sharing process, are shown.

2.4. ITS Communications

On-board communication capabilities allow ITS intelligent infrastructure to cooperatively connect to network nodes and to share resources without the need for a middleware or coordinating infrastructure, entailing cooperative ITS (C-ITS) communication [48]. Wireless communication is the cornerstone of C-ITS communication and is leveraged by scalability and easy deployment in vehicular environments. The ETSI TR 101 607 technical report lists standards, protocols, and specifications applied to C-ITS communications in Europe with respect to traffic efficiency and road safety requirements [49]. The architecture of ITS communication networks, to be reflected in the semantic model, is illustrated in Figure 3. Based on [50], ITS communication networks are in general categorized into ITS station internal networks and ITS station external networks; the latter include an ITS domain and a generic domain, as will be illuminated in the following paragraphs.

An ITS station internal network denotes communications within one ITS station. ITS station internal networks are defined in terms of a reference architecture based on layered communication protocols consisting of applications, facilities, networking and transport, access, management, and security layers. Each layer characterizes different functionalities and protocols relevant to ITS stations. For example, the ITS-G5 protocol characterizes access layer specifications for dedicated short-range communications in the 5.9 GHz frequency band [51], and GeoNetworking is a family of networking protocols that transports data packets based on geographical positions of the network nodes [50]. Every ITS station internal network possesses physical on-board equipment and devices, such as sensors, transceivers, and mechanical and/or electrical actuators, which are characterized and presented by the proprietary network. Only an ITS station internal network can access the proprietary network of the same ITS station.

ITS station external networks are composed of a generic domain and an ITS domain. The generic domain includes an access network to provide information to ITS users publicly, i.e., through public access networks, an access point to provide authorized closed groups of users with specific data, i.e., through private access networks, and a core network that provides access to the Internet, i.e., through core networks. In the ITS domain, the ITS ad-hoc network ensures wireless C-ITS communication between ITS stations, and the ITS access network provides direct connections between ITS station internal networks and the generic domain in ITS station external networks.

ITS station external networks exploit ITS station internal networks for combining on-board under-utilized resources of ITS stations, for transmitting data, and eventually for performing ITS applications. Therefore, ITS station external and internal networks, representing key components of ITS communications, are of notable importance for understanding ITS operations. As a result, direct implications for ITS communications are reflected by introducing ITS station external and internal networks in the semantic model.

3. A Semantic Model for Intelligent Transportation Systems

In this section, the semantic model for intelligent transportation systems for roads is presented, allowing technology-independent descriptions of road intelligent transportation systems. For validation, the proposed semantic model is instantiated using a cloud formation scenario, illustrating the capabilities of the proposed model to describe ITS for roads on a conceptual level.

3.1. Semantic Content and Structure

The semantic model, representing a metamodel for conceptually modeling ITS for roads, is developed based on the knowledge sources analyzed in the previous section. Figure 4 shows the ITS semantic model in terms of a class diagram. The main elements of the semantic model are described in the following paragraphs.

As depicted in Figure 4, the DigitalRoad class represents “non-conventional” roads that are furnished with ITS intelligent infrastructure. The DigitalRoad class is thus composed of the RoadStructure and ITSStation classes. The RoadStructure class displays the underlying physical body of a road, including spatial structural elements (e.g., bridges, tunnels, roads, ramps, and resting areas), as well as detailing of structural elements, such as cross section geometry, location, and material properties. Attributes defined for the RoadStructure class may specify standalone structural elements (e.g., a bridge slab) or grouped structural elements (e.g., a bridge) using id, geometry, location, and type.

The abstract class ITSStation represents core elements of the ITS architecture. Every ITS station is uniquely defined by an identification number, denoted by the id attribute, and on-board resources, expressed by the resourceUnit attribute. As mentioned earlier, ITS stations may be mobile or fixed. Thus, the ITSStation abstract class is modeled as a superclass of the Mobile and Fixed abstract subclasses. In the abstract class ITSStation, the attribute isFixed, with an initial value of false, represents mobile ITS stations. The Mobile abstract subclass is further categorized into Personal and Vehicle subclasses, which represent personal smart devices and vehicles of any type, respectively. The Fixed abstract subclass is depicted as a parent class to Central and Roadside subclasses to account for ITS control centers and roadside intelligent infrastructure, respectively. Furthermore, as a specific type of network nodes (Interface NetworkNode), ITS stations may perform a variety of operations, such as data processing, signaling, recording, data packet routing, and resource renting. Moreover, the abstract class ITSStation can perform operations, i.e., measureSpeed(), sendMessage(), receiveMessage(), rentResource(), and checkStatus(). The SensingUnit, ComputingUnit, PowerUnit, and CommunicationUnit classes, conforming to the assumptions made in Section 2.3, represent the four main on-board units of all ITS stations in the ITS architecture. Therefore, the ITSStation abstract class is connected to SensingUnit, ComputingUnit, PowerUnit, and CommunicationUnit classes using composition associations. However, some ITS stations may also have actuating capabilities, such as roadwork warning devices or traffic signal controllers. The actuating capability is represented via the ActuatingUnit class, which is connected to the ITSStation abstract class with an aggregation relationship.

The abstract class ITSCommunication portrays communication in the ITS architecture. The attribute domain represents communications in the generic domain or in the ITS domain, as described above. The communicationType and networkType attributes further characterize the instances of ITSCommunication abstract class with respect to communication type (internal and external) and network type (ad-hoc, ITS access, public, or private). The ExternalNetwork class depicts communications between ITS stations, whereas the InternalNetwork class presents communications within an ITS station. As introduced earlier, internal networks are dependent on a reference architecture, which is reflected in the semantic model as an interface that is realized by the InternalNetwork class. on-board units and all equipment and assets attached to each ITS station, whether connected wirelessly or with wires, are denoted by the ProprietaryNetwork class. Based on cooperative ITS communications in the vehicular environment, the ExternalNetwork class is categorized into V2X and I2I communications. The Wireless abstract class depicts wireless communication technologies and standards that are specifically deployed and used in the ITS architecture. The channelAllocated attribute lists frequency bands corresponding to different channels allocated to specific ITS applications. Furthermore, the LongRange and ShortRange subclasses represent wireless communication standards and protocols deployed for far-field and near-field wireless communications, respectively.

The semantic model illustrated in Figure 4 is designed as a metamodel to describe any instances of intelligent transportation systems with respect to different applications. In the following subsection, for validating the proposed semantic model, an instance, i.e., a model, of an ITS architecture and a cloud formation in connected vehicle ecosystems is showcased.

3.2. Validation of the Semantic Model

To illustrate the relationships between the ITSCommunication, ITSStation, and RoadStructure classes, and for validating the semantic model proposed in the previous subsection, a benchmark ITS scenario, shown in Figure 5, is semantically modeled. In other words, an instantiation of the semantic model as a metamodel is made to describe the ITS scenario, which is instantiated as a model. In the ITS scenario, it is assumed that an accident, e.g., a rear-end collision, occurs in a section of a highway and external networks of ITS stations form a vehicular cloud to disseminate safety-related messages. Therefore, to avoid chain accidents and traffic congestion, and to divert the traffic, ITS stations receive and send data packets by geographically addressing other nodes with potential interest in the content of data packets, or forward data packets to destination nodes.

In Figure 5, a highway section of the German Autobahn A9, labeled HA9, is shown, where the vehicle ITS station V1 broadcasts collision risk messages using the GeoNetworking protocol (“GeoBroadcast”) to ITS stations in the vicinity with potential interest, e.g., vehicles approaching towards the accident. The vehicle ITS station V1 uses short-range wireless communication to send a message (M1) to the vehicle ITS station V2. For sending and receiving the messages, the vehicle ITS stations V1 and V2 employ the ITS-G5 protocol. V1 also sends a media footage it has recorded from the accident to the nearest infrastructure node, here roadside ITS station RSU1, using short-range wireless communications (M2). In turn, vehicle ITS station V2 utilizes the point-to-multipoint networking protocol to ask the nearest infrastructure node (roadside ITS station RSU2) for an alternative route (M3). Using long-range wireless communication based on 5G cellular networks and the GeoNetworking protocol (“GeoUnicast”), RSU1 requests traffic-related data from the next fixed ITS station, here RSU2, and sends a detouring alert as well as traffic signals to RSU2 (M4).

The scenario shown in Figure 5 is semantically illustrated in Figure 6 in terms of an object diagram, i.e., an instance of the proposed semantic model. The object diagram comprises the HA9 object of type RoadStructure, four objects of type Vehicle and Roadside (V1, V2, RSU1, and RSU2), objects of type ITSCommunication characterized by the messages shared among the ITS stations (M1…M4), and Wireless-type objects displaying the wireless communication standards employed for each communication (5G and ITS-G5).

The scenario illustrated above may be interpreted from the object diagram depicted in Figure 6, corroborating that the proposed semantic model may define any scenario of vehicular cloud formations and ITS for roads, respectively. In the following section, a BIM-based description of ITS for roads in terms of an IFC schema extension is presented.

4. BIM-Based Description of ITS for Roads

In this section, the IFC schema extension is proposed to describe intelligent transportation systems for roads based on building information modeling. The official IFC schema, in association with IfcRoad introduced above, is used as the baseline schema, upon which the IFC schema extension is defined. By mapping the semantic model introduced in the previous section into the (baseline) IFC schema, the IFC schema extension for ITS for roads is achieved. In the following, components of the IFC schema extension are explained and verified. The section concludes with a validation procedure conducted on the proposed IFC schema extension.

4.1. An IFC Schema Extension for ITS for Roads

Figure 7 shows the proposed IFC schema extension. The entities, property sets, and an enumeration data type, which are newly proposed in this study (as described below), are shaded in gray.

The IFC schema follows an object-oriented approach based on the EXPRESS data modeling language, which is standardized in [52]. The IFC schema contains a hierarchy of several layers, in which IFC classes, i.e., IFC entities, are structured from the most abstract entities in the core layer to extensive, domain-specific, and resource-specific entities in upper layers. As can be seen from Figure 7, the entity IfcRoot of the core layer represents the most abstract class relevant to all entity definitions. The IfcRoot entity provides capabilities for globally identifying entities, attributing name and description of entities, and defining ownership information of entities. The entities IfcObjectDefinition, IfcPropertyDefinition, and IfcRelationship are subclasses of the IfcRoot entity, representing type and occurrences of objects, generalized characteristics assigned to objects, and objectified relationships in the IFC schema, respectively [53].

The IfcObject entity, a subclass of the IfcObjectDefinition entity, defines semantic occurrences of any “thing” or process. Several subclasses of the IfcObject entity exist, such as the IfcProduct entity, which represents geometrical and spatial objects, and the IfcGroup entity, defining a logical collection of objects. The IfcElement and IfcSpatialElement entities are two subclasses of the IfcProduct entity. The IfcElement entity defines physical components in an AEC product, whereas the IfcSpatialElement entity defines a generalized representation of components that construct spatial elements for structures. The IfcSpatialStructureElement represents spatial elements that construct a unit of project structure, such as construction sites, spaces, and facilities. The IfcFacility entity further classifies instances of the IfcSpatialStructureElement entity as built facilities, such as buildings (IfcBuilding), bridges (IfcBridge), and roads (IfcRoad). The IfcRoad entity, representing land routes, is a built facility defined for highways, streets, cycle, and foot paths. It is worth noting that IfcFacility and IfcRoad entities are included in the latest draft of the IFC schema, but are not yet standardized [54].

For describing ITS infrastructure, the IfcITSStation entity is newly defined in this study. The IfcITSStation entity is introduced as a subclass to the IfcDistributionElement entity, which represents elements participating in distribution systems. Additional to attributes inherited, the IfcITSStation entity is specified with attributes StationID of type IfcInteger, HasActuator of type IfcBoolean, and StationType of the IfcITSStationTypeEnum enumeration type. ITS station types are listed in the enumeration type IfcITSStationTypeEnum as the following constants: VEHICLEUNIT, PERSONALUNIT, ROADSIDEUNIT, CENTRALUNIT, USERDEFINED, and NOTDEFINED. on-board resources of ITS stations are specified using the property set Pset_ITSSResources, as shown in

Table 1. Property set Pset_ITSSResources for describing IfcITSStation entities.

Name	Type	Description
SensingResource	P_LISTVALUE/IfcLabel	A list of all sensors attached to ITS stations, e.g., MEMS,
		LiDAR sensors, RFIDs, cameras, and temperature sensors
ComputingResource	P_SINGLEVALUE/IfcLabel	Description and specification of the on-board computing unit
PowerResource	P_SINGLEVALUE/IfcLabel	Description and specification of the on-board power unit
CommunicationResource	P_LISTVALUE/IfcLabel	Description and specification of the on-board computing unit
		and network technology
ActuatingResource	P_LISTVALUE/IfcLabel	A list of all actuating units, if existing, attached to ITS stations,
		such as dampers and automatic crossing barriers

.

The entity IfcSystem presents organized combinations of objects that provide specific services. As a subclass of the IfcSystem entity, the IfcDistributionSystem entity accounts for networks, through which a distribution medium is controlled or maintained. Therefore, intelligent transportation systems may be regarded as distribution systems maintaining ITS communications and data transmissions among ITS stations. Hence, the IfcRoadITS entity is introduced as a subclass of the IfcDistributionSystem entity for describing instances of intelligent transportation systems for roads. The IFC schema defines different distribution system types using the enumeration type IfcDistributionSystemEnum, listing enumerators such as SIGNAL, DATA, and COMMUNICATION. For describing communications in the ITS domain, IfcDistributionSystemEnum of type COMMUNICATION is further specified using the property set Pset_DistributionSystemTypeITSC introduced in

Table 2. Property set Pset_DistributionSystemTypeITSC for describing IfcDistributionSystem entities of type COMMUNICATION.

Name	Type	Description
CommunicationType	P_ENUMERATEDVALUE/IfcLabel	Property enumerators are V2V, V2I,
		and I2I communication types
CommunicationChannel	P_BOUNDEDVALUE/ IfcReal	ITS-G5 transmission channel specifications
		based on ETSI EN 302 663 Standard [51]
CommunicationDuration	P_LISTVALUE/ IfcTimeMeasure	Duration of specific communication sessions

. As ITS communications are a variation of communications in cyber-physical systems, recommendations from [55] have been taken into consideration for developing the property set Pset_DistributionSystemTypeITSC.

The objectified relationship IfcRelAssignsToGroup assigns object definitions to a group. Here, instances of the IfcITSStation entity (RelatedObjects) are assigned to instances of the IfcRoadITS entity (RelatingGroup). Last, but not least, for connecting the IfcRoad entity as a spatial element to the IfcRoadITS entity, the objectified relationship IfcRelServicesBuildings is used. Listing 1 shows an extract of the extended IFC schema with entities relevant to ITS for roads denoted in EXPRESS.

Listing 1: Extract of the IFC schema extension in EXPRESS format showing entities relevant to ITS for roads.

…

TYPE IfcITSStationTypeEnum = ENUMERATION OF

(VEHICLEUNIT , PERSONALUNIT , ROADSIDEUNIT ,

CENTRALUNIT , USERDEFINED , NOTDEFINED);

END_TYPE ;

ENTITY IfcITSStation

SUBTYPE OF (IfcDistributionElement);

StationID : IfcInteger ;

HasActuator : IfcBoolean ;

StationType : IfcITSStationEnum ;

END_ENTITY ;

ENTITY IfcRoadITS

SUBTYPE OF (IfcDistributionSystem);

END_ENTITY ;

…

Listing 1: Extract of the IFC schema extension in EXPRESS format showing entities relevant to ITS for roads.

…

TYPE IfcITSStationTypeEnum = ENUMERATION OF

(VEHICLEUNIT , PERSONALUNIT , ROADSIDEUNIT ,

CENTRALUNIT , USERDEFINED , NOTDEFINED);

END_TYPE ;

ENTITY IfcITSStation

SUBTYPE OF (IfcDistributionElement);

StationID : IfcInteger ;

HasActuator : IfcBoolean ;

StationType : IfcITSStationEnum ;

END_ENTITY ;

ENTITY IfcRoadITS

SUBTYPE OF (IfcDistributionSystem);

END_ENTITY ;

…

The IFC schema extension is verified with respect to syntactic, semantics, and unit check criteria using the test software of the official IFC certification program [56,57]. The test software verifies the IFC schema extension according to EXPRESS syntax specifications, such as compliance to notational conventions, declarations of entities and data types, and declarations of entity attributes and functions. Moreover, since the syntactic criteria are met, the test software is able to generate Java classes for newly defined entities and enumeration data types. In this study, the test software confirms that no domain rules are violated and that the proposed IFC schema extension has successfully passed the verification test. Therefore, the proposed IFC schema extension can be used to create BIM-based models of ITS for roads in compliance with IFC syntax and semantics.

4.2. Validation of the IFC Schema Extension

In this subsection, to validate the IFC schema extension, the ITS scenario presented in Figure 5 is described in compliance with the IFC schema. Using the test software introduced above, the validation process is devised for checking whether the IFC schema extension precisely models BIM-based simulations of ITS for roads. For this purpose, the IFC model that corresponds to the ITS scenario shown in Figure 5 is created as an instance of the IFC schema extension, using the newly-defined entities, property sets, and the enumeration data type. The standard for the exchange of product model data (STEP) defines a data format for the IFC model [58]. Listing 2, as described below, shows an extract of the STEP-based IFC model used for the validation process. For greater clarity and transparency, obligatory attributes, such as the global identifiers, are removed from the IFC model shown in Listing 2.

Listing 2: Extract of the STEP-based IFC model of the ITS simulation scenario.

…

\#1= IFCROAD (\$ ,\$,’HA9 ’,\$ ,\$ ,\$ ,\$ ,\$ ,\$);

\#2= IFCROADITS (\$ ,\$,’ HA9_TestField ’,\$ ,\$ ,\$ ,\$);

\#3= IFCITSSTATION (\$ ,\$,’V1 ’,\$ ,\$ ,\$ ,\$ ,\$ ,935 ,.F.,. VEHICLEUNIT .);

\#4= IFCITSSTATION (\$ ,\$,’V2 ’,\$ ,\$ ,\$ ,\$ ,\$ ,913 ,.F.,. VEHICLEUNIT .);

\#5= IFCITSSTATION (\$ ,\$,’RSU1 ’,\$ ,\$ ,\$ ,\$ ,\$ ,42 ,.F.,. ROADSIDEUNIT .)

;

\#6= IFCITSSTATION (\$ ,\$,’RSU2 ’,\$ ,\$ ,\$ ,\$ ,\$ ,40 ,.T.,. ROADSIDEUNIT .)

;

…

\#13= IFCPROPERTYLISTVALUE (’ SensingResource ’,\$ ,(IFCLABEL (’GPS ’) ,

IFCLABEL (’RADAR ’) ,IFCLABEL (’ Front CCD ’)) ,\$);

\#14= IFCPROPERTYSINGLEVALUE (’ ComputingResource ’,\$, IFCLABEL (’ EvoTRAC

-G103 ’) ,\$);

\#15= IFCPROPERTYSINGLEVALUE (’ PowerResource ’,\$, IFCLABEL (’On - board

Power ’) ,\$);

\#16= IFCPROPERTYLISTVALUE (’ CommunicationResource ’,\$,

(IFCLABEL (’Short - range WiFi ’) ,IFCLABEL (’ Bluetooth 5’)) ,\$);

\#17= IFCPROPERTYSET (\$ ,\$,’ Pset_ITSSResources ’,’ V2_Units

’ ,(\#13 ,\#14 ,\#15 ,\#16) );

\#18= IFCRELDEFINESBYPROPERTIES (\$ ,\$ ,\$ ,\$ ,(\#4) ,\#17);

\#19= IFCPROPERTYLISTVALUE (’ SensingResource ’,\$ ,(IFCLABEL (’LiDAR ’) ,

IFCLABEL (’Wind ’) ,IFCLABEL (’ Daylight ’) ,IFCLABEL (’ Temperature ’)) ,\

$);

\#20= IFCPROPERTYSINGLEVALUE (’ ComputingResource ’,\$, IFCLABEL (’UNO

-2271G ’) ,\$);

\#21= IFCPROPERTYSINGLEVALUE (’ PowerResource ’,\$, IFCLABEL (’ Electric

Grid ’) ,\$);

\#22= IFCPROPERTYLISTVALUE (’ CommunicationResource ’,\$,

(IFCLABEL (’Long - range WiFi ’) ,IFCLABEL (’ Internet Gateway ’)) ,\$);

\#23= IFCPROPERTYLISTVALUE (’ ActuatingResource ’,\$,

(IFCLABEL (’ Announcement board ’) ,IFCLABEL (’ Solar cell switch ’)) ,\

$);

\#24= IFCPROPERTYSET (\$ ,\$,’ Pset_ITSSResources ’,’ RSU1_Units ’,

(\#19 ,\#20 ,\#21 ,\#22 ,\#23) );

\#25= IFCRELDEFINESBYPROPERTIES (\$ ,\$ ,\$ ,\$ ,(\#5) ,\#24);

…

\#33= IFCRELASSIGNSTOGROUP (\$ ,\$,’M1 ’,\$ ,(\#3) ,. PRODUCT . ,\#2);

\#34= IFCRELASSIGNSTOGROUP (\$ ,\$,’M2 ’,\$ ,(\#4) ,. PRODUCT . ,\#2);

\#35= IFCRELASSIGNSTOGROUP (\$ ,\$,’M3 ’,\$ ,(\#5) ,. PRODUCT . ,\#2);

\#36= IFCRELASSIGNSTOGROUP (\$ ,\$,’M4 ’,\$ ,(\#6) ,. PRODUCT . ,\#2);

\#37= IFCRELSERVICESBUILDINGS (\$ ,\$,’ Highway A9 ITS - enabled section

’,\$ ,\#2 ,(\#1) );

…

Listing 2: Extract of the STEP-based IFC model of the ITS simulation scenario.

…

\#1= IFCROAD (\$ ,\$,’HA9 ’,\$ ,\$ ,\$ ,\$ ,\$ ,\$);

\#2= IFCROADITS (\$ ,\$,’ HA9_TestField ’,\$ ,\$ ,\$ ,\$);

\#3= IFCITSSTATION (\$ ,\$,’V1 ’,\$ ,\$ ,\$ ,\$ ,\$ ,935 ,.F.,. VEHICLEUNIT .);

\#4= IFCITSSTATION (\$ ,\$,’V2 ’,\$ ,\$ ,\$ ,\$ ,\$ ,913 ,.F.,. VEHICLEUNIT .);

\#5= IFCITSSTATION (\$ ,\$,’RSU1 ’,\$ ,\$ ,\$ ,\$ ,\$ ,42 ,.F.,. ROADSIDEUNIT .)

;

\#6= IFCITSSTATION (\$ ,\$,’RSU2 ’,\$ ,\$ ,\$ ,\$ ,\$ ,40 ,.T.,. ROADSIDEUNIT .)

;

…

\#13= IFCPROPERTYLISTVALUE (’ SensingResource ’,\$ ,(IFCLABEL (’GPS ’) ,

IFCLABEL (’RADAR ’) ,IFCLABEL (’ Front CCD ’)) ,\$);

\#14= IFCPROPERTYSINGLEVALUE (’ ComputingResource ’,\$, IFCLABEL (’ EvoTRAC

-G103 ’) ,\$);

\#15= IFCPROPERTYSINGLEVALUE (’ PowerResource ’,\$, IFCLABEL (’On - board

Power ’) ,\$);

\#16= IFCPROPERTYLISTVALUE (’ CommunicationResource ’,\$,

(IFCLABEL (’Short - range WiFi ’) ,IFCLABEL (’ Bluetooth 5’)) ,\$);

\#17= IFCPROPERTYSET (\$ ,\$,’ Pset_ITSSResources ’,’ V2_Units

’ ,(\#13 ,\#14 ,\#15 ,\#16) );

\#18= IFCRELDEFINESBYPROPERTIES (\$ ,\$ ,\$ ,\$ ,(\#4) ,\#17);

\#19= IFCPROPERTYLISTVALUE (’ SensingResource ’,\$ ,(IFCLABEL (’LiDAR ’) ,

IFCLABEL (’Wind ’) ,IFCLABEL (’ Daylight ’) ,IFCLABEL (’ Temperature ’)) ,\

$);

\#20= IFCPROPERTYSINGLEVALUE (’ ComputingResource ’,\$, IFCLABEL (’UNO

-2271G ’) ,\$);

\#21= IFCPROPERTYSINGLEVALUE (’ PowerResource ’,\$, IFCLABEL (’ Electric

Grid ’) ,\$);

\#22= IFCPROPERTYLISTVALUE (’ CommunicationResource ’,\$,

(IFCLABEL (’Long - range WiFi ’) ,IFCLABEL (’ Internet Gateway ’)) ,\$);

\#23= IFCPROPERTYLISTVALUE (’ ActuatingResource ’,\$,

(IFCLABEL (’ Announcement board ’) ,IFCLABEL (’ Solar cell switch ’)) ,\

$);

\#24= IFCPROPERTYSET (\$ ,\$,’ Pset_ITSSResources ’,’ RSU1_Units ’,

(\#19 ,\#20 ,\#21 ,\#22 ,\#23) );

\#25= IFCRELDEFINESBYPROPERTIES (\$ ,\$ ,\$ ,\$ ,(\#5) ,\#24);

…

\#33= IFCRELASSIGNSTOGROUP (\$ ,\$,’M1 ’,\$ ,(\#3) ,. PRODUCT . ,\#2);

\#34= IFCRELASSIGNSTOGROUP (\$ ,\$,’M2 ’,\$ ,(\#4) ,. PRODUCT . ,\#2);

\#35= IFCRELASSIGNSTOGROUP (\$ ,\$,’M3 ’,\$ ,(\#5) ,. PRODUCT . ,\#2);

\#36= IFCRELASSIGNSTOGROUP (\$ ,\$,’M4 ’,\$ ,(\#6) ,. PRODUCT . ,\#2);

\#37= IFCRELSERVICESBUILDINGS (\$ ,\$,’ Highway A9 ITS - enabled section

’,\$ ,\#2 ,(\#1) );

…

The IFC model shown in Listing 2 includes object entities of type IfcRoad (#1), IfcRoadITS (#2), and IfcITSStation (#3 to #6). Attributes of IfcITSStation object entities, such as ITS station name, ID, actuating unit (T for true, F for false, i.e., not existing), and type are specified for each object. Property entities, property set entities, and relationship entities, which assign property set entities to object entities, are exemplarily shown in Listing 2 for only two ITS stations (#13 to #25). Using IfcPropertySingleValue and IfcPropertyListValue property entities, ITS station on-board units for object entities V2 (#13 to #16) and RSU1 (#19 to #23) are specified. The IfcPropertySet entity binds property entities in separate sets of type Pset_ITSSResources and creates V2_Units (#17) and RSU1_Units (#24) property sets for ITS stations V2 and RSU1, respectively. Finally, the IfcRelDefinesByProperties relationship entity is used to link each property set to the respective object entities (#18 and #25). Last, but not least, relationship entities (#33 to #37) define links between object entities (#1 to #6). The IfcRelAssignsToGroup relationship entity is used to specify links between object entities of type IfcITSStation and IfcRoadITS. For example, the ITS station V1 object ( #3) is integrated in the ITS network and linked to the HA9_TestField object (#2) using the IfcRelAssignsToGroup relationship entity (#33), representing ITS communication between two objects. The IfcRelServicesBuildings relationship entity denotes the link between object entities of type IfcITSRoad and IfcRoad. Figure 8 shows a visual representation of the IFC model of the ITS scenario.

Similar to the steps described above, the STEP-based IFC model is verified using the test software, which runs syntactic and semantic checks on the IFC model based on the IFC schema extension previously verified. The test software investigates the IFC model against syntactic and semantic requirements specified by the official IFC certification program. Several criteria, such as formal compliance with the STEP conventions and the conformance of data with the IFC schema extension are examined. It can be concluded from the results that the proposed IFC schema extension is capable of describing intelligent transportation systems in terms of IFC models. The IFC models represent correct information of scenarios in intelligent transportation systems for roads, providing a robust formal basis for designing simulation platforms and defining various ITS applications.

5. Summary and Conclusions

In this study, an IFC schema extension has been introduced to describe intelligent transportation systems for roads, in an attempt to provide a formal basis facilitating BIM-based ITS simulations. A semantic model, which formally describes ITS for roads, has been proposed to provide a technology-independent description on a meta level. With the semantic model, constructed upon an analysis of knowledge sources relevant to semantic modeling of ITS, a new concept for integrating ITS for roads into BIM data models has been materialized as an IFC schema extension, which have not been addressed prior to this work for intelligent transportation systems. For validating and verifying BIM-based simulations of ITS for roads, a benchmark scenario of vehicular cloud formation has been modeled using the IFC schema extension. The test software of the official IFC certification program has been used for verification purposes, i.e., for checking the IFC schema extension and the example IFC model representing the vehicular cloud formation scenario against syntactical and semantic criteria. The results have shown that the proposed IFC schema extension grants proper semantic description of ITS components, relationships between ITS components, and ITS applications. Therefore, it can be concluded that the IFC schema extension represents a sound formal basis to be used for BIM-based simulations of ITS for roads, not only in research projects, but also in the BIM industry, where infrastructure construction processes are yet to be (fully) digitalized. In future work, geometrical representation may be included in the IFC schema extension proposed herein, which may be tested using real data from field tests. Furthermore, the IFC schema extension may be enhanced by integrating and modeling further ITS use cases, focusing on ITS communication networks and decentralized data-processing issues. Furthermore, BIM-based simulations that consider the impact of ITS for roads on the environment are aspects that may be addressed in future research endeavors.