Ask HN: Risk of unsafe software in automobiles?
131 comments
Your link of Sudden unintended acceleration contains a lot of entries related to this issue which don't involve computers at all. It lists pedal misapplication, entrapped pedals, stuck throttles, electrical shorts, and diesel engine runaway as other things which can cause such an issue. A lot of the reported incidents had nothing to do with software.
Either way, if you've had a fuel injected car you were still exposed to these issues. You would have to go buy a carbureted engine from the 80s or before to get away from these "unintended acceleration" issues, as in the end a car with EFI probably has a computer actually controlling the injection. I'd be way more wary of daily driving an 80s or older car from a general safety standpoint than a software issue. You're way more likely to be t-boned at an intersection than a software glitch causing an accident; having a much more modern car will help from a crash safety standpoint than having a carburetor.
There's a ton of things that can go wrong in a car which can cause an accident. The software stack is surely one of those things, but even a 100% mechanical car can have a lot of failures as well. Ever have vacuum hoses fail on an old car? Carburetors get stuck or clogged? Personally, I'd prefer a computer controlling components directly instead of tons of vacuum lines and springs trying to keep things tuned right. On top of that I'll also get much better efficiency and reduce harmful emissions which hurt my family and my neighbors.
Either way, if you've had a fuel injected car you were still exposed to these issues. You would have to go buy a carbureted engine from the 80s or before to get away from these "unintended acceleration" issues, as in the end a car with EFI probably has a computer actually controlling the injection. I'd be way more wary of daily driving an 80s or older car from a general safety standpoint than a software issue. You're way more likely to be t-boned at an intersection than a software glitch causing an accident; having a much more modern car will help from a crash safety standpoint than having a carburetor.
There's a ton of things that can go wrong in a car which can cause an accident. The software stack is surely one of those things, but even a 100% mechanical car can have a lot of failures as well. Ever have vacuum hoses fail on an old car? Carburetors get stuck or clogged? Personally, I'd prefer a computer controlling components directly instead of tons of vacuum lines and springs trying to keep things tuned right. On top of that I'll also get much better efficiency and reduce harmful emissions which hurt my family and my neighbors.
> It lists pedal misapplication, entrapped pedals, stuck throttles, electrical shorts, and diesel engine runaway as other things which can cause such an issue.
And modern cars are much better at handling these types of scenarios. For example, in my late model car, if you apply the accelerator and brake at the same time, the vehicle will ignore the accelerator input. This solves two potential problems from the past: someone accidentally stomping on both pedals when they meant to hit the brake, and a foreign object wedging the accelerator pedal down.
And modern cars are much better at handling these types of scenarios. For example, in my late model car, if you apply the accelerator and brake at the same time, the vehicle will ignore the accelerator input. This solves two potential problems from the past: someone accidentally stomping on both pedals when they meant to hit the brake, and a foreign object wedging the accelerator pedal down.
> someone accidentally stomping on both pedals when they meant to hit the brake
This happens to me (sometimes) in parking lots where pedestrians walk between cars. Mine (2019 Mazda Miata) does not do this, instead I get an engine rev while standing half on brakes, half on accelerator, full on clutch. I end up feeling embarrassed as I tend to get glared at by the pedestrian (no, I did not intentionally rev it to scare you).
This happens to me (sometimes) in parking lots where pedestrians walk between cars. Mine (2019 Mazda Miata) does not do this, instead I get an engine rev while standing half on brakes, half on accelerator, full on clutch. I end up feeling embarrassed as I tend to get glared at by the pedestrian (no, I did not intentionally rev it to scare you).
I'm glad that's not the behavior on a manual Miata, that would totally kill the prospects of heel-toe downshifting. ;)
Wait what? You drive a manual and use the left foot to hit the brakes? Recipe for disaster.
Nah, their left is full on clutch, their right foot is between the accelerator and brake pressing both at the same time.
Correct. Left foot on the clutch as I was (in every one of these situations) backing out slowly. Then I see the pedestrian, lift foot off the gas and jam it on the brake. I guess, in my panic, I don't move the right foot far enough to the left (to get it fully off the gas pedal).
This is part of why I hate nose-in parking.
This is part of why I hate nose-in parking.
Yeah; my VW Golf does that. Makes it hard to warm up the brakes in icy/condensing weather.
> Either way, if you've had a fuel injected car you were still exposed to these issues.
I don't think unintended acceleration with cable operated throttles was ever much of an issue. The simpler EFI systems of the 80s and 90s were very robust with predictable failure modes. We've certainly bought a lot in terms of safety and efficiency with the newer designs, but their complexity also means problems can be more obscure and more likely to sneak their way to market.
Anecdote: My 01 Volvo had weird/dangerous intermittent acceleration, but had a fully computerized throttle. The software got confused by a failing throttle position sensor. The best fix is to replace it with a hall effect sensor that doesn't wear out.
I don't think unintended acceleration with cable operated throttles was ever much of an issue. The simpler EFI systems of the 80s and 90s were very robust with predictable failure modes. We've certainly bought a lot in terms of safety and efficiency with the newer designs, but their complexity also means problems can be more obscure and more likely to sneak their way to market.
Anecdote: My 01 Volvo had weird/dangerous intermittent acceleration, but had a fully computerized throttle. The software got confused by a failing throttle position sensor. The best fix is to replace it with a hall effect sensor that doesn't wear out.
Most EFI still has a mechanical throttle, so if there is a glitch in the EFI it can’t possibly cause unintended acceleration. Only fairly new cars now have electronic throttle that could potentially accelerate the engine due to a software glitch.
"Most" may vary by locale at this point. At least here in the US, automakers started migrating to throttle-by-wire in the 00s.
My early-2000s Japanese car was throttle-by-wire.
Yeah yeah, we had to get ECUs because of "problems". It's like how the terrible half working google captcha I get here for signing up with Tor is because "AI breaks text now". In reality it's just a bunch of lazy people going with the flow.
> reduce harmful emissions which hurt my family and my neighbors.
If there was a true problem it could be solved by having less kids. Why do you end your sentence with this dipshit way of arguing? Nobody falls for that. Of course we all know the game here is for someone to call you out being a passive aggressive dipshit and play the victim once that happens.
> reduce harmful emissions which hurt my family and my neighbors.
If there was a true problem it could be solved by having less kids. Why do you end your sentence with this dipshit way of arguing? Nobody falls for that. Of course we all know the game here is for someone to call you out being a passive aggressive dipshit and play the victim once that happens.
>There's a ton of things that can go wrong in a car which can cause an accident.
And pretty much none of them ever do if the driver doesn't react exceptionally poorly. Even the spectacular stuff that the internet absolutely loves to hand wring about, like a wheel falling off for whatever reason, almost always results in the car coming to a controlled stop on the side of the road. The conversion rate between "failures" and "meaningful harm to anyone or anything is abysmal."
And pretty much none of them ever do if the driver doesn't react exceptionally poorly. Even the spectacular stuff that the internet absolutely loves to hand wring about, like a wheel falling off for whatever reason, almost always results in the car coming to a controlled stop on the side of the road. The conversion rate between "failures" and "meaningful harm to anyone or anything is abysmal."
That’s true now, because most of the critical systems have redundancy. I wouldn’t want to drive a vehicle with one brake circuit and no throttle return spring, though. It has been a very long time since that was the case, but those days are probably where the mechanical failure horror stories come from.
Agreed. The biggest component failure leading to injuries is by far the one in the driver's seat.
Either way, if you've had a fuel injected car you were still exposed to these issues. You would have to go buy a carbureted engine from the 80s or before to get away from these "unintended acceleration" issues, as in the end a car with EFI probably has a computer actually controlling the injection.
Even with EFI, if the throttle is mechanical and the EFI continues to ask for more fuel for whatever reason (or a fuel injector gets stuck open), all that will happen is the engine will stall due to the excessively rich mixture.
Ever have vacuum hoses fail on an old car? Carburetors get stuck or clogged?
The normal failure mode of a carburetor leads to an engine that doesn't run, and not the opposite. Before complete failure, you will notice a performance decline.
Personally, I prefer no computer control.
On top of that I'll also get much better efficiency and reduce harmful emissions which hurt my family and my neighbors
You can get a lot better efficiency from a carbureted engine than most people think.
As for safety, I'd rather have freedom.
Even with EFI, if the throttle is mechanical and the EFI continues to ask for more fuel for whatever reason (or a fuel injector gets stuck open), all that will happen is the engine will stall due to the excessively rich mixture.
Ever have vacuum hoses fail on an old car? Carburetors get stuck or clogged?
The normal failure mode of a carburetor leads to an engine that doesn't run, and not the opposite. Before complete failure, you will notice a performance decline.
Personally, I prefer no computer control.
On top of that I'll also get much better efficiency and reduce harmful emissions which hurt my family and my neighbors
You can get a lot better efficiency from a carbureted engine than most people think.
As for safety, I'd rather have freedom.
> if the throttle is mechanical
If the throttle is mechanical. So yeah, I guess there's a window of time there where EFI became the norm but before throttles were also electronic, so late 80s to early 2000s. I imagine the majority of cars on the road today in the US are fully electronic.
> The normal failure mode of a carburetor leads to an engine that doesn't run, and not the opposite.
I've personally experienced carburetors getting stuck open, usually on abused/unmaintained lawn equipment. I do agree the usual failure is that it gets gummed up and inefficient in its atomization, but a stuck open carb isn't impossible. Either way, a carb that fails and you suddenly lose power can also cause problems when unexpected.
> You can get a lot better efficiency from a carbureted engine than most people think.
Yeah, a well-tuned and well-maintained carburetor isn't absolutely horrific in efficiency. But it'll still pale in comparison to the combustion efficiency that can be had in a GDI engine.
> As for safety, I'd rather have freedom.
Cool, and feel free to drive that freedom car in your freedom yard. Please keep your freedom emissions in your freedom air though instead of polluting your neighbors. When you're driving on the public streets there's more than just you out there.
If the throttle is mechanical. So yeah, I guess there's a window of time there where EFI became the norm but before throttles were also electronic, so late 80s to early 2000s. I imagine the majority of cars on the road today in the US are fully electronic.
> The normal failure mode of a carburetor leads to an engine that doesn't run, and not the opposite.
I've personally experienced carburetors getting stuck open, usually on abused/unmaintained lawn equipment. I do agree the usual failure is that it gets gummed up and inefficient in its atomization, but a stuck open carb isn't impossible. Either way, a carb that fails and you suddenly lose power can also cause problems when unexpected.
> You can get a lot better efficiency from a carbureted engine than most people think.
Yeah, a well-tuned and well-maintained carburetor isn't absolutely horrific in efficiency. But it'll still pale in comparison to the combustion efficiency that can be had in a GDI engine.
> As for safety, I'd rather have freedom.
Cool, and feel free to drive that freedom car in your freedom yard. Please keep your freedom emissions in your freedom air though instead of polluting your neighbors. When you're driving on the public streets there's more than just you out there.
Cool, and feel free to drive that freedom car in your freedom yard. Please keep your freedom emissions in your freedom air though instead of polluting your neighbors. When you're driving on the public streets there's more than just you out there.
Freedom includes doing things that others don't like --- and tolerating the opposite too. Otherwise you're just encouraging an authoritarian socialist dystopia.
Freedom includes doing things that others don't like --- and tolerating the opposite too. Otherwise you're just encouraging an authoritarian socialist dystopia.
> Freedom includes doing things that others don't like --- and tolerating the opposite too.
So I should tolerate people driving on public streets without insurance and without a license? I should tolerate people driving the wrong way on the highway? I should tolerate whatever emissions come from the tailpipe of someone's car? I should tolerate sompeone driving a car that nobody has touched the brakes on for a decade and they're about ready to fail at any moment? I should tolerate people driving at night without headlights on? I should tolerate people driving at any blood alcohol level?
All of these are laws which limit freedom in the name of safety. You're arguing you'd prefer freedom over safety. Personally, I prefer all of these tradeoffs of freedom over safety, at least when driving on public streets. If you don't like these regulations, don't drive on public streets.
Requiring a driver's license, having emissions controls, creating traffic standards for driving on public streets are examples authoritarian socialist dystopia I guess.
So I should tolerate people driving on public streets without insurance and without a license? I should tolerate people driving the wrong way on the highway? I should tolerate whatever emissions come from the tailpipe of someone's car? I should tolerate sompeone driving a car that nobody has touched the brakes on for a decade and they're about ready to fail at any moment? I should tolerate people driving at night without headlights on? I should tolerate people driving at any blood alcohol level?
All of these are laws which limit freedom in the name of safety. You're arguing you'd prefer freedom over safety. Personally, I prefer all of these tradeoffs of freedom over safety, at least when driving on public streets. If you don't like these regulations, don't drive on public streets.
Requiring a driver's license, having emissions controls, creating traffic standards for driving on public streets are examples authoritarian socialist dystopia I guess.
As far as I have understood, the previous commenter used to talk about FLOSS only (which is rather wise then not if you do value RMS' philosophy) and you have turned the discussion into absurd (kind of driving without license which has nothing to do with wiseness).
To me they brought it to that extreme when referencing authoritarian socialist dystopia when originally talking about carburetors. Hard to not see it going that direction about rights/freedoms when not having the ability to tune your carb means you're encouraging an authoritarian socialist dystopia.
It has been meant that there is no any car with FLOSS injector software. Every injector hardware devise has proprietary software. How on Earth can I drive an injector car if any proprietary software is not an option for me?
They weren't talking about FLOSS here. They weren't talking about free or proprietary software, they wanted no software
> Personally, I prefer no computer control.
They're not arguing for free software controlling their car, they're arguing for no software controlling the car. No software controlling the car means generally less safe cars with higher emissions on the road. Higher emissions hurt the people around them. Not having common safety systems like ABS and traction control make the cars harder to operate on normal roadways, leading to a higher likelihood of collisions.
They're arguing they should be free to operate less-safe cars which emit higher emissions on public roadways, and that everyone around should just accept it. Arguing otherwise is arguing for an authoritarian socialist dystopia.
> Personally, I prefer no computer control.
They're not arguing for free software controlling their car, they're arguing for no software controlling the car. No software controlling the car means generally less safe cars with higher emissions on the road. Higher emissions hurt the people around them. Not having common safety systems like ABS and traction control make the cars harder to operate on normal roadways, leading to a higher likelihood of collisions.
They're arguing they should be free to operate less-safe cars which emit higher emissions on public roadways, and that everyone around should just accept it. Arguing otherwise is arguing for an authoritarian socialist dystopia.
> no software controlling the car.
I understand that my opinion is heavily biased to RMS' philosophy, but if looking the facts, we can see that if the car (engine controller, ABS, comfort controller, pesky notifications about belts/weather/maintenance) would be controlled by FLOSS it is controlled by user (not manufacturer) de-facto. All the cons of software just disappear in FLOSS: if you don't like the pesky notifications or anything else - you just remove few lines from the source code, recompile and replace the binary in your car.
I really prefer driving carburetor Volga with no software goodies just because there is no any car which has a software which let me use the software instead of being used by it. And I really prefer absence of modern safety like ABS if the safety is controlled by software manufacturer only. I know that my car has significant higher emissions (not to mention efficiency and safety) and I am a big fan of global warming movement but all I can do is to use my car as little as possible because using proprietary software is bigger sin for me than to poison our planet.
> They're arguing they should be free to operate less-safe cars which emit higher emissions on public roadways
I also talk about this, but in a slightly different way.
I understand that my opinion is heavily biased to RMS' philosophy, but if looking the facts, we can see that if the car (engine controller, ABS, comfort controller, pesky notifications about belts/weather/maintenance) would be controlled by FLOSS it is controlled by user (not manufacturer) de-facto. All the cons of software just disappear in FLOSS: if you don't like the pesky notifications or anything else - you just remove few lines from the source code, recompile and replace the binary in your car.
I really prefer driving carburetor Volga with no software goodies just because there is no any car which has a software which let me use the software instead of being used by it. And I really prefer absence of modern safety like ABS if the safety is controlled by software manufacturer only. I know that my car has significant higher emissions (not to mention efficiency and safety) and I am a big fan of global warming movement but all I can do is to use my car as little as possible because using proprietary software is bigger sin for me than to poison our planet.
> They're arguing they should be free to operate less-safe cars which emit higher emissions on public roadways
I also talk about this, but in a slightly different way.
> And I really prefer absence of modern safety like ABS if the safety is controlled by software manufacturer only.
I'm really wondering where this mindset ends though. You're foregoing safety equipment which is proven to make you far safer on the roads because you can't access the firmware of the device. You're choosing a much older car with far worse safety designs because of this. How far would you take this idea? If you were seriously injured and in the hospital, would you refuse for the doctors to use machines which contain non-free software to save your life? Would you rather die than interface with non-free software?
Don't get me wrong, I'm a generally FOSS supporting person and agree with many of RMS' ideas surrounding software freedom. If there were two cars out there which were roughly the same, one with free software and one with closed, I'd pick the free software version. But in the end I value my family's safety far more than my opinion on free software, so it is an obvious choice to choose the safer car.
I'm really wondering where this mindset ends though. You're foregoing safety equipment which is proven to make you far safer on the roads because you can't access the firmware of the device. You're choosing a much older car with far worse safety designs because of this. How far would you take this idea? If you were seriously injured and in the hospital, would you refuse for the doctors to use machines which contain non-free software to save your life? Would you rather die than interface with non-free software?
Don't get me wrong, I'm a generally FOSS supporting person and agree with many of RMS' ideas surrounding software freedom. If there were two cars out there which were roughly the same, one with free software and one with closed, I'd pick the free software version. But in the end I value my family's safety far more than my opinion on free software, so it is an obvious choice to choose the safer car.
> which is proven to make you far safer on the roads because you can't access the firmware of the device.
I don't like the wording. ABS is safer not because I can not alter the firmware, it is safer on different reason.
> If you were seriously injured and in the hospital, would you refuse for the doctors to use machines which contain non-free software to save your life? Would you rather die than interface with non-free software?
I see benefits of this approach in learning: I do not want to learn any proprietary framework. I do not care about the doctor's software, he is free to learn anything.
I don't like the wording. ABS is safer not because I can not alter the firmware, it is safer on different reason.
> If you were seriously injured and in the hospital, would you refuse for the doctors to use machines which contain non-free software to save your life? Would you rather die than interface with non-free software?
I see benefits of this approach in learning: I do not want to learn any proprietary framework. I do not care about the doctor's software, he is free to learn anything.
Carbureted engines are significantly less fuel efficient than modern engines that use fuel injection systems. They're less precise; often times not able to fully burn all the fuel supplied.
Thoughts from my wife who has worked in electrical and software for OEM automakers (high volume, luxury sport and start up) for 10 years: (I’m typing while she is, ironically, driving our Volvo)
To answer your last question first, buy a car that hasn’t been launched within the last 12 to 18 months. That’s not software specific, that general vehicle safety across the board as they will be working through the initial warranty issues. So if you are looking at second hand and you know model ABC was launched 2016, don’t buy one made in the 2016/2017 period.
ISO 26262 rates every system on a critically rating, if they have a ASIL rating of C or D they have multiple back up systems in place. This falls under functional safety which is a newer (5 years or so) area targeting that cars are now highly complex interconnect systems linked with software - the idea being that you target specific subsystems to make sure their function isn’t totally taken out due to some failure or error in the wider system.
Cyber security wise there is an EU reg coming in from 2024 making sure that OTA updates are safe, reducing hacking attack vectors and the like. This is being introduced to new cars and designs as a result of the issues cited above.
As far as people hacking in via the infotainment to access the car control systems - there are firewalls between infotainment and primary car control to mitigate against that issue. There multiple networks in a single vehicle to isolate systems so that no one central unimportant system (infotainment for eg) can take out the whole vehicle.
Software in cars to this level is new, it’s evolving and it takes 7 or so years to create a new platform. This means there is a lag in the system, especially during this transitionary period.
However car makers take this stuff incredibly seriously and their software teams are absolutely not run in the same way as a lower consequence dev situation. Lives are on the line and the type of devs who work in this field know that.
Nothing is perfect but the safety downsides of an old car are widely considered to be far greater than the threat of hacking or bad code in a new car.
To answer your last question first, buy a car that hasn’t been launched within the last 12 to 18 months. That’s not software specific, that general vehicle safety across the board as they will be working through the initial warranty issues. So if you are looking at second hand and you know model ABC was launched 2016, don’t buy one made in the 2016/2017 period.
ISO 26262 rates every system on a critically rating, if they have a ASIL rating of C or D they have multiple back up systems in place. This falls under functional safety which is a newer (5 years or so) area targeting that cars are now highly complex interconnect systems linked with software - the idea being that you target specific subsystems to make sure their function isn’t totally taken out due to some failure or error in the wider system.
Cyber security wise there is an EU reg coming in from 2024 making sure that OTA updates are safe, reducing hacking attack vectors and the like. This is being introduced to new cars and designs as a result of the issues cited above.
As far as people hacking in via the infotainment to access the car control systems - there are firewalls between infotainment and primary car control to mitigate against that issue. There multiple networks in a single vehicle to isolate systems so that no one central unimportant system (infotainment for eg) can take out the whole vehicle.
Software in cars to this level is new, it’s evolving and it takes 7 or so years to create a new platform. This means there is a lag in the system, especially during this transitionary period.
However car makers take this stuff incredibly seriously and their software teams are absolutely not run in the same way as a lower consequence dev situation. Lives are on the line and the type of devs who work in this field know that.
Nothing is perfect but the safety downsides of an old car are widely considered to be far greater than the threat of hacking or bad code in a new car.
Follow up to this:
The one thing that could cause a lot of problems for cars and software is Agile/Scrum.
The projects that are being run in this, new for the industry way, are always late and people hate working on them.
CEOs and other C suite people see the massively shorter lead times that software can offer and are getting greedy. They saved a year or more of time on a feature thanks to code and over the air and then they decide they want it made in 4 weeks, when 3 months would be prudent.
There’s something about the intangibility of software that makes traditional automotive people’s brains break.
Thankfully many rank and file engineers and PMs in OEMs are pushing back against Scrum etc so a more pragmatic layer of management will come up in the coming years. Sadly Agile/Scrum will cause some preventable issues in the meantime.
Unlikely to be safety critical stuff due to the rounds of QA and safety council sign offs and gateways they need to go through. But less safety critical stuff may slip through.
The one thing that could cause a lot of problems for cars and software is Agile/Scrum.
The projects that are being run in this, new for the industry way, are always late and people hate working on them.
CEOs and other C suite people see the massively shorter lead times that software can offer and are getting greedy. They saved a year or more of time on a feature thanks to code and over the air and then they decide they want it made in 4 weeks, when 3 months would be prudent.
There’s something about the intangibility of software that makes traditional automotive people’s brains break.
Thankfully many rank and file engineers and PMs in OEMs are pushing back against Scrum etc so a more pragmatic layer of management will come up in the coming years. Sadly Agile/Scrum will cause some preventable issues in the meantime.
Unlikely to be safety critical stuff due to the rounds of QA and safety council sign offs and gateways they need to go through. But less safety critical stuff may slip through.
> There’s something about the intangibility of software
actually I see this break most managers' brains. In my experience it's been a constant pressuring to reduce scope such that the plans of the incompetent tend to be selected over those who know how to build great software with all the non-functional requirements in place (security, reliability, operability, modularity/flexibility etc) .
actually I see this break most managers' brains. In my experience it's been a constant pressuring to reduce scope such that the plans of the incompetent tend to be selected over those who know how to build great software with all the non-functional requirements in place (security, reliability, operability, modularity/flexibility etc) .
>> The one thing that could cause a lot of problems for cars and software is Agile/Scrum.
Nobody in the industry is doing Agile for safety critical systems. The development standards are getting such that writing automotive software is not fun any more, but that is the correct way to go.
Want to electronically open the frunk on an EV? That piece of hardware and software has a surprising level of safety concern. Because inadvertently opening the latch can kill someone.
You are correct to be concerned, but the industry is very much on top of things.
Nobody in the industry is doing Agile for safety critical systems. The development standards are getting such that writing automotive software is not fun any more, but that is the correct way to go.
Want to electronically open the frunk on an EV? That piece of hardware and software has a surprising level of safety concern. Because inadvertently opening the latch can kill someone.
You are correct to be concerned, but the industry is very much on top of things.
Cybersecurity is relatively new to the industry in a formal sense. I worked on helping the industry define SAE J3061 as detailed here. https://www.sae.org/standards/content/j3061_201601/
ISO 21434 came out a few years later. https://www.iso.org/standard/70918.html
This was all kicked off after the Jeep Hack. https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...
Overall the people in the field working on security these days seem to be excellent to me. They have crypto experts, kernel experts, and pretty good standards.
Before the Jeep Hack, they still took it seriously, but it was a lot of roll your own crypto types, and they didn't really know what they were doing.
Since then all the automotive companies hired and purchased companies from the traditional Cyber area and have trained up hybrid automotive and cybersecurity experts.
They still aren't perfect, but nobody really is, but cars these days have pretty cool tech in them.
If you are worried I'd recommend trying to hack your own car. You can learn a lot from it, and there are a lot of cool things you can do. In my experience, nothing alleviates fear better than a deep dive into a subject.
comma.ai for example have built an open source self-driving platform from hacking on the internals of vehicles. https://comma.ai/
ISO 21434 came out a few years later. https://www.iso.org/standard/70918.html
This was all kicked off after the Jeep Hack. https://www.wired.com/2015/07/hackers-remotely-kill-jeep-hig...
Overall the people in the field working on security these days seem to be excellent to me. They have crypto experts, kernel experts, and pretty good standards.
Before the Jeep Hack, they still took it seriously, but it was a lot of roll your own crypto types, and they didn't really know what they were doing.
Since then all the automotive companies hired and purchased companies from the traditional Cyber area and have trained up hybrid automotive and cybersecurity experts.
They still aren't perfect, but nobody really is, but cars these days have pretty cool tech in them.
If you are worried I'd recommend trying to hack your own car. You can learn a lot from it, and there are a lot of cool things you can do. In my experience, nothing alleviates fear better than a deep dive into a subject.
comma.ai for example have built an open source self-driving platform from hacking on the internals of vehicles. https://comma.ai/
For those interested, the EU standard mentioned here is the the UN standard 156.
https://unece.org/transport/documents/2021/03/standards/un-r...
The industry has also recently seen the introduction of ISO21434, cybersecurity engineering standard for road vehicles.
The industry has also recently seen the introduction of ISO21434, cybersecurity engineering standard for road vehicles.
Nothing is perfect but the safety downsides of an old car are widely considered to be far greater than the threat of hacking or bad code in a new car.
"widely considered" by the same industry who would love to sell you a new car...
"widely considered" by the same industry who would love to sell you a new car...
I take your point but my definition of new in this case is "something under 4 years old or so" - basically a newer car. So you can totally buy a second hand car.
> Lives are on the line and the type of devs who work in this field know that.
That wasn't enough to prevent the Uconnect disaster of a bug that only existed because they sold out on two occasions: when ECUs were invented (green and performance marketing), when smart crap was bundled into cars (smart being a word that universally means ostensibly convenient but in practice even layman consumers hate it).
That wasn't enough to prevent the Uconnect disaster of a bug that only existed because they sold out on two occasions: when ECUs were invented (green and performance marketing), when smart crap was bundled into cars (smart being a word that universally means ostensibly convenient but in practice even layman consumers hate it).
No amount of MISRA or ISO26262 or tests or any kind will help if the people doing the software are direct out-of-the-university mechanical engineers or physicist, who had at most one or two semesters of some kind of programming course.
The reality is that this is the current state of affairs. Most of people doing software for cars have not the foggiest idea what software is really about.
All the software I read is just impossible to understand. And no standard help in many cases.
Some examples I've seen in code: - Use of kind of hungarian notation to the point that a loop variable was named something like "uibe32bb_i_lns" - Comments in other human languages that were not english - Use of recursion - Have seen a call like name1::name2::name3::name4::name5::name6::name7::name8::name9::name10::name11::name12::name13::name14. The names where some kind of hungarian notation, those calls where everywhere in the code. - Lines more than 1000 characters wide, as a rule - Files north of 100kB of code I can go on and on and on....
Some examples of exchanges with people:
1) Software architect, of a ECU: one programer asks for the memory and CPU budget for a function. The reply was "I'm the architect, I've no idea what you are talking about"
2) System chief architect, for a very important project of a big auto-maker: one engineer says something about software errors. The architect interrupts, and explains that the software never makes an error. Because a computer only does what it is told to make. -- that is terrible enough, for example ignoring the possibility or a SEU, but he goes further, to say that any kind of test is not necessary, because, SW, as stated, makes no errors.
Some general points: - 99% of people in "SW" do not know what gdb is. They debug by "cout <<" - I found nobody who knows what tail recursion is - 90% are only able to program, to some extent, in one of C++ or Python, but no other language. - Mentioning Ada, Lisp, Forth will trigger a waterfall of insults saying those are old and should never be used.
I keep buying the most basic cars. I'm genuinely terrified to think in anything automatic in my car.
The reality is that this is the current state of affairs. Most of people doing software for cars have not the foggiest idea what software is really about.
All the software I read is just impossible to understand. And no standard help in many cases.
Some examples I've seen in code: - Use of kind of hungarian notation to the point that a loop variable was named something like "uibe32bb_i_lns" - Comments in other human languages that were not english - Use of recursion - Have seen a call like name1::name2::name3::name4::name5::name6::name7::name8::name9::name10::name11::name12::name13::name14. The names where some kind of hungarian notation, those calls where everywhere in the code. - Lines more than 1000 characters wide, as a rule - Files north of 100kB of code I can go on and on and on....
Some examples of exchanges with people:
1) Software architect, of a ECU: one programer asks for the memory and CPU budget for a function. The reply was "I'm the architect, I've no idea what you are talking about"
2) System chief architect, for a very important project of a big auto-maker: one engineer says something about software errors. The architect interrupts, and explains that the software never makes an error. Because a computer only does what it is told to make. -- that is terrible enough, for example ignoring the possibility or a SEU, but he goes further, to say that any kind of test is not necessary, because, SW, as stated, makes no errors.
Some general points: - 99% of people in "SW" do not know what gdb is. They debug by "cout <<" - I found nobody who knows what tail recursion is - 90% are only able to program, to some extent, in one of C++ or Python, but no other language. - Mentioning Ada, Lisp, Forth will trigger a waterfall of insults saying those are old and should never be used.
I keep buying the most basic cars. I'm genuinely terrified to think in anything automatic in my car.
In their defense, gdb is a pain in the ass to use if your editor doesn't come with integrated support. The debugger that comes with CLion/Visual Studio is perfectly adequate. Ada is useful for automotive. Lisp and Forth, not so much (especially since Lisp isn't usually used in hard real-time applications). This isn't the 1980s, MCUs aren't that memory constrained. Knowledge of obscure programming languages doesn't necessarily make you a better software engineer. I want my
automotive embedded engineer to have a solid grasp of computer architecture, real-time safety protocols, and defensive programming. I don't see a problem with a Korean/Japanese car manufacturer having their documentation in a non-English language. As long as they do everything in-house and don't outsource to India like Boeing I have no problem with it.
> In their defense, gdb is a pain in the ass to use if your editor doesn't come with integrated support. The debugger that comes with CLion/Visual Studio is perfectly adequate.
I meant, they do not know what a debugger is. As stated, they use "cout << "At line 26, after call to xx" as debugging tool. For gdb there are plenty of python extensions, and GUIs, even web front-end, that are not bad... but it may be difficult for some people, I understand that.
> Ada is useful for automotive. Lisp and Forth, not so much (especially since Lisp isn't usually used in hard real-time applications). This isn't the 1980s, MCUs aren't that memory constrained.
Well, first, they do not have the foggiest idea what Ada is. That is my problem. Once somebody suggested we should look into it, for L4 autonomous driving. He was laugh at, and it was said "it is a dead language from the 60, like Cobol or Fortran, nobody has used it in 50 years, there are no compilers for it!!!". I've seen forth being used in some 8-bit uC in the automotive industry still. Now is 99% gone, but was very much used. Lisp, can be used in hard real-time. BTW another thing always hanging around is the "hard real-time" for automotive. It is interesting, because other than for airbags, ignition and injection, you are talking about 100ms response times, which can be achieved very easily.
> Knowledge of obscure programming languages doesn't necessarily make you a better software engineer.
I'm not taking proficiency in the languages, I'm talking knowing it exist, having an idea of what is possible. I mean, I know no good C programmer that is not at least aware or the existence or Rust. And no, 90% of the programmers writing safety critical SW have no idea that a language called rust is available.
> I want my automotive embedded engineer to have a solid grasp of computer architecture, real-time safety protocols, and defensive programming.
Well, again, another example, with a chief software architect, in an ECU, so embedded: I ask "do we have some kind of stack monitoring?" Reply: "What?! we have no stack, stack is a data structure, ..." goes on with a long explanation of what stack, queue and tree are, and when are used... My personal opinion is, if you search for people that "know" only C++, and have no idea of asm, that is what you get. That is my experience at least.
> I don't see a problem with a Korean/Japanese car manufacturer having their documentation in a non-English language. As long as they do everything in-house and don't outsource to India like Boeing I have no problem with it.
I'm talking in-code comments, not documentation. But anyway, honesty, thinking you can do everything in-house today, and you will be able to maintain that in that way for the next 10 or 20 years when you have to maintain the code, sounds optimistic to me, at least. But again, I'm talking code I had to read, and maintain... so... yes... I'm talking a case, where it was BAD to have not english comments.
I meant, they do not know what a debugger is. As stated, they use "cout << "At line 26, after call to xx" as debugging tool. For gdb there are plenty of python extensions, and GUIs, even web front-end, that are not bad... but it may be difficult for some people, I understand that.
> Ada is useful for automotive. Lisp and Forth, not so much (especially since Lisp isn't usually used in hard real-time applications). This isn't the 1980s, MCUs aren't that memory constrained.
Well, first, they do not have the foggiest idea what Ada is. That is my problem. Once somebody suggested we should look into it, for L4 autonomous driving. He was laugh at, and it was said "it is a dead language from the 60, like Cobol or Fortran, nobody has used it in 50 years, there are no compilers for it!!!". I've seen forth being used in some 8-bit uC in the automotive industry still. Now is 99% gone, but was very much used. Lisp, can be used in hard real-time. BTW another thing always hanging around is the "hard real-time" for automotive. It is interesting, because other than for airbags, ignition and injection, you are talking about 100ms response times, which can be achieved very easily.
> Knowledge of obscure programming languages doesn't necessarily make you a better software engineer.
I'm not taking proficiency in the languages, I'm talking knowing it exist, having an idea of what is possible. I mean, I know no good C programmer that is not at least aware or the existence or Rust. And no, 90% of the programmers writing safety critical SW have no idea that a language called rust is available.
> I want my automotive embedded engineer to have a solid grasp of computer architecture, real-time safety protocols, and defensive programming.
Well, again, another example, with a chief software architect, in an ECU, so embedded: I ask "do we have some kind of stack monitoring?" Reply: "What?! we have no stack, stack is a data structure, ..." goes on with a long explanation of what stack, queue and tree are, and when are used... My personal opinion is, if you search for people that "know" only C++, and have no idea of asm, that is what you get. That is my experience at least.
> I don't see a problem with a Korean/Japanese car manufacturer having their documentation in a non-English language. As long as they do everything in-house and don't outsource to India like Boeing I have no problem with it.
I'm talking in-code comments, not documentation. But anyway, honesty, thinking you can do everything in-house today, and you will be able to maintain that in that way for the next 10 or 20 years when you have to maintain the code, sounds optimistic to me, at least. But again, I'm talking code I had to read, and maintain... so... yes... I'm talking a case, where it was BAD to have not english comments.
> Some examples I've seen in code
You are not reading it correctly. It is not code as everyone knows it. It's like an electrical circuit with variable names attached to each conductor, and the code propagates information like electricity would.
There's tools dedicated to this, able to draw pictures of such code circuits (e.g. Simulink, Ascet). And such pictures can be automatically translated into c-code, that looks even worse than anything translated manually.
In the end, of course the tests prove that the code works like the picture of the circuit shows, and therefore the car must work correctly! This avoids the need for anyone working on only the code to understand a car.
In reality, things usually work in the end only because of how simple everything is and high number of iterations.
You are not reading it correctly. It is not code as everyone knows it. It's like an electrical circuit with variable names attached to each conductor, and the code propagates information like electricity would.
There's tools dedicated to this, able to draw pictures of such code circuits (e.g. Simulink, Ascet). And such pictures can be automatically translated into c-code, that looks even worse than anything translated manually.
In the end, of course the tests prove that the code works like the picture of the circuit shows, and therefore the car must work correctly! This avoids the need for anyone working on only the code to understand a car.
In reality, things usually work in the end only because of how simple everything is and high number of iterations.
I think you are referring to something like Ascet. I know it.
I consider that code to be an intermediate representation that I'm not supposed to understand, maintain, or even test.
I’m talking about human written code, meant to be read, maintained, debugged and tested by other humans.
I’m talking about human written code, meant to be read, maintained, debugged and tested by other humans.
Modeling programs as circuits also makes them significantly easier to formally verify too! These sorts of synthesis tools are really cool, though writing traditional software in them is extremely painful.
I mirror your experience exactly. Well, maybe except the recursion one, that I have not seen... yet.
ISO 26262 is the functional safety standard that automobile manufacturers adhere to. Furthermore, companies with a strong safety culture may also have other safety controls, including MISRA, AUTOSAR, and others. I think reputable car companies take this stuff very seriously, but your concern is also well placed.
> I think reputable car companies take this stuff very seriously, but your concern is also well placed.
I trusted Volkswagen because of their reputation. Then the news broke about them systematically lying and breaking the law with respect to engine emissions. Shortly after this came to light, other "reputable car companies" turned out to have been not trustworthy at all.
Yes there are good standards in place and some companies claim to adhere to them but no company should be trusted on their word or reputation alone. The better question is what kind of regulatory oversight is in place to make sure those claiming to adhere to certain standards are actually doing so? Also, how much power do the regulatory organizations have in addressing violators?
I trusted Volkswagen because of their reputation. Then the news broke about them systematically lying and breaking the law with respect to engine emissions. Shortly after this came to light, other "reputable car companies" turned out to have been not trustworthy at all.
Yes there are good standards in place and some companies claim to adhere to them but no company should be trusted on their word or reputation alone. The better question is what kind of regulatory oversight is in place to make sure those claiming to adhere to certain standards are actually doing so? Also, how much power do the regulatory organizations have in addressing violators?
Faking those things is a totally different state of affairs to safe operation. I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety. Let's face it most people who work on cars love to drive cars. They would be putting their own and families lives at risk.
So you are oblivious to the history of Takata? Or the problem with the Ford Pinto, or the ignition key of GM, or the recursive function calls in Toyota code... just to name the most important that I can cite out of the top of my head.
Functional safety standards are performance based standards, which means they are shades of grey rather than prescriptive "follow these design clauses".
The designers get together and in a formal process try and come up with every possible adverse outcome and the probability it is likely to occur.
They then rank and use this info to assign performance requirements to various safety aspects and functions.
But a key part of the overarching parent IEC61508 standard is that there is a safety lifecycle - the designers make their best guess but the manufacturer has to at regular intervals compare actual gathered data against the predicted design data used and adjust accordingly, iterating to a better place.
Just like you might win the lottery first time you buy a ticket, under a performance based standard you might experience an adverse outcome in the first day of use, doesn't mean the design was necessarily deficient.
Infinite safety takes infinite cost, which would mean no cars, and what would the cost of that be to society.
Like I said,it's all shades of grey.
The designers get together and in a formal process try and come up with every possible adverse outcome and the probability it is likely to occur.
They then rank and use this info to assign performance requirements to various safety aspects and functions.
But a key part of the overarching parent IEC61508 standard is that there is a safety lifecycle - the designers make their best guess but the manufacturer has to at regular intervals compare actual gathered data against the predicted design data used and adjust accordingly, iterating to a better place.
Just like you might win the lottery first time you buy a ticket, under a performance based standard you might experience an adverse outcome in the first day of use, doesn't mean the design was necessarily deficient.
Infinite safety takes infinite cost, which would mean no cars, and what would the cost of that be to society.
Like I said,it's all shades of grey.
My comment was in reply to "I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety"
> I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety.
There is nothing to gain with not taking safety seriously, but fortunes to loose. Many of the software components of traditional automakers are built by suppliers. If a serious safety issue would arise and cause fatalities, the suppliers and the OEMs would not only have to pay enormous amounts in damages, they'd also need to issue recalls that might even pose an existential threat to the company.
There is nothing to gain with not taking safety seriously, but fortunes to loose. Many of the software components of traditional automakers are built by suppliers. If a serious safety issue would arise and cause fatalities, the suppliers and the OEMs would not only have to pay enormous amounts in damages, they'd also need to issue recalls that might even pose an existential threat to the company.
I've also never seen intentional compromises, but I've seen unintentional compromises made through ignorance or lack of foresight plenty of times. The bigger automakers seem to be better at this by virtue of developed processes, but what I've seen from smaller companies is terrifying.
I've been out of automotive safety critical software (engine, brake, controllers, etc...) but still have friends in it. Proper best practice is still followed by the likes of Toyota, Jaguar and Ford as the ones I've had experience in. That means the coding standards mentioned. Full requirements->design->implementation with functional unit testing, module unit testing and system testing including using simulators. Multiple people doing reviews, strict standards enforcement. Static analysis and code test coverage aiming for 100% path coverage with testing even when I was doing it. With staff typically staying on projects for the full 5 years of development.
Ford as one I can speak about with knowledge took seriously the cost of recalls versus catching issues in testing. It's massively cheaper to spend money up front to do full process and catch every bug you can than to cover recall costs to update later not even considering liabilities if anything does go pop.
Mistakes of course happen. But they're also rarely working from scratch.
It makes working in modern ways horrific seeing the shoddy shit tossed out to meet consumer gadget deadlines.
Ford as one I can speak about with knowledge took seriously the cost of recalls versus catching issues in testing. It's massively cheaper to spend money up front to do full process and catch every bug you can than to cover recall costs to update later not even considering liabilities if anything does go pop.
Mistakes of course happen. But they're also rarely working from scratch.
It makes working in modern ways horrific seeing the shoddy shit tossed out to meet consumer gadget deadlines.
Strange you mention Toyota as manufacturer, as they are the one who fucked up with the unintended acceleration issue mentioned earlier. The thing is that they "forgot" to implement the mechanism which ignore gas pedal when both brake and gas pedal are pressed. This was a recommended safety feature for accelerator by wire implementation (egas norm).
Then a few years later they got hit again with one of their suppliers: Takata's killing airbags
Then a few years later they got hit again with one of their suppliers: Takata's killing airbags
Apparently they are still killing people. If owners don't get the airbags replaced, the cars should be impounded.
I just read a story where someone borrowed a car with a Takata airbag in it and was killed.
I just read a story where someone borrowed a car with a Takata airbag in it and was killed.
It's worth noting that ISO 26262 is mostly concerned with preventing faults due to system failure, e.g. spurious hardware faults, hardware degradation over time, etc. As an example, it doesn't have much to say about preventing a child from being misclassified as a bollard. It's a quite robust standard, and one most auto makers (certainly the European ones) have spent a lot of effort processing and following for quite some time now (in my limited experience).
There's a separate standard (ISO 21448) trying to address issues with safety of intent, i.e. maintaining safety when there's no actual fault in the system. (Like the misclassification example.) This one's newer, much less effort has been spent developing it, and even less has been spent trying to follow it. Frankly it doesn't have as much to say. (And how could it? Nobody knows how to solve general classification problems, and especially not with something running on some 20 W max control unit.) This part of the problem space is basically the wild west. Some auto makers do a good effort trying to create safe solutions. Others not so much.
In summary, some of the electronics solutions in the car can probably be trusted to do what they're meant to (e.g. airbags). Others (e.g. lane keeping assist, emergency braking) are still still mostly be safe but certainly warrant keeping your hands on the wheel. Anything approaching fully self driving is at best quite dubious at this point though.
There's a separate standard (ISO 21448) trying to address issues with safety of intent, i.e. maintaining safety when there's no actual fault in the system. (Like the misclassification example.) This one's newer, much less effort has been spent developing it, and even less has been spent trying to follow it. Frankly it doesn't have as much to say. (And how could it? Nobody knows how to solve general classification problems, and especially not with something running on some 20 W max control unit.) This part of the problem space is basically the wild west. Some auto makers do a good effort trying to create safe solutions. Others not so much.
In summary, some of the electronics solutions in the car can probably be trusted to do what they're meant to (e.g. airbags). Others (e.g. lane keeping assist, emergency braking) are still still mostly be safe but certainly warrant keeping your hands on the wheel. Anything approaching fully self driving is at best quite dubious at this point though.
26262 covers system failures that produce unsafety, like broken accelerator sensors. ISO 21448 (SOTIF) covers system failure to detect and respond to the environment appropriately (e.g. does the radar detect small children?), which is also a common concern for people in my experience.
Both are acceptable standards, but ISO 26262 is a behemoth of a standard that most people have never read. Many companies don't even make the full standard available to their development teams, let alone educate people to employ it effectively. Similarly, MISRA is fine in theory, but the practical usage often ends with running code through an automatic checker that can only detect half the rules.
Both are acceptable standards, but ISO 26262 is a behemoth of a standard that most people have never read. Many companies don't even make the full standard available to their development teams, let alone educate people to employ it effectively. Similarly, MISRA is fine in theory, but the practical usage often ends with running code through an automatic checker that can only detect half the rules.
ISO 26262 is optional, and some car makers (e.g. Tesla) may choose not to use it directly; but in general they use another process that they feel provides equivalent safety properties, and feel so strongly enough that they're comfortable substantiating this in the inevitable lawsuits.
I don't know why you would ever think a company takes stuff seriously (well I do, patriotism). What was Dieselgate? Companies are identityless auotmata which simply run amuck until Murphy's Law causes regulators to force them to change.
Iso26262 is the safety standard (a slimmed down version of industrial standard by the way).
misra are the coding rules recommended to apply for these standard.
Autosar is an OS definition to make modular SW
Autosar is a horrible horrible standard that makes SW worse. I am of the oppinion that AUTOSAR based systems are _worse_ and less safe because of it.
The API itself is decent but the configuration and the ecosystem is a nightmare.
The API itself is decent but the configuration and the ecosystem is a nightmare.
Working on a ECU that at some point during the development had to switch to Autosar, I cannot agree more on this.
There are a number of things under the AUTOSAR umbrella, one of which is a set of C++ coding guidelines, akin to MISRA. This is what the other poster is referring to. Back when I worked at Tesla, we enforced a subset of MISRA rules, and at my current company we enforce a subset of AUTOSAR rules, but use none of the AUTOSAR “platform”.
I am scared of the infotainment system myself as it could distract you to death. That goes for cell phone and tablet and the stick-on GPS which gets confused in the most complex urban areas, falls into your lap when the suction cup fails, etc.
My big complaint is with the transition of controls from dedicated, tactile knobs, switches, and levers to touch-screen buttons or menus which demand more visual attention (i.e. distraction from driving) to operate.
Mazda did the research, and transitioned back to real tactile controls in 2019. I expect more automakers will be or are already following their lead.
https://www.motorauthority.com/news/1121372_why-mazda-is-pur...
https://www.motorauthority.com/news/1121372_why-mazda-is-pur...
I love Mazda for resisting the touchscreen-everything car interior. Everything in my 2021 CX-5 is physical buttons and knobs. The design and ergonomics are just fantastically nice and usable.
Like you said, the infotainment is also not a touchscreen and is rotary control only. While not as immediately intuitive as a touchscreen, once you get the hang of it it is much safer and more accurate to use while driving. Trying to use a touchscreen while moving is just awful.
And I don't think it is wise to optimize short term intuitiveness over long term safety and usability for a vehicle I will own for several years.
Like you said, the infotainment is also not a touchscreen and is rotary control only. While not as immediately intuitive as a touchscreen, once you get the hang of it it is much safer and more accurate to use while driving. Trying to use a touchscreen while moving is just awful.
And I don't think it is wise to optimize short term intuitiveness over long term safety and usability for a vehicle I will own for several years.
I have a 2016 Mazda and they had tactile controls then. What they did in 2019 was remove the touch screen feature on the center display, but there were always tactile controls to access the display. I have a 2022 Mazda and it's largely the same interface as the 2016 controls.
This is my least favorite trend in new cars. If there aren't any new cars in 10 years that aren't just a giant screen in the center then I guess I'm going to be walking.
You can make a modern electric vehicle with actual buttons and dials. There is nothing about a car not having a gas motor that requires every tiny bit of functionality being controlled by a touch tablet. If anything it just seems like laziness in car design.
You can make a modern electric vehicle with actual buttons and dials. There is nothing about a car not having a gas motor that requires every tiny bit of functionality being controlled by a touch tablet. If anything it just seems like laziness in car design.
You may get your wish. Recent research has shown that real knobs and switches are much less of a driver distraction than trying to fiddle with screens or get voice commands correct. The two either mean you look away from the driving because you can't just feel your way across a screen like physical controls or you add cognitive load whilst thinking and talking.
I'm with you and hope all the idiot touch screen crap is ditched.
I'm with you and hope all the idiot touch screen crap is ditched.
> I'm with you and hope all the idiot touch screen crap is ditched.
I agree many manufacturers have gone a bit overboard in making even things like vent positions and glove boxes behind touchscreens. But at the same time, I don't want touch screen to completely disappear. Punching in a destination and controlling the navigation interface is way better with a touchscreen than using a dial. As a passenger or while stopped, changing the media with a touchscreen interface is better than a dial. Changing a lot of the finer settings in the car (ones you wouldn't be doing while driving) with a touchscreen is better than scrolling through menus with a dial. For the most part, a lot of things you'd do with the system while not moving or while being the passenger can be better on the screen than with a bunch of physical controls, controls which would necessitate making the screen a lot smaller.
Also, then when wanting to quickly reference the navigation system, having a larger screen with larger items on it means it is easier to understand what it is telling the driver in a glance. Having a ton of physical controls means it is a much smaller map, meaning smaller items on the map, meaning harder to understand at a quick glance. It's nice having the next turn up in the driver's information cluster or on a heads-up display as well to reduce the needs for the driver to reference the larger navigation system.
There definitely needs to be a balance of physical controls versus software buttons, but I wouldn't buy a new car without a screen these days.
I agree many manufacturers have gone a bit overboard in making even things like vent positions and glove boxes behind touchscreens. But at the same time, I don't want touch screen to completely disappear. Punching in a destination and controlling the navigation interface is way better with a touchscreen than using a dial. As a passenger or while stopped, changing the media with a touchscreen interface is better than a dial. Changing a lot of the finer settings in the car (ones you wouldn't be doing while driving) with a touchscreen is better than scrolling through menus with a dial. For the most part, a lot of things you'd do with the system while not moving or while being the passenger can be better on the screen than with a bunch of physical controls, controls which would necessitate making the screen a lot smaller.
Also, then when wanting to quickly reference the navigation system, having a larger screen with larger items on it means it is easier to understand what it is telling the driver in a glance. Having a ton of physical controls means it is a much smaller map, meaning smaller items on the map, meaning harder to understand at a quick glance. It's nice having the next turn up in the driver's information cluster or on a heads-up display as well to reduce the needs for the driver to reference the larger navigation system.
There definitely needs to be a balance of physical controls versus software buttons, but I wouldn't buy a new car without a screen these days.
Muscle memory to know that the third button in past the volume knob turns on the windshield defroster, vs. looking at a menu on a screen whilst driving...
Indeed, the software most likely to kill or injure you in a car is running on someone’s smartphone. It’s probably not even close.
I know a connected car, as most modern cars are, can potentially be controlled from remote.
That means you can get OTA upgrades that 99% of the times will work flawlessly, but a day may do not, the day you are in a rush in the early morning.
Since most connected cars are de-facto owned by their vendor a potential breach or deliberate sabotage might brick ALL at once across the globe or in some specific areas/countries.
...
A modern car is a car co-piloted by a human and a computer. A local airgapped computer might have bugs, a connected one might have vulnerabilities. Be more scared about them.
In mere local safety terms I can say most cars I know are partially mechanical that means for instance your steering wheel can auto-steer BUT with (more than) a bit of force you can steer it mechanically even if automation completely fail. Similar the break pedal have some servo systems but still partially work in mechanical forms, so might became very hard to push but still able to break a bit.
The most dangerous common design I know are:
- impossibility to turn off certain ADAS who might act really badly in certain weather condition, like the classic ABS on icy roads;
- automatic doors lock when car move, NO DAMN WAYS to unlock them while the car still moving;
- manual parking break disappeared so a kind of emergency breaking ALSO usable by a passenger (for instance if the driver fell ill suddenly) ABSENT and no electronic replacement either since the electronic one if present refuse to engage if the car is moving;
- cockpit design that makes very hard/slow for a passenger to push the driver feet out of accelerator etc if he/she fell ill suddenly.
I consider the above as a sign of VERY BAD design, so I doubt those who made it can be trusted for anything else in safety terms...
That means you can get OTA upgrades that 99% of the times will work flawlessly, but a day may do not, the day you are in a rush in the early morning.
Since most connected cars are de-facto owned by their vendor a potential breach or deliberate sabotage might brick ALL at once across the globe or in some specific areas/countries.
...
A modern car is a car co-piloted by a human and a computer. A local airgapped computer might have bugs, a connected one might have vulnerabilities. Be more scared about them.
In mere local safety terms I can say most cars I know are partially mechanical that means for instance your steering wheel can auto-steer BUT with (more than) a bit of force you can steer it mechanically even if automation completely fail. Similar the break pedal have some servo systems but still partially work in mechanical forms, so might became very hard to push but still able to break a bit.
The most dangerous common design I know are:
- impossibility to turn off certain ADAS who might act really badly in certain weather condition, like the classic ABS on icy roads;
- automatic doors lock when car move, NO DAMN WAYS to unlock them while the car still moving;
- manual parking break disappeared so a kind of emergency breaking ALSO usable by a passenger (for instance if the driver fell ill suddenly) ABSENT and no electronic replacement either since the electronic one if present refuse to engage if the car is moving;
- cockpit design that makes very hard/slow for a passenger to push the driver feet out of accelerator etc if he/she fell ill suddenly.
I consider the above as a sign of VERY BAD design, so I doubt those who made it can be trusted for anything else in safety terms...
1. Cars have had computers in them for a very long time now.
2. The code, in many cases, is probably an unmaintainable mess. Embedded programming is not always modern programming, for good and bad.
3. Today, the computers in cars are doing more, and the systems are more complex. It's reasonable to expect more serious problems as a result.
4. Companies do safety testing, of course, but there's no such thing as as "100%" test coverage for complex physical machines running outside of a lab.
5. The best way to judge the safety of cars is the best way to judge safety for airplanes: let other people test them out for a while and then check whether or not they report problems.
2. The code, in many cases, is probably an unmaintainable mess. Embedded programming is not always modern programming, for good and bad.
3. Today, the computers in cars are doing more, and the systems are more complex. It's reasonable to expect more serious problems as a result.
4. Companies do safety testing, of course, but there's no such thing as as "100%" test coverage for complex physical machines running outside of a lab.
5. The best way to judge the safety of cars is the best way to judge safety for airplanes: let other people test them out for a while and then check whether or not they report problems.
This is absolutely the case. Until more or less now, the software was made with systems like simulink (but much much simpler), where a mechanical engineer could build blocks of very simple functions, using AND, NOT, OR gates, and mathematical operations.
Now the companies are migrating to real programming in C++, and it is a terrible mess. There are just not enough people with software competence to drive it.
I've seen people trying to do L4 automated systems with this blocks. Pages and pages and pages of boxes (which can only be the basic logical function, and the 4 basic arithmetic operations!!!). Of course the project didn't go anywhere!
Now the companies are migrating to real programming in C++, and it is a terrible mess. There are just not enough people with software competence to drive it.
I've seen people trying to do L4 automated systems with this blocks. Pages and pages and pages of boxes (which can only be the basic logical function, and the 4 basic arithmetic operations!!!). Of course the project didn't go anywhere!
Your comment is pretty accurate. Just remove "probably" from point 2.
You're thinking about this the wrong way. Don't optimize for the car behaving perfectly--like you said it's impossible for you to verify this. And even if you could formally prove a car is perfectly behaved, you are driving on streets with other cars and other unpredictable people who could just as easily crash into you.
Optimize this problem by buying a car with the best safety rating. This is something that can be objectively measured, both in crash testing/labs and from reviews of real-world crash results. Expect that a crash could be inevitable as it is totally out of your control. Optimize for the best odds of surviving a crash without issues.
Optimize this problem by buying a car with the best safety rating. This is something that can be objectively measured, both in crash testing/labs and from reviews of real-world crash results. Expect that a crash could be inevitable as it is totally out of your control. Optimize for the best odds of surviving a crash without issues.
Problem is that if you do that, you make the road less safe for everyone else
Only if you're then also willing to go up a size in vehicle. You can still choose more or less safe vehicles from within the same class. A 2022 Corolla is way safer than a 1998 Corolla, that 1998 Corolla is safer than a 1966 Corolla, etc.
If you're interested in this topic, you might want to check out ASRG[1]. It's a community of safety and security professionals in the industry working to improve standards. They share their research openly and have regular in-person and online events where you can reach out to people.
[1] https://asrg.io/
[1] https://asrg.io/
"Safety" and "Security" are considered separate topics in the automotive world, even though there's some overlap between them. There are usually completely separate teams with different skillsets responsible for each at any given manufacturer. ASRG is pretty focused on the security side rather than the safety side.
Short version of the difference: Safety = This shouldn't cause harm. Security = This should be hard to hack.
It's sad that this and many other admirable movements like langsec will never amount to much because of the false dilemma that everything needs to be complicated because of "reasons" (politics, in automobiles, and "the poor user who needs a complicated to implement interface that changes every day" in the case of langsec). That is, most electronics in vehicles are obviously not needed, and if it was up to me infotainment would just be illegal aside from a basic physical knob to change volume of some audio in the 3.5mm jack (and not by sending a digital signal to a system that makes the user readjust it several times after the large input delay). I was being half serious but now that I think of it bluetooth and "smart" tech and such atrocities should just be illegal. They are like what's already accepted as illegal harmful Chinese products.
Don't buy a Tesla and you'll be fine. I work in auto insurance and the other OEMs actually care about safety and testing of software. Tesla has the most bugs by far.
I don't know about tesla since I haven't had a chance to drive one yet, but the number of bugs especially in the interface but also in driver's "assistance" in other cars(VW, BMW) makes me doubt that it makes a noticeable difference - at least with tesla there is a chance they will fix it
Other OEMs fix bugs all the time.
The difference is that Tesla has bugs throughout its software, including critical systems.
The other OEMs are extremely slow and methodical about updating things like their fuel-injection software, and that stuff goes through incredible amounts of QA. The same is not true of Tesla. They're a company that, at Musk's direction, do not prioritize QA or human life.
The difference is that Tesla has bugs throughout its software, including critical systems.
The other OEMs are extremely slow and methodical about updating things like their fuel-injection software, and that stuff goes through incredible amounts of QA. The same is not true of Tesla. They're a company that, at Musk's direction, do not prioritize QA or human life.
Many of the electronic systems in traditional automaker's vehicles are made by a variety of other OEMs anyway. So judging by automaker brand may not really be a good judge of the engineering development of those subsystems. The infotainment might be made by Panasonic and the driver assistance might be made by Bosch.
They are interconnected though. Reputation for faults add up. To me the following is vw's fault.
I've recently had an id4's location fail, and the map was all over the place. It got worse as I drove on.
Annoying, but I thought not a safety issue until the speed limiter caused the car to attempt to slow down by more than 100kph as it was reporting it was somewhere else.
I've recently had an id4's location fail, and the map was all over the place. It got worse as I drove on.
Annoying, but I thought not a safety issue until the speed limiter caused the car to attempt to slow down by more than 100kph as it was reporting it was somewhere else.
The industry is really good at inventing the wheel multiple times. Even in a simple case: Two car manufacturers, same supplier for the same kind of control unit - the hardware will likely look similar, but most likely both are running almost completely different software.
> the hardware will likely look similar, but most likely both are running almost completely different software.
And automotive parts OEMs could run down to Best Buy, point at a Surface Book and a Macbook, and say the same thing.
And automotive parts OEMs could run down to Best Buy, point at a Surface Book and a Macbook, and say the same thing.
>other OEMs actually care about safety
https://en.wikipedia.org/wiki/Firestone_and_Ford_tire_contro...
https://en.wikipedia.org/wiki/General_Motors_ignition_switch...
https://medium.com/the-snail/the-exploding-ford-pinto-of-197...
https://abcnews.go.com/Blotter/toyota-pay-12b-hiding-deadly-...
Such care, wow.
https://en.wikipedia.org/wiki/Firestone_and_Ford_tire_contro...
https://en.wikipedia.org/wiki/General_Motors_ignition_switch...
https://medium.com/the-snail/the-exploding-ford-pinto-of-197...
https://abcnews.go.com/Blotter/toyota-pay-12b-hiding-deadly-...
Such care, wow.
It's easy to cherry-pick these things and succumb to confirmation bias. I was talking about company culture, not results.
But as long as we're talking about results, "FSD" is an intentional homicide engine and Tesla has had far more recalls per vehicle sold than any other company. They're at the bottom of quality rankings by a wide margin.
But as long as we're talking about results, "FSD" is an intentional homicide engine and Tesla has had far more recalls per vehicle sold than any other company. They're at the bottom of quality rankings by a wide margin.
There is a risk of automobile security. Nowadays cars have vast attack surface and uplink accesses directly into internal car's CAN/Ethernet bus: OBD-II port, bluetooth, GSM/5G, WiFI, NFC, access via OEM's web portal (these are big piles of unsecure code), via mobile app API, dealer network applications.
Plus OEMs have a vast parts and software supply chain that can be compromised.
I suspect that in couple years timeframe we can see massive incident, like ransomware, that will disable entire fleet of a single OEM globally. Like imagine all Mercedes around the world to just stop operating - these kind of incidents
Plus OEMs have a vast parts and software supply chain that can be compromised.
I suspect that in couple years timeframe we can see massive incident, like ransomware, that will disable entire fleet of a single OEM globally. Like imagine all Mercedes around the world to just stop operating - these kind of incidents
This is the correct take. Also just found yet another problem puiblished a few weeks ago: https://medium.com/@doctoreww/day-2-your-car-is-trackable-by...
This stuff falls completely within any infosec person's expectations. Privacy leaks are expected, as are interference from remote signals.
This stuff falls completely within any infosec person's expectations. Privacy leaks are expected, as are interference from remote signals.
Vehicle software faults are pretty far down the injury risk depth chart.
Once you've committed to never driving after having had a drink (and surely never more than 1 drink), never driving while tired or on medication, have completed several advanced driving courses/car control clinics, chosen the top cars based on safety and crash testing, only then might it make sense to use software development methods as a tie-breaker to pick a car.
Once you've committed to never driving after having had a drink (and surely never more than 1 drink), never driving while tired or on medication, have completed several advanced driving courses/car control clinics, chosen the top cars based on safety and crash testing, only then might it make sense to use software development methods as a tie-breaker to pick a car.
All of that firmware that isn't a self driving autopilot blackbox is probably quite safe. Such as anti-lock breaks and fuel injection timing.
I am never going to put my life in the hands of some software doing image analysis using machine learning.
I am never going to put my life in the hands of some software doing image analysis using machine learning.
> I am never going to put my life in the hands of some software doing image analysis using machine learning.
Well...on your car, at least. I'm not sure how comforting that approach is when you're surrounded on the interstate by Tesla "FSD"s.
Well...on your car, at least. I'm not sure how comforting that approach is when you're surrounded on the interstate by Tesla "FSD"s.
Ironically, I feel at much more ease driving surrounded by Tesla "FSD"s, as opposed to being surrounded by average Seattle drivers. At least FSD always uses turn signals when switching lanes and is way more cautious (while still remaining reasonable).
Back when I spent a full year commuting to work daily on a motorcycle, Teslas with "FSD" were the least of my worries. All while people who sharply switched into my lane in front of me with no turn signals used, they ended up almost killing me a couple of times.
Back when I spent a full year commuting to work daily on a motorcycle, Teslas with "FSD" were the least of my worries. All while people who sharply switched into my lane in front of me with no turn signals used, they ended up almost killing me a couple of times.
I'm ok with doing a bit of defensive driving against Teslas or bad drivers in general.
Normally, cars require certification to be allowed on public roads. My main problem with software in automobiles is that vendors can change my car even without any certification agency involved in the process.
So the answer is yes, and no.
> https://illmatics.com/carhacking.html
is a good starting point. But there are a bunch of buses on a modern car, some of them are critical, some less so. Some are firewalled off, others are open.
As you know you can get access to a lot of the car's inner workings by plugging into the ODB2 port. Its perfectly possible to brick some cars by fuzzing the ODB2 port.
In principle, most things in cars _should_ fail safe. even if they are electric or talking over a bus of somesort.
> https://illmatics.com/carhacking.html
is a good starting point. But there are a bunch of buses on a modern car, some of them are critical, some less so. Some are firewalled off, others are open.
As you know you can get access to a lot of the car's inner workings by plugging into the ODB2 port. Its perfectly possible to brick some cars by fuzzing the ODB2 port.
In principle, most things in cars _should_ fail safe. even if they are electric or talking over a bus of somesort.
OBD is a diagnostic bus. On modern car the access is authenticated on several layers (eg. guest, carmaker, ECU supplier). I would not call that interesting. Accessing a CAN/FlexRay/LIN/Eth bus is better.
If it has software in it, it's bad.
As a hacker like any other who realized that all supposedly ultra safe American quality (TM) software in mission critical applications is in fact less secure on average than random amateur projects, I have been worried about software in vehicles for 20 years. I correctly predicted that it will lead to remote control vulnerabilities such as the uConnect vulnerability disclosed a decade later. There are obviously more of such vulnerabilities out there, just nobody is researching this. I also suggest people start looking at HVAC.
In 2015, some security researchers found a vulnerability in the Chrysler Uconnect software which allowed them to connect to the car's IP address (yes, each car had an IP address, which you can't get rid of), and control the vehicle (as in actually control it). There were 1.5 million vehicles IIRC that were vulnerable to this. So if a bad guy found it first he could have controlled all those vehicles at once from the comfort of his home, probably causing 10% of them to crash and kill people (given that 1/10 of your average modern driver would probably panic (or not panic but still fuck up) from the slightest surprise on the road).
I also am of the opinion that people regularly die from software faults in vehicles, but we just haven't figured this out yet.
What is NASA/JPL rules? Some more misra C crap where it's just making the code more "readable"? Most "software engineers" have extremely wide gaps in their understandings of basic things from programming, to math, to physics. The problem has much more to do with this than cute little best practices recommendations.
As a hacker like any other who realized that all supposedly ultra safe American quality (TM) software in mission critical applications is in fact less secure on average than random amateur projects, I have been worried about software in vehicles for 20 years. I correctly predicted that it will lead to remote control vulnerabilities such as the uConnect vulnerability disclosed a decade later. There are obviously more of such vulnerabilities out there, just nobody is researching this. I also suggest people start looking at HVAC.
In 2015, some security researchers found a vulnerability in the Chrysler Uconnect software which allowed them to connect to the car's IP address (yes, each car had an IP address, which you can't get rid of), and control the vehicle (as in actually control it). There were 1.5 million vehicles IIRC that were vulnerable to this. So if a bad guy found it first he could have controlled all those vehicles at once from the comfort of his home, probably causing 10% of them to crash and kill people (given that 1/10 of your average modern driver would probably panic (or not panic but still fuck up) from the slightest surprise on the road).
I also am of the opinion that people regularly die from software faults in vehicles, but we just haven't figured this out yet.
What is NASA/JPL rules? Some more misra C crap where it's just making the code more "readable"? Most "software engineers" have extremely wide gaps in their understandings of basic things from programming, to math, to physics. The problem has much more to do with this than cute little best practices recommendations.
Cars have had software controlling essential functionality for decades. It didn't suddenly appear when touchscreens did.
Now is totally different. The software used to be done with graphical tools, with boxes like simulink, but with only basic logical and arithmetic operations.
Now they are trying to write C++.
Now they are trying to write C++.
Your concern is well founded given the proliferation of utter shit that is modern car "entertainment" centers. Scare quotes because some safety important things are handled by those. If you don't think so, drive my 2017 Ford Expedition when it's -10F outside and the windshield fogs up beyond visibility levels because the damn defroster (and other environment controls) doesn't work and and the windshield is fogging up. Or try to back up and see the backup-camera glitching out.
However, most of the safety systems software is held to a very high standard, and much happens in embedded systems where the surface level for software foot-guns (such as state) are minimal. I wouldn't worry about buying a new car for these reasons. Though I would try to find one with as many physical buttons as possible.
However, most of the safety systems software is held to a very high standard, and much happens in embedded systems where the surface level for software foot-guns (such as state) are minimal. I wouldn't worry about buying a new car for these reasons. Though I would try to find one with as many physical buttons as possible.
The problem is mostly a cultural one.
In my personal experience, the automotive industry has a problem with aggression and dishonesty, both of which seem to go hand-in-hand.
Both of these cultural traits tend to have a negative impact on quality and safety.
In my personal experience, the automotive industry has a problem with aggression and dishonesty, both of which seem to go hand-in-hand.
Both of these cultural traits tend to have a negative impact on quality and safety.
I don't think it is bugs which worries you, but rather the completely wrong concept of modern day car production. Almost all cars built in the past 20-years have 0 compliance with the laws of physics, being extremely front-heavy and with transversely-mounted engines - disbalanced even on the Y-axis. What keeps them from spinning is the so-called DSC/ESC/ESP which is basically a neural network. We all know how reliable those are. It is in fact a very similar situation to the 737 Max, just on wheels.
Due to regulations you will not be able to find a non-veteran vehicle without those systems, nor you'd want to, but BMW, Mercedes, Subaru and Lexus still have models which are well balanced and don't rely on those to such a heavy degree. This would be my advise as well.
Disclaimer: I am not against (almost) perfectly deterministic safety systems such as ABS. On the contrary - I consider them to be a massive advantage or almost mandatory.
Due to regulations you will not be able to find a non-veteran vehicle without those systems, nor you'd want to, but BMW, Mercedes, Subaru and Lexus still have models which are well balanced and don't rely on those to such a heavy degree. This would be my advise as well.
Disclaimer: I am not against (almost) perfectly deterministic safety systems such as ABS. On the contrary - I consider them to be a massive advantage or almost mandatory.
You're kidding if you think the premium brands you list don't have massive dependence on software systems. The basic physics is, as you say, better because they've kept mass distribution in line with how it was.
And how about the additional failure mode for say BMW. It's modern controllers have all the software for all the features in, just disabled unless you pay more. So a theoretic sophisticated attack could throw all sorts of crap into operation.
And how about the additional failure mode for say BMW. It's modern controllers have all the software for all the features in, just disabled unless you pay more. So a theoretic sophisticated attack could throw all sorts of crap into operation.
I don’t have numbers in front of me, but my impression is that carmakers have done a much better job in the last decade with front-rear balance decent on nearly all cars. Versus decades past when some were wildly front-heavy (or occasionally, wildly back-heavy, ouch).
Most BMWs have nearly perfect 50/50 weight balance between front and rear axles.
Generally speaking, most sportier cars have better handling and better weight distribution and are in fact regularly driven with DSC disabled (on racing track etc)
Generally speaking, most sportier cars have better handling and better weight distribution and are in fact regularly driven with DSC disabled (on racing track etc)
I’m way more worried about having a wreck while distracted by some horrible touchscreen interface than I am about a bug causing a wreck.
When will auto companies wake up and realize that physical controls are better in every way?
When will auto companies wake up and realize that physical controls are better in every way?
As long as you're not buying a Tesla/other "self driving car", you will not be the cause of an accident due to automobile software.
ISO 26262.
A long time ago I attended a DEFCON where this was discussed. Long before it became a big deal in the industry to have all this tech in cars. CANBUS was broken reliably, and if my memory serves me they even had a car you could take a shot at hacking yourself. After playing with it the entire conference I came to the conclusion I would never own a modern car if I can avoid it.
Any car running CANBUS is vulnerable to a potentially fatal attack. They have not resolved this. However, you also generally cannot avoid it. Even the base model Honda civic is vulnerable to attacks on the drive-by-wire system. In a less morbid sense, most modern cars cannot even be serviced at home without going to the dealer for a reset of whatever subsystem. ABS comes to mind.
I would not detract from an old car. A car 25 years old has 99% of the safety features of a modern car and, in good working order, will protect you just the same. Or maybe I just don't worry about it because the probability of anything greater than a minor fender bender killing you is pretty high even with modern tech.
Any car running CANBUS is vulnerable to a potentially fatal attack. They have not resolved this. However, you also generally cannot avoid it. Even the base model Honda civic is vulnerable to attacks on the drive-by-wire system. In a less morbid sense, most modern cars cannot even be serviced at home without going to the dealer for a reset of whatever subsystem. ABS comes to mind.
I would not detract from an old car. A car 25 years old has 99% of the safety features of a modern car and, in good working order, will protect you just the same. Or maybe I just don't worry about it because the probability of anything greater than a minor fender bender killing you is pretty high even with modern tech.
Pre-CANBUS cars were even easier to exploit. Much of everything on those systems were in plaintext, and could be easily tinkered with. A 25 year old car may have many of the same safety systems (although it is definitely missing a few), but the passive safety systems that do exist are most certainly not to the same standard as today's vehicles. To put it plainly, you are way more likely to die because the safety cage collapses on your late 90's vehicle, than you are to die because someone attacked the CANBUS of your vehicle.
DEFCON has a lot of great security demos, but don't mistake any of those demos as representative of the real-world landscape of issues.
DEFCON has a lot of great security demos, but don't mistake any of those demos as representative of the real-world landscape of issues.
This idea you seem to have of DEFCON having presentations that conflate things like backdooring with remotely exploitable vulnerabilities is wrong. That would be about 1% of them. DEFCON was always reasonable quality. Not sure what the parent poster is on about, though.
> CANBUS was broken reliably
So can my brake or fuel lines, if you're needing physical access. Get this, the door locks aren't even 100% secure, there's this whole thing that side steps them called "Windows".
I do lament not being able to fully flush my brakes at home and do wish the programming harness would be freely available to override the system and have the ABS clear the lines. However, I wouldn't for a second choose to not have ABS on any vehicle I own, including my motorcycle.
So can my brake or fuel lines, if you're needing physical access. Get this, the door locks aren't even 100% secure, there's this whole thing that side steps them called "Windows".
I do lament not being able to fully flush my brakes at home and do wish the programming harness would be freely available to override the system and have the ABS clear the lines. However, I wouldn't for a second choose to not have ABS on any vehicle I own, including my motorcycle.
> Any car running CANBUS is vulnerable to a potentially fatal attack.
No, it isn't. CANBUS is a non-safe protocol ("black channel" in safety parlance) and if anything safety-relevant is sent over it, there is a safety protocol on top.
No, it isn't. CANBUS is a non-safe protocol ("black channel" in safety parlance) and if anything safety-relevant is sent over it, there is a safety protocol on top.
Black channel schemes are not resistant to malicious input unless security was intentionally built in. Safety and security are separate (but related) concerns. Besides, white channel is still (unfortunately) a thing in some parts of the industry.
That's not strictly fair. The problem is that the critical systems were moved to share transport on the main hub with infotainment (safe, I did modelling of the messages for Volvo way back).
On that hub is wireless access. Cars have been using CANBUS way longer than that issue entering play and without physical access you wouldn't be able to hack them and with physical access you could easily tamper with brakes or other systems.
Dealerships routinely violate CANbus isolation with junky "add-ons" full of security holes and wireless interfaces directly attached to important buses. Every single manufacturer that cares at all about bus integrity should be doing message signing and that's where CANBus simply doesn't work. The bandwidth is far too low for good schemes (leading to custom implementations) and there are no decent standards for hardware vendors to implement, which means more of the already-limited CPU budget has to be allocated to it.
When it comes to potentially fatal attacks on my car, I'm a lot more worried about drunk drivers than CANBUS.
In which case, having a more modern car with better safety designs is way better than not having a CANBUS.
And I definitely agree; I'm way more likely to be harmed because of a drunk driver or someone running a red because they're just too busy to bother stopping at this light today rather than some hacker remoting into my car to change the car from drive to neutral or remotely disable ABS or something like that.
And I definitely agree; I'm way more likely to be harmed because of a drunk driver or someone running a red because they're just too busy to bother stopping at this light today rather than some hacker remoting into my car to change the car from drive to neutral or remotely disable ABS or something like that.
> CANBUS was broken reliably, and if my memory serves me they even had a car you could take a shot at hacking yourself.
This statement shows a fundamental lack of understanding of how automotive computer networks operate.
The CAN bus is just a network. It's an industrial control protocol that's been adopted by the automotive world. It doesn't offer security by design, it's intended for use in limited environments where all hardware on the network is known and trusted. CAN provides methods for prioritization of devices, that's it. Any security is left to higher layers of the stack.
There is no such thing as "breaking" CAN, you just physically connect to the network and you're able to talk to whatever controllers are on that network (most modern cars have multiple CAN buses connected to different subsets of the vehicle systems). At that point it's about the security features implemented by the devices on the network.
> Any car running CANBUS is vulnerable to a potentially fatal attack. They have not resolved this.
There is nothing to resolve at the network level. To put it another way, almost every computer that's ever been hacked over the internet was running Ethernet but that's just as irrelevant as CAN in cars.
If you are able to physically connect to the network, you can talk to and potentially spoof devices on the network.
> A car 25 years old has 99% of the safety features of a modern car and, in good working order, will protect you just the same.
You couldn't possibly be more wrong. Pick your favorite vehicle from 1997 and look up the crash test videos, then compare against a similar recent model.
Here's the most popular vehicle sold in the US, the Ford F-150, from 1997 (https://www.youtube.com/watch?v=_i5EmJBaGeQ) versus one from 2016 (https://www.youtube.com/watch?v=Cou88zi4pMY). You tell me which one you'd rather be in.
You might say, correctly, that the 1997 F-150 is particularly bad, but here you can see a 1997 Volvo V70 versus a 2009 Volvo V70 (https://www.youtube.com/watch?v=msnJK0ce-VM). Volvo has a reputation for building some of the safest vehicles on the road, and even those twelve years show substantial gains in crash performance where the older car's passenger compartment is clearly compromised while the newer one's crumple zones work as intended.
> Or maybe I just don't worry about it because the probability of anything greater than a minor fender bender killing you is pretty high even with modern tech.
Again, absolutely wrong. I say this as someone who's flipped a truck off the road at highway speed and walked away with minor abrasions and bruising from the seatbelt and a few cuts from broken glass as the rest of the truck got ruined but the cab stayed intact. My anecdote is of course statistically meaningless, but the data agrees. Crash fatality rates have consistently trended downward from the '80s until 2020. The main reason modern vehicles have gained so much exterior size without gaining nearly as much interior size is all the space taken up by modern safety equipment, crumple zones, etc.
This statement shows a fundamental lack of understanding of how automotive computer networks operate.
The CAN bus is just a network. It's an industrial control protocol that's been adopted by the automotive world. It doesn't offer security by design, it's intended for use in limited environments where all hardware on the network is known and trusted. CAN provides methods for prioritization of devices, that's it. Any security is left to higher layers of the stack.
There is no such thing as "breaking" CAN, you just physically connect to the network and you're able to talk to whatever controllers are on that network (most modern cars have multiple CAN buses connected to different subsets of the vehicle systems). At that point it's about the security features implemented by the devices on the network.
> Any car running CANBUS is vulnerable to a potentially fatal attack. They have not resolved this.
There is nothing to resolve at the network level. To put it another way, almost every computer that's ever been hacked over the internet was running Ethernet but that's just as irrelevant as CAN in cars.
If you are able to physically connect to the network, you can talk to and potentially spoof devices on the network.
> A car 25 years old has 99% of the safety features of a modern car and, in good working order, will protect you just the same.
You couldn't possibly be more wrong. Pick your favorite vehicle from 1997 and look up the crash test videos, then compare against a similar recent model.
Here's the most popular vehicle sold in the US, the Ford F-150, from 1997 (https://www.youtube.com/watch?v=_i5EmJBaGeQ) versus one from 2016 (https://www.youtube.com/watch?v=Cou88zi4pMY). You tell me which one you'd rather be in.
You might say, correctly, that the 1997 F-150 is particularly bad, but here you can see a 1997 Volvo V70 versus a 2009 Volvo V70 (https://www.youtube.com/watch?v=msnJK0ce-VM). Volvo has a reputation for building some of the safest vehicles on the road, and even those twelve years show substantial gains in crash performance where the older car's passenger compartment is clearly compromised while the newer one's crumple zones work as intended.
> Or maybe I just don't worry about it because the probability of anything greater than a minor fender bender killing you is pretty high even with modern tech.
Again, absolutely wrong. I say this as someone who's flipped a truck off the road at highway speed and walked away with minor abrasions and bruising from the seatbelt and a few cuts from broken glass as the rest of the truck got ruined but the cab stayed intact. My anecdote is of course statistically meaningless, but the data agrees. Crash fatality rates have consistently trended downward from the '80s until 2020. The main reason modern vehicles have gained so much exterior size without gaining nearly as much interior size is all the space taken up by modern safety equipment, crumple zones, etc.
I'm aware of the NASA/JPL rules for developing safety-critical software[2] but I'm not sure if any car manufacturers follow anything similar.
Does anyone here have any knowledge of the software development practices of any automakers and what they do to ensure safety and reliability? And is there anything else I can do to mitigate this risk (short of buying a very old car, which would have other safety downsides)?
[1] https://en.wikipedia.org/wiki/Sudden_unintended_acceleration [2] http://spinroot.com/gerard/pdf/P10.pdf