Computers in vehicles are more or less designed to do one thing and one thing only. If you're making a machine that only does one thing, it's relatively simple to optimize. Some times, it's such a...
Computers in vehicles are more or less designed to do one thing and one thing only. If you're making a machine that only does one thing, it's relatively simple to optimize. Some times, it's such a simple task they don't even bother using a full processor, they just create an application-specific integrated circuit - an ASIC - that has it's functionality built in.
Home computers don't have that luxury. They are general purpose machines. In other words, they can be made to do anything. It's actually more impressive than that; they are designed to use hardware and software that the designers and engineers who make them don't even know about. And because of that, there are too many possibilities for anyone to even imagine, let alone make accommodations for. That's why you have gigabytes of RAM and an operating system that takes up several gigabytes of storage. The computers in your car have storage and memory measured in kilobytes and often don't have any form of operating system whatsoever.
I think what you write here will be less and less true with more modern cars. For an engine control unit or the basic computers we had in cars a decade ago, sure. But a modern car has so many...
I think what you write here will be less and less true with more modern cars. For an engine control unit or the basic computers we had in cars a decade ago, sure. But a modern car has so many computers with so many different things running on them - heck, basically every component of the car is computerized at this point, or at least sends telemetry to a computer.
With that much going on, I highly doubt they use ASICs. I also doubt they stick to the kilobytes of RAM / no OS model that purely embedded systems go for. The entertainment system in your car surely has something that can be regarded as an OS, even if you can't buy it for your PC.
That said, the fact that hardware is known ahead of time, probably some architectural choices to firewall the engine from failures of the entertainment system, that kinda thing, should keep this computer from bricking your car. And then you network the entertainment system and patch it if it breaks. The manufacturer can do that, because any failure should not be specific to your setup (because your car is identical to all others of the same model)
Also, and this is likely mandated by regulatory agencies: I would guess that a lot of extra testing goes into anything security critical, compared to a PC OS.
You’re pretty much right, actually; modern cars are far more computerized and complex than they used to be. But I wanted to provide a simple and essential answer without filling in a ton of...
You’re pretty much right, actually; modern cars are far more computerized and complex than they used to be. But I wanted to provide a simple and essential answer without filling in a ton of details.
So yes, it’s more common for these controller chips running an OS, but generally it’ll be running an RTOS or Real Time Operating System. The big difference is that an RTOS is extremely bare bones and is designed to work in real time. Multitasking may be possible, but not always, and you can still have things happen instantaneously. An RTOS is less of an operating system and more like a framework that you develop your software on. You can still run an RTOS on a tiny microcontroller with a few KB of RAM. One of the big reasons you would want to use an RTOS is because you want to network your controller with a CAN bus or something like that, because modern cars still use a ton of separate controllers rather than one big CPU.
I’m no authority on this, so anyone who actually has in-depth domain knowledge on automotive technology, please chime in and correct anything that I mischaracterize. The computers that are part of...
I’m no authority on this, so anyone who actually has in-depth domain knowledge on automotive technology, please chime in and correct anything that I mischaracterize.
The computers that are part of the actual mechanical operation of cars, going back to the introduction of computer controlled functions—fuel injection, anti-lock brakes, power steering, etc.—aren’t fundamentally different than those in your laptop. What separates them most significantly, to wit, are the complexity of the systems they interact with and the software they run. They run so-called real-time OSes. This is a starkly different paradigm to regular OSes that human users interact with. Those take on a lot of a different kind of complexity in that they are intended to afford users the ability to run all kinds of other softwares, under myriad different configurations of hardware and other constraints determined by different users and environments.
The possible state-spaces that modern personal computers encompass is very vast. It’s impossible for software designers to fathom all the possibilities and test for them. By comparison the systems in your car have a much smaller (though still nontrivial, and ever growing) state-space.
I’d say this is the fundamental distinction that separates personal computers from the single-purpose ones that drive your car’s various systems.
There are likely similar systems in your laptop or cell phone to those in your car that you don’t directly interact with (if you own such devices): the power management controller, the SDD controller, the Wi-Fi/cellular radio controllers, etc. Those are similar to the systems in your car in that they are much simpler computers that run much simpler software.
As automotive technology increases in complexity, though, I think things may be changing. I think the complexity of the totality of the computerized systems in a new Tesla are getting to the point that the reliability of those systems is going to start to be impacted by the same lack of ability for software engineers to fully test the state-spaces. And the “ship now, patch later” mentality that is enabled by over-the-air software updates to newer cars is worrying. The very basic functions, though, should still be more reliable than what runs on general-purpose platforms.
A lot of it just comes down to requirements engineering. Automotive ECUs are required to have higher reliability than desktop CPUs, so they are designed that way. Just as an example, they use...
A lot of it just comes down to requirements engineering. Automotive ECUs are required to have higher reliability than desktop CPUs, so they are designed that way. Just as an example, they use fault-tolerant communication protocols that can operate in high noise environments like CAN bus and write code to standards like MISRA. RTOS is also a big one — everything needs to be deterministic such that you can guarantee response windows for things like assisted braking and the like.
Ohhh, that's an interesting point. You can always reduce the things you need to consider for your piece of code. Even just eliminating parallel/concurrent processing simplifies things a lot, but...
Ohhh, that's an interesting point. You can always reduce the things you need to consider for your piece of code. Even just eliminating parallel/concurrent processing simplifies things a lot, but that's not something we want to give up in the desktop space.
Usually yea, the simpler the better. It’s been a while since I’ve worked with an RTOS but most of them do have a scheduler and tasks but they are all using co-operative yielding and priority...
Usually yea, the simpler the better. It’s been a while since I’ve worked with an RTOS but most of them do have a scheduler and tasks but they are all using co-operative yielding and priority levels IIRC.
Even things as simple as heap allocation are not used. Everything in safety critical software is stack allocated on startup. Heap allocation introduces some level of non-determinism when you request a block of memory — how big is it, how fragmented is the heap and do we need to do some shuffling around etc. I think some places will maybe stack allocate pools and write deterministic allocators (don’t know what these would look like tbh) but mostly it was a strict avoidance of malloc and equivalents.
But then again if Intel can guarantee fulfilling the amount needed the reliability of no delays in production due to needing to switch chips could win out. Let alone the cost of redesigning things...
But then again if Intel can guarantee fulfilling the amount needed the reliability of no delays in production due to needing to switch chips could win out. Let alone the cost of redesigning things to work with a new chip.
It's probably down to Intel offering to design custom variants of their processors for cheap rather than a low cost per unit. Even for a large company developing custom silicon would be a big expense.
It's probably down to Intel offering to design custom variants of their processors for cheap rather than a low cost per unit. Even for a large company developing custom silicon would be a big expense.
Especially in that era, ECUs were custom silicon as general purpose microcontrollers weren't capable enough. My mid 2000s ford has an Intel chip that ford commissioned called the Intel 8065, it...
Especially in that era, ECUs were custom silicon as general purpose microcontrollers weren't capable enough.
My mid 2000s ford has an Intel chip that ford commissioned called the Intel 8065, it has different hardware to allow them to optimise it for the code they intended to run. (How crazy is that?).
Because creating large application specific silicon is extremely expensive (only very large companies could afford it), the entire chip and it's code have been reverse engineered. Because there was no cheaper way for the public to get ahold of computers capable of running engines.
Nowadays there is something of a revolution happening because general purpose microcontrollers have become very fast and easy to program. Open source engine management software running on extremely cheap microcontrollers is on the horizon.
From these answers, it sounds like automotive computers are more stable than personal computers because they are single purpose (or limited/known purpose). Does the same description apply to...
From these answers, it sounds like automotive computers are more stable than personal computers because they are single purpose (or limited/known purpose). Does the same description apply to computers in airlines? Or are there differences?
I know near to nothing about the hardware aspect. From software perspective, they are very similar. Airborne software is normally made to satisfy safety criteria specified by DO-178B / DO-178C....
I know near to nothing about the hardware aspect.
From software perspective, they are very similar. Airborne software is normally made to satisfy safety criteria specified by DO-178B / DO-178C.
Automotive follows a similar norm, I believe IEC 61508.
All that said, I have some limited experience with airborne software testing, and one of my senior co-workers there had had automotive background. In his opinion, both standards were pretty similar on paper. At the same time, the methods and processes used by airborne industry were ancient and more suitable to the electrical engineering, not software development.
Computers in vehicles are more or less designed to do one thing and one thing only. If you're making a machine that only does one thing, it's relatively simple to optimize. Some times, it's such a simple task they don't even bother using a full processor, they just create an application-specific integrated circuit - an ASIC - that has it's functionality built in.
Home computers don't have that luxury. They are general purpose machines. In other words, they can be made to do anything. It's actually more impressive than that; they are designed to use hardware and software that the designers and engineers who make them don't even know about. And because of that, there are too many possibilities for anyone to even imagine, let alone make accommodations for. That's why you have gigabytes of RAM and an operating system that takes up several gigabytes of storage. The computers in your car have storage and memory measured in kilobytes and often don't have any form of operating system whatsoever.
I think what you write here will be less and less true with more modern cars. For an engine control unit or the basic computers we had in cars a decade ago, sure. But a modern car has so many computers with so many different things running on them - heck, basically every component of the car is computerized at this point, or at least sends telemetry to a computer.
With that much going on, I highly doubt they use ASICs. I also doubt they stick to the kilobytes of RAM / no OS model that purely embedded systems go for. The entertainment system in your car surely has something that can be regarded as an OS, even if you can't buy it for your PC.
That said, the fact that hardware is known ahead of time, probably some architectural choices to firewall the engine from failures of the entertainment system, that kinda thing, should keep this computer from bricking your car. And then you network the entertainment system and patch it if it breaks. The manufacturer can do that, because any failure should not be specific to your setup (because your car is identical to all others of the same model)
Also, and this is likely mandated by regulatory agencies: I would guess that a lot of extra testing goes into anything security critical, compared to a PC OS.
You’re pretty much right, actually; modern cars are far more computerized and complex than they used to be. But I wanted to provide a simple and essential answer without filling in a ton of details.
So yes, it’s more common for these controller chips running an OS, but generally it’ll be running an RTOS or Real Time Operating System. The big difference is that an RTOS is extremely bare bones and is designed to work in real time. Multitasking may be possible, but not always, and you can still have things happen instantaneously. An RTOS is less of an operating system and more like a framework that you develop your software on. You can still run an RTOS on a tiny microcontroller with a few KB of RAM. One of the big reasons you would want to use an RTOS is because you want to network your controller with a CAN bus or something like that, because modern cars still use a ton of separate controllers rather than one big CPU.
I’m no authority on this, so anyone who actually has in-depth domain knowledge on automotive technology, please chime in and correct anything that I mischaracterize.
The computers that are part of the actual mechanical operation of cars, going back to the introduction of computer controlled functions—fuel injection, anti-lock brakes, power steering, etc.—aren’t fundamentally different than those in your laptop. What separates them most significantly, to wit, are the complexity of the systems they interact with and the software they run. They run so-called real-time OSes. This is a starkly different paradigm to regular OSes that human users interact with. Those take on a lot of a different kind of complexity in that they are intended to afford users the ability to run all kinds of other softwares, under myriad different configurations of hardware and other constraints determined by different users and environments.
The possible state-spaces that modern personal computers encompass is very vast. It’s impossible for software designers to fathom all the possibilities and test for them. By comparison the systems in your car have a much smaller (though still nontrivial, and ever growing) state-space.
I’d say this is the fundamental distinction that separates personal computers from the single-purpose ones that drive your car’s various systems.
There are likely similar systems in your laptop or cell phone to those in your car that you don’t directly interact with (if you own such devices): the power management controller, the SDD controller, the Wi-Fi/cellular radio controllers, etc. Those are similar to the systems in your car in that they are much simpler computers that run much simpler software.
As automotive technology increases in complexity, though, I think things may be changing. I think the complexity of the totality of the computerized systems in a new Tesla are getting to the point that the reliability of those systems is going to start to be impacted by the same lack of ability for software engineers to fully test the state-spaces. And the “ship now, patch later” mentality that is enabled by over-the-air software updates to newer cars is worrying. The very basic functions, though, should still be more reliable than what runs on general-purpose platforms.
A lot of it just comes down to requirements engineering. Automotive ECUs are required to have higher reliability than desktop CPUs, so they are designed that way. Just as an example, they use fault-tolerant communication protocols that can operate in high noise environments like CAN bus and write code to standards like MISRA. RTOS is also a big one — everything needs to be deterministic such that you can guarantee response windows for things like assisted braking and the like.
Ohhh, that's an interesting point. You can always reduce the things you need to consider for your piece of code. Even just eliminating parallel/concurrent processing simplifies things a lot, but that's not something we want to give up in the desktop space.
Usually yea, the simpler the better. It’s been a while since I’ve worked with an RTOS but most of them do have a scheduler and tasks but they are all using co-operative yielding and priority levels IIRC.
Even things as simple as heap allocation are not used. Everything in safety critical software is stack allocated on startup. Heap allocation introduces some level of non-determinism when you request a block of memory — how big is it, how fragmented is the heap and do we need to do some shuffling around etc. I think some places will maybe stack allocate pools and write deterministic allocators (don’t know what these would look like tbh) but mostly it was a strict avoidance of malloc and equivalents.
I’ll add this anecdote. I disassembled a honda ecu from the mid 90’s and found an intel 386 in there.
Wow, I can't even imagine what the engineers were thinking with that. Intel chips are extremely expensive.
Cars are extremely expensive. Few CPUs would even make a dent.
Mass production doesn’t work like that. Shaving a few dollars on a part or a few seconds on some automation process make a difference in the long run.
But then again if Intel can guarantee fulfilling the amount needed the reliability of no delays in production due to needing to switch chips could win out. Let alone the cost of redesigning things to work with a new chip.
It's probably down to Intel offering to design custom variants of their processors for cheap rather than a low cost per unit. Even for a large company developing custom silicon would be a big expense.
Especially in that era, ECUs were custom silicon as general purpose microcontrollers weren't capable enough.
My mid 2000s ford has an Intel chip that ford commissioned called the Intel 8065, it has different hardware to allow them to optimise it for the code they intended to run. (How crazy is that?).
Because creating large application specific silicon is extremely expensive (only very large companies could afford it), the entire chip and it's code have been reverse engineered. Because there was no cheaper way for the public to get ahold of computers capable of running engines.
Nowadays there is something of a revolution happening because general purpose microcontrollers have become very fast and easy to program. Open source engine management software running on extremely cheap microcontrollers is on the horizon.
From these answers, it sounds like automotive computers are more stable than personal computers because they are single purpose (or limited/known purpose). Does the same description apply to computers in airlines? Or are there differences?
I know near to nothing about the hardware aspect.
From software perspective, they are very similar. Airborne software is normally made to satisfy safety criteria specified by DO-178B / DO-178C.
Automotive follows a similar norm, I believe IEC 61508.
All that said, I have some limited experience with airborne software testing, and one of my senior co-workers there had had automotive background. In his opinion, both standards were pretty similar on paper. At the same time, the methods and processes used by airborne industry were ancient and more suitable to the electrical engineering, not software development.