Whats wrong with microcontrollers for robust electronics?

[Faringdon]

Hi,
Our customer wants an offline battery charger.
We offered it with a simple microcontroller to read the  charge current, and pwm via an digi isolator across to the primary controller and set the current like that...but cust tells us that microcontrollers are not robust, and so requested optocoupler feedback instead.
Why are microcontrollers not robust?...its for a military application, but its a kind of "well behind the lines application", so to speak.

[voltsandjolts]

It's the 11^th of December already and you've only started 9 threads so far this month. Must try harder, crack on sir, crack on.

[ejeffrey]

I mean, if the customer wants an isolator and it doesn't otherwise compromise the performance, just give them an isolator?  You havent and probably are not allowed to give us enough information to determine if it's a good idea.

If the requested approach will degrade performance in a way that is relevant to the application you should explain that to the customer and then describe what you can do to alleviate their concerns about the MCU.

There are several reasons this could happen.  The first of course is that the person asking for it doesn't actually know what they are doing and is just following something they heard.  Another is that they are following a procedure that makes sense in some situations but not others and your project isn't important enough to warrant an exception / review.  There could be a real reason behind it, and if a military application could be a reason they are not able or willing to share with you.

As for MCU robustness, they certainly can be robust and are used in far more critical applications than a battery charger, but it doesn't mean much until you look at the environment and application. 

[strawberry]

MCUs are digital and robust and in theory can run forever until memory loss kicks in ~5..10Y
military and airospace pay extra to get extra robust selected chips and everything else is dumped for consumer products

[magic]

You guys know what's worst?

This thread made me realize that in about 10 years somebody will put on the market a PSU utilizing feedback over WiFi with a pair of ESP8266.
You just know that this is inevitable

[coppercone2]

the well behind the lines application might be a critical communication link or something. I suggest not arguing with the milspec and just enjoy the work. Military stuff is more expensive for a reason.

And what the government wants is stuff that keeps working when congress ends up slashing their budget with a combine, leadership is replaced with incompetent leadership, your company goes under after three acquisitions, the schematics get lost, the engineer dies and general government corruption sets in. Then its at least like OK its really bad but at least I don't think that system is going to fuck us tomorrow on top of everything else. Also hackers, cyber warfare is taking off big time. Someone wants base system controlled by firmware to be paranoid on top of everything else? And with their luck, some fresh out of accelerated boot camp underpaid, young IDGAF attitude specialist with 2 months accelerated specialist training is going to end up running the operation lol.. these guys look like blurs their so accelerated.. and no he is not suffering cyanosis, its just blue shift from all the acceleration. Oh and the module might end up 135 feet under ground in a frequently flooded tunnel that has been heated to 75 degree C from the leaky 100 year old steam pipe connected to the white house

[DrGeoff]

That's right. I had the same issues a few decades ago with designs for Air Traffic stuff. Microcontrollers were an issue.
The reasons:
- Firmware issues. The firmware is not evident on the schematic and must be relied upon to perform the correct task.
- Firmware maintenance. Separate to the hardware revision control there must also be firmware revision control and test processes to ensure operational correctness.
- Device memory for firmware. Flash memory has a lifetime and degrades over time. The contents can be corrupted. If you don't build redundancy and auto-detection and correction of the firmware in flash then there is a potential for it to fail in the field. I did see this with Atmel 8051 flash devices after only a couple of years of operation under test conditions. The flash memory went soft and started throwing errors.
- Longevity of supply. With ATC and Mil gear, the supplier usually has to guarantee 20 years of supply of the components (or more in some cases). With the rapidly changing face of electronics, that's a long time. Usually requires stockpiling of the components for this requirement.
- MTBF. What's the MTBF for the microcontroller? There are usually strict minimum MTBF and MTTR numbers in mil and atc requirements. I've has stuff fail these number because the wrong LEDs were chosen. I can imagine problems with micro MTBF numbers as there is vastly more to fail.

[Nusa]

The correct answer for military contracts is: No problem! It'll cost this much to do it your way! Your money is our command!

[floobydust]

Modern microcontrollers are robust, they're spinning your car's steering, controlling airbags, brakes, drive by wire throttle etc.
Challenge-response watchdog, power supervisory, lock-step CPU, clock fail detect etc.  have all helped the hardware reliability - if only we weren't tied down to an antique programming language and the usual corporate crisis to get the product out the door ASAP.

The problem is a battery incident is extremely costly.
A battery charger, military use - is treezco capable of functional safety in firmware? Uh, no just do it in hardware with an opto-coupler lol.

[strawberry]

I guess airbag and sensors use flashless controllers
magnetic tapes seems to be best.

[DrGeoff]

I guess airbag and sensors use flashless controllers
magnetic tapes seems to be best.

The MTBF of airbag controllers is nothing to boast about.

[DrGeoff]

Modern microcontrollers are robust, they're spinning your car's steering, controlling airbags, brakes, drive by wire throttle etc.
Challenge-response watchdog, power supervisory, lock-step CPU, clock fail detect etc.  have all helped the hardware reliability - if only we weren't tied down to an antique programming language and the usual corporate crisis to get the product out the door ASAP.

The problem is a battery incident is extremely costly.
A battery charger, military use - is treezco capable of functional safety in firmware? Uh, no just do it in hardware with an opto-coupler lol.

Consumer vehicles and Military or Aerospace equipment are completely different things.
Retail/commercial application requirements are significantly relaxed from the Mil and ATC stuff.

I was only pointing out the requirements for this kind of stuff about 25 years ago. Things are better but I don;t know how much the requirements will be relaxed. MTTR and MTBF were hot issues.

[2N2222A]

Some really good reasons are already mentioned.

The thing that stands out to me most is repair. You cannot replace a microcontroller with a generic part. It has to be programmed exactly like the old one. This requires extra time and tools to do a repair.

There is also sabotage or planned obsolescence . There could be some timer in the firmware that disables it at a certain date or after so much use. There's no visual inspection for modified firmware.

Microcontrollers can also lock up from a brief EMP. A circuit without a microprocessor would immediately recover.

Microcontrollers are not always radiation hardened and can't be used in space. Maybe nuclear war radiation applies here too. The device must function in nuclear war.

[floobydust]

Consumer vehicles and Military or Aerospace equipment are completely different things.
Retail/commercial application requirements are significantly relaxed from the Mil and ATC stuff.

I was only pointing out the requirements for this kind of stuff about 25 years ago. Things are better but I don;t know how much the requirements will be relaxed. MTTR and MTBF were hot issues.

OP's threads are well known to contain vague, semi-fictitious premises leading to the thread circling the toilet bowl.
"well behind the lines application"" Is it really to a mil spec and which one applies? "Customer" telling engineering how to do the design?  "microcontrollers are not robust"

Every day people trust embedded systems, for example in cars and home heating systems. I treat functional safety as different from MTBF, although they meet in the FMEA.
Boeing 787 Dreamliner Battery fires, they bungled the safety analysis MTBF 1 in 10 million hours uh it was two in 52,000 hrs. The charger was implicated but I've forgotten its role.
Who knows what hazard there is due to an overcharging fault in OP's device. Why complain about using an opto-coupler?

[coppercone2]

well it is a highly integrated device, a optical wave guide and a diode/receiver might be more robust. Optocouplers are the cheapest solution (typical government).

[SiliconWizard]

Well as far as this question goes, anything can be answered. From one word to a whole thesis.

The more complex a system is, and the higher the probability of failure. In general. So we could say that a microcontroller + firmware is per se a much more complex *system* than a simple, purely hardware-based feedback. Now of course with a microcontroller, you can implement features that would otherwise be clunky to implement, and that can significantly reduce the number of parts in your design. System-wise, the microcontroller with its firmware is still more complex, but it can reduce the number of parts and thus fewer potential points of failure in terms of hardware.

The choice is, you guessed it... engineering.

To address the specific problem with your client, that's a very common issue IME. I dunno about you guys in general, but clients who think they know better than you on some technical points (while needing your expertise to design), often based on preconceptions ("I think that...", "Several people in the field have said that..."), they are not rare, and they are usually a pain to deal with. But in the end, it all comes down to your communication skills: convince them while still conveying the idea that it's in their best interest.

[tggzzz]

The choice is, you guessed it... engineering.

To address the specific problem with your client, that's a very common issue IME. I dunno about you guys in general, but clients who think they know better than you on some technical points (while needing your expertise to design), often based on preconceptions ("I think that...", "Several people in the field have said that..."), they are not rare, and they are usually a pain to deal with. But in the end, it all comes down to your communication skills: convince them while still conveying the idea that it's in their best interest.

While I agree.with those points, I have come across clients that do know more about their problem and (un)acceptable solutions.

But the major point is that, as noted above, this is another barely literate question from treez/faringdon. As such it isn't worth spending time on it. Even the OP seems to think that, since he hasn't bothered to reappear in this thread.

[penfold]

I'd guess that it's just a BS explanation from your customer.

In defense, there are a few top-level requirements that seem to find themselves copy-pasted verbatim into all UK defense projects and echo down from contractor to subcontractor without thought. At the higher levels, they're just kinda indisputable and too difficult to phrase to include possible exemptions, but by the time they're used in conjunction with a specific design entity (where an exemption could be perfectly valid), it is too time-consuming to have it changed back up the tree.

It could be that there is a requirement that mandates all software is validated according to a specific standard (i.e. no software of unknown pedigree (SOUP)) and makes even the smallest firmware project prohibitively time-consuming. There'll be one about field serviceability, no non-volatile memory etc.
The MOD also gets scared of the prospect of throwing spares into stores for 20 years and not having a copy of the firmware to hand if for some reason it was unprogrammed or for whatever reason corrupt.

There are plenty of ways to do it using a digital isolator without a micro surely?

[ogden]

Hi,
Our customer wants an offline battery charger.
We offered it with a simple microcontroller to read the  charge current, and pwm via an digi isolator across to the primary controller and set the current like that...but cust tells us that microcontrollers are not robust, and so requested optocoupler feedback instead.
Why are microcontrollers not robust?...its for a military application, but its a kind of "well behind the lines application", so to speak.

Who do you trust more: random integrator who promises to craft & code microcontroller-based battery charger or reputable semiconductor company which is known to deliver widely-used, dependable IC's?

[mzzj]

There are plenty of ways to do it using a digital isolator without a micro surely?

If you take a look of "Faringdon" aka Treez couple of last topics you'll find out this is not the first stumbling block.

[BrianHG]

From experience, do not trust the development microcontroller programmers for production.  Production grade programmers usually go through extra repetitive burning steps & multi-level voltage verification to truly burn in the Eprom / EEprom where the development programmers usually do no such thing, or aren't even capable of performing the function.

In the early years of Microchip PIC programming, I made this mistake and a few hundred returns made it back to me within 1 year or so.  Properly burning PICs takes 4x as long on the real production grade programmers, but once I made the switch, 0 returns in over a decade.

Same goes for regular eprom programming.

[SiliconWizard]

The choice is, you guessed it... engineering.

To address the specific problem with your client, that's a very common issue IME. I dunno about you guys in general, but clients who think they know better than you on some technical points (while needing your expertise to design), often based on preconceptions ("I think that...", "Several people in the field have said that..."), they are not rare, and they are usually a pain to deal with. But in the end, it all comes down to your communication skills: convince them while still conveying the idea that it's in their best interest.

While I agree.with those points, I have come across clients that do know more about their problem and (un)acceptable solutions.

Yes sure, if that is an area that you're not familiar with. The OP did mention a military application, which is a tiny bit different from random consumer electronics. Now the reported statement seems a bit weak - the client would need to provide a full set of requirements (including regulatory matters). Or maybe the client is just assuming that the OP will develop according to those requirements without having explicitely mentioned them. If that is the case, good luck (to the client! )

A military application is a specific beast indeed. Using a MCU? Why not. But you'd need to find one that is qualified for this, which is gonna be tough and expensive, possibly require signing NDAs with your blood, etc. And the software part will have to be validated.

If the OP runs a 1-person business (as I got it?), I would even say forget about it. I would not take a contract for a military application unless I had a solid business behind and a good insurance.

[floobydust]

Military projects are vetted, you'll have to meet many requirements to be a vendor including a track record, insurance, security, proficiency etc.
OP's company must be large. Or the BS has spilled over...

[tggzzz]

Or channelling Walter Mitty.
Or flying a kite.
Or asking "what if" questions.
Or just being treez/faringdon, with all that implies.

[pcprogrammer]

Military projects are vetted, you'll have to meet many requirements to be a vendor including a track record, insurance, security, proficiency etc.
OP's company must be large. Or the BS has spilled over...

I was just thinking that. You just don't land such a project without submitting a well specified offer based on a well specified request.

So again utter bullshit out of the, by now, well known corner called Faringdon

If the OP runs a 1-person business (as I got it?), ....

Don't forget that it is a Royal one person business 

Our customer wants an offline battery charger.