Automotive electronics best practice  - Page 1
Forum section: electronics / projects

author: SteveThackery
author_rank: Super Contributor
timestamp: January 22, 2025, 04:47:23 pm
content: I've made several electronic gadgets for installation on cars and motorcycles. Being aware of the hostile electrical environment I protect the electronics by enclosing the board in a conductive metal box connected to ground. All the inputs go first through a current limiting resistor - typically 10s of kilohms - (or a voltage divider pair as required), then are clamped to the +ve and -ve power rails for the electronics by Schottky diode pairs, and finally they go to the microcontroller input pins. The external 12V feed to the electronics has electrolytic and ceramic decoupling capacitors on the circuit board, followed in almost all cases by a buck regulator down to 5V, similarly decoupled. (Crude pic below.)Despite these precautions, crashes and lockup of the microcontroller are not unusual, so I always incorporate a watchdog.I've observed that automotive electronics are exceptionally rugged and reliable, and I don't believe crashes and lockups occur regularly, maybe never. So, how are "real" automotive electronics protected against their electrically hostile environment? In particular, is there any kind of "best practice" document that describes all the protection measures that are normally adopted?It is clear that making automotive electronics, including microcontroller devices, bullet-proof and crash-proof is a solved problem. I'm hoping to find out how that "solved" is achieved.

author: Stringwinder
author_rank: Contributor
timestamp: January 22, 2025, 04:58:43 pm
content: Highly recommended!National Semiconductor - Voltage Regulator Handbook - 1980

author: uer166
author_rank: Super Contributor
timestamp: January 22, 2025, 05:17:16 pm
content: Quote from: SteveThackery on January 22, 2025, 04:47:23 pmI don't have a doc for you since it's mainly internal stuff, but generally:Simple/robust input/output protection, which in practice is:Ceramic caps at every I/O for emissions and ESD toleranceSeries R where you can afford itClamping/steering diodes where it makes senseUsage of bus-fault tolerant HW (a great example is CAN transceivers that won't get damaged if any of the lines short to VCC or GNDExtensive usage of HSDs and eFuses to protect downstream power.Extensive case-by-case analysis and FMEA: there are generally no "rule of thumb" guaranteed shortcuts to everything

author: uer166
author_rank: Super Contributor
timestamp: January 22, 2025, 05:17:50 pm
content: Quote from: Stringwinder on January 22, 2025, 04:58:43 pmCompletely irrelevant to OP's question..

author: Benta
author_rank: Super Contributor
timestamp: January 22, 2025, 05:56:57 pm
content: Never solder stranded wire/cables. Use crimp connections only.Be prepared for high power load dump transients up to +/- 60 V.

author: Stringwinder
author_rank: Contributor
timestamp: January 22, 2025, 07:29:10 pm
content: Quote from: uer166 on January 22, 2025, 05:17:50 pmYeah - off course page 7-32 to 7-36 "Voltage Regulators In Automotive Applications" is irrelevant... but then your comment shows you haven't read that part.

author: SteveThackery
author_rank: Super Contributor
timestamp: January 22, 2025, 09:52:39 pm
content: Quote from: uer166 on January 22, 2025, 05:17:16 pmOK, but electronic control units have been commonplace in vehicles for 40 years now. I don't believe there to be any proprietary secrets, or any innovation happening in this space. As I say, "hardening" the electronics in vehicles is a thoroughly sorted problem. I'm certain the industry will have a standard set of practices that are universally adopted: power line conditioning, screening, protection circuits.... There is no business sense in researching and developing your own solution to this when - I strongly suspect - automotive engineering students are taught how it's done.The concept of 'best practice" is everywhere in engineering. Nobody wants to waste time R&D-ing a solution to something that is already solved. And that's why I suspect this best practice will be documented somewhere. Think about electrical safety: nobody wastes time R&D-ing breakdown voltages, air gaps, connectors, insulation, track spacing, any more; we know what to do to make an SMPS (say) safe, and we do it. Manufacturers everywhere use the same tried and tested practices because they know they work, and deviating from them incurs risk and costs money.I bet there are loads of people on this forum who are totally familiar with electrical safety standards and can point to where they are written down. Although there won't be the same weight of legislation behind them, I bet there will be a similar set of standard practices for "hardening" automotive electronics.Except I can't find them anywhere!

author: MisterHeadache
author_rank: Regular Contributor
timestamp: January 22, 2025, 10:20:23 pm
content: Quote from: SteveThackery on January 22, 2025, 09:52:39 pmI would be one of those guys. I've worked in automotive for 30+ years and have designed and put several powertrain and chassis sensors into high volume production. The simple answer is the OEM standards and best practices are proprietary to the tier suppliers and the OEM's. So you aren't going to (legitimately) get your hands on them. There of course is always reverse engineering which can reveal a lot of how we handle power supply transients, reverse voltage protection, and the always popular load dump spikes.Each OEM of course has their own EMC standards which -generally- align with ISO and other standards, but they also sometimes have their own sacred requirements that we have to design to just for them. Regarding ISO standards, ISO 7637-1, -2, and -3 are detailed specifications for the transient conditions that you are interested in and are not proprietary to an OEM, and would give you an idea of what automotive electronics typically have to withstand (but the standards aren't free).Regarding innovation, the OEM standards tend to stay static for a few years, but with the ever increasing electronic content in cars and increased use of the RF spectrum, they do get periodic updates and get stricter over time. There is also ISO26262 (functional safety) which has added an enormous amount of qualification work that has to be done now as part of qualifying a design for series production.

author: SteveThackery
author_rank: Super Contributor
timestamp: January 22, 2025, 10:32:32 pm
content: Thank you - that's a really informative reply.Like an idiot I didn't think to call upon ChatGPT et al to assist. I've had a little play and it did manage to dig out some generic best practices which do begin to address my question. I'll paste its reply here:PROMPT"Referring to the field of automotive electronics: electronic control units (ECUs) require "hardening" against the electrically hostile environment in vehicles. Protection against noise, voltage spikes and electromagnetic radiation is required. Where can I find a comprehensive description of industry best practice aimed at achieving these ends?"ChatGPT REPLIED:"Protecting Electronic Control Units (ECUs) in vehicles from electrical noise, voltage spikes, and electromagnetic interference (EMI) is crucial for reliable automotive electronics. Comprehensive industry best practices can be found in several authoritative resources:STMicroelectronics' Application Note AN2689: This document provides detailed guidelines on protecting automotive electronics from electrical hazards, including design approaches and component selection.STTexas Instruments' "Ten Tips for Successfully Designing with Automotive EMC/EMI": This resource offers practical advice for addressing electromagnetic compatibility (EMC) and EMI challenges in automotive applications.TIAnalog Devices' Article on Protecting Automotive Electronics Systems: This article discusses methods to protect and power automotive electronic systems while minimizing switching noise.ANALOG DEVICESThese resources cover essential topics such as filtering techniques, shielding methods, grounding strategies, and the selection of appropriate protection components to enhance the resilience of ECUs against electrical disturbances."

author: mr ed
author_rank: Regular Contributor
timestamp: January 23, 2025, 12:34:59 am
content: I remember way back 12v bus load dumps as being +60v but -300v (not -60v) !

author: Rerouter
author_rank: Super Contributor
timestamp: January 23, 2025, 10:38:47 am
content: Hardware Side:Use an automotive grade supply module to save a lot of the difficulties of load dump and other issues if your current is small, it also makes certification faster, Recom has been great to me so farTreat every connnection on your device as if it will be hooked up backwards across 24V while a 5W test light probes the other connections, (I use level converters for a lot of my IO)Those input diodes do result in side effects, if its to your VCC rail, is your load large enough to keep the voltage in check if every IO was connected to max voltage? this is sometimes called backdriving, where your powering your device through the IO,Don't trust the ground too much, a lot of older trucks and buses may have 2V offsets between electrical and chassis ground, some due to age, and some due to negative isolators, (These are also why I design around -24V, with some negative isolators it ends up biasing the chassis to -24V of the permanent electrical negative)if your using a potentiometer for some control input, make it ratiometric, this way noise gets mostly cancelled outUse pullups / pulldowns to define the disconnected state of inputs, and if something is important, detect if its actually connected, this might mean 2V is normal idle, and 5V is your signal high, so 0V or 12V you know there is an issueIf you don't care about the common mode voltage, consider AC coupling the signal, things like frequency inputs etc,Keep larger gaps between permanent supplies and ground, corrosion around where a battery pin is surrounded by a ground flood are pretty common,Be careful about how much your loading external signals, the last thing you want is for your device to change the behavior of some other device (ticket machines have a 10mA pullup on there speed signal which messes with a lot of systems)For the devices I had to design for very noisy environments I used a "demagnetiser" basically a cut in half mains transformer hooked up to a PA system, to sweep all kinds of noise over the PCB from various angles to try and induce any kind of misbehavior,If you have room on the board, label the connections, it makes debugging much faster to see that pin 43 is a clock, or the input range is 7-30V when your supporting something you designed 5+ years agoBreak out unused IO to pads, they don't have to be big pads, but enough that if something changes you can bodge a wire onto it for field testing until the next revision comes out.Software:Define the states your system can be in, in an ideal world if your watchdog just fired you will be able to take that state and pick up were you left off with no visible change to the user, (A watchdog does not have to just reset the system, it can call a cleanup interrupt function or similar)Figure out what valid and invalid data looks like from your sensors and bake that testing into your library, if your expecting 42 bytes within some range, did you get 42 bytes, and was it in the range? obviously it depends on how critical the data is, but as a designer you will have some idea, if a read failed, well that's a state your system can be in, and you need to define it, same for if writing to a sensor fails etc, it might seem overkill, but if a cockroach has pooped on your SPI clock and data lines, your going to need to have some awareness that a problem has occurred.some approaches are retry X amount, others are discard the result and defer the code that needs the result until some timeout, and if it cant get a result by some amount of effort, assume some safe default and handle the state. if its some option you dont care about, then have a branch for it saying as muchClass Enums, Constexpr and Static Asserts are great, the main trick is try and isolate the physical parts from the logic parts, this way you can test that 2+2=4 be it on the micro or on a PC, Enums help with making sure only the intended places can use or update the values, Constexpr lets you offload as much as reasonable to compile time, and with it you can then do compile time checking that functions are working how you expect,Specify sizes for your variables and functions rather than int or long helps with compiler warnings such as unintended conversions, alternatively you can use auto if code size is not as much of a constraint, though I prefer to be specific personally,Most libraries arent always that well made, I'll generally take ownership of the library for a given project, e.g. have a local copy or remake it specific to the purpose, for things like SPI or I2C peripherals its generally a hour or 2 to make tops, and means you have vetted that it is in agreement with the datasheet, (e.g stripping down software serial for write only takes it from 600 bytes of memory to 80)

author: SteveThackery
author_rank: Super Contributor
timestamp: January 23, 2025, 02:22:31 pm
content: Thank you, everyone, for the brilliant contributions.. Special mention to@Rerouterfor such a comprehensive essay.The references ChatGPT found, along with the information from you guys, has highlighted a number of areas where I should improve my practices, so that's a great success. Thank you all, again.

author: Terry Bites
author_rank: Super Contributor
timestamp: January 23, 2025, 05:54:05 pm
content: Seach for Auto qualified ICs "AEC-Q100"