[Sois-tcons] RE: reference model (2 levels of SOIS-compliance)

Jane K. Marquart Jane.K.Marquart at nasa.gov
Wed Mar 2 10:15:09 EST 2005

Hi Max,

Hope you're feeling better.  The flu has nailed quite a few people around 
here too.

I have to agree with Steve that there can only be 1 common layer and 1 
common protocol to achieve the SOIS goal of 
interoperability.  Interoperability is the only reason for SOIS's 
being.  There are plenty of other standards that can be, and are, used 
onboard spacecraft.  TCP/IP and SCPS are some of the "others", but they are 
not a SOIS protocol and are not SOIS-compliant (my opinion).  Rather, they 
can be carried over a SOIS protocol.  If I were a user looking at this 
diagram, I would assume I can use TCP/IP straight-up and be SOIS compliant, 
which I believe is not the case.  I don't think we are precluding the 
system engineer from trying other transport or network protocols but they 
have to meet the SOIS protocols and service interface BOTH.  Just meeting 
the service interface does not support the purpose of 

Let's take MTS.  I'm assuming that I can go out and find COTS middleware 
that may be compatible with MTS, can be carried by the MTS protocol, or I 
can build one to comply.  Does that mean I put all the possible middlewares 
in this diagram?  Also, there's nothing to say that I can't write my own 
network and transport code to meet the TCONS spec, but that's not shown in 
the diagram either.  TCP/IP carried over SOIS to me is an implementation 
(which is my favorite way to look at these things, but I'm trying to resist 
and do better at that "abstraction" view!)

As for other e-mails, I think the sub-net independent has ping-ponged back 
and forth between the network and data link layers.  Last I remember, its 
part of the data link.  I think we at GSFC got tired of the long name and 
started calling it the OBL generic (unofficially of course!).  Is OBL 
independent, and OBL dependent an option?

Lastly, should "services from OBL" extend into the physical layer?  I don't 
think we have any control over the physical layer, which is what this 
implies to me.

Anyway, that's my chime in!

At 03:01 PM 3/2/2005 +0100, you wrote:

>Dear all,
>Sorry for the late answer but I got the flu and come back to work only today.
>First of all I would like to remind you all to use the formal channels of
>communication (i.e. ccsds mailing list) in order not to remain 'invisible' to
>the secretariat.
>Second, I noticed that the choice of the reference diagrram model raised some
>very critical questions that have been dragged for long time.
>One in particular, above all, is:
>What does SOIS-compliance mean ?
>In my view, I do not feel like precluding system designers the possibility of
>experimenting different transport and network layer protocols for
>implementing "the same" SOIS standard services; this is why I think that
>TCP/UDP SCPS-TP IP etc. should be left in the diadram even if some minor
>graphical changes are required (will explain later why).
>The problem arises when we start to link protocol to service interfaces. I
>doubt that TCP/IP can fullfill ALL the requierments of SOIS services.
>In particular, how can TCP/IP guarantee a scheduled/time-constraint delivery
>of data onboard the spacecraft ?
>In other words, TCONS wg is working on the reccommendation of a standard
>service interface as well as the 'ideal' protocol definition for carring on
>ALL such services in the best way possible (hopefully); if a system designer
>decides not to use TCONS but other protocols instead, then the resulting
>system will lose interoperability with other systems implementing TCONS but
>it will still meet the requirements for being SOIS-compliant at the SERVICE
>At this point we see that 2 degrees of compatibility are emerging:
>Compliance with the SERVICE INTERFACE LEVEL will assure sw re-usability while
>compliance with the SERVICE INTERFACE LEVEL & PROTOCOL LEVEL will ensure sw
>re-usability as well as interoperability of SOIS implementations.
>You can notice how this 2-Levels SOIS-compliance will satisfy all parties
>without any major constraint on missions using SOIS.
>Having said that, the change that the diagram would need in order to reflect
>this concept is that the exposed TCONS service interface is always the same
>regardless of the protocols used for implementing a specific service,
>otherwise we can say goodbye to the sw re-usability.
>Furthermore, the protocols used within the TCONS box can be whatever
>combination of TCONS, TCP/IP, UDP/IP, SCPS/TP or any X-PROTOCOL still to be
>invented !!
>Attached is a revised version of the diagram:
>(See attached file: Ref_Model_Max.doc)
>What do you think of this approach ?
>Looking forward to your comments in order to solve this issue once for all.
>SW Engineer
>Computers & Data Systems Section
>VITROCISET - 2200 AG Noordwijk The Netherlands
>e-mail: Massimiliano.Ciccone at ESA.int               \|/
>Ph: +31-71-5655310                                         @ @
>                       Abhijit 
> Sengupta 
>                       <Abhijit.Sengupta at jp         To: 
> Stuart.Fowell at scisys.co.uk, Steve Parkes 
> <sparkes at computing.dundee.ac.uk>
>                       l.nasa.gov>                  cc: 
> c.plummer at skynet.be, Jane.K.Marquart at nasa.gov, 
> Massimiliano.Ciccone at esa.int,
>Patrick.Plancke at esa.int, 
>Rick.Schnurr at nasa.gov
>                       01/03/2005 11.21             Subject: RE: reference 
> model
>Hi Folks:
>Nice to receive comments from you on the reference model. Here is the
>changed version and responses to comments.
>Have fun!!
>All personal and professional opinions in this email are my own
>and do not represent, in any way, the opinion or policy of JPL
>(See attached file: sois-ref-model-w-response.doc)
>Sois-tcons mailing list
>Sois-tcons at mailman.ccsds.org

More information about the Sois-tcons mailing list