THE ECSS PACKET UTILIZATION STANDARD AND ITS SUPPORT TOOL

1
THE ECSS PACKET UTILIZATION STANDARD AND ITS
SUPPORT TOOL

• Mario Merri - ESA/ESOC
• Bryan Melton, Serge Valera - ESA/ESTEC
• Andrew Parkes - Nova Space Associates Ltd

2
Agenda

• Introduction
• Standardization of spacecraft monitoring and
  control
• Improvements and extensions to the ESA PUS
• The PUS tailoring and supporting tool
• Conclusions

3
What is the PUS?

• It is a standard that complements the CCSDS
  packet TM TC recommendations by defining the
  application-level interface between ground and
  space
• It covers nominal, contingency and
  troubleshooting operations for both AIV and
  mission operations
• It provides operational concepts and a set of
  on-board services meeting them
• It defines TM TC packets (including structures)
  to exploit the on-board services
• It promotes the selection and tailoring of the
  on-board services according to the needs of a
  given mission
• It allows mission-specific extensions

4
History and Status of PUS

• PUS Issue 1 published as an ESA standard
  (PSS-07-101) in May 1994
• at that time, in Europe, only the EURECA mission
  used packet TM TC
• ECSS Working Group E-70 (Ground Systems and
  Operations) took over PUS and revised it
• feedback from missions that have used the PUS
• studies have applied/validated the PUS
• many review comments collected
• need to align with latest CCSDS work
• ECSS PUS status
• public review closed on 1 June 2001
• waiting for ECSS final approval and publication

5
Missions Using or Considering the PUS

• XMM
• MSG
• INTEGRAL
• GOMOS (Envisat Instrument)
• ATV
• Ørsted (Danish microsatellite)
• PROBA

• ROSETTA
• MARS EXPRESS
• HERSCHEL-PLANK
• CRYOSAT
• GOCE
• GALILEO

Virtually all future ESA missions are considering
to adopt the PUS
6
Why PUS?

• GOAL reduce costs and risks of developing and
  operating on-board and ground systems and provide
  interoperability capability
• APPROACH re-use/share experience (ops concept)
  and software by
• standardise the spacecraft operational concept
• generalise the spacecraft on-board architecture
• standardise the service model
• standardise MC messages as a direct consequence
  of the underlying service model (and not the
  other way around)

7
The PUS Standardisation Approach
Generic Operations Concept
Generic On-Board Architecture
Generic Service Model
Message Definition

• Generic common across missions of different
  nature (scientific, microgravity, etc.) and
  orbital profile (interplanetary, low-Earth,
  geostationary, etc.)

8
Generic Operations Concept

• Operations concepts include
• Concepts relating to routine operations
  scenarios, such as telecommanding and telecommand
  verification, telemetry reporting, on-board
  software management, on-board operations
  scheduling, on-board monitoring, on-board storage
  and retrieval and packet forwarding control
• Concepts that relate to non-routine operations
  scenarios, such as software and memory
  maintenance and troubleshooting, diagnostic data
  reporting and off-line testing
• Not all of the operation concepts are necessarily
  applicable to a given mission

9
Generic On-Board Architecture

• Minimal assumptions on on-board architecture
  based on the concept of Application Process (AP)
• An AP, uniquely identified by an APID, is a
  system element capable of generating TM packets
  and receiving TC packets
• An AP can control other system elements (e.g.
  memory, device, on-board schedule, etc.)
• An AP can be implemented in software, firmware or
  hardware.
• No restrictions on the mapping between APs and
  the usual functional subdivision of a satellite
  into sub-systems and payloads
• A microprocessor can host one or more APs. An AP
  (presumably a rather complex one) can be
  distributed across two or more microprocessors
• Standardised messages are exchanged between
  ground and on-board APs that are independent of
  the transfer method
• currently via CCSDS TM and TC packets
• but open to other technologies (e.g. TCP/IP)

On-board Application Processes
TM Source Packets
TC Packets
Ground Service Users
10
Generic (Standard) Service Model
1 Telecommand Verification 2 Device Command
Distribution 3 Housekeeping and Diagnostic Data
Reporting 4 Parameter Statistics
Reporting 5 Event Reporting 6 Memory
Management 8 Function Management 9 Time Management
11 On-board Operations Scheduling 12 On-board
Monitoring 13 Large Data Transfer 14 Packet
Forwarding Control 15 On-board Storage and
Retrieval 17 Test 18 On-board Operations
Procedure 19 Event/Action
Commonality needed by several missions Coherence
self contained Implementation independent
minimal assumptions on on-board
architecture Minimum set core functionality of a
mission control system and electrical ground
support equipment
11
Message Definition

• ESA wants to be compliant to CCSDS Packet TM and
  TC, but there are many ways to use packets!
• To achieve full standardisation one needs to
  define
• the information exchange operational protocol
• the information to be exchanged (messages)
• the information format and structures
• the information tailorability for a given
  mission

12
IMPROVEMENTS AND EXTENSIONS TO THE ESA PUS (1)

• Alignment with evolution of CCSDS recommendations
• CCSDS removal of TM Segmentation concept releases
  Grouping Flags for use by Application Processes
• CCSDS File Transfer Protocol considered as
  complementary to PUS
• PUS Large Data Transfer Service retained as it
  affords a more secure mechanism for conveying a
  series of packets than using the segmentation
  flags
• Improvements in structure and presentation
• removed operational requirements
• added underlying operational concepts
• provided guidelines for commonly-asked questions
• emphasised tailoring concept
• Clarified scope of services and removed
  ambiguities

13
IMPROVEMENTS AND EXTENSIONS TO THE ESA PUS (2)

• Modifications to the Scope of the PUS
• Packet Header/Data Field Header
• added optional Type/Sub-type counter in TM Data
  Field Header
• added optional Source and Destination IDs in TC
  and TM Data Field Headers, respectively
• Services
• added 2 new services On-Board Operations
  Procedure and Event/Action
• merged Time Management and Time Reporting
  services
• merged Function Management and Task Management
  services
• extended On-board Storage and Retrieval service
  (on-board store catalogue and 2 options for the
  downlinking of retrieved packets)
• added option for both the On-board Storage and
  Retrieval service and the Packet Forwarding
  Control service to be implemented either in a
  distributed manner or to be provided by a
  centralised Application Process
• defined standard TC verification failure codes
  (based on XMM, MSG, Rosetta)

14
PUS Tailoring Concept
New a prototype tool available to automate PUS
tailoring and generation of mission-specific PUS
document
The specification of the standard services
identifies different levels at which each service
can be implemented, ranging from a very basic
functionality through to the most complex level
PUS Standard
PUS Services Tailoring
PUS Service selection
On-board Ground Segment Implementations

• Operations Concept
• Operational Requirements

• Spacecraft Design
• Ground Segment Design

15
Conclusions

• ESA PUS has been revised on the basis of
  real-life experience
• Operational concept and messages are fully mature
  (started about 10 years ago) and have been
  validated on real spacecraft and systematically
  used for new missions
• This already brings significant cost and risk
  reduction in the development and operations of
  both space and ground systems
• ESA ground infrastructure is ready (SCOS-2000)
• The new ECSS PUS will be soon available and will
  further establish the PUS as The Standard in
  this field
• The availability of tools will facilitate the
  tailoring of the PUS to missions