Analog Electronics vs Microcontroller Reliability - Page 1
Forum section: electronics / general

author: Pentoad
author_rank: Regular Contributor
timestamp: December 26, 2019, 05:39:39 pm
content: 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.

author: MadTux
author_rank: Frequent Contributor
timestamp: December 26, 2019, 05:46:38 pm
content: 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 26, 2019, 06:08:17 pm
content: 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.

author: German_EE
author_rank: Super Contributor
timestamp: December 26, 2019, 06:09:53 pm
content: 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

author: Kleinstein
author_rank: Super Contributor
timestamp: December 26, 2019, 06:20:19 pm
content: 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.

author: Pentoad
author_rank: Regular Contributor
timestamp: December 26, 2019, 07:08:23 pm
content: 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.

author: Kleinstein
author_rank: Super Contributor
timestamp: December 26, 2019, 07:24:56 pm
content: 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.

author: DannyTheGhost
author_rank: Contributor
timestamp: December 26, 2019, 07:32:32 pm
content: At first glance, software-based systems are more prone to different bugsBut 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 issuesAnd, 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

author: iMo
author_rank: Super Contributor
timestamp: December 26, 2019, 07:35:15 pm
content: Another analog system broadly used (from 40ties)https://www.cdvandt.org/Hoelzer%20V4.pdf

author: james_s
author_rank: Super Contributor
timestamp: December 26, 2019, 08:17:54 pm
content: 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.

author: schmitt trigger
author_rank: Super Contributor
timestamp: December 26, 2019, 09:21:41 pm
content: 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.

author: VK3DRB
author_rank: Super Contributor
timestamp: December 26, 2019, 10:17:34 pm
content: Quote from: schmitt trigger on December 26, 2019, 09:21:41 pmExactly. 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.

author: amyk
author_rank: Super Contributor
timestamp: December 26, 2019, 10:51:05 pm
content: Quote from: Pentoad on December 26, 2019, 07:08:23 pmYou might want to look at old (as in 1900s to 1940s) books --- they certainly had ways to do it back then.

author: David Hess
author_rank: Super Contributor
timestamp: December 27, 2019, 12:43:18 am
content: Quote from: Pentoad on December 26, 2019, 07:08:23 pmI 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 27, 2019, 01:14:57 am
content: 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.

author: GlennSprigg
author_rank: Super Contributor
timestamp: December 27, 2019, 12:13:52 pm
content: Most people here would understand that older 'analog' meters/multi-meters work better, whensubjected to stray electro magnetic fields in the immediate vicinity. Either due to the 'lag' of theneedle due to quick transient spikes, or due to the generally lower 'Ohms-Per-Volt' compared tomore sensitive 'instruments'. Although older analog devices can be such that the meter itself affectsthe 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, whensomeone in the control room pressed the 'Transmit' button on a Walkie-Talkie !!

author: mpgmike
author_rank: Newbie
timestamp: December 29, 2019, 08:10:41 pm
content: 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.

author: Red Squirrel
author_rank: Super Contributor
timestamp: December 29, 2019, 08:38:34 pm
content: 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.

author: hans
author_rank: Super Contributor
timestamp: December 29, 2019, 08:56:29 pm
content: “Hardware eventually fails. Software eventually works.” – Michael HartungDigital 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 aresoftware strategies to improveupon 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.

author: nctnico
author_rank: Super Contributor
timestamp: December 29, 2019, 09:14:53 pm
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2019, 10:55:15 pm
content: 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...

author: Zero999
author_rank: Super Contributor
timestamp: December 29, 2019, 10:56:13 pm
content: Quote from: German_EE on December 26, 2019, 06:09:53 pmI 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.

author: schmitt trigger
author_rank: Super Contributor
timestamp: December 30, 2019, 04:47:20 pm
content: Quote from: Zero999 on December 29, 2019, 10:56:13 pmIndeed!Just look at the MCAS fiasco.

author: German_EE
author_rank: Super Contributor
timestamp: December 30, 2019, 05:03:48 pm
content: 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.

author: james_s
author_rank: Super Contributor
timestamp: December 30, 2019, 05:44:43 pm
content: Quote from: schmitt trigger on December 30, 2019, 04:47:20 pmThat 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.

author: schmitt trigger
author_rank: Super Contributor
timestamp: December 30, 2019, 05:54:57 pm
content: Keyword: Therac 25;https://en.m.wikipedia.org/wiki/Therac-25Quote:“These accidents highlighted the dangers of software control of safety-critical systems, “

author: German_EE
author_rank: Super Contributor
timestamp: December 30, 2019, 06:41:28 pm
content: If you want a good example of a safety critical system that must deal correctly with failures then look at traffic lights. Years ago I spoke at length with one of their service engineers and he insisted that a double green at a crossroads CANNOT happen with the system as designed. Obviously there are more complex systems than crossroads but there are specific circuits built into traffic light systems that will turn a system off rather than display an unsafe output.

author: Gyro
author_rank: Super Contributor
timestamp: December 30, 2019, 06:55:42 pm
content: Yes, traffic light systems include redundant (separate H/W system in addition to the normal watchdog protected S/W control and monitoring) Green Conflict protection to shut down the controller. Green conflict is the worst of all situations for traffic and pedestrian crossings.They also include Red lamp current monitoring, to protect against too many Red signal lamps going out on any entrance to a junction - No Red lights can look like a failed junction to the driver, not quite as bad, but 'use caution' may not be sufficient if other vehicles have green signals.

author: iMo
author_rank: Super Contributor
timestamp: December 30, 2019, 07:01:58 pm
content: It took ~40years to replace the Argon-16 computer in the Soyuz rocket:Quotehttps://spectrum.ieee.org/aerospace/space-flight/a-digital-soyuzhttp://www.computer-museum.ru/english/argon16.htm

author: nctnico
author_rank: Super Contributor
timestamp: December 30, 2019, 07:17:25 pm
content: Quote from: james_s on December 30, 2019, 05:44:43 pmActually that is much less of a problem then you'd think. The safety critical stuff has to be well defined so you can add a single layer which checks the conditions and signals an error if there is a mismatch (I usually put in two of these layers written in different ways for redundancy). Whatever is on top can be any kind of software and give whatever command it likes. The safety layer will take care of any illegal situation. Ofcourse this assumes competent engineers working on -at least the safety related part of- a project.

author: SeanB
author_rank: Super Contributor
timestamp: December 30, 2019, 08:29:51 pm
content: there is one application where you only use plain old electrical controls, and that is inside reactors. No electronics, no digital electronics, just plain old magnetic amplifiers and AC synchronous motors, as those are easy enough to design ( as they have been around for over a century) into a near fail never part. They will work till the materials they are made from literally transmute into something else, though your power bill to run them is not ever going to be small, and they will never be small assemblies either.However aircraft still use them in the engines, control systems and avionics, despite the complexity of interfacing them with digital computers for input and output. Aircraft magnetic compass ( yes still a mechanical part) in the tail section is basically unchanged from the original Sperry designs, and there is still the old alcohol filled glass unit in the cockpit as the ultimate all power is gone backup, along with the artificial horizon gyro, standby altimeter and the standby air speed indicator, the rest may be glass but they are still there. Just motors, pressure capsules and geared mechanisms, capable of being dormant for decades, and still able to do that mission critical operation when needed.

author: schmitt trigger
author_rank: Super Contributor
timestamp: December 30, 2019, 09:16:45 pm
content: Quote from: German_EE on December 30, 2019, 06:41:28 pmA poster in another forum who was knowledgeable about traffic light controllers, mentioned that there is a redundant controller to detect invalid states, in which it overrides it and starts flashing the yellow light on all roads within the crossing.

author: Gyro
author_rank: Super Contributor
timestamp: December 30, 2019, 09:38:25 pm
content: That's certainly possible in some countries, the requirement in the UK however is lights out (all lamp power off).

author: SeanB
author_rank: Super Contributor
timestamp: December 30, 2019, 09:48:37 pm
content: Here the conflict monitor will default to all flashing red on fault, or, for some intersections, to a flashing red stop on the minor road and a flashing amber yield on the major road. With the lights all going to LED they had interesting problems with the controllers not recognising the lower load, and with moisture as well causing problems. As the LED lights use a very robust wide range SMPS ( it has to be robust, it can be flashing at 0.5Hz for years in some applications) to generate a 12V power rail, they use around 15W instead of the standard 75W of the original 15000hour rated Traffic lamps, went and looked at the print on an old bulb.In some cases a temporary (probably till they replace the entire control cabinet and cabling next century) fix is to simply place a lamp in a socket inside the cabinet, to draw the leakage down to a low enough voltage not to trip the conflict monitor. If the lights are out most drivers just mutter "Eishkom again", and wait for a gap in the careening taxis to cross safely.

author: Gyro
author_rank: Super Contributor
timestamp: December 30, 2019, 10:40:38 pm
content: ... and that's why we shouldn't venture too far from our own comfortable environments... too many country specific hidden hazards just waiting to bite you.I spent 5 years designing traffic controllers back in the '90s (for my sins!). The assumption over here is that you can't know where the lamp drive fault is - S/W or logic, shorted triac, damage to buried signal cable cores etc. So the only safe thing to do is kill the power to the whole lighting circuit.I'm curious about how other countries manage to safely (presumably independently?) bring up other warning light patterns on the same signal heads - different rules, or something we never thought of?LED signal heads were only just coming in at the time but were already a monitoring headache.

author: Zero999
author_rank: Super Contributor
timestamp: December 30, 2019, 11:08:05 pm
content: I imagine monitoring for a failed TRIAC is interesting, since they normally fail on. I suppose you'd monitor the current and if it doesn't switch off, when told so, cut the power by switching off the main contactor.I would have thought it would be easy to monitor LEDs by including photodiodes inside the lamp module. Granted, this solution would be no good as a simple retrofit, without modifying/replacing the existing control system.

author: schmitt trigger
author_rank: Super Contributor
timestamp: December 30, 2019, 11:25:46 pm
content: Speaking of Led traffic lights;The ones I see over here each individual light is made o a cluster of perhaps 50 or more discrete LEDs.The most common (anecdotal) failures appears to be that many, but not all, LEDs go dark. Leaving a dark area on the individual light.

author: Someone
author_rank: Super Contributor
timestamp: December 31, 2019, 01:20:56 am
content: Quote from: Gyro on December 30, 2019, 10:40:38 pmFrom the Australian standards.QuoteAll dark has been the common failure state. It is allowed to be implemented as a routine in a single processor:QuoteWith some requirements of a watchdog timer to ensure this integrity check is completed frequently enough.

author: NiHaoMike
author_rank: Super Contributor
timestamp: December 31, 2019, 03:10:33 am
content: Quote from: Zero999 on December 30, 2019, 11:08:05 pmActivate a crowbar if the indicator is to be off. Then a stuck on control or line energized by a short to another live line will blow the supply fuse.

author: SeanB
author_rank: Super Contributor
timestamp: December 31, 2019, 10:06:01 am
content: Here the standard Siemens controller uses relays, in plug in modules so you can replace them in the field. Current sensing is done with a simple current transformer per relay, giving feedback so the controller can detect single lamp failures with incandescent, though they had to change the sensitivity for LED clusters. overcurrent is via a circuit breaker per relay, along with a main breaker, and a back up master fuse in the power delivery side, in case a vehicle takes the controller off it's concrete pedestal. feedback is via sense resistors and optocouplers for the controller, but the conflict monitor is separately implemented with it's voltage sensing and change over relays to disconnect all the incoming supplies and change to the flashing relay circuit. You can set the monitor to automatic, where it will disconnect the lights from the controller, and flash for a few seconds, while monitoring for conflict, and switch back if it is transient, or to require manual reset, either by cycling the power, or resetting it.Can result in some odd displays in rain, with the lights cycling between the normal cycle and flashing every few seconds.

author: Gyro
author_rank: Super Contributor
timestamp: December 31, 2019, 02:40:50 pm
content: Wow, relay switching hasn't been used here for decades!It's all triac switched (apart from the main lamp supply contactor / dimming relay). I guess, yes, it must be down to how much rain we get here - relays wouldn't hack it long term here (although they used to I suppose).The only things we have rack mounted over here are loop detectors, and monitoring stuff (again talking from my '90s experience). The CPU and logic is all on a main PCB on a panel stood off from the the rear of the case and separate modular (replaceable) Triac lamp switching modules also at the rear of the case. The rest is 'metalwork' a nice big chunky (up to 30A) autotransformer (for night time dimming) mounted on the support cage (the concreted in bit) and keeping everything warm, together with all the clamps to wrangle the heavy armoured street cable coming in from below into some sort of order.Quote from: NiHaoMike on December 31, 2019, 03:10:33 amA crowbar on a 30A 240V large junction controller could be something to behold! Dropping out the contactor is deemed sufficient here.

author: james_s
author_rank: Super Contributor
timestamp: January 07, 2020, 07:40:01 pm
content: In the USA every control cabinet has a conflict monitor, this is a dedicated piece of hardware that monitors the outputs of the load switches and any kind of conflict will immediately trip the conflict monitor. When this happens a mechanical relay disconnects the signals from the load switches and transfers them to a separate flasher set up to either flash red in all directions, or red on the side street and amber on the main street. Any kind of fault detected in the controller will also cause it to fall back to 4-way flash mode until a worker goes out to reset things.My uncle spent the last 30 years of his career as a traffic signal electrician, he was often on-call and it was not uncommon for him to have to go out during a wind storm to reset several signals that failed to recover properly after a power outage. When I was a kid he showed me inside one of the cabinets a couple times and he used to give me failed or obsolete hardware that had been replaced. I still have an old Honeywell controller, a few load switches, signal heads and pedestrian signs.