[SystemSafety] systemsafety Digest, Vol 55, Issue 11
Peter Bishop
pgb at adelard.com
Mon Feb 20 14:45:30 CET 2017
Looks like you were using SIL4 techniques
for the non SIL4 functionality
- which would be OK
Peter Bishop
Adelard
On 17/02/2017 11:09, Rod Chapman wrote:
>>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
> <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>
> 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>
> 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
> <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
> <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
> <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
>
--
Peter Bishop
Chief Scientist
Adelard LLP
24 Waterside, 44-48 Wharf Rd, London N1 7UX
http://www.adelard.com
Recep: +44-(0)20-7832 5850
Direct: +44-(0)20-7832 5857
Registered office: Stourside Place, Station Road, Ashford, Kent TN12 1PP
Registered in England & Wales no. OC 304551. VAT no. 454 489808
This e-mail, and any attachments, is confidential and for the use of
the addressee only. If you are not the intended recipient, please
telephone 020 7832 5850. We do not accept legal responsibility for
this e-mail or any viruses.
More information about the systemsafety
mailing list