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

[Martyn Thomas]

Peter

Thamks for the clear explanation of the meaning of SIL and SC in 61508.

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. Can that 
assessment be partitioned so that most of the assessment can be reused 
in the context of a different safety function?

Martyn

On 07/05/2025 10:50, Prof. Dr. Peter Bernard Ladkin wrote:
> 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
>
> _______________________________________________
> 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/20250507/f4c84a12/attachment.html>