In this article in our BACnet Basics Series, we look at Device Profiles, why they’re important and how they’re created. We’ve also included a real world example that illustrates how to use device profiles to accurately specify your own projects.
What are Device Profiles?
As we saw in BACnet Basics: What are BIBBs?, device functions come in five basic categories, each containing specific capabilities. For example, the category Data Sharing (DS) includes capabilities like Read Properties (RP), Write Properties (WP) or Change of Value (COV). If we combined all these services into a minimum collection of capabilities, we would be creating a device profile.
As an analogy, think of the profile “Automobile”. Every machine that claims to be an “automobile” needs the functions of Acceleration (A), Deceleration (D) and Maneuverability (M). Of course, there can be automobiles that do much more, but every “automobile” must, at minimum, perform these three functions (A,D,M).
Definition: BACnet device profiles define the minimum set of BACnet Interoperability Building Blocks (BIBBs) supported by a device claiming that profile. When a device claims a specific profile, you know that it contains a preset of specified functions and services. Profiles are handy because they provide a short-hand method for describing a device and its interoperability capabilities. Device profiles are organized into Groups and Families
Device Groups
Device Groups are general categories of device functions. There are four Group types:
Operator Interface—Covers the minimum capabilities for workstations and other user interface devices. Devices normally support A-side (Client) functionality.
Controller Device—Covers anything from programmable building controllers to smart sensors. Devices normally support B-side (Server) functionality, but more advanced supervisory controllers also include A-side (Client) functionality.
Control Station—Covers lighting control stations that are smaller client devices that support specific user controls such as manual light switches.
Basic Device—Covers all “miscellaneous” family functionality. Usually included alongside other device profiles.
Device Families
Each Profile Group contains various Families within it. Families cover profiles for various, supported building systems like Lighting, Life Safety, and General Purpose. For example, the Controller Device Group contains profiles for the following Family types:
(Example) Controller Family
General Purpose—General purpose controllers usually for HVAC and lighting.
Access Control—Access control controllers such as an access control panel
Lighting—Lighting controllers such as supervisory lighting controller
Life Safety—Life safety controllers such as a fire detection panel.
Elevator—Elevator controllers
Let’s zoom into the General Purpose profile family within the Controller Device Group and see what BIBBs it contains.
Building Controller (B-BC) —Field programmable and configurable supervisory controllers in HVAC and general purpose application.
Advanced Application Controller (B-AAC)—Controllers that run advanced HVAC or general purpose control applications.
Application Specific Controller (B-ASC)—Controllers that run specific HVAC or general purpose control applications.
Smart Sensor (B-SS)—Small sensors that provide sensor values to other devices.
BACnet device profile Families are organized in a container hierarchy. As you move up in complexity, you increase the minimum amount of BIBBS required. Like nesting dolls, each profile contains all the minimum profiles from the previous ones.
For example, the above General Purpose BACnet profiles increase in complexity as you move up from Smart Sensor to Building Controller. All BIBBS included in a Smart Sensor profile are always included in a Smart Actuator profile, and all the BIBBs included in those two profiles are always included in an Application Specific Controller, and so on.
Although higher level BACnet profiles contain more BIBBs, it’s not the number of profiles that matters. Each profile requires a minimum number and type of profiles. So, even if a device contains or exceeds the minimum number of BIBBs, it doesn’t guarantee it will meet the standard. It must contain the minimum number of the correct BIBBs to meet the profile standard.
Specifying Device Profiles: Boardroom Example
Let’s use the Device Profile Quick Reference Guide to see an example of how to choose the device profiles for a real-world project. Read the following scenario:
You want to outfit a medium-sized boardroom equipped with a control panel with a built-in controller. The panel will control the room’s temperature and lighting. You also need manual lighting controls near the door.
To determine the device profiles needed for the project, we can start by listing the functionality we need. We will need HVAC controls for temperature. For lighting, we will need controls for both the panel and a manual user control switch on the wall. Therefore, we will need functionality from the Controller Group and Control Station Group.
Next, we can determine what Families we need within each group.
For the Controller Group, we need:
General PurposeFamily for HVAC
Lighting Family for panel control lighting
Access ControlFamily for access
For the Control Station Group, we need:
Lighting Family for manual switch lighting control
Finally, we can choose specific profiles to fulfill our HVAC and lighting functionality.
HVAC Profiles
In the Reference Guide, we see the following profiles for the General Purpose Controller Family:
B-BC: The building controller is intended for field programmable and configurable supervisory controllers in HVAC and general purpose applications.
B-AAC: The advanced application controller is intended for controllers that run advanced HVAC or general purpose control applications. It does not require being configurable through BACnet.
B-ASC: The application specific controller is intended for controllers that run specific HVAC or general purpose control applications. It does not require being configurable through BACnet.
B-SA: The smart actuator is intended for small actuator devices that allow being commanded.
B-SS: The smart sensor is intended for small sensor devices that provide sensor values to other devices.
We can ignore the last two profiles, because we need neither actuators (B-SA) or sensors (B-SS) for the project. We can also eliminate the Building Controller (B-BC) profile because it does not require supervisory control. Depending on our HVAC needs, we could choose either the Advanced Application (B-AAC) or the Application Specific (B-ASC) profile.
Lighting Profiles
In the Reference Guide, we see the following profiles for the Lighting Controller Family:
B-LS: The lighting supervisory controller is intended for controllers in lighting applications that can command and operate subordinate lighting controllers, in particular through group write commanding.
B-LD: The lighting device is intended for lighting controllers that control individual lights or groups of lights. Normally used as leaf nodes in lighting group setups.
We would choose the B-LD profile if the panel only controls one group of lights. However, if the lighting is more complex, we might opt for the B-LS with supervisory controls.
Control Station Profiles
Because the room also requires manual user lighting controls, we need a profile from the Control Station Family. In the Reference Guide, we see the following profiles:
B-ALCS: The advanced lighting control station is intended for sophisticated control stations that support user view, control and limited configuration of lighting functionality. Provides full commanding support of lighting objects and group operations for them.
B-LCS: The lighting control station is intended for control stations that support simple control of lighting functionality and limited status indication. Provides limited support of commanding lighting objects.
The simpler B-LCS would work for this project. But, again, depending on the complexity of the room’s lighting, we might choose the more complex profile.
Conclusion
Through the Boardroom Example above, we can see how BACnet profiles make project specifications easier and more accurate. Standards and profiles support an accurate procurement process, requiring less change orders and adjustments. Defining capabilities also creates an outcomes-based workflow so that buildings function the way owners and tenants need them to.
Every complex topic or field needs a helpful naming system. Scientists name flora and fauna by genus and species. Even astronomers have their own planetary nomenclature. Standard naming conventions do just that—they standardize how we talk about things. They’re also a convenient way to condense large amounts of information into a short form. Hence, they function like acronyms. We needn’t sound out “self-contained underwater breathing apparatus” when we can simply utter S.C.U.B.A. right?
In building automation, the same need for standards and compression applies, and BACnet gives us a convenient way to describe the functionality of devices using something called BIBBs.
What are BIBBs?
Definition: BIBBs stands for “BACnet Interoperability Building Blocks” and is a standard naming convention for representing specific device capabilities using simple acronyms. That is, it creates simple categories to describe how one device works with another.
Without short-form descriptions, listing all the capabilities and services that a device offers would turn functional descriptions into a messy scrawl of technical jargon. By condensing these functions into acronyms, BIBBs makes it easier for FMs, system integrators, and building engineers to talk about the same things. BIBBs help buyers get the minimum number of services for the job without over-engineering and spending for extraneous functionality.
BIBB Categories
The BIBB naming system starts with five broad categories that list interoperability functions. These are high level functions that host specific capabilities within them. Categories include:
Data Sharing (DS)
The data sharing function describes how devices exchange data. Data sharing is essential for reading and writing data from one device to another. For example. If you wanted to regularly check the water temp of your boiler to monitor its performance, you would need the DS functionality.
Alarm & Event Management (AE)
The alarm and event management functionality is for detecting and notifying alarms and events. For example, if your boiler temps exceeded a specified setpoint, the AE function would allow you to receive an alert.
Scheduling (SCHED)
The scheduling functionality is for scheduling values based on date, time, and calendar. For example, if you wanted to schedule your boiler to provide after-hours heating for tenants.
Trending (T)
The trending functionality is for trend logging and historical data support. For example, if you wanted to store your boiler’s temp data to create a history for your engineer.
Device Management/Network Management (DM/NM)
The DM/NM is for setting up device and network management. It allows devices to discover each other, to synchronize clocks, and to reset a device to factory settings (reinitialize). For example, if you wanted to discover a newly installed boiler temp sensor.
Specific Capabilities
Specific capabilities, or sometimes called services, are distinct functions that exist within a BIBBs category. Capabilities also have acronyms. For example, the Read Property (RP) service is under the data sharing (DS) category. The service must exist for data sharing to occur. That is, a device (e.g., controller) must be able to read data, while another device (e.g., thermostat) must be able to send it. Many devices have both capabilities. Here are some examples of services for different BIBBs categories:
Data Sharing (DS)
Read Property Multiple (RPM)
Write Property (WP)
Change of Value (COV)
Alarm & Event Management (AE)
Notification (N)
Alarm Summary (ASUM)
View Notifications (VN)
Device and Network Management
Dynamic Device Binding (DDB)
Text Message (TM)
Reinitialize Device (RD)
Find a more extensive list of device capabilities here.
Clients and Servers
BIBBs also distinguishes between clients and servers, assigning and A and B category to each respectively. Client devices (A) can initiate or call for data or service from a device that can respond to that request (B). An example of this would be a controller (A) requesting temp data from a thermostat (B), which responds with the requested data. You can remember this order by recalling that the letter “A” comes before “B” in the alphabet, just as a request must precede a response.
Putting It All Together
Now that we have all three parts of BIBBs, let’s look at a full interoperability description. The BIBBs naming syntax places the category first, specific capability second, and server/client designation third. Each acronym is separated by a dash. Consider a BACnet controller that has data sharing (DS), a read property service (RP), and client capability (A). It would be designated as DS-RP-A. Can you guess what functionality a thermostat would require to send temp data back to the controller? If you answered DS-RP-B, you’re correct!
Conclusion
As we’ve seen, BIBBs are the “building blocks” of the standardized system of naming devices and their interoperability functions. Devices can have many different functions, so there’s also a need to group them. For example, controllers, sensors, and actuators must all have a minimum number of specific functions to work. These groups of functions are called BACnet device profiles. Like BIBBs acronyms, profiles give us a shorthand way of quickly designating and describing a device. Read BACnet Basics: What are Device Profiles? to learn more or visit The BACnet Institute for free training.
Buildings are responsible for a significant chunk of emitted green house gases (GHGs) into the atmosphere. Therefore, they’re a leading contributor to global warming. In the U.S., buildings account for 40% of all U. S. primary energy and its associated GHG emissions. While these stats appear bleak, they actually represent a positive when it comes to FMs and owners. Because property owners and managers helm the ship of the Built Environment, they have the power to steer decarbonization efforts in the right direction. By adopting smart technology and building automation, property owners can significantly contribute to GHG reduction while saving money and futureproofing their investments.
With building decarbonization, small changes can make a big difference. Automating your after-hours HVAC program is an easy first step to reducing your property’s carbon footprint. You don’t need to take out a loan to invest in automation tech either. Online tools like cloud-based after-hours HVAC apps are inexpensive and simple to integrate with your existing BMS.
Cut Mistakes, Cut Waste
While after-hours request programs vary, the standard process works like this: the tenant fills out a work request for after-hours air conditioning or heating. Staff members record the request. The building engineer programs the HVAC to fulfill the request. The air con/heating is delivered at the require day and time. The property manager invoices the tenant at the end of the month.
Every step in this manual request process is an opportunity for errors to crop up. Forgotten emails, data entry mistakes and missed change requests are all more likely with a manual process. Mistakes cost time and energy, whether its extra lighting, access gates, lift rides or added HVAC service itself.
After-hours HVAC booking apps replace these manual step with wireless technology and network connections. Tenants create requests via a mobile or desktop app. The system then interfaces with the building’s BMS to schedule the request. The tenant, time and date are automatically logged, and the BMS delivers heating and air con on the requested days. By automating these steps, you cut out the wasted energy and help lower your carbon footprint.
Push Buttons vs. Cloud-Based Apps
Push button systems for activating HVAC service eliminate some, but not all, of the manual steps. They’re designed to deliver service as requested, giving tenants easy access to and control over HVAC operation. However, their openness can be a liability. Since anyone within the building can request service, savings from push button controls are often undermined by their public access.
There are no guards against everyone (ex. maintenance or cleaning staff) from accessing controls. So, unauthorized access can lead to unaccounted and wasted energy use. It’s also easy for occupants to “hit the button” minutes before leaving the room or floor, resulting in wasted energy from heating and cooling unoccupied spaces.
After-hours HVAC apps reduce energy waste by limiting access to the platform. In a cloud-based system, only authorized users can create HVAC requests. And the system records both the request and the requester. So owners always know who requests services. Plus, tenants can re-schedule and cancel bookings from anywhere there’s an internet connection. This helps save energy by eliminating empty room heating and cooling.
Data Equals Decarbonization
Automation goes hand-in-hand with data. Today’s smart sensors, IoT devices, machine learning, AI, digital twins, and BMS integration all point to the eventual integration of every building systems. In the near future, fire systems will “talk” with access systems to track occupants during an emergency. Access systems will work in tandem with HVAC systems to adjust heating and cooling demands based on occupancy levels. Building management systems will connect to utility providers to shift energy usage during peak demand. Such interoperability is already evolving, but it requires data to work properly.
By automating your HVAC requests, you can collect data on how and when your tenants are requesting HVAC services and use it to conserve energy. For example, you can identify seasonal trends and make targeted improvements and retrofits for specific zones of your property. Automation puts you in a better position to transition your property into a smart building and futureproof your assets.
Software-as-a-service (SaaS) is a growing trend in FM because of several advantages cloud-based services deliver over in-house development. For one, it’s generally cheaper to outsource your software needs rather than spend time and money developing a bespoke solution. Ramp up time is much faster too. The general wisdom is that FMs get a better product by letting the market do the heavy R&D lifting. Data accessibility and security is generally equivalent or comparable to in-house IT, provided you do your homework. To that end, here are some key SaaS components to consider during the procurement process. Download this SaaS procurement checklist for quick reference.
Mobile Access
Remote and hybrid work schedules are on the rise. Your team and your clients need the flexibility of mobile access to stay competitive. Look for a cloud-based software with admin/client access to most features, dashboards and data via mobile device and web browser.
Customer Support
Customer support is essential to seamless integration and service continuity, so invest some time here. Take advantage of free demos and trial periods to kick the tires on a vendor’s customer service. Submit a work order and note things like response times, professionalism, expertise and problem solving.
Pro Tip: If possible omit your company affiliation when creating a demo account. Companies often give a potential enterprise account better service than a single user.
Training Resources
Training resources ensure a smooth integration, and any SaaS vendor worth their salt will offer a healthy library of video tutorials, how-to guides, in-office training and online resources for you and your staff. Have your staff sample a few offerings and rate them for accessibility, clarity and ease-of-use.
Data Security
Given the rise in ransomware attacks, data security is a priority, and most SaaS platforms collect some data on you and your users. Data storage, collection and encryption are a security and compliance issue, so ask about these practices. If a vendor isn’t forthcoming, it may be a red flag. Look for security standards and certifications for cloud-based software. These credentials might include Cloud Industry Forum certification or compliance with international standards for cloud-based security such as ISO-27001.
Data Ownership
Who owns your data is also a key consideration, especially when and if you ever switch to another vendor. So, ask about the data transfer process to other platforms. How complicated is retrieval? Can you simply download a spreadsheet or does the vendor collect it for you? The vendor may claim rights to your data beyond the contract end date. Does this violate your own privacy policies? Ensure these data ownership topics are clearly spelled out in your SLA.
Integration
Software platforms need to easily integrate with your connected systems, like your BMS, CRM or billing software. Check the vendor’s list of supported brands and models. But even if your systems are supported, the integration process may take more time than you want. Ask for a time frame for getting up-and-running with the platform before making your final procurement decision.
Pricing Model
SaaS companies often use their pricing schemes to “hide” add ons and upsells for new features after purchase. Read their pricing page carefully. Even if the annual plan is cheaper, it may contain stipulations like extra costs for adding accounts or transactions. Month-to-month plans will have limited features, so check the pricing comparison list to see which ones you’ll be missing out on with a basic plan.
Pro Tip: If a platform offers “custom” pricing for enterprise accounts, take the opportunity to negotiate a lower price based on your evaluation of the product. For example, the lack of adequate training resources might justify a lower annual price.
Customer Reviews
For real-world usability, go to the source: customers. Review sites like Capterra and G2 Crowd offer descriptions and consumer ratings of all types of products. Sites like these also let you make an apples-to-apples comparison of SaaS platforms, their features and prices.
Usability
Ill-designed SaaS platforms erode their effectiveness, so evaluate these key usability components:
User Interface
Pages, buttons and menus are organised in a logical way
There is a consistent look (i.e., colors and textures) from area to area.
The font is easy to read
Navigation
It’s easy to locate information
There’s a smooth flow when performing steps in a task
You can perform the same task from multiple places
Responsiveness
The website loads quickly
The interface works well on mobile devices and small screens
Also keep in mind that an ineffective interface is harder to learn, which can length the training process and cost you time and money.
Growth
Finally, during your SaaS procurement, decide whether your chosen SaaS will grow with your business. Does the company have a track record of innovation and growth? How easy is it to add new accounts for future employees? Is there a limit on the number of users? Does the company have plans for expanding features? Answering these questions and others like them will get your better idea of whether a specific SaaS will meet your future needs.
