Virtual components under a NiagaraNetwork are a standard licensed feature of any Supervisor. In the Supervisor host's license, the boolean "virtual" attribute in the niagaraDriver feature line enables this:

<feature name="niagaraDriver" expiration="never"
device.limit="none" history.limit="none" point.limit="none"
schedule.limit="none" virtual="true" parts="AX-DEMO"/>

This option may not be licensed in most JACE hosts, nor needs to be—unless a JACE’s station is the “middle tier” of a “Niagara virtual to Niagara virtual” mapping back to an AX-3.7 or later Supervisor. In this case, the JACE’s niagaraDriver feature requires the "virtual" option, and it must run AX-3.7 or later.

Note an AX-3.7 Supervisor can effectively access “Niagara virtuals of Bacnet virtuals” in a AX-3.7 JACE station, without the JACE requiring its niagaraDriver license feature to have this "virtual" option.

An AX-3.7 Supervisor can also access Niagara virtuals of most components in AX-3.6 and AX-3.5 stations; however, no “Niagara virtuals of virtuals” (Bacnet virtuals or Niagara virtuals) are possible.

Use of Niagara virtuals in a Supervisor provides the same “on demand subscription” of remote realtime data on Px pages as does proxy points, including right-click popup menus to issues actions. However, the Supervisor station overhead from scores of persisted Niagara proxy points is gone—instead the only persisted items are simply the ORDs to virtuals within Px widgets. This results in fewer resources consumed, along with faster startup of the Supervisor station

Additionally, Niagara virtuals provide a possible savings in engineering time—as point “discovery” and creation using the Bql Query Builder is not needed. Instead, Niagara virtual components expand under a NiagaraStation’s “Virtual” gateway to reflect the entire component tree of that station. So, you can simply drag and drop virtuals onto Px pages and select appropriate settings in the popup “Make Widget” dialogs.

Further, writable Niagara virtuals provide user access to almost any property in a PxPage graphic, for both display and adjustment purposes. For example, to expose the high alarm limit for point, you simply expand its alarm extension to reveal child containers, drag the “Offnormal Algorithm” virtual onto the Px page, and in the Make Widget popup dialog, select the ORD to the “High Limit” property. Any beforehand creation of a Niagara proxy point for this is not needed.

For related details, see Niagara virtuals in Px views.

Because Niagara virtual components are not persisted in the Supervisor’s station database, links to and from Niagara virtuals are not supported. Therefore, values from remote stations needed within station logic require Niagara proxy points. A simple example is a Math “Average” object that averages zone temperatures originating in different JACE stations. Each input to the Math object would require a Niagara proxy point of the relevant (remote station) data source.

Point extensions under Niagara virtuals are also not supported, for example alarm and history extensions—although from a “best practices” perspective, such extensions are often misplaced in Niagara proxy points. For further details on this, see Best practices for Niagara proxy points.

For related details, see Virtual device extension and Views on Niagara virtuals.