Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Migration Of Engine ECU Software From Single-Core To Multi-Core

semiengineering.com

Post reply on HN
Print view View original

1–10 of 25 posts

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#3

Post by culopatin »

Can anyone enlighten me why you need multi thread to control something of much slower frequency than a CPU? I think there is more to be gained in the sensors than in a faster ECU. Of course I’m only speaking about Engine control, not all the other stuff in the car.

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#4

Post by potatochup »

culopatin wrote: post #3

Can anyone enlighten me why you need multi thread to control something of much slower frequency than a CPU? I think there is more to be gained in the sensors than in a faster ECU. Of course I’m only speaking about Engine control, not all the other stuff in the car.

CPUs in the automotive space are primarily chosen for being cheap, and with the right number/kind of IO. If you do enough stuff¹, it's certainly possible to reach the CPU load limits of a single core CPU, and it might cheaper to upgrade to a dual core than put in another ECU (also, faster ECUs with the same IO/arch might not be available).

I've also seen arrangements where the dual-cores have separate memory spaces, and one core acts like a safety processor/monitor while the other is the main compute module.

1: examples of CPU intensive stuff include active damping, active aero (spoilers), active rear steering, steer by wire, etc. You may think these things are irrelevant w.r.t. an engine ECU, but if the engine ECU is responsible for producing torque, then systems like traction control, stability control and etc are all directly related to torque production

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#6

Post by rurban »

potatochup wrote: post #4
culopatin wrote: post #3

Can anyone enlighten me why you need multi thread to control something of much slower frequency than a CPU? I think there is more to be gained in the sensors than in a faster ECU. Of course I’m only speaking about Engine control, not all the other stuff in the car.

CPUs in the automotive space are primarily chosen for being cheap, and with the right number/kind of IO. If you do enough stuff¹, it's certainly possible to reach the CPU load limits of a single core CPU, and it might cheaper to upgrade to a dual core than put in another ECU (also, faster ECUs with the same IO/arch might not be available). I've also seen arrangements where the dual-cores have separate memory spaces,…

I've worked in the field, even with the biggest and fastest ECU's in existance, Formula 1, with 10Khz cycles on 4Ghz CPU's

we never saw the need to use the other cores. the CPU is a few million times faster than the cycles, if there is a problem it's a HW IO or blocking driver. even with normal 500Hz ECU's you can always upgrade the CPU freq to run faster, than needing more cores. even better would be to use better drivers with zero copy and MMU access.

it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. and developers even less. maybe they think rust will help, but then they should chose a proper concurrency-safe system. certainly not rust, which only lies about it.

also this thing is only simulation verified, not formally verified.

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#7

Post by KennyBlanken »

JonChesterfield wrote: post #2

Well that's horrifying. Not where I want multithreaded code. Definite risk of it being written in C with volatile~=atomic as the working assumption.

People found the concept of computer control over an idle stabilization valve terrifying in the early 80's. Killer cars, everyone predicted. It never materialized. The lawsuits against Audi never went anywhere, and Audi even won some counter-suits.

Most cars have drive-by-wire throttles. Hundreds of millions of cars out there, and DBW throttle failures leading to crashes are unheard of.

You know what is an issue? Ford unable to make ignition switches that don't cause cars parked in house garages to catch fire. GM cheaping out on their own ignition switches, causing them to suddenly fail while driving....and thus shutting off the engine, ABS, and airbag systems, something that is known to have caused the deaths of half a dozen people and likely tens if not hundreds of other Cruze owners.

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#8

Post by koollman »

rurban wrote: post #6
potatochup wrote: post #4

Earlier quoted context omitted.

CPUs in the automotive space are primarily chosen for being cheap, and with the right number/kind of IO. If you do enough stuff¹, it's certainly possible to reach the CPU load limits of a single core CPU, and it might cheaper to upgrade to a dual core than put in another ECU (also, faster ECUs with the same IO/arch might not be available). I've also seen arrangements where the dual-cores have separate memory spaces,…

I've worked in the field, even with the biggest and fastest ECU's in existance, Formula 1, with 10Khz cycles on 4Ghz CPU's we never saw the need to use the other cores. the CPU is a few million times faster than the cycles, if there is a problem it's a HW IO or blocking driver. even with normal 500Hz ECU's you can always upgrade the CPU freq to run faster, than needing more cores. even better would be to use better d…

which systems would you consider "proper concurrency-safe" ?

Re: The Migration Of Engine ECU Software From Single-Core To Multi-Core

#10

Post by cillian64 »

KennyBlanken wrote: post #7
JonChesterfield wrote: post #2

Well that's horrifying. Not where I want multithreaded code. Definite risk of it being written in C with volatile~=atomic as the working assumption.

People found the concept of computer control over an idle stabilization valve terrifying in the early 80's. Killer cars, everyone predicted. It never materialized. The lawsuits against Audi never went anywhere, and Audi even won some counter-suits. Most cars have drive-by-wire throttles. Hundreds of millions of cars out there, and DBW throttle failures leading to crashes are unheard of. You know what is an issue? For…

I don’t have a source for this but I recall reading that mechanical throttle wires are actually not especially reliable so drive-by-wire doesn’t have to be super reliable in order to be better.

But perhaps it’s the same as self driving cars where people get especially disturbed by computers screwing up which sets the reliability bar higher than is otherwise logical.

Post reply on HN