Project

General

Profile

Task #618

Long test with SBM1 and SBM2 FSW 3.0.0.20

Added by Veronique bouzid almost 6 years ago. Updated almost 6 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
SRS
Target version:
-
Start date:
11/02/2016
Due date:
% Done:

0%

Estimated time:
revision:
r0

Description

Description

le script joué est joint il se nomme test_mode_SBMx_12h.py
1 Les parametres utilisés sont ceux par défaut du normal mode. Le test s'est bien terminé.
2- 10mn de NORMAL
3- 6h de SBM1
4- 6h de SBM2
5- 10mn de NORMAL

Les fichiers (2016_02_10_17_15_12*) sont pc-instru/weekly erased /Thomas/run-2016-02-10-3.0.0.20-1.1.89.

Les fichiers (2016_02_10_17_15_12*)sont rangés également sur pc-faust9 répertoire/ home/validation/data/R3/3.0.0.20/TESTCHARGEsbm1+sbm2

Contexte du test
---------------------
FSW 3.0.0.20
VHDL 1.1.89
EM AVEC Timegen
SocExplorerEngine.getSocExplorer: Version = 0.6.2, Branch = default, Changeset = 819d0376d481
StarDundee


Related issues

Related to Task #614: 3.0.0.20Closed2016-02-09

Related to Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22Closed2016-02-12

Has duplicate Bug #616: Long test in SBM1 and SBM2 modesClosed2016-02-10

History

#1 Updated by Veronique bouzid almost 6 years ago

#2 Updated by bruno katra almost 6 years ago

  • Has duplicate Bug #616: Long test in SBM1 and SBM2 modes added

#3 Updated by thomas chust almost 6 years ago

1482
1483
1484
Résults de tests dans les fichiers joints:
  1. SWF: idem que pour #614 (logique de synchro semble maitrisée et amplitude des oscillations "forte" car dérive, ~T2, plus forte que dans le cas du test à 22s) ; dans l'immédiat je n'arrive pas à comprendre l'évolution des dérives/resynchro observée au vu de l'algo ; à suivre ...
  2. ASM: il y a un problème à la transition SBM1 vers SBM2, donc 7h après les 10 min de NM; les 7ièmes ASM_F1 et ASM_F2 disparaissent (pas de ASM au temps attendu, les suivants sont 3600s après) alors que le 7ème ASM_F0 est bien là mais avec 1s de retard
  3. ASM: les premiers ASM arrivent 1h10 après le passage en NM lorsqu'il y a eu une transition en SBM1 10 mn après le début du NM. On dirait que le passage en SBM1 a remis à 0 le timer pour la génération des ASM toutes les 3600s. Cela veut dire que le NORMAL DATAFLOW a été impacté par le chgt de mode donc non conformité avec l'exigence SSS-CP-EQS-326 (Upon reception of a TC_xxx_ENTER_MODE(SBM1) / TC_xxx_ENTER_MODE(SBM2) /
    TC_xxx_ENTER_MODE(NORMAL), the equipment flight software shall not re-initialize the
    NORMAL data flow if this one was already active.)
  4. CWF3: il y a un problème avec le premier buffer ou le deuxième; en effet le deuxième buffer est daté 168.99776s après le premier, donc ~1s de trop !? Paul, est-ce que cela peut avoir un lien avec la façon dont maintenant on démarre LFR avec une date donnée (+1s par défault si on indique 0)? Sinon ensuite la continuité temporelle est nominale (les sauts de temps entre chaque buffer peuvent s'expliquer par la dérive ...)
  5. CWF2: OK (continuité temporelle est nominale)
  6. CWF1: pas fait car fichier trop lourd ; je vais modifier mon code pour ne prendre que les headers; à suivre donc ...

#4 Updated by paul leroy almost 6 years ago

2.
Il faudrait consulter un log des paquets pour se faire une idée, notamment voir l'arrivée de la TC de changement de mode. Tu es peut-être sur un cas limite où la transition a été demandée entre le moment où on a émis les ASM_F0 et le moment où les autres, ASM_F1 et ASM_F2, devaient suivre?

3.
Pour les ASM, il me semble que je t'avais parlé de ça lors de ma venue. Je ne retrouve plus le dessin que j'avais fait pour expliquer la chose.
Les tâches concernant les ASMs (AVFx et PRCx) sont redémarrées à la demande de transition NORM <=> SBMx. Ca a peu d'influence sur l'arrivée des BPs, qui sont fournis souvent, mais beaucoup sur les ASM malheureusement. Et ça, je n'y toucherai que si c'est fondamental. A la limite, on pourrait émettre une matrice spectrale sans attendre 3600s, genre juste après avoir démarré, pour ne pas attendre trop longtemps.

#5 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to thomas chust

#6 Updated by bruno katra almost 6 years ago

  • Assignee changed from thomas chust to paul leroy

2.
Il faudrait consulter un log des paquets pour se faire une idée, notamment voir l'arrivée de la TC de changement de mode. Tu es peut-être sur un cas limite où la transition a été demandée entre le moment où on a émis les ASM_F0 et le moment où les autres, ASM_F1 et ASM_F2, devaient suivre?

Oui c'est possible mais un changement SBM1 vers SBM2 n'est pas censé perturber le NORMAL DATAFLOW.
paul: ça ne perturbe pas les snapshots, j'avais demandé à Thomas si on pouvait accepter une perturbation sur les ASM et BP

3.
Pour les ASM, il me semble que je t'avais parlé de ça lors de ma venue. Je ne retrouve plus le dessin que j'avais fait pour expliquer la chose.
Les tâches concernant les ASMs (AVFx et PRCx) sont redémarrées à la demande de transition NORM <=> SBMx. Ca a peu d'influence sur l'arrivée des BPs, qui sont fournis souvent, mais beaucoup sur les ASM malheureusement. Et ça, je n'y toucherai que si c'est fondamental. A la limite, on pourrait émettre une matrice spectrale sans attendre 3600s, genre juste après avoir démarré, pour ne pas attendre trop longtemps.
==> Ok, je ne savais pas mais Véro a l'air au courant. Cela fait que nous sommes POK sur ce requirement et qu'il faudra le renseigner dans SRS, SUM + une RFD pour William. Cela concerne t'il aussi les transitions SBM1<=>SBM2 (cf . point 2 ci dessus ) ?

paul: oui, c'est pareil pour SBM1 <=> SBM2

#7 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to bruno katra

#8 Updated by bruno katra almost 6 years ago

  • Category set to SRS
  • Assignee changed from bruno katra to paul leroy

Ok c'est noté pour point 2 et 3, ce sera renseigné dans la datapack.

Pour le point 4, aurais-tu une théorie?

#9 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to bruno katra

Pour le point 4, tel Eric et Ramzy à la grande époque "nous n'avons pas d'autre explication".

#10 Updated by Veronique bouzid almost 6 years ago

  • Description updated (diff)

#11 Updated by thomas chust almost 6 years ago

  • Assignee changed from bruno katra to paul leroy

Paul,
2.
OK pour que cela soit lié à un cas limite de transition qui tombe mal. Pour autant cela n'explique pas que le 7ième SWF_F0 soit daté de 1s en retard. Cela est peut-être l'indication d'un bug à venir ... Il n'y a pas urgence mais pour la R3+ et en rapport avec le 3. cela reviendra peut-être à l'ordre du jour.
3.
Dans l'immédiat ce n'est pas fondamental. Pour la R3+ il y aura l'occasion de reconsidérer la question car il s'agira de maitriser avec encore plus de détails le timing du calcul des ASM (virer les FFT sous-jacente qui sont poluées ...).

#12 Updated by Veronique bouzid almost 6 years ago

  • Subject changed from Long test with SBM1 and SBM2 to Long test with SBM1 and SBM2 FSW 3.0.0.20

#14 Updated by thomas chust almost 6 years ago

  • File deleted (tests_time_cwf_VHDL-1.1.89_FSW-3.0.0.20_2016_02_10_test)

#15 Updated by thomas chust almost 6 years ago

  • Related to Task #624: Long test with SBM1 and SBM2 FSW 3.0.0.22 added

#16 Updated by bruno katra almost 6 years ago

  • Status changed from New to Closed

Also available in: Atom PDF