# Middleware for Plug and Play Integration of Heterogeneous Sensor Resources into the Sensor Web
## 5 Standards-Based Universal Acquisition Middleware
### Implementation  
In order to fulfil the cross-platform and minimum resources requirements, the SWE Bridge has been implemented using ANSI C, with special emphasis on minimizing the usage of underlying software and hardware resources. Its implementation is available online at [40]. All platform-dependent resources are abstracted using resource abstraction wrappers, which provide an unified way to access the platform's resources (see Figure 12). These wrappers are the only functions that need to be adapted when deploying the SWE Bridge in a new platform.  
The SWE Bridge operation is organized in four components that are executed sequentially: the OGC PUCK Detector & Extractor, the EXI decoder, the SensorML Interpreter and the Mission Scheduler. The hardware resources needed by these components are: access to a serial and/or Ethernet communication interface, access to the observation platform's coordinates (if the platform is mobile), access to the platform's filesystem and a timer to schedule internal operations.  
The execution of the SWE Bridge may vary slightly depending on whether the sensor is OGC PUCK-enabled or not, as shown in Figure 13. OGC PUCK-enabled sensors shall provide their SDF embedded within their payload memory. However, when interfacing a COTS sensor its associated SDF shall be uploaded to the platform filesystem.  
The OGC PUCK Detector and Extractor detects new OGC PUCK-enabled sensors connected to the communications interface. Once a new sensor is detected, this component extracts its SDF. When interfacing a COTS sensor, a local SDF can be passed as argument to the middleware, bypassing the OGC PUCK Detector and Extractor component.  
The EXI decoder, based on the EXIP framework, extracts and stores the desired information from the SDF into an intermediate structure [41]. Using a set of rules, the decoder identifies potentially useful elements to the SensorML Interpreter Service. The SensorML Interpreter service takes the extracted information and uses this data to configure the acquisition process. The first step is to configure a communication interface according to the information decoded sensor description. Afterwards this service examines the set of _SimpleProcesses_ that are defined within the Sensor Mission and generates a process instance for each one of them. The generated processes are connected according to the SDF's _connections_ section and finally the internal parameters of these processes are configured as specified in the _Settings_ section.  
Once the Auto-configuration Service has setup all necessary processes in the SWE Bridge, the Mission Scheduler is started. This is a timer-based scheduler that manages and controls the execution of the previously configured process chains.  
Figure 12: SWE Bridge internal architecture. The different components use the resource abstraction wrappers to hide the underlying hardware and operating system, providing a unified way of accessing platform-dependent resources.  
Figure 13: SWE Bridge operation. On the left the operation with a OGC PUCK-enabled sensor is shown. On the right the operation of a COTS sensor is presented, with the SDF stored locally on the platform.