Re: [foxboro] Can't figure out a way to justify it.

  • From: kevin.fitzgerrell@xxxxxxxxxxxx
  • To: foxboro@xxxxxxxxxxxxx
  • Date: Wed, 12 Jan 2005 15:07:50 +1300

Ken,

After reading your response I looked at the reasons my customers sites have
been upgrading and fundamentally they boil down to two reasons:

1) Expansion driven (plant and/or control growth).  Upgrades are done to
support a specific plant expansion or to improve the infrastructure now to
support future planned or projected growth.
The switched network and CP upgrades I've been doing and planning fall
under this category.

2) Maintenance driven (reliability, supportability).  Upgrades are done to
replace high maintenance items or those at or near the end of their life.
The B box replacements fall mostly under this category.

For those with 20 year old systems waiting for the justification to rip it
all out -- that justification may be a long time coming.  As long as we can
upgrade components when they start to fail, and add current generation
components for planned expansion, that justification shouldn't be
necessary.

At plants with the 20 year old system, everything may well work about as
well today as when it went in, although maintenance and production costs
related to component failure might be starting to creep up.  While the
system does what it was designed to it is likely to have limited
connectivity with other systems, is probably not easily expandible, and
it's nearly impossible to implement optimizing/supervisory control.  How
many projects have been passed up because the system was at or past it's
design limits and couldn't support incremental expansion or modernization?
How has this affected their profitability in comparison with their
competitors?

Regards,

Kevin FitzGerrell
Systems Engineer
Foxboro New Zealand
------------------------------------
Tel:  +64 (9) 573 7690
Fax:  +64 (9) 573 7691


                                                                                
                                                       
                      "Ken Heywood"                                             
                                                       
                      <kheywood@xxxxxxx        To:       
<foxboro@xxxxxxxxxxxxx>                                                       
                      om>                      cc:                              
                                                       
                      Sent by:                 Subject:  Re: [foxboro] Can't 
figure out a way to justify it.                           
                      foxboro-bounce@fr                                         
                                                       
                      eelists.org                                               
                                                       
                                                                                
                                                       
                                                                                
                                                       
                      12/01/2005 02:23                                          
                                                       
                      PM                                                        
                                                       
                      Please respond to                                         
                                                       
                      foxboro                                                   
                                                       
                                                                                
                                                       
                                                                                
                                                       




Everyone has a lot of great technical reasons that justify chosing I/A
Series over some other brand. Technology is wonderful, but where is the
return? The justification comes when you walk into your boss' office and
say you want to spend $2.3 million to replace the existing control system.
The boss will say "Show me the money." Are you making production targets?
Yes? Will the $2.3 million be paid back in 12 months? Maybe? How much more
money can we make with this upgrade? Dunno? I have lots of customers still
running control systems vastly older than I/A who are still waiting for the
justification to rip it all out.

             -----Original Message-----
             From: Kevin FitzGerrell [mailto:fitzgerrell@xxxxxxxxxxxxxxx]
             Sent: Tue 1/11/2005 8:13 PM
             To: foxboro@xxxxxxxxxxxxx
             Cc:
             Subject: Re: [foxboro] Can't figure out a way to justify it.



             I can share the key points driving upgrades at some of the
sites I work with.
             Outside of upgrading overloaded CPs, the biggest reasons for
recent major
             upgrades have been:

             1)  Switched networks allow for 8 segments on nodebus.  For
sites that already
             have 3 segment nodebus, this allows for easy extension of the
existing system to
             new plant areas without a CLAN.
             2)  Modbus/Profibus fbms on CP60 are much more attractive than
Integrator 30
             solutions.
             3)  B/B1 boxes are experiencing increasing incidence of
component failure (ram,
             NVRAM, floppys, HD, CD, Power Supplies) and don't run current
version of FoxView.

             Examples:

             Site 1
             ---------------------
             Before recent upgrades:  AP51E, WP51Es and WP51Ds.  MG30s and
MG30Bs.  CP30FTs
             and CP40BFT.  Three segment nodebus with FONBEs.  I/A version
6.1.

             Previous upgrades:
             Had upgraded with Y2K money from earlier workstations to the
51Es, and added
             51Ds later as more operator stations were desired.  Had
upgraded an overloaded
             CP30 to a 40B.

             Recent upgrades:
             Upgraded to high speed switched network (NCNIs, P92 XP AW,
Fiber switches) --
             driving factor was to add additional Nodebus segments without
going to a CLAN.
             Upgraded overloaded CP30FT to CP60FT -- driving factor was
critical nature of
             overloaded CP and desire to use Modbus FBMs to integrate
additional data from
             Triconex and Modicon PLCs.
             Upgraded from 6.1 to 6.5.1/7.1 -- necessary to support the two
items above.

             Single most important reason for upgrade was the ability to
have up to 8 Nodebus
             segments on a network without a CLAN.

             Considerations -- plant downtime where significant upgrades
can be done doesn't
             come often.  Desire is to bring system current during that
downtime to allow for
             ongoing addition of current generation equipment when
necessary.


             Site 2
             --------------------
             Before recent upgrades: AP51As, WP51As, WP51Bs, WP51Ds, a
couple WP20s.  CP30s,
             CP40s, CP40Bs.  Three networks, two of them with CLANs.  2 and
3 segment nodebuses.

             Previous upgrades:
             Large numbers of CP10s merged into CP40s/40Bs -- driving
factors were
             overloading in CP10s, extra engineering maintaining ring route
(implemented to
             overcome resource limitations of CP10s).

             Recent upgrades:
             AP51As upgraded to AW51Es, WP20s eliminated -- driving factors
were poor A box
             perfomance and extra engineering maintaining graphics on
WP20s.  Also considered
             increasing component failure on A boxes.
             CP30s and some CP40s merged into CP60s -- driving factors were
overloading due
             to ongoing project work, also considered memory related
reboots of CP30 and CP40
             modules.  Choice of CP60 over CP40B because of support of
larger number of FBMs
             and integration via Profibus/Modbus FBMs.  200 series FBMs
seen as easier to add
             in recovered cabinet space when new I/O is needed.
             CP40s to CP40FTs -- driving factor was reliability.  Used
modules made available
             by mergers above.
             Upgrade to switched network -- driving factor was desire to
eliminate CLANs in
             each network.  CLANs had become overloaded due to increase in
control strategies
             involving multiple previously independent plant areas.
             51B1 to 51F upgrades -- driving factors include poor
performance of the 51B1
             boxes and increasing component failure (ram, NVRAM, floppys,
HD, CD, Power
             Supplies).
             Upgrade in software from 4.3 -> 6.2.1 -- driving factor was
CP60s.
             Upgrade in software from 6.2.1 -> 6.5/6.5.1/7.1 -- driving
factors were switched
             network and Modbus FBM support.

             Future upgrades:
             Merge seperate networks to single plant network with ATS and
V8.1 I/A -- driving
             factor is growth of control strategies across previously
independent plants.
             CPxx -> CP270 -- driving factor is serial and ethernet FBMS --
Critical
             protocols seen as Modbus Slave, DH+, OPC, Control Logix.


             Site 3
             --------------------
             Currently:  AW51B, WP51B, Micro I/A with 100 series I/O,
Single Ethernet network.

             Considered future upgrades:
             51B -> 51F -- driving factor is component failure and
repairability status of B
             boxes.
             Micro I/A -> CP60/CP270 -- driving factor is repairability
status of Micro I/A
             controllers.


             Site 4
             -------------------
             Currently:  AP51B, WP51Bs, CP30s, CP40s, MG30s, MB+, 3 segment
nodebus with FONBEs

             Recent upgrade:
             110mhz AP51B -> 170mhz AP51B, increase in RAM -- short term
fix for AP overloading.

             Planned upgrades:
             Upgrade to switched network -- driving factor is increased
network performance
             and reliability.
             AP51B -> AP51F -- driving factor is AP performance and
increasing component
             failure in B boxes.
             I/A 6.2.1 -> I/A 6.5.1/7.1 -- to support above items and allow
for Modbus FBMs.

             Considerations -- plant downtime where significant upgrades
can be done doesn't
             come often.  Desire is to bring system current during that
downtime to allow for
             ongoing addition of current generation equipment when
necessary.
             --------------------

             Please feel free to contact me for more details.

             Regards,

             Kevin FitzGerrell
             Systems Engineer
             Foxboro New Zealand
             ------------------------------------
             Tel:  +64 (9) 573 7690
             Fax:  +64 (9) 573 7691






             Quoting "Johnson, Alex (Foxboro)" <ajohnson@xxxxxxxxxxx>:

             > I wish I had the key to offering something that would drive
             > replacements.
             >
             > So, what would justify an upgrade in the minds of you folks
- short of
             > the
             > "rip it out because we have a new system and won't support
our existing
             > one"
             > that some vendors use.
             >
             >
             > I'd really appreciate your thoughts on what would drive the
brownfield
             > sites
             > to upgrade.
             >
             >
             > Regards,
             >
             > Alex Johnson
             > Invensys Process Systems
             > Invensys Systems, Inc.
             > 10707 Haddington
             > Houston, TX 77043
             > 713.722.2859 (voice)
             > 713.722.2700 (switchboard)
             > 713.932.0222 (fax)
             > ajohnson@xxxxxxxxxxx
             >
             >
             >
             >
             >
______________________________________________________________________
             > _
             > 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: //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:
//www.freelists.org/list/foxboro
             to subscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
             to unsubscribe:
mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave



-- No attachments (even text) are allowed --
-- Type: application/ms-tnef
-- File: winmail.dat




_______________________________________________________________________
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:             //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:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
 

Other related posts: