Thesis presentation: Middleware for Ubicomp - A Model Driven Development Approach

KIT – University of the State of Baden-Wuerttemberg and

National Research Center of the Helmholtz Association www.kit.edu

Technology for Pervasive Computing

Middleware for Ubiquitous Systems:

a model driven development approach

Till Riedel, TecO, Pervasive Computing Systems

In a few decades there won’t be many industrial products that don’t have computers woven into them, just like a nervous system is woven into organisms”´ Karl Steinbuch, 1966

2

Overview

Motivation

Approach / Thesis

Domain Architecture #1: Implicit Middleware Optimized Distribution over heterogeneous, changing system

environments

Domain Architecture #2: Generative GWs Model Driven Sensor Network Gateway Generation

3

Prof. Dr.-Ing. Michael Beigl

Pushing computation to the item

Close gap between virtual world and reality

Scale with the with the item

4 Short History of Smart Items at TecO:

Relocation of Computation

Collaborative Business Items (2006)

In-situ detection of hazardous situations of chemical goods

App: safety provision for worker, environment

DigiClip (2004)

Couple paper-based documents to computer-based document management systems

App: Active physical (paper-based) documents

eSeal (2004)

Transform electronic contracts onto physical items,

App: Trustworthy, continuous self-supervision of goods during transport, cold supply chain

5

Ubiquitous Computing Systems

Technological Development Challenges

Resource-constrained Devices

Heterogeneous Environments

Changing Context

Cross-Domain Embedding

The industrial analogy: one engine (1900) for whole factory to many small specialized electrical motors (today) [Weiser, 1991]

(Bardram/Friday in Ubiquitous Computing Fundamentals, 2010) (Banavar, Bernstein, Software infrastructure and design challenges for ubiquitous computing applications, 2002) (Weiser, The computer of the 21st century, 1991)

6

The Software Engineering Problem

Bottom up

Bandram, Friday, 2010: Experimental

“As one experiment may enable a hypothesis to be refined leading to further experiments cyclically, so a system design may lead to another and be iteratively refined.”

Ubicomp systems development historically based in the 90s SE: participatory design, rapid prototyping

Problem: low-reuse of code&knowledge

Boehm, 2006: Hegelian Dialectics of Software Engineering’s Past

Top Down (Antithesis)

Milner, 2006: Tower of Models

“What concepts and properties are relevant to describing a ubiquitous system?“

“Any system must be modelled at higher and lower levels of abstraction.”

Rigorous approach to better understanding of the problem domain

Problem: reality often too messy,

Synthesis: Model driven software development (MDSD) Very pragmatic take on formalism. Rapid development using conceptual models. Tool

(Bardram,Friday, Ubiquitous Computing Systems, in Ubiquitous Computing Fundamentals, 2010) (Milner, Ubiquitous computing: shall we understand it?, 2006) (Boehm, A view of 20th and 21st century software engineering,2006) (Voelter, Stahl, Czarnecki, Model-Driven Software Development: Technology, Engineering, Management, 2006)

7

Hypothesis

Model Driven Software Development of Ubiquitous

Systems solves the inherent contradiction between

top-down and bottom-up development

by deduction we then expect to

see the following observable theses:

MDSD in Ubicomp should lead to better

a. flexibility (heterogeneity and re-use)

b. code size, performance (resource constraints)

c. complexity

d. analyzability (tower of models)

e. integrativeness

(effects of successful MDSD according to Stahl 2010)

8

Methodology

apply model driven software development paradigm

to complex realistic problems from the UbiComp domain and see if we can observe the theses

The two common problems:

Distributed execution of services with changing execution context

Communication in heterogeneous low-power wireless networks

„Abduction having suggested a theory, we employ deduction to deduce from that ideal theory a promiscuous variety of consequences to the effect that if we perform certain acts, we shall find ourselves confronted with certain experiences. We then proceed to try these experiments, and if the predictions of the theory are verified, we have a proportionate confidence that the experiments that remain to be tried will confirm the theory.“

– Peirce: Collected Papers (CP 8.209)

9

Bytecode

Prof. Dr.-Ing. Michael Beigl

#1: Implicit Middleware Distributed execution of services with changing execution context

10

Problem: Relocation of Service to SI Services

Service

Relocated

Service

Smart Items (SI)

Business Logic Backend

Problem: no optimal modularisation strategy for smart item services Fine granular modularization leads to high middleware overhead Coarse modularization leads to suboptimal mapping

Required knowledge not available at development time

Repository Mapper

11

Solution: Automatic partitioning

Optimization

System State

Cost Model Middleware

Generation

Profile

Distributed

SI Service

PlatformCode

Relocated

Service

Solution: Use implicit middleware instead of explicit modularization. Find optimal distribution and insert Middleware where needed.

12

The Domain Architecture

Input Models/Artefacts:

Service

System state

Cost

Profile

Transformations:

Optimization

Middleware Generation

Product:

platform-specific, distribution-optimized binaries

Platform:

Embedded JavaVM

Platform Gateway

WebAS Server

Smart Item Service

Web Service

Service Mapper

Web Service

System State

Web Service

Device Manager

Web Service

Implicit Middleware

Web Service

Service Repository

code, profile state

cost

Given: CoBIs, SAP (SI)² Integration

Product: Distributed SI Services

Platform: CatPart, ParticleVM

13

The MDSD approach

Describes mapping from models to platform:

1. Describe domain using formal models / domain specific languages

2. Build a reference product

3. Develop generic meta-model based transformations

4. Automate the process using domain architecture

Not quite the typical MDSD: DSL partially create as binary artifacts by other

systems use reverse engineering some AI involved (search and optimization) but implemented as EMF Workflow

Optimization

Middleware Generation

Input

Product

15

DrumConditionService

DrumNode DrumNode

LocalGateway EnvNode

Idea: Class based optimal assignment

TemperatureSensor

TemperatureSensingTask

397

TempSensor_native

0,4

AlarmSystem

Alarm

1

(default package)

ConditionServiceMain

AccelerationSensor

AccellerationSensor_native

FrequencyController

Fft FrequencyControler

DrumNode 9 20 100

EnvNode 7 100

Local GW 100

3

0.03 27,79 0,01

3,71 24,08 2,8

0,27

3 3 3

Simple Cost Model

co

m

16

A Domain Homomorphism

Map Problem to domain/goal driven, conceptual representation

RelocatedService Distributed SI Service

Transformation t

Assignment Problem

Optimization o

φ φ

φ ‘-1

OptimalAssignment

Byte Code

Mathematical

Programming

17

Optimization Transform

Find Mapping Function:

Objective Function:

Constraints:

classes of application

platforms of system state

Map all classes Fix some classes Obey available ROM

via indicator function

18 Mathematical Programming (ZIMPL) as Implementation

subto map_all_classes: forall <c> in CLASSES: sum <m> in MACHINES : mu[m,c] > 0;

minimize cost: sum <p,c> in PLATFORMS*CLASSES: c_exec_c[c] * c_exec_p[p] * mu[p,c] + sum <p0,p1,c0,c1> in PLATFORMS*CLASSES * PLATFORM*CLASSES: c_link_c[c0,c1] * c_link_p[p0,p1] * mu_times_mu[p0,c0,p1,c1]; #mu_times_mu(c0,p0,c1,p1) equals mu(c0,p0)*mu(c1,p1) subto if_mu_and_mu_the_mu2: forall <p0,p1,c0,c1> in MAP2 do mu_times_mu[m0,m1,c0,c1] >= mu[m0,c0]+mu[p1,c1,p0,c1]-1;

Constraints:

Objective Function:

19

LocalGateway

DrumNode DrumNode

LocalGateway EnvNode

Slow Network and Nodes

State dependent (re-)deployment

TemperatureSensor

TemperatureSensingTask

397

TempSensor_native

0,4

AlarmSystem

Alarm

1

(default package)

ConditionServiceMain

AccelerationSensor

AccellerationSensor_native

FrequencyController

Fft FrequencyControler

7 20 100

9 100

100

3

0.03 27,79 0,01

3,71 24,08 2,8

0,27

0,19 0,02

0,01

3 3 3

Faster network

before

Slow

Fast 330 + 420

= 231

after

330 + 420

= 231

330 + 420

= 231

7 20 10

9 10

100

330 + 420

= 231

21 Lazy Middleware Generation

EMF-Adapter for Java Byte-code

Fully automatic, platform-dependent stub/dispatcher generation

Meta-model-based QVT-R and ETL byte code-transformation

1. Remove instructions, fields (for stub

2. Add remote pointer

3. Transform signature to pushX/popX Sequence

Minimal static platform layer, efficient generated byte-code

DrumNode

AccelerationSensor

AccellerationSensor_native FrequencyControler

LocalGateway

FrequencyControler

Fft

Disp

atchH

elp

er

22

Runtime Performance

better than handwritten code*

lazy middleware insertion

optimal distribution**

low run-time overhead

* if execution context changes, **exact solution regarding model

23

#2: Model Driven Gateways

24 Ubiquitous communication platforms

32 bit ARM7 256KB RAM/2MB Flash/80 MHz, 802.15.4, Java

8bit PIC18F6720 MCU 4KB RAM /128KB Flash,5MIPS, Awarecon, C/Java

8bit rfPIC 64 Byte RAM/1.4 KB Flash 1MIPS, C/Config only

No MCU, 1bit-4kbyte EEPROM

32 bit OpenRISC NIC,

96K RAM/192K Flash/16 MHz, 6lowPAN,Contiki

32 bit AR7 MIPSel,2MB RAM/8MB Flash/212MHz, IP, DSL/WiFi/Ethernet, Linux

32 bit ARM9,

2M RAM/512M Flash/528 MHz, GSM/UMTS/WiFi/BT, Android

25

Sensor Web Services

GW

GW

GW

Client C Service Proxy S' WebService

The question will not be how to write a single gateway but how to write all the gateways needed in the future…

Aletheia

mobile

ABB

Sensor

Measurement

Service S

26

Gateway WS/WSN

Model based Transformation

PlatformX

WS Comm.

TransformationGW_AB

TransportB

How to write transformations • Manual Proxies • Declarative Mapping

• uMiddle • CoBIS UPnP GW

Better: Implicit Mapping!

TransportA

TransformationXA

TransformationXB

PlatformY

TransportB

TransportA

<sample> ….</sample>

111|101001011|1011

27

Domain Architecture

Models: High Level Message Model

(XML Schema, UML/MOF, …)

Transformations: Automata Representation

Aspect-oriented Platform and Encoding support

Product: m:n Gateways

Platform De/Encoders

Query Interfaces

Plattforms: Various SensorNodes (, RFID)

Embedded Gateways (Linux)

Microsoft .NET / WCF4

Aletheia

mobile

ABB

28

Model Based Transformation

Abstract, Executable

Platform Specific

Domain specific

29 Visibly Pushdown Automata & Aspect Oriented code generation

en

co

din

g

High code reuse factor

Efficient execution

MCU: min. RAM/Jumps

Encoding Aspects

Grammar Based Compression

Platform optimization: Align/Endian/Shift

Automated Encoding Translation

Platform Aspects (C, Java, Proto-threads, SAX, DOM,…)

Cross-Layer Network Integration

Physical Layer Query Support

1

<sample>

0

read(10bit)/10-20

30

DPWS Gateway

AVR Fritzbox 7170,AR7@150 MHz, 8MB

Particle/plain C/AwareCon

WCF 4.0/C#/IP

31

Conclusion

32

Conclusion

MDSD addresses core problem of UbiComp (middle-out development)

Formal models can really help to easily solve real life UbiComp SE problems

Tower of Models

DPWS GWs have successfully used in multiple projects (takes 1 person night to adapt to new platform ;) )

Thesis captures best practices/experiences from past practical projects

(>5 research projects, over 50 scientific publications)

Horizontal scoping (pervasive services, middleware) allowed efficient Model driven development for UbiComp

Discussion:

only partially practical/complete solutions in research projects

what about vertical scoping == ubicomp applications?

33 Also tried to scope and develop in some real vertical domains…

…, but there were not conclusive results.

ServIoT UbiML landmarke

34

A qualified Hypothesis Theses:

MDSD has led to better a. flexibility (heterogeneity and re-use)

b. code size, performance (resource constraints)

c. complexity

d. analyzability (tower of models)

e. integrativeness

Qualified Hypothesis:

Model Driven Software Development of Ubiquitous Systems solves the inherent contradiction between top-down and bottom-up development for Middleware for Ubiquitous Systems

35

Questions?

[email protected]

www.teco.edu/~riedel