Linux in mixed-criticality systems [LWN.net]

Linux in mixed-criticality systems

Posted Dec 14, 2018 15:18 UTC (Fri) by marcH (subscriber, #57642)
In reply to: Linux in mixed-criticality systems by nim-nim
Parent article: Linux in mixed-criticality systems

Just like any other type of product: it depends. The margins are low for low-end cars (the ones manufacturers want to stop selling, see recent GM layoffs for instance) but they're not low for trucks and SUVs and not the ones with... a gazillion electronic gadgets. We all heard countless stories of buyers negotiating harder and for longer and paying thousands of dollars less than the next guy for the same car.

to post comments

Linux in mixed-criticality systems

Posted Dec 15, 2018 10:30 UTC (Sat) by drag (guest, #31333) [Link] (6 responses)

Manufacturers are dependent on car dealerships to push their products onto the buying public. Dealerships depend heavily on post-sale support/maintenance/parts/repair and financing for a huge portion of their profits.

So there is a conflict of interest there. If manufacturers produce 'open' technology that is easy and simple for anybody to repair, provide parts for, and support then they risk alienating the sales goons. So they design vehicles specifically to be anti-serviceable and keep diagnostic tools and software extremely proprietary.

As the technology improves cars should be becoming simpler and easier to repair. The technology and engineering that goes into modern vehicles is incredible, very expensive, and hugely difficult... but the actual execution is still really basic. Hall effect sensors, fuel injectors, temperature sensors, O2 sensors, fuel meters, fuel pumps are all late 1970's early 1980's technology just highly evolved. A effective modern fuel injection system is much simpler and easier to support and repair then a old carbureted system. Parts are cheaper to manufacture on a large scale, too. Which is some of the major reasons why cars moved away from the old tech in the first place.

So, yes, piling on tons of gadgets and features to otherwise basic form of transportation is a big way they can help plump up the profits of their dealer networks.

As is tying computer systems together into big massive proprietary lumps and protecting access and tools required to diagnose with DRM in order to trigger DMCA legislation and making it illegal, or at least extremely difficult, for people to produce third party diagnostic and support tools.

https://www.wired.com/2015/04/dmca-ownership-john-deere/

> General Motors told the Copyright Office that proponents of copyright reform mistakenly “conflate ownership of a vehicle with ownership of the underlying computer software in a vehicle.”

Because of that sort of crap I am extremely weary of any attempt to combine entertainment and vehicle management systems into one big lump. Besides the fact that it's just poor engineering. I just don't trust these people.

Next thing you know they will have to have all sorts of backdoors and encrypted control over firmware that prevents user serviceability because of 'security'. Can't have somebody hack your bluetooth speaker and then updating the firmware for your anti-lock brake system... right? Right?

For tying these systems together in a secure manner it should be very possible to setup one-way communication so that information and logging and other things can flow from vehicle management into the display and networking computers. The protocols should be documented and 'best effort' standards should be established so that third party tools and software can be used to reduce the cost of ownership and increase the value of vehicles for the customers.

I have hopes for companies like Tesla will move the industry away from car dealerships and such things. And I think that things will improved provided the Government resists the temptation of strengthening IP protection legislation for the sake of these major corporations. (which are all already extremely damaging at all levels of society). But until that happens I really am going to stick with buying the most basic cars possible.

Linux in mixed-criticality systems

Posted Dec 18, 2018 13:28 UTC (Tue) by nilsmeyer (guest, #122604) [Link]

Great comment. I think adding a lot of Software in embedded devices also drastically increases the loss in value because of course you can't replace them once they stop receiving updates - although this may be discovered as an additional revenue stream instead of trying to get people to buy new cars.

There really is no good reason for an in-vehicle entertainment system providing anything beyond sound or display output and perhaps networking, since passengers usually have a powerful device like a smartphone or tablet with them which they replace more often than the car. The same also goes for airplanes.

I use the train a lot here in Germany, and while the railway company gets a lot wrong in the software / digitalization realm at least they resisted the temptation to outfit the trains with an entertainment system like you have on some airlines. Instead you can log-in to the on-board wifi over which they also offer a streaming service (persumably with lots of content cached on the train), since people bring their own devices anyways.

> So, yes, piling on tons of gadgets and features to otherwise basic form of transportation is a big way they can help plump up the profits of their dealer networks.

You can diversify a lot in the realm of sales here by offering choices so no two car buys are similar and then upselling the hell out of it - "want the soundsystem? You also have to get the undercoating." I never personally bought a car but from what I hear it's a very unpleasant experience, especially if you don't like to haggle.

Linux in mixed-criticality systems

Posted Dec 20, 2018 0:40 UTC (Thu) by rahvin (guest, #16953) [Link] (3 responses)

You should not trust them and there are significant risks to the convergence model. Look no farther than what's happened with Toyota's unintended acceleration issues after they moved to drive by wire. A code error created a situation where a car would accelerate indefinitely, and the transmission would look the shifter so it couldn't be slipped into neutral and the result was a bunch of fatalities. Toyota is going to pay out a LOT of profits by the time all those lawsuits are over.

And the remarkable thing about these suits was just how long it took and how much legal effort was expended just to prove it. IIRC it took almost 3 years of legal work before a set of lawyers were able to get discovery granted to the source code to the systems that caused the problem and a proper analysis was done.

With the move to drive by wire systems we need government regulations and code quality and testing requirements that protect life safety possibly even a requirement for a switch that turns the whole drive system off while preserving braking and steering or some other failsafe. One of the reasons cars were so bloody reliable from 1990 to about 2008 and didn't have these type of issues was because everything was designed previously as single controllers and ASIC's for every function so that a computer failure would only take out a single system not the whole drivetrain. This convergence is very scary to me and was vindicated by the finding on the Toyota acceleration issue where it was a code quality issue. Life safety needs very high standards and multiple failsafes.

I design roadways for a living and I'm legally required to consider safety before any other variable at the risk of my possible incarceration for failure to do so. I believe vehicle source code should be held to a similar standard.

Linux in mixed-criticality systems

Posted Dec 21, 2018 7:35 UTC (Fri) by murukesh (subscriber, #97031) [Link] (2 responses)

Do you have some reading material on this? I looked through https://en.wikipedia.org/wiki/Sudden_unintended_accelerat... and that article seems to claim that the problem was not with electronics or code, but with the pedal design (and the floor mat). Or are you describing another SUA incident?

Linux in mixed-criticality systems

Posted Jan 3, 2019 16:02 UTC (Thu) by sdalley (subscriber, #18550) [Link] (1 responses)

Lots of gripping stuff for the embedded software engineer here. I found it compulsive reading.

https://embeddedgurus.com/barr-code/2013/10/an-update-on-...
http://www.safetyresearch.net/Library/Bookout_v_Toyota_Ba...

Toyota's Unintended Acceleration

Posted Jan 6, 2019 1:02 UTC (Sun) by marcH (subscriber, #57642) [Link]

Fascinating, thanks.

Whether these bugs are real or not and no matter who "wins" this eventually, Toyota and others should already have learned a lesson the hard way: every time human life is at stake legal costs alone far outweigh any development cost saved by sloppy programming. While a rather low bar it's still a somewhat "good" bit of news.

People cope with getting screwed over again and again by $BIGCORP and the 0.1% but funny enough there's always this line that you really can't cross: they don't like to... die.

Now rebooting my smartphone to work around some memory leak and other random issues...

Linux in mixed-criticality systems

Posted Dec 20, 2018 20:12 UTC (Thu) by kamil (guest, #3802) [Link]

> I have hopes for companies like Tesla

Well, those hopes may be misplaced. Tesla, innovative though it is, has a well-deserved reputation of being extremely proprietary. There are plenty of stories flying around about the difficulties of reverse engineering what its cars do internally, etc.

Heck, recently they announced that they will stop working with third-party body shops and that they want all such repairs to be handled in-house. Compared to Tesla, traditional car manufacturers are a model of openness...