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
Nirosha Munasinghe MBusIT BSc BE (Hons) (Melb)
Product Development Manager,
Open General 

Contributing Editor

 

Articles
Interviews
Releases
New Products
Reviews
Editorial

[an error occurred while processing this directive]

Coming Events
Sponsors
Site Search
Blogs
Archives
Past Issues
Home

[an error occurred while processing this directive]


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.

Product Implementation

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:

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]

Events

Want Ads

Our Sponsors

Resources