Technical Stumbling Blocks: What Every …...Technical Stumbling Blocks: What Every Commissioning Agent Should Know About Open Protocol Systems Carl Lundstrom, P. E., CCP E M C Engineers,

Technical Stumbling Blocks: What Every Commissioning Agent Should Know

About Open Protocol Systems

Carl Lundstrom, P. E., CCPE M C Engineers, Inc.

www.emcengineers.com

2

Commissioning (Cx) Open-Protocol BAS

n Many building owners are requiring open-protocol data communication building automation systems (BAS)

n Integration of building controls between multiple vendors

n Integration of building controls into facility-wide enterprise-level system

n Technical issues occur with open-protocol multi-vendor installations that don’t occur with single-vendor systems

n Commissioning Providers must understand potential issues for system to meet the owner project requirements (OPR)

3

Controller to Controller, Same LAN

n PPC or ASC

R

PPC

ASC

ASC

R

PPC

ASC

Symbol Legend

Router

Program Controller

App Specific Controller

4

Communications Requirement

n Controller to controller, different LANs

R

PPC

PPC

R

PPC

PPC

Vendor X Vendor Y

5

Device to Server/Workstation

R

PPC

PPC

R

PPC

PPC

Vendor X Vendor Y

6

Operator to Device

R

PPC

PPC

R

PPC

PPC

Vendor X Vendor Y

7

Cx Issues

n Developing the OPRn Reviewing Drawings & Specsn Reviewing Submittalsn Installationsn Functional Testingn Trainingn Documentation

8

Open-Protocol Data Communication System used in Building Automation Systems

n Open-protocols– BACnet – Developed by ASHRAE– LonWorks® – Developed by Echelon

9

LonWorks® 101

10

What is LonWorks®?n Developed by Echelon Corporationn The technology encompasses

– LonTalk® protocol– “Neuron” chips– Communication media transceivers– Communication packet structures– Networking hardware (routers)– Network management software tools

n Strong “plug and play”n Strong industry standards and certification (LonMark®)n Developed for use by any control industry – lacking in

some areas for building automation type applications

11

Neuron Chipsn Neuron by Echelon

• Built by Cypress and Toshiba• Three basic models with varying on-board memory

n L-Chip by Loytec Gmb• The Lisa is based on NEC Electronic’s SoCLite+

architecture a system on chip (SoC) solution for– ANSI/EIA-709 (LonTalk)– ANSI/EIA-852 (LonTalk over IP)– BACnet networks– Developed under the name LISA.

12

Lon Standard Transceivers

n FTT–10A– Free Topology

Transceiver– Connects to a TP/FT–10

media– Data rate 78Kbs

n TP/XF–1250 – Twisted Pair/Extended

Frequency transceiver– Connects to the TP/XF–

1250 media– Data rate 1.25Mbs

n LPT–10 – Link Power Transceiver– Power supplied via the

LonWorks network – Connects to the TP/FT–10

media. LPT-10 and FTT-10 are compatible.

n TP/XF–78 – Older version of FTT–10.

Not compatible with FTT-10.

– Do not purchase by accident

13

Communication Packet Structure

Key types of packet structures:– Standard network variable type (SNVT)– User-defined network variable type

(UNVT)– Standard configuration property type

(SCPT)– User-defined configuration property type

(UCPT)

14

SNVTsn Standards for variable were developed by

LonMark associationn Three types of data format statement of

three types.– Simple (like SNVT_temp_p for temperature)– Structured (like SNVT_switch with two pieces of

data in one variable– Enumerated (like SNVT_occupancy; formats four

occupancy binary states in one analog number)n SNVTs define a common format, structure,

and resolution

15

Commissioning Issue: Network Variables

n Specs– Confirm submittals

require a data mapping matrix showing data moving to/from controller, and controller to server

– No proprietary network variables allowed (i.e., user defined)

– Controllers can utilize a large number of SNVTs (over 100) per controller

n Submittals– Review data mapping

matrix for all required data, and data types

– Review controller data sheets for maximum SNVT limits

– Review that contractor uses correct SNVT type for engineering units

n Testing– Verify data and SNVTs

by testing

16

SCPTsn SCPT: Standard Configuration

Property Type– A Name– Purpose or function

n Application configuration data– For example, duct diameter on a VAV

boxn Have an advantage in component

designs since the neuron allows more SCPTs than SNVTs.

17

Configuration Parameters n Examples of configuration parameters

– Operator adjusted set points• Temperature• Pressure• Lead lag

– Time settings within logic• Alarm delays• Sample rates for control loops• Execution delays

– Tuning parameters• Sample rate• Gain• Integral time constant

18

Configurationn Dynamic variables in a SCPT format written to EEPROM

from any HMIn Hard coded values within an application

– To change this type of parameter requires the use of the vendor unique application programming tool and an application download every time there is a change.

– Not very practical as the download process will interrupt the control of the connected system.

Commissioning: it will be important in the specificationsto define those parameters that must be adjustable without an application download!

19

Configurationn Commissioning CAUTION: Proprietary values

written to EEPROM from the vendors HMIn Example:

– Some major BAS vendors that use LonWorks can create a set point in a proprietary CPT format that can be easily adjustable from their HMI without an application download.

– This parameter can not be seen by the other vendor system in a multi-vendor environment.

20

Commissioning Issues:Configurations

n OPR –– what parameters should

be adjustable from OWS

n Specs –– Confirm that the specs

are clear the vendor must use SNVTs and SCPTs, not user-defined variables to create an open system – only exceptions is for specialty equipment where no SCPT exists

n Submittals– Check data matrix to

see type of SNVTs and SCPTs are being used

n Testing– Check the data types

being used– Check that configuration

parameters can be changed from HMI

21

A LonMark® Profilen Developed by the LonMark associationn It applies to a software object in a DDC device.n It defines the communication interface between

the software object and the LAN.– Mandatory network variables– Mandatory configuration properties– Optional network variables– Optional configuration properties– Format for each of the above

22

LonMark Profiles

n Example variable…

23

Commissioning Issue: LonMark Profiles

n Specs– Confirm specs

require controllers have all “required”network inputs/outputs to achieve functionality you want –

– Being LonMark certified is NOT ENOUGH

n Submittals– Review submittals to

confirm controllers have the correct network inputs/outputs for functionality

n Testing– Verify functionality

24

Commissioning Issue LonMark Profiles

n Example of one nvi - VAV Manual Override Input– network input SNVT_hvac_overid nviManOverride;

• This input network variable is used for commanding the controller into a manual mode (most importantly when balancing the box). It has the fields: state, percent and flow.

• For details refer to The SNVT Master List and Programmer’s Guide.– HVO_OFF: normal control.– HVO_POSITION: set damper to the value in the percent field.– HVO_FLOW_VALUE: control flow to value in the flow field.– HVO_FLOW_PERCENT: control flow to value calculated from the value in percent

field and min/max flow limits.– HVO_OPEN: Fully open the damper.– HVO_CLOSE: Close the damper.– HVO_MINIMUM: Control flow to the minimum value

• (nciMinFlow).– HVO_MAXIMUM: Control flow to the maximum value

• (nciMaxFlow).– HVO_NULL: INVALID (use default).

• percent: 0 to 100%• flow: 0 to 65,534 liters/sec• The default value is HVO_OFF. This value will be adopted at power-up or if an

invalid value is received.– Commissioning issue - some VAV controllers don’t provide this nvi

25

Software Tasks

n Communication from the server/workstation to the devices.

n Addressingn Bindingn Configurationn Editing time schedulesn Retrieving trend logsn Sending and receiving alarm messagesn Manual override of physical pointsn Creating and downloading applications to

PPCs

26

Addressingn In setting up a Lon-based system, a vendor

must have a software tool that will assign an address to a hardware device

– Domain number– Subnet number– Node number

n This software tool will write the addressing information into the memory on the device and record the information into a database on the PC.

27

Addressingn The task of writing addressing

information to a Lon device is well defined in the ANSI LON standard which makes it easy for vendors to create their own software tools for device addressing.

n When a vendor uses his vendor-unique software tool to write addressing information to a device, the addressing information is also stored in a vendor-unique database on the vendor’s PC.

28

Addressingn If one vendor addresses the controllers,

then another vendor changes the address, the first vendor PC system will no longer recognize the controllers, their configurations, etc.

n This will be a problem if the first vendor needs to download a program or configuration, etc.

29

Example System

PPC ASC

Field Bus

ASC

TAC

R

SLC

TAC HMIBuilding 1

JACE

Tridium HMIEnterprise System

PPC ASC

Field Bus

ASC

JCI

SLC

JACE NAE

JCI HMIBuilding 2

IP network

30

Commissioning Issues: Addressing

n OPR– Is there an existing

node addressing software platform to use?

n Design/Spec– Confirm design

explains how controllers will be addressed, especially if there is an existing system

n Construction– Confirm how

addressing is being done if multi-vendor system

– Two different vendor addressing can cause “unreliable”networking

– Test local connection of engineering computer. For example, laptop for VAV terminal setup

31

BindingsNetwork Communication

n Communication pathways in LonWorks are called bindings.

n Bindings are used to establish which components communicate which each other

– All communication is peer-to-peer– Bindings manage communication in an

effective and efficient manner using several approaches:

• Communication groups• Binding services

32

Bindingn Binding is a term used to describe the

process of informing a device:– When to send information over the network to

another device• Send on delta• Minimum send time• Maximum send time

– The address of the receiving device• Subnet and node number• Bound group address

– Communication service type• Unacknowledged• Unacknowledged, repeated• Acknowledged• Or polling

33

Binding Communication ServicesUpdate vs. Polled?

n Update -Acknowledged– Send until the receiver confirms delivery

n Update - Unacknowledged, repeated– Send three times, and stop

• “Send and pray”– Actually very reliable

n Update - Unacknowledged– Send once, and stop

• “Send and pray harder”n Polling

– Polled variables wait to be queried for data, and then respond when queried.

– Typically, polled variables operate on a continuous update methodology

34

Commissioning Issues: Bindings

n OPR– Are there any special

requirements for data that needs to be “bound” from this project to another existing systems or buildings (example: central plant)

n Specs– Confirm drawings/specs

are clear on OPR expectations

– Are specs clear on binding service expectations

n Testing– Confirm bindings thru

testing– Make sure multiple nvi’s

are not bound to the same value

35

Editing Time Schedules

n LON-based systems do not have an open system concept for editing time schedules excluding very custom programmed solutions.

n Part of the original vision for LON-based systems was the use of generic time scheduling devices that could be purchased by anyone and used in any system.

n Implementation of this concept has not occurred.

36

Editing Time Schedulesn As a result of current capabilities, the

HMI that is responsible for managing the time schedules within a system must have a corresponding (same vendor) time scheduler device in each system.

n This is a weakness in the LON-based systems that is currently overcome by the use of specific hardware.

37

Example System

PPC ASCASC

TAC

R

SLC

TAC HMIBuilding 1

JACE


PPC ASCASC

JCI

SLC

JACE NAE

JCI HMIBuilding 2

38

Commissioning Issue:Time Schedules

n OPR– Determine the

owner’s requirement for managing time schedules

n Design/Specs– Confirm vendor

specific equipment (sole source) that may be required for time schedules

n Submittal– Confirm how

contractor is dealing with hardware/ software for time schedules

n Testing– Confirm time

schedules are handled as required from HMI between multi-vendor systems

39


n Caution – if the control sequence reads “provide time schedule start/stop of the fan” – this maybe the only control you get of the motor.

n Make sure the control sequence also includes “operator shall also be able to manually start/stop the fan from OWS and override the time schedule control”.

40

Retrieving Trend Logsn The LON-based systems do not have an

open system concept for retrieving trend logs from a device to the PC.

n The original vision for LON-based systems included the use of generic trend logging devices that could be purchased by anyone and used in any system.


41

Retrieving Trend Logs

n As a result of current capabilities, the HMI that is responsible for storing and presenting the trend log data within a system must have a corresponding (same vendor) trend logging device in each system.


42

Details-Trend Logs-PPCs

Dynamic Data

AI

TAC - PPC

JACE

TL

TL

Trend Log Data

Trend Log Data

TAC HMI

TRIDIUM HMI

43

Commissioning Issue:Trending


owner’s requirement for managing trending

n Design/Specs– Confirm vendor

specific equipment (sole source) that may be required for trending


contractor is dealing with hardware/software for trending

n Testing– Confirm trends are

handled as required from HMI between multi-vendor systems

44

Alarm Handling

n The LON-based systems do not have an open system concept for generating alarm messages from a device to the PC.

n The original vision for LON-based systems included the use of generic alarm handling devices that could be purchased by anyone and used in any system.


45

Alarm Handling

n As a result of current capabilities, the HMI that is responsible for receiving and presenting alarms within a system must have a corresponding (same vendor) alarm generating device in each system.


46

Commissioning Issue:Alarm Handling

n OPR– Confirm how owner

wants alarms handledn Design/Specs

– Confirm vendor specific equipment (sole source) that may be required for alarm handling

– Make sure specs reflect OPR for alarm handling


contractor is dealing with hardware/ software for alarm handling

n Testing– Confirm alarms are

handled as required from HMI between multi-vendor systems

47

Point Overrides

n From the HMI, the operators need the ability to override physical points.

– Interrupt control logic and mandate a state or value for a physical output point

• Fan Start Stop DO point• Damper Position AO point

48

Point Overrides

n From the HMI, the operators need the ability to override physical points.

– Interrupt the measurement of an input variable and force the logic to used a specified value or state.

• Force the outside air temperature to a value of 70ºF to test the high limit on the economizer.

• Force the fan status input point to a state of ON.

49

Point Overrides

n In application specific devices, the capability to override either input or output points must be built into the application.

n You must read the documentation on the device to determine if this capability was included.

50

Point Overrides

n “LonMark®” controllers only require a few “required” data connections, that don’t guarantee “point override”capability.

51

Point Overrides

n The provision of a capability to override points in a PPC can be accomplished in one of three ways:

– Using a proprietary communication between the HMI and the point.

– Using an open protocol “priority” scheme within the application program.

– Using an open protocol “switching”scheme within the application program.

52

Point Overridesn If a vendor uses a proprietary communication

scheme between his HMI and one of his PPCs for affecting a point override, when you add the second HMI to the system, an operator at the second HMI will not be able to execute a point override.

n This concept would have to be “disallowed” in the specification for the building level controls in the multi-vendor system architecture.

n Because it takes a lot of variables passed back and forth to create point overrides, you can use up the maximum SNVTs in a controller (noted on slide 15)

53

Details-Override Points

JACE

TAC-PPC

1

0

SR

P

C

Switch

MM

MV

Logic

DO

Manual Mode

Manual ValueTridium HMI

TAC HMI

54

Commissioning Issues:Point Override

n Specs –– Require that all

programmable controllers have command override of inputs and outputs

– Require set points commanded from OWS

– Require submittals come with detailed data matrix of mapping of information

– Require only SNVTs and SCPTs for overrides (only exception is where a data type doesn’t exist – special equipment)

– Require ASC have overrides from OWS

n Submittals– Review submittals-matrix

for correct mapping– Review ASC for override

capabilityn Testing

– Confirm controller overrides are programmed correctly

– Confirm OWS graphics have correct overrides incorporated

– Confirm use of SNVTs and SCPTs

55

Application Programmingn There is no such thing as a generic

open- based application programming tool for creating and downloading applications to programmable devices.

n In the early days, there were visions of all vendors using Neuron C and writing applications to the application memory in the controllers. This would have created a universal programming language.

56

Applications Programmingn You must have the service PC

functionality in order to modify an application in a PPC device.

n This is not to say that the HMI PC and the Service PC can not be one and the same, but software will be unique.

n The downloading process also requires an “approved” path.

– A TAC service PC can not download an application to a TAC PPC through a Tridium JACE. A path around the JACE must be provided.

57

Example System

PPC ASC

LAN

ASC

TAC

R

SLC

TAC HMIBuilding 1

JACE


PPC ASC

LAN

ASC

JCI

SLC

JACE NAE

JCI HMIBuilding 2

58

Commissioning Issues:Application Programming

n OPR – are there any owner requirements for application software?

n Specs – Do the specs include

application programming for new controllers?

– What computer is provided for application program

– Confirm adequate training for application programming

n Design/spec– Does design include

networking devices to allow programming to controllers

n Installation– Did installation

include method for download of program

– Software received– Training received

59

BACnet 101

60

BACnet Basics

n BACnet stands for “Building Automation and Control Network”

n BACnet is an open data communications protocol developed by ASHRAE --- it’s a book, is not hardware, is not software (as compare to LonWorks from Echelon)

n BACnet is an ANSI/ASHRAE standard that specifies a common communication protocol that allows building systems to communicate with each other using a common language

n Was developed around building automation requirements

61

BACnet Basicsn BACnet protocol key terms are:

– Device = Controller or PC

– Network Type = Physical communication method (i.e., Ethernet)

– Object = Information point (i.e., temperature reading, flow set point or equipment schedule)

– Service = Request for information or fulfill change to information (read a temperature, change a flow set-point, edit an equipment schedule, send an alarm)

62

BACnet Basicsn BACnet Does Not Solve All Problems

– BACnet is not “plug-and-play”– Doesn’t address configuration, programming, or user

interface– Doesn’t address standard “transceivers”– BACnet does not address user security (open means

open)– Increased planning and engineering

63

BACnet Basics

n A BACnet device is a microprocessor-based unit that is designed to understand and use the BACnet protocol

n A BACnet device is typically a controller, gateway, or a user interface (workstation)

n A BACnet device contains a collection of information about the device called objects and properties

Devices

64

BACnet Basics

n A BACnet device will contain a deviceobject that defines certain device information, including the device object identifier or instance number

n A BACnet device object instance number must be unique across the entire BACnet network

Devices

nCommissioning issue – OPR – does the owner have a site-wide “device object instance number”scheme across the site?

65

BACnet Basics

n BACnet Standardized Device Profile (Annex L)Devices

B-OWS Operator WorkStationB-BC Building Controller: free programmable controller,

providing all BIBBs in profileB-AAC Advanced Application Controller: free

programmable controller, providing all BIBBs in profileB-ASC Application Specific Controller: fixed programmed,

configurable controllerB-SA Smart Actuator: BACnet compatible actuatorB-SS Smart Sensor: BACnet compatible sensor

66

BACnet Basics

n A BACnet object is a collection of information within a device

n BACnet passes “objects” which contain many properties, versus LonWorks passes variables and configuration parameters with limited information per variable.

n Objects represent either physical or virtual information, such as:

– Analog or digital inputs and outputs– Control algorithms– Specific applications– Calculations

Objects

67

BACnet Basics

n The BACnet protocol defines a collection of standard object types (127 possible)

Objects

Binary Input Multi-state Input File

Binary Output Multi-state Output Program

Binary Value Schedule

LoopAnalog Input

Calendar GroupAnalog Output

Notification Class Event EnrollmentAnalog Value

Command DeviceAveraging

Multi-state Value

Trend Log

LifeSafetyZone LifeSafetyPoint

68

BACnet Basics

n Some standard object types and the functionality that they are intended to represent:

Objects

(0) Analog Input Sensor input

(1) Analog Output Control output

(2) Analog Value Set-point or other analog control system parameter

(3) Binary Input Switch input

(4) Binary Output Relay output

(5) Binary Value Binary (digital) control system parameter

(6) Calendar Defines a list of dates, such as holidays or special events, for scheduling

(7) Command Writes multiple values to multiple objects in multiple devices to accomplish a specific purpose, such as day-mode to night-mode, or emergency-mode

(8) Device Properties tell what objects and services the device supports, and other device specific information such as vendor, firmware revision, etc.

69

BACNet BasicsObjects

(9) Event Enrollment Describes an event that might be an error condition (e.g., “Input out of range”) or an alarm that other devices know about. It can directly tell one device or use a Notification Class object to tell multiple devices.

(10) File Allows read and write access to data files supported by the device.

(11) Group Provides access to multiple properties of multiple objects in a read single operation.

(12) Loop Provides standardized access to a “control loop”.

(13) Multi-State Input Represents the status of a multiple-state process, such as a refrigerator’s On, Off, and Defrost cycles.

(14) Multi-State Output Represents the desired state of a multiple-state process (such as It’s Time to Cool, It’s Cold Enough and It’s Time to Defrost.

(15) Notification Class Contains a list of devices to be informed if an Event Enrollmentobject determines that a warning or alarm message needs to be sent.

70

BACnet Basics

n A BACnet object contains a collection of properties, based on the function and purpose of the object

n Each property contains two pieces of information:1) A property Name or Identifier2) The property’s Value

Properties

71

BACNet Basics

n BACNet objects have required and optional properties

Objects

Object_Name SPACE TEMPObject_Type ANALOG INPUTPresent_Value 72.3Status_Flags Normal,InServiceHigh_Limit 78.0Low_Limit 68.0

Required

Optional

72

BACNet BasicsProperties

Required & OptionalProperties

BACNet Analog Input Object

73

BACNet Basicsn Properties may be defined as read-only or

read/writen A property’s purpose is to allow other BACNet devices

to read information about the object containing the property, and potentially command a different value to the property

n Depending on the type of object that the property resides in, particular object properties may be optional or required for implementation per the BACNet standard

n Commissioning Caution: – Objects may also contain properties that are non-

standard or proprietary.– Objects may have properties that are locked from

read/write

Properties

74

Commissioning Issues: Read/Write to “Properties”

n Specs – Do the drawings/

specs describe what “properties”must be read/ written across the network

n Submittals– Confirm BACnet

device has correct properties, and with correct read/write capabilities

n Installation– Test to confirm

read/write is incorporated

75

BACnet Basics

n In order for actions to be taken on objects and properties, such as read or write, services are defined within BACnet

n BACnet services are actions that a BACnet device takes to read or write to another BACnet device

n Services act like the action verb in the BACnet protocol

– Services ask for an action to take place, like a read temperature request or a write to set-point request

Services

76

BACnet Basics

n Services are grouped into 5 categories of functionality:

– Object Access• Read, write, create, delete

– Device Management• Discover, time synchronization, initialize, backup and

restore database– Alarm & Event

• Alarms and changes of state– File Transfer

• Trend data, program transfer– Virtual Terminal

• Human machine interface via prompts and menus

Services

77

Interoperability Areas

n Using the concept of devices, objects, properties, and services, BACnet provides functional capabilities referred to as “Interoperability Areas”

– Data Sharing– Trending– Scheduling– Alarm & Event Management– Device Management– Network Management

78

Data Sharingn In Data Sharing, a client device (A)

requests a server device (B) for data and may also send commands to the server

n Typical Data Sharing requests that a client will make to a server are “read property”and “write property”

– Read/write property– Read/write multiple properties– Read property conditional– COV (Change of value)– Unsolicited COV

79

Data Sharing

n A “write property” request will allow a client device to write to the property of a server device

n In situations where there is a command priority array, a “write property” request will be a command accompanied by a command priority

n Commands are sent in one of 16 command priorities defined in the BACnet standard

n When a command is sent, it takes effect only if it is the highest command priority (lowest number) currently in the command priority array for that property.

80

Data Sharing Command PriorityPriority BACNet Priority

1 Manual Life-Safety

2 Automatic Life-Safety

3 Available

4 Available

5 Critical Equipment Control

6 Minimum On/Off

7 Available

8 Manual Operator

9 Available

10 Available

11 Available

12 Available

13 Available

14 Available

15 Available

16 Available (Default)

81

Data Sharing – Command Priority

50%

50%12

default

3456789

10111213141516

Priority_Array Present_Value

50%

80%

80%12

default

3456789

10111213141516


50%

65%

80%

65%12

default

3456789

10111213141516


Initially... After Write to Present_Value at priority 10

After Write to Present_Value at priority 7

82

Commissioning Issues:Command Priority

n OPR – are there any owner requirements for command priority

n Specs – Do the drawings/

specs describe what has command priority

– HMI priority– Engineering service

tool priority– Fire alarm system

priority

n Submittals– Confirm command

priorities are correct in submittals

n Installation– Test to confirm

priorities are programmed correctly

83

Scheduling

n Scheduling allows BACnet devices to establish and edit schedules in BACnet devices so that control can be coordinated based on dates and time

n Not all controllers are setup to be handle BACnet schedule – be careful!

84



owner’s requirement for managing time schedules

n Design/Specs– Confirm specs indicate

how scheduling handled from HMI to controllers; and devices have correct BACNet schedule objects

– Confirm controller can handle “schedule”


contractor is dealing with hardware/ software for time schedules

n Testing– Confirm time

schedules are handled as required from HMI between multi-vendor systems

85

Trending

n Trending allows BACnet devices to enable trend collection and request trend data from other BACnet devices

n Automated trend retrievaln Can controller handle BACnet trends?

86

Alarm & Event Managementn Alarm & Event Management defines

the exchange of data based on pre-defined alarm limits or event triggers

n The event or alarm may require human intervention and acknowledgement

n Alarm & Events may also be logged and summaries generated

87

BACnet Interoperability Building Blocks (BIBBs)n BIBBs are a collection of one or more

BACnet services that function to define the interoperable capabilities of a BACnet device

88

BACnet Interoperability Building Blocks (BIBBs)n BIBBs provide a logical method for

disclosure of BACnet device support for all of the BACnet interoperability areas:

1. Data Sharing

2. Scheduling

3. Trending

4. Alarm & Event Management

5. Device Management

6. Network Management

89

Example BIBBs n Say that one device has a temperature sensor whose

temperature is accessible as a property of a BACnet object.

n Another device would like to find out this temperature.n The device that has the sensor we'll call the "server."

TemperatureSensor

90

Example BIBBs n The server device must be able to receive a

ReadProperty service request and execute it and return a result.

– The BIBB for this kind of capability is called "DS-RP-B"

• DS meaning Data Sharing• RP meaning ReadProperty• B meaning the server device

DS-RP-B

91

Example BIBBsn The device that wants to know the temperature we'll

call the "client.“n The client device must be able to initiate the

ReadProperty service request and accept the response when it arrives.

92

Example BIBBs

n The BIBB for this capability is called "DS-RP-A“– DS meaning Data Sharing– RP meaning ReadProperty– A meaning the client or asking device

DS-RP-A

93

Example BIBBsn So to have an interaction like this, two BIBBs are

defined, – one for the asking– one for the answering

n Obviously, other kinds of interoperations are possible and desirable

DS-RP-A(Asking)

DS-RP-B(Answering)

94

Commissioning Issue:Specifications

Review specs to confirm the following are clear:– Data network connection/type/speed– BACnet Testing Lab (BTL) certified or BTL compliant– Required PROTOCOL IMPLEMENTATION CONFORMANCE (PIC)

Statement • What minimum BIBBs should be specified

– Binding map matrix– Submit the document that describes the sequence of control for the

device with BACnet interfaces between multi-vendor systems– Include command priorities– Which HMI will receive alarms, trends– Which HMI will coordinate scheduling

95

Example PIC statements

96

BACnet/IP - BBMDn BACnet/IP devices scattered around an IP

internetwork communicate directly with each other when reading data values, transferring files, or other direct device-to-device communications.

n "BACnet/IP Broadcast Management Device" (BBMD) is used to manage IP communications from one subnet to another.

n The BBMD keeps a table, called a "Broadcast Distribution Table," which lists all the BBMDs, including itself, in the virtual network. This table, identical in all the BBMDs of a virtual network, also tells which broadcast method, one-hop or two-hop, is to be used in each destination subnet.

n The BBMD does not need to be a physically distinct device. It can be integrated into a device that performs other operations, such as a building controller

97

BBMD

n Commissioning Caution:– A vendor can create a

BBMD that will receive objects, but will not send objects, thus limiting the “open system”

– Other BACnet vendors on a campus intranet would not have access to data

– Can only be validated by site testing

98

Commissioning Issue:Plug-Fest

n If you have two specific vendors you wish to work with, you will need to verify their documented compliance and most likely verify by product demonstrations.

n Specs– Review and recommend specs

require plug-fest between all vendors

– A simple table top demonstration of the demos would be an excellent test.

n Submittals– Submit hardware/

software to be used in plug-fest

– Review BIBBsn Testing

– Perform plug-fest before equipment installed

99

Commissioning Issues:Construction

n Installation inspection - testing– Duplicate BACnet network numbers– Duplicate Device Instance numbers– COV parameters to small– Limited bandwidth of MSTP networks– Field bus communication rates must be equal– HMI mapping for points– HMI for alarms, trends, scheduling

100

Commissioning Issues:Training and Documentation

n Review specs to make sure adequate training on networking and software is provided

n Review specs for adequate final documentation on data networking mapping between vendors

n Coordinate training for owner’s representative who will deal with networking and software issues

n Review final documentation on data networking

BACnet Updates - XML

n XML Addendum Approved for Publication! (1/10) Orlando, FL. Arguably one of the most significant addenda in some time, Addendum 135-2008t was approved for publication at the ASHRAE Winter Meeting in Orlando. The addendum specifies a standard way of representing data in XML that will give BACnet new capabilities for communications between a wide range of applications. The eXtensible Markup Language (XML) is a popular technology in the data processing and communications worlds due to its capability to model complex data and its flexibility to be transformed and extended.

101

102

Final Q&A

103

Web Links– BACNet – Standard 135-2004

• www.ashrae.org• www.bacnet.org• http://www.bacnetinternational.org/btl/

– LonWorks• www.Echelon.com• www.lonmark.org• http://www.lonmarkamericas.org/

– Building Commissioning Association• www.bcxa.org

104

Contact Info

Carl Lundstrom, P. E., CCPE M C Engineers, Inc.4550 Northpoint Pkwy, Suite 300Alpharetta, GA [email protected]

Documents

Technical Stumbling Blocks: What Every …...Technical Stumbling Blocks: What Every Commissioning Agent Should Know About Open Protocol Systems Carl Lundstrom, P. E., CCP E M C Engineers,