Hacker News Reader

Comment by cpeterso | Hacker News Reader

How much code reuse is there between the firmware in a manufacturer's different car models? I'm surprised there isn't a consortium (like Symbian was) to create a standard firmware kernel to share the benefits (and costs) of testing and auditing the code.

I'm also surprised C is still so commonly used for mission critical software. I understand that C is familiar, has many static analysis tools (to make up for the language's deficiencies), and has a straight-forward translation from C to object code (though only when using simple optimizations). For example, if MISRA-C's coding guidelines disallow recursion, why not design a language that only supports DAG function dependencies?

View on HN

OSEK is a an industry standard rtos that is used by almost all automotive players. It is specifically designed for use in the automotive environment. Toyota actually claimed to use an OSEK compliant rtos, but it later surfaced in this lawsuit that they had written their own implementation that was never certified by an outside organization. OSEK is in the process of being superseded by AUTOSAR, which defines much more than just the os, and included a large hal that allows for plug and play middleware libraries. Unfortunately it isn't economical for every ecu to make use of AUTOSAR: it has heavy resource requirements (> 2Mbyte RAM) and so many applications don't use it.

Also on the horizon is ISO26262, which mandates quality assurance for automotive embedded code in the form of paper trails. Unfortunately due to the huge amount of work required by the standard, some automakers are choosing to ignore it and hope it doesn't become mandatory.

Thanks! I'll read more about OSEK and AUTOSAR.

I'm honestly surprised that this kind of thing is running ANY OS, and not direct hardware control paths. Let alone the fact that they didn't use FB ECC ram... that's even before going down the path of code quality. Not having a safety case for a hardware off or powerdown state... though if they had such a thing, odds are it would have been botched worse than the system to begin with.

Personally, I could never handle the stress of designing or building something like this... I worked in a security software team for a bank for a year, that was about as far as I can get in terms of job stress. Just the same, it seems to me some of these choices were clearly rookie level mistakes that shouldn't have been put in production to control motor vehicles.

I also agree, that it would really make more sense for car mfgs to get together to form some standards for production and core controls. If they're determined to use an actual OS, then it better damned well be the most thoroughly tested OS, running on certified hardware, with certified controls in place.

If you mess up the code in a number of places, people don't die... Tasks that control fast moving and/or heavy machinery, medical devices, etc should have very tight controls in place.... this is the kind of situation where software is and should be treated like an engineering discipline. Most of the time it's more of a craft, this isn't one of them.

> I'm also surprised C is still so commonly used for mission critical software.

If you're surprised at that then you probably have not seen much of the embedded world where (gasp!) assembler is still in use and C is considered a 'high level' language.

A java programmer acquaintance of mine calls C "portable assembly language".

It's not that far from the truth. C was designed to be very close to the machine and allows mixing in of inline assembly.

This latter feature is almost unthinkable in what most people would call high level languages today (Java, C#, Swift, etc).

For better or worse, Java is increasingly being used in embedded scenarios. Blu-ray players are a prime example, but televisions, settop boxes of various kinds also use Java these days.

Java, originally called Oak, was created specifically for programming settop boxes for cable TV.

There have been languages designed for verifiably safe, hard realtime operations. The most interesting one among them is probably Esterel[1] (that compiles to C or even VHDL/Verilog), though I think the language has mostly been supplanted by graphical representations[2]. I believe that such development environments (and other relatively expensive ones like Ada and realtime Java) are mostly used in aviation/defense. I don't know whether it's due to tradition or cost.

[1]: http://en.wikipedia.org/wiki/Esterel

[2]: http://www.esterel-technologies.com/products/scade-suite/

We have to thank such developers for the rise of Ada in High Integrity Computing Systems, outside its original military domain.

I believe that when the recalls occurred, at least several models of Toyota/Lexus cars were affected.

Ultimately, it's impossible to know without being inside. I would imagine there's a fair bit of reuse within each manufacturer and very little sharing between manufacturers

Considering

1) how much other components are shared between manufacturers, and having companies like Delphi Automotive doing a lot of work for many manufacturers

2) how often car manufacturers own parts of each other, and how often these ownership structures change (look at Ford and Volvo and Mazda, or Daimler-Chrysler, etc)

I would imagine there are shared platforms and components, also software, between manufacturers.

Reply on news.ycombinator.com