The Program library

Introduction

The input to the application design process is the functional requirements specified by the customer. With TAC Menta, the application designer can implement the specified control and interlock functions in the BMS controller by selecting and combining appropriate macro blocks from a library. Should the customer requirements not be completely covered by the available library macro blocks, the application designer must also have the option to modify existing library blocks to fit the exact requirements, or, if necessary, implement new functions from “scratch”.

In order to support a modular approach to BMS application design and programming, it is possi­ble to save and load function block groups as macro blocks, which implement more complex re-usable function modules. A macro block file basically consists of a subset of a FBD, i.e. the FB definitions and their interconnections, with open connection points for the input and output signals of the macro block.

By using well tested and documented macro block library modules, the final testing of the completed application can be reduced significantly. In principle, it should only be necessary to verify that the selected modules correspond to the specified functionality, and that the interaction (i.e. the connections) between the used modules is correct.

Macro blocks

TAC supports a central library for application programs designed with TAC Menta. The library consists of two main parts, one standard library, and one user library.

In the standard library, you can find examples of control and super­visory functions, process models and macro blocks for different other functions. All these applications (or parts of applications) have been tested and approved according to TAC's quality system, although not necessarily designed by TAC. Therefore, only the TAC development department may include new applications in the standard library. The purpose of the official TAC standard library is:

• To provide examples of how to implement different functions.

• To provide examples of how to use different blocks.

• To show examples of how to graphically layout different functions.

• To make it possible to design a new application easily and quickly.

• To make it easy to test an application with simulated response from the process.

File structure

The Program library has the following directory structure;

Figure 1. File structure in the TAC Menta Macro block library.

Each directory in the library has a README.DOC file which explains the functionality of the different programs.

The programs in the directories have two parts, one with the graphical FBD source code and one with a textual description in an associated text file.

Macro block design guidelines

Modularisation

When designing a new macro block, it is important to consider the complexity of the function to be implemented as a macro block. If the macro block function is too complex, it may be difficult to re-use it in other applications. A small and easily understandable function is much easier to fit into an application than a more complex macro block with many input and output signals. It is a good rule to have one macro block for each basic control function, such as night cooling, night heating, economiser and so on. Even if the different functions are depending on each other, it is better to implement them as separate modules according to the principle ”one function - one macro block” instead of trying to do everything in one module. This approach also makes it possible to use the macro blocks separately in an application. For example, the macro blocks for night cooling and night heating should interlock each other, but by implementing them as separate macro blocks it is also possible to use night cooling only, without night heating, just by assigning a constant value to the interlock input. Thus, even if not all functions in a macro block are needed in a specific application, a well designed macro block can be used anyway by assigning appropriate constant values to unused inputs.

It is also important to consider how a macro block function handles the situation when there is no water or air flow in the controlled unit. For example, a macro block for control of the minimum return water temperature from a heating coil must also handle the case when the pump is stopped during summer and there is no heating water circulating. This can be done e.g. by using an input flag "Pump running indication".

Global signals and flags

Signals that are used to transmit status information to several macro blocks in an application are called global signals. If the signal is a Boolean value it is often called a global flag, e.g. a flag which indicates if the AHU is running or not. It is more important that all macro blocks are designed to use a common set of global signals and also that they have the same interpretation of them, than from which macro block or function the signal or flag is actually generated. For example, regardless of whether the flag "Normal run" is generated from the running indication of the supply fan or if it is taken directly from the fan control output, it is important that all the macro blocks using that flag have the same interpretation of it (e.g. 1 = on, 0 = off).

FBD Macro block layout

Macro blocks should have a consistent design and layout so that the application FBD is easy to read. Thus, the following design rules are suggested:

• The whole block should be enclosed by a dotted line.

• Block name in upper left corner; bold text, size 12 and underlined.

• Place file name, last edit date and author signature near the block name.

• Place Input signals on the left side, with explanations and units.

• Place Output signals on the right side, with explanations and units.

• A short description of the function, wherever suitable.

• The actual Macro block could be collapsed to a hierarchy functional block (HFB), but still, it must have comments for in- and output signals on all levels.

• The Macro block shall have an associated text file, written in Microsoft Word, with the extension *.doc.

Figure 2. Example of macro block FBD.

Associated text files

The text file associated with a macro block may be written with any kind of editor, but must be an ASCII-file with the extension .TXT, WRI or .DOC. The text file should contain a complete and detailed functional description of the macro block, a list of inputs and outputs (including their types and units), and also a list of all public variables with their initial values and units.

It should also have a history list with notes of all changes that are made in the program with date and signature of the author cf. Figure 3.

Domestic hot water control

==========================

File: hotwater.txt

Last edition: 96-10-01
Author: Mikael Krantz

History: 96-02-09/MK First released version.

96-10-01/MK Updated to Menta 1.20

Description

===========

The domestic hot water controller has a load depending dead zone changeover, to take care of low flow at HWC. There is also a time control to set a setpoint offset during night periods.

The dead zone changeover takes place when the output signal goes

below the "HWCFlow" set limit with a hysteresis of +- 1%.

Inputs:

=======

(Real) Domestic hot water temperature

Outputs:

========

(Real) Domestic hot water control signal

Parameters:

===========

(Real) HWCFlow 10%

(Real) HotWaterSV 50 °C

(Real) HotWaterSetback 0 °C

(Real) HotWaterPBand 50 °C

(Real) HotWaterITime 30 seconds

(Real) HWCDzone 5 °C

(Real) HWTravelTime 15 seconds

(TSCH) HotWaterTime 00:00 24:00 MTWTFSS

Public signals:

===============

(Real) ActualHotWaterSP

(Real) HotWaterControl

(Real) HotWaterITime

(Real) HotWaterPBand

(Real) HWCFlow

(Real) HotWaterSetback

(Real) HotWaterSV

(TSCH) HotWaterTime

(Real) HWCDzone

(Real) HWTravelTime

Figure 3. Example of macro block text file.

Process models

Within the TAC Menta environment, models of common HVAC are developed for use during offline test together with an application program. By connecting the application program to suitable models, we are able to simulate how the control system and the physical processes will influence each other. In this way we can get good knowledge about the system behaviour already in the programming phase. The system simulation also gives us an excellent tool for trouble-shooting in an efficient environment. Programming errors that before usually were discovered during commissioning, can now be detected during the programming phase.

A process model FBD has always an associated text file describing the model, it's inputs, output, parameters and hints on how to use the model.

Model accuracy and restrictions

When you make models of physical processes it is important to know how they are going to be used. If you e.g. are a heat exchanger manufacturer, you might need a model for calculation of the heat exchanger efficiency for different water velocities and plate properties. But, if you program or commission an application, you need models for evaluation of the control system instead. The models must describe the dynamic behaviour, although but the demands on accuracy are moderate. The models can be relatively simple because then they take less screen space and will execute faster. The purpose of the models in this library is to fulfil the demands for this later category of people.

Since the models are simple they have some restrictions. An important restriction for the models used in ducts, e.g. Cooler and Heater is that they are designed under the assumption of a constant air flow in the duct. Thus, these models should not be used when we have a varying air flow. However, the Fan speed model work with varying flow, but the other components are not affected by the air flow.

In some cases it may be necessary to adjust the constants of the model. The general rule is however that if you are not an experienced user you should stick to the nominal values. The reason for this is that the models have been tested with these constants and proved to give good results.

How to use process models

We will here give an example of how the process models can be used. The application is supply temperature control in a simple AHU consisting of a heating coil, a heat recovering rotating wheel and a cooling coil. For simplicity we will disregard the control of the fans:

Figure 4. Process example.

We have chosen to have different cooling and heating setpoints. The controller switches to heating operation when the supply temperature is below the heating setpoint, and it switches to cooling operation when the supply temperature is above the cooling setpoint. We are just studying the sequence in normal operation, i.e. we have no freeze protection, cool recovery etc.

The first step is to define what the HVAC-system looks like, i.e. what components the system consists of and how they are connected. In our example we have 3 components that influence the supply temperature (we neglect the influence of the supply fan on the supply temperature), the rotating wheel, the heating coil and the cooling coil. This implies that we will need the following models from the model library; HX Air2Air (model of a rotating wheel), Heater (model of a heating coil) and Cooler (model of a cooling coil).

The next step is to decide how the inputs of a certain model should be connected. Let us see how the model of the rotating wheel (HX Air2Air) should be connected. This model has 3 inputs. The inputs are; Temperature before HX (supply), Temperature before HX (return) and Control signal. We can see that the supply air to the HX comes directly from outdoor, i.e. we should connect an outdoor temperature to the input Temperature before HX (supply). We could e.g. use a PVR-block with the value 10 to represent the outdoor temperature. In the same way we see that the return air entering the HX is coming from the room. If we assume that the room temperature is 25 °C, we can connect a PVR-block with the value 25 to the input Temperature before HX (return). Finally, we have to connect the Control Signal. This signal is an output from the controller. The Control Signal that comes from a physical output should be connected to the model via a test probe.

To fulfil the example given in figure 4 above, the supply air temperature could origin from a PVR-block in to the rotating wheel model. The resulting calculated supply air temperature is used as input to the heating coil model.

The resulting calculated supply air temperature from the heating coil model is used as input to the cooling coil model.

The signal from the resulting calculated supply air temperature from the cooling coil model is used as input to the control program. This signal is also connected via test probes.

---