Comparing Models of Computation for Real-time, Distributed Control Systems

1. Comparing Models of Computation for Real-time, Distributed Control Systems Shawn Schaffert Bruno Sinopoli

2. Outline • The real-time, distributed control problem • The two car example • Analysis of different models • Implementation • Conclusion

3. The real-time, distributed control problem

4. The Real-time, Distributed Control Dream • Model for classical control • Model for discrete world • High level: networking, synchronization • Low level: task scheduling • Verification tools • Code-generation -> implementation

5. Key Ideas Mechanisms • Communication network • Local & global clocks • Distributed dynamical environment • Local shared resources • Dynamic node creation/destruction Properties • Controller stability • Fault tolerance • Task deadlines • Network reliability • Synchronization error Applications • Environmental monitoring (distributed sensing) • Rocket vibration damping (distributed actuation) • Two car example (distributed sensing and actuation) Algorithms • Routing • Localization • Synchronization • Control • Scheduling

6. The two car example

7. TURN! TURN! Cluster1 Cluster2 RF RF RF RF Ext_Node2 Int_Node2 Int_Node1 Ext_Node1 sensor sensor sensor sensor System Structure Distributed wireless sensor nodes detect the coming cars and their directions, communicate with neighbor nodes, and control the cars to avoid collision

8. Analysis of different models

9. Models • Continuous Time • Timed Multitasking • Continuous Time with Discrete Event • Globally Asynchronous Locally Synchronous (GALS) • Other models • Giotto • SDF • SR

10. Continuous Time (CT) • This model captures: • Control stability • This model doesn’t capture: • Synchronization • Scheduling • Network

11. Timed Multitasking (TM) • One purpose: analysis of scheduling of shared resources • Isn’t interesting for the two car example • Could be useful for general problems • Higher level provides bounds on event inter-arrival time • This level guarantees task deadlines are met

12. Continuous Time with Discrete Event (CT-DE) • Our models captures • Radio communication • Broadcast channel • Radio delay • Radio collision • Distributed environment • Nodes are separate entities • Communication only via radio channel • Distributed sensor readings

13. Continuous Time with Discrete Event (CT-DE) • Our model could be extended to capture: • Improved radio model • Radio noise • Low radio bandwidth – collision window based on packet size • Local and global clocks • Nodes query environment individually • Hardware-in-the-loop • Problems with the CT-DE model: • Dynamic node creation/destruction seems cumbersome • Does not model task level • Scale to 100 or 1000 nodes

14. Esterel • Synchronous language • Control-dominated software or hardware reactive system • High-level programming using functional models • C code is automatically generated

15. Implement functional specification using high-level language (Esterel) Directly generate function modules(C code) through compiling Build interfaces and wrappers needed by the execution platform Design Concepts Functional Specification Target Execution Platform Compiler CodeGeneration Performance evaluation Design Flow

16. TURN! TURN! Cluster1 Cluster2 RF RF RF RF Int_Node1 Int_Node2 Ext_Node1 Ext_Node2 sensor sensor sensor sensor High-Level Description module Cluster: loop await FROM_NC; await E; emit CAR_TURN each L || loop await E; emit TO_NC each L || loop await T; emit CAR_TURN; emit TO_NC each L module intnode: loop await [CAR or FROM_N]; present CAR then present FROM_N then emit T else [await FROM_N; emit L] end present else present FROM_N then [await CAR; emit E] end present end present end loop module extnode: Loop await CAR; emit TO_N end loop

17. The real World Esterel –A <modulename>.strl

18. Synch vs Asynch • In Synchronous models • “Reaction based” • Absence () can be sensed and used in the specification of behaviors • A global tick exists • In Asynchronous models • “Signal based” • No global tick • Reaction cannot be observed anymore •  cannot be sensed

19. Endochronicity • define desynchronization of P • This map is unique but not invertible “If P satisfies a special condition called endochrony, then there exists a unique such that holds”

20. Endochronicity: Meaning • STS • Set of variables • W’ clock inference of W ( ) if knowing presence/absence of allows deriving the presence absence of • If then the process is endochronous

21. Isochronicity • In general • WE want the equality to hold (no spurious behavior due to asynchronous communication) “If (P,Q) satisfies a special condition called isochrony then the equality indeed holds”

22. Isochronicity: Meaning

23. Our Case This is endochronous: module extnode: Loop await CAR; emit TO_N end loop module intnode: loop await [CAR or FROM_N]; present CAR then present FROM_N then emit T else [await FROM_N; emit L] end present else present FROM_N then [await CAR; emit E] end present end present end loop This is not endochronous since CAR and FROM_N are not related: if (messagePayload_ptr->sourceNodeID == DUMB_NODE) { internal_I_FROM_N()} else if (messagePayload_ptr->sourceNodeID == OTHER_SMART_NODE) { internal_I_FROM_NC()} internal()

24. Make it Endochronous • Simple solution: add signaling • For each signal add a boolean flag which indicates presence/absence • During the execution the functions will wait for all the flags and then will react • Very expensive in general: • If (flag==T) { set_input;set_arrived} • If (all_flag) {react;reset_arrived}

25. Some discussion • External node: • Code size overhead 7% • Internal node • Code size overhead 18% • The external node is already endochronous • Internal node needs some extra signaling

26. Implementation

27. Conclusion • Ptolemy • Allows accurate model for entire system • Network, dynamics, scheduling • User friendly (intuitive) • Scalability issues • Code generation for sensor networks? • Esterel • Limited modeling (only behavioral level) • Verifiability • Code generation

28. Controller CT DE Synchronization Routing Task & Resource Scheduling TM Proposed Design Methodology Hardware

29. END Acknowledgements: Professor Lee for stimulating discussion Alessandro Pinto, Yanmei Li for their contribution in the Esterel implementation