I don't normally contribute to discussions on this list for fear of being
lambasted, however it seems to me that the point of obtaining certification
for components or tools used in the development of safety critical systems
is being missed.
Surely if a tool or component has been assessed and granted certification
by an agency then what this means is that when the final system integrator
has to build his safety case he can do so more easily. If he has bought
for arguments sake a Gas Analyser that has been assessed by TuV (or another
agency) for compliance with IEC61508 SIL 2 and he wants to use it in his
safety critical application then he can rest assured that the development
process and the tools and techniques that were applied during the creation
of that product were suitable. He doesn't have to audit the manufacturer
himself (at least not so deeply) and that therefore reduces the burden of
work. I say reduces not removes.
The Analyser (or whatever product) should also come with a safety manual
telling him the constraints which apply to its use in a safety critical
system and he should use it within those constraints.
Furthermore if the Analyser itself includes sub-components, maybe an RTOS
and compiler libraries, then he can be assured that the Analyser
manufacturer evaluated and selected suitable sub-components and tested his
product with those in place. The safety manual may reference the safety
manuals of those components and the integrator may ask for further evidence
from the Analyser manufacturer that he used those components in their
constrained 'safe' manner, but at least if the Analyser manufacturer has
done his job properly the integrator won't have to go back to the RTOS
provider and the compiler vendor to assess them. He can once again rest
assured that the component or tool has been developed to an appropriate
standard because the certification agency say so and have also agreed that
their use in the Analyser was acceptable.
If this chain of evidence exists then it must reduce the amount of auditing
work for the Integrator. As systems become larger and more complex this
is surely essential to allow those safety critical applications to be
developed in a useful time frame.
Servomex Group Ltd
Tel: +44 (0)1892 603258
Fax: +44 (0)1892 668954
Nicholas Mc Guire
Sent by: safety-critical@xxxxxx
Re: [sc] Could anybody advise .....
Please respond to
On Thu, 05 Nov 2009, paul cleary wrote:
> > The CASS scheme started after the current version of IEC 61508 was
> > published.
> > My point is quite simple, and to those who understand the 61508
> > standard also obvious. It is not possible in the current state
> > of the art to take a piece of SW-driven kit and establish that in all
> > circumstances, in any application - car, train, power station,
> > children's toy - whatever "dangerous" might mean in that application,
> > this kit will only suffer at most one dangerous
> > failure on average every 10 million to 100 million hours of use
> > (unless that SW is blindingly simple and allows full mathematical
> > verification of its relevant properties). But that is what many people
> > seem to understand when
> > they read "61508 certified to SIL 3" in the marketing literature and
> > that is what people selling you kit "61508 certified to
> > SIL 3" will encourage you to believe.
> Agreed. i dont believe that you can correctly assess a COTS to
determine its ldevel of integrity/assurance without knowing the context it
will work. Which raises the question why the CASS scheme was created.
Looking at the folllowing
http://www.cass.uk.net/PDF's/The%20CASS%20Guide.pdf the list of
bodies/organisation who input into creation of CASS are well know within
I would claim that it's not quite that black or white - but as usual in
functional safety quite a dirty gray.
There are two general paths to distinguish here - which both are a good
for vendors to certify HW/SW according to a generic standard like 61508
- reuse of arguments
- explicid reference
Reuse of argument:
of cours you need to certify it in the sepcific context but the respective
standards also give you a set of methods (61508-7) and if a certain SW/HW
component has shown to be assessable/certifiable in a specific context it
quite likely that a appropriate set of methods is available for a different
(related) context. This is true most notably for derived standards - i.e.
EN 50128 (Ed1) reuses the method catalogue from IEC 61508-7 - so if you had
a IEC 61508 certified piece of SW it atleast would be a lot easier to get
certified according to EN 50128. Also note that 61508 actually has no
specific application domain and thus is quite generic. So cross-referencing
standards - notably those that have a common basis like 61508 - seems to be
a quite realistic path for a safety case.
There are functional safety standards that explicidly allow
resuse of components certified to a generic standard - i.e. 62061:
NOTE 2 In this standard, it is presumed that the design of complex
programmable electronic subsystems or subsystem elements conforms to the
relevant requirements of IEC 61508. This standard provides a methodology
for the use, rather than development, of such subsystems and subsystem
elements as part of a SRECS.
The subsystem shall be realised by either selection (see 6.7.3) or design
(see 6.7.4) in accordance with its safety requirements specification (see
220.127.116.11.7), taking into account all the requirements of 6.2. Subsystem(s)
incorporating complex components shall comply with IEC 61508-2 and IEC
61508-3 as appropriate for the required SIL.
Subsystems incorporating complex components shall comply with IEC 61508-2
and IEC 61508-3 as appropriate for the required SIL.
The subsystem shall be such as to meet all of the requirements a) to c) as
b) the requirements for systematic safety integrity comprising:
- the requirements for the avoidance of failures (see 18.104.22.168), and
the requirements for the control of systematic faults (see 22.214.171.124), or
- evidence that the equipment is `proven-in-use'. In this case, the
subsystem shall fulfil the relevant requirements of IEC 61508-2 (see IEC
61508-2, 126.96.36.199 to 188.8.131.52).
So IEC 62061 provides a clean path for arguing a 61508-3 certified software
component in the context of IEC 62061 complient machinery. Note that 61508
does not really provide any specific context for the certification.
------------ Servomex incoming mail advice ------------
Servomex may, as part of its normal activities, monitor, edit or censor the
content of any information and software, transmitted through, or stored on,
its facilities. Servomex reserves the right to monitor communications, as
required, to protect the legitimate interests of Servomex and its business
---- Servomex company information and outgoing e-mail advice. ----
Servomex Group Limited, Jarvis Brook, Crowborough, East Sussex, TN6 3FB,
Company Registered in England: No.2170458
VAT No.: GB 522 6077 63
This email has been scanned for all viruses by the MessageLabs and contains
information from Servomex which may be privileged or confidential. The
information is intended to be for the use of the individual(s) or entity
named above. If you are not the intended recipient be aware that any
disclosure, copying, distribution or use of the contents of this
information is prohibited. If you have received this electronic message in
error, please notify us immediately. Servomex may, as part of its normal
activities, monitor, edit or censor the content of any information and
software, transmitted through, or stored on, its facilities.
Received on Thu 05 Nov 2009 - 16:09:10 GMT