Basics of BACnet

Overview of Training
Building Automation Protocols
• History of BACnet
• What is BACnet
BACnet Architecture
BACnet Terminologies
BACnet Objects & Properties
BACnet Services
BACnet Profiles
BACnet Test Conformance & Process
Development Approach
Building Automation
Building Automation means “Integrated Management of Buildings” i.e. a solution of many sub-
systems and plants perfectly integrated among them
In a system where a BA solution is implemented there will coexist many subsystems such as,
heating and conditioning systems, management systems of electricity and lighting, video supervi-
sion, security, fire fighting, multimedia, etc
A particular control reader allows you to light, heat or air-condition a room just when the staff
enters it. When the room is empty everything is set in Stand-by.
In order to control all the subsystems of the plant it is necessary to have an integrated supervi-
sion system
The BAS (Building Automation System)functionality reduces building energy and maintenance
costs when compared to a non-controlled building. A building controlled by a BAS is often re-
ferred to as an intelligent building system.
Building Automation Protocols in market
LonTalk
• LonTalk is a protocol optimized for control created by Echelon Corporation for networking
devices over media such as twisted pair, powerlines, fiber optics, and RF. It is popular for
the automation of various functions in industrial control, home automation, transportation,
and buildings systems such as lighting and HVAC.
• All LonWorks devices communicate with each other using a standard protocol that's em-
bedded in Neuron Chips.

Modbus
• Modbus is a serial communications protocol published by Modicon in 1979 for use with its
programmable logic controllers (PLCs). It has become a standard communications protocol
in industry, and is now the most commonly available means of connecting industrial elec-
tronic devices
• The number of data types is limited to those understood by PLCs .
• Variations exist between different implementations. Common one are
- Support of different data types
- Different protocol extensions (16 bit slave address, 32 bit data size, word swapped data)
Challenges faced before BACnet
Proprietary products from different manufacturers and vendors are difficult or sometimes impos-
sible to integrate together. Building automation owners had no choice but to stick to ‘one ven-
dor’
Building owners feel trapped, locked-in to products made by a single manufacturer
Even though there are ways to interconnect products from different vendors in a
system through an ‘interface’, but developing such an interface require co-operation, knowledge
of proprietary standards.
In practice these systems have been very costly to implement and support, as the various sys-
tems they interface with evolve and change independently
The most important challenge was: how to achieve ‘interoperability’?
Benefits of Interoperability
Lower cost:
Most engineers and other building owners prefer to work with a small group of vendors or even
a single vendor, but desire the economy of competitive pricing during bidding. If all systems and
devices are interoperable, they can mix and match and select products in a competitive environ-
ment to create the best solution at the lowest cost.
Single point of control:
Users are interested in establishing a single point of control over all building systems, from HVAC
to lighting to access control, with an operator monitoring the whole system from the control
room. This arrangement greatly simplifies building management and creates synergies among
various building control systems to save energy and perform profiling
Flexibility and scalability:
Building owners always look for better options to replace any existing obsolete product in their
BAS. Interoperable products can be easily integrated in the existing running system without any
danger of affecting its functionality
Before BACnet After BACnet
A manufacture A manufacture

B manufacture C manufacture
B manufacture C manufacture
A proprietary protocol
B proprietary protocol Standard BACnet proto-
C proprietary protocol
col
Evolution of BACnet
Around early 1980, building owners and operators were trapped, locked-in to products made by
a single manufacturer and were looking for an open standard protocol. The industry needed a
leader to step forward and set a standard.
The resulting unrest prompted ASHRAE to form SPC-135P, a committee with the express charter
to investigate and develop a new standard to address their issues. Through a consensus process
involving nearly every major vendor of controls in North America, as well as academics, end
users, consulting engineers and government interests, the BACnet standard was born after
around nearly nine years of effort and brain storming.
ASHRAE's board of directors voted to approve the standard and publish ASHRAE 135-1995 in Sep-
tember, 1995. Since ASHRAE is an approved ANSI standards body, the standard was also submit-
ted to ANSI and BACnet became ASHRAE/ANSI Standard 135 in 1995 and ISO 16484-5 in 2003.
The Method of Test for Conformance to BACnet was published in 2003 as ASHRAE Standard
135.1.
BACnet is under continuous maintenance by the ASHRAE Standing Standard Project Committee
135
What is BACnet?
BACnet is the data communication protocol for Building Automation and Control Networks.
It is an ASHRAE, ANSI, and ISO standard protocol.
A data communication protocol is a set of rules that control the exchange of data over a network.
These rules have to be implemented consistently across all types of devices, and by all device
manufacturers whose products are connected to a common network.
BACnet was designed specifically to meet the communication needs of building automation and
control systems for applications such as HVAC, lighting control, access control, and fire detection
systems
Features of BACnet Protocol
Interoperability of devices and systems from various vendors
BACnet is independent from any specific hardware, operating system or software platform
No fixed architecture
Object model is easily extended
Broad participation in its development
Single point of control
Competitive system expansion
Eliminate fear of being “locked in”
Possibility of integrating all BAC functions
Low cost
Provides various data link and network options
BACnet is an Open standard Protocol
The following table reflects why BACnet is considered as an Open Protocol
Is BACnet protocol used by multiple vendors? Yes

Is BACnet protocol “freely” distributed? Yes

Is BACnet protocol hardware chip independent? Yes

Is BACnet protocol software independent? Yes

Is the BACnet standard developed in an “open” manner Yes

BACnet Architecture
BACnet is based on a four-layer collapsed architecture that corresponds to the physical, data link,
network, and application layers of the OSI model as shown in below figure.
Following are the features of BAC networks that can be used to evaluate the appropriateness of
the layers in the OSI model:
• BAC networks are local area networks.
This is true even though in some applications it is necessary to exchange information with devices in a
building that is very far away. This long-distance communication is done through telephone networks.
The routing, relaying, and guaranteed delivery issues are handled by the telephone system and can be
considered external to the BAC network.
• BAC devices are static.
They don‘t move from place to place and the functions that they are asked to perform do not change in
the sense that a manufacturing device may make one kind of part today and some very different part to-
morrow.
BACnet Architecture
Physical Layer :
The physical layer provides a means of connecting the devices and transmitting the electronic
signals that convey the data
Data Link Layer :
The data link layer organizes the data into frames or packets, regulates access to the medium,
provides addressing, and handles some error recovery and flow control.
Network Layer :
- BACnet is designed so that there is only one logical path between devices, thus eliminating the
need for optimal path routing algorithms. When two or more networks in a BACnet internet use
different MAC layer options, there is a need to recognize the difference between local and global
addresses and to route messages to the appropriate networks.
- BACnet provides this limited network layer capability by defining a network layer header that
contains the necessary addressing and control information.
Application Layer :
- The application layer of the protocol provides the communication services required by the ap-
plications to perform their functions, in this case monitoring and control of HVAC and other build-
ing systems.
- The functions of message segmentation and end-to-end flow control of transport layer is being
accommodated in application layer.
Different LAN Options
PTP (point-to-point)
• PTP is unique to BACnet and provides for internetworked communications over modems and voice grade
phone lines.
• PTP supports direct cable connections using the EIA-232 signaling standard.
• Speed is limited to from 9.6Kbps to 56.0Kbps
MS/TP (master slave/token passing)
• MS/TP is unique to BACnet and is implemented using the EIA-485 signaling standard.
• This is a shielded twisted-pair (STP) LAN operating at speeds from 9.6Kbps to 76.0Kbps.
• This LAN type is of low cost amongst the other available options
ARCNET
• ARCNET® is a token bus standard, and devices typically support it using single-source chips that handle
network communications.
• ARCNET can run on a variety of media at different speeds-from 150Kbps on EIA-485 (STP) up to 7.5Mbps
over coaxial cable, STP, or fiber optics. Typically, ARCNET runs at 2.5Mbps over twisted pair
LONTalk
• LONtalk is a proprietary technology developed by the Echelon Corporation and is the only LAN type that
requires special development tools and a proprietary chip set to implement.
Ethernet (ISO 8802-3)
• Ethernet is a popular international LAN standard widely deployed in commercial applications. Ethernet is
fast, running from 10Mbps to 100Mbps (fast Ethernet), and runs on a variety of media-STP, coaxial cable,
or fiber optics
• With BACnet/Ethernet, LAN addressing is accomplished using the Ethernet’s media access control (MAC)
48-bit address.
• Of all the BACnet data links, Ethernet provides the greatest speed.
Different LAN Options
BACnet/IP
• As the popularity of TCP/IP exploded, the BACnet community needed a strategy for using the BACnet pro-
tocol in an IP world without a major re-write of the standard. The result was BACnet/IP (B/IP) which is
described in Annex J of the BACnet standard.
• The body of the BACnet standard makes exclusive use of MAC addresses for all data links, including Eth-
ernet. But in the BACnet/IP world, IP addresses are needed.
• For BACnet/IP, Annex J defines an equivalent MAC address comprising of a four-byte IP address followed
by a two-byte UDP port number. The BACnet community registered a range of 16 UDP port numbers as
hexadecimal BAC0 through BACF
With the exception of PTP, which is unique to dialed and point-to-point communications,
BACnet generally provides the ability to choose the most appropriate trade-off between cost
and performance in the transport mechanism. The following figure shows the comparison of
different LAN options with respect to speed and cost.
BACnet Network Layer
The purpose of the BACnet network layer is to provide the means by which messages can be re-
layed from one BACnet network to another, regardless of the BACnet data link technology in use
on that network.
A BACnet Device is uniquely located by a network number and a MAC address.
BACnet routers:
• Devices that interconnect two disparate BACnet LANs, e.g., ISO 8802-3 and ARCNET, and provide the relay
function described in this clause are called "BACnet routers.“
• BACnet routers build and maintain their routing tables automatically using the network layer protocol
messages.
• Network layer protocol messages facilitate both the auto-configuration of routers and the flow of mes-
sages to, and between, routers.
BACnet imposes a limitation on the length of the NPDU (network layer protocol data unit) in
messages passed through a BACnet router. The maximum NPDU length shall not exceed the ca-
pability of any data link technology encountered along the path from source to destination. A list
of the maximum NPDU lengths for BACnet data link technologies is given below:
BACnet MS/TP device
MS/TP device works on a master slave approach
Each MSTP device has a MAC address of one octet. A Destination Address of 255 (X'FF') denotes
broadcast.
- Source address of 255 : not allowed.
- Source Addressed 0 to 127 : Valid for both master and slave nodes.
- Source Addresses 128 to 254 : Valid only for slave nodes.
MS/TP uses a token to control access to a bus network. A master node may initiate the transmis-
sion of a data frame when it holds the token. Both master and slave nodes may transmit data
frames in response to requests from master nodes.
When a request that expects a reply is sent to an MS/TP node, the sender shall wait for the reply
to be returned before passing the token. If the responding node is a master, it may return the re-
ply or it may return a Reply Postponed frame, indicating that the actual reply will be returned
later, when the replying node holds the token
MS/TP Frame Format
• Preamble : two octet preamble: X'55', X'FF‘
• Frame Type : one octet
• Destination Address : one octet address
• Source Address : one octet address
• Length : two octets, most significant octet first
• Header CRC : one octet
• Data : (present only if Length is non-zero)
• Data CRC : (present only if Length is non-zero) two octets, least significant octet first
• (pad) : (optional) at most one octet of padding: X'FF'
BACnet MS/TP device
The Frame Type is used to distinguish between different types of MAC frames. They are
00 : Token
01 : Poll For Master
02 : Reply To Poll For Master
03 : Test Request
04 : Test Response
05 : BACnet Data Expecting Reply
06 : BACnet Data Not Expecting Reply
07 : Reply Postponed
The connection of MS/TP device on a network is as shown in the following diagram
BACnet LAN: IP

BACnet IP device
BACnet Work Station BACnet/IP to
MS/TP Router
BACnet LAN: MS/TP

MS/TP Device
BACnet/IP device
Each BACnet/IP device has a B/IP MAC address. It consists of six octets consisting of the four-
octet IP address followed by a two-octet UDP port number(0xBAC0)

BACnet/ BACnet/
IP de- IP device
vice
BACnet terminology
Objects
• Devices and systems are seen as black boxes consisting of a number of objects
• BACnet objects only define the outside behaviour of the devices and systems – no in-
ternal functionality is defined

Object properties
• Each object has got a number of mandatory (required) and optional properties.
• The properties can be read by other devices and systems and some can be written to.
• Vendors may define vendor specific properties .

Services
• Communication between BACnet devices and systems is done using specific services.
• Services can be used to read object properties.
BACnet : Object Oriented Approach
BACnet has been designed taking into consideration the object-oriented approach.

This protocol models each building automation and control computer as a collection of data
structures called ‘Objects’, the properties of which represent various aspects of the hardware,
software, and operation of the device.

These objects provide a means of identifying and accessing information without requiring knowl-
edge of the details of the device's internal design or configuration

While this Standard prescribes the most widely applicable object types and their properties, im-
plementers are free to create additional object types if desired.

As the object model can be easily extended, it provides a way for BACnet to evolve in a backward
compatible manner as the technology and building needs change
BACnet Objects
Objects are defined as standard functional entities which have its own set of predefined proper-
ties making it unique.
Objects can be defined as a collection of information related to a particular function that can be
uniquely identified and accessed over a network in a standardized way.
Objects may represent single physical "points", or logical groupings or collections of points which
perform a specific function.
It is an abstract concept that allows us to talk about and organize information relating to physical
inputs and outputs, as well as non-physical concepts like software, or calculations
For example:
• For example, an object might represent a physical input device like a temperature sensor or thermostat,
or an output device like a fan or pump or valve position. Objects can also represent non-physical con-
cepts like program logic, schedules and historical data
BACnet Properties
Each object is characterized by a set of attributes or "properties” that describe its behavior or
govern its operation.
Object's properties can be visualized as a table with two columns. On the left is the name or
identifier for the property, and on the right is the property's value.
Property Identifier Property Value
Object Name "Thermostat"
Object Type Analog Input
Present Value 25.5
High Limit 50
Low Limit 2

Here is an example of a temperature sensor, which might be represented as a BACnet Analog In-
put object. The object has a name property (“Thermostat") and an object type (ANALOG INPUT).
The Present value property tells us what the temperature sensor is reading at this moment (25.5
degrees)
Some properties are read-only meaning that you can look at the property value, but not change
it. Some properties can be changed (written).
Vendors may add proprietary object properties or vendor specific objects to a device
BACnet Properties
Each object has got a number of mandatory (required) and optional properties.
Three BACnet properties are mandatory in every object
• Object_Identifier :
• This property, of type BACnetObjectIdentifier, is a numeric code that is used to identify the object. It
consists of (Object type, instance number).Instance number can vary between 0 to 4194303.
• Object_Name :
• This property, of type CharacterString, shall represent a name for the object that is unique within
the BACnet device
• Object_Type :
• This property, of type BACnetObjectType, indicates membership in a particular object type class
BACnet standard has listed down required properties for each object based on its characteristics.
To claim an object to be an BACnet object, it needs to have those required properties.
Few properties are optional, those are provided to give additional facilities for the particular ob-
ject.
Properties have read and write access attached to it. Following letters indicates whether the
property is required or not in the coming slides.
• O indicates that the property is optional,
• R indicates that the property is required to be present and readable using BACnet services,
• W indicates that the property is required to be present, readable, and writable using BACnet services
BACnet Objects
BACnet defines 30 standard object types detail. A BACnet standard object is one whose behavior,
in terms of which properties it provides and what they do, is defined in the BACnet standard.

Device Multi State Input Command

Analog Input Multi State Output File

Analog Output Multi State Value Program

Analog Value Event Enrollment Group

Binary Input Notification Class Life Safety Point

Binary Output Schedule Life Safety Zone

Binary Value Trend Log Pulse Converter

Accumulator Event Log Access Door

Averaging Trend Log Multiple Load Control

Calendar Loop Structured View

Device Object
Device Object is the collection of objects.
It can be treated as ‘main’ object just like the main class in C++.
Just as the main class cannot be initiated, similarly there cannot be two device objects in one de-
vice.
A Device object is referenced by its Object_Identifier property, which is not only unique to the
BACnet Device that maintains this object but also unique throughout the BACnet internetwork.
Device Object
Required properties of a Device object is listed down
Analog Input Object
The required and optional properties of Analog Input object are listed down
Binary Output Object
A "binary output" is a physical device or hardware output that can be in only one of two distinct
states. Here, those states are referred to as ACTIVE and INACTIVE.
A typical use of a binary output is to switch a particular piece of mechanical equipment, such as a
fan or pump, on or off. The state ACTIVE corresponds to the situation when the equipment is on
or running, and INACTIVE corresponds to the situation when the equipment is off or idle.
Schedule Object
The Schedule object type defines a standardized object used to describe a periodic schedule that
may recur during a range of dates, with optional exceptions at arbitrary times on arbitrary dates.
The Schedule object serves as a binding between these scheduled times and the writing of speci-
fied "values" to specific properties of specific objects at those times.
Schedules are divided into days, of which there are two types: normal days within a week and ex-
ception days. Both types of days can specify scheduling events for either the full day or portions
of a day, and a priority mechanism defines which scheduled event is in control at any given time.
The current state of the Schedule object is represented by the value of its Present_Value prop-
erty, which is normally calculated using the time/value pairs from the Weekly_Schedule and Ex-
ception_Schedule properties.
Schedule Object
Notification Class Object
The Notification Class object type defines a standardized object that represents and contains in-
formation required for the distribution of event notifications within BACnet systems.
Notification Classes are useful for event-initiating objects that have identical needs in terms of
how their notifications should be handled, what the destination(s) for their notifications should
be, and how they should be acknowledged.
It is often necessary for event notifications to be sent to multiple destinations or to different des-
tinations based on the time of day or day of week. Notification Classes may specify a list of desti-
nations, each of which is qualified by time, day of week, and type of handling.
Notification Class Object
BACnet Services
Services are the means by which one BACnet device acquires information from another device,
commands another device to perform some actions, or announces to one or more devices that
some event has taken place.

Each service request issued and service acknowledgment (reply) returned becomes a message
packet transferred over the network from the sending to the receiving device.

Services allow one BACnet device to do something on behalf of another BACnet device.

• For example, if one device needs to know a temperature, it can read the Present_Value property of the
analog input object which represents that temperature sensor.
BACnet Client/Server Architecture
A BACnet device may trigger a service or can react on a service request:

• Client: Requests services (Service user)

• Server: Offers services (Service provider)

Initiate
Service
(A side)
C S
Execute
Service (B side)

The one who acts as a user of the data(client) acts as a initiator and the one who is the
provider of this data(server) acts as executor
Application Services
Services in BACnet are classified in two types
• Confirmed Application Services

The client expects an acknowledgement for the requested service in case of confirmed ap-
plication services.
• Unconfirmed Application Services
The client does not expects an acknowledgement for the requested service in case of un-
confirmed application services.

‘Confirmed’ services is labeled "C" whereas ‘Unconfirmed’ services is

labeled “U” in the tables in the following sections.
Application Services
BACnet defines 32 Services and classifies them into following five categories.

• Object Access Services

• Alarm and Event Services
• File Access Services
• Remote Device Management Services
• Virtual Terminal Services

BACnet devices are not required to implement every single Service.

Just one Service, ReadProperty, is required to be processed by all BACnet devices .

Object Access Services
These are the services related to accessing the properties of the objects.
The Read-Property service, for example, is a message that contains the object and property iden-
tifiers that uniquely identify which object's property is to be read and sent back.
The message is always sent to a specific recipient and returns, hopefully, the requested property
value in a standard form.
Various object access services are:

• ReadProperty
• ReadPropertyMultiple
• ReadPropertyConditional
• ReadRange
• WriteProperty
• WritePropertyMultiple
• CreateObject
• DeleteObject
• AddListElement
• RemoveListElement
ReadProperty Service
The ReadProperty service is used by a client BACnet-user to request the value of one property of
one BACnet Object
It falls into confirmed application service category.
ReadProperty Service requires following two important fields
• Object Identifier
• Property Identifier
ReadPropertyMultiple Service
The ReadPropertyMultiple service is used by a client BACnet-user to request the values of one or
more specified properties of one or more BACnet Objects
WriteProperty Service
The WriteProperty service is used by a client BACnet-user to modify the value of a single speci-
fied property of a BACnet object.
This falls under Confirmed Application Services category .
WritePropertyMultiple Service
The WritePropertyMultiple service is used by a client BACnet-user to modify the value of one or
more specified properties of a BACnet object.
This falls under Confirmed Application Services category.
Remote Device Management Services
The Remote Device Management Services provide a number of disparate functions,
including operator control, specialized message transfer, and addressing/auto-
configuring functions. Following is the list of services under this category:

SERVICE BACnet DESCRIPTION

DeviceCommunicationControl C Tells a device to stop (and start!) accepting network messages.

ConfirmedPrivateTransfer C Sends a vendor-proprietary message to a device.

UnconfirmedPrivateTransfer U Sends a vendor-proprietary message to one or more devices.

ReinitializeDevice C Orders the receiving device to cold- or warm-boot itself.

ConfirmedTextMessage C Conveys a text message to another device.

UnconfirmedTextMessage U Sends a text message to one or more devices.
TimeSynchronization U Sends the current time to one or more devices.
Who-Has U Asks which BACnet devices contain a particular Object.

I-Have U Affirmative response to Who-Has, broadcast.

Who-Is U Asks about the presence of specified BACnet devices.

I-Am U Affirmative response to Who-Is, broadcast.

Who-Is and I-Am
The Who-Is and I-Am Services are used to obtain the network addresses of BACnet devices on a
BACnet internetwork.
A BACnet device that needs to know the address of one or more devices can broadcast a Who-Is
Service request (message) on the internetwork specifying a Device Object Instance Number or a
range of Instance Numbers. The devices that have the specified Device Objects broadcast an I-
Am Service request either on the network so that the requesting device will see the response.
Who-Has and I-Have Services
The Who-Has and I-Have Services are similar to the Who-Is and I-Am, but the Who-Has adds ei-
ther an Object Identifier or an Object Name. Receiving devices which contain an Object matching
the request broadcast the I-Have Service request
The Who-Has and I-Have services are unconfirmed services.
TimeSynchronization
The TimeSynchronization service is used by a requesting BACnet-user to notify a remote device of
the correct current time.
This service may be broadcast, multicast, or addressed to a single recipient and falls under un-
confirmed service category.
Its purpose is to notify recipients of the correct current time so that devices may synchronize
their internal clocks with one another.

Time parameter, of type BACnetDateTime, shall convey the current date and time as determined
by the clock in the device issuing the service request.
ReinitializeDevice Service & DeviceCommunicationControl
The DeviceCommunicationControl and ReinitializeDevice Services are intended to
provide a human operator with diagnostic tools which may be invoked remotely.
The ReinitializeDevice service is used by a client BACnet-user to instruct a remote de-
vice to reboot itself (cold start), reset itself to some predefined initial state (warm
start)
The DeviceCommunicationControl service is used by a client BACnet-user to instruct a
remote device to stop initiating and optionally stop responding to all APDUs (except
DeviceCommunicationControl or, if supported, ReinitializeDevice) on the communica-
tion network or internetwork for a specified duration of time.
Due to the sensitive nature of this service, a password may be required from the re-
sponding BACnet-user prior to executing the service.
Alarm and Event Services
“Events" are changes of value of certain properties of certain objects, or internal status changes,
that meet predetermined criteria.
There are three mechanisms provided in BACnet for managing events:
• change of value reporting,
• intrinsic reporting,
• algorithmic change reporting.
Alarms and events service provides a way to indicate problems or error conditions, such as a sen-
sor reading out of normal range or, for that matter, returning to normal operation ("Events"); or a
change in a reading (of some increment since the previous report) termed "Change Of Value" or
COV.
SERVICE BACnet DESCRIPTION
SubscribeCOV C Sent by a device to request that it be told of COVs in an object.
ConfirmedCOVNotification C Tells subscribing devices of the COV that occurred in a property.

UnconfirmedCOVNotification U Tells subscribing devices that a change has occurred to one or more
properties of a particular object.
ConfirmedEventNotification C Used to tell sender of a possible error condition.
UnconfirmedEventNotification U Used to tell sender of a possible error condition.
GetAlarmSummary C Requests from a device a list of "active alarms," if any.
GenEnrollmentSummary C Requests a list of "event" (possible error) generating objects.
GetEventInformation Service C To obtain a summary of all "active event states"
LifeSafetyOperation Service The LifeSafetyOperation service is intended for use in fire, life safety
and security systems
AcknowledgeAlarm Service C Used to tell sender of alarm that a human has seen the alarm.
COV Reporting
COV stands for Change of Value !
The SubscribeCOV service is used by a COV-client to subscribe for the receipt of notifications of
changes that may occur to the properties of a particular object.
For example:
- Let the client subscribe for an monitored object as Analog Input object(AI,0).
- At the time of subscription, client needs to specify whether it wants confirmedCOV notifica-
tion or unconfirmed COV notification.
- Also, it needs to mention the time duration for which the subscription is valid.
- Now, when any change in the present value of AI object occurs and it is larger than
COV_Increment property of the AI object, it will issue the confirmed COV notification to the
client in the time duration of its subscription.
- The (AI,0) object will wait for acknowledgement from the client for the Confirmed COV notifica-
tion.
- Let us see this happening in the next slide !
COV Subscription
Intrinsic /Algorithmic change Reporting
Object supporting intrinsic reporting has notification class property which refers to
the notification class object. Notification class object has recipient list property which
holds the list of referenced objects which needs to be notified in case of event/alarm
condition.
Intrinsic events are connected to one or more recipients indirectly through association
with a Notification Class object. Algorithmic change events are connected to one or
more recipients by the creation of an Event Enrollment object.
Intrinsic Event Reporting
• The recipient list of alarms and events from specific objects will statically or dynamic-
ally be managed using NotificationClass objects
• The objects to support intrinsic alarming will have to support various optional proper-
ties like the EventEnable property
Algorithmic Change Events
• In order to support algorithmic change events, the EventEnrollment object needs to be
supported. The EventEnrollment object list contains stages and values of data points
that need to be monitored.
• In case of a limit violation, the distribution of alarms/events can either be handled by
the EventEnrollment object itself (if recipients are defined) or via a Notification Class
object list if a NC object is defined with the object in alarm.
Intrinsic Reporting

Recipient
List
BACnet Interoperability Building Blocks
Services are paired based on the functionality it belongs to. Small building blocks were
formed for each functional area. Such groups or blocks are known as BIBBs
BIBBs come in pairs, designated A and B, that reflect the client/server nature of control
system communication. Both of these devices are nodes on a BACnet internetwork.
In most cases, the "A" device will act as the user of data (client), and the "B" device will
be the provider of this data (server).
There are BIBBs for the following areas of interoperability:
• Data Sharing (DS)
• Alarm and Event Notification (AE)
• Scheduling (SCHED)
• Trending (T)
• Device Management (DM)
• Network Management (NM)
• Virtual Terminal Management (VT)
BACnet Interoperability Building Blocks
BIBBs example:
• BIBB - Data Sharing - ReadProperty-A (DS-RP-A)
The A device is a user of data from device B

• BIBB - Data Sharing - ReadProperty-B (DS-RP-B)

The B device is a provider of data to device A.
BACnet Interoperability Building Blocks
BIBBs example:
• DS-COVP-B (Data Sharing-COVP-B)
• (A) is user (Client), (B) is server (Server)
• (A) subscribes change of value of a specific property from (B)
• (B) serves (A) with COV of the object property without the need of polling
How to use BIBB?
Consider a very simple application-specific controller.
• Does it have data that needs to be shared with some other device in the system? The an-
swer is almost certainly yes. This means that it must support the B-side of one of the Read-
Property BIBBs (some other device can read the properties of its objects).
• Does it have the resources to answer requests for more than one data value at a time? Let’s
assume the answer is no. That means DS-RP-B is the appropriate choice and not DS-RPM-B .
• Does it need to provide a way for another device to change the value of one or more of its
properties (e.g., a setpoint)? If yes, then it should also support DS-WP-B.
• Does it need to get data from or change values in another device? It probably doesn’t, which
means that it does not need any of the A side BIBBs. The end result is a specification that
these controllers must support DS-RP-B and DS-WP-B.
• This type of reasoning for each of the application area can be used to select building blocks
that define the communication capabilities for any BACnet device.
BACnet Profiles
BACnet devices support BIBBs which they require as per their device functionality and type. The
standardization of grouping of BIBBs has led to the concept of ‘profiles’
BACnet standard describes six types of BACnet devices i.e. profiles
Any device that implements all the required BACnet capabilities for a particular device type and
interoperability area may claim to be a device of that particular type.
The six different profiles are
• BACnet Operator Workstation B-OWS
• BACnet Building Controller B-BC
• BACnet Advanced Application Controller B-AAC
• BACnet Application Specific Controller B-ASC
• BACnet Smart Actuator B-SA
• BACnet Smart Sensor B-SS
Hierarchy of BACnet Components
C
B-AS
B- S
OW BACnet Profiles AC
B-SA B-A

-A
P-
A DM-TS DS
-W
-R P-B
DS
DS-
RP-
B
BACnet BIBBs AE
-ACK
-B

SCHE
D-A

s
er
ty o -Ha
ro
p Wh W
dP ho I-Am
Re
a
WriteP
BACnet Services
ropert
-Is

y I-Hav
e

BACnet BACnet BACnet Ob-

BACnet BACnet
Prop- Proper-
Proper- Proper- jects
erties ties
ties ties
Hierarchy of BACnet Profiles

Operator Workstation
B-OWS
(B-OWS)

B-BC B-BC B-BC

Building Controller
(B-BC)

Application-Specific Controller
B-AAC
B-ASC (B-AAC or B-ASC)

B-ASC B-ASC

B-SA B-SS
Smart Sensor/Actuator
BACnet profiles
BACnet Smart Sensor (B-SS)
• Supports Data Sharing BIBBs
• They are simple sensing device with very limited resources
• Ability to provide values for any of its BACnet objects upon request

BACnet Smart Actuator (B-SA)

• Supports Data Sharing BIBBs
• Ability to provide values for any of its BACnet objects upon request
• Ability to allow modification of some or all of its BACnet objects by another device

BACnet Application Specific Controller(B-ASC)

• Supports Data Sharing BIBBs
• Simple sensing device with very limited resources
• Ability to provide values for any of its BACnet objects upon request
• Supports Device and Network Management
• Ability to respond to queries about its status
• Ability to respond to requests for information about any of its objects
• Ability to respond to communication control messages
BACnet Profiles
BACnet Advanced Application Controller (B-AAC)
• Supports Data sharing BIBBs
• Ability to provide values for any of its BACnet objects upon request
• Ability to allow modification of some or all of its BACnet objects by another BACnet device
• Device and Network Management
• Ability to respond to queries about its status
• Ability to respond to requests for information about any of its objects
• Ability to respond to communication control messages
• Ability to synchronize its internal clock upon request
• Ability to perform re-initialization upon request
• Alarm and Event Management
• Generation of limited alarm and event notifications and the ability to direct them to recipients
• Tracking acknowledgments of alarms from human operators
• Adjustment of alarm parameters
• Scheduling
• Ability to schedule actions in the local device based on date and time
BACnet Profiles
BACnet Building Controller (B-BC)
• Supports Data sharing
• Ability to provide the values of any of its BACnet objects
• Ability to retrieve the values of BACnet objects from other devices
• Ability to allow modification of some or all of its BACnet objects by another device
• Ability to modify some BACnet objects in other devices
• Device and Network Management
• Ability to respond to queries about its status
• Ability to respond to requests for information about any of its objects
• Ability to respond to communication control messages
• Ability to synchronize its internal clock upon request
• Ability to perform re-initialization upon request
• Ability to upload its configuration and allow it to be subsequently restored
• Ability to command half-routers to establish and terminate connections
• Scheduling
• Ability to schedule output actions, both in the local device and in other devices, both binary and analog, based on
date and time
• Alarm and Event Management
• Generation of alarm / event notifications and the ability to direct them to recipients
• Maintain a list of unacknowledged alarms / events
• Notifying other recipients that the acknowledgment has been received
• Adjustment of alarm / event parameters
• Trending
• Collection and delivery of (time, value) pairs
BACnet Profiles
BACnet Operator work Station (B-OWS)
• Supports Data sharing
• Ability to provide the values of any of its BACnet objects
• Archival storage of data
• Presentation of data (i.e., reports and graphics)
• Ability to monitor the value of all BACnet object types, including all required and optional properties
• Ability to modify set points and parameters
• Supports Device and Network Management
• Ability to respond to queries about its status
• Ability to respond to requests for information about any of its objects
• Display of information about the status of any device on the BACnet internetwork
• Display of information about any object in the BACnet internetwork
• Ability to silence a device on the network that is transmitting erroneous data
• Ability to synchronize the time in devices across the BACnet internetwork
• Ability to cause a remote device to reinitialize itself
• Ability to backup and restore the configuration of other devices
• Ability to command half-routers to establish and terminate connections
• Ability to query and change the configuration of half-routers and routers
• Supports Alarm and Event Management
• Operator notification and presentation of event information
• Alarm acknowledgment by operators
• Alarm summarization
• Adjustment of alarm limits Supports Trending
• Adjustment of alarm routing • Modification of the parameters of a trend log
• Supports Scheduling • Display and archive of trend data
• Modification of schedules
• Display of the start and stop times (schedule) of scheduled devices
BACnet Profiles
BACnet profiles
BACnet Conformance Testing
ASHRAE published an ASHRAE Standard 135.1P. in 2003 which includes all the testing norms so as
to meet the compliance of BACnet standards.

BACnet Testing Laboratories was established by BACnet International to support compliance test-
ing and interoperability testing activities for BACnet devices using the draft testing procedures
from 135.1P.

Few basic terminologies involved in BACnet testing

• IUT (Instrument under testing) :

• It is the device available for Testing
• Functionality Checklist :
• Identifies the testable options implemented by the IUT and divides it out into section by its func-
tionality.
• PICS :
• PICS stands for BACnet Protocol Implementation Conformance Statement and it describes the BAC-
net functionality of the product to be tested
• EPICS :
• EPICS stands for Electronic Protocol Implementation Conformance Statement and it is the compati-
ble format of BACnet Testing software
The BACnet PICS
PICS: Protocol Implementation Conformance Statement
The PICS is a standard way of describing the BACnet functionality of a specific solution
in a kind of table format and contains information about
• BACnet services supported
• BACnet standard objects supported including information
• Whether or not BACnet objects can be created and deleted during runtime
• Which object properties are supported and which are read-only
• Data Link Layer Options
• Description of the network options supported
(like Ethernet, BACnet /IP)
• Special functionality
• Restrictions to properties, if exist
• e. g. the max. number of characters for a key name or the character set (e. g.
ANSI X3.4)
The BACnet PICS is an important means for end customers and consultants to under-
stand the functionality provided by a BACnet solution.
This is achieved through
• BACnet Interoperability Building Blocks (BIBBs)
• Standard device profiles
BACnet PICS (Extract)
BACnet EPICS
An Electronic Protocol Implementation Conformance Statement (EPICS) file contains a BACnet
protocol implementation conformance statement expressed in a standardized text form.
EPICS files are machine and human readable representations of the implementation of BACnet
objects and services within a given device.
EPICS files shall use the extension ".TPI”(text protocol information) and contain normal editable
text lines consisting of text character codes ending in carriage return/linefeed pairs (X'0D',
X'0A')
EPICS files are used by software testing tools to conduct and interpret the results of tests de-
fined in this standard. An EPICS file shall accompany any device tested according to the proce-
dures of 135.1
Following are the important sections that needs to be present in EPICS file
• General Information Section : These sections provide general information about the BACnet device(Vendor, product
name, Product model number, description)
• BIBBs Supported :This section indicates which BIBBs are supported
• Application Services Supported : This section indicates which standard application services are supported.
• Object Types Supported : This section indicates which standard object types are supported
• Data Link Layer Options : This section indicates which standard data link layer options are supported
• Character Sets : This section indicates which BACnet character sets are supported
• Special Functionality : This section indicates which BACnet special functionalities are supported
• Property Value Restrictions : This section defines default restrictions on the values of writable properties
• Timers : This section defines timer values that are used to determine when a test has failed
because an appropriate response has not been observed by the TD
• Test Database : The last section of the EPICS file defines the contents of the device's test database of
objects and their properties
BACnet EPICS (Extract)
BACnet Testing
Client Avadhana

Shipment of Device with following

documents IUT
Setup
inspection
BACnet test
– Report,
lab &
• PIC (Protocol Information Conformance) Power
deployon
resource
Test, Commu-
as per
file of product which specifies nature
nication
of testing
Test
 Services supported by the de-
vice
 Objects supported by the de-
vice
BACnet
 Object properties test re-
port by
• Functionality Check list SoftDEL
• EPIC (Electronic Protocol Information Con-
formance)
Mapping existing test cases
Mapping existing testreport
cases
• Product Application file with device Test execution and
Report study, Fix issues, with device functionality &
programming tool (if applicable) generation
implementing
Upgrade • Device accessory and power supply (if
not standard)
• Info on firmware uploading
Updated
Report No bugs detected,
Testing completed !
Changes & Report gen-
eration
Testing Tools
To Test BACnet/IP device:
Following is the list of tools required for testing BACnet/IP device
• VTS:

The Visual Test Shell (VTS) is a Microsoft Windows application for testing the BACnet functiona
lity of equipment used in building automation systems. It can be freely downloaded from http:
//[Link]/projects/vts/files
• Wireshark:

It is a Protocol Analyzer used for IP, Ethernet or MS/TP captures. It can be freely downloaded f
rom [Link]
To Test MSTP device:
Following is the list of tools required for testing MSTP device
• VTS
• Wireshark
• Oscilloscope – PicoScope 2204 - Used to verify MS/TP timing during BTL Testing.
• Frontline Serialtest - Serial Analyzer which can be used for MS/TP testing
VTS
Wireshark
Oscilloscope – PicoScope 2204
Frontline Serialtest
BACnet Development Approach
Factors to be considered for the development of BACnet Compliant device

1. Decide and finalize the BACnet application you need to develop.

[Link] on the application scope, one need to decide : which BACnet profile to go for !
3. Decide : which BACnet services one needs to support to satisfy the needs of the decided
profile
4. List down all the required BACnet objects one needs to have in the BACnet device based on
the requirement of the device
5. List down all the data and physical LAN options available and can be considered.
6. Decide whether you want to go for BACnet/IP or MSTP device development
7. Based on the above information, prepare a PICs file
8. Prepare a functionality check list and EPICs file for the device
9. Decide whether you want to develop your own BACnet stack or go for third party BACnet
Stack.
[Link] the efforts/cost/time involved in the integration of the third party stack with your
own BACnet application.
[Link] the development activity is over, it needs to be fully tested as per the norms set by
BACnet international.
12. You can go for pre-assessment BACnet testing services offered by Avadhana.
13. The final certification of whether the device is BACnet compliant will be given by BACnet In-
ternational based on the test results of BTL lab.
Development of BACnet/IP Stack
BACnet/IP Stack
The application Layer takes care of all the en-
The purpose of of
coding/decoding theBACnet
BACnetservices,
networkwhether
layer is it
to provide service
is confirmed the means by which
or not, messages
whether segmenta-can
Application Layer beisrelayed
tion requiredfrom one BACnet network to an-
or not.
other,
The regardless
BACnet VirtualofLink
theLayer
BACnet dataprovides
(BVLL) link
technology
the interfaceinbetween
use on that network.
the BACnet A BACnet
Network
BVLL (BACnet Virtual Link Deviceand
Layer is uniquely locatedcapabilities
the underlying by a networkof anum-
par-
Layer)
ber and
ticular a MAC address.
communication Six octets consisting
subsystem
of the four-octet IP address followed by a
two-octet UDP port number (0xBAC0) shall
Network Layer
function as the MAC address.

Data Link Layer

BACnet/IP uses Ethernet as its

data and physical link
Physical Layer
Network Layer PDU structure
Protocol Version Number
Each NPDU shall begin with a single octet that indicates the version
number of the BACnet protocol, encoded as an 8 bit unsigned
integer. The present version number of the BACnet protocol is 1.
Network Layer Protocol Control Information
The second octet in an NPDU shall be a control octet that
indicates the presence or absence of particular NPCI fields.
Network Layer PDU structure
BVLC frame structure
Each BVLL message has at least three fields.
• The 1-octet BVLC Type
This field indicates which underlying communication subsystem is in use. In this case, a BVLC Type of
X'81' indicates the use of BACnet/IP.
• The 1-octet BVLC Function
This field identifies the specific function to be carried out in support of the indicated communication
subsystem. Although there are 12 BVLC functions defined, only 3 are essential for a BACnet/IP device.
9 BVLC functions are defined to serve BACnet Broadcast Management Devices

• The 2-octet BVLC Length field

This field is the length, in octets, of the entire BVLL message, including the two octets of the length
field itself, most significant octet first.
BVLC frame structure
Original-Unicast-NPDU
This message is used to send directed NPDUs
to another B/IP device or router

Original Broadcast-NPDU
This message is used by B/IP devices and routers
which are not foreign devices to broadcast NPDUs on
a B/IP network

Forwarded NPDU
This BVLL message is used in broadcast messages
from a BBMD as well as in messages forwarded to
registered foreign devices. It contains the source
address of the original node as well as the original
BACnet NPDU
Application Layer frame Structure
Application Layer Protocol Data Units (APDUs) are used in BACnet to convey the information con-
tained in the application service primitives and associated parameters.
Each APDU consists of a fixed portion and a variable portion depending upon the APDU type.
Fixed Portion:
"Protocol control information" (PCI) comprises data required for the operation of the application layer protocol,
including the type of APDU, information to match service requests and service responses, and information to
carry out the reassembly of segmented messages. This information is contained in the "header," or fixed part, of
the APDU.
Variable Portion:
Variable part of APDU consists of "User data“comprising information specific to individual service requests or re-
sponses.
There are 8 types of BACnet APDU. They are:
Application Layer frame Structure
Let us take the example BACnet –Confirmed-Request-PDU
Application Layer frame Structure
Let us take the example BACnet -Unconfirmed-Request-PDU

BACnet-Simple-Ack-PDU