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
System overview
Data maintenance
3
CM110664en_07 25 | 351
All process data and parameter settings, even those that are not mapped to BACnet objects (engineering
setting), can be monitored and operated in Xworks Plus (XWP). BACnet clients only see what is available
via BACnet.
If several clients modify the same process data, the last change is accepted.
Volatile and non-volatile process data and parameter settings
The majority of the process data is volatile data, which is recalculated when the automation stations are
restarted. However, certain process data is retained even after an automation station restart, e.g., self-
adaptive control parameters, run-time totalizers, etc., which are specifically identified as such in a function
block. Even in the event of a program change, this non-volatile process data remains in memory and can be
read back with XWP.
All parameter settings are non-volatile, that is, they are retained in the event of a power failure.
Readback
All non-volatile PX process data and parameter settings can be read back into XWP. However, parameter
settings in the operator unit cannot be read back into a tool.
Global parameter settings
Some parameter settings are identical in all automation stations, e.g., date and time, calendar function
blocks and Notification Class function blocks. To ensure consistency, they are held in global objects which
are automatically replicated in the system.
Archived data
Setting parameters can be logged and archived. Archived data illustrates the response of process or system
variables or events over a time period, e.g., trend data can be moved from the trend database into archive
files. Archived data are typically lists of one or more of the aforementioned variables and are preferably
stored and processed on the management level. Only small amounts of data are archived at the automation
level. Such data is normally forwarded to the management level.
Ensuring consistency
Archived data only requires a consistency check in cases where it has been moved from one application to
another, e.g., from the automation level to the management level. The data origin is not deleted until a
check has been carried out to ensure that the data has been transferred in full. This data is stored in the
non-volatile memory.
Irregularities in the logging of archived data are recorded in the data itself.
The life of the data is determined either by the user or by a configurable application which automatically
condenses or deletes this archived data.
Configuration and description data
Configuration and description data is data which is defined for a specific system or project and only affects
the appearance and response of the plant for operation and monitoring purposes. Some configuration
parameters are tool-specific and control the options in XWP (e.g., connection allowed / not allowed, etc.).
Most configuration parameters, however, are mapped to BACnet and are available to the clients. Typical
data in this category is COV increment, operating limits, access level, descriptive text, engineering unit, etc.
This data is defined during engineering and always originates in the tool itself. Normally, the data is
predefined with likely default values or even generated automatically from the context. This data is static
and cannot be modified during operation. It is therefore not subject to consistency problems, and may be
duplicated elsewhere in the system to improve performance. If engineering changes are made, you must
ensure manually (through data import) that the copies are identical to the original data in the engineering
tool.
This data cannot be read back from the automation stations, and must therefore be stored with the project
data.
Metadata
Metadata is project-independent data from standard BACnet objects (e.g., analog input, schedule, etc.)
which needs to be known by a tool or a client, e.g., texts for predefined BACnet enumeration, maximum size
of arrays, data-type information, fixed operating limits, etc. The metadata is loaded into the relevant clients
or tools at HQ and (except texts) cannot be modified after delivery. Text, like the text for BACnet
enumeration referred to above, must be localized (language translation) and distributed to the clients and
tools. This is part of the localization process.