European Project Nº: FP7‐614154 Brazilian Project Nº: CNPq‐490084/2013‐3 

Project Acronym: RESCUER  

Project Title: Reliable and Smart Crowdsourcing Solution  for Emergency and Crisis Management 

 Instrument: Collaborative Project 

European Call identifier: FP7‐ICT‐2013‐EU‐Brazil Brazilian Call identifier: MCTI/CNPq 13/2012 

  

Deliverable D1.1.2 Requirements Specification 2 

 Due date of deliverable: PM13 

Actual submission date: January 31, 2015   

      

  

Start date of the project: Europe: October 1, 2013   | Brazil: February 1, 2014 Duration: 30 months Organisation name of lead contractor for this deliverable: UFBA  

Dissemination level 

PU  Public 

PP  Restricted to other program participants (including Commission Services)

RE  Restricted to a group specified by the consortium (including Commission Services)   

CO  Confidential, only for members of the consortium (including Commission Services)   

   

 

  

2  

Executive Summary Requirements Specification 2 

 

This document presents  the deliverable D1.1.2  (Requirements  Specification  2) of project  FP7‐

614154  |  CNPq‐490084/2013‐3  (RESCUER),  a  Collaborative  Project  supported  by  the  European 

Commission  and  the MCTI/CNPq  (Brazil).  Full  information  on  this  project  is  available  online  at 

http://www.rescuer‐project.org. 

This  deliverable  provides  the  results  of  Task  1.1  (Requirements  Engineering)  for  the  second 

iteration of RESCUER. This document is an evolution of the requirements specified for the RESCUER 

system,  presented  in  D1.1.1  [6].  Due  the  research  nature  of  this  project,  this  version  of  the 

document  has  significant  changes when  compared  to D1.1.1  [6]. Changes  refer  to  the  document 

contents, but also to the structure.  It updates the requirements and use cases specified  in the first 

iteration  as well  as  it  presents  new  requirements  and  use  cases  specified  for  the  second  project 

iteration. 

This  is a  living document that will be extended to support the goals of RESCUER third  iteration 

(D1.1.3), and to reflect acquired knowledge, as the project progresses and results are evaluated. 

  

 

List of Authors (alphabetical order)  

Ana Maria Amorim – UFBA 

Izabel Andion ‐ UFBA 

Laia Gasparin Pedraza – VOMATEC 

Pedro Kislansky – UFBA 

Renato Novais – UFBA 

Silas Graffy – VOMATEC 

 

 

List of Reviewers (alphabetical order) 

Eduardo Almeida – UFBA 

Lucas B. Ruas de Oliveira‐ USP 

Kai Breiner – IESE 

Vaninha Vieira – UFBA 

 

 

   

  

3  

Contents 1.  Introduction ........................................................................................................................ 6 

1.1.  Purpose ....................................................................................................................... 6 

1.2.  Change Log .................................................................................................................. 7 

1.3.  Partners’ Roles and Contributions .............................................................................. 7 

1.4.  Document Overview ................................................................................................... 7 

2.  RESCUER Goals and Components ....................................................................................... 8 

3.  Stakeholders ..................................................................................................................... 10 

3.1.  Users’ Profiles ........................................................................................................... 10 

3.2.  Interactions between Stakeholders .......................................................................... 11 

4.  Scenarios ........................................................................................................................... 13 

4.1.  Overview ................................................................................................................... 13 

4.2.  Variants in the Scenarios ........................................................................................... 14 

4.2.1.  Large‐scale events X Industrial parks ..................................................................... 14 

4.2.2.  Industrial Parks in Brazil x Industrial Parks in Europe ............................................ 15 

4.3.  Scenarios ‐ general .................................................................................................... 15 

4.3.1.  Scenario 1: Incident in Chemical Parks (Europe) ................................................... 16 

4.3.1.1.  Sub‐scenario 1.1 ‐ Fire in a Production Plant ............................................................ 16 

4.3.1.2.  Sub‐scenario 1.2 ‐ Gas Leakage while Filling Chlorine Gas ....................................... 18 

4.3.2.  Scenario 2: Incident in Industrial Parks (Brazil) ......................................................... 21 

4.3.2.1.  Sub‐scenario 2.1 ‐ Ethylene Gas Leakage .................................................................. 21 

4.3.3.  Scenario 3: Incident at Large‐scale Events (Europe) ................................................. 23 

4.3.3.1.  Sub‐scenario 3.1 – Fire in a football stadium during a football match ..................... 23 

4.3.4.  Scenario 4: Incident at Large‐scale Event (Brazil) ..................................................... 26 

4.3.4.1.  Sub‐scenario 4.1 ‐ Fire in a football stadium during a football match ...................... 26 

5.  RESCUER System Requirements ....................................................................................... 29 

5.1.  Functional Requirements .......................................................................................... 29 

5.2.  Non‐Functional Requirements .................................................................................. 38 

6.  Use cases ........................................................................................................................... 40 

References .................................................................................................................................. 50 

Glossary ...................................................................................................................................... 51 

Appendix A .................................................................................................................................. 54 

  

4  

List of Figures 

FIGURE 1: CONCEPTUAL OVERVIEW OF RESCUER .......................................................................................................... 8 

FIGURE 2: USER PROFILES AND SUBGROUPS FOR THE RESCUER SYSTEM ............................................................................ 10 

FIGURE 3: CROWDSOURCING INFORMATION GATHERING ................................................................................................ 11 

FIGURE 4: GROUP‐TARGET FOLLOW‐UP INTERACTION .................................................................................................... 12 

FIGURE 5: COORDINATION INTERACTION ..................................................................................................................... 12 

FIGURE 6: CAMAÇARI INDUSTRIAL PARK PLANT ............................................................................................................ 21 

FIGURE 7: TIME LINE EXAMPLE .................................................................................................................................. 36 

FIGURE 8: USE CASES DIAGRAM – MOBILE CROWDSOURCING SOLUTION ........................................................................... 40 

FIGURE 9: USE CASE DIAGRAM – EMERGENCY RESPONSE TOOLKIT .................................................................................... 44 

   

  

5  

List of Tables 

TABLE 1: EMERGENCY LEVELS ................................................................................................................................... 13 

TABLE 2: GENERAL VARIATIONS BETWEEN INDUSTRIAL PARKS AND LARGE‐SCALE EVENTS ........................................................ 14 

TABLE 3: DIFFERENCES BETWEEN BRAZIL AND EUROPE REGARDING ORGANISATIONS [10] ...................................................... 15 

TABLE 4: DIFFERENCES BETWEEN BRAZIL AND EUROPE CONCERNING SPECIFIC ROLES (ADAPTED FROM [10]) .............................. 15 

TABLE 5: FIRE IN A PRODUCTION PLANT (EUROPE) ......................................................................................................... 17 

TABLE 6: GAS LEAKAGE WHILE FILLING CHLORINE GAS (EUROPE) ....................................................................................... 19 

TABLE 7: ETHYLENE GAS LEAKAGE DUE TO A RUPTURE IN A STORAGE LOCATION (BRAZIL) ........................................................ 22 

TABLE 8: FIRE IN A FOOTBALL STADIUM DURING A FOOTBALL MATCH (EUROPE) ................................................................... 24 

TABLE 9: FIRE IN A FOOTBALL STADIUM DURING A FOOTBALL MATCH (BRAZIL) ..................................................................... 27 

TABLE 10: COMPONENTS CODIFICATION ..................................................................................................................... 29 

TABLE 11: RESCUER ITERATIONS AND GOALS ............................................................................................................. 29 

TABLE 12: LIST OF RESCUER FUNCTIONAL REQUIREMENTS PER ITERATION ........................................................................ 30 

TABLE 13: LIST OF RESCUER FUNCTIONAL REQUIREMENTS PER ITERATION ........................................................................ 38 

TABLE 14: MOBILE CROWDSOURCING SOLUTION ‐ FUNCTIONAL REQUIREMENTS X USE CASES ................................................ 54 

TABLE 15: EMERGENCY RESPONSE TOOLKIT ‐ FUNCTIONAL REQUIREMENTS X USE CASES ....................................................... 55 

TABLE 16: FEATURES (FIRST ITERATION) X REQUIREMENTS ............................................................................................. 57 

TABLE 17: FEATURES (SECOND ITERATION) X REQUIREMENTS ......................................................................................... 59 

   

  

6  

1. Introduction 

The  main  challenge  for  an  Emergency  Command  and  Control  Centre  is  to  obtain,  quickly, 

contextual information about the emergency in order to make the right decisions. Late decisions or 

decisions  based  on  inaccurate  information  have  a  great  potential  for  causing more  damages.  As 

mobile  devices  are  widely  used  and,  in  many  cases,  connected  to  the  Internet,  crowdsourcing 

information and mobile technologies offer great potential for addressing this challenge [5]. 

The  RESCUER  project  intends  to  provide  Command  and  Control  Centres  with  real‐time 

contextual  information related to the emergency situation through the collection, combination and 

aggregation of crowdsourcing  information, and to support announcements about the emergencies 

tailored to different audiences (e.g. authorities, affected community and general public) [5].  

This document describes the requirements for the RESCUER system from the users’ perspective 

using  general narrative, without  system details or measures. Other documents  in  the project  are 

responsible for complementing this information. 

The  identified  information, requirements and use cases, were obtained  in  interactions with the 

end‐user partners of the project, through the following methods: 

o Workshops; 

o Questionnaires; 

o Interviews; 

o Ethnographic studies; and  

o Literature and documentation reviews. 

1.1. Purpose 

The purpose of this document is to describe the scenarios, requirements and use cases involved 

in the RESCUER system, considering the first two iterations: 1) Crowdsourcing information gathering, 

and 2) Group‐target follow‐up Interaction and coordination among operational forces. As such, it  is 

an  evolution  of  the  Deliverable  D1.1.1  [6].  The  first  iteration  deals  with  the  spontaneous 

communication from the crowd to the Command and Control Centre, providing real‐time contextual 

information  regarding  the  incident. The second  iteration covers group‐target  follow‐up  interaction 

and the coordination among Workforces.  

Group‐target follow‐up interaction refers to communication between the Command and Control 

Centre and a specific group in the crowd. This communication aims to ask further information about 

an  incident,  including  missing  information,  clarify  information,  contradictory  information, 

investigation of potential problems, and continuously evolving  information. Coordination  refers  to 

communication  between  the  Command  and  Control  Centre  and Workforces  directly  or  indirectly 

involved  in the  incident. The communication,  in this case, aims to get  information about resources 

and tasks, request additional resources or ask people to perform specific tasks.  

Follow‐up interaction between the Command and Control Centre and the public is object of the 

third iteration (Crowd Steering). Therefore, this is beyond the scope of this deliverable. 

  

7  

1.2. Change Log 

This deliverable  is a  living document.  It extends the content of the deliverable provided  in the 

first  iteration  (D1.1.1)  by  adding  new  contents,  changing  and  deleting  previously  defined 

information.  It  updates  information  that was  not  available  at  the  time  of  the  first  iteration  and 

improves the overall deliverable. The document was restructured and the presented  information  is 

aligned with the information described in the deliverables D1.4.2 [9] and D4.1.2 [10]. 

The description of the organisations that act as stakeholders  in the RESCUER system, as well as 

their  internal processes, was  summarized, while  full details  are provided  in  the document D4.1.2 

[10].  This  document  focuses  on  the  stakeholders  necessary  to  understand  the  specified 

requirements and use cases.  

We changed the scenarios’ presentation from plain text to tables arranged chronologically and 

linked with the RESCUER iterations. Besides, following the Interim Review comments, we provided a 

better description of the differences between the Brazilian and European scenarios. 

The use cases and requirements specified in the first iteration were updated and new ones were 

included  regarding  the  second  iteration. We  created  a  coding  standard  to  uniquely  identify  the 

requirements and use cases. 

The  tables  with  the  matrix  Requirements  X  Use  Cases  were  changed  to  allow  a  better 

understanding of the Emergency Response Toolkit and Mobile Crowdsourcing Solution components. 

Tables with the matrix Features X Requirements were added for the first and second iteration. 

1.3. Partners’ Roles and Contributions 

UFBA was  responsible  for  coordinating  the writing  of  this  deliverable  in  the  second  iteration 

(D1.1.2), with the following contributions:  

To  review  D1.1.1  consolidating  its  information with  the  contents  of  others  system’s 

deliverables (D1.4.2 [9] and D4.1.2 [10]); 

To elicit with stakeholders the information regarding RESCUER second iteration goals; 

To  incorporate  the  acquired  knowledge  in  D.1.1.2  through  the  description  of  new 

requirements  and  use  cases,  and  the  update  of  the  requirements  and  use  cases 

provided in the first iteration. 

VOMATEC’s role in the second iteration was to elicit information concerning the particularities of 

the European side, and to discuss and review the specified requirements and concepts. 

1.4. Document Overview 

The remainder of this document is structured as follows: 

Chapter 2 briefly describes the RESCUER components; 

Chapter 3 presents the involved stakeholders and their profiles; 

Chapter 4 describes the system variants and investigated scenarios; 

Chapter 5 specifies the functional and non‐functional requirements; 

Chapter 6 specifies the use cases.   

  

8  

2. RESCUER Goals and Components 

The RESCUER project aims at developing an  interoperable computer‐based solution to support 

command  centres  in  quickly  handling  emergencies  and  managing  crisis  based  on  reliable  and 

intelligent analysis of crowdsourcing information mashed up with open data. The special focus is on 

incidents in industrial areas and at large‐scale events. 

The RESCUER solution encompasses four main components (Figure 1):  

Mobile Crowdsourcing Solution (MBL): supports the communication between the crowd 

(e.g.,  eyewitnesses,  employees)  with  first  responders  (e.g.,  police,  firefighter)  and 

command and control centres. The crowd can send information in text, image and video 

formats.  It  comprises  a  set  of mobile  applications  tailored  to  different  platforms  and 

devices;  

Data Analysis Solutions  (DAS): composed by  the algorithms  that will process and  filter 

the received data to extract relevant and consolidated information; 

Communication  Infrastructure  (COM):  offers  the  needed  equipment  to  allow  the 

information flowing between stakeholders; and  

Emergency  Response  Toolkit  (ERTK):  a  set  of  solutions  to  manage  the  analysed 

crowdsourcing  information  and  to  present  them  to  the  command  and  control  centre 

using adequate visualization metaphors. 

 

 

Figure 1: Conceptual overview of RESCUER 

The  functionalities of the Mobile Crowdsourcing Solution and the Emergency Response Toolkit 

are  the main sources  for  the  requirements and use cases specified  in  this deliverable, since  those 

components have explicit interaction with the stakeholders. 

  

9  

The  Mobile  Crowdsourcing  Solution  gathers  information  from  the  crowd  when  an  incident 

happens  (first  iteration),  and  supports  the  follow‐up  interactions  between  the  Command  and 

Control Centre and the workforces  (second  iteration). The main goal  is to keep the Command and 

Control  Centre  informed  about  the  evolution  of  the  emergency,  which  will  be  input  for  the 

Emergency Response Toolkit.  

The  main  objective  of  the  Emergency  Response  Toolkit  is  to  support  decision‐making, 

coordination, and  communication between  the Command and Control Centre and  involved users. 

The ERTK shall provide an  intuitive, concise, but resourceful,  information dashboard, with different 

metaphors for information visualisation, as well as modern solutions for emergency mapping. It will 

integrate and extend existing solutions and add support for coordination among Workforces. 

RESCUER components are designed for use in four scenarios (detailed in Section 4): 

1. Industrial Parks in Brazil; 

2. Industrial Parks in Europe; 

3. Large‐scale Events in Brazil; 

4. Large‐scale Events in Europe. 

   

  

10  

3. Stakeholders  

3.1. Users’ Profiles 

This section describes the stakeholders that are  intended to interact with the RESCUER system, 

and their profiles. The complete list of organisations, their members, roles, and detailed description 

are presented in the Deliverable 4.1.2 [10]. 

Users of the RESCUER System are divided into four main profile groups, as illustrated in Figure 2:  

Command and Control Centre (Crisis Committee, and Emergency Committee); 

Workforces (Firefighters, Police, and Rescue Services); 

Supporting Forces (Volunteers, Security Staff, and Emergency Staff); and 

Civilians (Employees and Visitors). 

 

 

Figure 2: User profiles and subgroups for the RESCUER system 

The  profiles  are  divided  into  subgroups.  Each  subgroup  has  a  set  of  stakeholders  and  each 

stakeholder has a  role. For  instance,  inside  the  subgroup Rescue Services we have  the  role of  the 

Rescue  leader, which  is  the  commander of  the Rescue  Service.  The  complete  list of  roles  can  be 

found in deliverable D4.1.2 [10]. 

The users of  the RESCUER system can also be classified according  to  the component  they can 

access, as MBL user or ERTK user. MBL users are allowed to use the Mobile Crowdsourcing Solution 

and can belong to the following User profiles: Workforces, Supporting Forces and Civilians. The ERTK 

users  are  those  that  can  use  the  Emergency  Response  Toolkit,  and  they  can  only  belong  to  the 

Command and Control Centre profile. 

Supporting  forces  are  people  or  organisation  that  don’t  belong  to  police,  firefighters,  rescue 

services  or  the  Command  and  Control  Centre  (C&CC)  and  yet  have  a  security  role  during  the 

incident. They are  responsible  for  supporting  the workforces. Civilians are people  that don’t have 

any  security  role  whatsoever  during  the  incident.  Additionally,  civilians  have  to  be  an  incident 

eyewitness or to be involved in some way in the incident.  

  

11  

3.2. Interactions between Stakeholders 

This section describes how the flow of  information happens  in RESCUER,  its goals and  involved 

stakeholders. The communication begins with  the  interaction between  the crowd and  the system. 

The Crowdsourcing Information Gathering is a spontaneous event from the crowd to the Command 

and Control Centre to inform about the incident in many ways (Figure 3). The user provides reports 

about the incident, in an intuitive way, answering pre‐defined simple questions, writing free text, or 

sending photos or videos. 

 

Figure 3: Crowdsourcing information gathering 

As a second step, the Command and Control Centre can communicate with the crowd to obtain 

further  information.  This  step  is  called  Group‐target  Follow‐up  Interaction  (Figure  4).  After  the 

information gathered in the first iteration has been analysed and visualized, they are used to support 

the  coordination  among  Workforces  to  clarify  received  information,  to  investigate  potential 

problems, and to continuously evolve the information.  

Group‐target Follow‐up  Interaction  is any communication between  the Command and Control 

Centre  and  a  specific  group.  This  specific  group  is  based  on  user  criteria  such  as  profile,  role, 

position, movement,  previous  interaction  and  affiliation.  The  communication  from  the Command 

Centre to the group‐target can occur in one of two ways: 

One‐to‐one: Command Centre → specific user  (a visitor, an employee or a member of 

the Workforces); 

One‐to‐many:  Command  Centre  →  group‐target  (a  specific  group  considering  the 

Command Centre needs in that moment). 

 

  

12  

 

Figure 4: Group‐target follow‐up interaction 

The  third  step  is  the  Coordination  Interaction,  where  the  Command  and  Control  Centre 

communicates with the Workforces, Supporting Forces or external entities (e.g. Civil Defence) to ask 

for resources or to execute specific tasks. The communication occurs to one person or to a group‐

target (Figure 5). 

 

Figure 5: Coordination interaction 

The  last  step,  the  Crowd  Steering  and  Communication  to  the  public,  is  subject  of  the  third 

project iteration. 

   

  

13  

4. Scenarios 

4.1. Overview 

The RESCUER project considers two main scenarios of usage: 

a) Large‐Scale  Events:  events  that  have  a  highly  concentrated  number  of  people  and 

mobilize several security resources. They can be of various types: sports (football, Olympic 

Games), popular street events (Carnival, typical local festivals), music festivals, and more. 

The  large‐scale  event  main  characteristic  is  also  the  object  of  the  RESCUER  project 

research,  the  existence  of  a  crowd  of  people  [13].  Besides,  this  scenario  considers 

heterogeneous places, meaning that not necessarily an emergency management protocol 

was tested, trained or simulated in that place before the event started; 

b) Industrial Parks: delimited areas  that comprise several  industrial companies  (from areas 

such as chemical, environmental protection, cellulose industry, and others). This is a more 

controlled  scenario,  where  protocols  and  standards  are  very  well  defined,  and 

continuously trained through exercises and simulations. Also, the kind of people allowed 

to be in this place is more limited and less heterogeneous. 

Table  1  shows  how  emergencies  in  industrial  parks  are  classified  in  four  different  levels, 

according to the incident’s severity. Those levels are common to both Brazil and Europe. 

Table 1: Emergency levels 

Level  Characteristics of the Emergency  Responsible for the Emergency Management 

LEVEL I  Emergencies that are restricted to a company and, most of the time, unnoticeable by people outside the company 

The Company Emergency Committee,using the company’s own resources 

LEVEL II  Emergencies that cause or have the potential to cause harm to people and/or company facilities and the environment, even if there is no evacuation. 

The Company Emergency Committee using the company’s own resources 

LEVEL III  Emergencies that cause or have the potential to cause harm to people and/or company facilities and the environment inside the Industrial Park, with partial or total evacuation of the Industrial Park Area. 

Representatives of all companies in the Industrial Park and a representative of the Industrial Park Emergency Committee 

LEVEL IV  The same scenario as level III, but with the potential to affect the surrounding community 

Representatives of all companies in the Industrial Park and a representative of the Industrial Park Emergency Committee 

 

  

14  

4.2. Variants in the Scenarios 

One  major  concern  in  the  RESCUER  project  is  to  identify  similarities  and  differences  in 

Emergency Management between Europe and Brazil and between  large‐scale events and  industrial 

parks.  In general, this study shows that the variances among them are not critical and their  impact 

on the RESCUER system development is minimal. 

In the following subsections, we discuss the variations between the scenarios of industrial parks 

and large‐scale events and between industrial parks in Brazil and in Europe. The differences between 

Brazil and Europe concerning large‐scale events will be investigated deeply in the third iteration. 

4.2.1. Large‐scale events X Industrial parks Table 2 shows the general differences found between Large‐scale Events and Industrial Parks.  

Table 2: General variations between industrial parks and large‐scale events 

Feature  Large‐scale Event  Industrial Park 

Operational 

Procedures 

Operational  procedures  used  to  be  less 

extensive  since  there  are  issues  known 

only with experience. The short duration 

of  its  activity  does  not  allow  the  Large‐

scale  Events  to  train  and  revise  the 

operational  procedures  as  much  as  in 

Industrial Parks 

Operational  procedures  are  better 

defined  and  specialized  for  each 

Industrial  Park.  These  procedures 

are  trained  and  revised  by  their 

security  experts  periodically.  Very 

organised. 

Professional 

Expertise 

Public services  in Large‐scale Events have 

more  unknown  issues,  which  increases 

the difficulty of their task. However, they 

are trained to work in these situations. 

Industrial  Parks  have  their  own 

internal Fire Brigade. This is a benefit 

in  terms of  training. The scenario of 

their  trainings  is  close  to what  they 

might  face. Even  the public  services 

are  aware  of  the  Industrial  Park 

potential  risks,  so  they  can  also  be 

better prepared. 

Technological 

Support 

It depends whether the organisation have 

resources  or  not  in  order  to  cope  an 

emergency. However, there is always the 

standard  technology  used  like  radio  and 

phones.  

RiskManager  –  System  for  supporting 

emergency management (Brazil) 

Radio  and  mobile  phones  for 

communication. 

None  emergency  management 

system found (Brazil). 

Financial 

Resources 

Shared budget.  Specific  budget  for  crisis  and 

emergencies. 

 

  

15  

4.2.2. Industrial Parks in Brazil x Industrial Parks in Europe Table  3  describes  the  differences  between  Brazil  and  Europe  concerning  the  organisations 

involved  in the Emergency Management. This  information was gathered during the Annual Project 

Meeting held  in Kaiserslautern, Germany,  in November 2014,  involvind end‐user partners of Brazil 

and Europe.  

Table 3: Differences between Brazil and Europe regarding organisations [10] 

Organisation  Brazil  Europe 

Emergency committee   

Command and Control Centre (C&CC)  

Fire Brigade 

Civil Defence 

Community volunteers 

Each  organisation  has  several  roles;  Table  4  shows  the  variance  between  Brazil  and  Europe. 

Although there is no emergency committee (EC) in Europe, several EC roles have an equivalent role 

in Europe, for instance, the emergency coordinator. Table 4 shows only the roles that are specific for 

one domain, Brazil or Europe. The Deliverable 4.1.2 [10] provides a complete list of all organisations 

related to Industrial Parks. 

Table 4: Differences between Brazil and Europe concerning specific roles (adapted from [10]) 

Organisation  Role  Brazil  Europe 

Emergency committee  Evacuation coordinator   

C&CC  Environment and energy coordinator

Crisis committee 

Police, firefighter and rescuer leader off‐

site 

Public authorities representative 

Committee coordinator 

Companies association representatives

 

4.3. Scenarios ‐ general 

The  scenarios  described  in  the  following  sections  are  actions’  protocols  established  by 

authorities, private organisations and security forces for emergency management. For the European 

scenario, only chemical companies compose the  Industrial Park of Linz (the  investigated park, used 

as reference in this document), therefore “Chemical Park” will be the term used to it. 

Each  scenario  is  followed by  a  table, which  summarises  the  scenario  and  links  the  scenario’s 

steps with  the  phase’s  iteration  of  the  project  (first  iteration   Information  Gathering;  second 

iteration   Follow‐up  Interactions  and Coordination;  and  third  iteration  Crowd  Steering).  The 

column  “Who”  refers  to  the  stakeholder  or  equipment  that  execute  the  action  described  in  the 

  

16  

column “Action Description”. The column “Iteration”  is divided  into two columns, the first column 

covers the Follow‐up interaction, while the second column the others.  

4.3.1. Scenario 1: Incident in Chemical Parks (Europe) 

The  two most  relevant  sub‐scenarios  regarding  incidents  in  a  chemical  park  are  fire  and  gas 

leakage.  In  this  scenario  description,  the  company  where  the  incident  presumably  occurred 

produces pesticides and  it  is  located  in  the Chemical Park of  Linz  (CPL). The  company  is classified 

according  to  the  SEVESO  II  guidelines  [3].  Therefore,  there  are  extensive  preventive  measures 

envisaged in its emergency and crisis management plan.  

4.3.1.1. Sub‐scenario 1.1 ‐ Fire in a Production Plant 

This scenario illustrates an emergency classified as Level III (see Table 1 for the description of the 

severity levels). An incident classified in this level is characterised by being clearly perceived outside 

the  CPL  and  by  clouds  of  smoke,  excessively  large  clouds  of  steam,  loud  and/or  lengthy  noise, 

powerful malodours,  the company’s  fire service acting outside  the chemical park, and  the  request 

for the emergency assistance of the Linz Professional Fire Service. 

Description of the Production Plant 

The  concerned production plant has  six  floors, with  a  total  height of  about  28 meters  and  it 

covers around 600 square meters. During the production process, easily flammable  liquid and solid 

matters are used. They are corrosive, toxic and they endanger the environment.  

The  whole  plant  is  secured  with  an  automatic  fire‐detecting  system  and  a  general  warning 

system. The production hall is defined as one fire compartment, thus it is a buildings section with the 

purpose  to  prevent  fire  spreading.  The  command  and  control  centre  of  the  industrial  area  is  in 

another fire compartment (as well as social areas and the interior staircases). 

Adjacent to the production plant, there is an above and underground tank storage used for input 

materials and  final products, an unloading  station  for wagons, an evaporation  system  for  sulphur 

dioxide and a production plant of a neighbouring company. 

Description of the Initial Situation 

An engine  fire occurs on  the  third  floor of  the described production plant and  the  fire  rapidly 

spreads within the production hall. A dense black cloud of smoke rises up to the sky and  it can be 

seen from far away. 

Day and time: Thursday, 10:00 a.m.  

Weather: light rain, + 7 °C, westerly wind (3 m/s) 

Process Flow and Organisation of Emergency Management 

 

Table 5 describes the sub‐scenario 1.1 ‐ Fire in a Production Plant in a chronological order, as 

the actions occur, and the procedures for handling the emergency. 

 

  

17  

Table 5: Fire in a production plant (Europe) 

Who  Action Description  Iteration 

Automatic or  

Eyewitness 

Start Incident: notify fire detectedInformation 

Gathering Eyewitness  Alert the Internal Fire Service (IFS)

Dispatcher  Send the IFS and the Rescue Service 

(RS) to the affected location 

Follow‐up 

interaction 

Coordination 

Activate the evacuation plan 

Inform External Fire Service (EFS) 

C&CC  Create a local command and control 

centre (C&CC) on site 

Call for reinforcements (EFS)

Patrimonial security  Block the surrounding roads for 

trucks 

Emergency 

manager 

Inform, via the C&CC, the adjacent 

enterprises and business 

representatives 

C&CC  Inform a fixed set of recipients Crowd Steering 

Fire service  Begin fighting the fire 

Coordination 

Workforces  Take actions to prevent further 

damages on surroundings and 

indoors 

Rescue service  Verify, at the meeting point, 

people’s status 

Rescue service 

commander 

Request (if someone is injured) 

reinforcements via the C&CC 

Establish a meeting point for the 

Workforces. 

Maintain contact with the local 

commander 

EFS  Help the IFS. Take the command of 

the emergency 

Representatives of 

the affected 

company 

Coordinate the actions with the local 

commander  

Meet with the crisis committee 

Provide incident reports for the 

surrounding companies 

Crowd Steering 

Members of the 

local command 

Arrive at the meeting room

Coordination Employees of the 

affected building 

Move to a safety location 

  

18  

Who  Action Description Iteration 

C&CC  Activate Linz telephone hotline 

Send first information to the press 

 

Crowd Steering 

Release first reports of the incident 

Communicate with the Press

Declare that the emergency 

operation is over 

  Clean the area 

Authorities  Start the investigation about the 

causes of the incident 

  Observe the affected area for the 

next 12 hours 

  Reduce the number of persons at 

the site of the incident 

  Update, periodically, the information 

about the incident 

 

4.3.1.2. Sub‐scenario 1.2 ‐ Gas Leakage while Filling Chlorine Gas 

Since  gas  leakage  also  affects  the  surrounding  areas  and  the  general  public  nearby,  it  is 

considered a level IV incident (Table 1). The organisation where the incident occurs has to take care 

about  the  external  operational  area.  Depending  on  the  leakage  expansion,  additional  external 

organisations (e.g., operational commands and commander‐in‐chief group) are set up. 

Description of the Manufacturing Plant 

In an uploading station of a manufacturing plant, chlorine gas is filled from a wagon into storage 

containers.  This  uploading  station  is  located  in  the middle  of  the Chemical  Park  of  Linz  and  it  is 

surrounded by production facilities, laboratories from neighbouring companies as well as a high‐bay 

warehouse. Chlorine gas at a high concentration is extremely dangerous and poisonous for all living 

organisms. 

Description of the Initial Situation 

During  the  filling operation  from  the  chlorine wagons  into  the  storage  containers  a  technical 

defect causes the collision of the transhipment locomotive with the wagon. Due to this collision, the 

filling‐spiral breaks. On the one hand, chlorine gas escapes from the storage containers and on the 

other hand,  liquid chlorine  leaks out from the wagon. Furthermore, the collision causes a defect of 

the pipe break safety devices and the emergency shut‐off valve does not work anymore. 

At  this moment,  two engineers  are working  in  the plant. When  the  incident occurs,  they  get 

seriously injured. However, both workers manage to escape from the danger zone. 

Day and time: Friday, 1:00 p.m. 

Weather: sunny, + 30 °C, westerly wind (3 m/s) 

 

  

19  

Process Flow and Organisation of the Emergency Management 

Table  6  describes  the  sub‐scenario  1.2  –  Gas  Leakage  while  Filling  Chlorine  Gas,  in  a 

chronological  order,  as  actions  are  executed,  and  the  procedures  for managing  the  emergency. 

Additionally, it links the procedures with the iteration steps of the RESCUER project. 

Table 6: Gas leakage while filling chlorine gas (Europe) 

Who  Action Description Iteration 

  Start Incident: Gas and chlorine liquid 

leaks 

 

Information 

Gathering 

Eyewitness  Two injured engineers escape from the 

danger (hot) zone 

Automatic 

pollutant‐

detecting system 

Alert the C&CC of the Company’s Fire 

Service (CoFS) 

Employees  All workers of the surrounding buildings 

move to the meeting point inside their 

buildings 

 

 

 

 

 

 

 

 

 

 

 

Follow‐up 

Interaction 

 

 

 

 

 

 

 

 

 

 

 

 

Coordination 

Dispatcher of 

CoFS 

Send an Internal Fire and Rescue Unit 

(IFRU) to the affected location 

Inform the Emergency Manager of the 

affected company 

IFRU  Arrive on site

Take the first operational actions 

Rescue unit  Take care of the injured workers 

IFRU  Request reinforcements (if necessary), 

via the C&CC of the CoFS 

C&CC  Request (if necessary) external 

Workforces to support the CoFS 

Request the set‐up of water walls

Form local command and control centre 

on site by company’s representatives 

and the emergency manager 

Dispatcher of 

C&CC 

Send updated reports to a predefined 

list of people 

Crowd 

steering 

Park’s property 

management 

Alert (if necessary) the surroundings, via 

loudspeaker and recorded voice 

messages  Coordination 

Gas gauge1  Transfer the results to the C&CC of the 

CoFS 

                                                            1 Tool that measures the amount or quality of the gas in the air or inside a device. 

  

20  

Who  Action Description Iteration 

Emergency 

manager 

Communicate the operations to the 

company’s managers 

  Control incident: the first operations 

show positive effects and the water wall 

holds back the main part of the 

escaping chlorine 

Members of the 

local commander‐

in‐chief group 

Arrive at the meeting room and are 

updated about the incident situation 

C&CC  Activate Linz phone hotline 

Requested 

workforces  

Arrive and take over the operational 

command 

Requested rescue 

services 

Arrive at the incident location

Commander of 

the operation 

Ask the roads blockage (if necessary)

Call surrounding volunteers fire service 

for further support (if needed) 

Instruct the fire service volunteers to 

measure, document and confirm, 

continually, the pollutant concentration 

outside the Chemical Park 

Firefighters  Wear protective suits and start caulking 

the leakage 

C&CC  Publish first information to the press 

about the incident 

Crowd 

steering 

Industry 

companies 

representative 

Update the company’s manager about 

the situation 

  End Incident: the situation is under 

control 

Commander of 

the operation 

Finish the operation

Unblock roads

Authorities  Start investigation about the causes of 

the incident 

 

  

21  

4.3.2. Scenario 2: Incident in Industrial Parks (Brazil) 

4.3.2.1. Sub‐scenario 2.1 ‐ Ethylene Gas Leakage 

This scenario describes an  incident that occurs  in a company  in the  Industrial Park of Camaçari 

(Brazil).  It simulates the occurrence of Ethylene Gas Leakage, a toxic and flammable  liquid, causing 

toxic smoke and fire in the containment basin. This scenario is considered catastrophic, requiring the 

convocation of PAM – Mutual Assistance Plan [2] with the possibility of convening the general PAM 

and total evacuation of the Park2. 

Description of the Industrial Park Plant 

The Camaçari Industrial Park (CIP) located in Bahia‐Brazil has more than 90 industries. The fields 

of expertise are varied: chemistry, petrochemical, automotive industry, cellulose, copper metallurgy, 

textile, fertilizer, wind energy, beverages and services. 

CIP’s Crisis Committee establishes contingency plans  in case of an emergency. Following those 

plans  is  the blueprint of  the CIP, as  illustrated  in Figure 6, which describes secure meeting points, 

streets that may be blocked, railroads, bus route and points where people should gather after the 

events in order to be transported to different locations. 

 

 

Figure 6: Camaçari Industrial Park Plant 

   

                                                            2According to NS007‐PCP Emergency Committee resolution. 

  

22  

Description of the Initial Situation 

During a normal operation at the Oxide Unit, U1400 area, Spheres of Ethylene Oxide (F‐1410 A), 

a 4” rupture of a line will occur between the F‐1410 A sphere and L‐1410 A pump, suddenly causing 

a large release of flammable and toxic liquid (Ethylene Oxide), causing fire in the containment basin 

and its surroundings. 

At  the moment  of  the  incident  there  will  be  a  team  (the  number  of  workers  can  oscillate 

between 2 and 4) performing activities around  the Oxide Spheres  (F‐1410), a  toxic  smoke and an 

open  flame  generated  from  the  leak, will  hit  them.  Thus,  between  2  and  4  victims will  undergo 

intoxication and  / or burns. They will be  removed  from  the hot zone  to  the  cold zone  for  further 

medical assistance. The service will be made to avoid a catastrophic scenario. 

Process Flow and Organisation of the Emergency Management 

Table  7  describes  the  sub‐scenario  2.1  ‐  Ethylene  Gas  Leakage,  chronologically  as  actions 

happened,  and  the  procedures  for  the  emergency management  due  to  a  rupture  in  a  storage 

location. Each action/procedure is associated with the RESCUER project iterations. 

Table 7: Ethylene gas leakage due to a rupture in a storage location (Brazil) 

Who  Description Iteration 

  Start incident: a pump leaks and releases 

a flammable and toxic liquid (Ethylene 

oxide), causing fire and toxic smoke 

Information 

Gathering 

Employee from the 

affected company 

Perceive (visually) the incident 

Inform, via the company’s radio, the 

operator supervisor (OS)    

Operator Supervisor   Convene the internal brigade 

 

 

 

 

 

 

 

 

 

 

Follow‐up 

Interaction 

 

 

 

 

 

 

 

 

 

 

Coordination 

Activate the company’s general alarm 

Members of the 

company’s crisis 

committee 

Arrive at the crisis room 

Crisis committee  Call the Mutual Aid Plan (PAM) of the 

affected area (for this scenario – Delta K) 

Inform the medical support 

  Expand incident: occurrences of 

explosions and fire 

Internal brigade  Identify injured people

Other operational 

personal 

Internal brigade   Intensify the operational work  

Remove injured people to a secure place 

Internal medical 

service (IMS) 

Supervise the situation 

Crisis committee  Activate the emergency plan (if the 

  

23  

Who  Description Iteration 

situation becomes worse) 

Medical support 

coordinator 

Ask for a general convening of the 

medical support personnel 

Operator Supervisor   Identify that the situation can affect the 

surrounding companies 

Emergency 

coordinator 

Request the blockage of surrounding 

roads 

Request medical support 

Company’s crisis 

committee 

Request the establishment of the 

emergency committee (EC) 

Emergency 

committee 

Order the evacuation of the Park

Crisis committee 

supervisor 

Inform the EC that the evacuation was 

performed 

Operator of the 

medical support 

(OMS) 

Identify complications on the victims

Ask for air support 

Ask for external medical support to 

transport victims to the nearest hospital 

Air and terrestrial 

support 

Arrive and take care of the victims 

  Control Incident: the incident is under 

control 

 

Internal brigade 

leader  

Notify (internally) the end of the 

emergency 

Allow the brigades to return to their 

companies 

Company’s crisis 

committee 

Notify the emergency committee that 

the situation is under control 

Crisis committee  Declare the end of the incident Crowd Steering 

Order roads to be unblocked

 

4.3.3. Scenario 3: Incident at Large‐scale Events (Europe) 

For the scenario of a Large‐scale Event  in Europe, a sub‐scenario of a fire  in a football stadium 

had been defined and described in the following.  

 

4.3.3.1. Sub‐scenario 3.1 – Fire in a football stadium during a football match 

   

  

24  

Description of a football stadium 

To describe this scenario, we took as reference the football stadium of the city of Linz, Austria. It 

lies on a hill in the urban area of Linz. This stadium is used as a football stadium as well as a stadium 

for athletic sports and concerts. Depending on the use, this stadium can hold up to 31,000 visitors. 

On the occasion of a football match, 18,000 visitors are expected. 

This stadium was build up according to modern aspects and safety standards and provides the 

necessary infrastructure for a UEFA‐license. 

Description of the initial situation 

At a  football match  in a  fully occupied stadium, with 18,000 visitors, a  fire  is  triggered due  to 

pyrotechnics. The fire spreads to an entire sector because of additional pyrotechnics. 

Due  to  smoke  emission  and  thermal  radiation,  a  mass  panic  is  triggered,  which  makes  it 

impossible for security and workforces to extinguish the fire. 

Day and time: Saturday 18:30 p.m. 

Weather: sunny, + 10°C, westerly wind (2m/s) 

Process Flow and Organisation of the Emergency Management 

Table  8  describes  the  sub‐scenario  3.1  –  Fire  in  a  football  stadium  during  a  football match, 

chronologically  as  actions  happen,  and  the  procedures  for  the  emergency  management.  The 

procedures are associated with the RESCUER system iterations. 

Table 8: Fire in a football stadium during a football match (Europe) 

Who  Action Description Iteration

Eyewitness  Start Incident: a fire is triggered due to 

pyrotechnics 

 

Information 

Gathering 

Expand incident: the fire spreads to an 

entire sector 

Occur mass panic 

Emergency manager  Activate the emergency exits 

Security Staff  Ensure the evacuation of the visitors

Follow‐up 

Interactions Coordination 

Workforce or 

supporting force on‐

site 

Set off the alarm

Release a red alert through the 

communication centre 

Crisis management 

team 

Start the emergency management 

operation  

  Expand incident: a bottleneck is 

formed at exits and escape openings 

Communication 

centres of the 

different organisations 

Coordinate operations among each 

other 

Workforces  Support the evacuation of the stadium 

and the people with sign‐postings  

  

25  

Who  Action Description Iteration

Try to calm down the situation at the 

exits 

 

Give instructions to the people on site 

via public address system (how to 

leave the place, be calm and 

organised, where the exit points are, 

etc.) 

Crowd 

Steering 

Emergency manager  Arrange a defined safety point for 

casualties  

Coordination 

 

 

Form rescue teams and triage forces 

Rescue teams and 

triage forces 

Search for injured people 

systematically in the stadium 

Fire service  Take first measures to fight the fire

Support the rescue teams 

Dispatchers at the 

command and control 

centres 

Send their task forces according to 

received orders  

Set off the alarm on their areas 

Task force’s crisis 

committee 

Convoke a meeting 

Member of the 

Workforces 

Assume the role of the overall 

commander‐in‐chief 

  Change the management phase: the 

mission shifts from the evacuation to 

the treatment of casualties 

Rescue service  Extend, continuously, their internal 

structures to cope with the incident (as 

needed) 

Rescue service’s 

command and control 

centre 

Request, periodically, the current 

situation in surrounding hospitals 

Member of the Rescue 

Service 

Support the communication with the 

press 

Crowd 

Steering 

Rescue service  Start the evacuation of casualties to 

surrounding hospitals 

Coordination 

Workforces on‐site  Send updates about the incident to the 

communication centre and the 

operational commander 

Police  Deal with the traffic routes and other 

casualties in the site of the incident 

Workforces on‐site  Notify the completion of the rescue   

  

26  

Who  Action Description Iteration

operation 

Transfer the coordination to the 

executive forces 

 

Executive forces  Cover the scene of the incident to 

collect forensic measures  

Investigate the causes of the incident   

Crisis committee and 

commander‐in‐chief 

Enable a “Crisis Hotline” and 

psychological care for relatives of the 

affected community Crowd 

Steering Hospital in 

surrounding areas 

Activate emergency plans and calls 

additional personal 

Communication 

centre of the rescue 

service 

Monitor the situation of the victims in 

the hospitals 

 

 

 

4.3.4. Scenario 4: Incident at Large‐scale Event (Brazil) 

This  scenario  describes  the  flow  of  events  during  a  fire  incident  in  a  football  stadium.  The 

procedures are based on a formal document of the fire department of Rio de Janeiro [12] and two 

interviews performed with:  

1) Colonel Julio, from the fire department of Salvador‐Bahia, responsible for the security of the 

Salvador main football stadium (the Arena Fonte Nova) during the Football World Cup 2014; 

2) Captain Paulo Henrique, from the fire department, specialist in football stadium security. 

 

4.3.4.1. Sub‐scenario 4.1 ‐ Fire in a football stadium during a football match 

Description of football stadium and general information 

The Arena  Fonte Nova  stadium was  built  according  to  the  FIFA  standards  for  the World Cup 

2014. It has a maximum capacity of 55,000 spectators. The stadium has 220 installed cameras.  

During FIFA World Cup 2014, FIFA representatives participated in some of the security decisions 

and  the  first  responders  are  called  “stuarts”,  who  are  volunteers  with  some  knowledge  about 

medical and  rescue procedures. The  first responders,  in normal situations, depend on the stadium 

status. If the stadium is private, the football team or private organisation, which owns the stadium, 

hires the security; they will be the first responders. If the situation worsens or the local workforces 

decide to  intervene, they have the authority to take over the situation. However,  if the stadium  is 

public, the local security forces of the city assume the security and they become the first responders. 

Arena Fonte Nova is a private stadium. 

   

  

27  

Description of the initial situation 

During a football match in Arena Fonte Nova with 20,000 people a smoke emerges on the north 

side of the stadium  followed by a  fire. The  fire  is detected by some of the 220 cameras  inside the 

stadium and by the some eyewitnesses. The people near the fire start to panic.  

Process Flow and Organisation of the Emergency Management 

Table 9 describes the sub‐scenario 4.1 ‐ Fire in a football stadium during a football match, in the 

chronological order of events, and the emergency management procedures, which are associated to 

the RESCUER system iterations. 

Table 9: Fire in a football stadium during a football match (Brazil) 

Who  Description  Iteration 

  Start incident: a smoke emerges on the 

north side of the stadium, followed by 

fire 

 

Information 

Gathering 

Eyewitness or 

Cameras 

Detect, visually, the fire 

  Expand incident: People near the fire 

start to panic 

  Activate the internal brigade (IB) 

Internal Brigade   Rescue people from the hot zone 

  

 

 

 

 

 

 

 

 

 

Follow‐up 

Interactions 

 

 

 

 

 

 

 

 

 

 

Coordination 

Call Salvador Fire Department (SFD), if 

they can’t manage the situation 

Commander on‐site 

(SFD officer) 

Establish a local Command Centre and 

analyse the situation 

SFD officer  Collect specific information (e.g., colour 

of the smoke, symptoms presented by 

the affected people, wind direction and 

people’s movement direction 

Notify the C&CC 

Request the area to be isolated

Call medical support to help the victims 

Local Commander 

and Police 

Isolate the area 

Police  Calm down the population 

  Inform the crowd (through scoreboard 

and stadium sound system) about the 

situation and ask them to evacuate the 

danger zone, without panic. 

  Evolve Incident: according to FIFA 

standards, the total evacuation of the 

stadium should occur up to 8 minutes 

  

28  

Who  Description  Iteration 

SFD officer  Ask (if necessary) for a helicopter to 

evacuate the victims 

Call for reinforcement (if the SFD brigade 

is not enough), directly or via C&CC 

  Evolve incident: fire fighting continues 

until the fire is completely controlled and 

there are no more victims on site 

Forensic team3  Control the perimeter of the incident to 

investigate the causes of the incident 

 SFD officer  Declare that the incident is over Crowd 

Steering Local commander  Provide the first details about the 

incident to the Press. 

 

                                                            3 Belongs to the civil or military police.  

 

 

29  

5. RESCUER System Requirements 

This section describes  the  functional and non‐functional  requirements of  the RESCUER system. 

The  functional  requirements  correspond  to  the  first and  second  iteration of  the project. The non‐

functional  requirements  are general  for all  iterations. The description of  the  requirements will be 

complemented according to the development and evolution of the components. The description of 

the non‐functional  requirements  is detailed  in  the Deliverable 5.1  [11]  including  their quantitative 

and qualitative metrics. 

Those  requirements were  identified  according  to  the  results  of  several workshops,  interviews 

and questionnaires, with different stakeholders from Brazil and Europe. They are in accordance with 

the set of features identified as the scope of the RESCUER system in the Deliverable 1.4.2 [9]. 

The  requirements  were  grouped  and  identified  considering  the  main  components  of  the 

RESCUER system. The identification was codified as FRXXXnn (functional requirements) or NFRXXXnn 

(non‐functional  requirements),  where  XXX  corresponds  to  the  component  that  implements  the 

requirement  (see Table 10)  and nn  is  a  sequential number  from 00  to 99. Table 11  identifies  the 

RESCUER iterations and goals, which is used to situate each requirement to the project iterations. 

Table 10: Components codification 

Code  Description

GNR  General (more than one component) 

COM  Communication Infrastructure 

DAS  Data Analysis Solution

ETK  Emergency Response Toolkit 

MBL  Mobile Crowdsourcing Solution 

Table 11: RESCUER iterations and goals 

Iteration  Goal 

1st Information Gathering 

2nd (a) Group‐target Follow‐up Interaction  

2nd (b)  Coordination among Operational Forces

3rd   Crowd Steering  

 

5.1. Functional Requirements 

This section describes the functional requirements  identified for the RESCUER system, for the 

first and second iterations of the project. Table 12 lists those requirements and associates them with 

the corresponding iteration. Next subsections describe each requirement and their business rules. 

   

 

 

30  

Table 12: List of RESCUER functional requirements per iteration 

Code  Name Iterations 

1st 2nd(a)  2nd(b)  3rd

FRMBL01  User Registration       

FRMBL02  SMS Support         

FRMBL03  Incident Notification Support       

FRMBL04  Report Support       

FRMBL05  Data Recording Advising  

FRMBL06  Automatic Data Recording       

FRMBL07  Position Data Tracking       

FRMBL08  Receive and Answer Follow‐up Structured Questions    

FRMBL09  Receive and Answer Follow‐up Free Questions     

FRETK01  User Registration   

FRETK02  Report Support   

FRETK03  Reports Filtering 

FRETK04  Report View   

FRETK05  Modify Report Characteristics   

FRETK06  Reallocate Report   

FRETK07  Highlight Important Report

FRETK08  Send Follow‐up Questions   

FRETK09  Incident View   

FRETK10  Incidents Filtering 

FRETK11  Merge Incidents   

FRETK12  Incident Map View   

FRETK13  Emergency Map View   

FRETK14  Crowd Density and Movement Speed

FRETK15  Workforces Position   

FRETK16  Key Places View   

FRETK17  Weather Information   

FRETK18  Emergency View 

FRETK19  Emergency Timeline   

FRETK20  Send Task/Resource Request   

FRETK21  Emergency Summary 

FRETK22  Time Frame Specification   

FRDAS01  Analysing Crowdsourcing Information   

 

   

 

 

31  

FRMBL01 ‐ User Registration  

Description: The Mobile Crowdsourcing Solution has  to offer an  interface where the user provides 

some basic  information, mainly the user profile: Workforces, Supporting Forces and Civilians. Other 

data  requested  depends  directly  on  the  user  profile.  The mobile  app  will  persist  this  data  (see 

deliverable D2.2.1 [8] 

 

Business Rules:  In the case that the user profile  is Workforces,  it must be  informed the workforces 

he  belongs  to  (Police,  Firefighter,  or  Rescue  Service),  and  his  role  on  the  emergency  manager 

process. If the user profile  is Supporting Forces, the user will at least  inform the specific supporting 

forces he belongs to (Volunteer, Security Staff, or Emergency Staff). Being a Volunteer,  in  industrial 

area, the user will at least inform the community around the industrial area in which he leaves. If the 

user profile  is Civilians, the user will  inform  if he  is a visitor or an employee. Being an employee,  in 

industrial area, the user will at least inform the company he works. 

 

FRMBL02 – SMS Support 

Description:  The  Mobile  Crowdsourcing  Solution  allows  users  to  send  and  receive  SMS  with 

timestamps information.  

 

Business Rules: Each SMS  is analysed by the Data Analysis Solution considering relevance, severity, 

reliability characteristics, and keywords, according to FRDAS01. 

 

FRMBL03 – Incident Notification Support 

Description: The Mobile Crowdsourcing Solution allows users to send incident notifications. The user 

can inform the type of incident (Fire, Explosion, Gas Leakage, or Environmental). 

 

Business Rules: Each  incident notification  sent  from  the Mobile Crowdsourcing Solution has  to be 

annotated with user profile, timestamp, device‐ID and position. 

 

FRMBL04 – Report Support 

Description: The Mobile Crowdsourcing Solution allows users to send  incident reports. A report is a 

set of predefined questions per type of incident with indications of possible answers. The detailing of 

each report is described in Deliverable D2.2.1 [8]. A report has to offer the possibility to add free text 

or/and photos or/and videos. 

 

Business Rules: Each report sent from the Mobile Crowdsourcing Solution has to be annotated with 

user profile, type of incident, timestamp, device‐ID and position. 

Each free text, photo or video has to be analysed by the Data Analysis Solution considering reliability 

characteristics. The analysis adds to the messages quantitative and qualitative attributes of reliability 

and keywords that distinguishes the incident type and the quantity of reports received, according to 

FRDAS01. 

 

 

 

32  

FRMBL05 – Data Recording Advising 

Description: The Mobile Crowdsourcing Solution has to inform the user about the start and end time 

of  data  recording,  and where  the  data  recording will  take  place.  The  user  can  accept  or  not  the 

automatic collection of information, according to FRMBL06. 

 

FRMBL06 – Automatic Data Recording 

Description:  The  Mobile  Crowdsourcing  Solution  has  to  collect  and  record  data  available 

automatically by the device of the users, as movement speed, movement direction, and altitude. 

 

Business Rules: Users must authorise their data recording, according to FRMBL05. 

 

FRMBL07 – Position Data Tracking 

Description:  If  the  position  sensor  is  available  in  the  user’s  device,  the  Mobile  Crowdsourcing 

Solution has to record the position, transfer  it to the RESCUER system and update this  information 

regularly, according to FRMBL05. 

 

FRMBL08 – Answer Follow‐up Structured Questions  

Description: The Mobile Crowdsourcing Solution has  to allow users  to answer  follow‐up questions received  from  the  Emergency  Response  Toolkit,  according  to  FRETK11.  There  are  pre‐defined answers associated with the corresponding questions.   Business Rules: The answer of these questions must return to the Command Centre.   

FRMBL09 – Answer Follow‐up Free Questions 

Description: The Mobile Crowdsourcing Solution has to provide the ability to answer follow‐up free 

text questions or coordination messages received  from the Emergency Response Toolkit, according 

to  FRETK11  and  FRETK24.  Coordination messages  are  associated  with  the  execution  of  tasks  or 

request for resources. 

 

Business Rules: A free text of these messages must return to the Command Centre.   

FRETK01 – User Registration 

Description: The Emergency Response Toolkit has to allow users to provide necessary information to 

access the system. 

 

FRETK02 – Report Support 

Description:  The  Emergency  Response  Toolkit  provides  the  ability  to  receive  SMS,  incident 

notification or incident reports previously filled with text, photos or videos. 

 

Business Rules: Each SMS, text, photo and video is previously analysed by the Data Analysis Solution 

considering relevance, reliability characteristics, and keywords, according to FRDAS01. 

 

 

 

33  

FRETK03 – Reports Filtering 

Description: The Emergency Response Toolkit has to provide filters to the reports. The user applies these filters according to their analyses needs. Some types of filters are:  

Reports by user profile;  

Reports with text message; 

Reports with photos; 

Reports with videos; 

Reports having analysed text message; 

Reports having analysed photos; 

Reports having analysed videos;  

Reports marked as important; 

Reports by keyword.  

FRETK04 – Report View 

Description: The Emergency Response Toolkit has  to provide an overview  for  the  report,  showing 

report identification, timestamp, send user profile, keyword, text, photos and videos. 

  

FRETK05 – Modify Report Characteristics 

Description:  The  Emergency  Response  Toolkit  should  allow  modifying  the  report  relevance  or 

reliability. 

 

FRETK06 – Reallocate Report 

Description: The Emergency Response Toolkit should permit to reallocate report from one  incident 

to another. 

 

FRETK07 – Highlight Important Report 

Description: The Emergency Response Toolkit allows highlight important reports. 

 

FRETK08 – Send Follow‐up Questions  

Description:  The Emergency Response  Toolkit has  to provide  the ability  to  send questions  to one 

person or a group‐target  in the crowd  in order to ask for additional  information about an  incident. 

This information is related to missing information, clarifying contradictory information, investigating 

potential problems and continuously evolving information. 

 Business Rules: The questions included in the message can be structured or free. The system should provide the ability to keep the list of structured questions to be chosen dynamically.  The questions could  be  selected  based  on  user  criteria  such  as:  profile,  role,  position,  movement,  previous interaction and affiliation.   The system can send follow‐up questions: 

To Civilians, only  if they have already  interacted with RESCUER and are  in safety areas and to know about their personal status only if they are not moving; 

 

 

34  

To  Supporting  Forces  on‐site,  to  obtain  missing  information  or  investigating  potential problems; 

To Workforces on‐site, to increase information reliability, obtain missing information, clarify contradictory information or investigate potential problems. 

  The following combinations should be provided: 

All Workforces / all Supporting Forces; 

Civilians, in a security area or injured, who provided reports; 

Workforces in a certain area.  

Besides these questions, the user can request for:  

Take Pictures/Record Videos;  

Inform People with Movement Difficulty.   

FRETK09 – Incident View 

Description: The Emergency Response Toolkit has to provide an overview for the  incident, showing 

timestamp, the quantity of reports, type of incident, keyword, dimension, severity and reliability. 

 

FRETK10 – Incidents Filtering 

Description:  The  Emergency  Response  Toolkit  has  to  provide  filters  to  show  the  incidents.  Filter types:  

Dimension 

Reliability  

Type of Incident 

Severity 

Timestamp  

FRETK11 – Merge Incidents 

Description: The Emergency Response Toolkit  should permit  to merge  two or more  incidents. The 

incidents will become only one. 

 

FRETK12 – Incident Map View  

Description: The Emergency Response Toolkit has to provide a map view of the incident area.   

FRETK13 – Emergency Map View  

Description: The Emergency Response Toolkit has to provide a map view with the incident, showing the Workforces location and crowd density.  Business  Rules:  The  Emergency  Response  Toolkit  should  permit  to  hide  and  show  the  different layers.  

   

 

 

35  

FRETK14 – Crowd Density and Movement Speed 

Description: The Emergency Response Toolkit has  to show/hide  the crowd density and movement speed on the map.  Business  Rules:  The Data Analysis  Solution  has  to  analyse  the  density  and  position  of  the  crowd periodically (e.g. every 20 second) and the Emergency Response Toolkit will use this  information to show the crowd density and movement speed.  

FRETK15 – Workforces/Supporting Forces Position  

Description:  The  Emergency  Response  Toolkit  has  to  show/hide  on  the  map  the placement/distribution in a certain area of the Workforces and Supporting Forces.  Business  Rules:  Concerning  the  Workforces,  it  ideally  should  provide  the  position  of  police, firefighters,  and  rescue  service.  Concerning  the  Supporting  Forces,  it  ideally  should  provide  the position of security staff, emergency staff, and volunteers.  

FRETK16 – Key Places View  

Description: The Emergency Response Toolkit has  to show/hide  layers on  the map. The  layers are 

used to show the key places. Examples of layer types:  

Large‐scale Events:  

o Public Clinics 

o Schools  

o Central Gas Station 

Industrial Parks 

o Gathering Points 

o Gas Pipe 

o Surrounding Communities  

o Gas Station 

Common to both Scenarios 

o Evacuation Routes 

o Approach Route 

o Safety & Security Areas 

o Factories with Hazard Material 

o Hospitals 

o Police Stations 

o Power Stations  

 

FRETK17 – Weather Information  

Description: The Emergency Response Toolkit has to provide  information about the weather on the map, including the wind direction and speed.    

FRETK18 – Emergency View  

Description:  The  Emergency  Response  Toolkit  has  to  provide  a  view  for  the  emergency,  several

(similar or different types of) incidents, reported in different positions and time may occur in an

 

 

36  

industrial area or Large-scale Event, and the option to visualize each one  individually. The following 

information must be provided per incident: 

Type (Fire, Explosion, Gas Leakage and Environmental) 

Location 

Starting Time 

Ending Time 

Altitude 

Injured People (Y/N) 

Status  

FRETK19 – Emergency Timeline  

Description: The Emergency Response Toolkit has  to provide a  timeline of  the emergency. As  the 

reports  related  to  a  specific  incident  come  to  the  command  centre,  a  timeline  is  created,  as 

illustrated in the example in Figure 7. 

 

 

Figure 7: Time line example 

FRETK20 – Send Task/Resource Request 

Description: The Emergency Response Toolkit has  to provide  the ability  to send  free or structured 

request to obtain resources or to execute a task. These requests are to one person or a group‐target 

(Workforces or Supporting Forces), on‐site or off‐site. The scope of this feature is set as "Maybe" in 

the Deliverable 1.4.2 [9] , and will be implemented only after confirmation of its importance. 

These are pre‐defined requests to execute task:  

Evacuate Incident Company  

Evacuate Industrial Park 

Evacuate Neighbourhood  

Block Roads  

Evaluate Environmental Damage  

These are pre‐defined requests to obtain resources:  

Need for Medical Support (intern) 

Need for Emergency Brigade (intern) 

Need for Helicopter (extern) 

Need for Firefighters (extern) 

Need for Security (extern: Police) 

 

 

37  

Need for Rescue Service (extern: Civil Defence) 

Need for Reinforcement from the Neighbour Companies 

 Business Rules: This requirement considers communications  from Command and Control Centre to 

internal or external stakeholders. Internals stakeholders (Workforces or Supporting Forces) are those 

directly  involved  in  the  incident:  on‐site  and  off‐site.  Externals  stakeholders  are  in  externals 

companies,  indirectly  involved  in  incident  like:  Civil  Defence,  Hospital,  and  others.  The  detailed 

description about communication with externals stakeholders will be provided  in the next  iteration 

Crowd Steering.   

 

FRETK21 – Emergency Summary 

Description: The Emergency Response Toolkit has to provide, periodically, within the start and end time of the emergency, an overview with the following emergency information:  

Number of Reports 

Number of Photos 

Number of Videos 

Number of Injured People  

Number of Deaths  Number of Incidents  Workforces Amount and Classified by Status  Tasks Amount and Classified by Status 

 

FRETK22 – Time Frame Specification 

Description: The Emergency Response Toolkit has to enable a time frame defining start and end time 

in which the system automatically collects data through the devices of the users. 

 

Business Rules: The starting and ending time must be informed by the Command and Control Centre 

and the Mobile Crowdsourcing Solution use this timeframe to start and end automatically recording 

the mobile information.  

 

FRETK23 – Draw Support 

Description: The Emergency Response Toolkit provides  the ability  to  free draw on  the Emergency Map View. The purpose is to allow the user to mark areas, point of interest and design route, in the map,  creating  layers  that  can  be  used  later.  This  design  should  be  labelled  to  be  retrieved  and displayed by the requirement FRETK16 – Key Places View. Examples of drawing routes types:  

Approach Routes 

Evacuation Routes  

FRDAS01 – Analysing Crowdsourcing Information  

Description:  The  Data  Analysis  Solution  has  to  assess  the  messages  (SMS,  text,  image,  video) received,  fusing  and  filtering,  considering  reliable  characteristics.  The  analysis  should  add  to  the messages quantitative and qualitative attributes of dimension, severity and reliability. The criteria for setting the dimension, severity and reliability model are still under research. 

 

 

38  

 Business Rules: The system must have the ability to filter the data coming from the crowd in order to show only high reliable information.   

5.2. Non‐Functional Requirements 

This section describes the non‐functional requirements identified for the RESCUER system, for 

all  iterations of  the project. More details are  found  in D5.1  [11]. Table 13  lists  those  requirements 

while the next subsections describe them and their business rules. 

Table 13: List of RESCUER functional requirements per iteration 

Code  Name Iterations 

1st   2nd(a)  2nd(b)  3rd 

NFRGNR01  Continuous Network Availability

NFRGNR02  Security 

NFRGNR03  Usability 

NFRGNR04  Scalability 

NFRGNR05  Extensibility 

NFRGNR06  Power Consumption 

NFRGNR07  Reliability 

NFRGNR08  Flexibility 

NFRGNR09  Portability 

NFRGNR10  Adaptability 

 

NFRGNR01 – Continuous Network Availability 

Description:  In case of  low or no network availability, the RESCUER system has to provide a way to transmit at least text. RESCUER will use an Ad‐hoc like approach for this goal.  

NFRGNR02 – Security 

Description: The RESCUER system should exchange messages via HTTPS.   

NFRGNR03 – Usability 

Description:  The  RESCUER  system  should  have  an  easy‐to‐use  user  interface  requiring  minimal 

interactions.  The  use  of  the  application  should  not  disturb  with  unnecessary  information  or  an 

overload. Users should  receive minimal  information, being  the  instructions  informative,  imperative 

and without  filler words.  The  guideline  for  user  interaction  is  detailed  at Deliverable  2.1.2  [7].  It 

explains the general recommendations for mobile users regarding simplicity, accuracy, instant usage, 

error tolerance and flexibility.  

 

NFRGNR04 – Scalability 

Description:  The  system  needs  to  be  scalable  regarding  the  number  of  running  and  especially communicating Mobile Crowdsourcing Solution.  In both  scenarios of  Large‐scale Events and  larger 

 

 

39  

Industrial areas, several thousand people may run the Mobile Crowdsourcing Solution of RESCUER. The  communication  network  as  well  as  the  server  system  should  be  able  to  handle  the  arising amount of data.  

NFRGNR05 – Extensibility 

Description:  In order  to  be  prepared  for  a  changing  environment  and  extension of  its  scope,  the RESCUER  system  should  be  designed  as  an  extensible  system  following  the  principle:  “close  for modifications open  for extension”  [4]. This holds  for software extensibility as well as  for hardware extensibility 

 

NFRGNR06 – Power Consumption 

Description: The Mobile Crowdsourcing Solution has to be designed  in such a way that the battery consumption is considered to ensure that the service will be available.   

NFRGNR07 – Reliability 

Description: The system needs to be reliable regarding to the information messages exchanged with 

the stakeholders.  

 

NFRGNR08 – Flexibility  

Description: The Mobile Crowdsourcing Solution has  to be designed  flexibly and has  to allow  that 

people  in  emergencies  provide  any  input  information with  no  restriction. Measures  for  achieving 

flexibility are described in D2.1.1 [7]. 

 

NFRGNR09 – Portability  

Description: The Mobile Crowdsourcing Solution should be able to run in all devices without knowing 

previously, which platform or operating system they are using, their screen size, or their hardware 

features. The Emergency Response Toolkit should also be able to run in different platforms, including 

small devices (e.g., notebook, tablet, smartphone) and big screen devices (e.g., tabletop).  

 

NFRGNR10 – Adaptability 

Description:  The  user  interface  in  the  Mobile  Crowdsourcing  Solution  and  in  the  Emergency 

Response Toolkit has  to be optimized  regarding users’ personal data. This means  the application’s 

interface  and  available  functions  adapt  to  the  user  preferences  and/or  current  situation.  For 

example, Civilians may have different functionalities than Workforces. The user interface has to show 

the  information  in the specified user  language  (using the device’s operational system  information). 

The adaptation may be applied  to user  interfaces, device’s characteristics, available  functionalities 

and provided information. 

 

 

40  

6. Use cases 

This chapter describes the use cases for the RESCUER system. As the requirements, the use cases 

describe  the  first and  second  iteration;  they have  to be valid and applicable  for devices, users, or 

organisations in the defined scenarios.  

Figure  8  shows  the  use  cases  diagram  and  the  interaction  between  the  actors  of  the Mobile 

Crowdsourcing Solution. The actor User represents: Workforces, Supporting Forces and Civilians. 

 

 

Figure 8: Use cases diagram – Mobile Crowdsourcing Solution 

 

 

 

41  

UCMBL01 ‐ User Registration 

Goal 

The goal of this use case  is to show which  information the user has to 

provide  to  the Mobile Crowdsourcing  Solution  for  the purpose of  the 

system  usage.  The  information  provided  will  be  associated  with  the 

user’s profile: Workforces, Supporting Forces and Civilians. 

Actor ‐ Workforces‐ Supporting Forces ‐ Civilians 

Pre‐Conditions  Mobile Crowdsourcing Solution installed on the user’s mobile device 

Input data  None 

Output data 

‐ Device‐ID  

‐ User profile 

‐ Depending on user profile: 

o Role 

o Community 

o Company 

 

UCMBL02 ‐ Send/Receive SMS 

Goal 

The goal of this use case is to allow the users involved in the incident to 

be  able  to  send/receive  information  as  text message  in  form  of  SMS 

to/from  the  command and  control  centre, even  if  they do not have a 

Smartphone or the Mobile Crowdsourcing Solution  installed or running 

in their Smartphone.  

Actor ‐ Workforces‐ Supporting Forces ‐ Civilians 

Pre‐Conditions ‐ Mobile telephone network coverage 

‐ User knows the number to reach the RESCUER system 

Input data  None 

Output data ‐ Text message 

‐ Device‐ID  

 

 

 

 

42  

UCMBL03 ‐ Send Incident Notification 

Goal 

The goal of  this use case  is  to allow  the users directly  involved  in  the 

incident  to  send  a  notification  identifying  the  type  of  incident  to  the 

command and control centre. The users should be able to choose what 

type of  incident  they want  to  report  (Fire, Explosion, Gas Leakage and 

Environmental). 

Actor ‐ Workforces‐ Supporting Forces ‐ Civilians 

Pre‐Conditions Mobile  Crowdsourcing  Solution  installed  on  device  and  network 

connection 

Input data  Kinds of incident  

Output data 

‐ Type of incident

‐ Device‐ID  

‐ User profile 

‐ Timestamp 

‐ Position (latitude, longitude) 

 

UCMBL04 ‐ Send Report 

Goal 

The goal of  this use case  is  to allow  the users directly  involved  in  the 

incident to send specific and structured information about the  incident 

to  the  command  and  control  centre.  They  should  be  able  to  choose 

what  type  of  incident  he  wants  to  report.  The  type  of  information 

depends  on  the  type  of  incident  (Fire,  Explosion,  Gas  Leakage  and 

Environmental).  The  user  can  add  free  text,  video  and  photos  to  the 

report. 

Actor ‐ Workforces ‐ Supporting Forces ‐ Civilians 

Pre‐Conditions  Mobile Crowdsourcing Solution installed on device 

Input data  Kinds of incident and pre‐defined questions  

Output data 

‐ Type of incident

‐ Device‐ID  

‐ User profile 

‐ Timestamp 

‐ Position (latitude, longitude) 

‐ Answers to the pre‐defined questions 

‐ Text message 

 

 

43  

‐ Videos 

‐ Photos 

 

UCMBL05 ‐ Answer Follow‐up Information 

Goal 

The goal of  this use case  is  to allow  the users directly  involved  in  the 

incident to answer follow‐up free or structured questions received from 

the command and control centre. 

Actor ‐ Workforces ‐ Supporting Forces ‐ Civilians 

Pre‐Conditions Mobile  Crowdsourcing  Solution  installed  on  device  and  follow‐up 

structured questions received 

Input data  ‐ Free or structured questions 

Output data 

‐ User profile 

‐ Type of incident 

‐ Device‐ID  

‐ Timestamp 

‐ Position (latitude, longitude) 

‐ Answers to the free or structured questions 

 

UCMBL06 ‐ Sensor Data Recording 

Goal 

The  goal  of  this  use  case  is  to  describe  the  automatic  recorded  data 

gathered  by  the  Mobile  Crowdsourcing  Solution.  This  data  is 

automatically  sent  to  the  RESCUER  system.  This  function  can  only  be 

active  in  the  period  defined  by  the  timeframe  and  with  the  user 

authorization.  

Actor  Crowdsourcing Solution Component 

Pre‐Conditions Mobile  Crowdsourcing  Solution  installed  on  device  and  running,  and 

timeframe specified. 

Input data ‐ Timeframe 

‐ User authorization (at the start of the recording) 

Output data 

‐ Device‐ID 

‐ Timestamp 

‐ Position (latitude, longitude) 

 

Figure 9 shows the use cases diagram and the interaction between the actors of the component 

Emergence Response Toolkit. The actor User represents the Command and Control Centre. 

 

 

44  

 

 

Figure 9: Use case diagram – Emergency Response Toolkit 

UCETK01‐ User Registration 

Goal The goal of this use case  is to show which  information the user has to 

provide to the ERTK for the purpose of use the system.  

Actor  Command and Control Centre

Pre‐Conditions  Emergency Response Toolkit installed 

Input data  None 

Output data 

‐ User id 

‐ Password 

‐ User information 

 

 

 

 

45  

UCETK02 – Define Timeframe  

Goal 

The goal of this use case is to allow the user to define when the Mobile 

Crowdsourcing Solution is allowed to record sensor data, this timeframe 

information  is  broadcasted  to  all  Mobile  Crowdsourcing  Solution 

installed on‐site and the mobile user has to authorize the record of the 

information.  

Actor  Command and Control Centre

Pre‐Conditions  Emergency Response Toolkit installed  

Input data  None 

Output data  Timeframe (start and end time) 

 

UCETK03 ‐ Display General Map 

Goal The  goal of  this use  case  describes  a  user  seeing  the  area where  the 

Large‐scale Event take place or the area of the Industrial Park.  

Actor  Command and Control Centre

Pre‐Conditions ‐ Emergency Response Toolkit installed  

‐ Map service must be active on the Internet 

Input data  None 

Output data  A map giving a picture of the general situation

 

UCETK04 ‐ Display Map Layers  

Goal The goal of this use case  is to allow the user to add  layers on the map 

view.  

Actor  Command and Control Centre

Pre‐Conditions ‐ Emergency Response Toolkit installed  

‐ Map service must be active on the Internet  

Input data 

List of layers: 

‐ Public Clinics 

‐ Schools  

‐ Central Gas Station 

‐ Gathering Points 

‐ Gas Pipe 

‐ Surrounding Communities  

‐ Gas Station 

‐ Hospitals 

‐ Evacuation Routes 

 

 

46  

‐ Approach Routes

‐ Police Stations 

‐ Power Stations 

Output data  Visualization of the layer requested. 

 

UCETK05 ‐ Display Weather Information 

Goal The goal of this use case is to show the current weather situation of the 

incident’s region in the map.  

Actor  Command and Control Centre

Pre‐Conditions ‐ Emergency Response Toolkit installed  

‐ The weather service must be active on the Internet 

Input data  None 

Output data ‐ Weather information 

‐ Wind direction and speed 

 

UCETK06 ‐ Ask Follow‐up Information 

Goal 

The  goal of  this use  case  is  to  allow  the user  sends questions  to one 

person  or  group,  to  confirm/receive  information  about  the  incident. 

This use case includes the follow‐up interaction between the Command 

Centre and the crowd. 

Actor  Command and Control Centre 

Pre‐Conditions  Emergency Response Toolkit installed

Input data 

‐ Type of incident 

‐ Device‐ID  

‐ User information (profile, role, community, company) 

‐ Timestamp 

‐ Position (latitude, longitude) 

‐ Pre‐defined questions answered 

‐ Text message 

‐ Videos 

‐ Photos 

Output data 

Additional questions about an  incident. These questions are related to 

missing  information,  contradictory  information,  investigation  of 

potential problem and continuously evolving information. 

 

 

 

47  

UCETK07 ‐ Display Emergency 

Goal The  goal  of  this  use  case  is  to  show  the  emergency  view  with 

information and its timeline. 

Actor  Command and Control Centre

Pre‐Conditions  Emergency Response Toolkit installed  

Input data  List of Emergencies 

Output data 

‐ Emergency‐ Location ‐ Starting Time ‐ Ending Time ‐ Altitude ‐ Injured People (Y/N) ‐ Timeline view ‐ Status 

 

UCETK08 ‐ Display Incident 

Goal The goal of this use case  is to show the  incident view with  information and  show  its  location  on  the map.  The  user  filters  the  incidents  by reliability or keyword and merges the incidents.  

Actor  Command and Control Centre 

Pre‐Conditions  Emergency Response Toolkit installed 

Input data  List of Incidents 

Output data 

‐ Incident 

‐ Timestamp 

‐ Quantity of reports 

‐ Keyword 

‐ Dimension 

‐ Severity  

‐ Reliability 

‐ Incident Map 

 

UCETK09 ‐ Display Report 

Goal 

The goal of this use case is to show the report view with information as: report  identification,  timestamp,  profile  of  the  user  who  sent  the report, keyword,  relevance,  reliability,  text message, photo and video. The  user  has  the  ability  to  modify  report  characteristics,  reallocate, highlight and hide  the  report.  In addition has also  the ability  to apply the following filters: 

 

 

48  

‐ Reports by user profile ‐ Reports with text message ‐ Reports with photos ‐ Reports with videos ‐ Reports having analysed text message ‐ Reports having analysed photos ‐ Reports having analysed videos  ‐ Reports marked as important ‐ Reports by keyword 

Actor  Command and Control Centre 

Pre‐Conditions  Emergency Response Toolkit installed  

Input data  List of reports 

Output data 

‐ Report identification 

‐ Timestamp 

‐ User profile  

‐ Keyword 

‐ Relevance 

‐ Reliability  

‐ Text message  

‐ Photo  

‐ Video 

 

UCETK10 ‐ Visualize Crowd Density and Movement Speed 

Goal The goal of  this use case  is to show the crowd density and movement 

speed on the map. 

Actor  Command and Control Centre

Pre‐Conditions  Emergency Response Toolkit installed  

Input data  None 

Output data ‐ Crowd Density

‐ Crowd Movement Speed 

 

   

 

 

49  

UCETK11 ‐ Coordinate Forces 

Goal 

The goal of  this use  case  is  to  send  free or  structured  request  to one 

person or a specific group, on‐site or off‐site, in order to get information 

about  resources  and  tasks,  ask  for  resources  or  ask  for  people  to 

perform tasks. 

Actor  Command and Control Centre

Pre‐Conditions  Emergency Response Toolkit installed  

Input data ‐ One person or specific group (on‐site or off‐site)  

‐ Structured request 

Output data ‐ One person or specific group selected  

‐ Structured request selected or free request 

 

UCETK12 – Draw on the Map 

Goal  The goal of this use case is to allow the user to draw on the map.  

Actor  Command and Control Centre

Pre‐Conditions ‐ Emergency Response Toolkit installed  

‐ Map service must be active on the Internet 

Input data  Draw and labels 

Output data  Visualization of the map with the drawing of the user. 

 

Appendix  A  contains  four  tables  that  show  the  traceability matrix  that  involves  the  RESCUER 

features (as described in deliverable D1.4.2 [9]), requirements and use cases. 

   

 

 

50  

References 

[1] COFIC  (2015).  Web  site  of  the  Camaçari  Industrial  Development  Committee.  In: 

http://www.coficpolo.com.br/2012/ing_index.php, Access: 01/2015. 

[2] COFIC.  (2014).  Activities  of  COFIC  Regarding  Health,  Safety  and  Environment.  In: 

http://www.coficpolo.com.br/2012/ing_interna.php?cod=63, Access: 01/2015. 

[3] EU Law (2012). Directive 2012/18/EU of the European Parliament and of the Council on the 

control  of  major‐accident  hazards  involving  dangerous  substances.  In:  http://eur‐

lex.europa.eu/legal‐content/EN/TXT/?uri=celex:32012L0018, Access: 01/2015. 

[4] MEYER,  B.  (1997).  Object  Oriented  Software  Construction.  Santa  Barbara,  USA:  Prentice 

Hall. 

[5] RESCUER (2013). Description of Work (Dow). Reliable and Smart Crowdsourcing Solution for 

Emergency and Crisis Management. 

[6] RESCUER (2014). Deliverable 1.1.1. Requirements Specification 1. 

[7] RESCUER  (2014).  Deliverable  2.1.1.  Conceptual  Model  of  Mobile  User  Interaction  in 

Emergencies 1. 

[8] RESCUER (2014). Deliverable 2.2.1. Crowdsourcing Information Gathering 1. 

[9] RESCUER (2015). Deliverable 1.4.2. Portability & Variation Management Strategy 2. 

[10] RESCUER  (2015).  Deliverable  4.1.2. Model  of Organizational  Behaviour  and  Structures  in 

Emergencies 2. 

[11] RESCUER (2015). Deliverable 5.1. Evaluation Model and General Evaluation Plan. 

[12] SSP‐Brazil  (2013).  Procedimento  Operacional  Padrão  (POP)  (in  Portuguese).  In: 

http://www.bombeiros.ms.gov.br/controle/ShowFile.php?id=178006, Access: 01/2015. 

[13] WANG,  L.,  YAQIN,  Y.  (2010).  Emergency  Risk  Evaluation  on  City  Bidding  for  Large‐Scale 

Sports Event, pp. 1‐6. 

[14] WIRZ, M., ROGGEN, D., TROSTER, G. (2010). User Acceptance Study of a Mobile System for 

Assistance  during  Emergency  Situations  at  Large‐Scale  Events. Human‐Centric  Computing 

(HumanCom), pp. 1‐6. 

 

 

   

 

 

51  

Glossary  

Terms 

Affected Community: People within the affected area of an incident that will most likely suffer from 

its impact.  

Command and Control Centre: Group of people assigned to evaluate risks and make decisions in an 

emergency and/or crisis in an Industrial area or at a Large‐scale Event.  

Crisis: the adverse and therefore undesired consequences of an emergency give rise to a crisis.  

Crowdsourcing:  In RESCUER, crowdsourcing  is described as  the  information gathering  from a  large 

number of people  involved  in an emergency situation, either explicitly  (e.g., through  form  filling or 

video/photos sending) or implicitly (by recording sensor data). 

Dispatcher:  Person working  in  a  command  and  control  centre  organising  the  operation  (but  not 

necessarily making decisions). 

Emergency Situation: Several (similar or different types of) incidents, reported in different positions 

and time, may occur in an industrial area or large‐scale event requiring the reaction of the command 

centre. In terms of the Emergency Response Toolkit, they belong to the same emergency situation.  

Emergencies: critical situations caused by  incidents, natural or man‐made that require measures to 

be  taken  immediately  to  reduce  their adverse  consequences  to  life and property  [5]. Examples of 

natural  incidents are  floods, wildfires, and snow storms, whereas examples of man‐made  incidents 

are fires, explosions and/or substance spills from oil platforms, ships, and factories. These and other 

man‐made incidents can also occur during large‐scale events, either by negligence or on purpose, as 

for  instance  in  the  case  of  a  terrorist  attack.  In  large‐scale  events,  the  risk  of  crowd‐inherent 

incidents,  like conflicts between opposing crowds  in football matches or mass panic,  is of particular 

concern.  

Event: Occurrence happening at a determined time and place, with or without the participation of 

human agents. It may be a part of a chain of occurrences, as an effect of a preceding occurrence and 

as the cause of a succeeding occurrence. 

Eyewitnesses: People in the place of the incident.  

First Responders: Members of the Workforces or volunteers that are sent to the place of the incident 

to control the emergency and restore safety conditions.  

Group‐target: can be dynamically composed by people belonging to any of the RESCUER profiles, in 

any combination as indicated by the Command and Control Centre. Below we list some examples:  

Group A: visitors that are 1 km away from the incident; 

Group B: people working on the incident area (Workforces + volunteers); 

Group C: people working on the incident area (Workforces only); 

Group D: visitors and employees leaving to exit A; 

Group E: All firelighters allocated to the incident (specific Workforces); 

Group F: Police working on the incident. Incident: Natural or man‐made occurrence  that  interrupts the normal procedure or behaviour  in a 

certain situation.  It may cause a critical or emergency situation that requires measures to be taken 

 

 

52  

immediately  to  reduce  adverse  consequences  to  life  and  property.  In  terms  of  the  Emergency 

Response Toolkit, a collection of reports that are closely related in terms of type of incident, position 

of incident and approximate time of occurrence will be considered as reports of the same incident.  

Production Plant: Building where products are created or processed. 

Timestamp: Information that includes current date and time. 

Workforces: Organisational  units  in  charge  of  security  and  safety  in  the  area where  the  incident 

occurred, e.g. police, fire fighters, and rescue forces.  

   

 

 

53  

Abbreviations 

CETREL ‐ Industrial Maintenance and Environmental Protection 

C&CC ‐ Command and Control Centre 

CIP ‐ Camaçari Industrial Park 

COM – Communication Infrastructure 

CPL ‐ Chemical Park of Linz 

DAS – Data Analysis Solution 

DoW ‐ Description of Work 

EC ‐ European Commission 

ERTK ‐ Emergency Response Toolkit 

MBL ‐ Mobile Crowdsourcing Solution 

PAM ‐ Mutual Aid Plan 

RESCUER ‐ Reliable and Smart Crowdsourcing Solution for Emergency and Crisis Management 

SESGE ‐ Special Department for Large Events Security 

 

 

 

54  

Appendix A 

Table 14: Mobile Crowdsourcing Solution ‐ functional requirements X use cases 

         Use Cases ‐ Mobile Crowdsourcing Solution  Iteration 

   UCMBL01 ‐ User Registration 

UCMBL02 ‐ Send/Receive SMS 

UCMBL03 ‐ Send Incident Notification 

UCMBL04 ‐ Send Report 

UCMBL05 ‐ Answer Follow‐up Information 

UCMBL06 ‐ Sensor Data Recording 

1st 2nd  3rd

  

Follow‐up 

Coordinatio

n 

Functio

nal R

equirem

ents 

FRMBL 

01 ‐ User Registration   X                 X          

02 ‐ SMS Support     X              X          

03 ‐ Incident Notification Support        X           X          

04 ‐ Report Support           X        X          

05 ‐ Data Recording Advising                 X  X          

06 ‐ Automatic Data Recording                 X  X          

07 ‐ Position Data Tracking                 X  X          

08 ‐ Answer Follow‐up Structured Questions  

            X        X       

09 ‐ Answer Follow‐up Free Questions 

            X           X    

FRDAS

01 ‐ Analysing Crowdsourcing Information  

   X     X        X  X  X    

 

 

 

55  

Table 15: Emergency Response Toolkit ‐ functional requirements X use cases 

         Use Cases ‐ Emergency Response Toolkit  Iteration 

     

UCETK

01 ‐ U

ser 

Registratio

n 

UCETK

02 ‐ D

efine 

Timefram

e 

UCETK

03 ‐ D

isplay 

Gen

eral Map

 

UCETK

04 ‐ D

isplay 

Map

 Layers 

UCETK

05 ‐ D

isplay 

Weath

er 

Inform

ation 

UCETK

06 ‐ A

sk 

Follow‐up 

Inform

ation 

UCETK

07 ‐ D

isplay 

Emergen

cy 

UCETK

08 ‐ D

isplay 

Incid

ent 

UCETK

09 ‐ D

isplay 

Rep

ort 

UCETK

10 ‐ V

isualize

 

Crowd Den

sity and 

Movem

ent Sp

eed 

UCETK

11 ‐ 

Coordinate

 Forces 

UCETK

12 ‐ D

raw on 

the M

ap 

1st2nd 

3rd

        

Follow‐up 

Coordinatio

n 

Functio

nal R

equirem

ents 

FRETK

 

01 ‐ User Registration  X                                      X  X    

02 ‐ Report Support                          X           X  X  X    

03 ‐ Reports Filtering                          X              X  X    

      

04 ‐ Report View                          X              X  X    

05 ‐ Modify Report Characteristics                          X              X       

06 ‐ Reallocate Report                          X              X       

07 ‐ Highlight Important Report                          X              X       

08 ‐ Send Follow‐up Questions                  X                       X       

09 ‐ Incident View                       X                 X  X    

10 ‐ Incidents Filtering                       X                 X  X    

11 ‐ Merge Incidents                       X                 X  X    

12 ‐ Incident Map View                        X                 X  X    

13 ‐ Emergency Map View         X                                X  X    

14 ‐ Crowd Density and Movement Speed                             X           X  X    

15 ‐ Operational Forces Position         X                                X  X    

 

 

56  

         Use Cases ‐ Emergency Response Toolkit  Iteration 

     

UCETK

01 ‐ U

ser 

Registratio

n 

UCETK

02 ‐ D

efin

e 

Timefram

e 

UCETK

03 ‐ D

isplay 

Gen

eral Map

 

UCETK

04 ‐ D

isplay 

Map

 Layers 

UCETK

05 ‐ D

isplay 

Weath

er 

Inform

ation 

UCETK

06 ‐ A

sk 

Follow‐up 

Inform

ation 

UCETK

07 ‐ D

isplay 

Emerge

ncy 

UCETK

08 ‐ D

isplay 

Incid

ent 

UCETK

09 ‐ D

isplay 

Rep

ort 

UCETK

10 ‐ V

isualize 

Crowd Den

sity and 

Movem

ent Sp

eed 

UCETK

11 ‐ 

Coordinate Fo

rces 

UCETK

12 ‐ D

raw on 

the M

ap 

1st2nd 

3rd

        

Follow‐up 

Coordinatio

n 

16 ‐ Key Places View             X                             X  X    

17 ‐ Weather Information              X                       X          

18 ‐ Emergency View                     X                    X  X    

19 ‐ Emergency Timeline                     X                       X    

20 ‐ Send Coordination Requirements                                 X           X    

21 ‐ Emergency Summary                    X                    X  X    

22 ‐ Time Frame Specification     X                                X          

23 ‐ Draw Support                                   X             

FRDAS

01 ‐ Analysing Crowdsourcing Information                           X           X  X  X    

 

 

 

 

 

 

 

 

 

57  

Table 16: Features (first iteration) X requirements 

        

SF1 M

onito

ring o

f crowd 

beh

aviour 

SF2.1 Sen

sor D

ata Gath

ering: 

Positio

n 

SF2.2 Sen

sor D

ata Gath

ering: 

Movem

ent Sp

eed

SF2.3 Sen

sor D

ata Gath

ering: 

Movem

ent D

irection

SF2.4 Sen

sor D

ata Gath

ering: 

Altitu

de 

SF5.1 Very q

uick in

ciden

t 

notificatio

n 

SF5.2 Incid

ent n

otificatio

n via 

SMS  

SF6.1.1 Incid

ent rep

ort: C

rowd 

SF6.1.2 Incid

ent rep

ort: Exp

ert 

SF6.2.1 Incid

ent rep

ort: G

as leakage 

SF6.2.2 Incid

ent  rep

ort: 

Explosio

n/Fire 

SF6.2.5 Incid

ent rep

ort: 

Enviro

nmen

t 

SF7 M

ultim

edia attach

men

t 

SF13.1 Crisis m

apping: In

ciden

t locatio

n 

SF13.2 Crisis m

apping: P

laces of 

concern

 

SF13.3 Crisis m

apping: Safety &

 secu

rity areas 

SF13.4 Crisis m

apping: C

rowd 

beh

aviour 

SF13.5 Crisis m

apping: 

Crowdsourcin

g inform

ation 

SF14.4 User registratio

n: C

rowd

        

Functio

nal R

equirem

ents 

FRMBL 

01 ‐ User Registration                                                         X 

02 ‐ SMS Support                     X                                     

03 ‐ Incident Notification Support  

               X                                        

04 ‐ Report Support                        X  X  X  X  X  X                   

05 ‐ Data Recording Advising 

   X  X  X  X                                           

06 ‐ Automatic Data Recording  X     X  X  X                                           

07 ‐Position Data Tracking     X                                                    

 

 

58  

        

SF1 M

onito

ring o

f crowd 

beh

aviour 

SF2.1 Sen

sor D

ata Gath

ering: 

Positio

n 

SF2.2 Sen

sor D

ata Gath

ering: 

Movem

ent Sp

eed 

SF2.3 Sen

sor D

ata Gath

ering: 

Movem

ent D

irection 

SF2.4 Sen

sor D

ata Gath

ering: 

Altitu

de 

SF5.1 Very q

uick in

ciden

t 

notificatio

n 

SF5.2 Incid

ent n

otificatio

n via 

SMS  

SF6.1.1 Incid

ent rep

ort: C

rowd 

SF6.1.2 Incid

ent rep

ort: Exp

ert 

SF6.2.1 Incid

ent re

port: G

as leakage 

SF6.2.2 Incid

ent rep

ort: 

Explosio

n/Fire 

SF6.2.5 Incid

ent rep

ort: 

Enviro

nmen

t 

SF7 M

ultim

edia attach

men

t 

SF13.1 Crisis m

apping: In

cident 

locatio

n 

SF13.2 Crisis m

apping: P

laces of 

concern

 

SF13.3 Crisis m

apping: Safety &

 security areas 

SF13.4 Crisis m

apping: C

rowd 

beh

aviour 

SF13.5 Crisis m

apping: 

Crowdsourcin

g inform

ation 

SF14.4 User registratio

n: C

rowd

        

FRETK

 

02 ‐ Report Support                 X  X  X  X  X  X  X  X                   

04 ‐ Report View                                                     X    

09 ‐ Incident View                                                      X    

12 ‐ Incident Map View  X                                      X                

13 ‐ Emergency Map View  X                                      X        X       

14 ‐ Crowd Density and Movement Speed  X                                               X       

16 ‐ Key Places View                                             X  X          

18 ‐ Emergency View                                          X                

 

 

59  

Table 17: Features (second iteration) X requirements 

         SF13.6

 Crisis M

apping: Free 

draw

ing 

SF16.1.1

 Follow‐up 

Interactio

n: C

ivilians 

SF16.1.2

 Follow‐up 

Interactio

n: Su

pportin

g Forces 

on‐site 

SF16.1.3

 Follow‐up 

Interactio

n: W

orkfo

rces on‐

site

SF17.1 Em

ergency m

apping: 

Placem

ent o

f Workfo

rces 

SF17.2 Em

ergency m

apping: 

Placem

ent o

f Supportin

g 

Forces

SF17.3 Em

ergency m

apping: 

Evacuatio

n an

d Approach

 

Routes

SF20 Em

ergency d

ashboard

: 

Classificatio

n of severity 

SF23 Human

 resource 

managem

ent 

SF24 M

aterial & equipmen

t 

managem

ent 

SF31 Ad‐hoc co

mmunicatio

n

        

Functio

nal  

FRMBL 

08 ‐ Receive and Answer Follow‐up Structured Questions  

   X  X  X                      

09 ‐ Receive and Answer Follow‐up Free Questions 

   X  X  X                      

FRETK

 

08 ‐ Send Follow‐up Questions      X  X  X                      

15 ‐ WorkForces/Supporting Forces Position               X  X                

16 ‐ Key Places View                   X             

 

 

60  

         SF13.6

 Crisis M

apping: Free 

draw

ing 

SF16.1.1

 Follow‐up 

Interactio

n: C

ivilians 

SF16.1.2

 Follow‐up 

Interactio

n: Su

pportin

g Forces 

on‐site 

SF16.1.3

 Follow‐up 

Interactio

n: W

orkfo

rces on‐

site

SF17.1 Em

ergency m

apping: 

Placem

ent o

f Workfo

rces 

SF17.2 Em

ergency m

apping: 

Placem

ent o

f Supportin

g 

Forces

SF17.3 Em

ergency m

apping: 

Evacuatio

n an

d Approach

 

Routes

SF20 Em

ergency d

ashboard

: 

Classificatio

n of severity 

SF23 Human

 resource 

managem

ent 

SF24 M

aterial & equipmen

t 

managem

ent 

SF31 Ad‐hoc co

mmunicatio

n

        

18 ‐ Emergency View                       X          

20 ‐ Send Coordination Requirements                           X  X    

23 ‐ Draw Support  X                               

Non‐Fu

nctio

nal 

NFRGNR 

01 ‐ Continuous Network Availability 

                              X