User interface prototype for geospatial early warning systems – a tsunami showcase

. The command and control unit’s graphical user interface (GUI) is a central part of early warning systems (EWS) for man-made and natural hazards. The GUI combines and concentrates the relevant information of the system and offers it to human operators. It has to support operators successfully performing their tasks in complex workﬂows. Most notably in critical situations when operators make important decisions in a limited amount of time, the command and control unit’s GUI has to work reliably and stably, providing the relevant information and functionality with the required quality and in time. The design of the GUI application is essential in the development of any EWS to manage hazards effectively. The design and development of such GUI is performed repeatedly for each EWS by various software architects and developers. Implementations differ based on their application in different domains. But similarities designing and equal approaches implementing GUIs of EWS are not quite har-monized enough with related activities and do not exploit possible synergy effects. Thus, the GUI’s implementation of an EWS for tsunamis is successively introduced, providing a generic approach to be applied in each EWS for man-made and natural hazards


Introduction
The tsunami disaster affecting the Indian Ocean region on Christmas 2004 demonstrated very clearly the shortcomings in tsunami detection, public warning processes as well as intergovernmental warning message exchange in the Indian Ocean region (Esbrí et al., 2010). Wächter et al. (2011) outline that this event in 2004 triggered various international efforts focused on tsunami early warning for the Indian Ocean Basin. The activities resulted in considerable progress in tsunami science, in particular concerning sensor systems and tsunami modelling. Stimulated by innovations in the field of Information Technology (IT), the architecture of tsunami early warning systems -including software components and UIs -could be improved considerably. These aspects have been specifically addressed in two complementary projects: firstly, the German Indonesian Tsunami Early Warning System (GITEWS) funded by the German Federal Ministry of Education and Research BMBF, and secondly, the Distant Early Warning System (DEWS). The latter project (DEWS, 2008), co-funded by the European Commission under the 6th Framework Program (FP6), aims at strengthening the early warning capacities by building an innovative generation of interoperable early warning systems (EWS). The system is based on service-oriented architecture (SOA) concepts and on relevant standards of the Open Geospatial Consortium (OGC), the World Wide Web Consortium (W3C) and the Organization for the Advancement of Structured Information Standards (OASIS). Thus the system continuously gathers, processes and displays events and data coming from open sensor platforms to enable operators to quickly decide whether an early warning is necessary and to send personalized warning messages to the authorities as well as, if desired, the population at large through a wide range of communication channels. The system is independent of the hazard risk, so it can be applied to multiple situations (earthquakes, tsunamis, floods, forest fires, etc.). The version of the system presented here is designed for tsunamis, which are one of the most demanding hazards. If an earthquake relatively near the coast originates a tsunami, the first wave may reach land in a few minutes. The system is designed to allow operators to receive the necessary information, interpret it and launch an early warning with corresponding personalized messages in sufficient time to initiate and have time for evacuation procedures. Customized messages can be sent by more than ten dissemination channels: Short Message Service (SMS) to subscribers, SMS via cell broadcasting (under investigation and dependent on arrangements with local operators), e-mail, fax, narrowcast and broadcast television, Really Simple Syndication (RSS) feed, social media (Facebook, Twitter, etc.), instant messaging, Voice over Internet Protocol (VoIP), frequency modulation (FM) radio, Radio Data System (RDS) and sirens (Esbrí et al., 2010(Esbrí et al., , 2012. The system prototype developed in DEWS is the result of the committed collaboration of 20 partners in the European Union (EU), Indonesia, Sri Lanka, Thailand, Japan and New Zealand, combining qualified technological competence and application experience. Interoperability with international cooperation mechanisms was also taken into account, including decisions of the Intergovernmental Oceanographic Commission of the United Nations Educational, Scientific and Cultural Organization (UNESCO-IOC), to ensure relevance and transferability of results to other tsunami-prone areas. The main scientific and technical outcomes are the prototype for a National Centre (NC), intended for use at the national level; and the prototype for the socalled Wide Area Centre (WAC), intended for use at international level, in order to allow exchange of information among NCs and to act as an umbrella centre for the whole region. Wächter et al. (2011) report that these developments are continued by the project Collaborative, Complex and Critical Decision-Support in Evolving Crises (TRIDEC, TRIDEC, 2011) funded under the European Union's FP7. TRIDEC focuses on real-time intelligent information management in Earth management. The addressed challenges include the design and implementation of a robust and scalable service infrastructure supporting the integration and utilisation of existing resources, with accelerated generation of large volumes of data; these include sensor systems, geo-information repositories, simulations and data fusion tools. Additionally, TRIDEC adopts enhancements of SOA principles in terms of event-driven architecture (EDA) design. This will enable the communication and synchronisation of activities between warning centres on local, national and wide-area / regional levels.

Methodology
The command and control unit's graphical user interface (GUI) implementation of an EWS for tsunamis is successively introduced, providing an approach to be applied in other EWS for man-made and natural hazards. Thus, the underlying EWS software system architecture and a possible operator's workflow are presented based on existing preconditions and defined scenarios for validation. Then the general approach of a GUI for various aspects in the domain of EWS is contemplated in detail exemplarily for the GUI named Command and Control User Interface (CCUI) developed in the projects DEWS and TRIDEC. Finally, the significance of the application and assessment of the system are considered.

Preconditions
The development of EWSs that are people-centred, in particular systems whose warnings are timely and understandable to those at risk, is encouraged by the Hyogo Framework for Action 2005-2015(UNISDR, 2006b. To be effective, EWSs must be people-centred and must integrate four interrelated elements: (i) knowledge of the risks faced; (ii) technical monitoring and warning service; (iii) dissemination of meaningful warnings to those at risk; and (iv) public awareness and preparedness to act. Failure in any one of these elements can mean failure of the whole EWS (UN, 2006). Within these four inter-related elements, UN (2006) identifies the monitoring and warning services lying at the core of the system. They must have a sound scientific basis for predicting and forecasting and must reliably operate twenty-four hours a day. Continuous monitoring of hazard parameters and precursors is necessary to generate accurate warnings in a timely fashion.
Natural hazard monitoring and forecasting are carried out by specialized scientific agencies at national level responsible for the development of technical capacities for monitoring, detecting and warnings for hazards and their impacts (UN, 2006). For the technical monitoring and warning service element of EWSs, UN (2006) includes technical capabilities by means of operational warning services in the operational technical agencies responsible for effective monitoring and forecasting of severe events. Also, systems are referred to provide hazard forecasts and warning against impending disasters. For the monitoring and warning service element, a system should be established to verify that warnings have reached the intended recipients (UNISDR, 2006b). UN (2006) continues that, with respect to the dissemination and communication element, warnings must get to those at risk. Regional, national and community-level communication channels and tools must be pre-identified. The use of multiple communication channels is necessary to ensure everyone is reached and to avoid the failure of any one channel, as well as to reinforce the warning message. For effective communication systems and equipment installed, UNISDR (2006b) requests that: communication and dissemination systems should be tailored to the needs of individual communities (e.g. radio or television for those with access; and sirens, warning flags or messenger runners for remote communities); multiple communication mediums should be used for warning dissemination (e.g. mass media and informal communication); consistent warning dissemination and communication systems should be used for all hazards; warning communication technology should reach the entire population, including seasonal populations and remote locations; communication system should be two-way and interactive to allow for verification that warnings have been received, and should be complemented by equipment maintenance and upgrade programs implemented and redundancies enforced so that back-up systems are in place in the event of a failure. UNISDR (2006b) concludes that there are clear references to the importance of early warning, and to be effective, EWSs need to effectively disseminate messages and warnings.
For monitoring systems developed, UNISDR (2006b) moreover requests that networks available and agreed with experts and relevant authorities are monitored with data received, processed and available in meaningful formats in real time or near-real time, and that data routinely is archived and accessible for verification and research purposes. For forecasting and warning systems established, UNISDR (2006b) includes data analysis, prediction and warning generation with data and warning products issued within international standards and protocols. UNISDR (2006b) emphasizes that warning centres should be equipped with appropriate equipment needed to handle data and run prediction models and that measures should be implemented to routinely monitor and evaluate operational processes, including data quality and warning performance. Complementary, USIOTWS (2007) provides an overview of the key operational and organizational requirements of an EWS centre for tsunami as they currently exist at the two National Oceanic and Administration (NOAA) tsunami warning centres and at the Japan Meteorological Agency (JMA), including various links in the end-to-end chain, meaning from initial to final steps required for a successful system. These steps include data collection and monitoring, timely decision making and warning issuance with the dissemination of warnings, advisories and information (see Fig. 1). For the instance of a tsunami, EWS USIOTWS (2007) continues that the heart of an EWS is its operations centre. The primary mission of a full-service EWS centre is to provide accurate and timely tsunami warnings and bulletins to populations in its area of responsibility (AOR) 24 h per day, 7 days per week (24/7). To accomplish this mission, a EWS centre detects and analyses events throughout its AOR. Events that are above a previously established threshold activate the centre's alarm system and initiate an investigation that includes the following four basic steps: locate and characterize the event and its probability of creating a hazard; review automated analysis, and if necessary, modify the automated results; obtain continuous data from sites and sensors, to verify the existence of a hazard and to calibrate models; prepare and disseminate information to appropriate emergency management officials and others.
Furthermore UNESCO (2011a) specifies detailed requirements of the design and implementation for the Indian Ocean Tsunami Warning System (IOTWS). The overall objective of the IOTWS is to efficiently identify and mitigate the hazards posed by local and distant tsunamis. To achieve this objective, an end-to-end tsunami warning system (TWS) is needed that includes hazard detection and forecast, threat evaluation and alert formulation, alert dissemination of public safety messages, and preparedness and response (see Fig. 2).
These preconditions define clearly key components of an EWS centre whose system's components finally are exposed through graphical software tools. The preconditions have been considered in the developments of DEWS integrating partners of the Indian Ocean region from Indonesia, Sri Lanka and Thailand, and in the developments of TRIDEC integrating partners of the North-eastern Atlantic, the Mediterranean and Connected Seas (NEAM) region from Turkey, Portugal and Italy. Among others, the given preconditions form requirements on the EWS's architecture, the workflow and thus the GUI that is implemented. The findings on the architecture and workflow are introduced shortly to finally present an adaptable and extensible GUI for geospatial EWS exemplarily for tsunami early warning scenarios. The system prototype has been designed and implemented to support plausible scenarios for a National Tsunami Warning Centre (NTWC) and to demonstrate the treatment of simulated tsunami threats with an essential subset of a NTWC, covering operational as well as tsunami detection and alerting functions and demonstrating the feasibility and the potentials of the approach for the involved partner countries.
In terms of demonstrating the escalation of a hazard case comprised from operational to tsunami mode, the treatment of the tsunami is therefore divided into five phases. Phase 1 outlines the operational mode. Phases 2 to 5 describe the tsunami mode from earthquake detection to warning dissemination: -Phase 1 -Tsunami Monitoring: normal observations are performed and incoming information from the connected sensors and sensor systems are monitored.
-Phase 2 -Earthquake Detection: from the connected seismic sensor system, an initial alert with measurements and further refinements are received that indicate an earthquake at an ocean bottom trench in the monitored region has been detected. If the earthquake measurements received exceed certain magnitude thresholds, an initial warning message is created and sent to registered target groups.
-Phase 3 -Tsunami Assessment and Verification: based on the sensor measurements from the seismic system and additional sea level measuring stations, such as buoys and tide gauges, the simulation system is requested to provide a set of feasible pre-computed tsunami simulations. The monitoring continues by receiving further measurements of sensors which are compared to the set of simulations and clearly indicate that a tsunami has been triggered. Further tsunami simulation sets are inquired to match the new measurements received.
-Phase 4 -Compilation of Tsunami Messages: based on accurate sensor measurements received and based on the requested tsunami simulations, the situation picture is improved and affected areas are calculated providing data concerning the estimated severity. If a high probability for a tsunami event is detected and affirmed by accurate sea level measurements received, a warning message is composed and sent including information about estimated times of arrival and severity for different identified threatened areas.
-Phase 5 -Post Tsunami Communication: finally status bulletins are compiled and sent informing about the phased down tsunami threat, including detailed information such as measured wave heights at the coast and improved damage estimations.
The country reports of the DEWS partners in the Indian Ocean have shown that Indonesia, Thailand and Sri Lanka have reached different steps of evolution in the field of EWS, especially in deploying sensor systems for tsunami detection. Since Indonesia has had the largest set of installed sensors and one of the most developed organisational governmental structure to operate national EWSs, this country has been selected for demonstration and evaluation purposes, at first. Furthermore, Indonesia is located along the most prominent active continental margin in the Indian Ocean, the socalled Sunda Arc, and therefore is one of the most threatened regions of the world in terms of natural hazards such as earthquakes and tsunamis. Thus, Indonesia is characterized by its unique geotectonic position and the resulting consequences in terms of natural hazards. Accordingly, the specific geodynamic situation of Indonesia requires a tsunami early warning system (TEWS) which, on the one hand, takes into account the extremely short early warning times required, and on the other hand, takes on the challenge of producing reliable tsunami warnings immediately after an earthquake based on data with high uncertainties (Lauterjung et al., 2010).
Facing the Sunda Arc, not only Indonesia is potentially affected by possible tsunamis but also other countries such as Thailand. But contrary to Indonesia, Thailand is not dependent on extremely short early warning times immediately after an earthquake since Thailand is located further away from the Sunda Arc, resulting in longer tsunami travel times until reaching Thailand's coast. Thus, Thailand has the opportunity to use more time to refine successively latest sensor data affirming or disconfirming the occurrence of a tsunami and, if required, to evaluate the estimated destructiveness more precisely. So a second set of simulated tsunami scenarios have been selected for demonstration purpose covering the Thai coastline.
Both demonstrations, Indonesia and Thailand, are based on several feasible scenarios ( Fig. 3) and have been used as a means to evaluate the ability of the system within the parameters of DEWS to enable the partners as end-users in achieving their operational goals. The purpose of demonstrating the different scenarios is to showcase how the CCUI can assist the NTWC's operators in the process of receiving earthquake alerts, evaluating the tsunami probability and disseminating warnings to different receivers at risk of impact by a threatening tsunami. Within the parameters of TRIDEC, the scenarios have been extended to allow validation of the significantly improved version of the system for Turkey, and also for Indonesia within the framework of continued DEWS activities leveraging the results achieved in TRIDEC (see section below entitled Validation).

Generic early warning system architecture
One of the key challenges of the DEWS project is to build a new generation of open standard based EWSs that realize reliable hazard detection and effective warning dissemination. The project follows a multi-hazard approach, so that the application can be potentially used for all types of hazards. Moreover, it must be transferable to different geographic areas. So to realize these aims, a modular architecture with standardized interfaces has been designed and implemented: first, for the upstream to allow the integration of sensor systems based on open standards; and second, for the downstream comprising information logistics and warning dissemination also based on open standards. A simplified architectural blueprint (Fig. 4) provides an overview of the system architecture depicting major components.
Starting on the left in Fig. 4 you find: the Sensor Network with the seismic system, buoys, tide gauges and various other sensors; the Situation Picture Component (SPC) responsible for maps, geo-data and geo-processing services; and the Simulation System providing pre-factored forecasts of tsunami wave propagation. Hammitzsch and Lendholt (2011) describe that these three components -altogether compiling the upstream information flow -are connected to the CCUI with OGC standards. The CCUI harvests and exposes all necessary upstream information, enabling the operator on duty to analyse and understand the current situation picture, to manage a tsunami threat, and to make decisions for releasing reasonable warning messages.
The dissemination of warning messages is realized with a chain of components -altogether compiling the downstream information flow. Lendholt and Hammitzsch (2011a)  point out that the downstream comprising the message generation workflow is divided into three phases and components. Firstly, the CCUI releases an initial warning message without any specific message for recipients and independent from specific user settings. Secondly, based on the initial warning message, the Information Logistics Component (ILC) generates one customized message for each user and the respective dissemination channel. Thirdly, the Information Dissemination Component (IDC) converts the customized messages into channel specific formats and finally disseminates them to the message recipients.
UDIGAPP (2009) summarizes that existing standards as well as free and open source software have been integrated wherever possible. The CCUI, a rich client application based on the Eclipse Rich Client Platform (RCP) and the User-friendly Desktop Internet GIS (uDig), integrates various OGC services. Using OGC Web Map Service (WMS) and Web Feature Service (WFS), spatial data are utilized to depict the situation picture and to integrate a simulation system via OGC Web Processing Service (WPS) to identify affected areas. Warning messages are compiled and transmitted in the OASIS Common Alerting Protocol (CAP) standard together with addressing information defined via OA-SIS Emergency Data Exchange Language -Distribution Element (EDXL-DE). Internal interfaces are realized with Simple Object Access Protocol (SOAP) web services.
In TRIDEC, Häner et al. (2011) reconsider that the key challenge is establishing communication infrastructures of interoperable services through which management of dynamically increasing volumes and dimensionality of disparate information is efficiently possible. To this end, a future architecture will be based on SOA 2.0, an eventdriven extension of SOA principles. This approach supports creating high-level business events from low-level system events. Events are created by analysing real-time data from services, business processes including service chaining, or system components and enhanced with details such as dependencies or causal relationships discovered by correlating other events and additional information. This process is facilitated by applying data-fusion and pattern-matching techniques as well as know-how derived from various knowledge bases, each covering domain-specific information. This approach supports and improves decision processes in evolving crises. Even more important, this allows collaborating systems to respond dynamically in real-time, automate decision processes, or to autonomously take actions like serviceorchestration and -choreography to react on unique event patterns. The architecture also enables evolvement and evolution of systems by facilitating long-running processing capabilities, e.g. data-mining of information from various asynchronous events, time series, information networks, numerical models, messages, or human feedback as well as the deduction of patterns, trends, and rules over a long period of monitoring.

Command and control workflow
In a first attempt, a minimal but well thought-out and consistent user interface should be the base for the implementation of a NTWC. The modular and dynamic approach of Eclipse RCP with perspectives and views leads to a base design and implementation of the CCUI that can be adapted while using and assessing the CCUI in the real life target environment. Subsequently, adaptations, improvements and extensions can be realized in a moderate and agile manner successively by different adopters. As a central concept, Eclipse RCP allows the arrangement of functionality within the user interface by usage of perspectives and views. Perspectives show all functionality associated with a large task. Each perspective has a default layout with views and editors appropriate for that task. However, each perspective could have other views, supplied additionally or by other perspectives, that may provide helpful functionality to the particular perspective. If views and editors are moved within a perspective, Eclipse will remember the new layout but can be reset again to the default layout of the perspective. of the user interface allows operators finding the best layout according to their needs without fearing to lose the initially intended layout.
Based on this approach, the CCUI perspectives have to be identified and designed successively with their particular assembly, content and functionality as well as their interplay. Furthermore, the CCUI must be flexible enough to be used in different workplace scenarios. The situation in different warning centres is based on national sensitivities and properties in the deployment area. Therefore it cannot be estimated how many operators will work on how many screens. For example, one operator processes all tasks or many operators work together, each of them managing only a subset of the overall process. In each case the perspectives and views should dovetail each other and support the operators' workflow without interference in a consistent manner.
Following main perspectives might support operators doing their tasks in EWSs for man-made and natural hazards. 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. The Forecasting Perspective supports the operator in analysing different probable forecasts provided and selected by the simulation system based on available sensor measurements. The Message Composition Perspective facilitates the operator to prepare and send warning messages or system messages. 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. The Situation Picture Perspective provides a set of preconfigured and selected thematic map layers and allows incorporating dynamically additional information in the map to analyse specifics of a given situation. The Maintenance Perspective enables the operator to maintain sensors and sensor networks by means of requesting sensor observations, planning services as well as rebinding and disconnecting them. The Administration Perspective allows the administration of configurations and settings needed for the information logistics. As depicted in Fig. 4, the CCUI is a central component, allowing the operator to access and interact with the different resources and functionalities provided by the system. The System Monitoring Perspective allows monitoring of the system itself to ensure its proper operation.
Summarized four perspectives (Fig. 5) of the CCUI support the operators in their duty to manage an imminent threat such as a tsunami: the Monitoring Perspective, the Forecasting Perspective, the Message Composition Perspective and the Dissemination Perspective. Additionally, various wizards accelerate the operator's work with automatic operations within these perspectives. Finally, the Situation Picture Perspective, the Maintenance Perspective, the Administration Perspective and the System Monitoring Perspective help the operators to carry out surrounding tasks done in advance, while or after an imminent hazard threat.

Monitoring Perspective
The Monitoring Perspective depicted in Fig. 6 provides a survey of a specific area and contributes an overall situation picture to the operator with geo-spatial information displayed in a central map, with additional details contained in multiple views surrounding the map. Additionally, the Monitoring Perspective provides a user interface to track on-going incidences with different events reported by the system with its sensors, sensor networks and other connected warning centres as well as with other system components able to report a status such as the simulation system. An event could be an earthquake detected by a seismometer, an anomaly detected by a pressure sensor at the ocean floor or simply a message from a sensor reporting low battery status. Thus, the perspective keeps the operator up to date, supports the operator in analysing the respective situation and allows the operator making decisions based on all-embracing information. For that purpose events are classified by relevance relating to the situation and thresholds configured in advance and specific to the monitored region.
The reported events are the central elements in the Monitoring Perspective. So the events received must be visualized as incoming elements to the operator and they must be accessed with their respective information by the operator in a convenient and clear way.. Thus, the incoming events have a message-like character and could be managed according to a known pattern, analogously to an e-mail client inbox. So the vital view of the Monitoring Perspective is the Incoming Events View constituting the inbox of received events but also serving as a kind of history of past events. The events are organized by their time of occurrence so that the latest events are automatically displayed on top. Moreover, the listed events are provided with additional metadata, e.g. indicating that critical thresholds have been exceeded and that the possible effects are estimated to be of minor or major impact. Additional filter mechanisms restrict the list of events according to qualified criteria, emphasize related events and grey out events that are replaced by other events updating previous events. Also, the Incoming Events View enables the operator to track incidents opened and administered by the operator. An incident in a case of hazard management could be an earthquake or tsunami. But in a case of maintenance, an incident could be a sequence of events belonging to a cut lost buoy sensor or low voltage batteries of a distributed sensor network. So an incident in general is something the operator has to take care of. The operator opens an incident with one or more selected events and adds successively further events while monitoring the respective incident. Each incident is monitored with an additional Incoming Events View displaying the events assigned by the operator for the respective incident only and accessible via the tab list. Within each Incoming Events View, an additional tool bar and context menu provides tools and actions to work with on one or more selected events, e.g. an action to start a computation for the evaluation of probable forecasts based on one or more selected events. The Map View of the Monitoring Perspective is used to display the monitored area in a map, e.g. containing the bathymetry of the ocean floor, the topography of the coastal area and the respective sensors delivering sensor information to the warning centre. In case of a threat, further information is depicted in the map, e.g. in an earthquake case its location and magnitude are depicted. Later on, other perspectives used in the operator's workflow subsequently enrich the map with additional information, such as the tsunami wave propagation and affected areas in cases of a NTWC. The Map View is also used to display information with geographic context regarding to selected events in the Incoming Events View. Events, for example those originated by buoys or tide gauges, produce a graphical accentuation depicting the position, sensor type and event type; whereas events originated by seismic sensors produce a graphical icon depicting the position of the earthquake centre. Complementary, the Map Elements View lists elements contained in the map. Typical elements that appear in this list are sensors, geo-referenced events such as earthquakes, and affected areas generated during message composition. According to the selected event, further details are displayed in the Detail View in order to give a precise understanding of the respective event data. The appearance of this view strongly depends on the event type selected. For example, the information displayed could be description and measurements of one of the available sensors selected in the Map Elements View but also sensed earthquake information of a seismic alert selected within the Incoming Events View. Plus, additional metadata such as calculated information on the aftershock probability and status information can be integrated in the Detail View.
Finally, measured data are displayed in form of time series for the different sensors in the Time Series View. Graphs allow the operator to track successively the incoming data graphically depicted in this view. Thus the operator is enabled to investigate conveniently measurements of selected events or selected sensors.

Forecasting Perspective
The Forecasting Perspective depicted in Fig. 7 is used to support the operator in analysing the different probable forecasts (matching scenarios) provided by the simulation system. An operator might switch to the Forecasting Perspective manually or automatically by issuing a computation to retrieve probable forecasts with the measurements of selected events in the Incoming Events View of the Monitoring Perspective. Displayed the Forecasting Perspective provides following views: a view with predicted sensor time series compared to real measurements, a ranking list with probable predictions, a view with absolute and relative time measurements used for selected predictions, and again the map showing the result of the selected forecast as well as the event list known from the Monitoring Perspective. The Sensor Timelines View contains the predicted time series in one diagram for each sensor. Only available sensors within the geographic area of interest are considered and have been automatically defined as input for the simulation calculation. Each diagram for the respective sensor includes differently coloured graphs for each predicted measurement calculated by the simulation system and a graph in black representing the real time measurement of the respective sensor updated automatically when new measurements are available via incoming events. In this vein the operator is enabled to compare and approve the forecasts given by the simulation system with the real measurement. The predicted time series for each sensor are also listed in the two small boxes to the right of a chart. The box called Simulation Visibility is used to select all or only single time lines which should be displayed in the chart. The box called Simulation Weighting is important for the ranking of the probable predictions. While examining each timeline the selections performed in the Simulation Weighting box are summarized in the Ranking View. In the Ranking View the forecasts are simply ordered by the count of their selection done within the Simulation Weighting of each sensor graph. By this selection process the simulation with the highest probability leads to an optimal forecast result and can be used for the dissemination of warning messages. Each listed forecast might contain additionally details of the key information, e.g. the earliest estimated time of arrival (ETA) and the maximum of estimated wave heights (EWH) in cases of a NTWC. In this vein the most reasonable simulation forecast can be used for the computation of affected areas and finally for warning message dissemination.
The forecast selected in the ranking list is displayed in the Map View with coloured isochrones. The outlined isochrones represent the tsunami wave propagation in time between the earthquake occurrence and the impact at the coast. The distance between two isochrones accounts for a defined time range appropriate for the monitored region. Also, the isochrones are updated frequently to display the current position of the tsunami wave front as calculated by the selected forecast with an isochrone marked in red.
Finally the Time Measurements View integrates relevant time measurements and information. When selecting a forecast in the ranking list, updated information is displayed not only in the map but also in the time measurements. The time measurements provide the UTC time of the occurrence of the initial event of an incident, the present UTC time and the relative time difference between the event time and the present time as delta value.
The Forecasting Perspective also integrates and reuses the Incoming Events View introduced in the Monitoring Perspective. Since the selected events serve the input for the simulation calculation, the operator is enabled to trigger another simulation calculation based on the latest received events directly in the Forecasting Perspective.

Tsunami Warning and Dissemination Wizard
To start the dissemination process based on a forecast selected in the Ranking View of the Forecasting Perspective, a context menu and tool bar action is provided to start a wizard in a separate popup view to calculate affected areas and start the warning messages dissemination based on the calculated affected areas. This Tsunami Warning Dissemination Wizard depicted in Fig. 8 represents an automatic support system to identify affected areas on the basis of the best fitting forecast, since it is nearly impossible for the operator to check manually the forecast result with predictions for hundreds or thousands of coastal points and to analyse manually the situation for each area. Instead, the Tsunami Warning Dissemination Wizard automatically calculates ETA and EWH for each of the administrative areas. These values are used to categorize messages later on according to the different severities and urgencies based on the CAP standard . The operator configures additional CAP relevant attributes, adds a screenshot of the map, and then disseminates warning messages when finishing the wizard. Thus, warning messages are sent to user groups registered to areas of interest considering the area-specific predicted parameters such as ETA and EWH in user tailored warning messages as described in Lendholt and Hammitzsch (2011a).

Message Composition Perspective
The Message Composition Perspective depicted in Fig. 9 supports the operator to prepare, to send and to observe the initiated warning dissemination. This perspective is either opened by the operator to disseminate messages manually or it is opened automatically in the background when starting the Tsunami Warning Dissemination Wizard with a selected forecast.
The Map View still depicts the specific geographic region with the information provided by the other perspectives. The calculated affected areas are displayed additionally in the map according to the selected forecast. On the one hand, the automatically calculated affected areas are mapped to administrative areas and on the other hand free hand shapes manually selected by the operator with tools available in the tool bar can be added as well. Automatically calculated areas are coloured by the predicted threat level in accordance with the colour scheme recommended by the US Department of Homeland Security (Lendholt and Hammitzsch, 2011b). Red coloured areas are at high risk; less endangered areas are depicted in orange, yellow or blue. Selected areas are also listed with additional information in the Affected Areas View so that the operator is able to manage the affected areas and reuse them later on, e.g. when composing refined warning messages the listed areas serve as input for the message composition of the intended warning dissemination and are attached to a warning message.
Furthermore, the operator is enabled to take snapshots of the currently displayed map, which are stored in the Snapshots View and attached later on to a warning message providing an evident situation picture.
Moreover, this perspective contains an editable form considering elements of the CAP standard in the Message Composition View for the manual composition of warning messages. The operator selects a specific message type defining its own range of values for the message details. Then the operator selects the appropriate value for each message element in relation to the current situation, such as the affected areas and the map snapshots. All values except the snapshots are mandatory. Snapshots are optional and serve as additional information of warning messages distributed via different dissemination channels such as TV Overlay, Narrow Casting and E-Mail. Finally, the composed message is sent when each value has been configured appropriately and the operator has triggered the button for dissemination. Composed and sent messages are listed in the Disseminated Messages View with additional processing information. In that vein, the operator is enabled to track an initiated dissemination, e.g. to observe success or failure of processing the initial warning message. Each message can be reused as a template for a refined message later on and pre-sets the form values of the Message Composition View.
The Ranking View introduced in the Forecasting Perspective is also available to allow changing the selection of forecasts. In this vein the operator is able to switch between the different estimated wave propagations of the different forecasts and their respectively calculated affected areas to analyse the most feasible forecast for dissemination.
Again the Incoming Events View is included as well to allow tracking of current events and to provide updates with latest information of the monitored region.

Dissemination Perspective
The Dissemination Perspective depicted in Fig. 10 provides a comprehensive overview of the status of disseminated messages sent through the different dissemination channels with a Channel Status View for each of the channels. These views display detailed status reports received and aggregated from the respective telecommunication providers. The Dissemination Perspective is designed to be expandable dynamically with additional views to allow the addition of further dissemination channels not initially considered. Thus each view represents one channel and displays status information according to the on-going dissemination of warning messages. Additionally, one view aggregates information of all channels related message exchange between the dissemination infrastructure and the respective dissemination channel provider and displays a short summary of the status information.
Since the dynamic nature of this perspective is dependent on the available channels and each channel might be fundamentally different in various aspects, each channel view is configured simultaneously with the registration of the respective channel. Consequently, a set of common and understandable status report information is used for all channel types equally and represented in the views. Then the specific aspects of each channel such as the different number of providers, the different number of message recipients reachable by each channel or different status notification mechanisms, codes and scope for each channel are mapped to the simplified set of the views.

Other perspectives
By default, each EWS CCUI provides a set of preconfigured and selected thematic map layers with predefined styles and scales. But the operator should have the possibility to customize the layers depending to the situation or to incorporate dynamically additional information in the map to analyse specifics of a given situation. Thus, the CCUI is extended with the Situation Picture Perspective equipped with common GIS tools and connected to the SPC to allow further investigations with geo-spatial information. Thus, map layers with further geo-spatial information can be visualized additionally when requested by the operator.
The configurations and settings needed for the information logistics are administered with the Administration Perspective of the CCUI. The configuration comprises message types and message templates, message consumer profiles and user groups as well as dissemination channels and dissemination provider profiles as conducted in Hammitzsch and Lendholt (2011).
The Maintenance Perspective provides a user interface for maintaining all sensors and sensor networks by means of requesting sensor observations, planning services as well as rebinding and disconnecting them, and thus the perspective is highly dependent on the connected sensor network.
Finally, the System Monitoring Perspective integrates specific views enabling operators to observe and configure internals of the CCUI and other parts of the system. For example, different status information such as errors or warnings provided by different plug-ins of the CCUI monitor the behaviour of the CCUI. Also system errors can be detected and logged to allow technicians to investigate and fix detected problems. Analogously, all actions that have been taken by an operator during managing an incident can be recorded. This could be valuable information in order to investigate and replay the performed actions as well as to use for training purposes later on.

Perspectives communication and operators intercommunication
Based on the approach of composing the CCUI into perspectives, their interplay has to be guaranteed in the CCUI, being flexible enough to be used in different workplace scenarios. The situation in different warning centres is based on national sensitivities and properties in the deployment area. Therefore it cannot be estimated how many operators will work on how many screens. For example, one operator might take care of all tasks or many operators work together, each of them managing only a subset of the overall process. In each case the perspectives and views should dovetail each other and support the operators workflow in a consistent manner and without interruption.
To pursue the idea of many operators working together and each of them managing a subset of the overall process in a dedicated perspective, it follows that each operator uses one workstation with the respective CCUI perspective opened. Thus the perspectives have to communicate output generated by one operator, as input to other operators' persectives. A possible inter-perspective communication exemplarily could work as follows.
The sensor network delivers information to the Monitoring Perspective via OGC Sensor Web Enablement (SWE) standards. Based on the delivered information, the operator at the Monitoring Perspective tasks the simulation system with the respective input to provide feasible forecasts, again using OGC standards such as WPS. The simulation system in turn notifies a registered perspective, i.e. the Forecasting Perspective, that the tasked calculation is finished, so that the operator at the Forecasting Perspective can request the calculated forecasts to analyse them. After revising the provided forecasts and selecting the most appropriate forecast, the operator at the Forecasting Perspective tasks the SPC via WPS to calculate the affected areas based on the selected forecast. If appropriate, additional expert information could be attached by the operator to guide the operator at the Message Composition Perspective. The operator at the Message Composition Perspective then receives this new input besides the calculated affected areas for dissemination and tasks the service framework to disseminate warning messages using again standards such as CAP, EDXL-DE and SOAP. Finally, the different dissemination providers deliver the warning messages and return the result of dissemination to the Dissemination Perspective, enabling its operator to react on dissemination failures. The outlined communication of perspectives relies on a service framework and the perspectives bind to this service framework via plug-ins. The communication and responsibilities of perspectives could be defined and realized dependent on the current needs of the respective EWS by including the required plug-ins in the appropriate perspectives to contain the desired communication facilities and functionality. Thus, the CCUI is highly customizable and flexible to serve the varying requirements of different EWS. Additionally, this service framework should address further functionality of the perspectives intercommunication such as a history store keeping log of actions carried out and decisions made by operators to allow further examination of emerged tsunami threats.

Caveats
Even though all developments of the CCUI are based to the largest extent on Free and Open Source Software (FOSS) components and industry standards (Löwe et al., 2011), and even though the CCUI integrates various services standardized by OGC, OASIS and W3C, the broad applicability of the CCUI is limited in terms of using it in other EWS for natural and man-made hazards without customization for the specific area of use or without modifications to the software. Rather the CCUI presented tries to provide a framework offering others to reuse most of its parts, i.e. perspectives and views, to extend untailored parts or to replace those parts being not relevant for their specific application. Although the CCUI is based on a concept that allows plugging in other, modified or additional functionality, the CCUI has been designed to work primarily with the described use case and scenarios.
That is, for example, that any tsunami forecasting software is going to be very dependent on the methodology to generate the actual prediction. This process may require a significant amount of input from the operator. So, to assist the operator in elaborating an accurate forecast other components might be required and accessed by perspectives and views not presented in this paper. For instance, in the case of incorporating source inversion tools to construct a tsunami source instead of selecting one from a pre-computed data base would require modifications to the CCUI. Apart from, that adaptions are dependent on the adopter's requirements, the development of the CCUI is not completed, still advancing and incorporating results achieved in on-going activities in collaboration with scientists, end users and stakeholders. Thus the CCUI is going to integrate requested functionally successively enabling the application of the CCUI with fewer modifications in future for areas other than those presented here.
Summarized the introduced CCUI is a proposal and a starting point every adopter might extend with its respective domain specific knowledge to achieve a comprehensive CCUI with a first basic set of adequate components.

Validation
In several project-internal demonstrations performing the complete EWS prototype including the presented CCUI, the designed concepts and implementation have been reviewed by DEWS project partners, including the: For validation, the strategy described by  has been applied using hypothetical future events for testing and training of core software system components. The system is being detached from real physical sensors and is being connected to a virtual sensor environment (see Fig. 11) fed by pre-computed so-called virtual scenario datasets of different sensor types. The fully synthetic virtual scenarios contain modelled sensor signals stored in natural sensor formats. Virtual scenarios can be any time played back on input to the software units. The latter does not actually realize if incoming data come from real or from virtual world. Furthermore, synthetic scenarios are fully under control of their developers. That makes them an ideal toolkit to simulate all possible situations which may realize in later operational work. Together with historical events, fully synthetic hypothetical scenarios provide a valuable basis for tuning and testing of the components as well as for teaching and training of the future warning centre personnel. Moreover, historical records, while being of highest priority, nevertheless cannot provide all necessary data for the extensive system verification and validation. Data are sparse and irregular; some sensor types were not available. Due to the same reasons, historical events are not the best scenarios for teaching and training of the warning centre personnel. In this respect, synthetic scenarios, which provide all possible coherent sensor data to the same event, appear to be the best candidates for validation, testing and training. The virtual scenarios selected for validation are listed in Figs. 12, 13 and 3. Finally, the system installed at BMKG has been used for evaluation of the CCUI together with the overall system in a closed and secure test environment in parallel to the Indian Ocean-wide Tsunami Warning and Communication Exercise in 2011 (IOWave11, UNESCO, 2011c) with the virtual scenario close to Aceh (Indonesia, see Fig. 12) and similar to the North Sumatra earthquake of 26 December 2004 which parameters provide the base for the scenario used in the IOWave11. The validation of the system performed against a real tsunami event is pending and has been made possible only by the deployment at KOERI as part of currently ongoing activities within the frame of the TRIDEC project and by the deployment at BMKG as part of resumed and continued DEWS activities. In the context of TRIDEC, the overall system including the CCUI is currently under further development and more extensive evaluation and revision of this system is expected to be completed in the future with multiple experts from research and responsible agencies offering their opinions on the system. Thus, also location-specifics, such as the validation of the system fed by sea levels which do contain noise and tidal components as the real system have, will be considered to confirm that the CCUI can be used in an unlikely event to analyse a real situation. Therefore, the location-specific CCUI has been installed on both locations having access to the respective sensor systems, i.e. sea level stations and the seismic system, serving raw data and/or post-processed data of real sensors, in addition to a CCUI installed together with a virtual sensor network for testing and training purposes. So the installed versions at KOERI and BMKG serve as a basis for a proof-of-concept, i.e. for validation purposes. It is important to know how the system reacts in real events with real data such as earthquake events (a) not generating a tsunami but felt at the coast, (b) generating a tsunami with high uncertainty while tsunami prediction, and (c) generating a tsunami with low uncertainty while tsunami prediction. The system should therefore be further evaluated to communicate feedback reporting experiences with the system and its behaviour in different events. The feedback will be used for improving the system until it works as expected by the involved stakeholders. Finally, decision-makers in local and regional authorities have expressed interest in the system (ICT, 2010).

Conclusions and future application
The paper covers results achieved in the projects DEWS and TRIDEC focusing on the the system's GUI in conjunction with the overall system's architecture, with details of the operator's workflow and connected system components based on a defined set of simulated tsunami scenarios. In particular the presented GUI for EWSs -named CCUI -aims to provide an appropriate and useful concept for the business of public safety, emergency management and homeland security. The concept presented is designed to be independent of the hazard risk and to provide an adaptable and extensible solution for specific applications of EWS. With less effort than starting from scratch, the CCUI can be adapted to multiple situations beyond tsunamis such as landslides, floods, forest fires, hurricanes and volcanic eruptions. Therefore, in future also multi-hazard functionality is conceivable. Adopting, extending and customizing the CCUI with hazard specific functionality furthermore is supported by the overall software architecture promoting a generic approach  CCUI version (right screen) used for international communication with national CCUIs, e.g. with the CCUI version (left screen) for Indonesia, both deployed at BMKG. . Especially the arrangement of functionalities within the user interface by usage of Perspectives and Views allowing access to functionalities associated with larger self-contained tasks in a comprehensive workflow and the underneath stack of generic frameworks leverage the reuse and adoption of the CCUI for specific applications in the field of EWSs for natural and man-made hazards. The CCUI in conjunction with the overall system was installed in 2011 at KOERI as part of TRIDEC project activities, and at BMKG as part of continued DEWS activities, leveraging results achieved in TRIDEC for evaluation and testing purposes in a closed and secure test environment within the domain of tsunami crisis management and solely used by its technical personnel. The deployed versions of the system correspond to software intended for future use in a national centre for tsunami early warning after extensive locationspecific validation has been successfully completed, either with different real events occurring real time or recorded. Also a successful validation importantly includes international communication with other national centres , exemplarily depicted in Fig. 14, considering the intended evolution of today's TWSs to regional or even global system-of-systems .