Re: Satellites running IP

[David Carek <[e-mail]>]

Colin Paul Gloster wrote:
> On Mon, 17 Jun 2002, David Carek wrote:
> "[..]
> 
> The problem is, that I keep coming up with more reasons not to use 
> Internet protols, than reasons to use them. [..]"
> 
> David,
> Could you please indicate what some of these reasons would
> be?
> Regards,
> Colin Paul Gloster


Sure

False Perception of Standards - There is a perception that using 
Internet standards is actually a single standard, when in fact it is a 
collage interpretations and implementations of RFC's.  I doubt any two 
TCP/IP stacks implement the standards the same way.  The standard is 
actually the least common demoninator of the various implemtations.

Flight Qualification (Increased Potential for Software Faults) - Adding 
15000 lines of code that someone else wrote to your satellite creates a 
black box of software that is extremely difficult if not impossible to 
thouroghly test.  I have had a bad experience with one stack we used on 
a shuttle experiment that would hang the system when it recieved any 
non-tcp packets.  This was a older real-time embedded system (that shall 
remain nameless).  It should have been impossible for the TCP/IP module 
to completely hang the system ... but it did.
Increased software = increased complexity = increased chance for errors

Other potential problems include:

Technology Lag/Obsolescence (satellite technology generally 5-10 years 
behind terestrial)
RTOS support
Deterministic Timing Requirements (onboard systems)
Performance Limitations of Rad Hard processors
Reliability (TCP reliability might not be good enough)

I've got others ... but that's a start.

This isn't to say these issues can't be overcome.  They are just 
engineering problems and entirely workable. And certianly a system that 
is compatible with Internet systems is definitely beneficial to the 
overall communications architecture ... especially when integrating into 
the  ground systems.