Note: lists.cip-project.org will be down for maintenance on Wednesday, October 5th, starting at 9AM Pacific Time (4PM Wednesday October 5, 2022 UTC), for approximately one hour.
Re: [C-safe-secure-studygroup] [SystemSafety] Critical systems Linux
Clive Pygott <clivepygott@...>
toggle quoted messageShow quoted text
I'll have a go at your question - FYI my background is system safety management (as in 61508 & DO178) and coding standards (MISRA & JSF++)
You are right that ultimately system safety is a system property. You cannot talk about software doing harm without knowing what its controlling and how it fits into its physical environment. However, a standard like 61508 takes a layered approach to safety. The topmost levels are system specific: how could the system behave (intentionally or under fault conditions) to cause harm? and what features of the architecture (including software requirements) mitigate these risks? This establishes traceability from software requirements to safety.
From the software perspective, under this is the requirement to show that those software requirements related to safety have been implemented correctly, and as usual this has two components:
The validation part aims to improve the (albeit flawed) belief in contiguous behaviour by:
This is the domain of MISRA and JSF++ checking that the code will behave sensibly, without knowledge of what it should be doing.
To get back to the original discussion, it is staggeringly naive to claim that 'I have a safe system, because I've used a certified OS kernel'. I'm sure you weren't suggesting that, but I have seen companies try it. What the certified kernel (or any other architectural component) buys you is that someone has done the verification and validation activities on that component, so you can be reasonably confident that that component will behave as advertised - its a level of detail your project doesn't have to look into (though you may want to audit the quality of the certification evidence).
As I read your original message you are asking 'why can't a wide user base be accepted as evidence of correctness?' The short answer is, do you have any evidence of what features of the component the users are using and in what combination? Is my project about to use some combination of features in an inventive manner that no-one has previously tried, so the wide user base provides no evidence that it will work (again a good few years ago, colleagues of mine were writing a compiler for a VAX and traced a bug to a particular instruction in the VAX instruction set that had an error in its implementation. No DEC product or other customer had ever used this instruction. BTW, DEC's solution was to remove it from the instruction set)
Hope this helps
On Thu, Nov 22, 2018 at 9:24 AM Paul Sherwood <paul.sherwood@...> wrote: