The four (five) Sensors
SWE based sensor integration in the
German Indonesian Tsunami Early
Warning and Mitigation System
project (GITEWS)
Content
GITEWS: A short introduction
SWE: A short introduction
SWE: Characterization of the GITEWS
sensors
SWE, sensor integration: Realization,
technology
GITEWS: Adoption of the GITEWS
sensors
GITEWS: Architecture
GITEWS: The Sensors
A colorful presentation of the
GITEWS Sensors
SWE: Sensor Integration, Categories
Sensor, Sensor System (individuals)
e.g.: Buoy (wave height)
Sensor Systems Network (network of
sensors and sensor systems)
e.g.: Seismic System (earthquake location, -strength)
Models, Databases (virtual sensors)
e.g.: Tsunami Simulation (scalar field of wave height)
Warning Systems (system of systems)
e.g.: GITEWS (tsunami phenomenon and parameters)
Actuators (active controlling units)
SWE: Sensor Integration, Sensors
Seismic System
QuakeML, proprietary data format, Messaging System (JMS) :
complex event model
Buoys
Proprietary data format and protocol: time series
Tide Gauges
Proprietary data format and protocol: time series
GPS Ground Tracking System
Proprietary data format and protocol: time series
Simulation
Sensor Web Enablement (SWE)
SWE comprises all endeavours to make all
types
of
sensors and instruments
available
on the Web, but
also archives of sensor data via the WWW,
traceable
,
accessible
and if possible,
controllable
as well.
(OGC)
SWE
Encodings
Sensor Model Language (SensorML)
standardized description of sensors and sensor data
Observations and Measurements (O&M)
model and encoding of sensor measurements
SWE
Services
Sensor Observation Service (SOS):
standardized access to sensor data
Sensor Planning Service (SPS):
monitoring and control of sensors and sensor networks
Sensor Alert Service (SAS):
active sending of data if defined events occur
Web Notification Service (WNS):
a service by which a service (client) may conduct
asynchronous dialogues (message exchange) to one or
more other services (clients). Messaging via various
communication encodings (e.g. SMS, e-mail)
Sensor Integration (Technology)
Approach:
“Tsunami Service Bus”
Establishment of a Service Oriented Architecture
based on the concept Enterprise Service Bus
Tsunami Service Bus (Wikipedia)
In computing, an enterprise service bus (ESB) refers to a software architecture construct, implemented by technologies found in a category of middleware
infrastructure products usually based on standards, that provides foundational
services for more complex architectures via an event-driven and standards-based
messaging engine (the bus).
An ESB generally provides an abstraction layer on top of an implementation of an enterprise messaging system which allows integration architects to exploit the value of messaging without writing code. Contrary to the more classical enterprise application integration (EAI) approach of a monolithic stack in a hub and spoke architecture, the foundation of an enterprise service bus is built of base functions broken up into their constituent parts, with distributed deployment where needed, working in harmony as necessary.
ESB does not implement a service-oriented architecture (SOA) but provides the features with which one may be implemented. Although a common belief, ESB is not necessarily web-services based. ESB should be standards-based and flexible, supporting many
transport mediums. Based on EAI rather than SOA patterns, it tries to remove the
coupling between the service called and the transport medium.
Most ESB providers now build ESBs to incorporate SOA principles and increase their sales, e.g. Business Process Execution Language (BPEL).
DSS
EWMS
Adoption of Sensor Systems
Sensor System Data Processing Sensor Proxy
Data & Event Processing Data Transforming proprietary encoding
Sensor System
Sensor Instrument Signal Processing proprietary encoding unique encodingAdoption of the Seismic System
EWMS
SeisComP Data Processing Seismometer Signal Processing Seismic Proxy Data Transforming Process Control Data Transfer proprietary encoding SensorML, O&MSeismic System
messages (non sensor events)
Decision Support
Control
common protocol
proprietary protocol
Tsunami Service Bus
SeisComP
IAS, System Control
Sensor Integration: EWMS
Earth
Observation Proxy
Data & Event Processing
Seismic Proxy
Data & Event Processing
Tide Gauge Proxy
Data & Event Processing
Buoys Proxy
Data & Event Processing
GPS GTS Proxy
Data & Event Processing
EWMS
Simulation Proxy
Data & Event Processing Classification GML Adap ter Adap ter Adap ter Adap ter Adap ter Adap ter
Sensor System Management Dissemination
DSS
Tsunami Process Engine: Tsunami Service Bus
unique encoding unique encoding unique encoding unique encoding unique encoding unique encoding
Tsunami Service Bus: SOA Layers
Access (GUI) Layer
Process (Orchestration) Layer
Service (Component) Layer
Tsunami Service Bus: Scenario
SPS
SOS SAS
WNS
Sensor Systems Early Warning System Simulation Data
Services
data/event processing
Process Engine
Access
Decision Process Controller
Tsunami Service Bus
Tsunami Service Bus
SWE Common Services WFS WMS
SAS
SOS SPS Registry WNS
WCS
OGC Common Services
Map Production Spatial Analysis Coarse grained Business Services Sensor System Management Decision Support Process Service Access Sensor Proxies Service Access Basic Services LDAP Triple A Diagram Service Visualization
Tsunami Service Bus, what is
Standards
XML, SWE. OGC, ISO
Protocols
O&M, SOAP, WSDL, JMS
Services
SOS, SAS, WCS, Registry
Processing Engines
BPEL
Loosely Coupling of Components
Standardized Interfaces
Middleware
Software Architecture
Logical View
Physical View
Component View
Deployment View
Logical View: Decomposition
Seismic System
Buoy System
SAS
SOS
Communication
EWMS
DSS
Seismic System
Proxy
Buoy System
Proxy
SSM
Physical View: Composition
Process 1 Process 2 Process 3 Communication
Seismic System Seismic System Proxy
DSS SOS SAS Process 1 Process 2
components
Process 3deployment
node 1
node 2
Sensor
System
SWE, Sensor Proxy: SAS
advertise
DSS
subscribe subscribeSensor
Proxy
alertSAS
IAC
Registry
communicate system status informationset sensor events
DSC
publish
Sensor
System
Management
Sensor
System
SWE, Sensor Proxy: SOS
Sensor
Proxy
getObservationIAC
communicate system status information setObservation getObservationDSS
SOS
Registry
DSC
Sensor
System
Management
SWE, Sensor Proxy: SOS
Some XML Code with XML Spy:
Seismic System Event Collection
Some buoy data with a visualization tool:
Sadly just simulated
Seismic System Proxy
id Prototype V. 0.5 -Decomposition View
Seismic System Messaging EventProvider SOS-Proxy Postgres DB JDBC JMS Client EventListener JDBC Seismic System Database DAO to Seismic System DB SWE QuakeML to SQL Converter DAO SWE JDBC «logical» SOS::SOS SWE SWE Service (Servlet) Request Converter Reply Converter call call QuakeML Call Call QML Events
generate Buoy „setMode“ Schedule (DSS) generate ETAs for Buoys (Simulation) optional check Schedule (OOD) Execute Buoy Schedule (DSS)
Tsunami Service Bus: Process Flow (extract)
OOD EQ Detection (Seismic System) EQ Classification (DSS) NN (DSS)