Desigo™

Building automation system 6.1

Technical Principles

CM110664en_03 Building Technologies

2017-09-18
 Copyright

Copyright
Technical specifications and availability subject to change without notice.

Transmittal, reproduction, dissemination and/or editing of this document as well as

utilization of its contents and communication thereof to others without express
authorization are prohibited. Offenders will be held liable for payment of damages.
All rights created by patent grant or registration of a utility model or design patent
are reserved.

Issued by:
Siemens Switzerland Ltd
Building Technologies Division
International Headquarters
Gubelstrasse 22
CH-6301 Zug
Tel. +41 58 724-2424
www.siemens.com/buildingtechnologies

Edition: 2017-09-18
Document ID: CM110664en_03

© Siemens Switzerland Ltd, 2015

2 | 377
Siemens CM110664en_03
2017-09-18
 Table of Contents

1 Preconditions of this Document .............................................................. 9

2 System Overview ............................................................................... 10
2.1 Management Level ....................................................................................11
2.2 Automation Level .......................................................................................12
2.3 Room Automation ......................................................................................14
2.4 Desigo Open .............................................................................................15
2.5 Workflow and Tools ...................................................................................15
2.6 Topologies .................................................................................................17
2.7 Communication Principles..........................................................................19
2.8 Data Maintenance......................................................................................22
2.9 Views ........................................................................................................27
3 Desigo Workflow, Tools and Programming ............................................ 30
3.1 Coverage of the Technical Process............................................................30
3.2 Coverage of the System ............................................................................32
3.3 Main Tasks ................................................................................................34
3.4 Tools for Different Roles ............................................................................38
3.5 Working with Libraries................................................................................39
3.6 Working in Parallel and Subcontracting ......................................................39
3.7 Workflow for Primary Systems ...................................................................40
3.8 Workflow for Room Automation Classic......................................................41
3.9 Workflow for Desigo Room Automation ......................................................41
3.10 Desigo Configuration Module (DCM) ..........................................................42
3.11 Desigo Xworks Plus (XWP)........................................................................43
3.12 Desigo Automation Building Tool (ABT) .....................................................49
3.13 Programming in D-MAP .............................................................................51
4 Control Concept ................................................................................. 54
4.1 Control Concept and Control Blocks...........................................................59
4.2 Local Control Design .................................................................................67
4.3 Superposed Plant Controls ........................................................................70
4.4 Closed-Loop Control Strategy ....................................................................86
4.5 Desigo Room Automation ..........................................................................95
5 Technical View ................................................................................. 112
5.1 Standard Plant Structures ........................................................................112
5.2 Technical Text Labels ..............................................................................117
6 Global Objects and Functions ............................................................ 120
6.1 Ensuring Data Consistency ......................................................................120
6.2 Roles in the System .................................................................................121
6.3 Life Check ...............................................................................................122
6.4 Time Synchronization ..............................................................................123
6.5 Examples of Global Objects .....................................................................124
7 Events and COV Reporting ................................................................ 129
7.1 Sources and Causes of System Events....................................................129

3 | 377
Siemens CM110664en_03
2017-09-18
 7.2 Routing System Events............................................................................ 130
7.3 Sources and Causes of COVs ................................................................. 130
7.4 COV Reporting ........................................................................................ 130
8 Alarm Management ........................................................................... 134
8.1 Alarm Sources ......................................................................................... 134
8.2 Alarm Example ........................................................................................ 136
8.3 Effects of BACnet Properties on Alarm Response .................................... 139
8.4 Alarm Response of the Function Blocks ................................................... 148
8.5 Alarm Functions....................................................................................... 156
8.6 Alarm Management by Notification Class ................................................. 158
8.7 Alarm Routing over the Network .............................................................. 162
8.8 Alarm Queuing ........................................................................................ 165
8.9 Common Alarms ...................................................................................... 166
8.10 Alarm Suppression .................................................................................. 167
8.11 Alarm Message Texts .............................................................................. 169
9 Calendars and Schedulers ................................................................. 171
9.1 Schedule ................................................................................................. 172
9.2 Calendar.................................................................................................. 177
9.3 Wildcards ................................................................................................ 177
9.4 Alarm Messages ...................................................................................... 178
10 Trending .......................................................................................... 179
10.1 Trend Functions....................................................................................... 179
10.2 Editing Parameters .................................................................................. 181
10.3 Processing Trend Data in Desigo CC....................................................... 182
11 Reports............................................................................................ 183
12 Data Storage .................................................................................... 184
12.1 Data Categories.......................................................................................184
12.2 Program Data .......................................................................................... 184
12.3 Libraries .................................................................................................. 185
12.4 Project Data............................................................................................. 186
12.5 Plant Data ............................................................................................... 187
12.6 Data Transfer Processes ......................................................................... 187
12.7 Texts ....................................................................................................... 189
13 Network Architecture ......................................................................... 190
13.1 BACnet Architecture (MLN & ALN)........................................................... 190
13.2 LonWorks Architecture (ALN) .................................................................. 203
13.3 KNX Architecture (ALN) ........................................................................... 205
13.4 KNX PL-Link Architecture (FLN) .............................................................. 206
13.5 DALI Architecture (FLN)........................................................................... 208
14 Remote Access ................................................................................ 210
14.1 Remote Access Methods ......................................................................... 210
14.2 Choosing a suitable Access Technology .................................................. 211
14.3 Technical Details ..................................................................................... 213
15 Management Platform ....................................................................... 214
15.1 User Functions ........................................................................................ 216

4 | 377
Siemens CM110664en_03
2017-09-18
 15.2 Main Components....................................................................................219
15.3 Access and Security ................................................................................220
15.4 Event Management..................................................................................221
15.5 Installation, Setup and Engineering ..........................................................222
15.6 Graphics Libraries....................................................................................224
15.7 Graphics Engineering ..............................................................................225
15.8 Virtual Environment .................................................................................226
16 Automation Stations.......................................................................... 228
16.1 Device Object ..........................................................................................229
16.2 Device Info Object ...................................................................................230
16.3 Error Sources and Monitoring Functions ..................................................231
16.4 Operating States......................................................................................232
16.5 Data Storage ...........................................................................................236
17 Logical I/O Blocks............................................................................. 238
17.1 General Functions ...................................................................................239
17.2 Input Blocks .............................................................................................254
17.3 Output Blocks ..........................................................................................257
17.4 Value Objects ..........................................................................................260
17.5 Value Objects for Operation .....................................................................263
17.6 Addressing the I/O Blocks ........................................................................263
17.7 Discipline I/Os..........................................................................................274
17.8 Reliability Table .......................................................................................275
17.9 Slope [Slpe] and Intercept [Icpt] ...............................................................277
17.10 Addressing entries for PXC…-U, PTM and P-Bus ....................................282
18 Room Automation ............................................................................. 289
18.1 Desigo Room Automation ........................................................................289
18.1.1 Configurable .............................................................................290
18.1.2 Programmable ..........................................................................297
18.1.3 Rooms and Room Segments ....................................................301
18.1.4 Central Control Functions and Grouping....................................302
18.1.5 Desigo Room Automation and the Management Level ..............303
18.1.6 Desigo Room Automation and the Automation Level .................303
18.2 Desigo RXC.............................................................................................303
18.2.1 Product Range Overview ..........................................................305
18.2.2 RXC Applications ......................................................................307
18.2.3 RXC and the Management Level...............................................308
18.2.4 RXC and the Automation Level .................................................310
18.2.5 Mapping LonWorks in the LonWorks System Controller ............310
18.2.6 Groups in the LonWorks System Controller ...............................311
18.2.7 System Functions .....................................................................313
18.3 Desigo RXB .............................................................................................314
18.3.1 Product Range Overview ..........................................................315
18.3.2 RXB and the Management Level ...............................................316
18.3.3 RXB and the Automation Level .................................................316
18.3.4 RXB Applications ......................................................................316
18.3.5 Mapping RXB in the PX KNX System Controller ........................317

5 | 377
Siemens CM110664en_03
2017-09-18
 19 Desigo Open .................................................................................... 318
19.1 Integration on Management Level ............................................................ 319
19.2 Integration on Automation Level............................................................... 321
19.3 Integration on Field Level......................................................................... 323
19.4 Integration on Room Level ....................................................................... 325
20 Desigo S7 Automation Stations........................................................... 326
20.1 Product Range Overview ......................................................................... 327
20.2 System Limits .......................................................................................... 329
20.3 Alarm Management ................................................................................. 329
20.4 Control Concept....................................................................................... 331
20.5 Desigo S7 Block Library........................................................................... 332
20.6 Operating States...................................................................................... 333
20.7 Error Sources and Monitoring Functions .................................................. 333
21 System Configuration ........................................................................ 335
21.1 Technical Limits and Limit Values ............................................................ 337
21.2 Networks ................................................................................................. 338
21.2.1 Desigo Room Automation System Function Group .................... 339
21.3 Devices ................................................................................................... 341
21.3.1 PXC..D Automation Stations / System Controllers ..................... 341
21.3.2 LonWorks System Controllers ................................................... 343
21.3.3 Automation Stations with LonWorks Integration ......................... 344
21.3.4 PX Open Integration (PXC001.D/-E.D) ...................................... 344
21.3.5 PX Open Integration (PXC001.D/-E.D + PXA40-RS1) ............... 344
21.3.6 PX Open Integration (PXC001.D/-E.D + PXA40-RS2) ............... 345
21.3.7 PX KNX Integration (PXC001.D/-E.D) ....................................... 345
21.3.8 TX Open Integration (TXI1/2/2-S.OPEN) ................................... 345
21.3.9 Number of Data Points on Desigo Room Automation Automation
Stations 345
21.3.10 Number of Data Points for PXC3............................................... 348
21.3.11 Number of Data Points for DXR2............................................... 348
21.3.12 PXM20 Operator Unit ................................................................ 349
21.3.13 PXM20-E Operator Unit ............................................................ 350
21.3.14 PXM10 Operator Unit ................................................................ 350
21.3.15 PXA40-W0 Web Controller Option Module ................................ 350
21.3.16 PXA40-W1/W2 BACnet/IP Web Controller Option Module ......... 351
21.3.17 Desigo Touch and Web - PXG3.W100 Web Interface................ 352
21.3.18 PXG3.L and PXG3.M BACnet Routers ...................................... 353
21.3.19 SX OPC .................................................................................... 354
21.3.20 Desigo CC ................................................................................ 354
21.3.21 Desigo Insight ........................................................................... 355
21.3.22 Desigo Xworks Plus (XWP) ....................................................... 355
21.3.23 Desigo Automation Building Tool (ABT) .................................... 356
21.4 Applications ............................................................................................. 356
21.4.1 Peak Demand Limiting (PDL) .................................................... 356
22 Compatibility..................................................................................... 357
22.1 Glossary .................................................................................................. 357

6 | 377
Siemens CM110664en_03
2017-09-18
 22.2 Desigo Version Compatibility Definition ....................................................358
22.3 Desigo V6.1 System Compatibility Basics ................................................359
22.3.1 Compatibility with BACnet Standard ..........................................359
22.3.2 Compatibility with Operating Systems .......................................360
22.3.3 Compatibility with SQL Servers .................................................361
22.3.4 Compatibility with Microsoft Office .............................................362
22.3.5 Compatibility with Web Browsers ..............................................362
22.3.6 Compatibility with VMware (Virtual Infrastructure)......................362
22.3.7 Compatibility of Software/Libraries on the Same PC ..................363
22.3.8 Hardware and Firmware Compatibility .......................................363
22.3.9 Backward Compatibility .............................................................363
22.3.10 Engineering Compatibility..........................................................363
22.3.11 Compatibility with Desigo Configuration Module (DCM) .............363
22.4 When to Upgrade to Desigo V6.1 .............................................................364
22.4.1 Automation Level Desigo PX / Desigo Room Automation ..........365
22.4.2 Desigo TX-I/O ...........................................................................368
22.4.3 TX Open ...................................................................................368
22.4.4 Desigo RX ................................................................................369
22.4.5 Libraries ....................................................................................369
22.5 Upgrade to Desigo V6.1...........................................................................369
22.5.1 Upgrade PX / Desigo Room Automation Automation Level ........370
22.5.2 Upgrade RX Room Automation .................................................372
22.5.3 Upgrade PX (CAS) Libraries .....................................................372
22.5.4 Upgrade Desigo Room Automation Libraries .............................372
22.6 Siemens WEoF Clients ............................................................................373
22.6.1 Desigo Software .......................................................................373
22.6.2 Third-Party Engineering Software..............................................373
22.7 Migration Compatibility.............................................................................373
22.8 Hardware Requirements of Desigo Software Products .............................374
22.9 VVS Desigo V6.1 .....................................................................................375

7 | 377
Siemens CM110664en_03
2017-09-18
 Preconditions of this Document
1

1 Preconditions of this Document

IT security
Building automation and control systems such as Desigo are increasingly
integrated into a building's IT infrastructure and will often also be remotely
accessible. Besides using the IT security features of the various products, it's very
important to implement an IT secure integration into the site's IT infrastructure. For
guidelines for such an IT secure integration, see IT Security in Desigo Installations
(CM110663). These guidelines are binding and must be implemented in every
Desigo project.
Furthermore, the usual rules and best practice procedures from the IT world must
also be observed to achieve a high protection level for the building automation and
control system and the customer's IT infrastructure.

Cyber security disclaimer

Siemens products and solutions provide security functions to ensure the secure
operation of building comfort, fire safety, security management and physical
security systems. The security functions on these products and solutions are
important components of a comprehensive security concept.
It is, however, necessary to implement and maintain a comprehensive, state-of-
the-art security concept that is customized to individual security needs. Such a
security concept may result in additional site-specific preventive action to ensure
that the building comfort, fire safety, security management or physical security
system for your site are operated in a secure manner. These measures may
include, but are not limited to, separating networks, physically protecting system
components, user awareness programs, defense in depth, etc.
For additional information on building technology security and our offerings, contact
your Siemens sales or project department. We strongly recommend customers to
follow our security advisories, which provide information on the latest security
threats, patches and other mitigation measures.
http://www.siemens.com/cert/en/cert-security-advisories.htm

Compatibility with third party products

This document lists various versions of third party hardware and software, Siemens
has tested the listed versions for compatibility with this version of the Desigo
release and was satisfied with the results. Nevertheless, Siemens assumes no
warranty or liability for any compatibility, be it backward, current and under no
circumstances for future versions thereof as such compatibility is extremely
dependent on the interaction of the system as a whole and the different
components interacting. If assurance on compatibility is needed, then please
inquire about a specific maintenance agreement for your system or solution.

9 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Management Level

2 System Overview
The Desigo building automation and control system has three levels:
● Management level
● Automation level
● Field level

Management Management platform Desigo CC

level

Automation System controller Desigo PX

level Automation stations

BACnet/IP

Desigo TRA
Desigo RX

KNX

Field level Sensors Symaro

10660Z36_02_en
Valves Acvatix

Figure 1: System hierarchy

10 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Management Level
2

2.1 Management Level

Operation and monitoring The key functions at the management level are operation and monitoring of the
plant, including:
● Graphics-based operation of the plant
● Cross-site alarm generation and alarm transfer
● Maintenance of a long-term log
● Storage and graphical display of trend data
● Graphics-based operation of time schedules
● Display, navigation and modification of data objects, which are displayed in a
hierarchical tree structure
● Visual monitoring of the operation of primary plants (monitoring to reduce
energy consumption and wear and tear)
● Visual monitoring of the rooms (HVAC, lights and blinds)
● Reporting function including energy reports
● Centralized time control and calendar functions
● Event program: Triggering system reactions based on system events
What is operation and Operation and monitoring encompasses all the interaction between a user and the
monitoring? plant via the building automation and control system.

Task Activity
Observing the operational status of the plant or Reading current values of all process variables, data objects and parameter
building settings
Receiving and acknowledging alarms
Overview of all pending alarms
Recording and analyzing trends

Observing the operational status of the building Overview of failed automation stations and network interruptions
automation and control system Signaling of anormal hardware or software states in an automation station or in
the associated field devices

Manipulating the operational status of the plant or Modifying parameter settings (for example, setpoints of control programs)
building Setting values for physical outputs of automation stations
Modifying system and management objects, especially calendars and time
schedules

Table 1: Operation and monitoring

Devices for operation and The following devices let you operate and monitor the system:
monitoring ● Desigo CC management platform either locally and/or with web operation
● PXM touch panels and operating devices

Operation and monitoring There are four operation and monitoring types:
types ● Generic operation
● Limited (station-specific) generic operation
You can limit the generic view to one or more selected automation stations
(including alarm display).
● Engineered (project-specific) operation
You can generate a project-specific view in the engineering phase.
● Limited (user-specific) operation in Desigo CC
Management platform Desigo CC can be installed on one computer, with full server and client
functionality, or on several separate computers. Web Clients, Windows App
(ClickOnce) Clients and installed Clients can be added.
Remote management Desigo CC can operate and monitor the automation level via a public network.

11 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Automation Level

2.2 Automation Level

The Desigo PX automation system meets all the requirements for the control and
monitoring of heating, ventilation, air conditioning systems and other building
services. Desigo PX with its programmable automation stations and graded range
of operator units is a scalable and open system.

D-MAP programming The starting point for the engineering of the application functions is the range of
language user-friendly application blocks and function blocks in the D-MAP (Desigo Modular
Application Programming) programming language. D-MAP is optimized for
applications for technical building installations and is based on the IEC 1131
standard. The graphical user interface of the Xworks Plus (XWP) [➙ 43]
engineering software ensures an efficient approach.
System functions All PX automation stations have comprehensive system functions, such as alarm
mangement, time schedules, trend histories, time synchronisation, global data
distribution, and life check, that work completely autonomously.
BACnet communication Devices on the automation level communicate with each other and with the
for maximum openness management platform and the operating devices via the BACnet protocol.
The use of BACnet/IP or BACnet/LonTalk underlines the openness of the system
and allows the easy integration of systems and components from third-party
manufacturers.

Automation stations and system controllers

PX Modular The Desigo PX range of programmable modular automation stations provides
maximum flexibility for controlling and monitoring building services. Comprehensive
system functions, such as alarm management, time schedules and trend histories,
meet all requirements for technical building installations.
The PXX-Lxx extension modules let you connect LonWorks devices, RXC room
controllers and third-party devices.
The PXX-PBUS extension module lets you integrate PTM IO modules.
The PXA40-Tx option modules provide functions, such as web operation.
TX-I/O Desigo TX-I/O modules provide the interface between PX Modular and the field
level devices, the actuators and sensors.
A range of configurable and flexible I/O modules are available for signalling,
measuring, metering, switching and controlling.
Some modules can be manually operated according to ISO 16484, and have an
LCD display with configurable LEDs.
The integrated isolating-terminals facilitate the hardware test during commissioning.
TX Open TXIx.OPEN lets you integrate third-party systems, such as M-Bus meters, pumps
(Grundfos, Wilo) and variable speed drives (Siemens G120P), and connect
intelligent aggregates, for example, chillers, via the Modbus protocol.
PX Compact The Desigo PX range of programmable compact automation stations with
integrated I/Os provides optimized solutions for small to mid-sized technical
building installations. Comprehensive system functions, such as alarm
management, time schedules and trend histories, meet all requirements for
technical building installations.
PX Compact with island The easy to install PXC22.1…D and PXC36.1…D compact automation stations
bus offer increased flexibility due to the island bus.
Properties:
● Up to 52 physical I/Os
● Integration of up to 5 subsystems, such as Modbus, M-bus, with up to 400 data
points

12 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Automation Level
2

PX Open PX Open system controllers let you integrate third-party devices via Modbus, M-
Bus, KNX and other protocols. System functions, such as alarm management, time
schedules, trend data storage and flexible programming are available.

Operating devices
The various operator units cover all the various requirements in terms of location
and function.
PXG3.W100 web interface The PXG3.W100 web interface lets you operate and monitor PX automation
stations that are engineered in the PXG3.W100. It is the system interface for the
PXM40/50 touch panels. It allows the homogenous operation on-site via PXM40/50
and remotely via a standard web browser.
PXM40 and PXM50 touch The PXM40 (10,1") and PXM50 (15,6") touch panels let you operate several PX
panels automation stations and monitor technical building installations in technical rooms.
The touch panels can be mounted in control cabinets. They are used in
combination with the PXG3.W100 web interface. Its user interface is optimized for
touch handling. If a fault occurs, a text message or email can be sent via a PXC
Modular (IP version).
PXM20/PXM20-E network The network capable PXM20 and PXM20-E operating units let you operate PX
capable operating units automation stations connected to a BACnet network.
PXM10 local operating The PXM10 operating unit lets you locally operate the PXC automation station it is
unit connected to. The device has a user friendly single button operation with an LCD
display.
PX Web The web solution in PXC Modular (BACnet/IP) together with the PXA40-Wx
optional module allows the generic operation of all values of the PX automation
stations from a web client. If a fault occurs, text messages or emails can be sent.
You can set up a graphical operation with a supplied tool.
See Desigo PX Automation system for HVAC and building services - System
overview (CM110756).

13 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Room Automation

2.3 Room Automation

The room automation is part of the automation level. The room automation
includes devices for the control functions within a room.
There are RX room controllers and Desigo Room Automation PXC3/DXR2 room
automation stations.
The PXC3/DXR2 room automation stations have the following functions:
● Measuring, controlling and processing of I/O signals
● Logging trend data
● Monitoring process variables and generating alarms
● Acknowledging and resetting alarms
● Monitoring process variables for value changes
● Exchanging data with clients and other automation stations
● Monitoring hardware and software functions and generating events in case of
faults or errors
● Processing BACnet access for operation and monitoring of one or multiple
clients
● Handling errors, for example, during data point exchange
The PX automation stations carry out coordination functions (Desigo Room
Automation system functions), such as time synchronisation, life check, scheduling,
etc., for the room automation stations.
Desigo supports the following communication technologies:
● BACnet
● KNX technology
● DALI (Digital Addressable Lighting Interface)
● LonWorks technology (only for RX)

Desigo Room Automation (PXC3..)

In Desigo Room Automation freely programmable PXC3 room automation stations
control the room climate. The Desigo Room Automation product range integrates
several disciplines (HVAC, lighting, shading). A room automation station can cover
several rooms. The room automation stations are integrated seamlessly into
Desigo PX and the management level via BACnet/IP.
Buttons, sensors, and actuators are connected to the PXC3 room automation via
TX-I/O modules or KNX PL-Link modules.
The KNX interface of the PXC3 room automation stations allows the direct
integration of devices with KNX PL-Link and KNX S-Mode in Desigo Room
Automation. KNX PL-Link is fully compliant with the KNX standard. The PXC3
room automation stations support plug and play functionality with automation
device detection. Devices with KNX PL-Link are parameterized with the Desigo
tools. The KNX commissioning software (ETS) is not needed.
The PXC3.. room automation stations have an integrated web server for IP
communication with QMX7.E38 touch room operator units. Engineering access is
available via the web interface.
A subset of the available TX-I/O modules can be used with the PXC3 automation
station.
The DALI (Digital Addressable Lighting Interface) bus of the PXC3...A room
automation station lets you integrate lighting.
The PXC3.E16A room automation station is tailored for lighting applications. It has
an on-board DALI interface for integrating up to 64 ECGs (electronic control gear).

Desigo Room Automation (DXR2..)

The DXR2 room automation stations let you automate heating, ventilation, air
conditioning, shading, and lighting for rooms.

14 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Desigo Open
2

The room automation stations communicate with each other and other system
components via BACnet/IP (DXR2.E…) or BACnet MS/TP (DXR2.M...).
The room automation stations support different I/O mixes, protocols (KNX S-Mode
and KNX PL-Link for IP and KNX PL-Link for MS/TP) and power supplies
(240/24V). Operating devices, buttons, sensors, and actuators for lighting and
shading can be connected to the room automation stations via KNX PL-Link.
The room automation stations contain preloaded applications, but are also freely
programmable. A comprehensive library of proven, standardized applications is
available.
The DXR2.. room automation stations have an integrated web server for IP
communication with QMX7.E38 touch room operator units. Engineering access is
available via the web interface.

Desigo RXC and RXB

The RXC and RXB room controllers control the room climate in individual rooms
and important parameters of the applications can be configured.
The RXC room controllers and the bus room operator units (QAX50/51)
communicate via LonWorks. The RXB room controllers communicate via KNX.
The LonWorks system controller (or a modular PXC50/100/200..D automation
station) or the PX KNX system controller connects the room automation devices to
Desigo PX and the management level and assumes coordination functions for
room automation (grouping, scheduling, demand signal exchange, peer-to-peer,
etc.).

2.4 Desigo Open

Desigo Open lets you integrate devices and systems from different manufacturers
into the Desigo system.
Desigo Open supports various protocols, for example, OPC, Modbus, KNX/EIB,
LonWorks, M-Bus, KNX, DALI, etc. for integrating energy monitoring, fire security,
access control and security, power distribution, refrigeration machines, pumps,
meters, variable speed drives, ligthing and blinds, etc.
Regional companies can use Software Development Kits (SDKs) to develop their
own solutions.
Integration on the Desigo CC uses BACnet, Modbus, OPC, S7 Ethernet, SNMP, and RESTful web
management level services to exchange data with third-party systems.
SX Open is a configurable third-party system - BACnet/IP gateway that allows the
data exchange between third-party systems and the Desigo system in an IP
network.
Integration on the PX Open system controllers let you integrate third-party devices on Modbus, M-
automation level Bus, KNX and other protocols, by converting all data into standard BACnet objects.
Integration on the field TXIx.OPEN lets you integrate third-party systems, such as M-Bus meters, pumps
level (Grundfos, Wilo) and variable speed drives (Siemens G120P), and connect
intelligent aggregates, for example, chillers, via the Modbus protocol.

2.5 Workflow and Tools

The Desigo tools cover parts of the technical process and parts of the Desigo
system:
● Desigo Configuration Module (DCM) lets you plan the system and determine
the quantity during the sales phase.
● Xworks Plus (XWP) lets you engineer, commission and service Desigo PX
system components.

15 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Workflow and Tools

● ABT Pro and ABT Site (Automation Building Tool) let you engineer,
commission and service Desigo Room Automation (BACnet) system
components.
● RXT10 lets you commission and service RXC room controllers.
● PX KNX-Tool lets you commission and service PX KNX.
● Desigo CC Graphics Generator lets you automatically generate Desigo CC
plant graphics using information from the System Definition Unit (SDU) and
XWP.
● System Definition Unit (SDU) lets you define application texts in different
languages.
● PX Open MONITOR lets you debug PX Open programs.
● TX Open tool lets you configure and commission TX Open modules.
● BIM tool lets you:
– Commission TX-I/O modules and the Bus Interface Modules (BIM)
– Simulate programs without I/O modules on the test rack
– Configure the colors of the I/O status LED on the TX-I/O modules
● Desigo Automation Level Migration Tool lets you copy engineering parameters,
such as I/O addresses, texts, data point parameters, PID controller parameters
and trend objects, of a Visonik controller to a PX automation station.
● Desigo Point Test (DPT) lets you test data points for field devices and PX
automation stations during commissioning.
Preloaded applications Some automation stations contain preloaded applications, but are also freely
programmable. A comprehensive library of proven, standardized applications is
available and can be used instead of the preloaded applications.
XWP to PXC XWP communicates with the PX automation station via BACnet/IP or
communication BACnet/LonTalk. The CFC or Parameter Editor can communicate online with the
PX automation stations. This is a useful aid both for commissioning and testing the
automation stations, and for operation and monitoring. The pin values and some
attributes of the compounds and blocks can be modified online.
To commission a Lon-based PX automation station, XWP must be connected to
the same LonWorks network as the automation station. The program or program
changes can be downloaded via BACnet router or PTP connection, which can also
be used for monitoring and operation. The functionality to configure and
commission the BACnet router is integrated in the XWP Network Configurator.

16 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Topologies
2

2.6 Topologies
Small system
Web client

PXM40/50
Touch panel
BACnet/IP
Ethernet

PXC50/100/200-E.D TXM1.. TXI.. PXG3.W100

PXC12/22/32-E.D Modular TX-I/O TX Open Web interface
Compact

PXM10 Integration

Figure 2: A typical small system on BACnet/IP

PXM20

BACnet/LonTalk

PXC50/100/200.D TXM1.. TXI..

PXC12/22/36.D Modular TX-I/O TX Open
Compact

Integration
Figure 3: A typical small system on BACnet/LonTalk

17 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Topologies

Medium system
Desigo
Management station

Web clients PXM40/50

Desigo touch panel

BACnet/IP 10660Z35en_01

Ethernet

PXC50/100/ TXM1.. TXI..

200-E.D TX-I/O TX Open
PXG3.L PXG3.W100
Modular Router Web interface PXC001-E.D
PXC12/22/36-E.D PXC001-E.D
Compact System controller System controller

Integration Integration
PXM10
Operator unit BACnet/LonTalk

TXI..
TX Open

PXC12/22/36.D
Compact KNX

Integration

DXR2.E...

Third party RDF/RDG

devices QAX5... Thermostat

°C

°C

QMX3 AQR25..
Room units Room
sensor

Figure 4: A typical medium system

Large system
E-Mail

Desigo
Management station

PXM40 / 50
Web clients Desigo touch panel BACnet
Third-party system
@

DSL-
BACnet/IP Modem 10660Z34en_01

DSL-
Modem
PXC50/100/ TXM1.. TXI..
200-E.D TX-I/O TX Open
PXG3.W100 PXG3.L PXG3.M BACnet
Modular Web interface Router Router Third-party
PXC12/22/36-E.D PXC001-E.D PXC001-E.D integration
Compact System controller System controller
Third-party
PTM-I/O integration PXC50/100/ TXM1..
Modules 200-E.D TX-I/O
integration
PXM10 Modular
Operator unit BACnet/LonTalk

Sinteso
DXR2.E CERBERUS PRO

PXC12/22/36.D
Compact BACnet MS/TP

Desigo TRA

PXC3... TXM1..
Modular TX-I/O
Third party RXB DXR2.M DXR2.E...
devices QAX5...
DALI
KNX

Third-party QMX7.E38 Touch

devices room operator units

KNX

° C ° C ° C

° C ° C ° C

RDF/RDG QMX3 AQR25.. QMX3 AQR25.. AQR25.. GAMMA pushbutton,

Thermostat Room units Room Room units Room Room presence detector etc.
sensor sensor sensor

GLB/GDB...1EKN RXM21/39.1
VAV compact controller Fan coil unit I/O boxes

Figure 5: A typical large system

PX site
PX site is a means of structuring large PX projects. Desigo room automation
stations are not part of a PX site.

18 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Communication Principles
2

In a PX site one PX automation station is defined as the primary server and all
other PX automation stations are defined as backup servers. Every automation
station can be defined as the primary server.
The primary server carries out system functions, such as time synchronization, life
check and the distribution of global data:
● Time synchronization: The primary server distributes the current time to the
backup devices.
● Life check: The backup servers detect the failure of the primary server and the
primary server detects the failure of the backup servers. If a server fails, an
alarm message is sent. If the primary server fails, another automation station
must be defined manually as the primary server.
● Distribution of global data: Global objects are available on all PX automation
stations. The primary server synchronizes changes, for example, calendar
object, notification class object, that are made on the primary server to the
backup servers.
Handling a PX Site in When an operating device starts, it searches for all primary servers and offers a log
Desigo clients in to the PX site.
A Desigo CC site can contain several PX sites and third-party devices. Desigo CC
registers itself as a global alarm recipient for the PX site on the primary server.

2.7 Communication Principles

Desigo uses open communications to connect various technical building systems
based on open and standardized data interfaces:
● BACnet is used from room automation to the management level
● KNX®, DALI, EnOcean® and LonWorks® are used in room automation and
decentralized secondary processes
● M-bus, Modbus, OPC, MS/TP, and other interfaces are used for connecting
third-party devices and systems
BACnet BACnet (Building Automation and Control Networks) is a communications protocol
for building automation and control networks. BACnet ensures the interoperability
between devices from different manufacturers. See
http://en.wikipedia.org/wiki/BACnet.
VendorID Each BACnet device has a VendorID to identify the manufacturer. The VendorID
for the Siemens BACnet system devices is 7.
BACnet over Ethernet/IP Applications on the management level can interact via standard IT network
services concurrently to BACnet services.
Desigo supports BACnet/IPv4 and BACnet/IPv6 (via PXG3.M/L router). IPv6 to
IPv4 is NOT compatible. The parallel operation of IPv4 and IPv6 is possible with
the use of a PXG3.L/M BACnet router. See http://de.wikipedia.org/wiki/IPv6.
Network performance The performance of the network depends on the following criteria:
● Number of devices on the bus
● Segmentation of the topology via routers (for LonTalk bus)
● Number of simultaneously active clients
● Peer-to-peer communication resulting from distributed PX applications
● Other communications services using the same transmission medium, where,
for example, office communication on a separate VLAN share the same IP
trunk
● Application download on the network
Due to these factors, which can vary widely from project to project, it is not possible
to make any generalized statements about network performance. If the specified
product quantities are adhered to, performance is adequate.

19 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Communication Principles

If the network performance is not satisfactory, the following actions may help:
● Use the same automation station for items of equipment with frequent process
interaction.
● Divide the network into segments via BACnet router and an Ethernet/IP
backbone.
● Isolate the automation station from the network when downloading an
application.
BACnet and IP network BACnet supports various application services which are transmitted to all BACnet
structuring devices (broadcasts). Global broadcasts are blocked by the IP router. BACnet
solves this problem by using a BACnet Broadcast Management Device which
ensures that IP broadcasts only appear in one IP segment. The logical BBMD
functionality can be configured in every BACnet router and in every PX automation
station with BACnet/IP. One BBMD can be configured per BACnet/IP port. Devices
with BBMD must have a static IP address.
BACnet over MS/TP MS/TP stands for Master Slave / Token Passing. Each device on the link is
considered the master when it has the token. If it does not have immediate need to
use the token, it passes the token along to the next device. All devices on the link
which do not currently have the token are regarded as slaves, and listen to any
messages the current master may have for it. As all devices take turns being
master, the link is effectively peer-to-peer.
Use of other network IP networks (besides the other technologies mentioned above) provide the network
technologies infrastructure Desigo devices are connected to. In case a Desigo installation is
spatially distributed (for example, several buildings on a campus, multiple branches
in a country) the connection of these local IP networks (LANs) normally is done
using a Wide Area Network (WAN) or a point-to-point transmission line. These can
be based on non-IP technologies but typically are transparent for IP traffic. In this
way, all the BACnet devices connected via an IP network can communicate with
each other.
Client/Server A BACnet device can assume two different roles within a system, the role as a
server and the role as a client. These roles are defined as follows:
● Client: A system or device which uses another device via a BACnet service
(service request) for a specific purpose. The client (for example, Desigo CC,
operator unit) requests a service from a server.
● Server: A system or device which responds to a given service request. The
server (for example, PXC automation station, Desigo Room Automation room
automation station) performs a service for a client.
Most system devices in Desigo can act either as a client or as a server, but they
normally each carry out their more typical role. An automation station is normally a
BACnet server, which supplies process data to other system devices. The
automation station can also act as a client, when it, for example, subscribes to a
process value from another automation station.

20 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Communication Principles
2

BACnet server BACnet client

D-MAP program

Process and
configuration Application
data process
(Visualisation)

BACnet objects

10660Z37_01_en
BACnet protocol

Figure 6: Client/Server roles distribution

BACnet standard device The BACnet standard defines several device profiles that simplify to judge (and
profile test) a device's capabilities against a specified function set. Desigo always tries to
work with such profiles and prove their fulfillment by independent test laboratories
and respective BTL logos and BACnet certificates.
● The PXC3 and DXR2 room automation stations comply with the B-ASC
standard device profile.
● The PXC automation stations comply with the B-BC standard device profile.
● The Desigo CC management platform complies with the B-AWS standard
device profile.
For a complete list with additional details, see BACnet Protocol Implementation
Conformance Statement (PICS) (CM110665) and the products page of the BIG-EU
website (www.big-eu.org).
BACnet protocol version Desigo is based on BACnet protocol versions 1.12 and 1.13:
● Desigo CC is based on version 1.13.
● The PXC3 and DXR2 room automation stations are based on version 1.13.
● The PX automation stations are based on version 1.12.
● PXM20 are based on version 1.12.

In BACnet, it is the BACnet client which ensures the backwards compatibility. As

a rule of thumb, a management platform should thus have a BACnet revision that
is at least the same as all of its connected BACnet servers.

AMEV guideline Desigo complies with the AMEV guideline BACnet 2011 Version 1.2 with the
following profiles:
● Desigo CC: AMEV profile MOU-B
● Desigo PX: AMEV profile AS-B

21 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Data Maintenance

Desigo room automation BACnet is used to exchange information between PX automation stations and
DXR2 and PXC3 room automations stations and the management platform.
Desigo RX The Desigo RXB room automation range communicates via KNX S-Mode (EIB)
and the RXC room automation range communicates via LonWorks standard.
Restrictions for LonWorks A LonWorks network cannot be segmented with LonWorks routers, as the
message length for BACnet is 228 bytes for performance reasons. Commercially
available LonWorks routers do not have sufficiently large buffers for this length. No
other media (power lines, infrared, etc.) can be used either.

For performance reasons, we do not recommend the operation of LonWorks and

BACnet devices on the same LonTalk cable.

2.8 Data Maintenance

A running Desigo system contains various categories of data, each with different
requirements in terms of consistency, period of useful life and visibility. The data is
distributed throughout the system, with each category having a unique origin.
There is no central data maintenance in the Desigo system. The system data is
distributed on all devices throughout the network, but is primarily located in the
automation stations.
During the sales, planning, engineering and commissioning phases, project data is
created. Part of the data is loaded into the system, while another part is tool-
specific and used, for example, for documentation of the project.
System data is:
● Process-data and parameter settings
● Archived data
● Configuration and description data
● Metadata
● D-MAP program
● Graphics and masks
● Libraries
● Offline trend object values

Process-data and parameter settings

Process data Process data is data generated by the physical process in the building using a
process control algorithm. Process data represents the process variables, such as
a temperature or a damper position.
Parameter settings Parameter settings are function parameters, settings, setpoints, etc. which are
defined for each plant or project and which affect the way in which an application
works. Parameter settings can be modified during operation.
Process data and parameter settings can be accessed within the system via
BACnet objects, for example, Present Value [PrVal] and Status [StaFlg], if the
associated mapping is enabled in the engineering phase.
If process data is used by several automation stations, the data origin is the
location where the physical variable is measured (for example, outdoor
temperature) or generated (for example, the control signal from a time schedule).
Copies are updated on an event-driven basis after a short delay.
To display process data and parameter settings mapped to BACnet on clients, only
one copy of the data needed for current operation and monitoring is stored. The
Desigo system does not store complete copies of process data or parameter

22 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Data Maintenance
2

Displaying process data settings. The data (copy) required by a client is normally updated via the BACnet
and parameter settings protocol on an event-driven basis and with a short time delay.
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 The majority of the process data is volatile data, which is recalculated when the
process data and automation stations are restarted. However, certain process data is retained even
parameter settings after an automation station restart, for example, 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, for example, 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. For example,
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, for example, 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 (for example, 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.

23 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Data Maintenance

Metadata
Metadata is project-independent data from standard BACnet objects (for example,
analog input, schedule, etc.) which needs to be known by a tool or a client, for
example, 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.

D-MAP program
The D-MAP program is an executable program, and contains instances of the
function blocks with the associated process data and parameter settings, the
configuration and description data and the interconnection and order of processing
of function blocks.
The D-MAP program can be modified during operation either by reloading the
complete program including any changes, or by delta (differential) loading. Delta
loading only reloads the changes.
The D-MAP program is generated in XWP/ABT from the information in the program
charts, compiled and downloaded into the automation station.

Libraries (LibSet)
The Desigo Library Set (LibSet) is a set of mutually interdependent libraries that
belong to a given Desigo system version.

ABT PXC PXC00(-E).D

Solution Library TRA PXX-L11/12
Preconfigured PXC3
Application functions
Charts
Function blocks
Inputs & Outputs
Networked devices
Firmwareblocks
Text catalog
E.g. global texts as: Firmwareblocks
- TD short name
- TD descriptions
- ...

RXB PX KNX RXC

Firmwareblocks

* For RXB Applications:

PXC00-U with dedicated
firmware version and
option modul PXA30-K11
needed. No I/O modules PXE
possible.

Figure 7: Libraries (LibSet)

The library contents are continuously extended. Every LibSet Extension of Desigo
(LED) is a comprehensively tested collection of solutions covering all the
necessary parts of the Desigo system.
The LibSet version number defines which LED runs on which system version. The
first part of the version number represents the applicable system version.
A LED includes the latest library per automation station type (PXC, PXC00(-E).D,
PXX-L11/12, PXKNX) for the latest Valid Version Set.
New LEDs are delivered at regular intervals. The individual LEDs are consecutively
numbered (LED0 to LED16).

24 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Data Maintenance
2

LibSet version number Version number DESIGO Libset counter: 02,04,06,08,10...

DESIGO-LibSet-HQ-230020-02

System version (for example, 230 for DESIGO V2.3)

Figure 8: LibSet version number

Desigo LibSet consists of various libraries for all system levels:

● Shared text library for PXC, PX KNX, PXE, PXR
● PXC library
● PXKNX library (RXB)
● PXE library
● PXE SCL library (Structured Control Language)
● PXR library
● RXC library
● Library to monitor primary plants
● Library for collaboration between Desigo PX and Desigo Room Automation
● ABT library (Desigo Room Automation Solution Library)

LibSet version number When a LibSet version number is released (new LED), the incremental part of the
and LED version number is increased accordingly, for example: Desigo-LibSet-HQ-410080-
10 > Desigo-LibSet-HQ-410080-20
The remaining numerical values in the decade (for example, 11 to 19) can be used
by the RCs for localization versions.
If the version number changes, the LibSet number is reset to 10 again. If the scope
of the Desigo application changes, the LED number is also incremented, for
example: LED02 > LED03
The following table shows the relationship between LED and LibSet version
numbers and an overview of current and planned application content for the
Desigo LibSet.

LED Description LibSet version number Date

LED00 Basic application content for LibSet Desigo LibSet-HQ-220031-02 August 2003

LED01 PXC: Additional applications for ventilation and heat generation Desigo LibSet-HQ-220031-04 October 2003
and distribution

LED02 All RXC applications for refrigeration generation and distribution Desigo LibSet-HQ-220041-02 December 2004

LED03 PXC: Applications for refrigeration generation and distribution Desigo-Libset-HQ-220041-06 March 2004
RXC: Additional combined applications (INT..)

LED04 PXC: Air quality and domestic hot water applications and recovery Desigo-Libset-HQ-220041-08 June 2004
function after power failure

LED05 RXB room automation Desigo LibSet-HQ-230010-02 September 2004

PXC: District heating application
Temperature cascade / Humid supply air control
Field test version for peak load program

LED06 PXC: Additional applications for ventilation and domestic hot water Desigo LibSet-HQ-230010-02 January 2005
Desigo Insight: Update to genie library for Visonik, Unigyr and
Integral

LED07 PXC: Additional solutions for ventilation facilities, refrigeration Desigo-Libset-HQ-230010-06 November 2005
plants, heating functions, heating plants and universal functions

LED08 PXC: Like LED07 and compounds for QAX, RX Desigo-Libset-HQ-235040-02 November 2005
DI: Genies for lab management integration
PXR: Compounds for Lab Management integration

25 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Data Maintenance

LED Description LibSet version number Date

LED10 PXC: Heating degree days, three-point actuator, storage Desigo-Libset-HQ-235040-04 July 2006
management, adjustment of humidity control

LED11 Like LED10 and RXB and RXL integration solutions Desigo-Libset-HQ-236040-02 July 2006

LED12 PXC: Solution for combined heating/cooling circuit, room model, Desigo-Libset-HQ-237030-02 February 2007
quality monitoring of control circuits, leakage suppression Desigo-LibSet-HQ-236050-04
PX/KNX: New integration compounds

LED13 PX Open compounds Desigo-LibSet-HQ-237070-02 December 2008

LED14 PXC: Additional applications for ventilation facilities, Desigo-LibSet-HQ-400210-10 March 2009
heating/refrigeration circuit, heating circuit
Heat storage tank and trend

LED15 PXC: Energy-efficient application AirOptiControl for ventilation and Desigo-Libset-HQ-410090-10 April 2010
air conditioning plants
Compounds to integrate Grundfos and Wilo pumps

LED16 PXC: CAS21 (HVAC) Desigo-Libset-HQ-500204-10 March 2012

Compound for Desigo Room Automation demand signals,
compounds for pumps and fans based on PTM16.xx
PXC: CRS01 (Collaboration Room Solutions)
Compounds for Desigo Room Automation collaboration
PXC: MON01 (Eco monitoring)
Monitoring compounds und standard solutions for monitoring
primary plants
ABT (Desigo Room Automation):
- TRA02_V5.0_HQ_ABT1.0 (for firmware TRA V5.0)*
- TRA03_V5.0_HQ_ABT1.0 (for firmware TRA V5.1)*
Basic library for integrated Desigo Room Automation room
solutions (HVAC/Lighting/Shading)
-TRA01_QMX3V5.0_V5.1_HQ_ABT1.1 (firmware TRA V5.1)*
Like TRA02/TRA03_V5.0_HQ_ABT1.0 (see above) plus room
units QMX3.P34, QMX3.P34, QMX3.P37, QMX3.P02 with V5.0
functionality like with QMX3.P36

LED17 PXC: CAS22 (HVAC) Desigo-Libset-HQ-500260-10 October 2012

Integration variable speed drive G120P

LED20 PXC: Desigo-Libset-HQ-510xxx-10 Summer 2013

Ventilation & air conditioning: Extensions for night ventilation,
room temperature monitoring, predefined trend objects, timer
function, temperature and humidity control, outside temperature
controlled heating and cooling function, fire control
Heating: Extensions for hot water coordinator.
PX KNX: CAS09
Integration RDG/RDF/RDG
ABT (Desigo Room Automation):
- TRA01_V5.1_HQ_ABT1.1 (for firmware TRA V5.1)*
VAV application extensions, chilled ceiling and fan coil application,
boost heating and optimum start/stop, air quality applications,
extended support for QMX3/AQR25

LED21 PXC: Desigo-Libset-HQ-51SPx-10 March 2014

- MON Library changed Compounds:
SetRlb-Pin at KPI is set, if there is invalid information
- This state is displayed in EcoViewer, All Observers are now
changed to reduced I/Os
ABT:
- TRA03_V5.1SP_HQ_ABT1.1
- Extended support for QMX7

26 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Views
2

Table 2: LibSet version number and LED

Key:
* The PXC3 room automation station supports several firmware versions independent of the
functional content of the application library.

Desigo CC The application libraries for Desigo CC are delivered as extension modules for the
respective system versions. For information about compatibility, see Desigo CC
System Description (A6V10415500).

2.9 Views
There are four views:
● Technical view
● User view
● System view
● Program view

PXM20
10523Z05en_01

Site

BACnet
objects

Technical View Technical View

Technical View Blinds

Room protection
Storen1
Storen2
Storen3
Storen4

Figure 9: The technical, user, and program view in the building automation and control system

Technical view
The technical view illustrates the technical building services equipment, such as
HVAC systems and associated elements, in the building automation and control
system. The technical view is always present and can be used as a substitute for
the user view if the user does not have his own user designation.

User view
Freely defined and The user view is optional in a project. The user view is based on user designations,
structural user view for example: PL7’FL3’ELE”HEAT.STPT
The structure and syntax of the user designations can be defined for each specific
project and customer. Example of a structure: Installation/building/room/plant
element/signal
User view via the User Desigo supports different user views, depending on the application:
Designation (UD) In Xworks Plus (XWP) a User Designation (UD) can be entered for function blocks
or compounds in addition to the Technical Designation (TD) and description. This

27 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
2 Views

entry is carried through in the system and can be evaluated by clients. The UD
allows customers to use their own preferred designations for the plant without
changing the technical structure. The UD can be used in the management platform
in addition to the TD. The detailed view in the PXM20 operator units shows the UD
as information.
User Designation for You can define the user view for Desigo Room Automation as follows:
Desigo Room Automation ● Define a structure for the user view
● Copy Desigo Room Automation objects into the user view
● Define UDs that can be used as object names

System view
The system view shows the standard system hierarchy (BACnet view):
● Network, topology
● Device and third-party device view
● Flat representation (no hierarchy) of all BACnet objects in one device
The system view provides access to all BACnet devices (including third-party
BACnet devices) and all BACnet objects. A third-party client displays this view of a
PX device.
The system view is used in the PXM20 only for third-party devices.

Program view
The engineering and program view corresponds to the XWP/ABT view. The
structure is matched to the automation station. Within an automation station, the
view is program oriented: nested CFC charts (compounds) and function block
instances.

Views and users

The views reflect the differing needs of their users. The following table shows the
users of the system and the type of view each might prefer.

Per User Technical view User view System view Program view
1 Operator (without technical Main view Main view No access No access
training)

2 Operator (with technical training) Main view Main view Occasionally No access

3 Engineer (Desigo CC), User Main view Main view Occasionally No access
(PXM...)

4 Service engineer, Siemens Main view Rarely Rarely Main view

service engineer

Table 3: Views and users

Flexible object name / device ID engineering

You can flexibly generate the object name during engineering in XWP. This is
called the Free Designation (FD). However, the FD has no inherent hierarchical
structure, which makes it tedious to engineer and lowers its helpfulness to orientate
in larger buildings. It should thus be considered as a naming type for very special
purposes only.

Flexible object name engineering causes a greater engineering effort and must
thus be requested specifically by the customer.

Each BACnet object has an object name for identification on the BACnet network.
This object name must be unique within the automation station. The Technical
Designation (TD) is used as default for the object names. The TD is a technical

28 | 377
Siemens CM110664en_03
2017-09-18
 System Overview
Views
2

identifier and is used to identify the plant and associated elements in the technical
view.
You can select how the object name is created for each standard BACnet object.
This especially applies to BACnet multivendor projects, where a special object
name structure is required.

Flexible name selection (TD, UD, FD)

for each object

Technical Designation (TD) ObjectName = TD

B’Ahu10'TSu B’Ahu10'TSu

User Designation (UD) ObjectName = UD

Areal_Geb1'L10-B01 Areal_Geb1'L10-B01

Free Designation (FD) ObjectName = FD

My’’Crazy/Name1 My’’Crazy/Name1

Figure 10: Object name engineering

Defaults and rules The following defaults and rules apply when you engineer the object name in the
XWP Hierarchy Viewer:
● The Free Designation (FD) can be max.69 characters.
● Only ISO-Latin-1 code points from [32..127] and [160..255] may be used. This
excludes all characters from [0..31] and [128..159]. These ISO-Latin-1 code
points are identical to Unicode code points.
● No lead or post blanks [32] may exist and object names containing only blank
characters are not possible.
The FD values and the object name selection are transferred automatically to the
automation station or exported to the management platform during compiling or
loading in the CFC.
The CFC Editor checks during compilation if the object name is unique for each
automation station under the following rules:
● The same resulting object name may exist only once per automation station.
This also applies to the device object that must be unique in the BACnet
internetwork.
● The resulting object name may not correspond to a TD of another object in a
Device. The TD is used to resolve BACnet references.
Exceptions for object Object names cannot be engineered in CFC charts or compounds. These elements
name assignment always define the TD and the object name is always the same as the TD.
Special blocks, such as Heatcurve and Discipline I/Os generate reduced value
objects in the background whose object name per default is the TD during
compilation.
Free definition of the The device ID (the object ID of the device object) can be freely defined. Range:
Device ID 0…4'194'303

29 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Coverage of the Technical Process

3 Desigo Workflow, Tools and Programming

The Desigo tools cover parts of the technical process and parts of the Desigo
system.
Main tools The most important tools are:
● Desigo Configuration Module (DCM): For designing the Desigo system in the
sales phase
● Xworks Plus (XWP): For engineering, commissioning and servicing Desigo PX
system components
● Automation Building Tool (ABT): For engineering, commissioning and servicing
Desigo room automation system components
Special tools There are also special tools, for example:
● Tools for configuring and commissioning specific product families, such as
RXT10 for the configuration of room devices on LON
● Tools for specific tasks, such as the AL Migration Tool for the migration of
legacy system components to Desigo PX
See Automation level migration, Engineering manual (CM110776).

3.1 Coverage of the Technical Process

The Desigo tools are used in the technical process, especially for designing the
system in the sales process, for engineering, commissioning, and servicing. The
tools have interfaces to specific tools of the regional companies, such as tools for
designing electrical wiring diagrams.
Which processes do the The Desigo tools cover the entire technical process from sales to service:
tools cover? ● Sales
● Planning
● Engineering
● Installation
● Commissioning
● Service
For service operations the Desigo tools support remote data access to project data
via Branch Office Server (BOS). SSP provides the service platform.

Figure 11: Technical process

Europe Sales Planning Engineering Installation Commissioning Service

STST •

DCM •

XWP • • • •

ABT • • • •

Table 4: Coverage of the technical process by Desigo tools

30 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Coverage of the Technical Process
3

USA Sales Planning Engineering Installation Commissioning Service

STST •

DCM •

ABT • • • •

Apogee tools • • • •

Desigo tool • • •

Table 5: Coverage of the technical process by Apogee and Desigo Tools

Sales DCM supports system design and quantity determination during the sales process.
Price calculation, offer preparation and tracking, and invitation of tenders are
supported by country-specific tools.
Planning The planning tools are country-specific and comprise the following:
● Network planning, design and documentation
● Cable planning and design (network cables, field device cables)
● Texts for equipment plates
● Building planning (system components in the building, room segmentation)
● Plant planning and documentation (plant schematics, function description)
● Planning of the groupings for Desigo Room Automation
● Order lists
Engineering Most of the Desigo system components are engineered offline, before they are
commissioned. This way you can verify and document the configuration (for
example, for the uniqueness of addresses), and define work packages for
subcontracting.
XWP and ABT are Desigo engineering tools and allow the following:
● Engineering the primary equipment, room automation, BACnet router
● BACnet references for the integration from/to third party systems
● Interfaces to ElektroCAD, Pharma Validation
● Exports for documentation
● Export for engineering in Desigo CC
The tool export:
● Generates information for illustrating the generic operation (technical hierarchy,
User Designation hierarchy)
● Contains information for efficiently generating graphics (mapping functions to
symbols and graphic templates in Desigo CC).
Installation XWP and ABT allow the following:
● Creating order lists that can be used for ordering the devices
● CAD export for connecting to ElektroCAD for designing control cabinets
● Parallel working of several subcontractors/engineers in a project
● Creating pack and go's for commissioning and the point test for subcontractors
● Loading configurations
● Creating commissioning data point lists
Commissioning XWP and ABT allow the following:
● Commissioning of the systems (loading programs, program function test)
● Online trending during commissioning
● Diagnostics during commissioning
● Parallel working of several commissioning engineers in the project
Service XWP and ABT allow the following:

31 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Coverage of the System

● Data access to Branch Office Server (central engineering data management of

the regional companies)
● Data security (reading system data in the engineering database)
● Remote engineering and operating, diagnostics and error recovery via an
external network connection

3.2 Coverage of the System

The Desigo tools cover all levels of the Desigo system except the management
level:
● Xworks Plus (XWP) covers Desigo PX.
● Automation Building Tool (ABT) covers Desigo Room Automation.

Tools for Desigo PX The following tools are used for Desigo PX:
● DCM: For designing the system and determining the necessary quantities
● XWP: For configuring and commissioning BACnet routers
● LNS Tool: For loading applications into the RXC controllers
● ACS: For configuring, commissioning and operating Synco and RXB devices
● PX KNX Tool: For configuring the KNX side of the PX KNX system controller
● AL Migration Tools: For migrating Unigyr, Visonik and Integral to Desigo

32 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Coverage of the System
3

Management Functions Desigo CC

Desigo CC Desigo CC GG

BACnet router Desigo XWP

Project Manager
Automation Functions
Network Configurator
PXC..D
PXC modular + TX-I/O modules
Point Configurator
PXC compact

CFC incl. Simulation

Utilities
Desigo Configuration Module

BIM Tool

TX Open Tool

Hierarchy Viewer

Report Viewer

DPT Tool

Room Automation
RXC Integration
RXC
Third-party
LNS Tool

RXT10

Additional Tools and Utilities for

Synco Integration
RXB
Third-party

Automation Level Migration Tool

Figure 12: Tools for Desigo PX

Tools for Desigo Room The following tools are used for Desigo Room Automation:
Automation ● DCM: For designing the system and determining the necessary quantities
● XWP/ABT:
– For configuring, programming and loading PXC3/DXR2 room automation
stations
– For integrating KNX devices into Desigo Room Automation (on KNX PL
Link Bus)
– For engineering and commissioning PXC3, TX-IO, In-Room Bus DALI and
KNX PL Link

33 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Main Tasks

Management Functions Desigo CC

Desigo CC Desigo CC GG

System Functions Desigo XWP

PXCx00-x.D Project Manager

Network Configurator

Utilities
Point Configurator

CFC
Desigo Configuration Module

Hierarchy Viewer

Report Viewer

Desigo Room Automation ABT

DXR2 ABT SIte
PXC3
TX-I/O modules ABT Pro

ETS
KNX PL-Link
VAV
FNCL
> ABT-SSA for KNX PL-Link
Switch
> ABT-SSA/ETS for KNX S-Mode
Presence
QMX3
KNX S-Mode

DALI
DALI > ABT-SSA for DALI

Figure 13: Tools for Desigo Room Automation

3.3 Main Tasks

What's covered by the The Desigo tools let you design, document and maintain Desigo systems, that is,
Desigo tools? you design and document technical configurations and programs for the Desigo
system.
What's NOT covered by The following processes and products are covered locally by SSP or VAPs and not
the Desigo tools? by the Desigo tools:
● Sales: Offer preparation and tracking
● Planning/Engineering: Network planning and design, floor plan, cabling,
designing control cabinets, designing electrical wiring diagrams, creating rating
plates, validating pharma systems
● Project management: Ordering devices, project planning, claim management,
project task planning
● Service management: Service database for devices, network planning, remote
service platform

34 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Main Tasks
3

Sales support
Desigo Configuration Module (DCM) supports the calculation of the Desigo
configuration for the sales process.
You can verify if:
● The Desigo configuration is technically correct, that is, the solution that was
sold can be implemented with Desigo
● The system limits have been taken into account, that is, the number of possible
devices and functions in the network is verified
● The quantity is correct, that is, correct device types for the automation and
room functions, field devices, accessories and licenses
● Services are correctly calculated
● The design for the review with the customer is well documented
● Prices are correct (regional companies can add their prices to the DCM
database)

Configuration and programming

The configuration and programming flexibility of system devices depends on the
product or product family. Some devices contain preloaded applications and
connections only to specific periphery device types.
You can configure and parameterize the devices offline or partly online with a
configuration tool. You can replace the preloaded applications on some devices in
the project.
You can freely program some devices. To create loadable applications, you can
use libraries to assemble project-specific solutions.
Degree of standardization The following table shows engineering methods by degree of standardization and
and flexibility flexibility:
● Level A: High degree of standardization with predetermined flexibility
● ...
● Level E: Low degree of standardization with very high flexibility
Solutions with a high Solutions with a high degree of standardization are:
degree of standardization ● More efficient to configure and commission than freely programmed solutions
● Easier to maintain, because the functions are verified and well documented
Solutions with a low Solutions with a low degree of standardization, that is, freely programmed solutions,
degree of standardization are:
● More laborious to create and document
● More error-prone than verified solutions
● Harder to maintain in the service phase, because they do not adhere to the
standard and are often not as well documented as verified solutions
The intermediate levels B, C and D allow you to choose a solution with the right
balance of flexibility and standardization.

35 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Main Tasks

Level Description Library Example Engineering Effort

Standard A Solution Browser in Locked CAS solutions AHU10 Low
XWP

B Solution Configurator CAS solutions, AHU10, fan, valve

in CFC, CAS library aggregates,
components

C CFC programming, Charts, blocks CAS library with

CFC library charts

High flexibility D CFC programming, Charts, blocks, LMU RC library High

solution creation (Library Maintenance
Utility), simulation

E CFC programming, CFC, SCL, simulation, HQ library

SCL block creation LMU, development
tools

Table 6: Desigo PX

Level Description Library Example Engineering Effort

Standard A Application selection Application type Standard, VAV Low

B Application Application modules Blind, radiator, light

assembling

C Application creation XFBs VAV

High flexibility D Application CFC FB's Regional specialties High

engineering

E Development All levels All

Table 7: Desigo Room Automation

Level A You can create solutions with the available options and variants with little prior
training and detailed knowledge.
The device is preconfigured and can be configured for the specific project. The
functions are predefined. You can configure the application using options and
variants. You can set the function of the application and the peripheral devices with
a configuration tool. The solutions are delivered by HQ as verified and documented
solutions.
Level B The device can be configured for the specific project. You can assemble the
application using library elements. This is a major advantage of the Desigo
application libraries. Even though assembling a solution is relatively easy, the
functions of the solutions are powerful. Using many options and variants, you can
customize the standard solutions to your project requirements.
Level C The device is preconfigured and can be configured for the specific project. You can
assemble the application using library elements. You can program the application
with default function modules with predefined interfaces. You can program using
simple programming functions.
Level D This level offers full flexibility, but requires detailed knowledge of the application's
structure, the programming tools, BACnet and the Desigo system functions. You
can program in CFC (Continuous Function Chart) with basic function modules. You
can use all available programming functions. You must ensure that the programs
you develop fit together regarding execution, priorities, auto-connecting in the tool,
interface usage, etc.
This level offers full flexibility, but requires detailed knowledge of the application's
structure and the programming tools. You must ensure that the functions of the
program work. You must ensure that the programs you develop fit together with all

36 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Main Tasks
3

Level E elements in the library and that they are well tested and documented. You must
take care of the compatibility, the versioning and the library packaging.

Creating a technical hierarchy

The technical hierarchy is the BACnet view on the Desigo system. It is based on
the plant-related structure in the building. This hierarchy is defined during
engineering. In special cases, if the customer requires it, the technical hierarchy
can be built according to a plant-specific structure defined by the customer (user
designation).
This lets, for example, the customer view the building in Desigo CC according to
this structure:
● Building topology (area, building, floor, plant, plant section, etc.)
● Naming in the system (names according to technical hierarchy, user
designation or free designation)

Creating loadable components for the automation stations

The result of the engineering are loadable configurations:
● Configuration of the automation station: Network configuration (IP, LON, MS
TP addresses), BACnet configuration (BACnet name and BACnet ID)
● Application: I/O configuration and setting parameters or program (for
programmable automation stations)
● Operating language: When you load the configuration, the operating language
for the generic operation is also loaded
● Firmware: For system upgrade or bug fixing

Creating the configuration of operation

The system devices can be operated locally, over the web, on a touch panel or in
Desigo CC. Operations can either be generic (without additional engineering) or
dedicated (with additional engineering via favorites or operating graphics).
● The generic operation is based on the technical hierarchy. It must not be
engineered.
● The room operation can be configured.
● Favorites are a simple grouping of operable elements in a summarized view.
This view can also be generic, for example, as a favorite in ABT-SSA, or it can
be engineered, for example, as a favorite for PXM20.
● The graphic operation must be engineered.

Installation, test and commissioning

An I/O configuration must be loaded for the point test. An application program is
not always loaded with the configuration.
You can carry out a point test with an application program if the application
program can be turned off during the point test. This way you can carry out a test if,
for example, a central security function would prohibit you from operating the I/O,
for example, if a central security function does not allow lowering the blinds.
The test protocol can store which points have passed the test and which points
have an error.

Creating local documentation and project documentation

The tools have two types of documentation:
● Local documents (work documents, simple templates, Excel exports) can be
used to, for example, verify results. You can, for example, export them to Excel
and add additional data to them.
● Project documentation (template with logo, author, table of contents, etc.) can
be attached to the customer documentation either in printed form or as a PDF.

37 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Tools for Different Roles

Managing project data

You can manage project data in three ways:
● Local project data management - You can save project data locally, that is, on
the local computer or on a share.
● Project data backup - You can create project data archives to, for example,
locally save the intermediate status of engineering data.
● Project data on the Branch Office Server (BOS) - You can store project data on
a BOS. This allows:
– Data storage on a server, incl. data backup
– Control of project data access, through login data
– Checking project parts in and out for working on engineering data in
parallel

3.4 Tools for Different Roles

In a project different roles are responsible for different tasks. Based on these roles,
there are various tool packages with different functions and licenses.

Role Description Application area

Application Engineer Can reprogram applications on a project-specific basis. System and room automation

Design Engineer Can carry out a project. System and room automation
Can select and configure solutions from the library.

Commissioning Engineer Can commission solutions, System and room automation

Can configure applications online.

OEM, Installer Can carry out a project. Room automation

Can select, configure and commission solutions from the
library.

Electrical Installer Can load configurations. System and room automation

Can configure devices.
Can test points.

Balancer Can balance rooms regarding air and water supply. Room automation

Table 8: Roles

Tool Tasks Application / Adv. OEM OEM, Installer Electrical Balancer

Design / Installer Installer
Commissionin
g Engineer
XWP Create projects and reports, design •
networks, BOS

ABT Site > Create and open projects • • • •

Projects

ABT Site > Create building structure and • • •

Building grouping hierarchy

ABT Site > Configure applications, mass create • • •

Configuration devices

ABT Pro Configure HW, edit applications, CFC • •

(TIA), debug

38 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Working with Libraries
3

Tool Tasks Application / Adv. OEM OEM, Installer Electrical Balancer

Design / Installer Installer
Commissionin
g Engineer
ABT Site > Device discovery, persistence of • • • • •
Startup readbacks, set up nodes, load web Simple GUI
pages, ABT-SSA for KNX PL-Link,
MS/TP

ABT Package XWP ABT ABT ABT Site ABT Site not ABT Site not
licensed licensed
ABT-SSA Access Point Test • • • •
via role and Operate and monitor
password Balancer • • • •
• • • •
ABT-SSA

Table 9: Tools for different roles

3.5 Working with Libraries

Libraries ensure efficiency and quality.
HQ libraries There are HQ libraries for every engineering level. HQ libraries:
● Allow you to work efficiently
● Are verified
● Are well documented
● Are based on a text data basis that allows you to switch the language in
engineering, that is, the library is language neutral
● Are versioned
● Can be installed with the library setup
RC libraries Based on HQ libraries, you can create country-specific RC libraries that cover
country-specific function requirements.
Project-specific libraries Project-specific libraries are based on HQ or RC libraries and contain components
with the specific settings needed in the project. This lets you use reuse already
configured solutions in the project.

3.6 Working in Parallel and Subcontracting

Project data management Project data management for the Desigo tools allows several users to work in
during parallel working parallel in different phases of the customer project, for example:
● Several users are engineering and commissioning in the same project
● Parts of the project are outsourced to subcontractors, for example, for the point
test
To ensure the consistency of the project data, parts of the project data are stored
on the Branch Office Server (BOS). This way several engineers cannot modify the
same data elements of the data basis at the same time.
Check-in/Check-out The check-in/check-out mechanism ensures that when several users are working
mechanism in parallel during engineering, commissioning or service, they cannot make
changes to the same automation station. This way no inconsistent data can be
created.
To quickly transfer project data, the data is compressed before it is sent from the
computer to the server. The data is managed on the Branch Office Server. The
project creator transfers the data from his local hard disk to the server.
In large projects the data can be moved in two steps:

39 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Workflow for Primary Systems

1. Step: Part of the project is transferred from the Branch Office Server to a
computer in the plant.
2. Step: Parts of the transferred project can be transferred to local computers. This
is called a sequential check-out.
Parts of the project, such as the building or network topology are checked out in
read-only mode, so that all users always have the project overview.

Working in parallel during Several users can work on different automation stations in the same project at the
engineering same time. To do this, data is transferred from the central data storage on the
Branch Office Server to the local hard disks. For example, individual automation
stations are being commissioned at the customer's site while some automation
stations are still being engineered at the office.
Working in parallel during Several users can work on different automation stations in the same project at the
commissioning plant at the same time. To do this, the components to be loaded are transferred
(Pack & Go), so that the user, for example, can load the configuration or program
and then perform the point test. The test results are saved in the automation
station and can be viewed and transferred back to the engineering database by the
commissioning engineer at any time.
Working in parallel during A service technician can connect with the plant by remote and make changes. To
service do this, data is transferred from the Branch Office Server to the local hard disk.
After the technician is done, the changes are transferred back to the Branch Office
Server, so that the project database is up-to-date again.
Subcontracting Project-specific solutions can be developed outside the project organisation and
specific tasks, such as configuration and point test can be outsourced to
subcontractors.
If you outsource specific tasks, make sure that:
● The work packages for the subcontracting can be easily transferred to the
subcontractor
● The subcontractor's work can be documented
● The changed data can be transferred back to the engineering database

3.7 Workflow for Primary Systems

Figure 14: Workflow for primary systems

XWP Project Manager Create project:

● Create project
● Check project in on Branch Office Server (BOS) and define access to project
● Define project defaults
● Create control cabinet topology (local specification of the automation station,
for example, control cabinet view)

XWP Hierarchy Viewer Create project structure (the building structure is system-oriented):
and XWP Network ● Create project structure
Configurator
● Create building topology (building, building parts, etc.)
● Create system topology (sites)

40 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Workflow for Room Automation Classic
3

● Create network topology (XWP Network Configurator, third party devices,

router, computer)
● BACnet references from third party devices and between primary system and
room (demand signals, supervisory)
● ACP (passwords for accessing the automation stations)
XWP Point Configurator Create systems:
● Define systems (systems, system sections, components, data points) (solutions,
data points, I/O modules)
● Configure the operations (XWP Hierarchy Viewer)
– configure the generic operation
– Configure the project-specific operation (favorites)
CFC & Simulation Program and configure:
● Program in CFC
● Define points in the I/O Address Editor
● Parameterize in the Parameter Editor
● Define alarming and trending
DNT and DPT Test and commission:
● Export data to Desigo CC
● Download firmware (upgrade if necessary)
● Load configurations and programs
● Carry out point test
● Debug in CFC (if necessary)
● Create commissioning documentation (local reports)
● Specialties:
– Integration (TX Open Tool, BIM Tool)
– AL Mig (AL Mig Tool)
– Simulation
XWP Report Manager Create documentation:
● Create project documentation

3.8 Workflow for Room Automation Classic

See Desigo Xworks Plus Overview of Workflows (CM111000).

3.9 Workflow for Desigo Room Automation

Figure 15: Workflow for Desigo Room Automation

XWP Create project:

● Create project
● ACP (passwords for accessing the automation stations)

41 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Desigo Configuration Module (DCM)

ABT Site > Building Create Desigo Room Automation project structure (the building structure is room-
oriented):
● Create building topology (buildings, floors)
● (Optional) Create user-specific building topology (UD structure)
● Create network topology (define address ranges)
● Create documentation (XWP Report Manager)
ABT Pro and ABT Site > Create project library:
Configuration ● Program automation stations (ABT Pro)
● Create templates for type-based automation stations (ABT Site > Configuration)
● Create templates for room control units
ABT Site > Building Create instances in the building:
● Create automation stations, or rooms, based on the project-specific library per
floor
● Edit room parameters
ABT Site > Startup Commission:
● Configure and load automation stations (node setup)
● Carry out point test (ABT-SSA) (subcontracting)
● Parameterize (ABT-SSA)
All projects are password-protected.

3.10 Desigo Configuration Module (DCM)

Desigo Configuration Module (DCM) lets users, who work in sales or project
execution, design the building automation and control system.
See Desigo Configuration Module (CM110752).
DCM is automatically updated with the latest data if installed correctly by using the
provided setup program, keeping the suggested installation path, and if an
online/network connection is available. The updated data can also be updated
regionally or dependent on a user to reflect relevant requirements.
Field of application DCM calculates the required materials for an installation from raw system data,
such as data points, panels, and building and plant structures.
You can use DCM to conduct analysis of variants after defining and completing the
installation structure by generating copies and then subsequently changing the
hardware specifications. If prices are stored in DCM, you can also compare prices
to find the best possible device for the money. You can copy the devices calculated
in DCM from the price lists or export them as an Excel file to calculate a bid.
Flexibility You can enter the data directly into DCM or import it as an Excel file for the
automation and Desigo Room Automation level.
The structure in DCM is hierarchical, but you can customize the structure according
to your requirements.
Management level The required software licenses for the selected functions, devices, integrations and
data points are calculated on the management level. The licenses are listed and
the required software units are calculated.
Calculations can be made for new installations and for upgrades and migration. To
calculate upgrades and migration, you can import existing license keys. The import
provides the exact installed basis and explicitly allows additional, required licenses
and software units.
Devices for the Desigo Web Interface are also determined on the management
level. The calculation is based on the number of data points to be integrated in the
web interface and by the number of desired touch panels.

42 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Desigo Xworks Plus (XWP)
3

Desigo Room Automation The Desigo Room Automation level lets you create highly complex building
level structures with the sublevels building, floor, zone, room, and room segment for
Desigo Room Automation.
The required hardware is calculated from the specified functions and/or data points
and/or KNX PL-Link and KNX devices. The specification follows a model function
set that is then assigned to the structure within the Desigo Room Automation level.
In addition, multiple model function sets can be created in a project and each of
them assigned as needed. A structure at the Desigo Room Automation level may
have multiple, assigned model function sets, and a model function set can be
assigned to different structures. As Desigo Room Automation often uses the same
structures and functions, you can indicate a multiplier on each sublevel within the
Desigo Room Automation level.
Automation level At the automation level you can calculate the required hardware based on
specified data points.
You can choose and calculate many variants using presettings. Variants include,
for example, the automation station type or I/O module type, larger automation
stations, or if plants are to be distributed among multiple automation stations. You
can also consider other criteria, such as available panel sizes.
Room automation You can choose solutions with LON and/or KNX. You can choose predefined
solutions with drag & drop and then equip them with the required field devices. This
way you can create a sample room and replicate it as required.
Third-party devices You can integrate third-party devices with protocols, such as LON, KNX, ModBus,
M-bus or OPC, on all levels.

3.11 Desigo Xworks Plus (XWP)

You can edit project data in the Xworks Plus Editors.
See Getting Started: Desigo Xworks Plus (CM110629).

Xworks Project Manager

The Xworks Project Manager lets you:
● Create, open and archive projects
● Check in/out project data for parallel engineering from the Branch Office Server
(BOS)
● Define PXC automation stations, control units and Desigo CC. The automation
stations are not engineered here, but only used in the documentation and
considered during the network check.
● Define rough network overviews (network data) and control cabinet
assignments (panel data)
● Define further project data, data and automation stations for RXC, RXB, and
Desigo Room Automation
● Create control cabinet assignments, that is, group automation stations to
control cabinets. This way you can export data and create documentation per
control cabinet.
● View locally available projects. There is no connection to the Branch Office
Server (BOS) in this mode.
● View the properties of an object, for example, a network, an automation station,
etc.

43 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Desigo Xworks Plus (XWP)

Figure 16: Xworks Project Manager

Xworks Point Configurator

The Xworks Point Configurator lets you define the functions of an automation
station. You can insert solutions for the object plant, plant section, aggregate and
component into this technical hierarchy. You can configure prebuilt verified
solutions using options (leaving out) or variants (options). After you select and
configure the solution, the program is automatically created.

Figure 17: Xworks Point Configurator

The Solution Browser lets you select and configure a plant.

● The tree view shows all selected objects of the plant.
● The configuration view shows all possible options and variants for the selected
object.
● The data point window shows all I/Os of the selected object.

44 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Desigo Xworks Plus (XWP)
3

You can configure I/Os and I/O modules and connect I/O channels with the I/Os.
You can design the integration of the room automation and the third party
integration. The import function lets you integrate third party data points on the
automation level. You can import data point information via a standardized
interface (SDF format). The BACnet reference browser lets you address BACnet
references. You can import BACnet references via a standardized EDE import file
(CSV or XLS format).

Xworks Hierarchy Viewer

The Xworks Hierarchy Viewer lets you verify the technical hierarchy of an
automation station or entire project. Conflicts in the technical hierarchy are
displayed.

Figure 18: Xworks Hierarchy Viewer

The Xworks Hierarchy Viewer shows the technical hierarchy per PX and the
technical hierarchy as it is shown, for example, in the generic view in Desigo CC.
You can define the user designation (UD) and the free designation (FD). You can
define the structure of the user designation with the field lengths and the
separators and assign the data points in the structure of the user designation. You
can verify the consistency of the user designation and free designation in the entire
project and assign the technical designation (TD = default value), the user
designation (UD) or the free designation (FD) to the object name (ON).

Xworks Network Configurator

The Xworks Network Configurator lets you define the network topology. You can
define LON, IP networks and network segments, assign and address automation
stations to the corresponding segments, and define automation stations and
routers.
You can define several sites in a project. The network check verifies all sites in the
project. You can verify all automation stations that have been defined in the
Automation Building Tool (ABT) for correct and unique addresses, and document it
in the network report.

45 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Desigo Xworks Plus (XWP)

Figure 19: Xworks Network Configurator

Programming in Xworks Plus

When the technical hierarchy and the automation station are defined, and the I/Os
are configured and addressed, you can create a program that corresponds to the
selected and configured solutions from the Xworks Point Configurator.

If you use the solution library, you do not have to program in CFC.

Workflow The workflow for creating programs usually runs as follows.

Workflow in the Xworks Point Configurator
● Select PXC hardware (compact or modular)
● Select and configure solutions
● Configure data points: data point type, signal type and conversion type to field
device
● Create and change programs
Workflow in the CFC Classic editor
● Define timer program
● Parameterize alarm behavior and I/Os
● Provide data signals for the energy exchange between different plants
● Transfer plans (create programs)
● load programs
● Carry out commissioning
● Test programs
● Create documentation: data point lists, device plaques, commissioning lists,
print parameter lists, etc.
CFC Classic editor The CFC Classic editor (Continuous Flow Chart) is a graphic tool tor creating plans.
The CFC Classic editor lets you create and change programs. A CFC plan consists
of function blocks and connections.

46 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Desigo Xworks Plus (XWP)
3

Figure 20: CFC Classic

The CFC Classic editor shows all blocks that are used in the program, nested
plans, all available CFC block libraries and the selected plan with the plan
interfaces to other plans. This view is available offline for programming and online
for checking the signal flow. The CFC Classic editor lets you compile programs,
that is, create loadable programs.
Additional editors In addition to the graphic programming, you can configure the programs in the
following editors:
● Parameter Editor: Lets you parameterize attributes.
● I/O Address Editor: Shows all I/Os of an automation station.
● Plant Control Editor: Lets you configure the plant controls for ventilation and
energy generation.
● Solution Configurator: Lets you configure solutions, that are from the CFC
library or have been generated from the Xworks Project Configurator.
● Simulation: Lets you simulate programs of a modular automation station
without hardware on the computer.
● Alarm display: Continuous update and local caching of all alarm status changes
during commissioning. Lets you view, acknowledge and reset alarms.

Xworks Report Manager

The Xworks Report Manager offers comprehensive customer documentation and
supports project staff during project handover. The customer can check the
documents and after handover the customer is supported during operations, for
example, when handling alarms and interruptions.

47 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Desigo Xworks Plus (XWP)

Figure 21: Xworks Report Manager

You can select one or more automation stations for the documentation, per
automation station, plant or system node. You can select document templates and
verify reports in a preview.

Desigo Point Test (DPT)

Desigo Point Test lets you test data points during commissioning of a Desigo PX
automation station. To carry out a data point test with configured I/O modules, you
must download the I/O configuration file for the modular PX automation stations in
the empty PX automation station.

BIM Tool
The BIM Tool is used for TX-I/O modules that are integrated with a BIM on
automation stations. The BIM was used on old automation stations for integrating
I/O modules.

TX Open Tool
The TX Open Tool lets you configure TX Open modules. You can define the TX
Open integration and commission the TX Open modules. To commission TX Open,
load a configuration into the modules with the TX Open Tool.
See TX Open Tool online help (CM111005).

RXT10 Tool
The RXT10 Tool lets you configure and commission RXC controllers.
In RXT10 you can select and configure the RXC applications. Then you define the
assignments in the rooms. After the room types have been tested, the applications
are multiplied and commissioned. Then you integrate the room automation (PXR).
Create the building hierarchy and design the rooms on CFC data. Finally group the
system functions and commission the PX application.

PX KNX Tool (Room Automation)

See chapter Room Automation.

48 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Desigo Automation Building Tool (ABT)
3

HVAC Integrated Tool (HIT)

HIT lets you design HVAC plants. HIT lets you to select and document any HVAC
control device as an individual product or in a system configuration. Using its
library of over 300 preconfigured HVAC applications for standard controllers
(Synco™, Sigmagyr™, and RXB) HIT generates a comprehensive specification
including plant diagram, list of material, technical documentation for each device,
and pricing.

3.12 Desigo Automation Building Tool (ABT)

The Desigo Automation Building Tool (ABT) is used for engineering and
commissioning Desigo Room Automation.
XWP in the Desigo Room Project data storage in a Desigo project is handled by Xworks Plus (XWP), that is,
Automation project you can create a customer project in XWP and check it in to the Branch Office
Server (BOS) using Xworks Project Manager. XWP is also used in the Desigo
Room Automation project to carry out the network check and to create the network
documentation. Some project reports, which also encompass the Desigo Room
Automation automation stations are created in XWP.

ABT Site > Projects

In ABT Site > Projects you create projects and define project settings.

ABT Site > Building

In ABT Site > Building you create building topologies. The topology shows the
assignment of room segments and rooms to floors and buildings.
You can define the grouping hierarchies for the central functions and assign the
grouping members to the grouping masters. You can create a user designation
with a user hierarchy.

ABT Pro
In ABT Pro you program automation stations (project-specific solution). Project-
specific solutions can be created in the Center of Competence (CoC) and used as
project-specific types in the project in ABT Site.
ABT Pro contains the CFC Plus editor for programming in CFC.

Figure 22: ABT Pro

ABT Pro shows:

49 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Desigo Automation Building Tool (ABT)

● The automation station objects

● The hardware view of the automation station
● The properties of the selected object
● The project-specific library
● Installed libraries
In the ABT Pro editors you configure room applications, rooms and BACnet objects.
In the CFC Plus editor you can program with CFC blocks. The CFC plan contains
CFC blocks and connections. A CFC block library is available. ABT Pro is based on
the Siemens TIA portal.

Figure 23: CFC Plus

ABT Site > Configuration

In ABT Site > Configuration you configure preloaded application types or project-
specific types.

ABT Site > Startup

In ABT Site > Startup you scan networks, load configurations and read back
parameters.

Figure 24: ABT Site > Startup

50 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Programming in D-MAP
3

ABT-SSA
In ABT-SSA (Setup & Service Assistant) you commission I/Os and carry out the
point test.
See Desigo TRA - Setup & Service Assistant (CM11105).
In ABT-SSA you can:
● Assign network points (DALI to device), make points available
● Test if the points work
● Define parameters, for example, time, desired value, default value, etc.

3.13 Programming in D-MAP

Programming is based on D-MAP principles (Desigo Modular Application
Programming), where you assemble blocks into compounds and then you build
hierarchically structured solutions using those compounds.
● In Xworks Plus (XWP) you program in the CFC Classic editor.
● In the Automation Building Tool (ABT) you program in the CFC Plus editor.
The CFC editors have a different look and feel. Their basic functions and basic
library blocks are almost identical.

Programming in XWP for Desigo PX

The Program View describes the concepts and elements on which D-MAP is based:
libraries, compounds, blocks, variables, data types and attributes.
The P&I diagram The Program View is based on the P&I (Process & Instrumentation) diagram. The
P&I diagram illustrates the plant and the associated instrumentation in the form of
a principles diagram.
The following figure shows a simplified P&I diagram of a partial air conditioning
system. The heating coil and its components, including the automation station
sequence, are encircled.

Figure 25: P&I diagram of a partial air conditioning system

XWP XWP is the programming tool for the PX automation station and incorporates all
system elements. XWP shows the structural view of the system with the plant,
partial plant, aggregates, and components, and, for example, the compound
functional unit for a valve.

51 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
3 Programming in D-MAP

Figure 26: Structural view (left pane) of the system and compound for a valve (right pane) in XWP

Programming in ABT for Desigo Room Automation

In Desigo Room Automation, the application architecture comprises the following
elements:
● Hardware configuration: Description of device configurations of the PXC3
automation station
● BACnet description with field device configuration for TX-I/O, KNX PL-Link and
DALI
● Automation program: Application description comprising application functions,
I/Os and CFC charts
This division lets you define application functions or CFC charts independent of the
hardware. The division is also reflected in the loadable units in the tool.
The program view describes the basic concepts and elements for programming for
Desigo Room Automation: Libraries, CFC charts, blocks, variables, data types,
configuration extensions and attributes.
In Desigo Room Automation, a program contains the application function (for
example, the lighting function), the associated CFC charts (for example, the chart
for manual control), and the I/O blocks (for example, the luminaries and buttons).

52 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Workflow, Tools and Programming
Programming in D-MAP
3

Primary

I/O
PX Prim I/O
Prim
Prim
I/O

Central
Central
Central
I/O
CenGen CenHvac CenLgt CenShd I/O
I/O Reference
PXC3 CenGen
CenGen CenHvac
CenHvac CenLgt
CenLgt CenShd
CenShd I/O
I/O
I/O
room
DXR2 CenGen
CenGen CenHvac
CenHvac CenLgt
CenLgt CenShd
CenShd I/O
I/O
CenGen
CenGen
CenHvac
CenHvac
CenLgt
CenLgt
CenShd
CenShd
I/O

Room
Room
Room
Room
RCoo Room
RHvacCoo
Room RLgtCoo RShdCoo
RCoo RHvacCoo RLgtCoo RShdCoo
RCoo RHvacCoo RLgtCoo RShdCoo
PXC3 RCoo RHvacCoo RLgtCoo RShdCoo
DXR2 RCoo
RCoo
RHvacCoo
RHvacCoo
RLgtCoo
RLgtCoo
RShdCoo
RShdCoo

Scene

Room Segment
Room Segment
Room Segment
Room Segment I/O
Hvac Room Segment Lgt Shd I/O
Hvac Room Segment Lgt Shd I/O
Hvac Room Segment Lgt Shd I/O
Room Segment
HvacRoom Lgt Shd I/O
Hvac Segment
Lgt Shd I/O
Hvac RoomSegment
Segment
Lgt Shd I/O
Hvac Room Lgt
Room segment Shd I/O
Hvac Lgt Shd I/O
Hvac Lgt Shd I/O
Hvac Lgt Shd I/O
PXC3 Hvac Lgt Shd I/O
I/O
DXR2
Hvac Lgt Shd I/O
I/O
Lgt
Lgt
Shd
Shd
I/O
Grouping Direct reference

TR Brgt Psc

Figure 27: Desigo Room Automation program elements

53 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Programming in D-MAP

4 Control Concept
Supply chain model
In building automation and control, media, such as warm water, cold water, warm
air, and cold air are generated using energy, such as oil, gas, and electricity, and
distributed to consumers.
Each medium can be assigned a supply chain. The supply chain starts at the
generation or handling of the medium. The distribution system then transports the
medium to one or several consumers. A supply chain for building services systems
comprises the following links:

Figure 28: Supply chain for a hot water plant

Consumers The consumer supplies the energy contained in the hot water medium to the room
as per the requested demand (for example, via a radiator).
Distribution The distribution system transports the medium from the producer to the consumer
and adjusts it to the individual requirements (minimum losses).
Production The production consists of a boiler where hot water is treated by means of energy
(for example, heating oil, gas) and provided to the process.
Supply chains of various The following illustration shows a schematic view of the supply chains for the
media media air, hot water, and cold water with their respective production (treatment),
distribution (for example, heating circuit, pre-control), and the consumers.
The supply chain for the medium electricity, which normally begins at supply or at
production, if electricity is produced on-site (for example, cogeneration plant,
photovoltaic) is also shown.

54 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Programming in D-MAP
4

Figure 29: Supply chains for the mediums air, hot water and cold water

A tree structure opens to the right for the individual supply chains. In other words,
one or more generators supply multiple primary controllers and each primary
controller for its part supplies one or more consumers or other primary controllers.
From the air supply chain point-of-view, air treatment is a part of production
(handling). From the hot water and cold water point-of-view, air treatment (or air
heater/cooler) belongs to consumption.
The air supply chain comprises the central air treatment plant, optionally
supplemented by pressurization control and air posttreatment.
Supply flow In each supply chain, the medium flows from the producer, through the distribution
system to the consumer. This flow within the supply chain is referred to as the
supply flow.
Supply chain structure A supply chain consists of at least one producer and one consumer. It can also
have multiple chain links, that is, producers, distributors, and consumers, and be
structured as follows:
1. One producer with one distributor and one consumer.
2. One producer with two distributors in series and one consumer.
3. One producer with two distributors in parallel and two consumers in parallel.
4. Multiple producers, distributors, and consumers in parallel.

55 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Programming in D-MAP

Figure 30: Design of supply chains

Producer In practice, however, there are often multiple producer units, for example, boilers
with the same or similar power, or a mixture of different units, for example, boiler
combined with a solar plant and cogeneration plant (usually with additional storage
units).
Logical producer From the distributor and consumer point-of-view, there is only one single producer
within the supply chain, the logical producer, with exactly one supply point as the
interface to the distribution network. This logical producer knows nothing about the
structure of the distribution network and the connected consumers. Also, neither
the distributor nor the consumer knows whether the producer consists of one or
multiple units.
Distribution components The distributor or distribution transports the medium within the supply chain. In this
process, energy losses and energy consumption of pumps and fans is to be kept to
a minimum.
Conversion Conversion (transformation) of the medium, for example, in a heat exchanger, is
assigned to a supply chain of distribution. A change of temperature (for example,
pre-control in the heating circuit) is also seen as conversion. Pre-controllers can be
arranged in series (cascading).
Consumers The following consumers, for example, belong to the various supply chains:

Supply chain Consumers

Hot water Air treatment and air posttreatment (heating register)
Radiators (radiator, convector)
Floor heating, domestic hot water heating

Cold water Air treatment and air posttreatment (cooling register)

Cooling surface (chilled ceiling)

Air Air posttreatment (dampers)

Electricity HVAC consumers, other consumers

Table 10: Supply chains and consumers

56 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Programming in D-MAP
4

Coordinator and In addition to the three chain links producer, distributor, and consumer, there are
dispatcher the logical links named coordinator and dispatcher.
Supply chains for a room You can define different consumer needs for a room, such as heat, refrigeration
and fresh air.
Heat demand The hot water supply chain exists for heat demand. The medium hot water is
prepared in hot water generation and distributed via a heating circuit. The heat is
emitted to the room as needed via a heating surface. If air is the carrier of heat, this
is done via pre-control and air posttreatment.
Refrigeration demand The cold water supply chain exists for refrigeration demand. The medium cold
water is prepared in cold water generation and distributed via a cooling circuit. The
refrigeration is emitted to the room as needed via a cooling surface. If air is the
carrier of refrigeration, this is done via pre-control and air posttreatment.
Fresh air demand The need for fresh air is met by the air supply chain, where the medium is
produced by the air treatment plant, distributed via the ducting, possibly adjusted to
differing requirements of the room by an air posttreatment plant, and transferred to
the room via air outlets.

HVAC application architecture

The HVAC application architecture contains an overall view of typical heating,
ventilation and air conditioning plants with distributed applications and is based
very strongly on the supply chains (energy and substance flows) in building
services systems.
● The mutually standardized exchange and re-use of HVAC-relevant demand
and coordination signals is possible in distributed applications.
● The HVAC application architecture structures the HVAC functions into
meaningful units, interfaces and functional mechanisms.
● The HVAC application architecture is scalable and independent of product and
communication standards.
HVAC system view The consideration and definition of the HVAC application architecture and its
functionality gives rise to the HVAC system view, which comprises:
● Plant (primarily HVAC plants)
● Operator interventions
● Functional units

57 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Programming in D-MAP

Figure 31: HVAC system view

Plant A plant consists of partial plants, aggregates, and components, which, as a rule,
form a supply chain with the chain links producer (here: boiler), distributor (pre-
control, heating circuit), and consumer (radiator).
Operator interventions Commands are executed at each link of the chain through operating interventions
via HMI commands. The impact on the plant (or the process) takes place via the
corresponding function unit and automation station.
Functional units Functional units represent the software map of chain links and plant elements. The
functional units contain all control, monitoring, and limiting functions that are
necessary for operation.
Information signals Energy demand information can be passed on implicitly via the medium within the
supply chain, for example, if the hot water supply temperature falls because of a
rise in heat consumption, more heat energy must be produced.
Information can also be represented by an explicit signal and transferred via a
signal path (for example, via a bus). The following explicit signals have been
defined in the Desigo system:

Explicit signals Signal flow Application

Demand signal Consumer to producer A plant functional unit communicates its demand (that is, operating mode, set
points) to another partial plant functional unit in the direction of the producer. The
demand signal eventually arrives at the producer.

Operating signal Producer to consumer A plant informs the downstream plants about its currently effective operating state.
This signal is only used as an exception and is therefore switched depending on
the situation.

Override signal Producer to consumer The producer demands a certain operating mode from a consumer. Forced
signals are more the exception than the rule and are therefore not implemented in
sample plants. Forced signals are used for solar plants and wood furnaces among
others, where the minimum heat production cannot be controlled.

Table 11: Information signals

In addition to the functional units, there are two further elements that belong to the
supply chain on the software side:

58 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Control Concept and Control Blocks
4

● Coordinator: The coordinator combines the demand signals of downstream (to

supply flow direction) plants and delivers a resultant demand signal to the
upstream plants. The coordinator also signalizes the operating state of the
upstream plants to the downstream plants.
● Dispatcher: The dispatcher determines the demand signals for the producers
on the basis of the resultant consumer demand signals. It decides which and
how many producers must be activated.

Figure 32: Example of a sequence control

4.1 Control Concept and Control Blocks

The Desigo control concept is a set a rules that determine in general terms the
principles governing all control, reporting and monitoring operations and the
switching interventions in the Desigo system. The rule applies to block-internal
control (priority array) and to functional interactions among participating blocks.
This specifically deals with:
● Structure and design of control as function blocks
● The hierarchical assignment of the function blocks among themselves
● The function hierarchy within the control chain for the function blocks
● Processing operational and fault messages
● Interventions in monitoring functions
● Impact of emergency switching
The open loop control strategy is based on the exchange of predefined signals
between functional units. Each functional unit is an image, or memory map, of an
actual element of the plant, for example, ventilation or boiler plant.
Control functions The open-loop control functions required for a given element are locally an integral
part of the functional unit (for example, the increase, after a time delay, in the
speed of a multi-stage fan, or the demand-based switch-on of a boiler). In each
functional unit, various possible requirements are prioritized and evaluated. The
resulting operating mode is then passed on to the elements or subordinate
functional units. The functional unit already incorporates the I/Os needed for the
physical data points.

59 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Control Concept and Control Blocks

Structure control functions In this way, complex control and monitoring functions of a plant can be logically
subdivided to allow for clear assignment of the function unit or the real element of
the plant. The higher-level control concentrates on the control and monitoring of
the overall plant, while the sub-control function units assume internal control and
monitoring of the given elements for the function unit.
Standardization of control Moreover, plant security and available was increased through standardized control
functions and monitoring functions which would result in considerable expense using
conventional methods.
Standardized control and monitoring functions:
● Unambiguous selection of operating mode
● Uniform fault-related shutdown
● Comprehensive status monitoring
● Switching sequence for ventilation systems
● Output stage control for heat generating plant
● Reporting of local intervention
● Avoidance of unnecessary attempts at switching
● Prevention of inadmissible switching operations
● Protection of plant by preventing switch-on or switch-off

Blocks bound by the control concept

The following table shows the blocks that are optimized for control tasks.

60 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Control Concept and Control Blocks
4

Function Block name Task in the control concept

Prioritization of influencing ENSEL_BO Collect information for the selection of the resulting plant operating mode. All
variables ENSEL_MS superposed information are processed by priority resulting in the plant being
turned on or off, for example, smoke extraction switch, frost protection, scheduler
program.
The blocks are primarily used on the hierarchy level plant/partial plant, but may
also be reasonably used, for example, in aggregates.

Command control CMD_CTL Superposed control block for sequence control. The block ensures that individual
plant aggregates are switched on or off sequentially in a certain order. The block
monitors aggregates and can send alarms. It is optimized for controlling air
handling plants, but can be used for other applications. The block is used on the
hierarchy level plant/partial plant.

Power control PWR_CTL Superposed control block for power control. The block is used for control and
monitoring of the performance of a number of energy producers (multiple boiler
systems, refrigeration machines). Depending on the request power demand,
energy produces are switch on or off in stages. PWR_CTL is optimized for
controlling heating and refrigeration plants. The block is used on the hierarchy
level plant/partial plant.

I/O blocks with control BO Output blocks implemented per BACnet standard and therefore including a priority
functionality MO mechanism (priority array) that is well suited for control tasks. The priority array
[PrioArr] be used through data flow interconnections and BACnet commanding.
AO
Moreover, the block integrate the following control functionality:
- Motor control (pump, burner, etc.), one- to four-speed [BO, MO]
- Fan control, one- to four-speed [BO, MO]

Value blocks with control BVAL Value objects or value blocks are implemented per BACnet standard and
functionality MVAL therefore includes output blocks via the priority mechanism. These blocks are
referred to as data points that can communicate within the system with the I/O
AVAL
modules via BACnet. These blocks are primarily used as the communication
interface between superposed control [CMD_CTL, PWR_CTL] and the
aggregates.

Rotation block ROT_8 The Rotation block switches the operating mode on and off for a maximum of
eight functional units in accordance with a selected mode of rotation (sequence or
hours run). The change of operating mode is based on demand, hours run,
occurrence of a fault or manual intervention (override).
The block is used to process the functional units (for example, aggregates or
components) as a function of run-time or faults. These blocks are used, for
example, for double pumps, that are changed over based on runtime.

Table 12: Blocks bound by the control concept

Control hierarchy
Control hierarchy is the map of the functional assignment and linking of those
function blocks included in the control concept for a plant. The structure of the
control hierarchy is subject to certain rules. A distinction is drawn between higher-
level plant control and local control of the functional units.
Superposed control Within the hierarchical structure, higher-level control functions are typically
assigned to the partial plant level. All the variables which are influencing factors on
the overall plant are weighted and combined to give the effecting plant operating
mode. In respect of each of the possible plant operating modes, a control strategy
can be defined for each underlying functional element. This makes it possible to
develop specific plant scenarios, such as fire control, smoke extraction, frost
control, on/off-switch control.
Local control Within the hierarchical structure, local control of the function elements is typically
assigned to the partial plant level. The main function of local control is to respond
to faults. The functional unit itself determines how the outputs are to be controlled
in the event of a fault. Interlocks between functional units (for example, damper/fan)
must be implemented locally. Local control prevents the risk of damage to plant, in
the event that the command control parameters are set incorrectly.

61 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Control Concept and Control Blocks

The control hierarchy in the following figure considers only the example application
for ventilation.

A-Transport

Ag: V(A,C-F) Fan1St

FanEx
PltCtl Cp: CMD_CTL

OpSta

EnCrit
DmpShofEh Ag:DmpShof
EnCrit

CMD_CTL

On

FanSu
Ag: V(A,C-F) Fan1St
SmextPrg

En

OpSta
SmextEh Cp:BI

EnCrit
E,U
BI

SmextEh

DmpShofOa Ag. DmpShof

En

On/P14 Open/P14
ErcRo DmpShof

EnCrit
On
SmextSu Cp:BI
E,U
BI

SmextSu

En

On/P14
FireDet Cp:BI
E,U

EmgOff

EmgOff
BI

ManSwi Cp:Ml
On

MI
En

TSu
ValSfty
SpErcTSu EnSfty
Frost

BO

KickDmp

Dstb
En

Sequence table

ValPgm OpSta

EnPgm PrVal

M
E,H
On
OpModSwi Cp:MI
E,H

Ax: DMUX8_BO

En
OpMSwiCnv
MI

BVAL
En

AO

PrVal FbVal

PrVal
On
OpModMan
Cp:MVAL_OP
MVAL

En

ValSfty
En

TSu
O&M

EnSfty

KickDmp
BO

Dstb
Frost

ValPgm OpSta

TOa EnPgm PrVal

E,H
En

DefVal:Off
Sched
Cp:BSCHED

BVAL
On

AO
En

En

PrVal FbVal

PrVal

Figure 33: Control hierarchy in a sample ventilation plant

I/O block functions and interfaces

The I/O blocks are the most important blocks in the Desigo system. In addition to
controlling the hardware, they are responsible for numerous control and monitoring
functions. They enable otherwise complex functions to be implemented with just a
small number of blocks. The following table shows the main functions and
interfaces of the I/O blocks.

62 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Control Concept and Control Blocks
4

Function Inputs Description AI AVAL AO BI BVAL BO MI MVAL MO

Stop transmission OoServ Out of service • • • • • • • • •
of input signal

Priority DefVal Default value • • • • • •

mechanism

PrioArr Priority array • • • • • •

Local override Ovrr Override • • • • • •

OvrrVal Override value • • • • • •

Alarm value EnAlm Alarm enable • • • • • • • • •

monitoring
HiLm Upper limit • • •
- Limits
- Reference LoLm Lower limit • • •
values Nz Neutral zone • • •
- Monitoring
periods RefVal(s) Reference value • • • • •

TiMonOn Monit. time • • • • •

switch-on

TiMonOff Monit. time • • • • •

switch-off

TiMonDvn Monit. time • • • • • • • • •

deviation

Switching delays DlyOn Switch-on delay • • • •

DlyOff Switch-off delay • • • •

TbTiDly Time delay table • • •

Switching action SwiKind Switch kind • • • • • •

Normal (motor)
Release
command
Trigger
Switch
Switch with delay

Table 13: Control and monitoring functions of the I/O blocks

Function Outputs Description AI AVAL AO BI BVAL BO MI MVAL MO

Feedback PrVal Present value • • • • • • • • •
monitoring
FbVal Feedback value • • •

Reliability Rlb Reliability • • • • • • • • •

monitoring

Fault monitoring Dstb Fault • • • • • • • • •

Status monitoring TraSta Transitional state • • • • • •

Priority SftyActv Safey priority • • • • • •

monitoring Active

CritActv Critical active • • • • • •

PgmActv Program active • • • • • •

PrPrio Present priority • • • • • •

Table 14: Control and monitoring functions of the I/O blocks

63 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Control Concept and Control Blocks

Function Inputs Description AI_RED AO_RED BI_RED BO_RED MI_RED MO_RED

Stop transmission of OoServ Out of service
input signal
DefVal Default value • • •

Priority mechanism PrioArr Priority array • • •

Local override Ovrr Override • • •

OvrrVal Override value • • •

Alarm value EnAlm Alarm enable

monitoring
HiLm Upper limit
- Limits
- Reference values LoLm Lower limit

- Monitoring periods Nz Neutral zone

RefVal(s) Reference value

TiMonOn Monit. time switch-

on

TiMonOff Monit. time switch-

off

TiMonDvn Monit. time

deviation

Switching delays DlyOn Switch-on delay

DlyOff Switch-off delay

TbTiDly Table for time delay

Switching action SwiKind Switch kind • • •

- Normal
- Release command
- Trigger

Table 15: Control and monitoring functions of the I/O blocks

Function Outputs Description AI_RED AO_RED BI_RED BO_RED MI_RED MO_RED

Feedback PrVal Present value • • • • • •
monitoring
FbVal Feedback value

Reliability Rlb Reliability • • • • • •

monitoring

Fault monitoring Dstb Fault • • • • • •

Status monitoring TraSta Transitional state • • •

Priority monitoring SftyActv Safety priority • • •

Active

CritActv Critical active • • •

PgmActv Program active • • •

PrPrio Present priority • • •

Table 16: Control and monitoring functions of the I/O blocks

Priority mechanism Within the Desigo PX system, the BACnet priority mechanism is used for the I/O
output blocks and in the value blocks. This priority mechanism provides a series of
prioritized levels at which intervention is possible, for use with the control functions
in HVAC plant and the associated components.
The following priority levels are available with blocks AO, BO, MO (and blocks
AO_RED, BO_RED, MO_RED) and AVAL, BVAL and MVAL.

64 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Control Concept and Control Blocks
4

Level Application Description

Safety level Life safety The safety level is assigned the highest priority and is used for the protection of
people and equipment. This is where local safety switches and emergency OFF
Plant safety buttons are wired or superimposed commanded, for example, smoke extraction
control or frost control.

Operator level Local manual intervention The operator level is where components are overridden manually. Here the
operator unit may be used to force the output of an I/O function block. This
Superposed manual operation overrides all operations at a lower priority level.
intervention

Automatic level Local control The automatic level is used for local control functions and for superposed BACnet
commanding.
General BACnet commanding

Table 17: Priority mechanism

The following figure illustrates the structure of [PrioArr] and the influence of local
and higher-level control.
Priorities 1, 4, 7, 15 Priority 6 Priorities 2, 5, 8, 14, 16
Local control Control within block Higher control
via data flow interconnection via BACnet command

AO BO MVAL
CMD_CTL

e.g. emergency stop

1 PWR_CTL
Life safety
2

3
e.g. anti-icing
ValCrit / EnCrit
protection
Critical value
5

6 Monitoring hours
7 Desigo CC
e.g. local manual Manual operation
switch ValOp / EnOp 8

13

14
Local control Program control
15 ValPgm / EnPgm

General BACnet command 16

PrVal

Figure 34: I/O block interface with [PrioArr]

Local override The override switch overrides the block's switching value and determines in this
way the switching value for the field device. Local override has priority over an
active manual operation at the same time, that is, priority over local override.
Status monitoring [AO, BO, MO, AVAL, BVAL, MVAL]
The process is monitored via the feedback signal, and in the case of switching
blocks, also via the ramp-up and ramp-down parameters set in [TbTiDly]. If the
feedback value deviates from the present value [PrVal] and the delay in [TbTiDly]
has not yet expired, the process is in a transitional state. The status monitoring
function shows the status at the transient state [TraSta] output. This output can be
used to switch on any subsequent components.

65 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Control Concept and Control Blocks

Feedback monitoring [BO, MO]

Monitoring feedback may be based on a data point or a purely internal to the block
based on the feedback time parameter.
● Feedback data point available [FbAddr:] = Address
Monitoring is based on the feedback signals. The delays can be defined with
the time parameters for switch-on [TiMonOn], switch-off [TiMonOff] and open-
circuit [TiMonDvn]. If the feedback signal [FbVal] deviates from the output value
[PrVal], an OFFNORMAL alarm will be triggered (provided the alarm function is
switched on).
● No feedback data point available [FbAddr:] = empty
Based on the feedback time parameter [TiMonOn/TiMonOff], the output [FbVal]
is delayed by [PrVal]. The output [TraSta] signals transition state.
Alarm value monitoring [AI, AO, AVAL, BI, BVAL, MI, MVAL]
Alarm monitoring is optional and can be enabled using [EnAlm]. Analog limit or
switching values can be monitored depending on the block type. The tolerance
time [TiMonDvn] to trigger a process alarm can be set. Deviations for switch on and
off procedures can be distinguished for switching blocks.
Alarm monitoring can be enabled based on the process or time. You can switch off
frost protection monitoring in summer, for example.
Reliability monitoring [AI, AI_RED, AO, AO_RED, AVAL, BI, BI_RED, BO,BO_RED, BVAL, MI, MI_RED,
MO, MO_RED, MVAL]
The blocks monitor the reliability of input and output sources and configuration
errors. A system alarm is generated for example when a source no longer
communicates and the cause is displayed on output [Rlb]. The disturbance output
[Dstb] changes to yes. This output, for example, can return to the block for the local
disturbance to achieve a more secure position using a higher priority. Reliability
monitoring can be switched off using [OoServ], which may make sense for
defective or faulty hardware.

Reliability monitoring is always active for the RED blocks since no [OaServ] is
available. Superposed control does not distinguish this state and plant safety is
not provided under certain circumstances.

Minimum switching times [BO, BVAL, MO, MVAL]

The minimum time on [TiOnMin] and the minimum time off [TiOffMin] may be
defined to reduce switching frequency. For a switch on or off command, is written
to [PrioArr] as priority 6 and maintained there during the defined switching period.
No lower priority can change the switching value during this time frame.
Switch-on and switch-off [BO, BVAL, MO, MVAL]
delay To delay switch on or off for elements [DlyOn/DlyOff]. For example to implement a
pump run-on to extract residual heat. For a switch on or off command, the
corresponding switching value is written to [PrioArr] as priority 6 and maintained
there during the defined switching period. No lower priority can change the
switching value during this time frame.
Ramp-up/down time Runtimes for ramp-up and down
[BO, BVAL, MO, MVAL]
The runtime of a damper or the coasting time for a multi-speed motor can be
defined in table [TbTiDly] to display or evaluate a transient state [TraSta]. The time
parameter can also influence the switching response depending on the switch kind
[SwiKind] used.
The block independently recognizes faults and reports them to the defined alarm
class [AlmCl], which for its part is responsible for distributing the alarms to alarm

66 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Local Control Design
4

Plant fault receivers. Depending on the alarm function [AlmFnct] set in the block, you may
have to acknowledge the alarm and reset it after eliminating the alarm.
The faulted block on output [Dstb] is reset only after the user action is run. The
plant ramps up only after an alarm reset since both the local control, as a rule, with
this output is blocked for a fault and as superposed control triggered a plant fault.
The alarm reset can be triggered:
● By triggering a common reset in the common alarm block CMN_ALM
● Via an alarm client

4.2 Local Control Design

Fault-related shutdown
The disturbance output [Dstb] for an I/O function block is activated when the block
recognizes a FAULT alarm (for example, broken wire) or an OFFNORMAL alarm
(for example, exceeding a limit value).
The following figure shows how a valve and a pump are forcibly shut down or
ramped up depending on the fault state.

Temp: AI

OR
100 %

P15 Pgm P4 Crit P15 Pgm P4 Crit

CritActv

CritActv
TraSta

TraSta
FbVal

FbVal
PrVal

PrVal
Dstb

Dstb

Pu Cp: BO

Figure 35: Fault-related pump shutdown

Example forced set-up A limit value [HiLm] is defined for the temperature in block AI Temp. As soon as
this threshold is reached, the output [Dstb] switches the valve via Enable [EnSfty]
for the analog output value to 100%. At the same time, the pump is switched to off
by Enable [EnSfty] for the Binary Output BO.
Example of fault-related The block BI ThOvrld monitors the state of the pump’s thermal switch. If the contact
shutdown is triggered, the function block is activated based on the parameterized reference
value [RefVal] for [Dstb] output. The pump is shutdown through Enable [EnSfty] of
the Binary Output BO. The Binary Output BO further monitors the contact’s
feedback. In the event of a fault, where the feedback is interrupted, for example,
the block reports the fault and shuts down itself via the back wired output [Dstb].
The pump can only be switched on again only after the fault is eliminated and the
alarm message is reset as required.
The following figure shows a local fault-related shutdown related to superposed
plant control. The compound mapped here as an example was reduced to make is
easier to recognize the structure of the local control.

67 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Local Control Design

15: ValPgm
14: EnPgm

13. ValCrit
12. EnCrit
Off

Ort
Ax:OR
P15 Pgm P4 Crit

CritActv
PrVal

Dstb
CmdVal Cp:BVAL Or2 Ax.OR

TCtr
PID_CTR

0% On Off

ValCrit
EnCrit
P15 Pgm P4 Crit

KickDmp
CritActv

TraSta
FbVal

PrVal
PrVal

Dstb

Dstb
Pu 1St: BO
R/sCtl

Data Sink: Receives Data

The Information is written by a Client with a
certain priority or is read by the Function Unit.
Figure 36: A local fault-related shutdown

Local fault-related shutdown of the aggregate depicted here as an example is

triggered as follows:
1. A fault is displayed at output [Dstb] when a component valve [Vlv] or pump
[Pu1St] reports a fault (FAULT or OFFNORMAL). The signals revert to enable
safety priority [EnSfty] for block BVAL (1). Fault-related shutdown of all
components is triggered via the state output [SftyActv] (2).
2. You can also impact the safety shutdown of the components via the compound
interface [I1 EnSfty].
The superposed plant control (not displayed here) can access the object directly
via referencing since the block BVAL is mapped on BACnet and has a priority array
[PrioArr]. As a result, plant control can also trigger a shutdown of the components
by commanding the safety priority.

Interlocks
The following figure shows a solution where a fan is only enabled after the damper
is completely open.

68 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Local Control Design
4

[On/Off]
OpMod
Yes
En Val En Val En Val En Val E,H
P15 Pgm P4 Crit

PfmActv

SftyActv
CritActv

TraSta
PrVal

Dstb
[On/Off] Damper Cp:BO
OpMod
Yes

Off

En Val En Val En Val En Val E,H

P15 Pgm P4 Crit
PfmActv

SftyActv
CritActv

TraSta
PrVal

Dstb

Fan Cp:BO
Figure 37: Local interlocks for damper/fan

Local interlocks A command to ramp-up the plant [OpMod] =On, the damper output changes to
[TraSta] = Yes, indicating that a transient state is now active, in other words, the
damper is moving. This information is formed on the one hand from the
parameterized damper run time [TbTiDly] and, on the other hand, from the
feedback contact for the damper's mechanical stop.
The valve is blocked via input [EnSfty] as long as the damper is either blocked or
moving, in other words, an intervention via the operator unit directly on the fan is
prevented. When the transient state ends and the damper is open, the Enable
[EnSfty] is cancelled and the fan switched on via the program value [ValPgm].
Enable of the program value [EnPgm] is a constant in this example.
Interlock among The targeted interlocking is employed in a modified form from the superposed plant
aggregates control. To allow, for example, plant control to access the fan during smoke
extraction control, the interlock is not implemented by enabling the safety value
[EnSfty], but rather by enabling the critical value [EnCrit].
The fan is set to Off by the damper via Enable [EnCrit] until the damper is fully
open. The fan can only then start. The damper is held open via [EnCrit] as long as
the fan is running to prevent a mistaken operation that could destroy the plant.

69 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

BACnet Reference
Open

ValCrit

EnCrit

OpSta
DmpShofOa Ag: DmpShof FanSu Ag: Fan1St

OpSta

EnCrit

ValCrit
Figure 38: Cross-aggregate interlocking of damper/fan

The operating state [OpSta] for both aggregates are formed within the compounds
as illustrated in the previous example from the AND link for [PrVal] and [TraSta].

4.3 Superposed Plant Controls

Two blocks are available in Desigo for superposed plant control:
● CMD_CTL command control for sequence control
● PWR_CTL power control for stepped control
Both blocks are based on the standard BACnet Command Object. They have both
tables that define the operating modes and switching response of the underlying
aggregates. The commandable blocks in the aggregates must have a BACnet
[PrioArr] to use the following output and value blocks: AO, BO, MO, AVAL, BVAL
und MVAL.
PWR_CTL may only be communicated using the MVAL blocks based on the
specialized task – controlling steps.
Referencing Referencing is used exclusively for communications by the superposed control
blocks with the output and value blocks in the aggregates to be commanded. The
references are derived from the Technical Designation (TD) of the block. The
reference is defined relative to the control block to the command block. The
aggregate does not have to be in the same hierarchy; cross-plant communications
is possible.
Example for a reference: B = \...\...\PreHcl’CmdVal
Where CmdVal is the designation for a BVAL object in the PreHcl aggregate. More
than one block can be referenced for each aggregate.
As the project-specific root is not part of the address, the references do not need to
be modified if the root changes. This simplifies project-specific name changes and
the copying of library solutions into a project.
The references, that is, the technical designations with relative addresses are
resolved in the controller at runtime. Any addressing errors will therefore only be
apparent during runtime. The cause of the error can largely be eliminated, however,
when parameterizing the controls blocks with the help of the Plant Control Editors.
The figure shows that the [PrioArr] can communicate directly with the referenced
blocks. You can command switch and positioning values and enable them. A
commanded command remains valid until the priority entry is enabled again. The
control blocks automatically enables all commanded priorities, when the block
commands the aggregates to the new plant operating mode. The entries for the

70 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

[PrioArr] are deleted in the commanded blocks when restarting the PX controller,
with the exception of local, manual interventions to priority 8.
Special Desigo S7 Interconnection in CFC and not referencing is used for superposed control blocks
features to communicate with the commanding aggregates! The control concept is
otherwise the same as the one for Desigo PX.
Determining plant A superposed plant control generally has different sources such as plant switch,
operating mode scheduler program or important fault messages, from which the resulting plant
operating mode must be determined.
The ENSEL_MS (Enable Selector Multistate) and ENSEL_BO (Enable Selector
Boolean) blocks are available for evaluating the resulting plant operating mode in
the firmware library of Desigo. As a rule, the block is placed before plant control as
illustrated in the following figure. All potential influences are interconnected,
prioritized by importance on the block and the corresponding required plant
operating mode is determined.
Example:
● A fire detector as a high priority (P04) and requires the plant operating mode
EmergOff.
● The smoke extraction switch has the highest priority (P01) and demands plant
operating mode smoke extraction.
● The scheduler has a low priority (P11) and demands plant operating modes
Stage 1, Stage 2 and Off.
The output [Val] for ENSEL_MS now supplies the CMD_CTL the resulting plant
operating mode for additional processing. It is important that the multistate
enumerations for both blocks ENSEL_MS and CMD_CTL are the same. The
multistate values are not text, but rather numbers based.

Superposed command control CMD_CTL

The command control CMD_CTL block is used primarily for the sequence control in
the ventilation plants. The block makes it possible to sequentially switch on and off
the aggregates. As it is implemented in a very general and flexible way, other fields
of application are also conceivable, for example, for refrigeration plants.

71 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

Ccl Ag: CclT

PltCtl Cp: CMD_CTL
Tsu

A-Transport

FanEx
Ag: V(A,C-F) Fan1St
OpSta

EnCrit
DmpShofEh Ag:DmpShof
EnCrit

CMD_CTL

On
SmextPrg

FanSu
Ag: V(A,C-F) Fan1St
En
SmextEh Cp:BI
E,U

SmextEh

OpSta

EnCrit
En

DmpShofOa Ag. DmpShof

SmextSu Cp:BI

On/P14 Open/P14
E,U

ErcRo DmpShof

EnCrit

On
SmextSu

En
FireDet Cp:BI
E,U

On/P14
EmgOff

En

EmgOff

TSu
On
Frost

En

Sequence table
On
OpModSwi Cp:MI
E,H

Ax: DMUX8_BO

DmpMx Ag: DmpMx

En
OpMSwiCnv

TSu
En
On
Cp:MVAL_OP
OpModMan

Cp: V(A) StupPrg

SttUpMod
En

TOa
En
O&M

TSu
En

DefVal:Off

Frost
Cp:BSCHED
Sched

TOa
On

En

En

Figure 39: Structural overview: Sequence control for a ventilation plant

The block CMD_CTL controls and monitors output and value blocks mapped on
BACnet. Communications is based on BACnet referencing rather than
interconnections to optimize the costs of engineering. The following blocks can be
used with CMD_CTL: AO, BO, MO and AVAL, BVAL and MVAL.
The sequence is determined in the CMD_CTL in a table. The command for the
individual aggregates and the components can be determined based on the plant
operating mode.
The main functionality of the block CMD_CTL is the sequential control of
aggregates and components dependent on the preset plant operating mode

72 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

[ValPgm]. For this purpose the switch-on sequence is defined by the order in the
function table [FnctTb]. The switch-off sequence is the reverse of the switch-on
sequence. Independent switch-on and switch-off sequences are not implemented
in this block.
Switched on block can be monitored for their states. There is no monitoring of the
OFF status.
Prior to switching on a block a test is made to see if the conditions for executing a
command are given. The switch-on process is not even available for active switch
on delay, minimum switch off times or a switch command with a higher command
(for example, a maintenance switch). This Look Ahead mechanism is described in
greater detail in this chapter.
This block does not contain interlocks of individual functional units within
aggregates. These are implemented locally via the data flow between the relevant
blocks.
Plant Control Editor The block parameters are set in the Plant Control Editor.

Figure 40: Plant Control Editor

The upper part of the dialog box serves primarily to provide a quick online overview
of the present plant operating mode. You can also define exception value which
become active as a plant operating mode during a plant fault.
The upper part of the table configures the sequences. The switch-on sequence of
the objects, the monitoring mode and the switch on and off types for the sequence
controllers can be defined here.
The lower part of the table is used to define the plant operating modes. You can
define what command at what priority is command per plant operating mode for
each sequence element.
The following priorities for commanding are available:
● Priority 2: Life safety, automatic
● Priority 5: Plant safety, automatic
● Priority 14: Specific command object
● Priority 16: System control
You can enable a command priority with the value Not command for plant
operating modes where the local control is intended to assume control of the
aggregate.
[DefVal] applies when the [PrioArr] for the corresponding block is empty, that is, not
active recognition set, at that time.
Function workflows in A series of safety, monitoring and switch actions are conducted for each change to
CMD_CTL the plant operating mode in block CMD_CTL. The following table includes an
overview of function workflows:

73 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

Stage Function Action

1 Safety function Check AllLifeSafety plant operating modes.

2 Preview Checks if the aggregates in question can be switched.

3 Abort sequence Incomplete sequences are interrupted.

4 Reset sequence Switch off unneeded aggregates.

5 Step-up sequence Switch on the newly needed aggregates.

6 Monitor switch-on states Start monitoring of countdown of delay period.

Table 18: Function workflows

Step 1: Safety function If all switch commands for a given plant operating mode have the priority Life
AllLifeSafety safety, it is referred to as the AllLifeSafety plant operating mode.
A pending AllLifeSafety plant operating mode in the [ValPgm] is executed
immediately in all cases and maintained regardless of previously existing and
newly occurring faults in the plant – human life takes precedence over plant safety.
If the AllLifeSafety mode includes switch-on commands, then the preset delay
times (Delay and Timeout) will be observed. However, in the case of the Timeout
setting, the switching sequence will continue even in the absence of any feedback
signal. Interlocks cannot therefore be guaranteed, with the exception of local
interlocks implemented via Priority 1 (life safety, manual).
Priority 1 (life safety, manual) cannot be overwritten in the AllLifeSafety.
Step 2: Preview Look Before changing to a different plant operating mode, in which referenced blocks
Ahead are to be enabled, block CMD_CTL checks to ensure that all the aggregates can
actually be enabled. For this purpose, the entries in the priority array [PrioArr] for
the switching sequence blocks are checked in advance. If switch commands of a
higher priority are found to be active (for example, a minimum switch-off time or the
OFF-command of a repair switch), then CMD_CTL waits to implement the new
plant operating mode until the full switching sequence can be implemented. Only
referenced blocks, for which a switch-on command exists in the new plant
operating mode, are checked, and only if the operating-state monitoring feature
has been enabled.
The following priorities are checked:
● Priority 1 [EnSfty/ValSfty], life safety, manual.
● Priority 7 [EnSwi/ValSwi], manual operation, for example, manual switch.
● Priority 8 [EnOp/ValOp], manual operation, operating unit.
● Priority 6 [TiMinOff], minimum switch off time.
Priority 6 is checked only for a switch on command to determine whether the
aggregate is still within the minimum switch off time. In this case, it waits until the
switch off time expires and only then switches on.

There is no Look Ahead for Desigo 7.

Priority 4 (plant safety, manual [EnCrit/ValCrit]) is not considered during the check,
since local mutual locking via data flow interconnection, such as depicted in the
figure Cross-aggregate interlocking of damper/fan, would change this value during
the switch-on process.
The present operating mode remains until it is certain that all impacted aggregates
with active operating state supervision can be switched to the new set state. A
process alarm is triggered in CMD_CTL of a monitored block is not switched on.
The exception value [EcptVal] is active as the new plant operating mode in this
case. The online diagnostics for the Plant Control Editors determines which
element is the cause of the fault.

74 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

Step 3: Abort sequence On-going switch sequences are aborted when delay times are still active.
Exception: An alarm is generated when a fault occurs as part of internal monitoring
of the block. The demanded plant operating mode is determined in this cased by
the exception value [EcptVal]. If the switch sequence is active, but not completed, it
is NOT aborted, but rather is completed.
Step 4: Ramp-down The ramp-down sequence is started first for the new plant operating mode. This
sequence shuts down all aggregates that must be switched off per the new plant operating
mode. The shut down takes place in the table sequence from right to left, in other
words, the last aggregate in the switch sequence is the shut down first. The
parameterized times for the time off delay are active during ramp down to off. The
time off delay can be activated using a fixed delay time or a maximum timeout or
deactivated using the immediate option. The length of the delay for timeout
depends on the switch off state of the monitored sequence elements. Transition to
the next sequence occurs as soon as it reports switched off, that is, the process
value of the block [PrVal] = Off. It switches after the timeout time expires when the
shut-down message is not sent.
If a sequence element with a life-safety or plant-safety priority is switched off, the
preset delay times will be ignored.
Step 5: Step-up sequence The step-up sequence is then started for the new plant operating mode. The
remaining aggregates are switched on per the data in the function table. The
switch on takes place in the table sequence from left to right, in other words, the
first aggregate in the switch sequence is the switched on first.
The parameterized times for the time on delay is active during step-up.
The step-up delay can be activated using a fixed delay time or a maximum timeout
or deactivated using the immediate option. The length of the delay for timeout
depends on the switch on state of the monitored sequence elements. Transition to
the next sequence occurs as soon as it reports switched on, that is, the process
value of the block [PrVal] <> Off. It switches after the timeout time expires when
the switch on message is not sent.
When a sequence element with a life-safety or plant-safety priority is switched on,
the preset delay times will take effect first.

Step 6: Monitoring switch A process alarm (off normal) is generated when the monitored aggregate is not
on state switched on after the sequence delay time expires.
The current switch sequence is immediately aborted when the current plant
operating mode is not AllLifeSafety and the exception value [EcptVal] is selected
as the operating mode.
If, however, the exception value [EcptVal] is already the plant operating mode, the
switch sequence is not aborted and the plant operating mode does not change.
Switch on aggregates The following figure shows the switch response and monitoring mechanism for
block CMD_CTL.
The system initially checks if the new plant operating mode is an AllLifeSafety
mode. The Look Ahead check takes place in the second step, followed by the
check and abort of on-going sequences. The next step is to run the shut-down
series, where objects 8 and 4 are switched off to the extent they have not yet be
shut down. The sequences are then switched on one after the other in the follow-
on switch on series.

75 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

Sequence 1 Sequence 2 Sequence 3

Object nr. 1 2 3 4 5 6 7 8

State monitoring None None None None

Switch-on mode Delayed

Switch-on delay 00:30 01:00 02:00

Switch-off mode Delayed Delayed Delayed

02:00 01:00 00:30

Operating states

Stage X On On On Not cmd On On

Priority Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd

Sequence 1
Objects 1, 2 and 3 are switched on in parallel.
Switch-on 1 Switch-on 2 Switch-on 3 As soon as 1 and 3 transmit an On signal
or the 30 sec. timeout expires,
the transition to the next sequence starts.

Timeout 0:30

Sequence 2 has no active switch-on command

Sequence 2
in stage X, and is therefore skipped.
(Off)
4 5

Sequence 3
Objects 6 and 7 are switched on in parallel.
Switch-on 6 Switch-on 7 The state monitoring mechanism waits
8 max. 2 minutes for objects 6 and 7 to
transmit an On signal.
Object 8 is inactive in stage X.
Timeout 2:00

Figure 41: Switch on from Off to Stage X

The set time (delay or timeout) marks a switch on or off sequence that may consist
of one or more objects. The times apply for the entire sequence and take effect,
when a switch on or step up command or a switch off or ramp down command is
demanded.
Switch on occurs in parallel per sequence. A check of the switch on state occurs
only in the switch on type timeout. The next sequence is only started after either all
monitored objects report a switched on state or the timeout period expires.
Operating state monitoring of the objects for monitoring, as depicted in the
following figure, only become active after the step-up process for a sequence is
completed.

76 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

Sequence 1 Sequence 2 Sequence 3

Object nr. 1 2 3 4 5 6 7 8

State monitoring None None None None

Switch-on mode Delayed

Switch-on delay 00:30 01:00 02:00

Switch-off mode Delayed Delayed Delayed

02:00 01:00 00:30

Operating states

Stage X On On On Not cmd On On

Priority Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd

Switch-on control of objects:

Check if switch-on time reached
Sequence 1

Switch-on procedure Object switch-on:

completed: No check if switch-on
Stae monitoring active state reached
Sequence 2

Object switch-on:
Switch-on procedure completed: Check if switch-on
State monitoring active state reached
Sequence 3

Switch-on procedure completed: State monitoring active

Figure 42: Switch on of blocks and status monitoring

Operating status monitoring is optional and monitors only blocks in a Switched on

state. If a referenced block is found to be switched off during active operating state
monitoring, but that the block should have been in the state Switched on, a process
alarm is generated and the plant operating mode changes to exception value
[EcptVal].
The momentary alarm state is visible from the state flag [StaFlg].
Sequence 1 Sequence 2 Sequence 3

Object nr. 1 2 3 4 5 6 7 8

State monitoring None None None None

Switch-on mode Delayed

Switch-on delay 00:30 01:00 02:00

Switch-off mode Delayed Delayed Delayed

02:00 01:00 00:30

Operating states

Stage X On On On Not cmd On On

Priority Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd

Figure 43: Operating state monitoring

Monitoring is active from the point when the corresponding sequence successfully
completes the switch on process, that is, the process value for block [PrVal] is not
equal to Off and the transient state is completed [TraSta] = No.
The [PrVal] of the block will be monitored. Hence, only those events which affect
[PrVal] can be detected, that is:
● Local fault shut down using interconnection of fault [Dstb] to enable safety,
manual [EnSfty].
● Local shut down of the block in a higher priority application program.
● Switch-off by manual operation of the output module if the I/O module returns
the manual setting value.
● Block switched off via HMI operation or manual switch in control panel
Command control is only in a position to recognize fault-related deviations and act
accordingly when the interconnection of all relevant faults [Dstb] occur locally on a
monitored output of value block to [EnSfty]. Its default value [DefVal] becomes the
process value [PrVal], if a referenced output or value block is out of service

77 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

[OoServ]. The state monitoring of the plant cannot operate correctly, since [PrVal]
no longer reflects the actual state of the aggregate.
To reduce the frequency with which aggregates are switched on and off, it is
possible to define a minimum switch-off time [TiOffMin] in the aggregates. The
look-ahead mechanism in the CMD_CTL block prevents the switching of the whole
sequence if the minimum off-time in one aggregate with active state-monitoring has
not yet expired. The output [TraSta] shows the transitional state and [PrVal]
remains unchanged, at the last value. The new plant operating mode will be
implemented only when all the aggregates to be enabled in the switching sequence
can actually be enabled.
A minimum off-time should always be set for aggregates incorporating a rotating
mass (for example, fans).
Operating mode The following figure shows a changeover from operating mode Stage Y to Night
changeover cooling.
All objects were switched on in Stage Y. During the changeover to Night Cooling,
the system initially checks whether the new plant operating mode is an
AllLifeSafety mode. The Look Ahead check takes place in the second step;
followed by the check and abort of on-going sequences.
In the next step, the switch off series is conducted where the sequence elements of
switch off sequence 1 are switched off in parallel. It transitions to the second
sequence after the delay time expires. Object 5 is commanded to Off with plant
safety, priority 5. For plant safety or life safety (priority 2), the delay times or
timeouts have no effect. The transition to switch-off sequence is immediately since
object 4 is already switched on.
Sequence 1 Sequence 2 Sequence 3

Object nr. 1 2 3 4 5 6 7 8

State monitoring None None None None

Switch-on mode Delayed

Switch-off delay 00:30 01:00 02:00

Switch-off mode Delayed Delayed Delayed

02:00 01:00 00:30

Operating states

On On

Priority Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd Spec. cmd
Sequence 1

Objects 8, 7 and 6 are switched off in parallel.

Switch-off 8 Switch-off 7 Switch-off 6 The transition to sequence 2 occurs as
soon as the 30 sec. delay has expired.

Delayed 0:30

Object 4 remains on, object 5 is

Sequence 2

switched off at priority level 5. The transition

Switch-off 5 to sequence 1 occurs immediately
4
without delay.

Delayed 1:00
Sequence 3

Objects 3 and 2 are switched off in parallel.

Switch-off 3 Switch-off 2 1 Object 1 remains on.

Delayed 2:00

Figure 44: Block switch-off

Objects 3 and 2 are switched at the same time as object 5. Object 1 remains
switched on.
Alarm management Block CMD_CTL is alarmable and differentiates process from system alarms.
A process alarm occurs, when:

78 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

● One of the monitored aggregates is not switched on.

● One of the referenced aggregates cannot be switched on.
The exception value [EcptVal] becomes the present plant operating mode as a
reaction to a process alarm. In addition, an alarm is sent.
A system alarm occurs for the following configuration efforts:
● A referenced aggregate is not available.
● A referenced aggregate is not a commandable object.
● Impermissible priorities are used (priorities 2, 5, 14, 16 are allowed).
● [ValPgm] or [EcptVal] are outside the permissible range.
● The referenced aggregates have a different number of operating modes.
The command control attempts for a system alarm to enable all referenced blocks
for local control. The four commandable priorities are commanded – in other words
enabled to Not commanded: Life safety (2), plant safety (4), specific command
control (14) and system control (16).
The response of the block to an alarm can be defined. The following mechanisms
have been incorporated to prevent hunting in the plant.
● Basic and standard: When the block goes into alarm, the exception value
[EcptVal] is switched. When all the aggregates are ready for switching again,
CMD_CTL automatically tries to implement the present plant operating mode
[PrVal]. If all the aggregates are ready for direct switching immediately after
implementation of the exception value [EcptVal], hunting is likely to occur. In
this case, CMD_CTL prevents any further switch-on attempt, and the required
plant operating mode [PrVal] must be changed.
● Extended: When the block goes into alarm, the exception value [EcptVal] is
switched. The alarm has to be reset by the user, and there is therefore no risk
of hunting.

The block is not alarmable for Desigo 7.

Out of service The block can be taken out of commissioning using [OoServ]. The following occurs
when switching [OoServ] to On:
● Immediately abort of switch on and off sequences and monitoring.
● All objects are commanded with a release of the priorities: Life safety (2), plant
safety (4), specific command control (14) and system control (16)

Superposed power control PWR_CTL

The power control function block PWR_CTL is used for control and monitoring of
the performance of a number of energy producers (multiple boiler systems,
refrigeration machines, etc.). As is the case for command control CMD_CTL, the
data is exchanged bilaterally between power control and the individual energy
producers (boiler, refrigeration aggregate, among others), via referencing. Since
the energy producers are generally implemented in the form of logical aggregates,
and contain local logic, the PWR_CTR block communicates only with MVAL blocks.
The control strategy is based on the use of tables and is designed for multi-stage
energy producers. Additional energy-producer stages are connected or
disconnected in accordance with the actual power demand. For modulating energy
producers, a stepped output is converted into a proportional output within the
aggregate. This makes it possible to handle the full power range (0…100%) in one
stage, or to divide the power range into several stages (for example, Stage 1:
0…20%; Stage 2: 20…40%; etc.).

79 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

Figure 45: Overview of PWR_CTL for control and monitoring of energy producers

Plant Control Editor The block parameters are set using the Plant Control Editor.

Figure 46: Plant Control Editor Aggregate tab

The upper part of the dialog box serves primarily to provide a quick online overview
of the block. The maximum power controlled by the block is set with the maximum
power parameter [MaxPwr]. The value must be greater than 0 kW in order for the
block to work. Any changes in this limit value have a direct effect in online mode. If
no limit value is required, the maximum power must be set at an appropriately high
value.
The Aggregates tab is used to set the control variables of the aggregates (boiler,
refrigeration machine).

80 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

● Enable: Activation/deactivation of an entry if they are not released, aggregates

in the Profile table will be ignored.
● Command object reference: Reference (relative addressing) to multistate value
blocks [MVAL] of the relevant energy producer. During the configuration
process, all MVAL blocks at the same and at lower hierarchical levels are
displayed.
● Aggregate description: The reference to the value object provides access to
(and hence, knowledge of) all information in a special dialog box via the
referenced object in the control command.
● Switch-on delay: Delay time when switching from OFF to Stage 1.
● Switch-off delay: Delay time when switching from Stage n to OFF.
● Step-up delay: Delay time when switching from Stage n up to Stage n+1.
● Step-down delay: Delay time when switching down from Stage n to Stage n–1.
● Switch-on stage power: Power in [kW] at the lowest (that is, first) stage.
● Next power stage: Additional power at the next stage(s) in [kW].
The control sequences for the aggregates (boiler, refrigeration machine) are
defined under the Aggregates tab. Each profile describes the order in which the
energy producers are to be switched and the maximum stage in each case. A total
of 8 profiles each with 15 sequence entries can be defined.

Figure 47: Plant Control Editor Profile tab

The active profile table is defined by entering the profile number [PrfNr] as an input
parameter, or by selecting it from the Profile dropdown list in the Plant Control
Editor. This input parameter can be interconnected, so that the profile can be
changed as a function of other events (faults, summer mode, boiler operating
hours, etc.). If the profile is changed during operation, the power output [PrPwr] is
switched in accordance with the power profile in the new profile table.
The profile definition determines the order in which individual aggregates are to be
switched on or off. The following information must be entered for every sequence
entry:
● Object: Selected from the previously referenced aggregates.
● Stage limitation: Limit up to which the aggregate may be enabled.
● Control type: Specifies whether the enabled stages are to be switched
permanently or released to the control system.
– Fixed: The total power provided by a given switch stage is switched on or
off permanently. This option can be used, for example, for a specific base
load which is required to be present at all times. The command is
implemented with Priority 14.
– Enable: The power actually required from the released switch stage is
determined by local control of the aggregates. The command is
implemented with Priority 16.
For each sequence step, the function block only ever releases the last aggregate
marked Release to the control system. It displays this released object [RlsObj], with
the released object stage [RlsObjSt], at the output. All other aggregates are fixed at

81 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

the released stage value. If none of the aggregates is marked Release, the
aggregate of the current sequence step is released to the control system.
On/Off switching of When PWR_CTL is switched on [ValPgm = On], the first step in the sequence of
PWR_CTL the current profile is executed immediately. In this case, the switch-on delay is not
valid. If the trigger for default power is on [PwrTrg = On], the aggregate is switched
directly to the default power level [DefPwr].
A switch-off command [ValPgm = Off], disables all the energy producers defined in
the profile table with Priority 14.
Out of service If the PWR_CTL function is taken out of service [OoServ = On], then all referenced
aggregates are switched OFF with Priority 14, without taking account of delay
times. The monitoring of the aggregates is disabled.
Demand signals The current power demand is determined locally in the energy producers. In the
event of a power deficit or surplus, the aggregate will send the appropriate demand
signal to the PWR_CTL block. The demand signal from the aggregate can be
generated, for example, on the basis of the boiler setpoint deviation and the
primary flow. The demand signals of the separate aggregates are combined and
transmitted to the [StepUp] or [StepDn] input of the PWR_CTL block. After expiry of
the relevant delay times, the block executes the appropriate sequence step to
increase or reduce the power, as necessary.
When both [StepUp] and [StepDn] demand signals are present simultaneously,
[StepDn] takes priority.
Direct switching of a load In cases where the power is to be increased or decreased without observing the
delay times, the default-power trigger input [PwrTrg] can be used to switch to a
defined default power level [DefPwr]. From the current profile, and taking account
of the current power output, the PWR_CTL block determines the sequence steps
required to cover the power demand and implements them directly.
Power display The block has two outputs at which it displays the current total power of the energy
producers. This consists firstly of the controlled power output [CtldPwr]. This output
represents the total power switched by the PWR_CTL block.
The other output, the present power output [PrPwr], shows the additional power
output of energy producers that are not directly switched by PWR_CTL. To do this,
PWR_CTL evaluates the priority array [PrioArr] of the MVAL blocks. In this way it
can detect, for example, that an energy producer has been switched manually
[Prio8] to a given stage.
Configuration error The entries in the two configuration tables are checked cyclically for validity.
● A fault alarm is generated under the following circumstances:
● Aggregates no longer accessible from PWR_CTL, owing, for example, to
retrospective modifications to the technical hierarchy, affecting the references
of the energy producers
● Retrospective changes to the stage-limit value in the aggregate, making the
value configured in the profile table too high
● No multistate value object
● Reference block no longer available: For example, deleted with delta download
● Several references to the same block
● Empty profile table
In the event of a fault alarm, all aggregates still accessible by PWR_CTL are
switched OFF permanently.
Alarm management The PWR_CTL block in the system is an alarm-generating block with a
configurable alarm class [AlmCl] and alarm function [AlmFnct].
An Offnormal process alarm is generated:

82 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

● When the step-up demand signal [StepUp] persists for longer than the
monitoring time deviation [TiMonDev], and there are no further sequence steps
to increase the power.
● When the step-up demand signal [StepUp] persists for longer than the
monitoring time deviation [TiMonDev] plus the step-up delay time of the next
sequence step, AND a step-up would cause the maximum power limit [MaxPwr]
to be exceeded.
The process alarm is reset to normal:
● When a sequence step with an increase in power becomes possible again.
Another sequence step with an increase in power becomes possible when the
[MaxPwr] limit will no longer be exceeded, or when a further sequence step
with a power increase is present.
● When there is no further [StepUp] demand signal
The text of process alarms can be defined to suit customer requirements.

For Desigo S7 the PWR_CTL block is not alarmable.

Switching alternatives Various switching alternatives can be defined by entries in the profile table. Note
that where one or more step-up sequence steps (intended to increase the power)
would, in practice, result in a drop in the power output, all steps in the step-up
sequence are enabled automatically until a sequence entry is reached, at which
the power output actually does increase as required. See also the following
example.

Figure 48: Example of aggregate table

The power data in the object table and the sequence entries in the profile table in
Figure Example of aggregate table together give the power profile illustrated in
Figure Example of profile entries with a drop in power (Profile 2) .
Profile 1
In the main application of the PWR_CTL function, a new energy producer is added
for each sequence entry in the profile table. For this purpose, an aggregate only
needs to be entered in the sequence table once.
In the event of a power demand, which the boiler transmits to the PWR_CTL
function in the form of the [StepUp] demand signal, a further boiler stage /
sequence step is enabled when the step-up delay has expired. When a boiler
reaches the stage limit, the function switches to the next boiler or boiler stage after
expiry of the switch-on delay. The last-enabled boiler stage is released to local
power control, while all other boilers are fixed at their current power output.
If the power needs to be reduced, this is transmitted to the PWR_CTL function via
the [StepDn] demand signal. The sequence steps are then executed in reverse
order, with the defined switch-off and step-down delay times.

83 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Superposed Plant Controls

Figure 49: Example profile table using a normal power profile

Figure 50: Example profile table using a normal power profile

Profile 2
Profile 2 shows that the order in which boiler stages are to be enabled has been
changed, and that sequences which will cause a drop in the power output have
been defined in the power profile. In the example illustrated, Boiler 3, which is
currently delivering 200 kW, is switched OFF via sequence entry 2. Boiler 1, which
could achieve a power output of 150 kW with its enabled stages, is defined as the
next object in the sequence. This results in a drop in the power output, causing the
function block to enable all sequence steps automatically until an actual increase in
power is achieved.
In sequence entry 4, Boiler 2 is enabled up to stage 2, giving a further 150 kW
output. Boilers 1 and 2 are thus enabled simultaneously up to stage 2, to prevent a
drop in power. The effective delay time for the simultaneous switching process is
determined the maximum delay time of the boilers concerned. Since it is Boiler 1
which has the longest delay (15 minutes), the simultaneous switching operation will
be delayed for this period of time.

84 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Superposed Plant Controls
4

Sequence entry 5 would again result in a drop in performance, because stage 2 of

Boiler 2 is no longer enabled. The block therefore switches straight to sequence
entry 6, enabling Boiler 3 to compensate for the power deficit. In this case the
effective switch-on time is based on the switch-on delay for Boiler 3 (10 minutes).

Figure 51: Example of profile entries with a drop in power

Figure 52: Example of profile entries with a drop in power

Online diagnostics A diagnostics screen for the PWR_CTL block is available online in Xworks Plus
(XWP).

Figure 53: Plant Control Diagnose

85 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Closed-Loop Control Strategy

The following states are displayed:

● Present value: Operating state at the block output pin [PrVal]
● Action: Transient state [TraSta] depending on actual switching conditions: Up,
down or hold
● Present power: Value at the block output pin [PrPwr]
● Status flag: In accordance with the BACnet definition, the value of [StaFlg] is
always Overridden. Alarms may also be displayed here.
● Released aggregate or stage: This shows the current sequence entry, the
released object [RlsObj] and the released object stage
● Last alarm/event message: Value at the block output pin [LstMsg]

4.4 Closed-Loop Control Strategy

Controller types
For closed-loop control purposes, two controller blocks are provided in the Desigo
system, which cover the majority of requirements:
● [PID_CTR]
● [CAS_CTR]
PID_CTR stand-alone The PID_CTR block is used as:
controller – Sequence ● A universal stand-alone PID controller
controller
● A universal PID controller with external tracking
● An individual sequence-controller element in a sequence controller or
sequence cascade controller
The PID_CTR block integrates the following functions:
● Can be programmed for P, PI, PID or PD control action
● Gain, integral action and derivative action can be programmed individually
● Proportional control output with minimum and maximum limit control
● Programmable gain factor
● Programmable neutral zone
● Programmable offset (for P and PD controllers)
● Programmable initial integrator value (for PI or PID controllers)
● Programmable runtime for control variable (0 – 100%, 100 – 0%) and
positioning speed
● Type of operation (direct acting or reverse acting) can be selected
A sequence controller can be implemented by interconnecting several PID_CTR
blocks. The sequence linker SEQLINK can also be used, where appropriate. The
only function of this block is to enable individual sequence elements to be deleted
without the need to create new connections.
CAS_CTR cascade The PID_CTR block is used:
controller ● As the master controller in a sequence cascade control configuration (for
example, room/supply air cascade).
● In temperature and humidity control loops
The following functions are integrated in the CAS_CTR block:
● Can be programmed for P, PI, PID or PD control action
● Proportional controller output with minimum and maximum limit control
● Setpoints for heating and cooling sequences, and for energy recovery
● Setpoint depending on type of operation, for energy recovery
● Initialization of integrator (initial value)

86 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Closed-Loop Control Strategy
4

Universal PID controller

The PID_CTL block can be used as a universal stand-alone controller in a plant for
the control of any control variables. For example:
● Temperature, temperature differential
● Pressure, pressure differential
● Velocity
● Absolute humidity, relative humidity

Figure 54: PID_CTR block

Control action The PID_CTR block can be configured as a P, PI or PID controller. The following
parameter settings are used to define the control action:
● Gain [Gain]
● Integral action time [Tn]
● Derivative action time [Tv]
As an option, the gain [Gain] can be influenced with the [GainFac] input. It can be
useful to correct the gain factor in this way when controlling outside air dampers,
for example, as the effect of the damper positions can depend on the outside air
temperature. The correction factor is defined with the gain scheduling block
ADAGAIN.
The actuator runtime can be set. Specifying the actual actuator run-times makes it
possible to tune the controller more accurately to the actuator concerned, so
improving the control quality of the control system.
Correcting range The correcting range is limited by specifying the minimum and maximum output
variable. In this process, the minimum of the two values is always set as the
maximum value. In other words, the maximum value may be below the minimum
value; there is no need to update the minimum value.
Neutral zone [Nz] [Nz] is a zone on either side of the setpoint, within which the controller does not
respond. As soon as the difference between the setpoint [Sp] and the measured
value [Xctl] is less than half of the [Nz], the output is driven for a further 7 cycles,
so that the measured value [Xctl] is as close as possible to the middle of the [Nz].
The output signal [Yctr] then remains constant. The output signal is only re-
adjusted when the parameters move outside the [Nz] again.

Figure 55: Controller response in the neutral zone

87 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Closed-Loop Control Strategy

P/PD controller If the PID_CTR block is configured as a P-controller or PD-controller, a calibration

point (Offset) [YctrOfs] can be specified. For example, the P-controller can be
calibrated so that the set point is maintained with a 50% load.
With a 0% or 100% load, the P-deviation is then half the amplitude of the
proportional range [Gain].

Figure 56: Calibration point (Offset) for P and PD-controllers

Tracking [Track] [Track] is used, for example, where the PI(D) controller, operates as a limit
controller, for example, acting on a valve or actuator via an intermediary minimum
or maximum selector block. The tracking input ensures the availability of the
controller during the period in which it is blocked by the minimum or maximum
selector block. During this time, its integrator (and, hence, its output) is maintained
at the value of the signal received, so that if the limit conditions are violated, it is
able to respond immediately. [Track] is also used in conjunction with special
actuators with positioning feedback.

Direct/reverse-acting [Actg] is a characteristic parameter of the controller and indicates the relationship
control action [Actg] between the setpoint deviation and the change in energy flow. A distinction is
made between direct action and indirect [Actg].
● Direct control [Actg]: As the controlled variable rises, the controller output
increases, and as the controlled variable falls, so the controller output
decreases.
Example: Cooling or dehumidification – as the measured value rises above the
setpoint, so the flow of energy is required to increase.
● Indirect control [Actg]: As the controlled variable decreases, the controller
output decreases.
Example: Heating or humidification – as the measured value falls below the
setpoint, so the flow of energy is required to increase.

Figure 57: Control action [Actg] with P controller

Inversion [Inv] [Inv] of the output signal is required, for example, for air dampers. The outside air
and exhaust air damper must close in response to an increasing heating demand.
The inversion of the manipulated variable affects only the output signal [Yctr] and
not the action of the controller.

88 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Closed-Loop Control Strategy
4

Sequence controller
Sequence controllers are used primarily in ventilation and air conditioning systems
to control the temperature and humidity. Other applications are also possible, for
example, in heating systems.
Each controlled aggregate functional unit incorporates a universal PID controller
function block, PID_CTR, as a sequence-controller element.
The statements made about the universal PID controller also apply to the use of
the PID_CTR function block as a sequence-controller element.
The sequence-controller elements coordinate their own interaction independently.
Interaction is coordinated with coordination signals [FmHigher] and [ToLower],
which are mutually exchanged by adjacent sequence-controller elements. This is
the only link between the sequence-controller elements. This process allows the
setting of individual parameters for each individual controller or aggregate, and
hence effective optimization of the entire plant.

Figure 58: Example of a sequence control

Properties and design of sequences and sequence controllers:

● Each sequence may include any number of elements
● The setpoint for each element of a sequence can be defined separately, but set
points must not be allowed to decrease in the direction from the heating
sequence to the cooling sequence.
● The setpoint for energy recovery can be selected and is either at the midpoint
between the setpoint of the first heating element and that of the first cooling
element, or (depending on the method of energy recovery currently possible), it
may be equivalent to the setpoint of the first heating element (if the extract air
temperature is higher than the outside air temperature) or equivalent to the
setpoint of the first cooling element (if the extract air temperature is lower than
the outside air temperature).
● The gain of each sequence element can be influenced individually. In this way,
for example, the amplification factor (gain) of the energy-recovery element
varies as a function of the difference between the extract air temperature and
the outside air temperature, in order to achieve an almost constant loop gain.
● For each element, P, PI, PID, PD or on/off control can be selected. The control
parameters for each element (controller gain, integral action time and derivative
action time) can be adjusted individually.

89 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Closed-Loop Control Strategy

● If all the sequence elements have the same parameter values, the sequence
responds in exactly the same way as a single PI(D) controller whose output
variable is distributed to individual aggregates within the plant.
● The controller output and the integrator of the sequence element is limited in
the range [YctrMin] to [YctrMax]. For this purpose, the high limit of the last
enabled sequence element of the heating and cooling sequence is limited with
an anti-windup strategy (limitation of I/portion on manipulated variable limits).
All other limit values are controlled by straightforward selection of the minimum
or maximum value.
● The rate of change of the output of each sequence element is limited to the
speed of the connected actuator. This helps improve control quality.
● The type of operation of each element (heating/cooling or
humidification/dehumidification) can be selected individually for each element.
● Only one element of the sequence can have a controlling function. When the
output of a controlling sequence element reaches [YctrMin] or [YctrMax],
control is transferred to the nearest adjacent active element ("ON").
Naming convention The term higher is applied to sequence elements that correspond to higher set
points in the sequence diagram (normally cooling or dehumidification).
The term lower is applied to sequence elements that correspond to lower set points
in the sequence diagram (normally heating, energy recovery or humidification).
Configuration of a Essentially, the sequence controller consists of individual PID_CTR blocks. with
sequence controller each PID_CTR block acting as a sequence-controller element for an aggregate.
The PID_CTR blocks are connected (from "Low" to "High") in the same order as
the control sequences (1…n) of the sequence controller. Accordingly, the
connection of the PID_CTR blocks must take account of the intended operating
range (for example, for heating) and the order of switching.

Figure 59: Control action [Actg] of the sequence-controller elements

For example, aggregates:

1 = Re-heater, 2 = Pre-heater, 3 = Dampers, 4 = Cooling coil
Control series for heating: 3 ---> 2 ---> 1
Cooling control sequence: 4 ---> …
The lowest sequence-controller element (Low) corresponds to control sequence 1,
and the highest (High) to control sequence n.
The lowest sequence-controller element controls a reverse-acting aggregate (if
used).
The type of operation may also be reversed during normal operation, (for example,
for energy recovery) but the order of the sequences must not be affected.
In the sequence controller, the set points [Sp] of sequence-controller elements
(1…n) must increase incrementally:

90 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Closed-Loop Control Strategy
4

[Sp]1 ≤ [Sp]2 ≤ [Sp]3 ≤ ... ≤ [Sp]n

In the transition from one control sequence to the next, continuous control is
maintained if all the control sequences with the same type of operation (direct or
reverse acting) also have the same setpoint.

Figure 60: Setpoints of the control sequence elements

When the type of operation changes, the neutral zone is defined by the set points
(for example, heating setpoint / cooling setpoint).

Figure 61: Zero energy zone

Options for connecting The PID_CTR blocks can be connected to form a sequence controller via:
sequence controller ● Direct connection
elements
● SEQLINK connection
Direct connection
The individual PID_CTR blocks are connected directly with each other. The
[ToLower] pins are connected to the [FmHigher] pins, and the [FmLower] pins are
connected to the [ToHigher] pins.

Figure 62: Direct connection of the PID_CTR block

SEQLINK connection
With this method, the individual PID_CTL blocks are connected via the SEQLINK
block. The sequence linker block SEQLINK is a wiring block with no function other
than that of connecting other blocks.

91 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Closed-Loop Control Strategy

Figure 63: Connecting a sequence controller using [SEQLINK]

The connection is made between the pins of block PID_CTL and a location on the
SEQLINK block. The order in which the PID_CTR blocks are connected must be
the same as that of the sequence. The connections to the SEQLINK block need
not be continuous: connected pins and unused pins may be interspersed.
For example, 1 = Re-heater, 2 = Pre-heater, 3 = Dampers, 6 = Cooling coil.

Figure 64: Connection details with interface names

This method of connection is used to interconnect PID_CTR blocks on different

charts, or in cases where individual project-specific sequence-controller elements
or aggregates are to be deleted from an off-the-shelf solution (CAS library).
Communication between one sequence controller element and another flows via
the pins [ToLower] → [FmHigher] and [ToHigher] → [FmLower].
The block recognizes configuration errors and shows these at the Token State
output [TknSta]. If, for example, the control action [Actg] of an individual sequence-
controller element is incorrectly set, the associated sequence controller element is
disabled and an error message is displayed.

Figure 65: Example: Output from elements 4 and 6 [TknSta] = HEL_CSEQ Output from elements 3 and
5 [TknSta] = CEL_HSEQ

Figure 66: Examples of automatically deactivated sequence elements

92 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Closed-Loop Control Strategy
4

In all the examples illustrated, several aggregates are deactivated. This is a

precaution, as the sequence elements cannot determine which of the aggregates
has incorrectly set parameters. For this reason, the aggregates are disabled one
after the other until there is a clear transition to the next sequence.

Cascade control
The CAS_CTR block integrated into the Desigo system is a PI master controller for
room supply air cascade control. It delivers three supply air set points on the basis
of the difference between the measured room temperature and the room setpoint.

Figure 67: CAS_CTR block

The following functions are integrated into the block:

● Facility to select P or PI control
● Gain and integral action time (can be configured)
● Low supply air setpoint for the reverse-acting part of the sequence
● High supply air setpoint for the direct-acting part of the sequence
● Supply air setpoint for energy recovery
● Min/Max setpoint limit control (supply air setpoint)
● Selection of type of operation for heat recovery
● Initial value for the integrator can be defined

Figure 68: Basic cascade control structure

Compared with control without a cascade, for example, cascade control improves
the dynamics of the control process.
If the temperature in a ventilated room is below the setpoint, for example, the
supply air temperature must be increased, at least for a brief period, in order to
raise the temperature to the room setpoint. This can be achieved by measuring
and controlling not only the room temperature, (that is, the value which actually
concerns the user), but also the supply air temperature, whose setpoint depends
on the difference between the room setpoint and the room temperature.
If the room temperature is lower than the room setpoint, the supply air setpoint is
adjusted in proportion to the room control differential, and the supply air
temperature is increased via the supply air control loop.
The master controller generates the setpoint for the auxiliary variable (for example,
the supply air temperature) on the basis of the difference between the primary
setpoint and the primary controlled variable (for example, the room setpoint and
the room temperature).
The master controller must include an integrator function (I component), because
even under static conditions (that is, when the measured value and the setpoint are
equal) there is generally a negligible control deviation, which means that the
controller output must be at a different operating point. For improved control
dynamics, a P-component should be connected in parallel with the integrator. This
is why the master controller in this case has a PI control structure.

93 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Closed-Loop Control Strategy

Even when the primary controlled variable (room temperature) is identical to its
setpoint, the auxiliary controlled variable (supply air temperature) must generally
be at a value other than 0, (that is, setpoint ≠ 0). This is only possible if the output
of the master controller is not equal to 0, even if the P component = 0. In other
words, the master controller must have an I-component which remains constant
when the control differential = 0. This is why the master controller has a
proportional and an integral component. It is a numerical PI controller for use as a
master controller in a room/supply air cascade.
To save energy in the ventilation plant, various room set points are selected for
different types of air handling (heating/cooling and humidification/dehumidification).
The master controller in the cascade must therefore be able to generate different
supply air set points, depending on how the kind of air treatment (heating/cooling
or humidification/dehumidification).

Figure 69: Supply air setpoints

The supply air controller must determine whether the heating or cooling sequence
is to be activated and the decision-making strategy does not affect the calculation
of the two supply air set points. Within the cascade control loop, the supply air set
points always move parallel to each other, and their offset is determined by the
integral component.
If the air handling plant includes an energy recovery aggregate, this aggregate may
be either reverse-acting (for example, heating) or direct-acting (for example,
cooling) depending on the relationship between the condition of the outside air and
the condition of the exhaust air.
To avoid external calculation of the energy recovery setpoint, this, too, is done by
the master cascade controller, and made available to the energy recovery
aggregate, if there is one, at a separate output pin:

Figure 70: Setpoint for energy recovery

In a humidity control system with various physical control variables, the initial value
of the integrator should be predefined.
Example:
If the humidity of the supply air is measured with an absolute humidity value [g/kg],
while the room air humidity is measured in terms of relative humidity [%Hu], an
initial value must be defined for the I-component, otherwise the mean value from
[SpLoR] and [SpHiR] will be used as the initial value. If the room set points are
expressed in terms of relative humidity, then the initial value for the integrator will
start at a numerically high value, and decrease as a function of the preset integral
action time [Tn]. The result of this can be that even if the room needs to be
dehumidified, the humidifier is enabled in the controller start-up phase until the
integrator reaches its correct value.

94 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

To prevent this, the current measured supply air humidity value is linked to the
initial value of the integrator, or a fixed parameter value is defined for the integrator.
If control accuracy is critical (for example, no deadband or zero-energy control
zone), then the current measured value is linked to the initial value of the integrator,
or a fixed parameter value is defined for the integrator.

4.5 Desigo Room Automation

Multiple mechanical and electrical installations (referred to as technical installations
in this chapter) come together in one room. These typically are HVAC, lighting, and
blinds. Each technical installation is automated and operated optimally from its
perspective. For Desigo Room Automation, coordination of the individual technical
installations must be optimized while considering that the same type of installation
may exist several times in one room.
Room featuring:
1. HVAC zone (blue)
2. Lighting zones (yellow)
3. Shading/blinds zones (green)

3 3

2
1

Figure 71: Room application sample with different mechanical and electrical installations

HVAC zone The room typically is considered 1 HVAC zone influenced via a common
automation and control strategy regardless of number and type of installed HVAC
plant components (for example, radiator, chilled ceiling, fan coil unit).
Lighting zone All lamps operated/automated together are grouped into a lighting zone regardless
of number and type of the installed lamps. A room typically has one or several
lighting zones.
Shading zone All shading products (blinds) operated/automated together are grouped into a
shading zone regardless of number and type of the installed shading products. A
room typically has one or several shading zones.

Desigo Room Automation and room coordination

Application function Specific functionality is set up for each zone of each technical installation: The
structure application functions. For Desigo Room Automation, this is supplemented by a
room-wide function coordination called room coordination.

95 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Figure 72: Overview of Desigo Room Automation application functions

Room coordination basically has two application functions:

● Cross-technical installation coordination to ensure smooth functional interplay
of the various installations
● Centralized, room-wide access point to operate and monitor a room
Cross-technical The application functions of the individual technical installations contain
installation coordination functionality required for technical installation-specific control. Additional
functionality assuming coordination with other technical installations is part of room
coordination. As a result, project-specific Desigo Room Automation requests and
changes can be carried out without changes to technical installation-specific
application functions.
Examples for coordination functions are coordination of HVAC and shading
functions and coordination of shading and lighting functions.
Centralized, room-wide Room coordination offers a centralized, room-wide access point to operate and
access point monitor a room. This allows users to enter common data for several technical
installations only once and retrieve them as a group.
Examples:
● Predefinition of the room operating mode (across all technical installations)
● Predefinition of a scene for the entire room
● Queries for general occupancy
● Common alarm for system alarms
The room coordination default solution influences the following functions:
Room operating mode Various sources influence and determine the room operating mode:
● Centralized commands from scheduler programs or manual intervention
● Local commands from presence detectors or scheduler program override
Room coordination offers a centralized, room-wide access point to operate and
monitor a room operating mode. The individual technical installations separately
acquire all relevant information.
Scene Scenes are defined to command several or all technical installations in a room via
one single command: For example, brightness of a lighting zone, or blinds
positions in each shading zone can be defined for each scene. Room coordination:
● Controls a scene as per the predefined values
● Changes the predefined values
Both are carried out by the room user.

96 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

Thermal room load Room coordination supports room temperature control via blinds control. The
analysis various HVAC data is analyzed to determine the thermal room load and the
associated signal definition for blinds control:
● Load if energy must be supplied to the room via the blinds position
● Unload if no additional energy must be supplied to the room via the blinds
position
Blinds control determines the optimal blinds position in dependence of room
occupancy and solar position (thermal radiation and glare).
Green Leaf Manual room user manipulations (for example, manual lighting and shading
(RoomOptiControl) commands, or manual changes to the room temperature setpoint) can result in
inefficient energy operation. Each zone and each technical installation is checked
for inefficient definitions to be pointed out to the room user. Room coordination
then summarizes the results and visualizes them on the room operator unit. The
room user can then reset all manual entries (which lead to inefficient plant
operation) by one single pressure of a button.
Room common alarm One common alarm is set up for each room to keep down the number of set up
system alarms. To this end, room coordination acquires status information
(normal/alarm) for each zone and each technical installation, and determines the
room-wide alarm state as a common alarm.

HVAC room control

HVAC plants and their HVAC devices in the room influence the climate in closed
rooms.
HVAC plants in rooms are used to:
● Maintain a temperature range suitable for building occupancy
● Control other control variables such as humidity and air quality
● Efficiently operate HVAC plants in the room
HVAC plants in the room are grouped into plant families differentiated by
mechanical design and functioning:

Figure 73: Examples for HVAC plant families in a room: radiators (right), Fan coil units (center), VAV
(left)

The members of the related HVAC family differ only marginally:

97 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Figure 74: Examples for members of the fan coil family

HVAC supply chain HVAC plants in a room consume energy. The supply chains outside the room
requirements supply air, water, or electricity to the room. Linked existing energy sources and
consumers are called supply chain. An air supply chain or a water supply chain
thus is an HVAC system with a supply/consumer relationship to the HVAC plant in
the room.
The supply equipment typically supplies more than one room, and the HVAC plant
in the room often is a consumer of multiple supply chains.
HVAC control basically has the same objectives as the entire HVAC plant:
● Maintain the room temperature in the selected comfort range
● Adapt the room temperature range to room user needs
● Supply, extract, and recirculated air to satisfy air quality and comfort needs
● Adapt the air flows to room user needs
Energy saving requirements:
● Devices for sequential control of a heating and cooling sequence and thus:
– Preventing sequence overlap (simultaneous heating and cooling)
– Using the most efficient energy source
● Reducing the temperature as soon as comfort mode no longer is needed
● Reducing ventilation as soon as it is no longer needed
Coordination of the HVAC supply chain:
● Operation of supply chain equipment as per user demand
● Optimization of operating levels (temperature, pressure) of the supply plant
● Prevention of damages to HVAC equipment
HVAC control structure An HVAC control application in the room is connected to the following:
● HVAC plant in the room via sensors and actuators
● Room coordination application
● Centralized coordination application for HVAC supply chain(s)
● Building operator via BAC workstations
● Building automation and control functions for scheduling
● Room user

98 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

Supply Chain
Room Coordination

Functions
User Request

HVAC Plant Control

WndCont PscDet

Figure 75: HVAC control structure

The HVAC control application in the room consists of two parts:

● Application function for user requirements
● Application function for HVAC plant control
The HVAC plant control contains a control module (CFC) that implements the
control functions associated with the HVAC device.
Control concepts The physical room conditions are controlled by a combination of control methods
(setpoints by operating mode).
Sequence control Algorithms for room temperature sequence control operate the heating and cooling
equipment within applicable limits. The algorithm for one single heating element is
as follows (for example, radiator):

Figure 76: Control algorithm for heating element

Below is an illustration of the temperature control sequence for a more complex

HVAC plant in the room. The charts show the segregation of heating and cooling
control sequences and associated setpoints and sequencing of heat convection by
fan air flow or associated switching stages.

99 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Heating nor Cooling

100%

0% TREff

Speed 3
Speed 2
Speed 1
FanSpdMin=Off TREff

SpH SpC

Figure 77: Temperature control sequence for complex HVAC plant

Individual temperature sequence controllers are assigned to each heating and

cooling element. They intercommunicate to achieve required sequencing.
Open-loop control Additional interactions between HVAC devices implemented via open-loop control
functions are required in an HVAC plant in the room. The open-loop control
functions feature two basic interactions:
● Support: Heating coil and cooling coil require the fan to run on the stage/speed
required for their operation.
● Lock: The electric heating coil is locked to ensure that it cannot be operated
without air flow.
Open-loop control and sequence controller are used together to implement the
above, typical control sequence.
The following display shows the connection between controller and actuating
devices (this does not correspond to the actual program structure).
FanDevMod=Mod
HclDevMod=Mod CclDevMod=Mod

AND AND

FanSpdMaxH FanSpdMaxC Room temperature

H2 H1 C1 C2
FanSpdMinH FanSpdMinC control
AirFlReqHeat
AirFlReqCool
FanSpdMin

Max

FanSpd HclVlvPos CclVlvPos

Figure 78: Open-loop control and sequence controller

100 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

Operating modes The HVAC plants in the room adapt to the room's comfort requirements. For
example, ventilation is:
Active while the room is occupied
Off, as soon as the room no longer is occupied
The following illustrations show sequence control for an HVAC plant in the room for
operating modes Comfort and Economy. Sequence control acts on heating and
cooling equipment and a multi-speed fan.
Plant operating mode Comfort

HCSta Heating Neither Cooling

Heat 2 Heat 1 Cool 1 Cool 2

100%

VlvPos VlvPos

0% TREff
HclHw01 CclChw01
AirFlReqHeat AirFlReqCool

Speed 3
Speed 2
FanSpd
Speed 1
FanSpdMin=Off TREff
FanMultiSpd01
SpH SpC

Figure 79: Control sequences in the Comfort operating mode

Plant operating mode Economy

HCSta Heating Neither Cooling

Heat 2 Heat 1 Cool 1 Cool 2

100%

VlvPos VlvPos

0%
HclHw01 CclChw01
AirFlReqHeat AirFlReqCool

Speed 3
Speed 2
FanSpd
Speed 1
FanSpdMin=Off TREff
FanMultiSpd01
SpH SpC

Figure 80: Control sequences in the Economy operating mode

The available operating modes determine both operation and basic control strategy
in the automation and control system at three different levels:
● The room operating modes determine the operation of HVAC equipment in a
room in terms of current use by the user. The room operating modes defined
for the room are available in all HVAC control applications in the room.
● The HVAC plant operating modes determine the operation the HVAC plant in
the room with regard to existing, physical plant processes. The HVAC plant
operating modes are defined specifically for 1 HVAC plant in the room.
● The device operating modes determine the operation of the HVAC devices in a
room by predefining their tasks and implementation method. The device
operating modes are defined specifically for each individual HVAC device.
The following table shows the plant and device operating modes of a plant with
heating coil, cooling coil, and fan. Project-specific adaptations of both plant and
device operating modes can be implemented by adapting the operating mode table.

101 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Plant operating mode Fan operating mode Heating coil operating mode Cooling coil operating mode
Off Off Off Off

Comfort Modulating Modulating Modulating

PreComfort Modulating Modulating Modulating

Economy Modulating Two-position Two-position

Protection Modulating Two-position Off

Heat up Modulating Two-position Off

Cool down Modulating Off Two-position

Table 19: Plant and device operating modes

In addition, setpoints and setpoint limits define room and device operating modes.
They can vary depending on the selected HVAC plant operating mode. Four
different setpoints are provided for heating and cooling in the room.
SpC

SpH
t
RClmOpMod Eco Cmf Eco
00:00 06:00 18: 00 24:00
Figure 81: Setpoints for room heating and cooling

The HVAC control applications in the room dynamically enable and disable the
setpoints to achieve the desired combination of energy-saving Economy and
demand-based Comfort operating mode.
Command priorities An HVAC control application simultaneously achieves several goals. Functions
with different objects may conflict when they are implemented. In this case, the
command priority determines which command value has priority in the priority array
of the BACnet objects.
HVAC control applications in a room are programmed to accept commands at
many different levels, including operating mode variable level. As a result, HVAC
control applications control the controlled output objects at a priority commensurate
with the active priority of the operating mode variable. The following figure shows
how commands and priorities are passed in the application.

102 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

Fire Detector
16 15 14 13 ... 8 7 6 5 4 3 2 1 RClmOpMod

Man / Auto Eco,Cmf

Fcu01

FcuPltMod01

Off

C ... 8 7 6 5 4 3 2 1
16 15 14 13 PltOpMod

Man / Auto Prot Emg

FcuDevMod01
Off Close Close Close
Eco Mod 2Pos 2Pos
Cmf Mod Mod Mod

16 15 14 13 ... 8 7 6 5 4 3 2 1 FanDevMod HclDevMod CclDevMod

Man / Auto Prot Emg

FanMultiSpd01 HclHw01 CclChw01

16 15 14 13 ... 8 7 6 5 4 3 2 1 FanSpd:MO HclVlvPos:AO CclVlvPos:AO

TXM1.6R TXM1.8U TXM1.8U

Figure 82: Application commands and priorities

The BACnet objects in the system support 16 priority levels. The HVAC control
applications apply these levels as follows:

Priority Purpose assigned to the level Use in HVAC library

Emergency mode 1 Manual commands related personal safety None

Emergency mode 2 Automatic commands related to personal safety Propagated response to Emergency
mode commands

Emergency mode 3 Unassigned - additional level for commands related to None

personal safety

Protection mode 4 Manual commands to avoid damage to equipment None

Protection mode 5 Automatic commands to avoid damage to equipment Programmed response to equipment
safety conditions

Minimum On/Off 6 Commands to avoid damage by short cycling equipment None

Manual operating 7 Manual commands through switches on equipment None

Manual operating 8 Manual commands through BAS workstation None

Automatic control 9 Unassigned - commands for comfort and energy conservation None

Automatic control 10 Unassigned - commands for comfort and energy conservation None

Automatic control 11 Unassigned - commands for comfort and energy conservation None

Automatic control 12 Unassigned - commands for comfort and energy conservation None

103 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Priority Purpose assigned to the level Use in HVAC library

Manual operating 13 Manual commands through room unit Programmed response to inputs from
occupants

Automatic control 14 Unassigned - commands for comfort and energy conservation None

Automatic control 15 Typical automatic commands for comfort and energy Typical automatic commands
conservation

Automatic control 16 Unassigned - commands for comfort and energy conservation None

Table 20: Priority levels

Adaptation to another An HVAC control application comprises several different members of an HVAC
HVAC plant room family. It contains application-specific components (CFC) matching existing
HVAC devices in the room. Components no longer matching existing HVAC
devices in the room are either added, removed, or replaced to control a slightly
different HVAC plant with different HVAC devices.
Room HVAC Plant Room

TEx

TR

TSu
FanMulti01 HclHw01 CclChw01

TOa
DmpOa01 Fan1Spd01 HclHw02 CclChw02

FanVarSpd01 HclEl01

Figure 83: Adaptation of an HVAC plant

Often, more must be done than merely adding or removing components (CFCs). If,
an HVAC device, for example, is to be added, the following must be added or
removed:
● Information in the operating mode table
● Corresponding BACnet objects to operate the new device

Shading control
Products and Suitable façade products and intelligent control allow for optimum satisfaction of
requirements various requirements for shading.
Façade products and their control required to protect against environmental
influences or to make use of the same are the primary issue:
● Shading to protect against glare
● Using daylight

104 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

● Using solar energy for heating

● Shading to protect against overheating
● Protection against rain
Other requirements may be:
● Intrusion protection
● Protection of privacy
Façade product control in addition must protect persons and equipment against the
façade products themselves. Examples:
● Drive up blinds in case of fire to open an escape route
● Protect against collision (for example, in the event of outward-opening doors)
Façade control protects the façade products and their functionality against
environmental damages caused, for example, by rain, wind, or frost.
The market knows many different façade products such as roller shutters, blinds,
awnings, etc. to satisfy the various requirements. The different properties of the
products are included in the respective control functions. The following figure
shows a few typical façade products (from left to right):
● Horizontal blinds
● Roller shutter
● Vertical blinds
● Drop-arm awning
● Vertical awning
● Sliding-arm awning

Figure 84: Typical facade products

Influences on blinds Blinds control requires much information on environmental influences and user
control interactions to be able to best satisfy requirements.
The blinds control can be influenced by, for example:
● Smoke, fire alarm
● Maintenance switch
● Wind, rain, humidity, temperature
● Intrusion alarm
● Date/Time
● Solar radiation
● Geographical position
● Horizon limitation

105 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

● Presence detector
● Local operator
● Saving and retrieving scenes
● Central operation (operation, scenes, override)
● Desigo CC
● Commissioning/Test
Blinds position on a building, room purpose, and allocation of rooms to an
organizational unit determine the type of information acting on blinds control.
Example:
● Wind speed monitoring acts on all blinds of a building or building wing
● Automatic shading acts on all blinds of façade or part of a facade
● A scheduler program acts on all rooms of a renter
● Local manual operation acts on all blinds of a room, or on a single blind

Figure 85: Grouping of blinds

Color key:
● Gray: Complete building
● Blue: Façade or part of a facade
● Green: Rooms of a renter, for example, one floor
● Orange, red: Local, manual operation
The functions are grouped into local and central functions depending on whether
the function acts on one or multiple blinds in a room, or on an entire group of blinds,
for example, on all blinds of a facade. The following table shows the grouping by
local and central functions for the examples from the figure above.

Local manual operation Automatic shading Wind speed monitoring Scheduler program
Central function n/a Determination of optimal Measuring of wind speed Commanding of a position
shading position in Monitoring of wind speed in dependence of daytime
dependence of sun
position Commanding of wind
protection position

Local function Commanding of manual Decision on which position Positioning of blinds Positioning of blinds
position is commanded
Positioning of blinds automatically
Positioning of blinds

Table 21: Grouping into local and central functions

Control concept The control concept is based on the following:

● Grouping into autonomous functions determining a set position for the blinds
● Priority assignment to individual functions
● Evaluation of all functions and decision in favor of specific blinds position based
on priorities

106 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

The following table provides an overview of autonomous functions to control blinds.

Priorities depend on plant requirements. The table shows the typical priorities in
ascending format.

Function Description
Automatic shading Automatic determination of optimum blinds position based on current room use, solar
radiation, outdoor brightness, solar position, and HVAC status. In simple terms, this
function prevents glare in occupied rooms and uses solar energy for heating in
unoccupied rooms, or protects the building against undesired heat-up.

Manual operation (room, central) Manual operation allows users to themselves determine the blinds position via buttons. If
manual operation overrides a lower-priority function, a scheduler program or local
presence information will reactivate the function.

Presence-based influence Locking of automatic operation upon entering a room, and activation of automatic
(room) operation upon leaving a room. The presence-based function generally acts on the same
priority as manual operation.

Scheduler program A scheduler program opens, closes blinds at specific times, or commands them to a
specific shading position. Furthermore, automatic operation can be activated or
deactivated via scheduler program. Another priority may need to be commanded
depending on purpose. If, for example, automatic operation should be activated at noon,
manual operation must be overridden by allowing the scheduler program to act on the
priority for manual operation. If the blinds are to be closed at night without allowing for
manual operation, a higher priority must be commanded.

Automatic shading at high priority For example, to prevent overheating it may be necessary to use automatic shading at
higher priority, which limits or prevents manual operation in certain situations.

Manual operation at high priority Manual operation at high priority allows for positioning blinds and overriding low-priority
(room, central) functions. For example, local operation can be overridden during, for example, a
presentation. Or it can be ensured that neither automatic shading nor a scheduler will
drive the blinds up or down at an undesired time.

Product protection, local Risks impacting a blind only, for example, protection against collision with a service door
opening outward, are included in local product protection.

Product protection, central Environmental influences impacting a group of blinds are included in the central functions
for product protection. A common function in this category is protection of blinds against
damage from strong winds.

Maintenance position, central For maintenance or cleaning, blinds are commanded or blocked to a specific position at
high priority enabling staff to carry out all required work without risking injury due to
moving blinds.

Protection, central Blinds can be moved/driven up to provide escape or access routes for emergency
personnel in the event of a fire.

Table 22: Autonomous functions

A very simple control contains just one or two functions; a complex plant may use
many or all available functions. In addition, the response of individual functions
may require parameterization depending on the requirements. The following figure
shows an example of a plant including all functions.

107 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

Central function Local function

Central safety (fire alarm)

Maintenance position
(blinds maintenance, window cleaning)
Product protection local (avoiding
collisions)
Product protection central
(wind, rain, frost)

Scheduler program, high priority

Manual operation at high priority

Selection of priority
(button)

Execute
Manual operation at high priority (btton,
resulting drive
management station)
command

Selection of right automatic

position for high priority

Scheduler program

Manual operation
(button, management station)

Manual operation (button)

Presence-induced activation/
deactivation of automatic mode

Determining shading position by solar Selection of right automatic

position position

Figure 86: Control concept shading

Lighting control
Products and Suitable lighting products and intelligent control allow for optimum satisfaction of
requirements various requirements.
Lighting products and their control are the primary means to create optimum
lighting conditions for building users:
● Optimum workspace conditions (bright or darkened rooms)
● Optimum lecturing/teaching conditions (presentation)
● Comfort in living spaces
● Mood lighting in entertainment spaces (restaurants, bars, etc.)
Other requirements may be:
● Energy savings
● Lighting of objects, products
● Façade lighting
● Intrusion protection
Lighting products control in addition must ensure the safety of persons. Examples:
● Switching on lights in case of fire
● Escape route lighting
A multitude of different lamps exists to satisfy the various needs, such as:
● Incandescent light bulbs
● Halogen lamps
● Fluorescent tube lamps
● Compact fluorescent tube lamps

108 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

● Metal halide lamps

● LEDs
For comprehensive information on lighting products and their application, see the
e-learning module Lighting basics (B_B01RA).
Influences on lighting Blinds control requires much information on external influences and user
control interactions to be able to best satisfy requirements. The following figure shows an
overview of the influences that may be considered as part of lighting control.

Figure 87: Lighting control influences

Lighting product positioning in a building, room purpose, and allocation of rooms to

an organizational unit determine the type of information acting on lamp control.
Example:
● A fire alarm acts on the entire building
● A scheduler program acts on all rooms of a renter
● Local manual operation acts on all lighting of a room, or on individual lamps
Gray: Complete building
Green/yellow: Rooms of a renter, for example, one floor
Orange: Local, manual operation

Figure 88: Lighting groups

109 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
4 Desigo Room Automation

The functions are grouped into local and central functions depending on whether
the function acts on one or multiple lamps in a room, or on an entire group of lamps,
for example, on all lamps of a renter. The following table shows grouping by local
and central functions for the examples from the figure above.

Local manual operation Fir alarm Scheduler program

Central function n/a Fire alarm reception Commanding of On/Off command in
Commanding of On-command dependence of time

Local function Commanding of manual brightness Switching on lighting Switch on/off lighting
Adapting lighting

Table 23: Local and central functions

Control concept The control concept is based on the following:

● Grouping into autonomous functions determining a command for lighting
● Priority assignment to individual functions
● Evaluation of all functions and decision on the state of lighting based on
priorities
The following table shows autonomous functions to control lighting. Priorities
depend on plant requirements. The table shows the typical priorities in ascending
format.

Function Description
Automatic control Automatic switch-on/switch-off based on brightness, constant lighting control.
In simply terms, this function achieves optimum lighting conditions automatically in
occupied rooms, and switches off lighting when rooms are unoccupied.

Manual operation (room, central) Manual operation allows users to themselves determine brightness via buttons. If manual
operation overrides a lower-priority function, a scheduler program or local presence
information will reactivate the function.

Presence-based influence (room) Automatic switch-on when dark upon entering a room, and automatic switch-off when
leaving a room. The presence-based function generally acts on the same priority as
manual operation.

Scheduler program Lighting can be switched on/off at specific times using a scheduler program. Furthermore,
automatic control can be activated or deactivated via scheduler program. Another priority
may need to be commanded depending on purpose. If, for example, automatic control
should be activated at noon, manual operation must be overridden by allowing the
scheduler program to act on the priority for manual operation. If lighting is to be switched
off at night without allowing for manual operation, a higher priority must be commanded.

Manual operation at high priority (room, Manual operation at high priority allows for influencing lighting blinds and overriding low-
central) priority functions. For example, this function allows for ensuring that neither motion
detectors nor scheduler programs can switch on/off lighting at the wrong time during a
lecture/presentation.

Maintenance, central For maintenance or cleaning, lighting is switched on/off at high priority enabling staff to
carry out all required work without risk of injury or being interrupted.

Protection, central Lighting can be switched on in the event of a fire alarm to light escape routes or support
emergency crew access.

Table 24: Autonomous functions

A very simple control contains just one or two functions, A complex plant may use
many or all available functions. In addition, the response of individual functions
may require parameterization depending on the requirements. The following figure
shows an example of a plant including all functions.

110 | 377
Siemens CM110664en_03
2017-09-18
 Control Concept
Desigo Room Automation
4

Central function Local function

Central safety (fire alarm)

Maintenance

Scheduler program at high priority

Manual operation at high priority

Selection of priority
(button)

Execution of
Manual operation at high priority (button, resulting lighting
management station) command

Scheduler program

Manual operation
(button, management station)

Manual operation (button)

Presence-induced influence

Automatic control

Figure 89: Control concept lighting

111 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
5 Standard Plant Structures

5 Technical View
The technical view illustrates the technical building services equipment, such as
HVAC systems and associated elements, in the building automation and control
system.
Area Gubelstrasse

Heat Heat distribution

generation Group N Group S

Air handling, 3rd floor

Burner

Sensor

KNG:ABdb6'AHU3Fl'FanSu

Figure 90: HVAC plants and their associated elements

The technical view helps organize measured and controlled physical variables from
specific, technical installations in a building. The technical view is modeled with
structure objects. The structure of the technical view represents the hierarchy of
the technical installations. Objects representing variables, such as setpoints or
operating modes supplement the view.
Plant types The technical view contains all the conceptual objects in the system. The following
plant types have been defined for descriptions and categories:
● Primary plant: All physical plants that are directly controlled from the
automation level, for example, heating systems, ventilation systems, etc.
● Room automation: Individual room controls.
● Global objects: Data objects which exist simultaneously in several automation
stations at the automation level, for example, an exception calendar for the
time schedules of all plants. These objects are combined as a virtual plant in a
global area and can be invoked as such (global data).
The technical view can be used for other disciplines integrated via PX Open. The
technical view and the associated technical designations can be set up in the
compounds library.

5.1 Standard Plant Structures

To display different plants in a uniform manner, a standard hierarchical plant
structure has been created for each plant type.

112 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
Standard Plant Structures
5

Primary plants with Desigo PX

Structure
Site

Plant

Partial plant,
Aggregate,
Component

Total max. 6
recursions (max. 7
levels)
Figure 91: Structure for primary plants

Elements Site: A site is a self-contained area in terms of location, function and organization,
usually a building or a group of buildings (facility). A site can comprise several
plants. Example: Building 6
Plant: A plant consists of partial plants, aggregates and components. A plant can
comprise several partial plants. Aggregates and components can be directly
subordinate to a plant. Example: Ventilation system, heating system
Partial plant: A partial plant can comprise various aggregates. Components can be
directly subordinate to a partial plant. Example: Central supply air treatment, air
distribution, hot water supply (one or more boilers)
Aggregate: An aggregate can comprise various components. Example: Exhaust air
fan
Component: A component can comprise several components, which can comprise
several components themselves. Example: Pumps (motors), dampers, valves,
sensors, detectors, limit switches, contactors, selector switches, remote/local
switches
Engineering model BACnet/System model
Site Site
1

n n
Element type:
Hierarchy element Hierarchy object Element type:
auxil. element
plant
plant (primary) Element type area
area CFC Editor: Compound
subarea
subarea
section
section Element type
1 1 Structured view object
Total max. 6 Element type
Assignable to PX recursions
(nesting)
n n
Element type:
Function element Block object Element type:
auxil. element
partial plant
partial plant Element type
CFC Editor: Compound aggregate
aggregate
Function block component
component
Function room
room
Element type Standard BACnet object
1 Element type

Element type: auxiliary element, plant, partial plant, aggregate, component, area, subarea, section, room

Figure 92: Primary plant with Desigo PX

113 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
5 Standard Plant Structures

Example: Ventilation VB Site: Site [Site]

Zug Area: A [Ventilation system]
Plant: Ahu03 [Ventilation VB Zug]
Aggregate: FanEh [Exhaust air fan]
Component: DPMon [Differential pressure]

Figure 93: Technical view of the Ventilation plant VB Zug

Global objects
Structure
Site

Global area

Component

Figure 94: Structure for global objects

Elements Site: A site is a self-contained area in terms of location, function and organization,
usually a building or a group of buildings (facility). Example: Building 6
Global area: The global area contains all the global components of the site. There
is one global area per site.
Global objects are data objects which exist simultaneously in several automation
stations at the automation level, for example, an exception calendar for the time
schedules of all plants. These objects are combined as a virtual system in a global
area and can be invoked as such.
Component: A global area may contain several components, such as 3 calendars,
18 notification classes for alarm distribution. Each component is present on all
automation stations of the site. For operation, however, each component is visible
only once.

114 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
Standard Plant Structures
5

Room automation with Desigo RX

Structure
Site

Area, Subarea,
Section

Room

Figure 95: Structure for room automation with Desigo RX

Elements Site: A site is a self-contained area in terms of location, function and organization,
usually a building or a group of buildings (facility). A site can comprise several
plants. Example: Building 6
Area: An area is typically a building, and can comprise subareas, sections,
components and subcomponents. Example: Building
Subarea: A subarea is typically the wing of a building and can comprise several
sections. Rooms can be directly subordinate to a subarea. Example: Building wing,
staircase
Section: A section is typically a floor in a building and can contain various rooms.
Example: Floor
Software objects, which need to be displayed and operated even though they do
not exist as physical elements in a real building, are also treated both as sections
(for example, via grouping criteria, such as east facade or emergency group 12)
and as components (for example, group object for distribution of centrally
determined control variables to several rooms).
Room: A room is a section of a building that is delimited by walls, ceilings, floors,
windows and doors. Example: Individual room, hall

115 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
5 Standard Plant Structures

Room automation with Desigo Room Automation

Structure

Building

Floor

Room

Room segment

Functional unit

Component

Figure 96: Structure for room automation with Desigo Room Automation

Elements Building: A building is a locally, functionally and organizationally defined area.

Example: Building 6
Floor: A floor in a building can contain various rooms. Example: Floor
Room: A room is a section of a building that is delimited by walls, ceilings, floors,
windows and doors. Example: Individual room, hall
Room segment: A room segment is a subdivision of a room. A room can contain
several room segments.
Functional unit: A functional unit is a logical component representing an
encapsulated application unit which may be independently deployed to an arbitrary
automation device. Example: Fan coil
Component: A functional unit can contain several components. Example: Awning
Example: Technical view Building: BU33 [Building 33]
of the Shd01 component Floor: Fl3 [Floor 3]
Room: R01Segm01 [Room]
Components: Shd01 [Shading 01, venetian blinds or awnings]

116 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
Technical Text Labels
5

Figure 97: Technical view of the Shd01 component

5.2 Technical Text Labels

The Technical Designation (TD) is a technical identifier that is used to identify the
plant and associated elements.
The structure of the TD is based on the hierarchical structure of the plant and its
associated elements, z.B.:
● For primary plants with Desigo PX:
Site / Plant / Partial plant / Aggregate / Component / Pin
● For room automation plants with Desigo RX:
Site / Area / Subarea / Section / Room
● For room automation plants with Desigo Room Automation:
Building / Floor / Room / Room Segment / Functional Unit / Component / Pin
The text is based on designations in abbreviated form that are customary within the
industry, for example:
GUB:AGeb6‘Ahu3St‘FanSu = Gubelstreet facility / ventilation plans building 6 / Air
handling third floor / supply air fan
Technical designations are linguistically neutral (mnemonic). They are based on
mnemonic texts set up in the library, with additional project-specific details.
The TD is defined by Siemens. The User Designation (UD) can be defined by the
customer.
Name&Description_Pair Each element of the TD is called ShortName. A ShortName is a designation for an
individual plant element within the automation station. A ShortName is always
linked to a description. This pair is called the Name&Description_Pair.
TD rules The following table shows the rules for the TD:

117 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
5 Technical Text Labels

Item Rule
Address structure Comprises at least one hierarchical object and one function object
Has a variable length (site + 1..8 hierarchy and function objects + pin name)
Is independent of the automation station, that is, does not contain a designation for an
automation station
Must be unique for each site

Mnemonic Based on the English terms

Must not be translated
Plant elements on the same hierarchy level are distinguished through different part
names, for example, HG01/HG02.

Syntax Site designation Consists of upper and lower case letters, and numbers (must start with a letter): [a..z,
A..Z, 0..9].
Is case insensitive, for example, Imax and IMAx are treated the same.

Other partial designations Consist of upper and lower case letters ([A..Z] and [a..z]) and/or numbers 0 to 9.
Is case insensitive, for example, Imax and IMAx are treated the same.

Max. number of characters Site: 10

Object: 9
Pin: 8
TD: 80

Separators Colon (:) after site name

Apostrophes (‘) for all other separations
Period (.) in front of pin name

Table 25: TD rules

Function blocks and pins

A function block, that is, an object with pins, can represent an area, a partial plant,
a sub-area, an aggregate, a section, or a component. Function blocks have
attributes and function block pins have attributes.
The following figure shows a function block and its pins as they appear in the
program view:

Figure 98: Function block in the program view

Function block attributes The main attributes of the function block are:
● Name: Name of the function block based on the key of the TD. Example:
ThOvrld
● Description: Additional description. For generic operation it is shown as text in
an operator unit. Example: Thermoelectrical ovrld
● Element type: Block in plant-engineering terms. Example: Component
● Main value: Main value of the function block. It is set during engineering.
Example: PrVal

118 | 377
Siemens CM110664en_03
2017-09-18
 Technical View
Technical Text Labels
5

Figure 99: Attributes of the function block Thermoelectrical ovrld

Function block pin The main attributes of the pins are:

attributes ● Name: Pin name, based on the key of the TD. Example: PrVal
● Description: Description of the pin name. Example: Present value
● Value: Current value of PrVal. Example: Normal
● Parameter Kind: Application pin type. Example: Process input
● Data Type: Data type of the pin. Example: Multistate
For a complete list of attributes, see CFC Online Help.

Figure 100: Pins of the function block ThOvrld

119 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
6 Ensuring Data Consistency

6 Global Objects and Functions

Every automation station contains all the data necessary for stand-alone operation,
including, for example, date and time, calendar function blocks and Notification
Class function blocks. The system functions of individual automation stations do
not depend on a central server.
The System View and the Program View are based on the automation station, that
is, each object (block, BACnet data object) belongs to a specific automation station.
These objects are called local objects. This form of representation is adequate for
most elements of a physical plant, for example, for the supply air temperature or
the set point of a ventilation system.
However, certain data objects need to be visible in identical form in some or all the
automation stations of a site. These objects are called global objects. Global
objects let you centrally change parameters, which are then distributed to all
automation stations.
Local objects Local objects are individual and unique objects which exist only once on a
particular automation station in the system. Most application-related objects are
local objects. When local objects are required, such as the outside temperature in
several automation stations, access to this data must be configured or
programmed explicitly with function blocks (such as analog, binary and multistate
inputs, or grouping in the room management system) and referencing.
Global objects Global objects are data objects which exist simultaneously on each automation
station at the automation level. Global objects are always global within a given site.
Global objects are engineered in Xworks Plus (XWP).
Global objects are compiled in a global chart. There is exactly one global chart per
site. You can modify global charts, save them in the tool's library folder, and copy
them to other projects.
Global objects and functions are not supported in Desigo S7.

6.1 Ensuring Data Consistency

Primary copy The primary copy procedure ensures that the global objects are consistent at all
times. This means that all copies of a particular global object contain the same
value and any modification of a value is transmitted to all copies.
Primary and backup Only one automation station per site acts as the primary server for all global
server objects of this site. All other automation stations of this site are backup servers. A
client may only modify the values of the global objects on the primary server. The
primary server then updates the copies of the modified global objects on all backup
servers. A backup server accepts the modifications to global objects only from its
primary server but not from a client.

120 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
Roles in the System
6

Figure 101: Primary copy procedure

Xworks Plus (XWP) and all BACnet clients can only modify the data of global
objects in the primary server.

6.2 Roles in the System

Server/Function Function and description
Primary server (Desigo PX) One automation station of a site acts as the primary server. Make sure that only one primary server
exists at any one time on a site.

Life check The primary server monitors the backup servers and the third-party BACnet devices of a site.
The primary server can monitor the Desigo Room Automation server.

Time synchronization The primary server synchronizes the time of the backup servers and the third-party BACnet devices of
the site.
The primary server can synchronize the Desigo Room Automation server time.

Start-up No coordinated start-up.

Replication The primary server replicates the global objects and properties (device object) to the backup servers
of a site. A backup server accepts changes of global objects only from the primary server.

Table 26: The role of the primary server

Server/Function Function and description

Backup server (Desigo PX) The other automation stations of a site must be backup servers.

Life check The backup servers monitor the primary server of the site.
Backup servers can monitor Desigo Room Automation servers.

Time synchronization The backup server can synchronize the time of the Desigo Room Automation server and of the third-
party BACnet devices.

Start-up No coordinated start-up.

Table 27: The role of the backup server

121 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
6 Life Check

Server/Function Function and description

Desigo Room Automation server / The Desigo Room Automation server acts like a standard BACnet device.
Third-party BACnet device

Life check The Desigo Room Automation server / third-party BACnet device is monitored by the primary server or
the backup server.

Start-up No coordinated start-up.

Replication No global objects to be replicated.

Table 28: The role of the Desigo Room Automation server and third-party BACnet device

Server/Function Function and description

Clients A client can read global objects from the primary server or any backup server. A client may only
modify a global object (for example, with WriteProperty) on the primary server. Each client must
therefore recognize the primary server of a site. A client can query the identification of the primary
server of a site.
Replicated objects from backup servers which are not online or which are connected to the BACnet
network at a later stage, are updated by the primary server as soon as the primary server becomes
aware of them. This occurs after a restart of the automation station, after connecting it to the network
or on expiry of the synchronization request period [SynReqp].

Table 29: The role of the clients

Server/Function Function and description

Alternative primary server If the primary server fails, no global objects can be modified. You can configure any backup server of
the site to act as the primary server using a client or Xworks Plus (XWP).

Table 30: The role of the alternative primary server

6.3 Life Check

The life check checks if all devices of the site (primary server, backup server,
Desigo Room Automation server or third-party BACnet device) work correctly, that
is, if they are operating and if they are running their application.
● The primary server monitors if the backup servers / Desigo Room Automation
servers are active.
● The backup servers monitor if the primary server is active.
● The primary server checks that only one primary server exists at any one time
on a given site.

122 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
Time Synchronization
6

Figure 102: Life check

Add and delete devices For life check and replication the primary server has a list [BckUpSrv] of all known
devices of a site. The primary server automatically adds newly commissioned
devices on the site to this list. Devices which are removed from the site must be
deleted manually in Xworks Plus (XWP) from the list in the primary server.
Check if all devices are The primary server performs a life check at regular intervals, to check that all
online devices of its site are online. The interval between life checks is defined by the
synchronization request period [SynReqp]. During this period, the backup servers
are checked one after the other in a cyclical process. The interval between two life
checks can be calculated as follows: t ≈ SynReqp / Number of backup servers .
A short synchronization request period and a large number of backup servers may
involve a substantial communications load. Take this into account when setting the
synchronization request period in Xworks Plus (XWP).
If one or more devices are not online, the primary server generates an alarm signal.
The alarm is reset as soon as all devices are online again and have been detected
by the primary server. This ensures that problems, such as the failure of a device,
the termination of the HVAC-application processing of a device, or faulty
configuration (for example, two primary servers in one site) are detected.
Monitor if the life check Each backup server monitors its own periodic life check by the primary server. If a
checks the backup server life check fails, or if no primary server has ever carried out any life checks on this
backup server, the backup server generates an alarm. The backup server resets
the alarm as soon as the primary server carries out a life check.

6.4 Time Synchronization

Each automation station is assigned to a site.
The primary server is the time master. It represents the system time within a given
site. The primary server synchronizes the time in the other automation stations at
regular intervals.
If the primary server receives a time synchronization request which triggers a time
change, the primary server synchronizes the time in the other automation stations.

123 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
6 Examples of Global Objects

The primary server transmits the time in UTC format (Coordinated Universal Time)
to the other automation stations (backup servers) and in UTC format or local time
format to the third-party BACnet devices.
The backup server then triggers time synchronization of its recipients configured in
Xworks Plus (Desigo Room Automation server, third-party server, third-party
BACnet devices). This can be in either UTC or local time format.
Periodic synchronization The time synchronization interval is defined in the property
TimeSynchronizationInterval [TiSynIvl] (default value: 150 minutes). The property
can be configured in Xworks Plus (XWP) and adapted to the specific situation via a
switchable [AlgnIvl] offset [IvlOfs]. How these three properties function is defined in
the BACnet standard and implemented accordingly.
Add and delete devices For time synchronization, the primary server has a list [TiSynRcp] containing the
recipients configured in Xworks Plus (XWP) and all known backup servers of its
site.
The primary server automatically adds newly commissioned backup servers on the
site to the list [TiSynRcp].
Backup servers which are removed from the site must be removed manually from
the primary server list in Xworks Plus (XWP).
Link the system time of a The network-capable operator units do not belong to a site. The primary server
site with operator units does not update the time in the operator units. The client can read and update the
time, if required.
Daylight saving time The daylight saving time changeover does NOT take place in the primary server.
changeover Each automation station makes this switch independently.
The date of the daylight saving changeover is set as a parameter in the primary
server. The primary server replicates the date on the backup server. The official
(Central European) changeover date is set as default.
The local time in an automation station is a calculated variable. The calculation is
based on the internal time in UTC format, the property UTC offset [UtcOfs] and the
date of the summer and winter time changeover.
See Desigo CC User Guide (A6V10415471).

6.5 Examples of Global Objects

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]

124 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
Examples of Global Objects
6

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.
Desigo CC PXM20

NotificationClass NotificationClass NotificationClass NotificationClass

Class# 12 Class# 13 Class# 22 Class# 31
Priority: 1,1,5 Priority: 1,1,5 Priority: 2,2,6 Priority: 3,3,7
AlarmClass: UrgentAlarm AlarmClass: UrgentAlarm AlarmClass: HighPrioAlarm AlarmClass: NormalAlarm
Alarmfunction: Basic Alarmfunction: Extended Alarmfunction: Basic Alarmfunction: Simple
Recipient list Recipient list Recipient list Recipient list

Source: Source: Source:

AlarmClass: HighPrioAlarm
DeviceInfoObject AlarmClass: UrgentAlarm AlarmFunction: Basic
AlarmClass: UrgentAlarm AlarmFunction: Extended
AlarmFunction: Basic

Locked Locked
Reset Reset Reset

DESIGO PX

Figure 103: Distribution of alarms and 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.

125 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
6 Examples of Global Objects

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).
Desigo CC PXM20

10664Z05en_07

Figure 104: Global and local Notification Class Objects

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.

126 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
Examples of Global Objects
6

Desigo CC

10664Z06en_07

Figure 105: 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 master 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, and to ensure continuity of operation in the event
of the failure of the master.

127 | 377
Siemens CM110664en_03
2017-09-18
 Global Objects and Functions
6 Examples of Global Objects

Desigo CC

10664Z07en_07

Figure 106: User profile objects

128 | 377
Siemens CM110664en_03
2017-09-18
 Events and COV Reporting
Sources and Causes of System Events
7

7 Events and COV Reporting

Events System events are messages which inform a client (for example, Desigo CC) of
specific events in an automation station, such as:
● Change in operating state of the automation station (STOP, RUN)
● Overflow of the operating hours counter built into certain I/O objects
Conceptually, system events are similar to alarms, however, they differ from alarms
in some ways:
● System events have no memory, that is, they do not have a finite state
machine.
● System events do not affect the status of a plant, that is, they can occur in any
alarm state without influencing it.
● System events are displayed, but do not need to be acknowledged or reset.
System events are forwarded to clients using the same mechanism as alarms.
COV reporting If a value of a specific process variable changes, the change is transmitted to other
system components by means of Change Of Value (COV) reporting. Polling is
used only in exceptional cases. COV reporting can be used to transfer value
changes to several automation stations. A COV notification is issued only when the
value of the process variable changes in comparison with the preset or default
incremental value. There is no need to poll the process variables at regular
intervals.
There are two roles:
● COV-Server: The automation station which reads the process variable and
whose change of value is to be reported.
● COV-Client: The recipient of the COV notifications. This may be another
automation station or a BACnet client.

7.1 Sources and Causes of System Events

The source of a system event is a function block (as with alarms). System events
can originate from the same block types as alarms:
● Analog Input/Output/Value
● Binary Input/Output/Value
● Multistate Input/Output/Value
● BACnet Device Info Object (not in Desigo Room Automation)
Every block type capable of generating a system event has a clearly defined set of
system event triggers.

Event-generating block types Description

Operating hours counter The input, output and value objects of the Binary and Multistate types have an inbuilt operating hours
counter. A system event is generated when the operating hours limit is exceeded or when the
maintenance interval has expired.

BACnet Device Info Object The BACnet Device Info Object detects the causes of system events which apply to the automation
station as a whole. The following causes are detected:
- Change of operating state (start and stop the program)
- Restart after a power-up
- Primary server has found a new backup server on the network
- Backup server has found the primary server

Table 31: Event-generating block types

129 | 377
Siemens CM110664en_03
2017-09-18
 Events and COV Reporting
7 Routing System Events

7.2 Routing System Events

System events are forwarded to clients using the same mechanism as alarms.
They are forwarded to all temporary and configured alarm recipients in accordance
with the settings in the associated Notification Class objects.
Comparison with the System events cannot be acknowledged or reset. A Confirmed Event Notification
alarm strategy message is sent to all alarm recipients. The Notify_Type data field in the message
defines that the event is a system event and not an alarm. Each alarm recipient
that receives the Confirmed Event Notification is required to respond with a
SimpleAck. If the SimpleAck is not received, the same mechanism comes into
operation as for alarms.

SimpleAck
SimpleAck

t t t

Figure 107: System event forwarding procedure

Event texts Each system event has a message text assigned to it. For the system events
related to the operating hours counter, a user-specific text can be set up in Xworks
Plus (XWP). Predefined system texts are available for the other system events.

7.3 Sources and Causes of COVs

Process variables which can be mapped to standard BACnet objects are COV-
capable.
I/O function block Function blocks for Analog, Binary and Multistate Inputs, Outputs and Values are
mapped directly to the associated BACnet object types. They are COV-capable
and can establish COV connections with all COV clients.
Interface variables Interface variables of compounds and function blocks whose data type is Analog,
Binary, Multistate, Integer, Duration and DateTime are COV-capable and can be
mapped to simplified BACnet value objects for operation and monitoring.
A COV is initiated when the value of the process variable [PrVal] of the BACnet
object which represents it changes. A COV is also initiated when a status flag
[StaFlg] (InAlarm, Fault, Overridden or Out of service) changes, for example, when
a sensor open circuit (fault) occurs or when an I/O value is overwritten manually.
COV increment For analog objects, a COV is not initiated for every minor change of [PrVal], but
only when the value changes by an amount greater than a predefined increment.
This increment is saved in the COV increment [COV] of the analog object, and can
be defined in Xworks Plus (XWP) during engineering.

7.4 COV Reporting

Subscription Each COV client must subscribe to every process variable from which it requires
COV notifications. Each COV-capable object transmits COV notifications only to
those COV clients which have subscribed to COV notifications. The subscription
process is carried out using the BACnet service SubscribeCOV, transmitted by the
COV client to the COV server. This message contains all the information that the
COV server needs to send the COV notifications to the correct destination. It also
includes a time period which determines the validity period of the subscription. The
time period may be infinite.
For system limits, see chapter System Configuration.

130 | 377
Siemens CM110664en_03
2017-09-18
 Events and COV Reporting
COV Reporting
7

COV notifications The COV server reports every COV individually to each COV client which has
subscribed to it. The BACnet service ConfirmedCOVNotification is used for this
purpose. It contains the values of [PrVal] and [StaFlg]. The service is a Confirmed
Service, which means that the COV client must acknowledge the notification
(SimpleAck). This ensures that when a COV client ceases to be available, this will
be recognized by the COV server. If no SimpleAck message is received, the
transmitting device tries to send the information again (three times).
For system limits, see chapter System Configuration.
Connection terminated If a COV client cannot be contacted, the COV server ceases to send COV
notifications to that client. The transmission of COV notifications to a COV client is
resumed when the COV client re-subscribes.
Checking the connection To ensure that the COV service is maintained over a long period, a maximum time
period without COV reporting can be set in the BACnet Device Info Object via the
BACnet property COV Resubscription Interval [CovRI]. The client must subscribe
with SubscribeCOV again before [CovRI] expires.
COV clients and COV Desigo CC
servers COV
Client

Automation level
COV
Client PXM20

Block A Block Z

COV
Client
COV
Server

Block V

COV

10664Z46en_07
Server Block B Block Q

Figure 108: COV clients and COV servers

The local PXM10 operator unit is not a BACnet client and cannot, therefore, be
used as a COV client.
See PXM10 operator unit: User's guide (CM110397).

COV reporting between COV client and COV server

COV mechanism BACnet clients use the COV mechanism for continuous monitoring of process
variables without putting an excessive load on the bus through continuous polling.
They subscribe to the objects that they are monitoring. These COV connections
must be maintained as long as the object is being monitored.

131 | 377
Siemens CM110664en_03
2017-09-18
 Events and COV Reporting
7 COV Reporting

SimpleAck
ation
COVNotific
Co irmed
nf
SimpleAck

cation
COVNotifi
Confirmed
SimpleAck

t t

Figure 109: COV reporting between COV client and COV server

The BACnet client subscribes to the COV server as a COV client using the BACnet
service SubscribeCOV. The server sends a SimpleAck acknowledgement.
Immediately after the acknowledgement, the COV server transmits an initial
ConfirmedCOVNotification. The COV client acknowledges receipt of the value with
a SimpleAck acknowledgement. The COV connection between the COV server
and COV client is now established, and ConfirmedCOVNotifications are sent
whenever a trigger for the subscribed COV occurs.
The BACnet service SubscribeCOV includes a time limit for the COV connection.
However, the COV client re-registers with the COV server before this limit expires,
thus ensuring that the connection is maintained. A COV connection ends when the
subscription period expires and is not renewed, or when the COV client can no
longer be contacted, causing the COV server to stop sending notifications.
In addition to the SubscribeCOV service, a SubscribeCOV Property service is
implemented, for example, for the operation of plant graphics in Desigo CC. This
enables the system to respond with appropriate speed to changes in the high or
low limit.

COV reporting between automation stations

COV connections between automation stations are used to implement pre-
engineered references, that is, for the exchange of process values between
individual plant parts on different automation stations. In this case the receiver is
an input function block of the relevant data type (Analog, Binary, Multistate). The
input function block contains the technical designation of the required COV source
in its input/output address parameter [IOAddr]. These COV connections must be
permanently live. The COV mechanism enables a dropped COV connection to be
re-established.

SimpleAck
ation
COVNotific
Confirmed
SimpleAck

ation
COVNotific
Confirmed
SimpleAck

t t

Figure 110: COV reporting between automation stations

132 | 377
Siemens CM110664en_03
2017-09-18
 Events and COV Reporting
COV Reporting
7

When an automation station connects, the BACnet service WhoHas searches the
entire network for the object referred to in the COV client. The automation station
concerned responds to the COV client with the BACnet service IHave. If the COV
client cannot find the COV server, it repeats the WhoHas request after the time
period defined in the BACnet Device Info Object Property Name resolution interval
[NamRI] until the COV server is found.
The COV client registers for a limited period as a COV client with the COV server
using the BACnet service SubscribeCOV. The server sends a SimpleAck
acknowledgement. The value is then sent to the COV client for the first time by the
COV server, using the BACnet service ConfirmedCOVNotification. The COV client
acknowledges receipt of the value with a SimpleAck acknowledgement. The COV
connection between the COV server and the COV client is established from this
point on. According to the global property COV renewal interval CovRI of the
BACnet Device Info Object, the COVsubscription is renewed. The lifetime used for
SubcribeCOV is twice the COV renewal interval CovRI. The COV connection ends
when the subscription period expires and is not renewed, or when the COV client
can no longer be contacted, causing the COV server to stop sending notifications.

133 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Sources

8 Alarm Management
Alarms indicate faults in the HVAC plant and building automation and control
system, and let you initiate corrective action, where appropriate. The management
of alarms (generation, signaling, acknowledgement) is in compliance with the
BACnet standard.
There are two alarm types:
● OFFNORMAL
● FAULT
OFFNORMAL OFFNORMAL alarms (process alarms) occur when a process variable assumes an
inadmissible value. What is inadmissible is determined during engineering. The
relevant parameters are stored in all alarm-generating objects. An OFFNORMAL
alarm always indicates a fault in a plant, while the automation system itself works
properly.
Examples of OFFNORMAL alarms:
● Temperature in HTHW circuit is too high or too low
● Alarm generated by fire detection system
● A damper-motor feedback signal has not been received
● A time schedule cannot execute a command
FAULT FAULT alarms are faults in the automation system itself (internal alarms). You
cannot define the cause of a FAULT alarm during engineering. Nor is it possible for
the user to suppress or otherwise influence the monitoring of FAULT alarms.
FAULT alarms are intrinsically linked to the system. A FAULT alarm always takes
precedence over an OFFNORMAL alarm from the same alarm source, because in
the case of a FAULT alarm, there is some uncertainty about the reliability of the
alarm source.
Examples of FAULT alarms:
● Faulty sensor (open circuit, short circuit, etc.)
● Buffer for storage of non-volatile data full
● Access to an I/O module failed
● Bus open circuit (RX integration)

Alarm detection procedure

Every alarm (OFFNORMAL or FAULT) can be uniquely allocated to a source. The
alarm monitoring system is based on the principle of Intrinsic Reporting or
Algorithmic Reporting as defined in the BACnet standard.
Intrinsic reporting Intrinsic reporting means that alarm monitoring (target-actual comparison) takes
place within the alarm-generating object itself (the alarm source). For this purpose,
the function block contains the entire alarm state machine. Alarm detection does
not require any function blocks with external functions. The alarm behavior of the
object is defined by setting variables in the alarm-generating object (function block).
Algorithmic reporting Algorithmic Reporting means that alarm suppression (target-actual comparison)
occurs outside the alarm source. The alarm state machine is not located in the
function block of the alarm source. For alarm detection, function blocks with
external functions are required. The object's alarm response is not parameterized
using variables of the monitored object (function block).

8.1 Alarm Sources

The following function blocks can be alarm sources:
● Analog Input / Analog Output / Analog Value
● Binary Input / Binary Output / Binary Value / Pulse Converter

134 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Sources
8

● Multistate Input / Multistate Output / Multistate Value

● Event Enrollment
● Command Control object2
● Power Control object2
● Schedulers (Analog / Binary / Multistate Scheduler object) 2
● AlarmCollection object
● Discipline I/O1, 2
● Trend Log / Trend Log Multiple
● Group1, 2
● Device Info object, which models the properties of an automation station as a
complete entity
● Loop object
Key:

1 Discipline I/Os, Groups, Time Scheduler and Trend Log Multiple support only system alarms, that
is, only alarms of the FAULT type. Both function blocks can transmit more than one system
alarm. The parameters [Rlb] and [MsgTxt] provide detailed information about the cause of the
most recent alarm message. The messages are transmitted in the order in which they occur,
irrespective of the importance of the alarm.

2 These function blocks only exist in Desigo PX.

Only these alarm sources incorporate Intrinsic Reporting, and can thus generate
their own alarms. If any other value of a function block needs to be monitored for
an alarm (for example, the control signal for a controller block), an Event
Enrollment object must be added.
Alarm-generating function blocks include a range of interface variables which can
be set as parameters to determine the alarm response (Input Property) or to supply
the relevant alarm state information (Output Property). These interface variables
are described further below. Some of the interface variables are common to all
alarm-generating block types, while others are specific to certain types of alarm-
generating blocks.

Alarm state machine in an alarm-generating function block

Alarm state machine The response in the event of an alarm is modeled by an alarm state machine. Each
alarm-generating block incorporates an alarm state machine of this type. The
alarm-related interface variables can therefore be used to define the response of
this state machine, to simulate state transitions, or to represent the current status
of the state machine itself.

Figure 111: Alarm response with an analog function block

135 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Example

Alarm state event states The alarm state machine can assume one of three basic states (event states
[EvtSta]):
● NORMAL: There is no alarm condition present
● OFFNORMAL: Alarm caused by an OFFNORMAL condition
● FAULT: Alarm caused by a FAULT condition
With analog blocks, the OFFNORMAL state is explicitly subdivided into the sub-
states HIGH LIMIT and LOW LIMIT, which are described in detail further below.
The current state of the alarm state machine in an alarm-generating block is
displayed externally in the form of the output variable [EvtSta] (event state) of the
block concerned.
State transitions The following table shows the state transitions between the alarm states:

Transition Trigger Action / Event state

TO_OFFNORMAL A new OFFNORMAL alarm condition has been detected. OFFNORMAL

TO_NORMAL1 The current OFFNORMAL alarm condition has disappeared, and there is NORMAL
no other alarm condition present.

TO_FAULT A new FAULT alarm condition has been detected. FAULT

TO_NORMAL2 The current FAULT alarm condition has disappeared, and there is NORMAL
currently no other alarm condition.

Table 32: Transitions between the alarm states

System events may also occur within each alarm state. These message functions
do not affect the alarm state.
Because FAULT alarms take priority over OFFNORMAL alarms, the state transition
from FAULT to OFFNORMAL only occurs under very special circumstances.
If, while in the OFFNORMAL state, a FAULT alarm condition occurs, there is then a
state transition TO_FAULT (because as stated above, FAULT takes priority over
OFFNORMAL).

8.2 Alarm Example

What happens in the The following figure shows the main information exchanged by the elements
Desigo system when the concerned, namely:
V-belt of an extractor fan ● Operator
breaks?
● Ventilation system sensor/actuator (differential pressure monitor, maintenance
switch and single-speed extract air fan)
● PXC program
● Desigo CC plant graphic
● PXM… operator unit

136 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Example
8

PXC - Programm Ventilator

Zustandsmaschine 1
RefVal 3 4
∆? PrVal disturbed Belt

PrVal
2
3 7 disturbance
appears
OR 6

BL Exhaust Air FAN 1 St.

MntnSwi Notification Class ( =23)
PrVal Cmd_CNTL 1 .. ..... High Pro Alarm
ON ........ Extendet Alarm
OFF ........ Receiver = DI Name
Auto 5

Pop Up Desigo CC
Txt:........................

3 ACK

RESE 5
Auto
ON Pop Up
OFF
Txt:........................
9 ACK

RESE

Figure 112: Information flow

Key:

A State machine

B CFC program

C Desigo CC plant graphic page

D Desigo CC popup

E PXM… Values (in a PXM10 alarm handling is only possible for connected PXCs or PXRs)

F PXM… Popup (in a PXM10 alarm handling is only possible for connected PXCs or PXRs)

137 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Example

Figure 113: Time sequence in the example

1. Ventilation system on (for example, in automatic mode, Cmd.ValPgm = 1),

single-speed extract air fan running, fan blades rotating
2. The V-belt breaks, the pressure drops, the differential pressure monitor
responds (delta p < X) and DPMon.PrVal goes to zero. This activates the alarm
monitoring function in the DP monitoring block, and the [TiMonDvn] timer starts
counting down.
3. After expiry of the time [TiMonDvn], the DPMon block (BI) establishes that
DPMon.PrVal (0) is still equal to DPMon.RefVal (0). This is equivalent to the
OFFNORMAL state. DPMon.Dstb then goes to 1, and a TO_OFFNORMAL
event is transmitted.
An alarm pop-up window is then displayed, in which the alarm message reads
Alarm, Unacked.
4. The motor of the single-speed extract air fan is disabled (that is, Cmd.PrVal → 0)
because [EnSfty → 1 and Cmd.ValSfty=0, Prio1 Cmd Input]. As a result,
DPMon.RefVal goes to 1, thereby activating the alarm monitoring function.
After expiry of the time [TiMonDvn], the alarm monitoring function determines
that [DPMon.PrVal (0) <> DPMon.RefVal (0)]. The state therefore changes to
NORMAL and a TO_NORMAL event is transmitted.
The alarm display now changes to Alarm = Normal, UnAcked.
5. The operator now acknowledges the alarm with Ack in the alarm pop-up dialog
box. The alarm display now changes to Alarm = Normal, Acked. The operator
sets the maintenance switch [MntnSwi] to Maintenance ON, replaces the fan
belt, returns the maintenance switch to Maintenance OFF and resets the alarm
with Reset.
The alarm in the display changes to Alarm = Normal, Unlocked and
DPMon.Dstb → 0.

138 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Effects of BACnet Properties on Alarm Response
8

6. The fault has been cleared. When DPMon.Dstb = 0, then Cmd.EnSfty → 0 and
hence Cmd.PrVal → Cmd.ValPgm=1, that is, the fan motor is enabled. Then,
with Cmd.TraSta = 1 (transient state), the fan ramp-up time is allowed to expire,
that is, DPMon.RefVal is held at 1 during the transient state. Only after expiry
of the ramp up time does DPMon.RefVal revert to 0.
7. The ventilation system is already running (from step 6 on), that is, the fan
blades start rotating, the pressure builds up and the differential pressure
monitor detects delta p = X again, that is, DPMon.PrVal → 1. The alarm
monitoring function is active again. After expiry of the time [TiMonDvn], this
determines that there is no alarm condition present, because [DPMon.PrVal(0)
<> DPMon.RefVal (1)]. The system then operates 100% correctly as described
under step 1 above.

Figure 114: CFC chart for single speed fan Fan1St

To simplify the time chart shown above, the connection to DPMon.EnAlm has not
been included.

Figure 115: State machine

8.3 Effects of BACnet Properties on Alarm Response

The following table shows which BACnet properties are present in which function
blocks.
I = Input
O = Output
V = Value

139 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Effects of BACnet Properties on Alarm Response

SBT designations BACnet property Function blocks (BACnet objects)

Long name Ref. Description Other Binary Analog Multistate
Alarm enable EnAlm Alarm enable Alarm_Enable Pulse Converter I/O/V I/O/V I/O/V
Event Enrollment

Event enable EnEvt Event enable Event_Enable Pulse Converter I/O/V I/O/V I/O/V
Command Control1
Power Control1
AlarmCollection
Trend Logs
Event Enrollment
Loop

Event detection EnEvtDet Enable event Event_Detection_ Event Enrollment

enable detection Enable

Event state EvtSta Event state Event_State Discipline I/O1 I/O/V I/O/V I/O/V
Group1
Pulse Converter
Trend Logs
Device-Info1
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

Feedback value FbVal Feedback value Feedback_Value O O O

Upper limit HiLm Hi Limit High_Limit Pulse Converter I/O/V

Limit enable EnLm Enable limit Limit_Enable

Lower limit LoLm Low limits Low_Limit Pulse Converter I/O/V

Message text MsgTxt/EvtMsg Message text Message_Text Discipline I/O1 I/O/V I/O/V I/O/V
Group1
Pulse Converter
Command Control1
Power Control1
Loop
Event Enrollment

Deviation TiMonDvn Deviation Time_Delay Pulse Converter I/O/V I/O/V I/O/V

monitoring period monitoring period Power Control1
Loop

Switch-off TiMonOff Switch-off Time_Delay2 I/O/V

monitoring time monitoring time

Switch-on TiMonOn Switch-on Time_Delay1 I/O/V

monitoring time monitoring time

Dead band or Nz Neutral zone Deadband Pulse Converter I/O/V

dead zone

140 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Effects of BACnet Properties on Alarm Response
8

SBT designations BACnet property Function blocks (BACnet objects)

Long name Ref. Description Other Binary Analog Multistate
Out of service OoServ Out of order Out_of_Service Device-Info1 I/O/V I/O/V I/O/V
Discipline I/O1
Group1
Pulse Converter
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

Present value PrVal Present value Present_Value Pulse Converter I/O/V I/O/V I/O/V
Command Control1
Power Control1
AlarmCollection
Loop

Reference value RefVal Reference value Alarm_Value I/V

Reference values RefVals Reference values Alarm_Values I/V

Reliability Rlb Reliability Reliability Device-Info I/O/V I/O/V I/O/V

Discipline I/O1
Group1
Pulse Converter
Trend Logs
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

141 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Effects of BACnet Properties on Alarm Response

SBT designations BACnet property Function blocks (BACnet objects)

Long name Ref. Description Other Binary Analog Multistate
State flag StaFlg State flag Status_Flags Device-Info I/O/V I/O/V I/O/V
Pulse Converter
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

Suppress event SupEvtDet Event algorithm Event_Algorithm_ Event Enrollment

algorithm inhibit Inhibit

Event time stamp TiStmEvt Event time stamp Event_Time_Sta Device-Info1 I/O/V I/O/V I/O/V
mps Discipline I/O1
Group1
Pulse Converter
Trend Logs
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

Notification NotifSel Notification Notification_Func Device-Info1 I/O/V I/O/V I/O/V

function selector function selector tion_Selector Discipline I/O1
[NotifSel]
Group1
Pulse Converter
Trend Logs
Command Control1
Power Control1
AlarmCollection
Event Enrollment
Loop

Table 33: BACnet properties

1 Only in Desigo PX.

Alarm enable [EnAlm]

[EnAlm] (Boolean type) is used to enable and disable the monitoring of
OFFNORMAL alarms. OFFNORMAL alarms will only be detected if [EnAlm] is
TRUE. This is equivalent to the standard BACnet property Alarm_Enable.
FAULT alarms are monitored independently of the value of the alarm enable
property [EnAlm]. Monitoring is continuous and cannot be disabled.
If [EnAlm] is changed from TRUE to FALSE during operation, the timer for all
deviation monitoring periods [TiMonDvn] will be reset to zero. As soon as the value
of [EnAlm] reverts to TRUE, the associated [TiMonDvn] timer starts counting to its
preset value again from zero.
The value of [EnAlm] can be modified via BACnet clients or using the CFC editor
online. During operation, if [EnAlm] is changed from TRUE to FALSE while an
OFFNORMAL alarm is still active, this will result in an immediate state transition to
TO_NORMAL1. In other words, the existing OFFNORMAL alarm condition is seen
as having cleared, and the alarm state of the alarm source is updated accordingly.

142 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Effects of BACnet Properties on Alarm Response
8

Enable event [EnEvt]

[EnEvt] (Boolean type) is used to enable and disable the transfer of OFFNORMAL
and FAULT alarms. OFFNORMAL and FAULT alarms are only transferred if [EnEvt]
is TRUE. This is equivalent to the standard BACnet property Event_Enable.

Enable event detection [EnEvtDet]

[EnEvtDet] (Boolean type) lets you turn the intrinsic/algorithmic reporting on/off.
OFFNORMAL and FAULT alarms are only forwarded when [EnEvtDet] = TRUE.
This is equivalent to the standard BACnet property Event_Detection_Enable.

Event state [EvtSta]

This variable denotes the current alarm state of the object. It can accept three
values: NORMAL, OFFNORMAL (in the case of analog HIGH_LIMIT and
LOW_LIMIT values) and FAULT. The value of the variables is updated immediately
after the associated alarm state transition. This is equivalent to the standard
BACnet property Event_State.

Feedback value [FbVal]

[FbVal] is a feedback signal input, configured at a physical input via a separate
hardware address. This use of a physical input can also be the source of reliability
errors. [FbVal] can be neither overridden nor commanded. If [FbVal] is not
configured at a physical input, then, by definition, it will be equal in value to Present
Value, in which case no OFFNORMAL alarms can be issued via the output object.
This is equivalent to the standard BACnet property Feedback_Value.
Unlike the binary output and multistate output blocks, the analog output function
block does not use [FbVal] as a criterion for OFFNORMAL alarm conditions. If
[FbVal] is used, it can be a source of reliability errors and can result in FAULT
alarms.

Hi limit [HiLm]
This parameter (data type Real) determines the high alarm limit. If [PrVal] exceeds
the high limit value [HiLm] for longer than the period defined under [TiMonDvn], an
OFFNORMAL alarm condition prevails, namely: HIGH_LIMIT.

Enable limit [EnLm]

This variable only exists in the BACnet view of analog blocks (for reasons of
compatibility with the BACnet standard). It has exactly the same meaning as the
alarm enable variable [EnAlm] and its current value is derived from the value of
[EnAlm] (that is, [EnLm = EnAlm], Limit enable = Enable alarm). This variable is
equivalent to the standard BACnet property Limit_Enable.

Low limit [LoLm]

This parameter (data type Real) defines the low alarm limit. If [PrVal] exceeds the
high limit value [LoLm] for longer than the period defined under [TiMonDvn], an
OFFNORMAL alarm condition prevails, namely: LOW_LIMIT. This is equivalent to
the standard BACnet property Low_Limit.

Message text [MsgTxt]

For Desigo PX, the variable [MsgTxt] contains the message text of the last event
notification associated with TO_OFFNORMAL, TO_FAULT and TO_NORMAL
alarms.
As of Desigo V6.0 the [EvtMsg] variable provides the same function.

Deviation monitoring period [TiMonDvn]

This refers to a delay before generating the alarm if an alarm condition is detected
without a prior change in switch command (that is, without a set point change).
[TiMonDvn] is not an integrating function, that is, the condition causing a change in

143 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Effects of BACnet Properties on Alarm Response

the alarm state must persist without interruption for a period of time at least
equivalent to the duration of [TiMonDvn], before it has any effect. The BACnet
standard only supports a [TiMonDvn] for a monitoring period and the associated
alarm delay. This is equivalent to the standard BACnet property Time_Delay.
In certain applications, different end-switch monitoring periods are required for
Open and Close commands and for the Idle state.
For this reason, the additional properties [TiMonOff] und [TiMonOn] have been
introduced for the binary input, binary output, binary value and multistate output
objects.

Switch off- [TiMonOff] and switch on monitoring period [TiMonOn]

[TiMonOff] Delay time before an alarm is generated when there is a preceding set point
enable command. This is equivalent to proprietary BACnet properties Time_Delay1
and Time_Delay2.
[TiMonOn] Delay time before an alarm is generated in the event of a set point switch-off
command.
Application: Control of fire protection dampers (see further below).

Figure 116: Monitoring period

The definitions of the set point and the measured value depend on the object type:

Object type Set point Measured value

Binary Input invers [RefVal] [PrVal]

Binary Output [PrVal] [FbVal]

Binary Value invers [RefVal] [PrVal]

Table 34: The set point and the measured value depend on the object type

Examples The following example shows the use of the three time periods [TiMonDvn],
[TiMonOn], [TiMonOff]. For another example, see Alarm Example.
It is assumed that a fire damper has two separate feedback mechanisms (end
switches). This means that the damper is commanded via the commands Open
and Close. The first end switch, the Open switch delivers the signals Fully open or
Not fully open. The second end switch, the Closed switch delivers the signals Fully
closed or Not fully closed. The following is an example of how to connect the BO
(binary output for commanding and integrating the Open switch) and BI (the binary
output for the closed switch):

144 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Effects of BACnet Properties on Alarm Response
8

Figure 117: Fire protection damper with two end switches

Given the feedback signal [FbVal] Fully open, the Open and Close commands
follow the time sequence shown below, making use of all three deviation
monitoring times [TiMonDvn].

Figure 118: Time sequence

Since the BO block can handle the feedback of two different addresses, the fire-
protection damper solution can be further simplified by direct connection of the
Closed switch (Addr. 1) and Open switch (Addr. 2). In cases where both end
switches are simultaneously On or simultaneously Off, the BO block treats the
[FbVal] as invalid. Throughout this period, therefore, the alarm monitoring function
will return the value Alarm = OFFNORMAL. The circuit and time sequence for
normal and error conditions are as follows:

145 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Effects of BACnet Properties on Alarm Response

Figure 119: Circuit and time sequence for normal and error conditions

Figure 120: Fire protection damper timing with BO and two feedback addresses

Figure 121: Fire protection damper timing with BO and two feedback addresses

Error condition: The damper does not close quickly enough.

Neutral zone [Nz]

[Nz] (data type Real) can be used to define a switching hysteresis for the state
transition TO_NORMAL1. This is equivalent to the standard BACnet property
Deadband.

Out of service [OoServ]

The following applies to alarm response:
[PrVal] can also change for [OoServ=TRUE].
[PrVal] is monitored for alarms irrespective of the source of any change in [PrVal].
In other words, the value of [OoServ] does not affect the monitoring of
OFFNORMAL alarms. If [OoServ = TRUE], the [Rlb] property can be overwritten
via BACnet. However, the alarm monitoring system responds to changes in
Reliability in the same way as if [OoServ=FALSE]. This makes it possible to
simulate FAULT alarms.
In the BACnet Device Info object, this Boolean variable is FALSE at the very time
when the operating state is RUN, that is, when the D-MAP program is being run on

146 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Effects of BACnet Properties on Alarm Response
8

the automation station. All the alarm-generating blocks (including the BACnet
Device Info Object) are only monitored in the operational status RUN. Corresponds
to the standard BACnet Property Out_of_Service.

Present value [PrVal]

OFFNORMAL alarms are monitored exclusively on the basis of the current value of
[PrVal] the present value variable. The source of this present value (whether a
process value, operator value, replacement value or commanded value) is
irrelevant. This is equivalent to the standard BACnet property Present_Value.

Reliability [Rlb]
The value under [PrVal] is only plausible if [Rlb] = NO_FAULT_DETECTED.
When [Rlb] <> NO_FAULT_DETECTED, this is precisely the condition for a FAULT
alarm.
The BACnet Device Info Object is an exception. The value of [Rlb] for the BACnet
device object is NO_FAULT_DETECTED, except in the case of the fault
FLASH_FULL (FAULT condition). This is equivalent to the standard BACnet
property Reliability.

Reference value [RefVal]

[RefVal] is a set point, used to set the value which [PrVal] (the measured value)
must assume in order to initiate an alarm after the time defined by [TiMonDvn] has
expired. [RefVal] is equivalent to the standard BACnet property Alarm_Value.

Reference values [RefVals]

The variable [RefVals] comprises a list of multistate elements. The value range
(number of states) of the items in the list is the same as for [PrVal]. All states to be
treated as OFFNORMAL are entered under [RefVals]. [RefVals] is equivalent to the
standard BACnet property Alarm_Values.
Example of [RefVals] : STEP 1, STEP 2, STEP 4

Name Value
State 1 STEP 1

State 2 STEP 2

State 3 STEP 4

Table 35: Reference values

In this example, an incoming OFFNORMAL alarm will be detected if [PrVal] =

STEP 1, STEP 2 or STEP 4 after expiry of the period defined by [TiMonDvn].

State flag [StaFlg]

The variable [StaFlg] includes the two bits 'In_Alarm' and 'Fault'.
By definition, In_Alarm is TRUE whenever [EvtSta] is not equal to NORMAL.
By definition, FAULT is TRUE whenever [EvtSta = FAULT].
The value of these two [StaFlg] variables is thus derived from another variable.
For each change of the variable [StaFlg] a Change of Value (COV) notification is
sent to all COV subscribers of the alarm-generating object. In this way, the COV
subscribers can be kept informed of an alarm state in their COV server. This is
equivalent to the standard BACnet property Status_Flags.

Suppress event detection [SupEvtDet]

[SupEvtDet] (Boolean type) lets you turn the OFFNORMAL and FAULT alarm
detection on/off. OFFNORMAL and FAULT alarms are only detected when
[SupEvtDet] = FALSE. This is equivalent to the standard BACnet property
Event_Algorithm_Inhibit.

147 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Response of the Function Blocks

Event time stamp [TiStmEvt]

This variable (ARRAY [3], type TimeStamp), contains time stamps for the last
changes of state of the alarm-generating object TO_OFFNORMAL, TO_FAULT
and TO_NORMAL. The value of the variables is updated immediately after the
associated alarm state transition. This is equivalent to the standard BACnet
property Event_Time_Stamps.

Notification function selector [NotifSel]

This variable specifies if the alarm function is executed as per default pattern
(Simple-/Basic-/Extended alarm) or as per a customized alarm function.

8.4 Alarm Response of the Function Blocks

Alarm Collection
The default value of [EnEvt] for the Alarm Collection object is FALSE, that is,
[EvtSta] transitions are not notified.
An OFFNORMAL alarm is generated when:
● The following applies to one or more alarm collection members:
[EvtSta] <> NORMAL and applies simultaneously for all these members:
[StaFlg].Fault = false.
A FAULT alarm is generated when:
● The following applies to one or more alarm collection members:
[StaFlg].Fault = true and therefore is set [Rlb] = UNRELIABLE_MEMBERS.

Analog Input, Analog Value, Analog Output

The Analog Input, Analog Value and Analog Output function blocks all have an
identical alarm handling procedure.
The analog output function block also has a feedback value [FbVal]; however, this
is not used for alarm monitoring. High and low alarm limits (variables [HiLm] and
[LoLm]) are set for the OFFNORMAL alarms of analog objects. An OFFNORMAL
alarm occurs either when the high alarm limit is exceeded, or when the current
value falls below the low alarm limit. OFFNORMAL alarms are thus subdivided into
two subcategories: HIGH_LIMIT and LOW_LIMIT. In addition, the variable [Nz] can
be used to define a switching hysteresis for [HiLm] and [LoLm] to prevent over-
frequent switching of alarms around the alarm limit.
Alarm response An OFFNORMAL alarm is generated:
● [PrVal] has either remained above the high alarm limit specified by the [HiLm]
variable for a period of time longer than the period specified in [TiMonDvn]
● or [PrVal] has remained below the low alarm limit specified by the [LoLm] for a
period of time longer than the period specified in [TiMonDvn]
An existing OFFNORMAL (HIGH_LIMIT) alarm will disappear when [PrVal] has
remained below the value ([HiLm] + [Nz]) for longer than the time specified in the
variable [TiMonDvn].
An existing OFFNORMAL (LOW_LIMIT) alarm will disappear when [PrVal] has
remained below the value ([HiLm] + [Nz]) for longer than the time specified in the
variable [TiMonDvn].
● A FAULT alarm is generated as soon as the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.

148 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Response of the Function Blocks
8

Figure 122: Alarm response

In Desigo S7 the monitoring described are not reported from the device object, but
rather from an MV object.

BACnet Device Info Object

OFFNORMAL alarms All the alarm-generating objects described so far model specific types of individual
data points (physical or virtual). The BACnet device object by contrast, models the
properties of an automation station as a complete entity. Alarm-relevant faults
which cannot be allocated to a data point can be generated in an automation
station (see the examples further below). This is why the BACnet device object
includes an alarm mechanism. The alarm state machine and the alarm-related
variables are essentially the same as for all the other alarm-generating block types.
The difference lies in the possible causes of the alarm:
The alarm conditions described below cause the generation of an OFFNORMAL
alarm in the BACnet Device Object:
Battery low The battery in an automation station is checked periodically. An alarm is generated
if the battery voltage is too low, or if the battery itself is missing. When the required
voltage level is reached again, the alarm is reset with BATTERY_NOT_LOW.
RAM Pattern failed This indicates that a memory-check error was found when the automation station
was switched on. If no memory-check error is detected when the automation
station is next switched on, the alarm will be reset.
Recipient not receivable A recipient name (for example, the configured recipient of an alarm) could not be
resolved, because, for example, the network connection to the recipient was
interrupted. This causes an alarm to be generated. The alarm is cleared as soon
as the subsequent name resolution process succeeds.
Notif. Class ref. missing Each alarm-generating block includes a reference to a Notification Class block. If
the referenced Notification Class block does not exist, the BACnet Device Object
generates an alarm.
Life check error While the life check is in progress, the primary server finds that it is unable to
communicate with one or more of its backup servers (for example, owing to a
network failure). This causes an alarm to be generated. The alarm is cleared when,
during a subsequent life check, all the backup servers are found again.
Primary server not found This bit is set when the backup server detects that the primary server is no longer
connected to the network. At the same time a notification (data-type STRING) is
sent, defining the source, target and reason. The bit is reset as soon as the backup
server detects the primary server on the network again.

FAULT alarms
The condition described below causes a FAULT alarm to be generated in the
BACnet Device Object:

149 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Response of the Function Blocks

Flash is full The automation station checks periodically whether there is at least one free page
(64 kB) in the flash memory. This bit is set if the flash memory falls below this value.
The bit is reset when the flash memory contains at least one free page again.
Alarm response of the BACnet Device Object is also parameterized or depicted by
the number of variables, but the display differs: The BACnet Device Object is not
displayed by a D-MAP function block, but rather only visible via BACnet. The
variables described are therefore only accessible as properties of the BACnet
Device Object.

Binary Input and Binary Value

The alarm handling process is identical for the function blocks Binary Input and
Binary Value.
● An OFFNORMAL alarm occurs when [PrVal] assumes the value specified by
the variable [RefVal] for a time period at least equivalent to the delay time
specified in the variable [TiMonDvn], [TiMonOff] or [TiMonOn].
● An existing OFFNORMAL alarm condition will disappear (a) when [PrVal]
assumes the value complementary to [RefVal] for a period at least equivalent
to the period specified in [TiMonDvn], [TiMonOff] or [TiMonOn] or (b) when
[EnAlm] is changed from TRUE to FALSE (see further below).
● A FAULT alarm is generated when the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.

Figure 123: Binary Input and Binary Value

Binary Output
The alarm handling process in the binary output function block is essentially
different from that of the binary input and binary value blocks.

150 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Response of the Function Blocks
8

● An OFFNORMAL alarm occurs when the current values of the variables [PrVal]
and [FbVal] differ from each other for a time period at least equivalent to the
delay time specified in [TiMonDvn], [TiMonOff] or [TiMonOn].
● An existing OFFNORMAL alarm will disappear when the current [PrVal] und
[FbVal] are again identical and remain so for a period at least equivalent to the
time specified in the variable [TiMonDvn].
● A FAULT alarm is generated when the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when the [Rlb] property changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
In the case of the binary output, [Rlb] errors may originate both from the [PrVal]
(or associated physical output) and from the [FbVal] (or associated physical
input).
● A FAULT alarm will disappear as soon as the variable [Rlb] changes from a
value not equal to NO_FAULT_DETECTED back to the value
NO_FAULT_DETECTED.

Figure 124: Binary Output

Command Control An OFFNORMAL alarm is generated:

● A monitored, referenced object is not enabled
● A referenced object cannot be enabled
A FAULT alarm is generated when:
● A referenced object is not found
● A referenced object is not a commandable object (output object or value object)
● Invalid priorities are used for the referenced object (valid priorities are Priority 2,
5, 14 and 16)
● ProgramValue or ExceptionValue are outside the permissible range
● The referenced objects have a different number of operating modes
● The function table is empty

Discipline I/Os and Group

Alarm response Alarm handling is identical for Discipline I/O and Group blocks. These function
blocks only support FAULT alarms.
● A FAULT alarm is generated as soon as the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to

151 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Response of the Function Blocks

NO_FAULT_DETECTED to another value not equal to

NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.
The following conditions cause a FAULT alarm to be initiated:
● Address conflict:
The subsystem fails to recognize the device defined in the [IOAddress]
parameter. This alarm is issued by the associated function block.
● Communications error:
The subsystem indicates a communications failure. This can be due to a bus
open circuit or a faulty device, or, very rarely, to a communications overload on
the bus. These alarms are indicated by the shared function block.
The subsystem indicates an inadmissible response from a device for example
in the case of faulty QAX… room unit. These alarms are indicated by the
shared function block.

Multistate Input and Multistate Value

The alarm handling process is identical for the function blocks Multistate Input and
Multistate Value.
● An OFFNORMAL alarm occurs when [PrVal] assumes one of the values
specified under [RefVals] (list of multistate values) and remains at this value for
a period at least equivalent to the time specified by the variable [TiMonDvn]. In
particular, this applies when [PrVal] changes from one value in [RefVals] to
another value in [RefVals].
● An existing OFFNORMAL alarm condition will disappear either if [PrVal] reverts
to a value not contained in the [RefVals] list, and retains this value for a period
at least equivalent to the period specified in [TiMonDvn], or if [EnAlm] is
changed from TRUE to FALSE (see further below).
● A FAULT alarm is generated when the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.

Figure 125: Multistate Input and Multistate Value

Multistate output
The alarm handling procedure for the Multistate Output function block is different
from the alarm handling procedure for the Multistate Input and Multistate Value
function blocks, but follows the same principles as for the Binary Output block:

152 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Response of the Function Blocks
8

● An OFFNORMAL alarm occurs when the current values of the variables

[RwVal] and [FbVal] differ from each other for a time period at least equivalent
to the delay time specified in [TiMonDvn].
● An existing OFFNORMAL alarm will disappear when the current [PrVal] und
[FbVal] are again identical and remain so for a period at least equivalent to the
time specified in the variable [TiMonDvn].
● A FAULT alarm is generated when the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when the [Rlb] property changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED. In the case of the multistate output block, [Rlb] errors
may originate both from the [PrVal] (or associated physical output) and from
[FbVal] (or associated physical input).
● A FAULT alarm will disappear as soon as [Rlb] changes from a value not equal
to NO_FAULT_DETECTED back to the value NO_FAULT_DETECTED.

Figure 126: Multistate Output

Power Control
An OFFNORMAL alarm is generated:
● The UP command is issued but the maximum stage has already been reached
● The UP command causes MaxPower to be exceeded
● Table_No is set outside the admissible range
A FAULT alarm is generated when:
● A referenced object is not found
● A referenced object is not a multistate value object
● Object_No. is outside the admissible range
● StepLimit is outside the range of the referenced object
● The function table is empty

Pulse Converter
Alarm response An OFFNORMAL alarm is generated, when [PrVal]:

153 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Response of the Function Blocks

● [PrVal] has remained above the high alarm limit specified by the [HiLm]
variable for a period of time longer than the period specified in [TiMonDvn]
(HIGH_LIMIT)
● or [PrVal] has remained below the low alarm limit specified by the [LoLm]
variable for a period of time longer than the period specified in [TiMonDvn]
(LOW_LIMIT)
An existing OFFNORMAL (HIGH_LIMIT) alarm will disappear when [PrVal] has
remained below the value ([HiLm] + [Nz]) for longer than the time specified in the
variable [TiMonDvn]
An existing OFFNORMAL (LOW_LIMIT) alarm will disappear when [PrVal] has
remained below the value ([HiLm] + [Nz]) for longer than the time specified in the
variable [TiMonDvn]
● A FAULT alarm is generated as soon as the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.

Figure 127: Pulse Converter

Trend Log
Alarm response The Trend Log function has an Intrinsic Reporting mechanism, but does not issue
OFFNORMAL alarms.
● A FAULT alarm is generated as soon as the [Rlb] property of the function block
assumes any value other than NO_FAULT_DETECTED. In particular, this is
the case when [Rlb] changes from a value not equal to
NO_FAULT_DETECTED to another value not equal to
NO_FAULT_DETECTED.
● A FAULT alarm will disappear as soon as the [Rlb] property of the function
block changes from a value not equal to NO_FAULT_DETECTED back to the
value NO_FAULT_DETECTED.
Event message An event is generated when:
● The record count exceeds the record count value [RecCnt] set via the
notification threshold [NotifThd], that is, the local non-volatile trend memory is
overflowing.

Event Enrollment
The Event Enrollment object monitors referenced BACnet properties in other
objects. The referenced property can be located in the local device or in another
device.

154 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Response of the Function Blocks
8

Event algorithms Monitoring details for a property value are defined by means of event algorithms.
An event algorithm has a specific parameter. Event algorithms are the same as for
Intrinsic Reporting. Intrinsic Reporting uses a subset of the possible event
algorithms of Event Enrollment.

Event_Type Event_State Event_Parameters Data Type

CHANGE_OF_BITSTRING NORMAL Time_Delay Unsigned
OFFNORMAL Bitmask BIT STRING
List_Of_Bitstring_Values list of BIT STRING

CHANGE_OF_STATE NORMAL Time_Delay Unsigned

OFFNORMAL List_Of_Values list of BACnetPropertyStates

CHANGE_OF_VALUE NORMAL Time_Delay Unsigned

Bitmask BIT STRING
Referenced_Property_Increment choice {BIT STRING, REAL}

COMMAND_FAILURE NORMAL Time_Delay Unsigned

OFFNORMAL Feedback_Property_Reference BACnetDeviceObjectPropertyRef
erence

FLOATING_LIMIT NORMAL Time_Delay Unsigned

HIGH_LIMIT Setpoint_Reference BACnetDeviceObjectPropertyRef
LOW_LIMIT erence
Low_Diff_Limit REAL
High_Diff_Limit REAL
Deadband REAL

OUT_OF_RANGE NORMAL Time_Delay Unsigned

HIGH_LIMIT Low_Limit REAL
LOW_LIMIT High_Limit REAL
Deadband REAL

BUFFER_READY NORMAL Notification_Threshold Unsigned

Previous_Notification_Count Unsigned

CHANGE_OF_LIFE_SAFETY NORMAL Time_Delay Unsigned

OFFNORMAL List_Of_Alarm_Values list of BACnetLifeSafetyState
LIFE_SAFETY_ALARM List_Of_Life_Safety_Alarm_Values list of BACnetLifeSafetyState
Mode_Property_Reference BACnetDeviceObjectPropertyRef
erence

EXTENDED Any BACnetEventState Vendor_Id Unsigned

Extended_Event_Type Unsigned
Parameters Extended_Event_Type

UNSIGNED_RANGE NORMAL Time_Delay Unsigned

HIGH_LIMIT Low_Limit Unsigned
LOW_LIMIT High_Limit Unsigned

Table 36: Event types and states and their parameters and data types

Event notification An Event Enrollment object also monitors the status flag property of an object with
referenced property. If the FAULT flag of the referenced object is set, the Event
Enrollment object generates a Fault alarm.

Loop object
Alarm response The Loop object contains intrinsic reporting.
An OFFNORMAL alarm occurs when:

155 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Functions

● [XCtr] exceeds the limit (SetPoint + ErrorLimit) longer than the specified time
(HIGH_LIMIT) defined in variable [TiMonDvn]
● [XCtr] drops below the limit (SetPoint – ErrorLimit) longer than the specified
time (LOW_LIMIT) defined in variable [TiMonDvn]
An existing OFFNORMAL alarm (HIGH_LIMIT) disappears again when [XCtr]
drops below the value (SetPoint + ErrorLimit – Deadband) longer than the specified
time defined in variable [TiMonDvn].
An existing OFFNORMAL alarm (LOW_LIMIT) disappears again when [XCtr]
exceeds the value (SetPoint – ErrorLimit + Deadband) longer than the specified
time defined in variable [TiMonDvn].
FAULT alarm:
● A FAULT alarm occurs immediately as soon as [Rlb] of the function block has a
value other than NO_FAULT_DETECTED. This is true in particular when [Rlb]
changes from a value that is not equal to NO_FAULT_DETECTED to another
value that is not equal to NO_FAULT_DETECTED.
● A FAULT alarm disappears immediately as soon as [Rlb] of the function block
changes again from a value that is unequal to NO_FAULT_DETECTED to the
value NO_FAULT_DETECTED.

8.5 Alarm Functions

Depending on the type and degree of urgency of the alarm, the system user may
be required to acknowledge a change in the alarm state with an explicit operator
action.
Acknowledgement There are two types of acknowledgement:
● Acknowledgement: Confirmation of an incoming alarm
● Reset: Confirmation that an alarm is no longer present
This type of interaction can be carried out locally or with clients, via the network.

Standard pattern
There are three standard categories of alarm, or alarm functions, reflecting the type
of acknowledgement required:
● Simple alarm
● Basic alarm
● Extended alarm
Each alarm source is assigned (via a Notification Class, see further below) to one
alarm function only. No further distinction is made at this stage between
OFFNORMAL and FAULT alarms.
Simple alarm Neither incoming alarms (disturbance appears) nor disappearing alarms
(disturbance disappears) require acknowledgement.

Figure 128: Simple alarm

Basic alarm Acknowledgment is required for incoming alarms only, but not for alarms that have
been cleared (that is, acknowledgement required but not reset).

156 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Functions
8

Figure 129: Basic alarm

Extended alarm Locking alarm with acknowledgement of incoming alarms (disturbance appears)
and cleared alarms (disturbance disappears). Alarms in this category require both
acknowledgement and reset.
While testing the system, it may not be possible to reset an alarm. The reason is
that an Extended Alarm is not reset until it has been acknowledged, and the time
delay has expired.

Figure 130: Extended alarm

Key:
The alarm remains locked until the fault has disappeared and has been
acknowledged and a reset has been carried out. For example:
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.

Figure 131: Alarm source with Simple message alarm function

157 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Management by Notification Class

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 This feature is used to represent the acknowledgement status, or to handle
transitions 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 Time of the last acknowledgement (time stamp).
acknowledgement

8.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

Figure 132: Alarm management by notification class

Each alarm-generating object is assigned one notification class [NotifCl] only, but
one notification class can be used by more than one alarm-generating object. This

158 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Management by Notification Class
8

makes it possible to create a Notification Class object for each group of alarms (for
example, HVAC alarms, fire alarms etc.). Each alarm source in a given alarm
group is assigned to the [NotifCl] for that group.
There are global and local notification class objects:
● Global notification class: One set of max. 18 global notification class objects
per site. Global notification classes are replicated and thus exist on all Desigo
PX of a site in identical form.
● Local notification class: On Desigo PX, local notification classes can be
engineered, but are NOT replicated.
● Desigo Room Automation supports exclusively local notification classes.
Interface definition The notification class function block [NotifCl] is the means by which functionality is
transferred from the BACnet standard into the CFC environment.

Figure 133: Function block

This function block contains the instance number of the Notification Class (an
integer). which must be identical to the value entered in the subordinate alarm
sources. This makes it possible to create a unique reference.
The number must not be modified online.
In Desigo S7 all Notification Classes are compiled in a function block.
Notification class number There are 18 predefined global notification classes. The notification class is
identified with the two independent variables AlarmFunction and AlarmClass, and
referenced in the alarm source:
● AlarmFunction [Simple(1), Basic(2), Extended Alarm(3)]
● AlarmClass [UrgentAlarm (1), HighPrioAlarm (2), NormalAlarm (3),
LowPrioAlarm (4), UserDefinedAlarm (5) and OffLineTrend (6)]
Formula The notification class number is calculated as follows:
NotificationClass# := 10 * AlarmClass + AlarmFunction
This gives the following notification classes:

AlarmClass AlarmFunction Priority Uses NotificationClass#

(default values) (derived)
To-Offnormal
To-Fault
To-Normal
Highly critical alarms, system
messages, device info object

UrgentAlarm Simple 1, 1, 5 11

UrgentAlarm Basic 1, 1, 5 12

UrgentAlarm Extended 1, 1, 5 13

Critical alarms

HighPrioAlarm Simple 2, 2, 6 21

HighPrioAlarm Basic 2, 2, 6 22

HighPrioAlarm Extended 2, 2, 6 23

Normal alarms

NormalAlarm Simple 3, 3, 7 31

159 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Management by Notification Class

AlarmClass AlarmFunction Priority Uses NotificationClass#

(default values) (derived)
To-Offnormal
To-Fault
To-Normal
NormalAlarm Basic 3, 3, 7 32

NormalAlarm Extended 3, 3, 7 33

Non-critical alarms

LowPrioAlarm Simple 4, 4, 8 41

LowPrioAlarm Basic 4, 4, 8 42

LowPrioAlarm Extended 4, 4, 8 43

As project-specific alarms for

special applications

UserDefinedAlarm Simple 5, 5, 9 51

UserDefinedAlarm Basic 5, 5, 9 52

UserDefinedAlarm Extended 5, 5, 9 53

Offline trends
The To-Normal priority must
be such that it is less than or
equal to the Alarm Priority
Limit of the device object (for
Remote Mgmt)

OffLineTrend Simple 2, 2, 2 61

OffLineTrend Basic 2, 2, 2 62

OffLineTrend Extended 2, 2, 2 63

Table 37: Notification classes

Project-specific notification classes can be defined in addition to predefined ones.

Alarm classes 7...16 are intended for this purpose. The associated calculation of a
notification class number is identical to calculation of predefined notification class
numbers.
Customized alarms can be engineered in Desigo PX. In this case, the value for a
notification class number can be defined without restrictions.
Priority [Prio] This defines the alarm priority on the basis of which alarm and system events are
to be transmitted to the receivers. Every transition can be described individually
with this BACnet property, data type ARRAY of INTEGERS [TO_OFFNORMAL;
TO_FAULT; TO_NORMAL]. Priority levels can range in value from 0 to 255. The
lower the value, the higher the priority. In Desigo only priorities 1 to 9 are used.
Alarmfunction [AlmFnct] Alarm function types: Simple, Basic or Extended. [AlmFnct] is only supported by
Desigo PX.
Destination list [RecpList] The configured (permanent) alarm recipients, the week days, and the time window
in which the alarm recipient is operated, are entered here. [RecpList] is equivalent
to the standard BACnet property Recipient_List.
Destination list [DestLi] This is where the configured (permanent) alarm receivers are entered, together
with the days of the week and the time-window in which the alarm receiver is
operated. [DestLi] is only supported by Desigo PX.

160 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Management by Notification Class
8

Remote-Area_Site "Luzern" Remote-Area_Site "Bern"

Device Name "CC 01" Device Name "CC 02" Device Name "CC 03"

Site "Muri"
BACnet PTP

BACnet PTP

Device Name "CC 04"

Router

Site Site Site

"Suhr" "Emmen" "Sempach"

Figure 134: Allocation of operator units to a remote area site

Operator units:
● Permanently connected operator units (and hence, alarm receivers) are
addressed by their Device Name.
● Operator units (and hence alarm receivers) with a point-to-point connection
(PTP connection) are addressed with a Remote Area Site identifier and their
Device Name. For example:
B=fff for permanent connection
B=kkk:aa for point-to-point connection (PTP connection)
● Adjustments are required during the addressing process so that there is no
conflict between the names of operator units and the plant or room
management designations.
Permanent and point-to-point connections:
● For alarm receivers, the address syntax (see further below) indicates the type
of connection: permanent or PTP connections.
● Desigo PX automation stations with half-routers must know the Remote Area
Site designators of their remote alarm receivers to enable an PX automation
station to resolve the remote alarm receiver designator.

161 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Routing over the Network

B=
Permanently
DeviceIdentifier connected
alarm receiver

RemoteAreaSite Alarm receiver with

PTP connection
and Desigo PX
DeviceIdentifier half router

Alarm receiver with

PTP connection
and third-party
DeviceIdentifier half router

Not case-sensitive

A..Z
a..z
0..9

Figure 135: Alarm receiver syntax

Element Description
DeviceName Device name. In plain text so that the user can understand it.
Example: CC 01

DeviceIdentifier Device Identifier. Alternative syntax for the alarm receiver of a third-
party manufacturer. If the alarm receiver has a special address range
or if DeviceName does not work.
Example: [13456]

RemoteAreaSiteName Remote area site name. In plain text so that the user can understand it.
Example: Chur

NetworkNumber Network number. Required with a third-party half router.

Example: [3]

Table 38: Alarm receiver syntax

8.7 Alarm Routing over the Network

Alarm server and alarm clients
Alarm servers are entities capable of producing an alarm. Alarm clients are entities
capable of receiving an alarm.
There are two types of alarm client: temporary alarm receivers and pre-configured
alarm receivers. The following concept for temporary alarm recipients is only valid
for Desigo PX.

Temporary alarm Temporary alarm receivers are not defined at the engineering stage. They can be
receivers connected to or removed from the network at any time during operation. If a
temporary alarm receiver is connected to the network, it will perform the following
activities for every alarm server:

162 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Routing over the Network
8

● The alarm recipient enters its address in the BACnet property recipient list
[RecpList] of the BACnet device object of the automation station, using the
BACnet service AddListElement.
● Read information about all currently existing alarms, and all currently
outstanding acknowledgements, from the automation station (BACnet service
GetEventInformation). This ensures that the alarm receiver – irrespective of
when it was connected – displays the current alarm status of the system.
After making these entries, the temporary alarm receiver, while connected, will
receive all alarm messages from the automation station in accordance with the
routing mechanisms described below.
If an automation station cannot transfer an alarm message to a temporary alarm
receiver (for example, because it is no longer connected to the network), the
address of the receiver concerned will be removed from the [RecpList]. All alarm
messages destined for that receiver will then be deleted.
Preconfigured alarm The preconfigured alarm receivers are entered in the notification class object:
receivers ● In the [DestList] for Desigo PX
● In the [RecpList] for Desigo Room Automation

Time response in the network

The routing of all alarm and acknowledgement ,messages between the alarm
server and the alarm clients takes place over the BACnet network using special
BACnet services. These are:
● Confirmed Event Notification for all changes in the alarm state of an alarm-
generating object (TO_OFFNORMAL, TO_NORMAL, TO_FAULT), and for
messages via local acknowledgements. Direction: Direction: From alarm server
to alarm client.
● AcknowledgeAlarm for the routing of acknowledgements (including reset)
performed by the user on an alarm client. Direction: From alarm client to alarm
server.
The two services are referred to as Confirmed Services, that is, the receiving
device always confirms the receipt of a service by immediately returning a
SimpleAck message. This tells the transmitting device that its message has been
received by the receiving device. If no SimpleAck message is received, the
transmitting devices tries to send the message again (up to three times).
An alarm is always issued by one (and only one) alarm server. Generally, however,
there will be several alarm clients on the network. To maintain consistency, all
alarm clients must always display the same alarm state. For this reason, all alarm-
related functions must always be routed to all the alarm clients. The procedure is
the same for both temporary and pre-configured alarm receivers.
The following time-diagrams describe the communications via the network for the
various alarm-related events.
Change of alarm state

SimpleAck
SimpleAck

t t t

Figure 136: Change of alarm state

This procedure is carried out for every change in alarm state on an alarm server:
TO_OFFNORMAL, TO_FAULT und TO_NORMAL. The data record Confirmed
Event Notification contains the following information:
● BACnet address of the alarm server
● Object ID of the alarm-generating object

163 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Routing over the Network

● Time stamp
● Alarm priority
● Initial and final state of the transmitted state transition (this is used to determine
whether the state transition is TO_OFFNORMAL, TO_FAULT or TO_NORMAL)
● Acknowledgement required [AckReq]: Does the notified state transition require
acknowledgement or not?
● Alarm text
● Other technical details
Based on this information, the alarm client can present the alarm in a
comprehensible way; it may also read additional information automatically from the
alarm server, and if required, return any acknowledgement to the correct address.
If a temporary alarm receiver does not confirm receipt with a SimpleAck message
(via the Confirmed Event Notification input), the alarm server will try three times
more to transmit the alarm to the relevant alarm receiver. The message for this
alarm client will then be lost and its reference will be deleted from the [RecpList] of
the BACnet device object.
Alarm acknowledgement This process is performed for all acknowledgements made on an alarm client.
over the network

SimpleAck

SimpleAck

t t t

Figure 137: Alarm acknowledgement over the network

Acknowledge and reset The alarm can be acknowledged by any alarm client. The AcknowledgeAlarm data
record contains information as to which alarm is being acknowledged and other
details related to this alarm and the acknowledging alarm client. The alarm
acknowledgement is confirmed with a SimpleAck message by the alarm server
which generated the alarm. All other alarm clients in the network will be sent a
Confirmed Event Notification to notify them of the alarm acknowledgement. They,
in turn, will send a SimpleAck message to acknowledge the receipt of this
notification, the objective being to ensure that all clients have up-to-date and
consistent information.
Local alarm Alarms can also be acknowledged and reset locally on the alarm server. The alarm
acknowledgement is acknowledged internally in the alarm server that generated the alarm. Confirmed
Event Notifications are now transmitted to all alarm clients, to notify them that the
alarm has been acknowledged. The alarm clients, in turn, send a SimpleAck
message to acknowledge their receipt of the Confirmed Event Notification.

SimpleAck
SimpleAck

t t t

Figure 138: Local alarm acknowledgement

Each alarm-generating object has an [EnEvt] parameter (data type: Boolean).

Alarm messages (and system events) are only transmitted over the network if

164 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Queuing
8

Disabling the routing of [EnEvt=TRUE]. This does not affect the alarm monitoring of the object, that is, the
alarms alarm state machine is always kept up to date.

8.8 Alarm Queuing

Until they have been forwarded to all the pre-configured alarm recipients, all alarm
messages are normally stored in the automation station.
Each automation station has its own alarm queue for this purpose. Each incoming
alarm and each system event is entered in the queue. An entry remains in the
queue until the alarm or system event has been sent with a confirmed event
notification to all recipients listed in the notification class object, and until the
relevant acknowledgements have been received.
If the queue is full to overflowing, the oldest entries are deleted automatically, and
a system event message is generated. Entries are deleted irrespective of alarm
priority.
Alarm queuing has no effect on the alarm state of the alarm source.
Alarms destined for a temporary alarm recipient are not saved in the automation
station. If a temporary alarm recipient can no longer be reached, the address of the
recipient concerned is removed from the [RecpList] of the device object.
BACnet device object The queuing of alarms is controlled by the following BACnet properties in the
properties device object of the Desigo PX automation stations. These properties are not
mapped to a function block, and can therefore only be viewed and modified online.
Buffer size [BufSize] This BACnet property defines the maximum number of entries which can be saved
in the queue.
A new value will only be accepted if it is greater than the record count [RecCnt].
Buffer size [BufSize] of the alarm queue.
● Default = 100 (PXC) or 150 (PXR)
● Range = 10…500 depending on the available memory space
Record count [RecCnt] This BACnet property represents the number of entries currently stored in the
queue.
The alarm queue can be deleted by writing the value 0 to this property. A write of a
value not equal to 0 results in an error message.
If the queue is deleted, this information is entered as a system event in the queue
and transmitted to the receivers. This causes the value to change to 1 as soon as
[RecCnt] is set to zero.
Notification threshold This BACnet property defines the dial-out threshold, and the number of alarms to
[NotifThd] be deleted in the event of a queue overflow.
If [RecCnt] is greater than or equal to [NotifThd], a connection is established with
any alarm recipients connected by cable (modem) which are destined to receive
alarms and events from the queue. The connection is established provided that the
remote alarm recipient concerned is listed in the notification class object.
The message threshold also defines how many alarms are to be deleted in the
event of a queue overflow. As many alarm entries are deleted as necessary until
[RecCnt] is equal to [NotifThd]. This function does not distinguish between local
and remote alarm recipients in the notification class object.
To avoid deleting too many alarms, it is recommended that [NotifThd] be set to
approximately 80% of the [BufSize].
Alarm queue message threshold [NotifThd]:
● Default = 80 (PXC) or 130 (PXR)
● Range = 5…495
Alarm priority limit This BACnet property defines another independent threshold for dial-out.
[PrlmAlm]

165 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Common Alarms

An alarm priority which is less than or equal to [PrlmAlm] results in a connection

with any alarm recipients connected by cable (modem) which are destined to
receive alarms and events from the queue. The connection is established provided
that the remote alarm recipient concerned is entered in the list of Notification Class
objects.
Alarm priority limit [PrlmAlm]:
● Default = 2 (HighPrioAlarm or UrgentAlarm)
● Range 0…255
If the notification class object contains only local alarm recipients, then the
optimum results are achieved by use of the default values for control of alarm
queuing. The default values should therefore not be changed.
If the notification class object contains remote alarm recipients, then it may be
appropriate to modify the default values for control of alarm queuing.
The values for [NotifThd] and [PrlmAlm] determine when a remote cable
connection (modem) is to be established, in order to inform the user of the
occurrence of alarms.
If low-priority alarms are to be forwarded immediately, the [PrlmAlm] value must be
increased (the higher the number, the lower the alarm priority). The value for
[NotifThd] must not be modified.
The value for [NotifThd] can be reduced, however, in cases where a connection is
to be established when there is a smaller number of alarms in the alarm queue. It
is important to ensure, however, that the difference between [BufSize] and
[NotifThd] does not become too great, as this is the value that controls the deletion
of alarms in the event of a queue overflow.
Note that modifying these values also affects connection costs.
It takes time to establish a connection by cable (modem). If it is likely that further
alarms will occur during this time, thereby causing the queue to overflow, the
difference between [BufSize] and [NotifThd] should be increased.
The following settings are recommended:
● Buffer size [BufSize] = 120
● Notification threshold [NotifThd] = 80
In cases of doubt, the default values should be left unchanged.
The parameters are hardcoded in Desigo S7 and not mapped in BACnet. A
project-specific modification is not required since only Ethernet-IP networks are
supported.

8.9 Common Alarms

The BACnet object alarm states InAlarm, Unacked and Unreset are grouped in the
following blocks:
● The CommonAlarm block for Desigo PX
● The CommonEvent block for Desigo Room Automation
The difference between CommonAlarm and CommonEvent is, that the
CommonAlarm block supports Intrinsic Reporting. The alarm detection and
notification of the CommonEvent block is handled by a special Event Enrollment
object called CommonEventEnrollment. The CommonEventEnrollment block also
handles the common alarm reset / ack and common manual intervention functions.
All alarms generated by alarm-generating BACnet objects on the same chart level
or subordinate charts are automatically grouped into a common alarm. There is
therefore no need for the user to create a common alarm by establishing links or
interconnections. The engineering process simply involves placing the block at the
required chart level. No other configuration steps are necessary.
Common alarm reset / ack Similarly, all the alarms covered by this block can be the subject of a common
alarm reset and acknowledge.

166 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Suppression
8

Acknowledging the common alarm object is equivalent to acknowledging all objects

on the same and lower levels in the hierarchy.
Resetting the common alarm object is the equivalent to resetting all objects on the
same and lower levels in the hierarchy.
Common manual The same common alarm object also uses the status flag Overridden to indicate
intervention the manual operation of one or more of the BACnet objects (with [StatFlag]
override facilities) on the same or a lower chart level. Manual intervention are
determined on the properties: Out of service [OoServ], overridden, commanding to
Prio 7 (manual switch) and Prio 8 (operator).
This diagram shows the practical application of the common alarm object within the
technical hierarchy. The common alarm object in the partial-plant compound
encompasses all the alarms of this partial plant. The higher-level common alarm
encompasses the alarms of both partial plants.

Figure 139: Common alarm object

In Desigo S7 the Common Alarm block in the CFC is nested with the block
generating the alarm.

8.10 Alarm Suppression

Alarm suppression refers to suppression of alarm and event notifications in the
Desigo system. Thus, sending BACnet event notifications is suppressed. Alarm
suppression does NOT prevent detection of alarm states.

Alarm suppression types

The following types of alarm suppression exist in Desigo:

167 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Suppression

● Alarm suppression by automation station using function block AS_STA allows

for implementing alarm suppression at the automation station level.
● Hierarchical alarm suppression is made possible via the common alarm object
based on the structure of the technical view.
● Specific alarm suppression: All alarmable objects offer alarm suppression by
object.
● Exceptions for alarm suppression: Each alarmable object has a pin SupEcpt.
This pin allows for defining exceptions to hierarchical alarm suppression.

Validity for alarm suppression

All types of alarm suppression apply to Desigo PX. Desigo Room Automation
devices can generate and suppress alarms.

Alarm suppression by automation station

AS_STA (Device Access) is a Desigo PX function block that allows to suppress all
alarms of an automation station. The function block allows for suppressing BACnet
event notifications by means of an application. Thus, sending of alarms and events
during, for example, maintenance, can be suppressed, for example, via a key
switch.
Alarm suppression is controlled via pin SupEvt. The following values are defined
for SupEvt:
● true: The automation station sends NO BACnet event notifications.
● false: The automation station sends BACnet event notifications.
For more information on function block AS_STA, see Desigo Firmware blocks,
automation level, Overview (CM110749) and Desigo Vxx Firmware blocks
(CM110729).
Desigo Room Automation supports the suppression of all alarms of an automation
station. To do this, it uses the device infrastructure objects CommonEvent and
CommonEventEnrollment.

Hierarchical alarm suppression

Hierarchical alarm suppression allows for suppressing alarms of a plant, partial
plant, aggregate, component, or subcomponent. Hierarchical suppression is based
on suppressing alarms of any part of a partial tree in the technical structure.
For Desigo PX hierarchical alarm suppression is carried out via the Alarm
Collection (CMN_ALM) object. CMN_ALM comprises all alarmable BACnet objects
as a group on the same or lower hierarchies in the technical view. Thus,
CMN_ALM allows for controlling alarm suppression for all alarmable BACnet
objects of a group.
Alarm suppression is controlled via pin SupEvt. The following values are defined
for SupEvt:
● true: Alarmable BACnet objects of a group do NOT send BACnet event
notifications.
● false: Alarmable BACnet objects of a group send BACnet event notifications.
Desigo Room Automation supports the hierarchical suppression of alarms. It uses
the CommonEvent and CommonEventEnrollment objects.
The CommonEvent object aggregates the alarm state of all BACnet objects on the
same or the lower hierarchy levels of the technical view.
The CommonEventEnrollment object monitors the CommonEvent object. The
hierarchical alarm suppression can be turned on or off in the
CommonEventEnrollment object.

Specific alarm suppression

All alarmable BACnet objects allow for specific suppression. Each alarmable
BACnet objects offers pin EnEvt for this type of alarm suppression.

168 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
Alarm Message Texts
8

The following values make sense for EnEvt:

● (False, False, False): The object sends NO BACnet event notification.
● (True, True, True): The object sends BACnet event notification.
Value combinations with True and False for EnEvt should be avoided.

Alarm suppression exceptions

A possible application is to activate alarm suppression during plant maintenance.
Vital alarms must be excepted from alarm suppression.
For Desigo PX exceptions can be defined for hierarchical alarm suppression with
CMN_ALM.
Function block CMN_ALM has pin EnSupEcp. This exception specifies if
exceptions are possible within the alarmable BACnet objects of the group. The
following values are defined for EnSupEcp:
● true: Exceptions for alarm suppression within the group of alarmable BACnet
objects are considered.
● false: Exceptions for alarm suppression within the group of alarmable BACnet
objects are NOT considered.
Each alarmable BACnet object can be exempted from hierarchical alarm
suppression with CMN_ALM. To do this, each alarmable BACnet object has pin
SupEcpt. The following values are defined for SupEcpt:
● true: The object is considered as an exception for alarm suppression.
● false: The object is NOT considered as an exception for alarm suppression.

Combination of multiple alarm suppressions

The above options to suppress alarms can overlap. For an object impacted already
by multiple types of suppression, the following rule applies: One type of alarm
suppression cannot be overridden by another type of alarm suppression.
The following table shows combinations of different alarm suppression types:

AS_STA. CMN_ALM. CMN_ALM. FB.SupEcpt FB.EnEvt Resulting alarm suppression

SupEvt SupEvt EnSupEcp for function block
True • • • • suppressed
• • • • (F, F, F) suppressed
False False • • (T,T,T) not suppressed
False True False • (T,T,T) suppressed
False True True True (T,T,T) not suppressed
False True True False (T,T,T) suppressed

Table 39: Alarm suppression

8.11 Alarm Message Texts

Desigo contains all the alarm texts necessary to help the user maintain an
overview and an understanding of the alarms. These alarm texts can be freely
defined in the engineering tool for each alarm source individually. If this is not done,
text will be generated automatically on the basis of the Technical Designation of
the individual function blocks. In a third category are the predefined alarm texts
used in conjunction with device faults.
Configured alarm The Desigo system supports alarm message texts.
message texts For Desigo PX the message texts for TO_OFFNORMAL, TO_FAULT and
TO_NORMAL alarms are entered as an Array [3] in the BACnet property
[Message_Text]. For Desigo Room Automation the BACnet Property
Event_Message_Texts_Config is used.

169 | 377
Siemens CM110664en_03
2017-09-18
 Alarm Management
8 Alarm Message Texts

For Desigo PX if no alarm message text has been entered for an alarm source, or
if the alarm message text for a given state (for example, TO_FAULT) has been left
blank, an alarm message text will be generated from the existing descriptions.

Project-spec.
Description
Description
Standard

Figure 140: Alarm message texts

Longer messages are divided into segments with forward slashes // so that the
client can display the message over several lines. Each segment may contain a
maximum of 70 characters, with a maximum of three segments separated by // for
any one message.
Non-configured message System alarms and events of the BACnet Device Info Object use text messages
texts which cannot be configured, for example, Battery low.
Predefined, language- System alarms and events of the BACnet Device Info Object use non-configured
dependent text text messages whose contents are language-dependent. These language-
dependent texts are organized into text groups with a predefined server system
text scope, and can be translated. The translated text groups are loaded into the
automation station via BACnet description information.

170 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
Alarm Message Texts
9

9 Calendars and Schedulers

Standard BACnet objects The standard BACnet objects Schedule and Calendar are used for time scheduling
functions in the Desigo system. These objects can be used to configure and
operate time scheduling functions at different operating levels within the system
and via BACnet-compatible operator units from other manufacturers.
The local PXM10 operator unit can also be used to operate the standard BACnet
objects for the connected automation stations and PXC.
Function blocks The time scheduling functions are implemented as function blocks in CFC charts of
automation stations. Each automation station and each switching operation
requires one schedule block. The pins of the function blocks are mapped to
standard BACnet properties.
There are four versions of the schedule block, with an analog, binary or multistate
output or with a variable data type (Boolean, Unsigned, Real or Enumerated). A
schedule block can only contain schedule values of the same data type.
[WeekSchd] [EcptSchd] The scheduler program consists of a weekly schedule [WeekSchd] and an
exception schedule [EcptSchd]. The weekly schedule contains a 24-hour profile for
each day. The exception schedule contains up to 20 profiles, which can be
activated for a date or date range. The date or date range can be defined both in
the schedule itself and in the calendar object.
[Prio] A priority must be assigned to each of the profiles in the schedule. Based on the
priority level assigned, the scheduler program determines from the priority [Prio]
which profile is to be processed. The weekly schedule has the lowest priority.
[EfPrd] The effective period [EfPrd] property defines the time period for which the schedule
is active.
[PrVal] [NxVal] [NxTi] The present value [PrVal], next value [NxVal] and next time [NxTi] are available at
the output of the time schedule. [NxVal] and [NxTi] are used for optimization
purposes.
Commanded objects The time schedule also incorporates a list of references to BACnet objects and
(optionally) a property which is to be controlled by the scheduler program via
BACnet.
[DefVal] The BACnet property Relinquish_Default is the default value [DefVal] for the
present value output [PrVal].

Figure 141: Scheduler with referenced calendar

171 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
9 Schedule

9.1 Schedule
Weekly schedule [WeekSchd]
The weekly schedule [WeekSchd] consists of seven 24-hour profiles, one for each
day of the week. By default, the priority level assigned to the weekly schedule is 16
(the lowest priority). The weekly schedule is active unless there is an exception
schedule.
For system limits, see chapter System Configuration.
24-hour profiles A 24-hour profile is a list of time-and-value pairs. The present value remains at the
[PrVal] output until the processing of the next time-and-value pair causes a new
value to be written to the output.
If there is no schedule entry with a switch time of 00:00 in the daily profile, the
default value determines the resulting Present_Value (=Rule schedule default
value).
If the daily profile encompasses an empty list of schedule entries, the default value
[DefVal] determines the resulting Present_Value (=Rule schedule default value).

Figure 142: Evaluate exception day program, weekly program and Schedule_Default

The evaluation of the exception schedule, weekly schedule, and [DefVal] is as

follows:
Start of the day:
● Exception schedule with switch value at 00:00:
The exception schedule determines the resulting Present_Value if an active
switch value exists at 00:00. The day begins with this exception value (=Rule
switch value exception schedule).
● Empty daily profile:
If the daily profile encompasses an empty list, the default value [DefVal]
determines the resulting Present_Value (=Rule schedule default value).
● Daily profile with switch value at 0:00.
If a schedule entry with switch time 00:00 and active switch value is available in
the daily profile, the switch value determines the resulting Present_Value. The
day begins with the daily profile value (=Rule Switch value daily profile).
Course of the day:

172 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
Schedule
9

● Switch value exception schedule:

If an active switch value exists for a specific time, the exception schedule
determines the resulting Present_Value.
● Daily profile switch value:
If an active switch value from a daily profile exists for a specific time, the daily
profile determines the resulting Present_Value.
● Default value switch value:
If no active switch value from the exception schedule and the daily profile exists
at a specific time of day, the default value determines the resulting
Present_Value.

Exception schedule [EcptSchd]

Exception profiles The exception schedule [EcptSchd] overwrites some or all of the daily switching
operations in a weekly schedule [WeekSchd]. It consists of one or more profiles
(max. 20).
Each profile has a:
● Date
● Specified time
● Priority
● Value for the output signal
The exception schedule may be a time range, including multiple days.
Activating exception Depending on the customer's requirement, the date on which an exception profile
profiles is to be activated can be defined either in the time schedule itself, or in the
standard BACnet object Calendar. In the latter case, the calendar object is linked
to the time schedule via BACnet references.
An exception begins with the first time entry and ends with the last. Each profile
may contain up to 20 switch times.
Setting priorities The switch value of all current profiles is continuously monitored for present
priorities. The priorities determine which switch value is transferred to the [PrVal]
output. The system evaluates every minute if a day or an exception profile should
be active. Each profile of the exception schedule is assigned a priority level from 1
(highest) to 16 (lowest). If several exceptions are valid at the same time, the profile
with the highest priority is processed.
If multiple switch values from different exceptions with the same priority exist at a
specific time, the active switch value of the exception with the lowest array index
(from the exception schedule) determines the exception switch value. The
procedure is the same as the procedure for various priorities. The array index is
used as a sub-priority. Exceptions with different priority levels however, are
independent of each other. That's why it is preferable to assign different priorities to
exceptions defined in the schedule.

173 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
9 Schedule

Figure 143: Exception schedule

Key:

1 An exception profile applies to more than one day. On the second day, the exception profile is
inactive, because another profile with a higher priority is active for the whole day.

2 An exception program without the entry NULL. This exception profile is active for the whole day
and ends automatically in the automation station at 24:00 hours by the NULL entry.

3 Several exceptions with the same priority on the same day, but without overlapping times. The
exception profiles do not interfere with each other as an exception begins with the first time entry
and ends with NULL.

4 Several exception profiles with the same priority on the same day with overlapping times. These
exception profiles affect each other, as several exceptions with the same priority level are active
simultaneously. In such cases, the rule is that if the switch commands are the same, the first
time-entry applies (in this example 13:00 to NULL). With non-identical switch commands, the
latest time-entry applies.

5 Operation in accordance with the weekly schedule.

Output signals
[PrVal] [NxVal] [NxTi] The scheduler sends the following output signals:
● [PrVal]
● [NxVal]
● [NxTi]
The [NxVal] und [NxTi] output signals support the optimum start/stop control of the
plant. When determining [NxVal] and [NxTi] in the time schedule, the current day
and the next two days are taken into account. This results in a time window of 48 to
72 hours, depending on the current time and the next switch entry. If there is no
change in [PrVal] within the time window, then [NxVal] is the same as [PrVal] and
[NxTi] is equivalent to the current date plus 3 days (00:00h).
[DefVal] This default value [DefVal] appears at the [PrVal] output when there is no active
entry in the time schedule, or when the entries are all NIL, or when the time period
is outside the active period.
[EnDef] The [EnDef] variable enables or disables the [DefVal] variable.
The function block variables [DefVal] and [EnDef] are mapped to the
Schedule_Default property. The property Schedule_Default can have the value
[DefVal] or NIL.

174 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
Schedule
9

Variable DefVal Variable EnDef Property Schedule_Default

Value True Value

Don't care False NIL (= Release)

Table 40: DefVal and EnDef function block variables

The NIL value in the Schedule_Default property is the release value for the active
priority of the object controlled by the scheduler. Do not confuse it with the NIL
value in the exception schedule used to prioritize the time entries.

Function blocks for various data types

There are four versions of the schedule block, with an analog, binary or multistate
output or with a variable data type (boolean, unsigned, real or enumerated).

Function block Output Example

BSchd (PX) Binary True/False

ASchd (PX) Analog 20°C

MSchd (PX) Multistate Off, Stage 1, Stage 2, Stage 3

Schd (PX and Desigo Room Boolean / Unsigned / Real /

Automation) Enumerated

Table 41: Function blocks for data types

The switching value is output to [PrVal] and to the objects to be switched

(commanded objects list). A schedule block can only contain switching values of
the same data type (binary or analog or multistate or boolean or unsigned or real or
enumerated). It is therefore not possible to switch two different data types in
sequence.

Figure 144: Schedule function blocks for analog, binary, and multistate

In Desigo PX the CAL (calender) and SCHED (schedule) function blocks can be
created online.

Commanded objects
The schedule can influence other commandable objects, irrespective of whether or
not they are in the same automation station.
The schedule is thus a grouping object and contains a list of group members, in the
form of a list of name references [NamrList]. These group members are the
commanded objects, that is, the objects to be switched. The list can contain up to
five entries.

175 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
9 Schedule

Referencing The referencing of group members is resolved at runtime.

Information flow The grouping and the information flow only go in one direction (forward
referencing).
The information flows inside one automation station or across several automation
stations. The scheduler object recognizes the flow of information and knows where
to send information and what data type is required by the group members. The
information transmitted covers only the present value [PrVal] or the values for the
Optimum Start/Stop functions [PrVal], [NxVal] and [NxTi].
Heartbeat [Hrtbt] In Desigo PX the function block variable Heartbeat [Hrtbt] determines the period
measured in seconds at which the current value (Present_Value) is written.
Enable_Repeat_ In Desigo PX the function block variable Enable_Repeat_Command [EnRptCmd]
Command [EnRptCmd] defines if the switching action is executed if the Present_Value does not change:
● EnRptCmd = TRUE: Switching action is executed if Present_Value does not
change.
● EnRptCmd = FALSE: Switching action is NOT executed if Present_Value does
not change.

Figure 145: Commanded objects

In Desigo S7 commandable objects are not supported. Control of the objects to be

switched occurs via interconnecting the output signals in the CFC.

Effective period [EfPrd]

You can define the period for which the schedule is to be active, for example, you
can configure separate schedules for summer and winter operation. If the current
day is outside the active period, the [PrVal] output is equal to the default value
[DefVal].

Time resolution
The smallest unit in the scheduler program is one minute and in the calendar one
day. The schedule may be dependent on the calendar. In the PX automation
stations, the calendar function block is automatically processed before the
scheduler function block. The superposed cycle for processing the calendar and
scheduler begins at the start of the new minute of the system time.
A PX automation station incorporates an automatic load shedding mechanism. The
result is that a switch command at time x is executed within a time-period defined
by time x + 1 minute.

176 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
Calendar
9

System time
Schedules and calendars are based on the same global time. This ensures that all
automation stations on a site have the same time base.

Interdependency and order of processing

Interdependency of The calendar and schedule function blocks are standalone objects which are
function blocks processed individually. The Schedule function blocks depend on the Calendar
function blocks. The objects to be switched (commanded objects or data flow
output) depend on the Schedule function blocks.
Processing order At start-up, when delta loading and when adjusting the date and time, the order of
processing is a key factor in ensuring that from the first processing cycle on, the
correct output values of a schedule function block are determined and transmitted
to the output. The temporary transmission of incorrect switch values can be
avoided in this way. The order of processing of the individual function blocks is
determined in the CFC Editor (manual/automatic).
The order of processing is:
1. Calendar function blocks
2. Schedule function blocks
3. Any other function blocks, which could be switched by a schedule function
block

Figure 146: Order of processing and interdependency of function blocks

9.2 Calendar
Function block Calendar The calendar object is a function block from the firmware library. It contains a list of
dates [DateList] with, for example, a date or a date range.
The date list [DateList] uses Boolean logic to control the calendar outputs. [PrVal]
activates an exception profile if the calendar object is referenced by a schedule
object. The outputs tomorrow [Tmw] and day after tomorrow [DayAfTmw] support
the optimum start/stop control of the plant.
Standard BACnet object The SCHED (schedule) and CAL (calender) function blocks in the firmware library
Calendar correspond to the SCHED and CAL standard BACnet objects. Standard BACnet
object can be operated via the BACnet clients.
The calendar and schedule can be linked at the BACnet level by references. There
is no data flow link between the calendar and schedule function blocks in the CFC
chart.

9.3 Wildcards
A wildcard character (*) generates a repetition and is an abbreviated way of listing
individual entries. For example, writing 3.* is a short way of representing 3.1., 3.2.,
3.3., 3.4., 3.5., etc.
All data structures of the scheduler or calendar objects support dates with
wildcards. Date ranges and time specifications do not support wildcards. Invalid
weekdays are ignored.

177 | 377
Siemens CM110664en_03
2017-09-18
 Calendars and Schedulers
9 Alarm Messages

Date entries with The following table shows examples of date entries containing wildcards:
wildcards
Date Meaning
23.April.2001 /Monday 23.April.2001, Monday

23.April.2001 /Tuesday Never, since 23.April 2001 is a Monday

23.April.2001 /* 23.April.2001

23.April.* /Monday Each April 23rd, each year if the weekday is a Monday

*.April.2001 /* Every day in April 2001

*.April.* /Tuesday Each day in April of each year if the weekday is a Tuesday

31.*.* /* Each January 31, March 31, May 31, … of each year
or each February 28/ 29, April 30,... of each year

Table 42: Date with wildcards

If a date contains a wildcard in the month or year, the last day of the month is used
for the day, if the value of the day is greater than the maximum number of days in
the month.

Week and day with The following table shows an example of entering a week and day (WeekNDay)
wildcards using wildcards. During the evaluation, a wildcard is replaced by the corresponding
value of the current date. If the WeekNDay generated in this way is equivalent to
the current date, this is an exception day.

Day of the week Meaning

January/2/Monday Monday in the second week of January

*/1/Tuesday Every first Tuesday of a month

February/*/Wednesday Every Wednesday in February

Table 43: Week and day with wildcards

9.4 Alarm Messages

The scheduler object cannot directly generate alarms when, for example, a
commanded object cannot be found.
The alarm function (extended, basic or simple) which defines the alarm behavior of
the object in the system, and the alarm class do not exist because of standard
compliance.
The fault alarming of the schedule object must therefore be implemented as an
additional binary value function block. That's why the function block is linked with
the Dstb (Disturbed) pin of the scheduler and parameterized accordingly. The
additional binary value function block is optional and only required, when a fault
alarming of the scheduler is wanted, for example, for scheduling external objects.

178 | 377
Siemens CM110664en_03
2017-09-18
 Trending
Trend Functions
10

10 Trending
Trend data provide important information about the processes in a building
automation and control system. For example:
● Monitoring of the control system for optimization purposes
● Logging the room temperature in association with the set temperature
● Logging of temperature and humidity trends for the pharmaceutical industry
Offline/Online trend There are two types of trend data:
● Offline trend:
The recorded trend data are saved in the automation station and uploaded to
Desigo CC periodically or as needed. The data can be analyzed in Desigo CC.
A connection is needed only during the data upload. Trend objects are needed
in the automation station.
Offline trend is mostly used for long term data logging.
● Online trend:
Arbitrary data points can be saved as online trends.
A permanent connection is needed. No trend objects are needed in the
automation station.
Online trend is mostly used for temporary data logging.
Trend Log Objects The trend data is saved in the buffer of the Trend Log and Trend Log Multiple
objects in the automation station.
The Trend Log object can only record one value of a data point. The Trend Log
Multiple object can record up to six different values of a data point.
The Trend Log object cannot be set up online, but must be set up in advance,
offline in the application. A Technical Designation (TD) determines (BACnet
reference) which object is to be logged. This presupposes that the referenced
object is visible via BACnet (not No Element). The reference and the parameters
can be defined and modified online or offline.
When the number of trend log entries reaches a definable threshold (Notification
Threshold [NotifThd]), the Trend Log object generates an event. The Trend Log
object sends out an alarm which is defined in a notification class specified for
Trend Log.
The trend log data acquired can only be read, and if necessary, archived, with a
BACnet Client configured for this purpose, for example, Desigo CC. The status of a
Trend Log object is not affected by reading out trend log data. It is not possible to
reload sampled data into Xworks Plus (XWP).
A BACnet client cannot reserve a Trend Log object. Every BACnet client can
access the Trend Log object. In the case of access or modifications undertaken by
several clients, the rule is that the most recent one always takes priority.

10.1 Trend Functions

The trend log object supports the following functions.
Continuous Run The trend data is saved continuously (ring buffer). When the available memory
area is full, the oldest data is overwritten by new data. You can define the
Continuous Run function with the parameter Stop when full.

179 | 377
Siemens CM110664en_03
2017-09-18
 Trending
10 Trend Functions

Figure 147: Continuous run

Single Run The trend data is saved until the available memory area is full. You can define the
buffer size [BufSize] within the range 2 to 5,000 entries. You can define the Single
Run function with the parameter Stop when full.

Figure 148: Single run

Logging Type The parameter Logging Type [LogTyp] defines the logging type. The values are:
● POLLED: Periodic Sampling
● COV: COV Sampling
● TRIGGERED: Triggered Sampling
By setting the parameters accordingly, you can define combinations of Continuous
Run / Single Run and Periodic Sampling / COV Sampling / Triggered Sampling.
Periodic Sampling In Periodic Sampling data is acquired by sampling and storing values in a regular
cycle. Periodic Sampling is supported by the trend log object and the trend log
multiple object.

Figure 149: Periodic sampling

COV Sampling In COV Sampling data is stored based on a change of value (COV) of the
referenced parameter. A COV subscription can be applied to all supported data
types (analog, Boolean and multistate). The amount of change required to initiate a
COV is set as a parameter in the object to be referenced. COV Sampling is
supported only by the Trendlog object.

180 | 377
Siemens CM110664en_03
2017-09-18
 Trending
Editing Parameters
10

Figure 150: COV sampling

Triggered Sampling In Triggered Sampling an application (for example, via data flow interconnection)
determines when values are acquired/logged and saved. Triggered Sampling is
supported by the Trendlog object and the Trendlog Multiple object.

Figure 151: Triggered sampling

10.2 Editing Parameters

Many of the parameters in the trend log object are definable only if:
● Enable for logging (Enable logging) [EnLog] is inactive
● The log buffer is empty (Record count = 1)
In this state, the following variables can be modified:
– Start time [TiStt] and stop time [TiStp]
– Interval [Ivl]
– Buffer size [BufSize]
– Record count [RecCnt] (can only be overwritten with 0: delete log buffer)
– Notification threshold [NotifThd]
– Input/Output address [IOAddr] (if an unavailable BACnet address is entered,
an alarm is initiated)
● [EnLog] is inactive or active
● The log buffer is not empty (log count > 1)
In this state, only the following parameters can be configured:
– Start time [TiStt] and stop time [TiStp]
– Record count [RecCnt] (can only be overwritten with 0: delete log buffer)
– Notification threshold [NotifThd]
The record count [RecCnt] can only be overwritten with 0. This deletes all the log
data. After a write operation of 0, there is one entry showing the log status (record
count = 1).
It is not possible to reload sampled data into the CFC Editor.

181 | 377
Siemens CM110664en_03
2017-09-18
 Trending
10 Processing Trend Data in Desigo CC

With a full loading procedure, any previously sampled data will be lost. With
differential or delta loading the data will not be lost.
The PXM20 stores modified parameters in its internal memory cache. To display
the data actually written, you must exit from the trend log object and re-select it.

10.3 Processing Trend Data in Desigo CC

The Trends application in Desigo CC lets you create and display online trends and
offline trends. You can save, query, delete, edit and save trend data in Trend
Views.
You can display the trend data in the Trend Viewer any time, even if Desigo CC is
not connected to the site (no real-time data is available).
For more information, see Desigo CC User Guide (A6V10415471).

182 | 377
Siemens CM110664en_03
2017-09-18
 Reports
11

11 Reports
You can create reports in Desigo CC about the functioning of the building
automation and control system.
You can configure:
● The elements in the report (such as tables, plots, logos, form controls, text and
so on), and their layout.
● Filters (such as name, condition, time, and/or row) to populate the elements of
the report with information. For example, if you want a report on a room's
activity data over the past month, you could define a name filter and a time filter
in an activities table.
● The formatting of the report elements and the page layout.
● The output type (PDF or XLS) and the output destination (file, email, or printer).
You can save your report definition for later use, run it, or schedule the report to be
run at a specified time.
You can use reports as a reference or as a troubleshooting mechanism. Reports
are helpful during system operation.
For example, you can:
● View a mixed report containing:
– A table displaying details of all active events for a floor of a building
– A table displaying a history report of events
– A trends plot displaying the temperature variations gathered from
temperature sensors
● Export trend data for statistical analysis to:
– An XLS file
– A CSV file (according to the EMC requirement)
● Schedule production of a report using macros and reactions
● Send a report by email, print it or save it as a PDF
You can export and import report definitions and logos.
You can also create and configure reports for operating procedures. These reports
are used during assisted treatment to enter information about how the alarm or
event is being handled.

183 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
12 Data Categories

12 Data Storage
Large volumes of data are created in the Desigo system during engineering,
commissioning and plant operation. The data is processed, saved, and archived as
needed in accordance with type, generation, and meaning in the various system
components.

12.1 Data Categories

The application logic (control functions) and the required setting and configuration
data are processed during engineering and loaded in the corresponding system
products, such as Desigo CC or an automation station during commissioning.
This data is arranged according to two criteria:
● Data category
● Data ownership
Data categories The following table shows a common method of classifying data in building
automation and control systems.

Data category Description Related terms

Program elements Software components which perform a predefined task Function blocks, functions, program
and have a known interface. blocks, compounds, solutions

Setting parameters Values that affect the program elements. Setpoints, default values, limit values,
address settings

Configuration parameters Data in the form of defined constants, or data that Description data, templates, profile,
influences the appearance or operability of the plant. metadata

Process data Physical process variables of the plant during operation. Measured values, state variables,
History or saved process data are plant data. calculated values

Table 44: Data categories

Data ownership Data ownership is based on the practical allocation of data to its owner. The owner,
usually an organizational entity, a person, or a group of people, checks the data
and is responsible for its scope and content. Data ownership shows in which
Desigo system product the data is located and which tools are available for its
management. Data ownership is divided in four groups.
The following table shows the four data ownership groups.

Data ownership Description Owner User

Program data Software of a Desigo system product with Research & Development Project/Library engineer
basic data blocks. (R&D) (HQ)

Libraries Collection of predefined, specific, and tested Library manager (HQ/RC) Project/Library engineer
program elements.
Libraries can be copied and customized.

Project data All data for the customer project or customer Contractor Plant operator
plant. Project engineer

Plant data Data from the customer plant saved Plant operator Customer
permanently following commissioning.

Table 45: Data ownership

12.2 Program Data

The executable software of a Desigo component is composed of programs. There
are system and product components.

184 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
Libraries
12

System components System components are:

● System blocks for controlling the plant
● System interfaces which are implemented in every component and which
control the data traffic between the components
Product components Product components are the local subroutines responsible for the internal
consistency of setup, startup, shutdown, navigation and display, etc. among the
individual components.
Parameterization There are two parameter types:
● Setting parameters: System and product components have predefined default
settings. These values are application-independent, but always lie within the
system limits.
● Configuration parameters: The system and product components have a basic
configuration. The basic configuration of certain blocks is not complete and
must be supplemented during engineering with, for example, addresses of the
I/O blocks.
The library or project engineers can adapt the setting and configuration parameters
to the plant or project conditions.

12.3 Libraries
Libraries are needed during engineering. You can create loadable applications
using libraries. Library elements are compiled from system basic components. For
example, the Desigo CC graphic library contains default graphics for visualizing
plants during engineering.
You can copy and customize or extend libraries. Every engineering level has a
library. Libraries can cover many combinations.
DXR2 automation stations are delivered with preloaded applications and only need
to be configured.
There are three library types:
● HQ libraries are tested, well documented and delivered with the system version.
Every new Desigo version contains new libraries.
● RC libraries are tested, well documented and contain country-specific
characteristics. They are optional, independent or an addendum to the HQ
library. Not all RCs offer comprehensive libraries.
● Project-specific libraries are not tested and documented.
Application libraries Application libraries contain plant-specific functions (heating, cooling, control of
electrical equipment, etc.) or templates for subsystem bindings. You can set up
and manage libraries with the Xworks Plus (XWP) and Automation Building Tool
(ABT) engineering tools.
PX libraries The functional units of the PX application libraries are defined by compounds. You
can copy, change and extend the compounds of the PX library.
Application libraries for PX and Desigo S7 are designed using the same application
principles and are provided via Xworks Plus during project engineering.
PXC3/DXR2 libraries The functional units of the PXC3/DXR2 application libraries are defined by
application functions. You can copy, change and extend the application functions
of the PXC3/DXR2 library.
Parameterization The library elements have plant-specific or function-specific setting and
configuration parameters:
● Setting parameters: The default values are defined by the application and
usually do not require adjustment.
● Configuration parameters: The default values can be adapted as needed.

185 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
12 Project Data

Graphics libraries Graphics libraries contain graphics that represent the operating elements of the
firmware and application libraries. The graphics are used in Desigo CC to visualize
and operate plants. The elements of the graphics libraries depend on the elements
of the application libraries. Any changes to the application libraries must therefore
also be made to the graphics libraries.
The graphics libraries for Desigo PX, PXC3/DXR2, and Desigo S7 are identical.

12.4 Project Data

There are three types of project data:
● Project data that is saved locally and then loaded into the system.
● Data on the Branch Office Server (BOS).
● Data that is loaded into the system with ABT Site and is not saved locally.
Project data is created during project engineering, when you create a project
program using library components. Project programs define the sequence in which
function blocks (programming elements) are processed, and what interconnections
are used between blocks.
The library components are selected:
● In Xworks Plus (XWP) in the Solution Generator (recommended workflow for
Desigo PX)
● In the CFC Editor from the compound and firmware libraries for Desigo PX and
Desigo S7
● In Xworks Plus and Automation Building Tool (ABT) from the Desigo Room
Automation automation stations
Desigo Room Automation Desigo Room Automation room applications are configured in ABT by selecting the
room applications required functions or model rooms.

RXC/RXB room RXC/RXB room applications are configured in XWP by selecting the required
applications functions or sample rooms. Data import in XWP to address the room devices is
carried out in different tools, depending on the RX device.

For device... From tool...

RXC RXT10

RXB and KNX/EIB third-party devices PX KNX tool and ETS

LonWorks third-party devices Standard LON tools

Table 46: Tools and devices for importing data

PXC3 room applications PXC3 room applications are programmed and configured in XWP/ABT by selecting
and configuring the applications required for the rooms and room segments
(application functions).
TX-I/O modules The configuration of TX-I/O modules depends on the PX automation station:
● PX automation station with island bus connection: The XWP/ABT tools transfer
the configuration data (IOC) to the target automation station PX/PXC3.
● PX automation station with P-bus connection: The configuration data (IOMD)
from XWP is loaded into the I/O modules via the TX-I/O tool.
The IOC/IOMD configuration data is saved as project data.
Back up and restore Project data is stored offline in XWP/ABT and Desigo S7 engineering tools. The
backup and restore function creates a backup of the data and, in case of data loss,
restores the data to the PX automation station.

186 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
Plant Data
12

Back up your data regularly to protect yourself against data loss.

The backup copy contains all necessary data of a PX automation station to ensure
the automation station is fully functional after data restoration. You can back up
and restore data on third-party automation stations. You can save engineering data
on PX compact automation stations.
Backup Data from the PX automation stations are saved as a backup copy on Desigo CC.
The data is exported and saved as BACnet data.
To back up the data:
● The PX automation station must be connected and available (online).
● The PX automation station must support backup and restore.
● The building automation and control system must work smoothly.
Restore You can restore data backed up on Desigo CC to the corresponding PX
automation stations. The restored PX automation station automatically restarts
after data restoration.

12.5 Plant Data

Plant data is process data from the operation of a customer plant, that is
permanently saved from the time of commissioning. Process data represents
process variables in a building. The data is continuously changed by the
environment, automation station and, in the event of physical outputs, the operator.
Most process data is volatile. Few process data, such as adaptive control
parameters and runtime totalization counts, remains available following a restart or
power failure of the automation station. Process data can be archived as plant data.

12.6 Data Transfer Processes

Project data is transferred from the tools to the devices or other consumers online
and offline via the system interface. PX automation stations are configured offline
and then the data is downloaded onto the automation station. Desigo Room
Automation automation stations (PXC3 and DXR2) can be engineered. DXR2
automation stations also have preloaded applications and only need to be
configured.
Transfer operations There are four transfer operations for data synchronization:
● Offline generation
● Online loading
● Online readback
● Offline import
Data transfer to PX You can load a new program on a PX automation station while the old program is
automation stations still running. The operation of the automation station is not interrupted. Process
values remain intact. If you load a firmware on the automation station, you must
restart the automation station.
Data transfer to Desigo If you load a new program on a Desigo Room Automation automation station, you
Room Automation must restart the automation station. The operation of the automation station is
automation stations interrupted. Process values do not remain intact. If you load a firmware on the
automation station, you must restart the automation station.
There are four loading units for Desigo Room Automation automation stations:
● Load program
● Load parameters (full download for DXR automation stations)

187 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
12 Data Transfer Processes

● Load configuration (settings on the automation station)

● Load firmware (programs, parameters and configuration are not lost)

Offline generation
Full code generation Full code generation:
● Checks the overall application consistency (limits, identifiers)
● Converts the application into loadable units
● Generates the appropriate description data for configuration

You must compile the code to get the required performance. You cannot engineer
a compiled program.

Delta generation Delta generation (converts only the modifications):

● Improves performance
● Is faster than full code generation

Online loading
Full download The full download transfers all loadable units into the automation station.
Delta download The delta download:
● Copies additional blocks into the automation station
● Deletes blocks which are no longer valid
● Updates parameter settings
The delta download is faster than a full download. You do not need to interrupt the
operation of the automation station.
The delta download helps prevent unintentional parameter changes. Online
changed process data and settings parameters are protected against unintentional
overwriting, provided the process data was not changed in the tool.
Download options You can define what happens in the automation station before and after the
download. You can define if:
● Parameters are read back before the download
● The program starts and/or the I/O bus is turned on after the download

Online readback
During readback of non-volatile process values and parameter settings the data in
the automation station is aligned with the project data in the tool.
Readback comprises two steps:
1. Current parameter settings and non-volatile process values in the PX/PXC3
automation station are read from the automation station and copied to the data
storage.
2. The values are updated in the CFC data storage or PXC3 program and
configuration data storage.
The following data can be read back from PX/PXC3 to the project data storage in
the XWP/ABT tools:
● Setting parameters changed in the PX/PXC3 automation station
● Changed, non-volatile process values or configuration data
Advantages Reading back data has the following advantages:
● Outdated data in XWP/ABT is overwritten by current data and thus is available
again for reloading programs in the PX/PXC3 automation station.
● During online changes of background variables (for example, calendar), data
between CFC and XWP/ABT and the automation station is retained.

188 | 377
Siemens CM110664en_03
2017-09-18
 Data Storage
Texts
12

● Current setting parameters and non-volatile process values (for example,

operating hours) are saved.
● The newest configuration is saved offline and can be used for, for example,
reports.
Runtime data cannot be read back. Only offline data can be read back. Only
objects (not individual properties) can be read back. If a property is changed, the
entire object (for example, data point), that is, the last change on the object is read
back. The last change per object is always valid.
Workflows for changes There are two workflows for changes:
Workflow 1 (ideal workflow):
1. Perform readback before the changes
2. Perform changes offline
3. Download
Workflow 2:
1. Perform changes offline
2. Perform readback
3. Compile
4. Download

Offline import
You can import configuration and description data for the plant into Desigo CC.
This is the same as the data downloaded to the automation station.

12.7 Texts
If you work with HQ or RC libraries, the texts are from a text database. These texts
can be automatically translated, because they have a unique ID. Project-specific
texts that are not from the text database cannot be automatically translated.

189 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

13 Network Architecture
The Desigo system is divided into three network levels:
● Management Level Network (MLN)
● Automation Level Network (ALN)
● Field Level Network (FLN)
BACnet Internetwork

BACnet Network #100

Management RemoteArea: Zürich

Desigo CC 1 Desigo CC 2
Level
Network

IP segment 1 IP segment 2 IP segment 3 IP segment 4

BACnet Network #1 BACnet Network #2 BACnet Network #3 BACnet Network #4

PXG3.W100 Desigo CC 3
Automation
Level IP segment 5 IP segment 6 IP segment 7 LONWORKS segment BBMD
Network

PXC00-U PXC #1 PXC #2 PXG3.M/L PXC #1 PXC #1 PXC #2 PXC #1 PXC #2

IP Segment 8

Field Level
IP segment 9

Network
PXC3/DXR2 #1 PXC3/DXR2 #2

PXC3/DXR2 #3, 4, 5, 6, 7, ... PXC3/DXR2 #1, 2, 3, ...

KNX segment (FLN)

RXB #1 RXB #2

Figure 152: Desigo architecture

This classification is based on the functions performed at a given level, rather than
on the communications protocol or medium. The MLN and ALN use the BACnet
protocol. The transport protocol (Data Link Layer) is LonTalk or IP. The FLN uses
LonWorks, KNX and MS/TP technology.

13.1 BACnet Architecture (MLN & ALN)

Structuring
BACnet defines the following structuring of the network topology:

190 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

Figure 153: BACnet internetwork

Key:

B Bridge, for example, IP router, LonWorks router

R Repeater, for example, LonWorks physical repeater

RT Router, for example, PXG3

½RT Half router, for example, PX..-T

Internetwork In BACnet, the BACnet internetwork is defined as the largest BACnet unit. It
consists of one or more BACnet networks. Only one active connection can exist
between any two BACnet devices in a BACnet internetwork.
All bus subscribers from the ALN and MLN, including BACnet third-party devices,
are part of the BACnet internetwork. The devices in the FLN are part of the Desigo
system but not part of the BACnet internetwork, because they do not communicate
via BACnet.
Network Desigo devices use LonTalk (BACnet/LonTalk), IP (BACnet/IP) or MS/TP (BACnet
MS/TP) as their transport protocol. If different transport protocols are used,
different physical networks are created, which must be connected to the PXG3
router. BACnet routers connect networks on the BACnet network layer and
transmit messages via the network number.
If the transport protocol changes, the BACnet network also changes. For example,
BACnet devices that use LonTalk as their transport protocol are always located in
a different network than devices that use IP as their transport protocol. This also
applies to PTP connections.
Desigo devices use LonTalk (BACnet/LonTalk) or IP (BACnet/IP) as their transport
protocol and MS/TP (BACnet MS/TP) to integrate third-party devices. If different
transport protocols are used, different BACnet networks are automatically created,
which must be connected to the PXG3 BACnet router. Multiple BACnet
internetworks can be created on an IP segment by using different UDP port
numbers.

191 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

Desigo establishes PTP connections only between operator units and a network.
Operator units duplicate a virtual network since PTP connections demand a
network at both ends.
Desigo CC does not use PTP.
Segment Large networks are structured, that is, divided into several (logical) network
segments for reasons of security, performance, size and (limited) address range of
network devices. The segments must then be connected to routers of the
corresponding transport protocol (for example, LonWorks router, IP router).
In most cases it is not necessary to divide a BACnet/LonTalk network into several
LonWorks segments (ALN). However, if it does prove necessary, it is not possible
to use a LonWorks router, because this limits the length of the data packets. An L-
switch (Loytec) can be used as a router on the ALN.
BACnet MS/TP networks cannot be segmented, because there are no associated
routers.
With BACnet/IP some IP segments may be connected by IP routers. Since the IP
router prevents broadcasting, the connection must be activated with the BACnet
Broadcast Management Device (BBMD).
Physical segment Physically, (cable) networks cannot be expanded as desired. Depending on
electrical transmission properties and the data link layer based on it, repeaters
must be added at specific cable lengths to amplify the signal. This divides the
network into multiple, physical segments. A repeater does not impact the
transmission protocol; it merely electrically connects two physical networks.
Dividing up the network into several physical segments may be necessary in
LonWorks technology.
See RXC Installation Guide (CA110334).
The physical segments are connected with physical or logical repeaters. Due to the
limited buffer size of logical repeaters, only physical repeaters may be used on the
ALN. Only one physical repeater may be located between any two nodes.
MS/TP is transmitted on a two-wire cable as per EIA-485/RS-485*. The length of
the physical segment can be max. 1,200 m and can be extended with EIA-485
repeaters.
*TIA standard (Telecommunications Industry Association): TIA-485-A Electrical
Characteristics of Generators and Receivers for Use in Balanced Digital Multipoint
Systems (ANSI/TIA/EIA-485-A-98) (R2003)
Desigo site A site is an independent and self-contained logical entity within the building
automation and control system. This type of structuring is not defined by BACnet,
and is therefore largely independent of the BACnet network topology. The BACnet
devices bound to a site can therefore be placed anywhere within a BACnet
internetwork. A site cannot extend across a PTP connection. Communication
occurs only within the site, but data can be exchanged with any device on the
BACnet internetwork.
Only automation stations (PXC/PXC3) and LonWorks system controllers
(PXC...D+PXX-L11/12)) are assigned to the sites, by special structuring of the
Device ID and Device Name. SX Open and Desigo S7 cannot be assigned to a site.
These products are considered third-party devices for the purposes of a site.

Protocol layer model

Desigo supports:
● BACnet/IP
● BACnet/LonTalk (LonWorks technology)
● BACnet/PTP
● BACnet MS/TP
● BACnet/IPv6 (only via PXG3 BACnet router)

192 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

ISO/OSI Layers BACnet Layers

Application Layer Application Layer

Network Layer Network Layer

VMAC
BVLL BZLL
BVLLv6
ISO8802-2 Type 1 LonTalk
MS/TP PTP
Data Link Layer UDP/IP UDP/IPv6 (IEEE802.2) (EIA 709.1)
ZigBee
ISO8802-2 Type 1
(IEEE802.2)
Ethernet Ethernet
Physical Layer IEEE TP/FT 10
ISO8802-3 ISO8802-3 ARCNET EIA-485 EIA-232
802.15.4 (EIA-709.1)
(IEEE802.3) (IEEE802.3)

Supported in Desigo Only via PXG3 router

Figure 154: BACnet protocol layer model

BACnet directly over ethernet, ZigBee or ARCnet is not supported.

Application layer
The BACnet application layer defines services, objects and their characteristics.
From the network viewpoint, the Device object is important. The object ID and the
object name must be unique within the BACnet internetwork.

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 155: Application layer

Device ID The Device ID is the object ID of the BACnet device object.

The device ID is divided into the following categories:

Category Device ID Description

Object type Object instance

2 bit 10 bit 10 bit

Unconfigured DEVICE 00 0000000000 0000000000 All unconfigured devices

Class A DEVICE 00 xxxxxxxxxx xxxxxxxxxx (1...1048576) Third-party devices

Class B1 DEVICE 01 Device number Stationary operator units

(Desigo CC)
0000000000 xxxxxxxxxx
(1...999)

Class B2 DEVICE 01 Device number Mobile operator units / tools

0000000001 xxxxxxxxxx
(1...999)

Class B3 DEVICE 01 Device number System devices (BACnet

193 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

Category Device ID Description

0000000010 xxxxxxxxxx router)
(1...999)

Class C DEVICE 10 Site number Device number Automation stations (PXC…)

xxxxxxxxxx xxxxxxxxxx System controllers (PXC…)

(1...999) (1...999)

Class D DEVICE 11 xxxxxxxxxx xxxxxxxxxx (1...1048576) Reserved

Table 47: Desigo definitions

Device name The device name is the object name of the BACnet device object.
Guidelines Different rules for object names apply for configuring TD (Technical Designation),
UD (User Designation), or FD (Free Designation):
● The TD is generated from predefined partial names, separated by an
apostrophe ('), that show the technical hierarchy with plant, partial plant, and
component. The TD is supplemented by site name and pin name.
● The names may consist of upper- and lowercase letters and numbers 0 to 9.
The site name is separated by a colon (:) and the pin name by a period (.). The
maximum total length is 30 characters.
● The UD is formed similar to the TD based on partial names. However, users
determine the partial names, structure, and separators. The names consist of
upper- and lowercase letters, numbers 0 to 9, and separators, such as _-;=’,
etc. The maximum total length (including site name and pin name) is 80
characters.
● The FD is a freely assigned name consisting of letters, numbers and a few
special characters, limited within the system only by uniqueness and length.
The maximum total length is 80 characters, ten of which, plus one separator,
are reserved for the site name.

Category Device name Description

Unconfigured ““ Empty string for unconfigured devices

Class A No rules

Class B1 Meaningful text for the user (this text is used as a reference
for the alarm recipient)

Class B2 Model name + device ID Model name + “ “ + 8 character device ID (hexadecimal). The
device name for temporary devices is generated
automatically.

Class B3 Max. 25 characters

Class C Site name + automation station name Site name + “:“ + automation station name

Table 48: Desigo definitions

Category Site number Device number Device ID Site name Device name Device name
A – 1 0x02000001 – Third-party 1 Third-party 1

B1 – 1 0x02100001 – Desigo CC 1 Desigo CC 1

B2 – 15 0x02100401 – – PXM20TMP0210040f

C 1 1 0x02200401 Cham PXC #1 Cham:PXC #1

C 1 2 0x02200402 Cham PXC #2 Cham:PXC #2

194 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

Category Site number Device number Device ID Site name Device name Device name
C 1 3 0x02200403 Cham PXC... #1 Cham:PXC... #1

C 2 1 0x02200801 Zug PXC #1 Zug:PXC #1

C 2 2 0x02200802 Zug PXC... #1 Zug:PXC... #1

C 3 1 0x02200C02 Baar PXC #1 Baar:PXC #1

Table 49: Examples from the topology at the beginning of the chapter

BACnet device The BACnet device parameters are written to the devices during commissioning.
parameters These parameters include the following values:

Designation Description
Max APDU Length Accepted Maximum length of application message (Application Protocol Data Unit) supported for this
device. The length depends on the transport medium used, and the capacity of the device
buffer. The length of the APDU must always be less than the length of the smallest NPDU
(Network Protocol Data Unit) between the different bus subscribers.

Beispiel There are two IP networks linked by a PTP connection. The two IP bus subscribers could have
a maximum APDU length of 1476 octets. However, since the maximum NPDU length of the
PTP connection is 500 octets, the maximum APDU length of both devices must be set to 480
octets.

Values for LonTalk Range: 50/128/206 Octets

Default value: 206 Octets

Values for MS/TP Range: 50/128/206/480 Octets

Default value: 480 Octets

Values for IP (equal for IPv6) Range: 50/128/206/480/1024/1476 Octets

Default value: 1476 Octets

APDU Segment Timeout
Timeout of an APDU segment (= part of an APDU). This value must be identical throughout the
internetwork.

Range: 1000...5000 ms

Default value: 2000 ms

APDU Timeout Timeout for an acknowledged message. This value must be identical throughout the
internetwork.

Range: 1000...5000 ms

Default value: 3000 ms

Number of APDU Retries Number of retries in the event of an APDU or APDU segment timeout. This value must be
identical throughout the internetwork.

Range: 1...5

Default value: 3

Table 50: Desigo definitions

Window size To transfer large data packs, BACnet uses the windowing algorithm. Windowing
means that instead of acknowledging individual segments separately, the
acknowledgement applies to a specific number of segments, referred to as a
window.
Definitions for Desigo The window size is permanently set to four for all Desigo devices, so that for
segmented messages, only every fourth segment is acknowledged.

Network layer
The most important information in the network layer is the network number of the
BACnet network.

195 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 156: Network layer

Network number The network number is the unique identification of the BACnet network. There are
stationary and temporary networks:
● Stationary networks are defined during commissioning and then remain
unchanged.
● Temporary networks are created when a tool (for example, XWP/ABT) dials
into a network via PTP.

Range/Value Description
0 Reserved for applications with only one BACnet network in a BACnet internetwork, that is, where there are
no BACnet routers.

1...65280 Network number for stationary BACnet networks. You can select any network number in this range.
We recommend that you form categories, for example:

BACnet/LonTalk networks via (half)router: 1...99

BACnet/IP network (common network): 100

Desigo CC or XWP/ABT connected via BACnet/PTP : 1000...1099

65281...65534 Reserved for temporary BACnet networks. Not yet used in Desigo.

Table 51: Desigo definitions

Router parameters The router parameters are written to the BACnet router during commissioning. The
following information is required for each port (logical connection to network):

Designation Description
Network Number Network number of the directly connected network.

Max NPDU Length Max. message length supported in this network. This value depends on the transport medium
used.

Values for LonTalk: Range: 50/228

Default: 228

Values for MS/TP: Range: 50/228/501

Default: 501

Value for IP (equal for IPv6): Range: 50/228/501/1497

Default: 1497

Values for PTP: Range: 50/228/501

Default: 228 for LonTalk

/ 501 for Ethernet/IP

Table 52: Desigo definitions

Hop counter Every BACnet that is routed to another BACnet network has a hop counter. The
counter reading is reduced by one with each pass of the BACnet router. When the
counter reads 0, the message will not be routed further. This prevents continuously
circulating messages.

196 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

Definitions for Desigo For Desigo the hop counter is initialized with a fixed value of 5. This means that a
message can pass through a maximum of four BACnet routers.

LonTalk data link layer

The LonTalk data link layer is supported by the PX automation station and by the
operator units and tools.
LonTalk ist he communications protocol for LonWorks technology.

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 157: LonTalk data link layer

Addressing under Physical address, neuron ID: The Neuron ID is the physical address for a
LonWorks technology LonWorks device. It is a unique 48-bit (6 byte) identifier which is assigned to each
neuron chip during manufacturing.
Logical address: The logical LonTalk address is written to the LonWorks node
during commissioning on the network side.

Figure 158: Logical address structure

Domain ID: The domain ID is the highest unit in the LonWorks addressing system.
Data can only be exchanged within a domain. A gateway is required for inter-
domain communication. The domain ID can be 0, 1, 3 or 6 octets in length. A
domain can consist of up to 255 subnets.
Subnet ID: The subnet is a logical collection of up to 127 nodes within a domain.
The bus traffic within a subnet can be kept local by using BACnet routers. Subnets
must never be defined across a router.
Node ID: Unique identifier within the subnet. Each node can be addressed uniquely
within a domain by the subnet ID and the node ID.
Group ID: The group address is a type of addressing. The group address is not
used in BACnet.
On the ALN, the following rules apply to Desigo:

Designation Values/Range Description

Domain ID 0x49h (73) The default length of the domain ID is one octet and the default value is
0x49h (73).

Subnet ID 1…255 The subnet ID is a consecutive number that starts with one. The subnet ID
is incremented by one when a subnet is full (no free node IDs).

Node ID 1…100 This range is for automation stations (PXC), system controllers (PXC...)
and system devices (BACnet routers).

101…120 Operator units and Desigo CC are assigned to this range.

121…127 Temporary operator units and tools (XWP/ABT) look for a free node ID in
this range.

197 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

Table 53: Desigo definitions

IP data link layer

An additional layer, the BACnet Virtual Link Layer (BVLL), is used for BACnet over
IP. This layer transmits broadcast messages across IP routers.

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 159: IP data link layer

Below the BVLL, BACnet relies on UDP (User Datagram Protocol). Unlike TCP
(Transmission Control Protocol), UDP supports broadcast messages. The
connection monitoring (carried out by TCP) is resolved in the Application Layer.
All media, such as ethernet, are available if supported by IP as physical layers.
For detailed information on the IPv6 data link layer, see Ethernet, TCP/IP, MS/TP
and BACnet basics (CM110666).
IP addresses The IP address of stationary and temporary operator units can be set automatically
via DHCP (Dynamic Host Configuration Protocol) provided that there is a DHCP
server in the network. The use of DHCP is not recommended with automation
stations and BACnet routers. DHCPv6 is currently not supported for IPv6.
DHCP is not allowed for devices using integrated BBMD functionality.
The IP addresses must be agreed upon with the IT department.
RFC1918 defines three specific address areas for private networks. IP addresses
within these ranges are not routed:
10.0.0.0 - 10.255.255.255 Subnet mask: 255.0.0.0
172.16.0.0 - 172.31.255.255 Subnet mask: 255.240.0.0
192.168.0.0 - 192.168.255.255 Subnet mask: 255.255.0.0
For IPv6, IP addresses and private address ranges are defined differently. See
Ethernet, TCP/IP, MS/TP and BACnet basics (CM110666).
IP address: Host address of the network subscriber.
Subnet mask: Subnet mask of the IP segment in which the device is located. This
value must be aligned with the other IP devices.
The subnet mask is required for the identification of broadcast messages and for
communication across IP segments. The subnet mask and target IP address
enable the transmitting IP device to decide whether the data packet can be
delivered directly to the target device or if it must be forwarded via the default
gateway.
For IPv6, the subnet mask corresponds to the network prefix. See Ethernet,
TCP/IP, MS/TP and BACnet basics (CM110666).
Default gateway: IP address of the IP router. This value is relevant for
communication across IP segments.
UDP port number For BACnet/IP to use UDP, a UDP port number must be defined. Only devices with
the same UDP port number can communicate with each other.
Port numbers are divided into the following classes by the IANA (Internet Assigned
Numbers Authority):
● Well Known Port Numbers: Fixed port numbers assigned by IANA (0… 1023)
● Registered Port Numbers: Numbers registered with IANA (1024…48151)
● Dynamic and/or Private Ports Dynamically assigned or privately used port
numbers (49152…65535)

198 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

For BACnet, port number 47808 (0xBAC0) is registered with IANA.

If there are several BACnet internetworks on an IP network, they can be separated
by different port numbers. Using several internetworks can be helpful in very large
projects, for migration, and to encapsulate sections of a plant with different
reliability criteria. Since Desigo CC communicates simultaneously with multiple
internetworks, the operation is not restricted.
However, only one port number is registered for BACnet with the IANA. If
additional UDP port numbers are required, we recommend the use of port numbers
47809 to 47823 (0xBAC1...0xBACF). This does not comply with IANA regulations.
This range is reserved for future applications and should not be used. There is only
a very small chance that these ports might be used elsewhere. To avoid clashes,
do not use any port numbers from the range of dynamic or private ports. See
www.iana.org/assignments/port-numbers.
BACnet Broadcast The BBMD is required as soon as IP routers are used in a BACnet network. IP
Management Device routers limit broadcast messages to the local IP segment, that is, they do not allow
(BBMD) any broadcast messages to pass through. In order to distribute BACnet broadcast
messages across IP segments irrespective of this limitation, a BBMD is required in
the relevant IP segments. If a BBMD receives a broadcast message, for example,
within the local IP segment, it transmits this as a unicast message to all other
BBMDs. The BBMDs then transmit the received message to their own local IP
segments. BACnet refers to this as two-hop distribution:
1. Hop: BBMD sends a unicast message to all other BBMDs.
2. Hop: They then distribute the message to all BACnet devices in the local IP
segment.
One-hop distribution can be implemented with Direct Broadcasts. In this case the
BBMD sends a direct broadcast to all remote IP segments. This broadcast is
received by all IP bus subscribers in the relevant segment. Not all IP routers
support Direct Broadcasts.
IPv6 (BVLLv6) only supports two-hop BBMD. Broadcasts are implemented via IPv6
mutlicasts. See Ethernet, TCP/IP, MS/TP and BACnet basics (CM110666).
BBMDs ensure that broadcast messages are distributed in a BACnet network.
They are grouped by BACnet network. A maximum of one BBMD is allowed in any
one IP segment.
BACnet network #100 is separated by IP routers. The Internet also contains IP
routers. This is why different segments are shown before and after the Internet
cloud. BBMDs are required so that BACnet broadcast messages are available in all
IP segments.
BBMD parameters The BBMD parameters are written to the BBMD or (for Desigo) to the BACnet
router during commissioning. The following information is required for each BBMD
in the BACnet network:

Designation Description
IP address IP address of the BBMD.

UDP port UDP port number of the BBMD.

Broadcast mask If the BBMD is to be addressed via direct broadcast (one-hop distribution) the subnet mask of the
BBMD must be specified. Since not all IP routers support this mechanism, direct broadcasts are
not supported by default. Two-hop-distribution is always possible. The broadcast mask is then
255.255.255.255.
Not required for IPv6.

Table 54: Structure

Foreign device A foreign device is a (remote) BACnet device in a remote IP segment. It registers
with a BBMD in order to send or receive broadcast messages. Registration with a
BBMD involves making an entry in its Foreign Device Table (FDT). The registration
must be renewed at regular intervals.

199 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

The foreign device does not send broadcast messages, but passes them as
unicast messages to the BBMD for distribution. The BBMD in turn passes incoming
broadcast messages as unicast messages to the foreign devices in its FDT.
In the Desigo system, Desigo CC, XWP/ABT, and PXM20-E can be operated as
foreign devices. IPv6 does not support foreign devices
Examples from the Desigo ● IP Segment 1: Desigo CC 1 does not have to be configured as a foreign device,
topology because this IP segment contains a BBMD.
● IP Segment 2: PXM20-E does not have to be configured as a foreign device,
because this IP segment contains a BBMD.
● IP Segment 2: Desigo CC 3 does not have to be configured as foreign device,
because this IP segment contains a BBMD.
● IP Segment 3: This segment only contains Desigo CC 2. To enable Desigo CC
2 to receive and send broadcast messages, it must register with a BBMD as a
foreign device. It does not matter with which BBMD it registers.
Foreign device If a BACnet device operates as a foreign device, the IP address and UDP port
parameters number of the BBMD must be specified.

Designation Description
IP Address of BBMD IP address of the BBMD with which the foreign device registers.

UDP Port of BBMD UDP port number of the BBMD with which the foreign device is registered. The default is 0xBAC0.

Table 55: Structure

The recording interval (Time-To-Live) for Desigo products is set at 300 seconds (=
5 minutes).

PTP data link layer

The PTP Data Link Layer is used for remote management over the telephone line.
Unlike LonTalk and IP, PTP does not allow the creation of a network. The PTP
connection is always between two half routers, and between two different BACnet
networks. Several BACnet networks may be located at each end of the PTP
connection. Only one active communication line can exist between any two
BACnet networks or between any BACnet devices.
The half-router function is implemented in Desigo CC, XWP/ABT and PX.

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 160: PTP data link layer

PTP connections are only possible between Desigo CC, XWP/ABT und PX. PTP
connections between PXs are not permitted.
PX devices which can be reached via PTP always belong to a separate site. With
reference to the topology at the beginning of the chapter, the site named Baar must
not be combined with the sites named Zug or Cham. Several PXs per site can be
used as half routers. When establishing a communication, the best-performing
connection is always selected. Redundancy is not allowed, that is, several
simultaneously active connections in a given BACnet network are not allowed.
With Desigo CC, a separate, independent, internal BACnet internetwork is created
for each Data Link Layer type. Routing between LonTalk, IP or PTP is therefore not
possible.
The following parameters are required for each half router:

200 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
BACnet Architecture (MLN & ALN)
13

Designation Description
Local network number The BACnet network number to which the half router belongs.
With PX, the local network number is the same as the device's own network number.
Desigo CC supports all three different Data Link Layers (IP, LonTalk and PTP). They are handled
internally as independent BACnet internetworks. This means that routing between the different
Data Link Layers is not possible. Therefore, the local network number can be allocated to IP
and/or LonTalk independently of the networks. However the local network number must be unique
among all networks which could possibly be reached from Desigo CC via a PTP connection.
Recommendation:
If Desigo CC has an additional Data Link Layer (IP and/or LonTalk), the local network number of
this network should be used (example in the beginning of the chapter: For Desigo CC 2, the local
network number of BACnet network #4 should be adopted).
In Desigo CC with only one PTP connection, the local network number must be in the range 1000
to 1099. (Example: Desigo CC 3 -> #1000).

COM parameter For the PX half router, the COM port to which a modem or null modem is connected must be
specified.

Modem parameters The modem parameters contain individual settings for the relevant modem types. Predefined
parameter sets are available for the PX half router.

Table 56: Parameters for half routers

The following parameters are required for each PTP connection starting from a PX
half router:

Designation Description
Remote network number This network number determines the BACnet network in which the remote partner device is
located. In the Desigo system this is the local network number of Desigo CC.

Remote area name The remote area name stands for a peer-to-peer remote network number of the network
containing Desigo CC.
During configuration, the remote area number lets you assign a clear name to the (remote) alarm
recipient rather than a network number.

Telephone number The telephone number for access to the remote device.

Performance index The performance index refers to the quality of the router data connection. If multiple PX half-
routers are available in a PX site, and if a connection to a remote network is to be established, the
router with the best performance index is selected. If no connection is established, the router with
the next best performance index automatically tries to connect.

Range: 0...255 (0= best / 255 = worst connection)

Table 57: Parameters for PTP connections

For each PTP connection in Desigo CC, only the telephone number needs to be
defined.

Data link layer MS/TP

Data Link Layer Master/Slave Token Passing MS/TP is another protocol variant for
BACnet. Desigo supports this variant via a specific router that connects BACnet
MS/TP to BACnet/IP.
MS/TP is based on the physical layer EIA-485/RS-485 and supports baud rates up
to 76.8 kbps. Up to 256 devices can be connected to one MS/TP segment (in
theory, dependent on their unit load).

Application Layer

Network Layer

LonTalk IP PTP MSTP

Figure 161: Data link layer MS/TP

201 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 BACnet Architecture (MLN & ALN)

Addressing MS/TP Each device has its own unique MAC address. The MAC address is one octet long
devices and defined as follows:
● 0-127 reserved for master devices
● 0-254 reserved for slave devices
● 255 reserved for broadcasts
The MAC address can be set via DIP switch (hardware) or related configuration
tools (software) for each device.
Structuring MS/TP is transmitted via two-core cables as per EIA-485/RS-485. The maximum
length of a segment is 1200 meters. 64 devices are allowed on a segment.
Different segments can be interconnected via repeaters to form a larger EIA-485-
network. The specific electrical properties, such as polarity, common signal ground,
terminating resistances, etc. must be taken into account. The actual, possible
network size and maximum transmission rate primarily depend on the network
structure. Establishing a network in daisy chain form is best.
BACnet/IP

10664Z42_06

MS/TP ...
Router
PXG3
DXR2 DXR2 DXR2 DXR2

Figure 162: MS/TP nodes in a line architecture

Due to relatively difficult, electrical conditions imposed by EIA-485 wiring and

limited data transmission capacity, we recommend using BACnet MS/TP only for
devices with low data volumes that are geographically far apart.
For devices with larger data volumes and shorter distances to the Desigo
automation station, integration in Desigo primarily should be carried out via TX
Open or PX Open.
System devices PXG3 is a BACnet router that routes BACnet telegrams between BACnet networks
and different data link layers. It is available in two versions:
● PXG3.L: (triangle router) Simultaneous routing between Ethernet/IP, LonTalk,
and MS/TP
● PXG3.M: Routing between Ethernet/IP and MS/TP
See BACnet router for BACnet/Ethernet/IP, BACnet/LonTalk, BACnet MS/TP
PXG3.L, PXG3.M (CM1N9270).
An individual BACnet IPv6 data link can be used as an option for the router. As a
result, the PXG3.M is turned into a triangle router and the PXG3.L to a square
router. The router can be configured either via XWP or the integrated web server.

BACnet address
Every BACnet device in the BACnet internetwork can be accessed via its BACnet
address.
The BACnet address is defined by the BACnet standard and comprises the
following elements:

202 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
LonWorks Architecture (ALN)
13

Designation Description
Network number Network number of the BACnet network in which the device is located. The network number is
only parameterized on devices with BACnet router functionality (including half router) and is
implicitly valid for all BACnet devices in the BACnet network.

BACnet MAC address Address specific to the transport protocol. This address is written to the device in the
commissioning phase.
BACnet MAC address for:

LonTalk: 2 octets, subnet ID und node ID

IP: 6 octets, IP address and UDP port

IPv6: 3 octets as virtual MAC address (VMAC)

MS/TP: 1 octet, MAC address (master 0-127, slave 0-

254, broadcast 255)

Table 58: Structure

BACnet device address Each BACnet device has a device address. This address is written to the device
during the network commissioning process. The BACnet device address is unique
within the BACnet internetwork. The term BACnet device address is an in-house
term rather than an official BACnet term.

Designation Description
Device ID Object identifier of the BACnet device object. The device ID is unique within the BACnet
internetwork.

Device name The object name of the BACnet device object. The device name is unique within the BACnet
internetwork.

Table 59: Structure

For information about the direct addressing of BACnet references to objects in

other networks and media, see Desigo Ethernet, TCP/IP, MS/TP and BACnet
(CM110666).

13.2 LonWorks Architecture (ALN)

With the LonWorks-based communication protocol complete networks made up of
interoperable products can be created. The protocol conforms to ISO/IEC 14908
(worldwide), EN 14908 (Europe), ANSI/CEA-709/852 (U.S.) and is also
standardized in China. See www.lonmark.org.
LonWorks is suited for use with different types of transmission media, such as
twisted pair cables, power line, RF, fiber optics or IP (TCP/IP and UDP/IP) It
supports straightforward installation with different cabling topologies (for example,
star or line). The connection of objects via bindings (for example, standard network
variables (SNVTs), standard configuration properties (SCPTs)) can be defined at
the project engineering stage or can be adapted in the field.

Structure
The following figure shows the structure of a Lon network in the FLN

203 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 LonWorks Architecture (ALN)

Figure 163: LonWorks network

Key:

R Repeater, for example, LonWorks physical repeater

B Bridge, for example, L-Switch (Loytec)

RT Router, for example, LonWoks router

GW Gateway, for example, PXC..., RXZ03.1

See LonWorks networks Checklist (CA110335).

Trunk A trunk holds all devices that can communicate with each other directly or via
repeater, bridge or router. The term trunk is specific to the Desigo system. One
trunk corresponds to one LonWorks or Desigo RXC project. Trunks can be
connected via gateways.
Segment A trunk can be divided into segments. The segments are connected by a router. If
there are no routers, the trunk comprises only one segment.
Physical segment The physical segment is the communication medium. LonWorks devices are
connected to the physical segment. One segment can be divided by bridges or
repeaters into several segments. The number of devices per physical segment is
limited. See RXC Installation Guide (CA110334).

System devices
Gateway The gateway links trunks. It operates on the application layer of the ISO/OSI layer
model. The following LonWorks gateways are available:
The RXZ03.1 point coupler provides a fixed number and type of LonTalk network
variables (NV). Each side of the point coupler belongs to a trunk or LonWorks
project. The point coupler can be used to implement time-critical connections
between two trunks. The point coupler integrates third-party devices that have
been engineered with a different tool.
Loytec L-Proxy and Sysmic XFM-LL are freely programmable point couplers. The
XFM-LL device may be used, when depicted like a standard third-party device
(configuration via its own tool).
The PXX-L.. extension modules let you connect LonWorks devices to the PXC..D
modular series. This adds the grouping, schedule, trend, and alarm management
functions to the RXC room automation and allows the mapping of data points to
BACnet/IP or BACnet/LonTalk.

204 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
KNX Architecture (ALN)
13

Router The LonWorks router operates on the network layer of the LonWorks protocol. It
filters data packets based on their subnet ID or group ID. Subnets or groups must
never be defined across a router, that is, the subnet IDs and group IDs at each end
of the router must never be the same. Routers are used where there is heavy local
network traffic. They allow the unloading of unaffected devices from the network
traffic. In Desigo there are no large LonWorks networks, as the FLN is divided into
trunks. Routers are only required in exception cases.
L-Switch (Loytec) The L-Switch filters the package on the basis of the subnet/node ID or group ID. It
automatically learns the topology and forwards the data packets accordingly. The
L-switch does not have to be configured. Unlike the router, there is no need to take
account of any addressing limits (allocation of Subnet ID or Group ID).
Physical repeater LonWorks has physical and logical repeaters. The physical LonWorks repeater
does not filter the data packets. It regenerates the electrical signal. One physical
LonWorks repeater can be used in the path between any two devices within a
segment.
In logical repeaters, the data packet is processed by the neuron chip. This enables
several logical repeaters to be connected in series. The disadvantage is that the
logical repeater must be configured, and that owing to the limited size of the buffer,
it cannot be used for large data packets, that is, for BACnet/LonTalk.

13.3 KNX Architecture (ALN)

KNX is an open standard that conforms to EN 50090 and ISO/IEC 14543. See
www.knx.org. KNX corresponds to the former European Installation Bus (EIB) and
is backward-compatible.
With KNX technology, advanced multiple disciplines and simple solutions can be
implemented to satisfy individual requirements in room and building automation in
a flexible way. The ETS, a vendor-independent tool is available for commissioning.
KNX can use twisted pair cables, radio frequency (RF) or data transmission
networks in connection with the Internet Protocol for communication between the
devices. KNX has links and interfaces for connection to Ethernet/IP, RF, lighting
control with DALI and building automation and control systems.

Structure
The following figure shows the structure of the KNX network:
● KNX: KNX devices, for example, third-party KNX
● PX KNX: Automation station PXC001.D or PXC001-E.D and PX KNX firmware

205 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 KNX PL-Link Architecture (FLN)

Backbone line

Backbone Backbone PX KNX Backbone

coupler coupler (0.0.y) coupler
(1.0.0) (2.0.0) (3.0.0)

Area 1 Area 3

PX KNX Line Line

(3.0.y) coupler coupler
(3.1.0) (3.2.0)

EIB EIB
PX KNX
(3.1.y) EIB EIB

EIB EIB

Line 1 Line 2
Figure 164: KNX network topology

Line A KNX network consists of lines. Up to 64 devices can be connected to each line.
Area Up to 15 lines can be connected to a main line via line couplers (LC). This is called
an area.
Backbone line The topology can be expanded by means of a backbone line. Up to 15 areas can
be connected to the backbone line via backbone couplers (BC). Technically, these
are the same devices as line couplers.
Line/Backbone couplers Couplers separate the areas and lines. Couplers keep the bus traffic within bounds.
Datagrams that are only needed on one line should not create a load on the entire
network and hence have to be confined to that line. Respective filter tables are
created (ETS) when setting up the project/network.
Engineering Tool Software The KNX Engineering Tool Software (ETS) is used to create KNX projects. A bus
(ETS) interface is required to commission the devices with ETS.
For a detailed description of the KNX topology, see
http://www.knx.org/fileadmin/template/documents/downloads_support_menu/KNX_t
utor_seminar_page/basic_documentation/Topology_E1212c.pdf.

System Devices
PX KNX The PX KNX system controller maps KNX devices to BACnet objects. PX KNX also
supports different system functions, such as grouping, scheduling, alarming,
trending, etc.
The system controller must be positioned correctly in relation to the topology and
the load on the bus caused by the devices and connections (group addresses).
Bus power supply Each line and each area must include a bus power supply.

13.4 KNX PL-Link Architecture (FLN)

KNX PL-Link (PeripheraL-Link) connects communicating room and field devices
(room devices, sensors, actors) with the PXC3 room automation station and the
DXR2 compact room automation station. KNX PL-Link fully complies with the KNX
standard.

206 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
KNX PL-Link Architecture (FLN)
13

Siemens field devices can be connected to the KNX PL-Link using the KNX PL-
Link plug & play capability. KNX PL-Link devices are configured using the Desigo
tools. The KNX commissioning software (ETS) is not needed.
One or more KNX PL-Link devices are connected to the trunk of the corresponding
room automation station in a line topology.
A comprehensive library with preconfigured devices supports simple engineering.
The PXC3 room automation station allows for simultaneous integration of devices
with KNX PL-Link and KNX S-Mode on a single bus line. Devices with KNX S-
Mode are additionally commissioned using ETS.

Structure
The following figure shows an example of a logical network topology with KNX PL-
Link devices, a room automation station and several rooms.

BAC network

Automation
station

KNX PL-Link network

Room Room Room

Figure 165: KNX PL-Link logical network topology

Power supply concept The PXC3 and DXR2 room automation stations have an integrated KNX power
supply to supply their trunks with the corresponding KNX PL-Link devices. This
allows simple installations, for example, an automation station with one or a few
room units, without an extra device for power supply to the KNX PL-Link network. If
many KNX PL-Link devices are connected, the power supply at the room
automation stations is shut off and an external KNX power supply must be used.
The following figure shows the concept of a built-in power supply unit (PSU):
Automation station

PSU

KNX PL-Link network

Figure 166: Built-In KNX PL-Link power supply unit

System devices
Third-party KNX devices can be integrated in KNX PL-Link networks via KNX S-
mode. The KNX Engineering Tool Software (ETS) is necessary to engineer and
commission these devices.
DXR2.M.. automation stations cannot integrate KNX S-Mode devices.

207 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
13 DALI Architecture (FLN)

13.5 DALI Architecture (FLN)

DALI (Digital Addressable Lighting Interface) is a dedicated protocol for lighting
control. See www.dali-ag.org.
DALI is tailor made for modern lighting solutions. A DALI system can be as small
as a single luminaire, or can encompass multiple systems across one or more
buildings. DALI systems can be connected using lighting hubs/routers.
DALI features:
● Max. 64 devices per subnet (hub/routers)
● Max. 300m cabling
● Max. 250mA device consumption
● Standard two-core cable (1,5mm²)
● Polarity free & free wiring topology
● DALI power and data on the same pair of wires
● Bidirectional communication with feedback of operating state (dim level, lamp
failure, etc.)

Structure
A DALI system can be made up of control gear, control devices and bus power
supplies.
Control gear Control gear usually contains the power control circuit to drive lamps, or some
other type of output, such as on/off switching or 1 to 10 V analog signals.
Control devices Control devices can provide information to other control devices, such as light
intensity information, and can send commands to control gear. Input devices are a
type or a part of a control device that provides some information to the system,
such as a button press or movement detection. DALI application controllers are
also control devices, for example, they can send commands to control gear to
modify the lighting.
Bus power supplies At least one bus power supply must be present in a DALI system. This is
necessary to allow both communications on the bus, and to power any bus-
powered devices. The bus power supply does not need to be a separate unit – it
could be part of another device such as a LED driver or a sensor.
Bus wires A DALI system also includes the bus wires that are used to connect the DALI
terminals of the various devices in the system.
Addressing DALI allows the flexible addressing of devices.
At the simplest level, all devices are addressed simultaneously by broadcast
commands. This allows the control of lighting in a similar manner to 1 to 10 V
analog control, without requiring any configuration of the individual devices. If a
level (Direct Arc Power Command) is broadcast, then all control gear will act upon
that command, changing their output to the same new level.
With simple configuration, DALI devices can be given one of 64 short-addresses.
This allows individual control, configuration and querying of any single device in the
system.
DALI devices can also be group addressed. For example, a DALI LED driver could
be programmed to be in any combination of the 16 available groups. When a
command is sent to a group, only devices that are in that group are addressed.

System devices
PXC3...A The PXC3…A automation stations have a DALI bus for connecting up to 64 DALI
ballasts/drivers.

208 | 377
Siemens CM110664en_03
2017-09-18
 Network Architecture
DALI Architecture (FLN)
13

PXC3.E16A The PXC3.E16A room automation station is optimized for lighting applications. It
has an onboard DALI interface for connecting up to 64 electronic ballasts or LED
drivers

209 | 377
Siemens CM110664en_03
2017-09-18
 Remote Access
14 Remote Access Methods

14 Remote Access
The remote access is an access to resources via the internet or a point-to-point
connection.
The remote access is used to:
● Connect a remote location to Desigo CC, for example, for on-call service,
managing different locations or support by a specialist
● Remotely access Desigo CC
● Make a change, create an extension or search for errors using an engineering
tool
● Forward alarms as text messages or emails from PX Web, TP Web, or Desigo
CC

14.1 Remote Access Methods

There are two remote access methods:
● Methods that establish a direct point-to-point connection
● Methods that use public networks (for example, telephone networks for
accessing the internet) as a transport medium

10664Z45en_02
Desigo CC
Metro ethernet

Modem

TV cabel

Mobile phone

Radio Touch Panel

BACnet/IP

Web interface

Automation station
Figure 167: Remote access methods

The following access networks can be used for the remote access:
● Telephone network
● TV cable network
● Other cable-based networks, such as metro ethernet
● Mobile networks
● Other RF-based access networks

Telephone network-based technologies

DSL variants Characteristics of DSL variants:

210 | 377
Siemens CM110664en_03
2017-09-18
 Remote Access
Choosing a suitable Access Technology
14

● There are different ADSL and VDSL variants. The DSL variants are country-
specific.
● The uplink (that is, the data flows from your private home or project to the
internet) and downlink (that is, the opposite direction) bandwidth are different.
Take this into account when you select a suitable internet access.
● The DSL line in parallel can be used for telephone calls.
● If you want to use telephony on the same line, you need a splitter in addition to
the DSL modem.

TV cable-based access
● This access is similar to DSL. You can access the system remotely via a cable
modem provided by the cable network operator.

Other cable-based networks, such as metro ethernet

Characteristics of other cable-based networks, such as metro ethernet:
● Connections with very high bandwidth are available.
● A metro ethernet connection is usually not implemented as part of a BACS
project.

Use of mobile telephone networks

The available bandwidth is shared by an unknown number of users with an
unknown usage profile. The maximum data transfer rates that are advertised by
the mobile network operators deviate substantially from the actual data transfer
rates.
The access via a mobile network is less stable than via a cable-based network in
terms of availability and data throughput.
If you have to establish a remote access in a remote area, check the service
availability and stability. You can use the distance from the base station of the
network operator as a criterion. You can also check if there are any large obstacles
(mountains, etc.) between the base station and the building.
LTE & UMTS Characteristics of LTE & UMTS:
● Can be fast
GPRS Characteristics of GPRS:
● The speed suffices merely for tasks requiring a low bandwidth, for example, for
the system to send an email with a small attachment.

Other RF-based access networks

Characteristics of such RF-based technologies:
● Suited for remote locations, when no DSL is available.
● There are various technologies used by the different providers. Find out what is
available at your location.
● Depending on the used frequency, transmission problems can occur during
rain or snowfall, even over short distances.

14.2 Choosing a suitable Access Technology

The technology depends on your intended use and the required bandwidth.

211 | 377
Siemens CM110664en_03
2017-09-18
 Remote Access
14 Choosing a suitable Access Technology

I want to use the remote access for... DSL LTE & GPRS TV cable Metro RF-based
UMTS ethernet
Remote access to Desigo CC o/+ o/+ - + + o/+

Remote access to another BACnet client + o o/- + + +

Connecting a Desigo system to Desigo CC o/+ -/o - + + o/+

Alarm forwarding + + + + + +

Table 60: Which remote access technology is suitable for which task?

Key:

+ Good

o Slow but still possible

- Not possible or too slow

The different access technologies are available with different bandwidth, for
example, DSL (o/+) can be fast or relatively slow.
Costs The costs are divided into monthly basic costs and usage costs. To optimize costs,
analyze your usage profile, that is, how many times per month do you use it and
how much data do you exchange per use.
A data flat rate ensures that the costs are capped. Choosing an inappropriate rate
plan for a mobile subscription could result in high costs.
Availability RF-based links and all mobile network-based transmission standards can suffer
from transmission problems due to bad weather especially at the cell border. The
bandwidth that can effectively be used in the project can vary over the day,
because the bandwidth is shared by all users. The bandwidth variations for cable-
based technologies are lower.
Recommendations To ensure a reliable remote access, use cable-based technologies even if the cost
is slightly higher. Use mobile networks or RF-based systems only if no alternative
is available. If you require a high availability remote access, you can additionally
establish a mobile network-based link as a fallback solution. To do this, use a
router that offers both a DSL and a GPRS/UMTS/LTE modem.

Every remote access can be attacked. Note the safety measures in the document
IT Security in Desigo Installations (CM110663).

Access to the PXC..D/-U automation stations via Xworks Plus (XWP) can be
protected with a password (password property for remote access [RemAcpwd]).
You can enter the password in the Device Property dialog in XWP.

Migrating from an analog Analog modems should not be used in new installations and are not future-proof
modem-based method due to the migration of the networks to Voice over Internet Protocol (VoIP).
ISDN also is not a future-proof technology and should therefore not be used.
If DSL is available, use DSL. Otherwise, use other cable-based internet access
networks. If you cannot use such a network, use a mobile network or an RF-based
access.
If a project is based on LON, use the PXG3.L router, to connect the remote access
on the IP side of the router.

212 | 377
Siemens CM110664en_03
2017-09-18
 Remote Access
Technical Details
14

14.3 Technical Details

DSL
The DSL modem must match the used xDSL technology and should be purchased
in the country of use. DSL connections can use different coding methods, which
differ from country to country.
A modem either has one RJ45 connector for connecting the router or has a built-in
router. The router must be configured. The modem needs an access code from the
Internet Service Provider (ISP).
If the telephone line is to be used for DSL and telephony, a DSL splitter that splits
the phone and data signals is necessary.

TV cable-based method
The operator provides the modem. Sometimes, you have to configure the modem.
Usually, the cable operator provides a preconfigured modem or the modem
configures itself automatically when you connect it for the first time. The modem
has an RJ45 connector to connect it to the IP network (the router) or a built-in
router. The router must be configured. Sometimes you need to enter an access
code received from the operator.
A separate DSL splitter for splitting TV and data signals is not necessary.

Metro Ethernet
Metro ethernet is usually not implemented in a BACS project and is therefore not
described in this document.

Use of mobile telephone networks (GPRS/UMTS/LTE)

Several suppliers offer GPRS/UMTS/LTE modems, for example, modems for
private use and modems for industrial applications (also top-hat rail).
Because of the attenuation of the walls and ceilings, the signal inside a building
can be weak, that is, an antenna must be placed on the exterior of the building,
preferably on the roof.
You can get the best signal strength when the nearest base station of the mobile
network you want to use is not too far away and there are no large obstacles
between the base station and the modem's antenna (line of sight). Directional
antennas improve the transmission quality, but must be optimally directed towards
the base station.
The antenna cable between the modem and the antenna must be short, otherwise
the signal is too weak. Observe the manufacturer's information on the cable type
and maximum length. Antenna cables may not be bent or pinched too severely.
The mobile modem must be placed near the optimum antenna location. The length
of the cable to the IP network is not that critical.
The mobile network operator provides the SIM card. SIM cards come in various
sizes, depending on the modem. Choose the correct SIM card.
The modem is connected to the IP network. The safety measures depend on the
modem.
GPRS modems with an RS-232 connection can be connected to some PX
controllers using a USB-RS-232 converter.

RF-based access networks

Since there are different technologies, an RF-based access is only implemented in
tight cooperation with the network operator. We recommend that you strictly follow
his guidelines.

213 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 Technical Details

15 Management Platform
A building automation and control system encompasses all control functions of one
or more buildings.
In addition to typical HVAC systems, there is a need to integrate other areas of the
building, such as lighting and blind control systems, fire alarm systems and access
systems.
At completion the system comprises one or more superordinate management
platforms that let you centrally operate and monitor the individual plants, while
each plant's technical building equipment still continues to work autonomously.

Figure 168: Desigo CC lets you operate and monitor the plant

Functions Desigo CC has the following functions:

● Central operation of HVAC processes and related areas of a building
● Visualization, storing and interpretation of data from underlying levels
● Control of superordinate functions (time catalogs, external process reactions)
● Interface for external communication (alarm messages, etc.)
● Data exchange between DDC controllers (automation level)
Requirements Modern building automation and control systems need to fulfill the following
requirements:
● User friendliness
● Integration capability
● Expandability
● Remote operability
● Cost effectiveness
Advantages Under the brand name Desigo™, Siemens offers a system family of
complementary automation modules and management platforms for buildings and
infrastructures of all types and sizes.
Desigo CC has the following advantages:
● A uniform interface for all connected areas from heating, ventilation and air-
conditioning through fire alarm systems, video solutions and intrusion alarms to
access control systems.
● Cost-effective solutions in every expansion phase through the broad scalability
of the number of data points, functions, and broad integration of subsystems.

214 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Technical Details
15

● A state-of-the-art graphical user interface.

● PC- or server-based management platform based on the current Microsoft
operating system.
For more information on the Desigo CC management platform, see Desigo CC
System Description (A6V10415500).
Architecture The Desigo CC management platform presents a single point of entry for users to
operate, monitor and optimize building automation, fire safety and security systems
or a combination thereof.
Desigo CC is a flexible, full client-server architecture allowing scalability from small
and medium to large and complex systems. The platform provides customizable
and market-specific distributions.
Desigo CC can be installed on one single computer, with full server and client
functionality. Furthermore, Installed, Web, and Windows App Clients can also be
added on separate hardware. Additional system connections can be made through
systems installed with Desigo CC Front End Processors (FEP) configurations. Web
interfaces provide the customer an increased flexibility for operation and future
extensions, e.g. mobile applications for tablets and smart phones.

Figure 169: Desigo architecture

Main server The main server contains the project database and the software that monitors and
commands the system network. Clients connect to this server to monitor and
control the facility. If the same computer runs Microsoft IIS, the installation provides
web clients with access to the facility. The Desigo CC server installation always
includes an installed client with a user interface for monitoring and controlling the
facility. The main server has interface connections to the field (either directly or
using FEP) and provides a centralized database and other services to the
connected clients. The main server can support a number of clients that are
connected using a network (LAN) or Intranet (WAN).
Installed client The Installed Client is typically used for operators who are focused entirely on
monitoring and managing building systems. In this configuration, software
components used for event management are locked in place and cannot be moved
or covered by other applications. This ensures that critical events are never missed
or hidden. Installed Clients can optionally be configured to run in a closed mode
where only Desigo CC and other specifically identified applications are allowed to
run. In closed mode, the workstation is dedicated to running Desigo CC, with
access to the Start menu or other operating system and customer applications
available only to administrative users.
Web client (browser client) The web client is deployed on the intranet with full trust and allows access to local
resources. The system runs in the Internet Explorer browser (using HTTP or
HTTPS as communication protocol) and is downloaded on demand each time the
user launches the system as web application. When working in a browser, you can
have the same capabilities as those working on an Installed Client, or can be
restricted to have different access when connected remotely.
As web clients require low latency and high network bandwidth, they are
appropriate for intranet use. We do not recommend it for internet use.
See Desigo CC Installing the Web Client Application Certificate (A6V10415479).

215 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 User Functions

Windows app client The Desigo CC Windows App Client looks like the standard system software, but is
(ClickOnce) a light application that can be downloaded from the Desigo CC server when
connecting through a browser. When the Windows App Client is downloaded, it
runs like any other Windows application on the desktop. It can be launched from
the Start menu, desktop icon, quick-launch toolbar, and so on. This deployment
does not require administrative privileges. The Windows App Client runs in its own
pane, without the overhead of the internet browser application and menus.
Web server To use the Desigo CC Web and Windows App Clients, you must install the web
server. To install the web server, you must first install Microsoft IIS on the web
server computer. Usually the web server is on the Desigo CC server. It might be
located on a separate computer, if the customer's IT department requires the web
server to be installed in a separate controlled environment, or if it is preferred not to
use the resources of the system server for the Microsoft IIS tasks.
The web server lets you to access the system using the intranet and a web
browser. You can add only one web server. It lets you download all files required
for the Web Client and Windows App Client environments. It provides a system
web page to access the Web Client, the Windows App Client, and the system
documentation in the Internet Explorer browser. It also represents the endpoint of
the communication with the system server.
Front End Processor A Front End Processor (FEP) is a computer that provides additional connections
between building level devices (such as field panels) and Desigo CC. By providing
additional connections to the building level network, an FEP enables load
balancing for the network-based processing for a Desigo CC system.
System Dimensioning Desigo CC covers a wide variety of solutions so that it is impossible to define
Guide simple rules for determining the size. Therefore, a system dimensioning tool is
available that estimates the system size and disk storage space on the basis of
information available at the time of the offer, for example, the number and type of
physical points and the expected history data base contents.

15.1 User Functions

Graphics The Graphics application allows you to view the configured graphics representing
your facility or equipment. You can change the current state of an object's
properties from a graphic, filter your view of a graphic by discipline and section and
you can zoom in and out for greater detail or for a birds-eye overview.
Trends All available process data of a system can be recorded and applied to operational
optimization. This lets you record information on plant states, temperature curves,
switching states, and counter values in a form that is suitable for your purposes.
The measured value data can be displayed and evaluated graphically.
Online trend records real-time values from your plant and displays them graphically
in a Trend View. If a value changes, the data values are sent to the trend
application. Offline trend data is used for the longer-term storage and retrieval of
historical data for the analysis of entire plants or single processes. With offline
trend, data is recorded directly in the automation station.
Trend and system activity data is stored in a Microsoft SQL Server database.
Microsoft SQL Server Express is included with the Desigo CC software, and can be
upgraded as required. The Trend Comparison View lets you time-shift the trend
view to compare data at different times for quick analysis of changing conditions.

216 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
User Functions
15

Figure 170: Trends

Scheduling The Scheduler allows you to schedule events for Desigo CC and field panels at
your facility. You can create daily or weekly schedules for Desigo CC and BACnet
devices. You can fully configure and monitor standard BACnet schedules,
calendars, command objects, and workstation-based schedules that can be used
to support systems without built-in scheduling capabilities. Schedules are
automatically associated with systems they control, so you can quickly navigate to
the schedules of any selected object. A Timeline Viewer lets you view the details of
multiple Desigo CCs and field panel schedules simultaneously, spanning a range
of time.

Figure 171: Scheduler

Reports The Desigo CC reporting tool includes standard reporting templates and lets you
create fully configurable reports with custom logos, headers, footers, and layouts
that include tabular and graphical system information. You can schedule reports
and save them in CSV or PDF formats.

217 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 User Functions

Figure 172: Reports

Event management Event management allows you to manage events throughout the system. You can
monitor and manage the progress of each event from initiation through resolution.
The full history of each event issue is recorded, and you can generate event-
related reports that you can view, save, and print.
Log Viewer The Log Viewer application provides an historic log of all user and system events
and activities that have occurred. You can retrieve these historic events and
activities for further analysis and investigation using sorting and filtering. Log views
can be saved and exported if required.
Detailed log The detailed log allows users to view the most recent records for any selected
object. The same content filtering and sorting functionality available in the Log
Viewer is possible in the detailed log.
Remote notification You can configure Desigo CC to automatically or manually send email or SMS
messages to specific recipients.
You can specify:
● What events the recipients should be notified for and when
● How notifications are escalated from one recipient to another until a notification
message is responded to
● If a message is periodically sent to the operators stating that the system is
running normally
● Which devices are used for the notification
Macros Macros are predefined lists of commands that enable a user to send out a group of
commands to specified devices with a single action. Some macros can be started
manually while others may be part of schedules defined for time-based functions or
automatic reactions. Macros are also used by the system to perform multiple
command actions. These predefined system macros are applied to specific control
actions, such as block commands to fire control panels and system backup
functions.
Reaction Processor Reactions are automations programmed in the system, so that when a specific
situation occurs on site, a command or a series of commands is automatically
executed.
You can define actions to be executed automatically when specific conditions are
verified. Conditions can be based on time, on events, on a change of values, or on

218 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Main Components
15

a combination of some or all. When conditions are met, the Reaction Processor
executes a pre-configured list of commands.
Document management Desigo CC can handle the different types of document templates used in the
project. You can configure document templates in PDF, RTF, TXT, XLS, and HTML
format.

15.2 Main Components

System Manager The System Manager lets you navigate the system, view and override current
conditions, analyze historical operations, and configure the system. The System
Manager contains the System Browser, Primary, Operation and Related Items
panes that interact via built-in workflows. Multiple system management session can
be concurrently used.

Figure 173: System Manager

System Browser The System Browser displays objects in the building control system through
various views. You can search and filter objects, display object names and
descriptions, and drag objects into Trends, Schedules, and Reports.
History Database (HDB) Historical data is stored in an access-controlled MS SQL Server database. The
System Management Console lets you create a project History Database (HDB)
and link it to the active Desigo CC project on the main server. The history database
is used to log a wide range of user and system activities, such as:
● User and system activities
● Alarms and their treatment
● Faults that have occurred and are handled as batch messaging
● Values that are logged as trends
Project database The runtime data (process image) and the engineering data are stored in a file-
based database in a subdirectory of the project directory. The data is unencrypted
and database access can only be prevented by restricting access to the database
files. The project directory needs to get shared when deploying installed clients. It
is therefore important to restrict access on the db folder in the project directory to
the Windows account running the Desigo CC main server.
Desigo CC uses the Microsoft SQL database software. Microsoft SQL Express is
included on the product installation DVD (Microsoft SQL Server 2008 R2 Service
Pack 2, Express Edition, version 10.50.4000.0). Alternately, you can use an
existing Microsoft SQL Server installation (same version 10.50.4000.0). In this
case, the Desigo CC Installer will skip the Microsoft SQL Server installation. In both

219 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 Access and Security

Microsoft SQL Server cases, Microsoft SQL must first be installed and running on the computer where
the Desigo CC main server will be installed.
Microsoft IIS server A Microsoft Internet Information Services (IIS) server for Web Clients and Windows
App Clients can be installed on the Desigo CC server or on a separate installation
(web server).
License Manager Licensing ensures the operation of the system within the agreed system limits.
Only the system is allowed to change license data.
If a license becomes temporarily unavailable (for example, due to network
connection issues) the system continues to run fully operational for a grace period.
The system continues to check for the license and shuts down at the end of the
grace period, if none of the license checks succeed.
Exceeding the limits of the license (for example, by integrating more field system
data points than stated in the license) puts the system into courtesy mode. Phases
of courtesy mode accumulate until a total duration of 30 days is exceeded, then the
server shuts down. Unless new licenses are made available, after a manual restart
the system again goes into courtesy-mode exceeding and shut down.
Any unauthorized attempt to modify system license data directly in the database
(for example, changing the remaining time of a specific license mode) shuts down
the system.

15.3 Access and Security

User management User privileges can be assigned to users and to workstations, allowing users to be
granted the same access from everywhere or different access depending where
they're logged on. The user interface displays only elements, such as menus,
buttons, list items, tree nodes, where the user has at least read access.
Access privileges can be assigned to resources/groups, such as workstations,
features, applications, system objects, system object properties and logical groups
of these resources.
User authorization User access rights in Desigo CC are determined by four main factors:
● The system must know the user (authentication).
● The user must be assigned to a user group.
● The user must have the appropriate application rights.
● The user must have the appropriate scope rights.
If all of these conditions are met, the user can log on to Desigo CC, and read/write
objects and execute tasks, depending on the assigned rights.
See Desigo CC Engineering Manual (A6V10415473).
Scopes Scope is the general term for specific object access in Desigo CC. A scope
segments and implements certain rules for the user role in the project. A user only
sees the area of the building assigned to him, for example, pumps, receives only
alarms from this area in the event of an emergency and can only acknowledge
those alarms. If an emergency occurs in an area that is not in the scope of this
user, for example, ventilators, the user does not receive an alarm about this event.
Communication security In general, communication channels are non-encrypted due to performance
reasons. Exceptions are communication channels for file transfer using web and
video transfer. Sensitive data (passwords during authentication or user
management configuration) is transferred as encrypted message content.
Wireless input devices (especially keyboards) use radio transmission that is often
not or inadequately cryptographically protected. Even from greater distances, it is
possible to listen in or even plant external data in the system.

220 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Event Management
15

We recommend that you do not use wireless input devices. If you must use
wireless input devices, use only devices with proven encryption.

Communication ports and Which ports are used depends on the actual deployment and subsystem
protocols integration of the whole system.
See Desigo CC System Description (A6V10415500).

15.4 Event Management

Desigo CC lets you quickly, easily, and accurately respond to any event.
Summary Bar The Summary Bar contains a summary of the events occurring in the system and
lets you quickly access functions, such as the Event List. It also displays
information, such as the system status, the logged in user, etc. Depending on the
client profile in use, the Summary Bar can be docked on the desktop or freely
opened and closed as needed.
Event List The Event List provides a complete and easily filtered list of events under control of
Desigo CC. When the Event List is expanded, it clearly shows each event source,
severity, current status, custom messages and suggested action steps through the
use of text, color, and icon representations. You can acknowledge, silence, and
reset alarms from the Event List.

Figure 174: Event List

Event Bar When using profiles for critical event management, you can collapse the Event List
into a condensed list of event buttons in an area called the Event Bar, that remains
docked on the desktop for easy access. This lets you keep an eye on the current
situation at all times.
Client profiles To ensure the correct level of event management support for users in any situation,
a workstation and/or users can be easily assigned predefined profiles supporting
casual, intermediate, or dedicated event notification and management.
Fast treatment From the Event List or Event Bar, you can quickly select an event and perform all
the commands (for example, Acknowledge, Reset, Close or Suspend) from the
Event Detail Bar and Event List, without looking at treatment steps, viewing live
video or a map of the alarmed area, etc. The event descriptor (visible when the
Event List is expanded) contains a short description of the next action (which
command to select).

221 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 Installation, Setup and Engineering

When event treatment is in progress, you can send the available commands to the
source object causing the event or suspend treatment.
Investigative treatment From the Event List or Event Bar, operators can quickly open the System Manager
with focus on the source of the event, and all information (live video, recent history,
schedules, etc.) related to the event source.
Operating procedures Operating procedures consist of a sequence of steps or actions, which the operator
must, or is suggested to perform with the assisted treatment. For each step of a
procedure, the system provides instructions and operating tools. With appropriate
permissions, you can create, view, edit, or delete operating procedures.
Assisted treatment From the Event List or Event Bar, operators can quickly open the assisted
treatment to guide the operator through pre-configured operating procedures. Each
operating procedure is composed of steps - some of which may be mandatory - for
the user to complete (for example, to see the graphic of the object in alarm, fill-in a
treatment form, or automatically print the information of the event).

15.5 Installation, Setup and Engineering

License Management The installation program installs the Siemens License Management Utility (LMU)
Utility (LMU) on every management platform in a Desigo CC network. The LMU enables and
manages licenses and holds the installed licenses for Desigo CC. The operating
state of Desigo CC, the number of seats, the point count, and all functions are
controlled through the LMU. Each Desigo CC management platform must be
licensed locally. Licenses can be activated, repaired, returned and renewed
through the LMU.
After you install the LMU, you must activate the Desigo CC licenses using the
following licensing methods:
● Online: Licensing carried out via the internet or intranet on the back office
license server.
● Certificate/Dongle (including remote dongle engineering): Licensing carried out
via certificate files representing the license.
– For Dongle-bound licenses, dongles and licenses can be obtained
individually and subsequently tied to each other and loaded onto the PC.
– Engineering licenses are always dongle-bound. Where a physical
connection of the dongle to the PC is not possible, for example, during a
remote support session, the engineering license can still be used for a
limited time.
● Manual: Manually returning a license based on XML request/response files.
See Desigo CC Installation Manual (A6V10376166).
System Management The Desigo CC server hosts the System Management Console (SMC), a stand-
Console (SMC) alone tool which is installed on the main server only, and can only be launched
locally. Once Desigo CC is installed successfully, the field engineers must first
perform the typical system administration operations, such as configuring system
users, projects, and history database in the SMC, before being able to launch a
Desigo CC client.
Profiles, schemas and Client profiles define the appearance and behavior of the system functions involved
templates in event management, such as Summary Bar, Event List, Event Detail Bar, event
filters, and event treatment. Every project template has a matching client profile,
and every client profile has a matching event schema. To a ensure a consistent
configuration, the project template, the client profile and the event schema must
match.
Representative data points in Desigo CC can be created manually, imported
through data exchange files, or uploaded through a selective auto-discovery
mechanism depending on the type of system being connected. A unique,
extensible object modeling approach allows Desigo CC to normalize information

222 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Installation, Setup and Engineering
15

Subsystem integration brought in through any interface, and to provide the same look, feel, and operation
through a common set of applications, without concern for the source of the data.
Desigo CC lets you configure connected subsystems directly and perform typical
automation station functions, such as scheduling and event generation, at the
management platform for connected systems that do not support those functions
directly.
Desigo CC supports the following subsystems:
● Desigo Building Automation system (Desigo PX V5.1 SP; V6)
● Desigo Room Automation system (V1.16; V1.2)
● Simatic S7 (S7-300; S7-400)
● Siclimat-X V4.1
● Sinteso Fire Safety System (FS20 EN MP5.2; FS20 DE MP5.2)
● Sinteso Fire Safety System (STT20 Centralisateur de Mise en Sécurité
Incendie)
● Intrunet Intrusion System (SPC MP3.4, connections using TCP-IP or UDP-IP
supported)
● Video through Milestone Video Management System
● Mass Notification System (Version 2.0) For a list of compatible Mass
Notification devices, please refer to the MNS documentation
● Third-party Building Automation and Fire Safety systems based on BACnet/IP
● Third-party subsystems through OPC (OPC DA V2.05/V3.00 standard)
● Third-party subsystems through Modbus/IP
● Integration through SNMP
● APOGEE Building Automation system (Apogee BACnet V3.1.2; V3.2.4; V3.3;
V3.4)
● XNET FireFinder XLS and MXL fire safety systems (FireFinder XLS V8 and
newer)
● Desigo Fire Safety FS20 UL systems (FS20 UL MP1.x, MP2.0)
Auto discovery Auto discovery lets you discover and import devices, which are already on the
network, into Desigo CC. You can set filters and detect your devices on the
network, which then display in the System Browser. You would typically use this
method for existing jobs, where field panels are already installed and online.
OPC server OLE for Process Control (OPC) is a widely accepted industrial communication
standard that enables the exchange of data between multi-vendor devices and
control applications without any proprietary restrictions. OPC is a client-server
technology and Desigo CC can acts as the server providing data to third party
clients.
Web services Using RESTful technology, Desigo CC provides alarm, object and time series data
via web based services to supervision management platforms or other third-party
external applications.
Language packs The Desigo CC software is delivered in English and can be extended with
additional languages. The following software language packs are supported:
● Arabic
● Chinese (simplified)
● Chinese (traditional)
● Czech
● Danisch
● Dutch
● English (default)
● Finnish
● French

223 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 Graphics Libraries

● German
● Italian
● Korean
● Norwegian
● Polish
● Portugese
● Russian
● Spanish
● Swedish
● Turkish
You can install 3 languages simultaneously. Every user can define his user
interface language.
Project and HDB backup Backing up Desigo CC requires saving independent parts on different servers or
PCs. We recommend that you save the backups of your project data to a different
machine from where they originally reside.
Two parts must be backed up:
● The entire customer project data, including all libraries, configurations, object
data (project backup).
● The historic data collected in the history databases (HDB backup).
Backups can be done either manually or by applying a macro in combination with a
management platform scheduler.
See Desigo CC System Management Console (A6V10415497).

15.6 Graphics Libraries

Desigo CC contains libraries with symbols and graphic templates for easy plant
graphics engineering. The Graphic Library Browser shows all the available
symbols and graphic template objects in your project libraries.
Symbols A graphics symbol is a reusable graphic image that represents a piece of
equipment, floor, or any component or entity. Symbols are stored in a library and
are used to display system object values. Symbols can be associated with one or
more object types in the Models & Functions application and bound to object type
properties to create substitutions in your graphics that provide a dynamic, visual
representation of changing values from Desigo CC.
In its simplest form, a symbol is a graphic made up of drawing elements on the
graphic canvas in the Graphics Editor. Each drawing element has a series of
associated properties. These properties can be used to create substitutions.
Symbols can be associated with an object type
An object type is associated with a symbol in the Models & Functions application.
When you drag-and-drop the symbol onto a graphic, the symbol displays the
system object values in runtime mode and in the Graphics Viewer. Animation is
supported through a series of graphics. Pre-defined symbols are stored in library
folders. These symbols are visible and editable from the Graphics Library Browser.
Advanced users can create their own symbols.
Generic symbols A generic symbol is a concept that allows you to create one type of symbol that
can support an object that has one or several properties with changing values.
Depending on the object, the symbol will not display the elements of the graphic
that do not have a data point associated them.
Graphic templates Desigo CC provides standard BACnet TEC graphics for various applications. You
can also create template graphics for TEC applications.

224 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Graphics Engineering
15

Figure 175: Graphic templates

See Desigo CC Getting Started (A6V10415475) and Desigo CC User Guide

(A6V10415471).

15.7 Graphics Engineering

Desigo CC graphics are built using smart objects that know how they are used and
how to represent themselves graphically. Smart objects let you create graphics by
dragging objects onto a page, without manually binding an object to graphical
symbols.
The Graphics application allows you to create, view, store, and command large
graphics representing equipment, floors, buildings, facilities, and entire campuses.
These graphical representations can contain dynamic elements to represent
devices or values you want to monitor or control. The Graphics application consists
of:
● Graphics Viewer
● Graphics Editor
● Graphics Library Browser
Graphics Viewer The Graphics Viewer lets you view the graphics representing your facility or
equipment. You can change the current state of an object’s properties from a
graphic. You can filter your view of a graphic by discipline, section, or you can
zoom in and out for greater detail or for a birds-eye overview.
Graphics Editor The Graphics Editor lets you create dynamic graphical representations of your
plants, buildings or equipment. You can test and simulate your dynamic graphics
before going online with them.
See Desigo CC Graphics Editor (A6V10415487).

225 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
15 Virtual Environment

Figure 176: Graphics Editor

Graphics Library Browser The Graphics Library Browser lets you toggle between a view that displays all the
available symbols and graphic template objects in your project libraries.
AutoCAD import You can import AutoCAD drawings and select and manipulate the layers of the
AutoCAD drawings during and after the import process.

Figure 177: An imported AutoCAD drawing

15.8 Virtual Environment

Desigo CC is compatible with following Virtualization software packages:

226 | 377
Siemens CM110664en_03
2017-09-18
 Management Platform
Virtual Environment
15

● VMware®:
– Virtualization platform: VSphere 6.0
– Fault-tolerant software: ESXi 6.0b (build 2809209) managed by VCenter
Server Appliance v6.0.0 (build 2793784)
● Stratus®:
– Virtualization platform: KVM for Linux CentOS v7.0
– Fault-tolerant software: everRun Enterprise 7.2
– Virtualization platform: Citrix XenServer 6.0.2
– Fault-tolerant software: everRun MX 6.2 HotFix4 (build 6.2.9125.825-
HF:EA)

227 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
16 Virtual Environment

16 Automation Stations
The Desigo PX range is based on freely programmable automation stations. They
provide the infrastructure to accommodate and process system-specific and
application-specific functions. The PX range of automation stations comprises the
compact and modular series.
See Desigo PX - Automation system for HVAC and building services - System
overview (CM110756), Automation stations modular series PXC..D, PXC..-E.D,
PXA40-.. (CM1N9222) and Automation stations compact model PXC..D
(CM1N9215).

Control Functions
The D-MAP programming language lets you program and parameterize plants,
using function blocks and compounds. The graphics-based data-flow programming
in Xworks Plus (XWP) lets you implement all the necessary control strategies for
optimum operation.

System Functions
The distributed functions, which ensure the overall functioning and inter-operation
of all plants, are described in the following chapters and documents:
● For alarm strategy, see chapter Alarm Management.
● For time scheduling, see chapter Calendars and Schedulers.
● For access rights and user designations, see IT Security in Desigo Installations
(CM110663).
● For emergency operation and forced control, see chapter Control Concept.
● For wiring tests with Desigo Point Test Tool, see chapter Desigo Workflow,
Tools and Programming.

Cyclical Processing
One PX automation station contains one downloaded D-MAP program. A D-MAP
program cannot run on two automation stations, that is, there are no overlapping
programs across automation stations. A downloaded D-MAP program does not run
automatically. It must be started explicitly and is executed in accordance with the
cyclical processing principle, that is, all D-MAP blocks in an automation station are
processed in a repeating cycle.
Cycle time A minimum and maximum cycle time is defined for each automation station. If the
processing of all blocks is:
● Shorter than the minimum cycle time, the next processing cycle is delayed until
the minimum cycle time has elapsed.
● Longer than the maximum cycle time, the next processing cycle starts as soon
as possible.
The processing order of the individual blocks:
● Does not depend on their arrangement on the plan (D-MAP program)
● Can be set explicitly when creating the D-MAP program
Process image The values at the physical inputs and outputs are displayed in the automation
station via the process image. There are two instances of the process image:
● The frozen process image does not change during a processing cycle. D MAP
programs only read from or write to this instance of the process image.
● The active process image is continuously connected to the real plant.

228 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
Device Object
16

AI AO

Read Write

Frozen values
Process image
buffer
Current values

I/O scan

Figure 178: Process image

Values read in cycle 1 are processed in cycle 2. Output values calculated in cycle 1
are transferred to the peripherals in cycle 2.

16.1 Device Object

Each automation station contains a device object. The device object:
● Contains the device and system information for the automation station
● Is based on the standard BACnet object as defined in the BACnet standard,
and contains additional proprietary properties
● Is always present and is set up in the automation station with initial values
● Is not programmed in the CFC Editor as a function block and is not loaded with
the program
You can monitor property values through a BACnet client (for example, Desigo CC,
XWP). You can change default values. You cannot read changed values back into
Xworks Plus (XWP). When an automation station is replaced, you must reenter any
changes made to property values.

Figure 179: Common tab

229 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
16 Device Info Object

The serial number in the row Serial number SN=150120C61487 consists of:
● 15 = Year
● 01 = Month
● 20 = Day
● C = Hardware version
● 61487 = Consecutive number

Division into groups

The properties of the device object can be divided into groups based on category,
for example:
● BACnet communication and BACnet interoperability
● Global properties and system functions
● Local functions and settings
● Statistics and diagnostics
Properties for BACnet These properties ensure communication and interoperability between BACnet
communication and devices, and are specified in the BACnet standard, for example, Protocol version
interoperability [ProtVn] and Vendor name [VndrNam]. Individual properties such as Object
identifier [ObjId] are set up by XWP during the commissioning process on the
network side.
Global properties Individual properties of the device object are defined as global properties, because,
from the system perspective, all automation stations on one site must have the
same value. Global properties are only adjustable on the primary server.
Local properties The device object contains local properties, which are necessary for the
parameterizing and functional scope of global objects and for functions, such as life
check, time synchronization and the replication of global objects. Local properties
also include properties for the system status of the automation station, the time
stamp for the generation of the program and the setting of the buffer size of the
alarm queue.
These properties can be reviewed in the Online Properties window in the Network
Configurator or CFC Editor in XWP.
Properties for statistics These properties contain statistical and diagnostic information and can be
and diagnostics reviewed in the Online Properties window in the Network Configurator or CFC
Editor in XWP.

16.2 Device Info Object

The Device Info Object is a proprietary BACnet object and contains the alarming
function for the automation station.

230 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
Error Sources and Monitoring Functions
16

Figure 180: Alarming tab

Properties for system The device object has an alarm mechanism, because system alarms and system
alarms and system events events, which cannot be assigned to a data point, may occur in an automation
station. The alarm state machine and alarm-relevant connections are mapped to
the BACnet properties of the device object.

16.3 Error Sources and Monitoring Functions

There are various error sources, for example:

Error Effect
Memory error, for example, faulty flash memory Desigo PX stops working.

Battery failure Desigo PX continues working.

Failure of backup server recognized by primary server Desigo PX recognizes the fault and transmits the relevant alarm.

Table 61: Errors and effects

Non-critical errors / Non-critical hardware and software errors are identified by Desigo PX and
configuration errors registered as a device object alarm.
Critical errors When a critical hardware or software error occurs, the automation station tries to
restart. If the same error is detected three times within 15 minutes, the automation
station switches to the COMA operating state. If the Fault LED is lit, the automation
station is in the COMA operating state.
Online properties for The values in the Online Properties window in Xworks Plus (XWP) give clues about
diagnostics the operation of the automation station.

231 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
16 Operating States

Figure 181: Diagnostics tab

16.4 Operating States

A PX automation station has the following operating states:
● STOP: The D-MAP program is stopped.
● RUN: The D-MAP program runs.
● KOMA: The automation station is in a prolonged sleep mode.
The following figure shows the operating states and the associated transitions:

232 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
Operating States
16

1: Power failure 1: Power failure

Mains OFF

2: Power restored COMA 2: Power restored RUN

1: Power failure 2: Power restored STOP

STOP RUN

BACnet: Download
required

14: Load
BACnet: Operational

12: Reanimation
COMA 13: Master reset
4: RUN Cmd 15: Delta loading
BACnet: Operational
5: STOP Cmd

16: Delta loading

10: Fatal Error

11: Fatal Error 7: Restart 9: Reset 7: Restart 9: Reset

Figure 182: Operating states and transitions

Operating states
Mains off ● No power supply

STOP
● I/O scan active
● Ready for wiring test (only possible without D-MAP program loaded) (PXM20,
for PTM modules only)
● D-MAP program processing stopped
● Communication with XWP: Master reset, complete loading and delta loading
allowed
● BACnet communication with Desigo CC and PXM20: ReadProperty,
WriteProperty, Who-Has, COVs, EventNotification, AcknowledgeAlarm
GetEventInformation
● COVs: For values changed by the operator, values cannot be changed by the
program
● Alarming: Alarm monitoring inactive, no new alarms or events are generated
(the device info object can still generate alarms and system events).
Notification of saved alarms and events is possible if recipient lists are set up.
GetEventInformation and AcknowledgeAlarm possible.
● Primary server in the STOP state: Primary server is not active, that is, no life
check, no time synchronization and no replication of global objects
● Backup server in the STOP state: The backup server is not active, that is, no
time synchronization and no replication of global objects by primary server. The
backup server will not accept changes to global objects by a client.
RUN ● I/O scan active
● Wiring test not allowed
● D-MAP program processing active
● Communication with XWP: Master reset and complete loading not allowed,
delta loading allowed
● BACnet communication with Desigo CC and PXM20: ReadProperty,
WriteProperty, Who-Has, COVs, EventNotification, AcknowledgeAlarm
GetEventInformation.
● COVs: For values changed by the program and operator

233 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
16 Operating States

● Alarming: Alarm monitoring active, notification of alarms and events,

GetEventInformation and AcknowledgeAlarm
● Primary server in the RUN state: Primary server is active, that is, life check,
time synchronization and replication of global objects
● Backup server in RUN state: The backup server is active, that is, time
synchronization and replication of global objects by primary server. The backup
server does not accept changes of global objects by a client.
COMA ● I/O scan not active
● Communication with XWP not active
● BACnet communication not active
● Wiring test not possible
● D-MAP program processing stopped

Transitions
1 Power failure Power failure
2 Power restoration STOP Power restoration. Operating state before power failure was STOP.
Actions (cold start response):
● Cold start I/O scan: Default values for output modules
● Cold-start variable function blocks: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value.
The STOP state is reached when the I/O scan is finished.
3 Power restoration RUN Power restoration. Operational status before power failure was RUN.
Actions (cold start response):
● Cold start I/O scan: Default values for output modules
● Cold-start variable function blocks: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value.
● System event: Power restoration.
D-MAP processing starts when the first I/O scan is finished.
4 RUN Cmd Explicit command via dialog in XWP or BACnet (DeviceObject, Out of service
property [OoServ])
Actions (warm start action):
● Implicit warm start I/O scan: I/O scan continues to run
● Implicit warm-start variables function blocks: All variables retain their last value
● System event: Change to operating state
D-MAP processing starts.
5 STOP Cmd Explicit command via dialog in XWP or BACnet (DeviceObject, Out of service
property [OoServ])
Actions:
● System Event: Change to operating state
● Stop D-MAP processing at the end of current cycle
I/O scan continues.
6 Restart Restart of the automation station due to software error.
Actions (cold start response):
● Cold start I/O scan: Default values for output modules
● Cold start function block variables: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value.
The STOP state is reached when the I/O scan is finished.
7 Restart Restart of the automation station due to software error.

234 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
Operating States
16

Actions (cold start response):

● Cold start I/O scan: Default values for output modules
● Cold start function block variables: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value.
● System event: Restart
D-MAP processing starts when the first I/O scan is finished.
8 Reset Explicit reset of automation station via hardware push button.
Actions (cold start response):
● Cold start I/O scan: Default values for output modules
● Cold start function block variables: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value.
The STOP state is reached when the I/O scan is finished.
9 Reset Explicit reset of automation station via hardware switch.
Actions (cold start response):
● Cold start I/O scan: Default values for output modules
● Cold start function block variables: Volatile variables are initialized with initial
value. Non-volatile variables retain their last value
● System event: Reset
D-MAP processing starts when the first I/O scan is finished.
10, 11 Fatal Error Restart due to fatal error in the software or in the D-MAP program. Criterion: Same
error occurs three times within 15 minutes.
Actions (cold start response):
● Stop I/O scan If possible: Loss of hardware output values for compact and
modular automation stations
● Stop BACnet communication
● Stop XWP communication
D-MAP processing is stopped.
12 Reanimation Only possible by deleting the D-MAP program (press ForceFWDownload pin and
reset the automation station).
Actions (cold start response):
● Change of required operating state to STOP
● Cold start I/O scan: Default values for output modules
The STOP state is reached when the I/O scan is finished.
13 Master reset Deletion of D-MAP program on automation station with XWP.
● Cold start I/O scan: Default values for output modules
D-MAP program data including system and event queue is deleted.
14 Load Complete loading of a new D-MAP program.
● Before downloading, a master reset must be carried out.
Function block variables are loaded with initialized values.
15 Delta download D-MAP program changes are loaded.
16 Power restoration - Power restored. Operating state before power failure was COMA.
COMA Actions (cold start response):
● Stop I/O scan
● Stop BACnet communication
● Stop XWP communication
D-MAP processing is stopped.

235 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
16 Data Storage

Summary
Every time the automation station restarts (Powerfail, Reset) a cold start is carried
out.
The operating state is stored as a non-volatile variable.
The operating state is mapped as follows to the system status [SysSta] property of
the device object:

Operating mode System status property [SysSta]

STOP (no D-MAP program loaded) DOWNLOAD_REQUIRED

STOP (D-MAP program loaded) NON_OPERATIONAL

RUN (D-MAP program loaded) OPERATIONAL

Table 62: Operating modes and system status property [SysSta]

16.5 Data Storage

The following memory types are used in the automation station:
● RAM: The content is lost during a cold start. Read and write access is possible
any time without any special action.
● Battery supported RAM: Operating hours and trend data are preserved during
a cold start if the battery is loaded.
● Flash memory: The content is retained during a cold start. Read access is
possible at any time. Write access is only possible via a special driver and with
restrictions (access time, sequential only).
The data and code of a D-MAP program are saved in the flash memory during the
download process. A copy of the data is always stored in the RAM so that the D-
MAP program can access data efficiently for processing purposes. This means,
that all changes to the program data must be updated both in the RAM and in the
flash memory.
The following figure shows the various sequences:

236 | 377
Siemens CM110664en_03
2017-09-18
 Automation Stations
Data Storage
16

PXM20

XWP

D-MAP Communication
Application

Flash RAM

Figure 183: Data storage process

Downloading the D-MAP 1. The D-MAP program (code and data blocks) is copied to the flash memory (1a).
program A copy of the data blocks is created in the RAM (1b) for later modification by the D
MAP program.
Read/Write via 2. When writing data, the data is written to the RAM (2a) and the flash memory (2b).
communication system Read access to the data is via the RAM (2c).
Processing the D-MAP 3. The D-MAP program code is read from the flash memory (3a). The program data
program is modified in the RAM (3b). Non-volatile process variables (for example, adaptive
control parameters, hours run, etc.) are written by the function blocks into the flash
memory (3c) at regular intervals (once per day) or saved in the battery supported
RAM.

Starting the automation 4. At each restart of the automation station, a copy of the data (data blocks) is
station created in the RAM (4) from the flash memory (including all communication and D-
MAP changes).

237 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Data Storage

17 Logical I/O Blocks

I/O blocks are used to register and transmit raw data to and from the plant, and to
convert, process and integrate it into the program.
The following options are supported:
● Raw data from or to the input or output modules.
● Raw data from or to the PPS2 interface (room units) (not for Desigo S7 and the
modular series PXC…D)
● Data referenced via the Technical Designation (TD) and accessed either in the
same automation station (without a connection), or peer-to-peer via BACnet
services.
● Data made available via a Discipline I/O of a room automation station or third-
party device (not for Desigo S7).
The term I/O blocks refers collectively to the individual input blocks and output
blocks.
● Input blocks are used to enable an input signal (for example, a measured value)
in the program to be handled as a process value.
● Output blocks are used to enable a process value to be transmitted as an
output signal (for example, a positioning command).
Value blocks act as a link between program pins, and are used to temporarily store
a process value, and if necessary, to display it on a client operator station. A
special version of the value block, the Value block for operation provides a
simplified means of operation from an operator client (without the facility to override
values manually).
Counter Input blocks (CI blocks) are used to enable a counter value (for example,
from a gas or electricity meter) to be processed in the application as a real-number
process value. In this process, the counter value (pulse) is converted in the block
into the associated physical variable.
Integration I/Os (Discipline I/O blocks) are used, for example, to integrate room
automation or third-party devices

Input blocks Output blocks Value blocks Value blocks for operation
Analog Input (AI, AI RED) Analog Output (AO, AO RED) Analog Input (AVAL) Analog Input (AVAL_OP)

Binary Input (BI, BI RED) Binary Output (BO, BO RED) Binary (BVAL) Binary (BVAL_OP)

Multistate Input (MI, MI RED) Multistate Output (MO, MO RED) Multistate (MVAL) Multistate (MVAL_OP)

Counter Input (CI)

Accumulator (CI ACC)

Discipline I/O

Table 63: I/O blocks

Program view and system I/O blocks are displayed in two different views:
view ● The program view shows an I/O block with the pins and attributes required for
configuration purposes and to create the program. This is the display format
used in Xworks Plus (XWP).
● The system view shows the I/O blocks as standard BACnet objects. These
BACnet objects and the associated properties are then available to clients from
where they can be operated and monitored.
Desigo S7 In Desigo S7 the Step 7 Manager is used with CFC instead of XWP. PXM20
cannot be used. Use Desigo CC as a client.
All the blocks listed above are implemented in accordance with the BACnet
standard. Therefore additional functions are available, such as alarm management.
These blocks incorporate a mechanism which acts as an alarm source for blocks

238 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

BACnet functions available as standard BACnet objects in the BACnet network. By use of various
BACnet services, a given event is displayed as an alarm event on the relevant
clients from where the alarm can be processed, that is, viewed, acknowledged
and/or reset.
In XWP these functions can be tracked via the relevant values at the block pins in
online test mode.

17.1 General Functions

Blocks: AO, BO, MO, This section describes the general functional scope shared by many of the I/O
AVAL, BVAL, MVAL blocks. Each subsection includes a list of the blocks to which that subsection
applies. Any block-specific details which are not shared by other blocks are
described together with the block concerned.

Priority mechanism
Basic function In order to evaluate the various defined setpoints received from the BACnet
command system and via the data flow connections, the AO, BO, MO, AVAL,
BVAL and MVAL blocks each incorporate a priority array [PrioArr].
All external sources write their defined setpoint and information bit (enable signal)
into this [PrioArr]. The block then evaluates these entries continuously, in order to
determine the valid present value [PrVal].
The [PrioArr] holds up to 16 different entries, each consisting of a setpoint
definition and the associated information bit (enable signal). The input number also
indicates the priority of the entry, where 1 is the highest and 16 the lowest priority.
Each priority level has a predefined meaning.

Figure 184: Priority arrayx

Determining [PrVal] The block continuously evaluates the valid present value at the output [PrVal]. It
selects the value that has the highest priority of those whose information bit
(enable signal) is also set. If none of the information bits is set, the default value
[DefVal] is processed.
Structure of the Priority Each priority level has a predefined meaning.
Array [PrioArr] In the [PrioArr], two adjacent priority levels each are reserved for life safety,
manual operation and plant operation.

239 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

● The higher priority (lower number) of each pair is reserved for local control and
monitoring, close to the plant (priority 1, 4, 7 and 15).
● The lower priority (higher number) of each pair is reserved for higher level
control and monitoring (priority 2, 5, 8 and 16).
● Priority level 6 is specifically designed for switch-on and switch-off delays and
to maintain minimum ON and OFF times.
This ensures that, for example, an on-site EMERGENCY OFF command, initiated
at the plant level, takes priority over a safety function from a higher-level
subsystem.
Priorities 1, 4, 7, 15 Priority 6 Priorities 2, 5, 8, 14, 16
Local control Control within block Higher control
via data flow interconnection via BACnet command

AO BO MVAL
CMD_CTL

e.g. emergency stop

1 PWR_CTL
Life safety
2

3
e.g. anti-icing
ValCrit / EnCrit
protection
Critical value
5

6 Monitoring hours
7 Desigo CC
e.g. local manual Manual operation
switch ValOp / EnOp 8

13

14
Local control Program control
15 ValPgm / EnPgm

General BACnet command 16

PrVal

Figure 185: Structure of the Priority Array [PrioArr]

Priority 6 Priority entry 6 is used to forward the switch commands resulting from [PrioArr] to
the [PrVal] output after a delay. This enables you to implement both switch-on and
switch-off delays and minimum ON and OFF times.
For this purpose, the internal block logic imports the Present value [PrVal] into the
priority 6 entry. While the delay times referred to above are running, priority 6 is set
to active and so takes priority over priority levels 7…16. Outside these delay times,
priority 6 is always inactive.
Locating this function in the [PrioArr] between priorities 1…5 and 7…16 has the
following consequences:
● Commands with a priority level of 1…5 are always executed immediately,
irrespective of any currently active delay times.
● Commands with a priority level of 7…16 are always overridden by any currently
active delay times.
Unlike all the other entries in [PrioArr], the commands and information bit for
priority 6 are generated exclusively by the BO, MO, BVAL and MVAL blocks. A
priority 6 entry cannot be written from an external source.

240 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

The switch-on and switch- As soon as one of the commands with a priority of 7…16 determines the [PrVal]
off delay which will therefore cause the present state of [PrVal] to change, the entry for
priority 6 is set up as follows:
If the switch-on delay [DlyOn] or switch-off delay [DlyOff] is greater than 0:
1. Priority 6 adopts the still unchanged present value [PrVal].
2. Priority 6 is set to active.
3. The switch-on or switch-off delay timer starts.
4. After expiry of [TiOnMin] or [TiOffMin], priority 6 is set to inactive.
If the delay times [DlyOn] or [DlyOff] are equal to 0, no action is taken.
If the new value which determines [PrVal] is the same as the current [PrVal], then,
here too, no action is taken.
The minimum on/off time For each change at the output [PrVal] from OFF to Stage n or from Stage n to OFF,
the entry for priority 6 is set up as follows:
If the minimum ON-time [TiOnMin] or OFF-time [TiOffMin] is greater than 0:
1. Priority 6 adopts the new present value [PrVal].
2. Priority 6 is set to active.
3. The timer for the minimum on-time or off-time is started.
4. After expiry of [TiOnMin] or [TiOffMin], priority 6 is set to inactive.
If the minimum switch-times [TiOnMin] / [TiOffMin] are set to 0, no action is taken.
Constraints ● The functions described above are supported only by the BO, MO, BVAL and
MVAL blocks.
● With multistage switch commands, the monitoring periods are enabled only
when switching from OFF to Stage n or from Stage n to OFF. When switching
from one stage to another (for example, Stage 1 to Stage 2), the timer times
are not enabled.
● However, any timer times already running will continue to run.
Application ● Unnecessary on/off switching operations can be prevented by activating
minimum switch-on or switch-off times.
● Activating switch-on or switch-off delays ensures that run-on time delays are
maintained.
Information bit In order for a given value to be included in the evaluation of [PrioArr], its
information bit must be set.
The following applies to priority 1,4,7 and 15 (data flow connection): The relevant
information bit is set via pins [EnSfty], [EnCrit], [EnSwi] and [EnPgm].
The following applies to priority 2, 5, 8, 14 and 16 (BACnet command system):
When a given value is commanded via BACnet, the value concerned is entered in
the [PrioArr] and the associated information bit is set automatically.
The following applies to priority level 6: Both the value and the information bit are
handled by the block concerned.

Prio Meaning Use Access via

1 Safety value (life safety) Local safety function, for example: Data flow interconnection via pins:
Reserved for the initiation of safety - Fire [ValSfty] and [EnSfty].
functions (1 = highest priority). - EMERGENCY OFF Normally, [ValSfty] is a constant and
If priority 1 or 2 becomes the determining [EnSfty] can be enabled/disabled.
- Service switch
value for [PrVal], then the value
concerned is transmitted immediately to - Gas alarm
the [PrVal] output. It is not subject to the - Thermal package
delay times defined for priority 6.
2 Higher-level safety function, for example: BACnet command system.
- Smoke extraction Access via the CMD_CTL block.

3 Not used in Desigo.

241 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Prio Meaning Use Access via

4 Critical value (plant protection) Local monitoring of critical plant states, for Data flow interconnection via pins:
Reserved for monitoring critical plant example: [ValCrit] und [EnCrit].
states. - Frost protection (protection from excess Normally, [ValCrit] is a constant and
If priority 4 or 5 becomes the determining cooling) [EnCrit] is enabled/disabled.
value for [PrVal], then the value - Interlock of aggregates
concerned is transmitted immediately to - Icing protection
the [PrVal] output. It is not subject to the
5 delay times defined for priority 6. Higher-level monitoring of critical plant BACnet command system.
states: Access via the CMD_CTL block.
- Frost in ventilation system (close
dampers, stop fans, switch pump on and
open valve)

6 Minimum switch-on/off time No access!

Prevent unnecessary switching operations. Commands are only generated internally
Switch-on/off delay in the block.

Can be used to ensure that run-on delay times are implemented. The timer periods [TiOnMin], [TiOffMin],
[DlyOn] and [DlyOff] can be configured in
blocks BO, MO, BVAL and MVAL.

7 Operating value Local manual operation, for example: Data flow interconnection via pins:
Reserved for manual operation. - Manual switch [ValSwi] und [EnSwi].

- Mode selector switch

8 Higher-level manual operation, for BACnet command system. Access via:

example: - Desigo CC
- Desigo CC - Operating unit
- Operating unit - Web client
- Web client

9...13 Not used in Desigo.

14 Program value Superposed control and monitoring of the BACnet command system. Access is via
Reserved for normal plant operation with plant. blocks:
monitoring and control. - CMD_CTL
- PWR_CTL (if control enable signal =
Fixed)

15 Local control of plant. Data flow interconnection via pins:

[ValPgm] and [EnPgm].
If the program value is a controller
variable, then [EnPgm] = True and
[ValPgm] = controller variable.
If the program value is not a controller
variable, then [EnPgm] = False.

16 Program value BACnet command system. Access via

Reserved for general cross-PX blocks:
commands via BACnet references. CMD_CTL
PWR_CTL (if control enable signal is =
Released)
Cross-PX via various blocks, for example,
ASCHED, BSCHED, MSCHED (name
reference list).

17 Default value [DefVal] The influence of [DefVal] depends on the BACnet command system. Access via:
If none of priorities 1…16 is active, then state of the block concerned: - CFC
the default value [DefVal] is processed Out-of-service [OoServ=False]: - PXM20
instead. [DefVal], like the values of priorities - Web client
7…16, is subject to the delay times of
priority 6.
[OoServ=True]:
[DefVal] is transmitted immediately to the
[PrVal] output.

242 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

Table 64: Priorities

Example: Effect of
priorities 7...16 on [PrVal]

Figure 186: Effect of priorities 7...16 on [PrVal]

Prio Use
1 Prio 7…16 Assumption: The effective switch command from priority (7…16) is Off and is set to active.

Prio 6 Assumption: Priority 6 is not active.

[PrVal] Assumption: The [PrVal] output is set to Off.

2 Prio 7…16 The effective switch command from priority (7…16) switches from Off to Stage 2.

Prio 6 Priority 6 adopts the (still unchanged) present value [PrVal=Off] and is set to active.
At the same time, the switch-on delay [DlyOn] starts. Throughout the delay time, priority 6 remains active –
the associated value remains Off.

[PrVal] Since priority 6 overrides the effective switch command from priority (7…16), the [PrVal] output remains
Off.

3 Prio 7…16 n/a

Prio 6 1. After expiry of the switch-on delay [DlyOn], priority 6 is released.

2. The effective switch command Stage 2 from priority (7…16) is transmitted to the [PrVal] output.
3. Priority 6 adopts the new value of [PrVal] and is set to active again. At the same time, the minimum
switch-on time [TiOnMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal] The [PrVal] output changes from Off to Stage 2.

4 Prio 7…16 n/a

Prio 6 The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

243 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Prio Use
[PrVal] When priority 6 ceases to take effect, the [PrVal] output is once again determined by the effective switch
command from priority (7…16).
[PrVal] remains at Stage 2.

5 Prio 7…16 None of the information bits for priorities (7…16) is active.
The resulting switch command is therefore determined by the default value [DefVal].

Prio 6 The block starts the switch-off delay [DlyOff].

Throughout this monitoring time, priority 6 is set to active – the associated value remains at Stage 2.

[PrVal] Since priority 6 overrides the effective switch command [DefVal], the [PrVal] output remains at Stage 2.

6 Prio 7…16 n/a

Prio 6 1. After expiry of the switch-off delay [DlyOff], priority 6 is released.

2. The effective switch command Off from [DefVal] is transmitted to [PrVal].
3. Priority 6 adopts the new value of [PrVal] and is set to active again. At the same time, the minimum
switch-off time [TiOffMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal] The [PrVal] output changes from Stage 2 to Off.

7 Prio 7…16 n/a

Prio 6 The minimum switch-off time [TiOffMin] has expired. Priority 6 is released.

[PrVal] Since neither priority 6 nor any of the information bits for priority entries (7…16) is active, the effective
switch command is determined by [DefVal].
The output value [PrVal] remains at Off.

8 Prio 7…16 At least one of the information bits for priorities (7…16) is active again.
The effective switch command from priority (7…16) is Stage 1.

Prio 6 Priority 6 adopts the (still unchanged) present value [PrVal=Off] and is set to active.
At the same time, the switch-on delay [DlyOn] starts. Throughout the delay time, priority 6 remains active –
the associated value remains Off.

[PrVal] Since priority 6 overrides the effective switch command from priority (7…16), the [PrVal] output remains
Off.
9 Prio 7…16 n/a

Prio 6 1. After expiry of the switch-on delay [DlyOn], priority 6 is released.

2. The effective switch command Stage 1 from priority (7…16) is transmitted to the [PrVal] output.
3. Priority 6 adopts the new value of [PrVal] and is set to active again. At the same time, the minimum
switch-on time [TiOnMin] is started. Priority 6 remains active throughout this monitoring time.

[PrVal] The [PrVal] output changes from Off to Stage 1.

10 Prio 7…16 The effective switch command from priority (7…16) switches from Stage 1 to Stage 2.

Prio 6 The minimum switch-on time [TiOnMin] is still active.

Changeover from Stage m to Stage n.
With multistage switch commands, the monitoring periods are enabled only when switching from OFF to
Stage n or from Stage n to OFF. When switching from one stage to another (for example, Stage 1 to
Stage 2), the monitoring periods are not enabled. However, monitoring periods which have already started
remain active – priority 6 adopts the new target value.

[PrVal] A change from Stage 1 to Stage 2 would not activate priority 6.

However, since the minimum switch-on time [TiOnMin] is still active, priority 6 still overrides the effective
switch command from priority (7…16).
The [PrVal] output changes from Stage 1 to Stage 2.

11 Prio 7…16 n/a

Prio 6 The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

[PrVal] When priority 6 ceases to take effect, the [PrVal] output is once again determined by the effective switch
command from priority (7…16).
The [PrVal] output remains at Stage 2.

244 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

Table 65: Effect of priorities 7...16 on [PrVal]

Example: Effect of
priorities 1...5 on [PrVal]

Figure 187: Effect of priorities 1...5 on [PrVal]

Prio Use
1 Prio 1…5 Assumption: All information bits for priorities 1…5 are inactive.

Prio 6 Assumption: Priority 6 is not active.

[PrVal] Assumption: The [PrVal] output is set to Off.

2 Prio 1…5 At least one of the information bits for priorities (1…5) is active again. The effective switch command from
priority (1…5) is Off.

Prio 6 Since the effective switch command for priority (1...5) does not cause a change in the [PrVal] output,
priority 6 remains inactive.

[PrVal] The output value [PrVal] remains at Off.

3 Prio 1…5 The effective switch command from priority (1…5) switches from Off to Stage 1.

Prio 6 Priority 6 adopts the new present value [PrVal=Stage 1] and is set to active. At the same time, the
minimum switch-on time [TiOnMin] starts without waiting for the delay time [DlyOn].
Note: Entries for priorities (1…5) initialize only the minimum switch-on or switch-off times [TiOnMin] and
[TiOffMin] respectively, but not the switch-on and switch-off delays.
[TiOnMin] and [TiOffMin] times for which the timer has already started only take effect when all priorities
(1…5) are inactive, that is, when the [PrVal] will be determined by one of priorities (7…16).

[PrVal] Priorities 1…5 are reserved to implement safety functions, and are executed immediately, irrespective of
any priority 6 monitoring periods which may already be running.
The [PrVal] output is switched immediately from Off to Stage 1.

4 Prio 1…5 None of the information bits for priority entries (1…5) is active.

245 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Prio Use
Prio 6 The minimum switch-on time [TiOnMin] is still active. Priority 6 adopts the new target value from priority
(7…16).

[PrVal] The effective switch command is determined from priority 6.

The [PrVal] output changes from Stage 1 to Stage 2.

5 Prio 1…5 n/a

Prio 6 The minimum switch-on time [TiOnMin] has expired. Priority 6 is released.

[PrVal] Since neither priority 6 nor any entries for priorities (1…5) are active, the output [PrVal] is now again
determined by the effective switch command from priorities (7…16).
The [PrVal] output remains at Stage 2.
Note: Switching from Stage 1 to Stage 2 does not re-start the minimum switch-on time [TiOnMin].

6 Prio 1…5 Assumption: All information bits for priorities 1…5 are inactive.

Prio 6 Assumption: Priority 6 is not active.

[PrVal] Assumption: The [PrVal] output is set to Off.

7 Prio 1…5 At least one of the information bits for priorities (1…5) is active again. The effective switch command from
priority (1…5) is Off.

Prio 6 Since the effective switch command for priority (1...5) does not cause a change in the [PrVal] output,
priority 6 remains inactive.

[PrVal] The output value [PrVal] remains at Off.

8 Prio 1…5 The effective switch command from priority (1…5) switches from Off to Stage 2.

Prio 6 Priority 6 adopts the new present value, [PrVal=Stage 2] and is set to active. At the same time, the
minimum switch-on time [TiOnMin] starts without waiting for the delay time [DlyOn].
Note: Entries for priorities (1…5) initialize only the minimum switch-on or switch-off times [TiOnMin] and
[TiOffMin] respectively, but not the switch-on and switch-off delays.
[TiOnMin] and [TiOffMin] times for which the timer is already running only take effect when all priorities
(1…5) are inactive, that is, when the [PrVal] will be determined by one of priorities (7…16).

[PrVal] Priorities 1…5 are reserved to implement safety functions, and are executed immediately, irrespective of
the switch state and of any priority 6 monitoring periods which may already be running.
The [PrVal] output is switched immediately from Off to Stage 2.

9 Prio 1…5 The effective switch command from priority (1…5) switches from Stage 2 to Off.

Prio 6 Priority 6 adopts the new present value [PrVal=Off].

The still-running minimum switch-on time [TiOnMin] is cancelled.
The block re-starts the minimum switch-off time [TiOffMin].

[PrVal] Priorities 1…5 are reserved to implement safety functions, and are executed immediately, irrespective of
the switch state and of any priority 6 monitoring periods which may already be running.
The [PrVal] output is switched immediately from Stage 2 to Off.

10 Prio 1…5 All information bits for priorities 1…5 are inactive.

Prio 6 The minimum switch-off time [TiOffMin] is still active.

[PrVal] The effective switch command is determined from priority 6.

The output value [PrVal] remains at Off.

11 Prio 1…5 n/a

Prio 6 The minimum switch-off time [TiOffMin] has expired. Priority 6 is released.

[PrVal] Since neither priority 6 nor any entries for priorities (1…5) are active, the output [PrVal] is now again
determined by the effective switch command from priorities (7…16).
The output value [PrVal] remains at Off.

Table 66: Effect of priorities 1...5 on [PrVal]

Switch types [SwiKind]

Blocks: BO, MO, BVAL, MVAL

246 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

All switching I/O blocks have a configurable switching response. The switching
response determines the functioning of the block. The switching functions are
subject to the priority mechanism in the [PrioArr] and the switch command delay.
● Normal: Direct switching in stages taking into account runtimes (for example,
motors, burners, dampers, etc.).
● Motor: Switching in stages for rotating aggregates taking into account ramp-up
and ramp-down times (fan-belt protection).
● Trigger: Event-driven switching, last command takes precedence; integration of
a data point (EIB, LONMARK)
● Switch: Generation of an ON/OFF pulse of a defined duration.
● Push button with delay: Generation of an ON/OFF pulse of a defined duration.
The pulse can be extended whenever required.
● Release (Release Command): Issuance of a subsystem-specific release value
instead of Present_Value (=Relinquish_Default), if no priority is active in the
output object.

[SwiKind] BO MO BVal MVal

Normal • • • •

Motor •

Trigger • •

Switch • •

Pushbutton with delay • •

Release •

Table 67: I/O block switch types

Normal Normal handling of the process values in the [PrioArr]. The configured runtimes are
active. The outputs can be switched directly or in stages.

Figure 188: Control of a multistage aggregate without configured runtimes

Motor The Motor setting is used when there is a need to allow for ramp-up and ramp-
down times due to a rotating centrifugal mass. The programmed times in this
setting can be used, for example, to avoid overloading the fan belt when starting a
fan motor.
When the motor is switched down, the system checks on the basis of the ramp-up
time whether or not the current motor speed has been reached. The switch-down
command is not executed until the motor speed is stable. During the ramp-down
period, the effective command to the hardware is Off. When the ramp-down time
has elapsed, the new command is transmitted to the hardware.

247 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Figure 189: Control of a multi-speed motor with configured runtimes

Trigger In the Trigger setting, the source of the last command takes precedence. The valid
value is written from the [PrioArr] to the [DefVal] and transmitted to the output. The
priority is then released again.
In this setting, Priorities 7…16 are treated equally; Priorities 1…5 have a blocking
effect.
The trigger function is used, for example, for the integration of LON data points.
Owing to the event mechanism, this function is not used for P-bus objects.
Switch The Switch setting is used to generate an ON or OFF pulse of a predefined
duration. A command via BACnet, or the activation of an Enable signal in one of
Priorities 7…16 via the data flow connection initiates an associated pulse (event).
The minimum switch-on time [TiOnMin] and/or minimum switch-off time [TiOffMin]
must be set. Setting both times can prevent fast switching operations. Priorities
1…5 have a blocking effect.
Pushbutton with delay The Pushbutton with delay function is like the Switch function, except an active
(time extension) pulse can be extended by another pulse at any time.

Runtimes and monitoring periods

The I/O function blocks are designed for the runtimes and monitoring periods
required in HVAC engineering, and can therefore be used directly as components
(motors, dampers, fans, etc.).
Different runtimes and monitoring periods can be set, depending on the function
concerned.
Runtimes:
● Switch-on/off delay
● Minimum switch-on/off time
● Ramp-up/-down time
Monitoring periods:
● Feedback time with switch-on/off
● Feedback signal deviation during operation

Runtimes
Switch-on/off delay Blocks: BO, MO, BVAL, MVAL
The switch-on/off delay when applied to the switching I/O blocks causes a delayed
output if the switch command was written via Priority 7…16. The delay time affects
Priority 6 as described. Switch commands via Priorities 1…5 are executed without
a delay.
When applied to the switching I/O blocks, the minimum switch-on/switch-off time
causes the output to be blocked for a period of time if the switch command was
written via Priority 7…16. The minimum switch-on/off time affects Priority 6 as

248 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

Minimum switch-on/off already described in Section 24.2.1.3. However, switch commands via Priorities
time 1…5 are executed immediately irrespective of the minimum switch-on/off time.
Ramp-up/down time The ramp-up/down times (run-up/-down times) can be defined in a table for each
stage. These times apply to the two switch types [SwiKind] Normal and Motor.
The ramp-up time is the time taken by a motor when changing from a lower speed
to the next higher speed, to reach the new speed. This limits the current
consumption of the motor.
The ramp-down time is the time taken by the motor when switching down from a
higher speed, to reach the lower speed. This prevents feedback to the mains
supply network and protects the fan belt and the motor.
As a rule, the ramp-up and ramp-down times depend on the centrifugal mass
involved, and must be determined separately for each project.
Especially with single-speed motors, the times can be used as Open/Close
runtimes (for example, damper actuator from 0…100%). A moving damper can
thus be mapped in the system and the transition signal can, if required, be used for
control purposes.

Monitoring periods
Feedback monitoring / Blocks: BI, MI, BO, MO, BVAL, MVAL
process value monitoring The I/O objects have a monitoring function. The output objects monitor the
feedback signal from the plant. For this purpose, an address string must be
entered for the [FbAddr] feedback parameter [FbAddr] and the alarm function must
be enabled.
The input and value objects can monitor reference values. For this purpose, the
relevant reference values must be configured and the alarm function must be
enabled.
Deviation monitoring If the feedback value deviates from the output value [PrVal], a deviation alarm is
generated after a configurable time period, and the block status changes to In
Alarm. When the two values match again, and the configured time period has
expired, the alarm and status are reset. There is otherwise no automatic block
reaction, that is, if a switch response in the plant is required as a reaction to this
alarm, this response must be programmed in CFC via the Disturbance output
[Dstb].
Switch-on/off feedback It is also possible to configure the time period during which the maximum deviation
monitoring of the feedback signal may occur after a switch-on/off operation. If the deviation
persists after the monitoring time has expired, an alarm is generated and the status
of the block changes to In alarm. When the two values match again, and the
configured time period has expired, the alarm and status are reset. There is
otherwise no automatic block reaction, that is, if a switch response in the plant is
required as a reaction to this alarm, this response must be programmed in CFC via
the Disturbance output [Dstb].
No feedback monitoring If no feedback monitoring is required, and the address string is left blank, the
monitoring periods are used by the block for the internal generation of the transient
state [TraSta]. This means that the transient state signal for the switch-on/off
operation is set for the preset period of time. This is how a moving actuator, for
example, a damper, is displayed in the system.

249 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Figure 190: No feedback monitoring

Limit monitoring
Blocks: AI, AO, AVAL
In the case of the analog I/O blocks, the present value [PrVal] can be monitored for
a high/low limit. If the alarm monitoring feature is enabled, a deviation alarm is
generated after a configurable time period, and the block status changes to In
Alarm. When the present value is within the limits again and the configured time
period has expired, the alarm and status are reset. There is otherwise no automatic
block reaction, that is, if a switch response in the plant is required as a reaction to
this alarm, this response must be programmed in Xworks Plus (XWP) via the
disturbance output [Dstb].

Override via client

The input, output and value blocks can be overridden via BACnet clients or in XWP
(CFC) in online test mode.
User override of an input Desigo
value Management station Web client

PXM20 PXM40/50
BACnet clients

Forced Forced Forced Forced

value value value value

Desigo PX
BACnet service, e.g.
WriteProperty (Present value)

Input block

F orced v
alue Out of Service Present value
Default value State flag
Reliability
Online test mode
in PX Design

10523Z15en

Figure 191: Override of input blocks

250 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

There are two options:

1. Override via a BACnet client:
A BACnet client is overridden with a BACnet service.
Input objects are overridden by setting the out-of-service parameter [OoServ] and
writing the desired present value [PrVal]. The default value [DefVal] is
automatically set to the same value as [PrVal]. (You can also overwrite [DefVal], in
which case [PrVal] is automatically used instead).
There is no need to follow these rules when using the PXM20 to override a value,
as the operator unit observes them automatically.
Overridden input objects are not reset automatically. To do this, reset [OoServ] first.
[DefVal] remains at the last overridden value and [PrVal] is again derived from the
physical input.
2. Override via online test mode in CFC:
Overrides with CFC are carried out via a proprietary service.
Outputs of a block cannot be overwritten.
To overwrite [PrVal] the out of service state in [OoServ] must be set to TRUE, after
which the default value [DefVal] can be modified. This value is then adopted (or
applied) as the present value and is made available under [PrVal].

User override of an output Desigo

value Management station Web client

PXM20 PXM40/50

BACnet clients

Override Override Override Override

Desigo PX BACnet Service:

WriteProperty [PrVal], Value, [Prio]
WriteProperty [PrVal], NULL, [Prio]
ReadProperty [PrioArr]

Output or Value block

[PrioArr]
1
[OoServ] 2 [PRVal]
3
[DefVal] 4 [StaFlg]
Override 5
[EnOp] 6 [Rlb]
7
[ValOp] 8
9
[EnPgm] 10
Online test mode 11
in PX Design [ValPgm] 12
13
14
15
16 ValueEnable

10523Z14en

Figure 192: Override of output blocks

There are two options:

1. Override via a BACnet client:
The override of an output or value object is based on the priority array [PrioArr] in
the object. Priority 8 is reserved for the operator, that is, an override from the
PXM20 and Web client is written to the Priority 8 entry. Other BACnet clients can
write to other priority entries.
The value (Value or Null) is stored in the [PrioArr]. After processing in the object,
the value, other than NULL, with the highest priority is transmitted to [PrVal]. If
there is no active priority, the [DefVal] is transmitted.
2. Override via the online test mode in Xworks Plus (XWP):
[PrVal] is an output and can therefore not be modified. In this case the value under
[EnOp] must first be set, after which the modifiable value under [ValOp] is written to

251 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 General Functions

Priority 8 in [PrioArr]. After processing in the object, the value, other than NULL,
with the highest priority is then transmitted to [PrVal]. If there is no active priority,
the [DefVal] is transmitted.

Runtime totals
Runtime totalization can be implemented in the binary input, binary output and
multistate input and output blocks (BI, BO, MI and MO). Part of the overall range of
functions is defined by the BACnet standard. In order to provide the complete
range of runtime totalizing functions required in the field of building automation and
control, certain proprietary enhancements have been added here.

Figure 193: Runtime totals

Function With a binary input object, the operating hours are determined on the basis of the
ON state of [PrVal] (that is, by measuring the time for which this value is active).
For multistate blocks, you can configure how many states are to be totalized.
These are combined and added in a totalizer (the various states cannot be
evaluated individually). In contrast to the input object, the output objects of the ON
state for [FbVal] is logged (not [PrVal]) to operating hours message of the output
objects.
There are two separate totalizers for runtime totalization:
● Runtime totalizer
● Overall runtime totalizer
Release Runtime totalization can be enabled via the [EnOph] pin (Enable operating hours
count). This is a binary value for binary objects, for multistate objects a list of
values released for counting.
Runtime totalizer Maintenance messages (events) are generated via the runtime totalizers. These
are typically reset when the maintenance has been carried out. The present
operating hours [PrOph] output can be used to connect the runtime totalization
feature for further use in the program (for example, for changeover of pumps or
boilers based on operating hours).
Resetting the runtime total The operating hours [Oph] input is used to reset the current runtime total. In online
test mode in Xworks Plus (XWP) via a BACnet client the present value can be
reset by overwriting it with a new value (usually 0). This reset does not affect the
total operating hours count (pins [OphTot] and [PrOphTot], total operating hours
and present total operating hours respectively).

252 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
General Functions
17

Overall runtime totalizer The total operating hours count records the total hours run by an aggregate. It is
only reset when the aggregate is replaced. The [PrOphTot] output is available for
further interconnection in the program.
Resetting the operating The [OphTot] input is used to reset the total operating hours. In online test mode in
hours total Xworks Plus (XWP) or via a BACnet client, the present value can be reset by
overwriting it with a new value (usually 0). This reset procedure simultaneously
sets the runtime totalizer (pins [Oph] and [PrOph]) to the same value.
This is necessary, for example, for an aggregate which is installed as a
replacement item, but which has previously been in operation elsewhere for some
time.
Maintenance message A maintenance message (event) can be generated either after a specified period of
operation or on a specified date. The operating hours limit value and the
maintenance date [OphLm]/[MntnDate] can be configured for this purpose. An
event message is generated when the limit value is exceeded or at 13:00 hours on
the preset date. At the same time, the binary output [MntnInd] (maintenance
indication) is set to active for further use in the program. After the operating hours
reset, this output reverts to inactive. At the same time, the time stamp of the last
reset is stored in the time stamp operating hours reset pin [TiStmOph].
Feedback value The following applies to output blocks: When a feedback is configured, operating
hours count is done based on the feedback value and not based on present value.
The maintenance interval can be further connected via the output present total
operating hours limit [PrOphLm].
Value range for run time The hours run are registered in 32-bit format, giving a maximum value of
totalizing 4,294,967,296. With a resolution in seconds, this gives a value range of over
49,000 days (more than 136 years).

Out of Service [OoServ]

The physical input/output is disconnected from the I/O block via the out-of-service
pin [OoServ]. This out of service function is normally used in cases where a
hardware module is faulty or temporarily not required, for example, sensor not
connected or faulty. This is a way of suppressing reliability problems and the
associated FAULT alarms.
Input block If the out-of-service property of an input block is set [OoServ=True], the physical
input is disconnected from the present value ([PrVal] = [DefVal]) and any changes
in the physical input will not be transmitted to [PrVal]. Furthermore the reliability
[Rlb] and status flag [StaFlg] are also disconnected from the physical input. In this
state, the properties [PrVal] and [Rlb] can be modified for test purposes.
Output block If the out-of-service property for an output block is set [OoServ=TRUE], the
physical output is disconnected from [PrVal]. Changes in [PrVal] will not be
transmitted to the physical output, which retains its last value. Furthermore, the
reliability [Rlb] and status flag [StaFlg] are also disconnected from the physical
output. In this state, [PrVal] and [Rlb] can be modified for test purposes. Other
functions that depend on these properties are not dependent on the [OoServ]
property. The [PrVal] is set in accordance with the priority array [PrioArr], but the
value is not transmitted to the physical output.

Alarm and event functions

Each input, output and value block can be enabled and disabled as an alarm
source. The blocks are configured by setting the relevant values at the block pins.
See Alarm Strategy.

Reliability [Rlb]
The reliability of the present value and of the physical input/output is represented
by the reliability pin [Rlb]. This makes it possible to detect and signal faults and

253 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Input Blocks

errors, such as addressing errors, sensor problems (short-circuit or open circuit)

and module faults (missing or incorrect modules). See Reliability Table.

Commissioning State [ComgSta]

The state of the I/O can be entered at [ComgSta], the commissioning state pin, in
the commissioning phase. The setting does not affect the program; it merely
serves as a kind of notepad for commissioning purposes.
The following states are available for selection:
● Checked
● Not Checked [DefVal]
● Periphery Defect or Missing
● Cable Defect or Missing
● I/O Defect or Missing

As these states are static, they must be set manually during commissioning.

Status Flag [StaFlg]

The status flag [StaFlg] indicates the state of the I/O block. This pin consists of four
Boolean values:
● IN_ALARM: Logic 1 (TRUE) if the event state pin [EvtSta] does not display
NORMAL as its value.
● FAULT: Logic 1 (TRUE) if the [Rlb] pin does NOT display the value
NO_FAULT_DETECTED.
● OVERRIDDEN: Logic 1 (TRUE) if the block point was overridden locally (for
example, manual switch on I/O module). If this flag is set, [PrVal] and [Rlb] will
no longer display any changes in the physical input/output.
● OUT_OF_SERVICE: Logic 1 (TRUE) if the out-of-service pin [OoServ] is active.

Default Value [DefVal]

For an input block, [DefVal] is transmitted to [PrVal] when [OoServ] is set to TRUE.
For an output block, value [DefVal] is transmitted to [PrVal] when none of the
priorities (1…16) is active.

17.2 Input Blocks

An input block is used to enable an input signal (for example, a measured value) in
the program to be handled as a process value.

Analog Input (AI)

The analog input is the logical image, or memory map, of an analog measured
value and describes its properties. The raw data is converted and made available
in the form of a current value (Present Value) at the block output for further
processing within the program.
The following functions are integrated in the block:
● Conversion of the input signal with slope [Slpe] and intercept [Icpt].
● Interruption of input signal [OoServ] and replacement with [DefVal]
● Limit value monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)

254 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Input Blocks
17

Figure 194: Analog Input block

Processing and displaying The measured raw value is converted into the measured present value in
the current value accordance with a conversion curve. This present value is available at [PrVal] for
further processing within the program.
Slope/Intercept The conversion curve is a linear function which takes the following form:
[PrVal] = Raw value * Slope + Intercept
The values for slope [Slpe] and intercept [Icpt] must be defined specifically for the
application concerned in accordance with the I/O system in use and the signal type.
For slope and intercept values for SBT products, see Slope [Slpe] and Intercept
[Icpt]. For sensors not listed, the following applies:
Calculating [Slpe] and The values for [Slpe] and [Icpt], which are to be entered in the block, must first be
[Icpt] calculated. These values are derived from the individual [Slpe] and [Icpt] values of
the signal type and the signal transducer in accordance with the following formula:
[Slpe] = (Slope SignalType / Slope SignalTransducer)
[Icpt] = (Intercept SignalTransducer / Slope SignalTransducer ) + Intercept SignalType
[Slpe] is calculated on the basis of:
[Slp] = (InterpolationPoint_y2 – InterpolationPoint_y1) / (InterpolationPoint_x2 –
InterpolationPoint_x1)

Binary Input (BI)

The binary input block is the logical image, or memory map, of a binary switch
value and describes its properties. The parameters of the physical value are set via
the polarity [Pol], and the value is then available as the present value for further
processing. The Present Value is monitored for a given state. For commissioning
and test purposes, or in the event of an error, the Present Value can be dissociated
from the process and overwritten with a replacement value.
The following functions are integrated in the block:
● Inversion of the input value
● Interruption of input signal [OoServ] and replacement with [DefVal]
● Alarm value monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Runtime totalization and maintenance messages

255 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Input Blocks

Figure 195: Binary Input block

Multistate Input (MI)

The multistate input block is the logical image, or memory map, of several binary
switch values or a direct hardware multistate value, and describes its properties.
The multistate capability is achieved by interconnecting a number of individual
binary states. The binary states are evaluated and mapped as integers. Each
integer in the series is allocated a text label which is further processed and
interconnected within the program as a current value. For commissioning and test
purposes, or in the event of an error, the Present Value can be dissociated from
the process and overwritten with a replacement value. As an auxiliary function, the
runtime total for this multistate input can be registered and evaluated.
The following functions are integrated in the block:
● Interruption of input signal [OoServ] and replacement with [DefVal]
● Alarm value monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Runtime totalization and maintenance messages
● Hardware mapping

Figure 196: Multistate Input block

Pulse converter (pulse counter)

The pulse converter object cumulates pulses for a meter. The Pulse converter
object is used where meter values already manipulate in a meter object or where
changes of values are required to further process control programs. Applications
include: Establishing 24-hour/7-day/monthly meters, transmission by the minute of
meter values to peak load programs, etc. Precision and round off error based on
real arithmetic is possible.
The counter value is scaled as a REAL number directly in the object using the
scaling factor. COV forming the Present_Value can be value or time-related and a
timestamp with the logged time is always provided with the Present_Value.

256 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Output Blocks
17

Specific properties Reduction of Present_Value by a value (subtraction) is supported as a standard.

You can set it to a pre-defined value using a trigger function (proprietary
expansion).
The Pulse Converter object can be used in two different manners: Counting or
metering. The type of application is parameterized using the FnctMod parameter.
The referenced object, for example, an external device provides the pulse value:
● Present_Value for the pulse converter object represent the pulse count of the
referenced object: The difference to the last read value is added for each
record.
● Present_Value can be set via the system.
● After start-up, the pulse converter object encompasses the last stored counter
value:
● After a change in counter, the pulse converter object encompasses a false
counter value.
● Typical application: On-board I/O with pulse logging.
The referenced object, for example, an external device provides the absolute pulse
value:
● Present_Value from the pulse converter object represents the absolute counter
value of the referenced object.
● Under no circumstance may the Present_Value be set via the system.
● After start-up or a change in counter, the pulse converter object after includes
the correct counter value.
● Typical applications:
– Access to an accumulator or pulse converter object is another BACnet
device
– I/O Open module or M-bus with counter value integration
– Integration of a device via LON
● Incorrect applications: I/O module with pulse recording

Accumulator object (counter value)

The accumulator object can map counter states unchanged and free of errors due
to rounding off or add the counter pulse without loss and scale the same. The
accumulator object is suitable to displaying meter values that justify monetary
performance. For this type of counter values, manipulations such as monthly
values, etc., must never be made directly in the meter object.
The addition of counter pulses and scaling without loss is accomplished using
whole-number operations with residual value processing. The conversion of
physical pulses can be adapted using a presale parameter. The resulting
Present_Value is a scalable variable.
Present_Value depends on the function mode to synchronized adjustable to any
value using a physical meter with the last value prior to setting saved with a
date/time stamp.

17.3 Output Blocks

An output block is the logical image or memory map of a command, and describes
its properties. Within the program, the Present Value is made available to the block
as a program value. The block converts the program value and transmits the raw
data to the physical I/O.

If an output is deleted from an existing system in the course of a modification, the

I/O module will retain the last valid value which it received from the system. You
can return the I/O channel to the default status by switching the power off and on
again. This problem can be avoided by performing a complete download.

257 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Output Blocks

Binary Output (BO)

The binary output block is the logical image, or memory map, of a binary switch
command and describes its properties. Within the program it is made available to
the block as a program value, and its parameters are set via the "Polarity" pin. The
block converts this program value and transfers the raw data to the physical I/O,
where it is converted into a digital signal, for example, which drives the field device
via a contact.
The following functions are integrated in the block:
● Evaluation of the priority array [PrioArr]
● Inversion of the switch value and the feedback value (Polarity of feedback
[Bop])
● Interruption of the output signal [OoServ]
● Feedback monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Configurable switch types (Normal, Trigger, Pushbutton, Pushbutton with delay)
● Runtimes and monitoring periods
● Switch-command delays
● Process monitoring [StaFlg]
● Runtime totalization and maintenance messages

Figure 197: Binary Output block

Feedback monitoring for To monitor the damper position of dampers with one end switch, the switch
dampers with one end position must be set by defining the polarity of the feedback signal [Bop].
switch OPEN end switch -> Feedback polarity [FbPol] set to NORMAL
CLOSED end switch -> Feedback polarity [FbPol] set to INVERTED
Feedback monitoring for The monitoring of dampers with two feedback signals (Open/Closed) is
dampers with two end implemented via the address string of the Feedback Address [FbAddr]. The first
switches address in the string must be that of the end switch which indicates that the
damper is closed. The end switch indicating that the damper is open is set in the
second part of the address string.
Example with PX modular:

258 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Output Blocks
17

P= M1.K1; M2.K2 (D20)

● 1. 1st address: Damper-CLOSED switch
● 2. 2nd address: Damper-OPEN switch
● Feedback polarity [FbPol] NORMAL
M1.K1 = True; M2.K2 = False -> Feedback value: Closed
M1.K1 = False; M2.K2 = True -> Feedback value: Open
When the damper is being driven to the OPEN or CLOSED position, this transient
state [TraSta] is displayed. If the preset monitoring time is exceeded, an alarm is
initiated. If the damper fails to reach an end position, the alarm is reset again after
the monitoring time has expired. There is otherwise no automatic block reaction,
that is, if a switch response in the plant is required as a reaction to this alarm, this
response must be programmed in CFC via the disturbance output [Dstb].

Multistate Output (MO)

The multistate output is the logical memory map of a multi-state switching
command, and describes its properties. Within the program, the current value is
made available as a program value to the block and transmitted after conversion
into raw-data format to the physical I/Os. Here the raw data is converted into a
digital signal, for example, which drives the field device via a contact. It is also
possible to connect a multistate feedback signal, which is used for alarm evaluation.
The following functions are integrated in the block:
● Evaluation of the priority array [PrioArr]
● Interruption of the output signal [OoServ]
● Feedback monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Configurable switch type (Normal, Motor, Trigger)
● Runtimes and monitoring periods
● Hardware mapping (refer to Section 0)
● Runtime totalization and maintenance messages
● Process monitoring [StaFlg]

Figure 198: Multistate Output block

259 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Value Objects

Analog Output (AO)

The analog output is the logical image, or memory map, of an analog control
command and describes its properties. Within the program, the Present Value is
made available to the block as a program value. The block converts the program
value and transfers the raw data to the physical I/O, where it is converted into a
0…10 V signal, for example, to drive a field device.
The following functions are integrated in the block:
● Evaluation of the priority array [PrioArr]
● Interruption of the output signal [OoServ]
● Conversion of the process value and feedback signal with slope [Slpe] and
● intercept [Icpt]
● Configurable switch type (Normal or Trigger)
● Limit value monitoring (OFFNORMAL alarm)
● Deviation monitoring
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Process monitoring [StaFlg]

Analog Output

[PrioArr]
[PrVal]

[FbVal]

[FbVal] :=
Feedback Raw Value *Feedback Slope+ Feedback Intercept

If
[FbAddr]

Feedback_Raw_Value

Figure 199: Analog Output block

The value [PrVal] from the program is converted into the physical positioning value
by use of a conversion curve. This present value is then available at [PrVal] for
further processing in the program while at the same time, the raw data is
transmitted to the associated I/O system, where it is converted into an electrical
signal to drive the field device.
The conversion curve is a linear function which takes the following form:
Raw Value [RwVal] = [PrVal] * Slope + Intercept
The values for slope [Slpe] and intercept [Icpt] must be defined specifically for the
application concerned in accordance with the I/O system in use and the signal type.
For slope [Slpe] and intercept [Icpt] values for SBT products, see Slope [Slpe] and
Intercept [Icpt].

17.4 Value Objects

Value objects can be seen as virtual data points which are defined in the BACnet
standard and have the same functions as the I/O blocks.
● Analog value block
● Binary value block
● Multistate value block
The only difference, in the case of value blocks, is that it is not possible to define
physical connections to sub-components or components (for example, to I/O

260 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Value Objects
17

modules) in the plant. The value objects BVAL, AVAL and MVAL are used in the
program whenever BACnet-defined functions, such as commands, alarm
generation and runtime totalizing are required, or when a value is to be modified
via an operator unit. Value blocks look like all other blocks, and can be connected
with other blocks.
Typical applications Value objects are used typically in aggregates as command control links
(PWR_CTL or CMD_CTL). The command control mechanism passes the
commands to the value object and derives the status from the BACnet referencing
system.

A-Transport

Ag: V(A,C-F) Fan1St

FanEx
PltCtl Cp: CMD_CTL

OpSta

EnCrit
DmpShofEh Ag:DmpShof
EnCrit
CMD_CTL

On

FanSu
Ag: V(A,C-F) Fan1St
SmextPrg

En

OpSta
SmextEh Cp:BI

EnCrit
E,U
BI

SmextEh

DmpShofOa Ag. DmpShof

En

On/P14 Open/P14
ErcRo DmpShof

EnCrit
On
SmextSu Cp:BI
E,U
BI

SmextSu

En

On/P14
FireDet Cp:BI
E,U

EmgOff

EmgOff
BI

ManSwi Cp:Ml
On

MI
En

TSu
ValSfty
SpErcTSu EnSfty
Frost

BO

KickDmp

Dstb
En

Sequence table

ValPgm OpSta

EnPgm PrVal
M
E,H
On
OpModSwi Cp:MI
E,H

Ax: DMUX8_BO

En
OpMSwiCnv
MI

BVAL
En

AO

PrVal FbVal

PrVal
On
OpModMan
Cp:MVAL_OP
MVAL

En

ValSfty
En

TSu
O&M

EnSfty

KickDmp
BO

Dstb
Frost

ValPgm OpSta

TOa EnPgm PrVal

E,H
En

DefVal:Off
Sched
Cp:BSCHED

BVAL
On

AO
En

En

PrVal FbVal

PrVal

Figure 200: Use of the value blocks

261 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Value Objects

Furthermore, the value objects can be used for alarm monitoring (reference values
or high/low limit value), or to determine and monitor operating hours. The value
objects designed specially for operation via BACnet client can be used, for
example, as a simple way of enabling the user to operate setpoints and switch
commands.

Analog Value (AVAL)

The analog value block provides access to the dataflow, that is, to signals and pins
with a Real number as the data type. The value objects can be inserted into the
program structure and interconnected in any configuration.
This block is used when, for example:
● An alarm is to be created within the CFC chart as a commandable interface of
an aggregate (for example, limit monitoring of an output value of an aggregate).
● Access from the operator unit is required, in order to modify a value
The following functions are integrated into the block:
● Evaluation of the priority array [PrioArr]
● Interruption of the output signal [OoServ]
● Limit value monitoring (OFFNORMAL alarm)
● Deviation monitoring
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Process monitoring [StaFlg]

Binary Value (BVAL)

The binary value block provides access to the dataflow, that is, to signals and pins
with a Boolean number as the data type. The value objects can be inserted into the
program structure and interconnected in any configuration.
This block is used when, for example:
● An alarm is to be generated as the commandable interface of an aggregate (for
example, monitoring of logic operations)
● The hours run are to be totalized after a logic operation
● Access from the operator unit is required, in order to modify a value
● Configurable switch types (normal, switch, pushbutton with delay)
The following functions are integrated into the block:
● Evaluation of the priority array [PrioArr]
● Interruption of the output signal [OoServ]
● Process value monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Configurable switch types (normal, switch, pushbutton with delay)
● Runtimes and monitoring periods
● Switch-command delays
● Process monitoring [StaFlg]
● Runtime totalization and maintenance messages

Multistate Value (MVAL)

The multistate value block provides access to the dataflow, that is, to signals and
pins with a Multistate number as the data type. The value objects can be inserted
into the program structure and interconnected in any configuration.
This block is used when, for example:

262 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Value Objects for Operation
17

● An alarm is to be generated as the commandable interface of an aggregate (for

example, for limit monitoring)
● Access from the operator unit is required, in order to modify a value
● Hours run are to be totalized
The following functions are integrated in the block:
● Evaluation of the priority array [PrioArr]
● Interruption of the output signal [OoServ]
● Process value monitoring (OFFNORMAL alarm)
● Reliability monitoring [Rlb] (FAULT alarm)
● Change of state messages (events / system events)
● Runtimes and monitoring periods
● Runtime totalization and maintenance messages
● Process monitoring [StaFlg]

17.5 Value Objects for Operation

To simplify operation, use the value objects BVAL_OP, AVAL_OP and MVAL_OP.
The blocks are specifically intended for the operation of setpoints via BACnet
clients. They do not require a manual override from the operator unit. Value objects
look like all other blocks, and can be connected with other blocks. The blocks do
not include alarm generation or runtime totalization.

17.6 Addressing the I/O Blocks

Hardware independence Logical I/O blocks allow the standardization of the inputs and outputs irrespective
of the hardware. The relationship between a given logical I/O and its physical
equivalent is established by assigning the address of the I/O system concerned.
This independence has the advantage that the functions of the block, as defined by
the BACnet standard and the specific Desigo PX enhancements, do not change.
The number of different I/O systems or physical I/Os can be expanded freely.

Identical compound Another advantage is that the compound libraries are always identical. In the
libraries engineering phase, they are adapted to the I/Os in the project by assigning the
appropriate addresses. The process values (0…10V, 0…25mA, signal contacts,
etc.) from the connected field devices are registered directly at the physical inputs.
The physical outputs deliver the process values (0…10V, switching stages 0 / I /II /
III, etc.) directly to the connected field devices.
The process values are transmitted in the form of raw data via the relevant medium
(for example, PPS2); the conversion of the raw value takes place within the block.
Rules:
● Values from the plant are measured and processed in Input blocks (Analog,
Binary or Multistate).
● Values to the plant are processed and transmitted by Output blocks (Analog,
Binary or Multistate).
Program in XWP
10664-24Z01en

I/O module Block I/O module

Physical Logical Logical Physical
input input output output
AI BO
T R Island bus Island bus R

Figure 201: Addressing the I/O blocks

263 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing the I/O Blocks

I/O systems
To enable the process value of the logical I/O block to be allocated to the
appropriate physical I/O, the relevant address must be assigned. The address is
assigned as follows:
● Via automated assignment by the Point Configurator to the CFC
● Direct allocation to the I/O block in Xworks Plus (XWP)

Figure 202: Assigning the address

The logical I/O blocks are designed for universal use in various I/O systems. The
specific address structures and hardware definitions are determined by the I/O
system, for example, the failsafe control value for the island bus.
In Desigo, they are as follows:
● Physical I/Os
● Values in a Desigo room unit, accessible via the PPS2 interface (does not
apply to Desigo S7)
● Data in the same or in another automation station, referenced by its Technical
Designation and accessed without a connection, peer-to-peer via BACnet
services.
For addressing I/O from Desigo S7, see Desigo S7.

Address prefix
The addressing syntax indicates the origin of the raw value. The syntax must
correlate with the actual physical inputs.
The prefixes for the various subsystems are as follows:
● "T=" for TX-I/O modules on an island bus-capable automation station PXC....D
● "C=" for on-board I/Os of the Desigo PX compact automation stations
● "B=" for referencing to BACnet objects
● "Q=" for QAX room units
● "L=" for LonWorks addressing
● "S=" for Simatic S7 addressing
● "M=" for PX-OPEN addressing
● "D=" for PX Open Diagnostic Addressing
For addressing with "P=", see Addressing Entries for PXC…-U, PTM and P-Bus.
For addressing with "S=", "M=" and "D=", see the corresponding expert
documentation.
For more information on TX-I/O, see TX-I/O Assortment overview (CM2N8170) and
TX-I/O Functions and operation (CM110561).

Addressing entries PX Modular (PXC100/200..D)

For PX compact, the TX-I/O module at the [IOAddr] pin start with a "T" (prefix: "T=").
Address syntax:
T= Module.I/O point (signal type)
Example: T=2.1 (Y10S)

264 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing the I/O Blocks
17

The parameters no longer appear in the I/O address string for direct island bus
integration, but rather in the IOC (I/O configuration).
The only exception is the Info LED which must have the prefix "C=", because the
fixed address, 8.1, which is used for the Info LED may also be used by an I/O
module.
The Info LED for PX KNX and PX Open can also be addressed with C=8.1.
The following table shows the various address entries required when using the
modular series automation station in conjunction with TX-I/O-I/O modules.
Signal types shown in italics are used to map virtual modules for use with TX
OPEN at module level. Signal types AIS, AOS, DIS and DOS deliver a 16 bit value
with status information, while signal types AISL, AOSL, DISL and DOSL deliver a
32 bit value with status information. All other signal types deliver a 16/32 bit value
without status information.
While all the module types listed may be connected to any island bus addresses,
not all module types have 16 points.

Type Module addressing I/O point

Desigo TX-I/O 1...120 1...16

PX Info LED 8 1

Table 68: Addressing entries

Module type Signal type Example

Analog Input R1K, P1K, P100, U10, I25, I420 T=1.1 (R1K)
R2500, R250 (only TX-I/O)
T1, NTC10K, NTC100K (only TX-I/O)

AI, AIS, AIL, AISL T=2.1 (AIS)

Analog Output Y10S T=2.1 (Y10S)

Y250T T=3.1 (Y250T)

PWM

Y420 T=34.1 (Y420)

AO, AOS, AOSL, AOL T=36.1 (AOS)

Binary Input D20, D20S T=25.2 (D20)

D42, D250 (only PT-I/O)

DI, DIS, DIL, DISL T=26.3 (DIS)

Counter Input C T=38.1 (C)

Info LED Q_LED C=8.1(Q_LED)

Binary Output Q250_P, Q250A_P T=12.1 (Q250_P)

Q250 T=1.1 (250)

QD, Q250B, (only PT-I/O) T=14.1 (Q250) + T =15.1(D20)

DO, DOS, DOL, DOSL T=15.2 (DOS)

Multistate Input D20 T=1.1 (D20) + T=1.2 (D20)

D42, D250 (only PT-I/O) --

DI, DIS, DIL, DISL T=7.1 (DIS)

Multistate Output Q250-P1 ... Q-P5 T=1.1 (Q250-P3)

Q-M1 ... Q-M4 T=1.1 (Q-M3)

QD-M2 (only PT-I/O) --

DO, DOS, DOL, DOSL T=26.3 (DIS)

Table 69: Addressing entries

265 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing the I/O Blocks

Parameter values Parameters are entered in the I/O address editor.

See Automation stations modular series PXC..D, PXC..-E.D, PXA40.. (CM1N9222).

Addressing entries PX Compact (PXC…)

The addressing procedure is almost identical for Desigo PX compact and for
Desigo PX modular. However, the valid address ranges and signal types are not
the same as those used for the addressing of individual TX-I/O modules.
For PX compact, the "on-board" I/O modules at the [IOAddr] pin start with a "C"
(prefix: "C="). Address syntax:
C=Module.Channel (signal type, parameter)
Example: C=2.1 (Y10S, NO)
The table below shows the available address ranges and signal types, which vary
according to the Desigo PX compact automation station (each with its own
integrated, fixed configuration of I/Os) type.

PX compact up to PXC12.D PXC22.D PXC36.D Signal type

V4.0 PXC12-E.D PXC22-E.D PXC36-E.D
Module Channel Module Channel Module Channel
UI 1 1..4 1 1..12 1 1..18 R1K, U10, T1,
Universal Input UI5..UI8 UI5..UI16 UI7..UI24 N1K, P1K, C,
D20, D20S

– 2 – 2 – 2 –

DI 3 1..2 3 – 3 1..4 D20

Binary Input DI1..DI2 DI1..CI4

UO 4 1..4 4 1..4 4 1..6 Y10S, Q250

Universal Output AO1..AO4 AO1..AO4 AO1..AO6

DO 5 1..2 5 1..6 5 1..8 Q250

Binary Output DO1..DO2 DO1..DO6 DO1..DO8

Internal LED 8 1 8 1 8 1 Q-LED

PPS-2 1..5 1 1..5 1 1..5 1 R1K, U10, D20

Table 70: Addressing entries PX compact up to V4.0

Key:
1 Syntax for PPS-2 signal: Q = Room device number.object number (profile number). Up to five
devices can be connected.

PX Compact from Desigo The existing UI and AO can be configured as AI, DI, CI, or AO.
V5.0 Signal type of no application is loaded (wiring test):
PXC12..D, U1…U4: xx = Y10S, U5…U8: xx = R1K
PXC22..D, U1…U4: xx = Y10S, U5…U16: xx = R1K
PXC36..D, U1…U6: xx = Y10S, U7…U24: xx = R1K

PX compact from PXC12.D PXC22.D PXC36.D Signal type

V5.0 PXC12-E.D PXC22-E.D PXC36-E.D
Module Channel Module Channel Module Channel
UIO 1 1..4 1 1..12 1 1..18 R1K, U10, T1,
Universal I/O U5..U8 U5..U16 U7..U24 N1K, P1K, C,
D20, D20S

UIO 4 1..4 4 1..4 4 1..4 R1K, U10, T1,

Universal I/O with U1..U4 U1..U4 U1..U6 N1K, P1K, C,
Q250 D20, D20S, Q250

266 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing the I/O Blocks
17

Table 71: Addressing entries PX compact from Desigo V5.0

DO1

U1 U2 U3 U4 U9 U10 U11 U12 U17 U18 U19 U20

HMI / TOOL

U5 U6 U7 U8 U13 U14 U15 U16 U21 U22 U23 U24

Figure 203: Layout of PXC36D housing with address ranges

See Automation stations, compact model PXC..D (CM1N9215).

Multiple use of sensors

Multiple use of I/O signals Multiple use by addressing the physical I/Os in two or more logical I/O blocks (as
shown in the following figure) is not allowed.
Program in XWP

Block

AI
I/O module Island bus

T R
10664-24z02en

AI
Island bus

Figure 204: Avoid this multiple use configuration

If you wire it as in the figure above, Xworks Plus (XWP) determines multiple use
and generates an error message.
For the multiple use of output blocks, the plant will malfunction, because there will
then be two or more sources acting on one switching command. The effective
switching command (at the output) is the last one received (determined by the rule
"the last command takes precedence"). In other words, the order of processing
determines which source or origin will be linked to the output.
In CFC the same address can be allocated to two or more input or output blocks.
This multiple address allocation goes undetected when the program is compiled;
the automation station also fails to recognize the error (a reliability error is
generated and an error message is transmitted only in the case of multiple address
allocation with two different signal types).
Solution 1 Many systems include a requirement for the multiple use of sensors. A typical
example of this is an outdoor air temperature sensor shared across systems. The
following example illustrates the simplest form of the multiple use of sensors:
In CFC the current value is transmitted for further use in the program by
interconnecting the blocks. The logical I/O block (Analog Input, {AI}) occurs in the
program once only, and its hardware-specific parameters only need to be set once.

267 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing the I/O Blocks

10664-24z03en
Block
I/O module

Analog input

Figure 205: Multiple use via data flow

Solution 2 The multiple use function can be implemented with a BACnet reference to the first
analog input block (Partial plant 1). In other words, the first block will receive the
island bus address at the [IOAddr] pin. The second analog input block (Partial plant
2) references the first AI (B=…) via the technical designation.

Figure 206: Multiple use via BACnet reference

Addressing multistate I/Os

Multistate input The multistate value is made up of several separate binary measured values.
Addressing is via the input/output address [IOAddr]. In both the modular and the
compact series, the logical and physical I/O must be "located" in the same
automation station, but they do not need to be contiguous (for example,
C=5.1;5.3;5.5;5.6(Q250) is valid). The addressing cannot extend across
automation stations. The addresses must be on the same module for TX-I/O.
For information about adressing multistate I/Os with PTM, see Addressing
Multistate I/Os with PTM.
Simple mapping Syntax: T=Module.I/O point;Module.I/O point;Module.I/O point;Module.I/O point
Examples:
● T=1.1
● T=1.1;1.2
● T=1.1;1.2;1.3
● T=1.1;1.2;1.3;1.4
● T=10.3
Up to four binary status values (for example, Off/St1/St2/St3/St4) can be registered.
The signals to be registered, which are addressed via Module.Channel, must
always be of the same hardware signal type. With the simple mapping procedure,
to enable the multistate input to interpret the current binary signals correctly, only
one binary signal may be present at any one time. If several binary signals are
present at once, this is displayed as an error at the [Rlb] pin.

268 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing the I/O Blocks
17

The examples below show a possible application for multistate input blocks in
conjunction with the physical I/O modules. The example on the left of the diagram
is a multiple I/O module, while the one on the right shows the mapping of several
individual I/O modules in one multistate input block.
Multistate output The multistate value from the program is converted in the Multistate Output block
into a switching command. Addressing is via [IOAddr]. For PX modular, the syntax
is as follows:
Syntax: T=Module.channel
Examples:
● Q-M1: T=1.1
● Q-M2: T=1.1
● Q-M3: T=1.1
● Q-M4: T=1.1
● Q250-P3: T=10.1
● DOS: T=24.7
Values with up to four stages can be processed. The signals to be registered,
which are addressed via Module.Channel, must always be of the same hardware
signal type. In the case of a multistate output on the hardware side, there is one
address only (this is only possible with PXC modular automation stations).
Error handling If an automation station does not support a given address (for example, incorrect
syntax) or a given I/O system, this will lead to a reliability error, which will be
displayed at the [Rlb] pin.
Advanced mapping The manual switch can be encoded on the PX Compact in various ways, for
(Multistate Input) example:
● (Auto/Off/On) or (Off/Auto/On)
● (Auto/Off/S1/S2) or (Off/Auto/S1/S2)
So avoid having to keep adapting the data types and text groups in the system, the
manual switch must always be represented in the same way within the system:
● (Auto/Off/On)
● (Auto/Off/S1/S2)
A prerequisite for this approach is that it must be possible in the multistate input
block to configure the hardware coding and mapping to the standardized manual
switch. This is made possible with parameters in the address.
1_n-Mapping (Multistate Syntax:
Input and Output) T = Module.channel
C=Module.channel;Module.channel;Module.channel;Module.channel (signal type,
a,b,c,d,e)
a represents [PrVal] for HW-I/O (0,0,0,0)
b represents [PrVal] for HW-I/O (1,0,0,0)
c represents [PrVal] for HW-I/O (0,1,0,0)
d represents [PrVal] for HW-I/O (0,0,1,0)
e represents [PrVal] for HW-I/O (0,0,0,1)
Example: T=2.1
For the TX I/O addressing no additional information in the address string is added.
All information (signal type, mapping table, mapping rules, for example, up-down,
etc.) is configured in the I/O Address Editor and loaded in the automation station
with the IOC file.
Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 3, 4, 5)

269 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing the I/O Blocks

[PrVal] Addr1 Addr2 Addr3 Addr4 Comment /

Text group
2 0 0 0 0 Off

1 1 0 0 0 Auto

3 0 1 0 0 Stage 1
4 0 0 1 0 Stage 2

5 0 0 0 1 Stage 3

Table 72: Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 3, 4, 5)

Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 5, 7, 9) ;-- with holes

[PrVal] Addr1 Addr2 Addr3 Addr4 Comment /

Text group
2 0 0 0 0 On

1 1 0 0 0 Off
5 0 1 0 0 Comfort

7 0 0 1 0 Eco

9 0 0 0 1 StandBy

Table 73: Example: C=2.1;2.2;2.3;2.4 (D20, 2, 1, 5, 7, 9) ;-- with holes

UpDown Mapping Syntax:

(Multistate Input and Application: Connecting/disconnecting further stages.
Output)
Example: Electric heating registers, multi-stage burners.
T=Module I/O point
C=Module.channel;Module.channel;Module.channel;Module.channel (signal type,
UPDOWN)
Example: T=2.1
For the TX I/O addressing no additional information in the address string is added.
All information (signal type, mapping table, mapping rules, for example, up-down,
etc.) is configured in the I/O Address Editor and loaded in the automation station
with the IOC file.
Example: C=5.1;5.2;5.3;5.4(Q250,UPDOWN)
Example: C=2.1;2.2;2.3;2.4(D20,UPDOWN)

[PrVal] Addr1 Addr2 Addr3 Addr4 Comment /

Text group
1 0 0 0 0 Off

2 1 0 0 0 Stage 1

3 1 1 0 0 Stage 2

4 1 1 1 0 Stage 3
5 1 1 1 1 Stage 4

Table 74: Example: C=5.1;5.2;5.3;5.4(Q250,UPDOWN) and C=2.1;2.2;2.3;2.4(D20,UPDOWN)

With Up/Down mapping, more than one hardware input or output may be active.
Binary Mapping (Multistate Application: Output of an integer in binary form.
Input and Output) Example: Binary electric heating coil.
Syntax: C=Module.channel;Module.channel;Module.channel;Module.channel
(signal type, BINARY)
Example: C=5.1;5.2;5.3;5.4(Q250,BINARY)

270 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing the I/O Blocks
17

Example: C=2.1;2.2;2.3;2.4(D20,BINARY)

[PrVal] Addr1 Addr2 Addr3 Addr4 Comment /

Text group
1 0 0 0 0 Off
2 1 0 0 0 Stage 1

3 0 1 0 0 Stage 2

4 1 1 0 0 Stage 3

5 0 0 1 0 Stage 4
6 1 0 1 0 Stage 5

...

16 1 1 1 1 Stage 15

Table 75: Example: C=5.1;5.2;5.3;5.4(Q250,BINARY) and C=2.1;2.2;2.3;2.4(D20,BINARY)

With binary mapping, more than one hardware input or output may be active.

BACnet addressing
Peer-to-peer Data can be exchanged via peer-to-peer communication.
communication The exchange takes place using the BACnet services defined in the BACnet
standard. The process employs mechanisms engineered in CFC which can be
tracked in online test mode, but which are based on BACnet objects and BACnet
services.
Engineering When engineering the exchange of data in CFC, it is important to take note of the
following:
● Addressing is via [IOAddr].
● Data is exchanged only between BACnet objects. The attributes of the I/O
blocks and pins must be defined appropriately, and the information must also
be made available in the form of a BACnet object. For this purpose, the
attributes of this block or I/O must be defined correctly.
● In BACnet terminology, the I/O block is a client which fetches the required
value from an object defined as the server. This process is carried out using
services defined by BACnet, for example: The client subscribes to the relevant
object (the server) using the SubscribeCOV service. The server then supplies
the value via the BACnet service COVReporting whenever it changes by the
programmed value, COVIncrement. ReadProperty (polling) is another BACnet
service. Here, the value is read at regular predefinable intervals.
● Addressing is carried out via the Technical Designation (TD). Note, however,
that this Technical Designation must first be made known to the client in the
form of a reference address.
● The data is exchanged both within a given automation stations, and across
automation stations.
Address syntax Addressing takes place via the input/output address [IOAddr] and always starts
with the prefix "B=".
The BACnet reference address is the same as the Technical Designation (TD) of
the value. The BACnet addressing syntax is as follows:
B=BACnetReference (BACnetConfig)
Example: B=Geb6'Lft3'FanSu'Mot'MntnSwi.PrVal(0)
Polling or COV procedure The FB variable PollCyc is used instead of the prior BACnetConfig parameter in
the I/O address syntax, to distinguish between COV or polling:
FB variable IOAddr. FB variable PollCyc
BACnetConfig = 0 -> COV (Change of Value)

271 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing the I/O Blocks

BACnetConfig = 1…65535 -> Polling in seconds

In an automation station operating as a BACnet device, the maximum number of

simultaneously supported COV subscriptions is limited to 400.

The BACnet Device as BACnet Server supports a maximum of 400 subscriptions

from BACnet clients or from other BACnet devices via the BACnetReference.
A BACnet device operating as a BACnet client can also accommodate a maximum
of 100 subscriptions to other values via the BACnetReference.
If the COV procedure is selected, COVIncrement is used for analog objects to
define the value by which the present value must change to initiate a COV event.
Data output using Output objects can write their Present_Value to the properties of other objects or
WriteProperty command other value or output object.
Write without priority: Optional address string-Par(P=Number) no available.
Command with priority: Optional address string-Par(P=Number) available.
COV across sites The value subscribed to must be available in the same BACnet network. Avoid a
COV across sites.
The DeviceID is used to access and subscribe freely to values in different BACnet
devices (especially in the case of third-party integration). The syntax is as follows:
B=[DeviceID]Objectname – where the object name can be any string required. The
DeviceID is entered in decimal (instance number or entire ObjectID).

PPS2 addressing
A PPS2 address is required when values are to be transmitted via the PPS2
interface. Addressing takes place via the input/output address [IOAddr] and always
starts with the prefix "Q=".
Address syntax Up to five room units can be connected to one Desigo PX automation station and
addressed via the PPS2 interface. The addressing syntax is as follows:
Q=RoomUnitNumber.Object(Profile)
Example: Q=1.40 (1)
The functions available in the room unit are mapped directly to the I/O blocks. The
following elements of the address are predefined:

Type (standard BACnet objects) Room unit Object Object description Profile1 Example
number
Analog input 1…5 24 Setpoint correction – Q=1.24

Analog output 1…5 24 Setpoint correction – Q=2.24

Analog input 1…5 40 Room temperature 0, 1…6 Q=1.401

Analog output 1…5 195 Room temperature display – Q=5.195

Multistate input 1…5 205 Mode – Q=4.205

Multistate output 1…5 205 Mode – Q=2.205

Multistate output 1…5 206 Heating/Cooling display – Q=3.206

Table 76: Predefined address elements

Key:
1 The Profile relates to the configuration number shown in the next table.

The room unit is configured with this configuration number and appended to the
Room temperature object. Other objects are not assigned a configuration number.

272 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing the I/O Blocks
17

Only the relevant operating and process values are mapped in the I/O blocks,
rather than all objects of a room unit.
Six profiles have been defined to keep both the memory requirements and the
demands placed upon the user in practice to a reasonable level. If no profile
information is supplied, the predefined device-specific default value [DefVal] is
used. As an exception in the case of the QAX units, Profile No. 5 is used.

Configuration Profile
1 2 3 4 5 6

Enable operating mode

StandBy ON ON ON ON ON ON

Auto ON ON ON ON ON ON

Fan1 ON ON ON ON ON ON

Fan2 OFF OFF ON ON ON ON

Fan3 OFF OFF OFF OFF ON ON

KonfLCD

Symbol Standby ON ON ON ON ON ON

Symbol Auto ON ON ON ON ON ON

Symbol Fan1 ON ON ON ON ON ON

Symbol Fan2 OFF OFF ON ON ON ON

Symbol Fan3 OFF OFF OFF OFF ON ON

TempUnit °C °F °C °F °C °F

Table 77: Room unit profile

This profile (or configuration number) is always valid for one room unit only. It is
used to configure the objects ConfigLCD and EnableOperatingMode and to define
how the room unit is to operate (for example, °C or °F).
In principle, the profile can be attached to any other object.

This configuration applies only to the QAX33.1 and QAX34.1 room units.

Configuration of the object ConfigLCD is only relevant in the case of the QAX34.1,
as this is the only unit with a display in °C or °F.
The configuration of the object EnableOperatingMode is only relevant in the case
of the QAX33.1 or QAX34.1, as only these two room units have the option of
selecting Fan1, Fan2 or Fan3.
Where QAX units without an address switch are still in use, only one room unit per
automation station can be integrated. The room unit number in such cases is then
"1".

LonWorks addressing
There are two ways to integrate data points from LonWorks devices:
● via Discipline I/O
● via standard inputs/outputs (the latter approach is only sensible with a small
number of data points to be integrated, for example, from third-party devices)
Address syntax The block registers the control variables and output variables of the RX devices
(outside the CFC chart) in accordance with the information in the [IOAddr] property
(Input/output address).
Addressing starts with the prefix "L=".

273 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Discipline I/Os

Addressing via discipline L=DeviceType DeviceNo. GroupIndex(MappingTableNo.)

I/O ● DeviceType: M (Master), S (Slave)
● DeviceNo: Field device identification number
● GroupIndex: Group identification: Up to 4 similar groups of an application unit
may exist in the field device (for example, lighting or window-blind groups). The
group index number is optional.
● MappingTableNo: Number of the mapping table which is valid for that
Discipline I/O.
More than one device can be specified for each [IOAddr] string. The devices are
separated with a semicolon. However, the maximum [IOAddr] string length of 60
characters must not be exceeded.

Desigo RXC DeviceType DeviceNo GroupIndex MappingTableNo Example

RXC14 M 1…255 – 1…99 L=M14;M27(4)
RXC27

RXC5 M 1…255 – 1…99 L=M5;M11;M22;M109(91)

RXC11
RXC22
RXC109

RXC13 M/S 1…255 1…4 1…99 L=M13.2;S17.2(9)

RXC17

Table 78: Addressing via discipline I/O

Addressing via standard L= DeviceType DeviceNo.GroupIndex(3RD[NVIndex.FieldIndex])

I/O ● DeviceType: M (Master). There are no slaves (S) with third-party devices There
is only ever one device.
● DeviceNo: Field device identification number
● GroupIndex: Group identification: Up to 4 similar groups of an application unit
may exist in the field device (for example, lighting or window-blind groups). The
group index number is optional.
● ObjectType: Constant for third-party devices: 3RD.
● NVIndex: Network variable referenced in the third-party device.
● FieldIndex: Element number, if the network variable is structured

Desigo RXC DeviceType DeviceNo GroupIndex ObjectType NVIndex FieldIndex Example

e.g. RXC 26 M 1…255 1….4 3RD 1…255 1…32 L=M26(3RD[4.1])

Table 79: Addressing via standard I/O

KNX addressing
You can integrate data points from KNX devices as follows:
● See PX KNX, RXB integration - S-Mode (CM1Y9775)
● See PX KNX, RXB/RXL integration - Individual addressing (CM1Y9776)
● Address Info LED for PX KNX: D=1001

17.7 Discipline I/Os

Discipline I/Os are standardized combinations of inputs and outputs related to a
specific application. They have a predefined number of parameters.
Three different input variable types can be interconnected to Discipline I/Os:

274 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Reliability Table
17

● Simple value
● Trigger value
● Commandable value
Simple value The input value can be connected via the data flow. In the engineering tool, this is
preceded by a function block or compound, for example, a Scheduler. However, if
the input value is not connected, it can also be modified via BACnet client. The
subsystem registers a change in the input value by comparing the value with the
process image and transferring it to the field devices.
Trigger value This input value is the logical image, or memory map, of an analog positioning
command and describes its properties. Within the program, the Present Value is
made available to the block as a program value. The block transfers the program
value to the subsystem, from where it is transmitted to the field device.
Writing to this value acts as a trigger. This makes it possible, for example, to
generate the output of the same value (for example, Lighting 100%, followed later
by 100% again). In this case the subsystem registers the trigger value and
transmits the value to the devices. This capability is required when the same
variable can be modified from several sources (for example, when Desigo CC
writes 100.0%, the local operator unit writes 0.0% and the Desigo CC user wants
to rewrite the value of 100.0%). The sources can be BACnet clients or system
function blocks.
Only analog trigger values may be used.
Commandable value The input value is the logical image, or memory map, of an analog positioning
command and describes its properties. Within the program, the Present Value is
made available to the block as a program value. The block transfers the program
value to the subsystem, from where it is transmitted to the field device.
The commandable value is based on the BACnet priority-mechanism (which is the
same as for the output blocks – refer to Section 0). A commandable value can be
operated from various sources. Each source has its own priority. The sources are
mutually exclusive (interlock). The source with the highest priority prevails. for
example, Emergency = Priority 1, Façade control = Priority 6, Operator = Priority =
8). The sources can be BACnet operator units or system function blocks (grouping
function).
Only analog commandable values can be used.

17.8 Reliability Table

Value (decimal) Text
0 No error recognized.

1 No sensor.

2 Above the range.

3 Below the range.

4 Continuous loop.

5 Short circuit.

6 No output.

7 Unreliable other.

8 Process error

9 Multistate fault.

64 Subsystem not supported.

65 Subsystem feedback not supported.

66 Invalid address (syntax error).

275 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Reliability Table

Value (decimal) Text

67 Invalid feedback address (syntax error).

68 Invalid address value.

69 Invalid feedback address value.

70 Invalid address parameter (syntax error).

71 Invalid feedback address parameter (syntax error).

72 Invalid address parameter value.

73 Invalid parameter value for feedback address.

74 Destination device unknown.

75 Feedback device unknown.

76 Destination object unknown.

77 Feedback object unknown.

78 Unsuitable destination type.

79 Unsuitable feedback type.

80 Unreliable destination object.

81 Unreliable feedback object.

82 Invalid subsystem (syntax error).

83 Invalid feedback subsystem (syntax error).

84 Memory full.

85 Unreliable target device.

86 Communication failure reported in subsystem.

87 Alarm in subsystem application.

88 Maximum BACnet references reached for device.

89 Reliable participant.

90 Feedback error reported in binary output.

91 Invalid reference: Address not valid.

92 Reference object cannot be commanded.

93 Actual operating mode not found in command list.

94 Invalid priority set for command (valid : 2,4,14,16).

95 Invalid object number configured in sequence table.

96 Invalid object type configured in sequence table.

97 Invalid step control configured in sequence table.

98 Neighboring object not reachable.

99 Command lists indicate different variables.

100 Invalid calendar reference.

101 Configured switch kind not supported by destination controller.

102 Multistate mapping error.

Table 80: Reliability table

Signal types in the automation station which are not supported also generate
reliability error message 72.

276 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Slope [Slpe] and Intercept [Icpt]
17

17.9 Slope [Slpe] and Intercept [Icpt]

[Slpe] and [Icpt] value exist for:
● I/O modules (PX Modular and PX Compact)
These values impact signal type (the I/O module).
● Siemens field devices
These values affect the combination of Slpe and Icpt values for the signal type,
the field device and its measurement and positioning range. XWP automatically
enters these values, and they can be changed there, for example, to consider
the line resistance of a sensor or to describe a third-party sensor.
● BACnet referencing
● PPS2 interface
The combined values [Slpe] and [Icpt] can be calculated as follows from individual
values for signal type (I/O module) and characteristic curve (field device):

Figure 207: Slope and intercept

Siemens Building Technologies field devices: XWP automatically enters the

combined values [Slpe] and [Icpt] (for the signal type, the field device and its
measurement or positioning range) on the I/O block.
Third-party field devices: You can calculate the value [Slpe] and [Icpt] using the
Intercept Calculator.

[Slpe] and [Icpt] Analog Input

TX- and PT-I/O modules In the Desigo PX modular automation stations, the analog input block is used with
PX modular the following TX-I/O and PT-I/O modules:

277 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Slope [Slpe] and Intercept [Icpt]

Signal type Description Standard measuring Resolution on the Value range on the [Slpe] [Icpt]
measurement range bus bus
R1K LG-Ni 1000 -50 … 150 °C 1/100 °C -5000 ... 15000 0.01 0

P100 Pt100 0 … 250 Ohm 1/100 Ohm 0 ... 25000 0.01 0

R250 Resistance 0 … 250 Ohm 1/100 Ohm 0 ... 25000 0.01 0

Pt100_4 Pt100 -50 ... 600 °C 1/100 °C -5000 ... 40000 0.01 0

P1K Pt1000 0 … 2 500 Ohm 1/10 Ohm 0 ... 25000 0.1 0

R2K5 Resistance 0 … 2 500 Ohm 1/10 Ohm 0 ... 25000 0.1 0

T1 PTC sensor -50 ... 150 °C 1/100 °C -5000 ... 15000 0.01 0

Ni1K LG-Ni 1000 -50 ... 180 °C 1/100 °C -5000 ... 18000 0.01 0

Pt1K375 Pt1000 (NA) -50 ... 180 °C 1/100 °C -5000 ... 18000 0.01 0

Pt1K385 Pt1000 (EU) -50 ... 600°C 1/100 °C -5000 ... 60000 0.01 0

NTC10K NTC sensor -40 ... 115 °C 1/100 °C -5000 ... 11500 0.01 0

NTC100K NTC sensor -40 ... 125 °C 1/100 °C -5000 ... 12500 0.01 0

U10 DC 0 ... 10V 0 … 10 Volt 1/1000 V 0 ... . 10000 0.001 0

I420 DC 4 ... 20mA 4 … 20 mA 1/1000 mA 4000 ... 20000 0.001 0

I25/020 (Shunt 200 DC 0 ... 25mA 1 … 5 mA 1/1000 V 0 ... 5000 0.001 0

Ohm)

I25/020 (Shunt 100 DC 0 ... 25mA 0 … 10 mA 1/500 V 0 ... 5000 0.002 0

Ohm)

I25/020 (Shunt 50 DC 0 ... 25mA 0 … 20 mA 1/250 V 0 ... 5000 0.004 0

Ohm)

I25/020 (Shunt 40 DC 0 ... 25mA 0 … 25 mA 1/200 V 0 ... 5000 0.005 0

Ohm)

I25/020 TX-I/O* DC 0 ... 20mA*) 0 ... 20 mA* 1/1000 mA 0 ... 20000 0.001* 0

U10 (Shunt 400 DC 0 ... 25mA*) 0 ... 25 mA* 1/1000 V 0 ... 10000 0.0025* 0
Ohm) TX-I/O*

Table 81: TX- and PT-I/O modules PX modular

Key:
* TX-I/O modules support only 0 ... 20 mA. For a range of 0 ... 25 mA, use the shunt for 400 Ohm
(0.1%, 1 W) and measure the voltage with U10.

I/O configuration PX The analog input block is used in the Desigo PX Compact PXC10 TL to PXC52
Compact automation station in cases where an LG Ni1000 sensor (signal type R1K) or DC
0…10 V (U10) is connected to device terminals X1…X16 of Module 001.
The following information results:

Signal type measurement Description Standard measuring range [Slpe] [Icpt]

R1K LG-Ni 1000 -50…150 °C 0.01 0

U10 DC 0…10V 0…10 Volt 0.001 0

Table 82: I/O configuration PX Compact

BACnet referencing Reference to a value in another BACnet object. As the referenced value is already
available as a converted or resulting value, no conversion is required, that is, [Slpe]
must be defined as 1 and [Icpt] as 0.
The measured value from a room unit connected via the PPS2 interface. In the
analog input block, only Objects 24 (setpoint correction) and 40 (room temperature)

278 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Slope [Slpe] and Intercept [Icpt]
17

PPS2 interface may be used. As the value is already available as a converted or referenced value,
no conversion is required, that is, [Slpe] must be defined as 1 and [Icpt] as 0.

[Slpe] and [Icpt] Analog Output

I/O modules PX modular In the PX modular automation stations, the analog output block is used with the
following signal types:

Signal type positioning Description Standard measuring range [Slpe] [Icpt]

Y10S DC 0…10 V 0 … 10 V 100 0

Y420 DC 4…20 mA 4 … 20 mA 160 4000

Y250T (P-bus)* Three-point AC 24…250 Volt 2.55* 0

Y250T (Island bus)* Three-point AC 24…250 Volt 100* 0

Table 83: I/O modules PX modular

Key:
* Value [Slpe] for Y250T is not a physical value, but rather a special code controlling output of the
AO to two relay outputs. This code differs between P-bus and island bus.

I/O configuration PX The analog output block is used in the PX compact automation stations, when
Compact valves or actuators with DC 0…10 V control signals, signal type Y10S, are
connected to device terminals Y1…Y8 of Module 004.

Signal type positioning Description Standard measuring range [Slpe] [Icpt]

Y10S DC 0…10 V 0 … 10 V 1000 0

Table 84: I/O modules PX Compact

PPS2 interface Transfer of an analog control command to a room unit connected via the PPS2
interface. Only Object 195 (= Room temperature display) can be used in the analog
output block. As the value is already available as a converted or referenced value,
no conversion is required, that is, [Slpe] must be defined as 1 and [Icpt] as 0.

Line resistance with [Icpt]

For analog inputs (measurement of temperatures or resistances), most signal types
are calibrated at a line resistance of 1 Ohm. The [Icpt] can be changed at the AI
block if the line resistance deviates strongly from 1 Ohm.

Line resistance [Slpe] [Icpt] Delta slope Delta intercept

P1K (Pt1000)

0 Ohm 0.0259740 -259.480519 0 0.259740

Default = 1 Ohm 0.0259740 -259.740260 0 0
2 Ohm 0.0259740 -260.000000 0 -0.259740
3 Ohm 0.0259740 -260.259740 0 -0.519481

R2K5
P1K (0...2500 Ohm)

0 Ohm 0.1 1 0 1
Default = 1 Ohm 0.1 0 0 0
2 Ohm 0.1 -1 0 -1
3 Ohm 0.1 -2 0 -2

279 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Slope [Slpe] and Intercept [Icpt]

Line resistance [Slpe] [Icpt] Delta slope Delta intercept

R250

0 Ohm 0.01 1 0 1
Default = 1 Ohm 0.01 0 0 0
2 Ohm 0.01 -1 0 -1
3 Ohm 0.01 -2 0 -2

R250
P100 (0...250 Ohm)*

0 Ohm 0.01 0 0 0
Default = 1 Ohm 0.01 -1 0 -1
2 Ohm 0.01 -2 0 -2
3 Ohm 0.01 -3 0 -3

Table 85: Measuring resistances (internal resolution = 1/10 Ohm)

Key:
* PT-I/O modules P100 is a four-wire type Default line resistance = 0 Ohm
Line resistance not compensated

TX-I/O modules with Pt100_4 is a four-wire type Default line resistance = 0 Ohm
island bus integration Line resistance not compensated

R250 is a two-wire type Default line resistance = 1 Ohm

TX-I/O modules with Pt100_4 is a four-wire type Default line resistance = 0 Ohm
BIM integration Line resistance not compensated

R250 is a two-wire type, but must Default line resistance = 0 Ohm

be connected to four terminals
using bridges

Line resistance [Slpe] [Icpt] Degrees per Ohm Degrees per Ohm
Pt 1K 385 3.85 0.259740

0 Ohm 0.01 0.259740

Default = 1 Ohm 0.01 0
2 Ohm 0.01 -0.259740
3 Ohm 0.01 -0.519481

Pt 1K 375 3.75 0.266667

0 Ohm 0.01 0.266667

Default = 1 Ohm 0.01 0
2 Ohm 0.01 -0.266667
3 Ohm 0.01 -0.533333

Ni1K 5 0.2

0 Ohm 0.01 0.2

Default = 1 Ohm 0.01 0
2 Ohm 0.01 -0.2
3 Ohm 0.01 -0.4

280 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Slope [Slpe] and Intercept [Icpt]
17

Line resistance [Slpe] [Icpt] Degrees per Ohm Degrees per Ohm
T1 9.57 0.104450 -50...0 °C
10.39 0.096246 0...50 °C
11.31 0.088417 50...100 °C
12.36 0.080893 100...150 °C

0 Ohm 0.01 0.096246

Default = 1 Ohm 0.01 0
2 Ohm 0.01 -0.096246
3 Ohm 0.01 -0.192493

Pt100_4

Pt100 is a four-wire type, default line resistance = 0 Ohm

-> Line resistance is not compensated

Table 86: Measuring temperature (internal resolution = 1/100 °C)

Power surges on U10 inputs

The U10 inputs are designed for DC 0 ... 10 V with a narrower high / low tolerance
range. The input reports an error when a value is stored that outside this range. A
transient voltage suppressor can prevent an error message. A faulty response from
the analog signal supplied by the automation station can no longer be detected.

BSG61

0 ... 5 V

U10 U10 U10

10563A22

Zener diode Voltage divider Active setpoint adjuster BSG61

(Datasheet CE1N1992)

Slope must be adapted to 0...5 V Switch position 1 (Setpoint limit

(0.01 -> 0.005) control) Setpoint 100%
Precision resistance, for
example, VISHAI MBB/SMA
0207

Table 87: Solution examples

[Icpt] and [Slpe] for BT devices

Note for all U10 inputs The physical inputs are designed for 0 -10V with narrow high and low tolerance
limits. If a value falls outside this range, the input transmits an error signal.
However, provided it is established that the peripheral devices are in order, an
error signal can be prevented by using a transient voltage suppressor (10 V Zener
diode and two resistors). A faulty response from the analog input signal supplied
cannot subsequently be detected in the automation station.

281 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing entries for PXC…-U, PTM and P-Bus

Figure 208: Example of a circuit including the QAF64 which transmits more than 10 volts

17.10 Addressing entries for PXC…-U, PTM and P-Bus

Addressing entries PX modular (PXC…-U)
For the PX modular series, the P bus I/O modules at the Input-Output address pin
[IOAddr] start with the prefix: "P=".
Address syntax: P= Module.Channel (Signal type, parameter)
Example: P=2.1 (Y10S,15)
The exception is the Info LED which must have the prefix "C=" because the fixed
address 8.1, which is used for the Info LED may also be used by an I/O module.
Info-LED for PX KNX: D=1001.
The following table shows the various address entries required when using the
modular series automation station in conjunction with TX-I/O modules.

Type Module addressing I/O point or channels

Desigo TX-I/O 1...120 1...16

Desigo PT-I/O 1...255 1...8

PX Info LED 8 1

Table 88: Addressing entries

Module type Signal type Parameters Example

Analog Input R1K, P1K, U10, I25, - P=1.1 (R1K)
I420
P100
T1 (only TX-I/O)

AI, AIS, AIL, AISL - P=2.1 (AIS)

Analog Output Y10S NO, KEEP P=2.1 (Y10S, KEEP)

0...30 P=2.1 (Y10S,15)

282 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing entries for PXC…-U, PTM and P-Bus
17

Module type Signal type Parameters Example

Y250T 1...13, 1...13 P=3.1 (Y250T,8)
P=3.1 (Y250T,8,10)

Y420 - P=34.1 (Y420)

AO, AOS, AOSL, AOL P=36.1 (AOS)

Binary Input D20, D20S - P=25.2 (D20)

D42, D250 (only PT-I/O)

DI, DIS, DIL, DISL - P=26.3 (DIS)

Counter Input C - P=38.1 (C)

Info LED Q_LED - C=8.1(Q_LED)

PX KNX: D=1001

Binary Output Q250_P, Q250A_P 0, 1...600 P=12.1 (Q250_P)

Q250 - P=1.1 (QD)

QD, Q250B, (only PT- P=14.1 (Q250)
I/O)

DO, DOS, DOL, DOSL - P=15.2 (DOS)

Multistate Input D20 Binary - Mapping P=1.1;1.2 (D20)

D42, D250 (only PT-I/O) Updown - Mapping

1:n - Mapping

Multistate Output DI, DIS, DIL, DISL P=7.1 (DIS)

Q250 Binary - Mapping P=1.1;1.2;1.3 (Q250)
Q250B, QD (only PT- Updown - Mapping
I/O)
1:n - Mapping

Q250_P3 0, 1...600 P=1.1 (Q250_P3,120)

Q-M3 - P=1.1 (Q-M2)

QD-M2 (only PT-I/O) P=1.1 (QD-M2)

DO, DOS, DOL, DOSL - P=26.3 (DIS)

Table 89: Addressing entries PX modular (PXC...-U)

Signal types shown in italics are used to map virtual modules for use with I/O
OPEN at module level. Signal types AIS, AOS, DIS and DOS deliver a 16 bit value
with status information, while signal types AISL, AOSL, DISL and DOSL deliver a
32 bit value with status information. All other signal types deliver a 16/32 bit value
without status information.
While all the module types listed may be connected to any P-bus addresses, not all
module types have 16 channels.
Parameter values Parameter values for the analog output, binary output and multistate output blocks:
Y10S Failsafe function (emergency control function) if the transfer of data over the P-bus
fails (for longer than 4 seconds) or in the event of a power failure. (an operating
voltage of AC 24 V must be available).
NO -> Module output signal goes to 0 V.
KEEP -> Module output signal remains at previous value.
0...30 -> Module output signal 0 = 0 V, 1 = 0.33 V, etc. , … 30 = 10 V.
Y250T 1…13, 1…13 Runtime ranges for On/Off signals (the ranges do not need to be the
same for On/Off). Values 1…13 correspond to the following runtimes:
1 = 8.5 ...13 seconds
2 = 13 ... 18 seconds

283 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing entries for PXC…-U, PTM and P-Bus

3 = 18 ...25 seconds
4 = 25 ...35 seconds
5 = 35 ... 48 seconds
6 = 48 ... 66 seconds
7 = 1.1 ... 1.6 minutes
8 = 1.6 ... 2.3 minutes
9 = 2.3 ... 3.2 minutes
10 = 3.2 ... 4.5 minutes
11 = 4.5 ... 6.3 minutes
12 = 6.3 ... 9.0 minutes
13 = 9.0 ... 11 minutes
The PTM1.2Y250T(-M) module can only implement one runtime. It therefore uses
the opening-command runtime for closing commands.
Q250_P, Q250A_P, 0, 1…600 -> Pulse times, where 0 = 0.5 seconds and then 1 = 1 second, 2 = 2
Q250_P3 …. seconds etc. up to 600 (=600 seconds).
Pulse times for island bus applications:
Values in the I/O address editor: 0...255 (corresponds to 0...25.5 seconds)
Default = 5 (corresponds to 0.5 seconds).

Addressing entries PX Compact (PXC…)

The addressing procedure is almost identical for Desigo PX compact and for
Desigo PX modular. However, the valid address ranges and signal types are not
the same as those used for the addressing of individual P-bus I/O modules.
For PX compact, the on-board I/O modules at the [IOAddr] pin start with a "C"
(prefix: "C=").
Address syntax: C=Module.Channel (Signal type, parameter)
Example:C=2.1 (Y10S, NO)
The table below shows the available address ranges and signal types, which vary
according to the Desigo PX compact automation station (each with its own
integrated, fixed configuration of I/Os) type.

Desigo PXC10-TL1 PXC12 PXC22 PXC36 PXC52 Signal

PX PXC12-T PXC22-T PXC36-T type
compact
Module Channel Module Channel Module Channel Module Channel Module Channel
Uni- 1 1…4 1 1…6 1 1…8 1 1…12 1 1…16 R1K,
versal X1…X6 X1…X8 X1…X12 X1…X16 U10, D20
Inputs T1, P1K,
(UI: for N1K
AI, DI)

Digital 2 1…4 – – 2 1…4 2 1…4 2 1…4 D20, C

Inputs D1…D4 D1…D4 D1…D4
(DI)
(Counter
Input)

Digital 3 1…4 – – – – 3 1…8 3 1…12 D20

Inputs D5…D12 D5…D16
(DI)

Analog - - 4 1…4 4 1…4 4 1…6 4 1…8 Y10S

Outputs Y1…Y2 Y1…Y4 Y1…Y6 Y1…Y8
(AO)

Digital 5 1…2 5 1…2 5 1…6 5 1…8 5 1…12 Q250

Outputs 51…54 51…56 51…58 51…62
(DO)

284 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing entries for PXC…-U, PTM and P-Bus
17

Desigo PXC10-TL1 PXC12 PXC22 PXC36 PXC52 Signal

PX PXC12-T PXC22-T PXC36-T type
compact
Module Channel Module Channel Module Channel Module Channel Module Channel

Manual – – – – – – 7 1…4 – – D_M3

switch2
(only
PXC36-
S)

LEDs 8 2…5 – – – – 8 2…7 – – Q_LED

Info LED 8 1 8 1 8 1 8 1 8 1 Q_LED

PPS-2 3 1..5 3 1..5 3 1..5 3 1..5 3 1..5 R1K,

signal3 U10, D20

PXC52 1 1…16 D20, C

from X1…X16 R1K,
Desigo 4 1…8 U10, D20
V54: Uni- Y1…Y8 T1, P1K,
versal N1K,
Inputs / Y10S
Outputs

Table 90: Addressing entries PX compact (PXC...)

Key:
1 For PXC10-TL the two Alarm1/2 buttons and the DIL switches1/2 are mapped to the modules
with the Address 3.
2 The manual switch can only be loaded into the application if the DIL switches (in the cover of the
PXC36-S) are set correctly.
3 Syntax for PPS-2 signal: Q=Romm device number.Object number (profile number). Up to five
devices can be connected.
4 The current UI and AO can all be configured as AI, DI, CI, or AO.

Signal type if no application is loaded (wiring test): X1...X16 = Y10S, Y1...Y8 = R1K.
Module 4 For Module 4, the universal outputs (UO for AO and DO) not only control
proportional actuators (AO), but can also be used as binary switch commands (DO).
Analog Output = 0…10 V
Binary Output = DC 0 or 24 V, max. 22 mA with the use of an additional external
relay.

285 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing entries for PXC…-U, PTM and P-Bus

D1..D4
MD002

X10

X12

D1
GND

GND

GND

GND
CP+
CP -

X11

D2
D3

D4

D5

D6
D7

D8
X1..16 D5..D16
AC24V
26VA MD001 MD003

GND

GND

GND

GND
X13

X14
X15

X16

D9
51..62 = MD005 Y1..Y8 = MD004

Figure 209: Layout of PXC52 housing with address ranges

Addressing multistate I/Os with PTM

Multistate input The multistate value is made up of several separate binary measured values.
Addressing is via the input/output address [IOAddr]. In both the modular and the
compact series, the logical and physical I/O must be located in the same
automation station, but they do not need to be contiguous. The addressing cannot
extend across automation stations. The addresses must be on the same module
for TX-I/O.
Simple mapping Syntax: P=Module.Channel;Module.Channel;Module.Channel;Module.Channel
(Signal type)
Examples:
● P=1.1 (D20)
● P=1.1;1.2 (D20)
● P=1.1;1.2;1.3 (D20)
● P=1.1;1.2;1.3;1.4 (D20)
● P=10.3 (DIS)
Up to four binary status values (for example, Off/St1/St2/St3/St4) can be registered.
The signals to be registered, which are addressed via Module.Channel, must
always be of the same hardware signal type. With the simple mapping procedure,
to enable the multistate input to interpret the current binary signals correctly, only
one binary signal may be present at any one time. If several binary signals are
present at once, this is displayed as an error at the [Rlb] pin.
The examples below show a possible application for multistate input blocks in
conjunction with the physical I/O modules. The example on the left of the diagram
is a multiple I/O module, while the one on the right shows the mapping of several
individual I/O modules in one multistate input block.
Multistate output The multistate value from the program is converted in the Multistate Output block
into a switching command. Addressing is via [IOAddr]. For PX modular, the syntax
is as follows:
Syntax: P=Module.Channel;Module.Channel;Module.Channel;Module.Channel
(signal type, parameter)
Examples:
● P=1.1 (Q250)
● P=1.1;1.2 (Q250)
● P=1.1;1.2;1.3 (Q250)
● P=1.1;1.2;1.3;1.4 (Q250)

286 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
Addressing entries for PXC…-U, PTM and P-Bus
17

● P=10.1 (Q250-P3,120)
● P=24.7 (DOS)
Values with up to four stages can be processed. The signals to be registered,
which are addressed via Module.Channel, must always be of the same hardware
signal type. In the case of a multistate output on the hardware side, there is one
address only (this is only possible with PXC modular automation stations).
Error handling If an automation station does not support a given address (for example, incorrect
syntax) or a given I/O system, this will lead to a reliability error, which will be
displayed at the [Rlb] pin.

Advanced mapping (Multistate Input)

The manual switch can be encoded on the PX compact in various ways, for
example:
● (Auto/Off/On) or (Off/Auto/On)
● (Auto/Off/S1/S2) or (Off/Auto/S1/S2)
To avoid having to keep adapting the data types and text groups in the system, the
manual switch must always be represented in the same way within the system:
● (Auto/Off/On)
● (Auto/Off/S1/S2)
A prerequisite for this approach is that it must be possible in the multistate input
block to configure the hardware coding and mapping to the standardized manual
switch. This is made possible with parameters in the address.

1_n-Mapping (Multistate Input and Output)

Syntax: P=Module.channel;Module.channel;Module.channel;Module.channel
(signal type, a,b,c,d,e)
a represents [PrVal] for HW-I/O (0,0,0,0)
b represents [PrVal] for HW-I/O (1,0,0,0)
c represents [PrVal] for HW-I/O (0,1,0,0)
d represents [PrVal] for HW-I/O (0,0,1,0)
e represents [PrVal] for HW-I/O (0,0,0,1)
Example: P=1.1;1.2;1.3;1.4 (D20, 1, 3, 2, 4, 5)

[PrVal] Addr1 Addr2 Addr3 Addr4 Comment /

Text group
1 0 0 0 0 Auto

3 1 0 0 0 Stage 1

2 0 1 0 0 Off

4 0 0 1 0 Stage 2

5 0 0 0 1 Stage 3

Table 91: 1_n-Mapping (Multistate Input and Output)

UpDown mapping (Multistate Input and Output)

Application: Connecting/disconnecting further stages.
Example: Electric heating registers, multi-stage burners.
Syntax: P=Module.channel;Module.channel;Module.channel;module.channel
(signal type, UPDOWN)
With "Up/Down" mapping, more than one hardware input or output may be active.

Binary mapping (Multistate Input and Output)

Application: Output of an integer in binary form.

287 | 377
Siemens CM110664en_03
2017-09-18
 Logical I/O Blocks
17 Addressing entries for PXC…-U, PTM and P-Bus

Example: Binary electric heating coil.

Syntax: P=Module.channel;Module.channel;Module.channel;Module.channel
(signal type, BINARY)
With binary mapping, more than one hardware input or output may be active.

288 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

18 Room Automation
Desigo Room Automation Desigo Room Automation offers solutions with greater functionality and flexibility
allowing for energy-optimized plant operation without loss of comfort (efficiency
class A).
The DXR2 room automation stations are perfectly suited to exclusively automate
heating, ventilation, and air conditioning in a room. In addition, the DXR2 can be
extended with lighting and shading functions by adding devices with KNX PL- Link.
The PXC3 modular room automation stations are used in buildings with multiple
disciplines for room automation (HVAC, lighting, blinds) all combined in one system.
Desigo RX Desigo RX is a proven room automation product range featuring comprehensive
communications and application functions for individual rooms. The product range
consists of two series of communicating room controllers (RXC…, RXB…) with
operator units and predefined applications for HVAC, lighting, and blinds. Desigo
RX room automation is capable of autonomous operation. Integration of LonWorks
or KNX network via the system controllers provides for additional functionality.

18.1 Desigo Room Automation

New guidelines to save energy and lower operating costs and greater requirements
for comfort and design require a more sophisticated interaction between a
building's various technical installations. The modular and compact room
automation stations combine lighting, shading, and HVAC in one total solution and
provide a direct connection to the automation stations via BACnet.

Overview of room automation stations

Product range Configurable Programmable
Applications and tool Configurable with ABT Site Programmable with library in ABT Pro
Communication (Backbone) BACnet ethernet BACnet MS/TP BACnet ethernet BACnet MS/TP

Communication with sensors and KNX PL-Link KNX PL-Link KNX PL-Link KNX PL-Link
actuators in room (integration) KNX (with ETS)
DALI

System integration/functions PXC..-E.D PXG3.L PXC..-E.D PXG3.L

PXC..-E.D PXC..-E.D

Modular controller PXC3.E..

I/Os TXM

Compact controller DXR2.E.. DXR2.M.. DXR2.E.. DXR2.M..

DALI extension PXC3.E16A

PXC3.E..A

Communication with room units KNX PL-Link KNX PL-Link KNX PL-Link KNX PL-Link

Room units QMX3.. QMX3.. QMX3.. QMX3..

Touch screen QMX7..

Table 92: Overview of room automation stations

KNX PL-Link KNX PL-Link (PeripheraL Link) connects communicating room and field devices
(room devices, sensors, actors) with the PXC3 room automation station.
DALI DALI (Digital Addressable Lighting Interface) helps control lighting.

289 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

18.1.1 Configurable
With DXR2.. up to two rooms can be automated for heating, ventilation, air
conditioning, shading, and lighting.
The stations communicate with each other and other system components,
depending on the type, via BACnet/IP (DXR2.E…) or BACnet MS/TP (DXR2.M...).
The room automation stations have a set number of I/O data points and an
onboard interface to KNX to connect field devices. The automation stations are
delivered with preloaded applications and only need to be configured.
A comprehensive library of proven, standardized applications is also available and
can be used instead of the preloaded applications. Buttons, sensors, and actuators
for lighting and shading are connected to the room automation stations via the KNX
PL-Link.
The preloaded and proven standardized applications in the library are configured
using ABT Site and offer a great deal of flexibility since the inputs and outputs of
the DXR2… can also be configured in addition to the functions.
See Desigo Configurable Room Automation (BACnet) – Product Range Description
(A6V10866237).

Topologies

Desigo CC

BACnet/IP Ethernet

DXR2.E.. DXR2.E..
KNX PL-Link

KNX PL-Link

Compact AC 230 V Compact AC 24 V PXC..-E.D

°C °C

°C °C

AQR25... Detector AQR25... Detector

10664Z49en

Room sensor QMX3... Room sensor QMX3...

Room Room
operator units operator units
Figure 210: Compact DXR2 room automation stations for BACnet/IP

290 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

Desigo CC

BACnet/IP Ethernet

PXG3.L
Router PXC..-E.D

BACnet MS/TP

DXR2.M.. DXR2.M..
KNX PL-Link

KNX PL-Link
Compact AC 230 V Compact AC 24 V

°C °C

°C °C

AQR25... AQR25...
10664Z48en

Detector Detector
Room sensor QMX3... Room sensor QMX3...
Room Room
operator units operator units

Figure 211: Compact DXR2 room automation stations for BACnet MS/TP

Applications
The following tables show the functions of the different applications of the DXR2
room automation stations.

291 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

Application Functions
Fan coil unit ● Outside Air Damper
● Single Speed Fan , Multi Speed Fan or Variable Speed Fan
● Chilled water cooling coil
● Direct expansion evaporator cooling coil
● Heating/Cooling coil
● Hot water heating coil
● Electric heating coil modulating, single stage or two stage
● Room temperature control by two-pipe system with change-over
● Room temperature control by four-pipe system
● Supply air temperature cascade control
● Room dehumidification control
● Air volume flow control
● Rapid ventilation
● Green leaf

Variable air volume ● Supply and extract air control

● External flow control for VAV with integrated flow controller and differential pressure sensor
● Internal flow controller and differential pressure sensor for damper actuator control
● Internal flow controller and velocity sensor for damper actuator control
● Chilled water cooling coil
● Heating/Cooling coil
● Hot water heating coil
● Electric heating coil modulating, single stage or two stage
● Room temperature control by two-pipe system with change-over
● Room temperature control by four-pipe system
● Supply air temperature cascade control
● Air flow tracking for under/overpressure
● Room dehumidification control
● Room air quality control
● Rapid ventilation
● Green leaf

Radiator and chilled ceiling ● Chilled ceiling with chilled water

● Heated/Chilled ceiling by two-pipe system with change-over
● Heated/chilled ceiling by four-pipe system with 6 way valves
● Heating ceiling with hot water
● Hot water radiator
● Electric radiator modulating or staged
● Downdraft compensation for radiators
● Condensation monitor
● Room temperature control
● Green leaf

292 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

Application Functions
Fan powered box ● Supply air control
● External flow control for VAV with integrated flow controller and differential pressure sensor
● Internal flow controller and differential pressure sensor for damper actuator control
● Internal flow controller and velocity sensor for damper actuator control
● Single Speed Fan , Multi Speed Fan or Variable Speed Fan
● Chilled water cooling coil
● Heating/Cooling coil
● Hot water heating coil
● Electric heating coil modulating, single stage or two stage
● Room temperature control by two-pipe system with change-over
● Room temperature control by four-pipe system
● Supply air temperature cascade control
● Room air quality control
● Rapid ventilation
● Green leaf

Four light groups ● Manual switched control

● Manual dimmed control
● Automatic presence control
● Automatic brightness control
● Constant light control
● Multi group constant light control
● LED support on push buttons
● Green Leaf - RoomOptiControl
● Burn-in & operating hours function

Two blinds ● Manual control

● Automatic control with anti glare function and energy efficiency function
● Green Leaf - RoomOptiControl
● Collision detection

Table 93: Preloaded applications

293 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

Application Functions
Central functions ● 4x Control room operating mode groups with:
– Room mode and room setpoint distribution to rooms
– Start optimization switches the heating on at the appropriate time
– Three delayed distribution groups of room operating mode for big buildings
● 1x Seasonal compensation of room temperature setpoints
● 2x Demand controlled hot water supply group
● 2x Demand controlled chilled water supply group with:
– Condensation prevention shifts the base chilled water setpoint to avoid condensation at chilled
ceiling radiant devices
– Two pipe changeover control handles the heating / cooling changeover for a two-pipe system
– Free cooling manages the delivery of chilled water in situations where this can be done with
almost a zero expenditure of energy. For example, chiller plants with the possibility to cool the
water with the recoolers when outside conditions are favorable.
● 1x Demand temperature control group with:
– Relief function opens additional VAV without demand to ensure stable working of the primary
plant
– Changeover evaluation decide if the central air should be used for heating or for cooling
– Dew point evaluation is used to dehumidify at the primary air handling unit to avoid condensation
in the rooms
– Humidity demand evaluates room humidity to help the primary plant determine when to humidify
or dehumidify
– Override function allows a technician or balancer to override the VAV applications for balancing
and commissioning
● 1x Demand controlled pressure control by either:
– Supply VAV position evaluation helps to optimize fan speed by averaging the 10 highest supply
damper positions and providing this information to the central plant
– Extract VAV position evaluation helps to optimize fan speed by averaging the 10 highest extract
damper positions and providing this information to the central plant.
– Supply VAV flow deviation helps to optimize the fan speed by calculating the airflow deviation
through the supply VAV dampers
– Extract VAV flow deviation helps to optimize the fan speed by calculating the airflow deviation
through the extract VAV dampers
– Supply VAV flow saturation evaluation (air flow control loop cannot get enough air to reach
setpoint) evaluates the supply VAV saturation signals from the rooms to optimize the fan speed
– Extract VAV flow saturation evaluation (air flow control loop cannot get enough air to reach
setpoint) evaluates the extract VAV saturation signals from the rooms to optimize the fan speed
– Supply VAV setpoint evaluation with the summed setpoints of the supply VAV the fan's speed
can be set for an optimized fan speed when VAV positions and VAV flow rates are not known
– Extract VAV setpoint evaluation with the summed setpoints of the extract VAV the fan's speed
can be set for an optimized fan speed when VAV positions and VAV flow rates are not known

Table 94: Loadable central functions

294 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

Application Functions
Central functions ● 2x VAV supply fire emergency group with off, extract, pressurization or purge
● 1x Central weather station with:
– Outside temperature
– Outside brightness
– Outside solar radiation
– Outside wind speed
– Outside precipitation
● 2x Light manual central operation group
● 1x Light central control group for emergency situations
● 4x Shading central facade functions with:
– Central weather station brightness calculation supports facade automatic function
– Glare protection function calculates the glare protection state by central weather station for all
facade
– Annual shading calculates the glare protection state for all facade by in-formation from annual
shading computer
– Thermal protection for unoccupied rooms by central global radiation sensor on weather station
– Three delayed distribution groups for central blind commands for big buildings
● 2x Shading manual central operation with 3 delayed distribution groups for big buildings
● 1x Shading service ensures central commanding of blind group with high priority
● 1x Shading central protection for all blinds with:
– Wind protection
– Precipitation protection
– Frost protection
– Three delayed distribution groups for big buildings

Table 95: Loadable central functions (continued)

See Application Catalog.

Compact room automation stations

Figure 212: DXR2 automation stations

Communication

BACnet ethernet DXR2.E09 DXR2.E09 DXR2.E10 DXR2.E12 DXR2.E12 DXR2.E18 DXR2.E18

-101A T-101A -101A P-102A PX-102A/B -101A -102A

BACnet MS/TP1 DXR2.M09 DXR2.M09 DXR2.M10 DXR2.M11 DXR2.M12 DXR2.M12 DXR2.M18 DXR2.M18
-101A T-101A -101A -101A P-102A PX-102A/B -101A -102A

Applications

Room operating • • • • • • • •

295 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

Heated / Chilled ceiling radiator • • • • • • • •

Fan coil unit • • • • •

VAV system • • •

Lighting • • • • • • • •

Shading • • • • • • • •

Central functions1 • •

Housing

DIN • • • • •

Flat • • •

Operating voltage

230V • • •

24V • • • • •

Inputs and outputs onboard

Digital inputs 1 1 1 1 1 1 2 2

Universal inputs 2 2 2 2 2 2 4 4

Relay outputs 3 1 3

Triac outputs 4 4 6 6 6 8 8

Analog outputs (DC 0...10 V) 2 3 1 2 2 2 4 4

Pressure sensor 1 1

Maximum configuration

Number of I/O data points 3 30 30 30 30 30 60 60 60

Integrated power supply for KNX 50 50 50 50 50 50 50 50

(mA)

Table 96: Compact room automation stations

Key:
1 Cannot be combined with other applications.
2 Cannot be extended by KNX PL-Link inputs and outputs.
3 Total number of data point used by TX-I/O, KNX PL-Link and DALI. For details, see chapter
System Configuration.

See Compact room automation stations, BACnet/IP, 230 V DXR2.E10..,

DXR2.E09.., DXR2.E09T.. (N9204).
See Compact room automation stations, BACnet/IP, 24 V DXR2.E18..,
DXR2.E12P.. (N9205).
See Compact room automation stations, BACnet MS/TP, 230 V DXR2.M10..,
DXR2.M09.., DXR2.M09T.. (N9206).
See Compact room automation stations, BACnet MS/TP, 24 V DXR2.M11..,
DXR2.M12P.., DXR2.M18.. (N9207).

Room pressurization and fume hood control

Desigo offers a range of air volume flow components and accessories for secure,
precise and fast measurement, control and monitoring of air volume flows and
room pressures in highly specialized working spaces.
See Desigo Configurable Room Automation (BACnet) – Product Range Description
(A6V10866237).

296 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

Figure 213: A room pressurization and fume hood control topology

Component Description
DXR2.E17C.. Room automation station, BACnet/IP, 24VAC, 17 I/Os, 30 data points

DXR2.E17CX.. Room automation station, BACnet/IP, 24VAC, 17 I/Os, 60 data points

QMX3.P87-1WSC Operating display panel, wall mounted (KNX)

QMX3.P88-1WSC Operating display panel, thin and flush mounted (KNX)

N/A Room condition monitor (BACnet/IP)

Table 97: Components for room pressurization and fume hood control

Accessory device Description

N/A Sash wire sensor

DXA.S04P1 Air flow pressure sensor (SCOM)

DXA.S04P1-B Air flow pressure sensor with IP65 box (SCOM)

DXA.S12C Sash open area module (SCOM)

Table 98: Accessories for room pressurization and fume hood control

18.1.2 Programmable
The DXR2.. and PXC3.. room automation stations are programmable, based on
proven application blocks. Thus, solutions can be tailored to specific needs and
can achieve maximum efficiency and comfort.
See Range Description Desigo Room Automation (BACnet), Programmable Room
Automation - Emergency Lighting (A6V10640596), Programmable Room
Automation - Room Operation (A6V10640597), Programmable Room Automation -
Distributed Functions and Scenes (A6V10640598) and Programmable Room
Automation - Lighting Controls and DALI (A6V10640599).

297 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

Topology

Desigo CC
BACnet/IP Ethernet

PXG3.L
Router
BACnet MS/TP

PXC3.E7.. TX-I/O PXC3.E16A DXR2.E.. DXR2.E.. DXR2.M.. DXR2.M..

Third-party
PXC00-E.D Modular Modules Lighting Compact AC 230 V Compact AC 24 V Compact AC 230 V Compact AC 24 V
integration

KNX
KNX
DALI
Third-party °C

°C
C
°

°C
C
°

°C
°C

°C
°C

C
°

devices
KNX

Push button, Push button, Push button, Push button, Push button,

QMX7.E38 Touch QMX3... QMX3... QMX3... QMX3... QMX3...

room operator units Room oberator units DALI Room oberator units Room oberator units Room oberator units Room oberator units
Third-party devices

AQR25... Detector AQR25... Detector AQR25... Detector AQR25... Detector AQR25... Detector
Room sensor Room sensor Room sensor Room sensor Room sensor

Third-party Third-party Third-party

integration integration integration
RS/RL Modules RS/RL RS/RL RS/RL RS/RL
Modules Modules Modules Modules
Third-party Third-party Third-party
RXM21/39.1 integration integration integration
PL-Link I/O boxes

11043z31en_02
GLB/
GDB..1E/KN
VAV compact
controller

Figure 214: Desigo Room Automation topology

Applications
A comprehensive block library for room automation is provided as part the scope of
delivery. The library contains predefined application functions for room climate,
lighting, shading, and superimposed room functions. The applications can be
combined with operating and display functions as required. The individual
application functions can be adapted to customer needs and are programmable.
The application functions do not depend on the selected field devices.
See Application Catalog.
Configuration of application functions
Many application functions are preconfigured and available in the library.
Retroactive configuration during engineering or commissioning is possible. Your
own configured application functions and entire rooms can be stored in a project
library.
Configuration of field devices
The application architecture does not depend on the field device interface. Field
devices can be connected directly to the PXC3 room automation station (via TX-I/O
modules) or via bus (KNX or DALI) or IP communication.
Many field devices are preconfigured and available in the library. Retroactive
configuration during engineering or commissioning is possible. Project-specific field
devices configured accordingly can be saved in a project library.

Modular room automation stations

PXC3 room automation stations with control functions for one or multiple rooms:
● Assume control functions for one or multiple rooms.
● Communicate with each other or other system components via BACnet/IP.
Scope and functionality of supported BACnet objects are matched to the
requirements of room automation.
● Provide a 2-port Ethernet interface for cost-effective cabling via daisy chaining.

298 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

● Contain bus supplies for island bus, KNX PL-Link, and DALI. Internal bus
supplies can be extended for island bus and KNX PL-Link as needed.
● Have an integrated web server for IP communication with QMX7.E38 touch
room operator units.
See Room automation station PXC3.E7.. (CM1N9203) and Touch room operator
unit QMX7.E38 (CM1N9295).

Figure 215: PXC3 automation station

PXC3.E72 PXC3.E72A PXC3.E75 PXC3.E75A PXC3.E16A

Typical number of rooms / room segments 4/8 4/8 8/16 8/16 N/A

System communication BACnet/IP BACnet/IP BACnet/IP BACnet/IP BACnet/IP

HMI automation level

QMX3 • • • •

QMX7 • • • • •

Web based test and setup tool • • • • •

System functions (BACnet)

BACnet profiles B-ASC B-ASC B-ASC B-ASC B-ASC

Programming • • • • •

Peripheral bus

Bus for I/O module • • • •

KNX PL-Link1 / KNX S-Mode • • • •

DALI • • •

Maximum configuration

Number of I/O data points 2 140 140 280 280 64

Inputs/Outputs for TX I/O modules 72 72 200 200 0

Devices on KNX PL-Link 64 64 64 64 0

DALI ballasts 64 64 64

Integrated power supply for KNX (mA) 160 160 160 160 N/A

Table 99: Modular room automation stations

Key:
1 Dedicated devices with KNX PL-Link.
2 Total number of data points used by TX-I/O, KNX PL-Link and DALI. For details, see chapter
System Configuration.

TX-I/O modules
TX-I/O modules (TXM1) help connect field devices to the PXC3 room automation
station. Bus supply and interface modules (TXS1, TXA1) are available as an
accessory.

299 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

Figure 216: TX-I/O module

The following TX-I/O modules can be used with the PXC3 room automation station:
● TXM1.8T: Triac module with 8 outputs (AC 24 V) to control thermal and
motorized valve actuators (AC 24 V) for up to 4 actuators (3-point output) or 8
actuators (permanent contact or pulse width modulation).
● TXM1.6RL: Bistable relay module to switch lighting for up to 6 data points.
● TXM1.8RB: Relay module to control blind motors for up to 2 motors (3 end
switches) or 4 motors (2 end switches).
● TXM1.16D: Digital input modules for up to 16 data points.
● TXM1.8D: Digital input modules for up to 8 data points.
● TXM1.6R: Relay module for up to 6 data points.
● TXM1.8U: Universal module for up to 8 data points.
See TX-I/O Assortment overview (CM2N8170).

Compact room automation stations

Communication

BACnet ethernet DXR2.E09 DXR2.E09 DXR2.E10 DXR2.E12 DXR2.E18

-101A T-101A -101A P -1..A

BACnet MS/TP DXR2.M09 DXR2.M09 DXR2.M10 DXR2.M11 DXR2.M12 DXR2.M18

-101A T-101A -101A -101A P -1..A

Housing

DIN • • •

Flat • • •

Operating voltage

230V • • •

24V • • •

Inputs and outputs onboard

Digital inputs 1 1 1 1 1 2

Universal inputs 2 2 2 2 2 4

Relay outputs 3 1 3

Triac outputs 4 4 6 6 8

Analog outputs (DC 0...10 V)* 3 1 2 2 4

Pressure sensor 1

Maximum configuration

Number of I/O data points 30 30 30 30 30 60

Integrated power supply for KNX (mA) 50 50 50 50 50 50

Table 100: Compact room automation stations

Key:

300 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo Room Automation
18

1 Total number of data points used by TX-I/O, KNX PL-Link and DALI. For details, see chapter
System Configuration.

PXC3.E16A room automation station for lighting

The PXC3.E16A room automation station is tailored for challenging lighting
applications. All lighting applications that also run on the PXC3.E7.. are available.
The PXC3.E16A communicates via BACnet/IP with the DXR2.E.. and PXC3.E..
room automation stations. Using the on-board DALI interface, up to 64 ECGs
(electronic control gear) can be integrated in 16 groups. The PXC3.E16A can be
used for centralized lighting automations or, as applicable, as a supplement to a
decentralized HVAC installation.
Example: Centralized lighting installation with decentralized HVAC installation
● DXR2.E.. to automate HVAC in the room
● Centralized installation with PXC3.E..A for lighting

Figure 217: Centralized lighting installation with decentralized HVAC installation

Example: Centralized lighting installation without HVAC installation

● One PXC3.E16A is centrally installed per DALI line
● Optional PXC3.E7..A
– To integrate buttons via KNX PL-Link
– To use TXM1 modules
– Three-phase power installation possible

Figure 218: Centralized lighting installation without HVAC installation

18.1.3 Rooms and Room Segments

There are two methods to structure a building:

301 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo Room Automation

● Rooms (with fixed walls)

● Room segments (typically based on movable walls)
One of the two methods or a mixture thereof is possible depending on the building
structure or required flexibility (for example, during the usage phase).

Figure 219: Rooms and room segments

A room segment is the smallest indivisible element. A room comprises at least one
or several adjacent room segments. A room segment is defined and created only
once. Room segments are typically combined several times to rooms over the
course of a building's lifecycle.

18.1.4 Central Control Functions and Grouping

Grouping is used to implement central control functions and to coordinate demand
and forced signals from the various rooms in an entire building, building wing, floor,
etc.
Hidden behind the central control functions are system functions, such as operator
interventions via BACnet clients, schedulers, automatic reactions, and data from a
weather station.
Central functions influence:
● Room operating mode (occupancy and use in room)
● HVAC control via various setpoint requirements depending on the room
operating mode
● HVAC setpoints via a weather-dependent adjustment
● Lighting control
● Shading control (blinds)
Grouping can be used to coordinate demand, operating, and forced signals, that is:
● Request signals for hot water distribution (heating circuit)
● Request signals for chilled water distribution (cooling circuit)
● Record demand, operating, and forced signals for the primary air handling unit

302 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

Figure 220: Grouping

Various sources are available for forming these central superposed functions:
● External system or third-party device
● System user via BACnet client
● Building user via BACnet client or local operator unit
● Scheduler or reaction program
● Superposed office based on grouping function
They are distributing after evaluating signals and commands via a Grouping
function.
One group master exists for each of the various categories which then forwards the
resulting information to all assigned group member (rooms). A group master can
for its part be a group member of a superposed group master.

18.1.5 Desigo Room Automation and the Management Level

See chapter Desigo Room Automation Integration.

18.1.6 Desigo Room Automation and the Automation Level

Alarming is triggered directly on the PXC3.E.. and DXR2.. room automation
stations. A primary automation station (typically PXC00.E-D) is only used for
calendars, schedulers and time setting. This simplifies engineering and reduces
the number of required system components.

18.2 Desigo RXC

The Desigo RXC room automation system controls and monitors comfort
conditions in individual rooms. It provides predefined solutions for HVAC, lighting
and blinds.
See Desigo RXC Room automation system, System description (CA110333).
The range consists of several controllers, operator units and predefined
applications. The applications are configured and downloaded into the controllers
with the RXT10 commissioning and service tool or a standard LNS tool.
See RXT10.3 commissioning and service tool User ’s Guide (CM110669) and
RXT10.5 commissioning and service tool User ’s Guide (CM110658).

303 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXC

Desigo CC

BACnet/IP or BACnet/LonTalk

PXX-L.. PXX-L..

PXC50/100/200...E.D PXC50/100/200...E.D TX-I/O-

PXC50/100/200...D PXC50/100/200...D TXM1..

Third party QAX... QAX...

devices QAX5... Room operator units Room operator units

Figure 221: RXC topology

Binding When a LonWorks network is designed, bindings are created with a LonWorks tool
(RXT10 commissioning and service tool or a standard LNS tool). A binding is the
connection of network variables of the same type between different nodes.
Network variables connected in this way communicate implicitly, that is, if a value
changes, the new value is transmitted automatically. Transmit and receive times
are also monitored, making it possible to react to communications errors.
Discipline I/Os Discipline I/Os are function block in the LonWorks system controller that gather
data from the RXC controller and make it available on the BACnet network.
Discipline I/Os are available for HVAC, lighting and blinds.
Floor Level Network (FLN) A Floor Level Network (FLN) is a communications network for room automation.
LonMark Interoperability The LonMark Interoperability Association is an association founded by the
Association manufacturers of LonWorks products, to define independent, interoperability
guidelines for LonWorks systems. The association is responsible for checking
compliance and for the certification of LonMark products.
LonWorks nodes LonWorks nodes are devices that are connected to the LonWorks bus and
communicate with other LonWorks nodes.
Network variables (NV) Network variables (NV) allow the exchange of data between different LonWorks
nodes. This type of communication is also called implicit, because transmission
and reception are automatic. Network variables may be input or output variables.
Room-based groups The discipline I/Os representing the RXC controllers in a room are combined in the
LonWorks system controller into a room-based group. The result is a room view.
Cross-room groupings A cross-room grouping contains all the control variables common to a given user
grouping (for example, North facade, Tenant A, West zone, etc.) and distributes
these control variables to the associated room or group members.

304 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

Standard Network A Standard Network Variable Type (SNVT) is a standard type of network variable,
Variable Type (SNVT) which simplifies the communication between LonWorks nodes. Only network
variables of the same type can be connected. The SNVTs are defined in the SNVT
Master List provided by LonMark.

18.2.1 Product Range Overview

Desigo RXC is an innovative product range comprising controllers, extension
modules, and room units. Data communication is based on LonWorks.
Desigo RXC hardware The range comprises compact and modular controllers, easy-to-operate room units
and room controllers.
The input and output configurations of the controllers, and the housing style are
fully optimized to suit their field of application. The modular controllers include
basic modules for HVAC control, which can be combined with extension modules
for control of lighting and blinds.
The HVAC functions are operated with standard room units or the compact
controller RXC10.5. The QAX50 and QAX51 configurable flexible room units are
available for combined operation (HVAC, lighting, blinds).

Communicating (RXB, RXC)

KNX LonWorks

Lighting and
blinds

VAV

Radiators and
chilled ceilings

Fan coil units

Device name RXB21 RXC20 RXC10 RXC30 RXC40

RXB22 RXC21 RXC31 RXC41
RXB24 RXC22 RXC32
RXB39 RXC39

Table 101: Desigo RX hardware

PPS2 (RXC, RXB, PX) enocean LonWorks

Standard Flush mounting Wireless Flexible

Lighting and
blinds

HVAC

Device name QAX30 QAX33 QAX84 QAX95 QAX50

QAX31 QAX34.3 QAX96 QAX51
QAX32 QAX39 QAX97
QAX98
Only for RXC &
RXB

Table 102: Desigo RX room units

305 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXC

Desigo RXC applications The controllers and the QAX5.. flexible room units are loaded with application
software which contains the control program for the associated room or area.
Siemens Building Automation maintains a comprehensive library of applications
covering a wide range of HVAC and electrical applications.
See RXC application library Version 2 (CA110300).
Example: Fan coil system

T
T

LON Controller

Figure 222: Example: Fan coil system

Application Name Controller

FNC02 Two-pipe system with changeover RXC20.5
RXC21.5
RXC39.5

FNC03 Two-pipe system with changeover and electric re-heater RXC20.5

RXC21.5
RXC22.5
RXC39.5

FNC04 Four-pipe system RXC20.5

RXC21.5
RXC39.5

FNC08 Four-pipe system with room supply air cascade control RXC21.5
RXC39.5

FNC10 Two-pipe system with changeover and outside air RXC21.5

damper

FNC12 Four-pipe system with outside air damper RXC21.5

Table 103: Applications for RXC controllers

Common functions:
● Window contact, occupancy sensor, four operating modes
● Manual fan control with room unit
● Automatic fan control
● RXC20.5 single-speed, RXC21.5, RXC22.5 three-speed, RXC39.5 constant 0-
10V
● Options with two-pipe systems: Heating only, cooling or changeover via bus
using LonWorks technology

306 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

18.2.2 RXC Applications

Desigo RXC applications are standard applications developed at HQ. They cannot
be modified for a specific project by the user. These applications are loaded to the
controller using the RXT10 commissioning and servicing tool or a standard LNS
tool (commissioning).
Applications of the same type are grouped into application groups. The complete
range of RXC applications is held in a library which is continuously expanded.
RXC applications Application Application Application
library group CLC CLC03 configuration
CLC
RAD CLC01
Electric radiator
CLC CLC02
Chilled ceiling with On/Off or
FNC CLC03 electric radiator modulating

INT Temp. Setpoint

... ...

Figure 223: Hierarchical structure of the application library

RXC application library The RXC application library contains application groups, each of which contains
applications of the same type. The RXC application library has a version number
which is defined in the RXC Valid Version Set. The Valid Version Set also defines
the version of each individual RXC application.
The structure described above can be seen in the documentation and in the
implementation of the RXT10 commissioning and service tool.
Application groups Similar application types are grouped into application groups. These differ from
each other in terms of how the functions are implemented. Thus, chilled ceiling with
radiator (CLC02) and chilled ceiling and electric radiator (CLC03) are two different
applications within the CLC group. The first of these two applications uses water
for heating, while the second uses electrical energy. The difference between
applications in the other groups follows a similar pattern.
The following application groups are available:
● 000: Basic applications (allow the RXC controllers to be used as I/O modules)
● RAD: Radiator applications
● CLC: Chilled ceiling applications
● FNC: Fan coil applications
● VAV: Variable air volume applications
● FPB: Fan-powered box applications (fan-assisted VAV)
● INT: Integrated applications (combined applications including lighting and/or
blinds)
● IRO: Integrated room operation applications (applications for the QAX50/51
flexible room units)
Individual applications The individual application is designed for typical HVAC systems as commonly used
in practice in individual rooms, for example:
● FNC10: Two-pipe system with changeover and outside air damper
● VAV06: Single duct supply and extract air system with electric re-heater
Applications are modular in structure, and cover a specific combination of functions
which are always implemented in the same way, for example, operating modes
and setpoint derivation are identical in all applications (including those in different
application groups). Similarly, fan speed control is identical in all FNC applications.

307 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXC

Y [% ]
100 H ea ting Co oling

0 TR

C om fort
P reC omfo rt
E co nomy
B uild in g prote ct io n
F r ost pr ote ct io n

Figure 224: Example: Operating modes

Key:

Y Output signal

TR Room temperature

Configuring applications Each application has a defined number of configuration parameters with which the
application can be programmed for a specific project. These parameters consist
both of general values, for example, temperature setpoints, etc., and of specific
values for the respective application, for example, changeover configuration,
electric reheater, etc.

18.2.3 RXC and the Management Level

Generic and engineered operation is available at the management level. The
operation is explained below based on Desigo Insight.
Generic operation For operation in the Object Viewer, no additional engineering is required in Desigo
Insight. Operation may be either via groups and rooms or directly via the discipline
I/Os.

Figure 225: Object Viewer with RXC integration

308 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

Engineered operation – A typical requirement in the case of room integration is a graphical representation
Plant Viewer of the building, showing the different floors and rooms. Desigo Insight supports the
generation of graphics and the integration of RXC.

Figure 226: RXC supergenie with a floor plan as the background

For each RXC application, there is a predefined graphic (supergenie) in the Desigo
Insight graphics library, containing the main data points. The information contained
in the supergenies is the same as the information in the binding templates in the
RXT10 tool.

309 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXC

Figure 227: RXC supergenie

18.2.4 RXC and the Automation Level

Desigo RXC is integrated into the automation level with the LonWorks system
controller.
The main tasks of the system controller are:
● Mapping RXC data to BACnet objects
● Implementing higher-level functions (grouping, time schedules, etc.)
On the BACnet side of the LonWorks system controller, the RXC controllers can be
operated and monitored from a client. Data can also be exchanged with the
primary plant.

18.2.5 Mapping LonWorks in the LonWorks System Controller

RXC data in the LonWorks system controller is mapped by objects that assemble
the main functions of the RXC applications. The LonWorks system controller thus
operates as a data concentrator (the data points are not mapped individually).
These objects are referred to as discipline I/Os and are components of the block
library.
The following types of discipline I/Os exist:
● HVAC: Comprises all the HVAC information
● Light: Comprises all the information relating to a lighting group
● Sunblind: Comprises all the information relating to a blinds group
● Shared: Contains shared data points (for example, time schedules, occupancy
status, etc.)
The discipline I/Os are defined according to the maximum principle, that is, one
HVAC discipline I/O contains all the information found in the HVAC part of the RXC

310 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

application. When mapping an application, however, only the specific data points
for that particular application are mapped to BACnet.
FNC04
FNC03 HVAC
discipline I/Os
FNC02
Inputs Outputs
Only application-
A discipline I/O specific data is
contains a mapped
superset of the FNC04
CLC03 data
CLC02
CLC01

FNC04
FNC03
FNC02

Figure 228: Data points in the application

18.2.6 Groups in the LonWorks System Controller

The RXC controller data is grouped in the LonWorks system controller. The
discipline I/O is a preliminary form of grouping. It groups the data for the different
sections (HVAC, lighting and blinds) of the RXC applications into the associated
objects.
The LonWorks system controller has the following groups:
● Room-based groups (grouping of discipline I/Os into a room) > Compounds
● Multi-room groupings (groups of rooms) > Firmware
Room-based groups A room-based group is a structuring element. If more than one RXC controller is
installed in a room, only the discipline I/Os of the master controller is integrated. In
such cases, master and slave are connected at the field level. A room-based group
accommodates all the discipline I/Os of one physical room. This leads to a room-
based view.
The second function of the room-based group is the mapping of application-
specific data to BACnet, that is, the selection of those points of the discipline I/Os
which are needed for the RXC application concerned. Room-based groups are
compounds. There is a room compound for every RXC application.

311 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXC

Room-based group

Shared Blinds Light

Room
RXC1 RXC2

Shared HLK Light Shared HLK Light

RXC room controller

Figure 229: Room-based view

Grouping across rooms A multi-room group contains all the control variables common to a given group of
users (for example, North facade, Tenant A, West zone etc.), and distributes these
control variables to the associated room or group members. For this reason, a
multi-room group contains two member lists, one for the referenced room and one
for the referenced group.
Multi-room groups take the form of blocks and are contained in the block library.
Referenced rooms Referenced rooms are referenced via the discipline I/O of the room-based groups.
Only rooms connected to the same LonWorks system controller can be referenced.
The addressed rooms cannot be modified online.
Referenced groups A multi-room group can also transmit values to another group, which may be
connected to the same or different LonWorks system controller. Up to five more
groups can be addressed. These references can be modified online.

A group can only distribute information. It cannot gather data.

System controller 1 System controller 2

X1 X1
X2 X2
Group objects

X3 X3
A2 __

R101'HVAC R101'HVAC
Room Room
R102'HVAC R102'HVAC
Members: Members:

R101 R102 R201 R202

Room objects

A1 A1 A1 A1

A2 A2 A2 A2

Figure 230: Multi-room groups

Group types The following group types are available:

312 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXC
18

HVAC functions:
● Changeover: Transmission of the changeover signal (LTHW or CHW in pipe
work)
● Setpoints: Basic setpoint correction and setpoint adjustments
● Emergency: Override of supply/extract air dampers in the event of fire/smoke
● Outdoor temperature: Distribution of outside air temperature
Electrical functions:
● Lighting: Transfer of lighting control and forced control of lighting
● Blind: Transfer of blind control and forced control of blinds
Time schedules:
● Building use: Transfer of values for the building use time schedule
● Room occupancy: Transmission of values for the room occupancy time
schedule

18.2.7 System Functions

System functions are higher-level functions which are typically applied to groups.
They are thus stored upstream of the groups and connected to them as part of the
data flow. System functions are implemented in the form of compounds and are
part of the compound library.
System functions Group objects Room objects

Floor
"Program" = System function Cmd R101'LightA
R102'LightB
Members:

X1
X2 R101'HVAC
X3 R102'HVAC
Members:

Emergency
Cmd R101'LightA
R102'LightB
Members:

R101'HVAC
R102'HVAC
Members:

Figure 231: System functions

The following system functions are available:

● Summer/winter compensation: Adjusts the setpoints as a function of the
outdoor temperature. For example, the heating setpoint is raised in winter as
the outdoor temperature falls.
● Changeover: Is used when both heating and cooling are required in a room, but
only one water pipe is installed. The changeover information is mapped in the
LonWorks system controller and transmitted to the RXC controllers via the
groups. These switch between heating and cooling accordingly.
● Emergency override: Is used in emergencies (for example, fire) to force a
specific and immediate reaction from the ventilation system in the individual

313 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXB

room. Possible reactions are: Close damper, generate positive or negative

pressure, etc.

18.3 Desigo RXB

The Desigo RXB room automation system controls and monitors comfort
conditions in individual rooms. It supplies predefined solutions for HVAC.
See RXB Room automation system - system overview (CM110380).
The range consists of controllers, operator units and predefined applications. The
applications are configured and downloaded with the ETS Professional
commissioning and service tool.
See Working with ETS (CM1Y9779).
RXB topology The Desigo RXB room automation system is based on KNX/EIB technology. To
integrate Desigo RXB into the automation level, the RXB data is mapped to
BACnet.

Desigo CC

PXM20

BACnet

PXC50/100/ TX-I/O
200...D
PX KNX
system controller

TX-I/O

Desigo RXB Synco 700

Figure 232: RXB topology

Group address / Binding A group address / binding is a connection of network variables of the same type
between different nodes. The group addresses / bindings are generated using ETS
(EIB tool software) when designing the KNX/EIB network. The bound network
variables communicate when changing the value and using a heartbeat.
Transmission and reception times are also monitored, allowing you to react to
communications errors.
Discipline I/Os Discipline I/Os are function blocks in the PX KNX system controller, which gather
data from the RXB controller and make it available on the BACnet network.
Discipline I/Os are available for HVAC functions.
The Konnex Association is an association founded by the manufacturers of
KNX/EIB products, to define interoperability guidelines for KNX/EIB systems. The

314 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXB
18

Konnex Association association is responsible for checking compliance and for the certification of
KNX/EIB products.
KNX/EIB nodes A KNX/EIB node is a device which is connected to the KNX/EIB bus and
communicates with other KNX/EIB nodes.
Network variables (NV) Network variables (NV) allow the exchange of data between different KNX/EIB
nodes. Network variables may be input or output variables.
Room-based groups The discipline I/Os representing the RXB controllers in a room are combined in the
PX KNX system controller into a room-based group. The result is a room view.
Cross-room groupings Cross-room groupings contain all the control variables common to a given user
grouping (for example, north facade, tenant A, west zone, etc.) and distribute these
control variables to the associated room or group members.
PX KNX system controller The PX KNX system controller comprises a PXC001(-E).D controller and loaded
PX KNX firmware. Communication takes place via BACnet/LonTalk (PXC001.D) or
BACnet/IP (PXC001-E.D). With the system controller, you can integrate the Synco
RMU710, RMU720, RMU730 and RMH760 controllers into Desigo.
PX KNX Tool The PX KNX tool is used to configure the PX KNX system controller on the KNX
side.

18.3.1 Product Range Overview

Desigo RXB is an innovative range of controllers and room units. Data
communication is based on KNX/EIB technology.
Desigo RXB hardware The range comprises compact controllers, easy-to-operate room units and
controllers in room-style housings. The input and output configurations of the
controllers, and the housing style are fully optimized to suit their field of application.
The HVAC functions are operated with standard room units or controllers in a
room-style housing.
Desigo RXB software Each controller is loaded with a selection of application software which contains the
control program for the associated room or area within a room.
The ETS commissioning and service tool is used for the engineering and
commissioning of a network incorporating the Desigo RXB range. This tool also
supports the creation of communication bindings between KNX/EIB-compatible
devices (Desigo RXB or third-party devices).
Example: Fan coil system

T
T

KNX/EIB Controller

Figure 233: Example: Fan coil system

315 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
18 Desigo RXB

Application Name Controller

FNC02 Two-pipe system with changeover RXB21.1/FC-10
FNC04 Four-pipe system RXB39.1/FC-13
FNC08 Four-pipe system with room supply air cascade control
FNC20 Four-pipe system with damper control

FNC03 Two-pipe system with changeover and electric reheater RXB22.1/FC-12

FNC05 Four-pipe system with electric reheater RXB39.1/FC13

FNC10 Two-pipe system with changeover and outside air RXB21.1/FC-11

FNC12 Four-pipe system with outside air
FNC18 Two-pipe system with changeover and radiator

Table 104: Applications for RXB controllers

Common functions:
● Window contact, occupancy sensor, four operating modes
● Manual fan control with room unit
● Automatic fan control (three speeds)
● Options with two-pipe systems: Heating only, cooling or changeover via
KNX/EIB bus

18.3.2 RXB and the Management Level

The integration of Desigo RXB into the management level is analogous to the
integration of Desigo RXC into the management level.

18.3.3 RXB and the Automation Level

Desigo RXB is integrated into the automation level with the PX KNX system
controller, which carries out the same tasks as the LonWorks system controller for
Desigo RXC.

18.3.4 RXB Applications

The existing Desigo RXB applications are identical to the RXC applications of the
same name. They cannot, however, be modified for a specific project by the user.
These applications are preprogrammed by groups in the controller and are
selected and parameterized using the ETS Professional commissioning and
service tool.
Applications of the same type are grouped into application groups. The technical
manual contains the complete range of RXB applications.
See RXB (KNX) Technical manual (CM110389).
RXB application library The RXB application library contains application groups, each of which contains
applications of the same type. The RXB application library has a version number
which is defined in the RXB Valid Version Set. This Valid Version Set also defines
the version of each individual RXB application.
Application groups Similar application types are grouped into application groups. These differ from
each other in terms of how the functions are implemented. Thus chilled ceiling with
radiator (CLC02) and chilled ceiling and electric radiator (CLC03) are two different
applications within the CLC group. The first of these two applications uses water
for heating, while the second uses electrical energy. The difference between
applications in the other groups follows a similar pattern.
The following application groups are available for RXB:

316 | 377
Siemens CM110664en_03
2017-09-18
 Room Automation
Desigo RXB
18

● CLC Chilled ceiling applications (not for Synco)

● FNC Fancoil applications
● VAV Variable air volume applications (not for Synco)
Individual applications The individual application is designed analogous to RXC for typical HVAC systems
as commonly used in practice in individual rooms.
Configuring applications Each application has a defined number of configuration parameters with which the
application can be programmed for a specific project. These parameters consist
both of general values (for example, temperature setpoints, etc.) and of specific
values for the application concerned (for example, changeover configuration,
electric reheater, etc.).

18.3.5 Mapping RXB in the PX KNX System Controller

The RXB system is mapped to the PX KNX system controller with objects
analogous to RXC. These objects are called discipline I/Os and are components of
the block library.
See PX KNX, RXB integration – S-Mode (CM1Y9775).
The following types are available for RXB:
● HVAC: Comprises all the HVAC information
● Shared: Contains shared data points (for example, time schedules, occupancy
status, etc.)

317 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
19 Desigo RXB

19 Desigo Open
Desigo Open lets you integrate devices and systems from different manufacturers
into the Desigo system. Integration with Desigo Open offers:
● Standardized automated functions, operating and monitoring of the entire
building
● Single-station operation, common view and display. Simplified multidisciplinary
operation, common reporting and common alarm management.
● Peer-to-peer interaction, communication on the automation level, automated
interactions and data exchange
● Comfort combined with lower energy consumption. New opportunities to save
energy with systems that communicate among themselves. Improved
performance, efficiency evaluation, flexibility and ability to modify system
operation and configuration without re-cabling or new hardware.
● Engineering of integrated solutions in Xworks Plus (XWP)
● Reduced risk thanks to standard solutions. Clear functions that cover the most
important standard protocols.
Topology Third-party devices and systems can be integrated with Desigo on all levels.
Desigo CC
BACnet
Management level

Third-party system

10660Z04en_08
Third-party
system

BACnet/LonTalk or BACnet/IP

Router
Automation level

LONWORKS PXC50/100/200..D TX-I/O TX Open SX Open

System controller Modular Modules
PX KNX PXC...D PX Open
System controller Compact
PXC001..D PXC001..D
RS232
RS485
LON WORKS Adapter

QAX9..
EnOcean
Room units
RXZ97.1/KNX
room level
Field and

LONWORKS Third-party Modbus OPC

RXC Third-party system M-bus Third-party system
Room system Third-party system
controller several protocols
Peer-to-peer communication via BACnet

Figure 234: Topology

Which protocols does

Desigo support? Desigo Open System Protocol
Desigo CC SCADA, etc.

SX Open OPC to BACnet

PX Open Modbus, KNX/EIB, LonWorks, M-Bus, SCL, etc.

TX Open Modbus, M-Bus, GENIbus, etc.

Room level (Desigo Room Automation and DALI, KNX, EnOcean, LonWorks
RX)

Table 105: Supported protocols

318 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
Integration on Management Level
19

Which plant sections can

be integrated into Desigo Desigo Open system Desigo Open application Data points
on which level? Desigo management platform Desigo CC, SX Open 1,000 - 10,000
Energy monitoring, fire security,
access control and security

Desigo PX SX Open, PX Open 50 - 2,000

Power distribution, refrigeration
machines

Desigo TX-I/0 TX Open Max. 160

Pumps, variable speed drives,
meters, etc.

Desigo Desigo Room PXC3 16 DALI groups

Automation / RX Lighting and blinds

Table 106: Integration of plant sections

SDKs If a solution is not supported by HQ and RCs need a specific solution, HQ offers
Software Development Kits (SDKs) for experts. The regional companies can
develop their own solutions using Software Development Kits (SDKs).
The following SDKs are available:
● PX Open platform SDK
● TX Open platform SDK

19.1 Integration on Management Level

The integration of third-party devices and systems on the management level is
appropriate:
● For monitoring and operating plants that are not time-critical
● When process communication with other automation stations is not needed

Desigo CC
BACnet BACnet is a widely used communication protocol for building automation and
control networks. It defines a number of objects, services and data link layers. It is
an essential part of Desigo CC's openness for integrating any third-party devices,
using the BACnet/IP protocol. An online auto-discovery and alternatively an offline
EDE import are available for integrating third-party devices.
See BACnet 3rd party Integration Guide (A6V10446271).
BTL Desigo CC is compliant with BACnet revision V1.13 of the latest BACnet Standard
135-2012. The compliance and interoperability has been tested. For more
information, see (http://www.bacnetinternational.net/btl).
Modbus-TCP A native Modbus-TCP driver lets you integrate a Modbus TCP server and
subsequent Modbus RTU devices via a protocol converter. An offline importer
supports the engineering workflow for integrating Modbus data points.
See Modbus Integration Guide (A6V10438039).
OPC OLE for Process Control (OPC) is a communication standard for exchanging data
between windows based software applications and process control hardware
without any proprietary restrictions. It is a client/server technology, where one
application acts as the server providing data, and another acts as a client using
data. The most common specification Data Access (DA) defines a set of objects,
interfaces and method to facilitate the interoperability. OPC has been extended to
become a cross-platform communication standard, named OPC Unified
Architecture (OPC UA).

319 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
19 Integration on Management Level

For more information about OPC, see the documentation by the OPC Foundation
(www.opcfoundation.org) and the OPC Training Institute (www.opcti.com).
OPC DA client An OPC client interface lets you integrate any OPC server, using the Data Access
specification. An offline Importer supports the engineering workflow to integrate
OPC items.
See OPC Server Integration Guide (A6V10415483).
OPC DA server An OPC server option provides a freely configurable set of data points for
integration in any enterprise system, using the OPC DA standard. Each data point
(object) is represented by several OPC items, providing the relevant readable and
writable object property information.
See OPC DA Server Manual (A6V10415485).
The Desigo CC OPC server is officially tested and certified by the OPC foundation
(https://opcfoundation.org/products/view/251).
OPC UA server OPC Unified Architecture (OPC UA) clients can connect to the Desigo CC OPC DA
server using the OPC DA/UA wrapper, provided with the Desigo CC setup. The UA
wrapper meets the security model of mutual authentication for a trusted connection
between the OPC UA server and the OPC UA client.
See OPC DA Server Manual (A6V10415485).
Simatic S7 A native S7 Ethernet driver lets you integrate S7-300 and S7-400 or S7-400H PLC.
You can use the CP for Ethernet or the built-in PNIO interface on the S7 hardware.
An offline importer supports the engineering workflow for integrating S7 data points.
See Simatic S7 Integration Guide (A6V1042787).
SNMP Simple Network Management Protocol (SNMP) is a data communication protocol
for monitoring devices and applications on a network. It is an Ethernet based
protocol for retrieving management data from networked devices, and exposing
this data as properties.
SNMP gives you the capability to monitor a device, for example, a printer or UPS,
which is not directly configured on a computer, but can be reached through a
network link.
Device monitoring capabilities are provided by device manufacturers via a
Management Information Base (MIB) text file, which describes the structure of the
device management data. MIB files use a hierarchical namespace containing
object identifiers (OID). Each OID identifies a property that can be read or written
via SNMP.
Desigo CC has an SNMP Manager feature for reading and writing information from
SNMP agents.
See SNMP Application Guide (A6V10455382).
Web services Using RESTful technology, Desigo CC provides alarm, object and time series data
via web based services for supervising management platforms or other third-party
external applications.

SX Open
SX Open is a configurable third-party system - BACnet/IP gateway. It allows the
data exchange between third-party systems and the Desigo system in an IP
network. That means, Desigo automation stations (peer-to-peer communication) or
a BACnet management platform. Multiple BACnet servers can be defined in the
gateway and third-party data points can be mapped to standard BACnet objects.
The mapping supports functional and signal mapping. Alarms, trends and
schedules can be defined in the BACnet server. With SX Open you can integrate
any number of data points. There are two application types.
SX API is the basic software with an Application Programming Interface (API). With
the API you can independently develop other applications using Microsoft® Visual

320 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
Integration on Automation Level
19

SX API Studio, if necessary. This lets you integrate other third-party systems, protocols,
and drivers.
SX OPC The predefined SX OPC application contains an OPC DA client that can connect to
respective OPC servers of the third-party system and map their domain to the
respective BACnet objects and properties.
Engineering Engineering is carried out with the SX Configurator (a predefined Excel sheet) in
which the allocation of OPC objects and BACnet objects can be configured line by
line. You can also enable additional functions, such as alarm, scheduler, trend and
individual mapping functions.
See SX OPC SX Configurator User's Guide (CM110702) and SX Open
Engineering Guideline (CM110700).
Licensing SX Open is available for both application types in four different license models,
graded according to the number of BACnet I/O and value objects.
● Tiny for up to 200 BACnet objects
● Light for up to 2,000 BACnet objects
● Regular for up to 5,000 BACnet objects
● Full for up to 20,000 BACnet objects
The license is linked with the hardware in use (the physical MAC address). A
registry key is generated with the license. The licenses can be ordered and
downloaded via CGU Web.
All third-party software is available directly from the appropriate producer as
described in the application guide. The number of configured BACnet objects are
relevant for licensing.
Installation SX OPC operates under Microsoft Windows. The SX OPC setup file including the
function block library and the SX OPC documentation can be downloaded from the
intranet.
See SX Open data sheet (CM1N9745).

19.2 Integration on Automation Level

The integration of third-party devices and systems on the automation level is
appropriate when:
● Cross-communication to other PX or BACnet devices is needed
● System functions (for example, alarms, trends, schedulers) are needed
The PX Open Platform comprises:
● PXC001.D system controller for the integration of KNX, Modbus, M-Bus and
SCL via BACnet/LonTalk
● PXC001-E.D system controller for the integration of KNX, Modbus, M-Bus and
SCL via BACnet/IP
● PXA40-RS1 and PXA40-RS2 option modules for additional data points
The automation stations have interfaces to RS232, RS485 and KNX.
Xworks Plus (XWP) is used to engineer all solutions. Various compounds and
blocks are available.
PXC001..D supports the firmware versions V4.1, V5.0, V5.1 and V6.0.
The following solutions on the PX Open platform are available:
● PX KNX
● PX Modbus
● PX M-Bus
● PX SCL
● PX RS-Bus

321 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
19 Integration on Automation Level

● PX Pronto
● PX Open Plattform (SDK)
Data points
PXC001.D PXC001-E.D PXA40-RS1 PXA40-RS2
PX KNX 2,000 2,000 N/A N/A

PX Modbus 250 250 800 2,000

PX M-Bus 250 250 800 2,000

PX SCL 250 250 800 1,000

PX RS-Bus 2,000 2,000 N/A N/A

PX Pronto 2,000 2,000 N/A N/A

Table 107: Data points

The platform for integrating LonWorks compatible third-party devices consists of:
● System controller PXC00.D and automation station PXC50.D, PXC100.D or
PXC200.D for integrating LonWorks devices via BACnet/LonTalk
● System controller PXC00-E.D and automation station PXC50-E.D, PXC100-
E.D or PXC200-E.D for integrating LonWorks devices via BACnet/IP
● PXX-L11 and PXX-L12 expansion modules for 60 and 120 LonWorks devices
PXC00..D with PXX-L11/L12 supports the firmware versions V4.1, V5.0, V5.1 and
V6.0.
PXC50..D, PXC100..D and PXC200..D with PXX-L11/L12 support the firmware
versions V5.0, V5.1 and V6.0. For information about the system limits, see chapter
System Configuration.
PX KNX PX KNX connects KNX networks with Desigo and maps the group addresses to
BACnet datapoints. PX KNX can handle the following main tasks:
● Data compression on the automation level (group functions)
● Time control
● Alarming, device monitoring
● Trend storage
● Mapping the Desigo RXB applications to BACnet for operating and monitoring
PX KNX supports the integration of:
● KNX S mode third-party devices
● RDF, RDG and RDU room thermostats
● RXB room automation stations
The PXC001.D system controller can integrate KNX via BACnet/LonTalk. The
PXC001-E.D system controller can integrate KNX via BACnet/IP. PX KNX is
preinstalled on PXC001..D controllers.
PX Modbus PX Modbus connects Modbus devices or networks supporting the Modbus protocol
to the Desigo system and maps their data points to BACnet data points. PX
Modbus is particularly suitable for integrating industrial controls or chillers and
linking them to the automation process.
The PXC001.D system controller can integrate Modbus via BACnet/LonTalk. The
PXC001-E.D system controller can integrate Modbus via BACnet/IP. The PXA40-
RS1 and PXA40-RS2 option modules support additional data points.
See PX Modbus (CA2N9772).
PX M-Bus PX M-Bus connects the M-Bus consumption meters to the Desigo system and
maps meter readings and device-related meter information to BACnet data points.
PX M-Bus handles the following main activities:

322 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
Integration on Field Level
19

● Measurement of consumption data and remote monitoring of max. 250

consumption and heat meters
● Compression of data from consumption and heat meters at the automation
level
● Alarm handling, device monitoring
● Trend storage to record meter readings
The PXC001.D system controller can integrate M-Bus via BACnet/LonTalk. The
PXC001-E.D system controller can integrate M-Bus via BACnet/IP. The PXA40-
RS1 and PXA40-RS2 option modules support additional data points.
See PX M-Bus (CM2N9774).
PX SCL PX SCL lets you quickly develop simple protocol solutions. The script control
language from XWP is used with an interpretable environment and lets engineers
create a solution. The solution cannot be used for complex protocols and solutions.
It is used to develop other applications, such as local serial printer driver and pager
applications.
The PXC001.D system controller can integrate SCL via BACnet/LonTalk. The
PXC001-E.D system controller can integrate SCL via BACnet/IP. The PXA40-RS1
and PXA40-RS2 option modules support additional data points.
The regional companies develop the necessary protocols themselves.
The hotel management system Fidelio can be integrated into Desigo via PX SCL.
See PX SCL (CA2N9773).
PX LON PX LON connects LonWorks networks to Desigo and maps Standard Network
Variables (SNVT) to BACnet data points. The main functions of PX LON are:
● Compression of Desigo RXC room automation stations and third-party data
● Mapping Desigo RXC applications to BACnet for operation and monitoring
(grouped as HVAC, lighting and blind control functions)
● Higher-level control and optimization functions, such as room and zone-based
groups, time control, and system functions, such as changeover,
summer/winter compensation, etc.
● Alarm handling, device monitoring
● Trend storage
PX LON maps RXC applications in such a way as to produce a room view. This
enables the rooms to be grouped together, for example, for shared occupancy
programs, or for shared commands for the control of lighting or blinds.
The PXC00.D system controller and the PXC50.D, PXC100.D and PXC200D
automation stations can integrate LonWorks devices via BACnet/LonTalk. The
PXC00-E.D system controller and the PXC50-E.D, PXC100-E.D and PXC200-E.D
automation stations can integrate LonWorks devices via BACnet/IP. With the PXX-
L11 and PXX-L12 expansion modules you can connect 60 and 120 devices.
PX Open Platform SDK HQ provides the PX Open Platform Software Development Kit (SDK) for experts in
the regional companies.

19.3 Integration on Field Level

The integration of third-party devices and systems on the field level is appropriate:
● For communicative pumps, meters, etc.
● For small numbers of data points (10 to 100/160 data points)
TX Open is suitable for the integration of a few data points (from 10 to 160 data
points). These data points can be processed further in the automation system or
used for visualization in Desigo CC.

323 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
19 Integration on Field Level

● The TXI1.OPEN module supports up to 100 data points and has an

RS232/RS485 interface.
● The TXI2.OPEN module upports up to 160 data points and has in addition an
ethernet connection for remote access, diagnosis and remote engineering.
● The TXI2-S.OPEN module supports up to 40 data points.
The TXI1.OPEN or TXI2.OPEN module is loaded with the protocol applications for
Modbus/M-Bus/GENIbus/G120P and then works as the Modbus/M-
Bus/USS/GENIbus master. The values of the Modbus/M-Bus/GENIbus/G120P
data points and the status of the existing data connection with the data points are
transmitted to the automation station via the island bus and mapped to BACnet
objects in the automation station. This way, the Modbus/M-Bus/GENIbus/G120P
data points can be made available to all the devices and applications in the Desigo
system.
The PXC50..D, PXC100..D and PXC200..D automation stations support TX Open.
You can attach up to five TX Open modules to one PXC automation station.
Xworks Plus (XWP) is used to engineer all solutions. Various compounds are
available, for example, for pumps, variable speed drives and heat meters.
Predefined solutions allow for simple commissioning. Solutions for Grundfos, Wilo,
Danfoss and G120P are delivered as part of the HQ CAS Library. For M-bus and
Modbus, sample solutions serving as device description templates are provided
(TX Open templates).
The following solutions on the TX Open platform are available:
● TX Modbus
● TX M-Bus
● TX G120P/SED2
● TX Grundfos via GENIbus
● TX Open platform (SDK)
TX Modbus TX Modbus supports Modbus RTU and Modbus TCP, Wilo pumps and variable
speed drives. TXI2.OPEN supports 160 data points. They may be distributed in
any fashion to the devices for the Modbus system. The number of devices is only
limited by the 160 data points.
See TX Modbus Engineering Guide (CM110571).
TX M-Bus TX M-Bus supports templates for meters. The regional companies can create
templates. You need a level converter for TX M-Bus. TXI2.OPEN supports 160
data points. They may be distributed in any fashion to the devices for the M-bus
system. The number of devices is only limited by the 160 data points.
See TX M-Bus Engineering Guide (CM110572).
TX G120P TX G120P supports the integration via the Modbus and USS protocol. You can
integrate up to eight G120P variable speed drives per TX Open module into the
Desigo system.
See TX G120P Engineering Guide (CM110576).
TX SED2 TX SED2 supports the integration via the USS protocol. You can integrate up to
eight SED2 variable speed drives per TX Open module into the Desigo system.
You can add new G120P variable speed drives to an existing TX Open (USS) with
already installed SED2 drives, for example, when:
● A defective SED2 needs to be replaced with a G120P in an existing project
● An existing project with installed SED2 drives needs to be extended with a new
G120P
See TX SED2 Engineering Guide (CM110573).
TX Grundfos via GENIbus TX Grundfos supports the integration of Grundfos via GENIbus. You can integrate
up to eight Grundfos pumps into the Desigo system.
See TX Grundfos / GENIbus Engineering Guide (CM110574).

324 | 377
Siemens CM110664en_03
2017-09-18
 Desigo Open
Integration on Room Level
19

TX Open Platform (SDK) HQ provides the TX Open Platform Software Development Kit (SDK), including
training, for experts in the regional companies. The training course provides the
necessary tools and knowledge to create new protocol applications.

19.4 Integration on Room Level

See chapter Network Architecture.

325 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
20 Integration on Room Level

20 Desigo S7 Automation Stations

Desigo S7 offers an expansion of the Desigo product portfolio with Simatic S7 for
applications requiring programmable logic controllers (PLC) at the automation level.
Desigo S7 uses the components spectrum for the Simatic S7-300, supplemented
by the BACnet communications processor CP 343-1 BACnet.
Desigo
Terminal Server
with high availability solution
RDT client

PXM20
Operator unit

BACnet/IP
Ethernet

RS232

PCX100/200-E.D TX-I/0 RS232

PXM10 Modular modules
Operator unit
S

TOUCH
PXM10 PXC...D
Operator unit Compact

SIMATIC S7 300 CP343-1BACnet TP177B

Automations station Communication processor Touch panel

PROFIBUS DP / PROFINET/IP

Peripheral device system

ET200S

Figure 235: Desigo S7 topology

The most important features are:

● Usage of Simatic S7 components and tools (input and output components,
network adapters, Step7 Manager, CFC Tool) in one integrated Desigo System
● HVAC library with standardized and test blocks and applications
● Use of standard communication BACnet, Ethernet TCP/IP, PROFINET,
PROFIBUS DP, KNX, ASI, Modbus
● Decentralized periphery ET 200S for distributed plants, larger distances, use of
integrated motor starts and a high degree of accuracy
Desigo S7 is designed for S7-300 automation stations.
H/F systems from the Simatic family are not supported.
Desigo S7 supports BACnet/IP at 10/100 bps for connecting Desigo CC or other
BACnet clients and for peer-to-peer data exchange with Desigo PX or other
BACnet servers. On the field level, PROFIBUS/IP and PROFINET are supported
directly. Other Simatic S7 stations are connected via Ethernet/IP or the PROFIBUS
S7 Protocol.

Market performance packages

Desigo S7 includes the market performance packages:
● Desigo S7 Building Solution
● Desigo S7 Building Integration

326 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
Product Range Overview
20

Desigo S7 Building The market performance package Desigo S7 Building Solution lets you expand a
Solution Desigo system using Simatic S7. Desigo S7 Building Solution is a complete
solution for industrial building automation and control. It expands the Desigo
system using Simatic S7 components and tools. The package uses the Desigo S7
HVAC library which is modeled on the Desigo application library.
It includes the following expansions, in addition to the communications processor
CP 343-1 BACnet:
● Desigo S7 Library
● Desigo S7 Basis Tool
Desigo S7 Library The Desigo S7 Library consists of an HVAC block library based on the proven
Desigo applications concept and functionality of the Desigo PX firmware library and
the HVAC compound library. The compound library includes preconfigured,
documented and tested applications as the basis for project-specific applications.
Desigo S7 Basis Tool The Desigo Basis Tool is an engineering tool based on the CFC Standard Tool. It
provides consistent data and efficient engineering thanks to a common data basis
for automation software and BACnet configuration. The Desigo Basis Tool is fully
integrated into the Simatic tool environment. Software changes are possible during
operation (delta download).
Desigo S7 Building The market performance package Desigo S7 Building Integration allows for
Integration seamless integration of existing Simatic S7 automation stations into the Desigo
system via BACnet communication.
In addition to using existing Simatic S7 and tools together with the CP 343-1
BACnet communication processor, the market performance package also includes
the Desigo S7 Mapping Tool.
Desigo S7 Mapping Tool The Desigo S7 Mapping Tool maps process data to BACnet objects and has
conversion functions for adapting the format.

Runtime protection
The licensing model from Siclimat is used for Desigo S7. Licensing costs depend
on the number of BACnet objects used for the building solution market
performance package. The license key must be entered on the corresponding pin
for block AS_BASIC.
The license key is part of the project data in the mapping tool for the market
performance package.

20.1 Product Range Overview

Simatic S7 automation station
The modular automation station Simatic S7 for all industrial plants and for HVAC
applications for industry and infrastructure. The modular, fan-free design, simple
implementation of distributed structures, and user-friendliness of Simatic S7 make
it the convenient and cost-effective solution for a wide range of functions.
Several CPUs with different levels of performance, plus an extensive range of
modules with numerous convenient functions enable the user to select only the
modules actually required for the application concerned. If the required function is
later extended, the automation station can simply be upgraded as required, by
adding further modules.
A Simatic S7 system comprises:
● A central processing unit (CPU): Different CPUs are available for various
performance ranges, to some extent, CPUs with integrated PROFINET or
PROFIBUS DP interfaces.
● Signal modules (SM) for digital and analog inputs and outputs

327 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
20 Product Range Overview

● Communication modules (CP) for bus coupling and point-to-point connections

● Power supply modules (PS) for connection of the Simatic S7 to a supply
voltage of AC 120/230 V or DC 24 V
Usage scenarios:
● Connected to BACnet/IP, Ethernet TCP/IP system bus
● Stand-alone, with local TP177B touch panel

Communications processor CP 343-1

The communications processor CP 343-1 BACnet for the Simatic 300 automation
station allow for cross-electrical and mechanical installation building automation
and control and process automation. For example, you can use Simatic S7
automation stations and Desigo PX automation stations at the same time in plants
and buildings.
The communications processor communicates with Desigo CC via BACnet/IP. It
can also directly exchange data peer-to-peer between Desigo PX and Simatic S7.
The CP 343-1 BACnet communications process for Simatic S7-300 automation
stations exchanges data between a S7 automation station and Desigo automation
stations including as third-party providers of BACnet clients.

Simatic ET 200 S
In conjunction with Simatic S7, digital and analog inputs and outputs can be linked
to the central control system via the PROFINET or PROFIBUS DP field bus system.
The peripheral devices can perform central control sub-functions independently.
Sections of the plant can be tested and commissioned in advance. In the event of
an error, stand-alone elements can continue to operate autonomously.

TX-I/O for Simatic

The PROFINET BIM allows you to use TX-I/O modules in plants with Simatic S7
via PROFINET communications.
This allows you to take advantage of the TX-I/O module benefits featuring, for
example, integrated local manual operation, cheaper integration of analog signals,
and support of typical HVAC field devices in plants with Simatic S7.
Engineering occurs via the standard PROFINET engineering workflow (Simatic
Manager). TX-I/O properties are available in the product range-specific device root
file (GSDML file) of the Profinet BIM. The GSDML file serves as engineering basis.

SBT TP177B touch panel

The SBT TP177B touch panel serves to locally operate and monitor the Simatic S7
automation station. It provides access to all data points and the associated
parameters (for example, messages and switch commands) in all plant. Normally
the unit is built into the control panel door.
The SBT TP177B enables the user to locate faults, operate and optimize the
operation of plant and equipment such as heating coils and fans, and modify switch
times.

Ordering
All Simatic components are ordered via the standard horizontal path at Siemens for
the relevant region.
The CP341-1 BACnet is ordered directly by SBT at the Distribution Center
Nuremburg.
The touch panel TP177B is ordered via the configuration center at SBT Zug.
Desigo S7 tools and library are downloaded via the SBT Standard Download
Server.

328 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
System Limits
20

20.2 System Limits

The following table shows the system limits for Desigo S7:

Item Limits
Configured alarm recipient (number of entries on the NC recipient list) 30

Number of peer to peer objects by BACnet (as client) approx. 50

COV subscriptions as server (If > 400 decrease of updating performance) approx. 400

BACnet object in the CP for building integration approx. 1000

Number of BACnet I/O objects including typical HVAC application* for building solution:

CPU 314 ..314-1AG13 / 96 KB approx. 20

CPU 314 ..314-1AG14 / 128 KB approx. 40

CPU 315-2DP ..315-2AG10 / 128 KB approx. 40

CPU 315-PN/DP ..315-2AH14 / 256 KB approx. 150

CPU 315-PN/DP ..315-2EG10 / 128 KB approx. 40

CPU 315-PN/DP ..315-2EH13 / 256 KB approx. 50

CPU 317-2DP ..317-2AJ10 / 512 KB approx. 200

CPU 317-PN/DP ..315-2EJ13 / 512 KB approx. 200

CPU 317-PN/DP ..315-2EK13 / 1000 KB approx. 200

CPU 317-PN/DP ..317-2EK14 / 1000 KB approx. 800

CPU 319-PN/DP ..318-3EL00 / 1400 KB approx. 800

Number of function block instances in the CFC chart 32767

Trend Log – limited only by available RAM in the CPU Depends on RAM*

Scheduler – limited only by available RAM in the CPU Depends on RAM*

Calendar – limited only by available RAM in the CPU Depends on RAM*

Max. number of TP177 on a CPU 3

Max. number of CPUs on a TP177 4

Communication between S7-Station (send – receive) Max. 3 partner

Max. 200 Bytes
Min. clock pulse 5 sec. for send

Table 108: Desigo S7 system limits

Key:
* A calculation table is available for a more precise calculation.

20.3 Alarm Management

Alarm Management in Desigo S7 is almost identical to alarm management in
Desigo PX. The BACnet objects displayed in the following figure are equipped with
intrinsic reporting. The objects report alarms to the assigned notification class
objects. The notification class objects forward the alarms to the assigned BACnet
clients.

329 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
20 Alarm Management

Figure 236: Alarming and Eventing

Desigo S7 Desigo PX
Principle The Notification Class (NOTIFCL) is local and applies Notification Class is a server function that applies
per automation station only. globally for the entire site.

Number of Notification One NOTIFCL required per automation station in the 48 NOTIFCL blocks per automation station in the
Class objects Global chart. Global chart.
All entries are made in this block.

Number of alarm classes 32 alarm classes (only 6 are used in the library). 16 alarm classes (only 6 are used in the library).

Table 109: Notification Class Object [NOTIFCL]

See Desigo S7 Building Integration (CM110890).

Detailed differences in the implementation

The following figure shows a typical application of blocks associated with the alarm
strategy.

Figure 237: Alarm blocks

330 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
Control Concept
20

Desigo S7 Desigo PX
Number of objects One CMN_ALM per BACnet hierarchy A CMN_ALM block per plant

Function Gather alarms Gather and filter alarms

Map to BACnet hierarchy

Mechanism Interconnect: All alarmable blocks must be Referencing – automatic

interconnected to the CNM_ALM.
Unwired object must be individually acknowledged via
a BACnet client.

Table 110: Common alarm [CMN_ALM]

Alarms can be acknowledged via the TP177B, which is wired on the CMN_ALM -
Acknowledge a BACnet hierarchy level.
Alarmable blocks not interconnect on the CMN_ALM may only be operated via a
BACnet client.

Desigo S7 Desigo PX
Principle Interconnected with CMN_ALM (optional functionality) Integrated in CMN_ALM

Number of objects One block per BACnet hierarchy A CMN_ALM block per plant

Number of filters Four filters per block – multiple blocks may be used Five filters

Table 111: Alarmfilter [ALM_FIL]

Desigo S7 Desigo PX
Function Light control Compound solution using the same functional scope
Flash speed depends on the alarm input

Table 112: Request indicator [REQ_IND]

20.4 Control Concept

Open-loop control strategy
The control strategy of the Desigo S7 building solution market performance
package is identical to the control concept for Desigo PX. Desigo S7 cannot,
however, reference BACnet to interfaces for other blocks for technical reasons. As
a result, all bindings between the blocks are wired.
Control blocks cannot use the PX look-ahead mechanism.
Interconnection in CFC and not BACnet referencing is used for superposed control
blocks to communicate with the commanding aggregates.
In contrast to Desigo PX, the scheduler cannot switch the objects to be controlled
via BACnet communication, but rather via wiring.

Control strategy
The control strategy for Desigo S7 is similar to the control strategy for PX.
The strategy comprises the following function blocks:
● PID_CTR: As individual controlled or wired (FmHigher/ToLower). It can be
used as a sequence controller. The block is mapped on a standard BACnet
loop object. This expands the interface for Desigo S7.
● CAS_CTR: A cascade controller like in PX.
● SEQLINK: The block binds multiple PID_CTR blocks to a sequence controller.
The block offers benefits primarily during engineering (PX).

331 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
20 Desigo S7 Block Library

20.5 Desigo S7 Block Library

Block concept
The block concept for the building solution market performance package is the
same as for Desigo, that is, interfaces and function distribution are the same.
Deviations to these concepts are explicitly described in this document.
The block interfaces correspond to BACnet version 1.5.

Changes to data types

The building solution market performance package is used to engineer the
standard CFC editor. To this end, some data types, which are specially supported
in Desigo, were changed at the block interfaces. The data types can still be
operated. The changes primarily effect time data types Long Duration and Short
Duration and date formats using jokers.
Storage for an optimized concept was selected. There are short and long runtimes
or monitoring times.

Command Control CMD_CTL

The block ensures that individual plant aggregates (optimized for ventilation plants)
are switched on or off in a certain order.
The differences to Desigo PX are:
● The normal signal flow between the blocks (interconnection) is used to
exchange data with the aggregates. The Standard CFC Editor does not contain
a Plant Control Editor. CMD_CTL cannot be used to reference aggregates via
BACnet.
● CMD_CTL has only two priorities for commanding: High priority (for example,
safety) and low priority (for example, program). The interconnection determine
the priority on the aggregate.
● The LookAhead function is not available on CMD_CTL.
● The CMD_CTL does not have switch-on and off delays. They must be
implemented on the aggregates. The OpSta feedback is used to consider
delays for switching.
● The CMD_CTL does not have a BACnet alarm function.
The control strategy itself is, however, identical to Desigo PX.

Power Control PWR_CTL

The block ensures that individual plant aggregates (optimized for ventilation plants)
are switched on or off in a certain order and at certain output.
The differences to Desigo PX are:
● The normal signal flow between the blocks (interconnection) is used to
exchange data with the aggregates. The Standard CFC Editor does not contain
a Plant Control Editor. PWR_CTL cannot be used to reference aggregates via
BACnet.
● PWR_CTL has two priorities for commanding: High priority (for example, safety)
and low priority (for example, program). The interconnection determine the
priority on the aggregate.
● The LookAhead function is not available on PWR_CTL.
● PWR_CTL does not have a BACnet alarm function.

I/O blocks
Emergency operation Manual operation can be recorded directly on the I/O Module using Desigo. For
(local override) Desigo S7, local manual override is logged on the module level via its own
feedback signal. The blocks BO, AO and MO have the pin [Ovrr] for this purpose.
In contrast to Desigo, the value of manual operation is not issued on PrVal.

332 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
Operating States
20

Peer-to-peer blocks
Blocks AO_PTP, BO_PTP and MO_PTP (FB327) write a value to the BACnet
object (command via BACnet). The block is used to write a process value via
BACnet to another automation station (commanding).

Memory optimized block pins

The pin sequence on Desigo S7 blocks differ from the sequence for Desigo, since
they are memory optimized (application-oriented in the case of Desigo).

Dynamic memory ranges

The block TRNDLOG stores the BACnet values on the CPU.

Alarm blocks (CMN_ALM, ALM_FIL)

The differences to Desigo PX are:
● In Desigo S7, all notification classes are compiled in block NOTIFCL.
● The Common Alarm block in the CFC is nested with the block generating the
alarm.

Device object
Each automation station contains a device object, which in turn contains the device
and system information for that automation station. The device object is a standard
BACnet object, representing the entire Desigo S7 automation station and, among
other, includes a list of all processed BACnet objects.

20.6 Operating States

The following table shows the operating states in Desigo S7:

S7-CPU RUN Normal operation - application software is processing

S7-CPU STOP Digital outputs are reset. Application software and BACnet communication are not processed.
The STOP state is achieved:
- After a fatal error in the S7 CPU
- During initial configuration
- During a full download
- When the operator uses the STOP switch
- When operated with the S7 – Manager

BACnet – IP RUN BACnet/IP allows Ethernet communication including BACnet/IP and S7 communication.
BACnet communication can also be interrupted in RUN mode. Reasons:
- No BACnet configured (S7 – hardware configuration)
- Reconfiguration is running
- Fatal error BACnet – CP

BACnet – IP STOP BACnet/IP allows PG functions via Ethernet, for example, restart or diagnostics.
The STOP state is achieved due to:
- Fatal error BACnet - CP
- User operation

Table 113: Desigo S7 operating states

20.7 Error Sources and Monitoring Functions

The following table shows some examples of errors and their effects:

333 | 377
Siemens CM110664en_03
2017-09-18
 Desigo S7 Automation Stations
20 Error Sources and Monitoring Functions

Error Effect
1) Fatal error in S7-CPU, for example, memory command S7 goes to STOP.
code. All binary outputs are reset.

2) Potentially dangerous process state in S7-CPU, for The application is no longer processed.
example, faulty I/O periphery. An alarm is sent via BACnet.
BACnet communication is stopped.
S7 must be restarted locally or via remote following troubleshooting.

3) Non-critical error in S7-CPU An alarm is sent via BACnet.

4) Critical error BACnet-CP, for example, memory. BACnet communication is stopped.

BACnet communication must be restarted locally or via remote following
troubleshooting.

5) Non-critical error BACnet-CP, for example, buffer An alarm is sent via BACnet.
overloaded.

Table 114: Errors and effects

334 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Error Sources and Monitoring Functions
21

21 System Configuration
System overview

Figure 238: System overview

Terms
Desigo system Covers all the devices on the MLN (Management Level Network), ALN (Automation
Level Network) and FLN (Field Level Network).

335 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Error Sources and Monitoring Functions

One Desigo system may comprise several BACnet internetworks. These are
connected into a system with Desigo CC. In this case, Desigo CC appears as a
BACnet device in several BACnet internetworks.
BACnet internetwork A BACnet internetwork consists of one or several BACnet networks. Individual
BACnet networks are connected to BACnet routers.
Each BACnet device can communicate with another BACnet device in the
internetwork. A BACnet device in one internetwork cannot communicate with a
device in another internetwork.
A Desigo management station can be used to integrate the operation of several
BACnet internetworks and other systems (see Desigo system).
When defining the system configuration, FLN integrations (LonWorks, KNX) are
also added to the BACnet internetwork. In this way, the Desigo system can be
seen as a combination of several BACnet internetworks. Technically, the individual
FLN devices are not BACnet devices. They do not communicate via the BACnet
protocol.
BACnet PTP internetwork BACnet PTP communication uses modem (telephony) or null-modem (RS232)
connections. Owing to the slow rate of data transfer via these connections, the
limits are lower for a BACnet PTP internetwork. Modem-based PTP connections
are considered obsolete and are therefore no longer used. The BACnet PTP
communication connects BACnet networks via BACnet half routers.
BACnet network A quantity of BACnet devices connected within an IP or LonTalk or MS/TP network
with specific (that means, the devices are in the same BACnet Broadcast Domain)
limits. In the case of the LonTalk or MS/TP network, the limit is physical. In the
case of an IP network, the network can be physically the same, but the limit is
determined by different UDP ports.
Local communication between two BACnet devices in a BACnet network is not
visible in another BACnet network.
IP segment Sub-area of an IP network. IP segments are connected by IP routers.
In order to ensure that BACnet communications (Broadcasts) can always take
place across IP routers, BBMDs (BACnet Broadcast Management Devices) are
required. PXG3.L/M and PXC…-E.D over IP can be configured as BBMDs.
Individual BACnet devices in an IP segment can register with a BBMD as foreign
devices.
LonWorks segment (ALN) Sub-area of a BACnet/LonTalk network. LonWorks segments are connected by
LonWorks routers. In most cases it is not necessary to divide a BACnet/LonTalk
network into several LonWorks segments (ALN).
It is not possible to use a LonWorks router because of the restricted length of the
data packets. An L-Switch can be used as a router on the ALN.
LonWorks segment (FLN) Sub-area of a LonWorks network. LonWorks segments are connected by
LonWorks routers.
An L-Switch or a LonWorks router can be used as a router on the FLN.
LonWorks trunk (FLN) Comprises all the devices connected on the FLN side of the PXC00.D/-E.D + PXX-
L1…. Consists of one or several LonWorks segments (FLN).
A LonWorks trunk (FLN) is the equivalent of a LonWorks network (FLN).
PX KNX integration Comprises the integration of KNX devices that are connected on the FLN side of
the PXC001.D/-E.D.
PX site A Desigo PX automation system site.
The PX BACnet devices which control the plant in a PX site are interconnected via
the global objects and the primary copy procedure.
A PX site is independent of the limits affecting the BACnet network. A site can
extend over several BACnet networks. One BACnet network may include several
sites. All the associated limits must be maintained simultaneously.

336 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Technical Limits and Limit Values
21

A PX site cannot be extended beyond the limits of a BACnet internetwork. This is

particularly important in the case of BACnet PTP internetworks.
PX plant A PX plant is part of a PX site and generally comprises several partial plants (plant
structure).
A PX plant can be distributed over several PX BACnet devices. In principle PX
BACnet devices can be distributed to different BACnet networks. However, owing
to the communications load between partial plants, this is not recommended.
The plant structure is mapped to BACnet by means of hierarchy objects. Operator
units with generic operation automatically read this structure.
BACnet MS/TP A BACnet MS/TP network is a BACnet network that is physically based on EIA-485
and operated using a BACnet-specific MasterSlave/TokenPassing data link
protocol (see BACnet standard clause 9). An MS/TP network is linked via a
BACnet router to a BACnet/IP or BACnet/LonTalk network.
Desigo Room Automation Includes the BACnet devices connected directly to BACnet/IP or BACnet MS/TP,
used for room automation.
These BACnet devices are not part of a PX site. There is no connection via global
objects and the primary copy procedure.
Desigo Room Automation In Desigo Room Automation, primary subsystem control functions are centralized
system functions as Desigo Room Automation system functions.
PX system functions A PXC.. of a PX site as PX system function can assume Desigo Room Automation
subsystem functions such as scheduling, life check, time synchronization for a
Desigo Room Automation system function group for BACnet devices for room
automation.
System function group A Desigo Room Automation system function group cannot be identified or defined
via the network topology. Engineering the Desigo Room Automation system
functions of the PX system functions determines the Desigo Room Automation
system function group.
For more information, see chapter System Overview and Network Architecture.

21.1 Technical Limits and Limit Values

There are two types of limits:
● Technical limits (hard-coded limits) are maintained by technical means. They
cannot be exceeded.
● Recommended limits (soft limits) are not enforced by technical means. They
can be exceeded.
The limits are defined to ensure the full and correct functioning of the system.
Consult Headquarters before exceeding the recommended limits. HQ can
modify the recommended limits on the basis of new findings at any time.
Changes are notified in Facts bulletins.
Certain limits cannot be verified (for reasons of cost or quantity). These limits are
shown in this document as follows:

This limit type… …is shown like this Example

Technical limit verified Limit* 60*

Technical limit NOT verified [Limit*] [50*]

Recommended limit verified Limit 64

Recomended limit NOT verified [Limit] [1'000]

Limit subject to proviso (refer to footnotes) (Limit) (10)9

Table 115: Verified and non-verified limits

337 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Networks

21.2 Networks
The following table shows the maximum number of elements, permitted in a
network area.
The columns show the network area. The rows show the maximum number of
elements permitted in the network area. For example, network area: BACnet
internetwork; number of elements: BACnet/LonTalk network. Maximum number of
BACnet/LonTalk networks per internetwork = 100.

Number of elements / Per Desigo BACnet BACnet BACnet/ BACnet BACnet/ LonWorks PX KNX PX site
network area system inter- PTP inter- IP MS/TP LonTalk trunk inte-
network network network network network (FLN) gration
Desigo topology

BACnet internetwork 200 n/a n/a n/a n/a n/a n/a n/a

BACnet PTP internetwork 118 n/a n/a n/a n/a n/a n/a n/a

BACnet/IP network n/a 10 [50*] [1]19 n/a n/a n/a n/a [total 20]

BACnet MS/TP network n/a [50] n/a 8 n/a n/a n/a n/a

BACnet/LonTalk network [3] n/a n/a n/a n/a n/a n/a

PXG3.M/L (BACnet router) n/a [100] [30] [100] 1 1 n/a n/a n/a

IP segment n/a 10 [50*] 6 [50*] 6 10 [50*] 6 n/a n/a n/a n/a n/a

LonWorks segment (ALN) n/a [100] [30] n/a n/a 1 n/a n/a n/a

PX site [1,000] [30] 5 n/a n/a n/a n/a n/a n/a

PX plant [4,000] [2,000] [60] n/a n/a n/a n/a n/a 100

LonWorks trunk (FLN) [200] [100] [30] n/a n/a n/a n/a [50]

LonWorks segment (FLN) n/a n/a n/a n/a n/a n/a [5] n/a [250]

PX KNX integration [200] [100] [30] n/a n/a n/a n/a [50]

Desigo devices

PX… without DXR2/PXC315 [2,000] [1,000]9 [30] [200]8 n/a 30 n/a n/a 50/10017

PXC3.E (Desigo Room (10,000)16 [1,500] n/a 25023 n/a n/a n/a n/a n/a15
Automation) (2,500) [500]24

DXR214 (Desigo Room (10,000)16 [1,500] n/a 25023 6421 n/a n/a n/a n/a15
Automation) (2,500) [500]24

Desigo CC 10 10 n/a 10 n/a n/a n/a n/a n/a

PXM20 n/a (10)9 10 n/a n/a 10 n/a n/a total 1510

PXM20-E n/a (50)9 [20] [50] n/a n/a n/a n/a total 1510

PXA40-W1/W2 (integrated n/a (15)9 [15] [15] n/a [15] n/a n/a total 1510
web server)

Desigo Xworks Plus (XWP) n/a [10] [10] [10] n/a [5] n/a n/a total 1510
(commissioning)12

Total LonWorks nodes [40,000] [20,000] [6,000] n/a n/a n/a 3002 n/a [10,000]

RXB [8,000] [2,000] [1,200] n/a n/a n/a n/a 454 [2,000]

Data points and BACnet objects

Physical data points [100,000] [100,000] [3,000] [20,000] n/a n/a n/a n/a [6,000]

Total BACnet objects [500,000] [100,000] [30,000] [100,000] [3,000] [30,000] n/a n/a [50,000]

Trendlog object [30,000] [2,500] [200] [2,500] [540] [600] n/a n/a [1,000]

338 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Networks
21

Table 116: Number of elements per network area

Key:
n/a Not applicable.
– No restrictions.
2 Not the same as the number of integrated devices ( PXC00.D/-E.D + PXX-L…).
3 LonWorks routers must not be used at the automation level.
4 Limit applies only if this device type is used exclusively.
6 For higher performance use a PXG3 instead of a PXC-E.D for the BBMD function.
7a Limit for PXC00.D/-E.D + PXX-L11.
7b Limit for PXC00.D/-E.D + PXX-L12.
8 Limit for PX devices without Desigo Room Automation (due to PX web support of a PX site). Do
not exceed the number of PXC devices per site.
9 The limit on the number of PX automation stations per internetwork can only be maintained if no
PX clients (PXM20, PXM20-E, PXA40-W1/W2) are used. PX clients limit the permissible number
of PX per internetwork. The values can be obtained by reference to the relevant automation
station columns. The restricted view option does not affect the system configuration of PX clients.
10 The number of temporary alarm receivers in a PX is a technical limit. The recommended limit is
lower. This takes account of the fact that additional devices may be connected for service
purposes.
11 The number of temporary alarm receivers in a PX is a technical limit. The recommended limit is
lower. This takes account of the fact that additional alarm receivers (third-party) may have entries
in this list.
12 Parallel engineering (commissioning ) is possible subject to the following restrictions:
- Node setup: Only one XWP per LonTalk/IP segment.
- Download and online operation: only one XWP for each automation station.
14 In pressurized rooms with or without fume hood, all automation stations of a room must be
connected to a switch in a starlike manner to ensure high availability.
15 Desigo Room Automation automation stations do not belong to a PX site (no primary copy
function).
16 For the system configurations of the Desigo CC management platform, see Desigo CC System
Description (A6V10415500).
17 50: If Lon PX exists in the PX site. 100: If no Lon PX exist in the PX site (only IP PX).
18 These limits in the Desigo system refer in particular to Desigo Insight. The limits may be
significantly lower due to the PTP connection(s) outside the Desigo system and their technical
limitations. Examples of such limitations outside the Desigo system can include available
bandwidth for the PTP link or available modem speeds.
19 This limit can be exceeded if all BACnet devices are located within the same IP subnetwork, or if
no communication between the various BACnet/IP networks is required.
20 These limits apply only to IP-based DXR2 devices.
21 These limits apply to MS/TP-based DXR2 devices.
23 Multiple IP segments per BACnet internetwork.
24 One IP segment per BACnet internetwork.

For more information about networks, see Application Guide for IP Networks in
Building Automation Systems (CM110668).

21.2.1 Desigo Room Automation System Function Group

A Desigo Room Automation system function group comprises parts of the Desigo
Room Automation automation stations on the BACnet internetwork. Grouping

339 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Networks

occurs based on Desigo Room Automation automation stations aassignment to PX

system function responsible for the Desigo Room Automation subsystem functions.
Desigo Room Automation defines Desigo Room Automation system functions
comprising life check and time synchronization.
The current limits for the Desigo Room Automation system function group are
mainly imposed by life check and scheduling carried out by the Desigo Room
Automation system function PX. To this end, the total number of the following
external BACnet references are planned per Desigo Room Automation system
function PX used: Approximately 200 (on PX V5.x) or approximately 500 (on PX
V6.x).
A PXC3 generally controls several (about 5..8) multiple rooms. The number of
rooms in the Desigo Room Automation system function group are the decisive
factor for some limits.
Desigo Room Automation automation stations are not part of a PX site. Data are
not aligned between the primary PX site and the Desigo Room Automation
automation stations.
Desigo Room Automation automation stations do not support BBMDs. This
restricts the BACnet/IP network, that is, all Desigo Room Automation automation
stations and their Desigo Room Automation system function PX or a PXG router
must be located in the same IP segment.

Desigo Room Automation automation stations with own alarming

Item Limit Description
Trend per room 5 It is assumed that a maximum of 5 trend points are logged on
average. Assumption for the trend interval: 15 minutes.

Number of external BACnet references 500 Maximum number of external BACnet references that support a
Desigo Room Automation system function PX. The Desigo Room
Automation system function PX requires external references for the
life check and for scheduler functions. Examples of objects with
external references:
- EventEnrollment: 1reference
- Schedule: 1-5 references

Event Enrollment per Desigo Room 1 Number of Event Enrollment objects required on the Desigo Room
Automation automation station Automation system functions PX for the life check per Desigo Room
Automation automation station.

Sample number of Desigo Room Automation 250 Desigo Room Automation system function PX with maximum
automation stations per Desigo Room scheduler functions.
Automation system function group The limit designates the maximum number of Desigo Room
Automation automation stations in the Desigo Room Automation
system function group. In this example, it is assumed that the
following scheduler objects are available on the Desigo Room
Automation system function PX:
- Maximum number of scheduler objects
- Per scheduler object, maximum number of external references

Sample number of Desigo Room Automation 500 Desigo Room Automation system function PX without scheduler
automation stations per Desigo Room functions.
Automation system function group The limit designates the maximum number of Desigo Room
Automation automation stations on the Desigo Room Automation
system function group. In this example, it is assumed that no
scheduler objects are available on the Desigo Room Automation
system function PX.

Table 117: Desigo Room Automation automation stations with own alarming (Desigo V6.x)

340 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

21.3 Devices

21.3.1 PXC..D Automation Stations / System Controllers

Item PXC..-E.D PXC50.D PXC100.D PXC200.D PXC00.D PX Open10 PX KNX9
PXC...D PXC50.E.D PXC100-E.D PXC200-E.D PXC00-E.D PXC001.D PXC001.D
PXC-NRUF modular modular modular PXC001-E.D PXC001-E.D
compact + PXA40-RS..

Temporary alarm 18* 18* 18* 18* 18* 18* 18*

receiver1

Configured alarm 20* 20* 20* 20* 20* 20* 20*

receivers2

BACnet references [1,400*] [1,400*] [1,400*] [1,400*] [1,400*] [1,400*] [1,400*]

COV server resources 3

BACnet references 400* 650* 650* 650* 650* 650* 400*

COV client resources 4 PXC36-E.D PXC50-E.D PXC100-E.D PXC200-E.D PXC00-E.D
950* 950* 950* 950* 950*
Total BACnet objects [4,000] [4,000] [4,000] [4,000] [4,000] [4,000] [4,000]

Number of function block 1,900* 1,900* 1,900* 2,900* 1,900* 2,900* 2,900*
instances (application
size)

Trend log5 100 100 200 350 200 600 100

Trend log multiple19 20 20 20 20 20 120 20

Scheduler 1517 5018 5018 5018 5018 1517 1517

PXC001:5017 PXC001:5017
Calendar14 10 50 50 50 50 10 10
PXC001:50 PXC001:50
PXM10 1 1 1 1 1 1 n/a

PPS2 devices (ALN)8 5 n/a n/a n/a n/a 5 n/a

(e.g. QAX3.x, RXZ90.1)

Physical data points n/a 52* 200* 15 (350)15 n/a n/a n/a
I/O module (TX-I/O, PTM)

Total number of data n/a 400* 600* 15 (1,000) 15 n/a n/a n/a
points (TX-/I/O, PTM and
TX Open)

TX Open per island bus n/a 516 516 516 n/a n/a n/a

PXX-PBUS n/a 1 1 1 n/a n/a n/a

P bus BIM TXB1.PBUS12 n/a n/a n/a n/a n/a n/a n/a

Dynamic calendar 10* 10* 10* 10* 10* 10* 10*

objects20

Dynamic event enrollment 50* 50* 50* 50* 50* 50* 50*
objects20

Dynamic notification class 50* 50* 50* 50* 50* 50* 50*
objects20

Dynamic schedulers 10* 10* 10* 10* 10* 10* 10*

Dynamic trend log 100* 100* 100* 100* 100* 100* 100*
objects20

Dynamic trend log 20* 20* 20* 20* 20* 20* 20*
multiple objects 20

341 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

Table 118: Automation stations / system controllers PXC..D

Key:
n/a Not applicable
1 PXM20, PX-Web and XWP are temporary alarm receivers.
2 Desigo CC is a configured alarm receiver.
The number of entries in the notification class is limited to 20. The total number of different
configured alarm receivers across all notification classes is limited to 30.
3 Max. number of SubscribeCOV requests which can be accepted.
Example: 400 1 client and 400 values 2 clients and 200 values.
4 Max. number of BACnet client references, values read from or written to (commanded) your own
automation station or a remote automation station.
BACnet client references are used in Input, Output, Scheduler, Trendlog and Group objects (all
NameRef_Type inputs with AddrKind = B). The configured alarm receivers of the Notification
Class objects do NOT require any BACnet client references.
The available number of BACnet client references shall address not more than 50 different
remote automation stations. If this value is exceeded the number of BACnet broadcast messages
on the network will increase.
5 Every active Trendlog object needs a BACnet reference.
Trends need 12 bytes per entry (irrespective of data type). Max. 64 KB can be allocated to the
log buffer (approx. 5,000 entries) for each Trendlog object. These log buffers are assigned in D-
MAP RAM. If the log buffer size is changed and there is insufficient D-MAP RAM available, the
Reliability property of the Trendlog object is set to Memory limit reached.
6 Max. number of physical data points (TX-I/O module) for PXC64-U is 200.
Max. number of physical data points (TX-I/O module) for PXC128-U is more then 200, however
the reaction times are in accordance with following table and the system limits to consider.
The number of physical data points influences the reaction time of the application. If minimum
reaction times are specified, the number of physical data points may have to be reduced.
The following relationship between reaction times and the number of physical data points can be
assumed:
- up to 150 physical data points = Reaction times < 1s
- up to 250 physical data points = Reaction times 1-2s
8 The address of the PPS-2 devices QAX84.1 and RXZ90.1 is always 1 (no address selection).
9 PX KNX = PXC001.D / PXC001-E.D and loaded PX KNX firmware.
10 PX Open = PXC001.D / PXC001-E.D with option module PXA40-RS1/RS2 and loaded PX Open
firmware.
14 Maximum 30 calendar entries.
15 Max. number of physical data points for PXC100.D/-E.D is 200.
Max. number of physical data points for PXC200.D/-E.D is more then 200, however the reaction
times are in accordance with following table and the system limits to consider.
The number of physical data points influences the reaction time of the application. If minimum
reaction times are specified, the number of physical data points may have to be reduced.
The following relationship between reaction times and the number of physical data points can be
assumed:
- up to 150 physical data points = Reaction times < 1s
- up to 250 physical data points = Reaction times 1…2 s
- up to 350 physical data points = Reaction times 2…3 s
16 Max. 5 TX Open per PXC50/100/200…D.

342 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

17 Number of switching times per day: 10; max. 5 BACnet references.

18 Number of switching times per day: 20; max. 5 BACnet references.
19 Every active trendlog multiple object needs a BACnet reference per logged value.
5 logged values are assumed for the number of trendlog multiple objects (number of Trendlog /
5).
Trends need 12 bytes per entry (irrespective of data type).
Max. 64 KB can be allocated to the log buffer (approx. 5,000 entries) for each trendlog object.
These log buffers are assigned in D-MAP RAM.
If the log buffer size is changed and there is insufficient D-MAP RAM available, the Reliability
property of the Trendlog object is set to Memory limit reached.
20 Dynamic objects are counted the same as non-dynamic objects for total limits.

D-MAP RAM If the whole D-MAP RAM is taken up with trendlog objects, a delta (differential)
download will no longer be possible.
The overall size of the free and used D-MAP RAM can be viewed with XWP,
Desigo CC or PXM20. The information concerned is stored in the device object
under the memory statistics property [MemStc].
Access rights Access rights are managed via USPRF. You can define a maximum of 10 user
management groups and 20 users. 10 user groups and 6 users are already predefined as a
template (global chart).

21.3.2 LonWorks System Controllers

Device combination: PXC00.D/-E.D + PXX-L11/12

Item Limit
LonWorks devices:
PXX-L11 60* (for example: 5 Group Members are defined, that means 5 x 12 = 60 COV resources are needed)
PXX-L12 120*
Max. number of integrated LonWorks devices covers RXC..., QAX50/QAX51 and third-party
LonWorks devices.

Discipline I/Os [600] max. number of discipline I/O objects

Groups [50] max. Number of groups

Room members No limits

Group members Cross-disciplinary groups can have more than 5 destinations. The number of cross-disciplinary groups
depends on the COV client resources (max. 250). A different number of COVs is required, depending
on the group type. These must be multiplied by the number of destinations.

Table 119: LonWorks system controllers

Calculation basis:

HVAC CHOGRP 1 COV client resource per destination

SPGRP* 12 COV client resources per destination

EMGGRP 1 COV client resource per destination

Lighting LIGHTGRP 2 COV client resources per destination

Blinds BLSGRP 4 COV client resources per destination

Building use USEGRP 3 COV client resources per destination

Room occupancy OCGRP 3 COV client resources per destination

LonWorks system controllers with physical I/Os and TX Open

Device combination: PXC50/100….D + PXX-L11/12

343 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

If the PXC50/100…D is used instead of the PXC00…D as a system controller,

physical I/Os can be integrated via TX-I/O modules and TX Open data points. The
reaction time can be greater for a larger number of physical I/Os or TX Open data
points, and depending on the complexity of the CFC program.

21.3.3 Automation Stations with LonWorks Integration

Device combination: PXC50/100/200…D mit PXX-L11
The modular automation stations PXC50/100/200.D and PXC50/100/200-E.D allow
the integration of LonWorks devices (RXC…, QAX50/QAX51 and third-party
devices) via PXX-L11 in addition to the use of I/O modules or third-party devices
via TX Open.
The integration on PXC50…D is limited to a maximum of 10 LonWorks devices.
The integration of LonWorks devices for PXC100/200…D is limited by response
times.
The following values can be assumed for reaction times depending on the number
of physical data points:

Reaction times depending on number of Without LonWorks devices Up to 5 LonWorks devices 5 to 20 LonWorks devices
physical data points
Max. 150 data points < 1s 1-2s 3-4s

Max. 250 data points 1-2s 2-3s 4-5s

Max. 350 data points 2-3s 3-4s 5-6s

Table 120: Reaction time

21.3.4 PX Open Integration (PXC001.D/-E.D)

Item Limit Description
Modbus data points [250*] Max. number of data points per PX Modbus.

SCL data points [250*] Max. number of data points per PX SCL.

M-bus data points [250*] Max. number of data points per PX M-bus.

M-bus meters [250] Max. number of M-bus meters in PX M-bus applications.

Table 121: PX Open Integration (PXC001.D/-E.D)

21.3.5 PX Open Integration (PXC001.D/-E.D + PXA40-RS1)

Item Limit Description
Modbus data points [800*] Max. number of data points per PX Modbus.

SCL data points [800*] Max. number of data points per PX SCL.

M-bus data points [800*] Max. number of data points per PX M-bus.

M-bus meters [250] Max. number of M-bus meters in PX M-bus applications.

Table 122: PX Open Integration (PXC001.D/-E.D + PXA40-RS1)

344 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

21.3.6 PX Open Integration (PXC001.D/-E.D + PXA40-RS2)

Item Limit Description
Modbus data points [2,000*] Max. number of data points per PX Modbus.

SCL data points [1,000*] Max. number of data points per PX SCL.

M-bus data points [2,000*] Max. number of data points per PX M-bus.

M-bus meters [250] Max. number of M-bus meters in PX M-bus applications.

Table 123: PX Open Integration (PXC001.D/-E.D + PXA40-RS2)

21.3.7 PX KNX Integration (PXC001.D/-E.D)

These limits also apply to PXC00-U.
The maximum number of devices only applies in cases where only one device type
is used. The following formula applies to mixed operation with third-party devices:
50 * RXB/RXL + third-party devices < 2,000 data points.

Item Limit Description

KNX/EIB data points [2,000*] Max. number of KNX data points that can be integrated (KNX
communication objects).

RXB 45 Max. number of RXB devices per KNX (approx. 50 KNX data points
per RXB, depending on the application).

RXL 45 Max. Number of RXL devices per KNX (approx. 50 KNX data points
per RXL, depending on the application).

Table 124: PX KNX-Integration (PXC001.D/-E.D)

21.3.8 TX Open Integration (TXI1/2/2-S.OPEN)

Item Limit Description
TXI1.OPEN 100* Max. number of data points per TX Open.

TXI2.OPEN 160* Max. number of data points per TX Open.

TXI2-S.OPEN 40* Max. number of data points per TX Open.

Table 125: TX Open Integration (TXI1/2/2-S.OPEN)

21.3.9 Number of Data Points on Desigo Room Automation

Automation Stations
Number of data points on the TX-I/O subsystem
Every used data point on TX-I/O is counted.

ASN Product description Data points Description

TXM1.6RL 6 I/O relay modules, bistable max. 6 Used TX-I/Os are counted.

TXM1.8RB 8 I/O blinds modules max. 8 Used TX-I/Os are counted (1 data point per
relay).

TXM1.8T 8 I/O triac modules max. 8 Used TX-I/Os are counted.

345 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

ASN Product description Data points Description

TXM1.8U 8 I/O universal modules (DI, AI, AO) max. 8 Used TX-I/Os are counted.

TXM1.6R 6 I/O relay modules max. 6 Used TX-I/Os are counted.

TXM1.8D 8 I/O digital input modules max. 8 Used TX-I/Os are counted.

TXM1.16D 16 I/O digital input modules max. 16 Used TX-I/Os are counted.

Table 126: Number of data points on the TX-I/O subsystem

Number of data points on DALI subsystem

Each individually controlled DALI lighting group and each individually controlled
ECB counts as 1 data point.

ASN Product description Data points Description

PXC3.E7xA Automation station max. 64 DALI lighting groups and/or individual DALI
PXC3.E16A-100A ECBs are counted.

Table 127: Number of data points on DALI subsystem

Additional DALI limits:

● Max. number of devices: 64
● Max. number of addresses: 64
● Max. number of groups: 16

Number of data points on KNX PL-Link subsystem

KNX PL-Link devices have a set count whereas KNX S-Mode devices are counted
according to the used group addresses.

ASN Product description Data points Description

RXM21.1 Fan coil PL-I/O 5 Fixed count

RXM39.1 Fan coil PL-I/O 5 Fixed count

QMX2.P33 Room operator unit with display and 3 Fixed count

temperature sensor

QMX2.P43 Room operator unit with display, temperature 4 Fixed count

and humidity sensor

QMX3.P02 Freely configurable operator unit, wall 5 Fixed count

mounted

QMX3.P30 Freely configurable operator unit, wall 1 Fixed count

mounted

QMX3.P36 Freely configurable flush-mounted room unit 3 Fixed count

QMX3.P34 Freely configurable operator unit, wall 3 Fixed count

mounted

QMX3.P37 Freely configurable operator unit, wall 7 Fixed count

mounted

QMX3.P40 Room operator unit without display, with 2 Fixed count

temperature and humidity sensor

QMX3.P70 Freely configurable operator unit, wall 3 Fixed count

mounted

QMX3.P74 Freely configurable operator unit, wall 5 Fixed count

mounted

QMX3.P87 Freely configurable operator unit, wall 3 Fixed count

mounted (fume hood)

346 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

ASN Product description Data points Description

QMX3.P88 Freely configurable operator unit, flush- 3 Fixed count
mounted (fume hood)

AQR253… Flush-mounted room sensor with: 1-3 Fixed count, 1 data point per measured value
AQR257… Front module (optional potential-free, passive NTC sensors
are not counted)
Base module

UP220/31 Switch interface 4 Fixed count

UP221/x Single switch 2 Fixed count

UP222/x Double switch 4 Fixed count

UP223/x Triple switch 6 Fixed count

UP287/x Quadruple switch 8 Fixed count

UP258D1x Occupancy, light sensor 2 Fixed count

UP255/D12 Brightness sensor 1 Fixed count

RL260xx 4 x binary input 4 Fixed count

RL512xx 1 x light 16A 1 Fixed count

RL513xx 3 x light 6A 3 Fixed count

RL521xx 2 x blinds 4 Fixed count

RL526D23 Switching/Dimming actuator 2 x AC 230 V, 10 2 Fixed count

A, 1 … 10 V

RS510xx 2 x light 10A 2 Fixed count

RS520xx 1 x blind 2 Fixed count

RS525xx 1 x light universal dim 1 Fixed count

UP285/x 1 x switch 2 Fixed count

UP286/x 2 x switch 4 Fixed count

UP287/x 4 x switch 8 Fixed count

UP510/xx 2 x light 10A 2 Fixed count

UP520/xx 1 x blind 2 Fixed count

UP525/xx 1 x light universal dim 1 Fixed count

N528D01 Universal dimmer, 2 x 300 VA, AC 230 V 2 Fixed count

GDB111.9E/KN Rotary actuator, AC 24 V, 5 Nm 1 Fixed count

GLB181.1E/KN Damper actuator VAV KNX, AC 24 V, 10 Nm 2 Fixed count

GDB181.1E/KN Damper actuator VAV KNX, AC 24 V, 5 Nm 2 Fixed count

KNX S-Mode Third-party device Group addresses used are counted

Table 128: Number of data points on KNX PL-Link subsystem

Additional KNX PL-Link limitations:

● Max. number of devices:
– 64 on PXC3.xx
– 32 on DXR2.xx
● The range of the Individual Address (IA) can be defined as follows in Desigo
Room Automation V6.0:
– KNX S-Mode: 1 … 179
– KNXnetIP: 180 und 181
– KNX PL-Link devices: 182 … 250
– Desigo Room Automation automation station: 251

347 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

– Max. number of KNX S-Mode group addresses: 238

21.3.10 Number of Data Points for PXC3

A PXC3.E72x supports max. 4 rooms or 8 room modules and is limited to 72 TX-
I/O data points.
A PXC3.E.75 supports max. 8 rooms or 16 room modules and is limited to 200 TX-
I/O data points.
These criteria must be satisfied to be able to select the correct PXC…:
● The physical TX-I/O data points used
● The total number of I/O data points used from TX-I/O, KNX PL-Link, and DALI

ASN Physical TX-I/O data points used Total I/O data points (TX-I/O, DALI, KNX PL-Link)
PXC3.E16A n/a 64

PXC3.E72 72 140

PXC3.E72A 72 140

PXC3.E75 200 280

PXC3.E75A 200 280

Table 129: Number of data points for PXC3

Web clients for room operation

Item Limit Description
QMX7.E38 and standard web clients 1 8 Recommended number of web clients that can simultaneously access
a PXC3.

Templates with standard background pictures 2 6 Maximum number of different templates which are using the default
background pictures.

Customized background pictures 2 1.5 MB Maximum total size of all customized background pictures (the PNG
file format is used as a reference).

Table 130: Web clients for room operation

Key:
1 Restriction: When using standard web clients (web browser on PCs, smart phones, tablets, etc.),
the screen display and operation (touch or mouse) are neither modified nor tested for the
available browsers.
2 Valid values when using 8 room applications at the boundary of maximum system limits.

21.3.11 Number of Data Points for DXR2

ASN Max. number of onboard IO- and KNX PL-Link data points Description
DXR2.x11 30 1 DI, 2 UI, 6 Triac, 2 AO

DXR2.x12P 30 1 Pressure, 1 DI, 2 UI, 6 Triac, 2 AO

DXR2.x12PX 60 1 Pressure, 1 DI, 2 UI, 6 Triac, 2 AO

DXR2.x18 60 2 DI, 4 UI, 8 Triac, 4 AO

DXR2.x09 30 1 DI, 2 UI, 3 AO, 3 Relay

348 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

ASN Max. number of onboard IO- and KNX PL-Link data points Description
DXR2.x09T 30 1 DI, 2 UI, 4 Triac, 1 AO, 1 Relay

DXR2.x10 30 1 DI, 2 UI, 4 Triac, 3 Relay

DXR2.E17C-1 30 3 DI, 2 10K input impedance, 4 UI, 4 Triac, 4 AO

DXR2.E17CX-1 60 3 DI, 2 10K input impedance, 4 UI, 4 Triac, 4 AO

Table 131: Number of data points for DXR2

Web clients for room operation

Item Limit Description
QMX7.E38 and standard web clients 1 3 Recommended number of web clients that can simultaneously access
a DXR2.

Templates with standard background pictures 2 2 Maximum number of different templates which are using the default
background pictures.

Customized background pictures 2 1.5 MB Maximum total size of all customized background pictures (the PNG
file format is used as a reference).

Table 132: Web clients for room operation

Key:
1 Restriction: When using standard web clients (web browser on PCs, smart phones, tablets, etc.),
the screen display and operation (touch or mouse) are neither modified nor tested for the
available browsers.
2 Valid values when using 8 room applications at the boundary of maximum system limits.

21.3.12 PXM20 Operator Unit

Item Limit Description
PX (no PXC3) 50 Number of PX that can be operated.
The visibility of the PX automation stations can be limited on the
BACnet network. This is only useful if the site is restricted to one
BACnet network.
For hardware series A devices (1 MB memory), the number of PX
automation stations per site should be limited to 30.

Alarm administration Only the alarms from the site where the user is logged on are
displayed (PXM20 self-registers as temporary alarm recipient for all
devices of a site).

BACnet objects in alarm per site 50* Maximum number of BACnet objects per site.
The administration of the number of BACnet objects in alarm per site
is limited. Others cannot be displayed or operated in Alarm Viewer
when there are more BACnet objects in alarm.

Alarm History 50* Maximum number of entries in the Alarm History. The oldest entries
are deleted when this limit is exceeded.

Table 133: PXM20 operator unit

349 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

21.3.13 PXM20-E Operator Unit

Item Limit Description
PX (no PXC3) [200] Number of PX that can be operated.
The visibility of the PX automation stations can be limited on the
BACnet network. This is only useful if the site is restricted to one
BACnet network.

Alarm administration Only the alarms from the site where the user is logged on are
displayed. (PXM20-E self-registers as temporary alarm recipient for all
devices of a site).

BACnet objects in alarm per site [250*] Maximum number of BACnet objects per site.
The administration of the number of BACnet objects in alarm per site
is limited. Others cannot be displayed or operated in Alarm Viewer
when there are more BACnet objects in alarm.

Alarm History [100*] Maximum number of entries in the Alarm History.

The oldest entries are deleted when this limit is exceeded.

Table 134: PXM20-E operator unit

21.3.14 PXM10 Operator Unit

Item Limit Description
PX (no PXC3) 1* Only the connected automation station / system controller can be
operated.

Alarm administration Management of the alarms of the PXC to which the PXM10 is
connected.

BACnet objects in alarm per PXC 25* Max. number of BACnet objects in alarm per PXC.
The management of the number of BACnet objects in alarm per PXC
is limited. Others cannot be displayed or operated in Alarm Viewer
when there are more BACnet objects in alarm.

Table 135: PXM10 operator unit

21.3.15 PXA40-W0 Web Controller Option Module

Impact of PX Web on PXC performance
PX Web has an impact on the reaction times of the PXC, to which the PXA40-
W1/W2 is attached. The reaction times can increase considerably for PXCs with
many:
● BACnet objects
● CFC function blocks
● Trendlog objects with large log buffers
● PBUS IO modules via PXX-PBus
Therefore, we recommend that you set up the PXA40 on a PXC with minimum load
(few BACnet objects, CFC function blocks, and Trendlog objects) or use an
additional PXC00-E.D for PX Web.

350 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

Item Limit Description

PX (no PXC3) 1* Only one PX with web controller can be operated, with attached
module PXA40-W0.

Alarm administration Alarm Viewer only handles the alarms from the local device.

SMS/Email messages 50* Maximum number of SMS/email messages that can be sent.
There is a limit to the number of messages sent by SMS/email. If
more than this number of BACnet objects are in alarm in the BACnet
internetwork, no SMS/email objects will be sent for these.

Alarm History [200*] Maximum number of entries in the Alarm History.

The oldest entries are deleted when this limit is exceeded.

Web graphic pages [100] Number of web graphics: Limited at present by the available memory
for the sum of all files of max. 7 MB.

Objects per web graphics page 60 Number of objects per web graphic.

Web clients 4 Number of simultaneously active web clients.

Table 136: PXA40-W0 web controller option module

PXA40-W0 can only be used together with PXC00/100/200-E.D (BACnet/IP).

21.3.16 PXA40-W1/W2 BACnet/IP Web Controller Option Module

Impact of PX Web on PXC performance
PX Web has an impact on the reaction times of the PXC, to which the PXA40-
W1/W2 is attached. The reaction times can increase considerably for PXCs with
many:
● BACnet objects
● CFC function blocks
● Trendlog objects with large log buffers
● PBUS IO modules via PXX-PBus
Therefore, we recommend that you set up the PXA40 on a PXC with minimum load
(few BACnet objects, CFC function blocks, and Trendlog objects) or use an
additional PXC00-E.D for PX Web.

Item Limit Description

PX (no PXC3) [20] Number of PX that one web controller can operate.

Alarm administration Management of all alarms in the BACnet internetwork (from all sites)
(PXA40-W1/W2 registers as a temporary alarm recipient with all
devices in the BACnet internetwork).
In Alarm Viewer, only the alarms from the site where the user is
logged on are displayed.
However, alarms from all sites can be forwarded via SMS and/or
email.

BACnet objects in alarm per internetwork 1,000* Maximum number of BACnet objects in the alarm per BACnet
internetwork.
Administration of the number of BACnet objects in alarm per BACnet
internetwork is limited. Others are not handled when there are more
BACnet object in alarm.

BACnet objects in alarm per site 200* Maximum number of BACnet objects per site.
The administration of the number of BACnet objects in alarm per site
is limited. Others cannot be displayed or operated in Alarm Viewer
when there are more BACnet objects in alarm.

351 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

Item Limit Description

SMS/Email messages 50* Maximum number of SMS / email messages that can be sent.
The number of messages sent via SMS/email is limited. No
SMS/emails messages are sent when there are more BACnet object
in alarm in the BACnet internetwork.

Alarm History [200*] Maximum number of entries in the Alarm History.

The oldest entries are deleted when this limit is exceeded.

Web graphic pages (VV2 only) [100] Number of web graphics: Limited at present by the available memory
for the sum of all files of max. 7 MB.

Objects per web graphics page (VV2 only) 60 Number of objects per web graphic

Web clients 4 Number of simultaneously active web clients

Table 137: PXA40-W1/W2 BACnet/IP web controller option module

PXA40-W1/W2 can only be used together with PXC00/100/200-E.D (BACnet/IP).

21.3.17 Desigo Touch and Web - PXG3.W100 Web Interface

General
Item Limit Description
Automation station (PX…) Unlimited number of PX (limited only by the BACnet object and the
number of customized views).
Adhere to the specified Desigo PX.. limits.

Configuration data size 7 MB* Limited by the available memory for all configuration data
(Configurationdata.tar).

BACnet objects, total number 2,000* Max. number of BACnet objects engineered on PXG3.W100.

Permanently displayed BACnet objects 300 Total number of permanently displayed BACnet objects which are
updated by PXG3.W100.

Customized Views 25* Max. number of customized views (memory limit of PXG3.W100).

Table 138: General

Customized views
Item Limit Description
BACnet objects 100* Max. number of BACnet objects per customized view.

Trends 10 Number of trends per customized view.

Scheduler 10 Number of schedulers per customized view.

Graphics pages 5 Number of graphics pages per customized view.

Table 139: Customized views

Graphics pages
Item Limit Description
BACnet objects 60* Max. number of BACnet objects per graphics page.

Table 140: Graphics pages

352 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

Connected web clients

Item Limit Description
Touch panel 10* Max. number of touch panels per PXG3.W100 with overview pages.

Web clients, max. system design 3* Max. number of registered users per PXG3.W100, where the limit of
permanently displayed BACnet objects of all clients may not be
exceeded at maximum system design1.

At low system design, more than 3 users can be logged in

concurrently.
Example: 1 customized view at 3 graphics pages at 10 BACnet
objects each. If 10 web clients are connected to it, the system limit
(300 permanently displayed BACnet objects) is reached.
All system limits must be adhered to simultaneously.

Table 141: Connected web clients

Key:
1 An example of a maximum system design:
- 20 customized views
- 5 graphics pages per customized view
- 20 BACnet objects per graphics page. System limit: 2000 BACnet objects total and 100 BACnet
objects per customized view.
- 3 Web clients with the above design. System limit: 300 permanently displayed BACnet objects.
- 10 trends per customized view
- 10 schedulers per customized view. System limit: The configuration data size < 7MB applies to
all of the above.

21.3.18 PXG3.L and PXG3.M BACnet Routers

Item Limit Description
BDT (Broadcast Distribution Table) [50*] Max. number of BBMDs (BACnet Broadcast Management Devices) in
a BACnet internetwork. If a BACnet router is in its own IP segment, it
must be configured as a BBMD.

FDT (Foreign Device Table) [50*] Maximum number of foreign devices which can register with the
BACnet router.
Desigo CC in a remote IP segment counts as a foreign device.

Ethernet bit rate 10/100 Mbit/s The router supports 10/100 Mbps.

353 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Devices

Item Limit Description

MS/TP telegrams [100 - 140] pkt/s The BACnet router integrates BACnet MS/TP not as a field bus in the
@115,200 bps network. The router operates transparently and routes all data traffic
[-120] pkt/s addressed to the subnet. This is why global broadcast telegrams
@76,800 bps negatively impact transmission performance of the router and end
devices.
Max. [~4,5] KB/s
Recommendation: Do not carry out time and security-critical process
controls using BACnet MS/TP.
Depends on baudrate, number of nodes and maximum number of
data frames (N max_info_frames).

BACnet/LonTalk [100 - 120] pkt/s The BACnet router integrates one (1) BACnet/LonTalk network. The
@78 KB/s router operates transparently. The same restrictions apply to global
Max. [~4,5] KB/s broadcast telegrams as for MS/TP.

BACnet/IPv4 [~2500] pkt/s The BACnet router can route between two BACnet/IP networks. The
Max. [~500] KB/s BACnet/IP networks have different UDP ports.

BACnet/IPv6 1 The BACnet router integrates one (1) BACnet/IPv6 network. The
router works transparent, but when connection ports for BACnet/IPv4
and BACnet/IPv6 are used simultaneously, make sure that no
unintentional ethernet loops are created on the IT side.

Table 142: PXG3.L and PXG3.M BACnet routers

21.3.19 SX OPC
Item Limit Description
SX OPC applications 1 SX OPC application per PC. The performance depends on the PC
hardware.

OPC server [10] Max. number; OPC data access 2.x or 3.0 specification.

BACnet objects 20,000* Maximum number of BACnet objects.

Configured alarm recipients 3*

Temporary alarm receiver 20* Minus configured alarm recipients.

Alarm-generating objects [2,000] Alarm-generating objects (of total 20,000 BACnet objects).

SX BACnet references client resources 1 [1,000]

Trendlog objects 1000 Maximum number.

Scheduler program / Scheduler objects [15] Per BACnet server.

Calendar objects [10]

Table 143: SX OPC

Key:
1 Max. number of BACnet client connections (COF or polling), that is, values read from or written to
(commanded) the own automation station or a remote automation station.
BACnet client connections are used in Input, Output, Scheduler, Trendlog and Group objects (all
NameRef_Type inputs with AddrKind = B). The configured alarm receivers of the Notification
Class objects do NOT require any BACnet client references.
The available number of BACnet client references does not address more than 50 different
remote automation stations.

21.3.20 Desigo CC
For the system configurations of the Desigo CC management platform, see Desigo
CC System Description (A6V10415500).

354 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
Devices
21

21.3.21 Desigo Insight

For the system configurations of the Desigo Insight management station V6.0 SP2,
see Desigo Building Automation System 6.0 SP, Technical Principles (CM110664 /
2016-09-20).

21.3.22 Desigo Xworks Plus (XWP)

Item Limit Description
Length of site name 9 Max. 9 characters.

Number of XWP per BACnet internetwork 10 Parallel engineering is possible under the following limitations:
(parallel engineering) Node setup: Only one XWP per LonWorks/IP segment.
Download and online operation: Only one XWP per automation
station.

Number of I/O function block instance per 200 The number of I/O function block instances are limited per plan
plan (compound). Mapping of function blocks on BACnet sets the limit. The
limit is lower for other function blocks mapped to BACnet.

Table 144: Desigo Xworks Plus (XWP)

Problems with a high When the maximum number of data points for a PXC..U is reached (350), it may no
number of data points per longer be possible to load the program into the PX automation stations due to the
automation station number of data blocks generated during compilation.
In this case, carry out the following steps on the PX automation station:
1. Reload parameters.
2. Run Reorganize in the PX Design Manager.
3. Go to Tools > Settings > Compilation download and select the Compress
check box.
4. Recompile the data.
5. Perform a full download.

Figure 239: Compress data blocks in PX

355 | 377
Siemens CM110664en_03
2017-09-18
 System Configuration
21 Applications

21.3.23 Desigo Automation Building Tool (ABT)

Item Limit Description
Function blocks [8,000] Max. number of function blocks per application function.

Table 145: Desigo Automation Building Tool (ABT)

21.4 Applications

21.4.1 Peak Demand Limiting (PDL)

Item Limit Comment
Monitored loads [28*] Max. number of monitored loads.

Tariff limits 4* Max. number of configurable tariff limits.

Cycle time [ms] 500 Minimum cycle time required to ensure the functioning of the PDL
application.
To guarantee the cycle time, use a PX modular automation station
(PXC 100/200…D, PXC12/22/36…D).
Do not use the the automation station with the PDL application to
control any other plant.
The PDL application must be confined to one automation station only.
Limit control is binary only (enabled/disabled). Step control (Stage1,
Stage2, Stage3) or modulating control (0…100%) is not possible.
Commissioning and operation are only possible with XWP.
There is no provision for backward compatibility with future PDL
applications.

Table 146: Peak Demand Limiting (PDL)

356 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Glossary
22

22 Compatibility
For information on the system compatibility of the Desigo CC management
platform, see Desigo CC System Description (A6V10415500).
For information on the system compatibility of the Desigo Insight management
station V6.0 SP2, see Desigo Building Automation System 6.0 SP, Technical
Principles (CM110664 / 2016-09-20).
For information on the compatibility of Desigo S7 with other Desigo system
components, see chapter Desigo S7 Automation Stations.

22.1 Glossary
Abbreviations
The following abbreviations are used in this document:

Abbreviation Description
ABT Automation Building Tool (XWP program component for engineering Desigo Room Automation)

AS Automation Station

BOS Branch Office Server

CC Desigo CC management platform

CAS Corporate Application Solutions (standard PX application libraries provided by HQ)

DCM Desigo Configuration Module

Desigo PX Compact and modular automation stations and system controllers (PXC…D)

DNT Discovery Network Tool

DPT Desigo Point Test Tool (for Desigo PX)

DTS Desigo Toolset

ETS Engineering Tool Software (KNX commissioning tool for RXB and KNX third-party devices)

FEP Front End Processor (the computer serving as the interface between the automation level and
Desigo CC)

FW Firmware

HQ Headquarters of Siemens Building Technologies in Zug (Switzerland)

HW Hardware

IE Internet Explorer

IIS Internet Information Services

LED LibSet Extension of Desigo (assigned LibSet numbering system displaying functional extensions
of Libsets)

LibSets Library Set. Standard application libraries. Each LibSet delivery is assigned to a Desigo system
version.

LMU (DCC) Licence Management Utility (activates and manages licences and contains the installed licences
for Desigo CC)

LMU (XWP) Library Maintenance Utility (library maintenance tool for XWP)

OS Operating System

Operator units Operator units Desigo Touch and Web (PXM40/50 with PXG3.W100), PXM20(-E), PXM10, PX
Web, and Desigo CC

RC Regional Company (Siemens regional company)

RXT LonWorks commissining tool for RXC

SD System Design (part of the Desigo tool set)

357 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Desigo Version Compatibility Definition

Abbreviation Description
SP Service Pack

SSA Service & Setup Assistant (commissioning tool for Desigo Room Automation)

SW Software

TRA Total Room Automation (from Desigo V6.0 Desigo Room Automation is also used)

V5.1 SP Service Pack version for Desigo V5.1

VVS Valid Version Set (set of released versions)

WEoF Internal Siemens PC standard (only relevant for Siemens employees)

XWP Desigo Xworks Plus

Table 147: Abbreviations

Terms
The following terms are used in this document:

Term Description
Project data Desigo engineering and project data required to create runtime systems, but that are no longer
needed for operation (offline data).

Runtime system Firmware (loaded) installed on the hardware of the customer plant or software with compiled
project data including libraries (online data).

New New Desigo customer project with no Desigo runtime system and project data.

Extension Existing plant or installation (existing Desigo runtime system with project data) that is being
expanded or extended (for example, additional buildings).

Migration Replacement of existing plant or installation (existing Desigo / Visonik / Unigyr / Integral runtime
system with project data) by new technology with a change of software and/or hardware.

Upgrade Functional improvement to existing plant or installation (existing Desigo runtime system with
project data) by deploying developments for a new Desigo system version.

Update Existing plant or installation (existing Desigo runtime system with project data) is updated within
the same version (for example, to eliminate errors with a service pack).

Project data conversion Online Desigo project data from earlier Desigo versions > V2.3x are migrated to the current
ABT/XWP V6.1 version when opened in ABT/XWP V6.1.
During conversion, the existing database structure and/or associated tool landscape is migrated to
the latest version. A conversion always impacts all project data of a tool project.
The project data and libraries remain unchanged. The runtime system (online project data) does
not change, that is, the original version status remains as is.

Table 148: Terms

22.2 Desigo Version Compatibility Definition

General definition
The Desigo V6.1 version compatibility describes the compatibility of Desigo
products:
● Within a Desigo Xworks Plus (XWP) project (incl. ABT/SSA)
● With the same tool project data
● On a Desigo V6.1 runtime system
The compatibility also comprises Desigo project data at both the management level
and room automation linked to the same Desigo Xworks Plus (XWP) project.

358 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Desigo V6.1 System Compatibility Basics
22

Desigo system versions

The term refers to the various development phases of the Desigo building
automation and control system. The currently supported versions are:
● Desigo V2.2
● Desigo V2.3
● Desigo V2.35
● Desigo V2.36
● Desigo V2.37
● Desigo V4.0
● Desigo V4.1
● Desigo V5.0
● Desigo V5.1
● Desigo V6.0
● Desigo V6.1

22.3 Desigo V6.1 System Compatibility Basics

22.3.1 Compatibility with BACnet Standard

Desigo V6.1 supports the following BACnet protocol revisions:
● Desigo CC: 1.13
● Desigo Room Automation devices: 1.13
● Desigo PX, PXM20: 1.12
● Desigo Touch and Web PXG3.W100: 1.10
● PXG3 router: 1.13
There are third-party BACnet devices on the market that support higher BACnet
protocol revisions.
Desigo CC Properties from earlier BACnet
BACnet 1.13 protocol revisions can continue to be
read from a BACnet device, even if
the device supports BACnet protocol
revision > 1.13.

New properties from a BACnet

protocol revision > 1.13 would not be
readable/changeable, as the new
properties would not be known to
Desigo management station.
10664Z41en

Third-party BACnet devices

Desigo devices BACnet protocol revision > 1.13
BACnet protocol revision <= 1.12
Figure 240: BACnet protocol revision

359 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Desigo V6.1 System Compatibility Basics

Desigo V6.1 does not support BACnet protocol revision functions higher than
V1.13. Usually, BACnet devices of a specific BACnet protocol revision fully support
earlier revision functions (downward compatibility). However, since this is not true
in all cases, we recommend that you verify the compatibility in each case.
For an overview of the BACnet functions supported in Desigo, see BACnet
Protocol Implementation Conformance Statement (PICS) (CM110665).
UTF-8 and ANSI 3.4 BACnet protocol revision 1.10 introduced UTF-8 instead of ANSI 3.4.
If ANSI 3.4 / UTF-8 is used for BACnet communications, and if devices featuring
BACnet protocol revision < 1.10 (prior to Desigo V5.0) communicate with devices
of BACnet protocol revision ≥ 1.10 (from Desigo V5.0):
● Received BACnet character strings of type ANSI 3.4 are handled properly, as
only ANSI X3.4 code points (0..127) are sent that have coding identical to UTF-
8.
● Sent BACnet character strings of type UTF-8 are added properly to data
storage by Desigo devices < V5.0, provided the code points are in the range
0..127.
● If the code points are in range 128..255, UTF-8 coding (multibyte) is interpreted
as ISO-Latin-1 (1 byte) and taken over into data storage. As a result, the data
storage does not match the received string ("René" becomes "René").
To read back this type of string, Desigo devices < V5.0 use ANSI conversion
and only code points in the range 0..127 are sent ("René" becomes "RenA.").
● If the code points are in the range 128..255, UTF-8 coding (multibyte) is
rejected either by third-party devices with BACnet protocol revision < 1.10 (not
ANSI X3.4), or not interpreted along a defined rule.
● Desigo V5.0 supports UTF-8 coding for code points in the range 0..255.
● The following applies from Desigo V5.1:
– Desigo PX / Desigo Room Automation fully supports UTF-8 coding.
Create and delete BACnet As of Desigo V5.1 a function is available for PXC automation stations to create and
objects delete dynamic BACnet objects. If you use this function with an older version, an
error message will appear.
The function can be used on Desigo PXC automation stations. Desigo Room
Automation room automation stations PXC3 are not supported.
Third-party devices can be processed using the same functionality as long as they
support creating and deleting BACnet objects. PXM20 operating units do not
display dynamic objects.
Backup and restore With the BACnet backup and restore function you can upload saved program data
BACnet devices (application program) from a BACnet device to Desigo CC and restore it to the
same or a new BACnet device.
The backup and restore function can only be run if the third-party BACnet devices
support it.

Compatibility Desigo For information on the system compatibility of the Desigo Insight management
Insight station V6.0 SP2, see Desigo Building Automation System 6.0 SP, Technical
Principles (CM110664 / 2016-09-20).
Compatibility Desigo CC For information on the system compatibility of the Desigo CC management
platform, see Desigo CC System Description (A6V10415500).

22.3.2 Compatibility with Operating Systems

Microsoft client operating systems
The following table shows which Microsoft client operating systems are compatible
with Desigo V6.1.

360 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Desigo V6.1 System Compatibility Basics
22

Desigo version Compatibility with Microsoft client operating systems

V6.1 Windows 7 Professional / Ultimate / Windows 8.1 Windows 10
Enterprise Professional / Professional /
Enterprise2 Enterprise
Tools 32-Bit 64-bit 64-bit2 64-bit
XWP Yes Yes No Yes
ABT Site/Pro No Yes Yes2 Yes
RXT10.3 Yes Yes No No
RXT10.51 Yes Yes Yes2 Yes
Desigo Configuration Module (DCM) Yes Yes Yes2 Yes

Table 149: Compatibility with Microsoft client operating systems

Key:
1 From Desigo V5.1 SP
2 Only basic tests (engineering, commissioning, reporting, driver compatibility)

Unlisted Microsoft client operating systems/editions (especially Home Premium or

32-bit versions) are not supported.
BOS only supports server operating systems.
LMS/LMU supports several Microsoft client operating systems. For details on
requirements and limitations, see License Management Utility (A6V10455206).

Microsoft server operating systems

The following table below shows which Microsoft server operating systems are
compatible with Desigo V6.1 (the compatibility applies only to the Desigo V6.1
products listed below).
The end user is responsible for the correct licensing of any third-party licenses.

Desigo version Compatibility with Microsoft server operating systems

V6.1 Windows Server 2008 R2 Windows Server 2012 R2 Windows Server 2016
(with SP1) Standard / Standard Standard
Enterprise
64-bit 64-bit 64-bit
Branch Office Server (BOS) Yes Yes Yes

Table 150: Compatibility with Microsoft server operating systems

Unlisted Microsoft server operating systems/editions are not supported. They can,
however, be used for stand-alone SQL servers and file hosts.

22.3.3 Compatibility with SQL Servers

The following table shows which Microsoft SQL server versions are compatible with
Desigo V6.1.

Desigo version Compatibility with Microsoft SQL servers

V6.1 SQL server 2008 R2 SQL server 2012 SQL server 2014 SQL server 2016
Standard Standard Standard Standard
64-bit 64-bit 64-bit 64-bit
Branch Office Server (BOS) Yes Yes Yes Yes

Table 151: Compatibility with Microsoft SQL servers

Unlisted SQL server versions/editions are not supported.

The Branch Office Server (BOS) is compatible with the following operating systems:

361 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Desigo V6.1 System Compatibility Basics

● SQL Server 2008 R2 Standard on Windows Server 2008 R2

Standard/Enterprise editions
● SQL Server 2012/2014 Standard on Windows Server 2012 R2 Standard edition
● SQL Server 2016 Standard on Windows Server 2016 Standard edition

22.3.4 Compatibility with Microsoft Office

The following table shows which Microsoft Office versions are compatible with
Desigo V6.1.

Product Version Microsoft Office Versions

Desigo Xworks Plus (XWP) (including ABT/SSA V6.1 MS Office 2007 (32-bit edition)
and other additional tools) MS Office 2010 (32-bit edition)

Desigo Configuration Module (DCM) V6.1 MS Office 2007 (32-bit edition)

MS Office 2010 (32-bit edition)

Table 152: Compatibility with Microsoft Office

22.3.5 Compatibility with Web Browsers

The following table shows which web browsers are compatible with Desigo V6.1
(compatiblity only applies to the listed Desigo V6.1 products).

Product Tested compatibility with web browsers

Microsoft Edge Microsoft Internet Google Chrome Firefox (also Safari 10
V38 Explorer V11 (also mobile) V51 mobile) V53
Desigo Touch and Web1, 3 Yes6 Yes6 Yes7 Yes Yes7
ABT/SSA4 Yes Yes Yes Yes Yes

Table 153: Compatibility with web browsers

Key:
1 These web browsers are supported in addition to the PXM touchpanels.
3 Lighting an blinds functions are not supported together with PXC3 room automation stations.
4 Support of of HTML5-capable browsers with native SVG format.
6 Tested and released browsers. Differences in display and operation compared to the
recommended browser (Firefox) are possible.
7 Minimallly tested browsers. No support from Siemens BT.

Desigo CC For notes on Desigo CC web client running in a browser shell, see Desigo CC
System Description (A6V10415500).

22.3.6 Compatibility with VMware (Virtual Infrastructure)

The following table shows which VMware versions are compatible with Desigo
V6.1.

Product Version VMware version

Desigo Xworks Plus (XWP) (including ABT/SSA and other V6.1 VMware Workstation 12
additional tools)

Table 154: Compatibility with VMware

362 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Desigo V6.1 System Compatibility Basics
22

22.3.7 Compatibility of Software/Libraries on the Same PC

The installed Desigo software and LibSets (standard application libraries) on the
same PC must have the same version.
You can install Desigo CC, RXT10.3/RXT10.5 (if required) and Desigo Xworks Plus
(XWP) V6.1 on one PC in any order. But you must install the libraries at the end.
Restrictions RXT10.5 is only supported as of Desigo V5.1 Service Pack.
RXT10.3 and RXT10.5 do not operate if installed in the same Windows
environment. The corresponding LNS server versions are not compatible. Solution:
Install one of the two components in a VMware.
Installing Desigo software from different systems versions on the same PC is not
supported. Check operating system compatibility prior to installing.

22.3.8 Hardware and Firmware Compatibility

Desigo V6.1 hardware and firmware is only partially compatible to products from
earlier versions in the same Desigo project runtime system.
BACnet peer-to-peer communication between Desigo PX devices from Desigo
V2.2 to Desigo V6.1 is guaranteed (see chapter Automation Level Desigo PX /
Room Automation).
Restrictions As soon as an automation station or a system controller with Desigo V6.1 firmware
is used in a runtime system, all operating clients, such as PXM20, PXM20-E, PX-
Web, and Desigo Insight must be upgraded to Desigo V6.1. Otherwise, only limited
operation is available.

22.3.9 Backward Compatibility

Desigo V6.1 software and libraries are downwards compatible. Desigo V6.1
products can process data compiled with earlier versions.
Restrictions After upgrading Desigo project data for a Desigo software product to V6.1, the data
can only be accessed or processed with the appropriate software/LibSets for
Desigo V6.1.

22.3.10 Engineering Compatibility

All project data on all system levels (automation level with room automation and
management level) must have the same LibSet with the same LibSet version
number (for example, V6.xxxx-xx) for unlimited engineering of tested Desigo
solutions (libraries).
Restrictions Library extensions for V6.1 cannot be used during engineering if the upgrade of a
Desigo runtime system > V2.3x occurs on only a portion of the project data to V6.1,
for example, only Desigo Xworks Plus (XWP).

22.3.11 Compatibility with Desigo Configuration Module (DCM)

The Desigo Configuration Module (DCM) version supplied with the relevant Desigo
system covers the available Desigo product scope.
When importing DCM projects from earlier DCM versions, the project is converted
to the status and options of the current DCM version. After conversion, the project
data can only be revised in the current DCM version.
DCM projects from DCM version 5.0 support import.
DCM requires Microsoft Office.

363 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 When to Upgrade to Desigo V6.1

22.4 When to Upgrade to Desigo V6.1

Desigo PX automation station
PX and PXC FW V6.1 is compatible with V6.0 programs. Upgrading makes sense when the new
functionality in V6.1, such as scheduler or a new user interface is supposed to be
employed for ABT SSA.
In addition, V6.1 is a bug fix version to V6.0.
If you want to deploy a Desigo PX automation station or system controller (PXC…)
with Desigo V6.1 firmware in a project, all operator clients must be upgraded to
Desigo V6.0, if you want to use the new functionality.
If a PXC3 already contains Desigo V6.0 firmware, newer firmware versions for V6.x
must be loaded together with ABT Startup.
PXC3x from Desigo V5.x The following requirements must be met to upgrade firmware on PXC3 room
to V6.0 automation stations (Desigo Room Automation) from Desigo V5.x to Desigo V6.0:
● ABT Pro project data is available.
● ABT project is converted to V6.0.
● Room automation station in ABT still has version V5.x.
● DNT is installed.
● V6.0 firmware is available.
● The administrator password V5.x for the room automation station is known (it is
visible in ABT Pro under project settings).
Do the following to upgrade firmware on a PXC3x room automation station from
Desigo V5.x to V6.0:
1. Room automation station: Restore Desigo V5.x parameters with ABT Pro.
2. Management station: Save trend data (if available).
3. ABT Pro: Delete (clear) room automation station application (but not the entire
device).
4. DNT: Load firmware.
5. ABT Pro: Upgrade room automation station to Desigo V6.0. Requirement: ABT
Pro Library V6.0 is installed.
6. Room automation station: Run a full compile.
7. Room automation station: Load program.
8. ABT-SSA: Check if the room automation station changes to operational after
loading.
9. ABT-SSA: Check if the TX, KNX PL-Link and DALI (if available) buses are
operational.
If the load of a PXC3 in V5.x approaches the upper load limit, the program may not
be able to be loaded after a firmware upgrade. In this case, the PXC3 must be
replaced by a PXC3x-100 of the new series.
Stricter guidelines for passwords apply after a firmware upgrade to V6.0. The user
profile is loaded by ABT Site after the program is loaded by ABT Pro. The V5.x
password is no longer valid at this point.
PXC3x from Desigo V6.0x For a firmware upgrade of the room automation stations PXC3 (Desigo TRA) from
to V6.1 Desigo V6.0 to Desigo V6.1, the following prerequisites must be met:
● PXC3x-100 belongs to the new series with extension -100 (e.g. PXC3.E72A-
● 100A). Upgrading older version from V6.0 to V6.1 is not possible.
● ABT Pro project data are available.
● The ABT project is converted to V6.1.
● The room automation station has version V6.0 in ABT.
● V6.1 firmware is available.
● The administrator password V6.0 of the room automation station is known.

364 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
When to Upgrade to Desigo V6.1
22

Proceed as follows in the event of a firmware upgrade of the PXC3 room

automation station from Desigo V6.0 to V6.1:
1. Room automation station: Read back Desigo V6.0 parameters with ABT Pro
(optional step).
2. ABT Startup: Load firmware V6.1.
3. ABT Pro V6.1: The room automation station remains at Desigo V6.0 (there is
no Desigo V6.1 version, as it is fully compatible with V6.1).

22.4.1 Automation Level Desigo PX / Desigo Room Automation

Desigo Xworks Plus (XWP) and Automation Building Tool (ABT)
Upgrading projects (while simultaneously converting and upgrading the project
data of a tool project as well as the libraries used) to XWP/ABT V6.1 may be
required under the following circumstances:
● When at least one automation station or system controller is used with Desigo
V6.1 firmware in the runtime system to allow the use of an additional
application scope for Desigo V6.1.
● When automation stations are used in the runtime system as per AMEV
profiles AS-A or AS-B are required (as of Desigo V5.1 firmware on the
automation stations).
● To be able to use the Desigo V6.1 tool environment.
The existing engineering and commissioning tool ABT V6.1 for Desigo Room
Automation supports all existing runtime systems from Desigo V5.0. It contains all
required firmware versions and application libraries from V5.0.
For Desigo Room Automation the firmware of the PXC3 room automation stations
can be upgraded from Desigo V5.0 to V5.1, without updating the rest of the runtime
system.
For details, see chapter Upgrade PX / Desigo Room Automation automation level .
What does conversion and upgrade mean?
Conversion means to upgrade the saved project data from the current XWP tool
version to a higher tool version (for example, from XWP V4.x, or XWP/ABT V5.0 to
XWP/ABT V5.1).
This conversion does not change the automation level system version of the
project (that is, an automation station with system version V4 remains as is in the
project).
A conversion of the XWP/ABT data structure always impacts all project data of a
tool project.
Upgrade means to upgrade the automation level system version to a higher
version (for example, system version V5.0 to automation station system version
V5.1).
With XWP V6.1 after upgrading, first check the CFC log file (CFC > Options > Log
file) for connection losses between the function objects in the CFC caused by
different pin assignments and designations in Desigo V5.1. Upgrade errors must
be corrected manually in the CFC.
Conversion and/or upgrade of the former Desigo LibSet V5.1 to Desigo LibSet
V6.1 has been carried out already and is provided on the Desigo LibSet installation
CD. Conversion and/or upgrade is necessary for RC and local libraries. To do this,
use the Library Maintenance Utility (LMU).
For details, see chapter Upgrade PX (CAS) Libraries.
Room automation stations or automation stations and system controllers with
firmware V2.x - V5.1 and V6.1 may be operated in the same runtime system.
An upgrade to firmware V6.1 of existing PXC3 room automation stations or PXC
automation stations and system controllers (V2.2 – V5.1) is only required when one
of the conditions mentioned above must be met.

365 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 When to Upgrade to Desigo V6.1

Restrictions When engineering a tool project, all tool installations must have the same version
as the project.

Branch Office Server (BOS)

XWP/ABT V6.1 can be used only in Branch Office Server (BOS) version V6.1
(BOS versions < V6.1 are not compatible).

Desigo PX / Desigo Room Automation

An upgrade of previously programmed and commissioned Desigo Room
Automation room automation stations or PXC automation stations / system
controllers (PXC...) <= V6.1 to Desigo V6.1 SP firmware is required:
● Generally:
– To permit the use of additional Desigo V6.1 products and application scope
on the Desigo Room Automation / PX device in question.
● For V6.1:
– T permit the use of additional Desigo V6.1 products and application scope
on the Desigo Room Automation device in question.
● For V5.0 - V5.1:
– To use additional V5.1 product and application scope and for Desigo V5.1
on the PXC3/PXC in question.
– When the use of certified devices as per AMEV AS-A or AS-B is demanded
by the runtime system.
– To integrate BACnet/IPv6 devices into the Desigo system (a router
PXG3.M/.L with V5.1 firmware is required).
● For V2.2-V4.1:
– If the automation station / system controllers are to be used as Desigo
Room Automation system function controllers for the PXC3 room
automation stations (Desigo Room Automation) for alarm and schedule
system functions.
– When the runtime system requires the use of certified devices with BACnet
revision 1.10.
● For V2.2 to V2.37:
– To allow storage of project data (engineering data storage on the plant) to
all automation stations / system controllers PXC…D, and PXC52 (from
Index D), and PXC-NRUF.
For Desigo Room Automation the firmware of the PXC3 room automation stations
can be upgraded from Desigo V5.0 to V5.1 / V5.1 SP, without updating the rest of
the runtime system.
For details, see chapter Upgrade PX / Desigo Room Automation Automation Level .
When converting and upgrading a plant <= Desigo Room Automation V5.1 to
Desigo Room Automation V6.1, the individual address (IA) on the KNX PL-Link
subsystem must be set as per the number of data points on KNX PL-Link
subsystem specifications. Failure to comply with the specifications can result in a
fault on the plant.
Restrictions Desigo Touch and Web (for PXM Touch Panel) is used exclusively with PXC
automation stations and system controllers from firmware V4.0 (BACnet Rev. 1.5).
The modular Desigo PX automation stations / system controllers
PXC00/50/100/200-E.D from firmware version V5.0 are supported as Desigo Room
Automation system function controllers for the PXC3 room automation stations. For
performance reasons, use PXC00-E.D where possible.
The local operator unit PXM10 cannot be used together with the following devices:
● PXC3 room automation stations (Desigo Room Automation)
● PX KNX (PXC001.D/PXC001-E.D)

366 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
When to Upgrade to Desigo V6.1
22

● PXG3.L/PXG3.M (BACnet router)

● PXG3.W100 (web interface BACnet/IP of Desigo Touch and Web)
No I/O modules may be connected to the system controller LonWorks PXC00(-
E).D.
Automation stations PXC50/100/200.D for BACnet/LonTalk communications
cannot be equipped with option module PXA40-W… (no PX Web possible).
The modular series PXC…D (Desigo PX) and the PXC3 room automation stations
(Desigo Room Automation) do not have a PPS2 connection.
Upgrading a BACnet primary server of a PX site to increase the system limits (for
example, up to 100 PXC..D per PX site):
● Increasing the system limits by upgrading a primary server is recommended
only for existing sites featuring primary servers and firmware version V4 or
higher. And, only if no changes to the site’s functional scope and system limits
are made.
● Upgrading V2.x primary servers only to extend the system limits is not
supported.
● Version-related limits continue to apply to each device of the site (for example,
no limit extensions with BACnet/LonTalk, but only for BACnet/IP
communication).
When replacing the primary server, the same firmware version must be used that is
available in the device to be replaced (for example, replacement FW V4.x by FW
V4.x, FW V5.x by FW V5.x). Within the same site, a firmware upgrade of the
primary server at the same time also means changes to the communication with
other PXC automation stations. This is true in particular for the replication of global
objects in a PX site (for example, calendar, notification class, user profile).
The compact automation station PXC-NRUF only runs from Desigo V2.37 firmware.
Upgrading PXC-NRUF firmware to Desigo ≥ V6.1 is required if BACnet Rev. 1.12
is needed.
The Desigo V6.1 firmware exclusively runs on the following devices:

ASN Product range

DXR2 Desigo Room Automation (from V6)

PXC00(-E).D Desigo PX

PXC001(-E).D Desigo PX

PXC50(-E).D Desigo PX (from V5)

PXC100(-E).D Desigo PX

PXC200(-E). D Desigo PX

PXC3.7..(A) Desigo Room Automation (from V5)

PXC3.E16A Desigo Room Automation (from V6)

TXI1.OPEN Desigo PX

TXI2.OPEN Desigo PX

TXI2-S.OPEN Desigo PX

PXC12(-E).D Desigo PX

PXC22(-E).D Desigo PX

PXC36(-E).D Desigo PX

PXC22/36-1 Desigo PX

PXG3.L/ PXG3.M Desigo PX

PXG3. W100 (web interface for PXM touch panel) Desigo PX

PXC-NRUF Desigo PX

367 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 When to Upgrade to Desigo V6.1

ASN Product range

QMX7.E38 Desigo Room Automation (from V5.1 SP)

PXM20(-E) Desigo PX

TXB1.P-BUS Desigo PX

PXX-L11/12 Desigo PX

PXX-PBUS Desigo PX

Table 155: Devices on which Desigo V6.1 firmware can run

Desigo PXR / LonWorks system controller

Migration of previously programmed and operational V2.2 - V2.37 system
controllers PXR11/12 to Desigo V6.1 using PXC00(-E).D+PXX-L11/12 is required:
● To use LNS based LonWorks standard tools NL220 (Newron System) or
LonMaker (Echelon) as an alternative to RXT10.3/RXT10.5 together with the
RXC Link plug-in. This applies to projects based on LNS TE and OpenLNS.
● When the runtime system (project) requires the use of certified devices with
BACnet rev. 1.12.
There is no need to exchange existing PXR11/12 devices. Migration to PXC00(-
E).D with a PXX-L…is only required if the aforementioned conditions are required.

22.4.2 Desigo TX-I/O

TX-I/O modules
Product range TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1. TXM1.
8D 16D 8U 8U-ML 8X 8X-ML 6R 6R-M 8P 6RL 8RB 8T
Desigo Room Automation • • • - - - • - - • • •
modular room automation
stations PXC3 (from index D)

Desigo PX modular room • • • • • • • • • •1 - •

automation stations PXC..D

Table 156: Compatibility of TX-I/O modules with PXC..D and PXC3 automation stations

Key:
1 Directly switched lighting applications (by the user) are not supported by the PXC..D automation
stations. For this reason, the configured button function of the digital input modules is not
available together with the PXC…D automation stations.

Restrictions A firmware update or upgrade from TX-I/O modules is not possible (except for
TXI1.OPEN, TXI2.OPEN, and TXI2-S.OPEN).

22.4.3 TX Open
Restrictions The TXI1.OPEN, TXI2.OPEN, and TXI2-S.OPEN TX Open modules can only be
used together with the PXC50/100/200(-E).D and PXC22.1/PXC36.1(-E).D
automation stations.

368 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Upgrade to Desigo V6.1
22

22.4.4 Desigo RX
Nides.RX PXR-xx PXX-Lxx
Description Phased out Q1/2010 Phased out Q4/2011 Released with Desigo V4

Desigo version < V4 ≤ V5 ≥ V4

Supports RXCxx.1 devices • • •

Supports RXCxx.1 devices - • •

Table 157: Desigo RX

RXT10.3 (RXC project RXT10.3 supports:

data) ● Desigo V2.x projects with PXR and NIDES integration
● The new LNS database version 3.2x
RXT10.5 (RXC project RXT10.5 was introduced as part of Desigo V5.1 SP and is not backwards
data) compatible to RXT10.3. The project data can, however, be taken over after an
export from RXT10.3 to RXT10.5.
RXT10.5 supports only system integration via the PXX L11/L12 Controller.
NIDES and PXR are not supported and the corresponding projects must be
maintained using RXT10.3.
You can only use LON standard tools NL220 (Newron System) or LonMaker
(Echelon) with project data from LonWorks PXC00(-E).D or PXC50/100/200 (-E).D
system controllers (from V5.0).

22.4.5 Libraries
Converting or upgrading existing Desigo V2.x/V5.0 V4.x libraries is required:
● To be able to use XWP/ABT V5.1.
● To allow the use of an additional application scope for Desigo V5.1.
● When an automation station, a system controller or room automation station is
used with Desigo V5.1 firmware in the runtime system.
● To make changes to old PX programs engineered with libraries V4.1 (or earlier)
with Desigo Xworks Plus (XWP).
LibSet Desigo LibSets have been converted and/or upgraded to Desigo LibSet V6.1 and
have been provided on the Desigo LibSet installation CD.
Restrictions All Desigo software and LibSets must be on the same PC and have the same
system version.
RC and local libraries Converting and/or upgrading is necessary for RC and local libraries at the
automation level. To do this, use the Library Maintenance Utility (LMU).
For details, see chapter Upgrade PX (CAS) Libraries.
Restrictions Mixing different versions of PX libraries on devices (PX...) is not allowed within the
same application. This applies to CAS libraries, RC libraries, and local libraries.

22.5 Upgrade to Desigo V6.1

Restriction Unless otherwise described, the upgrade to Desigo V6.1 must occur in stages as
per the system versions.

369 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Upgrade to Desigo V6.1

22.5.1 Upgrade PX / Desigo Room Automation Automation Level

Desigo Xworks Plus The Desigo Xworks Plus (XWP) V6.1 engineering and commissioning tool supports
all existing runtime systems, beginning from Desigo V2.2 to V5.x, which were
created in the Desigo Toolset (DTS) or Desigo Xworks ≤ V5.1.
Desigo PX All required firmware versions and application libraries are included. Converting
and/or upgrading with the Library Maintenance Utility (LMU) is necessary for RC
and local libraries at the automation level.
When you decide to use XWP V6.1 proceed as follows:
Case 1 Extend an existing Desigo project < V5.1. The existing runtime system will not be
upgraded to firmware Desigo V6.1.
1. Open the existing project in Desigo XWP V6.1. XWP data storage is converted
automatically to XWP V6.1.
2. Read back the parameters.
3. Edit your project as needed.
4. The firmware on the automation station or system controller does not need to
be changed.
Result:
The Desigo PX project data was not upgraded (conversion only) to Desigo V6.1.
The entire project can only be processed with XWP V6.1.
Case 2 Extend an existing Desigo project ≤ V5.1. The firmware Desigo V6.1 is to be used
in the existing runtime system to be able to use the new V6.1 features.
1. Open the existing project in Desigo XWP V6.1. XWP data storage is converted
automatically to XWP V6.1.
2. Read back the parameters.
3. Upgrade the project data from PX automation stations or system controllers to
Desigo V6.1 where the firmware needs to be upgraded to Desigo V6.1.
4. Edit your project as needed.
5. The firmware V6.1 must be loaded on the impacted automation stations/system
controllers.
Result:
The Desigo PX devices were upgraded to Desigo system version V6.1.
The entire project can only be processed with XWP V6.1.
Restrictions Not all Desigo PX devices in the field can be upgraded to firmware Desigo V6.1.
Automation Building Tool The engineering and commissioning tool ABT V6.1 for Desigo Room Automation
(ABT) supports all existing runtime systems starting from Desigo V5.0. It contains all
required firmware versions and application libraries from V5.0.
Desigo Room Automation For existing Desigo Room Automation ≤ V6.0 projects the following steps are
recommended for the change to Desigo Room Automation V6.1:
1. Upgrade all XWP/ABT ≤ V6.0 PC installations to XWP/ABT V6.1.
2. Convert all Desigo Room Automation ≤ V6.0 projects to Desigo Room
Automation V6.1 projects with XWP/ABT V6.1 (Offline).
3. Work with XWP/ABT V6.1 taking into account the Desigo Room Automation
system compatibility with:
– Existing PXC3 V5.x room automation stations where the Desigo Room
Automation V5.x functionality in existing or additional rooms still meets the
requirements.
– Existing PXC3 V5.x room automation stations where on demand the new
V5.1 / V5.1 SP functionality (QMX3 room operator units for wall mounting
or QMX7) is needed in existing or additional rooms.

370 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Upgrade to Desigo V6.1
22

– Existing or new PXC3 where the complete V6.1 functionality is needed in

additional or new rooms.

Library name Description

TRA04_V5.1SP_HQ_ABT1.2 For converted V5.1SP projects only.

TRA04_V5.1SP_V6.0_HQ_ABT1.2 Used to replace hardware on a converted V5.1SP project or generally, if the

automation station or system controller was migrated to V6.0.

TRA_01_V6.0_HQ_ABT1.2 Used in projects with Desigo V6.0 library solutions.

TRA_01_V6.0SP_HQ_ABT1.2 Desigo TRA library. Compatible with the Desigo V6.0 library.

TRA_CET_01_V6.1_HQ_ABT2.1 Desigo V6.1 library.

Table 158: Desigo Room Automation system compatibility

Restrictions Restricted readback of minor Command and Device objects properties which were
changed in the runtime system after the last read back with ABT V5.1 or ABT V6.1.
Affects upgrades of PXC3 room automation stations from Desigo 5.1 to V6.1 with
XWP/ABT V6.1 without readback done previously.

Affected BA Object Properties Description

ActnTbl Action table

ActnTxt Action text

EnMem Enable memorize

Des Description

ObjNam Object name

Table 159: Command object

Affected BA Object Properties Description

Locat Location

RstNfRcp Restart notific. recipients

TioBck Timeout for backup

Des Description

Table 160: Device object

QMX7 QMX7 is provided from Desigo V5.1 SP. This requires the following versions:
● ABT V5.1 SP
● Application library V5.1 SP
● PXC3 FW V5.1 SP
Restrictions Projects under older versions, such as V5.0, must be upgraded to ≥V5.1 SP
(System Version Set).
Branch Office Server Procedure for upgrading XWP and BOS from the previous version to the latest
(BOS) version:
1. Check in previous version of XWP using the presious version of BOS.
2. Install new BOS version.
3. Continue with new XWP version only.
You do not need to upgrade all tool project data of all automation stations, system
controllers or room automation stations to V6.1.
In a Desigo runtime system, existing PX automation stations, system controllers or
room automation stations may remain unchanged on Desigo ≤ V5.x even after a
conversion to the V6.1 tool environment.

371 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Upgrade to Desigo V6.1

Restrictions When engineering a tool project, all tool installations must have the same version
as the project.
All Desigo software and LibSets must be on the same PC and have the same
version.

22.5.2 Upgrade RX Room Automation

RXT10.x project data All Desigo software and LibSets must be on the same PC and have the same
system version.
RXC HW and applications Existing RXC (to V4.1) and RXC V5.x devices can be commissioned with
V2 to V4.1 to V5.x RXT10.3/RXT10.5. A tool workflow supports exchanging RXC (to V4.1) for RXC
V5.x devices.

22.5.3 Upgrade PX (CAS) Libraries

Libraries at the automation level must be converted and upgraded.
LibSet Former Desigo LibSets have been converted and/or upgraded to Desigo LibSet
V6.x and provided on the Desigo LibSet installation CD.
RC and local libraries Use the Library Maintenance Utility (LMU) to upgrade existing Desigo
V2.x/V4.x/V5.x RC or local libraries to Desigo V6.x. If the LMU is not available,
contact your local RC representative for upgrading.
First back up the library folder …\All Users\Application
data\Siemens\Desigo\Toolset\XwpData so that you do not lose existing RC or local
PX libraries.
Conversion or upgrading always applies to the entire library for RC or local libraries.
Restrictions Do not mix different versions of PX libraries (CAS libraries, local libraries and RC
libraries) on one Desigo PX.
All Desigo software and LibSets must be on the same PC and have the same
system version.
In a Desigo V2.x/V4.x/V5.x runtime system, existing PX automation stations or
system controllers may remain on Desigo V2.x/V4.x/V5.x, even after data
conversion to V6.x.
This means:
● The automation station or system controller remains on V2.x. The data was not
upgraded.
● You must use Xworks Plus (XWP) from V4.0 forward.
● The automation station or system controller are no longer compatible with DTS
or Xworks Plus (XWP) V2.x.

22.5.4 Upgrade Desigo Room Automation Libraries

The Automation Building Tool (ABT) scope of delivery contains libraries with
conversion and/or upgrades.
The ABT V6.1 engineering and commissioning tool for Desigo Room Automation
supports all existing runtime systems from Desigo V5.0. It contains all required
firmware versions and application libraries from V5.0.
If only QMX3 room operator units for wall mounting are used, you can upgrade the
firmware of the PXC3 room automation stations (Desigo Room Automation) from
Desigo V5.x to V6.1 without upgrading the entire runtime system. Use the special
Desigo Room Automation library.

372 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
Siemens WEoF Clients
22

22.6 Siemens WEoF Clients

This information is only for Siemens employees who use a WEoF client PC.

22.6.1 Desigo Software

All Desigo V6.1 software programs and LibSets (LED) operate on the Siemens
WEoF client.

Minimum user level required Version Desigo product compatibility

Standard User V6.1 Desigo Configuration Module (DCM)

Permanent Open User V6.1 Desigo Xworks Plus (XWP) including PX firmware library
(FW), Automation Building Tool (ABT) and additional tools

Permanent Open User V6.1 Branch Office Server (BOS)

Permanent Open User V6.1 RXT10 (including RX library)

Permanent Open User V6.1 HQ and RC libraries

Table 161: Desigo Software with WEoF

22.6.2 Third-Party Engineering Software

The ETS standard tool from the Konnex Association (www.konnex.org) is used to
engineer and commission KNX S-Mode / EIB segments (for RXB and KNX/EIB
third-party devices) at the field level.
The following standard Lon tools can be used from Desigo V4 instead of
RXT10.3/RXT10.5:
● NL220 (Newron System) www.newron-system.com
● LonMaker (Echelon) www.echelon.com

NL220 LonMaker ETS 3.0 Professional

Operating System Windows XP Professional Windows XP Professional Windows XP Professional

WEoF client WEoF WEoF WEoF

Minimum user level required Standard User Standard User Standard User

Table 162: Third-party software with CAT2

22.7 Migration Compatibility

Migration of Xworks Plus (XWP):

Described in Requirements
CM110776 Automation Level Engineering Manual

CM110563 Replacement of legacy I/O modules by TX-I/O modules or workarounds

Table 163: Migration of Xworks Plus (XWP) for all subsystems

Migration of Unigyr:

Described in Requirements
CM110496 Unigyr tools V7.61 with Unigyr automation level V7.64

Table 164: Migration of Unigyr

Migration of Integral:

373 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 Hardware Requirements of Desigo Software Products

Described in Requirements
CM110499 NCRS from V3.1 (only automation level)

CM110498 NITEL from V1.31 (only automation level)

Table 165: Migration of Integral

For replacing Integral RS modules (NRUA, NRUB, NRUC, and NRUD) with PXC
AS and PXC-NRUD modules, Desigo supports the use of PXC-NRUD modules
with PXC100/200(-E).D (from Desigo ≥ V4.1) and PXC50(-E).D (from V5.0).
Migration of Visonik:

Described in Requirements
CM110497 DCS from V22.16 Patch 195 or V24.16 Patch 195 (server with automation level)

Table 166: Migration of Visonik

22.8 Hardware Requirements of Desigo Software

Products
The following table shows the minimum hardware and software requirements of
Desigo software products.

Product Version CPU Frequency Storage Hard disk Other

Desigo Configuration V6.1 Compatible with 1.6 GHz 1 GB RAM 40 GB HD
Module (DCM) Intel and AMD
technology

Desigo Xworks Plus V6.1 Compatible with > 1.6 GHz (> 3 6 GB RAM (> 50 GB HDD* with Monitor: 1366x768
(including ABT/SSA Intel and AMD GHz) 16 GB RAM) good performance Recommended for
and other additional technology (HDD at very fast ABT 1680x1050
tools) or ABT Site access times)
(stand-alone) DVD
(SSD drive)
(USB port for SSA-
DNT as alternative to
ethernet connection)
Multiple core
processors, for
example, for VMware

Branch Office Server V6.1 Compatible with > 1.6 GHz (2.5 4 GB RAM (8 HDD size PCI slot or PC card
(BOS) Intel and AMD GHz) GB RAM) depending on (Typ II) or USB2
technology project data
volume

RXT10.3 / RXT10.5 - Compatible with > 1.6 GHz 4 GB RAM HDD size
Intel and AMD depending on
technology project data
volume

Table 167: Minimum hadware requirements of Desigo software products

Key:
* Desigo Xworks Plus (XWP) requires ca. 1.4 GB memory. Automation Building Tool (ABT)
requires ca. 1-2 GB memory. Uncompressed project data requires an additional 0.5 MB memory
per data point (reference value). The performance depends on available memory.

The indicated values apply to a host installation. For stable and reliable operation
of VMware, CPU and RAM requirements are higher.
Values in (…) are recommended, especially if Automation Building Tool (ABT) is
installed on a 64-bit operating system, to allow for larger projects (up to 12 PXC3

374 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
VVS Desigo V6.1
22

with 8 rooms each per ABT project). For details, see chapter Compatibility with
Operating Systems.
16 GB RAM are recommended if two Automation Building Tool (ABT) satellite
projects are opened at the same time, and if in ABT two PXC3 are to be online at
the same time.
Configure SSDs for a long life. See Microsoft documentation (Windows 7 & SSD).
ABT projects require ca. 2.5 times more memory per PXC3 room automation
station compared to PXC automation stations.
Parallel port or USB port for license dongle.
For online functions you need:
● LonWorks interface card or LonWorks dongle
● Ethernet interface
● Connection cable for automation stations
● USB port for P-bus BIM connection
The following software is required:
● Operating system: See chapter Compatibility with Operating Systems
● Microsoft Office: See chapter Compatibility with Microsoft Office
● Acrobat Reader 6.0 or higher (optional installation with tool installation)
● WinZIP
● .NET Framework >= V3.5 (version 3.5 is available on the tool DVD)

22.9 VVS Desigo V6.1

The following table shows the firmware versions delivered with Desigo V6.1
resulting in the valid VVS V6.1.xxx. For firmware compatibility, see also chapter
Automation Level Desigo PX / Desigo Room Automation.

Desigo hardware products Firmware version Required firmware loader

PXM20 V6.10.172 V5.00.000

PXM20-E V6.10.172 V5.00.000

PXC compact (PXC...D) V6.10.172 V5.00.000

V6.00.000

PXC modular (PXC...D) V6.10.172 V6.00.000

PXX-L11/12 and PXX-PBus V6.10.172 V5.00.001

TXI1.OPEN (TX Open module) IOOPEN 4.00.224 -

MODBUS_HQ_ V4.00.246
MBUS_HQ_ V4.00.240
SED2_HQ_ V4.00.226
GENIBUS_HQ_ V4.00.232

TXI2.OPEN (TX Open module) TXI2_FW_V6.00.660 -

TXI2-S.OPEN (TX Open module) TXI2_FW_V6.00.660 -

TXB1.P-BUS V1.1.34 -

PXC3.xxx-100A (Desigo Room Automation) V01.21.28.xxx -

PXC3.7.. (Desigo Room Automation) V01.21.28.xxx

DXR2 (-variants) V01.21.28.xxx -

PX KNX (in PXC00-U) V6.10.172 V5.00.000

PX M-Bus (in PXC00-U) V6.10.172 V5.00.000

PX Modbus (in PXC00-U) V6.10.172 V5.00.000

PX KNX (in PXC001..D) V6.10.172 V6.00.000

375 | 377
Siemens CM110664en_03
2017-09-18
 Compatibility
22 VVS Desigo V6.1

Desigo hardware products Firmware version Required firmware loader

PX M-Bus (in PXC001..D) V6.10.172 V6.00.000

PX Modbus (in PXC001..D) V6.10.172 V6.00.000

PX SCL (in PXC001..D) V6.10.172 V6.00.000

PXG3.M/.L (BACnet router) V01.21.28.xxx -

PXG3.W100 (web interface for PXM touch panel) V01.15.35.xxx -

PXC-NRUF AS Integral Migration V6.10.172 V5.00.000

Table 168: VVS Desigo V6.0 firmware

The versions listed correspond to the latest state upon delivery release of Desigo
V6.1. As part of continuous product improvements, more current firmware versions
(with higher numbers) may be delivered.
For the current state, see the current release notes of the product.

376 | 377
Siemens CM110664en_03
2017-09-18
Issued by © Siemens Switzerland Ltd, 2015
Siemens Switzerland Ltd Technical specifications and availability subject to change without notice.
Building Technologies Division
International Headquarters
Gubelstrasse 22
CH-6301 Zug
+41 58 724 2424
www.siemens.com/buildingtechnologies

Document ID: CM110664en_03 Technical Principles

Edition: 2017-09-18