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 2013 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...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

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.