|
From: emc-pstc@ieee.org on behalf of Kunde, Brian [brian_kunde@lecotc.com]
Sent: Friday, July 20, 2007 9:30 AM
To: emc-pstc@IEEE.ORG
Subject: Interlock Circuits Firmware/Silicon Controlled
I have limited experience working with industrial machines with moving
parts so I would appreciate any help you can provide.
To protect an operator from moving parts, my understanding is that I
have to use an approved interlock device (in this case a switch) and it
has to directly control the device that makes the motion (pneumatic
solenoid).
But on a future project, we would like to have the interlock switch talk
to an FPGA (silicon) and have firmware and software controls the motion
device after many sensor checks are made. These "checks" are quite
complex where many things have to be just right in the right sequence
for the motion to occur. Engineering is saying that the sequence is too
complex to limit with a simple interlock switch system.
Is it possible to use silicon chips, firmware, and software in such a
circuit? Can such an approach be used and if so what is involved in
qualifying it?
Thanks,
The Other Brian
-----
From: emc-pstc@ieee.org on behalf of Doug Nix [dnix@mac.com]
Sent: Friday, July 20, 2007 9:51 AM
To: Kunde, Brian
Cc: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
Brian,
You are correct regarding the interlocking device - it needs to be
designed and rated for this function, and should incorporate 'direct-
drive' or 'positive-drive' type contacts, but this is not a mandatory
requirement.
The interlocking device is not required to have direct control of the
power to the prime mover. This can be done, but is typically limited
to very simple equipment. The interlocking *system* is what must have
final control of power to the prime mover - in this case it sounds
like you are talking about a pneumatic actuator of some kind. This
could be achieved by using a valve in the main pneumatic supply and
the control valve for the actuator to provide you with diverse and
redundant control of the pneumatic power to the actuator. If it is an
electric output, such as a motor starter, then control power to the
controller outputs could be switched, and an additional contactor
installed at the point of supply to the branch feeder to create a
similar condition.
If you want to use a programmable controller as part of your safety
system, it must meet the reliability requirements required based on
the hazards presented by the equipment, so step 1 is a risk assessment.
Step two is to apply the relevant parts of IEC 61508 to the design so
that you can be confident that you have achieved a high enough SIL
(Safety Integrity Level) for the application. There are parts in this
standard that relate to the design and the validation.
If your equipment is reasonably hazardous - meaning that you have
some hazards that will result in severe injuries or possibly a
fatality - you will almost certainly end up with a requirement for
redundant controllers with sophisticated cross-checking. Typical
safety PLC's that meet these requirements often have two or three
processors internally for program control, validated function blocks
for gate interlock inputs, and redundant I/O.
If you plan to market the product in the EU, check to see if it is
included in Annex IV of the Machinery Directive. You can download a
copy at http://tinyurl.com/y8b592, or read it on line at http://
tinyurl.com/2zxnjs. If it is explicitly included in the Annex IV
list, then you will need Notified Body involvement before you market
it. If not, you will need to complete the 'internal production
controls' requirements and keep a Technical File on hand. Don't
forget that there will also be Low Voltage, EMC and possibly other
directives to deal with as well.
If you want to discuss this more off-line I would be glad to chat
with you at your convenience.
--
Doug Nix, A.Sc.T.
IEEE PSES
Kitchener-Waterloo Section, Ontario, Canada
-----
From: emc-pstc@ieee.org on behalf of John Woodgate [jmw@jmwa.demon.co.uk]
Sent: Friday, July 20, 2007 9:57 AM
To: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
In message
<0ED66CD2C9BD0A459D54FB9119A6056768DBEB@mailserver.lecotc.com>, dated
Fri, 20 Jul 2007, "Kunde, Brian" <brian_kunde@lecotc.com> writes:
>Is it possible to use silicon chips, firmware, and software in such a
>circuit?
With considerable difficulty, and no guarantee of success.
>Can such an approach be used and if so what is involved in qualifying
>it?
See IEC 61508.
One aspect to consider is how much of the sensor data is used to protect
the machine from damaging itself rather than injuring the operator.
Protecting the machine is a matter for the manufacturer, unless failure
could result in injury to people; protecting the operator is a matter of
standards and regulation. So you might be able to simplify the operator
protection system by making the machine protection system separate.
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
There are benefits from being irrational - just ask the square root of
2.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
-----
From: emc-pstc@ieee.org on behalf of Ted.Eckert@APCC.COM
Sent: Friday, July 20, 2007 10:02 AM
To: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
Let me add a bit to Doug Nix's comments.
For the United States, the applicable standard is UL 1998.
http://ulstandardsinfonet.ul.com/scopes/scopes.asp?fn=1998.html
I strongly recommend implementing interlocks in hardware. The UL group
that handles software and firmware testing is backlogged and works
slowly.
There will also be limits on what you can do to update electronics and
firmware. The amount of testing required is very extensive because there
are may types of single faults that could occur that may result in a
hazards.
Search for "Therac 25" at Google or some other search engine and you
will
see one of the worst-case results of a reliance on silicon for
interlocks.
Ted Eckert
American Power Conversion/MGE
http://www.apc.com/
-----
From: emc-pstc@ieee.org on behalf of Curt McNamara [mcnam025@umn.edu]
Sent: Friday, July 20, 2007 10:53 AM
To: Kunde, Brian
Cc: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
I am not in approvals, rather a designer of things (many of which have
been industrial). For safety you need an interlock which can easily be
accessed and stops the machine in a safe way. This switch should
interrupt power to the component, and should not depend on any other
circuitry.
There is a lot of sense to this -- who of us wants to trust our safety
to circuits and software? As an example, the FPGA doesn't load
correctly, the clock is lost (a common safety test), there is a
component failure, there is a connection failure. In industrial machines
this last is more common than we like.
Now if you are talking about an enable being complicated and depending
on many things that is OK. However, the circuit which is energized by
this complex logic needs to be disabled by a simple switch. So you could
have a relay that is powered by a chain of logic, one piece of which is
your interlock switch. All the logic needs to be true to enable, and any
of the logic could also disable. However, the interlock is in that
series chain and can also break current without any dependence on other
logic.
Curt
In real life:
Curt McNamara P.E. // senior electrical engineer
Logic Product Development
-----
From: emc-pstc@ieee.org on behalf of Brian O'Connell [oconnellb@tamuracorp.com]
Sent: Friday, July 20, 2007 11:19 AM
To: emc-pstc@IEEE.ORG
Subject: RE: Interlock Circuits Firmware/Silicon Controlled
> -----Original Message-----Ted.Eckert@apcc.com
> Let me add a bit to Doug Nix's comments.
>
> For the United States, the applicable standard is UL 1998.
> http://ulstandardsinfonet.ul.com/scopes/scopes.asp?fn=1998.html
> I strongly recommend implementing interlocks in hardware.
> The UL group
> that handles software and firmware testing is backlogged and
> works slowly.
> There will also be limits on what you can do to update
> electronics and
> firmware. The amount of testing required is very extensive
> because there
> are may types of single faults that could occur that may result in a
> hazards.
>
> Search for "Therac 25" at Google or some other search engine
> and you will
> see one of the worst-case results of a reliance on silicon
> for interlocks.
Indeed, the 'Therac' incident is a good place to start, but this
particular failure mode was not from any hardware or software failure,
but
was from an incorrect user-interface design and control-function design.
But you are very correct in the misplaced reliance on firmware. That is,
it can be argued that there was not 'logical' error in the Therac code,
but an user-interface design flaw that resulted in the machine applying
a
fatal radiation dose to the patient. And the 'seminal' recomendation of
the investigation was to recommend a HARDWARE fix - interlocks to back
up
software control of both electron scanning and beam energy selection.
Software that is safety critical must validate all code paths and
quantify
temporal determinism.
Software that is safety critcal, for most industry devices and consumer
goods, cannot be depended on as the only means of process interrupt and
user protection; an electro-mechanical device must be ultimately relied
on
for protection and fail-safe operation.
Previous posts have listed IEC 61508 and UL 1998 for guidance. I
respectfully add DO-170, IEC R 24731, EN 50129, MIL-STD-882, and this
link: http://www.softwaresafety.net/
luck to code-monkies,
Brian
-----
From: emc-pstc@ieee.org on behalf of Doug Nix [dnix@mac.com]
Sent: Friday, July 20, 2007 11:39 AM
To: Ted.Eckert@APCC.COM
Cc: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
I agree completely with Ted's comments - UL 1998 is a good standard
and certainly applies in the US. For Canadian markets, the IEC
standard still applies since Canada is an IEC country and CSA has no
formal adoption, nor a National Standard on this subject to draw on.
--
Doug Nix, A.Sc.T.
IEEE PSES
Kitchener-Waterloo Section, Ontario, Canada
-----
From: emc-pstc@ieee.org on behalf of John Woodgate [jmw@jmwa.demon.co.uk]
Sent: Friday, July 20, 2007 11:45 AM
To: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
In message <001001c7cae1$4e2d9150$d600a8c0@tamuracorp.com>, dated Fri,
20 Jul 2007, Brian O'Connell <oconnellb@tamuracorp.com> writes:
>IEC R 24731,
That looks highly unlikely to me. The IEC web site doesn't recognize it.
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
There are benefits from being irrational - just ask the square root of
2.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
-----
From: emc-pstc@ieee.org on behalf of Ralph McDiarmid
[ralph.mcdiarmid@xantrex.com]
Sent: Friday, July 20, 2007 1:01 PM
To: emc-pstc@IEEE.ORG
Subject: RE: Interlock Circuits Firmware/Silicon Controlled
Certainly possible, but I suggest that the intention of direct control
interlock is lost by interposing circuit and software.
Ralph McDiarmid, AScT
Compliance Engineering Group
Xantrex Technology Inc.
-----
From: emc-pstc@ieee.org on behalf of Brian O'Connell
[oconnellb@tamuracorp.com]
Sent: Friday, July 20, 2007 1:02 PM
To: 'John Woodgate'; emc-pstc@IEEE.ORG
Subject: RE: Interlock Circuits Firmware/Silicon Controlled
The correct designation is "ISO/IEC TR 24731-1", which is in
publication.
Mr Woodgate is correct that this is not a published std; it is a
Technical
Report of JTC1/SC22/WG14, and has not been incorporated into the C
language standard (IEC 9899). The WG recognizes that the C99 language
standard should not (unlike the constant wholesale changes to product
safety stds) necessarily be revised, but that an 'alternative' path to
safer code should be formally documented. Let the flames begin...
In any case, industrial programmers and compliance engineers ignore
these
IEC/ISO Working Group reports at their own peril. For example, this WG
has
also published some very important papers on Sequence Points, a common
point of failure for trans-platform code, and buffer overruns - the most
common entry point for malware.
ISO/IEC TR 24731 defines a version of the C standard function libraries
intended to be reliable replacements for library functions that are
known
to not be safe; e.g. strcpy(), strcat(), strncpy(), strncat(), gets(),
fileopen(), etc.
I suppose the "most safe" C is defined in the MISRA guide, which has
been
somewhat controversial.
The bottom line is that code cannot provide an inherently safe device.
luck,
Brian
-----
From: emc-pstc@ieee.org on behalf of John Woodgate
[jmw@jmwa.demon.co.uk]
Sent: Friday, July 20, 2007 1:20 PM
To: Brian O'Connell
Cc: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
In message <001301c7caef$b967f1a0$d600a8c0@tamuracorp.com>, dated Fri,
20 Jul 2007, Brian O'Connell <oconnellb@tamuracorp.com> writes:
>The correct designation is "ISO/IEC TR 24731-1", which is in
>publication.
It's still not on the IEC web site, but it is on the ISO site:
ISO/IEC PRF TR 24731-1 Ed. 1 Current stage 50.60 JTC 1/SC 22
Information technology -- Programming languages, their environments and
system software interfaces -- Extensions to the C library -- Part 1:
Bounds-checking interfaces (available in English only)
'Current stage 50.60' indicates that the document is not yet published
(but the web site may not have been updated).
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
There are benefits from being irrational - just ask the square root of
2.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
-----
From: emc-pstc@ieee.org on behalf of Doug Nix [dnix@mac.com]
Sent: Friday, July 20, 2007 1:42 PM
To: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
One more interesting little point - In the ANSI/RIA 15.06 Robot standard
and the CSA Z434 Robot standard, programmable controllers are allowed in
the safety related parts of the control system as long as they are NRTL
approved, or in Canada, approved by an SCC accredited body. There are NO
NRTL's and NO SCC accredited bodies that will certify such a controller
at this time.
In my practice we have allowed EU approved controllers for this purpose,
since they have been reviewed an approved by accredited organizations
under standards which are close adaptations of ISO and IEC standards.
In my opinion, unless you plan to build a significant quantity of the
product it's probably unwise to try to 'roll your own' software based
safety controller. Hardware is well proven and well accepted for good
reason.
--
Doug Nix, A.Sc.T.
IEEE PSES
Kitchener-Waterloo Section, Ontario, Canada
-----
From: emc-pstc@ieee.org on behalf of Jim Eichner
[Jim.eichner@Xantrex.com]
Sent: Friday, July 20, 2007 2:14 PM
To: emc-pstc@IEEE.ORG
Subject: RE: Interlock Circuits Firmware/Silicon Controlled
This thread has missed one major standard: UL991 “Standard for Tests for
Safety-Related Controls Employing Solid-State Devices”, which in the
scenario presented would be needed ALONG WITH UL1998 for the software,
and the right approvals on whatever electro-mechanical device ultimately
opens or closes a circuit. The UL991 requirements are a mix of EMC
immunity and environmental withstand, with FMEA used to determine what
components/subsystems require testing.
Jim Eichner, P.Eng.
Compliance Engineering Manager
Xantrex Technology Inc.
-----
From: emc-pstc@ieee.org on behalf of Nick Williams
[nick.williams@CONFORMANCE.CO.UK]
Sent: Friday, July 20, 2007 3:44 PM
To: Kunde, Brian
Cc: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
My experience of this field is limited mainly to the EU/CE marking
issues rather than requirements for the US, but it's a subject I've
been watching for years. I can tell you that this is a hot topic the
debate over which has been building up over some years and shows no
signs of cooling off any time soon.
You will get differing opinions from different people you talk to -
and, in particular, manufacturers of 'safety PLC's' (i.e.
programmable logic controls designed specifically for safety related
applications) will tell you things about the acceptability of their
devices which are not necessarily agreed with by other sectors of the
industry.
Currently, I know of no machinery 'type C' standard which permits the
use of programmable logic for safety functions (also known as
'programmable safety systems' or 'PSS') and while this by no means
prevents such systems being used, it does present some interesting
challenges for the designer who needs to be able to justify that
their machine will remain safe under foreseeable all conditions of
use. One of the fundamental challenges of using PSS is that the
Machinery Directive requires the manufacturer to compile a technical
file which shows how the machine compiles with the essential
requirements of the Directive. When a designer uses a PSS, it's very
difficult to create a file which does not, at some level or other,
rely on a certificate from a test house as evidence that a PSS will
work as intended, as opposed to a reasoned argument which is what the
directive actually requires.
As was mentioned by Doug Nix, if you happen to deal with machines
which fall into Annex IV of the Directive, the use of PSS will raise
some issues which might not otherwise arise. The involvement of a
Notified Body in the CE marking of Annex IV machines can be limited
to the lodgment of the Technical File in cases where the appropriate
type C standard has been full complied with, but since, as I have
already mentioned, no type C standard currently permit PSS to be
used, this means that for annex IV machines with a PSS, a type
approval will be required. This is a much more time consuming and
expensive process and, in my experience actually adds very little
value to the machine as far as the manufacturer is concerned.
Several other replies to this enquiry have mentioned IEC 61508,
apparently in ignorance of the existence of EN 62061:2005, "Safety of
machinery. Functional safety of safety-related electrical, electronic
and programmable electronic control systems" which is, in effect, an
adaptation of IEC 61508 to machine control applications. It is
harmonised under the Machinery Directive and it is definitely the
starting point for anyone thinking of using PSS in machine control
applications.
I may have come across as being overly negative but let me say that I
am in general in favour of using programmable safety systems - if
properly applied they are certainly no less safe than the
alternatives and can very likely be safer. They will almost certainly
be cheaper and more convenient for machines of any size. However,
they present a very different set of challenges to those which most
small machinery designers who are otherwise only used to dealing with
hardwired controls are used to, and meeting these challenges is not
trivial. I would certainly not advise any manufacture of machinery to
decide to follow this path without a good deal of initial thought and
investigation, especially if they intend to build their own
electronics.
Nick.
-----
From: emc-pstc@ieee.org on behalf of John Woodgate
[jmw@jmwa.demon.co.uk]
Sent: Friday, July 20, 2007 4:21 PM
To: emc-pstc@IEEE.ORG
Subject: Re: Interlock Circuits Firmware/Silicon Controlled
In message <p06240806c2c6b81bf4af@[192.168.1.145]>, dated Fri, 20 Jul
2007, Nick Williams <nick.williams@conformance.co.uk> writes:
>Several other replies to this enquiry have mentioned IEC 61508,
>apparently in ignorance of the existence of EN 62061:2005, "Safety of
>machinery. Functional safety of safety-related electrical, electronic
>and programmable electronic control systems" which is, in effect, an
>adaptation of IEC 61508 to machine control applications.
Well, in fact it's the European implementation of IEC 62061, as you can
tell by the number starting with 6 - home-grown CENELEC standards start
with 5.
From the IEC web site:
IEC 62061 (2005-01)
Safety of machinery - Functional safety of safety-related electrical,
electronic and programmable electronic control systems
Maintenance Result Date: 2007
IEC 62061 Corr.1 (2005-07)
Corrigendum 1 - Safety of machinery - Functional safety of
safety-related electrical, electronic and programmable electronic
control systems
I don't think it's easy to understand 62061 without also reading some of
the 61508 series.
--
OOO - Own Opinions Only. Try www.jmwa.demon.co.uk and www.isce.org.uk
There are benefits from being irrational - just ask the square root of
2.
John Woodgate, J M Woodgate and Associates, Rayleigh, Essex UK
###
The IEEE Product Safety Engineering Society
is seeking an author to write an article for our
Newsletter as a
follow-up to this discussion. If you are interested please contact
. Refer to the information
page or download the
author's guide.
 Back
to The Product Safety Engineering Society | |
