1. HMA Follow On Activities
Task 2: Feasibility Analysis Service
(Sensor Planning Service) PR
2 February 2010
Reuben Wright, Deimos Space
Alexandre Robin, Spot Image
Corentin Guillo, Astrium (if necessary, by telephone)

2. Sensor Feasibility Reference Environment
Project Management
Schedule and Progress
Actions and Deliverables
Specifications
SWE Service Model and sweCommon
SPS 2.0 (OGC )
SPS Extension for EO (OGC )
Sensor Feasibility Reference Environment
Requirements
Design
Cross specification issues for discussion

3. Schedule 1/2

4. Schedule 2/2

5. Progress by Work Package
WP 1000: Project Office
Ongoing: Progress Meetings, HMA Wiki updates, coordination
WP 2000: Completion of the SPS Specifications
At RFC: Core SPS 2.0 (09-000), SWE Service Model (09-001), SWE Common Data Model (08-094). Draft: SPS Profile for EO (07-018)
WP 3000: Sensor Feasibility Reference Environment
On schedule: Requirements completed, design work has begun
WP 4000: SPS Profile for EO - Test Suite
ATS draft: ATS delayed slightly to match rest of specification completion schedule and the tailoring to OGC specification model
WP 5000: Additional Environments, WP 6000: Warranty
Not yet scheduled to start

6. Proposal Information: List of Documentation Deliverables

7. Proposal Information: List of Software Deliverables

8. Actions from 19/01/10 26
closed
YC to upload to HMA-FO wiki the "HMA Scenario" technical note created by Astrium in HMA-I to provide a start for High Level requirements/scenarios (but note that terminology will have changed and some aspects are out of date).
HMA-FO-DMS-PMD-MOM02
01/12/2009 1
SPB
04/12/2009 27
open
Where possible updates to match the OGC specification model will be attempted before March TC. In particular to ensure we have appropriate Abstract Test Suites and some high level view. List of reqs from HMA Scenario document to be considered for the high level requirements summary. 2
ALL
08/03/2010 28
IPR situation means RW can copy OGC draft specifications to HMA Wiki rather than just links (this action replaces Action 9 of previous teleconf). 3
Deimos
11/12/2009 29
RW to add SPS EO draft to HMA wiki to show latest progress. This will be updated to the RFC package when finalised.
HMA-FO-DMS-PMD-MOM04
19/01/2010
21/01/2010 30
Cross-specification discussion with OWS Common group about if/how the Notifications information could be moved to OWS Common once it has been used in SPS.
Spot
31/03/2010 31
AR to send swe Common RFC package to YC and PGM
22/01/2010 32
RW to add swe Common RFC package to wiki. 33
A slide is to be added to the presentation, to show which RFCs are with Carl and OAB and which are to come, and the timing of these before issuing presentation along with minutes.
Will be shown in PR also

9. Status of SPS 2.0, SWE Common Data, SWE Service Common
All RFC packages have been added to the OGC private twiki and portal. SWE Common Data Model standard fully complies with new OGC Specification Model.
The commenting phase will start once the documents are approved by OAB and Carl Reed.
Process
30 day comment period (not started yet due to delays in the OAB)
Review of comments during Spring 2010
Final versions at least three weeks prior to TC meeting June, 2010
TC in June 2010: SWG and TC/PC votes to release for adoption
60 day IPR review and eVote

10. Work in Progress: SPS Extension for EO
Status
Document reorganized to comply with the OGC specification model. Added documentation for FeasibilityLevel, FeasibilityID and FeasibilityExpirationDate, and description of output parameters.
Final document will be presented at Frascati TC in March and released to OAB for the RFC phase.
Review of comments expected to take place before September TC in Toulouse, France where it can be moved forward for adoption.
Work Remaining
Further numbered requirements – some identified already and others under discussion.
ATS – first draft following recommended format from HMA-T – to be aligned to match requirements and requirements classes of the spec.

11. SWE Common Data Model 2.0 Specification – Intro
Previously integrated to SensorML 1.0
Now separate standard for clarity and to ease its use in conjunction with several SWE standards (SPS, SOS, SensorML, O&M, WPS for SWE, etc…)
Define low level building blocks for description of datasets and process inputs and outputs
SPS tasking parameters are described using SWE Common data components which provide a detailed description of the required input
SPS EO also uses the SWE Common Data Model to describe feasibility study results and detailed status information 11

12. SWE Common Data Model 2.0 Specification – Status
Work on 2.0 began at Potsdam TC in June 2008
Specification work occurred within the SWE Common SWG which met at all TC since then (2 hours sessions on average), and during regular telecons (bi-weekly)
Work of SWE Common took longer because it impacts other SWE specifications and thus the standard needs to satisfy requirements from many communities
UML models, XML schemas, Schematron and document produced by Spot Image
Document finalized and uploaded to SWG twiki and portal in January 2010, then submitted to OGC for OAB review and RFC (now waiting for OAB approval)
Fully compliant with new OGC Specification Model r3 12

13. SWE Common Data Model 2.0 Specification – Spec Design
Document organized into requirements classes that match conformance classes in the Abstract Test Suite
Model Driven approach - XML schemas generated automatically from UML models by following formal rules (similar to GML application schemas) implemented by FullMoon
UML models built from HollowWorld ISO models repository. UMLs compliant with ISO 19103, 19111,
Use of GML data types and elements
Data components pluggable within GML application schemas (substitutable for gml:AbstractValue) 13

14. SWE Common Data Model 2.0 Specification – Spec Content
Core Requirements class
High level concepts
Data representation
Semantics of measured properties
Time, space and projected quantities
Quality, lineage and traceability
Units of measure and category code spaces
Structure and encoding 14

15. SWE Common Data Model 2.0 Specification – Spec Content
UML Conceptual Models – 5 requirements classes
Simple data components (data types) = Scalars
Aggregate data components = Records and Vectors
Block data components = Arrays and Matrices
Simple encodings = Text and XML
Advanced encodings = Binary + compressed 15

16. SWE Common Data Model 2.0 Specification – Spec Content
XML Implementation – 5 requirements classes
Simple data components (data types) = Scalars
Aggregate data components = Records and Vectors
Block data components = Arrays and Matrices
Simple encodings = Text and XML
Advanced encodings = Binary + compressed
Implements UML models and associated requirements
Provide XML Schemas and Schematron patterns 16

17. SWE Common Data Model 2.0 Specification – Spec Content
Abstract Test Suite
~100 requirements
One test for each requirements
Requirements classes mapping to conformance classes 17

18. SWE Service Model 2.0 Specification – Intro
Previously duplicated in SOS 1.0, SPS 1.0 and SAS drafts
Now extracted as separate standard to allow better reuse of concepts that are constant across all SWE services (= reuse of code in implementations)
The SWE Service Model is NOT a replacement for OWS Common. It is fully compliant with OWS Common and adds sensor specific concepts and data structures
Includes a section on notifications based on WS-Notification. Some of it could be described in OWS Common to harmonize across all OGC services (i.e. not only SWE!) 18

19. SWE Service Model 2.0 Specification – Status
Work on 2.0 began at Athens TC in March 2009
Specification work occurred within the SWE Common SWG which met at all TCs since then (2 hours sessions on average), and during regular telecons (bi-weekly)
SWG charter had to be changed to incorporate the new SWE Service Model specification
UML models, schemas and document produced by IGSI
Document finalized and uploaded to SWG twiki and portal in December 2009, then submitted to OGC for OAB review and RFC (now waiting for OAB approval) 19

20. SWE Service Model 2.0 Specification – Spec Design
Specification organized into (UML) packages ~ requirements classes
Model Driven approach - XML schemas generated automatically from UML models by following formal rules (similar to GML application schemas) implemented by FullMoon
UML models built from HollowWorld ISO models repository. UMLs compliant with ISO 19107, 19108, 19136
Use of GML data types and elements, use of OWS Common data types and elements
ATS for exception handling, extension handling, capabilities section and common operations, SOAP binding 20

21. SWE Service Model 2.0 Specification – Spec Content
Skeleton for Capabilities Content Section 21

22. SensorDescriptionUpdated
SWE Service Model 2.0 Specification – Spec Content
Notification Topics
Topic name
Events posted on topic
Encoding of the event
CapabilitiesChanged
CAPABILITIES_CHANGED
SWESEvent (see clause 8.2.4)
code value shall be “CAPABILITIES_CHANGED”
OfferingAdded
OFFERING_ADDED
OfferingChanged (see clause 8.2.6)
code value shall be “OFFERING_ADDED”
OfferingDeleted
OFFERING_DELETED
code value shall be “OFFERING_DELETED”
SensorInserted
SENSOR_INSERTED
SensorChanged (see clause 8.2.7)
code value shall be “SENSOR_INSERTED”
SensorDescriptionUpdated
SENSOR_DESCRIPTION_UPDATED
SensorDescriptionUpdated (see clause 8.2.8)
code value shall be “SENSOR_DESCRIPTION_
UPDATED” 22

23. SWE Service Model 2.0 Specification – Spec Content
Common Extension Mechanism 23

24. SWE Service Model 2.0 Specification – Spec Content
DescribeSensor Operation 24

25. SWE Service Model 2.0 Specification – Spec Content
UpdateSensor Operation 25

26. SWE Service Model 2.0 Specification – Spec Content
InsertSensor Operation 26

27. SWE Service Model 2.0 Specification – Spec Content
DeleteSensor Operation 27

28. SWE Service Model 2.0 Specification – Spec Content
Service Exceptions 28

29. SWE Service Model 2.0 Specification – Spec Content
Identifiers Usage
How to specify an identifier and reference it
Use of GenericName in SWE = Possibility to have a code space or not
Use of GML data types for XML encoding 29

30. Sensor Planning Service 2.0 Specification – Intro
Revised to better harmonize with other SWE services
Better use of SWE Common Data Model components
Added full support for notifications using WS-Notification
New optional operations for task reservation (Reserve/Confirm)
Improved documentation of task state model 30

31. Sensor Planning Service 2.0 Specification – Status
Work on 2.0 began at Valencia TC in December 2008
Specification work occurred within the SPS 2.0 SWG which met at all TCs since then (1 hour sessions on average), and during regular telecons (bi-weekly)
UML models, schemas and document produced by IGSI
Document finalized and uploaded to SWG twiki and portal in December 2009, then submitted to OGC for OAB review and RFC (now waiting for OAB approval)
Unfortunately not compliant with OGC specification model (08-131r3) 31

32. Sensor Planning Service 2.0 Specification – Spec Content
Asynchronous Request Lifecycle 32

33. Sensor Planning Service 2.0 Specification – Spec Content
Task Lifecycle 33

34. Sensor Planning Service 2.0 Specification – Spec Content
Concurrency 34

35. Sensor Planning Service 2.0 Specification – Spec Content
Mandatory Interface (Operation Group) 35

36. Sensor Planning Service 2.0 Specification – Spec Content
Optional Interfaces (Operation Group) 36

37. Sensor Planning Service 2.0 Specification – Spec Content
Exceptions 37

38. Sensor Planning Service 2.0 Specification – Spec Content
Consistent Model 38

39. Need to reintroduce FeasibilityStudy class
Sensor Planning Service 2.0 Specification – Spec Content
Consistent Model
Need to reintroduce FeasibilityStudy class 39

40. Sensor Planning Service 2.0 Specification – Spec Content
Capabilities Content Section 40

41. Sensor Planning Service 2.0 Specification – Spec Content
WS-Notification
Submit
Sensor ID, Tasking Parameters
Submit Response
Task ID (or Task EPR), Initial Status
Subscribe
SPS
Client
Consumer Reference (EPR), Topic Filter = (Task ID, Event Type)
Subscribe Response
Subscription Reference (EPR)
NotificationMessage (or Raw Message)
Producer/Subscription References (EPR), Topic, Message
GetStatus
Task ID, since 41

42. Sensor Planning Service 2.0 Specification – Spec Content
Polling mode for light clients or behind firewall
Submit
Sensor ID, Tasking Parameters
Submit Response
Task ID (or Task EPR), Initial Status
… Wait around ½ ToC …
GetStatus
SPS
Client
Task ID, since
GetStatus Response
Status Report with estimated ToC
… Wait around ½ ToC …
GetStatus
Task ID, since
GetStatus Response
Status Report with estimated ToC 42

43. SPS Extension for EO 2.0 Specification – Intro
Specification of specific EO satellite tasking parameters and feasibility info
Aligned with SPS 2.0
Addition of Validate and GetSensorAvailability operations
Reorganization in requirements classes
Will be fully compliant with OGC specification model 43

44. SPS Extension for EO 2.0 Specification – Status
Work started beginning of 2009
Waited for SPS to be completed
Last minute additions to compensate for lack of description in SPS 2.0
Will be fully compliant with OGC specification model
Scheduled to be released for RFC after March TC
Should be ready for vote before September TC in Toulouse 44

45. SPS Extension for EO 2.0 Specification – Spec Design
Five Requirements Classes are defined
SPS parameters for all EO missions
SPS parameters for optical missions
SPs parameters for radar missions
GetSensorAvailability operation
Validate operation 45

46. SPS Extension for EO 2.0 Specification – Spec Content
SPS Tasking Parameters for all missions 46

47. SPS Extension for EO 2.0 Specification – Spec Content
SPS Tasking Parameters for all missions 47

48. SPS Extension for EO 2.0 Specification – Spec Content
SPS Tasking Parameters for all missions 48

49. SPS Extension for EO 2.0 Specification – Spec Content
SPS Tasking Parameters specific to Optical and Radar 49

50. SPS Extension for EO 2.0 Specification – Spec Content
SPS Tasking Parameters specific to Optical and Radar 50

51. SPS Extension for EO 2.0 Specification – Spec Content
SPS Feasibility Study Parameters 51

52. SPS Extension for EO 2.0 Specification – Spec Content
SPS Status Parameters 52

53. SPS Extension for EO 2.0 Specification – Spec Content
GetSensorAvailability 53

54. SPS Extension for EO 2.0 Specification – Spec Content
Validate 54

55. SPS Extension for EO 2.0 Specification – Spec Content
Additional Notification Topics
SEGMENT SCHEDULED
SEGMENT ACQUIRED
SEGMENT VALIDATED
TASK_IN_PROGRESS 55

56. SPS Application Profile for EO - Abstract Test Suite
Five Conformance Classes are defined
SPS for Earth Observation – test cases covering all mandatory requirements to be satisfied by a minimally conformant SPS for EO implementation;
Optical Sensor – test cases addressing the extra requirements for an Optical instrument;
Radar Sensor – test cases addressing the extra requirements for a Radar instrument;
Sensor Availability – test cases addressing the extra requirements for supporting the operation "GetSensorAvailability" defined in this EO Profile;
Validate – test cases addressing the extra requirements for supporting the operation "Validate" defined in this EO Profile;

57. SPS Extension for EO - Abstract Test Suite
SPS had three Test Groups
Common Test Elements – related to the GetCapabilities Request and Response;
Exception Reporting – related to the errors generated during the Operations;
Request / Response Handling – related to the nominal performance of Operations, including validation of the accepted requests, as related to the SPS Extension definitions;
SPS for EO adds a further Test Group
Notification – related to the ability to subscribe to Notifications;
Open Issues/Questions
Assumption is that the SPS for EO server is tested in terms of its conformance to the interface standard, not the accuracy of its planning results (eg. in suggesting scenes fully covering area)

58. Work in Progress: SFRE Requirements
Requirements Baseline Document
Drafted and in discussion
Requirements derived from Operational Scenarios Technical Note have been included
System Requirements Document
Some requirements from DAIL were of relevance to the Sensor Feasibility Client
Issues
Possible addition of requirement for order system to get details of feasibility request based on ID

59. Work in Progress: SFRE Design
Architecture Design Document
Sensor Feasibility Server follows on from HMA-T developments and large parts of design are being reused. Updates to design (and document) will be made reflecting experience of HMA-T, and new requirements
Sensor Feasibility Client again follows from some existing development work and some documentation reuse is anticipated
Interface Control Documents
The relevant OGC specifications are considered the authoratative ICDs for the system

60. SFRE system will consist of two different sub-systems:
SFRE Design
SFRE system will consist of two different sub-systems:
Sensor Feasibility Client (SF Client)
Sensor Feasibility Server (SF Server)

61. SF Server SF Server Notification Service Sensor Planning Service
Internal Sensor
Planning System +
StudyFeasibility()
SF Client
CFI Wrapper
SPS Library
SPS Controller
GetCapabilities()
DescribeSensor()
GetSensorAvailability()
Validate()
DescribeTasking()
GetFeasibility()
Submit()
GetStatus()
Cancel()
Update()
DescribeResultAccess()
Reserve()
Confirm()
Radar Mission 1
Radar Mission 2
Optical Mission 1
Optical Mission 2
SOAP reader/writer (Axis)
Earth Explorer Mission CFI
Notification Library
1..* 1
SF Server

62. SF Server Components Web server SOAP Reader/Writer SPS controller
Apache Tomcat
Endpoint where the clients can connect
Components forming the SF Server implementation will be deployed as web application
SOAP Reader/Writer
Axis 2
Serializes and deserializes SOAP message contents
SPS controller
Web Service that exposes an SPS EO (07-018) interface
Logic of the system, in charge of the control and management of incoming requests and the creation of the appropriate responses.

63. Internal Sensor Planning System
SF Server Components
SPS Library
Converts SPS requests coming from SPS clients into java objects that will be used by the SPS controller
Validates parameters as per their SWE Common definition
Internal Sensor Planning System
Performs feasibility studies for four simulated missions:
Radar Synchronous Mission – all feasibility requests processed immediately
Radar Asynchronous Mission which makes use of the Notification Service
Optical Synchronous Mission
Optical Asynchronous Mission

64. Mission Simulation configuration
SF Server Components
Mission Simulation configuration
Accessed by the Internal Planning System
Includes the (very simple) modeling of:
Sensor unavailability
Weather conditions
Station unavailability
Unavailability conditions are configured by editing the associated configuration files
Earth Explorer Mission CFI
Performs accurate computations of mission related parameters for Earth Explorer missions
Jave version being considered. If the C++ version is used then it will be accessed through a wrapper based on JNI framework

65. SF Server Components Notification Service
Web Service responsible for sending notifications to the client when it has subscribed for some event types
All the SPS operations are synchronous in the sense of the server returning an immediate SOAP or XML response to the client
However there are certain operations where the internal processing may take some time. In those cases the synchronous response will return an identifier to use to subscribe for notifications
The subscriptions offered by the Notifications System follow the topics in the SPS 2.0 Specifcation

66. SF Server operation with asynchronous processing response

67. For discussion: SPS and Ordering services
Suggested that Order Submit can take as input a Feasibility-ID (SPS-ID)
Raises an issue for the order/programming scenario to be demonstrated at the end of the project unless both services are physically at the same location and communicate between them
Possible additional SPS operations to obtain the metadata of pseudo-scenes from an SPS ID
Get the task history (ID, creation date, status, operation)
Get a single task by ID (ID, creation date, status, operation, request and response)
SFRE Scenarios

68. For discussion: EO Product Parameters
Parameters used in SPS to specify which products would be valid
SWE Common definitions
SPS Application Profile for EO has lists of names, definitions and semantics of suggested parameters
Profiles for Optical, and Radar missions
Future profiles anticipated (eg Atmospheric missions)
There are separate definitions for product metadata
Clear need for harmonisation where possible
SFRE Scenarios