- Report
Posted April 15, 2019
32 minutes ago, johncuyle said:
CAN is generally slower. That comparison uses 10MBPS Ethernet. Nobody's used that for ages. Your home network is most likely all gigabit (mine is, except for a handful of low cost appliance-like devices which only have 100mbps controllers because they don't need any more) and could easily be 10 gigabit if you have a reason to need that much throughput. Also odd, that paper compares TCP running on top of ethernet. TCP seems like an inappropriate protocol for this sort of application. High performance, low latency networking over ethernet generally calls for UDP.
CAN seems appropriate for aviation as it was for automotive. Small area, relatively low latency, low throughput is the application. It's a huge improvement over what aviation currently uses. Consider, you have a transponder, ELT, and a couple AP servos in the tail. Conventional aviation engineering requires two ports on your GPS with GPS out, one port each on your XPDR and ELT for GPS in, a third port to feed your AP somehow, three runs of wire, one for each device connected to your GPS (so two runs to the avionics bay) and separate runs from the AP to the servos (so a third/fourth run through the avionics bay) and also more runs to the switches for the ELT, etc. CAN allows one port per device and one run of wire from the panel to the avionics bay. Installation times and costs for additional remote avionics would be dramatically reduced. Volume and complexity of wiring would be dramatically reduced. WEIGHT of wiring would be dramatically reduced. It's amazing that they haven't done this ages ago. Inter-company device communications aren't generally a problem either. I know people think of their car as being made by, say, BMW or Mercedes, but both those manufacturers source lots of electronics from suppliers. You may have a Garett variable geometry turbo, a Bosch fuel injection system, and a Borg Warner transmission, all in the same Mercedes, all talking to each other.
I agree with your genreally slower statement, but think about what you actually send across the wire in these applications. It's short telegrams of very specific data. For example the basic ADS-B message your plane broadcasts, assuming you're 2020 compliant,is only 112bits. (https://mode-s.org/decode/adsb/introduction.html in case you're interested) That's not a typo, it's bits not bytes. That's only 14 bytes or .013kb, or 0.000013MB and that contains your ID, surface position, airborne position with baro alt, airborn velocity, airbone position with gnss height, and a few other pieces of info.You don't need blazing speeds for that kind of transmission. You're not sending video and pictures in these cases. You just needit to be robust and reliable.And the slower you go, the less opportunity there is for error in encoding or decoding.
Fun fact, we may all complain about the range of of our wifi, but did you know they were able to communicate all the way across the continent of Austrailia with 802.11b wifi? They were able to do this becuase of the speed degrades in wifi allow B wifi to downgrade all the way to 1MB which allows for up to 180 degrees of error to be injected and the signal still successfully decoded. To go faster, we have to define more data points on the carrier wave which means less room for error. To go even faster, we have to use mulitple modulation methods, which puts the data points even closer still and even less room for error.
Your point about TCP vs. UDP is where I was going with the industiral automation statement. We may use IP based systems for automation, but there is no TCP to be found(except for non-I/O related tasks). There isn't even UDP. They are all propritary standards. For example Allen Bradley uses EthernetIP, Siemens uses Profinet, and inside a Kuka cabinet, they use EtherCat. You can typically get any standard with any manufacturer, but these are the 'native' standards. All of these define their own special Transport layer specs. And you have to pay a liscense fee for every device that communicates using that protocol. Technology aside, I would think this alone could cause problems with certification. Who would pay to get the FAA to cerfity a protocol? I certainly wouldn't since it means if I do someone could buy my competitor's product since it would work with my other product. And I doubt the FAA is going to take the initiative to specify a certified standard either.That seems like it would open a whole new can of worms too. I assume that is how it would work. I'm not sure how exactly you go about certifying software.
Just my thoughts. Geeking out on this a little bit. 
1
- Quote
