[SystemSafety] An open source vehicle
Peter Bernard Ladkin
ladkin at causalis.com
Wed May 11 09:35:12 CEST 2022
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>
More information about the systemsafety
mailing list