FARM: A Feedback based Adaptive Resource Management for Autonomous Hot-Spot Convergence System

1. FARM: A Feedback based Adaptive Resource Managementfor Autonomous Hot-Spot Convergence System S. Swaminathan & G. Manimaran Dept. of Electrical & Computer Engineering Iowa State University {swamis,gmani}@iastate.edu

2. Problem Overview • NASA – Earth Science Enterprise • To understand Earth system • Employs Earth Observing Satellites to collect data about atmosphere, oceans, continents • Information used to solve scientific mysteries, society problems • One such problem: Hotspot • What? – Any abnormal natural/man made event • E.g., Volcano, Tornado or Nuclear explosion • Problem: Hot-spot detection and location • Solutions called for Collaborative Problem Solving

3. Today: Large space-based Observatories Today

4. Tomorrow Sensor Web - Web of satellites with on-board computing power

5. Today and Tomorrow • NASA - transition from large observatories to light space-based instruments • Instruments with on-board computing and communication power • On-board computing - must enable hot spot detection, location, and monitoring • Enable autonomous problem solving • Instruments placed at different orbits for different levels of accuracy • Work as a web of satellites – Sensor Web

6. Sensor Web • Sensor Web • Constellation of Earth observing satellites • Coordination for distributed monitoring, processing, and decision making • Can be considered as an internet of satellites • End user must be able to interact with sensor web to get information about hotspots • Easy deployment of technology and scalability

7. Sensor Web - Schematic

8. System Components • Satellites: • Orbit around the earth at different orbits • low earth orbit (small satellites), geostationary (geostationary satellites), and L1 and L2 orbits (sentinel satellites). • Spot beam (coverage area) • Data accuracy – depends on orbit level • Smaller the spot beam, higher the accuracy

9. System Components (contd..) • Satellite - sensors and instruments for measurement • Satellite • on-board data processing capabilities • on-board communication capabilities • Capable of reacting to changes in the spot beam • Earth Control Center: Controls/monitors the sensor web • End user: Queries the sensor web

10. System Model

11. Application Scenario • Scenario - handling of a hot-spot • Auto detection or External trigger • On-board processors analyze data • communicate directly or through other satellites • different data rates for different information • Autonomous satellites detect hot-spots • Establish contact with control center • If external triggered - instruments adjusted

12. Application Scenario (contd..) • Scientist becomes aware of hotspot • knowledge of location - not required • Triggers sensor web (nearby satellite) • Perform collaborative problem solving • specific satellite queries relevant satellites • detect hotspot and information to control center • control center can adjust other satellites (if reqd.) • Control center/end user can query any satellite about a hotspot

13. Sensor Web - Challenges • Information Technology • Resource management mechanism - handling uncertain workload • Algorithms and techniques - data aggregation, compression and image processing. • Reconfigurable architectures and algorithms for various on-board data processing. • Energy-efficient architectures and algorithms for on-board computing and communication. • Satellite Technology • Dynamic control and reconfiguration of satellite instruments. • Satellite computing, communication, and instrumentation technologies. • Global real-time onboard navigation capability for earth science remote sensing.

14. Challenges in building a Sensor Web (contd..) • Domain Specific Technology • e.g., water-level monitoring algorithm in Polar Ice caps • cloud contamination detection with atmospheric correction • Issue Addressed - Resource Management • Management of computing and communication resources • Reliability, availability, performance and security requirements • Dynamic re-configuration of sensor web

15. Issues in Autonomous Hot-Spot Convergence • Autonomous Hot-Spot Convergence • Hotspot Identification • Identification of satellite(s) to cover the hot-spot for required quality • Allocation of resources - computing and communication • Reconfiguration of instrumentation resources • Reliable communication with Earth Control Center/ End User.

16. Issues in Autonomous Hot-Spot Convergence (contd..) • Requirements drive the need for • Load balancing among the satellites • Distributed Coordination Schemes • for minimizing redundancy in the coverage area • Quality-aware distributed scheduling, as the quality of image perceived by one satellite might be higher than another • Further, there is a need for continuous monitoring of topology and resources • Topology Monitoring - knowledge of spot beam • Resource Monitoring – for resource allocation

17. Workload Characteristics Computational Workload Dynamic Static E.g., Default Spot beam coverage Aperiodic Periodic Fixed hotspot monitoring e.g, vulcano dynamic hotspot monitoring e.g., tornado Periodic computation and communication Continuous handoff Reconfiguration of sensors

18. Workload Characteristics (contd..) Communication Workload Inter-satellite - periodic and aperiodic satellite -> control center - periodic and aperiodic satellite -> end-user - aperiodic • Uncertainty - Computational and Communication • Workload !! • Need for Adaptive Resource Management!!

19. FARM: A New Resource Management Methodology • FARM - Feedback-based Adaptive Resource Management Methodology • Path-based Scheduling • coarse level timing requirements • easier to model application • Value-based Scheduling • Graceful degradation • paths offer value/benefit to the system • Feedback scheduling • Handles uncertainty in workload • Robust and graceful performance

20. Path-based Scheduling • Scheduling based on application semantics • Easiness to provide timing requirements • Scheduling a path (group of related tasks) • Paths – Data/Event source, Data Stream, Data/Event Consumer • Transient – initiated by event and ends in an event • Continuous • Data source, stream and consumer • Cycle deadline – deadline for processing • Quasi-continuous • Continuous path activated and deactivated by events • Cycle and deactivation deadline

21. Interacts with control center Adds track information Functional Modules Communicates with other satellites Analyzes hotspot Process user queries Updates load and topology Trigger hotspot identifier Reconfigures instruments Handles Overload

22. Functional Modules (contd..) Functions Tables Read Write Modules SRM Sensor Reading and configuration Track Track HIM Enduser/Control Center Interface Track Track HSI Identification and creation of monitor Track Hotspot HSM Analysis of hotspot, Overload Handling and Resource Reconfiguration Hotspot Hotspot OH Overload Handling, Migration Hotspot LTT, MT Sensor Reconfiguration - - RR Hotspot Track - Query Processing, data compression QP Hotspot Track Commn. With other satellites Hotspot, Track GC-I - Commn. for load and topology updation - LTT GC-II

23. Path-level Diagram

24. Paths Paths Path Type Source Streams Consumer Track Analysis Continuos Sensor Track table HSI Hotspot Identification Quasi-Continuos Track table Table entries HSA Hotspot table Table entries Hotspot Monitor Quasi-Continuos End User Query Query Processor Transient - Result HIS, HIM tasks Sensor Reconfig. Transient - Reconfiguration Load and Topology Updation Continuos LTM task LT table HS-Sel task Transient Overload detection Overload Handler - Migration Earth Center Interaction Commn. From Control Center Trigger HSI or RR task Transient -

25. Value-based Scheduling • Real-Time Systems • Primary Objective: Meet all deadlines • Underload situation – can meet deadlines • Overloads – schedule critical tasks, degrade gracefully !! • Value-based Scheduling • Scheduling paradigm aims at maximizing the value of system • Allows graceful degradation of system • Examples of Value • Criticality based Value • Performance Index (Schedulability-Reliability tradeoff value) function

26. Closed Loop Scheduling Plant Controller Actuators Sensors Feedback Set points System • The system periodicallymonitors and compares the controlled • variable to the set point to determine the error. • The controller computes the required control based on the error. • The actuators change the value of the manipulated variable to control • the system. Controlled variable: the quantity of the output that is measured and controlled. Set point: represents the correct value of the controlled variable. Manipulated variable: is the quantity that is varied by the Actuators so as to affect the value of the controlled variable.

27. FARM: Architecture Adjusts path quality Schedules accepted paths Admits/rejects paths Workload arrives at path queue • Observes value, rejection ratio • Computes Error • Calculates CPU1 and CPU2 • Instructs other controllers

28. FARM: Architecture (contd..) • Computation time adjustment • Hotspot monitor path can be adjusted without violating the minimum computational quality. • Query processing and overload handling not amenable for quality adaptation. • The controlled variables are observed and periodically fed back to the PID controller. • No. of hotspots/queries rejected fed-back by the path admission controller • Controller obtains the average hotspot value by periodically reading the hot-spot table (updated by hot-spot analyzer).

29. Satellite Coordination and Load Balancing • Need for coordination • Spot beam overlaps • Migration of hot-spots from one sate. to another • Hotspot monitor selection • Quality-based Coordination • select based on quality required • Load-based Coordination • During overload, select least loaded satellite • No potential satellites • Initiate a reconfiguration request to a satellite (consulting the topology table).

30. Policy Suggested Approach Information Periodic policy Threshold policy Transfer Value-based policy Selection Sender Initiated Location Global Policies for Distributed Real-Time System • Information Policy – information exchange timings • Transfer Policy – determines need for migration • Selection Policy – determines load to migrate • Location Policy – finds suitable receiver

31. Survivability • Potential threats • Hardware/Software faults • Malicious attacks from individual users (remember throwing a sensor internet is extremely dangerous) • Technology and service like deficiencies • Secure, reliable and dependable architecture amidst threats

32. Survivability (contd..) • Infrastructure protection • Hardware redundancy techniques • Firewall technology • Secure and fault-tolerant communication • Encryption of Inter-satellite communication • Authentication to protect against malicious activities • Fault-tolerant path execution • Critical paths need to be identified • Scheduled with multiple versions

33. Fault-Tolerant Policy Path Names N-Version Programming Load and Topology Updates Sensor Reconfiguration, Overload Handler, QP, ECI Recovery Block Track Analysis, Hotspot Identifier, Hotspot Monitor Imprecise Computation Survivability (contd..) • Fault-tolerant scheduling techniques • Tradeoff between schedulability and reliability • Use a value-based performability index to capture this tradeoff • Path-based fault-tolerant scheduler • Determines redundancy level for each path to maximize overall performability

34. Security • Security - important as satellites can be accessed by users over the Internet. • Adopted [SWARM] Integrated security framework • Network Intrusion Detection System and Resource Manager • Network Intrusion Detection System • Intrusion and anomaly detection • Resource Manager • Intrusion detected - take resource action • Drop suspicious paths

35. FARM: Summary • Our solution to AHSCS • System Modeling and Workload Characterization • FARM • New resource management methodology • Graceful Degradation • Coarse level timing requirements • Robust performance under uncertain workload • Survivability and Security strategies • Fault-tolerant techniques • Adopted Security Strategy