A Middleware-centric design methodology for networked embedded systems

Ambient intelligence, pervasive and ubiquitous computing are the center of a great deal of attention because of their promise to bring benefits for end-users, higher revenues for manufacturers and new challenges for researchers. Typical computing technologies (such as telemedicine, manufacturing, crisis management) are part of a broader class of Networked Embedded Systems (NES) in which a large number of nodes are connected together and collaborate to perform a common task under a defined set of constraints. Therefore, the key aspects of these applications are their distributed nature and the presence of very limited HW resources, as in case of WSNs. Their wide adoption requires interoperability across different manufacturers, simplification of application development, simulation tools for functional validation and the fulfilment of tight HW/SW constraints. Interoperability is achieved through the use of standard protocol stacks (e.g., IEEE 802.15.1/Bluetooth and IEEE 802.15.4/Zig- Bee). Simplification of application development can be achieved through a service layer, named middleware, which abstracts from the peculiarities of the operating system and HW components. Traditionally, many NES applications have been developed without support from system software [1] excepts for device drivers and operating systems. State-of-the-art techniques [2] for NES focus on simple data-gathering applications, and in most cases, the design of the application and the system software are usually closely-coupled, or even combined as a monolithic procedure. Such applications are neither flexible nor scalable and they should be re-written if the platform changes. Middleware is emerging as an important architectural component in supporting NES applications able to facilitate the application development. The role of middleware is to present a unified programmingmodel to application designers and to mask out the problems of heterogeneity and distribution providing a basic set of tools and libraries for the low-level handling of technology-specific NES. Several NES middleware have been implemented in the past years each one providing different programming paradigms (e.g., Tuplespace, messageoriented, object-oriented, database, etc.) and differ with respect to ease to use, expressiveness, scalability and overhead. However, their diversity makes the development of high quality middleware-centric software systems complex: software engineering methods and tools should be developed with the use of middleware in mind. In such way, Sensation [xxx] presents a middleware platform solution for pervasive applications inWSN providing a developer-friendly programming interface. This approach is valid just for WSN and does not include a network simulator for an exhaustive network evaluation. Model Driven Architecture (MDA) tries to overcome this problem; MDA is a new way of writing specifications, based on a platform-independent model. A complete MDA specification consists of a platform-independent UML model, one or more platform-specific models, and interface definitions, each describing how the base model is implemented on a different middleware platform. The MDA focuses primarily on the functionality and behaviour of a distributed application or system, not on the technology in which it will be implemented. Furthermore,MDA does not directly provide a simulation environment. Simulation tools are used for validating the application: there is a range of NES simulators available that focus on the network itself. NS-2 is a pure network simulator tool, where the nodes are abstracted and do not run real codes or operating systems, but rather simple behavioral models or statistical traffic generators. The advantage of NS-2 is that scalability is excellent. TOSSIM is a platform-specific simulator environment for sensor networks based on TinyOs operating system. TOSSIM can compile unchanged TinyOS applications directly into its framework, which means that most of the codes written for TOSSIM can be directly used in TinyOS. TOSSIM is a specific simulator for TinyOS and Berkeley motes and cant be used for simulating a generic NES (e.g.,WSN). Finally, SIMICS is a commercial full-system simulator that can be used to simulate heterogenous networked and distributed systems. Complete SW stacks from real system can run on the simulator without any modification. Despite of these punctual contributions, the literature does not report a complete design methodology for NES applications integrating all such three aspects. Therefore, in order to fully support the applications of a great variety of users with different needs, a complete NES application modelling and simulation environment have to include two main components: • a simulator to validate and explore application functional behaviuor in a network simulated environment supporting interoperability between different implementation platforms and ensure scalability of the NES technology. • a middleware environemnt providing different programming paradigms. This Layer will serve as an abstraction layer hiding the different NES implementations peculiarities from end-user applications. The goal of this work is to present a middleware-centric design flow for NES, where the middleware plays a decisive role in the design process. The proposed methodology allows programmers to write NES applications by using the system description language named SystemC and the AbstractMiddleware Environment (AME) framework for fast simulation. This proposal has three main advantages: (1) It provides a set of abstract services supporting the programming paradigms of different actual middleware implementations in order to meet the skills of the designer. AME facilitates the NES design flow by providing a unified and developer-common interface concealing the peculiarities of the underlying NES where the simulation environment is modelled in order to simulate the NES applications taking in account hardware and network effects. (2) The application can be simulated at early stage of the design flow for functional validation. (3) automatic mapping of AME applications on the actual platform; this guarantees the correct trade-off between level of abstraction and efficiency of implementation. In the follow we classify the actual middleware approaches according to their programming paradigms; then the AMEcentric design flow is described and finally we report the experimental results.