*-aware Software for Cyber Physical Systems

1. *-aware Software for Cyber Physical Systems John A. Stankovic BP America Professor University of Virginia Feb 3, 2012

2. What is a CPS? • Isn’t is just an embedded system? • Not the main question • Simply parsing “CPS” -> Many systems are CPS, but that is not the issue • REALLY INTERESTED IN • New research needed for the next generation of physical-cyber systems

3. Confluence of Key Areas Scheduling Fault Tolerance Wired networks Level of Uncertainty Cost Form Factor Severe Constraints Small Scale Closed Real-Time Embedded Systems Architecture Principles Wireless Sensor Networks Control Linear Adaptive Distributed Decentralized Open Human Models Noisy C. Sensing Scale Real-Time/Actuation Open

4. What’s New • Openness • Scale • World covered by trillions of sensors • Systems of systems • Confluence of physical, wireless and computing • Human (in the loop) Participation

5. Theme • How can we build practical cyber physical systems of the future? • 3 Critical (Foundational) Issues: must be addressedtogether • Robustness • Real-Time • Openness

6. Foundational Principle • Scientific and systematic approach for the impact of the physical on the cyber • Propose: • Physically-aware SW • Validate-aware SW • Privacy/security aware SW Real-time aware SW

7. “Open” Smart Living Space Building HVAC Eavesdrop

8. Openness • Typical embedded systems closed systems design not applicable • Added value • Systems interact with other systems • Evolve over long time • Physical system itself changes • High levels of uncertainty: Guarantees

9. Computing in Physical Systems Road and Street Networks Environmental Networks Industrial Networks Open, Heterogeneous Wireless Networks with Sensors and Actuators Battlefield Networks Building Networks Vehicle Networks Body Networks

10. Outline • Physically-aware software • Validate-aware software • Real-Time-aware software • Privacy-aware software

11. Physically Aware: Impact of the Physical • For Wireless Communications (things we know) • Noise • Bursts • Fading • Multi-path • Location (on ground) • Interference • Orientation of Antennas • Weather • Obstacles • Energy • Node failures

12. B, C, and D are the same distance from A. Note that this pattern changes over time. Asymmetry Irregular Range of A A and B are asymmetric

13. Impact on Path-Reversal Technique Routing • DSR, LAR: • Path-Reversal technique

14. Uncertainties -Voids Left Hand Rule Physically-aware SW Destination VOID Source

15. Cyber-Physical Dependencies • Sensing • Sensor properties • Target Properties • Environmental interference

16. Energy Efficient Surveillance System 1. An unmanned plane (UAV) deploys motes Zzz... Sentry 3. Sensor network detectsvehicles and wakes up the sensor nodes 2. Motes establish an sensor network with power management

17. Tracking • Magnetic sensor takes 35 ms to stabilize • affects real-time analysis • affects sleep/wakeup logic • Target itself might block messages needed for fusion algorithms • Tank blocks messages

18. Environmental Abstraction Layer (EAL) Not HW-SW co-design, but rather Cyber-Physical co-design

19. Open Q: Environment • How to model • How to know we have all the issues covered • Design Tools Impact of the Physical on the Cyber

20. Open Q: Correctness • What does correctness mean in an open system Formal Methods Don’t Address

21. Safety Critical Long Lived Validated Re-validated Dynamics of Environmental Changes Influence Correctness Validate Aware: Run Time Assurance (RTA) See Run Time Assurance paper in IPSN 2010.

22. RTA Goals • Validate and Re-validate that system is still operational (at semantics level) • Anticipatory RTA • Before problems arise • Robust to evolutionary changes Validate-aware software

23. RTA Solution • Emulate sensor readings • Reduce tests to focus on key functionality • Overlap tests and system operation • Evolve required tests

24. Current Solutions • Prior deployment analysis • Testing • Debugging • Post mortem analysis • Debugging • Monitoring low-level components of the system • System health monitoring Necessary, but not sufficient

25. RTA • Formally specify application level semantics (of correctness) • Ability to demonstrate that correctness over time

26. RTA Framework Inputs RTA framework

27. Model-based Specification Sensor Network Event Description Language (SNEDL) Smoke > x Temperature > 30°C >80°C

28. Test Specification //Declare the basic elements of the language Time T1; Region R1, R2; Event FireEvent; //Define the elements (time and place) T1=07:00:00, */1/2010; //first day of month R1={Room1}; R2={Room2}; FireEvent = Fire @ T1;

29. Token Flow Smoke > x Temperature >30°C >80°C

30. Code Generation • Code is automatically generated from the formal model • Advantages of the token – flow model: • efficiently supports self-testing at run time • it is easy to monitor execution states and collect running traces • we can easily distinguish between real and test events

31. Validate-aware SW • High level spec on “function” • Runtime SW that targets demonstrating “validation” • SW design for ease of validation • Framework – to load, run, display tests • System: Aware of validation mode

32. Open Q: Run Time Assurance • Open system evolves • Validate and re-validate (more than monitoring) • Limit number of tests • Level of detail Safety Analysis

33. Real-Time Aware • Hard deadlines • Hard deadlines and safety critical • Soft deadlines • Time based QoS • Dynamically changing platform (HW and SW)

34. Example: Group Management (Tracking) Base Station

35. Deadlines • If we have enough late messages within groups we can lose the track • Not straightforward deadline • Tied to redundancy, speed of target • If messages don’t make it to base station in hard deadline we miss activating “IR camera” • If we don’t act by Deadline D truck carrying bomb explodes – safety critical

36. Real-Time Scheduling Tasks Deadlines Algorithm EDF 1 Schedulable Yes 2 Order 1,2,3 3 How robust? CF=1 1 2 3 TIME

37. Robust RT Scheduling For Real World CPS Tasks Deadlines Algorithm EDF 1 Schedulable Yes (1.8) 2 Order 1,2,3 3 How robust? 1.8 CF 1 2 3 TIME

38. Real-Time Technology • Three possible approaches • Velocity Monotonic • Exact Characterization • SW-based Control Theory

39. Front-End feedback loops based on real world control generate timing requirements/rates generally fixed handed to scheduling algorithm Feedback Control S c h e d u l i n g A l g P1 P2 P3 P4

40. FC-EDF Scheduling Completed Tasks MissRatios MissRatio(t) EDF Scheduler CPU Service Level Controller PID Controller CPUi Accepted Tasks CPUo Admission Controller FC-EDF Submitted Tasks Real-Time aware SW

41. Open Q: Control • With humans in the loop • New system models • Robustness (and Sensitivity Analysis) • New on-line system ID techniques Interacting (dependency among) Control Loops

42. Privacy-aware: Fingerprint And Timing-based Snoop attack Adversary Fingerprint and Timestamp Snooping Device Bedroom #2 Kitchen Locations and Sensor Types Timestamps Fingerprints Bathroom T1 T2 T3 … … ? ? ? … Living Room Bedroom #1 Front Door V. Srinivasan, J. Stankovic, K. Whitehouse, Protecting Your Daily In-Home Activity Information fron a Wireless Snooping Attack, Ubicomp, 2007.

43. Performance • 8 homes - different floor plans • Each home had 12 to 22 sensors • 1 week deployments • 1, 2, 3 person homes • Violate Privacy - Techniques Created • 80-95% accuracy of AR via 4 Tier Inference • FATS solutions • Reduces accuracy of AR to 0-15%

44. ADL • ADLs inferred: • Sleeping, Home Occupancy • Bathroom and Kitchen Visits • Bathroom Activities: Showering, Toileting, Washing • Kitchen Activities: Cooking • High level medical information inference possible • HIPAA requires healthcare providers to protect this information Adversary Fingerprint and Timestamp Snooping Device Locations and Sensor Types Timestamps Fingerprints T1 T2 T3 … … ? ? ? …

45. Solutions • Periodic • Delay messages • Add extra cloaking messages • Eliminate electronic fingerprint • Potentiometer • Etc. Privacy-aware software

46. Open Q: Privacy • Eavesdropping • Access to information (in DB) • Power of inference over time Opt-in Strategies Public Places

47. Summary • Robustness – to deal with uncertainties: (major environment and system evolution) • Real-Time – for dynamic and open systems • Openness – great value, but difficult • Physically-aware • Validate-aware • Real-Time-aware • Privacy/security-aware • Diversity – coverage of assumptions • EAL *aware CPS-aware