Synchronization scheduling

The PI APS setup kit installs the PI APS Synchronization Engine as a Windows service that automatically starts when the system starts. Normally, the Sync Engine is always running and is listed as PI APS Synchronization Engine in the Windows Services applet or as process piapsengine.exe in the Windows Task Manager. Even though the Sync Engine runs continuously, it does not continuously scan the enabled interface instances for differences between the PI points and data source tags.

Note: PI APS does not synchronize points in real time.

The Sync Engine always initiates a synchronization scan for an interface instance when interactively requested via the PI APS Configuration Utility or on the occurrence of a configured trigger event. Also, each registered interface instance has an optional synchronization schedule. When automatic scheduling is enabled, the configuration settings specify the time interval (period) between synchronization scans and the Synchronization Engine initiates a synchronization scan when the elapsed time since the interface instance was last scanned exceeds the configured interval.

The Synchronization Engine implements the scheduling of synchronization scans in its main loop, which repeats until the Synchronization Engine service is stopped by some external event. Although the Synchronization Engine is internally a multithreaded process, only one thread runs the main loop and all synchronization scans are executed by this single thread. Therefore, all synchronization activities are effectively single-threaded. As discussed in the following sections, the priority of the main loop thread is lowered to reduce local CPU and memory usage.

Conceptually, the body of the main loop:

• Updates an internal table of enabled interface instances;=

• Determines if each enabled interface instance is due for synchronization;

• Selects one due interface instance and performs a synchronization scan;

• Pauses for 10 seconds (configurable) before repeating the loop.

  Sync Engine Main Loop

The following figure contains a flowchart of the Synchronization Engine main loop.

In this figure, steps 5 and 6 of the main loop affect the responsiveness of the Synchronization Engine to external events. External events include configured trigger events, manually-initiated requests from the PI APS Configuration Utility to immediately synchronize, or a request for the PI APS Synchronization Engine service to terminate. The reason is that the Synchronization Engine spends the majority of its time in steps 5 and 6, which delays the flow of control from returning to the decision blocks that detect external events. For example, suppose that the PI APS Configuration Utility is used to request immediate synchronization for an interface instance. Step 2 checks for interface instances with pending requests for immediate synchronization, so the request is not detected or initiated until the main loop next executes step 2. If the Synchronization Engine is paused in step 6, the worst-case delay is the length of the pause. If the Synchronization Engine is actively synchronizing (in step 5), the synchronization scan must complete and the pause in step 6 must elapse before the requested immediate synchronization is initiated.

The default setting (10 seconds) for the pause in step 6 is a compromise between responsiveness to external events (like immediate synchronization requests) and reducing the frequency of searches for newly registered or unregistered interfaces in step 1. Both factors must be considered before changing the setting for the pause time. Increasing the pause time makes the Synchronization Engine less responsive to external events, but decreasing the pause time increases the CPU usage on the PI APS system and load on the PI Servers.

Step 1 in the main loop is actually a two-part process because the Synchronization Engine maintains two internal lists: one contains the PI Servers that are enabled for PI APS and the other contains the registered interface instances that are enabled for synchronization and have points on those PI Servers. First, the Synchronization Engine reads the stored configuration settings and obtains a fresh list of the PI Servers that are enabled for PI APS. The Synchronization Engine compares the fresh list to the internal list and adds or deletes entries in the internal list as necessary to make it match the fresh list. Second, the Synchronization Engine searches the Module Databases on the enabled PI Servers for registered interface instances and adds or deletes entries as necessary to make the internal list consistent with the currently enabled set of registered interface instances. If the Synchronization Engine loses connection to an enabled PI Server, any interface instances for the PI Server are deleted from the internal list. When connection to the PI Server is restored, the Synchronization Engine adds new entries for the enabled interface instances to the internal list.

Steps 2, 3, and 4 determine which interface instances, if any, are due for synchronization at the current time because:

• The SyncImmediately flag is set (step 2);

• Automatic scheduling is enabled and the interface instance has never been synchronized (step 3); or,

• Automatic scheduling is enabled and the current time is chronologically greater than the last synchronization time plus the configured period (step 4).

The Synchronization Engine prioritizes these criteria in the order listed. That is, any interface instances with the SyncImmediately flag set have priority over other interface instances. If no interface instances have the SyncImmediately flag set, automatically scheduled interface instances that have never been synchronized have priority over interface instances that have exceeded the configured interval since last synchronization.

The PI APS Configuration Utility sets the SyncImmediately flag for an interface instance in response to clicking the SyncNow button on the toolbar. The PI APS Synchronization Trigger service monitors for configured trigger events and sets the SyncImmediately flag when a trigger event occurs. These events have highest priority for synchronization. If the SyncImmediately flag is set on more than one interface instance, the first one that the Synchronization Engine finds is selected for the next synchronization scan.

The intention of step 3 is to immediately synchronize an interface instance that is configured for automatic scheduling at the time it is enabled. The Synchronization Engine stores information that it needs to perform automatic scheduling in its internal list entry for each enabled interface instance. When an interface instance changes from disabled to enabled state, the Synchronization Engine adds a new entry to its internal list. The scheduling information in the new entry is initialized to a never synchronized state. Note that initialization to never synchronized occurs every time the Synchronization Engine adds a new entry to its internal list, not just the first time an interface instance changes from disable to enabled state. Therefore, the condition in step 3 is more accurately stated as "any interface instance that is automatically scheduled and has never been synchronized since being added to the internal list."

If an interface instance is configured for automatic scheduling at the time it is enabled, it immediately satisfies the condition in step 3, which makes it a candidate for the next synchronization scan. This is the typical sequence of events that step 3 is designed to detect. Another sequence can also cause an interface instance to satisfy the condition in step 3. If an interface instance is not configured for automatic scheduling at the time it is enabled, it does not satisfy the condition in step 3. If the scheduling setting is reconfigured to automatic before a synchronization scan occurs for the interface instance, the interface then satisfies the condition in step 3. Thus, reconfiguring an interface instance to automatic scheduling can also make the interface instance a candidate for the next synchronization scan.

The condition in step 3 is satisfied in another significant case: when the Synchronization Engine starts. At startup, the internal table of enabled interface instances in the Synchronization Engine is empty. Consequently, the first iteration of step 1 in the Synchronization Engine main loop adds a new entry to the internal table for each enabled interface instance. As before, the scheduling information in each new entry is initialized to a never synchronized state. So, interface instances configured for automatic scheduling immediately satisfy the condition in step 3 and are candidates for the next synchronization scan. As a result, every enabled interface instance with automatic scheduling is synchronized when the Synchronization Engine starts.

If more than one interface instance satisfies the condition in step 3, the Synchronization Engine selects one for the next synchronization scan. So many factors influence this choice that, for practical purposes, the interface instance selected for the next synchronization scan cannot be predicted. However, after the first synchronization of the selected interface, it no longer satisfies the condition in step 3. On the next iteration of the Synchronization Engine main loop, another interface instance that satisfies the condition in step 3 is selected for the next synchronization scan. The only guarantee is that this cycle repeats until all automatically scheduled interface instances are synchronized once.

The condition in step 4 identifies the automatically-scheduled interface instances that are due for synchronization because the elapsed time since the last synchronization exceeds the scheduling period. When the Synchronization Engine performs a synchronization scan for an interface instance, the time is stored in the internal table of enabled interface instances. When evaluating the condition in step 4 for each automatically-scheduled interface instance, the configured period is added to the last synchronization time to determine the time when the next synchronization should occur. If the calculated next synchronization time is chronologically earlier than the current time, the interface instance is due for synchronization. If more than one interface instance satisfies the condition in step 4, the interface instance with the earliest next synchronization time is selected for the next synchronization scan. That is, the interface instance that is most overdue for synchronization is selected.

Regardless of the condition that caused the last synchronization scan (step 5) for an interface instance, the Synchronization Engine stores the time that it occurred in the internal table. In particular, a manually-initiated or event-triggered synchronization scan also resets the recorded last synchronization time. After a manual or event-triggered synchronization, future scheduled synchronization occurs at multiples of the period from the time of the last synchronization.

The condition in step 7 checks for a service shutdown request. The Synchronization Engine also checks for service shutdown requests during a synchronization scan (step 5). When a service shutdown request is detected, the main loop thread terminates. However, the Synchronization Engine has other threads that also must terminate before the Synchronization Engine process can exit. In particular, one thread in the Synchronization Engine responds to status requests from the PI APS Configuration Utility and will not terminate while the PI APS Configuration Utility is running.