Digital Twins: Empowering Collaborative Data Management

JACOB D'ALBORA: Hey, everyone. Thank you for coming. This is AU2023 Class CS602401. We are speaking on digital twins and powering collaborative data management. Basically, have you ever heard of GitHub? So as I get in here, I'm Jacob D'albora. The FMP behind the name stands for Facility Management Professional. And I am the Director of Digital Building Operations for VIATechnik.

Now, most of the time, this is where I will go through all my achievements I've had over all the years. Wow, and it all started on May 3, 1985, when I entered the world. No, no, no. I'm kidding. I'm kidding. If you don't know me, the accolades and the achievements is not what you should know about me.

What you should know about me is, first, I am a family man. I have a beautiful wife, two kids, and they're my everything. The second thing you should know about me is I love what I do. I love my job. I love the people I work with. I love my clients. And I love to inspire others.

If you want someone that has a very monotone and slow presentation where I read each line on the slides for you, well, you're in the wrong class. People say I'm passionate. And I think that's an understatement.

I wear my passion as a badge of honor because I get to do some of the coolest things in the world with the coolest people in the world. And really, we're all just a bunch of nerds. So I want you all to take away from this that you know me as passionate but also that you can take back that we get to do cool shit every day. And we change the world doing this.

But what you might not know is who--

[AUDIO OUT]

We are an international VDC consulting firm. We have over 280 experts through nine global offices. Seven located in the state, one in Poland, and one in Manila. We, as a company of individuals, believe that we are changing the industry with our clients and projects. Our mission is to transform the built environment for a better future. We empower our clients through high quality, high-velocity experiences, consistently improving outcomes across design, construction, and operations of buildings and infrastructure.

One other thing I want to mention about us is the way we approach projects. We have established a three-phase process of how to help our clients with digital transformation. This process of strategy, execution, and enablement has proven highly successful and become a staple for VIATechnik.

The process is meant to align all stakeholders with expectations and goals, deliver quality in every aspect of our services and products, and enable our clients to continue gaining the value identified [AUDIO OUT]. Like it says at the bottom, our digital transformation services drive high quality, high-velocity decisions for our clients. If you would like to learn more about VIATechnik, please go ahead and reach out to me on LinkedIn or visit our website at viatecknik.com.

Now, onto the good stuff, digital twin. Yes. Yes, digital twins. I know, the biggest buzzword in construction since [INAUDIBLE] back in 2010. And yes, it actually is pretty similar to Green in 2010. If you were to ask 20 people, you may get 20 different definitions. For our ability to serve our client and help move the industry forward, VIATechnik has defined how it uses digital twins.

And we define the digital twin as a digital representation of a physical environment enabling data-driven insight and action. It represents a connection between the digital and physical world and is used to enable organizations to monitor, analyze, and simulate real-world data in a virtual environment. This definition is used to create alignment between us and our clients and sets a general goal of what we are looking to achieve with our clients.

Now, some key words and phrases in there. Digital representation of a physical environment, connection between the digital and physical world, and by far one of the most important, monitor, analyze, and simulate real-world data. So you can already understand that there is a digital aspect of the physical world that we are using to monitor, analyze, and stimulate real-world data.

Now, personally, I use this exercise to help explain digital twins. If I were to try to explain it to somebody that is really not part of our industry or doesn't know terms such as BIM or VDC, this is kind of where I start. And so we have four buckets here. We have asset, digital representation, centralized access, and data collection.

So we define an asset as property owned by a person or company regarded as having value. For this instance, I'm going to consider myself the asset. Or we can consider you the asset.

Second, digital representation. Well, this is a visual representation of myself and a virtual environment, or what we commonly refer to as BIM in these instances. There I am. And like BIM, the visual representation actually contains metadata about the asset. In this case, my metadata is added.

Now third, centralized access. And this is where we start speaking more of a common language. The centralized access for a platform represents a hub where you can begin to monitor and analyze [AUDIO OUT] similar to what Apple has created with Apple Health.

So Apple Health is a app that allows you to retain information about you within a single repository. And then other things can access that information, but also it can add to it. And so that's where the data collection comes in.

So you have sensors, like your Apple Watch, that then can track and monitor. But also, there are apps out there that do the same thing. So there's Humana and Under Armour, Nike and Peloton. All of these collect data and can provide it back to that centralized access point. This is the definition of a digital twin where an asset is recreated in a virtual environment to monitor, analyze, and simulate real-world data.

Now, let's take that analogy and apply it to buildings and their life cycles. Same idea as we look for, we look at the four buckets of asset, digital representation, centralized access, and data collection. Instead of using me or you as the asset, these are typically defined from a macro to a micro level.

So we look at campus, building, level, room, and then equipment. And really, in the world of digital twins, the equipment is that asset. Building operations focus on equipment and how equipment performs and consider that an asset. The rest end up becoming location-based property. So for this instance here, we're going to say a heat pump is our asset.

Next, digital representation. Remember the BIM being our digital representation. So here we are. We have our heat pump. And once again, the BIM has metadata to it. So for this instance, this is a YORK YMAE model heat pump. Now, that's what I put here. We all understand that BIM actually has plenty of other attributes that come with it as well. The air source heat pump, electrical demands, inlet and outlet connection sizes, filter types, and [INAUDIBLE]. The list goes on. But this is our idea of the digital representation.

All right, now I'm going to skip over centralized access real quick. We're going to look into data collection and how a facility operations and building do data collection. Well, just like the apps that are part of the Apple Health, there are platforms and applications that collect data. So we have building management system, BMS, or a centralized maintenance management system, or internal work management system. All of these are platforms that are used to operate and maintain facilities.

Next, sensor, so IoT sensors and even O&M in Log, these track performance and maintenance of the assets. Now, jumping back over is a centralized access. Last piece of this is that hub. This is that UI for digital twin. Well, in this case, we have a program called Voyager. And I can expand on it and everything. But this is what VIATechnik uses to actually establish what we do as a digital twin base. Once again, if you want to learn more about VIATechnik and myself, LinkedIn or VIATechnik.com.

Now, typically if we were to go through a digital twin implementation, we would go through a series of exercises. Remember that strategy, execution, and enablement, well, these are really the outcomes we look for as part of those exercises. We want a series of owner standard and handover requirements so project teams understand expectations and goals.

We would want to implement into the building operations phase so we can understand asset performance. And we would want to access IoT and facility data. That way we can optimize the facility operation. But really, there's something wrong with this scenario here.

In a building life cycle, we have design, construct, and operate. And the scenario that we were just talking about there of implementing digital twin actually happens here. That handover happens between construction and operation where there is so much more and so much more value to it. But we can come back to that.

What if we were able to actually maximize that value? So GitHub-- who here has heard of GitHub? So GitHub is a platform and cloud-based service for software development and version control using Git, allowing developers to store and manage their code. Thank you, Wikipedia. But really, actually, GitHub is an incredible company that was bootstrapped startup that set out to do one thing, solve the uncollaborative process of coding.

So back into the 2000s, coding was shared through email and snippet, were passed back and forth. But the actual software development was done locally. It became very difficult to have distributed team. Primary purpose of GitHub was to facilitate the version control and issue tracking aspects of software development. What it turned into was a full collaboration network where open source software thrived and became a learning center for anyone in the world that wanted to call themselves a coder.

Now, the underlying element of GitHub is a version control system known as Git. It was created by Linus Torvalds, also known as the creator of the Linux operating system. The value behind the Git versioning systems is that it is a distributed and it allows for the development of software to be non-linear. All right, so let me explain here.

All right, so looking at this diagram, you have what is known as the master branch. And if you wanted to make edits to the master branch, you would create another branch. OK, hold on. This is quite confusing actually.

Let me see if I've got something better here. Nope. Nope, that's even more confusing. It's an interesting take on it. But it doesn't help

Oh, vertical, maybe we can try something vertical. Well, no, let's keep going. No. Oh, annotations, those always help. No, actually, that looks like it's more confusing. Ah, something simple, but actually doesn't really get a point across. And that is way too simple.

This is perfect. This is the one I'm looking for. This helps us understand. So the Git version management system. In the middle is your master branch.

In this scenario of this presentation and how we will look at applying the concepts to the construction industry, I want everyone to think about this repository master bank as a master databank. When edits need to be provided to that master branch, a secondary branch is created known as a pull request. The edits are done on the secondary branch and then merged back to the master branch.

Now, the only way that changes are merged back into the master branch is by an action called a "commit," which then the owner of the master branch has to accept and approve the commit and merge. But as you see here, your work, which is one pull request, can happen in a parallel phase as somebody else's work that's a pull request. And both of them can actually merge back in to that master branch, which creates an incredibly collaborative experience in work being done in these parallel phases.

And as I was doing further research into GitHub and the Git process, there were two descriptions that stuck out with me. One, collaborative intelligence. I don't know if there's any better way to describe Autodesk University than collaborative intelligence. The second, collaborative Innovation network. To me, I think the BIM community as a whole has always been a collaborative innovation network.

All right, so moving away from the history of Git and GitHub, let's look at what impact it has actually had over the last decade or so for the AEC and BIM industry. And really, if you don't know this or didn't realize this, but GitHub has housed many different open source Revit plugins, including Dynamo, pyRevit, DiRoots, RevitLookup. All have been a huge staple of the growth of my career. Plus, there are dozens and dozens more out there on GitHub. All of them are open source. All of them are there for your availability and actually you can go get.

GitHub actually holds a very special place for me. The open source software that provided me many opportunities to explore and grow, learn new things, and apply them to my professional career. GitHub became a learning center for me. And it was fascinating that these tools were at my fingertips. And all it took was my initiative to explore and learn. And one of the big ones over the years was Autodesk Forge.

The ability for me to learn how BIM was evolving and apply it back to my professional life-- oh, wait, wait, yep. OK, I was wrong. AutoDesk Platform Services-- it was incredible. This is amazing. And did you know that it's still open source, that Autodesk Platform Services is still available on GitHub? It is free. It is available for you to go learn. You just need the initiative.

Now, a couple other ones that have been pretty powerful along the way is Speckle and Blender, both of them open source. Both of them have great powerful tool sets and will help continue to push the industry forward.

Now, enough of GitHub completely. Let's turn back to the AEC industry. And what can AEC industry learn at GitHub. Tell me if you've heard this one before. The AEC industry is siloed-- badly siloed. And the silos are locked down, secure, protected with "no trespassing" signs on them. Sometimes you can't even look into one of the silos even though you are part of one project.

So what is siloed? The way that the buildings are designed, constructed, delivered, and operated, majority of the time, project teams work in their own silo producing mountains of valuable information, only to deliver a fraction of that value to other project team members. The result is loss of value, increase of risk, and multiple efforts of rework for each project phase.

So what's currently being done? There's one concept out there called the "Golden Thread." And I pulled this one from my friends over at [? Knight. ?] They talk about the Golden Thread instituted by the British government through a safety act.

It involves keeping a digital record of important building information starting from design phase and continuing through the building's life. By maintaining an accurate and up-to-date source for all building information, building owners and operators better manage their buildings and safety. So even though this was part of a safety act, the concept is very strong. The concept is still maintaining a single source of truth, so to say. But the process defined looks at the transfer of data from one phase to the next more as an additive process. That has many holes in which data quality and validation might be at risk.

So my moonshot-- now, hear me out about this. And let me let you know I think this is where the industries could evolve.

The concept of the versioning system through GitHub, the Git actual process, and applying these collaborative experiences to the building industry and working as an open source might actually solve a lot of our problems. So we're going to open source building data.

And now, let me say, I'm not saying open source is this-- this becomes public. And I'm not saying that you're going to be able to access any information anywhere. I'm talking about project teams and building data within the project life cycle. So what we should be looking at is how all project team members within one project can access this open-source building data or this master branch and actually have a centralized database of the project.

What does that look like? Well, it looks like a master branch that is controlled and owned by a digital owner. And through the construction-- through the building life cycle, all the project stakeholders and team members are able to access, view, create a pull request, edit their stuff, and then commit it back to the master branch. This process gives the ability for anybody on the project team to utilize actual information about the project, but not risk the integrity of that information or who owns that information. It has to be validated before it becomes part of the master branch again.

So if we have this master branch database and we have our timeline, it's a evolving project history. We're not looking at something that is a additive process where you're taking what was done in design and adding to it. This is a process where the master branch is acceptable and it evolves through these phases. Now, evolving history, that is such a great term. Because usually history is static, usually history is about the evolution. But if it's an evolving history, it's continually updated and maintained. And it's accurate to everything you can do. I love this term of evolving project history.

Now, to tell you the truth, there's a huge road bump here. The database, it can't be used in the same way that projects are delivered today. You cannot do this type of workflow when your whole workflow is delivered on 2D drawing or your requirement is to produce 2D drawing. Everybody has to retrain what they think the project's about and define it by the assets that are within the building and how they're going to perform.

So our database has to go from, hey, what would be just a virtual replica that is then used to create 2D drawing through a database defined by assets. Remember the exercise we did at the very beginning, how we identified an asset and how everything kind of continued with it? That's where we'd have to go for for this to work.

Now, the other side, I want to acknowledge something. At the beginning of the presentation, I showed you this. I said, building lifecycle, design, construct operate. Well, we all know that's a lie. We all know that really it is much more complicated.

This is more of a building lifecycle. We have design, precon, construction, commissioning, handover, and operation. And it continues to evolve. It continues to be cyclical. So in operation, design happens again and the existing building is updated. We keep going through this. So we can't just point and say, oh, we were delivering between construction and operation. We have to identify so much more. And so to put this process in place, to even think about how this could be deeper and go further into a Git version history, let's look at each phase here.

For the design phase, so the design phase is pretty crucial. But this master branch or the master database is started and really uniquely established by the design phase. But it has to be established with a series of requirements and attributes that need to be defined and delivered. But once again, just because the design phase creates almost the initial master branch does not mean they own it. So once that is done, they actually have to look at it as we are going to create a pull request to update that master branch.

So this is what the pull request becomes, definition of assets and attributes. They're a design intent, the basis of design information. Now, I know everybody in this room understands that basically designs are delivered in drawings and specs. And those specs that contain the base design correlate directly back to the drawings. They're actually connected. No.

What about to the BIM model? They're connected directly to the BIM model. We have specs that talk back and forth. No. And I know there are ways out there. I know that there are capabilities of doing it. But 99% of projects delivered today, the specs and the drawings, the models, do not talk to each other. Well, this gives us a way. They're able to align that basis of the design information into this master branch. Then it's something that can be connected back and forth.

Next, precon. Precon is going to be looking at the next pull request. And I want you to even look at the diagram here as something that you could see happening during design. So a pull request has happened by the designer. And they're editing it.

Well, during that same time frame, the pull request by precon can happen. They can go ahead and start pulling some of this data that has been built by the designers and committed and merged and start using it. So they have access to design data. They have access to assets, equipment, basic design information.

What's more powerful here is, in their commit, in their work, they can flag pricing issues. They can flag supply chain issues, lead time and put it back into the master branch, put the commit in and merge it. And now we are looking at a evolving history of the project that basis of the design was at. But precon is saying X is going to take 12 months. So why not Y? And then it all becomes a evolving history of what this building is.

Next, construction. Construction comes in. And what is construction? Construction is the virtual to physical opportunity. This is when everything that was virtually built and virtually defined becomes a reality and is installed. So we have finalized attributes of property. We have installation information, record documentation, shop drawings, submittals, products data. All of this is built during the construction phase and can be committed and merged back into that master branch.

Top of that, there's commissioning. Now, commissioning actually offers us a rather unique but extremely valuable opportunity. And this is the opportunity of data validation. So during the design construction phases, commissioning is able to get in and do a data validation. And this data validation is going to look like, hey, what was virtually said was supposed to happen, what is physically in place, and does it match.

So we are looking at locations of equipment assets, were they defined correctly, where model names named correctly, serial numbers correct, do they have the correct tag on them, do they have the correct QR code on them. All this is the data validation exercise that is already part of commissioning when they start touching every object within the building.

The other thing which is significant to this whole process is for testing and balancing, they have the ability to set a performance [AUDIO OUT]. They can set a baseline in which a piece of equipment is supposed to run at. And that can be used later.

Hand over, everybody's favorite phase of construction. We are going to get there. And nobody has time left, nobody has money left, and even the owner's on to the next project. So hand over, this creates a construction handover process that is centralized, validated, and delivered on time, removing unnecessary work at the end of projects. This evolving building history soon becomes your hand over. Everything in that master branch now becomes the hand over, which is incredible.

Last, building operations. We are looking at this master branch going in and feeding facility operations in digital twin. But it also continues to evolve during the building operation phase. We can do an analysis of the actual performance of equipment and assets versus the commissioning benchmark. And all of it is within this master branch.

So this database continues to evolve. It continues to be a master branch with pull requests and commits back. Now, the next project that happens there has so much information to be able to start from and actually has an understanding what the project history is.

And now I share my digital twin dream. We are looking at what could be a version control collaborative innovation network tied to the siloed process of design, construction, handover, and building operation. And what does this get us?

Well, it should get us a digital twin. But we got to look at it differently. We got to look at how it's acting and what's going on. So I showed you this slide earlier, that digital twin consistently is considered part of that handover phase. But what if we were to look at phases differently?

What if we were to go ahead and say, what if we used the digital twin to build the full database, from design through precon, construction, commissioning, handover, operation, and back into it, all of which is important, all of which this digital twin becomes a master branch for data collection. The digital twin becomes the evolving history of the building. And see what we can do this moving forward.

I appreciate anybody that is watching right now. This is absolutely one of my favorite things to do. As I said at the beginning, I wear my passion as a badge of honor. And I love doing this stuff.

I love participating in these things and being part of your growth and your career. You want to learn more about this, learn more about VIATechnik and myself, please reach out. And thank you very much.