Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:3of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:4of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:5of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:6of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:7of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:8of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:9of60
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/
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:10of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:11of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:12of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
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
PUBLICAUTHORITIES CITIZENS
SELFPROTECTIONBEHAVIOURS
PREVENTION
PUBLICAUTHORITIES CITIZENS
OPERATIONALMANGEMENT
PUBLICAUTHORITIES CITIZENS
PUBLICAUTHORITIES CITIZENS
RESPONSEPREPAREDNESS(EARLYWARNING)
PUBLICAUTHORITIES CITIZENS
RISKAWARENESS FORECAST/NOWCAST WARNING&ALERTING
CITIZENS
Remotesensingdataandtools:collectedfromsatellitesMobileApplication:generalapplicationssuitableforinformationsharingandin-fieldreportingWearabledevices:smartglassesandbandusedforprofessionalin-fieldreportingandpositioningSocialmedia:toolsandmethodsthatallowinformationgatheringfromsocialmediaanddiffusiontroughthemUAVMapping:toolsthatcollectandbroadcastproperlyimages,dvideosandmapsfromUAVs
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:14of60
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:
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:15of60
• 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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:16of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:17of60
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).
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:18of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:19of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:20of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:21of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:22of60
• 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).
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:23of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:24of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:25of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:26of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:27of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:28of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:29of60
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/
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture DeliverableID:D2.7GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:30of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:31of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:32of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:33of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:34of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:35of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture DeliverableID:D2.7GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:36of60
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
Smallerfieldofview(23°)
Displayresolution:960x540px
Manualcalibrationisneededtoprovideagoodstereoscopicexperience
WiFi,BluetoothandGPS
Smallerfieldofview(23°)
Displayresolution:1280x720px(HD)
Manualcalibrationisneededtoprovideagoodstereoscopicexperience
WiFi,BluetoothandGPS
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:37of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:38of60
• 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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:39of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:40of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:41of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:42of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:43of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:44of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:45of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:46of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:47of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:48of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:49of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:50of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:51of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:52of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:53of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:54of60
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.
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:55of60
Figure4-26:NewOverallI-REACTarchitecturediagram
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:56of60
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
TR13 EMSIntegrationModule
Alertincaseingestionofdatasetisnotpossible
Alertsentinthe100%ofnon-ingesteddatasets
TR14 EMSIntegrationModule
Harmonisationofdatasetsintermsofprojection&metadata
AlldatasetdeliveredtoI-REACTORwiththesameprojectionandwithacommonmetadatastructure
TR15 EMSIntegrationModule AbilitytocopewithDBunavailability
Thetransferwillbetriedagainwithin10minutesafterendofunavailabilityuntilthetransferissuccessfullycompleted
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:57of60
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:58of60
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
Europe–eventextent
Europe–eventextent
Table5-4:DetailedKPIsforriskmaps
CharacteristicsModels
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
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreementNo:700256 CallID:H2020-DRS-1-2015 Page:59of60
Table5-6:DetailKPIsforseasonalclimateandclimatechangemodels
CharacteristicsModels
SeasonalClimateForecast ClimateChangeProjectionsForecastIntervals 3months 30yearsUpdateintervals 3months NoupdateVariables Precipitation,temperature Precipitation,temperature
ResolutionFrom0.5to2deg(inoriginalclimate
models).Tobedefinedafterdownscaling.
From0.5to2deg(inoriginalclimatemodels).Tobedefinedafterdownscaling.
Area Europe Europe
ImprovingResiliencetoEmergenciesthroughAdvancedCyberTechnologies
Project:I-REACT Report on Technical Requirements and Overall System Architecture
DeliverableID:D2.7
GrantAgreement:700256 CallID:H2020-DRS-1-2015 Page:60of60
ENDOFTHEDOCUMENT