I Got 19650 Problems—but the BIM Ain't One

KRIGH BACHMANN: Hi. Welcome to "I've got 19650 problems, but the BIM ain't one." And I'm Krigh Bachmann, and I'll be presenting this session where we're going to take a look at the ISO 19650 standard, BIM standard, but also look at how it's potentially unlocking digital innovation, both within smart buildings and digital twins.

So we're going to dive into a few quick introductions so you can get to know me and why I'm presenting on this topic.

My name is Krigh Bachmann, as I said. I'm the Leader of Digital Innovation at a design practice. Primarily I'm based out of Toronto, Canada. And you might say, well, what is a leader of digital innovation do?

Within my design practice I focus on more of the emerging tech side of things, more sort of researching and implementing new technology and making sure that the practice has it in hand to practice on the leading edge.

As well with that, we've got clients that are dealing with digital deliverables these days that's more cutting advanced stuff than most projects out there. And so I work closely with those groups to sort of ensure that the projects are delivered that way or help define the requirements for them.

My background-- I do work within our practice-wide technology team, but I am actually come from a design background. I've been working in the industry for about 19 years, 11 of which have been in Canada, eight have been in the United Kingdom.

And some of you might also know me for other presentations that I've done at AU in the past, such as shared coordinates, because after all these years, I still don't get it.

The design practice that I work for, Dialog, we're quite a large practice based out of primarily Canada, but we do have locations in the United States as well. And we're an integrated design practice.

What this means, where this becomes quite important when we start to get into things such as digital twins, as you'll start to see is the word integration is going to come back. But we've got the advantage of looking at projects holistically because we've got all these different groups.

So why are we all here and why are you-- why am I doing this session? Well, Dialog has clients that are looking to put together digital twins for their projects once they're completed. Or they're looking at how do they put together requirements for smart campuses or reviewing project requirements for the federal governments.

And part of this, that they're also looking at, is how do they use the ISO standard. The ISO standard, if you're not familiar with it, we're going to do a quick little introduction. But it's been growing in adoption. It's an international standard, and including it's been getting adoption in Canada, where I am here.

Part of my experience that I'm going to bring to the table is also the fact that the ISO standard was actually built off of the BIM Level 2, that you might have heard about, that was previously released in the United Kingdom. So I'm going to bring some of that experience to the table.

And why you here? Well, because we're going to bring all those things together, the ISO standard, the digital twins, and see how we can unlock some innovation with it.

So what am I going to cover? Well, I'm going to break these down into four different subjects or sections. And just to state right out of the gate, these are big topics. A lot of these things you could devote an entire AU session on just one of these topics. So I'm going to try to give you a high-level summary of some of them to give you a bit more context.

So we aren't going to do a deep dive into the ISO standard or digital twins. But I'm going to try to give you enough of an overview so you can see how these different pieces integrate together.

So I'm going to give you my take on the ISO standard, try to sort of highlight some of the more important parts. We're going to examine some of the concepts, and I'm going to try to bring it to you in plain English stuff that's easily digestible.

And because this is a BIM standard, you might be saying, well, how does apply to digital twins? What are digital twins versus BIM? So we're going to do a quick comparison, and then we're going to sort of see how all four come together-- or all three come together.

So getting to know the ISO standard. If you, like I said, there's a lot of reading when it gets into it, and I definitely recommend taking a deeper dive into the ISO standard. But just so you know a little bit about it, the very brief history of it is that it was based off of BIM Level 2 out of the UK, which was originally released as a publicly available specification.

So it was kind of thrown out into the wild and sort of tested on projects. Now that it's had quite a few years to mature, they finally have developed that into an ISO standard to release internationally so that people can use it, and it's not just that thing that's over in the UK.

Now with that, you might be saying, well, how does this apply to me in my regional context? So also keep in mind that there may be regional annexes that are developed.

I know of one, for example, that is being developed within Canada. You might have one within your region as well that tells you how to apply the ISO standard specifically within your region.

You'll also hear me refer to the ISO standards or ISO standard. This is because it's got five parts to it. One of them is still in development, by the way, so keep that in mind. But it is a large set of documents that you may have to refer to.

But the main thing that I really want to hit on is the fact that the ISO standard, specifically 19650, I see as a bit of a framework. Now, you might sort of say, well, what does that mean?

A lot of people when they hear standards within our industry, they immediately sort of freak out and sort of say, ah, somebody's imposing a standard on us, and that standard is going to be like, you must do your layers this color, and you must name your files this.

And for the most part, yes, this standard does have some of those pieces. But I like to think of this as more of a framework, more of a fill-in-the-blanks.

So, for example, it says you need to use a classification system. It doesn't tell you exactly which one. And it tells you certain steps that you have to do and certain documents to produce, but it doesn't give you the templates to actually produce them.

So what you have to keep in mind with this is that it helps guide you along, but it's not necessarily something that you can just specify as a, I want an ISO 19650 project, keeping in mind that's especially true when it comes to clients.

Clients are key contributors. For any of you out there that are on the client side, this is an excellent set of documents to help guide you through the BIM process.

But what you have to keep in mind is that much in the way that we've learned with BIM Level 2, you can't just come to the table saying, well, I want an ISO 19650 project, and call it a day. Because one of the first things you actually have to do is actually define what your requirements are.

So let's talk about that key concept. And again, I'm going to try to bring these back in plain English. So thinking about BIM. If any of you are still using BIM as a design tool or part of preconstruction, this is probably-- it's great. The industry has gotten well established with it.

But what we also have to keep in mind that the way we use BIM at different phases of the lifecycle are going to be different. And what's important to note about this is that the only person that really ties everything together is actually the client. And that's because the client has a vested interest in the whole process.

Now, you might sort of say, well, wait. Isn't the client the end use? I've worked on projects where even the facilities management group was outsourced. So each of these different groups will seek data and technology in a different way. And the client has the vested interest of pulling everything together.

So how do they do that? Well, one of the things that needs to be established is much in the way that, when you put out an RFP, a client has to establish a design brief so that everybody knows what we're actually designing. How big is the facility supposed to be? How many square feet? What departments are going in there?

Well, if you get requesting digital deliverables, it's going to be the same sort of thing. There's going to be a need to have some sort of definition up front as part of the requirements and contract of that project to define exactly what is needed. So how does that happen?

Well, on a lot of projects I've been on in the past, we produce information that we can deliver as part of the project. The typical idea of, hey, we've got a BIM file. You go to the client and you say, you've mentioned that you're interested in a BIM. What do you think? Do you want this information?

And it gets into this whole chicken and egg situation. Yes, we want BIM. OK. What do you want from BIM? I don't know. What can I get from BIM? And this is not really the right approach.

The question needs to be asked, what information does your organization need to be delivered as part of the project? And again, the usual question will come back of, well, what can I get?

And well, when it comes to a bigger lifecycle of things, making decisions on a project, a lot of that information can be fed into or should have the question asked, well, how do you organize-- how does your organization manage their assets? Because the biggest potential benefit of BIM that can be unlocked for the lifecycle of the project is passing that information down for use for facilities management.

So if you start to ask the question of how does your organization manage your assets, that starts to define what information needs to be delivered. Because that information will then be delivered and pass through to information that you can use to maintain your project.

Now, a lot of clients at this point will still be, well, what do you mean what information can we use to manage our assets? Well, it starts with a higher-level goal of this. And that is, what does your organization want to achieve across all of its assets or projects?

If you think about stuff like an academic institution, somebody that has a campus with lots of different facilities, or a real estate group that has lots of different properties, there's an organizational level that has to be achieved here, where you set out to sort of say we want to do this to achieve certain business goals across our entire portfolio.

Now, if the client only has one project, you might be asking that question about a single project as well. But it still should start with those business drivers.

Now, alongside of that, you'll also have specific goals that may need to be achieved for a particular project. So if you can imagine a campus situation, where maybe this project has something slightly different that needs to be thought of, that might be needed as part of this process.

So these are the different steps that are needed, that by defining those requirements up front, it starts to define what information needs to be delivered later down the road.

And so with this, this is where the ISO standard comes in. Each of these is a key piece that's actually created as part of the ISO 19650 project process. They're different documents, information requirements, that are put upfront that help define the information models that will be produced later on.

And if you're sort of wondering, OK, I'm trying to sort of follow this long, think of it this way. If an organization wants to achieve, for example, better goals of running their facilities, that's going to be their business objective at the high organizational level.

That means that the way they manage their asset, well, they have to monitor the performance and maintenance of all the mechanical units, which means that their specific exchange requirements are going to be asking for things like exports of data, including things like all of the mechanical units, model number, serial numbers, warranty information-- all of that imported or exported from the project as a CSV that could be imported into their building automation system.

And on the project side of things, there may be certain adjacencies to other properties or something like that might need to be incorporated because of a specific situation. And so there's going to be business objectives from that side of things.

So another way of looking at it is that you start at a high-level organizational strategy, and each of these things starts to feed their way down to different levels. So they flow through to define those deliverables.

Now, a lot of people will say, well, wait a second. Our clients just usually ask for BIM, and then nothing's been defined, and then we get into arguments over why aren't we doing this on the project. Can we extract that information?

So the other key piece about this is that these things need to be defined upfront. They are defined before the project starts, and then they're actually released as part of an RFP.

And the important thing about this is so that we understand what the digital deliverables are, much in the way that a design practice needs to be able to design towards a brief. We need to have that information upfront so that we know what digital deliverables are going to need to happen.

So what then can happen is anybody bidding on a job, both on the construction side and the design side, can put together a high-level plan of how they plan to deliver against those requirements. Those plans are actually included as part of their submission for a proposal. Why? Because that way the client side can compare things apples to apples.

So you've got both the opportunity, if one group is doing clash detection, and the other one isn't, if one of them is using a certain database system for collecting information, and one of them isn't, all of that can be seen up front under high-level strategies.

Now, you might sort of say, that's a lot of information to submit as just a proposal. But it doesn't have to be completely fleshed out, but there needs to be enough of an outline. Because then what happens is the contract is awarded, signed, based off of all those requirements.

Then details are started to be developed about exactly how and when the information is going to be delivered. So defining all the deliverables of who, when, and what, and including the fact that some of this information is going to be coming from sub-trades and sub-consultants.

So with all of this in mind, again-- and I know I'm throwing out a bunch of different terms here and I kind of flash up these acronyms. These are the ISO standard terms, but you can go and look at them. But the main thing to understand when I was going through the information requirements in these steps, is to understand this philosophy behind it. What are they actually trying to achieve?

So, for example, when you start to read up on a pre-appointment BIM execution plan, you understand why, as a client, you should be requesting this on all of your projects. It's because it helps define that information upfront, and then, post appointment, BIM execution plans can actually get into defining it further.

So how does this all flow down? Well, once this has all been agreed as part of the contract, then we get into the meat of the project, designing, building, preconstruction, all that sort of stuff. And a project information model or BIM model is developed.

Now, in usual fashion, that model can be exchanged over or information can be extracted from it. But what's different about this process now is we have something to evaluate it against. We have the opportunity to validate any information delivered against the EIR or the exchange requirements.

So if a group puts that information out, it can be evaluated, and if it doesn't meet it, it's going to get rejected and tossed back because it doesn't meet those requirements. You actually have something that the digital requirements are being evaluated against.

However, if the information is good or the model is good, it can be incorporated into an asset information model as part of the facilities management.

Now, this doesn't necessarily just happen at the end of the project. We may want to validate that process or that information as the project goes on, so it may happen multiple times throughout a project.

Now, you may be hearing some of this and going, OK, so I'm used to dealing with LODs. How does that actually apply in all of this?

Well, that's where things start to get interesting because if-- I'm sure a lot of you have worked on projects-- if you've worked on BIM projects, you've got sort of a matrix like this, that sort of lists out the different elements that are potentially in the model and what LOD they are defined as, or Level of Detail. You might have also the person or the party that's responsible for creating it.

The problem with this is this doesn't have anything to do with facilities management in here necessarily. It talks about the geometry, but it doesn't necessarily get into the nitty-gritty of the information.

So the other pieces that we have to keep in mind with this is that this traditional approach is taking into account the level of detail and the model element author, but doesn't have anything when it comes to-- it lacks the level of information, and it's not focused on asset management.

So how does the ISO standard change this? Well, it starts to define things and it talks about something called level of information need.

And I can tell you from getting into the ISO standard from somebody that's been quite familiar with BIM Level 2, this was probably a big jump and one of the things that our industry is going to have to tackle and really sort of figure out.

Because how do you actually require these different pieces of information and how do you put it into a way that can be easily communicated?

So they come up with a term, level of information need. Now, level of information need does not necessarily-- it's not just the new LOD. And also, don't make it into an acronym, even though everybody does, is basically what they keep saying as well.

But to give you some-- they don't really define it much in the ISO standard. But to give you some idea, as an example, one of the newer standards that's being released under the-- and again, another big long number, EN 17412, as an example, starts to talk about the different ways that you could require information. And when you start to look at it, you start to understand how this starts to come into play.

For example, when we talk about geometry, you can require, yes, level of detail. So is it simplified or quite generic? Is it quite detailed? But you can talk about dimensionality. You can talk about the location. How accurate is the information there? Is it actually in the exact position? What about the appearance?

What happens if you have a client that's actually very gunned-up for viewing their stuff in virtual reality or rendered fly-throughs? Maybe they want to be able to see the different finishes, and so they're going to actually require realistic finishes to be specified for certain output.

And that's just talking about the geometry. Then you've got the whole fact that there's all this information that's required for operations and maintenance, and there's going to be all sorts of alphanumeric information.

So think about exports into spreadsheets, things like door numbers, unit numbers, serial numbers, warranty information. So all of these additional pieces. Then you've also got documents as well on top of that.

So what this starts to look like, well, it starts to look very different depending on what type of units you're looking at. Because the other side of things is you can't just sort of say, OK, well, if you're looking at an air handling unit versus a door, maybe the door is a level one and the air handling unit is a level five.

But look at the parameters that a facilities group might be interested in tracking in a building automation system or a facilities management system that is completely different for those two different units.

So where we might sort of talk about the level of detail being different or its reliability being different, just the metadata alone, the different parameters that are going to be required within that, are going to be vastly different. And so, as you can see, starting to try to capture that in a simple Excel spreadsheet starts to be quite difficult.

And keeping in mind, even when you start to look at just one of those categories, an air handling unit, for example, might have all of these different parameters that are required as part of the as-built from the mechanical side of things and might be required from the mechanical sub-trade.

But that's going to be required-- a different deliverable might be required from a different group at each different milestone. So schematic design versus issued for construction might be completely different.

And think about this. The other side of things is that we've had a lot of fun when it starts to get into how do you define the actual outputs. Because if you're starting to talk about data, you have to start to talk about things like, well, what type of field is that? Is it a date format? Is it a number?

Is it a string value? How many characters can you have in that string value? You don't want people putting in a really long model description that ends up actually being exceeding the number of characters that you can put into the database.

So we need to know how all of this information is being delivered, in what format, and all these additional parameters. So, and is it going to be direct input or is it going to be exported? How is that information going to be transferred?

And so it starts to beg the question of maybe Excel is not the right answer in this case. And this is definitely something we have found true. When you start to look around the industry, there are different ways of gathering this information or even-- not even gathering the information, but just defining the requirements becomes quite a challenge.

And what I have on the screen here is actually a example from the UK BIM framework, where they've actually put together in Airtable, an online database format, the different potential requirements, data requirements, for a project.

And being able to put it into that format allows you then to filter for specific people. Because one of the other things that the ISO standard talks about is being able to filter down exchange information requirements based off of who's actually receiving it. So you don't actually give, for example, if you've got two consultants, you can filter out the architectural requirements for the architectural team and the mechanical stuff on the mechanical side of things.

So it starts to look at a need to apply almost a database format over top of this, a much more sophisticated system. There are also paid services that just do the documentation. There's groups like Plannerly that do this. There's databases that overlay on top of Revit such as dRofus.

Now you might also say, well, wait a second. I've heard about COBie. Isn't COBie supposed to be the answer? And wait a second. No, COBie is dead. We're not supposed to ask for COBie anymore.

The problem with COBie, for example, is when you look at it, it's got generic headings, and it was a potential way of answering some of this stuff, and it is one standard.

But there are certain situations where we've worked with clients where they actually just want certain other parameters, or they want to be able to filter that down to specific stuff that they track on their facility, and they'll grow that as time goes on. So COBie, just to keep in mind, is not necessarily the answer.

So we've been talking a lot about BIM. We've talked about the BIM standard, but what about the next evolution of this? Because you start hearing about, well, what about BIM for facilities management? Because when we've talked with our clients, they just seem to want the data, but they don't want the models.

And that is true right now. A lot of different systems out there for building automation systems are just looking at the non graphical data, the sort of stuff that you would find in an Excel spreadsheet COBie exports, that sort of stuff.

And there's not necessarily a requirement for 3D models. And why is that? Well, traditionally, facilities management and operations groups don't use 3D models. But why not?

And this is where it starts to beg the question of, well, what about building automation systems that could use a 3D model? Like, wouldn't that benefit a group? And it starts to beg a question that, well, there's a new term coming out that starts to answer that. And that is a digital twin.

So the digital twin. Let me just start by saying what the vision of it is. What are they trying to solve? Well, basically we've got a situation. If we just talk about buildings, and there's a lot of different ways you can apply digital twins out there in manufacturing and other things like that. But let's just talk about buildings.

Buildings are complex. Traditionally, they're disconnected systems, siloed systems. You've got the users inside them that are operating and using the facility, and you've got the environment around it. And this is all sort of disconnected data.

Now, as a facility owner or operator, you might be sort of saying, well, can't I understand more about my project? What happens if I want to run my facility better? What happens if I want to run my academic campus and really understand how the students are using it?

This starts to beg the question that they want to be able to understand anything and everything about that project, how it runs, how it's being used.

And we want to be able to monitor the present so we know what's happening in the project. But if we catalog and understand the past, we can sort of go back and sort of look at anything at any point. And if we've got those two pieces of information, that we can really potentially predict the future.

And we want to be able to understand this stuff anywhere, at any time. And the other thing about this is, well, buildings are 3D. We want to understand it spatially. So how do we do that?

So a digital twin starts to build up sort of a stack. It starts by creating a virtual copy of what's out there in the real world. Now, does this in the reverse.

We build the BIM file, the BIM model, and then we actually construct it out in the real world. So whether you're doing it one way or the other, you still need a 3D model of what's out there in the real world.

You then fill that project with all sorts of connected systems. So everything that you want to be able to monitor and maintain and optimize, you start to look at the connectivity.

So we start to look at, how do we integrate all the different sensors into it? How do we-- any piece of equipment, we start to make it connected, so a pump or a mechanical unit.

You're going to put a connection in there so you can monitor what's going on. Is it on? Is it off? How it's performing? We put in additional sensors so we can understand things maybe like occupancy that we don't normally have access to.

We're then going to put this all into a system where we can synchronize it with the 3D model. So there's a relationship between the 3D model and what's actually happening with the data.

We're going to store all of that, again, as I said, to monitor the past and the present. And then we're going to be able to start to apply, on top of that, analysis and simulation and automation on top.

So what that looks like is a stack this way. And so if we break down the different data pieces, you've got the spatial information, the 3D from the BIM file. You've got the asset information, which is like warranty information, serial numbers, model numbers, that sort of stuff. You've got all the IoT, or internet of things, so the connectivity of the equipment, so all their live information.

You've got how the occupants are going to be using it, and you've got the environment around it, maybe the outside temperature and inside, the weather conditions, the climate, all that sort of stuff.

You bring all that together. And the idea is to integrate and connect the data. Because if you can connect it and integrate it, you then can start to apply analysis simulation and automation over top of it so that you can start to optimize your building and start to look at where the inefficiencies are.

And the key piece of this that's important to note is that, well, BIM is part of that process. BIM is not necessarily being left behind in this. It's actually part of that stack.

Now, you might also look at this diagram and say, wait a second. This sounds a little bit like what I've heard about smart buildings. And yes, there are groups that are looking at it that way too.

In fact, there's whole groups that are dedicated to smart buildings. A great resource online that I recommend checking out is James Dice's website the Nexus Labs, which is sort of a collective of people that are looking at smart buildings.

And they've got some great diagrams for explaining how the traditional siloed approach just doesn't cut it because you don't have that integration.

But if you start to apply all sorts of connections and being able to sort of integrate things on a network layer and bring them together into an independent data layer, then you can apply certain applications on top to optimize them. So you get the applications on top.

And this is kind of just a different way of drawing that last diagram. Because what you'll note in the middle here is that it actually talks about that data model. And that data model, from some standpoints, may not be a 3D model, but if we start to apply 3D model into it, well, basically, it starts to build into what looks like a digital twin. And so there is a lot of crossover between the two.

Now, you might say, well, wait a second. Facilities management, they're looking at readouts on display boards. Why do they want the 3D model? And there is a lot of benefits to it. And I think that this is where there's huge potential within our industry to unlock.

And it may not be something that's requested right away, but if we start to look at how that graphical model is incorporated in it as well, you start to look at stuff like Autodesk Tandem.

The fact that you can start to spin around that model, take a look at it, reorganize the geometry, and look at it in different ways, but really it allows you to understand the spatial relationships. It allows you to understand that, hey, if something's not operating correctly, let's look at where it is in the building.

And if you can imagine, we've dealt with facilities management groups that are looking at this campus-wide. If somebody is on the other side of a campus, allowing them to understand what's happening in the building across campus is a lot easier through a 3D model than them walking across the campus to look at it. And imagine somebody that's managing a portfolio across the entire continent. This is something that becomes quite important.

The other side of things if you Google Howden Microsoft and PTC, and you watch this video, I think it gives you a great opportunity to get that vision of, well, what would happen if you took a Microsoft HoloLens and you compare it with a digital twin for facilities management?

Imagine walking into a mechanical room where the system actually recognizes where you are based off of the 3D model and starts to marry up the information that's in the digital twin with that so that you actually get the readouts of the information right there in front of you.

You could actually virtually press a button in the air and have it interact with a piece of equipment beside you because it understands the spatial relationship of what's happening inside the facility with what's happening on your visor, and it starts to marry up the two.

So you'll hear about all these different terms, and people will say, wow, we're moving way past BIM. BIM is dead. Yeah, we're doing digital project delivery. Yeah, we do project information modeling. No, no, no. We're all about digital transformation.

The truth of the matter is BIM is not being replaced. It's becoming part of something bigger. So if you're starting to look at smart buildings, it's asking the question of how can we build upon BIM, and not necessarily how we're looking to replace it.

So I personally find it really annoying sometimes when people say, oh, yeah. Can we stop calling it BIM? Because actually BIM isn't dead. It's just being incorporated into a bigger data stack. It's about digital transformation. It's about breaking down those silos. And all of the stuff that we talked about at the beginning is about bringing together information.

So the bigger question is, well, when you start to bring together the ISO standard, digital twins, how does this start to lead to innovation? So going back to that diagram. Remember how I defined-- you define your requirements up front. You make sure it's part of the contract so that they start-- consultant team delivers it as part of the information deliverables, and it can be fed into an asset information model.

Well, if digital twins is just another layer on top of that, why can't we use that same process. And this is something that we've discovered with our clients. Think back to the way we described the fact that these different levels of starting with things at an organizational level. And you'd say, well, how do you want to manage your asset?

Well, if you're potentially using digital twins, it just becomes that question of how do you want to actually collect the information to feed into working with your digital twin? And which is going to then, therefore, run your facility. So there's a bigger piece of this.

And so, what we've ended up doing working with clients is we've used the ISO standard as a framework. And again, try not to get too hung up on the fact that, yes, it says BIM on the front cover the ISO standard and that the certain terms are kind of hard to understand sometimes, but thinking more about the philosophy of what's behind it. Why are we doing this? What is the actual goal?

So when we start with a client and we talk to them, well, let's talk about your organizational requirement. What are your business objectives? What are you trying to achieve with your facilities on a business level?

Is it that you are trying to create a better experience for students? Is it the fact that you're managing a federal government-level portfolio of properties, and you need better control over what's happening in all of those? Is it the fact that you're doing a retail mall or center that you want to be able to understand how it's being used and how people move through it?

Well, all of these things could be achieved through a digital twin, but it has to start with that sort of high-level organizational requirements. But what starts to feed down the line is the fact that those can then start to feed into specific information requirements for those different pieces of the data stack.

Now, you might sort of look at this and go, yeah we're used to producing BIM models, and OK, we've gotten into exporting COBie and other databases and schedules out of stuff. But how do you get into things like IoT and occupancy data and sensors and things like that?

Well, not all of this stuff comes through as, specifically, information requirements that we then, therefore, actually deliver ourselves. Sometimes this information has to be transferred into project-level specifications so that it's actually delivered as part of the construction and delivery of the project.

There may be also rules of engagement. For example, we've had situations where we're implementing systems that we know need integration, but that integration might not happen for another five years because the systems just aren't there yet.

And so keeping that in mind, there are certain rules of engagement that need to be put in place so that if a system is put in place and we know that the other system has to interact with it, for example, an API is required, a way of accessing the data.

Because if a system is put in place that doesn't have those keys, those ways of unlocking the data and everything's siloed in a sort of proprietary, walled-garden approach, it may be great to work with on its own, but if it doesn't integrate with the rest of the system, it's not going to work for integration into a digital twin.

So these are things that we had to keep in mind as we worked through these requirements with clients. And we've actually sat down and actually created these organizational information requirements, asset information requirements, exchange information requirements, knowing that they need to build towards digital twins in the process.

And so we, again, come back to that high-level strategy. We use the ISO framework, even if we don't necessarily talk to our clients about, hey, we're going to be doing an ISO 19650 project. Just use it as a framework for having those conversations.

Start with them and say, what are those high-level objectives that you're trying to achieve on this project, and how can we get-- how are those going to be satisfied? Well, because you're going to run your facilities in a particular way. If you want to run your facilities in a particular way, you're going to have to ask for specific information, which then the designs and construction teams will deliver.

Now in doing this project or these requirements, one of the things that definitely comes up is this question of, well, how do we use that-- OK, so we've got those different steps that we have to go through. So where do we put these requirements?

And we did this whole exercise, and I know it's rather small, but I wanted to Zoom out to give you a sense of the sort of things, the way we mapped it out.

We'll get into the details of what's on the Post-it notes, but it's the idea that if you're starting with that organizational level you need to be able to see the relationship to how the facility is being run, and how the facility is being run will then define what's the specific information is required.

Or if there's a specific requirement on the project, you need to see the relationship going down that way. That way the only pieces of information that are being asked for are pieces that are going to be useful.

Many of you have probably heard of projects out there where somebody has asked for COBie. And then you go and ask the client, why are they asking for this big data export? And somebody says, well, because I read it online, and I think I'm supposed to ask for it. But not because they actually have a business driver behind it.

So it's understanding the relationships and the connections between the different pieces in the different buckets and understanding what those long-term goals are. If the long-term goal is a digital twin, we need to put things in place up front that then those business drivers that we then can achieve by putting the pieces on how we manage the asset and the specific requirements down the line.

And some of these pieces also might be future. They may not put them in right away, but you can start with those sort of first steps.

So the other thing about it is you might say, well, OK. I'm still a little bit unclear about exactly what goes under the exchange information requirements versus an asset information requirements, and I am too.

One of the things that the think that the ISO standard doesn't necessarily make clear is exactly which ones fall into which buckets. But in our experience, it doesn't necessarily matter which ones are in which buckets. Why? Because as long as you've got the information requirements in there, it's being communicated. And that's the key piece.

So whether or not you're, for example, have highlighted project delivery objectives, clash detection requirements. Is that part of the PIR? Is it supposed to be part of the EIR? Information container naming conventions-- so how you name your models that you're delivering-- does that fall under that or is it supposed to be under the AIR? As long as it's in there somewhere and it's communicated to the teams, that's what's important.

Now, there may be a question of is an OIR, for example, released to, for example, design teams? Maybe they just only receive the EIR. Now, if you're talking about a federal government or a academic institution, they might want to release that OIR.

If you're talking about a private real estate group, maybe they don't want to release it because it does have some of their high level business objectives.