Task #3944
closed
Modif de la TC_LOAD_KCOEFF : ICD + LFR FSW
0%
Description
Suite à la teleconf du 29/03/22, proposition au LESIA :
Salut à tous!
Comme discuté durant la teleconf, j'ai préparé un draft avec les nouveaux labels pour la TM_KCOEFF_DUMP.
Du coup, on avait aussi dit qu'on mettait les labels à jour pour la TC correspondante tant qu'à faire pour être symétrique avec ceux de la TM.
Pour rappel : dans l'implémentation actuelle le tableau complet de KCOEFF c'est 36 groupes de 32 floats. Thomas envoie un tableau 36 lignes x 32 colonnes à Diane qui construit les 36 TC afférentes.
Pour la nouvelle implémentation, afin de ne pas toucher à la TC, Thomas et Alexis utilisent pour la TC certains des floats à des fins différentes en fonction du paramètre KCOEFF frequency. C'est un arrangement un peu complexe mais qui permettait de conserver toute la partie TC identique.
Pas évident donc d'harmoniser les labels de ces champs qui sont soit utilisés soit SPARE.
Par contre, la teleconf de mardi nous a apporté un nouvel éclairage côté contrainte IDB qui est de mettre des champs en SPARE afin de conserver la structure et ne pas modifier l'IDB (ce que l'on va faire pour la TM).
En faisant cela pour la TC actuelle, on pourrait réarranger le placement de nos floats afin de le simplifier sans toucher à l'IDB.
Cela implique :
- Côté LPP : une modif du FSW de LFR (qui va simplifier le traitement de la TC)
- Côté LESIA : Diane devrait générer 39 TC au lieu de 36 TC (Thomas lui enverrait un tableau 39x32 au lieu de 36x32)
Hormis la contrainte opérationnelle, pouvez-vous aussi nous confirmer que cela est possible côté DPU? Les TC à exécuter sont-elles stockées à bord ? Y aurait-il la place pour 3 TC de plus?
Si c'est bon pour vous on part là dessus sinon on laissera nos labels génériques tout moches.
Merci d'avance de votre aide
Bruno
Files
Related issues
Updated by bruno katra over 2 years ago
- Related to Feature #3905: La TM_KCOEFF_DUMP n'a plus la structure dédcrite dans l'ICD added
Updated by bruno katra over 2 years ago
- Status changed from New to In Progress
- Assignee set to bruno katra
Réponse Thomas et Philippe Plasson : cas déjà étudié en octobre 2021, pas possible de passer à 39 TC sans impact sur IDB et FSW DPU...
On se limitera donc à un changement de label pour essayer de garder un peu de cohérence entre TM et TC. Le KCOEFF_FREQUENCY de la TC (devenu BIN_INDEX dans la TM) ne change pas non plus, il reste un entier de 0 à 35 car pas pertinent de le passer en index des BIN puisque certaines TC contiennent les valeurs de plusieurs BIN + Leeroy dit que cela impliquera un changement d'IDB...
Updated by bruno katra almost 2 years ago
- File [RID-875] Mise à jour relative à la MAJ LFR.pdf [RID-875] Mise à jour relative à la MAJ LFR.pdf added
Mail Leeroy 8/12/2022
Bonjour à tous,
Diane, pas de soucis pour produire les TC de chargement d'ici le 27 si le logiciel est livré le 20.
Pour ce qui est des modifications de l'IDB, vous pouvez confirmer que ça porte au final uniquement sur les points que listé dans l'issues RID-875 dont l'export est en pièce jointe ?
LeeRoy
Updated by bruno katra almost 2 years ago
- Assignee changed from bruno katra to Alexis Jeandet
Je suis en train de répondre à Leeroy, ils se sont carrément emmêlé les pinceaux dans le point JIRA. Ce qui est même bizzare c'est qu'ils parlent de faire des modifs sur les champs de la TC alors qui'ls nous avaient dit que c'était impossible... Bref...
Juste une question : j'ai demandé la modif du min/max du champs de la TM_KCOEFF_DUMP suivant :
KCOEFF_FREQ devient KCOEFF_BIN_INDEX avec un min/max de 1/128 mais j'ai l'impression que le FSW numérote à partir de 0 donc ce serait plutôt 0/127 :
@AlexisJ : tu confirmes?
Merci d'avance
Bruno
Updated by Alexis Jeandet almost 2 years ago
bruno katra wrote in #note-4:
Je suis en train de répondre à Leeroy, ils se sont carrément emmêlé les pinceaux dans le point JIRA. Ce qui est même bizzare c'est qu'ils parlent de faire des modifs sur les champs de la TC alors qui'ls nous avaient dit que c'était impossible... Bref...
Juste une question : j'ai demandé la modif du min/max du champs de la TM_KCOEFF_DUMP suivant :
KCOEFF_FREQ devient KCOEFF_BIN_INDEX avec un min/max de 1/128 mais j'ai l'impression que le FSW numérote à partir de 0 donc ce serait plutôt 0/127 :
@AlexisJ : tu confirmes?
Merci d'avance
Bruno
Hello,
Je confirme que ça part de 0:
https://github.com/LaboratoryOfPlasmaPhysics/LFR_Flight_Software/blob/R3.3/src/tc_tm/tc_load_dump_parameters.c#L555-L558
Updated by bruno katra almost 2 years ago
Finalement après 10 mois de discussions, le LESIA rejette toutes les demandes de modifs (telecon 13/01/2023), voir mail ci-dessous :
Salut à tous, nous avons une petite teleconf rapide avec LeeRoy et Philippe cet aprem pour refaire le point suite à mon mail ci-dessous.
Concernant le changement des labels prévus niveau TM, Philippe estime après réflexion que cela est trop risqué en terme de régression IDB comparé au gain d'information, il est vrai léger, que ces changements apporteraient. Il préconise plutôt qu'on laisse comme c'est et que l'on fasse un tableau explicite de correspondances 'labels IDB' <-> 'nouveaux labels/fonctions' dans le SUM. Du coup on ne touche aucun label.
Pour la valeur min/max du champs TM KCOEFF_FREQ, le risque est moins élevé mais comme il y a un flou si cette valeur est utilisée en aval (ROC, ESA, ...), il y a toujours un risque de régression. Alexis et moi avons proposé comme solution alternative de recompiler le logiciel de vol LFR en cours de validation pour remettre des valeurs qui sont dans l'intervalle actuel donc sans modifs IDB. Philippe et LeeRoy nous ont laissé évalué si cela était acceptable (car cela entraine une nouvelle version du FSW) ou si ils tentaient la mise à jour IDB.
Après discussions avec Alexis : on opte pour la recompilation du FSW LFR avec des valeurs qui sont valides avec le min/max actuel de l'IDB. On prend la responsabilité de ne pas recommencer la campagne de tests intégralement car la modif est plus que minime : on remplace la variable KCOEFF_FREQ (UINT_16) actuelle qui oscille entre 0 et 127 par : constante '0' pour les matrices de passage F0, constante '1' pour les matrices de passage F1,constante '2' pour les matrices de passage F2. Je rejouerai quand même les tests spécifiques sur les KCOEFF puisque c'est la seule portion du code qui est touchée.
Diane et Xavier : pour ce qui est de la livraison prévue le 20/01, nous avons pris du retard suite aux diverses grippes hivernales et à un problème de régression pas sur LFR mais sur le banc de test! (les machines vieillissent ) Le problème semble résolu depuis cette semaine et on a repris le rythme de croisière. Pour faire simple, à l'heure qu'il est et au chausse pied il est peut-être possible de livrer le 20/01 mais on ne peut plus le garantir. Quelles sont les options sans trop de contraintes pour vous ? Il me semble que l'ESA avait parlé d'une indisponibilité de leur côté courant février donc en gros si on ne livre pas le 20/01 on partirait pour fin février/début mars? Si vous souhaitez qu'on en discute de vive voix lundi ou mardi, n'hésitez pas.
Désolé de ce mail un peu long, beaucoup d'évènements ces quelques derniers jours!
Bon week-end à tous.
Bruno
Updated by bruno katra almost 2 years ago
- Status changed from In Progress to Closed