The BACnet BTL Testing Lab functions to test and certify that new BACnet-equipped devices will function as intended

Today’s HVAC units, lighting devices and other commercial and industrial devices can no longer function as stand-alone, independent units. Today’s commercial equipment buyers and owners expect these devices to operate as part of a system that can be managed and monitored together. 

This is why it’s imperative that today’s equipment manufacturers implement Building Automation and Control network protocols to ensure that their devices can work together with each other and other manufacturer’s devices. Not doing so at this point puts them well behind the curve from a technology and feature standpoint and gives all of their competitors a major differentiator and a competitive advantage. 

In this environment, it’s understandable that equipment manufacturers are pushing their engineers and product development teams to get these protocols implemented and integrated into their devices. There is one thing that every company needs to know as they work to integrate Building Automation and Control network protocols, the most popular and accepted of which is BACnet, into their devices: 

It’s harder than it looks, and they should probably get some help. 

The perils of going alone

Many equipment manufacturers are incredible at making boilers, or air conditioners, or elevators.  It’s what they know, and what they’re best at. What they’re not always good at is protocol development. In fact, most companies have to go out and hire a protocol engineer to spearhead their integration for them. 

While these companies are often aware that they’ll need to hire some new engineers to make an integration happen, they’re often unaware or even somewhat naïve about how long the process will take. 

It can take an equipment manufacturer up to a year and a half to internally develop a BACnet interface for just one of the two market-leading BACnet protocols: BACnet/IP and BACnet MS/TP. It can then take up to another year and a half to get the platform stable. 

When the development and integration is done, the protocol engineers need to stay. The company will need to continually support the product once it is released, meaning that the company’s protocol engineers need to remain onboard to continually support the BACnet implementation for the life of the product. This increase in overhead costs is not optional, as there are constant updates and changes to the BACnet protocol and the engineers are essential in ensuring that the product remains up-to-date.

The time to market and the increased overhead are really just the tip of the iceberg when it comes to BACnet integration problems that equipment manufacturers face. There’s also a good chance that the BACnet integration will stumble out of the gate and face interoperability issues. 

The protocol engineers spearheading an integration for an equipment manufacturer could interpret and implement BACnet differently. There is a chance that an engineer can misinterpret how some functionality should be implemented, creating massive interoperability problems. 

It was this specific issue that led to the BACnet organization introducing the BACnet BTL Testing Lab, which functions to test and certify that new BACnet-equipped devices will function as intended. 

The BACnet BTL Testing Lab functions to test and certify that new BACnet-equipped devices will function as intended.
The BACnet BTL Testing Lab functions to test and certify that new BACnet-equipped devices will function as intended.

Prior to the introduction of BTL Testing Lab, there were BACnet-enabled products that had problems speaking with each other and causing some significant interoperability issues in the field. That problem still persists today, often as a result of engineers interpreting things differently and introducing products that they claim are BACnet enabled but that aren’t BTL certified. 

Going it alone on a BACnet integration is clearly difficult, but it’s also bad for business. 

The bottom line Attempting to do its own BACnet integration can cost a company up to $400,000 and take up to three years. The BTL certification can add to the cost, and take from six months to a year to complete. That’s a scary statement, not because of the dollar amount, but because of the time frame. 

While a company is busy hammering out the kinks in a BACnet integration and going through the BTL testing process, their competitors that either did their own integration already or embraced a BTL certified gateway for their BACnet integration are already selling their BACnet-enabled devices. 

In the commercial and industrial equipment marketplace, it can be very difficult to unseat incumbent solution providers. Equipment owners are loyal to their brands and have a tendency to stick with them. This means that any potential customer lost to a competitor because their product was already BACnet enabled is a customer that could be lost for life. 

It could be even more damaging if a BACnet product is released with interoperability problems. This could lead to integrators charging the manufacturer for the time they spent debugging their products, which can be substantial. It can also lead to a damaged reputation for the equipment manufacturer, which can chase away both existing and potential customers in the future. 

The solution

If attempting a BACnet integration internally is both more trouble than it seems and potentially damaging to a manufacturer’s bottom line, then what’s the better alternative? 

As I discussed, manufacturers are very good at building incredible boilers, and air conditioners, and chillers and escalators, but they’re not great at protocol development. Why not outsource the protocol development to a company that is great at it? 

There is a universe of gateway manufacturers and solution providers that provide equipment manufacturers with gateways that are already BTL tested and certified, ensuring that any device that they’re integrated into will work with BACnet without any interoperability issues. Not only is this approach less risky, it also can be accomplished in months, instead of taking years. 

Also, BACnet represents just two of many protocols that are being used to connect industrial and commercial equipment and devices. There are numerous other protocols with significant buy-in and market share across the industry, including LonWorks, KNX, Metasys N2 Open and Modbus. Combined, these protocols make up more than 30 percent of the market worldwide. Integrating both BACnet protocols and these four additional protocols means six separate integrations for equipment manufacturers to spearhead and manage, each with their own challenges. 

Today’s gateways are modular in nature, capable of integrating and working with some or all of these different protocols by swapping out modules. This can give equipment manufacturers the ability to offer their customers integrations with multiple disparate protocols, and give equipment owners flexibility in the future. 

Protocol integrations are hard, and a protocol integration that takes too long or goes wrong can have long-lasting, negative effects on an equipment manufacturer. However, there is a viable, faster, cheaper and more effective solution available. Working with certified gateway solution providers can ensure that equipment manufacturers bring BACnet enabled devices to market quickly and efficiently, and ensure that their reputation for making exceptional products remains intact.

Implementing BACnet – why it’s harder than equipment manufacturers think

Today’s HVAC units, lighting devices, and other commercial and industrial devices can no longer function as stand-alone, independent units. Today’s commercial equipment buyers and owners expect these devices to operate as part of a system that can be managed and monitored together. 

This is why it’s imperative that today’s equipment manufacturers implement Building Automation and Control network protocols to ensure that their devices can work together with each other and other manufacturer’s devices. Not doing so at this point puts them well behind the curve from a technology and feature standpoint and gives all of their competitors a major differentiator and a competitive advantage. 

In this environment, it’s understandable that equipment manufacturers are pushing their engineers and product development teams to get these protocols implemented and integrated into their devices. There is one thing that every company needs to know as they work to integrate Building Automation and Control network protocols, the most popular and accepted of which is BACnet, into their devices: 

It’s harder than it looks, and they should probably get some help. 

The BACnet BTL Testing Lab functions to test and certify that new BACnet-equipped devices will function as intended.

The perils of going alone

Many equipment manufacturers are incredible at making boilers, or air conditioners, or elevators.  It’s what they know, and what they’re best at. What they’re not always good at is protocol development. In fact, most companies have to go out and hire a protocol engineer to spearhead their integration for them. 

While these companies are often aware that they’ll need to hire some new engineers to make an integration happen, they’re often unaware or even somewhat naïve about how long the process will take. 

It can take an equipment manufacturer up to a year and a half to internally develop a BACnet interface for just one of the two market-leading BACnet protocols: BACnet/IP and BACnet MS/TP. It can then take up to another year and a half to get the platform stable. 

When the development and integration is done, the protocol engineers need to stay. The company will need to continually support the product once it is released, meaning that the company’s protocol engineers need to remain onboard to continually support the BACnet implementation for the life of the product. This increase in overhead costs is not optional, as there are constant updates and changes to the BACnet protocol and the engineers are essential in ensuring that the product remains up-to-date.

The time to market and the increased overhead are really just the tip of the iceberg when it comes to BACnet integration problems that equipment manufacturers face. There’s also a good chance that the BACnet integration will stumble out of the gate and face interoperability issues. 

 

The protocol engineers spearheading an integration for an equipment manufacturer could interpret and implement BACnet differently. There is a chance that an engineer can misinterpret how some functionality should be implemented, creating massive interoperability problems. 

 

It was this specific issue that led to the BACnet organization introducing the BACnet BTL Testing Lab, which functions to test and certify that new BACnet-equipped devices will function as intended. 

 

Prior to the introduction of BTL Testing Lab, there were BACnet-enabled products that had problems speaking with each other and causing some significant interoperability issues in the field. That problem still persists today, often as a result of engineers interpreting things differently and introducing products that they claim are BACnet enabled but that aren’t BTL certified. 

 

Going it alone on a BACnet integration is clearly difficult, but it’s also bad for business. 

 

The bottom line Attempting to do its own BACnet integration can cost a company up to $400,000 and take up to three years. The BTL certification can add to the cost, and take from six months to a year to complete. That’s a scary statement, not because of the dollar amount, but because of the time frame. 

 

While a company is busy hammering out the kinks in a BACnet integration and going through the BTL testing process, their competitors that either did their own integration already or embraced a BTL certified gateway for their BACnet integration are already selling their BACnet-enabled devices. 

 

In the commercial and industrial equipment marketplace, it can be very difficult to unseat incumbent solution providers. Equipment owners are loyal to their brands and have a tendency to stick with them. This means that any potential customer lost to a competitor because their product was already BACnet enabled is a customer that could be lost for life. 

 

It could be even more damaging if a BACnet product is released with interoperability problems. This could lead to integrators charging the manufacturer for the time they spent debugging their products, which can be substantial. It can also lead to a damaged reputation for the equipment manufacturer, which can chase away both existing and potential customers in the future. 

 

The solution

 

If attempting a BACnet integration internally is both more trouble than it seems and potentially damaging to a manufacturer’s bottom line, then what’s the better alternative? 

 

As I discussed, manufacturers are very good at building incredible boilers, and air conditioners, and chillers and escalators, but they’re not great at protocol development. Why not outsource the protocol development to a company that is great at it? 

 

There is a universe of gateway manufacturers and solution providers that provide equipment manufacturers with gateways that are already BTL tested and certified, ensuring that any device that they’re integrated into will work with BACnet without any interoperability issues. Not only is this approach less risky, it also can be accomplished in months, instead of taking years. 

 

Also, BACnet represents just two of many protocols that are being used to connect industrial and commercial equipment and devices. There are numerous other protocols with significant buy-in and market share across the industry, including LonWorks, KNX, Metasys N2 Open and Modbus. Combined, these protocols make up more than 30 percent of the market worldwide. Integrating both BACnet protocols and these four additional protocols means six separate integrations for equipment manufacturers to spearhead and manage, each with their own challenges. 

 

Today’s gateways are modular in nature, capable of integrating and working with some or all of these different protocols by swapping out modules. This can give equipment manufacturers the ability to offer their customers integrations with multiple disparate protocols, and give equipment owners flexibility in the future. 

 

Protocol integrations are hard, and a protocol integration that takes too long or goes wrong can have long-lasting, negative effects on an equipment manufacturer. However, there is a viable, faster, cheaper and more effective solution available. Working with certified gateway solution providers can ensure that equipment manufacturers bring BACnet enabled devices to market quickly and efficiently, and ensure that their reputation for making exceptional products remains intact.

Democratizing the cloud for small and medium-sized OEMs

In some of our previous posts, we have laid out some benefits that OEMs can realize from cloud-enabling their devices. These benefits have ranged from providing better, more proactive service and repairs to equipment owners, to selling more service contracts, to helping eliminate warranty abuse. 

While we have discussed why an OEM would want to cloud-enable their devices, we haven’t talked about how to cloud-enable their devices. 

Many of the large, industry-leading OEMs out there have elected to do it themselves. They’ve hired teams of engineers and developers and given them budgets and resources to create gateways and other tools that enable their devices to connect to networks and, subsequently, the cloud. 

That’s great for the big companies. But how many OEMs can really afford to do that? How many small and medium-sized OEMs can bring on a team of dedicated engineers and developers to enable this capability? 

How many can dedicate budget dollars to cover their salaries and pay for the cloud servers and other tools that they’ll need to bring the capability from conception to reality? 

From my time in the industry, I can confidently say that very few can make that kind of investment. 

What does that mean for the small and medium-sized OEM? Does that mean that they can’t begin harvesting the data being generated by their equipment in the field? Does that mean that they can’t benefit from the knowledge about how their equipment is operating? Does that mean that they have to forfeit the benefits that cloud-enabled equipment and data analysis can deliver when it comes to developing new products and servicing their customers’ equipment?

No. Because there are other tools and pathways that can democratize the cloud and open the door to the cloud for these OEMs, even if their bank accounts aren’t on par with those of the big, internationally-known OEMs and global brands. 

Let’s look at two of them. 

The ever-expanding cloud ecosystem

Doing it yourself can save money in home renovations, but trying to build cloud capabilities for their own equipment can be prohibitively expensive for smaller OEMs. Cloud computing is big business. There is an ever-increasing universe of cloud providers owned by the world’s largest tech powerhouses that are competing for the infrastructure dollars of companies including,  Amazon Web Services (AWS), Microsoft’s Azure, Google Cloud and IBM Cloud. 

In an attempt to differentiate themselves and gain an advantage in the increasingly competitive and commoditized cloud market, these companies are constantly developing new tools and applications. From machine learning and AI tools to big data and data analytics tools, these cloud providers are constantly developing new solutions to help give their users more functionality and capability right out of the box. 

With the cloud becoming so pervasive across so many markets and industries, some cloud providers have begun developing applications and tools for specific industries. Some are beginning to launch IIOT and “Cloud with a Purpose” tools designed to help equipment owners and OEMs cloud-enable their devices and harvest data from them. 

This is a much more economical solution for OEMs than hiring a development team and bringing cloud capabilities to bear internally. However, it’s not all positive. 

Some technical know-how is still needed to implement and integrate these solutions in an OEM’s equipment. Also, these solutions are effectively cloud tools that have been developed by cloud companies for  OEMss The individuals that have developed these tools most likely lack a deep knowledge of OEMs, the equipment manufacturing industry and the requirements that these organizations have. 

This means that the solutions may not completely fit organizational needs and requirements. 

However, there is yet another solution for small and medium-sized OEMs looking to cloud-enable their equipment, gateways developed by companies with long histories of servicing the OEM market. 

They know you because they are you

A number of companies with deep industry knowledge and experience working with OEMs have begun developing gateways and other cloud-enabling tools that OEMs can use to get their devices in the field connected to the cloud and begin harvesting their data. 

The gateways being developed by these companies can be easily integrated into both new equipment, and equipment that’s already installed in the field. They can be integrated without a team of developers and engineers. Also, in contrast to tools being built by and within cloud vendors, these gateways are built to work across multiple protocols and to meet the specific needs and requirements of OEMs. 

Tools like these are the real leaders when it comes to democratizing the cloud for small and medium-sized OEMs. They’re built specifically for equipment manufacturers, require little cloud knowledge or expertise, and don’t require significant investment into new staff resources that are knowledgeable in development and the cloud. 

The benefits of the cloud shouldn’t be limited to the large OEMs that can afford to staff up with dedicated teams of developers, engineers and cloud experts. The cloud can be a game-changing tool for all OEMs of any size, and gateways, such as the ones offered by Sierra Monitor, are the best path to the cloud for OEMs that may struggle to find their way themselves.