EY-modulo 5 Engineering Guidelines

(1)

EY-modulo 5

Engineering Guidelines

Version 1.0 - E

(2)

(3)

Preface

Dear Colleagues,

Executing customer projects efficiently is crucial to our business success. Services account for around 25% of total project costs. Minimising the time and expense that go into designing a system, building it and putting it into operation is thus one of our top objectives – an objective that we address using our SAUTER CASE Suite engineering tool with its associated libraries.

Beyond achievement of this objective, we also see an enormous boost to project efficiency and, moving forward, in service efficiency as well by applying standards to system design. This is especially relevant with regard to the introduction of SAUTER EY-modulo 5 and BACnet, which further increase the complexity of our solutions and the number of potential sources for error. That makes it absolutely necessary to introduce a set of standardised design guidelines – the “BACnet Project Guidelines”.

This document makes available an initial version of these guidelines. It is a system of rules and standards that is based on experience obtained from real-world BACnet projects. An interdisciplinary team has spent many hours bringing all this experience together, and formalising it. The first presentations and user training sessions have already taken place. The next step is to spread and implement these rules throughout Sauter.

We look forward to receiving feedback from people working on projects so we can continue improving the Guidelines, and trust that the guidelines we are putting in your hands today will indeed prove useful to you.

Walter Reithofer

(4)

5.5 VALUE TRANSMISSION... 29 6. SETPOINT ADJUSTMENT... 30 7. CONTROL... 31 7.1 SAUTER'S RECOMMENDATION... 31 7.2 PARAMETERISATION... 31 8. TIME PROFILE ... 32 8.1 SCHEDULE OBJECT... 32 8.2 CALENDAR OBJECT... 34 9. DATA LOGGING ... 36 10. VENTILATION PROGRAMMING-RESPECTS ... 38 10.1 DDC-PLANT SWITCH... 38 10.2 THE DAMPERS... 39 10.3 THE HEATING COIL... 40 10.3.1 The valve... 40 10.3.2 The pump ... 41 10.4 THE COOLING COIL... 42 10.4.1 The valve... 42 10.4.2 The pump ... 42 10.5 THE FAN... 43

11. HEATING GROUP PROGRAMMING-RESPECTS... 44

11.1 PLANT SWITCHING... 44

11.2 ALARM SWITCHING... 45

12. WORKFLOW CASE VISION... 46

12.1 WITH A CASEBUILDER PROJECT... 46

12.2 WITH A CASEENGINE PROJECT WITHOUT CASEBUILDER... 46

13. BMS SETTINGS ... 47

13.1 INFORMATION ABOUT CHARACTERS... 47

FINAL LINES ... 48

(6)

1. BACnet Basics

1.1 What is BACnet?

BACnet denotes the "Data Communication Protocol for Building Automation and Control Networks".

BACnet is a manufacturer-neutral data transfer protocol for "open communication" in building automation, and for the control and regulation technology which it includes. BACnet enables communication between equipment in different systems, from different manufacturers.

BACnet was developed as a set of guidelines by ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers).

1.2 History

1987: ASHRAE set up Standard Project Committee SPC 135P, which included operators, consultants and representatives of official bodies as well as company staff. The Committee's remit was to define a communication protocol for the monitoring, control and energy management of buildings that would be suitable for general use.

1989: First report published in the ASHRAE Journal regarding the concept for a building automation communication protocol.

1991: The first draft of the new protocol was submitted to the public for comments. The second draft was published in March 1994. A third draft was published early in 1995. More than 790 comments (many of them from Europe) were received on the three submitted drafts.

1995: BACnet was adopted by ANSI (American National Standards Institute) as ANSI/ASHRAE Standard 135-1995.

1998: BACnet was implemented as the European experimental standard for the management level by CEN/TC 247, and was implemented as DIN pre-standard DIN V ENV 1805-1.

1999: BACnet /IP with Addendum 135a became part of ANSI/ASHRAE standard 135-1995. BACnet devices could communicate directly with one another on a LAN or WAN with the help of the Internet protocol.

2002: As expected, after worldwide coordination, BACnet was designated as global standard ISO/DIS 16484-5:2002 (Draft International Standard) and was given the European code of prEN ISO 16484-5. BACnet had thus successfully completed the long official journey from ASHRAE guideline to global EN-ISO standard.

(7)

1.3 Network technologies

BACnet can be used on different network technologies. The Sauter modulo 5 series operates with Ethernet technology.

A BA network with BACnet can manage up to 65,535 linked sub-networks. This allows enormous flexibility as regards the integration of systems in different buildings. This BACnet network addressing must be unique throughout the entire inter-network; this calls for cross-project organisation in cases where heterogeneous systems are used. Allocation of network numbers must be planned and defined for all the project participants.

1.4 BACnet Device

A BA network with BACnet may contain up to 4,194,305 participants (subscribers, or devices). This restriction is due to the technical address: each device must be uniquely definable within the BA network.

(8)

1.5 BACnet objects

Objects are used for programming. The BACnet standard defines various object types:

• Analogue Input • Analogue Output • Analogue Value • Binary Input • Binary Output • Loop • Notification Class • Schedule • etc.

In CASE Engine, some objects are used as function modules.

An object consists of a set of uniquely named and structured data elements. These data elements can be used to call up all the key information for building automation.

BACnet specifies that each object is referenced by means of an object name. The protocol does not specify any naming conventions for this purpose, but it does define a minimum length (in characters). To increase the efficiency of access to BACnet objects via the BA network, BACnet objects are additionally identified within a device by a technical 32-bit address known as the

instance number.

(9)

1.6 BACnet services

The objects communicate with each other with the help of the BACnet services.

The BACnet standard differentiates between confirmed services and unconfirmed services. A confirmed service typically expects a response. No response is expected in the case of unconfirmed services.

1.6.1 Alarm and event services

Alarm and event services are concerned with changes to the conditions recognised by a BACnet device. These services may report alarm status, fault status, operating status, fault/error status or changes to a measured value.

Alarm and event services:

• AcknowledgeAlarm • ConfirmedCOVNotification • UnconfirmedCOVNotification • ConfirmedEventNotification • UnconfirmedEventNotification • etc...

1.6.2 Object access services

Object access services describe options for reading and writing the properties of BACnet objects. These services are confirmed transactions.

Object access services:

• CreateObject • DeleteObject • ReadProperty • WriteProperty • etc...

1.6.3 Device and network management services

The higher-level services for "Device and Network Management" offer a number of different functions which allow the operator of the BA network to execute automatic restarts and automatic configuration, and to influence the configuration and the network behaviour. There are also options for setting up special manufacturer-specific features and new developments without affecting interoperability.

Device and network management services:

• ReinitializeDevice • TimeSynchronization • Who-Is

• I-Am • etc...

(10)

2. Stations

2.1 Parameterisation

2.1.1 IP Basics

IP (Internet Protocol) enables logical addressing of devices (hosts) that are connected to the usual kinds of IP network. Here, every host has at least one unique IP address of its own. Addresses are 4 bytes long (32 bits). That makes it possible to have around 4.3 billion distinct addresses.

Each of these 32-bit IP addresses contains a network block, and a device block. The way the 32 bits are apportioned between the network and the device blocks is defined by a subnet mask. Like the IP address, this subnet mask also consists of 32 bits. However, these are nothing more than a sequence of 0s and 1s. All the bits that correspond to the network block are set to 1 in the subnet mask, and all the bits corresponding to the device block are set to 0. In this way, it is possible to configure any desired apportioning between the network and device blocks of the IP address.

The network block (NET-ID) must be identical for all devices within a particular LAN. The device block (HOST-ID) is individually and uniquely assigned per device and interface (network card).

Example: the subnet mask is 255.255.255.0; all of the IP addresses within this LAN must therefore contain three identical bytes: e.g. 192.168.1.x. The last byte of the IP address, configured as 0s in the subnet mask, then varies from host to host (e.g. 11, 1, 32, 119, etc.).

The first device address (network address) should be left unassigned (e.g. 192.168.1.0). The highest device address is at present used for non-targeted (broadcast) messages to all the devices (e.g. 192.168.1.255).

(11)

When a device wants to send an IP packet, a comparison is made between the network block (NET-ID) of the source IP address, and the destination IP address. If they match, the packet is sent through the local network directly to the recipient. However, if the network blocks do not match, the IP address of the next device in line is picked out from a routing table, and the packet is sent via the local network to this device. It has multiple interfaces with access to other networks, and routes the packet to the next network along. To do this, the router for its part consults its own routing table and forwards the packet either to the next router, or to its final network destination as the case may be. A packet en route to its final destination may traverse numerous networks and routers.

When a station on the network wants to communicate with a station in another network, a router is necessary. For routing to work, both the sender and the recipient must know the address of the router within their respective local networks. This router address is often called the “Gateway address” (GW). The example below shows routing in operation within two private networks.

2.1.2 Address ranges

To provide for adequate IP address resources worldwide, three private address ranges were created. These addresses are used for private networks (LANs) only, not on the wider internet.

Class Address range Subnet mask Number of

IP-addresses Number of networks A 10.0.0.0 – 10.255.255.255 255.0.0.0 16 777 216 1 B 172.16.0.0 – 172.31.255.255 255.255.0.0 1 048 576 16 C 192.168.0.0 – 192.168.255.255 255.255.255.0 65 536 256

Stations should always be parameterised using private addresses. The address range for Sauter stations should be assigned by the customer’s CIT department.

Further IP address ranges exist that are reserved for special tasks and functions. For example, the “Automatic Private IP Addressing” function, APIPA for short, enables a station on the network to assign its own IP address. Our EY-modulo5 stations use this method when they boot up. They can then be addressed via the CASE SUN administration tool and configured/addressed with their final IP addresses (address range: 169.254.0.0 – 169.254.255.255).

(12)

2.1.3 DHCP

Next to static IP addresses, a host may be assigned a fresh IP address every time it sets up a connection with the network. This is known as dynamic addressing. Dynamic addressing by means of DHCP (Dynamic Host Configuration Protocol) is very widespread in LAN environments.

For a variety of reasons, Sauter recommends configuring modulo5 stations with fixed (static) IP addresses, and not to use DHCP.

2.1.4 Device ID

BACnet devices are represented in the BACnet protocol as objects. Just like other objects, they must have an “instance number” (Device ID or DOI).

Sauter recommends using the HOST_ID block of the IP address as the device ID

2.1.5 Port numbers

Ports are constituents of addresses that network protocols use to allocate data segments to their correct services (protocols).

Port numbers are 16-bit quantities, i.e. they can range in value from 0 to 65535.

(13)

2.2 Project planning table

Our recommendation for efficient network project planning is always to begin by filling out the table with all the key information for every station (location, IP configuration, …).

This table should be printed out at the end, so an electrician can affix the serial number stickers to the stations.

S e ri a l n u m b e r In s ta n c e n u m b e r S u b n e t M a s k IP -A d re s s S ta ti o n t y p e M C C o r ro o m F lo o r B u il d in g

(14)

3. Priority-Array

3.1 Principle

One of the strengths of the BACnet protocol is the priority array.

To enable prioritised processing of commands from different sources (process, manual operating panel, management level), the function modules make use of a priority control. The various sources write their values into a priority matrix within the module, including the relevant priority. 16 levels are available to prioritise the commands or functions. Level 1 has the highest priority and level 16 has the lowest.

In this matrix, the value that was last written to the highest priority is always output to "Present Value". If no released process value is available, the preset value "RlqDef" (Relinquish Default) is used.

3.2 Sauter Standard

On account of interoperability, five priorities are already pre-defined in BACnet. The other priorities are available for project-specific allocation.

A Sauter standard has been defined for the use of the free BACnet priorities.

Priority BACnet standard SAUTER standard

1 Manual-Life Safety Manual Safety 2 Automatic-Life Safety Automatic Safety

3 available Free

4 available Free

5 Critical Equipment Control Critical Application 6 Minimum On/Off Minimum On/Off

7 available Manual Operating Mode (HW switching on AS)

8 Manual Operator Manual Operating Mode (BMS systems + modu840)

9 available free

10 available free

11 available LOOP Controller

12 available free

13 available free

14 available Local Time Programmes

15 available Global Time Programmes

16 available Automatic Operating Mode

N.B.: Safety switching operations (frost, excessive temperature, damper or motor faults, etc.) and alarm suppression (Overridden, Out-Of-Service) should be set to priority 5 (Critical Application). Fire protection dampers are set to priority 2.

(15)

3.3 Priority connections

Structural parameter "PrioConn" can be set to execute two priority levels as connections, to be written by processes within the device. Setting these structural parameters also enables the associated properties.

So that the priority array can be used to switch specific statuses on the plant devices, the output HW modules (AO, BO, MO) each have two priority inputs, PrioV1 and PrioV2. An activation signal is required to enable the relevant input. These are inputs EnPrioV1 and EnPrioV2.

For priority values "PrioV1" and "PrioV2", it is possible to define priorities "Prio1" and "Prio2", with which they will be written to the priority matrix. Each of them can be pre-assigned a priority from 1 to 15.

Writing of this priority value to the corresponding position in the priority matrix must be enabled with "EnPrioV1" and "EnPrioV2".

(16)

3.4 Konfigurationsbeispielen

3.4.1 Frostschutz Konfiguration

Frost protection information (EnPrioV2 = 1) acts on priority 5 (value configured for priority input 2, "Prio2"). In case of frost, the heating coil valve is fully opened (100% on input PrioV2).

The "Present Value" then has value 100 for frost protection.

3.4.2 Configuration of main switch

In general, a BV module is used for the DDC main switch.

In that configuration, the signal "Alarm" has the highest priority (Prio2 = 5). If the value of "Alarm" is 1, then PV receives the value which is configured on "PrioV2" (in that example 0).

If the value of "Alarm" is 0, then the signal "Auto" is tested. If in that case "Auto" has the value 1, then PV receives the value which is configured on "PrioV1" (in that example 1).

If the both signals "Alarm" and "Auto" have the value 0, then PV receives the value which is configured for the property RlqDef (Relinquish Default, in that example 0).

(17)

4. Intrinsic Reporting

Intrinsic reporting offers the possibility of notifying clients about events or alarms that occur. Clients can enter themselves in the list of recipients.

The Notification Class object is used to specify the type of event or alarm for intrinsic reporting. This represents any desired number of objects that trigger events, and defines the type of alarm, e.g. its priority and whether an alarm acknowledgement is required.

4.1 Enable function

First of all, the IR structural parameter must be enabled in the properties of the various BACnet objects. Once this structural parameter is enabled, optional functions and the associated properties are also enabled.

4.2 Sauter recommendations

Sauter recommends that the IR function is always enabled for these objects:

• AI (measurement) • PC (counters)

• AV (setpoints and calculated setpoints) • AO (analogue hardware output)

• BO (digital hardware output) • LOOP (controller)

• BI (for alarm hardware feedback only) • MI (for alarm hardware feedback only) • BV (for alarm software feedback only) • MV (for alarm software feedback only)

(18)

4.3 State monitoring

BACnet differentiates between three basic states for notifying events:

• NORMAL (Prio3) : normal operating mode

• OFFNORMAL (Prio2) : alarm status/state

• FAULT(Prio1) : value is unreliable

The state is shown in the Event_State property, "EvTSt".

If intrinsic reporting is disabled, "EvtSt" only shows the current fault status (NO_FAULT_DETECTED (= NORMAL) or FAULT). In this case, the alarm state is not monitored. Intrinsic reporting must be enabled so that EvtSt will show the detailed alarm and fault status (NORMAL; OFFNORMAL; FAULT).

If IR is enabled, the Present Value (PV) is always compared with one (or more) alarm values. For a transition to the OFFNORMAL state, the PV must correspond to an alarm value for at least the notification time delay TiDly (Time_Delay).

For a transition back to the NORMAL state, the PV must be unequal to an alarm value for at least the notification time delayTiDly (Time_Delay).

A transition to the FAULT state occurs without the notification time delay TiDly (Time_Delay) and always takes priority over another state. A fault code is signalled by the Reliability property.

Every transition from one state to another can be enabled by the corresponding release parameter, "Event Enable" (EvtEn) for event transmission:

• TO-OFFNORMAL (EvtEnTON) • TO-FAULT (EvtEnTF)

• TO-NORMAL (EvtEnTN)

(19)

4.4 Transmission of notifications

A notification class "NtfCl" (Notification_Class) specifies how the notification is transmitted. Within one station, up to 16 Notification Class objects can be used.

For each of the 3 transition types (TO-OFFNORMAL, TO-FAULT and TO-NORMAL), the relevant Notification Class specifies whether an acknowledgement is required.

255 priorities are also available in order to prioritise the event transitions (To-Offnormal, To-Fault, To-Normal). On account of interoperability, the event priorities are already assigned in BACnet, according to their importance and the priority scheme.

4.4.1 Sauter standard for notification classes

For each complete, integrated BACnet system, the priorities and acknowledgement obligations must already be defined during the planning stage.

A Sauter standard for notification classes is defined in the following table.

NC Area Event priority Network priority scheme Acknow-ledgement To-Offnormal Acknow-ledgement To-Fault Acknow-ledgement To-Normal Importance 100 General 101 Heating 102 Ventilation 103 Cooling

00 - 63 Life Safety message yes yes yes Prio1

200 General 201 Heating 202 Ventilation 203 Cooling

64 - 95 Critical Equipment

Message yes yes yes Prio2

96 - 127 Urgent message yes yes no Prio3

128 - 255 Normal message /

Trend Log no no no Prio4

"Urgent message": alarms do not switch the plant off. "Critical Equipment message": alarms switch the plant off.

(20)

4.4.2 Alarm visualisation in moduWeb

Alarms are displayed in moduWeb with the "event priority":

4.4.3 Insertion of Notification-Classes in CASE Engine

The required Notification-Classes should be imported from the library.

Double-click on an imported object open a configuration window where the settings can be modified.

N.B.: during the conversion, CASE Engine 2.2 does not currently check whether the Notification Classes configured in the objects are also generated in the station.

This check should be performed manually, using the table function:

1._{At AS level, open the Table view} 2._{Set filter to notification class, "Ntfcl"}

3._{Check whether all notification classes are defined in the AS}

Values in parentheses are the event priorities

(21)

4.5 Collective alarm concept

4.5.1 Principle

Firmware modules "ST_OV_ACK" should be used for collective alarms and acknowledgements. An "ST_OV_ACK" should be used for each notification class. The relevant notification class number must be set in the parameters for these modules.

The alarm objects in the plant, which are also assigned this NC (parameter in the object), trigger an alarm notification to this ST_OV_ACK module in the event of an alarm.

The inputs and outputs of the "ST_OV_ACK" always refer to all the objects belonging to a notification class (i.e. those which reference the same notification class object).

(22)

ST_OV_ACK module

Outputs Denotes

UAckAl Signals the presence of at least one unacknowledged TO-OFFNORMAL

transition, with NotifyType: Alarm.

SmUAckAl Indicates the total number of unacknowledged TO-OFFNORMAL transitions,

with NotifyType: Alarm.

UAckEvt Signals the presence of at least one unacknowledged TO-OFFNORMAL

transition, with NotifyType: Event

SmUAckEvt Indicates the total number of unacknowledged TO-OFFNORMAL transitions,

with NotifyType: Event.

UAckTF Signals the presence of at least one unacknowledged TO-FAULT transition

SmUAckTF Indicates the total number of unacknowledged TO-FAULT transitions

UAckTN Signals the presence of at least one unacknowledged TO-NORMAL

transition

SmUAckTN Indicates the total number of unacknowledged TO-NORMAL transitions.

StAl Signals the presence of at least one OFFNORMAL state with NotifyType:

Alarm

SmStAl Indicates the total number of all OFFNORMAL states, type Alarm.

StEvt Signals the presence of at least one OFFNORMAL state with NotifyType:

Event

SmStEvt Indicates the total number of all OFFNORMAL states, type: Event.

StFlt Signals the presence of at least one FAULT state.

SmStFlt Indicates the total number of all FAULT states.

StN Signals the presence of at least one NORMAL state.

SmStN Indicates the total number of all NORMAL states.

StOvR Signals the presence of at least one OVERRIDDEN state.

SmStOvR Indicates the total number of all OVERRIDDEN states.

StOoS Signals the presence of at least one OUT_OF_SERVICE state.

SmStOoS Indicates the total of all OUT_OF_SERVICE states.

Inputs Denotes

AckTrnON Acknowledges all as yet unacknowledged TO-OFFNORMAL state

transitions.

(23)

4.5.2 Collective alarms and acknowledgements: recommended plan

In each station, there should be a collective alarm plan containing the various ST_OV_ACK modules for all the notification classes used in the program.

In the above example, all unacknowledged alarms (OFFNORMAL and FAULT states) and all pending alarms (OFFNORMAL and FAULT states) are gathered together for three notification classes.

At the plan output, there is a lamp command which is normally connected to a BO. If unacknowledged alarms are signalled, the lamp will flash. If no unacknowledged alarms are signalled and there are only pending alarms, the lamp will be on. The lamp goes out if no unacknowledged alarms and no pending alarms are signalled.

Alarms can be acknowledged via:

• Management level; each object independently, or jointly

• A binary input which can be connected to the ST_OV_ACK modules (example below).

In the above example, all state transitions are acknowledged with a signal (OFFNORMAL, TO-FAULT, TO-NORMAL).

(24)

4.6 Status flags

The status flags indicate the four most important states of a BACnet object:

• IN_ALARM (IA) : indicates an alarm state (Event State OFFNORMAL)

• FAULT (Flt) : indicates a reliability problem (Event State FAULT)

• OVERRIDEN (Ovr) : indicates manual override (e.g. by an operating unit)

• OUT_OF_SERVICE (OoSrv): indicates shutdown.

It is not necessary to evaluate the present values for the alarms; instead, the "In-Alarm" and "Fault" status flags are evaluated. This alarm information can be held until the required acknowledgement has taken place.

4.6.1 Enable function

To use the status flags in the program, the IR function must first be enabled in the object properties.

Once IR is enabled, parameter "StFlgConn" can be selected. This structural parameter specifies whether the status flags are made available as outputs on the module, and setting parameters are also enabled.

(25)

4.6.2 Status flag connector

When structural parameter "StFlgConn" is enabled, additional output connectors are also enabled.

Status Flag Connectors

Outputs Denotes

StUAck Status or missing acknowledgement

StUAckAl Active or unacknowledged alarm

Bit value 1 of StUAck

StUAckFlt Active or unacknowledged fault

StFOvR Manual override - Overridden

Bit value 3 of StUAck StFOoS Out of Service

4.6.3 Parameterisation

The two parameters "AlSt" and "FltSt" can be used to parameterise the alarms. Parameter "AlSt" is for the IN_ALARM state (Event State OFFNORMAL) and parameter "FltSt" is for the FAULT state (Event State FAULT).

(26)

There are three setting options for these two parameters: Active, Held or Unacknowledged.

Status Flag Outputs

StUAckAl StUAckFlt

1 : Alarm active Active

0 : Alarm inactive No effect 1 : Alarm active or unacknowledged

Held

0 : Alarm inactive and acknowledged No effect 1 : Alarm unacknowledged

A

lS

t

Unacknowledged

0 : Alarm acknowledged No effect 1 : Fault active

Active No effect

0 : Fault inactive

1 : Fault active or unacknowledged

Held No effect

0 : Fault inactive and acknowledged 1 : Fault unacknowledged F lt S t Unacknowledged No effect 0 : Fault acknowledged

As a general rule, it is always advisable to set parameters "AlSt" and "FltSt" to "Held" because a parameter has already been set in the notification classes to specify whether or not an acknowledgement is necessary.

The acknowledgement can be made at various levels: BACnet-Client, moduWeb, modu840 or also locally (acknowledgement key).

4.6.4 Application

Outputs "StUAckAl" and "StUAckFlt" can be linked to an OR module so that only one alarm output signal is present for the OFFNORMAL and FAULT states.

(27)

4.6.5 OVERRIDDEN state

If an output is switched via the operating unit from automatic mode, it is signalled via status flag "StFOvR".

This notification can be used:

• As an indication of "manual manipulation";

• To suppress the command execution check alarm that may occur (requires additional

programming).

4.6.6 OUT_OF_SERVICE state

The OUT_OF_SERVICE state can be enabled for test purposes via parameter "OoSrv". In this state, the hardware connection is temporarily interrupted. The "Present_Value" initially remains at the last input value, and it can be set to any desired value. When OUT_OF_SERVICE is reset, the "Present_Value" again shows the current input value. That state is signalled via status flag "StFOoS".

Out of Service is signalled in moduWeb by a yellow exclamation mark, and the PV can also be adjusted afterwards.

(28)

4.7 Alarm suppression

For example, for an inspection switch, the alarms can be suppressed.

For the inspection switch, in general a BI module is used. That object is called the "Object reference"

The Present Value of the object reference must be set to 1 in order to suppress the alarm. Parameters for the object reference may need to be adapted in order to meet these conditions. Configuration of object reference for alarm suppression:

Parameter Settings

HW active state Parameter "Pol" Parameter "AlV"

0 Reverse 1

1 Normal 1

For the objects where the alarm must be suppressed, the "Intrinsic Reporting" function must be activated first. In the tab "Alarm Suppression", the object reference and the tested property

must be selected.

It's possible to select the property "Present Value" (Test of the active state of the object reference) or "event suppress active" (only if the function "Intrinsic Reporting" is activated in the object reference). With the second possibility, the alarms are suppressed only if the alarms of the object

(29)

5. Setting the measurement values

An AI module should be used for measurement values. The parameters can be set relatively quickly in the properties.

5.1 General settings

The "Intrinsic Reporting" (IR) function should always be enabled, because this can be used to implement sensor monitoring (FAULT status) and limit value monitoring (Status OFFNORMAL).

The relevant notification class number should be entered in NtfCl. Parameter Unt can be used to set the unit for the measured value.

(30)

5.2 Limit value monitoring

LiEnLoLi and LiEnHiLi can be used to enable or disable limit value monitoring.

The limit values can be set with LoLi and HiLi. These limit values can either be entered in the properties for the module, or external values can be linked to the module inputs if function "LimConn" is enabled in the structural parameter (module definition).

Parameter DB is used to set the hysteresis.

For a transition to the OFFNORMAL/LOW_LIMIT state, PV must fall below the lower limit value

LoLi for at least the notification time delay TiDly (Time_Delay). For a transition back to NORMAL state, PV must again exceed the lower limit value LoLi plus hysteresis DB (Deadband) for at least the notification time delay TiDly (Time_Delay).

For a transition to the OFFNORMAL/HIGH_LIMIT state, PV must exceed the upper limit value HiLi

for at least the notification time delay TiDly (Time_Delay). For the transition back to the NORMAL state, PV must again fall below the upper limit value HiLi minus hysteresis DB (Deadband) for at least the notification time delay TiDly (Time_Delay).

The limit value violation is also shown in the form of flags (EvtStHiLi and EvtStLoLi) on the outputs of the module (but only if structural parameter "LimConn" is enabled).

5.3 Reliability and communication error

With MinPV and MaxPV it's possible to define a range of valid value. If the Present Value PV is outside of the valid range, then the Event State is FAULT.

(31)

5.4 Status Flags

Structural parameter "StFlgConn" specifies whether the status flags are made available as outputs on the function module.

Parameters "AlSt" and "FltSt" should be set to "Held".

The following information is shown by the status flags at the function module output:

1 : Alarm (OFFNORMAL) active or unacknowledged StUAckAl

0 : Alarm (OFFNORMAL) inactive and acknowledged 1 : Fault (FAULT) active or unacknowledged

StUAckFlt

0 : Fault (FAULT) inactive and acknowledged

5.5 Value transmission

Value changes are transmitted to subscribed BACnet clients if the present value PV exceeds the threshold value COVIncr or if a status indicator (flag) StFlg changes. In addition, the present value is transmitted cyclically within the CoVPrd.

CoVIncr should be set so that the system bus is not overloaded.

(32)

6. Setpoint adjustment

AV modules should be used for setpoints. The parameters can be set relatively quickly in the properties.

Structural parameter "IR" (Intrinsic Reporting) should always be enabled to allow monitoring of limit values.

Structural parameters "Cmdbl" and "Wrtbl" must be enabled for adjustable setpoints. For calculated setpoints, "Cmdbl" must not be enabled.

(33)

7. Control

7.1 Sauter's recommendation

Control should always be implemented with LOOP modules.

The LOOP object is a control module which allows the controller parameters to be changed via BACnet without additional wiring.

N.B.: A maximum of 16 LOOP modules per AS is possible.

7.2 Parameterisation

(34)

8. Time profile

The Schedule object plays a key part as regards time profiles.

The links between Schedule objects and commanded outputs are made by means of references. The commanded objects may be local (in the same device as the Schedule object) or global (in another device on the network).

Separate Schedule objects must be used for different data types (digital or analogue outputs). Calendar objects should be used for exceptions relating to more than one object.

8.1 Schedule Object

For the creation of a Time Program, the properties of the Schedule Objects should be set first.

(35)

Various properties should be entered on the "General" tab: instance number, object name, description, etc.

The "Safety priority" property should have value 14 if the time profile is local or 15 if the time profile is global. These values are taken from the Priority Array table (see section Priority-Array). The data type for the "Present Value" of the object should be defined in the "Data type" property:

• Unsigned: for Multistate and OPT_H objects • Real: for Analogue objects

• AnyEnumerated: for Binary objects

The "Schedule Default" property should have the default value of midnight.

On the second tab, "Parameter references" those objects are specified to which the predefined values from the time plan should be written.

On the third tab, "Weekly tasks", the weekly tasks are defined and shown in a table.

A profile with values and times can be created for each day of the week.

(36)

The exceptions are defined on the fourth tab "Exceptions" of the time profile object configuration window. "New" adds a new item to the list of exceptions.

Items may be a day, period, specific days (weeks or months) or a reference to a "Calendar" object, and they include time and value information. The priority should be set to 14 (local TP) or 15 (Global TP).

8.2 Calendar object

If the exception relates to several objects, it should be defined in a Calendar object and only one reference should be entered in the time profile objects.

The Calendar object is independent of the data type. The same Calendar object can therefore be used for objects that utilise different data types.

(37)

Double-click on the Calendar object that has been created to open a configuration window where the general settings should be made first (instance number, object name, description, etc.)

The calendar entries can be set for the exceptions. Click on the "New" button to open a configuration window.

This window allows you to make three different calendar entries, in accordance with the BACnet standard:

• A specific date only (Date) • A date range (DateRange)

• A combination: day of the week, week and month (WeekNDay)

Once the Calendar object has been parameterised, all that remains is to reference the various objects as described at the start of this section:

1 - Select "CalendarReference" in the "Exception configuration window" for the object(s). 2 - Select the relevant Calendar object.

(38)

9. Data logging

BACnet also makes it possible to log data by means of Trend Log objects.

Trend Log objects are local objects in the device, which are created or deleted dynamically with the help of a BACnet client.

The Trend Log object can record a property from an internal or external BACnet object. The stored data are read by a BACnet Client.

To activate data logging for a data point, the properties window of the data point must first be opened. A "Trends" tab is available.

Use the "Change period" button to define the start and stop times for logging. The times can be disabled.

(39)

Parameter "Log interval" can be used to enter the logging interval. The default value for this interval is 1 minute. However, if COV (Change of Value) mode is selected, logging takes place when the COV increment value is violated.

Enable the "Stop when full" parameter to halt logging when the log list is full (if the "Max. number of data sets" is exceeded). If this parameter is disabled, the oldest entries are overwritten with the newest ones.

Notification of this Trend object within the object can be enabled and parameterised on the "Intrinsic Reporting" tab.

The "Threshold value for notification" parameter can be used to specify the number of entries until a notification is issued. The default value is 100.

Parameter "Alarm identification" defines whether the generated notification is of the "Alarm" or "Event" type (less important than an alarm). The default setting is EVENT.

(40)

10. Ventilation programming-respects

10.1 DDC-Plant Switch

HW-Switch (PA7 = Priority Array 7)

The HW-Switch becomes at the BV-module (DDC-Plant switch) over the entrance „EnPrioV1“.If the signal stands on "1", the Present Value assumes the condition, that is (normal case is on for "installation ON 1) pre-determined at the entrance PrioV1.

Alarm (PA5 = Priority Array 5)

By alarm, the installation should become switch off.

The alarm-signal becomes at the BV-module, connected over the entrance EnPrioV2 (PA5). The command is overcharged from the HW-Switch (PA7) by alarm-case.

The plant switch assumes the condition, which is (in the normal case value "0" for "installation OFF") pre-determined at the entrance PrioV2.

If the alarm came back into the normal condition, the entrance EnPrioV2 becomes again inactive. If both signals "Switch" and "alarm" get along on "0", PV assumes the condition from "RlqDef (in the normal case, value "0" for "installation OFF")"

(41)

10.2 The Dampers

The command (PA16 = Priority Array 16)

The command for the damper becomes from the program at the BO-module over the input "in" (Priority) 16).

Fire-alarm (PA2 = Priority Array 2)

By fire-alarm, the damper should be closed.

The alarm-signal becomes at the BO-module of the damper, and connected over the entrance

EnPrioV1 (PA2).The alarm signal with the higher priority (P2) overcharges all the control (P16) into the command.

The dampers assumes the condition, that is pre-determined at the entrance PrioV1, (in the normal case value "0" for "damper Close")

If the fire-alarm came back into the normal condition, the entrance EnPrioV1 becomes again inactive and the command of the control with (PA16) or others possibly active alarms with lower priority, becomes active.

(42)

10.3 The heating coil

10.3.1 The valve

Signal from the automatic control (PA16 = Priority Array 16)

The control of the valve becomes from the program at the AO-module over the input "in" (PA16).

Frost-alarm (PA5 = Priority Array 5)

By frost-alarm, the valve is opened.

The alarm-signal becomes at the AO-module of the valve, connected over the entrance EnPrioV2

(PA5). The alarm signal with the higher priority (P5) overcharges all the control (P16) into the command.

The valve assumes the condition, which is pre-determined at the entrance PrioV2, (in the normal case value "100" for "damper Open")

If the frost-alarm came back into the normal condition, the entrance EnPrioV2 becomes again inactive and the output value of the control with (PA16), becomes active.

(43)

10.3.2 The pump

The command (PA16 = Priority Array 16)

The command for the pump becomes from the program at the BO-module over the input "in" (Priority) 16).

Frost-alarm and pump alarm (PA5 = Priority Array 5)

By frost-alarm, the pump is switched on. By pump-alarm without (frost-alarm) the pump is switched off.

The alarm-signals frost and pump becomes at the BO-module of the pump, connected over the entrance EnPrioV2 (PA5). The alarm signal with the higher priority (P5) overcharges all the control (P16) into the command.

The pump assumes the condition, that is pre-determined at the entrance PrioV2, (1=ON, 0=OFF). The frost-alarm has a higher priority than the pump-alarm.

(44)

10.4 The cooling coil

10.4.1 The valve

Signal from the automatic control (PA16 = Priority Array 16)

The control of the valve becomes from the program at the AO-module over the input "in" (PA16).

10.4.2 The pump

The command (PA16 = Priority Array 16)

The command for the pump becomes from the program at the BO-module over the input "in" (Priority) 16).

Pump alarm (PA5 = Priority Array 5)

By pump-alarm the pump is switched off.

The alarm-signals frost and pump becomes at the BO-module of the pump, connected over the entrance EnPrioV2 (PA5). The alarm signal with the higher priority (P5) overcharges all the control (P16) into the command.

The pump assumes the condition, that is pre-determined at the entrance PrioV2, (In the normal case value "0" for "Off")

If the alarm-signal came back into the normal condition, the entrance EnPrioV2 becomes again inactive and the output value of the control with (PA16), becomes active.

(45)

10.5 The Fan

The command (PA16 = Priority Array 16)

The command for the fan becomes from the program at the BO-module over the input "in" (Priority) 16).

The dampers-alarm (PA5 = Priority Array 5)

By dampers-alarm the fan is switched off.

The dampers-alarm becomes at the BO-module of the fan, connected over the entrance EnPrioV2

(PA5). The alarm signal with the higher priority (PA5) overcharges all the control (PA16) into the command.

The fan assumes the condition, that is pre-determined at the entrance PrioV2, (In the normal case value "0" for "Off")

If the damper-alarm came back into the normal condition, the entrance EnPrioV2 becomes again inactive and the output value of the control with (PA16) becomes active.

Fire-alarm (PA2 = Priority Array 2)

By fire-alarm, the fan should be off.

The dampers-alarm becomes at the BO-module of the fan, connected over the entrance EnPrioV1

(PA2). The alarm signal with the higher priority (PA2) overcharges all the control (PA16) into the command.

The fan assumes the condition, that is pre-determined at the entrance PrioV1, (In the normal case value "0" for "Off")

If the fire-alarm came back into the normal condition, the entrance EnPrioV1 becomes again inactive and the output value of the control with (PA16) becomes active.

(46)

11. Heating group programming-respects

11.1 Plant switching

The plant switching is realized by the shift of the room temperature setpoint. An AV module is available as "Room temperatur setpoint"

For that module, a time program which controls the setpoint setting is defined. The write priority of the time program is set on 15 (See priority array table for local time programs).

Option 1:

In front of the AV module, it is possible to integrate an OPT_H module.

That module manages the energy optimization with shift of the time points of switching on and off of the plant.

At the same time, the module gives the right setpoint to the AV module for the temperature shift.

It's also possible to define a time program fort he OPT_H module. In that case, we recommend the using of that time program for the plant. The time program of the AV module can be deleted.

Option 2:

In option, it's also possible to connect a hardware switch directly on the PrioV1 inputs (manual switching with prio 7).

(47)

11.2 Alarm switching

By the following critical alarm (NC201), a default notification appears and the plant is switched off with prio 5:

• Default of the heating group pump (NC 201)

• Alarm from the temperature limiter (Floor heating) (NC 201)

For example, if an alarm occur from the temperature limiter ("Alarm" = 1), the pump is switched off ("PrioV2" of the BO is 0) and the control valve is closed ("PrioV2" of the AO is 0).

Control Valve Switching:

(48)

12. Workflow CASE Vision

12.1 With a CASE Builder project

• CASE Builder:

1. Create a plant in CB and synchronise picture with the plant 2. Select AS and do the allocation

3. Export CASE Builder data (AS) to CASE Engine

4. Do the needed modifications in CASE Engine project and make the program suitable for downloading

5. Export data back to CASE Builder 6. Import data into CASE Builder

All the necessary data are available only after editing in CASE Engine (e.g. the MFAs of the soft addresses)

7. Create navigation tree for moduWeb (CB > moduWeb view)

8. Add display elements to plant diagram (For most analogue values, the display elements have already been stored and equipped with corresponding names.) 9. Create moduWeb files (PNG and ExportToVisu)

10. Associate data points with graphical objects (data point allocation) 11. Check the data before export

12. Data export for moduWeb (XML)

• CASE Vision:

1. Start CASE Vision with the active CASE Engine project

2. Select CASE Builder “export to visualisation” file as project source 3. Select the image location level (Project Settings)

4. If needed modify the picture and edit the dynamised data points

5. Do the download from CASE Engine to the station (write picture and navigation tree / SVO to the AS)

CASE Engine is searching (for moduWeb data) first in the CASE Vision directory and afterwards in the CASE Builder directory

12.2 With a CASE Engine project without CASE Builder

• CASE Vision

1. Start CASE Vision with the active CASE Engine project

2. Select CASE Engine data as project source. Choose between the following tree types: CE tree, object type-sorted or self-defined BACnet object name

components (define 5 levels / components)

3. Select the suitable level as picture location (level 3) (Project Settings) 4. Select a PNG picture from your computer

5. If needed modify the picture and dynamised data points

6. Do the download from CASE Engine to the station (write picture and navigation tree / SVO to the AS)

(49)

13. BMS settings

13.1 Information about characters

In novaPro Open, object names are limited to 31 characters.

No characters with the German umlaut should be used in the engineering, because many BMS systems recognise only the ISO format at present.

(50)

(51)

(52)

(53)

(54)

(55)

EY-modulo 5 Engineering Guidelines

EY-modulo 5

Engineering Guidelines

Version 1.0 - E

Preface

Table of contents

1. BACnet Basics

1.1

What is BACnet?

1.2

History

1.3

Network technologies

1.4

BACnet Device

1.5

BACnet objects

1.6

BACnet services

2. Stations

2.1

Parameterisation

2.2

Project planning table

3. Priority-Array

3.1

Principle

3.2

Sauter Standard

3.3

Priority connections

3.4

Konfigurationsbeispielen

4. Intrinsic Reporting

4.1

Enable function

4.2

Sauter recommendations

4.3

State monitoring

4.4

Transmission of notifications

4.5

Collective alarm concept

4.6

Status flags

4.7

Alarm suppression

5. Setting the measurement values

5.1

General settings

5.2

Limit value monitoring

5.3

Reliability and communication error

5.4

Status Flags

5.5

Value transmission