Analog Electronics vs Microcontroller Reliability

[Pentoad]

Given two systems designed to do the exact same task, which one would be more reliable and robust? The one designed around an MCU or one designed entirely using analog and logic electronics? I know that microcontrollers can occasionally crash for no obvious reason while analog electronics usually need to suffer some form of physical damage or wear out due to old age in order to fail.

[MadTux]

No idea what lasts longer.

But if you have to repair it, a device made from  opamps and 74xx/4000 logic is way ahead in repairability  than some similar device where the microcontroller/PAL/GAL/CPLD/FPGA... has crapped out and you can't get the binary/source code to program a new one.

[Kleinstein]

With analog solution it really depends how it is build. Analog parts are effected by drifting parts - how much this effects an analog circuit really depends on the circuit. Some are OK with 10% resistor drift while other more critical ones may need 0.1% stability. The parts chosen also have an effect. E.g. carbon film resistors are known to drift up.

The single 74xx logic chip is quite reliable, though some (especially the older ones) could still also show aging or failure from radiation induced latch-up.  However a complex job may need a large number of chips and than there is a turn over that an FPGA or µC will be more reliable.
Many µCs have things like a watch-dog, so in principle they can recover from random crashes, though with some hick-up.
There are also quite different µCs and ways to run them. The logic chips also come in different grades / families and cases. It's also not just the chips but also the soldering and caps.

[German_EE]

I guess that an analog circuit would be the most reliable. With analog all that can go wrong is the hardware, if you have a microcontroller based solution then you need reliable software as well that can cope with any eventuality.

A good example. I used to work in the elevator industry where if things go wrong people could get hurt. We came out with our first elevator car panel that used a CPU rather than relay logic and it was presented to the company chairman and the board. The first thing the chairman did was press down on the panel with the palms of his hands so that multiple random buttons were pressed at once, there was a single beep and the panel crashed so badly it needed a power on reset. PCB revision 2 worked better 

[Kleinstein]

It really depends on the problem:
A an analog solution that needs very long time constants and thus very low leakage can be quite tricky, even if well build. There are also functions that are not easy to do analog, like nonlinear things or memories. A simple PID regulator with short time constants is easy to do analog. It gets tricky if time constants are in the hours and nasty if accurate anti windup and changing parameters are needed or if auto-tune is wanted.

A TLL solution with a hand full of chips is OK - however if it goes to the hundreds, or thousands I would prefer a software solution. Complex logic can also have nasty hidden bugs, not just complex software. Testing software can be easier, especially for large quantities.

[Pentoad]

I've always had the idea of creating an AC motor controller for electric vehicles without using any MCU but I don't think such a thing is possible. That would require me to set up three sinewaves and lock them 120 degrees out of phase from each other and then figure out hall sensor feedback. I think such things are totally out of the realm of analog electronics only systems.

[Kleinstein]

In times before digital electronic and µCs were available there where quite intriguing analog solutions:

I remember a mechanical testing machine from the 1940s, that used tube amplifiers and magnetic amplifiers to control a servo motor to get wide range variable speed drive from a 3 phase motor. It was later modified to use a computer to set the speed and control, but still keeping much of the old system and power amplifier. It is a bit complicated, but not impossible to have analog control of a brush-less motor.

[DannyTheGhost]

At first glance, software-based systems are more prone to different bugs
But any single-chip solution is much more preferred because there is much less parasitic effects, starting from parasitic L and C in long wires and conductors and ending with no worries about same temperature over all PCB.
There are still some cases when you should worry about it all even in this case, but software bugs are easier to predict and avoid than complex EM-compatibility issues
And, of course, it is much, MUCH cheaper to develop uC and FPGA systems on 1x board space, when you would need 10x+ board space for equivalent discrete logic/analog system

[iMo]

Another analog system broadly used (from 40ties)
https://www.cdvandt.org/Hoelzer%20V4.pdf

[james_s]

I don't think there is any significant difference in reliability of one tech over the other, there are far bigger variables relating to how well designed the system is, quality of parts used, quality of construction, external factors, etc. Analog and digital (software) each have their own unique set of pitfalls and bugs. Each is capable of getting into undefined states or reacting in unpredictable ways to unforseen conditions.

[schmitt trigger]

The CDP1802 microprocessor has been used in several deep space missions.

Although the longest and farthest missions, the Voyager twins, used custom-built computers built from CMOS and TTL medium scale integrated circuits and discrete components. 

In the end, overall reliability is a question of a sound design and flawless execution.

This is more a reflection of a team with technical experience and organizational excellence, in my opinion.

[VK3DRB]

The CDP1802 microprocessor has been used in several deep space missions.

Although the longest and farthest missions, the Voyager twins, used custom-built computers built from CMOS and TTL medium scale integrated circuits and discrete components. 

In the end, overall reliability is a question of a sound design and flawless execution.

This is more a reflection of a team with technical experience and organizational excellence, in my opinion.

Exactly. A microcontroller is extremely robust providing the firmware and hardware developers understand it properly (and they have read the errata!). Most issues with microcontrollers occur due to firmware problems. If you want robustness, use an external independent watchdog timer, have clean power rails and make sure your I/O is handled correctly in firmware and hardware.

That being said, things can go wrong which is beyond the control of the developer. I designed and built the VK3RCW Interractive Morse Code Beacon that is a mixture of analogue and an ATmega128 microcontoller. This thing has been generating Morse code and handling a complicated state machine with speech generation for 10 years continuously on 145.650MHz, with a power output of 50W FM covering all of Melbourne and beyond. The design is rock solid, having been test thoroughly before being installed on the tower of a government facility. I used a simple quad op-amp as the sine wave generator. Much easier and quicker than doing the sine wave generation in the micro, although there is a ladder logic for ramp up / ramp down each dit and dah to prevent key clicks. The sine waves are quite pure. The DTMF decoding and other functions work fine, except there is on board a voice menu system that uses an addressable ISD voice recorder chip and when the voice of Jane reads out one part of a sub-menu, there is a small glitch in her speech I can detect. The glitch appeared about 6 years ago. Not a big issue and most people would not detect it. If the ISD chip eventually fails, I can replace it as I have still voice files. Or replace the whole system with a Raspberry Pi with more sensors connected and more features. But who listens to Morse code anymore.

[amyk]

I've always had the idea of creating an AC motor controller for electric vehicles without using any MCU but I don't think such a thing is possible. That would require me to set up three sinewaves and lock them 120 degrees out of phase from each other and then figure out hall sensor feedback. I think such things are totally out of the realm of analog electronics only systems.

You might want to look at old (as in 1900s to 1940s) books --- they certainly had ways to do it back then.

[David Hess]

I've always had the idea of creating an AC motor controller for electric vehicles without using any MCU but I don't think such a thing is possible. That would require me to set up three sinewaves and lock them 120 degrees out of phase from each other and then figure out hall sensor feedback. I think such things are totally out of the realm of analog electronics only systems.

I am a little fuzzy on the details of AC vector drive but I know it has been done using either discrete logic or analog plus some discrete logic.

[NiHaoMike]

It's surprisingly easy to build the control logic for an AC motor drive on a FPGA. (It doesn't take that much logic area - even a Tesla inverter uses a fairly small Actel.) It follows that if it could be done on a FPGA, it can also be done with discrete logic.

[GlennSprigg]

Most people here would understand that older 'analog' meters/multi-meters work better, when
subjected to stray electro magnetic fields in the immediate vicinity. Either due to the 'lag' of the
needle due to quick transient spikes, or due to the generally lower 'Ohms-Per-Volt' compared to
more sensitive 'instruments'. Although older analog devices can be such that the meter itself affects
the electronic circuit loading etc.!

Sometimes, modern electronic systems can be 'too' sensitive. I've personally witnessed a Control-
Room full of digital displays, suddenly start having all their digital read-outs going berserk, when
someone in the control room pressed the 'Transmit' button on a Walkie-Talkie !! 

[mpgmike]

Retired race car driver Jimmy Johnson took a retired race car & installed a '90s era video game in it as a simulation race car.  He takes it around to events & charges folks to drive it.  I worked with him in Daytona, 2019 where his old stuff started breaking.  While "under the hood", I was amazed at how many chips were used between logic and memory; a stack of 8 rather large PCB boards!

However, I must say his issues weren't related to the core circuitry, but connections and the like.  In other words, the analog electronics were reliable.  That 8 board stack could easily be replaced with a single board about 1/100 the real estate using modern electronics.  Obviously the modern replacement would cost about 1/1000 the money to build.

[Red Squirrel]

I'd lean towards analog, especially if it's using high quality parts.   But even if something does fail it's more repairable so it's more reliable in that sense, that it's more long term supportable. 

We have an operator intercept box at work (the machine that generates phone messages like "The number you are calling has changed, the new number is...") and it's been around for longer than I've been alive and is fully analog as far as I can tell by what I see when I look at it.  It has huge cards and it's all through hole basic parts.  Nobody actually knows how long it's been working for. I bet it was around when the stepper switch was active.   

[hans]

“Hardware eventually fails. Software eventually works.” – Michael Hartung

Digital design is great at absorbing a lot of design complexity which becomes unfeasible (size, power, cost) to build in analog electronics. A part of that complexity can be to make products robust, like @German_EE mentioned about the elevator, which clearly had some work to do in that area . But it is also a source of problems because bug-free software does not exist.

Assuming infinite development resources have been put into firmware such that it "eventually works", you can look at the reliability of microcontroller chip itself. For example, the FLASH retention of an ATMEGA328P is rated (1ppm "data retention failure rate") at 20 years @ 85C and 100 years @ 100C. Is that a severe hardware limitation? Sure, there are software strategies to improve upon that retention failure rate. However, these software mitigations assume that the hardware is available (powered on) for the whole time.. what if it is an emergency device that remains unpowered for years? Then FLASH cells can theoretically still corrupt after many years, and failure may occur.

With that reasoning, if I would need to kit out a post apocalypse nuclear bunker with electronic equipment that needs to be pick up and go, I would be rather picky about what digital parts were used for these kind of tasks.

[nctnico]

The whole analog versus digital discussion is rather moot. Just pick the simplest (=least time to develop) solution. However a big trap is underestimating the time to develop software. The 'we can fix this in software' line of thinking without actually doing a system design for the software is a recipe for a dissaster. If something can be implemented in hardware then implement it in hardware even if it requires an hour of puzzling it together. It will take more time to develop the software.

[SiliconWizard]

Can't be answered without 1/ defining reliability and 2/ issuing a proper system analysis. There's no simple answer to this; too bad for those looking for quick recipes.

Generally speaking, the more hardware components a given system includes, the more hardware failure possibilities. Now replacing a lot of hardware with less hardware and more software can lower failure probability - but not necessarily. Complex ICs like MCUs can "fail" for many reasons as well (not just software-wise). And then there's the software... it's well known that unless your system is very simple, bug-less software is notoriously hard to get. Again, only a thorough analysis will tell whether probable software bugs can lead to worse failures than hardware failures you'd get if you just had more components in the system instead...

And for the last part nctnico mentioned, it's a very, ultra common trap. Yes hardware issues can be very costly to fix compared to software bugs, but the difference is often largely overestimated in practice  - meaning, the cost of software (developing AND fixing) is largely underestimated. Just because software looks easy to fix compared to hardware doesn't mean that it will cost less in the end. As to pure development, IME it's even often the exact opposite. Unless you're working on systems that have extremely simple software, or on systems that are particularly tricky hardware-wise, software will most often cost you a lot more engineering time than hardware, and in many cases (not all of course), engineering costs overweigh most other kinds of expenses on a given project...

[Zero999]

I guess that an analog circuit would be the most reliable. With analog all that can go wrong is the hardware, if you have a microcontroller based solution then you need reliable software as well that can cope with any eventuality.

A good example. I used to work in the elevator industry where if things go wrong people could get hurt. We came out with our first elevator car panel that used a CPU rather than relay logic and it was presented to the company chairman and the board. The first thing the chairman did was press down on the panel with the palms of his hands so that multiple random buttons were pressed at once, there was a single beep and the panel crashed so badly it needed a power on reset. PCB revision 2 worked better 

I don't know when this was but nowadays safety critical systems must meet certain performance levels and shall be deigned to fail safe. Poorly designed relay logic can fail dangerously and the relays themselves can fail closed due to arcing or mechanical vibration. Once correctly designed any built, a solid state design should be more resistant to vibration and will have unlimited switching cycles, unlike a relay based system.

As mentioned above watchdog timers can help to improve safety but there are other things which can help such as using more than one microcontroller which have to agree on a potentially dangerous operation, before the system will allow it to happen. Safety critical design is a big can of worms.

[schmitt trigger]

Safety critical design is a big can of worms.

Indeed!
Just look at the MCAS fiasco.

[German_EE]

The car panel I talked about was designed in the early 1980's and was finally released to manufacturing four years later after extensive testing. There are probably a few thousand of them still in use so they eventually got it right.

Depending on how you wire the ladder logic (and what the customer asks for) multiple simultaneous button pushes on a car panel will cause the car to stop on the next highest or lowest floor. Modern CPU based designs will almost certainly do nothing and wait for a valid input.

[james_s]

Safety critical design is a big can of worms.

Indeed!
Just look at the MCAS fiasco.

That one has me scratching my head, I mean it's almost like they didn't even try.

I worry that the Agile/Continuous Integration/<insert buzzword here> trend of move fast, break things and fix often is spreading like cancer and leaking into things that should never be designed with that philosophy. Anyone who learned to develop consumer electronics or mobile/desktop/web software is going to face a huge culture shock developing anything safety critical. I'm half expecting to hear a story any day now of someone dying because a defibrillator or dialysis machine had a forced software update and got stuck in a reboot loop.