[SystemSafety] systemsafety Digest, Vol 55, Issue 11

Fri Feb 17 12:09:32 CET 2017

>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> wrote:

> Send systemsafety mailing list submissions to
>         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
>
> You can reach the person managing the list at
>         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>
> To: <systemsafety at lists.techfak.uni-bielefeld.de>
> Subject: Re: [SystemSafety] A question about ISO26262
> Message-ID: <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@
> lists.techfak.uni-bielefeld.de] On Behalf Of David Ward
> Sent: 17 February 2017 09:46
> To: 'systemsafety at lists.techfak.uni-bielefeld.de' <
> 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@
> lists.techfak.uni-bielefeld.de] On Behalf Of SPRIGGS, John J
> Sent: 17 February 2017 09:38
> To: 'martyn at thomas-associates.co.uk' <martyn at thomas-associates.co.uk
> <mailto:martyn at thomas-associates.co.uk> >; '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
>
>
>
> 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@
> 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>
> 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@
> 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
> https://lists.techfak.uni-bielefeld.de/mailman/listinfo/systemsafety
>
>
> ------------------------------
>
> End of systemsafety Digest, Vol 55, Issue 11
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20170217/7be272ca/attachment.html>