custom FDIR for tmp devices

2023-04-13 23:54:23 +02:00
parent aa746276ae
commit 33773179a7
24 changed files with 139 additions and 101 deletions
--- a/mission/system/tcs/TmpDevFdir.cpp
+++ b/mission/system/tcs/TmpDevFdir.cpp
@ -0,0 +1,91 @@
+#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.
+      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
+      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;
+  }
+}