Free Magazine Subscription
Printer-friendly version
Email to a Friend
The Making of the PLC
As the automation workhorse celebrates its 40th anniversary,Ken Ball provides this fascinating account of the evolution of the PLC.
Programmable logic controllers (PLCs) were more of a technology evolution than a startling discovery. Identifying the needs and early ideas first began to take shape in 1967. Documentation and actual building of prototype devices started in 1968, with early model deliveries and factory tests taking place in 1969 and1970.
The earliest robust, easily reprogrammed industrial controller – which we know as the PLC – evolved nearly concurrently along three independent paths and involved five companies: Bedford Associates; General Motors (Hydra-matic Division); International Instruments (3I); Digital Equipment Corporation (DEC); and Struthers-Dunn Systems Division.
Probably the most publicized early PLC development took place at GM’s Hydra-matic Division plant. Several engineers collaborated on a concept for what they called a “standard machine controller”, sharing their ideas with a number of GM technology vendors such as DEC and 3I. The GM engineers envisioned a controller to replace troublesome relay panels and provide a simpler interface between computers and machines.
Meanwhile, a second path was being pursued by Bedford Associates, a small New England company that today would be categorized as a control systems integrator. Bedford engineers developed a controller to replace costly minicomputers and reduce programming time for various machine tool applications.
The third approach underway at the time occurred at the Struthers-Dunn Systems Division. The relay manufacturer was probably best known at the time for its pocket “Relay Engineering Guide,” which taught engineers how to do logic and other clever things with relays.
Struthers-Dunn Systems also had strong automotive ties and was well aware of the shortcomings of relay and timer panels in the automotive mass production environment. The company’s intent was similar, in many ways, to that of the GM group – to develop a product that could replace costly, troublesome relay and timer panels.
Don’t call it a computer
Applying industrial computers during the mid- to late 1960s required a great deal of vendor support due to the cost and size of the associated projects. In the mid 1960s, for example, IBM 1800s or GE PAC 4000s were being budgeted at about a half million dollars – about evenly split between the hardware and programming/debugging (all dollar figures mentioned in this article reflect the time period noted).
As a result of these costs, minicomputer competition became intense and costs dropped appreciably. However, most installations were still a US$200,000 headache. These high level expenditures made computer installations the last thing most plant managers wanted to deal with at their facilities. Therefore, the persons incorporating digital monitoring and control capabilities into fledgling programmable controllers dared not mention the word “computer” to potential customers.
Dick Morley, founder and president of Bedford Associates, recognized this issue and, along with the other engineers in the company, decided to name their product Modicon, which was an acronym of MOdular DIgital CONtroller. This “don’t mention computer” strategy carried over to other PLC suppliers.
In 1967, a large problem for Morley’s operations was the six-month or so programming time required to get each minicomputer installation up and running at a client site. Many of Bedford’s projects weresimilar, thereby leading to frustration with the costs of programming and debugging that wasrequired to be done over and over.
This led Dick Morley to begin having thoughts of how to build a simpler but rugged, computer-like control unit that could replace minicomputers for machine tool control and related parts handling.
According to Morley, while walking off the effects of a New Years Eve party on January 1, 1968, he composed a 12- page concept memo which has become known as the earliest documentation of PLC development activity.
Bedford had a prototype up and running by March that they nicknamed “Stupid.” This was the company’s 84th project and so the prototype controller officially became the 084. Early demonstrations were made at Bryant Grinders and Landis Machines.
Detroit wish list
In May 1968, Bedford Associates sales manager, Lee Rousseau, attended the Westinghouse Annual Machine Tool Forum in Philadelphia. There, a speaker from GM’s Hydra-matic Division presented a wish list of needs and specifications for a standard machine controller.
Visits to the Detroit area, however, completely revised Rousseau’s market perceptions. The company would remain an engineering services provider and a manufacturing company would also be formed.
Four vendors – 3I, DEC, Allen-Bradley, and Century Detroit – were initially given copies of the preliminary specifications from GM. Cutler-Hammer, Cincinnati Milling Machine, and Bedford Associates were also included in the solicitation shortly thereafter. Of the group, only 3I, DEC, and Bedford Associates responded with product offerings.
First with a product to GM was DEC, with its PDP-14 unit delivered in June 1969 and installed on a gear grinding machine. Later that summer, 3I delivered its PDQ-II to control a segment of an assembly machine (PDQ stood for Program Data Quantizer). Bedford Associates, having organized its new manufacturing company – Modicon – delivered its 084 unit in November of 1969 to replace relay panels for a gear grinding machine.
After initial factory evaluations, Square D negotiated with DEC and began selling the PDP-14 and 14L. GE private-labeled Modicon’s 084 as the GE PC-45. And Struthers-Dunn Systems began marketing its VIP line.
Prices for these early PLCs ran in the $3,500 to $7,000 range. Because it didn’t take much of a production operation to justify the cost of a PLC, word of the new programmable controllers spread rapidly.
Working with Hydra-matic, 3I president John Dute appraised the PLC market potential and realized he needed financing to compete. He brought in Allen-Bradley, who bought 25 percent of 3I, rights to market the PDQ product, and an option to acquire 3I. Allen-Bradley exercised that option in 1969, but also began an in-house PLC R&D program. The PDQ went through several upgrades but eventually was discontinued.
Becoming established
Both GE (Logitrol) and Square D (SY/MAX) developed their own PLC products and became major suppliers. Industrial Solid State Controls (ISSC) introduced its IPC-4000 and Honeywell became the sales agent. Reliance Electric introduced the Automate 33. Allen-Bradley brought out the PMC (programmable matrix controller) and the PLC-1. Cutler Hammer began marketing an Entrekin-developed CON-64, and Datrak became a PLC supplier.
The period between 1972 and 1975 saw further growth and solidification in the use of PLCs. By 1975, a PLC base was established which led to exponential growth throughout the remainder of the decade and beyond.
Fifteen companies exhibited at the 1975 Controls Show. And by that year, a number of European and Japanese controls manufacturers began offering PLC products.
Early on, the controller was known as the PC and publications such as the PC Insider popularized the designation. This was fine until personal computers arrived around 1980 and this office/ consumer item stole the PC acronym.
To avoid confusion, controls people reverted to a PLC designation – a term that had been registered by Allen-Bradley for their newer model controllers. Allen-Bradley/Rockwell Automation has been quite gracious and has not attempted to restrict the use of the “PLC” term.
DEC was somewhat of a mystery with respect to the PLC industry. After the most noted start among the three GM suppliers, they quietly faded from the business about two years later. A major reason for this was the complexity of the PDP-14’s programming scheme. But why this wasn’t upgraded along with other improvements, as all PLC suppliers made, remains a question.
Shortly after its debut, PLC sales went from zero to more than a $1 billion in a little more than a decade. Equally significant is the fact that PLCs became the workhorse of factory automation. Other technologies such as CNC, motor drives, motion control, robotics, automatic ID systems, and vision systems became factory functional by becominghitched to a PLC system.
-----------------------------------------------------------------------------------
Decision: PLC or DCS?
As the evolution of control technologies makes it even more challenging for process manufacturers to select the best technology, Bob Nelson and Todd Stauffer provide some useful advice on makingthe right choice.
It used to be fairly easy to determine whether a distributed control system (DCS) or a programmable logic controller (PLC) based system was right for your application, because their strengths and weaknesses were well understood. In recent years, however, this has become more difficult, thanks primarily to the advancement of the microprocessor, which has allowed the technologies to converge.
The convergence of PLC and DCS has opened up a new set of options for those process plants that traditionally used PLCs to control their electrical infrastructure (such as motors, drives, and motor control centers), and DCSs for regulatory control.
And because your applications may have grown or evolved, you may find that a traditional PLC or DCS no longer meets your requirements. Understanding the merging of PLC and DCS functionality is important for selecting the best system for your company.
Please realize that we will be using broad generalizations in the following analysis, and that every individual application will have exceptions to these “rules.” However, the logic is still sound. Since the authors work on different sides of the PLC/DCS fence for a supplier that has delivered both DCS and PLC solutions to the market for over 25 years, we feel that we are in a unique position to deliver both sides of the story.
At first glance, system architectures look very similar – and they are. Both systems share the following components: field devices, input/output (I/ O) modules, controllers, human machine interfaces (HMIs), engineering, supervisory control, and business system integration. The differences become more apparent when you consider the nature and requirements of an application.
For example, in a DCS architecture, redundancy is often employed for I/O, controllers, networks, and HMI servers to ensure 100 percent availability. One of a PLC’s most common applications is the control of discrete field devices such as motors and drives. Effectively doing that requires that the controller be able to execute at high speeds (typically a 10 to 20 ms scan rate), and that the electrical technician responsible for maintaining it be able to read and troubleshoot the configuration in a language that he is familiar with (commonly relay ladder logic).
Because PLCs and DCS are not that different from a technology point of view, we must look beyond technology to the application expertise and domain knowledge built in to these systems by suppliers. This can help to better understand the sweet spots whereeach is best applied.
Asking questions
The seven questions that follow are designed to make you think about your company’s operating philosophy and application requirements, taking into account the point of view of all the major stakeholders in the plant (engineering, operations, maintenance, etc.).
1. What are you manufacturing and how?
This may seem like a very basic question, but it is fundamental to determining the requirements of the application and, therefore, the best-fit automation system.
Typical factory automation applications, for which the PLC was originally designed, involve the manufacturing and/or assembly of specificitems. These applications may employ one or more machines and a fair amount of material movement from machineto machine.
A typical characteristic of this type of process is that the operator can usually monitor the items visually as they progress through the manufacturing line. The process is, by nature, very logiccontrol- intensive, often with high-speed requirements (throughput = profits). This type of process is often controlled by a PLC and HMI combination.
Process automation applications, however, typically involve the transformation of raw materials through the reaction of component chemicals or the introduction of physical changes to produce a new, different product. These applications may be composed of one or more process unit operations piped together.
One key characteristic is that the operator can’t see the product. It is usually held within a vessel, and may be hazardous in nature. There is usually a large amount of simple as well as complex analog control (e.g., PID or loop control), although the response time is not exceptionally fast (100 ms or greater).
This type of process is often controlled by a DCS, although the analog control capability of a PLC may be more than adequate. A determining factor in the selection process is often the scope of the control application (i.e., plant-wide versus single unit, and number of I/O points).
Process applications may also have sequential (or batch) control needs. A PLC can be used effectively for “simple” batch applications, while a DCS is typically better suited for “complex” batch manufacturing facilities that require a high level of flexibility and recipe management.
2. What is the value of the product and the cost of downtime?
If the value of each independent product being manufactured is relatively low, and/or downtime results in lost production, but with little additional cost or damage to the process, the PLC is the likely choice.
But if the value of a batch is high, either in raw material cost or market value, and downtime not only results in lost production but potentially dangerous and damaging conditions, the selection should be DCS.
In some chemical applications, maintaining the process at steady state is critical, because if the system goes down, the product could solidify in the pipes. If the cat cracker in a refinery goes down it could be days before it can be brought back on-line and that means lots of lost revenue.
In contrast, the bottling operation of a brewery that only needs to run 10 hours a day to meet production schedules, and which can be shutdown for system maintenance, troubleshooting, or upgrades, is a classic PLC application.
Dangerous downtime is clearly another deciding factor. The more volatile the application, the more it may require a solution with lots of redundancy to ensure that the system is available when needed.
3. What do you view as the “heart” of the system?
Typically, the heart of a factory automation system is the controller (PLC). It contains all the logic to move the product through the assembly line. The HMI is often an on-machine panel or a PC-based station that provides the operator with supplemental or exception data. Operational information from data analysis is increasingly needed, however, driving demand for more robust HMIs.
In process automation, where the environment can be volatile and dangerous, and where operators can’t see the actual product, the HMI is considered by most to be the heart of the system. In this scenario, the HMI is a central control room console that providesthe only complete “window” into the process.
5. What system performance is required?
The speed of logic execution is a key differentiator. The PLC has been designed to meet the demands of high-speed applications that require scan rates of 10 ms or less, including operations involving motion control, high speed interlocking, or control of motors and drives.
A DCS doesn’t have to be that quick most of the time. The regulatory control loops normally scan in the 100 to 500 ms range. In some cases, it could be detrimental to have control logic execute any faster – possibly causing excessive wear on final control elements such as valves, resulting in premature maintenance andprocess issues.
The extra cost for redundancy, an insurance policy of sorts, may be well worth it in the case of the typical DCS system, but is often not cost-justified for PLC-based systems.
Taking the PLC system offline to make configuration and engineering changes may have less impact, since the platform is not running continuously or because the process can be restarted easily.
In contrast, configuration changes and tweaks to the DCS system are done online, while the process is running virtually non-stop. A blast furnace, for example, is planned to stay online continuouslyfor five to seven years.
6. What degree of customization is required?
The expectation and desire to be able to create a customized application varies greatly between DCS and PLC users. Because the PLC was originally designed to be a jack of all trades, it’s understood that the development of customized routines and functions is required to meet the unique needs of an application.
Pre-engineered solutions, consisting of standards, templates, and extensive libraries, are what DCS application engineers expect outof- the-box when working with a new system. The highest priority of a DCS is to deliver reliability and availability, which often results in a design which trades unlimited functionality for repeatability and dependability. The significant tradeoff with the DCS is its inability to accept many custom modifications without creatingcompatibility issues.
7. What are your engineering expectations?
Factory automation engineers want customizable control platforms, which offer the individual components that can be quickly programmed together to accomplish the task at hand. Often integrators and engineers open the PLC toolkit, roll up their sleeves, and start programming. The tools provided by a PLC are typically optimized to support a bottom-up approach to engineering, which works well for smaller applications.
DCS engineers, on the other hand, are typically most effective using a top-down approach for engineering, which forces them to put significant effort into the upfront design. The ability to propagate libraries and templates throughout the application is very importantto minimize rework and promote the use of standards.
Bob Nelson, PLC Marketing Manager, and Todd Stauffer, DCS MarketingManager, are with Siemens Energy & Automation.
-----------------------------------------------------------------------------------
--------------------------------------------------------
Controller/DCS convergence quiz
One simple method for gauging whether you should be using a PLC or DCS is to take this quiz, checking all of the responses that apply. If more of your responses are in the left (darker) column, then your application clearly calls for a PLC; more selections on the right points toward use of a DCS. If you have multiple selections from both columns, you may have a “hybrid” application, which requires a process control system capable of delivering both types of functionality.
Controller/DCS convergence quiz
--------------------------------------------------------
--------------------------------------------------------
What about hybrid apps?
We have explained the key attributes and differentiators between classic PLC and DCS systems. The same categories of information can be used to define the key requirements for a control system suited for “hybrid” applications. If the quiz you took revealed a roughly equal number of check marks on the left (PLC) side and on the right (DCS) side, you have a hybrid application.
If you determine that you have a hybrid control situation, here are the things you need in your process control system:
• Controller – can execute fast scan logic (10- 20 ms), such as that required for motor control, and slow scan logic (100 - 500 ms) such as required for analog control, simultaneously in a single controller.
• Engineering configuration languages – provides ladder logic, function block diagram, and a powerful programming language for creation of custom logic from scratch.
• Redundancy – offers the option of tailoring the level of system redundancy to deliver the required system availability by balancing up-front cost versus the cost of unplanned downtime.
• Batch capabilities – provides modular batch capability to cost-effectively address the continuum of simple to complex batch applications
• Alarm management – offers power alarm management tools to help operators respond effectively to plant upset conditions
• System diagnostics/asset management – provides both a rich set of built-in system diagnostics, as well as asset management of all critical assets in the plant (transmitters, valve positioners, motors, drives, MCCs, heat exchangers, etc.)
• Scalability – hardware, software, and licensing supports smooth and economical scaleup from small all-in-one systems (10’s of I/O) up to large client/server systems(10,000’s of I/O)
-----------------------------------------------------------------------------------
A Question of Migration
When a process control platform needs upgrading, the answer can be an incremental change, a system-wide rip and replace, or anything inbetween. Peter Welander reports.
At a recent automation supplier user group, a speaker cited an interesting statistic. He said that 50 percent of the DCS (distributed control system) platforms running process plants today are at least 20 years old. Knowing that, it isn’t hard to understand why control system upgrades are on many peoples’ minds as companies face growing cost and competitive pressures.
Should you be looking at replacing your control system simply because it’s in the half that’s more than 20 years old? Not necessarily, any more than you might want to think about trading in your 1987 car. Your aging DCS may regulate your process perfectly well, but like an old car, it can become maintenanceintensive and certainly lacks some of the capabilities of newer designs. Even if you decide those new capabilities aren’t all that important, eventually parts become harder to find, and keeping the system going gets costly.
While age-related problems are certainly a compelling argument for upgrading a system, functionality issues can also enter into the discussion. Even newer systems may not have some of thefunctions that could create value for your business.
Obsolescence & functionality
The first and most powerful driver that pushes change is obsolescence. When a platform is failing and the original provider no longer supports it, the risks of leaving it in place become too high. Obtaining replacement hardware eventually becomes problematic, leaving users to depend on parts recyclers and eBay. If part of a system goes down and there are no replacements, a whole process unit can grind to a halt.
Still, some plant managers have to learn the hard way. “It’s very difficult to build a business case based only on obsolescence,” says Mike Vernak of Rockwell Automation’s legacy DCS migration program. “Plant managers tell their plant engineers all the time, ‘If your system’s working and we’re not experiencing any downtime, I can’t justify a capital expenditure based on obsolescence.’ Of course, if you are experiencing downtime, the ROI is easy to calculate. But it’s hard to calculate it based on no downtime.”
While unreliable performance is the most obvious problem, moving toward obsolescence can have more subtle effects, including knowledge erosion. “Companies are finding it difficult to maintain technical expertise for these 20- or 25-year-old legacy systems,” Vernak adds. “The OEMs especially don’t have expertise, either because of attrition or retirements. Kids coming out of colleges today that are 22 or 24 years old have absolutely no idea about that technology. I hear things like, ‘That system is older than I am. They didn’t teach me this in college.’ They don’t have a clue how to work on it.
“It’s also expensive to maintain for training. I’ve seen companies that have multiple disparate DCS and PLC systems in a single plant. I can’t imagine how much cost that must be every year for the plant manager to maintain multiple folks for multiple control systems.”
The second driver that pulls change is functionality. A platform does not have to be all that old to lack specific functions that might be very helpful. For example, a system that does not have the I/O capability to handle Hart diagnostics will probably not be able to support an asset management program. Others may not have the connectivity to support growing integration with enterprise level systems.
John Murray, ABB Global Business Development Manager for control systems evolution, says his group did a survey on what motivates companies to upgradecontrol platforms.
“It surprised us that a very significant number, over 50 percent, said improving operator performance or maintenance practices were reasons that they were considering upgrades. We see that a lot today, as people recognize that’s where they have to get the step improvement in their business. The term is overused but it’s really about operational excellence.
“Solutions like asset management, information management, and data mining can really give you a competitive advantage if used properly. What we call a traditional control system has to be enhanced with these capabilities,” he says.
Mike Vernak agrees with that assessment and adds: “Most customers are migrating not because of obsolescence, but because of lack of performance from their systems. It doesn’t necessarily mean it isn’t controlling the process. It means that they aren’t able to get data that they need out of the system to be able to make better decisions.
“Because of the proprietary nature of the system, it’s hard to get data out or to be selective with the data they can get. These systems do not interface well with modern IT systems, with modern historians, etc. Many aren’t capable of connecting to expert systems that allow them to do advanced process control easily or cost effectively. It’s a lack of functionality.”
Older systems were designed to function in greater isolation, so cyber security is often rudimentary or non-existent. “A lot of people think, wrongly, that legacy systems are safe because they’re legacy systems,” says Ken Keiser, Siemens’ migration marketing manager.
“When it was first installed, that system might have been completely isolated. But as time goes on, maybe someone put in a modem line somewhere, or a link to an intermediate historian and that historian happens to be on the Internet where they didn’t think about the intermediate connection. You never know how somethingis connected after a 20-year period of time.”
Making the case
The first step in any upgrade project is figuring out what you need, in as specific terms as possible. Some answers may be very obvious but others that are equally important may require some probing. One of the downsides of remaining with an old system is that you don’t realize how technology has progressed. The result is that you may not think to ask for some types of functions because you don’t know that they are even available.
“Everybody wants to improve profit,” says ABB’s Murray. “But you have to work with customers to determine how they want to achieve that. The better a customer understands what problem he wants to solve, very specifically, we will come up with a much better solution.
“Whether it’s a new feature, new capability, or just adding controllers to provide better availability, once they understand that, they get a real sense of what those improvements are going to be. Then they can quantify that financially in terms of benefits they’ll derive or cost reductions, and that helps the cost justification process.
“If you have some grandiose target or scheme, then you’re really scratching for ‘how do I justify these expenditures?’ It’s important to drill down into the details for everybody’s sake to understand the problem and get the best solution.”
No plan is complete without a financial justification. Some situations will be very clear and direct. Replacing an old system that is waiting to fail and cannot be repaired should not be difficult to sell to management, particularly if its failure will halt production.
The difficult part may be convincing those responsible that the failure could be imminent. More subtle changes can be challenging. Your ability to place a value on an upgrade that adds some new functionality could depend on the extent to which you are personally convinced.
Marjorie Ochsner, Senior Product Manager, DCS platform migrations, for Honeywell Process Solutions, offers some useful questions to ask yourself early in the process:
• What’s your cost of doing nothing, and what are the expected benefits of doing the migration?
• How much is that unplanned shutdown costing you? • What is your actual cost of maintenance for this older system?
• How much are you paying for that replacement hardware at the parts recycler or eBay?
• What is the cost of inadequate response?
Then there’s the positive side: What are the added benefits of a new system? What’s the value of renewed operator effectiveness? Are there advanced control strategies that you can bring in? What is the value of bringing in those Hart signals from the field? “We look at the answers to those questions and have a very detailed analysisthat we help our customers with,” says Ochsner.
How drastic a change?
Control platform upgrades can range from small incremental changes to full rip-and-replace projects. Typically, the older the system, the more drastic the change. Older platforms were more integrated and not designed with open architecture which makes changing one part of the system more difficult. More modern approaches tend to be modular, allowing for evolutionary improvements. Frequently, companies begin with the HMI, and it’s more than just about graphics. The HMI is the main connection point for the data pipeline, providing an interface to higher level systems and amechanism for more advanced control strategies.
“The HMI is the component in a DCS that is made obsolete first, due to internal or external forces,” says Siemens’ Keiser. “When customers approach us, they are coming because they have a specific problem with the control system. It may be a problem in the controller, but more likely it is a problem viewing the data in the controller, so it’s really an HMI problem.”
Keiser says an HMI is not all that difficult or expensive to replace, so it’s a relatively easy migration to make for a first step. “You have a new look and feel, but the same exact equipment beneath it. As far as the process is concerned, it has not changed, the process control has not changed, so all of that equipment, knowledge and know-how is the same,” he says.
In some cases, a migration may involve a newer system from the same supplier, assuming that company still exists in a recognizable form. Other times it may be a more drastic change, moving to a completely different platform. A full change is traumatic in many respects, and companies should not take it lightly.
“When you get to the point that a system can’t meet your business needs, a more radical solution may be the only answer,” says Mark Bitto of ABB. “But even there, you should still look at what kind of investments you can protect. Can I leave the wiring in place? Can I leave the terminations in place? What costs can I eliminate best through whatever solution I have?”
“There has to be a very critical reason why customers don’t want to proceed down an incremental migration path,” says Keiser. “They’re saying, ‘We’re done with this vendor. We need to see what’s out there.’ In one case I can think of, the customer was considering a stepwise migration, but the more they looked at, they realized they had to take the big step. Smaller companies are more likely to do that. Some huge chemical company might not, preferring a lower-risk approach.”
Still, the extent of a change may be limited by production requirements for a plant. Full rip-and-replace projects invariably involve some downtime, whether it’s planned or not. A more incremental change can reduce this risk.
“Shutting down a process is often more expensive than keeping it going while you’re doing the upgrade,” Honeywell’s Ochsner suggests. “So most of the time owners do it incrementally on a unit-by-unit or controller-by-controller basis, laying the foundation with the networking and everything else so that they make a fairly smooth cut-over.
“It helps to do things from the top of the architecture on down, replacing the HMI first, then the networking, then the controllers,”she adds.
Executing right
Once you have decided to proceed down a specific path, it’s time to lay out the details. “The first step is always planning,” advises Oschsner. “You’ve got to know what you have, upfront.”
The first thing Honeywell looks at is the state of documentation, “which, sadly, is not usually in the greatest shape,” says Oschsner. “We want accurate and complete documentation upfront, even to the point of knowing what model numbers of controllers and I/O you have in the field.”
Graham Bennett, migration consultant for Invensys Process Systems has been involved with many projects and offers his suggestion for sharing responsibilities with the customer.
“We compile a work activities breakdown as a standard procedure,” Bennett says. “It lists pre-migration, migration, and post-migration items. We have action items that leave no stone unturned. Everybody has items and we follow it to the letter. One of the things is to confirm functionality of any third-party protocol.”
The ultimate benefits of a well-thought-out and well-executed upgrade project can be huge. Improvements of control capabilities, data mining, operator interface, feedstock utilization, product quality, and many other areas are all possible. But all of them depend on an intimate knowledge of your process, combined witheffective analysis and planning.
--------------------------------------------------------
From Five to One
The challenge at this plant: migrate five different control systems to a single platform.
Teck Cominco is a large mining, metals, and chemical company based in Vancouver, Canada. Its Trail facility in central British Columbia, includes one of the world’s largest fully integrated zinc and lead smelting and refining complexes, including the Waneta hydroelectric dam and transmission system. Trail’s metallurgical operations produce refined zinc and lead along with a variety of specialty metals, chemicals, and fertilizer products. The Waneta dam provides power for the facility, local customers, and the U.S.
Rob Zwick, Superintendent of Process Control, has been involved in an effort to move the entire facility to one common platform. As he describes it, “We have five major plants. We ended up with five platforms: ABB, Fisher Provox, Honeywell TDC 2000, Foxboro, and a PLC/Wonderware. One of the things we’ve been working toward is consolidating on Foxboro [I/A Series control system from Invensys Process Systems] as a common platform as best we can.
“We have migrated away from the Honeywell. We’re migrating away from the Fisher Provox, and by the end of this year, the Foxboro system will handle about 75 percent of our I/O,” Zwick says. “All our plants are coming to an identicalplatform with Foxboro hardware and software.”
Making the decision
Maintenance and training problems were a major driver toward convergence. Parts availability for the oldest platforms had been pushing a change, as the company cannot risk unscheduled downtime. The pressure to maintain uninterrupted production has not made the migration efforts any easier. “We’re on our fourth migration now,” Zwick notes.
“Our operations certainly run 24/7, and all the plants are inextricably linked, so we have to coordinate shutdowns between plants very carefully. We do have regular maintenance shutdowns for a couple hours here or there on a monthly basis, and we look for those to do the migration.”
All companies have been working at improving and modernizing their hardware and software, Zwick says. “Foxboro has a good installed base with mining and metals in Canada,whereas others don’t. Others have done better in oil and gas. It strikes me that differences are more historical than anyadvantages of features in a particular industry sector.”
Legacy connections
One of the things that has helped facilitate the changeovers has been special Foxboro I/O cards that provide an interface between the old and new system. Graham Bennett, migration consultant for Invensys Process Systems describes the approach:
“We retain all the field wiring up to and including the marshalling cabinets, and then the interface cabling between the marshalling cabinets and the actual I/O of the legacy vendor. We take the connection off and replace the card onefor- one using a new card made to the form factor of the legacy vendor,” he says.
“Having the one-for-one lineup, there isn’t any configuration change needed, and every point on the I/O from the field lines up with the original card layout,” Bennett adds.
Zwick is getting ready for his next major move. “It’s a big one,” he says. “We’ll have a 12-hour window, but it’s 4,000 I/O points, so we’ll need all of it. Downtime on this plant isUS$100,000 per hour,” he says.
--------------------------------------------------------
--------------------------------------------------------
‘We have migrated all makes of DCS systems’
Migration projects form a key part of Yokogawa’s efforts to expand market share,Kersi Aspar, Executive Vice President, tells CE Asia.
Q: How significant are migration projects to Yokogawa’s business?
A: Being the market leader for DCS, for Yokogawa, migration constitutes an important portion of our business as we continue to expand our market share. For us, such migration spans across almost all the vertical industries and such initiatives are justified by customers who realize the critical importance of long term lifecycle support with strong commitment to go the extra mile, which we often term as being “Vigilant” to protect customers’ interests.
It is worth noting that Yokogawa introduced the very first DCS, called Centum, in 1975, and in February 2008, we launched the eighth generation, Centum VP, which will become the flagship platform for the VigilantPlant Operational Excellence initiative. This year, we also have been recognized by Frost & Sullivan, through a number of awards, as the clear market leader for DCS across the Asia Pacific region.
Q: To what extent do these migrations replace other vendor systems versus replacing legacy Yokogawa systems?
A: Our policy has always been upward migration, including our very first DCS system, to ensure satisfactory return on investment for our customers. In addition, our core strengths such as quality, reliability and customer commitment have triggered many non-Yokogawa customers to switch to our DCS to enjoy peace of mind.
Over the years, we have migrated all makes of DCS systems, especially in major refineries, petrochemical, chemical, power, pharmaceuticals and paper industries. Some of our customers, who have learnt about our successes, have selected Yokogawa as the preferred partner in migration to ensure smooth cut-over with minimal risks.
Q: How easy is it to migrate a competitor’s DCS to Yokogawa DCS?
A: The notion that the effectiveness of migration depends on the amount of reusable components from the existing systems is incorrect. Frankly, this should be the least consideration as most customers look to the bigger picture as their main worry is to hand over a plant to operations with exactly the same or better operational functions but, more importantly, with no new restrictions.
Based on our experience, effective migration lies in understanding existing system configurations, control strategies and customer culture, which paves the way for effective planning of all activities, including the right resources that customers can rely upon. Many of the customer commendations that we received after smooth migration of non-Yokogawa systems are testimony to the efforts involved.
Q: Does Yokogawa offer any particular expertise to users looking to migrate systems?
A: Increasingly, customers are looking to ensure plant uptime and full avoidance of any unplanned incident. The first and foremost step in this direction is to select the right partner who has a track record of smooth migration in several mega plants.
Our commitment is to ensure that our customers’ investments are protected, and we help them manage obsolescence with long-term support and multi-generation compatibility. Our DCS users are assured of system compatibility with a smooth and flexible migration path.
Yokogawa brings to users proven on-site experience and methodology for migration of large scale and critical processes. Our migration approach is always focused on helping customers make improvement in plant reliability, performance, safety and productivity.
Other critical success factors for successful migration include planning, teamwork, and a risk management plan. The engagement of various departments within the customer organization also goes a long way in ensuring smooth migrationand on-time handover.
--------------------------------------------------------
