Embedded systems that can be sustained up to 60 years | Hacker News Reader

Embedded systems that can be sustained up to 60 years

cip-project.org

67 pointssmartmic21 comments

Great idea, especially for critical infrastructure. This makes sense and would seem to have big advantages over closed source systems.

That's a tough order. The closest I've seen is a 25 year old AS/400 working in the corner.

Mainly been IBM mainframes, AS/400's, VMS clusters, and NonStop systems hitting the multi-decade mark. It could be done for embedded using similar technologies on a smaller scale. Some even have things like lock-step. I've always considered knocking off a fraction of the original NonStop architecture for some embedded chips and boards to get five 9's on the cheap.

One bit of inspiration is Galileo mission running 13 years using its 6 1802's with redundant boards. That ended prematurely due to mission saturating it with radiation & slamming it into a planet. A similar setup fabbed on older nodes for their extra reliability might be able to last decades.

https://en.wikipedia.org/wiki/Galileo_(spacecraft)#Command_a...

https://en.wikipedia.org/wiki/RCA_1802

Of course, this link is talking about supporting the software and such. The hardware itself might not need to last several decades. It might be enough to simply design the HW architecture to be portable to whatever process node, link into a cluster, and take over for faulty hardware. In other words, standardize the interface on the HW and then the software. The hardware developers could then keep making the replacements on cheapest processes. However, I'd still recommend older, mature, simple nodes if it's safety-critical because the extra safety can only help & they can often forgo 1+GHz processors anyway.

Btw, what you think of a micro version of NonStop's HW/SW on inexpensive, embedded boards?

Aircraft embedded systems have very long lifetimes. I heard a story from one of the Cal Berkeley EE/CS faculty about how Boeing and Airbus stockpile microprocessors for critical systems on major aircraft programs so that they can continue to deliver without redoing FAA certifications for decades. I believe they even store them in super-cooled environments to keep the hardware from degrading. (Sorry no source but it was a very interesting talk.)

A former employer did something similar, for complete motherboards and a few things like power supplies.

Apparently this a common practice, then. In the aviation case the problem seems to be that critical avionics components like fly-by-wire control systems are real-time systems in which correct behavior depends not only on hardware interfaces but also temporal properties like response time. Upgrading to new hardware would potentially break the software in difficult-to-predict ways.

For other spacecraft, the Voyagers will hit 40 years this year. There are computers on them. If I remember correctly, they even updated software mid-mission to switch the forward error correction to Reed-Solomon for the later planet encounters.

I think that's a great idea. Those systems are super resilient and just keep trucking.

There are lots of building and HVAC systems with uptimes in the decades.

'Course, they're not running Linux.

I wonder how long some microcontrollers have been running in cars.

The design spec for the Ford EEC IV, circa 1985, was 30 years. I still have a working Ford Bronco with one, still using the original electronics. The program was on the IC chip itself, a custom Intel 8061 with mask-programmed ROM. The program was fixed for the life of the device.

It's also quite common that OEMs hold spare parts available for around 25-30 years. Which partly means the suppliers of these parts and also the µC manufacturers have to held spare parts available for a long timeframe.

However these spare parts usually don't come with updated or even maintained software. The lifecycle for SW currently is: Car is developed (3-4 years), then car enters the market and some minor updates/bugfixes are added (probably also for 3 years) and then nobody touches anything anymore. That worked out reasonably well for the last gen. However things will get very interesting for the current and next generation of vehicles with lots of connected features - and also driver assistance features which rely on connectivity. If the same model is applied here unlucky customers could be unable to use lots of features after only a fraction of the cars total lifetime. And of course they could be driving around with security holes.

Many original mid-80s units are still in use. What kills them is leaking capacitors that damage the board.

The design spec was final well before 1985. 1985 would have been considered "support and maintenance". Cars started getting EEC-IV in '81 IIRC and the form factor was revised soon after.

The system would have continued to have been used on new vehicles well past 1996 but it didn't have enough I/O pins to deal with all the things required for OBD2 compliance, thanks Commiefornia.

I read the link, but it's not clear whether 'sustained' means the code will be managed by an organization so that bugs and security issues can be fixed, compiled and downloaded, or, that the code actually runs uninterrupted for 60 (up to) years.

The latter is much more interesting to me.

It's the former. You'd be insane to design critical infrastructure under the assumption that a single machine is going to stay up nonstop for 60 years.

>You'd be insane to design critical infrastructure under the assumption that a single machine is going to stay up nonstop for 60 years.

With a definition of machine that's slightly more broad than "single desktop box or server" then I think 60yr is a pretty reasonable uptime goal. Something with redundancy and hot swap capabilities should have no problem getting several decade uptime. These are embedded devices, it's not like a nuclear reactor needs to reboot frequently.

Of course you could design a machine that can run for 60 years. It's just a bad idea to depend on it.

A nuclear reactor has regulatory oversight and a risk management plan. It must survive the failure of any single component, no matter its reliability target.

Over 60 years, those 'highly unlikely' threats -- earthquake, terrorist attack, military action -- they become 'kinda probable'. No single component can survive these, and you'd be foolish to try.

PDP-11's are still powering nuclear reactors to this day - a few years back GE were looking for programmers to keep them going (interesting to me, since I programmed them in octal and Macro-11 back in the early 80's).

http://www.theregister.co.uk/2013/06/19/nuke_plants_to_keep_...

I suspect my citizen solar digital watch I got in 1989 will still be "ticking" long after I'm gone. Likewise several of the PLC's I know have been up for 20+ years

I agree it's not clear but my money is on the intended meaning being the former, despite the intellectually greater interest in the latter!

I would not use anything less than SeL4 for the latter. [Or something else as verified.]

Reply on news.ycombinator.com