• Company
• Products
• Sectors
• Automation
• Life Science
• Healthcare
• Power
• Safety
• Services
• News
• References
• Downloads

Modern commercial buildings frequently offer the option of flexible room configurations with movable partition walls. The building automation systems for large and complex buildings need to provide solutions to keep pace with these requirements. New premises need a quick, efficient and reliable way of entering the world of automation systems.

The existing system

The system is based on a distributed programming environment (DPE), which allows work to be carried out on a database from the acquisition phase right through to start-up. During both configuring and start-up, different parts of a project can be worked on at the same time. An integrated security concept permits security precautions to be implemented under Windows 95/98 that go beyond those of NT 4.0. This is achieved by means of a database that can hold all objects. Parts of a project can be "borrowed" from this database and placed in a local database for processing. Users have access to all the data of a project, although they can only edit the data they have borrowed.

The OLE capability of the applications and the use of OLE monikers (unique, persistent key to an object) makes both read and write access possible with other applications. The graphical editor for programming the controllers (Continuous Function Chart, OpenCFC®) is an integral part of the system and speeds up and simplifies the process of programming and parameter assignment with the aid of a library of firmware blocks, various user libraries and complete application solutions. Transmission of the program to the controller is user-friendly and both programming errors and online values are displayed in the created diagram.

Firmware blocks can be positioned in a diagram and interconnected with other blocks. The connections are routed automatically. The drawing sheet has margin bars at either side. These are used for structuring within a diagram or as an interface to the next-highest level. Figure 2 shows the overview diagram to which this diagram belongs, and shows its interfaces as connections of a block. The overview diagram is used for structuring complex projects.

The dynamic building of the future

Can an automation system be as flexible as the room partitions?
To cut down costs, building automation systems are making increasing use of small controllers that can be installed "on the spot". This considerably reduces the amount of cabling, because the distances between sensor and actuator are much shorter. Apart from this, the concept of the dynamic building demands that the automation system should be easily and quickly adaptable to changes in room arrangements. At present, controllers that are going to perform the same task have to be programmed and assigned parameters individually, even though their programs are identical. This is done by loading the program into each controller. Incorporating the controllers into a network makes it considerably easier to put them into operation, because the program can be transferred by means of a network download. Diagnostics only need to be carried out on one of the controllers as an example for the others. If the division of rooms is changed, rewiring is necessary. If changes need to be made to the program, the modified program again has to be loaded into every controller. Because of the large number of controllers, both these changes are time-consuming and carry a high risk of error. In other words, a significant cost factor, which needs to be minimised by improving the process.

Creating groups

To find the key to the solution we need to look at the nature of the problem:
Several thousand miniature controllers are assembled, which are often equipped with identical program logic (floors with numerous rooms that need the same control mechanism), but which are to control different actuators and need to have dedicated addresses in the building network. It is apparent that common features can be used to form structures and that the programs for individual rooms can be formed by multiplication with the intersections of other sets. Example, sunblinds: The windows of a building are fitted with blinds that can be positioned steplessly (each blind is assigned its own controller in this case). The problem here is not to create a program that controls an actuator by processing a few input values. The difficulty lies in the number and interaction of the (up to 4000) controllers throughout the building. Requirements that might be made of sunblinds for a building include: The blinds at the windows of one room should have the same setting. But the windows might not always belong to the same room, because modern buildings have flexible partition walls. Position control should be both manual and centralised. It should be possible to monitor the states of the individual rooms from a central point (visualisation).

Example, lighting: The light fittings in a building are positioned at regular intervals on the ceilings and are in different rooms depending on the position of the partitions. All the light fittings in the same room are to receive the same control instructions. The controllers are divided into groups. Each group represents the external template for an automation task. A group is a set of controllers that all execute the same program. The program that is allocated to the group, which is created using conventional CFC technology, is also only a template. The controllers in a group are referred to as group members. Several group members can be grouped together in a master-slave group. This grouping usually maps the division into rooms. From the combination of the master-slave group (first template) and the function block diagram (second template) the allocation to each individual controller is performed and the "real" program is generated. Example (sunblinds and lighting): In the simplest case of the example outlined above one group would be formed for the controllers allocated to the windows (Group 1) and one group for the controllers allocated to the light fittings (Group 2). Two programs would be written and the room assignment would be handled by creating master-slave groups.

The arrangement of rooms can be mapped onto the group. If partitions are moved, the same change is made in the control system by reconfiguring the master or slaves. Each element (controller/actuator/sensor) of the control system is identified by a unique address. This is called its home address here (HA). Each controller has a home address, but each individual I/O block in the controller is also identified by its own unique home address. The home address is the multiplier of the system. The home address of a controller is thus formed from the fixed part for the group and the individual part for the group member. The home address for slave SS33 in the above example would be 12345678 12345686 12345678.

The program within a group

Each I/O block in a controller is individualised by the same method. The home address of a block is formed from the individual part for the controller and the individual part for the block. Even a simple example of a floor with four rooms and a program with three I/O blocks needs 30 home addresses.

Control output values or sensor signals are no longer transmitted using conventional wiring, but with "network wiring" within a master-slave group. When a change is made in the room layout, the program logic can be modified accordingly and downloaded to the relevant controllers in a matter of minutes.

This network of connections depends entirely on the interface of the program and, because the same program is executed in all the controllers, it must conform to certain conditions:

Master to slaves:

For every control output of the master the program must contain a corresponding control input of the slaves. If the master supplies two values for the slaves, two inputs must be provided in the (same) program. To minimise the load on the network, control output values from a master to its slaves are transmitted in the form of a broadcast. The broadcast is only received by the slaves with the same master-slave address as the master that transmitted it.

Slaves to master:

Each acknowledgement signal of each slave must have a corresponding input provided for it in the master. The number of slaves that can be controlled by a master is therefore restricted by the number of these inputs. Even if each slave in Figure 7 only issues one acknowledgement signal, the master needs to have three inputs.

Applications and operating experience:

The above software, based on the CFC programming environment of OpenPCS (infoteam Software GmbH, Bubenreuth) and the EY 3600 network system (Gebäudeautomatisierung Sauter AG, Basel) is currently applied on several pilot projects all over the world. The most famous one: The Royal Opera House, London.