20 likes | 153 Vues
On November 22nd, ARGOS-3 experienced a significant telemetry anomaly (AR 6555) characterized by corrupted mission data. Despite all health parameters appearing normal, inconsistencies were observed in telemetry messages. A subsequent hardware reset on November 24th restored normal operations. However, a second anomaly on January 1st revealed partial consistency in telemetry. Investigations indicate potential issues at the FIFO or FPGA levels. Specific monitoring procedures are in place for rapid detection of future anomalies. Restart procedures and corrective measures are outlined, with an expected mission downtime of half a day for resolution.
E N D
ARGOS-3 : Anomaly AR 6555 • Major Anomaly AR 6555 : Corrupted Argos Mission Telemetry • First occurrence on November 22nd • Telemetry is inconsistent but some characteristic « bytes » of messages can be recognized within the data • All HK parameters are « green », HK blocks that contain detailed software status don’t indicate any specific problem • All other functions of instrument work properly (beacon-instrument protocol, acknowledgement of Master Beacon directives, dump of memory) • Hardware reset on November 24th. Immediately all is OK. • Second occurrence on January 1st. • Telemetry is partly consistent (15 % of messages correct for all types, many ’00’ in the telemetry, most of ‘D60’ are missing though they have been checked by the SW before being written in the FIFO). • ‘Software restart’ on January 11th. Immediately all is OK. • ‘Software restart’ activates also some HW reset (ex : on telemetry FIFO) • Investigation still in progress : problem seems to be located at FIFO or at FPGA level. Telemetry is checked all the time until the writting in FIFO.
ARGOS-3 : Anomaly AR 6555 • Consequence of Anomaly 6555 • Implies a HW or SW restart of the instrument • Today, SW doesn’t seem involved (a new version of management SW is not expected therefore uploading is not expected ) • Specific monitoring of Argos Telemetry performed in CLS in order to detect asap the anomaly and to alert CNES then Eumetsat : it could take take several hours during the commissioning phase • Procedure to restart lasts 10 minutes (pass over Svalbard) and needs to be compatible with other EUM operations • Several patchs to be transmitted after each restart : • 2 corrective patchs (via master beacon) • 3 parameter setting patch (via master beacon then 3 x TC-Level from SVL) in order to reduce the false alarm probability on LD and HD beacons • need to have two visibilities over Toulouse for Master Beacon but could be done later through the Svalbard master beacon • Instrument counter is reset, that implies the ground to board synchronisation to be performed again (through the Toulouse reference beacon) • Half a day of mission loss is expected after the Restart • In Routine, if problem occurs again, specific Operations between CLS and EUMETSAT