Open Systems in Process Control Are They the Answer?

Free mixing of hardware and software to solve control problems has advantages, but only when it works.Finding a single definition for the term "open system" is a thorny problem. In an open system, control engineers should be able to take appropriate control hardware (sensors, controllers, PCs, cabling, etc.

By Dick Johnson, CONTROL ENGINEERING September 1, 1999
KEY WORDS
  • Process control & instrumentation

  • Open systems

  • Networks and communication

  • Process sensing

  • System integration

Sidebars:
‘Open’ your eyes to open systems
‘Open’ solution enables China’s Three Gorges Dam Project

Free mixing of hardware and software to solve control problems has advantages, but only when it works.

Finding a single definition for the term “open system” is a thorny problem.

In an open system, control engineers should be able to take appropriate control hardware (sensors, controllers, PCs, cabling, etc.) and software (any standard platform should do) and assemble the control application required to run a process plant.

Consensus among process control suppliers came slowly, taking most of the ’90s to implement. As customers demanded open system benefits, evolution of the true open system (and its unique definition) became unstoppable.

According to the “ISA Comprehensive Dictionary of Measurement and Control,” 3rdEd., an open system is defined as one “that complies with the requirements of the OSI (open system interconnection) reference model in its communication with other open systems.” Fitting into and working within the thorns of this definition varies among the control system suppliers, however.

According to Hesh Kagan, director of development, Invensys I/A Div., The Foxboro Co. (Foxboro, Mass.), to be considered open, process automation systems should have the following features:

  • Maximum interoperability of diverse components;

  • Ease of integration of products of multiple vendors accompanied by vendor willingness to consider integration of solutions that it does not sell directly;

  • Open application program interfaces, and

  • Ease of customization and extension.

Mr. Kagan is quick to note, however, “There are never any ‘pure’ systems—over time (and sometimes very short time), a system will contain mixed versions of software and become ‘unique.’ A true open system will tolerate and support highly heterogeneous environments from mixed versions of one operating system to various operating systems and platforms. An open system requires applications to be able to communicate and interoperate in a heterogeneous environment. Additionally, applications and their databases must be able to be transported, and migrated from version to version without loss of data or function.”

Greg Noll, product manager for Siemens Energy & Automation (Alpharetta, Ga.) adds, “In the process industries, Siemens hears a lot about interoperability as it applies to control hardware and software in a multi-vendor environment. However, a truly open package must allow customers to pick and choose which products are used to automate the process seamlessly and without significant re-engineering. As long as vendors adhere to industry standards, it is possible to sew together a system with ‘interchangeable’ best-of-class products and tweak them into as complete system.”

Freedom of choice

If interoperability and interchangeability are to be part of the “open equation,” freedom of hardware choice cannot be underestimated.

Rob Lewis, vp of research and development at Control Systems International Inc. (CSI, Fairway, Kan.) states, “Open is not just defined as the ability to buy your favorite hardware from multiple vendors to get competitive prices. That’s a given. It also means that users can choose hardware from multiple hardware manufacturers. Even more than that, the logic used to control the hardware should be independent of the hardware itself. Users should be able to develop one set of logic and then use it to control hardware from different vendors. That way users are never held hostage by any one supplier or hardware manufacturer. “

Let’s talk!

Ease of component integration in an open control requires close attention to system architecture; adherence to accepted standards is key. Ability to share data seamlessly is crucial to open system operation. “Open process automation refers to system strategies that leverage accepted industry standards for communication and interconnectivity,” says Rick Dolezal, manager, process architecture, Rockwell International. “Examples of currently accepted communication systems include Ethernet, ControlNet, and FOUNDATION fieldbus: interconnection standards include OLE for Process Control (OPC), Open database connectivity (ODBC), and Dynamic Data Exchange (DDE). Process control products and systems that adhere to these standards offer the ability to more tightly integrate with other products (typically via a network), and provide easier access to and sharing of control data,” Mr. Dolezal continues.

‘Open’ is good

Control engineers who have ever had to design, specify, procure parts, install, and thoroughly test anything but the simplest control system know just how difficult and time-consuming the process can be. Will open systems give them a “leg up” on the process, especially when it is compared to simply contracting for a proprietary system that should work perfectly right out of the box?

Perhaps the greatest advantage of using open technology is that users are free to choose the best product (hardware or software) to solve a given problem without regard to supplier. Greater familiarity with products chosen has real benefits. These can, according to Jim Cahill, automation and control engineer at Fisher-Rosemount Systems (Austin, Tex.) lead to other advantages for the user including:

  • Lower product costs;

  • Lower integration costs;

  • Increase performance from rapid improving technology;

  • Lower training costs; and,

  • Lower maintenance costs.

Steve Young, director, OCS platform management for Moore Process Automation Solutions (Spring House, Pa.) adds other potential advantages. According to Mr. Young, “Openness will provide greater opportunity to integrate plant standard applications, which allows users to preserve prior investment in existing systems. It also will afford greater flexibility when adding new functionality to and/or scale up or extend an installed open system.”

According to Frank Offenbacher, manager, systems products, at Yokogawa Corp. of America (Newnan, Ga.), the overall control system design process will benefit. “Not only will users have increased options in selecting products or applications that best meet their needs, but they can now evaluate products, systems, or applications from competing vendors without spending too much time worrying about the implications of integrating a multi-vendor system,” he adds.

‘Open’ ain’t perfect

Even with all the promise of openness, there are some definite drawbacks. Complete freedom of choice implies that users be more informed on more types of hardware and software and their interaction. Jack Gregg, principal technology consultant at Honeywell IAC (Phoenix, Ariz.) puts it this way, “General lack of technology awareness and the inability to put it into use is a tremendous disadvantage for users. End-users of today must make changes of the same magnitude as going from a pneumatic panel board to a DCS. In addition, open technologies are at different levels of maturity. This can result in products from different suppliers not working well as a system.” Additionally, says Bruce Becwar, senior automation consultant at Sequencia Corp. (Phoenix, Ariz.), “Flexible and diverse integration teams must be maintained to implement projects across multiple hardware and software platforms.”

Claiming responsibility

Once installed, a significant drawback to the “open system in action” is the shift for responsibility for installing and operating a safe and reliable system. When users purchase a proprietary control system, they receive one that has been designed and tested to handle an many untold number of abnormal situations. Vendors use operating systems, applications software, and protocols they have proven to “play” well together. This is one of the major reasons that companies, especially those in environmentally dangerous or highly regulated industries, are willing to pay higher prices for a proprietary control system. They are buying proven technology, and if it does not work, the user has a single entity, the vendor, to blame.

Install an open system and responsibility falls ultimately with the end user even if an integrator is used. How many users are willing to assemble an open system with hardware, software, networks, and operating systems from various vendors and test the system to ensure alarms make it to the HMI during a process update, or test response times for real-time data during a communications burst?

As Ralph Rio, Cimplicity manager, GE Fanuc Automation (Albany, N.Y.) admits designing an open system is no small undertaking. Says Mr. Rio, “If a user is going to go ‘open,’ the system design will probably need better debugging tools.”

Bob Hausler, director, open control systems business, Control Products Div., ABB Automation Inc., (Rochester, N.Y.) put it another way. “Within the open control system itself, there would seem to be little disadvantage to open systems technology. However, end-users can sometimes get into trouble when they commission system integrators to build a control system from a number of different third-party components. While most systems now have a high degree of open connectivity via OPC and similar technologies, often the ‘erector set’ style of system can be difficult to commission and difficult to maintain, since no one manufacturer has system responsibility.”

Who’s open and why

Open systems have not burst upon the control scene with the suddenness their proponents had expected. Slow evolution of standards for open field-based architectures, communication standards, interconnection protocols, and hardware has forced end-users to take a conservative approach to specifying “open.”

In many cases, open systems have found their way into applications where control upgrades included integration into asset management systems. In most cases, increased installation and integration costs of commissioning an open system are offset by reductions in the cost of maintenance. Large campus process plants, such as chemical manufacturing and petrochemical refining have been very successful in this area.

Out-and-out better control is also a reason for going “open.” The Mobil West Refinery (Torrance, Calif.) justified automatic control on a tank farm with the installation savings that a fieldbus-based system could bring. According to senior instrument and electrical reliability engineer, Rick Shriner, “The open, interoperable DeltaV system from Fisher-Rosemount that was specified connected easily with the refinery’s existing DCS via ModBus. Mobil is looking to OPC to provide further high-speed connection to the existing system. Beyond installation savings, we are getting 60% better tank pressure control, which reduces odor emissions. Information accessibility for both managers and engineers has also improved,” Mr. Shriner adds.

The versatility of an open system can allow for “phasing in ” of new control hardware. The Yuma Desalting Plant (Yuma, Ariz.) needed a new control system , but preference was not to replace it all at once. Had the company chosen a more traditional solution, it would have had a large capital outlay up front. By going with UCOS, an open system from Control System International, Yuma Desalting was able to use existing I/O hardware, install a new control system, and then replace its aging I/O connections on a more fiscally conservative schedule.

Although open systems will never be “all things to all users,” evolution of control standards that support them is a positive development for control engineers faced with designing new applications. Even though Murphy’s law will still apply somewhere (and probably more than once) in every control project, use of open technology can help the cause. Murphy does not have to be right all the time.

‘Open’ your eyes to open systems

End-users with an eye on open systems should realize “open” might be in the eye of the beholder.

According to the ARC Advisory Group’s (Dedham, Mass.) Dick Caro, more than one class of standards can define “open,” including official, consortium, and de facto standards, laws, and licensing.

First, and probably most commonly thought of, are official standards . These standards are developed by appointed committees and evolve through written rules voted on by participating organization members before being published as an accepted “standard” in a formal written document. The process followed to establish this type of standard falls under ANSI specifications. Examples of groups that actively develop engineering/industrial standards are ISA, IEEE, and ASME.

Consortium-developed standards make up a second class of open standards. Developed by groups usually more limited in scope or geographical distribution, these may be as formally developed as official standards. Special interest groups usually produce these open specifications. Groups as specialized as the Internet Engineering Task Force, purportedly a group of friends at MIT, or the more widely known network groups such as Fieldbus Foundation, ODVA, and the DeviceNet and Profibus organizations fit into this category. Usually technology driven, this class of organization also publishes “accepted” standards in formal form.

De facto (Latin for “in fact”) standards may also be written, but are in common usage through market selection. Examples include Microsoft Windows (Win32API) and Sun Microsystem’s Java standard. They are published and available.

Laws also can establish open standards. Radio frequency standards, for instance, are established by U.S. Federal Communication Commission rules. Once established, any communications vendor that adheres to them can operate over the assigned frequency without fear of interference from other devices. As technologies such as wireless industrial and personal communication continue to expand, adherence to this open standard increases in importance.

Finally, one of the most common standards to define “open” is the licensing standard . This standard applies to technology controlled by one source and available to all under license for (usually) a small fee. IBM’s Sequential Query Language is an example of this open standard.

No matter what type standard is developed, all systems it defines must work together over a wide set of conditions no matter where they are built. According to Mr. Caro “Open defines a whole set of things that I can build that have a reasonable expectation of complete interoperability.” The key word here, he adds, is “complete,” something highly specialized or incomplete standards cannot accomplish.

‘Open’ solution enables China’s Three Gorges Dam Project

Construction of the Three Gorges Dam on the Yangtze (Chiang Jiang) River began in 1994. Scheduled to be completed by 2009, it will provide central and eastern China with nearly 85 billion kilowatt-hours, or approximately one-eighth of China’s total annual energy requirements. It is the world’s largest hydroelectric project ever undertaken. In width alone, it will be nearly six times the size of Hoover Dam.

In terms of concrete requirements, the numbers are of equally mammoth proportions. Nearly 34 million cubic yards of concrete will be used. The concrete wall will reach nearly 607 ft (185 m) high, spanning a width of 7,054 ft (2150 m).

Concrete handling requirements

Handling and placement of concrete on a project of this size is critical. Concrete placement by belt conveyors must be a continuous, coordinated process. Properly mixed concrete must be placed on the belt (charged) and moved to the point of placement (discharged) without excessive vibration and avoid of any rehandling. Furthermore, the required concrete conveyor systems must run at the correct belt speeds and have properly functioning charging hoppers, transfer devices, and belt wipers. If the system runs either too fast or too slow, the strength, slump, or air content of the concrete being carried can be affected.

Moreover, the mechanical design and control functionality must provide for discharge of the concrete over the entire placement area without significantly interrupting or delaying the concrete placement. To do otherwise, would not provide uniform placement.

This is especially true on the Three Gorges Dam Project, where the conveyor is placing concrete in wall and column forms. The amount of concrete contained in the ribbon of material on the belt is substantial compared to the amount of concrete in such forms at one time. That makes it impractical to control filling of the form by controlling the charging of concrete onto the conveyor.

Tracking the system

Although monitoring the progress of cement consolidation and finishing at the discharge level is important, overall system monitoring remains critical. Sensors, actuators, PLCs, motor control centers, human-machine interfaces (HMIs), and electronic drives all must work in concert to keep the system operating properly. Overall system requirements at the project site are being handled by an integrated control system.

Rotec Industries (Elmhurst, Ill.) won the overall system contract. In turn, Rotec entrusted control system design and manufacturing to Ruggles Control Design (RCD, Antioch, Ill.). Using the Siemens “Totally Integrated Automation” concept, RCD derived all the key elements of the control system from a single manufacturer. Totally Integrated Automation is considered an “open” control strategy because it is built around a common database and uses common hardware and software strategies. Three Gorges’ software strategy was Microsoft Windows, and the networking platform was Profibus.

Seemingly, use of almost all Siemens’ hardware seems to decry “open.” Any Profibus-compatible hardware could have been used in place of the Siemens equipment specified by China’s government.

Start and stop parameters are being met by fiber-optic cable linked motor control centers (MCCs) built by RCD using Siemens components. Each MCC has a Simatic S7-416 programmable logic controller (PLC) as the central controller combined with S7-300 Series PLCs in a supplemental role.

The units also have Siemens SAMMS electronic overload relays, trip units, Sentron SBA 800 enclosed case circuit breakers and SikuStart soft starters. Additionally, the units at the batch concrete plants all have Siemens MidiMaster vector drives for controlling the speed of a metering belt. All of the intelligent automation devices, at the batch plants and elsewhere, communicate back to the main PLCs via Profibus, providing real-time information to the operator consoles.

At the batch plant charging areas where the concrete is mixed and placed on the belt conveyor, any difference between its velocity in the direction of the belt travel and the speed of the belt must be equalized by accelerating or decelerating the concrete. The resulting turbulence actually helps re-mix the concrete. However, the action must not be so severe that concrete spills over the edges of the belt. To assure that these surges of concrete flow are leveled out, a vector drive controls the metering belt. All batch plant sites use this strategy.

All three Midi Master drives use 75-hp (56 kW) ac induction motors. The vector drive system at each metering belt station uses only one motor, plus a gearbox compared to previously used hydraulic drives. Using vector drives with a single prime mover reduced losses and resulted in greater overall efficiency.

The other attraction for using the vector drives is the accuracy for controlling the metering belt speed. Each Midi Master drive dynamically senses the motor attached to it and then stores a mathematical model. This allows the drive to make instantaneous transitions from one steady state to the next by using a stored lookup table of values. Compared to scalar systems, this means better overall transient response.

Metering belts place concrete for transport on all feeder belts that require soft starting and stopping. They are controlled by the MCCs, using the soft starters and conventional relays and contactors, sized for the motors. The motors are large because of the weight of the concrete being moved. The size range (150 to 350 hp) depends on location and grade of the area near the motor.

The metering belts are the only belts where speed control is vital. When running at top speed, the overall belt system can deliver 420 cubic meters of mass concrete per hour. Belt speed is regulated to 200 m/min.

Tying it all together

Software on Microsoft NT-based computers at the site was developed by RCD using Visual Basic. This approach was chosen over off-the-shelf software development packages that require the user to purchase specific “tags” and have limited functional libraries. Even with RCD’s in-house Visual Basic experience in developing HMIs on other projects, the task was lightened by an existing toolbox of OCX functional files and ActiveX controls that RCD personnel had developed over the last few years.

However, not content with merely reapplying existing functions and graphic elements, RCD did substantial customizing for this project. This included providing real-time video within the program to provide monitors a “birds-eye” view of all the charging and discharging operations in the system. Using this feature, supervisory personnel can toggle among areas to see what is happening, while necessary alarms, belt speeds, concrete volume readouts, and other data are also being displayed.

Michael Ruggles is president of Ruggles Control Design in Wilmot, Wis.