1. HMA Follow On Activities
Task 2: Feasibility Analysis Service
(Sensor Planning Service)
Final Presentation
20 July 2011
Reuben Wright, Deimos Space

2. Overview
Objectives
Achievements
Document Deliverables
Specifications
Software
Future work
Demonstration

3. Objectives
I25. The completion of the work initiated in the HMA contract, on feasibility analysis service at the moment specified as OpenGIS® Sensor Planning Service Application Profile for EO Sensors OGC to
I25.1 specify unambiguously the interactions, taking into account the issues already identified in current version of the document
Published and adopted as Earth Observation Extension for Sensor Planning Service (EO SPS 2.0)
I25.2 The alignment of the specification with the evolving OGC “SWECommon” and SPS 2.0
Active work to complete all three of these “supporting” specifications. All published and adopted

4. Objectives
I25.3 Completely specify all the operations: GetCapabilities, DescribeTasking, GetFeasibility, Submit, DescribeResultAccess
All these and GetStatus, Reserve, Confirm, DescribeSensor, GetSensorAvailability, Validate and WS-Notifications
I26. The design, development and testing of an open source Sensor Feasibility Reference Environment to be used by the Agency as a reference server and client to be used both for the testing and demonstration of the relevant specification
Both Server and Client developed, tested and released open source. Demonstrations later

5. Objectives
I27 – I29. The Sensor Feasibility Reference Environment shall support optical and radar missions, support systematic instruments (see e.g. MERIS, atmospheric), be configurable to simulate the presence of at least 4 missions (2 optical, 2 radar), sensor unavailability, station unavailability and weather conditions. Linux based.
There are 4 missions, with MERIS swath supported. Server simulates all unavailabilities, and the responses (eg a failure due to weather) are displayed by the Client. URL based web admin and local configuration files
I30. The definition of an abstract test suite and an executable test suite to be executed via the OGC TEAM engine
Full ATS complementing the requirement classes. ETS to the extent possible within OGC TEAM Engine

6. Deliverables FP

7. Specifications
Three specifications were written and gained OGC adoption:
sweCommon 2.0 (Data Model and Service Model)
Sensor Planning Service 2.0
EO Extension for Sensor Planning Service 2.0
Compliant with the OGC Specification Model – A Standard for Modular Specification - OGC r3

8. Published as OGC 08-094 and OGC 09-001
sweCommon FP
Published as OGC and OGC
Comprises SWE Common Data Model and SWE Common Service Model.
Specifications published at:
Schemas published at:
Used by:
Sensor Planning Service, Ordering Service, Processing Service

9. Provides a set of Data Models
SWE Data Model – OGC FP
Provides a set of Data Models
Low level data models for exchanging sensor related data
Allow applications and/or servers to structure, encode and transmit sensor datasets
Structures are self describing
Structures can be linked to semantic definitions

10. SWE Service Model – OGC 09-001FP
Provides the following packages of datatypes and operations
Contents – data types for sensor services
Notification – data types for notification capabilities, and also definition and encoding of SWES events
Common - common data types for other packages
Common Codes – commonly used lists of codes with semantics
DescribeSensor – operation to retrieve sensor metadata
UpdateSensorDescription – operation to modify sensor description
InsertSensor – operation
DeleteSensor – operation

11. Sensor Planning Service 2.0
Specifications published at:
Schemas published at:
Provides a set of operations to:
Query about the capabilities of a sensor and how to task it
Determine the feasibility of a sensor planning request
Submit and reserve/commit a request
Find out the status of a request
Update or cancel such a request
Request information about access to the data collected

12. Sensor Planning Service 2.0 Operations 1/2FP
Mandatory Interface (Operation Group) 12

13. Sensor Planning Service 2.0 Operations 2/2FP
Optional Interfaces (Operation Group) 13

14. EO Sensor Planning Service 2.0
Specifications published at:
Schemas published at:
Provides an extension to SPS specifically for EO:
New Operations to support the way the industry works
Defined and registered common parameters to aid interoperability
New operations to:
Validate acquisitions made in response to a task
Find long term information on the availability of a sensor
Submit tasking requests related to individual segments of a task

15. EO Sensor Planning Service 2.0 Parameters
Tasking Parameters
for all missions (eg. how to specify Region and Time of interest)
for Optical (eg. MinLuminosity)
for Radar (eg. polarizationMode)
Validation Parameters
for Optical (eg. MaxCloudCover)
for Radar (eg. maxNoise)
Parameters are in OGC registry
Includes names, datatypes and semantics
Allows reuse
Allows RDF/Ontology support to link semantics to other definitions

16. EO Sensor Planning Service 2.0 Executable Test Suite
Executable Test Suite written in CTL
In the EO SPS Abstract Test Suite there are 31 core tests:
Have implemented 23 of these tests as a first release ETS.
Any limitations are documented in the test scripts.
The parts not implemented are because the specification says it is:
to be a manual check or to run a different ETS (for the core SPS), or require TEAM Engine to be able to handle asynchronous testing.

17. EO SPS 2.0 Executable Test Suite - Reusable functionFP
Provides ability to modify a provided set of parameters programatically. This means a “base” request can be edited to create the various test messages.
<ctl:call-function name="ModifyRequest">
<ctl:with-param name="Request" select="."/>
<ctl:with-param name="Modifications">
<Element name="procedure" namespace=" text="{$sensorID}"/>
<Element name="GetFeasibility" namespace="
<swes:extension>
<eo:FeasibilityLevel>COMPLETE</eo:FeasibilityLevel>
</swes:extension>
</Element>
</ctl:with-param>
</ctl:call-function>

18. EO SPS 2.0 Improvements from 0.9.5
All operations synchronous, but compatible with asynchronous processes
Based on sweCommon 2.0
Choice
Optional values / sections
Nil values
Use of sweCommon simplified and optimized
Description of parameters not in GetFeasibility and Submit requests anymore (only in DescribeTasking)
Parameters value can be sent using XML, binary or ASCII, optionally without tags
Progress Report section used in several operations

19. EO SPS 2.0 Improvements from 0.9.5
WS_Notification
No need for server on client side (WS-Addressing is a big issue in case of firewall)
Any number of subscribers
Subscriptions can be cancelled and/or modified at any time
Notifications can be sent to any support (sms, , etc.)
New operations (Reserve-Confirm, Validate, GetSensorAvailability)
Matches the OGC Specification Model including linked Requirement and Conformance Classes

20. SFRE Development (SF Client and SF Server)
Fully working reference implementations – client and server
All the EO SPS Operations have been successfully implemented:
GetCapabilities, GetSensorAvailability
DescribeSensor, DescribeTasking
GetFeasibility, Submit
Cancel, Update, Validate
Reserve, Confirm
GetStatus, DescribeResultAccess
SF server also implements Notifications
Code is Open Source:

21. Other (non-Open Source) code
SPOT Image SPS Server
Deployed at:
SF Client configured to use it (as well as SF Server)
Ad hoc SF Client testing and ETS testing has been carried out
Not Open Source.
Earth Explorer CFI
Used in SF Server, with the libraries included in the delivered code.
Collection of multiplatform precompiled C libraries for timing, coordinate conversions, orbit propagation, satellite pointing calculations, and target visibility calculations.
SF Server does not include the source code of the software. Library is provided under the Earth Observation CFI Licence Terms and Conditions -

22. DecribeSensor responses
Future Work
DecribeSensor responses
SensorML document containing information about the EO instrument being tasked and the satellite platform that carries it.
This profile will ideally build on a generic “discovery profile” of SensorML to which we add more specific metadata for EO sensors and platforms
Make sure to reference ISO descriptions of data collections, so that there will be consistency 
Orchestration between services
End to End workflows (eg within GSCDA)
Extension of such work as HMA Cookbook and various documents covering service interactions (eg SPS – Ordering, SPS – WCS)
Promotion, extension, integration of reference software

23. SF Feasibility Client basic UI
Demonstration
SF Feasibility Client basic UI
Globe, layers, past requests, ability to specify acquisition details
Parallel requests to SF Server, SPOT Server GetFeasibility / Submit
Display of server responses
Text of responses and Footprints plotted on the globe
Simulated acquisitions (servers on “fast forward”)
Visual status display in SF Client GetStatus
Ability to find details of the products DescribeResultsAccess
Links to: FTP, HTTP, Ordering Service, Web Catalogue Service
More sophisticated workflow possible Reserve – Confirm - Validate

24. Thanks for listening Questions Any Questions?