SIST EN 16603-70-32:2014

Space engineering - Test and operations procedure language

This Standard specifies:
•   The capabilities of the language used for the definition of procedures for space system testing and operations.
•   The PLUTO language.
Clause 4 defines the context in which procedures operate.
Clause 5 contains the requirements for  the procedure language.
Annex A specifies the PLUTO language. This includes:
•   The “building blocks” that constitute procedures and the role that each of these building blocks plays in achieving the overall objectives
of the procedure.
•   The dynamic aspects of procedures i.e. the execution logic of each building block and execution relationships between these blocks.
•   The syntax and semantics of the language itself.
Annex B specifies the engineering units to be supported by the procedure language.
Annex C specifies the mathematical, time and string functions to be supported by the procedure language.
This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00.

Raumfahrttechnik - Sprache für Test- und Bedienprozeduren

Ingénierie spatiale - Language de procedure pour les essais et des operations

Vesoljska tehnika - Jezik za postopke preskušanja in obratovanja

Standard EN 16603-70-32 določa: - zmogljivosti jezika, uporabljenega za opredelitev postopkov za preskušanje vesoljskih sistemov in obratovanja. - jezik PLUTO. Točka 4 določa okvir za obratovanje postopkov. Točka 5 vsebuje zahteve za jezik postopka. Dodatek A določa jezik PLUTO. Sem spadajo: - »gradniki«, ki sestavljajo postopke in vlogo, ki jo ima vsak od teh gradnikov pri doseganju skupnih ciljev postopka, - dinamični vidiki postopkov, tj. izvedbena logika vsakega gradnika in izvedbena razmerja med temi gradniki, - skladnja in semantika jezika kot takega. Dodatek B določa inženirske enote, ki naj jih podpira jezik postopka. Dodatek C določa matematične in časovne funkcije ter funkcije niza, ki naj jih podpira jezik postopka. Ta standard se lahko prilagodi posameznim lastnostim in omejitvam vesoljskega projekta v skladu s standardom ECSS-S-ST-00.

General Information

• Status: Published
• Publication Date: 22-Oct-2014
• ICS: 35.060 - Languages used in information technology
• ICS: 49.140 - Space systems and operations
• Technical Committee: I13 - Imaginarni 13
• Current Stage: 6060 - National Implementation/Publication (Adopted Project)
• Start Date: 24-Sep-2014
• Due Date: 29-Nov-2014
• Completion Date: 23-Oct-2014
• Mandate: M/496 - Mandate addressed to CEN, CENELEC and ETSI to develop standardisation regarding space industry (Phase 3 of the process)
• Ref Project: EN 16603-70-32:2014 - Space engineering - Test and operations procedure language

Overview - SIST EN 16603-70-32:2014 (Space engineering - Test and operations procedure language)

SIST EN 16603-70-32:2014 defines the capabilities and requirements for a procedure language used to create automated test and operations procedures for space systems. The standard introduces the reference language PLUTO (Procedure Language for Users in Test and Operations) and describes the context in which procedures execute (Clause 4), the requirements any procedure language must satisfy (Clause 5), and detailed PLUTO syntax and semantics (Annex A). Annex B lists supported engineering units and Annex C defines the supported mathematical, time and string functions. The standard may be tailored for specific projects in conformance with ECSS‑S‑ST‑00.

Key topics and technical requirements

• Procedure context and space system model: Defines how procedures interact with a space system model, EGSE and mission control system (EMCS), reporting data, events, activities and system elements.
• Language requirements (Clause 5): Covers procedure structure, required language constructs, and formal specification techniques.
• PLUTO language (Annex A):
  • Building blocks: procedures, steps, activities, watchdogs, preconditions and confirmation bodies.
  • Dynamic behavior: execution logic, parallel execution, continuation rules and confirmation semantics.
  • Formal syntax & semantics: keywords, identifiers, types, EBNF grammar and predefined operators.
• Engineering units (Annex B): Standardized unit symbols and compound unit rules to ensure consistent data interpretation.
• Functions (Annex C): Required mathematical, time and string function sets for expression evaluation and condition handling.
• Standards conformance & tailoring: Encourages project-specific tailoring while preserving conformance to ECSS-S-ST-00.

Practical applications and users

• Use cases:
  • Automated test procedure authoring for AIV and satellite testing (pre-launch).
  • Automated operational procedures for mission control and in‑orbit operations.
  • Formalized handover procedures between ground segment tools (EGSE, SCOE, MCS).
• Who benefits:
  • Mission operations engineers and test engineers writing deterministic, machine‑executable procedures.
  • Software developers and tool vendors implementing procedure execution engines and procedure editors.
  • Systems engineers and standards teams seeking consistent procedure definition across projects.

Related standards

• ECSS-E-ST-70-32 (origin of the PLUTO definition) and ECSS‑S‑ST‑00/EN 16601‑00‑01 (system glossary) are normative references.
• ISO/IEC 14977 (EBNF) is used for the formal grammar representation.

This standard is essential for organizations seeking a formal, interoperable approach to authoring and executing space test and operations procedures using a defined language (PLUTO), consistent units and function libraries. Keywords: PLUTO, procedure language, space engineering, test procedures, mission operations, EGSE, EMCS, engineering units, EBNF.

Standards Content (Sample)

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Vesoljska tehnika - Jezik za postopke preskušanja in obratovanjaRaumfahrttechnik - Sprache für Test- und BedienprozedurenIngénierie spatiale - Language de procedure pour les essais et des operationsSpace engineering - Test and operations procedure language49.140Vesoljski sistemi in operacijeSpace systems and operations35.060Jeziki, ki se uporabljajo v informacijski tehniki in tehnologijiLanguages used in information technologyICS:Ta slovenski standard je istoveten z:EN 16603-70-32:2014SIST EN 16603-70-32:2014en,fr,de01-november-2014SIST EN 16603-70-32:2014SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16603-70-32
September 2014 ICS 49.140
English version
Space engineering - Test and operations procedure language
Ingénierie spatiale - Language de procedure pour les essais et des operations
Raumfahrttechnik - Sprache für Test- und Bedienprozeduren This European Standard was approved by CEN on 6 March 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 © 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. EN 16603-70-32:2014 E SIST EN 16603-70-32:2014

Engineering units . 120 B.1 Introduction . 120 B.2 Engineering units and symbols . 120 B.3 Engineering units railroad diagrams . 126 B.4 EBNF representation of the engineering units . 129 Annex C (informative) Functions . 131 C.1 Introduction . 131 C.2 Mathematical functions . 131 C.3 Time functions . 134 C.4 String functions . 135 Bibliography . 137
Figures Figure 4-1: Example of space system elements . 13 SIST EN 16603-70-32:2014

Figure A-1 : Example of a procedure and its elements . 24 Figure A-2 : Execution states and transitions for a procedure . 31 Figure A-3 : Execution states and transitions for a step . 33 Figure A-4 : Execution states and transitions for an activity . 34 Figure A-5 : Confirmation status and continuation action combinations for main body “initiate and confirm” statements . 36 Figure A-6 : Confirmation status and continuation action combinations for watchdog “initiate and confirm” statements . 36 Figure A-7 : Example railroad diagram . 38
Tables Table A-1 : Predefined types . 43 Table A-2 : Activity and step operation requests . 78 Table A-3 : Reporting data, variable and argument operation requests . 78 Table A-4 : Predefined operators . 97 Table A-5 : Activity and step property requests . 101 Table A-6 : Reporting data, variable and argument property requests . 102 Table A-7 : Event property requests . 102 Table A-8 : EBNF symbols and meanings . 104 Table B-1 : Simple engineering units . 121 Table B-2 : Acceptable multiple and submultiple of engineering unit . 123 Table B-3 : Acceptable multiples of binary engineering units . 124 Table B-4 : Standard compound engineering units . 124 Table C-1 : Mathematical functions . 131 Table C-2 : Time functions . 134 Table C-3 : String functions . 135
It also defines a reference language that fulfils these requirements. This language is called the “procedure language for users in test and operations (PLUTO)”. SIST EN 16603-70-32:2014

the procedure language. Annex A specifies the PLUTO language. This includes: • The “building blocks” that constitute procedures and the role that each of these building blocks plays in achieving the overall objectives of the procedure. • The dynamic aspects of procedures i.e. the execution logic of each building block and execution relationships between these blocks. • The syntax and semantics of the language itself. Annex B specifies the engineering units to be supported by the procedure language. Annex C specifies the mathematical, time and string functions to be supported by the procedure language. This standard may be tailored for the specific characteristics and constraints of a space project in conformance with ECSS-S-ST-00. SIST EN 16603-70-32:2014

EN reference Reference in text Title EN 16601-00-01 ECSS-S-ST-00-01 ECSS system – Glossary of terms
ISO/IEC 14977 Information technology - Syntactic metalanguage – Extended BNF
3.2.4 continuation test language construct used to define how the execution of a procedure (or step) proceeds after a constituent step (or activity) has been executed 3.2.5 event occurrence of a condition or set of conditions that can arise during the course of a test session or a mission phase 3.2.6 initiation act of requesting the execution of a step or an activity 3.2.7 main body part of a procedure (or step) dedicated to achieving the objectives of the procedure (or step) SIST EN 16603-70-32:2014

NOTE
Reporting data can consist of a parameter (a simple type) or a compound parameter (a complex type). 3.2.12 space system model representation of the space system in terms of its decomposition into system elements, the activities that can be performed on these system elements, the reporting data that reflects the state of these system elements and the events that can be raised and handled for the control of these system elements, activities or reporting data
3.2.13 statement element of the procedure language which, together with other elements, implements the goal of a procedure (or step) 3.2.14 step component of a procedure that achieves a well-defined sub-goal 3.2.15 system element representation within the space system model of a functional element of the space system 3.2.16 watchdog body part of a procedure (or step) which manages contingency situations that can arise during the execution of the procedure (or step) 3.2.17 watchdog step component of the watchdog body dedicated to detecting the occurrence of a particular contingency condition and executing corrective actions SIST EN 16603-70-32:2014

Abbreviation Meaning AIV assembly, integration and verification EBNF extended Backus-Naur form EGSE electrical ground support equipment EMCS EGSE and mission control system FCP flight control procedure FOP flight operations plan MMI man-machine interface PLUTO procedure language for users in test and operations SCOE special check-out equipment SSM space system model
Ground
Ground Station
Mission Control
OCS PCS MES EGSE
SSCS SSCS SSC ME ME ME GCS Key: OCS: Operation control system SSC: Space segment control station
PCS: Payload control system ME: Mission exploitation station
MES: Mission exploitation system GCS: Ground communications subnet
AIV: Assembly, integration and verification Space
Spacecraft B Platfor Payloa Onboar subne Spacecraft
Platfor Payloa Onboard Subnet
Space Subnet AIV Subnet Launch Vehicle A Launch Service Segment Launch Vehicle B Launch Vehicle C Launch Facility Pre-Launch Service Link Comms Link
Figure 4-1: Example of space system elements 4.1.2 Satellite testing ECSS-E-ST-10, ECSS-E-ST-10-02 and ECSS-E-ST-10-03 define the requirements for space system engineering, verification and testing. This Standard does not prescribe the levels of integration and test at which procedures are used. This is considered to be a decision taken when the verification approach for a specific mission is defined. However, automated procedures are generally employed from the subsystem level upwards. The re-use of test procedures at different levels of integration implies standardization of the functionality of the EGSE. Furthermore, the re-use of these procedures in the mission operations domain implies the harmonisation of the requirements for EGSE and mission control systems.
• Nominal procedures These define the set of in-orbit operations of the space system to be used under nominal conditions. They constitute the building blocks from which the mission timelines and schedules of the flight operations plan (FOP) are constructed.
• Contingency procedures These define the recovery actions used to reconfigure the space system if pre-identified anomalies or failures occur. Although FCPs have traditionally been executed under manual control, pressure to reduce manpower during routine mission operations implies more automation of routine tasks such as the execution of procedures. 4.2 EGSE and mission control system (EMCS) 4.2.1 General In this Standard, the elements of the ground segment responsible for the monitoring and control of the overall space system, namely the EGSE and the mission control system are referred to jointly as the EMCS. The procedure language and the procedure development and execution environments are an integral part of any EMCS. As such, they have direct access to other monitoring and control functions implemented within the overall EMCS.
4.2.2 Space system model ECSS-E-ST-70-31 introduces the concept of a space system model (SSM) as a means for capturing mission knowledge used during AIV and operations. This knowledge is used by the different EMCS applications in order to interact with the space system and to process the dynamic data that is exchanged with it (i.e. space segment telemetry and telecommands, ranging data, ground segment commands and measurements). The SSM consists of different types of object and the relationships between these objects. The objects of relevance for the procedure language are system elements, reporting data, activities and events. System elements correspond to: • the elements of the space segment resulting from the functional decomposition defined in ECSS-S-ST-00; • the elements of the ground segment resulting from the functional decomposition defined in ECSS-E-ST-70. SIST EN 16603-70-32:2014

• Reporting data comprises parameters and compound parameters. A parameter is the lowest level of elementary information that has a meaning for monitoring the space system.
A compound parameter is a record comprised of any sequence of parameters, arrays of parameters and sub-records (see also ECSS-E-ST-70-41). For example, a complete telemetry packet, or part thereof, may be represented as a compound parameter. The parameters within a compound parameter are normally interpreted together (e.g. when interpreting the contents of an anomaly report). Reporting data can have different representations depending on its life cycle within the space system (e.g. an on-board measurement has an encoded value in telemetry and a raw or engineering value when presented on a ground segment display). • An activity is a space system monitoring and control function. The term activity is introduced to refer generically to procedures, telecommands (either to the space segment or to the ground segment) and any function provided by the underlying EMCS (e.g. a printer request, sending an e-mail, transferring a file using ftp). A given mission can implement additional mission-specific activity types (e.g. conforming to a non-standard protocol). Events are associated with system elements, reporting data and activities. An event is an occurrence of a condition or set of conditions that can arise during the course of a test session or a mission phase. It is used to trigger a monitoring and control function implemented within the space system. An example of a space system model is shown in Figure 4-1.
In order to understand the scope of the procedure language, it is important to understand what is provided by the SSM. The SSM (as specified in ECSS-E-ST-70-31) provides the definition of space system configurations, system elements, activities, reporting data and events. The procedure language provides the means to: • refer to system elements, activities, reporting data and events but not to define them; • define the procedural script. For activities, the common set of data definitions in the SSM includes: • name; • description; SIST EN 16603-70-32:2014

f. Where the achievement of a sub-goal involves complex logic (such as waiting for a period of time, waiting for a condition to become true or conditional branching), a step construct shall be provided to encapsulate the logic. g. The capability shall be provided to execute procedure sub-goals in series or in parallel. NOTE
Parallel execution is used, for example, when two or more steps can be performed completely independently. h. Preconditions may be specified for a procedure. NOTE
Preconditions are conditions to be fulfilled before the procedure can start. i. Confirmation conditions may be specified for a procedure. NOTE
Confirmation conditions are those conditions that determine whether the goal of a procedure is met. j. Preconditions and confirmation conditions may also be defined for steps. k. In addition to the “nominal flow path” of a procedure (i.e. the flow designed to achieve its primary goal), contingency actions may also be defined. l. A procedure contingency action may be executed upon: SIST EN 16603-70-32:2014

n. A step contingency action may be executed upon: 1. detection of a failure in the execution of the nominal path; 2. other specified events or conditions. o. A contingency action should be taken at the level at which a failure occurs, i.e. if a failure occurs in the execution of a step, a contingency action should be taken at the level of the step. p. A contingency action should rectify the detected anomaly or report it to the user and return control to the nominal flow path of the procedure (or step). q. If an anomaly cannot be rectified, one of the following actions shall be performed: 1. generate an event to flag the problem at a higher level for resolution; 2. use other means to achieve the goal of the procedure (or sub-goal of a step) and then terminate the procedure (or step); 3. abort the procedure (or step). r. If a contingency action is invoked, the body of the procedure (or step) shall be suspended until the contingency action is completed. 5.2 Language constructs a. The capability shall be provided to request the execution of any space system activity. b. The capability shall be provided to request the execution of an activity and proceed immediately with the execution of the next statement of the procedure. c. The capability shall be provided to request the execution of an activity and wait for the confirmation of execution before continuing. d. When a procedure waits for the confirmation of execution of an activity, the result of the execution of the activity shall be tested in order to determine the subsequent course of action. e. The capability shall be provided to acquire the following data: 1. the execution status or confirmation status of an initiated activity; 2. the initiation time, start time, termination time or completion time of the last execution of an activity; 3. the value of reporting data; SIST EN 16603-70-32:2014

This ensures that the procedure uses properties of reporting data that have been sampled at the same instant in time. h. To ensure that any service provided by the EMCS is accessible within a procedure, the following capabilities shall be provided: 1. to request any operation defined for any space system object; 2. to acquire the value of any property of any space system object. i. The capability shall be provided to perform the following execution flow controls within a procedure: 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 local variable, see j below); 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; 4. wait until a given absolute time; 5. wait for a given interval of time to elapse; 6. wait until a given condition becomes true; 7. wait until a given event occurs. SIST EN 16603-70-32:2014

Use of the PLUTO language ensures conformance with all requirements of this Standard. It also facilitates the transfer of procedure knowledge, acquired in the development phase during functional testing, to the mission operations phase (for a given mission) and encourages the use of a common procedure language across missions. SIST EN 16603-70-32:2014

b. An optional preconditions body, which ensures that the procedure is only executed if (or when) pre-defined initial conditions are satisfied. c. A mandatory main body, which fulfils the goal of the procedure. The main body can be composed of self-contained sub-goals fulfilled by activities or steps. d. An optional watchdog body, which manages contingency situations that can arise during the execution of the procedure. The watchdog body is composed of one or more special steps, called watchdog steps, which are all initiated in parallel. e. An optional confirmation body, which assesses whether the objectives of the procedure have been achieved or not.
An example of a procedure and its elements is shown in Figure A-1. SIST EN 16603-70-32:2014

Preconditions Body Main Body Sequential sub-goals
Parallel sub-goals Watchdog Body Confirmation Body Watchdog Step Watchdog Step Declaration Body Sub-goal Sub-goal Sub-goal Sub-goal Sub-goal
Figure A-1: Example of a procedure and its elements A.1.2 Procedure declaration body Local events that can be raised within the procedure, but which are accessible outside of the step in which they are raised (e.g. events that trigger a procedure-level watchdog, see clause A.1.5), are declared at procedure level. Arguments may be passed to a procedure at initiation time by the entity calling the procedure. These arguments are defined externally (see clause 4.2.2) and not as part of the procedure declarations. Arguments are similar to parameters in their definition and use. Argument values cannot be changed within a procedure. A.1.3 Procedure preconditions body The preconditions body contains the conditions that define whether a procedure can start. They may be any combination of the following: • wait until a given absolute time; • wait for a given time interval to elapse; • wait until a given condition becomes true; • if the result of a logical expression (Boolean condition) is true; • request a decision from the user. SIST EN 16603-70-32:2014

The purpose of the procedure watchdog body is the following: • Detection of, and reaction to, system-level events, for example space system anomalies. The procedure watchdog body need not rectify all anomalies internally; it can suspend or abort the procedure whilst another procedure handles the anomaly. • Ensuring that procedure-level invariant conditions are sustained for the duration of the procedure. • Management of errors (e.g. failures) in procedure execution that cannot be handled by the watchdog of the relevant procedure main body step (see clause A.1.7.5). NOTE
Error handling following execution of a procedure is managed by the calling entity.
Contingency situations monitored for by concurrently active watchdog steps are independent of each other. The reason for this is that when a watchdog step is triggered, it suspends the main body of the corresponding procedure whilst it takes the appropriate recovery action, but any other watchdog steps that are active continue their monitoring. Consequently, if there is any potential interaction between two or more contingency actions, the design of the procedure ensures that they are handled within the same watchdog step. SIST EN 16603-70-32:2014

The preconditions body is mandatory for a watchdog step (since the preconditions body defines the contingency condition for which the watchdog step is monitoring). A.1.7.2. Step declaration body The following are declared at step level: • Local variables: the objects defined for internal use within a step. Local variables are similar to parameters in their definition and use. They have an engineering value and a validity status, which is "invalid" until the variable is first assigned a value. Local variables can be used by steps contained within a step and also by watchdog steps within the step watchdog body. • Local events: the events that can be raised within the step and which are only accessible from within that step. SIST EN 16603-70-32:2014

Error handling following execution of a step is managed by the calling entity. A.1.7.6. Step conf
...