Development of tsunami early warning systems and future challenges

. Fostered by and embedded in the general development of information and communications technology (ICT), the evolution of tsunami warning systems (TWS) shows a signiﬁcant development from seismic-centred to multi-sensor system architectures using additional sensors (e


Introduction
The Boxing Day Tsunami in 2004 triggered various international efforts focused on tsunami early warning for the Indian Ocean Basin.Stimulated by developments in the field of tsunami science and information and communications technology (ICT), the technological concepts of tsunami early warning systems (TWS) have been improved considerably.The warning system architecture has been specifically addressed in two complementary projects: firstly, German Indonesian Tsunami Early Warning System (GITEWS), funded by the German Federal Ministry of Education and Research BMBF, and, secondly, Distant Early Warning System (DEWS), a European project co-funded under FP6.The development is continued by the FP7 large-scale integrated project Collaborative, Complex and Critical Decision-Support in Evolving Crises (TRIDEC).
The objectives of GITEWS included the design and implementation of an operational warning system and also training and capacity building activities (Lauterjung et al., 2010a).GITEWS was the first tsunami warning system that explicitly introduced the multi-sensor approach into near-field TWS (Behrens et al., 2010).With a response time of 2-3 min, the seismic system is a core component of near-field TWS and is expected to issue a warning in just few minutes after an event (Kamigaichi, 2009;Hanka et al., 2010).The integration of continuous near real-time global positioning system (cGPS) arrays is important for the acceleration of earthquake detection (Falck et al., 2010).Other sensor systems, GPS-buoys and coastal tide gauges (Schöne et al., 2010a, b) provide direct measurements on wave propagation and thus further constrain forecasting uncertainty.In order to integrate these heterogeneous upstream sensor data flows, an integration platform for sensor systems, the GITEWS Tsunami Service Bus (TSB), has been implemented (Fleischer et al., 2010).
Complementary to the TSB, DEWS addressed the downstream flow of information from a TWS to different types of message recipients.For this purpose procedures and components for the dissemination of customised warning messages and tsunami bulletins in a multilingual environment, suited for a broad range of individual message recipients, have been developed.Additionally, the information flow between national TWS in the Indian Ocean Basin (i.e.Indonesia, Thailand, and Sri Lanka) has been analysed and a basic concept for a wide area warning centre communication has been developed.
Both projects delivered contributions for the drafting and promotion of an initial concept for a service platform for TWS and developed a set of modules for the construction of warning centres in general.These results provided substantial input for TRIDEC focusing on new concepts of ICT for real-time intelligent information management in Earth management.One key topic is the design and implementation of a robust and scalable service infrastructure supporting the management of crisis situations, e.g. in the context of and resulting from tsunami disasters.The event-driven behaviour of this type of complex infrastructures is of special importance for the design and the core components of the TRIDEC architecture.
All research and developments activities have been and will be guided by the ongoing work of Intergovernmental Oceanographic Commission of UNESCO (UNESCO/IOC) on the implementation of tsunami warning systems.Intergovernmental Coordination Groups responsible for the implementation of regional tsunami warning infrastructures (e.g.Intergovernmental Coordination Group for the Indian Ocean Tsunami Warning and Mitigation System (ICG/IOTWS) or the Intergovernmental Coordination Group for the Tsunami Early Warning and Mitigation System for the North-eastern Atlantic, the Mediterranean and Connected Seas (ICG/NEAMTWS)) have developed concrete implementation plans, including service levels and performance indicators (UNESCO, 2011;ICG/NEAMTWS, 2011).
In this paper we present the results of our research and development activities in the field of TWS with the specific focus on system architecture and system components.In Sect. 2 we will address aspects of the architecture of tsunami warning systems in general, including design criteria, information flows and main architectural building blocks.Subsequently, in Sects.3, 4, and 5, the building blocks and main components are described in detail.The paper concludes with an overview about future challenges for tsunami warning system technology.
2 Architecture of tsunami warning systems

Design criteria
TWS are long-lasting and successively evolving systems.In their life-time new sensor systems, as well as decision support and warning dissemination components, will be developed.Old components therefore have to be replaced, and both new functionality and improved software versions have to be deployed.Beyond that, it is probable that business processes and operational procedures have to be modified or added (Häner and Kriegel, 2008).As a consequence the architecture of tsunami warning systems has to be flexible and adoptable by complying with the following design criteria (Erl, 2008): -Abstraction and encapsulation of data and functionality on data in standardised services: the access to the proprietary sensor data can be achieved via well-defined interfaces specified in appropriate service contracts.Interfaces that can be used in TWS to access heterogeneous sensor systems are comprehensively described in the Sensor Web Enablement (SWE) specifications of the OGC.
-Loose coupling of system components: coupling refers to the degree of direct knowledge that one component has of another and aims at resilient relationship between two or more systems and components.Loose coupling reduces the risk that a change made within one component results in unanticipated changes within other components.It also minimises the dependencies on each other to the least practicable extent.
-Location transparency of services: services can be provided everywhere and can be re-used in a federation of systems.Location transparency enables infrastructures that integrate proprietary and heterogeneous applications.Thus, it is possible to share and integrate resources beyond static utilisation to dynamically request information.
-Separation of concerns: breaking a system into distinct features that overlap in functionality as little as possible.This allows services to be commonly used and combined within different business processes.Thus, distinct components processing information independently can be utilised in other domains as well.
These criteria are adopted best by applying principles of the service oriented architecture (SOA) paradigm.A SOA is an integration concept (Josuttis, 2008) where functionality (e.g.alert, observe, plan, notify, process) is grouped around business processes (e.g.monitoring, decision support, or information logistics) and packaged as interoperable and standardised services.The SOA of GITEWS and DEWS has been realised with enterprise service bus (ESB) technology Upstream and downstream flow of events and information in early warning systems (Wächter et al., 2009;Lendholt and Hammitzsch, 2011).
providing a standards based integration platform for heterogeneous resources (Chappell, 2004).In particular, standards of Open Geospatial Consortium (OGC) and Organization for the Advancement of Structured Information Standards (OA-SIS) have been incorporated.

Information flows
According to USIOTWS (2007) the key operational components of a TWS are to provide real-time monitoring, alert of seismic and tsunami activities, timely decision making, and dissemination of tsunami warnings, advisories, and information.A TWS enables and controls upstream and downstream information flows.The overall information flow includes three segments (Fig. 1): 1. Upstream: acquisition of sensor data and transmission to the warning centre, including processing and event detection; 2. Decide-and-act: information flows within the warning centre, including situation analysis, decision support and warning dissemination planning; 3. Downstream: preparation of customised tsunami messages for the dissemination via selected channels.
The upstream information flow delivers observations about physical phenomena measured by sensor systems necessary for decision support processes into the warning centre.For each sensor system the upstream includes complex processing and transformation steps.Time series data measured by sensors have to be filtered and analysed in order to extract relevant events for decision making.The resulting aggregated data sets represent the input important for the decision support components of the TWS.The concrete decision processes are executed in the decide-and-act segment of the overall information flow.In this segment sensor events have to be analysed in order to determine if a tsunami has been triggered.Depending on this decision, the concrete risks for defined coastal areas have to be determined.This process is supported by what-if prognostic tsunami propagation models delivered by the simulation component.Based on this input the downstream information flow includes the transformation of tsunami hazard information into customised warning messages and situation reports delivered to defined target groups, including authorities, the public in case of emergencies, and other regional as well local warning centres.

Overall architecture
Following a simplified SOA model, a warning system supporting the information flows outlined above consists of three layers (Fig. 2).The basic layer comprises a pool of resources including, for example sensor systems and compute servers, as well as databases for spatial data and context information and also access points to warning dissemination channels.These resources are accessible via a set of services: -Sensor services for the monitoring of earthquake activities and sea level changes make use of services specified in SWE documents of the OGC.
-Decision support services support the detection of tsunami and the planning of warning activities, and associated components and services support prognostic modelling and the management of context information.
Standardised OGC Web Services (OWS), i.e.Web Mapping Service (WMS), Web Processing Service (WPS), and Web Feature Service (WFS) help to create the overall situation picture and support the prognostic tsunami wave simulation.
-Information logistics and dissemination services handle the downstream information flow and are responsible for compiling and disseminating customised warning messages.OASIS standards, mainly the Common Alerting Protocol (CAP) and the Emergency Data Exchange Language -Distribution Element (EDXL-DE) provide the foundation.
Based on this service platform, the top layer is represented by application components offering the required warning centre functions for the operation of the system via graphical user interfaces, concretely the Command and Control User Interface (CCUI).Figure 3 maps the upstream, decide-andact, and downstream segments to system components.The CCUI links the upstream and the downstream information flows of the TWS (Lendholt and Hammitzsch, 2011).The sensor platform, map services and simulation systems, embedded in and contributing to the upstream information flow and its processing, are connected to the CCUI.The detection of tsunami hazards is based on upstream information delivered from earthquake and sea level monitoring systems.
The CCUI desktop application provides an interface for the visualisation of hazard specific data and additional context information.By integrating the prepared upstream information, the operator on duty is enabled to perceive and analyse the current situation, to determine the hazard status in relevant coastal areas and in case of need to initialise the targeted dissemination of customised warning messages (Hammitzsch and Lendholt, 2011).The other main function of the CCUI is the management of downstream activities, including the generation and dissemination of specific customised warning products for defined target groups.

Information processing
The upstream information flow from the sensor system to the warning centre is characterised by a stepwise processing of raw event data coming from the sensors into decision relevant information that is used in the warning centre.Processing includes the filtering of time series data and the extraction of significant changes (i.e.events).Additionally, the upstream process includes the merging with other events and the amendment of context information (e.g.sensor status data).Signals measured by the sensor are transformed into context and decision relevant information.For example, irregular signals extracted from Earth tremor measurements of geographically distributed geophones are combined and become earthquake information.Upstream information processing results in a considerable reduction of data volumes.
Table 1 summarises the information refinement in GITEWS for different sensor types.The columns represent the different types of sensor systems, i.e. seismic (Hanka et al., 2010), buoy and ocean bottom unit (Schöne et al., 2011a), tide gauge (Schöne et al., 2011b), and cGPS (Falck et al., 2010) systems.Vertically, from the bottom to the top, the sequence of processing steps and their respective results are displayed.For example, the tide gauge system collects water level data using three independent sensors (radar, float, pressures) reducing the risk for a complete sensor failure caused by the impact of a tsunami wave.The different data streams are then packaged and distributed by the sensor station to the tide gauge system of the responsible agency, forwarding it to the national TWS.In its turn the tide gauge system integrates the incoming three raw data streams into a single sea level measurement (at a given place and time).By examining the resulting time series for anomalies, the tide gauge system eventually alerts the TWS if any anomalies were found.

Sensor integration
In general, all sensor measurements observe physical processes that have to be processed to obtain high level event data suitable for detecting emerging crisis situations, thus providing the necessary input for the planning and coordination of other crisis-related activities.For meaningful tsunami detection, it is necessary to include different auxiliary sensors that increase or even decrease the value of the basic observation.Most of the sensor system platforms therefore evaluate signals from different sensor types.An automatic pre-processing is often performed on site.This logic step provides a major advantage.Data from different sensors can be combined in order to extract the relevant information for tsunami warning purposes.For example, a sensor system may drop invalid measurements or even pre-calculate data Fig. 3. Upstream, decide-and-act, and downstream segments unfolded and mapped to system components (Lendholt and Hammitzsch, 2011).
Table 1.Summary of data refinement levels for GITEWS sensors.Data volumes decrease from raw data (bottom) to aggregated data (top) suited for complex decision processes in warning centres. of many sensors to transmit only essential information to the TWS.A good example is the measurement of a buoy's tilt and inclination to determine the position offset between the GPS antenna and the water surface to correct the GPS measurement (Schöne et al., 2011a).
Another important approach for smooth sensor integration is a standardised interface between the warning centre and sensor systems.Despite the fact that most sensors have their own (proprietary) protocols for data exchange and commanding, the sensor system provides a high level of abstraction to receive commands or requests from the warning centre.
In order to switch to a high resolution measurement mode, a sensor system is commanded by the warning centre.The mode change for each single sensor of the system is performed autonomously on site.Hence, a sensor system does not only comprise a set of sensors and a power supply, but also provides the first level of abstraction that is needed for the execution of its specific tasks within a TWS.
In order to manage different sensor types and a large quantity of sensor systems, the TSB was introduced in GITEWS as an intermediate layer to provide the required flexibility for sensor integration (Fleischer et al., 2010).Additionally, this layer offers a uniform interface for end-user applications, e.g. the decision support system.The implementation follows the paradigm of SOA by using SWE standards and services (Fig. 4).The SWE-based TSB framework accomplishes the integration task by providing a set of services: -the Sensor Observation Service (SOS) for obtaining sensor observations; -the Sensor Planning Service (SPS) for tasking the sensors; -the Web Notification Service (WNS) for asynchronous messaging; and -the Sensor Alert Service (SAS) for sending alerts.
In general, all TSB interfaces were designed as simple as possible by concealing the proprietary data formats and functions that are used inside specific sensor systems (Fleischer et al., 2010).However, the advantages of SWE are only exposed towards the application side.In contrast, the sensor integration itself cannot be standardised and imposes individual solutions for each sensor type by implementing specific adapters.An even more difficult task of semantic integration takes place inside the TSB within the dispatcher component and its respective plug-ins.This central processing component analysis processes, stores, and publishes all incoming sensor data.Depending on the received sensor data type, the dispatcher chooses at run time the appropriate processing mechanism, provided by "plug-ins".The content, format, frequency, and size of the incoming sensor data or data streams are in general not restricted, as long as a matching plug-in exists.

Graphical User Interface (GUI)
An important component of a TWS is the command and control unit's GUI concentrating all relevant information offered to human operators for decision making.According to Hammitzsch et al. (2012), the GUI has to support operators performing their tasks in complex workflows successfully.In critical situations operators have to make proper and reliable decisions in a very limited time frame.The GUI of the command and control unit therefore has to work reliably and stably, providing the relevant information and functionality timely with the required quality.
The design of the operator's interface is essential in the development of any TWS to manage hazards effectively and also to facilitate and enhance the decision making processes.The CCUI is a rich client application based on the Eclipse Rich Client Platform (RCP) and the free and open source Geographic Information System (GIS) uDig (Hammitzsch et al., 2010).Wherever possible, the architecture of the CCUI component is based on accepted standards.OGC standard compliant services support the access to geo-spatial data, e.g.WMS and WFS are used to compose the situation picture.The simulation system identifying affected areas is integrated via a WPS.The warning message content is structured following the CAP.
Based on a typical TWS command and control workflow supporting plausible scenarios, a user interface has been designed and implemented based on the modular and dynamic approach of Eclipse RCP with so-called perspectives and views.All functionality associated with a large task in a TWS workflow process is supported by the specific perspective integrating views and editors to cover appropriately details connected to that task (Hammitzsch et al., 2012).In the CCUI four main perspectives, arranged in a workflow, support the operators in their duty to manage a tsunami threat covering objectives of a TWS, including hazard detection and forecast, threat evaluation and alert formulation, and alert dissemination of public safety messages as specified by UNESCO (2011).These requirements are implemented in a workflow including the following main perspectives: 1.The "monitoring perspective" provides the survey of a specific area and contributes an overall situation picture to the operator with geo-spatial information to track running events; 2. The "forecasting perspective" supports the operator in analysing different probable forecasts provided and selected by the simulation system based on available sensor measurements; 3. The "message composition perspective" (see Fig. 5) enables the operator to prepare and send warning messages or system messages; 4. The "dissemination perspective" provides a comprehensive overview of the status of disseminated messages sent through the different dissemination channels and allows observing all disseminations initiated for specific user groups.

Simulation system
The simulation system is another core component of a TWS.Its main goal is to provide current situation assessment and tsunami impact forecasting.For this purpose, the simulation system relies on available sensor data, on one hand, and numerical models, on the other hand.Modern numerical models provide high accuracy of tsunami simulation and hence have a high prognostic potential.They have been extensively tested and routinely used for many years in all TWS (Babeyko et al., 2010;Behrens et al., 2010).However, tsunami propagation scenarios are very sensitive to the initial conditions.Due to this reason, real-time sensor observations provide absolutely necessary feedback to adjust numerical models in order to provide a reliable tsunami forecast.
In case of a tsunami threat, the simulation system is requested to provide a prognostic model of tsunami propagation and impact.This model should be consistent with current sensor observations.With an increasing number of sensor observations, the forecasting becomes more constrained and hence more reliable.Reconciling of numerical models with sensor observations is usually performed by different ways of comparing model predictions for sensors with real sensor data.Reconciling could be done either in fully automatic mode as implemented in GITEWS (Steinmetz et al., 2010) or by means of direct interaction of the officer-on-duty as implemented in DEWS.
Traditionally, scenarios of tsunami generation and propagation are pre-computed for a large set of initial conditions and stored in a database of virtual scenarios.This is done due to the fact that computation of tsunami propagation scenarios is time-consuming and, hence, cannot be done "onthe-fly" in real-time during the early warning process.Despite its dominant use, the technique of pre-computed scenarios has several important drawbacks like sampling effects or expensive database management.That is why TRIDEC, in addition to the traditional database approach, also started to implement real-time tsunami simulations for prognostic modelling.Real-time simulations make use of new high performance computing techniques such as Graphic Processing Unit (GPU) computing.

Generation of customised warning messages
The specification of message formats and content is a central topic for the implementation and operation of regional and national tsunami warning infrastructures (e.g.NEAMTWS, 2011).Message types addressing both the public information and the communication between warning centres have been developed and validated in large-scale exercises (e.g.NEAMTWS-ECTE1, 2011;IOWave11, 2011).The complexity of warning messages concerning type and content will grow resulting from the extended focus of warning systems and the integration of other threats, e.g.local tsunamis or other marine physical hazards.Additional requirements are imposed by the properties of the last mile connectivity and the dissemination channels used, e.g.Web portals, TV broadcasting and narrowcasting, as well as SMS and email.Another important type of message contains technical Fig. 6.Overall concept for the information logistics of early warning systems (Lendholt and Hammitzsch, 2011).control sequences directly sent to automatic devices, e.g.power line switches (actuators).
The specification of a generic Information Logistics Component (ILC) is a main result of the DEWS project.Although similar technological concepts were realised for other, locally bounded projects, they have never been adopted to the realm of ocean-wide tsunami early warning systems.So the key challenge has been the development of a model that would serve in different geographic areas, for heterogeneous message recipient groups, such as rescue services, civil defence agencies, and civilians.The model provides message filtering strategies as well as multilingualism and different target group vocabulary.
The warning dissemination is initiated by the decision support component.The concrete generation of customized warning products is executed to another building block of the reference architecture, namely the ILC.The generation of hundreds or even thousands of tailored warning products is a resource-intensive task, which should be handed over to a scalable system.Moreover, the system architecture should be flexible to allow a replacement of one component without replacing the other.Therefore, the decision support application releases an initial warning message providing all relevant information of a present hazard.These so-called hazard centric messages (HCM) are taken by the ILC to generate user centric messages (UCM) customized to the needs of each identified message recipient.These warning products must be converted into dissemination channel-specific formats and protocols.The required conversion of UCMs into channel-specific products is based on the respective channel characteristics and is managed by the Information Dissemination Component (IDC).IDC channel adaptors convert messages into formats suited for respective dissemination channels (Esbrí et al., 2012).
Standards of OASIS are used to communicate warning messages by means of CAP and EDXL-DE between these components.While CAP is used to encode tsunami warnings, alerts and other official bulletins, EDXL-DE serves as a routing envelope with addressing information.The backchannel, the feedback information from ILC and IDC to the decision support application, is also realised by using EDXL-DE messages with domain-specific payload informing about the number of generated, disseminated, and processed messages.
The assembly of customised messages is based on a database that provides numerous pre-defined message templates in different languages, and in different granularity regarding the message content and its details.These templates have to be defined by the authority administrating the TWS and can be freely configured to serve certain needs, e.g. to comply with the official tsunami bulletin formats as specified by the UNESCO/IOC.For each registered recipient, the message generation is triggered only if the recipient's area of interest (AOI) intersects with the affected area defined in the HCM.Based on the given message type and settings of the recipient's profile, e.g. the preferred language and vocabulary, a specific template is chosen and event specific attributes are ingested into the message template.Sophisticated filtering strategies are applied by checking user thresholds against CAP criticality values provided in the HCM. Figure 6 outlines the ILC model (further details in Lendholt and Hammitzsch, 2011).

Information logistics in centre-to-centre communication
A main objective of the IOC Tsunami Programme is the integration of national TWS towards ocean-wide networks of early warning systems to ensure information exchange during tsunami events.The centre-to-centre communication in a system-of-systems requires a new generation of interoperable message products introduced by Lendholt et al. (2012).
The information flow in a system-of-systems setup between warning centres combines up-and downstream information flow of a standalone system (Fig. 7).Therefore, message exchange in crisis situations relies on both -sensor measurements such as sea level data and earthquake measurements; however, only pre-processed and verified data will be exchanged to ensure reliability and confidence among the different centres.As discussed, the OGC SWE standards are best suited to communicate sensor data and observations.
-warning products such as tsunami bulletins: bulletins are disseminated by authorities in the context of international warning networks and serve other warning centres in decision processes.As discussed, CAP serves all needs to transport both human readable messages as well as structured information for (automatic) postprocessing by other centres.
For setting up a network of TWS, the challenge is to combine both protocols into a common message format.This is realized by using EDXL-DE as container format for both message types.Special attention must be drawn to the spatial reference scheme used in tsunami bulletins.In national systems the coastal forecast points (CFP) are used by simulations as reference points for the wave propagation.These points are mapped to administrative units or coastal forecast zones (CFZ) to establish an adequate and well-known spatial reference for warning dissemination.However, in the international context such proprietary solutions are not suitable.Therefore, Intergovernmental Coordination Group for the Indian Ocean Tsunami Warning and Mitigation System (ICG/IOTWS) has introduced a standardised set of CFZs for the Indian Ocean to ensure interoperability among interlinked warning centres.The DEWS project has implemented a prototype for centre-to-centre communication based on these precedent-setting concepts (further details in Lendholt et al., 2012).
6 Future challenges

Current status
In the last decade tsunami warning systems have shown a significant development from far-field to near-field monitoring systems.With respect to architecture far-field monitoring systems are built upon seismic systems responsible for earthquake localisation.This input is used by simulation tools for predicting the tsunami wave propagation in the ocean in order to calculate available time frames for initialising appropriate reactions.For GITEWS and the specific geological setting for Indonesia, near-field warning systems with drastically reduced time warning activities had to be addressed.These increased performance requirements and the integration of additional sensor system resulted in more complex warning system architectures.The design of a sensor integration platform adoptable for additional types of sensors was an important step in the GITEWS project.These TSB upstream services were complemented in the DEWS project, and specific components for the downstream information management have been added.As a result, the GITEWS TSB has been extended to a service platform covering the complete range of services supporting the upstream and downstream information flows and as well as basic decision support processes.
In cooperation with national warning centres in the northeastern Atlantic, the Mediterranean and connected seas (NEAM) region and the Intergovernmental Coordination Group for the Tsunami Early Warning and Mitigation System in the NEAM (ICG/NEAMTWS), the TRIDEC project is addressing the design and implementation of a robust and scalable service infrastructure.TRIDEC supports the integration and utilisation of existing systems and resources.More than that, the resulting technology framework can be applied for the accelerated and flexible development of distributed information systems that are capable to handle increasing amounts of information in critical and complex crisis situations.

Unconventional sensors for rapid situation assessment
In addition to "conventional" sensor systems, such as in-situ sensor networks providing time series measurements from seismic sensors, tide gauges and deep water buoys, in recent years vast amounts of Web 2.0 content has become available, such as Twitter messages, YouTube videos and RSS feeds (Middleton et al., 2012).These Web 2.0 "unconventional" sensors provide rapid in-situ crowd-sourced measurement actually experiencing the crisis event, e.g. using mobile devices, albeit with variable quality and a high noiseto-signal ratio.The application of unconventional sensors for wide area monitoring of coastal areas based on the exploitation of crowdsourcing approaches and social media or local webcams is a very promising approach for TWS.
The main goal of these new types of sensors is to acquire additional information on tsunami wave arrival and the effects on the coastal areas.In this sense, unconventional sensors operate like "light-weight sensors" providing simulation units and decision makers with data on the wave propagation.The expected data quality of this type of sensors is lower compared to traditional sensor systems.However, the potentially huge amounts of covered coastal locations, especially in high-populated areas such as Mediterranean, will compensate these quality deficits.Additionally, the consequent distribution of high numbers of low-cost sensor systems including accelerometers will become of increasing importance, e.g. for deriving early damage estimations in crisis situations.

Test strategies in a system-of-systems environment
Tsunamis are rare but potentially very disastrous events often affecting many regions around respective ocean basins.According to the results of the communication test exercise NEAMTWS-ECTE1 (2011), all warning system elements must keep a high level of readiness so as to be able to act efficiently and effectively during fast-onset and rapidly-evolving natural disasters like tsunamis.Regular tests of TWSs are conducted in other regions as well, e.g. in the Indian Ocean (IOWave11, 2011) and the Pacific Ocean (PacificWave11, 2011).To maintain a high state of operational readiness and especially for infrequent events such as tsunamis, tsunami watch/warning centres and emergency agencies must regularly practice their response procedures.
Additionally, a complementary set of tests has to be designed and implemented focussing on the technological performance of the warning system and the warning system components.All system parts have to work properly to guaranty the availability of the system in case of a crisis.This includes sensor systems and dissemination channels and also other system resources, e.g.compute servers and storage systems as well as telecommunication lines.The performance of all components has to be validated against defined criteria.Especially in a system-of-system environment, the concepts of IT Service Management (e.g.OGC/ITIL, 2010) and the negotiation of and the compliance with Service Level Agreements (SLA) have to be considered carefully.Tests of the complete system have to be executed on a regular basis or in case of need, e.g. after new software components or new sensor systems have been deployed.
All tests will depend on and will be conducted with simulations i.e. computed data sets describing virtual tsunami scenarios.For these reasons the sound understanding of tsunami generation and propagation derived from historic events plays a key role for a comprehensive set of system tests.Test scenarios do not only have to cover simple test cases, but also complex settings.Tests and embedding training activities have to take place on all levels of warning infrastructures: regionally, nationally, and locally.

Event-driven architecture
The requirements for TWSs outlined above will have a strong influence on the design, implementation, deployment, and successful operation of future warning systems.System-ofsystems approaches have been agreed on for the concrete implementation of large-scale infrastructures, e.g. the Global Earth Observation System of Systems initiated and organised by the Group on Earth Observation (GEOSS, 2011).In the context of TWS special attention has to be paid to performance and robustness criteria safeguarding the agile reaction and flexible behaviour of this system-of-systems in crisis situations.A technological core objective therefore is the design and implementation of a robust and scalable service infrastructure supporting the integration and utilisation of existing resources as well as the management of very large volumes of data.
The intended evolution of today's TWSs to regional or even global system-of-systems will benefit considerably from new architectural patterns for information systems that have been designed for event-driven systems.Events result from changes or developments in the respective system environment.Event-driven architectures (EDA; Taylor et al., 2009) are the new paradigm for the design of this type of system.EDA are the specific application of SOA concepts in areas where independent, very loosely coupled systems have to cooperate and synchronise their activities in order to react properly on complex events, e.g. a large-scale regional tsunami.Key concepts and essential methods for CEP have been developed and published by Luckham (2002).
According to Moßgraber et al. (2012), a system architecture providing the blueprints to implement the system-ofsystems approach has to combine multiple technologies and architectural styles.At the bottom layer it has to reliably integrate a large set of conventional sensors, such as seismic sensors and sensor networks, buoys and tide gauges, and also innovative and unconventional sensors, such as streams of messages from social media services.At the top layer the architecture has to support collaboration on high-level decision processes and facilitates information sharing between organizations.The consequent application of workflows and decision tables for the organisation of processes in this level provides a considerable increase in the flexibility to adopt the warning system to specific requirements (Riedel et al., 2012).

From system-of-systems to multi-hazard warning infrastructure
Important requirements for the design of the TRIDEC framework are currently being developed in the UNESCO/IOC framework.The specification process of NEAMTWS (and its general architecture) is on-going (ICG/NEAMTWS, 2009, 2011; see also TOWS-WG, 2011 andUNESCO, 2011).The main structural elements and components of the architecture have been identified including their basic functionality, standard operational procedures (SOP), as well as interaction patterns between national and regional warning centres.
The NEAM region consists of sub-basins with individual conditions and challenges for tsunami warning.For each of these sub-basins, specific RTSPs/RTWCs (RTSP: Regional Tsunami Advisory Service Provider according to TOWS-WG, 2011; RTWC: Regional Tsunami Watch Centre according to ICG/NEAMTWS, 2011) could implement defined responsibilities by working as a hub and message broker for several NTWCs, respectively.The NTWCs are responsible for the management of tsunami crises on a national level.The NTWCs together with the National Tsunami Focal Points (NTFP) operate within their national legal framework and provide warnings, watches, and advisories to their citizens, and public and private agencies.These warnings are based either on the NTWC's own analysis of the situation, on the advisory messages received from TWPs or on a combination of all (ICG/NEAMTWS, 2011).As a result a future tsunami warning infrastructure in the NEAM region will be a system-ofsystems with a complex multi-layer architecture (Fig. 8).
The objectives of UNESCO/IOC even go beyond the perspectives summarised above.The Working Group on Tsunamis and Other Hazards Related to Sea-Level Warning and Mitigation Systems (TOWS-WG, 2011) is developing terms of reference for a global early warning infrastructure not only for tsunamis, but also expanding the existing infrastructures to other sea related hazards, and in cooperation with organizations such as Group of Earth Observation (GEO) and GEOSS to implement a global multi-hazard infrastructure (summarised in Lauterjung et al., 2010b).
Appendix A

Fig
Fig.1.Upstream and downstream flow of events and information in early warning systems(Wächter et al., 2009;Lendholt and Hammitzsch, 2011).

Fig. 2 .
Fig. 2. Schematic architecture of multi-sensor warning systems.The access to computing services, sensor systems, repositories, and distribution channels is realised via standardised interfaces.

Fig. 4 .
Fig. 4. High level sensor system integration by Integration Platform TSB.

Fig. 8 .
Fig.8.Architectural levels of a regional tsunami warning system.