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

http://notessrv.chan.unsw.edu.au/faciliti.nsf/pages/conguide?OpenDocument

http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_a.pdf

http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_b.pdf

http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_c.pdf

http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_d.pdf

http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_e_1.pdf


http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_e_3_1.pdf







http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/se_f.pdf


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



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 UNSW Design & Construction Requirements (Rev 4.1) 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


http://notessrv.chan.unsw.edu.au/Faciliti.nsf/pages/man/$FILE/app_2.pdf







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



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.



• 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.



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.



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.



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;



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.



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.



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.



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.


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 Management

VLAN 11 129.94.38.000/24

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



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.



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.



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.



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.



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.



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.



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.



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.



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.



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. UNSW Design & Construction Requirements (Rev 4.1) 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.



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.



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.



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.



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



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.



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



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:

Note

If the building location was required to be idbuilding descriptor E6 would need to be mosubsection values, subsection G=90.

Therefore, E6G ≡ 1506 (representing E6), pG) to the last two digits. Hence, the building

1.54 Network Number As previously indicated, each BACnet LAN range 0 to 65535. This is a very large numbby the University. A six-digit number has bethe University.

These numbers are allocated to BACnet LApart of the campus wide network (ie UNSWwould need to be given this BACnet Networcampus-wide BACnet BACS identification r

1.55 Allocation of Network NumbeThe basic numbering is based on utilising tharea. The relevant alphanumeric grid referearea is allocated a total of ten (10) LANs. Acolumns (1-28), there are a total of 14 x 28 capacity of 280 LANs per row and 140 LAN

In particular, commencing from grid area A-subsequent area is allocated another ten nunetwork numbers 000011-000020, A-28 hahas a range from 000281-000560, C-1 to Chas a range of network numbers from 0036

Hence, for the Kensington Campus, the ran

UNSW Design & Construction Requirem

Building

Descriptor

entified more prdified to reflect t

lus the addition descriptor for lo

has a unique LAer of LANs and en selected to re

Ns; some of the IT Services LANk Number, to acegime.

rs e University gridncing descriptors there are a tota= 3920 BACnet s per column.

1, the allocated mbers, sequent

s network numbe-28 has a range 41 to 003920.

ge of network nu

ents (Rev 4.1) 33/37

Device

Descriptor

ecisely, say E6G, then the above his. From the above defined

of 90 (representing the subsection cation E6G ≡ 1596.

N number assigned to it, in the far more than would ever be used present the network numbers for

se LANs will concurrently also be ). The campus wide LANs utilised

hieve a consistent and unique

referencing to define a campus s defines a grid area. Each grid l of 14 rows (A-O) and 28

LANs defined. There is a defined

network numbers are 1-10; each ially. For example, A-2 has rs 000271-000280, B-1 to B-28 from 000561-000840,O-1 to O-28

mbers is from 1 to 3920.


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 Location

Manufacturer

Part No.

UNSW Network Port ID *

IP Address Device Instance

UDP No.

Virtual Network No.

E6 Delta 12345 1309-C4-PP5-18

129.94.38.00/24 1506555 XXXX VLAN-11

* 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



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 [email protected]

• 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.



• 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.



1.59 Basic BACnet System Identification Diagram

Internet

Firewall

RemoteUser

Alerton Web ServerSecurity Server Room

Alerton BACnet ServerSecurity Server Room

UNSW Ethernet VLAN 323 (BACnet)

User Workstations

NIU Network Interface Unit or otherdevice performing this function

BACS FieldController

RS485 M

S/T

P LA

N

ModbusDevice

RS485 M

odbus

LAN

* Device Instance* MAC Address

Network Number Network Number

* IP Address* MAC Address* Device Instance

* IP Address* MAC Address* Device Instance

ModbusAddress

29 DevicesMax.

125 DevicesMax.

BACS Hub/Switch Maintainedby UNSW IT Services Unit


BACNet BMS Overview

Documents

Transcript of BACNet BMS Overview