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 operationsICS:Ta slovenski standard je istoveten z:FprEN 16603-70-01kSIST FprEN 16603-70-01:2014en,fr,de01-oktober-2014kSIST FprEN 16603-70-01:2014SLOVENSKI
STANDARD



kSIST FprEN 16603-70-01:2014



EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
FINAL DRAFT
FprEN 16603-70-01
May 2014 ICS 49.140
English version
Space engineering - On-board control procedures
Ingénierie spatiale - Procédures automatiques de contrôle bord
Raumfahrttechnik - Bordseitige Kontrollprozeduren This draft European Standard is submitted to CEN members for unique acceptance procedure. It has been drawn up by the Technical Committee CEN/CLC/TC 5.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN and CENELEC 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.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without notice and shall not be referred to as a European Standard. CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels © 2014 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. FprEN 16603-70-01:2014 E kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 2 Table of contents Foreword . 4 Introduction . 5 1 Scope . 6 2 Normative references . 7 3 Terms, definitions and abbreviated terms . 8 3.1 Terms from other standards . 8 3.2 Terms specific to the present standard . 8 3.3 Abbreviated terms. 10 4 The OBCP concept . 11 4.1 Introduction . 11 4.2 Stakeholders and application areas for OBCPs . 11 4.2.1 Stakeholders . 11 4.2.2 Domains of OBCP application . 12 4.3 Types of OBCP . 13 4.4 The OBCP system . 14 5 OBCP system capabilities . 17 5.1 OBCP structure . 17 5.2 OBCP language capabilities . 18 5.2.1 Introduction . 18 5.2.2 General . 18 5.2.3 Data types . 18 5.2.4 Declarations . 19 5.2.5 Assignments . 19 5.2.6 Expressions . 19 5.2.7 Flow controls . 20 5.2.8 Waits . 20 5.2.9 External interactions . 21 5.2.10 Contingency handling . 22 5.3 The OBCP preparation environment . 22 kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 3 5.3.1 OBCP script preparation . 22 5.3.2 Syntax analysis, consistency, dependency and constraint checking . 23 5.3.3 Report generation . 23 5.3.4 Verification and validation . 23 5.3.5 OBCP characterisation . 24 5.4 The OBCP execution environment . 25 5.4.1 Ground capabilities . 25 5.4.2 OBCP monitoring and control . 25 5.4.3 OBCP integrity . 28 5.4.4 On-board capabilities . 28 6 OBCP engineering processes . 33 6.1 Introduction . 33 6.2 Overall management process of the OBCP system . 34 6.2.1 Management process . 34 6.2.2 OBAP vs. OBSW: criteria and trade-off analysis . 37 6.2.3 OBOP vs. ground-based operations . 38 6.2.4 Trade-off between OBCP engine capability and engineering effort . 39 6.2.5 Overall organization and management . 39 6.3 OBCP engineering . 40 Bibliography . 41
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
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 4 Foreword This document (FprEN 16603-70-01:2014) has been prepared by Technical Committee CEN/CLC/TC 5 “Space”, the secretariat of which is held by DIN (Germany). This document (FprEN 16603-70-01:2014) originates from ECSS-E-ST-70-01C. This document is currently submitted to the Unique Acceptance Procedure. This document has been developed to cover specifically space systems and will the-refore have precedence over any EN covering the same scope but with a wider do-main of applicability (e.g. : aerospace). kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 5 Introduction On-board control procedures (OBCPs) have been implemented on an ad-hoc basis on several European missions over the last 25 years, so the validity and utility of the concept has been amply demonstrated. The purpose of the present Standard is to define an OBCP concept that can be applied for any mission and which: • fulfils the needs of all categories of user (system engineers, on-board software engineers, AIT engineers, operations engineers); • ensures that OBCPs have a development lifecycle that is independent of the remainder of the on-board software (OBSW);. • conforms with, and extends, existing ECSS monitoring and control standards, namely ECSS-E-70-41 and ECSS-E-ST-70-31.
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 6 1 Scope This Standard defines the concept for an OBCP system, identifying the on-board functionality for OBCP execution and the ground functionality for OBCP preparation and subsequent control. This Standard also defines the development lifecycle for OBCPs and identifies the relationships of this lifecycle with the overall space system, and in particular with the other elements of the on-board software.
This Standard assumes that missions implementing OBCPs are also compliant with ECSS-E-70-41, since a number of services contained therein are invoked in support of the operation of OBCPs and their interaction with the ground. This Standard may be tailored for the specific characteristic and constraints of a space project in conformance with ECSS-S-ST-00.
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 7 2 Normative references The following normative documents contain provisions which, through reference in this text, constitute provisions of this ECSS Standard. For dated references, subsequent amendments to, or revision of any of these publications do not apply. However, parties to agreements based on this ECSS Standard are encouraged to investigate the possibility of applying the more recent editions of the normative documents indicated below. For undated references, the latest edition of the publication referred to applies.
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
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 8 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards For the purpose of this Standard, the terms and definitions from ECSS-ST-00-01, ECSS-E-ST-70, ECSS-E-ST-70-31 and ECSS-E-70-41 apply, in particular for the following terms: activity event event reporting service ground system on-board parameter operations procedure space project spacecraft 3.2 Terms specific to the present standard 3.2.1 automation replacement of manual operations by computerized mechanisms 3.2.2 on-board control procedure software program designed to be executed by an OBCP engine, which can easily be loaded, executed, and also replaced, on-board the spacecraft
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. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 9 NOTE 2 In service 18 of ECSS-E-70-41A, OBCP code is referred to as procedure code. 3.2.4 OBCP engine application of the on-board software handling the execution of OBCPs NOTE
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. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 10 3.3 Abbreviated terms The following abbreviations are defined and used within this standard: Abbreviation Meaning AIT assembly, integration and test AOCS attitude and orbit control subsystem AR acceptance review CDR critical design review CPDU command pulse distribution unit CPU central processor unit DDR detailed design review EBNF extended Backus-Naur form EEPROM electrically erasable programmable read-only memory EGSE electrical ground support equipment FDIR failure detection, isolation and recovery I/O input/output MCS mission control system OBAP on-board application procedure OBCP on-board control procedure OBOP on-board operations procedure OBSW on-board software PDR preliminary design review QR qualification review RAM random access memory SDE software development environment SRR system requirements review TRR test results review
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 11 4 The OBCP concept 4.1 Introduction The OBCP concept is that of a procedure to be executed on-board, which can easily be loaded, executed, and also replaced, on-board the spacecraft without modifying the remainder of the on-board software. 4.2 Stakeholders and application areas for OBCPs 4.2.1 Stakeholders Several categories of OBCP stakeholder are identified, each of whom has a distinct role in a space project, with corresponding responsibilities: • System engineers (spacecraft and payload); • On-board software engineers; • AIT engineers; • Operations engineers. There is continuous interaction and cooperation between these stakeholders throughout the development and operation lifecycle of a space system, for example: • during the spacecraft design phase, operations engineers are involved to ensure the operability of the overall space system; • during in-orbit operations, system and software engineers support commissioning and troubleshooting activities. The system or software responsibility may be transferred from the satellite prime contractor to the operations organization at some predetermined time after launch (e.g. in the case of long-duration missions).
The potential uses for OBCPs are therefore categorized in clause 4.2.2 according to the domain of application rather than stakeholder category. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 12 4.2.2 Domains of OBCP application 4.2.2.1 System design Typical scenarios where it may be decided to implement on-board functionality as OBCPs rather than as OBSW include: • Platform functions  To isolate mission-specific platform functions from the remainder of the OBSW, e.g. thermal control or battery control.  To implement one-shot applications that are deleted after use, e.g. deployment of appendices, firing of pyrotechnics.  To accommodate the late specification of the detailed FDIR strategy and to facilitate the tuning of this strategy during system testing. NOTE
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; kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 13 • the implementation of short-term workaround solutions for system or software problems without the need to wait for a new software delivery. 4.2.2.3 AIT OBCPs are useful tools for AIT engineers for testing and validation purposes during the AIT programme on-ground (i.e. not for in-flight use), for example: • to perform fault injection for robustness testing, especially scenarios that are not feasible with traditional means (e.g. telemetry and telecommand, observation and stimulus); • to implement long and complex configuration sequences for well-defined and repetitive scenarios; • to develop temporary functions of the OBSW for testing purposes. 4.2.2.4 Operations and operability The availability of OBCPs enables operations procedures (both for routine functions and contingency operations) to be executed on-board as an alternative to on the ground (either under manual control or automated in the mission control system). This can streamline the operations (reduction of bandwidth, potential reduction in operations manpower, reduction in the loop delay inherent in ground control, simplification of ground procedures) as well as increasing their overall reliability. The use of OBCPs also enhances the on-board autonomy capabilities and increases the robustness to ground station outages. This applies both where there is continuous visibility from ground (e.g. geostationary missions) and where ground station coverage is discontinuous (e.g. LEO and deep-space missions). In addition, the use of OBCPs facilitates the adaptation to prevailing mission conditions, e.g.: • the implementation of on-board solutions to counteract unforeseen failures occurring in orbit; • unpredictable environment, which can be encountered in deep-space missions; • the implementation of end-of-life operations (e.g. deorbiting). 4.3 Types of OBCP From the potential application of OBCPs described in clause 4.2.2, two types of OBCP can be distinguished: 1. “On-board Application Procedures (OBAP)” which implement part of the basic functionality of the spacecraft, i.e. which are an integral part of the spacecraft design. The overall qualification of the spacecraft requires the integration of the complete set of OBAPs. Historically, this type of OBCP has been called “Application Program” or “Flight Application Program”. NOTE
However, although the set of OBAPs is qualified as part of the spacecraft design, this kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 14 does not imply that they are not maintained (i.e. possibly updated) after launch. 2. “On-Board Operations Procedures (OBOP)” that are used to “operate” the spacecraft, but which are not involved in the qualification of the spacecraft.
Whilst both types of OBCP may use essentially the same on-board capabilities and may even be similar in complexity: 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). kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 15
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. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 16 In accordance with ECSS-E-ST-10, all space system data is maintained within a repository called the engineering data repository. As defined in ECSS-E-ST-70-31, the monitoring and control component of the engineering data repository includes the definitions of system elements (corresponding to the hierarchical decomposition of the space system), activities (e.g. telecommands, ground procedures and OBCPs), reporting data (e.g. telemetry parameters) and events (occurrences of predefined conditions that can be used to trigger monitoring and control functions). The engineering data repository is therefore the repository for OBCPs that are developed and validated in the OBCP preparation environment and is also the repository from which they are accessed later by the execution environment. The configuration management of OBCPs is handled by the generic configuration management function of the engineering data repository and is not addressed further within this Standard. The OBCP execution environment is part of the overall test and operations monitoring and control environment and includes: • A ground part with:  dedicated services for uplinking OBCPs, monitoring and controlling their execution;  the means to visualize the on-board execution environment (including the status of the on-board OBCPs);  constraint and consistency checking functions. • An on-board part with:  one or more OBCP engines which: o provide monitoring and control services for interfacing with the ground or onboard services; o provide standard services for interaction with other on-board systems (on-board software, platform subsystems and payloads); o manage the execution of OBCPs. 
(optionally) one or more OBCP stores for the intermediate storage of OBCPs prior to loading to an OBCP engine for execution. The mechanisms for transferring the OBCP from ground to an on-board store and the management of OBCPs within on-board stores are outside the scope of this Standard. The OBCP engine and the OBCP preparation environment are designed and developed as an integrated system and the partitioning of capabilities between them may vary from project to project. This Standard assumes that, if there are multiple OBCP engines, they are independent of each other. The requirements for the OBCP execution environment are contained in clause 5.4 of this Standard.
kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 17 5 OBCP system capabilities 5.1 OBCP structure a. Each OBCP shall have a unique “OBCP Identifier”, which is assigned by the ground system. b. It shall be possible to define “arguments” for an OBCP i.e. parameters whose values are input to the OBCP at initiation time. NOTE
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. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 18 h. In the case that there is no confirmation body, an implicit confirmation status shall be set by the OBCP engine. NOTE
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. kSIST FprEN 16603-70-01:2014



FprEN 16603-70-01:2014 (E) 19 b. The OBCP language shall support the definition of structured data types i.e. arrays and records. c. The OBCP language shall support explicit type-casting constructs.
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 withi
...