3
\$\begingroup\$

I have just joined a startup company that builds microsatellites. But I am quite new to the aerospace field.

I noticed that to connect components with the onboard computer we use many electrical protocols such as SPI, I²C, RS-485, SpaceWire, etc., but never USB. I noticed this behavior in other companies too.

Is this impression of mine grounded? If so, is there any reason USB is not widely adopted in the space industry?

I heard (I don't remember where) that USB electrical design is kind of flawed. Is it true? If so, what are the flaws and limitations that make it unsuitable for aerospace applications?

PS: We do have a USB port on the onboard computer but is only used for debugging. In-flight it is disabled.

\$\endgroup\$
10
  • 5
    \$\begingroup\$ One major limitation may be the lack of hardware with flight heritage. Spacecraft electronics designs are usually very conservative. \$\endgroup\$ Nov 5, 2022 at 1:39
  • 1
    \$\begingroup\$ USB tends to get upset with transients causing disconnects and sometimes the devices locking up. For these reasons I can understand why you would avoid it in high reliability applications. \$\endgroup\$
    – Kartman
    Nov 5, 2022 at 2:14
  • 3
    \$\begingroup\$ Have you ever had to re-plug or re-power a USB device before? Such as your mouse on computer startup because it wasn't detected? You don't get to do that on a satellite. I've had stuff at work where nearby equipment can make the USB lock up and I have to unplug or re-power it to get it to work again. \$\endgroup\$
    – DKNguyen
    Nov 5, 2022 at 3:09
  • 6
    \$\begingroup\$ Surely your colleagues could answer this. \$\endgroup\$
    – Chu
    Nov 5, 2022 at 12:33
  • 9
    \$\begingroup\$ There is simply no advantage to using USB for connecting components. You don't use USB for the same reason you don't use Ethernet or any of another hundred standards that aren't for this type of interconnect. Welcome to the aerospace field, by the way! It's fun. Mostly. :-) \$\endgroup\$ Nov 5, 2022 at 13:57

5 Answers 5

17
\$\begingroup\$

Consider the target application for USB are broadly compatible consumer devices, on an electrical and application level, this is translated as basically two killer features

  1. Foolproof connector
  2. Universal, immediately usable software.

These are positive things, and the billions invested into USB has resulted in truly impressive performance.

However, for certain applications, you could recast these features negatively. It's a matter of perspective.

  1. Overengineered connector and electrical spec
  2. Heavy application stack

If I was to consider USB in a serious application that might mean

  1. USB over PCB or a custom front end, hardwired peripheral

  2. Stripped down stack and/or hardware level acceleration.

That is doable, but at this point you are investing resources adapting a custom solution that strips away the best features of USB. You are adding complexity and quickly losing access to off-the-shelf tools, stacks, and support. This is certainly not the end of the world, especially if it is mission-critical. However, a bespoke solution like this is more expensive to maintain and ultimately is likely not IP. This leads many to look for other solutions.

If you could identify the reason why you would consider USB for a potential peripheral, e.g., the speed of USB 3.0, or lack of alternate component, it might be easier to see where a different solution might be preferred.

All that being said, it is absolutely true that there are a lot of momentum and ingrained practices in these industries that can be hard to overcome. There is similar pushback to industrial Ethernet due to familiarity with CAN and traditional fieldbuses and added the complexity of 802.3. If you see something others don't, and you have confidence it meets the requirements, that's an opportunity!

\$\endgroup\$
4
  • \$\begingroup\$ I just read your answer after trying to mentally compose my own in my head. But you hit on enough points that I'm no longer caring. Good! +1. Perhaps the most important that came to my mind is the heavy application stack, as you write. The idea of writing a new stack is daunting. And the idea of using an existing stack used for commerce on ground is probably foolhardy at best. Worse, there are many time-critical processes which not only must happen predictably and robustly but must have little to no variation, as well. USB just doesn't fit well. \$\endgroup\$
    – jonk
    Nov 5, 2022 at 2:48
  • 3
    \$\begingroup\$ What is IP? Ingress protection? Intellectual property? What is meant by it? Not patentable? \$\endgroup\$ Nov 5, 2022 at 17:29
  • \$\begingroup\$ I've studied aerospace computer science and one time my professor talked about how he wanted to implement his own USB stack such that he could interface with some specialized measurement equipment. He gave up after a few months, as it proved too complex/unreliable. So the task seams highly non-trivial, as that same prof wrote his own bare-metal real-time operating systems that is currently controlling a dozen or so satellites in orbit \$\endgroup\$
    – Gnarflord
    Nov 6, 2022 at 13:06
  • 2
    \$\begingroup\$ I wonder why you didn't mention hotplugging as a USB killer feature? \$\endgroup\$
    – Bergi
    Nov 6, 2022 at 21:02
7
\$\begingroup\$

You are correct in your belief that USB has a huge electrical level design flaw - it uses a non-differential signal to terminate low and full speed packets, and to indicate a bus reset condition. In consumer products this is not such a problem because the bus operates in electromagnetically benign environments (i.e. surrounded by appliances that have all passed EMC standards), and on consumer products a bus reset is simply an inconvenience they may not even notice.

In industrial applications, this is a huge flaw compared to other busses such as CAN, Ethernet or RS485. It is entirely possible for a spurious EM source to renders a USB connection unusable (due to repeated resets and the time required to restart the bus) while an equivalent RS485 bus would be completely unperturbed.

However in space applications I would imagine the main disadvantage of USB is that you have to support the complex software stack that allows USB to support dynamic bus configurations, even though you don't actually need dynamic bus configuration. This is not a trivial thing to do and I'd imagine in almost all situations it's better to use a fixed bus configuration with something more robust like CAN and be done with it.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I'm pretty sure the superspeed lanes in USB 3.x are a true differential bus, but other features of USB 3.x (the software stack in particular) still make it unsuitable for space applications. There are simply better options. \$\endgroup\$
    – Hearth
    Nov 5, 2022 at 16:05
  • \$\begingroup\$ Superspeed-only is an option for devices. So that could work to avoid non-differential operation. That software stack, tho… PCIe would be easier. \$\endgroup\$ Nov 5, 2022 at 17:52
7
\$\begingroup\$

The huge advantages of the USB that made it a monopoly in a consumer market are not really useful in the embedded world.

  1. Universal physical connectors - I doubt you would connect and disconnect anything after the assembly stage.
  2. Here goes the hotplug capability as well (both at the hardware and the protocol level).
  3. Dynamic power delivery capabilities - wait, what? etc, etc...

All these things come at a price - in complexity, power draw, physical size and mass. USB means huge (compared to other connectivity options) software libraries with their own cans of requirements and bugs.

One would make a certain design compromise towards the price in a consumer or even an industrial product (e.g. using a cheap mass-produced USB camera), but in aerospace environment the component price is somewhat less of a constraint.

For similar reasons, one would almost never see USB connecting e.g. components inside a smartphone.

\$\endgroup\$
0
\$\begingroup\$

Perhaps a better way to assess this is to ask yourself "what does USB provide that the other interfaces don't that would be advantageous for my micro-sat application?"

I don't think you can go wrong with Spacewire for your command and control interface. Spacewire is usually implemented with LVDS. Also, a lot of bus providers are making Spacewire available on their vehicles.

'485 is just an electrical specification for a differential interface, and says nothing about protocol, message formats, etc. So you would have to define this part of the interface.

We've also used SPI and I2C to communicate with things like receivers that don't need a lot of data at a very fast rate. SPI & I2C are both relatively easy to implement in things like FPGAs, especially of you don't need to support everything in the specification. Call it SPI-Lite, or I2C-Lite if you will.

Nice part about using established COTS interfaces it's that's it's relatively cheap to put together a test set to control your unit.

\$\endgroup\$
4
  • 2
    \$\begingroup\$ This answer doesn't even mention USB, much less describe the problems with the use of USB in aerospace, and so does not address the question at all. \$\endgroup\$
    – cjs
    Nov 6, 2022 at 0:24
  • 1
    \$\begingroup\$ OP mentioned other electrical interfaces/protocols besides USB. I expanded on that just a bit mentioning that they are used in real life space applications. \$\endgroup\$
    – SteveSh
    Nov 6, 2022 at 1:33
  • \$\begingroup\$ Well, yes, he explained that they used all those to show that things somewhat similar to USB are used, but not USB itself, thus justifying the question of why USB is not used. \$\endgroup\$
    – cjs
    Nov 6, 2022 at 3:04
  • \$\begingroup\$ Maybe that question is never asked. Just because they already use the other protocols and it just works fine. \$\endgroup\$
    – RemyHx
    Nov 6, 2022 at 3:44
0
\$\begingroup\$

Developing hardware and software for aerospace is not at all like developing for consumer applications.

In general, every functional unit of code needs to be documented with high and low level requirements, and then a test spec that shows that those requirements have been met.

Open source stacks and so on are out. Operating systems and components such as drivers have to be accredited. Typically they are sourced from specialist companies that specialise in this field, and at many times the cost of a consumer product. (All that documentation and testing costs.)

Over and above this, there are layers of redundancy and safeguards for flight-critical functions - for instance, function A (say, a set of critical sensor indications) will be monitored by a completely separate sub-system, developed by an entirely separate manufacturer and development process. This is because - even with all these standards - errors and bugs still can creep in at the level of requirements gathering, or simply human error.

These are some of the reasons that getting on an aeroplane has been getting safer over many decades, and is generally safer than crossing the road.

With all this in mind, the industry is understandably conservative when it comes to all aspects of technology, from the interface connector to the OS core. It has certain OS's and comms protocols which have stood the test of time, and there is little reason to change them.

The times that I worked on USB, it struck me as one of the most impenetrable and hard to debug stacks I've seen. When it works it is fine, when it doesn't, it's a very specialist job to figure out why. In addition, standard connectors generally wouldn't meet aviation standards (by a country mile) and some aspects of the hardware interface are not differential (as pointed out above).

In essence, USB was developed as a "one size fits all, plug and play" interface that is "good enough" for domestic use. The benefits of standardisation and volume beat the technical shortcomings of the interface (over complexity for many purposes and lack of built in reliability).

The things that make it attractive for (say) a home headset make it absolutely unusable for one used by a pilot.

For the same reasons, you will not see peripherals on an aircraft communicating over BLE, to save cost.

\$\endgroup\$
3
  • 1
    \$\begingroup\$ Also you'll need things like MISRA C and DO-178 compliance. You can't take some commercial protocol stack found in a Happy Meal and plug it into a safety-related product. \$\endgroup\$
    – Lundin
    Nov 25, 2022 at 9:41
  • \$\begingroup\$ @Lundin, yes correct. \$\endgroup\$
    – danmcb
    Nov 25, 2022 at 9:42
  • \$\begingroup\$ and when a manufacturer manages to subvert the process, as in the case of Boeing a few years ago, it can end up costing them very dearly indeed. \$\endgroup\$
    – danmcb
    Nov 25, 2022 at 10:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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