8
\$\begingroup\$

Introduction

USB has been around for quite a long time now, used extensively even in the automotive, marine and space industries to some extent. However certain communication ways are more reliable than others in terms of:

  • Possibility of hot redundancy

  • Protection of the connected equipment against failures in other connections (surges, short circuits, misbehaviours [data, voltage levels, timing...]...) or in the hub/switch itself

  • Large mean time before failure ("freeze" or hardware failure)

Usually, the error rate is a bit less important as detection and correction (which may require retransmission) is handled by the protocol library/stack.

Question

I would like to know how reliable is a system based on a USB hub (say, 16 ports, be it daisy chained or not). What can commonly go wrong, and what could be done (protections/topologies...) to prevent single point failures from spreading (ideally I would just swap the faulty equipment and it would be ready to go).

Specific problem

For a specific piece of equipment at work I need to interface 16 devices to both a primary PC and a redundant PC (taking over if the other one crashes). 75% of the devices have both Ethernet and USB and 25% are only USB, and I'm wondering if I should simplify everything (which may increase reliability as well) by using USB alone or have both to maximise reliability. For USB, switching between the 2 computers would be done using a manual switch.

To illustrate, the hub I'm considering is this one, handling < 350W surges but doesn't seem isolated; I have the hunch they're overusing the term "industrial" so I may switch it for several daisy chained 7 ports. The connected equipment is a bunch of industrial PID temperature controllers, a UPS and a precision thermometer. However this question is more of a general one.

\$\endgroup\$
  • 2
    \$\begingroup\$ I'm not sure that I'd describe USB as "less complex" than Ethernet. True, TCP/IP is non-trivial, but have you ever looked into the details of USB? In any case, TCP/IP is an easy pick for failover. \$\endgroup\$ – markt Jan 29 '15 at 13:11
  • 3
    \$\begingroup\$ Ethernet is galvanically isolated, USB isn't. If you're worried about surges then USB is far more likely to propagate failures than Ethernet. \$\endgroup\$ – pjc50 Jan 29 '15 at 15:49
  • \$\begingroup\$ Thanks for your comments. The thing is, I simplified the problem saying all the devices were USB/Ethernet. In fact, 75% are both, and the remaining 25% are only USB (modified my question). I can have both networks/busses, but it needs to be justified. When they say that the hub is surge protected, does that mean it's isolated as well just like ethernet? \$\endgroup\$ – Mister Mystère Jan 29 '15 at 16:05
  • \$\begingroup\$ Use Ethernet USB hosts, for example this one to attach the 25% of USB devices to your network. \$\endgroup\$ – markt Jan 30 '15 at 0:00
  • \$\begingroup\$ I have already looked at network attached USB hubs, and I concluded that it was complexifying too much to the point where it becomes less reliable - if one computer crashes while connected to the hub, the other one can't get a hold of the unit. \$\endgroup\$ – Mister Mystère Jan 30 '15 at 1:26
1
\$\begingroup\$

You are correct in that surges are a concern for cascade failures; it is also true that USB is not galvanically isolated by default, and in fact is a pain in the rump to isolate due to its half-duplex, bidirectional, differential-but-not-always (blast the SE0!) nature. Thankfully, the good folks at Analog Devices stepped up and put together the ADuM4160 to take care of all of the truly hard parts of USB isolation -- while it only supports low or full speed operation, and cannot pass low/full speed negotiation signals, meaning it can't be built into a general purpose isolated USB "lump" without help, it is still the closest thing to a generic USB isolator available.

Assuming that a reliable 5V supply to the hubs is available, and preferably one 5V supply per hub (not hard!), I would split the hubs into 4 ports each and isolate the upstream port for each hub -- pick your favorite hub chipset here. Along with good per-port surge suppression, for which I'd specify a pair of Bourns TBU devices in series with D+/D- and a shunt low-capacitance, high-energy suppressor in addition to a MOV and TVSS clamp + current limiter or PPTC for Vbus and the obligatory TVSS/clamp network for D+/D-, this should limit the propagation of surges through the USB network.

\$\endgroup\$
  • \$\begingroup\$ Note the serious bandwidth restrictions, though. No 480Mbps mode with isolated USB unless you do something custom and fancy. \$\endgroup\$ – user2943160 Aug 20 '16 at 3:00
  • \$\begingroup\$ @user2943160 -- I already noted them here (480Mbps = high-speed mode, and the ADuM4160 only supports low-speed and full-speed). For the OP's devices though, the bandwidth situation is not critical whatsoever, and this should do him just fine. \$\endgroup\$ – ThreePhaseEel Aug 20 '16 at 3:01
0
\$\begingroup\$

I work in the I.T. dept at my workplace and many people at my workplace run several devices at once on a six port USB hub. I have never had any complaints or issues with them whether it be at home or among others people at my workplace. We can hot-swap any device on the hub with no problems. The one thing to consider though, is that bandwidth will be shared across all devices on a hub. This means that if you have two nice USB 3.0 (theoretically 5 Gbit/s) hard drives running on a hub transferring information to each other, they will only transfer at 2.5 Gbit/s each (under optimal theoretical conditions).

\$\endgroup\$
  • \$\begingroup\$ While the anecdotes are nice in an IT environment, it doesn't give a very technical foundation for the reliability of USB hubs. Can you expand your answer to better address the question? \$\endgroup\$ – user2943160 Aug 20 '16 at 2:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.