[Smwg] RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

Mon Jun 15 18:30:19 UTC 2015

Erik,
See comments <JVP> embedded</JVP> below.

John

From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Tuesday, June 09, 2015 9:55 PM
To: John Pietras; CCSDS SMWG ML (smwg at mailman.ccsds.org); CCSDS_CSTSWG (css-csts at mailman.ccsds.org)
Subject: RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

John,

The notion of being able to only subtract from the maximum set of transfer services in the configuration profile I think addresses my main concern. I think we should note that this perhaps means some relatively minor lesser ability for dynamic configuration on the fly ("oh, but we really want that extra transfer service today") but that is probably okay. How I read this then (and probably what was implied all along) is that the resource instance numbers are a configuration profile build time activity only and cannot be dynamically added to at service package request time. Presumably, for the eventual SM spec, I assume that the FR Names will be called out for indicating the particular transfer instance is "on" or "off" (further assuming that this shows up in the new version of Service Package Request).

<JVP> I am assuming that we'll use something similar to the instanceEnabled parameter for each transfer service instance, as described below </JVP>

With regard to a diagram, below is a copy of a diagram we discussed at the service management meeting with regard to development of service agreement and service configuration profile books.    I think this helps in looking at the overall situation. For example, SLE will continue to have, presumably, it's "traditional" SIIs and not the "newfangled" CSTS identifiers. But service management will have to deal with both of these. Although these are not class diagrams, there was in some of the other diagrams in the discussion indications of cardinality and it will help to understand that, for example, the typical cardinality as far as I know for the SLE FWD Space Pkt to TC SLP is 0..* -- granted that does not add much to the SII discussion but it does help to know that the SIIs, based on the FR Name, need to allow for whatever cardinality is specified.

<JVP> It sounds like you're referring to the diagram that you are talking about is the big Functional Resource diagram (fig. 4-1) and possibly the functional resource composition diagrams throughout section 6 of the FR Tech Note. The Data Transfer Services FRs that correspond to the SLE and CSTS transfer services are color-coed as such, and the cardinality is shown. </JVP>

And it will also be nice to see MD-CSTS in this picture - messy as that may be.    If MD-CSTS is a functional resource to the same degree that TD-CSTS is, then this seems to argue that it will be called out in the SM configuration profile, as well.

<JVP>  The diagram below shows the Service Components involved in the production and provision of space communication and radiometric data services. MD-CSTS is not explicitly shown here because (a) it belongs to the Service Management Functions Abstract Service Component and (b) since the MD-CSTS "touches" everything involved in the production and provision of space communication and radiometric data services, it would indeed be messy. But if you do want to see MD-CSTS on a similar diagram, look at fig. 6-26 of the FR Tech Note. </JVP>

In any case, I think my main concerns re SII have been addressed for now.

Best regards,

-Erik

[cid:image001.png at 01D0A774.CD6BE6B0]

From: John Pietras [mailto:john.pietras at gst.com]
Sent: Monday, June 08, 2015 2:04 PM
To: Barkley, Erik J (3970); CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>); CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)
Subject: RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

Erik,
I'm not sure what you are asking for n the way of a diagram. Do you just want to see a graphical representation of the contents of the exist CSTS SII vs. the proposed one? Somehow I'm guessing that it's more than that. If you can give me a little better idea of what "situation" you are referring to, I'll give it a stab.

Meanwhile, I'll try to respond to your questions and comments on point 2 (interleaved in <JVP> red </JVP> below). Maybe the answers will be good enough to bypass the need for a diagram (or further clarify what the focus of the diagram should be).

Best regards,
John

From: Barkley, Erik J (3970) [mailto:erik.j.barkley at jpl.nasa.gov]
Sent: Thursday, June 04, 2015 8:02 PM
To: John Pietras; CCSDS SMWG ML (smwg at mailman.ccsds.org<mailto:smwg at mailman.ccsds.org>); CCSDS_CSTSWG (css-csts at mailman.ccsds.org<mailto:css-csts at mailman.ccsds.org>)
Subject: RE: [Css-csts] Relationship between CSTS Service Instance Identifier and Extensible SCCS-SM

John,

Now that I've had a bit of time to digest this, some comments, questions.

1)      Pg 6, it will probably be helpful if a diagram could be produced that illustrates the situation. I hope that is not a significant undertaking.

2)      Assuming that the FRIN being used in the SII is as I think it is (the diagram will help), it does raise some potential concerns

a.       If we assume that the next generation service package has the current B-1 capability (which I believe is the case per the current abstract service request engineering under way) to modify a configuration profile (technically profile re-specification) for the duration of the service package, then do we assume that the addition of a CSTS instance as part of that modification for the service package will come with a "pre-validated" FRIN --> SII ?  Or am I missing something here? ("Turning off" as CSTS instance does not seem like a problem).  Also, we would probably disallow modification of FRINs as part of the service package configuration profile re-specification?

<JVP> Good question and observation. If you recall, in SCCS-SM B-1 we didn't actually allow space communication service profiles to be re-specified in Service Packages to add  (SLE) transfer service instances in an unconstrained way. Rather, each space communication service profile is defined as having an existing set of transfer service mapping objects (TsMaps), where each TsMap is linked to a Transfer Service instance that is defined in a different part of the Service Package. Each TsMap object has an instanceEnabled parameter that is used to include that TS instance in the Service Package. So the greatest possible population of TS instances available via a given space communication service profile *is* predefined - the only option is to re-specify one or more of the  TsMaps as being disabled (i.e., not used in this particular Service Package).

We can use an approach that is similar for Extensible SCCS-SM, although there are possibilities for variations that might be better and should be explored. For the sake of discussion, the approach that is arguably closest to the B-1 approach  is one in which there are a predefined pool of TS profiles (now CSTSes in addition to SLE TSes) that can be used to construct Service Packages. Each of those pre-defined TS profiles will be for a specific service instance and  will have a FRIN that cannot be changed. Each space communication service packages will contain mappings to the maximum set of TS instances that might possibly be used.

This is my current thinking, and I think that it is feasible. If anyone can see flaws of has a better or more elegant approach, please don't hesitate to speak up.

Note that there is a slight difference between this Extensible approach and the B-1 approach. In B-1, we allowed for the possibility of multiple instances of the same TS profile to exist. Multiple TsMap objects is a space communication service profile could point to the same TS profile, and in scheduling a Service Package with such a space communication service profile, Complex Management (CM) would dynamically assign a different transferServiceInstanceNumber to each TS instance. If you think about it, that is exactly the situation that we had when we assumed that CM (now Provision Management (PM)) would dynamically assign the FRINs - Mission users of the service could only know what service instance they were dealing with after reading the Service Package Result. Requiring the there be a profile for each possible TS instance removes that dynamic uncertainty at the cost of creating multiple TS profiles where possibly only one might have needed to be created, although in reality I have come to question whether multiple instances of the same TS profile was all that useful a "feature" anyway.

</JVP>

b.      It seems that for this approach, for things like MD-CSTS or TD-CSTS instances would have to be part of the service configuration profile.   I'm not sure we have agreement that this would be the case - I think we have asked questions like "are things like MD-CSTS just assumed to be there or do they need to be explicitly defined in the service configuration profile"?  I will agree that it does not seem like a likely use case to have two MD-CSTS (or TD-CSTS) instances running in parallel, but I would not put it past an implementation to think of "interesting" deployment options.   Again, perhaps I'm mission something here.

<JVP> I'm not sure that I agree about the unlikelihood of multiple instances of MD-CSTS or TD-CSTS in the same Service Package - for complex spacecraft with concurrent links in multiple bands, there may be operators monitoring performance per band, and as far as TD-CSTS goes, I can easily see the spacecraft control center getting a subset of tracking data that helps them evaluate the progress of a maneuver in near-real time, whereas another TD-CSTS user of the same Service Package might be a Flight Dynamics facility that's collecting all sorts of measurements in order to maintain a highly accurate trajectory model.

Be that as it may, for whatever reasons, I have been assuming that multiple MD-CSTS and TD-CSTS instances can exist in a Service Package (however, I do believe that only one Service Control CSTS instance should exist per Service Package). However, the MD-CSTS and TD-CSTS cases relate to the sService Package in different ways. Let's look at each case individually.

The  MD-CSTS inherently can touch all functional resources in a service package, although the user of the MD-CSTS has to select (using the list-of-parameters and list-of-events parameters of the relevant START invocations) which parameters and event notification will actually be reported. The MD-CSTS has the great advantage that it names its parameters and events using the same functional resource-based naming that Service Management uses. E.g., since the functional resource that corresponds to the X-band downlink is represented in the Service Package as [FR Type OID = {Return 401 Space Link Carrier Reception} : FRIN = 2 ] , when MD-CSTS reports the actual-receive-frequency for [FR Type OID = {Return 401 Space Link Carrier Reception} : FRIN = 2 ] the MD-CSTS user already knows where its coming from.

There may be multiple MD-CSTS profiles (again, one for each possible MD-CSTS instance), but they will "attach" to the service package at a different place than where the space communication service profiles and what I'll call space communication transfer services profiles attach.

Now let's look at the situation with TD-CSTS, which  is a bit trickier. A TD-CSTS instance  is also nominally capable of reporting all tracking data measurements generated out of a service package, so it too attaches to the service package independent of individual space communication service profiles. But the relationship between what tracking-data-generating resources are contained in the configuration profiles and what gets reported in the payload of the TD-CSTS TRANSFER-DATA messages is not as straightforward is it is with MD-CSTS, because the TD-CSTS carries TDM segments that of course contain no reference to functional resource instances. I am still far from coming up with a complete solution, but as of now I'm assuming that the solution will involve something like the following:

1.       Those functional resources that represent resources that generate tracking data will have managed parameters that identify the TDM keyword values that are to be used for those tracking data parameters and associated metadata keywords. Admittedly, this mapping will be complicated, because of the way the TDMs separate their information between metadata and data sections.

2.       The TD-CSTS profiles will have to have some way of specifying which tracking data measurements from which particular functional resource instances are going to be reported by the particular TD-CSTS instance. Unlike MD-CSTS, where the user of the service instance selects what she wants reported dynamically after the service instance is bound, in TD-CSTS all such selections have been deferred to Service Management. I have to admit that that was done so that a TD-CSTS spec could be created without having to develop a language for dynamically specifying what is to be delivered. Yeah - I kicked the can over the wall to Service Management.

So the bottom line is that I'm comfortable that we've got a good handle on MD-CSTS (although I may not have yet convinced you of that), but I admit that there's still a lot of work integrating TD-CSTS into Service Management. But even so, to get back to what I think was the scope of your original question, TD-CSTS will still be an entity of the Service Package as a whole and not "contained by" space communication service profiles.

Did that in any way answer any of your questions?
</JVP>

Best regards,
-Erik

________________________________

Spam<https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=s>
Not spam<https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=n>
Forget previous vote<https://filter.gst.com/canit/b.php?i=01OCpW0PU&m=b17aa4c4c4a1&c=f>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150615/c3a88480/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 39071 bytes
Desc: image001.png
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20150615/c3a88480/attachment.png>