Understand Advanced Logic Processor (ALP) Global Process Settings

Note: For information on overriding default configuration settings, see Modify Configuration Settings.

The global settings for AVEVA Pipeline Operations for Liquids applications are set in the AVEVA Pipeline Operations for Liquids configuration JSON file located in %DNAInstallRoot%\RealTime\config\Settings\LMS.RealTime.Json. The Advanced Logic Processor (ALP) settings content is within the LMS > MonitorALP section.

The settings from this file are installed as part of the AVEVA Pipeline Operations for Liquids installation process. You will not normally need to change these settings. If you do need to change this file, the RealTime service must be restarted for the changes to take effect.

The following example details the default settings in the file:

"MonitorALP": {

"LogFile": "monitorALP.log",

"Debug": false,

"CheckIn": true,

"CriticalProcess": true,

"RestartProcessOnUnexpectedExit": false,

"CheckinTimeout": 60,

"CheckinSleepInterval": 15,

"StartUpDelay": 32,

"PublishDelayMilliseconds": 0,

"PubSubReceiveQueueSize": 50000

}

Where:

• "LogFile" is the name of the log file to which errors are generated when the debug level is defined as verbose. This value should be a valid file name.

• "Debug" is a true/false value indicating if the MonitorALP process should be operating in debug mode. When Debug is set to true, additional information will be sent to the monitorALP process log file as configured by "LogFile"—the default is false.

• "CheckIn" is a true/false value indicating whether the MonitorALP process should check into the RealTime Process Monitor at startup—the default is true.

• "CriticalProcess" is a true/false value indicating whether the MonitorALP process should check into RealTime Process Monitor as a critical process (only applicable when CheckIn is true)—the default is true.

• "RestartProcessOnUnexpectedExit" is a true/false value indicating whether the MonitorALP process should restart and check into RealTime Process Monitor as a process to restart on unexpected exit (only applicable when CheckIn is true)—the default is false.

• "CheckinTimeout" is an integer value indicating the maximum number of seconds between check-ins before the MonitorALP process is declared dead (only applicable when CheckIn is true)—the default is 60 seconds.

• "CheckinSleepInterval" is an integer value indicating the maximum number of seconds between each attempted checkin by the MonitorALP process (only applicable when CheckIn is true)—the default is 15 seconds.

• "StartupDelay" is an integer value indicating the number of seconds that the primary processing loop of the MonitorALP process will wait before beginning operations—the default is 32 seconds.

• “PublishDelayMilliseconds” is an integer value indicating the number of milliseconds to delay before publishing an Advanced Logic Processor (ALP) evaluation result—the default is 0 milliseconds.

  Note: An example, for a time delay of one second 1000 milliseconds should be used.

• "PubSubReceiveQueueSize" is an integer value indicating the size of the PubSub receive queue. The size of this queue is a function of the number of configured objects for each device type and the number of topics associated with these types. The default is 50000, which is the minimum, and the size can be calculated as follows:

  S =

  (Number of ALPConfigs x 163 topics per ALPConfig) x 1.10

  PubSubReceiveQueueSize = S rounded up to the nearest 10,000

  Notes: AVEVA recommends that the value of PubSubReceiveQueueSize be tested by performing a few failover scenarios to ensure connectivity between the standby and hot servers.
  An insufficient queue size will cause the system to disconnect from PubSub. A disconnected state is not recoverable and will trigger a failover to the standby server. When a disconnection from PubSub occurs, it is accompanied by the following log error message:

  ERROR - Application MonitorALP (pid N) has been declared too slow.

If the above error log message persists after using the calculated value for PubSubReceiveQueueSize, multiply the calculated value by a factor of two, restart RealTime and retest the same failover scenarios. You may need to perform a few iterations of adjusting the value and testing the failover scenarios until no errors occur.

It is recommended that you perform this test again whenever a large number of assets are added to the system.