SSFS Test Plan/Report Overview of the test cases What “success” means for a data format type test How the tests were conducted Key results and conclusions What needs to be addressed to complete the test report

Overview of SSFS Tests Goals of the tests were to demonstrate that the proposed schema can: be used to publish a schedule of services be applied to service schedules with time spans that are typical of normal operations scenarios including unused times of cross support service systems (CSSSs) Each test run represented simple schedule data exchanged from a Service Provider to a Service User. DLR-German Space Operations Center (GSOC) and NASA- Goddard Space Flight Center (GSFC), performed the tests acting as either the Service Provider or Service User To provide realistic prototype testing when acting in the role of the Service Provider, DLR and NASA used data from past missions: – DLR – GSOC missions TerraSAR-X, TET-1 and GRACE – NASA missions from the NASA Near Earth Network (NEN) (Solar- B mission and the NOAA Satellite Information System (NOAASIS)) and NASA’s Space Network (SN) for unused time.

Three Test Cases Test Case 1 focused on manually building an XML formatted file using the SSFS schema to test the ability to generate a schedule that is understandable to the Service User. – Demonstrated that a Simple Schedule could be developed with extended information and exchanged by . – 3 Test Runs of Test Case 1 were completed Test Case 2 utilized automated tools to build XML formatted files using the SSFS schema to test the ability to generate a large schedule used in operational scenarios that is understandable to the Service User. Large published schedules were represented. – Demonstrated that the Simple Schedule Format can be used in situations where there are numerous contacts and hence it’s practicality for use in an operational environment. – 5 Test Runs of Test Case 2 were completed Test Case 3 demonstrated the ability to build an XML formatted files using the SSFS schema to generate a schedule for unallocated time of the ground stations/relay satellites in the network to be used by missions that is understandable to the Service User. – 2 Test Runs of Test Case 3 were completed

Test Success Criteria Success criteria for the data/file format: The file formatting may be easily created by the Service Provider, so that all the required information is provided with no workarounds needed The file format created by the generating side, may be re-read by both the Service Provider and User and all the information is assessed as being correct and complete with no information is lost It is desirable that the file format allows for some kind of sanity check mechanisms (i.e. schema mechanism for XML files) The data/file format allows safe transport over whatever transport media (FTP, , web-services, etc…), so that no information content is being lost or changed during transport All the information shall be easy (uniquely) identifiable (i.e. with help of descriptive keywords or identifiers) The Service User shall be able make use of the transported information content When using automated software tools for processing the file format, the systems shall be able to process all different combinations of allowed content or file format options, as defined (i.e. with schema file) without a need for reprogramming. The file format shall contain all information required to understand the information transported. The file format shall allow for different amounts of information transported, thus not imposing any artificial limits on number of entries. File format containing high amount of information (like schedule for 1000 passes) may be processed by both sides (generator and receiver).

How the tests were conducted Service Provider: Obtained an existing published schedule in a conventional format Rendered the schedule in an XML file using the simple schedule format XML schema either manually or using automated tools Sent an to Service User with attached the XML file Service User: Received the Service Provider furnished XML file via Interpreted the XML file consistent with the simple schedule format XML schema Rendered the output either manually or in tabular form using automated tools and then manually verifying it against the input by verifying all output (with small schedules) or by picking random schedule entries to spot check. Sent the schedule entry output to the Service Provider for verification that the entries were interpreted correctly.

Key results and conclusions Test Case 1, Run 1A - successful Test Case 1 flushed out many uncertainties about what the actual test should be and parameters that should be included. Issues were a result of human errors and uncertainties, not a result of the SSFS Test Case 1, Run 1B - successful No issues Test Case 1, Run 1C – error in schema detected Identified a wrong definition in the Schema for numberOfScheduledPackages – nonPositiveInteger was the definition, which makes us use -1, -2, etc... Issue corrected in schema

Test Case 2, Test Run 2A – successful Minor errors occurred due to the tools not the SSFS Test Case 2, Test Run 2B – successful, no issues Test Case 2, Test Run 2C – successful, no issues Test Case 2, Test Run 2D-1 – Service Provider error ICD said all of passes were Full passes (Telemetry, Offline Telemetry and Telecommand) but the Service Provider mistakenly used “TELECOMMAND” for Service Type. Test Case 2, Test Run 2D-2 – successful, no issues Key results and conclusions

Test Case 3, Test Run 3A – successful Question raised concerning Schedule status - is it OPERATIONAL or PROVISIONAL? –RESPONSE: It could be either depending on if there is a mix of scheduled passes and free times or not. Question raised about Beginning of track and end of track required by the Schema - did not make sense because nothing is being tracked. –RESPONSE: BB updated to clarify: Antenna Free Time shall be specified with beginningOfTrack and endOfTrack parameters, whereas beginningOfActivity and endOfActivity shall stay NULL. Test Case 3, Test Run 3B – successful Key results and conclusions

What needs to be addressed to complete the test report Tighten Test conclusions – discussions were captured but could lead the reader to think that there were issues when there weren’t any Clean up Table of Contents Finalize Acronym list One additional pass with Marcin to finalize. Mission Ops personnel?….see next chart

Reference to Mission Ops During a previous discussion, it was recommended that we get input from the mission ops personnel about the SoS format. We didn’t get very much feed back. Recommend removing the reference to Mission ops from the test plan. Marcin showed the SSFS to some operations guys and even to the ground stations, but did not get from them any specific “survey” on that. More or less the reaction was “ooo… well… a bit different, but … ooo yes, yes… now I understand… seems good. When it will be available?”. I do not know if one can put it as “official response” into Test Report.