About virtual component spaces

A NiagaraAX station contains object “types,” each within a defined “space” at a top level (Figure 32).

Figure 32. 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.

A station uses these objects when running, and when it is stopped they persist—components in the station’s database (config.bog), files in the station’s directory, and histories within the history database.

Virtual component spaces are different, in the following ways:

There can be multiple virtual component spaces—each belongs to a different virtual gateway, which are specialized 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 are accessed, that is become subscribed.
Virtual components are transient components created in the station only when needed. When no longer necessary (i.e. become unsubscribed) they are automatically removed in 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). For example, links to and from virtual components, use of point extensions (history, alarm, etc.), and typical copy/paste operations are not supported.