Sensor Bean : A Component Platform for Sensor-based Services Cristina Marin
Mikael Desertot
Equipe Adele LSR Laboratory Grenoble, France
Equipe Adele LSR Laboratory Grenoble, France
[email protected]
[email protected]
ABSTRACT Sensor-based services propose to gather, manage, analyze, access and react to sensor data. These services are distributed over heterogeneous platforms. The complexity of the implementation of such services requires software engineering tools to relieve the architect and the developer who are often business experts and not technologies experts. Our proposal relates to the definition of a component model dedicated to the development of SBS, called Sensor Bean. Sensor Bean differs from the usual components models by its service orientation and dynamic architecture and the introduction of data-centric connectors well adapted to measurement flows. This proposal is validated by a prototype coupling OSGi and J2EE and by a first component container for OSGi gateways.
Categories and Subject Descriptors D.2.2 [Software Engineering]: Design Tools and Techniques; D.2.11 [Software Engineering]: Software Architectures Domain-specific architectures
General Terms Component models, services, sensors, data gathering
Keywords Sensor-based applications, sensor-based services, component models
1.
INTRODUCTION
The proliferation of smart communicating sensors and the emergence of low-cost Internet connections (offering wired or wireless connection possibilities) support the creation of value-added services exploiting measurements gathered by sensors in their deployment field. These new services, named sensor-based services, may allow the on-line integration of real-world data, for instance, in the information system of
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. MPAC’05 November 28-December 2,2005 Grenoble, France Copyright 2005 ACM 1-59593-268-2/05/11 ...$5.00.
a company thus allowing it to improve the coordination of field devices from a plant floor. Sensors may be deployed everywhere around us: in our house helping us to be up to date with our food provisioning or helping an old person with the everyday tasks [11], in factories, cars. . . . Sensor-based services are used to gather, treat and analyze data collected by sensors from their deployment field. Data can be the RFID identifier of a package, the GPS position of a prisoner, a room’s ambient temperature, a security camera stream or the soldier’s heart beat on the battlefield. Such services are primarily data-centric, their functionality being strongly coupled with the data acquired by sensors. It becomes more and more clear that deploying such services in centralized architectures where one server collects directly sensor data is no longer a reasonable solution [14]. Limitations are encountered when dealing with an important number of sensors and their measurements. Today, new architectures appear for the equipment’s remote exploitation: the use of standardized and intelligent Internet gateways between sensors and IT servers. The gateway deals with equipment administration and the collected data. Furthermore, a mediation protocol can be used between gateways and servers, alleviating the communications and satisfying eventual quality standards (figure 1). Quality of communication and adaptation capabilities are improved by abstracting the sensors infrastructure. Nevertheless, it is clear that the development of sensor-based services for such architectures becomes complex. The reasons are two-folded. The first one deals with the heterogeneity of execution platforms (J2ME, OSGi, J2EE, .NET) and middleware (OMG Data Distribution Service specification, OSGi Wire Admin Service, NIST IEEE 1451.1) deployed in these architectures. The second one considers the dynamic evolution of the deployment environment of sensors expressed by new sensors deployment, possible failures of sensors (transient or critical). In order to resolve this second point, application developers try to consider changes from the design phase. The resulting application is hard to evolve and unable to react to unknown events. We state the need of providing software engineering tools allowing the fast development and deployment of such services. The component-based software engineering (CBSE) approach [20] supports software development through composition of reusable software units (components) by making transparent the use of complex technical services that may be necessary. We argue that existing component models (CCM, EJB, Fractal) could be used to develop sensor-based services but the effort is considerable because here the treat-
Article No. 12
ment model is centered especially on data flows and not on component function calls. Furthermore, such component models do not consider the integration of legacy software and thus already developed services can not be reused when a new sensing infrastructure is deployed. This paper presents our proposal for sensor-based services development. We introduce Sensor Bean, a distributed and dynamic service-oriented component model. The component platform is based on standard existing solutions - component models (EJB for J2EE, Fractal for OSGi) and middleware - tailored for sensor-based service’s development and proposes a data-centric interaction pattern that follows the producer/ consumer paradigm. The article is organized as follows: section 2 gives an overview of sensor applications domain. Section 3 presents our component model proposal. An experimental prototype is presented in section 4. Section 5 discuses related work. Finally, we conclude and give some perspectives.
2.
much better the requirements of sensor-based applications than traditional request-reply schemes [19]. Today, sensor-based applications are designed using primarily two approaches [13]: • data-collection view - were the sensor network is considered a database (see Cougar [5], tinyDB [16]). Gathered data can be either aggregated through routing or processed centrally. Application knowledge is not distributed in the network, everything being processed off-line. The solution is quite generic. In the meantime, it is ill-suited for monitoring applications in resourceconstrained environments. • application-specific view - when conceiving an application over a sensor network, a developer tries to make the best use of his knowledge on the application’s dynamics integrating it in the network. Every decision is made during the design time, thus the resulting system is rigid and difficult to reuse.
SENSOR-BASED APPLICATIONS
Recent advancements in electronics and communications have enabled the development of low-cost sensor networks [15]. These wired or wireless networks are composed from hundreds to thousands small devices that are densely deployed inside or near the phenomenon they are sensing. They are used for a wide range of applications like habitat monitoring, object tracking, battlefield surveillance, traffic monitoring, supply-chain management. Sensors are small devices composed of a power unit (autonomous or not), a sensing unit, eventually a processing unit where data is aggregated or stored and a transceiver used to communicate with a base station or with the neighboring nodes. Limited size and energy autonomy also implies restricted resources (CPU performance, memory, communication bandwidth and range). It was proved that the most power consuming activity performed by sensors is communication. Therefore, special network communication protocols trying to minimize sensor power consumption were proposed [9] (other examples can be found in [3]). We name sensor-based applications the software entities used to gather, interpret measurements collected from sensor networks and perform information reporting and analysis . The special nature of sensor networks makes difficult their development. Sometimes the design of the sensor networks is strongly coupled with the design of the application intented to execute over it. Moreover, one may need to directly interact with the underlying embedded operating system or even the hardware components of a sensor node [22]. Thus, sensor-based application development must follow design methods based on standard system abstractions offered by specialized middleware. The role of middleware residing between the sensor network and the sensor-based application is to provide standard system services, support the execution and the coordination of concurrent applications and provide mechanisms in order to adapt resource usage. The most important demand for sensor-based applications middleware is to ensure support for communication. Communication in sensor-based applications is somehow special. We state that classical synchronous client-server communication is not suited for such application. In the meantime, data-centric communication that is based on a paradigm more similar to content-based messaging is more adapted in this context. Moreover, event-based messaging matches
The following section introduces sensor-based services, software entities that compose in our vision a sensor-based application.
2.1
Sensor-based Services
In order to have an open, reusable, evolving architecture for sensor-based applications, service-oriented computing (SOC) [12] seems to be the right choice. SOC proposes to compose an application from independent and reusable software units named services. Services interact through their interfaces - the single visible entry-point of a service. Architectures are open and dynamic because services can evolve, can be replaced or added to an existing architecture. We argue that a sensor-based application should be realized by composition of independent software units - sensorbased services. The role of a sensor-based service is to gather, aggregate, filter, store and analyze measurements gathered by sensors. The service paradigm is the proper solution for tangling the sensors environment dynamism. The abstraction of sensors as services permits to handle at runtime the addition/ retirement of a sensor. Furthermore, the service paradigm will permit rapid inter-enterprise integration of data coming from different sensor-based applications. One can imagine a sensor-based application that monitors a patient in convalescence at his home. The inter-enterprise integration will permit that hospital’s datafile on the patient to be kept up to date with his evolution. Imagine one sensor-based application which role is among others to control the heating system of a company’s building. This application will be composed of a number of sensorbased services that will cooperate in order to perform the application’s task. Sensor-based services are used to abstract sensor-equipments (for instance a temperature sensor) and to treat data collected by those equipments. One such service may be charged to collect information from multiple similar equipments (”take the temperature from all temperature sensors from the 1st floor of building C”), to filter this data (”take only temperature that is greater than 25 Celsius degrees”), to store it (”memorize the last retrieved value”). Further analysis may be done on collected data. One sensorbased service may have to compute the highest temperature retrieved in the last couple of hours. Another one will have to alarm the guardian of the building that in room x the
Article No. 12
temperature is too high or even to alert the firemen that a fire was detected in room y. Based on collected information, a sensor-based service may send a command to an actuator that will execute it (for instance ”switch off all the lights after 6 PM if no one is still inside”). We have identified a few standard sensor-based services that may appear in the composition of a sensor-based application. One important service that is mandatory for sensorbased applications is the data gathering service. This one is responsible for gathering sensor data, eventually transform it (filter, aggregate) and in the end forward it to another service. One such service may be the mediation service responsible of the measurement transformation, aggregation, correlation. For control applications we may need to use an alarm service that alarms another entity (service, human, equipment) if an abnormal situation is observed. If the application needs to work with measurements collected over a certain period of time, one may use a reporting service which administers data collected over that period of time and presents it in a given form to another entity (service, human).
2.2
Architectures
Sensor-based services will have to be deployed and executed in a proper sensing-architecture with adequate protocols in order to respect the special properties of sensor networks (energy limited, communication limited). This section presents past and current architectures for sensor-based applications deployment and execution. In the early 1990s, data gathering architectures were centralized. SCADA (Supervisory Control and Data Acquisition ) [2] was the most known industrial standard for industrial processes. Sensors were deployed in the environment they were sensing. With SCADA, sensors and controllers were hardwired to the host, which limited the number of sensors the technology could serve and the distance over which data could be transported. Data-servers had to interrogate sensor-equipments in order to collect the last measurement performed. Servers were responsible for data acquisition and handling (alarm checking, calculations, logging and archiving) on a set of equipments, typically those they were connected to. However, SCADA’s nodes were not capable to push data to the central server thus communication level was significant in order to keep up to date information in data-servers. Furthermore, SCADA was based on proprietary technologies, so its costs were not dropped enough to allow widespread deployment. The implementations were complex and time-consuming. Even that industrials may still use this standard, it is clear that deploying sensor-based services in such architecture is no longer a viable solution when dealing with an important number of sensors. With the adoption of M2M (Machine-to-Machine) paradigm [15], distributed architectures for sensor-based applications began to develop. One problem of centralized architectures was the important communication rate between the sensor network and the server. Thus important resources were wasted during the raw data’s transfer. In order to alleviate communication, data treatment logic had to be brought closer to the sensor network. This approach introduced gateways (figure 1) - an ”intelligent” platform were data collected by sensors supports at least a first treatment chain. The gateway has not the processing capabilities of a server but it can administer
Figure 1: Distributed architecture for gathering sensor network’s data
a group of sensors from the network (multiple gateways can be deployed over a large sensor network), gather data coming from that group, treat and even store it locally [7]. The gateway-server communication is sensibly alleviated. Before sending data, the gateway can filter or aggregate it. Furthermore, the gateway may function autonomously, meaning that in case of network failure the gateway himself may react and take decisions based on collected data. The server is a powerful computer with significant treatment capabilities. Here, received data may be again processed - filtered, analyzed, memorized in data-warehouses. Furthermore, one can imagine a hierarchy of gateways deployed over a sensor networks (figure 1). Gateways may manage a set of sensors, upper-level gateways may manage gateways and data coming from them. Furthermore, gateway-to-gateway and gateway-server communication may be alleviated by using mediation middleware [14]. Sensor-based applications will be executed over this distributed infrastructure. Sensor-based services have to be deployed at two levels: on the gateway and on the server. Given the computational different capabilities between those platforms, it becomes clear that we will not be able to have the same execution platforms at these two levels. For instance, the gateway may run over an OSGi framework [17] special designed for small platforms. The server may execute an J2EE infrastructure for high-level data processing. There is another advantage we can take from the service paradigm. We will be able to compose a sensor-based application from sensor-based services developed for different platforms. Considering the heterogeneity of execution platforms over which sensor-based applications will be deployed, we state that is important to provide software engineering tools and mechanisms for the development of such applications. We
Article No. 12
• Multi-platform - we saw that a sensor-based application will execute over a heterogeneous distributed infrastructure. Thus, the components of the application will be distributed and executed over different execution platforms.
present Sensor Bean, a service-oriented component model that is dedicated for sensor-based applications.
3.
SENSOR BEAN - A SERVICE-ORIENTED COMPONENT MODEL
We state in section 2.1 that the most adequate approach for sensor-based application development is a service-oriented architecture. In the meantime, service-oriented approach is not sufficient. We need to have more advanced mechanisms for deployment (service-orientation does not consider deployment), configuration, life-cycle management. Furthermore, non-functional services like distribution, security, persistence are a strong demand of sensor-based applications. Thus, we need to handle and make transparent their usage. The solution to all these problems is the component-based approach. Then, what about the service-oriented approach? We propose to combine these two approaches and define a serviceoriented component model. Such component model introduces concepts from service-oriented computing into a component model. Some advantages appear when having to deal with this approach. Firstly, we can benefit from the advantages offered by component models: automatic handling of non-functional services, life-cycle management. Secondly, one important characteristic of service-oriented approaches is the late-binding property. Component-based composition is realized at assembly time, where service-oriented approaches permit the run-time composition of needed entities. Furthermore, service-oriented compositions are more dynamic in nature than component-based ones since services may be registered/ unregistered at any moment (even at execution). Component-based approaches may permit some degree of such dynamism but in general this is not explicitly supported and must be handled programmatically.
3.1
• Standard compliance - a sensor-based service component model should provide means to integrate existing standards related to IT (HTTP, SOAP, IIOP, JMS) or to sensor applications (Corba DDS, OSGi WireAdmin and Event Admin, UPnP, NIST IEEE 1451.1). • Legacy integration - Furthermore, the component-model must assure the recovery of legacy services already developed for the existing platforms (OSGi, J2EE).
3.2
Sensor Bean Component Model
The Sensor Bean component-model (figure 2) takes into account possible interaction types that these services may need. Like usual component models, our model offers the method-call (EJB, Fractal) and the event-driven connection (CCM). It also adds a new connection that follows the producer-consumer communication paradigm and is used to transmit data among services. Moreover, component ports are dynamic service contracts which let us say that our component model is an service-oriented component model. These ports may be qualified by properties - (published) negotiation parameters and (required) selection properties used in the service discovery phase.
Key Features of the Component Model
We identified some key features that a component-model for sensor-based services development must consider: • Dynamic-awareness since sensors, gateways and even servers (from the distributed architecture presented) may be added or removed at runtime without interrupting the execution of the whole system. • The component-model is service-oriented. The functionality offered by a component will be a service. A service publishes a contract that will be the base for service’s runtime substitution. • Data-centric - the most important property of a sensorbased application is that his functionality is strongly data-centric. Unlike traditional component-models (EJB, CCM, Fractal), where the most important interaction type is the client-server approach and sometimes event-driven interaction (CCM), a componentmodel for sensor-based service development must be oriented on data-centric interactions. Components may communicate through flows of measurements. These flows must be typed to enable dynamic connection. We follow here a producer/ consumer interaction schema which is not implemented in any usual component model.
Figure 2: The SensorBean component model Service requester/ Service provider - These ports are used for synchronous method-call interactions. A component publishes his provided services through the service provider port. Another one demands a service functionality through his service requester port. Event source/ Event sink - These ports are used to publish and subscribe to events. Event sources and sinks are used to transmit events representing semantic information rather than raw measurements (for instance movement detection in a room, crossing of a overheating threshold). Producer/ Consumer - These ports are used to transmit sensor measurements. Producers and consumers are expressed by means of data types they produce (resp. consume). An important aspect is that the initiative of dataexchange is shared by these ports. Thus, a producer having a new obtained measurement can forward it toward connected consumers. In the same way, a consumer can request the last measurement value of one producer. Compared to usual component-models, this interaction type is new.
Article No. 12
Sensor Bean component model intends to be a general purpose model. Therefore, the first step in the development of a sensor-based application is to describe its architecture (figure 3). This architecture describes components configurations and connections between component ports. The ports specify contract properties and selection expressions on other ports properties. Selection expression on port properties enables to restrict the subset of available components providing the right contract. This contract could include quality of service criteria such as control flow for producer consumer port. Connections are established dynamically when required services become available on the execution platforms and only between compatible ports. For requester/ provider and event ports, compatibility is checked on interface typing. For producer/ consumer ports, compatibility is checked on exchanged data typing. The figure 3 presents an example of application monitoring buildings HVAC (Heat, Ventilating and Air Conditioning) for a company. In this distributed architecture, gateways take in charge the data polling. Building servers monitor the building boiler and aggregate measurements for the corporate server. The corporate server stores aggregated measurements and produces periodically reports and analysis. In order to support execution of concurrent applications, Sensor Bean component model permit component sharing (as we can see in the figure). Gateways and servers are different execution environments (for instance, OSGi and J2EE) but there is no impact on the application description. Platform component characteristics and application logic are weaved only at deployment time. One important aspect of component-based software development is the transparent use of technical services also called non-functional services. Interviews with industrial partners of our project suggested that distribution, security and logging are crucial technical services sensor-based applications. Distribution and security are obvious in the context of distributed infrastructures presented in section 2.2. The logging service keeps a certain number of traces about the last measurements gathered from a sensor. Other identified technical services are configuration, persistence, concurrency control, service level agreement,. . . We build an application-design environment where a developer can specify the application and the deployment environments. Based on this specification, we generate code for the target platforms specified for deployment. We have a prototype that helps us to develop sensor-based applications for a distributed infrastructure composed of gateways that run the OSGi framework and servers that execute over J2EE. The next section presents this execution infrastructure and one application we developed to validate our approach.
4.
EXPERIMENTATION
In this section we present a work from which the Sensor Bean component model resulted. It deals with a sensororiented architecture based on OSGi and J2EE technologies. We first describe the distributed infrastructure for sensor data gathering and then we detail a container prototype for the component model above OSGi.
4.1
Sensor data collection infrastructure
As we saw in a previous section, there are many limitations collecting data in a centralized way like SCADA does.
Σ
OSGi Gateways
J2EE Building Servers J2EE Corporate Server
Figure 3: Sensor-based application example
This is why gateways have been introduced to allow both software logic distribution and two-way gateways-server interaction. The main difficulty is to deal with platforms heterogeneity since gateways (that may be embedded systems) have much less capacities than the server. In our distributed sensor infrastructure (figure 4), we use two platform de-facto standards: OSGi for the gateways and J2EE for servers. This choice reflects the heterogeneity that can be found in a real environment. OSGi (Open Service Gateway initiative) is a platform targeting embedded servers. OSGi is an industrial consortium which specifies a deployment platform for software services. The platform relies on Dynamic Service Oriented Programming (DSOP) paradigm. However, OSGi only provides a basic component model which is not sufficient for our requirements. In our prototype, gateways run Oscar a open-source OSGi platform and servers run JOnAS a open-source J2EE server. OSGi gateways manage a variety of real sensors (thermometers, surveillance video cameras, GPS receivers and RFID readers). Gathered and treated data is made persistent in the database of the J2EE server. On the gateway side, the application is composed of two main parts: the information collection from connected sensors and the measurements upload to the server. The initiative of upload is shared between the server (i.e. pull mode) and the gateway (i.e. push mode). The former part relies on the WireAdmin technology defined in the OSGi specification. It introduces a pattern to connect a producer (the real sensor) to a consumer (mediator component, alarm component,. . . ). The communication part relies for the moment on Web Services protocols since servers and gateways can be deployed in a large scale and open network. The pushed upload puts measurements sequences in SOAP envelops that are bound on SMTP messages and JMS messages. The pulled upload is implemented by a SOAP HTTP servlet hosted by gateways and invoked by the server. The gateway embeds also a web server for direct HTML browsing of logs and configurations by maintenance operators with WiFi PDAs. A GPRS/SMS interface is also available for out-door gateways.
Article No. 12
'
'
Servlet /JSP
%
SB
%
SB
EB
MDB
&
" #
&
!
& $
Figure 4: Distributed prototyped architecture for gathering sensor network’s data On the J2EE server side, the application benefits from the gateway’s possibilities previously stated. Values are collected by interacting with a JMS queue or a SMTP server or by requesting Web Services. Uploaded values can be aggregated, filtered and correlated with other gateways uploads and then stored in the database. This database called Sensor Warehouse, stores the history of all measurements in the manner of Decision-Support Data Warehouse in IT systems. Several facilities are available in order to display HTML reports on the histories. The return of experience in building this infrastructure proved the development difficulty in handling both numerous and complex technologies. This is an important issue especially when information technologies are not the core business of the company deploying such data gathering applications. A conclusion of this demonstrator was the need of high-level concepts to hide the underlying infrastructure complexity. Sensor Bean is a response to this assessment.
4.2
OSGi container for Sensor Bean
The OSGi technology proposes only a basic component model that partially fits our requirements. It does not offer multiple service instances, remote service invocation and advanced ports type. Deploying Sensor Bean component toward this platform will be strongly forced with such a limitation. To fit those criteria, we use the OSGi deployment unit like a container allowing components encapsulation of a more complete component model like Fractal. Moreover, once encapsulated, these components ports are registered as services. They can be bound and interact with legacy OSGi components or with others from a different model. Components management interfaces (life-cycle management, binding connections, content controller,. . . ) are also registered
as OSGi services. We prototyped a tool that projects our SensorBean components toward OSGi encapsulated Fractal components. This implementation, named FROGi [6] (Fractal over OSGi), assess the feasibility of using OSGi as a generic deployment container for any component model. Besides that, we have automate the container generation (mapping between components interfaces and OSGi services, services dependencies,. . . ) from the component description in the Fractal component model.
5.
RELATED WORK
We already discussed that the most known industrial component models (CCM, EJB, .NET) are ill-suited for sensorbased applications development. The main reason is that they are resource consumers and gateways can be resourceconstrained systems. They can be systems similar to embeddedsystems. This is the reason for that related work deals with component-models and projects for embedded systems. PECOS (PErvasive COmponent Systems) [8] was designed for field-devices embedded systems that gather data from sensors and react by controlling actuators, valves, motors. It focuses on non-functional properties like memory consumption and timeliness. The component model’s key issues are the component’s cyclic behavior, data-flow oriented interaction and threading. Pecos components have interfaces defined by a number of ports. Ports are the means to exchange data between components. There are three types of ports: input, output and inout ports. Composite components are built by connecting the ports of other components and expressing which ports of the new component will be exported as ports of the composite. The model expresses three types of components. Active components dispose of an own thread of control. They are used to model ongoing or long-term activities that cannot complete in a short cycle-
Article No. 12
time. Passive components, without an own thread control, are used to encapsulate synchronous and short behaviors. Event components behavior is triggered by events. PECOS has his own architecture description language (CoCo) and execution environment. Pecos execution environment abstracts from the underlying real-time operating system and provides language independent interfaces for synchronization. Koala component technology [21] was developed for software development for consumer electronics (CE). It was developed and used by Philips for embedded software development for TV sets. Consumer electronics are resource constrained since they use cheap hardware in order to keep costs low. Thus, the component model pays a special attention to resource usage through a thread-sharing technique which keeps the memory consumption low. A Koala component communicates with the environment through interfaces, a small set of semantically related functions. Koala components are binded by matching provides with requires interfaces. Each one such interface defines ports equivalent to method calls. To limit the runtime overhead, Koala component model uses static binding wherever possible. One of the limitations is the evolution of components because interfaces are immutable. This means that one provides interface can not be enriched with methods. The developer has to declare another provides interface where new methods should be added. In our case, this is not convenient because we have to deal with a dynamic system without having to restart the software turning on top of the sensor network. The Robocop component technology [1] aims at covering all the aspects of a component-based development process for the consumer device domain. Key issues here are cost, security and robustness. The Robocop component is composed of a set of models. It represents the unit of trading. Each model provides a particular type of information about the component. Components contain executable services. The non-functional model includes modeling timeliness, reliability and memory consumption. The Robocop architecture defines two interrelated frameworks: the development framework and the execution framework. The development framework defines a number of aspects of the development, trading, and downloading of Robocop components. The Robocop execution framework (Robocop Runtime Environment) defines the execution environment for components and certain aspects of their dynamic behavior. The Rubus component model [4] was developed for small embedded systems. The component technology includes a scheduler and a graphical tool for application design. It is tailored for resource constrained environments with realtime requirements. It can be equally used for strict realtime applications like control applications, where the requirements are almost time-critical, and soft real-time applications where communications are event-triggered. Each Rubus component has a set of Input Ports where data is received, and a set of Output Ports where data is produced. Components can be combined to form a larger component. The propagation of signals (data) takes place with the invocation of the logic as guided by the scheduler offered by the Rubus Operating System (Rubus OS). A single Rubus software component, as well as the set of software components for handling a particular application, may be distributed over several nodes. SaveCCM [10] is a component model developed for the
SAVE (Component Based Design of Safety Critical Vehicular Systems) project. The idea is to provide an efficient support for designing and implementing embedded control applications for car systems. Like our component model, SaveCCM’s functional interface is defined through ports. Ports may be data-only ports, triggering-only ports and data and triggering ports. SOFA [18] is a new component model that offers the three communication types we identified for sensor-based applications. It is an hierarchical component model used initially to solve the problem of the software dynamic changes. Communications between components are carried out by entities called connectors. Like our component model, SOFA proposes 3 types of connectors: CSProcCall which models method calls interactions, EventPassing - modeling communication by messages and DataStream relating to data transmission. The difference resides in the fact that DataStream connectors are used to carry out binary data transmissions and Sensor Bean’s producer/consumer ports permit typed data transmission between components. These examples show that there are many component technologies for development of resource-constrained systems like embedded systems. The differences are that depending on the domain targeted requirements are different and thus solutions are numerous. This calls for specialization and not for generalization. Our component model is general but specialization is made in the code-generation phase where system constraints are taken into account. One point that our component model does not yet consider is the non-functional properties like memory consumption, resource usage but we consider that this is more an implementation issue.
6.
CONCLUSIONS
This paper has presented Sensor Bean, a general serviceoriented component model for sensor-based applications development. Unlike usual component models like EJB, CCM, .NET, we introduced a specified producer/ consumer connection that is used to transmit typed data between components. Other components models are either platform related (EJB or .Net) or general (Fractal, Avalon). Sensor Bean innovates by being centered on the treatment of measurement flows gathered by a myriad of sensors in a distributed, multiplatforms and dynamic architecture. The assembly unit of our component model is the component. Assembly is done by means of three types of connectors: service provider/ service requester, event sources and sinks and producer-consumer. Whereas the first two types are found in usual component models, the producerconsumer connector focuses on the exchange of measurements gathered by sensors and the two protagonists can have the initiative of the exchange. Connectors are expressed in term of service contracts qualified to ensure the property of substitutability of components sought by the service-oriented architectures. The architecture of services is dynamic to take into account the appearance and the final or temporary failures of physical sensors or gateways in this environment. We experimented our work by an implementation of SensorBean freely available at http://www-adele.imag.fr/ sensorbean. The demonstrator carried out an OSGi gateways and J2EE servers. We also developed a first prototype of container generator for Sensor Bean destined to the OSGi
Article No. 12
architecture part. This container combines at the same time Fractal and OSGi. This work is carried out in the RNRT PISE project (Passerelles Internet Securisees et flExibles) granted by the french Ministry of Industry.
7.
REFERENCES
[1] Robocop project home page. http://www.hitech-projects.com/euprojects/robocop/. [2] Supervisory Control and Data Acquisition. http://ref.web.cern.ch/ref/CERN/CNL/2000/003/scada/. [3] I. F. Akyildiz and all. A Survey on Sensor Networks. IEEE Communication Magazine, vol. 40:102–114, August 2002. [4] Arcticys Systems Home Page. www.arcticus.se, March 2003. [5] P. Bonnet and all. Querying the Physical World. IEEE Personal Communications, vol. 7(no. 5):10–15, 2000. [6] H. Cervantes and all. FROGi : Deploiement de composants Fractal sur OSGi. In 1ere Conference Francophone sur le Deploiement et la (Re) Configuration de Logiciels, Octobre 2004. [7] R. Clauber. RFID and Sensor Networks. From Sensor/Actuator to Business Application. RFID Workshop, University of St. Gallen, Switzerland, September 2004. [8] T. Genssler and all. Components for embedded software: the PECOS approach. In CASES, pages 19–26, 2002. [9] C. Hall and all. A Content-Based Networking Protocol For Sensor Networks. Technical Report CU-CS-979-04, Department of Computer Science, University of Colorado, August 2004. [10] H. Hansson and all. SaveCCM - A Component Model for Safety-Critical Real-Time Systems. In EUROMICRO, pages 627–635, 2004. [11] S. Helal and all. The Gator Tech Smart House: A Programmable Pervasive Space. IEEE Computer, March 2005. [12] M. N. Huhns and M. P. Singh. Service-Oriented Computing: Key Concepts and Principles. IEEE Internet Computing, vol. 9:75–81, Jan./Feb. 2005. [13] J.Liu and F. Zhao. Towards Service-Oriented Networked Embedded Computing. Technical Report MSR-TR-2005-28, Microsoft Research, February 2005. [14] P. Lalanda. E-services Infrastructure in Power Distribution. IEEE Internet Computing, May/June 2005. [15] G. Lawton. Machine-to-Machine Technology Gears Up for Growth. IEEE Computer, vol. 37:12–15, September 2004. [16] S. R. Madden and all. TAG: a Tiny AGgregation Service for Ad-Hoc Sensor Networks. In Proc. 5th Symp. Operating Systems Design and Implementation, December 2002. [17] Open Services Gateway Initiative. OSGi Service Platform (3d Release). www.osgi.org, March 2003. [18] F. Plasil and all. SOFA/DCUP : Architecture for Component Trading and Dynamic Updating. In I. C. Press., editor, Proceedings of ICCDS 98, Annapolis, Maryland, USA, May 1998.
[19] K. Romer and all. Middleware Challenges for Wireless Sensor Networks. ACM SIGMOBILE Mobile Computing and Communications Review, vol. 6:59–61, 2002. [20] C. Szyperski. Component Software: Beyond Object-Oriented Programming. Addison Westley Longman, 2nd edition, November 2002. [21] R. van Ommering and all. The Koala Component Model for Consumer Electronics Software. IEEE Computer, 33(3):78–85, March 2000. [22] Y. Yu and all. Issues in Designing Middleware for Wireless Sensor Networks. IEEE Network Magazine Special Issue, vol. 18:15–21, January 2004.
Article No. 12
