Some issues in model-based development for embedded control systems - - PowerPoint PPT Presentation

some issues in model based development for embedded
SMART_READER_LITE
LIVE PREVIEW

Some issues in model-based development for embedded control systems - - PowerPoint PPT Presentation

Some issues in model-based development for embedded control systems Paul Caspi Verimag-Cnrs www-verimag.imag.fr EMSOC Villard de Lans june 2006 intro intro intro intro intro intro Introduction Model-based development widely


slide-1
SLIDE 1

Some issues in model-based development for embedded control systems

Paul Caspi Verimag-Cnrs www-verimag.imag.fr EMSOC Villard de Lans june 2006

intro intro intro intro intro intro

slide-2
SLIDE 2

Introduction

  • Model-based development widely recognised as a method of choice for efficient and

safely design

  • More effectively used in embedded control

– e.g., automatic code generation in Airbus fly-by-wire (1984) – Simulink-CAN, Simulink-TTA,...

  • But rather empirical, lack of foundations

Some issues:

  • 1. Model-based development in control and in computer science
  • 2. Sampling theory for discrete event and hybrid systems
  • 3. Preserving a synchronous model semantic in asynchronous implementations
  • 4. UML vs Simulink: what is object orientation in block-diagram approaches?

intro comp intro comp intro comp

slide-3
SLIDE 3

Model-based design in computer science and control

Model-based design in computer science

  • Starts from a non deterministic specification
  • Based on successive property-preserving refinements
  • Until an implementation is reached

Remarks:

  • This is an idealised scheme, seldom fulfilled
  • Yet has a paradigmatic value
  • Some real-world impressive achievements in control!!

– B method (Abrial): Paris, Barcelona, New York subways

intro sample intro sample intro sample

slide-4
SLIDE 4

Model-based design in computer science

MACHINE initial SETS persons, buildings ABSTRACT CONSTANTS state, authorisation PROPERTIES persons = ∅ ∧ buildings = ∅ ∧ state ∈ persons → buildings ∧ authorisation ∈ persons ↔ buildings INV ARIANT state ⊆ authorisation OPERATION move ˆ = ANY (p, b) WHERE (p, b) ∈ authorisation ∧ state(p) = b THEN state(p) := b END END

intro sample intro sample intro sample

slide-5
SLIDE 5

Model-based design in computer science

Further steps:

  • Add implementation details:

– paths, doors, badge controls,...

  • Separate controllers from environment !!!
  • Generate control programs

intro sample intro sample intro sample

slide-6
SLIDE 6

Model-based design in computer science and control

Model-based design in control science

  • Start from a perfect model
  • Design a robust controller
  • Add perturbations and implementation details and checks for robustness

Remarks:

  • This is also an idealised scheme

intro sample intro sample intro sample

slide-7
SLIDE 7

Model-based design in control

Perfect model

xo" yo" x y xo yo

pendule

xd x xo xo" yo"

contcontr Scope Pulse Generator Band−Limited White Noise

50 100 150 200 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-8
SLIDE 8

Model-based design in control

Perfect model with noise

xo" yo" x y xo yo

pendule

xd x xo xo" yo"

contcontr Scope Pulse Generator Band−Limited White Noise

50 100 150 200 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-9
SLIDE 9

Model-based design in control

Discrete-time controller

xo" yo" x y xo yo

pendule

xd x xo xo"

discrcontr Scope Pulse Generator Constant Band−Limited White Noise

50 100 150 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-10
SLIDE 10

Model-based design in control

Discrete-time controller with noise

xo" yo" x y xo yo

pendule

xd x xo xo"

discrcontr Scope Pulse Generator Constant Band−Limited White Noise

50 100 150 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-11
SLIDE 11

Model-based design in control

Discrete-time controller with jitter

xo" yo" x y xo yo

pendule

In1 Out1

jitter

xd x xo xo"

discrcontr Scope Pulse Generator Constant Band−Limited White Noise

20 40 60 80 100 120 140 160 180 200 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-12
SLIDE 12

Model-based design in control

Discrete-time controller with jitter and noise

xo" yo" x y xo yo

pendule

In1 Out1

jitter

xd x xo xo"

discrcontr Scope Pulse Generator Constant Band−Limited White Noise

20 40 60 80 100 120 140 160 180 200 −0.5 0.5 1 1.5 Time offset: 0

intro sample intro sample intro sample

slide-13
SLIDE 13

Model-based design in computer science and control

How can we make them converge ?? A suggestion : Consider the perfect control model as specifying a set of behaviours, those behaviours which are within some “distance” of the perfect model behaviour. This requires some notion of “distance”, able to account for

  • perturbations
  • modelling errors
  • discretisation
  • jitter and communication delays
  • ...

intro sample intro sample intro sample

slide-14
SLIDE 14

Sampling discrete event and hybrid systems

Continuous control is implemented by periodic sampling (time-triggered)

  • sampled-data control theory
  • numerical analysis

Discrete event control is implemented by event triggered systems What about mixed (hybrid) systems ?? Experience shows that periodic sampling is a popular solution but an empirical one

intro preserv intro preserv intro preserv

slide-15
SLIDE 15

Sampling discrete event systems

A possible sampling b a

intro preserv intro preserv intro preserv

slide-16
SLIDE 16

Sampling discrete event systems

Another one b a

intro preserv intro preserv intro preserv

slide-17
SLIDE 17

Races

A race takes place when two variables can change in distinct orders A race is critical if different states can be reached according to which variable changes first A critical race A non-critical race ♠ ❄ a ↑, b ↑ ♠ a ↑

♠ b ↑ ❄ ♠

bad

♠ ❄ a ↑, b ↑ ♠ a ↑

♠ b ↑ ❅ ❅ ❅ ❅ ❘

intro preserv intro preserv intro preserv

slide-18
SLIDE 18

Sampling discrete event and hybrid systems

Which kind of “distance” can account for

  • perturbations
  • modelling errors
  • discretisation
  • jitter and communication delays
  • sampling discrete events
  • races
  • ...

intro preserv intro preserv intro preserv

slide-19
SLIDE 19

Event and time-triggered systems

Uniform Random Number Scope2 Scope Pulse Generator1 Pulse Generator

acceleration intake

Ignition

noise intake speed angle

Engine

actual speed desired speed acceleration

Control

intro uml intro uml intro uml

slide-20
SLIDE 20

Characteristics of the model

Based on several idealisations:

  • The engine model is more or less accurate
  • Computations are exact
  • Computations take no time (synchronous abstraction)

Implementation approximations

  • Bounds on computation errors.
  • Deadlines on executions

Domain dependent

intro uml intro uml intro uml

slide-21
SLIDE 21

Preemptive scheduling

If the deadline associated with event-triggered computations is smaller than the execution time of time-triggered tasks, preemptive scheduling is mandatory: ✲ ✲ ✲ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ ❄ Control Ignition Mixed

intro uml intro uml intro uml

slide-22
SLIDE 22

A solution : deadline monotonic scheduling

Fixed priorities in the reverse order of deadlines Di (Burns & al. 94) Schedulability test: iterative computation of response times Rj =

  • i=1,j−1

Rj Ti

  • Ci + Cj
  • task priorities in decreasing order
  • Ti minimum inter-arrival time ( Di < Ti)
  • Ci worst execution times

It suffices then to verify for every i : Ri < Di

intro uml intro uml intro uml

slide-23
SLIDE 23

Inter-task communication

Communication integrity, several approaches:

  • Blocking approaches based on semaphores

Priority inversion (pathfinder !!) priority inheritance, priority ceiling protocols

  • Lock-free methods
  • Loop-free, wait-free methods

Burns et Chen (triple buffer) provide easier schedulability analysis ?

intro uml intro uml intro uml

slide-24
SLIDE 24

What about semantics?

...and model-based development? Preemption alters the ordering of computations – In many cases it does not matter (robustness, continuity, ...) – In some cases it can (discontinuities, critical races, ...) Can we propose executions that be functionally equivalent to the model?

intro uml intro uml intro uml

slide-25
SLIDE 25

Proposed solution

Ensures communication integrity and provides executions that are functionally equivalent to the model: Based on:

  • 1. Syntactic checks: communications from low to high priority tasks should go through

a unit delay on the low task trigger

  • 2. Double buffer protocols where distinction is made between the occurrence of

triggering events and the task executions

intro uml intro uml intro uml

slide-26
SLIDE 26

Simulink and UML

Simulink Functional block-diagrams + Automata (Stateflow) Continuous time, discrete and event triggered systems Simulation, code generation (Scade...), verification Many libraries, (TTA, CAN, preemptive scheduling,...) UML Class, flow and activity diagrams, Message sequence charts Simulation, code generation, verifica- tion OS support

intro intro intro

slide-27
SLIDE 27

Ways of mixing them

A “popular way”:

  • Devote Simulink (Scade) to time-triggered systems
  • Devote UML to event-triggered systems

Some dubious statements:

  • “Simulink can’t handle event-triggered systems”
  • “Control people don’t care of objects and classes”

Are these the right ways ? Do these allow bridging the enlarging cultural gap between Control and Computer sciences ?

intro intro intro

slide-28
SLIDE 28

Mode-Automata in Simulink

A cooperative way of designing complex systems:

  • teams begin to agree on shared variable names,
  • then each team can independently design and validate its own mode.

intro intro intro

slide-29
SLIDE 29

The Up team builds the “up” mode . . .

function() In1 Out1

up Scope f() Function−Call Generator A Data Store Memory 1 Constant

double double fcn_call

up.mdl

1 Out1 A Data Store Write A Data Store Read f() function 1 In1

double double double

intro intro intro

slide-30
SLIDE 30

. . . , tries it and saves it

5 10 15 20 25 30 20 40 Time offset: 0

updown.mdl

function() In1 Out1

up

intro intro intro

slide-31
SLIDE 31

The Down team builds the “down” mode . . .

function() In1 Out1

down Scope f() Function−Call Generator A Data Store Memory 1 Constant

double double fcn_call

down.mdl

1 Out1 A Data Store Write A Data Store Read f() function 1 In1

double double double

intro intro intro

slide-32
SLIDE 32

. . . , tries it and saves it

5 10 15 20 25 30 −40 −20 Time offset: 0 updown.mdl

function() In1 Out1

up

function() In1 Out1

down

The Simulink library looks like a Java “static class”

intro intro intro

slide-33
SLIDE 33

The UpDown team combines the two models. . .

function() In1 Out1

up_down Scope f() Function−Call Generator 1 Constant

double double fcn_call

up down.mdl

1 Out1

function() In1 Out1

up

x s event event1

mode_control

function() In1 Out1

down z 1 Unit Delay Switch A Data Store Memory f() function 1 In1

double double fcn_call fcn_call double double double double

intro intro intro

slide-34
SLIDE 34

. . . through the activation automaton. . .

  • ther_up_down/up_down/mode_control

Printed 20−May−2005 11:21:03

up entry: event during: event down entry: event1 during: event1 /s=1 [x<−5]/s=1 [x>5]/s=0

intro intro intro

slide-35
SLIDE 35

. . . and tries it

5 10 15 20 25 30 −5 5 Time offset: 0

It works...

intro intro intro

slide-36
SLIDE 36

Interest and Drawbacks

  • Interest :

– Modular approach No redesign No complex wiring

  • Drawbacks

– Unsafe features when activations are not exclusive lexicographic execution order!!! – Dynamic binding the shared variable binding is performed at instanciation

intro intro intro

slide-37
SLIDE 37

How to improve on it?

  • Retrieve the advantages

last construct no redesign no complex wiring

  • Propose a safe construct

statically check the clock mutual exclusion (use the merge construct for instance)

  • Move to a much safer static binding

binding takes place at the definition libraries become true classes !!!

intro intro intro

slide-38
SLIDE 38

Libraries become true classes !!!

newupdown.mdl

function() In1 Out1

up

function() In1 Out1

down A Data Store Memory

Simulink could now be endowed with a class diagram : the distance with UML would get narrower

intro intro intro

slide-39
SLIDE 39

Conclusion

This seems to show some need for making control and computing cultures converge and cross fertilise Thank you for your attention

intro intro intro