# Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web
## 5 Standards-Based Universal Acquisition Middleware
### SWE Bridge Model  
The SWE Bridge has been designed following a SensorML-like style, implementing computational equivalents for the SensorML elements (_SimpleProcess_, _Parameters_, _DataRecord_, etc.) and also providing SensorML-based inheritance and configuration mechanisms (_typeOf_ and _Settings_). Due to this approach, the SWE Bridge can also be modelled using the SensorML standard. The ultimate goal of this model, named SWE Bridge Model, is to provide an unambiguous description of this middleware, understandable by automated processes, providing a framework to automatically generate SDFs with minimum human intervention. This model is shown in Figure 11 and it is available online at [39].  
The SWE Bridge model defines a generic communication interface that abstracts the physical layer, providing a protocol-agnostic communication functionality to the rest of the software. The supported protocols are serial communication, TCP and UDP.  
The SWE Bridge's core is its set of modules, which are templates for observation-related, built-in processes. These processes include data retrieval, simple data manipulation and data storage among others. All these operation are described with _SimpleProcess_ elements, which can be instantiated, configured and connected within a Sensor Mission as detailed in Section 4.3. Each module can be instantiated to create a process that will be executed on runtime.  
The generic module is an abstract module that contains the necessary information for the coordination and operation of the resulting processes. This information is encapsulated in a set  
Figure 11: SWE Bridge model. All modules inherit from the generic module, where the execution options for the processes are defined. Then each module expands its definition with its particular settings. The model also contains a set of identifiers and a generic communication’s interface.  
of flags named Execution Modes, whose main function is to control the circumstances under which a particular process shall be executed.  
Derived from this generic module the following built-in modules are implemented in the current version of the SWE Bridge:  
* **Instrument Command**: This module provides a unified process to communicate with a sensor. Depending on the configuration, this module can be used to send any kind of commands and/or receive sensor data.
* **Field Selector**: This module allows to filter the response of a sensor, selecting the desired information and discarding the rest.
* **Subsampling**: This module allows to create subsampled data sets. It is especially useful in platforms with severe communication constraints, where a subsampled data set is transmitted in real time and a full data set is stored locally.
* **Sampling Geometry**: This module adds the platform position to a data structure, correlating sensor data with the platform's coordinates.
* **Insert Result**: This module stores the incoming data to standard O&M files, encoded in XML or EXI.  
Depending on the module, it may have an input, an output or both. If a module does not have an input, it represents the beginning of the process chain (i.e., Instrument Command). On the contrary, if it has only an input and does not have output this process represents the end of a process chain (i.e., Insert Result). If a module has both input and output, the module is an intermediate process, performing data manipulation/processing. A _DataRecord_ structure emulating the SWE Common Data Model standard is also used to pass data from process to process [38]. It is also possible to expand the SWE Bridge functionalities by implementing custom modules. A new module shall also inherit the parameters from the SWE Bridge generic module and follow the same data structure and input/output logic. In Section 6 different process chains for different real-world use cases are presented, including custom modules.