Performance improvements with virtual components
Most drivers contain a device network, devices, and proxy points (control points with proxy extensions). Linking proxy points to control logic makes it possible to monitor and control building assets. The problem is that every piece of driver data used to visualize and configure a sophisticated model requires that a persistent component (that is, a proxy point) exist somewhere in a station's component space. This overhead becomes prohibitive when running on small embedded platforms with limited memory.
Virtual components solve this problem because they exist in a station database only as long as needed. These transient, on-demand entities reside in their own virtual space with their own virtual Ords (Object Resolution Descriptors), which provide the information needed to create the components at runtime. A virtual gateway links each virtual component space to an actual component space in a one-to-one relationship. A station may have multiple virtual gateways and virtual component spaces.
Each BACnet device includes a child component that serves as its virtual gateway (
) providing access to the device’s virtual component space. The device’s virtual points are under this gateway. There are
two primary uses for BACnet virtual points:
- To poll values in multiple Px view bindings. Only the Ords persist (using virtual syntax) in the Px widget bindings (including the BacnetVirtualGateway within the Ord). With replicated device applications, this allows a station to graphically monitor many more devices than it could monitor otherwise.
- To efficiently review and adjust device property values. Configuring the
You cannot link to virtual components and they do not support point extensions (alarm, history). Links and extensions require BACnet proxy points that persist in the station database.
Virtual Ord syntax
The syntax for a virtual Ord uses a specialized form as follows:
<ord to VirtualGateway>|virtual:/objectType_Instance[A]/propertyName[B]
where:
- <ord to VirtualGateway> identifies the path to the virtual gateway.
- objectType_Instance is the object type instance.
- [A] may be a semicolon-separated list of modifiers. Refer to [A] Modifiers.
- propertyName identifies the name of the property.
- [B] may be a semicolon-separated list of modifiers. Refer to [B] Modifiers
For Example: ip:xx.xx.xx.xx|foxs:|station:|slot:/Drivers/BacnetNetwork/StationName/virtual|virtual:/device_deviceID
Or in the special case of an arrayed property:
<ord to VirtualGateway>|virtual:/objectType_Instance/propertyName/elementN
where N is the property array index.
[A] Modifiers
Valid modifiers include:
- priority=X, which indicates the priority at which the point shall be written. Any set write to the polled present_value property of a Binary Output object occurs at priority level 10:station:|slot:/Drivers/BacnetNetwork/BnetDev_99/virtual|virtual:/binaryOutput_2;priority=10/presentValue
- policy=X indicates the name of a tuning policy. Virtual points do not use COV. Polling of this Analog Input object’s present_value occurs using a Bacnet tuning policy named FastP:station:|slot:/Drivers/BacnetNetwork/BnetDev_99/virtual|virtual:/analogInput_1;policy=FastP/presentValue
[B] Modifiers
Valid modifiers include:
- status=DOPR (Device Object Property Reference) is encoded numerically, ignore line wrap:
- objectType_instanceNumber_propertyId_[propertyArrayIndex]_[deviceObjectType_deviceInstance], where [options in brackets]
- status=0_0_85_8_10 (AI0, PresentValue in Dev10)
- status=0_0_111 (AI0, StatusFlags in local device)
- status=1_3_87_10 (AO3, PriorityArray[10] in local device)
The system merges properties that are BACnetStatusFlags with the bits in the status portion of the BStatusValue. It adds the value of other properties to the facets of the status portion.