Join us at NexusCon 2024 - Apply to attend now
“I know people have different views on what digital twins is all about. I think that if digital twins are fundamentally an integration challenge then the most pressing problem is how to make things work with each other."
—Anto Budiardjo
Welcome to Nexus, a newsletter and podcast for smart people applying smart building technology—hosted by James Dice. If you’re new to Nexus, you might want to start here.
The Nexus podcast (Apple | Spotify | YouTube | Other apps) is our chance to explore and learn with the brightest in our industry—together. The project is directly funded by listeners like you who have joined the Nexus Pro membership community.
You can join Nexus Pro to get a weekly-ish deep dive, access to the Nexus Vendor Landscape, and invites to exclusive events with a community of smart buildings nerds.
Episode 75 is a conversation with Anto Budiardjo, CEO of Padi and collaborator on many industry initiatives and thought leadership that we unpack as part of Anto's long background in our industry.
We took a bit of a deeper dive into integration, specifically the challenges with it historically, how it's time for a new paradigm, and where are the open source connection profiles initiative fits.
Then we discussed how Padi helps enable what we're all needing, which is interoperability.
Without further ado, please enjoy the Nexus Podcast with Anto Budiardjo.
You can find on Anto LinkedIn.
Enjoy!
Music credit: Dream Big by Audiobinger—licensed under an Attribution-NonCommercial-ShareAlike License.
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 Dice: hello friends, welcome to the nexus podcast. I'm your host James dice each week. I fire questions that the leaders of the smart buildings industry to try to figure out where we're headed and how we can get there faster without all the marketing fluff. I'm pushing my learning to the limit. And I'm so glad to have you here following along.
James Dice: This episode is a conversation with Anto Budiardjo, CEO of Padi and collaborator on many industry initiatives and thought . Leadership that we unpack as part of Anto's long background in our industry.
Then we took a bit of a deeper dive into integration, specifically the challenges with it historically, how it's time for a new paradigm, and where are the open source connection profiles initiative fits. Then finally, how Padi helps enable what we're all needing, which is [00:01:00] interoperability.
Without further ado, please enjoy the nexus podcast with Anto Budiardjo.
Hello, Anto. Welcome to the show. Can you introduce yourself?
Anto Budiarjo: Oh, James. I am Anto Budiardjo uh, most people forget the Budiardjo part just know me as I Anto I've been in the building space for over 30 years and a bit, I've tried to escape a couple of times, but I'm still here. Yeah.
James Dice: Yeah. And you've been you've been a thought leader in the industry for as long as I can remember.
So first, thanks for that for the
Anto Budiarjo: leadership. I'm excited to
James Dice: have you on the show for Albury for that reason and for obvious reasons.
Anto Budiarjo: You're doing a great thing with your community, so really appreciate it.
James Dice: Thank you. Uh, Can we start at the beginning? How'd you get into the industry and what were you doing when you decided, Hey, I want to work in buildings.
Anto Budiarjo: Okay. So this takes me back to London, which is where I hail from. In the, in the eighties I was running [00:02:00] a computer software and dealership company back then you can actually sell computers, personal computers, or make interesting margin and living uh, writing software.
A lot of the work I was doing was around a thing called aperture cards, which are microfilm. Stuck inside a, an IBM 80 column punch card. So that's how they used to manage microfilms in the sixties, seventies and eighties. Unbeknownst to me, that was actually, it really is taught about metadata, metadata about the drawings on the, on the actual card itself.
So unbeknownst to me, I was doing metadata where before I understood what the word meant. So that was the seventies and eighties. And one day sometime in the late eighties a guy that I know a customer. Bought some computers have me pointed to this box that turned out to be an Andover AC 256, or something, and said, can you connect that to this other box, which is a trend controls, IQ, [00:03:00] something or other, I can't remember the model.
And I looked at it product around and probably around the back and went away and raised some red, some software and made them talk. And that then led to the creation of the, the very first integration platform that I built in 1990. But we went to market in the UK called the CDC engine. So that was number one.
And that's really what brought me into the, to the, to the building space. And uh, integration is really been sort of, connecting different systems together. It's really been mostly. Cool. So you've built
James Dice: that first connection and then decided it was a commercial opportunity
Anto Budiarjo: from there. Yeah, that that's number one.
And Patty that we'll talk about later is actually number six. So there's been sort of others along the way. And and I, I just find the. notion of lots of different systems in the building and being [00:04:00] able to connect them to each other so that they can create some additional value. I just found that whole notion really, really interesting.
And even back in the late eighties, nineties, the concept of doing that so that you can extract business value and connect it to an enterprise information and other sort of retail information and things was always there. Although the older sort of things were being discussed, obviously the technology has changed a lot.
So it's kind of interesting to see people wanting that. And after 30 years, I, I feel like we're starting to get there in terms of the ability of, of an industry to understand what needs to be done and to actually start doing it.
James Dice: 30 years, 30, quick years, or almost there. So CDC engine was number one, Patty, which we'll talk about as number 6, 1 2 3 4
Anto Budiarjo: 5.
What happened in between um, number two as a project that we did with IBM in [00:05:00] the UK to monitor as 400 mini-computers in, in what they call dock sites, which are just in the room. And number three was something else that I did in in, in Europe. And number four was a product called you didn't have that then got acquired by CSI.
Then it became TAC and then now Schneider electric. So that's the, that was the time that I came over and a couple of other projects in between. I worked with helper to help him on some of those sort of middleware stuff that he was doing. And that takes us all the way up to now with Padi.
James Dice: Awesome. Alper Üzmezler at the BASSG
Anto Budiarjo: There's only one Alper.
James Dice: There is the only one out for everybody knows that. Alper just wanted to make sure that for anyone that doesn't know, we uh,
Anto Budiarjo: call them out. What cool. All right. So
James Dice: we'll talk about Padi hearing a little bit.
I think I'm wondering just like beyond, we're almost there. Can you reflect back on all of [00:06:00] these, these are all integration efforts, right? That's kind of a common thread in your careers, connecting devices. What was it like at the beginning? And then what's it like now, I guess,
Anto Budiarjo: Well, just as the concept of middleware wasn't really well understood.
And it was middleware that we were building back then. And back then it was all about using our ports as a way to connect to Andover and train and other other systems. And I was actually listening to a podcast of yours talking about API APIs and sort of the problems we have with API APIs API is reminds me a lot of
Back in the eighties and nineties, because my business partner will talk to somebody. And, you know, after about five minutes, the light bulb would come on and say, ah, yes, I have an RS 2 32. So he should be able to integrate it, right? Yes. Well, it depends on, depends on the configuration and it depends on protocols and stuff like that.
So [00:07:00] API is to me, the modern day equivalent of RS, 2, 3, 2, everybody has it. And they are wonderful, fundamental. They are wonderful, but it doesn't in itself answer all the problems. So it's kind of interesting how, that kind of thing, sort of repeated itself over the years and it's moving
James Dice: higher up the stack, same problems.
Anto Budiarjo: Yeah. Interesting.
James Dice: So what are you up to today? I have this list of all the things from, I always crepe on everybody's LinkedIn profile, but you're, you're currently doing a lot of stuff. So there's Patty we haven't talked about Monday Live deck what's what's Monday live for those that don't know.
Anto Budiarjo: And how'd that get started? Okay. So, Monday life is, is a, is a child of the pandemic, basically when back in March, 2020 when we started to go into lockdown, I remember standing in the, in my back porch as I was listening to the fact that Italy as a country was going into lockdown, I thought this [00:08:00] is crazy, right?
And this is going to come to the U S at some point or some variations on that. And I was kind of. I couldn't, I couldn't figure out what to do with that information. And so what I decided to do was start a zoom call on Wednesday evenings, happy hour time with a whole bunch of people that I know a lot of people that are now Monday live.
And so we, we started this weekly chat Wednesdays with with a beer in hand and just trying to sort of help each other, get through the understanding what the pandemic was all about. And you know, initially it was like, you know, I do I go shopping and all that kind of, sort of more like life stuff.
And then we started to think to, to use that sort of conversations, to think about what smart buildings, the relevance of smart buildings in COVID era. And that kept on going on a, on a, on a weekly basis. And after a couple of months of that, we kind of said, Hmm, wouldn't it be interesting if we took this format as just us [00:09:00] chatting and put it in front of the public.
Alright. So that's basically how Monday life got started. A couple of weeks after that, we decided to do it on Mondays at three o'clock because it needed to have a regular cadence. And that was Monday live. It started there. And we've been going ever since every single week, other than some holidays and stuff, but basically we're a, that that's our format and it sort of evolve initially.
It was about having to deal with pandemic. Then we started to think about what is this industry going to look like after the pandemic, and obviously this year sort of, that's where I think we're starting to get out of dependent. We're starting to think about what the reality is and, you know, and we discuss all sorts of things, including like supply chain problems is going on right now that other vendors are having.
So it goes, it goes in sort of many different directions, but that's really the thesis of it is just having conversations about it. Really [00:10:00] cool.
James Dice: And I've been a guest a few times. It's fun
Anto Budiarjo: to
James Dice: get into. I got interviewed by like 12 people at once. That was, my experience was like, oh wow, these questions are coming from all over the place.
So I think it's fun to get all those different perspectives each week. That's really cool. And those are on YouTube. People can go back and watch those.
Anto Budiarjo: The single ones on YouTube Monday live.org is where you go. You can register for the live sessions and there's a link to all of the YouTube videos.
James Dice: All right. Next next bullet point on your LinkedIn profile, a digital twin consortium. What's what's that all about? And what's your,
Anto Budiarjo: what's your, so, so I've been monitoring the concept of digital twin for, for a while. I think a lot of us are kind of intrigued with the, sort of the concept. The digital twin consortium got stood out.
I got, started roundabout that time, the spring of 2020. And so I saw an email or a post or something about it. Then there was [00:11:00] soliciting membership and I joined him. Partly because during that time I was, I was trying to sort of figure out what, what to do with the time and they loved him and I wasn't traveling and all that kind of stuff.
So I joined and it's actually been quite an interesting journey with the digital twin consulting. It's a pretty. Pretty awesome group of people. It has big big sort of hitters like Microsoft and Autodesk and GE digital and cleanliness and, and others. So there's a lot of sort of conversations about digital twins and they, they actually break it down into different vertical working groups.
So there's a, there's a working group on infrastructure, which is the one that attracted me most that talked about intro of infrastructure and buildings. And then there are others to do with aerospace, for example, and manufacturing. But that, that's kind of, that was the start of that. As part of doing that I kind of realized that digital twin in many ways is nothing but a giant.
Integration problem. [00:12:00] We're not talking about the systems in the building anymore. We're talking about all systems, whether it's smart cities or transportation or whatever, it's actually the same problem. You have all of these different systems that need to inter interact with each other, um, And that's roundabout the time that we were sort of working on the connection profile stuff, and I know we'll come back to that.
And so I decided that, that I wanted to inject that into the digital twin consortium conversation as a way of solving that particular problem or the integration problem in that space. And and in the process of doing that because the digital twin consortium is an open forum, right?
Everything has to be open. We, it kind of, accelerated us putting the connection profile mechanism into open source. So we're still working through that, but that was kind of the decision of actually taking the connection profile mechanism, putting it in the open source so that anybody can [00:13:00] ultimately use that mechanism to do integration.
Okay. And it's, it's continuing and it's continuing. And then there's sort of other interesting stuff that's going on to do with system interoperability, which is the focus right now in the DTC and some other interesting stuff. That's sort of a little bit sort of futuristic, such as I'm thinking about things like trust.
Okay, so your you're integrating, or you're connecting to some device that gives you a number of 75, you know, it's degrees because you have haystack tags or whatever, but how do you, how do you know it's actually coming from the sensor, but you think it's coming from right? What is the history of it?
What is the Providence of it? And why should you trust it to actually make a decision based on it and
James Dice: people, a bunch of potential competitors, but also building owners, it sounds like developers coming together to sort of solve these sort of common [00:14:00] problems to do with digital twins.
Anto Budiarjo: Yeah. Cool. Yeah. Yeah.
In different disciplines, which is, which is interesting. I I'm trying to get to my lane as it were, because you can get very easily distracted to go into aerospace and stuff like that. It's very interesting. But you know, ultimately the issue is the same, so right.
James Dice: Very cool. Yeah. I would have a hard time with that.
Pull into radical curious, curious people have hard times with digital.
Anto Budiarjo: You can be involved in those discussions and sort of, listen enough and contribute enough to know that to, to pick up the sort of commonalities right there that you can then say, okay, we can, we can apply the same technology this differently sort of way.
So it's a, it's a good way to expand the use cases.
James Dice: Okay. Last bullet point, the Coalition for Smart Buildings.
Anto Budiarjo: Yes. So that really came out of Monday live. So, towards the beginning of this year [00:15:00] after Biden got inaugurated there was obviously, and there still is a lot of discussion about what Biden's going to do with respect to climate policy and other sort of policies.
And so, Rick justice, I know, I think, you know, him and Pete Scanlon there've been there. They obviously work together and they've been sort of contemplating creating some kind of coalition, right? So they approached us and, and, and Monday live and when we had several discussions about it and, and they, they were very focused on states and local governments and persuading them or influencing them.
And we thought that was kind of interesting, but it wasn't sort of enough at the time. And an interesting thing, but we couldn't see how it could get traction. So we talked about it and, you know, mulled upon it for a couple of months and then. In may I think as many of may or June we got actually John petsy got an email from Jessica Grandison who formerly from Lawrence Berkeley national labs, and she's here.
She has just taken a position at the white house or the CQ, the cow's council for [00:16:00] environmental quality. And she was reaching out basically to, to seek help. Knowing that she having spent a lot of time in LBNL, she obviously knows all of the gap and all of the sort of Dr. Related stuff.
But she was basically saying to make this really impactful we need some additional help. We need to sort of understand how to address policy issues and regulations that can actually. Enable smarts in the building. And that was her ask. It was a pretty short ask and we then sort of looked at this and brought it in again with discussion with recompete and we decided, you know, this changes things a little bit right now we have the white house involved and, and, and other sort of place in DC.
So we stepped up and we put together a six page proposal document that basically laid out how we think all the, sort of the big issues that need to be dealt with from a policy and [00:17:00] regulation, including interoperability, analytics and some other stuff that we can go into. But and out of that, we, then that sort of then became the starting point of the coalition.
And and that's what the coalition is. We've now had two face-to-face meetings in DC, one in August and one actually just last week making a lot of progress talking to a lot of sort of DC people. It seems that we've sort of captured the, the, the essence of a really, really interesting topic that a lot of people in DC needs to understand and need some expertise.
And then we basically a sort of being appointed by ourselves, I guess, as a group of people that can contribute to that stuff. That's, that's the coalition for smarter buildings
James Dice: I like that we've been appointed by ourselves.
That's fair. That's fair. And I saw Elsa saw Kara Carmichael. Who's been a guest in the podcast. She just took a job at the CEQ as well. They're putting together quite the team over there. She's from [00:18:00] RMI net zero expert. So
Anto Budiarjo: very
James Dice: cool. All right. Let's, that's a lot to
Anto Budiarjo: be involved in Canto. Okay.
James Dice: All right, I'll cut it off. There that's enough context of what Anto is up to these days. So one of the things that you guys have developed through the Monday lab conversations is this smarter stack, smarter stack, not smart stack, smarter stack concepts. How did this come about? And before you talk there, For those of you that are listening on audio, we're just going to talk through this.
But this is the best as a visual tool. It is a visual tool. So we're also going to put a little demo, a little screen share on the YouTube version of this podcast that we'll put in the show notes as well. So this will just be audio, but then we'll, we'll, we'll add the video back end.
Anto Budiarjo: So let's launch into this. So what is, what is this all about? Where. The sort of a extremely high level. We know that there are users, there are as human beings, we occupy, we own operate them.
Otherwise we consume buildings, [00:19:00] right? And at the other end, we have the buildings and we know that there are controls and automation systems somewhere in the middle, there are some smarts, right, which are technology and services to, to make the building smart. That's really the, the, the, the, the, the mission of this whole industry.
And we also know that the smarts is generally speaking, made up of two things apps that actually do the computation and analysis and, and display and everything else and the data those are kind of the two really, really important parts of being smart. And we also know that in these sort of four layers users, apps, data, and building.
Also sort of describe the needs of those in a very generic way. So we know that users just need to consume the building. They just need to make sure it's safe and healthy and productive environment. The apps, if you're an app developer, you just want the app to be delivered to whatever user you you know, that your function is designed for and to get [00:20:00] data for that app to be used.
And the data needs to be there. It needs to be gathered, needs to be secured. It needs to be available to applications that need it, then the buildings just need to operate. Right? So we kind of understand the components and their needs. So the smarter slack starts to do is to start to sort of build on this and to make sure that the.
These the, the value flows, the value of the smart flows all the way to the, to the users. So the first realization that we had is that there's really sort of, not one group of users. You know, they're ultimately, there are many different types of users, but if we if we, if we try and split it into sort of broad groups based on their, based on their needs there's really two, there are those individuals or people or organizations that are interested in the purpose of the building, right?
So here, we're talking about building owners that whether they want to make profits or operate a hospital or whatever, the managers, meaning sort of store managers kind of, [00:21:00] individuals. Okay. Me going into a shopping mall and wanting to buy a pair of shoes. That's, that's me. There's a purpose being, being always being in play there with, with these types of users.
And then there's a second group of people that are more focused on the operations of the building, thinking about facility managers, maintenance, people, even janitorial kind of services. So they, they actually make the buildings be ought to be able to be consumed by those that actually wanting the purpose.
So that's kind of one realization. The other realization down down here is that from a buildings perspective, there's the physical part of it. And then there's the automation part of it. They're very different. They have different dynamics, different life's lifetimes et cetera, et cetera. So we separated those two out.
I think that's pretty obvious to people and in the smart. Part in the middle pop we basically split it into four. We said right at the top, there is a delivery layer, right? So this is talking about how the smart is being delivered to the users. So this [00:22:00] could be talking about an organization such as system integrator or a managed service provider.
Or it could be talking about technology. So it's a single pane of glass and, and mobile apps and other things. So there's kind of a delivery layer that's needed for the users to consume everything underneath it. Then there are the apps probably the best understood. So I don't need to spend that much time on that.
And then the, the other sort of new layer that is added to make sure everything works together is what we call the change. We've actually had new bed, various names for this, but we settled on the exchange after, after a while. And this is really a layer where things a layer that makes everything work.
So things like middleware. And things like haystack, semantic, tagging, and other sort of integration tools, as well as products and companies sit here in this, in this exchange there. And then we have the data layer and that's all to do with the data. How do you, how do you gather it? How do you store it?
How do you normalize it and do your governance to make sure [00:23:00] that only the right people can use it? So this is basically the smallest stack, this, this eight layer stack. That starts with purpose going all the way down to the physical layout of the buildings. Those of you that read the Simon Sinek know about this concept of starting from Y the notion here is the a lot of people when dealing with tech really focused on the word.
Right. As we typically do the writing the application and doing the data management and everything else, but really to fully understand the whole system and how to deal with it, you really need to start with a why. And this is what the purpose is all about. Why is this being done? Why is this meeting the spots as small as being, being done, and then does the, how, which is how it's being operated, the house, they live house being delivered, and then everything else, the Watts, right?
So this sort of maps, so that sort of Simon Sinek view, which is very interesting. So the way we see this smart suspects being used is that we use it as a backdrop. So a lot of words, if I'm [00:24:00] trying to explain product X, I just need to put it there. And we'll automatically know that it's. Right. We don't know at this point what app it is, but we know it's an app and the technology down here would be data.
So we understand that then even sort of companies, right? So this is how the tool has to be used and you'll see quite a number of of this. So one of the first things we did is to actually say what's really going on in the industry right now. And it can really be encapsulated in this one slide what's happening is that we're moving from a a sort of a model and an industry model of vertically integrated BAS offerings where the systems meaning the control and automation system is within the same offering as where the data is stored and where any data exchange is actually being done.
Typically everything's happening inside the boxes sort of proprietary. And then the apps are also proprietary. And so inside the box as well, and even the delivery is proprietary. If you think of the, the, the, the major companies, they have branches and they have channel, those are sort of delivery mechanisms, as well as [00:25:00] supervisory sort of applications.
So all of that is in a box making it typically is proprietary. Most cases are proprietary making it difficult to go. Except go out of the box and making it difficult to come into the box. So this is why integration is so hard with these kinds of systems, because it's not designed to be integratable.
So we're moving into this. And also on the, on the owner side, on the building side, typically the purpose and operation is incented done by the same group of people. We're moving from this model to a model. And this more like this, where everything's all split up and this is how the internet works, right?
So there are different purposes for owners and occupants. There are different entity is the operating the, the facility. There are different delivery mechanisms, technology and companies, and there are different apps and different exchanges and different places where data can be stored. Right? The only consistent thing is that the building itself 1, 2, 3 main street, right?
So this is kind of a one way of using the. I'm just going to quickly go through a couple of slides just to throw up some [00:26:00] concepts. This is just we brainstormed one of the Monday life planning sessions. Talk about all of the different categories that or different product type that is our space.
So something like energy management this year and the apps something like weather data is obviously data, data warehouses. It's in the data lake. I think like FM and IWMS applications or apps maintenance, genital, et cetera, et cetera. You see the sort of the full range here. One of the interesting things is somebody at some point said, where's connectivity.
Where does networking fit into this? Where's the layer for that? So one thing worth pointing out. This is not a network layer. This is not a technology layer. So there is no network layer, but this is not a technology stack. So there is no network layer. It's really a sort of a business value proposition, supply chain the stack.
So connectivity in a way is its own. Right. Because if you think [00:27:00] about connectivity, there's a whole bunch of purpose related sort of things you can say about connectivity. You need bandwidth, latency, reliability, et cetera, right. That's, that's kind of where you typically start. And then you have know different ways that you, you execute that.
And then you have applications like software defined networking, which is really an application. Then you have the data, meaning things like SIS logs, they're all kind of communication related data. And you even have physical things like antennas and cables and. Right. So those are all communications attributes, right?
So you can actually create multiple layers of stacks to deal with different things. Security is the same as well, because there is no layer for security, right? In a way it's a vertical saying, so you have purposes as well as security, defense, defense in depth and zero trust kind of things. And you have physical things.
So conduit protection is a legitimate cyber security thing to actually protect the conduit from, from being accessing the. [00:28:00] Right. So you can actually have different layers that sort of, start to draw the picture the other way to think about it as you can use the the, the smartest tack to describe the requirements, right?
So this is a fictitious high school requirement, right? Imagine myself sitting across the table, across the zoom, where they Sue a school superintendent or senior engineer or whatever now describing what their needs are. They need scheduling, they need comfort. They need some social interaction, principles, safety.
As far as operation, they would like a school. They would like a dashboard. Then they have an engineer on site and they would like to have CCTV monitoring as part of their operations. And in terms of delivery, they liked the MSP model. Let's say, so this is where it goes. These are the different apps that it is from the exchanges different where, where data is stored.
And these are the different systems that have in these other different buildings that have, so you could actually see. Just buy this one, buy this stack, you, you, you start to build a picture of what the requirements are very, [00:29:00] very you know, clearly now you obviously need to use this to create specifications and other things beyond this, but this is really sort of a great starting point.
One thing I want to comment on the use of the smartest stack is the perspectives matter. The stack looks different depending on who you are, if you're a building owner. If you think about it, ability known thinks about the purpose of why he, why he or she has that building. Right? And he cares about the operation and the lower down it gets on this stack.
The less he kind of cares about anything. Whereas a middleware kind of person would think about it from the exchange perspective, because about how the data is being used and how to get at the data and maybe how to communicate to other middleware. Right? So depending on where you are, you have different perspectives.
These are different standards and technologies. Again, this is rough and I don't want to spend too much time on it. And what I want to do next, where I want to get some time for some [00:30:00] discussion. I want to show two examples. One is an example of actually my company, Patty, of actually using the, using the stack to explain the product, right.
And then we'll, we'll go to another example of actually using a on a real site. So this is a Paris my company, and this is our smarter slack to explain what we do during this to, you know, as an example of how to use the smartest slack we have a Patti store where you can buy app.
Right. That's kind of the way it works. We don't create any apps. We provide a mechanism for all of you guys to create apps that can then go into the body store. And Patti itself is is a cloud based platform. So it sits on the delivery level. What we do is we, we, these are kind of the purpose of using Patty single sign on creating dashboards and collaboration, et cetera, as kind of, and we're using this another convention of the spotter stack is we using the solid box to indicate what we do in this case, Patty, our offering, and we're using the dotted line to to, [00:31:00] to say, this is what we expect other people to do.
Alright. So these are what we deliver in terms of the operation. These are the people that are going to use the product that we expect to use the products. They obviously did not ask. They're all dotted and the delivery against system integrators and consultants. They're the, they're the the type of people.
And these are the type of technology that we enable using using Patty. And on the other side or Patty, there's a thing called connection profile, which is an exchange layer. It's a system to system interoperability mechanism. So we then work with different it kind of standards. And we enable protocol and semantic standards to to work through this this, this mechanism, the data from our perspective, we don't care where it is, the systems.
We don't care what they are and the buildings, we don't care what they are. Right. I mean, we care a lot, but we, it works. It's designed to work with multiple scenarios. So that's kind of one example. The other example, and that I jumped into is like, fire station. This is actually created by [00:32:00] Pete who I don't see on the call here, or you hear beat.
And so, this is done retrospectively. So this was actually done three years ago. This was the original sort of document to describe the goals and what the pieces are and what Pete did is to put it on a stack. So this is what it looks on the stack, the smartest five station. This is the base fire station.
These other, the the objective that they had, the purpose they had, these are all the different pieces of. Of, of that the different areas of that fire station. These are the different systems that are involved. There's a 75 F system that is that is displayed here. That goes all the way up to the apps layer has faced.
It uses haystack and inside of it there's an EMS system. That's put on the other side and it uses Vultron which is sort of, focused on the data and exchange layer. And, and it has an FDD app that's using Skype. In the stack anyway, and the delivery, there's a, it's a direct channel delivery.
And [00:33:00] the, in terms of the interfaces, they this has done using a single pane of glass and this is how the operations is done. The city does most of the FM operations and the sort of management, right? So this draws a sort of a really clear picture of what's what's going on.
James Dice: So how did
Anto Budiarjo: this come about?
So, going back to the, sort of the conversations we've been having for the year and a half, but in Monday live, a lot of those discussions have been. Trying to rationalize all of the different technologies, the products, the companies, and the people involve and coming in and out of this of the industry.
And it gets very, very confusing, very, very fast because people are coming up with all sorts of great innovation. And in a way, a lot of the Monday live discussions is trying to organize that trying to organize the initiative now and our sort of minds. So we had the notion of, we had the notion of creating some kind of business stack quite early on in the middle [00:34:00] of 2020s, but it didn't sort of, hadn't sort of jelled and sodas kind of just sort of work this way through it.
That's one of my things about this kind of conversation with the group. You can sort of pick things up again over again and again. And so when, when the coalition started to come together this year spring early, early summer we now had the coalition as a sort of a potential vehicle to channel some kind of messaging about how to structure something.
So we thought let's take another look at the other stack that we're working on. So with, we picked it up again and talked about it. Made some changes. There's one of, one of the layers was not there. And the original one, it's actually very, very important. It's actually the top, most layer we didn't have top most layer.
And the top, most layer is actually the most important layer. It's the layer that says purpose, you know why you're doing something right? Simon Sinek, so talks about we'll focus. Typically we'll focus on a [00:35:00] watt all the time. He advised us to think about the why you're doing something and how you're doing it.
And then now talk about the watch, right? So the top layer is kind of the why. And so, we brought that into the conversation and we now have the stack, right? So the stack is eight layers at the top is purpose. And then underneath that, so purpose is kind of the building owner or a, an occupant or a school teacher or you know, somebody that actually.
Has a purpose in terms of their relationship with the building, they need something out of it. So that's the top layer, the second layer there, below that as the operations layer. And these are the technologies and the people with regards to operating the building on a daily basis. Right?
So facility managers, energy managers from a bank tenants people as well as janitorial and everything else. So that that's all on the operation. And then underneath, that is what we call the delivery layer. And this is kind of a a new concept. And it's really about how the smarts are delivered to the [00:36:00] operators and the purpose driven people.
And here, we're talking about system integrators and the people that actually work there and those kinds of companies, but all also delivery type technology. My company, Patty is a delivery type technology. So that's where it would go. But there are others. Mobile is essentially the same thing down the road.
AR and VR are sort of delivery technologies, right? So that's the delivery layer underneath the delivery layer. There's the apps layer. That's probably the one that we know the best. We understand that analytics and management tools and all this sort of stuff that people are developing. So that that's pretty easy to think about.
And underneath that underneath the apps layer is the layer that we call exchange. And that's really the layer of middleware. That's the layer of using technology to translate data, to make data able to be used by different different apps or different tools. So we call that the exchange layer, the [00:37:00] connection profile technology that that we created, this fits in there.
And then underneath that is the data there, which is really your independent data layer. That's what you talk about. So that is just the data layer of the smarter stack. But the way we think about it is not only does the data layer need to be independent, but so, so are the other layers need to be independent.
They changed Mister, be independent from the data and they changed needs to be independent from the apps and the apps it's independent from each other. So each of the, each of the layers. Independent, and if they are independent, then you can get composable sort of systems mix and match type things that can address whatever, the, whatever the building owner occupants need, which is right at the top of the purpose level.
So those are six levels go up. So, purpose, operation delivery apps, exchange data, and then at the bottom are the two layers of one is the systems, which are the systems, the HV systems and the control systems. And then right at the bottom is the physical, which is the actual building itself, the concrete and [00:38:00] steel that actually makes a building.
So that's the whole stack and the way we use it is that we, we use it to, to explain things, right? So the same way around saying Addie is a a delivery layer. Something like sky Spock from John's company as a, as an Appalachian. That's pretty easy what that is. And no no van what Andrew and the Frank is doing is a data layer thing.
Brian, it's very easy to think about it that way. And so you, you use that and you can also use this as a sort of to, to explain products, but you can use it also to build requirements, right? I need this, I need scheduling. I need critical emergency management. If you're doing schools or whatever, then you can then build out that requirements all the way down to the bottom. And then you can start to think about how the, the, the different pieces of the technology and products can, can interact with each other to make the whole thing, deliver the purpose. That's desired. So it's really a communications tool, quite quite a few engineers sort of, have problems with it [00:39:00] because you compare it to something like the network layer where everything's has very sort of very specific place. The smartest stack is really more of a communication tool. So you can actually have discussions about whether something, something like haystack, for example, is that an exchange layer or isn't that in the data layer, and there's actually different parts of haystack that haze that tagging is really in the, in the exchange layer because it enables things to be exchanged. But data that is tagged is obviously. So there's kind of different perspective and you can start to split those kinds of functionalities. It's been very, very powerful, and we're starting to build a library of a smarter stack because people are creating these it's going to be available on smarter stack.org which is actually hosted on using Patty to actually show it all.
But it, it's, it's a really, really interesting tool. And whenever I hear somebody trying to explain the technology, I try and sort of bring up the smarter stack and sort of imagine where they are, because that would at least clarify it for me as a listener. So, [00:40:00] yeah, very cool.
James Dice: I feel like, so I watched, I watched you there, your webinar with Memorial and I've watched a couple other of your demos and what, what I feel like it's like underneath this is kind of a new way
Anto Budiarjo: of.
James Dice: Developing a technology stack. You know, I know it's a business framework. I know it's a communication method, but one of the, one of the slides you showed in the Memorial webinar was this approach versus a full, the full stack approach of yesterday where one provider would provide the entire thing up and down.
Can you talk about like the difference in philosophy? And it seems like this is like the new, the new way of
Anto Budiarjo: doing. Yeah. So if you, if you think about traditional BAS offerings, I'm not going to mention any names because it applies to all of, all of the companies, what typically have a control system, which is down on the system level [00:41:00] right.
Of the stack, they would have some kind of data management on their, on their platform. So they're part of the data the, the data layer Probably we'll have some kind of exchange mechanism proprietary, or they may use a gateway to extract stuff from external. So that's the exchange layer and they obviously have apps, that actually is kind of whether it's configuration apps or analytics apps. So part of that, and then they also have a delivery layer, the big companies have branches as delivery tools in terms of how, how all of that stuff gets delivered to the user. And they have delivery technologies such as supervisors sort of, vendor specific supervisor.
So that is what five levels of the stack. And you basically put a box around all of that five because that is the vertically integrated solution. And what that means is it works really well inside because it's all done by one, one company, or maybe a very, very small ecosystem, but it's really, really hard to break out of it.
And it's really, really hard to [00:42:00] break into it. So when you want to integrate into such a system is typically hard because everything is inside. Everything inside the box has been configured to be proprietary. And it just works the way it. Yeah. So that's a vertically integrated sort of solution set.
And when the, the sort of the alternative way, and I think this is what you're talking about, the sort of the, the paradigm that we're moving into is. Each layer can be separate companies and separate technologies, right? So you can have systems that are just doing the controls and then the data, the data layer, you call it independent data.
Great. That is independent from the system, but it should also be independent to how it then gets used above it. So they change could be changed a bit different. It could be anything from a middleware thing, like, Niagara to you know, haystack and whatever, right? So you can use whatever you want.
And the applic applications can then also be [00:43:00] composable be sort of pluggable into each other. And then again, separating out the live delivery because things the smarts needs to be delivered in different ways, depending on what they are, depending on what the billing type is, depending on all sorts of different factors.
So you can actually split all these layers apart. And then you know, the, the, the one other comment. People often say, is that doesn't the owner just want one person to supply it, right? Yes they do. But the owner sits at the top of this layer. The owner typically works with the operator, he or she, or they care about the operations.
And they care a little bit about the delivery, but the deeper you get in the stack the less they care. Because they really care about the top stuff. So as long as it all works, as long as all the layers work with each other and they're all independent he still has he, or she still has one vendor, one service provider, maybe on a, on a service basis as the delivery or as the operations layer.
So we [00:44:00] take somebody like JLL, they're more sort of in the operations layer or a system integrator would be. Yeah, it will be on the, on the delivery layer now, just so you still have that mechanism of, of the getting, making sure that you, you get what you need. But it's composable and it makes it much more flexible.
Cool.
James Dice: Yeah. And what I, another thing that I, glean from it, when I, when I watched you talk about it is the, if these fully integrated companies were meeting the needs of the top layer, the why there wouldn't really be a problem with that, but those needs those why that top layer that's evolving and expanding.
And like the people that are needing smarter stacks, their needs are evolving and leveling up all the time and it's getting more and more and more important. And those integrated stacks, like you said, you can't pull anything out, you can't pull it to the new thing in. And it's just, it could becomes a [00:45:00] point where like you better meet the needs or else it's going to get disintegrated to something that can meet the needs.
And so I feel like that's the underlying message and I don't, I don't feel shy about pointing that out.
Anto Budiarjo: It's more that, that it's not in any way that they're bad companies or bad people, not at all. So it's kind of, the industry has evolved into that being the, the best way in the, in the past two or three decades.
So delivering I think we're going into a new a new phase where there are different ways of delivering it. And know, I, I sincerely hope that the big companies will sort of figure out a way that they can add value to this new world where things are split up. Totally. Me too.
James Dice: Hey guys, just another quick note from our sponsor nexus labs. And then we'll get back to the show. This episode is brought to you by nexus foundations, our introductory course on the smart buildings industry. If you're new to the industry, this course is for you. If you're an industry vet, but want to understand how technology is [00:46:00] changing things.
This course is also for you. The alumni are raving about the content, which they say pulls it all together, and they also love getting to meet the other students on the weekly zoom calls and in the private chat room, you can find out more about the course@courses.nexus lab. Start online. All right, back to the interview
Let's shift our focus to integration
Anto Budiarjo: platforms.
So
James Dice: that's honestly what you're developing now, right? With Patty. You've been thinking about integration for a long time. Let's talk generally first about sort of what's been missing from integration platforms. Why, why is integration so hard?
Anto Budiarjo: Historically. I opened up this interview explaining that integration has been my, my life.
But the more I do this, the more I realize that that's actually wrong because integration is an act of integration, the act of integrating things, right? So you are a system integrator and what you do is you make systems work with [00:47:00] each other. And those systems are inherently designed not to work with each other.
So that's why you integrate, so that's why it's hard because the, the systems that you're trying to integrate were not created to be integratable. So integration is actually the wrong word to use. Same way as smart as the wrong. Sorry, a smart, that's the wrong word to use. Now we're moving to smarter.
Integration is the wrong word to use. The better word to use or to aspire to is actually interoperability. we know how to interpret with you works, we know backnet devices can just plug into each other and the inter operates, we don't think twice and things like USB and other things that in our lives inter operate really, really well.
And with Symantec tagging haystack Braco Symantec and other industries you're able to inter operate within one domain typically right at the. Okay. Great. So you have interoperability at the protocol level, a physical level, and then you have interoperability at the semantic level.
What that [00:48:00] does not exist is interoperability at the system level. The concept of that is I should be able to introduce a system into a building. Let's say there's a building HPAC lighting, blah, blah, blah. And the, like, I should be able to introduce a, an IAQ or a people counting technology into that, into that building.
And into the twin of that building. And it should, it should be able to say, ah, okay, I understand how to talk to that. I understand how to talk to that and it should just work. So, I'm actually doing a podcast next month with a DTC called all about system interoperability. So I think that's what we should be targeting.
That's what we should be aiming at to make systems into operate each with each other. The stack provides us actually an interesting way of doing that because each layer is typically a system, right? The, the, the data, the data, or maybe multiple data sort of pools those are all systems, but they all need to interoperate [00:49:00] with each other and with a change layer and with the apps.
So they, they all just need to work with each other. And that's what I think that's really the, the main problem with integration. It's it's, it's, it's the wrong word. It's the, it's the wrong task. Totally. Yeah. That,
James Dice: that it should just work feeling. I think a lot of people have that feeling. Can you describe what has to happen?
Because say you're plugging in an IQ sensor because it doesn't just work at this point, what has to happen? And we spend in my course, which I'm in the mindset of right now, because we're in the last week of it, but we spend an entire week of a six week course talking about all the ways in which this process goes wrong.
But can you describe like, what has to happen in the case of an IQ sensor or the case of a new air handler controller being put in or whatever you want to talk about? What's the
Anto Budiarjo: current process. Well, the current process is what I describe [00:50:00] as end point thinking, okay, if I'm, if I'm an IQ system and I need to introduce it to a building, I know, I know my, I know my system. I know I'm an engineer or the IQ system. I know what my capabilities are. I may have API. And I'm being introduced to a building. I have to somehow figure out where I need to communicate with right. It could be a Metro system or it could be a Jace or whatever.
So I have to figure that out right manually. Then I have to figure out what protocol I need to use. What API is. I need to use, what keys I need to provide. There's a lot of metadata that is. Purely to do with communications. And I need to know where they, what API end points are. I need to know what protocol they talk to, and it needs to know that I'm legitimate user using keys and other stuff.
Then there's a lot of a lot of interaction about the context, I'm really only interested in IQ in the lobby, for example. And so I need to tell it I'm really interested in the lobby, right? [00:51:00] So as I think about it as end point thinking is because I can only do that from my end, from the ICU.
And you may be the HVC system or contractor engineer, so you are looking at the. From your endpoint I can provide and to an API so I can communicate to you, but it's all your perspective so you're thinking about your endpoint, I'm thinking about endpoint, everybody's doing the same thing, right?
And the only way we can communicate is if we want to one one-on-one agree, which ones that is, some standardization on somatics obviously helps a lot with that. So that, that is what makes it hard. And this is sort of a good segue if you're okay with that, into what connection profiles, all of that.
Because, because connect can profile turns that upside down, right? Because connection profile, isn't a profile about an end point. It's not, it's not a profile about media IQ or you the AJC, it's a profile about a connection. A connection of in this case, how I, and I, my boy, [00:52:00] how an IQ system talks to an HPAC system.
So what you do with connection profiles, you take that use case, right? Of which that I'm sure there's going to be thousands. If not millions of instances, that projects that needs that, right? You take that, that use case of why an IQ system needs to talk to an HAC and you codify that in a connection profile connection profile basically says one end needs to provide these days, these pieces of information, such as URI, the end points, keys, the other end needs to provide other sets of information, such as the context, the security keys or whatever.
You codify that into a connection profile. All connection profiles, have names, have unique names and are open and available on a directory in the, in the cloud. Very similar to the domain names are all open. You know what? cnn.com is doesn't matter where you are in the world is always going to get you to cnn.com.
With the connection profile, the connection profile is [00:53:00] given an eye, right? So it may have the name of IAQ dot HPAC. I'm just making that up. And you, you create that connection profile for that use case. And and you do that once, right? And ideally you would do it with people that understand the use case, understand IQ and understand HAC.
You do that once you put it in the directory in the sky, and whenever an IQ system comes along and being introduced to the twin of the building, it basically says, ha I I understand IQ dot HPAC, which is the connection profile has been defined as anybody else in this building understand.
Okay. And so the HPAC system, if it does, it says, yes, I can be the opposite end because it's that the two are complimentary ends. We call them client server. So the HPAC system says, yeah, I understand acute rotation. So who, who the HCA system is is irrelevant, right? So it's all coded in the connection [00:54:00] profile and the connection profile.
Then they find the, what parameters is actually going to be used for the IQ system to talk to the HPAC system automatically based on that profile, it says is you basically, you create an instance of that profile. You copy it. It's like a model of the profile. All right. So you can do that over and over again.
And you can also have multiple connection profiles to do lots of different things. So the, this IQ system could automatically collect, connect to the HPAC, but it can also connect to the lighting system or connect to the access control system in for four different use cases. So all of these things were just sort of instantiate themselves when you introduce the IQ system into the, into the building, they become interoperable.
James Dice: Very cool. So does this require them to be on the same network?
Anto Budiarjo: I bet that's a question that comes up. So the way connection profiles work is that the the connection profiles [00:55:00] require a broker. Mechanism. And so, Patty, my platform is a broker, such a broker. That's cool. We have to build first. Other digital twins will, can also be brokers.
So it requires a broker. And when I say introducing IQ into the, into the building or into the building's twin, what I'm saying is what you do with an IQ system is I'm introducing it into that broker into that system that understands all of the different systems that's in that building. Now what's important to note is that that doesn't mean that all of the data goes through the broker.
And this sort of a critical part of connection profiles is that I'm an IQ IQ. I've established that urinates vac that we can, we understand each other, we can talk with each other. So we, we can, we can exchange parameters in terms of how we talk. But really it could well be that the actual useful data flow or information flow will actually using some API APIs.
Which can happen across the [00:56:00] network, across the internet or whatever. So we actually separate out the, the, the controls the sort of communication controls from the data controls. so we think about it as orchestration layer, as a metadata layer that sits on top of the, all the different systems and the role of the orchestration is to discover and connect all of these different systems together.
James Dice: So when um, I ACU and I say, I'm in the lobby, I'm communicating that out. You know, the S the CO2 is 950 parts per million in the lobby. And then I'm the HVAC company. And I'm saying, I have his own in the lobby. Like, is it that? And then some sort of middle system needs to say, well, your lobby and your lobby are the same lobby.
How, how does that piece of it work,
Anto Budiarjo: Starts getting geeky and complicated? It kind of depends on, on the, on the structure, really connection [00:57:00] profiles is think about it as the main place where it works is in the initial installation and this. I install the IQ into the building, meaning into the, into the buildings twin, and with a broker, it then says, ah, okay, well you can connect to the HPAC. And then the profile defines how that connect communication occurs. And so, the connection profile, isn't concerned with a particular piece of data. That's going from my group to the HPAC, that the connection profile is just managing the connection between the two and between other other entities.
So
James Dice: something like a global data model that connects those two pieces of context that would live elsewhere. At
Anto Budiarjo: this point that would live, that would live in the twin. I mean, I, I actually think that's what a digital twin is. It's kind of what the role of the twin it's actually to understand all of these different systems and know when two or more systems need to connect with each other.
So that's really what the twin is doing. [00:58:00] And one of the sort of interesting things about, you know, about API is we were talking about API earlier is that this enables API has to be used, aPI has to be discovered. And there's another critical thing about API is that scares me a lot. Is that the, the, sort of the, the equivalent of the 4 0 4 problem with API APIs, you have a building, you know, a hundred systems.
There's lots of API is going back and forth, right? If something changes. There's actually nothing that sort of is monitoring to make sure that everything's still keeps on working right. When the URI changes, if a server is maintained or something, and the URI gets changed, all of the clients, all that API will break.
Because it works. Or if they API key has changed, same thing will happen. Connection profile stays there in the building forever. So it's monitoring an orchestra, orchestrating the connection. In real life forever. Right? So [00:59:00] if something changes, it can actually distribute that change instantly.
So everything's all up to date, right? So nothing, nothing breaks. It's dynamic. That's, that's another key part of connection profile and sort of the way to think about system interoperability is dynamics where, and this is going back to the little twin. This is where I find some of those sorts of use cases.
Interesting. I'm working on use case of basically your automated factories, right? Where you have sort of automated forklifts moving around, moving stuff. And they're obviously concerned that. These are not driven by humans, so we don't want them to run over people. So, we're using the connection profile mechanism to monitor all of that.
And monitor use cases like, okay, so what if the forklift breaks and you rent one from the, from Hertz or whatever they couldn't is. So that's going to come in. It has no knowledge of that factory that has no knowledge of the owner. But if it had this sort of level of metadata about trustworthiness and other, other stuff at this sort of metadata connection profile level, [01:00:00] then you can just hop in immediately.
The minute it drives into, into the manufacturing floor and actually discover itself self-discover itself. So it's all done. It's all designed to be dynamic.
James Dice: Okay. So my thinking about this right, where the digital twin has the sort of. Metadata that's related to physical systems, how they interact, that type of thing.
And then the connection profile has communications level metadata, and they, they need each other to continue to function.
Anto Budiarjo: To me, the way I think about it. And I know people have different views on what digital twin is all about. I think I fundamentally think that if, if digital twins are fundamentally an integration challenge then the most pressing problem is how to make things work with each other.
And therefore connection profiles, a collection of connection profiles is basically what connection of connection profile between nodes that are virtual representation of physical things, that is really a a digital twin
James Dice: I love how I'm just [01:01:00] like learning out loud here. So hopefully people find this helpful. I feel like I'm asking really basic questions, but the, what would be an X? So we used IQ and HVAC. So what can you, maybe this is even too long of a list to describe, but what would be in this packet of information that is the connection
Anto Budiarjo: pro, a connection profile is usually pretty brief.
Just a document. There's no code or anything. It's just a document that basically says the connection profile. This name X right. Was created. So that system a can talk to system B to do X. Okay. A could be a key or something else in system B, it could be something else. It doesn't really matter what they are.
And X is a purpose, right? Purpose could be to provide indoor air quality data, or it could be providing whatever. So the connection profile has that sort of use case driven thing, connecting one to another, to do [01:02:00] something. And the, the, the main part of connection profile is what does a need to provide and what does B need to provide?
So I've B is a server that is that API. So we're going to use one of the most common things in a connection profile is that you need to URI or where that API lives. Alright, that's one, that's one property of a connection profile. So another property could be what protocol the server is.
Speaking. Because it could be, it could say, you know, I can, I can do Jason, if you want, I can do X XML, I can do whatever. So that could be another property that the B system has to provide. And it could provide some others, but those are kind of two critical ones. The other end, a is going to consume that API.
So typically you need an API key, so, so the API key is then a property that has to be stored in the client. Side And another typical uses that you may need the context, [01:03:00] right? So the context ID, or some kind of naming convention needs to be provided by the client by ed. So, so that's just two on each side, The API key in the context, on the client side and a, the API endpoint and the protocol on the server side, right? You have, you have those two on both sides. When, when it gets instantiated to a particular building, the, the URI is then known because we know where the end point is.
The protocol is known because somebody would have configured it. And on the client, somebody would con would have configure the API key and the look and the, and the context. And so the connection profile then has all of the information that is in this case, just for
Very cool. Th this is kind of an interesting use case that I, that I've used to, to think about connection profiles. Maybe we can spend a couple of minutes on, is that. human to human contacts.
You have a contact database on your laptop or whatever computer. And it's a database that you maintain that you keep track [01:04:00] of. And it has my name in it, somewhere in it. Because you've emailed me, I know you have my name and your contact. I have the same. I have a a contact database and I have your name.
I have James Dyson in my contacts. So that is in point thinking. I have no idea at any given time whether the email address I have or the, the street address, which I know is not wrong because not that I know what it is. I have no idea of what that is. Because it's on your side.
And I have no access to it. A connection profile view of it. This. You don't have a contact database and I have a contact database. What we do is we have a connection profile that defines the relationship between James dice and answer right in there would be the information I need. So if you change something, it will be reflected on my view instantly and everybody else's view.
So that's kind of one way of thinking about connection profiles in more sort of human terms.
James Dice: So I would still need to say, Hey, I just moved. And my new address is yep. And I communicate that
Anto Budiarjo: to the broker. Yes, you do that [01:05:00] in whatever this affectional tool is, and that tells the broker and the broker will then tell everybody else that you have that relationship with.
The relationship is based on the connection profiles. And the broker knows all of the different instances of like, connection. I feel like the
James Dice: speaks. So you talked about integration in the past being like this end point thinking kind of manual process, like get two engineers from each side in the room and they create a project plan and go through all this stuff.
But you didn't talk about what happens to three years later when somebody changes something down the line. So then it's just this constant mess. And as we add more connected devices and more connected devices, it's a big spaghetti mess. So I feel like this speaks to the resilience and reliability and maintainability, and really just like making digital twins even viable from
Anto Budiarjo: a solution standpoint.
Yeah. That was part of my comment on [01:06:00] the dynamics part of it. But that's that's a great a great point that actually maintains the system as opposed to sort of a spaghetti or virtual spaghetti.
James Dice: Cool. So, so essentially what we could add in the future is that everything. I is actually plug and play people. People say, plug and play and throw that around that word around like, it's something that's happening all the time, these days. But what that can basically enable it
Anto Budiarjo: essentially. And, you know, I recall back to a debate.
I think you and John Betsy were having about the iPhone, how to make it as easy as the iPhone, this kind of mechanism I believe will get us there. And it should be if it's implemented widely and that's the vision, obviously the call to action is to invite people, to be part of this, is that everything will then understand how it can work with other things, the same way that your, you know, your Facebook app understands [01:07:00] how to work with another app that on your phone.
I don't
James Dice: remember where John and I ended up with that debate, but it's been a while since we've picked up, maybe we'll have to pick it up at IB con here next week. Well this, this episode will actually come out a couple of days after, but I'll be bringing that iPhone thing up with John. So where do you see this effort?
Like the open source connection profile effort. Where do you see this in sort of in context with things like haystack now that we're talking about John and other sort of. Standards and efforts that solve part of the interoperability puzzle, but not all of it. Obviously they're not solving what we're talking about here.
So is all of this going to converge into one thing in the future? Or what do you, what
Anto Budiarjo: do you think's going to happen? So I'm going to pull in the smartest stack to talk about that, because again, We have this exchange layer on the stack, which is where really where all this resides. So, so tagging [01:08:00] from a haystack and break records, not just styling, but that all exists in exchange layer.
And they both can co-exist, there's nothing wrong with that. And that, the date that the data does tag is all in the data layer, right? So it's kind of separate, right? The connection profile mechanism is an exchange layer, thin technology, right? But it's not concerning itself with tagging data is really the way to think about it.
It's actually tagging systems. You're tagging the IQ tagging the, the, the way it tax is different. It's not tagging the piece of the system. It's actually tagging its capabilities of talking to something. Yeah. So, and so connection profile which has a fancy name, it's actually called CNS CP connectivity, naming system connection profiles that sets in the exchange layer the same does any sort of semantic model does.
And so the way I see it working is that an app would say, you know, what's available for [01:09:00] me using this, this or these profiles and it will discover it. And then once those discovery, once those connections are established, it will then exchange data using Symantec Titans. Yeah. If it if it's if it applies or in some other cases, it may be completely proprietary because there's no reason why connection profiles can't be created to connect proprietary systems together, which is an intriguing kind of concept, I think.
Yeah.
James Dice: Yeah. So you think these, so the connection profiles open source effort, you think will be separate from haystack, which will be separate from other things in the future.
Anto Budiarjo: Yeah. Where, where we're trying to figure out where. Best be placed. I started life in the digital twin consortium which has been great from a, from an application perspective, application discussion and use cases.
That's really great. But it really needs to morph into real sort of open source [01:10:00] code sort of contributors. So we're seriously looking at Oasis as well as the Linux foundation as being the home for this. It's sort of intriguing similarities to Kubernetes. How well do you know Kubernetes, but Kubernetes orchestrates Vietnams and DM sort of components, right?
So that's what Kubernetes is. That's connection profile, orchestrates integration in much the same way. It's kind of a layer that sits on top of, on top of the actual work itself. Cool. Yeah. I believe Kubernetes has
James Dice: come up on the podcast
Anto Budiarjo: a couple of times. Cool. All right. So where does
James Dice: Patty sit in relation to connection profile?
So I think we, we talked about it a couple of times, but Patty, the company separate then connecting profiles, the standard different,
Anto Budiarjo: so Patty is Petty's cloud-based Aggregator of user interface. So if, if you, if you think of the, the, the alternative integration problems or the education products and all of the ones [01:11:00] that I've been involved with before and others, there's always two parts of it.
There's how do you integrate the UI? In other words, how do you integrate these different systems? So human being can consume it in a sort of organized way. And then how do you integrate or connect all the different systems together? There's always been the two things, right? So the connection profile is the latter is how the systems connect with each other.
So, Patty implements, connection profiles As part of what it does. The, the other part of Patty is the UI aggregation, and the UI aggregation in Patti is also different and very unique because we, we decided on the approach that we want to integrate, we want to do integration in the age of the internet.
So the way we're integrating the UI on the, on the, on the data side is we're integrating basically HTML UI, right? So if you have a system that provides HTML UI of some sort of dashboards or management tool or whatever that can plug into [01:12:00] Patti, Okay directly. And you can organize it.
There's lots of ways you can actually organize it then you know, make make one UI next to the next next to the other UI that normally wouldn't connect together. But because they are both in the lobby, you actually need both of them. So you do that. And so all of these are we think about them as.
So each system has an app. So with, with Patty, what you do is you install apps and you install apps at a particular context. So for example, in the building, you're creating a tree or ultimately you be able to pull in a bin database or I'll actually create the hierarchy of the building buildings, float rooms or whatever.
And then you would put an app pertaining to the a queue system in the lobby. And then the way you do that is you would install the IQ app on the lobby object and in it, and then it would know where it is, right? So the IQ app will then know that it's in the lobby so that when you then install [01:13:00] another app next to it or underneath it or somewhere, and you're installing HPAC app or a dashboard app, it will be able to communicate to the ICU.
App using connection profiles and Patty manages all of that. So all of these apps in the sort of complex hierarchy of a building can talk to each other, using connection profiles. And that's I go back to the, the, the words that I use, you introduce an ICU into the lobby, right? It will then say I'm here, I'm in the lobby.
Is there something, is there an HPAC system that can provide me a certain amount of data and they will do that. And the Patty will discover that the two should connect. It will actually connect them. It will actually instantiate connection, profile instance, exchange all of the data, all of that in a plug and play manner.
And then the user then has a single sign on single and consume all of that information maintain dynamic and everything that we talked about.
James Dice: So there's the ability to log [01:14:00] in to pretty much anything that has an HTML interface in the building
Anto Budiarjo: outside of. Yeah. And I'm sure a lot of engineers out there sort of thing I was asking, how do you deal with security and credentialing and things like that?
We've created an app framework. It's very flexible in terms of being able to accommodate different types of credentialing sort of requirements of different apps, different patients. So that's kind of how I would do that and all of these apps and up in the petty store, because. It's not an app store because I'm not allowed to use those words.
James Dice: I could see you're hesitating for those of you that don't see the video right now, Anto was about to say app store and he hesitated for like five seconds. There
Anto Budiarjo: it's a store, it's a party store. It's likely what it is. And, and so in the pedestal you can buy apps. I can say that. But you can also buy data to think about that, right? So if there's a, if there's some data in, in the data [01:15:00] layer that may be there because somebody has invested a lot of money to gather the data or for whatever reason.
And they actually want to monetize that we can actually use the Patty store and sort of the app mechanism to pay for data connection profiles. Very cool.
James Dice: I mean, what's striking me, is that now, now we're talking about as like the patties, the digital twin aspect of what you're talking about. So it's not just the broker, it's also the metadata as well. And the U
Anto Budiarjo: S yes, no data, no apps, no fundamental systems. We don't do any of that. And that's sort of, one of the interesting things about the smelter stack is that quite often I showed the smartest stack to somebody and ask them, you know, what does your product look like?
What does your offering look like? And the first thing they do is they drop vertical box. I'll do this, I'll do this, I'll do [01:16:00] this. I do everything. Keep the customer happy.
I think that's an old mindset. And so from my perspective, that is the delivery lab because we deliver all that to the users. The, the Patti store is obviously on the app layer and the connection profiles and the exchange layer. I'd say we have nothing on the data layer or anything below, and that's what other people do too, to bring their innovation.
Very cool. Well,
James Dice: people can check out the YouTube video for, I'm sure it will have a slide on where Patty and, and everything else fits. Anything we left out on, on Patty, I feel like there's a lot more than maybe we could dive into on a part two, but for time we
Anto Budiarjo: should should wrap this one up. I think that's a, that's a good.
Place to stop all of this, and we've been working on Patty for about three years. So the UI part of it is is pretty solid, the smarter stack.org, which actually has a library of smartest. I actually uses Patti. So when you go there, it allows you to log into Patty and you see all of the [01:17:00] libraries.
So that, that part is, is there the connection profile part as is relatively new, as far as explaining the, sort of the history of that. So we're working through that, but it is, it is functionally there and Patty as well. That's the way we are. We're in the process of going to market with this.
Cool.
James Dice: I'm sure you'll get people reaching out as a result
Anto Budiarjo: of this seems to me that the
James Dice: fact after the podcast, so All right. Well, this has been fun Anto, I'm glad we finally got, got this on the calendar and got it done. Thanks so
Anto Budiarjo: much.
James Dice: All right friends, thanks for listening to this episode of the Nexus Podcast. For more episodes like this and to get the weekly Nexus Newsletter, which by the way, readers have said is the best way to stay up to date on the future of the smart building industry, please subscribe at nexuslabs.online. You can find the show notes for this conversation there as well. Have a great day.
[01:18:00]
“I know people have different views on what digital twins is all about. I think that if digital twins are fundamentally an integration challenge then the most pressing problem is how to make things work with each other."
—Anto Budiardjo
Welcome to Nexus, a newsletter and podcast for smart people applying smart building technology—hosted by James Dice. If you’re new to Nexus, you might want to start here.
The Nexus podcast (Apple | Spotify | YouTube | Other apps) is our chance to explore and learn with the brightest in our industry—together. The project is directly funded by listeners like you who have joined the Nexus Pro membership community.
You can join Nexus Pro to get a weekly-ish deep dive, access to the Nexus Vendor Landscape, and invites to exclusive events with a community of smart buildings nerds.
Episode 75 is a conversation with Anto Budiardjo, CEO of Padi and collaborator on many industry initiatives and thought leadership that we unpack as part of Anto's long background in our industry.
We took a bit of a deeper dive into integration, specifically the challenges with it historically, how it's time for a new paradigm, and where are the open source connection profiles initiative fits.
Then we discussed how Padi helps enable what we're all needing, which is interoperability.
Without further ado, please enjoy the Nexus Podcast with Anto Budiardjo.
You can find on Anto LinkedIn.
Enjoy!
Music credit: Dream Big by Audiobinger—licensed under an Attribution-NonCommercial-ShareAlike License.
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 Dice: hello friends, welcome to the nexus podcast. I'm your host James dice each week. I fire questions that the leaders of the smart buildings industry to try to figure out where we're headed and how we can get there faster without all the marketing fluff. I'm pushing my learning to the limit. And I'm so glad to have you here following along.
James Dice: This episode is a conversation with Anto Budiardjo, CEO of Padi and collaborator on many industry initiatives and thought . Leadership that we unpack as part of Anto's long background in our industry.
Then we took a bit of a deeper dive into integration, specifically the challenges with it historically, how it's time for a new paradigm, and where are the open source connection profiles initiative fits. Then finally, how Padi helps enable what we're all needing, which is [00:01:00] interoperability.
Without further ado, please enjoy the nexus podcast with Anto Budiardjo.
Hello, Anto. Welcome to the show. Can you introduce yourself?
Anto Budiarjo: Oh, James. I am Anto Budiardjo uh, most people forget the Budiardjo part just know me as I Anto I've been in the building space for over 30 years and a bit, I've tried to escape a couple of times, but I'm still here. Yeah.
James Dice: Yeah. And you've been you've been a thought leader in the industry for as long as I can remember.
So first, thanks for that for the
Anto Budiarjo: leadership. I'm excited to
James Dice: have you on the show for Albury for that reason and for obvious reasons.
Anto Budiarjo: You're doing a great thing with your community, so really appreciate it.
James Dice: Thank you. Uh, Can we start at the beginning? How'd you get into the industry and what were you doing when you decided, Hey, I want to work in buildings.
Anto Budiarjo: Okay. So this takes me back to London, which is where I hail from. In the, in the eighties I was running [00:02:00] a computer software and dealership company back then you can actually sell computers, personal computers, or make interesting margin and living uh, writing software.
A lot of the work I was doing was around a thing called aperture cards, which are microfilm. Stuck inside a, an IBM 80 column punch card. So that's how they used to manage microfilms in the sixties, seventies and eighties. Unbeknownst to me, that was actually, it really is taught about metadata, metadata about the drawings on the, on the actual card itself.
So unbeknownst to me, I was doing metadata where before I understood what the word meant. So that was the seventies and eighties. And one day sometime in the late eighties a guy that I know a customer. Bought some computers have me pointed to this box that turned out to be an Andover AC 256, or something, and said, can you connect that to this other box, which is a trend controls, IQ, [00:03:00] something or other, I can't remember the model.
And I looked at it product around and probably around the back and went away and raised some red, some software and made them talk. And that then led to the creation of the, the very first integration platform that I built in 1990. But we went to market in the UK called the CDC engine. So that was number one.
And that's really what brought me into the, to the, to the building space. And uh, integration is really been sort of, connecting different systems together. It's really been mostly. Cool. So you've built
James Dice: that first connection and then decided it was a commercial opportunity
Anto Budiarjo: from there. Yeah, that that's number one.
And Patty that we'll talk about later is actually number six. So there's been sort of others along the way. And and I, I just find the. notion of lots of different systems in the building and being [00:04:00] able to connect them to each other so that they can create some additional value. I just found that whole notion really, really interesting.
And even back in the late eighties, nineties, the concept of doing that so that you can extract business value and connect it to an enterprise information and other sort of retail information and things was always there. Although the older sort of things were being discussed, obviously the technology has changed a lot.
So it's kind of interesting to see people wanting that. And after 30 years, I, I feel like we're starting to get there in terms of the ability of, of an industry to understand what needs to be done and to actually start doing it.
James Dice: 30 years, 30, quick years, or almost there. So CDC engine was number one, Patty, which we'll talk about as number 6, 1 2 3 4
Anto Budiarjo: 5.
What happened in between um, number two as a project that we did with IBM in [00:05:00] the UK to monitor as 400 mini-computers in, in what they call dock sites, which are just in the room. And number three was something else that I did in in, in Europe. And number four was a product called you didn't have that then got acquired by CSI.
Then it became TAC and then now Schneider electric. So that's the, that was the time that I came over and a couple of other projects in between. I worked with helper to help him on some of those sort of middleware stuff that he was doing. And that takes us all the way up to now with Padi.
James Dice: Awesome. Alper Üzmezler at the BASSG
Anto Budiarjo: There's only one Alper.
James Dice: There is the only one out for everybody knows that. Alper just wanted to make sure that for anyone that doesn't know, we uh,
Anto Budiarjo: call them out. What cool. All right. So
James Dice: we'll talk about Padi hearing a little bit.
I think I'm wondering just like beyond, we're almost there. Can you reflect back on all of [00:06:00] these, these are all integration efforts, right? That's kind of a common thread in your careers, connecting devices. What was it like at the beginning? And then what's it like now, I guess,
Anto Budiarjo: Well, just as the concept of middleware wasn't really well understood.
And it was middleware that we were building back then. And back then it was all about using our ports as a way to connect to Andover and train and other other systems. And I was actually listening to a podcast of yours talking about API APIs and sort of the problems we have with API APIs API is reminds me a lot of
Back in the eighties and nineties, because my business partner will talk to somebody. And, you know, after about five minutes, the light bulb would come on and say, ah, yes, I have an RS 2 32. So he should be able to integrate it, right? Yes. Well, it depends on, depends on the configuration and it depends on protocols and stuff like that.
So [00:07:00] API is to me, the modern day equivalent of RS, 2, 3, 2, everybody has it. And they are wonderful, fundamental. They are wonderful, but it doesn't in itself answer all the problems. So it's kind of interesting how, that kind of thing, sort of repeated itself over the years and it's moving
James Dice: higher up the stack, same problems.
Anto Budiarjo: Yeah. Interesting.
James Dice: So what are you up to today? I have this list of all the things from, I always crepe on everybody's LinkedIn profile, but you're, you're currently doing a lot of stuff. So there's Patty we haven't talked about Monday Live deck what's what's Monday live for those that don't know.
Anto Budiarjo: And how'd that get started? Okay. So, Monday life is, is a, is a child of the pandemic, basically when back in March, 2020 when we started to go into lockdown, I remember standing in the, in my back porch as I was listening to the fact that Italy as a country was going into lockdown, I thought this [00:08:00] is crazy, right?
And this is going to come to the U S at some point or some variations on that. And I was kind of. I couldn't, I couldn't figure out what to do with that information. And so what I decided to do was start a zoom call on Wednesday evenings, happy hour time with a whole bunch of people that I know a lot of people that are now Monday live.
And so we, we started this weekly chat Wednesdays with with a beer in hand and just trying to sort of help each other, get through the understanding what the pandemic was all about. And you know, initially it was like, you know, I do I go shopping and all that kind of, sort of more like life stuff.
And then we started to think to, to use that sort of conversations, to think about what smart buildings, the relevance of smart buildings in COVID era. And that kept on going on a, on a, on a weekly basis. And after a couple of months of that, we kind of said, Hmm, wouldn't it be interesting if we took this format as just us [00:09:00] chatting and put it in front of the public.
Alright. So that's basically how Monday life got started. A couple of weeks after that, we decided to do it on Mondays at three o'clock because it needed to have a regular cadence. And that was Monday live. It started there. And we've been going ever since every single week, other than some holidays and stuff, but basically we're a, that that's our format and it sort of evolve initially.
It was about having to deal with pandemic. Then we started to think about what is this industry going to look like after the pandemic, and obviously this year sort of, that's where I think we're starting to get out of dependent. We're starting to think about what the reality is and, you know, and we discuss all sorts of things, including like supply chain problems is going on right now that other vendors are having.
So it goes, it goes in sort of many different directions, but that's really the thesis of it is just having conversations about it. Really [00:10:00] cool.
James Dice: And I've been a guest a few times. It's fun
Anto Budiarjo: to
James Dice: get into. I got interviewed by like 12 people at once. That was, my experience was like, oh wow, these questions are coming from all over the place.
So I think it's fun to get all those different perspectives each week. That's really cool. And those are on YouTube. People can go back and watch those.
Anto Budiarjo: The single ones on YouTube Monday live.org is where you go. You can register for the live sessions and there's a link to all of the YouTube videos.
James Dice: All right. Next next bullet point on your LinkedIn profile, a digital twin consortium. What's what's that all about? And what's your,
Anto Budiarjo: what's your, so, so I've been monitoring the concept of digital twin for, for a while. I think a lot of us are kind of intrigued with the, sort of the concept. The digital twin consortium got stood out.
I got, started roundabout that time, the spring of 2020. And so I saw an email or a post or something about it. Then there was [00:11:00] soliciting membership and I joined him. Partly because during that time I was, I was trying to sort of figure out what, what to do with the time and they loved him and I wasn't traveling and all that kind of stuff.
So I joined and it's actually been quite an interesting journey with the digital twin consulting. It's a pretty. Pretty awesome group of people. It has big big sort of hitters like Microsoft and Autodesk and GE digital and cleanliness and, and others. So there's a lot of sort of conversations about digital twins and they, they actually break it down into different vertical working groups.
So there's a, there's a working group on infrastructure, which is the one that attracted me most that talked about intro of infrastructure and buildings. And then there are others to do with aerospace, for example, and manufacturing. But that, that's kind of, that was the start of that. As part of doing that I kind of realized that digital twin in many ways is nothing but a giant.
Integration problem. [00:12:00] We're not talking about the systems in the building anymore. We're talking about all systems, whether it's smart cities or transportation or whatever, it's actually the same problem. You have all of these different systems that need to inter interact with each other, um, And that's roundabout the time that we were sort of working on the connection profile stuff, and I know we'll come back to that.
And so I decided that, that I wanted to inject that into the digital twin consortium conversation as a way of solving that particular problem or the integration problem in that space. And and in the process of doing that because the digital twin consortium is an open forum, right?
Everything has to be open. We, it kind of, accelerated us putting the connection profile mechanism into open source. So we're still working through that, but that was kind of the decision of actually taking the connection profile mechanism, putting it in the open source so that anybody can [00:13:00] ultimately use that mechanism to do integration.
Okay. And it's, it's continuing and it's continuing. And then there's sort of other interesting stuff that's going on to do with system interoperability, which is the focus right now in the DTC and some other interesting stuff. That's sort of a little bit sort of futuristic, such as I'm thinking about things like trust.
Okay, so your you're integrating, or you're connecting to some device that gives you a number of 75, you know, it's degrees because you have haystack tags or whatever, but how do you, how do you know it's actually coming from the sensor, but you think it's coming from right? What is the history of it?
What is the Providence of it? And why should you trust it to actually make a decision based on it and
James Dice: people, a bunch of potential competitors, but also building owners, it sounds like developers coming together to sort of solve these sort of common [00:14:00] problems to do with digital twins.
Anto Budiarjo: Yeah. Cool. Yeah. Yeah.
In different disciplines, which is, which is interesting. I I'm trying to get to my lane as it were, because you can get very easily distracted to go into aerospace and stuff like that. It's very interesting. But you know, ultimately the issue is the same, so right.
James Dice: Very cool. Yeah. I would have a hard time with that.
Pull into radical curious, curious people have hard times with digital.
Anto Budiarjo: You can be involved in those discussions and sort of, listen enough and contribute enough to know that to, to pick up the sort of commonalities right there that you can then say, okay, we can, we can apply the same technology this differently sort of way.
So it's a, it's a good way to expand the use cases.
James Dice: Okay. Last bullet point, the Coalition for Smart Buildings.
Anto Budiarjo: Yes. So that really came out of Monday live. So, towards the beginning of this year [00:15:00] after Biden got inaugurated there was obviously, and there still is a lot of discussion about what Biden's going to do with respect to climate policy and other sort of policies.
And so, Rick justice, I know, I think, you know, him and Pete Scanlon there've been there. They obviously work together and they've been sort of contemplating creating some kind of coalition, right? So they approached us and, and, and Monday live and when we had several discussions about it and, and they, they were very focused on states and local governments and persuading them or influencing them.
And we thought that was kind of interesting, but it wasn't sort of enough at the time. And an interesting thing, but we couldn't see how it could get traction. So we talked about it and, you know, mulled upon it for a couple of months and then. In may I think as many of may or June we got actually John petsy got an email from Jessica Grandison who formerly from Lawrence Berkeley national labs, and she's here.
She has just taken a position at the white house or the CQ, the cow's council for [00:16:00] environmental quality. And she was reaching out basically to, to seek help. Knowing that she having spent a lot of time in LBNL, she obviously knows all of the gap and all of the sort of Dr. Related stuff.
But she was basically saying to make this really impactful we need some additional help. We need to sort of understand how to address policy issues and regulations that can actually. Enable smarts in the building. And that was her ask. It was a pretty short ask and we then sort of looked at this and brought it in again with discussion with recompete and we decided, you know, this changes things a little bit right now we have the white house involved and, and, and other sort of place in DC.
So we stepped up and we put together a six page proposal document that basically laid out how we think all the, sort of the big issues that need to be dealt with from a policy and [00:17:00] regulation, including interoperability, analytics and some other stuff that we can go into. But and out of that, we, then that sort of then became the starting point of the coalition.
And and that's what the coalition is. We've now had two face-to-face meetings in DC, one in August and one actually just last week making a lot of progress talking to a lot of sort of DC people. It seems that we've sort of captured the, the, the essence of a really, really interesting topic that a lot of people in DC needs to understand and need some expertise.
And then we basically a sort of being appointed by ourselves, I guess, as a group of people that can contribute to that stuff. That's, that's the coalition for smarter buildings
James Dice: I like that we've been appointed by ourselves.
That's fair. That's fair. And I saw Elsa saw Kara Carmichael. Who's been a guest in the podcast. She just took a job at the CEQ as well. They're putting together quite the team over there. She's from [00:18:00] RMI net zero expert. So
Anto Budiarjo: very
James Dice: cool. All right. Let's, that's a lot to
Anto Budiarjo: be involved in Canto. Okay.
James Dice: All right, I'll cut it off. There that's enough context of what Anto is up to these days. So one of the things that you guys have developed through the Monday lab conversations is this smarter stack, smarter stack, not smart stack, smarter stack concepts. How did this come about? And before you talk there, For those of you that are listening on audio, we're just going to talk through this.
But this is the best as a visual tool. It is a visual tool. So we're also going to put a little demo, a little screen share on the YouTube version of this podcast that we'll put in the show notes as well. So this will just be audio, but then we'll, we'll, we'll add the video back end.
Anto Budiarjo: So let's launch into this. So what is, what is this all about? Where. The sort of a extremely high level. We know that there are users, there are as human beings, we occupy, we own operate them.
Otherwise we consume buildings, [00:19:00] right? And at the other end, we have the buildings and we know that there are controls and automation systems somewhere in the middle, there are some smarts, right, which are technology and services to, to make the building smart. That's really the, the, the, the, the, the mission of this whole industry.
And we also know that the smarts is generally speaking, made up of two things apps that actually do the computation and analysis and, and display and everything else and the data those are kind of the two really, really important parts of being smart. And we also know that in these sort of four layers users, apps, data, and building.
Also sort of describe the needs of those in a very generic way. So we know that users just need to consume the building. They just need to make sure it's safe and healthy and productive environment. The apps, if you're an app developer, you just want the app to be delivered to whatever user you you know, that your function is designed for and to get [00:20:00] data for that app to be used.
And the data needs to be there. It needs to be gathered, needs to be secured. It needs to be available to applications that need it, then the buildings just need to operate. Right? So we kind of understand the components and their needs. So the smarter slack starts to do is to start to sort of build on this and to make sure that the.
These the, the value flows, the value of the smart flows all the way to the, to the users. So the first realization that we had is that there's really sort of, not one group of users. You know, they're ultimately, there are many different types of users, but if we if we, if we try and split it into sort of broad groups based on their, based on their needs there's really two, there are those individuals or people or organizations that are interested in the purpose of the building, right?
So here, we're talking about building owners that whether they want to make profits or operate a hospital or whatever, the managers, meaning sort of store managers kind of, [00:21:00] individuals. Okay. Me going into a shopping mall and wanting to buy a pair of shoes. That's, that's me. There's a purpose being, being always being in play there with, with these types of users.
And then there's a second group of people that are more focused on the operations of the building, thinking about facility managers, maintenance, people, even janitorial kind of services. So they, they actually make the buildings be ought to be able to be consumed by those that actually wanting the purpose.
So that's kind of one realization. The other realization down down here is that from a buildings perspective, there's the physical part of it. And then there's the automation part of it. They're very different. They have different dynamics, different life's lifetimes et cetera, et cetera. So we separated those two out.
I think that's pretty obvious to people and in the smart. Part in the middle pop we basically split it into four. We said right at the top, there is a delivery layer, right? So this is talking about how the smart is being delivered to the users. So this [00:22:00] could be talking about an organization such as system integrator or a managed service provider.
Or it could be talking about technology. So it's a single pane of glass and, and mobile apps and other things. So there's kind of a delivery layer that's needed for the users to consume everything underneath it. Then there are the apps probably the best understood. So I don't need to spend that much time on that.
And then the, the other sort of new layer that is added to make sure everything works together is what we call the change. We've actually had new bed, various names for this, but we settled on the exchange after, after a while. And this is really a layer where things a layer that makes everything work.
So things like middleware. And things like haystack, semantic, tagging, and other sort of integration tools, as well as products and companies sit here in this, in this exchange there. And then we have the data layer and that's all to do with the data. How do you, how do you gather it? How do you store it?
How do you normalize it and do your governance to make sure [00:23:00] that only the right people can use it? So this is basically the smallest stack, this, this eight layer stack. That starts with purpose going all the way down to the physical layout of the buildings. Those of you that read the Simon Sinek know about this concept of starting from Y the notion here is the a lot of people when dealing with tech really focused on the word.
Right. As we typically do the writing the application and doing the data management and everything else, but really to fully understand the whole system and how to deal with it, you really need to start with a why. And this is what the purpose is all about. Why is this being done? Why is this meeting the spots as small as being, being done, and then does the, how, which is how it's being operated, the house, they live house being delivered, and then everything else, the Watts, right?
So this sort of maps, so that sort of Simon Sinek view, which is very interesting. So the way we see this smart suspects being used is that we use it as a backdrop. So a lot of words, if I'm [00:24:00] trying to explain product X, I just need to put it there. And we'll automatically know that it's. Right. We don't know at this point what app it is, but we know it's an app and the technology down here would be data.
So we understand that then even sort of companies, right? So this is how the tool has to be used and you'll see quite a number of of this. So one of the first things we did is to actually say what's really going on in the industry right now. And it can really be encapsulated in this one slide what's happening is that we're moving from a a sort of a model and an industry model of vertically integrated BAS offerings where the systems meaning the control and automation system is within the same offering as where the data is stored and where any data exchange is actually being done.
Typically everything's happening inside the boxes sort of proprietary. And then the apps are also proprietary. And so inside the box as well, and even the delivery is proprietary. If you think of the, the, the, the major companies, they have branches and they have channel, those are sort of delivery mechanisms, as well as [00:25:00] supervisory sort of applications.
So all of that is in a box making it typically is proprietary. Most cases are proprietary making it difficult to go. Except go out of the box and making it difficult to come into the box. So this is why integration is so hard with these kinds of systems, because it's not designed to be integratable.
So we're moving into this. And also on the, on the owner side, on the building side, typically the purpose and operation is incented done by the same group of people. We're moving from this model to a model. And this more like this, where everything's all split up and this is how the internet works, right?
So there are different purposes for owners and occupants. There are different entity is the operating the, the facility. There are different delivery mechanisms, technology and companies, and there are different apps and different exchanges and different places where data can be stored. Right? The only consistent thing is that the building itself 1, 2, 3 main street, right?
So this is kind of a one way of using the. I'm just going to quickly go through a couple of slides just to throw up some [00:26:00] concepts. This is just we brainstormed one of the Monday life planning sessions. Talk about all of the different categories that or different product type that is our space.
So something like energy management this year and the apps something like weather data is obviously data, data warehouses. It's in the data lake. I think like FM and IWMS applications or apps maintenance, genital, et cetera, et cetera. You see the sort of the full range here. One of the interesting things is somebody at some point said, where's connectivity.
Where does networking fit into this? Where's the layer for that? So one thing worth pointing out. This is not a network layer. This is not a technology layer. So there is no network layer, but this is not a technology stack. So there is no network layer. It's really a sort of a business value proposition, supply chain the stack.
So connectivity in a way is its own. Right. Because if you think [00:27:00] about connectivity, there's a whole bunch of purpose related sort of things you can say about connectivity. You need bandwidth, latency, reliability, et cetera, right. That's, that's kind of where you typically start. And then you have know different ways that you, you execute that.
And then you have applications like software defined networking, which is really an application. Then you have the data, meaning things like SIS logs, they're all kind of communication related data. And you even have physical things like antennas and cables and. Right. So those are all communications attributes, right?
So you can actually create multiple layers of stacks to deal with different things. Security is the same as well, because there is no layer for security, right? In a way it's a vertical saying, so you have purposes as well as security, defense, defense in depth and zero trust kind of things. And you have physical things.
So conduit protection is a legitimate cyber security thing to actually protect the conduit from, from being accessing the. [00:28:00] Right. So you can actually have different layers that sort of, start to draw the picture the other way to think about it as you can use the the, the smartest tack to describe the requirements, right?
So this is a fictitious high school requirement, right? Imagine myself sitting across the table, across the zoom, where they Sue a school superintendent or senior engineer or whatever now describing what their needs are. They need scheduling, they need comfort. They need some social interaction, principles, safety.
As far as operation, they would like a school. They would like a dashboard. Then they have an engineer on site and they would like to have CCTV monitoring as part of their operations. And in terms of delivery, they liked the MSP model. Let's say, so this is where it goes. These are the different apps that it is from the exchanges different where, where data is stored.
And these are the different systems that have in these other different buildings that have, so you could actually see. Just buy this one, buy this stack, you, you, you start to build a picture of what the requirements are very, [00:29:00] very you know, clearly now you obviously need to use this to create specifications and other things beyond this, but this is really sort of a great starting point.
One thing I want to comment on the use of the smartest stack is the perspectives matter. The stack looks different depending on who you are, if you're a building owner. If you think about it, ability known thinks about the purpose of why he, why he or she has that building. Right? And he cares about the operation and the lower down it gets on this stack.
The less he kind of cares about anything. Whereas a middleware kind of person would think about it from the exchange perspective, because about how the data is being used and how to get at the data and maybe how to communicate to other middleware. Right? So depending on where you are, you have different perspectives.
These are different standards and technologies. Again, this is rough and I don't want to spend too much time on it. And what I want to do next, where I want to get some time for some [00:30:00] discussion. I want to show two examples. One is an example of actually my company, Patty, of actually using the, using the stack to explain the product, right.
And then we'll, we'll go to another example of actually using a on a real site. So this is a Paris my company, and this is our smarter slack to explain what we do during this to, you know, as an example of how to use the smartest slack we have a Patti store where you can buy app.
Right. That's kind of the way it works. We don't create any apps. We provide a mechanism for all of you guys to create apps that can then go into the body store. And Patti itself is is a cloud based platform. So it sits on the delivery level. What we do is we, we, these are kind of the purpose of using Patty single sign on creating dashboards and collaboration, et cetera, as kind of, and we're using this another convention of the spotter stack is we using the solid box to indicate what we do in this case, Patty, our offering, and we're using the dotted line to to, [00:31:00] to say, this is what we expect other people to do.
Alright. So these are what we deliver in terms of the operation. These are the people that are going to use the product that we expect to use the products. They obviously did not ask. They're all dotted and the delivery against system integrators and consultants. They're the, they're the the type of people.
And these are the type of technology that we enable using using Patty. And on the other side or Patty, there's a thing called connection profile, which is an exchange layer. It's a system to system interoperability mechanism. So we then work with different it kind of standards. And we enable protocol and semantic standards to to work through this this, this mechanism, the data from our perspective, we don't care where it is, the systems.
We don't care what they are and the buildings, we don't care what they are. Right. I mean, we care a lot, but we, it works. It's designed to work with multiple scenarios. So that's kind of one example. The other example, and that I jumped into is like, fire station. This is actually created by [00:32:00] Pete who I don't see on the call here, or you hear beat.
And so, this is done retrospectively. So this was actually done three years ago. This was the original sort of document to describe the goals and what the pieces are and what Pete did is to put it on a stack. So this is what it looks on the stack, the smartest five station. This is the base fire station.
These other, the the objective that they had, the purpose they had, these are all the different pieces of. Of, of that the different areas of that fire station. These are the different systems that are involved. There's a 75 F system that is that is displayed here. That goes all the way up to the apps layer has faced.
It uses haystack and inside of it there's an EMS system. That's put on the other side and it uses Vultron which is sort of, focused on the data and exchange layer. And, and it has an FDD app that's using Skype. In the stack anyway, and the delivery, there's a, it's a direct channel delivery.
And [00:33:00] the, in terms of the interfaces, they this has done using a single pane of glass and this is how the operations is done. The city does most of the FM operations and the sort of management, right? So this draws a sort of a really clear picture of what's what's going on.
James Dice: So how did
Anto Budiarjo: this come about?
So, going back to the, sort of the conversations we've been having for the year and a half, but in Monday live, a lot of those discussions have been. Trying to rationalize all of the different technologies, the products, the companies, and the people involve and coming in and out of this of the industry.
And it gets very, very confusing, very, very fast because people are coming up with all sorts of great innovation. And in a way, a lot of the Monday live discussions is trying to organize that trying to organize the initiative now and our sort of minds. So we had the notion of, we had the notion of creating some kind of business stack quite early on in the middle [00:34:00] of 2020s, but it didn't sort of, hadn't sort of jelled and sodas kind of just sort of work this way through it.
That's one of my things about this kind of conversation with the group. You can sort of pick things up again over again and again. And so when, when the coalition started to come together this year spring early, early summer we now had the coalition as a sort of a potential vehicle to channel some kind of messaging about how to structure something.
So we thought let's take another look at the other stack that we're working on. So with, we picked it up again and talked about it. Made some changes. There's one of, one of the layers was not there. And the original one, it's actually very, very important. It's actually the top, most layer we didn't have top most layer.
And the top, most layer is actually the most important layer. It's the layer that says purpose, you know why you're doing something right? Simon Sinek, so talks about we'll focus. Typically we'll focus on a [00:35:00] watt all the time. He advised us to think about the why you're doing something and how you're doing it.
And then now talk about the watch, right? So the top layer is kind of the why. And so, we brought that into the conversation and we now have the stack, right? So the stack is eight layers at the top is purpose. And then underneath that, so purpose is kind of the building owner or a, an occupant or a school teacher or you know, somebody that actually.
Has a purpose in terms of their relationship with the building, they need something out of it. So that's the top layer, the second layer there, below that as the operations layer. And these are the technologies and the people with regards to operating the building on a daily basis. Right?
So facility managers, energy managers from a bank tenants people as well as janitorial and everything else. So that that's all on the operation. And then underneath, that is what we call the delivery layer. And this is kind of a a new concept. And it's really about how the smarts are delivered to the [00:36:00] operators and the purpose driven people.
And here, we're talking about system integrators and the people that actually work there and those kinds of companies, but all also delivery type technology. My company, Patty is a delivery type technology. So that's where it would go. But there are others. Mobile is essentially the same thing down the road.
AR and VR are sort of delivery technologies, right? So that's the delivery layer underneath the delivery layer. There's the apps layer. That's probably the one that we know the best. We understand that analytics and management tools and all this sort of stuff that people are developing. So that that's pretty easy to think about.
And underneath that underneath the apps layer is the layer that we call exchange. And that's really the layer of middleware. That's the layer of using technology to translate data, to make data able to be used by different different apps or different tools. So we call that the exchange layer, the [00:37:00] connection profile technology that that we created, this fits in there.
And then underneath that is the data there, which is really your independent data layer. That's what you talk about. So that is just the data layer of the smarter stack. But the way we think about it is not only does the data layer need to be independent, but so, so are the other layers need to be independent.
They changed Mister, be independent from the data and they changed needs to be independent from the apps and the apps it's independent from each other. So each of the, each of the layers. Independent, and if they are independent, then you can get composable sort of systems mix and match type things that can address whatever, the, whatever the building owner occupants need, which is right at the top of the purpose level.
So those are six levels go up. So, purpose, operation delivery apps, exchange data, and then at the bottom are the two layers of one is the systems, which are the systems, the HV systems and the control systems. And then right at the bottom is the physical, which is the actual building itself, the concrete and [00:38:00] steel that actually makes a building.
So that's the whole stack and the way we use it is that we, we use it to, to explain things, right? So the same way around saying Addie is a a delivery layer. Something like sky Spock from John's company as a, as an Appalachian. That's pretty easy what that is. And no no van what Andrew and the Frank is doing is a data layer thing.
Brian, it's very easy to think about it that way. And so you, you use that and you can also use this as a sort of to, to explain products, but you can use it also to build requirements, right? I need this, I need scheduling. I need critical emergency management. If you're doing schools or whatever, then you can then build out that requirements all the way down to the bottom. And then you can start to think about how the, the, the different pieces of the technology and products can, can interact with each other to make the whole thing, deliver the purpose. That's desired. So it's really a communications tool, quite quite a few engineers sort of, have problems with it [00:39:00] because you compare it to something like the network layer where everything's has very sort of very specific place. The smartest stack is really more of a communication tool. So you can actually have discussions about whether something, something like haystack, for example, is that an exchange layer or isn't that in the data layer, and there's actually different parts of haystack that haze that tagging is really in the, in the exchange layer because it enables things to be exchanged. But data that is tagged is obviously. So there's kind of different perspective and you can start to split those kinds of functionalities. It's been very, very powerful, and we're starting to build a library of a smarter stack because people are creating these it's going to be available on smarter stack.org which is actually hosted on using Patty to actually show it all.
But it, it's, it's a really, really interesting tool. And whenever I hear somebody trying to explain the technology, I try and sort of bring up the smarter stack and sort of imagine where they are, because that would at least clarify it for me as a listener. So, [00:40:00] yeah, very cool.
James Dice: I feel like, so I watched, I watched you there, your webinar with Memorial and I've watched a couple other of your demos and what, what I feel like it's like underneath this is kind of a new way
Anto Budiarjo: of.
James Dice: Developing a technology stack. You know, I know it's a business framework. I know it's a communication method, but one of the, one of the slides you showed in the Memorial webinar was this approach versus a full, the full stack approach of yesterday where one provider would provide the entire thing up and down.
Can you talk about like the difference in philosophy? And it seems like this is like the new, the new way of
Anto Budiarjo: doing. Yeah. So if you, if you think about traditional BAS offerings, I'm not going to mention any names because it applies to all of, all of the companies, what typically have a control system, which is down on the system level [00:41:00] right.
Of the stack, they would have some kind of data management on their, on their platform. So they're part of the data the, the data layer Probably we'll have some kind of exchange mechanism proprietary, or they may use a gateway to extract stuff from external. So that's the exchange layer and they obviously have apps, that actually is kind of whether it's configuration apps or analytics apps. So part of that, and then they also have a delivery layer, the big companies have branches as delivery tools in terms of how, how all of that stuff gets delivered to the user. And they have delivery technologies such as supervisors sort of, vendor specific supervisor.
So that is what five levels of the stack. And you basically put a box around all of that five because that is the vertically integrated solution. And what that means is it works really well inside because it's all done by one, one company, or maybe a very, very small ecosystem, but it's really, really hard to break out of it.
And it's really, really hard to [00:42:00] break into it. So when you want to integrate into such a system is typically hard because everything is inside. Everything inside the box has been configured to be proprietary. And it just works the way it. Yeah. So that's a vertically integrated sort of solution set.
And when the, the sort of the alternative way, and I think this is what you're talking about, the sort of the, the paradigm that we're moving into is. Each layer can be separate companies and separate technologies, right? So you can have systems that are just doing the controls and then the data, the data layer, you call it independent data.
Great. That is independent from the system, but it should also be independent to how it then gets used above it. So they change could be changed a bit different. It could be anything from a middleware thing, like, Niagara to you know, haystack and whatever, right? So you can use whatever you want.
And the applic applications can then also be [00:43:00] composable be sort of pluggable into each other. And then again, separating out the live delivery because things the smarts needs to be delivered in different ways, depending on what they are, depending on what the billing type is, depending on all sorts of different factors.
So you can actually split all these layers apart. And then you know, the, the, the one other comment. People often say, is that doesn't the owner just want one person to supply it, right? Yes they do. But the owner sits at the top of this layer. The owner typically works with the operator, he or she, or they care about the operations.
And they care a little bit about the delivery, but the deeper you get in the stack the less they care. Because they really care about the top stuff. So as long as it all works, as long as all the layers work with each other and they're all independent he still has he, or she still has one vendor, one service provider, maybe on a, on a service basis as the delivery or as the operations layer.
So we [00:44:00] take somebody like JLL, they're more sort of in the operations layer or a system integrator would be. Yeah, it will be on the, on the delivery layer now, just so you still have that mechanism of, of the getting, making sure that you, you get what you need. But it's composable and it makes it much more flexible.
Cool.
James Dice: Yeah. And what I, another thing that I, glean from it, when I, when I watched you talk about it is the, if these fully integrated companies were meeting the needs of the top layer, the why there wouldn't really be a problem with that, but those needs those why that top layer that's evolving and expanding.
And like the people that are needing smarter stacks, their needs are evolving and leveling up all the time and it's getting more and more and more important. And those integrated stacks, like you said, you can't pull anything out, you can't pull it to the new thing in. And it's just, it could becomes a [00:45:00] point where like you better meet the needs or else it's going to get disintegrated to something that can meet the needs.
And so I feel like that's the underlying message and I don't, I don't feel shy about pointing that out.
Anto Budiarjo: It's more that, that it's not in any way that they're bad companies or bad people, not at all. So it's kind of, the industry has evolved into that being the, the best way in the, in the past two or three decades.
So delivering I think we're going into a new a new phase where there are different ways of delivering it. And know, I, I sincerely hope that the big companies will sort of figure out a way that they can add value to this new world where things are split up. Totally. Me too.
James Dice: Hey guys, just another quick note from our sponsor nexus labs. And then we'll get back to the show. This episode is brought to you by nexus foundations, our introductory course on the smart buildings industry. If you're new to the industry, this course is for you. If you're an industry vet, but want to understand how technology is [00:46:00] changing things.
This course is also for you. The alumni are raving about the content, which they say pulls it all together, and they also love getting to meet the other students on the weekly zoom calls and in the private chat room, you can find out more about the course@courses.nexus lab. Start online. All right, back to the interview
Let's shift our focus to integration
Anto Budiarjo: platforms.
So
James Dice: that's honestly what you're developing now, right? With Patty. You've been thinking about integration for a long time. Let's talk generally first about sort of what's been missing from integration platforms. Why, why is integration so hard?
Anto Budiarjo: Historically. I opened up this interview explaining that integration has been my, my life.
But the more I do this, the more I realize that that's actually wrong because integration is an act of integration, the act of integrating things, right? So you are a system integrator and what you do is you make systems work with [00:47:00] each other. And those systems are inherently designed not to work with each other.
So that's why you integrate, so that's why it's hard because the, the systems that you're trying to integrate were not created to be integratable. So integration is actually the wrong word to use. Same way as smart as the wrong. Sorry, a smart, that's the wrong word to use. Now we're moving to smarter.
Integration is the wrong word to use. The better word to use or to aspire to is actually interoperability. we know how to interpret with you works, we know backnet devices can just plug into each other and the inter operates, we don't think twice and things like USB and other things that in our lives inter operate really, really well.
And with Symantec tagging haystack Braco Symantec and other industries you're able to inter operate within one domain typically right at the. Okay. Great. So you have interoperability at the protocol level, a physical level, and then you have interoperability at the semantic level.
What that [00:48:00] does not exist is interoperability at the system level. The concept of that is I should be able to introduce a system into a building. Let's say there's a building HPAC lighting, blah, blah, blah. And the, like, I should be able to introduce a, an IAQ or a people counting technology into that, into that building.
And into the twin of that building. And it should, it should be able to say, ah, okay, I understand how to talk to that. I understand how to talk to that and it should just work. So, I'm actually doing a podcast next month with a DTC called all about system interoperability. So I think that's what we should be targeting.
That's what we should be aiming at to make systems into operate each with each other. The stack provides us actually an interesting way of doing that because each layer is typically a system, right? The, the, the data, the data, or maybe multiple data sort of pools those are all systems, but they all need to interoperate [00:49:00] with each other and with a change layer and with the apps.
So they, they all just need to work with each other. And that's what I think that's really the, the main problem with integration. It's it's, it's, it's the wrong word. It's the, it's the wrong task. Totally. Yeah. That,
James Dice: that it should just work feeling. I think a lot of people have that feeling. Can you describe what has to happen?
Because say you're plugging in an IQ sensor because it doesn't just work at this point, what has to happen? And we spend in my course, which I'm in the mindset of right now, because we're in the last week of it, but we spend an entire week of a six week course talking about all the ways in which this process goes wrong.
But can you describe like, what has to happen in the case of an IQ sensor or the case of a new air handler controller being put in or whatever you want to talk about? What's the
Anto Budiarjo: current process. Well, the current process is what I describe [00:50:00] as end point thinking, okay, if I'm, if I'm an IQ system and I need to introduce it to a building, I know, I know my, I know my system. I know I'm an engineer or the IQ system. I know what my capabilities are. I may have API. And I'm being introduced to a building. I have to somehow figure out where I need to communicate with right. It could be a Metro system or it could be a Jace or whatever.
So I have to figure that out right manually. Then I have to figure out what protocol I need to use. What API is. I need to use, what keys I need to provide. There's a lot of metadata that is. Purely to do with communications. And I need to know where they, what API end points are. I need to know what protocol they talk to, and it needs to know that I'm legitimate user using keys and other stuff.
Then there's a lot of a lot of interaction about the context, I'm really only interested in IQ in the lobby, for example. And so I need to tell it I'm really interested in the lobby, right? [00:51:00] So as I think about it as end point thinking is because I can only do that from my end, from the ICU.
And you may be the HVC system or contractor engineer, so you are looking at the. From your endpoint I can provide and to an API so I can communicate to you, but it's all your perspective so you're thinking about your endpoint, I'm thinking about endpoint, everybody's doing the same thing, right?
And the only way we can communicate is if we want to one one-on-one agree, which ones that is, some standardization on somatics obviously helps a lot with that. So that, that is what makes it hard. And this is sort of a good segue if you're okay with that, into what connection profiles, all of that.
Because, because connect can profile turns that upside down, right? Because connection profile, isn't a profile about an end point. It's not, it's not a profile about media IQ or you the AJC, it's a profile about a connection. A connection of in this case, how I, and I, my boy, [00:52:00] how an IQ system talks to an HPAC system.
So what you do with connection profiles, you take that use case, right? Of which that I'm sure there's going to be thousands. If not millions of instances, that projects that needs that, right? You take that, that use case of why an IQ system needs to talk to an HAC and you codify that in a connection profile connection profile basically says one end needs to provide these days, these pieces of information, such as URI, the end points, keys, the other end needs to provide other sets of information, such as the context, the security keys or whatever.
You codify that into a connection profile. All connection profiles, have names, have unique names and are open and available on a directory in the, in the cloud. Very similar to the domain names are all open. You know what? cnn.com is doesn't matter where you are in the world is always going to get you to cnn.com.
With the connection profile, the connection profile is [00:53:00] given an eye, right? So it may have the name of IAQ dot HPAC. I'm just making that up. And you, you create that connection profile for that use case. And and you do that once, right? And ideally you would do it with people that understand the use case, understand IQ and understand HAC.
You do that once you put it in the directory in the sky, and whenever an IQ system comes along and being introduced to the twin of the building, it basically says, ha I I understand IQ dot HPAC, which is the connection profile has been defined as anybody else in this building understand.
Okay. And so the HPAC system, if it does, it says, yes, I can be the opposite end because it's that the two are complimentary ends. We call them client server. So the HPAC system says, yeah, I understand acute rotation. So who, who the HCA system is is irrelevant, right? So it's all coded in the connection [00:54:00] profile and the connection profile.
Then they find the, what parameters is actually going to be used for the IQ system to talk to the HPAC system automatically based on that profile, it says is you basically, you create an instance of that profile. You copy it. It's like a model of the profile. All right. So you can do that over and over again.
And you can also have multiple connection profiles to do lots of different things. So the, this IQ system could automatically collect, connect to the HPAC, but it can also connect to the lighting system or connect to the access control system in for four different use cases. So all of these things were just sort of instantiate themselves when you introduce the IQ system into the, into the building, they become interoperable.
James Dice: Very cool. So does this require them to be on the same network?
Anto Budiarjo: I bet that's a question that comes up. So the way connection profiles work is that the the connection profiles [00:55:00] require a broker. Mechanism. And so, Patty, my platform is a broker, such a broker. That's cool. We have to build first. Other digital twins will, can also be brokers.
So it requires a broker. And when I say introducing IQ into the, into the building or into the building's twin, what I'm saying is what you do with an IQ system is I'm introducing it into that broker into that system that understands all of the different systems that's in that building. Now what's important to note is that that doesn't mean that all of the data goes through the broker.
And this sort of a critical part of connection profiles is that I'm an IQ IQ. I've established that urinates vac that we can, we understand each other, we can talk with each other. So we, we can, we can exchange parameters in terms of how we talk. But really it could well be that the actual useful data flow or information flow will actually using some API APIs.
Which can happen across the [00:56:00] network, across the internet or whatever. So we actually separate out the, the, the controls the sort of communication controls from the data controls. so we think about it as orchestration layer, as a metadata layer that sits on top of the, all the different systems and the role of the orchestration is to discover and connect all of these different systems together.
James Dice: So when um, I ACU and I say, I'm in the lobby, I'm communicating that out. You know, the S the CO2 is 950 parts per million in the lobby. And then I'm the HVAC company. And I'm saying, I have his own in the lobby. Like, is it that? And then some sort of middle system needs to say, well, your lobby and your lobby are the same lobby.
How, how does that piece of it work,
Anto Budiarjo: Starts getting geeky and complicated? It kind of depends on, on the, on the structure, really connection [00:57:00] profiles is think about it as the main place where it works is in the initial installation and this. I install the IQ into the building, meaning into the, into the buildings twin, and with a broker, it then says, ah, okay, well you can connect to the HPAC. And then the profile defines how that connect communication occurs. And so, the connection profile, isn't concerned with a particular piece of data. That's going from my group to the HPAC, that the connection profile is just managing the connection between the two and between other other entities.
So
James Dice: something like a global data model that connects those two pieces of context that would live elsewhere. At
Anto Budiarjo: this point that would live, that would live in the twin. I mean, I, I actually think that's what a digital twin is. It's kind of what the role of the twin it's actually to understand all of these different systems and know when two or more systems need to connect with each other.
So that's really what the twin is doing. [00:58:00] And one of the sort of interesting things about, you know, about API is we were talking about API earlier is that this enables API has to be used, aPI has to be discovered. And there's another critical thing about API is that scares me a lot. Is that the, the, sort of the, the equivalent of the 4 0 4 problem with API APIs, you have a building, you know, a hundred systems.
There's lots of API is going back and forth, right? If something changes. There's actually nothing that sort of is monitoring to make sure that everything's still keeps on working right. When the URI changes, if a server is maintained or something, and the URI gets changed, all of the clients, all that API will break.
Because it works. Or if they API key has changed, same thing will happen. Connection profile stays there in the building forever. So it's monitoring an orchestra, orchestrating the connection. In real life forever. Right? So [00:59:00] if something changes, it can actually distribute that change instantly.
So everything's all up to date, right? So nothing, nothing breaks. It's dynamic. That's, that's another key part of connection profile and sort of the way to think about system interoperability is dynamics where, and this is going back to the little twin. This is where I find some of those sorts of use cases.
Interesting. I'm working on use case of basically your automated factories, right? Where you have sort of automated forklifts moving around, moving stuff. And they're obviously concerned that. These are not driven by humans, so we don't want them to run over people. So, we're using the connection profile mechanism to monitor all of that.
And monitor use cases like, okay, so what if the forklift breaks and you rent one from the, from Hertz or whatever they couldn't is. So that's going to come in. It has no knowledge of that factory that has no knowledge of the owner. But if it had this sort of level of metadata about trustworthiness and other, other stuff at this sort of metadata connection profile level, [01:00:00] then you can just hop in immediately.
The minute it drives into, into the manufacturing floor and actually discover itself self-discover itself. So it's all done. It's all designed to be dynamic.
James Dice: Okay. So my thinking about this right, where the digital twin has the sort of. Metadata that's related to physical systems, how they interact, that type of thing.
And then the connection profile has communications level metadata, and they, they need each other to continue to function.
Anto Budiarjo: To me, the way I think about it. And I know people have different views on what digital twin is all about. I think I fundamentally think that if, if digital twins are fundamentally an integration challenge then the most pressing problem is how to make things work with each other.
And therefore connection profiles, a collection of connection profiles is basically what connection of connection profile between nodes that are virtual representation of physical things, that is really a a digital twin
James Dice: I love how I'm just [01:01:00] like learning out loud here. So hopefully people find this helpful. I feel like I'm asking really basic questions, but the, what would be an X? So we used IQ and HVAC. So what can you, maybe this is even too long of a list to describe, but what would be in this packet of information that is the connection
Anto Budiarjo: pro, a connection profile is usually pretty brief.
Just a document. There's no code or anything. It's just a document that basically says the connection profile. This name X right. Was created. So that system a can talk to system B to do X. Okay. A could be a key or something else in system B, it could be something else. It doesn't really matter what they are.
And X is a purpose, right? Purpose could be to provide indoor air quality data, or it could be providing whatever. So the connection profile has that sort of use case driven thing, connecting one to another, to do [01:02:00] something. And the, the, the main part of connection profile is what does a need to provide and what does B need to provide?
So I've B is a server that is that API. So we're going to use one of the most common things in a connection profile is that you need to URI or where that API lives. Alright, that's one, that's one property of a connection profile. So another property could be what protocol the server is.
Speaking. Because it could be, it could say, you know, I can, I can do Jason, if you want, I can do X XML, I can do whatever. So that could be another property that the B system has to provide. And it could provide some others, but those are kind of two critical ones. The other end, a is going to consume that API.
So typically you need an API key, so, so the API key is then a property that has to be stored in the client. Side And another typical uses that you may need the context, [01:03:00] right? So the context ID, or some kind of naming convention needs to be provided by the client by ed. So, so that's just two on each side, The API key in the context, on the client side and a, the API endpoint and the protocol on the server side, right? You have, you have those two on both sides. When, when it gets instantiated to a particular building, the, the URI is then known because we know where the end point is.
The protocol is known because somebody would have configured it. And on the client, somebody would con would have configure the API key and the look and the, and the context. And so the connection profile then has all of the information that is in this case, just for
Very cool. Th this is kind of an interesting use case that I, that I've used to, to think about connection profiles. Maybe we can spend a couple of minutes on, is that. human to human contacts.
You have a contact database on your laptop or whatever computer. And it's a database that you maintain that you keep track [01:04:00] of. And it has my name in it, somewhere in it. Because you've emailed me, I know you have my name and your contact. I have the same. I have a a contact database and I have your name.
I have James Dyson in my contacts. So that is in point thinking. I have no idea at any given time whether the email address I have or the, the street address, which I know is not wrong because not that I know what it is. I have no idea of what that is. Because it's on your side.
And I have no access to it. A connection profile view of it. This. You don't have a contact database and I have a contact database. What we do is we have a connection profile that defines the relationship between James dice and answer right in there would be the information I need. So if you change something, it will be reflected on my view instantly and everybody else's view.
So that's kind of one way of thinking about connection profiles in more sort of human terms.
James Dice: So I would still need to say, Hey, I just moved. And my new address is yep. And I communicate that
Anto Budiarjo: to the broker. Yes, you do that [01:05:00] in whatever this affectional tool is, and that tells the broker and the broker will then tell everybody else that you have that relationship with.
The relationship is based on the connection profiles. And the broker knows all of the different instances of like, connection. I feel like the
James Dice: speaks. So you talked about integration in the past being like this end point thinking kind of manual process, like get two engineers from each side in the room and they create a project plan and go through all this stuff.
But you didn't talk about what happens to three years later when somebody changes something down the line. So then it's just this constant mess. And as we add more connected devices and more connected devices, it's a big spaghetti mess. So I feel like this speaks to the resilience and reliability and maintainability, and really just like making digital twins even viable from
Anto Budiarjo: a solution standpoint.
Yeah. That was part of my comment on [01:06:00] the dynamics part of it. But that's that's a great a great point that actually maintains the system as opposed to sort of a spaghetti or virtual spaghetti.
James Dice: Cool. So, so essentially what we could add in the future is that everything. I is actually plug and play people. People say, plug and play and throw that around that word around like, it's something that's happening all the time, these days. But what that can basically enable it
Anto Budiarjo: essentially. And, you know, I recall back to a debate.
I think you and John Betsy were having about the iPhone, how to make it as easy as the iPhone, this kind of mechanism I believe will get us there. And it should be if it's implemented widely and that's the vision, obviously the call to action is to invite people, to be part of this, is that everything will then understand how it can work with other things, the same way that your, you know, your Facebook app understands [01:07:00] how to work with another app that on your phone.
I don't
James Dice: remember where John and I ended up with that debate, but it's been a while since we've picked up, maybe we'll have to pick it up at IB con here next week. Well this, this episode will actually come out a couple of days after, but I'll be bringing that iPhone thing up with John. So where do you see this effort?
Like the open source connection profile effort. Where do you see this in sort of in context with things like haystack now that we're talking about John and other sort of. Standards and efforts that solve part of the interoperability puzzle, but not all of it. Obviously they're not solving what we're talking about here.
So is all of this going to converge into one thing in the future? Or what do you, what
Anto Budiarjo: do you think's going to happen? So I'm going to pull in the smartest stack to talk about that, because again, We have this exchange layer on the stack, which is where really where all this resides. So, so tagging [01:08:00] from a haystack and break records, not just styling, but that all exists in exchange layer.
And they both can co-exist, there's nothing wrong with that. And that, the date that the data does tag is all in the data layer, right? So it's kind of separate, right? The connection profile mechanism is an exchange layer, thin technology, right? But it's not concerning itself with tagging data is really the way to think about it.
It's actually tagging systems. You're tagging the IQ tagging the, the, the way it tax is different. It's not tagging the piece of the system. It's actually tagging its capabilities of talking to something. Yeah. So, and so connection profile which has a fancy name, it's actually called CNS CP connectivity, naming system connection profiles that sets in the exchange layer the same does any sort of semantic model does.
And so the way I see it working is that an app would say, you know, what's available for [01:09:00] me using this, this or these profiles and it will discover it. And then once those discovery, once those connections are established, it will then exchange data using Symantec Titans. Yeah. If it if it's if it applies or in some other cases, it may be completely proprietary because there's no reason why connection profiles can't be created to connect proprietary systems together, which is an intriguing kind of concept, I think.
Yeah.
James Dice: Yeah. So you think these, so the connection profiles open source effort, you think will be separate from haystack, which will be separate from other things in the future.
Anto Budiarjo: Yeah. Where, where we're trying to figure out where. Best be placed. I started life in the digital twin consortium which has been great from a, from an application perspective, application discussion and use cases.
That's really great. But it really needs to morph into real sort of open source [01:10:00] code sort of contributors. So we're seriously looking at Oasis as well as the Linux foundation as being the home for this. It's sort of intriguing similarities to Kubernetes. How well do you know Kubernetes, but Kubernetes orchestrates Vietnams and DM sort of components, right?
So that's what Kubernetes is. That's connection profile, orchestrates integration in much the same way. It's kind of a layer that sits on top of, on top of the actual work itself. Cool. Yeah. I believe Kubernetes has
James Dice: come up on the podcast
Anto Budiarjo: a couple of times. Cool. All right. So where does
James Dice: Patty sit in relation to connection profile?
So I think we, we talked about it a couple of times, but Patty, the company separate then connecting profiles, the standard different,
Anto Budiarjo: so Patty is Petty's cloud-based Aggregator of user interface. So if, if you, if you think of the, the, the alternative integration problems or the education products and all of the ones [01:11:00] that I've been involved with before and others, there's always two parts of it.
There's how do you integrate the UI? In other words, how do you integrate these different systems? So human being can consume it in a sort of organized way. And then how do you integrate or connect all the different systems together? There's always been the two things, right? So the connection profile is the latter is how the systems connect with each other.
So, Patty implements, connection profiles As part of what it does. The, the other part of Patty is the UI aggregation, and the UI aggregation in Patti is also different and very unique because we, we decided on the approach that we want to integrate, we want to do integration in the age of the internet.
So the way we're integrating the UI on the, on the, on the data side is we're integrating basically HTML UI, right? So if you have a system that provides HTML UI of some sort of dashboards or management tool or whatever that can plug into [01:12:00] Patti, Okay directly. And you can organize it.
There's lots of ways you can actually organize it then you know, make make one UI next to the next next to the other UI that normally wouldn't connect together. But because they are both in the lobby, you actually need both of them. So you do that. And so all of these are we think about them as.
So each system has an app. So with, with Patty, what you do is you install apps and you install apps at a particular context. So for example, in the building, you're creating a tree or ultimately you be able to pull in a bin database or I'll actually create the hierarchy of the building buildings, float rooms or whatever.
And then you would put an app pertaining to the a queue system in the lobby. And then the way you do that is you would install the IQ app on the lobby object and in it, and then it would know where it is, right? So the IQ app will then know that it's in the lobby so that when you then install [01:13:00] another app next to it or underneath it or somewhere, and you're installing HPAC app or a dashboard app, it will be able to communicate to the ICU.
App using connection profiles and Patty manages all of that. So all of these apps in the sort of complex hierarchy of a building can talk to each other, using connection profiles. And that's I go back to the, the, the words that I use, you introduce an ICU into the lobby, right? It will then say I'm here, I'm in the lobby.
Is there something, is there an HPAC system that can provide me a certain amount of data and they will do that. And the Patty will discover that the two should connect. It will actually connect them. It will actually instantiate connection, profile instance, exchange all of the data, all of that in a plug and play manner.
And then the user then has a single sign on single and consume all of that information maintain dynamic and everything that we talked about.
James Dice: So there's the ability to log [01:14:00] in to pretty much anything that has an HTML interface in the building
Anto Budiarjo: outside of. Yeah. And I'm sure a lot of engineers out there sort of thing I was asking, how do you deal with security and credentialing and things like that?
We've created an app framework. It's very flexible in terms of being able to accommodate different types of credentialing sort of requirements of different apps, different patients. So that's kind of how I would do that and all of these apps and up in the petty store, because. It's not an app store because I'm not allowed to use those words.
James Dice: I could see you're hesitating for those of you that don't see the video right now, Anto was about to say app store and he hesitated for like five seconds. There
Anto Budiarjo: it's a store, it's a party store. It's likely what it is. And, and so in the pedestal you can buy apps. I can say that. But you can also buy data to think about that, right? So if there's a, if there's some data in, in the data [01:15:00] layer that may be there because somebody has invested a lot of money to gather the data or for whatever reason.
And they actually want to monetize that we can actually use the Patty store and sort of the app mechanism to pay for data connection profiles. Very cool.
James Dice: I mean, what's striking me, is that now, now we're talking about as like the patties, the digital twin aspect of what you're talking about. So it's not just the broker, it's also the metadata as well. And the U
Anto Budiarjo: S yes, no data, no apps, no fundamental systems. We don't do any of that. And that's sort of, one of the interesting things about the smelter stack is that quite often I showed the smartest stack to somebody and ask them, you know, what does your product look like?
What does your offering look like? And the first thing they do is they drop vertical box. I'll do this, I'll do this, I'll do [01:16:00] this. I do everything. Keep the customer happy.
I think that's an old mindset. And so from my perspective, that is the delivery lab because we deliver all that to the users. The, the Patti store is obviously on the app layer and the connection profiles and the exchange layer. I'd say we have nothing on the data layer or anything below, and that's what other people do too, to bring their innovation.
Very cool. Well,
James Dice: people can check out the YouTube video for, I'm sure it will have a slide on where Patty and, and everything else fits. Anything we left out on, on Patty, I feel like there's a lot more than maybe we could dive into on a part two, but for time we
Anto Budiarjo: should should wrap this one up. I think that's a, that's a good.
Place to stop all of this, and we've been working on Patty for about three years. So the UI part of it is is pretty solid, the smarter stack.org, which actually has a library of smartest. I actually uses Patti. So when you go there, it allows you to log into Patty and you see all of the [01:17:00] libraries.
So that, that part is, is there the connection profile part as is relatively new, as far as explaining the, sort of the history of that. So we're working through that, but it is, it is functionally there and Patty as well. That's the way we are. We're in the process of going to market with this.
Cool.
James Dice: I'm sure you'll get people reaching out as a result
Anto Budiarjo: of this seems to me that the
James Dice: fact after the podcast, so All right. Well, this has been fun Anto, I'm glad we finally got, got this on the calendar and got it done. Thanks so
Anto Budiarjo: much.
James Dice: All right friends, thanks for listening to this episode of the Nexus Podcast. For more episodes like this and to get the weekly Nexus Newsletter, which by the way, readers have said is the best way to stay up to date on the future of the smart building industry, please subscribe at nexuslabs.online. You can find the show notes for this conversation there as well. Have a great day.
[01:18:00]
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.