The BACnet Points List and PICS: What a BAS Submittal Has to Prove

The controls package comes back with two comments you did not see coming: "Provide PICS for all BACnet devices" and "Points list does not reflect the sequence of operations." The datasheets were perfect. The wiring diagrams were perfect. But the engineer reviewing a building automation system is not only asking what you are installing. They are asking what the owner's front end will see when it discovers your controllers, and whether those controllers can actually hold the conversation the spec requires. The points list answers the first question. The PICS and the BTL listing answer the second.

This article is the column list for a points list a reviewer can check, what a PICS and a BTL listing prove, and the review checks both have to survive.

Why the two travel together

A points list is a promise about data: every value the system exposes, what it is called, where it lives, and how it alarms and trends. A PICS is a promise about capability: which parts of the BACnet standard a device implements. One without the other leaves a gap. A points list full of trended values means nothing if the controller cannot host a trend log, and a capable controller means nothing if nobody wrote down what it will serve.

That is why a typical BAS spec, whether it sits in Division 25 or in 23 09 00, asks for both in the same submittal as the controller product data. Where the spec puts that requirement is worth checking on your job; the split between those two homes is covered in Division 25 vs 23 09 00.

The points list, column by column

One row per point, grouped by device. The columns below are the ones reviewers look for. Your spec may add more, and some owners hand you their own template, which wins over anything here.

Point name. The object name the front end will display. Most owners with an existing system have a naming standard, often built from building, system, equipment, and point, and the spec either includes it or tells you to get it from the owner. Use it exactly. A points list with names in your house style becomes a renaming job during integration that nobody budgeted for.

Object type and instance. Analog input, binary output, analog value, multi-state value, and so on, plus the instance number. Instances must be unique per object type within a device. Hardware points and software points both belong on the list; a setpoint living in an analog value is as much a point as a temperature sensor on a terminal.

Device. The controller that hosts the point, by its device instance and its tag. Device instances must be unique across the whole BACnet internetwork, not just your trunk, and on a campus the owner usually assigns ranges. Ask for your range before you number anything.

Units. The engineering unit from the BACnet enumeration: degrees Fahrenheit, percent, cubic feet per minute, inches of water. "No units" on an analog point is a comment waiting to happen.

Alarm settings. High and low limits, deadband, time delay, and the notification class or priority the alarm routes to. If the spec says alarms are configured during commissioning, say "per commissioning" on the row rather than leaving it blank. Blank reads as forgotten.

Trend settings. Interval or change of value, and the change of value increment where it applies. Specs often require trending on every hardware point plus named software points, and the reviewer will count.

Description. A plain sentence an operator would understand. "Supply air temperature, AHU-1, downstream of cooling coil" beats "SAT".

Two more columns earn their space on most jobs: whether the point is commandable or read-only, and the I/O terminal for hardware points. The terminal column ties the points list to the wiring, the same tag discipline that runs through I/O lists, instrument indexes, and loop drawings.

One filled example

Part of a points list for one air handler controller:

Every row can be checked against the sequence: if the sequence says the fan alarms on a status mismatch, the row says so, with the delay.

What a PICS proves

The Protocol Implementation Conformance Statement is a form defined by ASHRAE 135, the BACnet standard, filled out by the manufacturer for a specific product. It is the device's own declaration of what it supports. The parts a reviewer reads:

• Product and version. Vendor, model, firmware or application software revision, and the BACnet protocol revision it implements.
• Device profile. The standardized profile the device claims, such as building controller, advanced application controller, or application specific controller. Specs usually name the minimum profile for each tier of controller.
• Interoperability building blocks. The BIBBs list: which data sharing, alarm and event, scheduling, trending, device management, and network management services the device supports, and whether as client or server.
• Objects. Which object types it supports, and which properties are writable or creatable.
• Data link layers. BACnet/IP, MS/TP, and which baud rates.
• Network options. Whether it can route, act as a BBMD, or segment messages.

The PICS is how a reviewer confirms your points list is possible. If the list shows trend logs hosted in a controller, its PICS had better list trending. If the spec wants scheduling at the field level, the application controllers need the scheduling blocks.

What a BTL listing proves

The PICS is a claim. A BTL listing is a tested claim. BACnet Testing Laboratories, run under BACnet International, tests products against the standard and publishes the ones that pass. Many specs require every BACnet device to be BTL listed, or listed to a minimum profile.

The listing names the product and the firmware revision that was tested. That detail matters: a controller listed on an older firmware is not automatically listed on the one you will ship. Print the listing page for each device, match the firmware to what you are installing, and put it beside the PICS. If a device on your list is not BTL listed and the spec requires it, that is a deviation, and it belongs on the transmittal, not in a footnote.

What the reviewer checks

Expect these, roughly in this order:

1. Every controller on the equipment schedule has a PICS and, if required, a BTL listing.
2. Each device's profile meets the minimum the spec names for that tier.
3. The BIBBs support what the spec requires: alarming, trending, scheduling, and whatever the front end needs to write.
4. Every point the sequence mentions appears on the list, and every point on the list is used by the sequence or required by the spec.
5. Names follow the owner's standard. Device instances fall in the assigned range and do not collide.
6. Units are present on analog points. Alarm limits and trend settings match the spec's minimums.
7. Integration points from third-party equipment, such as chillers, drives, and meters through a gateway, appear on the list with their source.

The usual bounces

• PICS for the building controller, nothing for the terminal unit controllers, because there are two hundred of them and they "are all the same." One PICS covers one model; attach it once per model, but attach it.
• A BTL listing for a firmware version two years old.
• Points named in the integrator's convention when the spec named the owner's.
• Software points missing entirely: setpoints, modes, and calculated values the sequence depends on.
• Gateway points listed as "per manufacturer," with no names, units, or object types. The reviewer needs to see what the chiller will actually expose, so get that list from the chiller vendor early.
• A points list that predates the last sequence revision. Every sequence change touches the list; sequence of operations covers why the sequence is the document the list must follow.

How Submittal Kit handles this

Chasing the same PICS and BTL page for the same controller model on every job is wasted afternoon. In Submittal Kit you attach them to the part once, through the part's Datasheets, Manuals, and Other lists in part documents, and every package that includes that controller carries them. Mark a document Always full sheet so a short-scope package ships the whole PICS instead of only the highlighted pages. The points list itself is your own file; give it a named home in the package with a Custom Upload section from configure sections, placed right after the controller product data. The compiled submittal package binds it all with bookmarks for every section and item.

Disclosure: I build Submittal Kit. The points list and the PICS check work the same in a spreadsheet and a PDF binder.