cross support transfer services (csts) overview

Click here to load reader

Post on 11-Jan-2016




1 download

Embed Size (px)


Cross Support Transfer Services (CSTS) Overview. SLE Success Story (2002 to 2009). Svalbard. Troms ø. Kiruna. ESOC. Redu. Saskatoon. Roskosmos. Neustrelitz. St. Hubert. Weilheim. Toulouse. CNES/. DLR/GSOC. Denver. Goddard. CNSA. Usuda. JAXA. Madrid /CEB/VIL. Whitesands. - PowerPoint PPT Presentation


CCSDS-OMG Plenary TemplateOverview
SLE Service Provider
SLE Service User
Unframed telemetry data, tracking data, Station monitoring
CSTS builds on SLE success by supporting additional types of data.
Margherita Di Giulio (MG) - Have bi-directioonal lines for CSTS Provider to/from User.
SLE and CSTS are similar; they both transfer data between a Provider (typically a ground station) and a User (typically a mission control center). However, the types of data that can be transferred with CSTS are different than for SLE.
(abstract syntax)
CSTS reuses all the protocol layers underneath SLE, as well as the abstract syntax concept for its protocol messages.
OP 1
OP 2
OP 3
OP 4
The CSTS Framework provides a reusable foundation that allows services to be defined and implemented efficiently.
Operations provide the most basic capabilities – e.g. “transfer these bytes”.
Procedures build on the capabilities provided by operations. To ensure that they are generally useful, procedures are purposely abstract. They typically define mechanisms (e.g. for buffering and releasing data) but do not specify the type of data being carried. (The services that use a procedure make the abstract parts concrete)
The combination of the procedures and operations is known as the Framework.
The Framework is specified once, and can then be referenced from multiple service specifications. This allows the service specifications to be quite small – the normative section of the Monitored Data Service is only 6 pages long!
Similarly, the Framework can be implemented once, and that implementation can be reused across all the CSTS services.
Services use the Framework
Each service uses only those Framework procedures that are needed to get the job done. For example:
“notify User when certain events occur”
The Monitored-Data service allows the User to monitor the overall status of service being provided by, say, a ground station for a particular pass. Monitoring is accomplished via periodic reports and/or specific queries, plus the User is notified when “events of interest” occur.
As always, the Association-Control procedure establishes a connection between the User and Provider.
The Cyclic-Report procedure allows the User to request (and receive) periodic status reports.
The Information-Query procedure allows the User to request (and receive) a single status report.
The Notification procedure is used to notify the User when an “event of interest” occurs.
A service may extend the Framework
If a service needs capabilities that are not supplied by the Framework, it may extend the Framework – it can create a new procedure that adds new behavior and/or new data to an existing procedure.
Buffered Tracking Data Message Delivery
The new procedure adds one capability to the existing procedure - it delivers one context message prior to a stream of Tracking Data messages.
“establish connection”
The Real-time Tracking Data service delivers “fresh” Tracking Data Messages to the User for real-time monitoring. The service must ensure that a ‘metadata’ message is delivered at startup (the metadata will provide the context for the data that follows).
As always, the Association-Control procedure establishes a connection between the User and Provider.
The service defines a new procedure that extends an existing Framework procedure by specifying that ‘metadata’ shall be sent as part of the startup mechanism. Again, this metadata provides the context for the data that follows.
A service may refine the Framework
If a service needs more precise capabilities than the abstract capabilities provided by the Framework, it may refine the Framework -- for example, a new procedure narrows the possibilities provided by an existing procedure.
“establish connection”
“deliver data; buffer as needed”
The Buffered-Data-Delivery procedure does not specify the format of the data to be delivered; the new procedure specifies that the data will match the standard Tracking Data Message format.
Establish an association with the provider for the service instance
Start data flow
All operations do their work by means of protocol messages. These messages are defined using Abstract Syntax Notation, and are very similar to the SLE protocol messages.
This slide shows some of the available operations; there are others.
Buffered Data Delivery
Note: The Buffered Data Delivery procedure includes mechanisms for buffering and releasing of data units.
Service User
Service Provider
Start (data selection)
Margherita Di Giulio (MG) - Change the order of animations so the Bind/Unbind örange blocks" do not appear until after Ässociation Control" block.
All procedures use operations to help accomplish their work.
Procedures typically add behavior around the operations. For example, the Buffered-Data-Delivery procedure uses the Transfer-Data operation to send data from the Provider to the User, and adds mechanisms for buffering data at the Provider and deciding when to send (or possibly, discard) the buffered data.
Guidelines for Specification of Cross Support Transfer Services
Cross Support Transfer Service Specification Framework Concepts
Recommended Standards
Informative Report
The Framework specification defines the procedures and operations that make up the Framework. This includes specifying the format of all CSTS protocol messages.
The Guidelines specification is intended to guide people who want to create new services. This specification attempts to ensure that:
Services make maximum use of the reusable Framework.
When a service extends the Framework, that it does so in the most efficient way that is practical.
Service specifications follow a consistent outline.
Services are consistent in how they use Service Management to configure themselves.
The Concepts report explains:
The approach taken within the Framework
Capabilities that are assumed to be provided by protocol layers below the Framework.
How to use the Framework to build a service.
Reading the Framework specification
For managers and others interested in the bigger picture, sections 1 and 2 are recommended.
For implementers and others interested in the detailed rules to be followed, sections 3 and 4 are recommended.
Note that the formal definition of protocol message formats is found in Annex C.
Margherita Di Giulio (MG) - Add 1-2 slides to describe the outline of the documents and point readers to the relevant sections. e.g. Managers need only read section 1 and 2, etc. Dilbert must read the entire document.
The CSTS Framework builds on proven SLE concepts, and much of the source code developed for SLE can be reused for CSTS.
The CSTS Framework provides an efficient path to defining and implementing new services – it enables savings in time and cost.
The Framework specification provides building blocks that can be used to build new services.
These building blocks can easily be extended and/or refined as necessary.
While it is possible to transition the existing SLE services to the CSTS approach, there are no plans to do so at this time.
Margherita Di Giulio (MG) - Add 1-2 slides to describe the outline of the documents and point readers to the relevant sections. e.g. Managers need only read section 1 and 2, etc. Dilbert must read the entire document.