Live data from Hacker News

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

semiengineering.com

21–25 of 25 posts

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

#21
How do they plan to get through ISO 26262 verification? You do not need to do HARA to know ECU is ASIL D. ASIL D Item requires developer to do Modified Condition and Decision Coverage. Running through all the test cases will be a huge task. The golden rule for Automobile Software is simplicity. Always keep it simple unless it is absolutely necessary. They need to read through ISO 26262 chapter 6.

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

#22
post #14

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.

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…

> 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.

That's gross. Like that hardware uses no power, its purpose is to be at attention every foot of the journey. That's waiting, which in western culture means "slacking off", but in other cultures, like African cultures, is...well I don't know quite, but I think it's neither work nor rest.

It's like going to a restaurant, you want the waiter to wait on you, you do your thing and when you need him he'll be ready. Maybe you'll need him often, or not even once. Doesn't matter, he still waited on you. Doesn't have to be moving all his arms and legs every second from the minute you walk in to the minute you leave, if he's ready to help when you need him, it's much more useful.

Ultimately for tickless chips to be work there has to be a change in mentality that respects waiting as unique, that values availability without requiring effort.

I guess it goes back to the idea in the west that values effort in different ways, rather than results. Effort meaning personal cost, too. Well when I was an employee I'd say they're both valued, equally, in the following way: you get paid according to the minimum of the two. Good results? Yeah but that only took you an hour, that only cost you $20, "don't complain." Working really hard but not achieving the goals? We're going to have to fire you and rehire at a lower wage that you can actually bring in. And that's why employees are so "resentful" about working, they're not, it's just an optimization function, if they're producing good value they have to look like they're working hard or there's a big cost to them of producing it, that's the resentful part, otherwise they get cheated. And further, it explains forfeiting results for the business all the time, if they're maxed out on the effort part they won't make a single fucking cent from it. Even if it costs nothing, bad idea, no working for free because then the floodgates of exploitation open. The employee does not want to work for an even richer, and therefore more powerful, employer if that employer is exploitative.

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

#23
Few have demonstrated actual competency with using 1 computer. I struggle to comprehend a reality in which auto manufacturers or their vendors are able to manage more than 1 without causing net harm to themselves or society.

The only arguments for more compute power in cars boil down to distracting the driver or making them feel like they are somewhat less responsible for the laws of physics.

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

#24
post #14

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.

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…

The "E" in ECU sometimes is eletronic and sometimes engine, depending on the sub-field and region of the automotive industry.

For engine control (the topic of the original article) a general-purpose Os and lots of idle time are unusual. In many cases the most powerful controller available on the market is is filled with software just shy of losing tasks.

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

#25

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…

> Most cars have drive-by-wire throttles.

Cars where? Many cars here in Europe have a valve directly mechanically linked to the pedal. Any car without cruise control has it that way.

Post reply on HN