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

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

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

Compatibility Tests Data exchange and manual check of the formats of the data products Data products are exchanged by any convenient mechanism (e.g. email). 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

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

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

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

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

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

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

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

Document link The document describing in details all the presented information: SOL-SGS-TS-0006: Instrument Teams to SOC Test Specification https://issues.cosmos.esa.int/solarorbiterwiki/x/QQTE https://issues.cosmos.esa.int/solarorbiterwiki/display/SOL/Instrument+Teams+to+SOC+Test+Specification SOWG#8 – ESAC – January 2016