Skip to main content

Image

Space engineering

Spacecraft on-board control procedures

Foreword

This Standard is one of the series of ECSS Standards intended to be applied together for the management, engineering and product assurance in space projects and applications. ECSS is a cooperative effort of the European Space Agency, national space agencies and European industry associations for the purpose of developing and maintaining common standards. Requirements in this Standard are defined in terms of what shall be accomplished, rather than in terms of how to organize and perform the necessary work. This allows existing organizational structures and methods to be applied where they are effective, and for the structures and methods to evolve as necessary without rewriting the standards.

This Standard has been prepared by the ECSS-E-ST-70-01 Working Group, reviewed by the ECSS Executive Secretariat and approved by the ECSS Technical Authority.

Disclaimer

ECSS does not provide any warranty whatsoever, whether expressed, implied, or statutory, including, but not limited to, any warranty of merchantability or fitness for a particular purpose or any warranty that the contents of the item are error-free. In no respect shall ECSS incur any liability for any damages, including, but not limited to, direct, indirect, special, or consequential damages arising out of, resulting from, or in any way connected to the use of this Standard, whether or not based upon warranty, business agreement, tort, or otherwise; whether or not injury was sustained by persons or property or otherwise; and whether or not loss was sustained from, or arose out of, the results of, the item, or any services that may be provided by ECSS.

Published by:     ESA Requirements and Standards Division
    ESTEC, P.O. Box 299,
    2200 AG Noordwijk
    The
Copyright:     2010 © by the European Space Agency for the members of ECSS

Change log

ECSS-E-ST-70-01A


Never issued


ECSS-E-ST-70-01B


Never issued


ECSS-E-ST-70-01C


16 April 2010


 First issue


Introduction

On-board control procedures (OBCPs) have been implemented on an ad-hoc basis on several European missions over the last 25 years, so the validity and utility of the concept has been amply demonstrated.

The purpose of the present Standard is to define an OBCP concept that can be applied for any mission and which:

fulfils the needs of all categories of user (system engineers, on-board software engineers, AIT engineers, operations engineers);

ensures that OBCPs have a development lifecycle that is independent of the remainder of the on-board software (OBSW);.

conforms with, and extends, existing ECSS monitoring and control standards, namely ECSS-E-70-41 and ECSS-E-ST-70-31.

Scope

This Standard defines the concept for an OBCP system, identifying the on-board functionality for OBCP execution and the ground functionality for OBCP preparation and subsequent control.

This Standard also defines the development lifecycle for OBCPs and identifies the relationships of this lifecycle with the overall space system, and in particular with the other elements of the on-board software.

This Standard assumes that missions implementing OBCPs are also compliant with ECSS-E-70-41, since a number of services contained therein are invoked in support of the operation of OBCPs and their interaction with the ground.

This Standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.

Normative references

The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.

ECSS-S-ST-00-01


ECSS system - Glossary of terms



ECSS-E-ST-40


Space engineering - Software



ECSS-E-ST-70


Space engineering - Ground systems and operations



ECSS-E-ST-70-31


Space engineering - Ground systems and operations - Monitoring and control data definition



ECSS-E-70-41


Space engineering - Ground systems and operations - Telemetry and telecommand packet utilization



Terms, definitions and abbreviated terms

Terms from other standards

For the purpose of this Standard, the terms and definitions from ECSS-ST-00-01, ECSS-E-ST-70, ECSS-E-ST-70-31 and ECSS-E-70-41 apply, in particular for the following terms:

activity

event

event reporting service

ground system

on-board parameter

operations procedure

space project

spacecraft

Terms specific to the present standard

automation
replacement of manual operations by computerized mechanisms

on-board control procedure
software program designed to be executed by an OBCP engine, which can easily be loaded, executed, and also replaced, on-board the spacecraft

Depending on the context, OBCP can refer to an OBCP in program source code form, or in OBCP code.

OBCP code
complete representation of an OBCP, in a form that can be loaded on-board for subsequent execution

  • 1    In previous missions, such code is typically referred to as token code, executable code or bytecode depending on the implementation of the relevant OBCP engine.
  • 2    In service 18 of ECSS-E-70-41A, OBCP code is referred to as procedure code.
    OBCP engine
    application of the on-board software handling the execution of OBCPs

OBCP operations are initiated by means of ECSS-E-70-41 Service 18 telecommands.

OBCP language
programming language in which OBCP source code is expressed by human programmers

OBCP system
the entire machinery for the creation (in the ground system), uplinking, and on-board handling of OBCPs

OBCP step
sequence of OBCP source code statements constituting the smallest operational unit within an OBCP

on-board software
software hosted and executed by any programmable on-board computer or processor

scheduling
controlling the allocation of OBSW processor (CPU) time for execution of the various OBSW functions, according to a predefined algorithm

OBSW functions include the OBCP engine and execution of OBCPs.

survival mode
configuration of a spacecraft in which it can remain safely without ground segment intervention for a specified period

Survival mode is also commonly known as safe mode. In survival mode, typically all non-essential on-board units or subsystems are powered off, either to conserve power or to avoid interference with other subsystems, and the spacecraft can be (automatically) oriented to a particular attitude with respect to the sun.

Abbreviated terms

The following abbreviations are defined and used within this standard:

The OBCP concept

Introduction

The OBCP concept is that of a procedure to be executed on-board, which can easily be loaded, executed, and also replaced, on-board the spacecraft without modifying the remainder of the on-board software.

Stakeholders and application areas for OBCPs

Stakeholders

Several categories of OBCP stakeholder are identified, each of whom has a distinct role in a space project, with corresponding responsibilities:

System engineers (spacecraft and payload);

On-board software engineers;

AIT engineers;

Operations engineers.

There is continuous interaction and cooperation between these stakeholders throughout the development and operation lifecycle of a space system, for example:

during the spacecraft design phase, operations engineers are involved to ensure the operability of the overall space system;

during in-orbit operations, system and software engineers support commissioning and troubleshooting activities. The system or software responsibility may be transferred from the satellite prime contractor to the operations organization at some predetermined time after launch (e.g. in the case of long-duration missions).

The potential uses for OBCPs are therefore categorized in clause 4.2.2 according to the domain of application rather than stakeholder category.

Domains of OBCP application

System design

Typical scenarios where it may be decided to implement on-board functionality as OBCPs rather than as OBSW include:

Platform functions

To isolate mission-specific platform functions from the remainder of the OBSW, e.g. thermal control or battery control.

To implement one-shot applications that are deleted after use, e.g. deployment of appendices, firing of pyrotechnics.

To accommodate the late specification of the detailed FDIR strategy and to facilitate the tuning of this strategy during system testing.

It is not the intention to encourage the late definition of the FDIR strategy, but rather to accommodate the reality that the detailed strategy is often late. The decision about whether or not to use OBCPs for FDIR purposes is part of the trade-off addressed in detail in clause 6.

To accommodate the late delivery of, or the subsequent removal, addition or replacement of equipment.

To facilitate the tuning of on-board configuration sequences for complex equipment or subsystems following system testing, i.e. these sequences are modified directly avoiding the delays inherent in OBSW modification.

Payload functions

To accommodate the late definition and tuning of:

complex payload configuration or control sequences;

monitoring algorithms and recovery actions.

On-board software design and development

The benefits of implementing traditional OBSW functions as OBCPs include:

the relative ease of development and validation of OBCPs vs. OBSW;

the core OBSW can be made more generic and is hence potentially reusable across many missions, if mission-specific functions are implemented as OBCPs;

simplification of the OBSW maintenance task, i.e. changes to OBCPs can be easily and safely performed without changing the core OBSW.

OBCPs can also be written by OBSW engineers for their own needs, such as:

automation of tests;

investigation and debugging purposes;

the implementation of short-term workaround solutions for system or software problems without the need to wait for a new software delivery.

AIT

OBCPs are useful tools for AIT engineers for testing and validation purposes during the AIT programme on-ground (i.e. not for in-flight use), for example:

to perform fault injection for robustness testing, especially scenarios that are not feasible with traditional means (e.g. telemetry and telecommand, observation and stimulus);

to implement long and complex configuration sequences for well-defined and repetitive scenarios;

to develop temporary functions of the OBSW for testing purposes.

Operations and operability

The availability of OBCPs enables operations procedures (both for routine functions and contingency operations) to be executed on-board as an alternative to on the ground (either under manual control or automated in the mission control system). This can streamline the operations (reduction of bandwidth, potential reduction in operations manpower, reduction in the loop delay inherent in ground control, simplification of ground procedures) as well as increasing their overall reliability. The use of OBCPs also enhances the on-board autonomy capabilities and increases the robustness to ground station outages. This applies both where there is continuous visibility from ground (e.g. geostationary missions) and where ground station coverage is discontinuous (e.g. LEO and deep-space missions).

In addition, the use of OBCPs facilitates the adaptation to prevailing mission conditions, e.g.:

the implementation of on-board solutions to counteract unforeseen failures occurring in orbit;

unpredictable environment, which can be encountered in deep-space missions;

the implementation of end-of-life operations (e.g. deorbiting).

Types of OBCP

From the potential application of OBCPs described in clause 4.2.2, two types of OBCP can be distinguished:

“On-board Application Procedures (OBAP)” which implement part of the basic functionality of the spacecraft, i.e. which are an integral part of the spacecraft design. The overall qualification of the spacecraft requires the integration of the complete set of OBAPs. Historically, this type of OBCP has been called “Application Program” or “Flight Application Program”.

However, although the set of OBAPs is qualified as part of the spacecraft design, this does not imply that they are not maintained (i.e. possibly updated) after launch.

“On-Board Operations Procedures (OBOP)” that are used to “operate” the spacecraft, but which are not involved in the qualification of the spacecraft.
Whilst both types of OBCP may use essentially the same on-board capabilities and may even be similar in complexity:

There are major differences in how the two types are accommodated on-board in terms of resource allocation, scheduling and accessible services (see clause 5.4.4.5, for example).
The very nature of OBAPs requires that they undergo the same engineering processes as any other integral part of the spacecraft design.
In particular, the lifecycle of an OBAP is intimately tied to that of the spacecraft system (as well as any specific platform subsystem or payload to which it relates), in terms of engineering processes and reviews. The lifecycle of an OBOP, on the other hand, is more akin to that of a ground operations procedure.

The engineering processes for OBAPs and OBOPs and the corresponding requirements are elaborated in clause 6 of this Standard.

The OBCP system

The OBCP system that supports the stakeholder activities consists of an OBCP preparation environment located on the ground and an OBCP execution environment that is located partly on ground and partly on-board (see Figure 41).

Image Figure 41 The OBCP system

The OBCP preparation environment is part of the overall test and operations preparation environment and includes:

editors to support the scripting of OBCPs;

execution constraint checking functions (e.g. resource utilization);

consistency checking functions (e.g. compliance with telemetry and telecommand database definitions);

OBCP configuration management;

OBCP code production;

OBCPs exist in two forms: the OBCP script used to define the OBCP and the OBCP code for on-board execution. No assumption is made in this Standard about whether these two forms are the same or whether a transformation (e.g. compilation, pseudo-code generation) is applied to the script to generate the code.

OBCP validation tools e.g. a simulation environment.

The requirements for the OBCP preparation environment are contained in clause 5.3 of this Standard.

In accordance with ECSS-E-ST-10, all space system data is maintained within a repository called the engineering data repository. As defined in ECSS-E-ST-70-31, the monitoring and control component of the engineering data repository includes the definitions of system elements (corresponding to the hierarchical decomposition of the space system), activities (e.g. telecommands, ground procedures and OBCPs), reporting data (e.g. telemetry parameters) and events (occurrences of predefined conditions that can be used to trigger monitoring and control functions). The engineering data repository is therefore the repository for OBCPs that are developed and validated in the OBCP preparation environment and is also the repository from which they are accessed later by the execution environment. The configuration management of OBCPs is handled by the generic configuration management function of the engineering data repository and is not addressed further within this Standard.

The OBCP execution environment is part of the overall test and operations monitoring and control environment and includes:

A ground part with:

dedicated services for uplinking OBCPs, monitoring and controlling their execution;

the means to visualize the on-board execution environment (including the status of the on-board OBCPs);

constraint and consistency checking functions.

An on-board part with:

one or more OBCP engines which:

provide monitoring and control services for interfacing with the ground or onboard services;

provide standard services for interaction with other on-board systems (on-board software, platform subsystems and payloads);

manage the execution of OBCPs.

(optionally) one or more OBCP stores for the intermediate storage of OBCPs prior to loading to an OBCP engine for execution. The mechanisms for transferring the OBCP from ground to an on-board store and the management of OBCPs within on-board stores are outside the scope of this Standard.

The OBCP engine and the OBCP preparation environment are designed and developed as an integrated system and the partitioning of capabilities between them may vary from project to project.

This Standard assumes that, if there are multiple OBCP engines, they are independent of each other.

The requirements for the OBCP execution environment are contained in clause 5.4 of this Standard.

OBCP system capabilities

OBCP structure

Each OBCP shall have a unique “OBCP Identifier”, which is assigned by the ground system.
It shall be possible to define “arguments” for an OBCP i.e. parameters whose values are input to the OBCP at initiation time.

The definition of arguments, including data type, default value, maximum/minimum range of value, is covered by ECSS-E-ST-70-31, clause 6.7.1.2.

An OBCP shall consist of the following elements:

  • an optional declaration body which declares and initialises variables and declares local functions that are used internally within the OBCP;
  • an optional preconditions body which ensures that the OBCP main body is executed only if (or when) predefined initial conditions are satisfied;
  • a mandatory main body which fulfils the goal of the OBCP;
  • an optional confirmation body which verifies the conditions that determine whether the goal of the OBCP is met;
  • an optional contingency handling body that manages anomalies detected during the execution of the OBCP. The nominal execution sequence for an OBCP shall be:
  • declaration body;
  • preconditions body;
  • main body;
  • confirmation body. A step construct shall be provided to identify a block of functionally self-contained statements.
    Steps shall be uniquely identified within the context of an OBCP.
    The result generated by the confirmation body shall be used by the OBCP engine to determine the confirmation status of the OBCP.
    In the case that there is no confirmation body, an implicit confirmation status shall be set by the OBCP engine.

For example, if all activities initiated by the OBCP were successful and no exception has been detected, then the OBCP confirmation status could be set to “success”.

A “local function” construct shall be provided to encapsulate a self-contained sequence of statements which accepts input parameters and returns output parameters.
It shall be possible to initiate the execution of a local function from anywhere within an OBCP.

OBCP language capabilities

Introduction

The OBCP language enables the end-user to define the script of the OBCP, making reference as appropriate to system elements, activities, reporting data and events that are fully-defined within the engineering data repository. In the remainder of this clause, the capabilities of the language are organised as follows:

data types;

OBCP-internal declarations;

assignments;

expressions;

flow controls;

waits;

external interactions;

contingency handling.

General

The syntax of the OBCP language shall be formally specified.

For example, using the ISO extended Backus-Naur form (EBNF), see ISO/IEC 14977.

It shall be possible to include comments in every line of source code.

Data types

The OBCP language shall support the simple data types specified in clause 5.5 of ECSS-E-ST-70-31.
The OBCP language shall support the definition of structured data types i.e. arrays and records.
The OBCP language shall support explicit type-casting constructs.

This does not preclude that some implicit type-conversions are also supported.

Declarations

It shall be possible to declare variables of any data type, including their initialisation values.
It shall be possible to declare constants of any data type including their values.
It shall be possible to declare and define local functions.
A local function shall be uniquely identified within the context of an OBCP.

Assignments

It shall be possible to assign a value to a variable.

A variable, defined within the OBCP declaration body, is visible anywhere within the OBCP, including within a local function.

Expressions

Mathematical, time, string and bitwise operations and functions shall be supported.
It shall be possible to manipulate arrays, including operations on the elements of arrays.
It shall be possible to construct expressions that operate on constants, on-board parameters, activity arguments and variables.
It shall be possible to refer to constants together with their engineering units.
It shall be possible to mix compatible engineering units freely within an expression.
The automatic conversion between different, but compatible, engineering units shall be supported.
It shall be possible to refer to on-board parameters by their names as defined in the engineering data repository.
It shall be possible to express on-board parameter values in engineering units.
It shall be possible to express on-board parameter values in the raw form that is downlinked to the ground system.
It shall be possible to refer to events, and their associated parameters, by their names as defined in the engineering data repository.

Flow controls

It shall be possible to include the following execution controls within an OBCP:

  • simple conditional branching (i.e. if … then … else …);
  • multiple conditional branching where the path taken is dependent on the value of a specified parameter (or variable);
  • repeated execution of a statement (or a group of statements) with the possibility of repeating the execution a specified number of times, repeating the execution indefinitely whilst a given condition holds true or repeating the execution until a given condition becomes true. It shall be possible to nest execution control constructs.

Waits

It shall be possible to specify the following types of wait statement within the main body of an OBCP:

  • wait until a given on-board time;
  • wait for a given interval of time to elapse;
  • wait until a given condition becomes true;
  • wait until a given event occurs;
  • wait until any event from a specified list of events occurs. It shall be possible to specify a combination of conditions within a wait statement.
    The conditions specified for an OBCP precondition or confirmation shall be any combination of the following:
  • wait until a given absolute time;
  • wait for a given interval of time to elapse;
  • wait until a given condition becomes true;
  • wait until a given event occurs;
  • wait until any event from a specified list of events occurs;
  • test whether a given condition is true. It shall be possible to define timeout conditions for wait statements and the behaviour if the timeout is exceeded.

External interactions

Acquiring and setting the values of on-board parameters

It shall be possible to acquire the value of an on-board parameter including the on-board time.
It shall be possible to set the value of specific on-board parameters.

The following are examples:
  • Housekeeping parameters that are subsequently reported to ground.
  • Parameters used to retain information between successive executions of a given OBCP.
  • Parameters to be subsequently accessed by an on-board monitoring function.

Initiating activities

It shall be possible to refer to activities, and their associated arguments, by their names as defined in the engineering data repository.
It shall be possible to request the execution of any on-board activity accessible from ground, unless explicitly excluded.

For example, command pulse distribution unit (CPDU) telecommands can be excluded if they can only be sent from ground.

It shall be possible to indicate explicitly, for each activity, which stages of execution verification to report.
It shall be possible to acquire the execution status of an initiated activity.
It shall be possible to acquire the confirmation status of an initiated activity.

The confirmation status is acquired at the completion of execution and reflects the success or failure of the activity.

It shall be possible to acquire the initiation time, start time, termination time or completion time of the last execution of an activity.
It shall be possible to request the execution of an activity and proceed immediately with the execution of the next statement of the procedure.

This implies that more than one initiated activity can be executing in parallel.

It shall be possible to request the execution of an activity and wait for a given execution status or confirmation status to be tested in order to determine the subsequent course of action.
It shall be possible to request the execution of an activity and proceed without waiting for its completion.
If verification of the execution of activities has been requested, the OBCP shall not complete execution until verification reporting is complete.
Where an OBCP waits for activity verification, it shall be possible to define a timeout.
Within an OBAP, it shall be possible to request the execution of specific on-board activities not accessible from ground.

For example, low-level commands such as on-board bus access.

Raising and accessing events

It shall be possible to raise events with associated parameters.

Only an existing “system event” can be raised in this way i.e. it is not possible for an OBCP to declare and raise a “new” event.

It shall be possible to access events raised on-board together with their associated parameters.

Contingency handling

It shall be possible to define one or more contingency handling routines that are triggered by the occurrence of one or more conditions or events.

For example, resource being exceeded, parameter out-of-limits.

The OBCP preparation environment

OBCP script preparation

An editor (read and write) shall be provided for preparing OBCPs.
A viewer (read only) shall be provided for visualising OBCPs.
It shall be possible to collapse and expand the view of an OBCP, either globally or locally at the level of a step.
The script preparation environment shall be fully integrated with the engineering data repository, such that an OBCP can be populated with database objects that are selected from context-sensitive menus.

For example, only showing system elements, activities, reporting data and events belonging to the parent system element of the OBCP.

It shall be possible to override any default values contained in the engineering data repository.

For example, to specify a different activity verification profile from the default profile contained in the engineering data repository.

Syntax analysis, consistency, dependency and constraint checking

A syntax analyzer, consistency, dependency and constraint checker shall be provided that verifies and reports on:

  • the compliance of the OBCP script with the language grammar;
  • the consistency of the OBCP script with the current content of the engineering data repository;
  • inter-OBCP dependencies such as execution calls;
  • compliance with the constraints defined for the given OBCP.
  • 1    For example, constraints can include: the available OBCP engine services, on-board resources such as memory usage, maximum size of the OBCP code, CPU usage, maximum frequency of on-board parameter sampling requests or activity invocations.
  • 2    Different constraints may apply to all OBCPs, to OBOPs or OBAPs only or to defined sets of OBOPs or OBAPs.
  • 3    Different constraints may apply to different OBCP engines.

Report generation

It shall be possible to generate a report for an OBCP, containing at least:

  • a summary of referenced engineering data repository objects i.e. activities (including (OBCPs), parameters and events;
  • consumption of on-board CPU and memory;
  • prerequisites for execution;
  • script quality measures.

For example, nesting level, number of loops and other measures as defined in ECSS-Q-ST-80, clause 7.1.

It shall be possible to generate a report containing the activity call tree of all OBCPs, i.e. a tree showing all calling and called activities.

Verification and validation

A debugging facility should be provided that supports:

  • execution of OBCPs on a step-by-step basis;
  • execution of OBCPs on a statement-by-statement basis;
  • “step over”, “step into” and “step out of” statements;
  • forcing of a given execution path within an OBCP;
  • setting and visualisation of values for internal and external data;
  • stimulation of events;
  • simulation of the execution of an activity invoked by an OBCP, including the simulation of execution responses;
  • simulation of any interaction with the execution environment that can be experienced during the real execution of the OBCP;

For example, control operations such as suspend and resume).
  • creation of breakpoints from which the subsequent execution of an OBCP can be resumed.

Storing of a breakpoint includes storing of all relevant context data.

A flight representative verification and validation environment shall be provided to verify and validate OBCPs prior to their operational use.

The required level of fidelity can be higher for OBAPs than for OBOPs. For example, OBAPs can require the use of on-board hardware in the loop.

Test coverage analysis tools shall be provided covering code, branch and decision coverage, including the identification of missing coverage in accordance with the selected OBCP engineering process (see clause 6.3).

OBCP characterisation

Memory predictability

Dynamic and static memory requirements shall be predictable at procedure preparation time.

  • 1    Static memory requirements can be known at generation stage and monitored on-board, commonly split between mass memory (on-board store) and local RAM.
  • 2    Dynamic memory allocation includes stack allocation and stack saving (and persistence between executions).

Time predictability

It shall be possible to predict the upper boundary of the execution duration of an OBCP.

Observability

The OBCP engine shall provide observability of OBCP-related run time events and OBCP data.

For example, branching events.

It shall be possible to define levels of observability for OBCPs.
It shall be possible to select the level of observability for a given OBCP.

The OBCP execution environment

Ground capabilities

Prior to initiating OBCP operations, the ground system shall ensure that the following conditions are respected:

  • Compliance with the allowed state transitions for an OBCP.

For example, an “Activate OBCP” request is only allowed if the OBCP is already loaded in the OBCP engine and not currently “Active”.
  • Interdependencies between OBCPs.

For example, when a given OBCP is to be activated, ensure that all OBCPs callable from that OBCP are already loaded or scheduled for loading before their calling time.
  • Compliance with resources separately allocated to OBAPs and OBOPs.

For example, the maximum number of OBCPs concurrently loaded or concurrently active, CPU usage, memory usage.

The ground system shall uplink OBCPs to the spacecraft by telecommand in the form of OBCP code suitable for loading to the relevant OBCP engine.
Telecommand protocols for ground control of the management and operation of OBCPs on-board shall be based on the ECSS-E-70-41 on-board operations procedure service.

The ECSS-E-70-41 memory management service is only used to support OBSW or OBCP anomaly investigations, and in exceptional cases when the use of other ECSS-E-70-41 services is no longer possible due to on-board failures.

OBCP monitoring and control

Introduction

Figure 51 shows the different states through which an OBCP can pass and the transitions that are allowed between these states.

Image Figure 51: OBCP state diagram

Although the concept of on-board store and associated transitions are introduced in Figure 51, this Standard does not prescribe the implementation of on-board stores.

OBCP execution states

The following OBCP execution states shall be supported:

  • in store i.e. the OBCP is in the executable form, stored either on-board or on-ground.
  • in engine i.e. the OBCP is in an on-board memory accessible by the OBCP engine:
    • inactive i.e. the OBCP is idle;
    • active i.e. the OBCP is under control of the OBCP engine:
      running i.e. the OBCP is executing;held i.e. the OBCP execution has been placed on hold.#### OBCP operations and reporting

The OBCP engine shall be able to perform the following operations on OBCPs, in response to requests by telecommand from the ground system or from on-board processes:

  • Load i.e. request the OBCP engine to load the OBCP into the OBCP engine (transition from “in store” to “in engine: inactive”).

This is ECSS-E-70-41 service 18, subtype 1.
  • Activate i.e. request the OBCP engine to initiate the execution of the OBCP (transition from “inactive” to “active: running”).

This is ECSS-E-70-41 service 18, subtype 3.
  • Communicate Parameters i.e. request the OBCP engine to communicate parameters to an active OBCP.

This is ECSS-E-70-41 service 18, subtype 7.
  • Suspend i.e. request the OBCP engine to suspend the execution of a running OBCP at the end of the current statement or at the end of a specified step (transition from “active: running” to “active: held”).

This is ECSS-E-70-41 service 18, subtype 5.
  • Resume i.e. request the OBCP engine to resume a suspended OBCP from the point where it was suspended (transition from “active: held” to “active: running”).

This is ECSS-E-70-41 service 18, subtype 6.
  • Stop i.e. request the OBCP engine to stop execution of a running OBCP at the end of the current statement or at the end of a specified step, or a held OBCP (transition from “active” to “inactive”).
  • 1    This is ECSS-E-70-41 service 18, subtype 4.
  • 2    Execution of the OBCP cannot be resumed subsequently from that point.
  • Abort i.e. request the OBCP engine to stop immediately the execution of an active OBCP (transition from “active” to “inactive”).

This is ECSS-E-70-41 service 18, subtype 12.
  • Delete i.e. request the OBCP engine to remove an inactive OBCP from the OBCP engine (transition from “inactive” to “in store”).

This is ECSS-E-70-41 service 18, subtype 2.

If the OBCP engine receives a request that is not consistent with the current state of an OBCP, it shall fail the request and generate a telecommand verification failure.

For example, an Activate request for an already active OBCP.

At the end of its execution, the OBCP shall return autonomously to the “inactive” state (Transition: “Completion”).
The Activate request shall include any necessary parameters to be passed to the OBCP.
Once loaded to the engine, each OBCP shall remain available for subsequent reactivation until it is deleted from the OBCP engine.
The execution of OBCP requests (Load, Delete, Activate, Communicate Parameters to OBCP, Stop, Suspend, Resume, Abort) shall be reported to the source of the telecommand by means of telecommand verification reports.
The execution of OBCP requests commanded from on-board shall be reported to the ground system by means of event reports, containing the following information:

  • the identity of the source that requested the OBCP operation;

For example, an OBSW application or another OBCP.
  • the OBCP Identifier (object of the request);
  • the execution status of the requested operation. The OBCP engine shall report runtime errors detected during the execution of an OBCP by means of event reports.

OBCP integrity

A checksum associated with the OBCP code shall be loaded along with the OBCP, suitable for the verification of the code independently of any data security check mechanisms provided by the uplink protocol.
The OBCP code checksum shall be generated on the ground by the translation process which originally generates the code from the source language.
The OBCP code checksum shall be verified when the OBCP is loaded to the OBCP engine.
If the checksum verification fails, the OBCP engine shall fail the Load request and generate a telecommand verification failure.
The OBCP code checksum shall be verified whenever a checksum check is requested by ground.

On-board capabilities

General

A given on-board application process shall implement at most one OBCP engine whose function is the execution and associated handling of OBCPs.
The following aspects of the OBSW and the OBCP engine functionality shall be defined:

  • scheduling policy;
  • static and dynamic memory allocation;
  • garbage collection policy;
  • observability and controllability of these functions by the ground system.

OBCP engine services

The OBCP engine shall provide all the services necessary to implement the OBCP language capabilities.

There can be different services (or levels of service) applicable to OBOPs and OBAPs, e.g. OBOPs are only authorized to initiate activities accessible to ground.

The OBCP engine shall provide a “global function service” to OBCPs i.e. a set of standard functions that can be called from any OBCP.

Management of the global functions of an OBCP engine is implementation-dependent e.g. software patch, provision of additional ECSS-E-70-41 service 18 subtypes.

The behaviour of the OBCP engine in the event of a reset of, or discontinuity in, the reference clock on which the wait services of the OBCP engine depend, shall be defined.

OBCP engine monitoring

The following housekeeping information shall be made available for each OBCP present in the OBCP engine:

  • the OBCP execution status;
  • when the OBCP is running, the identification of the step being executed;
  • when the OBCP is suspended, the identification of the next step to be executed.

Configuration of the reporting of housekeeping information is performed using ECSS-E-70-41 service 3.

OBCP engine housekeeping information shall be made available.

Examples are:
  • Available free memory.
  • CPU processing time used by the OBCP engine.
  • I/O slots used.
    All events of operational significance shall be reported to the ground system using the ECSS-E-70-41 event reporting service.
    To support the investigation of anomalies, detailed information shall be made available on the basic functioning of the OBCP engine and loaded OBCPs.
  • 1    Examples are:
  • The management of memory used for the accommodation of OBCPs.
  • The content of the call stack at the time of the anomaly.
  • 2    Requirements for such reporting depend on the design and implementation of the individual OBCP engines and the OBSW.

OBCP loading policy

The OBCP loading policy to be implemented by the OBCP engine shall be defined.

  • 1    A loading policy is only applicable when OBCPs can be held on-board in more than one OBCP store. The policy defines precedence rules which steer the automatic selection of the OBCP store from which the OBCP engine obtains the OBCP code when responding to a Load request.
  • 2    OBCP stores can be implemented in devices of different nature, such as RAM, mass memory unit or EEPROM. A typical loading policy could be: local RAM, platform mass memory (volatile or non-volatile on loss of power), EEPROM (non-volatile).
    The following characteristics of the loading policy shall be defined:
  • whether the loading policy is reprogrammable;
  • how the loading policy is affected by reset or reboot of the OBSW, switch-over to a redundant processor or loss of power to on-board memories. The loading policy shall be definable on a per-OBCP basis.

Process scheduling (OBSW and OBCP engine)

The OBSW scheduling policy for the OBCP engine shall be defined.
A specified minimum allocation of processor time measured across specified regular time intervals shall be guaranteed to the OBCP engine.

There are a number of possible ways to meet these requirements, for example:
  • schedule a fixed CPU time-slot for the OBCP engine at fixed time intervals (simple solution);
  • schedule the OBCP engine in a prioritized scheduling scheme, with pre-emption by higher-criticality OBSW tasks;
  • dedication of a co-processor to the OBCP engine.
    The OBCP engine shall be able to execute several OBCPs in parallel.
    The allocation of on-board resources for running OBOPs shall be independent from the allocation of on-board resources for running OBAPs.

For example, CPU time, memory.

The maximum number of OBOPs (active or inactive) that can be loaded within an OBCP engine at any given time shall be specified.
The maximum number of OBOPs active in an OBCP engine at any given time shall be specified.
The on-board resources allocated to a given OBOP shall be independent of the number of running OBOPs.

As a consequence, the OBOP designer is free to write an OBOP solely to serve its intended monitoring and control purpose without needing to consider the resources utilized by the OBOP.

The rules for the allocation and utilisation of available resources to concurrently executing OBAPs shall be defined.

This covers in particular the definition of a priority scheme for OBAP scheduling.

Isolation of OBCPs

The OBCP engine shall ensure that internal faults and errors do not propagate to the OBSW.

This concerns faults that affect the CPU and memory resources provided by the OBCP engine to the OBCP and faults that affect the OBCP engine function itself. For example, an incorrect value written to an onboard parameter is excluded.

The OBCP engine shall ensure that it does not exceed its maximum allocated resources.
The operations of loading, activation and control of an OBCP shall not impact the operations of already active OBCPs.
The OBCP engine shall isolate OBCPs from each other in terms of fault and error propagation.
The OBCP engine shall prevent OBCPs from accessing unauthorised memory space.

Exception handling

Any OBCP-internal error situation arising during execution shall be detected either by an OBCP-internal exception handler or by the OBCP engine.

Examples are:
  • Overflow conditions and divide-by-zero when performing arithmetic operations
  • Operations accessing arrays outside their declared boundaries.
    The OBCP engine shall abort the execution of an OBCP following detection of an OBCP-internal error that is not handled by the OBCP exception handler.
    An anomaly event for reporting to the ground system shall be generated on the occurrence of any OBCP-internal error.
    A run-time error during execution of any OBCP exception handler shall result in immediate termination of the OBCP.
    Where the conditions required for the execution of running OBCPs can no longer be provided by the OBCP engine, the actions to be taken shall be defined.

An example set of actions could be:
  • the OBCP engine raises an event that can be caught by specific contingency handlers within running OBCPs. Such contingency handlers could establish a default state for all devices being controlled by the OBCPs.
  • all running OBCPs are suspended;
  • a report is issued to ground.

Continuity of service

The concept for ensuring continuity of service shall be defined.

Providing for continuity of service can imply a need to define requirements for preservation of OBCP state information in non-volatile on-board memory.

It shall be possible to specify the list of OBCPs to be automatically loaded and activated within the OBCP engine at OBCP engine initialisation.

Engine initialization is defined as the actions to be performed by the OBCP engine following engine start-up and finishing when the engine is ready to accept an external command.

OBCP engineering processes

Introduction

The OBCP concept enables a level of decoupling between the OBCP development and spacecraft lifecycles, as illustrated in Figure 61:

The OBOP lifecycle is fully decoupled from the spacecraft system and consequently, from the OBSW, e.g. OBOPs can be defined after launch without the need for system delta-qualification.

The OBAP lifecycle is partly decoupled from the OBSW but still tightly linked to the system development process, e.g. OBAPs are qualified as part of the system.

The engineering process required for any OBCP is determined by the level of isolation provided by the OBCP system i.e.:

The extent to which the capabilities of the system are protected against propagation of functional failures induced by the OBCP.

The extent to which the capabilities of the system are protected against propagation of software failures induced by the OBCP.

Finally, the development process is also influenced by quality considerations and development risk assessment. Special attention should be paid to "critical" OBCPs (OBAPs or OBOPs) in terms of margins and potential impact on the spacecraft and the mission.

Image Figure 61: Lifecycles of OBCPs originating from the different domains

Overall management process of the OBCP system

Management process

The OBCP system management process (see Figure 62) shall be defined and documented.
The OBCP system management process shall include the following activities:

  • collection of needs from the various stakeholders (see clause 4.2);
  • trade-off analysis between implementing the needs as OBSW or as OBAP (see clause 6.2.2);
  • analysis of the use case inputs for future OBOP needs (see clause 6.2.3) and expected benefits in terms of engineering effort (see clause 6.2.4) and assignment of requirements to the on-board system and to the ground system. The output of the OBCP system management process shall be the consolidation of the required capabilities of the OBCP engine, the preparation environment, the ground execution environment and engineering processes.
    All the requirements shall be traceable either to the OBCP engine, the preparation environment, the ground execution environment or engineering processes.
    The output of the OBCP system management process shall be reviewed during the system requirements review (SRR), see Figure 63.

The list of criteria and the weights of individual criteria which drive the trade-off analysis for OBCPs (see clauses 6.2.2 and 6.2.3) may vary according to the project phase. Before the SRR, flexibility is much higher than during system development or during the in-orbit life.

The capabilities of the OBCP engine and the preparation environment shall be defined and frozen at the software PDR, see Figure 63.

The trade-off between implementation of one single OBCP engine or several OBCP engines is performed as part of the OBSW engineering process.

The resource allocation, monitoring and consolidation of budgets shall be managed at system level and reviewed during system and OBSW reviews.

Examples of budgets are: number of OBCPs executing in parallel, number of activities invoked by an OBCP.

OBAP validation and verification shall be completed prior to system qualification, see Figure 63.
Image Figure 62: OBCP management overview

Image Figure 63: Synchronisation of OBAP lifecycles with system and OBSW lifecycles

OBAP vs. OBSW: criteria and trade-off analysis

The OBAP vs. OBSW trade-off shall be conducted according to a predefined set of criteria.
The justification for the trade-off decisions shall be documented.

The following criteria are typically used in making the trade-off between OBSW and OBAP:
  • Major capabilities and advantages afforded by the use of OBAPs:
  • Variability and flexibility, for example, due to changing mission requirements or system ageing.
  • Programmatic, e.g. late definition, reuse. However late selection of OBAPs to develop OBSW functions has the disadvantage of concentrating the validation effort into a short and critical period.
  • Major capabilities and advantages afforded by the use of OBSW:
  • Real-time capabilities.
  • Execution time (but this depends on the technology).
  • Suitability for implementation of complex functions (i.e. suitability of the software engineering process and techniques).
  • Suitability for implementing the core system management functions that have stable requirements and a close relationship with subsystem engineering (e.g. AOCS).
  • Suitability for implementing those functions required to sustain survival modes of the spacecraft in view of the need to be fully (extensively) validated by the end of the development phase.
  • Suitability for implementing the generic part of a system or of a family of systems (software product lines, reuse of components such as those supporting ECSS-E-70-41 standard services).
  • Reduction of schedule risks by requiring that on-board functionality is defined early in the spacecraft development programme.

OBOP vs. ground-based operations

When analysing the use cases for potential OBOP development, a trade-off between implementing the identified use cases on-board or by means of ground-based operations procedures shall be performed.

The decision process can be supported by the following criteria:
  • Major capabilities and advantages afforded by the OBOP concept:
  • Enable spacecraft operations during phases of non-visibility and/or with long signal propagation delays.
  • Improve security in the operations in case of loss of ground control.
  • Reduce operator errors.
  • Synchronise operations with asynchronous elements (e.g. on-board events).
  • “Coded and up-linked once, used many times”.
  • Combine “atomic” operations within a single operation (e.g. define critical activities to be performed in one block).
  • Decrease the need for round-the-clock human availability during the routine phase.
  • Major capabilities and advantages afforded by using ground-based procedures (potentially supported by automated ground tools):
  • Human response to unforeseen scenarios.
  • Decrease the capabilities required from the on-board system.
  • Decrease validation of the required on-board capabilities.
  • Engineering effort to develop and validate a ground-based procedure is less than required for an OBOP.
  • Less effort to update a procedure.
  • Less complex configuration management system.
  • Increased overall visibility of operations.

Trade-off between OBCP engine capability and engineering effort

When analysing the required OBCP engine capabilities (robustness w.r.t. failure propagation), a trade-off between implementing the required capability on-board or not, thereby increasing the engineering effort (validation), shall be performed.

  • 1    For OBAPs, isolation may be relaxed in order to simplify the OBCP engine. This is acceptable because of the increased validation effort.
  • 2    For OBOPs, a higher level of isolation is mandatory.

Overall organization and management

All the stakeholders shall be identified together with appropriate organisation and responsibilities and associated interactions between various teams (see clause 4.2).
Each category of stakeholder (see clause 4.2) shall be responsible for the overall development and validation of their own set of OBCPs.

For OBAPs, close collaboration between all interested parties is needed throughout the development lifecycle.

OBOP execution decisions shall be approved by one single authority in order to ensure compatibility with system constraints and consistency between OBOPs.

  • 1    Examples are:
  • Check that the maximum number of running OBOPs is not violated.
  • Check that no two OBOPs are accessing concurrently the same hardware resource.
  • 2    This does not preclude splitting OBOPs into different sets, with their development assigned to different teams, working to different schedules.
    Policies and procedures for the allocation of resources between stakeholders shall be established.
  • 1    For OBOPs this could be implemented by assignment of a maximum number of OBOPs per stakeholder category (including margin).
  • 2    For OBAPs this could be implemented by assignment of CPU and memory.
    A process shall be defined to ensure the enforcement of the resource allocation policies throughout the project lifetime.

OBCP engineering

The engineering process for OBOPs and for OBAPs shall be defined and documented.
For OBAPs, the usual software lifecycle process with requirements, design and coding phases shall be applied in accordance with ECSS-E-ST-40.
When tailoring ECSS-E-ST-40,, the following shall be ensured:

  • An adequate level of documentation and reviews.
  • Strict configuration control of the OBAPs.
  • An adequate level of validation effort and formalism. For OBOPs, the usual operations procedure engineering process shall be applied in accordance with ECSS-E-ST-70.
    When tailoring ECSS-E-ST-70, the following shall be ensured:
  • Timely documented feedback from operation engineers to the OBOP developers.
  • Concurrent maintenance of OBOP documentation.
  • Strict configuration control of the OBOPs both by developers and by test engineers.

Bibliography

ECSS-S-ST-00


ECSS system – Description, implementation and general requirements


ECSS-E-ST-10


Space engineering – System engineering general requirements


ECSS-Q-ST-80


Space product assurance – Software product assurance


ISO/IEC 14977:1996


Information Technology - Syntactic Metalanguage - Extended BNF - First Edition