4 ms·

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 t

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.

potatochup 5y ago
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
- rurban 5y ago
  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.
  - koollman 5y ago
    which systems would you consider "proper concurrency-safe" ?
    - WJW 5y ago
      Not GP, but something generated by CoPilot (https://hackage.haskell.org/package/copilot https://hackage.haskell.org/package/copilot) would generate constant-time constant-memory C code from a specification written in a DSL. That is what I would start to consider "proper" safe for stuff where it is really important. It depends on what you consider to be absolute requirements for proper concurrency safety of course, and how much of the hardware is allowed to fail before it starts impacting the software.
  - murderfs 5y ago
    > it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. I hate to break it to you, but hardware is basically always broken, and it's all "fixed" in software (especially in embedded, where some vendors don't even bother with steppings to fix errata).
bregma 5y ago
Full disclosure, I'm an insider in the industry. I'd like to comment on a few trends I've been seeing. First, ECUs are now running a general purpose OS rather than a single embedded application. That means compartmentalization of functionality into separate, restartable processes (a program crash is considered a safe failure mode), which is a very good thing. Most synchronization is performed at the low level by the safety-certified OS kernel using very well-known well-understood and well-tested mechanisms, so you don't have to worry about non-experts writing the bad C code so often lambasted in religious screeds. A big advantage is that the software components can be developed, tested, and verified in isolation all using proven-in-use techniquies on a development host before ever finding their way to a target system. The tradeoff is much higher overhead, which with todays processors is effectively noise that disappears into the background. Second, the CPUs are so fast that manufacturers have developed tickless mode in which most of the silicon gets put to sleep. ECUs these days do much much more nothing faster and in parallel. Things like bigLITTLE make it end up that only 1 32-bit core is actually doing anything almost all the time. So cheaper, less cost, but available when needed. Pretty much all of this is hidden by the OS, so don't worry about your storied ignorant C developer not understanding how to control their software. Third, somebody not close to the silicon but close to the ledger books looks at all this glorious CPU and memory on an ECU and realizes there are unused resources being paid for and going to waste. They realize they can stick logos on their product marketing material if they start using those spare resources for AI technologies. Yes folks, some of those ECUs are starting to crunch numbers using Fortran libraries driven by Python. From a consumer point of view it's great because the software can now make up for bad hardware dynamically, adaptively, and in real time. From a functional safety engineering point of view, as long as all hazards are mitigated and all failure modes lead to a safe state, it's not a bad thing. Yes, the silicon in control of your truck is getting bigger, wider, and faster is blooming multiple cores. The software development for it is taking advantage of 70 years of evolution to match. Sit back and enjoy the ride.
- fundmondawyaya 5y ago
  Many of the benefits that you list are for manufacturers, not consumers. My 1990s car has an ECU that only has one job, and runs fully-characterized code. I'd trust it to run another 25 years with no problems, firmware updates, or security patches. I do not trust something running a full-fledged OS to drive something safety-critical; I cannot imagine that the whole system is fully vetted, and I don't want bugs in the chip that is in charge of my engine. And now they're planning to run ML algorithms on the ECU to use all the extra compute that they never needed in the first place? That sounds like an absolute nightmare. Based on what you've written, I am very glad that I'll probably never buy a new ICE car ever again.

potatochup 5y ago

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

rurban 5y ago
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.
- koollman 5y ago
  which systems would you consider "proper concurrency-safe" ?
  - WJW 5y ago
    Not GP, but something generated by CoPilot (https://hackage.haskell.org/package/copilot https://hackage.haskell.org/package/copilot) would generate constant-time constant-memory C code from a specification written in a DSL. That is what I would start to consider "proper" safe for stuff where it is really important. It depends on what you consider to be absolute requirements for proper concurrency safety of course, and how much of the hardware is allowed to fail before it starts impacting the software.
- murderfs 5y ago
  > it's nice that threading got better recently in embedded Realtime OS's, HW always gets better, but certainly drivers not and SW not. I hate to break it to you, but hardware is basically always broken, and it's all "fixed" in software (especially in embedded, where some vendors don't even bother with steppings to fix errata).

bregma 5y ago

Full disclosure, I'm an insider in the industry. I'd like to comment on a few trends I've been seeing. First, ECUs are now running a general purpose OS rather than a single embedded application. That means compartmentalization of functionality into separate, restartable processes (a program crash is considered a safe failure mode), which is a very good thing. Most synchronization is performed at the low level by the safety-certified OS kernel using very well-known well-understood and well-tested mechanisms, so you don't have to worry about non-experts writing the bad C code so often lambasted in religious screeds. A big advantage is that the software components can be developed, tested, and verified in isolation all using proven-in-use techniquies on a development host before ever finding their way to a target system. The tradeoff is much higher overhead, which with todays processors is effectively noise that disappears into the background. Second, the CPUs are so fast that manufacturers have developed tickless mode in which most of the silicon gets put to sleep. ECUs these days do much much more nothing faster and in parallel. Things like bigLITTLE make it end up that only 1 32-bit core is actually doing anything almost all the time. So cheaper, less cost, but available when needed. Pretty much all of this is hidden by the OS, so don't worry about your storied ignorant C developer not understanding how to control their software. Third, somebody not close to the silicon but close to the ledger books looks at all this glorious CPU and memory on an ECU and realizes there are unused resources being paid for and going to waste. They realize they can stick logos on their product marketing material if they start using those spare resources for AI technologies. Yes folks, some of those ECUs are starting to crunch numbers using Fortran libraries driven by Python. From a consumer point of view it's great because the software can now make up for bad hardware dynamically, adaptively, and in real time. From a functional safety engineering point of view, as long as all hazards are mitigated and all failure modes lead to a safe state, it's not a bad thing. Yes, the silicon in control of your truck is getting bigger, wider, and faster is blooming multiple cores. The software development for it is taking advantage of 70 years of evolution to match. Sit back and enjoy the ride.

fundmondawyaya 5y ago
Many of the benefits that you list are for manufacturers, not consumers. My 1990s car has an ECU that only has one job, and runs fully-characterized code. I'd trust it to run another 25 years with no problems, firmware updates, or security patches. I do not trust something running a full-fledged OS to drive something safety-critical; I cannot imagine that the whole system is fully vetted, and I don't want bugs in the chip that is in charge of my engine. And now they're planning to run ML algorithms on the ECU to use all the extra compute that they never needed in the first place? That sounds like an absolute nightmare. Based on what you've written, I am very glad that I'll probably never buy a new ICE car ever again.