How caching works
- Last UpdatedMay 21, 2026
- 2 minute read
- PI System
- PI System Connector 3 3.0
- Connectors
AVEVA PI System Connector 3 (PSC3) uses a tiered caching model to protect data when downstream components are unavailable or unable to keep pace with incoming data. Caching ensures that both PI data and Asset Framework (AF) objects are delivered reliably and in the correct order after normal operation resumes.
PI Data Caching
PI data, including values, point creations, and digital state sets, follows a continuous caching model
-
In-Memory Queues
Under normal conditions, incoming data is placed into in-memory queues. Separate queues are maintained for real-time and history-recovery data. As long as the destination is available and able to process messages, data is sent directly without being written to disk.
-
Transition to Disk Caching
When caching is triggered, such as when communication fails, data held in memory is drained and serialized to disk. Cached data is written to timestamp-based .dat files that preserve message order and ensure reliable recovery.
-
Background processing
A background cache-tracking task runs every five seconds to monitor cache state and attempt delivery when conditions allow.
AF Data Caching
AF data caching is stored similarly to PI data caching but incorporates the following additional safeguards:
-
AF messages are always prioritized ahead of PI data.
-
During active caching, AF background file caching is disabled to preserve message order. This guarantees AF object dependencies are maintained.
-
AF messages are consolidated and processed as logical groups rather than individual files.
Cache Flush
When the destination becomes available again, cached data is sent before any new real-time data is received. This process is referred to as flushing the cache.
Flushing follows a defined priority:
-
AF data is processed first, ensuring object definitions and structure are restored.
-
PI data is processed next, once all AF cache files have been cleared.
The connector transitions through staged recovery, moving to the final stage when fewer than 30 files remain. During this time, new caching does not occur. After all cached files are processed, the cache returns to real-time delivery.