[SystemSafety] Critical systems Linux

[Peter Bernard Ladkin]

On 2018-11-21 11:35 , grivsta at gmail.com wrote:
> 
> The (similar?) QNX TUV Rheinland certificates can be found here:
> 
> https://www.certipedia.com/fs-products/certificates?cert_id=2323

Interesting (but not hugely informative). The original certificate is signed by a colleague of mine,
Heinz Gall, then-head of FS at TÜV Rheinland, who was on the German National Committee for 61508
(and is still listed as a committee member) but is now retired.

TÜV Rheinland are a little more careful. The certificate speaks of SC3, that is, systematic
capability level 3. They list the specific functions which are assessed by TÜV Rheinland to be
suitable to be included as part of an SC3 safety function.

This is the bit about information hiding. TÜV Rheinland has assessed the development and
accompanying documentation of each of the functions and has judged that, yes, it has been developed
in accordance with SC3 strictures. QNX will of necessity have had to supply proprietary information
in order to achieve that assessment, and the certificate relies on the fact that TÜV Rheinland is
one of the organisations that you might employ to assess your product for conformance to IEC 61508.

The catch will come in the specific conditions that are written in the "manual" for use of the SW.
They will say exactly what properties each SW function was assessed for and what was achieved, that
is, which parts of the systematic capability have been validated by TÜV Rheinland. I read one of
those from way back when TÜV Süd started doing this, for Esterel's SCADE tool suite, kindly shared
with me by one of Esterel's managers many years ago. I found it hard to interpret.

The definition which justifies this is as follows:

[begin quote]
3.5.9
systematic capability

measure (expressed on a scale of SC 1 to SC 4) of the confidence that the systematic safety
integrity of an element meets the requirements of the specified SIL, in respect of the specified
element safety function, when the element is applied in accordance with the instructions specified
in the system manual for compliant items.

NOTE 1 Systematic capability is determined with reference to the requirements for the avoidance and
control of systematic faults (see IEC 61508-2 and IEC 61508-3).

NOTE 2 What is a relevant systematic failure mechanism will depend on the nature of the element. For
example, for an element comprising solely software, only software failure mechanisms will need to be
considered. For an element comprising hardware and software, it will be necessary to consider both
systematic hardware and software failure mechanisms.

NOTE 3 A Systematic capability of SC N for an element, in respect of the specified element safety
function, means that the systematic safety integrity of SIL N has been met when the element is
applied in accordance with the instructions specified in the system manual for compliant items.

[end quote]

So SC 3 merely says that there is a "confidence" that the systematic safety integrity meets the
requirements of SIL 3, when you follow the instructions in the manual.

To be clear (or murkier) about what is going on, here is the definition of software SIL, which says
it is the "systematic capability", which itself is "confidence", in other words an assessor's view,
not a property of the SW itself:

[begin quote]
3.5.10
software safety integrity level

systematic capability of a software element that forms part of a subsystem of a safety-related system

NOTE SIL characterises the overall safety function, but not any of the distinct subsystems or
elements that support that safety function. In common with any element, software therefore has no
SIL in its own right. However, it is convenient to talk about ““SIL N software”” meaning ““software
in which confidence is justified (expressed on a scale of 1 to 4) that the (software) element safety
function will not fail due to relevant systematic failure mechanisms when the (software) element is
applied in accordance with the instructions specified in the system manual for compliant items for
the element””.

[end quote]

What is not clear in all this is exactly what SC3 strictures are. To my mind they are not clear in
the standard.

> The notes in the certificate appear to have weasel words, for example, "in extracts" 
> 
>   * IEC 61508 Parts 1-7:2010 (in extracts)

It will be specified in the manual exactly what has been validated.

> As you have noted, while it is likely that some checking was done, I am not sure of the depth. 

That is the point, I think. I doubt the functions will have been formally verified against a
rigorous specification. And you won't be able to reconstruct the assessor's less-formal reasoning,
because that will in part be based on proprietary information which the accompanying document will
not reveal. It is ultimately a matter of trust. (Even if nominally "formally verified", that is a
matter of trust also, namely in the organisation which performed the verification. Nobody else is
going to read the output of the theorem prover line by line.)

> Is it possible to purchase systems as in the example above and provide assurance without
> re-inventing the wheel, perhaps by leveraging what has been done in the initial certification? 

I understand that that is a process which organisations such as TÜV Süd and TÜV Rheinland are
attempting to introduce. A bit like turning repetitive code into a subroutine.

> Also, what is the relationship between being ISO 9001 certified and then developing assurance to a
> standard? Is it really necessary to have ISO 9001 to apply IEC61508 (I thought the need was implied)
> or could you achieve compliance to IEC61508 without extra effort and not having a certified quality
> system?
ISO 9001 is a business-process standard, so there is not a close relationship, I would say.

PBL

Prof. Peter Bernard Ladkin, Bielefeld, Germany
MoreInCommon
Je suis Charlie
Tel+msg +49 (0)521 880 7319  www.rvs-bi.de





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20181121/c0740851/attachment.sig>