[SystemSafety] A question about ISO26262

Michael J. Pont M.Pont at SafeTTy.net
Fri Feb 17 11:33:50 CET 2017

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.)




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' <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




From: systemsafety [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' <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”.




From: systemsafety [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> 
Subject: Re: [SystemSafety] A question about ISO26262



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).




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>  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. 




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.html>

More information about the systemsafety mailing list