[SystemSafety] COTS display certification

SPRIGGS, John J John.SPRIGGS at nats.co.uk
Thu Jul 28 11:43:47 CEST 2016


Matthew,
I do not use SILs or DALs, but in my industry sector we have a legal requirement that says, in effect, that if you have a general purpose program that you configure with data, then those data constitute software as much as the program does.  When that law asks for certain assurance arguments to be documented for software, they have to be made for the program with its configuration and adaptation data.
The criticality of the application data you transact with the program contributes to the formulation of the safety requirements, which in turn indicate the level of rigour that is required in those arguments (via our equivalent of a SIL or DAL).

John
P.S. The law is at http://eur-lex.europa.eu/legal-content/EN/AUTO/?uri=CELEX:02008R0482-20111107&qid=1469698921263

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Matthew Squair
Sent: 27 July 2016 01:25
To: Peter Bernard Ladkin
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] COTS display certification

I've always been a bit fuzzy about the next step though.

If we decide that software will implement this function then the software development processes must satisfy the allocated integrity level.

From a code/data duality perspective I implement a function in software as a mix of data and code. But I can use varying ratios of the two. Logically any integrity processes need to cover both the code and data 'parts' because it's both that are satisfying the functional requirement.

But how does one argue equivalence between integrity processes for code and data? At the aggregate level surely you must be making that argument? And that such integrity is independent of potentially varying ratios of the two in any solution?

Matthew Squair

MIEAust, CPEng
Mob: +61 488770655
Email; Mattsquair at gmail.com<mailto:Mattsquair at gmail.com>
Web: http://criticaluncertainties.com

On 27 Jul 2016, at 3:21 AM, Peter Bernard Ladkin <ladkin at rvs.uni-bielefeld.de<mailto:ladkin at rvs.uni-bielefeld.de>> wrote:


On 2016-07-26 18:33 , jean-louis Boulanger wrote:

In new OCC system, some vital information are displayed on control screen and this informations is
SIL x or DAL x.

Sorry, such a statement is a category mistake.

In IEC 61508, safety *functions* get SILs. Information is not a function, therefore information
cannot get a SIL.

PBL

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




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

***************************************************************************
If you are not the intended recipient, please notify our Help Desk at Email 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.

***************************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20160728/1bde7c8a/attachment.html>


More information about the systemsafety mailing list