SIST EN 16603-70-32:2014

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



SIST EN 16603-70-32:2014



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



EN 16603-70-32:2014 (E) 2 Table of contents Foreword . 5 Introduction . 6 1 Scope . 7 2 Normative references . 8 3 Terms, definitions and abbreviated terms . 9 3.1 Terms from other standards . 9 3.2 Terms specific to the present standard . 9 3.3 Abbreviated terms. 11 4 Context of the procedure language . 12 4.1 Introduction . 12 4.1.1 The space system . 12 4.1.2 Satellite testing . 13 4.1.3 Mission operations . 14 4.2 EGSE and mission control system (EMCS) . 14 4.2.1 General . 14 4.2.2 Space system model . 14 5 Requirements to be satisfied by procedures . 18 5.1 Procedure structure . 18 5.2 Language constructs . 19 5.3 Language specification . 22 Annex A (informative) The PLUTO language . 23 A.1 The structure of a procedure . 23 A.1.1 Procedure definition . 23 A.1.2 Procedure declaration body . 24 A.1.3 Procedure preconditions body . 24 A.1.4 Procedure main body . 25 A.1.5 Procedure watchdog body . 25 A.1.6 Procedure confirmation body . 26 SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 3 A.1.7 Structure of a step . 26 A.2 The behaviour of a procedure . 28 A.2.1 Procedure execution flow . 28 A.2.2 Step execution flow . 31 A.2.3 Activity execution flow . 33 A.2.4 Execution in parallel . 34 A.2.5 Continuation following an “initiate and confirm” statement . 35 A.3 PLUTO language definition . 37 A.3.1 Conventions . 37 A.3.2 Language case sensitivity . 38 A.3.3 Comments . 38 A.3.4 Keywords . 38 A.3.5 Identifiers . 39 A.3.6 Constants . 40 A.3.7 Types . 43 A.3.8 System interfaces . 44 A.3.9 Language constructs . 45 A.4 Extended Backus-Naur form (EBNF) representation of PLUTO language constructs . 103 A.4.1 Conventions . 103 A.4.2 PLUTO language constructs . 105 A.5 Index of PLUTO language constructs . 117 Annex B (informative)
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



EN 16603-70-32:2014 (E) 4 Figure 4-2: Example of a space system model . 16
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
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 5 Foreword This document (EN 16603-70-32:2014) has been prepared by Technical Committee CEN/CLC/TC 5 “Space”, the secretariat of which is held by DIN. This standard (EN 16603-70-32:2014) originates from ECSS-E-ST-70-32C. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by March 2015, and conflicting national standards shall be withdrawn at the latest by March 2015. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document has been prepared under a mandate given to CEN by the European Commission and the European Free Trade Association. This document has been developed to cover specifically space systems and has therefore precedence over any EN covering the same scope but with a wider domain of applicability (e.g. : aerospace). According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: 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 the United Kingdom. SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 6 Introduction The procedure is the principal mechanism employed by the end-user to control the space system during pre-launch functional testing and post-launch in-orbit operations. This Standard identifies the requirements to be satisfied by any language used for the development of automated test and operation procedures.
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



EN 16603-70-32:2014 (E) 7 1 Scope 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. SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 8 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 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.
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
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 9 3 Terms, definitions and abbreviated terms 3.1 Terms from other standards For the purpose of this Standard, the terms and definitions from ECSS-S-ST-00-01 apply. 3.2 Terms specific to the present standard 3.2.1 activity space system monitoring and control function 3.2.2 compound parameter record comprised of any sequence of reporting data, arrays of reporting data and sub-records that are interpreted together EXAMPLE An anomaly report generated by the space segment comprising an anomaly report ID and a set of associated parameters. 3.2.3 confirmation body part of a procedure (or step) whose purpose is to assess whether or not the objective of the procedure (or step) has been achieved
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



EN 16603-70-32:2014 (E) 10 3.2.8 parameter lowest level of elementary information that has a meaning for monitoring the space system 3.2.9 preconditions body part of a procedure dedicated to ensuring that the procedure only executes if or when pre-defined initial conditions are satisfied 3.2.10 procedure means for interacting with the space system in order to achieve a given objective or sequence of objectives 3.2.11 reporting data data used for assessing the functioning of the space system
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



EN 16603-70-32:2014 (E) 11 3.3 Abbreviated terms For the purpose of this Standard, the abbreviated terms from ECSS-S-ST-00-01 and the following apply:
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
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 12 4 Context of the procedure language 4.1 Introduction 4.1.1 The space system ECSS-S-ST-00 defines the overall space system as comprising a space segment, a ground segment and a launch service segment. An example of the elements of a space system is shown in Figure 4-1. The space system elements shown in this figure are operational at different times: • the electrical ground support equipment (EGSE) during the development phase; • the launch service segment during the pre-launch and launch phases; • the mission control and ground station systems during the mission operations phase.
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 13
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.
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 14 4.1.3 Mission operations ECSS-E-ST-70 identifies procedures as the primary mechanism for conducting mission operations and defines two types of flight control procedures (FCP):
• 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



EN 16603-70-32:2014 (E) 15 Reporting data and activities are associated with system elements:
• 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.
SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 16 Space segmentTemperatureSwitch OnSpace systemGround segmentAOCSPower subsystemStar trackerOptical headEGSEMCSGround StationBaseband equipmentTelemetry decoderSwitch OnBackground Count ReportTelemetry Lock StatusGo NoGo StatusSource CountSwitch On FailureUndervoltageEventKey:Reporting dataActivity Figure 4-2: Example of a space system model During the course of spacecraft testing and mission operations, the space system is configured in different ways, for example: • to test elements of the space segment in a stand-alone manner; • to test the space segment during integration when some elements are missing; • to validate the ground segment with a simulated space segment. The concepts of system elements, activities, reporting data and events provide a complete definition of the SSM independent of any specific space system configuration. However, for a given space system configuration, only a subset of the overall SSM is used.
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



EN 16603-70-32:2014 (E) 17 • type (procedure, telecommand or operating system call); • associated system element; • version number and configuration history; • validation status (i.e. information on the testing status of the activity); • validity period, i.e. the earliest and the latest date on which the activity can be executed; • expected (i.e. mean) duration; • maximum and minimum durations; • list of arguments, including for each argument:  name,  description,  engineering units,  data type, and  default value; • allowed combinations of argument values; • other attributes used for mission planning purposes such as the profile of resources that the activity utilizes (e.g. onboard power and downlink bandwidth). In addition, the different types of activity have type-specific definitions; for procedures, this includes: • default execution mode (manual or automatic); • activation mode (i.e. whether the procedure is permanently active or is explicitly initiated); • the procedural script. SIST EN 16603-70-32:2014



EN 16603-70-32:2014 (E) 18 5 Requirements to be satisfied by procedures 5.1 Procedure structure a. The capability shall be provided to construct a high-level, goal-oriented activity (namely a procedure) using elementary activities consisting of telecommands and operating system calls. b. A procedure may include calls to execute other procedures. c. The capability shall be provided to define self-contained sub-goals for a procedure. d. A given sub-goal may be achieved by a single activity call or a sequence of activity calls. e. An activity may have associated arguments whose values are passed to the activity at the time of initiation.
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. I
...