The                                                                Fixed Logical Execution Time (FLE...
Download
1 / 84

The Fixed Logical Execution Time (FLET) Assumption - PowerPoint PPT Presentation


  • 223 Views
  • Uploaded on

The Fixed Logical Execution Time (FLET) Assumption. Tom Henzinger University of California, Berkeley. The History of Computer Science: Lifting the Level of Abstraction.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'The Fixed Logical Execution Time (FLET) Assumption' - Antony


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Slide1 l.jpg

The Fixed Logical Execution Time (FLET) Assumption

Tom Henzinger University of California, Berkeley


Slide2 l.jpg

The History of Computer Science: Lifting the Level of Abstraction

High-level languages: Programming to the application

Compilation: perhaps “the” success story of computer science

It is feasible to abstract the platform.

The “assembly age”: Programming to the platform


Slide3 l.jpg

The History of Computer Science: Lifting the Level of Abstraction

Automatic program synthesis: No more programming

Code generation from specifications: still mostly a dream

It is not feasible to abstract algorithms and data structures.

High-level languages: Programming to the application

Compilation: perhaps “the” success story of computer science

It is feasible to abstract the platform.

The “assembly age”: Programming to the platform


Slide4 l.jpg

Current Practice in Embedded Software Design Abstraction

-often inefficient -often unpredictable -e.g. Real-Time Workshop

Some automatic code generation from models

-difficult to reuse -difficult to verify -requires systems experts

Some manual programming to the platform


Slide5 l.jpg

Current Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

Code generation difficult

Code verification difficult

Efficient code (scheduled by RTOS)


Slide6 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

The missing link: platform-independent programming model

Efficient code (possibly schedule-carrying)


Slide7 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

Verification

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)


Slide8 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

Verification

-verifiable -reusable-efficiently implementable

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)


Slide9 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

Verification

-verifiable -reusable-efficiently implementable

The missing link: platform-independent programming model

Reusable = composable + portable

Compilation

Efficient code (possibly schedule-carrying)


Slide10 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Requirement A

Requirement B

+

Program A

Program B

+

Compositionality

Platform P


Slide11 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Requirement A

Requirement B'

+

Program A

Program B'

+

Compositionality

Platform P


Slide12 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Requirement A

Program A

Portability

Platform P

Platform Q


Slide13 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

-concurrency -environment time

Verification

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

-distribution -platform (CPU) time


Slide14 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

-concurrency -environment time

Verification

-concurrency -environment time

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

-distribution -platform (CPU) time


Slide15 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

-descriptive -mathematics / logic

Verification

-concurrency -environment time

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

-prescriptive -algorithms + data structures


Slide16 l.jpg

Advocated Practice in Embedded Software Design Abstraction

Mathematical models (e.g. Simulink)

-descriptive -mathematics

Verification

-concurrency -environment time-prescriptive -virtual machine

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

-prescriptive -algorithms + data structures


Slide17 l.jpg

Advocated Practice in Embedded Software Design Abstraction

e.g. What is the control equation? What is the sampling rate?

Mathematical models (e.g. Simulink)

Verification

e.g. Which procedure computes the control equation? Which event triggers the computation?

The missing link: platform-independent programming model

Compilation

e.g. Which CPU executes the control procedure? What priority has the execution?

Efficient code (possibly schedule-carrying)


Slide18 l.jpg

First Attempt Abstraction

Mathematical models (e.g. Simulink)

The missing link: platform-independent programming model

Priorities

Efficient code (scheduled by RTOS)


Slide19 l.jpg

First Attempt Abstraction

Mathematical models (e.g. Simulink)

Not sufficiently abstract

-not about environment time -not compositional

Programming model: Priorities

Efficient code (scheduled by RTOS)


Slide20 l.jpg

First Attempt Abstraction

Mathematical models (e.g. Simulink)

Correctness?

Scheduling theory

Not sufficiently abstract

-not about environment time -not compositional

Programming model: Priorities

Efficient code (scheduled by RTOS)

Efficiency!


Slide21 l.jpg

Second Attempt Abstraction

Mathematical models (e.g. Simulink)

Synchrony assumption: platform time infinitely faster than environment time

The missing link: platform-independent programming model

Efficient code (scheduled by RTOS)


Slide22 l.jpg

Second Attempt Abstraction

Mathematical models (e.g. Simulink)

Too abstract

difficult to compile to resource-constrained, distributed platforms

Synchronous programming languages (Esterel, Lustre, Signal, etc.)

Efficient code (scheduled by RTOS)


Slide23 l.jpg

Second Attempt Abstraction

Mathematical models (e.g. Simulink)

Correctness!

Too abstract

difficult to compile to resource-constrained, distributed platforms

Synchronous programming languages (Esterel, Lustre, Signal, etc.)

Efficient code (scheduled by RTOS)

Efficiency?


Slide24 l.jpg

Our Attempt Abstraction

Mathematical models (e.g. Simulink)

FLET assumption:

-verifiable -efficiently implementable -composable -portable

The missing link: platform-independent programming model

Efficient code (possibly schedule-carrying)


Slide25 l.jpg

The FLET (Fixed Logical Execution Time) Assumption Abstraction

Software Task

write actuator output at time t+d, for fixed d

read sensor input at time t


Slide26 l.jpg

The FLET (Fixed Logical Execution Time) Assumption Abstraction

Software Task

d>0 is the task's "logical execution time"

write actuator output at time t+d, for fixed d

read sensor input at time t


Slide27 l.jpg

The FLET Programming Model Abstraction

The programmer specifies d (could be any event) to solve the problem at hand.

The compiler ensures that d is met on a given platform (hardware resources and performance); otherwise it rejects the program.


Slide28 l.jpg

The FLET (Fixed Logical Execution Time) Assumption Abstraction

time t

time t+d

possible physical execution on CPU

buffer output


Slide29 l.jpg

Portability Abstraction

50% CPU speedup


Slide30 l.jpg

Composability Abstraction

Task 1

Task 2


Slide31 l.jpg

Verifiability through Predictability (Internal Determinism) Abstraction

-timing predictability: minimal jitter -function predictability: no race conditions


Slide32 l.jpg

Contrast FLET with Standard Practice Abstraction

output as soon as ready




Slide35 l.jpg

Test Case: Flight Control Software Abstraction

UC Berkeley (Horowitz, Liebman, Ma, Koo, Sangiovanni-Vincentelli, Sastry). Two connected CPUs.



Slide37 l.jpg

Flight Control Software Architecture Abstraction

200 Hz

400 Hz

1 kHz

200 Hz


Slide38 l.jpg

Platform-independent Software Model Abstraction

1. Concurrent periodic tasks:

-sensing -control law computation -actuating

2. Multiple modes of operation:

-navigational modes (autopilot, manual, etc.) -maneuver modes (taxi, takeoff, cruise, etc.) -degraded modes (sensor, actuator, CPU failures)


Slide39 l.jpg

Platform-independent Software Model Abstraction

Mode 1

Mode 2

Condition 1.2

Task S 400 Hz

Task S 400 Hz

Task C 200 Hz

Task C 200 Hz

Task A’ 1 kHz

Task A 1 kHz

Condition 2.1

Task A” 1 kHz

Mode 3

Mode 4

Task S 400 Hz

Task C’ 100 Hz

Task C 200 Hz

Task A 1 kHz

Task A 2 kHz


Slide40 l.jpg

Platform-independent Software Model Abstraction

Functionality.

Timing and interaction.

Host code e.g. C

Glue code e.g. Giotto

-No time. -Sequential.

-Environment time, not platform time. -Concurrency, not distribution.

This kind of software is understood: Host code may (sometimes) be generated automatically.

The software complexity lies in the glue code (minimize jitter!): Giotto enables requirements-driven rather than platform-driven glue-code programming.



Slide42 l.jpg

The Giotto Programmer’s Model Abstraction

Programming in terms of environment time:

Programmer’s fiction: -time-triggered task invocation -tasks are functions with a fixed duration -platform offers sufficient performance

Implementation in terms of platform time:

Compiler must maintain programmer’s fiction: -needs access to global time, no other platform requirements -tasks may finish early, but outputs cannot be observed early -tasks may be preempted and distributed


Slide43 l.jpg

Functional Components Abstraction

  • 1. Units of scheduled host code (application-level tasks). e.g. control law computation

  • 2. Units of synchronous host code (system-level drivers). e.g. device drivers

Input ports

Task

Output ports

Task driver loads task input ports.

Task


Slide44 l.jpg

Environment Timeline (defined by Giotto semantics) Abstraction

Task duration

Actuator

Sensor

Driver

d

Task

Driver execution in environment time 0.

Task execution in environment time d.

Sensor/output ports read.

Input ports loaded.

Output ports read.

Actuator/input ports loaded.

Time t

Time t

Time t+d

Time t+d


Slide45 l.jpg

Platform Timeline (chosen by Giotto compiler) Abstraction

Actuator

Sensor

Driver

d

Task

Task on CPU.

Input ports loaded.

Output ports read.

Time t

Time t

Time t+d

Time t+d


Slide46 l.jpg

Platform Independence ensures Predictability Abstraction

The Giotto compiler chooses for a given platform a platform timeline that is value equivalent to the environment timelinedefined by the Giotto semantics.

Internal Determinism:

For a given sequence of sensor readings, the corresponding sequence of actuator settings is uniquely determined (i.e., there are no race conditions).


Slide47 l.jpg

Simplified Helicopter Software Abstraction

Control

10

a

Actuators

i

5

Navigation

Sensors

s


Slide48 l.jpg

Simplified Helicopter Software Abstraction

Control

10

a

Actuators

i

5

Navigation

Sensors

s

Simulink / legacy design


Slide49 l.jpg

Helicopter Software: Giotto Syntax Abstraction

mode Flight ( )period10ms

{

actfreq 1 do Actuator( actuating ) ;

taskfreq 1 doControl( input );

taskfreq 2 doNavigation ( sensing) ;

}

Control

10

a

i

Navigation

5

s


Slide50 l.jpg

Helicopter Software: Environment Timeline Abstraction

Task

a

i

Control

a

i

s

Navigation

s

Navigation

s

t+5ms

t+5ms

t+10ms

t

t

t+10ms

Block of synchronous code(nonpreemptable)

Scheduled tasks (preemptable)


Slide51 l.jpg

Single-CPU Helicopter: Platform Timeline (EDF) Abstraction

Task

t+5ms

t+10ms

t+10ms

t

t

t+5ms


Slide52 l.jpg

Two-CPU Helicopter: Platform Timeline (Time-triggered Communication)

TDMA Slot

HeliCtr

HeliNet

HeliNav

t+10ms

t

t

t+5ms

t+5ms

t+7ms

t+10ms


Slide53 l.jpg

Two-CPU Helicopter: Platform Timeline (Event-triggered Communication)

Message

HeliCtr

HeliNet

HeliNav

t+5ms

t+5ms

t+10ms

t

t

t+10ms


Slide54 l.jpg

1. The Giotto Programmer’s Model (Event-triggered Communication)

2. The Giotto Compiler


Slide55 l.jpg

The Giotto Compiler (Event-triggered Communication)

Functionality

Native Code

Tasks and Drivers

TimingInteraction

Giotto Program

Platform

Giotto-P

Platform Specification

-topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols)

Giotto Compiler

“Failure”

either Giotto-P overconstrained, or compiler not smart enough (distributed scheduling problem)

Executables

or


Slide56 l.jpg

Closing the Gap: Annotated Giotto (Event-triggered Communication)

Functionality

Native Code

Tasks and Drivers

TimingInteraction

Giotto Program

-topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols)

Platform

Giotto-P

Map

Giotto-PM

-assign tasks to CPUs -assign connections to networks

Giotto Compiler

“Failure”

either Giotto-PM overconstrained, or compiler not smart enough (global scheduling problem)

Executables

or


Slide57 l.jpg

Closing the Gap: Annotated Giotto (Event-triggered Communication)

Functionality

Native Code

Tasks and Drivers

TimingInteraction

Giotto Program

-topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols)

Platform

Giotto-P

Map

Giotto-PM

-assign tasks to CPUs -assign connections to networks

Communication

Giotto-PMC

-assign connections to TDMA slots (say)

Giotto Compiler

“Failure”

Giotto-PMC overconstrained (local scheduling problems solvable)

Executables

or


Slide58 l.jpg

Code Generation (Event-triggered Communication)

Functionality

Native Code

Tasks and Drivers

TimingInteraction

Giotto Program

-topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols)

Platform

Giotto-P

Map

Giotto-PM

-assign tasks to CPUs -assign connections to networks

Communication

Giotto-PMC

-assign connections to TDMA slots (say)

Giotto Compiler

or

“Failure”

VxWorks

OSEK


Slide59 l.jpg

Code Generation: The Embedded Machine (Event-triggered Communication)

Functionality

Native Code

Tasks and Drivers

TimingInteraction

Giotto Program

-topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols)

Platform

Giotto-P

Map

Giotto-PM

-assign tasks to CPUs -assign connections to networks

Communication

Giotto-PMC

-assign connections to TDMA slots (say)

Giotto Compiler

Embedded Machine code

or

“Failure”

Embedded Machine interpreter


Slide60 l.jpg

The Embedded Machine (Event-triggered Communication)

-a virtual machine that mediates the interaction of physical processes (sensors and actuators) and software processes (tasks and drivers) in real time

-the Giotto compiler can be retargeted to a new platform by porting the Embedded Machine


Slide61 l.jpg

The Embedded Machine (Event-triggered Communication)

Environment

Environment Processes: environment time

Software Processes: platform time

Software


Slide62 l.jpg

The Embedded Machine: Time is like Memory (Event-triggered Communication)

Environment

Reactivity: programming in environment time

Embedded Machine

Schedulability: time safety checking for platform time

Software


Slide63 l.jpg

The Embedded Machine (Event-triggered Communication)

Environment Ports

e.g. clock

environment triggers

sense actuate

Driver Ports

Embedded Machine

call drivers

task triggers

read write

schedule tasks

Task Ports

e.g. task completion


Slide64 l.jpg

The Embedded Machine: Three Instructions (Event-triggered Communication)

Call driver:

Schedule task:

call(d)

schedule(T)

T

d

Hand task t over to the system scheduler (RTOS).

Execute driver d now.

Enable trigger:

Have code B executed as soon as trigger g becomes true.

future(g,B:)

g

B:


Slide65 l.jpg

Giotto Code Generation (Event-triggered Communication)

B1: call(actuate)

call(sense)

call(input)

schedule(Control)

schedule(Navigation)

future(now+5, B2:)

relax

Task

a

i

Control

a

i

s

Navigation

s

Navigation

s

t

t

t+5ms

t+5ms

t+10ms

t+10ms


Slide66 l.jpg

Giotto Code Generation (Event-triggered Communication)

B2: call(sense)

schedule(Navigation)

future(now+5, B1:)

relax

Task

a

i

Control

a

i

s

Navigation

s

Navigation

s

t

t

t+5ms

t+5ms

t+10ms

t+10ms


Slide67 l.jpg

Embedded Machine Code combines (Event-triggered Communication)

  • Synchronous code:

    • -Embedded Machine instructions and drivers -kernel context (trigger-related interrupts disabled)

  • Scheduled code:

    • -tasks -user context (trigger-related interrupts enabled)


Slide68 l.jpg

Real-Time Programs (Event-triggered Communication)

  • Task-triggered code:

    • -triggers on environment and task ports -observable behavior depends on environment and scheduler

  • Environment-triggered code:

    • -triggers only on environment ports -observable behavior depends on environment only

All Giotto programs result in environment-triggered code.


Slide69 l.jpg

Real-Time Programs (Event-triggered Communication)

  • Time-safe code:

    • No driver accesses a scheduled task before completion.

  • Time-live code:

    • There is no infinite synchronous computation.

All Giotto programs result in time-live code. Time safety is checked by the Giotto compiler.

Alternatively, time safety violations can be can be handled through run-time exceptions.


Slide70 l.jpg

Real-Time Programs (Event-triggered Communication)

Time Safety:

Violations due to combination of -insufficient synchrony (environment events too frequent) -insufficient platform utilization (scheduler too weak) -insufficient platformperformance (hardware too slow)

Our approach systematically integratessynchronous programming and scheduling theory.


Slide71 l.jpg

Distributed Giotto Compiler (Event-triggered Communication)

Giotto Program

Giotto Compiler

E Code


Slide72 l.jpg

Distributed Giotto Compiler (Event-triggered Communication)

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

Proof of Time Safety = Schedule


Slide73 l.jpg

Schedule-Carrying Code (Event-triggered Communication)

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

+

Proof of Time Safety (Schedule)


Slide74 l.jpg

Schedule-Carrying Code (Event-triggered Communication)

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

+

S Code (Executable Schedule)


Slide75 l.jpg

Giotto Code Generation (Event-triggered Communication)

B1: call(actuate)

call(sense)

call(input)

schedule(Control)

schedule(Navigation)

future(now+5, B2:)

relax

Task

a

i

Control

a

i

s

Navigation

s

Navigation

s

t

t

t+5ms

t+5ms

t+10ms

t+10ms


Slide76 l.jpg

Giotto EDF Schedule Generation (Event-triggered Communication)

B1: call(actuate)

call(sense)

call(input)

schedule(Control)

schedule(Navigation)

future(now+5, B2:)

dispatch(Navigation,now+5)

dispatch(Control,now+5)

idle(now+5)

Task

a

i

Control

a

i

s

Navigation

s

Navigation

s

t

t

t+5ms

t+5ms

t+10ms

t+10ms


Slide77 l.jpg

Advantages of SCC (Schedule-Carrying Code) (Event-triggered Communication)

Advantages of PCC:

-schedule generation is harder than schedule validation (nonpreemptive or distributed case: NP-hard vs. linear)

-once generated, schedule can be reused

-compiler does not need to be trusted


Slide78 l.jpg

Advantages of SCC (Schedule-Carrying Code) (Event-triggered Communication)

Advantages of PCC:

-schedule generation is harder than schedule validation (nonpreemptive or distributed case: NP-hard vs. linear)

-once generated, schedule can be reused

-compiler does not need to be trusted

Advantages of Executability:

-flexible scheduling scheme

-no system scheduler (RTOS) necessary

-overhead reduction of up to 80%


Slide79 l.jpg

The Giotto Project (Event-triggered Communication)

www.eecs.berkeley.edu/~tah/giotto

Software Tools:

Simulink to Giotto translator (Pree) Giotto to E code compiler (Kirsch) E Machine on Linux, VxWorks, OSEK (Kirsch) S code time safety checker (Matic) Integrated E and S machine on StrongARM (Kirsch, Sanvido) Event-triggered xGiotto (Ghosal, Sanvido)

Applications:

Lego Mindstorms (Horowitz, Kirsch, Majumdar) Zurich helicopter (Kirsch, Sanvido)Berkeley helicopter (Horowitz, Liebman, Ma, Sastry) BMW electronic throttle control (Kirsch, Pree)


Slide80 l.jpg

GIOTTO (Event-triggered Communication): FLET for periodic tasks with time-triggered mode switching

Mode 2

Mode 1

Task S Task C Condition 1.2


Slide81 l.jpg

xGIOTTO (Event-triggered Communication): General (event-triggered) FLET programming

  • Schedule Instruction:

    • scheduleTaskby Event;

  • Reaction Block:

    • react {when EventdoBlock ; wheneverEventdoBlock ; begin … end ; } untilEvent ;

  • logical deadline


    Slide82 l.jpg

    xGIOTTO (Event-triggered Communication): General (event-triggered) FLET programming

    If all events can happen at any time, then few programs would be time-safe.

    However, nested reaction blocks can be used for event scoping (i.e., not all events are listened to all the time).


    Slide83 l.jpg

    xGIOTTO (Event-triggered Communication): General (event-triggered) FLET programming

    If all events can happen at any time, then few programs would be time-safe.

    However, nested reaction blocks can be used for event scoping (i.e., not all events are listened to all the time).

    xGiotto = Structured Real-Time Programming


    Slide84 l.jpg

    The Giotto Project (Event-triggered Communication)

    www.eecs.berkeley.edu/~tah/giotto

    Participants:

    Ben Horowitz Arkadeb Ghosal Christoph Kirsch Slobodan Matic Marco Sanvido

    Sponsors:

    DARPA SEC (Software-Enabled Control) NSF CHESS (Center for Hybrid & Embedded Software Systems)