D2.7 Report on Technical Requirements and Overall System … · Project: I-REACT Report on...

IMPROVINGRESILIENCETOEMERGENCIESTHROUGH

ADVANCEDCYBERTECHNOLOGIES

ReportonTechnicalRequirementsand

OverallSystemArchitecture

DeliverableID D2.7

WorkPackageReference WP2

Issue 3.0

DueDateofDeliverable 30/11/2016

SubmissionDate 30/12/2016

DisseminationLevel1 PU

LeadPartner ISMB

Contributors -

GrantAgreementNo 700256

CallID H2020-DRS-1-2015

FundingScheme Collaborative

I-REACTisco-foundedbytheHorizon2020FrameworkProgrammeoftheEuropeanCommission

undergrantagreementn.700256

1

PU=Public,PP=Restrictedtootherprogrammeparticipants(includingtheCommissionServices),

RE=Restrictedtoagroupspecifiedbytheconsortium(includingtheCommissionServices),

CO=Confidential,onlyformembersoftheconsortium(includingtheCommissionServices)

Ref. Ares(2016)7203402 - 31/12/2016

ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies

Project:I-REACT Report on Technical Requirements and Overall System Architecture

DeliverableID:D2.7

GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:2of60

Preparedby Reviewedby Approvedby

C.Rossietal. C.Rossi,F.Dominici F.Dominici

Issue Date Description Author(s)

3.0 29/12/2016 Finalreview C.Rossi,F.Dominici

2.0 15/12/2016 Integrationofcontributionsafter

reviewattheDesignReview

L.Lopez,Ç.Mete,N.Martínez,

J.Sánchez,S.Tadic,A.Bosca,

F.Tarasconi,M.Velluto,M.

Ballerini,C.Bielski,V.Maggio,

A.Alikadic,W.Stemberger,F.

Girtler,V.Macchia,L.Bruno,

A.Ragucci,G.Audino,I.

Porras,J.MariaSolé,G.Zeug,

V.Naeimi.

1.0 16/12/2016 Integrationofcontributionsfrom

partnersforDesignReview

L.Lopez,Ç.Mete,N.Martínez,

J.Sánchez,S.Tadic,A.Bosca,

F.Tarasconi,M.Velluto,M.

Ballerini,C.Bielski,V.Maggio,

A.Alikadic,W.Stemberger,F.

Girtler,V.Macchia,L.Bruno,

A.Ragucci,G.Audino,I.

Porras,J.MariaSolé,G.Zeug,

V.Naeimi.

0.5 28/10/2016 First content of the deliverable to

collectcontributionsfrompartners

C.Rossi

0.1 26/10/2016 Firsttableofcontent C.Rossi



DeliverableID:D2.7


TABLEOFCONTENTS1 INTRODUCTION...........................................................................................................................6

1.1 PurposeoftheDocument....................................................................................................7

1.2 StructureoftheDocument..................................................................................................7

1.3 Acronymslist.......................................................................................................................8

1.4 Referenceandapplicabledocuments.................................................................................9

2 EXECUTIVESUMMARIES...........................................................................................................10

2.1 Multi-HazardRequirements..............................................................................................10

2.2 Report on Users and Stakeholders Requirement Analysis, Operational Procedures,

Processes,Scenarios&End-usersRequirements.........................................................................14

2.3 ReportonDesignoftheBigDataArchitecture,LinkedData&SemanticStructure.........18

2.4 ReportonPrivacyandSecurity..........................................................................................20

2.5 ReportonGamificationandEngagement.........................................................................21

2.6 ReportonDesignofDataInterface...................................................................................23

3 FEASIBILITYCONSIDERATIONS..................................................................................................25

4 OVERALLSYSTEMARCHITECTURE............................................................................................26

4.1 ArchitectureoftheI-REACTORbackend............................................................................27

4.2 FrameworkSelectionfortheI-REACTORfrontendandtheMobileApplication...............28

4.2.1 ArchitectureoftheI-REACTORfrontend......................................................................31

4.2.2 ArchitectureoftheMobileApp....................................................................................33

4.3 ArchitectureofDecisionSupportSystemEngine..............................................................34

4.4 ArchitectureSmartGlasses................................................................................................35

4.5 ArchitectureofWearablePositioningDevice....................................................................37

4.6 ArchitectureoftheAugmentationModule.......................................................................38

4.7 ArchitectureofEMSIntegrationModule..........................................................................39

4.8 ArchitectureoftheSentinel-1DataProcessing.................................................................40

4.9 Architectureoftheseasonalforecastmodeldataintegration..........................................42

4.10 Architectureoftheclimatechangemodeldataintegration........................................43

4.11 Architectureofthefireweatherindexmodeldataintegration...................................44

4.12 Architectureoftheweatherforecastmodeldataintegration.....................................45



DeliverableID:D2.7


4.13 ArchitectureofForecastingandNowcastingServicesforFloodandFireDisasters.....45

4.13.1 ForecastingFloodandFireHazards..........................................................................46

4.13.2 NowcastingFloodandFireHazards.........................................................................47

4.14 ArchitectureoftheIn-SituWaterMonitoringSystem.................................................49

4.15 ArchitectureoftheUAVDataServicesviaASIGN&ASMIRA.......................................50

4.16 ArchitectureofExistingLocalEmergencyManagementSystems................................51

4.17 ArchitectureofSocialMediaDataEngine....................................................................53

4.18 FinalArchitecturalDiagram..........................................................................................54

5 TECHNICALREQUIREMENTS.....................................................................................................56

LISTOFFIGURESFigure1-1:WP2approach..................................................................................................................6

Figure1-2:TasksanddeliverablesdependenciesinWP2..................................................................7

Figure2-1:SchemaofI-REACTcontributioninthedifferentDRMphasesfornaturalhazards.......13

Figure2-2Rankingbasedongoal,typeofinformationandchannel...............................................16

Figure2-3Contentstructureofdatarequiredfromthefield..........................................................17

Figure2-4Responsesketchscanlayout...........................................................................................17

Figure2-5:I-REACTDataArchitecture.............................................................................................19

Figure2-6-OverallschemeoftheI-REACTgamificationstrategy...................................................22

Figure2-7:ArchitecturalviewoftheIDIcomponentasintegratedwiththeI-REACTDataLayer...23

Figure2-8CommunicationDiagramfortheprocessthatsendsdatatotheI-REACTDataLayer...23

Figure2-9CommunicationDiagramfortheprocesstogetdatafromtheI-REACTDataLayer......24

Figure3-1:I-REACTreferenceArchitecture.....................................................................................27

Figure3-2:I-REACTORBackendsoftwarearchitecture....................................................................27

Figure3-3:TrendsofGooglesearchesofkeytermsassociatedtotheframeworksanalysed........29

Figure3-4:I-REACTFront-endsoftwarearchitecture......................................................................31

Figure3-5:I-REACTFront-endsoftwarearchitecture......................................................................31

Figure3-6:I-REACTcross-platformmobileapplicationsoftwareachitecture.................................33

Figure3-7:DSSmacroarchitecture..................................................................................................34



DeliverableID:D2.7


Figure3-8:Preliminarycomparisonanalysisofcommerciallyavailablestereoscopicsmartglassesfor

AR.....................................................................................................................................................36

Figure3-9:I-REACTWearablepositiongdevicesoftwareachitecture/interfaces...........................37

Figure3-10:Detailedorganizationofwearabledevicefirmware–preliminaryversion.................38

Figure3-11:MainsoftwarecomponentsandflowsoftheAugmentationmodule.........................39

Figure3-12:ConceptualsystemarchitectureofEMSintegrationmodule......................................40

Figure3-13:TheSentineldataprocessingandproductgenerationarchitecture............................42

Figure3-14:SeasonalForecastmodeldatasystemarchitecture.....................................................43

Figure3-15:ClimateChangemodeldatasystemarchitecture........................................................44

Figure3-16:FireWeatherIndexmodeldatasystemarchitecture..................................................44

Figure3-17:Weatherforecastmodeldatasystemarchitecture.....................................................45

Figure3-18:Thefireandfloodforecastarchitecture.Notethatsimilarinputdataisusedhowever

theforecastmodelsdiffer................................................................................................................46

Figure3-19:Thefireandfloodnowcastarchitecture......................................................................48

Figure3-20:Systemarchitectureoverviewforin-situwatermonitoring........................................49

Figure3-21:SystemarchitectureforI-REACT–ASIGNsystemsforUAVDataServices....................50

Figure3-22-Scenario1–directdataintegrationfromexistingsources.........................................51

Figure3-23-Gateway:architecturaldesignschema.......................................................................52

Figure3-24-Scenario2–Connectionthroughamediationcomponentforrealtimestreamsand

RESTAPIs..........................................................................................................................................52

Figure3-25SocialMediaDataEngineArchitecture.........................................................................54

Figure3-25:NewOverallI-REACTarchitecturediagram.................................................................55

LISTOFTABLETable2-2-1:Actionsmappedwith respect to theemergencymanagementphasesand themain

operationconceptoftheontology..................................................................................................11

Table2-2Enduser’srequirementdescription.................................................................................18

Table2-3Requirements(Priority/Type)...........................................................................................18

Table2-4Requirements(Priority/Touchpoint)...............................................................................18

Table3-1:PrioritizationofrequirementswithoutpriorityinD2.2..................................................26



DeliverableID:D2.7


Table4-1:ComparisonamongthemostwidelyusedJavaScriptframeworks.................................30

Table5-1:Initiallistoftechnicalrequirements................................................................................56

Table5-2:DetailKPIsforweatherforecasts....................................................................................58

Table5-3:DetailedKPIforfireandfloodnowcastandforecastmodel...........................................58

Table5-4:DetailedKPIsforriskmaps..............................................................................................58

Table5-5:DetailedKPIsforsocialmediamodels.............................................................................58

Table5-6:DetailKPIsforseasonalclimateandclimatechangemodels..........................................59

1 INTRODUCTION

Thisdeliverablegathers theoutcomesofallpreviousactivitiesanddeliverables ([RD02], [RD03],

[RD04],[RD05],[RD06],[RD07]),andcomplementsthembyaddingamoredetailedoverallsystem

architectureandpreliminarytechnicalrequirements.Thelatterwillbefinalizedtogetherwithall

usecasesandsystemprocessesduringthetechnicalWPs,namely“WP3–ExternalServicesand

DataIntegration”,“WP4–ModellingandEngines”,and“WP5–ServiceOrientedArchitecture”.

InWP2,theactivitiesofalltaskshavebeenstructuredwithapreliminaryanalysisthatwasfollowed

bytheInternationalUserRequirementWorkshop(IURW),throughwhichtheI-REACTconsortium

gatheredmanyinputsanddesignrecommendationsfromboththeend-userpanelandtheAdvisory

Board.TheoutcomesofIURWcomplementedthepreliminaryanalysis,allowingthefinalizationof

theWP tasks and of the associated deliverables. Figure 1-1 and Figure 1-2 show the approach

followed in the WP and the dependencies among tasks and deliverables, respectively. This

deliverable,togetherwiththeDataManagementPlan,isthefinaloutcomeofWP2.

Figure1-1:WP2approach



DeliverableID:D2.7


Figure1-2:TasksanddeliverablesdependenciesinWP2

1.1 PURPOSEOFTHEDOCUMENT

ThemaingoalofthisdocumentistofinalizetheoveralldesignactivityofWP2,andgiveasolidbasis

forthedetailedanalysisandtheimplementationthatwillberealizedinthesubsequenttechnical

WPs.Specifically,thisdeliverableaimsto:

1. Summarize through executive summaries the key outcomes of the previous WP2

deliverables;

2. Definetheoverallsystemarchitecture,highlightingitsmaincomponentsandfunctionalities;

3. Definetheinitiallistsoftechnicalrequirements.

1.2 STRUCTUREOFTHEDOCUMENT

Thedocumentisorganizedasinthefollowing:

• Chapter1isthisintroductionanddescriptionofthedocumentitself;

• Chapter2outlinestheexecutivesummariesofpreviousWP2deliverables;

• Chapter 3 contains feasibility considerations taking into account the collected userrequirementsalongwiththetimeandbudgetconstraints;

• Chapter4definestheoverallsystemarchitecture,detailingthearchitectureofallmainI-

REACTsystemcomponents;

• Chapter5listtheinitialtechnicalrequirements.



DeliverableID:D2.7


1.3 ACRONYMSLIST

AM AugmentationModule AOI AreaofInterest API ApplicationProgramInterface AR AugmentedReality BT Bluetooth DEM DigitalElevationModel DOM DocumentObjectModel DoW DescriptionofWork DR DesignReview DSS DecisionSupportSystem DTO DataTransferObject EBIOS ExpressiondesBesoinsetIdentificationdesObjectifsdeSécurité ECMWF EuropeanCentreforMedium-RangeWeatherForecasts EDAS EGNOSDataAccessService EGNOS TheEuropeanGeostationaryNavigationOverlayService EMS EmergencyManagementSystem EO EarthObservation

EODC EarthObservationDataCentre ESA EuropeanSpaceAgency EU EuropeanUnion

FTP FileTransferProtocol FWI FireWeatherIndex GDPR GeneralDataProtectionRegulation GIVE GridIonosphericVerticalErrorIndicator GIS GeographicInformationSystem GNSS GlobalNavigationSatelliteSystem GPS GlobalPositioningSystem HPL HorizontalProtectionLevel HTTP HypertextTransferProtocol IDI I-REACTDataInterface IGP IonosphericGridPoints IURW InternationalUserRequirementWorkshop JSON JavascriptObjectNotation JSON-LD JSONforLinkedData MDA Mechanics,DynamicsandAesthetics NMME North-AmericanMulti-ModelEnsemble ORM ObjectRelationalMapper OSM OpenStreetMap PVT Position,velocity,Time RDF ResourceDescriptionFramework REST Representationalstatetransfer RSS RichSiteSummary SAR SyntheticApertureRadar SDK SoftwareDevelopmentKit SIDP ScienceIntegrationanddevelopmentPlatform SPA SinglePageApplication SQL StructuredQueryLanguage ToW TimeofWeek UAV UnmannedAerialVehicles UI UserInterface



DeliverableID:D2.7


1.4 REFERENCEANDAPPLICABLEDOCUMENTS

ID Title Revision Date

[RD01] I-REACTProjectproposal:GrantAgreement–Annex1

- 16/03/2016

[RD02] D2.1ReportonMultiHazardrequirementanalysis

2.0 17/10/2016

[RD03]

D2.2 Report on Users and Stakeholders requirement

analysis, operational procedures, processes and

scenarios

2.0

17/10/2016

[RD04]

D2.3Reportondesignof theBigDataArchitecture, Linked

Data&SemanticStructure

1.0

10/10/2016

[RD05] D2.4ReportonPrivacyandSecurity

[RD06] D2.5ReportonGamificationandEngagement

[RD07] D2.6ReportodDesignofDataInterfaces

[RD08]

Jae-Gil Lee,Minseo Kang, “Geospatial BigData: Challenges

and Opportunities,” Big Data Research, Volume 2, Issue 2,

June2015,Pages74-81,ISSN2214-5796,2015.

[RD09]

MicrosoftSQLServer

https://www.microsoft.com/en-us/cloud-platform/sql-

server

[RD10]

ApacheSpark

http://spark.apache.org/



DeliverableID:D2.7


2 EXECUTIVESUMMARIES

Theaimofthischapteristobrieflyrecapthemainoutcomesofpreviousdeliverablessubmitted

withintheWP2.Itcontainsonesectionofeachdeliverable.

2.1 MULTI-HAZARDREQUIREMENTS

TheDeliverable2.1-ReportonMultiHazardrequirementanalysis-containsfourmainchapters

followedbytheoverallconclusions,assummarizedbelow.

Multi-riskapproach

I-REACTwillsupporttheconcurrentmanagementofmultiplehazardhappeningsimultaneouslyorinclosesuccession.I-REACTwillsegregatethedataflowsbyhazardandtime,andwillbeableto

handleparallelflowsofdatainreal-timefromallsupportedsources.TheI-REACTriskapproachaims

tocharacteriseitstoolsandservicesaccordingtothefollowingcriteria:

• Focusonconsolidatedriskmanagementpracticesthatarerecognizedamongpublicauthorities;

• Focusonhazardsforwhichtheoccurrencecanbepredictedinduetime,toalertexposedpeople

andtoactivateresponseoperations;

• Focus on hazards with high expected impact, e.g. fatalities, injuries, economic loss,

environmentalimpact.

SelectionofI-REACTfocusedhazards

I-REACTaimstotacklethemostfrequentandimpactinghazardsintheEU.EUstatisticsforeach

hazardwereanalysed inorder toprioritize them.Theextremeweather (storm,windstorm)and

climate(extremetemperature,drought,wildfire)driveneventsaccountedfor90%oftotalreported

disasters,andforaround82%ofthetotaldamagesoccurredovertheperiod1980-2013,intheEU

MemberStates1

.Floodisthemajorhazardintermsoftotaleconomicdamage,followedbystorms,

whilethedeadliesthazardisextremetemperature,followedbyearthquakeandflood.Wildfiresare

less impacting (ranking fourth in affected people), however there is a growing concern due to

climatechange,whichisdrivinguptemperaturesandincreasingwildfirerisk.Thewildfiresseason

isgettinglongerandfiresareprojectedtoscorchmorelandastemperaturecontinuetorise.Climate

changeeffectsincludingextremeweatherevents,suchasheavystormsandheatwaves,donotonly

driveupfloodsandfires,buttheyalsorepresentapossibletriggerforothernaturalhazards,such

asavalanches,landslidesanddroughts.

I-REACTfocusesonthefollowinghazards:floods,wildfiresandextremeweatherevents,including

stormsandextremetemperatures(heatwaves)

This is due both to the technologies and the approaches proposed within the I-REACT project

[RD01],alongwiththegiventheexpertiseoftheconsortiatedpartners.

1

EM-DAT,2016



DeliverableID:D2.7


I-REACT focus hazards were analysed inmore detail with respect to their phenomenology and

statisticsattheEUlevel.Foreachhazardtheemergencymanagementprocessisbrieflyanalysed

basedonthepastknowledgeoftheconsortiumpartners,includingrecommendationshighlighted

intheoutcomesofpreviousEUprojects.Thisin-depthanalysismappedthesolutionsprovidedby

different ICT tools for each hazard using the I-REACT platform throughout the emergency

managementcycle.

InlinewiththeDoW,droughts,landslidesandearthquakes,wereconsideredassecondaryI-REACT

targetsandtheywillnotbefullyaddressedintheproject.However,somefunctionalitieswillbe

designedtobeeasilyextendabletothemaswell.

I-REACTtechnologiesservingforfocusedhazards

ForfocushazardsI-REACTtechnologicalsolutionsweremapped.Targetedusersweredifferentiated

intotwogroups,namelycitizensandpublicauthorities.Thelatterincludesfirstresponders(decision

makersandin-fieldagents),aswellasanyothernational,regional,andlocalpublicentitiesinvolved

intheemergencymanagement.

I-REACTpossibleactionsfordifferentemergencymanagementphasesweredefined.Thelistofmain

actionsisreportedinTable2-2-1below.Someactionsincludemorethanoneitem:theconceptof

“Information Sharing” includes several actions (“Self-protection Information”, “RiskAwareness”,

and“Forecast/Nowcast”),while“DataCollection”includes“DamageReport”aswell.Someactions

couldbeperformedindifferentphases:“ForecastandNowcast”appearsboth inthePrevention

and in the Response phases, while “Risk Awareness” is associated with both Prevention and

Preparedness.

Table2-2-1:Actionsmappedwithrespecttotheemergencymanagementphasesandthemainoperationconceptoftheontology

Phase Actions MainOperation

(ontology)

Prevention Self-protectionBehaviors

RiskAwareness

InformationSharing

Preparedness(EarlyWarning) RiskAwareness

Forecast/Nowcast

InformationSharing

Preparedness(EarlyWarning) Warning Warning

Preparedness(EarlyWarning) DataCollection DataCollection

Response Forecast/Nowcast InformationSharing

Response OperationalManagement OperationalManagement

Response Alert Alert

Response DataCollection DataCollection

Post-Event DamageReport DataCollection



DeliverableID:D2.7


ThefollowingfivemaintypesofICTtechnologies,summarizedinFigure2-1,wouldbeusedwithin

I-REACTsystem:

1. Mobile Applications have the widest impact because they allow to define and develop

communicationtools thatcanbeuseful ineveryhazard,andeveryphaseofdisaster risk

management. The great flexibility of such applications with respect to design and

functionalitiesallowstheiruseforbothusergroups(PublicAuthoritiesandCitizens).

2. Socialmediawillhaveagreatimpactaswell.Theirimpressivediffusion,oftenencouraged

by thewide spread expansion ofmobile technologies,makes them a primary source to

extractusefulinformationandtodisseminateriskawarenessinformationthatcaninduce

virtuous behavior in population, especially in the Prevention and Preparedness phases.

Moreover,duringemergencyresponsetheycanprovidetimelyinformationthatencourage

self-protectivebehaviors.So,theywillhaveanimportantroleinsupportPublicAuthorities

andCitizensineveryriskmanagementphase.Weexcludetheuseofmobileapplicationsand

socialmediatocollectdamagereportsrelatedtoinfrastructuresforheatwaves,because

thishazarddoesnotaffectsuchstructures.Citizenswillcommunicatethroughthem,giving

information to assess emergency situations and damages.Public Authoritieswill receiveunstructuredstreamsfromsocialmedia,filterthem(e.g.usingsemanticanalysis)inorder

toobtainactionabledata.

3. Wearable devices will be mostly used by Public Authorities to coordinate operational

management or to transmit more technical in-field reports to timely assess emergency

situationsordamages.Theywillbeimportantinalmostallrisksandmacroactions.

4. Inorderto improvetheforecastandnowcastofhigh-impactweatherevents,mapsfrom

remotesensingwillbeusedbothfromexistingsystems(CopernicusEMS)andfromadirect

datachainfeaturingfastdatatransferandcommunication.Suchmapswillbedirectlyused

mostlybyPublicAuthorities,buttheywillbepropagatedalsotocitizensaccordingtothe

policyindicatedbytheauthorities.Themapsaremainlyaimedatimprovingriskawareness

andforecast/nowcast.


Project:I-REACT Report on Technical Requirements and Overall System Architecture DeliverableID:D2.7GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:13of60

Figure2-1:SchemaofI-REACTcontributioninthedifferentDRMphasesfornaturalhazards

ThecolorcodeofFigure2-1isreportedbelow:

EXTREMEWEATHERFIREFLOODHEATWAVES

DATACOLLECTION

POSTEMERGENCY

DAMAGEREPORTS

PUBLICAUTHORITIES CITIZENS


SELFPROTECTIONBEHAVIOURS

PREVENTION


OPERATIONALMANGEMENT



RESPONSEPREPAREDNESS(EARLYWARNING)


RISKAWARENESS FORECAST/NOWCAST WARNING&ALERTING

CITIZENS

Remotesensingdataandtools:collectedfromsatellitesMobileApplication:generalapplicationssuitableforinformationsharingandin-fieldreportingWearabledevices:smartglassesandbandusedforprofessionalin-fieldreportingandpositioningSocialmedia:toolsandmethodsthatallowinformationgatheringfromsocialmediaanddiffusiontroughthemUAVMapping:toolsthatcollectandbroadcastproperlyimages,dvideosandmapsfromUAVs



DeliverableID:D2.7


I-REACTcontributionsforotherhazards

Giventheimportanceofdroughts,landslides,andearthquakes,theI-REACTsystemwillimplement

somededicatedfunctionalities.Specifically,thecrowdsourcingservice(reporting)willsupportthese

kindof events, allowingbothPublic authorities andCitizens to reporton theoccurrenceof the

event,aswellasontheobserveddamages.Moreover,theCopernicusEMSactivationsrelatedto

this hazard group will also be embedded in the system. Produced maps will be ingested and

complemented with (i) in-field reports from the I-REACT application and with (ii) social media

streams. The social media algorithms for event detection and filtering will be tested on these

hazardsandincludedintheI-REACTsolution,underconditionthattheyperformeffectively.

The extremeweather detection could be usedwithin themanagement of any kind ofweather

relatedhazards,landslidesincluded,whiletheclimatechangemapsproducedbyI-REACTcouldbe

usedasinputsforlongtermriskassessmentofdroughts.Nowcastandforecastriskmapswillnot

beproducedforthisgroupofhazards.

2.2 REPORTONUSERSANDSTAKEHOLDERSREQUIREMENTANALYSIS,OPERATIONAL

PROCEDURES,PROCESSES,SCENARIOS&END-USERSREQUIREMENTS

The Deliverable 2.2 - Report on Users and Stakeholders Requirement Analysis, Operational

Procedures,Processes,Scenarios&End-usersRequirementscontains:

• adescriptionofthemethodologyweusedtoidentifyanddescribe,inasharedway,thepossible

requirementsfromEuropeanendusersconcerningthedevelopmentofIREACTproducts;

• theresultsobtained.

Methodology

To achieve the results,we used three different tools. They allowedus to harvest requirements

comingbothfromtechnicalconstraintsandtheemergencymanagementdomain:anonlinesurvey,

agapanalysis(focusedonprocesses)andaco-designsession(focusedonmobilesolutionsprovided

by the project). The latter two activities have been carried out during the International Users

RequirementsWorkshop(IURW),inParis.

Consideringthegreatcomplexityofthistask,firstofallwedecidedtodefineaframeworkaimedto

generalisethespecificneedscomingfromtheexpertsandstakeholdersinvolved,inordertocover

in an exhaustive way, all the processes that can be improved by exploiting the available ICT

capabilities.Theframeworkhasbeendevelopedbydefininganontology.

Outcomes

a) Ontology

Theontologyprovided:



DeliverableID:D2.7


• a set of shared definitions concerning high level concepts and instances (this is essential in

projectscharacterizedbymultipleapproaches,likeI-REACT);

• Thebasicconceptsthatmakeupageneralprocessaimedatcreateandcommunicatedataand

informationtosupportthedifferentriskmanagementphases;

• Atooltoformaliseandorganiseallthecollectedinformationfromtheend-usersandexpertsin

thedomainofdisastermanagement(Gapanalysis);

• Theelementsthatweusedtodefinedifferentscenariosduringtheco-designsessioninParis.

b) GapAnalysis

Theend-user requirementsare composedbymany typesofdifferentprocesses thatoperateat

differenttimesinthevariousDisasterRiskManagementcyclephases.

Forthisreason,itwasincorrecttobegintodefineavalidprocessforeveryone,butitwasnecessary

tocollectawidernumberofdifferentprocessesinorderto:

• comparethem;

• assesstheirimportanceandlevelofimplementation;

• understandhowtheycanbeimprovedthroughmethodsandtoolsproducedbyI-REACT.

Toachievethisgoal,duringtheInternationalUsersRequirementWorkshopinParis,theend-users

wereaskedtoprovidetheinformationrequiredbyincludingtheminapredefinedstructure:the

processes schema. This scheme was created in order to allow end-user to describe the main

processesthatcharacterizetheirriskmanagementactivities,usingacommonlanguageincluding

some ' basics ', derived from the Ontology, which can be combined to describe their specific

processes and their improvement areas. The diagram below shows the ranking of processes

assessedaccordingtodifferentvariables.Itreferstoprocessesfreelyprovidedbyendusers.



DeliverableID:D2.7


Figure2-2Rankingbasedongoal,typeofinformationandchannel

c) Co-designsession

Theco-designactivitieshavebeensplitintwophases:

1. Datascouting:aimedatcollect,defineandprioritizethedatafromthefieldabletosupport

theDRMprocess.Asshown inFigure2-3, thedataanalysishighlightedrelevantclusters,

interconnectionsanddifferentweightsofallthecollectedinformation,thatweorganizedin

twomainblocks:

a. WHOissendingthereport-Reporterstatusb. WHATinformationdoyouhavetotransmit-Real-timeData



DeliverableID:D2.7


Figure2-3Contentstructureofdatarequiredfromthefield

TheReportSketching:"Sketching”ofamobilesolutionforthedatacollectionfromthefield,inorder

toprovidesuggestions for thedesignand the implementationof the I-REACTmobileapp.Every

groupreceivedataskscenario (10differentworkgroupshavebeenactivated). InFigure2-4we

reportthreesketchesprovidedforResponsescenarios.

Figure2-4Responsesketchscanlayout

d) Finalrequirements

Theend-users’ surveyandgapanalysis,plus the co-design session jointly realizedbyend-users,

advisors, and the I-REACT team, lead to the definition of a comprehensive requirements list of

requirements,thathavecategorizedon:Type;Topic;Priority;Possibletouchpoints(seeTable2-2).



DeliverableID:D2.7


Type Topic Requirementdescription PriorityPossible

Touchpoints

Functional

Operational

Management

Implementation of command and control

features(setupamission,assigntoateam,

monitortheprogressofthemission)

Might

Web based DSS,

Mobile App,

SmartGlasses

Table2-2Enduser’srequirementdescription

Table2-3andTable2-4summarizethefinalrequirementsobtained.

PriorityType

Functional Notfunctional Performance Total

Must 52 14 3 69

Should 46 6 1 53

Might 26 3 1 30

notdefined 6 6

Total 124 29 5 158

Table2-3Requirements(Priority/Type)

Touchpoints

Priority Webbased

DSS

MobileApp Smart

Glasses

Wearable

band

UAV Social

Media

Chatbot

Must 31 40 14 3 3 0 6

Should 25 34 6 3 1 1 2

Might 15 19 5 2 1 0 6

NotDefined 1 1 0 0 0 0 1

Total 72 94 25 8 5 1 15

Table2-4Requirements(Priority/Touchpoint)

2.3 REPORTONDESIGNOFTHEBIGDATAARCHITECTURE,LINKEDDATA&SEMANTIC

STRUCTURE

Deliverable D2.3 [RD04] contains the analysis of the related work on Big Data Frameworks,

GeospatialDatabasesandLinkeddataandSematicStructures.Basedontheanalysisoftherelated

work,andtherequirementsoftheI-REACTproject,theBigDataArchitectureandtheSemanticand

LinkedDataLayerhavebeendesigned.Figure2-5reportstheschemaofthedesignedarchitecture,

whichisdescribedindetailinthedeliverableD2.3[RD04].Inthefollowing,themainfeaturesofthe

designedarchitecturearediscussed.



DeliverableID:D2.7


Figure2-5:I-REACTDataArchitecture

BigDataArchitecture

TheBigDataArchitectureofI-REACT,analogouslytothestate-of-the-artsolutions[RD08],isbased

ontwomainbuildingblocks:(i)anOperational/Onlineblockand(ii)anAnalytics/Offlineblock.The

twocomponentsoftheproposedarchitectureaddressdifferentneedsofI-REACT:(i)nearreal-time

responseand(ii)historicalpossibly-complexanalyses.Specifically,theOperational/Onlineblockis

usedtostoreandquery“operational”data, i.e.,data thatarequeried toanswernear real-time

requests.Differently,theAnalytics/Offlineblockisusedtostorehistoricaldataperformcomplex

dataanalyticsoperationsonthem.ThetwoblockssupportcomplementaryusecasesofI-REACT.

To deal with near real-time queries, managed by the Operational/Online block, a geospatial

database has been selected. Differently, the Analytics/Offline block is based on a Big data

framework.Specifically,basedontheperformedqualitativecomparisonoftheavailabledatabases

andbigdataframeworks,wedecidedthatthe implementationoftheBigDataArchitecturethat

bestfitstherequirementsofI-REACTisbasedonAzureSQLDatabasefortheOperational/Online

buildingblock[RD09]andSpark[RD10]fortheAnalytics/Offlineone.

Amongtheseveralconsideredspatialdatabases,weselectedAzureSQLDatabaseforthefollowing

motivations:

• AzureSQLDatabaseprovidesadvancedfeaturesforgeospatialqueries.

• AzureSQLDatabaseiscompatibleandtightlyintegratedwiththeGeoServersoftware

• AzureSQLDatabaseisprovidedasaservice

FortheAnalytics/OfflineblockweselectedSparkbecauseitisefficientandisthede-factostandard

forbigdataanalyticssolutions.Moreover,geospatiallibrariesforSparkarealsoavailable,whichis

anindispensablefeaturesincethedatamanagedbyI-REACTaregeolocalized.

Semantic&LinkedDataLayer

EnrichingI-REACTdatawithexistingLinkedData,suchasgeographicordemographicdata,couldbe

extremely inproviding contextual informationuseful inorder tobetterprevent and respond to



DeliverableID:D2.7


disastersandcrises,forinstancebyenhancinglocationinformationwiththepopulationnumbersor

the presence of specific building (i.e. hospitals, schools, train stations, ...) in area where an

emergencyeventisoccurring.

The“SemanticandLinkedDataLayer”Block(seeFigure2-5)hasthreemaintaskstoperform:

• exposing the information collected in thedatabase as LinkedData, either for presenting

selectedpartsofitontheweborforfurtherprocessingandanalysisbytheBusinessLayer

(i.e.tobeprocessedbystandardsemantictoolsoringestedinatriplestoreforinference

purposes)

• providingsemanticsearchfunctionalities(e.g.searchingforallUserReportsreferencinga

FloodHazardEvent-thussearchingforagivenconceptanditssubtypes,inthiscaseCoastal

Flood,FlashFloodandRiverineFlood)

• facilitating the linking between I-REACT data stored in the database and the contextual

informationstoredintheRDFtriplestore(bothatingestiontimeandatquerytime)

AnOntologyhasbeendevelopedinI-REACTforrepresentingtypes,propertiesandvaluesofthe

datastoredI-REACTBigDataArchitecture(bothforofflineandonlinebuildingblocks)inorderto

expose it as Linked Data. The developed Ontology draws inspiration from existing semantic

resourcesinthedomainofemergencyresponse,adaptingthemtothespecificcontextofI-REACT

(inparticulartheMOAContologyandEMDATclassificationforwhatconcernsHazardandDamage

types) aswell as fromprocesses and concepts emerged from I-REACTWorkshopholdon14-15

September2016,inParis,atUNESCOheadquarters(detailedinI-REACTDeliverableD2.2)forwhat

concernstheCommunicationProcess,theRiskManagementandtheExchangedInformation.

I-REACTarchitecturewillincludeaRDFtriplestoreforhostingtheI-REACTontologyandacopyof

theLinkedDatasourcesthathasbeenidentifiedasrelevantcontextualinformationforenrichingI-

REACTdata.ThetechnologicalsolutionidentifiedforI-REACTRDFtriplestoreisVirtuososinceitis

availableasanOpenSourcecomponent,presentson theaveragethebestperformancesacross

differentbenchmarks(andsupportsGeoSPARQL).MoreoverVirtuosoisthetriplestoreadoptedby

LinkedGeoData for its online demo, the Linked Data with the richer andmore complex spatial

informationamongthedatasetsselectedforenrichingI-REACTdata.,theLinkedDatawiththericher

andmorecomplexspatialinformationamongthedatasetsselectedforenrichingI-REACTdata.

2.4 REPORTONPRIVACYANDSECURITY

InD2.4amethodologytoembedprivacyanddataprotectionintheoverallsystemdesignhasbeen

defined. The selected approach, namely EBIOS (Expression des Besoins et Identification des

Objectifs de Sécurité), is aprivacy-by-designmethodologywhich is compliantwith theprinciple

expressedintheGeneralDataProtectionRegulation(GDPR).EBIOSisbasedonriskassessmentand

aimsatdefiningthequantitativeorqualitativevalueofapotentialriskrelatedtoasetofconcrete

events(orthreats).Thegoalofthemethodologyistoidentifyasetcountermeasureontheprimary

assets (data) and the secondary assets (software/architectural components) to mitigate the

potentialriskonprivacyandprotectionofpersonalinformation.InI-REACT,thefocusoftheanalysis



DeliverableID:D2.7


isonpersonalandlocationdatatransmittedbycitizen,volunteerandfirstrespondersthroughthe

Reports generated via smart devices. At the end of this process, several technological

countermeasures have been identified to be included in the system design to assure personal

privacy:

• Measuresonprimaryassets(data):

o Non-disclosureofpersonalandlocationdata

o Dataanonymizationandpseudonymisation

o Dataminimization

o Imageobjectsdetectionandblurring

• Measuresonthesecondaryassets(I-REACTarchitecture):

o Administration

o AuthenticationandPerimeterSecurity

o Authorization-Restrictedaccesstodataandreportinformation

o Securecommunicationanddatatransfer

o Databackupandrecovery

o Securedatastorage

o Audit

Thisanalysishasbeenperformedatveryearlystageoftheprojectexecution,advisingonasetof

countermeasure for privacy risk mitigation that should be applied on the entire system

implementation.Forthisreason,wouldkeyfactorforthesuccessofthismethodologytoiteratethis

process in order to have a constant check over the validity of the proposed Privacy-by-Design

approach, in anticipation of any possible changes in the system design driven by technical or

architecturalneeds/choices.

2.5 REPORTONGAMIFICATIONANDENGAGEMENT

Thegamificationhasbeen identifiedas core strategy toengage the targetend-users into the I-

REACTprocess. Inparticular, the I-REACTgamificationstrategy(describe inD2.5[RD06])aimsat

fostering and supporting the citizen involvement and engagement toward topics related to the

environmentalobservation,riskawareness,cooperationandactiveenvironmentalsurveillance.The

I-REACTgamification strategyassignsanactive role to thecitizens that, adequatelyhookedand

informed,cancontributetothecrisismanagementprocess,fromthepreventiontothepost-event,

byperformingreal-timereportingandbypromotingself-protectionbehaviours.Thegoalsofthe

gamificationaremanifold:

• Toraisepeople’sinterestandawarenessonenvironmentalrisks;

• To provide information on environmental risks to the population, adapting the official

sourcesforthemobiledevicesandcontextsofuse;

• Tostimulatethecrowdsourcing,trainingactivecitizenstocollectreliableandusefuldatafromthefield,abletocomplementthetechnologybasedmonitoring.



DeliverableID:D2.7


• To implement a reliable and redundant process of validation of the data collected,sotobeeffectivelyusefulforthedecisionmakers/crisisoperationmanagers.

Inordertoreachthesegoals,theI-REACTstrategy(Figure2-6)leveragesonboththesocialnetworks

andthemobileapp.Inparticular,theactionsonthesocialnetworkswillsupporttheonboardingof

thecitizensandtheirparticipation.Themobileappwillbetheenvironmentwherethecitizenswill

act.Aprogressivepathhasbeendesigned,inordertodrivethepersonfromanentrylevel,based

ontheinformationandtrainingonthemostimportantconceptsonenvironmentalrisksandcorrect

behaviours,toamoreactiverole,basedonthereportingandthevalidationoftheothercitizens’

reports.

Thispath isarticulatedintoastrategy,designedaccordingtotheMDAapproach2,thereference

method forgamifyingservices. It impliesdifferentelements: theCompetences that theappwilltrainandrewardtotheusers,thetraceableActivitiestobeperformedbyusers;aRewardSystem

consisting of Points, Achievements, which are progressively gained, and Awards, which are

periodicallyassigned.ThestrategyalsospecifiesthePlayerScorecomputeonthebaseofallthe

Pointsgainedfromcompetences,Achievements,andAwards.Finally,aleaderboardwillrepresent

theprogressesapplyingspecificBadgesassociatedtoeachAchievementandeachAward.

Figure2-6-OverallschemeoftheI-REACTgamificationstrategy

2MDAstandsforMechanics,DynamicsandAesthetics,accordingtoHunicke,etal.(2004).



DeliverableID:D2.7


2.6 REPORTONDESIGNOFDATAINTERFACE

TheI-REACTDataInterface(IDI)hasbeendefinedintermsoftwoseparatecomponents:asoftware

module,andanassociateddataformat.Theformeriscomposedbyaseriesofmultipleadapters,

eachofwhichisusedtoextractdataandmetadatafromthedataformatsathand,accordingly.On

the other hand, the defined data format specifies the format that has to be used in the

communicationprotocolbetweenexternalI-REACTmodulesandservicesfordataexchange.Inthis

scenario,theIDIseeminglyintegrateswiththeI-REACTDataLayer(seeFigure2-5andFigure2-7),

acting either as a broker for communication to and from the data layer with external I-REACT

services,andasamediatorforboththeOfflineandOnlineStorage.Thisroleisfurtheremphasized

inthecommunicationdiagramsreportedinFigure2-8andFigure2-9.

Figure2-7:ArchitecturalviewoftheIDIcomponentasintegratedwiththeI-REACTDataLayer

Figure2-8CommunicationDiagramfortheprocessthatsendsdatatotheI-REACTDataLayer

IDIComponent

I-React Data Layer

Offline DB "Big Data Lake" (HDFS) Online DB

(Relational)

EntityRelation

Entity

Entity

I-REACTExternal module 1

I-REACTExternal module n

I-REACTExternal module 2

an I-REACT External Service

I-REACT Data Web Service

IDI

1: send request to store data into the I-REACT Data Layer

send actual binary files/data and metadata (e.g. original_format) wrapped into a unique JSON object formatted according to the IDI Data Format

issue a POST HTTP request with multipart/encoding

2: send the JSON object and binary file to the IDI

I-REACTOnline Storage

3: process metadata and binary file(s); instantiate proper adapters (for format) and extract data and metadata

I-REACTOffline Storage

IDI DataObject

4: Save original file into the I-REACT Data Lake

6: Save data into the online storage

5: format data and metadata according to the Online storage schema

{"@context":"ireact.azurewebsites.net/context.jsonld","meta":{

"source":"UKEnvironmentAgency","licence":"http://nationalarchive.co.UK/v/3","version":"0.1","has_format":[“netcdf”,“csv”],"original_format":[“netcdf”,],“privacy”:“public”,“access_level”:“no-restriction”,“hazard_type”:“flood”,“report_type”:“flooding-hazard-daily-report”},"data":[“filename”:“flood_report_area_1.nc”,“filename”:“flood_report_area_2.nc”,“filename”:“flood_report_area_3.nc”,“filename”:“flood_report_area_4.nc”,]}}

example



DeliverableID:D2.7


Inmoredetails,Figure3-3describetheprocessofanexternalI-REACTservicewhichisgoingtosend

data(inbinaryformat)totheI-REACTDataLayer. Inthisscenario,theexternalserviceissuesan

HTTPPOSTrequesttotheI-REACTDataWebService-i.e.aRESTfulendpointspecificallysetupto

receivedatafromexternalservices.Inthisexample,therequestcontainsaseriesofbinaryfilessent

overthenetworkwithamultipart/encodingrequest,alongwithcorrespondingmetadata.These

metadataaresentbytheexternalserviceintheIDIformat,andhavethepurposetocomplement

anddescribecorrespondingdata.OncedataandmetadataareprovidedtotheIDI,properadapters

aretriggered.Theseadaptersembedthespecificrulesandalgorithmsrequiredtomanipulatedata

andmetadatafromspecificdataformat.The IDImodule instructsthedifferentadapterssothat

rulesandconditionstogetthedataarespecified.Then,eachadapterselectsandfetchesthedata

tobestoredintothedatastorage.

Ontheotherhand,incaseanexternalserviceaskstheI-REACTDataLayerforspecificdata(Figure

2-8andFigure2-9),theIDIisresponsibletofetchthedatafromthe(online)storage,andtransforms

obtainedresultsintotheIDIdefinedformattoenablethedataexchangeprocess.

The formatdefinedby the IDI isbasedon JSON.This JSON format is flexibleenough tosupport

dynamic data schemas,which is necessary to support heterogeneous data inmultiple formats.

Moreover,theJSONextensionsforgeospatialandlinkeddata,namelyGeoJSONandJSON-LDwould

supporttheexchangeofdatafromexternalsourcesandthesemanticdata layer.Finally,aREST

styleaccesstothedata(viasimpleHTTP(s)requests)canbeenabled,evenifdiversedataformats

areinvolvedintheprocessing.

Figure2-9CommunicationDiagramfortheprocesstogetdatafromtheI-REACTDataLayer

an I-REACT External Service

I-REACT Data Web Service

IDI

1: send request to get data from the I-REACT Data Layer

Specific endpoints will be setup for the data to be available for services

issue a GET HTTP request

2: forward the request to the IDI

3: get the data from the Online Storage

I-REACTOnline Storage

5: send the JSON data object back to the Web Service

4: format data and metadata according to the IDI format JSON schema

6: forward the JSON data object to the requestingservice

direct connection orby means of a data brokerservice



DeliverableID:D2.7


3 FEASIBILITYCONSIDERATIONS

The full list of end-user requirements has been included in [RD03], where a priority has been

assignedtoeachrequirement,namelyMust,Should,andMight.However,forsomeofthemthis

prioritizationwasnotcompleted,anditisreportedinTable3-1.

Duetothehighnumber(151)ofrequirementsandthedurationofthetechnicalWPs(18months),

notallShouldandMightrequirementswillbeimplemented.AlltheMustrequirementswillbefullyimplemented,andtheir implementationwill start fromthe firstAgilecycle.TheShouldandthe

Might requirements will be gradually introduced starting from the second and third, cycle,

respectively.Thisprioritizationschemewillguaranteethatthemostimportantrequirementswillbe

morelikely implemented.Atpresent, it isestimatethatthe60%andthe30%oftheShouldand

Mightrequirementwillbeimplemented,respectively.

Afteradeeperanalysisoftherequirementlist,somecriticalitiesemerged,themainofwhichare

commentedbelow:

• In-field report and its submission process: from one side, it is required a high level of

completeness,butfromtheothersideitiscrucialtoimplementasimple,easytouseprocess

abletoallowautomaticinterpretation,validationandvisualizationwhileavoidingsubjective

reportingandmistakes.ThesubsequentanalysisinWP5,willdesignthecontentofthein-

field report taking intoaccountall theaforementionedaspects inorder to find the right

trade-off between completeness and actionability of this information source in the

emergencycontext.

• Burnedareaextent:thecomputationandtheconsequentvisualizationoftheburnedarea

extent after a fire will be possible only if the collected information will allow its

determination.

• Dustandwaterproofingofpositioningwearabledevice:thedecisionaboutthedustandwaterproofingofthewearabledevicewillbefinalizedinWP5consideringthetechnological

constrainsimposedbythesensorsthatwillbeincludedinthedevice.

• Communicationwithcitizens:theI-REACTsystemwillinitiallycontainalistofinformation

aimedatimprovingtheawarenessontherisksbroughtbynaturalhazardsandatfostering

self-protectionbehavior.However,itislefttothedecisionmakerthepossibilitytomodify

andcomplementsuchlistthroughthefrontend(WebBasedDSS).Thesystemwillallowto

communicate to citizens through themobileapplicationand the socialmedia,proposing

contents,buttheactualinformationdelivered,includingwarningsandalerts,willbedecided

bythedecisionmakersinordertorespectthe“onevoiceprinciple”.

Whentwoormorerequirementswillbefoundtobeintotalorpartialcontrastwitheachother,a

furtheranalysiswillbecarriedoutinordertodecidewhattoimplement.

ThefeasibilityanalysisoftheoperationalprocessesandprocedureshavebeencarriedoutinTask

2.3.Asaresult,19pre-definedprocesseshavebeendefinedandevaluatedduringtheIURW.Atthe

same time, the end-users have been asked to identify additional processes to be implemented



DeliverableID:D2.7


within I-REACT.Thepre-definedprocesseswillbeconsideredasMust requirements,while theadditionalonesasMight.

Table3-1:PrioritizationofrequirementswithoutpriorityinD2.2

ID Type Topic Requirementdescription Priority PossibleTouchpoints

101 NotfunctionalReporting&Data

Collection

Supportfirstrespondersintheuseof

mobileappsthroughspecifictrainingShould

111 Functional Models

Tovalidateforecastmodels,allow

usersonthegroundtoreportthe

presenceandtheextentoftheevent

ShouldMobileApps,

Chatbot,Smart

Glasses

112 Functional Validation

InMobilereportsfromcitizensa

validationmechanismismandatory

inordertousetheprovided

informationformodelupdates

Should MobileApps,

Chatbot

113 FunctionalReporting&Data

Collection

Defineapreferredstructuretoget

informationfromsocialmedia

accordingtothehazardandthe

emergencyphase(e.g.safetycheck)

Should SocialMedia

114 FunctionalReporting&Data

Collection

Implementanautomaticfiltering

algorithmtoexclude(orlimit)the

amountofnotrelatedornot

informativecontentfetchedbythe

systemfromsocialmedia

Must WebbasedDSS

115 NotFunctionalOperational

management

Useofwearabledevicestotransmit

moretechnicalin-fieldreports

withoutreducingtheoperational

capabilityoffirstresponders

Must

4 OVERALLSYSTEMARCHITECTURE

StartingfromthereferencearchitecturereportedintheDoW[RD01]andshowninFigure4-1,and

giventhedataarchitecturedefinedin[RD04],thedatasourceslistedandtheI-REACTDataInterface

(IDI)definedin[RD07],thissectionoutlineseacharchitecturalblock inordertodrawthefinal I-

REACToverallarchitecture.Amoredetaileddescriptionofthecontentofeachprocessingblockwill

begiveninthedeliverablesofthetechnicalWPs.



DeliverableID:D2.7


Figure4-1:I-REACTreferenceArchitecture

4.1 ARCHITECTUREOFTHEI-REACTORBACKEND

Thissectiondetailsthesoftwarestackoftheback-end,complementingthearchitecturedefinedin

[RD04].

Figure4-2:I-REACTORBackendsoftwarearchitecture

The project is based on amulti-tier architecture. Thismeans that presentation, application

processing and data management functions are logically separated into loosely coupled



DeliverableID:D2.7


modules, so that they can be edited or replaced without affecting others. In addition, this

stratificationallowstoreducecomplexityandtoimprovecodereusability.

ASP.NETBoilerplate,theframeworkASP.NETZeroisbasedon,respectsthispatternbyfollowing

theprinciplesofDomainDrivenDesign.Inparticular,thesolutioncanbesubdividedintofourlayers:

• PresentationLayer:it’sthehighestleveloftheapplicationanditcancommunicatewiththe

businesslayer.ItcontainsthedefinitionoftheDTOs,thatareobjectsthatwillbeusedfor

theinteractionbetweenclientandserver,andtheservicesofferedbytheapplication.

• Business Layer: acts as an intermediary between Presentation and Data layers. It can

manageobjectderivingfromlowerlayers.

• DataLayer: includesbusinessobjectsandtheirrules.Itrepresentsthecentralpartoftheapplicationbecause it contains thedefinitionofobjects calledEntities.Theseareusually

mappedwiththedatastoredinthedatabase.Moreover,itcontainsthedefinitionofsome

interfacesimplementedintheInfrastructurelayer,suchasRepositoriesandUnitofWork.

Whatmatters is thatthis layershouldbe independentofthird-party librariesasmuchas

possible.

• InfrastructureLayer:itstaskistoabstractawaydependenciesonthird-partylibrariesfrom

theotherlayers.ItprovidestheimplementationsoftheinterfacesdefinedintheDatalayer.

Finally,ASP.NETBoilerplatehasabuilt-inintegrationwithEntityFramework,thatistheORM,

providedby.NETFramework,usedtoimplementrepositories.Thiscomponentallowstowork

withahigherlevelofabstractionandtomaintaindata-orientedapplication.

4.2 FRAMEWORK SELECTION FOR THE I-REACTOR FRONTEND AND THE MOBILE

APPLICATION

A comparison (see Table 4-1) among the most actively used state-of-the-art JavaScript

frameworks wasmade in order to choose themost suitable for developing the I-REACTOR

frontendandmobileapplication.GoogletrendsprovidedtheresultsshowninFigure3.3,which

showsthatFacebookReactnowadaysisthemostgoogledamongnewestfrontendframeworks,

followedbyAngularJS(v1.x).

ThefigurealsoreportscomparisonwithXamarin(whichisamobile-only,.NET-basedapplication

developmentframework)andAngularv2.x,whichwasreleasedoutofbetaonlyrecently.

Thus,consideringthatAngular1.xhasreportedsomeperformanceissuesonmobiledevicesand

it is targeted for obsolescence given the fact that a new major release has been recently

published,thechoicewasmadeonReactJS,whichexploitstheredux-fluxdesignpatternand

hasproventobeveryefficientforbothlargeandsmallapplicationsonbothmobileanddesktop

environments.Theredux-fluxpatternisaspecificversionoftheone-way-flowpattern.



DeliverableID:D2.7


Furthermore,theReactJSdevelopers’communityisverylargeandthereisgoodsupportand

maintainability.

ReactJS actually is only the presentation layer of a React-Redux application, thus regarding

mainlytheuserinterfaceandrouting.ThepointofstrengthofReactisthatitsmodules,called

component, are designed for maximizing reusability, while performance are boosted by

manipulating an optimized shadow DOM instead of accessing the actual DOM directly,

propagating only necessary UI mutations. More details can be found on the React official

website3.

TheothercomponentofaReact-ReduxapplicationsisRedux,whichcontrolsandmodelsthe

application state and how statemutations are propagated to the views using the so-called

providers.Reduxpatternisaspecificimplementationofthefluxpattern,whichinturnbelongs

tothefamilyoftheone-way-flowpatterns.

Redux thus controls how data are accessed, represented andmutated in the app state by

describinghowdata sourceshave tobe integrated into theapp state. The stateof aRedux

application is saved to a single store, which may also be serialized, and it is created by

composition of the connected Redux modules. More details can be found on the Redux

documentation4.

Asaresultofthisanalysis,theReact+Reduxsolutionischosen.

Figure4-3:TrendsofGooglesearchesofkeytermsassociatedtotheframeworksanalysed

3https://facebook.github.io/react/

4http://redux.js.org/



Table4-1:ComparisonamongthemostwidelyusedJavaScriptframeworks

FrameworkComparison

Xamarin Angular1 Angular2 REACT+REDUX

Highcodereuse LowcodeNotpossibletodowebapp,hencenocodereusebetweenwebappand mobile. Possible reuse of someclassesbetweenbackendandmobile

Notfreeforcommercialapp

Potentially high, if wellstructured and if mobile appwithIonic1.0(Cordova-based).

MVCpattern

Component based, high reusability.Compatibility between web and mobilewith Ionic2 (Cordova-based).Still inbeta(preview).Moreresearchneeded.

OneWayFlowpattern

Reduxcodecanbesharedbetweenwebandmobileapp.Reactcodeis incompatiblewithReact-Native(since RN uses native UI components), butComponentscanbeusedonmobileonaCordova-basedapp.

OneWayFlowpattern(Flux/Redux)

Maturity,documentation,support

Mature, is around the internet sincesomeyears.RecentlytheXamarin IDEwasembeddedintoVisualStudio,alsoforMac(Beta)

Mature,createdbyGoogle,verywelldocumented

Out of beta since September 15, 2016.Good documentation, but not asmatureastheotherframeworks.

Verymature,usedinproductionbybigcompanieslike Netflix, Facebook, Yahoo, Microsoft. WelldocumentedandsupportedbyFacebook.

Performance Good,comparablewithReactNative good, but worse thanReact/Angular2 due to two-waysdatabinding

does not support well mobilebrowsers

Verygoodperformance,comparablewithReact.

optimizedformobile

Verygood,probablythefastestwithsupportbybigcompanies. Even more performant (and mostlycompatible)solutionsincludeInfernoandPreact.

supportformobileisexcellent

Modularity andmaintainability

It’sC#.Modularitystronglydependsonpattern.

Baseonmodulesandwritteninjavascript. Not sure aboutmaintainability due toobsolescence

Based on typescript, which is differentfromjavascript(higherlearningcurve)

Modularbydefinition,codecaneasilybesplitandworkcanbedividedamongteams.

Futurelookout Microsoft bought it recently, so it islikelytoseeitaroundforthenextyearsAppealing for .NET dev community.Interestnotgrowing

once the traffic levels of thedocumentation for Angular 2overtakes Angular 1.x, supportwilldecline

Will increment to Angular 3-4-5 but willstillbemaintainedforalongtime(link)

Interestisslowlyincreasing

Highutilization,willbemaintainedforalongtime.Strongincreaseininterest

Preference None

webappnotpossible

Low

due to performance andobsolescence

Mid

butIonic2stillinbeta

High



DeliverableID:D2.7


4.2.1 ARCHITECTUREOFTHEI-REACTORFRONTENDFigure4-4andFigure4-5describestheoverallarchitectureoftheI-REACTORfrontend.

Figure4-4:I-REACTFront-endsoftwarearchitecture

Figure4-5:I-REACTFront-endsoftwarearchitecture

The I-REACTOR Frontend will be developed as Single Page Application (SPA) using a JavaScript

Frameworkwhichwillallownavigationbytheuseofacomponentcalledrouter,andthesitewillbe

dividedinreusablecomponentswhosedatawillberetrievedbyservicesthatfetchinformationfrom

different sources likeexternalAPIor theapplicationBackendasOAuth2.0 clientover a secure

channel (https). The frontend will expose specific views for the data to be displayed, using a

responsiveapproach.

The frontend will be accessible through any modern browser with JavaScript enabled. For a

complete list of the officially supported browsers and their versions, please refer to Section 5

(TechnicalRequirements).

Theredux-fluxpatternestablishesaunidirectionaldataflowwithasinglestorefortheapplication

state.Thisensuresthattheviewswillalwaysrespectthechangesoftheappstate,whicharefired

by actions. Actions can be related to UI interactions or other events. This allows to separate

presentation from abstract representation of the app state, while boosting performances and

simplifyingcomponentreusabilityandscopeisolation.



DeliverableID:D2.7


TheselectedReact-Reduxdesignallowstoseparateviewrenderingfromappstaterepresentation,

writingbetterorganizedandmoremaintainableandreusablecode.Themaincomponentsofthis

architectureare:

• ActionCreators:thesefunctionsdefinewhichactionaredispatchedinreactiontoeventssuch as user interaction, network, system or sensor events. Action Creators can be

synchronousorasynchronous.InordertocommunicatewiththeI-REACTORbackend,Action

CreatorswilltakeadvantageoftheWebAPImodule.

• Dispatcher: depending on the triggered Action Creators, the dispatcher has the task ofpropagatingeventsthatmutatetheappstate.SinceReduxcontemplatesasinglestorefor

theappstate,alltheactions,definedasplainobjects,aredispatchedbythiscentralstore.

• State:itencapsulatesthestateoftheapplicationanditisread-only,inthesensethatneitherviewsnornetworkcallscandirectlymanipulateit.Thewaythestatecanmutateisdefined

throughsocalled“reducers”,whicharepurefunctionsthatgiventhecurrentstateandan

action, return thenext state. It canbe thought in termsofaFiniteStateMachine (FSM)

whosestatesareacompositionofeachmodulestates,andreducersareacompositionof

eachmodulereducers,exploitingmodularityandreusability.Eachmodule thusdefinesa

portionoftheappstatethatiscombinedtotheotherportionsandstoredintothesingle

store.Thestateisthereforeahierarchicalobjecttreewhichservesassinglesourceoftruth.

• ReactViews:roughlycorrespondingtotheVoftheclassicMVCpattern,ReactViewsare

madeofreusablecomponentsthatonlyrenderaportionofthecurrentappstate,whichis

propagated by mean of immutable properties in a hierarchical way. User Interface (UI)

interactionsarethenpropagatedtotheappstatebycallingtheActionCreators,thatwill

update the app state and finally propagate to the interested view components, when

needed.

Thefrontendwillincludeanadditionalmodule,i.e.,theWebAPIUtils.Itwillbetaskedtoactasaliaisonwiththebackend,managingallinteractions,bothinboundandoutbound.

Whiletheproposedarchitectureisverysimilarforbothfrontendandmobileapp,eachoneofthese

will implementspecificmodulesandviewcomponentstocopewithitsownpeculiarities.Onthe

otherhand, all effortswill bemade for sharing commonmodules and view componentswhere

possible.



DeliverableID:D2.7


4.2.2 ARCHITECTUREOFTHEMOBILEAPP

Figure4-6illustratestheproposedarchitecturefortheI-REACTmobileapp.

Figure4-6:I-REACTcross-platformmobileapplicationsoftwareachitecture

TheproposedarchitectureleveragesthehybriddevelopmentapproachusingtheApacheCordova

Framework,whichallowtousebothHTML5/JavaScriptAPIforcommontasks,businesslogicandUI,

andnativeplatformlibraryforaccessingdevice-specificAPIsuchasthoseforaccessingsensors.

AhybridapplicationisanapplicationthatencapsulatesanHTML5/JavaScriptapplicationinaweb

view,thatisasystemclassthatexposesanHTMLDOMsimilarlytoawebbrowser.Awebviewcan

belinkedtoanyclassofthetargetplatformSDK,soitispossibleto“bridge”webcoderunningin

thewebviewwithothersystemfeatures.

ApacheCordovaisapopularframeworkthatimplementsthiskindofbridgingforseveralplatforms,

bothmobileanddesktop,inawaythatthesamecodecanrunondifferentnativeplatformswith

noneorminoradjustments.Therefore,requiringnoneorlittleknowledgeoftheunderlyingtarget

platforms, Cordova has become quickly very popular among developers with good web

development skills, or in situationswhere the sameapphas tobedeployedondifferent target

platforms.

ApacheCordovafirstreleasedatesbackin2009anditwasproprietaryanditwasnamedPhoneGap.

In2011 itwasboughtbyAdobeSystemandreleased itsOSSversionasApacheCordovaforthe

ApacheSoftwareFoundation.

Even though the first releasesof the framework sufferedof a consistentperformancegapwith

respect to native development, evolvements in the web view technology and implementation

nowadaysallowauserexperiencewhichisundistinguishablefromtheapplicationsdevelopedwith

nativeSDKsinmostofthecases,elevatingCordovatoanIndustrystandard.Thepointofstrength

oftheCordovaplatformarecodereusabilityandflexibility,thankstotheHTML5DOMAPIandthe

JavaScriptlanguage.

Cordova incudesapluginsystemthatallowtoextendthe featuresetofahybridapplicationby

accessingonlythesystemfeaturesthatareneeded,suchassensors,camera,filesystemetc.



DeliverableID:D2.7


Eventhoughthere isasolidbaseofofficiallysupportedpluginsforthemostlyusedfeatures,by

leveragingtheOSSdevelopers’community,itispossibletopickfromaverylargesetofpluginsand

features,ordevelopacustompluginforthosefewfeaturesthatarenotyetavailable.

Thehostedwebapplication isalmost independent fromApacheCordovaandcanbedeveloped

using standard web development techniques, attaching to the system events exposed by the

Cordovaplatformandpluginsabstractionlayer.Basically,anythingthatcanruninabrowsercan

runinApacheCordova.

Onthebasisofthesepremises,theproposedarchitecturefortheI-REACT,willenablesharingpart

of the code with the I-REACTOR frontend (section 3.2), especially those classes dealing with

authentication,datamodelsandRESTAPIs(businesslogic).

TheUI(views)willhoweverbeadaptivewiththetargetmobiledevices,incompliancewitheach

targetplatformdevelopmentguidelines.ThisispossiblebyselectingaproperUIHTML5framework

thatadapttheUIwidgettotheplatformwhereisbeingrun,suchasOnsenUI.

ThelistoftheofficiallysupportedmobileplatformsandtheirversionsfortheI-REACTapplicationis

reportedinSection5(TechnicalRequirements).

4.3 ARCHITECTUREOFDECISIONSUPPORTSYSTEMENGINE

The DSS is a Decision Support System that integrates a rule-based system aimed at providing

suggestionsthatcouldhelpdecisionmakersinmanagingtherisksassociatedtoemergencyevents.

AsshowninFigure4-7,ithasamultilevelarchitecturewhosegatewayistheIREACTORDataWeb

Services layer to receive triggers. These triggers are stored in amessage queue to avoid losing

receivedevents.ThismessagequeuefeedstheDSSEngine.

TheDSSEnginecontainstheruleengineandcommunicatewiththeBigDatalayer.Itconnectswith

thedatabasesystemtostoreandretrievinginformation.

Figure4-7:DSSmacroarchitecture



DeliverableID:D2.7


4.4 ARCHITECTURESMARTGLASSES

Figure4-5illustratedtheproposedarchitecturefortheI-REACTSmartGlasses.

Figure4-5:I-REACTSmartGlassessoftwareachitecture

IthasnotyetbeendecidedtheSmartGlassesdevicethatwillbeusedfortheproject,thechoiceis

betweenEpsonMoverioandMicrosoftHololens,thefirstareusingAndroidOSwhileHololensare

usingWindows10.NativeplatformAPIwillbeusedfordevelopment.

Thedevicemust:

• RetrievethelocationeitherthoughtheintegratedGPSorviathewearablepositioning

device

• Havesensorslikegyroscopeandaccelerometer;

• Havethecapabilitytounderstandvocalcommands;

• Beusableinoutdoorenvironmentwithoutdisruptthenormalviewandin-fieldagent

capabilities;

• enoughdatastoragethatwillbeusedtostorethedataacquiredonfield;

AcquireddataisstoredatfirstontheSmartGlassesthen,sharedthroughI-REACTOR.Thisapproach

guaranteethepossibilityofacquiredataalsoifInternetconnectivityisnotavailable,andsharethem

whenconnectivitywillbeavailableagain.SmartGlasseswillreceiveInternetconnectivitythrough

tetheringprovidedbyamobiledevice.

When Smart Glasses App is launched the procedures that retrieve real-time notifications,

contextualizeddataandpositionofother teamsare initiatedandtheappstart tocommunicate

directlywithI-REACTORexchangingdatainaJSONstandard.Theexchangeddataarestoredina

databaselinkedtoI-REACTOR.

CurrentlythedevicesavailableinthemarketinEuropeareveryfew,andtheyarestillnotmature

inordertobeadopted inoperationalactivitiesrelatedwithemergencyresponse.However, it is

expectedthatmoremodelswillbecommercializedinthenearfuturewithmoreenhancedfeatures

andusability.

ThefinalselectionofthesmartglassmodelforI-REACTwillbemadebyFebruary2017.Apreliminary

comparisonstudyisreportedbelow.



SmartGlasses EpsonMoverioBT-200 EpsonMoverioBT-2200 EpsonMoverioBT-300 MicrosoftHololens

Wearabilty

Customcorrectivelensescanbeattachedthroughtheincludedaccessory

Theviewerislinkedtoacontrollerthatneedstobestoredinsomepocketorbeltcase

Createdtocopewithextremeindustrialsituations[IP54(Resistenzaapolvereeschizzid’acqua),Shockresistant(cadutada1,2mt),ANSIZ87.1/EN166]

Bestfitwithaprotectivehelmet

Theviewerislinkedtoabulkycontrollerthatneedstobestoredinsomepocketorbeltcase

Thedistancefromlensesmakeitdifficultforsomepeopletofocusthedisplay

Thinnestmodel,allowsagoodwearabilityandit’ssuitableforanytypeofheadgear

Customcorrectivelensescanbeattachedthroughtheincludedaccessory

Theviewerislinkedtoacontrollerthatneedstobestoredinsomepocketorbeltcase

Heaviestmodelbutthepossibleadjustmentsallowaperfectfitwithoutstrainingtheuser

It’spossibletowearthemtogetherwiththesafetyequipment

Correctiveglassescanbewornunderit

Interface

Smallerfieldofview(23°)

Displayresolution:960x540px

Manualcalibrationisneededtoprovideagoodstereoscopicexperience

WiFi,BluetoothandGPS


Displayresolution:960x540px




Displayresolution:1280x720px(HD)



Widerfieldofview(30°)

Displayresolution:�1268x720px

Beststereoscopicexperience

WiFiandBluetooth,noGPS

Interaction

Controller:touchpad+7actionbuttons

Voicecommandrecognitioncanbedeveloped(microphoneneeded)

Controller:directionalbuttons+7actionbuttons

Build-invoicecommandrecognition(40commands)

Controller:directionaltouchpad+7actionbuttons

Voicecommandrecognitioncanbedeveloped(microphoneneeded)

Build-inhandgesturerecognition

Build-invoicecommandrecognition

Preference None Mid Low Mid

Figure4-8:PreliminarycomparisonanalysisofcommerciallyavailablestereoscopicsmartglassesforAR



DeliverableID:D2.7


4.5 ARCHITECTUREOFWEARABLEPOSITIONINGDEVICE

Figure4-9illustratestheproposedarchitecturefortheI-REACTWearablepositioningdevice.

GNSSRAWDATA SENSORDATA

PACKETFORMING/MESSAGEQUEUE

MOBILEAPPLICATION

ACTIVITYDETECTION

OTHERPROCESSES:mainprocess,powersaving,Bluetoothcontrol

I-REACTOR

WEARABLEDEVICE

Bluetoothconnectivity

Figure4-9:I-REACTWearablepositiongdevicesoftwareachitecture/interfaces

TheproposedarchitectureshowshowWearablepositioningdevicesoftwareisdirectlyconnected

tothemobileAppthroughBluetoothdirectconnection.Mainfunctionalitiesofwearabledevicewill

includestreamingofGNSS rawpositioningdataandsensordata (environmentalandpotentially

activitydata) tomobile application.Protocol fordataexchangewill beagreed in furtherdesign

steps,withgoaltoenablerobustandfastoperationofothertasksofI-REACTmobileapplication.

Moredetailsonpreliminaryfirmwareorganizationofwearablepositioningdevicearedepictedin

Figure4-10.Asprocessofselectionofallelectroniccomponentsisnotfinalizedyet,finaldecision

ontheexactfirmwareorganizationwillbedoneinfurthersteps.Oneofthemainwearabledevice

designrequirementsisverylowpowerconsumptionandhighautonomywithsmallandlightweight

battery. Consequentially, wearable device will be based on one of themicrocontroller families

withoutmemorymanagementunits,andfirmwarewillbebuiltusingeithersocalled“bare-metal”

(noOS)approachorusingappropriateoperatingsystemsuchasFreeRTOS.“Bare-metal”approach

islessflexibleandusuallyhardertobuild,butmorestableandmorepredictiveinfield-use.Main

processeswillinclude:

• BTcontrolprocess–initializesBluetoothcommunicationwithmobileapplication.

• Communicationprocess–communicationwithmobileapplication.

• GNSS/positioningprocess–collectsmeasurementsfromGNSSmodule

• Sensors/algorithmsprocess–collectssensordataandoptionallydetectsactivity.

• Firmwareupdateprocess(optional)–checkslocalrepositoryonmobileapplicationandupdates

all applications to the newest version. Alternatively, this may be resolved via USB-based

firmwareupdate.

• MainorcoreprocessusesBluetoothstatusdata,GNSSmoduledata,powerdatatocreatestatus

messages.



DeliverableID:D2.7


• Dedicatedlocal“databases”willbeusedforstoringinformationsuchasstatusmessages,and

bufferingmessagesformobileapplication.

Firmware update process

GNSS/Positioning

process

Main process

Status message database

Message queue/buffer

Communication process

BT control process

Sensors/algorithms

process

Figure4-10:Detailedorganizationofwearabledevicefirmware–preliminaryversion

4.6 ARCHITECTUREOFTHEAUGMENTATIONMODULE

TheAugmentationModule(AM)willbeimplementedfollowingthesamearchitecturalpatternof

theI-REACTORback-end,whichisreportedinFigure4-2.

Thecloud-basedaugmentationservicecomputestheimprovedPositionVelocityTime(PVT)vector

and the Horizontal Protection Level (HPL or PL). The service gets the GNSS raw data and the

associatedtime,expressedusingtheTimeofWeekformat(TOW)fromtheuserrequest,retrieves

thecorrespondingEDASdataformtheAzureTable,appliesthecorrections,andcomputesthePVT

usingtheLeastMeanSquare(LMS)estimator,andtheHPL.TheAMcorrectsthepseudorangesfor

eachGPSsatelliteincludedintherawdata,excludingthepseudorangesforsatellitesdeclaredasDo

NotUseandNotMonitoredbyEGNOS.ThemostimportantcorrectionsappliedbytheAMtoobtain

thePVTare:

• Fastcorrections,usedtocompensateshort-termdisturbancesintheGPSsignals,generally

due to satellite clocks errors: these are applied to the pseudorange measurements

performedbytheGNSSreceiver;

• Long-termcorrections,usedtocompensateforthelonger-termdriftinsatelliteclocksand

theerrorsinthebroadcastsatelliteorbits:theseareappliedtothepositionofthesatellites

ascomputedusingthebroadcastedephemerisdecodedbytheGNSSreceiver;

• Ionosphericcorrections,providedasGridIonosphericVerticalErrorIndicator(GIVE)values

correspondingunivocallytothepointsbelongingtoaregionspecificsetofIonosphericGrid

Points(IGP).Fromthemtheuserreceivercandetermineaslantcorrectiontobeappliedon

eachpseudorangemeasurementtocompensateforthedelayexperiencedbythesignalas

itpassesthroughtheionosphere.



DeliverableID:D2.7


AuserwhowantstoperformapositionaugmentationandvalidationneedstocalltheRESTfulweb

servicesexposedbytheAM,passingasparameterstheTOW,andtherawdatacomingfromthe

GNSS receiver. After validating the request, theAM retrieves the required data from the cloud

storageandperformsboththeaugmentationandthevalidationalgorithms,returningtheimproved

PVTandtheHPLtotheuser.Theoverallprocessofacquiringthedataandprovidingtheserviceis

sketchedinFigure4-11

AM

EDAS

Decoder

Aug.DataEphClock

AzureStorage

ServiceSelection

SL2

I-REACTORbackend

ParseData

ComputePVTandlocalintegrity

GetEDASdata

Applycorrections

RawDataTOW

PVTPLs

AM

EDAS

Decoder

Aug.DataEphClock

AzureStorage

ServiceSelection

SL2

I-REACTORbackend

ParseData

ComputePVTandlocalintegrity

GetEDASdata

Applycorrections

RawDataTOW

PVTPLs

Figure4-11:MainsoftwarecomponentsandflowsoftheAugmentationmodule

4.7 ARCHITECTUREOFEMSINTEGRATIONMODULE

TheEMS Integrationmodule consists of twopiecesof software: the EMSController and theGI

Processor.Themodulehasonemaindatainputsource,whichistheCopernicusEMSwebsite,and

a single data destination,which is the I-REACTOR. The key responsibilities of the two software

componentsareasfollows:

• TheEMSController shall recognise the availability of newgeodataon the EMSwebsite,

detectandnotifyabouterrorsingeodatahandlingaswellasalerttheI-REACTORe.g.about

newEMSactivations.

• TheGeoinformationProcessor(“GIProcessor”)will takecareofgeodataacquisitionandprocessing.

Figure4-12showstheconceptualarchitectureoftheEMSIntegrationModule,whichissubjectto

minorchangesduringtheimplementation.



DeliverableID:D2.7


Figure4-12:ConceptualsystemarchitectureofEMSintegrationmodule

IndetailtheEMSControllershalltakecareofthefollowingtasks:

• ImmediatelyrecognisetheavailabilityofnewEMSactivationsbymonitoringtheRSSfeeds

oftheEMSwebsiteandalerttheEventDetectionModuleoftheI-REACTORincaseofnew

activations

• ImmediatelyrecognisetheavailabilityofnewgeodataonEMSwebsiteandinitiatethedata

downloadtroughtheGIProcessor

• Recognise failed downloads and re-initiate newdownloads; in case of unsuccessful data

downloadstheDSSoftheI-REACTORshallbeinformed

• InformtheI-REACTORincaseofsuccessfuldataprocessing

• SendprocessedgeodatatoIDIorasbackupsolution(e.g.incaseofnon-availabilityofIDI)

directlytothegeospatialdatabasewithintheI-REACTORbackend

TheGIProcessorwillinparticularlytakeoverthefollowingduties:

• Conduct download of all geodata available on EMS website related to floods, storm,

earthquake,industrialaccidentsandfire(RapidmappingandRisk&Recoverymapping)

• Harmonisation of collected data by carrying out dedicated GIS processing steps like

reprojecting,geometrycleaning,renaming,formatconversionetc.

4.8 ARCHITECTUREOFTHESENTINEL-1DATAPROCESSING

In frameof I-REACTproject, theSentinel-1(S-1)dataprocessing chain for floodmappingwill be

implementedwithinavirtualmachinehostedbytheEarthObservationDataCentre(EODC).The

processingchainanddataflowincludesfollowingstepsasillustratedinFigure4-13.

• Dataacquisition:thedataacquiredbythesatellitesisdownlinkedtothecollaborativeground

segmentfromwhereviaESAnetworkitisbeingdistributedtoothersourceslikeScientificHub

andESAServerZAMG(ZentralanstaltfürMeteorologieundGeodynamik).FromZAMG,datais



DeliverableID:D2.7


pushedtonationalmirrorandthentotheEODC(EarthObservationDataCentre)datastorage.

IthasthecompletearchiveoftheENVISATASAR,coveringthelifespanofthemissionfrom2005

to 2012, and acquires regularly the S-1A&B data. The S-1 data at the EODCwarehouse are

currently available approximately2.5hours after the initial signalprocessingbyESA (level-1

product)and6.25hoursaftertheacquisition.TheS-1level-1dataarearchivedonfastdiscsand

backedupusingarobotictapelibraryonaregularbasis.

• Floodmappingprocessor:ThefloodmappingalgorithmisbeingdevelopedbyTUWienandwill

be implementedwithin a virtualmachine at Science Integration and development Platform

(SIDP) hosted by EODC. The processing chain includes pre-processing of the SAR data, data

qualitycontrols,floodmapping,andnecessarypost-processingsteps.TheSIDPisalsoconnect

totheViennaScientificClusterwithmorethan2000computingnodeswhichmightbeusedfor

heavyprocessingtasksthatneedparallelprocessing.Thefinalproductswillbefloodandflood

frequencymaps.Duringtheprojectlifetime,thefloodmappingprocessorwillberuniteratively

overthehistoricalEnvisatASARWSandS-1IWGRDproductsovertheselectedtestareasto

improvealgorithmaccuracy.

• Serviceonrequest:thisservicewillbeestablishedduringtheprojectlifetimetoproviderapid

postdisasterfloodingstatusandinundationextentmaps,whichcanbeusedforpost-disaster

management and relief activities. In this service the user/customer would contact TUWien

throughI-REACTcoordination(e.g.viaEmail)totriggertheproductgeneration.Therequested

productcanbedeliveredviaFTPserverorown-clouddependingonthesizeoftheproduct.In

practical terms the monitoring/status service over a defined location can be triggered and

stoppedbyanemailnotification.



DeliverableID:D2.7


Figure4-13:TheSentineldataprocessingandproductgenerationarchitecture.

4.9 ARCHITECTUREOFTHESEASONALFORECASTMODELDATAINTEGRATION

TheSystemArchitecture(Figure4-14)ofseasonalmodeliscomposedoftwomainblocks:DataInput

andDataAnalysis.Data Inputconsistsofcollectionofmodeldataandobservations.Ontheone

hand,modeldataconsistsoftheNorth-AmericanMulti-ModelEnsemble(NMME)whichprovides

seasonalhindcastsandforecastsina9monthstimehorizon.Ontheotherhand,realobservations

will be collected based on Reanalysis (such as CFSR and ERA-Interim if available), satellite

observations (GPCP for precipitation and E-OBS for temperature) and local or national climate

networks.

DataAnalysisconsistoftwosteps:firstly,theskillofNMMEhindcastandtheaddedvalueagainst

climatologywillbeanalyzedforEuropearea.Afterthisanalysis,anESDapproachwillbeappliedto

downscaleEuropeanforecasttosub-regionsinmorespatialdetail.Asaresult,seasonalforecastwill

beprovidedforEuropeandforsub-regionsintermsofanomaliesandprobabilities.



DeliverableID:D2.7


Figure4-14:SeasonalForecastmodeldatasystemarchitecture.

4.10 ARCHITECTUREOFTHECLIMATECHANGEMODELDATAINTEGRATION

ClimateChangeSystemArchitecture(Figure4-15)iscomposedoftwomainblocks:DataInputand

DataAnalysis.DataInputconsistsofcollectionofmodeldataandobservations.Ontheonehand,

model data consists of the CMIP5 globalmodels and CORDEXRegionalModels,which provides

climatehindcastsoverthelastdecadesandclimateprojectionsupto2100inmonthlyanddailytime

bases forprecipitationand temperature.On theotherhand, real observationswill be collected

basedonReanalysis (suchasCFSRandERA-Interim ifavailable),satelliteobservations (GPCPfor

precipitationandE-OBSfortemperature)andlocalornationalclimatenetworks.

DataAnalysisconsistoftwosteps:firstly,theskillofmodeldatawillbeevaluatedusinghindcast

data for Europe area. After this analysis, ESD approachwill be applied to downscale European

climate projections to sub-regions in more spatial detail. As a result, climate change will be

evaluatedintermsofanomaliesfordifferenttimeslicesinthefuture,trendsandprobabilities.



DeliverableID:D2.7


Figure4-15:ClimateChangemodeldatasystemarchitecture.

4.11 ARCHITECTUREOFTHEFIREWEATHERINDEXMODELDATAINTEGRATION

TheFireWeatherIndex(FWI)modeldataarchitectureisshowninFigure4-16.Thesystemisbased

ontwoclearlydifferentiatedparts,thefirstonewhereallthenecessarydataisgatheredfromthe

I-REACTOR and the second part concerning the data analysis that consist of calculate the

probabilisticforecastingoftheFWIanditscomponents(FFMC,DMC,DC,ISI,BUIandDSRcodes).

AlltheseoutputdatawillfeedtheI-REACTOR.

Figure4-16:FireWeatherIndexmodeldatasystemarchitecture.



DeliverableID:D2.7


4.12 ARCHITECTUREOFTHEWEATHERFORECASTMODELDATAINTEGRATION

TheWeatherForecastSystemArchitecture(Figure4-17)consistsofcollectionofnecessaryinput

data,andprocessingstepsofthedata.InitialweathermodeldataaregatheredfromECMWFand

GLAMEPSensemblepredictionsystemswhichconsistsofmultipleperturbedforecasts.

DataProcessingstepsarecalibrationoftheinitialmodeldata,andcomputationofthefinalweather

forecastproducts.Onceaweek,thecalibrationcoefficientsarecalculatedandupdatedusingthe

information from prior (e.g. last 30 days) forecasts and observations.When the updated initial

weathermodeldataarereceived,theyarecalibratedusingthecalculatedcoefficients.Afterthat,

calibratedweatherdataareutilized tocompute theprobabilisticanddeterministic forecasts for

selected variables. Probabilistic forecasts are calculated forweather hazards according to given

thresholds.Finally,theseforecastproductsaresenttoI-REACTORinanappropriatedataformat.In

addition,calibratedensembleweatherforecastsaresenttoMETOSIMforFireWeatherIndex(FWI)

calculation.

Figure4-17:Weatherforecastmodeldatasystemarchitecture.

4.13 ARCHITECTUREOFFORECASTINGANDNOWCASTINGSERVICES FORFLOODANDFIREDISASTERS

AspartoftheI-REACTORthereisacomponentthatdealswiththeforecastingandnowcastingof

floodandfirehazards.Modellingfutureeventsandhowtheyunfoldrequiresaccesstorelevant

databut also applying sophisticatedphysicalmodelswith thebestdata in-hand. There are two

significantdifferencesbetweennowcastingandforecasting:

1. Timing–forecastingrelatestothelongertermandwithrespectfireandflooddisastersthe

timewindowisbetweenonetoupto10daysinadvance.Ontheotherhand,nowcastingis



DeliverableID:D2.7


fortheveryshorttermcomprisingofthecurrentsituationuptoseveralhoursinadvance

butlessthanoneday;

2. Modelsophistication–forecastingisbasedonsophisticatedphysicalmodelsthatrequire

inputdataofknownaccuracyandrequireheavycomputingtocalculatetheirresults.Onthe

otherhand,inorderfornowcastingtodeliverquickresultsthemodelsmustbesimplifiedin

order to reduce computing timeand the inputdata shouldbe local andprovided to the

nowcastingsystemassoonasitisavailableorchanged.

Thearchitectureoftheforecastingandnowcastingservicesdifferbecauseofthesetwodifferences.

Thetypesofmodelsandthetimingoftheservicesarealsohazarddependent.Notehoweverthat

theboththenowcastandforecastfloodandfireservicesfortheI-REACTORareonlyrunningfor

specificlocationsbasedonthetriggeringoftheservicesforaregionwherealarmsarebeingraised

and/orforongoingdisasters.

Thefollowingsubsectionsdescribethetwoarchitecturesusedforforecastingandnowcastingand

howtheyrelatetofireandfloodhazards.

4.13.1 FORECASTINGFLOODANDFIREHAZARDSThefloodandfirehazardforecastingsystemisexpectedtorunatleastdailyanduptotwicedaily

basedontheavailabilityofforecastedinformationthroughCopernicusservicesaswellasaweather

forecasts.ThearchitecturefortheforecastingsystemispresentedinFigure4-18.

Figure4-18:Thefireandfloodforecastarchitecture.Notethatsimilarinputdataisusedhowevertheforecastmodelsdiffer.

ThefloodandfireforecastservicesaretriggeredbyeitheraCopernicusEmergencyMappingService

(EMS) activation or by an authorized I-REACTOR user. Such triggers are needed because the

forecasting service requires an area of interest to be defined where the service will focus the

modellingefforts.

Aftertriggeringtheserviceandtheareaofinteresthasbeendefined,thereareanumberofdata

inputs required by the forecast models. The flood forecasting service requires that the region

aroundthefloodingriver,AreaofInterest(AOI),isextractedandthereforetherivercoursemustbe

known.ThisisextractedfromtheOpenStreetMap(OSM)database.Thetopographyoftheregion



DeliverableID:D2.7


mustalsobeknownandbydefaultthiswillbeextractedfromtheCopernicusEU-DEMbecauseitis

availablethroughoutEurope.TheManningCoefficientforthesameregionmustalsobeextracted

whichisbasedonthetypeofland-coverintheregion.Finally,whentheseinputsareavailablethe

forecastedriverflowforthesectionofinterestisrequired.Riverflowforecastsaremadeavailable

throughtheEFAS-SOSwhichisupdatedtwicedaily.

Thefirsttimethefloodforecastserviceistriggered,thelastEFAS-SOSdataisusedtostarttheflood

forecastforthedefinedregionimmediately.Afterthefirstfloodforecasthasbeendelivered,the

floodforecastserviceisruneverytimetheEFAS-SOSriverforecasthasbeenupdated.

For themoment, theLISFLOOD-FPmodel isbeingused for the I-REACTORfloodforecastservice

howeverothermodelswillbetestedinparallelinordertoproducedifferentfloodforecastoutputs

andprovidearangeofscenariostodecisionmakers.Eachtimethefloodforecastruns,theresults

aredeliveredimmediatelytotheI-REACTOR.

Anotherimportantcomponentofthisservicearchitecturerelatedtofloodingistheuseof initial

conditions.Asnoted,thefloodforecastserviceisbasedonamodelwhichisalsoheavilydependent

ontheinputinformation.Forthisreason,itshouldalsobepossibletoimprovethemodelresultsby

providingrealinitialconditions.Initialconditionsmaynotbeavailablerightaway,buttheycanbe

integratedintothemodellingprocess.FloodmapsthathaveeitherbeenproducedbyaCopernicus

EMSactivationand/orproducedbyI-REACTprojectpartnerscanbeusedforthis.Furthermore,field

reportscouldalsobe includedas initialconditions.The floodforecastservicewill take integrate

thesewhentheyareavailableintheI-REACTOR.

The fire forecasting service differs because of themodel used aswell as the input information

however it is triggered in the samemanner and also requires that an AOI be defined. The fire

forecast is driven by theweather forecastwhich is provided either twice daily but can also be

availableat6hourly intervals.Thefirsttimethatthefireforecast istriggered itwillusethe last

availableweatherforecast.Eachtimeafterthatitwillbeautomaticallyrunwhenthenextweather

forecastisavailable.ThefireforecastresultsareimmediatelydeliveredtotheI-REACTOR.

4.13.2 NOWCASTINGFLOODANDFIREHAZARDSThenowcastingserviceisexpectedtobetriggeredmuchmoreoftenespeciallywhentherearemany

newfieldupdatesprovidedtotheI-REACTOR.Theoverallarchitectureofthenowcastingserviceis

showninFigure4-19.Notethattheprocessingtimeofafloodorfirenowcastislessthan15minutes.



DeliverableID:D2.7


Figure4-19:Thefireandfloodnowcastarchitecture.

Thenowcastarchitecturediffersintheprocesstimingaswellastheinputdatathatisusedforthe

short-term processing expected of a nowcasting system. The service again begins when it is

triggeredby either aCopernicus EMSactivationor an I-REACTOR request. The triggeringof the

nowcasting service provides the service an AOI that defines the region where the disaster is

occurring. From this information, the necessary geospatial input data is first acquired. For the

nowcastservicefinerspatialresolutiondataisexpected.Therefore,theDEMandtheland-cover

informationshouldcomefromregionaltolocalauthoritiesoracquiredduringthedisasterevent.

Forexample,afinespatialresolutionDEMwhosecharacteristicsarebetterthan10mintheXandY

andbetterthan10cmintheZdirectionwouldbeidealespeciallyforfloodnowcasting.Thiscanbe

providedthroughLidardatasetsand/orthroughUAVbasedacquisitions.Similarly,localland-cover,

land-use and asset information can be used in the nowcasting service. Consequentely, the

nowcastingservicemustalsohavetheabilitytoadapttotheinformationavailableatthetimewhen

theserviceisstarted.

Theotherimportantarchitecturedifferenceisthefactthatverylocalizedinputdataisusedforthe

nowcasting.TheI-REACTORhastheabilitytoreceivefieldreportsonbothfireandfloodhazardsvia

mobiledevices.Thisdataisoneoftheprimarysourcestoupdatethenowcastmodelforboththe

fireandfloodservices.SocialmediadataafterithasbeenfilteredthroughtheI-REACTORcanalso

beused.

Specifictothefloodnowcastingservice,thereisalsoachancethatrivergaugedatacanbeingested

andused.However,duetotheheterogeneityofgaugesandserviceaccessrequirementsthismay

notalwaysbeavailable.

Asmentionedpreviously,thefloodnowcastmodelsaresimplifiedanditisimportanttomaintain

resultswithintheexpectedphysicalextentforagivenregion.Forthisreason,thefloodnowcast

architectureincludesexternalconditionsthatarerealfloodextentmapoutputsproducedduring

the course of the flood disaster event. Such information is used to constrain the flood model

outputs. They will be taken from the I-REACTOR when they are made available either by the



DeliverableID:D2.7


CopernicusEMSactivationorby the I-REACTpartnerproducing floodmapsbasedonSentinel-1

imagery.

The floodand firenowcast service isexpected to runevery timean I-REACTORauthorizeduser

makesarequestand/orwhenenoughnewfieldreportshavebeenreceived.Thismeansthatitcan

berunningevery15minutesbasedonupdatedfieldinformation.Alltheresultsareimmediately

outputtotheI-REACTOR.Situationalawarenessisparamountanddisastermanagerscanusethe

serviceoutputsandtheirexperienceandexpertisetomakethebestdecisionsinadisastersituation.

4.14 ARCHITECTUREOFTHEIN-SITUWATERMONITORINGSYSTEM

Thein-situwatermonitoringsystemwillperformvideoanalysisusingcomputervisiontechniques

tocomputeestimationsofwatervelocityfromvideostakenprimarilyusingmobilephone.Itwill

compriseaclient-side(mobile)SDKlibrarythatcanbeinterfacedbytheI-REACTappusingCordova,

andmostlikelyaserver-sidecomponentlibraryusedintheI-REACTserver.Notethisserver-side

componentmaynotbenecessaryifcomputationsturnouttobeeasilymanageableusingjustthe

mobileclient-sideprocessors.

Figure4-20:Systemarchitectureoverviewforin-situwatermonitoring

The client-side interfacewill involvepassinga video filedescriptor to the client-side libraryand

requestingvelocityestimations,whichwillasynchronouslyreturnJSONdatagivingeitherthewater

velocity estimation values, or error codeswithusefulmessages (e.g. “Couldnot detect suitable

objectmovinginthewater,pleaseensurethere'sfloatingobjectmovingwiththeriverandretake

video.”)Iftheserver-sidecomponentisused,theclient-sidecomponentwillneedtobeconfigured

withtheavailableserverhostAPIcallthatitcandependupontoreturntheexpectedJSONresult

data.

Ontheserverside,apublicAPIcall(e.g.RESTful)willneedtobeopenedtoenabletheclient-side

componentstopasswatervelocitycomputationrequeststo.Uponcompletionofwatervelocity

calculations, the server-sidewould then respondwith its results (JSON format as above)which



DeliverableID:D2.7


wouldbethereturnvalueoftheabove-mentionedAPIcall.Thearchitecturalblocksinvolvedinthe

watervelocityprocessingissketchedinFigure4-20.

4.15 ARCHITECTUREOFTHEUAVDATASERVICESVIAASIGN&ASMIRA

TheUAVDataservicesarchitectureincorporatestheASIGNandASMIRAsystemsbyAnsuR.

TheASIGNarchitecturecomprisesseparatemobileapps(Android,iOS)andservers,whichensure

thecommunicationofphotosandvideoclipsfromUAVs–eitherline-of-sightquadcopterslikethe

DJI phantom communicating overmobile phone data connection on ASIGNUAV-centricmobile

apps,orbeyondline-of-sightdronescommunicatingviaon-boardsatellitecommunicationterminals

throughembeddedASIGNsoftware(alsoon-board).

TheASIGNback-endwillthenmakethatdataavailabletotheI-REACTserverasitappearsinthe

ASIGNdatabases.TheacquireddatawillbevisualizedintheI-REACTfrontend,andeventuallytothe

I-REACT mobile application. This choice will be finalized in the design phase of T5.3 “Mobile

Applications”.

StreamingvideosolutionswillbeprovidedviatheASMIRAsystem,wherebyvideoisstreamedfrom

aUAVtoreceiverunitselsewhere.Onesuchreceiverunitcanthenmakethisstreamingvideodata

availabletotheI-REACTbackend,aswiththeASIGNphotoandvideo-clipdata.

Other integrationwebserviceswillberequired inordertomaketheUAVdatachainacquisition

operationalfromtheinitialrequestfromtheauthoritiesviatheI-REACTORfrontend,uptothedata

beingacquiredanddisplayedwithinthe I-REACTsystem.Thedefinitionof theactualsetofweb

servicesrequiredfortheoperationalintegrationofASIGNandASMIRAwillbedefinedwithinTask

T5.6“UAVdataservices.ThearchitecturalcomponentsinvolvedinthemanagementofUAVsare

sketchedinFigure4-21.

Figure4-21:SystemarchitectureforI-REACT–ASIGNsystemsforUAVDataServices



DeliverableID:D2.7


4.16 ARCHITECTUREOFEXISTINGLOCALEMERGENCYMANAGEMENTSYSTEMS

The architecture of the external module that will allow the dialogue between I-REACTOR and

existinglocalEmergencyManagementInformationSystemsincludestwodifferentscenarios:

Scenario1-directconnectionwithexternalsourcesThefirstscenario,depictedinFigure4-22,involvesthedirectconnectionwithexternalsources.Inthe case of structured databases a specificwebmodule (java application)will be developed. A

backofficeinterfacewillallowthemanualmappingbetweenthedatamodelofthedatabasesource

withtheI-REACTORbackend,beforegoingonwiththeconversionandingestion.Themodulewill

allow to choose the frequency of data update. A reverse flow, from the I-Reactor towards the

originaldatabasewillbepossibleaswell.

Inthecaseofexternalsensors,a‘’streammediator”willbedeveloped.Itwillimplement'complex

eventprocesses',beforetheingestiononI-REACTOR.Thestreammediatorwillofferthepossibility

topreprocessdifferentstreamsinrealtime,byimplementingreal-timeprocessinglogics,including

datafilteringandeventcorrelation,etc.Thismodulewillberealizedwithtechnologies(eg.WSO2

CEP)suitabletomanageandprocessstreamsofmassiveeventsinparallel.

Figure4-22-Scenario1–directdataintegrationfromexistingsources

Ifitwillberequiredbythespecificsensorsnetwork,gatewaysenabling"EdgeComputing"scenarios

andsupportingofflineoperativityofsensorswillbedefined,implementinganarchitecturesimilar

towhatshowninFigure4-23.



DeliverableID:D2.7


Figure4-23-Gateway:architecturaldesignschema

Scenario2-existenceofintermediateserviceplatformsThe second scenario, depicted in Figure 4-24, involves the existence of intermediate service

platforms,thatexposedatafromstructureddatabasesorsensorsthroughrealtimestreamsand

APIrest,definedusingOdataprotocol.

TheseplatformsprovideseveraltypesofAPIs,mostlyinRESTandJSONformat,whichrespondto

needsforintegrationandconfigurationofdifferenttypes:

• StreamingAPIs:allowtogiveorreceivethedatastreams(linkedtosensors,socialnetworks,

third-partyapplications,...),possiblyprocessedinrealtime;

• MonitoringAPIs:allowtoreceivespecificdefaultnotificationconcerningplatformoperativity;

• DataServiceAPIs:provideaccessandqueryingtodata;• DataIntegrationAPIs:provideofflinedataandscheduleddataintegration.

Figure4-24-Scenario2–ConnectionthroughamediationcomponentforrealtimestreamsandRESTAPIs



DeliverableID:D2.7


Note:inthislastcase,strongsecurityrequirementsarenormallysatisfiedbytheplatform.Inthe

formercase,itwillbenecessarytodefine,casebycase,thespecificrequirementsandimplement

solutionsthatcansatisfythem.

4.17 ARCHITECTUREOFSOCIALMEDIADATAENGINE

SocialMediaDataconstitutesavaluableresourceforI-REACT,especiallyfordetectinghazardevents

(i.e. many citizens, from the same area, writing about a fire) and for providing to Emergency

Response actors (i.e. first responders, civil protection, fire fighters) additional contextual

information.

SocialMediaDataEngine isanexternalmodule thatwillmonitora setof selectedsocialmedia

streams(i.e.Twitter)inordertodetectusergeneratedcontentsconcerningthedomainofinterest

oftheproject(allhazards)andthenprovidetheI-REACTORwithsuchrelevantsocialmediadata,

enrichedwithadditionalinformationtailoredforI-REACTprojectlikeaclassificationofthereported

emergencyevent,thegeographicalentities(i.e.rivers,cities,..)mentionedinthedata.

The component presented in Figure 4-25 uses a set of different Adapters (one for each of the

supportedSocialMediaChannels)inordertomonitorsocialmediadatastreamsandsomeExtractor

Modules (one for each of the supported languages) in order to discriminate between domain

contentsandnotrelevantones.RelevantcontentswillbefurtherprocessedwithaLanguageand

Semantic Analysis Pipeline in order to be enrichedwith additionalmetadata (Emergency Event

classification,SentimentAnalysis,EntitiesDetection).Theenricheddataisthenstoredinaninternal

storage(PrimaryIndex)andfinallyprovidedtotheI-REACTORthroughasetofRESTAPIs.

BesidesprovidingtheenrichedsocialmediadataondemandthroughtheRESTAPIstheSocialMedia

DataEnginecomponentwillproactivelydelivertotheI-REACTORadditionaldata:

• Early Warning Alerts on Emergency Events detected from the analysis of the Social Media

Streams.Thesealertswilldetail thetypeofeventdetected(i.e.,Forest Fire,Coastal Flood,

etc..)byreferencingtheclassificationofhazardsmodelledintheI-REACTontology(see

DeliverabledocumentD2.3“ReportondesignoftheBigDataArchitecture,LinkedDataand

Semantic Structure”). The alertswill also include additionalmetadata as the location, the

volumeoftheexchangedmessagesrelatedtothedetectedevent,asummaryofthe

contents present in the stream by means of a selection of the most representative

messages and the top keywords. A confidence value provides a measure of the estimated

relevanceofthealert.

o ThesealertswillneedtobevalidatedbyDecisionMakersinordertotriggerthecreation

ofanEmergencyEventintheI-REACTORsystem.

• DuringanEmergencyEvent,theSentimentAnalysisongeo-localizedcontentswillbeusedto

generatea“panicmap”.ThismaplayerwillbeautonomouslyuploadedonI-REACTMapServer

andperiodicallyupdatedwithnewcontents.



DeliverableID:D2.7


Figure4-25SocialMediaDataEngineArchitecture

4.18 FINALARCHITECTURALDIAGRAM

TheresultinghighleveloverallarchitectureofI-REACTisshowninFigure4-26,wheretheMobile

Appsblockincludethemobileapplicationforsmartphone,thesmartglassapplication,thewearable

positioning device, and UAVs. External I-REACTModules are all modules developed within the

projectthatareexternaltotheI-REACTORstructure.



DeliverableID:D2.7

GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:55of60

Figure4-26:NewOverallI-REACTarchitecturediagram



DeliverableID:D2.7


5 TECHNICALREQUIREMENTS

Thissectionliststheinitialtechnicalrequirementsidentifiedsofar,whicharereportedinTable5-1thatgathersalltechnicalrequirementsresultingfromthedeliverablessubmittedinWP2andfromthe preliminary analysis done in WP3, WP4, and WP5. This initial list will be updated in thesubsequentdeliverables.

Table5-1:Initiallistoftechnicalrequirements

Req.code Category Description KPIs

TR1 General Serviceavailability(allservices) 99.9%onayearlybasis

TR2 Models Datasourcesthatwillbeusedfornowcastcomputation Atleast3

TR3 Models Datasourcesthatwillbeusedforforecastcomputation Atleast4

TR4 Models Requirementsforweatherforecastmodels SeeTable5-2

TR5 Models RequirementsforFireandFloodnowcastandforecastmodels SeeTable5-3

TR6 Models RequirementsforRiskMaps SeeTable5-4

TR7 Models Requirementsforsocialmediaengine SeeTable5-5

TR8 WebBasedDSS BrowsercompatibilityChrome53+Firefox49+Edge38+

TR9 MobileApplication Mobileoperatingsystemscompatibility Android5+AppleiOS10+

TR10 MobileApplication Applicationavailability Publishedineachappstoreofthesupportedoperatingsystem

TR11 EMSIntegrationModule Rapidnessofdatadownloads

Newdatadownloadedwithin5minutesfromavailabilityintheEMSwebsite

TR12 EMSIntegrationModule

FlexibilitytoingesthistoricdatasetsintheDB

Atleast90%ofallprovidedandrelevantdatasetswillbesuccessfullyingestedintoDBviaIDI


Alertincaseingestionofdatasetisnotpossible

Alertsentinthe100%ofnon-ingesteddatasets


Harmonisationofdatasetsintermsofprojection&metadata

AlldatasetdeliveredtoI-REACTORwiththesameprojectionandwithacommonmetadatastructure

TR15 EMSIntegrationModule AbilitytocopewithDBunavailability

Thetransferwillbetriedagainwithin10minutesafterendofunavailabilityuntilthetransferissuccessfullycompleted



DeliverableID:D2.7


TR16 Mapserver Serviceavailability 99.9%onayearlybasis

TR17 Mapserver Maplayervisualisationonweb-basedfrontend Within3seconds

TR18 Mapserver Maplayervisualisationonmobileapplications

Within3secondsLTEWithin5secondsH+Within10secondsG+Within45secondsEDGE

TR19 Mapserver Servicecompleteness(allmaptilesshown)

In9of10 casesallmap tilesof therequiredlayerareloaded

TR20 Mapserver RapidnessofnewWMSprovisionNew data set is available as WMSwithin 10 min after ingestion indatabase

TR21 Models SeasonalClimateForecastandClimateChangeprojections

SeeTable5-6

TR22 Wearable AverageaccuracyofGNSSpositioninginopenskycondition

<10m

TR23 Wearable

Useofwearabledevicestotransmitmoretechnicalin-fieldreportswithoutreducingtheoperationalcapabilityoffirstresponders

Weight(<300g)Batteryautonomy(>1day)

TR24In-SituWaterVelocityMeasurement

Cross-platformcompatibilityExternal Libraries to be linked andusedinCordovaformobile

TR25In-SituWaterVelocityMeasurement

Watervelocitymeasurementcalculationscompleteinadequatetime

Within 30-60 seconds fromacquisitiontofinalresult

TR26 UAVDataServices

I-REACTabletoingestphotosandvideo(clipsandstreaming)madeavailablefromASIGN/ASMIRAsystemsforUAVs(LOSandBLOS)

Averagewebservicesresponsetime<3s(excludingpayloadtransfertime)

TR27 UAVDataServicesCommunicationbetweenI-REACTandexternalservers(e.g.ASIGN)toberapidandtransparenttoI-REACTusers

Averagewebservicesresponsetime<3s(excludingpayloadtransfertime)

TR28 SoftwareModules AvailabilityofGISlibraries e.g.GistoolsforHadoop,GeoSpark

TR29 Models EarlyAlertsfromSocialMediaStreams HighRecalloneventdetection

TR30 Models SocialMediaFiltering(detectingcontentsrelevanttoI-REACTdomainofinterest)

Serviceavailableforat leastoneforeach of the languages used in thelocationsofin-fielddemos



DeliverableID:D2.7


Table5-2:DetailKPIsforweatherforecasts

CharacteristicsModels

ECMWF GLAMEPS METEOSAT(cloud) Radar(rain)ForecastIntervals[h] Upto360 Upto48 nowcast nowcastUpdateintervals[h] 12 6 1 0,25

Variables

TemperatureWind

Precipitationsurfacepressure

TemperatureWind

Precipitationsurfacepressure

Cloud(observations)

Rain(observations)

Resolution 0.2degree(gridspacing) 8km 2km 2kmArea Europe Europe Europe Europe

Table5-3:DetailedKPIforfireandfloodnowcastandforecastmodel

Characteristics ModelsFloodnowcast FloodForecast FireNowcast ForeForecast

ForecastIntervals[h] 4 Upto240 12 48Updateintervals[h] Ondemand 12 12 12Variables Floodextent Floodextent Fireextent FireextentResolution 30morbetter 30morbetter 500m 1km

Area Europe–eventextent

Europe–eventextent



Table5-4:DetailedKPIsforriskmaps


HeavyRainfallRisk

SevereGustRisk

HeatWaveRisk

ColdWaveRisk

FireRisk

ForecastIntervals[h] Upto48/360 Upto48/360 Upto48/360 Upto48/360 Upto48/360Updateintervals[h] 6/12 6/12 6/12 6/12 12Variables[Probabilitytoexceedathreshold]

50mm/day,100mm/day,30mm/3h,50mm/3h

17m/s,25m/s

31oC,37oC

-5oC,-25oC

FWI(appropriatethresholds)

Resolution 8/16km 8/16km 8/16km 8/16km 8/16kmArea Europe Europe Europe Europe Europe

Table5-5:DetailedKPIsforsocialmediamodels

CharacteristicFunctionality

EventDetection Sentimentanalysis TopicMonitoring TopicfilteringHazards Primaryandsecondary,asdefinedinD2.1Updateinterval real-time 30minaftercontentsingestion ondemand real-timeArea Europe



DeliverableID:D2.7


Table5-6:DetailKPIsforseasonalclimateandclimatechangemodels


SeasonalClimateForecast ClimateChangeProjectionsForecastIntervals 3months 30yearsUpdateintervals 3months NoupdateVariables Precipitation,temperature Precipitation,temperature

ResolutionFrom0.5to2deg(inoriginalclimate

models).Tobedefinedafterdownscaling.

From0.5to2deg(inoriginalclimatemodels).Tobedefinedafterdownscaling.

Area Europe Europe



DeliverableID:D2.7


ENDOFTHEDOCUMENT

D2.7 Report on Technical Requirements and Overall System … · Project: I-REACT Report on...

Documents

Transcript of D2.7 Report on Technical Requirements and Overall System … · Project: I-REACT Report on...