CONTROL SYSTEMS MIGRATIONS IN PHOSPHATE PLANTS: A ROAD MAP FOR SUCCESS. Richard Brooks & John O Toole. Hatch Queen Palm Drive Suite 100

Transcription

1 CONTROL SYSTEMS MIGRATIONS IN PHOSPHATE PLANTS: A ROAD MAP FOR SUCCESS Richard Brooks & John O Toole Hatch 3611 Queen Palm Drive Suite 100 Tampa, FL Prepared for American Institute of Chemical Engineers 40 th Annual Clearwater Convention 1

2 ABSTRACT Hatch is currently completing a staged control system migration for a phosphate producer to migrate from a legacy control system to a modern control system. Hatch has also completed similar projects previously in related industries such as potash. These projects reveal that there are options for control system migrations in mature phosphate plants (online versus offline; utilizing existing cabinets in existing footprints versus new cabinets requiring additional physical space/footprint, amongst other plant-specific considerations). For best results, the specific approach and option selected for a control system migration project has to be developed through an integrated Owner/Engineer/Vendor team which has a common understanding of the risks associated with the migration (cost, schedule, production, quality, and safety impacts) as well as a strategic mitigation plan in place to mitigate and, where possible, eliminate those risks. This paper will address challenges in three areas as follows: Project Challenges Preliminary Steps; Detailed Planning; Migration Strategies Migration Challenges Development of as-built documentation of existing field installation and control system functionality. Creation of software standards (alarm management, HMI graphical displays, and control system logic) and detailed control narratives for client-specific operating scenarios and unique plant control philosophies Operational Challenges Migration of plant areas while plant is in operation to minimize production losses; customizing migration strategy for existing plant maintenance outages and detailed coordination with operations to capitalize on unscheduled downtimes Fig. 1 A Modern DCS Control Room 2

3 TABLE OF CONTENTS PAGE ABSTRACT..2 LIST OF FIGURES AND TABLES INTRODUCTION MIGRATION: PRELIMINARY STEPS SYSTEM STATUS....6 SELECTING YOUR PARTNER...9 TYPES OF MIGRATION WHAT TO MIGRATE? MIGRATION: DETAILED PLANNING DETAILED DESIGN AND DOCUMENTATION DEVELOPMENT...13 PROGRAMMING STANDARDS DEVELOPMENT.14 FUNCTIONAL DESCRIPTION DEVELOPMENT MIGRATION STRATEGY DEVELOPMENT HPMP BROWNFIELD MIGRATIONS...22 EXAMPLES.. 22 CONCLUSION AND RECOMMENDATIONS FOR FUTURE MIGRATIONS..25 3

4 LIST OF FIGURES AND TABLES FIGURE PAGE 1. A Modern DCS Control Room Control Room Before and After Control System Migration Process Control System Lifecycle Continuum Average Process Automation Component Lifecycle in Years 9 5. Preliminary Migration, HMI Level HMI and Alarm Optimization Before and After Migration Equipment Program Sheet Sample Cut Over Package I/O Signal Classification per System Example 1: Marshalling Cabinet I/O Table and Picture Example 2: Cabinet Table and Picture Many Reasons to Migrate Many Opportunities When Migrating Control System Cabinet Before and After Migration 26 4

5 INTRODUCTION In the United States, the majority of the phosphate processing facilities were originally built from the late 1940 s through the mid-1980 s, with virtually no Greenfield plant construction during the last 30 years. Many process control systems that were state of the art at the time of plant construction are now either outdated from a technology standpoint, or are nearing end of life in terms of hardware breakdowns. Many legacy process control systems require replacement parts that are now obsolete, forcing the Owner to source used, reconditioned parts from third party resellers which are typically very expensive, carry limited or no warranties and often no control system Vendor support. Relying on legacy systems and parts of systems which are no longer supported by Vendors raises the risk of plant outages which translates directly to production losses. Unfortunately, unless and until these production losses actually occur, any large scale system migration project is perceived to have little or no pay back, and it is very challenging for plant process control systems groups to justify large scale migrations from legacy to modern process control systems. During the last 30 years, phosphate producers have achieved throughput increases primarily through Brownfield expansion and debottlenecking projects. Owners have generally utilized most or all of the physical space in their plants that was originally allocated for future expansion, especially from a process controls perspective. This limited footprint condition often precludes the use of new process control cabinets, leading to the need to retrofit existing cabinets with new process controllers and wiring housed within the existing footprints. Major expansion projects are typically the vehicle by which control system migrations are accomplished, as the cost of the control system migration is small relative to the overall capital expenditure for the expansion. It is not unusual that the cost of the control system migration is less than the value of the project contingency, if the expansion is in the range of $150 million or greater. Hatch has completed several process control system migrations in both the phosphate industry and in similar industries such as potash. Hatch is currently executing a migration project for a phosphate producer, which we will refer to as the Hatch Phosphate Migration Project (HPMP) throughout this paper to illustrate the lessons learned and provide concrete examples. While there are often multiple control system upgrade solutions and migration options available to an Owner there are certain situations when the only real option is a full rip-and-replace, as was the case with the HPMP. This paper will primarily focus on the preparations for and execution of a rip-and-replace control system migration, highlighting the procedures and innovative solutions that will help ensure ultimate project success (minimal unplanned downtime and maximum use of existing plant assets and available footprint). Although the migration method utilized for the HPMP is project-specific, the steps required to scope, plan, and execute the project will be an integral part of any successful migration project. 5

6 Fig. 2 Control Room Before and After Control System Migration SYSTEM STATUS MIGRATION: PRELIMINARY STEPS In order to determine whether a process control system migration is warranted and what type of migration is required, it is first necessary that the Owner understand the status of the current system in broad terms. System status can be categorized into four groups which roughly correspond to the modernity and functionality or capability associated with the existing process control system. The four groups are: Active An Active process control system is characterized by consisting of the most recent product offering within a category. Adding new process control loops or Input/Output (I/O) points in an Active process control system does not require the launch or rollout of a newer/later version of a given process control system. The Active process control system is fully supported by the Vendor, who can typically provide training in the 6

7 system for operations, and can troubleshoot and support debugging efforts or replacement of hardware which is found to be defective or not functioning properly. Active Mature An Active Mature process control system is fully supported by the Vendor, but a newer product or product family exists. In this case, adding new process control loops or Input/Output (I/O) points in an Active Mature process control system requires a decision to be made regarding whether the added functionality of the newer version of the product outweighs the risks and/or complications associated with migrating to a newer version. For example, one phosphate producer operating on a Siemens PCS7 platform had to make this determination when an expansion project added new I/O points in the system. The existing I/O points in this area were programmed in an older software version, but the Vendor had released a newer version at the time of the expansion project. The Owner decided to program the new points into the latest software, as the Vendor assured backward compatibility with the older version, and the latest software included better trending functionality. The addition of the new points into the latest software on a primarily older platform was successful. End of Life An End of Life process control system has had its discontinue date announced. The Vendor will no longer be manufacturing the equipment and hardware associated with the system in the near future. The Vendor would offer to buy back or exchange old equipment for upgrade and migration to the new product. The Owner, knowing that the end date is near, would likely begin ordering (and possibly overordering) spare parts for ongoing maintenance of the system at this time. Discontinued A Discontinued process control system is no longer being manufactured nor supported by the Vendor. It is possible that repair and/or exchange services are available from the Vendor at this stage. In other cases, no hardware or training support is available, and it is left to the Owner s process control group to scavenge as necessary to keep the system functional. It can become very expensive to source discontinued or obsolete parts as time goes by. This system status often is the result of Vendors buying out competitors, but only working to sell a new control system product. The system status can be thought of as a lifecycle continuum, starting with the latest technology, and finishing with obsolescence. A graphical depiction of this continuum is as follows: 7

8 Fig. 3 Process Control System Lifecycle Continuum As Owners move across this continuum, the incentive and necessity for process control system migration increases. As outlined above, in the absence of a recent migration program, most phosphate producers are in the End of Life or Discontinued phases with their process control systems. The risk of plant outages increases greatly with the lack of support of the process control system in the Discontinued stage of the life cycle. For example, one phosphate producer is running the majority of the plant on a legacy Bailey Infi90 process control system, which is in the Discontinued category. The reliability of the system is declining as the controllers and I/O modules are progressively failing. The Owner s process control group is sourcing used, reconditioned components from third parties and very expensive auction-type websites. Over time, the Owner has found that the resources with the requisite expertise to maintain and modify the older system have retired or left, leaving a knowledge vacuum behind. Also, the older system did not allow the Owner to leverage newer asset management and maintenance technologies that are now industry standards. The Owner has recognized the risks in operating in this manner, and has elected to pursue a staged, online migration across the various plant units, with Hatch providing the necessary control system engineering and programming support under the HPMP. Typical lifecycles for process automation system components are as follows: 8

9 Fig. 4 Average Process Automation Component Lifecycle in Years As Figure 4 indicates, many plants in the phosphate industry are approaching obsolescence for basic infrastructure such as wiring, and it is expected that overhaul or infrastructure replacement projects will become common going forward in addition to control system migrations, as plants experience failures and recognize the risks of running with obsolete process automation components. SELECTING YOUR PARTNER Owners generally know their plants and processes very well and are expert in maintaining production. However, the Owner typically lacks the resources and expertise to undertake a process control system migration without outside assistance. As a result, the one of the first decisions an Owner must make is the selection of a partner to lead the migration effort. For process control migration projects, there are typically three choices for selection of a partner: Vendor Local System Integrator Engineering Firm The consensus amongst process control professionals across multiple chemical process industries is that Vendors technology offerings, while different from one another, are generally adequate and provide the functionality as advertised. Vendor support can vary. For Vendors who have 9

10 not been on Owner sites on a day-to-day basis, there can be a lack of understanding of the plant processes and needs of the operations team which translates into dissatisfied end users. Local System Integrators can provide good value if they have been working on the Owner s site on various projects. This site experience leads to an understanding of the Owner s operations team needs and to an understanding of the overall plant processes. An Engineering Firm can be a good choice, especially as a follow-on to or as part of a major project. For the HPMP, the Owner chose Hatch to lead the migration effort because the expansion project had included the addition of new I/O and controllers to the existing process control system, and Hatch had had approximately two years on site continuously for both the expansion project as well as for other minor follow-on projects. As a result, Hatch was able to leverage both its process knowledge as well as knowledge of the plant control system, its personnel, and their preferences to begin to develop the HPMP scope in line with the Owner s expectations. Ultimately, regardless of which type of partner is chosen, the quality of service provided should be the deciding factor. It is well understood across the chemical process industries that service and personal attention from the selected migration partner is required in order solve problems with debugging and to enhance the system with providing additional functions as requested by the Owner s operations team. TYPES OF MIGRATION When it is determined that a process control system migration is necessary, then the Owner must decide what type of migration is required and what is to be migrated. The type of migration will depend on the state of the existing process control system. The types of process control system migrations fall into five broad categories as follows, each includes dollar signs to indicate the relative capital investment associated with each: Evolution ($) An Evolution-type migration generally requires only minor programming adaptations as it is in accordance with the Vendor s existing process control system. The current process control system situation is well understood, the path to the future condition is also well understood and changes are of a low risk nature. Convergence ($$) A Convergence-type migration is characterized by migrating to a technology already well established at the site. The current process control system is well understood as well as the desired final outcome. The migration will rely on existing standards for hardware, software version, and programming. The exact path to achieve the final outcome may require certain decision-making (online migration versus offline migration, will outside resources be required for the engineering and programming for the migration? Etc ). 10

11 Technology Change ($$$) A Technology Change-type migration involves a complete change to a new technology used little or not at all on site. While the current process control system may be well understood, the path to achieve the migration and the destination itself are likely not well understood. These migrations can be quite complex and require careful planning. An integrated team of Owner, engineer, and Vendor should be assembled to ensure that all standards for hardware, software, and programming are properly developed and that adequate system support for training and familiarization of operations staff with the new system is in place. Integration ($-$$$) An Integration is not normally considered a migration, per se, but is similar in the sense that it requires hardware, engineering, and programming in order to integrate different technologies, either temporarily or permanently into the plant operating platform. Hybrid ($-$$$) A Hybrid-type migration is composed of a combination of the other migrations outlined above. It is important to note that HPMP was a Hybrid Migration scenario where an Owners corporate mandate dictated a Technology Change migration from an obsolete Bailey Infi90 control system (now owned by ABB) to the latest Siemens PCS7 control system. An initial vendor led migration of the plants upper level systems (HMI servers and Operator consoles) led to a follow-up Convergence-type migration that was executed as part of a major plant expansion project that the Owner engaged Hatch to perform and ultimately resulted in the HPMP. Fig. 5 Preliminary Migration, HMI Level The Vendor-led migration was relatively inexpensive, utilizing a tool to import the legacy HMI screens into the new servers and operator consoles. However, old errors, patches, and workarounds embedded in the legacy system were propagated to the then newly configured 11

12 system. Also, legacy HMI standards (or lack thereof) and limitations were carried over into the new system. The majority of the plant is still on the legacy system, and Hatch and the Owner are working together in the development of a staged, online migration. The migration will take several years to complete, as the plant is cut over from Bailey to Siemens by major process unit WHAT TO MIGRATE? After determination of what type of migration is to be undertaken, the Owner needs to have a good understanding of what control system components need to be migrated. At a minimum, the equipment involved in a process control system migration is as follows: CONTROL SYSTEM MAIN COMPONENTS Central Processing Unit (CPU) Processors Communication Modules Input and Output (I/O) Modules Central Operational Interfaces aka Human Machine Interfaces (HMI) Additionally, there are other items which may or may not be migrated, depending on the state of the existing process control system: OPTIONAL MIGRATION COMPONENTS Local Operation Interfaces (Field HMI s) Networking (adaptations required) IT Equipment (Servers, PCs, etc. ) and Software (programming, engineering, etc. ) Interfaces with Other Systems Migration of the optional components is typically driven by the control system Vendor selection. The migration of these components hinges on compatibility with the selected Vendor s product line. Generally, a Technology Change (described below) would result in more optional components being migrated than other migration types. 12

13 Fig. 6 HMI and Alarm Optimization Before and After Migration MIGRATION: DETAILED PLANNING DETAILED DESIGN AND DOCUMENTATION DEVELOPMENT Proper planning is required for any project, and the larger or more complex the project, the greater the planning effort required. The following are steps that were taken for the HPMP engineering and are typical for any control system migration project: Control System I/O Field Verification Extensive field investigations were conducted to ensure that the master I/O List was current and validated against actual connected field wiring and also against existing DCS code and HMI. Numerous points were clarified with operations and maintenance teams (field wiring abandoned in place, DCS code fragments that were unused, etc.) Updates to Existing Documentation - All existing drawings (Loop Drawings, Motor Schematics & Junction Box Wiring Diagrams) were collected and where missing they were created based on field verification of wiring and cabling. These documents were updated to showing all new terminations at DCS. An additional level of effort was required to as-built these drawings to reflect multiple field modifications. 13

14 Control System Hardware Design In the HPMP scenario, we required extensive detailing of new backplanes with heavily customized design and component selection due to space constraints in existing legacy control system cabinets. Standardization of hardware components was maintained, but location of specific hardware was made suitable to specific field cabinet realities (i.e. location of marshalling terminals to account for field cable entry to the panel being top entry or bottom entry). Control System Hardware Fabrication and Acceptance Testing Customized backplanes were fabricated and extensive hardware and software testing was conducted at the panel fabrication facility to ensure that the panels complied with approved design drawings and that they were functional from a software standpoint (i.e. Analog and Digital points were working). Panels were modified to reflect all punch-list items identified during testing. Control System Software Design In the HPMP, DCS and HMI code were developed in accordance with approved programming standards and FD s. Print outs of legacy code and HMI screens were used to provide another level of back-checking. Continuous interface with operations, maintenance, and process control teams was required to eliminate legacy coding errors from being propagated to the new system. Control System Software Acceptance Testing Once programming was completed, the software testing was formalized with the Owner s Team (operations and process control). The code was verified against the approved programming standards and FD s. FD s were updated to match any functional changes that were introduced during acceptance testing. Code was updated to reflect all punch-list items identified during testing. PROGRAMMING STANDARDS DEVELOPMENT In plants that have been through multiple expansions over the years, there is often no single standard for the development of a process control system in place. Rather, there is typically a serious lack of standards or governing documentation for the development of the HMI screens and programming logic. In the case of the HPMP, Hatch worked with the Owner, Vendor and operations team as part of an expansion project to document and define standards for control system hardware and software. The methodology used to develop the control system programming and HMI standards included a thorough review of the legacy code functions to define similar or enhanced functions in the new system code. In addition to reviewing legacy code functions some additional elements that require review and documentation include: Tag Naming Conventions (control system components, field components, networks, etc.) Control System Architecture (servers, controllers, remote I/O, I/O cards, etc.) 14

15 Controller Programming Methods (hierarchy, function blocks, HMI Programming Methods (colors, graphics, text, format, etc ) Alarm Management Data Historian It is critical that standards for the hardware, software, and programming are in place prior to the start of a migration, or that these are developed at the outset of the migration project. FUNCTIONAL DESCRIPTION DEVELOPMENT Another key design basis document that should be developed is the Functional Description. The Functional Description (FD) provides the operation and process control requirements for the equipment involved in a given process unit within the scope of the project. The primary purpose of the FD is to govern all PCS programming efforts, but is used to establish the basis for agreement between the Owner and the engineer on the functionality of the new Process Control System (PCS). The complete description of the functions to be performed by the software specified in the FD assists the Owner in determining whether the software specified meets their operational and process control requirements. The level of detail of the FD is intended to be sufficient to eliminate ambiguity as to the nature and intent of the functionality of the PCS, while at the same time giving the PCS programmers the necessary latitude to implement the functions as appropriate. The FD further provides a baseline for the validation and verification of the PCS programming efforts. It is important to notice that the FD document is not intended to be a replacement of a Standard Operating Procedure or a Plant Operator Training Manual. Where documented programming does not exist, typically the engineering contractor will develop a preliminary version of the FD based on control logic shown on P&ID s, system architecture diagrams, operating procedures, and other project documents. This preliminary FD is then formally reviewed at site with plant personnel including area process engineers, control room operators, and the plant s process control systems group. This formal review process enables the engineering contractor to capture all relevant redline comments regarding programming logic, HMI screen design, and trends or tracking functionality requested by the plant. The FD is then revised and issued for use by the plant and the programmers. Standard elements of the FD are as follows: Introduction This section includes a statement of the intent of the FD, as well as a list of abbreviations and reference documents. The reference documents cited in this section are 15

16 normally the required inputs that help guide the development of the FD and essentially document the existing code. Process Area Overview This section summarizes the overall process description and includes a listing of the major tagged equipment in the area (e.g. vessels, tanks, pumps, agitators, etc ). Control System Description This section outlines the system architecture which will be utilized as well as the controllers location and function. This section also describes the locations of the remote I/O racks and the Operator Station (OS) Servers as well as the Local (Field) Controls and Operator Station consoles. Process System Description This section describes the specific details of a process system and the equipment associated with that system. Typical sections and content descriptions of process areas from the HPMP are as follows: o Tabulated lists of P&ID s, Motors, Valves, Control Loops, Instruments, etc. o Alarms These normally appear on a separate Alarm List attached to the FD o Inter-Controller Data Exchange These normally appear on a separate list attached to the FD o Control Methodology This section describes the calculations that are programmed into the DCS as well as the programming logic associated with tripping the setpoints associated with the calculated values (e.g. close or open a valve when a value is achieved) o Equipment Program Sheets The equipment program sheets describe the DCS programming / monitoring requirements for a given piece of mechanical equipment within the process system. The following example is that of a feed pump in the No. 1 Reactor Feeds System: 16

17 Fig. 7 Equipment Program Sheet MIGRATION STRATEGY DEVELOPMENT While the programming standards and FD outline the hardware, software, and programming standards to be implemented or maintained for a process control system migration, the phosphate producer must also select the proper migration strategy for a given situation. For the HPMP there were two broad categories of migrations that were assessed: Online Migration For this migration option, the cut over to the new process control system is done during plant operations in a staged or phased fashion. The main benefit of this migration 17

18 option is that it can be done process system by process system, with less pressure to cut over all at once. This option requires careful packaging of the cut over scopes to coincide with unit downtimes or maintenance cycles. One of the drawbacks of this option is that the Electrical and Instrumentation (E&I) Contractor hired to assist with the cut over would potentially have to mobilize and demobilize several times throughout the life of the contract in order to support each of the cut over scopes. Ideally, the planning strategy for packaging the work would produce a steady stream of small amounts of work for the E&I Contractor so that the contractor could mobilize a small team on an almost continuous basis to support the cut over effort. Offline Migration For this migration option, the cut over to the new process control system is done during a plant outage. The main benefit of this migration strategy is that it does not disrupt plant operations. One of the drawbacks of this method is that it requires waiting for planned plant outages which may be few and far between resulting in a migration process stretching over multiple years and running the risk of the new control system becoming out dated before the it is even completely installed. Another issue is that plant outages are often focused on major mechanical and maintenance work tasks and thereby potentially minimizing the real available time to implement a control system cut over. For the HPMP, the Owner requested that Hatch pursue an online migration strategy in order to reduce the need to wait for planned plant outages, since previous expansion projects were successful in reducing the need for annual outages (the expansion projects added a train of process equipment which enabled the plant to run while other trains were down for maintenance). No plant downtime was specifically allocated for the cut overs, so Hatch, in concert with the Owner, developed a Migration Strategy Plan (MSP) for the project. The MSP was a formal document, developed in much the same way as described above for the FD. The MSP developed for the HPMP includes standard elements of any migration plan, and these are as follows: Introduction This section includes a statement of the intent of the MSP, which, in the case of the HPMP, was to outline the approach which was to be adopted in order to facilitate the successful on-line migration of the control system. It defined the activities, resources and scheduling required which were aimed at replacing the existing system safely, with as little as possible unplanned downtime or process interruptions as possible. Project Description This section includes a description of the existing process controllers, their physical location, a listing of the I/O cards that report to the controllers and their locations. The HPMP MSP goes on to describe what functionality will be replicated by the new Siemens PCS7 system and the communications protocol. 18

19 Additionally, each I/O cabinet area is described, detailing which panels or cabinets are to be used for the migration and whether they will be new or existing. Migration Organization and Responsibilities This section includes a listing of off-site activities (hardware design and engineering; software design, engineering and testing; hardware procurement, manufacturing and testing) and on-site activities. Also included is a clear delineation of the roles and responsibilities associated with the migration including the roles of the Owner s Team: Engineering, the Operations Group, the Construction Group, Commissioning Group and Equipment Vendors. Clearly defining these roles prior to the commencement of migration will greatly increase the probability of success. On-Site Activities and Prerequisites This section identifies the prerequisites that need to be completed before onsite activities can commence. In addition to this, the basic approach to each phase of the onsite activities is defined. The onsite activities are broken up into four groups: o Pre-Migration Installation Activities o Power-Up and Commissioning Activities o I/O Cutover and Re-commissioning Activities o Post-migration Cleanup and Final Installation Activities Cut Over Packages It is the responsibility of the Migration Engineer to compile, coordinate and update the cut over packages with input from the Owner s operations and maintenance teams as well as the software engineer. Scheduling and prioritization of packages will be dependent on planned as well as un-planned process downtimes, i.e. equipment that is designated as to be cut over offline, will be prioritized if a planned or unplanned process outage occurs. Packages where all equipment and devices are designated to be cut over online, will be scheduled during periods where no process downtimes are planned. The general approach for each package, highlighting the major equipment and devices that may require special attention during cut over activities is tabulated by process area in this section. Returning to our HPMP No. 1Reactor Feeds System example, the cut over summary tabulation is as follows: 19

20 Equipment Description Type Classification Proposed Critical Redundant Cutover / / Non- Non- Critical Redundant PP-1102A FY-10302B WIC FIC No. 1 Reactor Rock Slurry Feed Pump A Reactor Sulfuric Latch Valve Weight Control Loop for Rock Slurry to No.1 Reactor Flow Control Loop for Sulfuric Acid to No.1 reactor Electrical Critical Redundant On-line: Redundant unit in service Solenoid Critical Non- Redundant Control Critical Non- Redundant Control Critical Non- Redundant Off-line Possible on-line if solenoid can be forced in field On-line: VFD local speed Off-line FT-10101A FI-10101A Monitor Critical Redundant On-line DT-10358A DI-10358A Monitor Critical Redundant On-line PT PI Monitor Critical Non- Redundant Fig. 8 Sample Cut Over Package On-line: Forced value / interlock bypassed Dependencies FIC WIC TT GA-1202 FIC WIC PT HV PP-1102A PP-1102S FY-10302B FIC WIC PT FY-10302B FIC Schedule Prior to commencement of the work, the detailed scheduling of individual cut over packages should be determined on site with the necessary inputs and coordination with the Operations Group and other dynamic factors such as scheduled and unscheduled system and sub-system downtimes. Prior to that, for an online migration, such as the HPMP, pre-migration, migration, and post-migration installation durations can be estimated. 20

21 Once cut over packages are defined and durations established, the Migrations Engineer can work directly with the Operations Superintendent and Maintenance Supervisors to identify downtime slots for staged/phased migrations to occur. The MSP needs to address I/O cut over from a field perspective as well as HMI cut over from an operational perspective and must be appropriate for each process system and subsystem. This development and planning must be conducted in concert with the Owner s Team (operations, E&I maintenance, and controls). The HPMP had a total of 661 I/O points to cut over during the migration. With the inputs from operations on the original MSP, each signal was classified as either changeable Online, Offline, or during Turnaround (a pre-planned process plant maintenance outage). Online signals were I/O that could be changed over while the associated system or subsystem was in operation. Offline signals were I/O that could be changed over during normally scheduled process downtimes (e.g. when the filter table is down for washing). Turnaround signals were signals that could be changed over during a pre-planned process plant shutdown period. For the purpose of this paper, only the total classification breakdown per system have been included: System Online Offline Turnaround Reaction Filtration Evaporation & Fluorine Recovery Acid Load Out Rock Receiving Storage Safety Showers Fig. 9 I/O Signal Classification per System Finally, as part of any successful migration execution, there needs to be daily meetings with the Owner s Team and contractors to discuss plans for the day and to ensure safety and continuous alignment with any unplanned process area or equipment outages. The previous day s progress is reviewed against the original plans and any necessary adjustments made (e.g. staffing, communications, coordination with plant operations, etc ). 21

22 HPMP BROWNFIELD MIGRATIONS EXAMPLES The following are examples from the HPMP which illustrate the various situations that the phosphate producer will face during a migration, and the strategy selected to cope with the given scenario: EXAMPLE 1: MARSHALLING CABINET I/O o Footprint: Space is available o Shutdown Required: No o Solution: Online migration with new cabinets. Demolish old controller and I/O cabinets when migration is complete. Marshalling cabinet will not be demolished. Cabinet / IO Location CPU (3 Bailey Cabinets) MCC-1 (Ground Level) EXISTING PANELS MIGRATION PANELS Cable Entry Top Migration Opt Jumper Cables Cabinet Type Bailey Front/Back Cabinet Type Siemens/Rital - Front Bailey PCU 2 Siemens Ctrl New AS/OS SULF Field Wiring Marshalling Terminals Backplane Siemens Standard Comments Use existing Bailey marshalling cabinet. Jumper cables to new front entry Siemens cabinets containing marshalling/mtas/io/cpus. Demo old Bailey CPU/IO cabinets. 22

23 Fig. 10 Example 1: Marshalling Cabinet I/O Table and Picture EXAMPLE 2: CABINET o Footprint: Space is not available o Shutdown Required: Yes o Solution: Offline migration within existing cabinet. Temporarily locate new backplanes on cabinet doors, and then swing new backplanes into cabinet when old hardware components are demolished. Retain certain old hardware components for future use. 23

24 Cabinet / IO Location (1 Blue Honeywell Cabinet) MCC (Sub A) Ground Floor EXISTING PANELS MIGRATION PANELS Cable Entry Top Migration Opt New Backplanes Cabinet Type Honeywell/TDC Cabinet Type Use Existing Bailey PCU 4 Siemens Ctrl New AS/OS Field Wiring Marshalling/IO Cards Backplane 23 W x 70 H (x2) Comments Use existing cabinet and swing field wiring to new backplane with new marshalling/io/cpus (fixed on cabinet doors). Demo old Bailey components and then swing new backplanes into old cabinets. NOTE: Keep old IT (current transmitters) intact. Fig. 11 Example 2: Cabinet Table and Picture 24

25 CONCLUSION AND RECOMMENDATIONS FOR FUTURE MIGRATIONS Do your homework! ~ Gerald G. Hatch In a world of falling commodity prices and an ever increasing focus on production margins and profitability it has never been more important to insure that critical process control systems are able to meet the challenge. Best practices and latest technologies that are inherent in new systems are an important consideration to insure that previously invisible plant assets are able to be managed and maintained. Operational safety, process optimization, and production uptime are all dependent on the reliability of control systems and all their associated hardware and software. Each is process facility is only as strong as its weakest component. The question any owner can ask themselves is not if but when they will need to migrate their existing process control system and as such it is a discussion that should be addressed proactively. It cannot be emphasized enough that early planning and comprehensive preparations are the surest way to ensure the success of any migration project. Fig. 12 Many Reasons to Migrate The HPMP is currently in progress, but based on previous experience in similar migration projects we can be confident that the carefully executed steps that we have outlined in this paper will continue to insure ultimate project success as it had done for us time and again in the past. With that in mind, what follows are recommendations for any future migration projects that phosphate producers should already be contemplating: 1. Determine Your System Status 2. Select Your Partner (Service is Key) 3. Create an Integrated Migration Team 4. Determine Type of Migration 5. Understand What to Migrate 6. Develop Detailed Design Documents 7. Create Software/Hardware Standards 8. Produce Functional Descriptions 9. Plan a Detailed Migration Strategy 10. Execute the Plan (Daily Meetings) 25

26 Fig. 13 Many Opportunities When Migrating Fig. 14 Control System Cabinet Before and After Migration 26

27 REFERENCES Hebert D Best Practices in Control System Migration. Control Global. O Brien L. and Woll D The Control System Migration Survival Manual. ARC Advisory Group. ARCweb.com Jacques P Migration of Control Systems. Unpublished presentation. Located at: Hatch Baird F HPMP Migration Strategy Plan. Unpublished work product. Located at: Unavailable Baird F HPMP Functional Description. Unpublished work product. Located at: Unavailable THANK YOU!!! 27