Project

General

Profile

Actions

Feature #481

closed

Cohérence/Intégrité sur TC_LFR_LOAD_NORMAL_PAR

Added by Veronique bouzid over 6 years ago. Updated about 24 hours ago.

Status:
Closed
Priority:
Normal
Category:
SRS
Target version:
-
Start date:
10/08/2015
Due date:
% Done:

0%

Estimated time:

Description

Voici les régles appliquées pour valider las paramètres utilisés dans TC_LFR_LOAD_NORMAL_PAR:
6 parametres sont disponibles pour configurer le NORMAL MODE

SY_LFR_N_SWF_L
SY_LFR_N_SWP_P
SY_LFR_N_ASM_P
SY_LFR_N_BP_P0
SY_LFR_N_BP_P1
SY_LFR_N_CWF_LONG_F3

Le parametre SY_LFR_N_CWF_LONG_F3 étant codé sur 1 bit,aucun test n'est effectué.

2 types de vérification sont effectués
- le parametre doit appartenir à son domaine de définition (cf ICD)
- le parametre doit etre coherent avec les objectifs scientifiques

Voici l'ordre dans lequel les parametres sont évalués

La référence est ICD 3.9

SY_LFR_N_SWF_L
--> ICD indique [16,2048] par défaut 2048
SY_LFR_N_SWF_L = 2048 --> VALEUR FIXEE, on ne peut pas la modifiée
--> INCONSISTENT si cette valeur n'est pas 2048
Voir s'il faut mettre à jour l'ICD

SY_LFR_N_SWP_P
--> ICD indique [16,65528] par défaut 300
SY_LFR_N_SWP_P < 16
--> INCONSISTENT
Par contre 65528 n'est plus correcte (plus besoin de multiple de 8), on peut accepter 65535.
--> Mettre à jour l'ICD

Attention, je me suis rendue compte que Le parametre SY_LFR_N_BP_P0 etait testé avant SY_LFR_N_ASM_P (cf Bug xxx)

SY_LFR_N_BP_P0
Aucun domaine de définition valeur par défaut = 4
SY_LFR_N_BP_P0 < 4
--> INCONSISTENT
Voir s'il faut mettre à jour l'ICD

SY_LFR_N_ASM_P
Aucun domaine de définition valeur par défaut = 3600s
SY_LFR_N_ASM_P = 0
--> INCONSISTENT
Voir s'il faut mettre à jour l'ICD

SY_LFR_N_BP_P1
Aucun domaine de définition valeur par défaut = 20s
SY_LFR_N_BP_P1 < 20
--> INCONSISTENT
Voir s'il faut mettre à jour l'ICD

Cohérence entre parametres
Ces vérifications ne sont effectuées que si les paramètres respectent leur domaine de définition.

1- on accepte que SY_LFR_N_ASM_P = 4s si SY_LFR_N_BP_P0 = 4s par exemple, cela un sens scientifiquement
donc
si SY_LFR_N_ASM_P est un multiple de SY_LFR_N_BP_P0 --> OK

2- on accepte que SY_LFR_N_BP_P1 = 24 et SY_LFR_N_BP_P0 = 4s
donc
si SY_LFR_N_BP_P1 est un multiple de SY_LFR_N_BP_P0 --> OK

De meme SY_LFR_N_BP_P0 = SY_LFR_N_BP_P1 = 255 sera accepté


Files

just_load_normal_par.py (4.71 KB) just_load_normal_par.py Veronique bouzid, 02/10/2015 04:56 PM

Related issues

Related to Bug #65: TC_LFR_LOAD_NORMAL_PAR: pas de vérif sur SY_LFR_N_ASM_P, S_LFR_N_BP_P0, SY_LFR_N_BP_P1.Closedbruno katra24/02/2014

Actions
Related to Bug #170: Mauvais parametrage avec TC_LOAD_NORMAL_PARClosedVeronique bouzid16/06/2014

Actions
Related to Bug #62: Mise à jour ICDClosedVeronique bouzid21/02/2014

Actions
Actions #1

Updated by Veronique bouzid over 6 years ago

  • Description updated (diff)
Actions #2

Updated by Veronique bouzid over 6 years ago

  • Description updated (diff)
Actions #3

Updated by Veronique bouzid over 6 years ago

  • Status changed from New to In Progress

De meme SY_LFR_N_BP_P0 = SY_LFR_N_BP_P1 = 255 sera accepté

--> faire le test

Actions #4

Updated by Veronique bouzid over 6 years ago

Le parametrage SY_LFR_N_BP_P0 = SY_LFR_N_BP_P1 = 255 sera accepté seulement si le parametre SY_LFR_N_ASM_P est un multiple de 255.

Ici un extrait du fichier 2015_10_02-15_47_40-Detail.txt

15:46:11.31063, TC_LFR_LOAD_NORMAL_PAR, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TC_PACKET = 1, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: PRIVATE_SCIENCE_OR_TELECOMMAND = 12, (PACKET_ID=0x1ccc), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=14572, (PACKET_SEQUENCE_CONTROL=0xf8ec), PACKET_LENGTH=15, CCSDS_SECONDARY_HEADER_FLAG=0, PUS_VERSION = 1, ACK_EXECUTION_COMPLETION=1, ACK_EXECUTION_PROGRESS=0, ACK_EXECUTION_START=0, ACK_ACCEPTANCE=1, SERVICE_TYPE: EQ_CONFIGURATION = 181, SERVICE_SUBTYPE: LOAD_NORMAL_PARAMETERS_1 = 13, SOURCE_ID: MISSION_TIMELINE = 110, SY_LFR_N_SWF_L = 2048, SY_LFR_N_SWP_P = 300(s), SY_LFR_N_ASM_P = 3600(s), S*Y_LFR_N_BP_P0 = 255(s), SY_LFR_N_BP_P1 = 255(s)*, SPARE=0x0, SY_LFR_N_CWF_LONG_F3 = 0, SPARE=0x0, CRC = 0xb926

15:46:11.320167, TM_LFR_TC_EXE_INCONSISTENT, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: ACKNOWLEDGE = 1, (PACKET_ID=0xcc1), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=1, (PACKET_SEQUENCE_CONTROL=0xc001), PACKET_LENGTH=19, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: TELECOMMAND_VERIFICATION = 1, SERVICE_SUBTYPE: TC_EXECUTION_COMPLETION_FAILURE = 8, DESTINATION_ID: MISSION_TIMELINE = 110, TIME=0x8000000dff4f, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xf8ec, PA_RPW_TC_FAILURE_CODE: WRONG_APP_DATA = 5, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=13, PA_RPW_BYTE_POSITION=14, PA_RPW_RCV_VALUE=16

Le parametre PA_RPW_BYTE_POSITION correspond à l octet 14 de la TC_LFR_LOAD_NORMAL_PAR qui pointe sur SY_LFR_N_ASM_P,
Le parametre PA_RPW_RCV_VALUE correspond aux 8 bits de poids faible du champ SY_LFR_N_ASM_P = 3600 , E10 en hex donc 10 hexa = 16 en decimal.

Les résultats sont rangés dans le repertoire /home/validation/data/R3/3.0.0.9/TESTS-UNITAIRES/FEATURE-481

Actions #5

Updated by bruno katra almost 6 years ago

  • Status changed from Resolved to Closed

Fait dans SRS + SUM

Actions #6

Updated by bruno katra about 24 hours ago

Issue fermée mais je rajoute ce commentaire pour l'historique suite à une discussion avec Alexis, en particulier sur la phrase de la description :
Le parametre SY_LFR_N_CWF_LONG_F3 étant codé sur 1 bit,aucun test n'est effectué.

En effet, Alexis m'a alerté sur le fait que le FSW ne vérifie pas l'intervalle de valeurs acceptables. Après réflexion, cela a un sens car dans l'ICD le champs SY_LFR_N_CWF_LONG_F3 est bien un boolean codé sur 1 bit, toutes les valeurs (0 et 1) sont acceptables. Le fait de ne pas écrire n'importe quoi (les 7 autres bits de l'octet sont des spares) dans la TC relève de la vérification d'intégrité faite au niveau de la construction de la TC donc le LESIA et non le LPP. Par contre Alexis a du coup supprimer la lecture de cette valeur au niveau de l'acceptance dans FSW>=3.3.0.5 car elle était lue mais jamais utilisée (car non testée) dans l'acceptance. Elle est bien lue plus tard pour l'execution avec un masque explicite pour masquer les 7 bits de spare par précaution (masque ajouté par Alexis en 3.3.0.5)

Actions

Also available in: Atom PDF