Hacker News new | ask | show | jobs
by mcqueenjordan 1271 days ago
ISO 26262 is the functional safety standard that automobile manufacturers adhere to. Furthermore, companies with a strong safety culture may also have other safety controls, including MISRA, AUTOSAR, and others. I think reputable car companies take this stuff very seriously, but your concern is also well placed.
7 comments

> I think reputable car companies take this stuff very seriously, but your concern is also well placed.

I trusted Volkswagen because of their reputation. Then the news broke about them systematically lying and breaking the law with respect to engine emissions. Shortly after this came to light, other "reputable car companies" turned out to have been not trustworthy at all.

Yes there are good standards in place and some companies claim to adhere to them but no company should be trusted on their word or reputation alone. The better question is what kind of regulatory oversight is in place to make sure those claiming to adhere to certain standards are actually doing so? Also, how much power do the regulatory organizations have in addressing violators?

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.

My comment was in reply to "I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety"
> I've been out of automotive for 20 years but never met anyone who would compromise normal operational safety.

There is nothing to gain with not taking safety seriously, but fortunes to loose. Many of the software components of traditional automakers are built by suppliers. If a serious safety issue would arise and cause fatalities, the suppliers and the OEMs would not only have to pay enormous amounts in damages, they'd also need to issue recalls that might even pose an existential threat to the company.

I've also never seen intentional compromises, but I've seen unintentional compromises made through ignorance or lack of foresight plenty of times. The bigger automakers seem to be better at this by virtue of developed processes, but what I've seen from smaller companies is terrifying.
I've been out of automotive safety critical software (engine, brake, controllers, etc...) but still have friends in it. Proper best practice is still followed by the likes of Toyota, Jaguar and Ford as the ones I've had experience in. That means the coding standards mentioned. Full requirements->design->implementation with functional unit testing, module unit testing and system testing including using simulators. Multiple people doing reviews, strict standards enforcement. Static analysis and code test coverage aiming for 100% path coverage with testing even when I was doing it. With staff typically staying on projects for the full 5 years of development.

Ford as one I can speak about with knowledge took seriously the cost of recalls versus catching issues in testing. It's massively cheaper to spend money up front to do full process and catch every bug you can than to cover recall costs to update later not even considering liabilities if anything does go pop.

Mistakes of course happen. But they're also rarely working from scratch.

It makes working in modern ways horrific seeing the shoddy shit tossed out to meet consumer gadget deadlines.

Strange you mention Toyota as manufacturer, as they are the one who fucked up with the unintended acceleration issue mentioned earlier. The thing is that they "forgot" to implement the mechanism which ignore gas pedal when both brake and gas pedal are pressed. This was a recommended safety feature for accelerator by wire implementation (egas norm).

Then a few years later they got hit again with one of their suppliers: Takata's killing airbags

Apparently they are still killing people. If owners don't get the airbags replaced, the cars should be impounded.

I just read a story where someone borrowed a car with a Takata airbag in it and was killed.

It's worth noting that ISO 26262 is mostly concerned with preventing faults due to system failure, e.g. spurious hardware faults, hardware degradation over time, etc. As an example, it doesn't have much to say about preventing a child from being misclassified as a bollard. It's a quite robust standard, and one most auto makers (certainly the European ones) have spent a lot of effort processing and following for quite some time now (in my limited experience).

There's a separate standard (ISO 21448) trying to address issues with safety of intent, i.e. maintaining safety when there's no actual fault in the system. (Like the misclassification example.) This one's newer, much less effort has been spent developing it, and even less has been spent trying to follow it. Frankly it doesn't have as much to say. (And how could it? Nobody knows how to solve general classification problems, and especially not with something running on some 20 W max control unit.) This part of the problem space is basically the wild west. Some auto makers do a good effort trying to create safe solutions. Others not so much.

In summary, some of the electronics solutions in the car can probably be trusted to do what they're meant to (e.g. airbags). Others (e.g. lane keeping assist, emergency braking) are still still mostly be safe but certainly warrant keeping your hands on the wheel. Anything approaching fully self driving is at best quite dubious at this point though.

26262 covers system failures that produce unsafety, like broken accelerator sensors. ISO 21448 (SOTIF) covers system failure to detect and respond to the environment appropriately (e.g. does the radar detect small children?), which is also a common concern for people in my experience.

Both are acceptable standards, but ISO 26262 is a behemoth of a standard that most people have never read. Many companies don't even make the full standard available to their development teams, let alone educate people to employ it effectively. Similarly, MISRA is fine in theory, but the practical usage often ends with running code through an automatic checker that can only detect half the rules.

ISO 26262 is optional, and some car makers (e.g. Tesla) may choose not to use it directly; but in general they use another process that they feel provides equivalent safety properties, and feel so strongly enough that they're comfortable substantiating this in the inevitable lawsuits.
I don't know why you would ever think a company takes stuff seriously (well I do, patriotism). What was Dieselgate? Companies are identityless auotmata which simply run amuck until Murphy's Law causes regulators to force them to change.
Iso26262 is the safety standard (a slimmed down version of industrial standard by the way). misra are the coding rules recommended to apply for these standard. Autosar is an OS definition to make modular SW
Autosar is a horrible horrible standard that makes SW worse. I am of the oppinion that AUTOSAR based systems are _worse_ and less safe because of it.

The API itself is decent but the configuration and the ecosystem is a nightmare.

Working on a ECU that at some point during the development had to switch to Autosar, I cannot agree more on this.
There are a number of things under the AUTOSAR umbrella, one of which is a set of C++ coding guidelines, akin to MISRA. This is what the other poster is referring to. Back when I worked at Tesla, we enforced a subset of MISRA rules, and at my current company we enforce a subset of AUTOSAR rules, but use none of the AUTOSAR “platform”.