The post How to Drive Continuous Improvement with Information first appeared on the ISA Interchange blog site.
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” 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.
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.
Click here to continue reading Roy Kok’s article at InTech magazine.
Source: ISA News