An Integrated Data-Driven System for Digital Bridge Management

Abstract

Relational databases are established and widespread tools for storing and managing information. The efficient collection of information in a database appears to be a promising solution for bridge management (BM), thus facilitating the digital transition. The Italian regulatory framework on infrastructure operation and maintenance (O&M) is complex and is constantly being updated. The current plan for implementing its guidelines envisages that infrastructure managers, also on a regional scale, equip themselves with their own digital database for BM. Within this context, this research proposes an integrated methodology that collects information derived from project documentation, in situ inspections, digital surveys, and monitoring and field tests in a queryable database for digitalising, georeferencing, and creating models of many bridges. Structured query language (SQL) statements are used to efficiently export specific shared information, enabling network cross-analysis. Furthermore, the database represents the source of a geographic information system (GIS) catalogue and the basis for deriving models for building information modelling (BIM). The methodology focuses on the infrastructural context of the Lazio region, Italy, the first beneficiary of the research.

1. Introduction

Bridges are fundamental elements of infrastructure worldwide, providing vital links for transportation, mobility, and the development of the economies of entire countries. Like all civil infrastructures, bridges undergo ageing processes and experience deterioration over time, thereby becoming a significant safety risk [1].

Over time and around the world, several bridge collapses have been observed due to multiple causes [2]. Historical data show that in the United States between 1989 and 2000, more than 500 collapses occurred [3]; in China, between 2000 and 2014, 302 catastrophic highway bridge collapses occurred [4], 157 of which occurred between January 2000 and March 2012, excluding those caused by earthquakes [5]; and in India, more than 2130 bridges failed to provide the expected service or even collapsed during various stages of construction from 1977 to 2017 [6].

These collapses have generated the need to establish efficient tools for the maintenance and management of bridges, which has led to the development of several bridge management systems (BMSs), including the preservation, optimization and network information system (PONTIS [7]) in the United States, the Japanese bridge management system (J-BMS [8]), and the BaTMan (Sweden), BAUT (Austria), DANBRO (Denmark [9]), KUBA (Switzerland), SIB-Bauwerke (Germany), and SMIS (United Kingdom) [10] systems, with the most recent and innovative one proposed by Li et al., 2023 [11]. The latter is a BIM-based BMS in which a 3D BIM library is implemented, allowing for managing and visualising defects in bridge models. All the aforementioned BMSs were developed via collaborations between universities, private individuals, and investee companies.

In Italy, the dramatic collapse of the Polcevera Bridge in Genoa in 2018 gave a strong impetus for the development of guidelines and systems for bridge safeguarding. In the same year, the National Computer Archive of Public Works (AINOP) was created [12], and two years later, the Ministry of Infrastructure and Transport (MIT) issued the Guidelines for Risk Classification and Management, Safety Assessment and Monitoring of Existing Bridges [13,14]. Furthermore, all infrastructure managers, including regional-scale managers, have been required to have their own digital database for bridge management. Consequently, the Autostrade Group enhanced their ARGO^® monitoring system; ANAS S.p.A. improved the M.R.C.S.^®, SOAWE^®, and RAM^® systems [15]; and Ferrovie dello Stato Italiane S.p.A. developed the DOMUS^® system.

Almost all BMSs are based on data-driven approaches and rely on the use of a unified database (DB), which features precise and standardized data organization [16] and serves as a prerequisite for implementing semi-automatic procedures and leading managers to the implementation of the most advanced technologies for bridge monitoring and maintenance. In this field, relational databases (RDBs) are powerful tools for storing, organizing, and managing large amounts of data related to bridge maintenance, inspection, and repair [11]. These features make it possible to perform a complete large-scale analysis based on structured query language (SQL) statements [17].

Within this framework, the present paper proposes an integrated data-driven approach for bridge management digitalization at the regional scale, coherent with the multi-level approach for the safety management of existing bridges outlined in the abovementioned guidelines published by the Italian MIT [13,14]. A unified relational database (RDB) is used to derive, through SQL cross-analysis queries, the fundamental data for BIM [18,19,20] design, geographic information system (GIS) [21,22] cataloguing, and calculations through existing algorithms [23,24]. In particular, the information stored in the RDB is automatically made available in GIS and allows the automatic generation of preliminary BIM models, which can be enriched with multi-source data derived from the use of the latest technologies. These include (i) sensing techniques, e.g., sensors [25,26] and laser scanners [27,28,29], useful in the phase of geometric characterization of the artefact and identification of its state of damage; (ii) space-based techniques such as interferometric synthetic aperture radar (InSAR) [30,31,32,33], enabling the measurement of millimetre settlements of the structure and the souring area; and (iii) analytical models, such as mechanical models [34,35], machine learning models [36,37,38], and multi-level monitoring algorithms [39,40,41,42]. Compared to existing literature, the methodology intends to enrich BIM models and GIS representation with information on the defect level of individual structural elements of a bridge and the attention class of the entire structure according to an algorithm in which the relational DB plays a central role.

The proposed approach focuses on the bridge assets of the Lazio region, Italy, the first beneficiary of the study.

2. Digital Bridge Management Methodology

The present research provides an effective and time-efficient methodology that, starting from a well-structured RDB, enables the creation of a digital BIM and GIS-implementable model of many bridges. The methodology, summarized in Figure 1, is designed to be applied to the existing road bridges located in the Lazio region in Italy, in the framework of the MLAZIO project. The main goal of the project, developed by the Structures and Road Infrastructures research groups of the Department of Civil, Computer Science and Aeronautical Technologies Engineering of Roma Tre University, is to provide the regional infrastructure manager with a multi-level approach for risk assessment, both static and seismic, and the management of its infrastructural network, in accordance with the Italian Ministry of Infrastructure and Transport (MIT) [13,14].

The proposed approach is based on the preliminary organization of data within a unified relational database (RDB), collecting information associated with each bridge, its elements, and the territorial context in which it is set. Following this multi-level approach suggested by Italian MIT guidelines, data are derived, first, from available documentation on the infrastructure (including design drawings, construction details, information collected in previous on-site inspections, material data, etc.), and are enriched by in situ inspections, from which preliminary information on the work (geometry, materials, location, administration, viability, geomorphological data, etc.) are obtained. To optimise the data collection phase, a digital survey is used to obtain a 3D model of the structure, which can be assessed to obtain geometric and defect data (the latter are used in more advanced stages of the methodology).

The data are geo-referenced and are automatically imported into a GIS environment. Starting from the basic information gathered in the RDB, extrapolated through SQL queries and analyses, it is possible to automatically obtain preliminary BIM models of bridges via appropriate visual scripting tools.

The next step of the methodology, currently in progress, involves developing digital twins (DTs) of bridges derived from BIM models. The BIM models are enhanced by importing defect data derived from inspection notes and digital surveys and, in perspective, data from structural monitoring operations. DTs are designed to be remotely assessed, in order to examine the current on-site conditions.

The advantage of the implemented methodology is its scalability, as once fine-tuned for one bridge, it is immediately replicable for the remaining bridge assets.

The methodology applied shows that the virtualization of information from existing bridges is feasible, fast, and simple. It exploits the potential of the organization of initial data within the relational database, which is a consolidated tool for collecting all the information held by the individual Departments of Transport (DoTs).

In the following subsections, all the steps included in the presented methodology (Figure 1) are described in detail.

2.1. Initial Data Sources

In the proposed digital process, the relational database (RDB) plays the important role of a catalyst, by representing an efficient starting point for the final goal of the automatic generation of “primitive” BIM models of the whole bridge stock.

As a starting point, the RDB is fed with initial data, consisting of design documentation, data from in situ inspections, and information derived through digital surveys.

Design Documentation: This information includes existing documentation on design calculations and drawings, design building codes used for the construction of the bridge, past maintenance and restoration operations, historical photographic documentation, and the history of damage suffered by the work in operation (man-made damage, such as impact damage or natural damage caused by fire, earthquakes, hydrological phenomena, and landslides).

In Situ Inspections: A first form of enrichment of the information contained in the database comes from on-site inspections. They are aimed at verifying the reliability of the collected design documentation as well as gathering further lacking information about geometric and structural characteristics of the bridge and useful data on the location site. A further scope is to visually assess the degree of preservation of the bridge on site. The latter operation is also aided by performing a digital survey, as explained in the next section.

The inspection information is collected in digital format, through the help of specific digital forms designed to automatically feed into the RDB.

Digital Survey: The 3D survey based on the use of laser scanning technology and digital photogrammetry provides a high-precision 3D model of the bridge, in the format of a point cloud and textured model (Figure 2).

The point cloud is used to derive the actual geometry of the infrastructure as well as shape defects and deformations. This can be carried out by sectioning the point cloud and processing sections with Computer-Aided Design (CAD) software, also by means of adaptive processes [43,44,45,46].

On the other hand, the 3D textured model provides detailed information on the damage state of the construction, including surface damages and crack patterns. This can be acquired by remotely inspecting the model through 3D viewer software, even with the use of artificial intelligence tools [47,48]. These features prospectively contribute to enrich the digital twin.

The most adopted solution involves the combination of aerial photogrammetry through the use of unmanned aerial vehicles (UAVs) [49] and terrestrial laser scanning [27]. For the implementation of the proposed methodology, regarding aerial photogrammetry, a DJI Mavic Mini 2^® drone, characterized by a take-off mass of 249 and equipped with a 12 MPixel camera with a 1/2.3″ CMOS sensor, was used. Frames were processed with the software Agisoft Metashape Professonal^® to obtain point clouds and textured models. A Teledyne Optech Polaris TLS^® was used for terrestrial laser scanning, with a pulsed range measurement principle, 1550 nm wavelength (near infrared), 250 m/750 m/2000 m max range capacity, and a corresponding sample collection rate of 500 kHz/200 kHz/50 kHz. Point clouds were derived through Atlas Scan^®.

2.2. Relational Database (RDB)

The database was built in Microsoft Access 2019^® and was designed to be implementable by both expert users, capable of modifying its content and functionality, and operators with basic computer skills interested in its complete use (Figure 3).

The following standard process was adopted for RDB development [50]:

• problem analysis;
• conceptual design (E-R model);
• logical design (relational logic scheme);
• physical design and implementation;
• implementation of applications.

In the problem analysis phase, the three following macro-categories of information were identified (Figure 4):

• Bridge-related data: containing information on the bridge and its context;
• Bridge element data: containing information on the elements that constitute the bridge;
• Element inspection data: concerning inspections carried out and defects found.

A fundamental entity for the first macro-category (bridge-related data) of information is “administration data”, whose attributes (and relative type) are detailed in

Table 1. Administration data entity belonging to the bridge-related data macro-category.

Table	Label	Type
Administration data	Id	bigserial
	MLAZIO item code	varchar (38)
	Identifier for the manager/owner	varchar (50)
	Type of infrastructure to which the work belongs	varchar (50)
	Belonging road	varchar (50)
	Administrative classification	varchar (50)
	Managing authority classification	varchar (50)
	Bypassed element	varchar (50)
	Maintenance centre	varchar (50)
	Start of the bridge	varchar (50)
	End of the bridge	varchar (50)
	Name of the bridge	varchar (50)
	Picture of the bridge	doc
	Notes	varchar (5000)

. All the other entities (geographical location data, project data, geometry data, and satellite-monitoring data) of the present macro-categories refer to this main entity, in which the bridge is uniquely identified according to the MLAZIO item code (see the next section for further explanation).

Different approaches for bridge component organization may be adopted by the Departments of Transport (DoTs) of each state. In the present methodology, the approach provided by the Italian Ministry of Infrastructure and Transport (MIT) guidelines was adopted. For the sake of an example, Figure 5 shows the entity-relations model of the bridge element data macro-category.

An example of an entity representing the pillar structural member is shown in

Table 2. Pillar entity belonging to the bridge element data macro-category.

Table	Label	Type
Pillar	Id	bigserial
	Id of bridge	int
	Relative number	int
	Unique code	varchar (500)
	Element family	varchar (50)
	Related defects	varchar (50)
	Coordinates	varchar (50)
	Construction material	varchar (100)
	Shape typology	varchar (100)
	Critical cross-section’s surface	decimal (6,2)
	Moment of inertia	decimal (6,2)
	Resistance modulus	decimal (6,2)
	Height	decimal (6,2)
	Presence of pulvinus	bool
	Type of foundations	varchar (100)
	Defect level	varchar (50)

.

The central entity for the third macro-category of information is the “defect inspection”, in which the attributes of the individual defects found on the bridge are collected.

Table 3. Defect inspection entity belonging to the element inspection data macro-category.

Table	Label	Type
Defect Inspection	Id	bigserial
	Unique code	varchar (500)
	Detector technician	varchar (50)
	Date of inspection	date
	Defect code	varchar (50)
	Description	varchar (50)
	Weight	int
	Presence	bool
	K1 extension	varchar (50)
	K2 intensity	varchar (50)
	Affect statics	bool
	Defect	varchar (100)
	Defect level	varchar (50)
	Extraordinary inspection	bool
	Notes	varchar (1000)
	Photo N progressive code	varchar (50)
	Photo N attachment	doc
	Photo N caption	varchar (50)

shows the entity in detail.

As previously mentioned, a combined alphanumeric code, named the MLAZIO item code, has been implemented to uniquely manage the information of the individual elements. The code consists of ten characters for each level of elements (Figure 5 and Figure 6,

Table 4. Examples of MLAZIO item codes.

MLAZIO Item Code	Label	Structural Units
bri00001aa_abu00001aa	ABU1	Abutment
bri00001aa_abu00002aa	ABU2
bri00001aa_par00001aa	PAR1	Partition beam
bri00001aa_par00002aa	PAR2
bri00001aa_par00003aa	PAR3
bri00001aa_spa00001aa	SPA1	Span
bri00001aa_spa00002aa	SPA2
bri00001aa_spa00003aa	SPA3
bri00001aa_spa00001aa_sla00001aa	SLA1	Slab
bri00001aa_spa00002aa_sla00001aa	SLA2
bri00001aa_spa00003aa_sla00001aa	SLA3
bri00001aa_spa00001aa_bea00001aa	BEA1	Beam
bri00001aa_spa00001aa_bea00002aa	BEA2
bri00001aa_spa00001aa_bea00003aa	BEA3
bri00001aa_spa00001aa_bea00004aa	BEA4
bri00001aa_spa00001aa_bea00005aa	BEA5
bri00001aa_pil00001aa	PIL1	Pillar
bri00001aa_pil00002aa	PIL2
bri00001aa_joi00001aa	JOI1	Joint
bri00001aa_joi00002aa	JOI2
bri00001aa_joi00003aa	JOI3
bri00001aa_joi00004aa	JOI4

). In the case of a beam, for instance, the item code is: bri00001aa_spa00001aa_bea00001aa, where the first ten characters (bri00001aa) refer to the bridge level, the other ten (spa00001aa) are relative to level 1 elements (span of the bridge to which the beam belongs), and the last ten (bea00001aa) refer to level 2 elements (the beam itself). Each part of the code is structured as follows (reference to the first section of the beam’s item code bri00001aa): the first three characters represent the element’s abbreviation (bri), the subsequent five characters (00001) are numeric and indicate the element’s indexing within the reference system, and the final two characters (aa) enhance possible modifications undergone by the element.

Some MLAZIO item code examples are shown in Table 4.

The numbering in the coding of the elements works as follows (Figure 6):

• The origin and the end of the bridge to which the two end joints of the bridge correspond are defined based on the progressive kilometre distance. In particular, the origin is associated with the lower progressive kilometre distance, while the end corresponds to the major progressive kilometre distance;
• The reference system (x,y,z) of the bridge is fixed at the ground level of the bridge (Figure 6c);
• The x-axis is parallel to the longitudinal axis (Deck axis in Figure 6a) of the bridge and has the direction of increasing progressives;
• The y-axis, perpendicular to the x-axis, has direction in the inward direction of the bridge;
• The z-axis is pointed upwards.

The data entry into the database and consultation takes place via the user interface (UI) of the computer tool, constructed using Microsoft Access^® forms (Figure 3).

2.3. Geographic Information System (GIS)

When working on bridge data and considering the interactions that these works have with the territory, a GIS–database connection is indispensable, which allows working with database tables directly in the GIS environment. The database connection can be created with the database supported by the GIS system.

To create the database connection, the following general prerequisites must be met:

• Have an appropriate connector;
• Have the appropriate privileges granted by the database administrator;
• Authenticate the connection using a username and a password.

The software used for the connection is ArcGIS^® (v. 3.1.2), which, through the OLE DB (object linking and embedding database) equipped with the Microsoft Access database engine 2016 redistributable driver, reads and writes .accdb files in Microsoft Access^® format. This allows the sources of fundamental information for bridge visualisation and management to be directly available in the GIS catalogue.

GIS allows each bridge to be spatially located and associated with its corresponding geographical coordinates, referenced to the World Geodetic System 1984 (WGS 84). As a result, at the end of the procedure, georeferenced point icons can be displayed and associated with each bridge, enabling their accurate spatial representation within the GIS environment. The implemented GIS catalogue allows rapid visualization and geolocation of all the bridges located in the regional territory covered by the investigation. Georeferenced viaducts can be accurately identified using cartographic reference. Additionally, it enables efficient management of large volumes of data and information associated with bridge assets. These data can be directly viewed, modified, and analysed within the GIS environment through the investigation of the “attribute table”, which is created from the extracted information stored in the database, which encompasses the comprehensive information outlined in Section 3.1. All the characteristics of the structural elements of each bridge can be taken into consideration, including the viaduct ID, geographical coordinates, structural typology, and length. Therefore, all this information can be displayed on a dedicated table in the GIS environment in an automatic manner once the icon relating to the bridge of interest has been selected.

In addition, the authors used the same GIS catalogue to integrate information on the structural health and the degraded state of the bridge. The GIS catalogue contains the dates of on-site inspections as well as the outcomes of possible monitoring analyses, including remote sensing data derived through satellite InSAR technology.

The decision to develop this advanced bridge catalogue as a GIS-based computer tool is motivated by the necessity to effectively acquire, visualize, process, and update geospatially referenced data about bridge structures. This implies the integration of various data sources such as Base Maps, satellite optical imagery, and additional relevant information that could be easily imported within the GIS environment. Moreover, the system incorporated historical archives of natural hazards and past phenomena such as landslides, earthquakes, subsidence, and floods, thus establishing a comprehensive and unified framework. The software architecture is accurately designed to facilitate data retrieval from the external SQL database implemented in Microsoft Access^®. Consequently, upon query, the GIS catalogue extracts and visualizes the pertinent information associated with the targeted bridge, ensuring useful and streamlined access to the required data. It should be noted that the abovementioned operation is very complex and difficult to implement using other types of analysis tools and visualization software or platforms. For this reason, the use of a GIS catalogue and GIS environments allows the management of a large amount of data, integrating several databases into a unique interoperable system in an innovative way, through established procedures. The implemented procedure increases the effectiveness and efficiency of data analysis activities and the planning of on-site inspections or the implementation of ground-based investigations (e.g., network-wide visualization of findings of indices of deterioration from site inspections, non-destructive surveys).

Already in the early design and definition phases of the GIS-based catalogue, the need to use an operational IT tool capable of automatically reading the information from the project database is considered. Therefore, it is necessary to combine IT knowledge appropriate for data analysis and database creation and management with an application field appropriate for bridge management and maintenance to create a useful application tool that allows the construction, management, and localization of all the bridges at the regional network level.

The digital GIS catalogue conceived is defined based on two information levels: a first level consisting of general information, and a second level with more detailed information, up to and including information on structural elements. The information gathered uses ever-increasing data sources, updated and upgradable with data from site inspections and non-destructive technologies.

An example of GIS-generated output is illustrated in Figure 7, which showcases bridges within a regional portfolio, emphasizing attention classes (see Section 3.1 for further details). The icons representing the bridges are colour-coded according to their attention class: red indicates high attention, orange medium-high, yellow medium, light green medium-low, and dark green low.

2.4. Building Information Modelling (BIM)

A semi-automatic algorithm was developed for the creation of BIM models starting from the available information, gathered in the relational database.

BIM models are generated by extracting data through the extract, transform, and load (ETL) process, which outputs a .csv file that is ready to be read by the visual scripting program for the creation of the BIM model.

It is crucial to define the database parameters to consider during the BIM modelling process, the procedure, and the level of geometric definition. The level of development of the digital objects that make up the models defines the quantity and quality of their information content and is functional in achieving the objectives of the model to which they refer. Nature, quantity, quality, and stability of data and information constituting each object of a model define its level of development.

The implementation of building information modelling (BIM) holds significant promise, shedding light on the prospective evolution of design, management, and monitoring phases within the realm of transport assets. This assertion finds support in numerous contemporary research studies that delve into the application of BIM for monitoring, maintenance, and the seamless integration of non-destructive testing (NDT) data in the context of transport assets, including bridges and viaducts. Notably, these studies have advanced considerably in recent years. It is noteworthy, however, that only a limited number of studies have concentrated on the development of an automated procedure for generating BIM models of infrastructures, employing semi-automatic approaches. Furthermore, in recent years, novel transport asset management applications based on BIM procedures have been developed. This is evidenced by several pioneering research studies, as highlighted by [51,52,53,54].

To define and initialize the BIM modelling phase, it is first necessary that the elements constituting the model can receive input data, unambiguously defined by the technical operator who is carrying out the digitalization action, and then return output information when analysing the model itself. The characteristics of these elements depend on the external parameters assigned to the model by reading data from the database, which in turn are fed into the creation of the digital information model.

The first modelling phase consists of the creation of a ‘family’ that characterizes the modelling element geometrically and then informatively.

The element families are then defined and created from scratch. Adaptive families are used, which allow parameters to be entered to define the correct position of the elements within the model.

By using customizable, programmed scripts, it is possible to create parametric BIM models. The programming of these scripts, following the compilation of the fields in the database and the modelling of the individual parts of the bridge, enables the correct positioning of the elements and the correct input of qualitative and quantitative data with the subsequent development of an informative BIM model. To this end, Dynamo^® software (v. 2.13.1.3891) is used, which is equipped with a graphical programming interface to customize the workflow within the Revit 2023^® application. It allows programming in the Python language using ‘nodes’ which are nothing more than blocks of code that perform specific tasks, providing the correct inputs and returning the corresponding outputs after executing the code; they can be used in other nodes as cascading inputs or can be handled directly in Revit^® or even in other programmers. This procedure of composing nodes and linking inputs corresponds to the creation of a script. The Dynamo^® application allows for the creation of new workflows that allow for the alternative handling of data, enabling the direct input of the file extracted from the database or the automatic compilation of certain parameters according to defined conditions.

The following steps are needed for the parametric BIM modelling of a bridge:

• Creation of the algorithm that reads the Cartesian x, y, and z coordinates of a linear infrastructure from the Excel^® file containing the information extracted from the database;
• Creation of a layout from the latter;
• Definition of further calculation scripts for the correct dynamic positioning of the bridge elements from the point layout.

In this way, it is possible to obtain a parametric BIM model whose characteristics change dynamically according to the input fields entered in the database. This allows the code to be applied repeatedly for any bridge, guaranteeing continuous control of the bridge, which means that any change or update would be reflected semi-automatically on the model itself; thus, all that is required is to update the read-out file extracted from the database.

Once the methodological approach has been defined, the authors proceeded with the development phase of the complete code, which was created by combining the following code components:

• Script for creating a layout from known coordinate points;
• Script for dynamic assignment of opera parts;
• Script for automated parameter reading from the database.

Once the various code blocks have been created, the union of all parts is performed, thus obtaining a single, complete script. The union of all the elements described above constitutes and defines the realization of a semi-automatic algorithm for the generation of BIM models from the information obtainable and available from the data contained in the bridge database (Figure 8).

3. Data Analysis

The proposed RDB-based methodology allows for digital, fast, and network-wide data analysis.

The research context in which the proposed methodology is applied has as its main objective the creation of a procedure for the classification of bridges and viaducts on a territorial scale through the simplified and expeditious estimation of their structural health.

Within this framework, the following sections show the application of the methodology for the automatic calculation of the attention class, which, according to the Italian Ministry of Infrastructure and Transport Guidelines [13,14], is a synthetic indicator representative of the structural health of the bridge.

3.1. Analysis Using the Database

The attention class is an approximate estimate of the risk factors, useful for the definition of an order of priority for in-depth investigations/checks/inspections to be carried out on bridges.

The details of the fields used for the calculation of the static and seismic attention classes, both contributing to the overall attention class of the bridge, are described below. The algorithm is implemented in Microsoft Access^®, using the Visual Basic for Applications (VBA) language.

For the calculation of the static attention class, it is necessary to combine three different classes: the vulnerability class, hazard class, and exposure class.

Vulnerability considers the inherent properties of the bridge, both geometrically and health-wise. For this reason, the parameters that contribute to the definition of the vulnerability class are, for example, the type of deck, the length of the span, the defective condition, etc.

Hazard is the potential for harm or an adverse effect. It depends on boundary conditions and is therefore closely related to the context and location of the bridge. Parameters that contribute to the definition of the hazard class are, for example, the seismicity of the area or the maximum loads passing over the bridge.

Finally, the exposure depends mainly on the consequences of damaging the bridge. For this reason, the main parameters involved in determining the exposure class are, for example, the average daily traffic or the type of entity bypassed.

The vulnerability class is evaluated through the function calculationStaticVulnerability, in which the following variables are involved:

vulnerability = calculationStaticVulnerability (def_lev deg_dev, L, cat_br, des_ye, st_sch, mat, max_L)

• def_lev: overall defect level of the bridge;
• deg_dev: year of design or completion;
• L: total bridge length;
• cat_br: bridge category;
• des_ye: design year;
• st_sch: static scheme of the structure;
• mat: type of material characterizing the bridge;
• max_L: longest span.

The hazard class is evaluated through the function calculationStaticHazard, in which the following variables are involved:

hazard = calculationStaticHazard (p_class, adt)

• p_class: permissible through-load class (category according to regulations depending on load limitations);
• adt: average daily commercial vehicle traffic on a single lane.

Finally, the variables required for the calculation of the exposure class are listed below:

• exposure = calculationStaticExposure (av_L, adt, bypass_class, r_alt)
• av_L: average span;
• adt: average daily traffic;
• bypass_class: importance of the bypassed body;
• r_alt: presence of road alternatives.

Along the same vein, the seismic attention class is carried out by the combination of the three classes: the vulnerability class, hazard class, and exposure class.

Concerning the seismic vulnerability calculation, the following variables are considered:

vulnerability_seis = calculationSeismicVulnerability (mat, n_spans, st_sch, L, seis_non, liv_dif)

• mat: type of material characterising the bridge;
• n_spans: number of spans;
• st_sch: structure with isostatic or hyperstatic static scheme;
• L: total bridge length;
• seis_non: seismic or non-seismic design;
• def_lev: overall defect level of the bridge.

The variables required for the seismic hazard calculation are listed below:

hazard_seis = calculatingSeismicHazard (ag, to_cat, und_cat)

• ag: seismicity area as a function of peak ground acceleration;
• to_cat: topographical category (A–E);
• sub_cat: subsoil category.

Finally, the two variables considered in the seismic exposure calculation are:

exposure_seis = calculationSeismicExposure (ex_class, st_class)

• ex_class: static exposure class;
• st_class: strategic class of the bridge.

All these parameters are combined following the prescription provided in the Italian Ministry of Infrastructure and Transport Guidelines [13,14] to carry out the attention class of the bridge.

As described above, one of the principal input data for obtaining the attention class is the defect level (DL).

This is a qualitative indicator of the current state of conservation of the structure and can be evaluated through data collected during on-site inspections. The Italian Ministry of Infrastructure and Transport Guidelines [13,14] provide instructions for the calculation of DL, schematically represented in Figure 9. Five classes are possible for the DL (from low to high), depending on the severity, intensity (K), and extent of the defects detected as well as the affected element and its relevance to the overall structural behaviour of the bridge.

Following the flowchart depicted in Figure 9, the meaning of the main parameters involved is provided below:

• K: is the intensity of the damage, and it can be assumed that there are three different levels (low, medium, or high). As prescribed in the MIT guidelines [14], it depends on the ratio between the dimension of the damage and the dimension of the element;
• Critical elements: these are the particularly vulnerable elements whose crisis can lead to an overall collapse of the bridge (for example dapped-end, post-stressed cable, etc.);
• High/low number of damages: is the ratio of the number of defects present of a certain magnitude to the total number of possible defects of that magnitude. A ratio higher than 0.3 indicates a high number of damages.

In the proposed methodology, the defect level is evaluated via an automatic algorithm (based on the instructions in the MIT guidelines, [13,14]) that derives input data, previously collected in pertinent Microsoft Access^® forms for the census, from the database through appropriate queries.

The information calculated for the defect level is also stored in the database and merged into BIM and GIS.

3.2. Visualisation of Analyses in GIS Environment

The classification of bridge attention classes is determined using appropriate calculation algorithms outlined in the MIT guidelines. This paper introduces an automated calculation procedure to compute the attention classes, which are categorized into five ascending levels ranging from “LOW” to “HIGH” (indicating higher risk) in accordance with the guidelines.

Within the GIS environment, the respective attention classes can be associated with each bridge, and the filtered data can be displayed at a regional scale. The static attention class and the seismic attention class are visualized in GIS, as depicted in Figure 7. As already mentioned in Section 2.3, the colour scale associated with the legend, represented by a variable colour bar, indicates the attention class levels, ranging from light green (LOW level) to red (HIGH level). By applying querying filters, it is also possible to display and isolate bridges that meet certain conditions or criteria, such as those bridges exhibiting a high attention level within the GIS environment. Additionally, the information about the most recent visual inspections conducted on the bridges is captured and managed within the GIS environment.

Furthermore, the information related to the last visual inspections on the bridges is carried out in the GIS environment as well.

3.3. Visualisation of Analyses in the BIM System

The use of the BIM methodology allows for the updating and integration of the previously created models, with information from the processing of data within the database.

In this respect, it is possible to show the different defect levels of each element of the bridge colouring the BIM element according to the specific defect level, varying from a low to a high level with the colouring ranging from green to red.

As in the GIS environment, the same classification is also used for the BIM environment to have uniformity between the different systems. The only difference between the GIS and BIM representation is that the first one aims to show a comparison between the different attention classes of the bridges in a network context, while the second one is focused on showing the defect level of the various elements of the individual bridge. Thanks to this criterion, it is possible to easily display the model and the various elements of the structure with the colour associated with the defect level established through the calculations performed.

The necessary strings are entered to describe the attributes of the defect level of the elements. To obtain the visualization of the defect level, it is necessary to add a customized parameter to the BIM element constituting the part of the bridgework concerned and then automatically attribute the calculated value of the defect level contained in the database, associating the visual information of the defect level as shown in Figure 10.

4. Conclusions

The present paper demonstrates how a relational database can be efficiently used as a driving force for a massive digitalization of bridge operation and management.

An integrated data-driven methodology is proposed, in which the database is used to derive, through cross-analysis queries, the fundamental data for BIM design, GIS cataloguing, and calculations through existing algorithms. The latter include the evaluation of specific qualitative parameters required by existing guidelines for expeditious analysis, such as the defect level at the scale of both the structural element and the entire structure, or the attention class, whether static, seismic, or hydrogeological.

The proposed approach allows the managing authority to obtain, in a semi-automatic manner, an overview of the structural health of the entire bridge network and, on a more detailed scale, information specific to each bridge and its component elements.

More specifically, with the presented methodology, it is possible to carry out the following (the software/drivers used, at present, to implement the methodology are presented in parentheses):

• Digitally collect, in a relational database (RDB), the boundary information of the bridge, the information proper of the bridge, and that of the single elements that constitute it (Microsoft Access^® database, .accdb file);
• On the basis of the connection (Microsoft Access Database Engine 2016 Redistributable driver) between the RDB and GIS (ArcGIS^®), generate a GIS representation of the bridge network and perform geo-referenced queries in a GIS environment;
• Automatically generate BIM models (Revit^®) through visual scripting (Dynamo^®) by extracting data from the RDB through appropriate SQL queries and gathering them in .csv files;
• Carry out detailed data queries on the entire infrastructural network;
• Perform data analysis to derive vulnerability, hazard, and exposure classes of each bridge of the infrastructural network (Visual Basic for Application—VBA).

Keeping the centrality of the RDB, the strength of the methodology lies in the continuous updating of information on physical and functional characteristics of the bridge throughout its life cycle, through the constant data exchange between RDB and GIS and between RDB and BIM.

Furthermore, the computerized digital model provided by BIM represents a dynamic and multidisciplinary container to carry out the activities of the AECO sector (Architecture, Engineering, Construction and Operation), in which AEC and O&M sectors can synergistically operate.

The main limitation of the presented methodology is related to the availability of the minimum starting data, i.e., bridge geolocation, bridge type, materials, static scheme, bridge length and width, number and type of pillars, abutment dimensions, type of deck, average daily traffic, etc., necessary to start the automatic process of generating the preliminary BIM model and GIS representation of the structure. These data are often not available and must be obtained from scratch by means of special on-site surveys, investigations, and tests. Furthermore, several information items must be entered manually at the database set-up stage, as they are not digital. Moreover, at present, the methodology allows for a rapid extension to an entire set of bridges but requires further thorough investigations to verify the actual health of the bridge. In addition, the BIM models generated, although sufficient for regulatory compliance, need to be constantly updated to obtain the corresponding digital twins.

It is worth noting that the application of the proposed methodology is not limited to bridge management but can be extended to all those fields where there is a need to digitally manage numerous assets with clearly identifiable elements (e.g., cultural heritage structures, industrial plants, dams, tunnels, electricity pylons, etc.). This applicability is independent of the scale of the context, be it local, regional, or national.

The next steps of the research include:

• The creation over time of real digital twins (DTs), starting from the BIM model created and updated with the as-built data surveyed through the most advanced techniques for digital survey and monitoring [55];
• The implementation of a methodology for data-driven maintenance through automatic algorithms based on intelligent maintenance efficiency [56].