[trustable-software] Additional requirement for trustability

Tue Sep 11 15:23:50 BST 2018

In automotive at least the department is generally called Homologation. These people are charged with a couple of key responsibilities:

1. Assembling the pieces of paper for a product action into the archive that will get released in discovery and may help the argument that the OEM adopted State of the Art, wasn't incompetent/lazy/ignorant etc.

2. When a new product action is announced identifying the pieces of paper that engineering need to create so they can estimate the effort, plan and deliver them prior to launch 18-24 months later.

For a world car this can be quite complex and in part I think what's driving the effort, in the US at least, to attempt to prevent individual states from creating their own unique legislation regulating automated driving vehicles. I'm not 100% sure the value of this because algorithms of the future are likely going to have to deal with handedness, road sign differences, local conventions anyway but that's as I understand the approach at the moment.

If you have interest in this sort of thing then https://autonomousregulationscongress.com/en/ is pretty good value for money and does a good job of conveying the latest thinking in the US.

Keep in mind most (all) automotive OEMS and their reputable Tier One's are members of the SAE. This 'club' is intended as the repository of all things best practice, state of the art and forms the back bone of most liability defenses and is an attempt at a sort of herd immunity. The argument is something like, the last model of the vehicle was demonstrably safe (didn't have this particular fault), here are the changes we made (they were small and incremental improvements), here's the statistics, data, studies, conclusions of the experts in how to engineer x safely. Here's our evidence we followed those recommendations and evidence that what we changed made improvements. SAE have a very close relationship with ISO and IEC and OEMs like the voluntary adoption of their standards because of the collective immunity by adopting best practice.

In Europe it's not so clear to me that IEC 61508 and ISO 26262 are in fact not legal requirements. The three key Type Approval regulations (that apply since the Machinery Directive excludes on road vehicles) - have language like "include but not limited to" when it comes to identifying risk and safety based actions, or they specifically mandate E/E systems by name necessary for safety which current best practice/state of the art brings them into 508 and 262. Incidentally there is a proposal for regulation in progress since May and I've not met an European OEM homologation engineer that believes these 'guidelines' are anything other than required i.e. unwilling to let the company take a risk of finding out in a court. The directives in force in Europe are 661/209, 78/2009 and 79/2009 and freely available from EUR-Lex.  If the call is successful it looks like the plan is to repeal these in favour of a new regulatory document.

Ultimately I think the legal compliance or not discussion is a dead end. Toyota taught us the courts don’t even care to see a specific bug if the overwhelming evidence is that the product wasn't the result of reasonable engineering best practice.

The fundamental question is one that has been debated and argued for many decades now. Do you believe it is possible to predict the failure of electronics using statistical techniques or not? If you don't and there are standards e.g. 13849 that don't, or do and there are standards that are firmly rooted in this 61508 the fact remains we have to describe / defend / justify to our peers, families, friends and children what we are doing and why it is safe. If we get it wrong there will be a chorus of 'told you so' and experts lining up to defend the plaintiff and I don't know any automotive Homologation Engineers whose organization will allow them to take a course of action that puts them out of step with their peers and colleagues - either within or external to their company. ie if we take a new position on a model year 2020 vehicle and it's safer why did the company not adopt this new approach on all their other carlines.

I have some notes on this equation if folk are interested in the derivation. What we are wrestling with is the RHS equation and I think the conclusion that this is basically unknowable / too complex to calculate from first principals (e.g. as 61508/26262) requires - we don’t have 1E9 hours of proven in use and in automotive at least the use case is so general purpose and since we don’t recover units from the field at end of life (crushing vs. e.g. lifting a plane from the ocean floor) and …

[cid:image001.jpg at 01D449A0.62482FC0]

An alternative approach might be to select from several design alternatives - the one that is least likely to fail and then combine that with STAMP/Reliability prediction on the lower complexity subsystems/subcompents/elements.

Jonathan

-----Original Message-----
From: trustable-software <trustable-software-bounces at lists.trustable.io> On Behalf Of Andrew Banks
Sent: Monday, September 10, 2018 5:34 AM
To: 'Trustable software engineering discussion' <trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] Additional requirement for trustability

>> On further thought I'm tempted just to call this "Compliance" rather

>> than "Legality".

Agreed...

Compliance covers legal, regulatory, standards and industry best-practice - there is not necessarily any single "overlap in the Venn Diagram)

For example, IEC61508/ISO26262 are not legal requirements, nor are they even regulatory requirements - however, if the smelly stuff interfaces with the air-con, non-compliance with the applicable standard will not help your case!

A

_______________________________________________

trustable-software mailing list

trustable-software at lists.trustable.io<mailto:trustable-software at lists.trustable.io>

https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180911/1bc6169e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 11803 bytes
Desc: image001.jpg
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20180911/1bc6169e/attachment-0001.jpg>