Re: embedded aviation computers.

[Jerome Kaidor <jerryk@best.com>]

> First off, the group looks dead, what's up, or not up as the case may be?
> 
> 
> In the never-ending quest....
> 
> All these projects related to custom hardware etc are very interesting, 
> but I really wonder if we'd not be a lot better off to grab semi-standard
> eqpt and get moving.
> 
> Decent linux code sould be portable to any reasonable platform as it 
> becomes reasonable in cost, reliability and support.
> 
*** My only problem with all of this is reliability.  Whups, just a second,
my PC just died....<reset>.   While Linux is surely more robust than Windows
of any flavor, I would still not trust it to run my flight instruments! 
It's just too big.

   Imagine, you have a standard PC, running a large OS, such as Linux or 
Windows.  How can you convince yourself that the software is correct? 
There's so much of it!  And PC hardware is not necessarily designed
to high standards of timing and temperature range, not to mention vibration
resistance.

   My first job in programming was for a piece of railroad equipment.  The
safety of life and property was involved, so the hardware design was 
extremely robust.  Clock rates were kept low, and ample margins used for
all timings.  The backplane had traces on one side, a solid ground on
the other, and guard traces ( all connected to ground ) between the signal
traces.  The clock pulses on this thing looked like out of a textbook!
The engineer tested it with a 5W CB radio with a rubber duckie antenna -
he stuck the antenna inside the chassis and scoped the clock lines.  If
he saw RF, he went back to the drawing board.

   The software was written to the same high standard.  Our CPU spent 
something like 30% of its time doing integrity tests.  Things like the
memory and I/O were constantly being incrementally tested.  Critical 
software items like the stack were constantly checked for reasonableness.
For example, the main loop checked the stack pointer each time around - it
needed to always be the same number.  The stack was "guarded" with a known
value somewhat below the top - if it was about to blow, that known value
would change, and our program could take action.  A hardware watchdog timer
on a short 200-ms fuse constantly watched the system.

   There was no OS, and we laboriously verified every section of the program
for correctness.  It got so good that we had trouble fixing bugs, because
the system would fix itself so fast!  If something really bad happened, the
system would reset, and we had it to where it could perform a full reset and
be back in normal operation in about a half a second.   But we gradually 
weeded out even all the causes of these failures.

   And THAT's the caliber of hardware and software I would want running my
flight instruments.  I don't think it's attainable with a "big" OS, even
Linux.  Maybe with something like VRTX or Nucleus OS, although I even have
my doubts about those.   At least with Linux, you get the source.

                      - Jerry Kaidor ( jerry@tr2.com )
-
Archives of linux-aviation: http://mail.nl.linux.org/lists/linux-aviation/
To unsubscribe: send the command "unsubscribe linux-aviation" in the body
of a mail message to <Majordomo@mail.nl.linux.org>.