[SystemSafety] An open source vehicle

[Peter Bernard Ladkin]

On 2022-05-10 23:27 , Stefano Costa wrote:
>
> Well actually my understanding is that building safe hardware and software is (also) a matter of independent review and test, and of course this ought not to be done by the same individuals developing or designing the architecture. This is a reason for medium to big corporations perhaps being more into safety, not the only one of course

I suspect there is very much more going on behind the scenes than is evident from brief 
descriptions. It is not as if engine-control SW is not safety-critical - remember Bookout/Toyota. 
That means inter alia that functional safety standards must be fulfilled.

If we are not talking about road vehicles, then we would be talking IEC 61508. (ISO 26262 is the 
appropriate standard for road vehicles, obviously, but I know about 61508 text and much less about 
26262 text.) If you are writing SW nominally conformant with IEC 61508-3, then there are between 50 
and 60 documentation requirements that you must fulfil.

That is a lot of documentation for a single person. It is a lot of work even for a small company. 
Not only that, but it is not as if these requirements are all clear and well-explained. Reading the 
standard and understanding what is thereby required is a non-trivial skill, most efficiently 
practiced by organisations set up to do this as part of their regular business.

A single person can of course write 61508-conformant SW. But this will usually be done through 
subcontracting to an organisation responsible for ensuring that the 61508 documentation requirements 
are fulfilled (and seen to be fulfilled).

And it is not as if all the nominal requirements are rational -- see the comment about subclause 
7.7.2.7.a) below. So the organisation has to know what is rational and what is not rational and must 
fulfil the irrational requirements rationally. That usually requires experience and some negotiation.

IEC 61508 also has some vague guidance on who should review and test, that is, what counts as 
relative independence. Edition 3 will have more specifics on that. (Some credit is due. Theo Hannen 
worked this out in detail for the German mirror committee, where it was discussed on many occasions. 
Some of this work, but by no means all, has made it into the CD of Edition 3).

IEC 61508-8 also says (subclause 7.7.2.7.a) "testing shall be the main validation method for 
software". Anyone intellectually familiar with the science and engineering of SW knows this is, as 
Americans of my generation say, a crock. SW is assigned a Systematic Capability (SC) such that a 
safety function with SILx may be operationally involve SW with SCx (or higher). If the "systematic" 
(that is, design-related) failures of the safety function are intended to be comparably rare with 
random HW failures, then it was already well-known through two simple arguments four years before 
the first publication of IEC 61508 that this rarity of failure is not possible to achieve through 
testing the SW (Littlewood-Strigini in CACM, Butler-Finelli in IEEE TSE) for SC2-SC4.

PBL

Prof. i.R. Dr. Peter Bernard Ladkin, Bielefeld, Germany
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de




-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20220511/5e028993/attachment.sig>