thesis presentation: middleware for ubicomp - a model driven development approach
DESCRIPTION
With computers that will be interwoven into almost every industrial product like its nervous system (Steinbuch, 1966) we are already approaching what Weiser (1991) called Ubiquitous Computing, in terms of quantity, degree of embedding of computing systems in our life and work environment. This thesis investigates model driven software development (MDSD) approach as a tool for contextual adaption of ubiquitous systems. Ubiquitous Systems (i.e. the embedded devices) are subject to changes that affect the execution of software. The systems are very heterogeneous and and the designer has to take a diverse set of plattforms and ressource constrained hardware into consideration. By implementing a model driven development techniques for core problems of ubiquitous computing, namely distributed execution and heterogeneous communication in ubiquitous systems the work demonstrates that Model Driven Software Development of Ubiquitous Systems maybe used to solve the inherent contradiction between top-down and bottom-up development of networked embedded systems.TRANSCRIPT
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