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

Wed Mar 3 08:08:39 UTC 2021

For Your Information

As you see, many SLS items are addressed by Peter.

Please forward any comment/remark to Gilles and me for proper coordination 
in the Area.
Please do not forward comments directly to Peter to avoid increasing 
entropy.

Best regards and stay healthy

Gian Paolo

----- Forwarded by Gian Paolo Calzolari/esoc/ESA on 03-03-21 09:03 -----

From:   "Shames, Peter M\(US 312B\) via CESG" <cesg at mailman.ccsds.org>
To:     "CCSDS Engineering Steering Group - CESG Exec" 
<cesg at mailman.ccsds.org>
Date:   03-03-21 00:19
Subject:        [CESG] Request for CESG discussion of some SCCS-ARD topics 
that have arisen ...
Sent by:        "CESG" <cesg-bounces at mailman.ccsds.org>

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
 _______________________________________________
CESG mailing list
CESG at mailman.ccsds.org
https://mailman.ccsds.org/cgi-bin/mailman/listinfo/cesg

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.ccsds.org/pipermail/sls/attachments/20210303/50fab7ed/attachment-0001.htm>