User Manual
Table Of Contents
- 1 Cyber security disclaimer
- 2 Preconditions of this document
- 3 System overview
- 4 Desigo workflow, tools and programming
- 4.1 Coverage of the technical process
- 4.2 Coverage of the system
- 4.3 Main tasks
- 4.4 Tools for different roles
- 4.5 Working with libraries
- 4.6 Working in parallel and subcontracting
- 4.7 Workflow for primary systems
- 4.8 Workflow for room automation classic
- 4.9 Workflow for Desigo room automation
- 4.10 Desigo Configuration Module (DCM)
- 4.11 Desigo Xworks Plus (XWP)
- 4.12 Desigo Automation Building Tool (ABT)
- 4.13 Programming in D-MAP
- 5 Control concept
- 6 Technical view
- 7 Global objects and functions
- 8 Events and COV reporting
- 9 Alarm management
- 9.1 Alarm sources
- 9.2 Alarm example
- 9.3 Effects of BACnet properties on alarm response
- 9.4 Alarm response of the function blocks
- 9.5 Alarm functions
- 9.6 Alarm management by notification class
- 9.7 Alarm routing over the network
- 9.8 Alarm queuing
- 9.9 Common alarms
- 9.10 Alarm suppression
- 9.11 Alarm message texts
- 10 Calendars and schedulers
- 11 Trending
- 12 Reports
- 13 Data storage
- 14 Network architecture
- 15 Remote access
- 16 Management platform
- 17 Desigo Control Point
- 18 Automation stations
- 19 Logical I/O blocks
- 20 Room automation
- 21 Desigo Open
- 22 System configuration
- 22.1 Technical limits and limit values
- 22.2 Maximum number of elements in a network area
- 22.3 Desigo room automation system function group limits
- 22.4 Devices
- 22.4.1 PXC..D automation stations / system controllers
- 22.4.2 LonWorks system controllers
- 22.4.3 Automation stations with LonWorks integration
- 22.4.4 PX Open integration (PXC001.D/-E.D)
- 22.4.5 PX Open integration (PXC001.D/-E.D + PXA40-RS1)
- 22.4.6 PX Open integration (PXC001.D/-E.D + PXA40-RS2)
- 22.4.7 PX KNX integration (PXC001.D/-E.D)
- 22.4.8 TX Open integration (TXI1/2/2-S.OPEN)
- 22.4.9 Number of data points on Desigo room automation stations
- 22.4.10 Number of data points for PXC3
- 22.4.11 Number of data points for DXR1
- 22.4.12 Number of data points for DXR2
- 22.4.13 PXM20 operator unit
- 22.4.14 PXM10 operator unit
- 22.4.15 Desigo Control Point
- 22.4.16 PXG3.L and PXG3.M BACnet routers
- 22.4.17 SX OPC
- 22.4.18 Desigo CC
- 22.4.19 Desigo Insight
- 22.4.20 Desigo Xworks Plus (XWP)
- 22.4.21 Desigo Automation Building Tool (ABT)
- 22.5 Applications
- 23 Compatibility
- 23.1 Desigo version compatibility definition
- 23.2 Desigo system compatibility basics
- 23.2.1 Compatibility with BACnet standard
- 23.2.2 Compatibility with operating systems
- 23.2.3 Compatibility with SQL servers
- 23.2.4 Compatibility with Microsoft Office
- 23.2.5 Compatibility with web browsers
- 23.2.6 Compatibility with ABT Go
- 23.2.7 Compatibility with VMware (virtual infrastructure)
- 23.2.8 Compatibility of software/libraries on the same PC
- 23.2.9 Hardware and firmware compatibility
- 23.2.10 Backward compatibility
- 23.2.11 Engineering compatibility
- 23.2.12 Compatibility with Desigo Configuration Module (DCM)
- 23.2.13 Compatibility with Desigo PX / Desigo room automation
- 23.2.14 Compatibility with Desigo RX tool
- 23.2.15 Compatibility with TX-I/O
- 23.2.16 Compatibility with TX Open
- 23.3 Desigo Control Point
- 23.4 Upgrading from Desigo V6.2 Update (or Update 2) to V6.2 Update 3
- 23.5 Siemens WEoF clients
- 23.6 Migration compatibility
- 23.7 Hardware requirements of Desigo software products
- 24 Desigo PXC4 and PXC5
- 25 Compatibility of Desigo V6.2 Update 3 with PXC4 and PXC5
Alarm management
Alarm management by notification class
9
CM110664en_07 155 | 351
The burner system is restarted when the service engineer has acknowledged the alarm, cleared the fault
and reset the alarm. The alarm state of every alarm-generating object is managed within the object itself.
The state machines above illustrate this for each of the alarm functions.
Simple message
The alarm function simple message is the same function as the simple alarm. State transitions, however,
are not indicated as events, but alarms.
For HVAC applications and response in the system, the functionality is identical to simple alarm: Simple
alarm without acknowledgement of incoming and outgoing faults. The only difference is EventNotification
as alarm or event.
Customized alarm
Any alarm function under BACnet can be used. The following behavior can be defined for customized
alarms:
● EventNotification can occur as either event or alarm
● Acknowledgement: For each change of state (TO-OFFNORMAL, TO-NORMAL, and TO-FAULT) can be
defined whether or not an acknowledgement is required.
[AckTra] Acknowledged transitions
This feature is used to represent the acknowledgement status, or to handle information about which state
transitions currently still require acknowledgement. The value of [AckTra] is based on the alarm function,
the current [EvtSta] and the monitoring of acknowledgements already received.
[AckTra] consists of three flags, one each for TO-OFFNORMAL, TO-NORMAL and TO-FAULT. The flags
have the following meanings:
● The flag is always FALSE when there has been a relevant state transition and an acknowledgement is
required, because this is a requirement of the alarm function and no acknowledgement has yet taken
place.
● The flag is TRUE when no acknowledgement of the state transition is required. This may be the case
because the alarm function does not require acknowledgement, or because no state transition has
occurred, or because a state transition that has occurred has already been acknowledged.
[TiAck] Time of acknowledgement
Time of the last acknowledgement (time stamp).
9.6 Alarm management by notification class
Intrinsic reporting
With intrinsic reporting, the alarmable object itself assumes alarm identification and state machine for
alarm handling. However, the subsequent distribution of alarm messages to alarm clients and the alarm
management is no longer the responsibility of the alarm source itself, but of a Notification Class object
assigned to the alarm source. The Notification Class object is both a D-MAP function block and a standard
BACnet object, which contains all the information required for the distribution of alarms and system events
within the system.
Algorithmic reporting
With algorithmic reporting, alarm detection and the state machine for alarm handling normally are taken
over by the Event Enrollment object. In this case, alarm management also is set up in an alarm source via
assigned Notification Class object.
Notification Class