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

Car companies are in a billion-dollar software war

insideevs.com

Post reply on HN
Print view View original

41–50 of 848 posts

Re: Car companies are in a billion-dollar software war

#41

Post by AlotOfReading »

gjsman-1000 wrote: post #23
rjsw wrote: post #19

Earlier quoted context omitted.

Updating the software in the computers that control the car has traditionally been combined with providing diagnostic support for it through the dealerships, not done OTA. Having an OBDII connector has been mandated in vehicles for a long time, you plug something into it that lets you either listen to CAN bus traffic or reprogram an individual Electronic Control Unit (ECU). Now that all vehicles have entertainment sy…

> The first use case of connecting entertainment systems to a vehicle bus that I can remember was to read some engine settings and turn up the volume on the radio at higher speeds. Is anyone actually begging for this though? And why do you need a full bus? This feels like a luxury car problem that could be solved over I2C or something. I’m reading this whole SDV thing, and outside of using less ECUs, it seems like an…

I2C is also a bus, just one that's less reliable and involves more custom work to use.

A "virtualized OBD-II" is really just a UDS server if I understand what you're trying to convey. UDS is a dumpster fire of a protocol that should be expunged from existence, but my personal feelings aside can be run anywhere you want. That exists. I'm not aware of many systems that directly connect the infotainment processors directly to critical CAN buses. Usually there's an intermediary component to isolate them.

Re: Car companies are in a billion-dollar software war

#42

Post by ghaff »

nickff wrote: post #38
tcmart14 wrote: post #29

Earlier quoted context omitted.

I took an embedded course in university where we programmed the AVR AtMega 328p on the Arduino UNO not using the Arduino libraries and compiler. Make files and setting up an environment. But yea, a single class probably isn't sufficient and also I image a lot of embedded companies have a preference to hire someone already familiar with the chip they are targeting and the toolchain for the stack. I also see a lot of a…

RTOS-based development varies significantly from RTOS to RTOS, so I’m not sure how much it’d help to learn to use one. On the other hand, most fundamental OS knowledge is fully transferable to RTOS, so that would be helpful for embedded developers to understand.

Yes, there’s a ton of specificity. Could probably say that about kernel dev too. But there is a ton of things people do that’s a lot more generalized. Of course I’ve used very little of specific things I got tested on in my day to day over the years.

Re: Car companies are in a billion-dollar software war

#43

Post by tehjoker »

AlotOfReading wrote: post #7
tehjoker wrote: post #3

Earlier quoted context omitted.

I'm not sure this is exactly the problem. It sounds like turning the car into a platform with changeable parts has caused both organizational and technical problems. To be fair, im still not sold that this is an advancement except maybe in simplifying the number of components. I'd prefer the car to work without "updates" and DLC. Why does my car need a firewall??

It's not practical to produce a car that never needs updates. That would be a bug-free system, which is impossible. Since they're going to ship updates anyway, a lot of focus is on minimizing the cost and hence OTA. For what it's worth, I work in this industry and the general rule of thumb is that every increase in validation from QM (standard quality) up to the various levels of safety critical code has up to 10x th…

If you get updates at the dealership, you don’t need a network firewall.

Re: Car companies are in a billion-dollar software war

#44

Post by FrankWilhoit »

tcmart14 wrote: post #29
FrankWilhoit wrote: post #2

Embedded-systems programming is not taught, and no one is willing to pay for training. The result is that development is outsourced to entities that claim, falsely, to have the knowledge. Eventually the consequences of the fact that they do not have the knowledge surface in an undeniable manner, and the only way to cover is to make a great show of a fresh start. (This affects all industries, not just automotive, but…

I took an embedded course in university where we programmed the AVR AtMega 328p on the Arduino UNO not using the Arduino libraries and compiler. Make files and setting up an environment. But yea, a single class probably isn't sufficient and also I image a lot of embedded companies have a preference to hire someone already familiar with the chip they are targeting and the toolchain for the stack. I also see a lot of a…

Programming embedded devices is not the same thing as "embedded-systems programming". The latter means, first and foremost, that the software is not allowed to crash, ever, for any reason, else it is people's lives.

I did some initial requirements work on a system to monitor continuous-web papermaking machinery; the line had to be stopped, physically and completely, within 100ms if anything went wrong, because an uncontained web of paper can literally cut people in half. They wanted, in order to be able to hire, to use one of the embedded flavors of a well-known consumer-grade OS, and I had to prove to them that there was no way to make any of them safe, at any cost. And they knew their hardware, because they had built it themselves.

The absolute last resort is a watchdog timer that hits the reset button if N milliseconds go by without the software telling it it's okay. This is what you have to implement if you are dealing with buggy and undocumented hardware -- as, all too often, you are. Sometimes you can get some doco for $ and an NDA, but then in order to get the real doco it is much more $$$ and a much tighter NDA, and the existence of that option is not even divulged until after things have already gone very far south.

If it were only a matter of reading the top-level doco for this or that chip, there would be no issue.

Re: Car companies are in a billion-dollar software war

#45

Post by tehjoker »

smartmic wrote: post #30

So I have serious thoughts about driving “software defined vehicles” in the future. I mean, and the article has confirmed this sufficiently, the core competence of the established car manufacturers is not software. I don't trust the newcomers like Tesla or the Chinese manufacturers for the time being. In my opinion, the same standards should apply to software in motor vehicles as in the aviation industry. And there c…

Aviation standards are the way they are because if you have an engine problem you can’t pull over to the side of the road. But yes, something approximating these for road conditions is a good idea imo.

Part of me thinks the reason they are doing an integrated system is a combination of economics and convenience for 3 letter agencies to remotely assassinate ppl.

Re: Car companies are in a billion-dollar software war

#46

Post by sillystu04 »

FrankWilhoit wrote: post #44
tcmart14 wrote: post #29

Earlier quoted context omitted.

I took an embedded course in university where we programmed the AVR AtMega 328p on the Arduino UNO not using the Arduino libraries and compiler. Make files and setting up an environment. But yea, a single class probably isn't sufficient and also I image a lot of embedded companies have a preference to hire someone already familiar with the chip they are targeting and the toolchain for the stack. I also see a lot of a…

Programming embedded devices is not the same thing as "embedded-systems programming". The latter means, first and foremost, that the software is not allowed to crash, ever, for any reason, else it is people's lives. I did some initial requirements work on a system to monitor continuous-web papermaking machinery; the line had to be stopped, physically and completely, within 100ms if anything went wrong, because an unc…

Why do the hardware companies make things so difficult?

If I were selling hardware I’d want it to be as open and well documented as possible. So that more people buy it and so that I get credit for all the great stuff people make with my products.

Re: Car companies are in a billion-dollar software war

#47

Post by FrankWilhoit »

maldev wrote: post #28
tonetegeatinst wrote: post #15

Earlier quoted context omitted.

This is all the more frustrating as I'm in the security side if IT, and have been trying to teach myself C and assembly for embedded development and understanding how malware and vulnerability exist in this ecosystem and how I can help address these issues.

You can find router firmware sourcecode online and find pretty egregious vulnerabilities if you're really trying to learn. Alot of embedded stuff is outsourced and doesn't want to waste the computing power for stuff like stack canaries. I recall the following from making a tool for a dlink? router? //Reads a file name foo ReadFilePath() { // Get file name // TICKET 21321: Fixed crash by increasing buffer size char Fi…

The people who actually can do it are not underpaid. These days they are brought in to do cleanup. They can name their price and pick their assignments.

Re: Car companies are in a billion-dollar software war

#49

Post by odiroot »

FrankWilhoit wrote: post #2

Embedded-systems programming is not taught, and no one is willing to pay for training. The result is that development is outsourced to entities that claim, falsely, to have the knowledge. Eventually the consequences of the fact that they do not have the knowledge surface in an undeniable manner, and the only way to cover is to make a great show of a fresh start. (This affects all industries, not just automotive, but…

I've been taught 8051 programming at my university. But I'm an older Gen Y, this could be going away for all I know.

Re: Car companies are in a billion-dollar software war

#50

Post by mihaaly »

smartmic wrote: post #30

So I have serious thoughts about driving “software defined vehicles” in the future. I mean, and the article has confirmed this sufficiently, the core competence of the established car manufacturers is not software. I don't trust the newcomers like Tesla or the Chinese manufacturers for the time being. In my opinion, the same standards should apply to software in motor vehicles as in the aviation industry. And there c…

Projecting that "software had to be fully validated and finalized before the product entered production" was the stale old days and "make the car better over time" (i.e. out being driven) is the bright future by the automotive industry is far beyond worry.

Basically sitting inside a Windows that can kill you.

They all lost their minds putting stakes on software makers. I intentionally avoid the word engineering, engineering is far far away what is built up by the software making industry that is now tasked with being the babckbone of vechicles you put your and your family's life into. The cultures are incompatible.

(disregard mission critical software, their engineers are not proud members of the 'do not finalize, fix it later' bunch, not at all, they are nowhere here)

Post reply on HN