Multi-Objective Optimized Software Architectures (MOOSA ... · Multi-Objective Optimization (MOO) of Configurations Fakultät Informatik Institut Software- und Multimediatechnik,

Fakultät Informatik Institut Software- und Multimediatechnik, Lehrstuhl Softwaretechnologie

Multi-Objective Optimized Software Architectures (MOOSA) for Life-by-Wire Prof. Dr. Uwe Aßmann Sebastian Götz Technische Universität Dresden ResUbic Lab http://www.resubic.org http://st.inf.tu-dresden.de July 3, 2012


•  FLY-BY-WIRE •  William G. Redmond - US Patent 3,679,156, 1972 •  http://www.google.com/patents?

hl=de&lr=&vid=USPAT3679156&id=GTswAAAAEBAJ&oi=fnd&dq=fly-by-wire&printsec=abstract#v=onepage&q=fly-by-wire&f=false

Prof

. U

. Aßm

ann,

TU

Dre

sden

2

Fly By Wire


1. The Near Future: Help-By-Wire


Rescue-By-Wire Pr

of.

U.

Aßm

ann,

TU

Dre

sden

4

46

agendaCPS

einen eventuellen Fehlalarm anzuzeigen. Zeigt ein Bewe-gungssensor beispielsweise einen Sturz an, muss nicht unbe-dingt etwas passiert sein und ein Notruf ausgelöst werden.

Reagiert der Patient nicht, löst das Mobilgerät einen Not-ruf aus und übermittelt seine aktuellen Daten sowie die Kranken akte an die Notrufzentrale. Auf Basis dieser In-formationen lässt sich dort eine fundierte Entscheidung treffen, wie am besten zu reagieren ist. Handelt es sich beispielsweise nicht um eine lebensbedrohliche Situation, kann etwa als erster Schritt auch ein Verwandter oder Nach-bar informiert werden, um nach dem Rechten zu sehen. Die über die Mobilgeräte des Patienten und von möglichen Ersthelfern ermittelten Ortsinformationen können genutzt werden, um zunächst einen geeigneten Helfer in der Nähe

auszuwählen und mittels einer Navigationslösung auf sei-nem Mobilgerät an den Ort des Geschehens zu lotsen.

Wird die Entscheidung getroffen, einen Krankenwagen zu entsenden, können die gesundheitsrelevanten Daten unmittelbar dorthin übermittelt und noch während der Fahrt ausgewertet werden. So kann sich das Team im Krankenwagen optimal auf den Einsatz vorbereiten und während der Fahrt anhand aktueller Sensorwerte den Pa-tientzustand abschätzen. Auch an das Krankenhaus selbst können die Daten bereits übermittelt werden, sodass, etwa für eine erforderliche Notoperation, alles vorbereitet werden kann.

GeschützteGesundheitsdaten

Smart HealthNotrufzentrale

Abbildung 2.7: Illustration der Koordinationsbeziehungen im beschriebenen Notfallszenario

[Acatech]


•  „In der Europäischen Union werden jährlich ueber 7.000 Fussgänger und 2.000 Fahrradfahrer bei Verkehrsunfällen getätet. Hunderttausende werden darüber hinaus bei Verkehrsunfällen verletzt.“

•  [M. Bischoff. Aktive Sicherheitssysteme fuer den Schutz von Fussgaengern im Strassenverkehr]

Prof

. U

. Aßm

ann,

TU

Dre

sden

5

The Oma Warner

Um 4.30 Uhr hatte sich Regina F. auf den Weg zur Arbeit gemacht. Von der Britzer Straße in Schöneweide zum Putzen nach Marienfelde. Sie schaffte es nicht mal bis zum S-Bahnhof. Viel zu schnell kam ein Kombi um die Ecke gefahren. So schnell, dass das Auto aus der Kurve flog und über den Bürgersteig raste. Durch den Aufprall wurde Regina F. auf die Straße geschleudert. Nur kurz hielt der Mann an, dann gab er Gas und raste davon.

http://www.bz-berlin.de/bezirk/treptow/raser-faehrt-oma-um-und-macht-sich-davon-article1373880.html


•  reach a safe state without power

Passive Fail-safe system (FS)

• Extensive testing

Quality assurance

• Normal mode • Safe

Verification

• Certification agencies • For product liability

Certification

Prof

. U

. Aßm

ann,

TU

Dre

sden

6

Requirements for Help-by-Wire Systems


2. The Mid-Term Future: Move-By-Wire


Prof

. U

. Aßm

ann,

TU

Dre

sden

8

Drive-By-Wire: The Google Car


Prof

. U

. Aßm

ann,

TU

Dre

sden

9

BMW Connected Drive Connect (CDC)

http://www.digitaltrends.com/cars/destination-home-how-fully-autonomous-driving-might-come-sooner-than-we-think/


• reach this safe state only with power

Active Fail-safe systems (AFS)

• may fail but continue to work

Fail-operational systems (FO)

• Extensive testing

Quality assurance

• Normal mode • Safe

Verification

• Certification agencies • For product liability

Certification

Prof

. U

. Aßm

ann,

TU

Dre

sden

10

Requirements for Move-by-Wire Systems

3. The Software for Life-by-Wire: Mul%-‐Objec%ve Op%miza%on So5ware Architectures (MOOSA)

Prof. Uwe Aßmann Sebastian Götz


Sensor Sensor

Actuator Actuator

10.04.2012

12

Basics of a Cyber-Physical System for Life-by-Wire

Environment

Computing Part Computing

Actuators

Sensors

Cyber Physical

Communication


3-Dimensional Self-Adaptivity: Delivered Quality x Context x Available Resources:

Collect

Analyze

Decide

Act

QoS Demands Objectives

Software Component 1



Impl Impl Impl

Internet

UMTS/LTE

W-LAN LAN

Slide 13 time energy

contexts

Fakultät Informatik Institut Software- und Multimediatechnik, Lehrstuhl Softwaretechnologie Li

ve-b

y-w

ire

syst

em (

Cyb

er-

phys

ical

sys

tem

) Reliability

Real-Time Simulation

World model

Dynamics model (movements)

Safety-criticality

Privacy

Fail safety

Security

Self-Adaptivity Efficiency requirements

Real-time

Energy consumption

Prof

. U

. Aßm

ann,

TU

Dre

sden

14

Requirements for Life-by-Wire


•  CPS must be reliably composable –  Functional Contracts –  Quality Contracts

•  Heterogeneous Rich Components (Damm et.al, 2005)

•  Contract Checking of Quality Properties, e.g.

•  Energy reserve for active fail-safety (AFS)

•  „The robot swarm can still run 25s, so the shutdown to safe state has start in 5s“

Reliability with Contract Checking Pr

of.

U.

Aßm

ann,

TU

Dre

sden

real-time

safety

dynamics

component

component

component energy

Quality Contract

Quality Contract

Quality Contract


CPS need self-adaptability •  Which implementations of the

contracts •  in which quality mode •  on which resources •  give the most efficient

configuration?

•  Configuration Optimization –  QoS adaptation –  Context adaptation –  Resource adaptation

Self-Adaptivity with Multi-Objective Optimization (MOO) of Software

Architectures

Multi-Objective Optimization of Software Architectures (MOOSA)


A Platform for Multi-Objective Optimized Software Architectures

Prof

. U

. Aßm

ann,

TU

Dre

sden

17

MOO Software Architecture with CCM

Contract Checking with Heterogeneous Rich

Components

Self-adaptive Workflow Systems (TUD, Richly)

Contract negotiation (TUD, Comqud, Zschaler, Härtig,

MUSIC, Madam)

Reliability Adaptivity


A Platform for Multi-Objective Optimized Software Architectures

10.04.2012

18

Functional Requirements

Non-functional Requirements

Realtime Energy Safety

Modelling

Test

Quality Contract Checking

Multi-Objective Optimizer

(multi-quality)


Multi-Quality Multi-Objective Configuration Optimization

04.07.12 19

Request/Load/

Resource Change

Configuration Optimization

(MOO)

Reconfi-guration

Quality Contract Checking

Modeling

Run Time

Design Time


System

C1 (3 GHz, 1 Core)

C2 (4 GB)

C3 (3 GHz, 1 Core)

C4 (4 GB)

Hierarchical Architecture with Variants Pr

of.

U.

Aßm

ann,

TU

Dre

sden


System

C1 (3 GHz, 1 Core)

C2 (4 GB)

C3 (3 GHz, 1 Core)

C4 (4 GB)

Dynamic Variant Reconfiguration Pr

of.

U.

Aßm

ann,

TU

Dre

sden

System

C1-1 (3 GHz, 1 Core)

C2-1 (3 GB)

C3-2 (4 GHz, 12Core)

C4-1 (4 GB)

System


C2-1 (3 GB)


C4-2 (5 GB)

System


C2-2 (1 GB)


C4-2 (5 GB)

System


C2-2 (2 GB)


C4-2 (5 GB)

MOO


Server1 : Server

frequency : 3GHz perform : 45 GFLOPS

Self-Adaptivity with Multi-Objective Optimization

04.07.12 22

Player

framerate: fps

VLC QT

Decoder

datarate: kb/s

Free Comm

DataProvider

bitrate: kb/s

File URL

CPU_S1 : CPU

free : 402 MB throughput : 3 GB/sx

RAM_S1 : RAM

Car1: Car

CPU_S2 : CPU

RAM_S2 : RAM

NET_S2 : NET


Server1 : Server


Optimal Configuration for One Request

04.07.12 23

Player

framerate: fps

VLC QT

Decoder

datarate: kb/s

Free Comm

DataProvider

bitrate: kb/s

File URL

Request

CPU_S1 : CPU


RAM_S1 : RAM

Car1: Car

CPU_S2 : CPU

RAM_S2 : RAM

NET_S2 : NET


Server1 : Server


Optimal Configuration for Another Request

04.07.12 24

Player

framerate: fps

VLC QT

Decoder

datarate: kb/s

Free Comm

DataProvider

bitrate: kb/s

File URL

Request

CPU_S1 : CPU


RAM_S1 : RAM

Car1: Car

CPU_S2 : CPU

RAM_S2 : RAM

NET_S2 : NET

4. The Cool Component Model

• Prof. Uwe Aßmann • Sebastian Götz


•  So5ware is described using a CCM Structural Model •  approx. SysML plus QCL contract language

•  SW Components have provided/required ports (e.g. methods of classes) •  Quality-‐Modes and Implementa%ons of SW Components are described using QCL contracts

Cool Component Model (CCM) for Multi-Objective Optimization


Approach: Quality Contract Language

1 contract VLC implements VideoPlayer.play {

2

3 mode highQuality {

4 requires component Decoder {

5 min dataRate: 50 KB/s

6 }

7

8 requires resource CPU { 9 max cpuLoad: 50 percent

10 min frequency: 2 GHz

11 }

12 requires resource Net {

13 min bandwidth: 10 MBit/s

14 }

15

16 provides min frameRate: 25 FPS

17 provides min imageWidth: 1024 Pixel

18 provides min imageHeight: 768 Pixel

19 }

20

21 mode lowQuality {

22 /* More requirements and provisions here ... */

23 }

24 }

Quality Modes

Software Dependencies

Resource Dependencies

Quality Provisions

Quality Modes

Contracts characterize implementations

04.07.12

Seb

astia

n G

ötz

- M

QuA

T

Slide 27


•  Hardware Structural Model •  Hardware Variant Model •  Hardware Behavior using Energy State Charts

-  Which ResourceTypes exist -  How they are connected -  Mul%plici%es -‐ Contracts

Specifying Hardware in CCM


-  Concrete resources are modeled and connected to structural model -  Behavior templates are assigned per resource -  Cost parameters are assigned with values or formulas

Hardware Variant Model


-  use cost parameters instead of concrete value -  reuse for resources of same kind -  can be executed using workload descrip%ons

Behavioral Modeling with Energy State Charts


Workload Descriptions


Resources (Hardware, OS, VM, …)

Software Components

Users

Approach: Runtime Environment

04.07.12

Global Resource Manager

Local Resource Manager #1

Local Resource Manager #2

Local Resource Manager #2.1

Effi

cien

cy

Workload + Demands

Global Control Loop Manager

Container Manager #1

Container Manager #2

Local App Manager #1.2

Local App Manager #1.1

MOO

Reconfiguration Planning

Monitoring / Profiling

Reconfiguration Act

Dec

ide

An

alys

e

Collect

Seb

astia

n G

ötz

- M

QuA

T

Slide 32

4. The Multi-Objective Optimization


Multi-Objective Optimization (MOO) with: •  Integer Linear Programming (exact) •  Pseudo-Boolean Optimization (exact) •  Ant Colony Optimization (approx.) •  Simulated Annealing (approx.) •  ... Contents of ILP for MOO:

–  Variables •  Base load •  Ressource consumption •  Mapping of Implementation (boolean) •  NFPs (e.g., bitrate, throughput, framerate, …)

–  Restrictions –  Objective Function

Speed –  Slow: with 30 components, 30 servers: 25 min

Multi-Objective Optimization (MOO) of Configurations


•  An ILP is generated for a certain request on a software component and a hardware variant.

ILP Generation for MOO


The Generated ILP


ILP Generator Architecture

1 contract VLC implements VideoPlayer.play {

2

3 mode highQuality {

4 requires component Decoder {

5 min dataRate: 9 MB/s

6 }

7 requires resource Net {

8 min bandwidth: 10 MB/s

9 }

10

11 provides min frameRate: 25 FPS

12 }

13 mode lowQuality {

14 /* More requirements and provisions here ... */

15 }

16 }

CCM Variant Model Runtime Description of Hard- & Software Infrastructure

CCM Structure Model Architecture of Hard- & Software System

QCL Contracts Characterizing Non-functional Behavior of Implementations

Decision Variables

Select Impl Map to HW

Constraints

NFP Provisions

NFP Requirements

Resource Provisions

Resource Requirements

fixed

Knapsack

Knapsack

Architectural Constraints

Objective Functions Requests + QoS Demands

ILP


Life-by-Wire needs Reliability and Adaptivity

Quality Contract Modeling

Static Quality

Contract Checking

Dynamic configuration optimization with MOO


Prof

. U

. Aßm

ann,

TU

Dre

sden

39

Live-by-Wire ...

http://www.digitaltrends.com/cars/destination-home-how-fully-autonomous-driving-might-come-sooner-than-we-think/


Contact Info

•  http://www.resubic.org •  [email protected] •  [email protected] •  [email protected] •  [email protected]

•  [Acatech] Agenda CPS. Acatech Studie März 2012.

HAEC CRC 912


Related Publications

S. Götz, C. Wilke, M. Schmidt, S. Cech, and U. Aßmann. Towards energy auto tuning. In: Proceedings of First Annual International Conference on Green Information Technology (GREEN IT), pp. 122–129. GSTF, 2010.

S. Götz, C. Wilke, S. Cech and U. Aßmann. Runtime Variability

Management for Energy-efficient Software by Contract Negotiation In Proceedings of the 6th International Workshop [email protected] (MRT 2011)

S. Götz, C. Wilke, S. Cech, and U. Aßmann. Architecture and Mechanisms of Energy Auto-Tuning. In: Sustainable ICTs and Management Systems for Green Computing, IGI Global, 2012

S. Götz, C. Wilke, S. Richly and U. Aßmann. Approximating Quality Contracts for Energy Auto-Tuning Software. To appear in Proceedings of First International Workshop on Green and Sustainable Software (GREENS 2012), 2012.

04.07.12

Seb

astia

n G

ötz

- M

QuA

T

Slide 41


•  ResUbic Lab develops the foundation of software for CPS –  Connects young researcher groups –  ZESSY ST / TIS –  EDYRA

•  Fluid Data / Open Data •  RIA / Mash-Ups

–  FlexCloud –  New: VICCI (CPS dashboards)

•  Common vision and demonstrators •  http://www.resubic.org/

10.04.2012

42

Forschergruppen

Documents

Multi-Objective Optimized Software Architectures (MOOSA ... · Multi-Objective Optimization (MOO) of Configurations Fakultät Informatik Institut Software- und Multimediatechnik,