EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: max_torque on March 19, 2022, 12:03:58 am
-
I have a (automotive) system that could have between 2 and 6 "slave" units, which are arranged in different locations on the vehicle, depending on the exact setup of the particular vehicle.
I need those units to be able to robustly communicate with a master control unit. So far, CAN is the selected transport medium.
However, the physcial location of the units, and the requirement to be failure tollerant is driving a Star topology, which is of course not actually supported by CAN :phew:
So, i'm after ideas how to solve this problem, so far i have
1) Run two seperate parallel buses in a psuedo star layout, ie the bus is actually linear, but looks star shaped physically.
This is done with an IN and OUT type arrangement, so each slave unit is actually just a short stub on the bus. The advantage is two CAN busses is no problem (plenty of controllers with dual CAN) the downside is that this system, even with two seperate buses will not be as failure tollerant because those buses are in phsical close proximity to each other, so any physicaldistruption to one bus is actually very likely to kill the other bus too. This could be mitigated to some degree with using physically seperate connectors and harnesses for each bus, but that adds cost and complexity, and in the worse case (large high energy impact) this isn't going to be enough to prevent both buses being degraded, and hence losing COMS to any downstream slave unit.
2) Run multiple Point-to-point buses, using some sort of "multiplexer" device up by the master controller
This would use one transceiver+terminator for each bus at the master end, and either use logic hardware "ORing" or i guess a uC or FPGA could do the same trick. Personally, i would like a "non software" solution that can be proven and then left alone, ie not require EOL programming etc. thought would be required, and testing to understand the latency and exact "ORing" architecture - any device that transmits in any "direction" (obs a single CAN bus is techincally multi-directional at all times) would need to appear on all buses simultaneously to ensure the arbitration and sequencing inherent in CAN was maintained
3) Splash out on some super fancy master controller with 6 or perhaps even 12 seperate buses (dual buses are quite likely still to be needed to each slave node to cope with failure modes and ISO 26262 compliance.)
What would EEVBlog do? That is the question?
(bandwidth requirements are reasonably small, i don't yet have a figure for what each slave needs to exchange with the master, but i would expect a BUS at 500kbs to easily cope with 6 slave units)
Perhaps CAN isn't the answer? Perhaps a "Homebrew" protocol where the master controls the bus completely, ie no broadcast by the slaves unless asked using CAN h/w or RS-485 is the answer? CAN however has a massive advantage in the automotive world by being very standard and understood, whereas other solutions, despite havign technical merit would certainly be frowned upon.......
-
I saw a youtube repair video on a mercedes car which implemented what you are suggesting. About 8 of the CAN bus devices were plugged into a single box located in the cabin. The repairman was trying to isolate a fault on the CAN bus, and was able to unplug each device from this common box until the fault disappeared. He was very grateful for this feature. Looked like a great idea.
-
Took a while but I found the link to the video: https://www.youtube.com/watch?v=Kg-05nOfBqU (https://www.youtube.com/watch?v=Kg-05nOfBqU)
-
Sorry, I misunderstood the requirements, you are not after multiple devices sharing a single parallel bus, but each device on its own bus to avoid one device failure bringing down the entire bus. I have also seen in repair videos, a gateway unit, which splits a single CAN bus into multiple buses.
-
Neat overview of CAN topologies:
http://www.mindsensors.com/content/86-can-and-its-topology (http://www.mindsensors.com/content/86-can-and-its-topology)
Since you mentioned a star topology I assume graceful degradation suffices? In that case, yes, some central switch or hub seems to be the way to go. I think you would have to implement it though, I could find some ready products marketed as CAN hub, but no CAN hub IC...
Now, if complete fault tolerance is needed, I think the double ring is the only option.
Now for fancy stuff. Ever considered using Ethernet? Specifically 100BASE-T1 (AKA SPE or Single Pair Ethernet). This is coming strong for automotive applications, with many new automotive graded ICs coming out. The star topology is natural with a switch. For true fault tolerance maybe even mesh? The only problem is that it's so hot now that everything is sold out to the big guys. But then again, can we buy any ICs at all right now?
-
This article investigates the various CAN gateway topologies and their strength and weaknesses: https://www.can-cia.org/fileadmin/resources/documents/proceedings/2005_taube.pdf (https://www.can-cia.org/fileadmin/resources/documents/proceedings/2005_taube.pdf)
-
And, just for completeness, the easy [non-]solutions are out?
1. Comms are a secondary system e.g. entertainment/accessory, failure in a crash is fine (the non-solution).
2. Just turn down baud rate so a star topology can be wired directly. CAN is quite tolerant of signal quality, and car-sized stubs on the bus are acceptable at a low enough rate (<5Mbaud?).
I'm guessing from the description, this is a critical enough system that it needs to remain operational through a crash, so (1) is out. Unless I've slipped a decimal mentally, (2) seems feasible though?
Note that, a physical star bus is still vulnerable to short circuits. So there's that. The stub effects at least, can be mitigated by using resistive splitters at the node(s): basically, for a collection of N transmission lines joined in parallel, the N-1 of them acts like a low source impedance for remaining one, thus that TL will see substantial reflections from the node, and this reflection can be absorbed with a source termination resistance at the node. And by symmetry, the same is true of all TLs joined to the node. So, any node with N >= 3 sub-buses joining, should have Zo/N series resistance from the common mode to each TL. (Or since this is balanced, Zo/(2N) in each line.) Note this attenuates all frequencies, which might be a concern for range. It can be done at high frequencies only (with an R||L network, or suitably chosen ferrite bead, for the loss elements at the node), which trades low LF loss for increased HF loss. Now, I started this paragraph about vulnerability to shorts, then discussed reflections; the connection is this: note that with resistors at the star node, one line becoming shorted will increase bus attenuation and cause some additional reflection on the remaining buses; but it's not a complete loss, some signal remains. If that signal level is still adequate for communication -- there you have it -- the strategy has improved both signal quality and reliability. So this might be an option.
Tim
-
Why do you feel the need to use more physical redundancy than passenger safety systems on cars?
As long as you can detect faults and act appropriately, is not like the car is going to fall out of the sky like an airplane where they do use multiple physically separated systems for redundancy.
-
Take a look here:
http://srv.uib.es/pub/838.pdf (http://srv.uib.es/pub/838.pdf)
-
A simple possible topology is to use 3 iMXRT1020's, they each have two CAN buses. Two of the processors (slaves) could connect to the master processor via dedicated UART ports, they have eight each, the slaves can filter the info and communicate what is necessary to the master. This gives a total of six independent CAN buses.
-
The linear (but star shaped) networks is how cars do it when they need to.
CAN-FT was designed specifically for what you're looking, it can tolerate single faults such as short to VCC, short to GND etc, and automatically switches to single ended mode. The termination is distributed across the nodes. It's very limited in speed though.
But honestly, unless you're building a plane, even that might be over-doing it. 2 normal CANs on separate connectors would be more than enough in most cases, and much easier than implementing a gateway.
-
I just realized CAN-FT doesn't return much search results. What I meant is TJA1055 and similar FT transceivers that handle it at the physical level, you can interface that with any normal CAN periphery given speed limitations. I've seen it used like once in a vehicle bus for seat controllers out of all things (probably because some other OEM had a FT bus they wanted to use it on and it was re-used).
-
I can't actually tell you what the application is, but it's not a passenger car and it's large enough to have significant CAN bus lengths (>15m) which makes a fake star topology out of the question.
It also is more safety critical than a passenger car, so we are looking for proper redundancy and graceful degredation and failure (and to meet ISO 26262).
I think i may prototype a hardware solution to OR'ing muliple buses from a master, and see what performance i can get with that....
-
If you don't need multi-master or arbitration CAN doesn't offer much over vanilla RS485 or other homebrew solutions. You can even look at the ARINC family of old-school avionics buses, most of which are a "one-to-many" topology, much like RS485. Good luck finding hardware for those though.
I would assume this is some sort of time-triggered system where simplicity of RS485-like buses (UART at the MCU level) might be advantageous and win over CAN.
-
If you don't need multi-master or arbitration CAN doesn't offer much over vanilla RS485 or other homebrew solutions. You can even look at the ARINC family of old-school avionics buses, most of which are a "one-to-many" topology, much like RS485. Good luck finding hardware for those though.
I would assume this is some sort of time-triggered system where simplicity of RS485-like buses (UART at the MCU level) might be advantageous and win over CAN.
Sounds like a good idea, you only need one iMXRT1020, as it has 8 UARTs.
-
If you don't need multi-master or arbitration CAN doesn't offer much over vanilla RS485 or other homebrew solutions. You can even look at the ARINC family of old-school avionics buses, most of which are a "one-to-many" topology, much like RS485. Good luck finding hardware for those though.
I would assume this is some sort of time-triggered system where simplicity of RS485-like buses (UART at the MCU level) might be advantageous and win over CAN.
RS485 and CAN is almost the same physical layer, afaiu the first CAN transceivers were actually repurposed RS485 transceivers
and rs485 is also supposed to be a single bus terminated at each end
-
It's not exactly what you're asking for, but it may be useful to know about CAN repeaters/bus bridges. These let you send signals between two otherwise electrically distinct bus branches, and are how you split up bus loads or have two galvanically isolated segments of a single bus.
TI has a design, TIDA-01487: https://www.ti.com/tool/TIDA-01487 (https://www.ti.com/tool/TIDA-01487)
The idea and architecture there is fine, but the implementation of the core arbitrator is appallingly bad. (Student-level bad.) It's just a flip-flop, you can do it in a handful of gates, not the bloated mess they have. And it works really well!
-
If you don't need multi-master or arbitration CAN doesn't offer much over vanilla RS485 or other homebrew solutions. You can even look at the ARINC family of old-school avionics buses, most of which are a "one-to-many" topology, much like RS485. Good luck finding hardware for those though.
I would assume this is some sort of time-triggered system where simplicity of RS485-like buses (UART at the MCU level) might be advantageous and win over CAN.
Sounds like a good idea, you only need one iMXRT1020, as it has 8 UARTs.
OP is talking about ISO26262 and higher levels of assurance than automotive (let's say > ASIL D). No way in hell OP would achieve that with a single MCU design, even if it was some magical auto-qualified lockstep voodoo thing, let along a normal commercial unit.
The FMEAs would be huge, and triplication with common failure modes accounted for would be standard. This may even need some form of mechanical/hardware voting logic. In things like airbag controllers a lot of it is achieved using special ASICs not because volumes require custom silicon, but because it might be the only way to achieve it safely.
-
As far as I understood the issue, it was a matter of a single remote device bringing down a shared bus, hence the emphasis on a star topology, not what was processing that bus, i.e. transceiver/wiring faults. I can understand that, as many car CAN faults are due to a single remote device bringing down the bus. If you want to talk about triple redundancy and voting systems as aircraft are supposed to have, I can do that as well, having worked on fighter aircraft for a number of years, but that is another issue. I've also learnt from experience that triple redundancy is a bit of a myth. Single points of failure still exist, like three hydraulic lines running to an actuator, but they run them all together, or three sets of cabling in the same conduit. The list goes on and on. Redundant sensors, but only two with the avionics giving preference to only one. etc. etc. etc.
Don't get me wrong I do believe in fail safe designs, that takes effort and time. :)
P.S. reliability is related to complexity, sometimes adding parts can make a design less reliable. What was that quote: "Use the minimum number of parts necessary for a design but no less." excuse the paraphrase.
-
You're right of course, if it's only a harness-level or slave issue, then getting one chip with enough UARTs (or whatever interface) a no-brainer. And I agree 100% that there are Jesus nuts holding everything together in all kinds of safety systems..
I was reading between the lines, and usually ISO26262 and/or ASIL D and such (since OP said "better than auto"), would require more thought than just the interface/harness level.
I do wonder what it is: 15m, star, modest amount of slaves, not multi-master.. Some sort of self-flying robo-taxi hexacopter contraption that's all the rage nowadays? Autonomous train?
-
He does mention "(automotive)", but apart from that, no idea.
-
Of some related relevance, perhaps; I've worked on a fire protection system, of automotive spec, but similar scale. So, mining and other heavy equipment, basically.
I don't recall that they were doing anything out of the ordinary, though -- raise an alert if any cables come loose, sound an alarm (trigger extinguishers, etc.) if a clear signal is had (from flame sensors, shorting fuse wires, etc.).
Forget if they had a CAN interface to that, either; there was RS-485 inside, but I think it was just between base unit and HMI. Fairly simple system, in any case, so maybe it's not all that applicable here anyway.
Tim
-
The slave devices are multiple to provide assured operation under significant duress, and unfortunately that duress can include the complete physical destruction of the slave, so that's why the data bus can't really "loop through" those slaves.....
-
It's not exactly what you're asking for, but it may be useful to know about CAN repeaters/bus bridges. These let you send signals between two otherwise electrically distinct bus branches, and are how you split up bus loads or have two galvanically isolated segments of a single bus.
TI has a design, TIDA-01487: https://www.ti.com/tool/TIDA-01487 (https://www.ti.com/tool/TIDA-01487)
The idea and architecture there is fine, but the implementation of the core arbitrator is appallingly bad. (Student-level bad.) It's just a flip-flop, you can do it in a handful of gates, not the bloated mess they have. And it works really well!
I'd be interested to hear more about a better arbitrator logic block! I'll have to sit down and read that document and get my head around the requirements!
-
Perhaps CAN isn't the answer? Perhaps a "Homebrew" protocol where the master controls the bus completely, ie no broadcast by the slaves unless asked using CAN h/w or RS-485 is the answer? CAN however has a massive advantage in the automotive world by being very standard and understood, whereas other solutions, despite havign technical merit would certainly be frowned upon.......
Single Pair Ethernet is gaining momentum in Automotive. Your choice might be 100Base-T1, which will sooner or later replace MOST or FlexRay just because of costs and use of standard protocols.
The center of the network is a 100Base-T1 switch, just like normal fast ethernet. Apart from the MII/RMII PHY transceivers everything else (controllers, TCP/IP stack, applications, protocols) is standard, there is no need to reinvent the wheel.
fchk
-
One thought, what is a dual out and back linear bus is routed in OPPOSITE directions through the slaves ie
BUS 1 goes
Master out -> Slave 1 in, Slave 1 out -> Slave 2 in, Slave 2 Out -> Master In
And BUS 2 goes
Master out -> Slave 2 in, Slave 2 out -> Slave 1 in, Slave 1 out -> Master In
This means a double bus failure, which is most likely to occur at a single slave unit or point in the harness between the slaves means the buses can still communicate to all slaves with data travelling in via the opposite directions?
Termination would have to be robust to this failure, so perhaps distributed termination will have to be used?