Virtual node under a NiagaraStation

In the initial driver application of virtual components, each device component in a driver network has its own single virtual gateway (as shown here) for a BacnetDevice in the bacnet palette.

Figure 32.   One virtual gateway per device

This is a logical division of gateways (separating data by its source device). Future virtual component applications may not always use this one-to-one device hierarchy. At some future point, a driver may have a network level virtual gateway or possibly provide multiple virtual gateways under the same device level or network level.

A few drivers have device-level components that contain a Virtual gateway child. This is in addition to the standard collection of slots for device-level components. In the Niagara driver architecture, a device’s virtual gateway provides access to virtual components in the station’s virtual component space, specific to the device.

The BACnet driver, and the niagaraDriver (NiagaraNetwork) both provide virtual components.

Successfully accessing components under the Virtual gateway dynamically adds them as virtual components (or virtuals) while they are subscribed, but they exist only in memory. They do not persist in the station database like proxy points.

Virtual components are sometimes referred to as virtual points, but they are quite different from the proxy point components found in most drivers. The term “virtual point” is a actually a misnomer as virtual components represent any component type in the source remote station (not just control points).

Niagara virtual gateway requirements

Virtual gateways provide virtual component access only if the following are all true: