Project

General

Profile

Bug #558

[QR R3] [RPWMEB-515] - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu

Added by bruno katra about 6 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Category:
SRS
Target version:
-
Start date:
03/11/2015
Due date:
% Done:

90%

Estimated time:
revision:
r0

Description

In order to test failure cases, a wrong telecommand TC_LFR_ENTER_MODE is sent.
A telemetry packet TM_LFR_TC_EXE_INCONSISTENT is received instead of a telemetry packet TM_LFR_TC_EXE_NOT_EXECUTABLE (which is the expected behaviour).

----------------------
A cloturer après maj SRS.

History

#1 Updated by bruno katra about 6 years ago

Le 19/10/2015 08:12, paul leroy a écrit :

Je veux bien faire la modif si ça arrange tout le monde, mais je préférai mon interprétation bien entendu.

Le 10/16/2015 10:29 AM, Bruno Katra a écrit :

Salut à tous !
concernant ce point, je comprends qu'en cas de TC_LFR_ENTER_MODE à une date définie erronée, le LESIA souhaiterait recevoir du fsw un TM_LFR_TC_EXE_NOT_EXECUTABLE mais actuellement nous envoyons un TM_LFR_TC_EXE_INCONSISTENT.

Or la sss dit :

SSS-CP-EQS-150 Equipment command feedback

The equipment flight software shall produce, depending on the final status of the execution and the
possible encountered errors, the following command acknowledgment packets (which are
compliant to the PUS service n°1):

 TM_xxx_TC_EXE_INCONSISTENT in case of wrong or inconsistent field in the data fields.
 TM_xxx_TC_EXE_NOT_EXECUTABLE in case of command that can not be executed at
this time.

Là on est dans la pure philosophie car au niveau de l'interprétation, je rejoins Paul, les 2 cas sont défendables!

Il se trouve que les 2 autres instruments ont choisi le TM_LFR_TC_EXE_NOT_EXECUTABLE et que du coup on nous demande de se plier à la raison du plus grand nombre et faire comme eux.

Si cette analyse vous convient, je vais ouvrir un point redmine en NC (dès que notre serveur redmine sera reparti) et répondre au JIRA.

A+

bRunO

#2 Updated by bruno katra about 6 years ago

  • Subject changed from JIRA RPWMEB-515 to JIRA RPWMEB-515 - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu

#3 Updated by paul leroy almost 6 years ago

  • Assignee changed from paul leroy to bruno katra

fsw >= 3.0.0.14
J'ai fait la modification, je renvoie maintenant TM_LFR_TC_EXE_NOT_EXECUTABLE si la date est erronée.

#4 Updated by bruno katra almost 6 years ago

  • Description updated (diff)
  • Status changed from New to In Progress
  • % Done changed from 0 to 90

Constaté OK par Véronique.
A cloturer après maj SRS.

#5 Updated by bruno katra almost 6 years ago

  • Subject changed from JIRA RPWMEB-515 - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu to [QR R3] [RPWMEB-515] - TM_LFR_TC_EXE_INCONSISTENT au lieu de TM_LFR_TC_EXE_NOT_EXECUTABLE attendu

#6 Updated by Veronique bouzid almost 6 years ago

Bug (qui n'en est pas un) est corrigé en 3.0.0.14.
Le script rejoué est /opt/VALIDATION_R3/lfrverif/LFR-SVS/SVS-0034/activateLfrModeNominalCuc.py.

Les fichiers (2016_01_27-08_29_33*) se trouvent dans /home/validation/data/R3/3.0.0.14/1.1.89/SVS-0034.
Voici un extrait du fichier Detail.txt

08:23:52.07408, TM_LFR_HK, CCSDS_VERSION_NUMBER = 0, PACKET_TYPE: TM_PACKET = 0, DATA_FIELD_HEADER_FLAG: WITH_HEADER = 1, PROCESS_ID: RPW_PID_2 = 76, PACKET_CATEGORY: HK_ROUTINE = 4, (PACKET_ID=0xcc4), SEGMENTATION_GROUPING_FLAG: STANDALONE_PACKET = 3, SEQUENCE_CNT=158, (PACKET_SEQUENCE_CONTROL=0xc09e), PACKET_LENGTH=129, SPARE_1=0, PUS_VERSION = 1, SPARE_2=0, SERVICE_TYPE: HOUSEKEEPING_AND_DIAGNOSTIC_DATA_REPORTING = 3, SERVICE_SUBTYPE: HK_PARAMETER_REPORT = 25, DESTINATION_ID: GROUND = 0, TIME=0x800000a0439b, PA_LFR_HK_REPORT_SID: LFR_HK_SID = 1, HK_LFR_MODE: SBM2 = 4,

08:23:52.099268,* TC_LFR_ENTER_MODE (CP_LFR_MODE=1)*, 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=5545, (PACKET_SEQUENCE_CONTROL=0xd5a9), PACKET_LENGTH=13, 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: ENTER_MODE = 41, SOURCE_ID: MISSION_TIMELINE = 110, SPARE=0, CP_LFR_MODE: NORMAL = 1, CP_LFR_ENTER_MODE_TIME=0x000000a40000, CRC = 0xe084

08:23:52.154976, TM_LFR_TC_EXE_NOT_EXECUTABLE, 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=67, (PACKET_SEQUENCE_CONTROL=0xc043), 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=0x800000a05836, PA_RPW_TELECOMMAND_PKT_ID=0x1ccc, PA_RPW_PKT_SEQ_CONTROL=0xd5a9, PA_RPW_TC_FAILURE_CODE: TC_NOT_EXE = 42000, PA_RPW_TC_SERVICE=181, PA_RPW_TC_SUBTYPE=41, HK_LFR_MODE: SBM2 = 4, HK_LFR_DPU_SPW_ENABLED: ENABLED = 1, HK_LFR_DPU_SPW_LINK_STATE: RUN = 5, SPARE=0, HK_LFR_SC_POTENTIAL_FLAG: ON = 1, HK_LFR_MAG_FIELDS_FLAG: OFF = 0, SY_LFR_WATCHDOG_ENABLED: DISABLED = 0, HK_LFR_CALIB_ENABLED: DISABLED = 0, HK_LFR_RESET_CAUSE: POWER_ON = 1

Ici le log concerne une commutaion en normal mode. Dans le fichier tous les modes ont été testés et à chaque fois lla TM_LFR_TC_NOT_EXECUTABLE a été géneré si le champ CP_LFR_ENTER_MODE_TIME.

Contexte du test
----------------------
FSW 3.0.0.14
VHDL 1.1.89
EM sans timegen
SocExplorerEngine.get SocExplorer: Version = 0.6.2, Branch = defaukt, Changeset = 819d0376d481
StarDundee

#7 Updated by bruno katra over 5 years ago

  • Status changed from In Progress to Closed

Mis à jour dans SRS 2.0

Also available in: Atom PDF