Re: [foxboro] Failsafe PLC

I too have integrated several TRICONs to the I/A system.  Even in the "old 
days" (I think I did the second one ever), it was a robust communication path, 
and the TRICON is a good product.  

Jim
> 
> From: <tom.vandewater@xxxxxxxxxxxxxx>
> Date: 2006/02/09 Thu PM 05:00:01 EST
> To: <foxboro@xxxxxxxxxxxxx>
> Subject: Re: [foxboro] Failsafe PLC
> 
> Dirk,
>       We are in the process of migrating our old ICS, (hardwired SIS),
> systems to TRICONEX Tricons.  We have had two Tricon systems in place
> for over 5 years now and have recently added two more.  They are serving
> us well.  The old ICS system, although pretty reliable, was hard to
> modify, difficult to document, and required a lot of cross wiring to
> different systems, in the form of physical I/O point interconnections.
> Because they were located near the process areas they served, a lot of
> additional wiring and IO points were needed to send alarms to the
> control room, send shutdown status information to the DCS, and notify
> the site security system of problems. =20
>       In looking for a replacement, we viewed the ability to easily,
> and relatively seamlessly, pass data from the SIS system, (Safety
> Instrumented System), to the DCS system, as critical.  We needed a
> robust communication interface from the SIS to the DCS to insure that
> the DCS knows when it can no longer control a process that has been
> shutdown by the SIS safety system.    We have a rather complex but
> valuable set of schemes and interlocks on the DCS that can be broken
> down into two basic categories:
> 
> Pre-SIS - these interlocks are in place to try to take DCS control
> actions that will prevent the SIS from needing to take action, thus
> keeping the DCS under control.  In the past, this was done using inputs
> and transmitters that were connected to the DCS, but, with easy read
> access to SIS transmitters and switches it is possible to use both DCS
> and SIS inputs for Pre-SIS strategies.
> 
> Post-SIS - This is logic and DCS control actions that are initiated if
> an SIS shutdown occurs.  It focuses on things that are required to put
> the DCS in a good position for resuming process control whenever the SIS
> shutdown condition clears.  Most often this means the DCS will be
> bringing the process from a "Not Running" condition back to an operating
> state.
> 
>       All of that being said, here are some of the reasons we chose to
> use a Triconex TRICON with our Fox IA DCS system:
> 
> It employs TMR, (Triple Modular Redundant), hardware architecture that
> allows for a single electronic component failure to occur without
> shutting down the process.  The TMR functionality is present even in the
> IO cards.  This allows physical board replacement online with no
> downtime.
> 
> The TRICON can support an ACM card in one of its slots that allows it to
> host several functions:
> 1. It can communicate as a station on the Foxboro nodebus through a DNBI
> 2. It can host ECB's that allow the TRICON I/O cards to communicate and
> map variables into Foxboro Global Object variables that can then be used
> by any other Fox IA control or display station. =20
> 3. ECB and Control blocks are configured into the ACM memory via the ICC
> or IACC applications in the same way that you would configure any other
> control station.  The interface is what Foxboro calls FoxGuard.  With
> this functionality we can use the Foxboro HMI and alarm mechanisms to
> display and alarm SIS conditions through the DCS interface and our pre
> and post SIS control strategies running in Foxboro IA CP's can acquire
> real-time data from the SIS system, (without all the wires).
> 4. The ACM also supports a 2nd Ethernet connectivity that allows us to
> access the TRICON processors and configure the SIS logic using a
> Triconex 1131 software application running on a networked PC.  That
> configuration can also be done via a local serial connection on the ACM
> card to a Windows PC running the 1131 software application.  There is a
> local keylock on the TRICON that can keep anyone from making changes
> from remote connections.
> 5. A 200 series FBM option using an FBM232 FDSI module can allow you to
> connect the TRICON ACM onto an FCM100 fieldbus segment on the MESH
> network.
> 6. The TRICON System status is displayed via an assigned System Monitor.
> Power Status, Processor Faults and even individual IO point alarms can
> be alarmed and diagnosed using the familiar Foxboro interface.
> 
>       Triconex offers a newer, smaller, potentially more economical
> solution for smaller applications called the TRIDENT, but for us, the
> functionality, connectivity, and economy of the TRICON made the most
> sense.  We were able to eliminate a tremendous amount of cross wiring,
> establish much better change control, easily implement logic
> modifications, utilize existing HMI stations, monitor System Status via
> existing applications, and initiate SIS alarms on the same operator
> workstations used by the Foxboro DCS operators.
> 
>       I hope this information is useful.  This might sound like I am
> bucking for an Invensys sales position.  How'd I do Dick Staun?
> 
> Cheers,
> Tom VandeWater
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Pauwels, Dirk - RSM
> Sent: Thursday, February 09, 2006 8:35 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: [foxboro] Failsafe PLC
> 
> We're currently considering the implementation of a safety PLC (fail
> safe) for critical process apps. I was wondering if any of you guys have
> such PLC's (triconex - trident/tricon....) installed.
> =20
> We're in the process of listing our critical apps and the more we look
> at it the more crit. apps there seem to be :-)
> =20
> Do you have you're crit. equipm double wired, both to DCS and Triconex
> or single to triconex, connected to DCS etc.....
> =20
> We also have PT100's, RTD temp transmitters. These cannot be wired in
> parallel, for crit apps do you suggest putting in a second RTD or use an
> RTD to 4-20 convert module?
> =20
> Is there such a thing as a critical apps manual or standard we can use
> as a guideline?
> =20
> Thanks & rgds,
> =20
> Dirk Pauwels - DCS/MOC coordinator=20
> Engineering dept.
> Hexion Specialty Chemicals
> E mail: dirk.pauwels@xxxxxxxxxxxxxx
> T.  +32.(0)3.570.95.97
> F.  +32.(0)3.570.16.09
> Mob. +32.(0)497.428.300
> =20
> =20
> =20
> _______________________________________________________________________
> 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
> =20
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:      =
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
>  
>  
> _______________________________________________________________________
> 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: