A discussion of Building Automation Interoperability Issues and Approaches with a Focus on Project Haystack. Semantics, data modeling and a broad variety of applications are examined.
--------------------------------------------------------------------------
Would you like to be a guest on our growing podcast?
If you have an intriguing, thought provoking topic you'd like to discuss on our podcast, please contact our host Jim Frazer
View all the episodes here: https://thesustainabilitypodcast.buzzsprout.com
A discussion of Building Automation Interoperability Issues and Approaches with a Focus on Project Haystack. Semantics, data modeling and a broad variety of applications are examined.
--------------------------------------------------------------------------
Would you like to be a guest on our growing podcast?
If you have an intriguing, thought provoking topic you'd like to discuss on our podcast, please contact our host Jim Frazer
View all the episodes here: https://thesustainabilitypodcast.buzzsprout.com
Hello everybody, and welcome to the Arc smart cities podcast. I'm Larry O'Brien, vice president of research at Arc and member of the smart cities team. I have with me here today, Jim Frazer of Arc,
Jim Frazer:Thanks Larry. Good morning. I'm the vice president of smart cities and intelligent infrastructure here at Arc and today we're very happy to welcome John Petze of Project Haystack as our guest today.
John Petze:Thanks. Glad to be here. Really appreciate the opportunity to talk to you guys about what's happening with the Project Haystack initiative. So, looking forward to it.
Larry O'Brien:So, John, can you start off by telling us a little bit about your role at sky Foundry, and then maybe jump into what you're doing at Project Haystack and what is Project Haystack?
John Petze:Sure, I'd be glad to. So yeah, my day job, that pays the bills is I'm a co founder and partner in a company called Sky Fo undry a nd we're a software company- we make an alytics s oftware for the built environment, a nd th e IOT, Our software products are called Sky Spark. And it's a platform that, pu l ls data in from diverse sources, whether it be streaming live data or, dat a from databases or files or from websites. It i nc ludes performance analytics, on t h at data to identify patterns and pat ter ns that might represent an outright fault, but a lso a trend, a trend that's predictive of a futur e problem, anomalies, patterns, correlations, et cetera. In Project Haystack, which i s an open source initiative started back in 2011, I am the executive director and am on the board of directors.
Larry O'Brien:Okay. so what's the idea behind Project Haystack? I mean, I've done some reading. What, I'm willing to bet that may be ma ny of our listeners aren't familiar with Project Haystack yet, but I think the real purpose behind Project Haystack is to kind of make sense out of all the data that's coming from these millions of smart sensors that we have, i n building control applications and smart city applications with the, onslaught of, of IOT technology and lots and lots of cheap, inte lligent sen sors. We need some way to make sense of all this data. Right?
John Petze:Yeah. And I think you, you captured the most fundamental goal of Haystack. It's to make sense of the data, right? So we've got, we're watching data, right? We have data coming from all different types of existing systems and a huge volume of new devices. But the challenge is, and there's two challenges, one, and I think people may understand it more because it's been talked about longer, is they talk different protocols. And there's been efforts with standard protocols and there are many standards and many is the problem, right? There's lots of different steps- and that's not going to change. There are reasons for them beyond the commercial battles. There are actual reasons you need different protocols to do different things. So we have to accept that fact, right? And I think by and large you can buy gateways, to integrate any protocol that's out there now. So that's no longer the big barrier. The real barrier is that the data has poor semantic modeling or descriptors, right? So even if I can get the data out of your system because you support one of the open standards when I get it to, I know what it means, right? Well, maybe if I was involved with implementing the system, I know, Oh, this, name means this and this name means this and this value means this. But how do I do that in a way that is, normalized, repetitive and easy for anybody? So it's ki nd o f, in some ways I'll make some analogies to day. One might be, do y ou remember what we used to have to do to set up a printer? Now that's pl ug a n d p lay, right? There wa s s ome standards around per how each printer announced themselves, what attributes they have. They had pretty much plug and play. Right. That's one analogy I've made. I'll make one other analogy. Y ou k ind o f get us started here is you guys have a website. I've visited your website, and magically I was able to read the text on your website and you know what? You and I, we didn't get our engineers together ahead of time, right? To do any coordination. Why can I read your website? Well, because long, long ago in a galaxy far away, right? The industry said, Hey, we've got to have a standard mark up language so that we can put descriptors on our te xt s o that when I pull up my browser, I can read what you wanted, what yo u p ublished in the way you want. Right. Without HTML, where would we do, well in a way, conceptually Haystack is virtually the same thing, but for the data that comes out of devices, systems, whether it be control systems, metering systems, occupancy sensors, infrared, so me, any type, we need a markup language so that when I get the data over whatever protocol, there's some way to interpret what is this? Is it a, is this value KW demand? Is it degrees Fahrenheit, is it kiloPascals and that's kind of like one of the most basic things. when I talk about Haystack, one of the things I kind of ch allenged p eople with is, numbers have no meaning without units. An d L arry, I'm going to give you a hundred
Larry O'Brien:Exactly, a hundred what?
John Petze:A hundred a hundred lashes,$100 on one of the units. Right. And I think people overlook this because if you're working with a system that you implemented or you work with day by day, those things are in there, right there on the screen or whatever. And I want to pull the data out of the room
Larry O'Brien:And there in lies the problem. We have a bunch of proprietary systems. They all have kind of their own unique way of feeding up with serving up data and expressing data.
John Petze:Expressing it, storing it, pinging it, et cetera. Okay. So that's the problem. Right? And so what happens? Well, the situation is if I want to get the data from all these different systems that represented in different ways, if they represented at all, by the way, right. I'm going to encounter an extensive manual labor intensive process where I'm going to map it down. I'm going to say, Hey, Larry, what's this name about the, what's this sensor name mean? Oh, yeah, yeah. That's that. that's outside air temperature. Okay. What are the units? Okay, thanks. I wrote it down. Right. And we're going to go through hundreds, thousands, hundreds of thousands of sensor points.
Larry O'Brien:Yep. That can lead to a pretty costly integration project.
John Petze:Exactly. And in fact, I got a great, example for you on that. We in our commercial role where we make software that consumes data from different systems and doing, been very fortunate with it and we got involved in a number of great projects and there was a consulting engineering firm who was involved in specifying these projects. And, after a couple of projects and they kind of specialize in this for the owners. They contacted a number of system integrators who bid projects and they said, hey, we want you to help us with an exercise. I'm going to give you a sample project. I want you to give me a, a budget price, but I want you to break it down. Where the heck is this money going? Right. And they said that in quotes on a sample job, 50 to 70% of the engineering line item was doing this data wrangling data mapping manually intensive process.
Larry O'Brien:I can totally believe that. I mean I come out of the world of the process control, moved into smart cities and building controls about three years ago and, a nd process control, it was even worse. 75% of the cost of a project could be tied up into custom integration from t he software perspective. Yeah, no question.
Jim Frazer:Well guys, I'll jump in there because I come to this from the transportation domain and the USDOT decades ago, recognized that that exact cost was an order of magnitude larger than the acquisition cost of the hardware, software and actual physical installation. So, they have a set of very strict interoperability standards for all the 18 subsystems that go out on roads today.
John Petze:That's a great point because there was a governmental agency that was able to force that. So if I want to sell traffic systems, I will comply and it's over and it's done with, and with my example of HTML, it wasn't governmental, it was enough. People at the beginning of the web said, we get to solve this problem. But unfortunately, all of us on the call today are involved in control and automation that emerged with microprocessors in the 70s and primitive proprietary field buses, this and that, and it's a mess, right? And the systems are installed. So what do we do about this? Okay, so the first thing, I would say the first era of interoperability with a standard protocols, right? And we never got one. We have more than we ever had. And so the next era was, well, gateways and manufacturers opening up their products or their protocols. So gateways could be effective Now we can get the data and that delivers us right to where we are today, which is really the entry of the data age, which is, I can get the data, I don't know what it means, right? So data is exploding among us, all right. So how are we gonna solve this? All right. So in 2011, o f a number of us who were facing this in our daily life got together and we started working on a solution, right? For our own product. We did that and we came up with modeling and we l ooked to research a nd what it was doing i n software industry, the semantic web. And we looked at that and we said, the building systems, th e b uilt en vironment, sensors, equipment, factories, it's a little different than the web, right? so we came up with a model and it made our product work. And then we went on, this is actually not a competitive advantage. This is a fundamental problem that's holding us all back. So we get together and we talked to some people at some of the government energy research labs and everybody was, yeah, this is a problem. We gotta solve this. And we said, well, we think we've got a great approach to this, a methodology to solve it. Let's make it open source. We can join in. And the quick answer we got was, you got to do this. But if we have to go to apply for dollars to get an official project stood up at one of the research labs, we won't get started for a year or two. Just go do it. So in 2011, March of 2011, about 10 of us got together and rented a server and stood it up and we at Skype Foundry who had been dealing with this because of, analytic software has to be able to interpret the meeting of data. We donated everything we had done and put it out on a form and said, come on in, contribute, help us solve this problem, help us extend what we've done, help us model other systems. Right? And that's how it got started. Okay. With the simple goal of we need to make it easier to work with the data from diverse systems. That's the goal. How do you get there? Right? Well you get there a couple of ways right? In the first if you will, generation iteration of Haystack really focused on we need to be able to add descriptors and the whole concept of tagging had been used significantly in the software industry, right. The analogy I make is, I don't know what email client use, but I used to work with a Microsoft outlook and if you want an organize your emails, you had to put them in folders- once you put it in a folder, that's where it was, right? And then you have products like Gmail and the difference was you could add tags. So you could search on beach pictures, you could search on emails from Larry, they weren't in one place. We had descriptors tags that would allow us to organize, query and find stuff however we wanted to. And that's really the model that we took-metadata tech. So the first step, let's create a standard vocabulary. So if I say, this tag is, A HU, that means it is an air handling unit, a piece of equipment that blows air into a space. Okay, we need a standard vocabulary. Again, I, make some analogy to HTML, r ight? There were standard vocabularies of how you're g oing t o call an image in a page and text and bold and all that type of stuff. So that was the first generation is a standard vocabulary. Right. And what that vocabulary with the contribution of the community, we built out a vocabulary that would allow you to put semantic tags on whatever you had so that they could be interpreted by software applications. What type? Well, for us it was analytics. We want to get the data in, know what it is so we can detect, Hey, this is an incorrect value or not a good value for this sensor. Right. My chilled water supply should be, 46 degrees Fahrenheit, not 96 degrees Fahrenheit. Oh, but now I know what it is. So it would streamline whatever people wanted to do with the data. And that was really important. We weren't telling people what to do with the data. We didn't want to make any assumptions or any barriers. If you can suck the data in as semantics, you can do what you want. Now
Larry O'Brien:You can contextualize, you can turn that data into meaningful information. That's one of the things that we're constantly harping on at Arc- data's not enough. Right? Like that example you gave, if you don't know, what you're looking at, you can't determine there's some kind of an anomaly happening with this piece of equipment or, or what have you. So that's, in order to get that good information, you need to have that common context, right?
John Petze:So we get the common vocabulary we agree on this is the tag you're going to use and these are the meanings of it. And that was the first generation Haystack. And I want to follow up one thing to say, I think one of the challenges about this topic is often companies who provide value from data, whether it's through machine learning or AI, whatever, they hide this behind the curtain and maybe not even intentionally so people don't encounter the challenge or the problem. Right. And then on aware of it. And I would guess that's kinda like how most of the world doesn't know why a web browser can read your website either. Right. But
Larry O'Brien:yeah, they don't want to know. Yeah.
John Petze:One of them, I know our industry doesn't want to know. The problem is we're not far enough along that you can hide this, you have to talk about it. Because what we find is there are lots of equipment manufacturers don't actually understand the problem. And if we can bring them into understanding it, maybe they'll implement a semantic model so their data can be used more easily. So we find we're in a major educational phase to help the people who make sensors and devices understand that they need to implement a semantic model. Obviously from the Haystack point of view, we're going to encourage them to do that. But if you have a semantic model that is well thought out and I have one you can in software and make a quick mapping between the two. If you don't have one, it's manual, right?
Larry O'Brien:Yup. It's still like the point integration.
John Petze:Yep. Right. So the other thing we did is we said, this has gotta be open source. People had said, well, why don't you do the classic standards organization? And we said, what, we've been through that I've been through that, participated in, in a couple of standards. One in OASIS another... Ye ah,
Larry O'Brien:I know Jim has been through that.
Jim Frazer:I have!
Larry O'Brien:And that process is not fast nor efficient.
John Petze:Jim- you know how fast moving that is. And we said, what, that's not how the software industry works now to solve these problems. They work in an open source model. S o makes a proposal. People w ho care get in, they critique, they debate, they solve it and it moves much faster.
Larry O'Brien:But I don't want to disparage standards, I mean, standards are needed, standards are good. When I looked at Haystack, my question was, are you guys interfacing with a standards group or is that part of the plan in the future? Or, c ause a lot of these initiatives end up becoming standards, the f acto standards then, honest to God, IEC standards.
John Petze:So to quickly answer and then we'll come back to it. Yes. we are working, so a little bit of preface to answer that question. I think one of the questions we're discussing today is, where is Haystack used and as we describe it, it's for the built environment, the data that comes out of the built environment. Oh, that's factories, that's buildings, th at's s olar installations, that's indoor agriculture, anything, the built environment an d a ll the sensors. Right. historically there's been more take up because of where we started of Haystack in buildings and building controls. But the technology, the methodology, the way you build the vocabulary, the way you build taxonomies is not limited. It works with machine data at any tim e. N ow. Yes. we've had some good progress to work with. One of the major standards organizations in the built environment, which is ASHRAE, the American Society of Heating, Refrigeration, Air-conditioning Engineers that one of the biggest standards organizations and we started a formal process to work with them. It'll be years down the road, likely before Haystack is adopted as a standard. It's a part of the vision. We think it needs to get there. We think before it gets to a prescribed standard, it'll be a de facto standard. In fact, today it really is. And part of the challenge is you can't solve all these problems ahead of time and standards like to do that. Right. with the wire protocol they had to figure it all out ahead of time. But with semantic modeling, society at large and our industry is still figuring out how do we use data, what do we need to do to effectively model it? So it's still open source.
Larry O'Brien:it isn't sort of the things you've mentioned in your paper is we haven't fully realized the promise of the semantic web. Right. Which, I remember reading about the semantic web over 10 years ago,- the promise of that. So these are not easily solvable kind of piecemeal technology problems. Yeah. These, this will be evolving.
John Petze:Our understanding has evolved. So, let's continue on. So we started with the standard vocabulary that allowed people to tag their data and applications. Could this, as we say, just work. Good example. We could suck in tag data into our software and do analytics on it because we know the meaning of the data. Great. And then we saw other people using it. For example, i n S CADA systems you have the graphics of equipment and how much work that usually is. Right? I g o t t o p ick the point, I go t u nderstand what it is. I got the units and I'm going to display it this way. And in m y experience what happened with graphics is more engineering effort goes to building the pretty pictures an d t hen went into the actual control system.
Larry O'Brien:Yeah, you're absolutely right. Yeah, correct. Right, right.
John Petze:But with tag data you can say, Oh, this is an air handler. I know what picture I should grab. This is the returning a sensor, this is the valve and it can auto-generate the graphics dramatically.
Larry O'Brien:I wasn't aware that you went to level. That's really interesting.
John Petze:We have people doing that and it's astonishing the engineering savings. Okay. Because if you were building the graphic manually, you're still pulling the components out of a standard library. Right? I've got a valve, I got a pump, I've got a fan. But if it can read the data, it can say, I know what that is and I can assemble it. And we have people been doing that for a number of years.
Larry O'Brien:That is a tremendous elimination of unnecessary work as other colleagues call it. We need to eliminate unnecessary work.
John Petze:Well let me give you another one. So then people started taking another direction, right? Which is, I've got a control sequence here for a variable speed drive on a pump. Well now with tagging, I can read in the data, know what the PO all the pumps and I can automatically attach the control sequence to them instead of manually have to do it. Dramatic savings in engineering effort.
Larry O'Brien:Yeah. Yeah. Really.
John Petze:this is what it enables. Right? And we'd like to say it enables applications that just work because the application can interpret the data and know what to do. So these are some huge impacts that you get if you adopt a semantic model and then can build applications to interpret it. And that's what we're trying to help the world do. So we, we have the vocabulary and the, and then people sa id, well, is that what Haystack is? And it's actually one part of it. Probably one of the most important things is that it's a standard methodology for a, it's a methodology for how we'll tag data and then it's a standard vocabulary on the tags you will use. But it goes beyond that. It's the community of people who understand this problem and care about it who are out trying to solve this from different perspectives, different equipment. And we've got government energy labs and heavily involved in this, manufacturers, system integrators, consulting engineering firms. They're the ones who ever encountered this problem are actively participating. Right. And some of them did another phase, which was they built software tools. First thing community did said, okay, I've got this model, I need to be able to query it. And so some of the community members built a REST API. Here's how you query Haystack tag data, great. Or how you're writing or how you add tags. So they built a complete API to interact with Haystack tag data and then one was done in Java and then somebody said, well I like C++. So somebody wrote one in C++ and then somebody did Node.js And somebody did Dark and somebody did Python and now all these reference implementations are out there solving the next unnecessary work, which is, Hey, I got an application, it's written in Java, I'd really like it to communicate Haystack. Oh, I can just download the reference implementation at no charge. Do a little bit of glue code in three days. I'm talking. Right. So that's another part of what Haystack is, right? Then really the fourth thing is this. People say, well, it's great John, you guys did a standard tags for, air handlers, chillers, boilers, or whatever. I'm dealing with a solar array and I go, you're not, nobody is in the community is really been a domain expert in a solar array. Learn the methodology and go contribute to that. Create one, create a working group. Yeah. Right. So that was, so we have this model and we have facilities on the projectHaystack.org website to set up a working group and say, Hey, I know a lot about solar systems, lighting systems. Let's get some birds of a feather, take the methodology and build out the vocabulary that will capture all of the semantics for those different systems. So that's another thing. And this brings up an interesting distinction. The difference between open source and standards. We often have people come to us, me, right? John, I need the standard for lighting. Hey Larry, I don't know anything about, well I think, right, we have a methodology, right? But with true standards body standards, there's some team doing it. Who's going to deliver it to you with, with open source, it's the community has to come together to create it. And what we found, and you guys have a lot of background and automation and control and industrial et cetera, is our industry wasn't highly attuned to open source.
Larry O'Brien:And that's an understatement.
John Petze:I'm glad you agree. It isn't about whether you charge for the software, it's about the concept of working together in an open source method to create a solution that will be available to all, it wasn't the lingua franca of how our industries worked. Right. I'm talking about proprietary and that was beat into everybody's head. So we're often educating people, not about the technology, but about here's how it works. You are interested, you post it, you find other people, you go off, you try to solve it, you work on it for a day, a week, a month, a year, you come back, you propose it, that's open source, right? And somebody's going to critique you and find something you missed,? so that's a big part of it. And about the adoption and partly about, the challenge we have, in bringing this to our industries.
Larry O'Brien:Yeah. That kind of peer review can really make things much better.
Jim Frazer:Exactly you need all your stakeholder communities and consensus, whether it's a formal standard or open source.
John Petze:Absolutely. So, yeah,
Larry O'Brien:and this is represented by both owner operators and users and suppliers are participating in this.
John Petze:That's key, right. to have an end user who can chime in with a manufacturer and say, well, oftentimes you have, manufacturers will say, well we have semantics. Yeah, you get five, five pieces a day. Right. It doesn't tell you anything. Relationships with taxonomy or any of this. The other thing I guess it'd be worth mentioning is, one of the things people think at first is, Oh, it's a standard naming convention. And we say, no, that's not right because it's a naming convention can't solve it. A standard naming convention is a great advantage. So you don't have, five different variations of a name, but it didn't solve the problem. And I, and one of the best examples I heard, it didn't come from me, but somebody else who says, I have a name John Petze, that's my name. that didn't tell you about me, where I live, my address, what I drive for a car, what color my hair?. Those are my attributes. Those are my tags. Right? But having a standard naming convention is a good thing, but it doesn't solve the problem. Because if I had to encapsulate everything about you and your name, Larry, it would be what, 64,000. Careful also. So names don't solve it. And this is often part of the education process that people think just standardized naming will solve it or that that's what we're trying to do with Haystack. And we're saying, what, you can't standardize names. T hey're already out there, we'll never make you change your names and your control systems or your se nsor s ystems. You had the tags after, right? The describe it. So you name it whatever you want.
Jim Frazer:So John let me take a stab at this. Project Haystack from, from the software, i nteroperability perspective is a collection of objects that are hiker hierarchically arranged into groups of functional profiles. Each object has its na me, it has a descriptor that tells you what that name really represents. It has engineering units and it may even have a legal range for the actual value.
John Petze:Okay. So thank you for setting me up with that. But Jim, no, no, that's not what it is. Oh, okay. It is the standardized methodology and elements to build what you just,
Jim Frazer:aha. Okay.
John Petze:And that's what's key. For example, we have the vocabulary of the tags, right? We have the vocabulary of the units complete. every unit you can think of how you want to use them up to you. But you mentioned something, objects, it isn't objects, it's the attributes tags you would put on objects to give them meaning that could be interpreted. It also isn't necessarily a formal taxonomy. It is a taxonomy descriptive model so that you can build the taxonomy for your application. Now, there are some standard taxonomies in there, right? But the reality is in the built environment, how your equipment systems, your process is structured, right? The hierarchy that can't be predetermined, right? That's project specific. So I need the facilities in Haystack to be able to define the taxonomy and hierarchy that fits with your application.
Jim Frazer:Well, thanks John. That's very instructive for me. It's very powerful and I'm sure our audience appreciates, that as well. can you comment on, where we're P roject Haystack fits in the OSI interoperability model?
John Petze:Yeah, I'll try. It's really above those, right? It's, and that brings up a example. People say, okay, well we're as Haystack used. How can I use it? All right, so let's, let's start at the ideal. The ideal would be, I'm a manufacturer. I make a sensor. If you talk to my sensor, it's just a temperature sensor. It comes out with all its tags so that it's completely self describing. Right? That would be great. And we see manufacturers starting to do that. But the reality of the existing world is none of these sensors have that in it. So where can we implement that next? Right? Well, the next place you could implement the semantics would be in the controller, right? The aggregator that talks to all those sensors and some of those control products are flexible enough that you can create an attribute model. So in the control of talking to the sensor, I can add the tags to describe what that sensor is. So now anybody who talks to the controller can actually get tagged data out.
Jim Frazer:Okay, John. So in regards to interoperability, there are, there are seven layers of interoperability defined bynOSI, and in very anecdotal forms, the lowest level is that your connectors much must match. That's the physical layer. The top most layer is the application layer. And that's where Project Haystack really works.
John Petze:Yes. Application layer. And even there, you've got different forms t hat it can take, right? A ll r ight. Yeah, I'd s ee it's, it's at the application layer. It impose anything on those lower layers. Right? It's like in the payload that you eventually get out in t hese seven layers is readable Haystack tagging information that the application can interpret.
Jim Frazer:And the way I think about this is in, in spoken language, English and French d o share the same c haracter set, but we can't speak to each other. And that's an application layer interoperability problem.
John Petze:Yes. That people are actually solving with amazing translation tools. Right? Absolutely. Yeah. Yeah. And, and that's, that gets back to something we touched on earlier. I mean, we're obviously promoting a Project Haystack- it fits a lot of applications. It's extensible, it's got a community, it's highly adopted, but guess what, there'll be others out there. But again, if you have a defined model, then writing an interpreter or cross mapping, that becomes a one time software project as opposed to a manual. every project, has to be done over and over again. so, so, it won't be the end of the world if there's more than one model out there. Yeah. It'll still move us forward. Right,
Larry O'Brien:right, right. Well, it seems to me also, I mean you were talking about proprietary controllers and then at the sensor level too. But to me it kind of seems like this would be pretty well suited to what's happening now in the world of control where we're starting to see an influx of edge computing devices and a lot of commercial off the shelf edge kind of stuff is starting to take over the role of kind of traditional proprietary control stuff.
John Petze:Yeah. And we're seeing Haystack built in two products in at that level of the system. But we try to emphasize that it doesn't have to be built in at the edge for it to be useful. Maybe the only place you can do the tags is all the way at the top of the controller hierarchy at the host software. Okay. Do it there. But at least that means now we can integrate a CMMS with the control system. We can implement analytics against the control system without doing all the data mapping.
Larry O'Brien:Or the interesting thing to me is, and I've talked about this with other people, is if you look at smart cities today, they tend to be silos, right? L ike kind of like p rocess plants are, y ou gotta you have a silo over here that's, that's maybe related to intelligent lighting. Y ou'd have an intelligent lighting system you might have intelligent traffic systems, you've got the water system. Now very few people are actually tying these together into an overall platform where you can look at data from multiple systems in a common environment, to see how these systems are related to each other because they are related to each other in many ways a nd, and make intelligent decisions about what's happening on a system wide basis.? So to me that's where the real value is, is this, provide know, providing this sort of infrastructure for this common environment across different systems.
John Petze:and an environment that is evolving. We don't know all the things we want to do with the data from the different systems that make up a smart city. Right. We're g oing t o learn over time, we're going to come up with really interesting ideas. Right? But if the d ata i s semantically modeled, th en I can try out my idea without a lot of wasted effort. We had one of those come up. Ye ah. Yes, exactly. We had an interesting one come up. Our company, with our analytics software, the majority of people use it for sensor data, equipment, data, detecting patterns of operation and proper operation correlation, stuff like that. We just had a case study submitted, o u t of Europe where they are col lecting social disturbance information and they've created an application that they call the antisocial activity thermometer. All right. So they just, and it's everything from barking dogs to traffic jams. everybody wants to jump to crime. They actually stayed away from that. What they're trying to see is quality of life, right. And show it in a way that people can and make it accessible so people understand and the city can somehow, they don't know yet how to work on these things because now they understand the patterns. Right. What was key to that was a defined way to add the semantic data. What we didn't have in Haystack was the vocabulary for antisocial activity. They added that because our methodology allows the tag sets to be independently extended and then submitted back, Hey, here are the tags we came up for to capture barking dogs and traffic jams and noisy horns and on and on and on.
Larry O'Brien:Very cool. Yeah. Yeah.
Jim Frazer:Fascinating. John, I know that I'm active in the connected vehicle world where there's 120 objects that will be broadcast out of every vehicle and connected pedestrian 10 times a second. Wow. Humidity, temperature, pressure, road, friction, headlight status. Well, business intelligence can be derived from all of that.
John Petze:Yeah, and can you imagine if every manufacturer on every model could do it differently? You'd never be able to deliver the value. But again, in the transportation sector, there's enough of a organization that can force standardization ahead of time. Right? The problem is we in the controls industry, the buildings themselves, right? The build environment in factory, all this stuff pre-existed these levels of understanding and we're stuck with what's there. So we need a methodology where we can add the semantics to the stuff that's already there. We can't say you've got to replace all your control systems, not going to work. And Haystack let you do that.
Jim Frazer:Well that's very powerful.
Larry O'Brien:Yeah, really good stuff. So if I am a owner operator or a supplier or whatever, how do I get involved in project tastes deck? What are some of the ways to contact you guys and resources maybe to look at and so forth?
John Petze:Yeah, so we'll start with the website. That's actually three websites and maybe we want to make it possible t he share that information with people. But t he, the first one is p roject-Haystack.org and it includes the links to the other. That was the first one. And that's where the people will have the working groups. And the discussion forum and all that stuff. And quite frankly, it's a little dry, right? But the organization also stood up a marketing website where we bring together magazines. There's a magazine that the organization publishes twice a year, articles, media videos from conferences and all of that. And you can link to that. But getting involved when the interesting things is we made a conscious decision that you could come to this site and you could download every bit of work the organization had done without even having to register. OK. everything is under the academic free license 3.0 so it's free to use. And we thought this was essential. A nd part of the reason I think you guys will get this i s, the kind of proprietary mindset t hat dominated the controls industry, right? People are afraid. I know there are people who I see, I see someone, w hen we look at the people, I know who that person is, but he won't use his actual email address. Right. Y eah. there's just this perception and I think it was a lot driven by the protocol wars of the 90s and h undreds in early two thousands w here mistakenly people b elieved one protocol could win over another. Right. And t here w ere all these battles and I think people still have them, but i t's so anyways, you can download it all. But if you want to contribute to the form. You're registered, no costs, you register, you're an expert in something. Join the discussion. Next level. We do have two levels of membership organizations to help formally support the organization. The first is associate level and basically there's an application and there's a yearly dues. And what you get for those yearly dues is basically you're helping us solve the problem by giving us a little bit of money every year that we can put in a marketing activity, et cetera. and there's a way to contact us on the website for that. And then there is a board of directors we call founder level participation. This seven members on the board of directors right now including Siemens and Intel- very excited to have Intel j oin us about two years ago. I think I mentioned we hold th e b iannial conference every other year and, w e' ll go out and notify the community and, some Intel people were coming and they pre sented an d it turned out they were using it in their IOT group. We didn't even know that, right, because it was solving the problem. And then they came and they've come ever since. And they joined as a founder level on the board of directors. We've got LeGrand which is an automation controls company, and Sky Foundry. We are of course, one of the people t hat got it going. Another company, if you will in the, t he smaller companies, is J2 innovations. And A company out of Australia, Con s erve IT. Those are the board members. But there's a whole, suite of associate members out there consulting engineers and end user organizations, produc t manufacturers, so you can get involved that way. but to get everything we've done in participate and contribute to solving a vocabulary and tag set for some application- just, sign up and contribute to the forum. So p rojec t-haystck.org is the central URL you need to get to everything else.
Larry O'Brien:Well, thanks for that John. so we're approaching the top of the hour now. I think we're probably go ing t o w rap things up, bu t a very informative discussion about Project Haystck. Again, this is the Arc smart cities podcast, w i th Larry O'Brien and Jim Frazer. And joining us today was John Petze of Sky Foundry and Project Haystack. I want to t h an k you guys for joining us this week and we'll see you soon.