Commanding via the CCSDS Forward CLTU Service: The Mission Perspective

1
Commanding via the CCSDS Forward CLTU
ServiceThe Mission Perspective
A presentation to the SpaceOps 2002 Conference
Deane Sibol and Valerie Mallder The Johns
Hopkins University Applied Physics
Laboratory 11100 Johns Hopkins RoadLaurel, MD
20723-6099, USA deane.sibol_at_jhuapl.edu
2
Introduction

• JHU/APL missions use NASA/JPLs Deep Space
  Mission System
• DSMS now provides several Space Link Extension
  (SLE) services
• Mission Operation Centers Ground System to
  include user-side implementation
• Integration must be flexible and mission
  independent

3
SLE Forward CLTU Service

• Focus on single uplink service only return link
  not SLE at this time
• CLTU-BIND to provider from MOC
• CLTU-START to provider after Operational no
  CLTUs queued before provider ready to radiate
• All parameters from CLTU-STATUS-REPORT and
  CLTU-ASYNC-NOTIFY included in ground telemetry
• Service Instance State included in ground
  telemetry
• Allows user to change uplink data rate,
  modulation index and to enable/disable inter-CLTU
  modulation via CLTU-THROW-EVENT

4
The SLE API

• Proxy layer (TCP) is providers identical
  implementation
• Nine (9) libraries from JPL
• Required to implement only a few
  application-level interfaces

5
CONTOUR

• Launched July 3, 2002
• First to use SLE Forward CLTU Service for launch
  and early orbit
• First to operationally use the service from an
  externally managed organization
• Integration into existing ground system expedited
  by provider supplied API (JPL), simulator (JPL),
  and INTEGRAL (ESA) testing
• Automation does rely on some non-standard
  CLTU-THROW-EVENTs

6
Ground System Integration

• New application replaces Front End
• Convert transfer frame to CLTU
• Handle all user-side operations

7
Multi-Mission Design Issues

• Support PLOP-1 (via PLOP-None) and PLOP-2
• Do not use earliest and latest radiation times
• Propagate inter-CLTU delay to user
• Handle multiple providers/stations in a single
  instance of the application

8
End-User Design Issues

• Do not automate CLTU-START and CLTU-STOP (even to
  recover from failure) propagate to user
• In command system, flow control implemented in
  this application
• Hide PLOP via configurable acquisition sequence
• Provide a command history
• Hide protocol details, but propagate select
  parameters to user
• Book keep number of CLTU in providers queue

9
Flow Control

• Eliminate propagation delays
• Do not wait for current CLTU to radiate before
  sending next
• In fact, fill queue without confirmed responses
• Target Queue Depth is configurable
• Flywheel cltu-id in CLTU_TRANSFER-DATA
• When queue is at target level, accept next
  transfer frame, but do not handshake
• Invoke CLTU-TRANSFER-DATA with pending CLTU on
  receipt of next CLTU-ASYNC-NOTIFY confirming
  radiation and handshake with Transfer Frame
  Generator

10
Command History

• Key is command system sequence (not shown)
  CLTU Id
• Data is extracted from parameters within
  CLTU-STATUS-REPORT and CLTU-ASYNC-NOTIFY, when
  available

11
Lessons Learned

• JPLs SLE API invaluable to success
• JPLs Forward CLTU Provider Simulator jump
  started development
• Network Security at Proxy Layer was biggest
  obstacle
• Alternate ASN.1 compiler evaluated, but not
  integrated because of schedule and risk

12
Future Missions

• MESSENGER, STEREO and New Horizon missions will
  use the existing SLE Forward CLTU Service
  Application in their ground system
• MESSENGERs addition of interleaved CFDP
  telecommand frames to be coordinated before
  reaching this application
• Goal was to have this application completely
  configurable to support these and future missions
  without modification