eive-obsw/mission/system/tcs/TmpDevFdir.cpp

96 lines
3.5 KiB
C++
Raw Normal View History

2023-04-13 23:54:23 +02:00
#include "TmpDevFdir.h"
#include <fsfw/devicehandlers/DeviceHandlerIF.h>
#include <fsfw/modes/HasModesIF.h>
#include <fsfw/power/Fuse.h>
#include <fsfw/thermal/ThermalComponentIF.h>
TmpDevFdir::TmpDevFdir(object_id_t sensorId)
: DeviceHandlerFailureIsolation(sensorId, objects::NO_OBJECT) {}
ReturnValue_t TmpDevFdir::eventReceived(EventMessage* event) {
if (isFdirInActionOrAreWeFaulty(event)) {
return returnvalue::OK;
}
ReturnValue_t result = returnvalue::FAILED;
switch (event->getEvent()) {
case HasModesIF::MODE_TRANSITION_FAILED:
case HasModesIF::OBJECT_IN_INVALID_MODE:
case DeviceHandlerIF::DEVICE_WANTS_HARD_REBOOT:
// We'll try a recovery as long as defined in MAX_REBOOT.
// Might cause some AssemblyBase cycles, so keep number low.
// Ignored for TMP device, no way to power cycle it without going to OFF/BOOT mode.
// handleRecovery(event->getEvent());
break;
case DeviceHandlerIF::DEVICE_INTERPRETING_REPLY_FAILED:
case DeviceHandlerIF::DEVICE_READING_REPLY_FAILED:
case DeviceHandlerIF::DEVICE_UNREQUESTED_REPLY:
case DeviceHandlerIF::DEVICE_UNKNOWN_REPLY: // Some DH's generate generic reply-ids.
case DeviceHandlerIF::DEVICE_BUILDING_COMMAND_FAILED:
// These faults all mean that there were stupid replies from a device.
// With now way to do a recovery, set the device to faulty immediately.
if (strangeReplyCount.incrementAndCheck()) {
setFaulty(event->getEvent());
}
2023-04-13 23:54:23 +02:00
break;
case DeviceHandlerIF::DEVICE_SENDING_COMMAND_FAILED:
case DeviceHandlerIF::DEVICE_REQUESTING_REPLY_FAILED:
// The two above should never be confirmed.
case DeviceHandlerIF::DEVICE_MISSED_REPLY:
result = sendConfirmationRequest(event);
if (result == returnvalue::OK) {
break;
}
// else
2023-06-18 17:11:38 +02:00
if (missedReplyCount.incrementAndCheck()) {
setFaulty(event->getEvent());
}
2023-04-13 23:54:23 +02:00
break;
case StorageManagerIF::GET_DATA_FAILED:
case StorageManagerIF::STORE_DATA_FAILED:
// Rather strange bugs, occur in RAW mode only. Ignore.
break;
case DeviceHandlerIF::INVALID_DEVICE_COMMAND:
// Ignore, is bad configuration. We can't do anything in flight.
break;
case HasHealthIF::HEALTH_INFO:
case HasModesIF::MODE_INFO:
case HasModesIF::CHANGING_MODE:
// Do nothing, but mark as handled.
break;
//****Thermal*****
case ThermalComponentIF::COMPONENT_TEMP_LOW:
case ThermalComponentIF::COMPONENT_TEMP_HIGH:
case ThermalComponentIF::COMPONENT_TEMP_OOL_LOW:
case ThermalComponentIF::COMPONENT_TEMP_OOL_HIGH:
// Well, the device is not really faulty, but it is required to stay off as long as possible.
setFaulty(event->getEvent());
break;
case ThermalComponentIF::TEMP_NOT_IN_OP_RANGE:
// Ignore, is information only.
break;
//*******Default monitoring variables. Are currently not used.*****
// case DeviceHandlerIF::MONITORING_LIMIT_EXCEEDED:
// setFaulty(event->getEvent());
// break;
// case DeviceHandlerIF::MONITORING_AMBIGUOUS:
// break;
default:
// We don't know the event, someone else should handle it.
return returnvalue::FAILED;
}
return returnvalue::OK;
}
void TmpDevFdir::eventConfirmed(EventMessage* event) {
switch (event->getEvent()) {
case DeviceHandlerIF::DEVICE_SENDING_COMMAND_FAILED:
case DeviceHandlerIF::DEVICE_REQUESTING_REPLY_FAILED:
case DeviceHandlerIF::DEVICE_MISSED_REPLY:
setFaulty(event->getEvent());
break;
default:
break;
}
}