Distributed control systems: Four things to consider when emulating a third-party application

The capabilities of a DCS appear so limitless that we’re sometimes asked to replicate an external third-party application in the existing control system. Keep these four considerations in mind.

04/08/2014


The modern distributed control system (DCS) is extremely powerful and highly versatile. The capabilities appear so limitless that we’re sometimes asked about the option to replicate an external third-party application in the existing control system. Typical justifications include saving thousands each year in maintenance costs and product support while streamlining operator training. Though it would appear that this might be a fairly small project, there can be a lot more to consider than meets the eye, especially to someone that's not highly attuned to complex control configuration. Before signing on the dotted line, here are a few things to keep in mind.

1. Evaluate the existing third-party system

When assessing the features operators use most often in this application, don’t overlook other elements of value. Though it may be possible to match most of the functionality, what corners would need to be cut to make this work? Conversations with the end-users can highlight the things they find indispensable, and often give some ideas for improvement as well.

Operators may not be the only people using the application, though. If your control system relies on data from this third party package, emulating or re-routing this information is another issue to be addressed. Often the system you’re cloning is more than the operator interface, and even if a DCS-based version is successful in cutting out the third party’s PC on the desk, the plant may still be beholden to that company for the support of their field communication devices. If that’s the case, you wouldn’t see as much of those enticing savings that were initially suggested. Knowing how many layers are involved is crucial. If the existing system is simply a PC with a software package, the path forward will be much simpler than one that also includes field communications that may be difficult to reroute.

Essentially, as accurately as possible, consider how you would tackle this application-clone in the control system. If it’s largely a matter of fancy scripting in some new operator graphics, it will bring on a different set of challenges than a solution that relies on multiple levels of control structures (e.g., function/logic blocks, custom algorithm blocks and/or sequential controls).

2. Evaluate the DCS

Starting with a new, state-of-the-art DCS will certainly help the cause. Having the processing power to take on the extra load you may incur with the new tasks is crucial. Is this muscle car DCS connected to a fiber optic network or an older data highway? Will it be necessary to modify a lot of currently used tags or hardware to accommodate the new features?

This may not seem revelatory, but the success of this endeavor will only be as good as the weakest link. For instance, take the question above about how we'll tackle it in the DCS. If most of the legwork to mimic the application can be done with a bunch of complex scripting in the graphics, this can be good or bad. On one hand, it’s simpler to keep it all in one place, since you don't have to go rooting through a rat’s nest of tags, function blocks and custom algorithms to make changes in the future. However, that many scripts running may cripple the operator display’s performance, causing graphics to appear laggy or hurt the call up time.

Stretching the limits of the human-machine interface (HMI) with script is especially ineffective if it will be responsible for data transfer. DCS HMIs were designed to execute code to provide the operator interface functionality, and as such, are typically programmed in Visual Basic while programs running in a dedicated PC are often written in much more powerful coding languages aimed at computationally intensive functions. Data refresh rates, which can get hung up at any level between the field communications and the HMI, can also hinder the quality of the final product, if the current third-party program updates much faster than the DCS comfortably can.

The feasibility of this endeavor increases the more you can rely on your strongest link, which typically lies in control applications rather than graphics. This may seem redundant, given the previous point, but there's a subtle difference. Just as your “Achilles heel” (like limited processing power, or sometimes simply unyielding corporate configuration standards) can put the brakes on a DCS clone, some HMI were made with complex scripting in mind, and make quick work of loaded graphics. Be creative here. Try to focus your most data-intensive operation on something your DCS does very well. If the graphics processing isn't very robust, figure out how some of that burden can be unloaded to control tags or custom algorithm blocks. Make your strongest asset do the most thinking.

3. Good, fast or cheap. Pick two.

This adage has been around a long time, but may never have been so appropriate. Good programming (thus, a good program) doesn’t just materialize in a few hours, when there are often hundreds of trial and error refinements that take time. Are you looking to launch on a short timeline to save on a pricey, long-term service contract renewal with the third party, or possibly before the last piece of hardware fails? If you want to get a "good" product out in that time frame, it won't be “cheap.” It may take multiple engineers working the problem from different angles. If time isn’t a major constraint, you can probably save money on the implementation by using fewer resources. Again, this trade-off may seem obvious, but it's a worthy matter to deliberate.

4. Look to the future

Who will be supporting this new Frankenstein? It's always a desired engineering practice to be courteous to those who will be the long term caregivers for what you implement. More often than not, when playing to your DCS's strengths (as suggested with the weakest/strongest link points above), the "Keep It Simple" motto will go out the window. A complex solution is often the best way to satisfy all criteria without sacrificing functionality or performance. Whatever the case, thorough documentation is key. Don't cut this corner. The engineers supporting this in the future should be able to easily find the documentation describing what each piece of the puzzle is, why it's there, and what needs to be done if there are future expansions to the original I/O count. Further, if there's old code that was tried, but scrapped, delete it! If it doesn't satisfy a purpose, why leave it in to confuse the next person? Tie up loose ends so that whoever sits down at the computer a decade later doesn't have to play "Simon Says" with complex computer code.

With all of these speed bumps, roadblocks and milestones, is it really worth it? Well, that is the question here. There are obviously a lot of hurdles to clear, but often the benefits are worth it. If your DCS can't handle the extra weight, this probably won’t be a good move. In many cases, though, it's worth it to have one less system to train the operators on and to keep the support in-house. At the end of the day, it comes down to the complexity of the program you're cloning, the capabilities and strong suits of your control system, what level of investment (both time and money) is acceptable, and just how adept the implementer is at programming the clone. When all of these variables are weighed properly, the right decision will become apparent.

This post was written by Josh Bozeman. Josh is an Engineer II 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.



Alex , MI, United States, 05/21/14 01:50 PM:

Good topic, but Josh did not mention the safety part we at Ford using Siemens distributed safety in machining equipment and assembly. Distributed safety is a part of our controls standards (I used to write machining standards in core controls) and all OEM's must have all safety levels for Safety DCS maybe in the future this topic can be discussed. Thanks.
The Top Plant program honors outstanding manufacturing facilities in North America. View the 2015 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Strategic outsourcing delivers efficiency; Sleeve bearing clearance; Causes of water hammer; Improve air quality; Maintenance safety; GAMS preview
World-class maintenance: The three keys to success - Deploy people, process and technology; 2016 Lubrication Guide; Why hydraulic systems get hot
Your leaks start here: Take a disciplined approach with your hydraulic system; U.S. presence at Hannover Messe a rousing success
Flexible offshore fire protection; Big Data's impact on operations; Bridging the skills gap; Identifying security risks
The digital oilfield: Utilizing Big Data can yield big savings; Virtualization a real solution; Tracking SIS performance
Getting to the bottom of subsea repairs: Older pipelines need more attention, and operators need a repair strategy; OTC preview; Offshore production difficult - and crucial
Applying network redundancy; Overcoming loop tuning challenges; PID control and networks
Putting COPS into context; Designing medium-voltage electrical systems; Planning and designing resilient, efficient data centers; The nine steps of designing generator fuel systems
Package boilers; Natural gas infrared heating; Thermal treasure; Standby generation; Natural gas supports green efforts

Annual Salary Survey

Before the calendar turned, 2016 already had the makings of a pivotal year for manufacturing, and for the world.

There were the big events for the year, including the United States as Partner Country at Hannover Messe in April and the 2016 International Manufacturing Technology Show in Chicago in September. There's also the matter of the U.S. presidential elections in November, which promise to shape policy in manufacturing for years to come.

But the year started with global economic turmoil, as a slowdown in Chinese manufacturing triggered a worldwide stock hiccup that sent values plummeting. The continued plunge in world oil prices has resulted in a slowdown in exploration and, by extension, the manufacture of exploration equipment.

Read more: 2015 Salary Survey

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.
This article collection contains several articles on the vital role that compressed air plays in manufacturing plants.
This article collection contains several articles on the Industrial Internet of Things (IIoT) and how it is transforming manufacturing.
This article collection contains several articles on strategic maintenance and understanding all the parts of your plant.
click me