Space engineering

Space segment operability

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-11 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, ,
    2200 AG Noordwijk
    The
Copyright:     2008 © by the European Space Agency for the members of ECSS

Change log

ECSS-E-70-11A

5 August 2005

First issue

ECSS-E-70-11B

Never issued

ECSS-E-ST-70-11C

31 July 2008

Second issue

Editorial changes to conform to the ECSS template, including renumbering of the requirements

Introduction

The operability of the space segment has an impact on total life cycle cost inasmuch as increased operability can increase development costs, but certainly decreases operations and maintenance costs. Therefore, the adoption of specific operability goals for a given mission is decided by careful balancing of costs, risks, and schedules for both the development and the operations and maintenance phases.

The objective of this standard is to define operability requirements that:

ensure that the space segment can be operated in a safe and costeffective manner;

facilitate the tasks of preparation for, and execution and evaluation of, space segment checkout and mission operations activities;

facilitate the tasks of space segment suppliers when preparing a proposal in response to a request for proposal (RFP).

Scope

This Standard contains provisions for the design of onboard functions for unmanned space segments in order to ensure that the space segment can be operated inflight in any nominal or predefined contingency situation.

The requirements in this Standard are grouped in two clauses, containing general operability requirements and detailed operability requirements, respectively. The general operability requirements can be applied to all missions, whilst the detailed operability requirements are only applicable if the corresponding onboard function is implemented.

The operability of the space segment to meet missionspecific requirements is outside the scope of this standard.

To support the users of this Standard in tailoring the requirements to the needs of their particular mission, Annex B contains a table that indicates, for each requirement, the potential impact of its omission.

This standard may be tailored for the specific characteristics 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 revisions 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 most recent editions of the normative documents indicated below. For undated references the latest edition of the publication referred to applies.

ECSSSST00-01	ECSS system – Glossary of terms
ECSSEST-5003	Space engineering – Space data links – Telemetry transfer frame protocol
ECSSEST-5004	Space engineering – Space data links – Telecommand protocols, synchronization and channel coding
ECSSEST7041	Space engineering – 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 ECSSSST0001 apply.

Terms specific to the present standard

Categories of operability
commandability

provision of adequate control functions to configure the onboard systems for the execution of nominal mission operations, failure detection, identification, isolation, diagnosis and recovery, and maintenance operations

compatibility

ability of two or more systems or components to perform their specified functions without interference

deactivation

capability to undertake planned operations to terminate the mission at the end of its useful lifetime

Terminate can mean to deactivate the spacecraft, to deorbit it, or both.

flexibility

capability to configure and make optimum use of existing onboard functions, the capacity of the spaceEarth communications links, and any redundancy built into the design in order to meet the reliability targets

observability

availability to the ground segment and to onboard functions of information on the status, configuration and performance of the space segment

testability

capability to test the onboard functions of the space segment including those that are “offline”

“Offline” means functions that do not form part of the current operational configuration.

Terms pertaining to critical functions
commandable vital function

vital function that is commandable by highpriority commands without the involvement of onboard software

high priority command

pulse command that is routed directly to hardware by means of an onboard command pulse distribution unit (CPDU)

high priority telemetry

telemetry that enables a reliable determination of the current status of vital onboard equipment and which is available under all circumstances

High priority telemetry can be managed by a mechanism that is independent of the one used for standard housekeeping telemetry and normally without any microprocessor involvement.

locallycritical function

function that, when executed in the wrong context (e.g. at the wrong time), can cause temporary or permanent degradation of the associated local functions, but does not compromise higher level functionality

missioncritical function

function that, when executed in the wrong context (e.g. at the wrong time), or wrongly executed, can cause permanent mission degradation

permanent degradation of space segment function

situation where a given onboard function cannot be achieved either on the nominal or on any redundant chain for the remainder of the mission lifetime

permanent mission degradation

situation where space segment functions or performances affecting mission product generation or primary mission objectives cannot be achieved either on the nominal or on any redundant chain for the remainder of the mission lifetime

temporary degradation of space segment function

situation where a given onboard function cannot be achieved either on the nominal or on any redundant chain for a limited period of time

temporary mission degradation

situation where space segment functions or performance affecting mission product generation or primary mission objectives cannot be achieved either on the nominal or on any redundant chain for a limited period of time

For example, a mission outage following transition to survival mode.

vital function

function that is essential to mission success and that can cause permanent mission degradation if not executed when it should be, or wrongly executed, or executed in the wrong context

vital telecommand

telecommand that activates a commandable vital function

Other terms
application process

onboard entity capable of generating telemetry source data and receiving telecommand data

authorization

right of an authenticated entity to perform a function or access a data item or data stream

chain

set of hardware or software units that operate together to achieve a given function

For example, an attitude and orbit control subsystem (AOCS) processor and its software and a set of AOCS sensors and actuators together constitute an AOCS chain.

confidentiality

property that information is not made available or disclosed to unauthorized individuals, entities or processes

control function

mechanism to maintain a parameter or a set of parameters within specified limits

A control function normally consists of a set of measurements and responses (commands) related according to a function, algorithm, or set of rules.

data integrity

property that the data has not been altered or destroyed in an unauthorized manner

data origin authentication

corroboration that the source of the data received is as claimed

datation

attachment of time information to telemetry data

This includes payload measurement data.

device telecommand

telecommand that is routed to and executed by onboard hardware

For example, a relay switching telecommand, a telecommand to load an onboard register.

housekeeping telemetry

telemetry provided for the purposes of monitoring the health and functioning of the space segment

loss of mission

state where the ground segment can no longer control the space segment (e.g. due to loss of contact), or where the space segment can no longer achieve the mission goals (e.g. due to anomalies)

memory

onboard data storage area

1 This includes main memory and storage memory.
2 Examples of memory are disk, tape, and bubblememory.
mode

operational state of a spacecraft, subsystem or payload in which certain functions can be performed

mode transition

transition between two operational modes

onboard autonomy

capability of the space segment to manage nominal or contingency operations without ground segment intervention for a given period of time

onboard monitoring

onboard application of checking functions to a set of onboard parameters in conformance with predefined criteria

Monitoring functions include limitchecking, expectedvaluechecking and deltachecking.

onboard operations procedure

monitoring and control procedure that is stored onboard and whose activation is under ground segment control

onboard operations schedule

onboard facility for storing and releasing telecommands that were loaded in advance from the ground

In its simplest form, the onboard operations schedule stores timetagged telecommands loaded from the ground and releases them to the destination application process when their onboard time is reached.

operability

capability of the space segment to be operated by the ground segment during the complete mission lifetime, whilst optimizing the use of resources and maximizing the quality, quantity, and availability (or timeliness of delivery) of mission products, without compromising space segment safety

operations

activities undertaken by the ground and space segments in order to ensure the timely provision of mission products or services, recover from onboard contingencies, carry out routine maintenance activities and manage onboard resources in order to maximize the provision of mission products or services and the mission lifetime

parameter

lowest level of elementary data item onboard

parameter validity

condition that defines whether the interpretation of a telemetry parameter is reliable and meaningful

The angular output of a gyro only has a valid engineering meaning if the power to the gyro is “on”, while at other times the output is random. Such a parameter is deemed conditionally valid, with its validity determined from the power status.

peerentity authentication

corroboration that a peer entity in an association is the one claimed

safe state

safe condition for a system, subsystem or payload

space segment status

information from which the operational status of the space segment is assessed and the criteria driving operational decisions are determined

survival mode

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

telecommand function

operationally selfcontained control action initiated by telecommand that can comprise or invoke one or more lower level control actions

Abbreviated terms

For the purpose of this Standard, the abbreviated terms from ECSSSST0001 and the following apply:

Abbreviation	Meaning
AOCS	attitude and orbit control subsystem
APID	application process identifier
CPDU	command pulse distribution unit
CPU	central processor unit
CRC	cyclic redundancy check
EEPROM	electrically erasable programmable readonly memory
FDIR	failure detection, isolation and recovery
GPS	global positioning system
I/O	input/output
ID	identifier
MAP	multiplexed access point
OBT	onboard time
RAM	random access memory
RF	radio frequency
RFI	radio frequency interference
RFP	request for proposal
TT&C	telemetry, tracking and command
UTC	universal time coordinated

Conventions

Some requirements introduce quantities for which values cannot be defined across the board, but only on a missionbymission basis (e.g. time intervals or response times). These are termed mission constants and are identified within this Standard in angular brackets.

For example, <TC_VERIF_DELAY>

Example values are indicated in some cases. These mission constants are summarized in Annex A.

General requirements

Introduction

This clause contains general (highlevel) requirements that pertain to the different categories of operability identified in clause 3.2.1. The requirements can be applied to missions of all classes (e.g. science, telecommunications or Earth observation) and orbittype (e.g. geostationary, lowEarth orbiting or interplanetary).

Observability

The space segment shall provide visibility of its internal status, configuration and performance to the ground segment in conformance with the level of detail and the time delays specified for all routine and specified contingency operations, including subsequent diagnostic activities.

1 For detailed operability requirements reflecting these objectives, refer to clause 5.2.
2 Specified contingency operations are derived during the failure analysis performed in the mission development process (e.g. the failure modes, effects and criticality analysis (FMECA).

Commandability

The control functions (telecommands) provided at each level of the system hierarchy shall be capable of achieving the mission objectives under all specified circumstances.

1 This can include the use of redundant equipment to meet the overall system reliability requirements.
2 Detailed operability requirements reflecting these objectives appear in clause 5.5.

Compatibility

The space segment shall conform to all onboard design standards specified for the mission in order to ensure compatibility with the specified ground systems.
The space segment design shall be such that its operation is not constrained by, nor adversely constrains, the availability or capacity of the spaceEarth communications links.

Safety and fault tolerance

No single command function executed at the wrong time or in the wrong configuration shall lead to the loss of the mission.

For a missioncritical command function, this can be ensured by the provision of two independent commands, both to be executed (e.g. ARM and FIRE).

Except for explicitly agreed single point failures, the capability shall be provided to recover all onboard functions after a single failure within a specific function.

The impact of several noncorrelated failures occurring at the same time has to be assessed at missionlevel.

No single unintentional ground command or failure in one space segment element shall cause a failure in another space segment element.
The design of the space segment failure detection, isolation and recovery (FDIR) function shall be such that all anticipated onboard failures can be overcome either by autonomous onboard action or by clear, unambiguous and timely notification of the problem to the ground segment.
The FDIR design shall ensure that the space segment is safe without ground segment intervention for the specified duration in the presence of a single failure.
No reconfiguration of the spacecraft shall lead to a configuration where new single point failures are introduced.

With the exception of reconfigurations that are triggered onboard as the result of genuine failures.

Flexibility

All authorized combinations of prime and redundant equipment shall exhibit the same operational characteristics.

1 This requirement does not prevent a change of calibration data, but it precludes different operational procedures.
2 This does not include any reduced redundancy that exists following a failure.
The capability shall be provided for the ground segment to allocate which of the redundant units are included in the nominal chain and which in the redundant chain.
1 This enables redundancy to be restored without reconfiguring the onboard hardware and also enables a failed unit to be removed from both the nominal and redundant chains while maintaining the rest of the redundancy of the chain.
2 Softwareselectable units, rather than hardware, are more suitable for use where the extent of crossstrapping provided is determined from the reliability analysis.
Any selection of prime or redundant equipment shall be reversible.

This implies that the space segment design supports switching between prime and redundant equipment in both directions.

For each onboard function, there shall be at least one alternative configuration that can achieve the same function using different onboard units.
Onboard functions shall have welldefined inputs and outputs that are accessible from the ground for workaround solutions in case of contingency operations.

Whilst inputs to onboard functions can be modified from the ground (e.g. threshold settings), this does not include the manipulation of onboard measurements.

Onboard storage and buffer areas should be resizable to cater for nonnominal mission events.

There can be operational restrictions on how this is achieved.

The allocation of budgets for onboard resources shall provide the specified spare capacity for each subsystem and each payload.

1 For example, mass memory, power, fuel.
2 This spare capacity is provided in order to ensure flexibility during the mission.
The capability shall be provided to determine, at any point in the mission and with the specified accuracy, the remaining onboard resources that impact on mission lifetime.
1 For example, power, cooling fluid, fuel.
2 The accuracy is specified to be compatible with the mission requirements.

Testability

Each application process shall provide the capability to perform a set of endtoend test functions which can be exercised under ground control.

For example, an “are you alive” function which generates a response for testing the endtoend connection between the ground and an application process.

For test purposes, the capability should be provided to operate redundant onboard equipment in an “offline” manner (i.e. in parallel with, but without any disturbance to, the prime equipment).

This capability can be unfeasible if the redundant unit has an unacceptable disturbing influence such as in the case of a momentum wheel.

The capability should be provided to confirm the health of a currently unused unit prior to operational utilization.

This applies in particular to units that are vital for the health and control of the space segment. The selection of units is to be made on a casebycase basis, taking into account the impact on the space segment design (e.g. the telemetry definition).

The capability shall be provided to load and check redundant memory prior to operational utilization.

Deactivation

Onboard resources shall be provided for configuring the spacecraft into a safe state at the end of its life.

1 This can include deorbiting (essential for LEO spacecraft) or bringing the spacecraft to a graveyard orbit (GEO spacecraft).
2 Safe state means safe for the space environment.
The capability shall be provided to completely deactivate the spacecraft at the end of its life.

This can include the removal of all internal energy sources, e.g. power and fuel.

Detailed requirements

Introduction

Requirements in this clause are grouped according to function, in contrast to Clause 4 where they are grouped according to operability class. It follows therefore that the requirements are only applicable if the corresponding function is actually implemented onboard. Some of these functions correspond to services defined within ECSSEST7041 (the packet utilization standard), which are, by definition, all optional. The services are:

statistical data reporting;

memory management;

function management;

onboard operations scheduling;

onboard monitoring;

large data transfer;

telemetry generation and forwarding;

onboard storage and retrieval;

onboard traffic management;

onboard operations procedures;

eventtoaction coupling.

Missionlevel

Security

The space segment shall be designed such that the following can be ensured:

the integrity of each data stream produced;
the confidentiality of each data stream produced;
the authentication of each telecommand received;
the authorization of each telecommand received. The space segment shall be designed such that continued access to both the telemetry and telecommand transmission functions in the presence of specified external influences outside the control of the mission control team can be ensured.

The external influences to be accommodated are identified during the spacecraft design phase, i.e. at mission analysis level. They generally include RFI and adverse weather conditions. However, other influences, such as meteorite impacts or malicious dazzling of the uplink, clearly cannot be accommodated.

The space segment shall be designed such that the recovery of access to both the telemetry and telecommand transmission functions can be ensured after all specified space and ground segment configuration changes.

Control functions

The design of the overall mission operations system (i.e. constituting both the ground and space segments) shall ensure that control functions that have response times shorter than <GRND_RESP_TIME> are implemented onboard.
Under all circumstances, the elapsed time for an application process to build and release telemetry source packets shall be such that the overall delay between the generation of a packet and its reception at the mission control centre is consistent with the response times <GRND_RESP_TIME> (there can be several such parameters for a given mission) that have been identified for ground control functions.
The frequency of generation of telemetry source packets shall be consistent with <GRND_RESP_TIME>.
The time differences between the release of packets containing data and packets containing ancillary information used for its ground processing shall be such that the effective operational information (i.e. after ground processing) is available within delays consistent with <GRND_RESP_TIME>.

Uplink and downlink

Different downlink bandwidths shall be allocated to different classes of data using physical channels and virtual channels.
The assignment of virtual channels to different data classes shall not be changed during the mission.

Data classes means distinct data streams, such as realtime housekeeping telemetry, science data or playback data rather than different packet types within the same stream.

The allocation of bandwidth to different virtual channels shall be modifiable during the mission.
The capability shall be provided to transmit realtime telemetry data and deferred telemetry data simultaneously.
Requestdriven telemetry source packets (e.g. telecommand verification packets) shall be routed to the originating source of the telecommand.

1 The source can be either the ground or an onboard application process. In the case of telecommands released from an onboard schedule, the source is the ground.
2 Onboard autonomous activities are reported to the ground segment using event report packets.

Telemetry

Telemetry design

Telemetry data shall be provided, as defined for all mission phases, for the ground segment to determine the status of the spacecraft subsystems and payloads and to monitor the execution of nominal and anticipated contingency operations.
The data specified in requirement 5.3.1a shall include sensor readings, register readouts, equipment status (including power status), function status, reports of onboard events and actions taken by autonomous functions, and processor and memory autotest results.
The data specified in requirement 5.3.1a shall be telemetred to the ground segment in a complete, unambiguous, and timely manner.
Eventbased reporting shall be achieved by means of dedicated event report packets (progress or anomaly reports) which are generated onboard, e.g. by a failure detection and recovery function.
The design of event reporting mechanisms and of the event report packets themselves shall be such that the utilization of the downlink bandwidth does not adversely affect the availability of other operational information to the ground segment.
Essential space segment status data shall be derived from direct measurements.

This means that the essential status of the space segment is observable directly from the telemetry without the need for ground processing.

The design of telemetry shall be such that preconditions for the switching of onboard equipment and units are acquired independently, i.e. they are not dependent on the status of the equipment or unit to be switched.

1 To comply with this requirement, power status and thermal data used prior to unit switchon are managed at a higher level.
2 This provides the capability of monitoring and assessing the status of a unit even when it is switched off.
The values of telemetred parameters shall be selfcontained.

This precludes, for instance, the telemetring of deltachanges or status changes.

If operationallysignificant parameters monitored onboard (e.g. pyro currents) can change value at a frequency in excess of the telemetry sampling frequency, the event shall be memorized and the memorized value telemetred.
The resolution and range of analogue telemetry parameters shall be such that monitoring can be performed in all nominal and anticipated contingency situations.
Vital space segment health functions shall be monitored with redundant telemetry parameters (e.g. primary bus current and voltage, and propellant tank pressure).
Telemetry shall be provided to enable detection and diagnosis of any failure identified during the failure analysis phase (e.g. as defined in the FMECA) at least down to function or equipment level.
Where telemetry measurements are processed onboard, the capability shall be provided to downlink the raw data to the ground segment, on request.

For example, AOCS sensor data.

For elements in hot redundancy, telemetry shall be provided to enable an independent and unambiguous evaluation of the status of each chain.
For elements in redundancy, the loss or failure of one chain shall not prevent access to the telemetry of the other chain.
Where parameters are conditionally valid, the parameters determining their validity shall be telemetred with a frequency that is the same as, or higher than, the conditionallyvalid parameter.
Sampling sequences and frequencies shall be specified for all related parameters that are correlated or combined for the purposes of space segment monitoring or performance evaluation to ensure that no information of operational significance is lost.
Where the interpretation of a parameter in a variable packet depends on the values of other onboard parameters, these parameters shall all be telemetred in the same packet.

When the interpretation of a parameter in a variable packet depends on the values of other onboard parameters, the first parameter is a deduced parameter, as defined in ECSSEST7041.

A telemetry parameter shall always have the same structure and interpretation, even if it appears in different telemetry source packets.
The location of a parameter within a nonvariable telemetry source packet shall be fixed and derivable from an implicit knowledge of the packet structure.
The telemetry data at a given position in a telemetry packet shall either correspond to a given physical address onboard or to a given logical address, i.e. a mixture shall not be used.

Physical means that it corresponds to a physical unit onboard, whether or not that unit is being used as prime. Logical means that the telemetry corresponds to the prime unit, which can be either one of two different physical units.

If the same telemetry parameter appears more than once in the same housekeeping telemetry source packet, then the parameter shall be sampled regularly in time.
The design of housekeeping telemetry source packets shall not use subcommutation.

A subcommutated parameter is one that does not appear (at a given location) in each a packet, but only in every nth packet.

The capability shall be provided for the ground segment to define (and redefine) the packet contents for housekeeping telemetry source packets.
The capability shall be provided to request that housekeeping telemetry source packets are only sent to ground segment if there has been a change in value of specified contained parameters by more than a specified threshold.
Within a given virtual channel, telemetry packets originating from the same APID shall always be delivered to the ground segment in the same sequence as they are generated onboard.

This does not apply across separate retrievals from onboard storage, where the original chronological order is not always retained.

Within a given virtual channel, consecutive samples of the same telemetry parameter shall be transmitted to ground segment in chronological order, even if they appear in separate packets.

This does not apply across separate retrievals from onboard storage, where the original chronological order may not be retained.

Diagnostic mode

For anomaly investigation purposes, the capability shall be provided for the ground segment to select a set of telemetry parameters to be sampled at a high rate.
All telemetry parameters shall be accessible in diagnostic mode.
The capability shall be provided to sample a given telemetry parameter at a configurable sampling rate down to a minimum sampling interval of <DIAG_MIN_INTERV>.
The capability shall be provided to record diagnostic mode data onboard for later retrieval by the ground segment.

For example, by using the ECSSEST7041 onboard storage and retrieval service (see clause 5.8.9 for additional information).

Datation and synchronization

Timing information shall be provided in the telemetry such that onboard time and ground time can be correlated with an accuracy of <TIME_CORREL_ACCUR>.

For some missions, OBT/UTC time correlation is performed autonomously onboard (e.g. using GPS). Nevertheless, this requirement specifies the provision of means to check this correlation function on the ground.

Onboard time shall be common to all spacecraft modes, including standby and survival modes.

For space segment modes see clause 5.6.1.

All timing information in the telemetry shall be synchronized with a single onboard reference clock.
When an application process using time synchronization has just been initialized, telemetry shall be provided to notify the ground segment that time synchronization has not yet occurred.
After initialization of an application process using time synchronization, telemetry shall be provided to notify the ground segment when time synchronization has been achieved.
For application processes using time synchronization, telemetry information shall be provided to enable the ground segment to verify synchronization.
No onboard clock shall wraparound during the mission lifetime.
All telemetry source packets should have an onboard generation time in their packet header.

Generation time is the time when the packet is created.

The onboard time, as telemetred to the ground segment, shall not wraparound during the mission lifetime.
No onboard counter telemetred to ground segment shall wrap around within the agreed ground segment nonavailability period.
The capability shall be provided to establish on the ground the time at which parameters of operational significance have actually been sampled onboard to an accuracy of <PARAM_ABS_SAMPL_TIME>.
The capability shall be provided to determine the relative sampling time of any two parameters to an accuracy of <PARAM_REL_SAMPL_TIME>.

This also applies if the parameters appear in different packets, whether housekeeping or scientific in nature.

The onboard sampling time of a telemetry parameter in a nonvariable content telemetry packet shall be derivable from the packet generation time by adding or subtracting an implicitly known time offset.
If the requirements for timing accuracy are expected to vary during the course of a mission, the capability shall be provided to change the rate of generation of the time packet.

Telecommanding

Telecommand design

Telecommands shall be available to command all onboard equipment and functions under all nominal and envisaged contingency conditions.

This implies the provision of a high priority command to reestablish command processing in the event of processor failure.

If a telecommand executes more than one control action, these actions shall be strictly operationally related, such that they constitute a single logical telecommand function.

To comply with this requirement, a device telecommand cannot put a battery in trickle charge and at the same time switch on a heater, unless these operations are always strictly related.

A telecommand packet shall contain one, and only one, telecommand function.

A telecommand that loads or starts an onboard schedule only executes a single function (load or start) irrespective of the number of command functions contained in the load or schedule itself.

Where a given function is invoked by a sequence of two or more telecommands, the capability shall be provided to “pack” such telecommands within a single telecommand packet.
The capability shall be provided to aggregate telecommand packets within the same telecommand segment.

This does not apply to CPDU commands.

A telecommand shall have the same action definition for the complete mission duration.

This precludes the use of flip/flop commands.

The conditions under which a configurationdependent telecommand can be sent (or cannot be sent) shall be determinable unambiguously from the housekeeping telemetry.
The execution of any telecommand shall not lead to permanent loss of the telecommand function.
Repetition of the same telecommand shall not result in any permanent degradation or loss of onboard functionality.
The capability shall be provided to command all onboard devices individually from the ground.

1 If a device is normally commanded using a higherlevel telecommand function, this requirement specifies the capability for the ground segment to issue a device telecommand to be routed directly to that device.
2 This does not imply the use of highpriority commands, but can be achieved using buslevel commands.
Command types shall correspond to the onboard function involved.
1 The adjustment of the level or value of an onboard register or counter by the use of a registerload device command (not by a sequence of on/off commands).
2 The command of an on/off device by an on/off device command (not by a subfunction of a registerload device command).
For redundant onboard units that can only be operated in cold standby (i.e. only one unit can be on at any given time), the equivalent telecommands on the prime and redundant equipment shall be:
identical, and
allocated the same APID. For redundant onboard units that can be operated in parallel (i.e. both units can be operated simultaneously), the equivalent telecommands on the prime and redundant equipment shall be:
identical, and
allocated different APIDs. The maximum execution duration of a telecommand shall be deterministic.

This implies knowledge by the ground segment that a command has been successfully executed so that the next command can be initiated. This does not exclude the possibility that subsequent automated processes with a specified goal (bounded duration) are triggered by a telecommand, so long as the process can be monitored as specified in clause 5.3.1.

Critical telecommands

The capability shall be provided to implement critical command functions using different categories of telecommand.

For example, the use of an onboard operations procedure or the onboard schedule to execute a critical telecommand function that is normally executed from the ground using a CPDU telecommand; the use of lowlevel commands to replace a nominal highlevel function.

At least two separate command actions shall be used for the execution of missioncritical and safetycritical functions.

1 This means an arm/safe or enable/disable command followed by an execute command.
2 See clause 3.2.2 for the definition of telecommand criticality categories.
3 An example where this requirement is applicable, is for commands for pyrotechnic devices.
Register load telecommands that are missioncritical, safetycritical or vital in nature shall have a separate execute command so that the loaded data can be verified prior to execution.
Redundant telecommands shall be provided for all missioncritical and vital telecommands by means of a maximum diversity onboard routing, i.e. using onboard routes that share no common nodes or paths.

This can be achieved by using redundant equipment.

Telecommand transmission and distribution

The capability shall be provided to “interrupt” the transmission of a telecommand packet by the transmission of another telecommand packet of higher priority.
The onboard processing and distribution of telecommands shall ensure that no restrictions arise when the ground segment transmits telecommands of any type at the highest possible rate (i.e. making full use of the available uplink bandwidth).

This includes the case where all commands are of the same type and to the same application process, e.g. a memory load.

Telecommand routing shall ensure that an onboard “blockage” resulting from payload commanding has no impact on platform commanding.

For example, an extensive command sequence for the configuration of a payload, which has no impact on the essential commanding of platform subsystems in parallel.

Where the allocation of onboard routes can be modified (e.g. using a tablebased mapping of APIDs to MAPs), the capability shall be provided to request a report of the onboard routing and status information.
In order to be able to unambiguously identify the source of a telecommand (e.g. the ground or a given onboard application process), the source shall be explicitly indicated within the telecommand packet itself.

The source of telecommands released from an onboard schedule is the ground segment.

Telecommand verification

The capability shall be provided to perform complete and unambiguous verification of welldefined stages of telecommand execution.

This applies to telecommands that are sent directly from the ground or are stored onboard for release at a later time.

The potential stages of telecommand execution that can be verified shall include acceptance, start of execution, progress of execution and completion of execution.

These stages of telecommand execution are defined in ECSSEST7041, clause 4.4.3.

Except for telecommands that are executed purely by hardware (e.g. CPDU commands), verification of the acceptance stage shall be provided for all telecommands.
Verification of execution stages subsequent to acceptance:

need not be performed, and
may be different for individual telecommands. Failure of telecommand execution at any of the identified stages shall either be explicitly reported or unambiguously observable in the housekeeping telemetry.

ECSSEST7041 service 1 can be used for this purpose.

The telecommand packet shall indicate, in its packet data field header, the reports of successful execution to be generated.
The selection possibilities for the reports of successful execution shall range from “no telecommand verification packets” to “verification at each distinct step of acceptance and execution”.
Verification telemetry shall be provided with a delay of less than <TC_VERIF_DELAY> with respect to the time of completion of the corresponding telecommand execution stage.
If a telecommand is invalid, it shall fail verification at the acceptance stage and shall not be distributed further.

For example, the length or CRC are wrong or the APID is invalid.

Failure in the acceptance or the execution of commands originating onboard shall be notified to the ground segment by means of anomaly event reports.
Verification of completion of execution of a telecommand shall use telemetry sampled at the same level as the device or function for which the telecommand is executed.

Examples are:

A device telecommand verified by a hardware measurement that is directly telemetred without intermediate processing.
A bilevel command verified by a status parameter.
If a telecommand results directly in one or more changes to the space segment configuration, these changes shall be reported in the housekeeping telemetry.
The effect of a telecommand shall be observable on the ground using telemetry data available under all circumstances under which the telecommand can be successfully executed.

To comply with this requirement, the effect of a telecommand affecting the status of onboard units involved in the generation or routing of telemetry is available in the “high priority” telemetry.

Register load commands shall be confirmed by unique telemetry parameters dedicated to each commanded register, echoing exactly the currently loaded value.

Configuration management

Modes

For configuration management purposes, the space segment shall be able to support at least the following modes:

“nominal” modes ensuring the generation of mission products;
“standby” modes ensuring safe operation of all spacecraft subsystems and payloads;
“survival” modes ensuring safety of all spacecraft subsystems and payloads. The operational modes of the space segment and its payload, subsystems and units shall be clearly identified in terms of both hardware and software configurations.
The telemetry shall provide unambiguous identification of the modes and mode transitions.
The capability shall be provided to perform payload modeswitching at a highlevel, e.g. by sending a single modeswitching telecommand from the ground which initiates all the corresponding lowlevel commands to bring the payload into the desired mode.
The capability shall be provided to perform all routine maintenance activities for spacecraft units by using nominal modes and mode transitions without impact on the performance of the modes and mode transitions.

Onboard configuration handling

All onboard reconfigurations shall end with an unambiguously known and observable state of all involved elements (hardware and software).
The maximum duration of an onboard reconfiguration shall be deterministic.
Telemetry shall be available for the ground segment to monitor all stages of an onboard reconfiguration.
The reconfiguration of onboard units or the switching between onboard functions shall not affect the status, the configuration, or the proper operation of any other unrelated unit or function.
Telemetry indicating the cause of an onboard reconfiguration shall be available to the ground segment after the completion of the reconfiguration.
The capability shall be provided to preconfigure selected units into consistent configurations prior to their selection as operational.

For example, the bolometer inhibition status of an infrared attitude sensor.

With the exception of highpriority commands, all potentially critical configuration change telecommands initiated by the ground segment shall be buffered onboard in such a way that all parameters defining the new configuration can be inspected by the ground segment, via telemetry, before executing the change onboard.
The capability shall be provided to trigger any onboard reconfiguration activities that put the space segment into a predefined safe state:

autonomously, and
by ground commanding. After separation from the launcher, the space segment shall enter a state in which it can survive for a predefined period without ground segment support.

For example, an automatic sequence triggered on detection of the separation.

The capability shall be provided to configure the timing of the individual actions within onboard sequences by ground commands.
The effect of each individual action within an onboard sequence shall be visible in the telemetry.
The space segment shall provide mechanisms to avoid or recover from any conflict that can arise from the execution of onboard autonomous actions and ground scheduled commands.

For example, the parallel execution of routine procedures and eventdriven procedures.

At power up, restart and upon recovery from any power loss, the space segment electrical configuration (including all subsystems, units and instruments) shall be set into a known deterministic and reproducible state.

Onboard autonomy

Introduction

Onboard autonomy management addresses all aspects of onboard autonomous functions that provide the space segment with the capability to continue mission operations and to survive critical situations without relying on ground segment intervention.

The implementation of onboard autonomy depends on the specific mission requirements and constraints, and can therefore vary between a very low level of autonomy involving a high level of control from ground to a high level of autonomy, whereby most of the functions are performed onboard.

General autonomy

The space segment shall provide onboard autonomy management functions taking into account specific mission constraints and characteristics such as:

acceptable mission outage;
expected ground station coverage;
maximum unexpected ground segment nonavailability period. The onboard autonomy management functions shall be capable of performing all operations to continue mission operations for an autonomy duration of <AUT_DUR_EXEC>.
The onboard autonomy management functions shall be capable of performing all operations to store mission products for an autonomy duration of <AUT_DUR_DATA>.
The onboard autonomy management functions shall be capable of performing all operations to safeguard the space segment for an autonomy duration of <AUT_DUR_FAIL> in the presence of a single failure.

This includes the time used by the ground segment to perform failure diagnosis and full recovery.

The fault management functions implemented onboard shall be designed such that the reaction time for the ground segment is not less than <ANOM_RESP_TIME>.
The ground segment shall be capable of overriding any onboard autonomous function.

Autonomy for execution of nominal mission operations

For the execution of nominal mission operations, the following autonomy levels can be identified:

execution mainly under realtime ground control;
execution of preplanned mission operations onboard;
execution of adaptive mission operations onboard;
execution of goaloriented mission operations onboard.
These autonomy levels are summarized in Table 51.

Table 51: execution autonomy levels

Level	Description	Functions
E1	execution under ground control; limited onboard capability for safety issues	Realtime control from ground for nominal operations Execution of timetagged commands for safety issues
E2	Execution of preplanned, grounddefined, mission operations onboard	Capability to store timebased commands in an onboard scheduler
E3	Execution of adaptive mission operations onboard	Eventbased autonomous operations Execution of onboard operations control procedures
E4	Execution of goaloriented mission operations onboard	Goaloriented mission replanning

The corresponding requirements for onboard operations scheduling, onboard operations procedures and eventaction coupling are addressed in clauses 5.8.5, 5.8.11 and 5.8.12, respectively.

Autonomy for mission data management

For mission data management, the following autonomy levels can be identified:

essential mission data used for operational purposes can be stored onboard;

all mission data can be stored onboard (science data and housekeeping data).

These autonomy levels are summarized in Table 52.

Table 52: execution autonomy levels

Level

Description

Functions

Storage onboard of essential mission data following a ground outage or a failure situation

Storage and retrieval of event reports

Storage management

Storage onboard of all mission data, i.e. the space segment is independent from the availability of the ground segment

As D1 plus storage and retrieval of all mission data

The corresponding requirements for onboard storage and retrieval are addressed in clause 5.8.9.

Onboard fault management

Overview

The overall onboard fault management concept is based on the failure detection, isolation and recovery (FDIR) paradigm. This means that functions are implemented:

to detect onboard failures and to report them to the relevant onboard units or subsystems and to the ground segment;

to isolate the failure, i.e. to avoid the propagation of the failure and the deterioration of equipment;

(in the case of F2, see below) to recover the onboard functions affected by the failure such that mission operations can continue.

The following autonomy levels can be identified:

autonomy to safeguard the space segment or its subfunctions;

autonomy to continue mission operations.

These autonomy levels are summarized in Table 53.

Table 53: execution autonomy levels

Level

Description

Functions

Establish safe space segment configuration following an onboard failure

Identify anomalies and report to ground segment

Reconfigure onboard systems to isolate failed equipment or functions

Place space segment in a safe state

Reestablish nominal mission operations following an onboard failure

As F1, plus reconfigure to a nominal operational configuration

Resume execution of nominal operations

Resume generation of mission products

The corresponding requirements for fault management are addressed in clauses 5.7.5.2 to 5.7.5.7. The general FDIR requirements and the failure detection and isolation requirements are applicable to autonomy levels F1 and F2, while the failure recovery requirements given in clause 5.7.5.5 are only applicable to autonomy level F2.

General FDIR

The space segment shall provide FDIR functions that take into account:

the autonomy requirements addressed in clause 5.7.2a,
system, subsystem, equipment and unit safeguarding needs, and
ground segment intervention conditions.

FDIR functions are those functions that implement the failure detection, isolation and recovery actions. The FDIR functionality is established at various levels within the space segment, e.g. at hardware and software levels. The implementation of the FDIR functions is based on specific system needs, e.g. specific time constants.

FDIR functions shall be implemented in a hierarchical manner in order to detect, isolate and recover failures at the lowest possible implementation level.

1 For example, FDIR handling on an onboard data bus implying retries and subsequent error mechanisms in case these retries are unsuccessful.
2 This requirement can imply a staggered recovery scheme based on retry functions (see also clause 5.7.5.4).
The FDIR design should not be overly cautious, e.g. if a detected anomaly can be isolated to a specific payload or subsystem, it should not trigger a full payload switchoff or a switch to a spacecraft safe mode.
If an FDIR function that is implemented in software is not available, a fallback mechanism shall be provided using an independent mechanism.

The independent mechanism can be a watchdog running on a separate unit or a hardwarebased mechanism.

The FDIR functions shall make use of the redundancy implemented on board.
Any abnormal operational situation of the spacecraft, its subsystems, equipment or units shall be notified to or detectable by the next higher operational control instance (FDIR level).
Failures that cannot be handled at a given level shall be handed over to the next higher operational instance, the highest instance being the ground segment.
Failure detection, isolation and recovery activities performed onboard shall be reported in an unambiguous manner to the ground segment.
The reporting of FDIR activities shall contain all information for failure analysis (e.g. time of occurrence, parameter outoflimit, switching performed).

A time delay for this reporting can be accepted if, for example, the reporting uses an operational onboard processor.

The FDIR functions implemented onboard should be intrinsically failsafe.
Except for passive hardware functions that cannot be overridden (such as fuses), the capability shall be provided to enable and to disable any onboard FDIR function by telecommand.

For example, the inhibition of a latchup detector or the bypassing of an autotest function.

Where FDIR functions are based on several inputs (e.g. sensor readings, and unit status), which are independently tested to determine a failure condition, the capability shall be provided to enable and disable each such input by telecommand.
The FDIR functions shall not be based on processing of an input that is currently disabled.
The FDIR design shall be modular such that the ground segment can enable and disable parts of it in a graceful and consistent manner without having a detrimental effect on the overall system.

Failure detection

The space segment shall provide the means to detect and report any onboard anomaly condition.

This includes both hardware and software anomalies.

The capability shall be provided to monitor and to define outoflimit conditions for essential onboard parameters (see clause 5.8.6).
Failure detection algorithms shall not repeat the generation of the same exception telemetry if the same failure is detected at each successive failure detection cycle.
A separate telemetry indication should be generated if the exception condition disappears.
Anomaly reports shall contain a unique identification of the anomaly, its time of occurrence, and a record of the input data to the anomaly detection function.

The record of the input data can range from a snapshot to a historical record.

The failure detection functions shall be independent from the nominal monitoring and control functions.

For example, an AOCS FDIR function using different sensors from those used by the nominal AOCS control function.

If a failure detection function uses multiple inputs which are combined (e.g. OR/AND), then these inputs shall be independently derived, i.e. the inputs shall not come from the same source (e.g. unit), in case that source is faulty.
The capability shall be provided to detect failures in systems that are off line (i.e. not involved in any primary function) when this does not conflict with operational configurations or operational constraints.
Except for hardwired failure detection mechanisms, parameters of failure detection criteria (such as thresholds and number of failure repetitions) shall be modifiable by telecommand.

Failure isolation

The space segment shall provide functions to isolate the failed unit or subsystem, to avoid failure propagation and deterioration of the impacted equipment.
For failures whose resolution implies safeguarding of system functions, the offending unit, subsystem or function shall be disabled or switched off.

For example, avoidance of power drain by a failed unit to a level where the ability to provide power to the rest of the spacecraft (a vital system function) is endangered.

For failures whose resolution does not imply the safeguarding of system functions, hierarchical isolation steps shall be applied (e.g. protocollevel retries or onboard operations procedures) before removal of the failed unit from the operational configuration.

The hierarchical isolation steps can include:

command retries and telemetry readback;
appropriate equipment switching, i.e. the selection of redundant equipment by telecommand or by onboard operations procedures, including functional verification;
application of delay times before switching off the failed equipment.

Failure recovery

If an onboard failure detection function identifies an anomalous situation, it shall trigger autonomous recovery actions consistent with the specific mission needs without ground segment intervention.
Any potential conflict between failure recovery activities and nominally ongoing onboard commanding activities shall be identified and managed.

This can imply suspending the onboard operations schedule and currently active onboard operations procedures.

A failure in the performance of an autonomous recovery action shall be followed by an action to ensure the safety of the spacecraft, subsystem or payload.

In some cases, predefined retries are implemented in the system (e.g. for protocol handling).

Where FDIR functions trigger an autonomous recovery to redundant units, the capability shall be provided to independently specify by telecommand the units to be monitored (for failure detection) and the combination of units to be selected for the recovery activities (from the available combinations).

Fault management level F1

The safety of the space segment and its subfunctions shall be ensured for a predefined period <AUT_DUR_FAIL> in the presence of a single onboard failure and in the absence of ground segment intervention.
After detection of an onboard failure that threatens space segment safety, the Level F1 fault management functions shall trigger reconfiguration activities leading to an onboard safe state.
The spacecraft shall enter a safe state if any hazard exists that affects spacecraft or payload health or mission objectives.
The spacecraft shall not enter survival mode if no hazard exists that affects spacecraft or payload health or mission objectives.

In particular, this implies a robustness of the implementation of the hierarchical FDIR to cope with minor errors (e.g. operational errors resulting from a single telecommand issued in the wrong context) without causing entry into survival mode.

Recovery from survival mode shall be undertaken under ground control.

Fault management level F2

The failed function shall be restored within a missionspecified interval of time.
The onboard fault management function shall autonomously establish a fully operational configuration such that mission operations can continue, including the generation of the mission products.

Requirements specific to the telemetry and telecommand packet utilization standard

Application process and service design

The capability shall be provided for the ground segment to exercise control over an application process.

As a minimum this includes “reset”.

The application process identifier (APID) shall uniquely identify the onboard address indicating the source (telemetry source packets) or destination (telecommand packets) of packets.
Different platform subsystems and payloads should be assigned different sets of APIDs.
The assignment of APIDs shall remain unchanged during the mission.
If the onboard design includes functions providing services and capabilities for which there is a standard service defined in ECSSEST7041 clause 5.5, these services and capabilities should conform to ECSSEST7041, clauses 6 to 21.
The structure of all variable telemetry and telecommand packets shall conform to ECSSEST7041, clauses 5.3 and 5.4.
Each telecommand packet shall be characterized by its destination service type and by a service subtype indicating the type of function or activity requested to be executed by the service.
All telemetry packets containing a data field header shall include type and subtype fields which appear in the same location.
The structure of a telemetry packet containing a data field header shall be derivable from the combination of its APID, type and subtype and up to two auxiliary packet identification fields.

For example, the structure ID (SID) in ECSSEST7041 housekeeping packets.

All telemetry packets of the same type and subtype shall contain the auxiliary identification fields at the same location and with the same width.
The combination of APID, packet type, subtype and auxiliary identification fields shall be uniquely assigned across the complete spacecraft (i.e. across all application processes generating telemetry).
Variable packet structures shall only be used for eventdriven or requestdriven telemetry packets.

This does not apply to payload measurement data.

The “Parameter#” used onboard to identify telemetry parameters shall be uniquely assigned across the complete spacecraft.

For the “Parameter#” used onboard to identify telemetry parameters, see ECSSEST7041 for additional information.

The choice structure corresponding to a given value of a choice parameter shall be unique for the complete spacecraft.

For the choice structure corresponding to a given value of a choice parameter (see ECSSEST7041 for additional information).

Statistical data reporting

The capability shall be provided to report statistics relating to a specified set of parameters over an interval of time.
The capability shall be provided to report maximum, minimum and mean values and the standard deviation.
The capability shall be provided to add and delete parameters from the set being evaluated.
The capability shall be provided to clear the set of parameters being evaluated.
The capability shall be provided to reset the evaluation of parameter statistics.
The capability shall be provided to request a report of the current set of parameters being evaluated.

Memory management

The capability shall be provided for the ground segment to load any changeable memory area.
The capability shall be provided to load a contiguous memory area (e.g. by specifying the start address and the data to be loaded).
The capability shall be provided to perform scatter loads with a single telecommand message (e.g. by specifying sets of start address and data to be loaded).
As part of the onboard acceptance of a memory load, the destination application process shall be able to detect data corruptions.
The onboard endtoend verification of a memory load shall consist of confirming that the data has been correctly loaded into its destination memory (by reading it back from the memory and comparing it with the load data).
The capability shall be provided for the ground segment to dump any memory area, on request.
The capability shall be provided to request a memory dump from a contiguous memory area (e.g. by specifying the start address and the length of the dump).
A single memory dump telemetry packet shall only contain data from memory areas containing contiguous onboard memory addresses.

If a dump is requested across one or more discontinuities in memory address (e.g. due to memory pages), this implies that the memory dump uses different telemetry packets that are aligned with the address discontinuities.

The capability shall be provided to request scatter dumps (e.g. by specifying sets of start addresses and length of the dump).
The onboard system shall not impose artificial constraints on the size of memory areas that can be loaded and dumped based on a single command.
The onboard system shall not impose artificial constraints on the uplink speed of memory load command or memory dump command.
The capability shall be provided for the ground segment to request a check of any onboard memory.
The capability shall be provided to request a memory check of a contiguous memory area (e.g. by specifying the start address and the length of the area to be checked).
The capability shall be provided to request a memory check of several areas with a single telecommand message (e.g. by specifying sets of start addresses and lengths of areas to be checked).
In response to a request to check memory, the onboard action shall be to perform a checksumming over the requested address ranges and report the result to the ground segment.
Integrity of the memory area during load, dump or check operations shall be ensured by the onboard application process.

Memory integrity is normally ensured by preventing other application processes from writing to this memory area during the load or check process.

Memory loads should be permanently available onboard to avoid timeconsuming memory reloads from the ground following memory switch on.

For example, using EEPROM.

Function management

The specialized groundcontrollable tasks of an application process should be implemented using the “Function management service” specified in ECSSEST7041.
The capability shall be provided for the ground segment to invoke a function and to pass instantiation parameters to it, by means of a single telecommand.

Onboard operations scheduling

The capability shall be provided for the ground segment to load any telecommand into the onboard operations schedule.

This restricts the maximum usable packet length of a telecommand, since it is a command embedded within an “insertintoschedule” telecommand.

The capability shall be provided to edit the onboard operations schedule (insert, append and delete telecommands).

Although it can be assumed that most telecommands are appended (i.e. uploaded in execution time order), no constraint is imposed on the order in which telecommands are uploaded.

The capability shall be provided to perform the editing operations without stopping the schedule.
The capability shall be provided to start and stop the onboard operations schedule.
The onboard operations schedule shall consist of subschedules that can be individually controlled (started and stopped).
The capability shall be provided to timeshift (i.e. advance or retard) a selected set of telecommands that have already been loaded in the onboard operations schedule.

This function is used to support the rescheduling of operations and to avoid having to delete and reload the affected telecommands.

The capability shall be provided for a telecommand released from the onboard operations schedule to set an interlock on (i.e. condition the release of) subsequent telecommands within the same subschedule.
The capability shall be provided to request a report of the contents of the onboard operations schedule.
The capability shall be provided to perform all editing operations on the schedule even when it is in a stopped state.
The capacity of the onboard operations schedule shall cover at least the needs of the autonomy period.
The elapsed time for the onboard transfer of telecommands from the onboard operations schedule to the destination application process shall be predictable to an accuracy compatible with the telecommand execution time accuracy specified for the mission.
The protocol for the onboard transfer of telecommands to their destination application process shall ensure that any transfer error is reported to ground and to the onboard operations schedule service.
The onboard operations schedule service shall detect any situation that prevents the onboard transfer of a telecommand to its destination application process.
A telecommand loaded into the onboard operations schedule with an onboard release time earlier that the current onboard time (OBT) shall be rejected.
A telecommand loaded into the onboard operations schedule with an onboard release time equal to that of a telecommand already loaded shall not be rejected but released immediately after that other telecommand.
Any telecommands in the onboard schedule that have “elapsed” because the schedule, subschedule or application process to which they relate has been stopped and subsequently restarted, shall not be released.
Management of the memory area used for the onboard operations schedule shall be performed autonomously onboard and shall not restrict schedule operation or schedule editing operations.
The execution of each telecommand released from the onboard operations schedule shall result in the generation of either a “successful completion of execution” or an “execution failure” verification report.

Onboard monitoring

The capability shall be provided to monitor onboard a set of onboard parameters defined by ground segment.

All telemetry parameters are normally available to the onboard monitoring function.

The onboard monitoring capabilities shall include limitchecking, expectedvaluechecking and deltachecking.
The capability shall be provided to specify more than one modedependent monitoring check for a given parameter.

“Mode dependent” means that the check is only applied if the corresponding mode is TRUE. In the event that more than one mode is contemporaneously TRUE, all corresponding checks are applied.

The capability shall be provided to enable and disable either the complete onboard monitoring function or selected parameters in the “monitoring list”.
The capability shall be provided to add parameters and their monitoring information to the onboard monitoring list.
The capability shall be provided to modify the monitoring characteristics of a parameter, including limit sets, expected value checks, delta checks and filtering characteristics.
The capability shall be provided to modify parameter monitoring information without having to first delete the parameter and then add it again to the monitoring list.
The capability shall be provided to clear the complete onboard monitoring list or to delete selected parameters from it.
If the onboard monitoring list contains checks that are used by onboard FDIR functions, then the clear command shall be implemented as a missioncritical command.
All changes of monitoring status shall be reported to the ground segment by means of a “check transition” telemetry packet.

For example, a check transition telemetry packet produced when a parameter goes outoflimits and when it subsequently returns back into limits.

The capability shall be provided for a change of monitoring status to give rise to an event report.

1 This capability is used when an onboard action is defined for execution when this check transition occurs (see clause 5.8.12).
2 This capability is not provided as a standard onboard monitoring service capability by ECSSEST7041.
The capability shall be provided to request a report of the contents of the monitoring list including the parameter monitoring characteristics.
The capability shall be provided to request a report of the full set of parameters that are currently in violation of any of their monitoring checks.
The capability shall be provided to perform all editing operations on the onboard monitoring function even when it is in a disabled state.

Large data transfer

Taking into account factors such as uplink bandwidth, ground contact periods and time to recover from telecommand failure, a given mission shall be capable of defining a maximum telecommand packet length which is less than the maximum specified by ECSSEST-5004.
Taking into account factors such as downlink bandwidth and ground contact periods, a given mission shall be capable of defining a maximum telemetry source packet length which is less than the maximum specified by ECSSEST-5003.
When transferring a set of data that exceeds the maximum packet size specified for the mission (e.g. memory loading or dumping), the capability shall be provided to transfer this data in more than one packet (part packet).
The capability shall be provided to send part packets with or without intermediate acknowledgement of receipt.
In the event that the transfer of a part packet to its destination is not successful, the capability shall be provided to transfer succeeding part packets.

The procedure used for the large data transfer protocol is defined in Clause 16 of ECSSEST7041.

Telemetry generation and forwarding

The capability shall be provided to selectively enable and disable the forwarding of telemetry source packets to the ground segment.
The capability shall be provided to enable and disable telemetry source packet generation at the level of the originating service.
The capability shall be provided to request a report of which telemetry source packets generated by an application process are currently disabled for forwarding to the ground segment.

Onboard storage and retrieval

For missions with intermittent ground coverage, the onboard storage capability shall be able to store all packets generated onboard for space segment monitoring and control purposes, for a duration at least equal to the longest noncoverage period.
For missions with continuous ground coverage, loss of oneshot packets (i.e. eventdriven or requestdriven packets) shall be remedied by the shortterm onboard storage of the last <PKTS_NUM_STORED> packets.

This includes telecommand verification packets (they are effectively requestdriven).

An onboard store shall be provided containing an “anomaly log” of all event or requestdriven packets reporting onboard anomalies.

For example, autonomous switchdowns and command failure reports.

The content of the anomaly log specified in requirement 5.8.9c shall be persistent even after a reconfiguration or a cold restart of the application process managing the store.
Onboard storage shall be such that the ground segment can retrieve the stored packets within specified delays <PKT_RETR_DELAY>.

1 For example, packets of high operational significance, such as error or anomaly packets, processed on the ground with shorter delays than routine status reporting packets.
2 There can be several such parameters for a given mission corresponding to data of different operational significance.
The capability shall be provided to assign priorities to parallel retrievals from different stores.

These priorities can be assigned to maximize the utilization of the downlink bandwidth.

For each independent onboard store, the capability shall be provided for the ground segment to enable and disable the storage function.
For each independent onboard store, the capability shall be provided to specify the packets to be stored by adding or removing packets from a list maintained onboard.
The capability shall be provided to select a given telemetry packet to be stored in more than one onboard store.
Onboard stores shall be either circular, where the oldest data is automatically overwritten when the store is full, or linear, where storage terminates when the onboard store is full.
The capability shall be provided for the ground segment to clear the contents of a linear onboard store.
The capability shall be provided to configure a linear packet store such that packets can be overwritten once they have been dumped and their reception has been acknowledged by the ground segment.
The storage of packets shall not be interrupted if the ground segment requests a retrieval from, or reset of, the onboard storage.
The capability shall be provided for the ground segment to request the retrieval of all packets from an onboard store or to specify a time window or a packet range for the retrieval.
The capability shall be provided to request the retrieval of telemetry packets that have previously been retrieved (provided they have not yet been overwritten).
The capability shall be provided to suspend and resume the retrieval of stored telemetry packets.
When resuming a retrieval, it shall continue from the point where it was suspended.
Housekeeping information shall be provided on the state of the onboard storage and retrieval function for each onboard store.

For example, fill level, pointer addresses.

Onboard traffic management

The onboard packet distribution system shall generate a report whenever a problem arises with the onboard traffic.

For example, a bottleneck in the distribution of telecommand packets or of telemetry source packets on the packet bus.

Control capabilities shall be provided such that the ground segment can resolve all preidentified onboard problems relating to telecommand packet reassembly, telemetry data handling or onboard traffic.
Packet bus management and resource parameters, such as average and peak bus loading and numbers of packet retransmissions, shall be routinely reported to the ground segment.

Onboard operations procedures

The capability shall be provided to execute a set of operations procedures which can be loaded and controlled from the ground segment.
The capability shall be provided to execute more than one operations procedure at the same time.
The control operations shall include load, delete, start, stop, suspend, resume and transfer parameters.
The ground segment shall be able to request a report of the currently active onboard operations procedures.
The ground segment shall be able to request a report of the currently loaded onboard operations procedures.
Onboard operations procedures shall be capable to send any command available for transmission from the ground segment.
Onboard operations procedures shall have access to any telemetry parameter available to the ground segment.
The capability shall be provided to prioritize the execution of onboard operations procedures.

1 For example, to give priority to fault management procedures.
2 Priority applies in the event of conflicts.

Eventtoaction coupling

The capability shall be provided to trigger an onboard action as a result of the detection of an onboard event.

An action in this context is a telecommand, which can itself initiate other onboard actions (e.g. a telecommand which starts an onboard operations procedure).

Onboard actions shall include any command available for transmission from the ground segment.
The ground segment shall be able to add and delete eventtoaction definitions to and from an onboard list and to request a report of the list.
The capability shall be provided to enable and disable individual actions without having to delete the eventtoaction definition.
The triggering of an onboard action shall itself give rise to an event report.

Equipment and subsystemspecific

Onboard processors and software

The design (selection) of onboard processors shall ensure that the available memory and performance accommodates, with a margin of <RESOURCE_MARGIN>:

the requirements of the baseline (i.e. as launched) processes, and
a realistic allocation for processes and data to be developed and loaded after launch. If an onboard processor is switched from a prime to a redundant unit (or vice versa), the switchover shall be such that operations can continue safely.

This implies either that:

the operational context need not be reloaded from the ground segment, or
the new processor can be loaded with a safe default context before the switchover.
A processor switchover should not invalidate telecommands not yet released from any ground schedule.

This implies that telecommands defined for the prime unit are also valid for the redundant unit, except for any command routing data which the ground system can automatically change when addressing the redundant processor.

The capability shall be provided to save the operational context in nonvolatile memory so that it can be restored if a processor is reset or temporarily switched off.
Redundant processors should provide the capability to be turned on and operated outside of any control function, for the purpose of evaluating their performance prior to switching to become prime.
The resources utilized by onboard software shall be telemetred (e.g. memory usage, central processor unit (CPU) usage and I/O usage).
The capability shall be provided to check that onboard software has been correctly uploaded before enabling it.
The capability shall be provided for the ground segment to patch the nominal software directly.
The contents of a RAM of a unit or instrument that is suspended or switched off as a result of an FDIR action shall be preserved so that the ground segment can dump the content for the purposes of failure investigation.
Enabling of onboard software should use only a single telecommand.

This does not preclude dualstep commanding because only the final command enables the software.

Any communication between the ground and an onboard software function or software task shall be effected by means of telecommand and telemetry source packets specifically designed for the purpose.

The objective is to ensure that memory dump and memory load packets (for example) are not used for this purpose. They are not adequate for changes of this operational significance.

Whenever a condition that forces a processor reset is detected by software, an event report shall be generated prior to enforcement of the reset.
Whenever a processor is running synchronously scheduled tasks, it shall check at the end of each software cycle that all tasks scheduled for that cycle have been duly completed.
Whenever a processor overload condition is detected, an event report shall be generated.
A processor overload condition should not automatically lead to the processor being halted.
Whenever an unexpected arithmetic overflow condition is detected, an event report shall be generated.
Whenever an illegal program instruction is encountered during execution of a program code, an event report shall be generated.
Whenever a data bus error is detected, an event report shall be generated.
Whenever a memory corruption is detected by an error detection and correction mechanism, an event report shall be generated.
Whenever a checksum error is detected, an event report shall be generated.
Whenever an internal inconsistency is detected, an event report shall be generated.
The event reports that are generated in the case of a failure shall indicate the type of failure, its location and any additional information needed for failure diagnosis.

Power supply and consumption

The power telemetry parameters assigned shall be such that the power available and power demand can be directly established from the telemetry alone.

This becomes critical in eclipse seasons, for instance, when the solar array degrades to a level approaching the sunlit demand plus recharge demand, or when the ineclipse loads closely match the battery capabilities.

Means and telemetry shall be provided such that the ground segment can determine the state of charge of each battery throughout all mission phases, to an accuracy of better than <BATT_CHARGE_ACC>.
For all units that have primary power consumption greater than <POW_CONS_THRESH>, a thermistor on a hot point or a primary current sensor shall be provided and made available in telemetry.
The power for telemetry conditioning of equipment shall be hierarchically structured to avoid the generation of invalid telemetry (which could in turn trigger unnecessary recovery actions).
The power for telemetry conditioning of equipment shall not be supplied from other unrelated units that are not permanently powered.
Vital power control functions shall have a switchover function to the redundant path, but never a switchoff function.
The capability shall be provided to redefine the list of nonessential loads to be shed in the event of a power anomaly (e.g. battery undervoltage).
The capability shall be provided to change the state of a critical relay without powering it on.

Telemetry, tracking and command (TT&C)

Redundant receivers, crossstrapped to redundant decoders, shall be provided.
Except following the occurrence of postlaunch failures, the ground segment shall not be enabled to achieve by command a state where less than two receivers are active.
The combined coverage of all onboard TT&C antennas shall be such that telemetry and telecommand contact can be provided under specified attitude and orbit conditions.

This does not imply ensuring full ground segment coverage during all mission phases, but rather that the spacecraft can be accessed when specified.

Where the onboard design implies switching between antennas (e.g. for inertialpointing spacecraft or during attitude manoeuvres), it shall be ensured that the overlap between antenna patterns is such that there is at least <ANT_SWITCH_TIME> to effect antennaswitching under all expected orbit and attitude conditions.

Attitude and orbit control

Telemetry generated by sensor elements shall be assigned to dedicated telemetry channels (i.e. parameters) in order to be able to monitor all sensors (whether used or not) for diagnostic purposes.
The operating ranges of onboard sensors shall accommodate all operational scenarios with adequate margins.
The telemetry of stimulated detectors shall be designed to handle all flightphase conditions either in normal mode telemetry or by modeswitching to extended range.
Housekeeping telemetry shall be continuously available to enable verification of the operation of onboard attitude control functions and the results of any onboard attitude determination.
Telemetry monitoring of thruster actuation shall be provided to enable thruster ontime surveillance and fuel consumption determination.
In normal conditions the avionics of 3axis controlled spacecraft should maintain the knowledge of the current 3axis attitude.
Means shall be provided for determining from telemetry the remaining fuel in each independent propellant system.
The accuracy for determination of the amount of remaining fuel at any given point in the mission shall be related to the amount of fuel remaining, as agreed with the customer.

1 This accuracy depends on the particular mission planning requirements.
2 An accuracy of 5 % is normally acceptable at the start of the mission; however, when there is only 10% of the fuel remaining, the acceptable accuracy is normally about 10% to 20%.

Mechanisms

Oneshot drivable mechanisms shall be provided with both hard and soft endstops, independently telemetred.
The status of mechanisms that are locked during launch shall be available during the prelaunch phase.
The capability shall be provided to monitor the various stages of a deployment process.

For example, all motorized deployments monitored by potentiometers.

The position of all mechanisms shall be known for all anticipated operations.
The positions of all mechanisms shall be commanded and monitored absolutely, i.e. not commanded incrementally or monitored by relative or cyclic readings.

Thermal control

The capability shall be provided for the ground segment to enable and disable each individual thermal control loop.
With the exception of loops that are driven by thermostats, the capability shall be provided to adjust the temperature control thresholds of each thermal control loop by ground command.

Payload

The design of the payload shall include taking protective action against potential damage caused by the external environment.

For example, switchoff of the high voltages if the background radiation level is detected to be too high.

Payloads shall provide the capability to enter a safe state upon receipt of a specific command.
There shall be no requirement for the ground segment to perform extensive payload operations for an interval <PAYLOAD_INT> after separation from the launcher.

Simple instrument switchon, or heater activation is not excluded.

If data compression techniques are implemented, they shall not impose special requirements on the design of the ground segment, such as redundant links or larger antennae.
The interpretation of compressed data shall not depend on the telemetry history.
All information to assess the health and safety of a payload instrument shall be available in the housekeeping telemetry, i.e. this information shall be available without accessing science telemetry.
Any operationallysignificant information on the configuration and timing of payload operations should be downlinked in the telemetry.

ANNEX(informative) constants

The mission constants identified within the body of this Standard are summarized and defined below.

<ANOM_RESP_TIME>

minimum response time for the ground segment to react to anomalies detected from the telemetry with the generation of a telecommand

This is applicable for short, welldefined intervals during critical mission phases and for preagreed contingencies and anomaly conditions.

<ANT_SWITCH_TIME>

minimum time interval that is available for switching between onboard antennas

<AUT_DUR_EXEC>

interval of time for which the space segment can execute nominal mission operations autonomously

<AUT_DUR_DATA>

interval of time for which the space segment can store mission data onboard

<AUT_DUR_FAIL>

interval of time for which the space segment safety is ensured (without ground segment intervention) in the event of a single failure

<BATT_CHARGE_ACC>

accuracy to which the charge status of an onboard battery can be determined

<DIAG_MIN_INTERV>

minimum sampling interval for sampling an onboard parameter in diagnostic mode

<GRND_RESP_TIME>

response time for control functions involving the ground segment

There can be several such parameters for a given mission.

<PARAM_ABS_SAMPL_TIME>

accuracy of determination of the absolute (onboard) sampling time of a telemetry parameter

<PARAM_REL_SAMPL_TIME>

accuracy of determination of the relative sampling time of any two telemetry parameters

<PAYLOAD_INT>

interval of time following separation from the launcher during which there is no requirement for the ground segment to perform extensive payload operations

<PKT_RETR_DELAY>

maximum time delay for the ground segment to retrieve data generated at an earlier time and stored onboard

There can be several such mission parameters relating to data of different operational priority.

<PKTS_NUM_STORED>

number of packets stored in shortterm storage onboard

This is applicable for missions with continuous ground coverage.

<POW_CONS_THRESH>

threshold of electrical power consumption beyond which specific requirements exist for the provision of telemetry data

<RESOURCE_MARGIN>

minimum resource margin for onboard subsystems and payloads that is available at all times during the mission

For example, power, onboard memory, CPU load, bus traffic and registers

<TC_VERIF_DELAY>

maximum delay between the execution of a telecommand and its verification within the telemetry

<TIME_CORREL_ACCUR>

correlation accuracy between onboard time and ground time

ANNEX(informative)Tailoring guide

For tailoring purposes, the following major areas of potential impact are identified:

Ground segment functions

If a requirement is tailored out, this can give rise to a requirement (tailored in) for special ground segment functions instead. For example, a requirement for an additional ground station in order to increase the coverage or a requirement for complex ground functions to process the telemetry or telecommand data.

Space segment safety

If a requirement is tailored out, the safety of the space segment can be endangered. This relates either to unauthorized access to the spacecraft, or to loss of control of the spacecraft.

Space segment and mission degradation

If a requirement is tailored out, this can have consequences in terms of:

Temporary or permanent degradation of a space segment function.

As long as redundancy is provided, the mission objectives can still be achievable.

Temporary or permanent degradation of the mission.

Operations impact

If a requirement is tailored out, the efficient control of the satellite can be impacted, with a subsequent effect on the mission performance.

Table B-1 shows the impact of each requirement in each of these areas and also provides additional comments concerning the potential implications if the requirement is tailored out.

Table: Tailoring guide

Requirement	Ground segment function	Space segment safety	Space segment and mission degradation	Ops impact	Tailoring out implications
4.2a		X	X	X
4.3a			X	X
4.4a	X				High complexity ground segment functions to process the data, if the space segment is not designed in conformance with to Standards (e.g. telemetry and telecommand packet definitions).
4.4b	X			X
4.5a		X
4.5b		X	X
4.5c		X	X
4.5d		X	X
4.5e		X	X
4.5f		X	X
4.6a				X	Definition by the control centre of special procedures and limit checks for each combination of equipment.
4.6b				X
4.6c				X	Loss of capability to check redundant equipment before their utilisation by the control centre.
4.6d			X	X
4.6e			X		Loss of capability to control the space segment in case of failures of automatisms.
4.6f			X		Loss of flexibility to handle changes to ensure that the mission goals can be achieved. The flexibility to be provided is highly dependent on the mission duration and complexity. The longer the mission the more likely are changes.
4.6g			X		Loss of flexibility to handle changes to ensure that the mission goals can be achieved. The flexibility to be provided is highly dependent on the mission duration and complexity. The longer the mission the more likely are changes.
4.6h				X
4.7a				X
4.7b				X	Loss of control of the space segment if the redundant equipment is not working as expected. If this function is not implemented as far as possible (i.e. ensuring that onboard design constraints, e.g. power constraints, are not violated), an increase in the risk of losing control can be expected.
4.7c			X		Potential severe impact on the mission in case of a failure.
4.7d			X
4.8a				X
4.8b				X
5.2.1a		X
5.2.1b	X	X
5.2.1c	X	X
5.2.2a	X			X	High availability requirement on the ground segment which leads to the implementation of special ground functionality.
5.2.2b	X			X
5.2.2c				X
5.2.2d				X	Delays leading to inefficiencies in executing operations.
5.2.3a	X			X	More complex ground processing. Inefficient use of downlink bandwidth.
5.2.3b	X			X
5.2.3c	X			X
5.2.3d				X	Impact on the mission return if data recovery is part of the nominal operations to avoid data losses.
5.2.3e	X			X
5.3.1a			X	X
5.3.1b				X
5.3.1c				X
5.3.1d				X	Potential for the ground segment to miss essential onboard events.
5.3.1e	X
5.3.1f				X
5.3.1g			X		Wrong decision by the ground segment if invalid or outofdate telemetry data are used.
5.3.1h				X
5.3.1i			X
5.3.1j			X	X
5.3.1k			X
5.3.1l			X	X
5.3.1m				X	Potential for the ground segment to be misled by incorrect processing of the telemetry. This concerns in particular AOCS sensor data.
5.3.1n			X	X
5.3.1o			X	X
5.3.1p	X			X	Wrong decision by the ground segment if invalid telemetry data are used.
5.3.1q	X			X
5.3.1r	X			X
5.3.1s	X
5.3.1t	X
5.3.1u	X
5.3.1v	X
5.3.1w	X
5.3.1x				X
5.3.1y				X	Loss of flexibility to reduce the update and downlink rate of parameters (less frequent parameter updates or fewer packets).
5.3.1z	X			X
5.3.1aa	X			X
5.3.2a				X	Limitation of the detailed analysis of specific anomaly cases.
5.3.2b				X	Limitation of the detailed analysis of specific anomaly cases.
5.3.2c				X
5.3.2d				X	Loss of flexibility of data analysis. This requirement is only applicable if an onboard storage function is provided.
5.4a			X	X	Potential inability to achieve the mission objectives if the specified timing accuracy is not provided.
5.4b	X			X	Implementation of special ground processing.
5.4c				X
5.4d				X
5.4e				X
5.4f				X
5.4g	X			X	Implementation of special ground processing.
5.4h	X				Inability to apply the standard ground segment processing software. This requirement is essential for housekeeping telemetry but can be relaxed for payload data if the relevant time information appears elsewhere within the packet.
5.4i	X			X	Implementation of special ground processing.
5.4j			X	X	Ambiguity of telemetry.
5.4k			X	X	Potential inability to achieve the mission objectives if the specified timing accuracy is not provided.
5.4l			X
5.4m	X			X
5.4n				X
5.5.1a		X	X
5.5.1b	X			X	Higher complexity of the configuration control of commands. Risk of sending commands in the wrong context.
5.5.1c	X			X
5.5.1d				X
5.5.1e				X
5.5.1f	X		X	X	Higher complexity of the configuration control of commands. Risk of sending commands in the wrong context.
5.5.1g	X			X
5.5.1h		X	X
5.5.1i			X	X	Inability of the ground to send commands in a safe manner when the onboard situation is unclear, e.g. in the event that telemetry data is not available.
5.5.1j			X	X	Potential impact on the control of the space segment in specific failure situations.
5.5.1k	X			X
5.5.1l	X			X	Increase in the size of the operational database and higher complexity of the configuration control task.
5.5.1m	X			X
5.5.1n	X			X
5.5.2a			X	X	Potential impact on the access to the space segment in the event of processor failures.
5.5.2b		X	X
5.5.2c		X	X
5.5.2d		X	X
5.5.3a				X	Cumbersome uploading of memory load commands and the imposition of severe restrictions on the operations.
5.5.3b	X			X
5.5.3c			X	X
5.5.3d				X
5.5.3e	X			X
5.5.4a			X	X
5.5.4b			X	X
5.5.4c				X
5.5.4d				X
5.5.4e	X			X
5.5.4f	X			X
5.5.4g	X			X
5.5.4h				X	Impact on the definition of efficient control procedures and command sequences.
5.5.4i			X	X
5.5.4j	X			X
5.5.4k				X
5.5.4l			X	X
5.5.4m			X	X
5.5.4n	X			X	Implementation of special ground processing functions.
5.6.1a			X	X	Loss of flexibility to control the configuration of the space segment.
5.6.1b				X
5.6.1c				X
5.6.1d				X
5.6.1e				X
5.6.2a				X
5.6.2b				X	Loss of the capability to identify whether an onboard reconfiguration is executed nominally and to intervene early enough in the event of malfunctions.
5.6.2c				X
5.6.2d				X
5.6.2e			X	X	Impact on the detection of possible onboard failures.
5.6.2f				X
5.6.2g			X	X
5.6.2h		X	X
5.6.2i	X	X	X		Potential entry of the space segment into a hazardous status if ground contact cannot be guaranteed.
5.6.2j			X
5.6.2k				X
5.6.2l			X
5.6.2m		X	X		Potential entry of the space segment into a non recoverable state.
5.7.2a	X		X	X	Exacting requirements on the ground segment availability, i.e. substantial redundancy requirements.
5.7.2b			X	X
5.7.2c			X	X
5.7.2d		X	X	X
5.7.2e	X			X	Special setup on ground, which can also include extra manpower.
5.7.2f		X		X
5.7.5.2a	X		X	X
5.7.5.2b			X
5.7.5.2c			X
5.7.5.2d		X	X		Impact on the safety of the space segment in the event of onboard processor failures.
5.7.5.2e			X
5.7.5.2f			X
5.7.5.2g			X
5.7.5.2h			X	X
5.7.5.2i			X	X	Impact on the identification of a nonnominal onboard behaviour.
5.7.5.2j		X	X		Potential entry of the space segment into dangerous configurations.
5.7.5.2k			X	X	Potential loss of the mission or at least potential significant impact on the performance (e.g. nonavailability of a function) if an onboard mechanism fails.
5.7.5.2l			X	X	Inability of the ground to correct the onboard configuration in the event of performance degradation or onboard failures.
5.7.5.2m		X	X
5.7.5.2n			X	X
5.7.5.3a			X	X
5.7.5.3b			X	X	Outoflimit conditions can only be detected during ground coverage. This requirement is applicable if the space segment provides an onboard monitoring function.
5.7.5.3c	X		X	X	Potential for the ground to be misled by the telemetry information and to overlook essential information.
5.7.5.3d			X	X
5.7.5.3e				X
5.7.5.3f		X	X		Potential impact on the recovery from an anomaly condition of the failure that caused the entry into that anomaly condition.
5.7.5.3g		X	X
5.7.5.3h				X	Reduced probability of safety mechanisms working.
5.7.5.3i			X	X	Inability of the ground to correct the onboard configuration in the event of performance degradation or onboard failures.
5.7.5.4a		X	X
5.7.5.4b			X
5.7.5.4c			X
5.7.5.5a	X	X	X
5.7.5.5b	X		X	X
5.7.5.5c		X	X
5.7.5.5d		X	X		Potential failure of recovery if faulty equipment is used.
5.7.5.6a	X	X	X
5.7.5.6b		X	X
5.7.5.6c		X	X
5.7.5.6d			X	X	Potential inappropriate entry of the space segment into survival states, which impacts the mission return.
5.7.5.6e			X	X
5.7.5.7a			X	X
5.7.5.7b				X
5.8.1a			X	X	Loss of control of onboard processes in case of failures.
5.8.1b	X			X
5.8.1c				X
5.8.1d				X	Potential high complexity of the configuration control task on ground.
5.8.1e	X				Implementation of special ground processing functions and inability to reuse the standard infrastructure.
5.8.1f	X
5.8.1g	X
5.8.1h	X
5.8.1i	X
5.8.1j	X
5.8.1k	X				Implementation of special ground processing functions and inability to reuse the standard infrastructure. This requirement can be relaxed for payload data, for which special processing is envisaged.
5.8.1l	X
5.8.1m	X				Potential high complexity of the configuration control task on ground.
5.8.1n	X
5.8.2a				X	Impact on long periods without ground coverage and on downlink efficiency.
5.8.2b				X
5.8.2c				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.2d				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.2e				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.2f				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.3a				X	Loss of flexibility to react to changes of the onboard performance and functions.
5.8.3b	X			X
5.8.3c	X			X
5.8.3d			X
5.8.3e	X			X
5.8.3f				X
5.8.3g	X			X
5.8.3h	X			X	High complexity of the processing of dump data.
5.8.3i	X			X
5.8.3j	X			X
5.8.3k	X			X
5.8.3l				X	Risk of inconsistent onboard memory if there are no automatic onboard functions to check the consistency of the memory. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.3m	X			X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.3n	X			X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.3o	X			X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.3p			X
5.8.3q	X			X
5.8.4a	X			X	Implementation of special ground processing functions, if this functionality is provided and ECSSEST7041 is not followed.
5.8.4b	X			X
5.8.5a				X
5.8.5b				X	Significant impact on the execution of the operations.
5.8.5c				X
5.8.5d				X
5.8.5e				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.5f				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.5g			X	X	Risk of releasing commands in the wrong context, which can lead to hazardous situations. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.5h				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.5i				X
5.8.5j				X	Endangering of the safety of the space segment if the space segment autonomy is not ensured.
5.8.5k				X	Potential inefficient use of the onboard operations schedule.
5.8.5l				X	Potential sending of commands in the wrong context.
5.8.5m			X	X	Potential sending of commands in the wrong context.
5.8.5n			X	X
5.8.5o				X
5.8.5p			X	X	Potential entry of the space segment into a dangerous state.
5.8.5q	X			X
5.8.5r				X
5.8.6a			X	X	Reduction of the onboard autonomy and potential inability to detect anomalies in time.
5.8.6b			X	X
5.8.6c			X	X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6d			X	X	Risk of false anomaly notifications in the event of an onboard failure, which can lead to wrong operational decisions. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6e			X	X	Loss of flexibility to handle changes of the performance and functions of the space segment e.g. in the event of failures. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6f			X	X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6g				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6h				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6i		X		X
5.8.6j	X			X
5.8.6k				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6l	X			X	Implementation of a complex ground model. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6m				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.6n				X
5.8.7a	X			X
5.8.7b	X			X
5.8.7c	X			X
5.8.7d				X
5.8.7e				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.8a				X	Inability to use the available telemetry bandwidth in an efficient manner and potential overflow in case of a failed application.
5.8.8b				X	Potential overflow in case of a failed application.
5.8.8c				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9a				X	Impact on the onboard autonomy and the completeness of the data. The functionality to be provided depends on the mission characteristics.
5.8.9b				X
5.8.9c				X
5.8.9d				X
5.8.9e				X
5.8.9f				X
5.8.9g				X
5.8.9h				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9i				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9j				X
5.8.9k				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9l				X
5.8.9m				X
5.8.9n				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9o				X	This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.9p				X
5.8.9q				X
5.8.9r				X
5.8.10a			X	X	Reduced probability of detecting onboard malfunctions.
5.8.10b			X	X
5.8.10c				X
5.8.11a			X	X	Potential noncompliance of the achieved onboard autonomy with the mission goals.
5.8.11b				X
5.8.11c				X
5.8.11d	X			X	Implementation of complex ground models. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.11e	X			X	Implementation of complex ground models. This requirement corresponds to an optional capability of the corresponding ECSSEST7041 service.
5.8.11f				X
5.8.11g				X
5.8.11h		X		X
5.8.12a		X	X	X	Potential noncompliance of the achieved onboard autonomy with the mission goals.
5.8.12b		X	X	X	Potential noncompliance of the achieved onboard autonomy with the mission goals.
5.8.12c	X			X
5.8.12d				X
5.8.12e				X	Reduced probability of detecting the execution of an onboard action with the risk that the ground interferes erroneously with an onboard process.
5.9.1a				X	Loss of flexibility to handle changes of the performance and functions of the space segment.
5.9.1b			X	X
5.9.1c			X	X	Potential sending of commands in the wrong context.
5.9.1d	X			X
5.9.1e			X	X
5.9.1f			X	X	Potential inefficient use of the onboard processors.
5.9.1g			X	X
5.9.1h			X	X
5.9.1i		X	X	X
5.9.1j				X
5.9.1k	X			X
5.9.1l			X	X
5.9.1m			X	X
5.9.1n			X	X
5.9.1o		X	X	X
5.9.1p			X	X
5.9.1q			X	X
5.9.1r			X	X
5.9.1s			X	X
5.9.1t			X	X
5.9.1u			X	X
5.9.1v				X
5.9.2a			X	X
5.9.2b			X	X
5.9.2c			X	X
5.9.2d			X
5.9.2e			X
5.9.2f		X	X
5.9.2g			X
5.9.2h			X	X
5.9.3a			X
5.9.3b		X	X
5.9.3c			X	X
5.9.3d			X	X
5.9.4a	X		X	X
5.9.4b		X	X
5.9.4c			X	X
5.9.4d			X	X
5.9.4e			X	X
5.9.4f	X		X	X
5.9.4g			X	X
5.9.4h			X	X
5.9.5a			X	X
5.9.5b			X	X
5.9.5c			X	X
5.9.5d			X	X
5.9.5e	X			X
5.9.6a			X	X
5.9.6b			X	X
5.9.7a		X	X		This requirement depends on the mission characteristics.
5.9.7b		X	X	X
5.9.7c	X			X	Implementation of special functions on ground.
5.9.7d	X			X	Implementation of special functions on ground.
5.9.7e	X			X	Implementation of special functions on ground. High availability of the ground segment.
5.9.7f	X			X	Implementation of special functions on ground.
5.9.7g			X	X

Bibliography

ECSS-S-ST-00

ECSS system — Description and implementation and general requirements

Space engineering

Space segment operability

Change log

Introduction

Scope

Normative references

Terms, definitions and abbreviated terms

Terms from other standards

Terms specific to the present standard

Abbreviated terms

Conventions

General requirements

Introduction

Observability

Commandability

Compatibility

Safety and fault tolerance

Flexibility

Testability

Deactivation

Detailed requirements

Introduction

Mission­level

Security

Control functions

Uplink and downlink

Telemetry

Telemetry design

Diagnostic mode

Datation and synchronization

Telecommanding

Telecommand design

Critical telecommands

Telecommand transmission and distribution

Telecommand verification

Configuration management

Modes

On­board configuration handling

On­board autonomy

Introduction

General autonomy

Autonomy for execution of nominal mission operations

Autonomy for mission data management

On­board fault management

Overview

General FDIR

Failure detection

Failure isolation

Failure recovery

Fault management level F1

Fault management level F2

Requirements specific to the telemetry and telecommand packet utilization standard

Application process and service design

Statistical data reporting

Memory management

Function management

On­board operations scheduling

On­board monitoring

Large data transfer

Telemetry generation and forwarding

On­board storage and retrieval

On­board traffic management

On­board operations procedures

Event­to­action coupling

Equipment­ and subsystem­specific

On­board processors and software

Power supply and consumption

Telemetry, tracking and command (TT&C)

Attitude and orbit control

Mechanisms

Thermal control

Payload

ANNEX(informative) constants

ANNEX(informative)Tailoring guide

Bibliography

Missionlevel

Onboard configuration handling

Onboard autonomy

Onboard fault management

Onboard operations scheduling

Onboard monitoring

Onboard storage and retrieval

Onboard traffic management

Onboard operations procedures

Eventtoaction coupling

Equipment and subsystemspecific

Onboard processors and software