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

[Prof. Dr. Peter Bernard Ladkin]

On 2025-05-08 09:57 , Paul Sherwood wrote:
> On 2025-05-07 10:50, Prof. Dr. Peter Bernard Ladkin wrote:
>
>> But I am somewhat confused by the concepts used. .....
>
> I confess even after all this time I still don't fully understand the linguistic nuances is this 
> special "functional safety language", so thank you for your attempt at explanation.

Conceptually it is clear, and has been so for going on for thirty years now. But people (including 
some on the Maintenance Team) develop their own ideas of what they prefer things to mean, rather 
than what things do mean. And then there are the inconsistencies and fudges in the standard itself. 
Including the idea that there are no numerical reliability requirements on safety-critical software. 
(Of course there are. They are directly derived from the SIL of the safety function they implement, 
as I pointed out in my answer to Martyn. But this derived numerical requirement is not assessed or 
enforced because it is largely impractical, as pointed out inter alia by Littlewood and Strigini a 
few years before 61508 was first published.)

>>
>> First, pure software does not have a SIL. Safety functions have SILs.
>
> Excellent. Makes sense. And yet in 26262 world, somehow folks certify (pure) SEooC software to 
> (say) "ASIL B", and then other folks may stick a couple of "ASIL B" things together and call the 
> result "ASIL D". So I am also somewhat confused :)

Yes, you can get confused if you try to take some of the nonsense seriously.

Lots of people use incoherent reasoning about these things. It's like politicians and economics (for 
similar reasons). And some develop practices which they hope work, and can sometimes persuade an 
assessor of that. Some of them even write it up and publish it in RAMS. That happened a decade ago 
with 61508 proven-in-use software assessment. The author was introduced into discussion with three 
software-reliability statisticians and me, and quickly backed out.

>> Can you please tell me what is being asserted here about CTRL OS?
>>
>
> IIUC exida's position is that CTRL OS "is a safety mechanism with very high diagnostic coverage". 
> Not sure if/how this fits with your terminology as expressed above.

Say I am a provider of software to be used in safety functions to the 61508 standard. CTRL OS offers 
certain functions which I need. I have (at least) two options. One is to write them myself. The 
second is to use CTRL OS as part of my software. There are (at least) two decision criteria. One is: 
which option will cost me more (in terms of all resources)? The second is: which option will enhance 
the quality of my product?

I don't see how your response helps answer either of those two questions for me.

Please keep in mind that anyone who chooses Option 2 is going to have to provide evidence to an 
assessor that the development processes along with the 50+ pieces of documentation mandated by 
61508-3 have been followed for the SW. If CTRL OS is to be a part of the software then that 
requirement includes CTRL OS. But I think we have it on record, don't we, that you didn't use such a 
development process for CTRL OS; you probably don't have much of that required documentation.

How are you going to deal with that conundrum?

PBL

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