Virtual gateways reside in the station database, along with other persisted components. Each virtual gateway provides the
link between the normal component space and its own virtual components. In the initial “driver application” of virtual components,
each device component in a driver network has its own single virtual gateway, as shown in Figure 33 for a BacnetDevice in the bacnet palette.
This is a logical division of gateways (separating data by its source device). However, note that future virtual component applications may not always use this “one-to-one-device” hierarchy for virtual gateways. 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.
Unlike with most device extensions, there is no special view for a virtual gateway—in Workbench you can simply double-click it to access the gateway’s property sheet, or expand it in the Nav tree. When you do this for a device’s virtual gateway, a “driver-specific” call is made to the device to gather data, where the results appear as child virtual components.
In the case of the BACnet driver, expanding a virtual gateway fetches “an object list,” where each BACnet object in the device appears as a virtual component (slot) under the gateway. You can further expand each property of an object to see its “virtual properties,” including a value and poll status. See Figure 34.
In this case, each “virtual property” component is a virtual point. For further details about the BACnet implementation, see the “About Bacnet virtual points” section in the NiagaraAX BACnet Guide. For details about virtual components in the NiagaraNetwork of a Supervisor, see Niagara virtual components.