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…
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…
Ask HN: Risk of unsafe software in automobiles?
111–120 of 133 posts
Re: Ask HN: Risk of unsafe software in automobiles?
#112Don'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.
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.
Re: Ask HN: Risk of unsafe software in automobiles?
#113Thoughts 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…
The industry has also recently seen the introduction of ISO21434, cybersecurity engineering standard for road vehicles.
Re: Ask HN: Risk of unsafe software in automobiles?
#114Don'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.
>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.
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.
Re: Ask HN: Risk of unsafe software in automobiles?
#115No 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…
I’m talking about human written code, meant to be read, maintained, debugged and tested by other humans.
Re: Ask HN: Risk of unsafe software in automobiles?
#116No 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 ne…
I meant, they do not know what a debugger is. As stated, they use "cout > 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.
Re: Ask HN: Risk of unsafe software in automobiles?
#117Earlier quoted context omitted.
> 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: s…
> 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 scar…
Re: Ask HN: Risk of unsafe software in automobiles?
#118Earlier quoted context omitted.
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 pa…
Re: Ask HN: Risk of unsafe software in automobiles?
#119I 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.
Re: Ask HN: Risk of unsafe software in automobiles?
#120Earlier quoted context omitted.
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…