Model-driven Development of Self-organizing Control Applications - - PowerPoint PPT Presentation

model driven development of self organizing control
SMART_READER_LITE
LIVE PREVIEW

Model-driven Development of Self-organizing Control Applications - - PowerPoint PPT Presentation

Model-driven Development of Self-organizing Control Applications (MODOC) Prof. Dr.-Ing. Torben Weis Dr. Arno Wacker Dipl.-Inform. Sebastian Holzapfel Dipl.-Inform. Christopher Boelmann Universitt Duisburg-Essen Prof. Dr. Hans-Ulrich Hei


slide-1
SLIDE 1

Model-driven Development of Self-organizing Control Applications (MODOC)

  • Prof. Dr.-Ing. Torben Weis
  • Dr. Arno Wacker

Dipl.-Inform. Sebastian Holzapfel Dipl.-Inform. Christopher Boelmann Universität Duisburg-Essen

  • Prof. Dr. Hans-Ulrich Heiß

Dr.-Ing. Jan Richling Dipl.-Ing. Arnd Schröter Technische Universität Berlin

  • Prof. Dr.-Ing. Gero Mühl

Dipl.-Inform. Helge Parzyjegla M.Sc. Enrico Seib Universität Rostock

slide-2
SLIDE 2

Self-* in Embedded Systems

> „Pervasive Computing at Large“

> Tiny computers in day-to-day devices

> Clothing, > Kitchen devices, > Buildings, …

> Self-Organization

> Manual administration is impossible > Tiny devices are mobile and not very reliable

> Self-Stabilization

> External sources can induce transient errors in the hardware

> Radio noise, solar radiation, voltage fluctuation, …

> Cost pressure on hardware manufacturing makes tiny computing devices less reliable, too

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 2

slide-3
SLIDE 3

7 October 2010 DFG 1183 ORGANIC COMPUTING 3

Software Development Methodology for OC

Code Stack Heap Watchdog

Self-stabilizing Machine Application model Self-stabilizing and safe implementations Self-X compiler Back-annotation

> Self-stabilizing algorithms > Self-stabilizing Turing Machine > Monitoring interfaces > Reflection

slide-4
SLIDE 4

Overview

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 4

> Self-Stabilizing Controller

> Embedded systems > MSP 430 controller

> Self-X Composition

> Composition challenge > Example and evaluation

> Composite Events

> Distributed detection > Self-organizing detector placement

> Conclusions

slide-5
SLIDE 5

Towards a Self-stabilizing Controller

> Self-stabilizing automaton

> Adaptation of a 3-tape Turing Machine with I/O capabilities > Addition of an energy concept to force the decay of old data > This has shown theoretical feasibility

> Self-stabilizing virtual machine

> Stack machine approach, similar to Java or .NET > Self-stabilizing data structures > Assurance: After a transient fault, code is executed correctly again after a bounded time > Approach: A watchdog resets the machine if the main loop is not reached in time

> Self-stabilization on the MSP 430 controller

> Realization of above assurance on real hardware

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 5

slide-6
SLIDE 6

Application Anatomy

> Anatomy of a networked sensor/actuator application void main() { while(true) { ev = wait_for_event(); process_event(ev); send_output(); reset_watchdog(); } } > For self-stabilization, the software has to return to the main loop in bounded time in any case after a transient fault > Some faults can invalidate this assumption …

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 6

slide-7
SLIDE 7

MSP 430 Controller

> Frequently used for embedded systems and sensor networks > Possible temporary faults

> Bit errors in RAM (tackled by

  • ur self-stabilizing virtual machine)

> Bit errors in CPU registers > Faulty execution of CPU instructions

> Execution of unintended CPU instructions

> PC register points to the data field of a CPU instruction > This may lead to an unintended infinite loop > However, the watchdog timer can rescue the system

> Worst case scenario

> Unintended infinite loop resets the watchdog in each iteration > Self-stabilization would no longer be possible

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 7

slide-8
SLIDE 8

Unintended Infinite Loops

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 8

> Unintended loop is entered due to corrupted PC register > This loop is only critical if it continuously resets the watchdog

slide-9
SLIDE 9

Unintended Watchdog Reset

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 9

> Correct execution: Opcodes at 0x4100, 0x4104, 0x410a > Unintended execution: Opcode at 0x4102 (watchdog reset) followed by an unintended JMP at 0x4108

slide-10
SLIDE 10

Solutions

> Unintended loop detection

> Find all possible unintended loops > Ensure that the CPU returns to correct instructions eventually by inserting NOPs > An inserted NOP ensures that an unintended JMP targets the NOP instead of the data field of an operation

> Optimized unintended loop detection

> Cure only loops which reset the watchdog > Limits the number of inserted NOPs

> Watchdog protection

> Prevent unintended code from resetting the watchdog > Elegant solution, but not possible for all hardware architectures > Possible for the MSP 430 (again by inserting NOPs)

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 10

slide-11
SLIDE 11

Breaking Unintended Infinite Loops

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 11

slide-12
SLIDE 12

Prevention of Unintended Watchdog Reset

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 12

slide-13
SLIDE 13

Self-X Algorithms

> Switches between different routing schemes for each link (flooding vs. filtering) > Connects sub-topologies with similar interests

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 13

> Keeps the overlay connected when a broker crashes

Pub Sub

Self-Optimizing Routing (SOR) Self-Optimizing Topology (SOT) Fault Tolerant Topology (FTT)

crash shortcut reconfiguration

slide-14
SLIDE 14

Composition of Self-X Algorithms

> Superimposed QoS feedback loops > Dependency analysis shows conflict in overlay reconfiguration > Conflict Resolution

> Transaction scheme for SOT to deal with broker crashes (FTT) > Support for connecting arbitrary topologies with SOR > Mutual blocking of SOT and SOR

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 14

slide-15
SLIDE 15

Composition of Self-X Algorithms

> Preserves properties of composed algorithms > Achieves higher performance than each single algorithm

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 15 SOT SOR

reconfiguration

  • verhead
slide-16
SLIDE 16

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 16

Event Patterns

Event patterns

> Application roles communicate by exchanging notifications via publish/subscribe > Actions are often triggered only if several conditions are met  event patterns

Application level detection

  • f event patterns

> Candidate notifications must be forwarded to application > Notification traffic concentrates at event sinks  bottlenecks > Majority of notifications are forwarded unnecessarily Room 2

Σ Σ Σ

Room 1

Hidden application constraints on events A and B

A B A B

Addition of noti- fication streams

slide-17
SLIDE 17

Composite Event Detection

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 17

> Event composition at middleware level

> Replaces/complements pattern recognition at application level to enable efficient distributed pattern detection > Patterns are specified by composition algebra (definition, visibility, reusability)

> Four basic detector operations based on composition algebra used for optimization

Decomposition

> Hierarchical decomposition

  • f a detector into

constituent subpatterns

Recombination

> Dissolve no longer useful detectors and recombine them with others

Migration

> Early filtering by seamless migration of detectors along the event stream

Replication

> Divide event space into disjoint domains

slide-18
SLIDE 18

Force Model

> Heuristic based on relaxing forces due to dynamically changing environment

> Gradually optimizes placement using local knowledge and basic detector operations > Balances responsiveness and stability

> Model system as compensating forces

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 18

Selectivity

> Indicates potentially saved forwarding costs > Pull detectors towards sources or sinks > Migration or decomposition with replication depends on the number of pulling forces

selectivity selectivity selectivity costs costs costs

Costs

> Storage utilization, migration costs > Pull related detectors together  recombination

Friction

> Counter oscillations but keep system responsive

slide-19
SLIDE 19

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 19

Simulation

> Discrete event simulation of detector placement strategy > Network consumption  width of lines > Computational load  area of red dots > Shows decomposition, migration and recombination

slide-20
SLIDE 20

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 20

Conclusions

> MODOC allows for engineering

  • f distributed control-applications

> Comprehensive tool chain supporting modeling, code generation, deployment and debugging of OC applications > MODOC provides self-organization and self-stabilization > Self-stabilizing controller and virtual machine > Self-organizing and self-optimizing publish/subscribe infrastructure

slide-21
SLIDE 21

16.09.2011 DFG SPP 1183 ORGANIC COMPUTING 21

Discussion

Thanks for your kind attention.

  • Prof. Dr. Gero Mühl

Architecture of Application Systems University of Rostock

gero.muehl@uni-rostock.de http://wwwava.informatik.uni-rostock.de