[SystemSafety] Comparing reliability predictions with reality

[Robert P Schaefer]

Hi, Nick, Dewi,

  As a new engineer I was told by more experienced engineers (way back in the early ‘80s) that the 3 rules of (parts and other) vendors is:
    1. the vendor lies
    2. the vendor lies
    3. the vendor lies

   For bespoke fpga work, the effort is a cycle of fpga delivery to board, test by hardware and or software engineers, followed
   by reprogramming up until either “good enough” or end of project/delivery.  Correctness was a judgement call.

   I have online access Rierson’s book and at first glance it significantly overlaps mil-std-2167a, I’ve yet to google both DO-178C
   and the mill std with the 2 terns as keywords in the search, but consider this a reminder for me to go do that.

bob s

On Feb 28, 2025, at 2:39 AM, Nick Tudor <njt at tudorassoc.com> wrote:

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<http://www.tudorassoc.com/>
[http://www.tudorassoc.com/wpimages/wpb4e71a5c_0f.jpg]

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<mailto:dewi.daniels at software-safety.com>> wrote:
On Mon, 24 Feb 2025 at 19:07, Prof. Dr. Peter Bernard Ladkin <ladkin at causalis.com<mailto: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<mailto: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<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>
Manage your subscription: https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
_______________________________________________
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/05d464cd/attachment-0001.html>