Colin More is an applications engineer with global engineering, procurement and construction (EPC) company M+W Group, formerly Global Automation Partners, or GAP. M+W uses FactoryTalk Historian from Rockwell Automation, which can connect to almost any type of real-time control system via OPC servers or other connections (ODBC, Batch executive, Modbus, etc). The data gathered from FactoryTalk Historian can be accessed by standard Rockwell FacotryTalk tools such as, but not limited to, ProcessBook, Datalink, VantagePoint, and BatchView.
AW: Why use a data historian?
More: I think we should look at historians as part of the infrastructure that will not only provide the capability to investigate, report, monitor, but also as an excellent gateway to provide to advanced packages the necessary data—think manufacturing execution systems (MES), analytics software, and bridging the gap between enterprise resource planning (ERP) and plant floor systems.
A historian can be used for many purposes. A few examples are:
-
Gather data from multiple sources and store in one place (end users don’t need multiple applications to look at data from various equipment/sources)
-
Retrieve data in the context needed by the end user
-
Report on how a process has run
-
Compare the same process from two different runs to look for anomalies in process data
-
Monitor multiple process variables for a given piece of equipment to do predictive maintenance (reduce downtime by scheduling maintenance beforehand)
-
Monitor energy usage (reports can be used to flag efficiency issues with energy usage)
-
Perform calculations on data (can be viewed on a trend or in Excel).
AW: What are the main functions of historian software?
More: There are three: Acquisition of real time data, storing of real-time data and access to the data from various other applications for presentation to the end-user.
A historian can acquire different types of data from analog (floating point and integer), discrete (on/off, open/close, 0/1), string information, batch information, alarms and events. Historians need to serve a platform to link disparate, real-time data sources into a single application. The application can of course render the information in the form a trend, but historians can also provide the perfect platform to support applications that create dashboards, compare batches, create reports, and more.
A typical system that would use a historian could range from few hundred data points to hundreds of thousands of points. Historians are built to acquire massive amount of data for these systems on a real-time (in the second/millisecond range). Some historians can also collect some relational data.
AW: So historians are databases. How do they interact with other software?
More: It is important to remember that a historian application does not replace all other data collection systems and databases in a plant or enterprise. Production data, MES systems, existing batch databases, and alarm and event databases still exist and present a challenge in accessing all these data sources via a presentation application or layer.
When a plant implements a historian application, it doesn't mean that the plant no longer needs its existing Microsoft SQL Servers or Oracle servers. Instead, the historian application should gather the historical data that was previously collected into a SQL database, in our case through FactoryTalk Transaction Manager software, FactoryTalk Historian Classic software, FactoryTalk View DataLogger software or similar systems.
AW: How much and what kind of effort is put into configuring or designing the database prior to implementation?
More: Continuous data collection is pretty straight forward to design and implement. Batch data when not available directly from a Batch Execution System such as FactoryTalk Batch, need a lot of investigation and design to ensure that the batch context represents what is happening on the shop floor.
When not using a Batch Executive, the batch context is built using triggers from the control systems when available or an equation dealing with a combination of triggers. Normally when using batch triggers from the control systems (not using a batch execution system) a period of time must be allocated to make proper adjustment to the batch configuration.
Alarm and event data also needs additional design and configuration time. This type of data has many attributes (priority, description, module, etc.) that relate in order to give the end user the full message. If these are not stored in a matter that is easy to extract without breaking the attribute relationships, it is very difficult for the end user to make effective use of this data.
AW: How did you decide what data to collect, how much to save, etc.?
More: A client generally knows what data is critical to their operations, and normally any data that has an impact on quality or productivity will be collected in the historian, in a conjunction of batch data and critical alarms. A client’s system administrator (with proper training) is responsible for adding and modifying data points when needed. The amount of data to be saved in the historian will depend on the type of data logged. For example, temperature will normally be scanned at a slower rate than pressure, discrete data are stored only when a change happens.
With FactoryTalk Historian, three factors will determine the amount of data to be stored. First, the scan rate (which is normally in the second to minute range). Second, the exception is set to avoid collecting noise, so no change reported if the value did not change by at least the exception value. And, third, the compression which will allow the system to minimize the number of data points stored without losing the ability to reproduce what happen on the plant floor (with the proper resolution). This configuration should be done with the thought of not storing too much data, but still capturing the peaks and valleys of trends.
For analog tags, it is typically recommended to start by setting the exception to the tolerance of the measuring device (there is no need to collect data that is considered noise since it didn’t change more than the tolerance of the device output) and the compression to twice the exception setting. Once this is in place it is a good idea to review trends with the end users and adjust accordingly. This is a recommended method to eliminate noise and store all relevant data points.
Another method is to set the exception and compression settings based on the measurement type (temperature, pressure, etc.). This could be based on the end users resolution requirement. With this method, it is easier to administer the system but a lot of thought needs to be put into place when designing the system.
AW: How long after the historian is implemented does the data start being delivered to decision makers? What are the obstacles or accelerants?
Continuous data is available immediately after the implementation, but without the batch context history, this data is less useful. In this case, users start to use the data about one to two months after implementation. The client took two months to get used to having easy access to real-time data, which is typical in our experience.
Starting with predefined screen and reports helps reduce the time before users can benefit from the historian. Many clients will only start collecting data, but will let users build their application, which delays the time for users to benefit from the historian.
AW: What sort of ongoing maintenance or monitoring of data or deliverables (HMIs, Web dashboards, etc.) is required to keep historian data useful?
It is important to make sure the data is reliable, and make sure the interfaces are always up and running. For example, the maintenance screen with some sort of notification is very useful. More importantly however, is to educate plant workers on the importance of ongoing data monitoring.
FactoryTalk Historian has an interface called the “Interface Status Utility.” This interface can be used to monitor timestamps of watchdog tags to alert when data flow has stopped.
AW: Overall, what advice do you have for a company who's invested in a historian product but may be struggling to use it fully?
Ensure you have a good plan in place that responds to problems end users may experience. A working session with a Rockwell Automation or a systems integrator to present typical use of an historian is a good way to address and educate new users. Do not restrict the implementation to continuous data if you have a batch process, as batch context provides added value when analyzing the data.
Also, it helps to ensure that you have sound requirements for the historian when you implement. Continuous data can be displayed in any method a user chooses. Batch, alarm and event data can be stored in the historian in different methods. Depending on how it is stored it can make it easy or very difficult to view the data in context by user. This is mainly due to the fact that this type of data has many relationships where continuous data is always related to just time.
Also, take advantage of available computer-based training from client tools, and stay in touch with the group who implemented your system. Rockwell Automation provides excellent service and support for historian clients.
Another option is to contract remote support. Being able to pull resources from another company that has multiple people with remote access can be very valuable. Supporting a system remotely works well if rules are well established ahead of time.
