Assessing, Coding, and Marking of Highway Structures in Emergency Situations, Volume 1: Research Overview (2016)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

70 C H A P T E R 6 6.1 Background and Motivation Field inspections can generate a large amount of data including digital images, text-based narra- tives, voice recordings, and other logged data. Therefore, computer-aided data collection, archival, or even data processing in the field become desirable, which enables rapid data synchronizing and coordination between field crews and office analysts. The latest smart devices, including smart tablets and smartphones, integrate a variety of advanced hardware and software systems for sophisticated multi-functionality. With the basic smart functions including high-quality imaging, geo-tagging, and communication, smart devices tend to replace many conventional single-function mobile devices, such as phones, cameras, laptops, and GPS devices. Therefore, smart devices are ideal equipment for emergency response. The questionnaire results (see Chapter 2) and feedback from the emergency responders at the state DOTs revealed two important facts, which further motivate the development of smart applications (or “smart apps”) as one of the key emergency response technologies. First, the feedback indicates that the majority of respondents (92%) store their structural inventory and assessment data in a digital format based on typical computer servers or work- stations. Second, the questionnaire results revealed that, compared with other technologies, smartphones and tablets are given higher priority by the DOTs when responding to emer- gency events. The two facts imply that SHAs and the professional community are ready and keen to use, and in many cases have used, smart mobile technologies for rapid emergency response. 6.2 Development of Primary Smart App Functions A technical manual developed in this project provides guidelines for developing a mobile- device-based smart app for PDA responders (PDARs). The manual includes guidelines for developing interfaces, basic functions, and server or cloud-side services to support the smart functions. The complete manual is available as NCHRP Web-Only Document 223: Guide- lines for Development of Smart Apps for Assessing, Coding, and Marking Highway Structures in Emergency Situations on the TRB website (www.trb.org); this chapter summarizes the guidelines. The envisioned smart app primarily aims to automate the manual and paper-based assess- ing, coding, and marking procedures, which are described in detail in this volume, Volume 2: Assessment Process Manual, and Volume 3: Coding and Marking Guidelines of NCHRP Research Report 833. The smart app runs on a smart device, which relies on its back-end server for data storing, retrieving, and processing; information retrieval or relay; and providing aggregated Smart App Development Guidelines

Smart App Development Guidelines 71 results. Therefore, the resulting smart app is a client–server software system. The manual defines two basic functions for the smart app: 1. Primary function: automating the assessing, coding, and marking (ACM) functions to enhance the efficiency of field-based ACM procedures. 2. Auxiliary function: providing sharing and visualization functions that access aggregated and GIS-based ACM analytics products to the DOTs’ management and other emergency response engineers. A worst-case scenario for using the smart app—no external digital data communication (via neither Wi-Fi Hot Spot nor cellular network) is available to the PDARs in the field—is con- sidered in the manual. In this scenario, smart devices are unable to connect to the Internet and hence to the back-end servers. The software design should consider this worst-case scenario and warrant that PDARs can continue to use their smart devices alone without connecting to the server and then perform ACM in the field. This means that a PDAR can perform ACM based on his/her training, experience, and basic aids such as GPS location services. Once the field data and individual PDAR’s coding/marking have access to the Internet, these data can be uploaded and synchronized to the server. Then through a unified analytics service from the server, high-level decision making by the SHA’s emergency officials can still be conducted. The following sections brief the guidelines and present the major illustrations showing the smart app’s interfaces. 6.3 General Software Design Guidelines The guidelines address the following key suggestions for the general software design and development: • Field operation and data generation workflows • Data structures • System architecture and ACM functions 6.3.1 Field Operation and Data Generation Workflows The purpose of defining the primary operation workflow and the associated data workflow is to prepare a systematic “big picture” for the software engineers who need to understand the basic procedures of the assessing, coding, and marking performed by the PDARs (who are not soft- ware engineers) in the field. 6.3.2 Data Structures: Variables, Data, and Interoperability Field assessment followed by coding and marking, whether paper based or smart app based, involves collecting and logging data into the designed data entry fields. For designing and pro- gramming the smart app software, internally a set of global variables need to be defined that await user’s input values or retrieved values from existing databases. Many of these variables are hierarchically or causally related. Therefore a data structure that describes the relations of the basic variables that are involved in the PDA procedures is critical. The manual suggests a series of key variables, their values, and more importantly their inherent relations that reconciles the field operation and data generation workflows. 6.3.3 System Architecture and ACM Functions The system architecture and the primary ACM-related functions of the smart app are sug- gested in the manual. In Figure 6-1, two software subsystems are shown including the client-side

72 Assessing, Coding, and Marking of Highway Structures in Emergency Situations: Research Overview (user interface) smart functions and the server-side services. The proposed architecture design in Figure 6-1 suggests the essential functions and services, which are grouped as different modules. For practical implementation, it is up to the software engineers to decide how to group these functions/services in different modules. 6.4 Guidelines for Interface Design NCHRP Web-Only Document 223 provides recommendations for the major interface design. These major interfaces are listed hierarchically and the major interface illustrations follow: 1. User Registration and Logging Function: Provides user registration, login, and ID authen- tication with services aided by the server. 2. Main Entry Interface: Provides a unified interface for initializing the main functions of the app. 3. Event and Hazard Information Interface: Provides interfaces for retrieving the event (the emergency), hazard-based data, and disaster response information and an inter- active mobile environment that assists the PDAR’s on-demand and real-time decision making. 4. ACM Knowledge Base: Serves the PDARs who are in the field to assess a structure of interest. The basic design methodology for this interface is suggested as follows: – Structure ACM Interface (Figure 6-2): Acts to automate the PDA procedures for the global structure and provides an entry point to the element-level ACM interface. The major inter- face design for this interface includes the following: ▪ Structure Type, Location, and Structure Name (Figure 6-3) ▪ Structure Information, Predicted Damage, and Overall Damage Description (Figure 6-4) ▪ Imaging, Annotation, and Sketching (Figure 6-5) ▪ Coding and Marking (Figure 6-6) – Element ACM Interface: Automates the PDA procedures for elements when structures show no obvious patterns or show signs of major damage that is not visible at distance (Figure 6-7) Figure 6-1. Suggested ACM architecture design and basic functions grouped as modules of the smart app system.

Smart App Development Guidelines 73 Figure 6-2. Suggested structure ACM main interface with menu items to lower-level interfaces. Figure 6-3. Suggested interface design for (a) structure type and (b) location and structure name.

74 Assessing, Coding, and Marking of Highway Structures in Emergency Situations: Research Overview Figure 6-4. Structure ACM interfaces for (a) structure information, (b) predicted damage, and (c) overall damage description. Figure 6-5. Structure ACM interfaces for (a) imaging/annotation and (b) sketching.

Smart App Development Guidelines 75 Figure 6-6. Structure ACM interfaces for coding and marking: (a) marking decision and (b) coded placard. Figure 6-7. Element-level assessment interface: (a) selecting element and (b) element-level damage type and rating that may be further linked to imaging/sketching interface for any element.

76 Assessing, Coding, and Marking of Highway Structures in Emergency Situations: Research Overview – ACM Analytics and Posting Decision-Making Interface (Figure 6-8): Provide both team-based data sharing and a final coding and marking decision-making interface. Figure 6-8(a) shows a sample illustration of the aggregated results of the ACM process from different PDARs for multiple structures. 6.5 Server Design and Services Design The server development includes design and implementation of critical services that collab- oratively realize the functions in the front-end interfaces as shown in the previous sections and figures. As illustrated in Figure 6-1, the basic services grouped based on the directions of the data flow, are as follows: • Downlink Data Services that provide retrievable information for event information, hazard- related mapping products, and other regular mapping products. Downlink data also include structural inventory and condition data per users’ query based on the inventory databases and the structure condition records databases. The databases also include an ACM knowledge database, which provides searchable ACM procedures and sample images of all types of dam- ages for transportation structures and element. • Uplink Data Services that handle field data receiving and storing including all the structural ACM data for structures and structural elements. • Interactive Data Services that deal with field query, interactive ACM data appending, modification, PDA report generation, and other on-demand two-way data services. Figure 6-8. ACM Analytics and Posting: (a) aggregated ACM for different structures in a disaster zone; (b) one structure with different ACM results accessible through QR code reading, and damage data for the global structure or the elements, which can be amended (by modifying existing data or adding more observation data); and (c) a consensus for the final coding and marking.

Smart App Development Guidelines 77 6.6 Summary NCHRP Web-Only Document 223 provides guidelines for developing mobile-device-based smart applications for PDARs to use in emergency situations for assessing, coding, and mark- ing transportation structures. Besides the guidelines briefed in this volume of NCHRP Research Report 833, NCHRP Web-Only Document 223 suggests optional smart functions for the app, including voice recognition and recording, peer-to-peer tethering between devices, and cloud- computing-based advanced analysis and data interoperability services. This manual is expected to facilitate communication between structural engineers, PDARs, inspectors, and the IT profes- sionals who will develop and manage the application and associated data; therefore, the resulting smart app would greatly automate the manual and paper-based assessing, coding, and marking procedures.