Skip to end of metadata
Go to start of metadata

The execution of mission plans may be transitioning a platform agent's instruments through various states without the parent platform being directly involved. So, for those platform commands that involve corresponding processing in its child instruments, the parent platform needs to check the state of each child instrument before determining that the command needs to be issued against it.

The following strategy for a more graceful dispatch is based on:

  • an ordering of relevant agent states according to "level of activation": UNINITIALIZED < INACTIVE < IDLE < COMMAND < STREAMING
  • and whether or not a particular command will increase the level of activation of an instrument agent; for example, GO_INACTIVE would decrease it and GO_ACTIVE would increase it.

The algorithm to dispatch a platform agent command, which is also in principle to be issued against its child instruments as part of the processing of the command, is as follows:

  • Let EVT be the command sent to the parent platform agent.
  • Let CHILD be one of the platform's child instruments, and CUR_STATE be the current state of CHILD.
  • Let EXP_STATE be the expected state of CHILD according to the intended command EVT against that CHILD.
  • Check if CUR_STATE is already "acceptable" for the intended state:
    • if CUR_STATE == EXP_STATE
      • CUR_STATE is immediately acceptable; no need to issue EVT.
    • else
      • if EVT is a command that decreases the level of activation and CHILD's current state is already at an even lower level,
      • or (symmetrically), EVT is a command that increases the level of activation and CHILD's current state is already at an even higher level,
      • then:
        • CUR_STATE is acceptable, no need to issue EVT.
      • else
        • issue EVT to the CHILD.
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.