SAL - Sensor Abstraction Layer
Lack of standards makes it difficult to integrate heterogeneous sensors in a single sensor network. Therefore it is important to have middleware that is able to manage all types of sensors. This middleware is often implemented specifically for a specific sensor network, which makes it very hardware dependent. Changes in the network, such as adding a new sensor, lead to the need for manipulating the code of the middleware. The Sensor Abstraction Layer (SAL) is designed to address these issues.
SAL is a middleware that provides a plug-in-based model where support for new types of sensors can be loaded to the running system via plug-in. The system automatically detects and configures new sensors, if permitted by the hardware and underlying operating system. Furthermore, it provides a unified interface to all sensors by abstracting the sensor specific features. With this it aims at simplifying the access to a sensor network as well as the management and control of its sensors [4, 5].
SAL can be seen as a low-level software layer as it bridges a network of sensors with high-level applications or further middleware technologies, e.g., a ring buffer. Figure 1 presents an architectural overview of a system stack using SAL.
SAL is implemented as a client-server application and thus consists of two components, the SAL client and the SAL agent. The SAL client represents an interface for SAL to either the user via a user interface or to other applications. It implements the SAL agent Application Programming Interface (API) in order to provide the functionality of the SAL agent. The API is grouped into the following categories:
- Sensor Management – Methods to manage the pool of sensors and including operations for enumerating, adding and removing sensors.
- Sensor Control - Methods to report on a sensor’s capabilities and control the streaming of the data.
- Platform Configuration - Methods to adjust the platform, e.g., add support for a new sensor type.
Each category uses a different markup language. The Sensor Management methods use SensorML  which describes a sensor’s configuration. The methods in the category Sensor Control use CommandML. The CommandML documents contain a list of commands which are supported by a sensor. The last category, Platform Configuration, uses Platform Capabilities and Configuration Markup Language (PCML). Documents of the type PCML contain information on how the platform is to be configured in order to support a certain type of sensor technology.
The SAL agent implements the various features of SAL. It runs on a platform which is connected to the sensors and therefore is regarded as a sensor gateway. The connection between the platform and the sensors can be either direct using platform specific I/O ports like USB or indirect by using wireless technology. The SAL agent manages the sensors, which are directly connected and are found by the agent and the indirectly connected sensors it has been told of. The SAL agent consists of three layers: Agent Layer, Communication Layer, and EndPoint Layer (see Figure 2).
The Agent Layer is responsible for the communication with the SAL client. It receives messages, parses and forwards them to the underlying Communication Layer and sends the response back to the client.
The Communication Layer provides methods for managing and controlling sensors. The managing methods are used to configure and set up hardware while the controlling methods translate a generic command into a sensor native command, which then can be transmitted to the sensor. The generic commands are provided in the SAL API. For translating the generic commands the two sub-layers Abstraction Layer and Protocol Layer are used. The Abstraction Layer is an adapter layer where the generic commands are implemented. From here the sensor-specific methods are called, which are implemented in the Protocol Layer.
The EndPoint Layer is tightly coupled to the I/O ports available on the sensor gateway. It is responsible for transmitting native sensor commands produced by the sub-layer Protocol to the sensor. In the other direction, data from the sensor is transmitted to the SAL agent. The software code for this layer is normally included in the operating system. SAL ensures it is available and configured correctly.
The two sub-layers Abstraction and Protocol and the EndPoint Layer together form a Logical Port. Each sensor is connected to a Logical Port. SAL allows a specific client to control multiple agents (horizontal scalability). Furthermore, the logical port allows SAL to scale vertically (vertical scalability) in that an agent can control other agents in a hierarchical manner. This is due to the logical port treating the attached device as a data source, independent of whether it is a sensor or another agent. The ability to scale allows sensor networks of almost any topology or configuration.
SAL has been successfully trialled on the Davies Reef sensor network project  whereby it controls a sensor array via a low cost/power computer in a remote reef. It is also being used in the SEMAT project.
SAL can effectively integrate existing hardware and communications infrastructure which offers versatility in the establishment of cheap and reliable sensor networks. These networks are suitable for environmental monitoring in developing countries where cost and existing infrastructure may be limited .