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

About This Presentation
Title:

The Fixed Logical Execution Time (FLET) Assumption

Description:

sensing -control law computation -actuating. 2. Multiple modes of ... sense actuate. read write. call drivers. The Embedded Machine. schedule tasks. e.g. clock ... – PowerPoint PPT presentation

Number of Views:56
Avg rating:3.0/5.0
Slides: 85
Provided by: tah96
Learn more at: https://www.cs.uic.edu
Category:

less

Transcript and Presenter's Notes

Title: The Fixed Logical Execution Time (FLET) Assumption


1
The
Fixed Logical Execution Time
(FLET) Assumption
Tom Henzinger
University of California, Berkeley
2
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
3
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
4
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
5
Current Practice in Embedded Software Design
Mathematical models
(e.g. Simulink)
Code generation difficult
Code verification difficult
Efficient code
(scheduled by RTOS)
6
Advocated Practice in Embedded Software Design
Mathematical models
(e.g. Simulink)
The missing link
platform-independent programming model
Efficient code
(possibly schedule-carrying)
7
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)
8
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)
9
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)
10
Advocated Practice in Embedded Software Design
Requirement A
Requirement B

Program A
Program B

Compositionality
Platform P
11
Advocated Practice in Embedded Software Design
Requirement A
Requirement B'

Program A
Program B'

Compositionality
Platform P
12
Advocated Practice in Embedded Software Design
Requirement A
Program A
Portability
Platform P
Platform Q
13
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
14
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
15
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

16
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

17
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)
18
First Attempt
Mathematical models
(e.g. Simulink)
The missing link
platform-independent programming model
Priorities
Efficient code
(scheduled by RTOS)
19
First Attempt
Mathematical models
(e.g. Simulink)
Not sufficiently abstract -not about environment
time -not compositional
Programming model
Priorities
Efficient code
(scheduled by RTOS)
20
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!
21
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)
22
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)
23
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?
24
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)
25
The FLET (Fixed Logical Execution Time) Assumption
Software Task
write actuator output at time td, for fixed d
read sensor input at time t
26
The FLET (Fixed Logical Execution Time) Assumption
Software Task
write actuator output at time td, for fixed d
dgt0 is the task's "logical execution time"
read sensor input at time t
27
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.
28
The FLET (Fixed Logical Execution Time) Assumption
time t
time td
possible physical execution on CPU
buffer output
29
Portability
50 CPU speedup
30
Composability
Task 1
Task 2
31
Verifiability through Predictability (Internal
Determinism)
-timing predictability minimal jitter
-function
predictability no race conditions

32
Contrast FLET with Standard Practice
output as soon as ready
33
Contrast FLET with Standard Practice
Race
34
yes but, what about the sacrifice in
performance ?!
35
Test Case Flight Control Software
UC Berkeley (Horowitz, Liebman, Ma, Koo,
Sangiovanni-Vincentelli, Sastry). Two connected
CPUs.
36
Flight Control Software Architecture
37
Flight Control Software Architecture
200 Hz
400 Hz
200 Hz
1 kHz
38
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)
39
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 4
Mode 3
Task S 400 Hz
Task C 100 Hz
Task C 200 Hz
Task A 1 kHz
Task A 2 kHz
40
Platform-independent Software Model
Functionality.
Timing and interaction.
Host code e.g. C
Glue code e.g. Giotto
-Environment time, not platform time.
-Concurrency, not distribution.
-No time. -Sequential.
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.
41
1. The Giotto Programmers Model
Time-triggered FLET 2. The Giotto
Compiler
42
The Giotto Programmers Model
Programming in terms of environment time
Programmers 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 programmers
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
43
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

Task
Input ports
Output ports
Task driver loads task input ports.
Task
44
Environment Timeline (defined by Giotto semantics)
Task duration
Actuator
Driver
Sensor
d
Task
Driver execution in environment time 0.
Task execution in environment time d.
Input ports loaded.
Output ports read.
Sensor/output ports read.
Actuator/input ports loaded.
Time t
Time t
Time td
Time td
45
Platform Timeline (chosen by Giotto compiler)
Actuator
Driver
Sensor
d
Task
Task on CPU.
Input ports loaded.
Output ports read.
Time t
Time t
Time td
Time td
46
Platform Independence ensures Predictability
The Giotto compiler chooses for a given platform
a platform timeline that is value equivalent to
the environment timeline defined 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).
47
Simplified Helicopter Software
Control
10
Actuators
a
i
5
Navigation
Sensors
s
48
Simplified Helicopter Software
Control
10
Actuators
a
i
5
Navigation
Sensors
s
Simulink / legacy design
49
Helicopter Software Giotto Syntax
mode Flight ( ) period 10ms
actfreq 1 do Actuator ( actuating )
taskfreq 1 do Control ( input )
taskfreq 2 do Navigation ( sensing )
Control
10
a
i
Navigation
5
s
50
Helicopter Software Environment Timeline
Task
a
i
a
Control
i
s
Navigation
Navigation
s
s
t10ms
t5ms
t5ms
t10ms
t
t
Block of synchronous code (nonpreemptable)
Scheduled tasks (preemptable)
51
Single-CPU Helicopter Platform Timeline (EDF)
Task







t10ms
t10ms
t5ms
t
t
t5ms
52
Two-CPU Helicopter Platform Timeline
(Time-triggered Communication)
TDMA Slot




HeliCtr
HeliNet



HeliNav
t10ms
t10ms
t
t
t5ms
t5ms
t7ms
53
Two-CPU Helicopter Platform Timeline
(Event-triggered Communication)
Message




HeliCtr
HeliNet



HeliNav
t5ms
t5ms
t10ms
t10ms
t
t
54
1. The Giotto Programmers Model
2. The Giotto Compiler
55
The Giotto Compiler
Native Code
Tasks and Drivers
Functionality
Timing Interaction
Giotto Program
Giotto-P
Platform Specification -topology (CPUs, networks)
-performance (WCETs,
latencies) -APIs (RTOSs, protocols)
Platform
Giotto Compiler
Failure either Giotto-P overconstrained, or
compiler not smart enough (distributed scheduling
problem)
Executables
or
56
Closing the Gap Annotated Giotto
Native Code
Tasks and Drivers
Functionality
Timing Interaction
Giotto Program
-topology (CPUs, networks) -performance
(WCETs, latencies) -APIs (RTOSs, protocols)
Giotto-P
Platform
Giotto-PM
-assign tasks to CPUs -assign connections to
networks
Map
Giotto Compiler
Failure either Giotto-PM overconstrained, or
compiler not smart enough (global
scheduling problem)
Executables
or
57
Closing the Gap Annotated Giotto
Native Code
Tasks and Drivers
Functionality
Timing Interaction
Giotto Program
-topology (CPUs, networks) -performance
(WCETs, latencies) -APIs (RTOSs, protocols)
Giotto-P
Platform
Giotto-PM
Map
-assign tasks to CPUs -assign connections to
networks
Giotto-PMC
Communication
-assign connections to TDMA slots (say)
Giotto Compiler
Failure Giotto-PMC overconstrained (local
scheduling problems solvable)
Executables
or
58
Code Generation
Native Code
Tasks and Drivers
Functionality
Timing Interaction
Giotto Program
-topology (CPUs, networks) -performance
(WCETs, latencies) -APIs (RTOSs, protocols)
Giotto-P
Platform
Giotto-PM
Map
-assign tasks to CPUs -assign connections to
networks
Giotto-PMC
Communication
-assign connections to TDMA slots (say)
Giotto Compiler
or
Failure
VxWorks
OSEK

59
Code Generation The Embedded Machine
Native Code
Tasks and Drivers
Functionality
Timing Interaction
Giotto Program
-topology (CPUs, networks) -performance
(WCETs, latencies) -APIs (RTOSs, protocols)
Giotto-P
Platform
Giotto-PM
Map
-assign tasks to CPUs -assign connections to
networks
Giotto-PMC
Communication
-assign connections to TDMA slots (say)
Giotto Compiler
Embedded Machine code
or
Failure
Embedded Machine interpreter
60
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
61
The Embedded Machine
Environment
Environment Processes environment time
Software Processes platform time
Software
62
The Embedded Machine Time is like Memory
Environment
Reactivity programming in environment time
Embedded Machine
Schedulability time safety checking for platform
time
Software
63
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
64
The Embedded Machine Three Instructions
Schedule task
Call driver
schedule(T)
call(d)
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)
B
g
65
Giotto Code Generation
B1 call(actuate) call(sense) call(input) s
chedule(Control) schedule(Navigation) future(n
ow5, B2) relax
Task
a
i
a
Control
i
s
Navigation
Navigation
s
s
t
t
t5ms
t5ms
t10ms
t10ms
66
Giotto Code Generation
B2 call(sense) schedule(Navigation) future(n
ow5, B1) relax
Task
a
i
a
Control
i
s
Navigation
Navigation
s
s
t
t
t10ms
t10ms
t5ms
t5ms
67
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)
68
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-triggere
d code.
69
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.
70
Real-Time Programs
Time Safety Violations due to combination of
-insufficient synchrony
(environment events too frequent) -insufficient
platform utilization (scheduler too weak)
-insufficient platform performance (hardware too
slow)
Our approach systematically integrates
synchronous programming and scheduling theory.

71
Distributed Giotto Compiler
Giotto Program
Giotto Compiler
E Code
72
Distributed Giotto Compiler
Giotto Program
Giotto-P Platform Spec
Giotto Compiler with Time Safety Checker
E Code
Proof of Time Safety Schedule
73
Schedule-Carrying Code
Giotto Program
Giotto-P Platform Spec
Giotto Compiler with Time Safety Checker
E Code
Proof of Time Safety (Schedule)

74
Schedule-Carrying Code
Giotto Program
Giotto-P Platform Spec
Giotto Compiler with Time Safety Checker
E Code
S Code (Executable Schedule)

75
Giotto Code Generation
B1 call(actuate) call(sense) call(input) s
chedule(Control) schedule(Navigation) future(n
ow5, B2) relax
Task
a
i
a
Control
i
s
Navigation
Navigation
s
s
t
t
t5ms
t5ms
t10ms
t10ms
76
Giotto EDF Schedule Generation
B1 call(actuate) call(sense) call(input) s
chedule(Control) schedule(Navigation) future(n
ow5, B2) dispatch(Navigation,
now5) dispatch(Control, now5) idle(now5)
Task
a
i
a
Control
i
s
Navigation
Navigation
s
s
t
t
t5ms
t5ms
t10ms
t10ms
77
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
78
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
79
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) Integrat
ed 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)
80
GIOTTO

FLET for periodic tasks with time-triggered mode
switching
Mode 2
Mode 1
Task S Task C Condition 1.2
81
xGIOTTO

General (event-triggered) FLET programming
  • Schedule Instruction
  • schedule Task by Event
  • Reaction Block
  • react when Event do Block
    whenever Event do Block begin end
    until Event

logical deadline
82
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).
83
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
84
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)
Write a Comment
User Comments (0)
About PowerShow.com