This post was written by Roy Kok, vice president of sales and marketing at Ocean Data Systems.

These days, lack of data is not the problem, it is the visibility into that data that is challenging. But do not get caught up into thinking that the solution is advanced analytics. There is a step that is far more valuable and easy to accomplish. We are surrounded by gigabytes and terabytes of data, being dutifully archived by our human-machine interface/supervisory control and data acquisition (HMI/SCADA) systems, historians, and SQL databases. There is comfort in knowing that the data exists should you want to jump in and analyze it. And, no doubt, that is a valuable capability. But if that is your modus operandi, then you will be diving into that sea of data without a suitable context with which to view it. The ability to recognize the unusual in data requires familiarity with the data and systems generating that data. Operators develop that familiarity through their day-to-day interaction with a process. Operators have been known to step into a control room and know through the hum and buzz that the process is running as it should. That familiarity comes with time.

The second-level metrics are a bit harder to become accustomed to. Second-level metrics refers to calculations, based on primary sensor data, which are easily measured and reported. For example, HMI/SCADA calculates and displays secondary metrics for a pump such as run time, off time, cycles per day, peak torque, and motor temperature; it is up to the operator to review these results and become familiar enough with them to recognize a subtle shift or anomalous behavior. We are all well aware of retirement statistics and the workload on operators. An operator’s ability to be proactive is being diminished

Report generation is a solution to this problem—not the report generation of old, but a new class of report generation that makes the selection and presentation of data so easy that you can have any report you want with minimal effort. “Easy” report generation is changing the game. It is likely that you already have lots of experience with report generation. Your experience comes from vendor-specific solutions, designed to meet the requirements of compliance reporting (e.g., Food and Drug Administration, Environmental Protection Agency, state and federal, batch quality, or validation). Compliance reports are the ones you “must have” to accomplish the business you are in. As part of your fundamental business, they will be done at any cost. Hence, the tools do not have to be great; they just have to get the job done. That has been the level of the bar for industrial report generation. As a result, typical report generation goals have been the absolute minimum requirements.

Solutions for report generation also come from bridging business intelligence (BI) solutions, such as SAP’s Crystal Reports and Microsoft’s SQL Server Reporting Services, into industrial automation applications. This approach typically has several compromises: connectivity to data sources is limited to those with business interfaces (OLE-DB or ODBC); these solutions are not aware of automation-style metrics (OEE, set-point analysis, energy analytics, etc.); ease of use is secondary to functionality—domain experts are typically required for implementation; and a high level of information technology (IT) familiarity is required for solution rollout. These tools are very capable and are excellent for enterprise-level reporting, but BI solutions all have limitations when applied to industrial automation. So, what are the attributes of an “industrial” reporting solution?

Ease of use

“Ease of use” is a feature critical to quality (CTQ) to meet the requirements of industrial reporting. In the world of automation, ease of use also means following the paradigm of the common “tools of the trade.” The tools of the trade in automation are configurable and should not be programmer oriented. The eye is on the result, not the process. An engineer wants an HMI, the storage of data, operation of a programmable logic controller (PLC), or the definition of a report. High-level environments delivering this functionality are configurable through menus and selections in a way that any plant personnel can easily learn and apply. For many years, the focus was on the integration of programming environments, such as Microsoft’s Visual Studio or VBA, to augment a configurable solution, enabling the “yes” answer to “Can your system do that?” We are in the age of “give me the fish,” not “teach me to fish.” Again, report generators of the past have never delivered on this “ease of use” CTQ, and so they have limited the opportunity for report generation as a corporate solution for information visibility and continuous improvement. This paradigm has shifted. Purpose-built report generation for the automation industry is now easy and powerful, and report generation is ready to become a significant component of every automation environment.

Connectivity

A report solution for industry must understand industrial data sources. Users benefit most when a report can aggregate and analyze data from a variety of data sources, both business and industrial. From a product perspective, this refers to drivers that can be installed to connect the reporting engine to any source of data that exists inside or outside your plant. Data in enterprise systems, wherever they are, can be queried through business standards, such as OLE-DB or ODBC or by importing CSV or Excel files. BI tools can address only some of these requirements.

Data sources also include industry standards, such as OPC DA, OPC AE, OPC HDA, Modbus, BACnet, and proprietary interfaces to HMI, SCADA, Historian, analyzer, custody transfer, batch, and myriad vendor-specific solutions. Often, these data sources can analyze and return data in advanced ways, and performance is maximized when leveraging this functionality. For example, if you need hourly averages for a day, it is best to ask the source for that statistic rather than request a day of data (potentially tens of thousands of samples) to produce the hourly stats. Of course, if that level of analysis is required, an industrial reporting solution would package and compress remote requests of data and securely pass that data to the reporting server, performing the task as efficiently as possible.

It is also extremely valuable to recognize the different types of data in industry, for example, real-time, history, and especially alarm data. An industrial report generator understands alarms and provides the ability to intelligently query and display results based on the uniqueness of that data. Ideally, connectivity to disparate data sources will be normalized—presented in a similar way to the user—to remove any data access complexities and allow the user to focus on the task at hand: simple access to the data. BI solutions just do not address this.

Industrial metrics

The world of automation wants answers to automation questions. How many times did that pump cycle? What was the maximum and average temperature reached when the motor was running for more than 1 hour? How long did that batch take? Does that furnace meet the required Thermal Uniformity Standards? Is the building efficiency as expected for today’s weather conditions?

The answers can come from any reporting system, but will come “easily” in a system designed for this type of analysis. Ideally, these metrics can be applied to a data query, and the results will be formatted for presentation with little additional effort, because the report generator is smart, and display objects are aware of upstream statistics.

Some process reports are time based, for example, monthly, weekly, or shift reports for production, energy, or quality. However, some processes are event based, displaying irregular start and end times. The latter can be considered analytics on “batches” of data. Examples of the latter are the backwash process of a water filtration system, triggered by a filter pressure and finished at a minimal turbidity level, or any traditional batch process in the food, pharmaceutical, or chemical industries. This type of reporting can be tricky for BI tools.

Batches of data require the identification of the batch and then subsequent queries of sensor data based on the batch start and end time from automation data sources like plant historians. Batches may not be stored ahead of time. Batches may require manual identifications or can be automatically triggered through monitoring a status variable (pressure drop or turbidity) as in our previous example. Industrial report generators can also automatically name batches based on HMI/SCADA tag data or manual selections.

Formatting and presentation

Formatting data to deliver automation information is critical. All report generators offer formatting options for displaying values. But in the world of automation, values need to be displayed in a context, for example in relation to alarm limits or the display of objects that conform to specific standards.

Take, for example, the “Setpoint Analysis Report” on a thermal process and the validation that the thermal processing was a success. This sample report displays a variety of productivity features that are delivered through a set of standard analytic functions and graphic objects that are function aware: the analysis of a set of sensors, the detection of appropriate soak start and end times based on last sensor in and first sensor out, the calculations of duration and rate of changes, the final determination of pass/fail, and the resulting presentation in a “Setpoint Analysis” aware trend chart.

Of course, a reporting solution should also offer a broad range of presentation objects such as pie charts, bar charts, tables, trends, and x-y plots. But in automation, users will benefit from numeric displays, gauges with color bands, graphic images with data overlays, and performance objects.

Manual data entry

Automation data is never complete. There is always the need for some level of manual data entry, either as lab samples or operator observations. A reporting solution for automation has the ability to integrate user-friendly data collection mechanisms. These can take many forms, from automatically importing CSV or Excel data files to data entry forms in a web portal. In either case, the resulting reports will be a combination of automatically acquired data from automation and business systems and information entered manually or through bar codes and other data input methods.

Flexible delivery options

One of the most important aspects of any report generation solution is not the actual generation of the report. It is the storage and delivery of information. Here too, BI tools can come up short. The generation of information spawns the need to intelligently archive said information. This can include automatically naming directories and defining the longevity of storage, automatically purging that which is no longer needed. After archiving comes delivery. Delivery often includes automatically emailing to individuals or groups. Reports are often delivered to remote archives; FTP should be an option. Finally, reports should be easily accessible through an intranet or Internet web portal. Web portals should support all browser types (e.g., Internet Explorer, Chrome, Firefox, Safari) and both full browser and mobile browser form factors independent of operating system, (e.g., iOS, Android, Windows, or Linux). These delivery options are part of a robust, easy-to-use reporting solution designed for automation systems. Add-on technologies should not be required.

Support for vertical applications

In addition to the features for broad market appeal, report generation needs to address the requirements of vertical applications. The life sciences markets of pharmaceutical and biotechnology require a high degree of security and user authentication, version management, audit trails, and electronic signatures. These features are necessary for 21 CFR Part 11 requirements. Other markets may require high availability and the ability for report generators to support primary and backup printing devices. In even more critical circumstances, reporting solutions may be required to work in tandem, allowing one report server to automatically take over in the case of a primary report server failure.

Although BI tools can and do clearly address some of the requirements of the industrial automation marketplace, it is also clear that new purpose-built solutions will offer significant advantages across the board, and especially in vertical markets. Although the purchase price of automation-oriented reporting tools is typically higher, their overall cost of ownership will be greatly reduced due to the savings in development and customization and by leveraging the automation-oriented statistics, easy-to-use configuration environment, and reduced learning curve.

With connectivity to all automation data sources, purpose-built automation-oriented reporting and dashboard solutions can aggregate information from a wider range of sources than BI tools offer. Finally, as a configured solution with all functionality already delivered, these tools display higher reliability and a significantly reduced learning curve, letting you focus on acquiring and delivering information, not getting caught up in IT technologies and system integration.

About the Author
Roy Kok is vice president of sales and marketing for Ocean Data Systems. Prior to Ocean Data Systems, Roy worked with ARC Advisory Group, the leading research and advisory firm for industry and infrastructure. As vice president of marketing, he was responsible for marketing all ARC products and services globally. Roy has had more than 30 years of experience in industry and automation with companies including Kaye Instruments, SyTech, Nematron, Intellution, VenturCom, GE, and Kepware.

Connect with Roy:

A version of this article also was published at InTech magazine