[Css-csts] RE: functional resource types for Retrieval Service Packagecomponents?

[John Pietras]

Marcin,

Please see below for my responses, in red.

 

Best regards,

John

 

From: Marcin.Gnat at dlr.de [mailto:Marcin.Gnat at dlr.de] 
Sent: Monday, August 06, 2012 4:45 AM
To: John Pietras
Cc: smwg at mailman.ccsds.org; css-csts at mailman.ccsds.org
Subject: RE: functional resource types for Retrieval Service
Packagecomponents?

 

Hi John,

 

Maybe you could clarify that to me -  I do not see maybe the obvious
things.

And anyway, I'm also not so deep into CSTS as you.

 

What is the actual difference between online and offline services? I
mean, why should I want to control the on-line stuff, and things which
come later (offline) not? 

 

For the online services, there are many aspects of production of a
Service Package that could be controlled and monitored that are not
accessible via the SLE (and in the future, CSTS) transfer services that
are used to transfer the space link data itself*. That is why CSTSWG is
currently developing the Monitored Data  CSTS, and will likely develop
the Service Control CSTS in the future - to be able to "get at" those
parameters. 

[*Of course, the F-CLTU service does have the THROW-EVENT operation, but
as formally defined it only addresses the production processes
associated with that forward link. Although it's possible to use the
THROW-EVENT operation of F-CLTU to control non-forward link production,
that essentially is nothing more than a kludged approach to the Service
Control service.]

 

For the offline-mode SLE services (and future complete-mode CSTS
services), the "production" is much simpler (there are no
transmitter/receiver parameters to deal with), and the needed real-time
control and monitoring functions are intended to be built-in in-band in
the service. When a UM schedules an offline SLE transfer service
instance as part of a Retrieval Service Package, the data store (i.e.,
the location of the stored data) and the physical channel source of the
data (e.g., S-Band I-channel) are identified in the configuration of the
Retrieval Service Package. When the user of that offline service BINDs
than STARTS the offline SLE/complete CSTS service instance, the user
identifies in the START invocation the time-span of data to be delivered
and (a) for RAF the frame quality (good frames only, erred frames only,
or all frames), or (b) for RCF and ROCF, the master channel or virtual
channel to be delivered. During the operation of the transfer service,
the services provide status reports and notifications. The intent of
these in-band control and reporting capabilities was that it would not
be necessary to have them separately controlled or reported on by
out-of-band means such as MD-CSTS or SC-CSTS. 

 

However, when I wrote my question last week I was not thinking about
legacy "playback"(i.e., offline) transfer services that may not have
sufficient in-band status and control capabilities. If we want to have
SCCS-SM be locally extended to encompass legacy capabilities, then our
model should be robust enough to allow for some out-of-band control and
monitoring of such services. Under this broader view, being able to
define Transfer Service Functional Resource types for such legacy
transfer services will allow them to be easily plugged into the monitor
and control architecture that we are developing.

 

Furthermore, perhaps it is an incorrect assumption that everything that
a user might want to monitor or control regarding a CCSDS-standard
retrieval (offline SLE or complete CSTS) service instance is available
in-line through that service instance.  What if the CM wants to see how
full a particular data store is, or cause it to purge some data ahead of
its algorithmically-defined time to purge data? Since by definition the
data store does not "belong" to a single Service Package (it persists
independent of the multiple Service Packages that collect its data) nor
does it belong to a single retrieval transfer service instance, neither
the SLS Service Package nor the individual retrieval transfer service
instance has the "authority" to control on the data store.  Perhaps we
want to expand out notion of Retrieval Service Package to, say, include
multiple retrieval transfer service instances and the data store with
which they are associated, along with MD-CSTS and SC-CSTS service
instances to monitor and control the Retrieval Service Package as a
whole. 

 

Reason I'm asking is, we have some offline services which produce the
service based on some specific information provided to the ground
station (or better to say, to the storage). The information is a kind of
a request for sending these and that frame range from the data dump
id-such-and-such. Does it fall under eventual CSTS in-band monitoring &
control? What would be an example of (probably not needed from us)
control service on such offline transfer? 

 

I think that I answered your questions in my response above.

 

Regards

Marcin

 

From: smwg-bounces at mailman.ccsds.org
[mailto:smwg-bounces at mailman.ccsds.org] On Behalf Of John Pietras
Sent: Dienstag, 31. Juli 2012 17:22
To: smwg at mailman.ccsds.org; css-csts at mailman.ccsds.org
Subject: [Smwg] functional resource types for Retrieval Service Package
components?

 

SMWG and CSTSWG colleagues -

I'm in the process of walking through a detailed scenario involving the
scheduling and execution of a Service Package that has Monitored Data
and Service Control services. In particular, I'm looking at how the
functional resource types and associated parameters, events, and
directives that are monitored and controlled (respectively) are properly
correlated to the Service Package. 

 

Until now, I think it's safe to say that we have all been thinking about
the Monitored Data and Service Control services as being associated with
Space Link Sessions. Does anyone envision monitoring or controlling
offline services (outside of the in-band capabilities provided by the
respective transfer services)? I personally cannot come up with a reason
to do so, especially since for SLE transfer services and CSTSes we have
essentially built in any monitoring that seems necessary.

 

If we do not see a need to monitor or control offline services, do we
need to define functional resource types corresponding to offline
service resources? The original purpose for defining functional resource
types was to provide a structure for naming monitored parameter values
and notified events (and then extended to cover directives); what, if
any, other purpose does a functional resource designation serve?

 

If you have an opinion on this I'd like to hear it.

 

Thanks.

 

Best regards,

John

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/css-csts/attachments/20120806/20c43758/attachment.html