1. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 1 HMA SPS Mandatory I/F Development HMA-T Phase 2 KO Meeting 2-3 July 2008, Frascati Ricardo Moyano, DEIMOS Space Reuben Wright, DEIMOS Space Philippe Merigot, SPOT Image

2. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 2  Objectives  ITT and Proposal information HMA-T team Work Breakdown Structure Deliverables Schedule DEIMOS SPS SPOT SPS

3. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 3 This project aims at :  The implementation of a SPS EO library  The implementation, based on this library, of two SPS Profile for Earth Observation (OGC 07-018) interoperability standards defined within the HMA contract:  SPOT IMAGE SPS EO – optical  DEIMOS SPS EO – radar  The full life cycle process for the two software developments, starting from the generation/update of the Requirement Baseline up to the validation of the interface at the development platform. Objectives All documentation shall be generated for each development phase following the tailored ECSS standards from the Statement Of Work.

4. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 4 Proposal Information: HMA-T SPS Team

5. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 5 Proposal Infromation: WBS

6. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 6 Proposal Information: List of Deliverables

7. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 7 Schedule : HMA “short” schedule shall be applied

8. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 8 Reviews and Payment Plan Milestone%Date KOM20T0 (03/07/08) AR-170T0 + 7m (02/02/09) FP10T0 + 18m (03/06/09) Notes  In our proposal, only one travel is foreseen (this one!)

9. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 9 Proposal Information: SPS development (1/2) SPS is dedicated to the EO Sensor domain complying with specification OGC 07-018. The operations part of the contract are aimed at: Determining the request and receive service metadata describing the abilities of the specific server implementation (GetCapabilities) Requesting information needed to send GetFeasibility and Submit requests (DescribeTasking) Determining the feasibility of an intended sensor planning request (GetFeasibility) Submitting such a request (Submit) Retrieving information about how and where data (produced by the sensor) can be accessed (DescribeResultAccess)

10. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 10 Proposal Information: SPS development (2/2) SPOT System connector Deimos CFI- based System

11. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 11 Proposal Information: Development issues The proposal describes the implementation complying with version 1.0 of OGC 07-018.  We will need finalised inputs from the SPS Application Profile standardisation. The proposal describes the implementation complying with version 1.0 of OGC 07-018.  The Requirements and Software specification will follow directly from the Use Cases identified  Validation testing must not be confused with conformance testing. Validation shall follow the ECSS approach comprising test case and test procedure specifications.

12. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 12 Proposal Information: DEIMOS SPS – Technical Approach (1/3)  SPS SOAP interface will be developed “Contract first” using Web Service Description Language (http://www.w3.org/TR/wsdl).http://www.w3.org/TR/wsdl  The Java code stubs are then generated via a framework – Axis – this is an Apache project.  The SPS I/F shall then be developed, utilising the core library and accessing the existing CFI sensor planning system.  SPS I/F server will be deployed on an Apache Tomcat server. No client software deliverable is anticipated.

13. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 13 Proposal Information: DEIMOS SPS – Technical Approach (2/3) CFI-based System

14. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 14 Proposal Information: DEIMOS SPS – Technical Approach (3/3) Earth Explorer Mission Software CFI  Existing sensor planning library, ie. a COTS to this project.  Collection of software functions performing accurate computations of mission related parameters.  Computes time segments at which an Earth Explorer satellite, or one of its instruments is in view of various targets.  Implemented in C but will be accessed in Java code via a Java Native Interface (JNI).  Can simulate a variety of Earth Explorer missions, such as GOCE, CryoSat and Aeolus. We will decide early on in the project the details of the Radar planning system we wish to simulate.

15. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 15 Proposal Information: SPOT SPS overview Client SPS Request SPS Response Mapping Spot Image SPS PRM request PRM response Deserialization Req validity check Serialization EO LIB XML sweCommon request response Java objects XML sweCommon PRM Spot Image Programming System

16. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 16 SOAP Framework HTTP Servlet SPS Message Deserializer SWE Common Reader SPS Message Serializer SWE Common Writer XML Tree Objects (i.e. DOM) XML Tree Objects Byte Stream Ground Segment Connector EO Writer Helper EO Reader Helper SPS Message Java Object Users, Tasks DB Programming Orders Feasibility Studies Apache Tomcat Apache Axis SPS Library Programming Status Notification System Subscrip- tion DB Sensor Params DB GS Specific Feasibility Report Proposal Information: SPOT SPS in details

17. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 17  Simplify the life of implementer  Contains a Low-level module (sweCommon) that can be reused by other WS  Improve Interoperability SPS Lib : key points

18. Frascati, 2-3 July 2008 SPS Mandatory I/F Development Slide 18  New SPS v2.0 specification will be the basis for the SPS EO Profile (i.e. part of the Requirement Baseline)  Spec currently under construction via the SPS SWG at OGC. HMA SPS EO Profile 1.0 will follow shortly  Should simplify the life of implementers. More consistent with other SWE standards and notifications are optional  EO Profile specification will reuse more of the core SPS and define specific data structures used in EO (hopefully better than in v0.9.5)  Target for SPS 2.0 draft: September 2008 (TC Atlanta, USA) Target for SPS 2.0 final: December 2008 (TC Valencia, Spain) SPS specification : key points