Middleware for Networked Embedded Systems

Literature Review Project

Instructor : Dr Xiaolin Hu

Rajapaksage Jayampathi

DM Rasanjalee Himali

Outline

Networked Embedded Systems(NESs) Types of Networked Embedded Systems

Middleware for NESs Design and Implementation Challenges Non-Functional Requirements Functional Requirements

A Case Study : RUNES Middleware : Disaster Management Scenario

Applying Patterns to build middleware for NESs

Networked Embedded Systems(NESs)

Embedded Systems a computer system designed to perform one or a few

dedicated functions often with real-time computing constraints

Embedded systems span all aspects of modern life and there are many examples of their use. Telecommunications:

Telephone switches, mobile phones Consumer electronics:

PDA, mp3Players, digital cameras, GPS receivers Household Appliances:

Microwave ovens, washing machines Transportation Systems:

Automobiles, motor controllers, ABS

Types of Embedded Systems

Mobile Systems Nomadic

Core fixed network | Some mobile nodes | Ex: cellular network Ad Hoc

No fixed core structure | each node may be mobile Both cases : Network links wireless | devices change location frequently

Embedded Systems Computing components built-in to some other purpose built device (ex: car/

aircraft) Not mobile Not networked in large scale Often wired

Sensor Systems Large no. of tiny devices monitoring some environmental condition and

report back to a central server Usually not mobile | connected through radio links Ex: wireless sensor networks

NESs Middleware Why not General purpose middleware?

General Purpose Middleware: (-) designed for devices with almost no resource limitations (-) Interactions assume stable, high bandwidth constant connection (-) synchronous point-to-point communication

This is inappropriate for applications with need for real-time performance or limited memory.

To resolve this tension, special-purpose middleware must be designed. Therefore, careful selection of features is crucial for memory

constrained and/or real-time networked embedded systems.

Challenges and Requirements

Challenges: No stable network infrastructure : disconnections more

frequent/unexpected Devices need to discover each other in an ad-hoc manner Severely constrained by scarce resources : low battery, slow CPU,

limited memory Often real-time

Requirements: Limited resources: Smaller footprint (requires less code-bloat) Real-time support (available in Real-Time CORBA specification)

Non-Functional Requirements Heterogeneity

Variety of embedded systems: Industrial machines, auto mobiles, medical equipment, cameras, household appliances ..

Middleware should include necessary abstractions for corporating with heterogeneous devices

Middleware should also support using available communication protocols of devices

Openness Middleware should have the capability to be extended and modified during its

lifetime. Implementation of new functionality, or changes of an existing functionality should be

possible Real time app - of updating or extending the middleware should not require halting its

operation while this is being done.

Scalability ability of the system to accommodate a higher load at some time in the future. No. of nodes in a NES can be several orders of magnitude higher than in traditional

distributed system. Ex: sensor network- dense deployment (20nodes/m3) Therefore, middleware should scale w.r.t. the no. of sensor nodes

Non-Functional Requirements – Contd. Failure Handling

In a NES, failures are common than distributed systems with permanent connections Dynamic topology: some nodes may fail, or die due to lack of power, node

leave/join Communication errors: communication may fail due to unreliable transmission

medium, increase/unpredictable delay, high packet loss The failure of inidividual nodes should not affect the overall task of the NES.

Performance Energy and memory limitations of NES:

Ex: For battery operated sensor networks, enerygy efficient mechanisms should be implemented in middleware

Real-time requirement: Ex: use of middleware to receive real-time temperature data in a sensor network

Functional Requirements – Mobile System

Event Notification the ability to deliver messages to one or more recipients. nomadic networks:

event notification is done by the core fixed infrastructure; mobile devices simply receive the events.

Ad-hoc network: Each node has an event notification component. publish/subscribe :information providers publish events and information consumers

subscribe to a event

Mobility and location awareness Ability of nodes move from location to location Middleware, should be able to recognize a new environment and adapt to it.

Service discovery the ability to identify new services and, possibly protocols.

Code Updater ability to dynamically change the protocol and the code of the running

applications or of the middleware itself in order to adapt to context.

Functional Requirements – Embedded System

Real-time systems embedded into larger machines and devices that

perform critical real-time operations.

Middleware should maintain and monitor time and deadlines to maintain these kind of guarantees.

Functional Requirements – Sensor System

Event Notification middleware has to provide mechanisms to notify sensors when

an event occurs within the environment Code Updater

replacing the code running on the sensor, ranging from a single application routine to the entire operating system.

Wake-up coordination sensors must sleep most of the time to preserve battery, but

sender/receiver should be up when transmission take place. appropriate wake-up schemes must be adopted

Clustering fundamental functionality needed in sensor networks (e.g.,

for data aggregation and for energy-efficient communication). Middleware should model the ability of aggregating nodes

based on geographic proximity or other criteria (e.g., battery level, sensor types)

Case Study: RUNES and its Application in a Disaster Management Scenario

RUNES Motivation:

A Road Tunnel equipped with networked sensors

and actuators Cars/Trucks Going Through

Vehicles/People have portable devices

Crash! Fire! Chemical spillage! Road Tunnel Closes

Emergency Team Goes In Equipped with life-saving PDAs,

body sensors How To Make Everything Work

Together? Provide information to firefighter and

command/control

RUNES Problem Heterogeneity

Tiny devices to PCs Variety of power sources, OSs, languages Wired & wireless networks Higher level interaction paradigms like messaging, RPC, &

publish subscribe

Resource scarcity Power, CPU, Memory

Dynamism Loss of network connectivity, reconfiguring the network topology, loading new functionality in to devices & off loading functionality

RUNES Solution Traditional solutions are ill matched

Such as CORBA, Jini, .NET etc Lack of support of heterogeneity, resource scarcity & dynamism

RUNES overview Based on two level architecture

The foundation layer: light weight language independent component based programming model.

Layer of software components: offers middleware functionality

Application/Middleware Components

Middleware Kernel API

Platform-specificKernel Implementation

Platform-specificKernel Implementation

Platform-specificKernel Implementation

Contiki FreeRTOS

Gateway device

Linux

Gateway device

Component-based Middleware

Hardware and RF

Sensor device

EnvironmentEnvironment

Runes Middleware

Component-Based System Aiming To: Tackle Heterogeneity

Hardware Platforms OS Programming Languages

Offer Reconfigurability Software Network

Allows Networking of Heterogeneous nodes

Runes Component Model Component model elements

components component type Interfaces receptacles connectors connector factories attributes capsules

API associated with the model similar to OMG’s IDL

RUNES Relationships Between Component Model Elements

RUNES Elements component:

basic run time units, instantiated at run time from component types, use instantiate(), destroy()

component types: can themselves be loaded and unloaded. Provides basics for dynamic

nature of programming model. interface:

components offer functionality through one or more interfaces defined in programming language independent manner.

receptacles: express dependencies among components

connector: model to connect receptacle and interface.

connector factory: a component that creates connectors.

attributes: are key/value pair can be used to express meta-data.

capsule: all the entities reside in a capsule.

RUNES Kernel Implementation

Java/JVM C/Unix C/Contiki OS

Component & Component Types

Java classes, load() implemented as java class loader,

Component types are shared objects, load() implemented using dlopen(),

Similar to C

Interfaces, Receptacle & connectors

Interfaces implemented as Java interfaces, receptacles implemented as objects

interfaces & receptacles implemented as structs.

Similar to C

Memory Footprint kernel Code

14.65KB 16KB 780 bytes

Using Components: An Example

A component based calculatorA component based calculator

Java Kernel : Interface for a generic multiplier componentJava Kernel : Interface for a generic multiplier component

Java Kernel : Implementation of a simple multiplier componentJava Kernel : Implementation of a simple multiplier component

Java Kernel : Installing and connecting components for the calculator application

Java Kernel : Installing and connecting components for the calculator application

Java Kernel : Replacing the adder component in the calculator applicationJava Kernel : Replacing the adder component in the calculator application

Fire in a road tunnel: Application Design

When fire fighters arrives First check PS

component within the range.

Deploy PS component on sensors

Instructs sensors to send their reading PS component as well.

Applying Patterns to build middleware for NESs

Today, patterns are used in several domains (distributed applications, security, software requirements, architecture…)

It is possible to design and build a lightweight middleware for embedded systems with well known patterns such as Composite, Proxy, Visitor, Observer, Publish/Subscribe, Leasing, Evictor or Configurator

The selected patterns to be implemented should allow keeping the memory footprint reduced

As a result of using patterns , the middleware is modular, flexible, extensible, and lightweight (< 128 kb) according to targeted embedded systems requirements.

NES Middleware Use cases

Use Cases and Functional RequirementsUse Cases and Functional Requirements

Use Cases and Non-Functional RequirementsUse Cases and Non-Functional Requirements

Case Study JavaCard

credit card-sized plastic card with an integrated micro controller chip inside.

can both to store information and run Java programs within the JavaCard Runtime Environment (JCRE)

Thereby, it is a perfect specimen of an embedded system

When it is combined with an additional network-based device: called Card Acceptance Device (CAD), it can turn then into a node like others within the network.

Although it is severely constrained by memory limitations, this does not prevent us to upload cardlets inside it and invoke them as services from the web.

Most of JavaCards are embedded within iButton™ or TINI cards. In addition, there are some students possessing their own JavaCards.

It is possible using a middleware to group all these JavaCards to build new collaborative applications to provide useful services for both the students and the teachers Ex : authentication, courses planning, exams results, labs solutions, etc.)

Patterns to Build the Middleware

Architectural patterns govern the whole middleware design deal with the organization of the system’s elements into

subsystems and components also specify the responsibilities of each element and the

rules defining their relationship Patterns:

1. Layers Pattern 2. Microkernel Pattern

Layers Pattern

helps to structure systems into groups of subtasks

There are three ways to implement this pattern. Closed layered, one layer can only invoke its own services or those provided by the next

layer down. Open layered, one layer can invoke its own services or those provided by any layer below

it. Layering through Inheritance, lower layers are implemented as base classes from which

higher layers inherit.

We can apply this pattern to decompose the middleware architecture onto two layers: lowest layer is dedicated to the core functionalities of the middleware higher is concerned with user application.

Doing so, we isolated the core services such as resource management from the application’s service

Composite Pattern

Used for Topology Management

recursively create with composite and leaves complex or hierarchical structures like trees

provides a unique interface to users, So, the user can address in the same way leaves and containers

For middleware, we can apply Composite to organize elements hierarchically.

Netmaster is hosting the IButton JavaCard containing several cardlets. The TINI card , in which have a plugged sensor, is added as child to the Netmaster.

Typical composition of NESTypical composition of NES

NES CompositionNES Composition

Observer Pattern Used for event notification

implements a one-to-many dependency between the subject and the observers.

Ex: log any modification of a JavaCard in a database. the database is registered as an observer with the Netmaster and the

TINI card. Every time their state is updated, a notification is sent to the database

Strategy Pattern Used for network communication

Strategy let us to define a family of algorithms, encapsulate each one and make them interchangeable.

It allows the algorithm to be unaware about the client using it.

In NES, there are several protocols to connect peers: Ethernet, Wifi, Bluetooth, IrDA, and Serial…

Thereby, we can apply Strategy in order to let applications to use one protocol or another according to the device network interfaces

Putting it all together….

Memory Footprint

The final size of the middleware compressed jar file is about 68 kilobytes:

The middleware jar file’s size is about 24 kilobytes.

The configuration file is 1 kilobyte.

Brazil-TINI Server library is 43 kilobytes

Future Work

Dynamic adaptation mechanisms of middleware

The requirement for heterogeneity need to be addressed by the middleware

Requirement of feasibility has not been adequately addressed by existing middleware systems.

Conclusion Designing middleware for NESs is challenging Traditional middleware systems have been designed

targeting devices with almost no resource limitations Research has shown that there is no middleware

readily available for very heterogeneous scenarios in NESs In this literature review we considered three types of

systems and review the middleware developed for these different systems. Mobile Systems, Embedded systems, Sensor Systems

Functional and Non Functional Requirements Design Patterns in NES Middleware

References Networked Embedded Systems, Richard Zurawski, 2009

Applying Patterns to build a lightweight middleware for embedded systems, D. Bellebia, J-M Doulin Proceedings of the 2006 conference on Pattern languages of programs, 2006

The RUNES Middleware for Networked Embedded Systems and its Application in a Disaster Management Scenario Paola Costa et al., Proceedings of the Fifth IEEE International Conference on Pervasive Computing and Communications , 2007

Design patterns – Elements of Reusable Object-Oriented Software, E. Gamma, R. Helm, R. Johnson, J. Vlisside Addison-Wesley Professional, 1995

Any Questions?