Multilevel Assessment of Seismic Damage and Vulnerability of Masonry Buildings (MUSE-DV) in Historical Centers: Development of a Mobile Android Application

Abstract

Empirical data on the seismic behavior of masonry buildings are collected by technicians through rapid visual assessment procedures, i.e., by filling in forms that organize information in short answers or ticks. The resulting empirical database serves as a basis for prevention strategies, but the archiving and the post-processing of data are always a potential cause of losses and misinterpretations. New technologies are nowadays entering seismic risk analyses as a support to the usual visual approach. This paper proposes a new application for Android mobile devices that digitalizes an assessment form (MUSE-DV) able to collect damage and vulnerability data of masonry buildings in seismic areas, including information on strengthening interventions applied to buildings in the past. The client–server architecture of the app considers local devices communicating over the web with a central unit; data processing is split between them to reduce network and resource needs. This approach is convenient with thin devices, such as smartphones, and in post-disaster situations, when the mobile network may not be available. Data collected onsite can be stored in remote archives and therefore shared among technicians without affecting the integrity and consistency of the database. The whole dataset can be extracted and processed by a dedicated software for statistical and spatial analysis. The MUSE-DV procedure was validated in the area struck by the 2016 Central Italy earthquake and the app presented here was preliminarily tested onsite on the buildings of Castelsantangelo sul Nera (Macerata district); the results contributed to damage and vulnerability analyses by the means of thematic maps.

1. Introduction

Earthquakes in Italy are characterized by a moderate magnitude, but their consequences are far more severe, owing to their frequency and the exposure and vulnerability of the built heritage [1,2].

The first emergency phase following an earthquake summons teams of technicians and experts to set up rescue and safety operations and then to expeditiously estimate the severity of the seismic event in terms of economic and structural damage to buildings. Macroseismic scales are usually utilized to define, per each urban area, the intensity level of the earthquake, i.e., according to the first effects on the built environment and the feeling of the people. The Mercalli–Cancani–Sieberg scale [3] is the preferred option in the immediacy of the event to quickly attribute the intensity level, whereas the European Macroseismic Scale (EMS-98; [4,5]) is used afterward as it requires a bit more detailed building-by-building assessment. According to the EMS-98, a damage grade from 0 (no damage) to 5 (collapse) and a vulnerability class from A (most vulnerable) to F (less vulnerable, with earthquake-resistant design) should be assigned to each building [6,7].

Post-earthquake surveys give a crucial contribution to the empirical knowledge of the seismic behavior of buildings that has both scientific and social value [8], i.e., in terms of: (i) addressing and optimizing emergency management strategies [9,10,11], reconstruction plans [12,13], and solutions of risk prevention and mitigation [14,15,16,17]; (ii) increasing awareness of the inhabitants against the critical conditions of existing buildings in historical centers and the importance of prevention of damage by strengthening actions [18,19].

The onsite visual inspection of buildings is nowadays formalized in rapid assessment procedures, usually supported by paper forms that supply surveyors with scheduled questions with single or multiple choices and short answers to guide them in the observation and description of building features, damage patterns, vulnerability factors, and damage mechanisms completed by photographs, sketches, and notes.

It is worth noting that, since the same factors that caused seismic damage in a building could be recognized before an earthquake as vulnerabilities as well, these forms could work also as a preventive tool for the assessment of buildings [20,21]. However, rapid assessment procedures are acceptable as far as large stocks of buildings are concerned since more refined analyses (e.g., numerical models) would be too time consuming and would require information that is not available for every assessed building [22].

1.1. Survey Forms for the Assessment of Damage and Vulnerability of Masonry Buildings

Assessment survey forms are commonly defined according to their: (i) target, i.e., building type (e.g., houses, churches, palaces); (ii) aim, i.e., damage and/or vulnerability; (iii) structural interpretations (e.g., macroblocks, building components); (iv) scale of application (e.g., individual buildings, whole towns, districts, regions) [23]. Their present schedules are the result of actual usage onsite and therefore of the progressive updates occurring in the course of time that aim at either improving clarity or including new aspects to the survey.

In Italy, forms are distinguished according to the level of evaluation. Level 1 focuses on the evaluation of the damage grade suffered by a building, which is divided into structural components or macroblocks, and the rapid recognition of its construction techniques and materials. Level 2 assesses the vulnerability, that is, the parameters that qualify the condition of a building in respect to the ideal behavior, i.e., box-like. Some procedures express the damage or the vulnerability as a normalized index in the 0–1 range, where 1 represents the total collapse or the most vulnerable condition, respectively [24].

In the following, the rapid assessment schedules currently in use are briefly described according to their aims (i.e., damage or vulnerability) and their level of evaluation. They are mostly developed in Italy, owing to the availability of systematic studies on built heritage in seismic-prone areas. For a more detailed discussion, see Saretta et al. [25].

At Level 1, in Italy, the usability of ordinary buildings (either masonry or reinforced concrete) is addressed by the AeDES form (Italian acronym for the ‘Level 1 form for post-earthquake damage and usability assessment and emergency countermeasures in ordinary buildings’). It was formerly presented by Bernardini [26] and then updated according to Baggio et al. [27] and Dolce et al. [28], whose first version was the Level 1 GNDT form (Italian acronym for ‘national group for the protection against earthquakes’ [29,30]). A faster version of that form has been recently proposed by Zucconi et al. [31] based on the analysis of data collected after the 2009 L’Aquila earthquake.

Two other procedures were developed with the same purpose but focused on cultural heritage assets: (i) the A-DC form [32,33] for the seismic damage assessment of masonry churches, and (ii) the B-DP form [34] for palaces and monumental buildings. Both forms provide a damage index referring to a selection of local mechanism whose damage grade is assessed in the 0–5 EMS-98 scale; the index is obtained as the ratio between the total damage score and the potential total obtained when every mechanism is graded as 5. All three forms indicate the short-term countermeasures to be applied in the post-earthquake emergency phase to prevent new collapses to buildings.

The CLE form (Italian acronym for ‘limit condition for the emergency’) [35,36] provides an extension of the survey at the urban scale by identifying the strategic buildings and assessing the functional level of an urban area in seismic emergency conditions.

In the USA, the standard for the preventive evaluation of a building’s vulnerability, or rapid visual screening (RVS), is given by the Federal Emergency Management Agency (FEMA) [37,38]. The corresponding RVS is based on a scoring system to quantify the expected seismic performance of a building. The surveyor is required to identify the structural system of a building, the organization of its plan and elevation, and its interaction with the adjacent units; thus, a preventive planning and a careful management of the emergency can be addressed. Moreover, the buildings that require a more detailed vulnerability analysis can be identified. Conversely, the Evaluation Safety Assessment Form ATC-20 [39] is used to identify the seismic damage level suffered by a building. The damage is evaluated per each structural and non-structural component in order to determine the usability of a building.

At Level 2, the GNDT form is commonly utilized in Italy but is also quite widespread at the European level. It was formerly proposed by Benedetti and Petrini [40], who devised 11 parameters to represent the structural features of a building (e.g., level of earthquake-resistant design, masonry quality, roofing system). Ferrini et al. [41], Formisano et al. [42], and Ferreira et al. [43] added new parameters or changed how they are evaluated, e.g., by including the interaction between adjacent buildings or the effect of structural transformations on the vulnerability of a building.

As regards churches, the Level 2 form [44,45] requires a careful evaluation of each part of the building; damage mechanisms, vulnerability aspects, and earthquake-proof devices are identified and qualified by assigning a numerical factor.

Recently, the multilevel procedure CARTIS form (Italian acronym for ‘structural and typological characterization of urban areas’ [46]) is proposed to recognize homogeneous urban areas and their common constructive techniques in order to define the recurrent building types in a town. The procedure spans the two levels of analysis: one form (Level 1) describes the overall vulnerability of buildings in a homogeneous area and the other (Level 2) targets the vulnerability factors of the reference building types.

1.2. Information Technologies for Earthquake-Related Data Collection

In this framework, information technologies can help decision making by creating, hosting, and processing large amounts of data such as those coming from earthquakes [8,47]. In the post-processing of data, the Geographic Information System (GIS), also implemented on web platforms [48], is a common choice for the spatial representation of damage and vulnerability data at both the urban (see, e.g., [22,23,43,49]) and regional scales. Examples of the application of such a system are the Global Earthquake Model (GEM) [50], the HAZUS-MH platform [51], the CAPRA Probabilistic Risk Assessment Platform [52], and the ARCH DSS WebGIS Decision Supporting System [53]. Web mapping platforms can also support the assessment through simplified evaluations based on visual inspections, provided the accuracy of the observations and the dimension of the inventory comply with the evaluation purpose [54]. Sometimes, the dissemination of software for data storage can be a viable option for data management, as for the CLE form [55] and the LOG-IDEAH post-earthquake tool for architectural assets [56]. Artificial intelligence theories such as neural networks, [57] fuzzy logic [58], and remote sensing [59,60] have been tested for quick data collection in the first phase of a post-earthquake emergency for civil protection purposes and the adoption of short-term measures. The preventive usage of the latter is preferred for infrastructures (e.g., highway bridges) and landslides [61,62], although some applications to civil buildings have been proposed [63,64,65].

With those tools, the collection of data can be more problematic as visual assessment needs to be carried out onsite, often in difficult operational conditions. However, the schematic structure and the minimal computations required by rapid assessment procedures make their translation into software applications a viable option. Applications for mobile devices (apps), such as smartphones and tablets, offer an interesting alternative support to paper forms as they enable a rapid access to various sources of information. Their easy and widespread use can both increase the awareness of earthquake effects and create positive cooperation with the public authorities responsible for the planning of remedying actions [66].

As far as professional post-earthquake analysis is concerned, Shan et al. [67] and Xu et al. [68] proposed a smartphone app to collect pictures, videos, and text notes, also with a GPS (Global Positioning System) tag. Data are hosted in a common database and they can be accessed via a web browser for either research [68] or public use [67]. Astarita et al. [69] proposed an app to gather data from the population on damage to the transportation network (caused by floods and forest wildfires). Foresti et al. [70] developed a platform for the real-time acquisition of disaster-related damage data from social networks and sensors (microphones and security cameras). Cimellaro et al. [8] devised a simplified AeDES form for mobile devices to be filled in by the population rather than the experts. Finally, Lwin and Murayama [71] proposed a web-GIS for earthquake data collected by smartphones by means of a Post Office Protocol (POP3) mail server.

The active involvement of a community is a positive effect of easy-to-use and widespread devices to increase awareness and preparedness to a seismic event [72]. Fallou et al. [73] developed an app to collect the effects of the earthquakes in the Mediterranean basin, similar to the web platform developed by Wald et al. [74] for the USA. Fallou’s system feedbacks the user with the best practices recommended for that event, whereas Wald’s system contributes to the creation of the United States Geological Survey (USGS) ShakeMaps. In this case, a user is asked to answer a few questions based on the Modified Mercalli scale to assess the intensity level by the post-processing of data collected in each locality. The MyShake app [75] recognizes the shaking level based on the background noise detected by the smartphone. Information coming from various devices is processed to estimate the possible location and magnitude of an earthquake. Aydin et al. [66] proposed an app with civil protection purposes as it enables the sharing of information about missing people, available resources, and damage levels in buildings after a seismic event.

Colombelli et al. [76] developed an app that works both in passive and active mode, i.e., as a seismic bulletin (e.g., by localizing the user and informing him or her about the magnitude and the epicenter distance) and as a warning system (i.e., trigger mode to detect the shakes).

At last, both FEMA and ATC forms were translated into a browser-based software, namely Rapid Observation of Vulnerability and Estimation of Risk (ROVER) [77], which contains two modules for pre- and post-earthquake assessment aimed at addressing hazard mitigation actions. The software works on any mobile device with a browser without the need to download an application; however, it requires an active data connection. The pre-earthquake assessment according to FEMA’s RVS is addressed also by the RViSITS [78,79], the Urban RAT [80], and the ML-EHSAPP [81] applications. The information gathered by the latter helps the training of artificial neural networks in order to refine the evaluation of seismic vulnerability and the exposure of buildings. Still, in the framework of RVS, [82] proposes an ‘identity card’ of buildings stored in a remote database that is accessible through a QR code attached to each building in the study area. Finally, hazard and risk analyses performed according to GEM were translated into a digital tool [83].

1.3. Digitalization

Onsite assessment forms standardize a survey, that is, they limit the subjectivity of the surveyor and enhance the homogeneity of data in the onsite inspection. Moreover, they are thought to be filled in a reasonable time, guiding the user throughout the schedule to the final judgment of the structural parameter of interest (e.g., damage, vulnerability, usability). The filling of assessment forms on paper arises some problems that are overtaken by the advent of digitalization. Common problems of keeping the paper format of data are [68]:

• The accumulation of physical material and data, which must then be reported manually within a digital database; this operation is time consuming and can lead to archiving errors or losses and the consequent slowdown of the following actions;
• Misinterpretations of either the questions (uncertainty in what a field means when the user manual is not available) or the usage of the schedule (e.g., multiple checks when just one is required, see below);
• The need, to complete the survey, of pictures taken onsite which are not directly connected either to the building to which they refer or to a specific component. The reassociation of the pictures to the pertinent elements increases the time needed for the archiving and is similarly affected by possible mistakes;
• Lack of precise geographical positioning.

These limits of analogic data acquisition stimulated the proposal of computer-based tools that support the surveyor by easing repetitive tasks and controlling material errors. In particular, digitalized procedures help the onsite filling of the procedure as they:

• Facilitate the surveys through hints and feedbacks;
• Can use portable devices with already mounted acquisition tools (camera, recorder, sketchpad);
• Can store data directly on a centralized database and allow data to be shared;
• Can manage different types of data (e.g., videos, pictures, text notes) and associate them to the correct or building element;
• Simplify the post processing, as the data collected are homogeneous.

The design of a digital survey tool begins with the typological analysis of input data to determine the logic value of the desired answer, e.g., a short text rather than a choice from predetermined values. The type of managed data governs their cataloguing and the following analysis phase [21,47]. The possible formats for input data are numbers, characters, or string, single or multiple choice. This distinction already exists in assessment procedures as a graphic agreement: for instance, the single choice corresponds to circular symbols (radio button), whereas multiple choice corresponds to square ones (checkboxes, see

Table 1. Type of answer and graphic element in both analogical and digital survey tools.

Graphic Element		Type of Answer
Analogic Form	Digital Tool
_________________	_________________	short answer
|__|__|__|__|__|__|	_________________	short answer
○	○	single choice
	▼	single choice on drop-down list
□	□	multiple choice

).

Table 2. Predefined structure for answers in common assessment procedures according to specific issues.

Procedure	Level	Damage	Vulnerability	Structural Features	Usability
AeDES	1	multiple choice, severity, extent (EMS-98)	-	multiple choice	Yes
A-DC	1	0÷5 grade damage index	-	-	Yes
B-DP	1	multiple choice, severity, extent (EMS-98)	-	short answers, extent within the building	Yes
CLE	1	multiple choice (description)	-	multiple choice	No
CARTIS urban area	1	-	factors: tick	walls: single choice diaphragms: multiple choice	No
FEMA	1	-	factors: tick	-	No
ATC-20	1	multiple choice (description), severity, extent	-	-	Yes
Churches	2	0÷5 grade damage index	factors: tick and 0÷3 grade vulnerability index	multiple choice	Yes
GNDT	2	-	parameters: A÷D class vulnerability index	(*)	No
CARTIS building	2	-	factors: tick	walls: single choice diaphragms: multiple choice	No

* Considered in vulnerability parameters.

compares the organization of the previously mentioned forms (see Section 1.1) with respect to a specific issue (i.e., damage, vulnerability, usability, and structural features).

The Italian forms for post-earthquake analyses are mainly based on the damage evaluation proposed by the EMS-98. In the A-DC, B-DP, and CLE forms, the surveyor is asked to define the seismic damage by ticking the corresponding grade, whereas AeDES, B-DP, and ATC-20 forms require to assess each building component in terms of damage extent and severity.

As regards vulnerability forms, the surveyor is required to tick the identified vulnerability parameters amongst a list of proposed factors. A more precise assessment is required in the Level 2 GNDT and churches forms, in which a textual and a numerical evaluation is given, respectively.

In Italy, digital applications for onsite damage and vulnerability assessment are limited to the works by Cimellaro et al. [8] and Bramerini et al. [55], who referred to already existing procedures. This paper presents the translation into an Android mobile application of a multilevel assessment procedure developed by the authors after the 2016 Central Italy earthquake. The form is called ‘MUSE-DV Masonry’ (‘Multilevel assessment of Seismic Damage and Vulnerability of masonry buildings’) [25] and was conceived to collect post-earthquake data [84] of masonry buildings in historical centers, including the effects of common strengthening interventions that buildings underwent starting from the 1980s [85,86,87]. Both the types of interventions and the specific damage mechanisms induced by them (see Section 2) are catalogued. The form also includes vulnerability factors and classification, therefore it can also be used with preventive purposes.

The aim of the MUSE-DV procedure differs from the FEMA RVS, as the latter is conceived to identify the most vulnerable buildings for defining priority lists and risk mitigation strategies. The RVS is also thought for a rapid application in large urban areas and for an inclusive analysis of the vulnerability of as many buildings as possible; therefore, it aims at assessing the risk for high population figures. The MUSE-DV took inspiration from this approach and from other well-known procedures adopted in Italy, but it is intended for an in-depth evaluation of the seismic behavior of buildings in historical centers after people rescue and safety countermeasures have been addressed. Therefore, the MUSE-DV procedure should be adopted in a later phase when the damaged area is made accessible after the securing of streets and buildings. Indeed, it requires a comprehensive building-by-building evaluation to identify crack patterns and their causes and the construction techniques, either as built or integrated by strengthening interventions, if any. In this context, machine learning and automatized inspection procedures cannot yet replace the human judgment as a refined, even empirical, evaluation is required and the surveyor needs to move close to the building and, possibly, also to inspect the interior. At last, satellite and aerial images obtain a reliable damage scenario only when buildings or roofs are at least partially collapsed [56,59].

The MUSE-DV app is conceived to be utilized offline and to offer logic support to the surveyor. In fact, the mobile network can be unavailable during onsite inspections owing to either damage to the infrastructure or limited coverage, which is likely to happen in mountainous or hilly areas, and the app can implement automatic rules that prevent skipped fields or answers in a wrong format.

2. The MUSE-DV Mobile Application

2.1. Analogical Procedure

The MUSE-DV form is structured according to a ‘multilevel approach’ [88] that combines information coming from both Level 1 (post-earthquake data with an expeditious approach) and Level 2 (vulnerability analysis and detailed post-earthquake data) assessment. This led to a four-section form [25]: each part collects data about damage and vulnerability of a masonry structural unit (SU) within an historical center, i.e., a building or a portion of a town block which is homogenous for structure and construction process [89]. A preliminary identification on cadastral maps or satellite photos of the SUs in the survey area is required; however, it can also be updated during the inspections. It is not compulsory to complete the whole form as the parts, albeit related, are independent. The complete or partial filling in depends on the available time, the purposes of the survey, and the usage of the data collected (damage analysis or vulnerability assessment campaigns).

The MUSE-DV form was developed by combining some of the Italian forms described in Section 1.1 and adding specific items concerning the effects of interventions on the structural behavior of a building [86]. Many buildings surveyed after the 2016 Central Italy earthquake had already been strengthened or repaired after previous seismic events according to old codes and regulations that favored standardized practices, e.g., the addition of reinforced concrete (r.c.) tie beams and the replacement of timber diaphragms with r.c. ones [85]. The observed damage patterns proved that these interventions often had an unfavorable contribution on the seismic behavior of a building, owing to the incompatibility between old and new parts and the poor design and/or construction of interventions (Figure 1).

The procedure is consistent with the damage grading and the vulnerability classes of the EMS-98 scale. Damage can be evaluated through the MUSE-DV form either overall, according to EMS-98, and by structural components, as in AeDES and B-DP forms, or by local collapse mechanisms, as in A-DC and churches forms. The vulnerability of a building can be estimated by using a ‘scoring method’, i.e., by inferring its proneness to damage from the recognition of vulnerability factors among those proposed by the method, similarly to CARTIS and churches forms.

The multilevel assessment is obtained by progressively increasing the level of detail of the analysis as the survey progresses throughout the sections of the form (

Table 3. Outline of MUSE-DV assessment procedure; type of answer and output refer to digital tool. For the explanation of symbols please refer to Table 1.

MUSE-DV Masonry: MUltilevel Assessment of SEismic Damage and Vulnerability of Masonry Buildings
Subpart	Issue	Type of Answer	Output
Part 0—Building identification, overall vulnerability, and damage
Building identification	Location	_______________
	Survey information	_______________
	Building ID	_______________
	Seismic identification	_______________
Typological analysis	Building type	○
	Block shape/position of building inside a block	○
	Maintenance state and pre-existing damage	○
	Site morphology	○
	Geometric data	_______________
Damage identification	Prevailing damage mode	○
	Main mechanism	○
	Secondary mechanism	○
	EMS-98 damage grade	○
Part 1—Vulnerability and damage assessment of structural components
Vulnerability assessment of structural components	Masonry quality	○
	Connections	○
	Load bearing system	○
	Structural irregularities (plan or elevation)	○
Damage assessment of structural components	Façade damage, orientation of seismic force	Sketch
	Damage assessment of structural components (extent and severity)	○	Damage Index DI1
Usability classification		○
Part 2—Local mechanism analysis
(1) External bearing walls	Mechanisms due to poor masonry quality	Damage: ▼ Photos	Damage Index DI2
	Out-of-plane mechanisms
	In-plane mechanisms
	Damage due to interventions
(2) Horizontal structures	Damage to loadbearing and non-structural elements
	Damage to structural vaults
(3) Staircases	Damage to staircases
(4) Roof structures	Damage to loadbearing and non-structural elements	Vulnerability: □	Vulnerability Index VI2
(5) Internal bearing walls	Out-of-plane mechanisms on internal bearing walls
(6) Non-structural elements	Damage to ceilings; internal partitions; chimneys; cornices; roofing tiles; parapets; jambs
(7) Geometrical irregularities and soil–structure interaction	Interaction among adjacent buildings or between building and soil; mechanisms due to irregularities
Part 3—Building features
Masonry quality	Units and mortar	□
	Texture and arrangement	□
	Cross-section	□
Diaphragms	Floors/Vaults	□
	Roofs	□
CARTIS type		○
Structural Interventions	Walls	□
	Diaphragms	□
Type identification	EMS-98 Vulnerability class	□
Extent of the survey		○

). Part 0 (Building identification, overall vulnerability, and damage) collects identification data and analyzes the site and the overall configuration of a building (e.g., age, number of floors, maintenance state) also in respect to adjoining portions. Then, the schedule requires the recognition of the main damage mechanisms and the 0–5 overall EMS-98 damage grade.

A more detailed evaluation is carried out in Part 1 (Vulnerability and damage assessment of structural components). Vulnerability is assessed in terms of masonry quality, load bearing system, geometry, and interaction with adjacent buildings. Seismic damage is evaluated by assigning its severity and extent to the main structural components (e.g., masonry walls, horizontal diaphragms, roofs, and non-structural elements) that led to the definition of a preliminary damage index. At the end of this section, the usability of the building is assessed.

A synthetic damage index can be calculated based on damage data collected in this section. The Part 1 damage index (DI₁) is calculated according to the AeDES procedure [27], i.e., by expressing the grade (slight, moderate, severe) and the extent (as a percentage on the total, i.e., >2/3, 1/3–2/3, >1/3) of the damage to a building, distinguished for structural elements (walls, horizontal structures, staircases, roof, internal walls, non-structural components). It is computed as the average of the damage grade weighted by its extent according to Equation (1) [90]:

DI₁ = (Σ_i d_i ∙ e_i ∙ w_i)/3

(1)

where d_i is the damage level on a 0–3 scale (no damage to collapse), e_i is the extent of damage as the ratio between the damaged portion of a structural element and the overall element, and w_i is a coefficient that expresses the relative importance of that structural element in the overall behavior of a building. The overall damage is also expressed in a 0–3 scale, and it can be normalized to 3, as proposed in Equation (1).

Differently from the AeDES procedure, the MUSE-DV considers the possibility that a structural element is ‘not observed’. In this case, the damage value and extent are disactivated in the widget and, in the calculation, the expression is modified in order to exclude that structural element. This feature is useful when a building is unsafe and cannot be accessed by the surveyor or, as in the case of most of the MUSE-DV surveys, they happen from the outside. In addition, the surveyor is asked to assess the damage caused by structural irregularities such as a different percentage of openings between converging façades that induces overall torsion on a building.

Part 2 (Local mechanism analysis) deals with the recognition of macroblocks and 18 possible collapse mechanisms [91,92], whose damage is defined in a 0–3 scale (0 stands for no damage, 1 for activation, 2 for severe damage, and 3 for collapse of the mechanism). Each mechanism is related to a list of vulnerability factors that the surveyor can simply tick when relevant. This part of the schedule is also thought to obtain damage and vulnerability indexes that can be compared with the EMS-98 overall damage grade and DI₁ (see Section 3.4). This method of assessment is inspired by the A-DC procedure that evaluates the damage to the local mechanisms. Differently from that method, in which the damage scale includes five grades, the MUSE-DV reduces the evaluation of mechanisms to three grades. As a result, this choice describes more consistently the damage to civil buildings whose macroblocks are smaller than those of churches. Part 2 damage (DI₂) and vulnerability indexes (VI₂) are both normalized sums: damage index in respect of the damage grades (in a 0–3 scale), the vulnerability index of a list of factors per each mechanism, for a total of 84 items. The MUSE-DV procedure also considers the cases of ‘non-assessable’ when a part of a building is out of sight and cannot be assessed during the survey and ‘non-triggerable’ when there are devices that prevent the activation of a mechanisms (e.g., tie rods in the case of out-of-plane overturning) or when the architectural or structural layout forbids them. In the former case, vulnerability factors can be still checked, in the second one this is not possible. As a result, DI₂ is expressed by Equation (2):

DI₂ = Σ_i d_i/[3 ∙ (18 − t − h)]

(2)

where d_i is the damage level on a 0–3 scale of the triggered mechanism, t is the number of non-triggerable mechanisms, and h is the number of those whose assessment was not possible. By way of example, in an SU internal to a terrace and with the same height of adjacent units, the mechanism ‘corner overturning’ is non-triggerable as there are no free corners that can be overturned. Similarly, when the specific safety conditions of the building under assessment prevents its complete visual inspection, some mechanisms could be hidden from view and therefore cannot be assessed in a proper way. In both cases, these mechanisms are excluded from the total and the reference basis reduces from the potential total of 18 local collapse mechanisms. The possibility that a mechanism is non-triggerable is a simplification from the churches form [44] that asks for vulnerability and safety factors. Indeed, as there are devices that act against vulnerability, the MUSE-DV considers the macroblock safe and it is excluded from the list of possible ones for the sake of rapidity. The vulnerability index VI₂ is calculated according to Equation (3):

VI₂ = Σ_i v_i/(84 − Σ_i t_i)

(3)

where v_i is the number of identified vulnerability factors for the triggered mechanisms and t_i is the number of those that were considered as non-triggerable or whose assessment was not possible. Therefore, the denominator refers to the number of potential vulnerability factors of a building. It is calculated by subtracting the number of factors that are not relevant for a building, as related to non-triggerable mechanisms, from their total number proposed by the MUSE-DV method, i.e., 84. These factors are obtained from the assessment procedure described in Section 1.2.

The higher the score the higher the vulnerability of a building.

At last, Part 3 (Building features) focuses on structural features and interventions to complete the overall knowledge of the building and to assess the EMS-98 vulnerability class. This section was deliberately placed at the end of the schedule as the data required are not very urgent in the first emergency phase; furthermore, its filling is eased by a comprehensive observation of the building gained through the previous parts.

The MUSE-DV form was utilized by the authors to inspect 2300 masonry SUs within 20 historical centers located in the area struck by the 2016 Central Italy earthquake [84]. The data collected led to the definition of the contribution of interventions to the seismic behavior of strengthened buildings, i.e., favorable or unfavorable [86], and to their vulnerability classification according to EMS-98 [87].

2.2. Digital Procedure

The MUSE-DV procedure was translated into an application (app) for Android-based portable devices, such as smartphones and tablets, that can access the web via the mobile network or wi-fi connection. Compared with the paper version, this app simplifies the distribution of the tool and supports the integrity of the information input through its interface. Furthermore, the implementation in the source code of the logic rules that govern the filling in of the modules composing the various sections works as a guide to the surveyor. In addition, hints and recalls to the reference manual can be added through the procedure. Network access allows an effective cooperation among the app users, as the information they collect can be conveyed in a shared remote archive that can be accessed at any time over the web, rather than saving them on the local device. The central archive simplifies the management of data as they are saved in the same place and according to the same structure; therefore, they can be easily extracted and translated in a post processing software.

The deployment of the MUSE-DV app considered the logic structure of the paper form and the main issues described in Section 2.1, along with flexibility and scalability. The app repeats the structure of the paper version for a total of 220 modules, distributed between free text fields, radio buttons (single choice), checkboxes (multiple choice), and drop-down menus. It is also possible to acquire pictures and sketches of the damage pattern on an outline of a building. The logic bounds of the paper version are implemented in the app, e.g., by including mandatory fields and turning off options as a consequence of certain choices. In addition, as the communication between the modules of the application require that values are always defined, the surveyor is always asked to fill in at least a ‘null’ value. Therefore, a negligible value assumed by a parameter is transparent to both the one who fills in the forms and the one who processes them, thus avoiding possible data voids and improving the efficiency of the onsite data collection. Completed forms can be deleted only from the central archive for integrity reasons when they are exported for post processing.

The workflow progresses as follows (Figure 2). Firstly, a preliminary mapping of SUs in a GIS software defines a numeric ID for each building. Different surveyors can be assigned to non-overlapping portions of the study area, thus reducing potential conflicts among them, that is, multiple forms referring to the same building. This ‘hard’ approach is different from the strategies proposed, e.g., by Xu et al. [68] that solve the conflicts only through the software. As a user creates a new form, the app asks for the SU location and ID, which are appended to create a unique tag for archival purposes. During the survey, the app saves a temporary .xml (extensible markup language) file in the local device, which allows the persistence of the values in already filled in modules as the user moves through the interface. The .xml files are light documents (less than 1 Mb) that describe the meaning of the values stored in them through custom tags corresponding to the names of the field in both the app and the archive. Consequently, these files enable the communication between the app and the central archive. Each file corresponds to a single SU and is named after it. The local caching of data reduces the exchanges between the app and the archive over the web and it is a useful feature in post event conditions or simply in mountainous or hilly areas where the mobile network can be unavailable or unstable. Therefore, at the end of the survey the app checks whether the device is on or offline. In the former case, the completed form is sent to the central archive in real time, in the latter it is stored locally to be sent when the connection returns and the cache is emptied. As files are synchronized, the app also checks whether there are duplicates in the archive, but the criterion for their choice is the simple priority of time.

At the end of onsite activities, data can be exported from the archive in an interoperable format such as .csv (comma separated values) files. These files can be imported in software for data analysis and spatial representation (e.g., GIS) of the survey, as done by Vettore et al. [49].

3. App Architecture

The operations on data can be distinguished in acquisition, processing, and storage and they reflect in the three logic levels of an application [94], that is, a ‘presentation logic’ (front end) that a user interacts with to collect information, and the ‘data logic’ (back end), that is, a database where data are stored and queried. In between the ‘application logic’ processes the information collected in the upper layer according to certain rules and writes and reads data in the back end. The front-end device is called client and the back end one, server. In a client–server software architecture, the data and the application logic are hosted on the server, whereas the client provides the interface to the resources and services on the server. This model, which relies on a network of devices, has the advantage of sharing resources among clients and of having thinner clients than those needed to run the entire system alone [95]. However, the MUSE-DV app was designed according to a variation of this model known as microservice architecture, in which the application logic is a collection of loosely coupled services that are split between the client and the server (Figure 3). The client runs the graphic interface and those services needed to acquire data, does simple calculations on them, and communicates with the server. The server hosts the data and that part of the application logic that is needed to access them when a query is launched from the app through the network. Consequently, the services of the app can be deployed independently or with limited reciprocal interference. The network access and the operation effort of the app are less intense as they are limited to the data (already elaborated) specifically needed by a user. The downside of this model is the need to adapt how data logic is called according to the device type and an additional operational complexity [96].

The proposal of a digital survey module according to the architecture described above requires the development of the following items:

• On the server side: (i) the data storage, i.e., a relational database; (ii) the application that queries data and provides the communication between the client and the server (API-REST, i.e., Application Programming Interface-Representational State transfer);
• On the client side: (iii) a sequence of modules framed in graphic interface, i.e., the app that replaces the physical form for data collection; (iv) an application that processes data, i.e., the services.

The database hosts the data coming from the mobile devices and it can be accessed via a web browser, which provides the interface for its administration; data are hidden to the user. The API-REST manages the communication between the app and the server over the web and data logic, i.e., the queries on database entries. The app runs on the client and provides the graphic interface, which replaces the paper form. A user is guided by the layout throughout the stages of the analysis, taking pictures, and running the routines included in the local device (e.g., index calculation).

3.1. Database

The server offers a centralized support to the archiving of those data produced by the users that are formatted in the same way thanks to the .xml file and then transferred to it over a network (the web in this case) [97]. The remote archive frees the memory of the clients and allows their cooperation. A relational database, i.e., that used in the MUSE-DV app, is a set of data homogeneous in format and type and structured according to relations; it can be visualized as a table in which the rows (records) represent an individual building and the columns represent the pieces of information associated to it (attributes). The possible operations on data (queries) are those actions known as CRUD (Create, Read, Update, and Delete) and the usage of a Management System helps in defining the users and the relative privileges, that is, the rules called to avoid possible conflicts, to keep the integrity of data, and to restore them in case of anomalies [98]). A successful operation that complies to these rules is a transaction and determines a permanent change in the database.

The management system chosen for the MUSE-DV app is MySQL [99], but the database and the operations on it were defined in phpMyAdmin [100], which provides a graphic interface to the database and the operations on it through a web browser instead of coding them in SQL (Structured Query Language). The database consists of a single table in which each record describes an individual structural unit in the survey area and the fields corresponds to the modules of the schedule (see Table 3). Rows can be ordered according to any field, but there cannot be duplicates, that which is granted by an ID field (primary key). In the MUSE-DV database, the primary key is autoincremented for integrity and robustness reasons, but a field is reserved to a unique code obtained by appending the SU number, defined in the preliminary mapping, to the census code of the municipality, which is unique at a national level. This code is also used as a tag for the communications among the client and the server. The MUSE-DV table has a 1:1 relation, as the records are associated only to the fields instead of other tables; there are 220 fields in total. This appeared as the best choice as the data asked the surveyor to make a list of items that change just by the logic type, and the software on the server side (see Section 3.2) was much simpler to deploy referring to a single table. The fields in the database match the definition of variables in the app’s source code. The type of data collected are those listed in

Table 4. Data type and number of fields in MUSE-DV database.

Datum Type	MySQL Variable Type	Description	Number of Fields
ID	INT	integer number	1
text	VARCHAR	short string	42
photograph url	LONGTEXT	long string	19
single choices	ENUM	set of named values	126
multiple choices	SET	set of multiple values	31
date of the survey	TIMESTAMP	time and date	1

, and they are mainly strings for free texts and short answers and lists of predefined values obtained from the already existing Italian rapid assessment forms. Such an approach saves their definition from scratch and reduces uncertainties as clarifications are already implemented in the reference manuals of other procedures. List fields can allow single or multiple values according to the logic requirements of the procedure (see also Table 3). Photographs are stored in the client; however, the complete URL (Uniform Resource Locator), that is, the complete address of the resource on the device, is stored in the database. The ‘null’ value is allowed in the user-completed fields and it is set as the default.

3.2. Data Exchange

The data exchange between the app on the smartphone and the database on the server relies on a web API-REST, which is a communication framework between the client and the server over the web through http (Hypertext Transfer Protocol) communications. The MUSE-DV web API is a server-side software that manages requests and responses between the client and the server, i.e., the access to the resources (the database) on the server through web URLs (Figure 4). The messages are coded in specific languages and contain either the data to be written in the database or to be displayed by the app [98]. In addition, the API complies with the REST principles, which include, among others, statelessness and cacheability. This implies that the requests are independent from one another and that they can be cached on either the client or the server and then deleted once they have been sent. The API approach to app design simplifies both the app deployment, as it is not required to define all the connection parameters in its source codes, and its maintenance and update, since either the server or the app can be updated provided that the request structure managed by the API remains the same.

The API software is coded in PHP language and it is called when the app summons one of the following functions:

• Write data in the database in real time;
• Write data in the database with delay;
• Read data from the database;
• Export data from the database to a file.

The client–server messages are coded in JSON (JavaScript Object Notation) language with http methods invoked, which the API parses in SQL instructions to operate on the database, as shown in

Table 5. Matching rule between http methods in API-REST and CRUD operations on database.

http Methods	CRUD Operations	Description
POST	CREATE	create a new resource
GET	READ	read a resource
PUT	UPDATE	update or change the status of a resource
DELETE	DELETE	delete a resource

. The ‘get’ and ‘post’ http methods correspond to ‘create’ and ‘read’ SQL operations, that is, to write a new record or to retrieve an existing one in the database, respectively. In addition, the API gives feedback about the result of the operation. A correct input corresponds to an operation on the database (read/write) and a user gets a message of the success; otherwise, a bad input returns an error, e.g., when a duplicate SU is sent to the database or a missing SU is requested. Therefore, an appreciable fault tolerance and robustness are met [68]. In case of read operations, the data retrieved from the server are sent back to the app as a JSON message, which is compiled in a .xml document and then displayed by showing the modules of the app filled in. Data exporting is important as any analysis is carried out outside the server to keep the integrity of data.

When there are multiple temporary files in the app cache, they are sent one by one to the database and deleted starting from the oldest one when the network returns available. The MUSE-DV API checks whether they are duplicated and gives feedback on the results of the operation, thus improving the efficiency of data storage.

3.3. Graphic Interface

The user interface of the app was developed in Android Studio [101], which combines a visual editor with an integrated development environment to dynamically interact with the layout and the view of the app and precise them through the source code in .xml format. The .xml codes describe the structure of views, that is, the pages of the app and their general properties such as the colors, labels, and icons. The functionalities of the components, i.e., the widgets, inside each view, the interactions between them, and the data processing are written in Java [102], which is an object-oriented programming language. Such tasks are defined activities and they are the entry points for the interaction with the user. The whole graphic interface was defined from scratch and it translates the structure of the MUSE-DV form into a digital tool. The home screen shows the four possible operations (Figure 5) that correspond to the calls to the database:

• Create the survey of a new building;
• Retrieve and display the data of a building already archived in the database;
• Synchronize to the database those compiled while offline;
• Export data to a text file.

The MUSE-DV app uses various widgets that can be distinguished according to their function (Figure 6):

• Event triggering: buttons;
• Selection: radio buttons, checkboxes, spinners;
• Value input: text boxes, sketchpad;
• Output: labels and progress bar.

A button is a graphic element that allows the user to perform an action, that is, in the Java code an activity is summoned or interrupted (Figure 6a). Buttons appear as rectangles in the home screen to call the main functions of the app, at the bottom of a page to move to the previous or the following or in a page to run the calculation procedures or take pictures. Text boxes, which appear as a horizontal line, enable the input of strings by the user when the answer is not predefined, e.g., when the app asks for the location, the name of the team, or the SU ID. The input can be numbers or text and a hint suggests its type and the required answer; by default, they are empty (Figure 6b). Checkboxes allow multiple choice in a set of predefined items and they are displayed as squares checked with a tick when they are selected (Figure 6c). As the checkboxes are separated items, the source code specifies the activities for the tap on each; by default, they are all unchecked. This widget is used to state the vulnerability factors related to local mechanisms in Part 2 of the MUSE-DV form or to acquire the material features of a building in its Part 3. The single choice is managed by radio buttons (Figure 6d) or spinners (Figure 6e). The former consists of small circular buttons that allow the user to choose only one option in a set at a time; selecting a new value automatically de-selects any other previously defined. Consequently, this widget ensures an unambiguous response and avoids errors due to haste in compiling, such as selecting more than one answer within the same question by default or when no option is selected. This widget is used for short alternative answers, e.g., the building type, the damage mode, and the overall damage grade. A spinner is a range of values that a user can step through to choose one and appears as a drop-down menu. It is used mainly in the definition of the damage grades of the local mechanisms in Part 2 that are a set of predefined numeric values in the 0–3 range.

The user interface is organized in pages that can be scrolled down to fill in the data required by the widgets that are simply stacked (Figure 7a). In general, each request for information finds the input field immediately below, except for a few cases in which the answer must be indicated at the intersection between the rows and the columns of a table. Pages can be changed by the ‘forward’ and ‘back’ buttons placed at the bottom of them.

The survey schedule consists of 31 pages in total. In addition to the home page, there are 12 main pages subdivided as follows: one per each Part 0 and 1, nine per Part 2, one per Part 3; there are also 18 subpages, one for each local mechanism. The subpages can be reached from the main pages of Part 2 as they contain a diagram of the local mechanism to support its comprehension and a button to take a picture referring to it on the building under study (Figure 7b). The multiple tasks of the app, i.e., data collection, drawing of sketches, and photograph shooting, improve data management by storing efficiently the overall information related to a building. Each photograph is therefore simultaneously matched to the reference building, thus reducing the post-processing phase.

In Part 1 there is the possibility to open a graphic widget that allows to sketch by hand an outline of the building and its damage pattern (Figure 8a); this works as a reference for later interpretation of the input value. The sketchpad is a Java element that is called by a button in the main page (Figure 8b).

The graphic interface is thought to help the surveyor complete the task step-by-step, focusing on the building under study and avoiding mistakes and information losses. The pieces of information input are retained by the forms as the user navigates through the pages and therefore they can be changed at any time. A selected field in the form is displayed in red.

In addition, popup messages are displayed when mistakes are made that, conversely, in the analogical procedure would pass into the post-processing phase; these messages do not cover the entire page of the app, so the user does lose the context of the warning. The absence of the number and the location of a building prevents the user to continue to the second page of the app as the key information concerning its identification would be missing; in this case a message reminds the user to fill in the required data (Figure 9a) that are highlighted in red (Figure 9b).

The logic bounds introduced in the paper schedule are implemented in the app. They can be simply represented by the widget type that determines the type of input (text, numbers) or choice (single or multiple), or can influence the behavior of the components, e.g., when some selection options are disactivated as a function of certain values. As an example, when the ‘other’ choice is checked in check boxes or radio buttons, a user can complete the field with a free text that is activated only in that case, whereas the other options cannot be selected; or, when certain values are assigned to damage or vulnerability (generally ‘null’ or ‘non-triggerable’), the other values cannot be selected anymore. Enabling or disabling specific options simplifies the filling work, reduces mistakes, and supports the surveyor’s critical inspection process.

A user can either complete all the modules of the form and send it or, once any section is completed, proceed to the end and send it to the database. In fact, at each page change a partial .xml file is created and then cached in the local device; at any change in the page, its contents are updated. This behavior also makes possible to display the answers already given when pages are swapped. At the end of the procedure, the partial files are appended to one another to build the final .xml file, which replaces the paper form, and it is transferred over the web to the database by pushing the ‘send’ button (Figure 10).

When the mobile network is available, the user receives a message of a successful synchronization to the database and only then the app returns to the home page to start a new routine. Conversely, the app returns to the homepage, but the user is warned that there is no connection available and that the data are stored locally on the device until the network returns. A banner warns the user of this availability and a tap on it brings to the sync page where the pending forms are shown; the user is warned when there are no pending forms. The sync page can also be reached from the home page of the app. At the user’s tap, the forms are sent to the database starting from the oldest, while the cache is emptied in order to avoid confusion, emptying the fields of the module and limiting the occupied space in the device.

The home screen also displays a button for the retrieval of completed schedules. Each user can retrieve any survey archived in the database according to the location and the unique number of a building given in the preliminary mapping (Figure 11a). The app feedbacks the user when the schedule does not exist or there is no network connection; otherwise, the form received by a message over the web is locally compiled into the .xml file that can be loaded and displayed by the app, scrolling it up and down through its entire length (Figure 11b).

3.4. Damage and Vulnerability Indexes

At the end of Parts 1 and 2 of the MUSE-DV schedule, a user can also calculate damage and vulnerability indexes to obtain an overall evaluation of a building. This leads to an immediate estimation of damage and vulnerability of a building that can be compared with the results of previously inspected buildings. The availability of the indexes during the survey is important to support the expert judgment of the surveyor, who can take advantage of the direct comparison between the synthetic results and the real performance of a building also in relation to already compiled forms. The calculations are executed in the local device and the results are stored in the local .xml file until the form is completed and sent to the database. The app’s input widgets are matched with numeric variables in the source code, which are initialized and then set to the value selected on the corresponding widget. The valorization of the variables happens in different ways depending on whether checkboxes, radio buttons, or spinners are used. Warning messages are displayed when the ‘index’ button is tapped and some fields are still blank.

At the end of Parts 1 and 2, indexes are calculated on the fly by tapping on the ‘summary’ button (see Figure 12a,b), as well as a summary of quantitative evaluations, including the damage grade according to EMS-98 and the damage and vulnerability indexes (Figure 12c). Therefore, indexes should not be calculated in a post-processing phase, but they are elaborated in the same phase of data collection. Moreover, their values can be adapted to the specific condition of a building by correcting in real time the answers given, if needed.

3.5. Data Export and Interoperability

In order to make data already usable in other applications, e.g., GIS software or for statistical analysis, the database entries can be exported to text files with comma-separated values, i.e., .csv file format. This operation can be activated from the app, which feedbacks the user of the successful operation, but the file is exported in the server directory. Through the admin page of the database in a web browser, the last .csv exported can be downloaded and they are progressively overwritten.

4. Trial Application

The MUSE-DV app was tested on a pilot sample of 50 masonry buildings located in Castelsantangelo sul Nera (district of Macerata, central Italy). This village was struck in 2016–2017 by a seismic sequence that spanned more than five months, with major events on 24 August, 26 and 30 October 2016, and 18 January 2017.

The origins of Castelsantangelo sul Nera date back to the 13th century when a walled village was founded at the foot of Mount Cornaccione. The boundary walls have a triangular plan developed on the flank of the mountain and enclose the oldest part of the village, whereas the expansion grew on the bank of the river Nera that flows in the valley beneath (Figure 13).

Castelsantangelo sul Nera was in the epicentral area of the 26 and 30 October events. Severe damage and many collapses were observed in the oldest masonry buildings and those that had undergone the replacement of horizontal diaphragms and roofs with r.c. structures with no strengthening applied to low-quality walls (random limestone rubble laid in a lime and clay mortar). Other relevant information about the case study can be found in Vettore et al. [49].

According to the methodology proposed in Section 2.2, the structural units (SUs) were first identified on a preliminary GIS map of the settlement (Figure 13). A progressive number was assigned to each polygon representing an SU, as well as cadastral data, using QGIS software [103]. A first inspection within the historical center was carried out by the authors in June 2018 with support of the analogical MUSE-DV procedure. The data collection onsite and the following post-processing gave the chance to optimize and improve the organization of the schedule. The use of the MUSE-DV app was then tested in November 2019. The acquisition time was reduced thanks to the availability of multiple tools (whiteboard for sketches, camera for pictures, survey schedule) in the same device. Similarly, the post-processing phase was optimized since the database was already available at the end of the survey with minimum editing effort and it was already formatted as required for the following analyses.

The post-processing started downloading a .csv file from the web page of the database. The analyses carried out were related to damage, vulnerability, and constructive issues on a statistical and spatial basis. This file was imported within the GIS database and joined to the attribute table already defined in the preliminary mapping of the SUs. The data were subdivided into four layers, referring to the same polygons, which corresponded to the four sections of the MUSE-DV form (see Table 3). Once the data had been stored in the database, they were queried to identify specific issues concerning damage patterns (e.g., damage grade according to EMS-98 or mechanisms for Part 0; damage level for each mechanism for Part 2), vulnerability factors (e.g., presence of large openings or number of tie rods per façade for Part 1; specific vulnerability factors identified in Part 2), and constructive elements (e.g., type of units in masonry, type of roofs, interventions for Part 3).

As the overall damage and vulnerability indexes calculated by the app are also stored in the database, their thematic map was obtained in QGIS (Figure 14 and Figure 15). Figure 14 compares the damage grade according to EMS-98 (Part 0) with the damage index derived from Part 1 (DI₁); each SU polygon was colored according to a DI interval.

The EMS-98 damage grade (Figure 14a) is the reference for the calibration of the damage indexes of Parts 1 and 2, whereas the EMS-98 vulnerability class is the reference for vulnerability as they are obtained from a method independent from MUSE-DV (i.e., [4]). In addition, damage and vulnerability indexes must be consistent among the MUSE-DV sections, although they refer to different items for assessment (building components, damage mechanisms). As one may observe, in general, DI₁ (Figure 14b) does not have the same variability as the EMS-98 damage grades, especially at low damage, whereas DI₂ (Figure 14c) offers a better matching as the highest values (0.61–1.00) correspond to the severe damage (Figure 14a (4,5)). This can be explained as DI₁ depends on factors (e.g., building components inside a building) that cannot generally be assessed through an external survey, whilst Part 2 refers only to the external aspect of a building as it involves damage mechanisms. Therefore, the validity of DI₁ is limited to the cases in which a complete inspection was possible.

As far as vulnerability is concerned, Figure 15 shows the VI₂ values of Part 2 and the EMS-98 vulnerability classes assigned to Castelsantangelo sul Nera buildings at the end of Part 3. One may observe that high VI₂ values correspond to the most vulnerable EMS-98 classes, i.e., A and B, and vice versa. In addition, the vulnerability distribution of Part 2 (Figure 15a) has a good matching with the damage one (Figure 14c) as a high vulnerability index corresponds to high damage; however, VI₂ ranged between 0 to 0.68, i.e., it underestimates the parameter if compared with DI₂ (0.94 maximum value). Therefore, referring to collapse mechanisms, the MUSE-DV vulnerability index can be considered as a proxy of damage, but a larger sample is required to find a robust correlation between the two parameters.

5. Conclusions

The visual inspection of the actual damage to buildings is the primary source of information on their behavior to the earthquake for both preventive (vulnerability) and balance (damage) aims. Over the years, this activity has been standardized in procedures based on printed forms to be filled in onsite; their usage homogenizes the data collected and reduces the subjectivity of the surveyor.

Information technologies are nowadays largely applied to acquire, process, and interpret earthquake-related data that cover a wide range of types, such as texts, pictures, schemes, and indexes. In such a framework, this paper proposed an Android application for mobile devices for the onsite multilevel assessment of seismic damage and vulnerability of masonry buildings (MUSE-DV). As a survey procedure, the MUSE-DV form was validated by a large extent by buildings struck by the 2016 Central Italy earthquake. The front-end app is structured in four sections, divided into 12 pages for a total of 220 modules; the back-end database contains the same fields, and each record describes an individual building on site. The app supports the data collection phase in a methodological framework that begins with the preliminary mapping of buildings as individual structures in a Geographic Information System (GIS) and ends in data export and post processing in either GIS or statistical pieces of software. The app communicates over the internet with a remote archive (database) and the mobile device displays the procedure and manages the minimum data processing required to calculate overall damage and vulnerability indexes. The source code and the interface implement the logic bounds defined in the paper schedule, thus helping the surveyor and improving the final quality of the data collected onsite.

The MUSE-DV app helps in improving the efficiency of a survey, regardless its aim, by including data, pictures and sketches collection, indexes calculation on the same platform, and their storage within a central online database. The post-processing phase can take advantage of the predefined data structure, which enables interoperability, as data can be imported in various processing software for statistical analysis or mapping. The app manages different states of network connectivity (offline and online modes) using a cache in the local device and automatically checks the integrity of the database, removing conflicts and accessing the database to retrieve already completed forms. The delete operation of already filled forms can be managed only within the online database so that no records can be unintentionally deleted or altered. As far as the assessment is concerned, the main advantage of the application is that certain options are automatically turned on or off based on specific answers given during onsite activities, supporting and accelerating the surveyor’s activity. In addition, the app ensures the integrity of data as the surveyor is warned of logical errors and wrong formats in answering the form.

The MUSE-DV app supported the onsite survey of the village of Castelsantangelo sul Nera in the Macerata district from data collection to spatial analysis.

Possible developments of the app include its adaptation to an iOS operative system to widen the audience and a specific calibration of damage and vulnerability indexes based on their crossed comparison with the EMS-98 damage grades and vulnerability classes.