Dateoct. 12, 2017
Demandes

Getting issues...


Summary

Preparation of the IGST 4_2 data package for RPW:

  • The IGST 4_2 is planned to be run on the ETB with MEB EM2 on April 2018 
  • ISM doc. to be delivered at MOC before 
  • Procedure/sequence to be delivered at MOC before . 
  • MEB EM2 with IDB 4.3.3 will be used on ETB during test, however the procedures/sequences must be written using the PFM IDB 4.3.3 version (indicating clearly where there are discrepancies between the two versions).
  • Presence of 1-2 max. people from RPW at ESOC during test is strongly recommended by MOC

Interlocutors are:

  • Sylvain Lodiot at MOC

Main features of the release

  • Preparation of the RPW flight procedures/sequences for:
    • Switch-on,
    • Ping,
    • exercise the different modes and changes between them (test the state model in the ORCD),
    • dump with S6 of one of the instrument memories,
    • generate science if possible,
    • Text S22 (context saving) if applicable (Not applicable for RPW)
    • Switch-off.

  • Preparation of the related RPW Instrument State Model (ISM) doc. 

Description of the data package

  • List of RPW flight sequences (SQ) Excel files (one file per sequence), named as the sequence convention in the FOP Plan (FOPP) doc. The SQ files must be gathered by procedure (one directory per proceduce named as the procedure convention defined in the FOPP). The procedure directories must be grouped by type "FCP", "CRP" or "COM" (one directory per type).
  • The RPW ISM doc. in pdf format
  • The RPW MU updated with the procedure/sequences.
  • A README.rst text file providing information about the content of the package
  • a CHANGELOG.rst providing the changes history.

The name of the data package must be delivered as a zip file, named as: RPW_IGST4-2_DATAPACK_IssueXX_RevYY.zip, where XX and YY are the issue and revision of the data pack.

Main constraints

IGST RPW-related setup

The IGST will be run on the ETB with the RPW EM2.

In terms of command/control the RPW IDB (V4.3.3) is the same for EM1, EM2 and PFM, nevertheless the FDIR triggering threshold values can be different between the 3 models! This has to be taken account when validated the test results.

Moreover there is no SCM and PA-HF/ANT sensor on the ETB/RPW-EM2 setup, in consequence during the IGST :

  • Switching ON SCM shall be prohibited
  • BIAS HV shall be not ENABLE
  • BIAS current setting/sweeping/calibration shall not be performed
  • Switching ON PA HF shall be prohibited


NOTE

According to Sylvain Lodiot (see comments at the bottom of the page) the corresponding prohibited TCs in the sequences must be clearly indicated with the  [not for the EM2 on the ETB] comment.

Status of the data package 

Sequences status

IGST mandatory sequences

The table gives the list of critical sequences required to perform the IGST test.

Sequence nameDescriptionCategoryStatusComment
AIWF001AFrom SAFE mode switch OFF the RPW prime power interface (UNIT_A and UNIT_B ) via OBCP. Nominal switch OFF via OBCPDelivered
AIWF002AFrom SAFE mode switch OFF the RPW prime power interface (UNIT_A and UNIT_B ) via manual.Other OFF proceduresDelivered
AIWF002BSwitch OFF the RPW prime power interface (UNIT_A) via OBCP from the SAFE modeOther OFF proceduresDelivered
AIWF010ABoot RPW DBS in prime power interface (UNIT_A) via OBCPNominal switch ON via OBCPDelivered
AIWF011ABoot RPW DBS in prime power interface (UNIT_A) via manualNominal switch ON via manualDelivered
AIWF030ABoot RPW DAS from EEPROM1 (default), EEPROM2, RAMModes transitionDelivered
AIWF031AEnter SERVICE mode and switch on RPW equipmentNominal Switch On equipmentDelivered
AIWF032AConfigure HK periodConfiguration DPU and DASDelivered
AIWF032BLoad DPU and DAS common parametersConfiguration DPU and DASDelivered
AIWF032CLoad DPU and DAS power parametersConfiguration DPU and DASDelivered
AIWF032DConfigure Bias High Voltage parameterConfiguration DPU and DASDelivered
AIWF032EConfigure parameters for monitoring temperatureConfiguration DPU and DASDelivered
AIWF032FConfigure Waveform parametersConfiguration DPU and DASDelivered
AIWF032GConfigure SBM1 parametersConfiguration DPU and DASDelivered
AIWF032HConfigure SBM2 parametersConfiguration DPU and DASDelivered
AIWF032IConfigure SC potential computation algorithmConfiguration DPU and DASDelivered
AIWF032JClear HK counterConfiguration DPU and DASDelivered
AIWF032KEnable HK parameter report generationConfiguration DPU and DASDelivered
AIWF035AEnter in SCIENCE SURVEY_NORMAL submodeModes transition ScienceDelivered
AIWF035BEnter in SCIENCE SURVEY_BURST submodeModes transition ScienceDelivered
AIWF035CEnter in SBM_DETECTION modeModes transition ScienceDelivered
AIWF037AConfigure THR for the RPW SCIENCE SURVEY_NORMAL mode.Configuration THRDelivered
AIWF037BConfigure THR for the RPW SCIENCE SURVEY_BURST mode. Configuration THRDelivered
AIWF037CLoad calibration parameters for THRConfiguration THRDelivered
AIWF038ALoad common parameters of TDSConfiguration TDS

AIWF038BConfiguration of TDS for SBM1 modeConfiguration TDS

AIWF038CConfiguration of TDS for SBM2 modeConfiguration TDS

AIWF038DConfigure TDS LFM parametersConfiguration TDS

AIWF038EConfigure TDS for the RPW SCIENCE SURVEY_NORMAL mode. Configuration TDS

AIWF038FConfigure TDS for the RPW SCIENCE SURVEY_BURST modeConfiguration TDS

AIWF039AConfiguration of LFR for SBM1 modeConfiguration LFR

AIWF039BConfiguration of LFR for SBM2 modeConfiguration LFR

AIWF039CLoad common parameters of LFRConfiguration LFR

AIWF039DConfigure LFR for the RPW SCIENCE SURVEY_NORMAL mode. Configuration LFR

AIWF039EConfigure LFR for the RPW SCIENCE SURVEY_BURST mode.Configuration LFR

AIWF040AConfigure the Bias (mode, and relay) for the RPW SCIENCE mode.Configuration Bias

AIWF041AEnable CompressionCompression

AIWF041BDisable CompressionCompression

AIWF042ASwitch the converter (CONV)Switch On equipment

AIWF042BBOOT LFR from EEPROM1 (default), EEPROM2 and RAM + Enabled Verif BootSwitch On equipment

AIWF042CBOOT THR from EEPROM1 (default), EEPROM2 and RAM + Enabled Verif BootSwitch On equipment

AIWF042DBOOT TDS from EEPROM1 (default), EEPROM2 and RAM + Enabled Verif BootSwitch On equipment

AIWF042ESwitch ON BIASSwitch On equipment

AIWF042FPA Switch ONSwitch On equipment

AIWF042GSCM switch ONSwitch On equipment

AIWF043AEnter SERVICE modeEnter SERVICE Mode

AIWF044AEnter in SCIENCE SURVEY_BACKUP submodeEnter Science BACKUP Mode

AIWF045AEnter in RPW STANDBY mode from any other mode (except OFF)Enter STANDBY Mode

AIWF046AGo to SAFE mode (DBS) with TC_DPU_RESET commandEnter SAFE Mode

AIWF260ADump DPU memory (TC_DPU_DUMP_MEMORY - Service 6)Memory dump (S6)

AIWF370ARun a test connection (PUS, Service 17) with the TC_DPU_TEST_CONNECTION {ZIW00012} (i.e. "ping")"ping" (PUS, Service 17)

Extra sequences (required for the E2E 0th test)

Additionally to the sequences above, the following sequences shall not be run during the IGST, but are required to perform the E2E 0th test performed by the SOC (see RPW E2E-0 TEST DATAPACK RELEASE for more details).

Sequence nameDescriptionCategoryStatusComment
AIWF033AInternal Calibration for LFRCalibrationDelivered
AIWF033BBIAS CalibrationCalibrationDelivered
AIWF033CRun THR internal calibrationCalibrationDelivered
AIWF033DConfigure and execute the BIAS sweepCalibrationDelivered
AIWF034ADump LFR, TDS, THR parametersDumpDelivered
AIWF036AConfiguration Bias currentsConfiguration Bias CurrentsDelivered


ISM status

VersionStatusCommentChecking
1.0DeliveredDelivered with the datapack 1.0
1.1Delivered

Delivered with datapack 1.1.

  • Does the ISM is consistent with the list of delivered sequences?
  • Does the ISM fully cover the delivered sequences (and transitions)?
1.2DeliveredDelivered with datapack 1.2

Data package delivery status

VersionStatusDelivery dateCommentChecking
1.0Delivered

 

Delivered to Sylvain Lodiot (MOC). See feedbacks in ROCOPE-81 - Getting issue details... STATUS


1.1Delivered

 

Delivered to Sylvain Lodiot (MOC).

  • Is the new naming convention for the sequences compliant?
  • Does the list of sequences is consistent with what has been decided with the MOC?
  • Does the RPW UM is up-to-date?
  • Does the datapack is complete?
1.2Delivered

 

Delivered to Sylvain Lodiot (MOC). See feedbacks in ROCOPE-126 - Getting issue details... STATUS


Expected documentation


QuestionAnswerSeverityComment
Do the sequences related to the routine operations (Bias sweeping, calibrations, etc.) will be tested during the IGST?No (especially, the BIAS sweeping/calibration/current setting shall not be run if BIAS HV is DISABLE)Low
What is the configuration of the flight software (DBS, DAS) at boot? Is the TM_DPU_OBC_HK generation ENABLE or DISABLE?
Medium


Attached items

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


19 Comments

  1. Xavier Bonnin

    As said previously, the RPW procedures/sequences are written using the IDB MEB PFM 4.3.3 version (named "4.3.3" in the MIB). And there is no difference in terms of control/command with the MEB EM2 4.3.3 IDB (used for the IGST on ETB). However our RPW system engineer at CNES says that some specific commands (TC) must not at all be executed on the MEB EM2 on the ETB(e.g., SCM and PA HF switching-on). Our first idea is to deliver our sequences without these TC inside. But do you prefer to remove them from your side after delivery? (And, hence, is it relevant to keep these sequences as "FCP" if we remove these TC? Should we use "SVT" instead or other procedure category?)

    1. Xavier Bonnin

      Sylvain Lodiot (MOC): first I confirm we'll be using  4.3.3_MEB_EM2 for the IGST 4_2. 
      I would propose that you deliver the inputs with those TCs, but with a specific comment saying explicitely [not for the EM2 on the ETB]. 
      What I'll do on my end is remove them from the procedures with a specific comment. This way, we are sure the commands will not be sent; I'll then add these TCs at a later stage. 
      Will we be able to use these TCs during SVT1 on the FM next year? Or only once in flight? 
      I'd keep these as FCPs to keep simple. We'll simply work with updated versions in the future. 
      Does this work for you?

  2. Xavier Bonnin

    At the SOWG11, Chris Watson said that the procedures/sequences required for the 0th E2E CP test must be delivered at the same time than the IGST ones (see slide 9 of https://issues.cosmos.esa.int/solarorbiterwiki/display/SOSP/SOWG+%2311+-+Jan+2018?preview=/23331212/23332085/SOWG11%20-%20E2E%20test%20v0_2.pptx). For now, we think about deliver 0th E2E and IGST sequences into two distinct data packages (.zip), is it fine for you?

    1. Xavier Bonnin

      Sylvain Lodiot (MOC): I assume the datapacks are the same (with reference to the procedures)? 
      What Chris will need in the end is IORs I guess? These need to be populated such that they are consistent with the command sequences I'll be generating and the database (containing these SQs) he'll be getting. So we should be able to do all in one go. 
      I don't need the IORs, just your procedure inputs. 
      Does this answer your questions?

  3. Diane Berard

    02/03/2018 : Roc team send an IGST 4_2 v1.2 package to S. Lodiot (MOC).

    Its comments are:

    " Some comments: 

    (1) 37b: some FPs had enginnering def values while the TC pars don't have calibrations. These have no def value now. I don't think this is a problem. 

    (2) 39c: comment second TC (executing 1 sec after) not understood 

    (3) 42D: typo: some FPs defined as eng in param val int 

    (4) 42B: def val of first FP NOK -> no def val 

    (5) 032a: changed value of PIW00002 to OBC_HK_SID; value specified is not in DB (IIT_HK_SID) 
    problem here? wrong TC? The TC par has only 1 calibrated value in the curve. 

    (6) 33D: how is the dump of the sweep parameters done? see comment in red @ step 4.4 

    (7) 34D: minor and FYI there is a space in the input file post TC ZIW00054! The import file complains! 

    (8) 034 overall, MAJOR: excel sheet mentions 1 SEQ, input has 4, SEQs A to 3 seem identical, SEQ D has DAS and other identical TCs. 
    Please clarify what is really intended with this procedure. 

    (9) 046 procedure: why does your new input only contain the reset TC and no longer the equipment off TCs? Where is this done if this is removed? I have left all OFF TCs for the time being. 

    -------------- 
    general 

    how is TM 180, 34 generated? 

    --------------"

  4. Antonio Vecchio

    02/03/2018 : Other omments from S. Lodiot (MOC) about IGST 4_2 v1.2 package


    (1) please cross check my procs and in particular all TC parameters/
    (2) we need to coe up with a timeline for IGST 4_2
    (3) can we do any patching on top of the dumps? Please specify patch/dump addresses
    (4) let me know if you want any specific TM displays and graphs for the test
    (5) I'll need a formal GO and approval from you for the procedures and the timeline. Written. per email is fine.
    (6) Once you are OK with the procs, I'll put them in conf control and generate the corresponding command sequences and will pass you the corresponding database as agreed.

  5. Antonio Vecchio

    05/03/2018: ROC response to S. Lodiot comments:


    I corrected the sequences using your comments. I attach the new version of the modified sequence (changes have been highlighted in red in each xls file).

    Here are some comments about your questions:

    (1) In CMD param sheet, line 48 -49 : FP_Dec_val_int have been changed from Dec to Eng.

    (2) I removed the line 3: the comment was for a previous version of sequence. Don't take it into account.

    (3) You are right. Line 4 and 5 have been corrected in CMD param sheet

    (4) Yes the def value is LFR_EXE_EEPRM1

    (5) It was a mistake. In STMT sheet, line 20 : TC_DPU_UPDATE_HK_PERIOD, and in CMD param sheet, line 18 PIW00000

    (6) The comment a line 12 "DUMP BIAS sweep params" of the sequence 33D is no more needed. It is left from a previous version of the same sequence. Indeed to check the values of sweep current now, we use the PKT YIW00287.

    (7) noted

    (8) It is a mistake : the 4 sequence 34A,B,C,D are the same. Remove B,C and D sequence and keep only 34A. This sequence is about dumping parameter for each sub-system. So it contains 3 TC and 3 TM checks. Is it ok for you?

    (9) The TC DPU_RESET switch off all the equipment before go back to SAFE. So the switches off are included. But we agree that it's better to turn off the equipments before. So you can keep seq 46A as you did.

    We were considering create separated sequences to switch off each equipment independently of each other (for example 46B, C, D...). But it won't be tested at IGST 4_2.


    -----------

    I do not understand your question about generation of TM 180 and 34? Could you please give me some details?


    Everything else sounds good for us so you can generate the command control.

    -----------

    Timeline:

    We will take a closer look at your timeline but at first approach, it looks ok for us.

    What is the deadline to give you the final timeline for IGST 4_2 tests?

    Do you have the final dates of IGST 4_2?

  6. Antonio Vecchio

    06/03/2018: ROC to S.Lodiot

    - Be careful that BIAS HV, and ANT should not be used for the IGST 4_2. So line 88 and after, it is necessary to add !!!NOT for the EM2 on the ETB!!! You added it but too late in the document.

    - Line 135 : you switch on the SCM but parameter PIW00104 = RPW_CONV_EID instead of RPW_SCM_EID (it was a mistake from us. I corrected it in our file)

  7. Antonio Vecchio

    07/03/2018: ROC to S.Lodiot

    About your comment (9) : the TC_DPU_ENTER_STANDBY switches off properly all the equipement, so when we are in SERVICE mode, we planned to use the 45A sequence to enter STAND BY and switch off all the equipement and then go to SAFE mode using 46A. So in the 46A, no need to switch off the equipment.

    Nevertheless, you highlight a point : do you want us to test the switch off of each equipment independently? We could create a new procedure (for exemple IW-FCP-047) with a sequence for each switch off ?

  8. Antonio Vecchio

    14/03/2018: S. Lodiot to ROC
    ------------------------------------------------------------------------------------------------------
    (1) In CMD param sheet, line 48 -49 : FP_Dec_val_int have been changed from Dec to Eng.
    SL; procedure updated (SEQ 37B)
    (2) I removed the line 3: the comment was for a previous version of sequence. Don't take it into account.
    SL: OK, procedure 039 attached but unchanged.
    (3) You are right. Line 4 and 5 have been corrected in CMD param sheet
    (4) Yes the def value is LFR_EXE_EEPRM1
    SL: OK, procedure 042 updated.
    (5) It was a mistake. In STMT sheet, line 20 : TC_DPU_UPDATE_HK_PERIOD, and in CMD param sheet, line 18 PIW00000
    SL: SEQ 032A updated
    (8) It is a mistake : the 4 sequence 34A,B,C,D are the same. Remove B,C and D sequence and keep only 34A. This sequence is about dumping parameter for each sub-system. So it contains 3 TC and 3 TM checks. Is it ok for you?
    SL: fine with me, procedure 034 updated
    (9) The TC DPU_RESET switch off all the equipment before go back to SAFE. So the switches off are included. But we agree that it's better to turn off the equipments before. So you can keep seq 46A as you did.
    SL: see below, superseeded
    We were considering create separated sequences to switch off each equipment independently of each other (for example 46B, C, D...). But it won't be tested at IGST 4_2.
    SL: fine with me; provide me the input when needed/available.

    ------------------------------------------------------------------------------------------------------
    I do not understand your question about generation of TM 180 and 34? Could you please give me some details?
    SL: if you look @ proc 032 for ex, step 1.9, we check for YIW00063 (180,34). I'm just wondering how this dump is generated. Via procedure 034?

    Everything else sounds good for us so you can generate the command control.
    SL: OK; I'll wait for your final go for all above and then put in conf control.

    ------------------------------------------------------------------------------------------------------
    Timeline:
    We will take a closer look at your timeline but at first approach, it looks ok for us.
    What is the deadline to give you the final timeline for IGST 4_2 tests?
    Do you have the final dates of IGST 4_2?
    SL: IGST 4_2 is now planned for 15/16 May. Which day for RPW we'll get back to you soon. I'll need the names of RPW people coming on site. 2-3 max ideally!

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

    I was looking at some of your inputs and I found errors in the procedure IW-FCP-031 :
    - Be careful that BIAS HV, and ANT should not be used for the IGST 4_2. So line 88 and after, it is necessary to add !!!NOT for the EM2 on the ETB!!! You added it but too late in the document.
    - Line 135 : you switch on the SCM but parameter PIW00104 = RPW_CONV_EID instead of RPW_SCM_EID (it was a mistake from us. I corrected it in our file)
    SL: procedure updated.
    ------------------------------------------------------------------------------------------------------
    About your comment (9) : the TC_DPU_ENTER_STANDBY switches off properly all the equipement, so when we are in SERVICE mode, we planned to use the 45A sequence to enter STAND BY and switch off all the equipement and then go to SAFE mode using 46A. So in the 46A, no need to switch off the equipment.
    SL: not done yet and just to cross check; I shall delete all switch off equipment TCs.
    Nevertheless, you highlight a point : do you want us to test the switch off of each equipment independently? We could create a new procedure (for exemple IW-FCP-047) with a sequence for each switch off ?
    SL: fine with me; I can create the 047 based on what I delete from 046.

    ------------------------------------------------------------------------------------------------------
    (6) 33D: how is the dump of the sweep parameters done? see comment in red @ step 4.4

    ANSW: The comment a line 12 "DUMP BIAS sweep params" of the sequence 33D is no more needed. It is left from a previous version of the same sequence. Indeed to check the  values of sweep current now, we use the PKT YIW00287.
    SL: OK, procedure updated

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

    We have several questions though:

    - When will happen IGST tests?
    See above, 15/16 May

    - Do you need the absolute timings (like in an IOR) of each sequence?
    SL: no. we'll load each sequence one after the other on our control system straight, and as this is the first time, send the commands one after the other. So no need for anything else from you.


    Let us know if  this proposition is ok for you?
    SL: I like the proposition! Do you have an idea of how long the whole timeline takes? Should we skip the dark blue part at the end? What is the purpose of that?


    ------------------------------------------------------------------------------------------------------
    Next steps:
    ------------------------------------------------------------------------------------------------------
    (1) please cross check my procs and in particular all TC parameters -> nearly there. happy with latest updates?
    (2) we need to come up with a timeline for IGST 4_2 -> nearly there
    (3) can we do any patching on top of the dumps? Please specify patch/dump addresses status?
    (4) let me know if you want any specific TM displays and graphs for the test
    (5) I'll need a formal GO and approval from you for the procedures and the timeline. Written. per email is fine.
    (6) Once you are OK with the procs, I'll put them in conf control and generate the corresponding command sequences and will pass you the corresponding database as agreed. Do you need this for the go under (5)? I'd need to send out the procs for review to ADS and project end of next week...!


  9. Antonio Vecchio

    14/03/2014: J.M. Travert to ROC


    Suite à la téléconférence, voici les infos qui vous permettrons de désactiver les FDIR internes RPW.
    Les FDIR internes sont gérées par les 3 TC suivantes :

    • TC_DPU_LOAD_POWER_PAR avec les arguments qui se présentent sous la forme suivante :
    • SY_DPU_XXX_YYY_HNOM : qui définit la valeur haute nominale
    • SY_DPU_XXX_YYY_LNOM : qui définit la valeur basse nominale
    • SY_DPU_XXX_YYY_WDEV : un pourcentage de dépassement des seuils nominaux à partir duquel on lève un warning
    • SY_DPU_XXX_YYY_FDEV : un pourcentage de dépassement des seuils nominaux à partir duquel on lance une action de reconfiguration
    • SY_DPU_XXX_YYY_MTR : un booléen qui définit si le monitoring est actif
    • SY_DPU_XXX_YYY_REC : un booléen qui définit si les actions de reconfigurations doivent être jouées
    • TC_DPU_LOAD_TEMP_PAR avec les arguments qui se présentent sous la forme suivante :
    • SY_DPU_XXX_YYY_LOW : qui définit la valeur basse en dessous de laquelle on lance une action de reconfiguration
    • SY_DPU_XXX_YYY_UP : qui définit la valeur haute au-dessus de laquelle on lance une action de reconfiguration
    • SY_DPU_XXX_YYY_MTR : un booléen qui définit si le monitoring est actif
    • SY_DPU_XXX_YYY_REC : un booléen qui définit si les actions de reconfigurations doivent être jouées
    • TC_DPU_LOAD_BHV_PAR avec les arguments qui se présentent sous la forme suivante :
    • SY_DPU_XXX_YYY_LOW : qui définit la valeur basse en dessous de laquelle on lance une action de reconfiguration
    • SY_DPU_XXX_YYY_UP : qui définit la valeur haute au-dessus de laquelle on lance une action de reconfiguration
    • SY_DPU_XXX_YYY_MTR : un booléen qui définit si le monitoring est actif
    • SY_DPU_XXX_YYY_REC : un booléen qui définit si les actions de reconfigurations doivent être jouées


     
    Pour éviter que les FDIR ne déclenche pendant les essais il y a donc plusieurs possibilité :

    • Modifier les seuils pour les FDIR ne déclenche pas avec le modèle sur lequel l’essai est joué
    • C’est la méthode la plus propre c’est le travail qui a été fait pour définir des seuils FDIR correct pour le modèle PFM mais c’est fastidieux
    • Désactiver totalement la FDIR en passant toutes les booléens _MTR et _REC à DISABLE
    • C’est la méthode choisi pour les test sur l’EM2 fait chez ADS
    • Désactiver seulement les actions de reconfiguration en passant les booléens _REC à DISABLE
    • Cette méthode permet de voir passer les évènements liées au Monitorings mais sans déclencher les actions de reconfiguration


     
    A priori vous pouvez choisir n’importe laquelle des méthode 2 ou 3. Je conseil d’utiliser la méthode 2 comme pour les tests ADS car il est possible que côté ESA ils surveillent toutes les TM inattendues pendant l’IGST et donc qu’il faille par la suite expliquer chacune des occurrences des TM inattendues ce qui peut être fastidieux si il y en a beaucoup.
    Les 2 premières TC sont je pense envoyées respectivement par les séquences AIWF032C et AIWF032E, il faudra donc peut-être faire une version spécifique de ces séquences pour les essais avec EM2. Pour la 3ème je ne sais pas si elle est déjà dans une des séquences ou pas.
    Dans tous les cas il faudra que vous vérifiez que l’on n’envoi aucunes de ces TC dans d’autres séquences pour ne pas ré-écrasée les valeurs qu’on aura mise.
     
    De plus lorsque l’on démarre LFR, THR ou TDS avec les TC de boot dédiées TC_DPU_BOOT_LFR, TC_DPU_BOOT_THR et TC_DPU_BOOT_TDS l’argument CP_DPU_XXX_BOOT_VERIF permet de faire des vérifications liées aux FDIR lors du BOOT. Je ne sais pas comment ces vérifications se comportent les vérif sont à ENABLE mais les FDIR désactivées, il faudrait poser la question à Leroy et/ou Philippe sur ce point. Il sera peut être nécessaire de passer les vérif à DISABLE pour être sûr que ça fonctionne. Pour les démarrage des analyseurs je suis d’avis de ne pas faire de modifications si ce n’est pas réellement nécessaire car toutes les procédures spécifiques pour les essais ne seront donc pas validées en version « vol ».
     
    Si ce n’est pas clair n’hésitez pas à poser des questions.
     
    Jean-Michel


    Les différences entre DB_433_EM2 et DB_433 tout court sont dans le fichier txt joint, il y’a un certain nombre de courbe de calibration mais comme préciser dans la téléconf les seuils FDIR ne correspondent pas à l’EM2 et donc la modif n’est pas suffisante pour éviter les déclenchements de FDIR.

    ****************************************************************************************


    Version numbers

Latest EM IDB: 4.3.3 MEB EM2
Latest FM IDB: 4.3.3 MEB PFM


TM & TC packet & parameter structures

None


Calibrations (manually selected)

- CIW00056TM (EM) / CIW00056TM (FM)	changed
- CIW00052TM (EM) / CIW00052TM (FM)	changed
- CIW00051TM (EM) / CIW00051TM (FM)	changed
- CIW00053TM (EM) / CIW00053TM (FM)	changed
- CIW00059TM (EM) / CIW00059TM (FM)	changed
- CIW00060TM (EM) / CIW00060TM (FM)	changed
- CIW00061TM (EM) / CIW00061TM (FM)	changed
- CIW00062TM (EM) / CIW00062TM (FM)	changed
- CIW00063TM (EM) / CIW00063TM (FM)	changed
- CIW00064TM (EM) / CIW00064TM (FM)	changed
- CIW00065TM (EM) / CIW00065TM (FM)	changed
- CIW00066TM (EM) / CIW00066TM (FM)	changed
- CIW00067TM (EM) / CIW00067TM (FM)	changed
- CIW00068TM (EM) / CIW00068TM (FM)	changed
- CIW00069TM (EM) / CIW00069TM (FM)	changed
- CIW00070TM (EM) / CIW00070TM (FM)	changed
- CIW00072TM (EM) / CIW00072TM (FM)	changed
- CIW00073TM (EM) / CIW00073TM (FM)	changed
- CIW00074TM (EM) / CIW00074TM (FM)	changed
- CIW00075TM (EM) / CIW00075TM (FM)	changed
- CIW00071TM (EM) / CIW00071TM (FM)	changed
- CIW00076TM (EM) / CIW00076TM (FM)	changed
- CIW00077TM (EM) / CIW00077TM (FM)	changed
- CIW00078TM (EM) / CIW00078TM (FM)	changed
- CIW00079TM (EM) / CIW00079TM (FM)	changed
- CIW00080TM (EM) / CIW00080TM (FM)	changed
- CIW00081TM (EM) / CIW00081TM (FM)	changed
- CIW00083TM (EM) / CIW00083TM (FM)	changed
- CIW00082TM (EM) / CIW00082TM (FM)	changed
- CIW00035TM (EM) / CIW00035TM (FM)	changed
- CIW00036TM (EM) / CIW00036TM (FM)	changed
- CIW00037TM (EM) / CIW00037TM (FM)	changed
- CIWP0077TC (EM) / CIWP0077TC (FM)	changed
- CIWP0032TC (EM) / CIWP0032TC (FM)	changed
- CIW00092TM (EM) / CIW00092TM (FM)	changed
- CIWP0073TC (EM) / CIWP0073TC (FM)	changed
- CIWP0074TC (EM) / CIWP0074TC (FM)	changed


Calibrations (automatically selected

N/A

     


     

  10. Antonio Vecchio

    14/03/2018: ROC to S. Lodiot

    ------------------------------------------------------------------------------------------------------
    (1) In CMD param sheet, line 48 -49 : FP_Dec_val_int have been changed from Dec to Eng.
    SL; procedure updated (SEQ 37B) ok
    (2) I removed the line 3: the comment was for a previous version of sequence. Don't take it into account.
    SL: OK, procedure 039 attached but unchanged.     ok
    (3) You are right. Line 4 and 5 have been corrected in CMD param sheet
    (4) Yes the def value is LFR_EXE_EEPRM1
    SL: OK, procedure 042 updated. ok
    (5) It was a mistake. In STMT sheet, line 20 : TC_DPU_UPDATE_HK_PERIOD, and in CMD param sheet, line 18 PIW00000
    SL: SEQ 032A updated ok
    (8) It is a mistake : the 4 sequence 34A,B,C,D are the same. Remove B,C and D sequence and keep only 34A. This sequence is about dumping parameter for each sub-system. So it contains 3 TC and 3 TM checks. Is it ok for you?
    SL: fine with me, procedure 034 updated ok
    (9) The TC DPU_RESET switch off all the equipment before go back to SAFE. So the switches off are included. But we agree that it's better to turn off the equipments before. So you can keep seq 46A as you did.
    SL: see below, superseeded
    We were considering create separated sequences to switch off each equipment independently of each other (for example 46B, C, D...). But it won't be tested at IGST 4_2.
    SL: fine with me; provide me the input when needed/available. You just need to use the switches off you put in the proc 46.

    ------------------------------------------------------------------------------------------------------
    I do not understand your question about generation of TM 180 and 34? Could you please give me some details?
    SL: if you look @ proc 032 for ex, step 1.9, we check for YIW00063 (180,34). I'm just wondering how this dump is generated. Via procedure 034? 

    a TC to generate this dump was indeed missing. We added a new TC: STMT_nr 23 ZIW00054 TC_DPU_DAS_DUMP_PAR. No CMD Params are needed for this TC.


    Everything else sounds good for us so you can generate the command control.
    SL: OK; I'll wait for your final go for all above and then put in conf control.

    ------------------------------------------------------------------------------------------------------
    Timeline:
    We will take a closer look at your timeline but at first approach, it looks ok for us.
    What is the deadline to give you the final timeline for IGST 4_2 tests?
    Do you have the final dates of IGST 4_2?
    SL: IGST 4_2 is now planned for 15/16 May. Which day for RPW we'll get back to you soon. I'll need the names of RPW people coming on site. 2-3 max ideally! ok the date is in our agendas. I will come (Diane Bérard) with Antonio (Antonio Vecchio). Please let us know as soon as possible when is the RPW turn so we can organize our plans.

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

    I was looking at some of your inputs and I found errors in the procedure IW-FCP-031 :
    - Be careful that BIAS HV, and ANT should not be used for the IGST 4_2. So line 88 and after, it is necessary to add !!!NOT for the EM2 on the ETB!!! You added it but too late in the document.
    - Line 135 : you switch on the SCM but parameter PIW00104 = RPW_CONV_EID instead of RPW_SCM_EID (it was a mistake from us. I corrected it in our file)
    SL: procedure updated. ok
    ------------------------------------------------------------------------------------------------------
    About your comment (9) : the TC_DPU_ENTER_STANDBY switches off properly all the equipement, so when we are in SERVICE mode, we planned to use the 45A sequence to enter STAND BY and switch off all the equipement and then go to SAFE mode using 46A. So in the 46A, no need to switch off the equipment.
    SL: not done yet and just to cross check; I shall delete all switch off equipment TCs. Yes you can delete all the switches off and put them into a new procedure called IW-FCP-47 and sequences from A to K. You can also remove the Enter_service and enter Stand_BY that are already done in independant sequences.
    Nevertheless, you highlight a point : do you want us to test the switch off of each equipment independently? We could create a new procedure (for exemple IW-FCP-047) with a sequence for each switch off ?
    SL: fine with me; I can create the 047 based on what I delete from 046. Yes please

    ------------------------------------------------------------------------------------------------------
    (6) 33D: how is the dump of the sweep parameters done? see comment in red @ step 4.4

    ANSW: The comment a line 12 "DUMP BIAS sweep params" of the sequence 33D is no more needed. It is left from a previous version of the same sequence. Indeed to check the  values of sweep current now, we use the PKT YIW00287.
    SL: OK, procedure updated ok

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

    We have several questions though:

    - When will happen IGST tests?
    See above, 15/16 May
    ok noted

    - Do you need the absolute timings (like in an IOR) of each sequence?
    SL: no. we'll load each sequence one after the other on our control system straight, and as this is the first time, send the commands one after the other. So no need for anything else from you. ok


    Let us know if  this proposition is ok for you?
    SL: I like the proposition! Do you have an idea of how long the whole timeline takes? Should we skip the dark blue part at the end? What is the purpose of that?
    If everything is working allright, the whole timeline is ~3min20  (if all the sequences are played one after each other without deadtimes).
    The darkest blue, is to switch off the instrument. So except if you want it to be on for tests of others instruments, you should run them.
    ------------------------------------------------------------------------------------------------------
    We have changed two sequences (32C et 32E) in order to avoid problems of threashold during tests. I attached the two concerned sequences.
    ------------------------------------------------------------------------------------------------------
     
    Next steps:
    ------------------------------------------------------------------------------------------------------
    (1) please cross check my procs and in particular all TC parameters -> nearly there. happy with latest updates? Yes, with the updates including in this emails, it should be good for us.
    (2) we need to come up with a timeline for IGST 4_2 -> nearly there For us the timeline is ok
    (3) can we do any patching on top of the dumps? Please specify patch/dump addresses status? What do you mean by "patch"? Do you mean flight software update? If yes, we won't have time to organize it so we won't be able to do so.
    (4) let me know if you want any specific TM displays and graphs for the test
    (5) I'll need a formal GO and approval from you for the procedures and the timeline. Written. per email is fine.
    (6) Once you are OK with the procs, I'll put them in conf control and generate the corresponding command sequences and will pass you the corresponding database as agreed. Do you need this for the go under (5)? I'd need to send out the procs for review to ADS and project end of next week...! Once you take into account the changes described in this email, you can send us the new proc and we will check one last time before final approval.

  11. Antonio Vecchio

    15/03/2018: S. Lodiot to ROC

    a) For 032 C and E I have not updated the TM checks as I assume we'll revert the command parameter values for flight. I have just added a comment.

    (b) for the timeline duration you are very optimistic! We'll be running everything manually so it will take longer!
    We should have a slot of about 2h (5 instruments/day) TBC.

    (c) For patch we're after something much simpler; dumping some address, if possible patching it, CRC?

    (d) Waiting for your go for the procs, then I put everything in conf control, generate the command sequences and send the DB back to you.

    (e) For the IGST, we'll need to have values for the FPs if different than the def ones in the procedures.
    Can you provide those via the timeline too?

    Regards,
    Sylvain

  12. Antonio Vecchio

    16/03/2018 ROC to S. Lodiot

    Dear Sylvain,


    (a) For 032 C and E I have not updated the TM checks as I assume we'll revert the command parameter values for flight. I have just added a comment.

    ROC : Good idea. As long as we don't use those parameters during tests, it should be ok

    (b) for the timeline duration you are very optimistic! We'll be running everything manually so it will take longer!
    We should have a slot of about 2h (5 instruments/day) TBC.

    ROC: You are perfectly right. The 3-4 min are only the times of the execution of TCs only. 2h seems good to have time.

    (c) For patch we're after something much simpler; dumping some address, if possible patching it, CRC?

    ROC : ok, in order to patch something we add a new sequence 261A. It is attached to this email. Can you add it to your sequences? I also add some lines in the timeline to test this patch (sse version 1.4 attached to this email).


    (d) Waiting for your go for the procs, then I put everything in conf control, generate the command sequences and send the DB back to you.

    ROC: We changed the HK configuration in the 32A: to this purpose, could you please remove the lines 39-40 of YOUR sequence 32A. We do not configure IIT_HK anymore.

    (e) For the IGST, we'll need to have values for the FPs if different than the def ones in the procedures.
    Can you provide those via the timeline too?

    ROC : For the IGST, we planned to use the default value for each FP. So we don't need to give you any value. Is it ok?

    We have one question: in the SSS, it's written :

    and in FOPPP : FCP 230 - 239: Service 3 Management (HK).

    Does that mean that the actual procedure 32 should be actually 230?

  13. Antonio Vecchio

    16/03/2018: S. Lodiot to ROC

    1) Your 261 input does not work straight.
    The TC par values you mention are not eng but hex; PIW00009 is 8 bits, you provide a value of 4 octets, so we need a group repeater of 4 (the group repeater for the number of bytes to patch is missing in your input, this is PIW00008, but there in your input I think you provide the actual patch).
    PIW00009 should be there 4 times I believe with the data to load.
    Have a look at the modified proc and let me know if this is what you are actually after!
    I have also added a dump TC before and after so we can check the effect of the patch. Is this OK?
    Is the TM packet check OK?
    Will you be using CRC checks with RPW? If yes can we add a CRC check too?

    (2) 032 proc updated is attached.
    It does much more than HK (this is a configuration proc) so need to change its name!

    (3) Fine for FPs!

    (4) I'll start to put the procs in conf control. (It does not mean we can't change them later on)!

  14. Antonio Vecchio

    16/03/2018 ROC to S. Lodiot

    > (1) Your 261 input does not work straight.
    > The TC par values you mention are not eng but hex; PIW00009 is 8 bits, you
    > provide a value of 4 octets, so we need a group repeater of 4 (the group
    > repeater for the number of bytes to patch is missing in your input, this
    > is PIW00008, but there in your input I think you provide the actual > patch).
    > PIW00009 should be there 4 times I believe with the data to load.
    > Have a look at the modified proc and let me know if this is what you are
    > actually after!
    > I have also added a dump TC before and after so we can check the effect of
    > the patch. Is this OK?

    You are right. All your modifications are ok for us. After a discussion with the flight software team here at LESIA we decided to change the address of the memory area to 0x40100000 . Please update it in the proc. 261 (PIW00007)

    > Is the TM packet check OK?
    Ok

  15. Antonio Vecchio

    16/03/2018: S. Lodiot to ROC

    All procs except 261 are under conf control.
    Attached are the pdfs, this is what we will be using during IGST 4_2.

    If you spot any problem, let me know and we fix.

    Command sequences are generated; as soon as they are fed back in the database, I'll pass it on to you.
    What do you prefer? ASCII files? mdb database?

    Dear All,

    An other question from me.
    Project and ADS have asked us to systematically check for IGST 4_2 with all instruments the following 2 points:


    (1) ESA/ESOC to contact instruments on any special preparation and/or configuration needed for their payloads for IGST4.

    (2) ESA/ESOC to check with each Instrument team on command parameters (or a combination of them) which should not be used with the EM unit (in order not to endanger the EM unit)

    I believe not.
    Commands not allowed are clearly highlighted in the procedures we will follow step by step.
    I'm not aware of anything else, can you please confirm?

    Thank you,

    Regards,
    Sylvain

  16. Antonio Vecchio

    21/03/2016 S. Lodiot to ROC

    Dear Antonio,

    (1) for the CRC, not really. This has purely to do with patch and dump operations.
    Some teams/SW verify proper patching via dumps, some via checksum requests only, some via both mechanisms.

    In the IGST 4_2 patch/dump procedure, we currently only have dumps. If RPW will use the CRC way to verify proper patching in flight, we should complement that procedure with a CRC request.

    (2) I'll send you mdb and ASCII files then. Likely early next week.

    (3) Question to the timeline:

    Before the patch, RPW mode is changed from Standby to Service.
    Then a patch and a dump operaiton is done
    Then we change from Standby to Safe in preparation for switch off.
    But we are in Service (not in Standby)
    You use procedure 046 which in your state model says:
    (ROC-OPS-OTH-NTT-00056-LES issue 1.1).

    I believe there is no issue and this is just a typo in the timeline (should say service not standby), because we have done a clean switch off of the equipment with the previous transition to standby.

    Can you confirm?

    Thank you,

    Regards,
    Sylvain

    ps and FYI IGST 4_2 will be on 3 days not 2 (15 to 17 May); we'll get back to you ASAP for your exact slot.

  17. Antonio Vecchio

    ROC to S. Lodiot

    Ciao Sylvain,

    (1) for the CRC, not really. This has purely to do with patch and dump operations.
    Some teams/SW verify proper patching via dumps, some via checksum requests only, some via both mechanisms. In the IGST 4_2 patch/dump procedure, we currently only have dumps. If RPW will use the CRC way to verify proper patching in flight, we should complement that procedure with a CRC request.

    ROC: Ok, let me check this with the CNES team. I will answer you ASAP.
    (2) I'll send you mdb and ASCII files then. Likely early next week.
    ROC:Perfect. Thanks.

    (3) Question to the timeline:
    Before the patch, RPW mode is changed from Standby to Service.
    Then a patch and a dump operaiton is done
    Then we change from Standby to Safe in preparation for switch off.
    But we are in Service (not in Standby)
    You use procedure 046 which in your state model says:
    (ROC-OPS-OTH-NTT-00056-LES issue 1.1).
    I believe there is no issue and this is just a typo in the timeline (should say service not standby), because we have done a clean switch off of the equipment with the previous transition to standby.

    ROC: Yes you are right. There is no issue but just a typo.
    Third column of line 126 in IGST4_2_plan_rpw_V1.4 is SERVICE instead of STANDBY.

    Ragards

    Antonio