Earthquakes frequently hit Taiwan because of its location on the Circum-Pacific seismic belt. Although most earthquakes do not significantly damage buildings and infrastructure, some of these earthquakes are quite destructive. For example, the 7.3 magnitude Chi-Chi Earthquake in 1999 damaged hundreds of schools in Taiwan [1
]. This earthquake resulted in close attention being given to governmental disaster management, innovative seismic design, and existing building retrofitting.
School building safety is a pressing issue in Taiwan as the major occupants are students, and many public school facilities are utilized during disasters. The students are mostly children or minors. It is a challenge to ensure that all occupants can protect themselves or evacuate from buildings in time during a disaster. Meanwhile, many local governments use schools as emergency shelters during disasters. In Taiwan, approximately 47.6% of emergency shelters are schools; for some regions, over 70% of the shelters are schools [2
]. However, damage statistics of historical earthquakes in Taiwan show that there was a lack of seismic performance in existing school buildings in Taiwan [3
], threatening the safety of students during school hours and refugees or shelter users during disasters.
Both officials and universities have devoted themselves to supporting schools in the retrofit of existing buildings, and they have produced results. To grasp the current situation of the seismic resistance of existing school buildings, the National Center for Research on Earthquake Engineering (NCREE) proposed a three-stage strategy for the seismic evaluation and retrofit of school buildings [3
]. In addition, the Ministry of Education, in cooperation with NCREE, has implemented a program for improving the seismic performance of schools since 2009, and thus far has retrofitted over 7900 buildings for a higher seismic resistance [4
]. Meanwhile, the Ministry of Education also requisitioned public schools to establish “safety inspection task forces” in 2009 [5
]. The task forces aim to conduct the building maintenance, inspect the campus safety planning—which includes safety equipment and facilities—and update the records on required retrofitting. Beyond regular inspections, additional inspections are also required, especially after hazards such as earthquakes and typhoons. The members of the task force of each school include the principal, the director of general affairs, and other staff of the school. The members are responsible for initial inspections, and they determine whether further inspections by professional engineers are required based on the initial results. After they submit the inspection reports to the oversight authority, managers of the oversight authority determine budget and resource allocations for school building retrofits.
Despite the results produced in the retrofit process, some difficulties in the overall process require solutions or improvements. First, the number and spatial complexity of school buildings complicate the inspections for different buildings. The current standard evaluation covers at least twenty checkpoints, targeting different parts of the campus. Some of the checkpoints are for facilities in individual classrooms, while others may be for corridors in different stories or for the safety planning of the entire campus. Assessors have to repeat the inspections on different buildings and adjust the required checkpoints case by case. Second, the paperwork is in paper form, thus requiring hard copies and restricting the form of inspection reports and potential advanced usages. Multimedia such as images and videos provide abundant information about building damage; however, they cannot be simply attached to hard-copy reports. Furthermore, numerous paper reports without summarization hinder managers from grasping the potential damage situation. Third, the members of safety inspection task forces often do not have expertise in structural or civil engineering. The inspection process may burden the assessors, and the results may not comprehensively present the building damage to the managers of the oversight authority.
Besides the disadvantages mentioned above, an advanced usage of inspection reports is noticed during an interview with a target user. During an interview with the Director of General Affairs in a public school, who conducts the school building inspection, we noticed that for assessors it is a requirement to track the damage of school buildings. The local government may provide tutorials for assessors who are not structural engineering professionals to learn how to observe deformations and determine when to seek professional advice. The director suggested an aggressive integration of historical inspection reports as well as the inspection task for reminding assessors of previous and accumulated damage.
This study aims to reduce the complexity of building inspection tasks, the restrictions of the paperwork process, and the ineffectiveness of the management of existing school building inspections. By adapting smart device technology, this study provides a novel solution featuring aggressive notifications and a guiding interface for nonprofessional assessors. A literature review of advanced smart device technology is discussed in Section 2
. The system architecture is introduced in Section 3
and the implementation of the system is described in Section 4
2. Literature Review
The evolution of information and communications technology (ICT) has lowered the barrier of accessibility to information. Wireless protocols and techniques enable connections to the Internet, regardless of time and location. Additionally, the size of electronic devices has decreased and they have become more powerful than ever before. Minister Audrey Tang of the Executive Yen, Taiwan, insists that there is no such concept as a genius in the modern world since people can easily look up the answers to their questions on the Internet, benefiting from advancing technology. Nowadays, people may access, process, and produce information online using their smart devices anytime and anywhere.
Electronic devices have been adapted to solve problems in the civil and construction engineering field to eliminate challenges in manual paperwork. Kim et al. [6
] developed an on-site management system focused on on-site monitoring, task management, and real-time information sharing by utilizing wireless communication and augmented reality, thus supporting engineers in obtaining high-level productivity and efficiency. Lin et al. [7
] discussed a two-step user-centered design approach to develop and evaluate iSafe
, an iPad application that reduces the drawbacks of the safety inspection process on construction sites. iSafe
improves the day-to-day practices and management of safety inspections and features data collection for developing advanced analysis techniques. However, traditional designs of user interfaces are not ideal for the reduced size of screens and keyboards of smart devices [8
]. Moreover, the graphic user interface (GUI) designed for larger devices such as tablets may not be compatible with smaller devices such as smartphones, which are more popular than tablets [9
The growing popularity of smartphones has also triggered the growth of messaging applications. In 2015, the number of people using instant messaging (IM) applications surpassed the number of people using social networks [10
]. This phenomenon has resulted in conversational agents becoming a new trending solution for trivial problems. A conversational agent or a dialogue system is a software application that uses conversations to interact with users for different purposes [11
]. It communicates with users in natural language (text, speech, or both) and may fall into two classes: task-oriented dialogue agents and chatbots. Task-oriented dialogue agents aim to solve specific tasks, while chatbots aim to extend conversations and mimic human–human chatting. However, in industry, the term “chatbot” has been widely used to describe both types of conversational agents. In this study, the term “chatbot” generally refers to a conversational agent.
Nowadays, chatbots are widely used in several areas, including in businesses, in medical applications [12
], and disaster management [13
]. In the construction field, most chatbots are designed to support the management of work sites. Some chatbots assist in scheduling future works and remind managers of scheduled tasks. For example, ConBot
, a construction site data assistant developed by Botmore Technology in the United Kingdom [14
] and SafeTrack
, produced by Talania Ltd in New Zealand [15
], feature daily report submission and completed work logging in the form of conversations. Other chatbots focus on construction site safety issues, such as the Workplace Safety Chatbot
, developed by the Robust Tech House of Singapore, which allows users to easily report hazards and broadcasts safety reminders to users [16
The convenience in access and the capability of user interaction has made conversational agents a viable solution to integrate smart devices in all fields. Conversational agents feature interaction with users in natural language, leading to the adoption of conversational agents due to benefits in higher user efficiency in task fulfillment. Tsai et al. [13
] remarked that users can easily retrieve desired information by text since the conversational agent extracts their intent directly from their language. Additionally, since conversational agents communicate with users in natural language by either speech or text, the barrier posed by the use of different devices is reduced as long as the devices support input by text or speech. Chan and Tsai [17
] integrated semantic and temporal types of terms to enhance the question analysis capacity in the disaster management field, enabling decision-makers to retrieve not only static documents but also real-time information directly in natural language. In addition, the omission of additional installation and the lowered cost for training reduces the resistance to conversational agents compared to other types of smartphone applications. It is not necessary to download any additional application that may occupy device storage; instead, only adding a chatbot to a contact list is required for acquiring its services. For most IM applications, adding chatbots is equivalent to adding actual people. An online survey report [18
] found that the ability to easily register a complaint makes chatbots outperform regular smartphone applications. Furthermore, conversations can be opened simply to offer services. It does not take extra effort for users to be familiar with how to obtain desired services. In contrast, more time is required for users to learn how to use other types of smartphone applications.
As the preliminary work, we have attempted to develop a chatbot to reduce the difficulties encountered in the paper-based school building inspection process [19
]. The preliminary work established a framework and drafted a series of digitalized procedures to discover the potential of adopting chatbots to support building inspection tasks. A prototype was also developed in the preliminary work, providing an effective interface that utilized smart device technology. However, the preliminary work offered neither the intuitive way to locate the discovered damage for assessors nor the summary of inspections for managers. The need to repeatedly perform inspections on multiple buildings in a single campus was also not considered in the procedures drafted in the preliminary work. Hence, the result we produced in the preliminary work requires further extension and discussion.
In the present study, the process of building inspections is digitalized, and a conversation-based system framework is developed to support accomplishing the inspection tasks. The system framework adopts a chatbot as an interface to notify, guide, and assist assessors in completing their building inspections, and a dashboard as an additional interface for managers to read reports to determine whether further assessments or retrofits are required. The proposed system has the following features:
Notification for informing assessors to begin routine inspections or inspections after safety thresholds are reached after seismic events;
Conversation-based interface for guiding assessors to complete their inspections through a procedure that is user-friendly for nonprofessionals;
Integrated tool for starting inspection tasks after receiving notifications in a single application to improve the intuitiveness of the whole inspection process;
Ability to accept multimedia inputs to allow the assessor to attach images or videos to reports to show damage or deficiencies directly to lower the possibility of mistakes in inspections;
Data visualization to managerial decision-making to enhance the quality and accuracy of budget allocation for building retrofits.
As illustrated in Figure 1
, the system framework includes three modules: (1) the notification module (N-module), (2) the conversation module (C-module), and (3) the display module (D-module). All three modules connect to the database, which contains data such as intensity-scale thresholds of school buildings, contact information of registered assessors, and inspection reports. The N-module notifies assessors via IM applications for either routine or post-event building inspections. The C-module guides assessors in completing the predesigned checkpoints in inspections with a smartphone-friendly interface in the form of a chatbot. The D-module manages the dashboard used by managers to check the status of inspections via a web browser.
The N-module notifies assessors to start inspections. It is activated by a routine inspection or after seismic events. For routine inspections, each school may schedule specific dates for inspection according to government regulations. On the specified inspection dates, the system sends messages to notify the registered assessors of the school. For post-event inspections, notifications are issued after the N-module receives the earthquake information and starts up. The system selects the critical schools of which the intensity-scale thresholds are reached from the database and sends notification messages to the registered assessors of the selected schools.
The C-module, which is the core of the application framework, supports assessors in locating and describing the inspected building damage. After starting a new inspection, the system guides assessors in specifying the inspected targets by clicking on a map selector. Next, assessors may provide content on the inspected targets by typing descriptions or uploading pictures of damage. The system collects the inspection, confirms the content with the assessor, and submits the inspection to the system.
The D-module is designed to enhance managerial efficiency and accuracy in reading inspection reports for decision-making. By analyzing the collected reports from critical schools, the D-module provides summarized information for managers. The information is displayed with interactive maps, tablets, and figures. Managers can interact with the D-module via a web browser to select specific schools and obtain detailed reports.
3.1. Notification Module (N-Module)
The notification module (N-module) is intended to inform assessors to start either routine inspections or post-event inspections. It determines which schools require inspections and sends direct notifications to the registered assessors of those schools. The notifying messages are sent to assessors’ IM applications by the chatbot in their contact list as if a real person sent the notifications. After being notified, the assessors may start their inspections by interacting seamlessly with the chatbot without switching to another application or device. The N-module improves the efficiency of selecting critical schools based on earthquake data and enhances the intuitiveness of the application through the notifications for assessors to start inspections.
Based on the different types of inspections, the N-module has two notifiers:
Routine notifier, which works on a schedule and sends messages to inform assessors of regular inspections;
Post-event notifier, which is activated by earthquakes and informs the registered assessors of schools located in areas where the intensity scales reached the critical threshold.
The routine notifier sends notifications to the registered assessors on selected dates. For example, schools in Taiwan may specify dates in July for the annual inspection since few students are present during their summer vacation. In addition, multiple dates for different inspection scopes can be specified. For example, assessors can schedule individual buildings for inspections on dates in different weeks or schedule inspections to focus on specific types of inspected targets. On the scheduled dates, the routine notifier sends messages detailing the scope of the inspection via IM from the chatbot to the registered assessors.
The post-event notifier automatically selects the registered assessors that are required to be notified. For each school building, an intensity scale is assigned as the threshold based on the building’s condition and expert opinion. When an earthquake occurs, the system obtains detailed information on the event, including the epicenter, the magnitude, and the observed intensity scales in different areas. The post-event notifier compares the observed intensity scales with the assigned threshold of school buildings and determines the buildings that require inspections. For the critical schools housing these buildings, the post-event notifier sends messages to the registered assessors from the chatbot via IM applications.
3.2. Conversation Module (C-Module)
The conversation module (C-module) digitalizes the inspection procedure and provides guidance for assessors to reduce the difficulty of accomplishing the inspection. Since the members of safety inspection task forces are school faculty members, the assessors may not be properly trained engineers that are capable of assessing buildings efficiently and correctly. The C-module interacts with assessors in the form of a chatbot, making inspections similar to having conversations with real people.
By replacing the traditional paper-based procedure, the system directly integrates the utilities of smart devices and improves the efficiency and convenience of completing inspection reports. The C-module leads the nonprofessional assessors through all the checkpoints. It also accepts multimedia files such as images or videos sent from assessors to the chatbot for clearer damage reporting, reducing potential mistakes in the inspection.
We abstract the inspection procedure into four steps:
Initiate the inspection: Assessors initiate inspections after receiving notifications by sending text commands.
Specify the inspection target: Assessors specify the inspection targets following the system’s guidance. An inspection target may be a classroom, corridor, outdoor facility, or the overall campus safety planning.
Describe the damage: Assessors describe the damage or deficiency of the current inspection targets following the selected checkpoints. The selection of checkpoints is based on the type of current inspection target.
Modify or submit the inspection result: Assessors review the inspection results before submission, modify the inspection if needed, and submit the inspection report.
The target specification and damage description steps are repeated during an inspection. In a single inspection task, multiple inspection targets may be covered. After an inspection is initiated by sending text commands to the chatbot after a notification is received, the activated chatbot guides the assessor in specifying an inspection target following a cascaded procedure precustomized for each campus. The procedure may be text-based, meaning that the chatbot guides the selection by posing questions to the assessor and narrowing the candidate target following the assessor’s response. After specifying the target, the chatbot asks the assessor “questions”, referring to the checkpoints based on the type of the specified target. The checkpoints are divided into several categories based on the types of inspection targets, including an overview of the campus, indoor facilities, outdoor facilities, and facilities in corridors. Following the type of the specified target, the assessor answers the “questions” sequentially by sending messages to the chatbot. The assessor may send photos and videos of the damage as if communicating with real people via IM applications. Since the C-module manages the process of filling out the checklist, completed checklist data is preserved, allowing the inspection to be paused and continued later at any desired time. Finally, the chatbot summarizes the contents of the inspection into a message and presents it to the assessor for final confirmation. If modification is required, the assessor may select the checkpoints to be modified and correct the answers. After the corrections are accomplished and confirmed, the C-module saves the results to the database.
Providing spatial information is essential for both target specification and damage description. To specify the inspection target, the assessor needs to indicate the target in the campus plan. Similarly, to describe the damage, the assessor needs to locate and record the location of the discovered damage on the floor plan. Thus, the proposed application integrates these similar needs, with a two-phase damage locating process designed for the conversation-based system framework. This process is illustrated in Figure 2
. The process combines collected plans and links them into a cascaded map system. In the first phase, from the overall campus plan, the assessor selects the submap layer and zooms in the map view to a narrowed area to select the desired inspection target. After the target is specified, the assessor starts the inspection. If any damage is found, the assessor enters the second phase to locate the damage on the inspected target.
3.3. Display Module (D-Module)
The D-module presents the inspection reports visually to lower the inefficiency and difficulty for managers to analyze data for making high-quality decisions. Managers need to understand both the routine damage and post-earthquake damage of school buildings and determine the budget allocation for building retrofits. The D-module supports managers in selecting digitalized reports, analyzing the reports, and visualizing the results to support decision-making.
The dashboard is designed to be accessed with a web browser, and features two views:
Summary view, which shows an overview of inspection reports utilizing data visualization;
Detailed view, which lists all the school inspection reports and provides the full report content of the selected report.
The manager can switch between the two views, interact with the dashboard, and select one of the events on the dashboard. Both views consist of interactive maps to show the geographic distribution of inspection results. Additionally, colors are utilized for indicating the number, amount, or scale of different statistics, emphasizing the severity of damage or the progress of inspections.
For the summary view, the D-module retrieves the inspections of the selected event from the database and performs data visualization for obtaining the summary of the event. The dashboard reveals the completeness of inspections in different districts with a colored map and the total amount of damage in different checklist categories. The manager utilizes the information shown on the dashboard to make decisions about allocating budgets and resources to retrofit the damaged school building.
In the detailed view, the map demonstrates the number of critical schools in the affected areas by coloring them, while a table lists all schools and their reports. By clicking one of the areas on the interactive map, reports of schools in that specific area are selected and highlighted to emphasize their severity levels. The reports show the detailed damage, supporting the manager in efficiently determining which schools still have inspections in progress and to consume the reports in detail.
In the present study, as a case study, the proposed system was implemented for the main campus of National Taiwan University of Science and Technology (Taiwan Tech). Flask
, a micro-web-framework written in Python [20
], was adopted to implement the system as an HTTP (Hypertext Transfer Protocol) service to control the interaction process between users and the chatbot and to host the web-based dashboard for managers. The interface of the system is implemented via LINE, a common IM application. Many popular IM applications provide application programming interfaces (API) or software development kits (SDK) to develop chatbots, including Slack, LINE, Google Hangouts, Facebook Messenger, and Telegram. Among all IM applications, LINE has the largest popularity in Taiwan [21
]. In addition, the LINE Messaging API features various messaging features such as confirmation buttons and clickable images. The API also accepts multimedia in a user’s response [22
The database is designed to store the following data:
Public schools and their locations;
Inspection targets including their names, types, intensity-scale thresholds, and the cascaded maps that lead to them;
IM application account IDs and the contact information of the registered assessors;
Checkpoints for the inspection;
Responses to the checkpoints.
For the N-module, the routine notifier runs per the schedule for the school. The post-event notifier is linked to the open data platform of the Central Weather Bureau (CWB), which is the authority on earthquakes in Taiwan. When an earthquake occurs, the N-module acquires seismic data from the authority and selects the schools that reached their intensity-scale thresholds. The NCREE sets the threshold of each school based on the school’s condition. If the threshold of the school building is reached, the N-module is activated and sends messages to the registered school assessors for completing inspections. For schools whose thresholds are not reached, the school assessors do not receive messages.
The C-module adopted diverse formats of messages from the LINE Messaging API. The “template message”, which provides a set of buttons as the interface, is adapted for replacing typing if the expected response is from a set of options. For example, the confirmation of each checkpoint is implemented with the “template message”, providing an alternative means of input by pressing the “no problem” button instead of typing “no problem” directly. We also adopted “image maps” and “rich menus”, which are clickable images with covered invisible buttons. Typing can be replaced if the expected responses are limited and correspond highly to images. For example, the cascaded target specification is implemented with the “image map” and the “rich menu”, enabling assessors to specify the inspection targets intuitively with the aid of maps. The C-module regards the LINE Messaging API as a proxylike interface between the chatbot and assessors. For providing checkpoints to assessors, the C-module sends requests with message objects in JSON format to LINE via HTTP. When assessors send messages to the chatbot via LINE, the LINE Messaging API calls the webhook of the C-module, and the C-module thus receives the assessors’ messages. The C-module accepts multiple types of incoming messages, including text inputs, postback actions, and multimedia files.
To implement the two-phase damage locating process, the campus plan and floor plans of each building in Taiwan Tech was collected. The campus plan was divided into several subplan areas that cover different parts of the campus considering their relative size. By pressing the subplan area, the chatbot leads the assessor step-by-step toward the inspection target, such as a room in a building, and thus completes the first locating phase. The assessor starts to inspect the room through the guidance of the checklist; if any damage is discovered, the assessor enters the second locating phase and indicates the damage location using the given plan image of the room, thus directly linking the description and the multimedia file to the location of the damage.
, for data visualization. OpenLayers
provides several map-related features such as map loading, geographic data visualization, and overlaying [23
dynamically visualizes data and features functions to enable interactive graphics [24
An example of the post-event inspection accomplished with the chatbot’s support is demonstrated with the series of screenshots shown in Figure 3
. The chatbot interacts with the assessor using diverse message formats adapted from the LINE Messaging API. The system first informs the assessor to start an inspection after an earthquake occurs. The assessor sends a command to the chatbot for initiation. Next, the chatbot provides a series of cascaded, clickable maps for the assessor to specify a room that requires inspection. By pressing on the desired region on each map, the chatbot narrows down the map display area and leads the assessor to one of the rooms. The assessor then selects one of the question categories and starts to fill in the report. Entire questions are displayed as confirmation buttons. If the assessor selects “no problem”, the next checkpoint for inspection pops up sequentially. If “require improvement” is chosen, the chatbot is switched into input mode. The assessor makes detailed textual or multimedia descriptions. After completing the inspection, the system summarizes the current contents and presents it to the assessor for final confirmation. If modification is required, the assessor may select the checkpoints to be modified and correct the answers. Finally, the corrections are completed and confirmed, and the system saves the report to the database.
For the web-based dashboard for managers, the summary view is shown in Figure 4
and the detailed view is shown in Figure 5
. Each view includes an interactive map on the left and a panel on the right, providing an overview or a detailed table. In the summary view, the manager first selects an earthquake event using the selection bar, then clicks one of the districts on the map. The summary of inspection reports of schools related to the earthquake event in the district is then revealed. The summary includes a bar chart of the distribution of answered checklists over the checklist categories, showing a brief overview of the building damage in the district. In the detailed view, similar to the summary view, the manager selects an earthquake event and a district, and a table lists inspection reports of the schools with links to the detailed results. The color demonstrates the severity level of each school according to the inspection records; the more checkpoints that fail in the inspection, the darker the color of the report. By clicking one of the links to a specific detailed report, the results of buildings in the report are shown as in Figure 6
. Only the checkpoints denoted as “require improvement” and their descriptions are displayed in the detailed results.
5.1. Advantages of the System
The major advantages of this study include the development of the conversation-based system, the utilization of novel techniques for solving several difficulties in the school buildings inspection, and the feasibility of implementing the system for an existing campus. This study provides a conversation-based solution to reduce the complexity of building inspections, the inconvenience of the paperwork process, and the inefficiency of management. The system features notifications sent either by a routine schedule or after seismic events, a conversation-based interface for guiding nonprofessional assessors to perform inspections, the integration of intuitively activating inspections after receiving notifications, the use of multimedia to show damage directly without the possibility of mistakes, and data visualization for supporting managerial decision-making to enhance the quality and accuracy of budget allocation. As the case study, we implemented the proposed system for an existing campus composed of several buildings and demonstrated the actual inspection procedure with a series of screenshots. The whole process, from receiving notifications to completing inspections, was fulfilled seamlessly within the chatbot, eliminating the need to switch to another application. Also, the dashboard for managers, providing the summary view and the detailed view, clearly showed the overview and details of the inspection in different regions.
There are three aspects that require improvement. One is the lack of evaluation of the system’s effect on managers’ efficiency. Another aspect is that despite the digitization of the inspection process and content, techniques to automatically perform further analyses of the content, including text and images, are not developed. The other is that the solution in this study highly relies on internet services; that is, the system is not appropriate for disasters that damage the network infrastructures. In future work, to evaluate managers’ efficiency of understanding the presented information, further interviews with managers about the interactive dashboard is required. Additionally, natural language processing (NLP) techniques have the potential to be adopted for analyzing text in inspection reports for obtaining more in-depth information from the inspection reports, which may provide support for managers to determine budget allocations. The application of NLP should consider the challenges due to the characteristics of different languages, especially about how the on-site assessors describe the damage. In addition, image-recognition techniques may be adopted to automatically find damage from uploaded images and thus reduce the time needed to manually check the images. Furthermore, for inspecting isolated disaster areas, remote sensing techniques such as UAVs can provide potential help to inspect buildings that are hard to access.
5.3. Potential Applications of the System
Not only school buildings but also other public buildings located in areas with frequent earthquakes may require periodical inspections and seismic capability evaluations. Fire prevention and fire risk assessments are also critical for public buildings that gather massive numbers of people, such as gyms, libraries, and hospitals. Inspections targeting different safety aspects are required to grasp the situation of the buildings. However, the inspection of public buildings encounters similar difficulties to the school building inspection, including the restrictions of the paperwork process and the complexity of inspections. Thus, the introduced concept and the system framework in this study may be adapted to public buildings and serve as a feasible solution. The implemented system may notify the assessors to start inspections on specified dates or after particular incidents. By utilizing the feature for predefining checkpoints, the system may also support the assessors to complete inspections that target different topics such as seismic resistance, fire prevention, or other facilities.