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.

1. 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
KIT – University of the State of Baden-Wuerttemberg and
National Research Center of the Helmholtz Association www.kit.edu

2. 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. Pushing computation
3
to the item
Close gap
between virtual world and reality
Scale with the
with the item
Prof. Dr.-Ing. Michael Beigl

4. Short History of Smart Items at TecO: 4
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. 5
Ubiquitous Computing Systems
The industrial analogy: one engine (1900) for whole factory to many
small specialized electrical motors (today) [Weiser, 1991]
Technological Development Challenges
Resource-constrained Devices
Heterogeneous Environments
Changing Context
Cross-Domain Embedding
(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. 6
The Software Engineering Problem
Bottom up Top Down (Antithesis)
Bandram, Friday, 2010: Experimental Milner, 2006: Tower of Models
“As one experiment may enable a hypothesis to be refined “What concepts and properties are relevant to
leading to further experiments cyclically, so a system describing a ubiquitous system?“
design may lead to another and be iteratively refined.”
“Any system must be modelled at higher and lower
Ubicomp systems development levels of abstraction.”
historically based in the 90s SE: Rigorous approach to better
participatory design, rapid prototyping understanding of the problem domain
Problem: low-reuse of code&knowledge Problem: reality often too messy,
Boehm, 2006: Hegelian Dialectics of Software Engineering’s Past
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. 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. 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. #1: Implicit Middleware
9
Bytecode
Distributed execution of services with changing execution context
Prof. Dr.-Ing. Michael Beigl

10. 10
Problem: Relocation of Service to SI Services
Business Logic Backend
Service
Relocated
Service
Mapper
Repository
Smart Items (SI)
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

11. 11
Solution: Automatic partitioning
System Cost Platform
State Model Middleware Code
Optimization
Generation
Profile
Relocated
Service
Distributed
SI Service
Solution: Use implicit middleware instead of explicit modularization.
Find optimal distribution and insert Middleware where needed.

12. 12
The Domain Architecture Web Service
Service Mapper
Web Service
 Input Models/Artefacts: Service Repository
Web Service
System State
 Service
 System state code, profile state
 Cost Web Service Web Service
cost Implicit Middleware Device Manager
 Profile
Given: CoBIs, SAP (SI)² Integration
 Transformations:
 Optimization WebAS Platform
 Middleware Generation Server Gateway
Smart Item Service
 Product:
 platform-specific, Product: Distributed SI Services
distribution-optimized binaries
 Platform:
 Embedded JavaVM
Platform: CatPart, ParticleVM

13. 13
The MDSD approach
Describes mapping from models to platform:
Input
1. Describe domain using formal models /
domain specific languages
2. Build a reference product
3. Develop generic meta-model based Optimization
transformations
4. Automate the process using domain
architecture
Middleware Generation
 Not quite the typical MDSD:
 DSL partially create as binary artifacts by other
systems
 use reverse engineering Product
 some AI involved (search and optimization)
 but implemented as EMF Workflow

14. 15
Idea: Class based optimal assignment
EnvNode
DrumConditionService LocalGateway
TemperatureSensor AlarmSystem
TempSensor_native TemperatureSensingTask Alarm
0,4 397 1
0.03 27,79 0,01
DrumNode DrumNode (default package)
ConditionServiceMain
3
0,27
AccelerationSensor FrequencyController
AccellerationSensor_native FrequencyControler Fft
3 3 3
3,71 24,08 2,8
Simple Cost Model
com
DrumNode 9 20 100
EnvNode 7 100
Local GW 100

15. 16
A Domain Homomorphism
RelocatedService Distributed SI Service
Byte Code Transformation t φ ‘-1
φ φ
Mathematical
Programming Optimization o
Assignment Optimal
Problem Assignment
Map Problem to domain/goal driven, conceptual representation

16. 17
Optimization Transform
Find Mapping Function:
classes platforms
of application of system state via indicator function
Objective Function:
Constraints:
Map all classes Fix some classes Obey available ROM

17. Mathematical Programming (ZIMPL) 18
as Implementation
Objective Function:
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:
subto map_all_classes: forall <c> in CLASSES:
sum <m> in MACHINES : mu[m,c] > 0;

18. 19
State dependent (re-)deployment
EnvNode LocalGatewayLocalGateway
before after
TemperatureSensor AlarmSystem
TempSensor_native TemperatureSensingTask Alarm
0,4 397 1
0.03 27,79 0,01
DrumNode DrumNode (default package)
Slow 330 330
ConditionServiceMain + 420 + 420
3
0,27 0,01 = 231 = 231
AccelerationSensor
AccellerationSensor_native
FrequencyController
FrequencyControler Fft Fast 330 330
3
3,71 24,08
3
0,19 2,8
3
0,02
+ 420 + 420
= 231 = 231
Slow Network and Nodes Faster network
7 20 100 7 20 10
9 100 9 10
100 100

19. LocalGateway 21
Lazy Middleware Generation
DispatchHelper
Fft
DrumNode
 EMF-Adapter for Java Byte-code
AccelerationSensor
AccellerationSensor_native FrequencyControler FrequencyControle
 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

20. 22
Runtime Performance
 better than handwritten code*
 lazy middleware insertion
 optimal distribution**
 low run-time overhead
* if execution context changes, **exact solution regarding model

21. 23
#2: Model Driven Gateways

22. Ubiquitous communication 24
platforms
32 bit ARM9,
2M RAM/512M Flash/528 MHz, GSM/UMTS/WiFi/BT, Android
32 bit AR7 MIPSel,2MB RAM/8MB
Flash/212MHz, IP, DSL/WiFi/Ethernet, Linux
32 bit ARM7
256KB RAM/2MB Flash/80 MHz, 802.15.4, Java
32 bit OpenRISC NIC,
96K RAM/192K Flash/16 MHz, 6lowPAN,Contiki
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

23. 25
Sensor Web Services
ABB
Aletheia
mobile
Client C WebService Service Proxy S'
GW
GW Sensor
GW Measurement
Service S
The question will not be how to write a single gateway but
how to write all the gateways needed in the future…

24. 26
Model based Transformation
Gateway WS/WSN
TransportA WS Comm. TransportA
TransformationXA TransformationGW_AB
<sample> ….</sample>
PlatformX TransportB
111|101001011|1011
How to write transformations
• Manual Proxies
• Declarative Mapping
• uMiddle TransportB
• CoBIS UPnP GW TransformationXB
Better: Implicit Mapping! PlatformY

25. 27
Domain Architecture
Models:
 High Level Message Model ABB
 (XML Schema, UML/MOF, …) Aletheia
mobile
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

26. 28
Model Based Transformation
Domain specific
Abstract, Executable
Platform Specific

27. Visibly Pushdown Automata 29
& Aspect Oriented code generation
read(10bit)/10-20
 High code reuse factor 0
1
 Efficient execution <sample>
 MCU: min. RAM/Jumps
 Encoding Aspects
 Grammar Based Compression
 Platform optimization:
Align/Endian/Shift
encoding
 Automated Encoding Translation
 Platform Aspects
 (C, Java, Proto-threads, SAX, DOM,…)
 Cross-Layer Network Integration
 Physical Layer Query Support

28. 30
DPWS Gateway
Particle/plain C/AwareCon
WCF 4.0/C#/IP
AVR Fritzbox 7170,AR7@150 MHz, 8MB

29. 31
Conclusion

30. 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?

31. Also tried to scope and develop in 33
some real vertical domains…
landmarke
ServIoT UbiML
…, but there were not conclusive results.

32. 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

33. 35
Questions?
riedel@teco.edu
www.teco.edu/~riedel