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.
The Niagara Framework (NF) is developed by Tridium, and if you visit the company’s website, you will learn Niagara is a “comprehensive software platform for the development and deployment of connected products and device-to-enterprise applications.” If you’re like most FMs and property owners, that description sounds pretty technical and dense, as if it were written in a different language. Ironically, the notion of miscommunication within different languages illustrates perfectly what the Niagara Framework is and, more accurately, what it attempts to solve.
Let’s try to clarify Tridium’s definition by breaking it down into parts, so that by the end of this article you should have a better idea of what Niagara does. We’ll start with a simple thought experiment, then take a deeper dive into how Niagara helps buildings and devices communicate.
Niagara: The Ultimate Travel Adapter
Imagine you’re going on an overseas vacation and need a travel adapter. While at the airport waiting to take off, you spot an adapter in a retail store window. However, it’s not just any old travel adapter, it’s the Ultimate Travel Adapter, equipped with hundreds of outlets for every country, region and plug type imaginable. What’s more, the adapter has older plugs styles, so now you can charge that ancient iPod you brought along. Imagine you bought such a product. What could it do for you?
For one, it would give you the flexibility to buy and use any device you wanted. It would free you from having to use one brand. It would eliminate compatibility issues. Plus, it would let you plug all your devices into one place, simplifying the management of all your electronics.
The Niagara Framework functions like the Ultimate Travel Adapter, connect all of your devices and platforms together into one architecture. You can find a Tridium explainer video here.
Next, imagine your adapter has controls for managing each device. It also comes equipped with a dashboard that shows power consumption, current status, and security alarms. Even better, you’re able to access all of this valuable information online. With such a digital tool, you could save energy by unplugging unneeded components, quickly identify failed devices and better predict outages. In short, you could save time and money by increasing your efficiency.
Finally, image your travel adapter itself adapts to the changing technological landscape. After all, plug styles come and go, and so your adapter must also adapt or risk becoming antiquated. Such an adaptation feature could help extend the life of your equipment, letting you bring your favorite devices into the future. It would give you considerable freedom and centralised control over your travel itinerary.
This, in a nutshell, is what the Niagara Framework platform does: it works as a “architecture” for connecting systems and devices for building operation and automation. Now let’s take a deeper dive into how devices and systems communicate to better understand Niagara’s role.
Protocols: The “Language” of Machines
Dozens of systems and hundreds of pieces of hardware make up modern buildings, and each of these components must communicate with one another. To accomplish this, building devices must share a common “language” or what engineers call a protocol. The result is “interoperability” of devices, which is the main goal of platforms like Niagara. This is what Tridium means by “development and deployment of connected products” within their description.
The two dominant standard protocols for building devices are BACnet and LonWorks. These protocols are why your smart meter can transmit energy data to your BMS, even though two different companies made them. The two companies have agreed to design their products using these standard protocols so that you could integrate them easily. Another benefit of standard protocols is that you get to pick and choose which devices you want to use, as opposed to being locked into using propriety hardware from a single vendor (think Apple products).
Standard vs Open Protocols
There are two basic approaches to achieving interoperability of devices: standard and open protocols. Open protocols are when hardware designers use a propriety language for their devices, but “open” their protocol for public use. Access to the protocol gives other developers the “dictionary” for building gateways and interfaces, which “interpret” from one machine language to another. Essentially, the company is saying: Take our protocol and design something that will let other devices work with it. Developers use these open protocols to ensure interoperability between their products and others.
Standard protocols work by building consensus among many different developers to adhere to a standard machine language. So, a standard protocol isn’t proprietary but shared among the members. The upside to a standard protocol is that it requires no interpreter or gateway. Devices speak directly to one another right out of the box.
The Niagara Framework adopts a standard protocol stance towards development of building automation devices. That is, it attempts to wrangle the long list of standard device protocols under one umbrella platform—a type of protocol for protocols. But more than devices make up buildings. What’s this “device-to-enterprise application” all about?
Buildings: A Polyglot of Digital Voices
In addition to device languages, there are also standards and protocols for almost everything that helps your building and business function. For example, there are computing standard languages for the internet (IP or internet protocols). Then there’s programming languages for software, operating systems (Windows vs Mac) and computer networks. When you add it all up, buildings are a cacophony of digital voices singing ones and zeros to each other (#ITjokes).
To ensure these voices sing in unison, enterprise standards like CORBA, XML and DCOM were created. These standards attempt to translate between different operating systems, programming languages and computing hardware. They ensure interoperability of platforms. Without them, companies would be inundated with service calls and services would grind to a halt.
The Niagara Framework, again, connects devices to any enterprise applications within your buildings. Say you wanted to pass energy usage data through to your accounting software. Because it’s a flexible platform that facilitates interoperability, you can use Niagara to easily build these types of connections. This is what Tridium means by “device-to-enterprise application.”
The Internet Connection
One big advantage the Niagara platform brings to building automation systems and devices is wireless connections. It achieves this by using the internet to connect all your devices and controllers. Thus, it sits firmly within the market of platforms that utilise the Internet of Things (IoT) to give building owners and managers granular access to every component of their systems.
In hardwired connections, your BMS would communicate to, say, your HVAC controller through a wired connection. Hardwired connections limit your access. But Niagara wireless internet connection gives you access through web browsers from anywhere. Connection via internet opens up possibilities. For example, it makes connecting new devices much easier. Management is easier too. Check the status of your fire safety systems while at home or on vacation.
Now, give Tritium’s definition another read: “Niagara Framework is a comprehensive software platform for the development and deployment of connected products and device-to-enterprise applications.” Hopefully, you understand it a bit better now.
Summary
Many systems make up today’s buildings. Fire alarms systems, HVAC systems, access systems and security systems to name a few. Today, most modern buildings have automated the management and operation of these systems. The Internet of things has streamlined management of systems, with sensors, devices, and equipment sending streams of data back for collelction and display to stakeholders.
The Niagara Framework is essentially a system of systems, a software architecture designed to integrate multi-vendor building automation systems (BAS) under one umbrella platform. It improves flexibility in managing, connecting, and visualising of your properties and data.
