Proxy point best practices
The typical large scale use of proxy points has historically been in a Supervisor station to model and display real-time values centrally in Px views. Historically, a Supervisor station may have several hundred or even thousands of proxy points with data that originated within multiple remote stations.
Are proxy points even needed for Px views?
The introduction of export tags, metadata tagging and enhanced writable virtual points has diminished the need for proxy points in a Supervisor stations:
If a Supervisor needs to serve up Px pages that already exist in a station, the use of PxViewTag export tags in that controller station can automatically replicate all needed components on the Supervisor, including all necessary virtual points. Proxy points are not needed.
If you are engineering Px pages that exist only in the Supervisor station and you need real-time values from subordinate controller stations with access to right-click actions, consider using virtual points instead. In some cases, writable virtual points offer techniques previously harder to perform, such as providing a user edit access in a graphic to properties, such as alarm limits.
Metadata tags associated with objects, including categories, roles (permissions), and hierarchies, provide access control and configuration options to manage automated buildings efficiently.
Avoid point extensions under proxy points
Although there is no rules to prevent you from adding history extensions or alarm extensions to proxy points, doing so may be unwise as even momentary communication issues between a controller station and its Supervisor station can result in loss of otherwise recorded history records and alarm conditions.
These recommendations apply to configuring roxy points:
Instead of adding a history extension to a proxy point in the Supervisor station, add it to the source point in the remote station. Then, either import such histories into the Supervisor or, from the controller station side, export them to the Supervisor.
Instead of adding an alarm extension to a proxy point in the Supervisor station, add it to the source point in the remote station. Then, configure alarm routing from the controller station into the Supervisor.
The routines for inter-station history archiving (import) and alarm routing provide integral retry mechanisms, such that temporary loss of station communication typically does not result in loss of history data or alarm events. Instead, that data safely reside in the controller until communication can be re-established.
When is a proxy point required
A proxy point is required when station control logic requires its data value, that is, as the source of a link. For example, you may have a local Average math component that is averaging temperature values sourced from three different stations, using proxy points. Virtual components cannot be used in this way because they do not persist. They exist only during active subscriptions (typically from users accessing Px pages).
Controller stations that directly share and process selected data for control purposes require proxy points.