Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Risk of unsafe software in automobiles?

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 133 posts

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

#91

Post by RealityVoid »

f1shy wrote: post #64

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

I mirror your experience exactly. Well, maybe except the recursion one, that I have not seen... yet.

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

#92

Post by Yujf »

qbasic_forever wrote: post #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…

Problem is that if you do that, you make the road less safe for everyone else

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

#93

Post by smolder »

vel0city wrote: 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.

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.

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

#94

Post by airbreather »

f1shy wrote: post #61
jimbomins wrote: post #20

Earlier quoted context omitted.

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.

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

#95

Post by userbinator »

vel0city wrote: post #87
userbinator wrote: post #79

Earlier quoted context omitted.

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

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.

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

#96

Post by vel0city »

Yujf wrote: post #92
qbasic_forever wrote: post #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…

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.

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

#97

Post by ptmcc »

mikehodgson wrote: post #56
SoftTalker wrote: post #16

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.

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

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.

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

#98

Post by vel0city »

userbinator wrote: post #95
vel0city wrote: post #87

Earlier quoted context omitted.

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

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.

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.

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

#99

Post by melony »

f1shy wrote: post #64

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

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.

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

#100

Post by Sirened »

someweirdperson wrote: post #78
f1shy wrote: post #64

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

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

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.
Post reply on HN