Automotive Software and the Law

As you eluded to there is quite a few system level requirements. For the most part it is a little like DO-128 lite. Most of the system regulations are EPA related broadly in three categories requirements, testing and documentation. There are a lot of industry related agreement on industry wide device compatibility much of it based around various standards.

Contact me offline and I probably point you to specific documents that affect what you are doing.

My personal knowledge is all most all power-train specific.

w..

Here is one for FPGA/ASIC designs:

"Today's safety-critical automotive products require development and tool flows which are proven safe in accordance with ISO 26262," said

qualification reports for software tools used in the development of safety-critical products have been properly assessed in accordance with ISO 26262, reducing the costly efforts needed for tool qualification."

Hans

report-300422187.html

Thanks Hans! Actually, it looks like ISO 26262 covers anything electronic, including the software.

Do you know if it's been adopted into law anywhere?

On 15/03/2017 16:36, Tim Wescott wrote: ..

Hi Tim,

I assume with law you mean if this is the standard that all automotive suppliers/manufacturers tried to adhere to (similar to DO-254 for the avionics market), I so then I believe this is indeed the case.

However, I have no experience with this standard, I just play with FPGA's day in day out...

Regards, Hans.

Actually by "law" I mean "law". Are there regulations in any country or other polity that require companies manufacturing or selling automobiles to adhere to the standard before they can legally sell their wares? Is there anywhere in the world where not following ISO 26262 will have a cop or a government lawyer knocking on your door? Is there anywhere in the world where, before you can offer a newly-designed car for sale, you have to show documentation that proves that you've followed the standard, or regulations based on the standard?

Here's a cynical response: No, no, and no; not until somebody is killed.

Straying off topic, I personally believe that lack of gov regulation is the single biggest weakness of the technology. Imagine what will happen when a steering wheel free car is involved in a fatal crash. The entire fleet will be grounded.

JJS

In Denmark a car model has to be approved by the authorities before it can be sold. The approval is related to safety and pollution, but I'm not sure if there is a formal requirement that the safety argument is based on ISO 26262.

Jacob

Well, yes, I'm pretty sure that's the case in the US. I know there's regulations governing safety features behaving correctly at some point in the process, but I suspect there isn't anything that governs the kind of stuff that can cause faults like Toyota's sudden unintended acceleration incidents.

Well, lack of proper care in the execution, which problem may only be fixed with government regulation.

The entire Toyota fleet wasn't grounded even after several (possibly dozens of) deaths worldwide from unintended acceleration; I'm not sure that steer-by-wire or even autonomous vehicles will be stopped.

It is one thing to provide non critical add on's when it is part of the critical components with real consequences. I believe that the Toyota problem was component failure without an appropriate fail-safe mode even though there was testimony that given the following 24 conditions or so it could have been software. Another example of this type of failure is the GM ignition switches.

It has been a long time since we have seen a fleet shutdown but mandatory few day recalls for ranges of serial numbers are actually quite common.

The ability to flash software has made a real difference in a lot of area's. There are often several versions of software depending on where the vehicle is located.

w..

There was a lawsuit, and a code review by an independent group documented cases where the right combination of normal inputs would cause the throttle pedal position calculation task to die, which in turn would hold the throttle at some high value until the brakes were entirely let off and then reapplied.

They actually replicated the bug on cars on dynos. Search on "barr" and "toyota" and you'll find lots of material.

Would it be law that works that way, or would it be a certification agency?

As I understand, technology has to fulfill certain systems requirements (for a car, things like "can steer", "can brake", "engine warning light"), and there's recognized state-of-the-art how you do that. The law doesn't say your steering column has to work mechanically, but everyone agrees that's a good way to do it. And if you do it differently, you have to prove to achieve equivalent safety.

In Germany, you need a type approval to sell cars to customers (alternatively, customers would have to get that approval themselves). You probably don't get a type approval for a steering column programmed in Visual Basic because you cannot prove its safety.

On the other hand, do you really want to build a car, or are you building components? In that case, the automakers' rules are not less important than laws. Laws don't care about quiescent current; the automaker does. Laws don't care about MISRA or V-model; the automaker does.

Stefan

In order for a certification agency to have the authority to do such, there has to be a law that gives it that power. So, law.

Based on what little I know for sure, automotive safety certification is based on end-product black-box testing. Such testing may make sense when everything is mechanical and all systems are (at least relatively) simple and decoupled, but it's not necessarily sufficient when there's CPUs in the mix.

Might be worth googling "micheal barr group". Emphasis "might"; I still get spam from 'em now and again.

There isn't any that I am aware of. It's all self-regulation. There is MISRA, which is fine as far as it goes.

Lawsuits may stand as legal precedent, but a settlement can't be concluded - even legally - as a recognition that a defect was a cause.

I don't know that either D0-128 or medical device standards actually do that much to enforce any sort of defect rate. At least in the Toyota cases, the logic was more about process than product.

Throw in self-driving cars and abandon all hope. I don't think those can actually be verified nor validated. They'll advance one crash at a time.

There have been fatalities already when the car was on "autopilot".

My point is that the law doesn't say "the brake controller has to be written in programming language X using coding standard Y and development process Z", it just has to be "state-of-the-art". That state-of-the-art is defined by ISO standards and industry rules. If you now want to deviate from that standard, you got to prove equivalent safety. Or get an industry consortium behind you that makes this the new standard. But you don't need to, nor can you, change the law to allow a Visual Basic brake controller.

Stefan

But now /deliberation/ and multiple parties are involved in the decision.

Philosophy can be useful. In this case, should you /design/ the car so that it chooses to kill the driver (by swerving into a brick wall) in preference to killing 10 pedestrians?

Fun, fun, fun.

The trolley problem isn't that fun :)

No, you assign agency to the driver with the automation as subcontractor and shrug if it goes wrong. All the cases I know about there was a strong probability that a human driver would have made the same error.

In effect, the (non)drivers are test pilots.

Unless I'm out of date ( and I am ) none of these things much touch on *actual* hi-rel and improved-provability techniques.

Most, if not all of the ISO standards have to do with chains of documentation.

What are these "drivers" of which you speak?