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 (See About device components.) In the NiagaraAX driver architecture, a device’s virtual gateway provides access to “virtual components” in the station’s “virtual component space,” specific to that device.

At the time of this document update, there are two drivers that have implemented virtual components: the BACnet driver, and the AX-3.4 and later niagaraDriver (Niagara Network). Details on the latter are in this document, see Niagara virtual components.

Virtual components are sometimes referred to as “virtual points”, quite different from the “proxy point” components found in most drivers. The term “virtual point” is a actually a misnomer to describe the niagaraDriver implementation, as Niagara virtual components reflect whatever component types are in the source remote NiagaraAX station (not just control points).

Baja virtual components are not specific to just drivers. However, the original need for virtual components (which are transient, and do not permanently reside in a station’s database) and a persisted “gateway” component to access them, came about from driver “use case needs.” It is possible that other applications for virtual gateways (with virtual components) may evolve in future builds of NiagaraAX.

See the following sections for more details: