Architecture

I/O process image

At the lowest level is the process image, via which the application program communicates with the hardware. The connection between the application program and the process image is defined via the I/O mapping. The user specifies which actuator, sensor or subsystem (DALI line, EnOcean line etc.) is assigned to which fieldbus terminal. The TwinCAT Building Automation Manager automatically generates the I/O mapping during the activation of the configuration. As a matter of principle only sensors, actuators or subsystems can be linked with the process image.

Actuators, sensors and subsystems

Information that is read in via input terminals usually has to be prepared. This includes functions such as scaling, filtering, negation, generation of replacement values, flank evaluation or delay. Thus ‘clean’ input signals are available to all higher-level objects. Threshold switches can be defined at sensor level. It is thus possible to activate scenes when the actual value is exceeded or undercut.

An actuator object represents a lamp, a blind drive, a valve actuator or a window drive. The actuator object receives switching commands, prepares them and generates the process data. The behaviour of the actuator can be specified via the parameters of the actuator object. The limitation of the control value for a lamp or the driving duration of a blind drive are just a few examples of this.

Not every sensor object or actuator object is directly connected to a fieldbus terminal. In some cases linking takes place indirectly via a further fieldbus such as DALI, EnOcean or RS485. A subsystem object abstracts the access to such a subsystem. All services required for operation and configuration are also contained in the subsystem object. For example, there is a subsystem object for DALI lines, which is connected to the appropriate DALI fieldbus terminal. The configuration and addressing of the DALI devices can be accomplished with the help of the DALI object. A DALI object also makes all necessary interfaces available, so that a lamp object can access individual DALI lamps. A lamp object can be assigned selectively to a channel of a fieldbus terminal or a DALI lamp of a DALI subsystem. The interface for controlling a lamp is always the same, irrespective of whether a lamp object for DALI or a lamp object for a dimmer terminal is involved. Access to the higher levels is thus “fieldbus-neutral” and considerably simplifies further use.

Actuator groups and sensor groups

It is very frequently necessary to group sensors or actuators. Hence there can be several blind drives in a room that are always driven at the same time, or several temperature sensors, whose average value is passed on to the controller. For this task there is an equivalent group object for each sensor or actuator object. An actuator group object contains a reference to a list of the respective group elements. If the group object receives a switching command, then this is passed on to all group elements. The states of the individual elements are likewise collected and evaluated. It is thus possible to read from each group object how many elements are assigned to this object or how many of them are signalling an error. Like sensor objects, sensor groups can also call scenes with the aid of threshold switches.

Group objects are not limited to one controller. Elements can be assigned not only by the local controller, but also by any controller located within the same network. The TwinCAT Building Automation Manager generates the necessary infrastructure. TwinCAT network variables are used here so that virtually delay-free communication is possible.

The lamp group object is of particular importance if several DALI lamps are registered. The DALI lamps can originate from the same DALI line, from a further DALI line of the same controller or from a DALI line of another controller. The TwinCAT Building Automation Framework ensures that the DALI devices are assigned to the correct DALI groups and that the necessary TwinCAT network variables are created for communication between the controllers. A group of lamps that is distributed over the entire network can thus be controlled with a group object.

Scenes

Scenes have a central function in the TwinCAT Building Automation Framework. Sensor objects, group objects, timer channel objects and weather station objects can exclusively call scenes. Hence, all event-controlled commands merge in the scenes. The result of triggering a scene is that the stored commands are executed. Commands from any local objects may be contained. Since scenes can also be called via the network, they offer an efficient method of executing global building actions (outside lights, changing the mode of operation of the air conditioning system or the like). The cascading of scene calls is also possible. Hence, one scene can call another. This scene may be located on the same controller or on a different one.

Functional units

The task of sensor objects, actuator objects and group objects is to standardise access to the hardware. The objects also contain fundamental functions that affect the input and output. Switching functions are possible via threshold switches. However, this does not suffice for air conditioning or constant light control. This task is performed by functional units. Functional units represent the link between sensors and actuators. The values of the sensors are evaluated according to the task and the assigned actuators are controlled.

Timer switch channels

Recurring events can be activated by timer switch channels. Objects for daily, week and monthly timer switch channels are available for this. Sunrise and sunset can also be selected as events in addition to the absolute time.

Weather stations

The values from the weather stations can be distributed via weather station objects in the network and individually evaluated on each controller. At least one threshold switch can be parameterised for each measured value. This can call scenes selectively when the threshold is exceeded or undercut. The concept of the virtual weather station supports the distribution of the meteorological data over a network. The data is transmitted virtually delay-free on the basis of the TwinCAT real-time network variables. In order to do this, a virtual weather station object is linked to a ‘real’ weather station of another controller. The TwinCAT Building Automation Manager generates all necessary TwinCAT network variables upon activation of the configuration.

Composite modules

Composite modules represent the highest level. They enable access to different objects without being assigned to a specific system such as lighting or air conditioning. This is used, for example, for room control units which frequently access different functional units and which must be capable at the same time of calling scenes. The TwinCAT Building Automation Framework offers two object types with which lighting, shading and scene management can be implemented with simple digital inputs and outputs. Using buttons, individual lights can be dimmed, individual sun blinds can be driven and scenes can be called. However, the scenes can also be changed and persistently saved via the buttons.

Global variables

The individual objects use global variables in order to exchange information and commands with one another. All necessary variables are provided in the PLC library of the TwinCAT Building Automation Framework, so that it is not necessary to explicitly create them.