<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
p
{mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
</head>
<body lang=EN-GB link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>And what glued the whole CCSDS show
together in the early days was the clear link to a project! It is my
contention that one way to sharpen up all of CCSDS activities would be to make
it a requirement that each new work item is only approved if it has a “customer”,
i.e. a project backing it. However, I’m loath to push this forward
through the CESG channels without further offline discussion with CESG members
because I realise that pragmatically this would be very hard to achieve given
the way that projects currently behave (institutional inertia as you so
delicately put it Dai).<o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Chris. <o:p></o:p></span></font></p>
<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p> </o:p></span></font></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabindex=-1>
</span></font></div>
<p class=MsoNormal><b><font size=2 face=Tahoma><span lang=EN-US
style='font-size:10.0pt;font-family:Tahoma;font-weight:bold'>From:</span></font></b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
dstanton@keltik.co.uk [mailto:dstanton@keltik.co.uk] <br>
<b><span style='font-weight:bold'>Sent:</span></b> 01 April 2005 16:09<br>
<b><span style='font-weight:bold'>To:</span></b> dstanton@keltik.co.uk;
sois-tcons@mailman.ccsds.org; Chris Plummer<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Sois-tcons] TCONS
rationale</span></font><span lang=EN-US><o:p></o:p></span></p>
</div>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Agreed.
At present we have, on the one hand, synchronous, inflexible busses which
support rigidly planned, inflexible operations and they bot to some extent feed
off each other. In many ways, the operators are very comfortable with knowing
what information is on the bus to an increment of a clock cycle. However, these
busses do not easliy support message-based applications.<o:p></o:p></span></font></p>
<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>I believe
SOIS need to take a bold line. SOIS need to make the case for succesful
operations using a flexible asynchronous communications model. CCSDS took this
line in the space link. It took 10 years for publication to general acceptance
but now packet TM/TC is CCSDS's only true success. It was achieved by laying
aside current practice in the large agencies and looking to future
requirements. I beleive SOIS needs to play just such a long game and not try to
buy instant acceptance by adopting too much of the current approach. Outside of
the large agencies who have risk and cost pressures to reuse design and
equipment over the next few mission cycles, there are missions who would
welcome flexible standardised interfaces particularly at the bus/LAN level if only
to settle the interfaces between the academic institutions providing payloads
and the designers of the bus. 10 years ago, on STRV, we'd have been glad of an
international standard for packet transfer to impose on everyone. Without a big
stick (like, for instance, a CCSDS recommendation) we had to negotiate
interfaces individually.<o:p></o:p></span></font></p>
<p style='margin-bottom:12.0pt'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>We need to take the example of packet TM/TC, play to
the missions who don't have any institutional intertia and possibly wait for
many of the current generation of project managers to expire.<br>
<br>
<br>
<br>
<b><span style='font-weight:bold'>On Fri, 1 Apr 2005 14:16 , Chris Plummer
<c.plummer@skynet.be> sent:<o:p></o:p></span></b></span></font></p>
<blockquote style='border:none;border-left:solid whitesmoke 1.5pt;padding:0cm 0cm 0cm 4.0pt;
margin-left:3.75pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt'><DEFANGED_META content="text/html; charset=us-ascii" http-equiv="Content-Type"><DEFANGED_META name="Generator" content="Microsoft Word 11 (filtered medium)"><!--
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
--><!--
<!--
/* Font Definitions */
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman";}
a:link, span.MsoHyperlink
{color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:Arial;
color:navy;}
@page Section1
{size:595.3pt 841.9pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>--> <o:p></o:p></span></font></p>
<DEFANGED_BODY lang=EN-GB link="blue" vlink="purple">
<div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Yes, that’s the right direction in my view.<u1:p></u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><u1:p> </u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>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.<u1:p></u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><u1:p> </u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>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!<u1:p></u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><u1:p> </u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>LetR17;s look very carefully at the formats of the data that
onboard users want to exchange, and the size and frequency of exchange.<u1:p></u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><u1:p> </u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>Chris. <u1:p></u1:p></span></font><o:p></o:p></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><u1:p> </u1:p></span></font><o:p></o:p></p>
<div>
<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span lang=EN-US style='font-size:12.0pt'>
<hr size=2 width="100%" align=center tabIndex=-1>
</span></font></div>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b><font
size=2 face=Tahoma><span lang=EN-US style='font-size:10.0pt;font-family:Tahoma;
font-weight:bold'>From:</span></font></b><font size=2 face=Tahoma><span
lang=EN-US style='font-size:10.0pt;font-family:Tahoma'>
sois-tcons-bounces@mailman.ccsds.org [mailto:sois-tcons-bounces@mailman.ccsds.org]
<b><span style='font-weight:bold'>On Behalf Of </span></b>dstanton@keltik.co.uk<br>
<b><span style='font-weight:bold'>Sent:</span></b> 01 April 2005 13:06<br>
<b><span style='font-weight:bold'>To:</span></b> sois-tcons@mailman.ccsds.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> [Sois-tcons] TCONS
rationale</span></font><o:p></o:p></p>
</div>
<u1:p></u1:p>
<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><u1:p> </u1:p><o:p></o:p></span></font></p>
<p class=MsoNormal style='mso-margin-top-alt:auto;margin-bottom:12.0pt'><font
size=3 face="Times New Roman"><span style='font-size:12.0pt'><br>
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.<br>
<br>
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:<br>
<br>
Bit efficiency (arguments about IP header compression etc.)<br>
Priority (does Diffserv do the job?)<br>
Scheduling (Why?, Which applications?)<br>
<br>
The fundamental arguments against are likely to be (and I'm playing devils's
advocate here):<br>
<br>
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?<br>
<br>
Are these services actually required by real applications? <br>
<br>
Can these services be provided by other transport/network layers?<br>
<br>
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?<br>
<br>
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.<br>
<br>
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. <br>
<br>
Any thoughts?<br>
<br>
Dai<br>
<br>
<br>
<o:p></o:p></span></font></p>
</div>
</blockquote>
<u1:p></u1:p>
<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p> </o:p></span></font></p>
</div>
</body>
</html>