In message <c9810f950902011357w67f3077ayca9fb265a4908...@mail.gmail.com> you 
wrote:
> One key feature of CAN is the lack of a single point of
> failure (minus a physical failure). In USB, you have the
> host controller. If it fails, all communications
> stop. With CAN, if any node fails, communications can
> continue among all remaining nodes.

The odds of us having a failure in the physical layer seem
to me to be much larger than the odds of a failure in some
higher layer---we know how to build and test our software on
the ground, but the physical problems we might have in
flight are hard to account for.  If there's a physical layer
failure in a node or wire other than the host controller,
USB can in principle (and in practice?) shut that connection
down and keep right on talking to the remaining nodes.  (If
you don't trust the USB host controller electronics, it's
possible in principal to optoisolate the host controller
from the rest of the system.) Because CAN is a hard-wired
bus, there's no physical-layer isolation between nodes, so a
bus short means we're totally screwed, and a bus open means
we're pretty well screwed, and a transceiver electrical
failure could in principle do anything.  Or am I missing
something?

At any rate, my understanding is that when you actually look
harder at the details of CAN's guarantees of reliability,
they really only apply to the MAC/link layer.  The
application layer is IMHO the most likely place other than
the physical layer for a problem to appear.  An
application-layer error that floods the CAN bus will
effectively kill the entire bus; again USB will to some
degree resist this because of its polled and slotted nature.
(Again unless I'm missing something...)

Remember, USB lives in an environment that is in some ways
much harsher than aerospace---the brutally careless and
wilfully ignorant consumer who cables things together wrong,
then shorts the cable by rolling over it, then energizes the
5V device with a 9V wall wart, etc, etc.  End users do
unspeakable things to electronics, and USB in my limited
experience mostly just sits there and tolerates them.  YMMV.

> In reading I've done in the past that discuss
> high-reliability aviation systems, the designs have been
> such that no single point can take out the whole system,
> and in many systems, the capability's of one component are
> also available in another component such that when the
> system as a whole notices the failure of the primary, the
> secondary can take over the functionality. One of the
> thing it depends on though is a communications mechanism
> where all devices on the communications system can work
> with or without the other devices.

I don't want to even try to engineer to this degree of
reliability until we've demonstrated we can actually fly
something at all.  It's been almost three years since we've
flown any avionics, and I would much rather do a later
redesign of a simple but sufficient system we will have
built and flown in an upcoming launch, and whose weaknesses
we will understand from modeling and experience, than keep
building ever more "reliable" systems on paper.  IMHO the
only thing worse than starting over with a second bus at
this point would be to do so while still continuing to work
on the current bus.  Our resources for building a working
avionics system are split fine enough as it is, and time is
getting short.

> I'm in agreement that for large quantities of data
> transfer (large quantities being our high sample rate
> sensor data streams) CAN is not the best choice. But for
> controls, which need "high" speed, low latency and high
> reliability, CAN is more appropriate for these situations.

If we want CAN for its putative reliability or for some
other reason, I feel strongly that we should just ditch USB
and go with CAN as our primary system bus.  Yes, it has some
limitations, but I'd much rather work around them as we
build the thing than work simultaneously on one untested and
two unbuilt aviation buses for an untested and unbuilt
avionics system.  We deliberately chose the hardware we did
so that we could put off the CAN vs USB decision until late
in the process; AFAIK it would be easy right now to just use
the CAN version of the LPC instead of the USB version.  And
we've demonstrated that CAN is sufficient, if not ideal, for
flying a rocket with hardware very like the one we're
building now.

I obviously would prefer to fly USB for several reasons.  As
I stated above, I think USB can be made highly reliable
while maintaining its nice bandwidth.  The ability to buy
cheap and easy-to-get COTS modules and plug them into our
rocket is potentially really convenient.  The ability to
take our custom modules and plug them directly into our
laptops without a complex $200 piece of disintermediary
hardware is potentially really convenient.

Also, I think there's an intangible advantage in
externalities.  Just as people's eyes get big when we say
we've flown a telemetry system at mach 1.2 and 10000' using
'COTS' 802.11, I think some people's eyes will get big when
we say "oh, yeah, and our avionics is just an ordinary Linux
flight computer with 'ordinary' USB peripherals."

Finally, I think it would be sad to abandon USB based on
nothing more than fears that so far have proven groundless
when we have tested them.  When Dave and K got a reliable
isochronous connection between the LPC and a Linux box, I
thought we'd pretty much shown we can make this puppy work.
I'm hearing that folks think that's not good enough.  So
someone please tell us specifically what it would take to
remove the fear of USB, so that we can at least try to
produce that quickly.  It doesn't seem like too much to ask
given all the work that has been put in so far.

But whatever we do, I'm afraid I'm with Sarah.  The simplest
single sufficient thing everybody can agree would be OK,
that we can build, evaluate and fly quickly is far and away
my preference.  At the end of the day I don't care if it's
HDLC or Appletalk (which is a kind of HDLC) or FSK modems or
old-school Ethernet transceivers.  If it will likely work,
and we can slap it together with a microcontroller, try it
out with the host, and then put a fire under it to make it
go up in the air, all with the least effort, I vote yes.

Let's build something.

    Bart

_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics

Reply via email to