Planning I&E activities for control system migration projects
While some of these elements may seem relatively minor, dealing with them early in the planning process keeps them from becoming major problems.
A comprehensive—hardware and software—control system migration project normally involves some combination of the following engineering activities:
• Control system database development
• Control logic and function block programming
• Batch programming
• HMI graphical user interface development
• HMI alarming, and
• I&E (instrumentation and electrical) design engineering.
The planning process for such comprehensive migration projects is critical for the I&E design engineering effort as well as all other project activities because a good planning process can identify additional and less obvious work activities or equipment that are needed but might not have been anticipated or addressed otherwise. Since additional work and equipment affect cost and schedule, an initial, high-level pass at I&E planning should be conducted during the project scoping stage of these projects, with more detailed planning performed during project implementation. (Please read an earlier blog post for additional thoughts regarding scoping automation and control projects.)
Control system transition, documentation methodology, integration of existing hardwired and pneumatic control functionality, and the assessment changes to plant standards or practices are some of the I&E design engineering activities that can justify planning in order to reveal and address invalid assumptions or otherwise unanticipated concerns to ensure project success.
Control system transition
Distinct transitional phases may need to be identified and ultimately assigned to control loops as a coordination tool to ensure success. For example, during large system migrations, one or more processes within a manufacturing facility are often required to continue operating—on the existing control system—while other parts are shut down for the upgrade. Although the original control system hardware design might have segregated these different process areas, the numerous projects implemented over the past 20 or 30 years might have mixed the different process areas by using the available spare I/O, wherever it might have been at the time.
Identifying transitional phases for the control loops is the first step to ensure they will be available whenever needed throughout the migration process. Such large systems also tend to have several critical and shared utility functions used by all operational areas for which additional transition management is required. On a related side note, given that running multiple control system platforms simultaneously will tax the support infrastructure, the project team should consider whether the existing UPS has sufficient capacity to power both the existing and new control system hardware for the duration of the transitional period.
Since P&ID’s are normally considered the preeminent document of record, the project plan must clearly specify who has custody of the P&ID’s, how comments from various sources are collated into revisions, and how the revisions are distributed to the extended project team.
The project plan should also define whether existing loop sheets and/or I/O loading drawings will be revised or whether entirely new drawings will be created. The extent to which the existing drawings have been maintained over the years and whether native CAD files are available are normally key factors in this decision.
The project plan should include sufficient time and cost for what can be a lengthy work process to establish the large and complex database infrastructure that can be required if an automated drawing generation tool, such as Smart Plant Instrumentation (SPI), is to be used.
The project team should consider construction and maintenance implications of the wiring tagging nomenclature used on new or revised drawings. For example, incorporating the existing control system I/O addressing in the wire tagging on the new or revised drawings could avoid the need to physically re-tag each of the numerous signal wiring terminations that will remain in service within existing marshalling cabinets, field junction boxes, and field instrument housings when the existing wiring is tagged with I/O addressing instead of by device tag.
Integrating existing hardwired and pneumatic control functionality
An engineering work process could be required to identify and define existing hardwired control functionality, such as relays, stand-alone loop controllers, hardwired push-buttons, specialized control panels, etc., that should be implemented within the new control system. These functions can easily be missed because they do not normally appear within the tag name lists or logic configuration files extracted from existing control systems.
The magnitude and nature of this work can vary widely depending upon the vintage of the existing control system as well as the plant’s past engineering practices. This work can also be complicated by the fact that the existing, original hardwired relay design might not have made clear delineation separating safety instrument system (SIS) functionality and basic process control system (BPCS) functionality as needed for implementation on the new platform.
For some projects, large quantities of hardwired relay schematics must be analyzed to document or verify existing control functionality and distill a multitude of interconnecting wiring down to what will become physical I/O and internal control functions on the new system. In some cases, special DCS electronic hardware—that will not appear in existing DCS software configuration files—was used on older-vintage DCS platforms to provide discrete control and/or alarming signals to field devices and/or other systems.
Project teams should also identify any existing pneumatic control functions and consider integrating them into the new control system as part of a comprehensive migration or upgrade project.
Assessment of changes to plant engineering standards or practices
The project team should consider whether changes to the plant’s engineering standards or practices will expand the project scope. For example, the plant’s motor control philosophy could have changed since the original installation such that the new control system must now provide start/stop/run status motor control, as opposed to the existing, local field push-buttons, perhaps because the facility intends to have fewer “outside” operators to improve personnel safety and reduce cost. Another example could be a plant’s adoption of intrinsic safety (IS) barriers upstream of field devices in non-hazardous locations, typically control building I/O rack rooms, which can be appealing for greenfield projects, but are not normally cost-effective on migration projects where existing field wiring is to be reused because IS wiring must be installed in separate raceways from non-IS wiring.
Other examples of possible engineering practice changes since the original installation are separating SIS wiring from BPCS wiring, separating 120 Vac control wiring from 24 Vdc control wiring, standardizing on 24 Vdc I/O and eliminating 120 Vac I/O, and using smart motor control centers (MCC’s) on discrete fieldbuses for motor control instead of hard-wired start/stop signals.
Although each project has its own unique needs and there certainly are other aspects worthy of consideration, deliberately planning these I&E design engineering activities for a comprehensive control system migration projects can help you achieve project success.
This post was written by Shane Hudson. Shane is a principal engineer at MAVERICK Technologies, a leading automation solutions provider offering industrial automation, strategic manufacturing, and enterprise integration services for the process industries. MAVERICK delivers expertise and consulting in a wide variety of areas including industrial automation controls, distributed control systems, manufacturing execution systems, operational strategy, business process optimization and more.
Case Study Database
Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.
Annual Salary Survey
In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.
Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.