Page 1 beAWARE Enhancing decision support and management services in extreme weather climate events 700475 D7.1 Technological Roadmap Dissemination level: Public Contractual date of delivery: Month 6, 30 June 2017 Actual date of delivery: Month 6, 30 June 2017 Workpackage: WP7 System development, integration and evaluation Task: T7.1 System Requirements and Architecture Type: Report Approval Status: Final Draft Version: 1.0 Number of pages: 52 Filename: d7.1_beaware_technological_roadmap_2017-6- 30_v1.0.docx Abstract The objective of this document is to define the outline of the time plan for the development of the beAWARE platform. In this context, the deliverable provides a high level view of the beAWARE platform architecture and a specification of the infrastructure layout. In addition the deliverable includes an initial functional description of each of the technical modules, describing the supporting technologies, the increasing functionalities over time and the development timeline. Finally, the deliverable includes a summary of the use cases and a global project timeline, describing the platform’s scheduled iterations and the levels of functionality at the project milestones. The information in this document reflects only the author’s views and the European Community is not liable for any use that may be made of the information contained therein. The information in this document is provided as is and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information Ref. Ares(2017)3305579 - 30/06/2017
52
Embed
d7.1 beaware technological roadmap 2017-6-30 v1.0 · Page 1 beAWARE Enhancing decision support and management services in extreme weather climate events 700475 D7.1 Technological
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
4. External facing layer, including the end-users’ applications and PSAP (Public-safetyansweringpoint)modules,interactingwithpeopleandentitiesoutsidetheplatform
(end-usersoftheplatform).
Figure1:Architecturalhigh-levelview
D7.1–V1.0
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
Internal services – These services are used internally for the proper functioning of thecapabilities provided by the various components. These services are usedmostly for data
storage and communication. Some generic data analytics and processing servicesmay be
used as well. Examples of this layer include a central (raw) data repository, a central
A preliminary list of miscellaneous technological packages (application servers, special
purposestacks,etc.)isprovidedinTable3.
Product Versions
allowed
Notes
Kafka 0.8.x Messagingservice
1 Open Source Initiative, see http://opensource.org/. 2 See https://joinup.ec.europa.eu/software/page/eupl/eupl-compatible-open-source-licences for complete list of EUPL-compatible open source licences.
D7.1–V1.0
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
(MessageHub)
Jetty 9.x J2EEapplicationserver(preferred)
Tomcat 7.x J2EEapplicationserver
Node.js 0.10+ JavaScriptapplicationserver
ApacheJena 3.x SemanticWebframeworkforJava
Table3:Othertechnologies
2.2.4 Exchangeformats
The preferred exchange format for structured datawill be JSON3.UTF-8 encodingwill be
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
3.2 Aggregation and semantic integration of emergency information fordecisionsupportandearlywarningsgeneration(WP4)
WP4addressesthecollection,aggregationandsemantic integrationofcontentrelevanttoemergencyinformationinordertofacilitatedecisionsupportandearlywarningsgeneration.This is accomplished through: i) the social media monitoring module, ii) the moduleresponsibleformonitoringmachinesourcinginformationfromIoTandM2Mplatforms,andiii)thesemanticrepresentationandreasoningmodule.
3.2.1 SocialMediaMonitoringmodule
TheaimofthesocialmediamonitoringmoduleistocollectpostsfromTwitterthatappeartoberelevanttothethreemainpilots,i.e.floods,fire,andheatwave.Thecrawlingprocessneeds tobe real-timeandefficient, able tohandle large streamsofdata, especiallywhenkeywords such as “fire” have multiple meanings. The module collects tweets in English,Greek, Italian, Spanish, and Danish, that are published by any citizen, civil protectionorganisationoronlinenewswebsites.
InordertogainaccesstoTwitter’sglobalstreamofdata,wehaveexploitedtheStreamingAPIs9, a streaming client that receives tweets themoment that they occur. Compared toTwitter’sRESTAPIs10 ,thisoptionoffersareal-timestreamoftweets insteadofconstantlymakingrequestsandthusoverridesanyratelimiting,i.e.maximumnumberofrequests.TheonlylimitationwhenusingtheStreamingAPIsisthateachaccountisallowedtocreateonlyonestandingconnection.
There are various streaming endpoints that can be divided into the following categories:Public streams, User streams, and Site streams. In our case, the “POST statuses/filter”endpoint of public streams is the most suitable, since it focuses on public data flowingthroughTwitterthatmatchesoneormorefilterpredicates.Specifically,the“track”fieldcanbeusedtodefineupto400searchkeywords,combinedwithanORoperator,sothattheAPIwillreturntweetsmatchinganyofthesekeywords.
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
To consume Twitter’s Streaming API, we chose to adopt the Hosebird Client (hbc)11, anopen-sourceandeasy-to-use JavaHTTPclient.A requiredparameter is theuseraccount’scredentials, while an optional parameter is the track keywords. For each pilot and eachlanguage we sustain separate collections in a MongoDB database, not only to store thecrawledtweets,butalsotokeepacollectionofrelevantkeywords.Bycommunicatingwiththesecollectionsweareable todefinea setofwordsanduse themas track terms.Afterconnection with the Twitter API is established, every time a new tweet is retrieved, weexaminewhich of the keywords exists in the tweet’s text. In this waywe canmatch thetweet to the corresponding languageandpilot (e.g. “inundación”matches to Spanishandfloods),andtheninsertittotherespectivedatabase,maintainingthestructureprovidedbytheAPI,sincetheJSONformatfitswellforMongoDBdatabasesstructures.
Aservice iscreatedtoclassifyallpostsasrelevantor irrelevant,soonlytherelevantonesproceed to the beAWARE analysis component, aiming mainly to extract locations and todetect key events. The training of the classificationmodel is based on user feedback, ascollected from our dedicated interface that demonstrates all social media collections,offeringtheannotationoptionasrelevant/irrelevant,whichisstoredasabinaryattributeinMongoDB.
OnceanewTwitterpost is collectedand identified as relevant, amessage is createdandpublishedtothecommunicationbusandallsubscriberscanaccessthemarkedTwitterpostsdirectlyfromtheMongoDBdatabase.
Sensordataiscrucialfortrackingtheonsetandprogressofacrisis.Thereisalargevariationinsensorsandanalmostequallylargevariationininterfacestoaccessthedatafromthosesensors. The aimof thismodule is to collect time-series sensor data from various on-linesensors and make this sensor data, and the sensor metadata, available through astandardisedinterface.
Amodern, RESTful interface for accessing time-series sensor data and sensormetadata isTheOGCSensorThingsAPI14. Itspecifiesadatamodel,a JSONdataformatfortransferringthe data, and a RESTful interface for accessing the data. The datamodel is based on theISO/OGC Observation and Measurement (O&M) model. The data format and RESTfulinterfaceisbasedontheOASISODataVersion4.0specification.SeveralimplementationsoftheSensorThingsAPIexist,bothopen-andclosed-source.
Thesensordatawillbe fed into thesystemthroughdatawrappers thatmediatebetweenthe (oftenproprietary) interfaceof the sensor and the SensorThingsAPI. Themodulewillcontain an extension for setting thresholds and for sending notifications through thecommunicationbus(WP7)whenthresholdsarepassed.
The semantic representationand reasoningmodule consistsof the followingcomponents:(a)thebeAWAREKnowledgeBase (KB),alsoreferredtoas“ontology”,(b)theKBService,(c) the semantic enrichment and reasoning framework. More information on thesecomponentsisgiveninthefollowingsubsections.
SemanticKBcomponent
ThesemanticKB,orontology,constitutesthecoremeansforsemanticallyrepresentingthepertinentknowledgeandforsupportingdecision-making.Basedonawell-definedformalism(OWL–WebOntologyLanguage),thebeAWAREontologywillencompass,amongstothers,information regarding domain knowledge (types of crises, risks and impacts), multimodalinput (image, video, text and speech) and contextual information, climate andenvironmentalconditions,geolocations,aspectsrelevanttoeventsandtime.
Typicalconstructsstoredinanontologycontaintheclassesrepresentingthemainentitiesinthedomain,the instantiationsoftheseclasses(i.e.objects)andtherelationsbetweentheentities. Specifically, for thebeAWAREontology, the storednotions and interrelationshipswill depend on the output of the requirements analysis activities within WP2, and mostnotablyonD2.1,deliveredinM5.Thecontentoftheontologywillbeupdatedinlaterstagesin the project lifetime, according to more up-to-date needs arising from the pilotdeployments.
The design and development of theontologywillfollowawell-knownontologyengineering methodology, called “NeOnmethodology”,whichisextremelysuitablefor collaborative ontology design andauthoring (i.e. twobeAWAREpartnersareinvolved in developing the ontology,CERTH and IOSB). The actual deploymentof the ontology will rely on open-sourceestablished software tools: Protégé (v.5+) ontology editor for authoring the ontology,GraphDBorWebGenesistriplestoreservingastheontologyrepository.
Inordertoconformtoamoremodularapproach, thebeAWAREontologywillconsistofaset of interconnected sub-ontologies, one per class of crises (flood, fire, heatwave).
Figure4:beAWAREontologynetwork
D7.1–V1.0
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
Additionally, existing standards and ontologies will be adapted or extended according tobeAWAREneeds.
Afterthebasicschemaoftheontology is finalised,the inputtotheontologywillcome(inthe formof instances) fromvariousotherbeAWAREcomponents, likee.g. thecomponentextractingconceptsandconceptualrelationsfromtext(T3.2),orthecomponentretrievingconcepts and events frommultimedia (T3.3). Sincewe are expectingmassive volumes ofinstancestobeaddedintotheontologyinthecaseofacrisisevent,thechoiceofascalableontologyrepositoryisofutmostimportance.
CriticalFactors • Inefficient communicationwith use case partners on themostrelevantnotionstobestoredintheKB.
• Scalabilityoftheontologyrepository.
Table16:SemanticKBcomponentsummary
KBServicecomponent
TheKBServiceisresponsibleforaccessingandupdatingtheontologycontent,byprovidingaRESTFulAPIservice.CallstotheAPIfromend-userswillbetranslatedtoappropriateSPARQL1.1 queries, which will then be submitted to the GraphDB triple store maintaining theontology.Thus, thiscomponent is responsible for theontology’ssemantic integration, i.e.semantically integrating information that is the output from other modules into theontology.
Other aspects thatwill be investigated (and potentially added to the KB Service) include:ontologypopulationandontologyenrichment.Theformerprocessinvolvestheadditionofobjects/instances into the ontology, while semantic enrichment refers to the process ofaugmenting the semantics of anontologyby establishing links to external sources andbyappendingnewknowledge retrieved fromthosesources. It is imperative that theexternalthird-partyknowledgesourcesservedatainanappropriateformat(i.e.asRDFLinkedData),thuswewillconsiderknowledgesourcessuchasDBpedia,GeonamesandFreebase.
Input Select/Updatequeriesfromothercomponents.
Output Responsecontainingtheresultsetofthe‘Select’query.Inthecaseof ‘Update’ queries, the response will be the number of triplesaddedto/removedfromtheontology.
This component is responsible for performing semantic reasoning on the ontology,whichrefers to the process of inferring implicit knowledge from the explicitly asserted factsresidingintheontology.Thereasoningmechanismswillsupportsophisticatedinterpretationtasksrelevanttothemanagementofmultimodalincominginformationandtotheretrievalofinformationpertinenttotheusers’needs.
AcriticalissueforbeAWAREinvolveshandlinguncertaininformation.Forthispoint,wewillrelyonfuzzyand/ornon-monotonicreasoningapproaches,inordertocopewithincompleteand inconsistent information and to resolve conflicts and prioritize the proposed actions.Existingreasoningengineswillbethebaselineforthesemanticreasoningactivityandwillbeeffectivelyextended,inordertomitigatetheircurrentlimitations,likee.g.scalabilityissues,non-seamlessintegrationwithontologies(inthecaseofuncertaintyreasoningengines)andmoreimplementation-specificlimitations.
Output A graph of query-relevant facts extracted from the triple store.Relevantinformationwillbeencodedinthegraph.
Programminglanguages Javaand/orPython
Dependencies • OntologyandKBServicefromWP4;• Use case needs and requirements from WP2 with respect to
datatypesandreasoning.
CriticalFactors • The accuracy of this service is crucial to the quality of usersupporting information. Flaws/errors in the reasoning andinferenceproceduresmightproducesub-optimalresults.
• The size of the knowledge base might be too large for thereasonertohandleefficiently.
• The lack of specificity can lead to poor results with thiscomponent.
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
3.3 Multilingualreportgeneration(WP5)WP5 addresses the generation of the emergency reports andmessages that need to (orshould) be communicated to the different types of stakeholders that beAWARE considers(authorities, first responders, citizens,etc.)duringanemergency inorder toprovide themwithtailoredsupport.Itaccomplishesthisthroughthefollowingtwomodules.
3.3.1 Textplanningmodule
Thetextplanningmoduledealswiththeselectionofcontentfromthesemanticrepository(KB) and the creation of a discourse plan for the reports and messages that are to begenerated. It serves as the first step in the beAWARE emergency report and messagegenerationpipeline,anditisresponsiblefortailoringcontentsselectionandtheirstructuringtotheinformationneedspertinenttothespecifictargetusergroupandcontext.
Input • RDFtriplesobtainedviaSELECTqueriesfromtheKB• Targetedusergroup (e.g.authorities, first responders,citizens,
etc.), with the possibility for further potentially relevantinformation(e.g. filters) fromthetriggeringmodules (semanticreasoningandPSAP)
• Domain knowledge modelling, as it affects the selection anddiscoursestructuringcriteria
• Specification of the information needs of the different usergroupsaddressed
CriticalFactors • Scalabilityofcontentselectionalgorithm• Update effectively with respect to what has been
communicatedpreviously• The richer the semantic domainmodel, themore changes for
coherentcontentselectionanddiscourseplanning
Table21:Textplanningmodulesummary
3.3.2 Multilinguallinguisticgenerationmodule
The multilingual linguistic generation module deals with the verbalization of emergencyreportsinthelanguageofendusergroupstargetedinthebeAWAREpilots.Ittakesasinputthe abstract (conceptual) representations produced by the text planning module andsuccessivelyproducesallthelayersforeseenbytheMeaning-TextTheorythroughapipelineofgraphtransducersandclassifiers.
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
3.5 Systemdevelopment,integrationandevaluation(WP7)Due to the distributed approach of the design and implementation of the beAWAREplatform,inwhichdifferentpartnersmaintainownershipoverdifferentcomponentsofthesystem,combinedwiththecomplexityoftheplatform,whichiscomprisedofmanydifferentcomponentswe opted to follow amicro-services approach tomake the entire process ofdesign,implementation,andintegrationmoremanageable,inadistributedmanner
Using thisapproach,wemaintain the independenceof thedifferentcomponents,and theintegrationfocusisontheexposedcapabilitiesofeachcomponent.Theintegrationbetweencomponents isbeingrealizedvia twomainmechanisms, first, inter-communicationvia theplatformcommunicationservicebus,andsecondthroughexposedRESTinterfacesofvariouscomponents,potentiallyaidedbyadiscoveryservice.
Micro-servicesisanarchitectureformandmethodologyforbreakingupalargeandcomplexsystemintosmallunits,eachfulfillingauniquewell-definedtask,inanindependentmanner.Eachsuchmicro-serviceisdeployedseparatelyandcaninteractwithitspeermicro-servicesusing standard communication protocols. Such an approach eases the task of long termmaintenanceandevolutionofalargesystem,comparedtoamonolithicsystem.Inaddition,internal changeswithin amicro-service do not influence any other system component aslongastheexternalcontractofthemicro-serviceisadheredto.Moreover,eachcomponentcanbeimplementedinadifferentprogramminglanguage,usingdifferentmiddleware.
Asmentionedearlier,therearetwomainmechanismsformicro-servicestointeract,namely,thecommunicationservicebusandaREST interface(possiblywiththehelpofadiscoveryservice).Forcommunicatingthroughthecommunicationbusthecomponentsneedonlytoagree on the topic via which they will be interacting and the format of the messagespublishedonthattopic.ForcommunicatingviaaRESTinterface,thereneedstobeawayforone micro-service to find another micro-service it wishes to invoke. For that purpose, aservice discovery component may be deployed. Such a component serves as a centralregistry of availablemicro-services, responding to queries about the location of a certainmicro-service. In actual deployments, this capability can be provided by packages such asNetflixEureka,amalgam8,orConsul.
Additional helping capabilities that may be employed in our environment consists of agateway,healthmonitoring,andlogging(ELKstack).
Dependencies User requirements, specification of pilot use cases and validationplan: the Use Cases will drive the processes and ultimately thearchitecture will be built to service those use cases, so a cleardefinitionisessential.
D7.1–V1.0
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
CriticalFactors • IncompleteUseCasedefinition:UCsmustbeclearlydefinedandwell understood to ensure the appropriate systems, processesand capabilities are put in place in the architecture.UCsmustincludecomprehensivescenariosandvalidationplanstoensurethearchitectureisbuiltcorrectlytospecifications.
• Incomplete service definition: each of the technicaldevelopmentWP is responsible fordefiningtheserviceAPI forcomponents related to its research. Failure to provide theAPIspecification in a timely and thorough manner can lead todelaysorerrorsindefinitionofthearchitecture.
Table33:Architecturedefinitionsummary
3.5.3 Technicalinfrastructure
This implies the provisioning and operation of the infrastructure, onwhich the beAWAREsystemwillrun.Thisincludestheinternalservices,businessservices,associatedrepositoriesandexternalentities(mobileapplications,controlcenters).
IteasilyfollowsthatsomesubsystemsofthebeAWAREplatformcannotbedeployedtotheplatform, due to licensing reasons. Othersmay be dependent on secondary systems thatcannot be easily replicated in a different environment, or may require concentratedcomputingpowerthat isprovidedbyahighlyspecializedexpertsysteminapartner’sdatacentre.Insuchcases,proxyserviceswillbebuiltbypartnersandexposedtotherestoftheplatform.Proxyserviceswilldelegateworktotheactualservicesanddoanyextraworkasrequiredinatransparentway.
CriticalFactors • Distributed infrastructure: parts of the infrastructure areforeseentobedistributedandincludesystemswhicharerunin-house by some partners. Issues with firewalls, authentication,etc.aretobeexpected,andacteduponasneeded.
• Performance: the scope and complexity of the beAWAREprocesses and the size of the data to be handled is not yetknown and is likely to evolve as research progresses.Performance problems may arise, and resizing and/orprovisioningofextracapacitymayberequired.
CriticalFactors • Changingrequirements:UseCasesshouldremainstableduringthe project. While minor changes are always to be expected,major breaking changes may cause throwing away work thathasalreadybeendoneandimpactondeliverycapabilities.
Table35:Systemdevelopmentsummary
3.5.5 Communicationbus
The communication bus serves as a central point of communication between differentsystem components. Its main mode of operation is that of publish / subscribe, whichsupports different parts of a composite application to be unaware of each other but stillmanagetocommunicateuponneed.Theonlyitemsthatneedtobeagreeduponbetweenapublisher and a subscriber is the name of the topic (channel) throughwhich theywill becommunicatingandtheformatofthemessagesflowingthroughthattopic.
Theproposedbusisinchargeofnotifyinginterestedandregisteredcomponentswhennewitems which are of interest to them have been received or calculated by anothercomponent. In addition, the bus may perform some light transformations on incominginformation,uponneed.
The communication bus will be configured, upon deployment, with the necessary set oftopics as agreed upon between the different components. In addition, the messagestructure of each message in each topic will be agreed upon and documented by thecooperatingcomponents.Thecommunicationbusneedstosupportthenumberofdifferenttopics required for a beAWARE installation, along with the associated aggregatedthroughputinalltopics.
This project has received funding from the European Union’s Horizon 2020 research and innovation program under grant agreement No 700475
3.5.6 End-usersapplications
Therearetwoend-userapplicationsformobiledevices(smartphonesortablets):oneusedby the first responders and one used by the public. These mobile applications willcommunicatewithabackendthatwillconnecttotherestofthebeAWAREsystem.
With these applications, the first responders can communicate with the PSAP, sendinformationabouttheemergencyevent, receivetasksandreportonthoseassignedtasks.Thepublicwillbeabletoreceiveinformationaboutemergencyeventsandsendinformationabout theevent to thePSAPusing the communicationbus.Both first responders and thepublicwillbeabletosendtext,image,videoandvocalinformation.
Theoverall strategy for thedevelopmentof thebeAWAREplatform is tostartwithsimplescenarios and proceed stepwise towards the final system. The detailedwork plans of theindividualmodulespresentedinSection3willfollowthegeneralcycle:afterthecompletionofeachprototypeversion(timingdefinedbyMilestones),thefunctioningoftheprototypeisassessed, the needs for further development are identified and agreed upon, a detailedworkplanforthenextprototypeversionisfinalizedandthedevelopmentcycletowardsthenextprototypeisinitiated.Oneimportantpredefinedconceptforthedifferentprototypesisthedefinitionofthepracticalusecaseseachprototypeisserving.
4.1 Scenario1:FloodTargetgroup:
In each development cycle different user groups (target groups)will be involved in pilot-testinginareal-worldenvironmentandwithreal-worlddata:
• Support the collection and visualization of spatially distributed and multi-sourcedinformationrelatedtoafloodemergency(floodreports,weatherforecasts, floodearlywarningsystemresults,elementsatrisk,extensionoffloodedareas,crisisclassificationbasedonallavailabledata).
D7.1–V1.0
Page47
• Enable the automatic detection of flood hazardous situations, such as river levelovertopping/breaking.
• Provideauthoritieswiththeabilitytomanagefirstresponderassignments.• Facilitate the communication between authorities and citizens, also in different
Τhe target groups listed below are those who will use and interact with the beAWAREplatforminthephaseofpreparednessandresponseduringaforestfireemergency:
• Provide visualization on incoming information (mobile apps, videos, calls, textmessages,sensors,socialmedia).
• Givetheabilitytomanagethetasksassignedtothefirstrespondersandtrackthesetasks, as well as personnel and material to allow appropriate mobilization andcoordinationofresources(watersupplyetc.).
• Provide information about the fire and weather conditions (development, flameheight,winddirection,droughtindexetc.).
• Provide information to the public (safe locations, safe evacuation directions/ways,warnings,forbiddenactivities/behaviors).
4.3 Scenario3:HeatwaveTargetgroup:
The target groups listed below are those, who will use and interact with the beAWAREplatforminthephaseofpreparednessandresponseduringaheatwaveemergency.Thesegroupsarecategorizedbasedontheirgeographicallevelofinvolvement.
• Assigntaskstofirstrespondersandevaluatetheirdevelopmentinrealtime.• Monitorheatwavedevelopmentandtheweatherconditions.• Keepingtrackofpersonnel,volunteersandequipment/vehicles.• Allowingtheappropriatemobilizationofresources.• Monitortrafficconditionsinordertomobilizefirstrespondersmoreeffectively.• Monitor the level of occupancy in places of relief that are offered to general public
In this deliverable, the technical roadmap of the beAWARE platformwas presented. Thisdocumentwillguidethedevelopmentof theprojectwithaviewtoattainingthescientificandthetechnicalobjectivesenvisaged.
However, since the project is following an iterative development procedure (use cases-requirements-development-evaluation),itisexpectedthatsmalladaptationsanddeviationsfrom the initial technical specifications and the module functionalities foreseen by thisdocumentwillbeneededtosatisfy the finaluserrequirements.Suchchanges/adaptationsmightberequiredatcomponentorsubcomponentlevel.Theplatformarchitecturetogetherwith the detailed specification of the modules (including any updates required) will bereportedinD7.2(Systemrequirementsandarchitecture).