Scenarios@run.time Distributed Scenarios@run.time Distributed - - PowerPoint PPT Presentation

▶
scenarios run time distributed scenarios run time
SMART_READER_LITE
LIVE PREVIEW

Scenarios@run.time Distributed Scenarios@run.time Distributed - - PowerPoint PPT Presentation

Mar 22, 2024 474 likes •868 views

Scenarios@run.time Distributed Scenarios@run.time Distributed Execution of Specifications on Execution of Specifications on IoT-Connected Robots IoT-Connected Robots 10th International Workshop on Models@run.time at MODELS 2015,

slide-1
SLIDE 1

29 September 2015

Scenarios@run.time – Distributed Scenarios@run.time – Distributed Execution of Specifications on Execution of Specifications on IoT-Connected Robots IoT-Connected Robots

10th International Workshop on Models@run.time at MODELS 2015, Ottawa, Canada

Joel Greenyer, Daniel Gritzner, Timo Gutjahr, Tim Duente, Stefan Dulle, Falk-David Deppe, Nils Glade, Marius Hilbich, Florian Koenig, Jannis Luennemann, Nils Prenner, Kevin Raetz, Thilo Schnelle, Martin Singer, Nicolas Tempelmeier, Raphael Voges

slide-2
SLIDE 2

2

Student Project UbiBots 2015

Student Project Website: http://ubibots2015.scenariotools.org/

Youtube Video: http://youtu.be/g0hcGSYC2Wk ScenarioTools Website: http://scenariotools.org

slide-3
SLIDE 3

3

Motivation

  • Examples: CarToX, Intelligent Factories, Smart Cities, …

– reactive: software continuously reacts to environment events – cyber-physical: multiple software components communicate to control processes in the physical world – ubiquitous: software interacts with users in diverse ways – safety-critical: failures can cause damage or cost lives – dynamic structures:

  • relationships between objects change (real and virtual)
  • relationships affect the communication behavior and vice versa
slide-4
SLIDE 4

4

Example: An Advanced CarToX Driver- Assistance System

  • Car-to-Car / Car-to-Infrastructure (Car-to-X) communication

– provides advanced driver-assistance features – controls traffic more efficiently

  • Examples:

BMW Car-to-X Communication https://www.car-2-car.org/

slide-5
SLIDE 5

5 approaching

  • bstacle on

blocked lane

Example CarToX Use Case: coordinated passage of a road work site

  • One lane of a two-lane street is blocked by road works
  • cars communicate with a control station for a safe passage

– instead of using traffic lights – an on-board display shows drivers whether they are allowed to enter the narrow passage or not

approaching

  • bstacle on narrow

passage lane

  • bstacle

ahead

road work control

slide-6
SLIDE 6

6

Example CarToX Use Case: coordinated passage of a road work site

  • What kinds of dynamism do we see here?

– Message-based communication of cars and control station

approaching

  • bstacle on

blocked lane approaching

  • bstacle on narrow

passage lane

  • bstacle

ahead

road work control

approaching

  • bstacle on

blocked lane approaching

  • bstacle on narrow

passage lane

  • bstacle

ahead

slide-7
SLIDE 7

7

Example CarToX Use Case: coordinated passage of a road work site

  • What kinds of dynamism do we see here?

– Message-based communication of cars and control station – Structural dynamism:

  • Physical: cars move along different sections of the road
  • Physical: cars change their relative position relationships
  • Virtual: the control station registers approaching cars

road work control cars approaching

  • n blocked lane

cars approaching

  • n narrow passage

lane

slide-8
SLIDE 8

8

Example CarToX Use Case: coordinated passage of a road work site

  • What kinds of dynamism do we see here?

– Message-based communication of cars and control station – Structural dynamism:

  • Physical: cars move along different sections of the road
  • Physical: cars change their relative position relationships
  • Virtual: the control station registers approaching cars
  • Physical: even road works may appear and disappear
slide-9
SLIDE 9

9

CarToX-System

  • Question: How would you approach the design of the

software for such a system?

slide-10
SLIDE 10

10

Collaboration: “approaching

  • bstacle on blocked lane”
  • Identify the different situations in which system and

environment objects interact to fulfill a certain functionality

– We call them Use Cases or Collaborations

  • Describe what the objects may, must, and must not do in

the form of scenarios

approaching

  • bstacle on

blocked lane

road work control

Collaboration

slide-11
SLIDE 11

11

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Dashboard Of Car Approaching On Blocked Lane

Shows Stop Or Go”:

road work control

slide-12
SLIDE 12

12

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Dashboard Of Car Approaching On Blocked Lane

Shows Stop Or Go”:

1) When approaching an obstacle on the blocked lane

road work control

1

approaching an obstacle

  • n the blocked lane
slide-13
SLIDE 13

13

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Dashboard Of Car Approaching On Blocked Lane

Shows Stop Or Go”:

1) When approaching an obstacle on the blocked lane 2)Then the dashboard must indicate to STOP or to GO

road work control

1 2

approaching an obstacle

  • n the blocked lane

showStop or showGo

slide-14
SLIDE 14

14

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Dashboard Of Car Approaching On Blocked Lane

Shows Stop Or Go”:

1) When approaching an obstacle on the blocked lane 2)Then the dashboard must indicate to STOP or to GO 3)Before the car finally reaches the obstacle

road work control

1 2

approaching an obstacle

  • n the blocked lane

showStop or showGo

3

  • bstacle

reached

slide-15
SLIDE 15

15

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Dashboard Of Car Approaching On Blocked Lane

Shows Stop Or Go”:

1) When approaching an obstacle on the blocked lane 2)Then the dashboard must indicate to STOP or to GO 3)Before the car finally reaches the obstacle

road work control

1 2

approaching an obstacle

  • n the blocked lane

showStop or showGo

3

  • bstacle

reached

How do we know whether to show STOP or GO?

slide-16
SLIDE 16

16

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Control Station Checks for Car Approaching On

Blocked Lane Entering Allowed Or Not”:

road work control

slide-17
SLIDE 17

17

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Control Station Checks for Car Approaching On

Blocked Lane Entering Allowed Or Not”:

1) When approaching an obstacle on the blocked lane

road work control

1

approaching an obstacle

  • n the blocked lane
slide-18
SLIDE 18

18

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Control Station Checks for Car Approaching On

Blocked Lane Entering Allowed Or Not”:

1) When approaching an obstacle on the blocked lane 2)The car must register at the obstacle's control station

road work control

1 2

approaching an obstacle

  • n the blocked lane

register

slide-19
SLIDE 19

19

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Control Station Checks for Car Approaching On

Blocked Lane Entering Allowed Or Not”:

1) When approaching an obstacle on the blocked lane 2)The car must register at the obstacle's control station 3)If there is an approaching car in or before the narrow passage area: disallow the car entering the narrow passage

  • otherwise allow it

road work control

1

approaching an obstacle

  • n the blocked lane

entering (Dis)Allowed

2

register

3

cars approaching

  • n narrow passage

lane

?

slide-20
SLIDE 20

20

Collaboration: “approaching

  • bstacle on blocked lane”
  • Scenario “Control Station Checks for Car Approaching On

Blocked Lane Entering Allowed Or Not”:

1) When approaching an obstacle on the blocked lane 2)The car must register at the obstacle's control station 3)If there is an approaching car in or before the narrow passage area: disallow the car entering the narrow passage

  • otherwise allow it

4)Then show STOP/GO accordingly on the driver's dashboard

road work control

1

approaching an obstacle

  • n the blocked lane

entering (Dis)Allowed

2

register

3 4

showStop or showGo

slide-21
SLIDE 21

21

A typical Software/Systems Development Process...

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design

slide-22
SLIDE 22

22

A typical Software/Systems Development Process...

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design informal specification: unambiguous? consistent?

slide-23
SLIDE 23

23

A typical Software/Systems Development Process...

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design informal specification: unambiguous? consistent? All requirements considered? Design correct?

slide-24
SLIDE 24

24

A typical Software/Systems Development Process...

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design informal specification: unambiguous? consistent? All requirements considered? Design correct? Testing? Based on informal specification.

slide-25
SLIDE 25

25

A typical Software/Systems Development Process...

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design informal specification: unambiguous? consistent? All requirements considered? Design correct? Testing? Based on informal specification. Not what stakeholder

  • wanted. Violates

critical requirements, → costly iterations

slide-26
SLIDE 26

26

Software Development Process

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design

rc:RailCab curr:TSC e:Env rc:RailCab e:ENV next:TSC

realizability checking & controller synthesis

formal, but intuitive specification

communicate, simulate

rc:RailCab e:ENV next:TSC

slide-27
SLIDE 27

27

Software Development Process

public void run(){ ...; }

✓ × ✓×

informal requirements informal or “semi-formal” specification implementation unit tests integration/ system tests use and maintenance

= ?

design

rc:RailCab curr:TSC e:Env rc:RailCab e:ENV next:TSC

realizability checking

formal, but intuitive specification

communicate, simulate

rc:RailCab e:ENV next:TSC rc:RailCab curr:TSC e:Env rc:RailCab e:ENV next:TSC

scenarios@run.time

slide-28
SLIDE 28

28

Scenario Design Language (SDL)

  • Textual language based on Live Sequence Charts (LSCs)
  • Collaborations describe, by a set of roles, a structure of
  • bjects that collaborate to fulfill a certain functionality
  • Scenarios describe properties that must be satisfied by all

message-based interactions of objects

collaboration ApproachingObstacleOnBlockedLane{ dynamic role Environment env dynamic role Car car dynamic role Dashboard dashboard ... specification scenario DashboardOfCarApproachingOn

  • BlockedLaneShowsStopOrGo{

message env->car.approachingObstacleOnBlockedLane() ... }

slide-29
SLIDE 29

29

The Object System

  • SDL specifications refer to systems
  • f objects (instances of a class model)

env

[...]

<<instanceof>>

slide-30
SLIDE 30

30

The Object System

  • SDL specifications refer to systems
  • f objects (instances of a class model)
  • Objects can exchange messages

env

[...]

approaching an obstacle

  • n the blocked lane

approachingObstacle- OnBlockedLane <<instanceof>>

slide-31
SLIDE 31

31

Scenario Design Language

  • Formalizing our first scenario:
  • With the modalities strict and requested, we can express

what may, must, and must not happen

specification scenario DashboardOfCarApproachingOn

  • BlockedLaneShowsStopOrGo

with dynamic bindings [ bind dashboard to car.dashboard ]{ message env->car.approachingObstacleOnBlockedLane() alternative{ message strict requested car->dashboard.showGo() } or { message strict requested car->dashboard.showStop() } message env->car.obstacleReached() }

slide-32
SLIDE 32

32

Scenario Design Language

  • Formalizing our second scenario:

specification scenario ControlStationChecksForCarOnBlockedLane with dynamic bindings [...]{ message env->car.approachingObstacleOnBlockedLane() message strict requested car->obstacleControl.register() alternative if [

  • bstacleControl.carsOnNarrowPassageLaneApproaching.isEmpty()

] { message strict requested obstacleControl->car.enteringAllowed() message strict requested car->dashboard.showGo() } or if[ !obstacleControl.carsOnNarrowPassageLaneApproaching.isEmpty() ] { message strict requested obstacleControl->car.enteringDisallowed() message strict requested car->dashboard.showStop() } }

slide-33
SLIDE 33

33

Simulation via Play-Out

  • An SDL specification can be executed via play-out

– an executable interpretation of the scenarios

  • This can be used for simulation

– to analyze and understand the interplay of the scenarios

  • The play-out algorithm In a nutshell:

1)environment events occur and activate scenarios 2)the scenarios prescribe events that the system must execute 3)play-out executes these events while trying to avoid violations 4)when all system reactions are executed, wait for the next environment event (goto Step 1)

slide-34
SLIDE 34

34

Simulation via Play-Out in ScenarioTools

slide-35
SLIDE 35

35

Scenarios@Run.time

slide-36
SLIDE 36

36

Steps in the Scenarios@Run.time Framework

  • ther clients

MQTT boker sensors actuators client (e.g. robot) MQTT client executor ScenarioTools play-out engine 1 3

publish sensor event publish event broadcast event

5 6

execute step enabled requested system events

7

if event is actuator event

  • f client then

execute

4 8

select and send event sendable by client

3 2 ...

slide-37
SLIDE 37

37

Summary & Perspective

  • Execute scenario specifications on distributed systems
  • New:

– dynamic structures: interpretation of dynamic role bindings – also execute environment assumptions

  • run-time monitoring if environment behaves as assumed
  • Relies on full synchronization of all components on all events

– this overhead must be reduced:

  • only synchronize objects in certain parts of the system
  • analyze at run-time minimal set of components to synchronize
  • Future work:

– safe run-time updates of specification changes – dependability: how to recover from run-time failures