Data Network Resource
       Earn on the Web


BACnet



Introduction


In June 1987 the American Society of Heating, Refrigeration and Air-conditioning Engineers (ASHRAE) set up the Standard Project Committee 135 (SPC 135) to develop a data communications protocol for Building, Automation and Control Networks (BACnet). As well as becoming a national standard in 1995 (ASHRAE/ANSI 135-1995) and then updated in 2001, in many countries it also became an ISO standard 16484-5 in January 2003. BACnet also became a European standard CEN TC 247 in 2003.

Each control system has its own method of communicating to its controllers and to the front end management systems. Owners feel locked in to proprietary systems which cost a great deal to interface to common front ends so BACnet was developed to be 'Open Protocol' meaning that it is free from any licensing costs although it is not open source as ASHRAE maintain control over it.

Other building protocols can be converted to BACnet so that BACnet can be used as the main protocol receiving and sending data to other systems, be they heating, ventilation, lighting, security, lift or fire and life safety systems.

Structure


Objects


Objects are data structures designed to represent the devices, the groups of information related to software processes, physical inputs and physical outputs. An Object has a set of properties that are used to obtain or send information or commands. A property consists of the properties such as the following examples that can either be read-only or read-write:
  • Object_Identifier - mandatory
  • Object_Name - mandatory
  • Object_Type - mandatory
  • Present_Value
  • Status_Flags
  • High_Limit
  • Low_Limit
There are altogether 128 such properties that have been defined however the first three above are required for every Object. These Properties can be set during the device's installation and/or some can be manipulated during the operation of the device. Manufacturers are able to create their own Properties but these then make their devices non-standard.

There are 50 standard Object Types:
  • Access Credential
  • Access Door
  • Access Point
  • Access Rights
  • Access User
  • Access Zone
  • Accumulator
  • Analogue Input
  • Analogue Output
  • Analogue Value
  • Averaging
  • Binary Input
  • Binary Output
  • Binary Value
  • Bit String Value
  • Calendar
  • Character String Value
  • Command
  • Credential Data Input
  • Date Pattern Value
  • Date Value
  • Date Time Pattern Value
  • Date Time Value
  • Device
  • Event Enrollment
  • Event Log
  • File
  • Global Group
  • Group
  • Integer Value
  • Large Analogue Value
  • LifeSafetyPoint
  • LifeSafetyZone
  • Load Control
  • Loop
  • Multi-state Input
  • Multi-state Output
  • Multi-state Value
  • Network Security
  • Notification Class
  • Octet String Value
  • Positive Integer Value
  • Programme
  • Pulse converter
  • Schedule
  • Structured View
  • Time Pattern Value
  • Time Value
  • Trend Log
  • Trend Log Multiple
Each Object Type will contain data in a specific type. There are 13 data types that can be mixed together into Constructed Data Types or linked together in Arrays of the same data type. These data types are as follows:
  • NULL - no value
  • Boolean - true or false
  • Unsigned integer - 1 byte, 2 byte, and 4 byte
  • Signed integer - unlimited
  • Real - single precision floating point
  • Double - double precision floating point
  • Octet string - unlimited in length
  • Character string - various character sets are supported
  • Bit string - unlimited length
  • Enumerated
  • Date - 4 bytes containing year, month, day of month, day of week
  • Time - 4 bytes containing hours, minutes, seconds, hundredths of second
  • BACnetObjectIdentifier - 32 bit string - 10 bits for Object type, 22 bits for Object Instance
A BACnet Device can have any number and combination of these Objects in addition to one representing itself.

Application Services


Application Services are the services carried out by the server for the client, these are the messages containing parameters that devices use to convey information to one another, announce events or issue commands. There are 38 of these services segregated into classes, these classes of Application Services and their services are as follows:
  • Alarm and Event Services - apart from UnconfirmedCOVNotification, a reply is expected from each of these requests
    • AcknowledgeAlarm
    • ConfirmedCOVNotification - COV is Change of Value
    • ConfirmedEventNotification
    • UnconfirmedEventNotification
    • GetAlarmSummary
    • GenErollmentSummary - Requests a list of "event" (possible error) generating objects
    • GetEventInformation
    • LifeSafetyOperation
    • SubscribeCOV
    • SubscribeCOVProperty
    • UnconfirmedCOVNotification
  • File Access Services - files represent group databytes of arbitrary length and meaning, and Atomic means that only one read or write operation can occur at any one time. Files are vendor proprietary rather than defined by BACnet.
    • AtomicReadFile
    • AtomicWriteFile
  • Object Access Services - These messages contain the object and property identifiers that need to be read and then sent back by the device.
    • ReadProperty - Mandatory for every device and contains the message number, the ID of the required Object and the ID of the required Property.
    • ReadPropertyConditional
    • ReadPropertyMultiple
    • ReadRange
    • WriteProperty
    • WritePropertyMultiple
    • CreatObject
    • DeleteObject
    • AddListElement
    • RemoveListElement
  • Remote Device Management Services
    • DeviceCommunicationControl - tells a device to stop/start accepting network messages
    • ConfirmedPrivateTransfer
    • UnconfirmedPrivateTransfer
    • ReinitializeDevice
    • ConfirmedTextMessage
    • UnconfirmedTextMessage
    • TimeSynchronization
    • UTCTimeSynchronization
    • Who-Has - which device has a particular Object
    • I-Have
    • Who-Is
    • I-Am
  • Virtual Terminal Services
    • VT-Open - open a session with a remote device
    • VT-Close
    • VT-Data - send text from one device to another
The great variety of Objects and Services means that each device is provided with a Protocol Implementation Conformance Statement (PICS) so that a designer is able to select the correct device for a system.

Networking BACnet


Overview


In the 1990s when BACnet was being developed three existing LAN technologies were chosen to transport BACnet messages, these were ARCNET (a token-bus system running at 2.5Mbps on IBM Type 3 100 ohm impedance cable), Ethernet and Echelon's LonTalk. For dial-up the BACnet committee developed the Point-to-Point (PTP) protocol for EIA-232 and for EIA-485 a Master-Slave/Token-Passing (MS/TP) protocol was developed. In addition, BACnet/IP was created to enable greater flexibility across many media types where each BACnet device is an IP node. This is different from tunnelling BACnet messages through IP where the BACnet devices need know nothing at all about the IP infrastructure that they are using. Also, BACnet has the capability of running over ZigBee (based on 802.15.4).

In order to accommodate native BACnet devices on separate and different networks, a Network Layer has been developed that provides a way of labelling each network with a unique number allowing the communication of messages between networks. These networks are connected via BACnet routers that can translate between messages on say Ethernet to another network type such as MS/TP.

In order to communicate between BACnet devices and non-BACnet devices, gateways are required which are complex translation devices that not only have to translate between message formats but may also have to cope with different network types.

BACnet over MS/TP


The standard merely specifies that RS-485 (a two-core screened cable, with true differential signals on the two cores) can be used, it does not state whether it should use screened or unscreened cable, twisted or untwisted pairs, use 2 wires or 3 wires, or whether its inputs should be floating or referenced to a ground potential.

BACnet over Ethernet


BACnet uses the device's MAC address to identify itself and a BACnet over Ethernet installation can coexist on the same LAN as a BACnet over IP installation.

IP Tunnelling


BACnet devices that do not understand IP but sit on an Ethernet network can have their messages picked up by an Annex H Router (Annex H of the BACnet specification describes the tunnelling device which is also known as a BACnet/Internet Protocol Packet-Assembler-Disassembler (PAD)) which does understand IP. The BACnet message sits within the BACnet Link Layer Service Data Unit (LSDU) structure within the Ethernet frame. The Annex H Router then extracts the LSDU and forwards it wrapped in a UDP datagram (using port 47808) to a normal IP router. In principle, an Annex H Router at the receiving end receives the UDP datagrams and strips away the IP portion releasing the BACnet messages in the LSDU to be sent to the receiving BACnet device. The TCP port 47808 is also reserved for BACnet/IP however this is currently unused.

An Annex H router can have two network ports or just one port. The two-ported version sits inline between the BACnet Ethernet network and the IP Ethernet network. BACnet devices send Ethernet frames to the Annex H router which takes the messages and places them within IP datagrams for forwarding over the IP network. The Annex H router that just has one network port receives the BACnet Ethernet frames on this port and sends out the IP datagrams on the same port so that the BACnet messages traverse the same Ethernet network twice. See below for an illustration of a one-port Annex H router in operation:

Annex H Routers

In order to know where to forward the packets, each Annex H router has to know the IP address of every other Annex H router. Each Annex H router has to contain a list of IP addresses of all the other Annex H routers. When an Annex H router is added to, or removed from the IP network, each Annex H router has to have its list of IP addresses updated and there can only be a maximum of 31 in the list.

BACnet/IP


With BACnet over IP (Annex J), BACnet devices connected directly to the IP network and use their IP address as if it were a MAC address as far as identification is concerned. The IP network is viewed as a virtual data link and is referred to as the BACnet Virtual Link Layer (BVLL). The BVLL has a packet structure and contains a set of control messages that manage the interaction of BACnet with virtual networks such as IP, ATM, Frame Relay, SONET and ISDN, although IP is nowadays the predominant one. The BVLL modifications to the BACnet data mean that although the same UDP port is used for the resulting datagrams, the BACnet/IP datagrams are not compatible with the IP tunnelling datagrams.

The BVLL packet structure follows the UDP header and is as follows:

BVLL

  • Type - 0x81
  • BVLC Function
    • 0x01 - Write Broadcast Distribution Table
    • 0x02 - Read Broadcast Distribution Table
    • 0x03 - Read Broadcast Distribution Table ACK
    • 0x04 - Forwarded NPDU with optional Originating Device IP address and Port included in BVLL header
    • 0x05 - Register Foreign Device with expiration timeout (Time-to-live) in seconds
    • 0x0a - Original-Unicast-NPDU used to send directed NPDUs to another BACnet/IP device or router. Optional Originating Device IP address and Port NOT included in BVLL header.
    • 0x0b - Original-Broadcast-NPDU used by devices (except foreign devices) to broadcast messages on B/IP networks. Optional Originating Device IP address and Port NOT included in BVLL header
  • BVLL Length
  • IP address of Originating Device - optional depending on BVLC Function Code
  • Port number of Originating Device - optional depending on BVLC Function Code
  • NPDU - Network Layer Protocol Data Unit (see below)
BVLL

  • Version - Always 0x01
  • NPCI Control - Network Protocol Control Information is variable and occurs if the NSDU is a Network Message or an APDU
  • DNET - Destination Network where 65535 is a broadcast.
  • DLEN - Destination MAC address length, if DLEN is 0, and DNET is 0xffff, then the packet is a Global Broadcast If DLEN is 0, and DNET is not 0xffff, then the packet is a Remote Broadcast to the BACnet Network indicated by the DNET.
  • DADR - Destination MAC address
  • SNET - Source Network which can be between 1 and 65535.
  • SLEN - Source MAC address length.
  • SADR - Source MAC address.
  • Hop Count
  • NSDU - Network Service Data Unit - depending on the Control Byte of the NPCI, The NSDU can be either an APDU (If Bit 7 of the Network Layer Protocol Control Information byte is a 0) or a Network Layer Message (If Bit 7 of the Network Layer Protocol Control Information byte is a 1).
BACnet devices frequently broadcast messages to all other BACnet devices, this is a problem if these messages are encapsulated in IP and then routed across an IP network because routers do not normally broadcast IP datagrams. There is therefore the provision of the BACnet Broadcast Management Device (BBMD).

BBMD

The BBMD takes the BACnet broadcast and unicasts it to a BBMD on the remote network. The remote BBMD then strips off the unicast wrapper and broadcasts the BACnet message on the remote network as originally intended. This flexibility allows the concept of Foreign Device Registration where any BACnet device can join the BACnet internetwork from anywhere. This foreign device registers first with the BBMD and then may not only receive broadcasts but also request broadcasts to be created on its behalf.

References and Further Reading



Valid HTML 4.01 Transitional




Earn on the Web    


All rights reserved. All trademarks, logos, and copyrights are property of their respective owners.