General Configuration

Engine startup type

Engine.StartupType

The Type of startup for the object the next time startup occurs: Auto, SemiAuto, or Manual. For an automatic startup, the AppEngine starts automatically in the last check-pointed scan state. A semi-automatic startup is the same as an automatic startup, except that the Engine starts in an offscan state. For a manual start, the AppEngine must be started using the System Management Console.

Supervisory, User

Scan period

Scheduler.ScanPeriod

The period of time, in milliseconds, in which the AppEngine object executes all onscan hosted objects in a sequential order. This is a single thread of execution that represents the desired rate of execution for each of the hosted object. If the time to execute all objects is shorter than the scan period, the remaining time is used by the AppEngine object to process outgoing requests, incoming requests, and checkpoint snapshots. If the time to execute all objects extends beyond the scan period, a "scan overrun" occurs, and the next execution period will not start until the beginning of the next scan period. The default is 500 milliseconds.

Supervisory, User

Enable storage to historian

Engine.Historian.Enabled

If enabled, the values for attributes that have historization enabled will be stored to the specified historian.

None

Enable Tag Hierarchy

Engine.Historian.EnableTagHierarchy

If enabled, the model view is automatically replicated to the Historian node associated with the Galaxy. You can control this behavior at run time without undeploying and redeploying the engine of any affected objects.

Supervisory, User

Historian

Engine.Historian.Connection

The string to use for the connection to the historian. For the Historian, this is the node name.

If two Historian Servers are configured as partners, the node identified by this string becomes the primary historian for this engine. The partner information is configured and maintained on the Historian Server.

Click the ellipse button to browse for the historian on the network.

Read-Only

TCP Port

Engine.Historian.ConnectionTCPPort

The TCP port on the Historian Server node to which history data will be sent. The TCP port is configured when the Historian Server is installed. The default is 32565.

Read-Only

Enable compression

Engine.Historian.CompressionEnable

If enabled, history data is compressed before it is sent over the network to the Historian Server. This is used to reduce network utilization, but enabling this setting will increase the CPU load.

Read-Only

Throttling network bandwidth

Engine.Historian.BandwidthLimit

Specifies limit of bandwidth usage, in kbps, for network communication used by HCAL when communicating with the Historian. A value of 0 disables this feature (default). For more information on estimating your bandwidth needs, see the performance and sizing recommendations for the Historian Server in the System Platform Installation Guide.

On networks with limited bandwidth (for example, 256 kbps) you may want keep half of the bandwidth available for other traffic, so you would set this value to 128 kbps. Consider when the historian connection is lost, and store-and-forward data has accumulated on AppEngine nodes. When the connection between an AppEngine node and historian is restored, all the store-and-forward data is sent at once, and may use the entire network bandwidth (on a slow network) and cause the AppEngines to again lose communication with the Historian and go into store-and-forward data again. By setting a limit here of 2/3 the total bandwidth, this problem of AppEngines going in and out of store-and-forward can be avoided.

This limit applies to all history-related communication, including tag creation, sending real-time data, sending late data, and sending store-and-forward data.

Read-Only

Wait to send incomplete packets

Engine.Historian.BufferAgeLimit

Specifies the maximum time, in milliseconds, for keeping a partially-filled Historian Client Access Layer (HCAL) buffer before sending it to the Historian Server. If the buffer is full, then it is sent immediately, regardless of any value configured in this field. If you have fast-changing data, this setting is irrelevant. If you have slow-changing data and limited network bandwidth, you might want to increase this value so that you have less "chatter" on the network. The default is 1,000 milliseconds. Valid values are between 1,000 and 30,000 milliseconds.

Read-Only

Pre-processing buffer size

Engine.Historian.BufferSize

The total size, in MB, of all buffers used by Historian Client Access Layer (HCAL). The default and minimum value is 8. If you have very high data bursts, then you should increase this value. If this is too low, data loss occurs and error messages related to buffer overflows appear in the ArchestrA Logger. Increase this value in increments of 10 MB.

Supervisory, User

Store forward threshold

Engine.Historian.StoreForwardDeletionThreshold

The size, in MB, of free space to reserve on the HCAL store-and-forward disk. The space designated will not be used during store-and-forward. This value cannot be a negative number.

Read-Only

Store forward minimum duration

Engine.Historian.StoreForwardMinDuration

The minimum duration, in seconds, for HCAL to function in store-and-forward mode. HCAL will function in store-and-forward mode for this length of time even if the condition that caused HCAL to function in store-and-forward mode no longer exists.

Supervisory, User

Reconnect as soon as possible & do not mark disconnects

Engine.Historian.LateDataEnabled

Specifies how trends appear during communication disconnects between Application Server and Historian. It does not affect how trends of history data appear after communications have been restored.

If TRUE, no gap will appear in client-side trends for the disconnect interval. While disconnected, the interval is filled in with the last-received value before the disconnect.

If FALSE, a gap will appear in client-side trends for the disconnect interval. NULL values are injected on disconnect to create the gap.

In both cases, after reconnect, the interval will be filled in with store-and-forward data.

Supervisory, User

Maximum time for scripts to execute

Engine.ScriptExecuteTimeout.Limit

The time, in milliseconds, allowed for any synchronous script primitive to execute before an alarm is raised on that script primitive. This timeout applies to script primitives attached directly to the AppEngine object, as well as to ApplicationObjects hosted by the AppEngine object. Note that configuration security means that this attribute can only change when the AppEngine object is offscan, thus allowing the optimization of the script engine, since it only needs to read the attribute once when going onscan. The maximum value is limited to the Scheduler.ScanPeriod for the AppEngine object. The default is 500 milliseconds.

User

Maximum asynchronous thread count

Engine.AsyncScriptThreadMax

The maximum number of asynchronous script threads that can be executing simultaneously.

Read-Only

Checkpoint period

Scheduler.CheckpointPeriod

The Checkpointing saves run-time attribute values. The checkpoint period is the time, in milliseconds, at which checkpointing is performed. The default checkpoint period is 10,000 ms. If set to 0, the checkpoint period defaults to the scan period, but may occur at a slower rate (it is done as fast as possible as a background task).

The minimum checkpoint interval for retentive attributes is 10,000 ms. Retentive attributes are defined as those attributes configured as calculated retentive, or object- or user-writeable. If the checkpoint period is set to less than 10,000 ms, retentive attributes will not be saved at every checkpoint. For example, if the checkpoint period is set to 4,000 ms, retentive attribute values will only be saved at every third checkpoint (4,000 x 3 = 12,000 ms).

Retentive attributes retain the last value set during run time, and the run-time value is saved across redeployments. Non-retentive attributes revert to their configured values at redeployment. The default is 10,000 milliseconds.

Supervisory, User

Checkpoint directory location

Engine.CheckpointPath

The path where the checkpoint files will be located. If you do not specify a location, the system default path will be used. If the specified location is not accessible, a warning will be logged. If the location you specify does not currently exist, it will be created. You cannot use a virtual drive or a UNC path for the checkpoint directory location.

Read-Only

Alarm throttle limit

Engine.AlarmThrottleLimit

The limit for the number of alarms per second that can be raised by the object before throttling occurs. If set to 0, alarm throttling is disabled.

User

Statistics average period

Scheduler.StatsAvgPeriod

The frequency, in milliseconds, that averaged attribute values are updated. This value must be greater than or equal to the scan period. The average is a running average; that is, values are accumulated for an attribute over the period of time set for this attribute. The value of this attribute affects the run-time values at any given time of all other attributes of the same type of object that are averaged and can be used to "slow down" the updating of the cycle-oriented statistics.

Supervisory, User

Maximum input queue size

Scheduler.InputQueueSizeMaxAllowed

The maximum size for the object input queue. The default is 16 MB. An object's input queue receives all system level messages, such as publish packets, heartbeats, gets, sets, and so on. These messages are then processed by the system. The input queue size grows and shrinks over time. Should the input queue grow to its maximize size, messages are not queued until messages in the queue are processed, making room for additional ones. Valid values are 2 through 128.

Read-Only

Engine failure timeout

Engine.EngineFailureTimeout

The amount of time, in milliseconds, that the engine can run without notifying the bootstrap of its health. After this time elapses, the EngineFailureAlarm attribute is set TRUE in the WinPlatform object. Be sure that you specify a time long enough to accommodate the completion of any engine-related actions that might prevent or delay the bootstrap notification (for example, cascade deployment of objects with a large number of scripts). The minimum timeout the system allows at run time is 55000 ms. If a shorter timeout is configured, the configured value is ignored and the object will use the 55000 ms minimum when it is deployed.

Supervisory, User

Maximum number of consecutive data notification failures allowed

Engine.DataNotifyFailureConsecMax

The number of consecutive data change notification failures that will be allowed before the subscription is stopped by the publisher engine.

Supervisory, User