[SystemSafety] Baseline Safety Assessment for a Linux-based OS to SIL 3 /ASIL D

[Prof. Dr. Peter Bernard Ladkin]

On 2025-05-07 19:47 , Martyn Thomas wrote:
>
> When a safety function requires a SIL 1 reliability and is implemented using/incorporating a 
> software component such as an operating system, it seems that the component/OS is assigned SC 3 
> and assessed in the context of the use of that component by the specific safety function.
>
I assume you meant "safety function requires a SIL 3 reliability" ..... "component/OS is assigned 
SC3" ...

> Can that assessment be partitioned so that most of the assessment can be reused in the context of 
> a different safety function?

Ideally yes. But the most obvious way of doing so violates some of the presumptions that people 
using 61508 hold dear.

First, if software drives your safety function and the safety function has SIL x, then it surely 
must follow that <software failure that results in safety function failure> can only occur with a 
frequency given explicitly by the SIL. For "continuous" functions that would be less than 1 in 
10^(-5) per ophour for SIL 1, less than 1 in 10^(-6) per ophour for SIL 2, less than 1 in 10^(-7) 
per ophour for SIL 3 and less than 1 in 10^(-8) per ophour for SIL 4 (derived from Table 3, p34 of 
61508-1:2010). But, for reasons which I do not understand, it is currently regarded as taboo to set 
numerical reliability rates for software.

If one were allowed to do so, it is surely possible to say the following. Consider an OS function OF 
used in safety-function software S for a safety function F with SIL x, for which the hardware has 
\epsilon failure rate, then the software failure rate acceptable for F must not exceed 1 in 
(10^(-(x+4)) + \epsilon). If we make the conservative assumption that a failure in OF results in 
failure of S, then there is an arithmetical relation between <allowable failure rate in OF> and 
<allowable failure rate in S assuming failure rate of OF is 0) and the target of 1 in (10^(-(x+4)) + 
\epsilon).

Now, in my opinion it is fine to perform those sorts of calculations, and even to turn them into 
resulting numerical "reliability requirements" for software (including OF and S considered 
"separately" if you will, according to some apportioning of failure between OF and S). But what is 
not currently possible is dependably to assess the software in question (OF / S) to determine if it 
actually fulfils the reliability requirements so derived.

All you can say is that (a) the developers did this-and-this; (b) we currently think this-and-this 
enhances the chance that the software is dependable; (c) ... and we have following historical 
evidence for Assertion b. Of this chain of reasoning, most of Assertion c is missing.

That is in part why 61508 continues to "fudge".

PBL

Prof. Dr. Peter Bernard Ladkin
Causalis Limited/Causalis IngenieurGmbH, Bielefeld, Germany
Tel: +49 (0)521 3 29 31 00