T2S6 - Advanced BACnet Spec Writing

TRACK 2, SESSION 6
Advanced Spec Writing with BACnet

Integrating BACnet-based systems together
Presented by: Grant Wichenko, P. Eng.

Appin Associates
www.appin.com
204-9251450
Advanced BACnet Spec Writing

Advanced Spec Writing:
Topics to be covered
 Specifying controls has always a “pain” for consultants.
 Controls is NOT a “commodity” business.
 The Contractor’s Guide to Change Orders lays out how to get
Change Orders with poor specs.
 Specifying BACnet to avoid Change Orders.
 Integration issues: Implementing BACnet-based systems on multi-
building sites.
 Specifying a chiller correctly.
 Commissioning the systems.
 CSI MasterFormat means a Controls spec rewrite.
 Final Thoughts on Specifying with BACnet.

Specifying Controls a “Pain” for Consultants
 Controls is 5% of a job and 70% of the grief.
 What did you really buy and when do you determine what you have
bought?
 When is the job done so you feel comfortable in paying out the
holdback or retention?
 Control systems are like computers…except they have to work for

up to 30 years…not until next Thursday when the new Service Pack
is released!!!

Specifying Controls was poorly done even
before BACnet
 Historical approaches to DDC specs…Sequence of Ops, flat spec.
 No special ASHRAE classes on specifying pumps.
 Consultant knowledge on controls is limited….Now with GPC 13 or

CtrlSpecBuilder…no excuses for poor quality specs.

Controls is NOT a “commodity” business:
Don’t specify it that way!
 Features vary widely…concept of EQUALS makes no sense.
 BACnet implementation varies by vendor.

 Native vs non-native product.
 Web access to features varies (e.g., programming).
 Giving EQUALS in a Specification implies that DDC is a commodity

business…not the case.
 The spec and the bidding process should foster the development of
a long term, positive relationship between the Vendor and the
Owner….now it can be a competitive one with BACnet!!

Contractor’s Guide To Change Orders
By Andrew M. Civitello, Jr.
 Contractor’s Guide To Change Orders is designed to give you

valuable guidance and working tools for increasing profits.
 Everything you need for lean, advantageous contract interpretation is in

this single-volume workbook.
 You will be able to uncover all the “hidden” cost items for which you are
entitled to receive compensation.
 What the architect/engineer would have previously “clarified,” for
example, the owner will now process and pay for as a change order.
 Change Orders are due to bad specs…not the Contractor’s fault

Prospecting for Change Orders:
Controls Specification
 Design Intent vs What is actually Included in the Specification…not
the Contractor’s fault if the spec is defective.
 Division 15 vs Division 16 responsibility on power and interlocks.
 Spec simple things like insulation standoffs for controls devices.
 Points list present or just a Sequence of Operations.
 Controls requirements in the equipment spec for devices to be
controlled by controls (chillers, humidifiers, VSDs).
 Who installs what…Who wires what?...Do you follow Bid Depository
rules or other rules?
 My personal favorite…..“As indicated/shall be capable of ”

Specifying BACnet to avoid Change Orders:
Introduction
 Saying BACnet Compliant in the Spec is not enough.
 You do not need to be a BACnet expert but you must specify:
 Need for schedule, alarm, trends using the BACnet.

Interoperability
 Building Blocks (BIBBs).
 Where is this information to be sent.
 Gateway requirements to other proprietary or legacy systems.
 Use ASHRAE Guideline 13 Spec. It is a good starting point to help

you specify BACnet and non-BACnet items.

Learn the language of BACnet
 Ask for a PICS (Updated version). Learn to read it…You
need to learn the language so you can be precise with your
requirements….Controls must be as precise as Medicine.
 BACnet interoperability is the intersecting set of a Venn

diagram….A and B sides must be present. Look at what
is/is not done by BACnet (trending alarming, scheduling) if
a multi-vendor site.
 You must be comfortable with BACnet terminology to do

your job – alarms vs events, OFF-NORMAL, RecipientList,
binary input vs digital input, object vs point.
 Ask to see any proprietary objects and services… Trade

secret issues…yes… but there could be interop problems
with proprietary objects and services.

Spec Organization
 BMA/BTL participation mandatory condition of bidding the
job…Like a UL listing.
 Give definitions for network visibility, native BACnet

devices, gateways, etc.
 Put BACnet spec sections in one place. This simplifies

making changes.
 Include the object list in the Specification at a

minimum….YOU pick the points.
 Approve Facility/System/Point (F.S.P.) naming convention

via SD. Give points for wildcarding support.

Dealing with Equals
 Concept of equals a poor one and never has worked with
controls…there are better solutions.
 Set minimum mandatory requirements to avoid purchasing

problems…DS-RP is a minimum mandatory requirement
whereas trending is a scored item….more on “best value”
procurement later.
 Categorize vendor’s hardware. BACnet has defined device

profiles (B-BC).
 Devices like RTUs, VSDs, Humidifiers, Chillers have on-

board controls. Networked connections will replace hard
wiring of these devices. Include BACnet language in the
Device specs.

Specifying Services
 ReadPropertyConditional is a powerful BACnet service.
Encourage suppliers to support it.
 Ask for object creation/deletion services. Some vendors

provide pre-created objects.
 Set number of entries in the Calendar and Schedule

objects…need a next day transition for Optimum Start.
 Intrinsic alarming vs Event Enrolment support for alarms.

Specifying services
 Allow for pager dialouts (local matter). Report dialout using
BACnet (emails to a cell phone).
 Allow for additional entries in the RecipientList for future

notifications (network printer).
 Ask support for the Out_of_Service property for fault

reporting.
 Give options in the BACnet section. Consider Alternates

for compliance…COV vs RPM as a fallback.
 Set command priorities. Leave some free. Which vendor

supports what command priorities?

Getting what you paid for
 Provide a network throughput test in case you get into
trouble.
 Allow for hardware and software updates in the Base Bid

during the warranty and the extended warranty period.
 Allow for time on site to deal with interop issues, in each

contract (alarms vs event transmission, choking on some
characters, truncating character names ..that is what the
interop demo will help identify).
 Deal with allocating devices instances…no duplicate ids

allowed in BACnet.
 Allow for a sniffer if necessary. VTS helpful in finding

interop problems. Like reading sheet music.

Trending
 Review the device profiles to type of devices you want on
the job (e.g., trending at the panels or not).
 Support the audit trail for creation/deletion of trendlog

records.
 Define what is to be logged and how many samples

(BufferSize) needed.
 Support for trending and archived data.
 Define the amount of globally shared data needed (OAT).

Integrating systems together
with BACnet
 DDC technology is constantly improving…a moving target

for a specifier/designer. This means constant spec
updates.
 Buildings are always being built, renovated or demolished

on campus. The integration process must respond to this.

with BACnet
 Network security a concern…IT people must be involved in the

process at the outset or outside access will not be allowed.
 Good fences make good neighbors…Create a VLAN of DDC

systems to segment traffic and to improve security of the network
as a whole, or provide a physically separated LAN/WAN.
 There may be an Energy Performance Contract on the campus

that requires the ongoing installation of DDC systems on a sole
source basis.
 There are usually existing proprietary systems on campus that

must be integrated into the internetwork (need for a gateway).

with BACnet
 Contracts for each must define clear lines of

responsibility…Supervisory control model available from
some vendors is problematical and is old technology. The
peer-to-peer model to establish contractor responsibility is
preferable.
 Different consultants have their own way of doing a job.

Using different specs means different features are being
implemented in each building.

with BACnet
 There are rules for public sector client Bids that are
imposed by the Purchasing department. Sole source or
owner negotiated deals are frowned upon. Purchasing
wants a public, competitive bidding process….this means
more systems on campus or on base.
 This conflicts with maintenance who want fewer systems

on campus. More systems mean more headaches for
maintenance (spare parts, training, players, another
computer on the desk).

with BACnet
 Integration must provide campus-wide alarming, scheduling,
trending and utility meter collection.
 The technology now allows for integrating HVAC, fire, security

and other systems together .
 Vendors who are competitors must co-operate for the success

of the project. This has not been a problem to date.
 We question the need for another integrator to undertake or co-

ordinate installations by other DDC system vendors. Just
specify trade co-ordination properly among the vendors.

with BACnet
 We ask for a four year warranty/maintenance contract as

part of the Bid price. Much better pricing a Bid time.
 Plan for a migration to XML:
Meter data can be collected from a BACnet panel and

converted to XML for generating bills or for real time
pricing.
Alarms can be used to generate Work Orders or
eventually order parts.

with BACnet: SUMMARY
 BACnet is the easy part.
 Implementing the technology is the easy part if you have a

good vendor selection method and a good spec that clearly
lays out responsibilities to all parties.
 The hard part is dealing the numerous consultants, bad

specs, existing proprietary/legacy systems, Purchasing
department requirements, IT’s security concerns, etc. etc.
etc.,
 …these other parties must be brought on board to make

integration work successfully.

Specifying the BACnet Internetwork
 Make it clear who provides internet access (e.g., who
provides network drops from comms closet).
 Allow for a minimum number of concurrent users and the

number of software objects, as part of the software site
license requirements in the Base Bid.
 Set functionality via the web (changing schedules,

start/stop equipment, programming).

Specifying the BACnet Internetwork
 Support for hypertext links on a graphic.
 Use Vendor web hosting for small jobs.
 Decide where web clients are located...Use cheap

computers with IE6 in boiler rooms for local access…
Expect resistance from IT over patch management.
 Look at future support for BACnet/WS and XML from each

vendor.
 Device instances allocations must unique on the BACnet

Internetwork.

LON/Proprietary Protocol Integration
 Decide if LON/BACnet/proprietary controllers are to be

used at the device level (VAVs, heat pumps, VSDs). This
may constrain future expansion in the building.
 Review profile (e.g., SCC profile) and what optional SNVTs

are to be supported.
 Select a gateway that can translate between LON and

BACnet. Use proven gateways. Are all SNVTs
mapped….are the mappings done automatically or
manually.

LON/Proprietary Protocol Integration
 Decide who wires the LonTalk LAN if LON HVAC, lighting
and security involved with BACnet.
 Decide where LON and ModBus are to be used….My

definition of a gateway..3rd party or not.
 Carefully specify gateway solutions for integrations to

proprietary or legacy systems to BACnet.
 Non-native BACnet field devices reduces flexibility for

expansion.

Front End/Graphics Design Issues
for the Internetwork
 Use one vendor to re-generate the graphics for the other
vendors…Sole sourcing…competitive advantage….
exception is Owner’s who build their own graphics on one
Front End
 Use a product like Cimetrics BACnet Explorer if there is no

vendor support for a Windows Explorer two-pane view.
 Set a graphics standard and point naming conventions.
 Use a 3rd party system to be the Master OWS.
 Use the different systems for different uses. We are going

to use one vendor for generating table data and archiving
trends and another vendor’s system because graphic re-
creation is not required.

Set a Graphics Standard for all Vendors
Both graphics look and feel the same to the user.

A single Front End is not necessary.

A Successful Multi-Vendor Strategy
 Host a “plugfest” of interested vendors to demonstrate BACnet
interoperability and vendor co-operation in setting up the internetwork.
 Select up to 3 preferred vendors for a time period to bid jobs. Minimize

number of systems on campus or on base while still having a competitive
Bidding process.
 Set a 3 year period for the selection of approved vendors. We allow for 2
one year renewals. The sunset clause is needed to satisfy Purchasing
requirements

A Successful Multi-Vendor Strategy
 Award contract via a RFP/points scoring approach. Best value
rather than low price.
….car analogy.
 Resolve all thorny contract issues before award. The Pre-

Nuptial Agreement.
 Approve programming, object list, graphics as a Shop Drawing.
 Commissioning process must be fair and transparent to all

parties.

Bidding Options
 Open bid with award to lowest qualified bidder.

 Sole source/owner negotiated.
 Base Bid with alternate vendors.
 Two envelope system (RFP …. (it is like choosing between various

models of cars)…we use a split between price and technical score.
Best Value Procurement …the preferred method.

Best Value Procurement Model Spec:
Scored and Mandatory Spec Sections
 The Owner and Engineer will need to evaluate the submissions.
 DDC systems lend themselves to awards using methods other than low
Bidder as each Vendor has a different feature set (it is like choosing
between various models of cars).
 Appin has a points scoring mechanism. There are two components
 35 minimum mandatory requirements.

 60 scored items.
 The process avoids the problem of putting in a desired feature that may
limit competition. You pick which vendor comes closest to your ideal
system.

Minimum Mandatory Spec Item:
Support of DS-RP-A, B
 Support for DS-RP-A and DS-RP-B BIBBs by panel Level as

listed in the Device Profiles Section 15952 forms part of the
minimum mandatory requirements. Provide proof of compliance.
 Other BIBBs (Trending, Alarming, Scheduling and Data Sharing) are

scored.
 Support for the Group, Loop, Averaging, Command and other

objects is also scored.

Minimum Mandatory Spec Item:
Must be a Voting BMA Member
 This clause forms part of the minimum mandatory requirements. Provide proof
of compliance.
 Proponent must provide evidence in Schedule that the Proponent’s

DDC equipment manufacturer is participating in the BACnet
Manufacturers Association (BMA) interoperability testing program as
a condition of bidding the Work.

Scored Spec Item:
Native BACnet Panel Support
 This clause is scored based on partial or complete support. Provide

information to allow a score to be assigned by the Engineer.
 The Engineer prefers that native BACnet devices be provided at the

Level 0 OWS and at all DDC panel levels. Points will be awarded
for Proponents having native BACnet devices. All Level 0, 1/1A and
2/2A devices shall be native BACnet in order for a Proponent to
receive 100% of the points for this clause.
 The Engineer will not consider their products native BACnet unless
the products comply with the definition in this Supplier Arrangement
Specification.

Scored Spec Item:
Support for ReadPropertyConditional
 This clause is scored based on partial or complete support. Provide

information to allow a score to be assigned by the Engineer.
 Support ReadPropertyConditional service to read properties of

objects based on operator defined selection criteria. Support DOS-
style wildcarding in the Object_Name to reference/collect all
Present_Values of an object (e.g., *.TMP returns the Present_Value
of all AI temperature objects to support the reporting requirements
of 15953.12). Use the ReadPropertyConditional service to satisfy
the other point and attribute reporting requirements of 15953 (listing
all overridden objects or objects in fault).

Using the Vendor Plugfest to test out the
Internetwork
 Get a submission on the

features. Score submissions.
 One-on-one demo to review
the system features.
 BACnet demo to show the
BIBBs.
 The client sees all the
prospective systems at one time
over a two day period…like
buying a car.
 Needed for standalone
integration design
Using VTS to see Read-Property-Multiple

Using VTS to see Read-Property-Multiple

Chiller Integration: BACnet Spec Language
in the Spec Chiller Section
 Chiller control panel requirements:
 The chiller shall be represented externally as a BACnet device on the

Owner’s Intranet.
 It shall support the following BACnet Interoperability Building Blocks

(BIBBs):
 List BIBBs
 Support the following objects. Support the required optional properties to

meet the Specification requirements and Sequence of Operations:
 List objects

Chiller
Integration:
BACnet
Chiller
points list
in the
Chiller Spec
Section

Chiller Integration: BACnet Spec Language
in the Spec Chiller Section
 The chiller controller shall be a BACnet device that shall be connected to the
Base-wide EMCS WAN using BACnet-IP.
 The chiller controller shall reside on the Engineer’s Intranet in the

building. The Engineer will provide the network drop to the chiller to
within 3 ft. of the panel. This Section is responsible for providing the
network connection to the Engineer's EMCS WAN so the access to the
chiller is possible. The Engineer will provide IT personnel to assist with
the commissioning of the network connection.
 The chiller controller shall support use of a static IP address for remote
access through the Engineer's firewall. The chiller controller shall have
an Annex J router to support BACnet/IP.
 The chiller data may be represented internally as SNVTs or proprietary
points, but the data must be represented externally as BACnet objects
and services. Chiller controllers using LonMark or a proprietary EIA-485
protocol are acceptable only on this basis.

Chiller Integration: DDC Contractor’s
responsibility for Chiller Work
 The Controls Contractor shall map all BACnet points referenced in
Section 15624 back to the Front End and provide a chilled water
system graphic with all control, status and monitoring points
displayed.
 The list shown in 15624 is approximate. All data shown must be
represented externally on the network as BACnet objects and
services.
 Chiller Suppier does not support BACnet Alarms and Events.
Controls is responsible for generating the required EE and NC
objects for the chiller per the DDC spec requirements.
 Controls shall supply at least two graphics to represent the data.
Controls will also have to parse, process and transmit the alarms
that will be represented as AV and BV objects by the Chiller
Supplier’s panel.

Chiller Integration: DDC Contractor’s
responsibility for Chiller Work
 Transmit a critical alarm and disable the chillers if any of the
following conditions are met:
 A refrigerant gas leak has been detected.

 Chiller common alarm is detected.
 Chilled Supply water pump status indicates a no flow condition.
 The chilled water setpoint is user adjustable. The chiller shall use
its own packaged controls to maintain the external setpoint provided
by the DDC system. The packaged chiller controls shall allow the
DDC system to sequence the chillers and receive an alarm signal
when a fault has occurred.

Chiller Integration: Interlock between R-22
monitor and Chiller Room EF:
 Alarm for refrigerant leakage. Provide hardwired interlock to chillers to
shut down chillers in case of a refrigerant leak. Open the inlet and outlet
dampers and then start the exhaust fan.
 Chiller supplier shall provide the required contacts for an interlock
between the refrigeration monitor system and the exhaust fan.
 Section 15900 shall provide the interlock wiring.
 Section 15800 will provide the exhaust fan.
 Section 15900 will provide the dampers for installation by 15800.
 Division 16 shall provide power for the refrigeration monitor, exhaust
fan and shall provide power wiring to this equipment.
 Chiller supplier and Section 15900 shall be on-site together to
commission this system to the satisfaction of the Engineer.

BACnet - The Easy Part:
DDC Contractor’s Display of Chiller Data

BACnet - The Easy Part:
Chiller Supplier’s Display of Chiller Data

Commissioning: Are we done yet?
 Put forms and procedures in spec. No surprises for the

Contractor.
 Decide who completes and who checks the commissioning

forms (20% check).
 Define when different vendors come to the site for

commissioning if a BACnet job.
 Collect trends during a pre-commissioning period for at

least 30 days.

Commissioning: Are we done yet?
 Involve Owner’s staff during the commissioning process.

Does not count as training time.
 Allow for static and dynamic commissioning.
 Commission programming and graphics – not just

hardware points.
 Allow for seasonal commissioning.

CSI MasterFormat Specification:
You will have to rewrite your Controls Spec
 The Specification World is changing.
 Controls is now in Division 25…Not in Division 15.
 The 3-part Spec format - General/Products/Execution – is gone.
 The new format is much better but it will mean a re-write of the spec.

Advanced Spec Writing:
Final Thoughts
 Specifying controls will continue a “pain” for consultants
 Read The Contractor’s Guide to Change Orders. Defective specs
are NOT the Contractor’s fault.
 Controls is NOT a commodity….use the 2-envelope RFP approach
to develop a long term competitive relationship with selected
vendors, using BACnet.
 Specifying BACnet is the easy part. The chiller example showed
that there are many other issues to get it right.
 The CSI MasterFormat Division 25 will meet a controls spec rewrite.
 Commissioning must include the SOFTWARE as well as the
hardware.
 BACnet is expanding to lighting, fire, security, new services, new
objects, etc….you need to stay current by joining BI.

BACnet
A FORCE TO BE RECKONED WITH
www.APPIN.com

T2S6 - Advanced BACnet Spec Writing

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

T2S6 - Advanced BACnet Spec Writing

Transféré par

Droits d'auteur :

Formats disponibles

TRACK 2, SESSION 6

Advanced Spec Writing with BACnet

Presented by: Grant Wichenko, P. Eng.

Advanced BACnet Spec Writing

Advanced BACnet Spec Writing

 Control systems are like computers…except they have to work for

Advanced BACnet Spec Writing

 No special ASHRAE classes on specifying pumps.

 Consultant knowledge on controls is limited….Now with GPC 13 or

Advanced BACnet Spec Writing

 BACnet implementation varies by vendor.

 Giving EQUALS in a Specification implies that DDC is a commodity

Advanced BACnet Spec Writing

 Contractor’s Guide To Change Orders is designed to give you

 Everything you need for lean, advantageous contract interpretation is in

 Change Orders are due to bad specs…not the Contractor’s fault

Advanced BACnet Spec Writing

 My personal favorite…..“As indicated/shall be capable of ”

Advanced BACnet Spec Writing

 You do not need to be a BACnet expert but you must specify:

 Need for schedule, alarm, trends using the BACnet.

 Use ASHRAE Guideline 13 Spec. It is a good starting point to help

Advanced BACnet Spec Writing

 BACnet interoperability is the intersecting set of a Venn

 You must be comfortable with BACnet terminology to do

 Ask to see any proprietary objects and services… Trade

Advanced BACnet Spec Writing

 Give definitions for network visibility, native BACnet

 Put BACnet spec sections in one place. This simplifies

 Include the object list in the Specification at a

 Approve Facility/System/Point (F.S.P.) naming convention

Advanced BACnet Spec Writing

 Set minimum mandatory requirements to avoid purchasing

 Categorize vendor’s hardware. BACnet has defined device

 Devices like RTUs, VSDs, Humidifiers, Chillers have on-

Advanced BACnet Spec Writing

 Ask for object creation/deletion services. Some vendors

 Set number of entries in the Calendar and Schedule

 Intrinsic alarming vs Event Enrolment support for alarms.

Advanced BACnet Spec Writing

 Allow for additional entries in the RecipientList for future

 Ask support for the Out_of_Service property for fault

 Give options in the BACnet section. Consider Alternates

 Set command priorities. Leave some free. Which vendor

Advanced BACnet Spec Writing

 Allow for hardware and software updates in the Base Bid

 Allow for time on site to deal with interop issues, in each

 Deal with allocating devices instances…no duplicate ids

 Allow for a sniffer if necessary. VTS helpful in finding

Advanced BACnet Spec Writing

 Support the audit trail for creation/deletion of trendlog

 Define what is to be logged and how many samples

 Support for trending and archived data.

 Define the amount of globally shared data needed (OAT).

Advanced BACnet Spec Writing

 DDC technology is constantly improving…a moving target

 Buildings are always being built, renovated or demolished

Advanced BACnet Spec Writing

 Network security a concern…IT people must be involved in the

 Good fences make good neighbors…Create a VLAN of DDC

 There may be an Energy Performance Contract on the campus

 There are usually existing proprietary systems on campus that

Advanced BACnet Spec Writing