[SystemSafety] Comparing reliability predictions with reality

[Nick Tudor]

Re Hardware
>>
What I found in practice was hardware faults that were never going to be
resolved or were resolved in closed door meetings that I was not allowed

  to attend, because the hardware were signed off as working, or the
politics of billion dollar procurement and need to keep the money
>>
I understand from studies undertaken with people on this list, that some
companies make available firmware for their processors. They may make
little or no claims for the correctness of that very low level code and in
assessing the repositories for some of this it has been found to have
little evidence to support making claims for correctness. The disclaimer
(if there is one), is that this is supplied as examples and it is for the
user to build their own or/and verify themselves. However, on checking,
quite often these are used ‘out of the box’.

This might give the illusion to some that software (applications) therefore
can have a ‘reliability’ attributed to it/them.

In other quiet conversations with hardware developers, it seems that even
the publicly declared hardware behaviour might not actually be the
behaviour, even accounting for manufacturing variability (that is, known
variability, which is often accounted for in avionics applications; it gets
a bit ‘Rumfeldian’ from here on!)

Avionics hardware typically has to be ‘qualified’ for use and this involves
a lot of effort to ensure that it behaves as needed prior to entering
certification.

Nick Tudor
Tudor Associates Ltd
Mobile: +44(0)7412 074654
www.tudorassoc.com

*77 Barnards Green Road*
*Malvern*
*Worcestershire*
*WR14 3LR*
*Company No. 07642673*
*VAT No:116495996*

*www.aeronautique-associates.com <http://www.aeronautique-associates.com>*


On Thu, 27 Feb 2025 at 16:57, Dewi Daniels <dewi.daniels at software-safety.com>
wrote:

> On Mon, 24 Feb 2025 at 19:07, Prof. Dr. Peter Bernard Ladkin <
> ladkin at causalis.com> wrote:
>
>> On 2025-02-24 19:55 , Robert P Schaefer wrote:
>> > hi,
>> >
>> >    You have me there, I can’t speak to DAL A and would like to know
>> more.
>> >
>> >    Could you reference a software engineering or computer science
>> textbook that covers the topic?
>>
>> I can't, but others here (such as Dewi Daniels) maybe can. The relevant
>> standards are RTCA DO-178C
>> and RTCA DO-333. They of course cost money, but NASA has oodles of tech
>> reports on the topic.There
>> are NASA experts on this list who could say more.
>
>
> The best book I have read on DO-178C is Developing Safety-Critical
> Software: A Practical Guide for Aviation Software and DO-178C Compliance by
> Leanna Rierson. Leanna is a former Chief Scientific and Technical Advisor
> for airborne software at the FAA and she was a member of the committee that
> wrote DO-178C.
>
>
> https://www.routledge.com/Developing-Safety-Critical-Software-A-Practical-Guide-for-Aviation-Software-and-DO-178C-Compliance/Rierson/p/book/9781439813683
>
> https://books.google.co.uk/books?id=R0vRBQAAQBAJ&printsec=frontcover&redir_esc=y#v=onepage&q&f=false
>
> Yours,
>
> Dewi Daniels | Director | Software Safety Limited
>
> Telephone +44 7968 837742 | Email dewi.daniels at software-safety.com
>
> Software Safety Limited is a company registered in England and Wales.
> Company number: 9390590. Registered office: Fairfield, 30F Bratton Road,
> West Ashton, Trowbridge
> <https://www.google.com/maps/search/30F+Bratton+Road,+West+Ashton,+Trowbridge+,+United+Kingdom%C2%A0+BA14+6AZ?entry=gmail&source=g>,
> United Kingdom
> <https://www.google.com/maps/search/30F+Bratton+Road,+West+Ashton,+Trowbridge+,+United+Kingdom%C2%A0+BA14+6AZ?entry=gmail&source=g>BA14
> 6AZ
> <https://www.google.com/maps/search/30F+Bratton+Road,+West+Ashton,+Trowbridge+,+United+Kingdom%C2%A0+BA14+6AZ?entry=gmail&source=g>
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE
> Manage your subscription:
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/pipermail/systemsafety/attachments/20250228/37b2c157/attachment-0001.html>