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?