Historian Support and Meter Unit Operations

V4 offers native support for reading and writing data against process historians, providing an easy way of bringing time-stamped data into a case. This mechanism supersedes use of user variables in V3 cases to achieve the same end. We have made these data mechanisms readily accessible from the toolbar and appropriate menus, making bringing in new process data simple.

We have dropped support within meters for multiple datasets, since your feedback was that this only confused. Instead V4 includes a set of methods for importing and exporting all meter data in the case, allowing you to archive information to the Petro-SIM database or XML files.

Stream meters can be linked to a second meter that acts as a reference for property values. Typically this will be used with recycle streams, where the recycle meter will have its own Flow, T and P tags/properties but share the laboratory information from a product meter. Meters holding links to other meters let you view the composite set of properties. The composite set of properties is available to operations like Plant To Crude that explicitly link to meters.

V4 formalizes the mechanism for plugging in new historian links, providing a formal API for this purpose. As part of this, Petro-SIM V4 is a native OPC Client, capable of directly connecting to OPC-HDA servers.

Sharing data between cases

We have extended the techniques available for sharing data between cases to make it easier for you to maintain consistency as calibrations and their associated target and operating data change. The new techniques build on the V3 synchronization mechanism that makes use of the Petro-SIM Database: this automated the data exchange and automated detecting when things had changed.

The functionality is collected together as Data Management tools that let you:

  • Read/write any case data to the Petro-SIM database
  • Read/write any case data to an XML file

In both methods you choose the objects that participate in the data exchange. With the database exchange, data is written to a collection on the database identified by case name and timestamp. You can write each set of data to a new collection or add data as new revisions to existing collections.

For example, suppose you have a refinery wide model that uses FCC and Hydrotreater reactors and you also have detailed unit models of each of these complexes. You need to keep the unit models consistent with the refinery-wide model and you will have set up calibration within the unit models but not included it in the refinery-wide model.

In this scenario, you start out by calibrating the FCC unit model, including the fractionation system. You want to have the refinery-wide model use the same data. To do this you:

  • Export the FCC and Main Fractionator data from the FCC unit model to the database
  • Import the data to the refinery-wide model, filtering it so you load only the calibration factors.

For those familiar with the V3 calibration method, this is equivalent to calibrating the FCC in the standalone model and exporting its factors to a Petro-SIM case. The differences here are that:

  • You can include the fractionation system in the calibration scope
  • The import and export steps are separate, meaning you export once to the database and then import the data into as many cases as necessary

Using revisions, you can re-calibrate the reaction system and save the new data as a new revision on the database.

Using XML files instead of the database

You can read and write files to disk instead of using the Petro-SIM database. Files are saved in an XML format that mirrors the information written to the database, and are saved by default in the User Support Files folder. The revision mechanism is not available with the XML file, meaning that each data set you export is saved as a new file on disk.

What gets imported

Each object included in an export always writes all its data. You decide how much of it you want on import, making your selection by checking the filter options presented to you. These categorize data as:

  • design data: parameters that affect unit configuration
  • calibration factors
  • target data
  • operating data

Advantages and Disadvantages of the various techniques

  • XML-based data exchange
+ Portable mechanism allowing data to be emailed around or saved to a central location for sharing
- Will generate more files that have to be kept track of
– No automatic change notification
  • Database-based data exchange
+ Simplifies sharing by keeping data in one location
+ Supports change tracking by revisions
+ Data import can pull data from full cases saved on the database as well as from object datasets
– Requires use of the database which may be problematic for distributed teams
– No automatic change notification
  • Database Sync mechanism
+ Simplifies sharing by keeping data in one location
+ Provides automatic change notification, alerting users of a case when linked data has changed – for example, when a new assay is available or a new calibration
– Requires use of database which may be problematic for distributed teams
– Best suited to refinery use: requires more forethought when setting up