Transcript CCSDS Cross Support Services

CCSDS Cross Support Services
Issue 0.1
October, 2008
Takahiro Yamada, JAXA/ISAS
Peter Shames, NASA/JPL
Purpose of This Document





Identify services that should be provided by IOAG member
agencies for cross support
Differentiate communications, applications, and management
services
Show relationships among the services
Provide some thoughts on necessary / useful service views
Some thoughts about “generic” forward / return terms
Communications Services
Cross Support
Service Types
Forward Delivery
Services
Basic Cross Support Services
Forward CLTU/Frame Delivery Service (these may be different svcs)
Forward Packet Delivery Service (is packet relaying implied?)
Forward Bundle Delivery Service (IP too, what is this service interface?)
Forward File Delivery Service (what is this service interface, FTP?)
Return Delivery
Services
Return Frame Delivery Service
Return Packet Delivery Service
Return Bundle Delivery Service (IP too)
Return File Delivery Service
Voice and Video
Services
Voice Service
Routing/
Networking
Services
IP Routing/Networking Services (why are these separate from fwd / ret
bundle svc, aren’t they just part of Bundle / IP service?)
Video Service
DTN Routing/Networking Service (ditto )
Application Services
Cross Support
Service Type
Tracking Services
Basic Cross Support Service
Radio Metric Data Service
Delta-DOR Service
Orbit Determination Service
Time Service
Spacecraft Time Correlation Service
Spacecraft Time Synchronization Service
Monitor and
Control Services
Spacecraft Monitor and Control Service (not clear this should be a cross
support service)
Ground Station Monitor and Control Service (this should NOT be one)
Planning Support
Services (see next
page)
Ephemeris Access/Delivery Service
Tracking Schedule Access/Delivery Service
Management Services
Cross Support
Service Type
Planning Services
Basic Cross Support Service
Catalog Services
Service Agreement Management Service
Spacecraft Configuration Management Service
Service Envelope Validation Service
Support Commitment Service
Planning Support
Services
Viewperiod Validation Service
Mission Timeline Management Service
Ephemeris Access/Delivery Service
Tracking Schedule Access/Delivery Service
Scheduling
Services
Nominal Service Request
Emergency Service Request
N.B. question of whether we would want to use the same planning and scheduling
services for both terrestrial and space service instances. I.e. does a rover wanted
service ask an orbiter for a pass?
Alternative Application Services
Cross Support
Service Type
Basic Cross Support Service
Monitor and
Control Services
(may be requested
by users)
Service Monitoring Request (monitor one or more Application or
Communication Service execution instances)
Network
Management
Services (only for
network operators)
Manage Routing
Service Control Request (control service production for only one
Application or Communication Service execution instances, only one Svc
Control at a time per service exec instance)
Manage Links & interfaces
Manage ephemerides
Manage on-board storage
Mission Monitor
and Control
Services
Spacecraft Monitor and Control Service (not clear this should be a cross
support service)
Ground Station
Services
Ground Station Monitor and Control Service (this should only be an intranetwork service used by network operators)
Relationships Among Services
(really need to show protocol layering here, look at ADD
diagrams)
Orbiter
Lander
Time
Corr. U
Time
Corr. P
Bundle
Delivery U
Lander Control Center
Bundle
Delivery P
Orbiter Control Center
GS M&C U
Bundle
Delivery P
Bundle
Delivery U
Ground Station
GS M&C P
Bundle
Delivery U
Bundle
Delivery P
Thoughts on Different Service Views

Service Interface view (per service)
 What service is provided to the users?
 How it is accessed and delivered?
 What is its behavior from the users point of view?
 What are the data objects that are transferred across the interface?
 Is it throughput, store & forward, or both?
 What security is provided / required to access & control the
interface? What credentials are required?
 What constraints are there on the service?
 Check out FIPA Service definitions and ontology

Service Protocol Communications view (per service)
 What protocols implement the service interface?
 What protocols support the service interface?
 What constraints are there on the protocols?
 How are end-to-end paths constructed?
Thoughts on Different Service Views, contd

Mission Operations view (per related set of services)
 How is mission operations service provided?
 What mission operations service elements (and others) are
involved?
 What are their data and control flows?
 How do they behave together to deliver the operations service?
 What constraints are there on this operations service?

End-to-end View (per service)
 How do users request the end-to-end services (ties to service IF
view)?
 How do users monitor and control these services?
 What system elements implement the service (ties to MO view)?
 What functions do these element perform to deliver the service (ties
to svc IF view)?
 How do the operators of these elements monitor and control them?
 What constraints are there on the end-to-end service?
Thoughts on Different Service Views, contd

Mission Lifecycle view (per set of services)
 How does this set of services support mission operations lifecycle?
 Are different services used during different phases, do they evolve?
 What are their data and control flows during / across phases?
 How is information managed / passed among services during the
lifecycle?
 Are there gates to be passed to transition among phases?
 What constraints are there on this set of services during lifecycle?

Cross Support / Enterprise view (per service)
 Does the service operate differently in cross support mode (vs
intra-agency use)?
 How are contracts for services established?
 Are funds exchanges or is it quid pro quo or some other payment in
kind?
 Are there constraints on what cross support users can do?
 How is access and security managed, how are credentials issued
and managed?
Thoughts on Different Service Views, contd

Questions for Infrastructure elements (per service node)
 What minimal set of services are required to participate?
 What is the full set of services provided?
 What is the PICS for each provided service?
 What service interface options are offered?
 What service modes are supported?
 Which communications links and protocols are supported?
 What are performance capabilities and capacities of the links and
service elements?
 What components are used to provide service interfaces?
 How many simultaneous users can be serviced?
 What constraints on use of the element?

And also what are requirements from infrastructure elements on the
compliant components and sub-systems that they require?
Semi-random Thoughts on “Generic” Forward / Return









Forward / return have been used to imply direction from / to Earth
Command and Telemetry come associated with specific semantic meanings,
and may still be useful but miss other data types, voice, video, software loads,
OBC dumps, eng vs housekeeping
Notion of request / response (/ ack / nack) is a good one too, but it is more of an
interaction pattern and there are others including multi-cast
Link asymmetries are likely to remain due both to physical constraints (aperture,
mass, power) and different data transfer requirements
FIPA uses: REQUEST, if the sender wants the receiver to perform an action,
INFORM, if the sender wants the receiver to be aware of a fact, QUERY_IF, if
the sender wants to know whether or not a given condition holds, CFP (call for
proposal), PROPOSE, ACCEPT_PROPOSAL, REJECT_PROPOSAL, and
interactions like REQUEST-WHEN, RECRUITING & BROKERING
SM&C uses: SEND, SUBMIT, REQUEST, INVOKE, PROGRESS, PUB-SUB
SM uses: SENDER/RECEIVER, INVOKATION, SUCCESS/FAIL RETURN, ACK
RETURN
CSTS uses: initiator, responder, invoker, performer, and also send, receive
Maybe what we need to do is to treat the links themselves as just that, full, half,
simplex, symmetric, asymmetric, uni-cast, multi-cast, broadcast as is their
physical nature, and use these other semantic terms, e.g. command, telem,
request, respond, upload, download to refer to the interface interactions and
patterns of how the links are used