Terra (MODIS)

1. Terra (MODIS) Aqua (MODIS) Making Space-based Sensors Discoverable on the Internet Using A Service Oriented Architecture and Open Geospatial Consortium StandardsJanuary 16, 2007Dan Mandl NASA/GSFC MODIS Active Fire Map Co-authors: Rob Sohlberg/Univ. of Md. Stu Frye/MitreTek Pat Cappelaere/Vightel Steve Ungar/GSFC Troy Ames/GSFC Steve Chien/JPL Sensor Planning Services (SPS) EO-1 (ALI & Hyperion)

2. Introduction NASA/GSFC prototyping open source software based on Open Geospatial Consortium (OGC) standards to enable user-centric geospatial sensor web services User can access: Data from sensors (space-based, unmanned aerial vehicles and in-situ) Services to perform various levels of data processing Models which describe how to create desired science products from available sensor data Science products/algorithms are registered on a catalog server and are easily discoverable, accessible, modifiable and extensible via service chains

3. User Types Basic user (pick dish from menu) Uses features to request capability (system translated into sensor web actions) Doesn’t know available capabilities in advance Doesn’t know how data is obtained in detail Needy user (pick from menu, but change certain items) Needs to change parameters such as spectral band selections, desired resolution or data delivery mechanisms Wants specific capabilities and can add/change/mix parameters to produce custom outputs Advanced user (creates menu items/recipes) Generates and registers new service chains from existing data sources and data processing algorithms Supplier/provider (manufacturer/producer) Supplies new data nodes, new processing nodes, new registry tools & sensor web models/optimizers

4. Some Basic Definitions Ontology - a data model that represents a domain and is used to reason about objects in that domain and the relations between them Virtual data product – a new data type created out of lower level data types using a specific ontology, which can include real sensor data Geo-processing model – a conceptual workflow to create the virtual data product using a specific ontology Used to cross reference desired geo-spatial features to specific workflows that will generate the desired geo-spatial features (e.g. create fire map from satellite multispectral sensor data) Concrete workflow – a set of specific steps applied to a specific input to get a specific science output product

5. XML SCRIPT Reference Architecture for an Inter-Operable Sensor Web Requested data from sensor data nodes or data processing nodes via Internet DEMIS Register Catalog Registry Register Web Map Service Catalog Service for Web (CSW) SensorML Map Discover (Product Features and Service Capabilities) SensorML "Thin" Web Client (blog, wiki, IM, forum) Register SensorML Capabilities Documents Data Processing Node SensorML Capabilities Documents Workflow Editor SAS SAS Web Feature Service (WFS) EO-1 Satellite EO-1 Satellite SAS SAS In-situ Sensor Data Node Web Coverage Service (WCS) Web Coordinate Transformation Service (WCTS) Web Processing Service (WPS) UAV Sensor Data Node Sensor Planning Service (SPS) SOS SOS Geospatial Processing Models SOS SOS Satellite sensor data product L1G WFS WFS Sensor Alert Service (SAS) L1G WFS WFS Optimizer Scheduler Check Workflow Feasibility Sensor Observation Service (SOS) SPS SPS SPS SPS Execute Instantiation Service Satellite Data Node Execute Decision Support System & Tools Workflow Engine IRC GMSEC Service Chain Sensor Analysis/Simulation Concrete Workflow

6. Basic Services of an Inter-operable Sensor Web User interface – thin Web client Data node – supplies sensor data over Internet Satellite, UAV and in-situ Data processing node – applies algorithms to data supplied by data nodes Workflow engine – executes XML-based scripts in a workflow/service chain to produce a user requested science product Catalog – stores capability/feature documents of the data nodes, data processing nodes, and scripts from the workflow sequencer Decision Support System and tools – user tool box to enable the creation of science products

7. User Interface HTML browser Web-centric collaborative tools such as: Blog Wiki Forum Instant messenger Thin client Web map services

8. Basic Components of the Decision Support System Geospatial processing models Workflow editor – creates or updates workflows and registers them in the catalog as needed Instantiation service Discovers available virtual products available to fulfill a user request for geospatial features Checks the feasibility of the specified workflows Creates a concrete workflow script which can be executed by the workflow engine to create the specific instance of the virtual product requested Optimizing scheduler – looks at workflows and assists the instantiation service in selecting the optimal workflow for the desired result

9. Basic Components of a Data Node Sensor Planning Service (SPS) – provides standard interface which is OGC compliant to task sensor and to provide status to user Sensor Observation Service (SOS) – processes and delivers sensor data compliant with OGC standards. Sensor Alert Service (SAS) – enables data node to publish alerts and subscribe to alerts from other nodes. Data node capabilities defined in SensorML documents Sensor capability description Data delivery format Tasking formats May also include adapters for Instrument Remote Control (IRC) and GSFC Mission Services Evolution Center (GMSEC) protocols

10. Basic Components of a Data Processing Node Web Coordinate Transformation Service (WCTS) – transforms standard data products into grids required for algorithms Web Processing Service (WPS) – Executes user selected algorithms such as data classifiers. Web Coverage Service (WCS) – Repackages output of WPS for display on map or other visualization techniques. All operations defined in SensorML documents

11. Catalog Service for Web Catalog of available data with pointer to location Sensor data Virtual data Catalog of available processing services with pointers to locations Provides registration services for both data and processing services to other nodes on the Internet

12. Target EO-1 User Scenario • Department of Homeland Security (DHS) analyst requests fire, flood, ice breakup, and other features of interest to analyze emergency response in disaster area • Client DSS Model queries catalog and finds sensor capabilties and processing services that can potentially supply the requested features • Catalog returns EO-1 and other data sources as possible source via Catalog Services for the Web (CSW). • Access to high resolution EO-1 data is granted based on user/role permission • No recent EO-1 data is available for the disaster site, so satellite tasking is required and achieved (at no cost to DHS) via DSS Optimizing Scheduler and SPS service • Analyst is notified via instant message that Hyperion/ALI data products are available. High resolution imagery is retrieved via SOS, WCS and WFS services • Analyst requests data processing to extract desired features from EO-1 data and Workflow Engine executes data processing algorithms in response • Processed features are overlaid on maps, annotated by the analyst, and shared with other users via blog, wiki, and/or forum

13. Benefits of Architecture

14. Our First Sensor Web Experiment with EO-1 National Priority Wildfires Fire location confirmed and selected for imaging 3 Science Goal Monitor 1 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 Correlate latest fire location information with MODIS imagery 4 5 EROS Data Center L1 Data Roberts Fire UMD Natural HazardsInvestigation Team 6 Active Fires Detection Map Aqua or Terra MODIS data Roberts Fire USFS Burned Area Emergency Response (BAER) team

15. End product of Event Driven Service Chain Burned Area Reflectance Classification (BARC) map - used by Forestry Service to efficiently rehabilitate burned areas

16. Often times the Features Were Correlated or Superimposed on Maps Burned areas – red Unburned areas – green Burn perimeter –blue MODIS Rapid Response Active Fire Detections Map EO-1 Advanced Land Imager Burn Scar Image

17. Piru/Simi/Verdale MODIS Old/Padua ALI MODIS ALI MASTER Landsat 5 Cedar/Paradise SPOT AirDAS Also Needed to Implement Horizontal Sensor Data Fusion Across Multiple Sensors such as for This Set of Images of Southern California Wildfires • Assets used: • EO-1 • SPOT • Aqua & Terra (MODIS) • Terra (ASTER) • Landsat 5 • MASTER • Aircraft (ER-2) based MODIS & ASTER • AirDas • Airborne Infrared Disaster Assessment System

18. Evolving Sensor Web Experiment to New OGC Compliant Architecture – Demo 1 SPS Implementation Area of Interest EO-1 Tasking Menu Selection

19. The Architecture Behind the SPS for EO-1 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

20. Other Targeted Activities Complete SensorML discovery process demonstration Add authentication services between nodes Create a variety of WPS as standard services from the already available onboard classifiers used on EO-1 such as thermal, clouds, floods, ice, etc. Demonstration of optimization for task scheduling and coordination of multiple assets Add NASA/Ames Unmanned Aerial System (UAS) to sensor web with services (see next two slides) Use Instrument Remote Control (IRC) to control various sensors

21. Vince Ambrosia, PI 12-Channel Wildfire Scanner Specifications Channel 1: 0.42 - 0.45 um Channel 2: 0.45 - 0.52 um Channel 3: 0.52 - 0.60 um Channel 4: 0.60 - 0.62 um Channel 5: 0.63 - 0.69 um Channel 6: 0.69 - 0.75 um Channel 7: 0.76 - 0.90 um Channel 8: 0.91 - 1.05 um Channel 9: 1.55 - 1.75 um Channel 10: 2.08 - 2.35 um Channel 11: 3.60 - 3.79 um (VIIRS M12) Channel 12: 10.26 -11.26 um (VIIRS M15) FOV: 42.5 or 85.9 degrees (selectable) IFOV: 1.25 mrad or 2.5 mrad (selectable) Spatial Res.: 3 – 50 meters (altitude dependant) General Atomics Altair UAS Also compatible with the GA Mariner, Predator-B & Cessna Caravan C208. • Targeting input from NIFC, MODIS Rapid Response, and GOES. • Onboard, real-time geolocation and product generation for both imagery and fire detects. • Browse and fire detects available via Google Earth interface within ca. 4 minutes. • Cal/Val coordination with MODIS Land Team and CEOS-LPV. • Activities in plan with AIST PIs for SensorWeb implementation in concert with MODIS and EO-1.

22. At the request of California Gov. Schwarzenegger, the FAA issued an emergency COA to fly the Altair UAS with the NASA WRAP payload into civilian airspace to support the Esperanza Fire incident command. #2 Climb to altitude using Edwards AFB restricted airspace. #1 Take off from GA / El Mirage. #3 Esperanza Fire 96 images collected (including conincident with MODIS). Altair UAS Flight Line 10/28 pm & 10/29/06 am.

23. Conclusion Integrating sensors with open source, interoperable reusable science services facilitates the vision of Global Earth Observing System of Systems Creating these open services lowers the cost of performing science analysis and creating new methods, thus expanding the user base for the geospatial community. With the OGC or similar standards, any set of sensors can become a virtual sensor web Data volume is greatly reduced since only virtual products are stored and desired products produced on-demand

24. Glossary BPEL – Business Processing Execution Language DSS -- Decision Support System ebRIM -- Enterprise Business Registry Information Model SOS – Sensor Observation Service CSW – Catalog Services For the Web SPS – Sensor Planning Service GMSEC – Goddard Mission Services Evolution Center WCS – Web Coverage Service IRC – Instrument Remote Control WCTS – Web Coordinate Transformation Service SAS – Sensor Alert Service (Pub/Sub) WFS – Web Feature Service WMS – Web Map Service WPS – Web Processing Service

25. Backup Slides

26. Underlying “Plug and Play” Message Bus Architecture-- Goddard Mission Services Evolution Center (GMSEC) GMSEC architecture provides a scalable and extensible ground and flight system approach • Standardized messages formats • Plug-and-play components • Publish/Subscribe protocol • Platform transparency • ST5 first mission to be totally GMSEC compliant More info at: http://gmsec.gsfc.nasa.gov

27. Example of Rapid Mission Configuration Using GMSEC Interoperable Catalog Components GMSEC approach gives users choices for the components in their system. The ST-5 mission rapidly selected key components from the GMSEC catalog.

28. Core Flight Executive (cFE), an Extension for GMSEC for Flight SW cFE provides a framework that simplifies the development and integration of applications • Layered Architecture – software of a layer can be changed without affecting the software of other layers • Components communicate over a standard message-oriented software bus, therefore, eliminating the need to know the details of the lower layers of inter-networking. • Software components can be developed and reused from mission to mission. • Developed by Flight SW Branch at GSFC • To be used on LRO • More info at: http://gmsec.gsfc.nasa.gov

29. Instrument Remote Control (IRC) IRC is an extensible and flexible architecture that can control a wide variety of instrumentation • XML based instrument descriptions • Based in Instrument Markup Language (IML) • Object-oriented architecture implemented in JAVA • Easy user interface • Used by: • Center for Astrophysical Research in Anarctica (CARA) • Stratospheric Observatory for Infrared Astronomy (SOFIA) – HAWC and SAFIRE • More info at: http://pioneer.gsfc.nasa.gov/public/irc IRC

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

31. Various EO-1 Sensor Web Experiments Conducted