Figure 19: SCGMMS overall architecture
SCGMMS is carefully designed to provide a seamless, user-friendly, scalable and fault- tolerant environment for the development of different applications which utilize
information provided by the sensors. Application developers can obtain properties, characteristics and data from the sensor pool through the SCGMMS API (see Section 3.5 for details), while the technical difficulties of deploying sensors are abstracted away. At the same time, sensor developers can add new types of sensors and expose their services to application developers through SCGMMS’s Sensor Service Abstraction Layer (SSAL) (see Section 3.2.5for details).
NaradaBrokering (NB) is the transport-level messaging layer for SCGMMS. It is a distributed message-based transport network with a publish-subscribe messaging model.
By using NB as the transport different components of SCGMMS can be deployed and works collaboratively in a distributed manner.
The overall architecture of SCGMMS is shown in Figure 19. Internally SCGMMS is composed of 2 main modules – Sensor Grid (SG) and Grid Builder (GB) which serves different functions.
3.2.1 Grid Builder (GB)
Given the large amount of sensors, GB is a sensor management module which provides mechanism and services to do the following:
1. Define the properties of sensors
2. Deploy sensors according to defined properties 3. Monitor deployment status of sensors
4. Remote Management - Allow management irrespective of the location of the sensors
5. Distributed Management – Allow management irrespective of the location of the manager and the users.
GB itself posses the following characteristics:
1. Extensible – the use of Service Oriented Architecture (SOA) to provide extensibility and interoperability
2. Scalable - management architecture should be scale as number of managed sensors increases
3. Fault tolerant - failure of transports OR management components should not cause management architecture to fail.
Details of GB is discussed in Section 3.3.
3.2.2 Sensor Grid (SG)
SG communicates with a) sensors b) applications c) Grid Builder to mediate the collaboration of the three parties. Primary functions of SG are to manage and broker sensor message flows.
3.2.2.1 Sensor/Sensor Grid flow
SG keeps track of the status of all sensors when they are deployed or disconnected so that all applications using the sensors will be notified for changes. Sensor data normally does not pass through SG except that it has to be recoded intentionally. In this case data of that particular sensor is subscribed by SG.
3.2.2.2 Application/Sensor Grid flow
Applications communicate with SCGMMS through the Application API, which in turn communicates with SG internally. Applications can define their own filtering criteria, such as location, sensor id, and type to select which sensors they are interested in. These
filters are sent to SG for discovering and linking appropriate sensors logically for that application and forwards messages among the relevant sensors and that application. SG must always check which sensors meet the selected filter criteria and update the list of relevant sensors accordingly. It then sends an update message to application if there are any changes of the relevant sensors.
3.2.2.3 Grid Builder/Sensor Grid flow
Sensors’ properties are defined in GB. Applications have to obtain this information through SG. Moreover, filtering requests are periodically sent to GB for updating the lists of sensors needed for each application according to their defined filter parameters. Much of the information will be stored in a SG to minimize queries to Grid Builder.
3.2.2.4 Application/Sensor flow
SG provides each application with information of sensors they need according to the filtering criteria. The application then communicates with sensors through the Application API for receiving data and sending control messages.
Details of SG is discussed in Section 3.4.
3.2.3 Sensorcentric Grid Middleware Management System (SCGMMS) API
SCGMMS aims at supporting a large amount of applications for users and service providers of different industries (e.g., financial, military, logistics, aerospace, etc.). SCGMMS provides a common interface which allows any kind of application to retrieve information from the sensor pool managed by SCGMMS. The API also provides filtering mechanism which provides application with sensors matching their querying criteria only. Details of SCGMMS API is discussed in Section 3.5.
3.2.4 Sensor
The definition of sensor is a time-dependent stream of information with a geo-spatial location. A sensor can be a hardware device (e.g., GPS, RFID reader), a composite device (e.g., Robot carrying light, sound and ultrasonic sensor), Web services (e.g., RSS, Web page) or task-oriented Computational Service (e.g., video processing service).
3.2.4.1 Sensor Client Program
A sensor needs a Sensor Client Program (SCP) to connect to SCGMMS. The SCP is the bridge for communication between actual sensors and SCGMMS. On the sensor side SCP communicates with the sensor through device-specific components such as device drivers. On the SCGMMS side SCP communicates with SCGMMS through Sensor Service
Figure 20 shows a physical sensor and the corresponding Sensor Client Program.
Figure 20: Structure of sensor client program
3.2.4.2 Computational Service
Computational Service is a special kind of sensor which does not take input from the environment. Instead, they take output of other sensors as their input, perform various computations on the data, and output the processed data finally. It is called a sensor because it totally matches with our definition of sensor.
Figure 21 shows the data flow of how environmental data is transformed by processing data through a sensor and a Computational Service. The architecture of SCGMMS allows the data source to be assigned and reassigned dynamically.
Computational Service
Sensor sensor data processed data
environmental data
Figure 21: Computational service data pipeline
3.2.4.3 Supported sensors
To illustrate the usage of SCGMMS, several predefined sensors are supported in our initial implementation.
Hardware sensors 1. GPS device
2. RFID reader and tags’ signal strength
3. NXT Robots with ports attached to 4 of the following sensors: 3.1. Light 3.2. Sound 3.3. Touch 3.4. Ultrasonic 3.5. Compass 3.6. Gyro 3.7. Accelerometer 3.8. Temperature 4. Wii Remote Controller
5. Nokia N800 Internet Tablet PC video camera 6. PC Webcam
Computational sensor:
Video Edge Detection (software service as a sensor).
3.2.5 Sensor Service Abstraction Layer (SSAL)
SCGMMS can potentially support large amount of sensors of different kind. Ease of adding new sensors by different sensor developers without internal knowledge of SCGMMS is one of the most important requirements. SSAL provides a common interface for adding new sensors to the system easily. Sensor developers have to write simple programs utilizing SSAL libraries for connecting sensors to SCGMMS.
Afterwards the sensor will be available for all applications right away. Details of SSAL is discussed in Section 3.5.