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

754
-1

Published on

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.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
754
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

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

  1. 1. Technology for Pervasive ComputingMiddleware for Ubiquitous Systems: a model driven development approachTill 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. 2Overview 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. 3. Pushing computation 3 to the itemClose gapbetween virtual world and realityScale with thewith the item Prof. Dr.-Ing. Michael Beigl
  4. 4. Short History of Smart Items at TecO: 4Relocation 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. 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. 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. 7HypothesisModel Driven Software Development of UbiquitousSystems solves the inherent contradiction betweentop-down and bottom-up developmentby deduction we then expect tosee 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. 8Methodology apply model driven software development paradigmto complex realistic problems from the UbiComp domain and see if we canobserve the thesesThe 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 apromiscuous variety of consequences to the effect that if we perform certain acts, we shall findourselves confronted with certain experiences. We then proceed to try these experiments, and ifthe predictions of the theory are verified, we have a proportionate confidence that the experimentsthat remain to be tried will confirm the theory.“– Peirce: Collected Papers (CP 8.209)
  9. 9. #1: Implicit Middleware 9 BytecodeDistributed execution of services with changing execution context Prof. Dr.-Ing. Michael Beigl
  10. 10. 10Problem: Relocation of Service to SI Services Business Logic Backend Service Relocated Service MapperRepository 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. 11Solution: 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. 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. 13The MDSD approachDescribes mapping from models to platform: Input1. Describe domain using formal models / domain specific languages2. Build a reference product3. Develop generic meta-model based Optimization transformations4. 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. 14. 15Idea: 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. 15. 16 A Domain Homomorphism RelocatedService Distributed SI ServiceByte Code Transformation t φ ‘-1 φ φMathematicalProgramming Optimization o Assignment Optimal Problem Assignment Map Problem to domain/goal driven, conceptual representation
  16. 16. 17Optimization TransformFind Mapping Function: classes platforms of application of system state via indicator functionObjective Function:Constraints: Map all classes Fix some classes Obey available ROM
  17. 17. Mathematical Programming (ZIMPL) 18 as ImplementationObjective 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. 18. 19State dependent (re-)deployment EnvNode LocalGatewayLocalGateway before after TemperatureSensor AlarmSystemTempSensor_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 AccelerationSensorAccellerationSensor_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. 19. LocalGateway 21Lazy 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. 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. 21. 23#2: Model Driven Gateways
  22. 22. Ubiquitous communication 24platforms 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. 23. 25 Sensor Web Services ABB Aletheia mobile Client C WebService Service Proxy S GW GW Sensor GW Measurement Service SThe question will not be how to write a single gateway buthow to write all the gateways needed in the future…
  24. 24. 26Model based Transformation Gateway WS/WSN TransportA WS Comm. TransportA TransformationXA TransformationGW_AB <sample> ….</sample> PlatformX TransportB 111|101001011|1011How to write transformations• Manual Proxies• Declarative Mapping • uMiddle TransportB • CoBIS UPnP GW TransformationXBBetter: Implicit Mapping! PlatformY
  25. 25. 27Domain ArchitectureModels:  High Level Message Model ABB  (XML Schema, UML/MOF, …) Aletheia mobileTransformations:  Automata Representation  Aspect-oriented Platform and Encoding supportProduct:  m:n Gateways  Platform De/Encoders  Query InterfacesPlattforms:  Various SensorNodes (, RFID)  Embedded Gateways (Linux)  Microsoft .NET / WCF4
  26. 26. 28Model Based Transformation Domain specificAbstract, Executable Platform Specific
  27. 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. 28. 30 DPWS GatewayParticle/plain C/AwareConWCF 4.0/C#/IP AVR Fritzbox 7170,AR7@150 MHz, 8MB
  29. 29. 31Conclusion
  30. 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. 31. Also tried to scope and develop in 33 some real vertical domains… landmarkeServIoT UbiML…, but there were not conclusive results.
  32. 32. 34A qualified HypothesisTheses: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. integrativenessQualified Hypothesis:Model Driven Software Development of UbiquitousSystems solves the inherent contradiction betweentop-down and bottom-up developmentfor Middleware for Ubiquitous Systems
  33. 33. 35 Questions?riedel@teco.eduwww.teco.edu/~riedel

×