Steps and Procedures

Operations are written in a dedicated language, inspired by PLUTO (ECSS-E-ST-70-32C): simple keywords, one statement per line, blocks by indentation. It is meant for operators and mission engineers, not developers: every file is checked by the compiler before it can run, in CI and live in the editor, and the same procedure runs on a simulator, on a flatsat and in orbit.

The language has two building blocks:

• a step is an action and its success criterion, reusable across procedures. It is the unit of execution, of reporting, of recovery and of retry;
• a procedure is a composition: it orders steps and sub-procedures, handles failure, and declares the environments where it may run.

A first look#

The library platform-v3-steps of the example configuration repository (examples/config) defines two steps:

step "TCU answers" retry 3 times every 2 s
  uses sat: platform-v3
  input tcu: tcu_id
  send ping to sat.tcu[tcu] via direct
  expect sat.tcu[tcu].responding is true within 5 s

step "TCU in mode"
  uses sat: platform-v3
  input tcu: tcu_id
  input mode: tcu_operating_mode
  check sat.tcu[tcu].mode is mode

and procedures that use them:

procedure "Check TCU"
  uses sat: platform-v3
  input tcu: tcu_id
  input expected_mode: tcu_operating_mode

  do "TCU answers" with sat, tcu
  do "TCU in mode" with sat, tcu, mode = expected_mode

procedure "Hot standby test"
  description "Powers the platform from the bench supply, then brings a TCU to hot standby."
  uses sat: platform-v3
  uses psu: lab-psu
  input tcu: tcu_id
  input bus_voltage: f32 V
  allowed in AIT, IVV

  step "Power the PPU"
    send set_voltage to psu with voltage = bus_voltage
    send output_on to psu
    expect psu.output_enabled is true within 3 s

  run "Check TCU" with sat, tcu, expected_mode = STANDBY

  if failed
    run "Safe TCU" with sat, tcu

Steps#

A step contains only these statements (see the Statement Reference):

A step has no control flow and calls nothing: the first statement that fails stops the step. There is no rollback: a telecommand sent is never undone. Failure handling belongs to the procedure that calls the step.

A step of a library has a name, and declares its roles (uses) and inputs (input). A step may also be written inline, inside a procedure; it then uses the roles and inputs of its procedure, and may have no name.

Procedures#

A procedure contains:

• declarations: description, uses, input, allowed in;
• actions, run in order: do "<step>" calls a step of the library, run "<procedure>" calls a sub-procedure, step opens an inline step;
• if failed blocks, run after a failure of an earlier action.

When an action fails, the following actions are skipped up to the next if failed block, which runs; the procedure then stops, failed. See if failed.

Roles, not targets#

uses sat: platform-v3 declares a role typed by a platform (a catalogue package). A procedure never names a target: the concrete target is bound to each role when the run is launched, by a run request:

run: Hot standby test
environment: AIT
targets: {sat: sim-1, psu: psu-sim-1}
inputs: {tcu: TCU2, bus_voltage: 28 V}

The same procedure therefore runs on the simulated target sim-1, on the flatsat flatsat-1 or on the flight model sat1-fm: only the run request and the environment change. The environment decides who confirms a hazardous telecommand, whether an identity is required, and whether the procedure must be planned on a pass; the text of the procedure stays the same.

Typed inputs#

Inputs are typed: input tcu: tcu_id takes a value of the enum tcu_id of the platform, input bus_voltage: f32 V a voltage. A value given at launch carries its unit (28 V) and is converted into the unit of the input, or refused when the units are incompatible. There is no textual templating: expressions are parsed and type-checked. See Expressions, Types and Units.

Passing roles and inputs#

Roles and inputs of the same name are passed implicitly: in do "TCU answers" with sat, tcu, the step receives the role sat and the input tcu of the caller. A different name is passed explicitly: mode = expected_mode. See Calls.

Checked before running#

The compiler checks every file of a library together:

• references: roles, components, instances, measures, telecommands and their arguments;
• types and units of inputs, arguments and conditions;
• the safety rules: one confirmation per hazardous telecommand, bounded waits, no recursion, retries only where they are safe;
• environments named in allowed in.

It also computes the maximum duration of each step and procedure, retries included, which the scheduler compares with the window of a pass. See Safety Rules and Maximum Duration.

Where they live#

Steps and procedures are written in .proc files of a library package, next to its package.yaml and its stellar.lock, in the configuration repository. The shared steps of a platform live in a library versioned with its catalogue (platform-v3-steps for platform-v3). See Libraries and Validation.