[Sois-tcons] TCONS rationale

[Chris Plummer]

Yes, that's the right direction in my view.

 

A couple of points to throw into the mix. For the OBL stuff and the fact
that we have to "pander" to such horrors as 1553, there is a subtle reason
for this. 1553, and other similar buses like ESA OBDH impose some limits on
the way you do things. In the old days, spacecraft that adopted these buses
were obliged to work within those limits and there flight architecture and
the way the software was designed was basically driven by this. Subsequent
missions tend to base themselves on what went before to a greater or lesser
degree and therefore generate specifications that are similar to preceding
spacecraft. When you design a spacecraft based on these specs, you find that
not surprisingly, they can be implemented quite nicely on 1553 like buses.
So we have a self reinforcing feedback system that is based on outdated
considerations that no one seems prepared to challenge seriously. This
fundamentally is why projects do not give proper consideration to the choice
of onboard bus, and why we keep having 1553 and its like thrust upon us. I
think the OBL concepts as they were originally conceived back in 2001 break
this unhealthy feedback loop and open the way to making a better informed
selection of the onboard bus, but we have not promulgated this concept
sufficiently well.

 

As for the application needs, onboard systems are typically run on
synchronous distributed deterministic schedules at the moment, largely
because that is the way they have been done before, and that is what the
current onboard buses seem to support best. There are a few systems that are
breaking away from this model (including things like OBOSS) which are based
on asynchronous operation and the exchange of short (10 to 20 octet) fully
delimited messages. As Steve pointed out yesterday there are also users who
want to transfer enormous images and usually get dedicated links to do this.
However, while these latter applications might look like candidates for a
stream service, I would contend that this is actually a very risky and
inefficient way of transferring such data. In fact, I cannot imagine any
data, even in terrestrial applications, that is naturally suited to a
streaming service!

 

Let's look very carefully at the formats of the data that onboard users want
to exchange, and the size and frequency of exchange.

 

Chris.  

 

  _____  

From: sois-tcons-bounces at mailman.ccsds.org
[mailto:sois-tcons-bounces at mailman.ccsds.org] On Behalf Of
dstanton at keltik.co.uk
Sent: 01 April 2005 13:06
To: sois-tcons at mailman.ccsds.org
Subject: [Sois-tcons] TCONS rationale

 


My initial thoughts were to look to the TCOA documentation to find the
services which they are demanding of the underlying transfer layer and which
are not provided by current transport services. However, there isn't much to
be got from their documents.

We need to identify very succinctly the TCONS USPs (Unique Selling Points)
in bullet form and to identify the arguments for and against existing
protocols which may already have them. So, a first cut would be:

Bit efficiency (arguments about IP header compression etc.)
Priority (does Diffserv do the job?)
Scheduling (Why?, Which applications?)

The fundamental arguments against are likely to be (and I'm playing devils's
advocate here):

Are we really likely to need to have to provide these services across
hetereogeneous busses? Are we compensating for bad spaceraft design and
(flameproof suit on) the failure of OBL to arrive at a standardised bus/LAN?

Are these services actually required by real applications? 

Can these services be provided by other transport/network layers?

Can these issues be solved by using conventional protocols across high
capacity busses? The space link guys have the laws of physics working
against them. We don't have such an excuse for having limited bandwidth. Do
the power or availability of rad hard devices arguments wash? If we have
spacewire why are we worried about bit efficiency and priority?

Fundamentally we are missing a SOIS concept of operations and policies (one
such policy issue is why are we prepared to be iconoclastic at the network
layer and yet pander to entrenched positions at the bus/lan level, trying to
accommodate every flavour of bus that has ever flown or likely to be flown).
Looking at the documentation, ther's a lot of assertion without much in the
way of justification. This may be because I haven't seen some of the earlier
work.

I'm not trying to shoot everyone down here. It's just that if we aren't
clear in our own minds on these issues, it will be very difficult to defend
TCONS/SOIS at the CESG. 

Any thoughts?

Dai



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/sois-tcons/attachments/20050401/35416513/attachment.html