[Smwg] Framework for service management

Barkley, Erik J (3970) erik.j.barkley at jpl.nasa.gov
Thu Sep 14 01:48:20 UTC 2017

CSSM Colleagues,

I think that many of you can appreciate that we are not exactly "overflowing" with resources for the service management work. This was one of the factors that went into the decision to create an inter-recommendation tracking spreadsheet so that we could informally keep track of concerns and considerations that affect the set of service management recommendations as a whole without engaging the effort to produce a blue book or magenta book specifically to deal with this. I firmly believe that had we taken that path would still be laboring on getting to a first agency review given our resources!, and still be unfortunately quite a ways away from producing a first practical recommendation for our agencies - namely the Simple Schedule Format, or SSF (not to mention that the framework would be suffering from "abstract-itis" -- lack of real world experience gained with the SSF prototype interactions that have been successfully carried out).

Nonetheless, there is still a need for formal specifications and we have attempted to do that by including a normative annex in the first recommendation that is about to be published which is the SSF. However, Colin and myself and a few other members of the working group have had some second thoughts about this. In particular in attempting to perform the clean-up for the accepted RID SSF-R2-4.  This has to do with the inclusion of the abstract event definition which we have worked out in coordination with the navigation working group. In attempting to fix this up, as we originally conceived in the acceptance of the RID, it became clear to us that we are introducing, unnecessarily, dependencies between working groups in terms of maintaining formal definitions that will cause us pain for no benefit. I think this becomes even more apparent if you consider that the navigation working group is now starting to spin up work that will involve the abstract event definition and there may be in fact further changes needed for this which really have no bearing on the service management recommendations other than the fact that it happened to be defined here (you may wish to recall that in fact the SSF really has no need for the event definition).  Furthermore, it puts the CSSM WG in the rather awkward position of assuming some sort of NAVWG expertise, which we clearly do not have.

Taking a step back and recognizing that we have been struggling a bit with something of a similar problem in terms of what we view as the common type definitions for all of service management, Colin and I came to the conclusion that we can take a slightly different approach here that will lessen our dependencies but at the same time provide a more formal framework for moving forward with the service management recommendations as well as coordinating with other working groups.  So, rather than "burden" the SSF recommendation with definitions that are not directly and/or particularly germane to the recommendation it makes more sense to us to put these common and/or abstract definitions into a normative yellow book. I believe this is in fact a very good vehicle as a normative yellow book it can only be normative on CCSDS itself and in fact this is exactly what we are doing -- i.e. providing a framework to keep all of the service management work "honest" but not conflating the "inward" looking CCSDS production rules with the "outward" looking recommendations that agencies may eventually conform to.  (Kind of like not requiring someone to understand the entire automobile manufacturing supply chain cycle as pre-requisite to driving a car).

In practical terms, it means:

a)    a revised disposition to SSF-R2-4, which is still accepted

b)    The creation of a draft yellow book, which addresses the common and abstract type definitions

c)     Minor modification to the SSF book to remove these definitions and refer to the yellow book

d)    Minor revision to the UML model

e)     Minor re-factoring of the XML Schema,  which will not materially affect those infusion efforts already underway

The above have essentially already been done to see how things look. I will be checking this a bit further and will make it available to the WG as soon as possible and prior to the next teleconference on the 19th at the latest.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/smwg/attachments/20170914/8fab5880/attachment.html>

More information about the SMWG mailing list