[CESG] Can we put a quick discussion of the SSI Architecture Document on the agenda for the telecon?

Tue Oct 8 07:34:07 EDT 2013

Scott and all, I would like to add my pennyworth on the SSI document.

The document has been around for years now and I wonder if is really worth
trying to improve it any further when there are other issue to be solved.

CCSDS can push the SSI as much as they want but in the end the only way our
mission will take it onboard (unintended pun) is if they see a benefit,
mainly in terms of science return and potentially in reduced operations
costs.

On new ESA missions (Euclid and JUICE)  we are now seeing a move from the
conventional  packet store and TM dump towards an onboard filing system and
the transfer of files in foreword and return directions using CFDP. This is
clearly a big step forwards but is has taken a significant effort  to
convince our project people, supported by analysis, test-bedding and
tutorials. Even so,  there are still those who persist on maintaining the
status quo and indeed there are still some advantages to self -identifying,
self-contained packets, especially when operating over long delay links,
where retransmission becomes an difficult.

I know I have expressed this point before, but here it is again: the way
forward to DTN take up is to first to establish file based operations as the
way of doing business in our missions. To support this by promoting the use
of the existing  CFDP protocol  (including the currently planned updates) and
to ensure that the necessary ground x-support services are established (I
don't believe they are yet, especially when I see the proposed BOF on ground
based file transfer). Once we have the community using files and file
transfer as nominal way of operating, the shift to DTN an the SSI will make
far more sense and will meet less resistance. On no account should we try and
cripple the existing CFDP protocol in an attempt to make DTN more attractive.

Even with the use of conventional file transfer there are issues which must
be resolved:

- The interface between instruments and the onboard mass memory - typically
this is based on self identifying packets so that even if packets are lost
science can be returned (I know that this shouldn't happen with a reliable
transfer but things can go wrong). The question is if we don't use packets,
what formatting should we promote to our instrument providers?

- The need for quick look data to determine if bulk science data should be
downloaded or deleted (sometimes implemented by selecting individual packets
from a packet store) but if we use files, the quick look data needs to be in
a separate file, again a change to the instrument interface and to the
operational scenario.

- HK data for platform and payload is typically stored in packets in a packet
store, sometime the complete packet store is download but sometimes the
download is only performed if there has been an onboard anomaly. In this case
the packets for download are selected by time. ( with file based ops we can
only download the complete file.

- observation related  information is generally required to be downloaded to
enable the associated science data to be processed. Again typically in
individual packets with the packet header containing  timing and validity
information  which we do not have with files.

There are also questions to be answered in the ground segment -  where is the
CFDP engine located (in the ground station or control centre or both).

The above, among others are all questions posed by the Euclid and Juice
projects. As CCSDS, we also need to cover the aspect of interoperability,
particularly for the ground segment but in the longer term also the space
segment.

The point,  as I see it is that we have probably spent enough time on laying
out the ground work and road map for the SSI. What needs to be done now is to
ensure that the associated transfer protocols are complete and fit for
purpose and  ensure that we can meet the actual mission application related
requirements.

Regards,
//ct

From:	"Scott, Keith L." <kscott at mitre.org>
To:	"Nestor Peccia (nestor.peccia at esa.int)" <nestor.peccia at esa.int>,
Cc:	"Burleigh, Scott C \(313B\)" <scott.c.burleigh at jpl.nasa.gov>,
            "John.j.rush at nasa.gov" <John.j.rush at nasa.gov>, "CCSDS Engineering
            Steering Group - CESG Exec	\(cesg at mailman.ccsds.org\)"
            <cesg at mailman.ccsds.org>
Date:	07/10/2013 20:41
Subject:	[CESG] Can we put a quick discussion of the SSI Architecture
            Document on the agenda for the telecon?
Sent by:	cesg-bounces at mailman.ccsds.org

Nestor,

SIS and SEA are trying to resolve the RIDS against the SSI architecture
document from the SEA area.  Peter’s proposal is to redefine the ‘stages’ of
the SSI architecture document around ‘degree of change to existing networks’
rather than the current ‘degree of automation / cross-support’.  Resolving
the RIDs would result in (I believe) significant changes in the document with
respect to what was sent to and approved by SISG / IOP.  I’m concerned that
large changes to the document at this point could be disruptive.

Attached are the SEA RIDs and a document from Peter describing his proposed
changes.

I’d like to discuss with the CESG what our options are for moving forward:

      1)    Go with Peter’s proposal (change the document)
      2)    Reject Peter’s RIDs and publish the document as-is
      3)    Consult with the SISG to determine their opinion
      4)    Other?

   Best Regards,

                     --keith

Dr. Keith Scott
Office: +1.703.983.6547
Principal Engineer, E535
kscott at mitre.org
The MITRE Corporation
M/S H300
7515 Colshire Drive
McLean, VA 22102

Area Director, CCSDS Space Internetworking Services

MITRE self-signs its own certificates.  Information about the MITRE PKI
Certificate Chain is available from http://www.mitre.org/tech/mii/pki/

    [attachment "730x1g01_CESG_Approval-SEA.pdf" deleted by Chris
   Taylor/estec/ESA] [attachment "IOP-3 SISG Updated proposal - 7Oct13.pptx"
   deleted by Chris Taylor/estec/ESA]
   _______________________________________________
   CESG mailing list
   CESG at mailman.ccsds.org
   http://mailman.ccsds.org/mailman/listinfo/cesg

This message and any attachments are intended for the use of the addressee or addressees only. The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content is not permitted. If you received this message in error, please notify the sender and delete it from your system. Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.