slide1
Download
Skip this Video
Download Presentation
The Fixed Logical Execution Time (FLET) Assumption

Loading in 2 Seconds...

play fullscreen
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

The Fixed Logical Execution Time (FLET) Assumption

Tom Henzinger University of California, Berkeley

slide2

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

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

Current Practice in Embedded Software Design

-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

Current Practice in Embedded Software Design

Mathematical models (e.g. Simulink)

Code generation difficult

Code verification difficult

Efficient code (scheduled by RTOS)

slide6

Advocated Practice in Embedded Software Design

Mathematical models (e.g. Simulink)

The missing link: platform-independent programming model

Efficient code (possibly schedule-carrying)

slide7

Advocated Practice in Embedded Software Design

Mathematical models (e.g. Simulink)

Verification

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

slide8

Advocated Practice in Embedded Software Design

Mathematical models (e.g. Simulink)

Verification

-verifiable -reusable-efficiently implementable

The missing link: platform-independent programming model

Compilation

Efficient code (possibly schedule-carrying)

slide9

Advocated Practice in Embedded Software Design

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

Advocated Practice in Embedded Software Design

Requirement A

Requirement B

+

Program A

Program B

+

Compositionality

Platform P

slide11

Advocated Practice in Embedded Software Design

Requirement A

Requirement B\'

+

Program A

Program B\'

+

Compositionality

Platform P

slide12

Advocated Practice in Embedded Software Design

Requirement A

Program A

Portability

Platform P

Platform Q

slide13

Advocated Practice in Embedded Software Design

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

Advocated Practice in Embedded Software Design

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

Advocated Practice in Embedded Software Design

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

Advocated Practice in Embedded Software Design

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

Advocated Practice in Embedded Software Design

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

First Attempt

Mathematical models (e.g. Simulink)

The missing link: platform-independent programming model

Priorities

Efficient code (scheduled by RTOS)

slide19

First Attempt

Mathematical models (e.g. Simulink)

Not sufficiently abstract

-not about environment time -not compositional

Programming model: Priorities

Efficient code (scheduled by RTOS)

slide20

First Attempt

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

Second Attempt

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

Second Attempt

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

Second Attempt

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

Our Attempt

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

The FLET (Fixed Logical Execution Time) Assumption

Software Task

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

read sensor input at time t

slide26

The FLET (Fixed Logical Execution Time) Assumption

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

The FLET Programming Model

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

The FLET (Fixed Logical Execution Time) Assumption

time t

time t+d

possible physical execution on CPU

buffer output

slide29

Portability

50% CPU speedup

slide30

Composability

Task 1

Task 2

slide31

Verifiability through Predictability (Internal Determinism)

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

slide35

Test Case: Flight Control Software

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

slide38

Platform-independent Software Model

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

Platform-independent Software Model

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

Platform-independent Software Model

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

The Giotto Programmer’s Model

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

Functional Components

  • 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

Environment Timeline (defined by Giotto semantics)

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

Platform Timeline (chosen by Giotto compiler)

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

Platform Independence ensures Predictability

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

Simplified Helicopter Software

Control

10

a

Actuators

i

5

Navigation

Sensors

s

slide48

Simplified Helicopter Software

Control

10

a

Actuators

i

5

Navigation

Sensors

s

Simulink / legacy design

slide49

Helicopter Software: Giotto Syntax

mode Flight ( )period10ms

{

actfreq 1 do Actuator( actuating ) ;

taskfreq 1 doControl( input );

taskfreq 2 doNavigation ( sensing) ;

}

Control

10

a

i

Navigation

5

s

slide50

Helicopter Software: Environment Timeline

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)

slide52

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

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

Message

HeliCtr

HeliNet

HeliNav

t+5ms

t+5ms

t+10ms

t

t

t+10ms

slide55

The Giotto Compiler

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

Closing the Gap: Annotated Giotto

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

Closing the Gap: Annotated Giotto

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

Code Generation

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

Code Generation: The Embedded Machine

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

The Embedded Machine

-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

The Embedded Machine

Environment

Environment Processes: environment time

Software Processes: platform time

Software

slide62

The Embedded Machine: Time is like Memory

Environment

Reactivity: programming in environment time

Embedded Machine

Schedulability: time safety checking for platform time

Software

slide63

The Embedded Machine

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

The Embedded Machine: Three Instructions

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

Giotto Code Generation

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

Giotto Code Generation

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

Embedded Machine Code combines

  • Synchronous code:
    • -Embedded Machine instructions and drivers -kernel context (trigger-related interrupts disabled)
  • Scheduled code:
    • -tasks -user context (trigger-related interrupts enabled)
slide68

Real-Time Programs

  • 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

Real-Time Programs

  • 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

Real-Time Programs

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

Distributed Giotto Compiler

Giotto Program

Giotto Compiler

E Code

slide72

Distributed Giotto Compiler

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

Proof of Time Safety = Schedule

slide73

Schedule-Carrying Code

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

+

Proof of Time Safety (Schedule)

slide74

Schedule-Carrying Code

Giotto Program

Giotto-P Platform Spec

Giotto Compiler with Time Safety Checker

E Code

+

S Code (Executable Schedule)

slide75

Giotto Code Generation

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

Giotto EDF Schedule Generation

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

Advantages of SCC (Schedule-Carrying Code)

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

Advantages of SCC (Schedule-Carrying Code)

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

The Giotto Project

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

GIOTTO: FLET for periodic tasks with time-triggered mode switching

Mode 2

Mode 1

Task S Task C Condition 1.2

slide81

xGIOTTO: General (event-triggered) FLET programming

  • Schedule Instruction:
      • scheduleTaskby Event;
  • Reaction Block:
      • react {when EventdoBlock ; wheneverEventdoBlock ; begin … end ; } untilEvent ;

logical deadline

slide82

xGIOTTO: 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

xGIOTTO: 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

The Giotto Project

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)

ad