SIST EN 16603-70-41:2017

SLOVENSKI STANDARD
01-december-2017
1DGRPHãþD
SIST EN 14776:2005
Vesoljska tehnika - Uporaba telemetrije in daljinskega vodenja podatkovnih
paketov
Space engineering - Telemetry and telecommand packet utilization
Raumfahrttechnik - Telemetrie und Telekommando
Ingénierie spatiale - Utilisation de la télémétrie et de la télécommande par paquets
Ta slovenski standard je istoveten z: EN 16603-70-41:2017
ICS:
33.200 Daljinsko krmiljenje, daljinske Telecontrol. Telemetering
meritve (telemetrija)
49.140 Vesoljski sistemi in operacije Space systems and
operations
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

EUROPEAN STANDARD
EN 16603-70-41
NORME EUROPÉENNE
EUROPÄISCHE NORM
October 2017
ICS 49.140
Supersedes EN 14776:2004
English version
Space engineering - Telemetry and telecommand packet
utilization
Ingénierie spatiale - Utilisation de la télémétrie et de la Raumfahrttechnik - Telemetrie und Telekommando
télécommande par paquets
This European Standard was approved by CEN on 30 June 2017.

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,
Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.

CEN-CENELEC Management Centre:
Avenue Marnix 17, B-1000 Brussels
© 2017 CEN/CENELEC All rights of exploitation in any form and by any means Ref. No. EN 16603-70-41:2017 E
reserved worldwide for CEN national Members and for
CENELEC Members.
Table of contents
European Foreword . 6
Introduction . 8
1 Scope . 9
2 Normative references . 11
3 Terms, definitions and abbreviated terms . 12
3.1 Terms from other standards . 12
3.2 Terms specific to the present standard . 12
3.3 Abbreviated terms. 16
3.4 Nomenclature . 17
4 Context and background . 18
4.1 Introduction . 18
4.2 Modelling the PUS . 21
5 The PUS foundation model . 25
5.1 Introduction . 25
5.2 Convention . 26
5.3 The generic service type abstraction level . 26
5.4 The generic service deployment abstraction level . 38
6 Service type system requirements . 55
6.1 ST[01] request verification . 55
6.2 ST[02] device access . 63
6.3 ST[03] housekeeping . 76
6.4 ST[04] parameter statistics reporting . 109
6.5 ST[05] event reporting . 119
6.6 ST[06] memory management . 124
6.7 ST[07] (reserved) . 153
6.8 ST[08] function management . 153
6.9 ST[09] time management . 155
6.10 ST[10] (reserved) . 161
6.11 ST[11] time-based scheduling . 161
6.12 ST[12] on-board monitoring . 191
6.13 ST[13] large packet transfer . 221
6.14 ST[14] real-time forwarding control . 229
6.15 ST[15] on-board storage and retrieval . 256
6.16 ST[16] (reserved) . 308
6.17 ST[17] test . 308
6.18 ST[18] on-board control procedure . 311
6.19 ST[19] event-action . 331
6.20 ST[20] parameter management . 341
6.21 ST[21] request sequencing . 347
6.22 ST[22] position-based scheduling . 357
6.23 ST[23] file management . 390
7 Space to ground interface requirements . 412
7.1 Introduction . 412
7.2 Convention . 414
7.3 Packet field type code . 415
7.4 The CCSDS Space Packet . 425
8 Service type interface requirements . 432
8.1 ST[01] request verification . 432
8.2 ST[02] device access . 437
8.3 ST[03] housekeeping . 442
8.4 ST[04] parameter statistics reporting . 459
8.5 ST[05] event reporting . 462
8.6 ST[06] memory management . 465
8.7 ST[07] (reserved) . 475
8.8 ST[08] function management . 475

8.9 ST[09] time management . 476
8.10 ST[10] (reserved) . 478
8.11 ST[11] time-based scheduling . 478
8.12 ST[12] on-board monitoring . 490
8.13 ST[13] large packet transfer . 507
8.14 ST[14] real-time forwarding control . 510
8.15 ST[15] on-board storage and retrieval . 520
8.16 ST[16] (reserved) . 538
8.17 ST[17] test . 538
8.18 ST[18] on-board control procedure . 540
8.19 ST[19] event-action . 548
8.20 ST[20] on-board parameter management . 552
8.21 ST[21] request sequencing . 556
8.22 ST[22] position-based scheduling . 561
8.23 ST[23] file management . 574
9 Command Pulse Distribution Unit . 584
9.1 Scope . 584
9.2 System requirements . 584
9.3 Interface requirements . 586
Annex A (informative) IEEE and MIL-STD real formats . 588
A.1 IEEE standard format . 588
A.1.1 General . 588
A.1.2 Single-precision . 589
A.1.3 Double-precision . 589
A.2 United States Air Force military standard format . 591
A.2.1 General . 591
A.2.2 Simple-precision . 591
A.2.3 Extended . 592
Annex B (informative) CRC and ISO checksum . 593
B.1 The cyclic redundancy code (CRC) . 593
B.1.1 General . 593
B.1.2 Symbols and conventions . 594
B.1.3 Encoding procedure . 594
B.1.4 Decoding procedure . 594
B.1.5 Verification of compliance . 595
B.1.6 Software implementation . 595
B.2 The ISO checksum . 604
B.2.1 General . 604
B.2.2 Symbols and conventions . 605
B.2.3 Encoding procedure . 605
B.2.4 Decoding procedure . 606
B.2.5 Verification of compliance . 606
B.2.6 Software implementation . 606
Annex C (informative) Summary of requests and reports for PUS standard
services . 612
C.1 Convention . 612
C.2 Requests and reports . 612
C.2.1 ST[01] request verification . 612
C.2.2 ST[02] device access . 614
C.2.3 ST[03] housekeeping . 615
C.2.4 ST[04] parameter statistics reporting . 617
C.2.5 ST[05] event reporting . 618
C.2.6 ST[06] memory management . 619
C.2.7 ST[07] (reserved) . 621
C.2.8 ST[08] function management . 621
C.2.9 ST[09] time management . 621
C.2.10 ST[10] (reserved) . 622
C.2.11 ST[11] time-based scheduling . 622
C.2.12 ST[12] on-board monitoring . 624
C.2.13 ST[13] large packet transfer . 625
C.2.14 ST[14] real-time forwarding control . 626
C.2.15 ST[15] on-board storage and retrieval . 628
C.2.16 ST[16] (reserved) . 630
C.2.17 ST[17] test . 631
C.2.18 ST[18] on-board operations procedure . 631
C.2.19 ST[19] event-action . 633
C.2.20 ST[20] Parameter management . 634
C.2.21 ST[21] request sequencing . 634
C.2.22 ST[22] position-based scheduling . 636
C.2.23 ST[23] file management . 638
Annex D (informative) System and interface specification index . 640
Bibliography . 641

European Foreword
This document (EN 16603-70-41:2017) has been prepared by Technical
Committee CEN-CENELEC/TC 5 “Space”, the secretariat of which is held by
DIN.
This standard (EN 16603-70-41:2017) originates from ECSS-E-ST-70-41C.
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 April 2018,
and conflicting national standards shall be withdrawn at the latest by April
2018.
This document supersedes EN 14776:2004 Space engineering – Ground systems
and operations - Telemetry and telecommand packet utilization.
The main purpose of the update of EN 14776:2004 was the need:
• to remove the deficiencies of the previous issue and to inject lessons
learned,
• to improve the standard to meet the need for future missions,
• to acknowledge the existence of new ECSS and CCSDS standards and to
ensure consistency,
• to implement the updated drafting rules that apply to any ECSS
Standards (e.g. naming each requirement to facilitate tailoring,
traceability),
• maintaining backward compatibility when possible.
The main changes are:
• the introduction of the PUS foundation model that:
− has been used to produce the “standard service types”;
− shall be used to produce the “mission-specific service types”, i.e.:
◊ adding new service types, subservice types, message types,
etc;
◊ adding capabilities to the ”standard service types”;
− shall be used to produce the “mission services”, i.e.:
◊ creating the required services by:
♦ “realising the service types”, and
♦ inheriting all mandatory subservices and minimum
capabilities;
◊ selecting, for each service, the additional capabilities, the
optional subservices, etc;
◊ creating the service specific definitions.
• a proper separation of system versus interface requirements.
• material common to the three ECSS branches (Space engineering, Space
project management and Space product assurance moved to EN 16601-00
(EN version of ECSS-S-ST-00), material specific to product assurance to
this standard,
• reorganization of the content of the document to separate descriptive text
and requirements, including clarification, modification of requirements
and implementation of change requests,
• pre-tailoring matrix (Clause 6) added,
• addition of new DRDs.
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 standardization request 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, Serbia,
Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and the United
Kingdom.
Introduction
The CCSDS Space Packet Protocol (CCSDS 133.0-B-1) and the ECSS-E-ST-50
series of standards address the end-to-end transport of telemetry and
telecommand data between user applications on the ground and application
processes on-board the spacecraft, and the intermediate transfer of these data
through the different elements of the ground and space segments.
This packet utilization standard (PUS) complements those standards by
defining the application-level interface between ground and space, in order to
satisfy the requirements of electrical integration and testing and flight
operations.
Scope
This Standard addresses the utilization of telecommand packets and telemetry
packets for the purposes of remote monitoring and control of spacecraft
subsystems and payloads.
This Standard does not address mission-specific payload data packets, but the
rules contained herein can be extended to suit the requirements of any mission.
This Standard does not address audio and video data as they are not contained
within either telecommand or telemetry packets.
This Standard defines a set of services that satisfy all the fundamental
operational requirements for spacecraft monitoring and control during
spacecraft integration, testing and flight operations, refer to ECSS-E-ST-70-11. It
also specifies the structure and contents of the telecommand packets used to
transport the requests and the telemetry packets used to transport the reports.
This Standard can be used by any mission, no matter what its domain of
application, orbit or ground station coverage characteristics. However, it is not
the intention that the PUS should be applied in its entirety to a given mission.
The services defined in this Standard cover a wide spectrum of operational
scenarios and, for a given mission, only a subset of these services is likely to be
appropriate.
Choices are made early in the design phase of a new mission resulting in the
need to tailor the PUS to suit the requirements of that mission. These choices
include:
• the on-board system design and architecture, in terms of the number of
on-board application processes, their on-board implementation (e.g. the
allocation to on-board processors) and their roles (i.e. which functions or
subsystems or payloads they support);
• which PUS services are supported by each application process.
Each mission usually documents the results of this design and selection process
in a "Space-to-Ground Interface Control Document".
Some missions implement a centralized architecture with a small number of
application processes, whilst others have a highly-distributed architecture
within which a correspondingly larger number of application processes are
distributed across several on-board processors.
The specification of services in this Standard is adapted to the expectation that
different missions require different levels of complexity and capability from a
given service. To this end, all services are optional and a given service can be
implemented at one of several distinct levels, corresponding to the inclusion of
one or more capability sets. The minimum capability set corresponds to the
simplest possible level that also remains sensible and coherent. At least this set
is included in every implementation of a given service.
The standardized PUS services fulfil the following criteria:
• Commonality: each standard service corresponds to a group of
capabilities applicable to many missions.
• Coherence: the capabilities provided by each standard service are closely
related and their scope is unambiguously specified. Each standard
service covers all the activities for managing inter-related state
information and all activities that use that state information.
• Self-containment: each standard service has minimum and well-defined
interactions with other services or on-board functions.
• Implementation independence: the standard services neither assume nor
exclude a particular spacecraft architecture (hardware or software).
This Standard mainly addresses the requirements that apply to the spacecraft
and its components. The ground segment counterpart requirements related to
the testing or the operations of the spacecraft and its components can be
derived from these requirements and are not specified in this Standard.
Tailoring the PUS for a mission is mainly a task for the operations team and the
spacecraft manufacturer. This Standard assumes that the mission ground
segment used to test or operate the spacecraft implements all standardized
capabilities and as such, does not further constrain the mission tailoring process
of these capabilities.
The PUS should be viewed as a "Menu" from which the applicable services and
service-levels are selected for a given mission. This selection process is repeated
for each on-board application process, since each application process is
designed to provide a specific set of tailored services.
This standard may be tailored for the specific characteristics and constraints of a
space project in conformance with ECSS-S-ST-00.
This Standard does not include any protection against inadequate operations.
This is considered mission specific.
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-70 ECSS-E-ST-70 Space engineering – Ground systems and operations
EN 16603-70-01 ECSS-E-ST-70-01 Space engineering – Spacecraft on-board control
procedures
EN 16603-70-11 ECSS-E-ST-70-11 Space engineering – Space segment operability
EN 16603-70-31 ECSS-E-ST-70-31 Space engineering – Ground systems and operations –
Monitoring and control data definition
CCSDS 133.0-B-1, Space Packet Protocol, Blue Book
September 2003
CCSDS 301.0-B-4, Time Code Formats, Blue Book
November 2010
Terms, definitions and abbreviated terms
3.1 Terms from other standards
a. For the purpose of this Standard, the terms and definitions from ECSS-S-
ST-00-01 apply, in particular for the following terms:
1. space system
2. space segment
3. spacecraft
4. ground segment
3.2 Terms specific to the present standard
3.2.1 acceptance notification
notification that is generated by the acceptance and reporting subservice
provider of the application process that hosts the subservice provider in charge
of executing the related request
3.2.2 acceptance verification report
report generated by the acceptance and reporting subservice provider as a
consequence of a request acceptance verification
NOTE The acceptance and reporting subservice for a
request is hosted by the application process that
hosts the subservice responsible for executing that
request. Each acceptance verification report is
reporting either the successful acceptance of a
request or the failed acceptance. In case of
successful acceptance, the request is sent to the
subservice provider in charge of its execution. In
case of failed acceptance, the request is rejected
and as such, not sent to any subservice provider.
3.2.3 application process
element of the space system that can host one or more subservice entities
NOTE An application process resides either on-board or
on ground. An on-board application process
usually hosts some subservice providers but can
also host some subservice users. A ground
application process usually hosts some subservice
users. If a ground application process is remotely
controlled by the ground monitoring and control
system, that application process behaves as an on-
board application process and can host some
subservice providers.
3.2.4 capability
functionality of a service or a subservice
NOTE A capability is specified by a set of operational
requirements for a function of the overall space
system that can be remotely controlled by the
ground monitoring and control system or by other
on-board applications. This Standard mainly
addresses these remote controlled related
requirements and especially those applicable to the
subservice providers.
3.2.5 data report
report generated by a subservice provider as part of the subservice functionality
NOTE A data report can be generated in response to a
request or to an instruction to elicit some specific
service data. A data report can also be generated
autonomously, when reports are enabled by a
request, or as part of a continuous reporting
functionality.
3.2.6 event report
report related to an occurrence of an event
NOTE Event reports are generated by the subservice
providers.
3.2.7 execution notification
notification that is generated by the subservice provider in charge of execution
of the related instruction
NOTE An execution notification reports on the successful
or failed execution of an instruction. This Standard
does not specify how the notifications are
implemented on-board, nor how the subservice
providers in charge of their generation interact
with the subservice providers in charge of
generating the corresponding execution
verification reports.
3.2.8 execution verification report
report generated by the execution reporting subservice provider of an
application process as a consequence of the reception of one or more execution
notifications
NOTE The execution reporting subservice for a request is
hosted by the application process that hosts the
subservice responsible for executing that request.
Each execution verification report is reporting
either a successful or a failed execution stage (start,
progress or completion) of a request.
3.2.9 instruction
elementary constituent of a request that is generated by a subservice user for
execution by a subservice provider
3.2.10 message
request or report
3.2.11 notification
elementary constituent of a report than is generated by a subservice provider
for interpretation by a subservice user
3.2.12 object path
combination of a repository path and a file name or directory name
3.2.13 on-board file system
system used to control data organised in files
3.2.14 on-board memory
logical memory space
NOTE The on-board memories can potentially be
managed by different on-board processors. The
mapping between the on-board memories and the
physical memories is out of the scope of this
Standard.
3.2.15 on-board parameter
lowest level of elementary data item on-board
NOTE A parameter has a unique interpretation.
3.2.16 report
message made of one or more notifications generated by a subservice provider
for interpretation by a subservice user
NOTE This Standard identifies three types of reports:
• verification reports,
• data reports, and
• event reports.
3.2.17 repository path
logical path to where a file or a directory is located
NOTE A repository path can either represent a physical
path such as a directory path within a file system
or a logical path such as a mounted device (e.g.
"/mm1"pointing to a mass memory device), a
directory within a mounted device (e.g.
"/mm1/dir1").
3.2.18 request
message consisting of one or more instructions generated by a subservice user
for execution by a subservice provider
3.2.19 routing notification
notification that is generated by a routing and reporting subservice provider as
a consequence of a request routing verification
3.2.20 routing verification report
report generated by a routing and reporting subservice provider as a
consequence of a request routing verification
NOTE The routing verification reports are generated by
the application processes that are involved in the
routing of a request between a subservice user and
a subservice provider. The routing and reporting
subservice generates a failed routing verification
report to inform a subservice user of the
impossibility of pursuing the routing of the
request, e.g. because of corruption of that request
during the routing.
3.2.21 service
functional element of the space system that provides a number of closely-
related functions that can be remotely operated
NOTE Each service is composed of one or more
subservices, where each subservice involves a
subservice provider and one or more subservice
users. A subservice provider is in charge of
performing some space system functions. A
subservice user is in charge of issuing requests for
the execution of those functions and of processing
the resulting feedback.
3.2.22 subservice
elementary constituent of a service composed of exactly one subservice
provider and the related subservice users that are interacting through dedicated
sets of messages
3.2.23 subservice entity
operational element of a subservice hosted by an application process that acts as
subservice user or subservice provider
3.2.24 subservice provider
operational element of a subservice that is in charge of execution of the
subservice requests and generation of the subservice reports
3.2.25 subservice user
operational element of a subservice that is in charge of initiating the subservice
requests and processing the subservice reports
3.2.26 transaction
set of messages related to the execution of exactly one capability which are
exchanged between a subservice user and a subservice provider
NOTE The different types of transactions defined in this
Standard are:
• request related transaction,
• autonomous data reporting transaction, and
• event reporting transaction.
3.2.27 verification report
routing, acceptance or execution verification report
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
ANSI American National Standards Institute
AOCS attitude and orbit control subsystem
APID application process identifier
ASCII American standard code for information interchange
CCSDS Consultative Committee for Space Data Systems
CDS CCSDS day segmented
CPDU command pulse distribution unit
CRC cyclic redundancy code
CUC CCSDS unsegmented code
ESA European Space Agency
FDIR fault, diagnostic, isolation and recovery
FMON functional monitoring
GPS global positioning system
ID identifier
IEEE Institute of Electrical and Electronics Engineers
ISO International Organization for Standardization
LSB less significant bit
MAP multiplexer access point
MIL-STD United States military standard
MSB most significant bit
OBCP on-board control procedure
PCS packet check sequence
PFC packet field format code
Abbreviation Meaning
PMON parameter monitoring
PTC packet field type code
PUS packet utilization standard
RAM random access memory
ST service type
TAI international atomic time
TC telecommand
TM telemetry
UTC coordinated universal time

3.4 Nomenclature
The following nomenclature applies throughout this document:
a. The word “shall” is used in this Standard to express requirements. All
the requirements are expressed with the word “shall”.
b. The word “should” is used in this Standard to express recommendations.
All the recommendations are expressed with the word “should”.
NOTE It is expected that, during tailoring,
recommendations in this document are either
converted into requirements or tailored out.
c. The words “may” and “need not” are used in this Standard to express
positive and negative permissions, respectively. All the positive
permissions are expressed with the word “may”. All the negative
permissions are expressed with the words “need not”.
d. The word “can” is used in this Standard to express capabilities or
possibilities, and therefore, if not accompanied by one of the previous
words, it implies descriptive text.
NOTE In ECSS “may” and “can” have completely
different meanings: “may” is normative
(permission), and “can” is descriptive.
e. The present and past tenses are used in this Standard to express
statements of fact, and therefore they imply descriptive text.

Context and background
4.1 Introduction
This Standard addresses the need to standardize the way the space system
functions are defined when involved in an interaction between space and
ground.
This Standard introduces the concept of PUS services, consisting of PUS
subservices. The services and subservices formalise the closely related and self-
contained set of space system functions and all related entities and interaction
artifacts.
Each PUS subservice is composed of PUS subservice entities, each one playing
either the role of a subservice provider or the role of a subservice user. Each
PUS subservice entity is hosted by an application process on-board or on-
ground.
As depicted in Figure 4-1, it is usually understood that the on-board application
processes host the subservice providers and the ground application processes
the subservice users but this standard does not constrain those relationships.
For example, a ground equipment can host some subservice providers so that
the equipment can be remotely controlled by a mission control centre, a
payload can host some subservice users for controlling solid-state mass
memories (e.g. using file management subservices).
No particular topography is assumed in this Standard for how application
processes and hosted PUS subservice entities are implemented or distributed,
neither is any topography precluded. Thus:
• for a given mission, there can be any number of on-board application
processes (with a minimum of one), each one hosting any number of PUS
subservice entities (with a constraint that a given application process can
only host a single subservice entity provider of a given type of
subservice);
• there are no restrictions on the mapping between application processes
and the usual functional subdivision of a spacecraft into subsystems and
payloads (at one extreme, with a simple spacecraft topology, there can be
a single application process within a centralized data management
system which hosts PUS services for all the other platform subsystems
and payloads; at the other extreme, intelligent subsystems and payloads
can each be served by their own independent application processes and
PUS services);
• an application process can be implemented in software, firmware or
hardware;
• an on-board computer can host one or more application processes or an
application process can be distributed across two or more on-board
computers.
Figure 4-1 The space to ground PUS service system context
The information exchanged between a subservice user and subservice provider
is termed a "message". A message is transmitted semantically unchanged by the
transmission protocol that connects the subservice users and subservice
providers.
A message sent by a subservice user to a subservice provider, to invoke the
execution of on-board activities, is termed a "request". Each request contains
one or more instructions, one for each activity to execute. A message sent by a
subservice provider to a subservice user is termed a "report". Each report
contains one or more notifications.
Three distinct categories of report are distinguished:
a. the verification reports, which report on the routing, acceptance, start,
progress and completion of the request execution;
b. the data reports, which are generated:
1. on request, as one or multiple responses to the instructions of a
request to elicit some specific service data,
2. autonomously as one or multiple reports activated by a request or,
routinely, i.e. as part of a continuous reporting functionality;
c. the event reports, which carry information related to the occurrences of the
events detected by a service.
The request carries information used by the subservice provider to identify the
subservice user that issued that request. This is especially interesting if several
subservice users can send requests to a given subservice provider. It provides
the means to the subservice provider to route the related verification reports
and on-request data reports back to the subservice user who invoked the
activity.
The routing of the autonomous data reports and of the event reports is either
known implicitly (by design) or explicitly (e.g. by using an on-board routing
table).
When messages (requests and reports) are exchanged between ground and
space, they are encapsulated into CCSDS space packets, refer to clause 7.4.
Figure 4-2 provides an example of how PUS services can be deployed on-
ground and on-board a spacecraft and how commanding with this Standard is
understood.
Figure 4-2 A PUS utilization example
The mechanisms which on-board application processes use to communicate
with each other and with other on-board entities are implementation-
dependent. Historically, spacecraft on-board interfaces have been specified and
implemented on a project-by-project basis and any reuse of interfaces has
usually been a by-product of reuse of existing spacecraft busses. While it is true
that there are a limited number of physical interfaces available for use on-board
a spacecraft, the services and access to these interfaces vary considerably
between implementations. This Standard does not specify how requests,
instructions, reports and notifications are implemen
...