1 / 20

Challenges in Transforming Space Missions: Service-Oriented Architectures

Explore the journey of transforming space missions into service-oriented architectures, ensuring instant connections, scalability, fault tolerance, and cost-effectiveness. Leveraging satellite, sensor, ground sensors, and integrated services. Examples include wildfire monitoring and rapid data delivery for informed decisions.

mbetancourt
Download Presentation

Challenges in Transforming Space Missions: Service-Oriented Architectures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Terra (MODIS) Aqua (MODIS) Challenges in Transforming Space Missions Into Service Oriented ArchitecturesDan Mandl NASA/GSFCOctober 4, 2006 MODIS Active Fire Map Sensor Planning Services (SPS) EO-1 (ALI & Hyperion)

  2. Challenges for SOA Mission Architecturewith Sub- Services • Instant real-time connections and disconnections of services and sub-services • Cost-effective mission scalability – new services can be plugged in real-time • Prevent obsolescence – old services unplugged and instantly substituted for new services • Cost-effective fault tolerance – user can discover and connect to alternate services Satellites/ Sensors Ground Sensors Rovers Instruments Integrated Services WMS SOS WPS WfCS WFS SPS SAS Service Registry Support Sub- Services Load Bal T&C Orbit Att P&S Interoperability and Meta-Language Services Users IRC UDDI MOIS SensorML Distributed Multi-Protocol Message Bus cFE For Space GMSEC For Ground Internet SpaceWire, PowerPC 750

  3. EROS Data Center EO-1 Sensor Web Targeting National Priority Wildfires 3 Fire location confirmed and selected for imaging 1 GSFC’s Science Goal Monitor Identify NIFC-tracked Wildfire Incidents 3 SGM adds target to EO-1 ground & on-orbit planning & scheduling systems and tasks EO-1 1 Roberts Fire 2 4 SGM Correlate latest fire location information with MODIS imagery 5 L1 Data Roberts Fire UMD Natural Hazards Investigation Team 6 Active Fires Detection Map Aqua or Terra MODIS data Roberts Fire USFS Burned Area Emergency Response (BAER) team

  4. Example of Rapid Delivery of Information for Decisions Using EO-1 Sensor Web On 11-2-03, the NASA Wildfire SensorWeb was employed to collect data on the burn scars resulting from the Simi Valley, Val Verde and Piru fires in Southern California. MODIS active fire detections for the duration of the event were used to target an acquisition by the ALI and Hyperion instruments onboard EO-1. Such data are employed by the USDA Forest Service for Burned Area Emergency Rehabilitation mapping. BAER maps are used to target high risk areas for erosion control treatments. MODIS Rapid Response Active Fire Detections In this image, burned areas appear red while the unburned areas appear green. The blue burn perimeter vector is based on ground data. EO-1 Advanced Land Imager Burn Scar Image

  5. Various EO-1 Sensor Web Experiments Conducted

  6. Key Capabilities Implemented to Enable EO-1 Sensor Webs & Support “Backend” of SPS

  7. ASE Flight Software Architecture Raw Instrument Data Band Extraction ObservationPlanner Image ObservationGoals Overflight Times CASPER Planner – response in 10s of minutes Onboard Science High level S/C State Information Plans of Activities(high level) L2 – Model-based Mode Identification & Reconfiguration SCL – response in seconds with rules, scripts AutonomousSciencecraft Commands (low level) S/C State Conventional Systems EO 1 Conventional Flight Softwarereflexive response Control Signals (very low level) Sensor Telemetry Spacecraft Hardware

  8. Original Operations Flow to Task Sensors & Access Science Data processed science data GSFC Science Processing USGS targets targets, engineering requests raw science data contacts Engineer White Sands weekly schedule station in-views Mission Planner FDSS overflights selected weekly schedule MOPSS tracking data daily activities CMS daily commands commands ASIST telemetry

  9. Revised Operations Flow To Task Sensors and Access Science Data Using Onboard Autonomy processed science data JPL USGS GSFC targets targets, engineering requests Science Processing targets WWW SOA Users weekly goals raw science data targets White Sands contacts SPS ASPEN station in-views overflights daily goals Note that engineer and mission planner removed goals FDSS ASIST telemetry tracking data Onboard EO-1 science data Science Processing EO-1 goals commands CASPER SCL activities

  10. Vision: Sensor Web Enablement via a Service Oriented Architecture (SOA) Scientists Sensor Planning Services (SPS) Land Remote Sensing Observation Data Sensor Alert Services (SAS) Sensor Registry Services (SRS) Sensor Observation Services (SOS) Work Flow Chaining Services (WfCS) Earth Weather Data • Users do not task satellite • Users focus on products they need • Implicit /Transparent Satellite/Asset Tasking • Automated Just-In-Time Processing • User-Driven Custom Processing • User Notification/Delivery Space Weather Data

  11. Product Request – Step 1 User Area Of Interest 1. Fire 2. Water 3. Ice… + Discovery CASPER Onboard Planner Decision Support System ebRIM Register UAV MODIS ASPEN Planner / Scheduler EO1 SPS Ground Station

  12. Product Processing – Step 2 User Area Of Interest 1. Fire 2. Water 3. Ice… + CASPER Onboard Planner Decision Support System Discovery ebRIM BPEL Automation Ground Station Web Feature Service Web Coverage Service Web Processing Service Sensor Observation Service Level 0 & Level 1 GST Storage NYC Area Fire Classifier Get 3 bands L0 & L1 Process

  13. Product Notification – Step 3 User Area Of Interest 1. Fire 2. Water 3. Ice… + Email/IM Notification Content Syndication Data Feed CASPER Onboard Planner Sensor Alert Service Decision Support System Discovery ebRIM BPEL Automation Ground Station Web Feature Service Web Coverage Service Web Processing Service Sensor Observation Service Level 0 & Level 1 GST Storage NYC Area Fire Classifier Get 3 bands L0 & L1 Process

  14. Product Retrieval/Display – Step 4 User 1. Fire 2. Water 3. Ice… CASPER Onboard Planner Decision Support System Discovery Query/ Retrieval ebRIM Sensor Web Enabled Data Node BPEL Automation Ground Station Web Feature Service Web Coverage Service Web Processing Service Sensor Observation Service Level 0 & Level 1 GST Storage NYC Area Fire Classifier Get 3 bands L0 & L1 Process

  15. Another View of SOA Multi-MissionArchitecture Users Support Services GMSECDecision Support System ebRIMRegistry Support Services Support Services Distributed Multi-Protocol Message Bus (SWE) Data Node EO1 (SWE) Data Node TERRA (SWE) Data Node AQUA (SWE) Data Node Instruments IRC (SWE) Data Node Rover (SWE) Data Node Ground Remote Sensors

  16. Example of work on Sub-service - SBIR-1 Work on SOA Planning and Scheduling • Universal P&S System (UPASS) built by Emergent Space Technologies • Utilizes Professional Open-Source JBoss J2EE Application Server • Distributed clustered environment has a high-reliability, high-availability SOA with load balancing, automatic failovers, and no single points of failure • API allows developers to build plug-in objects and develop custom services and interfaces that interact with standard UPASS services • GMSEC translator allows all services to be accessed from the GMSEC bus UPASS Architecture P&S Engine UPASS Services UPASS API Task Type X Resource Type X Task Type X Resource Type X Task Type X Resource Type X UPASS GUI Relational Database/Object Persistence P&S Algorithm X External Services and Interfaces P&S Algorithm X P&S Algorithm X

  17. SOA Enterprise - Web 2.0 Data Nodes Interoperable User Communities (OWS-4 Demo) Data Nodes EO1 NASA DHS Terra USCG Aqua… CBP DOD NORTHCOM Civil Air Patrol Sea Nodes

  18. Funded Efforts • Two recent 3 year awards from AIST ESTO call for proposal • An Inter-operable Sensor Architecture to Facilitate Sensor Webs in Pursuit of GEOSS • Key topic – Interoperability and demonstration of service oriented architecture for space missions and sensor webs • PI: Dan Mandl - 3 year effort • Using Intelligent Agents to Form a Sensor Web for Autonomous Mission Operations • Key topic distributed mission control • Extend effort depicted on slide 16 in which ST-5 components turned into mobile agents for use onboard spacecrafts with GMSEC/CFS • PI: Ken Witt/ISR Co-I Dan Mandl/GSFC – 3 year effort • Goddard Institute for Systems, Software and Technology Research (GISSTR) contract effort being applied by Institute of Scientific Research (ISR) to: • Building GMSEC compliance tester for new components • Help to synergize other ESTO awards with above mentioned awards • Integrate Real-time Object Modeling Environment (ROME) (another service developed on ST-5) in collaboration with Capitol College into TRMM, GLAST and MMS

  19. Funded Efforts • West Virginia Challenge Grant (set-aside) to be applied to develop Sensor Modeling Language (SensorML) schemas for follow-on SOA efforts • SensorML schemas will describe sensor capabilities and once put in online registries, will enable discovering of those capabilities on the Internet • Open Geospatial Consortium (OGC) ongoing testbed effort OGC Web Services 4 (OWS-4) June 2006- December 2006 • Universal Planning and Scheduling System (UPASS) SBIR-1 (Emergent Space Technologies) • Submitted SBIR-2 proposal

  20. Conclusion • This approach can reduce cost for missions by • Use of automation • Reducing system obsolescence • Providing cost-effective scalability • Providing cost-effective fault tolerance • This approach increases data availability to users • Just-In-Time Processing • Custom Data Production (No Scientist in the Loop) • Data Feed Syndication (Leverage Existing Standards) • Aggregation Possible • This approach is user focused • Support new classes of Users • Non-scientific (DHS, DOD…) • This approach provides interoperability with other communities • Support For Disaster Relief / Emergency Response • Increase Return on Existing Data • More Science Opportunities

More Related