Environments and Policies

An environment is a phase in which targets are engaged: simulation, integration on a bench, validation, operations in orbit. It carries the policies that change between phases, so that a procedure validated on a flatsat runs unchanged in orbit: only the environment differs. The procedure text stays identical from one environment to the next.

environments:
  SIM:
    allow_draft: true
    human_orchestration: off
  AIT:
    allow_draft: true
    human_orchestration: off
  IVV:
    allow_draft: false
    human_orchestration:
      identity: declared
      hazardous_confirmation: [operator]
  in_orbit:
    allow_draft: false
    human_orchestration:
      identity: jwt
      hazardous_confirmation: [operator, supervisor]
      hazardous_requires_plan: true

Environment names are identifiers (a letter, then letters, digits and _): procedures name them in allowed in. A target lists the environments it may be engaged in, and every run, schedule and direct telecommand runs in one environment.

Keys#

human_orchestration rules:

The compiler refuses an unknown identity or role (topology::unknown-value), a role listed twice (topology::duplicate-role), and a list that does not start with operator (topology::invalid-confirmation): the operator confirms at the ask operator of the step, then the supervisor approves.

allow_draft: package status#

Catalogues and libraries have a status, draft or released. In an environment without allow_draft:

• a target implementing a draft catalogue cannot be engaged there (topology::draft-not-allowed, at compile time);
• a run using a draft package is refused at launch (run::draft-not-allowed).

Promoting a package from draft to released follows the review process of the team on the Git repository; the MCS only enforces the status.

human_orchestration: off#

With off (written off or false), none of the human rules apply: no identity required, anonymous callers included, no approval to wait for, manual runs free. Confirmations of hazardous telecommands are acknowledged automatically and traced as such in the evidence of the step (answered without author). A typed question (ask operator "…" as … into …) still needs an operator: without one it fails the step.

This is the setting of simulation and of AIT on a flatsat, where procedures must run unattended (dry runs, CI of procedures).

identity#

The rule applies to the launch of a run, to its answers and its commands (suspend, resume, abort), and to the creation and validation of schedules, in the environment of the run. With identity: jwt, the executor checks the token of each answer again. See Identity and Roles.

hazardous_confirmation#

In a step, each send of a hazardous telecommand follows an ask operator "…". The roles of hazardous_confirmation answer it in turn, each by a different person:

• [operator]: one confirmation, from an operator (IVV on a bench);
• [operator, supervisor]: the operator confirms, then a supervisor with the supervisor role approves, from his own session (in orbit).

Both identities and times go into the evidence of the step. See Hazardous Confirmations.

hazardous_requires_plan: mandatory planning#

With hazardous_requires_plan: true, a run that sends a hazardous telecommand (directly or through its calls) cannot be launched manually:

• without plan, its request is refused (422 run::plan-required);
• with a plan too (422 run::must-be-scheduled): it runs only from a schedule, which the scheduler submits itself at its time;
• where a supervisor confirms, the schedule needs the validation of a supervisor beforehand (stellar schedules validate <id>).

See Scheduling.

Procedures allowed in an environment#

A procedure declares where it may run with allowed in:

procedure "Hot standby test"
  uses sat: platform-v3
  uses psu: lab-psu
  input tcu: tcu_id
  input bus_voltage: f32 V
  allowed in AIT, IVV

A run of it elsewhere is refused (run::not-allowed). Without allowed in, a procedure is allowed in every environment. The procedure of an alarm reaction must be allowed in the environment where the reaction runs.

The in_orbit environment#

The environment named in_orbit has additional rules, tied to passes:

• a run bound to a pass needs a booked pass (409 run::not-booked; a schedule is at_risk otherwise);
• a manual run is refused when the default link of a target is not bound, or its gateway reports no link (409 run::no-link), and warned when it may outlast the pass in progress;
• an alarm reaction is launched only when the target is ready.

Keep that name for the operational environment of a spacecraft. See Passes.