[SystemSafety] systemsafety Digest, Vol 55, Issue 11

Fri Feb 17 18:48:43 CET 2017

Andy,

You note:

“a SIL4 process will not guarantee that a non-SIL4 element cannot affect SIL4 elements”

I think we are singing from the same (or a similar) hymn sheet.  

I have looked (again) at Rod’s paper.  It is clear that a lot of care went into this design, which would increase my confidence that the system would work as expected.  

However, the claims being made here (for Freedom From Interference) appear to be rather stronger than this.

Michael.

From: Andy Ashworth [mailto:Andy.Ashworth at ottawa-lrt.ca] 
Sent: 17 February 2017 13:42
To: M.Pont at SafeTTy.net
Cc: Rod Chapman <roderick.chapman at googlemail.com>; systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] systemsafety Digest, Vol 55, Issue 11

Michael

Surely software architecture would be part of the SIL4 process so there is process assurance that separation of modules has been addressed. The word "interfere" is though a very broad term... from the safety and integrity perspective, a SIL4 process will not guarantee that a non-SIL4 element cannot affect SIL4 elements, what will be assured will be that the failure modes of the non-SIL4 elements will have been identified and that such failures will not compromise the safety of the SIL4 functions. If the SIL4 elements "fail-safe" then the lower integrity units will only affect reliability and operability, not safety.

Best regards

Andy

Sent from Andy's iPad

Sent from Andy's iPad

On Feb 17, 2017, at 08:16, Michael J. Pont <M.Pont at SafeTTy.net <mailto:M.Pont at SafeTTy.net> > wrote:

Rod,

Your development process would increase my confidence that your system would work correctly.

However - if you wished to claim that your ‘not SIL 4’ software modules could not interfere with your ‘SIL 4’ modules - I would still be sceptical.

Michael.

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Rod Chapman
Sent: 17 February 2017 11:10
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] systemsafety Digest, Vol 55, Issue 11

>Michael wrote
>
>Every time I?m told that ?Software Component A? cannot interfere with ?Software Component B? I?m sceptical.

In 1996, we built SHOLIS - it had both SIL4 and "not SIL4" software modules running in the same single-threaded program in the same address space, on a bare-metal target (a 68020 no less), with no RTOS, MMU or hardware-enforced separation.

We argued separation by _lots_ of static analysis, including proof, information flow analysis, WCET, termination for all but the main loop, and worst-case analysis for I/O buffers being (not) filled and emptied adequately fast. Apart from about 10 lines of assembly language to boot the CPU, it was all SPARK Ada. Full story in IEEE Tr on SE, August 2000.

 - Rod

On 17 February 2017 at 11:00, <systemsafety-request at lists.techfak.uni-bielefeld.de <mailto:systemsafety-request at lists.techfak.uni-bielefeld.de> > wrote:

Send systemsafety mailing list submissions to
        systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> 

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
or, via email, send a message with subject or body 'help' to
        systemsafety-request at lists.techfak.uni-bielefeld.de <mailto:systemsafety-request at lists.techfak.uni-bielefeld.de> 

You can reach the person managing the list at
        systemsafety-owner at lists.techfak.uni-bielefeld.de <mailto:systemsafety-owner at lists.techfak.uni-bielefeld.de> 

When replying, please edit your Subject line so it is more specific
than "Re: Contents of systemsafety digest..."

Today's Topics:

   1. Re: A question about ISO26262 (Michael J. Pont)

----------------------------------------------------------------------

Message: 1
Date: Fri, 17 Feb 2017 10:33:50 -0000
From: "Michael J. Pont" <M.Pont at SafeTTy.net <mailto:M.Pont at SafeTTy.net> >
To: <systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> >
Subject: Re: [SystemSafety] A question about ISO26262
Message-ID: <007a01d28909$54bbf200$fe33d600$@SafeTTy.net <mailto:007a01d28909$54bbf200$fe33d600$@SafeTTy.net> >
Content-Type: text/plain; charset="utf-8"

A general point.

Assume we have a single processor plus software.

Every time I?m told that ?Software Component A? cannot interfere with ?Software Component B? I?m sceptical.

(If I?m told that it will be possible to detect that Software Component A has interfered with / attempted to interfere with Software Component B, I?m - sometimes - less sceptical.)

Michael.

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of David Ward
Sent: 17 February 2017 09:46
To: 'systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> ' <systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> >
Subject: Re: [SystemSafety] A question about ISO26262

A couple of comments:

*         Just to clarify something on the OP?s comments, there is not a 2016 version of ISO 26262.  Edition 2 is due to be published in early 2018.  The DIS was released for comment and vote earlier this year and some parts did carry a 2016 date, but as a draft concepts, definitions, etc. are of course subject to change.

*         There are proposals in Edition 2 to include more information on ?dependent failure initiators?, the intention is to give guidance on the types of failure modes that could cause loss of freedom from interference or loss of independence.  I believe the intention is this would cover situations where an element is operating normally but still causes an issue with another element (e.g. through a timing conflict).

Best regards

David

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de <mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de> ] On Behalf Of SPRIGGS, John J
Sent: 17 February 2017 09:38
To: 'martyn at thomas-associates.co.uk <mailto:martyn at thomas-associates.co.uk> ' <martyn at thomas-associates.co.uk <mailto:martyn at thomas-associates.co.uk>  <mailto:martyn at thomas-associates.co.uk <mailto:martyn at thomas-associates.co.uk> > >; 'systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> ' <systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de>  <mailto:systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> > >
Subject: Re: [SystemSafety] A question about ISO26262

If you are looking for the document Martyn mentions below, open the UK CAA?s ?Air Traffic Services Safety Requirements? at http://www.caa.co.uk/cap670 and go to Part B, Section 3, which is called ?SW 01: Regulatory Objectives for Software Safety Assurance in ATS Equipment?.

John

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de <mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de> ] On Behalf Of Martyn Thomas
Sent: 16 February 2017 18:16
To: systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de>  <mailto:systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> >
Subject: Re: [SystemSafety] A question about ISO26262

David,

I'll use the standard's term "element" as a generic word for functions, processes and other bits of software, as I don't have the standard available and it's not necessary to be more precise to make the point that I want to make.

It's certainly possible for an element to meet its functional specification whilst preventing another element from doing so - for example by taking too many processor cycles, or holding a shared resource, or by using storage that is also being used by another element.

Drew has expressed his view that an element that "spams" another has failed, and I wouldn't disagree. But the practical question will often focus on the assurance that a safety-critical function cannot be disrupted by other elements, and it will generally be impractical to assess the total possible behaviour of every system element in order to assure the safety critical elements. In practice it will be necessary to show that the safety-critical functions cannot be disrupted by any elements at a lower assurance level (DAL, SIL or whatever) and this will in general require architectural protection (e.g. separate processors or a high integrity scheduler and supervisor). I think the UK CAA standard SW01 may have addressed this in some detail (if not, I'm fairly sure there's a paper by Adelard on the subject, possibly written by Robin Bloomfield).

Regards

Martyn

On 16/02/2017 10:37, David Haworth wrote:

However, it is possible to imagine scenarios where, in the absence
of a protection mechanism, an element causes another element to fail
while still continuing to perform its own function flawlessly.

  _____

If you are not the intended recipient, please notify our Help Desk at Email Information.Solutions at nats.co.uk <mailto:Information.Solutions at nats.co.uk>  <mailto:Information.Solutions at nats.co.uk <mailto:Information.Solutions at nats.co.uk> >  immediately. You should not copy or use this email or attachment(s) for any purpose nor disclose their contents to any other person.

NATS computer systems may be monitored and communications carried on them recorded, to secure the effective operation of the system.

Please note that neither NATS nor the sender accepts any responsibility for viruses or any losses caused as a result of viruses and it is your responsibility to scan or otherwise check this email and any attachments.

NATS means NATS (En Route) plc (company number: 4129273), NATS (Services) Ltd (company number 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd (company number 3155567) or NATS Holdings Ltd (company number 4138218). All companies are registered in England and their registered office is at 4000 Parkway, Whiteley, Fareham, Hampshire, PO15 7FL.

  _____

HORIBA MIRA Ltd

Watling Street, Nuneaton, Warwickshire, CV10 0TU, England

Registered in England and Wales No. 9626352

VAT Registration  GB 100 1464 84

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170217/23bb0848/attachment-0001.html>

------------------------------

Subject: Digest Footer

_______________________________________________
systemsafety mailing list
systemsafety at lists.techfak.uni-bielefeld.de <mailto:systemsafety at lists.techfak.uni-bielefeld.de> 
https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety

------------------------------

End of systemsafety Digest, Vol 55, Issue 11
********************************************

_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE <mailto:systemsafety at TechFak.Uni-Bielefeld.DE> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170217/31ce16c8/attachment-0001.html>