Dateoct. 12, 2017
Demandes

Getting issues...


Summary

Preparation of the E2E-0 test data package for RPW:

  • Related procedure/sequence to be delivered at MOC before  (SOC in copy). 
  • Draft of related STP IORs to be delivered at SOC before .
  • Final related STP IORs to be delivered at SOC on April 2018.
  • SOC will send test specification on March-April 2018.
  • MEB PFM IDB 4.3.3 will be used during test.
  • The 0th E2E test is planned to be run on April-May 2018 at SOC.
  • Presence of people from RPW at ESAC is not required (TBC)

Details about the E2E-0 test plan and specification can be found on the SOC public page (see https://issues.cosmos.esa.int/solarorbiterwiki/display/SOSP/SOC+System+Test+Specifications)

Input data files sent by SOC are available here: https://rpw.lesia.obspm.fr/roc/data/private/devtest/soc/E2E-0/ (restricted access)

Main points of contact are:

  • Sylvain Lodiot at MOC (for procedures/sequences)
  • Chris Watson at SOC (for IOR)
  • Andrew Walsh at SOC (for LTP exercice timeline and E2E-0 datapackage submission)
  • Fernando Martin Porqueras at SOC (for test manager)

Main features of the data package

  1. Release of the set of flight procedures/sequences to run the IOR related to the LTP SOWG10 exercice timeline (see https://solarorbiter.esac.esa.int/soopkitchen/#/planning/SOWG10_LTP_Exercise)
  2. Release of the STP IORs as expected by SOC (see E2E-0 test plan).

Description of the data package

  • Set of STP IORs for the E2E-0 CP test
  • Associated procedures/sequences (already delivered in the IGST 4_2 datapack)
  • README.rst with a description of the content
  • CHANGELOG.rst, with a history of modifications

The data package must be released as a zip file, named as: RPW_0thE2E_DATAPACK_IssueXX_RevYY.zip, where XX and YY are the issue and revision of the data pack.

Additionally, the ROC shall deliver the set of STP IOR files, as specified in the E2E-0 test plan.

Status of the data package 

Sequences status

The sequences required to run the E2E-0 test are delivered to the MOC via the IGST data package.

See RPW IGST 4_2 DATAPACK RELEASE for a complete list of the sequences status.

Deliverable status

It is planned to deliver the IOR XML files for two identified STP-cycles of the SOWG10 LTP exercice timeline.

ContentStatusComment
Set of draft STP IORs for the 0th E2E test

Delivered to SOC on  

(Feedbacks in comments of this page, and several iterations before finalization : v1.5)

To be checked:

  • Do the IORs cover the LTP time range?
  • Do the IORs are consistent with the LTP RPW modes?
  • Do the IORs are in agreement with the TMC constraints?
  • Do the IORs are valid according to the IDB (4.3.3 PFM)?
  • Do the IORs are valid according to the IOR ICD?
  • Do the SOC GFTS is up-and-running?
Set of final STP IORs for the 0th E2E testDone on May 16, 2018

Related Documents

IORs_E2E0th_v1.1.zipIORs_E2E0th_v1.5.zip

Expected documentation

N/A

Release-related JIRA issues

Key Summary T Created Updated Due Assignee Reporter P Status Resolution
Loading...
Refresh



2 Comments

  1. 20/03/2018:

    Added a new version of the E2E0th_v1.2 including the telemetry calculation

    STP_data_rate_E2E0th_v1.2_telemetry.xlsx

  2. Comments sent by Andrew : 

    1) For the the absolute synchronisation flag parameters, the MIB we have only has their raw values defined, not the engineering values. I doubt that a MIB update will make it through the system in time for the test so I'd suggest using the raw values in the IORs, and sorting out the definition of the engineering values in the MIB outside/after the test.

    I know this syntax works (at least in our planning tool): <value representation="Raw" radix="Decimal">0</value>

    2) Most of the errors are to do with the parameter values in the sequence calls. Although the schema allows the value element to be empty, our planning system doesn't (we'll fix this inconsistency one way or the other for the next version of the ICD - the test is good for catching our mistakes too!). In any case, looking at the sequence definitions, no default values for these parameters have been set (defaults don't propagate from the command parameters to the sequence parameters in our system), you'll need to explicitly specify the parameter value for each sequence call, e.g.

    <value representation="Raw" radix="Decimal">0</value>

    3) you're using command parameters directly in the sequence calls. Instead you should use the parameters that are defined for the sequences and which map to the relevant command parameters. So for example when you call AIWF035C in your IOR


            <sequence name="AIWF035C">
            <observationID>SRPW003ID0101001</observationID>
            <source>SRPW</source>
            <destination>R</destination>
            <executionTime>
              <actionTime>2020-158T22:15:36Z</actionTime>
            </executionTime>
            <parameterList count="1">
              <parameter name="PIW01293" position="1">
                <value/>
                <description>Absolute synchronization flag.</description>
              </parameter>
            </parameterList>
          </sequence>

    The parameter should be XF035C01, the value of which is passed to the command parameter when the sequence is expanded to commands by the MOC's mission planning system: ZIW00040 ( PIW01293 = XF035C01 ); see the attached FCP pdf. The parameters for each sequence are defined in the FCPs from ESOC and also in the MIB. It looks like sdf.dat summarises how sequence and command parameters link together, but I'm not very familiar with the MIB so I couldn't tell you exactly what all columns in the file are.