Making agricultural knowledge globally discoverable: are we there yet?
1 Terra (MODIS) Making Space-based Sensors Discoverable on the Internet Using A Service Oriented...
Transcript of 1 Terra (MODIS) Making Space-based Sensors Discoverable on the Internet Using A Service Oriented...
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
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