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.
This archive was generated by hypermail 2b29 : Mon Jun 17 2002 - 13:38:26 EDT