Re: [foxboro] Measuring Overall System Reliability

Hank and Ted,
        We, too, have migrated from CP-10's, WP-20's, AP-20's, and Legacy
FBM's over the years.  We now have a mix of CP-30's, CP-40A's, CP-60's,
AW51B's, WP/AW51D's, Leagcy and 200 series I/O.  We recently purchased two
XP AW's to try to utilize the MODBUS TCP and OPC IOGates and Hank, I'd have
to agree with your sentiment about IA on the Microsoft platform.  It is
pretty weak with a whole host of new problems to mess with our heads, not
the least of which was contraction of a network virus almost immediately.
        The bottom line is that the less you upgrade your hardware and
software the higher your system reliability is likely to be, up to a point.
You probably moved from CP-10's, WP-20's and AP-20's because their
reliability and capability wasn't good enough to suit your operational and
maintenance needs.  That is why we moved on.  Every time new software or
equipment is introduced, so are a host of new problems associatied with
them.  That is the nature of the beast.  Communicating those problems to
affected users and getting them fixed in a reasonable timeframe is where
Foxboro really struggles.  They either need to do more stringent testing
before release, or dedicate significant resources to quickly respond to the
problems that they have unleashed on a large user base.
        The functionalities of the 200 series FBM's, although better than
the Legacy FBM's, don't provide us with enough advantages to justify
replacing the existing Legacy FBM's.  It is costly because they don't fit
into the Legacy I/O racks and require an expensive CP-60 to boot.  The only
way I can justify the change is by the fact that the legacy FBM's are
electronic modules that are 15+ years old and I know that they are
eventually going to reach their electronic life and begin to fail at a much
higher rate.  When they do, there will be a limited number of replacements
available before they are completely gone.  If we don't have a replacement
plan in place, we are going to have to really scramble to keep the plant
running.
        Updating the CP's has been less of a challenge because we have
replaced as many as 6 CP-10's/30's with a single FT CP-60 and have utilized
the advantage upgrade pricing plus gained additional functionality that we
needed anyway.  The biggest challenge in that was getting an opportunity to
do the required software upgrades that support the CP-60's and outliving the
new bugs introduced by it.  The FBM's are another matter entirely.  There
are many more of them, no advantage upgrade, and no significant increase in
functionality for us at this time.  Don't get me wrong, they are a no
brainer when installing new processes and I/O but it is hard to justify
replacing Legacy I/O if you are experiencing 99.99% online time.  By the way
Ted, I liked your "MAGIC of NINES" table.
        We have had very few downing events also.  We had one in the mid
90's that was the result of CP FT Sequencer errors that were introduced with
a Version 3.X release, one associated with Nodebus extender communication
errors, and the one associated with the loss of CP-60 fieldbus
communication.  We experience an average of 9 FBM failures/year spread out
over 1853 total FBM's in our system.  The failures range from individual
point failures to total FBM, (red dead).  During our last EEprom update to
Legacy FBM's we had 12 failures out of 1273 total 100 series FBM's.  Some of
those FBM failures have caused partial loss of process control and a
resulting production loss.  It is those events that get managements'
attention and make them question total system reliability.  And thus I am
looking for a measure that can show them that our reliability isn't
degrading, and that is where this whole thread began. 

Tom VandeWater
Control Systems Developer/Analyst
Dow Corning Corp.
Carrollton, KY   USA

-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]On Behalf Of TED PLUMB
Sent: Wednesday, June 16, 2004 10:16 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Measuring Overall System Reliability


Ditto here.  Our system has been down only once since 1990 and that was
because of flooding when we abandonded our facility.  Only FBM failures
were when doing a CP reboot after a major upgrade (never while on line).
 Lost two analog channels on separate FBM since 1990.  Regarding
filedbus issues, we experienced fieldbus errors and found the length of
a FT pair had to be very close.  So we just disable automatic switching
and let it switch if there is a failure.  This has resolved our fieldbus
problems.  Our goal IS 100% uptime.   We have achieved just under  than
99.9900%

The magic of Nines
Availability     Downtime/Yr
90.0000%     37 days
99.0000%     3.7 Days
99.9000%     8.8 Days
99.9900%     53 minutes
99.9990%     5.3 minutes
99.9999%     32 seconds


>>> Hank.Matic@xxxxxxxxxxxxxxx 6/16/2004 4:31:29 AM >>>
We've been running Foxboro I/A here since 1990 , with only one major
upgrade
for the y2k fiasco. At that time we replaced our CP10's with CP30's ,
our
AP20's with AW51E's , our PW's with AW51B's , our WP20's with WP30's
and
WP51B's. With the original hardware the highest failures we had were
on
WP20's especially when they were rebooted. The minor failures we have
had on
FBM's ( usually single piont failures ) were due to events out in the
field
rather than the hardware itself. We experienced a small failure rate on
the
FBM's when we did EEPROM updates and we had an AW51E fail in infantcy.
Thru
all of that we never experienced any down time on our units due to the
I/A
system. Our other plants have WGH systems , 2 of the plants that use
the DCS
for controls have had significant failures which caused one plant to
go
offline , and caused some signifiacnt damage at the other. All in all
I'm
happy with I/A although I wouldn't recommend the Microsoft version to
anyone.
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys
Process
Systems (formerly The Foxboro Company). Use the info you obtain here
at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html

 
foxboro mailing list:             http://www.freelists.org/list/foxboro

to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join

to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

 

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys
Process
Systems (formerly The Foxboro Company). Use the info you obtain here
at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html

 
foxboro mailing list:             http://www.freelists.org/list/foxboro

to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join

to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: