What are the limitations of USB in aerospace (especially microsatellites)?

Question

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.

Answer 1

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!

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.