- #1
- 3,511
- 1,623
- TL;DR Summary
- In the wake of a dead battery, a car problem lead to this discussion related to Embedded Software Development.
This post was made in another thread in the "General Engineering" forum in a thread related to automobiles:
An automobile "Electronic Control Unit" (ECU) is an embedded computer processor module responsible for all sorts of data management chores in modern cars. Each manufacturer is responsible for selecting and/or designing the ECU for each of their car models. These units run highly customized software and may or may not use an "off-the-shelf" "Real-Time Operating System" (RTOS).
In the US (and many other countries), the ECU software must be developed under "MISRA" standards.
Personally, I have never programmed an ECU, but I have done a lot of Software development work on automotive radar units.
For that unit, the RTOS was kind of a starter kit. The developers would supply scores and scores of pages of parameters, and the package would generate source code for an RTOS finely tuned to what we would be needing. As a member of the "core" group, if we found a problem in the generated code, we would fix it. There were about eight of us working on this for roughly 5 years. For the most part, issues with the RTOS were resolved within the first 12 months. After that, there were rare changes in response to things like the electronic interface to the rest of the car.
These radar units sold in the tens of millions of units - so "Non-recurring Engineer" (NRE) costs were not a major obstacle.
I don't know if there is any one ECU that is used in as many cars as this radar (Veoneer).
In general, embedded software has the potential for being very reliable. In many cases, the OS is simply too small to hide major surprises. And in most cases, the support for the application has a very limited and predictable scope that allows for thorough testing.
So, if your car needs to "recover" from a dead electrical system, it was likely a deliberate management/engineering decision.
DaveE said:Software. A reliable RTOS is a myth ASFAIK. The exception is if it cost as much as what they put in an F-18 and such. We simply don't pay enough to get really good SW in our cars.
An automobile "Electronic Control Unit" (ECU) is an embedded computer processor module responsible for all sorts of data management chores in modern cars. Each manufacturer is responsible for selecting and/or designing the ECU for each of their car models. These units run highly customized software and may or may not use an "off-the-shelf" "Real-Time Operating System" (RTOS).
In the US (and many other countries), the ECU software must be developed under "MISRA" standards.
Personally, I have never programmed an ECU, but I have done a lot of Software development work on automotive radar units.
For that unit, the RTOS was kind of a starter kit. The developers would supply scores and scores of pages of parameters, and the package would generate source code for an RTOS finely tuned to what we would be needing. As a member of the "core" group, if we found a problem in the generated code, we would fix it. There were about eight of us working on this for roughly 5 years. For the most part, issues with the RTOS were resolved within the first 12 months. After that, there were rare changes in response to things like the electronic interface to the rest of the car.
These radar units sold in the tens of millions of units - so "Non-recurring Engineer" (NRE) costs were not a major obstacle.
I don't know if there is any one ECU that is used in as many cars as this radar (Veoneer).
In general, embedded software has the potential for being very reliable. In many cases, the OS is simply too small to hide major surprises. And in most cases, the support for the application has a very limited and predictable scope that allows for thorough testing.
So, if your car needs to "recover" from a dead electrical system, it was likely a deliberate management/engineering decision.