A Framework of Life-Cycle Infrastructure Digitalization for Highway Asset Management

Abstract

With increased highway mileage, various types and quantities of infrastructure are equipped on the roadside to improve traffic safety and efficiency but also encounter difficulty in asset management. The collected data are separately stored with diverse formats, granularity and quality, causing repeated acquisitions and islands of information coherence. The life-cycle interoperability of infrastructure data are required to support life-cycle application scenarios in sustainable development. This paper analyzes 459 papers and 538 survey questionnaires to obtain the literature and practical digital requirements, including unified classification and standardized formats, linkage from separated data sources, support for data analysis across different scenarios, etc. To satisfy these requirements, an infrastructure digitalization framework is proposed, including road infrastructure and other data, data governance, life-cycle data integration, application scenarios, regulations and standards, and performance assessment. The application scenarios involve four categories—design and construction, maintenance, operation, and highway administration—each of which contains four or five scenarios. Then, the data integration approach is first developed with master data identification and determination of data elements for data interoperation between different application scenarios, using a modified data–process matrix, correlation matrix, and evaluation factors. A data relationship model is adopted to present static and dynamic correlations from the multi-source data. Numerical experiments are implemented with two practical highway administration and maintenance systems to demonstrate the effectiveness of the data integration approach. Master data identification and data element determination are applied to guide life-cycle data interoperation.

1. Introduction

With expeditious growth in mileage, highway asset management encounters pressure with various types and quantities of infrastructure and long life-cycles. Assets consist of physical infrastructure, human resources, equipment and materials, rights of way, computer systems, methods, technologies, etc. [1], and this paper mainly focuses on physical infrastructure. By 2023, China’s highway mileage had reached 5.43 million kilometers, comprising 183.6 thousand kilometers of expressways, more than 1.07 million bridges, and 27.2 thousand tunnels [2], ranking first in the world. Meanwhile, a variety of facilities are equipped on the roadside to improve traffic safety and management efficiency, such as perception sensors, traffic control devices, positioning and communication devices, etc. Several hundred types of highway infrastructure have increased the management difficulty, owing to their long life-cycles across construction, maintenance, and operation. Traditional infrastructure management aims at special application scenarios and naturally causes information fragmentation. Due to the lack of coordination between whole-life-cycle application scenarios, infrastructure data suffer from missing values, inconsistency, varying granularity, etc., resulting in lower utilization efficiency in other scenario applications and a high cost of repeated data collection.

Sustainable transport is central to sustainable development for universal access, enhanced safety, reduced environmental and climate impact, improved resilience, and greater efficiency [3]. Infrastructure, as a crucial asset in society, influences 72% of the targets of the Sustainable Development Goals (SDGs). Reducing life-cycle costs of transport infrastructure is an effective way to achieve green and low-carbon transport [4,5]. There are also some state-of-the-art methods and solutions in traffic and transportation engineering for energy saving [6]. Infrastructure digitalization, as an innovation driving transport sustainability, has transformed domains from data acquisition to whole-life-cycle data government and analysis, supporting the decision-making process of highway asset management.

The purpose of this paper is to develop a framework and approach to improve data interoperability between life-cycle application scenarios. Therefore, the life-cycle asset management framework and data integration method for master data and element identification both need to be addressed for infrastructure data recycling across different scenarios. Note that master data are the common infrastructure data that exist across critical application scenarios; for the underlying information objects, refer to [7].

A variety of asset management frameworks have been proposed by international technical societies for investment appraisal, strategy setting, program definition, evaluation and forecasting benefits, and improved performance, including The Institute of Asset Management (IAM) [8], World Road Association (PIARC) [9], Global Forum on Maintenance and Asset Management (GFMAM) [10], etc. In 2024, the IAM’s 10-box capabilities model [8] was proposed, with a whole-life/whole-cost perspective involving information management, life-cycle delivery, asset management decision making, values and outcomes, etc. These frameworks have also been applied in power systems [11,12], railways [13], etc. Some standards [14,15,16] have been released to regulate the requirements for the establishment, implementation, operation, maintenance, and improvement of asset management systems. Abu-Samra et al. [17] presented an asset management framework including data collection and invention, intervention quantification modeling, and an optimization model to ensure proper expenditure utilization and maintain performance in municipal infrastructure coordination. To find barriers to road infrastructure, Cruz and Sarmento [18] discussed the impact of technologies on existing management, including infrastructure-related and service-related innovations. Petchrompo et al. [19] proposed the two multi-asset categories of fleet and portfolio, and potential multi-component dependencies (performance, stochastic, and resource) were selected to apply in multi-asset systems. Transportation asset management was proposed to describe the strategic and systematic process of operating, maintaining, upgrading, and expanding physical assets effectively throughout their life-cycles [20]. O’Brien et al. [21] developed a guide for integrated civil management to assess the use of digital information in project delivery and subsequent asset management, improve project quality, and more effectively control costs. To achieve sustainability perspectives, Hanski et al. [22] conducted a systematic literature review of strategic asset management frameworks including data collection, descriptive analysis, category selection, and data evaluation.

Highway asset management has also paid increasing attention to risk evaluation [23], impact indicators [24], decision support [25], sustainability, etc. The impact of connected and automated vehicles has also been discussed in asset management [26]. A value-based method was proposed to map stakeholder requirements for effective decisions on infrastructure asset management and was demonstrated in a case study of transportation tunnels [27]. Asres et al. [28] conducted a meta-analysis with preferred reporting items for systematic reviews and meta-analyses (PRISMA) principles to develop a single sustainable flexible pavement design framework for highway agencies to effectively quantify the lifetime sustainability performance of flexible pavement in the design phase. Hakimi et al. [29] designed a digital twin-based life-cycle management framework based on data fusion and the integration of open building information modeling (openBIM) and geographic information systems (GISs). Wang et al. [30] proposed a technical framework for highway construction, including perception acquisition, integrated processing, business application, etc., and summarized the developmental status of key technologies. Peraka et al. [31] collected and reported current state-of-the-art developments of pavement asset management systems, summarizing information on data collection methods, data analysis, decision-making tools, and processing methods. Adey et al. [32] used a high-level process of the entire road infrastructure management process to increase efficiency and effectiveness. Recent studies have mainly focused on a single phase but lacked a life-cycle framework for highway infrastructure in asset management.

To capture the effects of digitalization, digital infrastructure was defined as a socially embedded mechanical system with feedback loops and self-reinforcing, including technological and human components, network, systems, and processes [33]. Digital technologies have been applied in various fields to improve efficiency, such as construction [34,35,36], freight transport [37], urban green economic transformation [38], urban water systems [39], entrepreneurial ecosystems [40], municipalities [41], etc. Lafioune et al. [41] conducted a study on the barriers and issues of urban infrastructure from a systematic literature review, like the lack of organizational change management, absence of data management, etc.

In highway infrastructure, some methods have been proposed to increase data interoperation, such as artificial intelligence (AI) of data analysis, GIS, BIM, and digital twin. The interstate highway system [42] incorporated risks of system failure and performance measures in an asset management framework with asset data inventory. Piryonesi et al. [43] applied decision trees to the analysis of long-term pavement performance database to predict the deterioration of the pavement condition index. Gao et al. [44] conducted a bibliometric analysis of BIM and digital twin technologies on transportation and discussed the goals of the entire life-cycle management. Current studies on road infrastructure data management mainly focus on data inventory and the proposed concept of life-cycle delivery, but lack the detailed method to guide data integration.

Highway traditional information systems are designed for business applications with vertical resources, resulting in the islands of information coherence. To enhance data recycling, master data management (MDM) was recommended to capture, integrate and subsequently share the master data, achieving accurate, timely, consistent and complete data quality [7,45,46]. Then, multi-domain master data management was presented to build a more cohesive multi-domain MDM plan with a series of strategies [47,48], including master data definition, data integration, data government, data stewardship, quality management, etc. These strategies are also applied in this paper to guide the data integration on highway infrastructure management, but do not provide specific approaches for identifying master data and determining the element.

Highway infrastructure digitalization captures, governs, integrates and analyzes digital data of physical infrastructure across design and construction, maintenance, operation and highway administration to maximize long-term data sustainability and minimize the life-cycle cost; also, refer to [49]. This paper proposes the life-cycle framework for highway asset management to support the recycling of infrastructure data and achieve the delivery from construction to maintenance, operation, and highway administration in multi-users. Then, an integration approach is developed to identify master data and determine elements for infrastructure data interoperation. The main contributions of this paper are given as follows:

• A conceptual framework of infrastructure digitalization is proposed with four layers and two support systems to facilitate the life-cycle highway asset management, and a 6-step procedure is presented to guide the framework development. The digital requirements are analyzed through a literature review and survey questionnaires, such as islands of information coherence.
• A modified data–process matrix with service duration is first developed to characterize the data interoperation across life-cycle scenarios, then identifies master data with evaluation factors.
• The correlation matrix is adapted to depict the relationship between infrastructure data and different scenarios, and then it determines data elements with the selected assessment factors. A data relationship model is also proposed to describe static and dynamic data correlation from multiple sources.

For comparison, some related studies with the objective, framework, and data acquisition are presented in

Table 1. Comparison of some related studies.

Publication	Area	Objective	Framework	Data Acquisition
[8]	General	Improve organizations’ asset management capabilities	10-box capabilities model	Concept of life-cycle delivery
[10]	General	Maintenance framework of physical assets with the entire life-cycle	Maintenance framework	Concept of asset data and information
[28]	Road	Quantify the lifetime sustainability performance of flexible pavements on design phase	Flexible pavement framework of design	/
[42]	Highway	Manage interstate highway system investments	Asset management framework for investment analysis	Data inventory
This paper	Highway	Life-cycle data interoperation	Life-cycle asset management framework	Data integration method with master data identification and data element determination

.

The rest of this paper is structured as follows. The digital transformation and the research methodology are introduced in Section 2. Section 3 describes the life-cycle infrastructure digitalization framework with four layers and two support systems. In Section 4, a life-cycle data integration approach is proposed to determine master data and elements. The experiments with practical data are implemented in Section 5, and conclusions are presented in Section 6.

2. Method

We analyzed the digital requirements of asset management via a literature review and survey questionnaires. Then, we designed the research methodology to describe the development process of the digitalization framework.

2.1. Literature Requirement

The thematic analysis was utilized in the literature review to summarize the challenges of road asset management. The studies were retrieved from the Web of Science (WoS) core collection for the initial full records, with the keyword “road asset management challenge” or “road asset management requirement” within the period from 2000 to 2024. The automation filtering was set as the document type (article, proceeding paper, and review article), research area (engineering, business economics, computer science, transportation, and construction building technology), and language (limited to English). The search results were then dropped to 459 papers.

All keywords from the authors and also the WoS were applied for co-occurrence analysis in Vosviewer (v1.6.20). The minimal number of occurrences was set as 7 for keyword screening, and a total of 20 requirements were selected. The requirements were divided into five clusters: inspection and optimization, performance and strategy, model and information, risk and sustainability, and investment and technology. The network mapping is shown in Figure 1. Five clusters are represented by red, yellow, green, blue, and purple. The node denotes the requirement and its color and size are determined by the belonging cluster and the occurrence value. The link indicates the co-occurrence of two requirements and the occurrence number in the literature is reflected by its strength.

The occurrences and total link strength of each requirement and cluster are delineated in

Table 2. The key challenges of road asset management.

No.	Key Requirement	Occurrences	Total Link Strength
Cluster 1 (red): Inspection and optimization		13.9	19.3
1	Genetic algorithms	7	16
2	Integration	7	8
3	Maintenance and inspection	29	32
4	Optimization	24	35
5	Reliability	13	16
6	Selection	7	17
7	Simulation	10	11
Cluster 2 (green): Performance and strategy		11.8	13.5
1	Behavior	6	11
2	Competition	6	10
3	Efficiency	9	10
4	Performance	27	23
5	Policy	6	6
6	Strategy	17	21
Cluster 3 (blue): Model and information		18	18.25
1	BIM	6	3
2	Information	8	10
3	Machine learning	10	3
4	Model	48	57
Cluster 4 (yellow): Risk and sustainability		13.3	18
1	Resilience	10	14
2	Risk	20	29
3	Sustainability	13	11
4	Vulnerability	10	18
Cluster 5 (purple): Investment and technology		9.7	11
1	Internet	6	3
2	Investment	15	18
3	Technology	8	12

. Note that the occurrences and total link strength of each cluster are the average values derived from the associated requirements. The results indicate that the model (in Cluster 3) has the highest occurrence of 48 and total link strength of 57, making Cluster 3 (model and information) the highest occurrence at 18 and the second-ranked total link strength at 18.25. Then, maintenance and inspection and optimization (in Cluster 1) are ranked second place on the occurrences and total link strength. Cluster 1 (inspection and optimization) has the highest value of total link strength 19.3. In sum, Cluster 3 has received more attention in the literature and has a stronger relation with other requirements.

2.2. Practical Requirement

The survey questionnaire was designed for the importance analysis of digital application scenarios, mainly focusing on traffic engineering and facilities. The questionnaire contains 33 questions involving personal information, archives and assets, modeling and simulation, aided decision-making, and auxiliary maintenance. The personnel dealing with design, construction, and operation were invited to fill out the questionnaires, covering highway agencies in provinces of China (i.e., Jilin, Liaoning, Beijing, Jiangxi, Xinjiang, etc.). A total of 538 valid survey questionnaires were screened when the personnel’s response time was greater than 120 s. For more details, we refer the reader to [50].

The importance of digital application scenarios comprises 20 scenarios and importance degrees, as presented in

Table 3. Digital application scenarios and importance degree from survey questionnaires.

No.	Scenarios	Degree
Category 1: Archives and assets		4.33 (average)
1	Life-cycle digital archives	4.33
2	Intelligent spare part management	4.35
3	Asset value assessment	4.3
Category 2: Modeling and simulation		4.29 (average)
4	Reliable digital twin display	4.26
5	Spatial association visual display	4.4
6	Maintenance decision-making simulation	4.27
7	Data modular access and conversion from construction to maintenance	4.25
8	BIM from construction to maintenance	4.29
Category 3: Aided decision-making		4.31 (average)
9	Aided planning and budget allocation of operation and maintenance	4.24
10	Implementation tracking and post-evaluation of operation and maintenance	4.26
11	Operation and maintenance assistance with fault knowledge base	4.38
12	Layout with forward design assistance	4.3
13	Data statistics and mining analysis	4.36
Category 4: Auxiliary maintenance		4.42 (average)
14	Data acquisition via wireless communication of handheld terminal and infrastructure	4.38
15	Autonomous control and remote operations	4.47
16	Remote inspection and robotic patrolling	4.31
17	Real-time monitoring of operation status	4.47
18	Impact analysis and fault deduction	4.44
19	Failure precise positioning and cause analysis	4.49
20	Autonomous emergency disposal and collaboration	4.41

. These scenarios are divided into four categories, archives and assets (Category 1), modeling and simulation (Category 2), aided decision-making (Category 3), and auxiliary maintenance (Category 4), in which the first two provide the data and modeling foundation for other applications. Note that the degree of each scenario has five scales from strong unimportance to strong importance (i.e., integers 1 to 5). For each category, the degree is the average importance value of all-belonged scenarios.

Table 3 also indicates that Category 1 has a higher value of 4.33 in importance degree, only ranking after Category 4. Intelligent spare part management (Scenario 2) and spatial association visual display (Scenario 5) are also the most important scenarios in Categories 1 and 2, respectively. Hence, life-cycle digital archives and spatial association visualization have drawn more attention in infrastructure digitalization to achieve the life-cycle digital asset management.

2.3. Research Methodology

We propose the processes to establish the framework of infrastructure digitalization, including requirement analysis, a summary of challenges, and a critical part extraction of the framework, as presented in Figure 2. Through an analysis of the literature and practical requirements (see Section 2.1 and Section 2.2), the main challenges are summarized to achieve interoperability of all of the life-cycle scenarios as follows: Challenge 1—provides unified classification and standardized formats of infrastructure data to overcome poor interoperability with multi-scenario applications; Challenge 2—expresses the linkage from separated data sources; and Challenge 3—supports the data analysis for different applications.

To deal with these challenges, critical parts of the framework are extracted as multi-source infrastructure data, data government, life-cycle data integration, application scenarios, regulation and standards, and performance assessment. As divided by the dashed line in the figure, the first two provide the unified classification and data format (for Challenge 1); life-cycle integration provides the master data identification, data element determination, and data relationship model to formulate the data linkage of disparate sources (for Challenge 2); regulation and standards also support Challenges 1 and 2; and application scenarios and performance assessment provide the support for the digital application (for Challenge 3).

The process of the infrastructure digitalization framework is explicitly given below:

Step 1:

Application scenario. Select the application scenarios that are determined for digitalization support, with consideration of business scope, social benefit, etc.

Step 2:

User requirement collection. Collect the requirements for the selected scenarios in Step 1, via literature retrieval and survey questionnaires. Studies are retrieved when setting keywords, period, research area, language, etc. Survey questionnaires can also be used to analyze the requirements of users and operation departments.

Step 3:

Challenge summary. The key challenges are analyzed from the literature with occurrences and total link strength, and practical requirements are selected with importance degree. Then, common interests are summarized as the key challenges.

Step 4:

Critical parts of framework. Find critical parts and methods to solve challenges (in Step 3). Decide the acquisition of multi-source infrastructure data and data government rules. Determine relevant sub-scenarios in the life-cycle data integration for data interchange and data service, which have data interchange with application scenarios in Step 1. Provide the evaluation factors for performance assessment.

Step 5:

Master data and element determination. Across the selected application scenarios in Step 4, master data and the element are determined by the life-cycle data integration method. A data relationship model is also established with static and dynamic infrastructure data.

Step 6:

Establish framework. The infrastructure digitalization framework is established with critical parts, master data and elements, application scenarios, etc.

3. Infrastructure Digitalization Framework

In this section, an infrastructure digitalization framework is introduced for the life-cycle data management on application scenarios, constituting six critical parts (see Section 2.3). The whole framework is proposed with four layers and two support systems: road infrastructure and other data, data governance, life-cycle data integration, application scenarios, regulations and standards, and performance assessment (Figure 3).

The framework is adaptable for life-cycle data application: collect the multi-source data at the data layer, improve the data quality and storage at the data government layer, combine multi-source data with a unified view and support the life-cycle application scenarios of design and construction, maintenance, operation and highway administration. The process complies with regulations and standards and is evaluated at the performance assessment. Note that the infrastructure digitalization framework can guide the design and development process of the highway electromechanical digital twin platform and we refer the reader to [51].

3.1. Data Layer

The data layer aggregates all the information from data acquisitions, including highway infrastructure and other relevant data. The highway infrastructure mainly consists of roads and structures, and traffic engineering and facilities [42,52,53,54]: route, pavement, subgrade, bridge, traffic safety facilities, mechanical and electrical equipment, service facilities, environmental landscape facilities, etc. (Figure 4). New intelligent equipment of surveillance camera, thunder-vision all-in-one machine, infrastructure condition detector, roadside unit, payment self-service terminal, etc., are also categorized as mechanical and electrical equipment.

The basic static data and monitoring data of road infrastructure can be automatically collected from construction (maintenance) and the sensors from maintenance and operation with the front-end process, respectively. Other data are also collected for road asset management, such as traffic operation data, spatial data, and meteorological data.

3.2. Data Government Layer

The data governance layer improves the data quality perceived from the data layer and stores data for data analysis, which contains data preprocessing, quality assessment, standardization and storage, analysis and visualization, etc. The perceived infrastructure data can be inaccurate, incomplete and inconsistent. Data preprocessing is applied to fix poor-quality data, involving the filling of missing values, removal of redundant data, outlier detection, noisy data smoothing, etc. Then, the assessment is provided to evaluate the uniqueness, accuracy, consistency, completeness, format compliance, etc. (refer to [55,56]). Note that only the satisfied data can be standardized and stored for the application. According to data-related regulations and standards for scenario application (such as [52,57,58,59]), data are transformed into the standard form with predefined and constrained values through data standardization. Data analysis and visualization are also applied to discover characteristics or trends of infrastructure.

We give an example to depict the data storage of route, subgrade, and surveillance camera on design and construction, maintenance, operation, and highway administration, as presented in Figure 5. On route data, all scenarios require information of the route name, starting and ending position in mileage, etc. Maintenance, operation, and highway administration, respectively, require the information of handover data, completion data, whether there are toll fees or not, building control zone width, etc. Similarly, subgrade data and surveillance camera data are stored with various contents related to these scenarios.

3.3. Life-Cycle Data Integration Layer

The data from different scenarios (see Figure 5) are maintained to solve the duplication, inconsistencies, and fragmentation and to create the inter-relationships at the life-cycle data integration step, which then provides the application of scenarios as a whole. Hence, the governed infrastructure data are interchanged across the construction, operation, maintenance and highway administration via master data. Data service is provided for the application scenarios, such as attribute, relationship model, spatial typology, etc. A series of processes are applied to avoid discrepancy and strengthen the coherence of infrastructure data from different scenarios, consisting of data requirements, master data identification, data element determination, data assessment, data relationship model, etc.

Figure 6 illustrates infrastructure data integration across four categories: design and construction, maintenance, operation, and highway administration. Except for the master data, each scenario contains its transactional data. For instance, in the operation scenario, traffic volume, traffic incident, emergency event, surveillance video data, etc., are required to handle traffic monitoring and emergency aid. The detailed process of the data integration step is presented in Section 4.

3.4. Application Scenario

The main application phases of highway infrastructure [60,61,62] can be divided into design, construction, maintenance, operation, highway administration, etc. We classify the application scenarios into four categories, i.e., design and construction, maintenance, operation, and highway administration. Each category contains four or five scenarios, which are composed of various sub-scenarios. The unified infrastructure data support the application of these scenarios, provided by the life-cycle data integration layer.

An example of scenarios and sub-scenarios is depicted in

Table 4. An example of life-cycle highway application scenarios.

Category	Scenario	Sub-Scenario
Design and Construction	Investigation and survey	Topographical analysis, soil testing, alignment, grading, etc.
	Design	Preliminary design, construction drawing design, design delivery, etc.
	Testing and inspection	Concrete testing, pavement testing, electrical and mechanical engineering testing, etc.
	Construction	Subgrade compaction, surface pavement, construction monitoring and control, etc.
Maintenance	Condition inspection	Daily, routine, periodic, special, and emergency inspections of structures, traffic safety devices, etc.
	Maintenance decision	Automatic generation of maintenance plan, project-level decision, network-level decision, etc.
	Maintenance design	Strengthening design of bridge, maintenance design of asphalt pavement, etc.
	Maintenance execution	Rehabilitative, preventive, special maintenance engineering, etc.
Operation	Traffic monitoring	Network operation monitoring, geological disaster monitoring, structural safety monitoring, etc.
	Trip service	Traffic information service, tunnel operation service, service area operation, etc.
	Emergency aid	Traffic emergency disposal, equipment and material reserve, etc.
	Vehicle–road coordination	Traffic risk warning, traffic incident control service, safe driving behavior reminder, etc.
	Tolling	Mobile payment of toll road, free-flow electronic toll collection on expressway ramp, etc.
Highway administration	Abnormal indivisible load transport	Administration permit, driving behavior supervision, vehicle escort, etc.
	Overload transportation	Inspection station monitoring, command and dispatch, analysis and evaluation, etc.
	Patrol	Building and structure control zone, safety protection zone, etc.

. For instance, the maintenance category consists of four major scenarios: condition inspection, maintenance decision, maintenance design, and maintenance execution. The sub-scenarios of condition inspection include daily, routine, periodic, special, and emergency inspections of structures, traffic safety devices, etc.

3.5. Support System

The two support systems mainly comprise regulations and standards and performance assessment: regulations and standards specify data classification, quality, access rules, security management, etc.; performance assessment evaluates the performance of digital transformation, data quality and interoperability, application effects, etc. The data dictionary of infrastructure is established for the data interoperation requirements, which includes basic information, catalogue of facilities, data attributes and meaning, data structure definition, etc. The dictionary for traffic engineering and facilities is given as an example in [63]. The assessment of infrastructure digitalization is also proposed with a series of factors, such as value, utilization, compliance, consistency, stabilization, etc. (see [64]).

4. Life-Cycle Data Integration Approach

The integration approach is proposed for infrastructure data interoperability across the life-cycle scenarios, with data provided from design and construction, maintenance, operation, and highway administration. According to the integration process in Section 3.3, the detailed integration approach comprises data requirements of life-cycle scenarios, master data identification, data element determination, and the data relationship model.

4.1. Data Requirements

According to the application scenarios (see Section 3.4), the dataflow diagram is applied to describe the interchange data between sub-scenarios and then collect the required and provided data for each scenario. The requirement analysis is divided into the single scenario and life-cycle scenarios.

4.1.1. Analysis of Single Scenario

For each scenario, the sub-scenarios are selected as key domains for data-sharing requirements, and the dataflow diagram is used for the relationship analysis between sub-scenarios and then summarizes the required and provided data. An example of condition inspection is given to analyze the data requirements:

Key sub-scenarios. Condition inspection provides the evaluation quality of infrastructure conditions to support the decision-making plan of maintenance through artificial or automated structural monitoring (see Table 4). The inspection frequency is associated with the structural type, technical condition grad, climate information, etc. The key sub-scenarios consist of automated monitoring, daily inspection, routine inspection, periodic inspection, special inspection, and emergency inspection.

Relationship analysis of sub-scenarios. The dataflow diagram describes the primary data travels of sub-scenarios based on the core business process. The dataflow diagram of condition inspection is summarized in Figure 7; refer to [65,66]. In the figure, sub-scenarios and key processes are denoted as red and gray rectangles with rounded corners, and the datastore of inspection records is represented as right-angle rectangles. For instance, special inspection involves basic information, daily and routine inspection records, automated monitoring, infrastructure damage condition, etc., to generate the special inspection report and provide for the performance assessment.

Additionally,

Table 5. Dataflow from start to end points.

No.	Dataflow	Start Point	End Point	Data Description
1	Basic information	/	Daily and routine inspection, periodic inspection, special inspection, monitoring scheme, emergency inspection	Static infrastructure data, historical records of inspection and maintenance engineering, etc.
2	Daily and routine inspection result	Daily and routine inspection	Field diagnosis	Infrastructure performance, abnormal condition, etc.
3	Daily and routine inspection records	Field diagnosis	Special inspection	Infrastructure performance, abnormal condition, field diagnostic conclusion, special inspection recommendation, maintenance measure, etc.
4	Periodic inspection records	Periodic inspection	Special inspection	Basic situation, inspection result, condition grade, main disease analysis, maintenance measure, etc.
5	Periodic inspection result	Periodic inspection	Technical conditions evaluation	Static infrastructure data, infrastructure performance, etc.
6	Item and requirement	Monitoring scheme	Automated monitoring	Subgrade deformation, bridge structure, tunnel structure, tunnel environment, geological disasters, meteorological disasters, etc.
7	Early-warning information	Automated monitoring	Special inspection	Structural monitoring, geological hazard monitoring, meteorological monitoring, environmental monitoring, etc.
8	Special inspection result	Special inspection	Special performance assessment	Carrying capacity, anti-disaster capacity, traffic capacity, operation safety, material monitoring, etc.
9	Special inspection reports	Special performance assessment	Emergency inspection report	Basic situation, inspection result, condition grade, main disease analysis, maintenance measure, etc.
10	Emergency event	/	Emergency inspection	Disaster report information; road, terrain, and geological environment information; monitoring and forecasting information of daily meteorological and geological disaster, etc.
11	Infrastructure damage condition	Emergency inspection	Emergency repair plans	Scope, type, causes of damage, secondary disasters and potential safety hazards, traffic condition of road, etc.
12	Emergency inspection report	Emergency repair plans	/	Basic situation, disaster situation, risk analysis of secondary disaster, required special performance assessment, emergency repair and operational plans, recommendation of reconstruction projects, etc.

provides the dataflow, start point, end point, and data description to illustrate the dataflow between sub-scenarios, processes, and datastore. Data description depicts the content from the start to the end point in detail. Basic information, involving static infrastructure data, historical records of inspection and maintenance engineering, etc., is provided for daily and routine inspection, periodic inspection, special inspection, monitoring scheme, etc.

Data requirement. In the scenario, the required data are set as the initial datastore of the dataflow diagram, i.e., the start point without input. The provided data are also set as the terminal datastore and partial intermediate data. Note that the terminal is the end point without output. As illustrated in Figure 7, the required and provided condition inspection data can be summarized below.

4.1.2. Analysis of Life-Cycle Scenarios

Required and provided data. The data interchange process of life-cycle scenarios is aggregated from the required and provided data of all-belonged scenarios (i.e., single scenario; see Section 4.1.1).

Table 6. Required and provided data of each category.

No.	Category	Provided Data	Required Data
1	Design andconstruction	Road and structure design information, line scheme, land acquisition and relocation, project schedule, contract management information, construction monitoring and control, road property data, delivery data of road infrastructure, etc.	/
2	Maintenance	Inspection records and reports, road property data, structural monitoring data, condition grade, maintenance plan and execution data, etc.	Significant emergency event, traffic interruption, delivery data of road infrastructure, weight detection, etc.
3	Operation	Traffic flow, abnormal driving behavior and congestion analysis, vehicle identification data, traffic incident, emergency event, emergency resource and plan, toll transaction and audit data, etc.	Traffic condition, road and toll station, traffic engineering and facilities, special transportation vehicle monitoring, patrol information, overload case, etc.
4	Highwayadministration	Carrier information, certificate of vehicles, weight detection of special transportation vehicle, special transportation vehicle monitoring, patrol information, overload case, administration and law enforcement officials, etc.	Traffic interruption, road property data, meteorological information, satellite positioning of vehicle, traffic flow, emergency event, etc.

gives the main data requirements of the four categories across the whole life-cycle application, which is composed of categories, provided data, and required data. Note that the design and construction category only generates the design and delivery data of road infrastructure to others without the required data.

Match of required and provided data. The match between the required set ${\mathcal{R}}_i$ of scenario i and the provided set ${\mathcal{P}}_{i^{*}}$ of scenario $i^{*}$ is formulated on the life-cycle data interchange process. When required data $r_{i,j}\in {\mathcal{R}}_i$ are matched with the provided data $p_{i^{*},j^{*}}\in {\mathcal{P}}_{i^{*}}$, we have

$$\left.\begin{array}{c}i=i^{*},{\mathcal{R}}_i\cap {\mathcal{P}}_{i^{*}}\ne \varnothing \hfill \\ j=j^{*},r_{i,j}=p_{i^{*},j^{*}}\hfill \end{array}\right\}i,i^{*}\in \mathcal{S}$$

(1)

where scenario set $\mathcal{S}$ can add third parties to ensure all required data matches.

An example of the dataflow between design and construction, maintenance, operation, highway administration, and third parties is presented in Figure 8. The third parties consist of the meteorological administration, the transport management department, and mapmaker. Meteorological information, satellite positioning of vehicle, traffic condition, etc., are provided to highway administration and operation scenarios. The circular dataflow describes the data provided and required from the same scenario, such as maintenance plan and execution data, condition grade, and structural monitoring data in maintenance.

4.2. Data Identification

With the required and provided data, the modified data–process matrix is proposed to select the master data on the life-cycle processes. Then, the correlation matrix is established to determine the master data element for interchange. Some factors are also considered to evaluate the infrastructure data-sharing process (see [64]), comprising value, utilization, compliance, consistency, stabilization, validity, etc.

4.2.1. Master Data Identification

The data–process matrix (also named use–create matrix) is the necessary step in business system planning [67,68], and is widely applied to link business functions and data class on the information requirement [69,70], enterprise architecture [71], strategy assessment [72], etc. This paper proposes the modified data–process matrix with service duration to characterize data sharing and usage time across life-cycle scenarios. The scenarios in columns contain design and construction, maintenance, operation and highway administration, and the rows are data classes with categories of the road infrastructure data and related data. The dataflow from single-creator to multi-user involves the short, medium, and long users and the data creator to reflect the service duration.

An example of the life-cycle scenarios and data is illustrated in Figure 9. Each type of road infrastructure (see Section 3.1) is composed of topographical analysis, line scheme, design information, project management, construction and delivery information, etc. The related data (i.e., the key factors of influence on the infrastructure maintenance and operation) include traffic condition, emergency measure, abnormal driving detection, weight detection of special transportation, etc. The blue dotted rectangle represents the main life-cycle information systems. The number of systems is determined by the actual application and we set the number to 4 for clarity and brevity. Notations “C”, “SU”, “MU”, and “LU”, respectively, denote the scenario as the creator, shorter, medium, and longer user to provide and use data, which are denoted by green, orange, light brown, and brown circles in the figure. These three users can be defined as the frequency of data usage and whether or not they use data from other systems. For instance, the shorter user uses the data from the belonged category provided by the others, and the longer user uses the data more than 5 times/day from other systems, or is otherwise set as the medium user.

To identify the master data, some principles for utilization and validity are shown below:

• Source uniqueness. Only one creator is allowed for each datum in the same column.
• High utilization. Data can be frequently utilized in the same system and other systems, which can be reflected by the user type (the shorter, medium, and longer) and number of users (i.e., inside and outside the blue rectangle in Figure 9).
• Data storage. The number of medium and longer users (notations “MU” and “LU”) reflects the long storage duration.
• Data value. Data are necessary for the business function (cannot be missing) and affect management efficiency, operation benefit, driving experience, carbon emission, etc.

For instance, set the following requirements to satisfy high data utilization (in the same line): longer user, medium user from more than two systems, or more than two shorter users inside the system. Then, we have the master data set including line scheme, construction and delivery information, maintenance execution and delivery data, structural monitoring data, traffic interruption information, emergency measure, maintenance plan, patrol information, and overload case.

4.2.2. Data Element Determination

The process data are time-variant across the life-cycle scenarios, and the elements are correlated with the others. So the correlation matrix is proposed to establish the correlation between process data class and the type of infrastructure, and then to determine the master data elements with compliance, consistency, stabilization, etc.

For life-cycle data interchange, data requirements of other processes and infrastructure determine the master data element. The correlation between process data u and $u^{*}$ is divided into strong, medium, and weak with scores from 1 to 3, denoted by the coefficient $c_{u,u^{*}}$. Similarly, the correlation between infrastructure data k and process data u is classified as weak and strong with relevant scores of 1 and 2, and then the coefficient $a_{u,k}$ is estimated.

Let ${\mathcal{D}}_u=\{D_{u,1},\cdots ,D_{u,k},\cdots \}$ be the original data element set of process u, where data element $D_{u,k}$ can be empty. For process data $u\in \mathcal{U}$, the data element set ${\overline{\mathcal{D}}}_{u^{*}}^u$ of other process data $u^{*}$ is formed by modifying the data element ${\overline{D}}_{u,k}$ when the correlation coefficient $c_{u,u^{*}}$ is not less than the threshold value $C\in [1,3]$. ${\overline{D}}_{u,k}$ of infrastructure k is equal to $D_{u,k}$ when the correlation coefficient $a_{u,k}$ is greater or equal to threshold value $A\in [1,2]$. So, we have

$$\begin{array}{c}{\overline{\mathcal{D}}}_{u^{*}}^u=\left\{\begin{array}{cc}\{{\overline{D}}_{u^{*},1},\cdots ,{\overline{D}}_{u^{*},k},\cdots \},& \mathrm{if}{c}_{u,u^{*}}\ge C\hfill \\ \varnothing ,& \mathrm{otherwise}\hfill \end{array}\right.\hfill \\ {\overline{D}}_{u,k}=\left\{\begin{array}{cc}{D}_{u,k},& \mathrm{if}{a}_{u,k}\ge A\hfill \\ \varnothing ,& \mathrm{otherwise}\hfill \end{array}\right.\hfill \\ u,u^{*}\in \mathcal{U},k\in \mathcal{K}\hfill \end{array}$$

(2)

Here, $\mathcal{U}$ and $\mathcal{K}$ are the index sets of process data and infrastructure, respectively. Correlation coefficients $c_{u,u^{*}}$ and $a_{u,k}$ can be calculated as the mean value with a series of matrices, obtained from the survey questionnaire.

With the original data element ${\mathcal{D}}_u$ and modified process data ${\overline{\mathcal{D}}}_{u^{*}}^u$, the data element set $M_u$ of process data u is determined by compliance, consistency, and stabilization, and the function $f(*)$ is given as

$$M_u=argmaxf({\mathcal{D}}_u,{\overline{\mathcal{D}}}_{u^{*}}^u,\cdots ,{\overline{\mathcal{D}}}_{u^{*}}^u)$$

(3)

Note that the principle is determined by the actual decision requirements to formulate the $f(*)$. For instance, the element with the same metadata attribute, value, and source is selected to achieve consistency.

An example is illustrated in Figure 10 to better comprehend the correlation matrix, which contains process data in columns and infrastructure data in rows. The relative correlation of multiple processes on the left is described as three types of blue cycles, i.e., strong, medium, and weak. The center is the relationship between process data and infrastructure, and the strong and weak are denoted by two types of orange diamonds. For the maintenance plan, correlations with other process data are listed below:

• Strong: Structural monitoring data, technical condition grade, maintenance execution, and delivery data.
• Medium: Construction and delivery information, traffic interruption information, and traffic condition.
• Weak: Line scheme and administration permit.

4.3. Data Relationship Model

Using the master data element, a data relationship model is established to describe the infrastructure data correlation from different scenarios to support and display the infrastructure data in application scenarios. The model comprises a static layer of route and structures, a static layer of traffic engineering and facilities, and a dynamic layer, as presented in Figure 11.

The first two static infrastructure layers are formed by infrastructure data and spatial connectivity with physical interconnection, power supply network, communication network, etc. The data can be obtained from the process data of the topographical analysis, line scheme, design information, and construction and delivery information. On the dynamic layer, infrastructure maintenance information, real-time states, and traffic operation are mainly displayed from the process data of maintenance execution and delivery data, traffic interruption information, traffic condition, emergency measure, etc.

5. Results and Discussion

In this section, numerical experiments of the master data calculation process are presented to explicit the data interoperation between highway administration and maintenance, operation, etc. The effectiveness of the life-cycle data integration approach is verified through two methods: master data identification and data element determination. Master data are the core part of data interchange between different scenarios on the life-cycle data integration layer of the infrastructure digitalization framework (see Figure 3).

Two practical highway administration and maintenance systems are adopted for these instances. Accordingly, the required and provided data are summarized via maintenance and highway administration systems; see Appendix A. Then, master data and data elements are determined as follows.

5.1. Master Data Identification Results

In accordance with the provided and required data, condition inspection with six sub-scenarios to create/use process data are visualized in Figure 12. The creator, shorter user, medium user, and longer user are denoted by the notations “C”, “SU”, “MU”, and “LU”. Road infrastructure and related data consist of line scheme, design information, construction and delivery information, structural monitoring data, inspection data, technical condition grade, traffic condition, and emergency event. In the column, six sub-scenarios contain daily and routine inspection, periodic inspection, special inspection, emergency inspection, technical condition grade, and fault reporting information. Combined with the sub-scenario status, the creator/user status of condition inspection is presented in the last column. There are some rules for the combination: when the sub-scenario has creator “C”, set the status of condition inspection as “C”; otherwise, the status follows the priority of “LU” > “MU” > “SU”. For instance, “Structural monitoring data” is created by daily and routine inspection, and is shortly used by other sub-scenarios, so the status of condition inspection on “Structural monitoring data” is set as “C”.

Then, the life-cycle data–process matrix involves 22 sub-scenarios—maintenance and highway administration, construction and operation, etc., as illustrated in Figure 13. The abbreviation of electronic toll collection data is ETC data. Other scenarios are incorporated with a similar analysis of condition inspection as mentioned above (i.e., the red rectangle in the figure). Each column has one creator and three multi-users (composed of shorter, medium, and longer users) denoted by “C”, “SU”, “MU”, and “LU”. Note that the user is set as the shorter user when the user and creator belong to the same category. When the use frequency is greater than 5 times/day, it is set as the longer user; otherwise, it is set as the medium user.

The principles of source uniqueness and high utilization are chosen to select the master data. When the data have one creator, no less than two medium users, or one longer user (i.e., the data in line contain one “C”, “MU” $\ge 2$, or “LU” $\ge 1$), the data have high utilization and are set as the master data. Consequently, the master data set is selected as {Line scheme, Design information, Construction and delivery information, Maintenance execution, Traffic interruption information, Traffic condition, ETC data, Vehicle operation data, Emergency event, Weight detection of special transportation}, i.e., the red color in the figure.

5.2. Data Element Determination Results

Next, the correlation matrix is formulated to depict the correlation between the process data and infrastructure data as illustrated in Figure 14. Note that this correlation between process data and infrastructure data mainly depends on standards and workflow regulations. We recommend survey questionnaires to obtain an accurate value of this correlation. The process data in line are obtained in maintenance and highway administration, and infrastructure data in the column consist of route, structures, traffic safety facilities, mechanical and electrical equipment, and service facilities. On the left side, the correlation between different process data is classified into three levels of strong, medium, and weak. For instance, “Construction and delivery information” has a strong influence on “Maintenance design”; there is a medium effect on “Structural monitoring data”, “Inspection data”, “Technical condition grade”, etc., but a weak effect on “Patrol data”, “Maintenance plan”, etc.

In the figure, strong and weak correlations between each process datum and infrastructure datum are denoted by solid and hollow orange diamonds, respectively. The process data of “Design information”, “Construction and delivery information”, and “Structural monitoring data” strongly correlate with all infrastructure, and other data only have a strong or weak correlation with parts of infrastructure data. “ETC data” only have a weak correlation with route data, while “Case data” have strong and weak correlations with route data and structure data.

The data element $D_{u,k}$ of process data $u\in \{1,19\}$ and infrastructure data $k\in \{1,5\}$ is summarized. For instance, data element $D_{1,1}$ of “Line scheme” and route, and $D_{2,2}$ of “Structural monitoring data” and structure are presented below:

$$\begin{array}{cc}\hfill & D_{1,1}=\{\mathrm{route}\mathrm{name}, \mathrm{starting}\mathrm{mileage}, \mathrm{ending}\mathrm{mileage}\};\hfill \\ \hfill & D_{2,2}=\{\mathrm{damage}\mathrm{situation}\mathrm{of}\mathrm{structure}, \mathrm{damage}\mathrm{type}\mathrm{of}\mathrm{structure}, \mathrm{number}\mathrm{of}\mathrm{damages},\hfill \\ \hfill & \mathrm{damage}\mathrm{condition}\mathrm{grade}\mathrm{of}\mathrm{structure}\}.\hfill \end{array}$$

Then, according to the correlation matrix (see Figure 14), the principle of consistency (i.e., same metadata attribute) is selected to determine the master data element. Set threshold value C as 2 and the modified data element set with medium and strong correlations is selected when correlation coefficient $c_u^{u^{*}}$ is not less than 2. The threshold value A is set as 2, i.e., only the strong correlation between process data and infrastructure data is selected. The master data of the “Weight detection of special transportation” (i.e., $u=18$) are given below to illustrate the calculation process.

The master data $M_{18}$ are dependent on the original data element ${\mathcal{D}}_{18}$ and have medium correlations with “Inspection data” ${\overline{\mathcal{D}}}_6^{18}$, “ETC data” ${\overline{\mathcal{D}}}_{13}^{18}$, “Administration permit” ${\overline{\mathcal{D}}}_{16}^{18}$, and “Special transportation vehicle monitoring” ${\overline{\mathcal{D}}}_{17}^{18}$, as well as a strong correlation with “Case data” ${\overline{\mathcal{D}}}_{19}^{18}$. With principles of consistency and value (denoted by $f(*)$), the master data of “Weight detection of special transportation” can be obtained when those data elements have the same metadata attribute. Note that ${\overline{\mathcal{D}}}_{16}^{18}$ and ${\overline{\mathcal{D}}}_{17}^{18}$ are empty sets because these two process data cannot contain the strong correlation with infrastructure data (because the threshold value A is 2). Thus, we have

$$M_{18}=argmaxf({\mathcal{D}}_{18},{\overline{\mathcal{D}}}_6^{18},{\overline{\mathcal{D}}}_{13}^{18},{\overline{\mathcal{D}}}_{19}^{18})$$

where

$$\begin{array}{c}{\overline{\mathcal{D}}}_6^{18}=\{D_{6,1},D_{6,2},D_{6,3},D_{6,4},D_{6,5}\}\hfill \\ {\overline{\mathcal{D}}}_{13}^{18}=\left\{D_{13,1}\right\}\hfill \\ {\overline{\mathcal{D}}}_{19}^{18}=\left\{D_{19,1}\right\}\hfill \\ {\mathcal{D}}_{18}=\{D_{18,1},D_{18,4}\}\hfill \end{array}$$

Table 7. Original data element of “Inspection data”, “ETC data”, “Weight detection of special transportation”, and “Case data”.

Index u	Process Data	Data Element ${\mathcal{D}}_{\mathit{u}}$
6	Inspection data	$D_{6,1}:$ Inspection time, route ID, route name, inspection starting and ending mileage, weather condition, etc.
		$D_{6,2}:$ Inspection time, inspection position, disease type of structure, number of diseases, disease range, size, cause analysis, process description, treatment advice, inspection personnel, inspection organization, etc.
		$D_{6,3}:$ Inspection time, inspection item, damage position, damage type, whether discontinuity, damaged condition, failures cause, treatment measures, inspection personnel, inspection organization, etc.
		$D_{6,4}:$ Inspection time, lane ID, inspection item, equipment ID, operational status, operating environment, whether satisfy technical requirement, warning message checking, abnormal status description, fault cause, reporting department, inspection personnel, inspection organization, etc.
13	ETC data	$D_{13,1}:$ Entrance toll gate, entrance time, exit toll gate, exit time, vehicle license number, carrying capacity, cargo type, vehicle trajectory, toll cost, etc.
18	Weight detection of special transportation	$D_{18,1}:$ Overload station ID, station name, detection direction, administrative region, mileage of station, longitude and latitude of station, etc.
		$D_{18,4}:$ Weighing equipment ID, lane ID, detected vehicle type, detection time, detected vehicle speed, total weight of cargo, detected number of axles, etc.
19	Case data	$D_{19,1}:$ Administrative region, organization of administrative penalty, case type, violation time, violation place, punishment basis, punishment time, punishment penalty, driver name, license number, transport certificate number, cargo source company, etc.

shows the original data element of “Inspection data” ${\mathcal{D}}_6$, “ETC data” ${\mathcal{D}}_{13}$, “Weight detection of special transportation” ${\mathcal{D}}_{18}$, and “Case data” ${\mathcal{D}}_{19}$ for the master data $M_{18}$ calculation. Index is the number index u of process data in Figure 14. Note that the original data of $D_{6,1}, D_{6,2}, D_{6,3}, D_{6,4}, D_{6,5}$, respectively, denote the data element of route, structure, traffic safety facility, and mechanical and electric equipment. For instance, $D_{6,4}$ contains equipment ID, operational status, fault cause, etc., to describe the inspection of mechanical and electric equipment.

For consistency and value, the same and valuable metadata attributes are selected from ${\overline{\mathcal{D}}}_6^{18}$, ${\overline{\mathcal{D}}}_{13}^{18}$, and ${\overline{\mathcal{D}}}_{19}^{18}$, and then the original data ${\mathcal{D}}_{18}$ are extended to obtain the master data. Hence, $M_{18}$ contains two parts: the route, and mechanical and electrical equipment. They are given below:

$$\begin{array}{c}\hfill M_{18}=\{M_{18}^1, M_{18}^4\}\end{array}$$

where $M_{18}^1$ and $M_{18}^4$ correspond to $D_{6,1}$ and $D_{18,1}$, and $D_{6,4}$ and $D_{18,4}$. So, we have the following:

$M_{18}^1=${route ID, route name, overload station ID, station name, mileage of station, detection direction, entrance and exit toll gate, entrance and exit time, vehicle trajectory, vehicle license number, carrying capacity, cargo type, violate time, punishment type, cargo source company}.

$M_{18}^3=${lane ID, equipment ID, operational status, operating environment, detected vehicle type, detection time, detected vehicle speed, total weight of cargo, detected number of axles}.

6. Conclusions

Highway asset management encounters difficulty with the hundreds of types of infrastructure. To achieve maximal data sustainability and minimal cost, infrastructure digitalization is the main method used to integrate information resources and support life-cycle application scenarios. In this paper, the digital requirements are analyzed from the literature and through survey questionnaires, and a research methodology with a six-step procedure is proposed to guide the development of the life-cycle framework. The infrastructure digitalization framework is designed with four layers and two support systems, i.e., road infrastructure and other data, data governance, life-cycle data integration, application scenarios, regulations and standards, and performance assessment. Focused on data integration, an approach with the modified data–process matrix, correlation matrix, and selected factors is first developed to identify master data and the elements. Static and dynamic data are connected in the data relationship model from multi-source infrastructure data. Finally, we verify the effectiveness of the life-cycle data integration approach in numerical experiments to guide the data interoperation between highway administration and maintenance, operation, etc.

Faced with transportation digitalization and transformation, some potential future developments can also be considered in highway asset management. First, a performance assessment system is required to establish a set of detailed evaluation indicators to guide the highway digital transformation in terms of economic and social benefits, like sustainability, values, and outcomes. Second, highway digital transformation involves not only physical infrastructure but also organizational transformation, such as approval process simplification, people’s digital ability, compatible regulation, etc. Third, highway digitalization is a new high-quality means of productivity that promotes society’s economic growth and infrastructure, and other data that act as a digital asset will serve in the integration of transportation with tourism, logistics, commercial business, etc.