Advanced Real Time Systems Paper Presentation · Advanced Real Time Systems Paper Presentation...

Advanced Real Time Systems

Paper Presentation

Thiago R. Assis Advisor: Dr. Bharat L. Bhuva

Nashville – TN - USA

Oct. 11th 2012

The Synchronous Approach

To Reactive and Real-Time Systems

Nashville – TN - USA

By: Albert Benveniste

Gérard Berry

Proceedings of the IEEE, Vol. 79, No. 9

September 1991

Invited Paper

Vanderbilt Engineering

3/37 10/15/2012 Paper Presentation – Advanced Real Time Systems – Thiago Assis

Introduction

Real Time and Reactive Systems

Reactive and Real Time Systems

Application Areas

Case of study

Major Issues

Real Time Programming

State of the art

The Synchronous Approach to Reactive and RT Systems

Examples – Synchronous Approach

Clicking on a Mouse

Digital Filtering

Toward the Synchronous Modeling

Summary of the Synchronous Model

Synchronous Model versus Asynchronous Systems

Implementing a Digital Filter

Synchronous Approach to Asynchronous Implementations

Possible Impact of the Synchronous Approach

Conclusions

Attachment 1

Summary


4/37 10/15/2012

Introduction



Reactive and Real-Time Systems

Reactive systems

Systems that maintains a permanent interaction with the

environment

Real Time (RT) systems

Systems that subjected to timing constrains.

Systems Constrains

Logical correctness

Temporal correctness

Safety

Synchronous Approach

Consider “ideal” systems

Output are synchronously with their inputs

First introduced for Software [HAREL, 1985][BERRY, 1983][GUERNIC, 1986]

Similarities with classical hardware concepts

Clocked digital circuits

Communication between subcomponents

Introduction

This concept will be expanded later…


6/37 10/15/2012

Reactive and RT Systems



Application Areas

Pure Task Sequencers

Command boards, man-machine interfaces, computer

integrated manufacturing (CIM)

Sequence of tasks like:

Communication Protocols

Network equipment's

Low Level Signal Processing, Industrial Process Control,

Complex Signal Processing systems, Complex Control and

Monitoring systems, Command-Control-Communicate C3-

Systems, etc.


PUN_OBJECT_ON_BELT;

BELT_IN_MOTION;

DETECT_OBJECT;

GRASP_OBJECT;



Case of Study

Automobile Control.

Controllers for:

Fuel injection

Brakes

Suspension, direction, etc.

Complexity is growing

Coordination will become a problem

Safety must be considered

Man-machines interfaces

Will be computerized

Failure detection and reporting

Messages should be simple and should not involve dozen

of individual failures.




Case of Study

Speech Recognition Systems

Continuous speech signal must be processed on-line to avoid

unbounded buffering.

High-speed numerical preprocessing and complex

symbolic post processing is required


Speech-to-phoneme system

1) Segmentation of the continuous speech

signal

2) Automaton: supervises the

segmentation, fires small modules to

compute the “cepstra” (spectral

characteristics of the signal) and

acoustic-phonetic cues.

3) High level processing using (Hidden-

Markov Model (HMM)).

4) String of phones is outputted



Major issues to be considered when designing a RT System

1) Use modular and formal techniques to specify, implement and

verify programs

Modular programming is necessary to reflect the conceptual

architecture of the system

Formal verification tools should be provided to analyze

the equivalence between the architecture and the

modular representation.

2) Encompass within a single framework all reactive aspects

A single framework should be able to deal with different kinds

of systems aspects

3) Deal with distributed target architectures

Distributed systems might be a requirement.

4) Preserve Determinism whenever possible

Avoid nondeterministic solutions. No reason to create

unpredictable behavior.

5) Consider issues of speed.

Avoid overheads due to unnecessary computation.



11/37 10/15/2012




State of the Art

Classical – OS primitives

Programs communicate using OS system calls, making the

development more easy.

No single object to evaluate, but a set of loosely connected

programs, and OS are generally somewhat “nondeterministic”

Finite-states machines

State machines are deterministic, efficient and can be

automatically analyzed

Do not directly support hierarchical design and can be very difficult

to design if the system is big

Petri Nets

Naturally support concurrency

Do not scale well to big applications.

Concurrent Programming Languages

Concurrency and modular programming are supported.

Considered asynchronous and nondeterministic. Automatic

verification is often not feasible.





Reconciles the aspects discussed before

Deterministic

Concurrent programming

Hierarchical design

The approach is simple:

Their reaction takes NO observable time.

Interactions are Instantaneous

It’s also known that: a set of ideal systems, compose “very well”

into other ideal systems.


“Consider the system as an IDEAL reactive systems that produce their outputs

SYNCHRONOUSLY with their inputs”

Two examples of the “Synchronous style of modeling” are going to be briefly discussed


14/37 10/15/2012

Examples – Sync. Approach



Clicking on a Mouse

Mouse Handler with two inputs

CLICK (Push-button)

TICK (Clock signal)


State Transition Diagram

1) “Click” is interpreted at SIMPLE_MOUSE

1) START signal “fires” GO module

2) GO “watches” for elapsed time (4 cycles)

1) RELAX indicates end of period

3) SIMPLE_MODULE

1) Wait for Clicks and RELAX

1) Decide for SINGLE our DOUBLE

START

CLICK

CLICK

SINGLE DOUBLE

SINGLE DOUBLE

TICK

RELAX

MOUSE

SIM

PL

E_

MO

US

E

GO

CLICK?

TICK?.RELAX?

TICK?

TICK? TICK? TICK? START?

START?.TICK?

CLICK?

CLICK?.RELAX? DOUBLE!

RELAX?.DOUBLE!

CLICK?.START!

RELAX?.SINGLE!

CLICK?.RELAX?.DOUBLE!



Specification Interpretation - Rules

1) Changes of state should be considered Synchronous (Simultaneous)

2) Emission of output signals in each modules should be considered

synchronous with the associated change of states

3) Communication follow the principle of “instantaneous broadcast”. The

reception is synchronous with their emission.

4) The output behavior of MOUSE is entirely fixed whenever the global

interleaving of the two input signals TICK, CLICK is give by the

environment.


A Chronogram of events:

time

START RELAX

DOUBLE

TICK

CLICK

TICK TICK TICK TICK TICK

CLICK

Notice:

I. These are discrete events

II. State change simultaneous

III. Output signal is synchronous with the

input events.

Inp

ut

Ou

tpu

t

! Use ideal synchronous model as much as possible and consider actual timing dependencies ONLY when

needed and where needed.



Digital Filtering

At the nodes of the graph, incoming signals are added and their

result is broadcast along the outgoing branches.


This graph is a coding of the following formula:

Signal Flow Graph (Second order filter)

𝑎𝑖 , 𝑏𝑗 ; 𝑚𝑢𝑙𝑡𝑖𝑝𝑙𝑖𝑐𝑎𝑡𝑖𝑜𝑛 𝑏𝑦 𝑡ℎ𝑒 𝑐𝑜𝑛𝑠𝑡𝑎𝑛𝑡 𝑧−1; 𝑠ℎ𝑖𝑓𝑡 𝑟𝑒𝑔𝑖𝑠𝑡𝑒𝑟𝑠

𝑤𝑛 = 𝑢𝑛 + 𝑎1𝑤𝑛−1 + 𝑎2𝑤𝑛−2

𝑦𝑛 = 𝑏0𝑤𝑛− + 𝑏1𝑤𝑛−1 + 𝑏2𝑤𝑛−2

𝑦𝑛 = 𝑎1𝑦𝑛−1 + 𝑎2𝑦𝑛−2 + 𝑏0𝑢𝑛 + 𝑏1𝑢𝑛−1 + 𝑏2𝑢𝑛−2

𝑛 ; 𝑡𝑖𝑚𝑒 𝑖𝑛𝑑𝑒𝑥

(!) Observe that it follows the principles

(1,2,3) of synchronicity.



Digital Filtering

The 4th principle will apply to the following example


Signal Flow Graph (Two port filter)

Input “v” is added to the formula

𝑦𝑛 = 𝑎1𝑦𝑛−1 + 𝑎2𝑦𝑛−2 + 𝑏0𝑢𝑛 + 𝑏1𝑢𝑛−1 + 𝑏2𝑢𝑛−2 + 𝑣𝑛

(!) Principle (4) of synchronicity

applies here.

* Each sample of u, must correspond to a unique

sample of v.


19/37 10/15/2012

Toward the Synchronous Mod.



The next two slides will “illustrate” that the last two examples could be

represented in different ways. (Digital Filter with transition diagram and

Mouse with recurrent equations)

State Transition for the Digital Filter

Use a more simple digital filter, with the following equation


𝑦𝑛 = 𝑎1𝑦𝑛−1 + 𝑎2𝑦𝑛−2 + 𝑢𝑛

i) Introduce the vector signal: 𝑋𝑛 =𝑦𝑛

𝑦𝑛−1

ii) Rewrite in the state space form: 𝑋𝑛 =

𝑎1 𝑎2

1 0𝑋𝑛−1 +

𝑢𝑛

0

𝑦𝑛 = 1 0 𝑋𝑛

𝛼

Transition diagram: 𝛼 State counts the interactions and

execute the equations at each cycle.



Recurrent Equations for the Mouse

Simplify to only consider: SIMPLE_MOUSE module.


START CLICK

SINGLE DOUBLE

RELAX

SIM

PL

E_

MO

US

E

CLICK?

CLICK?

CLICK?.RELAX? DOUBLE!

RELAX?.DOUBLE!

CLICK?.START!

RELAX?.SINGLE!

CLICK?.RELAX?.DOUBLE!

𝑁 = 1,2, … . .

𝐶 = 𝐶1, 𝐶2, … . , 𝐶𝑚

𝑅 = 𝑅1, 𝑅2, … . , 𝑅𝑘

Events will be indexed with:

Click event:

Relax event:

Running index (n) denotes current event:

𝑁 = 𝐶 ∪ 𝑅 (1)

𝑋𝑛 = 𝑖𝑓 𝑛 ∈ 𝑅 𝑡ℎ𝑒𝑛 0 𝑒𝑙𝑠𝑒 𝑚𝑖𝑛 2, 𝑋𝑛−1 + 1 (2)

𝑀𝑅𝑘 = 𝑖𝑓 𝑅𝑘 ∈ 𝐶 𝑡ℎ𝑒𝑛 𝑚𝑖𝑛 2, 𝑋𝑅𝑘−1 + 1 𝑒𝑙𝑠𝑒 𝑋𝑅𝑘−1 (3)

𝑖𝑓 𝑅𝑘 ∈ 𝐶, 𝑡ℎ𝑒𝑛 𝑋𝑅𝑘−1 ≠ 0 (4)

(1) Specifies that events consist of occurrence of at least CLICK or RELAX.

(2) X (state) is reset to 0 whenever RELAX is received and incremented whenever

CLICK is received but not Relax.

(3) 𝑀𝑅𝑘(output: 1 or 2). Output M has the same index of R.

(4) States that RELAX cannot occur when counter is in its initial state 0.



Summary of the Synchronous Model

Features of the Ideal RT machine specified before

Output is synchronous with input. Internal actions are

instantaneous.

Global interleaving of the external communication may be

partially chosen by the environment.

State Based Formalisms

Used in the mouse example. Arrows indicate communication

actions.

Easy and natural to use when control flow is prevalent

Define concurrent behavior is not easy.

Multiple Clocked Recurrent Systems (MCR’s)

Digital filter example. Describe the legal traces of the system

and are generalization of the usual models of dynamical

systems used in digital signal processing or control.

Well-adapted where data flow is prevalent

When the control flow is complex, defining MCR’s can be very

difficult.




Solving Communication Equations

No solution: constrains may contradict each other

Infinitely many solutions: if the timing of the various signals is

not completely determined, we get a nondeterminism solution

Single solution: The program is deterministic and is suitable for

execution.

Program Verification

It’s a very important feature that should be taken into account

Formally verify program properties

MCR’s and State Diagrams

Software tools available to perform verification over this kind

of approach



24/37 10/15/2012

Synchronous Models

Vs.

Asynchronous Systems



Real Time Systems

Usually they are asynchronous

Distributed Systems and Multiprocessors

Most of the applications listed before are asynchronous

Synchronous modeling it is still possible

Implementing a Digital Filter

The state machine representation of the Digital Filter is unrealistic

A better solution is required.

Purely sequential implementation

First consider the Filter cutting the branch 𝑧−1

Synch. Model vs. Async. Systems



An acyclic graph is generated

This yields a sequential execution scheme of each single time

step of the system.


A data flow (asynchronous) execution can

be derived by interpreting each node and

branch in the graph (of the two port filter)

according to the following data flow.

Data flow mechanism representation:



Validating Asynchronous Machines with Synchronous Models

The data-flow representation[LEE, 91] can be used to model the data

flow

A global “time indexing” of the tokens is generated


Data-flow actor: SELECT Time indexing of the tokens

Example, using the SELECT operation “The tokens that are consumed or produced in a

given firing must have the same time index.”

The result is that a synchronous model was associated with the “data-flow actor”

Using the “data-flow actors” primitives we can automatically build a synchronous model.

Formal verification methods, associated with the “data-flow actors” can now be

used.



Approach Presented:


Application

Problem

4 Principles 1) Synchronous state change.

2) Output synchronous with change of

states.

3) Instantaneous broadcast of messages

4) Output is synchronous with the inputs

Transition

Diagram

Recurrent

Equations

Async. Appr. Styles

Mo

delin

g

Synchronous\Asynchrnous problem

The “problem” will be considered “ideal” within respect to the principles

of Sync. Systems.

Async. Problems will be relaxed to be modeled as Synchronous

problems.

Fo

rmal

Veri

ficati

on

Model the data

Flow with the

“actors” model

Create a Data Flow

representation

Use the concept

Of indexed tokens

To make the actors

model synchronous

Use Available

Formal Verif.

Methods

The objective at this moment is to show that it is possible to verify the solutions if a

Synchronous Approach is considered.



The Synchronous Approach to Asynchronous Implementations

1) When feasible, strictly synchronous executions of synchronous

systems are certainly valid

2) Verification and proofs of correct synchronization and logic are

available in the Synchronous Approach.

3) A sequential execution scheme can be derived at compile time

for any synchronous system

4) The synchronicity hypothesis can be relaxed to yield fully

asynchronous executions of synchronous systems that are

guaranteed correct.

5) Formal verification tools based on synchronous approach provide

a way to validate asynchronous executions



30/37 10/15/2012

Possible Impact of the

Synchronous Approach



The techniques presented here are a “novel”.

Two questions still largely open

User-interfaces

The development of rich user interfaces for Synchronous

Languages must be a technical priority

Statecharts: state oriented

Block-diagram: data-flow oriented

Non of these approach's cover the hole area of reactive

and real time systems.

Programming Methodology


New design and programming styles

New methodologies needs to be created to make this new

style easy to master

Possible Impact of the Sync. Approach


32/37 10/15/2012

Conclusions



Major issues related with Reactive and RT Systems were discussed

The new Synchronous Programming Approach was informally presented

Two different styles to define synchronous solutions were presented

Each style applies to a particular class of problem.

A Methodology to verify program constrains was briefly discussed

It was shown that it’s possible to make an asynchronous implementation

looks like a synchronous one.

Conclusions


34/37 10/15/2012

Thanks….. Paper Presentation

The Synchronous Approach to Reactive and Real-Time Systems

Short Bio:

In 1990 he received the CNRS silver medal and in 1991

he has been elected IEEE fellow. In 2008 he was winner of

the Grand Prix France Telecom of the French Academy of

Sciences. From 1986 to 1990 he was vice-chairman of the

IFAC committee on Theory and was chairman of this

committee for 1991-1993. From 1979 to now he has been

Directeur de Recherche at INRIA.

www.irisa.fr/distribcom/benveniste


35/37 10/15/2012

Attachment 1



The Synchronous Languages

12 Years Later

By: Albert Benveniste, Paul Caspi, Stephen A. Edwards, Nicolas

Halbwachs, Paul Le Guernic and Robert de Simone.

Proceedings of the IEEE, Vol. 91, No. 1

January 2003

Invited Paper

“12 years later” (1991->2003)



“12 years later…..”

Synchronous languages have been established as a technology

choice for:

Modeling, specifying, validating and implementing RT embedded

applications.

The paradigm of synchrony has emerged as an engineer-friendly

design method.

Synchronous Languages Like

Esterel, Lustre and Signal

Have been successfully commercialized.

The Synchronous Languages 12 Years Later

Advanced Real Time Systems Paper Presentation · Advanced Real Time Systems Paper Presentation...

Documents

Transcript of Advanced Real Time Systems Paper Presentation · Advanced Real Time Systems Paper Presentation...