Feature #481
closed
Cohérence/Intégrité sur TC_LFR_LOAD_NORMAL_PAR
0%
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
Related issues
Updated by Veronique bouzid about 9 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
Updated by Veronique bouzid about 9 years ago
- File just_load_normal_par.py just_load_normal_par.py added
- Category set to SRS
- Status changed from In Progress to Resolved
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
Updated by bruno katra almost 9 years ago
- Status changed from Resolved to Closed
Fait dans SRS + SUM
Updated by bruno katra almost 3 years 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)