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.
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.