Control system architectures: Remote control

By using fieldbus, OPC links, secure data transmission systems, appropriate software and modern server technologies, you, too, can build your own server-based architecture. That is, if you are ready for it.

Share Print Related RSS

By Rich Merritt, Senior Technical Editor

WE'VE BEEN PREDICTING it for years: Server technology is coming. Instead of having millions of dollars worth of asset management, process historian, supply chain management and other high level software in your plant, it will be centrally located, perhaps at your corporate headquarters, and reached by high speed networks.

Or you may be renting high-level software, such as loop tuning and ERP programs that are running on secure servers thousands of miles away. In other words, instead of spending $6 million for ERP software, you’ll just pay for the time you use. Siemens already makes this service available in Germany.

Soon, you may be running your HMI/SCADA systems on servers at your corporate headquarters, instead of in the plants. As server technology grows and expands, more of the non-real-time control functions will leave plants and reside in central servers. Soon, some local control systems will be a thing of the past, because remote and unmanned plants won’t need them (See Figure 1).

FIGURE 1: REMOTE CONTROL

This offshore platform for Shell Malamplaya in the Philippines can operate completely unmanned, thanks to a server-based control system architecture and a remote DCS. Source: Emerson Process Management.

As you select a new control system architecture for your latest project, keep in mind that you probably will be connecting it to a server-based system sometime soon. Make sure that whatever you buy will have hooks to the future.

Shhh…Servers are Here Already
The concept of client-server systems in a plant is not new. Server technology has been around for several years, and it has been used in process control for quite a while. What’s new is that vendors are able to put advanced control and support functions in a server computer that can be located anywhere in the world – in remote server farms, in a vendor’s regional service center, or even at an end user’s central engineering office.  Vendors just don’t like to talk about it, apparently because the whole idea of outsourcing control support functions is anathema to the user community.

I scanned about a dozen recent issues of CONTROL, examining all the ads by process control vendors, and did not find a single mention of remote server capability, even though almost all of them can do it. Why keep it a big secret?

Jim Carr, a control engineer at CH2M Hill, a consulting engineering company in Corvallis, Oregon, works on municipal water and wastewater control systems, and he tells the typical user reaction: “I have to say that most of the clients we work with would have very little interest in having any entity that was not under their direct control having any part in the high level operation of their system.”

Since this attitude is widespread, no wonder the vendors are playing down their server capabilities.

Nevertheless, the secret is getting out. Cliff Speedy, a controls engineer at C&I Engineering sums up what you probably already know or have heard rumors about: “It seems that the DCS market is in a huge state of flux,” notes Speedy. “Honeywell is in the process of migration from the old TDC3000 to the newer Experion, Yokogawa and Delta V are now emerging with quality systems that seem to be easier to configure and maintain and employ open Ethernet-based communication systems. YCA and Honeywell both are employing remote servers to perform complex control functions.”

I searched the archives of other control magazines for any stories on Shell Malampaya – the most well-known example of a remote server application (see below)— and found only a single news story, with no mention of the servers. Clearly, vendors are not promoting server technology. Maybe they think you are not ready for it.

It is important to note up front that server-based systems do not perform real-time control, safety shutdowns, process logic, or any other function that requires fast, deterministic, reliable control. Those functions will always be in the plants, under the direct control of PLCs, PCs, hybrid controllers, distributed control systems, fieldbus systems, smart valves and similar products. Server-based systems monitor, supervise, analyze, and support those real-time plant systems, but they don’t actually control the plant on a real-time basis. Not yet, anyway. 

Achitecturally Speaking
We see three basic kinds of control system architectures available today:
  • Standalone System: A standalone control system is completely self-sufficient and self-contained. Typically based on a PLC, industrial PC, hybrid PLC, or PAC (programmable automation controller), it includes I/O, a controller, an HMI, and some means of connecting its various components via a network, fieldbus, hard wiring or a bus system. Standalones are typically used to control individual unit operations, packaged systems, small processes, skid-mounted systems, etc. Although it may take direction from a higher-level system (such as a command from a supervisory system, “make batch recipe 123 today”), a standalone system carries out its task without direct supervision. A standalone system can be linked to other control elements in a plant if necessary, but if the communications are severed for some reason, the standalone system carries on by itself.
  • Distributed control system: A DCS ranges from the traditional distributed process control systems that we've been using since 1975, up to the modern process automation system (PAS) of today. A DCS consists of multiple direct control elements, HMI workstations, SCADA systems, control processors, logic processors, I/O processors, servers, process historians, and high level software packages, all linked by networks such as fieldbus or Ethernet. A DCS is truly “distributed,” with various tasks being carried out in widely dispersed devices.  In general, a DCS is often used to control large processes, and it often incorporates high-level software packages, such as asset management. Oddly enough, none of the major control system vendors that made DCSes so popular in the past call their systems DCSes any more. They are now called every euphemism in the book except DCSes when they are, in fact, even more distributed than the original DCSes of the 1970s.
  • Server-based system: In a traditional standalone control system or a DCS, as described above, all the various control and monitoring devices, networks, HMIs and other equipment are located on the plant’s premises. In a server-based system, certain non-critical parts of the control system can be located on or off the premises. While all I/O, critical controls, shutdown systems, and other real-time functions are kept in the plant, remote servers can perform all the advanced DCS-type supervisory control, SCADA, asset management, ERP, loop tuning and similar functions from afar. Such servers can be located anywhere in the world, and can be reached by secure and non-secure communication links, such as microwave, satellite, virtual private networks, the Web, dial-up modems and cell phones. Both standalones and DCSes can make use of server-based support systems.

Because the definitions of control architectures are blurring, it is getting more difficult every day to make clear distinctions. “In my conversations with users of process automation systems, there still seems to be a strong preference with traditional architectures,” says Chris Martin, manager process control for GE Fanuc Automation. “The differences in the first two options mentioned above are becoming blurred, and I believe most users are starting to think of them as one. Advantages of the traditional architectures are less reliance on PC-based operating systems, familiarity and lower overall cost with hardware redundancy.  Also, separation of I/O networks from enterprise networks is still preferred.”

Carr of CH2M Hill thinks control system architectures will use all of the above. “This includes PLCs or RTUs for field I/O and control, Windows-based PCs for HMI and all data handling functions, and standard network hardware,” he says. “All devices are connected by Ethernet LANs and WANs.  This works for everything from a small processing facility, to a campus environment, to a hydro-electric system spanning multiple dams across several states.  Bigger systems don't need bigger parts, just more of them.”

Standalone Systems
Some users believe in standalone systems. “PLCs are the best option for anything but a large-scale chemical, petrochemical or maybe some pharmaceutical plants, where a batch may cost more than $1 million,” says Speedy. “Advantages are that the control schemes, while not as mature as those of the DCS world, are very, very capable and are available at a fraction of the cost. Another huge advantage to these systems is the vast support resources available.”

"Vendors are not promoting server technology. Maybe they think you are not ready for it."

Jorge Cano, a process control engineer at MetMex Peñoles S. A. de C. V. in Torreon Coah, Mexico, disagrees. “PLC equipment loses capability when the process grows,” he says. “If you install a PLC in a process that has a certain amount of processing and data requirements, it may be OK at the beginning, but if you grow your process maybe the PLC will not be able to handle the increased processing and communication load. Therefore, a PLC may be the best solution only for equipment and process units that you're sure will not grow.”

“The only drawback I see to these systems is the lack of true redundancy, unless you are dealing with an expensive system such as Triconex,” counters Speedy. “Also, while a PLC is capable of some complex control, the programmer must be well-versed in how to configure the system.”

David Crump, marketing manager for Opto 22 says a PLC system can be expanded when needed. “Expanding a PLC-based control system without degrading performance often requires deployment of a separate micro PLC,” he says. “Expansion of the PLC-based control system can also be accomplished using various remote I/O processors, which act as slaves or ‘dumb’ I/O units to the master PLC.”

Even so, with servers on the horizon, Cano’s comments about communications limitations may be spot-on. On the other hand, many PLC-based controls have PC-based HMIs, which are certainly capable of handling advanced communications.

Speaking Up(ward)
Robert Jackson, PXI product manager for National Instruments says modern PC-based systems make it easy to talk to servers. “Often times it is difficult to integrate traditional standalone systems into a server based infrastructure, such as the IT infrastructure of a plant,” he says. “However, the latest generation of standalone processors, such as PACs, offer this integration because they are based on PC technology.  Challenges that must be overcome when connecting standalone processors to a server-based system include security, deterministic communications, and the availability of a real-time OS and supported hardware.”

Security is certainly an issue when talking to remote systems. We don’t have room to discuss cybersecurity in depth here, but suffice it to say that technology exists to provide all the security anyone needs. For example, completely isolating a control system from outside networks and only allowing an external “Shadow Server” to communicate with the world (see “What’s in Your Server?,” CONTROL, March 2004) is an excellent way to protect your system.

In today’s world, even standalone systems must deal with the enterprise, as Steve McGeorge, Manager, Product Marketing, at Honeywell Process Solutions  points out: “As customers seek to optimize their supply chain, control systems need to be connected to Enterprise systems, and the various plant floor systems themselves need to be integrated.  About 8-10 years ago, some users were attempting to craft their own architectures out of a mix of systems and components. These users have typically changed course since then, after experiencing the cost of integration, maintenance and support and general lack of ultimate functionality.”

A small DCS can fit into the standalone market. “At the smaller end of the market, where single loop and now multi-loop controllers are used on isolated process units, PLCs can run loops and are used in some situations,” notes McGeorge. “Honeywell serves this market with the HC900 integrated with Experion Vista system-level software. This configuration can be as small as a single PC and controller and be used, for example, to run a furnace.”

Standalone systems can become DCS-like by adopting some of the DCS-based  technologies, such as fieldbus, says Jonas Berge, marketing manager at SMAR. “For package units and similar systems, users don't mind a small control system, but increasingly they want package unit controls to tie in with the main control system digitally, not via hard wire,” he says. “Standard application layers for industrial Ethernet are helping to make this possible. A good example is FF-HSE [Foundation fieldbus high speed Ethernet—ed.]. Several control systems now support FF-HSE as a control network thus making such integration possible.”

Berge also believes that OPC-based systems are a good way for standalone systems to reach servers. “Users can best prepare themselves by investing in control systems that have open platforms,” he advises. “The system's software architecture should be based on OPC, rather than being proprietary with a gateway ‘application station’ to OPC. Migration from DCOM-based OPC to OPC-UA is expected to be smooth, enabling users to take advantages of web services such as server-based systems.”

Another way is to install DCS-based HMI/SCADA software in the standalone system’s PC. Software such as Wonderware’s InTouch, for example, can easily link a standalone PLC or PAS to a host of advanced IT functions typically offered by the big DCS vendors.

DCSes Understand Servers
While standalone systems must reach out to a host of suppliers to find the enterprise-level support that Honeywell’s McGeorge notes above, modern DCSes already have it. Virtually every DCS vendor supports a wide range of enterprise-level software. The vendors either have their own packages, or they have made agreements with software vendors. Most importantly to DCS users, the integration of all this software is transparent. If you need condition monitoring or a process historian, it just plugs into your existing system.

Because functions such as asset management, condition monitoring, process historians, and all the other IT-like tasks are contained in one or more separate workstations, these workstations are performing the functions of a server. They just happen to be resident in the plant, and they only “serve” one user or process.

“Many suppliers are using the client/server model for HMI,” notes Bruce Jensen, manager systems marketing for Yokogawa. “Not only does that facilitate local control, but also remote access as well.  The downside is that graphics and data are managed by single PCs.  Yokogawa uses peer-to-peer operation and monitoring operator stations which are independent, but augment with a client/server specifically for remote access.”

All a server-based DCS does is move those IT functions elsewhere, and connect to them via Ethernet, private networks, microwave or some other medium. Some services – such as condition monitoring, advanced loop tuning, and process historians— are already being “farmed out” by plants worldwide. In other words, some end users are already employing remote server technologies, in spite of their alleged resistance to letting outside entities process their data.

Server Systems at Work
We know that most major DCS vendors support server technology, and all of them are capable of providing remote servers. Four years ago (May 2001, p 31), we reported on how Siemens provides a remote server-based system for foundries in Germany, where a host of enterprise software is available on a per-use basis over the Internet. Because the foundries don’t have to buy ERP, asset management, and similar software, they save about 70% in overall costs. It also illustrates that a number of different companies – all competitors, in this case – are willing to use a common “information utility” to gain access to advanced software for minimal expense. That puts paid to the argument that user companies won’t subscribe to such a service.

Honeywell also has server systems in the field, according to McGeorge. “We have one pharmaceutical customer who has implemented a control system architecture with 12 redundant servers distributed and integrated through Honeywell's Distributed System Architecture (DSA),” he says. “Several years ago, we deployed our system in ASP style over the public Internet using VPN technology to monitor multiple utilities.  Due to the efficient communication regimes we use and open protocols, this was accomplished without any difficulty.”

Nevertheless, only two vendors supplied specific information about server systems used for control and monitoring: Wonderware/Invensys and Emerson Process Management.

Wonderware, in fact, is supplying server based systems to several companies, including the London Underground, Nutramax (Gloucester, Mass.), DMS Powders (South Africa), Kansas City Power & Light (Kansas City, Mo.), Yellow River Conservancy Commission (China) and Arla Foods (Christiansfeld, Denmark).

“Some end users are already employing remote server technologies, in spite of their alleged resistance to letting outside entities process their data.”

 
The Arla Foods installation involves using Wonderware’s ArchestrA, IndustrialSQL and its other server-based software products on the plant side with SAP’s NetWeaver ERP system on the business side. he system obtains real-time information from Arla’s widely scattered 70 dairies and processing plants, and makes the information available to company personnel in a central location. “The program calls for all of the systems within the Arla Foods organization to be integrated into a single system,” says Jorgen Greve, plant manager at the Christiansfeld Dairy Centre. “This will make it easier for our corporate headquarters to follow up on business operations on a regular basis.”

Closer to home, Kansas City Power & Light has a similar system, for similar reasons. KCP&L collects real-time data from two of its power generation plants, with their multiple power production systems, and stores it in a real-time depository. This data is then available to any authorized user, anywhere in the company, using standard web browsers. The software involved includes Wonderware’s FactorySuite, InTouch thin clients, IndustrialSQL Server, and SuiteVoyager web portal, operating with Microsoft Terminal Services.

"For the first time, we have the capability of literally monitoring performance from the plant floor data sources all the way up to management desktops, in one integrated set of applications,” says William Radford, head of operations at the La Cygne plant. The plant uses several types of control systems to manage coal handling, water treatment, boiler management, and power generation, including Bailey and Honeywell DCSes, and Allen-Bradley and Siemens PLCs.

“One of the critical elements in the development of the browser-based system was that we needed to merge data from all these control networks,” explains Bruce Kelly, information director at Sega, the systems integrator in Stillwell, Kansas, that put the system together. “In the past, this hasn’t really been possible because each is proprietary in nature. However, by using thin client applications, a real-time relational data base, PC based industrial portal software, and the Internet Explorer browser, everyone now can see data they need from any of the control systems. The system allows us to use a central server with all that software running in a centrally maintained environment.”

KCP&L first tried to implement something similar as far back as 1996. “The previous performance monitors we employed were ‘thick client’ applications,” says Tor Anderson, Sega’s manager of information technology. “The program ran on a specific machine and was only available for viewing on that machine. Now, by running it on a server and making it available via a web portal, various users can look at the same information at the same time.”

The Granddaddy of all server-based systems is probably the Shell Philippines Exploration (SPEX) Malampaya project in the Philippines. Begun in 1999 and completed in 2002, this system uses Foundation fieldbus instrumentation and an Emerson DeltaV PAS/DCS to control operations of an offshore gas platform, pipeline, and onshore gas processing plant. More than 1,600 fieldbus devices are involved. The offshore platform and the onshore PAS are linked by a wireless satellite data transmission system.

The offshore platform is of particular interest because it uses smart fieldbus devices that can continue to operate in standalone mode if the data link to the Delta V system goes down. The platform operates unmanned at night in a “lights out” operation. During the day, only 14 operators and technicians are needed. In fact, SPEX wants its operators to spend a minimum amount of time in the control room, so they can be doing tasks in the plant environment. Although it not yet doing so, extensive tests prove the feasibility of operating the platform from the onshore gas plant 24 hours a day.

“The onshore gas plant (OGP) and the platform’s PAS are connected via a satellite link, forming a wide area network to share data,” reports Ken Jones, senior instrument engineer of SPEX, in an article in World Oil, Sept. 2002. “The OGP PAS can monitor, control, and operationally manage all essential functions, offshore and onshore. In addition, the PAS supports a fully functional asset management system. This enables remote instrument calibration, diagnostics and troubleshooting of fieldbus devices.”

The standalone capability of the fieldbus devices is one key to success. “On the few occasions where failure of a non-redundant electronic card occurred, process control was not lost,” says Jones. “Control continued with direct communication between field devices.”

Servers in Your Future
The success of the projects noted above make it clear that a server architecture is coming to your plant. The economics alone will drive the transition. No longer will you have to pay millions for IT support software; instead, you’ll rent it, or you’ll set up a central engineering office where all your plants will access data from central servers. No longer will you have to update scores of workstations and PCs; instead, you will only have to update your central servers. No longer will you have to staff unsafe plants in war-torn countries, remote jungles, offshore platforms, or other hazardous locations. Instead, you can install your own Malampaya-like remote system.  Although the major vendors are driving the technology, you are not tied to their systems. As we reported (February 2005, p 81), WPS Energy Systems, an electricity and natural gas provider in Green Bay, Wisc., developed its own server-based system to monitor all its power generation and gas distribution operations nationwide over the Internet.

Several of the independent HMI/SCADA vendors, such as Iconics and Indusoft, and software vendors such as Software Toolbox have already exhibited server-based and web-based technologies at ISA shows. Such systems could be added to existing controls to gain server access.

By using fieldbus, OPC links, secure data transmission systems, appropriate software and modern server technologies, you, too, can build your own server-based architecture for your DCS or standalone control systems. That is, if you are ready for it.
Share Print Reprints Permissions

What are your comments?

You cannot post comments until you have logged in. Login Here.

Comments

No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments