Lightweight Middleware for Seamless HW-SW Interoperability, with
Application to Wireless Sensor Networks
F. J. Villanueva, D. Villa, F. Moya, J. Barba, F. Rinc´on and J. C. L´opez
Department of Information Technologies and Systems
School of Computer Science
13071, Ciudad Real, Spain.
[email protected]
Abstract
HW-SW interoperability by means of standard dis-tributed object middlewares has been proved to be useful in the design of new and challenging applications for ubiq-uitous computing and ambient intelligence environments. Wireless sensor networks are considered to be essential for the proper deployment of these applications, but they im-pose new constraints in the design of the corresponding communication infrastructure: low-cost middleware imple-mentations that can fit into tiny wireless devices are needed. In this paper, a novel approach for the development of pervasive environments based on an ultra low-cost imple-mentation of standard distributed object middlewares (such as CORBA or ICE) is presented. A fully functional proto-type supporting full interoperability with ZeroC ICE is de-scribed in detail. Available implementations range from the smallest microcontrollers in the market, to the tiniest em-bedded Java virtual machines, and even a low-end FPGA.
1. Introduction
The perceived value of an ubiquitous system is mainly due to its ability to create and to support end-user services. Firstly we should be able to acquire and distribute as much information from the environment as possible. Then we should be able to build robust scalable distributed applica-tions based on that information. Two major components should interact seamlessly: networked sensor/actuator de-vices and distributed serde-vices.
Wireless sensor networks (WSN) provide an excellent platform for the development of useful ubiquitous comput-ing applications. Our aim is to integrate them in the global system in such a way that software developers do not need to make distinction between interacting applications in a
WSN and a typical distributed application in a traditional network.
In this paper, we are mainly concerned with the imple-mentation of minimum cost devices able to support the large variety of device and network technologies currently de-ployed in the target environments. Besides, we also in-tend to make them interoperable with traditional distributed software platforms for easier deployment of next generation services.
Our goal, then, is to allow wireless sensor devices to ex-port their capabilities as if they were standard distributed objects. These objects should be able to hide the hetero-geneity of underlying technologies such as transport proto-cols and network architecture and topology.
2. Previous work
There are dozens of distributed object implementations in the market: DCOM, Java RMI, Jini, EJB, CORBA, Web Services, .NET Remoting, ZeroC ICE [2], etc. Most of them rely on a shared networking core, the communi-cation middleware, which provides locommuni-cation and network transparency. Unfortunately, the mentioned implementa-tions of standard object oriented middlewares require too much computing resources for our target devices. In this paper we will center on ZeroC ICE, an excellent CORBA-like middleware, but the same approach is also applicable to the other middlewares.
Lowering the cost of embedding a distributed object middleware has been the focus of some miniaturization ef-forts. There are three common strategies to reduce the foot-print of an embedded middleware [15]: 1) to remove costly features keeping a good degree of genericity, 2) to adapt the middleware to specific devices, or 3) to use proxies.
The first approach is used by the Object Management Group [14] in MinimumCORBA [7], a lightweight version of its widespread CORBA [6] architecture. Others efforts
in this way include e*ORB [1] or dynamicTAO [10] and its descendants: LegORB [16] and UIC-CORBA [18]. Micro-QoSCORBA [9] and nORB [19] also use this first strategy. A representative of the second approach to the develop-ment of small footprint middlewares is PalmORB [17].
The third alternative requires a mediating host to allow interoperability with objects in a standard middleware. This approach is used by UORB [15] and one of the integration alternatives proposed in SENDA [13]. For further details over these three different strategies please see [20].
All these previous works follow the same basic rules: they remove dynamic invocation and dynamic instantia-tion features, they simplify the interface definiinstantia-tion language (OMG IDL in the case of CORBA) removing complex or variable length data types, they also remove some fields from the communication protocol, they also remove or sim-plify the types of messages used in the protocol, they even drop support for indirect references or common services, and they modularize the communication engine and instan-tiate only those components which are actually used.
There are also a number of proposals for WSN middle-wares such as TinyLime [4], TinyDB [12] or Sensation [8]. Unfortunately they require too much computing resources to be useful in our target devices. Specifically, TinyLime and TinyDB requires TinyOS [12]. Additionallly TiniDB requires a query parser in each node and Sensation provides of a middleware integration architecture by means of a sen-sor abstraction layer and a XML based unified sensen-sor lan-guage.
Besides, all of them introduce specific API’s and archi-tectures which contribute to increase the learning curve and make more difficult the interoperability with high level ap-plications (from application developer point of view). We need something much smaller, self-contained, and much cheaper, but with a similar set of features.
3. Minimal footprint
Instead of removing even more features from the mid-dleware, let’s think the other way. First we will define the smallest feature set that a distributed object should provide. Then we will consider the overhead introduced for each ad-ditional feature and whether they meet the application con-straints.
Although it is important that each device looks like a tributed object, it is not essential that they are actual dis-tributed objects. If devices are able to generate coherent replies when they receive predefined request messages then the system will work as expected. For a given communi-cation middleware these requests and reply messages are completely specified by the communication protocol (ICEp in the case of ZeroC ICE or GIOP in the case of CORBA).
If the device is just an application-specific ICEp server it will be seen as a standard object from the network but there is a huge potential for resource savings. The object may get rid of the whole communication engine and its API. There is no need for object adapters, marshalling routines, etc. We just need to implement the message handling code for those messages whose destination is an object placed at the device. Therefore there would be a generated ad-hoc implementation for each device.
We used the above implementation strategy to develop a set of functional prototypes namedpicoObjects. In sum-marypicoObjectsprovide a toolset for the automated gen-eration of code able to replace a standard communication engine in WSNs devices.
Code generation must be performed with careful consid-eration of the constraints imposed by the target platform. Generated code is obviously different for each platform but it will also differ for servers with a different set of objects, even when the platform and the object interfaces are the same.
It is worth noting that a server implemented using this technique will only reply to messages directed to its resident objects. Messages handled by the communication middle-ware (such as object location in CORBA) will be silently discarded. It is always possible to include these messages as the methods of a special object if needed.
A communication middleware will usually expose two different interfaces to access every service in the system: 1) at the programming level, it provides a standardized ap-plication programming interface which abstracts commu-nication details, protocols, etc.; 2) at the network level it provides a common protocol (ICEp in case of ZeroC ICE) allowing seamless interconnection among communication engines running on different machines.
A picoObject lacks in a local communication engine. The server program must include code to perform com-munication primitives and manage its registered objects. Nonetheless, for the rest of the network apicoObject be-haves as an usual object. It provides a network level inter-face without significant differences with respect to a stan-dard object. We may say that a picoObjectimplements a virtual communication engine.
PicoObjects may also handle client-side communica-tions using similar techniques. Client-side messages are composed as a set of templates with just the bare minimum configurable fields.
4. General design of
picoObjects
The main goal ofpicoObjectsis the implementation of the essential features needed for a device to expose a stan-dard object behaviour in the network. From that point we intend to define and develop mechanisms to scale the
func-tionality of the device depending on the constraints im-posed by the target platform. Our initial targets range from the smallest and cheapest eight-bit microcontroller (even cheaper and smaller than the common choice for wireless sensor devices) to a standard PC.
It may be argued that generating the message handling code for a whole communication middleware does not of-fer any particular advantage over a standard middleware. Even in that case there are situations that may favour our approach over full-blown middlewares (reliability, real-time constraints, security, etc.).
We define the minimum set of features using the siderations made in section 2, adding a few additional con-straints for the sake of simplicity:
• We always follow the standard message format for the communication protocol.
• We will only support the simplest protocol version whenever interoperability is not compromised.
• We will not support common middleware services (e.g. Naming and Event services).
• Implementations will be fully static.
• Resident objects are always on. There is no way to activate or deactivate objects.
This set of features warranties a compliant behaviour with no need of mediator devices. This fact has been veri-fied by means of several prototypes (see section 5).
PicoObjects can be looked up at the middleware ORB (Object Request Broker) and used just like any other object, without any difference for the client.
The simplest way to achieve a coherent behaviour for each picoObject is by means of message matching au-tomata. In this context, the allowed message set for a given object constitute a BNF grammar defined by the following elements:
• Message format for the middleware communication protocol.
• Object identity, that is to say, unique object identifiers. It should be noted that several object identities may be backed by a single piece of code. This technique is usually calleddefault servantin CORBA parlance.
• Concrete interfaces provided by the object. It includes name, arguments and return value for each method (SLICE declaration in ICE or IDL in CORBA).
• Serialization format (CDR in case of CORBA).
• Standard interfaces inherited from the communication engine (Ice::Object in case of ICE).
• Constraints for the target platform.
From the careful analysis of these elements we define the set of lexical elements (tokens): compulsory fields in each message with a known format and size, object identities and identifiers for methods and interfaces.
Then we generate the rules describing how these tokens may be combined together (the BNF grammar). This in-formation is enough to automatically generate a fully func-tional parser. The whole development flow is shown in Fig-ure 1.
EverypicoObjectmust include a set of user procedures (object method implementations) that must be filled by hand (as in any traditional middleware). When the grammar parser of aPicoObjectidentifies a whole request message, the corresponding user procedure is automatically invoked and a reply message is generated. If the parser fails to iden-tify a valid method request, then the message is discarded and thepicoObjectlooks for a new synchronization point at incoming data.
Figure 1.picoObjectDevelopment Flow
Input and output messages may be handled on-the-fly us-ing a generated byte-stream processor. This is a very conve-nient solution for devices with severe memory constraints (just a few hundred program memory words and a dozen general purpose registers). In this scenario there is no room to even store the incoming message. The request message is processed as the bytes arrive and the reply message is also generated partially from replication of the incoming data. The last part of the reply message is generated by the user procedure for each method.
Our strategy is quite different with respect to previ-ous middleware minimization approaches such as Micro-QoSCORBA. MicroQoSCORBA tries coarse grain code minimization by building a custom implementation from predefined libraries.PicoObjectsuse a finer grain code min-imization strategy by completely generating the message parsing code for each application.
5. Sample prototypes
The above approach has been applied to a pair of ex-isting middlewares: CORBA and ZeroC ICE, leading to
picoCORBA and picoICE respectively. The constraints im-posed by each particular middleware lead to slightly differ-ent design decisions. We will describe in depth the ICE prototype as “proof of concept” of aPicoObjectreal imple-mentation.
Both prototypes were developed in Microchip PIC as-sembler, Java on a standard embedded PC, Java on an em-bedded Dallas Semiconductors TINI device, C on a stan-dard embedded PC, and VHDL on a Xilinx VirtexE FPGA. We are currently integrating the prototypes in WSNs plat-forms like Zigbee CC2420 based development kit from Chipcon [3].
The latency for the responses depends on the trans-port mechanism. Our prototypes using a Lantronix XPort for TCP/UDP encapsulation introduce some latency due to buffering and timeout driven packetization. However, the transport layer may easily be changed without major mod-ifications in the picoObject. For example, the SLIP based prototype begins the transmission of serial response pack-ets well before the end of the request.
Two simple but fully functional prototypes supporting complete interoperability with CORBA and ICE, with spe-cific developing details, are available in our website at [5].
6. PicoICE
ICE is a CORBA-like middlware which implements a feature set unparalleled in any other distributed object plat-form (object persistence, object migration, authentication, security, replication, deployment services, firewall gate-ways, etc.). A summary of the differences between ICE and CORBA is available at the ICE home page [2].
ICE already provides a reduced implementation for em-bedded devices, and offers a few advantages over CORBA to reduce resource usage even further. ICE protocol is sim-pler than GIOP for a number of design decisions:
• Messages are always little-endian so we do not need to care about byte ordering.
• There is support for unreliable transports such as UDP (much easier to implement in a low cost embedded de-vice).
• There are less types of messages and some of them may not be implemented without compromising inter-operability.
• Unprocessed message fields may be easily skipped be-cause they are usually preceded by the field length.
• There are no data alignment requirements for messages on-the-wire.
Embedded middleware Minimal server code size
TAO 1738 KB + OS nORB 567 KB + OS MicroQoSCORBA (TINI) 21 KB + OS UIC/CORBA 35 KB + OS ZEN (Java) 53 KB + OS picoCORBA (Java) 5 KB + OS picoCORBA (TINI) 4 KB picoCORBA (C) 5.2 KB + OS picoICE (C) 5.4 KB + OS
picoCORBA (PIC12C509) 415 words
picoICE (PIC12C509) 503 words
Table 1. Small server sizes on embedded mid-dlewares
The picoICE prototype fully conforms to the ICE pro-tocol specification for connection-oriented transports and connection-less transports. Any reliable or unreliable trans-port protocol may be used in combination with picoICE ob-jects.
An implementation of a fully operative servant, able to handle method invocations for a set of 64 X10 (well known control protocol used for in-home networking) ob-jects fits on less than 1KB of program memory in a Mi-crochip PIC12f675 microcontroller (see table 1) and needs less than 16 eight bit registers. That is three orders of mag-nitude smaller than the ZeroC ICE implementation and two orders of magnitude smaller than the ZeroC Embedded ICE implementation.
Currently we support TCP and UDP transports over Eth-ernet or WiFi through a Lantronix XPort device. A picoOb-jectmay also be connected to a SLIP (serial line IP) serial port.
In [11] a survey of most used WSN HW platforms and their resource requirements is presented. The required code/data memory for these platforms ranges from 60 KB / 1 KB (MOS) to 128 KB / 64 KB (Btnodes). In Table 1 we can see how our implementation fits in all these platforms.
Although, for the same type of implementation (i.e. C language), picoICE objects are a bit larger than pico-CORBA objects this is only due to the extra introspection features supported by ICE, that may be removed if they are not needed.
Any ICE object implements an standard interface called Ice::Object defining a set of common methods. Fortunately some of these methods are already handled by the client stubs provided by the standard middleware interface com-piler or by the communication engine at the client side. Therefore there is no need to implement all of them as po-tential ICEp messages.
andice isA. These methods add minimal introspection ca-pabilities and the ability to remotely test the existence of an object. This and other interoperability implementation details are explained with detail in [20].
6.1. Asynchronous Advertisements
When a picoICE either needs to communicate a state change or wants to advertise itself to the network it can gen-erate an event using the ICEStorm service (an efficient pub-lish/subscribe standard service for ICE applications). Gen-erating an event in picoICE implementation requires a sin-gle ICEp message to a previously known ICE channel.
For example, a minimal advertisement service requires that anypicoObjectsends an event (advoperation) contain-ing its own reference (its ICEproxyin ICE parlance) to an administrative channel in order to be known by the rest of the network and applications. In order to save memory re-sources, this first message shares most of the information with the events generated to notify a change in the state of the sensor or actuator.
An ICE packet generated by a picoObject event looks like this:
Magic Number: ’I’,’c’,’e’,’P’ Protocol: 1,0 Encoding: 1,0 Message Type: Request (0)
Compression Status: Uncompressed (0) Message Size: 53
Request Message Body Request Identifier: 0
Object Identity Name: publish Object Identity Content: asdf Facet Name: (empty)
Operation Name: adv
Ice::OperationMode: normal (0) Invocation Context: (empty) Input Parameters Size: 16 Input Parameters Encoding: 1,0 Encapsulated parameters (10 bytes)
Most of the fields are kept constant for all messages, and only Object Identity name, Object identity content, Opera-tion name and, obviously, the parameters differ.
7. Implications in WSN design flow
Let’s see how the design flow for an application over WSN using our approach looks like. At the beginning, it is necessary, like in the design of any distributed applica-tion, to specify the object interfaces. The simplest interface that we use for a WSN would be:
module iFloat { interface R { float get(); };
};
In our case, we specify that interface using SLICE, the definition language defined by the ICE platform (CORBA uses IDL and JINI uses JAVA). With this interface we can get, for example, the temperature of a sensor node.
At this point it is necessary to generate an object identity in order to identify the object inside the network: this is called in ICE the universally unique identifier (UUID). The simplest UUID is a string, for example WSN-O1, WSN-O2, etc.
This UUID identifies the object in the network. If a WSN node implements two objects, each object needs its own UUID.
After that, we specify the standard methods of the inher-ited ICE::Object interface which have to be implemented by thepicoObject(ice ping,ice isA, ...).
All this information, specified as follows, is gathered in a file that feeds the automatic generator:
uses WSN.ice interface Ice.Object{ ice_ping, ice_isA, ice_id, ice_ids} WSN-01: WSN.iFloat.R, Ice.Object
Now we need to generate the stubs for the client and the skeleton for the server (the WSN node in our target environ-ment). The client stubs can be generated with the off-the-self SLICE compiler from the interface definition (like in any traditional distributed application). The skeleton for the server is generated with our compiler from the file shown above. The compiler generates a platform independent fi-nite state machine that recognizes the incoming messages and produces the appropriate responses. This finite state machine is then compiled (next step) to several specific lan-guages such as standard C, Microchip PIC assembler, Java or VHDL (for a specific hardware implementation).
In the last step of the design flow, the wireless sensor developer has to write the particular implementation of the get() method for this application, that is, he/she decides the specific actions to be performed when the method is invoked (i.e., to “read” the temperature value from the hardware sen-sor and then to return the value).
The implementation of the complete client application does not differ from any other traditional distributed appli-cation.
As a conclusion the advantages of using our approach to the design of WSN applications include:
• We provide to the WSN application developer with generic and high-level programming inter-face that allows to completely abstract the design from technology-specific WSN issues. The soft-ware/hardware objects that resides in the sensor nodes
can be looked up at the communication engine (ORB) and used just like any other object.
• We provide tothe embedded code developerwith a set of tools that automatize the creation of the communi-cation infrastructure that allows a wireless sensor node to interact with the rest of the WSN and even with any other system out of the WSN. The programming and configuration of a sensor network are very difficult and error prone tasks [4]. With our approach, the com-piler generates all of the communication related code (obviously, if the platform is conveniently supported). Currently we support the PIC microprocessor family and we are working in the Atmel family (both of them broadly used in the design of WSNs).
• We provide tothe designer of sensor nodeswith a mid-dleware which can be implemented in hardware just specifying a set of basic parameters (the supported in-terface and the object identifiers). In fact, we have al-ready extended our set of tools to automatize the gen-eration of the VHDL code that corresponds to the hard-ware version of the communication engine.
8. Conclusions and future research
In this paper we propose a set of techniques for the im-plementation of distributed objects on low cost WSN de-vices such as eight-bit microcontrollers. Results show that resource consumption is two orders of magnitude than pre-viously published data on small middlewares implementa-tion.
As they are currently implemented,picoObjectsexhibit ultra-low latency, since the reply messages are composed on the fly while the object is still receiving the request. This makes them specially suitable for low-latency opera-tion even on low bit-rate networks.
As the basic prototypes still evolve, we are now devel-oping high level tools to deploy a completepicoObject net-work. We are also extending the concept to support other middlewares.
PicoObjects are being used as major components of SENDA, a middleware-based infrastructure for modelling, development, and deploying of next generation ubiquitous computing services [13].
9. Acknowledgements
This research is partly supported by FEDER and the Spanish Government (under grant TIN2005-08719) and by FEDER and the Regional Government of Castilla-La Man-cha (under grants PBC-05-0009-1 and PBI-05-0049).
References
[1] Openfusion e*orb. available online at http://www.prismtechnologies.com/.
[2] Zeroc, inc. ICE Home Page. available online at http://www.zeroc.com/.
[3] Chipcon. Cc2420 zigbee dk user manual v1.0. Available online at http://www.chipcon.com.
[4] C. Curino, M. Giani, M. Giorgetta, and A. Giusti.
TinyLIME: Briding Mobile and Sensor Networks through Middleware.PerCom, 2005. Hawaii. USA.
[5] A. Group. Picoobject web demostration example. http://arco.inf-cr.uclm.es/marisa.html.en.
[6] O. M. Group. The Common Object Request Broker: Archi-tecture and Specification. Technical report, Object Manage-ment Group, 1999. Available in http://www.omg.org/. [7] O. M. Group. Minimum CORBA Specification. Technical
report, Object Management Group, August 2002. available online at http://www.omg.org/.
[8] T. Hasiotis, G. Alyfantis, V. Tsetsos, O. Sekkas, and S. Had-jiefthymiades. Sensation: A middleware Integration Plat-form for Pervasive Applications in Wireless Sensor Net-works.EWSN, 2005. Instambul Turkey.
[9] Haugan and Olav.Configuration and Code Generation Tools for Middleware Targeting Small Embedded Devices. Mas-ter’s thesis, M.S. Thesis, Dec 2001.
[10] F. Kon, F. Costa, G. Blair, and R. Campbell. The Case for Reflective Middleware.
[11] M. Kuorilehto, M. Hannikainen, and T. Hamalainen. A sur-vey of Application Distribution in Wireless Sensor Networks.
EURASIP Journal on Wireless Communications and Net-working, pages 774–788, 2005.
[12] S. Madden, J. Hellerstein, and W. Hong. TinyDB: In-Network Query Processing in TinyOS, September 2003. Ver-sion 0.4.
[13] F. Moya and J. L´opez. SENDA: an alternative to OSGi for large-scale domotics. The Proceedings of the Joint Inter-national Conference on Wireless LANs and Home Networks (ICWLHN 2002) and Networking (ICN 2002), 2002. World Scientific Publishing, pp 165-176.
[14] OMG. Object management group. http://www.omg.org. [15] Rodrigues, G., Ferraz, and C. A CORBA-Based Surrogate
Model on IP Networks, 2001.
[16] M. Roman, M. Dennis, Mickunas, F. Kon, and R. Campell.
LegORB and Ubiquitous CORBA. Technical report, Feb 2000.
[17] M. Roman and A. Singhai. Integrating PDAs into Dis-tributed Systems: 2K and PalmORB. HUC, 1999.
[18] M. Rom´an, F. Kon, and R. H. Campbell.Reflective Middle-ware: From Your Desk to Your Hand, 2001.
[19] V. Subramonian and G. Xiang.Middleware Specification for Memory-Constrained Networked Embedded Systems, 2003. [20] D. Villa, F. J. Villanueva, F.Moya, F. Rinc´on, J. Barba, and J. C. L´opez. Embedding a general purpose middleware for seamless interoperability of networked hardware and soft-ware components. In proceedings of Grid And Pervasive Computing (GPC), LNCS, Taiwan, 2006.
