The Evolution of Disaster Early Warning Systems in the TRIDEC Project
•Transferir como PPT, PDF•
1 gostou•961 visualizações
The TRIDEC project (Collaborative, Complex, and Critical Decision Processes in Evolving Crises) focuses on real-time intelligent information management in the Earth management domain and its long-term applications. It is funded under the European Union’s seventh Framework Programme (FP7). The TRIDEC software framework is applied in two application environments, which include industrial subsurface drilling (ISD) and natural crisis management (NCM). For each domain, three consecutive demonstrators with extended capabilities are developed and field-tested during the projects lifespan. This article focuses on the technical advances achieved by the light-, mid- and heavyweight NCM demonstrators for Tsunami Early Warning.
Recomendados
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (20)
Semelhante a The Evolution of Disaster Early Warning Systems in the TRIDEC Project
Semelhante a The Evolution of Disaster Early Warning Systems in the TRIDEC Project (20)
Mais de Peter Löwe
Mais de Peter Löwe (20)
Último
Último (20)
The Evolution of Disaster Early Warning Systems in the TRIDEC Project
- 1. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Collaborative, Complex, and Critical Decision Processes in Evolving Crises •TRIDEC is a IT Research Project in the European Union’s Framework Programme (FP7) •New approaches and technologies for intelligent information management in collaborative, complex and critical decision processes in earth management. •This presentation focuses on the architecture developed for natural crisis management (NCM) and the light-, mid- and heavyweight demonstrators for Tsunami Early Warning.
- 2. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Tsunami Early Warning Systems (TEWS) TEWS are distributed software and hardware systems supporting – reliable detection of imminent tsunami hazards, – rapid situation assessment, and the – targeted dissemination of customised warning messages. TEWS infrastructures consist of •national (National Tsunami Warning Centre: NTWC); and •regional warning centres (Regional Tsunami Watch Centre:RTWC).
- 3. ISOPE-2013 Anchorage ISOPE-2013 Anchorage ICT Research and Development Strategy Information and Communication Technology (ICT) view of Tsunami Early Warning Systems: •integrated software- and hardware systems for •data acquisition, •decision making and •information dissemination, which •support the detection and analyses of imminent hazards and the dissemination of customised related warnings.
- 4. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Predecessor Projects 2005 – 2011 2007 – 2010 2010 – 2013
- 5. ISOPE-2013 Anchorage German Indonesian Tsunami Early Warning System (GITEWS) Focus: Sensor data integration Duration: 2006 – 2011 Funding: German Ministry for Education and Research (BMBF) Distant Early Warning System (DEWS) Focus: Information logistics Duration: 2007-2010 Funding: EU (FP6) Predecessor Projects
- 7. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Architectures and Application Development • Concept and Design of a reference architecture for tsunami warning systems based on the TRIDEC service infrastructure • Application Development – Establishing a service orchestration platform to support sustainable crisis management and collaboration workflows – Specification and implementation of adaptive, autonomous and intelligent information management 7
- 8. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Spiral Model for Demonstrator Evolution 8 Y1 – Y2 – Y3 – Each yearly cycle comprises requirement analysis, design and development activities followed by test phases to validate the results repeatedly against the requirements. Year 1: Light weight Demonstrator Year 2: Middle weight Demonstrator Year 3: Heavy weight Demonstrator
- 9. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Design of Reference Architecture for Crisis Management Systems • Specification of Information Model • Identification of System Components • Specification of Interaction Scenarios, Tasks, Choreographies and Business Processes • System-of-Systems (SoS) design 10
- 10. ISOPE-2013 Anchorage ISOPE-2013 Anchorage TRIDEC Architecture Overview • The generic TRIDEC architecture describes a common layout for the sub-systems of a System of Systems to interact via a communication infrastructure. • A communication infrastructure based on a Message-oriented middleware (MOM) enables distributed applications and distributed systems in heterogeneous environments to communicate by message exchange. Red triangles: SoS sub-systems with their own data.
- 11. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Generic Architecture Components Display of the identified generic components for a generic decision support system.
- 12. ISOPE-2013 Anchorage Architecture for Natural Crisis Management 13 Decide & Act Downstream •Generation of customized warning information •Dissemination via different channels •Control actuators Decide & Act •Decision finding based on context analysis •Evaluation of alternatives •Initiation of warnings Upstream •Sensor data •Context information •Dynamic analysis
- 13. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Natural Crisis Management System Architecture – Concept 14
- 14. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Upstream / Decide and Act Architecture 15
- 15. ISOPE-2013 Anchorage Upstream / Decide & Act: Light weight and middle-weight systems 16 Year 1 Year 2
- 16. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Decide and Act / Downstream Architecture 17
- 17. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Service Oriented Architecture for Sensor Integration (Upstream)
- 18. ISOPE-2013 Anchorage ISOPE-2013 Anchorage End User Use Cases Natural Crises Management
- 19. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Collaboration for Natural Crises Management
- 20. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Roles and Tasks in the TRIDEC System of Systems
- 21. ISOPE-2013 Anchorage Tasks, Roles, and Conversations (Collaboration Model and Business Processes) 22
- 24. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Remaining Work • Extension of the System-of-Systems character (federation of distributed components, international communication of systems) • Integrate non-traditional tsunami signal detection approaches • Leverage intelligent information management 25
- 25. ISOPE-2013 Anchorage ISOPE-2013 Anchorage The road ahead / ICT Megatrends •Ubiquitous sensing, •integration of Earth Observation (EO) systems, •volunteered geographic information (VGI), and •cloud computing However, for any kind of early warning system, it will be critical to prove that the range of functions can also be reliably offered as cloud-based software services.
- 26. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Conclusion • Information and communication technology (ICT) has become the driving factor for Tsunami Early Warning Systems (TEWS). • IT concepts such as service-based architecture (SOA), system of systems (SoS), middleware and semantic services enable standards-based software infrastructures for national and regional TEWS. • The TRIDEC software framework is used for local TEWS instances in the North East Atlantic / Mediterranean (NEAM) region to be connected in a system of systems.
- 27. ISOPE-2013 Anchorage ISOPE-2013 Anchorage Thank you for your attention
Notas do Editor
- The GITEWS project (German Indonesian Tsunami Early Warning System), funded by the German Federal Ministry of Education and Research (BMBF) addressed the challenges of early warning for near-field Tsunami with limited reaction times (Lauterjung et al. 2010; Fleischer, 2010). This was complemented by the DEWS project (Distant Early Warning System), funded under the European Union’s sixth Framework Programme (FP6), which focussed on both the multi-channel warning dissemination in a multi-lingual environment and the communication between warning centres in South East Asia (Hammitzsch et al., 2009) . Both projects took on the task to develop an overall generic architecture for TEWS based on best practices and the results of international standardisation activities in the geospatial domain and the information and communication technology (ICT) community. This included both service-oriented architecture design based principles and specifications from the Open Geospatial Consortium (OGC) for geodata sensors and measurements (Percivall, 2010). The projects also laid the foundation for the design of collaborative decision-support environments such as those investigated in the TRIDEC project.
- Demonstration in two scenarios: Tsunami Early Warning System (Natural Crisis Management): Important for public authorities Drilling Operations (Industrial Subsurface Development): Important for industry
- The research and development activities of TRIDEC follow a spiral approach consisting of three cycles in total. Each cycle comprises requirement analysis, design and development activities followed by test phases so that the results of the project can be repeatedly validated against the requirements of the respective user domains. The TRIDEC Natural Crisis Management (NCM) demonstrators address collaborative information management and decision-support processes in a hypothetical natural crisis situation caused by a tsunami in the North East Atlantic/ Mediterranean (NEAM) regions. The quality levels, functionality and complexity of the NCM system and application demonstrators are increasing step by step and are driven by the cyclic development process. In addition to the task to provide early warning on a national scale, it is paramount to provide such service also on a supra-national scale for the affected ocean basin. This requires a collaborative regional infrastructure, integrating the differing national infrastructures and decision taking approaches, to enable appropriate and reliable early warning dissemination for affected nations. During the second phase of TRIDEC development cycle, research and development activities focused on the middleware, the knowledge base and the decision support components to enhance scalability and resilience: The light-weight TRIDEC system was extended towards a mid-weight system , including a shift of focus from a message-oriented-middleware (MoM) towards a more general system of systems (SoS) perspective. Consequently, enhanced core components, like the knowledge-base and decision support, were integrated as sub-systems to the TRIDEC MoM. Also, a full enterprise service bus and security services were implemented to allow operators of the data acquisition sites to help protect the confidentiality and integrity of their data. Additionally, prescribed work-flows for more extensive thematic services are supported. For the NCM mid-weight application demonstrator, the key objectives were the enhancement of the sensor integration platform (SSB) and the Command and Control User Interface (CCUI) to comply with the MOM and greater SoS concept and to investigate in the application of new sensors. Design changes necessitated by the performance, resilience and scalability modeling were included. Another key objective for the NCM mid-weight demonstrator was the deployment of installations to gain real-world experience: TRIDEC NCM software instances were installed at the Meteorological, Climatological and Geophysical Agency (BMKG) in Jakarta, Indonesia, the Kandilli Observator y and Earthquake Research Institute of the Bogazici University in Istanbul (KOERI), Turkey and the Instituto Portugues do Mar e Atmosfera (IPMA) in Lisbon, Portugal. The latter two installations were successfully used in the context of the NEAMWave 2012 exercise
- The overall TRIDEC architecture was planned with an emphasis on the federated nature of the overall system. In [Maier, 1998] the "leverage at the interfaces" is described not only as one of the fundamental principles for architecting system of systems but as the only one: When the components of a SoS are highly independent, operationally and managerially, the architecture of the SoS is the interfaces. There is nothing else to architect. The Internet is the interfaces, in this case the Internet Protocol (IP). Equally important is the definition of the common or shared data syntax and semantics. These interfaces include expected coordination of system behaviours as well as the actions (information exchange and trigger events) that serve to moderate the collective behaviour of the systems in the SoS.
- Please add here: A title regarding the respective task handled in this section (e.g., name of the task or topics you want to lay special emphasis on) What is the status of the task after year 2 What is the progress when compared against the objectives formulated in the DoW You can add as many additional slides as required
- To enable distributed applications and distributed systems in heterogeneous environments to communicate with each other a resilient Message-oriented middleware (MOM) was put in place. Subsystems are designed and implemented with different programming languages (e.g., Java, C#) and deployed on different operating systems (e.g., Linux, Windows). Such heterogeneity requires a standard and open communication layer that allows loosely-coupled and asynchronous communication between the heterogeneous sources.
- These components will be explained in the following sections. It should be noted that not always all of these components need to be present at a site, e.g. the 2 nd site might use a reduced setup with no data archiving but a control user interface.
- A layered architecture, consisting basically of a resource, service, orchestration, and application layer. This concept of functional integration relies on the principles of Service Oriented Architectures (SOA) as well on an integration concept, which is built on standardized encodings and protocols provided by Sensor Web Enablement (SWE). A SOA is determined by a layered architecture, consisting basically of a resource, service, orchestration, and application layer as shown. Functionality (e.g. alert, task, notify, observe) required by the business processes on the application layer (e.g. Decision Support System) is provided by interoperable services (e.g. SAS, SPS, etc.) that follow common service oriented principles, as service contract, loose coupling, abstraction, reusability, autonomy, statelessness, discoverability, and composability. A SOA also orchestrates services to execute specific processes of the application domain, which might be supported by execution languages or workflow engines. The conception of autonomous and loosely-coupled services enables the compilation and reusing of services within the production of manifold multi-hazard systems. Bild: SOA Layers: The architecture of the Sensor Integration Platform as applied to GITEWS is depicted in Figure 20. Following a SOA the system architecture is separated into a sensor, service, and application layer.
- The Use Cases regarding Natural Crisis Management can be classified according the main processes and tasks which take place during a crisis and also during maintenance- and planning phase. The tasks as shown in Figure 6 can be processed autonomously which affects the architecture of the TRIDEC system to such an extent, that it is possible to assign them to geographically distributed systems which communicate on the basis of message exchange
- Collaboration between various, heterogeneous and geographically distributed participants can be modelled by the specification of the interactions which take place between them. The definition of collaboration specifies the various participants and their roles, as well as their activities which take place in certain interaction scenarios during crisis management. Collaboration relies on the standardised specification of messages and events which will be exchanged within the interactions between the participants.
- Conversations between Tsunami Warning Centres and Sensor Systems
- Coordination of work between spatially distributed systems for crises management implies providing support to a potentially high number of stakeholders and actors who play different and changing roles within a crisis and who require individual access to a multitude of resources – including other actors – in order to be able to make timely and well-founded decisions. Events via the MOM trigger standard or locally adapted workflows and rule sets on each of the nodes of the network. This kind of message-based event processing allows for complex and rich choreographies where each node can react specifically in accordance with local rules as well as on global constraints. The encoding of rule sets and the adaptation of workflows is carried out by the domain experts.
- Upstream SIP/TSB MOM compliance (seismic observation) Sensor System Management (management and maintenance of sensors) Geohazard Android App (user reports) Crowd-mapping platform (user reports) Micro-blogging platform (tweets) Decide & Act CCUI (usability improvements and new functionality) AAIS (generic access to spatial data, e.g. criticality analysis) SPC (updated and new spatial data infrastructure) On-demand simulation computation and MSDB extension by integrating product of other providers Downstream Information Logistics (re-design and) Information Dissemination (channel adapters and improvements) System monitoring Spurtracer (active monitoring) Nagios adoption (passive monitoring)