Live data from Hacker News

Ask HN: Risk of unsafe software in automobiles?

news.ycombinator.com

81–90 of 133 posts

Re: Ask HN: Risk of unsafe software in automobiles?

#81

Earlier quoted context omitted.

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

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.

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.

Re: Ask HN: Risk of unsafe software in automobiles?

#82

Earlier quoted context omitted.

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.

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…

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

Re: Ask HN: Risk of unsafe software in automobiles?

#83
post #7

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 expose…

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 i…

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.

Re: Ask HN: Risk of unsafe software in automobiles?

#84

Earlier quoted context omitted.

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.

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.

Re: Ask HN: Risk of unsafe software in automobiles?

#85
post #47

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.

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

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

Re: Ask HN: Risk of unsafe software in automobiles?

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

Re: Ask HN: Risk of unsafe software in automobiles?

#87
post #7

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 expose…

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 i…

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

Re: Ask HN: Risk of unsafe software in automobiles?

#88

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 w…

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…

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

Re: Ask HN: Risk of unsafe software in automobiles?

#89

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 w…

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…

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

Re: Ask HN: Risk of unsafe software in automobiles?

#90
post #47

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.

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.

Post reply on HN