Redmine: Issueshttps://hephaistos.lpp.polytechnique.fr/redmine/https://hephaistos.lpp.polytechnique.fr/redmine/redmine/favicon.ico?15080976012023-02-13T10:10:15ZRedmine
Redmine LFR-FSW - Task #4026 (Closed): Analyse GCOVhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/40262023-02-13T10:10:15ZVeronique bouzid
<p><strong>Début de la couverture de Test en 3.3.0.16</strong></p>
<p>Une quinzaine de tests ont été joués. Avant de pousser plus loin, il faudrait traiter ses tests et évaluer la couverture atteinte.</p>
<p>Sur pc-solar3, dans le répertoire /opt/VALIDATION_R3.3/GCOV/3.3.0.16, voici les fichiers à traiter:</p>
<p>gcov_out_2023-02-13 09:10:52.635355.txt<br />gcov_out_2023-02-13 09:12:32.358845.txt<br />gcov_out_2023-02-13 09:15:53.533775.txt<br />gcov_out_2023-02-13 09:17:58.219268.txt<br />gcov_out_2023-02-13 09:23:23.893858.txt<br />gcov_out_2023-02-13 09:33:27.972367.txt<br />gcov_out_2023-02-13 09:37:47.458757.txt<br />gcov_out_2023-02-13 09:39:33.827127.txt<br />gcov_out_2023-02-13 09:41:52.977440.txt<br />gcov_out_2023-02-13 10:23:51.069120.txt (SVS-0002 à SVS-0010 + SVS-0059)</p> LFR-FSW - Bug #4015 (Closed): HK_LFR_ME_CNT ne s'incremente pas lors du passage à zero du compteu...https://hephaistos.lpp.polytechnique.fr/redmine/issues/40152023-01-24T11:00:35ZVeronique bouzid
<p>Le test SVS-0026 doit vérifier le requirement suivant<br />All the counters (error counter, packet counter, etc) managed by LFR FSW shall restart at 0 when tehy reached their maximun value.</p>
<p>Le script qui teste le compteur HK_LFR_DPU_SPW_RX_TOO_BIG envoie 257 Tc générant une erreur. Le compteur valide bien le requirement et on voit parfaitement le passage à zero.</p>
<p>Un autre compteur nommé HK_LFR_ME_CNT comptabilise les erreurs de type medium. HK_LFR_DPU_SPW_RX_TOO_BIG fait partie de ce type d erreur et donc on s'attend à la fin du test à obtenir<br />HK_LFR_ME_CNT=257. Ce n est pas le cas il manque 1.</p>
<p>Ici un extrait des valeurs de ces 2 compteurs (fichir verif_count.txt)<br />11:47:45.222921 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=0 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />11:47:46.242728 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:47.222395 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:48.223832 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:49.222892 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=1 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />11:47:50.223058 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=2 HK_LFR_DPU_SPW_RX_TOO_BIG=2<br />----</p>
<p>12:04:48.226406 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=255<br />12:04:49.225973 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0</strong><br />12:04:50.225914 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:51.226438 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:52.225955 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=255 HK_LFR_DPU_SPW_RX_TOO_BIG=0<br />12:04:53.225879 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:54.22646 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:55.225976 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:56.225969 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:57.22624 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:58.226003 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:04:59.226005 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:00.226468 HK_LFR_LE_CNT=1 HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1<br />12:05:01.226032 HK_LFR_LE_CNT=1 <strong>HK_LFR_ME_CNT=256 HK_LFR_DPU_SPW_RX_TOO_BIG=1</strong></p>
<p>On voit la parfaite égalité des 2 compteurs excepté après le wrap de HK_LFR_DPU_SPW_RX_TOO_BIG.<br />Le script joué se nomme /opt/VALIDATION_R3.3/lfrverif/LFR_SVS/SVS-0026/check_rx_too_big_cnt_wrap.py et les fichiers de test sont dans<br />/home/validation/data/R3.3/3.3.0.11/1.1.91/SVS-0026/TESTS/check_rx_too_big_cnt_wrap</p>
<p>Contexte du test<br />---------------------<br />FSW 3.3.0.11<br />VHDL 1.1.91<br />EM1 sans Timegen<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />StarDundee</p>
<p><strong>ATTENTION<br />Il se peut que ce bug soit applicable également à la gestion du compteur d'erreur HK_LFR_LE_CNT.</strong></p> LFR-FSW - Task #3171 (Closed): GCOV pour TEST-TYPEhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31712018-10-30T15:41:01ZVeronique bouzid
<p>Peux-tu m extraire la couverture de test en 3.2.0.22.</p>
<p>Les fichiers sont rangés dans data/R3++/3.2.0.22/1.1.91/GCOV/TEST-TYPE</p> LFR-FSW - Task #3166 (Closed): GCOV pour SVS-0003https://hephaistos.lpp.polytechnique.fr/redmine/issues/31662018-10-29T14:58:38ZVeronique bouzid
<p>Le CRC comprend 2 octets, le test ne changé que le dernier octet du CRC.</p>
<p>J ai donc rajouté le test pour le 1er octet du CRC</p>
<p>Les fichiers de tests (2018_10_29-15_50_08*) sont rangés dans /home/validation/data/R3++/3.2.0.22/1.1.91/GCOV/SVS-0003</p> LFR-FSW - Task #3165 (Closed): GCOV pour test SUB-TYPE vs LONGUEURhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/31652018-10-29T12:35:24ZVeronique bouzid
<p>Analyse GCOV du test décrit ci-dessous.</p>
<p>Ce test se nomme /opt/VALIDATION_R3plusplus/lfrverif/LFR_SVS/SVS-0003/send_bad_length_vs_subtype.py.<br />Il envoie un TC_LFR_DISABLE_CALIBRATION qui a une longueur de 14 octets au lieu de 12.<br />Cette TC sera refusée lors de la phase d'acceptance suite à la comparaison de longueur attendue pour le sub-type = 63.</p>
<p>En réponse à cette TC, on aura une TM_LFR_TC_EXE_CORRUPTED avec les champs suivants</p>
<p>PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=63, <br />PA_RPW_PKT_LEN_RCV_VALUE=7, PA_RPW_PKT_DATFIELDSIZE_CNT=7, <br />PA_RPW_RCV_CRC=0x8f8c, PA_RPW_COMPUTED_CRC=0x8f8c</p>
<p>Le resultat du test se trouve dans /home/validation/data/R3++/3.2.0.22/1.1.91/GCOV/TEST-NEW.</p> LFR-FSW - Support #1091 (Feedback): Lost some BP packets in BURST modehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10912017-04-27T09:51:05ZVeronique bouzid
<p>1 test "CAS NOMINAL" <br />on entre en burst mode<br />17:34:51.300563, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />17:34:52.481738, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f503ffff<br />17:34:52.537164, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f504000a</p>
<p>17:34:53.482246, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5050000<br />17:34:53.537797, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f505000a</p>
<p>17:34:54.482316, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5060000<br />17:34:54.537483, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f506000a</p>
<p>17:34:55.481104, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x27b7f5070000<br />17:34:55.534692, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x27b7f507000b</p>
<p>17:34:56.486681, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x44a32a03c608<br />17:34:56.489927, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x44a32a03c608</p>
<p>17:34:56.527804, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />17:34:56.548004, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x44a32a03c612<br />17:34:56.587099, TM_LFR_SCIENCE_BURST_BP2_F1, TIME=0x44a32a03c612<br />17:34:56.587799, TM_LFR_TC_EXE_SUCCESS, TIME=0x44a32a04efa2</p>
<p>17:34:56.920005, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x44a32a050001</p>
<p>Ce cas est nominal. On recoit bien tous les produits BURST meme apres le passage en SBM1.<br />5 BURST_BP1_F0<br />5 BURST_BP1_F1<br />1 BURST_BP2_F0<br />1 BURST_BP2_F1</p>
<p>-Le meme test rejoué " ERREUR" <br />16:27:43.862845, TC_LFR_ENTER_MODE (CP_LFR_MODE=2)<br />16:27:43.871156, TM_LFR_TC_EXE_SUCCESS, TIME=0x318b8203e9a3</p>
<p>16:27:45.049608, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82040001<br />16:27:45.105166, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8204000b</p>
<p>16:27:46.050847, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82050001<br />16:27:46.106364, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8205000b</p>
<p>16:27:47.049695, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82060001<br />16:27:47.104954, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8206000c</p>
<p>16:27:48.049311, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x318b82070001<br />16:27:48.103473, TM_LFR_SCIENCE_BURST_BP1_F1, TIME=0x318b8207000c</p>
<p>16:27:49.055988, TM_LFR_SCIENCE_BURST_BP1_F0, TIME=0x3d633003c8cd<br />16:27:49.058668, TM_LFR_SCIENCE_BURST_BP2_F0, TIME=0x3d633003c8cd</p>
<p>16:27:49.084134, TC_LFR_ENTER_MODE (CP_LFR_MODE=3)<br />16:27:49.094502, TM_LFR_TC_EXE_SUCCESS, TIME=0x3d633004ebbe<br />16:27:49.476704, TM_LFR_SCIENCE_SBM1_BP1_F0, TIME=0x3d6330050000</p>
<p>--> la il nous manque BURST_BP1_F1 et un BURST_BP2_F1 un on a seulement recu<br />5 BURST_BP1_F0<br />4 BURST_BP1_F1<br />1 BURST_BP2_F0</p>
<p>Ma piste s oriente vers le changement de mode qui resette les buffers alors parfois les produits burst sont deja dabns la file d attente pour envoi et parfois<br />non</p>
<p>--> Peux-tu expliquer ?</p>
<p>J ai rencontré plusieurs ce petit dysfonctionnement souvent sur le burst mais egalement sur les NORMAL_BP NORMAL_ASM et sur les BP en SBM2.</p>
<p>Je ne classe pas cette issue en BUG car je pense que c'est le comportement de LFR et qu il faut juste documenter ce point.</p>
<p>Contexte du test<br />----------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Support #1090 (Feedback): Back to time managementhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/10902017-04-27T07:43:37ZVeronique bouzid
<p>Premier cas de test<br />- LFR a booté, <br />Le soft remonte bien que le timecode est missing et la derniere erreur tracée est coherente avec cela<br />HK_LFR_UPDATE_TIME_TC_CNT=0, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, , HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>- Envoi d'une TC_LFR_UPDATE_TIME avec 300ms apres une timecode invalid ( je mets 5)<br />TC_LFR_UPDATE_TIME, CCSDS_VERSION, CP_RPW_TIME=0x38f223010000</p>
<p>sur la TM_LFR_HK<br />HK_LFR_UPDATE_TIME_TC_CNT=1, HK_LFR_LE_CNT=1, HK_LFR_ME_CNT=0, HK_LFR_HE_CNT=0, HK_LFR_LAST_ER_RID: LE_LFR_TIMEC = 42129, HK_LFR_LAST_ER_CODE: MISSING = 21, HK_LFR_LAST_ER_TIME=0x8000000209dd, HK_LFR_DPU_SPW_TICK_OUT_CNT=0, HK_LFR_DPU_SPW_LAST_TIMC=0, HK_LFR_TIMECODE_ERRONEOUS=0, HK_LFR_TIMECODE_MISSING=1, HK_LFR_TIMECODE_INVALID=0, HK_LFR_TIME_TIMECODE_IT=0, HK_LFR_TIME_NOT_SYNCHRO=0, HK_LFR_TIME_TIMECODE_CTR=0,</p>
<p>--> Le soft ne remonte aucune erreur et donc la derniere erreur tracée est toujours missing.</p>
<p>--> Peux-tu expliquer CELA</p>
<p>Contexte du test<br />---------------------<br />FSW 3.2.0.15<br />VHDL 3.1.91<br />SocExplorerEngine.getSocExplorer: Version = 0.7.0, Branch = default, Changeset = c459540a6dbdcbb4e17f204685fce02c070ba971+<br />EQM sans Timegen<br />StarDundee</p> LFR-FSW - Task #1067 (Closed): Preparation Datapack R3++https://hephaistos.lpp.polytechnique.fr/redmine/issues/10672017-04-20T08:30:18ZVeronique bouzid
<p>Voici le bilan des documents à fournir envoyé par William.</p>
<p>Ci-joint le document, j'ai noté dans toutes les colonnes les issues JIRA encore notées "Opened" ou notées "reopened" pour ne pas les oublier.</p>
<p>Il est possible que vous ayez plus de documents à produire que ceux que j'ai noté car je suis reparti de la liste R3 pour faire l'état => e.g. si vous avez créé de nouveaux documents produits, ils ne sont pas dans la liste que j'envoie.<br />De mon côté je suis en train de dépouiller l'analyse Logiscope et j'espère vous faire un retour pour vendredi.</p> LFR-FSW - Feature #593 (In Progress): adapter tm_lfr_period.py au fonctionnement des modeshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/5932016-01-26T08:29:15ZVeronique bouzid
<p>Le normal mode ne s'interrompant plus quand on commute vers sbm1 et sbm2, il faut modifier <br />la fonction tm_lfr_period.py qui testait le timing en fonction du mode actif.</p>
<p>Maintenant la prise en compte des TM_LFR_SCIENCE_NORMAL* doit etre global pour vérifier la continuté des timing.</p> SocExplorer - Bug #498 (New): Timecode + timegen en mode router non fonctionnelshttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4982015-09-18T11:35:50ZVeronique bouzid
<p>Timecode:<br />Revoir la fonction SendOneTimecode</p>
<p>Timegen:<br />la procedure manuelle d'utilisation de Timegen fonctionne.<br />Investiger pourquoi en automatique le mode router ne fonctionne pas.</p> SocExplorer - Feature #497 (In Progress): Ajouter une fonction retournant l'etat du cachehttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4972015-09-18T11:19:35ZVeronique bouzidLFR-FSW - Support #494 (Feedback): Gestion timecode https://hephaistos.lpp.polytechnique.fr/redmine/issues/4942015-09-11T10:33:03ZVeronique bouzid
<p>J'ai travaillé sur la gestion manuelle de l'envoi de timecode.<br />Pour cela on utilise la fonction SpwPlugin0.StarDundeeSendOneTimecode. Parfois, il faut envoyer 2 timecodes de suite pour que la commande<br />TC_LFR_UPDATE_TIME soit prise en compte, parfois un seul suffit. L'effet de bord est que si les 2 timecodes sont pris en compte, le temps interne de LFR est positionné au temps contenu<br />dans la TC_LFR_UPDATE_TIME + 1s. Donc cela n'etait pas concluant.<br />En effet, la TC_LFR_UPDATE_TIME se traduit par l'ecriture du temps dans le registre COARSE TIME LOAD et l'arrivée du timecode va ecrire ce registre dans le registre COARSE TIME. La reception du 2eme<br />timecode lui, incrementera de 1 ce temps.</p>
<p>--> Conclusion ce n'est pas ce que l'on veut.</p>
<p>En fait je me suis rendue compte que si je resette la carte LFR, je relance le test avec le couple TC_LFR_UPDATE_TIME + 1 timecode = 1, cela<br />fonctionne systématiquement.</p>
<p>Ma conclusion est donc que la remise à zero du timecode géré par le spw n'est effectuée que sur le reset et que meme si je ferme socexplorer<br />je conserve la valeur du dernier timecode que j ai envoyé.</p>
<p>Pour valider cette conclusion, j'ai lu la doc grlib.pdf de Gaisler et j'ai été aidé par Alexis.</p>
<p>J'ai donc écrit un petit script qui lit le registre nommé Time register (0x800000514) dans l'onglet GRSPW et qui contient sur 8 bits <br />- Time control flags (TCTRL) = 2 bits = b7 et b6<br />- Time counter (TIMECNT) = 6 bits = b5 à b0<br />Attention, cela correspond à la valeur du dernier timecode valide et non le nbre de timecode valides. Ce registre n'est accessible qu'en lecture et il est à l'adresse<br />0x800000514</p>
<p>Pour le lire, j ai utilisé la fonction SpwPlugin0.Read <br />et ma théorie s'est vérifiée, quand on sort de socexplorer , il y a conservation de ce registre.</p>
<p>Conclusion, avant d'envoyer un time code,<br />1- il faut lire la valeur contenue dans 0x800000514<br />2- incrementer cette valeur et l envoyer avec SpwPlugin0.StarDundeeSendOneTimecode</p>
<p>Voici donc la séquence à mettre<br />Lecture du timer counter<br />loc_time = SpwPlugin0.Read(0x80000514, 1)<br />timec = loc_time<sup><a href="#fn0">0</a></sup> & 0xff<br />print hex(timec)</p>
<p>timecode=int(timec)+2<br />print timecode<br />SpwPlugin0.StarDundeeSendOneTimecode (timecode)</p>
<p>Remarque<br />--------<br />Comme on ne s interesse pas aux 2 bits de controles, <strong>le masque devrait etre 3f au lieu de ff.</strong><br />En effet les timecodes sont modulo 64.<br />Je l'ai egalement vérifié si j'ecris SpwPlugin0.StarDundeeSendOneTimecode (255) et que je lis le registre, j obtiens en binaire 00111111 soit 3f<br />soit 63.</p>
<p>Autre test, j ai envoyé la sequence suivante<br />py > SpwPlugin0.StarDundeeSendOneTimecode (6)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (254)<br />py > SpwPlugin0.StarDundeeSendOneTimecode (255)</p>
<p>--> le registre ne s'est mis à jour que lors de l'envoi de 255 , car 6 n'etait pas valide, 254 pas valide<br />mais 255 oui car increment de 1/ à la valeur précédente.</p>
<p>Voila ma conclusion. <br />Par contre, on voit bien que 254 a été conservé puisque 255 a été validé, mais je ne sais pas ou ???</p> LFR-FSW - Task #492 (New): Implementation Timing LFRhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4922015-09-10T12:32:30ZVeronique bouzid
<p>Ces informations sont extraites du document RPW-SYS-SSS-00013-LES_Issue3_rev3_Software_System_Specification_bars.pdf</p>
<p>1- Liste des requirements liés au Timing (section Time management 4.1.4)</p>
<p>SSS-CP-FS-340 REQ-LFR-SRS-5300 SVS-0020<br />SSS-CP-FS-350 REQ-LFR-SRS-5217 Design<br />SSS-CP-FS-360 REQ-LFR-SRS-5218 SVS-0011<br />SSS-CP-FS-370 REQ-LFR-SRS-5219 SVS-0012<br />SSS-CP-FS-376 REQ-LFR-SRS-5237 noté Design mais on a un test<br />SSS-CP-FS-380 REQ-LFR-SRS-5220 SVS-0013<br />SSS-CP-FS-390 REQ-LFR-SRS-5301 Design<br />SSS-CP-FS-400 REQ-LFR-SRS-5221 Design<br />SSS-CP-FS-405 REQ-LFR-SRS-5238 SVS-0014<br />SSS-CP-FS-410 REQ-LFR-SRS-5222 SVS-0076</p>
<p>Résumé de ma compréhension du timing LFR</p>
<p>le développement du software est axé principalement sur le fonctionnement nominal :<br />- toutes les secondes, LFR recoit du DAS le couple suivant<br /> - une commande TC_LFR_UPDATE_TIME ( CTR Time Update command ou bien CTR SpaceWire command packet)<br /> - 300ms aprés un timecode valide (SpaceWire time code)</p> LFR-FSW - Support #486 (Feedback): SSS-CP-FS-340 : Design or Testhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/4862015-08-18T06:46:10ZVeronique bouzid
<p>Hello,<br />Je m'interroge sur ce requirement<br />SSS-CP-FS-340<br />The RPW Flight Software shall maintain a local time with:<br />− a resolution of at least SY_RPW_TIME_RESOLUTION = 1 ms and a relative accuracy of<br /> SY_RPW_TIME_ACCURACY = 500 μs for the DAS and the three analyzers.<br />− a resolution of at least SY_DPU_DBS_TIME_RESOLUTION = 10 ms and a relative<br /> accuracy of SY_DPU_DBS_TIME_ACCURACY = 1 ms for the DBS.</p>
<p>Il est associé dans la SRS à REQ-LFR-SRS-5300_Ed2.<br />Dans notre fichier SSS-SRS-SVS-compliance_matrix_LFR_V2-1.2.xlsx , il apparait comme un test SVS-0020. Le script associé <br />est time_resolution.py (ce qui ne correspond pas à ce qui est ecrit dans le fichier ). Le nom est internal_time_consistent.py,<br />qui est un script de dépouillement.</p>
<p>Ma question est la suivante, <br />Je ne vois pas comment vérifier ce requirement et pour moi, c'est un test de Design.</p>
<p>J ai assigné ce point à Paul et mis Bruno en observateur ainsi que moi.</p> LFR-FSW - Task #398 (New): Utilisez le script periodicity.py sur les tests de Geraldhttps://hephaistos.lpp.polytechnique.fr/redmine/issues/3982015-04-27T13:32:54ZVeronique bouzid
<p>Il serait bien d'utiliser le script periodicity.py que Bruno a développé<br />pour dépouiller les tests de charge (analyse des fichiers de type *_packet_log.data, format ecrit par Paul).</p>
<p>Le script de Gerald verif_fields.py gere un fichier tm_time.txt dont le format<br />n'est pas trop éloigné de celui de Paul.</p>
<p>Il faudrait transformer le format<br />07:57:08.364223, TM_LFR_SCIENCE_NORMAL_BP1_F2, TIME=0x0000001133f7</p>
<p>en<br />2015 3 25 16:22:00:360 TM_LFR_SCIENCE_SBM1_BP1_F0 time = 0x 80000020 5bd2</p>
<p>J ai donc commencé par <br />1- Recuperer la date du fichier à traiter pour l'ecrire dans le fichier (verif_fields.py) + passage de l argument<br />2- reformatter les infos comme il faut (supprimer les micros secondes, parser le temps...)<br />3- creer un fichier resultat avec la nomemclature <strong><em>packet_log.data et qui ne contient que les TM</em></strong></p>