This standard has been cancelled and replaced by ECSS-E-ST-70-41C (15 April 2016).
This Standard addresses the utilization of telecommand packets and telemetry source packets for the purposes of remote monitoring and control of 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 source packets.
This Standard is structured as follows. Firstly a set of operational concepts is identified, covering all the fundamental requirements for spacecraft monitoring and control during satellite integration, testing and flight operations. A set of services that satisfy these operational concepts is then defined. The detailed specification of these services includes the structure and contents of the associated service requests (telecommand packets) and service reports (telemetry source packets).
This Standard is applicable to any mission, no matter what its domain of application, orbit or ground station coverage characteristics. However, it is not the intention that the PUS is applicable to a given mission in its entirety. The operational concepts and corresponding services contained in this Standard cover a wide spectrum of operational scenarios and, for a given mission, only a subset of these operational concepts and services is 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 the particular mission. These choices include:
a. 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).
b. Which PUS services are supported by each application process.
NOTE Tailoring is a process by which individual requirements or specifications, standards and related documents are evaluated and made applicable to a specific project by selection, and in some exceptional cases, modification of existing or addition of new requirements (ECSS-M-00-02A, clause 3 (Reference [11])).
Each mission should document the results of this design and selection process in a space-ground interface control document (SGICD).
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 functionality 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, which also remains sensible and coherent. At least this set is included in every implementation of a given service.
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.
Attachments: