Quoting Barton C Massey <b...@cs.pdx.edu>:
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?
Yes, I think you are. A failed node (dominant state) will cause the
CAN hardware to release the bus and allow other traffic (including
reception) to continue within 1 millisecond. A node failed in the
recessive state will not affect the bus at all. Further, CAN nodes are
isolated in practice (not just in principle) if the application
warrants doing so. I believe the isolation provided by a standard
transceiver is sufficient.
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...)
Again, you are missing something. An application layer that floods the
bus (but doesn't invoke transceiver safeguards) will cause enough
error frames that the CAN controller will go "bus-off" and stop
transmitting.
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.
Rolling over your mouse cable won't cause 100,000 lbs of cargo to get
dropped 3 stories onto a shipping dock. That's why desktop computers
can use USB, while industrial equipment uses CAN. Try merely *using*
your mouse within 20 feet of a 3-phase arc furnace.
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.
Agreed. I think this level of redundancy is not realistic with the
expertise on hand. The analysis required is far beyond what the
members of this group are willing to do for free and in a timely manner.
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 don't think we are starting over. I think Andrew and Tim have some
good reasons for adding a back channel to counter a few weaknesses of
USB.
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.
I think some folks are not quite on the same page here... One chip,
the LPC2378, does both CAN *and* USB. We have demonstrated both. The
only thing that has not been done is to demonstrate both on the FC
using actual, useful data, primarily because no one has built an
application for the FC which needs any data.
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.
I don't think the intention is to abandon USB. Instead, we would like
to augment USB so that we can have a bus either A) If the FC fails, or
B) If we are too afraid to risk the FC on an initial recovery test
flight. Andrew said "a serial bus". That could be uart, but CAN
clearly makes more sense for a back channel for all the reason
discussed in this thread.
All,
Either way, if you have reservations to the idea of using CAN, then
please allow those of us that are interested in it to give it a try.
We aren't slipping any schedules to get it done, so there is no harm.
_______________________________________________
psas-avionics mailing list
psas-avionics@lists.psas.pdx.edu
http://lists.psas.pdx.edu/mailman/listinfo/psas-avionics
