sofftwwa arree vvaalliiddattiioonn ssppeecciificcaattiioonn

DEIMOS Space S.L.U.

Ronda de Poniente, 19, Edificio Fiteni VI, 2-2ª

28760 Tres Cantos (Madrid), SPAIN

Tel.: +34 91 806 34 50 / Fax: +34 91 806 34 51

E-mail: [email protected]

© DEIMOS Space S.L.U.

RESTRICTED

DMS-DQS-QREVV01-VVP-20-E

Code : HMA-FO-DMS-VVR-SVS01-E-R

Issue : 1.0

Date : 05/10/10

Name Function Signature

Prepared by Reuben Wright

Corentin Guillo

DEIMOS Project Manager

Astrium Ltd Project Manager

Reviewed by Teresa Garcia Project Team

Approved by Reuben Wright Project Manager

Signatures and approvals on original

HMA Follow On. Task 2: Feasibility Analysis Service

(Sensor Planning Service)

SSooffttwwaarree VVaalliiddaattiioonn SSppeecciiffiiccaattiioonn

HHMMAA--FFOO FFeeaassiibbiilliittyy AAnnaallyyssiiss SSeerrvviiccee


Code : HMA-FO-DMS-VVR-

VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 2 of 105


RESTRICTED


This page intentionally left blank




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 3 of 105


RESTRICTED


DDooccuummeenntt IInnffoorrmmaattiioonn

Contract Data

Contract Number: 22506/09/I-LG

Contract Issuer: ESA

Internal Distribution

Name Unit Copies

Reuben Wright MOS 1

Teresa García MOS 1

Internal Confidentiality Level (DMS-COV-POL05)

Unclassified Restricted Confidential

External Distribution

Name Organisation Copies

Corentin Guillo Astrium Ltd 1

Archiving

Word Processor: MS Word 2000

File Name: HMA-FO-DMS-VVR-SVS01-10-E-R.doc




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 4 of 105


RESTRICTED


DDooccuummeenntt SSttaattuuss LLoogg

Issue Change description Date Approved

1.0 First draft of the document 05/10/10




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 5 of 105


RESTRICTED


TTaabbllee ooff CCoonntteennttss

1. INTRODUCTION _____________________________________________________________ 19

1.1. Purpose ________________________________________________________________________ 19

1.2. Objective and Content ____________________________________________________________ 19

2. RELATED DOCUMENTS ______________________________________________________ 20

2.1. Applicable Documents ____________________________________________________________ 20

2.2. Reference Documents ____________________________________________________________ 20

2.3. Standards ______________________________________________________________________ 21

2.4. Acronyms and Abbreviations ______________________________________________________ 21

2.5. Definitions ______________________________________________________________________ 22

3. SOFTWARE OVERVIEW ______________________________________________________ 23

3.1. Static View _____________________________________________________________________ 23

3.2. Behavioural View ________________________________________________________________ 27

4. Software validation specification task identification __________________________________ 30

4.1. Task and criteria ________________________________________________________________ 30

4.1.1. Tasks and Items under test ______________________________________________________ 30

4.1.1.1. Organization ______________________________________________________________ 30

4.1.1.2. Standard, Practices and Conventions ___________________________________________ 30

4.1.1.3. Items under test ____________________________________________________________ 31

4.1.2. Criteria ______________________________________________________________________ 31

4.2. Features to be tested _____________________________________________________________ 31

4.3. Features not to be tested __________________________________________________________ 31

4.4. Test pass - fail criteria ____________________________________________________________ 31

4.5. Items that cannot be validated by test _______________________________________________ 32

5. Software validation testing specification design ______________________________________ 33

5.1. Test Design Overview ____________________________________________________________ 33

5.2. Test Design TD-0010: SF Server and SF Client Deployment ____________________________ 33

5.2.1. Features to be tested ___________________________________________________________ 33

5.2.2. Approach refinements __________________________________________________________ 33

5.3. Test Design TD-0020: EO Extension for SPS 2.0 Operations ____________________________ 33






VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 6 of 105


RESTRICTED


5.4. Test Design TD-0030: SF Client and SF Server interaction _____________________________ 39



6. Software validation test case specification __________________________________________ 42

6.1. Test Case TD-0010/TC-0010: SF Server Installation, Configuration, Start-up ______________ 42

6.1.1. Inputs and Outputs specifications _________________________________________________ 42

6.1.2. Feature pass/fail criteria ________________________________________________________ 42

6.1.3. Environmental needs ___________________________________________________________ 42

6.1.4. Special procedural constraints ____________________________________________________ 42

6.1.5. Interfaces dependencies _________________________________________________________ 43

6.2. Test Case TD-0010/TC-0020: SF Client Installation, Configuration, Start-up ______________ 43






6.3. Test Case TD-0030/TC-1000: SF Client requests the SF Server capabilities ________________ 44






6.4. Test Case TD-0030/TC-1010: SF Client requests for a Sensor description _________________ 44






6.5. Test Case TD-0030/TC-1020: SF Client requests for the Sensor availability ________________ 45









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 7 of 105


RESTRICTED


6.6. Test Case TD-0030/TC-1030: SF Client requests for the information needed to perform a

feasibility analysis ___________________________________________________________________ 46






6.7. Test Case TD-0030/TC-1040: SF Client requests for a synchronous sensor feasibility analysis 46






6.8. Test Case TD-0030/TC-1050: SF Client requests for a asynchronous sensor feasibility analysis 47






6.9. Test Case TD-0030/TC-1060: SF Client requests for a multi synchronous sensor feasibility

analysis ____________________________________________________________________________ 48






6.10. Test Case TD-0030/TC-1070: SF Client requests for a multi asynchronous sensor feasibility

analysis ____________________________________________________________________________ 48

6.10.1. Inputs and Outputs specifications ________________________________________________ 48

6.10.2. Feature pass/fail criteria _______________________________________________________ 48

6.10.3. Environmental needs __________________________________________________________ 49

6.10.4. Special procedural constraints ___________________________________________________ 49

6.10.5. Interfaces dependencies ________________________________________________________ 49

6.11. Test Case TD-0030/TC-1080: SF Client requests for a multi sensor (synchronous and

asynchronous) feasibility analysis ______________________________________________________ 49





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 8 of 105


RESTRICTED






6.12. Test Case TD-0030/TC-1090: SF Client requests for a synchronous sensor acquisition ______ 50






6.13. Test Case TD-0030/TC-1100: SF Client requests for an asynchronous sensor acquisition ___ 50






6.14. Test Case TD-0030/TC-1110: SF Client requests for a multi synchronous sensor acquisition_ 51






6.15. Test Case TD-0030/TC-1120: SF Client requests for a multi asynchronous sensor acquisition 52







asynchronous) acquisition ____________________________________________________________ 52









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 9 of 105


RESTRICTED


6.17. Test Case TD-0030/TC-1140: SF Client requests for a synchronous sensor reservation _____ 53






6.18. Test Case TD-0030/TC-1150: SF Client requests for an asynchronous sensor reservation ___ 54






6.19. Test Case TD-0030/TC-1160: SF Client requests for a multi synchronous sensor reservation 54






6.20. Test Case TD-0030/TC-1170: SF Client requests for a multi asynchronous sensor reservation 55







asynchronous) reservation ____________________________________________________________ 56






6.22. Test Case TD-0030/TC-2000: Sensor unavailability ___________________________________ 56







VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 10 of 105


RESTRICTED




6.23. Test Case TD-0030/TC-2010: Station unavailability __________________________________ 57






6.24. Test Case TD-0030/TC-2020: Weather conditions ____________________________________ 59






7. Software Validation Test Procedures ______________________________________________ 61

7.1. TP-0010: SF Server Installation, Configuration, Start-up _______________________________ 61

7.2. TP-0020: SF Client Installation, Configuration, Start-up _______________________________ 62

7.3. TP-0030: Automated testing of SF Server using Executable Test Suite ____________________ 65

7.4. TP-0040: SF Client based testing of information operations _____________________________ 66

7.5. TP-0050: SF Client based testing of Synchronous operations ____________________________ 67

7.6. TP-0060: SF Client based testing of Asynchronous operations ___________________________ 76

7.7. TP-0070: SF Client based testing of multi-sensor requests ______________________________ 84

7.8. TP-0080: SF Server simulation of unavailabilities _____________________________________ 87

8. Software validation by analysis, inspection, review of design ___________________________ 91

9. Validation test platform requirements _____________________________________________ 93

9.1. Test Platform ___________________________________________________________________ 93

9.2. Network Architecture ____________________________________________________________ 93

10. Requirement traceability matriX ________________________________________________ 94

10.1. Requirements vs. Test cases traceability matrix ______________________________________ 94

11. Software Validation Test Reporting _____________________________________________ 103

12. Directory structure for file-based tests ___________________________________________ 105

1. INTRODUCTION _____________________________________________________________ 12

1.1. Purpose ________________________________________________________________________ 12

1.2. Objective and Content ____________________________________________________________ 12




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 11 of 105


RESTRICTED


2. RELATED DOCUMENTS ______________________________________________________ 13

2.1. Applicable Documents ____________________________________________________________ 13

2.2. Reference Documents ____________________________________________________________ 13

2.3. Standards ______________________________________________________________________ 14

2.4. Acronyms and Abbreviations ______________________________________________________ 14

2.5. Definitions ______________________________________________________________________ 15

3. SOFTWARE OVERVIEW ______________________________________________________ 16

3.1. Static View _____________________________________________________________________ 16

3.2. Behavioural View ________________________________________________________________ 20

4. Software validation specification task identification __________________________________ 23

4.1. Task and criteria ________________________________________________________________ 23

4.1.1. Tasks and Items under test ______________________________________________________ 23

4.1.1.1. Organization ______________________________________________________________ 23

4.1.1.2. Standard, Practices and Conventions ___________________________________________ 23

4.1.1.3. Items under test ____________________________________________________________ 24

4.1.2. Criteria ______________________________________________________________________ 24

4.2. Features to be tested _____________________________________________________________ 24

4.3. Features not to be tested __________________________________________________________ 24

4.4. Test pass - fail criteria ____________________________________________________________ 24

4.5. Items that cannot be validated by test _______________________________________________ 25

5. Software validation testing specification design ______________________________________ 26

5.1. Test Design Overview ____________________________________________________________ 26

5.2. Test Design TD-0010: SF Server and SF Client Deployment ____________________________ 26



5.3. Test Design TD-0020: EO Extension for SPS 2.0 Operations ____________________________ 26



5.4. Test Design TD-0030: SF Client and SF Server interaction _____________________________ 32



6. Software validation test case specification __________________________________________ 35

6.1. Test Case TD-0010/TC-0010: SF Server Installation, Configuration, Start-up ______________ 35





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 12 of 105


RESTRICTED






6.2. Test Case TD-0010/TC-0020: SF Client Installation, Configuration, Start-up ______________ 36






6.3. Test Case TD-0030/TC-1000: SF Client requests the SF Server capabilities ________________ 37






6.4. Test Case TD-0030/TC-1010: SF Client requests for a Sensor description _________________ 37






6.5. Test Case TD-0030/TC-1020: SF Client requests for the Sensor availability ________________ 38






6.6. Test Case TD-0030/TC-1030: SF Client requests for the information needed to perform a

feasibility analysis ___________________________________________________________________ 39









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 13 of 105


RESTRICTED


6.7. Test Case TD-0030/TC-1040: SF Client requests for a synchronous sensor feasibility analysis 39






6.8. Test Case TD-0030/TC-1050: SF Client requests for a asynchronous sensor feasibility analysis 40






6.9. Test Case TD-0030/TC-1060: SF Client requests for a multi synchronous sensor feasibility

analysis ____________________________________________________________________________ 41






6.10. Test Case TD-0030/TC-1070: SF Client requests for a multi asynchronous sensor feasibility

analysis ____________________________________________________________________________ 41







asynchronous) feasibility analysis ______________________________________________________ 42






6.12. Test Case TD-0030/TC-1090: SF Client requests for a synchronous sensor acquisition ______ 43





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 14 of 105


RESTRICTED






6.13. Test Case TD-0030/TC-1100: SF Client requests for an asynchronous sensor acquisition ___ 43






6.14. Test Case TD-0030/TC-1110: SF Client requests for a multi synchronous sensor acquisition_ 44






6.15. Test Case TD-0030/TC-1120: SF Client requests for a multi asynchronous sensor acquisition 45







asynchronous) acquisition ____________________________________________________________ 45






6.17. Test Case TD-0030/TC-1140: SF Client requests for a synchronous sensor reservation _____ 46









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 15 of 105


RESTRICTED


6.18. Test Case TD-0030/TC-1150: SF Client requests for an asynchronous sensor reservation ___ 47






6.19. Test Case TD-0030/TC-1160: SF Client requests for a multi synchronous sensor reservation 47






6.20. Test Case TD-0030/TC-1170: SF Client requests for a multi asynchronous sensor reservation 48







asynchronous) reservation ____________________________________________________________ 49






6.22. Test Case TD-0030/TC-2000: Sensor unavailability ___________________________________ 49






6.23. Test Case TD-0030/TC-2010: Station unavailability __________________________________ 50







VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 16 of 105


RESTRICTED




6.24. Test Case TD-0030/TC-2020: Weather conditions ____________________________________ 52






7. Software Validation Test Procedures ______________________________________________ 54

7.1. TP-0010: SF Server Installation, Configuration, Start-up _______________________________ 54

7.2. TP-0020: SF Client Installation, Configuration, Start-up _______________________________ 55

7.3. TP-0030: Automated testing of SF Server using Executable Test Suite ____________________ 58

7.4. TP-0040: SF Client based testing of information operations _____________________________ 59

7.5. TP-0050: SF Client based testing of Synchronous operations ____________________________ 60

7.6. TP-0060: SF Client based testing of Asynchronous operations ___________________________ 69

7.7. TP-0070: SF Client based testing of multi-sensor requests ______________________________ 77

7.8. TP-0080: SF Server simulation of unavailabilities _____________________________________ 80

8. Software validation by analysis, inspection, review of design ___________________________ 84

9. Validation test platform requirements _____________________________________________ 86

9.1. Test Platform ___________________________________________________________________ 86

9.2. Network Architecture ____________________________________________________________ 86

10. Requirement traceability matriX ________________________________________________ 87

10.1. Requirements vs. Test cases traceability matrix ______________________________________ 87

11. Software Validation Test Reporting ______________________________________________ 96

12. Directory structure for file-based tests ____________________________________________ 98




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 17 of 105


RESTRICTED


LLiisstt ooff TTaabblleess

Table 1: Applicable documents ....................................................................................................................... 20

Table 2: Reference documents ........................................................................................................................ 20

Table 3: Standards ........................................................................................................................................... 21

Table 4: HMA-FO SFRE Components ........................................................................................................... 23

Table 5: Test Case identification for TD-0020 ................................................................................................ 34


Table 7: Test Case TD-0010/TC-0010 Inputs and Outputs specifications ...................................................... 42



Table 10: Test Case TD-0030/TC-2050 Inputs and Outputs specifications .................................................... 58


Table 12: TP-0010 Procedure .......................................................................................................................... 61








Table 20: Text Execution Record template ................................................................................................... 103

Table 1: Applicable documents ....................................................................................................................... 13

Table 2: Reference documents ........................................................................................................................ 13

Table 3: Standards ........................................................................................................................................... 14

Table 4: HMA-FO SFRE Components ........................................................................................................... 16











VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 18 of 105


RESTRICTED










Table 20: Text Execution Record template ..................................................................................................... 96




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 19 of 105


RESTRICTED


11.. IINNTTRROODDUUCCTTIIOONN

This document concerns the HMA-FO project Task 2: Feasibility Analysis Service (Sensor Planning

Service) devoted to complete the specification of the Earth Observation Satellite Tasking Extension for

OGC Sensor Planning Service 2.0 [RD 1], and the design, development, testing and documentation of a

Sensor Feasibility Reference Environment (SFRE) that shall be used by ESA for the testing and

demonstration of the relevant specification.

11..11.. PPuurrppoossee

The purpose of this Software Validation Specification document with respect to the requirement

baseline is to describe all the validation activities to be carried out during the software life cycle of

HMA-FO Task 2 and the schedule, resources, methods and techniques needed to perform those

activities.

The intended readerships for this document are ESA, Spacebel and the HMA-FO development teams at

SPOT Image, Astrium Ltd, and Deimos Space.

11..22.. OObbjjeeccttiivvee aanndd CCoonntteenntt

The document will indicate how to validate that the completed end product complies with established

software and user requirements.

The goal of this activity is to reduce software errors as much as possible and to assure that the final

products implements the required functionalities.. The SFRE will be validated against the requirements

defined in the Software Requirements Specification [AD 8].

This document is organised as follows:

Section 1 provides the purpose, scope and this document’s overview

Section 2 provides the lists of related documents, acronyms and definitions

Section 3 contains an overview of the Sensor Feasibility Reference Environment

Section 4 provides the identified tasks for carrying out the verification activity

Section 5 contains the Test Designs

Section 6 contains the Test Cases

Section 7 contains the Test Procedures

Section 8 provides, for items where a test is not possible, another validation method based on

analysis, inspection, or review of design

Section 9 provides information on the validation test platform

Section 10 contains traceability matrices of test cases w.r.t. requirements and vice versa.

Section 11 provides information on the test reporting

Section 12 provides the directory structure to be used for file-based tests




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 20 of 105


RESTRICTED


22.. RREELLAATTEEDD DDOOCCUUMMEENNTTSS

22..11.. AApppplliiccaabbllee DDooccuummeennttss

The following table specifies the applicable documents that shall be complied with during project

development.

Table 1: Applicable documents

Reference Code Title Issue

[AD 1] SGSE-DFPR-EOPG-SW-08-0001 Statement of Work – HMA Follow on activities 1.2

[AD 2] Appendix 3 to ESRIN/AO/1-

5949/09/I-LG

Special Conditions Of Tender -

[AD 3] RES-POE/2009/34/LG/cb Letter with the Invitation to Tender AO/1-

5949/09/I-LG – HMA Follow On

-

[AD 4] Appendix 2 to ESRIN/AO/1-

5949/09/I-LG

Contract – HMA Follow on activities -

[AD 5] HMAFO-MOM-0001-SPB Minutes of the negotiation meeting held at

ESRIN on 24 June, 2009

-

[AD 6] HMA-FO-DMS-PMD-PMP01-E-R Project Management Plan 1.0

[AD 7] HMA-FO-DMS-TEC-SSS01-E-R Software System Specification 1.1

[AD 8] HMA-FO-DMS-TEC-SRS01-E-R Software Requirements Specification 1.1

[AD 9] HMA-FO-DMS-TEC-SDD01-E-R Software Design Document 1.0

22..22.. RReeffeerreennccee DDooccuummeennttss

The following table specifies the reference documents that shall be taken into account during project

development.

Table 2: Reference documents


[RD 1] OGC 10-135 Earth Observation Satellite Tasking Extension for

OGC® Sensor Planning Service 2.0

2.0

[RD 2] OGC 09-000 OpenGIS® Sensor Planning Service

Implementation Standard

2.0




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 21 of 105


RESTRICTED


22..33.. SSttaannddaarrddss

The following table specifies the standards that shall be complied with during project development.

Table 3: Standards


[ECSS-40C] ECSS-E-ST-40C Space Engineering Software Standards -

22..44.. AAccrroonnyymmss aanndd AAbbbbrreevviiaattiioonnss

The acronyms and abbreviations used in this document are the following ones:

Acronym Description

DMS DEIMOS Space

ECSS European Cooperation on Space Standardization

EO Earth Observation

ESA European Space Agency

HMA Heterogeneous Missions Accessibility

ICD Interface Control Document

N/A Not Applicable

OGC Open Geospatial Consortium Inc.

RID Review Item Discrepancy

SAR Synthetic Aperture Radar

SDD Software Design Document

SFRE Sensor Feasibility Reference Environment

SOAP Simple Object Access Protocol

SoW Statement of Work

SPR Software Problem Report

SPS Sensor Planning Service

SSS Software System Specification

SRS Software Requirements Specification

SVS Software Validation Specification

TC Test Case

TD Test Design

TS Test Specification

TP Test Procedure




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 22 of 105


RESTRICTED


Acronym Description

UML Unified Modelling Language

22..55.. DDeeffiinniittiioonnss

The definitions of the specific terms used in this document are the following ones:

Verification: Confirmation, through the provision of objective evidence, that specified requirements

have been fulfilled [ISO 9000:2000]

NOTE: verification process (for software) is the process to confirm that adequate specifications and

inputs exist for any activity, and that the outputs of the activities are correct and consistent with the

specifications and input.

Validation: Confirmation, through the provision of objective evidence, that the requirements for a

specific intended use or application have been fulfilled [ISO 9000:2000]

NOTE: The validation process (for software) is the process to confirm that the requirements baseline

functions and performances are correctly and completely implemented in the final product.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 23 of 105


RESTRICTED


33.. SSOOFFTTWWAARREE OOVVEERRVVIIEEWW

33..11.. SSttaattiicc VViieeww

The SFRE components are presented in the table below.

Table 4: HMA-FO SFRE Components

System Component Description

SF Client Web Client This component is in charge to allow users to invoke SPS

operations (ie. To define and send requests to the SF Server and to display the results returned by the SF Server).

SF Client Web Server This component is an Apache Tomcat web server. The SOAP

Reader/Writer and SPS Library will be deployed within the

Web Server. The Web Server is responsible for the communication between the Web Client and the SF Server.

SF Client SOAP

Reader/Writer This component is responsible of the SOAP envelope

extraction from incoming responses as well as appending the

SOAP header to the built requests.

It serializes and de-serializes SOAP message contents.

SF Client SPS Library The SPS library component is responsible for de-serializing

SPS responses coming from SF Server into java objects and serializing SPS requests sent to the SF Server

SF Client Database A database is used on the client side to store the requests and

responses

SF Server Web server This component shall be an Apache Tomcat web server,

where the clients can connect to, and where the various

components conforming the SPS implementation will be

deployed.

SF Server SPS controller Web Service that exposes an SPS EO interface. This is the

core element that holds the logic of the system, in charge of

the control and management of incoming requests and the creation of the appropriate responses.

SF Server SOAP

Reader/Writer This component is an external library charged with the SOAP

envelope extraction from incoming requests as well as

appending the SOAP header to the built response prior to

passing it to the web server for delivery to the client.

Furthermore, along with the SPS Library it serializes and

deserialises SOAP message contents. It shall support version

1.1 and 1.2 of the SOAP specification.

SF Server SPS Library The SPS library component is responsible for:

Desterilising SPS requests coming from SPS clients into

java objects that will be used by the SPS controller;




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 24 of 105


RESTRICTED



Serializing java objects generated by SPS controller into

SPS responses;

SF Server Notification

Service

This component is a Web Service responsible for sending

notifications to the client when it has subscribed for some events.

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 and identifier to use with an

associated notification web service.

The operator can then subscribe to get notifications (using the

WS Base Notification standard) about the progress of the operation.

SF Server Internal Sensor

Planning System

This component will perform feasibility studies based on

Earth Explorer CFI technology. It will be configured in order to expose four simulated missions:

Radar Mission 1: Radar Synchronous Mission.

Radar Mission 2: Radar Asynchronous Mission. It makes

use of the Notification Service to provide an asynchronous

response to the client.

Optical Mission 1: Optical Synchronous Mission.

Optical Mission 2: Optical Asynchronous Mission. It

makes use of the Notification Service to provide an

asynchronous response to the client.

The simulation will be done via a number of configuration

files that will be processed by the Internal Planning System

and it will include the modeling of a number of conflicts/constraints as listed here:

Sensor unavailability

Weather conditions

Station unavailability

These unavailability conditions shall be configurable by the edition of the associated configuration file.

SF Server CFI Wrapper Based on JNI (framework that allows Java code running on a

Java Virtual Machine to call native applications written in

other languages) this component encapsulates the interactions

with the Earth Explorer CFI library, written in C++.

SF Server Earth Explorer

Mission CFI

The Earth Explorer Mission Software is a collection of

classes and methods performing accurate computations of

mission related parameters for Earth Explorer missions.

SF Server Notification

Library

This component is an external library that assist in the

notification process including the serialisation/deserialisation




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 25 of 105


RESTRICTED



of the notification messages.

SF Server Database The database shall store the relevant information of the

system.

The following diagram shows the SF Client components and their interactions.

Figure 3-1: HMA-FO SF Client Component Diagram

The following diagram shows the SF Server components and some of the classes, and their interactions.

The grayed out elements are external components not developed in the scope of this project.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 26 of 105


RESTRICTED


cd HMA-FO Class Diagram

SF Serv er

Notification Serv iceSensor Planning Serv ice

Internal Sensor

Planning System

+ StudyFeasibil i ty()

SF Client

CFI Wrapper

SPS Library

SPS Controller

+ GetCapabil ities()

+ DescribeSensor()

+ GetSensorAvailabil ity()

+ Validate()

+ DescribeTasking()

+ GetFeasibil i ty()

+ 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

Figure 3-2: HMA-FO SF Server Component Diagram




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 27 of 105


RESTRICTED


33..22.. BBeehhaavviioouurraall VViieeww

The SF Client uses a web browser and established a connection through a Web Server to the SF

Server. The SF Client Web Server passes the SOAP messages to a SOAP Reader/Writer which uses

a shared SPS Library. These produce Java objects manipulated by the SPS Controller which is the

core of the system. It uses a Database for storage.

For asynchronous responses, the SF Client shall invoke periodically the GetStatus operation to update

the SF Client database.

The connection from SF Client is handled by the SF Server Web Server, which passes the SOAP

messages to a SOAP Reader/Writer which uses a shared SPS Library. These produce Java objects

manipulated by the SPS Controller which is the core of the system. It uses a Database for storage and

produces responses which are serialized by the SOAP Reader/Writer (again using the SPS Library)

and sent back to the Client through the Web Server. For the complex task of establishing the feasibility

of a request the SPS Controller passes the information to an Internal Sensor Planning System. This

system will either

1. produce a response immediately and inform the SPS Controller, which will store the response in

the Database and send the response to the client (SF Client), or

2. produce a response asynchronously and inform the SPS Controller, which will store the response in

the Database and trigger the Notification Service to contact the Client. The SPS controller

communicates with the Notification server by sending Notify SOAP messages (cf. [RD

Notifications]). The response data will be pulled out of the Database to provide a synchronous

response to a separate Client operation.

The following diagram shows the data flow in a representative case for asynchronous message

processing, where a response is sent immediately back to the client via the same HTTP connection but

further activity generates a Notify message. This then triggers the client to send a GetStatus to receive

the outcome of the processing:




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 28 of 105


RESTRICTED


Figure 3-3: Notification Service Uses Cases GetFeasibility asynchronous scenario

The following one describes a representative case for synchronous SOAP message exchange, where the

response is sent immediately back to the client via the same HTTP connection.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 29 of 105


RESTRICTED


Client

Web Serv er

SPS

SOAP Reader

Writer

SPS Library

DescribeTasking

DescribeTasking

extract_SOAP_Header

deserialize

create_response

serialize

create_SOAP_Header

describeTaskingResponse

describeTaskingResponse

Figure 3-4: Sequence diagram for a HTTP POST operation




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 30 of 105


RESTRICTED


44.. SSOOFFTTWWAARREE VVAALLIIDDAATTIIOONN SSPPEECCIIFFIICCAATTIIOONN TTAASSKK

IIDDEENNTTIIFFIICCAATTIIOONN

44..11.. TTaasskk aanndd ccrriitteerriiaa

44..11..11.. TTaasskkss aanndd IItteemmss uunnddeerr tteesstt

44..11..11..11.. OOrrggaanniizzaattiioonn

The QA Manager will ensure that the staff assigned to the system test activities have the necessary

experience, knowledge and skills to be able to carry out their assigned roles effectively and efficiently.

This assurance may include identifying the need for specific training, which may be met by attendance

to internal and/or external courses.

Test results will be provided in Test Report forms, which will be signed-off by the tester, the Project

Manager and the QA Manager.

Similarly, SPRs will be signed and authorised by the Project Manager and QA Manager before being

sent to the Customer for further processing.

44..11..11..22.. SSttaannddaarrdd,, PPrraaccttiicceess aanndd CCoonnvveennttiioonnss

Testing will follow a formal life-cycle approach consisting of the sequential execution of the following

activities:

1. Analysis of the problem domain, leading to the generation of Test Designs.

2. Analysis of the specific requirements belonging to the units under test, leading to the generation of

Test Case Specifications conformant with the overall test designs.

3. Analysis of the test execution environments, leading to Test Procedures that permit the execution of

the test case specifications.

4. Execution of the test procedures on the test execution environments.

5. Evaluation and reporting of the results of the test executions.

6. Generation of SPRs as and when a test result reveals an error in the unit under test.

7. Regression testing on receipt of a software change to correct an error reported in an SPR.

Note that steps 4 to 7 may be performed in parallel, for example, SPRs will be raised as soon as an error

is found, without waiting until all tests have been executed once. Similarly, regression testing will be

conducted as soon as it is considered convenient, not necessarily when all SPRs have been processed.

Traceability matrices will be maintained in order to trace from Test Case Specifications and Procedures

to Test Results and SPRs, in order to assure complete test coverage of the subject requirements.

Test Cases will be defined in terms of the following points:

Software requirements

Test Configuration




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 31 of 105


RESTRICTED


Test Inputs

Test Outputs

Pass/Fail Criteria

44..11..11..33.. IItteemmss uunnddeerr tteesstt

Tests are designed to verify features or sets of features of the system. One feature may correspond to

only one requirement or to a group of requirements.

The features that are to be tested correspond to the system requirements that are to be verified by test,

according to the validation method of the requirements as identified in the Software Requirements

Specification [AD 8].

Unit and integration testing will be carried out during development as required and formal System tests

will be specified below and carried out before formal presentations. The outputs will be recorded as Test

Execution Records and made available for review.

44..11..22.. CCrriitteerriiaa

As stated in the Software Requirements Specification [AD 8] various requirements are validated via

Inspection or Review, rather than Testing. These are not covered in the test cases or procedures, but are

detailed in Section 0.

44..22.. FFeeaattuurreess ttoo bbee tteesstteedd

This document is in charge of verifying all requirements listed in the Software Requirements

Specification [AD 8].

44..33.. FFeeaattuurreess nnoott ttoo bbee tteesstteedd

All requirements and features not reported in Software Requirements Specification [AD 8] are out of the

scope of this document.

44..44.. TTeesstt ppaassss -- ffaaiill ccrriitteerriiaa

This may be based on specifying explicitly the expected output, with an allowed tolerance between

expected and observed outputs.

It is expected that the outputs will be logged automatically, but checked and compared manually. That

is, it will be up to a test engineer to look at the test results and say whether the test was successful, rather

than relying on an automatic check (which might otherwise allow an error, which would be spotted by a

human operator, to slip through).




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 32 of 105


RESTRICTED


44..55.. IItteemmss tthhaatt ccaannnnoott bbee vvaalliiddaatteedd bbyy tteesstt

The Software Requirements Specification [AD 8] lists (in Section 5.1) the various validation methods

for the requirements. As well as Test (T) which needs "Execution of the element under certain

conditions to check the outputs corresponding to particular inputs" it lists:

Inspection (I) – Exhaustive evaluation of the code by manual reading;

Analysis (A) – Deduction method applied to documentation, code, test results, etc; it is partially

or totally automated;

Review (R) – Review of project documentation.

For these methods further details of the validation are contained in Section 0.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 33 of 105


RESTRICTED


55.. SSOOFFTTWWAARREE VVAALLIIDDAATTIIOONN TTEESSTTIINNGG SSPPEECCIIFFIICCAATTIIOONN

DDEESSIIGGNN

55..11.. TTeesstt DDeessiiggnn OOvveerrvviieeww

The testing is broken down into 3 different designs, based on the sequence of testing and the equipment

and personnel required.

Test Design TD-0010: SF Server and SF Client Deployment tests the ability to deploy the SFRE. It is a

prerequisite for the later testing. It requires the software packages and the chosen hardware.

Test Design TD-0020: EO Extension for SPS 2.0 Operations tests the SF Server in terms of its

compliance to the Abstract Test Suite (ATS) of the specification [RD 1]. It requires the SF Server to be

deployed, and also a Team Engine instance which can connect to it. Testing is automated.

Test Design TD-0030: SF Client and SF Server interaction tests the SF Server and SF Client in terms of

user interaction, and mission simulation. It requires the SF Server and SF Client to be deployed, and a

user to manually operate the SF Client and evaluate responses.

55..22.. TTeesstt DDeessiiggnn TTDD--00001100:: SSFF SSeerrvveerr aanndd SSFF CClliieenntt DDeeppllooyymmeenntt

55..22..11.. FFeeaattuurreess ttoo bbee tteesstteedd

This test design will check that the SF Server and the SF Client are correctly installed (i.e. deployed)

and its services can be correctly accessed.

55..22..22.. AApppprrooaacchh rreeffiinneemmeennttss

One test case TD-0010/TC-0100 will be designed in order to check that:

SFRE Web Server is correctly installed in the target platform and its services can be accessed.

A second test case TD-0010/TC-0200 will be designed in order to check that:

SF Client is correctly installed in the target platform and its services can be accessed.

55..33.. TTeesstt DDeessiiggnn TTDD--00002200:: EEOO EExxtteennssiioonn ffoorr SSPPSS 22..00 OOppeerraattiioonnss


This test design will check that the SFRE Web Server implements all the operations specified in [RD 1]

and provide adequate XML responses.


The Executable Test Suite (ETS) built in accordance to the ATS of [RD 1] provides automated report

generation on the conformance to the specification. Within the ETS the tests are organised according to

the conformance classes of the specification, ie.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 34 of 105


RESTRICTED


The following Test Cases constitute the ATS.

Table 5: Test Case identification for TD-0020

Test Case

Identifier URN in EO Extn for SPS 2.0 [RD 1]

Description

TD-

0020/TC-

0100

http://www.opengis.net/spec/EOSPS/2.0/conf/core/dependency-

sps Instances of the EO SPS service

satisfy requirements of SPS 2.0

TD-

0020/TC-

0110

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-

params-valid The DescribeTaskingResponse

document contains EO satellite

tasking parameters.

TD-

0020/TC-

0120


params-vendor Vendor specific tasking

parameters are optional

TD-

0020/TC-

0130


params-xml-encoding The XMLEncoding format

optional in SPS 2.0 is supported

TD-

0020/TC-

0140


params-root The DescribeTaskingResponse

contains the definition of

parameters for a coverage or

swath programming request

TD-

0020/TC-

0150

http://www.opengis.net/spec/EOSPS/2.0/conf/core/priority-

default STANDARD and HIGH priority

are supported via the Priority field

TD-

0020/TC-

0160

http://www.opengis.net/spec/EOSPS/2.0/conf/core/swath-

request-time A SwathProgrammingRequest

with invalid temporal parameters

is correctly rejected by the server

TD-

0020/TC-

0170

http://www.opengis.net/spec/EOSPS/2.0/conf/core/survey-

period-mandatory Single time periods are always

supported

TD-

0020/TC-

0180

http://www.opengis.net/spec/EOSPS/2.0/conf/core/time-series-

coherent A CoverageProgrammingRequest

containing a time series instance

with inconsistent parameters is

correctly rejected by the server

TD-

0020/TC-

0190

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-

level-default The FeasibilityLevel element is

taken into account

TD-

0020/TC-

0200


level-valid A GetFeasibility request

containing an invalid

FeasibilityLevel element is


TD-

0020/TC-

0210

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-

feasibility-id-used The ReferenceFeasibilityID

element is taken into account

http://www.opengis.net/spec/EOSPS/2.0/conf/core/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/core/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-vendor

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-vendor

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-xml-encoding

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-xml-encoding

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-root

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-root

http://www.opengis.net/spec/EOSPS/2.0/conf/core/priority-default

http://www.opengis.net/spec/EOSPS/2.0/conf/core/priority-default

http://www.opengis.net/spec/EOSPS/2.0/conf/core/swath-request-time

http://www.opengis.net/spec/EOSPS/2.0/conf/core/swath-request-time

http://www.opengis.net/spec/EOSPS/2.0/conf/core/survey-period-mandatory

http://www.opengis.net/spec/EOSPS/2.0/conf/core/survey-period-mandatory

http://www.opengis.net/spec/EOSPS/2.0/conf/core/time-series-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/time-series-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-level-default

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-level-default

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-level-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-level-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-used

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-used




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 35 of 105


RESTRICTED


Test Case


Description

TD-

0020/TC-

0220


feasibility-id-correct The ReferenceFeasibilityID

element references an active

feasibility study

TD-

0020/TC-

0230


feasibility-id-params A Submit or Reserve request with

tasking parameters different than

the ones used to generate the

reference feasibility study is


TD-

0020/TC-

0240


feasibility-id-valid The ReferenceFeasibilityID

extension element is valid

TD-

0020/TC-

0250


study-report Successful feasibility studies

include a detailed report

TD-

0020/TC-

0260


study-acc-obj-status Grid cells and segments always

have the POTENTIAL status

when inserted in the report of a

feasible request

TD-

0020/TC-

0270


study-rej-obj-status Grid cells and segments always

have the POTENTIAL or

REJECTED status when inserted

in the report of an unfeasible

request

TD-

0020/TC-

0280


study-valid The FeasibilityStudy element is

valid

TD-

0020/TC-

0290

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status Status reports of accepted tasks

include detailed information

TD-

0020/TC-

0300

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-

inc-segments Acquired segments are all listed in

the task status report

TD-

0020/TC-

0310


inc-cells Grid cells used for the feasibility

study are all listed in the task

status report

TD-

0020/TC-

0320


valid The ProgrammingStatus element

is valid

TD-

0020/TC-

0330

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-

coherent GridCell attributes are consistent

with the programming request

TD-

0020/TC-http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell- The CRS of the footprint polygon

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-correct

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-correct

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-params

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-params

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/ref-feasibility-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-report

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-report

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-acc-obj-status

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-acc-obj-status

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-rej-obj-status

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-rej-obj-status

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/feasibility-study-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-inc-segments

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-inc-segments

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-inc-cells

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-inc-cells

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-footprint-srs




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 36 of 105


RESTRICTED


Test Case


Description

0340 footprint-srs is EPSG 4326

TD-

0020/TC-

0350

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-

footprint-syntax The footprint polygon does not

contain holes and uses the posList

syntax

TD-

0020/TC-

0360

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-

coherent Segment attributes are consistent

with the programming request

TD-

0020/TC-

0370


footprint-syntax Segment footprint polygons

satisfy the same constraints as grid

cell footprint polygons

TD-

0020/TC-

0380


units Unit of measures are all SI units

TD-

0020/TC-

0390

http://www.opengis.net/spec/EOSPS/2.0/conf/core/prog-status-since The status report obtained by

calling the GetStatus operation

with a since parameter shall

contain only segments and grid

cell objects whose status has

changed after the date given in the

since parameter.

TD-

0020/TC-

0400

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/dependency-

core An implementation supporting the

optical extension is conformant

with the core of this standard

TD-

0020/TC-

0410

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-

params-used An implementation supporting the

optical extension uses the OPT

tasking parameters defined in this

standard.

TD-

0020/TC-

0420


params-codespace-gml A custom instrument mode code

space is URL accessible and GML

encoded

TD-

0020/TC-

0430

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-

params-codespace-default A custom instrument mode code

space includes the default spectral

modes

TD-

0020/TC-

0440

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/dependency-

core An implementation supporting the

SAR extension is conformant with

the core of this standard

TD-

0020/TC-

0450

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-

params-used An implementation supporting the

SAR extension uses the SAR

tasking parameters defined in this

standard.

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-footprint-syntax

http://www.opengis.net/spec/EOSPS/2.0/conf/core/gridcell-footprint-syntax

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-coherent

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-footprint-syntax

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-footprint-syntax

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-units

http://www.opengis.net/spec/EOSPS/2.0/conf/core/segment-units

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/dependency-core

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/dependency-core

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-params-used

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-params-used

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-codespace-gml

http://www.opengis.net/spec/EOSPS/2.0/conf/core/tasking-params-codespace-gml

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-params-codespace-default

http://www.opengis.net/spec/EOSPS/2.0/conf/opt/tasking-params-codespace-default

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/dependency-core

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/dependency-core

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-used

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-used




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 37 of 105


RESTRICTED


Test Case


Description

TD-

0020/TC-

0460


params-codespace A code space for SAR instrument

modes is defined

TD-

0020/TC-

0470


params-codespace-gml A custom SAR mode code space

is URL accessible and GML

encoded

TD-

0020/TC-

0480

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/capabilities The GetSensorAvailability request

is listed in the service capabilities

TD-

0020/TC-

0490

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/request-valid An invalid GetSensorAvailability

request is correctly rejected by the

server

TD-

0020/TC-

0500

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/response-

valid A GetSensorAvailability response

is valid with respect to the XML

schema

TD-

0020/TC-

0510

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/sensor-id-

valid An exception is returned when the

sensor identifier is invalid

TD-

0020/TC-

0520

http://www.opengis.net/spec/EOSPS/2.0/conf/val/capabilities The Validate request is listed in

the service capabilities

TD-

0020/TC-

0530

http://www.opengis.net/spec/EOSPS/2.0/conf/val/request-valid An invalid Validate request is


TD-

0020/TC-

0540

http://www.opengis.net/spec/EOSPS/2.0/conf/val/response-

valid A Validate response is valid with

respect to the XML schema

TD-

0020/TC-

0550

http://www.opengis.net/spec/EOSPS/2.0/conf/val/task-id-valid A Validate request with an invalid

task identifier is correctly rejected

by the server

TD-

0020/TC-

0560

http://www.opengis.net/spec/EOSPS/2.0/conf/val/segment-id-

valid A Validate request with an invalid

segment identifier is correctly

rejected by the server

TD-

0020/TC-

0570

http://www.opengis.net/spec/EOSPS/2.0/conf/val/manual-

validation-valid The ManualValidation element is

valid with respect to the XML

schema

TD-

0020/TC-

0580

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/capabilities The SubmitSegmentByID request

is listed in the service capabilities

TD-

0020/TC-

0590

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/response-valid An invalid SubmitSegmentByID

request is correctly rejected by the

server

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-codespace

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-codespace

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-codespace-gml

http://www.opengis.net/spec/EOSPS/2.0/conf/sar/tasking-params-codespace-gml

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/capabilities

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/request-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/response-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/response-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/sensor-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/gsa/sensor-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/capabilities

http://www.opengis.net/spec/EOSPS/2.0/conf/val/request-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/response-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/response-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/task-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/segment-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/segment-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/manual-validation-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/val/manual-validation-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/capabilities

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/response-valid




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 38 of 105


RESTRICTED


Test Case


Description

TD-

0020/TC-

0600

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/request-valid A SubmitSegmentByID response

is valid with respect to the XML

schema

TD-

0020/TC-

0610

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/task-id-valid A SubmitSegmentByID request

with an invalid task identifier is


TD-

0020/TC-

0620

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/segment-id-

valid A SubmitSegmentByID request

with an invalid segment identifier

is correctly rejected by the server

TD-

0020/TC-

0630

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/all-

operations The SOAP binding is

implemented for all operations

TD-

0020/TC-

0640

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/dependency-

sps The SOAP binding is

implemented as prescribed in

[OGC 09-000]

TD-

0020/TC-

0650

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/action-uris The proper SOAP Action URIs

are used

TD-

0020/TC-

0660

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-

support The GetFeasibility operation can

be called asynchronously

TD-

0020/TC-

0670

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-

single-response The GetFeasibility operation can

be called asynchronously

TD-

0020/TC-

0680

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/dependency-

sps Notifications are implemented as

defined in SPS 2.0

TD-

0020/TC-

0690

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-

support-basic Basic notification topics are

supported

TD-

0020/TC-

0700


support-reserve Reservation notifications are

supported

TD-

0020/TC-

0710


support-cancel Cancellation notifications are

supported

TD-

0020/TC-

0720


support-update Update notifications are supported

TD-

0020/TC-

0730


support-eo The EO SPS implementation shall

advertise and generate

notifications for the events

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/request-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/task-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/segment-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/sid/segment-id-valid

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/all-operations

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/all-operations

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/action-uris

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-support

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-support

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-single-response

http://www.opengis.net/spec/EOSPS/2.0/conf/soap/gf-wsa-single-response

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/dependency-sps

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-basic

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-basic

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-reserve

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-reserve

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-cancel

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-cancel

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-update

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-update

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-eo

http://www.opengis.net/spec/EOSPS/2.0/conf/notif/events-support-eo




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 39 of 105


RESTRICTED


Test Case


Description

SegmentPlanned,

SegmentAcquired,

SegmentValidated,

SegmentCancelled and

SegmentFailed.

Full details of the Test Cases (ie specification requirements that are tested, scope of testing and the

specific pass/fail test criteria applied) are to be found in the ATS of [RD 1]. They will not be detailed

further in this document. Test procedures for this test design are the ETS of [RD 1] and will be executed

using the TEAM engine. The capabilities of the TEAM engine and the coverage of the ETS will

determine the number of tests which will be run.

55..44.. TTeesstt DDeessiiggnn TTDD--00003300:: SSFF CClliieenntt aanndd SSFF SSeerrvveerr iinntteerraaccttiioonn


This test design will check that the SF Client allows an operator to carry out single or multi feasibility

analysis to asynchronous and/or synchronous missions and then to submit an acquisition request. This

test cover all the use case of the SF Server capabilities discovery, sensors identification, request

definition and submission, results display and submit operations.

This test design will also check the SF Server simulates four different missions and it is able to perform

feasibility studies considering different sensor unavailability issues. These will be performed by

preloading scenarios into the SF Server (dictating weather conditions and sensor unavailabilities) before

the manual operation of the SF Client.


Test cases will be designed in order to check

The SFRE Server capabilities and sensors availabilities

Single Asynchronous Mission Feasibility Analysis can be performed

Single Synchronous Mission Feasibility Analysis can be performed

Multi Asynchronous Missions Feasibility Analysis can be performed

Multi Asynchronous Missions Feasibility Analysis can be performed

Multi Missions (Asynchronous and Synchronous) Feasibility Analysis can be performed

Acquisition (Synchronous and Asynchronous) requests can be submitted to the SFRE Server

Results and Results Access are provided by the SFRE Server when the acquisition is successful

Several test cases will also be designed in order to check that the four missions are correctly simulated

by the SF Server and the different unavailability scenarios are considered. They will be carried out by

loading a scenario into the SF Server before executing one or more previous test cases. Often the result

given with one loaded scenario (with an unavailability) will have to be compared with the result given

with another scenario (without the unavailability). This involves:

All 4 missions are simulated by the SF Server




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 40 of 105


RESTRICTED


Feasibility analyses take into account the following:

o Sensor unavailability

o Station unavailability

o Weather conditions

Thus the following Test Cases are identified:

Table 6: Test Case identification for TD-0030

Test Case Identifier Description

TD-0030/TC-1000 SF Client requests the SF Server capabilities

TD-0030/TC-1010 SF Client requests for a Sensor description

TD-0030/TC-1020 SF Client requests for a Sensor availability

TD-0030/TC-1030 SF Client requests for the information needed to perform a feasibility analysis

TD-0030/TC-1040 SF Client requests for a synchronous sensor feasibility analysis

TD-0030/TC-1050 SF Client requests for an asynchronous sensor feasibility analysis

TD-0030/TC-1060 SF Client requests for a multi synchronous sensors feasibility analysis

TD-0030/TC-1070 SF Client requests for a multi asynchronous sensors feasibility analysis

TD-0030/TC-1080 SF Client requests for a multi sensors (synchronous and asynchronous) feasibility analysis

TD-0030/TC-1090 SF Client requests for a synchronous sensor acquisition

TD-0030/TC-1100 SF Client requests for an asynchronous sensor acquisition

TD-0030/TC-1110 SF Client requests for a multi synchronous sensors acquisition

TD-0030/TC-1120 SF Client requests for a multi asynchronous sensors reservation

TD-0030/TC-1130 SF Client requests for a multi sensors (synchronous and asynchronous) acquisition

TD-0030/TC-1140 SF Client requests for a synchronous sensor reservation

TD-0030/TC-1150 SF Client requests for an asynchronous sensor reservation

TD-0030/TC-1160 SF Client requests for a multi synchronous sensors reservation

TD-0030/TC-1170 SF Client requests for a multi asynchronous sensors reservation

TD-0030/TC-1180 SF Client requests for a multi sensors (synchronous and asynchronous) reservation

TD-0030/TC-2000 SF Server feasibiltiy analysis takes into account Sensor unavailability

TD-0030/TC-2010 SF Server feasibiltiy analysis takes into account Station unavailability

TD-0030/TC-2020 SF Server feasibiltiy analysis takes into account Weather conditions

Test of this kind will be regarded as passed whenever:




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 41 of 105


RESTRICTED


The SF Client submit requests compliant with the semantics of Earth Observation Satellite Tasking

Extension for OGC® Sensor Planning Service 2.0 [RD 1], ie. the users can submit requests and

display the according responses.

The SF Server provides responses compliant with the semantics of Earth Observation Satellite

Tasking Extension for OGC® Sensor Planning Service 2.0 [RD 1], ie. the responses correctly fulfill

the user request in terms of area and time of interest, sensor characteristics and provides suitably

realistic and efficient planning. The test operator will have to use visual inspection through the SF

Client for checking that some of the characteristics, for example that the results constitute a full

coverage of the area of interest.

The configured environment for unavailability and weather scenarios is considered when

performing feasibility studies.

The SF Server accepts suitable parameters for the different missions.

The Asynchronous missions makes use of a Notification Service to provide asynchronous responses

to SF Client, which presents them to the user.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 42 of 105


RESTRICTED


66.. SSOOFFTTWWAARREE VVAALLIIDDAATTIIOONN TTEESSTT CCAASSEE SSPPEECCIIFFIICCAATTIIOONN

Note that full details of the Test Cases TD-0020/TC-0100 to TD-0020/TC-0710 (ie EO SPS

specification requirement testing) are to be found in the ATS of [OGC 07-018]. The associated Test

Procedure for these is TP-0030 Automated testing of SF Server using Executable Test Suite.

66..11.. TTeesstt CCaassee TTDD--00001100//TTCC--00001100:: SSFF SSeerrvveerr IInnssttaallllaattiioonn,,

CCoonnffiigguurraattiioonn,, SSttaarrtt--uupp

This test case deals with the building of the software, installation on run time environment,

configuration and then start-up of the system.

The aim of this test case is to verify correctness of:

SF Server Installation document that specifies:

o procedures for building and deploying the system

o procedures the user / operator shall follow for configuring and starting the system

SF Server configuration items (source files, scripts, configuration files) needed to build and run

the system

66..11..11.. IInnppuuttss aanndd OOuuttppuuttss ssppeecciiffiiccaattiioonnss

The following files are required.

Table 7: Test Case TD-0010/TC-0010 Inputs and Outputs specifications

Input File Name File Type Description Usage / Expected Output Response

HMA-FO_[Version].zip

.zip Deployment Package Installed software

66..11..22.. FFeeaattuurree ppaassss//ffaaiill ccrriitteerriiaa

Tests will be regarded as passed whenever:

The SFRE Web Server is correctly installed and accessible from the test execution

platform/machine.

66..11..33.. EEnnvviirroonnmmeennttaall nneeeeddss

These are as stated in the SF Server Installation document.

66..11..44.. SSppeecciiaall pprroocceedduurraall ccoonnssttrraaiinnttss

None.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 43 of 105


RESTRICTED


66..11..55.. IInntteerrffaacceess ddeeppeennddeenncciieess

None. This test is to be run before other SF Server testing.

66..22.. TTeesstt CCaassee TTDD--00001100//TTCC--00002200:: SSFF CClliieenntt IInnssttaallllaattiioonn,,

CCoonnffiigguurraattiioonn,, SSttaarrtt--uupp

This test case deals with the building of the software, installation on run time environment,

configuration and then start-up of the system.

The aim of this test case is to verify correctness of:

SF Client Installation document that specifies:

o procedures for building and deploying the system

o procedures the user / operator shall follow for configuring and starting the system

SF Client configuration items (source files, scripts, configuration files) needed to build and run

the system


The following files are required.



faceo_hmafo_1.1.16

War See Installation documents



The SF Client is correctly installed, connects to SF Server (or other target environment offering an

SPS Service) and can be operated by the test personnel from the test execution platform.


These are as stated in the SF Client Installation document.


None.


None, but note that in order to check connection to a server offering an SPS interface then TC-0010 can

be run to install and configure the SF Server. Alternatively another Test environment/server could be

used.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 44 of 105


RESTRICTED


This test is to be run before other SF Client testing.

66..33.. TTeesstt CCaassee TTDD--00003300//TTCC--11000000:: SSFF CClliieenntt rreeqquueessttss tthhee SSFF

SSeerrvveerr ccaappaabbiilliittiieess

This test case deals with the capabilities offered by the SFRE Server


In the test the input comes through the SF Client user interface, rather than preloaded files.



the response from the SFRE capabilities request is displayed and could be analysed


The hardware and software resources needed are those specified in the installation procedures for SF

Client and SF Server, and setup as in Test Case TD-0010/TC-0010 and Test Case TD-0010/TC-0020.


None.


The following test cases shall be successfully completed before this one:

TD-0010/TC-0010: SF Server Installation, Configuration, Start-up

TD-0010/TC-0020: SF Client Installation, Configuration, Start-up

66..44.. TTeesstt CCaassee TTDD--00003300//TTCC--11001100:: SSFF CClliieenntt rreeqquueessttss ffoorr aa

SSeennssoorr ddeessccrriippttiioonn

This test case deals with the asynchronous and synchronous optical and radar sensors offered by the

SFRE Server





The description of the sensors following the request is displayed and could be analysed




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 45 of 105


RESTRICTED






None.





66..55.. TTeesstt CCaassee TTDD--00003300//TTCC--11002200:: SSFF CClliieenntt rreeqquueessttss ffoorr tthhee

SSeennssoorr aavvaaiillaabbiilliittyy

This test case deals with the asynchronous and synchronous optical and radar sensor availability offered

by the SFRE Server





The availability of the sensor following the request is displayed and could be analysed





None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 46 of 105


RESTRICTED


66..66.. TTeesstt CCaassee TTDD--00003300//TTCC--11003300:: SSFF CClliieenntt rreeqquueessttss ffoorr tthhee

iinnffoorrmmaattiioonn nneeeeddeedd ttoo ppeerrffoorrmm aa ffeeaassiibbiilliittyy aannaallyyssiiss

This test case deals with the different attributes (mandatory and optional) that the operators need to set

in order to perform a feasibility analysis





The availability of the tasking parameters of a sensor are displayed and could be analysed





None.






ssyynncchhrroonnoouuss sseennssoorr ffeeaassiibbiilliittyy aannaallyyssiiss

This test case deals with the feasibility analysis of a request performed by a synchronous (optical or

radar) sensor





The request is sent to the selected synchronous sensor and the response displayed




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 47 of 105


RESTRICTED






None.






aassyynncchhrroonnoouuss sseennssoorr ffeeaassiibbiilliittyy aannaallyyssiiss

This test case deals with the feasibility analysis of a request performed by a asynchronous (optical or

radar) sensor





The request is sent to the selected asynchronous sensor and the response displayed





None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 48 of 105


RESTRICTED


66..99.. TTeesstt CCaassee TTDD--00003300//TTCC--11006600:: SSFF CClliieenntt rreeqquueessttss ffoorr aa mmuullttii

ssyynncchhrroonnoouuss sseennssoorr ffeeaassiibbiilliittyy aannaallyyssiiss

This test case deals with the feasibility analysis of a request performed by multi synchronous (optical or

radar) sensors





The request is sent to the selected synchronous sensors and the responses displayed





None.






mmuullttii aassyynncchhrroonnoouuss sseennssoorr ffeeaassiibbiilliittyy aannaallyyssiiss

This test case deals with the feasibility analysis of a request performed by multi asynchronous (optical

or radar) sensors





The request is sent to the selected asynchronous sensors and the responses displayed




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 49 of 105


RESTRICTED






None.






mmuullttii sseennssoorr ((ssyynncchhrroonnoouuss aanndd aassyynncchhrroonnoouuss)) ffeeaassiibbiilliittyy

aannaallyyssiiss

This test case deals with the feasibility analysis of a request performed by synchronous (optical or radar)

and asynchronous (optical or radar) sensors





The request is sent to the selected synchronous and asynchronous sensors and the responses

displayed





None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 50 of 105


RESTRICTED



ssyynncchhrroonnoouuss sseennssoorr aaccqquuiissiittiioonn

This test case deals with the acquisition simulation of a request performed by a synchronous (optical or

radar) sensor










None.





66..1133.. TTeesstt CCaassee TTDD--00003300//TTCC--11110000:: SSFF CClliieenntt rreeqquueessttss ffoorr aann

aassyynncchhrroonnoouuss sseennssoorr aaccqquuiissiittiioonn

This test case deals with the acquisition simulation of a request performed by an asynchronous (optical

or radar) sensor









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 51 of 105


RESTRICTED






None.






mmuullttii ssyynncchhrroonnoouuss sseennssoorr aaccqquuiissiittiioonn

This test case deals with the acquisition simulation of a request performed by multi synchronous (optical

or radar) sensors










None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 52 of 105


RESTRICTED



mmuullttii aassyynncchhrroonnoouuss sseennssoorr aaccqquuiissiittiioonn

This test case deals with the acquisition simulation of a request performed by multi asynchronous

(optical or radar) sensors










None.






mmuullttii sseennssoorr ((ssyynncchhrroonnoouuss aanndd aassyynncchhrroonnoouuss)) aaccqquuiissiittiioonn

This test case deals with the acquisition simulation of a request performed by synchronous (optical or

radar) and asynchronous (optical or radar) sensors






displayed




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 53 of 105


RESTRICTED






None.






ssyynncchhrroonnoouuss sseennssoorr rreesseerrvvaattiioonn

This test case deals with the reservation simulation of a request performed by a synchronous (optical or

radar) sensor










None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 54 of 105


RESTRICTED


66..1188.. TTeesstt CCaassee TTDD--00003300//TTCC--11115500:: SSFF CClliieenntt rreeqquueessttss ffoorr aann

aassyynncchhrroonnoouuss sseennssoorr rreesseerrvvaattiioonn

This test case deals with the reservation simulation of a request performed by an asynchronous (optical

or radar) sensor










None.






mmuullttii ssyynncchhrroonnoouuss sseennssoorr rreesseerrvvaattiioonn

This test case deals with the reservation simulation of a request performed by multi synchronous (optical

or radar) sensors









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 55 of 105


RESTRICTED






None.






mmuullttii aassyynncchhrroonnoouuss sseennssoorr rreesseerrvvaattiioonn

This test case deals with the reservation simulation of a request performed by multi asynchronous

(optical or radar) sensors










None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 56 of 105


RESTRICTED



mmuullttii sseennssoorr ((ssyynncchhrroonnoouuss aanndd aassyynncchhrroonnoouuss)) rreesseerrvvaattiioonn

This test case deals with the reservation simulation of a request performed by synchronous (optical or

radar) and asynchronous (optical or radar) sensors






displayed





None.





66..2222.. TTeesstt CCaassee TTDD--00003300//TTCC--22000000:: SSeennssoorr uunnaavvaaiillaabbiilliittyy

This test case deals with the SF Server simulation of sensor unavailability.


In the test the input comes through the SF Client user interface, rather than preloaded files, except for

the preloaded "scenario" files for the SF Server. These are loaded via a servlet interface provided by SF

Server (separate from the OGC Web Services which are SOAP based).



Scenario-TC-0000

SF Server configuration file. Format is

Scenario file with no unavailabilities or weather problems

The SF Server is instructed to use the scenario with a HTTP GET request to: http://dione.deimos-space.com:8080/HMA-FO/SetScenarioServlet?scenario= Scenario-TC-




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 57 of 105


RESTRICTED



XML 0000&startTime=[current time as YYYY-MM-DDThh:mm:ss]

SF server will return the message that:

"Scenario set to:

ScenarioId: Scenario-TC-0000

StartTime: [time as provided in request]"

The GetFeasibility request will be feasible.

Scenario-TC-0010

SF Server configuration file. Format is XML

Scenario file with Sensor unavailability

The SF Server is instructed to use the scenario with a HTTP GET request to: http://dione.deimos-space.com:8080/HMA-FO/SetScenarioServlet?scenario= Scenario-TC-0010&startTime=[current time as YYYY-MM-DDThh:mm:ss]


"Scenario set to:



The GetFeasibility request will be not feasible, for reasons of a sensor unavailabiltiy.



With Scenario-TC-0000 loaded the response will be that the task is feasible.

With Scenario-TC-0010 loaded the response will be that the task is not feasible. The reported

reason will be a sensor unavailability.



Client and SF Server, and setup as in Test Case TC-0010 and Test Case TC-0020.


None.



TC-0010: SF Server Installation, Configuration, Start-up

TC-0020: SF Client Installation, Configuration, Start-up

66..2233.. TTeesstt CCaassee TTDD--00003300//TTCC--22001100:: SSttaattiioonn uunnaavvaaiillaabbiilliittyy

This test case deals with the SF Server simulation of ground station unavailability.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 58 of 105


RESTRICTED








Scenario-TC-0010





"Scenario set to:




Scenario-TC-0020


Scenario file with Station unavailability



"Scenario set to:



The GetFeasibility request will be not feasible, for reasons of a station unavailabiltiy.





reason will be a station unavailability.





None.






VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 59 of 105


RESTRICTED




66..2244.. TTeesstt CCaassee TTDD--00003300//TTCC--22002200:: WWeeaatthheerr ccoonnddiittiioonnss

This test case deals with the SF Server simulation of weather conditions.







Scenario-TC-0000



The SF Server is instructed to use the scenario with a HTTP GET request to: http://dione.deimos-space.com:8080/HMA-FO/SetScenarioServlet?scenario=Scenario-TC-0000&startTime=[current time as YYYY-MM-DDThh:mm:ss]


"Scenario set to:




Scenario-TC-0030


Scenario file with Weather conditions



"Scenario set to:



The GetFeasibility request will be not feasible, for reasons of weather conditions.





reason will be a weather problem.







VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 60 of 105


RESTRICTED



None.








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 61 of 105


RESTRICTED


77.. SSooffttwwaarree VVaalliiddaattiioonn TTeesstt PPrroocceedduurreess

77..11.. TTPP--00001100:: SSFF SSeerrvveerr IInnssttaallllaattiioonn,, CCoonnffiigguurraattiioonn,, SSttaarrtt--uupp

Table 12: TP-0010 Procedure

TEST PROCEDURE

TP Id.: TP-0010 Id of Associated TCs: TC-0010

Required Test Environment:

Not applicable

Purpose of the test procedure:

The objective of this test is to verify that the SF Server can be deployed correctly and it is accessible for servlet and SOAP requests.

Detailed description of the test procedure, including how to observe and verify the results:

8. Stop Apache Tomcat if running

9. Copy the WAR file HMA-SPS.war to $CATALINA_HOME/webapps. The environment variable

$CATALINA_HOME indicates the path where Apache Tomcat is installed, e.g. /opt/apache-tomcat-6.0.18

10. Update $CATALINA_HOME/bin/setenv.sh (create if it does not exist) with the following information

#!/bin/sh

export LD_LIBRARY_PATH=$CATALINA_HOME/webapps/HMººA-SPS/WEB-

INF/lib/CFIs/lib

export ROP_PATH=$CATALINA_HOME/webapps/HMA-SPS/WEB-

INF/lib/CFIs/ropFiles

11. Copy the TGZ file endorsed.tgz to $CATALINA_HOME/ and extract the contents. It will create an

endorsed/ directory and add six JAR files.

12. Start Apache Tomcat

13. A new folder with the name HMA-SPS is created in $CATALINA_HOME/webapps as result of the

deployment of the HMA-SPS.war file.

14. Shutdown Apache Tomcat

15. Update the permissions of the shared libraries libCFIWrapper.so and libCFIWrapperJNI.so

contained in $CATALINA_HOME/webapps/HMA-SPS/WEB-INF/lib/CFIs/lib

cd $CATALINA_HOME/webapps/HMA-SPS/WEB-INF/lib/CFIs/lib

chmod +x *.so

16. Start Apache Tomcat




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 62 of 105


RESTRICTED


17. Open the Web browser and enter the following URL that requests a GetCapabilities operation:

http://hostname:port/HMA-

SPS/GetCapabilitiesServlet?service=SPS&request=GetCapabilities where “hostname:port” the Internet Protocol hostname or numeric address and the port number used for the interaction.

18. Check that the message returned is an XML document conformant to the schemas of [RD 1] and contains the expected data for a GetCapabilities response. For this, compare the returned

message/file with the reference file stored in the reference directory (tp/tp-

0020/reference/GetCapabilitiesResponse.xml)

77..22.. TTPP--00002200:: SSFF CClliieenntt IInnssttaallllaattiioonn,, CCoonnffiigguurraattiioonn,, SSttaarrtt--uupp


TEST PROCEDURE

TP Id.: TP-0020 Id of Associated TCs: TC-0020


Not applicable

Prerequisite for the linux server :

Tomcat version 6 installed in the folder /var/lib/tomcat6)

MySQl version 4 minimum (5 recommended) installed

PhpMyAdmin version 2.11 minimum installed

JDK version 6.13 minimum installed


The objective of this test is to verify that the SF Client can be deployed correctly, accessible from a web browserand connected to the SF Server.


Database initialisation with PhpMyAdmin and the following script :

-- phpMyAdmin SQL Dump

-- version 2.11.9

-- http://www.phpmyadmin.net

--

-- Serveur: faceo-mysql

http://localhost:8080/HMA-SPS/GetCapabilitiesServlet?service=SPS&request=GetCapabilities

http://localhost:8080/HMA-SPS/GetCapabilitiesServlet?service=SPS&request=GetCapabilities




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 63 of 105


RESTRICTED


-- Généré le : Ven 10 Septembre 2010 à 10:59

-- Version du serveur: 4.1.22

-- Version de PHP: 5.2.13

SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";

--

-- Base de données: `hmafo`

--

-- --------------------------------------------------------

--

-- Structure de la table `tasks`

--

CREATE TABLE IF NOT EXISTS `tasks` (

`TASK_ID` varchar(100) NOT NULL default '',

`TASK_USER` varchar(30) NOT NULL default '',

`TASK_NAME` varchar(50) NOT NULL default '',

`TASK_OPERATION` varchar(20) NOT NULL default '',

`TASK_STATUS` varchar(20) default NULL,

`TASK_SENSOR` varchar(70) NOT NULL default '',

`TASK_REQUEST` text,

`TASK_REQUEST_STATUS` varchar(20) NOT NULL default '',

`TASK_RESPONSE` text,

`TASK_RESPONSE_TYPE` varchar(14) NOT NULL default '',

`TASK_CREATION` datetime NOT NULL default '0000-00-00 00:00:00',

`TASK_MODIFICATION` datetime NOT NULL default '0000-00-00 00:00:00',

UNIQUE KEY `TASK_ID_IDX` (`TASK_ID`)

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

Authorisation rules definition for the ‘root’ user in order to give him admin rights (password

‘HMAFOPASSWORD’ to the ‘tasks’ database with PhpMyAdmin

Add the library 'mysql-connector-java-5.1.13-bin.jar' to Tomcat 6 in the folder

'/var/lib/tomcat6/lib' :

Database definition within Tomcat: '/var/lib/tomcat6/conf/server.xml', add the following lines

in the '<GlobalNamingResource>' attributes: ‘port 3306’ is set by default in MySQL




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 64 of 105


RESTRICTED


installation

<Resource name="jdbc/hmafoDS"

scope="Shareable"

auth="Container"

type="javax.sql.DataSource"

driverClassName="com.mysql.jdbc.Driver"

factory="org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory"

url="jdbc:mysql://@IP_Serveur:3306/hmafo"

username="root"

password="HmaPassword"

maxActive="100"

maxIdle="30"

maxWait="10000"

removeAbandoned="true"

logAbandoned="true"

removeAbandonedTimeout="30"

/>

Paste the 'faceo_hmafo.war' file in the Tomcat webapps folder(/var/lib/tomcat6/webapps)

Startup Tomcat 6 :

cd /etc/init.d

./tomcat6 start

Connect to the SF Client by typing the following url in a Firefox 3.6 + browser:

http://@IP_Serveur:8080/faceo_hmafo/www/com.astrium.faceo.HomePage/Home

Page.html




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 65 of 105


RESTRICTED


77..33.. TTPP--00003300:: AAuuttoommaatteedd tteessttiinngg ooff SSFF SSeerrvveerr uussiinngg EExxeeccuuttaabbllee

TTeesstt SSuuiittee


TEST PROCEDURE

TP Id.: TP-0030 Ids of Associated TCs: TC-0100 to TC-0710


SF Server deployed and available

Test platform with TEAM Engine

Scenario files for SF Server

Executable Test Suite (CTL Scripts) for EO Extension for SPS 2.0 [RD 1]


The objective of this test is to verify that the SF Server correctly implements the EO Extension for SPS 2.0 specification [RD 1] by using the executable Test Suite which is part of that specification


TBD when ETS is written.

There will be some use of scenario files (loaded by using a web browser to HTTP GET given URLs on the SF Server) and the execution of CTL scripts using the Team Engine.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 66 of 105


RESTRICTED


77..44.. TTPP--00004400:: SSFF CClliieenntt bbaasseedd tteessttiinngg ooff iinnffoorrmmaattiioonn ooppeerraattiioonnss


TEST PROCEDURE

TP Id.: TP-0040 Ids of Associated TCs:

TD-0030/TC-1000, TD-0030/TC-1010, TD-0030/TC-1020, TD-0030/TC-1030


SF Client

SF Server


The objective of this test is to:

allows the user to request and receive service metadata (or Capabilities) documents that

describe the abilities of the specific sensor implementation

allows the user to obtain a description of the sensors supported by the current implementation

provides information on the availability of the sensor

allows the user to request the information that is needed in order to send GetFeasibility (for a

feasibility study), Submit, Update and Reserve (for tasking the asset) requests


Step

Description Expected Result Requirement Tested

TP-0040.01 Open a compatible web browser and type http://@IP_Serveur:8080/faceo_hmafo/www/com.astrium.faceo.HomePage/HomePage.html, then select "run" for the WorldWind java applet.

The client will load and a globe with be displayed

SR-FUN-0920/1.0: The SF Client shall be executable in a common web browser (Mozilla Firefox 3, IE 8) run on a Windows (WP, Vista or Seven) based operating system SR-FUN-0930/1.0: The SF Client shall display a globe representation of the earth as the cartographic component of the Application

TP-0040.02 Select the left hand arrow, pointing towards the globe The "Satellite Programming” tab appear on the Tasks section.

TP-0040.03 Select the "Others Operations" tab. a list of sensors and operations will appear

TP-0040.04 Select the following criteria:

sensors: OPT1, OPT2, SAR1 or SAR2

Operations: GetCapabilities and click the "Send Request" button at the bottom of the tab.

a "pending" screen shows the request is being sent. A "Response" pop up window will appear with an XML file corresponding to the GetCapabilities results is

SR-FUN-0010/1.0: The Sensor Feasibility Client shall provide compliant implementation of the GetCapabilities operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.

http://ip_serveur:8080/faceo_hmafo/www/com.astrium.faceo.HomePage/HomePage.html





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 67 of 105


RESTRICTED


displayed within it. SR-FUN-0200/1.0: The SF Client shall be configured to interface the four fixed missions exposed by the SF Server

TP-0040.05 Close the pop up windows and select the "Others Operations" tab.

a list of sensors and operations will appear



Operations: DescribeSensor and click the "Send Request" button at the bottom of the tab.

a "pending" screen shows the request is being sent. A "Response" pop up window will appear with an XML file corresponding to the DescribeSensor results is displayed within it.

SR-FUN-0020/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the DescribeSensor operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.





Operations: GetSensorAvailability and click the "Send Request" button at the bottom of the tab.

a "pending" screen shows the request is being sent. A "Response" pop up window will appear with an XML file corresponding to the GetSensorAvailability results is displayed within it.

SR-FUN-0030/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetSensorAvailability operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.





Operations: DescribeTasking and click the "Send Request" button at the bottom of the tab.

a "pending" screen shows the request is being sent. A "Response" pop up window will appear with an XML file corresponding to the DescribeTasking results is displayed within it.

SR-FUN-0050/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the DescribeTasking operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification

77..55.. TTPP--00005500:: SSFF CClliieenntt bbaasseedd tteessttiinngg ooff SSyynncchhrroonnoouuss

ooppeerraattiioonnss


TEST PROCEDURE


TD-0030/TC-1040, TD-0030/TC-1060, TD-0030/TC-1090, TD-0030/TC-1110, TD-0030/TC-1140, TD-0030/TC-1160


SF Client

SF Server


The objective of this test is to test all the operation related to a synchronous sensor offered by the SFRE

Comment [CG1]: Under implementation

Comment [CG2]: Under Implementation




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 68 of 105


RESTRICTED


Server


Step Description Expected Result Requirement Tested




TP-0050.03 Select the "Parameters" tab A list of Request Parameters will appear.


TP-0050.04 Enter the following criteria:

Name: Single Synchronous Sensor GetFeasibility

AOI: o Upper (N/W): 60.000, 60.000 o Lower(S/E): 61.000, 61.000

Date Begin/End: 01/01/2013 - 02/03/2013

Sensors: OPT2

1 tab will become highlighted: OPT2. it will have different parameters according to their sensor types.

SR-FUN-0210/1.0: The SF Client shall allow the users to task one or more integrated missions with the same feasibility analysis request parameters. SR-FUN-0220/1.0: The SF Client shall allow the users to define the requests parameters according to the interfaced missions SR-FUN-0950/1.0: The SF Client shall allow the users to define a feasibility analysis request based on a bounding box AOI, time frame and tasked mission parameters. There is no requirement for the Client to validate the user provided values.

TP-0050.05 Leave the rest as default. On the drop down menu at the bottom on the tab select "GetFeasibility" and click "Send Request".

A pop up window with message "Infos : Task feasible." will appear.

SR-FUN-0060/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetFeasibility operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification. SR-FUN-0960/1.0: The SF Client shall allow the users to define or not (ie. leave as default values) technical parameters according to the tasked missions.

TP-0050.06 click "ok" on the pop-up window A pop-up window with message “Completed status for task %taskNumber%” will appear






VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 69 of 105


RESTRICTED


TP-0050.07 click "ok" on the pop-up window Select the "Tasks" tab

There will be 1 new Tasks called " Single Synchronous Sensor GetFeasibility "

SR-FUN-0970/1.0: The SF Client shall allow the users to task one or more mission with the same feasibility analysis request parameters If the users choose several missions, SF Client will send several feasibility requests.

TP-0050.08 Click the "getStatus" icon next to the Single Synchronous Sensor GetFeasibility task.

A pending animation will run. Then, a pop-up window titled Status will appear.

SR-FUN-0080/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetStatus operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification. SR-FUN-1010/1.0: The SF Client shall allow the users to view the status of the feasibility analysis requests. SR-FUN-0180/1.0: SF Server shall maintain a list of states a request/order can be in stored in the database

TP-0050.09 Click the “ShowRes” icon next to Single Synchronous Sensor GetFeasibility and navigate in the “Results” tab

The “Parameters” tab will appear with a list of request parameters and the mashes displayed with the AOI on the globe

SR-FUN-0230/1.0: The SF Client shall allow the users to display the response(s) from a feasibility analysis request performed by the SF Server SR-FUN-0240/1.0: The SF Client shall allow the users to display the requests parameters in addition to the feasibility analysis responses SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server

SR-FUN-0990/1.0: The SF Client shall allow the users to display the feasibility request parameters related to the feasibility analysis response received

SR-FUN-1000/1.0: The SF Client shall allow the users to display one or more meshes from the feasibility analysis response by selecting the related image acquisition

SR-FUN-1050/1.0: The SF Client shall manage the Acquisition Order and the Coverage Order transparently for the users





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 70 of 105


RESTRICTED


TP-0050.10 Refine the tasking parameters by entering the following criteria:

Name: Single Synchronous Sensor GetFeasibility Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT2


SR-FUN-0250/1.0: The SF Client shall allow the users to refine the previously submitted feasibility analysis request accordingly to the related received feasibility analysis response by constraining key parameters (like ROI or period) before re-submitting a feasibility analysis study. SR-FUN-1030/1.0: The SF Client shall allow the users to refine the feasibility analysis request (from a previous request) by editing the parameters.





There will be 1 new Tasks called " Single Synchronous Sensor GetFeasibility Refined"

TP-0050.14 Click the "getStatus" icon next to the Single Synchronous Sensor GetFeasibility Refined task.


TP-0050.15 Click the “ShowRes” icon next to Single Synchronous Sensor GetFeasibility Refined and navigate in the “results” tab


SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 71 of 105


RESTRICTED


TP-0050.16 Change the tasking parameters by entering the following criteria:

Name: Multi Synchronous Sensors GetFeasibility


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT2 and SAR2

2 tab will become highlighted: OPT2 and SAR2. it will have different parameters according to their sensor types.



2 pop up windows with message "Infos : Task feasible." will appear.

TP-0050.18 click "ok" on the pop-up windows 2 pop-up windows with message “Completed status for task %taskNumber%” will appear

TP-0050.19 click "ok" on the pop-up windows Select the "Tasks" tab

There will be 2 new Tasks called " Multi Synchronous Sensors GetFeasibility "

TP-0050.20 Click the "getStatus" icon next to the Multi Synchronous Sensors GetFeasibility task.


TP-0050.21 Click the “ShowRes” icon next to one of the Multi Synchronous Sensors GetFeasibility task and navigate in the “results” tab

The “Parameters” tab will appear with a sensor and a list of request parameters and the mashes displayed with the AOI on the globe






TP-0050.22 Leave the parameters as they are but change the name to Single Synchronous Sensor Submit. On the drop down menu at the bottom on the tab select "Submit" and click "Send Request".

1 pop up window with message "Infos : Task feasible." will appear.

SR-FUN-0070/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the Submit operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 72 of 105


RESTRICTED


TP-0050.23 click "ok" on the pop-up window 1 pop-up window with message “Completed status for task %taskNumber%” will appear


There will be 1 new Tasks called " Single Synchronous Sensor Submit "

TP-0050.25 Click the "getStatus" icon next to the Single Synchronous Sensor Submit task.


SR-FUN-0080/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetStatus operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.

TP-0050.26 Click the “ShowRes” icon next to one of the Single Synchronous Sensor Submit task



TP-0050.27 Click the "describeResultsAccess" icon next to the Single Synchronous Sensor Submit task.

A pending animation will run. Then, a pop-up window titled DescribeResultsAccess will appear with an XML file displayed.

SR-FUN-0110/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the DescribeResultAccess operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD 1] specification.



Name: Single Synchronous Sensor Submit Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT2



TP-0050.29 Leave the rest as default. On the drop down menu at the bottom on the tab select "Submit" and click "Send Request".




There will be 1 new Tasks called " Single Synchronous Sensor Submit Refined "




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 73 of 105


RESTRICTED


TP-0050.32 Click the "getStatus" icon next to the Single Synchronous Sensor Submit Refined task.


TP-0050.33 Click the “ShowRes” icon next to Single Synchronous Sensor Submit Refined.



TP-0050.34 Click the "describeResultsAccess" icon next to the Single Synchronous Sensor Submit Refined task.




Name: Multi Synchronous Sensors Submit


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Synchronous Sensors Submit "

TP-0050.39 Click the "getStatus" icon next to the Multi Synchronous Sensors Submit task.


TP-0050.40 Click the “ShowRes” icon next to one of the Multi Synchronous Sensors Submit task



TP-0050.41 Click the "describeResultsAccess" icon next to the Multi Synchronous Sensors Submit task.



TP-0050.42 Leave the parameters as they are but change the name to Single Synchronous Sensor Reserve. On the drop down menu at the bottom on the tab select "Reserve" and click "Send Request".


SR-FUN-0120/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the Reserve operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD 1] specification




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 74 of 105


RESTRICTED




There will be 1 new Tasks called " Single Synchronous Sensor Reserve "

TP-0050.45 Click the "getStatus" icon next to the Single Synchronous Sensor Reserve task.



TP-0050.46 Click the “ShowRes” icon next to one of the Single Synchronous Sensor Reserve task



TP-0050.47 Click the "describeResultsAccess" icon next to the Single Synchronous Sensor Reserve task.





Name: Single Synchronous Sensor Reserve Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT2



TP-0050.49 Leave the rest as default. On the drop down menu at the bottom on the tab select "Reserve" and click "Send Request".




There will be 1 new Tasks called " Single Synchronous Sensor Reserve Refined "




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 75 of 105


RESTRICTED


TP-0050.52 Click the "getStatus" icon next to the Single Synchronous Sensor Reserve Refined task.


TP-0050.53 Click the “ShowRes” icon next to Single Synchronous Sensor Reserve Refined.



TP-0050.54 Click the "describeResultsAccess" icon next to the Single Synchronous Sensor Reserve Refined task.




Name: Multi Synchronous Sensor Reserve


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Synchronous Sensor Reserve "

TP-0050.59 Click the "getStatus" icon next to the Multi Synchronous Sensor Reserve task.


TP-0050.60 Click the “ShowRes” icon next to one of the Multi Synchronous Sensor Reserve task



TP-0050.61 Click the "describeResultsAccess" icon next to the Multi Synchronous Sensor Reserve task.





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 76 of 105


RESTRICTED


77..66.. TTPP--00006600:: SSFF CClliieenntt bbaasseedd tteessttiinngg ooff AAssyynncchhrroonnoouuss

ooppeerraattiioonnss


TEST PROCEDURE


TD-0030/TC-1050, TD-0030/TC-1070, TD-0030/TC-1100, TD-0030/TC-1120, TD-0030/TC-1150, TD-0030/TC-1170


SF Client

SF Server


The objective of this test is to test all the operation related to a asynchronous sensor offered by the SFRE Server









Name: Single Asynchronous Sensor GetFeasibility


Date Begin/End: 01/01/2013 - 02/03/2013

Sensors: OPT1








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 77 of 105


RESTRICTED







There will be 1 new Tasks called " Single Asynchronous Sensor GetFeasibility "


TP-0060.08 Click the "getStatus" icon next to the Single Asynchronous Sensor GetFeasibility task.


SR-FUN-0080/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetStatus operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification. SR-FUN-1010/1.0: The SF Client shall allow the users to view the status of the feasibility analysis requests.

TP-0060.09 Click the “ShowRes” icon next to Single Asynchronous Sensor GetFeasibility and navigate in the “results” tab


SR-FUN-0230/1.0: The SF Client shall allow the users to display the response(s) from a feasibility analysis request performed by the SF Server SR-FUN-0240/1.0: The SF Client shall allow the users to display the requests parameters in addition to the feasibility analysis responses SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 78 of 105


RESTRICTED






Name: Single Asynchronous Sensor GetFeasibility Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT1







There will be 1 new Tasks called " Single Asynchronous Sensor GetFeasibility Refined"

TP-0060.14 Click the "getStatus" icon next to the Single Asynchronous Sensor GetFeasibility Refined task.


TP-0060.15 Click the “ShowRes” icon next to Single Asynchronous Sensor GetFeasibility Refined and navigate in the “results” tab




SR-FUN-1000/1.0: The SF Client shall allow the users to display one or more meshes from the feasibility analysis response by




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 79 of 105


RESTRICTED


selecting the related image acquisition




Name: Multi Asynchronous Sensors GetFeasibility


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Asynchronous Sensors GetFeasibility "

TP-0060.20 Click the "getStatus" icon next to the Multi Asynchronous Sensors GetFeasibility task.


TP-0060.21 Click the “ShowRes” icon next to one of the Multi Asynchronous Sensors GetFeasibility task and navigate in the “results” tab







TP-0060.22 Leave the parameters as they are but change the name to Single Asynchronous Sensor Submit. On the drop down menu at the bottom on the tab select "Submit" and click "Send Request".


SR-FUN-0070/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the Submit operation following the EO




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 80 of 105


RESTRICTED


Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification.



There will be 1 new Tasks called " Single Asynchronous Sensor Submit "

TP-0060.25 Click the "getStatus" icon next to the Single Asynchronous Sensor Submit task.



TP-0060.26 Click the “ShowRes” icon next to one of the Single Asynchronous Sensor Submit task



TP-0060.27 Click the "describeResultsAccess" icon next to the Single Asynchronous Sensor Submit task.





Name: Single Asynchronous Sensor Submit Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT1









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 81 of 105


RESTRICTED



There will be 1 new Tasks called " Single Asynchronous Sensor Submit Refined "

TP-0060.32 Click the "getStatus" icon next to the Single Asynchronous Sensor Submit Refined task.


TP-0060.33 Click the “ShowRes” icon next to Single Asynchronous Sensor Submit Refined.



TP-0060.34 Click the "describeResultsAccess" icon next to the Single Asynchronous Sensor Submit Refined task.




Name: Multi Asynchronous Sensors Submit


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Asynchronous Sensors Submit "

TP-0060.39 Click the "getStatus" icon next to the Multi Asynchronous Sensors Submit task.


TP-0060.40 Click the “ShowRes” icon next to one of the Multi Asynchronous Sensors Submit task



TP-0060.41 Click the "describeResultsAccess" icon next to the Multi Asynchronous Sensors Submit task.



TP-0060.42 Leave the parameters as they are but change the name to Single Asynchronous Sensor Reserve. On the drop down menu at the bottom on the tab select "Reserve" and click "Send Request".


SR-FUN-0120/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the Reserve operation




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 82 of 105


RESTRICTED


following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD 1] specification



There will be 1 new Tasks called " Single Asynchronous Sensor Reserve "

TP-0060.45 Click the "getStatus" icon next to the Single Asynchronous Sensor Reserve task.



TP-0060.46 Click the “ShowRes” icon next to one of the Single Asynchronous Sensor Reserve task



TP-0060.47 Click the "describeResultsAccess" icon next to the Single Asynchronous Sensor Reserve task.





Name: Single Asynchronous Sensor Reserve Refined


Date Begin/End: 01/01/2013 - 02/06/2013

Sensors: OPT1









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 83 of 105


RESTRICTED



There will be 1 new Tasks called " Single Asynchronous Sensor Reserve Refined "

TP-0060.52 Click the "getStatus" icon next to the Single Asynchronous Sensor Reserve Refined task.


TP-0060.53 Click the “ShowRes” icon next to Single Asynchronous Sensor Reserve Refined.



TP-0060.54 Click the "describeResultsAccess" icon next to the Single Asynchronous Sensor Reserve Refined task.




Name: Multi Asynchronous Sensor Reserve


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Asynchronous Sensor Reserve "

TP-0060.59 Click the "getStatus" icon next to the Multi Asynchronous Sensor Reserve task.


TP-0060.60 Click the “ShowRes” icon next to one of the Multi Asynchronous Sensor Reserve task



TP-0060.61 Click the "describeResultsAccess" icon next to the Multi Asynchronous Sensor Reserve task.





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 84 of 105


RESTRICTED


77..77.. TTPP--00007700:: SSFF CClliieenntt bbaasseedd tteessttiinngg ooff mmuullttii--sseennssoorr rreeqquueessttss


TEST PROCEDURE


TD-0030/TC-1080, TD-0030/TC-1130, TD-0030/TC-1180


SF Client

SF Server


The objective of this test is to test all the multi synchronous and asynchronous sensor operations offered by the SFRE Server









Name: Multi Synchronous and Asynchronous Sensor GetFeasibility


Date Begin/End: 01/01/2013 - 02/03/2013









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 85 of 105


RESTRICTED







There will be 2 new Tasks called " Multi Synchronous and Asynchronous Sensor GetFeasibility "


TP-0070.08 Click the "getStatus" icon next to the Multi Synchronous and Asynchronous Sensor GetFeasibility tasks.


SR-FUN-0080/1.0: The Sensor Feasibility Client and Server shall provide compliant implementation of the GetStatus operation following the EO Satellite Tasking Extension for SPS (OGC 07-018) [RD1] specification. SR-FUN-1010/1.0: The SF Client shall allow the users to view the status of the feasibility analysis requests.

TP-0070.09 Click the “ShowRes” icon next to a Multi Synchronous and Asynchronous Sensor GetFeasibility.


SR-FUN-0230/1.0: The SF Client shall allow the users to display the response(s) from a feasibility analysis request performed by the SF Server SR-FUN-0240/1.0: The SF Client shall allow the users to display the requests parameters in addition to the feasibility analysis responses SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server SR-FUN-1050/1.0: The SF Client shall manage the Acquisition Order and the Coverage Order transparently for the users





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 86 of 105


RESTRICTED



Name: Multi Synchronous and Asynchronous Sensor Submit


Date Begin/End: 01/01/2013 - 02/06/2013








There will be 2 new Tasks called " Multi Synchronous and Asynchronous Sensor Submit "

TP-0070.14 Click the "getStatus" icon next to the Multi Synchronous and Asynchronous Sensor Submit task.


TP-0070.15 Click the “ShowRes” icon next to one of the Multi Synchronous and Asynchronous Sensor Submit task


SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server SR-FUN-1050/1.0: The SF Client shall manage the Acquisition Order and the Coverage Order transparently for the users

TP-0070.16 Click the "describeResultsAccess" icon next to the Multi Synchronous and Asynchronous Sensor Submit task.



TP-0070.17 Change the tasking parameters by entering the following criteria: Name: Multi Synchronous and Asynchronous Sensor

Reserve


Date Begin/End: 01/01/2013 - 02/06/2013










VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 87 of 105


RESTRICTED



There will be 2 new Tasks called " Multi Synchronous and Asynchronous Sensor Reserve "

TP-0070.20 Click the "getStatus" icon next to the Multi Synchronous and Asynchronous Sensor Reserve task.


TP-0070.21 Click the “ShowRes” icon next to one of the Multi Synchronous and Asynchronous Sensor Reserve task


SR-FUN-0980/1.0: The SF Client shall allow the users to display the feasibility analysis response from the SF Server SR-FUN-1050/1.0: The SF Client shall manage the Acquisition Order and the Coverage Order transparently for the users

TP-0070.22 Click the "describeResultsAccess" icon next to the Multi Synchronous and Asynchronous Sensor Reserve task.


77..88.. TTPP--00008800:: SSFF SSeerrvveerr ssiimmuullaattiioonn ooff uunnaavvaaiillaabbiilliittiieess


TEST PROCEDURE


TD-0030/TC-2000, TD-0030/TC-2010, TD-0030/TC-2030


SF Client

SF Server


The objective of this test is to test the ability of the SF Server to simulate different sorts of unavailabilities



TP-0080.01 Open a compatible web browser (eg Firefox) and go to http://dione.deimos-space.com:8080/HMA-FO/SetScenarioServlet?scenario=Scenario-TC-0000&startTime=[current time as YYYY-MM-DDThh:mm:ss]

The server will load the scenario and the browser will display: "Scenario set to: ScenarioId: Scenario-TC-0000 StartTime: [time as provided in request]"

SR-FUN-0840/1.0: The Internal Planning System shall consider environmental configuration for unavailability scenarios when performing feasibilities studies. The configuration of these conflicts/constraints shall be done via a set of user-editable configuration files.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 88 of 105


RESTRICTED







Name: Single Synchronous Sensor Baseline


Date Begin/End: 01/01/2013 - 02/03/2013 Sensors: OPT2











Name: Station Unavailability


Date Begin/End: 01/01/2013 - 02/03/2013

Sensors: OPT2



A pop up window with message "Infos : Task not feasible." will appear. (unlike as seen in step TP-0080.06)

SR-FUN-0840/1.0: The Internal Planning System shall consider environmental configuration for unavailability scenarios when








VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 89 of 105


RESTRICTED


performing feasibilities studies. The configuration of these conflicts/constraints shall be done via a set of user-editable configuration files.








Name: Sensor Unavailability




















VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 90 of 105


RESTRICTED


TP-0080.23 Enter the following criteria: Name: Weather Unavailability










VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 91 of 105


RESTRICTED


88.. SSOOFFTTWWAARREE VVAALLIIDDAATTIIOONN BBYY AANNAALLYYSSIISS,, IINNSSPPEECCTTIIOONN,,

RREEVVIIEEWW OOFF DDEESSIIGGNN

The Software Requirements Specification [AD 8] gives the validation methods for each requirement.

For the ones which are not "Test" it defines:

Inspection (I) – Exhaustive evaluation of the code by manual reading;

Analysis (A) – Deduction method applied to documentation, code, test results, etc; it is partially

or totally automated;

Review (R) – Review of project documentation

This section reports the manual steps to be performed for verifying these requirements.

The following table reports all requirements from [AD 8] of this type, along with the description of

manual verification activities to be performed.

Identifier Description Type Activity

SR-FUN-0310/1.0

SF Server shall use the Apache/Tomcat Web server for hosting the SPS implementation.

R Review of Software Design Document [AD 9]

SR-FUN-0320/1.0

The [SF Server] Web server shall be accessible for protocols as needed for the required operations – HTTP GET with information in Keyword-Value pairs and HTTP POST with information in SOAP messages. It shall support versions 1.1 and 1.2 of the SOAP specification.

I Inspection to verify the protocols accepted. This is supported in part by some of the tests in the Executable Test Suite for EO Extension for SPS 2.0.

SR-FUN-0420/1.0

SPS Controller shall populate the Java classes representing the SOAP responses, and pass these back to the SOAP Reader/Writer to be sent to the client synchronously.

I Inspection to verify the use of classes to represent responses, and the component (Axis) involved in serialization.

SR-FUN-0610/1.0

SPS SOAP Reader/Writer shall extract the SOAP headers from the incoming SPS requests. It shall support version 1.2 of the SOAP specification.

I Inspection to verify the use of Axis to carry out deserialization.

SR-FUN-0620/1.0

SPS SOAP Reader/Writer shall append a SOAP header to the serialized information constituting a response to a given SPS request. It shall support version 1.2 of the SOAP specification.

I Inspection to verify the use of Axis to carry out serialization.

SR-FUN-0710/1.0

The SF Server shall use the SPS Library for deserialization of the incoming requests and the serialisation of the generated responses.

I Inspection to verify the use of SPS Library.

SR-FUN-0720/1.0

SPS Library shall extract the SOAP body and shall pass it to the SPS Controller to trigger further processing. This extraction shall involve the creation and population of Java classes representing the same structures as appear in the SOAP input and output messages.

I Inspection to verify the use of SPS Library.

SR-FUN-0810/1.0

The Internal Sensor Planning System shall perform feasibility studies by using the Earth Explorer CFI as a COTS Satellite Programming System for the

I Inspection to verify the use of Earth Explorer CFI.




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 92 of 105


RESTRICTED


Identifier Description Type Activity implementation.

SR-FUN-0820/1.0

The implementation of the interface related to the Earth Explorer CFI shall use either the JNI library as a bridge between the C++ and Java languages, or a native Java implementation of Earth Explorer CFI.

I Inspection to verify that Earth Explorer CFI is implemented using JNI bridge (which was the method chosen)

SR-OPE-0010/1.0

SFRE is not intended to be an operational system. The developed systems shall be maintained only on a best-effort basis.

R Review of Software Requirements Specification [AD 8] Section 5.5 to note that this is the only Operational requirement listed.

SR-IMP-0010/1.0

The SFRE development process shall be based on UML

R Review of Software Design Document [AD 9]

SR-IMP-0020/1.0

The SFRE requirement analysis shall be performed using UML, including the production of use cases and interaction diagrams for the various message types

R Review of Software Requirements Specification [AD 8]

SR-IMP-0030/1.0

The SFRE design shall be performed using UML. R Review of Software Design Document [AD 9]

SR-CON-0010/1.0

The configuration aspects applicable for the project shall be defined in the Software Configuration Management Plan, included in [the Project Management Plan]

R Review of Project Management Plan [AD 6] Section 5.5.1 which includes Configuration Items Data List as a project document.

SR-INS-0010/1.0

For any software components delivered for deployment at ESRIN instructions shall be produced regarding how to install the software. This could include information for the SF Server and SF Client software developed and/or the used libraries and COTS.

R Review of this document (TP-0010: SF Server Installation, Configuration, Start-up and TP-0020: SF Client Installation, Configuration, Start-up) and Project Management Plan [AD 6] Section 5.5.1 which includes "COTS, Libraries or support packages necessary for building the SFRE, All related procedures (installation, compilation, building, …)" as required parts of the SFRE Software.

SR-VVA-0010/1.0

Unit test shall be designed, implemented an executed to test each individual software component composing the system to be developed. Stubs shall be used in case of component interactions.

R Inspection to verify the use of unit tests for operations.

SR-VVA-0020/1.0

Integration tests shall be designed, implemented and executed to mainly verify the interfaces between software components.

R Review of this document - note that many of the tests are concerned with SF Client and SF Server integration.

SR-VVA-0030/1.0

In order to support the demonstration activities in the Acceptance Review a System Test Plan shall be written to cover requirements marked T (Test) above. System testing shall be carried out at DEIMOS resulting in Validation Testing Reports. These tests shall be based on, and shall reference, this Software Requirements Document and the SPS EO Application profile

R Review of this document.

SR-VVA-0040/1.0

An Abstract Test Suite shall be specified as part of EO Satellite Tasking Extension for SPS and an Executable Test Suite will be deployed for use in testing the SF Server.

It will consist of a set of test scripts that shall be delivered to ESA.

R Review of the Earth Observation Satellite Tasking Extension for OGC® Sensor Planning Service 2.0 specification for the Abstract Test Suite.

The "set of test scripts" to be delivered are the Executable Test Suite described in this document, Section 5.3, and Test Procedure TP-0030: Automated testing of SF Server using Executable Test Suite




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 93 of 105


RESTRICTED


99.. VVAALLIIDDAATTIIOONN TTEESSTT PPLLAATTFFOORRMM RREEQQUUIIRREEMMEENNTTSS

99..11.. TTeesstt PPllaattffoorrmm

Test Procedures TP-0010 and TO-0020 cover the installation of software - each can be installed on a

Linux server with Apache tomcat, for example.

Executable Test Suite testing (TP-0030) is carried out in an automated way, using the TEAM Engine.

The TEAM engine is deployed as a web application (on top of Apache Tomcat 5.5) and is accessed

through a web browser.

All other testing is carried out using a web browser (for example Firefox) to connect to the SF Client.

The operator does not need any further software or any specific hardware.

99..22.. NNeettwwoorrkk AArrcchhiitteeccttuurree

Figure 9-1: Deployment and Interfaces required for Validation




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 94 of 105


RESTRICTED


1100.. RREEQQUUIIRREEMMEENNTT TTRRAACCEEAABBIILLIITTYY MMAATTRRIIXX

The following traceability matrix includes a description of the requirement, and titles of the tests, for

readability purposes. Note that only requirements where the Validation method is Test have associated

Test Cases, other requirements are marked "N/A" and covered in Section 8.

1100..11.. RReeqquuiirreemmeennttss vvss.. TTeesstt ccaasseess ttrraacceeaabbiilliittyy mmaattrriixx

Require

ment ID

Description Test

Procedure

Step ID(s)

Title

SR-FUN-0010/1.0

SF Client and SF Server provide compliant implementation of the GetCapabilities operation.

TP-0040.04 SF Client based testing of information

operations

SR-FUN-0020/1.0

SF Client and SF Server provide compliant implementation of the DescribeSensor operation.


operations

SR-FUN-0030/1.0

SF Client and SF Server provide compliant implementation of the GetSensorAvailability operation.


operations

SR-FUN-0040/1.0

SF Client and SF Server provide compliant implementation of the Validate operation.

SR-FUN-0050/1.0

SF Client and SF Server provide compliant implementation of the DescribeTasking operation.


operations

SR-FUN-0060/1.0

SF Client and SF Server provide compliant implementation of the GetFeasibility operation.

TP-0050.05 SF Client based testing of Synchronous

operations

TP-0060.05 SF Client based testing of

Asynchronous operations

TP-0070.05 SF Client based testing of multi-sensor

requests

SR-FUN-0070/1.0

SF Client and SF Server provide compliant implementation of the Submit operation.


operations



SR-FUN-0080/1.0

SF Client and SF Server provide compliant implementation of the GetStatus operation.


operations









VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 95 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title


requests

SR-FUN-0090/1.0

SF Client and SF Server provide compliant implementation of the Cancel operation.

SF Client based testing

SR-FUN-0100/1.0

SF Client and SF Server provide compliant implementation of the Update operation.


SR-FUN-0110/1.0

SF Client and SF Server provide compliant implementation of the DescribeResultAccess operation.


operations



SR-FUN-0120/1.0

SF Client and SF Server provide compliant implementation of the Reserve operation.


operations



SR-FUN-0130/1.0

SF Client and SF Server provide compliant implementation of the Confirm operation.


SR-FUN-0140/1.0

SF Client and SF Server support both Coverage Order and Acquisition Order


SR-FUN-0150/1.0

SF Server uses exception report messages. TP-0030 Automated testing of SF Server using

Executable Test Suite

SR-FUN-0160/1.0

Four simulated systems exposed by the SF Server.

TP-0070.10 + TP-0070.17

SF Client based testing of multi-sensor

requests

SR-FUN-0170/1.0

SF Server simulates:

Optical asynchronous mission which makes use of a Notification Service

Optical synchronous mission

Radar asynchronous mission which makes use of a Notification Service

Radar synchronous mission

TP-0070.10 + TP-0070.17 + TP-0030


requests and Automated testing of SF

Server using Executable Test Suite

SR-FUN-0180/1.0

SF Server shall maintain a list of states a request/order can be in stored in the database


operations

SR-FUN-0190/1.0

SF Server shall manage state transitions. Any change of state will be saved and needed notifications will be triggered.

TP-0030 Automated testing of SF Server using


SR-FUN-0200/1.0

The SF Client shall be configured to interface the four fixed missions exposed by the SF


Comment [CG6]: Implemented but test needs to be written







VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 96 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

Server operations

SR-FUN-0210/1.0

The SF Client shall allow the users to task one or more integrated missions with the same feasibility analysis request parameters.


operations




requests

SR-FUN-0220/1.0

The SF Client shall allow the users to define the requests parameters according to the interfaced missions.


operations




requests

SR-FUN-0230/1.0

The SF Client shall allow the users to display the response(s) from a feasibility analysis request performed by the SF Server.


operations




requests

SR-FUN-0240/1.0

The SF Client shall allow the users to display the requests parameters in addition to the feasibility analysis responses.


operations




requests

SR-FUN-0250/1.0

The SF Client shall allow the users to refine a previously submitted feasibility analysis request.


operations







VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 97 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

requests

SR-FUN-0310/1.0

SF Server shall use the Apache/Tomcat Web server for hosting the SPS implementation.

N/A

SR-FUN-0320/1.0

The Web server shall be accessible for protocols as needed for the required operations – HTTP GET with information in Keyword-Value pairs and HTTP POST with information in SOAP messages. It shall support versions 1.1 and 1.2 of the SOAP specification.

N/A

SR-FUN-0410/1.0

SPS Controller shall process the received messages. This includes synchronous responses for each message type.

Many steps SF Client based testing of Synchronous

operations

Many steps SF Client based testing of


SR-FUN-0420/1.0

SPS Controller shall populate the Java classes representing the SOAP responses, and pass these back to the SOAP Reader/Writer to be sent to the client synchronously.

N/A

SR-FUN-0430/1.0

If necessary for any change of state of a request or task the SPS Controller shall send information to the Notification server by sending Notify SOAP messages to alert a client that a task request has been processed successfully.

http://ww

w.opengis

.net/spec/

EOSPS/2.

0/conf/not

if

Automated testing of SF Server using


SR-FUN-0510/1.0

The Notification Service shall provide a mechanism for users to subscribe to notifications when certain events occur during the lifecycle of a task.

http://ww

w.opengis

.net/spec/

EOSPS/2.

0/conf/not

if



SR-FUN-0520/1.0

The notification process shall be done via WS-Notification protocol.

http://ww

w.opengis

.net/spec/

EOSPS/2.

0/conf/not

if



SR-FUN-0530/1.0

The Notification Service shall provide a predefined list of topics that correspond with all possible task status transitions.

http://ww

w.opengis

.net/spec/

EOSPS/2.

0/conf/not



http://www.opengis.net/spec/EOSPS/2.0/conf/notif


























VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 98 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

if

SR-FUN-0610/1.0

SPS SOAP Reader/Writer shall extract the SOAP headers from the incoming SPS requests. It shall support version 1.2 of the SOAP specification.

N/A

SR-FUN-0620/1.0

SPS SOAP Reader/Writer shall append a SOAP header to the serialized information constituting a response to a given SPS request. It shall support version 1.2 of the SOAP specification.

N/A

SR-FUN-0710/1.0

The SF Server shall use the SPS Library for deserialization of the incoming requests and the serialisation of the generated responses.

N/A

SR-FUN-0720/1.0

SPS Library shall extract the SOAP body and shall pass it to the SPS Controller to trigger further processing.

N/A

SR-FUN-0810/1.0

The Internal Sensor Planning System shall perform feasibility studies by using the Earth Explorer CFI as a COTS Satellite Programming System for the implementation.

N/A

SR-FUN-0820/1.0

The implementation of the interface related to the Earth Explorer CFI shall use either the JNI library as a bridge between the C++ and Java languages, or a native Java implementation of Earth Explorer CFI.

N/A

SR-FUN-0840/1.0

The Internal Planning System shall consider environmental configuration for unavailability scenarios when performing feasibilities studies. The configuration of these conflicts/constraints shall be done via a set of user-editable configuration files.

TP-0080.01 + TP-0080.12 + TP-0080.18 + TP-0080.24

SF Server simulation of unavailabilities

SR-FUN-0910/1.0

The SF Client should be based on WorldWind Java and Google Web Toolkit technologies


operations

SR-FUN-0920/1.0

The SF Client shall be executable in a common web browser (Mozilla Firefox 3, IE 8) run on a Windows (XP, Vista or Seven) based operating system


operations

SR-FUN-0930/1.0

The SF Client shall display a globe representation of the earth as the cartographic component of the application.


operations

SR-FUN-0940/1.0

The SF Client shall be interfaced to the SF Server following the EO Satellite Tasking Extension for SPS 2.0 specification


operations

SR-FUN-0950/1.0

The SF Client shall allow the users to define a feasibility analysis request based on a bounding box AOI, time frame and tasked mission


operations




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 99 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

parameters. There is no requirement for the Client to validate the user provided values. TP-0060.05 SF Client based testing of



requests

SR-FUN-0960/1.0

The SF Client shall allow the users to define or not (ie. leave as default values) technical parameters according to the tasked missions


operations




requests

SR-FUN-0970/1.0

The SF Client shall allow the users to task one or more mission with the same feasibility analysis request parameters

If the users choose several missions, SF Client will send several feasibility requests.

TP-0050.07 and TP-0050.16 and TP-0050.35

SF Client based testing of Synchronous

operations

TP-0060.07 and TP-0060.16 and TP-0060.35

SF Client based testing of


TP-0070.07 and TP-0070.10 and TP-0070.17


requests

SR-FUN-0980/1.0

The SF Client shall allow the users to display the feasibility analysis response from the SF Server

TP-0050.09 and TP-0050.15 and TP-0050.21


operations

TP-0060.09 and TP-0060.15 and TP-0060.21



TP-0070.09 and TP-0070.15 and TP-0070.21


requests

SR-FUN-0990/1.0

The SF Client shall allow the users to display the feasibility request parameters related to the feasibility analysis response received

TP-0050.09 and TP-0050.15 and TP-0050.21


operations

TP-0060.09 and TP-0060.15 and TP-0060.21






VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 100 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

TP-0070.09 and TP-0070.15 and TP-0070.21


requests

SR-FUN-1000/1.0

The SF Client shall allow the users to display one or more meshes from the feasibility analysis response by selecting the related image acquisition

TP-0050.09 and TP-0050.15 and TP-0050.21


operations

TP-0060.09 and TP-0060.15 and TP-0060.21



TP-0070.09 and TP-0070.15 and TP-0070.21


requests

SR-FUN-1010/1.0

The SF Client shall allow the users to view the status of the feasibility analysis requests


operations




requests

SR-FUN-1030/1.0

The SF Client shall allow the users to refine the feasibility analysis request (from a previous request) by editing the parameters.


operations




requests

SR-FUN-1050/1.0

The SF Client shall manage the Acquisition Order and the Coverage Order transparently for the users

TP-0050.09 and TP-0050.15 and TP-0050.21 and TP-0050.26 and TP-0050.33 and TP-0050.40 and TP-0050.46 and TP-0050.53 and TP-0050.60


operations

TP-0060.09 and TP-





VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 101 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

0060.15 and TP-0060.21 and TP-0060.26 and TP-0060.33 and TP-0060.40 and TP-0060.46 and TP-0060.53 and TP-0060.60


TP-0070.09 and TP-0070.15 and TP-0070.21


requests

SR-PER-0010/1.0

Each of SF Server and SF Client shall be capable of being deployed on a single server.

TP-0020 SF Client Installation, Configuration,

Start-up

SR-PER-0020/1.0

SF Server shall respond rapidly enough to all message receptions that sensible time-out parameters can be set for any client software. 60 seconds is the anticipated value, although this may be changed during testing if necessary. This is the benchmark when a single message is being processed at once. In case of multiple clients connecting at the same moment it is permissible (though not expected) that one should be given a time out by the SF Server in the understanding that the client will retry later.

All steps SF Client based testing of Synchronous

operations

All steps SF Client based testing of


All steps SF Client based testing of multi-sensor

requests

SR-INT-0010/1.0

The SFRE system (SF Server and SF Client) shall be deployed on servers within DEIMOS/ASTRIUM facilities or at ESRIN.

All steps SF Server Installation, Configuration,

Start-up

All steps SF Client Installation, Configuration,

Start-up

SR-INT-0020/1.0

The encoding of the operation requests shall use HTTP GET with KVP encoding (GetCapabilities) and HTTP POST with XML, SOAP (all other operations).

All steps SF Client based testing of Synchronous

operations

All steps SF Client based testing of


All steps SF Client based testing of multi-sensor

requests

SR-OPE-0010/1.0

SFRE is not intended to be an operational system. The developed systems shall be maintained only on a best-effort basis.

N/A

SR-RES-0010/1.0

SF Server shall be deployed on a server running Linux and the Apache Tomcat web application

All steps SF Server Installation, Configuration,

Start-up




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 102 of 105


RESTRICTED


Require

ment ID

Description Test

Procedure

Step ID(s)

Title

server.

SR-IMP-0010/1.0

The SFRE development process shall be based on UML

N/A

SR-IMP-0020/1.0

The SFRE requirement analysis shall be performed using UML, including the production of use cases and interaction diagrams for the various message types

N/A

SR-IMP-0030/1.0

The SFRE design shall be performed using UML. N/A

SR-CON-0010/1.0

The configuration aspects applicable for the project shall be defined in the Software Configuration Management Plan, included in Project Management Plan

N/A

SR-INS-0010/1.0

For any software components delivered for deployment at ESRIN instructions shall be produced regarding how to install the software. This could include information for the SF Server and SF Client software developed and/or the used libraries and COTS.

N/A

SR-VVA-0010/1.0

Unit test shall be designed, implemented an executed to test each individual software component composing the system to be developed. Stubs shall be used in case of component interactions.

N/A

SR-VVA-0020/1.0

Integration tests shall be designed, implemented and executed to mainly verify the interfaces between software components.

N/A

SR-VVA-0030/1.0

In order to support the demonstration activities in the Acceptance Review a System Test Plan shall be written to cover requirements marked T (Test) above. System testing shall be carried out at DEIMOS resulting in Validation Testing Reports. These tests shall be based on, and shall reference, this Software Requirements Document and the SPS EO Application profile

N/A

SR-VVA-0040/1.0

An Abstract Test Suite shall be specified as part of EO Satellite Tasking Extension for SPS and an Executable Test Suite will be deployed for use in testing the SF Server.

It will consist of a set of test scripts that shall be delivered to ESA.

N/A




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 103 of 105


RESTRICTED


1111.. SSOOFFTTWWAARREE VVAALLIIDDAATTIIOONN TTEESSTT RREEPPOORRTTIINNGG

A typical form for reporting the pass/fail result of the execution of a test is shown below:

Table 20: Text Execution Record template

Project Acronym/Name HMA-FO Feasibility Analysis Service

SW Item/Version:

Test Campaign: Unit Tests Integration Tests System Tests Acceptance Tests

Test Procedure: Test Run Identifier: Acceptance Review

Functionality to be tested: Test Cases (including Pass/Fail Criteria)

Detailed observations obtained from the test execution:

Test Procedure TPIV-NNNN:

Step Step Details Pass/Fail Affected SR (if Failed)

Remarks

1

2

3

Summary of test execution results:

Test Cases Pass/Fail Remarks

Overall Test Result: Compliant Not Compliant Partially Compliant

Raised SPR(s) / NCR(s):

Electronic copy of test results stored in (e.g. directory):

Attachments: Test Results Other documentation

Test Engineer Project Manager PA Verification Customer

Representative (for AT)




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 104 of 105


RESTRICTED


Name:

Date:

Signature:




VVP01-E-R

Issue : 1.0

Date : 05/10/10

Page : 105 of 105


RESTRICTED


1122.. DDiirreeccttoorryy ssttrruuccttuurree ffoorr ffiillee--bbaasseedd tteessttss

Certain test procedures require a file as an input, or a reference file to be compared with the output

given by the software. These test procedures shall be organised under a dedicated directory named tp.

An environment variable named TEST_HOME shall point to this directory. A directory per test

procedure shall exist with all the necessary elements needed for its execution. Thus, it is possible to

conduct the execution of the different test procedures and to control and manage the outputs that are

obtained as a result of each run.

The directory name for each system test shall be named as tp-nnnn, being nnnn the number of the

test procedure (e.g. 0020). Under this directory, data are arranged in a set of sub-directories:

input/ including the set of files that will represent the input data for the associated test procedure.

output/ where the tests output, i.e., information logged as a result of the execution of the test is

placed.

reference/ where reference data is kept for the verification activities of the test procedure.

The figure below summarises the directory structure applicable for the HMA-FO test development.

tp

tp-0010 tp-0010 tp-nnnn

input output reference

Figure 2: Test procedures directory structure