[CESG] Request for CESG discussion of some SCCS-ARD topics that have arisen ...

[Shames, Peter M (US 312B)]

Dear CESG,

The SEA SAWG is working to clarify the path forward for updating the CCSDS Space Communication Cross Support Architecture Requirements Document, SCCS-ARD, CCSDS 901.1-M-1.

For the most part this is quite straightforward, involving the inclusion of new / modified standards, like:


  1.  SLS USLP
  2.  CSS CSTS MD, TD, and FF
  3.  SIS Newly published DTN standards
  4.  SLS Newly published optical comm standards
  5.  SLS DVB-S2, SCCC, and VCM standards that were not in the original version
  6.  The explicit inclusion of the SIS audio, video, and RFID standards left out of the original version

Most of these are fairly straightforward.  The inclusion of optical comm (item 4) is going to need to be handled with care, since it is a whole new set of coding and physical layer standards.  We believe that this is an important new capability in CCSDS, so we want it to be addressed clearly and carefully, but we do not want to warp the entire document by including, at every possible point, “RF and/or optical”.  We are still working out how best to deal with this, but it will likely involve introducing the issue early on, identifying that there will be explicit places where the two different physical layers are addressed, and otherwise retaining the “RF layer” references throughout.

We will need to take some similar approach with item 5) where we have the “standard CCSDS” suite of standards and then the quite different SCCC and DVB-S2 that combine three layers into one document, a distinct departure from the rest of the CCSDS canon.  Here too we do not want to warp the rest of the document by including these everywhere, so we plan to treat them in separate subsections where their distinct features can be described and then related to the rest of the standards suite.  The core of the document will remain focused on the “standard standards”.

As we did in the original SCCS documents, and in the ASL, we are adopting an approach of including not yet published, but planned, future standards.  These will be marked as [Future] in the text and listed only in an informative annex.  The idea is to provide visibility for the readers into what they can expect to become available during the five years until the next update.  This seems to have worked well in this last round, based on the significant, but relatively modest, list of new standards we have identified.

All of which brings us to one somewhat challenging topic:  CSS Service Management.  The CSS Area has been making very good progress in shifting from the earlier, massive and daunting, 910.11 Blue Book to a series of more focused data exchange standard formats for planning and scheduling.  As with the other significant, and valuable, new CCSDS standards we wanted to feature these new SM standards in their proper place.  However, after looking at these standards, and their delivery schedules, we think that the most significant ones will not be published for 2 years or more.

We are probably being optimistic, but we are making great progress and think that we can have this edited document ready for “prime time” review and approval processes in 12-18 months.

Given this assumed schedule, we think that we can get this revision done more quickly than the CSS SM WG is likely to get their SM docs standardized.  It would be nice, but unreasonable, to include these SM standards as [Done] when they are still [Future].  And we do not really want to create a new [Almost fully cooked] category.  So we think we have no choice but to leave them all in [Future] state and publish with the very limited SM features that are available.  This is clear and transparent, if not very satisfying.

We also think that these new CSS SM capabilities are major advancements that should be incorporated at the soonest opportunity.  We would like to know if the CESG agrees with this assessment?

One approach that has occurred to us is that we may wish to actually plan for an interim set of updates, published as a Corrigendum, once these SM documents are published.  This is a little out of the norm, but all of us who discussed it felt it was the best way forward given the situation.

We would like to know if the CESG agrees with this as well?

Thanks, Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/cesg/attachments/20210302/daa2bdd8/attachment-0001.htm>