PI BACnet Interface

Version 1.2.3.0

Revision A

OSIsoft, LLC
777 Davis St., Suite 250
San Leandro, CA94577USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web:
OSIsoft Australia • Perth, Australia
OSIsoft Europe GmbH • Altenstadt, Germany
OSIsoft Asia Pte Ltd. • Singapore
OSIsoft Canada ULC • MontrealCalgary, Canada
OSIsoft, LLC Representative Office • Shanghai, People’s Republic of China
OSIsoft Japan KK • Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. • Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. • Sao Paulo, Brazil
Copyright: © 2008-2019 OSIsoft, LLC. All rights reserved.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.
OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, Sigmafine, Analysis Framework, IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI BatchView, PI Data Services, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ, RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC. All other trademarks or trade names used herein are the property of their respective owners.
U.S. GOVERNMENT RIGHTS
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as applicable. OSIsoft, LLC.
Published: 06/2010

Table of Contents

Terminology

Chapter 1.Introduction

Reference Manuals

Supported Features

Diagram of Hardware Connection

Chapter 2.Principles of Operation

Chapter 3.Installation Checklist

Data Collection Steps

Interface Diagnostics

Advanced Interface Features

Chapter 4.Interface Installation

Naming Conventions and Requirements

Interface Directories

PIHOME Directory Tree

Interface Installation Directory

Interface Installation Procedure

Installing Interface as a Windows Service

Installing Interface Service with PI Interface Configuration Utility

Service Configuration

Installing Interface Service Manually

Chapter 5.BACnet Query Tool

Who IS Device Query

IP Addresses

Object Explorer

Query View

PI Tag Creation

Object Reports

COV Subscription Tests

Query Settings

Alternative Query Settings

General Settings

PI Tag Settings

Chapter 6.Digital States

Chapter 7.PointSource

Chapter 8.PI Point Configuration

Point Attributes

Tag

PointSource

PointType

Location1

Location2

Location3

Location4

Location5

InstrumentTag

ExDesc

Scan

Shutdown

Output Points

BACnet Output

Output Tag Configuration

Output Debugging

Chapter 9.Startup Command File

Configuring the Interface with PI ICU

BACnet Interface page

Command-line Parameters

Sample PIBACnet.bat File

Chapter 10.UniInt Failover Configuration

Introduction

Quick Overview

Synchronization through a Shared File (Phase 2)

Configuring Synchronization through a Shared File (Phase 2)

Configuring UniInt Failover through a Shared File (Phase 2)

Start-Up Parameters

Failover Control Points

PI Tags

Detailed Explanation of Synchronization through a Shared File (Phase2)

Steady State Operation

Failover Configuration Using PI ICU

Create the Interface Instance with PI ICU

Configuring the UniInt Failover Startup Parameters with PIICU

Creating the Failover State Digital State Set

Using the PI ICU Utility to create Digital State Set

Using the PI SMT 3 Utility to create Digital State Set

Creating the UniInt Failover Control and Failover State Tags (Phase 2)

Chapter 11.Interface Node Clock

Chapter 12.Security

Chapter 13.Starting / Stopping the Interface

Starting Interface as a Service

Stopping Interface Running as a Service

Chapter 14.Buffering

Which Buffering Application to Use

How Buffering Works

Buffering and PI Server Security

Enabling Buffering on an Interface Node with the ICU

Choose Buffer Type

Buffering Settings

Buffered Servers

Installing Buffering as a Service

Chapter 15.Interface Diagnostics Configuration

Scan Class Performance Points

Performance Counters

Performance Counters for both (_Total) and (Scan Class x)

Performance Counters for (_Total) only

Performance Counters for (Scan Class x) only

Interface Health Monitoring Points

I/O Rate Point

Interface Status Point

Appendix A.Error and Informational Messages

Message Logs

Error Messages

Messages

System Errors and PI Errors

UniInt Failover Specific Error Messages

Informational

Errors (Phase 1 & 2)

Errors (Phase 2)

Appendix B.PI SDK Options

Appendix C.BACnet Object Types

Appendix D.BACnet Object Properties

Appendix E.Technical Support and Resources

Before You Call or Write for Help

Help Desk and Telephone Support

Search Support

Email-based Technical Support

Online Technical Support

Remote Access

On-site Service

Knowledge Center

Upgrades

Appendix F.Revision History

PI BACnet Interface1

Terminology

To understand this interface manual, you should be familiar with the terminology used in this document.

Buffering

Buffering refers to an Interface Node’s ability to store temporarily the data that interfaces collect and to forward these data to the appropriate PI Servers.

N-Way Buffering

If you have PI Servers that are part of a PI Collective, PIBufss supports n-way buffering. N-way buffering refers to the ability of a buffering application to send the same data to each of the PI Servers in a PI Collective. (Bufserv also supports n-way buffering to multiple PI Server however it does not guarantee identical archive records since point compressions specs could be different between PI Servers. With this in mind, OSIsoft recommends that you run PIBufss instead.)

ICU

ICU refers to the PI Interface Configuration Utility. The ICU is the primary application that you use to configure PI interface programs. You must install the ICU on the same computer on which an interface runs. A single copy of the ICU manages all of the interfaces on a particular computer.

You can configure an interface by editing a startup command file. However, OSIsoft discourages this approach. Instead, OSIsoft strongly recommends that you use the ICU for interface management tasks.

ICU Control

An ICU Control is a plug-in to the ICU. Whereas the ICU handles functionality common to all interfaces, an ICU Control implements interface-specific behavior. Most PI interfaces have an associated ICU Control.

Interface Node

An Interface Node is a computer on which

  • the PI API and/or PI SDK are installed, and
  • PI Server programs are not installed.
PI API

The PI API is a library of functions that allow applications to communicate and exchange data with the PI Server. All PI interfaces use the PI API.

PI Collective

A PI Collective is two or more replicated PI Servers that collect data concurrently. Collectives are part of the High Availability environment. When the primary PI Server in a collective becomes unavailable, a secondary collective member node seamlessly continues to collect and provide data access to your PI clients.

PIHOME

PIHOME refers to the directory that is the common location for PI 32-bit client applications.

On a 32-bit operating system

A typical PIHOME is C:\Program Files\PIPC.

On a 64-bit operating system

A typical PIHOME is C:\Program Files (x86)\PIPC.

PI interfaces reside in a subdirectory of the Interfaces directory under PIHOME.

For example, files for the Modbus Ethernet Interface are in

[PIHOME]\PIPC\Interfaces\ModbusE.

This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory. For example, ICU files in [PIHOME]\ICU.

PIHOME64

PIHOME64will be found only on a 64-bit operating system and refers to the directory that is the common location for PI 64-bit client applications.

A typical PIHOME64 is C:\Program File\PIPC.

PI interfaces reside in a subdirectory of the Interfaces directory under PIHOME64.

For example, files for a 64-bit Modbus Ethernet Interface would be found in

C:\ProgramFiles\PIPC\Interfaces\ModbusE.

This document uses [PIHOME] as an abbreviation for the complete PIHOME or PIHOME64 directory. For example, ICU files in [PIHOME]\ICU.

PI SDK

The PI SDK is a library of functions that allow applications to communicate and exchange data with the PI Server. Some PI interfaces, in addition to using the PI API, require the use of the PI SDK.

PI Server Node

A PI Server Node is a computer on which PI Server programs are installed. The PI Server runs on the PI Server Node.

PI SMT

PI SMT refers to PI System Management Tools. PI SMT is the program that you use for configuring PI Servers. A single copy of PI SMT manages multiple PI Servers. PI SMT runs on either a PI Server Node or a PI Interface Node.

Pipc.log

The pipc.log file is the file to which OSIsoft applications write informational and error messages. When a PI interface runs, it writes to the pipc.log file. The ICU allows easy access to the pipc.log.

Point

The PI point is the basic building block for controlling data flow to and from the PI Server. For a given timestamp, a PI point holds a single value.

A PI point does not necessarily correspond to a “point” on the foreign device. For example, a single “point” on the foreign device can consist of a set point, a process value, an alarm limit, and a discrete value. These four pieces of information require four separate PI points.

Service

A Service is a Windows program that runs without user interaction. A Service continues to run after you have logged off from Windows. It has the ability to start up when the computer itself starts up.

The ICU allows you to configure a PI interface to run as a Service.

Tag (Input Tag and Output Tag)

The tag attribute of a PI point is the name of the PI point. There is a one-to-one correspondence between the name of a point and the point itself. Because of this relationship, PI System documentation uses the terms “tag” and “point” interchangeably.

Interfaces read values from a device and write these values to an Input Tag. Interfaces use an Output Tag to write a value to the device.

PI BACnet Interface1

Chapter 1.Introduction

The Building Automation and Control Network or BACnet protocol was designed to allow building systems to communicate with each other and to allow users to write external applications that can send requests to the BACnet devices or retrieve information from them. Systems that normally communicate with the BACnet protocol are HVAC equipment, Fire/Life safety, lighting control and other building automation systems.

The PI BACnet Interface is a BACnet interface for the OSIsoft PI System. The interface uses the BACnet/IP Datalink layer which implements the BACnet Virtual Link Control (BVLC) for networking using UDP/IP and conforms to the ANSI/ASHRAE Standard 135-2004: BACnet – A Data Communication Protocol for Building Automation and Control Networks Annex J.

The PI BACnet Interface is read-only and does not support writing values back to the BACnet controllers. The PI BACnet Interface can communicate with any device using BACnet/IP which is a UDP based protocol. The PI BACnet interface can also communicate to other devices which use different BACnet protocols via a BACnet Gateway or a BACnet Router. The BACnet devices or routers do not need to be on the same subnet as the interface. The data can be obtained from the BACnet controller by either polling for the data on a specific frequency or by using the BACnet Change-Of-Value (COV) protocol which allows the BACnet Controller to send data as it changes without the interface having to request the data.

The PI BACnet Interface will support the ability to read the following BACnet objects Types:

Analog Input

Analog Output

Analog Value

Binary Input

Binary Output

Binary Value

Loop

Multi-State Input

Multi-State Output

Multi-State Value

Life Safety Point

Life Safety Zone

Accumulator

The PI BACnet Interface supportsUniInt Phase 2 Failover.

Reference Manuals

OSIsoft
  • PI Server manuals
  • PI API Installation manual
  • UniInt Interface User Manual

Vendor

ANSI/ASHRAE Standard 135-2004: BACnet - A Data Communication Protocol for Building Automation and Control Networks

Supported Features

Feature / Support
Part Number / PI-IN- OS-BACN-NTI
* Platforms / 32-bit Interface / 64-bit Interface
Windows XP
32-bit OS / Yes / No
64-bit OS / Yes (Emulation Mode) / No
Windows 2003 Server
32-bit OS / Yes / No
64-bit OS / Yes (Emulation Mode) / No
Windows Vista
32-bit OS / Yes / No
64-bit OS / Yes (Emulation Mode) / No
Windows 2008
32-bit OS / Yes / No
64-bit OS / Yes (Emulation Mode) / No
Windows 2008 R2
64-bit OS / Yes (Emulation Mode) / No
Windows 7
32-bit OS / Yes / No
64-bit OS / Yes (Emulation Mode) / No
APS Connector / No
Point Builder Utility / No
ICU Control / Yes
PI Point Types / Int32 / Int16 / Digital / Float 64 / Float32 / Float16 / String
Sub-second Timestamps / No
Sub-second Scan Classes / No
Automatically Incorporates PIPoint Attribute Changes / Yes
Exception Reporting / Yes
Outputs from PI / No
Inputs to PI: Scan-based / Unsolicited / Event Tags / Scan-based/Unsolicited
Supports Questionable Bit / No
Supports Multi-character PointSource / Yes
Maximum Point Count / Unlimited
* Uses PI SDK / No
PINet String Support / N/A
* Source of Timestamps / PI Server
History Recovery / No
* UniInt-based
* Disconnected Startup
* SetDeviceStatus / Yes
Yes
Yes
* Failover / UniInt Failover (Phase 2, Hot, Warm and Cold)
* Vendor Software Required on PI Interface Node / PINet Node / No
Vendor Software Required on Foreign Device / No
Vendor Hardware Required / No
* Additional PI Software Included with Interface / Yes
Device Point Types / Real/Digital/Integer/String
Serial-Based Interface / No

* See available paragraphs below for further explanation.

Platforms

The Interface is designed to run on the above mentioned Microsoft Windows operating systems and their associated service packs.

Please contact OSIsoft Technical Support for more information.

Uses PI SDK

The PI SDK and the PI API are bundled together and must be installed on each PI Interface node. This Interface does not specifically make PI SDK calls.

Source of Timestamps

The interface uses the PI Server time as the source of timestamps for the values sent by the PI BACnet interface. The interface writes a timestamp that reflects the time at which it receives data from the BACnet devices.

UniInt-based

UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft-developed template used by developers, and is integrated into many interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of OSIsoft’s interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt-based interface, the interface uses some of the UniIntsupplied configuration parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.

The UniInt Interface User Manual is a supplement to this manual.

Disconnected Start-Up

The PIBACnet interface is built with a version of UniInt that supports disconnected start-up. Disconnected start-up is the ability to start the interface without a connection to the PI server. This functionality is enabled by adding /cachemode to the list of start-up parameters or by enabling disconnected startup using the ICU. Refer to the UniInt Interface User Manual for more details on UniInt Disconnect startup.

SetDeviceStatus

The PI BACnet Interface supports health tags. The Device Status health tag has its point attribute Exdesc set to [UI_DEVSTAT] and is used to represent the status of the source device. The following events can be written into this tag:

  • "Good" – the interface is communicating with all BACnet Devices assigned to this interface.
  • "1 | Starting | UI x.x.x.x" – the interface is starting.
  • "3 | n BACnet device(s) in error | message" – The number of BACnet Devices not operational.
  • "4 | Intf Shutdown" – the interface is shutting down.
  • "5 | n BACnet Object(s) in error | message " - The number of BACnet Objects not operational.

Please refer to the UniInt Interface User Manual.doc file for more information on how to configure health points.

Failover

  • UniInt Failover Support

UniInt Phase 2 Failover provides support for cold, warm, or hot failover configurations. The Phase 2 hot failover results in a no data loss solution for bi-directional data transfer between the PI Server and the Data Source given a single point of failure in the system architecture similar to Phase 1. However, in warm and cold failover configurations, you can expect a small period of data loss during a single point of failure transition. This failover solution requires that two copies of the interface be installed on different interface nodes collecting data simultaneously from a single data source.Phase 2 Failover requires each interface have access to a shared data file. Failover operation is automatic and operates with no user interaction. Each interface participating in failover has the ability to monitor and determine liveliness and failover status. To assist in administering system operations, the ability to manually trigger failover to a desired interface is also supported by the failover scheme.

The failover scheme is described in detail in the UniInt Interface User Manual, which is a supplement to this manual. Details for configuring this Interface to use failover are described in theUniInt Failover Configuration section of this manual.

Additional PI Software

The PI BACnet Query Tool allows a user to test the connection of BACnet devices on the network. It also allows a user to create BACnet PI tags directly using the PI SDK or to produce a CSV file for consumption by PI SMT to create PI Tags. The Query Tool supports the following BACnet Commands:

  • WhoIs Function – The WhoIs function returns a list of all BACnet devices that are listening on the current network subnet or a specific IP address. If a devices shows up on the WhoIs list, it can be accessed by the PI BACnet Interface.
  • ReadProperty Function - The ReadProperty function can be used to pull single values from BACnet objects.
  • COV Function – The query tool allows the testing of the BACnet COV commands.

Device Point Types

BACnet information is represented by collections of objects on each BACnet device. The objects can consist of one data point or groups of related data points. Each object has a set of required properties and optional properties depending on the equipment vendor. To read information from BACnet the Device, object, object type and object property must be known.

A list of all supported object types can be found in Appendix C. BACnet Object Types and a list of supported BACnet Object Properties in Appendix D. BACnet Object Properties.

The object property values that are returned to PI can be either numeric or string values.

Diagram of Hardware Connection