This work was supported by the Ontario Centres of Excellence project UO AG R50649-07)

Integration of Component-based Frameworks with Sensor Modelling Languages for the Sensor Web

Ramiro Liscano Senior Member, IEEE

Faculty of Engineering and Applied Sciences University of Ontario Institute of Technology

Oshawa, Canada Ramiro.Liscano@uoit.ca

Kimia Kazemi Faculty of Engineering and Applied Sciences University of Ontario Institute of Technology

Oshawa, Canada Kimia.Kazemi@uoit.ca

Abstract— The integration of sensor networks with service oriented architectures requires explicit representations of sensor information and interfaces. A strong candidate language for modelling sensor information is SensorML. SensorML as opposed to other sensor modelling languages supports a specification of a process model associated with a sensor system. As a way of facilitating interaction with other decision making software modules this paper presents a translation procedure that leverages the SensorML modelling language and maps this into Java Bean software components and events. Software components design is a common approach for supporting high-level interoperability in software engineering. To demonstrate the value of this approach the translation procedure is compared against the more classical object-based approach used to develop a sensor web middleware platform. The results show that the use of SensorML to drive the software design of sensor components is simpler to that based on classical OO design.

Keywords- SensorML; Component-based Design; Sensor Networks; SensorWeb.

I. INTRODUCTION In order to support better interoperability of sensory

information in sensor networks a component-based approach for software design is generally better than a conventional object-oriented approach [1]. The reason why this is so is based on the intrinsic ability for components to support, introspection and management of events. Introspection is the ability to dynamically extract from a component the methods (interfaces) or properties of the component and event management is a crucial mechanism for receiving from the component information when changes have occurred to an internal property of the component.

These features of components map well with information coming from sensor networks. Introspection can be used to determine what properties and interfaces are supported by a sensor node and the event services can be used for other software modules to receive events that signify new sensor values.

The challenge in developing components that represent sensors in a sensor network is the tedious effort in developing the component as well as the fact that each component might be inconsistent with other components because of differences on what information needs to be coded into the component,

A potential solution to this problem comes from the ability to leverage explicit sensor descriptions captured in a sensor modelling language. Of particular interest to this paper is the SensorML (Sensor Model Language) [2] adopted by the Open Geospatial Consortium (OGC) [3], because it can capture the flow of information in a sensor system using a process model as well as the static information describing the sensor devices themselves ( i.e. name, manufacturer, etc.)

This process model can be read and translated into software components and corresponding events among the components. This paper presents a translation procedure that leverages the static and process specification part of SensorML and maps this into software components and corresponding component events.

II. RELATED WORK There are very few papers in the area of component-based

design for sensor networks. Table 1 shows a comparison of these related works with the SensorML/Component Translator (SCT), which is the approach presented in this paper. Of these Insense [4] is one that is the closest to our work.

Insense is a component-based model and language for wireless sensor network applications. Their approach does not leverage an explicit sensor representation like SensorML as we do but instead it is a more generic component development environment with a focus on sensor devices. Our SensorML mapping mimics the same thought process as Insense in that a sensor component has I/O channels with which it can connect to other sensor components. In the translator we present in this paper this is comparable to the inputs and outputs of a SensorML process models and the connections between the components is comparable to the connections between SensorML process models.

Insense is written using Java and creates “C” source code. This is very similar to what is being done in this paper as the work in this paper consists of generating Java Beans from SensorML so in fact both Insense and the developed system work as translators to convert one language to another.

UM-RTCOM [5] is another component-based framework but targeted more for real time systems but it could be adapted to develop sensor specific software components. We considered how SensorML could be mapped into UM-RTCOM

IEEE Globecom 2010 Workshop on Advanced Sensor Integration Technology

978-1-4244-8865-0/10/$26.00 ©2010 IEEE 235

<sml:member> <sml:Component> <sml:identification> <sml:IdentifierList> <sml:identifier name="Manufacturer"> <sml:Term

definition="urn:ogc:def:identifier:manufacturer">

<sml:value>Crossbow</sml:value> </sml:Term> </sml:identifier> <sml:identifier name="Mote Type"> <sml:Term

definition="urn:ogc:def:identifier:moteType"> <sml:value>Mica2</sml:value> </sml:Term> </sml:identifier> <sml:identifier name="Sensor Board"> <sml:Term

definition="urn:ogc:def:identifier:sensorBoard">

<sml:value>MTS310</sml:value> </sml:Term> </sml:identifier> </sml:IdentifierList> </sml:identification> <sml:inputs> <sml:InputList> <sml:input name="Temp1"> <swe:Quantity> <swe:uom code="" xlink:href="degreeF" /> </swe:Quantity> </sml:input> </sml:InputList> </sml:inputs> <sml:method

xlink:href="C:\\workspace\\tezFogh7_13\\Calibration.java" />

</sml:Component> </sml:member> </sml:SensorML>

but determined that this was quite difficult since it is a generic component design tool that supports real-time analysis.

Another generic software component development environment is The Java Component Model (JCM) [6]. It also could be adapted to support SensorML but similar to UM-RTCOM generic component-based development environments require a significant amount of customization in order to take advantage of sensor specification languages like SensorML.

TABLE I. COMPARISON OF COMPONENT MODELS' IMPLEMENTATION

Communication

Approach

Scope Code generati

on

Trigger

SCT Getter and setter

methods

Sensor Systems

Java Beans

Event

Insense Interfaces Sensor Networks

C semaphore

UM-RTCO

M

Interfaces Real Time applications

Java Event

JCM Interfaces General Java Event

III. SENSORML In general SensorML represents a sensor system as a

process chain composed of sub parts called process models. Sensors or devices in SensorML are also seen as a kind of process model which have single inputs and single outputs.

The sensors (process models) are then encapsulated within a system (a process chain). A process model itself describes the inputs and outputs and contain a reference to a process method which consists of: a metadata, a schematron, a MathML and a coding section. Fig. 1 shows an architecture diagram of SensorML’s Process chain:

Figure 1. SensorML’s architecture

Part of the SensorML description also captures static metadata information about the sensor like the sensor name, type, manufacturer, etc.

Code 1 shows an example of a temperature sensor coded in SensorML. SensorML defines the sml XML namespace. This code shows the metadata for this sensor using the sml:Term tag and in this case it is trying to model an MTS 310 sensor board

from Crossbow. The code also shows the sensor inputs (sml:Inputs) and a reference link to the process method given by the sml:method tag. This particular example has one input property variable (Temp1) that corresponds to an un-calibrated temperature reading that will be processed by the code defined in the Calibration.java file. SensorML does not have to specify an output since it is implicit. In our translator this calibrated sensor value is stored in a component variable called output (all process SensorML process modules have 1 output).

Code 2 shows an example of a process chain, taken and modified from [7] of a sensor system that combines temperature and wind chill sensor devices to produce wind chill temperature values as depicted in Fig. 2. Wind Chill has two inputs, temperature and wind speed. As can be seen from Fig. 2 the output of the Temperature sensor provides one of the inputs to the Wind Chill sensor.

Code 1. SensorML document for a temperature sensor

A sensor system is defined as a set of components that include references to SensorML devices, given by the sml:component reference, and links between these components (sml:Link).

236

Temperature

Wind Chill

<sml:connections> <sml:ConnectionList> <sml:connection> <sml:Link> <sml:source ref="Temperature\Temp1" /> <sml:destination ref="Temperature\Temp1" /> </sml:Link> </sml:connection> <sml:connection> <sml:Link> <sml:source ref="WindChill\Windspeed" /> <sml:destination ref="WindChill\Windspeed" /> </sml:Link> </sml:connection> <sml:connection> <sml:Link> <sml:source ref="Temperature\Temp1" /> <sml:destination ref="WindChill\Temperature" /> </sml:Link> </sml:connection> </sml:ConnectionList> </sml:connections>

public class Calibration{ public double output; public void Temperature_Calibration(){ output = 2.5 * ((double) Temp1 / 4096) * 100 * 2. - 273; }}

Figure 2. Sensor system with 2 connected sensors (process models).

Code 2. SensorML document of a sensor system (process chain) with a Temperature and Wind Chill sensor (process model).

Code 3 gives an example of the process method code referenced in a process model like the one shown in Code 1. This example is a calibration code for temperature calibration and it is captured in the “Calibration.java” file. This process method contains a method that will convert raw temperature data to calibrated, temperature data defined as Temperature_Calibration().

Code 3. Process method Calibration.java.

IV. MAPPING SENSORML INTO JAVA BEANS The translator presented in this work is used to convert

SensorML files to Java Beans components. The process models depict sensors in the system. Each process model is mapped into a Java Bean component.

Process methods define the work flow in the process model thus they are mapped to parts of the code in the Bean.

The process chain defines connections between process models and is mapped into Bean events. Table 2 shows the mapping of SensorML into Java Beans.

TABLE II. MAPPING SENSORML INTO JAVA BEANS

SensorML Java Beans

Process Method Part of the Bean

Process Model A Bean

Process Chain Events

Java Beans abide by a certain number of rules such as special naming patterns. The following are the core Beans’ concepts:

• Introspection: is used to extract a beans properties, methods and events.

• Properties: Behavior of beans.

• Event handling: used to propagate messages between Beans.

• Persistence: used to save and restore the beans properties.

Java Beans are different from normal reusable class libraries in the sense that:

• They need to define getter and setter methods.

• They can use java.bean.PropertyChangeEvent to notify interested parties when values change.

• They can use java.bean.PropertyChangeListener to register for notifications when a particular property changes.

A. EVENT HANDLING IN JAVA BEANS Communications along the connections in the process chain

are implemented by using Java Bean events. Java Beans use three classes when dealing with events:

• PropertyChangeSupport: Contains three methods, add/removePropertyChangeListener and firePropertyChange.

• PropertyChangeEvent: Contains three methods, getNewValue, getOldValue and getPropertyName.

• PropertyChangeListener: This is an interface supplying one method, propertyChange.

Events are addressed in Java Beans by using bound properties. Bound properties are properties that transmit notifications when changes occur to a Java Bean’s attribute variables.

A Java Bean that has bound properties must keep a list of propertyChangeListeners. As such the bean implements the propertyChangeListener interface. When we implement this interface we override the propertyChange method that specifies what should happen once the property changes.

237

main_class

--process_models:ArrayList--process_names:ArrayList--source:String--destination:String

DOMParser_pch

-+dpch: DOMParser_pch-+d: DOMParser-+name:String

createsBean --input:ArrayList--type:ArrayList--method:ArrayList--method_name:String

DOMParser

«uses»«uses»

«uses»

double val=50; Temperature b0=new Temperature(); b0.setTemp1(val);

public class Temperature double Temp1; ... public void run(){ double out = 2.5 * ((double) Temp1 / 4096) * 100 * 2. - 273;

System.out.println("Calibrated Temperature is: " + out);

} public void propertyChange(PropertyChangeEvent evt)

run(); }

The class PropertyChangeSupport implements methods that add and remove PropertyChangeListeners. Since adding and removing PropertyChangeListeners is needed the Bean will have a PropertyChangeSupport attribute.

The firePropertyChange method that is called within the setter method sends a PropertyChangeEvent to the Java classes which implement the PropertyChangeListener. The message carries the old and new value of the changed attribute as well as the attribute name.

V. THE SENORML / COMPONENT TRANSLATOR (SCT)

The SCT consists of seven classes. Fig. 3 shows the class diagram of the translator.

Figure 3. Translator class diagram

The main_class is used for running all the other classes. The class DOMParser is used to parse the SensorML process model and acquire information from it such as the inputs and the inputs’ types and the process method name and location. The class DOMParser_pch does the same activity but for the process chain. It stores information about the process models’ connections and also the name and the location of the process models used. The class createsBean gets the information from the DOMParser classes and creates a Java file based on the translation algorithm presented in Section IV.

The main_class first instantiates the DOMParser_pch class. This class parses the process chain and retrieves information about:

• Inputs and outputs to the system.

• The name and location of the process models.

• The connection between the process models.

The main_class then instantiates DOMParser class. This class parses the process model (sensor) documents and retrieves information about:

• The input and output to the process model.

• The process method’s location.

The main_class then instantiates the createsBean class. This class uses the information retrieved from the process chain and the process model by the classes DOMParser_pch and DOMParser to create the Java Beans.

VI. RESULTING COMPONENT ARCHITECTURE One of the most important characteristics of Java Beans is

their getter and setter methods. The translator creates getter and setter methods for each of the components’ attributes.

Components talk to each other using the setter methods. When a setter method is called an event is triggered and the components that registered for that event receive a message associated with the change to the corresponding attribute.

Code 4 shows an example of Java code that a developer would write in order to interact with the Temperature Java Bean that was created by the SCT. In this example the value of Temp1 will be set to 50 triggering a propertyChangeListener method to execute in the Temperature Java Bean that simply computes the calibrated value of the temperature value based on the code encoded in the Calibration,java file that is now embedded in the Temperature Java Bean.

Code 4. Example of a Java Test Program that sets the Temp1 value of the Temperature Java Bean and triggers the SensorML process chain.

Code 5.lists code for the Temperature Java Bean showing the declaration of the Temp1 attribute, the propertyChange callback method, which calls the run method that contains the process method code declared in the SensorML file.

Code 5. The propertyChange method in the Temperature Java Bean.

VII. ANALYSIS OF SCT In this section an analysis of the value of the SCT is

performed by comparing it to an existing Java-based middleware sensor system called SensIV that was also developed at the same research group.

The SensIV system is a sensor network that measures the temperature in a field using a set of temperature sensors consisting of a set of wireless sensors forwarding their data to a Java-based middleware platform as shown in Fig. 4.

The SensIV middleware application is written in Java and is characteristic of a classical Object Oriented (OO) program. The design of SensIV is based on the proper interpretation of the incoming message from the sensor network, the type of sensor

238

that sent the message. The details of the encoding of this information in the SensIV message are not relevant to this paper.

Figure 4. Architecture of SensIV system

The core classes that represent the sensors in SensIV are based on the type of sensor boards in the sensor network. In this case these are the Crossbow MTS300, MTS310, and MDA300 sensor boards. These classes are in effect comparable to the process models in SensorML except that in SensIV each sensor board type has only a single instance of the sensor board class, while when SensorML is used each sensor has a SensorML file describing it resulting in a Java bean for each sensor in the system.

The purpose of this analysis is to learn if there is an improvement over SensIV in using the SCT in terms of:

• A software developer’s effort in changing the sensor system. For example adding a new sensor to the system.

• The cohesion and coupling of the resulting code.

A. EVALUATION OF A DEVELOPER EFFORT IN CHANGING THE SENSOR SYSTEM For this analysis several graduate, undergraduate, and

professors with software engineering background were asked to modify SensIV code as well as to use the SCT.

A two hour session was held and instructions were handed to these software developers. The software developers had different initial levels of knowledge about SensIV and the SCT but all of them were developers with a fundamental knowledge of Java and of XML. Before the software developers performed the code change exercise their development environment was set up with the appropriate files. Code development was performed using the Eclipse IDE.

The software developers where then guided in how to add a new sensor using both the SCT and the SensIV system. After they all succeeded doing this they proceeded to fill in a survey about their experience of using both systems. The following questions were asked about each approach.

1. Ease of use (on a scale from 1–5, 5 being better).

2. Wealth of information captured by the system on the sensor (on a scale from 1–5, 5 being better).

Also the developers were categorized as follows:

Cat 1. Software developers who had knowledge of SensIV but no knowledge of the SCT.

Cat 2. Software developers who were not acquainted with any of the 2 sensor systems and they were using both for the first time.

Cat 3. Software developers with knowledge of both SensIV and the SCT.

The results of the survey for questions 1&2 are summarized in Table 2.

TABLE III. SUMMARY OF SURVEY RESULTS COMPARING SOFTWARE DEVELOPERS USING SENSIV AND SCT

Person ID

Cat. Q1 SCT

Q1 SensIV

Q1 SCT

Q1 SensIV

1 1 4 Not Rated

2 Not Rated

2 1 3 Not Rated

Not Rated

3

3 2 3.85 2 3 1

4 2 4 3 5 4

5 3 4 3 3.5 1

Ave. 3.77 2.67 3.37 2.25

Unfortunately some of the developers did not put in a ranking for the questions but did include comments instead. For Q1, “ease of use” for the SensIV system both the comments from the developers 1 & 2 were rather negative, i.e it took to much effort.

B. COHESION AND COUPLING Cohesion is defined as how strongly related to each other

the functionalities of software modules are. In general high cohesion is a good thing because it reflects that the methods of a class are tightly related to the class. Coupling is defined as the knowledge each class has of other classes. In general a low value for cohesion is desired since this reflects ease of code modification since modules are not tightly connected.

In this paper the “Lack of Cohesion in Methods” test of the Eclipse Metrics 1.3.6 [8] plug in was used to measure the cohesion in both the SensIV code and the code generated by the SCT.

1) Cohesion The lack of cohesiveness (inverse of cohesion) in this plug-

in is measured using an algorithm called Henderson-Sellers. The formula used in this measure is:

Μ(Α)−Μ/1−Μ. (1)

Where M(A) is the average number of methods that access all attributes, M is the total number of methods, and A is the

239

number of attributes. This value ranges from 0-1 where the lower the value the more cohesive the classes are.

This formula reflects that the more methods that access the attributes in a class the higher the cohesiveness. The measure of cohesion is not well applicable to Java Beans because access to a classes attributes are limited to getter and setter methods only. This generally results in a value of M(A) of 2 no matter how many more methods are added to the Java Bean driving the lack of cohesiveness value close to 1 (or a poor cohesive value.)

In the case of SensIV code the average cohesion factor is about 0.785 as opposed to 0.332 for the code generated by SCT. In other words cohesion is better for the OO system but as previously mentioned we do not believe that the Henderson-Sellers measure is well suited in measuring cohesion for component-based software.

It should also be noted that additions of new sensor types to either of these systems had little impact on cohesive value of the code. In both cases the values for lack of cohesion remained nearly the same.

2) Coupling To compare the coupling of the components generated by

SCT to SensIV a measure called Method Invocation Coupling (MIC) is used. MIC is defined as the number of classes that are coupled to a particular class [9]. The formula for MIC is:

ΜΙC=ηΜΙC/(Ν−1) (2)

Where ηMIC= number of classes that use a particular class and N=total number of classes.

For the example shown in Fig. 2 where there are 2 components created, Temperature and Wind Chill, the average MIC for the components generated by was 8.25%. For the SensIV system where 2 sensor types were defined the average MIC was 32.14%. In this example the coupling for SensIV is four times more than the coupling for the components generated by SCT.

VIII. CONCLUSION This paper presented a software development system that

leverages the SensorML description language to automatically generate software components and flow between those components as specified by the sensor process model in SensorML. Software components are known to support high-level software interoperability.

In order to validate the value of this approach the developed SCT was compared against an existing OO-based middleware for a sensor network system (SensIV) in terms of ease of use when sensors are added to a sensor system and code complexity. The test results showed that when new sensors are introduced in the system the SCT was easier to develop with than if using the SensIV system and the code had less coupling. It was also demonstrated that the standard measure used for cohesion, the Henderson-Sellers measure, is not suitable for Java Beans component systems because of the convention of using setter and getter methods to access the components attributes.

As future work, we are looking at applying this approach to software on wireless sensor nodes based on the TinyOS environment. TinyOS also supports a component-based software design methodology but it is quite different than Java Beans. In the sensor networks it is also quite challenging to take into account integration with the non-functional components like low power listening and sensor interfaces.

REFERENCES [1] C. Szyperski, Component Software - Beyond Object Oriented

Programming, Addison-Wesley, Reading: M.A.,1997. [2] Mike Botts, Alexandre Robbins, “OpenGIS Sensor Model Language

(SensorML) Implementation Specification”, SensorML Specification,2007.[Online].Available: http://www.ogcnetwork.net/SensorML_Spec. [Accessed: June 2010].

[3] Open Geo Spatial Consortium, Available: http://www.opengeospatial.org/. [Accessed July 2010].

[4] A. Dearle, D. Balasubramaniam, J. Lewis, R. Morrison,” A Component-Based Model and Language for Wireless Sensor Network Applications,” Computer Software and Applications, 2008. COMPSAC '08. 32nd Annual IEEE International, p. 1303 - 1308, July 2008.

[5] J. Barbaran , M. Diaz, I. Esteve , D. Garrido , L. LLopis, B.Rubio, “A Real-Time Component-Oriented Middleware for Wireless Sensor and Actor Networks,” Complex, Intelligent and Software Intensive Systems, 2007. CISIS 2007. First International Conference on, p.3-10, April 2007.

[6] M. C. da Silva, J.P.A. de C. Guerra, C. M. F. Rubira,"A Java Component Model for Evolving Software Systems," Automated Software Engineering, 2003. Proceedings. 18th IEEE International Conference, p.327-330, Oct 2003.

[7] K. Kazemi, Integration Of Component Based frameworks with sensor web languages. Thesis, (Master). University of Ontario Institute of Technology, 2010.

[8] Metrics1.3.6-Getting Started, Available: http://metrics.sourceforge.net/. [Accessed March 2010].

[9] Tutorials on coupling and cohesion: Two cornerstones of OO, Available: http://javaboutique.internet.com/tutorials/coupcoh/index-2.html. [Accessed Âugust 2010].

240