BACnet device object

Certain properties of the BACnet device object are defined as global, because from the perspective of the system, they are required to have the same value throughout the site. These properties are set in Xworks Plus (XWP). Examples:

Global properties

  • Date and time for the summer and winter time changeover.
  • Daylight savings time start date [DsavSdt] (Default: last Sunday in March)
  • Daylight savings time start time [DsavSti] (Default: 02:00AM)
  • Daylight savings time end date DsavEdt] (Default: Last Sunday in October)
  • Daylight savings time end time [DsavEti] (Default: 03:00AM)
  • UTC_Offset [UtcOfs]
  • Difference between UTC and local Winter time in minutes. Default value: – 60 mins (Central Europe). In Summer, the effective difference [UtcOfs] is –60 mins (Central Europe: –120min).
  • Synch.Request Period [SynReqp]
  • Period between life checks by primary server The load on the communications system generated by the life check can be controlled with this parameter by adapting it to the site size. Default value: 1800 s.
  • Name resolution interval [NamRI]
  • Periodic repetition for the resolution of references across devices. Default value: 900 s.
  • COV resubscription interval [CovRI]
  • Time within which the automation station resubscribes to a subscribed value. Default value: 1800 s.

Local properties

Local properties which refer to the functionality of the life check / replication:

  • Server type [SvrTyp]
  • Defines if the device acts as a primary server or a backup server. Default: backup.
  • Primary device [PrimDev]
  • Device object ID of the primary server of the site or an invalid value if the primary server is not known (read-only, set automatically by the primary server).
  • Last engineering time, global object [GOEngTi]
  • Time stamp of the last structure modification of the global objects by Xworks Plus (XWP).
  • Last online modification of global objects [GOChgTi]
  • Time stamp of the last online modification of a global object in Xworks Plus (XWP) (modified by the primary server, read-only).

Notification class object

The Notification Class object is a standard BACnet object and defines the system response of alarms and system events.

There are local and global Notification Class Objects.

Global Notification Class Object: A logical object at site level that exists in identical form (as a replicated object) in every automation station on a site.

Local Notification Class Object: Individual object (unique object) that exists only on a particular automation station.

Reading of objects by a client: A client may read the global notification class objects from any automation station.

Reasons for replication: Keeping the setting parameters consistent for all automation stations of a site when modifications occur (adding or deleting configured recipients from recipient list, changing priorities).

The number of global Notification Class objects is limited to 18 (six alarm classes each with three possible alarm functions).

Calendar object

There are global and local calendar objects.

Global calendar object: A logical object at site level. It exists in identical form (as a replicated object) on each automation station of a site.

Local calendar object: Individual (unique) object that exists only on a particular automation station.

Local processing: Schedule objects in an automation station may reference the replicated calendar objects in the device. A client may read the global calendar objects from any automation station.

Reasons for replication: Global exceptions (bank holidays, general holidays, etc.) can be modified centrally in one location for the entire site. Ensures continuity of operation if the main object fails.

User profile object

Global user profile object: A logical object at the site level. It exists in identical form (as a replicated object) on each automation station of a site. There must be at least one user profile object.

There are no local user profile objects.

Local processing: Access control is based on the replicated user profile objects in the automation stations (BACnet devices): No dependency on a server.

Reading of objects by a client: A client may read the global user profile objects from any automation station.

Reasons for replication: Replication is designed to maintain consistency of the access rights throughout the site. Ensures continuity of operation if the main object fails.