PTIDES Project Overview

1. PTIDES Project Overview Slobodan Matic, JiaZou Edward Lee, John Eidson ActionWebs, 09/29/10

2. Transportation (Air traffic control at SFO) Orchestrating networked computational resources with physical systems Avionics Building Systems Telecommunications Automotive Instrumentation (Soleil Synchrotron) E-Corner, Siemens Factory automation Power generation and distribution Daimler-Chrysler Military systems: Deterministic Implementations of Event-driven Software Courtesy of General Electric Courtesy of Doug Schmidt Courtesy of Kuka Robotics Corp.

3. Current Practice: Printing Press • High-speed, high precision • Speed: 1 inch/ms • Precision: 0.01 inch • -> Time accuracy < 10us • Application aspects • local (control) • distributed (coordination) • global (modes) • Open standards (Ethernet) • Synchronous, Time-Triggered • IEEE 1588 time-sync protocol Bosch-Rexroth

4. For distributed cyber-physical systems, Timing needs to be a part of the network semantics, not a side effect of the implementation. Technologies needed: • Time synchronization • Bounds on latency • Time-aware fault isolation and recovery

5. A Programming Model for Distributed Cyber-Physical Systems The question we address: Given a common notion of time shared to some known precision across a network, and given bounded network latencies, can we design better distributed embedded software? Our answer (PTIDES): Use discrete-event (DE) models for specification of systems, bind model time to real time only exactly where this is needed.

6. Outline • Introduction • PTIDES Basics and Workflow • PTIDES Runtime Framework • Single CPU: Tunneling Ball Device • Multiple CPU: Power Distribution Subsystem • Summary

7. PTIDES Basics • Programming Temporally Integrated Distributed Embedded Systems • Based on Discrete-Event model of computation • Event processing in time-stamp order • Deterministic under simple causality conditions • Fixed-point semantics • Can be extended to super-dense form • Timing constraints for interaction with environment

8. Model vs. Physical Time • At sensors and actuators • Relate model time (τ) to physical time (t) t ≥ τ t ≤ τ τ1 do i4 model time τ1 τ4 0 physical time t1 t4 0

9. Single Processor PTIDES Example • Boundeddelay between any two hardware components • Bounded sensor latency (d0) t ≥ τ, t ≤τ + do t ≤ τ τ1 do i4 τ2 model time τ2 0 physical time t2 0 e2 ati2

10. Single Processor PTIDES Example t ≥ τ , t ≤τ + do t ≤ τ τ1 do i4 τ2 model time τ2 0 physical time t2 τ2+d0 0 e2 safe to process if t > τ2 + do

11. Single Processor PTIDES Example t ≥ τ, t ≤τ + do t ≤ τ τ1 do i4 τ2 model time τ1 0 physical time t2 τ1+d0 0 e2 safe to process if t > τ2 + do

12. Distributed PTIDES Example • Local event processing decisions: • Bounded communication latency (d0) • Distributed platforms time-synchronized with bounded error (e) d 1 τ1 τ3 Sensor d01 τ is safe to process if: t > τ+ do2 + e - d 2 τ2 τ4 Network Interface do2 o3 Merge τ Actuator d 2

13. Distributed PTIDES Example • Local event processing decisions: • Bounded communication latency (d0) • Distributed platforms time-synchronized with bounded error (e) τ3 Sensor d01 τ is safe to process if: t > τ+ do2 + e - d 2 τ4 d 1 Network Interface τ1 do2 o3 Merge τ Actuator d 2

14. What Did We Gain? First Point: Ensures deterministic data outputs Merge e1 = (v1, τ1) δ e1, e2, … safe to process analysis for e safe to process analysis for e e2 = (v2, τ2) Second Point: Ensures deterministic timing delay from Sensor to Actuator t ≤τ + do t ≤ τ τ1 do i4 τ2

15. PTIDES Program Design Workflow PTIDES run-time HW Platform

16. PTIDES Runtime Framework • Software components (actors) are “glued together” by a code generator into an executable • Lightweight real-time kernel (5KB) • Actors are state machines, each with an event queue and context • Asynchronous delivery: producer posts to event queue • Framework handles thread-safe event exchange and queuing   • Run-to-completion : No blocking code • No busy-waiting, semaphore, mailbox • Preemptive -> Single-stack implementation • Encapsulate each resource inside a dedicated active object • rest of app shares the dedicated active object via events  • Fast and deterministic memory allocation • Event pools:  fixed-size memory blocks

17. PTIDES Scheduler • Two layer execution engine • Event coordination (safe-to-process) • Event scheduling (prioritize safe events) • Earliest Deadline First foundation • Deadline based on path from input port to actuator • Schedulability analysis requires WCET of software components + event models • PTIDES implementation delivers DE semantics even w/o WCET • Even if deadlines missed, events are determinate • PTIDES repeatable even if WCET wrong

18. PTIDESWorkflow Analysis Schedulability Analysis Causality Analysis Program Analysis Ptides Model Code Code Generator PTIDES run-time HW Platform Software Component Library Mixed Simulator HW in the Loop Simulator Plant Model Network Model

19. Schedulability Analysis • Three cases: • Zero event processing time assumption (feasibility test) • if P fails, P will not satisfy constraints on any hardware • No resource sharing assumption (an event is processed as soon it is safe) • if P fails, P may still satisfy constraints on other hardware • Resource sharing (a safe event is processed according to a scheduling algorithm) • if P fails, P does not satisfy this implementation (and algorithm)

20. Feasibility Test • Feasibility assumptions • Zero event processing time • Bounds on event communication latency (d0) • If test fails, no HW satisfies constraints • detect flows

21. Feasibility Test • For each input port ion a sensor-actuator path

22. Single CPU - Proof of Concept • Tunneling Ball Device • sense ball • track disk • adjust trajectory

23. Single CPU Proof of Concept • Event sequences • periodic • quasi-periodic • sporadic

24. Tunneling Ball Device – 10 rps

25. Tunneling Ball Device – 1 rps

26. Distributed Testbed Objectives • Safe event processing • Offset attribute of a port • Check: real time vs model time + offset • Bounded latency between hardware components • Distribution: bounded-delay networking protocol • Scheduling • Deadlines defined by sensor – actuator model delays • Single CPU: use Earliest Deadline First • Distribution: local from end-to-end deadlines • Expressiveness of interaction • Complexityof real sensor, actuator and network interfaces • Timing support • Externalto microprocessor • National Semiconductor DP83640: IEEE 1588enabled PHY chip

27. Synchrophasor-based measurement and control Power swing and Unstability detection

28. ExperimentDiagram Grid emulator built with National Instruments PXI ‘PMU’s built with Renesas demo boards with DP83640 Ethernet bridge or 1588 boundary/transparent clock ‘SVP’ built with Renesas demo board with DP83640

29. Basic PTIDESTiming Testing Vary phasor data independently Freq. and phases w.r.t. global time Sample voltage and current Signal processing Send phasor data Local control: on/off breaker Wireshark monitoring of network events Detect discrepancies If unstable region send on/off command

30. Single platform PTIDES approximation model

31. Multi-platform PTIDES approximation model

32. Summary • The networking problem requires timing to be a correctness property rather than a quality of service • PTIDES model of computation offers a possible programming model for distributed CPS • Correct deterministic DE implementations • Better match for reactive state-machine systems  than traditional multi-threaded     or     super loop     programming models • Time stamps provides runtime information for detecting and reacting to variety of timing faults • Goal: scalability, robustness, fault-tolerance