Method for the Rapid Creation of Bridge Database Systems and Practices in Developing Countries

Conventionally, bridge inspection work is conducted using simple field tools. The inspector manually writes the inspection record in a sketch book, drawing, inspection sheet, and so on at the site. After returning to the office, the field information is re-entered into digital inspection forms, which are normally Microsoft Excel files stored locally on a computer and printed out to serve as the inspection report; however, this approach is inefficient because it involves double recording.

Table 1 indicates that JICA typically assists in projects related to bridge maintenance and management capacity development for periods of 3–4 years. During these periods, data such as bridge inventory and inspection results must be collected, the bridge conditions must be assessed, and the bridge maintenance plan must be formulated. Because the latter half of the project must focus on developing a bridge maintenance plan and calculating the bridge maintenance budget, the collection of bridge data must be completed within the first year of the project.

Therefore, it would be difficult to collect all inventory and inspection data for bridges in an entire country and build a bridge database during the project period using the conventional bridge inspection and data recording method. To address this issue, the author referred to a bridge inspection method using tablet computers developed by Ibayashi et al. (2013) and applied in Cambodia by Watanabe et al. (2021) to propose a system that can collect bridge data and build a database using smartphones, making it globally applicable.

During their practical study in Cambodia, Watanabe et al. (2021) reported that tablet computers used in a high-temperature environment frequently crashed because of high internal temperatures. To address this and other issues, the following points were considered to enable the easy, rapid, accurate, and efficient collection of bridge data:

The system introduced in this paper is essentially an updated version of the Watanabe et al. (2021) system applied in Cambodia. Further, considering the reality of developing countries, where connectivity can be weak in rural areas, the following points were considered:

The proposed system operates via smartphone as the client device. A smartphone has built-in capabilities such as a camera, GNSS, text input, data storage, sound recorder, and data communication. This enables the simultaneous development of a bridge database system while conducting and recording the results of bridge inspections onsite. Data recorded at the bridge site can then be sent to the data server from the smartphone.

The system is based on the FileMaker series version 13 software for database development; the iPhone device series serves as the client device operated by the inspector recording the data at the site. The iPhone was adopted because it has common specifications worldwide as well as many language settings. Furthermore, a computer with MacOS running a FileMaker server was used as the database server. If the server is installed in a location with an unreliable power supply, it is preferable to adopt a laptop computer that does not turn off immediately in the event of a power outage to prevent data loss. A schematic of the system configuration is illustrated in Fig. 2.

The system file consists of two features: (1) an inventory system, and (2) a brief inspection system; the data in both systems are linked by the bridge ID allocated by the inventory system, as indicated in Fig. 3. The basic operation flow of the system involves preparing the inventory data using the inventory system, after which the inspector inputs data (general data, superstructure, pavement, slab, substructure, and so on) by performing measurement work and taking photos at the site. Next, the brief inspection system is launched to conduct the bridge inspection. There are five preset inspection categories: road surface, superstructure (including the deck slab), abutment, pier, and around bearing. The operational flow of the system is summarized schematically in Fig. 4.

Data describing the bridge inventory and inspection recorded at the site can be communicated from the iPhone client device to the database server using the mobile data connection. However, it is assumed that a large quantity of data will be generated owing to the many photos included, making it difficult to send the data from the site using the mobile data connection, especially in rural regions in developing countries where high-speed data communication networks may not be established. Therefore, another version of the system, called the offline version, was prepared for such scenarios. In the offline version, the data recorded onsite are temporarily stored on the iPhone. When it becomes possible to connect to the internet through a high-speed data communication network, the data stored in the iPhone are transmitted to the server. This system is designed for use with the iPhone but can also be used with an iPad if a larger screen is desired.

The inventory data system requires information fundamental to the preparation of a bridge maintenance and management plan. For example, it requires bridge dimensions (bridge length, width of carriage way, and width of sidewalk), location (coordinates automatically acquired by GNSS), material, structure type, existence of bridge accessories (bearings, expansion joints, and so on), and photos. The items recorded in the inventory data system are listed in Table 2, and the data input procedure is illustrated in Fig. 5.

The inventory data input method comprises five screens on the client device, as shown in Fig. 5. The first screen [Fig. 5(a)] indicates that three photos of the bridge should be taken: a general view, the road surface on the bridge, and the bridge nameplate. The location information (longitude and latitude) can be passed to the external Maps.me application by pressing the Map button in the upper right corner to check whether the latitude and longitude are approximately correct. The second screen [Fig. 5(b)] is used to input general information such as the bridge name, road category/class, and road administrator; the latitude and longitude are entered automatically. Even if the inspector forgets to check the bridge location on the map on the first screen, the Map button is placed in the same position on the second screen so that location can still be confirmed. The third screen [Fig. 5(c)] is used to input additional general information such as bridge length, width, number of spans, and year of construction. The fourth screen [Fig. 5(d)] is used to enter information describing the superstructure such as pavement type, superstructure material, structural type, slab material, bearing and telescopic device information, and presence or absence of attachments.

The fifth and final screen [Fig. 5(e)] is used to input information describing the substructure; the inspector takes a photo from underneath the bridge and enters several items regarding piers and abutments. After these inputs are completed, the bridge inventory sheet shown in Fig. 6 is automatically generated, and the data are stored on the client device. This inventory sheet can also be emailed directly from the client device as a PDF file.

The four pull-down items in Table 2 (Area 1, Area 2, Road category, and Administrator) can be replaced according to the specifications of each country, making this system globally applicable.

After preparing the inventory data, the bridge inspection commences using the brief inspection system to record information describing the structural soundness of the bridge. The smartphone-based input method is used to guide the inspector to check for existing damage in accordance with the inspection items displayed on the screen (Table 3). If damage is found, a situational photo is captured using the camera built into the iPad/iPhone. If an anomaly that cannot be reported with a photo is found, such as an abnormal sound at an expansion joint, this sound can be recorded using the built-in microphone. Thus, it is possible to report damage that could not be previously recorded using paper documentation. Furthermore, these inspection data, including damage situation photos and sound data, can be managed on the same platform.

Watanabe et al. (2021) established a bridge database for the Ministry of Public Works and Transport in Cambodia under the Project for Strengthening Capacity for Maintenance of Roads and Bridges supported by JICA using a similar system (Japan International Cooperation Agency 2019); however, the system checked for the existence of damage for each inspection item in a predetermined order: road surface, superstructure, deck slab, bearing area, and then substructure. This inspection approach had notable usability issues. For example, the bridge inspection always had to start from the road surface, and if damage was found in the deck slab during the substructure inspection, it was necessary to return to the relevant damage item in sequence. Thus, the authors improved the system to enable the inspector to begin the bridge inspection from the easiest point after preparing the inventory data, regardless of their location. In addition, the system was upgraded to cover masonry bridges in reference to the inspection guidelines for masonry bridges in Oita Prefecture, Japan (Oita Prefecture 2021).

Bridge components were categorized into the five elements shown in the Element column of Table 3, and inspections and records are completed based on these elements. This allows for the inspector to navigate among elements as they are observed, for example starting from the substructure at the completion of the inventory preparation, eliminating the need to first return to the road surface, as was necessary in the system described by Watanabe et al. (2021). Eliminating unnecessary movements of the inspector not only saves inspection time but also improves safety because bridge inspection sites are fraught with hazards.

The brief inspection system comprises the 10-screen sequence shown in Fig. 7. The inspector proceeds with the inspection in accordance with the inspection items displayed on the screen. The screen in Fig. 7(a) shows a list of bridges recorded in the system, from which the inspector chooses the bridge to be inspected. The list is displayed in order of proximity to the current location of the client device, reducing the need to scroll through a long list to find the appropriate bridge; the top bridge shown in the list is usually selected. The screen in Fig. 7(b) shows the previous inspection record for the selected bridge. After tapping the New Inspection button shown in Fig. 7(b), the inspector may start the bridge inspection. If the previous inspection record needs to be checked/reviewed before starting a new inspection, the Show Inspection Sheet button can be tapped. The screen in Fig. 7(c) is used to provide a safety check before starting the bridge inspection. The inspector should accordingly check their gear, then tap Yes, and the button Start Inspection will be automatically on.

The screen in Fig. 7(d) is used to select the bridge element being inspected. The bridge elements are categorized into the five elements summarized in Table 3; the inspector may start the inspection from any element as convenient. The screens in Figs. 7(e–g) are used to input the inspection data. If no damage is found for the chosen element, No damage is tapped on the screen in Fig. 7(e); the inspection of that bridge element is now completed. However, if damage is found, Damaged is tapped and the various types of damage to the identified bridge element are shown on the screen in Fig. 7(f), as listed under the Inspection Item column in Table 3.

Next, the screen for taking photos is displayed. On the screen shown in Fig. 7(g), six photos can be recorded for each element. The option Not Visible is provided for elements other than the road surface. If inspection of the superstructure, abutment, pier, and around bearings is not possible due to topography or other access difficulties, Not Visible can be selected. Furthermore, this option provides useful information that helps future inspectors consider their access and inspection methods by referencing photos in the inventory data, satellite photos on the internet, and so on in advance. This sequence of screen transitions, i.e., (1) identifying the existence of damage, (2) checking the damage type, and (3) taking photos of the damage, remains the same regardless of which element the inspector selects on the screen in Fig. 7(d). After taking the photos, the user is returned to the screen to select another bridge element, as shown in Fig. 7(h).

After the completion of each element inspection, the color of the button showing that bridge element is changed to light blue. The inspector can then continue to inspect other elements of the bridge. When the inspection is completed for all elements, the button Comment by Inspector is made available [Fig. 7(i)], and the inspector can then add their comments, signature, and name [Fig. 7(j)]. The inspection result is subsequently stored on the iPhone, and the results for each bridge can be output as an inspection report, as shown in Fig. 8. The aforementioned bridge inspection procedural flow uses the brief inspection system developed by the authors.

The bridge inspection method applied in the proposed system involves checking for the existence of the damage items listed in Table 3; if any damage is found, a photo of the damage scenario is captured and recorded. Each damage item is then assigned a score between 1 and 10, as indicated in Table 3. Minor damage is assigned a low score, whereas major damage (such as the settlement of the substructure) is assigned a high score. These assigned points are set as an initial value based on author experience as a professional engineer specializing in structural and material. The points for the damage items are then summed to obtain the total score for each corresponding member. These scores are then evaluated in terms of three damage levels (DLs) based on the judgment criteria determined for each member type (DLs I–III in Table 3); for each member, one point is given for DL I, three points for DL II, and five points for DL III. Weights of 10%, 30%, 10%, 20%, 20%, and 10% are then allocated to the road surface, superstructure, deck slab, abutment, pier, and around bearing member types, respectively. In the case of single span, the abutment accounts for 40% as the sole substructure. The sum of the values obtained by multiplying the score for each member ($A$) by the weight for the corresponding member type ($B$) is then used as the damage score for the entire bridge ($T$), as follows:

The damage degree of the entire bridge is divided into four levels according to the value of $T$, as indicated in Table 4. Thus, the system can evaluate bridge damage at multiple levels, such as the existence of damage to a member, level of damage to a member, and level of damage to an entire bridge. This makes it possible to search for the following in a database:

Moreover, the score allocated to each damage item, classification criteria of damage levels, score per member, and/or weight for each member type summarized in Table 3, as well as the classification criteria presented in Table 4, can be adjusted based on the collected data and photos in accordance with the administrator’s policy for bridge maintenance; for example, more emphasis could be placed on damage to the superstructure and/or deck slab.