d7.1 beaware technological roadmap 2017-6-30 v1.0 · Page 1 beAWARE Enhancing decision support and management services in extreme weather climate events 700475 D7.1 Technological

Page1

beAWAREEnhancingdecisionsupportandmanagementservicesinextremeweatherclimate

events

700475

D7.1TechnologicalRoadmap

Disseminationlevel: Public

Contractualdateofdelivery: Month6,30June2017

Actualdateofdelivery: Month6,30June2017

Workpackage: WP7Systemdevelopment,integrationandevaluation

Task: T7.1SystemRequirementsandArchitecture

Type: Report

ApprovalStatus: FinalDraft

Version: 1.0

Numberofpages: 52

Filename: d7.1_beaware_technological_roadmap_2017-6-

30_v1.0.docx

Abstract

Theobjectiveofthisdocumentistodefinetheoutlineofthetimeplanforthedevelopment

ofthebeAWAREplatform.Inthiscontext,thedeliverableprovidesahighlevelviewofthe

beAWAREplatformarchitectureandaspecificationoftheinfrastructurelayout.Inaddition

the deliverable includes an initial functional description of each of the technicalmodules,

describing the supporting technologies, the increasing functionalities over time and the

development timeline. Finally, the deliverable includes a summary of the use cases and a

global project timeline, describing the platform’s scheduled iterations and the levels of

functionalityattheprojectmilestones.

The information in thisdocumentreflectsonly theauthor’sviewsandtheEuropeanCommunity isnot liable foranyuse

that may be made of the information contained therein. The information in this document is provided as is and no

guaranteeorwarrantyisgiventhattheinformationisfitforanyparticularpurpose.Theuserthereofusestheinformation

Ref. Ares(2017)3305579 - 30/06/2017

Page2

atitssoleriskandliability.

Co-fundedbytheEuropeanUnion

D7.1–V1.0

This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475

History

Version Date Reason Revisedby0.1 05.06.2017 Deliverablestructure Allpartners

0.2 22.06.2017 Contributionsbyallpartners Allpartners

0.3 23.06.2017 Integrateddocument CERTH

0.4 24.06.2017 Internalreviewofthedocument B.Mandler(IBM)

1.0 30.06.2017 Finalversion CERTH

Authorlist

Organisation Name ContactInformationCERTH YiannisKompatsiaris [email protected]

CERTH AnastasiosKarakostas [email protected]

CERTH KonstantinosAvgerinakis [email protected]

CERTH EfstratiosKontopoulos [email protected]

IBM BenjaminMandler [email protected]

IBM EvgeniyHvostenko [email protected]

MSIL IsraelAltar [email protected]

MSIL YanivMordecai [email protected]

IOSB HylkevanderSchaaf [email protected]

UPF StamatiaDasiopoulou [email protected]

UPF JensGrivolla [email protected]

UPF GerardCasamayor [email protected]

UPF SimonMille [email protected]

UPF LeoWanner [email protected]

AAWA DanieleNorbiato [email protected]

AAWA MichelleFerri [email protected]

PLV CarmenCastro [email protected]

HRT IosifVourvachis [email protected]

FBBR AmalieJanniche [email protected]

D7.1–V1.0


ExecutiveSummary

This deliverable presents the technological roadmap towards the implementation of the

beAWAREplatform.

First, this roadmap presents a high-level view of the envisioned architecture for the

beAWARE platform, illustrating the conceptual architecture and a draft of the complete

technical architecture. Then, the deliverable describes themodules that are developed in

eachWork Package and comprise the beAWARE platform. For eachmodule, a functional

description is provided including a summary of its scientific and technical objectives and

supportingtechnologies,input/outputspecifications,theincreasingfunctionalityovertime,

the development timeline, as well as the detailing schedule and resource allocation. In

addition, D7.1 provides a summarised vision of the proposed use cases and their

implementation strategy. Finally, a global project timeline is presented, describing the

platform’sschedulediterationsandthelevelsoffunctionalityattheprojectmilestones.

D7.1–V1.0


AbbreviationsandAcronyms

ASR Automaticspeechrecognition

CCTV CloseCircuitTV

DTr Dynamictexturerecognition

GIS GeographicalInformationSystem

HTTP HypertextTransferProtocol

JSON JavaScriptObjectNotation

KB KnowledgeBase

ObjD Objectdetection

OWL WebOntologyLanguage

PSAP Public-safetyansweringpoint

RDF ResourceDescriptionFramework

REST RepresentationalStateTransfer

STL Spatio-temporallocalization

TLc Trafficlevelclassification

UC UseCase

WP WorkPackage

XML ExtensibleMark-upLanguage

D7.1–V1.0


TableofContents

1 INTRODUCTION......................................................ERROR!BOOKMARKNOTDEFINED.

2 ARCHITECTURE.........................................................................................................10

2.1 Description...........................................................................................................112.1.1 Platformcomponents..........................................................................................................11

2.2 Technologystack...................................................................................................122.2.1 Programminglanguages......................................................................................................13

2.2.2 Databases/Repositories.......................................................................................................13

2.2.3 Othertechnologies..............................................................................................................13

2.2.4 Exchangeformats................................................................................................................14

3 FUNCTIONALDESCRIPTIONOFMODULES...............ERROR!BOOKMARKNOTDEFINED.

3.1 Earlywarninggeneration(WP3)............................................................................153.1.1 Crisisclassificationmodule..................................................................................................15

3.1.2 Conceptandconceptualrelationextractionfromtextualinformationmodule.................15

3.1.3 Conceptandeventdetectionfrommultimediamodule.....................................................16

3.1.4 AutomaticSpeechRecognition(ASR)module.....................................................................18

3.1.5 Activitytableandworkload.................................................................................................19

3.1.6 Timelineanddependencyfromothermodules...................................................................21

3.2 Aggregationandsemanticintegrationofemergencyinformationfordecisionsupportandearlywarningsgeneration(WP4)..................................................................22

3.2.1 SocialMediaMonitoringmodule.........................................................................................22

3.2.2 MonitoringmachinesourcinginformationfromIoTandM2Mplatformsmodule.............24

3.2.3 Semanticrepresentationandreasoningmodule.................................................................25



3.3 Multilingualreportgeneration(WP5)...................................................................303.3.1 Textplanningmodule..........................................................................................................30

3.3.2 Multilinguallinguisticgenerationmodule...........................................................................30



3.4 MainPublicSafetyAnsweringPointforemergencymultimediaenrichedcalls(WP6) 33

3.4.1 PSAPcapabilities..................................................................................................................33



3.5 Systemdevelopment,integrationandevaluation(WP7).......................................393.5.1 Twelve-FactorApplications..................................................................................................39

3.5.2 Systemarchitecture.............................................................................................................40

3.5.3 Technicalinfrastructure.......................................................................................................41

D7.1–V1.0


3.5.4 Systemdevelopment...........................................................................................................41

3.5.5 Communicationbus.............................................................................................................42

3.5.6 End-usersapplications.........................................................................................................43


3.5.8 Timelineanddependenciesfromothermodules................................................................45

4 DEVELOPMENTCYCLEANDUSECASES......................................................................46

4.1 Scenario1:Flood...................................................................................................46

4.2 Scenario2:Fires....................................................................................................47

4.3 Scenario3:Heatwave............................................................................................48

5 PROJECTTIMELINEANDMILESTONES.......................................................................51

6 SUMMARY................................................................................................................52

ListofFiguresFigure1:Architecturalhigh-levelview....................................................................................10

Figure2:AllocationofTwitterpoststoitsproperdatacollection..........................................22

Figure3:Interfaceforclassifyingpostsasrelevant/irrelevant...............................................23

Figure4:beAWAREontologynetwork....................................................................................25

Figure5:PSAPTechnologicalArchitecture.............................................................................33

Figure6:beAWAREwalkingskeleton......................................................................................51

ListofTablesTable1:Programminglanguages............................................................................................13

Table2:Databaseandrepositorypackages............................................................................13

Table3:Othertechnologies....................................................................................................14

Table4:Crisisclassificationmodulesummary........................................................................15

Table5:Conceptextractioncomponentsummary.................................................................16

Table6:Relationextractioncomponentsummary.................................................................16

Table7:Dynamictexturerecognitioncomponentsummary..................................................17

Table8:Objectdetectioninvideoframesandimagescomponentsummary........................17

Table9:Trafficlevelclassificationcomponentsummary.......................................................18

Table 10: Spatio-temporal localization of fire, smoke and flood incidents component

summary.................................................................................................................................18

Table11:Automaticspeechrecognitionmodulesummary...................................................19

D7.1–V1.0


Table12:WP3activitytable....................................................................................................20

Table13:WP3timeline...........................................................................................................21

Table14:Socialmediamonitoringmodulesummary.............................................................24

Table 15:Monitoringmachine sourcing information from IoT andM2Mplatformsmodule

summary.................................................................................................................................25

Table16:SemanticKBcomponentsummary..........................................................................26

Table17:KBservicecomponentsummary.............................................................................27

Table18:Semanticreasoningcomponentsummary..............................................................27



Table21:Textplanningmodulesummary..............................................................................30

Table22:Multilinguallinguisticgenerationmodulesummary...............................................31



Table25:Pre-EmergencyDecision-SupportingRiskVisualizationsummary..........................34

Table26:EmergencyIncidentCollectionandDisplaysummary.............................................34

Table27:FirstResponderPositionCollectionandDisplaysummary.....................................35

Table28:IncidentAssignmenttoFirstRespondersummary..................................................35

Table29:PublicAlertsummary..............................................................................................35

Table30:IncidentManagementsummary.............................................................................36



Table33:Architecturedefinitionsummary............................................................................41

Table34:Infrastructuredefinitionsummary..........................................................................41

Table35:Systemdevelopmentsummary...............................................................................42

Table36:Communicationbussummary.................................................................................42

Table37:End-usersapplicationssummary.............................................................................43



D7.1–V1.0


1 Introduction

ThisdocumentpresentsaroadmapofhowtheConsortiumplanstodevelopthebeAWARE

platform. The objective of the deliverable is to specify in detail: (i) the progressively

increasingfunctionality(inparticularatthetimepointsofthemilestones)oftheindividual

modules as well as of the platform as a whole, (ii) the temporal and functional

synchronisationoftheindividualmodulestoensurethisfunctionality;(iii)theresourcesthat

willbeneededtoachievethisfunctionality;(iv)thetechnicalinfrastructurespecifications.

Tothisend,andbasedonamodelofiterativedevelopment,theroadmapincludes:

1. Ahigh-levelviewoftheenvisionedPlatformarchitecture,illustratingtheconceptual

architectureandadraftofthecompletetechnicalarchitecture.Aspecificationofthe

infrastructurelayoutandtopologyisalsoprovided.

2. Afunctionaldescriptionofeachofthetechnicalmodules,describing:

a. A summary of its scientific and technical objectives, and supporting

technologies;

b. Itsprogressivelyincreasingfunctionalityovertime;

c. Itstimeline,detailingscheduleandresourceallocation;

3. Asummarisedvisionoftheproposedusecasesandtheirimplementationstrategy;

4. A global project timeline, describing the platform’s scheduled iterations and the

levelsoffunctionalityattheprojectmilestones;

Therefore, this deliverable is structured as follows. Section 2 presents the architecture.

Section3providesthefunctionaldescriptionofthemodulesinvolvedinalignmentwiththe

project Work Packages (WPs). Section 4 presents the development cycle and briefly

discusses the use cases. Finally, Section 5 provides the overall project timeline and the

milestones,whileSection6concludesthedeliverable.

D7.1–V1.0


2 Architecture

The forming architecture is formulated with the ultimate goal of providing accuracy and

functionality for decision support systems to be able to respondwell to weather related

disasterscenarios.

Thearchitectureisroughlymadeupofthefollowinglayers:

1. Ingestionlayer,containingmechanismsandchannelsthroughwhichdataisbrought

intotheplatform;

2. Internal services, genericdata repositoriesandcommunicationservicesbeingused

bythedifferentcomponents;

3. Businesslayer,containingthecomponentsthatperformtheactualplatform-specific

capabilities;

4. External facing layer, including the end-users’ applications and PSAP (Public-safetyansweringpoint)modules,interactingwithpeopleandentitiesoutsidetheplatform

(end-usersoftheplatform).

Figure1:Architecturalhigh-levelview

D7.1–V1.0


2.1 DescriptionAscanbederivedfromFigure1,thefirststepinagenericflowoftheplatformconsistsof

new data being pushed into the platform. The new data can originate from specific

beAWARE applications used by civilians (end-users) or first responders. Note that these

applicationsmay be bi-directional as they can serve to communicate backwith the users

uponneed.Moreover, incomingdata to theplatformcanoriginate fromother sources as

well,suchasIoTdevices,socialmediapotsgrabbedbycrawlers,andweatherdata,toname

afew.

Once a newpieceof data is successfully ingested into the system, thedata is stored in a

temporaryrawdatastoreandtheavailabilityofthenewpieceofdataisbroadcastedtoall

interested components using a specific topic of the messaging service. There shall be a

separate topic for each kind of information flowing into the system, such that only

componentswhich are interested in that specific kind of datawill bemade aware of the

arrivalofanewrelevantpieceofdata.

All interested parties will receive the information, which includes a pointer enabling to

access the data, and shall perform their specific analysis on the newdata.Note, that the

resultofsuchananalysismayinturncreateanewpieceofdatawhichisofinteresttoother

components,thatonceagainwillbemadeawareandaccessthedatainthesamemanner

explainedabove,providingservicesforcrisisclassificationandearlywarning.

The final results of the analysis canbe added to the knowledgebase, and if requiredwill

notifyPSAPrelatedcomponentsoftheidentificationofanewstate.

ThePSAP in turnmayusebeAWAREcomponents, includingapps tomanageandalert the

differentstakeholders(citizens,firstresponders,andauthorities).

2.1.1 Platformcomponents

Ingestion layer – Serves as the input mechanism into the platform. Different kinds of

informationcanserveasinputtothesystem.Forexample,IoTdevicesandadditionalinput

mechanisms, such as dedicated applications, can produce different kinds of data such as

measurements (time series), pictures, videos, audio, and more. An additional source of

incominginformationisweatherrelateddata.Typically,onceanewpieceofdatahasbeen

ingested into theplatform, it is stored temporarily in a raw storage system, andaproper

notificationissentviatheservicebustotheinterestedparties.

Internal services – These services are used internally for the proper functioning of thecapabilities provided by the various components. These services are usedmostly for data

storage and communication. Some generic data analytics and processing servicesmay be

used as well. Examples of this layer include a central (raw) data repository, a central

messagebus,andagenericknowledgebase.Theseserviceswillbeaccessibletoallplatform

components.

Businesslayer–This layerencompassesthecomponentsthatperformtheactualplatform

specificcapabilities.Thebulkoftheplatformisconcentratedatthislayer,whichinteractsin

turnwithalladditionallayers.Aparticulargroupofcomponentsinthislayertacklestheanalysisofdifferentkindsofdata

flowingintotheplatform.Amainaspectofthecomponentsinthiscategoryisextractionof

D7.1–V1.0


semanticdata flowing into theplatform fromvariousdifferent sources.Among this group

wecanfindthefollowingcomponents:

• SocialMediaAnalysisServices

• Imageanalysis

• Videoanalysis

• Multimediaanalysis

• Automaticspeechrecognition

• Sensoranalysis

These components help to determine the crisis classification and drive the detection of

eventswhichleadsinturntomeaningfuldecisionsupport.

Asecondgroupofcomponentsdealmorespecificallywiththeanalysisofweather-related

data.Amongthesecomponentsare:

• ClimateEmergencyModelingandPredictionServices

• WeatherForecastServices

• FloodPredictionServices

Bothsub-categorieslistedabovecontributetotheproperwarninggenerationcapabilitiesof

theplatform,includingmeasuresofcrisisclassification.

A third groupof related components dealmostlywith text, both at the input andoutput

aspects.Namely, incomingtextmessages,possibly inavarietyof languages,areprocessed

and analyzed, and outgoing textmessages that need to be delivered by the platform are

prepared:

• MultilingualReportGenerator

• MultilingualTextAnalyzer

External layer – This layer handles the interaction of the platformwith external entities,

bothas inputprovidersandoutput recipients. Thereare twomaingroupsof components

makingupthislayer,namely:

• Mobileapplications

o CiviliansMobileApplication

o FirstResponderMobileApplication

• Controlcenters

o PublicSafetyAnsweringPoint(PSAP)

o ValenciaLocalPoliceControlCenter

The REST architectural pattern will be used to model the services used by the different

services. REST proposes a very lightweight, HTTP-based method of stateless operations

betweenresourcesintheWeb.

2.2 TechnologystackIn order to keep the architecture coherent and manageable, and simplify hosting and

maintenance, a controlled set of technologies will be used to implement the shared

componentsoftheplatform.

D7.1–V1.0


As a general principle, open source technologies will be used to implement the platform

(“opensource”definedassoftwarelicensedunderanOSI1-approvedlicensethatisincluded

in the list of EUPL-compatible licenses2). Exceptions will be proprietary or non EUPL-

compatible licenses for software belonging to a partner in the beAWARE consortium, or

specificproducts,wherenoEUPL-compatiblealternativesexist.

2.2.1 Programminglanguages

A preliminary list of the selected programming languages for module implementation is

providedinTable1.

Language/framework Versions

allowed

Notes

Python 2.7 Forcomponentdevelopment

Java JSE7,JSE8,JEE7 Forcomponentdevelopment

C/C++ ANSI-C99/ISO

C++

Forcomponentdevelopment

R 3.2 Forcomponentdevelopment

JavaScript Any Node.js0.10.x

Table1:Programminglanguages

2.2.2 Databases/Repositories

Apreliminarylistofselecteddatabase/storagesolutionsisprovidedinTable2.

Datastore Versions

allowed

Notes

GraphDB 8.1 RDFrepository–accessviaSPARQLandHTTP

MongoDB 3.4.2 Socialmediaandmultimediastorage

PostgreSQL 9.x RelationalDB(Time-seriessensordataandmetadata)

ObjectStorage - IBM®ObjectStorageforBluemix(rawdatastore)

Table2:Databaseandrepositorypackages

2.2.3 Othertechnologies

A preliminary list of miscellaneous technological packages (application servers, special

purposestacks,etc.)isprovidedinTable3.

Product Versions

allowed

Notes

Kafka 0.8.x Messagingservice

1 Open Source Initiative, see http://opensource.org/. 2 See https://joinup.ec.europa.eu/software/page/eupl/eupl-compatible-open-source-licences for complete list of EUPL-compatible open source licences.

D7.1–V1.0


(MessageHub)

Jetty 9.x J2EEapplicationserver(preferred)

Tomcat 7.x J2EEapplicationserver

Node.js 0.10+ JavaScriptapplicationserver

ApacheJena 3.x SemanticWebframeworkforJava

Table3:Othertechnologies

2.2.4 Exchangeformats

The preferred exchange format for structured datawill be JSON3.UTF-8 encodingwill be

usedinordertoensurecorrectandconsistenthandlingofmultilingualcontent.

For semantic data representation and serialisation, theOWL2/XML format4 will be used.

JSON-LD5willbeusedwhereappropriatetorepresentLinkedData.

Finally,forannotationsofmultimediacontent,theMPEG-7standard6willbeused.

3 http://json.org/ 4 https://www.w3.org/TR/owl2-xml-serialization/ 5 http://json-ld.org/ 6 http://mpeg.chiariglione.org/standards/mpeg-7

D7.1–V1.0


3 FunctionalDescriptionofModules

3.1 Earlywarninggeneration(WP3)WP3 addresses the provision of the necessary technological solutions that will allow the

beAWARE framework to provide early warning and decision support to the PSAP. This is

accomplished through: i) the crisis classification module, ii) the module that deals with

concept and conceptual relation extraction from textual information, iii) the multimedia

concept/eventdetectionmodule,andiv)theautomaticspeechrecognition(ASR)module.

3.1.1 Crisisclassificationmodule

ThebeAWAREcrisisclassificationmoduledealswith the identificationandclassificationof

crisis events, based on 1) weather forecasting data (provided by FMI), 2) data from

heterogeneoussources(e.g.photos,writtentext,socialmedia,etc.)and3)rulesthatwillbe

definedwith the help and guidance of user experts. Themodule serves as a two-layered

crisisclassificationsystem(firstlayer:earlywarningofupcomingcrisisevents,secondlayer:

real-timemonitoringofanidentifiedcrisisevent’sseveritylevel).

Input • Weatherforecastingdata(earlywarninglayer)

• OutputsfromWP3-WP5modules(monitoringlayer)

Output • Identificationofupcomingcrisisevent(earlywarninglayer)

• Levelofseverityforidentifiedcrisisevent(monitoringlayer)

Programminglanguages Java,R

Dependencies • WP2weatherforecastingdata

• WP2userrequirements

• OutputfromWP3-WP5modules

CriticalFactors • DifficultiesinutilizingtheoutputsofsomeWP3-WP5modules

inthemonitoringlayerofthemodule

• Insufficientintegrationoftheuserpartners’domainexpertise

intothemonitoringlayer

Table4:Crisisclassificationmodulesummary

3.1.2 Conceptandconceptualrelationextractionfromtextualinformationmodule

Theconceptandconceptualrelationextractioncomponentsimplementthemultilingualtext

analysis functionalities of beAWARE, enabling to process textual inputs in the targeted

languages and abstract them into structured representations that faithfully capture their

meaning,andcanbesubsequentlyreasoneduponforintelligentdecisionmakinginWP4.

ConceptextractioncomponentThe concept extraction component tackles the recognitionof namedandnominal entities

(objects,locations,etc.)andeventsfromthepertinenttobeAWAREtextualinputs(i.e.social

media posts, SMS messages, transcribed language, etc.), their disambiguation, and their

mapping to existing structured lexical and knowledge resources such as BabelNet7 and

7 http://babelnet.org/

D7.1–V1.0


DBpedia8. ItservesasthefirststepofthebeAWAREsemantic,multilingualtextanalysis. It

involvesseveralsteps,includingthenormalisationofthetextualinputs.

Input Rawtext,pluspertinentmetadata(e.g.geolocation)

Output RDFrepresentations,fedtotheKBviaUPDATEqueries

Programminglanguages/tools

Java,UIMA/DKProsoftwarearchitecture,JenaAPI

Dependencies • Componentsaffording(viatheBUS)textualinputs,namely:

socialmediamonitoring,automaticspeechrecognition,and

mobileapplicationbackend

• Semanticrepresentationandreasoning:theextractedRDF

representationsareusedtopopulatetheKB

CriticalFactors Poorcontextduetobrevityandnatureofinputtexts

Table5:Conceptextractioncomponentsummary

RelationextractioncomponentThe relation extraction component deals with the identification of semantic frames, i.e.

relationalcontextsthatdenoteeventsandsituationsbetweenentities(frameparticipants)

andthesemanticroles(frameroles)oftheparticipatingentities.Itservesasthesecondstep

ofthebeAWAREsemantictextanalysis.

Input Raw text plus annotations extracted by the concept extraction

module

Output RDFrepresentations,fedtotheKBviaUPDATEqueries


Java,UIMA/DKProsoftwarearchitecture,Matetools,JenaAPI

Dependencies • Conceptextractionperformance

• Semantic representation and reasoning: the extracted RDF

representationsareusedtopopulatetheKB

CriticalFactors • Poorcontextduetobrevityandnatureofinputtexts

• Incompleteand/orpartiallyungrammaticalinputs

Table6:Relationextractioncomponentsummary

3.1.3 Conceptandeventdetectionfrommultimediamodule

Thismoduleconsistsof severalcomponents thatdealwithseveralaspectsofconceptand

event detection. More specifically, the concept and event detection from multimedia

modulecomprisesthefollowingcomponents:(a)Thedynamictexturerecognition(DTr),(b)

the object detection (ObjD) in video frames and images, (c) the traffic level classification

(TLc)and(d)theSpatio-Temporallocalization(STL)offire,smokeandfloodincidents.More

informationforeachcomponentisprovidedinthefollowingsubsections.

8 http://wiki.dbpedia.org/

D7.1–V1.0


Dynamictexturerecognition(DTr)componentThedynamictexturerecognitioncomponentisresponsibleforanalysingvideosamplesand

determining whether they contain a fire, smoke, flood or traffic incident. It is used as a

prerequisitebeforerunningobjectdetectionandtrafficclassificationcomponents.

Input Videofile(.avi,.mp4)fromstaticormobilecamera.

Output .xmlwiththepredictionscoreoftheclassificationtask


C/C++,Python,openCV,vlfeat

Dependencies • WP2userrequirements

• WP4modulesthatwillprovidetheinputvideosfromtweets

• WP4modules (KB service) that will retrieve information from

theDTr

CriticalFactors It is essential that the input files have been acquired from video

samples that do not contain a lot of camera motion, and good

lightingcondition.

Table7:Dynamictexturerecognitioncomponentsummary

Objectdetection(ObjD)componentObjectdetectionwilltakeplaceonvideosamplesthathavebeenindicatedbythedynamic

texturecomponenttoincludeafire,smoke,floodortraffic incidents.Objectdetectionwill

alsotakeplaceon imagesthatthetextretrievalmodulewhichanalysestweeterpostshas

indicatedthattheycontainfire,smokeoffloodincident.

Input Video(.avi, .mp4)fromstaticofmobilecameraor imagefile(.png,

.jpg)frommobilecamera

Output .xmlwiththepredictionscoresforeachobjectthatexistsinsidetheimageframeanditsboundingbox(i.e.wherethisobject is located

insidetheimage)


C/C++,python,openCV,vlfeat,caffe


• DTrcomponent

• WP4 modules (KB service) that will provide the input images

andvideosfromtweets

• WP4modulesthatwillretrieveinformationfromtheObjD

CriticalFactors Theobjectsthatweexpecttoidentifyshouldnotbeoccludedmore

than50%bywater,smokeorfloodregions.

Table8:Objectdetectioninvideoframesandimagescomponentsummary

Trafficlevelclassification(TLc)componentThe traffic level classification component will be responsible for classifying the traffic

incidentsthathavebeendetectedbythedynamictexturecomponent.Trafficlevelincidents

couldbeclassifiedaslight,mediumorhighdensityones.Thealgorithmcouldworktwofold

sothatitcanclassifybothimagesandvideoinputfiles.Ontheonehand,thecomponentwill

count thenumberofcarsbyusing theobjectdetectioncomponent toclassify image files,

D7.1–V1.0


while on theother hand itwill use dynamic texture representation features to clarify the

motionpatternthatthecarsexhibitanddistinguishthetrafficlevelinvideos.

Input Video (.avi, .mp4)or image file (.png, .jpg) from static surveillance

cameraorCloseCircuitTV(CCTV)

Output .xmlwiththetrafficlevelofanimageorvideofile




• DTrandObjDcomponents


theTLc

CriticalFactors Wewould need long duration videos to classify appropriately the

trafficlevelclassificationmodel.

Table9:Trafficlevelclassificationcomponentsummary

Spatio-temporallocalization(STL)offire,smokeandfloodincidentscomponentThespatio-temporallocalizationcomponentwillanalysevideofilessoastoidentifythestart

andendboundarydetectionframeswhereacriticaleventoccurs(dynamictexturetemporal

detection).Afterwards,spatiallocalizationwilltakeplacetoidentifythisincidentspecifically

in each frame (dynamic texture frame-based spatial localization). This component will

produceamoredetailedanalysisofwhereacriticaleventoccurs insidea longhourvideo

sample.

Input Video(.avi,.mp4)fromstaticormobilecamera

Output .xmlwiththeboundarytimestampsofacriticalevent(startandend

frame) and corresponding bounding boxes for each video frame

inside




• WP3component:DTr


theSTL

CriticalFactors This module will work only for long duration videos with critical

events

Table10:Spatio-temporallocalizationoffire,smokeandfloodincidentscomponent

summary

3.1.4 AutomaticSpeechRecognition(ASR)module

The automatic speech recognition module provides a channel for analysis of spoken

language in audio and video files. Themodule considers both audio extraction and audio

transcriptionfunctionalities.Theformerdealswiththeextractionofaudio,inthecasethat

the input to themodule is a video file. The latter dealswith the conversion of the audio

input into written texts. The module is able to accept audio and video input in various

D7.1–V1.0


formatsandencodings.WithinbeAWARE,ASR isperformed for three languages regarding

thepilotusecases,namelyItalian,SpanishandGreek.ASRisalsoperformedforEnglish(for

presentation/demonstrationpurposes).

Input Audioorvideofile,languageparameter(English,Italian,Spanishor

Greek)

Output Theoutputisretrievedasynchronously:

• Inthefirststepafile-ID

• Inthesecondstep,eithertherecognisedtextasaplainUTF-8

textortheCTMfilewithtimestepsforeachrecognisedword

Programminglanguages C++,Python

Dependencies • InordertobeabletoadapttheASRfortheusecasedomains,

there will be a need to collect (monolingual) corpora for the

defined domains. Thus, the ASR quality will depend on the

quality and the use-case closeness of the data which will be

usedforthetraining.

CriticalFactors • Therecognitionqualitymightbe lowfortheselecteddomains,

ifthetrainingdatadiffersfromthetestingdata.

Table11:Automaticspeechrecognitionmodulesummary

3.1.5 ActivitytableandworkloadActivity Subactivity Description Dependencies

Crisisclassification Earlywarning Identification and

early warning of

upcoming crisis

events

WP2 weather

forecastingdata

Severity level

monitoring

Real-time

monitoring of an

identified crisis

event’s severity

level

• WP2user

requirements

• Outputfrom

WP3-WP5

modules

• Userpartners’

domain

expertise

Concept and

conceptual relation

extraction from

textualinformation

Conceptextraction Textualinputs

normalization;

identificationand

disambiguationof

named(locations,

temporal,etc.)and

nominalentities

(events,objects)

• Feedoftextual

inputsfrom

socialmedia

monitoring,

mobile

application&

ASR

components

• KBmodeling

andpopulation

requirements

Relationextraction Distilleventsand

situationsalong

with-centric

• Concept

extraction

• KBmodeling

D7.1–V1.0


representations

thatcapturethe

participating

entitiesandtheir

relations

andpopulation

requirements

Concept and event

detection from

multimedia

Dynamic texture

recognition

Classify video

samples as critical

ornot

• WP2user

requirements

• WP4modules

• KBservice

Object detection in

video frames and

images

Detect persons and

cars within video

andimagefiles

• WP2user

requirements

• Dynamic

texture

recognition

component

• WP4modules

• KBservice

Traffic level

classification

Determine the

traffic level of a

videoorimagefile

• WP2user

requirements

• Dynamic

texture

recognitionand

object

detection

components

• WP4modules

Spatio-temporal

localization of fire,

smoke and flood

incidents

Localize the

existence of critical

event in a spatio-

temporal manner

insidevideofiles

• WP2user

requirements

• Dynamic

texture

recognition

component

• KBservice

Automatic speech

recognition

Baselinesystem ASRtrainedon

general-domain

data

N/A

Domain-adapted

system

ASRadaptedforthe

use-casedomains

andtunedbyin-

domaindata

Collectedcorpora

forthedefineduse-

casedomains

Table12:WP3activitytable

D7.1–V1.0


3.1.6 Timelineanddependencyfromothermodules

ACTIVITY Y1 Y2 Y3

WP3 D3.2

D3.3D3.1 D3.4

Crisisclassification Earlywarning Severitylevelmonitoring Multilingualtextanalysis Conceptandconceptualrelationextractionv1 Conceptandconceptualrelationextractionv2 Conceptandeventdetectionfrommultimedia Dynamictexturerecognitionv1 Dynamictexturerecognitionv2 Objectdetectionv1 Objectdetectionv2 Trafficlevelclassificationv1 Trafficlevelclassificationv2 Spatio-temporallocalizationv1 Spatio-temporallocalizationv2 Automaticspeechrecognition Baselinesystem Domain-adaptedsystem

Table13:WP3timeline

D7.1–V1.0


3.2 Aggregation and semantic integration of emergency information fordecisionsupportandearlywarningsgeneration(WP4)

WP4addressesthecollection,aggregationandsemantic integrationofcontentrelevanttoemergencyinformationinordertofacilitatedecisionsupportandearlywarningsgeneration.This is accomplished through: i) the social media monitoring module, ii) the moduleresponsibleformonitoringmachinesourcinginformationfromIoTandM2Mplatforms,andiii)thesemanticrepresentationandreasoningmodule.

3.2.1 SocialMediaMonitoringmodule

TheaimofthesocialmediamonitoringmoduleistocollectpostsfromTwitterthatappeartoberelevanttothethreemainpilots,i.e.floods,fire,andheatwave.Thecrawlingprocessneeds tobe real-timeandefficient, able tohandle large streamsofdata, especiallywhenkeywords such as “fire” have multiple meanings. The module collects tweets in English,Greek, Italian, Spanish, and Danish, that are published by any citizen, civil protectionorganisationoronlinenewswebsites.

InordertogainaccesstoTwitter’sglobalstreamofdata,wehaveexploitedtheStreamingAPIs9, a streaming client that receives tweets themoment that they occur. Compared toTwitter’sRESTAPIs10 ,thisoptionoffersareal-timestreamoftweets insteadofconstantlymakingrequestsandthusoverridesanyratelimiting,i.e.maximumnumberofrequests.TheonlylimitationwhenusingtheStreamingAPIsisthateachaccountisallowedtocreateonlyonestandingconnection.

There are various streaming endpoints that can be divided into the following categories:Public streams, User streams, and Site streams. In our case, the “POST statuses/filter”endpoint of public streams is the most suitable, since it focuses on public data flowingthroughTwitterthatmatchesoneormorefilterpredicates.Specifically,the“track”fieldcanbeusedtodefineupto400searchkeywords,combinedwithanORoperator,sothattheAPIwillreturntweetsmatchinganyofthesekeywords.

Figure2:AllocationofTwitterpoststoitsproperdatacollection

9 https://dev.twitter.com/streaming/overview 10 https://dev.twitter.com/rest/public

D7.1–V1.0


To consume Twitter’s Streaming API, we chose to adopt the Hosebird Client (hbc)11, anopen-sourceandeasy-to-use JavaHTTPclient.A requiredparameter is theuseraccount’scredentials, while an optional parameter is the track keywords. For each pilot and eachlanguage we sustain separate collections in a MongoDB database, not only to store thecrawledtweets,butalsotokeepacollectionofrelevantkeywords.Bycommunicatingwiththesecollectionsweareable todefinea setofwordsanduse themas track terms.Afterconnection with the Twitter API is established, every time a new tweet is retrieved, weexaminewhich of the keywords exists in the tweet’s text. In this waywe canmatch thetweet to the corresponding languageandpilot (e.g. “inundación”matches to Spanishandfloods),andtheninsertittotherespectivedatabase,maintainingthestructureprovidedbytheAPI,sincetheJSONformatfitswellforMongoDBdatabasesstructures.

Aservice iscreatedtoclassifyallpostsasrelevantor irrelevant,soonlytherelevantonesproceed to the beAWARE analysis component, aiming mainly to extract locations and todetect key events. The training of the classificationmodel is based on user feedback, ascollected from our dedicated interface that demonstrates all social media collections,offeringtheannotationoptionasrelevant/irrelevant,whichisstoredasabinaryattributeinMongoDB.

Figure3:Interfaceforclassifyingpostsasrelevant/irrelevant

11 https://github.com/twitter/hbc

D7.1–V1.0


Theclassificationservicecollectsthestoredannotatedpostseverymidnight(00:00GMT+2)toupdatethetrainingset.TheupdatedtrainingsetisusedtoassignanestimatedrelevancescoretosendonlytherelevantTwitterpostsforfurtheranalysis.Theclassificationisbasedonopen-sourcecode,whichisalsoavailableasalibraryinR(RTextTools12),incombinationwiththetm13library.

OnceanewTwitterpost is collectedand identified as relevant, amessage is createdandpublishedtothecommunicationbusandallsubscriberscanaccessthemarkedTwitterpostsdirectlyfromtheMongoDBdatabase.

Theoverallinput,output,dependenciesandcriticalfactorsarelistedinTable14.

Input Twitter API, Streaming API, relevant keywords for each languageanduse-casescenario

Output RelevantTwitterposts

Programminglanguages Java,R

Dependencies ConceptextractionmoduleandmainlyTask3.2.

CriticalFactors The percentage of relevant to irrelevant Twitter posts; the totalamountofcollectedposts

Table14:Socialmediamonitoringmodulesummary

3.2.2 MonitoringmachinesourcinginformationfromIoTandM2Mplatformsmodule

Sensordataiscrucialfortrackingtheonsetandprogressofacrisis.Thereisalargevariationinsensorsandanalmostequallylargevariationininterfacestoaccessthedatafromthosesensors. The aimof thismodule is to collect time-series sensor data from various on-linesensors and make this sensor data, and the sensor metadata, available through astandardisedinterface.

Amodern, RESTful interface for accessing time-series sensor data and sensormetadata isTheOGCSensorThingsAPI14. Itspecifiesadatamodel,a JSONdataformatfortransferringthe data, and a RESTful interface for accessing the data. The datamodel is based on theISO/OGC Observation and Measurement (O&M) model. The data format and RESTfulinterfaceisbasedontheOASISODataVersion4.0specification.SeveralimplementationsoftheSensorThingsAPIexist,bothopen-andclosed-source.

Thesensordatawillbe fed into thesystemthroughdatawrappers thatmediatebetweenthe (oftenproprietary) interfaceof the sensor and the SensorThingsAPI. Themodulewillcontain an extension for setting thresholds and for sending notifications through thecommunicationbus(WP7)whenthresholdsarepassed.

12 https://cran.r-project.org/web/packages/RTextTools/index.html 13 https://cran.r-project.org/web/packages/tm/index.html 14 http://docs.opengeospatial.org/is/15-078r6/15-078r6.html

D7.1–V1.0


Input Time-seriessensordatainvariousformats

Output Time-series sensordataandmetadata in JSON format, conformingtotheOGCSensorThingsAPIspecifications

Programminglanguages Java,PLSQL

Dependencies • Modulessupplyingsensordata(WP2,WP7)• Modulesaccessingsensordata(WP3,WP6,WP7)• Communicationbus(WP7)

CriticalFactors Accesstoon-linesensordata

Table15:MonitoringmachinesourcinginformationfromIoTandM2Mplatformsmodulesummary

3.2.3 Semanticrepresentationandreasoningmodule

The semantic representationand reasoningmodule consistsof the followingcomponents:(a)thebeAWAREKnowledgeBase (KB),alsoreferredtoas“ontology”,(b)theKBService,(c) the semantic enrichment and reasoning framework. More information on thesecomponentsisgiveninthefollowingsubsections.

SemanticKBcomponent

ThesemanticKB,orontology,constitutesthecoremeansforsemanticallyrepresentingthepertinentknowledgeandforsupportingdecision-making.Basedonawell-definedformalism(OWL–WebOntologyLanguage),thebeAWAREontologywillencompass,amongstothers,information regarding domain knowledge (types of crises, risks and impacts), multimodalinput (image, video, text and speech) and contextual information, climate andenvironmentalconditions,geolocations,aspectsrelevanttoeventsandtime.

Typicalconstructsstoredinanontologycontaintheclassesrepresentingthemainentitiesinthedomain,the instantiationsoftheseclasses(i.e.objects)andtherelationsbetweentheentities. Specifically, for thebeAWAREontology, the storednotions and interrelationshipswill depend on the output of the requirements analysis activities within WP2, and mostnotablyonD2.1,deliveredinM5.Thecontentoftheontologywillbeupdatedinlaterstagesin the project lifetime, according to more up-to-date needs arising from the pilotdeployments.

The design and development of theontologywillfollowawell-knownontologyengineering methodology, called “NeOnmethodology”,whichisextremelysuitablefor collaborative ontology design andauthoring (i.e. twobeAWAREpartnersareinvolved in developing the ontology,CERTH and IOSB). The actual deploymentof the ontology will rely on open-sourceestablished software tools: Protégé (v.5+) ontology editor for authoring the ontology,GraphDBorWebGenesistriplestoreservingastheontologyrepository.

Inordertoconformtoamoremodularapproach, thebeAWAREontologywillconsistofaset of interconnected sub-ontologies, one per class of crises (flood, fire, heatwave).

Figure4:beAWAREontologynetwork

D7.1–V1.0


Additionally, existing standards and ontologies will be adapted or extended according tobeAWAREneeds.

Afterthebasicschemaoftheontology is finalised,the inputtotheontologywillcome(inthe formof instances) fromvariousotherbeAWAREcomponents, likee.g. thecomponentextractingconceptsandconceptualrelationsfromtext(T3.2),orthecomponentretrievingconcepts and events frommultimedia (T3.3). Sincewe are expectingmassive volumes ofinstancestobeaddedintotheontologyinthecaseofacrisisevent,thechoiceofascalableontologyrepositoryisofutmostimportance.

Input TheKBsimplystoresinformation–inputandoutputarehandledbytheKBservice(seenextsubsection).Output

Ontologylanguage OWL2

Dependencies Ontologyhasdependencieswith:

• WP2userrequirements;• KnowledgeextractedfromWP3andWP4modules;• WP5modules,whichwillretrieveinformationfromtheKB.

CriticalFactors • Inefficient communicationwith use case partners on themostrelevantnotionstobestoredintheKB.

• Scalabilityoftheontologyrepository.

Table16:SemanticKBcomponentsummary

KBServicecomponent

TheKBServiceisresponsibleforaccessingandupdatingtheontologycontent,byprovidingaRESTFulAPIservice.CallstotheAPIfromend-userswillbetranslatedtoappropriateSPARQL1.1 queries, which will then be submitted to the GraphDB triple store maintaining theontology.Thus, thiscomponent is responsible for theontology’ssemantic integration, i.e.semantically integrating information that is the output from other modules into theontology.

Other aspects thatwill be investigated (and potentially added to the KB Service) include:ontologypopulationandontologyenrichment.Theformerprocessinvolvestheadditionofobjects/instances into the ontology, while semantic enrichment refers to the process ofaugmenting the semantics of anontologyby establishing links to external sources andbyappendingnewknowledge retrieved fromthosesources. It is imperative that theexternalthird-partyknowledgesourcesservedatainanappropriateformat(i.e.asRDFLinkedData),thuswewillconsiderknowledgesourcessuchasDBpedia,GeonamesandFreebase.

Input Select/Updatequeriesfromothercomponents.

Output Responsecontainingtheresultsetofthe‘Select’query.Inthecaseof ‘Update’ queries, the response will be the number of triplesaddedto/removedfromtheontology.

Programminglanguages Any(RESTfulAPIsarelanguage-independent).

Dependencies • CommunicationBus(WP7);• ModulesaccessingtheKBService(throughtheBus):WP3,WP4,

WP5modules.

D7.1–V1.0


CriticalFactors • Concurrencyoftransactionstotriplestore.• Scalabilityoftheontologyrepository.

Table17:KBservicecomponentsummary

SemanticReasoningcomponent

This component is responsible for performing semantic reasoning on the ontology,whichrefers to the process of inferring implicit knowledge from the explicitly asserted factsresidingintheontology.Thereasoningmechanismswillsupportsophisticatedinterpretationtasksrelevanttothemanagementofmultimodalincominginformationandtotheretrievalofinformationpertinenttotheusers’needs.

AcriticalissueforbeAWAREinvolveshandlinguncertaininformation.Forthispoint,wewillrelyonfuzzyand/ornon-monotonicreasoningapproaches,inordertocopewithincompleteand inconsistent information and to resolve conflicts and prioritize the proposed actions.Existingreasoningengineswillbethebaselineforthesemanticreasoningactivityandwillbeeffectivelyextended,inordertomitigatetheircurrentlimitations,likee.g.scalabilityissues,non-seamlessintegrationwithontologies(inthecaseofuncertaintyreasoningengines)andmoreimplementation-specificlimitations.

Input Asetoffacts(inRDF)relevanttothequeryfromtheuser.

Output A graph of query-relevant facts extracted from the triple store.Relevantinformationwillbeencodedinthegraph.

Programminglanguages Javaand/orPython

Dependencies • OntologyandKBServicefromWP4;• Use case needs and requirements from WP2 with respect to

datatypesandreasoning.

CriticalFactors • The accuracy of this service is crucial to the quality of usersupporting information. Flaws/errors in the reasoning andinferenceproceduresmightproducesub-optimalresults.

• The size of the knowledge base might be too large for thereasonertohandleefficiently.

• The lack of specificity can lead to poor results with thiscomponent.

• Uncertaintyhandlingshouldbemeaningfulandnottrivial.

Table18:Semanticreasoningcomponentsummary


SocialMedia

SocialmediacrawlingCollect social mediainformation from socialmedia(real-time)

• TwitterStreamingAPI

Classification of socialmediaposts

Classify the collectedsocial media posts asrelevantorirrelevant

• WP2 user requirementsfor annotating a trainingsetofTwitterposts

Event detection andlocalisation

Detect locations in rawtextfromsocialmediaandclusterpostsbylocation

• Task 3.2 (conceptdetection from textualinformation)

Sensordata Sensordataintegration Mediatingbetweensensor • WP2Userrequirements

D7.1–V1.0


interfaceandtheSensorThingsAPI

andSensordatasources

Thresholddetection Implementingthresholddetectionandnotification • WP7Communicationbus

SemanticKB

Ontology specification&conceptualization

Designtheontology,usingrequirements extractionand conceptualizationtechniques(e.g.diagrams)

• WP2userrequirements• WP5modules,whichwill

retrieveinformationfromtheKB

Ontology formalization&implementation

Formalize the ontologyusing an appropriateontologylanguage

• WP2userrequirements• WP5modules,whichwill

retrieveinformationfromtheKB

Ontology mapping andalignment

Establish links to othervocabularies/ontologies

• Knowledge extractedfrom WP3 and WP4modules

KBService

Investigate semanticintegrationtechniques

Examine approaches forsemanticintegration N/A

KBServicev1 Integrateinv1operationalprototype

• Communication Bus(WP7)

• ModulesaccessingtheKBService:WP3,WP4,WP5modules

KBServicev2 Integrateinv2operationalprototype

SemanticReasoning

Investigate uncertainty&scalablereasoning

Examine relevantapproaches N/A

Implement uncertaintyreasoningv1

Integrateinv1operationalprototype

• Ontology and KB ServicefromWP4

• Use case needs andrequirementsfromWP2

Implement uncertaintyreasoningv2


Integrate scalablereasoningv1


• Ontology and KB ServicefromWP4

• Use case needs andrequirementsfromWP2

Integrate scalablereasoningv2



D7.1–V1.0



ACTIVITY Y1 Y2 Y3

WP4

D4.1

D4.2 D4.3

Socialmediamonitoring Socialmediacrawling Classificationofsocialmediaposts Eventdetectionandlocalisation Sensordataintegration SemanticKB(ontology) Ontologyspecification&conceptualization Ontologyformalization&implementation Ontology mapping and alignment with othervocabularies

KBService Investigate semantic integration techniques formultimodalinput

ImplementKBServicev1 ImplementKBServicev2 SemanticReasoning Investigateuncertainty&scalablereasoning Implementuncertaintyreasoningframeworkv1 Implementuncertaintyreasoningframeworkv2 Integratescalablereasoningtechniquesv1 Integratescalablereasoningtechniquesv2

Table20:WP4timeline

D7.1–V1.0


3.3 Multilingualreportgeneration(WP5)WP5 addresses the generation of the emergency reports andmessages that need to (orshould) be communicated to the different types of stakeholders that beAWARE considers(authorities, first responders, citizens,etc.)duringanemergency inorder toprovide themwithtailoredsupport.Itaccomplishesthisthroughthefollowingtwomodules.

3.3.1 Textplanningmodule

Thetextplanningmoduledealswiththeselectionofcontentfromthesemanticrepository(KB) and the creation of a discourse plan for the reports and messages that are to begenerated. It serves as the first step in the beAWARE emergency report and messagegenerationpipeline,anditisresponsiblefortailoringcontentsselectionandtheirstructuringtotheinformationneedspertinenttothespecifictargetusergroupandcontext.

Input • RDFtriplesobtainedviaSELECTqueriesfromtheKB• Targetedusergroup (e.g.authorities, first responders,citizens,

etc.), with the possibility for further potentially relevantinformation(e.g. filters) fromthetriggeringmodules (semanticreasoningandPSAP)

Output PartiallyorderedsequenceoftheselectedRDFtriples


Java,BabelNetsynsetannotatedWikipediadump

Dependencies • Modules triggering report generation, namely semanticreasoningandPSAP

• Domain knowledge modelling, as it affects the selection anddiscoursestructuringcriteria

• Specification of the information needs of the different usergroupsaddressed

CriticalFactors • Scalabilityofcontentselectionalgorithm• Update effectively with respect to what has been

communicatedpreviously• The richer the semantic domainmodel, themore changes for

coherentcontentselectionanddiscourseplanning

Table21:Textplanningmodulesummary

3.3.2 Multilinguallinguisticgenerationmodule

The multilingual linguistic generation module deals with the verbalization of emergencyreportsinthelanguageofendusergroupstargetedinthebeAWAREpilots.Ittakesasinputthe abstract (conceptual) representations produced by the text planning module andsuccessivelyproducesallthelayersforeseenbytheMeaning-TextTheorythroughapipelineofgraphtransducersandclassifiers.

Input RDFtriplesasselectedbythetextplanningmodule

Output Naturallanguagereportsandmessagestobeshowntotheinvolvedstakeholders(authorities,firstresponders,citizens,etc.)

D7.1–V1.0



Java,JenaAPI,Matetools

Dependencies • Textplanningmoduleperformance• User partner’s specifications about the desired/appropriate

language style for the different types of generatedreports/messagesintheconsideredpilotcontexts

CriticalFactors Flexible projection of RDF constructs to predicate-argumentstructuresthataresuitableforlinguisticgeneration

Table22:Multilinguallinguisticgenerationmodulesummary

3.3.3 ActivitytableandworkloadActivity Subactivity Description DependenciesTextplanning Contentselection Selectrelevant

contentsformtheKB,uponpertinentsystem/userrequest

• Semanticreasoning/PSAPtriggersforcontentselection

• Expressivityofreferencedomainontology

• Userpartnerdelineatedcriteriaforassessingrelevance/importanceofthecontentstobeincluded

Discoursestructure Arrange selectedcontents in acoherentway

• Contentselectionperformance

• Expressivityofreferencedomainontology

Multilinguallinguisticgeneration

Mappingfromconceptualrepresentationstolinguisticsemanticstructures

Projectionofontologicalrepresentationstolinguisticsemanticstructures

• Textplanningcompleteness• Underlyingsemanticsof

referencedomainontology

Mapping fromlinguistic semanticrepresentations tosurface-syntacticones

Projection oflinguistic semanticstructures tosyntacticones

N/A

Linearisation &morphologicalrealisation

Projection oflinguistic syntacticstructures tonatural languagetext

N/A


D7.1–V1.0



ACTIVITY Y1 Y2 Y3

WP5

D5.1

D5.2 D5.3

Emergencyreportgenerationspecificationsandrequirements

Textplanning

Contentselection&discourseplanningv1

Contentselection&discourseplanningv2

Multilinguallinguisticgeneration

ProjectionofconceptualreprensetationstoNLtextv1

ProjectionofconceptualrepresentationtoNLtextv2

Table24:WP5timeline

D7.1–V1.0


3.4 Main Public Safety Answering Point for emergency multimediaenrichedcalls(WP6)

TheobjectivesofWP6aretodevelopaunifiedplatformdeployedinpublicsafetyanswering

points (PSAP) for efficient emergency incidents management through the provision of a

commonoperationalpictureandimprovedsituationalawareness,basedon4mainpillars:

1. Collectingandcorrelatingmultimodaleventscomingfromdisparatedatasources;

2. Videomanagement;

3. GeographicalInformationSystem(GIS)analysis;

4. Incidentandresourcemanagement.

One of the main objectives of this WP is the design and development of an advanced

presentationlayerbasedoncuttingedgeGIS,analyticandvisualizationtechniques.Thiswill

include research on novel interaction techniques and investigation of new presentation

conceptsindataanalysis.

PSAPhasathree-tiertechnologicalarchitectureasshowninFigure5:

• FrontEnd–DesktopandWebClients,endpointsecurity.

• BackEnd–DesktopandWebServices,Inbound/OutboundCommunicationServices,

ServerSecurity(includingClientAuthenticationServices).

• Infrastructure–ArcGISGeographicalInformationServices,IBMmessagingservices.

Figure5:PSAPTechnologicalArchitecture

3.4.1 PSAPcapabilities

ThefollowingcapabilitiesareplannedaspartofthePSAPfunctionality:

Pre-EmergencyDecision-SupportingRiskVisualizationPSAP shall display pre-emergency risk assessment and crisis classification to the decision

makers.

Input Risk assessment, Crisis Classification, Alerts,

Position-based metrics, Analyzed video and

images,analyzedsensorreadingreports

Sources: Flood Risk Analysis

Services, Crisis Classification

Services, Video Analytics,

Social Media Analytics,

SensorAnalytics

D7.1–V1.0


Output Risk display, decision supporting information

display,geo-basedinformationlayerdisplay

Videoplayback,Imagedisplay

Riskindicatorandmetriccharts

Recipients: Decision Makers,

Emergency Managers,

EmergencyAnalyst


N/A

Components DSS,Front-End,Back-EndServices,GIS

Dependencies Flood Risk Analysis Services, Crisis Classification Services, Video Analytics,

SocialMediaAnalytics,SensorAnalytics,MessageBus

CriticalFactors FloodRiskAnalysisServices,CrisisClassificationServices,OutcomesofD6.1

Table25:Pre-EmergencyDecision-SupportingRiskVisualizationsummary

EmergencyIncidentCollectionandDisplayPSAP shall collect and display emergency incident information to the emergency control

centeroperators.

Input Incident Sources:VideoAnalytics,

SocialMediaAnalytics,

Generalpublic,First

responders,LocalPolice/

Calltakingservice

Output Geo-basedincidentdisplay

Incidentrecorddisplay

Recipients:

EmergencyManagers,

ControlCenterOperators


N/A

Components Front-End,Back-End,GIS

Dependencies VideoAnalytics,SocialMediaAnalytics,FirstResponder(FR)MobileApp,Public

MobileApp,Calltakingservice,ExternalIncidentDataProvider,MessageBus

CriticalFactors N/A

Table26:EmergencyIncidentCollectionandDisplaysummary

FirstResponderPositionCollectionandDisplayPSAPshallcollectanddisplay first responderteampositionsandstatus informationtothe

emergencycontrolcenteroperators.

Input FirstResponderPosition Sources:FRMobileApp

Output Geo-basedworkforcepositiondisplay

Workforceinformationdisplay

Recipients:

EmergencyManagers,

ControlCenterOperators


N/A


D7.1–V1.0


Dependencies FRMobileApp,MessageBus

CriticalFactors FRMobileApppositionsending

Table27:FirstResponderPositionCollectionandDisplaysummary

IncidentAssignmenttoFirstResponderPSAP shall allow assigning incidents to first responder teams and incident information

distributiontothefirstrespondersbytheemergencycontrolcenteroperators.

Input Incidentassignmenttoworkforce Sources:ControlCenter

Operator

Output Incidentinformation(positionanddetails) Recipients:

Firstresponders(withFR

MobileApp)


N/A

Components Front-End,Back-End

Dependencies FRMobileApp,MessageBus

CriticalFactors FRMobileAppTaskReceptionInterface

Table28:IncidentAssignmenttoFirstRespondersummary

PublicAlertPSAP shall allow sendingpublic alerts regarding incidents and general risk assessments to

citizenswhohavethePublicAppontheirmobiledevice.

Input PublicAlert,incidentcue Sources:ControlCenter

Operator

Output PublicAlertMessage Recipients:

Citizen(withPublicMobile

App)


N/A

Components Front-End,Back-End

Dependencies PublicMobileApp,MessageBus,AlertTranscripts

CriticalFactors N/A

Table29:PublicAlertsummary

IncidentManagementPSAP shall receive and display incident information, status, and footage from first

respondersinthefieldorbystanders(citizens)whowillprovidetheinformationandfootage

fromtheirmobiledeviceandFRMobileapp.

Input Incidentinformation,IncidentFootage(video,

stills)

Sources:FRMobileApp,Public

MobileApp

D7.1–V1.0


Output Incidentinformationdisplay

Incidentlifecyclemanagement

On-mapincidentinformationdisplay

Videoplayback,Imagedisplay

Recipients:

ControlCenterOperator


N/A


Dependencies PublicMobileApp,FRMobileApp,MessageBus

CriticalFactors N/A

Table30:IncidentManagementsummary


Main Public

SafetyAnswering

Point for

emergency

multimedia

enrichedcalls

Pre-Emergency

Decision-

SupportingRisk

Visualization

Display pre-emergency risk

assessment and crisis

classification to the

decisionmakers

FloodRiskAnalysis Services, Crisis

Classification Services, Video

Analytics, Social Media Analytics,

SensorAnalytics,MessageBus

Emergency

Incident

Collection and

Display

Collect and display

emergency incident

information to the

emergency control center

operators

Video Analytics, Social Media

Analytics, FR Mobile App, Public

Mobile App, Calltaking service,

External Incident Data Provider,

MessageBus

FirstResponder

Position

Collection and

Display

Collect and display first

responder team positions

and status information to

the emergency control

centeroperators

FRMobileApp,MessageBus

Incident

Assignment to

FirstResponder

Assign incidents to first

responder teams and

incident information

distribution to the first

responders by the

emergency control center

operators

FRMobileApp,MessageBus

PublicAlert Sendpublicalertsregarding

incidents and general risk

assessments to citizens

whohavethePublicMobile

Appontheirmobiledevice

Public Mobile App, Message Bus,

AlertTranscripts

Incident

Management

Receive and display

incidentinformation,status

and footage from first

responders in the field or

bystanders (citizen) who

will provide the

information and footage

from their mobile device

PublicMobileApp,FRMobileApp,

MessageBus

D7.1–V1.0


andFRMobileapp


D7.1–V1.0



ACTIVITY Y1 Y2 Y3

WP6

D6.1

D6.2

D6.3 D6.4

Pre-emergency decision-supporting riskvisualization

Researchandspecification Designanddevelopment Deployment,integration,demonstration Emergencyincidentcollectionanddisplay Designanddevelopment Deployment,integration,demonstration Firstresponderpositioncollectionanddisplay Designanddevelopment Deployment,integration,demonstration IncidentAssignmenttoFirstResponder Designanddevelopment Deployment,integration,demonstration PublicAlert Designanddevelopment Deployment,integration,demonstration IncidentManagement Designanddevelopment Deployment,integration,demonstration

Table32:WP6timeline

D7.1–V1.0


3.5 Systemdevelopment,integrationandevaluation(WP7)Due to the distributed approach of the design and implementation of the beAWAREplatform,inwhichdifferentpartnersmaintainownershipoverdifferentcomponentsofthesystem,combinedwiththecomplexityoftheplatform,whichiscomprisedofmanydifferentcomponentswe opted to follow amicro-services approach tomake the entire process ofdesign,implementation,andintegrationmoremanageable,inadistributedmanner

Using thisapproach,wemaintain the independenceof thedifferentcomponents,and theintegrationfocusisontheexposedcapabilitiesofeachcomponent.Theintegrationbetweencomponents isbeingrealizedvia twomainmechanisms, first, inter-communicationvia theplatformcommunicationservicebus,andsecondthroughexposedRESTinterfacesofvariouscomponents,potentiallyaidedbyadiscoveryservice.

Micro-servicesisanarchitectureformandmethodologyforbreakingupalargeandcomplexsystemintosmallunits,eachfulfillingauniquewell-definedtask,inanindependentmanner.Eachsuchmicro-serviceisdeployedseparatelyandcaninteractwithitspeermicro-servicesusing standard communication protocols. Such an approach eases the task of long termmaintenanceandevolutionofalargesystem,comparedtoamonolithicsystem.Inaddition,internal changeswithin amicro-service do not influence any other system component aslongastheexternalcontractofthemicro-serviceisadheredto.Moreover,eachcomponentcanbeimplementedinadifferentprogramminglanguage,usingdifferentmiddleware.

Asmentionedearlier,therearetwomainmechanismsformicro-servicestointeract,namely,thecommunicationservicebusandaREST interface(possiblywiththehelpofadiscoveryservice).Forcommunicatingthroughthecommunicationbusthecomponentsneedonlytoagree on the topic via which they will be interacting and the format of the messagespublishedonthattopic.ForcommunicatingviaaRESTinterface,thereneedstobeawayforone micro-service to find another micro-service it wishes to invoke. For that purpose, aservice discovery component may be deployed. Such a component serves as a centralregistry of availablemicro-services, responding to queries about the location of a certainmicro-service. In actual deployments, this capability can be provided by packages such asNetflixEureka,amalgam8,orConsul.

Additional helping capabilities that may be employed in our environment consists of agateway,healthmonitoring,andlogging(ELKstack).

3.5.1 Twelve-FactorApplications15

Theplatformwillbecomposedofmultiplemicro-servicesandaspirestoseamlesslydeliverservicestoitsusers,thusweareencouragedtousethefollowingguidelines:

1. Codebase

Maintainaone-to-onerelationshipbetweencodebaseandtheapplication(onecodebasemultipledeploys).

15 https://12factor.net/

D7.1–V1.0


2. Dependencies

Theyshouldnotrelyonsystem-widepackagesorfunctions.Dependenciesmustbedeclaredinsidethescopeoftheapplication

3. Configuration

Separationbetweenconfigurationandcode,asconfigurationvariesacrossdeployments.

4. Back-endServices

Amicro-serviceshouldmakenodistinctionbetweenlocalandthirdpartyservices.

5. Build,release,run

Separatebetweenbuild,release,andrunstages.

6. Processes

Stateless.Anypersistentdataisstoredusingexternalservices.

7. Portbinding

Applicationshouldbestandalone,ratherthanrelyingonarunninginstanceofanapplicationserver.Servicesareprovidedtoexternalsviaacertainportboundtotheapplication.

8. Concurrency

Shouldeasilybescaledhorizontallyandhavingtheworkloaddistributedamongstmultipleinstancesofthesamemicro-service.

9. Disposability

Supportfailuresbyeasilybeingstartedandstopped.

10. Development/productionparity

Designedforcontinuousdeployment.Therefore,thedifferencebetweendevelopmentandproductionenvironmentsshouldalwaysbeminimal.

11. LogsProvideacontinuousstreamoflogginginformation,whichisretrievedbyaseparatelyconfiguredservice.

12. Adminprocesses

Runadmin/managementtasksasone-offprocesses,onanenvironmentsimilartoproduction.

3.5.2 Systemarchitecture

ThiswillinvolvethedefinitionoftheglobalarchitectureforthebeAWAREplatform,fromitshigh-levelcomponentdesigntotheserverlayoutdefinition.Aroadmapwillalsobedefined,todrivetheprocessofimplementation.

Dependencies User requirements, specification of pilot use cases and validationplan: the Use Cases will drive the processes and ultimately thearchitecture will be built to service those use cases, so a cleardefinitionisessential.

D7.1–V1.0


CriticalFactors • IncompleteUseCasedefinition:UCsmustbeclearlydefinedandwell understood to ensure the appropriate systems, processesand capabilities are put in place in the architecture.UCsmustincludecomprehensivescenariosandvalidationplanstoensurethearchitectureisbuiltcorrectlytospecifications.

• Incomplete service definition: each of the technicaldevelopmentWP is responsible fordefiningtheserviceAPI forcomponents related to its research. Failure to provide theAPIspecification in a timely and thorough manner can lead todelaysorerrorsindefinitionofthearchitecture.

Table33:Architecturedefinitionsummary

3.5.3 Technicalinfrastructure

This implies the provisioning and operation of the infrastructure, onwhich the beAWAREsystemwillrun.Thisincludestheinternalservices,businessservices,associatedrepositoriesandexternalentities(mobileapplications,controlcenters).

IteasilyfollowsthatsomesubsystemsofthebeAWAREplatformcannotbedeployedtotheplatform, due to licensing reasons. Othersmay be dependent on secondary systems thatcannot be easily replicated in a different environment, or may require concentratedcomputingpowerthat isprovidedbyahighlyspecializedexpertsysteminapartner’sdatacentre.Insuchcases,proxyserviceswillbebuiltbypartnersandexposedtotherestoftheplatform.Proxyserviceswilldelegateworktotheactualservicesanddoanyextraworkasrequiredinatransparentway.

Dependencies Systemarchitecture:technicalinfrastructurewillbeprovisionedtoimplementthesystemarchitecture.

CriticalFactors • Distributed infrastructure: parts of the infrastructure areforeseentobedistributedandincludesystemswhicharerunin-house by some partners. Issues with firewalls, authentication,etc.aretobeexpected,andacteduponasneeded.

• Performance: the scope and complexity of the beAWAREprocesses and the size of the data to be handled is not yetknown and is likely to evolve as research progresses.Performance problems may arise, and resizing and/orprovisioningofextracapacitymayberequired.

Table34:Infrastructuredefinitionsummary

3.5.4 Systemdevelopment

ThisisthetaskforalldevelopmentactivitiesrelatedtothetechnicalimplementationoftheUseCasesandanyotherworkrequiredforthecompletionoftheobjectives.

The system development will be iterative, from an initial dummy prototype to the finalversion,withthefollowingcycleplanned:

OperationalPrototype

Dummyend-to-endarchitecture;allservicedummiesinplace,operatingontest/mockdata.

FirstPrototype

D7.1–V1.0


UsingrealservicesfromWP3-WP6;FirstPrototypemilestone(MS3).

SecondPrototype

UsingrealservicesfromWP3-WP6;SecondPrototypemilestone(MS4).

FinalSystem

CompletebeAWAREplatform;FinalSystemmilestone(MS5).Dependencies • AlltechnicalWPservices

• WP2UseCasesandEvaluation

CriticalFactors • Changingrequirements:UseCasesshouldremainstableduringthe project. While minor changes are always to be expected,major breaking changes may cause throwing away work thathasalreadybeendoneandimpactondeliverycapabilities.

Table35:Systemdevelopmentsummary

3.5.5 Communicationbus

The communication bus serves as a central point of communication between differentsystem components. Its main mode of operation is that of publish / subscribe, whichsupports different parts of a composite application to be unaware of each other but stillmanagetocommunicateuponneed.Theonlyitemsthatneedtobeagreeduponbetweenapublisher and a subscriber is the name of the topic (channel) throughwhich theywill becommunicatingandtheformatofthemessagesflowingthroughthattopic.

Theproposedbusisinchargeofnotifyinginterestedandregisteredcomponentswhennewitems which are of interest to them have been received or calculated by anothercomponent. In addition, the bus may perform some light transformations on incominginformation,uponneed.

The communication bus will be configured, upon deployment, with the necessary set oftopics as agreed upon between the different components. In addition, the messagestructure of each message in each topic will be agreed upon and documented by thecooperatingcomponents.Thecommunicationbusneedstosupportthenumberofdifferenttopics required for a beAWARE installation, along with the associated aggregatedthroughputinalltopics.

ThecommunicationbusisrealizedbyusinganinstanceofaMessageHubservice,deployedin IBM’sBlueMixcloud.Theback-end isbasedonaKafkacluster,andthe interactionwiththeserviceisrealizedusingstandardKafkaclients.

Dependencies • Kafka–apopularopensourcemessagingplatform• MessageHub–aclouddeploymentbasedonKafka

CriticalFactors • Needstosupportthenumberoftopicsrequiredalongwiththeaggregated throughput. Requires cooperating components toagreeuponmessagesformatandabidebythem.

Table36:Communicationbussummary

D7.1–V1.0


3.5.6 End-usersapplications

Therearetwoend-userapplicationsformobiledevices(smartphonesortablets):oneusedby the first responders and one used by the public. These mobile applications willcommunicatewithabackendthatwillconnecttotherestofthebeAWAREsystem.

With these applications, the first responders can communicate with the PSAP, sendinformationabouttheemergencyevent, receivetasksandreportonthoseassignedtasks.Thepublicwillbeabletoreceiveinformationaboutemergencyeventsandsendinformationabout theevent to thePSAPusing the communicationbus.Both first responders and thepublicwillbeabletosendtext,image,videoandvocalinformation.

Dependencies • Communicationbus• Mobiledevicehardware(camera,voice,gps,gsm)

CriticalFactors • Badreceptiononthemobilenetwork• BadGPSreception

Table37:End-usersapplicationssummary


Systemarchitecture

Technologicalroadmap

Currentdocument N/A

Systemrequirementsandarchitecture

DescriptionoftechnicalrequirementsderivedfromUseCasesanddetaileddesignofplatformarchitecture

WP2userrequirements

Technicalinfrastructure

N/A Provisioningandoperationoftheinfrastructure,onwhichthebeAWAREsystemwillrun

Systemarchitecture

Systemdevelopment

OperationalPrototype

Initialdummyprototype

WPs3-6

FirstPrototype FirstiterationofbeAWAREplatform

WPs3-6

SecondPrototype SeconditerationofbeAWAREplatform

WPs3-6

Finalsystem FinalversionofbeAWAREplatform

WPs3-6

Communicationbus

N/A Centralpointofcommunicationbetweendifferentsystem

• Kafka• MessageHub

D7.1–V1.0


components

End-usersapplications

N/A Mobileapplicationusedbyfirstrespondersandthegeneralpublic

• WP2userrequirements• Integratedsystembackend

(T7.2)• Communication

infrastructure(T7.4)


D7.1–V1.0


3.5.8 Timelineanddependenciesfromothermodules

ACTIVITY Y1 Y2 Y3

WP7

D7.1

D7.2

D7.3 D7.4 D7.5

D7.6

D7.7

D7.8 D7.9

Systemarchitecture Technologicalroadmap Systemrequirementsandarchitecture Technicalinfrastructure Systemdevelopment OperationalPrototype FirstPrototype SecondPrototype Finalsystem Communicationbus End-usersapplications

Table39:WP7timeline

D7.1–V1.0

Page46

4 DevelopmentCycleandUseCases

Theoverall strategy for thedevelopmentof thebeAWAREplatform is tostartwithsimplescenarios and proceed stepwise towards the final system. The detailedwork plans of theindividualmodulespresentedinSection3willfollowthegeneralcycle:afterthecompletionofeachprototypeversion(timingdefinedbyMilestones),thefunctioningoftheprototypeisassessed, the needs for further development are identified and agreed upon, a detailedworkplanforthenextprototypeversionisfinalizedandthedevelopmentcycletowardsthenextprototypeisinitiated.Oneimportantpredefinedconceptforthedifferentprototypesisthedefinitionofthepracticalusecaseseachprototypeisserving.

4.1 Scenario1:FloodTargetgroup:

In each development cycle different user groups (target groups)will be involved in pilot-testinginareal-worldenvironmentandwithreal-worlddata:

• AAWApersonnel

• Decisionmakersinvolvedduringthefloodemergencies:intheC.O.C(theMunicipal

operativecentre):

o TheMayor

o TheheadoftheMunicipalgroupofVicenzaCivilProtection

o TheheadoftheNationalAssociationofCarabinieri

o TheheadoftheNationalAlpineTrooperAssociation

o ThecoordinatorofVoluntaryAssociationsofCivilProtection,ProvinceofVicenza

o TheheadoftheLocalItalianRedCross

o TheheadoftheVicenzaFireBrigades

o TheheadoftheVicenzaLocalPolice

• Citizens

• Firstresponders

• Researchcommunity

• SMEs

• FloodRiskManagementauthorityatnationalandinternationalscale

Objectives:beAWAREshould:

• Support the collection and visualization of spatially distributed and multi-sourcedinformationrelatedtoafloodemergency(floodreports,weatherforecasts, floodearlywarningsystemresults,elementsatrisk,extensionoffloodedareas,crisisclassificationbasedonallavailabledata).

D7.1–V1.0

Page47

• Enable the automatic detection of flood hazardous situations, such as river levelovertopping/breaking.

• Provideauthoritieswiththeabilitytomanagefirstresponderassignments.• Facilitate the communication between authorities and citizens, also in different

languages.Morespecifically,beAWAREshould:o Provideauthoritieswiththeabilitytowarnpeoplewithmessages,oncetheyare

approachingafloodedarea.o Allowcitizenstosendfloodreportswithtext,images,audioandvideo.

4.2 Scenario2:FiresTargetgroup:

Τhe target groups listed below are those who will use and interact with the beAWAREplatforminthephaseofpreparednessandresponseduringaforestfireemergency:

UsersInvolvedinFireUsecases

• Localentities

o CivilProtection-ValenciaCityCouncil:Volunteers

o LocalPolice-ValenciaCityCouncil

o LocalFirefighters:Professionalbody

o Devesa-AlbuferaService

• Localauthorities

o Mayor

o CityCouncilors

ProvincialEnd-UserInvolvedinFireUsecases

• Provincialentities:ValenciaProvincialFireConsortium

• Provincialauthorities:PresidentoftheProvincialCouncil

RegionalUsersInvolvedinFireUsecases

• EmergenciesRuralBrigades

• AirborneandHeliborneBrigades

• ForestFirePreventionServiceoftheDepartmentofAgriculture,Environment,Climate

changeandRuraldevelopment

• NaturalParkGuards

Healthservices

• CenterofCoordinationforEmergencyInformationandCoordination(CICU)

• UrgentMedicalAssistanceServiceUnits(SAMU)

D7.1–V1.0

Page48

• BasicLifeSupportUnits(SVB)

• NotAssistedTransport(TNA)

RegionalAuthorityinFireUsecases

• RegionalAuthority

• RegionalDirectorforPrevention,FireExtinctionandEmergencies

• ValencianSafetyandEmergencyResponseAgency(112-regionalPSAP)

NationalUsersInvolvedinFireUsecases

• GuardiaCivilTrafficGroup

• GuardiaCivilNatureProtectionService(SEPRONA)

• NationalPolice

• UME(militaryemergencyunit)

NationalFirstrespondersInvolvedinFireUsecases

• AircraftsoftheMinistryofEnvironment

Objectives:beAWAREshould:

• Sendinformationregardingpeopleindanger–wherearethey,howmany,howwilltheybeaffected–inordertooptimizetheresponseandpossibleevacuation.

• Provide visualization on incoming information (mobile apps, videos, calls, textmessages,sensors,socialmedia).

• Givetheabilitytomanagethetasksassignedtothefirstrespondersandtrackthesetasks, as well as personnel and material to allow appropriate mobilization andcoordinationofresources(watersupplyetc.).

• Provide information about the fire and weather conditions (development, flameheight,winddirection,droughtindexetc.).

• Provide information to the public (safe locations, safe evacuation directions/ways,warnings,forbiddenactivities/behaviors).

4.3 Scenario3:HeatwaveTargetgroup:

The target groups listed below are those, who will use and interact with the beAWAREplatforminthephaseofpreparednessandresponseduringaheatwaveemergency.Thesegroupsarecategorizedbasedontheirgeographicallevelofinvolvement.

Usersinvolvedinheatwavecasesinlocallevel

• MunicipalCivilProtection

• MunicipalSocialServices

• Mayor

D7.1–V1.0

Page49

• LocalFirefighters:Professionalbody

• NationalEmergencyAidCentre(EKAV)

• Hospitals

• Volunteerorganizations:Firstresponders

• Localtrafficpolice(incaseofatrafficjam)

Usersinvolvedinheatwavecasesinregionallevel

• RegionalDirectorateofFireDepartment

• RegionalCivilProtection

• RegionalHealthDirectorate

• RegionalGovernor

• RegionalPSAP(112,166,199)

Usersinvolvedinheatwavecasesinnationallevel

• NationalHealthOperationsCentre

• GeneralSecretariatforCivilProtection

• MinistryofHealth

• MinistryofforCitizenProtection

• MinistryofNationalDefense

Objectives:beAWAREshouldprovidethefollowingsupporttofirstrespondersanddecisionsmakers:

• Issueanalertonanimminentheatwaveinordertoinformauthoritiestotakeproactivemeasures.

• Provideanassessmentonfirerisk,theperiodduringandafteraheatwave.• Send information of where people are in danger in order to send rescue teams or

orderingevacuations/confinement,especiallyinthecaseswhereelderorsickpeopleareconfinedinhouseswithnoA/Corpeoplearetrappedinanelevator.

• Sendinformationandcreateanestimatebasedonpastevents,onhowmanypeopleareindangerandhowmanyare/couldbeaffectedfromtheheatwave.

• Visualizationonrelevant informationprovidedviamobileapps,calls, textmessages,aswellassocialmediastreams(socialmediamonitoring).

• Assigntaskstofirstrespondersandevaluatetheirdevelopmentinrealtime.• Monitorheatwavedevelopmentandtheweatherconditions.• Keepingtrackofpersonnel,volunteersandequipment/vehicles.• Allowingtheappropriatemobilizationofresources.• Monitortrafficconditionsinordertomobilizefirstrespondersmoreeffectively.• Monitor the level of occupancy in places of relief that are offered to general public

duringaheatwave.

D7.1–V1.0

Page50

beAWAREshouldalsoprovidethefollowingsupporttocitizensaffectedbytheheatwave:

• Sendinformationonplacesforrelief,e.g.wheretheyareandwhatistheleveloftheiroccupancyinrealtime,asmuchaspossible.

• Sendwarningstocitizensinordertoavoidinterferenceswithfirstresponders.• Informcitizensofbestpractices/behavioursduringaheatwave.• Warncitizensofanimminentheatwave.

D7.1–V1.0

Page51

5 ProjectTimelineandMilestones

Theplatformwillbebuilt incrementallyand iteratively, startingwithasystemmadeupofdummy services for formal end-to-end validation and delivering increasingly enrichedfunctionalityandfurthercapabilitiesoneachmilestone.

Thefigurebelowillustratesthetimelineforthetechnicalmilestonesintheevolutionofthesystem.

Figure6:beAWAREwalkingskeleton

D7.1–V1.0

Page52

6 Summary

In this deliverable, the technical roadmap of the beAWARE platformwas presented. Thisdocumentwillguidethedevelopmentof theprojectwithaviewtoattainingthescientificandthetechnicalobjectivesenvisaged.

However, since the project is following an iterative development procedure (use cases-requirements-development-evaluation),itisexpectedthatsmalladaptationsanddeviationsfrom the initial technical specifications and the module functionalities foreseen by thisdocumentwillbeneededtosatisfy the finaluserrequirements.Suchchanges/adaptationsmightberequiredatcomponentorsubcomponentlevel.Theplatformarchitecturetogetherwith the detailed specification of the modules (including any updates required) will bereportedinD7.2(Systemrequirementsandarchitecture).

Documents

d7.1 beaware technological roadmap 2017-6-30 v1.0 · Page 1 beAWARE Enhancing decision support and management services in extreme weather climate events 700475 D7.1 Technological