NC: A Verifiable, Executable Coordination Paradigm for Real-Time Communication

1. NC: A Verifiable, Executable Coordination Paradigm forReal-Time Communication Sebastian Fischmeister sfischme@seas.upenn.edu Department of Computer and Information Science University of Pennsylvania

2. No RT Soft RT Hard RT Computer simulation Internetvideo, audio Cruisecontrol Telecommunication Flightcontrol Electronic engine Userinterface Real-Time Systems • Right value at the wrong time can cause an error!  How to guarantee timeliness in the system?

3. Shared medium Brake pedal Brake Fuel tank Board computer Tires Distributed RT Systems • Multiple nodes together realize one real-time application.  How to bound communication delays in the system? Collisions, retransmissions, delays!  need for a coordination model for controlling access.

4. N1 N2 N3 N4 Slot t Round Time Division Multiple Access • TDMA is a method for realizing collision-free access to a shared medium. • Partition access into time slices (=slots) and rounds. • Assigns slots to nodes for exclusive access using some algorithm. • Example: Round robin with four nodes

5. statically allocated One static phase: static dynamic Static + dynamic: static dynamic free Static, dynamic, free: dynamic Only dynamic: Flavors of TDMA • Great for safety-critical systems, but too inflexible. • Still: • Decisions are made at the beginning of the round/phase. • Phase order stays the same. • Typically independent of the software.

6. Goals of Network Code • Goals: • Allow close interaction between the application and the medium access control. • Allow developers to program their own access control. • Allow decisions during the communication round. • Should be apt for safety-critical hard real-time systems.

7. Application Application NC program Program logic Value space Value space set X NCM NCM get X get X set X tx M/ch Network Code[ISCC05] • Executable programmable coordinationmodel for real-time communication with a domain specific language. • Split application into: program logic + communication logic • Communication logic is programmed separately (=Network Code program) • An interpreter(=Network Code machine) executes the program at run time Node1 Node2 Medium

8. Research Results/Status • Theory: • Underlying concept and idea of Network Code [ISCC05] • Verification of Network Code programs [RTAS06] • Given a set of programs, are they safe to run concurrently? • Metrics framework for measuring programs [EmSoft06] • Overhead, throughput, avg. cycle length, avg. waiting time • Composition algorithms for programs [submitted] • Given several applications, how can they run together? • Simulation: • In round decisions increase throughput and performance. [EmSoft06] • Gains are kept despite overhead introduced during composition. [submitted] • Implementation: • Implementation RTLinuxPro[RTAS06,TC07]+Ethernet, PIC18F+CAN , FPGA

9. How does it work?

10. L0: create(M, X) send(ch, M, _) wait(20) goto(L0) La: wait(10) receive(ch, Y) wait(10) goto(La) Example: Transmit X in M • Slot length is 10t. • Node 1 transmits variable X every 20t in message M on channel ch. • Node 2 receives this message and stores it Y. t 0 10 20 Sender Receiver

11. A B C D E Standard: t Vote decisive? Skip ahead! A B C D E Improved version: t Complex Example • Transmit a value with temporal replication tolerating 2 failures • Sensor values A to E. (2n+1) • Decide at the end of the round what the sensor value is. • Take the majority vote (e.g., ‘4,4,3,2,4’ is 4)

12. A B C D E t Complex Example Code Node A: La: create(MA, A) send(ch, MA) wait(20) receive(ch, B) wait(10) receive(ch, C) if(voteDecisive, La) wait(10) receive(ch, D) if(voteDecisive, La) wait(10) receive(ch, E) goto(La)

13. Network code program set/get set/get Queue Queue Access control Coordination Communication medium System Overview Application layer RT application Value det. layer Variable space Network code machine Soft queue Hard queue Dynamic TDMA layer Message transceiver

14. set/get set/get Queue Queue Access control Coordination Communication medium Data Flow (Hard Values) Application layer RT application Network code program Value det. layer Variable space Network code machine Soft queue Hard queue Dynamic TDMA layer Message transceiver

15. set/get set/get Queue Queue Access control Coordination Communication medium Data Flow (Soft Values) Application layer RT application Network code program Value det. layer Variable space Network code machine Soft queue Hard queue Dynamic TDMA layer Message transceiver

16. Verification & Checking[RTAS06] • What if I have a bug in my Network Code program?  a verification framework with model checking • Use operational semantics of instructions to model system state. • Convert program instructions to transformations of the system state. • Check properties are reachability questions using model checking. Prgm 1: La: wait(20) send(_,_,_) if(guardX, La) wait(10) send(_,_,_) goto(La) Prgm 2: Lb: wait(10) send(_,_,_) wait(30) goto(Lb)

17. Example Properties • Integrity checks • All guards present • Valid jump addresses • Successor address • Consequential code • Behavioral checks • Non-empty send • Local message lifecycle • Distributed checks • Collision-free communication • Schedulability • Non-empty receive • Message reception within timeout

18. (X,3) !g1 g1 (Y,4) (Z,2) Metrics Framework[EmSoft06] • What is the overhead? What is the throughput? What is the cycle? • Convert the Network Code Program into a timed tree communication schedule. • Compute metrics on the tree schedule using DFS & model checking. • Timed tree communication schedule: • Nodes encode messages releases and delays • Transitions encode mutually excl. decisions(exhaustive, deterministic) • Leaves cause a reset

19. A A B C D E B t g1 g2 C g1 !g1 - D !g2 g2 - E Example Metrics • Longest cycle length = longest branch • Guard overhead • End-to-end constraints for messages • Probabilistic tree schedules: • Average cycle length = average branch length • Average waiting times

20. Is it better?

21. Inverted Pendulum • Pendulum sitting on a cart with one degree of freedom. • Measure the angle w.r.t. to straight up. • The cart moves horizontally to balance the pendulum. • Temporal replication to tolerate two faults: • 5 measurement units (A to E) • Report measurements to the controller. • Controller updates the kart at the round.

22. A B C D E Network code: t Vote decisive? Skip ahead! A B C D E t Simulation Results Standard schedule: Network Code is better*

23. Simulation Results Mean time to failure With an increase in the mean time to failure, standard TDMA stays the same. Network Code utilize this increase in reliability.

24. Implementation Measurements • Given the shortest program, what is the fastest execution rate? • Output queue must not overflow. • Input queue must not under-/overflow. • Slot structure must not be violated. • RTLinuxPro + direct link (100 MBit/s) • 10% latency increase due to computation time • 2.96MByte/s with a 99% guarantee of a successful transmission • 2.65MByte/s with 99.999% guarantee • Interrupts preempt instructions, cause jitter, cause delays. • Send() instruction: 372ns (39.47%), 733ns (99%), 19090ns (99.999%) => FPGA! (10us)

25. Conclusions • Communication behavior differs among applications; custom protocols/schedules can: • Significantly improve the application’s performance • Incorporate/guarantee new properties at the communication layer • Network Code allows programming custom TT communication behavior. • Programs are checkable, guarantee properties in the distributed system. • Programs are measurable with tree schedules. • Can run real-time and non-real-time traffic on the same network. • Future work: multi-resource tree schedules and resource DSLs, program generation, development methodology

26. Other/Past Research • Logical execution model has deficits when considering communication. • Task chains[DASC04] • Case study[RTAS05] • How to deterministically reconfigure RT software? • Use virtualization and separate behavior & functionality[ECRTS05] • Are mobile agents systems secure? (year 2000) • No![MA01] • How to build efficient proactive location-based systems? • Decentralized architecture[LNAI] • Use notification service[PERCOM03]

27. Outlook

28. Resources close() open() DSL1 send() Software Component x++ DSL2 X() Consumption read() malloc() Functionality DSL3 receive() y+=5%x write() Network Code spawn() fun() Medium DSLs & Interfaces Current Approach • What are good abstractions for resources, what are good DSLs? • What makes the interface of a software component? Is the DSL the interface? • How can we generate code for a component? • How do we provide hardware support for DSLs? (e.g., programmable memory)