Skip to main content

Documentation Portal

PI EF Configuration

Aveva PI Event Frames are treated as an external data source and must be configured in the Data Source section of ConfigHub. You can either add a new data source with asset capabilities using the PI Asset Framework provider or enable asset capabilities on an existing asset data source.

Important

In Aveva PI, PI Event Frames are linked to the PI Asset Framework through the primary element property, which connects an event frame to an asset framework element. Because of this relationship, TrendMiner’s integration with PI Event Frames depends on its integration with the PI Asset Framework.

For everything to work correctly, both TrendMiner integrations for Event Frames and Asset Framework must be active and have the same configuration. If they are not aligned, TrendMiner cannot properly link a context item to its corresponding TrendMiner component, which represents the PI primary element of an event frame.

In summary, you can only use event frames from a PI Event Frame data source if the linked PI Asset Framework data source is also configured in TrendMiner for asset framework integration.

You can either:

Supported versions

To synchronize your Aveva PI event framework, TrendMiner needs to have access to the PI AF SDK. The SDK is included in the PI AF Client and the PI OLEDB Enterprise driver.

We recommend using release 2018 SP2, 2.10.5 or later of the Aveva PI AF Client or PI OLEDB Enterprise packages for compatibility. Syncing older versions is possible but won't achieve optimum performance and might lose events in specific cases as the PI API in the older versions don't support the necessary query parameters TrendMiner needs. Contact TrendMiner support (support@trendminer.com) for more information.

How does the sync work?
  • Last synced

    • Live synchronization:

      TrendMiner offers live synchronization (with a 20 second interval) of all event frames based on their last modified date. This includes both newly created and recently modified event frames, as creation also sets the last modified date.

      Each interval retrieves up to 200 event frames per page, with a maximum of 4 pages per interval (800 event frames total). If more than 800 event frames need to be processed within a single interval (e.g. due to a bulk action in PI EF), the interval is offloaded to a separate excessive sync thread to avoid delaying the next live sync cycle. Each datasource with live sync enabled gets a dedicated thread. The number of live sync threads equals the number of datasources with live sync enabled.

      The live sync can be enabled in the Context Read section of the data source.

      Enabling live synchronization will start synchronizing context items from the moment of enablement onwards. For historical data, please use a historical sync.

  • Historical synchronization

    • Start historical sync:

      TrendMiner offers a historical synchronization of all event frames whose last modified date falls within a predefined timeframe. The start and end date can be selected in the datasource detail panel.

      Historical sync uses 1 thread by default shared across all datasources, meaning only one historical sync runs at a time. Additional historical syncs will be queued and picked up once the running sync completes.

      Note

      The sync interval is based on the last modified date of event frames in the source system, not on their start or end date. This means that an event frame with a start date in 2023 will only be picked up if it was also last modified within the selected sync interval.

      If event frames are missing after a historical sync, check whether their last modified date in PI falls within the configured interval. If not, either modify the items in PI (which updates their last modified date and triggers a live sync pickup), or run a historical sync that covers the period when the items were last modified.

    • Resume historical sync:

      If the last historical sync did not complete successfully and is therefore in a FAILED or CANCELLED state this action will appear to allow the user to resume the sync manually. The sync will start back from where it left off, in contrast to "Start historical sync" which restarts the synchronization from the start date.

  • Cleanup

    There are three cleanup processes: the nightly cleanup which runs automatically every night, a manual cleanup which can be triggered on demand, and an AF synccleanup which is triggered automatically after an AF sync completes.

    All cleanup processes share the same thread pool as excessive interval sync. The number of available threads scales with the number of enabled datasources (see Excessive Interval Sync above). This means that running multiple cleanup jobs simultaneously, or a cleanup job alongside an excessive sync, will compete for the same threads.

    • Nightly cleanup:

      Every night, TrendMiner automatically checks all open context items from external datasources that have been open for more than 24 hours, meaning they have a start date but no end date. For each of these items, TrendMiner checks the source system:

      - If the item is no longer present in the source system, it is deleted in TrendMiner.

      - If the item is still present and can be updated, it is resynced.

      This process runs automatically and does not need to be triggered manually. It applies to all context-capable datasources.

    • Resync all open items (manual cleanup):

      This process checks whether open context items are still present in the source system and determines if they can be updated. The manual cleanup runs per datasource and cannot be started if a cleanup process is already running for that datasource. The progress and result are visible in the cleanup processes table on the diagnostics screen.

    • AF sync cleanup

      A cleanup process is triggered automatically after a successful AF sync or AF import. This cleanup specifically targets context items that could not be linked to their corresponding asset during a previous synchronization, these are items marked internally with a missing data reference. For each of these items, TrendMiner checks the source system:

      - If the item is no longer present in the source system, it is deleted in TrendMiner.

      - If the asset link can now be resolved, the item is updated and the missing data reference marker is removed.

      - If the asset link still cannot be resolved, the item remains marked and a retry counter is incremented. After 25 unsuccessful retries, the item is no longer picked up automatically.

      This process applies to all context items with a missing data reference, regardless of which datasource they originate from. The progress and result are visible in the cleanup processes table on the diagnostics screen.