Making History

With the ability to store vast quantities of data from disparate systems, plant historians are quickly becoming a must-have for the modern manufacturing facility.

Industrial processes must be run efficiently and reliably to be able to lower overall production costs. But these processes can be substantially complex, and it is not unheard of to have an infinite number of sensors and control elements, monitoring and controlling all aspects of a multistage process within an industrial plant.

Therefore, the amount of data sent for each measurement and the frequency of these measurements can vary from one sensor to another in a system. And, for accuracy and to facilitate quick notice and response of plant events and upset conditions, these sensors should update and transmit their measurement data several times every second. That which can be measured can be controlled, but it entails that proven technologies be used, which can acquire, store, and display process data, helping enterprises to turn these data into information.

In this sense, Plant Historians are quickly becoming a minimum standard for any manufacturing facility that employs process controls. They can acquire plant or process data from virtually any type of sensor, automated control system or other source, and store an almost limitless amount of historical data, at its original resolution, at times, virtually forever.

Moreover, today’s historians offer flexibility that makes it easy to configure for any industry or function, and they can collect and store large volumes of process data for analysis and reporting by client users, business systems, and production applications.

However, the historian’s processing tools must be able to transform raw data into useful information. At the plant level, it must be able to produce status reports and operation summaries of the incoming data, associated with an industrial process, which then allows the process management and control software to respond to events, or operator instructions, by sending commands to controllers that modify operation of at least a portion of the industrial process.

This can include tailoring the process, like specifying new set-points in response to varying external conditions, detecting an inefficient or non-optimal operating condition, or impending equipment failure, and taking remedial action such as moving equipment into and out of service as required.

On the other hand, at the enterprise level, the historian must be able to collect and format the plant floor data for use in other systems such as enterprise resource planning (ERP) systems. When the plant floor process data is transformed into meaningful information, it would allow for real-time decision making, helping the enterprise to plan production and maintenance schedules, and correlate product quality to real costs. In essence, historians can connect the events on the plant floor with business issues such as order throughput, and return-on-assets.

Thus, personnel throughout the enterprise can gain unprecedented access to real-time information, helping them to make better business decisions. This can help companies enhance productivity, increase business flexibility, and streamline operations, but it is only possible when the flow of data plant-wide to the enterprise is improved.

Relationship problems
Productivity gains can be achieved by making better use of the information gathered from the manufacturing process. And providing workers at every level in the company with new insight into the manufacturing process will help them make better decisions in real time, from the plant floor production line to the enterprise level.

However, this is more easily said than done. The production environment offers unique challenges that require more than just standard capabilities to help users access and deploy data for empowering workers with information.

Traditionally, plant historians have collected and archived streams of raw data representing process, plant, and production status over the course of time. They have been developed to handle the potentially massive amounts of production information generated by specialized process control and manufacturing systems.

The historian collects these time-series data from a variety of data sources, for purposes of maintaining a record of plant performance, and for presenting, and recreating the state of a process or plant equipment, at a particular point in time. Historians are a perfect choice when data must be captured from sensors and other realtime systems because this type of repository uses manufacturing standards, such as OPC that facilitate communications. With historians, implementation can be streamlined by using standard interfaces.

However, individual pieces of data taken at single points in time are often insufficient to discern whether an industrial process is operating properly or optimally. Further processing of the raw data is necessary to render more useful information for operator decision making.

And this time-series data that describes plant and equipment behavior is very different from the transactional data found in business systems, such as the ERP, and may make it difficult to correlate plant data with business decisions. Therefore, the plant data needs to be processed in the context of business. And to do this, the time-series data of the historian requires specialized handling, transformation, and loading techniques, as well as specialized visualization and reporting tools.

At its most basic level, to achieve this, the historian can be deployed in concert with a relational database. The database is an ideal option for storing contextual information about the manufacturing processes. But by depositing the data with the historian, the relational database achieves data access efficiency and querying benefits and capability. Hence, the historian, through its relational database, integrates plant data with event, summary, production, and configuration information.

In other words, the historian acts as data repositories for manufacturing environments in which vast quantities of time-series or temporal data are acquired and stored at very high rates. The relational database, on the other hand, performs mathematical operations that aggregate and transform the acquired data from the historian into operational intelligence that can be used for decision support.

Moreover, the relational nature of the database provides a flexible architecture and the ability to integrate well with other business systems. In fact, in such a case, the historian provides a data abstraction layer between the real-time process realm and the environment of transaction-oriented business and financial systems, and offers a platform for aggregating, consolidating, and recalibrating data from various systems in the production environment.

Rules of engagement
Today, the historian has become a critical part of a processing environment. that requires reliable, 24/7 data collection, with often an equivalent time of data access. It is also an environment subject to tougher government regulations, increased industry consolidation, and tighter process monitoring. All this makes it imperative that the process data absolutely gets into the historian and that it is highly accessible.

However, this requirement has also been compounded by the expanding role of historians, which has influenced initiatives ranging from demand-driven manufacturing to plant energy management.

Incidentally, the most commonly used decision-support tool in virtually all functional areas of these disparate enterprises remains the ubiquitous spreadsheet, even with its recognized limitations as a means to integration and collaboration.

But to understand the value of integration of process data with other types of information, for things like batch report generation and in-depth analysis and optimization, requires the standardization of the architectures, configurations, and processes involved. This would also include the naming standards for tags and classes, equipment models, procedural models, and security.

In this sense, government agencies such as those involved in environmental protection take a very dim view if this standardization with regards to regulations and data custody transfer is not adhered to. These agencies exhibit very little tolerance for large or frequent periods of missing data, and if the plant is divided into multiple entities, the enterprise must ensure that the data is reliable enough to correctly indicate on what came into and out of the transfer points of these entities.

Moreover, reliable real-time access allows the analysis of trends and the action to be taken before the plant is adversely affected. Typically, thousands of process data points are monitored for deviations against plans. The process tags are checked against standard operating limits and planning targets. These are automatically recorded and any deviations detected can stay in the system for years of analysis.

But to be able to do this, three basic questions need to be answered: the sources of data or process variables that have to be monitored simultaneously; the rate of access required; and the period of time for which this accessibility should be extended.

This will then determine the architectures with regards to speed and storage, all driven by the challenge to acquire and store vast volumes of data rapidly. Historians utilize a number of storage and retrieval strategies, primary amongst which are data compression algorithms that archive scanned data only as needed.

Compression algorithms use sampled data and a user-specified tolerance or dead-band to calculate a mathematical representation of the behavior of the data. This is then projected on each scanned point, and is then used to determine which of the many scanned data points are to be archived.

Data values that fall within the predicted operating range are not stored because they can be interpolated and reproduced within acceptable tolerances. But data that falls outside the dead-band is archived and the algorithm is modified to predict the new behavior.

Too much of a good thing Traditionally, historians were used to supplement operator logs and reports. Therefore, any loss of data was merely looked up with a trip to the control room to search for the missing data. All in all, glitches in the plant historian had minimal impact on plant performance, and any unaccounted for anomalies in plant performance were compensated for in the historian.

But in today’s facilities, reliable real-time access to performance data, to analyze trend, and to automatically calculate the economic impact of process deviations, has become an important by-function of historians. In this respect, even though modern historians continue to process streaming data in the traditional manner, they now combine relationship database management features like for alarm, event and aggregated data.

Historians can accurately record all alarm data and tag values at 100,000 changes per second and, hence, help plant operators to gather and organize alarm data from across the entire plant floor.

But the clutter of multiple alarms, which can overwhelm the capacity of plant operators to assimilate and act upon them, can be minimized by the range of facilities offered by the historian. These include event analysis – the pulling up of all alarms that occurred at a given point in time; alarm and event archiving for long term analysis; alarm analysis – identifying consequential or source alarms around which other alarms are triggered; identifying nuisance and shelved alarms; and alarm setting analysis, by the state or mode of operation of the plant.

However, for effective alarm management, a clear justification for each alarm is required. If the alarm is not intended to elicit a specific operator action, then its legitimacy should be questioned. Historians enable this by comparing one set of alarm data with another set of alarm data, which however, is dependent on the query placed. The intent is to identify root or consequential alarms, but this requires that prioritization models have been correctly configured such that the consequential alarm does not get lost or remain unnoticed in the multitude of alarms.

Hence, when historians archive both alarms and plant process trends so that alarm and event data can be co-related to trend data from the plant, this can enable insights into process anomalies or areas for alarm rationalization, and even assist in incident reviews.

This can help in fine-tuning alarm settings and in linking alarm spikes to specific process conditions such as start-ups, shutdowns, change in process set points, amongst others, or changes in instrumentation or control system configurations.

Of course, precautions need to be taken, and it is important to separate plant information data requests from operationally required data systems. The prevalence of a disparate set of controls equipment instills the need to collect data from a diverse set of control systems and consolidate them into a single data store.

These distributed systems can create an environment where individual unit-level equipment maintains a local data set. This local data set can then meet the plant’s operational data needs and provide a source for history data back-up in the event of areawide system loss.

Recovery schemes
To avoid data loss or gaps, history recovery schemes can be considered. A plant historian with an appropriate real-time data interface (RDI) can recover missing history from any system on the plant floor that maintains a local data set.

This becomes essential when the historian is down for planned or unplanned reasons, and is not collecting or storing key plant data to history archives. When the historian restarts, the missing data can be obtained from the lower-level system, thus filling in the historian’s data archives from the period of non-collection.

But such recovery may require a plant-wide standard of open application programming interface to historical data, such as the OPC historical data access (HDA). If this standard is implemented, plant historian systems can recover history from any system that provides OPC HDA access. However, HDA awareness is necessary in two places: on the source system, such as an OPC HDA server, and on the RDI, such as an OPC HDA client.

In view of this, the root of data retrieval may ultimately depend on the SCADA system, which should accurately and efficiently monitor and log the plant floor information. However, SCADA trending and logging packages typically provide rudimentary repositories into which data is logged and often do not provide the means to reconcile time-based and discrete events within the same system.

But to enable the kind of granular and flexible analyses of the plant data that is typically needed to drive intelligent business decisions, these data must be easily correlated to the process events such as the start of the batch, or the trigger of the system alarms.

The problem can be overcome by using a relational database application that can log discrete and time-based events at the volume and speed necessary for production or process systems. But such a system would require software tools that easily allow users to create reports from this data and get the reports to those that need the information to make key manufacturing or business decisions. Unfortunately, the cost of the software and effort to configure this software, to create, distribute and update reports from such systems can often spin out of control.

This has prompted vendors such as Wonderware and ActiveFactory to come up with historians and, reporting and analysis tools, respectively, at a fractional cost. The suite of products from these vendors can enable an organization to log and report the data that is critical for making intelligent real-time manufacturing decisions in a true plant historian product, but for the cost of a small SCADA node.

The future of history
Regulations, business directives, or other factors may not immediately dictate consistent data collection and access. But tools that can help to effectively share data analytics, and the resulting insights that these bring in a simple, relevant, meaningful and easy-to-understand format, can help to ensure that the history of the data collected is correlated back to the multi-level and multi-disciplinary input it requires to validate it, and hence, keep it relevant to the business objectives and philosophy of the organization.

In addition, these tools can take the plant’s key performance indicators and benchmark them against industry best practice, and take the historian’s data retrieval and analysis to the next level. This would then provide the organization with the plant’s performance report cards that can directly result in improved productivity, profitability and safety.

In this sense, it is possible for historians to interface with configurable software frameworks that synchronize supply chains with financial processes, resulting in improved productivity and reduced costs. Such software configurations would allow the tracking, tracing, storage and analysis of all supply chain data, including material flow, quality, type of product and other relevant information, plus site-specific, real-time views of critical production information, that allow operators to execute and adjust production plans within the supply chain.

A basic off-shoot of this concept is the asset management software for improving predictive maintenance that analyzes fluctuations and trends, alerting operators to problems before they happen. However, the asset management systems depend on the accurate, real-time data provided by smart instruments.

In addition, the interface used by the asset management software applications is a plant historian. But even though, smart instrumentation and device standards, such as Hart, Foundation fieldbus, Profibus, and DeviceNet, specify how the device connects to the system, they do not specify how a diagnostic system connects to the asset management system.

Therefore, although the plant historian often stores the primary measurements of the smart devices, it does not typically store diagnostic information. While plant historians often organize points of data by tag number, they do not enable structuring of data in a hierarchical fashion by device, with grouping of multiple parameters of information within that device.

So, to put it simply, while a plant historian can easily obtain data from Hart and fieldbus, it does not always get the maintenance and diagnostic data. However, with the advent of open solutions, this could be a thing of the past. In such a situation, when plant historians and asset management software use a similar kind of database, all the process control or data acquisition software has to do is put maintenance and diagnostic data into the correct database in the correct format.

Plant historian systems collecting data and presenting to the operator help achieve a level of plant floor-to-customer integration, and manufacturers also get a better handle on their supply chains, which leads to multiple benefits including and the ability to match inventories with customer demands. This integrated approach helps align the financial process with the supply chain and result in more efficient productivity on the plant floor.

Figure 1

Figure 2

Figure 3