1. Introduction
Asset management is a subset within the Architecture, Engineering, Construction, and Operation (AECO) [
1] sector that is deeply involved in asset lifecycles. The primary objective of an asset lifecycle is to establish guidelines for the effective management of assets, from their acquisition to their eventual disposal. An asset lifecycle deals with numerous types of information to facilitate effective data-driven decision-making. Examples of such information include operational and maintenance (O&M) information, the spatial description of the assets, and historical information regarding assets in the O&M phase of an asset lifecycle. Effective management of this diverse range of information will allow asset managers to establish a methodical and active asset management strategy that focuses on predictive asset maintenance (PdM) [
2].
According to the authors of [
3], asset managers often struggle with the abundance of information rather than the lack of it. A contributing factor to this phenomenon is the proliferation of Big Data and its technologies, which have emerged as an indispensable source of information and information management for asset management [
4]. Information management stands as a critical subject for asset managers when examining the optimal approach to managing the heterogeneous data sources involved in asset management. The increasing prevalence of digital asset management subsequently prompts information management as an emerging topic in asset management research, which results from the increasing prevalence of digital asset management. The digital and virtual transformation of asset management through the involvement of 3D models using the digital twinning approach could be the key to solving data storage and data processing while fully utilising rich information from various sources [
5].
While having a wealth of information and data is advantageous for asset management decision support tools, managing them to ensure the quality of the information is often a challenge. Substandard information quality caused by inadequate information management will impose significant difficulties on asset management operations [
6]. The resistance to implementing an efficient method for information management in asset management stems from the absence of a widely accepted method for managing information originating from multiple sources [
7] and the interoperability issues of available data [
1,
7,
8,
9]. According to several studies, asset and facility management operations spend approximately 80% of their time searching for relevant information, a problem originating from inadequate data integration [
10] and poor interoperability [
1,
11] that hinders effective decision-making. Therefore, it is imperative to address the issue of data interoperability in asset management with a well-defined strategy, which can be achieved through the development of a robust asset management data modelling approach [
7,
8].
Efficient operation in asset management relies on effective data exchange and sharing in all phases of the asset lifecycle [
7,
12]. A systematic review by the authors of [
7] demonstrated several built environment data models that aim to solve the problems of interoperability and data exchange in the asset management domain. Data modelling in asset management can be regarded as a method to facilitate a seamless exchange of information by establishing the classification and relationship of entities, ontology, taxonomy, and information hierarchy of physical assets [
8]. Designing and structuring are important aspects to consider when developing an asset data model [
13]. This is because a data model that possesses a systematic conceptual and logical design is not only capable of facilitating the smooth flow of data but also grants the ability to integrate with a database to enhance the efficiency of data storage, data query, and data manipulation.
An essential consideration during the development of a data model is deciding which information must be incorporated to meet the operational requirements and demands of an asset-intensive organisation. In the context of infrastructure asset management, incorporating spatial information is crucial to constructing a reliable asset data model. Despite its prominence in asset management, the integration of spatial information into asset data models is seldom discussed. Spatial information is vital for risk management in asset management as it can be used to determine the hotspot of risk concerning infrastructure assets [
14,
15,
16] and to assess the risk of exposure from natural disaster risks [
17,
18,
19,
20].
In asset management, specifically regarding building assets, spatial information comprises three distinct types of information, namely, coordinates, geometry, and space. Such information can be obtained using 3D city models, either by visualising them or are captured within the data structure of the 3D city models themselves. Building space arrangements within the buildings are classified as spatial information, which can be discerned through the visualisation of 3D city models. Incorporating the building space information into an asset data model could facilitate indoor navigation during a disaster risk, which is one of the capabilities of 3D city models when they are represented and modelled at a high level of detail (LoD) [
21]. As an initial step towards developing an effective asset data model, a technique is required for modelling high-LoD 3D city models that manage to capture the arrangement of interior building spaces.
Asset management must also maintain records of temporal information in the form of historical data and the progression of events from the operation and maintenance phases of the asset lifecycle [
22]. Temporal information plays a crucial role in making informed decisions in asset management [
23] and improving the reliability of available assets [
24]. Historical information can also provide valuable insights to diagnose problems with an asset, predict what will happen to an asset, and prescribe appropriate action for assets at risk [
25]. Consequently, it is clear that asset management should incorporate temporal data and that providing strategies for managing temporal information is equally important.
Temporal information can be captured and managed using process mining techniques. Process mining is a discipline that facilitates the extraction of data regarding business processes from the event log information [
26]. Asset management can benefit significantly from process mining techniques, which facilitate the discovery and modelling of event-related information including timestamps, activities, and their flows. Process mining identifies the flow of activity through the use of graphical representations.
The process mining domain plays a critical role in describing and analysing the flow of process events. Understanding the sequence of events in asset management is crucial for several reasons. Process mining techniques are designed to extract meaningful information from recorded event logs, which document various activities and interactions within an asset, and discover how the activities will affect asset performance. Therefore, by leveraging process mining, asset management organisations can significantly improve performance by analysing event sequences that can help enhance business processes [
27,
28]. Analysing the events helps to uncover inefficiencies and vulnerabilities that can aid risk assessment in asset management to prevent asset downtime.
This study aims to propose a comprehensive spatio-temporal asset data model that incorporates the aspects of building components from 3D city models and the management of events in the O&M phase of asset management. The proposed data model addresses two main gaps: the absence of a bi-dimensional data model in asset management and the insufficient focus on managing historical events within asset management.
4. Evaluation of the Data Model
This section illustrates the data model’s query capability through the execution of a query pertaining to the asset management maintenance phase. The query is divided into two categories, which are the spatial query and the temporal query. It should be noted that the data model is implemented in the ArangoDB graph database. Therefore, the query is based on the ArangoDB Query Language (AQL).
4.1. Spatial Query
The formulisation of Queries 1 and 2 is based on a use case on asset maintenance, where in some cases, the inspection and maintenance of a building are conducted by external contractors hired specifically to address specific issues. These individuals may not be familiar with the building’s layout and, therefore, require guidance to locate the rooms where inspection or maintenance is needed. Therefore, it is necessary to provide ways to guide these individuals in navigating a building across multiple floors and traversing various rooms on each floor. Query 1 identifies a room by specifying the block and floor where the room is located. Query 2 reveals the adjacency between rooms on the same floor.
The objective of this query is to locate a room that is the lowest-level entity of the spatial model. This query involves the containment relationship and can be made by filtering the ID or the name of the room by modifying the
@BuildingSpace parameter inside the query. The parameter
@BuildingSpace is a bind parameter in the AQL that allows users to insert any filterable attributes without modifying the query. The following query will return the ID and name of the room and the floor and building where the room is located.
Query 1: Finding where a room is located |
1 | FOR v,e,p |
2 | IN 2..2 |
3 | OUTBOUND @BuildingSpace BelongsTo, INBOUND DividedTo |
4 | RETURN {RoomID: p.vertices [0]._key, RoomName: p.vertices [0].Name, Floor: p.vertices [1]._key, Block: p.vertices [2]._key} |
The purpose of this query is to determine which rooms are connected to a certain room. In other words, it returns the room that shares the same boundary wall with a specific room. This query involves the adjacency relationship and utilises the bind parameter to filter which room the user desires to be queried.
Query 2: Finding adjacency of building spaces |
1 | FOR v,e,p |
2 | IN 1..1 |
3 | ANY @BuildingSpace ConnectedTo |
4 | RETURN {RoomID:v._key, RoomName:v.Name} |
Alternatively, a user who wishes to ascertain the complete extent of the building space connectivity within a floor may alter the query to retrieve the graph view of the query. It will visually represent the whole length of the building space connection. This involves the user specifying a large upper bound number for the path length as they may not know the precise quantity of rooms situated on a certain floor. However, the query will still return the correct number of rooms situated on a floor.
Query 2 (Alternative): Finding connectivity of building spaces |
1 | FOR v,e,p |
2 | IN 1..100 |
3 | ANY @BuildingSpace ConnectedTo |
4 | RETURN p |
4.2. Temporal Query
The temporal query for the evaluation of this data model is separated into three queries, corresponding to three use cases involving asset maintenance practices. Query 1 is based on first use cases, which involve asset managers that are required to ascertain which asset has undergone which event and the status of the event. This process is essential to enable the efficient scheduling of maintenance operations, ensuring that each asset receives the necessary attention based on its activity history and condition. Furthermore, understanding the event history of assets is vital for effective cost management. By keeping track of events, asset managers can analyse the total cost for maintenance, replacements, or failures and make informed financial decisions.
Query 2 plays a part in risk management, which is a crucial task in asset management. Identifying the frequency of an asset experiencing specific events, such as failures or accidents, allows asset managers to assess risks and implement preventive measures. Asset managers can accomplish this by finding the amount of time an asset has gone through a specific event. Asset managers can identify patterns and potential vulnerabilities by determining the number of operational failures or downtime experienced by an asset.
Finally, for Query 3, it is imperative to understand the sequence and timing of events to allow better coordination and optimisation of operations. Asset managers can guarantee the timely and efficient execution of all asset management activities, consequently minimising downtime and enhancing overall operational efficiency. They need to identify the sequence of events to improve the efficiency of the asset operation. The formulation and strategy for each query are explained in detail below.
The first query is finding the asset that has undergone a specific maintenance event. This query is completed over the
undergoes relationship, which is the spatio-temporal layer of the data model, since it relates to the asset (i.e., spatial elements) and events (i.e., temporal elements). Asset managers may require information regarding the maintenance status and completion time to ensure that no asset has been neglected during the maintenance process and to schedule subsequent maintenance activities.
Query 1: Finding the asset that has undergone a specific event |
1 | FOR c IN Work |
2 | FILTER c.Name == @Work |
3 | FOR v, e, p IN 1..1 OUTBOUND c Undergoes |
4 | return {eventID:e.eventID, Block:e.Block, Work:c.Name, Time:e.Time} |
The result from Query 1 may not clearly demonstrate the frequency of maintenance work. Therefore, it will aggregate the amount of time and frequency of a maintenance event undergone by the asset. The filterable attributes are the name of the asset and the type of maintenance work. This query is also completed over the
undergoes relationship.
Query 2: Finding the amount of time an asset has gone through a specific event |
1 | FOR c in Blocks |
2 | FILTER c.BlockName == @Blocks |
3 | FOR v, e, p IN 1..1 OUTBOUND c Undergoes |
4 | FILTER v.Name == @Work |
5 | COLLECT BlockName = c.BlockName INTO Grouped |
6 | RETURN {Block: BlockName, Frequency: LENGTH(Grouped)} |
This query will determine the sequence of events by querying the
DirectlyFollow relationship.
Query 3: Finding the sequence of events |
1 | FOR c IN Work |
2 | FOR v, e, p IN 1..1 OUTBOUND c DirectlyFollow |
3 | FILTER e.eventID == @eventID |
4 | RETURN {eventID:e.eventID, Block:e.Block, Work:c.Name, Time:e.Time, NextEvent:v.Name} |
The query will return the event that directly follows an event by filtering the event ID. The asset and work can also be filtered as an alternative to filtering solely by the event ID.
4.3. Comparison of the Insert Operation between Flattened Graph Event Log and the ADFM
One of the differences between a flattened graph event log and the ADFM is how the DF relationship is developed. The DF relationship in the ADFM uses more attributes to add more information to the edge relationship, as an effort to reduce the graph traversals from two-level to single-level graph traversals. Therefore, the insert operation for the edge might be influenced by the amount of information that is available within the DF relationship.
Figure 15 visualises the result of the insert operation of the edge between the two approaches. The operation was completed on ArangoDB using the AQL function, enabling the user to obtain the execution time. The numbers of edges tested were 100, 500, 1000, 5000, and 10,000 for both approaches. As seen from the figure, the execution time for both approaches increases linearly, with the ADFM possessing a longer execution time for the insert operation across all numbers of edges. The key difference between both approaches is the edge attributes within the edge, and this occurrence is afflicted by the number of edge attributes within the ADFM that are larger than the flattened event log. As a comparison, the edges of the flattened graph event log and the ADFM consist of three and five attributes, respectively. The type of edge attributes for both approaches is shown in
Table 2. This signifies a trade-off for the ADFM, which offers a more straightforward and accurate query, although a longer execution time is observed for the insert operation.
5. Discussion
This paper introduces a spatio-temporal data model for asset management applications, which consists of two main layers, which are the spatial and temporal layers. The spatial layer focuses on modelling the component of interior building space arrangements. The initial building space arrangements are acquired from the visualisation of a 3D city model, which is then modelled using graph notation, where each component is treated as a node, while the relationship between components is denoted using edges. The modelling of the interior building space arrangement is facilitated by an edge relationship that shows the containment and connectivity relationship of elements in the interior building space to allow a graph view of the building space arrangement, as shown in
Figure 16. The graph illustrated in
Figure 16a shows the full length of the building connection of a building space located on a floor, where the building space is identified by its alphabetical identification. Meanwhile,
Figure 16b illustrates the room arrangement of the first floor for C02 block, from which the graph view of the building connection shown in
Figure 16a is derived. This method enables the implementation of indoor navigation through the utilisation of NoSQL graph databases, which have been demonstrated to offer clearer representations via graph visualisation. Consequently, the modelling of the interior building space using graphs offers an alternative to high-LoD 3D city models. Illustrating the containment and connectivity relationship also serves as key topological information for the management of 3D objects within spatial databases to allow more complex spatial queries [
56].
The ADFM was introduced in the temporal layer as a graph model to show the chronological sequence of repetitive events stored in a graph database. This model leverages the notion of the Directly-Follows Multigraph (DFM) introduced by the author of [
57] as an object-centric process mining approach, which has proven to provide a more realistic view of process event data. The main difference introduced by this paper is implementing it in a graph database alongside elucidating the factors and strategies that must be considered when implementing it in a graph database. The main characteristic of this model is the aggregation of event nodes and the separation of temporal information from nodes, which, alternatively, are stored within the directly-follows edge relation. This approach produced a graph data model, where both the node and edge are unique, in an effort to solve the issue of false traces, when querying the sequence of events from a flattened event log. The difference between the ADFM and a flattened event log in
Figure 11 is shown in
Table 3.
Asset management is a dynamic activity with ever-changing events that will be undergone by assets. The proposed ADFM model facilitates understanding the sequence of activities and extracting information through queries to conduct analysis that can enhance O&M phases in asset management. With many new activities that an asset will undergo on a daily basis, it is imperative that the model can accommodate changes and updates of activities. The proposed model is designed to be adaptable to allow new events to be added and linked to the respective assets undergoing the activity. This is essential to ensure that the data remains current and reflective of the asset’s latest activities.
The problem when modelling the event log (see
Figure 11) is that the false trace arises from the edges that are not unique and the two-level graph traversal queries to relate the asset and their DF relation.
Table 4 shows the difference in query complexities between the ADFM and a flattened event log to query the DF relation. The flattened event log consists of a two-level graph traversal query, which in turn necessitates a more complex query strategy. As a consequence of the edge lacking essential information, which includes the asset and temporal information, the query process will return all the records that are connected with the filtered attributes, as no specific information can be filtered to differentiate the edge. Consequently, false traces and duplicate records are produced for this reason. Unlike the ADFM, which consists of a single-level graph traversal query, the query strategy to gather the sequence of events is more straightforward. Furthermore, as all the important information is stored within the edge, all filterable attributes can be filtered in one single query. A correct result from the query can thus be guaranteed as a result of multiple edges that are unique.
6. Conclusions
In this paper, we introduced a spatio-temporal graph data model for the application of asset management, concentrating on the management of the bi-dimensional information within the graph database. The variety of information in asset management has been identified and adapted to our data model, which consists of spatial and temporal layers. In the spatial layer, we introduced a graph-based building space management that separates a building component into three levels, which are the block, floor, and building space. The elements in each level are connected to each other through cross-level relationships or within-level relationships. These two types of relationships allow containment and adjacency relationships to be established between relevant components to allow spatial queries pertaining to containment and connectivity information of 3D model elements.
In the temporal layer, the main objective is to model the chronological flow of events in asset management using graph notation. The primary concern is resolving the issue with repetitive events in asset management, which may result in inaccurate event traces when event logs are modelled as flattened graph data models due to divergence issues, which are prevalent in the process mining domain. Therefore, we introduce the Aggregated Directly-Follows Multigraph (ADFM) to counter the issue of repetitive events in any business process application. Our model involves aggregating all repetitive events into one single node, creating a unique set of event nodes. To show the chronological flow of the event log, multiple edges are connected between relevant event nodes through a directly-follows relationship. The multiple edges between the same set of nodes are differentiated by inserting event ID information within the edge to enforce the integrity and uniqueness of each edge to ensure that the correct flow of events is acquired when queried.
There is a limitation concerning the proposed ADFM. The limitation concerns the insert operation, where the execution time for loading edge information in the ADFM is longer when compared to the flattened graph event log. This increased execution time is due to the edge attributes that exist within the ADFM that are larger than the flattened event log. However, it is a necessary drawback to provide a data model with a straightforward query and accurate query results. This balance between the insert operation and query accuracy is essential in information management applications for developing a robust and effective data model that meets the needs of sophisticated data management and analysis tasks.
Furthermore, the integration of the spatial and temporal layers constitutes the main component of the spatio-temporal data model, allowing spatio-temporal queries to ascertain which asset has undergone which event. Although such a query is temporal, it requires the integration of both layers to produce an efficient model that enables flexible queries to retain query accuracy. It is hoped that the findings of this paper provide necessary insights for further research on the management of 3D city model information using NoSQL databases, particularly graph databases. In the context of asset management, our findings offer key information for researchers and asset managers to manage historical records of activity, particularly in the O&M phase of asset management. This paper also provides a way to manage and manipulate temporal information using graph modelling to support an active and data-driven asset maintenance strategy through Predictive Maintenance (PdM).