Join us at NexusCon 2024 - Apply to attend now
Happy Thursday!
Welcome to this week’s deep dive exclusively for Nexus Pro members. It’s an honor to have you here. This deep dive is a follow up to my recent podcast conversation my NREL colleague, Cory Mosiman. I learned a lot from this conversation and want to share my takeaways and the full transcript with you below.
In case you missed it in your inbox, you can find the audio or video here:
Nexus site | Apple Podcasts | Spotify | YouTube | Add to other podcast apps
Enjoy!
—James
Disclaimer: James is a researcher at the National Renewable Energy Laboratory (NREL). All opinions expressed via Nexus emails, podcasts, or the website belong solely to James. No resources from NREL are used to support Nexus. NREL does not endorse or support any aspect of Nexus.
This was the nerdiest conversation yet for the Nexus Podcast. As I say, Nexus is my project for learning out loud, and this episode definitely reflects that ethos.
My main reaction was that I hope it clears up some myths for others. Since meeting Cory and having these types of conversations, I've had a few myths busted of my own. I used to be one of those people that thought Haystack 3 was the end all be all solution for interoperability.
One thing I'm wondering from the community is what everyone sees as today's best practice for a building owner to model their data, based on the state of Haystack, Brick, and ASHRAE 223? On one hand, you could say "why even bother?" With things in so much flux, it could be difficult to justify jumping on any bandwagon.
I see it differently. I think a building owner or application vendor should model their data in the most detailed way they need to in order to meet the needs of their use cases. But it should be done in a flexible way to accommodate these changing standards. Then, as the standards change, they can update their semantic model to stay in line with the standard.
[00:15:03]
Cory: So there's never really been a need to understand, like the essence of what something is I would say.
And that's kind of a question like, you know, it's kind of a philosophical question and this is like, from my understanding where, you know, ontologies and taxonomies kind of come in, right? Cause they're talking about kind of the philosophy of what it means to be this thing, and what do systems mean? And, those kinds of things.
James: Before we get there, I think the not needed piece is key. So a control system doesn't need that. It doesn't need to know that today, right, to produce what is today's building automation system, right? It's inputs and outputs. It's PID loops and it like gets the job done okay, basically, without knowing anything about itself. But as we, I think, where we're going in the industry is when we start to do things like analytics, those do require some sort of knowledge of what this thing is, right? The essence of the thing. And that's how we basically add intelligence. We add analytics to it. We need to know those things. And so I think from my perspective, like, where we're going is because that of that gap, where we're going with this conversation is because of that gap that's been created. Right? We need, we need the system to know what it is, and it doesn't know what it is. Maybe it's just that, that's as simple as we can put it.
Cory: Yeah. And I think like, yeah, so analytics, FDD come in and I think for the most part, like people thought BMS was probably going to be the last thing that was like ever needed, right? And so that was kind of like - and still is considered a lot of times - like the top tier application in the stack of kind of the controls world.
But then you had, you know, analytics and FDD kind of come into play. And now what you introduce is basically a new application, right? That now is trying to communicate with your BMS application or your BACnet network, and it's trying to come to some sort of understanding of what's all out there, right, in terms of systems and devices. And it doesn't actually really care too much about the devices, only in the sense that the devices are what gives it the information. And FDD is really about understanding, you know, kind of system, system workings. And so this is I think really where, you know, semantic interoperability comes into play, is when you have kind of complex applications that are, or applications that are trying to do more complex things, which are, you know, a lot of times based on the physics and the thermodynamics and things like that, where it becomes really important to know kind of, what the essence of things are, what properties things have, stuff like that.
[00:27:16]
James: So if we take it back to that DAT sensor that's kind of lost in the world. So if we do Haystack 3 perfectly, what do we now know about? Or what can we communicate to each other about that DAT sensor?
Cory: Yeah. So, and I think this is kind of an important aspect. So you and I could definitely communicate discharge air temp sensor point. We understand that concept, and that conveys like a full meaning to us. And then we would also use like an equip ref tag on that point to say, you know, that this belongs to this air handler.
So I know basically kind of the type of that thing, I also know what it's kind of connected to-
James: Say we were on a campus though. We would also know like, we'd have site refs, and maybe even more metadata around like what building that sits in. Maybe, maybe we'd know, like, depending on the user of the Haystack tags, we would know, like maybe we would even know what floor or like what like group of zones, like things like that can be added, right? If I want to, to kind of provide more tag-based context around that DAT sensor. Right?
Cory: Yep.
James: Cool. So, I mean, that helps. Right? So that allows someone that is setting up something like an analytics platform to quickly and easily understand the context of all the data in the building. Right? So that's, I mean, I think one thing to note is that as we talk about all this different progression, we're big fans of everything that's happened so far.
[00:29:13]
Cory: Yeah. So this, this goes back to kind of this application level interoperability. And so if we think about a data dictionary, you and I can have like a conversation, but there's no, in Haystack 3 it was just, you know, if you go to their tags page, right, it's just a list of like 50 or a hundred tags and a definition next to it. And so every time let's say a human had to kind of go, you still had a human in the loop, type process. So it was a human going to the Haystack website, kind of interpreting what an individual tag meant. Now there were some examples of like what tag sets together, like you, you know, typical tag sets on an air handler or a VAV box or something like that, but it was still kind of a highly human in the loop process. And part of that had to do with what we'll get into as like a taxonomy. So Haystack didn't really have a taxonomy or like an ontology in Haystack 3. And what a taxonomy does, it's basically, it provides like formal, like more formalized definitions for subtyping , and kind of providing categories and subcategories to the data that we're talking about.
So, in Haystack, you know, there was this kind of convention that, you know, there were three main types of things: a site, an equip, and a point, and these were, you know, kind of more specific types of things. But there was nothing really formal to say that; there was no like machine readable way to say that. So Brick came along and said, okay, like we need to define this in a more formal structure. And they use semantic web technologies, which kind of consists of RDF OWL, RDF SPARQL. Maybe you hear these words every once in a while, but these are kind of just like the grouping of what they call semantic web technologies.
And so they say, okay, let's, let's use this technology to do this kind of typing system, and like a formal typing system. So now I have a top level thing that's called a point. And, you know, a sensor point is a direct subclass of a point, right? It is a more specific type of point and more specifically, it is something that is kind of being read in from a sensor, whether that's like a digital or something sensor, right. And then they say, okay, a temperature sensor is an even more specific type of sensor point. And it is something that, you know, specifically measures the temperature property of something else. Right. And then, and they also, you know, now I have air temperature sensor, which I know is measuring, it's measuring the temperature property of the air substance. And then I have a discharge air temperature sensor, right. Which is measuring the air substance, the temperature property of the air substance located in the discharge basically.
Now, now this you could do with Haystack, but it was Haystack 3, but it was still informal. So that's kind of where Brick comes along is like, let's just have some more specific categories and we can, you know, use just a class oriented, you know, sub-classing mechanism to more narrowly define what something is.
James: That formality word I feel like is important to me. Cause the way I understand it, is they came along and said, this is not machine readable. Like the way that Haystack is being done, two different machines would get two different answers. Right?
Cory: Yeah. And, and there still is this human in the loop problem , right? So in Haystack it was kind of going in and, and say, you know, I have to apply this entire tag set to type this thing as a discharge air temperature sensor point, okay. Now there is still in Brick, right? Somebody still has to go in and say that this thing is a discharge air temperature sensor. That, I would say doesn't really-, you know, at this point there's still that effort that needs to happen. And so that's, I guess just a point to make, but it does provide more formality in terms of how can you like understand the essence of something by looking like up the tree, right? And so-
James: And the tree is the taxonomy, right?
Cory: And the, and the tree is a taxonomy. So we might think of like felions as, you know, a category, which is a sub category of mammals. And, you know, there's then more specific types of cats, right, and these more specific types of cats, you know, get even more specific, and whatever, we have house cats. And so it just provides this structure originally.
And then, so the other problem that they basically wanted to address, is defining kind of legitimate relationships between things of different types. So now we have kind of within more specific categories and subcategories, but how do I relate to things that are kind of, of different categories? So like a bunny is the prey of like a coyote, right? Or, you know, those end up in two different, you know, bottom levels of the tree, but there's still some sort of like kind of relationship between them. And so this is where, like the ontology kind of comes into play and you say, you know, you define legitimate relationships between different types of things.
And I think one of the biggest grievances that Brick had, and I know as like a user starting off that, so it was very difficult for me to understand what type of relationship they should use to reference certain things. So certain things were easy, like a point related to a piece of equipment, it's always an equip ref, you know. But then you use something like a fan located in it , in the discharge duct of an air handling unit. And now a fan equip refs to an equipment, to an air handler. Now those are two very distinct types of relationships, right? So it's , you know, it's a thing it's contained by, or is a part of, I guess, is what Brick uses. And this other thing is a point of this thing. So Brick kind of said like, let's have more relationships, and define these more formally in a sense.
James: Yeah. And I've had the same thing where you're using, if you're using Haystack 3, you're using the same tag to mean different stuff. And that's where you start to confuse a computer. You know, a human would notice the difference between an equip ref. when you, when they look at a VAV or an air handler, or where a fan is in an air handler, but the machine is like, you just used the same tag to mean two different things.
So, okay. So as we kind of keep kind of moving down this progression of where we've come, so the way I understand it then is the Haystack guys basically said, okay, I hear you Brick.
[00:37:40]
I think this is a distinction. Because, you know, some things in Haystack don't really map cleanly because they, they weren't really-, Haystack was designed to solve different problems than I think what Brick and 223 are actually going after. So Brick and 223 are really going after the ontology issue, which is only actually part of what Haystack addresses. So Brick and 223 are basically trying to say like, How do we talk about systems and what sort of things do we need to talk about? And Haystack, you know, it does that for the most part kind of, but it also goes into, you know, how do you get, you know, other metadata info from this? How do you get time series data out of this thing? Right? And, and that, I think just goes with, you know, where these are at, or what they originally intended to solve. And Haystack wanted to kind of provide like a one stop shop solution to all of this stuff. And Brick and 223, I think are more like, let's solve the ontology issue first, and then we can go after data access and stuff.
[00:42:01]
Brick kind of started with Haystack terms and tags and kind of, let's say reorganized it a little bit. 223 is going into, you know, let's break down like a piece of equipment, right? So we're going through this exercise where we're just looking at, you know, ASHRAE Guideline 36 systems and breaking it down into all of its constituent pieces. And what kinds of relationships and systems and components do we need to kind of consider, right? And so a classic example right now is, Brick and Haystack had no kind of concept of connections or, you know, the directionality between things, besides like maybe feeds or something like that. But within like an air handling unit, right, I might define, I have a heating coil, a cooling coil or whatever. And there was no way to basically say like what the order of these things are, right? And what kind of, you know, substances are kind of like flowing between these things. And so Joel, you know, there' s-, in 223 it's really about trying to bring together the best of a lot of different ontologies and say, this is how you can, like they can work together.
So there's this other ontology called SAREF which, you know, has the concept of connections, connection, points, and systems. And so it's kind of marrying, you know, SAREF with these different connections and basically, you know, defining ports, right? So a connection might have multiple connection points and defining like legitimate, you know, inputs and outputs to these connection points. So if I have a heating coil, like a hot water coil, right, that might have an air inlet and outlet, but it also has like water inlet and an outlet, right? And so it's pretty interesting because it's getting down to like, how do we model very, very detailed things? And, and then, and the other question is like, at what detail do we need to model it right now?
[00:47:52]
James: I think what you're saying is like use cases, that there's many different use cases for the same data, right? So just because someone tags a data set for their use case doesn't mean it then enables every smart building use case that could possibly use that data, right?
Cory: Exactly. Yeah. And so you have different applications that actually need different things, right? So one application, and this is like, you know, there's no concept of Haystack like compliance or verification right now, because it's kind of like you use the dictionary terms to basically identify the things that you need to identify. And primarily this is for, you know, let's say a monitoring based commissioning firm, or, you know, some sort of firm who's selling SaaS, you know, to implement their solution. They're not really looking at, you know, who might the next player down the line be, who might want to consume this and what might they need from a data perspective, and what aspects of the model do they actually need to know about?
And so, so this is where it kind of, if we're talking about application to application interoperability, you have to take like the same viewpoint on modeling something so that you can kind of both, both of your applications could get the data that they need to, to run whatever they need to run, basically.
[00:49:18]
And right now the standards aren't extensive enough. Maybe that's not the right term, but we've kind of covered it. They're not at a place where they have a standardized way to add all of this metadata, basically that would then fully describe a, say a discharge air temperature sensor for every application that could use it.
And so I think what I've experienced is you might have two companies that are trying to use Haystack, for instance, and they've gotten to the limits of the Haystack standard, and then they've then added onto it, right. So they've used Haystack up to a point, and then now they've added Haystack-ish sorts of tags. And so now we have basically n plus one standards. And then you have the next company that's doing Haystack, and then they got Haystack-ish, and their Haystack-ish is different than the other company's Haystack-ish. And so now what we have is like basically, we have a world where then the humans can probably understand it, but the machines couldn't, if you wanted to plug two different applications into that tagged dataset.
[00:51:36]
Cory: There hasn't really been like a third party spec that basically says, you know, like when we say a package rooftop unit with single-stage DX cooling and gas furnace, you know, heating, this is exactly what your model needs to look like. There's nothing out there that says that. There's kind of maybe some like examples, but there's nothing saying like, this is how to do that system. And so I think that's an opportunity, is to kind of look at what are the most common system, you know, a few of the most, five to 10 of the most common system types out there, come to an agreement on basically how those should be modeled and kind of prove round tripping, you know, through multiple vendor systems to do that.
…
And with that, I think comes the opportunity to also have basically reference implementations, right? So a big ask is on the Haystack forums, you'll see this, it's like where can I-, like do people have sample data that I can look at? There's not really much out there. There's a few sample buildings generally with simple systems , but we don't really have good reference implementations for doing, you know, more complex systems. I liken this to kind of having the DOE prototype buildings from an energy modeling perspective, which is like, look, we're just going to define like a very generic, small office building and say, you know, this is the system type, and this is like what it looks like. I think we can kind of do that, in the same way for Haystack as well. So putting those out there so that people can go in, look at examples. I mean, I'm a very example- oriented learner. So it's, it's very easy for me to go see something, and okay, now it makes a lot more sense.
…
And along with that is kind of like some tooling. So having some vendor tooling, you know, to help people do these systems more consistently, right. We still, you still probably want to use it or to interface with something that is very simple. You know, you want to abstract away tags probably in the data model that goes underneath it, but providing them with some sort of forms or whatever that, you know, just enter in this information quickly. You know, don't worry about the data model that all happens in the backend and, you know, you're good to go. So, you know, I think tooling around this is really important and that's something that, you know, will push I think, vendors, to, to improve tooling, to help with that.
James: Yeah. And do you think that would be on-, like I know SkySpark is definitely building out tooling in their latest releases. So you think that would be a vendor thing or it would be a vendor agnostic sort of set of tools?
Cory: Yeah. I mean, I think you could go both ways. It definitely seems like there is like a cry out there for, you know, some sort of open source Haystack builder type of thing.
James: Yeah.
Cory: Brick is maybe like a little bit easier because it, it uses, it builds on the semantic web technologies. So there are, you know, in Python, things like that, you know, typical RDF tool sets, and standard ways of kind of constructing these. So not, you know, not that everybody's going to go in Python and build RDF graphs or whatever, but it is available for people if they want to get their hands dirty.
One of the things with Haystack is that it can be difficult because the ibraries that maybe are available on the Project Haystack website, you know, different programming language libraries, they cover very different aspects of Haystack. Some of them just implement kind of the API spec. Some of them have incorporations of the Haystack data model. Some of them have incorporations of like the Haystack literals and actual like data types that, so there's kind of a wide spread, and it's, and they're not consistent.
And so anyways, I do think that there is kind of a cry in the industry to have some sort of open, you know, third party Haystack builder type thing, so.
What did you think about these highlights? Let us know in the comments.
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James: [00:00:00] Hello, friends. Welcome to Nexus, a smart buildings technology podcast for smart humans. I'm your host, James Dice. If we haven't met before, I write a weekly newsletter on the same topic. It's also called Nexus. Each week I share what I've learned, my opinions, and what I'm excited about in the quickly evolving world of intelligent buildings. Readers have called Nexus the best way to stay up to date on the future of this industry without all the marketing fluff. You can check it out and subscribe at nexus.substack.com or click the link in the show notes.
Since starting the Nexus newsletter, many of you have reached out to me wanting to talk shop, and we have. After a few weeks of those wonderful conversations, I realized I needed to record and share them with our growing community. So here we are. The Nexus podcast is born. This is our chance to explore and learn with the brightest in our industry together.
One more quick note before we get to this week's episode. I'm a researcher at the National Renewable Energy Laboratory, otherwise known as NREL. All opinions expressed on this podcast belong solely to me or the guest. No resources from NREL are used to support Nexus, and NREL does not endorse or support any aspect of Nexus.
Okay. Episode 11 is a conversation with my NREL colleague, Cory Mosiman. Cory and I have these conversations all the time, so we thought it'd be fun to press record once in awhile. Fair warning though, this is the nerdiest episode yet. However, before you stop listening, I want to put that nerdiness in context. Today in buildings across the world, data is locked up and unable to be used. If we could use it, we could do things like help mitigate climate change, create healthier indoor environments, and automate our buildings.
People new to the industry often ask why that is. This conversation is part of that answer. We set aside the business reasons of why the data can't be used, like vendor lock-in that have plagued the industry forever. Instead we dove into the semantic interoperability problem and all of the efforts going on to solve it. This includes the open source projects called Project Haystack and Brick. It also includes the proposed ASHRAE Standard 223 and the associated working group. This is a difficult subject to learn and an even more difficult one to convey. So I hope this conversation takes you closer to understanding what's going on, like it did for me.
This episode of the podcast is directly funded by listeners like you who have joined the Nexus Pro membership community. You can find info on how to join and support the podcast at nexus.substack.com. You can also find the show notes there, which has links to Cory's LinkedIn page. Without further ado, please enjoy Nexus Podcast Episode 11.
Hello, Cory. Welcome to the Nexus Podcast. Can you go ahead and introduce yourself?
Cory: [00:02:58] Hey, James. Yeah, sure. So my name's Cory Mosiman. I am a software engineer at the National Renewable Energy Lab. So James and I work together. I work mainly on interoperability type projects. So I work on interoperability with respect to energy audits, and also a lot of Brick and Haystack, and also I'm in the ASHRAE 223 kind of working group. So, as I understand it, we're going to be talking a lot about aspects of interoperability today. And I'm looking forward to it. I just wanted to make sure I said real quick, so I do participate in the ASHRAE 223 group. I'm not, you know, in any-, you know, none of this stuff is basically official, coming out of ASHRAE. So this is just my understanding of kinda what some of the ASHRAE 223 stuff that's going on, what it looks like. So, but looking forward to discussing.
James: [00:03:46] Yeah, this is not the official ASHRAE position on interoperability at this point. This is us two, trying to figure the world out. Cool.
So yeah. You've taught me a lot. So I thought it'd be good to kind of bring you onto the podcast and see, you know, what we can kind of spread around to the rest of the Nexus community. So first of all, thank you for that. You and I have had lunches, and chats on Microsoft Teams, and a lot of stuff that's kind of helped me. I think I've helped you a lot as well. So it's been good so far.
So let's start off with just setting the context around interoperability. So I mean, you and I are, you know, HVAC and energy nerds. I would say a lot of the Nexus community are the same sort of nerds. So I think a great place to start with this conversation is let's zoom out. Like what the hell is interoperability?
And I'll start by saying here's how I thought of it before our conversations. So I come from the world of energy efficiency and retrocommissioning and monitoring based commissioning. So I've always used Haystack as a way to take data in a control system and make it easier to use in an analytical application. But I realized that's a very limited definition of interoperability . So let's just zoom out and just say like in general, in the world, what is, what does interoperability mean?
Cory: [00:05:17] Yeah. Good question. So to your point, we can talk about interoperability at like a few different levels. And so I think it's important to distinguish. So very briefly we can talk about device level interoperability, so the ability for two devices on a controls network basically to communicate with one another. And I think that that is generally kind of covered in what we think of as BACnet.
James: [00:05:45] And so they speak the same language, basically. So if I'm speaking English and somebody else is speaking Chinese or Mandarin, then it just works?
Cory: [00:05:54] Yeah. And it's kind of about the rules of like negotiation as well, so how do I even find somebody that exists in the world?
James: [00:06:06] Right, so it's more than just the language.
Cory: [00:06:09] Yeah, that's maybe a first part. Right? So how do I find people? How do devices find devices? And then it's kind of like how do you even, how do you identify the language that the other device speaks, if they speak your language, maybe. And then it's kind of what sort of, what sort of services or transactions can you make with that device?
I think of it that way. Right? So you might go to a grocery store and want to buy apples, but they're only, you know, selling pears or whatever. Right? So, and this is kind of where BACnet is. It's understanding, you know, who's out there, and you know, how you can talk to them and what kind of services you can exchange with one another.
James: [00:06:53] Okay. Before we get into BACnet, let's talk about like, what's the definition of interoperability? I mean, you were telling me the other day, it sounds like it's it's like repeatable, and two people from different companies have to be able to do the exact same thing for it, like without human intervention, right? For it to be considered interoperable. Right?
Cory: [00:07:13] Yeah. So I'll also make the disclaimer that I'm not an expert on any of this stuff. So, I'll definitely parrot a lot of things that I've learned from other people. So one of the definitions and ways I like to think about it, I think was brought up by Gabe Fierro, who's one of the Brick guys. And he basically said, you know, W3C, which is worldwide web consortium, they, when they were proving out kind of interoperability for web standards, they always, basically they required that two companies, basically competitors, so similar interests, able to communicate, and basically relay information to one another.
So they never said that some like an interoperability standard was like actually taken into effect until, you know, two separate bases had proven out that they can kind of communicate with one another, and what that communication is, you know, whether that was just, you know, two things talking to each other or, you know, really conveying meaning at the application level. There's, you know, there's lots of different ways that that can be, but I like that definition, you know, proving out that, you know, two people have the same understanding of what they're trying to do and can do that successfully.
James: [00:08:24] Yeah, I like it too, because I think it sets the stage for kind of where we're going to go with this conversation a little bit.
So, there are a ton of different interoperability efforts, right? If we talk about smart buildings and we just like draw a boundary around the smart buildings world, like you could probably just like name off like 20 different interoperability efforts. And so while we're here to talk mostly about HVAC and Haystack, Brick, can you just kind of give us an overview and put in context, Haystack and Brick in the context of all these other efforts that people might've heard about in passing or on their projects?
Cory: [00:09:05] Yeah, sure. I think that's a good idea. So I think you can, you can kind of group these into, you know, different things, that have been solved for, or are trying to be solved for by these standards. So if we talk about kind of device to device communication, we tend to think of BACnet, LonWorks, or Modbus, right? Those are kind of three pretty standard things that a lot of controls people are familiar with. That's one small portion, right? And that's all in the operational phase. You know, design and construction processes are like processes, right? They're ongoing. And, they, you know, contain a lot of stakeholders.
So, so additionally in this world, you know, we think about kind of building information modeling. So, how do basically, you know, an Autodesk Revit and another like BIM application, how do they, you know, take whatever that they're building and, you know, transfer it to one another, without, you know, data loss or corruption. So that, that I would say is like BIM to BIM interoperability. And that is covered by the industry foundation classes. And I think like COBie is maybe another one. I think there's some relation between those two, but anyway, so that I would say-
James: [00:10:17] I actually have heard those two.
Cory: [00:10:19] Okay, so that I would say is kind of like the BIM to BIM world.
We also have this other workflow, right? That is the building information modeling to the building energy modeling. Right? So, using EnergyPlus OpenStudio to simulate a building, and taking basically information as defined in your Revit model and running that into energy model, right? So not having to rebuild your whole building. And that's, you know, generally covered by gbXML, and yeah. So that's, let's say gbXML.
Then we have this other one, which is kind of like auditing and reporting, I would characterize it as. So these are things like Green Button X ML, maybe it's an XML? ENERGY STAR XML, BuildingSync XML, which is kind of like a schema for energy reporting, energy audit data, and then HPXML, which is energy audit data for residential. So this is another one, right? So a lot of these are, you know, XMLs, schemas, things like that.
And then you have, you know, these things, which are, you know, everybody in our world talks about right now, which is more on the operational side of things, is how I tend to think of it. So this is where like Haystack and Brick and 223 come into play, where you're really kind of looking at maybe more controls-oriented, system-oriented kind of interoperability. And people often talk about, you know, this thing or this concept of semantic interoperability when they're talking about that. So we can discuss that a little bit more.
You know, then you have, you know, Troy Harvey is doing some things with this digital twin standard. Microsoft I know is working on this digital twin definition language, which is another kind of schema ontology, not totally sure. Basically, there's a lot of stuff out there.
James: [00:12:05] Yeah, definitely. And I just have this sense that as you just listed all of that off, I just-, there has to be more, right? Like those are the ones that-, yeah. Right. So there's just a ton of things going on. So I don't want to blow this conversation up. We want to just keep it narrow, down to what we know.
So let's, let's kind of dive into HVAC and controls type of applications. So I know this is like a big question, but why don't we have interoperability now with that sort of data?
I mean, and let me set the context a little more there. So BACnet has been around for 20 plus years, something like that. so I think there might be sort of a first myth that BACnet has solved it. And then I think there's also probably a question around like if BAcnet's around, and then we all understand that interoperability is a goal, couldn't a control system just be set up from the beginning for interoperability to begin with? So I know this is a huge question-
Cory: [00:13:14] You mean sort of semantic interoperability to begin with, or-
James: [00:13:17] Maybe you just begin there. So what's the difference between semantic interoperability and just more general interoperability, like we defined it earlier?
Cory: [00:13:27] Sure. Yeah, so I would say, so two things. I think if, if we look at kind of the history of basically BMS applications, right, and kind of as they exist today, they're really, you know, implementing control methods. And many people have pointed this out already that, you know, they don't really have an understanding of what a system is, right? I can use a, I could probably use something like a VAV controller and plug a few IOs from like an air handling unit into it, right, and it probably wouldn't know the difference except that now I don't have enough landing ports, you know, to land all of the input output that I need to for an air handler, right. So there's, there's kind of this, this aspect, you know, that controllers are very extensible, right? So they can, you can add more IOs, but really it's controls right now. It's all IO driven and so, so it doesn't really have an understanding, let's say, of the system, of like the components in the system. And more broadly, and this is kind of like Troy Harvey's point, it doesn't really understand physics at all, or like thermodynamics. Right? Which are very important for it to function. Right? So a VAV box doesn't really understand, you know, like, or a VAV controller doesn't really understand like flow rates and how actuating a damper is going to, you know, change flow rates, right? It does only in the sense that you kind of programmed a few things in there to, and based on IOs, right?
James: [00:14:55] So a semantic model is like not needed for the way that our control systems are set up in the buildings world right now.
Cory: [00:15:03] Yeah. So there, yeah, there's never really been a need to understand, like the essence of what something is I would say.
And that's kind of a question like, that's like, you know, it's kind of a philosophical question and this is like, from my understanding where, you know, ontologies and taxonomies kind of come in, right? Cause they're talking about kind of the philosophy of what it means to be this thing, and what does systems mean? And, those kinds of things.
James: [00:15:27] Before we get there, I think the not needed piece is key. So a control system doesn't need that. It doesn't need to know that today, right, to produce what is today's building automation system, right? It's inputs and outputs. It's PID loops and it like gets the job done okay, basically, without knowing anything about itself. But as we, I think, where we're going in the industry is when we start to do things like analytics, those do require some sort of knowledge of what this thing is, right? The essence of the thing. And that's how we basically add intelligence. We add analytics to it. We need to know those things. And so I think from my perspective, like, where we're going is because that of that gap, where we're going with this conversation is because of that gap that's been created. Right? We need, we need the system to know what it is, and it doesn't know what it is. Maybe it's just that, that's as simple as we can put it.
Cory: [00:16:31] Yeah. And I think like, yeah, so analytics, FDD come in and I think for the most part, like people thought BMS was probably going to be the last thing that was like ever needed, right? And so that was kind of like - and still is considered a lot of times - like the top tier application in the stack of kind of the controls world.
But then you had, you know, analytics and FDD kind of come into play. And now what you introduce is basically a new application, right? That now is trying to communicate with your BMS application or your BACnet network, and it's trying to come to some sort of understanding of what's all out there, right, in terms of systems and devices. And it doesn't actually really care too much about the devices, only in the sense that the devices are what gives it the information. And FDD is really about understanding, you know, kind of system, system workings. And so this is I think really where, you know, semantic interoperability comes into play, is when you have kind of complex applications that are, or applications that are trying to do more complex things, which are, you know, a lot of times based on the physics and the thermodynamics and things like that, where it becomes really important to know kind of, what the essence of things are, what properties things have, stuff like that.
James: [00:17:51] Cool. Yeah. That helps, that helps me at least understand it. So I want to take us through kind of the history of like, we had that gap and now there's been several efforts to close that gap. And they've been happening over the last many years up until today where you're helping to work on this ASHRAE 223 project.
So I think a good way to maybe frame this progression is to put it in the context of a single sensor. So I think the example I always like to use is a discharge air temperature sensor for an air handler. So maybe we could start like, with that in mind, start with BACnet. So how does BACnet handle and communicate the essence of a discharge air temperature sensor to other devices?
Cory: [00:18:43] Sure. Yeah. So in general, in BACnet world, a discharge air temperature sensor, is just an analog input, right? So, I have, you know, a sensor out in the field. I wire back 0 to 10 volt or 4 to 20 milliamp or whatever to my controller, and that is basically, you know, just doing analog to digital conversion, right? So it's reading a value and converting it into something digital. So then what happens, you know, you have a controls engineer who kind of knows where this sensor landed and this, I think, you know, just to be clear, this part will never really go away. This will always be part of the process, right? Because you will always have to like at some point map physical world to digital world, and you know, wiring that back. Right? So now I know, you know, that this temperature sensor landed on port four or whatever, input four.
So then, you know, a controls person, they go in and they say, you know, they provide a name, right? And this is where BAS naming conventions come into play. We won't really go into that except to say that, you know, they haven't worked and they are all over the place. And-
James: [00:19:57] Everybody names their temperature differently, right? It could be SUP air temp, supply air temp, discharge air temp, DAT, DIS AT you know, everything. Right?
Cory: [00:20:07] Yup. Exactly. And so, so, you know, we get a name, there's a description field. Probably nobody fills it out. We assign units to it. So we might say that this is degrees Fahrenheit. And we know that it's an analog input, right?
So in general, you can use these, you know, your name, what type of input or what type of a thing it is, so analog input, binary input, whatever, and units to, you know, kind of help you, right? But this is, this is really lacking. Right? So I might just know that it's degrees Fahrenheit, which likely tells me that it's measuring a temperature property, but I don't really know like where that is, right ?
James: [00:20:48] So I could comply with BACnet, fully comply with BACnet and really provide nothing more than just degrees Fahrenheit from my little sensor?
Cory: [00:20:57] I think you have to provide a name, and you know, there's like some object ID, like device ID or something like that.
James: [00:21:02] But I've seen names that are just like AI4, right, which provide nothing.
Cory: [00:21:08] Totally. Bob, Fred, whatever. James. That could be the name of something. Totally. That's legal.
James: [00:21:16] So I think that the context here would be like, if that's how say an air handler is set up, right, and it can communicate with say its supervisory network or other, you know, devices on that BACnet network, totally fine with BACnet, right. But then there still would be no meaning passed along that network with the way BACnet is set up right now.
So let's kind of add in, okay so what I see-, the way I understand it, at least is then Haystack comes along, right? So they say, let's close this gap, and I want to kind of group in version one, two, and three. So what do those add to this discharge air temperature sensor for us?
Cory: [00:22:05] Yeah. Sure. So let's say up through Haystack 3, right, we just utilize the concept of a data dictionary, and so that is basically all coming to agreement on what are the words that people will use, right? So it kind of like levels the playing field a little bit.
So the classic example is, you know, supply and discharge are, you know, synonymous and people use them. So Haystack takes a stance. We're not gonna use supply. We're just gonna use discharge. So say discharge, right? That is the word. Don't use supply. Okay. So, and it, you know, it says that if we're going to keep the discharge air temp sensor going, right, then we basically, we have those four words, discharge air temp sensor, and then point. Right? And those are, you know, five, let's say valid definitions in the Haystack like data dictionary. So it does the first thing in terms of, you know, you and I are coming to the table and at least talking the same or using the same words.
And then the other thing that Haystack 3 kind of, and I don't know where in the progression of Haystack 1, 2, or 3 this happened, but they added an API, which, an API specification, right? So standardizing operations for getting data in, or writing data into a Haystack server. So, so what's-, I think we'll probably mainly not worry about the API. I think the important thing that I just want to convey there is that Haystack was designed to solve kind of multiple issues and it kind of lumps these all together into Haystack. But it, it solves kind of the data-, it intended to solve somewhat of the data modeling issue, and data access issue. So, yeah.
James: [00:23:53] Okay. So what are-, what about the concept of tags? So if I've never heard the word tag before , those are basically, those dictionary terms are themselves tags that get added to data. And that's the same thing as metadata, right?
Cory: [00:24:08] Yeah. And I'll say one thing real quick with respect to tags is that, and this'll lead us into Brick as well, but you have two kind of different types of tags in Haystack. You have tags, which are typing tags. So, and these are what Haystack calls marker tags. So these tags are intended to provide a typing definition to what it is that they represent. So typing can be kind of confusing, but generally just think about it as, if I have like an entity and I want to describe that entity, I might use discharge, right? And discharge is a marker tag that says, this thing is a discharge. Now in Haystack, you don't really use just a single tag.
And this is where Brick kind of comes in and they say, look, like nobody wants to talk about single tags. They want to talk about tag sets or really, you know, concepts. And, you know, if I were just to describe something that is a discharge tag, that doesn't really make sense. It doesn't help me. So now I have, you know, a tag set in Haystack, which would be a discharge air temp sensor point, which kind of provides like a full typing definition to this thing. Right? And that is a tag set that actually conveys like a legitimate concept, you know, that we would then have an understanding of. And so that's, that's the talk about marker tags.
And then the other thing that Haystack does is kind of these metadata tags, which just, they're not typing, they're just providing kind of like some additional metadata. So it, it, you know, it tells me maybe the unit, that's kind of some additional metadata. It might tell me, like I put a geo state on a site entity that tells me, you know, where this site is located. Right? But it doesn't tell me that the type of this thing is a site. So those are also two kind of, I think, important distinctions in Haystack, is that you have typing tags and you also have additional kind of metadata tags.
James: [00:26:12] Okay. And where do reference tags come into play? Cause that's where the modeling, I guess in my mind, the modeling concept is handled through references.
Cory: [00:26:22] Yeah. So, so references are, you know, kind of pointers between two entities. So, and I'll just say if people aren't super familiar, entity is just like this very generic something. So anything in Haystack is like an entity. And it's just, you know, this kind of free something. We provide typing tags to inform what this something is, right? So, and then we provide reference tags to basically help define relationships between two somethings, basically. So a classic example is I want to, you know, say that this, like a VAV box is connected to an air handler. So I put an AHU ref tag onto a VAV box and I point it upstream kind of to the air handler entity that is feeding this thing. So that's kind of where, where ref tags come into play.
James: [00:27:16] Yeah. So if we take it back to that DAT sensor that's kind of lost in the world. So if we, if we do Haystack 3 perfectly, what do we now know about? Or what can we communicate to each other about that DAT sensor?
Cory: [00:27:33] Yeah. So, and I think this is kind of an important aspect. So you and I could definitely communicate discharge air temp sensor point. We understand that concept, and that conveys like a full meaning to us. And then we would also use like an equip ref tag on that point to say, you know, that this belongs to this air handler.
So I know basically kind of the type of that thing, I also know what it's kind of connected to,
James: [00:28:02] Say we were on a campus though. We would also know like, we'd have site refs, and maybe even more metadata around like what building that sits in. Maybe, maybe we'd know, like, depending on the user of the Haystack tags, we would know, like maybe we would even know what floor or like what like group of zones, like things like that can be added, right? If I want to, to kind of provide more tag-based context around that DAT sensor. Right?
Cory: [00:28:31] Yep.
James: [00:28:32] Cool. So, I mean, that helps. Right? So that allows someone that is setting up something like an analytics platform to quickly and easily understand the context of all the data in the building. Right? So that's, I mean, I think one thing to note is that as we talk about all this different progression, we're big fans of everything that's happened so far. Right? We're not, we're not trying to bash any one project. So given like where we are with this DAT sensor, the way I understand it is that at some point, the guys from Brick came along and they basically said that, Hey, wait, like that's not good enough. And so can you kind of explain what they were basically saying?
Cory: [00:29:13] Yeah. So this, this goes back to kind of this application level interoperability. And so if we think about a data dictionary, you and I can have like a conversation, but there's no, in Haystack 3 it was just, you know, if you go to their tags page, right, it's just a list of like 50 or a hundred tags and a definition next to it. And so every time let's say a human had to kind of go, you still had a human in the loop, type process. So it was a human going to the Haystack website, kind of interpreting what an individual tag meant. Now there were some examples of like what tag sets together, like you, you know, typical tag sets on an air handler or a VAV box or something like that, but it was still kind of a highly human in the loop process. And part of that had to do with what we'll get into as like a taxonomy. So Haystack didn't really have a taxonomy or like an ontology in Haystack 3. And what a taxonomy does, it's basically, it provides like formal, like more formalized definitions for subtyping , and kind of providing categories and subcategories to the data that we're talking about.
So, in Haystack, you know, there was this kind of convention that, you know, there were three main types of things: a site, an equip, and a point, and these were, you know, kind of more specific types of things. But there was nothing really formal to say that; there was no like machine readable way to say that. So Brick came along and said, okay, like we need to define this in a more formal structure. And they use semantic web technologies, which kind of consists of RDF OWL, RDF SPARQL. Maybe you hear these words every once in a while, but these are kind of just like the grouping of what they call semantic web technologies.
And so they say, okay, let's, let's use this technology to do this kind of typing system, and like a formal typing system. So now I have a top level thing that's called a point. And, you know, a sensor point is a direct subclass of a point, right? It is a more specific type of point and more specifically, it is something that is kind of being read in from a sensor, whether that's like a digital or something sensor, right. And then they say, okay, a temperature sensor is an even more specific type of sensor point. And it is something that, you know, specifically measures the temperature property of something else. Right. And then, and they also, you know, now I have air temperature sensor, which I know is measuring, it's measuring the temperature property of the air substance. And then I have a discharge air temperature sensor, right. Which is measuring the air substance, the temperature property of the air substance located in the discharge basically.
Now, now this you could do with Haystack, but it was Haystack 3, but it was still informal. So that's kind of where Brick comes along is like, let's just have some more specific categories and we can, you know, use just a class oriented, you know, sub-classing mechanism to more narrowly define what something is.
James: [00:32:41] That formality word I feel like is important to me. Cause the way I understand it, is they came along and said, this is not machine readable. Like the way that Haystack is being done, two different machines would get two different answers. Right?
Cory: [00:32:55] Yeah. And, and there still is this human in the loop problem , right? So in Haystack it was kind of going in and, and say, you know, I have to apply this entire tag set to type this thing as a discharge air temperature sensor point, okay. Now there is still in Brick, right? Somebody still has to go in and say that this thing is a discharge air temperature sensor. That, I would say doesn't really-, you know, at this point there's still that effort that needs to happen. And so that's, I guess just a point to make, but it does provide more formality in terms of how can you like understand the essence of something by looking like up the tree, right? And so-
James: [00:33:44] And the tree is the taxonomy, right?
Cory: [00:33:46] And the, and the tree is a taxonomy. So we might think of like felions as, you know, a category, which is a sub category of mammals. And, you know, there's then more specific types of cats, right, and these more specific types of cats, you know, get even more specific, and whatever, we have house cats. And so it just provides this structure originally.
And then, so the other problem that they basically wanted to address, is defining kind of legitimate relationships between things of different types. So now we have kind of within more specific categories and subcategories, but how do I relate to things that are kind of, of different categories? So like a bunny is the prey of like a coyote, right? Or, you know, those end up in two different, you know, bottom levels of the tree, but there's still some sort of like kind of relationship between them. And so this is where, like the ontology kind of comes into play and you say, you know, you define legitimate relationships between different types of things.
And I think one of the biggest grievances that Brick had, and I know as like a user starting off that, so it was very difficult for me to understand what type of relationship they should use to reference certain things. So certain things were easy, like a point related to a piece of equipment, it's always an equip ref, you know. But then you use something like a fan located in it , in the discharge duct of an air handling unit. And now a fan equip refs to an equipment, to an air handler. Now those are two very distinct types of relationships, right? So it's , you know, it's a thing it's contained by, or is a part of, I guess, is what Brick uses. And this other thing is a point of this thing. So Brick kind of said like, let's have more relationships, and define these more formally in a sense.
James: [00:35:38] Yeah. And I've had the same thing where you're using, if you're using Haystack 3, you're using the same tag to mean different stuff. And that's where you start to confuse a computer. You know, a human would notice the difference between an equip ref. when you, when they look at a VAV or an air handler, or where a fan is in an air handler, but the machine is like, you just used the same tag to mean two different things.
So, okay. So as we kind of keep kind of moving down this progression of where we've come, so the way I understand it then is the Haystack guys basically said, okay, I hear you Brick. And so then they created Haystack 4, is that how things happened?
Cory: [00:36:18] Yeah, my understanding, yeah. I know that there was kind of a lot of conversations between Brian Frank and Gabe and like, you know, how do we transition forward? And I know, I would say that Haystack 4 is like, you know, still like an in-progress kind of effort. So they're on like, you know, pre-released like 3.9.8, right. So they're just trying to get this better and better and addressing more aspects. And I would say that, so let's say Haystack is kind of moving to this more type-oriented system, defining, you know, subclasses and things like that.
And in general, if you look at kind of where Brick and Haystack 4 are right now, like their equipment hierarchy looks very similar, for, you know, most of what those, the equipment that is there. But you then look at the point typing system, and it's like very different. And, you know, I basically have a top level point and then, in Haystack, and then I have a cur point, and a his point, and a write point, or something like that. These are subclasses of points. but it's very different than Brick, which basically says that-, well, we talked about this before, so I won't go into it. Right? But that's just to say, and I don't necessarily know who's right, or what the right way to go about it is.
And I think that, and I think this is a distinction. Because, you know, some things in Haystack don't really map cleanly because they, they weren't really-, Haystack was designed to solve different problems than I think what Brick and 223 are actually going after. So Brick and 223 are really going after the ontology issue, which is only actually part of what Haystack addresses. So Brick and 223 are basically trying to say like, How do we talk about systems and what sort of things do we need to talk about? And Haystack, you know, it does that for the most part kind of, but it also goes into, you know, how do you get, you know, other metadata info from this? How do you get time series data out of this thing? Right? And, and that, I think just goes with, you know, where these are at, or what they originally intended to solve. And Haystack wanted to kind of provide like a one stop shop solution to all of this stuff. And Brick and 223, I think are more like, let's solve the ontology issue first, and then we can go after data access and stuff.
James: [00:38:49] Okay. Interesting. So, so 223, if we just kind of continue in the very generalized, probably not that accurate story that I've been telling here, is then Haystack 4 came out and at some point ASHRAE sort of decided they were going to bring all this together into one effort. And so is Haystack and Brick, they're both on the 223 committee. Who else is on that committee, and how does that, what, like what's their, their goal and timeframe and all that? And what's the status of it?
Cory: [00:39:21] Yeah. Good question. So what is now the SI, semantic interoperability, working group, as part of ASHRAE 135 committee, I'm still trying to understand like all the SSPCs and SPCs and things like that in ASHRAE, but we have that. So that originally, the Semantic Interoperability working group started off actually as the Application Profiles working group. And that had been going on as I understand it for maybe like 10 years, and they were trying to do something similar. And so then yeah, Brick and Haystack and 223, want to work together. And so recently I think just this year, Steven Bushby took over as kind of the head convener of the semantic interoperability working group. It got like a rebranding kind of, and is going through kind of like modifying the title, purpose, and scope for it. But it's gotten a lot of people kind of to the table. And these are people from like NIST, universities, national labs, and DOE has kind of been, you know, seeing that this is kind of an issue and wants to, you know, help address it. So, and then you have, you know, industry folks as well. And so I think, yeah, so, so that's kind of like who's on the committee.
If you look at the timeline, I'm not really too sure about the timeline. I'm assuming that it's going to be something like three to five years before a standard comes out, but-
James: [00:40:50] Which is surprising to me, right? Because this group was announced in like 2018. So it's already been like-, before talking to you and like, I didn't know, like, is this close to being done? Like, it sounds like it's not converged on solution. You guys are still working through, like you said, starting with ontology and then you move on after that.
Cory: [00:41:13] Yep. Yeah, I would agree with that. So it's-, and I would say that, you know, 223 is actually, you know, asking some really tough questions. And I think that, you know, there are some very smart people in there. So people who like are like information architects either like by learning or training or whatever, right. But people who like actually do this as a job. This to me, like I'm trying to learn how to do it, right. So, but you have Joel Bender who is, you know, kind of trying to identify gaps in like both Brick and Haystack and kind of what 223 it needs to be. And I think that it's, it's actually a really good exercise because, it's trying to start, I wouldn't say fresh, but it's trying to, you know, evaluate things through a new lens.
And, you know, Brick kind of started with Haystack terms and tags and kind of, let's say reorganized it a little bit. 223 is going into, you know, let's break down like a piece of equipment, right? So we're going through this exercise where we're just looking at, you know, ASHRAE Guideline 36 systems and breaking it down into all of its constituent pieces. And what kinds of relationships and systems and components do we need to kind of consider, right? And so a classic example right now is, Brick and Haystack had no kind of concept of connections or, you know, the directionality between things, besides like maybe feeds or something like that. But within like an air handling unit, right, I might define, I have a heating coil, a cooling coil or whatever. And there was no way to basically say like what the order of these things are, right? And what kind of, you know, substances are kind of like flowing between these things. And so Joel, you know, there' s-, in 223 it's really about trying to bring together the best of a lot of different ontologies and say, this is how you can, like they can work together.
So there's this other ontology called SAREF which, you know, has the concept of connections, connection, points, and systems. And so it's kind of marrying, you know, SAREF with these different connections and basically, you know, defining ports, right? So a connection might have multiple connection points and defining like legitimate, you know, inputs and outputs to these connection points. So if I have a heating coil, like a hot water coil, right, that might have an air inlet and outlet, but it also has like water inlet and an outlet, right? And so it's pretty interesting because it's getting down to like, how do we model very, very detailed things? And, and then, and the other question is like, at what detail do we need to model it? Right now to me, it looks a lot like something like an EnergyPlus or OpenStudio, where, you know, they did have to solve this kind of issue a long time ago. You know, how do we-, because you have to have full fidelity of like an energy model, right? So you have to know flows, you have to know inputs, outputs, like exactly, right? I can't not know that. So it's pretty interesting because it, it, it does look to me a lot like it is going to somewhat line up with what, you know, we would think of as like a building energy model might look like.
James: [00:44:33] Okay, well I think that's a fascinating kind of, you know, we kind of just fast forwarded through like 10 plus years of semantic interoperability history, but I wanted to do it because this isn't a solved problem. And it's also a really big problem. Right? So it's not as easy as just adding tags and hoping the problem is solved. Right? And I think it's good to like tell that story because I think there is a myth in at least the, the kind of circles that I've come from, which is if I'm using Haystack, for instance, or, you know, even, or Brick, right? But mostly it's Haystacks more popular in the private sector, right. It's, it's, it's a lot more widely distributed. It's a lot more, it has been, you know, people are making Haystack their standard, right? And they're, they're more often in buildings right now. So I think there's this sort of myth, right, that if I add Haystack tags to a building, then now it's set up for whatever you want to do. And it's now interoperable, right? So how would you sort of respond to that assessment? I mean, we've, we've touched on it a little bit, but I think we should just kind of directly talk about it pretty quickly here.
Cory: [00:45:48] So, sorry. Say the question just one more time.
James: [00:45:51] Yeah. So like, I think there's a myth around, if you just sort of, and one of my buddies likes to use the word, if you just sprinkle Haystack tags, then the interoperability problem is solved, right? And this kind of gets at this whole kind of trend towards open data layer or data lakes, where there's people out there that are basically saying, but, you know, just get your data into a database and get it Haystack tagged, and now you're ready to do whatever you want with it, right. So how would you sort of respond to that besides laughing?
Cory: [00:46:27] Yeah. So I would say, like the reason that this whole ontology question comes into play is that, that might work for certain applications. And this is where, you know, if we talk about the smart building space, the smart building space is growing very fast, right? And we can talk about this all the way from, you know, doing simple rules-based fault detection and diagnostics, and starting, you know, with a lot of this stuff that Steve Bushby worked around on 15 years ago with these air handling performance assessment rules, right? I'm just comparing supply air temperature and mixed air temperature. And based on a mode, right, I can say that a fault has occurred. Now, that is a very-, that's at one end of the spectrum. The other end is that now, if you're looking at kind of grid interoperable buildings or grid efficient buildings, and you're looking at model predictive control, you need to have like a very, very, very detailed picture what your system is, and what is contained in it, and its relationships. And even how the, you know, the thermodynamics and stuff work. And those are, those are very two different views that you have to take of the world.
And so what 223 is kind of doing, it's like, what is the most detailed view that we can take? And if we take that, how, what are the things that we need to talk about, and how can we talk about it in an abstract manner? Whereas-
James: [00:47:52] I think what you're saying is like use cases, that there's many different use cases for the same data, right? So just because someone tags a data set for their use case doesn't mean it then enables every smart building use case that could possibly use that data, right?
Cory: [00:48:11] Exactly. Yeah. And so you have different applications that actually need different things, right? So one application, and this is like, you know, there's no concept of Haystack like compliance or verification right now, because it's kind of like you use the dictionary terms to basically identify the things that you need to identify. And primarily this is for, you know, let's say a monitoring based commissioning firm, or, you know, some sort of firm who's selling SaaS, you know, to implement their solution. They're not really looking at, you know, who might the next player down the line be, who might want to consume this and what might they need from a data perspective, and what aspects of the model do they actually need to know about?
And so, so this is where it kind of, if we're talking about application to application interoperability, you have to take like the same viewpoint on modeling something so that you can kind of both, both of your applications could get the data that they need to, to run whatever they need to run, basically.
James: [00:49:18] Yeah. And right now the standards aren't extensive enough. Maybe that's not the right term, but we've kind of covered it. They're not at a place where they have a standardized way to add all of this metadata, basically that would then fully describe a, say a discharge air temperature sensor for every application that could use it.
And so I think what I've experienced is you might have two companies that are trying to use Haystack, for instance, and they've gotten to the limits of the Haystack standard, and then they've then added onto it, right. So they've used Haystack up to a point, and then now they've added Haystack-ish sorts of tags. And so now we have basically n plus one standards. And then you have the next company that's doing Haystack, and then they got Haystack-ish, and their Haystack-ish is different than the other company's Haystack-ish. And so now what we have is like basically, we have a world where then the humans can probably understand it, but the machines couldn't, if you wanted to plug two different applications into that tagged dataset.
Cool. So that's a good summary of the, what I see as the two main challenges. So let's talk about opportunities. So what are the kind of the big opportunities for kind of making interoperability more, more streamlined, easier to do, and more heavily promoted in the industry today?
Cory: [00:50:48] Yeah. You know, I think, I think a big aspect of that is just proving out or like having two kind of vendors come together and say like, look, we're going to prove, you know, not just that we can exchange Haystack data over like an API, but that, you know, we can both kind of like round trip, you know, fully round trip through our tools, and come to the same conclusion like about, you know, what this system is. And we agree on the necessary components that we need to model in order to do that. And it's, you know, and, and that's kind of, to me, a big aspect of it that I think hasn't really been done super well.
I think one of the reasons it hasn't been done super well is there hasn't really been like a third party spec that basically says, you know, like when we say a package rooftop unit with single-stage DX cooling and gas furnace, you know, heating, this is exactly what your model needs to look like. There's nothing out there that says that. There's kind of maybe some like examples, but there's nothing saying like, this is how to do that system. And so I think that's an opportunity, is to kind of look at what are the most common system, you know, a few of the most, five to 10 of the most common system types out there, come to an agreement on basically how those should be modeled and kind of prove round tripping, you know, through multiple vendor systems to do that.
So I think that's definitely like, from an interoperability perspective, especially in the semantic aspect, that is I think the opportunity. It's also, you know, the hardest, in terms of like, we have to have two vendors who are kind of gonna take this on. You know, I think if two vendors took this on, it becomes easier for other people to get in on the game.
And you kind of-, it might not be, you know, a hundred percent like, perfect in the sense that I think 223 is like trying to work towards, but maybe it gets us kind of 90% of the way there for a few different system types that we generally see. So I think that's one big opportunity.
And with that, like, I think comes the opportunity to also have basically reference implementations, right? So a big ask is on the Haystack forums, you'll see this, it's like where can I-, like do people have sample data that I can look at? There's not really much out there. There's a few sample buildings generally with simple systems , but we don't really have good reference implementations for doing, you know, more complex systems. I liken this to kind of having the DOE prototype buildings from an energy modeling perspective, which is like, look, we're just going to define like a very generic, small office building and say, you know, this is the system type, and this is like what it looks like. I think we can kind of do that, in the same way for Haystack as well. So putting those out there so that people can go in, look at examples. I mean, I'm a very example- oriented learner. So it's, it's very easy for me to go see something, and okay, now it makes a lot more sense. Seeing a list of tags and, you know, and these scattered forum posts that you have to maybe try to, you know, work through to kind of come to a conclusion about how something should be done. I'm sure you can do that, but it would be nice if we just had like a best practice type book. So I think that that's definitely an opportunity as well.
And along with that is kind of like some tooling. So having some vendor tooling, you know, to help people do these systems more consistently, right. We still, you still probably want to use it or to interface with something that is very simple. You know, you want to abstract away tags probably in the data model that goes underneath it, but providing them with some sort of forms or whatever that, you know, just enter in this information quickly. You know, don't worry about the data model that all happens in the backend and, you know, you're good to go. So, you know, I think tooling around this is really important and that's something that, you know, will push I think, vendors, to, to improve tooling, to help with that.
James: [00:55:04] Yeah. And do you think that would be on-, like I know SkySpark is definitely building out tooling in their latest releases. So you think that would be a vendor thing or it would be a vendor agnostic sort of set of tools?
Cory: [00:55:16] Yeah. I mean, I think you could go both ways. It definitely seems like there is like a cry out there for, you know, some sort of open source Haystack builder type of thing.
James: [00:55:30] Yeah.
Cory: [00:55:30] Brick is maybe like a little bit easier because it, it uses, it builds on the semantic web technologies. So there are, you know, in Python, things like that, you know, typical RDF tool sets, and standard ways of kind of constructing these. So not, you know, not that everybody's going to go in Python and build RDF graphs or whatever, but it is available for people if they want to get their hands dirty.
One of the things with Haystack is that it can be difficult because the ibraries that maybe are available on the Project Haystack website, you know, different programming language libraries, they cover very different aspects of Haystack. Some of them just implement kind of the API spec. Some of them have incorporations of the Haystack data model. Some of them have incorporations of like the Haystack literals and actual like data types that, so there's kind of a wide spread, and it's, and they're not consistent.
And so anyways, I do think that there is kind of a cry in the industry to have some sort of open, you know, third party Haystack builder type thing, so.
James: [00:56:39] Yeah. Okay. Alright. Cool. I mean, those are three great projects. How should listeners get involved in something in this area if they're interested?
Cory: [00:56:49] Yeah, I mean, likely people might hear this conversation. You know, I don't think anybody is just building like Haystack things for the fun of it or Brick things or whatever, right. So probably people have products and probably all of these different products have different use cases or applications or similar ones or whatever.
When you talk about kind of like application level interoperability and the importance of semantic models, it's really good to get like all of these perspectives involved, because you know what one application needs and what they talk about it as, might not be the same as another one. And so getting these people kind of in the same room together, becomes really useful to, you know, just have the conversation. And I think that's kind of where 223 has done a really good job. Steve Bushby kind of sets this really good tone, like invitational tone, for, you know, getting people involved and hearing different perspectives and stuff. And so, you know, I think, you know, that the 223 group is a good place.
You know, the Haystack forums as well. Generally there's not a ton of people who I would say participate in the Haystack forums, right. It's kind of easy to do like a one off like question, like I have a, I need a quick answer, but, you know, to really dedicate time to try to propose like a thoughtful solution to some of these problems that we face in a way that becomes, you know, usable for others down the road, right. It's not just like one person solving it in their application. It's, you know, how do I take the experiences that I've had in the field in implementing Haystack, translate those into, you know, present the, present the use case, present the scenario to the group and, you know, contribute back. And so I, I think that's would be like super helpful. You know, we would, I think love to have more people contributing in that space and kind of working towards a kind of common goals, so.
James: [00:58:41] Got it. Alright. I think that's a good place to drop off for now, but I'm sure this conversation will continue as things progress in this area. So thanks, Cory, for coming on the show. Really appreciate it.
Cory: [00:58:53] Yeah. Cheers man. Thanks for having me.
James: [00:58:55] Alright, friends. Thanks for listening to this episode of the Nexus podcast. For more episodes like this and to get the weekly Nexus newsletter, please subscribe at nexus.substack.com. You can find the show notes for this conversation there as well. As always, please reach out on LinkedIn with any thoughts on this episode.
I'd love to hear from you. Have a great day.
Happy Thursday!
Welcome to this week’s deep dive exclusively for Nexus Pro members. It’s an honor to have you here. This deep dive is a follow up to my recent podcast conversation my NREL colleague, Cory Mosiman. I learned a lot from this conversation and want to share my takeaways and the full transcript with you below.
In case you missed it in your inbox, you can find the audio or video here:
Nexus site | Apple Podcasts | Spotify | YouTube | Add to other podcast apps
Enjoy!
—James
Disclaimer: James is a researcher at the National Renewable Energy Laboratory (NREL). All opinions expressed via Nexus emails, podcasts, or the website belong solely to James. No resources from NREL are used to support Nexus. NREL does not endorse or support any aspect of Nexus.
This was the nerdiest conversation yet for the Nexus Podcast. As I say, Nexus is my project for learning out loud, and this episode definitely reflects that ethos.
My main reaction was that I hope it clears up some myths for others. Since meeting Cory and having these types of conversations, I've had a few myths busted of my own. I used to be one of those people that thought Haystack 3 was the end all be all solution for interoperability.
One thing I'm wondering from the community is what everyone sees as today's best practice for a building owner to model their data, based on the state of Haystack, Brick, and ASHRAE 223? On one hand, you could say "why even bother?" With things in so much flux, it could be difficult to justify jumping on any bandwagon.
I see it differently. I think a building owner or application vendor should model their data in the most detailed way they need to in order to meet the needs of their use cases. But it should be done in a flexible way to accommodate these changing standards. Then, as the standards change, they can update their semantic model to stay in line with the standard.
[00:15:03]
Cory: So there's never really been a need to understand, like the essence of what something is I would say.
And that's kind of a question like, you know, it's kind of a philosophical question and this is like, from my understanding where, you know, ontologies and taxonomies kind of come in, right? Cause they're talking about kind of the philosophy of what it means to be this thing, and what do systems mean? And, those kinds of things.
James: Before we get there, I think the not needed piece is key. So a control system doesn't need that. It doesn't need to know that today, right, to produce what is today's building automation system, right? It's inputs and outputs. It's PID loops and it like gets the job done okay, basically, without knowing anything about itself. But as we, I think, where we're going in the industry is when we start to do things like analytics, those do require some sort of knowledge of what this thing is, right? The essence of the thing. And that's how we basically add intelligence. We add analytics to it. We need to know those things. And so I think from my perspective, like, where we're going is because that of that gap, where we're going with this conversation is because of that gap that's been created. Right? We need, we need the system to know what it is, and it doesn't know what it is. Maybe it's just that, that's as simple as we can put it.
Cory: Yeah. And I think like, yeah, so analytics, FDD come in and I think for the most part, like people thought BMS was probably going to be the last thing that was like ever needed, right? And so that was kind of like - and still is considered a lot of times - like the top tier application in the stack of kind of the controls world.
But then you had, you know, analytics and FDD kind of come into play. And now what you introduce is basically a new application, right? That now is trying to communicate with your BMS application or your BACnet network, and it's trying to come to some sort of understanding of what's all out there, right, in terms of systems and devices. And it doesn't actually really care too much about the devices, only in the sense that the devices are what gives it the information. And FDD is really about understanding, you know, kind of system, system workings. And so this is I think really where, you know, semantic interoperability comes into play, is when you have kind of complex applications that are, or applications that are trying to do more complex things, which are, you know, a lot of times based on the physics and the thermodynamics and things like that, where it becomes really important to know kind of, what the essence of things are, what properties things have, stuff like that.
[00:27:16]
James: So if we take it back to that DAT sensor that's kind of lost in the world. So if we do Haystack 3 perfectly, what do we now know about? Or what can we communicate to each other about that DAT sensor?
Cory: Yeah. So, and I think this is kind of an important aspect. So you and I could definitely communicate discharge air temp sensor point. We understand that concept, and that conveys like a full meaning to us. And then we would also use like an equip ref tag on that point to say, you know, that this belongs to this air handler.
So I know basically kind of the type of that thing, I also know what it's kind of connected to-
James: Say we were on a campus though. We would also know like, we'd have site refs, and maybe even more metadata around like what building that sits in. Maybe, maybe we'd know, like, depending on the user of the Haystack tags, we would know, like maybe we would even know what floor or like what like group of zones, like things like that can be added, right? If I want to, to kind of provide more tag-based context around that DAT sensor. Right?
Cory: Yep.
James: Cool. So, I mean, that helps. Right? So that allows someone that is setting up something like an analytics platform to quickly and easily understand the context of all the data in the building. Right? So that's, I mean, I think one thing to note is that as we talk about all this different progression, we're big fans of everything that's happened so far.
[00:29:13]
Cory: Yeah. So this, this goes back to kind of this application level interoperability. And so if we think about a data dictionary, you and I can have like a conversation, but there's no, in Haystack 3 it was just, you know, if you go to their tags page, right, it's just a list of like 50 or a hundred tags and a definition next to it. And so every time let's say a human had to kind of go, you still had a human in the loop, type process. So it was a human going to the Haystack website, kind of interpreting what an individual tag meant. Now there were some examples of like what tag sets together, like you, you know, typical tag sets on an air handler or a VAV box or something like that, but it was still kind of a highly human in the loop process. And part of that had to do with what we'll get into as like a taxonomy. So Haystack didn't really have a taxonomy or like an ontology in Haystack 3. And what a taxonomy does, it's basically, it provides like formal, like more formalized definitions for subtyping , and kind of providing categories and subcategories to the data that we're talking about.
So, in Haystack, you know, there was this kind of convention that, you know, there were three main types of things: a site, an equip, and a point, and these were, you know, kind of more specific types of things. But there was nothing really formal to say that; there was no like machine readable way to say that. So Brick came along and said, okay, like we need to define this in a more formal structure. And they use semantic web technologies, which kind of consists of RDF OWL, RDF SPARQL. Maybe you hear these words every once in a while, but these are kind of just like the grouping of what they call semantic web technologies.
And so they say, okay, let's, let's use this technology to do this kind of typing system, and like a formal typing system. So now I have a top level thing that's called a point. And, you know, a sensor point is a direct subclass of a point, right? It is a more specific type of point and more specifically, it is something that is kind of being read in from a sensor, whether that's like a digital or something sensor, right. And then they say, okay, a temperature sensor is an even more specific type of sensor point. And it is something that, you know, specifically measures the temperature property of something else. Right. And then, and they also, you know, now I have air temperature sensor, which I know is measuring, it's measuring the temperature property of the air substance. And then I have a discharge air temperature sensor, right. Which is measuring the air substance, the temperature property of the air substance located in the discharge basically.
Now, now this you could do with Haystack, but it was Haystack 3, but it was still informal. So that's kind of where Brick comes along is like, let's just have some more specific categories and we can, you know, use just a class oriented, you know, sub-classing mechanism to more narrowly define what something is.
James: That formality word I feel like is important to me. Cause the way I understand it, is they came along and said, this is not machine readable. Like the way that Haystack is being done, two different machines would get two different answers. Right?
Cory: Yeah. And, and there still is this human in the loop problem , right? So in Haystack it was kind of going in and, and say, you know, I have to apply this entire tag set to type this thing as a discharge air temperature sensor point, okay. Now there is still in Brick, right? Somebody still has to go in and say that this thing is a discharge air temperature sensor. That, I would say doesn't really-, you know, at this point there's still that effort that needs to happen. And so that's, I guess just a point to make, but it does provide more formality in terms of how can you like understand the essence of something by looking like up the tree, right? And so-
James: And the tree is the taxonomy, right?
Cory: And the, and the tree is a taxonomy. So we might think of like felions as, you know, a category, which is a sub category of mammals. And, you know, there's then more specific types of cats, right, and these more specific types of cats, you know, get even more specific, and whatever, we have house cats. And so it just provides this structure originally.
And then, so the other problem that they basically wanted to address, is defining kind of legitimate relationships between things of different types. So now we have kind of within more specific categories and subcategories, but how do I relate to things that are kind of, of different categories? So like a bunny is the prey of like a coyote, right? Or, you know, those end up in two different, you know, bottom levels of the tree, but there's still some sort of like kind of relationship between them. And so this is where, like the ontology kind of comes into play and you say, you know, you define legitimate relationships between different types of things.
And I think one of the biggest grievances that Brick had, and I know as like a user starting off that, so it was very difficult for me to understand what type of relationship they should use to reference certain things. So certain things were easy, like a point related to a piece of equipment, it's always an equip ref, you know. But then you use something like a fan located in it , in the discharge duct of an air handling unit. And now a fan equip refs to an equipment, to an air handler. Now those are two very distinct types of relationships, right? So it's , you know, it's a thing it's contained by, or is a part of, I guess, is what Brick uses. And this other thing is a point of this thing. So Brick kind of said like, let's have more relationships, and define these more formally in a sense.
James: Yeah. And I've had the same thing where you're using, if you're using Haystack 3, you're using the same tag to mean different stuff. And that's where you start to confuse a computer. You know, a human would notice the difference between an equip ref. when you, when they look at a VAV or an air handler, or where a fan is in an air handler, but the machine is like, you just used the same tag to mean two different things.
So, okay. So as we kind of keep kind of moving down this progression of where we've come, so the way I understand it then is the Haystack guys basically said, okay, I hear you Brick.
[00:37:40]
I think this is a distinction. Because, you know, some things in Haystack don't really map cleanly because they, they weren't really-, Haystack was designed to solve different problems than I think what Brick and 223 are actually going after. So Brick and 223 are really going after the ontology issue, which is only actually part of what Haystack addresses. So Brick and 223 are basically trying to say like, How do we talk about systems and what sort of things do we need to talk about? And Haystack, you know, it does that for the most part kind of, but it also goes into, you know, how do you get, you know, other metadata info from this? How do you get time series data out of this thing? Right? And, and that, I think just goes with, you know, where these are at, or what they originally intended to solve. And Haystack wanted to kind of provide like a one stop shop solution to all of this stuff. And Brick and 223, I think are more like, let's solve the ontology issue first, and then we can go after data access and stuff.
[00:42:01]
Brick kind of started with Haystack terms and tags and kind of, let's say reorganized it a little bit. 223 is going into, you know, let's break down like a piece of equipment, right? So we're going through this exercise where we're just looking at, you know, ASHRAE Guideline 36 systems and breaking it down into all of its constituent pieces. And what kinds of relationships and systems and components do we need to kind of consider, right? And so a classic example right now is, Brick and Haystack had no kind of concept of connections or, you know, the directionality between things, besides like maybe feeds or something like that. But within like an air handling unit, right, I might define, I have a heating coil, a cooling coil or whatever. And there was no way to basically say like what the order of these things are, right? And what kind of, you know, substances are kind of like flowing between these things. And so Joel, you know, there' s-, in 223 it's really about trying to bring together the best of a lot of different ontologies and say, this is how you can, like they can work together.
So there's this other ontology called SAREF which, you know, has the concept of connections, connection, points, and systems. And so it's kind of marrying, you know, SAREF with these different connections and basically, you know, defining ports, right? So a connection might have multiple connection points and defining like legitimate, you know, inputs and outputs to these connection points. So if I have a heating coil, like a hot water coil, right, that might have an air inlet and outlet, but it also has like water inlet and an outlet, right? And so it's pretty interesting because it's getting down to like, how do we model very, very detailed things? And, and then, and the other question is like, at what detail do we need to model it right now?
[00:47:52]
James: I think what you're saying is like use cases, that there's many different use cases for the same data, right? So just because someone tags a data set for their use case doesn't mean it then enables every smart building use case that could possibly use that data, right?
Cory: Exactly. Yeah. And so you have different applications that actually need different things, right? So one application, and this is like, you know, there's no concept of Haystack like compliance or verification right now, because it's kind of like you use the dictionary terms to basically identify the things that you need to identify. And primarily this is for, you know, let's say a monitoring based commissioning firm, or, you know, some sort of firm who's selling SaaS, you know, to implement their solution. They're not really looking at, you know, who might the next player down the line be, who might want to consume this and what might they need from a data perspective, and what aspects of the model do they actually need to know about?
And so, so this is where it kind of, if we're talking about application to application interoperability, you have to take like the same viewpoint on modeling something so that you can kind of both, both of your applications could get the data that they need to, to run whatever they need to run, basically.
[00:49:18]
And right now the standards aren't extensive enough. Maybe that's not the right term, but we've kind of covered it. They're not at a place where they have a standardized way to add all of this metadata, basically that would then fully describe a, say a discharge air temperature sensor for every application that could use it.
And so I think what I've experienced is you might have two companies that are trying to use Haystack, for instance, and they've gotten to the limits of the Haystack standard, and then they've then added onto it, right. So they've used Haystack up to a point, and then now they've added Haystack-ish sorts of tags. And so now we have basically n plus one standards. And then you have the next company that's doing Haystack, and then they got Haystack-ish, and their Haystack-ish is different than the other company's Haystack-ish. And so now what we have is like basically, we have a world where then the humans can probably understand it, but the machines couldn't, if you wanted to plug two different applications into that tagged dataset.
[00:51:36]
Cory: There hasn't really been like a third party spec that basically says, you know, like when we say a package rooftop unit with single-stage DX cooling and gas furnace, you know, heating, this is exactly what your model needs to look like. There's nothing out there that says that. There's kind of maybe some like examples, but there's nothing saying like, this is how to do that system. And so I think that's an opportunity, is to kind of look at what are the most common system, you know, a few of the most, five to 10 of the most common system types out there, come to an agreement on basically how those should be modeled and kind of prove round tripping, you know, through multiple vendor systems to do that.
…
And with that, I think comes the opportunity to also have basically reference implementations, right? So a big ask is on the Haystack forums, you'll see this, it's like where can I-, like do people have sample data that I can look at? There's not really much out there. There's a few sample buildings generally with simple systems , but we don't really have good reference implementations for doing, you know, more complex systems. I liken this to kind of having the DOE prototype buildings from an energy modeling perspective, which is like, look, we're just going to define like a very generic, small office building and say, you know, this is the system type, and this is like what it looks like. I think we can kind of do that, in the same way for Haystack as well. So putting those out there so that people can go in, look at examples. I mean, I'm a very example- oriented learner. So it's, it's very easy for me to go see something, and okay, now it makes a lot more sense.
…
And along with that is kind of like some tooling. So having some vendor tooling, you know, to help people do these systems more consistently, right. We still, you still probably want to use it or to interface with something that is very simple. You know, you want to abstract away tags probably in the data model that goes underneath it, but providing them with some sort of forms or whatever that, you know, just enter in this information quickly. You know, don't worry about the data model that all happens in the backend and, you know, you're good to go. So, you know, I think tooling around this is really important and that's something that, you know, will push I think, vendors, to, to improve tooling, to help with that.
James: Yeah. And do you think that would be on-, like I know SkySpark is definitely building out tooling in their latest releases. So you think that would be a vendor thing or it would be a vendor agnostic sort of set of tools?
Cory: Yeah. I mean, I think you could go both ways. It definitely seems like there is like a cry out there for, you know, some sort of open source Haystack builder type of thing.
James: Yeah.
Cory: Brick is maybe like a little bit easier because it, it uses, it builds on the semantic web technologies. So there are, you know, in Python, things like that, you know, typical RDF tool sets, and standard ways of kind of constructing these. So not, you know, not that everybody's going to go in Python and build RDF graphs or whatever, but it is available for people if they want to get their hands dirty.
One of the things with Haystack is that it can be difficult because the ibraries that maybe are available on the Project Haystack website, you know, different programming language libraries, they cover very different aspects of Haystack. Some of them just implement kind of the API spec. Some of them have incorporations of the Haystack data model. Some of them have incorporations of like the Haystack literals and actual like data types that, so there's kind of a wide spread, and it's, and they're not consistent.
And so anyways, I do think that there is kind of a cry in the industry to have some sort of open, you know, third party Haystack builder type thing, so.
What did you think about these highlights? Let us know in the comments.
Note: transcript was created using an imperfect machine learning tool and lightly edited by a human (so you can get the gist). Please forgive errors!
James: [00:00:00] Hello, friends. Welcome to Nexus, a smart buildings technology podcast for smart humans. I'm your host, James Dice. If we haven't met before, I write a weekly newsletter on the same topic. It's also called Nexus. Each week I share what I've learned, my opinions, and what I'm excited about in the quickly evolving world of intelligent buildings. Readers have called Nexus the best way to stay up to date on the future of this industry without all the marketing fluff. You can check it out and subscribe at nexus.substack.com or click the link in the show notes.
Since starting the Nexus newsletter, many of you have reached out to me wanting to talk shop, and we have. After a few weeks of those wonderful conversations, I realized I needed to record and share them with our growing community. So here we are. The Nexus podcast is born. This is our chance to explore and learn with the brightest in our industry together.
One more quick note before we get to this week's episode. I'm a researcher at the National Renewable Energy Laboratory, otherwise known as NREL. All opinions expressed on this podcast belong solely to me or the guest. No resources from NREL are used to support Nexus, and NREL does not endorse or support any aspect of Nexus.
Okay. Episode 11 is a conversation with my NREL colleague, Cory Mosiman. Cory and I have these conversations all the time, so we thought it'd be fun to press record once in awhile. Fair warning though, this is the nerdiest episode yet. However, before you stop listening, I want to put that nerdiness in context. Today in buildings across the world, data is locked up and unable to be used. If we could use it, we could do things like help mitigate climate change, create healthier indoor environments, and automate our buildings.
People new to the industry often ask why that is. This conversation is part of that answer. We set aside the business reasons of why the data can't be used, like vendor lock-in that have plagued the industry forever. Instead we dove into the semantic interoperability problem and all of the efforts going on to solve it. This includes the open source projects called Project Haystack and Brick. It also includes the proposed ASHRAE Standard 223 and the associated working group. This is a difficult subject to learn and an even more difficult one to convey. So I hope this conversation takes you closer to understanding what's going on, like it did for me.
This episode of the podcast is directly funded by listeners like you who have joined the Nexus Pro membership community. You can find info on how to join and support the podcast at nexus.substack.com. You can also find the show notes there, which has links to Cory's LinkedIn page. Without further ado, please enjoy Nexus Podcast Episode 11.
Hello, Cory. Welcome to the Nexus Podcast. Can you go ahead and introduce yourself?
Cory: [00:02:58] Hey, James. Yeah, sure. So my name's Cory Mosiman. I am a software engineer at the National Renewable Energy Lab. So James and I work together. I work mainly on interoperability type projects. So I work on interoperability with respect to energy audits, and also a lot of Brick and Haystack, and also I'm in the ASHRAE 223 kind of working group. So, as I understand it, we're going to be talking a lot about aspects of interoperability today. And I'm looking forward to it. I just wanted to make sure I said real quick, so I do participate in the ASHRAE 223 group. I'm not, you know, in any-, you know, none of this stuff is basically official, coming out of ASHRAE. So this is just my understanding of kinda what some of the ASHRAE 223 stuff that's going on, what it looks like. So, but looking forward to discussing.
James: [00:03:46] Yeah, this is not the official ASHRAE position on interoperability at this point. This is us two, trying to figure the world out. Cool.
So yeah. You've taught me a lot. So I thought it'd be good to kind of bring you onto the podcast and see, you know, what we can kind of spread around to the rest of the Nexus community. So first of all, thank you for that. You and I have had lunches, and chats on Microsoft Teams, and a lot of stuff that's kind of helped me. I think I've helped you a lot as well. So it's been good so far.
So let's start off with just setting the context around interoperability. So I mean, you and I are, you know, HVAC and energy nerds. I would say a lot of the Nexus community are the same sort of nerds. So I think a great place to start with this conversation is let's zoom out. Like what the hell is interoperability?
And I'll start by saying here's how I thought of it before our conversations. So I come from the world of energy efficiency and retrocommissioning and monitoring based commissioning. So I've always used Haystack as a way to take data in a control system and make it easier to use in an analytical application. But I realized that's a very limited definition of interoperability . So let's just zoom out and just say like in general, in the world, what is, what does interoperability mean?
Cory: [00:05:17] Yeah. Good question. So to your point, we can talk about interoperability at like a few different levels. And so I think it's important to distinguish. So very briefly we can talk about device level interoperability, so the ability for two devices on a controls network basically to communicate with one another. And I think that that is generally kind of covered in what we think of as BACnet.
James: [00:05:45] And so they speak the same language, basically. So if I'm speaking English and somebody else is speaking Chinese or Mandarin, then it just works?
Cory: [00:05:54] Yeah. And it's kind of about the rules of like negotiation as well, so how do I even find somebody that exists in the world?
James: [00:06:06] Right, so it's more than just the language.
Cory: [00:06:09] Yeah, that's maybe a first part. Right? So how do I find people? How do devices find devices? And then it's kind of like how do you even, how do you identify the language that the other device speaks, if they speak your language, maybe. And then it's kind of what sort of, what sort of services or transactions can you make with that device?
I think of it that way. Right? So you might go to a grocery store and want to buy apples, but they're only, you know, selling pears or whatever. Right? So, and this is kind of where BACnet is. It's understanding, you know, who's out there, and you know, how you can talk to them and what kind of services you can exchange with one another.
James: [00:06:53] Okay. Before we get into BACnet, let's talk about like, what's the definition of interoperability? I mean, you were telling me the other day, it sounds like it's it's like repeatable, and two people from different companies have to be able to do the exact same thing for it, like without human intervention, right? For it to be considered interoperable. Right?
Cory: [00:07:13] Yeah. So I'll also make the disclaimer that I'm not an expert on any of this stuff. So, I'll definitely parrot a lot of things that I've learned from other people. So one of the definitions and ways I like to think about it, I think was brought up by Gabe Fierro, who's one of the Brick guys. And he basically said, you know, W3C, which is worldwide web consortium, they, when they were proving out kind of interoperability for web standards, they always, basically they required that two companies, basically competitors, so similar interests, able to communicate, and basically relay information to one another.
So they never said that some like an interoperability standard was like actually taken into effect until, you know, two separate bases had proven out that they can kind of communicate with one another, and what that communication is, you know, whether that was just, you know, two things talking to each other or, you know, really conveying meaning at the application level. There's, you know, there's lots of different ways that that can be, but I like that definition, you know, proving out that, you know, two people have the same understanding of what they're trying to do and can do that successfully.
James: [00:08:24] Yeah, I like it too, because I think it sets the stage for kind of where we're going to go with this conversation a little bit.
So, there are a ton of different interoperability efforts, right? If we talk about smart buildings and we just like draw a boundary around the smart buildings world, like you could probably just like name off like 20 different interoperability efforts. And so while we're here to talk mostly about HVAC and Haystack, Brick, can you just kind of give us an overview and put in context, Haystack and Brick in the context of all these other efforts that people might've heard about in passing or on their projects?
Cory: [00:09:05] Yeah, sure. I think that's a good idea. So I think you can, you can kind of group these into, you know, different things, that have been solved for, or are trying to be solved for by these standards. So if we talk about kind of device to device communication, we tend to think of BACnet, LonWorks, or Modbus, right? Those are kind of three pretty standard things that a lot of controls people are familiar with. That's one small portion, right? And that's all in the operational phase. You know, design and construction processes are like processes, right? They're ongoing. And, they, you know, contain a lot of stakeholders.
So, so additionally in this world, you know, we think about kind of building information modeling. So, how do basically, you know, an Autodesk Revit and another like BIM application, how do they, you know, take whatever that they're building and, you know, transfer it to one another, without, you know, data loss or corruption. So that, that I would say is like BIM to BIM interoperability. And that is covered by the industry foundation classes. And I think like COBie is maybe another one. I think there's some relation between those two, but anyway, so that I would say-
James: [00:10:17] I actually have heard those two.
Cory: [00:10:19] Okay, so that I would say is kind of like the BIM to BIM world.
We also have this other workflow, right? That is the building information modeling to the building energy modeling. Right? So, using EnergyPlus OpenStudio to simulate a building, and taking basically information as defined in your Revit model and running that into energy model, right? So not having to rebuild your whole building. And that's, you know, generally covered by gbXML, and yeah. So that's, let's say gbXML.
Then we have this other one, which is kind of like auditing and reporting, I would characterize it as. So these are things like Green Button X ML, maybe it's an XML? ENERGY STAR XML, BuildingSync XML, which is kind of like a schema for energy reporting, energy audit data, and then HPXML, which is energy audit data for residential. So this is another one, right? So a lot of these are, you know, XMLs, schemas, things like that.
And then you have, you know, these things, which are, you know, everybody in our world talks about right now, which is more on the operational side of things, is how I tend to think of it. So this is where like Haystack and Brick and 223 come into play, where you're really kind of looking at maybe more controls-oriented, system-oriented kind of interoperability. And people often talk about, you know, this thing or this concept of semantic interoperability when they're talking about that. So we can discuss that a little bit more.
You know, then you have, you know, Troy Harvey is doing some things with this digital twin standard. Microsoft I know is working on this digital twin definition language, which is another kind of schema ontology, not totally sure. Basically, there's a lot of stuff out there.
James: [00:12:05] Yeah, definitely. And I just have this sense that as you just listed all of that off, I just-, there has to be more, right? Like those are the ones that-, yeah. Right. So there's just a ton of things going on. So I don't want to blow this conversation up. We want to just keep it narrow, down to what we know.
So let's, let's kind of dive into HVAC and controls type of applications. So I know this is like a big question, but why don't we have interoperability now with that sort of data?
I mean, and let me set the context a little more there. So BACnet has been around for 20 plus years, something like that. so I think there might be sort of a first myth that BACnet has solved it. And then I think there's also probably a question around like if BAcnet's around, and then we all understand that interoperability is a goal, couldn't a control system just be set up from the beginning for interoperability to begin with? So I know this is a huge question-
Cory: [00:13:14] You mean sort of semantic interoperability to begin with, or-
James: [00:13:17] Maybe you just begin there. So what's the difference between semantic interoperability and just more general interoperability, like we defined it earlier?
Cory: [00:13:27] Sure. Yeah, so I would say, so two things. I think if, if we look at kind of the history of basically BMS applications, right, and kind of as they exist today, they're really, you know, implementing control methods. And many people have pointed this out already that, you know, they don't really have an understanding of what a system is, right? I can use a, I could probably use something like a VAV controller and plug a few IOs from like an air handling unit into it, right, and it probably wouldn't know the difference except that now I don't have enough landing ports, you know, to land all of the input output that I need to for an air handler, right. So there's, there's kind of this, this aspect, you know, that controllers are very extensible, right? So they can, you can add more IOs, but really it's controls right now. It's all IO driven and so, so it doesn't really have an understanding, let's say, of the system, of like the components in the system. And more broadly, and this is kind of like Troy Harvey's point, it doesn't really understand physics at all, or like thermodynamics. Right? Which are very important for it to function. Right? So a VAV box doesn't really understand, you know, like, or a VAV controller doesn't really understand like flow rates and how actuating a damper is going to, you know, change flow rates, right? It does only in the sense that you kind of programmed a few things in there to, and based on IOs, right?
James: [00:14:55] So a semantic model is like not needed for the way that our control systems are set up in the buildings world right now.
Cory: [00:15:03] Yeah. So there, yeah, there's never really been a need to understand, like the essence of what something is I would say.
And that's kind of a question like, that's like, you know, it's kind of a philosophical question and this is like, from my understanding where, you know, ontologies and taxonomies kind of come in, right? Cause they're talking about kind of the philosophy of what it means to be this thing, and what does systems mean? And, those kinds of things.
James: [00:15:27] Before we get there, I think the not needed piece is key. So a control system doesn't need that. It doesn't need to know that today, right, to produce what is today's building automation system, right? It's inputs and outputs. It's PID loops and it like gets the job done okay, basically, without knowing anything about itself. But as we, I think, where we're going in the industry is when we start to do things like analytics, those do require some sort of knowledge of what this thing is, right? The essence of the thing. And that's how we basically add intelligence. We add analytics to it. We need to know those things. And so I think from my perspective, like, where we're going is because that of that gap, where we're going with this conversation is because of that gap that's been created. Right? We need, we need the system to know what it is, and it doesn't know what it is. Maybe it's just that, that's as simple as we can put it.
Cory: [00:16:31] Yeah. And I think like, yeah, so analytics, FDD come in and I think for the most part, like people thought BMS was probably going to be the last thing that was like ever needed, right? And so that was kind of like - and still is considered a lot of times - like the top tier application in the stack of kind of the controls world.
But then you had, you know, analytics and FDD kind of come into play. And now what you introduce is basically a new application, right? That now is trying to communicate with your BMS application or your BACnet network, and it's trying to come to some sort of understanding of what's all out there, right, in terms of systems and devices. And it doesn't actually really care too much about the devices, only in the sense that the devices are what gives it the information. And FDD is really about understanding, you know, kind of system, system workings. And so this is I think really where, you know, semantic interoperability comes into play, is when you have kind of complex applications that are, or applications that are trying to do more complex things, which are, you know, a lot of times based on the physics and the thermodynamics and things like that, where it becomes really important to know kind of, what the essence of things are, what properties things have, stuff like that.
James: [00:17:51] Cool. Yeah. That helps, that helps me at least understand it. So I want to take us through kind of the history of like, we had that gap and now there's been several efforts to close that gap. And they've been happening over the last many years up until today where you're helping to work on this ASHRAE 223 project.
So I think a good way to maybe frame this progression is to put it in the context of a single sensor. So I think the example I always like to use is a discharge air temperature sensor for an air handler. So maybe we could start like, with that in mind, start with BACnet. So how does BACnet handle and communicate the essence of a discharge air temperature sensor to other devices?
Cory: [00:18:43] Sure. Yeah. So in general, in BACnet world, a discharge air temperature sensor, is just an analog input, right? So, I have, you know, a sensor out in the field. I wire back 0 to 10 volt or 4 to 20 milliamp or whatever to my controller, and that is basically, you know, just doing analog to digital conversion, right? So it's reading a value and converting it into something digital. So then what happens, you know, you have a controls engineer who kind of knows where this sensor landed and this, I think, you know, just to be clear, this part will never really go away. This will always be part of the process, right? Because you will always have to like at some point map physical world to digital world, and you know, wiring that back. Right? So now I know, you know, that this temperature sensor landed on port four or whatever, input four.
So then, you know, a controls person, they go in and they say, you know, they provide a name, right? And this is where BAS naming conventions come into play. We won't really go into that except to say that, you know, they haven't worked and they are all over the place. And-
James: [00:19:57] Everybody names their temperature differently, right? It could be SUP air temp, supply air temp, discharge air temp, DAT, DIS AT you know, everything. Right?
Cory: [00:20:07] Yup. Exactly. And so, so, you know, we get a name, there's a description field. Probably nobody fills it out. We assign units to it. So we might say that this is degrees Fahrenheit. And we know that it's an analog input, right?
So in general, you can use these, you know, your name, what type of input or what type of a thing it is, so analog input, binary input, whatever, and units to, you know, kind of help you, right? But this is, this is really lacking. Right? So I might just know that it's degrees Fahrenheit, which likely tells me that it's measuring a temperature property, but I don't really know like where that is, right ?
James: [00:20:48] So I could comply with BACnet, fully comply with BACnet and really provide nothing more than just degrees Fahrenheit from my little sensor?
Cory: [00:20:57] I think you have to provide a name, and you know, there's like some object ID, like device ID or something like that.
James: [00:21:02] But I've seen names that are just like AI4, right, which provide nothing.
Cory: [00:21:08] Totally. Bob, Fred, whatever. James. That could be the name of something. Totally. That's legal.
James: [00:21:16] So I think that the context here would be like, if that's how say an air handler is set up, right, and it can communicate with say its supervisory network or other, you know, devices on that BACnet network, totally fine with BACnet, right. But then there still would be no meaning passed along that network with the way BACnet is set up right now.
So let's kind of add in, okay so what I see-, the way I understand it, at least is then Haystack comes along, right? So they say, let's close this gap, and I want to kind of group in version one, two, and three. So what do those add to this discharge air temperature sensor for us?
Cory: [00:22:05] Yeah. Sure. So let's say up through Haystack 3, right, we just utilize the concept of a data dictionary, and so that is basically all coming to agreement on what are the words that people will use, right? So it kind of like levels the playing field a little bit.
So the classic example is, you know, supply and discharge are, you know, synonymous and people use them. So Haystack takes a stance. We're not gonna use supply. We're just gonna use discharge. So say discharge, right? That is the word. Don't use supply. Okay. So, and it, you know, it says that if we're going to keep the discharge air temp sensor going, right, then we basically, we have those four words, discharge air temp sensor, and then point. Right? And those are, you know, five, let's say valid definitions in the Haystack like data dictionary. So it does the first thing in terms of, you know, you and I are coming to the table and at least talking the same or using the same words.
And then the other thing that Haystack 3 kind of, and I don't know where in the progression of Haystack 1, 2, or 3 this happened, but they added an API, which, an API specification, right? So standardizing operations for getting data in, or writing data into a Haystack server. So, so what's-, I think we'll probably mainly not worry about the API. I think the important thing that I just want to convey there is that Haystack was designed to solve kind of multiple issues and it kind of lumps these all together into Haystack. But it, it solves kind of the data-, it intended to solve somewhat of the data modeling issue, and data access issue. So, yeah.
James: [00:23:53] Okay. So what are-, what about the concept of tags? So if I've never heard the word tag before , those are basically, those dictionary terms are themselves tags that get added to data. And that's the same thing as metadata, right?
Cory: [00:24:08] Yeah. And I'll say one thing real quick with respect to tags is that, and this'll lead us into Brick as well, but you have two kind of different types of tags in Haystack. You have tags, which are typing tags. So, and these are what Haystack calls marker tags. So these tags are intended to provide a typing definition to what it is that they represent. So typing can be kind of confusing, but generally just think about it as, if I have like an entity and I want to describe that entity, I might use discharge, right? And discharge is a marker tag that says, this thing is a discharge. Now in Haystack, you don't really use just a single tag.
And this is where Brick kind of comes in and they say, look, like nobody wants to talk about single tags. They want to talk about tag sets or really, you know, concepts. And, you know, if I were just to describe something that is a discharge tag, that doesn't really make sense. It doesn't help me. So now I have, you know, a tag set in Haystack, which would be a discharge air temp sensor point, which kind of provides like a full typing definition to this thing. Right? And that is a tag set that actually conveys like a legitimate concept, you know, that we would then have an understanding of. And so that's, that's the talk about marker tags.
And then the other thing that Haystack does is kind of these metadata tags, which just, they're not typing, they're just providing kind of like some additional metadata. So it, it, you know, it tells me maybe the unit, that's kind of some additional metadata. It might tell me, like I put a geo state on a site entity that tells me, you know, where this site is located. Right? But it doesn't tell me that the type of this thing is a site. So those are also two kind of, I think, important distinctions in Haystack, is that you have typing tags and you also have additional kind of metadata tags.
James: [00:26:12] Okay. And where do reference tags come into play? Cause that's where the modeling, I guess in my mind, the modeling concept is handled through references.
Cory: [00:26:22] Yeah. So, so references are, you know, kind of pointers between two entities. So, and I'll just say if people aren't super familiar, entity is just like this very generic something. So anything in Haystack is like an entity. And it's just, you know, this kind of free something. We provide typing tags to inform what this something is, right? So, and then we provide reference tags to basically help define relationships between two somethings, basically. So a classic example is I want to, you know, say that this, like a VAV box is connected to an air handler. So I put an AHU ref tag onto a VAV box and I point it upstream kind of to the air handler entity that is feeding this thing. So that's kind of where, where ref tags come into play.
James: [00:27:16] Yeah. So if we take it back to that DAT sensor that's kind of lost in the world. So if we, if we do Haystack 3 perfectly, what do we now know about? Or what can we communicate to each other about that DAT sensor?
Cory: [00:27:33] Yeah. So, and I think this is kind of an important aspect. So you and I could definitely communicate discharge air temp sensor point. We understand that concept, and that conveys like a full meaning to us. And then we would also use like an equip ref tag on that point to say, you know, that this belongs to this air handler.
So I know basically kind of the type of that thing, I also know what it's kind of connected to,
James: [00:28:02] Say we were on a campus though. We would also know like, we'd have site refs, and maybe even more metadata around like what building that sits in. Maybe, maybe we'd know, like, depending on the user of the Haystack tags, we would know, like maybe we would even know what floor or like what like group of zones, like things like that can be added, right? If I want to, to kind of provide more tag-based context around that DAT sensor. Right?
Cory: [00:28:31] Yep.
James: [00:28:32] Cool. So, I mean, that helps. Right? So that allows someone that is setting up something like an analytics platform to quickly and easily understand the context of all the data in the building. Right? So that's, I mean, I think one thing to note is that as we talk about all this different progression, we're big fans of everything that's happened so far. Right? We're not, we're not trying to bash any one project. So given like where we are with this DAT sensor, the way I understand it is that at some point, the guys from Brick came along and they basically said that, Hey, wait, like that's not good enough. And so can you kind of explain what they were basically saying?
Cory: [00:29:13] Yeah. So this, this goes back to kind of this application level interoperability. And so if we think about a data dictionary, you and I can have like a conversation, but there's no, in Haystack 3 it was just, you know, if you go to their tags page, right, it's just a list of like 50 or a hundred tags and a definition next to it. And so every time let's say a human had to kind of go, you still had a human in the loop, type process. So it was a human going to the Haystack website, kind of interpreting what an individual tag meant. Now there were some examples of like what tag sets together, like you, you know, typical tag sets on an air handler or a VAV box or something like that, but it was still kind of a highly human in the loop process. And part of that had to do with what we'll get into as like a taxonomy. So Haystack didn't really have a taxonomy or like an ontology in Haystack 3. And what a taxonomy does, it's basically, it provides like formal, like more formalized definitions for subtyping , and kind of providing categories and subcategories to the data that we're talking about.
So, in Haystack, you know, there was this kind of convention that, you know, there were three main types of things: a site, an equip, and a point, and these were, you know, kind of more specific types of things. But there was nothing really formal to say that; there was no like machine readable way to say that. So Brick came along and said, okay, like we need to define this in a more formal structure. And they use semantic web technologies, which kind of consists of RDF OWL, RDF SPARQL. Maybe you hear these words every once in a while, but these are kind of just like the grouping of what they call semantic web technologies.
And so they say, okay, let's, let's use this technology to do this kind of typing system, and like a formal typing system. So now I have a top level thing that's called a point. And, you know, a sensor point is a direct subclass of a point, right? It is a more specific type of point and more specifically, it is something that is kind of being read in from a sensor, whether that's like a digital or something sensor, right. And then they say, okay, a temperature sensor is an even more specific type of sensor point. And it is something that, you know, specifically measures the temperature property of something else. Right. And then, and they also, you know, now I have air temperature sensor, which I know is measuring, it's measuring the temperature property of the air substance. And then I have a discharge air temperature sensor, right. Which is measuring the air substance, the temperature property of the air substance located in the discharge basically.
Now, now this you could do with Haystack, but it was Haystack 3, but it was still informal. So that's kind of where Brick comes along is like, let's just have some more specific categories and we can, you know, use just a class oriented, you know, sub-classing mechanism to more narrowly define what something is.
James: [00:32:41] That formality word I feel like is important to me. Cause the way I understand it, is they came along and said, this is not machine readable. Like the way that Haystack is being done, two different machines would get two different answers. Right?
Cory: [00:32:55] Yeah. And, and there still is this human in the loop problem , right? So in Haystack it was kind of going in and, and say, you know, I have to apply this entire tag set to type this thing as a discharge air temperature sensor point, okay. Now there is still in Brick, right? Somebody still has to go in and say that this thing is a discharge air temperature sensor. That, I would say doesn't really-, you know, at this point there's still that effort that needs to happen. And so that's, I guess just a point to make, but it does provide more formality in terms of how can you like understand the essence of something by looking like up the tree, right? And so-
James: [00:33:44] And the tree is the taxonomy, right?
Cory: [00:33:46] And the, and the tree is a taxonomy. So we might think of like felions as, you know, a category, which is a sub category of mammals. And, you know, there's then more specific types of cats, right, and these more specific types of cats, you know, get even more specific, and whatever, we have house cats. And so it just provides this structure originally.
And then, so the other problem that they basically wanted to address, is defining kind of legitimate relationships between things of different types. So now we have kind of within more specific categories and subcategories, but how do I relate to things that are kind of, of different categories? So like a bunny is the prey of like a coyote, right? Or, you know, those end up in two different, you know, bottom levels of the tree, but there's still some sort of like kind of relationship between them. And so this is where, like the ontology kind of comes into play and you say, you know, you define legitimate relationships between different types of things.
And I think one of the biggest grievances that Brick had, and I know as like a user starting off that, so it was very difficult for me to understand what type of relationship they should use to reference certain things. So certain things were easy, like a point related to a piece of equipment, it's always an equip ref, you know. But then you use something like a fan located in it , in the discharge duct of an air handling unit. And now a fan equip refs to an equipment, to an air handler. Now those are two very distinct types of relationships, right? So it's , you know, it's a thing it's contained by, or is a part of, I guess, is what Brick uses. And this other thing is a point of this thing. So Brick kind of said like, let's have more relationships, and define these more formally in a sense.
James: [00:35:38] Yeah. And I've had the same thing where you're using, if you're using Haystack 3, you're using the same tag to mean different stuff. And that's where you start to confuse a computer. You know, a human would notice the difference between an equip ref. when you, when they look at a VAV or an air handler, or where a fan is in an air handler, but the machine is like, you just used the same tag to mean two different things.
So, okay. So as we kind of keep kind of moving down this progression of where we've come, so the way I understand it then is the Haystack guys basically said, okay, I hear you Brick. And so then they created Haystack 4, is that how things happened?
Cory: [00:36:18] Yeah, my understanding, yeah. I know that there was kind of a lot of conversations between Brian Frank and Gabe and like, you know, how do we transition forward? And I know, I would say that Haystack 4 is like, you know, still like an in-progress kind of effort. So they're on like, you know, pre-released like 3.9.8, right. So they're just trying to get this better and better and addressing more aspects. And I would say that, so let's say Haystack is kind of moving to this more type-oriented system, defining, you know, subclasses and things like that.
And in general, if you look at kind of where Brick and Haystack 4 are right now, like their equipment hierarchy looks very similar, for, you know, most of what those, the equipment that is there. But you then look at the point typing system, and it's like very different. And, you know, I basically have a top level point and then, in Haystack, and then I have a cur point, and a his point, and a write point, or something like that. These are subclasses of points. but it's very different than Brick, which basically says that-, well, we talked about this before, so I won't go into it. Right? But that's just to say, and I don't necessarily know who's right, or what the right way to go about it is.
And I think that, and I think this is a distinction. Because, you know, some things in Haystack don't really map cleanly because they, they weren't really-, Haystack was designed to solve different problems than I think what Brick and 223 are actually going after. So Brick and 223 are really going after the ontology issue, which is only actually part of what Haystack addresses. So Brick and 223 are basically trying to say like, How do we talk about systems and what sort of things do we need to talk about? And Haystack, you know, it does that for the most part kind of, but it also goes into, you know, how do you get, you know, other metadata info from this? How do you get time series data out of this thing? Right? And, and that, I think just goes with, you know, where these are at, or what they originally intended to solve. And Haystack wanted to kind of provide like a one stop shop solution to all of this stuff. And Brick and 223, I think are more like, let's solve the ontology issue first, and then we can go after data access and stuff.
James: [00:38:49] Okay. Interesting. So, so 223, if we just kind of continue in the very generalized, probably not that accurate story that I've been telling here, is then Haystack 4 came out and at some point ASHRAE sort of decided they were going to bring all this together into one effort. And so is Haystack and Brick, they're both on the 223 committee. Who else is on that committee, and how does that, what, like what's their, their goal and timeframe and all that? And what's the status of it?
Cory: [00:39:21] Yeah. Good question. So what is now the SI, semantic interoperability, working group, as part of ASHRAE 135 committee, I'm still trying to understand like all the SSPCs and SPCs and things like that in ASHRAE, but we have that. So that originally, the Semantic Interoperability working group started off actually as the Application Profiles working group. And that had been going on as I understand it for maybe like 10 years, and they were trying to do something similar. And so then yeah, Brick and Haystack and 223, want to work together. And so recently I think just this year, Steven Bushby took over as kind of the head convener of the semantic interoperability working group. It got like a rebranding kind of, and is going through kind of like modifying the title, purpose, and scope for it. But it's gotten a lot of people kind of to the table. And these are people from like NIST, universities, national labs, and DOE has kind of been, you know, seeing that this is kind of an issue and wants to, you know, help address it. So, and then you have, you know, industry folks as well. And so I think, yeah, so, so that's kind of like who's on the committee.
If you look at the timeline, I'm not really too sure about the timeline. I'm assuming that it's going to be something like three to five years before a standard comes out, but-
James: [00:40:50] Which is surprising to me, right? Because this group was announced in like 2018. So it's already been like-, before talking to you and like, I didn't know, like, is this close to being done? Like, it sounds like it's not converged on solution. You guys are still working through, like you said, starting with ontology and then you move on after that.
Cory: [00:41:13] Yep. Yeah, I would agree with that. So it's-, and I would say that, you know, 223 is actually, you know, asking some really tough questions. And I think that, you know, there are some very smart people in there. So people who like are like information architects either like by learning or training or whatever, right. But people who like actually do this as a job. This to me, like I'm trying to learn how to do it, right. So, but you have Joel Bender who is, you know, kind of trying to identify gaps in like both Brick and Haystack and kind of what 223 it needs to be. And I think that it's, it's actually a really good exercise because, it's trying to start, I wouldn't say fresh, but it's trying to, you know, evaluate things through a new lens.
And, you know, Brick kind of started with Haystack terms and tags and kind of, let's say reorganized it a little bit. 223 is going into, you know, let's break down like a piece of equipment, right? So we're going through this exercise where we're just looking at, you know, ASHRAE Guideline 36 systems and breaking it down into all of its constituent pieces. And what kinds of relationships and systems and components do we need to kind of consider, right? And so a classic example right now is, Brick and Haystack had no kind of concept of connections or, you know, the directionality between things, besides like maybe feeds or something like that. But within like an air handling unit, right, I might define, I have a heating coil, a cooling coil or whatever. And there was no way to basically say like what the order of these things are, right? And what kind of, you know, substances are kind of like flowing between these things. And so Joel, you know, there' s-, in 223 it's really about trying to bring together the best of a lot of different ontologies and say, this is how you can, like they can work together.
So there's this other ontology called SAREF which, you know, has the concept of connections, connection, points, and systems. And so it's kind of marrying, you know, SAREF with these different connections and basically, you know, defining ports, right? So a connection might have multiple connection points and defining like legitimate, you know, inputs and outputs to these connection points. So if I have a heating coil, like a hot water coil, right, that might have an air inlet and outlet, but it also has like water inlet and an outlet, right? And so it's pretty interesting because it's getting down to like, how do we model very, very detailed things? And, and then, and the other question is like, at what detail do we need to model it? Right now to me, it looks a lot like something like an EnergyPlus or OpenStudio, where, you know, they did have to solve this kind of issue a long time ago. You know, how do we-, because you have to have full fidelity of like an energy model, right? So you have to know flows, you have to know inputs, outputs, like exactly, right? I can't not know that. So it's pretty interesting because it, it, it does look to me a lot like it is going to somewhat line up with what, you know, we would think of as like a building energy model might look like.
James: [00:44:33] Okay, well I think that's a fascinating kind of, you know, we kind of just fast forwarded through like 10 plus years of semantic interoperability history, but I wanted to do it because this isn't a solved problem. And it's also a really big problem. Right? So it's not as easy as just adding tags and hoping the problem is solved. Right? And I think it's good to like tell that story because I think there is a myth in at least the, the kind of circles that I've come from, which is if I'm using Haystack, for instance, or, you know, even, or Brick, right? But mostly it's Haystacks more popular in the private sector, right. It's, it's, it's a lot more widely distributed. It's a lot more, it has been, you know, people are making Haystack their standard, right? And they're, they're more often in buildings right now. So I think there's this sort of myth, right, that if I add Haystack tags to a building, then now it's set up for whatever you want to do. And it's now interoperable, right? So how would you sort of respond to that assessment? I mean, we've, we've touched on it a little bit, but I think we should just kind of directly talk about it pretty quickly here.
Cory: [00:45:48] So, sorry. Say the question just one more time.
James: [00:45:51] Yeah. So like, I think there's a myth around, if you just sort of, and one of my buddies likes to use the word, if you just sprinkle Haystack tags, then the interoperability problem is solved, right? And this kind of gets at this whole kind of trend towards open data layer or data lakes, where there's people out there that are basically saying, but, you know, just get your data into a database and get it Haystack tagged, and now you're ready to do whatever you want with it, right. So how would you sort of respond to that besides laughing?
Cory: [00:46:27] Yeah. So I would say, like the reason that this whole ontology question comes into play is that, that might work for certain applications. And this is where, you know, if we talk about the smart building space, the smart building space is growing very fast, right? And we can talk about this all the way from, you know, doing simple rules-based fault detection and diagnostics, and starting, you know, with a lot of this stuff that Steve Bushby worked around on 15 years ago with these air handling performance assessment rules, right? I'm just comparing supply air temperature and mixed air temperature. And based on a mode, right, I can say that a fault has occurred. Now, that is a very-, that's at one end of the spectrum. The other end is that now, if you're looking at kind of grid interoperable buildings or grid efficient buildings, and you're looking at model predictive control, you need to have like a very, very, very detailed picture what your system is, and what is contained in it, and its relationships. And even how the, you know, the thermodynamics and stuff work. And those are, those are very two different views that you have to take of the world.
And so what 223 is kind of doing, it's like, what is the most detailed view that we can take? And if we take that, how, what are the things that we need to talk about, and how can we talk about it in an abstract manner? Whereas-
James: [00:47:52] I think what you're saying is like use cases, that there's many different use cases for the same data, right? So just because someone tags a data set for their use case doesn't mean it then enables every smart building use case that could possibly use that data, right?
Cory: [00:48:11] Exactly. Yeah. And so you have different applications that actually need different things, right? So one application, and this is like, you know, there's no concept of Haystack like compliance or verification right now, because it's kind of like you use the dictionary terms to basically identify the things that you need to identify. And primarily this is for, you know, let's say a monitoring based commissioning firm, or, you know, some sort of firm who's selling SaaS, you know, to implement their solution. They're not really looking at, you know, who might the next player down the line be, who might want to consume this and what might they need from a data perspective, and what aspects of the model do they actually need to know about?
And so, so this is where it kind of, if we're talking about application to application interoperability, you have to take like the same viewpoint on modeling something so that you can kind of both, both of your applications could get the data that they need to, to run whatever they need to run, basically.
James: [00:49:18] Yeah. And right now the standards aren't extensive enough. Maybe that's not the right term, but we've kind of covered it. They're not at a place where they have a standardized way to add all of this metadata, basically that would then fully describe a, say a discharge air temperature sensor for every application that could use it.
And so I think what I've experienced is you might have two companies that are trying to use Haystack, for instance, and they've gotten to the limits of the Haystack standard, and then they've then added onto it, right. So they've used Haystack up to a point, and then now they've added Haystack-ish sorts of tags. And so now we have basically n plus one standards. And then you have the next company that's doing Haystack, and then they got Haystack-ish, and their Haystack-ish is different than the other company's Haystack-ish. And so now what we have is like basically, we have a world where then the humans can probably understand it, but the machines couldn't, if you wanted to plug two different applications into that tagged dataset.
Cool. So that's a good summary of the, what I see as the two main challenges. So let's talk about opportunities. So what are the kind of the big opportunities for kind of making interoperability more, more streamlined, easier to do, and more heavily promoted in the industry today?
Cory: [00:50:48] Yeah. You know, I think, I think a big aspect of that is just proving out or like having two kind of vendors come together and say like, look, we're going to prove, you know, not just that we can exchange Haystack data over like an API, but that, you know, we can both kind of like round trip, you know, fully round trip through our tools, and come to the same conclusion like about, you know, what this system is. And we agree on the necessary components that we need to model in order to do that. And it's, you know, and, and that's kind of, to me, a big aspect of it that I think hasn't really been done super well.
I think one of the reasons it hasn't been done super well is there hasn't really been like a third party spec that basically says, you know, like when we say a package rooftop unit with single-stage DX cooling and gas furnace, you know, heating, this is exactly what your model needs to look like. There's nothing out there that says that. There's kind of maybe some like examples, but there's nothing saying like, this is how to do that system. And so I think that's an opportunity, is to kind of look at what are the most common system, you know, a few of the most, five to 10 of the most common system types out there, come to an agreement on basically how those should be modeled and kind of prove round tripping, you know, through multiple vendor systems to do that.
So I think that's definitely like, from an interoperability perspective, especially in the semantic aspect, that is I think the opportunity. It's also, you know, the hardest, in terms of like, we have to have two vendors who are kind of gonna take this on. You know, I think if two vendors took this on, it becomes easier for other people to get in on the game.
And you kind of-, it might not be, you know, a hundred percent like, perfect in the sense that I think 223 is like trying to work towards, but maybe it gets us kind of 90% of the way there for a few different system types that we generally see. So I think that's one big opportunity.
And with that, like, I think comes the opportunity to also have basically reference implementations, right? So a big ask is on the Haystack forums, you'll see this, it's like where can I-, like do people have sample data that I can look at? There's not really much out there. There's a few sample buildings generally with simple systems , but we don't really have good reference implementations for doing, you know, more complex systems. I liken this to kind of having the DOE prototype buildings from an energy modeling perspective, which is like, look, we're just going to define like a very generic, small office building and say, you know, this is the system type, and this is like what it looks like. I think we can kind of do that, in the same way for Haystack as well. So putting those out there so that people can go in, look at examples. I mean, I'm a very example- oriented learner. So it's, it's very easy for me to go see something, and okay, now it makes a lot more sense. Seeing a list of tags and, you know, and these scattered forum posts that you have to maybe try to, you know, work through to kind of come to a conclusion about how something should be done. I'm sure you can do that, but it would be nice if we just had like a best practice type book. So I think that that's definitely an opportunity as well.
And along with that is kind of like some tooling. So having some vendor tooling, you know, to help people do these systems more consistently, right. We still, you still probably want to use it or to interface with something that is very simple. You know, you want to abstract away tags probably in the data model that goes underneath it, but providing them with some sort of forms or whatever that, you know, just enter in this information quickly. You know, don't worry about the data model that all happens in the backend and, you know, you're good to go. So, you know, I think tooling around this is really important and that's something that, you know, will push I think, vendors, to, to improve tooling, to help with that.
James: [00:55:04] Yeah. And do you think that would be on-, like I know SkySpark is definitely building out tooling in their latest releases. So you think that would be a vendor thing or it would be a vendor agnostic sort of set of tools?
Cory: [00:55:16] Yeah. I mean, I think you could go both ways. It definitely seems like there is like a cry out there for, you know, some sort of open source Haystack builder type of thing.
James: [00:55:30] Yeah.
Cory: [00:55:30] Brick is maybe like a little bit easier because it, it uses, it builds on the semantic web technologies. So there are, you know, in Python, things like that, you know, typical RDF tool sets, and standard ways of kind of constructing these. So not, you know, not that everybody's going to go in Python and build RDF graphs or whatever, but it is available for people if they want to get their hands dirty.
One of the things with Haystack is that it can be difficult because the ibraries that maybe are available on the Project Haystack website, you know, different programming language libraries, they cover very different aspects of Haystack. Some of them just implement kind of the API spec. Some of them have incorporations of the Haystack data model. Some of them have incorporations of like the Haystack literals and actual like data types that, so there's kind of a wide spread, and it's, and they're not consistent.
And so anyways, I do think that there is kind of a cry in the industry to have some sort of open, you know, third party Haystack builder type thing, so.
James: [00:56:39] Yeah. Okay. Alright. Cool. I mean, those are three great projects. How should listeners get involved in something in this area if they're interested?
Cory: [00:56:49] Yeah, I mean, likely people might hear this conversation. You know, I don't think anybody is just building like Haystack things for the fun of it or Brick things or whatever, right. So probably people have products and probably all of these different products have different use cases or applications or similar ones or whatever.
When you talk about kind of like application level interoperability and the importance of semantic models, it's really good to get like all of these perspectives involved, because you know what one application needs and what they talk about it as, might not be the same as another one. And so getting these people kind of in the same room together, becomes really useful to, you know, just have the conversation. And I think that's kind of where 223 has done a really good job. Steve Bushby kind of sets this really good tone, like invitational tone, for, you know, getting people involved and hearing different perspectives and stuff. And so, you know, I think, you know, that the 223 group is a good place.
You know, the Haystack forums as well. Generally there's not a ton of people who I would say participate in the Haystack forums, right. It's kind of easy to do like a one off like question, like I have a, I need a quick answer, but, you know, to really dedicate time to try to propose like a thoughtful solution to some of these problems that we face in a way that becomes, you know, usable for others down the road, right. It's not just like one person solving it in their application. It's, you know, how do I take the experiences that I've had in the field in implementing Haystack, translate those into, you know, present the, present the use case, present the scenario to the group and, you know, contribute back. And so I, I think that's would be like super helpful. You know, we would, I think love to have more people contributing in that space and kind of working towards a kind of common goals, so.
James: [00:58:41] Got it. Alright. I think that's a good place to drop off for now, but I'm sure this conversation will continue as things progress in this area. So thanks, Cory, for coming on the show. Really appreciate it.
Cory: [00:58:53] Yeah. Cheers man. Thanks for having me.
James: [00:58:55] Alright, friends. Thanks for listening to this episode of the Nexus podcast. For more episodes like this and to get the weekly Nexus newsletter, please subscribe at nexus.substack.com. You can find the show notes for this conversation there as well. As always, please reach out on LinkedIn with any thoughts on this episode.
I'd love to hear from you. Have a great day.
Head over to Nexus Connect and see what’s new in the community. Don’t forget to check out the latest member-only events.
Go to Nexus ConnectJoin Nexus Pro and get full access including invite-only member gatherings, access to the community chatroom Nexus Connect, networking opportunities, and deep dive essays.
Sign Up
Nexus Labs exists to move the smart buildings industry forward, without the fluff.
On Wednesday, we send out the renowned (and free) Nexus Newsletter.