1. Instrument Teams to SOC Test Specifications
Nana Bach
SOWG#8 – 26 Jan 2016

2. List of Interfaces
Low Latency Pipelines and their Visualisation ([AD.06] and [AD.07])
IOR exchange (Instrument operation Request) ([AD.02])
E-FECS exchange (Planning Skeleton)([AD.04])
Tm-Corridor exchange (A TM resource constraint definition on the IT’s) ([AD.05])
Other Auxiliary Data Products exchange, e.g.:
SPICE orbit file (no ICD yet)
Historic SPICE time-kernel (no ICD yet)
Historic SPICE attitude kernel (no ICD yet)
Boresight Alignment Definition File (no ICD yet)
Power Allocation File (no ICD yet)
The GFTS (all the data will be exchanged via this tool, Technical Description to be provided)
SOWG#8 – ESAC – January 2016

3. Identification of Test Levels (Test Design Description)
Compatibility
Integration Tests for all the exchanged data products
Validation
For all data products except Low Latency Pipelines and
Except GFTS
Low Latency Pipelines considered Externally Developed Software Products -> No Compatibility Test Cases
GFTS is not a data product but the media for their exchange (will be tested within each Integration and Validation Test Case, no special need on separate test cases)
SOWG#8 – ESAC – January 2016

4. Compatibility Tests
Data exchange and manual check of the formats of the data products
Data products are exchanged by any convenient mechanism (e.g. ).
Production and checking of the representative example file for each of the data products.
Data product generated by SOC -> 1 Compatibility Test Case
Data product generated by ITs -> 10 Compatibility Test Cases
SOWG#8 – ESAC – January 2016

5. Integration Tests
Data exchange and running specific Sub-System(s) in order to read and execute some involved parts of the Sub-Systems
Evaluate the outputs
Product delivery conducted using the intended flight mechanism, and development versions of the appropriate SW for the production, and ingestion at the other end.
Ingestion processing can be relative limited - it does not need to be a full end-to-end processing.
Integration Test Cases can be for all the instruments in one Integration Test Case per Data Product
SOWG#8 – ESAC – January 2016

6. Validation Tests
Part of particular System Tests which will involve running the entire System or relevant part of it
Involves all the data product exchange needed for given Interface Test
Objective is to operate the product, not in isolation, but in a representative scenario with good flight-like context (e.g. other related processing and product exchange in parallel).
End-to-end processing is highly desirable at this level.
Validation Test Cases will summarize all the data products and all the instruments involved into one System Test.
SOWG#8 – ESAC – January 2016

7. Compatibility Test Cases
Each Test Case should contain:
Definition of the Input Dataset
Definition of the expected Output Dataset
Definition of the Execution Pre- and Post-Conditions
Definition of the Entry Criteria
Definition of the Exit Criteria
Environment/Hardware definition
Definition of the Test Procedure in detail
Pass/Fail criteria
Responsibilities in each side of the Interface (SOC of Solar Orbiter and the External Interface)
SOWG#8 – ESAC – January 2016

8. Integration Test Cases
Each Test Case should contain:
Definition of the Input Dataset
Definition of the expected Output Dataset
Definition of the Execution Pre- and Post-Conditions
Definition of the Entry Criteria
Definition of the Exit Criteria
Environment/Hardware definition
Definition of the Test Procedure in detail
Pass/Fail criteria
Responsibilities in each side of the Interface (SOC of Solar Orbiter and the External Interface)
SOWG#8 – ESAC – January 2016

9. Validation Test Cases Each Test Case should contain:
Definition of the Input Dataset
Definition of the expected Output Dataset
Definition of the Execution Pre- and Post-Conditions
Definition of the Entry Criteria
Definition of the Exit Criteria
Environment/Hardware definition
Definition of the Test Procedure in detail
Pass/Fail criteria
Responsibilities in each side of the Interface (SOC of Solar Orbiter and the External Interface)
SOWG#8 – ESAC – January 2016

10. First Schedule FROM TO ICD Draft Compatibility Integration Validation
Reference schedule are System Tests (=Validation Test Cases)
Going back in time to Integration and Compatibility Test Cases
Inputs from E-FECS and TM-Corridor needed for IOR
First System Test is PTR Validation
FROM TO
ICD Draft
Compatibility
Integration
Validation
E-FECS
SOC
ITs
yes
01-Apr-16
01-Mar-17
01-Apr-18
TM-Corridor
IOR
01-Oct-16
01-Jul-17
SOWG#8 – ESAC – January 2016

11. List of existing ICDs
[AD.02] IOR-ICD SOL-SGS-ICD-0003 Instrument Operation Request ICD
[AD.03] SOL-SGS-TN-0009 Metadata Definition for Solar Orbiter Science Data
[AD.04] SOL-SGS-ICD-0006_EFECS-ICD Extended Flight Events and Communications Skeleton (E-FECS) file ICD
[AD.05] SOL-SGS-ICD-0007_TMC-ICD Solar Orbiter TM corridor ICD
[AD.06] SOL-SGS-ICD-0004_LLCDFICD Solar Orbiter Interface Control Document for Low Latency Data CDF Files
[AD.07] SOL-SGS-ICD-0005_LLFITSICD Solar Orbiter Interface Control Document for Low Latency Data FITS Files
SOWG#8 – ESAC – January 2016

12. Document link
The document describing in details all the presented information: SOL-SGS-TS-0006: Instrument Teams to SOC Test Specification
SOWG#8 – ESAC – January 2016