Migration Tools to Convert Your Legacy DCS

Editor's Notes

• #4: The PlantPAx® System is a modern distributed control system (DCS). The system is built on a standards-based architecture by using Integrated Architecture™ components that enabling a common automation platform for your entire plant. Provides all the core capabilities expected from a traditional DCS, while enabling plant-wide control & optimization Built on scalable and modular architectures to match exact control requirements and reduce time to market Utilizes an open, information-enabled & secure architectures for easy connectivity to business systems & 3rd party networks Provides flexible options in the delivery and support for the system
• #5: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #8: Of all of the benefits to migrate a legacy DCS system – none is greater for the enduser than the reduction of the total cost of ownership of a control system(s) or control assets). The Total Cost of Ownership is a financial estimate designed to help businesses and consumers assess direct and indirect life-cycle costs – from “cradle to grave”. Some examples of TCO are as follows: HW, SW, Networks Engineering Simulation Commissioning Support contracts Energy Floor Space Training - Operator, Maint, IT Upgrade, Expansion, Migration Decommissioning Un-planned downtime Obsolescence Planning The reduction of TCO for a given control system or systems can save the end user multiple $Millions of Dollars in a 20 year life cycle! Determining the benefits of the new Control System and placing tangible $ to them can help to justify a migration. If the TCO of the legacy system is greater than the TCO of a new control system then a migration is well justified. End-users have told us that just because their DCS system is obsolete – they will not migrate it, unless they need to expand their existing processes or equipment for new or improved product offers, or until they experience un-scheduled downtime (and associated high risk to their business) due to legacy control system failures. We need to provide compelling value assessments to help them build successful CapEx business cases.
• #10: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #11: - To migrate from your current stuff to new stuff, might be risky if you want to rip EVERYTHING out and replace itBUT we offer the ability to rip a part out and replace it with our stuff little by little. How can we do it little by little? by using OPC servers that sit inside white boxes PCs or SAMS - These OPC servers are widely available - easy to get and support + inexpensive - BONUS - you dont need another computer IF you already have a computer for your FTView server.
• #12: - To migrate from your current stuff to new stuff, might be risky if you want to rip EVERYTHING out and replace itBUT we offer the ability to rip a part out and replace it with our stuff little by little. How can we do it little by little? by using OPC servers that sit inside white boxes PCs or SAMS - These OPC servers are widely available - easy to get and support + inexpensive - BONUS - you dont need another computer IF you already have a computer for your FTView server.
• #13: Rockwell developed a database conversion utility that converts Bailey console database tags into either OPC tags or CLX tags depending upon the communication method selected to communicate to the Bailey system. OPC tags are used when the Rovisys OPC90 OPC server for Bailey is deployed. CLX tags are used when the Online Development’s BLY90 dedicated interface to a CLX controller is deployed. The database conversion utility will convert most of the Bailey Exception Report Block information (including PID tuning constants) into OPC or CLX tags.
• #14: The CLX-PVX module is a dedicated I/O Scanner module that allows CLX controllers to re-control existing legacy I/O. It is typically in a Phase II senario – when the enduser wants to replace their legacy process controllers and retain the existing I/O infrastructure. The customer will be able to leverage the power of a new process controller without experiencing long, risky shutdown/commissioning outages. The PVX module has two operating modes – Shadow and Scanner. In shadow mode, the module can be deployed very early in a migration project. It can connect to a live, operating system to capture pertinent I/O information that reflects the performance and dynamics of the actual process. This information is used to simulate a CLX controller’s program to test all logix and control strategies before the new controller is cutover. This capability allows for very short, low risk shutdown and commissioning tasks. The second operating mode is Scanner Mode. In scanner mode, the module captures all inputs, and sends them to a CLX controller. The CLX controller performs logic on the inputs and sends appropriate outputs to the PVX module – controlling the process. The PVX module auto-interrogates the existing I/O racks and I/O modules residing in those racks, and captures all I/O module information. The PVX module can shadow and re-control both Series 10 (MUX I/O), or Series 20 (Control I/O) (including SMART I/O) that is connected on the Serial I/O Network.
• #15: The CLX-PVX module is a dedicated I/O Scanner module that allows CLX controllers to re-control existing legacy I/O. It is typically in a Phase II senario – when the enduser wants to replace their legacy process controllers and retain the existing I/O infrastructure. The customer will be able to leverage the power of a new process controller without experiencing long, risky shutdown/commissioning outages. The PVX module has two operating modes – Shadow and Scanner. In shadow mode, the module can be deployed very early in a migration project. It can connect to a live, operating system to capture pertinent I/O information that reflects the performance and dynamics of the actual process. This information is used to simulate a CLX controller’s program to test all logix and control strategies before the new controller is cutover. This capability allows for very short, low risk shutdown and commissioning tasks. The second operating mode is Scanner Mode. In scanner mode, the module captures all inputs, and sends them to a CLX controller. The CLX controller performs logic on the inputs and sends appropriate outputs to the PVX module – controlling the process. The PVX module auto-interrogates the existing I/O racks and I/O modules residing in those racks, and captures all I/O module information. The PVX module can shadow and re-control both Series 10 (MUX I/O), or Series 20 (Control I/O) (including SMART I/O) that is connected on the Serial I/O Network.
• #17: The CLX-PVX module is a dedicated I/O Scanner module that allows CLX controllers to re-control existing legacy I/O. It is typically in a Phase II senario – when the enduser wants to replace their legacy process controllers and retain the existing I/O infrastructure. The customer will be able to leverage the power of a new process controller without experiencing long, risky shutdown/commissioning outages. The PVX module has two operating modes – Shadow and Scanner. In shadow mode, the module can be deployed very early in a migration project. It can connect to a live, operating system to capture pertinent I/O information that reflects the performance and dynamics of the actual process. This information is used to simulate a CLX controller’s program to test all logix and control strategies before the new controller is cutover. This capability allows for very short, low risk shutdown and commissioning tasks. The second operating mode is Scanner Mode. In scanner mode, the module captures all inputs, and sends them to a CLX controller. The CLX controller performs logic on the inputs and sends appropriate outputs to the PVX module – controlling the process. The PVX module auto-interrogates the existing I/O racks and I/O modules residing in those racks, and captures all I/O module information. The PVX module can shadow and re-control both Series 10 (MUX I/O), or Series 20 (Control I/O) (including SMART I/O) that is connected on the Serial I/O Network.
• #18: The CLX-APX module is a dedicated I/O Scanner module that allows CLX controllers to re-control existing legacy I/O. It is typically in a Phase II senario – when the enduser wants to replace their legacy process controllers and retain the existing I/O infrastructure. The customer will be able to leverage the power of a new process controller without experiencing long, risky shutdown/commissioning outages. The APX module has two operating modes – Shadow and Scanner. In shadow mode, the module can be deployed very early in a migration project. It can connect to a live, operating system to capture pertinent I/O information that reflects the performance and dynamics of the actual process. This information is used to simulate a CLX controller’s program to test all logic and control strategies before the new controller is cutover. This capability allows for very short, low risk shutdown and commissioning tasks. The second operating mode is Scanner Mode. In scanner mode, the module captures all inputs, and sends them to a CLX controller. The CLX controller performs logic on the inputs and sends appropriate outputs to the APX module – controlling the process. The APX module auto-interrogates the existing I/O racks and I/O modules residing in those racks, and captures all I/O module information. The APX module can shadow and re-control APACS I/O that is connected on the I/Obus Network.
• #21: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #22: These items are typically what is required for a good start of a migration project – either phased or rip and replace. Good, up-to-date documentation to work from is essential for a successful project. We typically require exported database and configuration files We’ll need hardcopy printouts of the legacy graphics I/O and interlocking information is important Controller configuration (programming) printouts are needed to review the legacy control strategies to learn how the loop (or control functionality) was initially designed. Up to date loop descriptions are also important to work from – they were the original (directives) to configure the legacy DCS with. And of course having updated P&ID’s available that show what the controlled equipment is and how it interacts with the overall process and ancillary equipment
• #23: Interviewing the customers migration team is essential for a successful migration project! We interview Operators for their opinions and experience on how they control the process, but also for an idea of how we can potentually improve the process. Maintenance personnel are interviewed to help us to understand how they use the system to troubleshoot problems, and maintain system hardware and software. We’ll talk with Plant Engineering and Plant Managers to understand what the expectations are of the new system and how we can improve system performance, or improve product yeild and quality, or reduce waste and product variability.
• #24: The above slide depicts a typical Bailey NET90 or INFI90 architecture. It shows the HMI Consoles – both Operator Stations and Engineering Work Station. It also shows the INFI Loop network and controllers and I/O (PCU) – with the Termination Units accepting instrumentation signals. Architecture Legend: Bailey Console versions – OIU, OIS (proprietary and obsolete) standalone units Conductor NT, Operate IT (Process Portal B), PCView, 800xA (current offer) – PC based – could be deployed standalone or client/server CIU – Computer Interface Unit – interface modules used to comm to the Infi Loop network – equates to an ENBT, or CNBT. It is always used to connect the Bailey System to external 3rd party PC’s for Historians, HMI’s, etc via OPC Servers. Plant Loop or Infi Loop – Proprietary network (obsolete) – 75ohm token passing PCU – Process Control Unit – combination of comm modules, controllers (MFP, MFC, BRC), I/O slaves (I/O modules), and MMU (I/O rack) MFP – Multifunction Processor (obsolete) – equates to a Logix controller MFC – Multifunction Controller (obsolete) – equates to a Logix controller BRC – Bridge Controller – (current offer) – equates to a Logix controller TU – Termination Unit – equates to our IFM product
• #25: Phase I or HMI replacement Phase can be performed with ZERO shutdown! First – Deploy the Online Development cATM-BLY90 module (dedicated interface) with a CLX. The cATM-BLY90 communicates to the Bailey CIU or ICI – via a Serial connection The cATM transact data to a CLX PAC across the CLX backplane – it can handle up to 5,000 Bailey tags (or 40,000+ data items). The CLX PAC acts as a database engine for a new HMI, Historian, MES, ERP layers of Control and Information requirements We use a tool to convert the Bailey Console tags into CLX tags Graphics are converted manually using engineering services To reduce risk, the enduser can retain existing Consoles as the new FTView consoles are deployed – the enduser can retire the legacy consoles as they gain expertise and comfort in controlling from the new consoles The Bailey controllers remain in place – continuing to control the Process
• #26: Phase I or HMI replacement Phase can be performed with ZERO shutdown! First – Deploy the Online Development cATM-BLY90 module (dedicated interface) with a CLX. The cATM-BLY90 communicates to the Bailey CIU or ICI – via a Serial connection The cATM transact data to a CLX PAC across the CLX backplane – it can handle up to 5,000 Bailey tags (or 40,000+ data items). The CLX PAC acts as a database engine for a new HMI, Historian, MES, ERP layers of Control and Information requirements We use a tool to convert the Bailey Console tags into CLX tags Graphics are converted manually using engineering services To reduce risk, the enduser can retain existing Consoles as the new FTView consoles are deployed – the enduser can retire the legacy consoles as they gain expertise and comfort in controlling from the new consoles The Bailey controllers remain in place – continuing to control the Process
• #27: Phase I or HMI replacement Phase can be performed with ZERO shutdown! First – Deploy the Online Development cATM-BLY90 module (dedicated interface) with a CLX. The cATM-BLY90 communicates to the Bailey CIU or ICI – via a Serial connection The cATM transact data to a CLX PAC across the CLX backplane – it can handle up to 5,000 Bailey tags (or 40,000+ data items). The CLX PAC acts as a database engine for a new HMI, Historian, MES, ERP layers of Control and Information requirements We use a tool to convert the Bailey Console tags into CLX tags Graphics are converted manually using engineering services To reduce risk, the enduser can retain existing Consoles as the new FTView consoles are deployed – the enduser can retire the legacy consoles as they gain expertise and comfort in controlling from the new consoles The Bailey controllers remain in place – continuing to control the Process
• #28: Phase I or HMI replacement Phase can be performed with ZERO shutdown! First – Deploy the Online Development cATM-BLY90 module (dedicated interface) with a CLX. The cATM-BLY90 communicates to the Bailey CIU or ICI – via a Serial connection The cATM transact data to a CLX PAC across the CLX backplane – it can handle up to 5,000 Bailey tags (or 40,000+ data items). The CLX PAC acts as a database engine for a new HMI, Historian, MES, ERP layers of Control and Information requirements We use a tool to convert the Bailey Console tags into CLX tags Graphics are converted manually using engineering services To reduce risk, the enduser can retain existing Consoles as the new FTView consoles are deployed – the enduser can retire the legacy consoles as they gain expertise and comfort in controlling from the new consoles The Bailey controllers remain in place – continuing to control the Process
• #29: The above slide depicts a typical Foxboro I/A architecture. It shows the HMI Consoles – both Operator Stations and Engineering Work Station. It also shows the proprietary network and controllers and I/O – with the Termination Units accepting instrumentation signals. Architecture Legend: Foxboro I/A Console versions: Unix based Workstation Processor (WP50), Application Station Processor (AP50) (proprietary and obsolete) standalone units NT PC based WP70, AP70 , and XP PC based WP70P and AP70P AW50 – Unix based engineering workstation, AW70 is PC based engineering workstation Nodebus – Proprietary network – equates to Enet or Cnet uplink of Supervisory network where level 1/level 2 components reside CP30/40/60 – Control Processor – equates to Logix controllers Fieldbus – Proprietary network where only CP’s and I/O reside – equates to Enet or Cnet downlink (Not Foundation Fieldbus related) FBM – Fieldbus modules (I/O modules) – most deployed is FBM100 Series I/O – equates to our I/O modules Nosecone – Connects the I/O signals to the I/O module (FBM) via the termination unit and cable - equates to our IFM
• #30: Of all of the benefits to migrate a legacy DCS system – none is greater for the enduser than the reduction of the total cost of ownership of a control system(s) or control assets). The Total Cost of Ownership is a financial estimate designed to help businesses and consumers assess direct and indirect life-cycle costs – from “cradle to grave”. Some examples of TCO are as follows: HW, SW, Networks Engineering Simulation Commissioning Support contracts Energy Floor Space Training - Operator, Maint, IT Upgrade, Expansion, Migration Decommissioning Un-planned downtime Obsolescence Planning The reduction of TCO for a given control system or systems can save the end user multiple $Millions of Dollars in a 20 year life cycle! Determining the benefits of the new Control System and placing tangible $ to them can help to justify a migration. If the TCO of the legacy system is greater than the TCO of a new control system then a migration is well justified. End-users have told us that just because their DCS system is obsolete – they will not migrate it, unless they need to expand their existing processes or equipment for new or improved product offers, or until they experience un-scheduled downtime (and associated high risk to their business) due to legacy control system failures. We need to provide compelling value assessments to help them build successful CapEx business cases.
• #31: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #33: Knowing the lifecycle status can help you identify your risks The Installed Base Evaluation helps identify risks and opportunities for optimization Tools, utilities, and services are available to make migration from legacy Rockwell products to
• #34: Knowing the lifecycle status can help you identify your risks The Installed Base Evaluation helps identify risks and opportunities for optimization Tools, utilities, and services are available to make migration from legacy Rockwell products to
• #36: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #37: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #38: For today’s Agenda we are going to cover what the Legacy DCS Market looks like, talk about the perspective from the Enduser regarding their needs to migrate their aging DCS, and highlight the cost and benefits of a migration. We’ll talk about a Phased Migration (where we remove the least supported component of a legacy architecture – focused on the risk, cost, and downtime. We will also talk about rip & replace migration strategies and compare this with a Phased approach. We’ll wrap up with a help slide of who to go to for help.
• #41: Global Solutions – Bring You a World of Experience!
• #42: Customer Maintenance and Support – Global Support, Local Address, Peace of Mind
• #43: Rockwell’s Global Partner Network -
• #44: Who Should You Call for Help?
• #45: Who Should You Call for Help?
• #46: Who Should You Call for Help?
• #47: Where to find more information: The PlantPAx Selection Guide (PROCES-SG001) and the Process System Estimator (part of the Integrated Architecture builder available from IA Tools) assists with system selection and procurement after defining application requirements. The PlantPAx Reference Manual (PROCES-RM001) defines what you need to know to setup and configure a PlantPAx system. For more information on how we compete in the DCS market, see the Modern DCS whitepaper (PROCES-WP010) coming soon! For more information on characterization, check out our video on YouTube.