BACNet BMS Overview

Last Update July 2005
APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM –

TABLE OF CONTENTS
UNSW DESIGN & CONSTRUCTION REQUIREMENTS – WEB ENTRY PAGE
SECTION A – INTRODUCTION
SECTION B – DEVELOPMENT & PLANNING
SECTION C – ARCHITECTURAL REQUIREMENTS
SECTION D – EXTERNAL WORKS
SECTION E.1 – HYDRAULIC SERVICES
SECTION E.2 – MECHANICAL SERVICES
SECTION E.3.1 – ELECTRICAL SERVICES
SECTION E.3.2 – LIGHTING
SECTION E.3.3 – SPECIAL SYSTEMS
SECTION E.3.4 – HIGH VOLTAGE
SECTION E.4 – COMMUNICATIONS
SECTION E.5 – LIFTS
SECTION E.6 – FUME CUPBOARDS
SECTION F – SPECIFIC AREA REQUIREMENTS
APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM – SCHEDULE OF

CHANGES – REVISION 4.1...................................................................................................... 5
1 BUILDING AUTOMATION AND CONTROL SYSTEM .................................................. 6
1.1 General .................................................................................................................... 6
1.2 Scope....................................................................................................................... 6
1.3 Preliminary Proposal Review .................................................................................. 7
1.4 Submittals................................................................................................................ 8
1.5 Installation Standards .............................................................................................. 8
1.5.1 Fixings and Supports ..................................................................................... 10
1.5.2 Building penetrations...................................................................................... 11
1.6 BACnet Network Wiring......................................................................................... 11
1.7 Power Supplies...................................................................................................... 11
1.8 Electromagnetic Interference (EMI)....................................................................... 11
UNSW Design & Construction Requirements (Rev 4.1)

1/37
1.9 Operator Interfaces................................................................................................ 12

1.10 Identification....................................................................................................... 12
1.11 Interoperability ................................................................................................... 12
1.12 Materials ............................................................................................................ 12
1.13 Proprietary Brand Name References................................................................. 12
1.14 Relocation and Re-use of Existing Equipment .................................................. 13
1.15 Communication .................................................................................................. 13
1.16 BACnet Conformance ........................................................................................ 13
1.17 Change Management Procedures..................................................................... 13
1.17.1 Urgent Changes ............................................................................................. 14
1.17.2 Temporary Changes....................................................................................... 14
1.17.3 Remote Changes ........................................................................................... 14
1.17.4 Setpoints and Operating Time Schedules ..................................................... 14
1.17.5 Operations Log Book ..................................................................................... 14
1.17.6 Backup Copies of System Files ..................................................................... 14
1.18 Architecture........................................................................................................ 14
1.19 Auxiliary Communication Devices ..................................................................... 15
1.20 Communication Mechanism .............................................................................. 15
1.21 Capacity ............................................................................................................. 15
1.22 Operator Interface.............................................................................................. 15
1.23 BACnet Conformance ........................................................................................ 15
1.24 Operating System .............................................................................................. 16
1.25 Operator Display ................................................................................................ 16
1.26 System Graphics................................................................................................ 16
1.27 System Configuration, Programming and Management.................................... 16
1.28 Programming and Diagnostic Tools................................................................... 17
1.29 Control Simulation Mode ................................................................................... 17
1.30 On-line Help ....................................................................................................... 17
1.31 Security .............................................................................................................. 17
1.32 Alarms and Alarm Indication.............................................................................. 18
1.33 Scheduling ......................................................................................................... 19
1.34 Trend Log Displays and Reports ....................................................................... 19
1.35 Remote Communications .................................................................................. 20
1.36 Operator Interface Hardware ............................................................................. 20
1.37 Maintenance Supervision .................................................................................. 20
1.38 Data Accessibility by Stakeholders.................................................................... 20
1.39 Metering ............................................................................................................. 21
1.40 Field Devices ..................................................................................................... 22
1.40.1 Temperature Sensors..................................................................................... 22
1.40.2 Humidity Sensors ........................................................................................... 22
2/37
1.40.3 Differential Pressure switches........................................................................ 22

1.40.4 Differential Pressure Sensors (LP air)............................................................ 22
1.40.5 Pressure Sensors (HP air) ............................................................................. 22
1.40.6 Remote Adjustment Potentiometers .............................................................. 23
1.40.7 Flow Meters.................................................................................................... 23
1.40.8 D.P switches (liquids) ..................................................................................... 23
1.40.9 Carbon Dioxide (CO2) Sensors ...................................................................... 23
1.40.10 Air Quality Sensors ..................................................................................... 23
1.40.11 Liquid Level Switches ................................................................................. 23
1.40.12 Light Level Sensors .................................................................................... 23
1.40.13 Control Status Relay................................................................................... 23
1.40.14 Control Relay (Solid State) ......................................................................... 23
1.40.15 Control Relay (Electro-Mechanical)............................................................ 24
1.40.16 Current Sensor (Analogue)......................................................................... 24
1.40.17 Load Shedding Devices.............................................................................. 24
1.40.18 Automatic Control Valves ........................................................................... 24
1.40.19 Electric Valve Actuators.............................................................................. 24
1.40.20 Damper Actuators....................................................................................... 24
1.40.21 Pneumatic Transducers.............................................................................. 25
1.40.22 Variable Speed Drive Controller ................................................................. 25
1.41 Execution ........................................................................................................... 26
1.41.1 Sequence of Operation .................................................................................. 26
1.41.2 Graphics Preparation ..................................................................................... 26
1.42 Commissioning .................................................................................................. 26
1.42.1 Commissioning and Programming ................................................................. 26
1.43 Acceptance Testing ........................................................................................... 27
1.44 Documentation................................................................................................... 27
1.45 As-built Documentation...................................................................................... 28
1.46 I/O Points List..................................................................................................... 28
1.47 Non-standard BACnet Objects .......................................................................... 28
1.48 Program Records............................................................................................... 29
1.49 BACnet Gateways.............................................................................................. 29
1.49.1 Scope of Work................................................................................................ 29
1.49.2 Minimum Requirements ................................................................................. 29
1.49.3 Additional Desirable Features ........................................................................ 30
1.49.4 Information to be provided with Proposals/Tenders....................................... 30
1.50 Training .............................................................................................................. 30
1.50.1 General FM/Engineering staff ........................................................................ 30
1.50.2 Engineer & selected staff ............................................................................... 31
1.51 Campus Wide BACnet System Identification .................................................... 31
3/37
1.52 MAC Address..................................................................................................... 32

1.53 Instance Device ................................................................................................. 32
1.54 Network Number ................................................................................................ 33
1.55 Allocation of Network Numbers ......................................................................... 33
1.56 BACnet Broadcast Management Device (BBMD) Scheme ............................... 34
1.57 Off-Campus System Identification ..................................................................... 34
1.58 Summary – UNSW Data Network...................................................................... 35
1.58.1 Active Equipment ........................................................................................... 35
1.58.2 VLAN .............................................................................................................. 35
1.58.3 Initial Activation & Ongoing Support............................................................... 35
1.59 Basic BACnet System Identification Diagram................................................... 37
APPENDIX 2 – CONCRETE FOR STRUCTURES
APPENDIX 3 – UNSW CONTROL SYSTEM STANDARDS HVAC
APPENDIX 4 – DOCUMENT REQUIREMENTS
APPENDIX 5 – UNSW STANDARD PRELIMINARIES
APPENDIX 6 – SECURITY SYSTEMS
APPENDIX 6 – SECURITY SYSTEMS

4/37
APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM – SCHEDULE

OF CHANGES – REVISION 4.1
As a guide only, attention is drawn to changes that have been made in the following clauses
since the last revision
Clause Date
General revision
No changes August 2004
Major rewrite (Version 4.1) July 2005

5/37
1 BUILDING AUTOMATION AND CONTROL SYSTEM

1.1 General
The work shall include design; supply, installation, and commissioning a complete
microprocessor based automatic control system to achieve the performance specified in the
following clauses hereafter called the BACS (Building Automation and Control System).
Operator Interfaces and Controllers shall be connected directly through a BACnet
communication internetwork. All communications across this internetwork shall conform to
ASHRAE Standard 135-2004, BACnet protocol.
All products used in this project installation shall be currently under manufacture. This
installation shall not be used as a test site for any new products unless explicitly approved by
the University’s Representative, in writing.
Spare parts shall be available for at least five years after project completion. The
manufacturer shall have a stated policy of maintaining backward compatibility with previous
versions of its products. Tenderers shall provide a copy of this statement with their
submission.
Protocol Implementation Conformance Statements (PICS) for each and every device shall be
submitted as verification of compliance with the BACnet standard and a complete schedule of
BACnet devices shall be supplied, and approved, prior to any works commencing on site.
It is essential for tenderers to visit the University site to become familiar with field conditions,
existing equipment, communication arrangements and other matters impacting on the BACS
works.
1.2 Scope
a) The BACS architecture shall comprise:
i) Operator Interfaces comprising PC-based workstations;
ii) Communications network with BACnet/IP connection to the UNSW BACS VLAN
network;
iii) Controllers with inputs and outputs (I/O) for controlling central plant and air
handling systems with customable control sequences, data collection
(metering/trending);
iv) Application Specific Controllers with inputs and outputs (I/O) for controlling
packaged systems, unitary equipment and terminal units.
b) This project encompasses the following:
• Work Description
• Preparation of control shop drawings for review.
• Provision of control components.
• Provision of a network of BACnet Direct Digital Control Devices.
• Provision of all necessary graphics software, system software, and third party
software as specified.
• Wiring of the BACS controls system.
• Programming the sequence of operation.
• Preparing dynamic graphics screens (at least two audits to be allowed for during
production).
• Calibration and commissioning of the installed controls system in accordance with
CIBSE Commissioning Code C: Automatic Controls.

6/37
• Provision of maintenance manuals and as built drawings.

• Provision of training of University's operators.
• Provision of a one-year warranty on all components.
• Provision of one year of maintenance (to be included in project cost).
• Demonstration and confirmation that all systems are programmed and operation
correctly.
• Submission of CD ROMs (including back-ups) containing up to date copies of the
programs in each controller. Provision of original program disks and documentation,
proving registration for all software programs provided as a part of this contract,
including: Windows 2000, the BACS operator interface software, and the BACS site
graphics.
• Submission of four (4) printed copies of the final programs and documented
programmed sequences of operation.
• Provide the necessary engineering, installation, supervision, commissioning and
programming for a complete and fully operational system. Tenderers shall include in
their tender price, for as many trips to the job site for installation, supervision, and
commissioning as are necessary to complete the project to the satisfaction of the
University’s representative.
• The system shall consist of all operator interfaces, microprocessor based controllers,
sensors, wells, automatic control valves, transducers, and relays, automatic control
valves, damper actuators, meter interfaces etc as detailed on the points schedules.
• Provide all the necessary software and interface devices for all BACS-based
systems.
• At the completion of the installation and immediately following commissioning provide
appropriate on site training for four (4) people nominated by the University.
• Include the cost of a preventative maintenance service contract, during the one- (1)
year, defects liability guarantee period. Include all parts and labour in the service
contract during the one-year guarantee period. Provide two site visits of
approximately one day each and two, quarterly remote access reviews of the system.
• Check sensor calibration and control system twice during the first year (one check
shall take place one (1) month prior to the expiration of the defects liability period).
Following each visit:
i) Printed graphs shall be provided of trend logs for all values that are being
logged as specified.
ii) Update the printed and CD copies of any changes made to programs for any
controller.
iii) Warranty all components supplied under this contract for a period of one year
from practical completion. Replace all controls equipment that fails during this
period without cost to the University.
1.3 Preliminary Proposal Review

Within (5) five working days after proposal closing, and before award of a contract, tenderers
shall submit preliminary design documentation for review by the University. This document
shall contain the following information:
a) Location of local or nearest office.
b) Description and location of technical staff available for installation and service.
c) Location and qualification of design, support and programming staff.

7/37
d) Location of spare parts stock and list of spares considered necessary, including
prices for each item. The University may at its discretion elect to purchase some or
all of the listed items.
e) Name of Project Manager.
f) Name of all subcontractors, and their roles.
g) Specification sheets/PICS for all pieces of equipment proposed.
h) A copy of the control specification with a statement of compliance or non-compliance
clearly identified for each item.
i) A complete schedule of rates showing prices for addition and deletion of all point
types and devices included in the proposal.
j) Description of the system operation including; speed and type of data transmission
used, type of cable or wire used, operator action necessary to execute commands,
obtain data displays or respond to alarms.
k) System capacity and limits of expansion.
l) Type and size of memory with statement of spare capacity.
m) Sample displays of graphics, reports, and trend logs, in colour.
n) Confirmation that commissioning will be conducted in accordance with CIBSE
Commissioning Code C: Automatic Controls.
o) Identity of three similar installations installed by the tenderer within the last year
(preferably within Sydney), with references. The University may at its discretion
contact the nominated referees.
1.4 Submittals
Submit with the tender the following information for review:
a) Protocol Implementation Conformance Statements (PICS) and a complete schedule
of all BACnet devices (to be approved prior to commencing any on site works).
b) A detailed proposal for a five-year comprehensive maintenance service contract,
which shall include site inspections, re-calibration, and re-programming as necessary.
c) Sample Control Schematics from a similar project, prepared on the controls graphic
system.
d) Sample detailed as-built control flow charts/programs from a similar project.
e) Sample wiring diagrams including complete power system, interlocks, control and
data communications from a similar project.
f) Component Data including engineering data sheets with sufficient detail to indicate
that the proposed equipment complies with the specifications.
All sample documentation is to be from a project or projects that have been completed by the
tenderer.
1.5 Installation Standards

The BACS shall be installed complying with all:
i) National and local statutory regulations.
ii) Occupational Health & Safety legislation and codes of practice.
iii) SAA Wiring Regulations (AS3000).
iv) AS/NZS 3080:2003 – Integrated Telecommunications Cabling System for
Commercial Premises.
v) AS/NZS 3084:2003 – Telecommunications Pathways and Spaces for Commercial
Buildings.
8/37
vi) Building Code of Australia.

vii) Equipment manufacturers instructions.
viii) Regulations and conditions of the PTT and utilities suppliers.
All cabling shall be routed via the most direct route whilst maintaining a good level of
accessibility and following good general wiring practice.
Ensure that the location of all cables do not clash with other services. Locations shall be
adjusted where necessary to avoid other services and to provide a uniform and symmetrical
layout relative to structural members.
Co-ordinate with existing and new communications cabling, and provide power wiring
installed with clearances and segregation to communications cabling as required by
Communications Manual regulations and by AS3080. Provide earthed Anaconda PVC,
sheathed, metallic conduit where necessary.
Care should be taken to ensure that installed cabling does not interfere with current or future
UNSW network cabling. New or existing UNSW network infrastructure including tray,
conduits or catenary is not to be used without prior written approval from UNSW IT Services.
All mains voltage supply feeds at switchboards shall be via switched circuit breakers, supply
use and breaker rating to be indicated. At operator and user terminal sites sufficient mains
outlets shall be installed to prevent the need for plug adapters or extension leads with multiple
socket outlets, and at least one local spare outlet shall be provided.
All extra-low voltage BACS cables shall be run in screened twisted pair cables. They shall be
affixed to discrete trays, drawn into conduit or trunking and protected as agreed with the
engineer to suit the various environmental, social and mechanical locations. All new cable
runs to be installed under this contract shall be approved by the University’s representative
before installation. Cable specifications shall meet the manufacturer’s requirements,
particularly respecting overall resistance and capacitance limits. No joints will be allowed in
cables installed end-to-end. Trays, conduits and cables are not to be affixed horizontally at
floor or pedestal level. Where cables are connected to sensors measuring extreme heat, the
necessary thermal breaks with local connecting cables are to be supplied. No BACS data
cable shall be installed in the same conduit as any power cable nor affixed within 25mm if
surface/tray mounted. Where cables are run in trunking or with others clipped to tray of a
similar type they shall be identified either by colour or labels every 2m.
All wiring within false ceiling spaces shall, as far as is practical, be neatly grouped and
suspended.
Care shall be taken to ensure that the manufacturer’s recommendations with respect to
earthing data cables and controllers are obeyed.
LAN cabling between control panels shall be installed without splicing.
Ethernet cable terminations shall be made using appropriate connectors and crimping tools.
Crimping using pliers is not acceptable.
Cabling for inputs and outputs is to be double insulated 7/0.30 twisted and shielded with a
drain wire grounded at the control panel end only unless otherwise specified.
Cabling for RS485 communication networks shall be double insulated 7/0.30 twisted and
shielded, with a drain wire continuous throughout the network and grounded at the main
control panel.
Cabling for Ethernet communication networks shall be either Category 5 or 6 UTP (where a
10-Base-T network is to be installed) or RG58-BU 50 ohm coaxial cable with 90% braid
(where a 10-Base-2 network is to be installed). A certified installer must carry out installation
of Category 5 or 6 UTP cable and the cable shall be coloured pink to avoid confusion with
UNSW network cabling, which is blue.
Cabling for Power Supplies to remotely located control panels shall be double insulated, with
a minimum size of 7/0.30 and a maximum size of 7/0.50. Circuits that require cable sizes
outside this range should be avoided.

9/37
Cabling for Power Supplies to main panels located in plant rooms shall be minimum of 7/0.67.
Each BACS field device shall be identified (internally on space temperature and humidity
sensors) with a common code used on points and wiring schedules, parts lists, control
strategy, Motor Control Centre (MCC) and installation diagrams/drawings.
Where a MCC is fitted with Hand/Off/Auto switches, a common circuit shall monitor their auto
condition, which shall cause an alarm when any switch is moved from the auto position.
All BACS cables shall be suitably identified with sleeves at the terminations. These shall be
recorded on the installation diagrams, wiring schedules and commissioning sheets. Marking
pen is NOT acceptable for this purpose.
Sensors, actuators, switches and all field devices shall be mounted according to the
manufacturer’s instructions. All will be installed with clearance to allow for servicing, and the
conduit connected by methods to allow easy replacement.
Where controllers switch circuits having potentially different mains voltage supply feeds, extra
low voltage relay circuits (24V dc) powered from the BACS supply shall be employed. A
notice shall be fixed inside the controller detailing how all mains feeds into it can be isolated.
Consideration shall be given to employing an extra low voltage control circuit for motor starter
and contactor coils and shall be mandatory where MCC with separate cubicles for motor
starters are employed.
All terminations shall be undertaken in terminal strips (where provided) or in Scotch-lok UR2
connectors. Twist on, IDC and BP style connectors shall not be used unless specifically
approved by the University’s representative.
Each controller shall be provided with a schedule identifying the points connecting into the I/O
terminals inside the panel door.
1.5.1 Fixings and Supports

Fixings and supports for equipment and wiring for securing to walls, ceilings, floors or
structures shall be provided as applicable. All fixings adopted shall be of an approved type
and pattern.
All fixing holes in concrete or brickwork shall be neatly drilled to a depth equal to the length of
plug to be used, excluding plaster or other soft cladding finish. Fixings shall not be made into
joints between brick and block work.
All load-bearing fixings shall be of appropriate size for the anticipated load plus a 50% safety
factor. All fixings shall be corrosion resistant and shall be of the same or nobler material so
that they will not be preferentially corroded.
All supports shall be:
i) Electro-galvanised threaded rod hangers;
ii) Galvanised steel brackets;
iii) Approved for the purpose intended.
All nuts and bolts shall:
i) Have heads which are hexagonal in shape;
ii) Be provided with flat washers;
iii) Have metric threads in accordance with AS1275;
iv) Be of full length so that when tightened to the correct tension, will show at least one
full thread beyond the nut.
The following fixings are not acceptable:
i) Fixings made by the use of explosive powered tools;
ii) Fixings made in the mortar joint in brick or block work;
iii) Fixings made into the timber infill of concrete slab floors;

10/37
iv) Fixings into plasterboard, fibre cement, ceiling tiles or similar friable material;
v) Self-tapping screws into sheet metal;
vi) Nails;
vii) Anchor plugs or ties incorporating synthetic material where used to secure essential
services wiring and equipment (eg. lift sub-mains, wiring to smoke exhaust systems,
emergency warning wiring, emergency lighting wiring etc).
1.5.2 Building penetrations

The locations of all penetrations through the building structure shall:
i) Be submitted for approval prior to their installation;
ii) Be arranged in consultation with other trade works.
All penetrations shall:
i) Comply with the requirements of the local Building Authority;
ii) Be sized and located to suit the works;
iii) Be sealed with an approved fire-resistant packing after installation of the service
penetrating the fire rated barriers, so that the integrity of the fire rating is maintained
and to provide a smoke-tight seal;
iv) Have sleeves, blockouts etc provided where necessary;
v) Be drilled or cut out where they have not been provided during construction of the
wall, floor etc.
Sleeves shall:
i) Be formed from not less than 1.2mm galvanised sheet steel;
ii) Be trimmed flush with the surrounding concrete except for plantroom floors, where
they shall project 100mm above the finished floor level.
1.6 BACnet Network Wiring

LAN cables are to be wired in a daisy chain. Star or tee connections are not permitted unless
specifically recommended by the manufacturer in published installation procedures.
Install LAN cabling between control panels without splicing.
Ethernet cable terminations are to be made using appropriate connectors and crimping tools.
Crimping using pliers is not acceptable.
1.7 Power Supplies

All transformers and power supplies for field devices to be located within designated control
enclosures.
All power for controls equipment shall be from dedicated circuits. Where a controller is
dedicated to controlling a single piece of equipment power may be obtained directly from that
equipment.
Power shall not be obtained by tapping into miscellaneous circuits that could be inadvertently
switched off.
1.8 Electromagnetic Interference (EMI)

The complete installation and all equipment shall be in accordance with the Electromagnetic
Compatibility (EMC) framework for commercial environments to the requirements of the
Australian Communications Authority (ACA) under the Radio Communications ACT 1992, as
amended. Australian standards AS 4251 and AS 4051 shall also be applicable.

11/37
1.9 Operator Interfaces

Only one level of software interface shall be provided for the complete project. Access at any
point into the system must be through the same interface. Different interfaces for different
levels of access are not acceptable. If graphics are provided, then graphical interface
software will be used for every level of interface into the system and on all interfacing
equipment (desktop computer, laptop computer, and modem). The operating software will
allow the University to access the complete operating system. The software provided with this
system will be the same software package that the controls vendor uses to access and edit
the BACS. If the manufacturer provides multiple levels of software packages, the most
complete and powerful package available shall be provided.
The software package provided must allow the University to completely handle the BACS.
The BACS will have help screens to assist the University in monitoring, editing, and
programming the complete BACS. The University must not necessarily be dependent on the
controls manufacturer or BACS integrator, for future changes and expansion of the system.
Expanding the BACS must not require additional software packages. The control
manufacturer agrees to provide all hardware components for future changes to the University,
at published list prices or better. Provide a statement in writing to the University, agreeing to
provide access to BACS and terminal components as condition of accepting a purchase
order.
1.10 Identification
A professionally printed/typed input / output layout sheet shall be mounted within each
controller. This sheet shall be laminated and shall include the name of the points connected to
each controller channel together with the revision number and date.
All controllers and associated devices shall be identified with symbols relating directly to the
control diagram. Provide permanent plastic labels for each input and output point, with the
following information:
a) Point descriptor
b) Point type and channel number
c) Corresponding controller number
1.11 Interoperability
As the campus may have a variety of BACS systems, from different vendors, various actions
and interactions are required between vendors, integrators and the University. To ensure that
interoperabilty is achieved in a smooth and well-defined manner, the successful contractor,
for any BACS, shall produce a co-ordination action list that identifies all BACnet-related
information requirements. For example each BACS integrator/vendor involved, HVAC
equipment interfaces, University LAN/WAN co-ordination, responsible parties, contact names,
critical times/dates (if required) and so forth.
1.12 Materials
All products used in this project shall be new and currently under manufacture. This
installation shall not be used as a test site for any new products, unless explicitly approved by
the University in writing.
Spare parts shall be available for at least five years after completion of this contract.
1.13 Proprietary Brand Name References

Any reference in this Specification to proprietary brand names or to a particular manufactured
product without the use of “or approved equal” is to be interpreted to mean that the particular
article or product is the only one to be supplied or used.

12/37
1.14 Relocation and Re-use of Existing Equipment

Where equipment is to be relocated or re-used, all tests necessary to ensure that the
equipment will satisfactorily perform the final duty as specified shall be carried out prior to
relocation or re-use. If, after testing, any items cannot perform as specified, the University’s
representative shall be advised and instructions awaited before any further work on those
items is undertaken.
1.15 Communication
The system architecture shall comprise the following components, networked together to
provide a system of connected devices that operate as a single BACS for the entire project:
a) Operator Interfaces comprising PC-based workstation/s
b) BACnet/IP communications network linking to the campus-wide BACnet VLAN
provided by the UNSW data network
c) Controllers with inputs and outputs (I/O) for controlling central plant and air handling
systems with customable control sequences
d) Controllers with inputs and outputs (I/O) for controlling packaged systems, unitary
equipment and terminal units
BACnet LANs (especially MS/TP LANs) shall be operated at the maximum speed specified by
the BACnet Standard. If it is proposed to use devices, which cannot operate at the maximum
speed, on new or existing LANs, this shall be clearly identified and highlighted to the
University at the time of tender. The University reserves the right to reject devices that
operate at less than maximum BACnet Standard MS/TP LAN speed.
1.16 BACnet Conformance

Operator Interfaces, Building Controllers, System Controllers, and Application Specific
Controllers shall be connected directly through a BACnet communication internetwork. All
communications across this internetwork shall conform to ASHRAE Standard 135-2004,
BACnet protocol.
1.17 Change Management Procedures

The BACS Contractor shall work with the University’s representative to develop a mutually
satisfactory change management procedure that will be applied to any changes that affect the
BACS. The change management procedure shall ensure that:-
i) No change is made without the written approval of the University;
ii) Every change is fully documented and O & M manuals are updated as
necessary;
iii) Backup copies of software are made as described below.
When the BACS Contractor wishes to make any changes to the system, however minor or
temporary, a Change Note shall be submitted to the University’s representative for approval
before any work is undertaken. The Change Note shall fully describe the proposed change,
why it is considered necessary and the effect, if any, that the change will have on the
operation of the system. No change shall be implemented until the Change Note has been
approved and signed by the University’s representative.
A backup copy of the affected system files shall be made before carrying out any
modifications, as described below.
When an approved change has been made, a copy of the Change Note shall be inserted in
the relevant section(s) of the O & M manual and shall remain there until the manual has been
updated. Documentation updates shall be made within 5 working days of any change being
made, and the Change Note(s) shall then be removed and filed in a separate Change Note
file.

13/37
1.17.1 Urgent Changes

If, in the opinion of the BACS Contractor, an urgent control strategy modification is necessary
in order to correct a fault then the verbal approval of the University’s representative shall be
sought before proceeding. If the University’s representative cannot be contacted then the
urgent modification may be carried out provided that the University’s representative’s
approval is sought as soon as possible afterwards, and subject to the requirements for
backup copies to be made and documentation to be updated.
1.17.2 Temporary Changes

When a temporary change is made, there will be no need to update the O & M documentation
but a copy of the Change Note shall be inserted in the manual as described above. Such
Change Notes shall be removed and filed in the Change Note file once the temporary change
has been reversed. Temporary changes are subject to the requirements for approval by the
University’s representative and for backup copies of all affected system files to be made.
1.17.3 Remote Changes

The BACS Contractor shall have remote access to the system via the Internet. The change
management procedures described in this section shall apply equally to any changes that
may be made via remote access. Change notes relating to remote operations shall be faxed
or e-mailed to the University’s representative. The BACS Contractor shall only make changes
via remote access under emergency circumstances or in response to a written request from
the University’s representative.
1.17.4 Setpoints and Operating Time Schedules

The BACS Contractor shall not change setpoints or adjust operating time schedules without
written authorisation from the University’s representative. Once authorised, there will be no
need for a Change Note or documentation updates but the details must be entered in the
operations logbook.
1.17.5 Operations Log Book

All system operators, whether they are employees of the BACS Contractor or representatives
of the University, shall enter details of any work done on the system into the operations
logbook. The logbook will be kept adjacent to the Operator Workstation and will contain
entries for date, time, operator’s name and details of work done. Log book entries shall be
made immediately, not retrospectively. Note: the Log Book may be in electronic format and
kept on the BACS server, subject to approval by the University’s representative.
1.17.6 Backup Copies of System Files

A backup of all affected system files, programs and data, is to be made whenever any
changes are to be made. There are to be two copies of each backup, written to CD-R disks,
clearly labelled with the title, date and time and stored on site. The University’s
representative will keep one copy while the other will be stored in the University’s fire-safe
archive.
The BACS contractor may make and retain a third backup copy, labelled as detailed above,
for his own records.
The media used for backup files shall be Compact Disk, writable once only. CD-RW formats
and all magnetic media are not acceptable.
The agreed change management procedure will be appended as a schedule to the contract.
1.18 Architecture
The BACnet communication internetwork shall be based on ISO 8802-3 (Ethernet) for
Operator Interfaces. System Controllers shall be connected using ISO 8802-3 (Ethernet), or
any BACnet LAN. The system shall utilise BACnet IP based on UDP/IP for routing across the
Internet or across complex routers and /or hubs to create a wide area network, with remote
operator workstation/s.
14/37
NOTE: It shall be the responsibility of tenderers and contractors to ensure that the BACS
design transparently interconnects with the University network, to achieve a fully functional
BACnet-based BACS.
Presently, there are two virtual LANs (VLANs) for BACS energy management use. These are
identified as follows:
Description VLAN IP Address
Energy VLAN 11 129.94.38.000/24
Management
BACnet VLAN 323 TBA
In general, BACnet shall be used for general building automation, monitoring and control.
However, selection of the VLAN to be used shall be discussed with the University’s Facilities
Management Unit.
Tenderers and contractors must note the details given in the appendix relating to information
and services provided by the IT Services Unit. Any requests for information shall be handled
as described in that appendix. Tenderers and contractors shall not contact the IT Services
Unit unless specifically authorised to do so by a representative of the Facilities Management
Unit.
All work shall be in accordance with the requirements of UNSW IT Services. All fees, costs
payable to the IT Services Unit shall be specifically allowed for in the tenders submitted.
1.19 Auxiliary Communication Devices

Provide all communication media, connectors, repeaters, hubs, and routers necessary for the
BACnet communication network.
1.20 Communication Mechanism

Communication services over the BACnet communication network shall result in operator
interface and value passing that is transparent to the internetwork architecture as follows:
(a) Connection of an operator interface device to any one controller on the BACnet
communication network will allow the operator to interface with all other controllers as
if that interface were directly connected to the other controllers. Data, status
information, reports, system software, custom programs, etc., for all controllers shall
be available for viewing and editing from any one controller on the BACnet
communication network.
(b) All database values (e.g., objects, software variables, custom program variables) of
any one controller shall be readable by any other controller on the BACnet
communication network. All objects and object properties shall be easily viewed and
shared on a system wide basis.
1.21 Capacity
The BACnet communication network shall have a minimum total routing capacity for
4,000,000 system BACnet devices.
1.22 Operator Interface

Furnish the specified number of operator workstation software packages. The workstation(s)
shall be able to access all information in the system. These workstation(s) shall reside on the
same high-speed network as the Building Controllers.
1.23 BACnet Conformance

Protocol Implementation Conformance Statements (PICS) shall be provided for each and
every device. Workstation information access shall use the BACnet protocol. Communication
shall use the ISO 8802-3 (Ethernet) Data Link/ Physical layer protocol and communicate

15/37
directly on the network as a native BACnet device by using the Read (Initiate) and Write
(Execute) Services as defined in ANSI/ASHRAE Standard 135-2004.
Standard BACnet objects types supported shall include as a minimum:
Analogue Input, Analogue Output, Analogue Value, Binary Input, Binary Output, Binary Value,
Calendar, Schedule, Loop, Trend Log and Event Enrolment object types.
1.24 Operating System

Where specified, furnish a Microsoft Windows based concurrent multi-tasking operating
system. The operating system also shall support the use of other common software
applications that operate under Microsoft Windows including Microsoft Office, Lotus 123 and
WordPerfect. Tenderers shall contact the Facilities Management Unit to ascertain the
currently acceptable Operating Systems.
1.25 Operator Display

The operator workstation software shall display and provide operator access to all objects
associated with the project as specified in the drawings and/or points list.
1.26 System Graphics

a) Dynamic objects shall include analog and binary values, dynamic text, static text, and
animation files. Graphics shall have the ability to show animation by shifting image
files based on the status of the object.
b) System graphics shall permit authorised operators to command outputs and change
operator settings directly from interactive command and value fields. Any object
contained within the system graphic can be selected and opened for access to the full
set of object properties.
c) System graphics can be custom created and modified while on-line with a built-in
system graphic editor.
d) The system graphics editor shall include a complete library of standard HVAC
equipment graphics such as chillers, boilers, air handlers, terminals, fan coils, and
unit ventilators. This library also shall include standard symbols for other equipment
including fans, pumps, coils, valves, piping, dampers, and ductwork.
1.27 System Configuration, Programming and Management

Provide the tools to create, modify, and debug custom application programming. The
operator shall be able to create, edit, and custom programs on-line at the same time that all
other system applications are operating. The system shall be fully operable while custom
routines are edited, compiled, and downloaded. The programming language shall have the
following features:
a) The programming language shall allow independently executing program modules
residing within the same controller to be developed. Each module shall be able to
independently enable and disable other modules.
b) The programming shall be able to read and, where applicable, write the values of
objects, object properties and local variables and use them in programming statement
logic, comparisons, and calculations.
c) The operator workstation software shall provide a method of configuring the system.
This shall allow for future system changes or additions by users under proper
password protection.
d) The workstation/s shall store on the hard disk a copy of the current database of each
controller. A system operator with the proper password clearance shall be able to
save the database from any individual controller or for all controllers in single
operation.

16/37
e) The operator shall be able to clear a controller database and manually initiate a down
load of a specified database to any controller in the system.
f) The real-time clocks in all Building Controllers and System Controllers and Operator
Interfaces shall utilise the BACnet time synchronisation service. The system also
shall be able to automatically synchronise all system clocks daily from any operator-
designated device in the system. The system shall automatically adjust for daylight
savings and standard time, if applicable. The system shall automatically monitor the
operation of all network devices and annunciate any device that goes off-line because
it is failing to communicate.
1.28 Programming and Diagnostic Tools

Operator’s terminals shall include programming tools for all controllers supplied. All controllers
shall be programmed using a common programming language or graphic programming
environment utilising function blocks to carry out the requirements of the control strategy.
Function blocks shall include, P, PI, PID, Comparator, Delay-on-break, Delay-on-make, Add,
Subtract, Multiply, Divide, AND, OR, EXCLUSIVE OR, NOT, mathematical calculations,
psychrometric functions and all other necessary control function types required to represent
control logic and control loops.
Programming tools shall include a database manager of logic files and associated graphics.
Operators shall be able to select unit type, input/output configuration and any other items that
completely define units. The database function shall select pre-programmed logic and
graphics for downloading to device(s), and for use as display graphics.
Documentation, in flow-chart form, for all programming shall be included in the final system
as-built documentation. Samples of flow-chart documentation shall be included in submittals.
1.29 Control Simulation Mode

Programming tools shall include a simulation mode. This mode shall provide a means to
graphically view inputs and outputs to each program block, in real-time, as programs are
executing. Function blocks shall be animated to show the status of data inputs and outputs.
Animation shall show change of status on logic devices and countdown of timer devices in
graphical format, providing an easy to use diagnostic tool. It shall be possible to have project
graphics open, whilst concurrently using the simulation mode, such that the consequences of
user adjustments may be tested and observed in real time. This function may be performed
via the operator’s terminal, field computer, or remotely.
1.30 On-line Help

The system shall incorporate the manufacturer’s generic on-line help facility. This shall be
context sensitive and shall provide full details of every aspect of the configuration and use of
the software, such that a printed manual shall not be necessary.
Application specific on-line help shall be provided for the system as installed at the University.
This may be created using the built-in Windows Help application or may use graphic screens
created within the BACS head-end software package.
All on-line help systems shall have a contents page and a searchable index based on key
words.
1.31 Security
a) Each operator shall be required to log on to the system with a user name and
password to gain entry into the operator workstation software. System security shall
be selectable for each individual operator whereby typically the system supervisor
shall have the required access level to set passwords and security levels for all other
operators.

17/37
b) Operator passwords shall be set up to individually allow or restrict each operation,

including creating, displaying, editing, deleting, commanding and printing of objects,
for each object type.
c) Each operator shall automatically be logged off of the system if no keyboard or
mouse activity is detected. This auto logoff time shall be set per operator password.
d) The software shall maintain an operator activity log file on hard disk for tracking
operator sign on/off, commands and operations.
e) There shall be eight levels of security as described in the table below.
Level Access Privileges
Level 0 View All. No other Access.
Level 1 As level 0 plus acknowledge alarms.
Level 2 As level 1 plus Manual start for lighting and air conditioning
control. Suggested users to be Security and CATS.
Level 3 As level 2 plus time and event schedule adjustments. Also view
trend logs.
Level 4 As level 3 plus zone temperature setpoint adjustment, alarm
history viewing, and set up of trend logs. Suggested users: Asset
Services Technicians.
Level 5 As level 4 plus general HVAC setpoint adjustment. i.e. HWV,
CHWV, Static Pressures etc. Set-up of alarm parameters, viewing
of user activity logs and reporting. Suggested users: Asset
Services Supervisors.
Level 6 Not Yet Assigned
Level 7 Not Yet Assigned
Level 8 As level 5 plus User privileges and Password set-up. Suggested
users to be limited to senior system operators.
1.32 Alarms and Alarm Indication

a) The operator workstation shall provide audible, visual, and printed means of alarm
indication. The alarm dialog box shall always become the top dialog box upon receipt
of an alarm irrespective of the foreground application. Alarms assigned for printout
shall be routed to the destination printer. In addition, alarms shall be routed to
specified personnel by means of pager, mobile telephone (by SMS messaging), palm
computer, WAP, or other remote means of communication. Details to be discussed.
b) Alarm messages shall be generated and delivered as described in the detailed
specification for the individual project. Alarm messages shall not be generated or
transmitted indiscriminately.
c) Alarms shall be routed to the appropriate destination device(s), based on time and
other conditions. An alarm shall be able to initiate sequences, print, be logged in the
event log, generate custom messages, and automatically display an associated
system graphic.
d) Any object in the system shall be configurable to generate alarms on transition in and
out of normal state. The operator shall be able to configure the alarm category, alarm
limits, alarm limit differentials, states, alarm message, states and reporting actions for
each alarm in the system.
e) Minimum alarm categories required are notification, maintenance, critical and
security.

18/37
f) Alarm messages shall be user-defined text in English, such that the operator will be
able to recognise the source, location, and nature of the alarm without relying upon
acronyms or other mnemonics.
g) Each reported alarm event shall indicate the event name, the initiating object name,
alarm category and time and date of alarm occurrence. Acknowledged and restored
alarms shall additionally report the user name, time and date of acknowledgment and
time and date of restoration to normal.
h) The operator workstation shall maintain an alarm log storing the reported alarm
events as described under the previous item above in chronological order.
i) Provision shall be made to route alarms to the Security workstation outside normal
working hours, the latter to be advised by the University. Details to be discussed with
the University.
1.33 Scheduling
a) The University uses a central scheduling arrangement that is accessed and
maintained via the central BACS server. All existing and future BACS installations
shall be integrated with this system. Tenderers are required to make themselves
familiar with the operation of the system and to confirm that any proposed systems
will integrate seamlessly with it.
b) The operator workstation shall retrieve and display weekly schedules, stored in
Building and System Controllers in an easy-to-read 7-day (weekly) graphical format
for each schedule along with any applicable exception day schedules for holidays,
daylight saving periods, or special events
c) Separate schedules shall be definable for each day of the week.
d) Exception schedules shall be supported, to provide the ability for the operator to
designate any day or period of the year as an exception schedule. Once an exception
schedule is executed, it will be discarded and replaced by the standard schedule for
that day of the week.
e) Holiday Schedules shall be supported to provide the capability for the operator to
define special event or holiday schedules. The dates for these schedules may be
placed on the scheduling calendar and will be repeated each year. The operator
shall be able to define the dates of each holiday period for more than one year in
advance.
f) The operator workstation shall retrieve and display exception date schedules, stored
in Building and System Controllers in an easy-to-read monthly format.
1.34 Trend Log Displays and Reports

a) The operator workstation shall retrieve and display trend logs, in real time, of
historical object data stored in the Building Controller and System Controllers as well
as maintain trend log files saved to hard disk for subsequent use in spreadsheet or
database programs.
b) The software shall be capable of dynamically graphing the trend logged object data
by creating two-axis (x, y) graphs that simultaneously display values relative to time
for up to eight objects in different colours. This shall be achievable for any period of
time, limited only by the stored data. Facilities shall be provided to zoom in and out of
selected areas of interest.
c) It shall be possible to trend log any number of points at least equal to twice the
number of connected physical points. Any object in the system (physical or
calculated) may be logged. Sample time interval shall be easily software adjustable at
the operator’s terminal. The points to be logged, their sampling interval and their
maximum number of samples shall be as described in the individual specification for
the project, or as directed by the University’s representative.

19/37
d) Logs may be viewed from both on-site or off-site operator interface, via remote
communication where the data can be saved to files on hard disk for subsequent use
in spreadsheet or database programs.
e) The software shall also be capable of displaying trend log data in tabular form.
f) For the purpose of energy, performance, activity and event reporting, the software
shall allow hard copy and/or send to file reporting of object values according to the
operator selection criteria, as well as trend logs, operator activity logs and alarm logs.
1.35 Remote Communications

a) Provide all functions that will allow remote communications via Internet to off-site
locations.
b) Operators shall be able to access from an off-site location all objects, object
properties and programs residing in all Building Controllers, System Controllers and
Application Specific Controllers on a system wide basis. Operators shall be able to
utilise the same set of system graphics that are utilised in the LAN-based operator
interfaces to remotely operate the system.
c) All Building Controllers connected to the network shall be capable of automatically
transmitting alarm messages through the BACS network. The alarm information shall
be directed to one or more of the devices described above (see Alarms and Alarm
Indication).
d) The Building Controller shall have the capability to transmit alarms to a minimum of
20 different destination devices. Destination devices may be selected by; type of
alarm, time schedule, holiday schedule, or other selectable program parameters.
e) Access to the BACS shall be provided by means of a web browser and shall require
no special software to be installed on the user’s computer. Downloadable browser
plug-ins are permissible provided that they require no user intervention to download,
install and use. System details, including security/fire-walling, shall be discussed with
the University’s representative before any work is undertaken.
1.36 Operator Interface Hardware

The University will make a suitable Personal Computer complete with Windows operating
system available to the BACS contractor at the commencement of the works. The contractor
shall install the specified BACS workstation software on this PC and shall be responsible for
the connection of the PC to the BACnet network within the building. The contractor shall be
responsible for the security and safe keeping of this PC while it is in his possession.
This PC workstation shall be used to monitor, adjust and program the system within the
building during the installation and commissioning stages of the project. After the final stage
of commissioning the new building shall be integrated with the University’s campus-wide
BACnet systems and the University may then elect to remove the workstation for use
elsewhere.
1.37 Maintenance Supervision

(a) The System Controller software shall totalise run-times for plant items detailed in the
specification for the individual project. A high run-time alarm shall be assigned, if
required, by the operator.
(b) The System Controller shall monitor equipment status and generate maintenance
messages based upon user-designated run-time, starts, and/or calendar date limits as
detailed in the specification for the individual project.
1.38 Data Accessibility by Stakeholders

The BACS shall be accessible to users of the University’s IT network. Access shall be via a
standard web browser such as Microsoft Internet Explorer and shall be password protected
so that only authorised users can gain access.
20/37
The system shall allow a variety of University stakeholders to obtain a “view only” access to
specific information/data that is related to their particular faculty or business unit. A page-print
or printout of data may also be required, with restrictions in accordance with particular
requirements extant. Details to be discussed with the University.
1.39 Metering
The University has an extensive campus-wide Energy Monitoring And Control System
(EMACS) comprising of digital meters located in 11kV substations and selected locations
within buildings. These are remotely monitored via a purpose-built communication network.
This consists of five and twelve pair shielded, twisted cables, as well as Category 5
communication cables.
The EMACS measures consumption and demand of utilities such as electricity, gas and
water.
All existing meters have an RS485 serial communication output and communicate using
Modbus® RTU network protocol and any new meters shall conform to this standard.
The University will supply all new meters as required for future projects. The BACS
contractor shall be responsible for interfacing to these meters to provide the facilities
described below.
Where appropriate, electricity meters are required to monitor either single or three phase
loads and display and/or communicate (for each phase and in total) the following parameters:
Description Accuracy Reading
1. Phase & line Voltage (VL-N, VL-L) 0.5%
2. Current (A) 0.5%
3. Frequency (Hz) 0.1%
4. Power (W, VA and VAr) 1.0%
5. Power Factor (lead/lag) 1.0%
6. Energy (kWhr) 1.0%
7. Demand (max/min kVA) 1.0%
In addition, at major buildings, the utilities are, or will be, monitored by a digital meter
incorporating 'on-board' memory retention capability in the event of power failure.
For this purpose a meter such as the “GE” PQM meter is generally used, the version required
incorporates the four input module, permitting pulse measurements.
i. Gas consumption
ii. Gas pressure
iii. Water consumption
iv. Electricity - energy usage
• Maximum demand
• Volts, amps, kVA, kW, kVAr, power factor.
The EMACS meter panels contain (where existing), or need to be provided with (where new
metering is required) digital meters, together with approved terminal strips for data cables, CT
wiring and shorting links, power supplies, fuses or circuit breakers.
The University shall be responsible for the installation and commissioning of all new meters
and shall ensure that the RS485 communications port is made available to the BACS
contractor for connection of the BACS interface.

21/37
NOTE: Tenderers and contractors are required to clearly demonstrate how they are able to
incorporate the EMACS and these meters within their overall BACS operation, providing full
functionality and remote monitoring.
Details to be discussed with the FM Engineering Section.
1.40 Field Devices

1.40.1 Temperature Sensors
(a) Space temperature:
All temperature sensors associated with main plant control shall be PT100 types
giving a linear 4-20mA signal. Sensor ranges shall be chosen so that the range
extends to those that might be experienced under plant fault conditions.
Temperature sensors associated with terminal controllers or short wiring lengths
may be thermistor types. Compensation for the non-linear characteristic shall be
such that the accuracy shall not exceed +/- 5% at range ends and +/- 2% at the
setpoint.
(b) Duct temperature sensors shall be PT100/4-20mA, used for ducts up to 1M
diameter or square. Over that size, an averaging PT100/4-20mA type shall be
supplied, with the element fixed by clips, zigzagged across the duct.
(c) Immersion temperature sensors shall be PT100/4-20mA mounted in stainless
steel probes. All hot water pockets shall be supplied in bronze or stainless steel.
All chilled water pockets shall be stainless steel. New sensor pockets shall be
installed at sites indicated by the BACS contractor and agreed with the
University’s representative.
(d) Clamp-on temperature sensors shall only be installed in applications as agreed
with the University’s representative. Sensors heads shall be PT100 accuracy,
and suitable for lagging over with the flying lead connecting to the
electronics/junction box.
(e) Outside temperature sensors shall have a range -10/+50°C, output 4-20mA,
protection to IP67 standard and shall be fitted with a radiation shield.
1.40.2 Humidity Sensors

Humidity sensors shall be of good stability having less than 1% drift per year and an accuracy
of +/- 3% over a range of 20-90%RH including hysteresis, linearity and repeatability. Output
shall be 4-20mA linear.
1.40.3 Differential Pressure switches

D.P. switches for fan proving and filter monitoring shall be supplied complete with duct
connections and PVC connecting tubes of suitable length. The range and hysteresis
adjustments shall be concealed to prevent tampering.
1.40.4 Differential Pressure Sensors (LP air)

D.P. sensors for measuring air at duct pressures shall have an accuracy of 1% and a
resolution of 0.1% or better with output 4-20mA. The sensors shall be supplied complete with
pressure connections and connecting tubes.
1.40.5 Pressure Sensors (HP air)

Pressure sensors for measuring air at pressures greater than 1 bar shall be rated to meet 2
times the maximum pressure and 1.5-2 times the working pressure. Duct pressures shall
have an accuracy of 1% and a resolution of 0.1% or better with output 4-20mA. The sensors
shall be supplied complete with pressure connections and connecting tubes.

22/37
1.40.6 Remote Adjustment Potentiometers

Where these are supplied for local override of setpoint, they shall not be scaled. The scaling
and range shall be achieved in software to allow the engineer to adjust to his design. RAP's
may be mounted integrally with space temperature sensors or in their own enclosure as
dictated by the performance specification.
1.40.7 Flow Meters

Types proposed shall be chosen to suit the application, static pressure and pressure drop.
The meter range and turn-down ratio shall be chosen such that the full anticipated flow range
is measured within an accuracy of +/-2% or better. No positive displacement types shall be
employed where safety is jeopardised by lack of flow. Flow meters shall supply a pulse
output (max 25Hz at full rated flow) or 4-20mA. All flow metering devices shall be supplied
complete with any output transducers and supplied with individual over-all calibration chart.
The BACS Contractor shall advise the University’s representative of any isolating valves or
bypass circuits thought necessary for instrument service and maintenance of flow.
1.40.8 D.P switches (liquids)

D.P Switches for water applications shall be rated to meet 2 times the static pressure and/or 4
times the working pressure. All wetted parts shall be stainless steel and switch housing
protection to IP67 standard. The range and hysteresis adjustments shall be concealed to
prevent tampering. The mechanical contractor shall install the DP switch and connect
suitable pressure pipes to the service isolating cocks to be provided by him.
1.40.9 Carbon Dioxide (CO2) Sensors

Carbon Dioxide (CO2) sensors shall be duct mounted and shall have a 0-10Vdc or 4-20mA
signal output.
CO2 sensors shall meet the following specification:
i. Measuring range: 0 - 1500 ppm
ii. Accuracy: ± 25 ppm
iii. Operating Temperature Range: -10°C to 40°C
iv. Operating Humidity Range: 10 to 95% RH non-condensing
1.40.10 Air Quality Sensors

Air Quality sensors shall be supplied duct-mounted in the return air from the space. The
sensor shall monitor a mix of gases/impurities to provide a variable 0-10Vdc or 4-20mA
signal. The instrument housing shall be tamper-proof and provide protection to IP67.
1.40.11 Liquid Level Switches

Select by mounting style, liquid type and number of switching levels.
1.40.12 Light Level Sensors

Outside light sensors shall have a range of 10-2000 Lux with an output of 4-20mA and be
mounted in an IP67 enclosure. The sensor shall be mounted in an open position not subject
to shade.
1.40.13 Control Status Relay

Technical Performance: A high impedance relay to produce a dry contact
1.40.14 Control Relay (Solid State)

Technical Performance: 240V a.c., 10amp capacity. Normally open or normally closed to suit
the application, suitable for switching inductive AC loads.

23/37
1.40.15 Control Relay (Electro-Mechanical)

Technical Performance: A high impedance relay to produce a dry contact
1.40.16 Current Sensor (Analogue)

Technical Performance: End-to-end accuracy +/- 2% of full scale at each range.
1.40.17 Load Shedding Devices

The Electrical Contractor shall supply and install Field devices comprising contactors and
relays for load shedding. Slave relays with 24V dc coils shall be energised by the BACS to
achieve load shedding. The Electrical Contractor shall supply and install bypass switches
adjacent to the slave relays.
1.40.18 Automatic Control Valves

(a) Size control valve actuators to provide a tight close off against system head pressures
and pressure differentials.
(b) Size control valves to accommodate a maximum pressure drop to suit the installed
systems.
(c) Provide true feedback as an analog input of actuator position for all proportional air
handling unit and boiler system valves, where specified.
(d) Valve actuators shall be 0-10 V dc control voltage, except where two-position control is
specified.
(e) Floating point control of valves is acceptable only if the control system is equipped to
determine the precise valve positions.
1.40.19 Electric Valve Actuators

Electric valve actuators shall operate from low voltage single-phase power supply and shall
produce an adequate torque for all conditions of operation in the particular service. Visible
indication of valve disc position shall be provided.
Actuators shall be totally enclosed with a minimum degree of protection IP66D in accordance
with AS 1939 and shall mount direct on the valve shaft with no external linkages. A reversible
motor shall drive the actuator through permanently lubricated steel gears running on ball and
needle bearings. Adjustable end travel limit switches, factory set torque limit switches and
motor thermal overload protection shall be incorporated.
Modulating electric actuators shall be fitted with a positioner that positions the valve in
response to the control signal.
All electric actuators shall have provision for position feedback to the BACS controller, where
this is required by the specification for the individual project.
1.40.20 Damper Actuators

Actuators shall be direct coupled for either modulating or two-position control. Actuators shall
be powered by an overload-proof synchronous motor. Provide 0-10 V dc control voltage, for
all proportional applications and either line or low voltage actuators for all two-position
applications.
Damper actuators shall be supplied complete with all necessary mounting brackets and
linkages. The BACS Contractor shall mount and stroke the actuators.
Damper actuators shall be fitted with a spring-return mechanism to provide automatic
positioning in the event of a power failure, where this is required by AS1668 or other
regulations or standards.
All electric actuators shall have provision for position feedback to the BACS controller, where
this is required by the specification for the individual project.

24/37
1.40.21 Pneumatic Transducers

E/P transducers shall have an input 0-10Vdc or 4-20mA giving an output of 3-15psi (0.207-
1.03bar) from a 20psi supply. The transducer shall have a manual adjustment facility and be
fitted with an output pressure gauge.
1.40.22 Variable Speed Drive Controller

Variable speed drive controllers shall be solid-state electronic, variable frequency or variable
frequency/variable voltage type as specified for the individual application, suitable for control
of three-phase, squirrel-cage induction motors.
The input circuit shall consist of an uncontrolled, three-phase, minimum six-pulse rectifier.
The output stage shall consist of three-phase, minimum six-pulse Converter Bridge operating
in Sine Coded Pulse Width Modulated mode. The output shall be a variable frequency of 1 to
50Hz proportional to input signal within 1% and a voltage/frequency ratio to provide the
highest efficiency possible for a centrifugal load.
Controllers shall be enclosed and protected to minimum classification IP33 to AS1939. The
units shall be individually wall mounted and shall not be mounted within switchboards.
Controllers shall be capable of operating continuously at a minimum upper limit of 40ºC
ambient temperature or at a higher ambient temperature determined by local ambient
temperature conditions.
The electromagnetic compatibility (EMC) characteristics and harmonics generated into the
supply system shall be in accordance with the relevant Australian Standards.
Controllers shall be capable of operation on a 415V ± 10% three-phase power supply with a
frequency of 50Hz ± 5%.
Controller efficiency shall be not less than 95% when operating at 50Hz and not less than
84% when operating at 25Hz.
When operating at 50Hz the controller shall not cause an increase in motor losses of more
than 1.5% as compared to motor operation on mains supply.
VSDs shall be provided with the following features:
i. Current Limit Trip
An inverse time current trip shall protect the controller against currents in excess of its rating.
ii. Instantaneous Over-current Trip
An instantaneous over-current trip shall operate in under 50 microseconds to protect the
controller against severe over-currents including phase to phase to earth faults.
iii. Over-voltage Trip
An instantaneous over-voltage trip shall protect the inverter against voltage in excess of its
rating.
iv. Under-voltage Trip
An under-voltage trip shall operate if line voltage drops 15% or more below rated input.
v. Over-temperature Trip
An over-temperature trip shall protect the controller against temperatures in excess of its
rating.
vi. Remote Trip
The controller shall accept an input from a volt free contact to indicate motor overload and
shall shut down if the contact opens.
vii. Trip Limiting
The controller shall automatically cease acceleration or deceleration of the motor when a
controller trip is imminent and shall resume acceleration or deceleration when the condition
returns to normal.
25/37
viii. Power Interruption

In case of power loss or the opening of an input or output power contactor, no damage to the
controller shall result. On restoration of power or re-closing of contacts, the controller shall
automatically return to normal operation.
ix. Start of Rotating Motor
The controller shall be capable of starting a motor that is rotating in forward or reverse
direction with controlled acceleration or deceleration as required.
x. Speed Control Input
The controller shall accept an analogue speed input signal, either 4-20mA dc or 0-10V dc (to
suit remote device output) and one digital input signal with adjustable speed pre-setting which
will override the analogue input control and all manual controls on the VSD for smoke mode
operation.
1.41 Execution
1.41.1 Sequence of Operation
Allowance shall be made for programming each point in the points list summary. Allow for
programming sequences of operation, alarm points, trend logs, totalisers, and energy
management routines.
A customised sequence of operation for each piece of equipment shall be developed in
accordance with the functional description contained in the specification for the individual
project.
1.41.2 Graphics Preparation

The University has a standard design for all BACS graphic displays. Tenderers shall make
themselves aware of this standard and shall confirm that all proposed systems shall conform
to the standard.
Dynamic graphic floor plans (with consistent north-south orientation) shall be prepared,
showing all spaces on the work site and schematics of all controlled systems. Provide intuitive
links so that every controlled input, output, and software point can be accessed from floor
plan and schematic views. Provide point and click active links from the schematics to access
inputs, outputs, trend logs, schedules, alarms, control loops, and any other virtual or physical
control points.
Details of the graphic displays required for each project are given in the specification for the
individual project.
1.42 Commissioning
1.42.1 Commissioning and Programming
Commissioning shall be conducted in accordance with CIBSE Commissioning Code C:
Automatic Controls.
In order to properly commission campus BACS, contractors shall supply all relevant test
equipment, ancillary equipment, monitoring devices, network analysers, protocol
testers/analysers as well as relevant personnel who are able to analyse, interpret and apply
the BACS data obtained. Contractors are required to fully test and commission the BACS, or
sub-systems thereof.
Prior to powering equipment, end-to-end checks of all wiring are required. Copies of proposed
commissioning sheets, for approval by the University’s representative, are to be provided
prior to commissioning. Each and every input and output shall be signed off, and initialled, by
the commissioning party on the commissioning sheets.
Each controller shall be programmed immediately following installation.

26/37
Calibration checks shall be performed of every analogue point. All control loops shall be set
up and tuned during the initial start-up of the systems. A comprehensive print out of the
controller program shall be submitted for review. Each and every control loop shall be signed
off and initialled by the commissioning party on the commissioning sheets.
Point failures shall be rectified and require re-testing of the entire control loop until satisfactory
operation is achieved.
Commissioning sheets shall be provided, showing every sequence of operation. Each control
sequence shall be verified, along with the functionality of each workstation component,
including graphics, reports, trend logs, and so forth. Copies of commissioning sheets shall be
provided to the University’s representative. Each and every sequence will be signed off and
initialled by the commissioning party on the commissioning sheets confirming that sequence
has been tested through complete simulated operation for regular and fire modes
1.42.1.1 Practical Completion:

This section shall be read in conjunction with section 7. In addition, other references to
practical completion, elsewhere in these guidelines, shall also be included.
Contractors are required to:
(a) Demonstrate and confirm that all systems are programmed and operating correctly. See
“Acceptance Testing” below.
(b) Submit CD ROM (including back-up CD ROM) containing up to date copies of the
programs in each controller. Provide the original program disks for all software programs
provided. This includes all third party software and the control manufacturer's controller
interface software and the controls graphics program if provided. Register all software
with the program manufacturer and provide documentation of all software registration.
(c) Submit (4) printed copies of the final programs which shall be “site specific” and include
all point definitions, weekly and annual schedule setting, controller set points and tuning
parameters, and documented programmed sequences of operation. The four (4)-printed
copies shall be in the form of manuals, suitably bound in hard covers, fully indexed and
hierarchically arranged to the approval of the University’s representative. A sample copy
shall be submitted to the University’s representative for approval, prior to the submission
of the final approved version.
LAN addresses for BACS communication shall be identified and documented in the
commissioning report, and incorporated in the BACS Operation and Maintenance Manuals.
1.43 Acceptance Testing

When the contractor is satisfied that the BACS is operating correctly, the University’s
technical representative shall be invited to witness acceptance tests. The cost of such tests
shall be included in the tender of any BACS works or projects.
All devices, BACnet objects, points, systems and sub-systems shall be tested. Other
operational matters such as system trending, alarm generation shall be tested. If there is any
non-conformance or failure, the relevant system or sub-system shall be retested at no
additional cost. All test results are to be suitably recorded and included in the as-built
documentation.
1.44 Documentation
At practical completion, a complete set of “as–built” documents shall be provided. These
documents shall be modified incorporating any changes that occurred during the defects
liability period, this revised documentation should be provided at final completion.
NOTE: The site specific documentation is required to be in a form that any experienced BACS
integrator would be able to easily understand and modify the system as may be required.
Details to be discussed with the University.

27/37
1.45 As-built Documentation

These documents shall represent the BACS as specified, subject to approved modifications,
and include schematic and single line diagrams that represent:
(a) Various systems of the BACS
(b) Final system architecture
(c) Final system configuration, including communication network (with associated interfacing
devices and field devices)
(d) System topology- i.e. a schematic diagram showing all devices (controllers and PCs),
LAN types and network numbers, MAC addresses where available or required.
(e) The physical location of each controller and field device
(f) All input/output (I/O) points
(g) All system settings and set points for proper system operation
(h) Commissioning and acceptance test details and results
The above shall be depicted on the system graphics, thus enabling easy accessibility for
operational and maintenance needs.
1.46 I/O Points List

(a) The I/O point list shall include:
i) Name and description
ii) Display unit
iii) Alarm limit(s)/definition
iv) Each I/O point, the BACnet object description including
v) Object ID
vi) Device ID
(b) To ensure BACnet interoperability, the points lists shall also contain the following:
i) Proposed I/O Names – an I/O naming convention is required to clearly
identify system points. Discuss with the University.
ii) BACnet Object Description – each I/O point shall include the Object and
Device IDs. Care shall be taken not to duplicate device IDs within the campus
environment. Non-standard BACnet objects and properties, including their
structure and data types, are required to be fully documented.
iii) A full listing is required of all BACnet objects used. The list shall include the
device instance, object type (AV/BV/A/BO etc), object instance and
description for objects. This list shall include all set points, control
parameters (proportional bands, differentials, integral gains, time delays, etc),
inputs, outputs, and, all other parameters that are defined as BACnet objects
by the appendices to the BACnet standard in force at the time the project is
commenced (eg soon to include log objects, schedule objects, etc).
1.47 Non-standard BACnet Objects

Any non-standard BACnet object, properties or enumerations utilised, shall be clearly
documented. This shall detail their structure, data types, addresses, any associated lists, or
enumerated values. All BACnet objects within all devices shall be fully accessible to other
BACnet devices on the network. The use of the OUT OF SERVICE flag or any other method
of restricting access to any objects, or settings within any BACnet device, shall be strictly
prohibited. It is an essential requirement that alternative BACnet BACS integrators/suppliers
should be able to address and utilise such non-standard features/usage without requiring
further documents or information.
28/37
Use of any non-BACnet objects within control programs is strictly prohibited unless approval,
in writing, is given by the University.
1.48 Program Records

Complete program descriptions of all control and application software shall be provided for
the BACS installation. These records shall include English language descriptions of control
functions, plant operation, application programs, flow charts and actual source code/files.
1.49 BACnet Gateways

When connecting networks having different protocols, protocol conversion must be provided.
To connect to the University’s BACS, that utilises the BACnet protocol for data
communication, non-BACnet networks will require gateways to convert those protocols into
the BACnet protocol. Gateways are also the devices that are used as entry points from one
network into another.
Whilst the use of gateways is not preferred by the University, applications of these may occur
from time to time. Typically, existing or legacy systems may need to be incorporated within
the campus wide BACnet BACS. Other examples may be proprietary chiller control software
requiring to be incorporated within building air-conditioning system controls or a BACS.
The following is a brief general outline of requirements for gateways:
1.49.1 Scope of Work

Provide a gateway to connect a nominated, or specified system where installed, or to be
installed in a particular building or location, to the BACnet system(s) installed on the UNSW
network. Work shall include provision of all necessary hardware, software, installation works
and testing to achieve a fully operational interface including adding BACnet objects from this
system to an existing BACnet workstation.
1.49.2 Minimum Requirements

The gateway shall map data to and from the system requiring a gateway, providing all
information as BACnet objects in full compliance with the BACnet standard (ANSI/ASHRAE
135-2004). As a minimum the gateway shall provide the following:
i) Connection to BACnet Ethernet or MS/TP.
ii) Full support of the features of the BACnet/IP standard, to allow
connection to the IP network
iii) Full support of the University BBMD Scheme
iv) Mapping of all physical system inputs to BACnet objects, types BI and AI
(read only by other BACnet devices)
v) Mapping of all physical system outputs to BACnet objects types BO and
AO (these must be at a minimum readable by other BACnet devices and
preferably read/write)
vi) Mapping of all system setpoints, parameters and calculated variables to
BACnet object types AV and BV. Adjustable system setpoints and
parameters shall be available as read and write points. (ie they may be
read and written to by BACnet devices)
vii) The minimum BACnet attributes to be supported by all objects are Name
(description) and Present Value.
viii) Full documentation of gateways is required, including manufacturer,
model, operating characteristics, technical arrangements, limitations, as
well as particular information that will enable other parties to easily
understand what has been undertaken and provided. See also Section 7:
Documentation.

29/37
1.49.3 Additional Desirable Features

Additional desirable features include support for the following BACnet functions:
i) BACnet schedules to allow adjustment of the system schedules for this
system from a BACnet operator terminal.
ii) BACnet trend log objects and alarms.
iii) Support for BACnet priority arrays for BACnet object types BO, AO, AV,
BV.
iv) Discuss details with Engineering Services.
1.49.4 Information to be provided with Proposals/Tenders

The following information shall be provided with the proposal/tender:
i) A schedule of all points to be mapped to BACnet objects through the
gateway including:
• Name of the point,
• Units
• Description of the point
• Cross reference to field wiring
• Whether the BACnet object is read only or read/write
• BACnet attributes supported
ii) Confirmation that costs for the full testing of the gateway(s) have been
included. Testing shall include verifying functionality from field wiring back
to a BACnet workstation for all physical points, and a University approved
method of verifying the system responses back to a BACnet workstation
for all other system variables and parameters.
iii) Confirmation that all costs associated with all necessary works to connect
the system to the University Wide Area Network are obtained from the
University’s IT Services Unit.
iv) Confirmation that the system supports BACnet/IP and the University’s
BBMD Scheme.
v) Confirmation that works associated with displaying all of the information
from the gateway on to an existing BACnet workstation, located at a
remote location elsewhere on the University campus is included.
Discuss particular details of this aspect of any works with FM Engineering Section.
1.50 Training
The BACS Contractor shall supply the following training for the University’s Facilities
Management and Engineering staff.
1.50.1 General FM/Engineering staff

(4 people)
i. System structure
ii. Components and applications
iii. Operation of user terminals, keyboards and displays
iv. Adjustments, trend graphs and alarm handling
v. Overrides and passwords
vi. Controller locations
30/37
vii. Control strategy overviews

viii. Other networked components.
1.50.2 Engineer & selected staff

(4 people)
All as above but also including:
i. Configuration of controllers and user terminals software
ii. BACS file structures
iii. Password and engineering utilities
iv. Fault-finding, tuning and maintenance.
The University’s engineer will attend the acceptance demonstrations and the BACS
Contractor shall instruct him in the specific application of the system, the structure and the
control strategies adopted to meet the specification.
Details of proposed training shall be discussed with the University’s representative.
1.51 Campus Wide BACnet System Identification

The use of the BACnet building automation and control system (BACS) communication
protocol requires that the system devices and communication networks be uniquely identified.
This is to ensure that messages are correctly sent and received within the network, and
between devices.
To achieve a unique BACnet system identification regime, three sets of numbers are required
to be allocated within a system. These numbers are respectively allocated to; a device
connected to a particular LAN, a device located in a particular building, and a network within
the building on which the device is installed. The numbers are described as follows:
(a) MAC Address
(b) Device Instance
(c) Network Number
In addition to the above, and to minimise communication traffic, a BACnet Broadcast
Management Device Scheme is also required.
NOTE
The following are brief notes on some common terms used in describing BACnet systems.
A BACnet Device is any communicating device using the BACnet protocol. Therefore, a
small VAV controller is a BACnet device, a large main plant controller is a device and an
operator terminal (PC or other) is a device. Non-communicating peripherals such as sensors,
control valves, damper actuators, etc are not BACnet devices.
An Internetwork is a network made up of several interconnected networks. In BACnet, a
typical BACnet internetwork usually consists of Ethernet, plus MS/TP or ARCnet networks
connected together via a BACnet network router.
A Network is a group of devices (computers, controllers, etc) connected together via twisted
pair cabling, fibre-optic cable, etc.
A Local Area Network (LAN) is a distance-limited communication network for transferring data
between computers or other devices. In BACnet, there are four common LAN types:
Ethernet, ARCnet, point to point (PTP), and master slave/token pass (MS/TP). Each BACnet
LAN must have a unique LAN number assigned to it, in the range 0 to 65535, ie 216.
Assignment of LAN numbers (frequently referred as network numbers) is independent of
assignment of Device Instances (device numbers).
The system identification can only consist of numeric integers (up to the number 4,000,000).
Alphanumeric identifiers cannot be used.

31/37
1.52 MAC Address

The MAC Address is an abbreviation for Media Access Control Address. In BACnet, each
device has a unique MAC Address/Network Number combination that identifies it on the
Internetwork. For example, every device in an Ethernet network has a unique MAC address
for that network. In the case of Ethernet, it is usually embedded within the Network Interface
Card (NIC) and allocated under the ISO convention to guarantee worldwide uniqueness.
For other BACnet networks, the MAC address of devices is usually adjustable, for example
via DIP switches. These usually come with factory default settings (often 0 or 1). The MAC
address is for devices located on an MS/TP LAN. Each MS/TP LAN can have 128 devices.
MAC addresses on any MS/TP LAN are therefore given a MAC address from 01 to 128
(without repetition).
This means that every individual MS/TP LAN has the same selection of MAC numbers, i.e. 01
to 128. Clearly these numbers are only unique to a LAN.
For example, if there is a BACnet MS/TP network in Building A, it can have up to 128 devices
connected to it. If there were say 20 devices connected to this MS/TP network, they could
have the MAC addresses set from 1 through to 20. If there was an MS/TP network in Building
B, also with 20 devices connected to it, these could also be numbered from 1 through to 20,
without any operational problems, because they are physically connected to a different
network.
1.53 Instance Device

In BACnet, the Device Instance is the allocated device number that uniquely identifies a
device on any BACnet internetwork. For example, if the UNSW has BACnet systems within
several buildings, and these are connected together via the UNSW WAN, then there may only
be one device with the device instance (device number) of one (1), only one with device
instance two (2), etc.
Device instances are adjustable by the supplier/installer/service engineer to meet the
requirements of any site or client and range up to 4,000,000 in integer steps. Associated with
each device there can be a number of system ‘points’.
It is crucial that each system device is allocated a unique number to specifically identify it.
Clashing Device Instances will lead to system malfunction.
To provide a consistent, unique Device Instance identity, the following Device Instance
descriptor requirements shall be strictly adhered to: -
(a) The existing generic alphanumeric Kensington Campus grid reference, utilising the A-
O, 1-28 grid reference system shall be used as the basis of depicting the device
instance.
(b) An off-main campus regime requires a different basis of identification
The Device Instances Numbering is as follows:
The device number consists of a seven-digit numeral. This is known as the device instance.
The first four numbers, from left to right represent the building location.
The vertical alphabetic location letters are given a numerical value. These range from A to O.
Starting at A=1, each subsequent letter in the alphabet is increased in value by 1.
To avoid number clashes, a fixed value of 10 is added to the alphabetical locator e.g.
C≡3+10=13
The second two-digits represent the horizontal numeric grid locators. These range in value
from 1 to 28.
NOTE:
Although adding complication to the BACS identification, subsections within a grid area (e.g
A, B, C, D, E, F, G) can be identified by adding the value 10 for each letter, starting with

32/37
A=30. The reason for starting with 30 is to avoid clashing with numbers within the range of the
horizontal grid (i.e. 1-28).
Where possible, to minimise complications, the use of grid area subsections is to be avoided.
The last four digits represent the device number within a particular building. The number
ranges from 000 to 999. This means that there is an allowance of 1000 BACnet devices per
building.
Example
The Roundhouse location is designated as E6 on the campus grid.
The Device Instance range would be, E6000 to E6999
The E6 needs to be converted to a numeric value as per the above regime.
a) E≡5+10=15
b) 6=06
Therefore, E6≡1506, is the building descriptor.
The range 000 to 999 represents the range of device numbers available for any building.
For the Roundhouse, the Device Instances available are 1506000 to 1506999.
For example, if a device has a Device Instance of 1506 020, this numeric descriptor
represents:
Building Device
Descriptor Descriptor
Note
If the building location was required to be identified more precisely, say E6G, then the above
building descriptor E6 would need to be modified to reflect this. From the above defined
subsection values, subsection G=90.
Therefore, E6G ≡ 1506 (representing E6), plus the addition of 90 (representing the subsection
G) to the last two digits. Hence, the building descriptor for location E6G ≡ 1596.
1.54 Network Number

As previously indicated, each BACnet LAN has a unique LAN number assigned to it, in the
range 0 to 65535. This is a very large number of LANs and far more than would ever be used
by the University. A six-digit number has been selected to represent the network numbers for
the University.
These numbers are allocated to BACnet LANs; some of these LANs will concurrently also be
part of the campus wide network (ie UNSW IT Services LAN). The campus wide LANs utilised
would need to be given this BACnet Network Number, to achieve a consistent and unique
campus-wide BACnet BACS identification regime.
1.55 Allocation of Network Numbers

The basic numbering is based on utilising the University grid referencing to define a campus
area. The relevant alphanumeric grid referencing descriptors defines a grid area. Each grid
area is allocated a total of ten (10) LANs. As there are a total of 14 rows (A-O) and 28
columns (1-28), there are a total of 14 x 28 = 3920 BACnet LANs defined. There is a defined
capacity of 280 LANs per row and 140 LANs per column.
In particular, commencing from grid area A-1, the allocated network numbers are 1-10; each
subsequent area is allocated another ten numbers, sequentially. For example, A-2 has
network numbers 000011-000020, A-28 has network numbers 000271-000280, B-1 to B-28
has a range from 000281-000560, C-1 to C-28 has a range from 000561-000840,O-1 to O-28
has a range of network numbers from 003641 to 003920.
Hence, for the Kensington Campus, the range of network numbers is from 1 to 3920.

33/37
NOTE
As the network number is a six-digit number, for any ‘raw’ number that is less than six digits,
zeroes must be placed before the numbers to make up the six digits.
Example
The AGSM building has a grid reference of G27.
The network number range is found as follows:
(a) The building descriptor is G27.
(b) The LAN number range is from 001941 to 001950, to serve all buildings in grid area
G27.
(c) MAC addresses range from 01 to 128 for each LAN in the building.
1.56 BACnet Broadcast Management Device (BBMD) Scheme

The BBMD scheme is the required method of allowing BACnet systems on campus to
communicate. The scheme serves to provide full BACnet Appendix J “IP” support (rather than
tunnelling), and keeps network traffic down to a minimum by arranging data to be routed only
to, or between, relevant network interface units (NIUs) requiring the data to be sent or
received.
On each logical or virtual network, with BACnet equipment connected (excluding servers and
PCs), there will be one BBMD. This connects all BACnet equipment on this logical network to
the rest of the IP network.
Each BBMD must be programmed with the identities of all other BBMDs on campus. If this is
not done, full BACS communication will not be achieved.
In order to ensure that the University has a properly documented BACS, which can be
modified as may be required, all BBMDs added to the BACS must be fully described and all
information included in the BBMD Register below.
BBMD Register
Full Part UNSW IP Address Device UDP Virtual
Location Manufacturer No. Network Instance No. Network
Port ID No.
*
E6 Delta 12345 1309- 129.94.38.00/24 1506555 XXXX VLAN-
C4- 11
PP5-18
* UNSW network port ID labelling has the following information as standard: Communication
Room No.for that cabling – Cabinet No – Patch Panel Number – Port Number. An outlet may
be identified as 1309-C4-PP5-18 which translates to comms room 1309, cabinet 4, patch
panel 5, port 18. If there is a problem this (in combination with the building information)
uniquely identifies the port so IT Services Unit can identify the switch and check if there is a
switch port problem, a patch problem, or a cabling problem.
NOTE
The above BBMD Register data are indicative and not representative of actual site
requirements.
1.57 Off-Campus System Identification

The off-campus system identification would be as follows:
TBA

34/37
1.58 Summary – UNSW Data Network

The University of New South Wales has an existing data and phone network which connects
all buildings on campus. The data network infrastructure consists of three primary elements:
The Core Network - consists of equipment in a number of locations providing connections to
the Internet and remote campuses and to all buildings on Kensington Campus.
The Building Backbone - each building is connected via a fibre optic cable (all buildings
have a multimode connection and most buildings now have a dual single mode fibre
connection) to one of the core locations. Within each building, fibre optic and UTP tie cables
are run to equipment cabinets located on the various floors. Connections between buildings
run at 1000Mbits/sec (1Gbps)
Floor Cabling – from each cabinet location Unshielded Twisted Pair (UTP) cabling (usually
CAT5, 5e or 6) is run to the RJ45 outlet in the office, plantroom or laboratory. Data rates of
10-100MBits/sec are the standard to the user. RJ45 outlets have been installed in various
locations to provide network connectivity for BACnet control equipment. New outlets can be
installed on a fee for service basis as required. Orders can be placed via the RWS system. If
cabling is to reticulate to the UNSW network, work must be completed by UNSW IT Services.
1.58.1 Active Equipment

Users are connected to the network via Cisco switches (either 10mb or 100mb connections).
Additional connections will have a cost associated for the switchport and possible costs
associated if additional outlets are required.
1.58.2 VLAN
A Virtual Local Area Network (VLAN) extending across Kensington Campus has been setup
for BACnet (VLAN 323) and Energy Management (VLAN 11). Similar Vlans exist or can be
created at all UNSW remote campus/ sites. Facilities manage the allocation of IP addresses
for these VLANS.
These Vlans have Access control lists (ACL’s) applied to provide security for the BACnet
equipment. To make modifications to the ACL’s, contact Facilities Management who will
request any changes via Requisition for Works and Services (RWS).
1.58.3 Initial Activation & Ongoing Support

Installed outlets are not activated until specifically requested by the user. The procedure to
have an outlet activated is as follows:
To activate an outlet:
• Contact UNSW IT Services – Service Desk - Phone 9385-1333 (internal
extension x 51333) or email servicedesk@unsw.edu.au
• The following information will be required by the Service Desk:
Caller, Full name
Phone number (alternate number if any eg mobile phone, second
desk phone)
Email address
Building & room number of port to be activated
Full port outlet details (outlets are labelled with an ID number)
Vlan number or details
IP address of machine
Who can provide access to site to test and contact details for this
person.

35/37
• The nominated contact will be advised on completion of the activation.

To Report a fault:
• Contact UNSW IT Services - Service Desk
• The following information will be required by the Service Desk
Caller, Full name
Phone number (alternate number if any eg mobile phone, second
desk phone)
Email address
Building
Room Number
Accurate and detailed description of the request or problem and
tests/diagnosis already done.
Full port outlet details (outlets are labelled with an ID number)
Vlan number or details
IP address of machine
Is this a new installation?
When was it last working?
Alternate contact person in the area and phone number
Who can provide access to site to test and contact details for this
person
• The nominated contact will be phoned if additional information is required or
to advise of resolution of the problem.

36/37
1.59 Basic BACnet System Identification Diagram

Alerton Web Server Alerton BACnet Server
Security Server Room Security Server Room
Remote
User
Firewall
UNSW Ethernet VLAN 323 (BACnet)
Internet
BACS Hub/Switch Maintained
by UNSW IT Services Unit
User Workstations
* IP Address
* MAC Address
* Device Instance
Network Interface Unit or other
NIU
* IP Address device performing this function
* MAC Address Network Number Network Number
* Device Instance
Modbus BACS Field
Device Controller
RS485 Modbus LAN
RS485 MS/TP LAN

Modbus * Device Instance
Address * MAC Address
29 Devices 125 Devices

Max. Max.

37/37

BACNet BMS Overview

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BACNet BMS Overview

Uploaded by

Copyright:

Available Formats

Last Update July 2005

APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM –

UNSW DESIGN & CONSTRUCTION REQUIREMENTS – WEB ENTRY PAGE

SECTION B – DEVELOPMENT & PLANNING

SECTION C – ARCHITECTURAL REQUIREMENTS

SECTION D – EXTERNAL WORKS

SECTION E.1 – HYDRAULIC SERVICES

SECTION E.2 – MECHANICAL SERVICES

SECTION E.3.1 – ELECTRICAL SERVICES

SECTION E.3.2 – LIGHTING

SECTION E.3.3 – SPECIAL SYSTEMS

SECTION E.3.4 – HIGH VOLTAGE

SECTION E.4 – COMMUNICATIONS

SECTION E.5 – LIFTS

SECTION E.6 – FUME CUPBOARDS

SECTION F – SPECIFIC AREA REQUIREMENTS

APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM – SCHEDULE OF

UNSW Design & Construction Requirements (Rev 4.1)

1.9 Operator Interfaces................................................................................................ 12

1.40.3 Differential Pressure switches........................................................................ 22

1.52 MAC Address..................................................................................................... 32

APPENDIX 2 – CONCRETE FOR STRUCTURES

APPENDIX 3 – UNSW CONTROL SYSTEM STANDARDS HVAC

APPENDIX 4 – DOCUMENT REQUIREMENTS

APPENDIX 5 – UNSW STANDARD PRELIMINARIES

APPENDIX 6 – SECURITY SYSTEMS

APPENDIX 6 – SECURITY SYSTEMS

UNSW Design & Construction Requirements (Rev 4.1)

APPENDIX 1 BUILDING AUTOMATION AND CONTROL SYSTEM – SCHEDULE

UNSW Design & Construction Requirements (Rev 4.1)

1 BUILDING AUTOMATION AND CONTROL SYSTEM

UNSW Design & Construction Requirements (Rev 4.1)

• Provision of maintenance manuals and as built drawings.

1.3 Preliminary Proposal Review

UNSW Design & Construction Requirements (Rev 4.1)

1.5 Installation Standards

vi) Building Code of Australia.

UNSW Design & Construction Requirements (Rev 4.1)

1.5.1 Fixings and Supports

UNSW Design & Construction Requirements (Rev 4.1)

1.5.2 Building penetrations

1.6 BACnet Network Wiring

1.7 Power Supplies

1.8 Electromagnetic Interference (EMI)

UNSW Design & Construction Requirements (Rev 4.1)

1.9 Operator Interfaces

1.13 Proprietary Brand Name References

UNSW Design & Construction Requirements (Rev 4.1)

1.14 Relocation and Re-use of Existing Equipment

1.16 BACnet Conformance

1.17 Change Management Procedures

UNSW Design & Construction Requirements (Rev 4.1)

1.17.1 Urgent Changes

1.17.2 Temporary Changes

1.17.3 Remote Changes

1.17.4 Setpoints and Operating Time Schedules

1.17.5 Operations Log Book

1.17.6 Backup Copies of System Files

1.19 Auxiliary Communication Devices

1.20 Communication Mechanism

1.22 Operator Interface

1.23 BACnet Conformance