Disclaimer: The following notes are based on our own review and interpretation of the service from the official documentation and may not represent the intended behavior of the service author. It should not be considered official guidance but OpenJAUS' opinion on the considerations and challenges needed to use this service.



Description of the Service


The PlatformState service provides a mechanism to the manage the state of an entire platform (i.e., an entire unmanned vehicle) versus managing the state of individual components one the platform.


At first glance, it is easy to connect the PlatformState service and the Management service, and while they are linked, the PlatformState states are NOT the same as the Management states. In fact, the PlatformState service could have dependencies on JAUS services other than the Management service or even dependencies outside of JAUS.


Below we the discuss the possible PlatformState states:


PlatformState::Initialize


This is the initial state of the platform after power on (or reset).  While in this state, the platform is not ready to undergo any commanded action and the various subsystems and/or software processes are running initialization routines and coming online.


Relationship to other JAUS services


JAUS components that contain the Management service would be moving out of the Management::Init state.


PlatformState::Operational


In this state the full functionality of the platform is available to the operator. The transition into this state occurs automatically when the various platform subsystems come online and/or special or emergency vehicle operation constraints are removed (Example: E-Stop is cleared?).


Relationship to other JAUS services


JAUS components that contain the Management service would be in one of the normal operating states for the Management service (NotControlledStandby, ControlledStandby, Ready).


PlatformState::Emergency


In this state the platform has experienced some recoverable malfunction and the platform should be made safe while the malfunction is recovered. The definition of safe will vary based on the vehicle; for ground vehicles this could mean coming to a safe, controlled stop; for underwater vehicles this could mean returning to the surface; for air vehicles, this could mean loitering around a specific point and/or a specific altitude. A platform should not accept any commands while it is in the Emergency state.


Relationship to other JAUS services


When the PlatformState service is commanded to the PlatformState::Emergency state, JAUS components that contain the Management service would be commanded to the Management::Emergency state.


PlatformState::Shutdown


The platform has received a request for a platform-wide shutdown of all of its hardware and software subsystems. When the platform enters PlatformState::Shutdown state it should end operations and stop responding to messages until the platform is physically restarted.


Relationship to other JAUS services


When the PlatformState service is commanded to the PlatformState::Shutdown state, JAUS components that contain the Management service would be commanded to the Management::Shutdown state.


PlatformState::SystemAbort


The platform has experienced a non-recoverable failure in a mission critical component, resulting in the platform being incapable of completing it's mission. The transition into this state occurs automatically when the a mission-critical component failure is detected.


Relationship to other JAUS services


The transition to the PlatformState::SystemAbort state may occur when a mission-critical JAUS component that contains the Management service enters the Management::Failure state.


PlatformState::RenderUseless


The platform has been commanded to render itself useless. When in this state, the platform has been disabled in some way such that it is less valuable if it were captured by an adversary.

 

Relationship to other JAUS services


When the PlatformState service is commanded to the PlatformState::RenderUseless state, JAUS components that contain the RenderUseless service would be sent the RenderUseless command.



Considerations and Challenges


What does Operational mean?


In IOP v3 Profiling Rules Section 6.2.6.2.1.1, the Operational state is described as: "indicates that all systems can be in an actively controlled state and the full functionality of the platform is available to the operator". Earlier in that same section, it also says "the transition from Initialize to Operational is expected to occur automatically when all mission-critical components that support the JAUS Management interface have transitions out of the Init state". However, just because the mission-critical components are available doesn't mean the full-functionality of the platform is available. For example, let's say I have a vehicle with 5 cameras but I can complete a mission with just 2 specific cameras if necessary. In this scenario, the mission-critical components are the 2 required cameras, so:

  • Do we move to Operational when those 2 cameras are online? If so, the "full functionality of the platform" is not available.
  • Do we requires all 5 cameras to be online before moving to Operational? If so, is the PlatformState constantly in Initialize?
  • How does the vehicle operate outside of the Operational state? While it is possible to prevent an operator from directly controlling the Mobility component if it is online while other components are still coming online, it would probably not be a recommended design approach. As such, I would be able drive the vehicle while still in the Initialize state, so is the PlatformState state more informational than prescriptive?



Synchronization of PlatformState and Management


The behavior of the PlatformState service relative to the Management service can vary based on a number of implementation specific decisions. Below, we outline some considerations to take into account during the design and implementation process. 



PlatformState::Emergency and Management::Emergency


The description of the PlatformState service seems to imply that when it is transitioned to the PlatformState::Emergency state it should command the on-board JAUS components that contain the Management service to the Management::Emergency state. While this is not necessarily a requirement, depending on the overall platform design, it may be the only option. For example, if off-the-shelf JAUS devices (such as cameras, manipulators, etc) are used, the only option would be to use the Management service on those devices. As such:

  • What happens if a JAUS component is directly commanded to Management::Emergency? Does PlatformState monitor the state of all JAUS components and move to the PlatformState::Emergency state?
    • Since the Management service allows for a client to command the service to the Management::Emergency state directly, an OCU could allow an operator to bypass the PlatformState service and command a JAUS component to Management::Emergency directly.
  • If we force PlatformState into PlatformState::Emergency if a component is in Management::Emergency and since PlatformState specifies that the platform should not accept any commands while in the PlatformState::::Emergency state, what happens when there are partial errors?
    • For example, if a Manipulator component is put into Management::Emergency but there is no problem with the Mobility component, and we force the PlatformState into PlatformState::Emergency, we prevent operation of the Mobility component, and possible recovery of the platform, even though there is no problem with the Mobility component.
  • If we don't force PlatformState into PlatformState::Emergency if a component is in Management::Emergency, then the PlatformState state is not a summary of the platform's actual state but instead is representation of the desired/commanded state of the platform?



PlatformState::Shutdown and Management::Shutdown


The description of the PlatformState service seems to imply that when it is transitioned to the PlatformState::Shutdown state it should command the on-board JAUS components that contain the Management service to the Management::Shutdown state. While this is not necessarily a requirement, depending on the overall platform design, it may be the only option. For example, if off-the-shelf JAUS devices (such as cameras, manipulators, etc) are used, the only option would be to use the Management service on those devices. As such:

  • What happens if a JAUS component is directly commanded to Management::Shutdown? Does PlatformState detect the change in state of the JAUS component and move to the PlatformState::Shutdown state?
  • If we force PlatformState into PlatformState::Shutdown if a component is in Management::Shutdown, then we tie the entire platform to a single component?
    • There may be valid reasons to shutdown an individual component but still want the rest of the system running (though I can't think of any right now).
  • If we don't force PlatformState into PlatformState::Shutdown if a component is in Management::Shutdown, then the PlatformState state is not a summary of the platform's actual state but instead is representation of the desired/last commanded state of the platform?



PlatformState::SystemAbort and Management::Failure


The description for the PlatformState::SystemAbort state is more definitive than the PlatformState::Emergency and PlatformState::Shutdown states in that the PlatformState::SystemAbort state is entered when the platform being incapable of completing it's mission. However, while in this state, the platform could still be partially operational. For example if the Mobility component moves to the Management::Failure state it seems reasonable that the PlatformState service will move to the PlatformState::SystemAbort state. However, the manipulator or cameras may still be usable and depending on the current mission could still be useful.



Hard Terminal States and State Monitoring


The PlatformState::Shutdown and PlatformState:: RenderUseless states are "hard terminal states" meaning that the implementation could be such that all hardware and software processes are terminated. This is different from the PlatformState::SystemAbort which although also a terminal state is less likely to result in the intentional termination of software and/or hardware. Therefore, when the platform is put into the PlatformState::Shutdown or PlatformState:: RenderUseless state it may be impossible to determine that actual current PlatformState state.



PlatformState reported in ReportPlatformState is unreliable


The PlatformState reported the ReportPlatformState message is unreliable and ambiguous. When the PlatformState service is commanded to transition to a new state (using the SetPlatformState message), the transition can take some time. For example, when transitioning to the PlatformState::Emergency state the PlatformState service may need to send SetEmergency messages and monitor that all the necessary components have correctly entered the Management::Emergency state. However, the service definition does handle transitioning between states every well. While a ConfirmPlatformStateRequest message is sent to indicate that the PlatformState service is transitioning, this message is only sent once and due to the potential for loss of messages, may never be received by the PlatformState client. If this happens, the client cannot determines if the PlatformState service is transitioning or not. In addition, the service also does not specify what state should be reported in the ReportPlatformState message. While the PlatformState is transitioning, there are 2 options for the ReportPlatformState: (1) report the state we are transitioning from, or (2) report the state we are transitioning to. Either option has issues (assuming that the ConfirmPlatformStateRequest message is lost):

  1. Report the state we are transitioning from
    • If the state we are transitioning from is reported, the client cannot determine if the PlatformState is attempting the transition or not. The only option is to continue to send the SetPlatformState message until the reported PlatformState matches the desired PlatformState.
  2. Report the state we are transitioning to
    • If the state we are transitioning to is reported, the client can determine that the SetPlatformState message was received and at best PlatformState is attempting the transition. However, the client cannot determine if the transition is still ongoing, or if the transition is complete.



Problems with PlatformState Transitions cannot be Detected 


Regardless of the approach chosen above for the ReportPlatformState message, a client cannot determine if there was a problem transitioning to the desired platform state. For example, in order to transition to the PlatformState::Shutdown state, the PlatformState requires control of JAUS components with the Management service to put them into the Management::Shutdown state (assuming that is how Shutdown is implemented). However, if there is a problem with getting control of the component, there is no way for the PlatformState client to determine there was a problem.




Errata:


IOP v3 Profiling Rules

  • Section 6.2.6.2.1.1
    • The RenderUseless state is not described or addressed in any way


IOP v3 Custom Services

  • Section 4.43.5.2.1
    • The SetPlatformState message allows for PlatformState value of System_Abort which is never used.
      • It appears as though these are duplicates of the values in the ReportPlatformState message. In our opinion, the availability of the System_Abort value in the SetPlatformState message can be easily mistaken as the ability to command the service to the PlatformState::SystemAbort state using the SetPlatformState message, which is not true.