SIST EN 16603-70-01:2015

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - Krmilni postopki na plovilihRaumfahrttechnik - Bordseitige KontrollprozedurenIngénierie spatiale - Procédures automatiques de contrôle bordSpace engineering - On-board control procedures49.140Vesoljski sistemi in operacijeSpace systems and operations49.090On-board equipment and instrumentsICS:Ta slovenski standard je istoveten z:EN 16603-70-01:2015SIST EN 16603-70-01:2015en01-april-2015SIST EN 16603-70-01:2015SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-70-01
January 2015 ICS 49.140
English version
Space engineering - On-board control procedures
Ingénierie spatiale - Procédures automatiques de contrôle bord
Raumfahrtproduktsicherung - Bordseitige Kontrollprozeduren This European Standard was approved by CEN on 23 November 2014.
CEN and CENELEC members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN and CENELEC member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN and CENELEC member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN and CENELEC members are the national standards bodies and national electrotechnical committees of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2015 CEN/CENELEC All rights of exploitation in any form and by any means reserved worldwide for CEN national Members and for CENELEC Members. Ref. No. EN 16603-70-01:2015 E SIST EN 16603-70-01:2015

Figures Figure 4-1 The OBCP system. 15 Figure 5-1: OBCP state diagram . 26 Figure 6-1: Lifecycles of OBCPs originating from the different domains . 34 Figure 6-2: OBCP management overview . 36 Figure 6-3: Synchronisation of OBAP lifecycles with system and OBSW lifecycles . 36
This Standard assumes that missions implementing OBCPs are also compliant with ECSS-E-70-41, since a number of services contained therein are invoked in support of the operation of OBCPs and their interaction with the ground. This Standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.
EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system - Glossary of terms EN 16603-40 ECSS-E-ST-40 Space engineering - Software EN 16603-70 ECSS-E-ST-70 Space engineering - Ground systems and operations EN 16603-70-31 ECSS-E-ST-70-31 Space engineering - Ground systems and operations - Monitoring and control data definition
EN 16603-70-41 ECSS-E-70-41 Space engineering - Ground systems and operations - Telemetry and telecommand packet utilization
NOTE
Depending on the context, OBCP can refer to an OBCP in program source code form, or in OBCP code. 3.2.3 OBCP code complete representation of an OBCP, in a form that can be loaded on-board for subsequent execution NOTE 1 In previous missions, such code is typically referred to as token code, executable code or bytecode depending on the implementation of the relevant OBCP engine. SIST EN 16603-70-01:2015

OBCP operations are initiated by means of ECSS-E-70-41 Service 18 telecommands. 3.2.5 OBCP language programming language
in which OBCP source code is expressed by human programmers 3.2.6 OBCP system the entire machinery for the creation (in the ground system), uplinking, and on-board handling of OBCPs 3.2.7 OBCP step sequence of OBCP source code statements constituting the smallest operational unit within an OBCP 3.2.8 on-board software software hosted and executed by any programmable on-board computer or processor 3.2.9 scheduling controlling the allocation of OBSW processor (CPU) time for execution of the various OBSW functions, according to a predefined algorithm NOTE
OBSW functions include the OBCP engine and execution of OBCPs. 3.2.10 survival mode configuration of a spacecraft in which it can remain safely without ground segment intervention for a specified period NOTE
Survival mode is also commonly known as safe mode. In survival mode, typically all non-essential on-board units or subsystems are powered off, either to conserve power or to avoid interference with other subsystems, and the spacecraft can be (automatically) oriented to a particular attitude with respect to the sun. 3.3 Abbreviated terms The following abbreviations are defined and used within this standard: Abbreviation Meaning AIT assembly, integration and test
The potential uses for OBCPs are therefore categorized in clause 4.2.2 according to the domain of application rather than stakeholder category. SIST EN 16603-70-01:2015

It is not the intention to encourage the late definition of the FDIR strategy, but rather to accommodate the reality that the detailed strategy is often late. The decision about whether or not to use OBCPs for FDIR purposes is part of the trade-off addressed in detail in clause 6.  To accommodate the late delivery of, or the subsequent removal, addition or replacement of equipment.
 To facilitate the tuning of on-board configuration sequences for complex equipment or subsystems following system testing, i.e. these sequences are modified directly avoiding the delays inherent in OBSW modification. • Payload functions  To accommodate the late definition and tuning of: o complex payload configuration or control sequences; o monitoring algorithms and recovery actions. 4.2.2.2 On-board software design and development The benefits of implementing traditional OBSW functions as OBCPs include: • the relative ease of development and validation of OBCPs vs. OBSW; • the core OBSW can be made more generic and is hence potentially reusable across many missions, if mission-specific functions are implemented as OBCPs; • simplification of the OBSW maintenance task, i.e. changes to OBCPs can be easily and safely performed without changing the core OBSW. OBCPs can also be written by OBSW engineers for their own needs, such as: • automation of tests; • investigation and debugging purposes; SIST EN 16603-70-01:2015

However, although the set of OBAPs is qualified as part of the spacecraft design, this SIST EN 16603-70-01:2015

Whilst both types of OBCP may use essentially the same on-board capabilities and may even be similar in complexity: 1. There are major differences in how the two types are accommodated on-board in terms of resource allocation, scheduling and accessible services (see clause 5.4.4.5, for example). 2. The very nature of OBAPs requires that they undergo the same engineering processes as any other integral part of the spacecraft design. In particular, the lifecycle of an OBAP is intimately tied to that of the spacecraft system (as well as any specific platform subsystem or payload to which it relates), in terms of engineering processes and reviews. The lifecycle of an OBOP, on the other hand, is more akin to that of a ground operations procedure. The engineering processes for OBAPs and OBOPs and the corresponding requirements are elaborated in clause 6 of this Standard. 4.4 The OBCP system The OBCP system that supports the stakeholder activities consists of an OBCP preparation environment located on the ground and an OBCP execution environment that is located partly on ground and partly on-board (see Figure 4-1). SIST EN 16603-70-01:2015

Figure 4-1 The OBCP system The OBCP preparation environment is part of the overall test and operations preparation environment and includes: • editors to support the scripting of OBCPs; • execution constraint checking functions (e.g. resource utilization);
• consistency checking functions (e.g. compliance with telemetry and telecommand database definitions); • OBCP configuration management; • OBCP code production;
NOTE
OBCPs exist in two forms: the OBCP script used to define the OBCP and the OBCP code for on-board execution. No assumption is made in this Standard about whether these two forms are the same or whether a transformation (e.g. compilation, pseudo-code generation) is applied to the script to generate the code. • OBCP validation tools e.g. a simulation environment. The requirements for the OBCP preparation environment are contained in clause 5.3 of this Standard. SIST EN 16603-70-01:2015

(optionally) one or more OBCP stores for the intermediate storage of OBCPs prior to loading to an OBCP engine for execution. The mechanisms for transferring the OBCP from ground to an on-board store and the management of OBCPs within on-board stores are outside the scope of this Standard. The OBCP engine and the OBCP preparation environment are designed and developed as an integrated system and the partitioning of capabilities between them may vary from project to project. This Standard assumes that, if there are multiple OBCP engines, they are independent of each other. The requirements for the OBCP execution environment are contained in clause 5.4 of this Standard.
The definition of arguments, including data type, default value, maximum/minimum range of value, is covered by ECSS-E-ST-70-31, clause 6.7.1.2. c. An OBCP shall consist of the following elements: 1. an optional declaration body which declares and initialises variables and declares local functions that are used internally within the OBCP; 2. an optional preconditions body which ensures that the OBCP main body is executed only if (or when) predefined initial conditions are satisfied; 3. a mandatory main body which fulfils the goal of the OBCP; 4. an optional confirmation body which verifies the conditions that determine whether the goal of the OBCP is met; 5. an optional contingency handling body that manages anomalies detected during the execution of the OBCP. d. The nominal execution sequence for an OBCP shall be: 1. declaration body; 2. preconditions body; 3. main body; 4. confirmation body. e. A step construct shall be provided to identify a block of functionally self-contained statements. f. Steps shall be uniquely identified within the context of an OBCP. g. The result generated by the confirmation body shall be used by the OBCP engine to determine the confirmation status of the OBCP. SIST EN 16603-70-01:2015

For example, if all activities initiated by the OBCP were successful and no exception has been detected, then the OBCP confirmation status could be set to “success”. i. A “local function” construct shall be provided to encapsulate a self-contained sequence of statements which accepts input parameters and returns output parameters. j. It shall be possible to initiate the execution of a local function from anywhere within an OBCP. 5.2 OBCP language capabilities 5.2.1 Introduction The OBCP language enables the end-user to define the script of the OBCP, making reference as appropriate to system elements, activities, reporting data and events that are fully-defined within the engineering data repository. In the remainder of this clause, the capabilities of the language are organised as follows: • data types; • OBCP-internal declarations; • assignments; • expressions; • flow controls; • waits; • external interactions; • contingency handling. 5.2.2 General a. The syntax of the OBCP language shall be formally specified. NOTE
For example, using the ISO extended Backus-Naur form (EBNF), see ISO/IEC 14977. b. It shall be possible to include comments in every line of source code.
5.2.3 Data types a. The OBCP language shall support the simple data types specified in clause 5.5 of ECSS-E-ST-70-31. SIST EN 16603-70-01:2015

NOTE
This does not preclude that some implicit type-conversions are also supported. 5.2.4 Declarations a. It shall be possible to declare variables of any data type, including their initialisation values. b. It shall be possible to declare constants of any data type including their values. c. It shall be possible to declare and define local functions. d. A local function shall be uniquely identified within the context of an OBCP. 5.2.5 Assignments a. It shall be possible to assign a value to a variable. NOTE
A variable, defined within the OBCP declaration body, is visible anywhere within the OBCP, including within a local function. 5.2.6 Expressions a. Mathematical, time, string and bitwise operations and functions shall be supported. b. It shall be possible to manipulate arrays, including operations on the elements of arrays. c. It shall be possible to construct expressions that operate on constants, on-board parameters, activity arguments and variables. d. It shall be possible to refer to constants together with their engineering units. e. It shall be possible to mix compatible engineering units freely within an expression. f. The automatic conversion between different, but compatible, engineering units shall be supported. g. It shall be possible to refer to on-board parameters by their names as defined in the engineering data repository. h. It shall be possible to express on-board parameter values in engineering units. i. It shall be possible to express on-board parameter values in the raw form that is downlinked to the ground system. SIST EN 16603-70-01:2015

5.2.7 Flow controls a. It shall be possible to include the following execution controls within an OBCP: 1. simple conditional branching (i.e. if … then … else …); 2. multiple conditional branching where the path taken is dependent on the value of a specified parameter (or variable); 3. repeated execution of a statement (or a group of statements) with the possibility of repeating the execution a specified number of times, repeating the execution indefinitely whilst a given condition holds true or repeating the execution until a given condition becomes true. b. It shall be possible to nest execution control constructs. 5.2.8 Waits a. It shall be possible to specify the following types of wait statement within the main body of an OBCP: 1. wait until a given on-board time; 2. wait for a given interval of time to elapse; 3. wait until a given condition becomes true; 4. wait until a given event occurs;
...