Unlike other PI interfaces, the Batch Framework Interfaces do not use buffering. If the interface loses connection to the PI Data Archive, the interface continues collecting data and stores it in its local cache. The PI Batch Database is primary-only so it did not make sense to fan data to other PI Collective members. However, this is no longer a consideration if Event Frames are being written. There should be an officially tested and supported way to fan tag data to a PI Collective.

Batch Framework Interfaces currently do not support two byte languages. Please add support of two byte languages to batch interfaces.

When my EFGen Active Point tags have a type of digital, the interface should allow certain digital states to be designated as a Zeroth State.

When my EFGen Active Point tags have a null value, the interface should be able to designate this as a Zeroth State.

Batch Framework Interfaces - [TIME] and [TIMESTAMP] placeholders should consider whether TS=LCL is configured (meaning the interface is processing incoming events as Local Time). Currently, values of these placeholders always show up as GMT timestamps.

Werum has recently released the next version of their PAS|X Database, and it bolsters a new method of Data Access. OSIsoft will need to release an re-tooled version of their PI Interface for Werum PAS|X to support this latest Werum version and the new data access method.

Rockwell FactoryTalk Batch v12.01 allows to output batch data to a SQL database as well as EVT files. Just like with EMDVB, the PI Interface for FTBatch should be able to use both data sources.

Up to PI EFGen 4.0, we were able to backfill OOO Event Frames by simply inputting the start and end time of the corresponding period. Since 4.1, this must be done in a per-event basis, since larger time ranges are modified so that RST matches the start of the latest active event and OOO EFs are missed.

Allow EFGen to use a Mix of PITAG + Text for the Creation of event frame names . Concatenate a Text + PITAG for example

Currently, Batch Interface Framework interfaces implement tag template triggers that can trigger whenever a placeholder has any value. These interfaces should also support triggering when a placeholder does not have a value. For example, our SISBatch data source has separate columns for Operation and Phase information. We would like to record the value of the [DESCRIPT] column in a tag only for non-phase batch events (i.e. trigger the tag template only when the [PHASE] placeholder is blank).

We are in need of a PI Batch/AF Events Interface to store data from Honeywell Experion Batch or Honeywell Procedure Analyst into PI Asset Framework.

ABB 800xA offers a batch capture mode that is more flexible than ISA88 since it doesn't match all unit procedures to units, but rather acquires them at the beginning of the batch. Currently the interface is designed to only retrieve batches that follow the ISA88 model.

Batch interfaces should follow a similar approach to UniInt based interfaces to retrieve the diagnostic tags. That is to say they should pull the diagnostic tags based on the PointSource, Location1, and ExDesc, not a hardcoded name based purely on EXE name and Location1. This would allow the PI admin to name tags to their organization's naming convention and also avoid naming conflicts between interface instances of the same type running on another interface node.

Add a feature that performs a verification check of the data in PI against data in the DeltaV Historian and provide a report of any missing or mismatched data.

Add support for workgroups for PI Interface for Emerson DeltaV Syncade

The MAXSTOPTIME parameter for batch interfaces does not kill the interface process when the limit is exceeded, however the parameter does work for UniInt based interfaces. Please fix the batch interfaces so that the interface process is killed once the MAXSTOPTIME has elapsed.

Batch interfaces should write their messages to the message logs using the Source1 and Source2 fields just like UniInt based interfaces. Currently, batch interfaces leave these 2 fields blank. Source1 should contain the process name or similar and Source2 should contain a string in the format of "<PointSource> | <Location1/ID> | <FailoverID>". Having this will greatly help PI administrators filter the logs based on point source, especially when there are 20+ interfaces running on a server.