Don’t shackle yourself to the wrong platform

March 14, 2007
Today, process data are readily available at many levels, from instrumentation to higher-level data historians and OPC servers. Choosing the right platform can be key to successfully implementing robust and maintainable process calculations at your company.

Process calculations can separate you from your competition, giving you insight into your process and an extra edge. Unfortunately, many companies don’t successfully implement process calculations because of poor selection of the platform or fear of the costs associated with development and maintenance of the new software.

Today, process data are readily available at many levels, from instrumentation to higher-level data historians and OPC servers. While each may offer the capability to create process calculations, there are advantages and disadvantages that should be considered. Choosing the right platform can be key to successfully implementing robust and maintainable process calculations at your company.

What are process calculations?

Process calculations are a set of user-developed rules and logic, a blend of real-time and historical process data providing real-time or historical summary values. These distilled statistics furnish vital insight into equipment performance, process economics, environmental or regulatory compliance, quality or any other factors affecting the bottom line.

Examples of process calculations include fermentation rate and efficiency, analyzer performance, equipment utilization, stack emission rates, and optimizations. The purpose of each calculation is to generate information that isn’t directly available from the raw measurement values. Ideally, the calculation results are written back to the underlying system where they are available to users along with the raw measurements. Existing tools typically applied to analyze and monitor raw measurement can then be used to analyze the calculation results.

Platform choices

With the proliferation of networks and networked devices in industry, process data are available on many different levels and platforms. Instrumentation is generally tied to a programmable logic controller (PLC) or distributed control system (DCS). A supervisory control data acquisition (SCADA) systems or process historian may provide bi-directional communication to the PLC or DCS. More recently, object linking and embedding (OLE) process control (OPC) servers may provide bi-directional communication to the PLC, DCS, SCADA system or historian. Each process data platform is a potential process calculation platform (Figure 1).

Figure 1. Potential candidates for a calculation platform are shown in a common hierarchy of a control system.

Choosing the correct process calculation platform involves careful analysis of a range of factors, including stability, functionality, maintenance, available tools and life-cycle costs.

When analyzing the various platform choices, you may want to ask the following questions:

  • Can those with the process knowledge easily implement the calculations? Many solutions require someone with a configuration access to write the logic. Often, the programmer isn’t the technical expert on the process, so there will be a knowledge transfer: from the process engineer to the programmer. These platforms will require significant development effort involving many, expensive hours of writing, testing and debugging.
  • How easy is maintenance and editing? There is more to think about beyond the initial implementation costs. Software, like hardware, must be maintained. After a successful roll-out, you may find that the calculations are commonly used across the company at many different levels. The ability for multiple people to edit and maintain the calculations may become increasingly important as jobs duties and roles change. Ease-of-implementation will result in reduced development time and a significant savings to overall cost.
  • How “open” is the solution? Am I tied to a specific vendor or piece of hardware? An open solution implies many things. At its best, the software will be vendor-neutral, utilizing data from a variety of systems and vendors (process data, relational databases) for both inputs and outputs. The platform should also have access to real-time and historical data, and support the output of results to multiple systems.
  • How flexible is the solution? Flexibility becomes important as the number and complexity of your calculations increase. You may need to be ability to run calculations at different intervals, add new equations without affecting current equations, or control the order of execution between multiple equations. You may have data in a variety of sources including proprietary databases and files. A black-box product may provide quick-and-easy setup but have limits in handling complex calculations. Therefore, it isn’t a good choice for long-term calculation solution choice. Make sure your solution is adaptive to meet your potential future requirements.


A PLC or DCS provides stable and speedy access to the instrumentation measurements in the process. It offers the ability to add programmatic input and output logic (e.g., ladder logic). The problem is that the main purpose of this logic is for control and not complex or multiple-system calculations.

The main advantage of the PLC/DCS platform is reliability and speed. The results of any logic calculations are immediately available within the control system.

Yet, there are many reasons that the PLC/DCS is not an ideal platform for process calculations. The hardware is fairly expensive and provides limited access to other systems and data. A PLC/DCS has only limited or no historical data. Typically, you can access control data from other networked controllers. However, a PLC/DCS platform may be dependent on a specific vendor or depend on a specific control network protocol; this limits the scope of calculations. From the standpoint of commissioning and maintenance, it is costly to develop and maintain complex process calculations in a PLC/DCS. The development tools require special skills and application knowledge, often requiring a PLC programmer.

The cycle for development, testing, and debugging is quite long for any significant calculation. Complex logic involving numerous inputs, multiple if/then/else branches or “looking back” to previous executions will require significant effort or may not even be possible in a reliable and supportable manner.

For example, compensating a gas flow meter for temperature and pressure becomes an exercise in simplification. Non-linear equation must be reduced to simple straight lines that can be accepted in the PLC/DCS language. At the same time, a scaling factor can become an issue between an analog value provided by field instrument and the value read by the PLC/DCS.

Unfortunately, all of this effort and cost results in a closed solution whose underlying logic isn’t widely available to others. In the end, documentation suffers. A process engineer managing the ISO-9001 will have a difficult time translating the programmer's work into training material.


SCADA systems and process historians brought data out of the PLC/DCS and into the PC world, making it easier for more people to view and interact with the process data. Various networking protocols allow you to distribute these process data across your enterprise.

What these systems lack in real-time control and speed, they make up for with ease of use, advanced tools and affordable platforms. Most of these solutions give you easy access to real and historical data through PC-based databases that communicate to the control system or PLC. Most will include a vendor-specific library or scripting language that allows users to create process calculations. They improve on the PLC/DCS calculation platform by providing a better test and debug environment, along with improved maintainability and calculation visibility, all on an affordable hardware platform.

Yet, these solutions also are fairly closed, providing easy access to the vendor’s process data database but making access to other systems possible, but difficult. Programming skills are typically required, along with knowledge of the vendor-specific scripting language or another programming language.

Although the tools are more advanced, the development cycle is similar to custom-code development. Multiple stages of development are necessary including testing, debug, and deployment. While some vendors provide smooth upgrade paths, others may require significant code updates, edits or complete rewrites when new vendor software versions are released and installed. If your solution was developed by a person who no longer works for your company, you may find yourself “version-stranded” with your calculations, searching for and hiring contractors with specific scripting or programming skills just to upgrade to the latest vendor software versions.


Numerous products let you quickly and easily retrieve process data into a spreadsheet. Unlike older tools, which required you to perform multiple steps (data extraction, file transfer, import into spreadsheet), these tools allow you to retrieve the data in one step by communicating directly from the spreadsheet to a process data database.

The main advantage of spreadsheets is that they are easily implemented and understood by a large number of people. Because they are fairly easy to implement, those people with the process knowledge are often able to develop the calculation logic. This leads to a solution that can be easily supported and isn’t necessarily dependent on a specific individual.

Yet, spreadsheets are typically a closed solution. Although they are a great tool for the creation of data tables, reports, and charts, the calculation results are usually available only within the spreadsheet; often they do not support the ability to write results back to the process system for use by other decision-makers. There is limited or no real-time component for the creation of scheduled calculations which need to run continuously, so spreadsheets are used for ad-hoc, on-demand, or infrequent execution.


OPC provides a standard mechanism for reading and writing process data in a vendor-generic manner. An OPC client communicates to an OPC server using this standard. The OPC server then translates for the PLC, SCADA or data historian. Many vendors provide OPC servers for their data, as well multiple third-party companies. As long as your data source has an OPC server, an OPC client solution is an option for your calculation platform.

To create calculations in OPC, you need one or more OPC servers for your process data, as well as an OPC client to create the calculations (Figure 2).

Figure 2. An OPC server can serve as the calculation platform for your control system.

Today, most OPC clients and servers run on a Windows operating system. The OPC client can be local or remote to the OPC server, so you have the option to run an OPC calculation solution from any computer that has network access to the OPC server(s).

The biggest advantage to an OPC-based calculation solution is vendor neutrality. An OPC client can read and write process data to multiple OPC servers (and therefore multiple vendor process databases) using a single communication specification (OPC). Not only is the solution vendor-generic, you can now create calculations that read and write data to/from multiple sources in a single, unified framework. Imagine having a single calculation solution which supports your PLCs, control system, SCADA system and process historian!

Yet, OPC may not provide the ultimate, trouble free platform you may expect. OPC adds a layer of communication between your calculation platform and the process data, adding another level of possible failure. Many vendors provide OPC servers for free or fee, mostly because their users have demanded it. There are also third-party companies that have built a business on providing OPC servers. Because OPC is only a specification, the quality of the OPC server roll-out may be problematic. Typically, stability, throughput and performance will be the largest source of an OPC calculation solution troubles.

A summary of options for choosing a calculation platform is provided in Table 1.

Table 1. Each platform offers advantages and disadvantages.


Regardless of the chosen platform, vendor or third-party tools and software will be needed. For SCADA systems, data historians and OPC, there are two typical paths that you can take:

  • custom client code using process data libraries; and
  • calculation engines.

Implementing process calculations using custom client code requires many of the same steps regardless of the chosen platform. Generally, a “programmer-level” individual writes the calculation modules and will need to develop all of the required activities: reading and writing values, scheduling, error-handling, startup and shutdown, logging, testing and debugging. As with most custom solutions, there is usually a long cycle for development and debugging while the core calculation functions are developed, and unexpected behaviors are encountered. Unfortunately, those with the process knowledge aren’t often the ones who write the custom solution. The eventual transfer of calculation logic delays development and may reduce the number of implemented calculations, ultimately limiting the possible benefit of process calculation results.

A calculation engine can overcome many of the problems with custom-written client code (Figure 3).

Figure 3. A “calculation engine” can provide ready templates to reduce the skill level required for programming.

This type of software tool is typically geared toward those with the process knowledge, putting them in an environment where they can easily and quickly create process calculations. These products range from simple graphical-based tools to more powerful scripting solutions. Because many of the required activities are common to all calculations, these “under-the hood” requirements can be separated from the calculation logic. The user can then work on the calculation logic, knowing that the other requirements are already provided in a consistent manner.

The result of this separation can be a reliable process calculation framework, and in the case of the OPC platform, a vendor-neutral solution that can be used across your organization. Not only will you shorten development time but allow a higher volume of process calculations because the ease-of-use. And, those with the process knowledge will be directly involved in preparing the calculation software.

The payoff

Intelligent process calculations can separate you from your competitors, allowing you to draw valuable information from your raw process data. Vendor claims and the wide variety of platforms that provide access to process data can cloud your decision on the best choice for a calculation platform. OPC’s strengths of vendor-neutrality and company or site-wide implementation may present an ideal calculation platform — as long as the proper development tools and quality OPC servers are selected. Compared to process calculations implemented through a traditional “programming environment,” calculation engines that present an environment in which knowledge users can easily implement calculations will foster more creativity and value.

Dane Overfield, is a product development lead engineer at Exele Information Systems in Rochester, N.Y.; e-mail him at [email protected].

Sponsored Recommendations

Heat Recovery: Turning Air Compressors into an Energy Source

More than just providing plant air, they're also a useful source of heat, energy savings, and sustainable operations.

Controls for Industrial Compressed Air Systems

Master controllers leverage the advantages of each type of compressor control and take air system operations and efficiency to new heights.

Discover Your Savings Potential with the Kaeser Toolbox

Discover your compressed air station savings potential today with our toolbox full of calculators that will help you determine how you can optimize your system!

The Art of Dryer Sizing

Read how to size compressed air dryers with these tips and simple calculations and correction factors from air system specialists.