The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley.

Slides:



Advertisements
Similar presentations
Simulation of Feedback Scheduling Dan Henriksson, Anton Cervin and Karl-Erik Årzén Department of Automatic Control.
Advertisements

Flexible Scheduling of Software with Logical Execution Time Constraints* Stefan Resmerita and Patricia Derler University of Salzburg, Austria *UC Berkeley,
A Hierarchical Co-ordination Language for Interacting Real-time Tasks Arkadeb Ghosal, UC Berkeley Thomas A. Henzinger, EPFL Daniel Iercan, "Politehnica"
Undoing the Task: Moving Timing Analysis back to Functional Models Marco Di Natale, Haibo Zeng Scuola Superiore S. Anna – Pisa, Italy McGill University.
Introduction CSCI 444/544 Operating Systems Fall 2008.
Time Safety Checking for Embedded Programs Thomas A. Henzinger, Christoph M. Kirsch, Rupak Majumdar and Slobodan Matic.
Event Driven Real-Time Programming CHESS Review University of California, Berkeley, USA May 10, 2004 Arkadeb Ghosal Joint work with Marco A. Sanvido, Christoph.
Overview of PTIDES Project
Synthesis of Embedded Software Using Free-Choice Petri Nets.
Page 1 Building Reliable Component-based Systems Chapter 16 - Component based embedded systems Chapter 16 Component based embedded systems.
Architecture Modeling and Analysis for Embedded Systems Oleg Sokolsky CIS700 Fall 2005.
Integrated Design and Analysis Tools for Software-Based Control Systems Shankar Sastry (PI) Tom Henzinger Edward Lee University of California, Berkeley.
NSF Foundations of Hybrid and Embedded Software Systems UC Berkeley: Chess Vanderbilt University: ISIS University of Memphis: MSI A New System Science.
April 16, 2009 Center for Hybrid and Embedded Software Systems PtidyOS: An Operating System based on the PTIDES Programming.
Scheduling for Embedded Real-Time Systems Amit Mahajan and Haibo.
From Models to Code: The Missing Link in Embedded Software Tom Henzinger University of California, Berkeley Joint work with Ben Horowitz and Christoph.
Chess Review May 11, 2005 Berkeley, CA Composable Code Generation for Distributed Giotto Tom Henzinger Christoph Kirsch Slobodan Matic.
Chess Review May 10, 2004 Berkeley, CA Distributed Schedule-Carrying Code Tom Henzinger Slobodan Matic.
Chapter 13 Embedded Systems
Design of Fault Tolerant Data Flow in Ptolemy II Mark McKelvin EE290 N, Fall 2004 Final Project.
Expressing Giotto in xGiotto and related schedulability problems Class Project Presentation Concurrent Models of Computation for Embedded Software University.
1 of 14 1 Analysis and Synthesis of Communication-Intensive Heterogeneous Real-Time Systems Paul Pop Computer and Information Science Dept. Linköpings.
Giotto A Time-Triggered Language for Embedded Programming Thomas A. Henzinger, Benjamin Horowitz Christoph M. Kirsch, Rupak Majumdar UC Berkeley.
NSF Foundations of Hybrid and Embedded Software Systems UC Berkeley: Chess Vanderbilt University: ISIS University of Memphis: MSI A New System Science.
NSF Foundations of Hybrid and Embedded Software Systems UC Berkeley: Chess Vanderbilt University: ISIS University of Memphis: MSI Hybrid Systems: From.
Interfaces for Control Components Rajeev Alur University of Pennsylvania Joint work with Gera Weiss (and many others)
7th Biennial Ptolemy Miniconference Berkeley, CA February 13, 2007 PTIDES: A Programming Model for Time- Synchronized Distributed Real-time Systems Yang.
Designing Predictable and Robust Systems Tom Henzinger UC Berkeley and EPFL.
November 18, 2004 Embedded System Design Flow Arkadeb Ghosal Alessandro Pinto Daniele Gasperini Alberto Sangiovanni-Vincentelli
By Group: Ghassan Abdo Rayyashi Anas to’meh Supervised by Dr. Lo’ai Tawalbeh.
CprE 458/558: Real-Time Systems
Misconceptions About Real-time Computing : A Serious Problem for Next-generation Systems J. A. Stankovic, Misconceptions about Real-Time Computing: A Serious.
MOBIES Project Progress Report Engine Throttle Controller Design Using Multiple Models of Computation Edward Lee Haiyang Zheng with thanks to Ptolemy Group.
1 Chapter 13 Embedded Systems Embedded Systems Characteristics of Embedded Operating Systems.
Giotto and TMO Yerang Hur System Design Research Lab. Dept. of Computer and Information Science.
Copyright Arshi Khan1 System Programming Instructor Arshi Khan.
EMBEDDED SOFTWARE Team victorious Team Victorious.
Performance Evaluation of Real-Time Operating Systems
©Ian Sommerville 2004Software Engineering, 7th edition. Chapter 15 Slide 1 Real-time Systems 1.
Computer System Architectures Computer System Software
Real-Time Software Design Yonsei University 2 nd Semester, 2014 Sanghyun Park.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Advanced Operating Systems CIS 720 Lecture 1. Instructor Dr. Gurdip Singh – 234 Nichols Hall –
Introduction and Overview Questions answered in this lecture: What is an operating system? How have operating systems evolved? Why study operating systems?
1 CS 501 Spring 2003 CS 501: Software Engineering Lecture 16 System Architecture and Design II.
Proof Carrying Code Zhiwei Lin. Outline Proof-Carrying Code The Design and Implementation of a Certifying Compiler A Proof – Carrying Code Architecture.
1 of 14 1/15 Synthesis-driven Derivation of Process Graphs from Functional Blocks for Time-Triggered Embedded Systems Master thesis Student: Ghennadii.
Scheduling policies for real- time embedded systems.
Giotto A tool-supported design methodology for developing hard real-time applications Cyber Physical Systems Lab Ramtin Raji Kermani.
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Reference: Ian Sommerville, Chap 15  Systems which monitor and control their environment.  Sometimes associated with hardware devices ◦ Sensors: Collect.
REAL-TIME SOFTWARE SYSTEMS DEVELOPMENT Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Operating Systems David Goldschmidt, Ph.D. Computer Science The College of Saint Rose CIS 432.
Conformance Test Experiments for Distributed Real-Time Systems Rachel Cardell-Oliver Complex Systems Group Department of Computer Science & Software Engineering.
> Power Supervison Desired Output level Source Diesel Valve Sink Diesel Valve > Valve Regulator Sink T = 40 ms Air Valve CBSE Course The SaveComp Component.
Chapter 1 Basic Concepts of Operating Systems Introduction Software A program is a sequence of instructions that enables the computer to carry.
Real-Time Operating System Design
CIS 540 Principles of Embedded Computation Spring Instructor: Rajeev Alur
Embedded Computer - Definition When a microcomputer is part of a larger product, it is said to be an embedded computer. The embedded computer retrieves.
T imed Languages for Embedded Software Ethan Jackson Advisor: Dr. Janos Szitpanovits Institute for Software Integrated Systems Vanderbilt University.
Agenda  Quick Review  Finish Introduction  Java Threads.
Unit - I Real Time Operating System. Content : Operating System Concepts Real-Time Tasks Real-Time Systems Types of Real-Time Tasks Real-Time Operating.
Giotto Embedded Control Systems Development with Thomas A. Henzinger Ben Horowitz Christoph M. Kirsch University of California, Berkeley
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Operating Systems Overview: Using Hardware.
Programming 2 Intro to Java Machine code Assembly languages Fortran Basic Pascal Scheme CC++ Java LISP Smalltalk Smalltalk-80.
Embedded Control System Development with Giotto Thomas A. Henzinger, Benjamin Horowitz, Christoph Meyer Kirsch UC Berkeley.
Real-Time Operating Systems RTOS For Embedded systems.
Real-time Software Design
Shanna-Shaye Forbes Ben Lickly Man-Kit Leung
Chapter 13: I/O Systems.
Presentation transcript:

The Fixed Logical Execution Time (FLET) Assumption Tom Henzinger University of California, Berkeley

The History of Computer Science: Lifting the Level of Abstraction The “assembly age”: Programming to the platform High-level languages: Programming to the application Compilation: perhaps “the” success story of computer science It is feasible to abstract the platform.

The History of Computer Science: Lifting the Level of Abstraction The “assembly age”: Programming to the platform High-level languages: Programming to the application Automatic program synthesis: No more programming Compilation: perhaps “the” success story of computer science Code generation from specifications: still mostly a dream It is feasible to abstract the platform. It is not feasible to abstract algorithms and data structures.

Current Practice in Embedded Software Design Some manual programming to the platform Some automatic code generation from models -often inefficient -often unpredictable -e.g. Real-Time Workshop -difficult to reuse -difficult to verify -requires systems experts

Current Practice in Embedded Software Design Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Code verification difficult Code generation difficult

Advocated Practice in Embedded Software Design Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -verifiable -reusable -efficiently implementable Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -verifiable -reusable -efficiently implementable Reusable = composable + portable Advocated Practice in Embedded Software Design

Platform P Requirement A Program A Advocated Practice in Embedded Software Design Requirement B Program B + + Compositionality

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

Requirement A Platform P Advocated Practice in Embedded Software Design Platform Q Portability Program A

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -concurrency -environment time -distribution -platform (CPU) time Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -concurrency -environment time -distribution -platform (CPU) time -concurrency -environment time Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -descriptive -mathematics / logic -prescriptive -algorithms + data structures -concurrency -environment time Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation -descriptive -mathematics -prescriptive -algorithms + data structures -concurrency -environment time -prescriptive -virtual machine Advocated Practice in Embedded Software Design

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Verification Compilation Advocated Practice in Embedded Software Design e.g. What is the control equation? What is the sampling rate? e.g. Which procedure computes the control equation? Which event triggers the computation? e.g. Which CPU executes the control procedure? What priority has the execution?

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model First Attempt Priorities

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Programming model: Priorities First Attempt Not sufficiently abstract -not about environment time -not compositional

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Programming model: Priorities First Attempt Not sufficiently abstract -not about environment time -not compositional Scheduling theory Correctness? Efficiency!

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Second Attempt Synchrony assumption: platform time infinitely faster than environment time

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Synchronous programming languages (Esterel, Lustre, Signal, etc.) Second Attempt Too abstract difficult to compile to resource-constrained, distributed platforms

Efficient code (scheduled by RTOS) Mathematical models (e.g. Simulink) Synchronous programming languages (Esterel, Lustre, Signal, etc.) Second Attempt Too abstract difficult to compile to resource-constrained, distributed platforms Correctness! Efficiency?

Efficient code (possibly schedule-carrying) Mathematical models (e.g. Simulink) The missing link: platform-independent programming model Our Attempt FLET assumption: -verifiable -efficiently implementable -composable -portable

The FLET (Fixed Logical Execution Time) Assumption Software Task read sensor input at time t write actuator output at time t+d, for fixed d

Software Task read sensor input at time t write actuator output at time t+d, for fixed d d>0 is the task's "logical execution time" The FLET (Fixed Logical Execution Time) Assumption

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. The FLET Programming Model

time ttime t+d possible physical execution on CPU buffer output The FLET (Fixed Logical Execution Time) Assumption

50% CPU speedup Portability

Task 2 Task 1 Composability

-timing predictability: minimal jitter -function predictability: no race conditions Verifiability through Predictability (Internal Determinism)

output as soon as ready Contrast FLET with Standard Practice

Race Contrast FLET with Standard Practice

… yes but, what about the sacrifice in performance ?!

Test Case: Flight Control Software UC Berkeley (Horowitz, Liebman, Ma, Koo, Sangiovanni-Vincentelli, Sastry). Two connected CPUs.

Flight Control Software Architecture

200 Hz 400 Hz 200 Hz 1 kHz Flight Control Software Architecture

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) Platform-independent Software Model

Mode 1 Mode 4Mode 3 Mode 2 Task S 400 Hz Task C 200 Hz Task A 1 kHz Task S 400 Hz Task C 200 Hz Task A’ 1 kHz Task C’ 100 Hz Task A 1 kHz Task S 400 Hz Task C 200 Hz Task A 2 kHz Task A” 1 kHz Condition 1.2 Condition 2.1 Platform-independent Software Model

Host code e.g. C Glue code e.g. Giotto Functionality. -Environment time, not platform time. -Concurrency, not distribution. Platform-independent Software Model Timing and interaction. 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. -No time. -Sequential.

1. The Giotto Programmer’s Model: Time-triggered FLET 2. The Giotto Compiler

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

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 portsOutput ports Task Task driver loads task input ports. Functional Components

Task Driver Input ports loaded. Driver execution in environment time 0. Task execution in environment time d. Output ports read. Sensor/output ports read. Sensor Actuator Actuator/input ports loaded. Time t Time t+d d Task duration Environment Timeline (defined by Giotto semantics)

Task Driver Input ports loaded. Output ports read. Sensor Time t Time t+d d Task on CPU. Actuator Platform Timeline (chosen by Giotto compiler)

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). Platform Independence ensures Predictability

Navigation Control Simplified Helicopter Software Sensors Actuators i s a 10 5

Navigation Control Simplified Helicopter Software Sensors Actuators i s a 10 5 Simulink / legacy design

… mode Flight ( ) period 10ms { actfreq 1 do Actuator ( actuating ) ; taskfreq 1 do Control ( input ) ; taskfreq 2 do Navigation ( sensing ) ; } … Helicopter Software: Giotto Syntax Navigation Control i s a 10 5

aia t+10ms s Task Navigation Control t+10ms tt t+5ms i ss Helicopter Software: Environment Timeline Block of synchronous code (nonpreemptable) Scheduled tasks (preemptable)

t+10ms Task t+10ms tt t+5ms Single-CPU Helicopter: Platform Timeline (EDF)

t+10ms ttt+5ms t+7ms HeliCtr HeliNav TDMA Slot HeliNet Two-CPU Helicopter: Platform Timeline (Time-triggered Communication)

t+10mstt t+5ms HeliCtr HeliNav Message HeliNet Two-CPU Helicopter: Platform Timeline (Event-triggered Communication) t+10ms

1. The Giotto Programmer’s Model 2. The Giotto Compiler

The Giotto Compiler Giotto Program Native Code Tasks and Drivers Giotto-P Platform Specification -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) Executables Giotto Compiler Functionality Timing Interaction Platform “Failure” either Giotto-P overconstrained, or compiler not smart enough (distributed scheduling problem) or

Closing the Gap: Annotated Giotto Giotto Program Native Code Tasks and Drivers Giotto-P -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) Executables Giotto Compiler Functionality Timing Interaction Platform “Failure” either Giotto-PM overconstrained, or compiler not smart enough (global scheduling problem) or Giotto-PM -assign tasks to CPUs -assign connections to networks Map

Closing the Gap: Annotated Giotto Giotto Program Native Code Tasks and Drivers Giotto-P Executables Giotto Compiler Functionality Timing Interaction Platform “Failure” Giotto-PMC overconstrained (local scheduling problems solvable) or Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks

Code Generation Giotto Program Native Code Tasks and Drivers Giotto-P Giotto Compiler Functionality Timing Interaction Platform Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks or “Failure” VxWorksOSEK …

Code Generation: The Embedded Machine Giotto Program Native Code Tasks and Drivers Giotto-P Embedded Machine code Giotto Compiler Functionality Timing Interaction Platform or Giotto-PM Map Giotto-PMC Communication -assign connections to TDMA slots (say) -topology (CPUs, networks) -performance (WCETs, latencies) -APIs (RTOSs, protocols) -assign tasks to CPUs -assign connections to networks “Failure” Embedded Machine interpreter

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

Environment Software Software Processes: platform time Environment Processes: environment time The Embedded Machine

Environment Software Schedulability: time safety checking for platform time Reactivity: programming in environment time The Embedded Machine: Time is like Memory Embedded Machine

Environment Ports Task Ports Driver Ports Embedded Machine task triggers environment triggers sense actuate read write call drivers The Embedded Machine schedule tasks e.g. clock e.g. task completion

Enable trigger: future( g,B:) B: Schedule task: schedule( T ) T Call driver: call( d ) d g The Embedded Machine: Three Instructions Execute driver d now. Hand task t over to the system scheduler (RTOS). Have code B executed as soon as trigger g becomes true.

ai a t+10ms s Task Navigation Control t+10ms ttt+5ms i ss B1:call( actuate ) call( sense ) call( input ) schedule( Control ) schedule( Navigation ) future( now+5, B2:) relax Giotto Code Generation

ai a t+10ms s Task Navigation Control t+10ms tt t+5ms i ss B2:call( sense ) schedule( Navigation ) future( now+5, B1:) relax Giotto Code Generation

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)

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.

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.

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.

Distributed Giotto Compiler Giotto Compiler Giotto Program E Code

Distributed Giotto Compiler Giotto Compiler with Time Safety Checker Giotto Program E Code Giotto-P Platform Spec Proof of Time Safety = Schedule

Schedule-Carrying Code Giotto Compiler with Time Safety Checker Giotto Program E Code Giotto-P Platform Spec Proof of Time Safety (Schedule) +

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

ai a t+10ms s Task Navigation Control t+10ms ttt+5ms i ss B1:call( actuate ) call( sense ) call( input ) schedule( Control ) schedule( Navigation ) future( now+5, B2:) relax Giotto Code Generation

ai a t+10ms s Task Navigation Control t+10ms ttt+5ms i ss 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 ) Giotto EDF Schedule Generation

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 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%

The Giotto Project 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)

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

xGIOTTO: General (event-triggered) FLET programming 1.Schedule Instruction: schedule Task by Event ; 2.Reaction Block: react { when Event do Block ; whenever Event do Block ; begin … end ; } until Event ; logical deadline

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

The Giotto Project 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)