What is an Open BAS?

Hey folks, Phil Zito here and welcome back. In this post, we're going to be discussing what is an open building automation system. This topic has been getting a lot of noise lately on social media and on YouTube. So, I wanted to revisit an article we wrote a while ago about how to evaluate a building automation system where we go through what an open building automation system is and what are the types of openness in building automation systems. We're going to go through some criteria related to how to evaluate each type of openness and we're going to go through some spec language that you can utilize if you're a specifier, contractor, or an owner.

To begin, I'm going to say something a little bit provocative, and that is, nothing is truly open. No building automation system, whether they brand themselves as an open building automation system, is truly open. Here's why: Take whatever system that is available through most procurement channels. Can you use someone else's tools to program that system? The answer, as far as I've ever seen, is no. So, there is no system that I'm aware of in the building automation space, where you can take someone else's tools, their software development tools, and the programming tools, and create stuff on that system. And in my opinion, that's not a bad thing.

I do want to say that anyone who says there are open systems, there are not truly open systems, there are flavors of openness. So, what are the flavors of openness? Well, as far as I'm concerned, having worked on a ton of different systems, a lot of different projects, it comes down to four criteria:

1. Open procurement, meaning you can easily get access to the product and or software.
2. Open protocol, meaning that the system uses common protocols that enable integration.
3. Open API's and data exchange.
4. Open tools and software.

So, let's dive into what most people think when they hear openness. For a good chunk of the market, if you ask them what an open building automation system is, you'll get two primary answers.

1. The product is available, anyone can get access to it.
2. The software is available, anyone can get access to it.

So, that comes down to procurement. So, at the beginning of our 10 or 11 part series on how to evaluate a building automation system, we first look at openness. We come to open procurement first and that is because people want to be able to buy the product. They don't want someone who has a stranglehold on availability of the product.

Could you imagine if you went to Home Depot, or you went to Lowe's, and they were the only ones who could sell you nails or screws. Now, arguably, control systems are way more complicated than screws and they're way more complicated than nails, but if you could only buy that through one person, that person could dictate price. They could say, “Hey, you can't have that.” They could put stipulations around when you could and could not have a product. So, being able to support a facility, being able to deliver projects within the open market requires open procurement.

Nowadays, most manufacturers have a product line that is available throughout the market. They may require you to sign up as a dealer, they may require you to have some form of certification, but I will tell you, when I first started in this industry, everyone had their own product. It was a very closed channel and primarily you went to the OEMs. That's where you were able to get your product, that's where you were able to get your service, that's where you were able to get your installation. Nowadays, you can Google most controllers and you can find them on the secondary market through resell. Sometimes that's allowed, sometimes that's not allowed, through terms and conditions, but you can definitely find, for pretty much every OEM out there, they have a product. You can find some sort of supplier or distributor who provides the product.

I'm going to go through the pros and cons of each criteria. We'll go through, how do we rank that, and we’ll go through how do we specify that? So, what are the pros and cons?

• Pros: With multiple suppliers, you're going to have cost pressures, and you're going to have multiple different people you can go to within the market for control service and controls installation.
• Cons: Now the con, this is actually a significant con and it's why you see a lot of contractors and system integrators starting to spread across geographies. When open procurement first came out, and I'm going to give you a little history lesson here. When you first started to see broad scale open procurement, you would see it typically being utilized for contractors on local projects only. The problem was, these contractors who were buying these products tended to not have a market in multiple municipalities, multiple states. So, if you wanted standardization and consistency across your portfolio, you would have issues.

Now the industry has started to turn on this. You've started to see owners with building automation standards. You've started to see contractors that have standards and this stretches across multiple municipalities, multiple states. So be cognizant though, that if you are using a contractor for multi-state projects or multi-municipality projects, that there is some form of standardization in place.

Okay, so how do we evaluate open procurement. I use a four number ranking.

• Ranking of 0 is you cannot purchase the controls except through a proposal from a salesperson at that manufacturer.
• Ranking of 1 would be you can purchase the controls by only going through a local branch or reseller.
• Ranking of 2 would be you can purchase from multiple resellers.
• Ranking of 3 would be you can purchase direct from the factory.

So, the purpose of this is that you'll put specific language in your RFPs, you Request for Proposal, or your RFQs, your Request for Qualification. Then you'll be able to rank people based on these scores. In your documentation you would put: Please detail out how we can purchase future products for this building automation system. And then, based on their response, you would rank it here.

Alright, let's move on to open protocol. So, there's a misunderstanding with open protocol. A lot of folks mistake open protocol to mean open procurement and they also mistake it to mean open software. Open protocol is not necessarily a building automation thing; it is a way of tools and hardware communicating. The most common open protocols that we see right now are BACnet, LON, and if you're over in Europe and other areas, you have things like DALI and KNX. Some folks will argue, and they're correct as it's just a matter of perspective, about OPC, and about Modbus. They'll argue about all sorts of different protocols, but primarily what we want to do with the protocol is we want to ensure that we are able to discover other controllers.

Now, I'm not an advocate of mixing controllers at the field level, but I do recognize that you can have assets with multiple different control systems. You want to tie all those together, especially at a supervisory or a server level. So, you do that through open protocol.

Now, why do I not advocate for mixing of controllers at the field level? I want to clarify that I have no problem. If one trunk is one manufacturer and another trunk is a different manufacturer, I do not recommend mixing manufacturers on a trunk. From a troubleshooting perspective, if you're going out there, you now have to try to have two sets of tools and two sets of training in order to work on that trunk, which is ineffective. Then you also have to stock more parts and pieces per building.

Let's look at how we rate this though.

So, for open protocol, we would ask to, Please detail out how you will integrate to the following systems in the list the systems and versions. It's really important. I was on a call with an organization this morning who's most likely going to be using us for consulting services around cybersecurity evaluations of products. One of the things I recommended, as part of their initiation phase, was that they grab a bill of materials and a list of systems as well as the versions of those systems.

Please be clear if this will be a native integration or require additional devices. That is a huge one. Lot of folks don't catch it. They don't realize that they need a gateway, they need a field server or a Babel buster, they need some form of router, because the supervisory device or the field controllers themselves do not natively integrate to whatever protocol.

So how do we rank that?

• Ranking of 0 would be they cannot integrate or connect with any of the systems. That would be a big fat zero, and you'd be like, “Hey, this doesn't work.”
• Ranking of 1 would be contractor could connect with less than 50%. This is arbitrary.
• Ranking of 2 would be contractor can connect with 50% or more, but only using other products. That's an important point. You may get someone who says they can integrate with every protocol and every system you have, and you’d be fine with that. Then they’d tell you that you have to put in this $50,000 server to do it, and then you’re like, “Okay, no.” So, be cognizant of that.
• Ranking of 3 would be, they can connect with 50% of systems natively, with just the existing architecture that they're going to deploy.

Let's move on to open data and application interfaces. Everyone loves API's, everyone's super stoked about them. It seems to be the talk of the town lately, because data is what powers all this prop tech, it's what powers all the SAAS software. So of course, people want API's, of course, people want data, because they want to sell you more software, they want to sell you more prop tech. Which isn't a bad thing. I mean, a lot of the analytic software, a lot of the prop tech out there lately has beneficial aspects to it. In the beginning, not so much.

Well, an Application Programming Interface, or API, is essentially a software interface into the programming of an application. So, if you ever want to understand an API, read the API backwards.

For example, I could pull up on my screen a list of interfaces and these interfaces are data feeds from my webpage. So, when I refresh this webpage, it would then show me these data feeds. These data feeds are tied into the application, which is my web server, and the program that's running in it, which is Apache, and via an interface.

So, why does any of this matter to you? For a good 95% of you, it's not going to matter, but the thing is, for those of you who want to do digital twins, those of you who want to do analytics, those of you who want to do anything with your data, you're going to need a way to pull data out of your system.

In the past, we would have to use BACnet interfaces, or we'd have to export Excel sheets, or we'd have to do a direct connect with our database. With API's we're now able to connect software together using things like Node-RED, JS, etc, which enables us to have some low cost options of consuming data from your building automation system.

So, how do you rank this?

Well, you would say, Please detail out if you have an open Application Programming interface. Detail out if this API has documentation, sample applications, and if the API requires a developer license. If you've ever done anything with API's, like, I like to teach our students on openweatherdata.com, and unfortunately, I had to switch to another API because they started charging people per call. A call is when you grab data from the program. So, some manufacturers out there require a developer license to get access to their API and they may not have documentation or sample applications on how to use their API. So, you can't really do anything.

So how do we rank this?

• Ranking 0 is the building automation provider has no API or way of consuming data.
• Ranking 1 is they have an API but with no documentation.
• Ranking 2 is they have an API, but it requires a license.
• Ranking 3 is they have an API with documentation and doesn't cost you anything to use.

Let's talk open software. So why will we never have open software? Because it makes no freaking sense to have open software. In order for you to understand that comment, let me paint a picture for you. You have two primary frameworks of coding in the world. One is called Java and the other is called .Net Framework. Java is Java, it's open source. .Net is Microsoft and it’s also pretty much an open source. The thing is, if you've ever installed BAS software, it’ll ask if you have version 4.51 of .Net Framework, and you're like, “What is this?” Well, that framework is a code base that your building automation software was built on.

The problem with us having an open software as an industry is, every manufacturer would have to create and agree upon some form of programming software. That programming software would have to be capable of visualization, which lets us see our data from our BAS, of commanding, which lets us do stuff with the data, and programming. Well, what the manufacturers have done, and rightfully so, is they've used Java or .Net to create their programming software, to create their building automation software.

Now, some building automation software comes with drivers, some software lets you use plugins to do programming, but by and large, there is no standard programming software or configuration or user software across the market. Nor do I ever see there being one in the future.

That being said, it's still important for us to have open software. What do I mean by that? Open software is not software that you can use to work on everybody's system. Much rather, open software is giving you access to the configuration tools that you need to do whatever you need to do in your building automation system. So, if you need to create a graphic, if you need to change a schedule, change a trend, add a point, map in a new controller, that all requires programming software, that requires visualization software.

My belief is that as an owner, you should have access to that. If you bought a building automation system, you should be given that software. Now, there may be a licensing cost to that software that you may have to pay, that's normal. But you shouldn't be precluded from having software to operate the system that you own. That is my opinion. I don't think that's right, and I think that is one of the single largest reasons why we have so many owners who can't operate their systems, because they weren't given the software to do it.

So, what does open software look like? What is the spec language for us?

That is, Please detail out how we will purchase your configuration software and any and all licensing costs for this software. Please also detail out any software we cannot have, or any limitations to the version of the software.

So basically, what we're finding out here is we're not going to be vendor locked, we don't want to have a dumbed-down version of the configuration software that doesn't let us do everything we want to do. So, we need to flush that out in our RFP/RFQ. So, what does that open software ranking look like?

• Ranking 0 is that the contractor will not provide you with their configuration software.
• Ranking 1 is that the contractor will provide you with limited versions. So, you won't have admin rights, you'll maybe have like a lesser right.
• Ranking 2 is that the contractor will provide you the full version of their software but it requires a license. You know, this could be a 2 in some cases, it could be a 3 in other cases. I'm seeing increasingly that pretty much every vendor out there is charging for a yearly license. There are some that aren't, but it makes sense.

You know, back when you first started to get software for manufacturers, there weren't all the cyber risks, there weren’t all the continuous development costs that there are nowadays. OEMs need a way to make up having a cyber team on staff to evaluate and patch their software, as well as continuing to develop improvements to software that is changing on a regular basis. So, having a license, to me, makes sense. I don't like point licenses. I don't like device licenses. I'm just not a fan of them, but I do understand them.

• Ranking 3 is that the contractor will provide you a full version of their configuration software for a one time cost.

So, there you have it, a lot of stuff on openness. My hope is that this pulled away the fluff because you see folks talk about open and it's like super fluffy, all these big words. I feel like it doesn't help anyone really understand what's going on. So, my hope is that looking at these four criteria of openness, with some clear evaluation criteria and with some clear spec language, gives you a better like picture of this.

So, if you have any questions, please reach out to me. I used to run the integration program at a large OEM, so I can definitely answer whatever questions you may have. I'd love to answer them. This is an area I feel I'm pretty much a SME on, Subject Matter Expert, so ask away.

Thanks so much for being here and take care.