1

Terra (MODIS)

Making Space-based Sensors Discoverable on the Internet Using A Service Oriented Architecture and Open Geospatial Consortium Standards January 16, 2007

Dan Mandl NASA/GSFC

EO-1(ALI & Hyperion)

Aqua (MODIS)

MODIS Active Fire Map

Sensor Planning Services (SPS)

Co-authors:Rob Sohlberg/Univ. of Md.Stu Frye/MitreTekPat Cappelaere/VightelSteve Ungar/GSFCTroy Ames/GSFCSteve Chien/JPL

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

Reference Architecture for an Inter-Operable Sensor Web

IRCIRC

GMSECGMSEC

SensorSensor

L1G

SOS

WFS

SPS

SAS

SOS

WFS

SPS

SAS

Sensor Planning Service (SPS)

Sensor Planning Service (SPS)

Sensor Alert Service (SAS)Sensor Alert

Service (SAS)

SensorObservation

Service (SOS)

SensorObservation

Service (SOS)

Web Feature Service (WFS)Web Feature

Service (WFS)

SensorML

Capabilities

Documents

Satellite Data Node

EO-1 SatelliteEO-1Satellite

In-s

itu

Sen

sor

Dat

a N

od

e

UA

V S

enso

r D

ata

No

de

SensorML

SensorML

Sa

tell

ite

se

ns

or

da

ta p

rod

uc

t

DEMIS

"Thin" Web Client(blog, wiki, IM,

forum)

Web Processing

Service(WPS)

Web Processing

Service(WPS)

Web Coverage Service(WCS)

Web Coverage Service(WCS)

Web Coordinate

Transformation Service(WCTS)

Web Coordinate

Transformation Service(WCTS)

Catalog RegistryCatalog Service for Web (CSW)(Product Features and Service Capabilities)

Service Chain

XMLSCRIPT

Workflow Engine

L1G

SOS

WFS

SPS

SAS

SOS

WFS

SPS

SAS

Instantiation Service

Instantiation Service

OptimizerScheduler

OptimizerScheduler

SensorML

Capabilities

Documents

Decision Support System & Tools

DataProcessing Node

Map

Web MapService

Discover

Register

Register

Execute

Analysis/SimulationAnalysis/Simulation

Concrete Workflow

Check Workflow Feasibility

Workflow EditorWorkflow Editor

GeospatialProcessingModels

Register

Execute

Requested data from sensor data nodes or data processing nodes via Internet

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

Current Way Vision for New Way

Method to develop new algorithms

Custom (license fees)

Open source building blocks (no fees)

Interoperability Low High

Cost to create & implement new algorithms/service chains

High Low

Data storage and transfer requirements

High: Store/archive and transfer all sensor data

Modest to Low: Filter and transfer only needed features; archive virtual products

Ease of finding and reusing existing algorithms

Difficult Easy with automatic discovery

14

1

Identify NIFC-tracked Wildfire Incidents

Aqua or TerraMODIS data

Science Goal Monitor

2

4

UMD Natural Hazards Investigation Team

5

3

3

Active Fires Detection Map

Roberts Fire

Roberts Fire

1

Roberts FireUSFS Burned Area Emergency Response (BAER) team

6

Correlate latest fire location information with MODIS imagery

SGM adds target to EO-1 ground & on-orbit planning & scheduling systems and tasks EO-1

L1 Data

Our First Sensor Web Experiment with EO-1 National Priority Wildfires

Fire location confirmed and selected for imaging

EROS Data Center

15

End product of Event Driven Service Chain Burned Area Reflectance Classification (BARC) map -

used by Forestry Service to efficiently rehabilitate burned areas

16

MODIS Rapid ResponseActive Fire Detections Map

EO-1 Advanced Land ImagerBurn Scar Image

Burned areas – redUnburned areas – greenBurn perimeter –blue

Often times the Features Were Correlated or Superimposed on Maps

17

Piru/Simi/Verdale

Cedar/Paradise

MODIS

ALI

MASTER

MODIS

ALI

Landsat 5

SPOT

AirDAS

Old/Padua

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

EO-1 Tasking Menu Selection

Area of Interest

19

The Architecture Behind the SPS for EO-1

WWW

GSFCUSGSJPL

ASPEN

FDSS

White Sands

ASIST

rawsciencedata

trackingdata

goals

telemetry

overflights

weekly goals

targets, engineering requests

targets

targets

daily goals

ScienceProcessing

EO-1

CASPER

ScienceProcessing

SCLactivities

commands

sciencedata

goals

stationin-views

contacts

processedsciencedata

Onboard EO-1

Note that engineer and mission planner removed

SPS

SOA Users

targets

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

General Atomics Altair UAS

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)

• 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.

Also compatible with the GA Mariner, Predator-B & Cessna Caravan C208.

Vince Ambrosia, PI

22

Altair UAS Flight Line 10/28 pm & 10/29/06 am.

#3

EsperanzaFire

96 images collected(including conincident

with MODIS).

#1Take off

from GA /El Mirage.

#2Climb to

altitude usingEdwards AFB

restricted airspace.

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.

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

GlossaryBPEL – 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

GMSEC approach gives users choices for the components in their system. The ST-5 mission rapidly selected key components from the GMSEC catalog.

Example of Rapid Mission Configuration Using GMSEC Interoperable Catalog Components

Middlewares: GSFC Bus, ICS SWB, TIBCO Rendezvous, TIBCO SmartSockets, RTI NDDS, SOAP, MQSeries, ICE

Front End Processors+ Simulators

GMSEC APIs/Ops Systems

Linux

Solaris

C, C++

J ava

Python

HP/UX

Telemetry + CommandSystems

ASIST

ITOS

TReK

Desk TM

InControlNG

ScriptingControlGDS

FEDS

FFTB

IRTS

SIMSS

STARS

Python

SCL

Automation

ANS

CAT

Pag

ing

ScenarioScheduler

ExpertSystems

Planning +Scheduling

AMPS

MOPSS

STK/Scheduler

Flight Dynamics

STK

MTASS

MSASS

XFDS

Archive + Assessment

Tre

ndin

gS

yste

ms

RPTS

SystemMonitoring

ITPS

TAPS

MTASS

Archiving

SimulinkROME

MacOSHigh

Fly/SCOS

VisualFocus

Front End Processors+ Simulators

GMSEC APIs/Ops Systems

Solaris

C, C++

Python

HP/UX

Telemetry + CommandSystems

ASIST

ITOS

TReK

Desk TM

InControlNG

ScriptingControlGDS

FEDS

FFTB

SIMSS

STARS

Python

SCL

Automation

ANSPag

ing

ExpertSystems

Planning +Scheduling

AMPS

STK/Scheduler

STK

MTASS

MSASS

XFDS

Archive + Assessment

Tre

ndin

gS

yste

ms

RPTS

SystemMonitoring

ITPS

TAPS

MTASS

Archiving

SimulinkROME

MacOS

FlexPlan

VisualFocus

IRTSANSR

IRTSScenarioScheduler

IRTSCAT

IRTSPPF

IRTSGREAT

Windows

IRTSLinux

FocusConstellation

AutoFDS

IRTSMOPSS

IRTSST5

Eclipse

Java

Usage Key:

IRTS

PerlPerl

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