Project

General

Profile

Bug #450

SSS-CP-EQS-526 non conforme par rapport à ICD >= 3.3

Added by Veronique bouzid over 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Category:
-
Target version:
-
Start date:
26/06/2015
Due date:
% Done:

100%

Estimated time:
revision:
r0

Description

Ici le texte de la SSS en 3.3
Each second, the LFR flight software shall put in its periodic HK packet (TM_LFR_HK) a mean of
the 16 last values of the electric field components sampled at f3: V_f3, E1_f3, E2_f3.

Paul confirme qu'il n a pas adapté ce requirement pour etre conforme à 3.3 mais qu'il respecte celui de 2.2

Le voici
Each second, the LFR flight software shall put in its periodic HK packet (TM_LFR_HK) the
last value of the electric field components sampled at f3: V_f3, E1_f3, E2_f3.

Paul, peux-tu expliquer comment tu determines la derniere valeur at f3 de V_f3, E1_f3, E2_f3?

History

#1 Updated by paul leroy over 6 years ago

  • Status changed from New to Feedback
  • Assignee changed from paul leroy to Veronique bouzid

L'implémentation actuelle est directement liée au VHDL. Jean-Christophe met à jour un registre en temps réel avec les valeurs des échantillons à f3. Lorsqu'un paquet HK est généré, la valeur contenue dans le registre est simplement lue et copiée dans le paquet. Pas de moyenne sur plusieurs échantillons. Faire des moyennes en continu sur les f3 demanderait trop de ressource.

#2 Updated by bruno katra about 6 years ago

  • Subject changed from SSS-CP-EQS-526 non conforme par rapport à 3.3 to SSS-CP-EQS-526 non conforme par rapport à ICD >= 3.3

Après discussion lors de la venue de Paul le 25/09, envoi d'un mail à P.Plasson :

Bonjour Philippe.
Je reviens vers toi concernant SSS-CP-EQS-526. Paul est venu au LPP vendredi
dernier pour faire le point et corriger le logiciel de vol. Nous avons donc
reparlé de ce requirement.
La position côté développement est confirmée : ce n'est pas trivial
actuellement à implémenter côté soft car directement lié au VHDL. Du coup,
quelle est la criticité de ce requirement? En cas de non conformité, y a
t-il un impact considérable sur la chaîne RPW?

Réponse Philippe :

C'est à Bernard et Emmanuel de répondre à cette question. Je les mets en copie.

Si Bernard et Emmanuel confirment que l'on peut faire sauter le
moyennage, je propose que l'on modifie la SSS pour éviter de se
traîner une non conformité.

A bientôt,

Philippe

#3 Updated by bruno katra about 6 years ago

ECHANGES Philippe Plasson / E. Guilhem du 29/09/2015 :

On va le traiter dans la NC, que l'on va clore en disant "use as is". Ne change rien.

-----Message d'origine-----
De : Philippe Plasson [mailto:]
Envoyé : mardi 29 septembre 2015 14:38
À : Guilhem Emmanuel (ALTRAN TECHNOLOGIES)
Cc : Bruno Katra; paul leroy; ; Veronique Bouzid; William Recart; Thomas Chust; Gaele Barbary; Vincent Leray; Pontet Bernard
Objet : Re: Non conformités FSW R3 LFR

Le 29 septembre 2015 14:34, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) <> a écrit :

Philippe,

Initialement, il était prévu de moyenner pendant 180s V_DC (SSS-CP-DAS-643) qui était lui-même la moyenne sur 4 secondes (SSS-CP-DAS-642) du potentiel S/C de LFR dans la HK qui est une moyenne sur 16pts de la mesure F3 (req LFR).
En l'état actuel de la R3 on moyenne pendant 180s V_DC (SSS-CP-DAS-643) la moyenne sur 4 secondes (SSS-CP-DAS-642) du potentiel S/C de LFR dans la HK qui est un échantillonnage de 1pt sur 16pts de la mesure F3 (modif LFR).
Et ce dans un mode dégradé où l'on ne peut pas communiquer avec SWA, (ce mode a tout de même des chances d'être utilisé...).

A priori il n'y a pas de quoi lancer une modif sur du VHDL pour ça.

En ce qui concerne les échanges avec SWA, on envoie toute les secondes la mesure du potentiel S/C de LFR contenu dans la HK, il faudra les informer que cette valeur n'est pas moyennée (ACTION CNES).

Du coup je vais fermer la NC.

Et alors finalement, est-ce que je modifie SSS-CP-EQS-526 ?

Philippe

Emmanuel

-----Message d'origine-----
De : Philippe Plasson [mailto:]
Envoyé : mardi 29 septembre 2015 12:16 À : Guilhem Emmanuel (ALTRAN
TECHNOLOGIES) Cc : Bruno Katra; paul leroy;
; Veronique Bouzid; William Recart;
Thomas Chust; Gaele Barbary; Vincent Leray; Pontet Bernard Objet : Re:
Non conformités FSW R3 LFR

Le 29 septembre 2015 11:58, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) <> a écrit :

Merci pour les documents,

Je suis désolé, je ne pense pas que nous puissions éviter de se traîner une non-conformité . Si le SBM1 se déclenche en permanence sur des faux évènements, on peut avoir une anomalie grave. Il y a sûrement plusieurs mitigations possibles autre que l'implémentation du moyennage (paramétrage de l'algorithme, masquage, moyenner dans le DPU...), et des tests à mener pour évaluer la sensibilité de cet algo en autocompatibilité et vis-à-vis des spécifications S/C (nous devions le tester en novembre suite à la réception de RPW_R3, nous allons le faire en portant notre attention sur ce problème).

OK, on ne touche pas à SSS-CP-EQS-526.
L'algorithme de détection SBM1 ne peut pas être sensible à ce problème car il est déjà basé sur une moyennage des données à bord (sur 180 secondes). Le potentiel S/C calculé à partir des F3 de LFR est utilisé, en mode dégradé, comme proxy de la densité de proton : tout l'algo SBM1 est basé sur une comparaison entre deux grosses moyennes de 180 secondes de données de la densité de proton, de B et de V.

Philippe

Pour bien gérer tout ça j'ai créé la NC 208.

Emmanuel

-----Message d'origine-----
De : Philippe Plasson [mailto:]
Envoyé : mardi 29 septembre 2015 11:26 À : Guilhem Emmanuel (ALTRAN
TECHNOLOGIES) Cc : Bruno Katra; paul leroy;
; Veronique Bouzid; William
Recart; Thomas Chust; Gaele Barbary; Vincent Leray; Pontet Bernard Objet : Re:
Non conformités FSW R3 LFR

Le 29 septembre 2015 11:18, Guilhem Emmanuel (ALTRAN TECHNOLOGIES) <> a écrit :

Bonjour,

Au niveau système, la génération du potentiel V de LFR est nécessaire pour les fonctions suivantes :
- Trigger du mode SBM1,
- Echange inter-instrument, le potentiel S/C est fourni à SWA
périodiquement toute les 4 secondes,

Si je comprends bien, dans la version R3 du LFR, la valeur de F3 fournie au DPU, est la dernière valeur mesurée lors de l'échantillonnage du snapshot F3, et non la moyenne de ce snapshot. A priori le potentiel S/C (Vx_DC à 16hz) ne devrait pas varier à l'échelle des besoins (4secondes(SWA), ou 300s(SBM1)). Néanmoins, nous avons vu lors des essais de compatibilité que des évènements transitoires provoqués par le S/C pouvaient être samplé par LFR F3. Le moyennage est une solution pour s'affranchir de ces perturbations.

C'est bien cela dont il s'agit.

Actuellement, nous ne pouvons pas garantir que le S/C sera propre dans cette bande de fréquence.

Ce problème pourrait impacter fortement l'algorithme de détection des SBM1.

Philippe est -ce que tu pourrais nous envoyer la dernière version du doc de Milan spécifiant les algorithmes de détection?

Ci-joint.

Philippe

Cordialement,

Emmanuel Guilhem

#5 Updated by bruno katra almost 6 years ago

  • Status changed from Feedback to In Progress
  • % Done changed from 0 to 90

Traité au niveau CNES par NC208 et accepté par le projet (QR R3).
A clôturer après datapack QR R3 updated

#6 Updated by Veronique bouzid over 5 years ago

  • Status changed from In Progress to Closed
  • % Done changed from 90 to 100

Traité et approuvé au niveau du projet

Also available in: Atom PDF