About virtual component spaces

A station’s virtual space describes a transient location for modeling components, devices and points that are not saved to the station database. The original requirement for virtual objects, with a persisted gateway component to access them, came about from driver use-case needs.

Figure 1. Top level object spaces


Object types in these spaces are:

  • Components — in the component space under a Config node (regular component space).

  • Files — in the files space under a Files node.

  • Histories— in the histories space under a History node.

You can optionally enable virtual components to provide a virtualized Px view of any Px views on the remote (actual) component. The Px files are imported (on demand) from the remote device to the Supervisor when the virtual Px view is first accessed.

A station uses these objects when running and, when the station stops, they persist as components in the station’s database, files in the station’s directory and histories in the history database. Virtual component spaces are different from regular components, in the following ways:

  • You may have multiple virtual component spaces, each belonging to a different virtual gateway (specialized persistent components in the station’s component space (under Config).

  • A virtual component space is a mapping of virtual components organized in a tree fashion, created at runtime when components under its virtual gateway, and accessed when subscribed.

  • Virtual components are transient components created in the station only when needed. When no longer necessary (that is when unsubscribed), the driver automatically removes from the running station. This permits monitoring applications in cases where proxy points would use too many resources.

  • Virtual components have limitations and should not be confused with other components, such as proxy points. Links to and from virtual components, use of point extensions (history, alarm, etc.), and typical copy/paste operations are not supported.

Virtual component licensing

Virtual components under a NiagaraNetwork are a standard part of a Supervisor host’s license.

This feature is licensed with the Boolean virtual attribute in the niagaraDriver feature line:

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

This option is typically not licensed in any controller host. It does not need to be.