 |
| Titel |
The tsunami service bus, an integration platform for heterogeneous sensor systems |
| VerfasserIn |
R. Haener, J. Waechter, U. Kriegel, J. Fleischer, S. Mueller |
| Konferenz |
EGU General Assembly 2009
|
| Medientyp |
Artikel
|
| Sprache |
Englisch
|
| Digitales Dokument |
PDF |
| Erschienen |
In: GRA - Volume 11 (2009) |
| Datensatznummer |
250023069
|
|
|
|
|
|
| Zusammenfassung |
| 1. INTRODUCTION
Early warning systems are long living and evolving: New sensor-systems and -types may be developed and deployed, sensors will be replaced or redeployed on other locations and the functionality of analyzing software will be improved. To ensure a continuous operability of those systems their architecture must be evolution-enabled. From a computer science point of view an evolution-enabled architecture must fulfill following criteria:
• Encapsulation of and functionality on data in standardized services. Access to proprietary sensor data is only possible via these services.
• Loose coupling of system constituents which easily can be achieved by implementing standardized interfaces.
• Location transparency of services what means that services can be provided everywhere.
• Separation of concerns that means breaking a system into distinct features which overlap in functionality as little as possible.
A Service Oriented Architecture (SOA) as e. g. realized in the German Indonesian Tsunami Early Warning System (GITEWS) and the advantages of functional integration on the basis of services described below adopt these criteria best.
2. SENSOR INTEGRATION
Integration of data from (distributed) data sources is just a standard task in computer science. From few well known solution patterns, taking into account performance and security requirements of early warning systems only functional integration should be considered. Precondition for this is that systems are realized compliant to SOA patterns. Functionality is realized in form of dedicated components communicating via a service infrastructure. These components provide their functionality in form of services via standardized and published interfaces which could be used to access data maintained in - and functionality provided by dedicated components. Functional integration replaces the tight coupling at data level by a dependency on loosely coupled services. If the interfaces of the service providing components remain unchanged, components can be maintained and evolved independently on each other and service functionality as a whole can be reused. In GITEWS the functional integration pattern was adopted by applying the principles of an Enterprise Service Bus (ESB) as a backbone. Four services provided by the so called Tsunami Service Bus (TSB) which are essential for early warning systems are realized compliant to services specified within the Sensor Web Enablement (SWE) initiative of the Open Geospatial Consortium (OGC).
3. ARCHITECTURE
The integration platform was developed to access proprietary, heterogeneous sensor data and to provide them in a uniform manner for further use. Its core, the TSB provides both a messaging-backbone and -interfaces on the basis of a Java Messaging Service (JMS). The logical architecture of GITEWS consists of four independent layers:
• A resource layer where physical or virtual sensors as well as data or model storages provide relevant measurement-, event- and analysis-data:
Utilizable for the TSB are any kind of data. In addition to sensors databases, model data and processing applications are adopted. SWE specifies encoding both to access and to describe these data in a comprehensive way:
1. Sensor Model Language (SensorML): Standardized description of sensors and sensor data
2. Observations and Measurements (O&M): Model and encoding of sensor measurements
• A service layer to collect and conduct data from heterogeneous and proprietary resources and provide them via standardized interfaces:
The TSB enables interaction with sensors via the following services:
1. Sensor Observation Service (SOS): Standardized access to sensor data
2. Sensor Planning Service (SPS): Controlling of sensors and sensor networks
3. Sensor Alert Service (SAS): Active sending of data if defined events occur
4. Web Notification Service (WNS): Conduction of asynchronous dialogues between services
• An orchestration layer where atomic services are composed and arranged to high level processes like a decision support process:
One of the outstanding features of service-oriented architectures is the possibility to compose new services from existing ones, which can be done programmatically or via declaration (workflow or process design). This allows e. g. the definition of new warning processes which could be adapted easily to new requirements.
• An access layer which may contain graphical user interfaces for decision support, monitoring- or visualization-systems:
To for example visualize time series graphical user interfaces request sensor data simply via the SOS.
4.BENEFIT
The integration platform is realized on top of well known and widely used open source software implementing industrial standards. New sensors could be added easily to the infrastructure. Client components don’t need to be adjusted if new sensor-types or -individuals are added to the system, because they access the sensors via standardized services. With implementing SWE fully compatible to the OGC specification it is possible to establish the "detection" and integration of sensors via the Web. Thus realizing a system of systems that combines early warning system functionality at different levels of detail (distant early warning systems, monitoring systems and any sensor system) is feasible. |
|
|
|
|
|
|