HACKER Q&A
📣 disqard

Tech to build a self-contained appliance that lasts 20 years


Hi HN folks,

What, in your opinion, would be a good hw+sw platform to build an appliance (offline, not cloud-connected in any way) that could conceivably keep working for another ~20 years?

For context, I used to live near a drawbridge, and its motion was controlled for 30+ years by a DOS-based computer (https://www.seattletimes.com/seattle-news/seattles-university-bridge-undergoing-a-reboot).

I'm sure there are very knowledgeable folks here, who might have built such long-lived systems, and I'd love to hear about platforms that are (relatively) future-proof.

Thanks!


  👤 bombcar Accepted Answer ✓
Well, you could build them the way they built those space probes, as they're still out there squeaking back to us.

Much of it is going to depend on the problem definition; for example, it is moderately hard to build a simple door that will work for 20 years with no maintenance at all. It is certainly possible but it's not a given, and even if the door is perfect the building may shift around it.

Software wise you're probably going to want something running on C on chips that are easily replaceable; but the real trick is to remove software entirely and just run with analog or direct ICs. Again, depends on what you want it to do.

Cars get moderately close for a surprisingly complex piece of equipment, if you allow maintenance.


👤 koz1000
One embedded platform I worked on was developed in the late 80s, launched in 1990, and code I wrote in 1994 is still running. It's a 6809 processor with a little bit of RAM and 512KB of EEPROM attached. The entire code base is pure assembly language. That doesn't mean it doesn't have bugs, it just means no stdlibs to lean on.

The key isn't the longevity of the CPU, it's whatever is attached to it. Input and output stages fail, power supplies spike, things burn out, things wear out. So the processor can keep going strong...but what are you controlling?

But TDLR the answer is use the oldest sustainable tech you can find. Think like Gunpei Yokoi and build a Gameboy, not a Steam Deck.


👤 iancmceachern
PC104, it's everywhere used in exactly these kinds of applications

https://en.m.wikipedia.org/wiki/PC/104


👤 chunkles
The satellite industry uses hardware equipment that has been around for a long so that all known issues are worked out and they can have an idea of lifespan because cost of replacement is astronomical. There are a few places online that talk about the processors and boards used in that industry. Might be an interesting place to start.

👤 eternityforest
I have not worked in tech long enough to see a microcontroller fail(Except in cases like dumping 5v into a 3.3v chip, and even then, most of the time it keeps working).

I have almost no doubt that even a cheap consumer chip will keep running up to and beyond whatever it's flash retention time is.

20 years is not that long. I would guess that quite a few consumer appliances made now will work by then.

Being able to totally guarantee it will work then is another matter.

Things I do see break, sometimes as a bear guarantee within a year kind of thing:

* Power conversion. Some modules more than others. I don't see the ones with rated MTBFs fail before their time much, but cheap stuff fails all the time.

* Switches. I no longer trust any mechanical switch that doesn't cost way more than it should. For some reason, switches seem to hate being held in the pressed position long term. However, cherry MX and all the clones are fine, and even if they weren't they're swappable. I wish people would use them instead of microswitches more...

* Connectors. I don't see a lot of USB-C and 2.1mm barrel jack failures. XLR seems mostly OK. Everything else common fails proportionally to how cheap it is, except microUSB, which is a complete dumpster fire. Therefore, I try to use USB-C and 2.1mm a lot.

* Power Switching. I don't actually see this as much as I expect. I'm not sure I've ever actually seen a mechanical relay fail even though it's very much a thing that can happen. But it's still something I watch out for.

* Marginal stuff that was out of spec to begin with but just now randomly decided to stop working.

Ran I2C over long wires? Yeah you're not really supposed to. It will work for now. It might stop working. It might not start working again. I probably won't be able to figure out what changed in less than several days. Probably something about interference or a wire scooted an inch or the weather changed and that made voltage thresholds different.

Therefore, I pay more attention to what the datasheet says than personal experience. I don't care what works right now, I care what they specified to work in all conditions.

* Rotary encoders. These are like switches but they switch even more so they break even more.

* Mechanical stuff. I trust a chip a lot more than a mechanical part. There are just so many more interactions, thermal, vibration, wear, etc. It can be incredibly reliable or it can be total crap. Nylon gears can get randomly brittle. Screws can strip.

If you want to do mechanical stuff at all, you should find a copy of Exact Constraint by Douglas Blanding. Or not, it's expensive, but at least read the Hackaday article. I have very little spatial intelligence and can still get by when needed, mostly thanks to this one idea.

* Sheet metal. This one is mostly only relevant during maintenance and is more of a personal pet peeve.... But this stuff can take on a permanent bend rather easily. It always seems to be just a little out of alignment when you take it apart and replace it.

Basically, if it gets hot or moves, it's gonna break. If it's unique and interesting only time can tell if it lasts 100 years or 10 hours. Pay attention to all the failures you see in everyday life. Those are probably the same modes you need to watch out for.

Unfortunately, this causes a lot of conflict, because I'm constantly pushing for less and less interesting stuff with no personality or innovation anywhere on it, which seems to make the more idea driven engineers rather bored.

There's a whole bunch of other soft failure modes that can be resolved by cleaning a sensor window or rebooting too, but as I don't work in life safety stuff, I often ignore them. Usually the fix for them would either cost money or it would introduce a hard failure mode.

This also causes conflict, because people remember soft failures once a month and think the thing is unreliable, even if it's just a few seconds inconvenience, when really the soft failures could be a safety shutdown because you pushed too hard on a drill.

People might perceive an old thing that will happily strip its own gears as being more reliable than something that occasionally shuts off if it detects a little too much pressure.

There's also lots of network related stuff that you don't have to worry about in this case.

And of course, computer hardware failure issues. Not relevant if you don't need a full computer.

If you need UI, try to keep it separate. Use a computer for that, but communicate over a really simple serial protocol, so that the UI could be reimplemented if needed, and don't use any weird stuff in the software.

Sometimes I've wondered about using an old game console emulator as an embedded UI, because those are likely to be around indefinitely and follow the same spec, and not much else has that kind of staying power. That's of course, totally nuts, but the fact I thought of it shows how insane things are getting with programmers making breaking changes all the time.