Programming with Time for Mixed Criticality Systems Dagstuhl - PDF document

Programming with Time for Mixed Criticality Systems Dagstuhl Seminar, March 16-20, 2015 Mixed Criticality on Multicore/Manycore Platforms David Broman Associate Professor, KTH Royal Institute of Technology Assistant Research Engineer, University of California, Berkeley 2 What is mixed criticality? Mixed-Criticality Systems (MCS) Challenge Reconcile the conflicting requirements of: • Partitioning (for safety assurance) • Sharing (for efficient resource usage) (Burns & Davis, 2013) This talk focuses on the time and timing aspects of the problem Mixed Time -Critical Systems Other aspects are equally important (hardware failures, network aspects etc.), but are not considered here. Part I Part II The Implementation The Specification David Broman View View dbro@kth.se

3 Viewpoints on the MCS timing aspect Viewpoint II Viewpoint I The Implementation View The Specification View • Software Scheduling • A Task Model with Bounded Vestal’s model (and variants Frequencies thereof) with different WCET num- Yip et al. (2014) on relaxed the bers for different criticality levels. synchronous approach for MSC. • Hardware Scheduling • Programming with Time For instance, the FlexPRET Express timing constraints and approach (Zimmer et. al 2014) with fault handling explicitly in a predictable and less predictable programming language. hardware threads. Part I Part II The Implementation The Specification David Broman View View dbro@kth.se 4 Hardware Scheduling with FlexPRET Fine-grained Multithreaded Processor Platform (thread interleaved) implemented on an FPGA Flexible schedule (1 to 8 active threads) and scheduling frequency (1, 1/2, 2/3, 1/4, 1/8 etc.) Hard real-time threads (HRTT) with predictable timing behavior • Thread-interleaved pipeline (no pipeline hazards) • Scratchpad memory instead of cache Soft real-time threads (SRTT) with cycle stealing FlexPRET Softcore from HRTT Note: Not limited to 8 tasks. Can schedule several tasks on the same hardware thread using software scheduling. Open Source: Zimmer, Broman, Shaver, and Lee. “FlexPRET: A Processor https://github.com/pretis/flexpret Platform for Mixed-Criticality Systems” (RTAS 2014) Part I Part II The Implementation The Specification David Broman View View dbro@kth.se

5 Viewpoints on the MCS timing aspect Viewpoint II Viewpoint I The Implementation View The Specification View • Software Scheduling • A Task Model with Bounded Vestal’s model (and variants Frequencies thereof) with different WCET num- Yip et al. (2014) on relaxed the bers for different criticality levels. synchronous approach for MSC. • Hardware Scheduling • Programming with Time For instance, the FlexPRET Express timing constraints and approach (Zimmer et. al 2014) with fault handling explicitly in a predictable and less predictable programming language. hardware threads. Part I Part II The Implementation The Specification David Broman View View dbro@kth.se 6 A Task Model With Bounded Frequencies Example: Unmanned Aerial Vehicle (UAV) Each periodic task has Input from two frequency parameters: position & f max and f min . orientation Nav Stability Output sensors (Life-critical) (Life-critical) to flight Input from 4Hz 20Hz surfaces comms • Life Critical Tasks f max = f min . Input from Avoid Logging proximity (Mission-critical) (Non-critical) • Mission Critical Tasks sensor 10Hz – 20Hz 10Hz f max > f min . • Non-Critical Tasks Video Sharing Input from f max is the goal. f min = 0 (Mission-critical) (Non-critical) camera 10Hz – 25Hz 10Hz Output to Note: comms The task model does not say anything about the implementation technique or Eugene, Kuo, Roop, and Broman. “Relaxing the Synchron- WCETs for specific platforms. ous Approach for Mixed-Criticality Systems” (RTAS 2014) Part I Part II The Implementation The Specification David Broman View View dbro@kth.se

7 Viewpoints on the MCS timing aspect Viewpoint II Viewpoint I The Implementation View The Specification View • Software Scheduling • A Task Model with Bounded Vestal’s model (and variants Frequencies thereof) with different WCET num- Yip et al. (2014) on relaxed the bers for different criticality levels. synchronous approach for MSC. • Hardware Scheduling • Programming with Time For instance, the FlexPRET Express timing constraints and approach (Zimmer et. al 2014) with fault handling explicitly in a predictable and less predictable programming language. hardware threads. Part I Part II The Implementation The Specification David Broman View View dbro@kth.se 8 Programming with Time Motivation • Timing Specification: Be able to describe different task models within one framework • Formal: To have an unambiguous formal semantics with precise meaning • Fault handling : Be able to express precise run-time behaviors when e.g. deadlines are missed. Some related work • Giotto by Henzinger et al. (2001) • Ptides by Eidson et al. (2012) • Timing constraint logic by Lisper and Nordlander (2012) • Synchronous approach for MSC by Cohen et al. (2015) Part I Part II The Implementation The Specification David Broman View View dbro@kth.se

9 A Timed Lambda Calculus (unpublished work) Syntax Variables x, y 2 X Constants c 2 C Time t 2 N [ 1 Expressions e ::= x | λ x.e | e e | c | overrun | time | within t to t do e else e Values v ::= λ x.e | c Frames F ::= 2 e | v 2 | within t 1 to t 2 do overrun else 2 Dynamic Semantics @ d 2 D. t 0 > d δ ( c, v, s, t ) = ( v 0 , s 0 , t 0 ) ( λ x.e ) v | s, t, D � ! [ x 7! v ] e | s, t (E-DELTA) (E-BETA) ! v 0 | s 0 , t 0 c v | s, t, D � 9 d 2 D. t 0 > d δ ( c, v, s, t ) = ( v 0 , s 0 , t 0 ) time | s, t, D � ! t | s, t (E-OVERRUN) (E-TIME) ! overrun | s 0 , t 0 c v | s, t, D � within t 1 to t 2 do v else e | s, t, D � ! v | s 0 , min ( { t + t 1 } [ D ) (E-WITHIN) within t 1 to t 2 do overrun else v | s, t, D � ! v | s, t (E-OVERRUN-HANDLING) ! e 0 1 | s 0 , t 0 e 1 | s, t, D [ { t + t 2 } � (E-CONG-WITHIN) within t 1 to t 2 do e 1 else e 2 | s, t, D � ! within t 1 to t 2 do e 0 1 else e 2 | s 0 , t 0 ! e 0 | s 0 , t 0 e | s, t, D � F [ overrun ] | s, t, D � ! overrun | s, t (E-CONG) (E-OVERRUN-PROP) F [ e ] | s, t, D � ! F [ e 0 ] | s 0 , t 0 Part I Part II The Implementation The Specification David Broman View View dbro@kth.se 10 The within construct Upper timing bound (to be verified Lower timing bound for a specific statically and checked at runtime) resolution (e.g., microseconds) Computation to be done within the bound. within 5 to 10 do e 1 else e 2 Fault handling if a deadline is missed In this case, specifies Constructs can be the timing bounds for within 5 to 10 do nested releases. within 0 to 3 do () else (); computation () else Construction can errorHandling () be put within loops or have conditions. Part I Part II The Implementation The Specification David Broman View View dbro@kth.se

11 Conclusions Some key take away points: • Implementation view of MCS • Software Scheduling • Hardware Scheduling • Specification view of MCS • Bounded Frequencies Task Model • Programming with Time Thanks for listening! Part I Part II The Implementation The Specification David Broman View View dbro@kth.se