November 2010
Article
AutomatedBuildings.com
|
[an error occurred while processing this directive]
(Click
Message to Learn More)
|
The Protocol Implementation Conformance Statement (PIC)
&
BACnet
Interoperability Building Blocks (BIBB)
|
Nirosha Munasinghe MBusIT BSc BE (Hons) (Melb)
Product Development Manager,
Open General
Contributing Editor
|
As open
protocols evolve in the BAS industry, control requirements for new and
retrofitted buildings are specifying detail features of the protocol to be
implemented in the control devices. A few years ago, the control specification
only stated that the communication protocol must be BACnet or native BACnet.
There were no specific details outlined of the features and the services that the
device must support. However, through education and evolution of the open
standards, the requirements are now asking specific features from the control
devices. The specifications are
outlining detail implementation features for alarming, data logging, scheduling
and data sharing. In most cases, it is
also specifying a conformance statement for each control device to be submitted
for tendering process. For example “Provide all necessary BACnet-compliant
hardware and software to meet the system’s functional specifications. Provide
protocol implementation conformance statement (PIC) for every controller in the
system, including unitary controllers.”
Such a statement is a step forward for the industry. It is attempting to
verify system compatibility of pre-existing and/or new devices to the
requirements of the client. However, do the decision makers have the right
understanding to interpret a PIC statement from different vendors? Not many and
in most cases, not at all. The decision makers understand it is a document
that outlines protocol conformance but when it comes to analysing the details
inside the document there is a knowledge gap. I have seen in some situations,
the decision makers counting the number of features supported in Vendor A versus
Vendor B and offering the tender to vendor who has the larger count. Then the word
spreads in the industry that Vendor A has more features than Vendor B,
therefore Vendor A is a better product. This is simply wrong. This article examines what is a PIC statement
in BACnet and outlines the main characteristics of the document.
The Protocol
Implementation Conformance Statement (PIC) is a written document created by
the BACnet device manufacturer to outline the BACnet features implemented in a
device. The primary purpose of the document is to verify if the device is
compatible to the specified system and has synergy with the client’s
requirements. Therefore, every BACnet
device must have a PIC statement.
Following is an
example of a PIC statement for a BACnet device.
From the
document most players in the BAS industry can deduce that the BACnet device can
execute physical input/output, alarming, scheduling, data logging and data
sharing in a RS485 communication medium. This is correct but many assume all
functions relating to the features can be achieved by the device. This
assumption leads to many issues such as overestimation of the devices features
and system integration problems causing increases in costs throughout the
building life cycle. To avoid these
issues we must have a deep understanding of what is included in the PIC statement.
Let's dissect each section of the PIC statement in detail:
Profile: Outlines the specific profile of the BACnet
device. BACnet standard specifies various profiles which must support certain
features for the device to be classified as the profile. BACnet standard
defines the following profiles:
[an error occurred while processing this directive]BIBBs Supported: BACnet
Interoperability Building Blocks (BIBB)
are a collection of BACnet services. It outlines the exact capabilities of the device
in a structured format. It defines the data sharing, alarming, scheduling, data
logging and network management of the device. It also defines if the devices
have the capabilities to initiate and/or execute a service. For example, in the
example PIC statement, the device can initiate a read (ReadProperty A) and also
can execute a read request directed at the device (ReadProperty B). Refer to the BACnet Standard 135-2008 for
detail explanation about the services. It is critical that the decision makers
understand the implications of the services to select the right product for the
requirements. For example
ReadPropertyMultiple-B implies that the device has the capability of sending a
reply to a read request of multiple properties in one single frame, hence
minimizing bandwidth on the network. Therefore, if a device does not support
ReadPropertyMultiple-B service, the decision maker must understand that all the
reads for the device must be executed one property per frame using ReadProperty
service, increasing bandwidth on the network. Each of these services has an
implication on the system. Why, how Therefore, for greater performance,
multi-vendor integration and future network expansions, the services must be
greater understood by the industry.
Objects Supported: A
BACnet object is a group of properties which describes a physical or logical
point in a BAS system. The BACnet objects allow logical structuring of the
system without the requirement of proprietary programming. For example Analog Input object type describes
the physical input such as a temperature sensor. A schedule object defines a
logical point of plant schedule. Each object contains mandatory properties
which must be implemented by the vendor if the device supports the object and
optional properties. Do not assume that if a device implements a specific
object that it implements all of its properties. For example if there is a
requirement that a Binary Output change state after a certain amount time, a Binary
Output object which supports the optional properties Minimum_Off_Time and
Minimum_On_Time is required. Similarly the ability to have special exception
scheduling events (e.g. holidays) is an optional property for the Schedule
object.
Data Link and Network Options: It outlines the communication
architecture which the device operates and the networking option available to
view the device in a LAN or WAN.
As it can be
seen from this simple example, choosing the correct device to match the control
requirements is not an easy task. Many take a device which supports BACnet for
granted and assume it can perform many tasks. It is important that the decision
makers have in depth knowledge of the intricacies of BACnet and invest time during the
initial stage of the project to choose the right products to suit the
requirements. The product with the most
features does not imply it is the best product.
footer
[an error occurred while processing this directive]
[Click Banner To Learn More]
[Home Page] [The
Automator] [About] [Subscribe
] [Contact
Us]