niagaraDriver-NiagaraTuningPolicy

Contains properties used in the NiagaraNetwork’s handling of both write requests (e.g. to writable proxy points) as well as the acceptable freshness of read requests of proxy points. You can create multiple tuning policies under the NiagaraNetwork’s NiagaraTuningPolicyMap. You can then assign one or more proxy points to a specific policy. Container for one or more NiagaraTuningPolicy(ies), found in the NiagaraNetwork’s property sheet.

A network’s Tuning Policies holds one or more collections of rules for evaluating both write requests (e.g. to writable proxy points) as well as the acceptable freshness of read requests from polling. In some drivers (such as Bacnet), also supported is association to different poll frequency groups (Slow, Normal, Fast). Tuning policies are important because they can affect the status of the driver’s proxy points.

In the network’s property sheet, expand the Tuning Policies (Map) slot to see one or more contained Tuning Policies. Expand a Tuning Policy to see its configuration properties, as shown.

Figure 74. Example Tuning Policies Map (OpcUa)

NOTE: Some driver networks do not have Tuning Policies, for example an RdbmsNetwork for a database driver.

By default, a driver’s TuningPoliciesMap contains just a single TuningPolicy (Default Policy). However, you create multiple tuning policies, changing those items needed differently in each one. Then, when you create proxy points under a device in that network, you can assign each point (as needed) to the proper set of “rules” by associating it with a specific tuning policy.

CAUTION: Using only a single (default) tuning policy, particularly with all property values at defaults, can lead to possible issues in many driver (network) scenarios. In general, it is recommended that you create multiple tuning policies, and configure and use them differently, according to the needs of the network’s proxy points and the capabilities of the driver. In particular, tuning policy properties that specify writes from the framework should be understood and applied appropriately. See Tuning Policy properties for more details.

As a simple example (under a BacnetNetwork), you could change the default tuning policy’s Write On Startproperty from the default (true) to false. Then, duplicate the default tuning policy three times, naming the first copy Slow Policy, the second copy Normal with Write Startup, and the third copy Fast Policy. In two of those copies, change the Poll Frequencyproperty from Normal to Slow or Fast, corresponding to its name. In the Normal with Write Startup tuning policy copy, you could change its Write On Start property back to true.

Then, only the Normal with Write Startup tuning policy has Write On Start set as true. At this point you would then have four available (and different) tuning policies to pick from when you create and edit proxy points, where you could selectively apply the policy needed.

Tuning Policy Properties

Tuning policies used by a specific driver may have unique characteristics. Other drivers may have specific considerations for tuning policies. The below is the example of Bacnet driver tuning policy properties:

Figure 75. Example of tuning policy properties for the Bacnet driver

You access this Property Sheet by expanding Config > Drivers followed by double-clicking or right-clicking the network node, clicking Views > Property Sheet and expanding the Tuning Policies > Default Policy.

Property	Value	Description
Min Write Time	hours minutes seconds (defaults to zero (0))	Specifies the minimum amount of time allowed between writes to writable proxy points, especially ones that have one or more linked inputs. This provides a way to throttle rapidly changing values so that only the last value is written. The default value (0) disables this rule causing all value changes to attempt to write.
Max Write Time	hours minutes seconds (defaults to zero (0))	Specifies the maximum amount of time to wait before rewriting the value, in case nothing else has triggered a write, to writable proxy points. Any write action resets this timer. The default (0) disables this rule resulting in no timed rewrites. In some cases, setting this to a value, such as 10 minutes, may be useful. Often, a network may have devices that, upon a power cycle or even a power interruption, have writable points that reset to some preset default value or state. Often, in a site-wide power bump of a few seconds, such field controllers (devices on the network) typically reset, but the controller continues normal operation running on a backup battery. Since the network’s default monitor ping is usually 5 minutes, the station (network) may never mark these devices as down, such that a `Write On Up` does not occur. If a writable point represents an AHU or chiller that defaults to unoccupied following a device reset, the load never restarts until the next day when the schedule toggles. Assigning the point to tuning policy that does have a configured `Max Write Time` can correct this problem. At the same time, realize that many networks may be configured such that multiple masters may be issuing conflicting writes to one or more points in a device. In this case, exercise caution with this property to avoid write contention that could result in toggling loads.
Write On Start	`true` (default) or `false`	Determines a writable proxy point’s behavior when the station starts. `true` initiates a write when the station first reaches a steady state. `false` prevents a write when the station first reaches a steady state. NOTE: Consider setting to `false` except for critical proxy points, otherwise large networks may experience write-queue-overflow exceptions. Consider setting this to `false` for most tuning policies, except for tuning policies selectively assigned to more critical writable proxy points. This is particularly important for large networks with many writable proxy points. For example, a BacnetNetwork with 4,000 writable proxy points, if configured with only the default Tuning Policy (at default values), upon station startup attempts to write to all 4,000 points. This puts a significant load on the station. As a consequence, the BACnet driver (network) may generate write-queue-overflow exceptions.
Write On Up	`true` (default) or `false`	Determines a writable proxy point’s behavior when the point and its parent device transition from down to up. `true` initiates a write when a transition from down to up occurs. `false` prevents a write when a transition from down to up occurs.
Write On Enabled	`true` (default) or `false`	Determines a writable proxy point’s behavior when the point’s status transitions from disabled to normal (enabled). `true` initiates a write when the transition occurs. `false` prevents a write when the transition occurs. The disabled-to-enabled status transition can be inherited globally by points if the parent device was set to disabled, or network-wide, if the driver network was set to disabled. Therefore, be aware that when left at `true` all associated writable proxy points receive a write when either the device or network transition from a status of disabled to enabled.
Stale Time	hours minutes seconds (defaults to zero (0))	Defines the period of time without a successful read (indicated by a read status of {ok}) after which a point’s value is considered to be too old to be meaningful (stale). A non-zero value causes the point to become stale (status stale) if the configured time elapses without a successful read, indicated by Read Status {ok}. The default value (zero) disables the stale timer causing points to become stale immediately when unsubscribed. A tan background identifies stale proxy points. A stale status is considered invalid for any downstream-linked control logic. Do not configure an amount of time shorter than the poll cycle time. If you do, points will go stale in the course of normal polling. Instead, set this time to be longer than the largest expected poll cycle time. You should configure a Stale Time that is at least three times the expected poll cycle time. Most peer-to-peer networks do experience collisions and missed messages. Setting the Stale Time short will likely produce nuisance stale statuses. If a message is missed, a longer Stale Time allows for another poll cycle time during which to receive the message before setting the stale flag.
Poll Frequency (This property may not exist in some driver’s tuning policies, but is instead a separate property of each ProxyExt)	drop-down list (defaults to Normal)	Selects among three rates (Fast, Normal and Slow) to determine how often to query the component for its value. The network’s Poll Service or Poll Scheduler defines these rates in hours, minutes and seconds. For example: `Fast` may set polling frequency to every second. `Normal` may set poll frequency to every five seconds. `Slow` may set poll frequency to every 30 seconds. This property applies to all proxy points. Depending on the driver, there may be a single Poll Service (or Poll Scheduler) slot under the network, or as in the case of a BacnetNetwork, a separate Poll Service for each configured port (IP, Ethernet, Mstp) under its BacnetComm > Network container. The NiagaraNetwork uses subscriptions instead of polling.
Use Cov	`true` or `false` If the device was discovered, and station database determined that the device indicates support for server-side COV, this property defaults to `true`. Otherwise, it defaults to `false` indicating that no proxy points under the device use COV.	Enables and disables a device’s support for COV (change of value) as a way to monitor proxy point values. Assuming the device supports subscription to the COV service, `true` triggers the driver to attempt the necessary updates (proxy subscriptions) to the value of each point using the BACnet COV subscription to the device. If the subscription attempt succeeds, the `Read Status` property of the point’s BacnetProxyExt displays COV. If the subscription attempt fails, the driver uses normal polling and the `Read Status` property shows Polled. When `true`, individual proxy points under the device may use COV subscriptions, depending on their assigned tuning policy. When `false`, the driver ignores any proxy subscription updates. How to find: expand the BACnet network and double-click the BACnet device. Also available on the Device Manager Add window.
Use Confirmed Cov	`true` (default) or `false`	Controls device updates. If enabled (`true`), and the assigned proxy points are under a BacnetDevice that supports Confirmed COV notifications, the driver attempts any necessary updates (proxy subscriptions) using BACnet confirmed COV subscriptions to the device. If disabled (`false`), the driver ignores this property. How to find: expand Config > Drivers, BACnet network, expand Tuning Policies and double-click Default Policy
Cov Subscription Lifetime	time range (defaults to 15 minutes)	Indicates the lifetime, in minutes, for which the database subscribes for COV notifications, then (if necessary) periodically subscribes again. A value of zero means an indefinite lifetime, although this is not guaranteed to persist across resets of the server device.

NiagaraNetwork Tuning Policies

A NiagaraNetwork has only three tuning policies as shown below:

Figure 76. NiagaraNetwork Tuning Policy

Property	Value	Description
Stale Time	time	If set to a non-zero value, a subscribed proxy point becomes stale (status stale) if the configured Max Update Time expires without an update from the server (source station). This stale timer is reset upon each subscription update. If set to zero (default), the stale timer is disabled, and a subscribed point becomes stale only while the source (server) point is also stale. NOTE: Whenever a source point of a proxy point has a stale status, for example a Bacnet proxy point, the proxy point for it will also have a stale status, regardless of this setting. Stale time is client side, whereas the other two update time properties affect server side operation of the subscription. For example, when a client ( Supervisor) station creates subscriptions to a server station (JACE with a field bus), say to update proxy point values on a Px page, subscriptions are set up with the server to observe rules in the Min and Max Update Time values.
Min Update Time	Time	The minimum amount of time between updates sent from the server to the client. It is used to throttle data changing at a rate faster than minUpdateTime. Default value is 1 second.
Max Update Time	Time	Used by the server to resend the values to the client for subscribed points, if values have not been sent for other reasons (such as a change of value or status). Default value is 15 minutes. NOTE: Relative to tuning policies in other networks, the importance of NiagaraNetwork tuning policies are secondary, and then only applicable for a station that has proxy points under its NiagaraNetwork. In applications, this means the Supervisor station only. As a general rule, if configuring the Stale Time in a Tuning Policy, it is recommended to be greater than the Max Update Time by a factor of three.