Robin Mueller
52eba5cae6
All checks were successful
EIVE/eive-obsw/pipeline/pr-main This commit looks good
96 lines
3.5 KiB
C++
96 lines
3.5 KiB
C++
#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.
|
|
setFaulty(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());
|
|
}
|
|
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
|
|
if (missedReplyCount.incrementAndCheck()) {
|
|
setFaulty(event->getEvent());
|
|
}
|
|
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;
|
|
}
|
|
}
|