State Machine High Level

High level design of the State Machine subsystem

The following description of the state machine was given in the HYPED Final Design Document (FDD) in 2021. As such, this article is mainly aimed at readers who are not concerned with the implementation of the state machine subsystem. It may however serve as an internally agreed upon reference for what state machine does and does not do and what is and is not expected of the other subsystems. For more detailed information, please consult the rest of the documentation.

The goal of the state machine system (STM) is to make high level decisions solely based on information provided by the other systems. This means on the one side that the system does not have any direct interface to the pods hardware and on the other side that for the system to behave as intended, all other systems need to report their information accurately and act within the strict guidelines set by STM.

At any point in time after turning on power the pod is in exactly one state. Upon encountering different events like user input, emergencies or changes in navigation data, the pod can transition from one state to the next. Each state can only be entered once and which events may cause a transition depends on the current state.

There are nine states in total, namely

1. Idle,
2. Calibrating,
3. Ready,
4. Accelerating,
5. NominalBraking,
6. Finished,
7. FailureBraking,
8. FailureStopped, and
9. Off.

Of these, there are six nominal states, i.e. states that are reached in any successful run, and two emergency states, i.e. states that are reached only if an emergency has been reported. There are two ways in which this can happen: either another module has reported an internal failure or the emergency stop command has been received by the telemetry subsystem.

Nominal Behaviour

Idle

Let’s consider the nominal behaviour of the pod. After the start of the program and all the systems, the pod is in the Idle state (denoted kIdle for internal communication). In this state software-related initialisation, e.g. telemetry connecting to the base station, is being done. From the Idle state there is one nominal transition. If telemetry has received the command to start calibration and all the modules report that they are done with initialisation, the pod enters the Calibrating state.

Calibrating

Only three modules are currently known to do any work in the Calibrating (kCalibrating) state: Embrakes, Navigation and Motors. These three modules have time to calibrate. The other modules do not require any calibration and thus don’t have anything to do while the pod remains in this state. However, they are required to indicate that they are ready for the run.. This can, in fact, already be done in Idle as any module that is in is ready for the run has to be initialised. Once all the modules signal that calibration has been completed, the pod transitions into the Ready state.

Ready

In the Ready (kReady) state, the pod itself is fully prepared to start the run - from the software team’s point of view. Some setup, like activating high power, may still be required. While in this state, the pod is waiting for a signal from the user to make sure the run can be started safely. Upon receiving the command, the pod will then transition into the Accelerating state.

Accelerating

Accelerating (kAccelerating) is the first state of the run itself. During this phase the pod will keep accelerating and monitoring. If the pod reaches the maximum velocity before entering a predefined braking zone, then the pod enters the Cruising (kCruising) state, where the pod aims to run at a constant speed. Upon entering a predefined braking zone (depending on a calculated braking distance, the run length and a buffer) the pod then enters the NominalBraking state. This behaviour applies to Accelerating and Cruising alike. In NominalBraking (kNominalBraking) the pod starts braking. All the modules, especially motor controls, should act accordingly. Once navigation reports a velocity of less than or equal to zero, the run is finished and the pod will enter the Finished state.

Finished

The Finished (kFinished) state indicates that the run is over and nothing needs to be done anymore.

Emergency Behaviour

Now let’s consider the emergency behaviour of the pod. If a failure condition occurs while the pod is in either Idle, Calibrating or Ready state, i.e. before the run has started, then the pod enters the FailureStopped (kFailureStopped) state directly. This state indicates that the system run procedure is stopped due to a failure in one or more modules and the pod needs to be shut down in order to fix the problem in the relevant modules. All the modules should shut down immediately.

If a failure condition occurs while the pod is in either Accelerating, Cruising or Braking states, i.e. during the run, then the pod enters the FailureBraking (kEmegencyBraking) state. While in this state, motors need to be turned off and the emergency brakes need to be engaged. After coming to a stop (cf. NominalBraking) the pod then enters the previously mentioned FailureStopped state.

We do not handle indicated emergencies after the run is completed.

Shutting down

At the end, the pod is waiting for a shutdown command and will turn off upon receiving it. This applies to the Finished state and the FailureStopped state. No emergencies can occur at this stage.