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

[Prof. Dr. Peter Bernard Ladkin]

On 2025-05-07 10:55 , Paul Sherwood wrote:
> .... please take a look at the Safety Assessment Report [2], and let me know your thoughts!
>
> [2] https://marketing.codethink.co.uk/asset/20:ctrl-os-baseline-assessment
>
Congratulations on progress! It looks as if you have reached a milestone.

But I am somewhat confused by the concepts used. The baseline assessment appears to say that CTRL OS 
is <suitable for something> up to SIL 3. That <suitable for something> doesn't occur in, for 
example, your message title. Neither can I extract it from the baseline assessment. People often try 
to use 61508 SILs as if they were some kind of criticality level and a statement such as "assessment 
for CTRL OS to SIL 3" reinforces that impression- But SILs are not criticality levels, and this form 
of words doesn't have a meaning per se without lots of other bits being filled in.

So here is a short explanation of the concepts behind safety requirements (= SILs on safety 
functions) in 61508, followed by a request for you to say what is being claimed in terms of these 
concepts.

First, pure software does not have a SIL. Safety functions have SILs.

Second, a safety function is a function that ensures that the risk attached to an operation O (or a 
collection of operations), that would pose an unacceptable safety risk in the absence of that safety 
function, is acceptable. Safety requirements in 61508 are SILs assigned to safety functions (that 
verb "are" is literal).

Third, a SIL sets the required reliability of the safety function (here, reliability in terms of the 
proportion of allowed failures/the allowed failure rate). It follows that 61508 safety requirements 
are reliability requirements on safety functions.

Fourth, software alone does not have a SIL because running software alone can't result in any unsafe 
situation (except in the case in which the processor on which it is running overheats, which is 
dealt with, usually very effectively, by the hardware people). The software has to be attached to 
some bits and pieces which move, or heat up, or react and it is what those bits and pieces do that 
is monitored and possibly controlled by a safety function. Software is assigned a systematic 
capability (SC). Software essential to executing a safety function F with SIL x is assigned SC x.

Fifth, safety functions are not generic things; they are specific to a safety-related system. There 
is no provision for assigning a SIL to a generic operation independent of the specific system for 
which that operation is acting as a safety function. There is concomitantly no way of assigning an 
SC to generic software which provides various operations of use in building software to run safety 
functions.

Sixth, CRTL OS is generic software. There is no safety-related system it is attached to (such as a 
chemical-reactor pressure vessel), from which SILs for safety functions may be derived and thus SCs 
inherited by the software driving those safety functions.

So, I am puzzled as to what is being asserted. I can't tell from the baseline assessment what is 
being asserted. It is something like the following.

[begin assertion]

CTRL has been assessed by exida to be suitable <for something> to SIL 3 <without a safety function 
being mentioned>

[end assertion]

Can you please tell me what is being asserted here about CTRL OS?

PBL

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