At Bentley Systems’ recent ‘Year in Infrastructure’ event, we got the chance to catch up with CTO Keith Bentley and get his perspective not only on the company’s iTwin technology, but also the ‘platformification’ of the design software world
A study of Bentley Systems’ current marketing output could easily bamboozle the reader with its terminology and fool – them into thinking that the company’s only focus is now digital twins. For anyone led down that path, it’s important to keep in mind that the company is still solidly built around a single platform (MicroStation), its core DGN format, and its broad array of design and project management tools.
At the same time, the digital twin messaging and focus on iTwin services are about more than just marketing. In fact, they signify an important technology progression, from file-based, project milestone workflows to live databases that can ultimately be integrated with Internet of Things (IoT) and Bentley iTwin services for infrastructure lifecycles.
The first stage of this transition came with the introduction of the iModel back in 2007. An iModel is Bentley’s information container for data exchange — a selfdescribing, geometrically precise, portable and secure entity, containing the history of file changes and encapsulating information regardless of its original source, be that a Bentley tool or software from another vendor. Then, in 2017, Bentley launched iModel.js, version 2.0 of its iModel technology, providing spatial and unit alignment between the contents of iModels. At the same time, iModelHub was also introduced, in order to handle change management, time stamping and allocating changes to team members to support managed digital workflows.
As iModel.JS developed, it became clear that it was going to contain and do a lot more than just manage iModels. Its new roles included connecting to IoT devices, connecting and streaming geometry to Unreal Engine, storing reality data, and so on. It was renamed iTwin.js to reflect this expanded vision — a move that has caused some understandable confusion.
From there, Bentley open-sourced iTwin.js on Github under an MIT licence. The thinking here was that an open approach to users’ data is necessary because digital twin information will never come from a single source, requires a fusion of formats and has many layers. With this methodology, it’s possible for anyone to leverage the open-source code to create, query, modify and display infrastructure digital twins.
At Bentley Systems’ ‘Year in Infrastructure’ (YII) event, held in London in November 2022, we sat down with the company’s CTO and co-founder Keith Bentley to get his views on how this significant technology progression is unfolding.
Martyn Day for AEC Magazine (MD): Keith, I’d like to start by asking whether you can define a Bentley data lake workflow without concentrating on iTwins?
Keith Bentley for Bentley Systems (KB): We purposely use the iTwin brand to describe what I call ‘Phase Two’. Here’s what’s going to happen: You are using MicroStation, just plain old MicroStation. It’s the lowest common denominator. Everybody understands MicroStation — and here, I’m not saying you need a product like OpenRoads to get any value out of iTwins. What I am saying is you can be using products, and I expect many people will be using STAAD and other products that they have bought, where there is no such thing as a digital twin.
Over many years, you’ve built up a workflow that works. Of course, it involves DGN files for our products, mostly DGN. It might involve creating, exporting, importing SketchUp files etcetera. There’s a workflow that people use today to get their jobs done, and the output of their job is not a digital twin. In fact, it is largely drawings. So, what we’re going to do is deliver a version of MicroStation next year. It will have, within it, an engine, but it’s the iTwin platform embedded inside MicroStation.
So you’re using MicroStation, you’re opening up a DGN. These DGNs are being managed in ProjectWise, or you are using another file share service. The digital twin doesn’t change the way you start. You start with that DGN file and you’re going to end your session with that DGN file.
During your session, you modify a bunch of elements, you add a bunch of elements. The iTwin engine is running in the background and you either select to synchronise – or it can happen automatically, when you exit at the end of your session. Now, you’ve got an iModel. This is synchronised with all the changes that you’ve made and your DGN files are still your master file.
Drawings are stupid and the goal of BIM is to automate drawing creation
Now you have an iModel sitting on your desk, updated with the changes you just made to the DGN file. What good does that get you? For one thing, it gives you the ability to invite somebody else who has a web browser to look at the changes you just made. They are my changes, they haven’t been published by anybody other than me. I can now synchronise with the iTwin server.
Today, the way it works in the demos that we’ve been showing at YII, with our iTwin format, customers change the data on their desktop, they push that up to the cloud, where we run a copy of a programme that effectively mirrors MicroStation in the cloud and it updates the iModel in the cloud.
The phase lag can be minutes, hours, depending on many things — but usually, people don’t do it often. Instead, they only do this at project milestones, only when they then generate the PDFs for the milestone. The iModel is always out of sync, it’s not up to date, nobody has it on their desk. So nobody thinks of it when you’re using MicroStation as being relevant to the job.
But because you now have an iModel, you don’t have to do any extra work and use a different tool to create the iModel. You didn’t end up with a different DGN file. It’s the very same DGN file. Now, when you’re at the point where you’re going to push your changes to ProjectWise, we push them into an iModel on your desktop. So now there’s an iModel that exists that includes all the users’ changes — but only the changes between milestones get recorded. They don’t include the changes in between milestones. But now the iModel has the ability to store the whole team’s collaboration history.
MD: Will this support real-time collaboration?
KB: In MicroStation or OpenRoads today, you have a DGN file, you have it locked, perhaps I have a copy of it. But I can’t make any changes. We can’t change the way that that works. Those locks are there so we don’t conflict. It doesn’t change that. This iModel is merely a journal of what happened. It doesn’t include new capabilities for you and to be on the same model at the same time. It’s a cache, but it’s more than a cache, as it’s been transformed and combined.
If we were working on a project together, people segregate their data into files, for locking purposes. We have to decide who takes what file and what part of the project will be done in that file. And another user is going to work on a different project — otherwise, you can’t write to them at the same time. In the iModel, they’re all combined. They’re geo-located, so that if you’re using five different tools inside the same iModel, I can do a query and find everything in this volume of space – and that’s really hard to do in a DGN. They’re also synchronised, right, so that you have this journal of change and you can push that to the cloud.
So, for now, the iModel someone else creates for me is on my desk. Now what? Well, there are some really cool things we can do. We can give you the tools that we’ve written to do carbon footprint analysis, clash detection, consistency checks, etcetera. We can run that against the iModel on your desktop. And it didn’t cost you anything, because you already paid for that computer. If you don’t use the cycles, they go to waste. If we run it in the cloud, somebody’s got to charge you and give you feedback. The iModel tells you when someone else just changed something that affected the thing you’re working on. So we can start improving the process of creating the data, even though the master copy is still a DGN file. People will start to recognise that iModel isn’t ‘an output’, it’s just sort of ‘always there’. It’s a second copy of my data. So why do you need two copies of your data? Well, because we can’t change the way that OpenRoads works with DGN data, as well as other data files and stuff.
MD: Will you start rewriting the apps to use iModel as the new format?
KB: If you have been using OpenRoads for a long time, you are now going to have some new features that are going to be in the iTwin model. Maybe it’s in a separate window, but wouldn’t it be really cool if we then start adding some new capabilities that are in the iModel part of it? Over time, the iModel part of it grows and the DGN part of it shrinks, and by the time we are done, you’ve gone through the transition and you are only working on iModels. It’s not going to happen all at once. It’s going to take years. It has taken us five years to get us to where we are now. Do you think that’s quick for the AEC industry? [laughs]
MD: Was this because of Covid?
KB: Covid didn’t really hurt us. When you think about adoption of new technologies, people were way more interested in doing things differently during Covid. They had to do things differently. If it hadn’t been for Covid, I don’t think we would have been able to convince people to start to have digital design review meetings. Online meetings were necessary because they couldn’t physically be in the office. They were presented with a fact: the old way couldn’t be the current way.
We need to go fast. But we should expect that only incremental change gets adopted. But what I hope is that, in the mental world view of the designer using MicroStation, they think their purpose in life is not to modify the DGN, but to modify the iModel. Even though to modify the model, they first modify the DGN file, DWG or RVT, even if they’re going to use a different tool. But when they’re done, they’re going to look at what’s in the iModel, what’s in the digital twin.
I know you think “There’s that term” — that term ‘digital twin’, which you say that not many people want to hear. But I don’t think they don’t want to create a digital twin. When they get paid for it, they will care about it. When we start giving them ways that they can be more productive, add more value, they’ll wish for a digital twin.
MD: But people naturally switch off when a message gets repetitive. It’s always about change. How about them getting value from the stuff that’s already been paid for and delivered?
KB: I do concede that. But I think a digital twin is a big thing. Drawings are stupid and the goal of BIM is to automate drawing creation. And here’s an easy step forward. I want the world view to be that, at the end of a design session or after a period of work, users think: “I’m going to commit my changes now and modify the digital twin.” And, in the case of our users, an iTwin.
DGN files are of course important. You can’t throw them away — but everyone who’s looking at my work and commenting on whether or not a change had some kind of positive or negative impact, they’re going to evaluate the iModel. We have to get people using smart tools to analyse the current state of projects and looking at past stages of other similar projects to get feedback. I don’t think that’s going to happen with a bunch of loose DGN and RVT files being the input for machine learning, especially not when they’re all in different coordinate systems.
MD: At our NXT BLD event, and in AEC Magazine, we’ve been covering industry initiatives to get data out of proprietary file formats and into data bridges that span the silos and deliver entity-level exchanges. What’s your view on that?
KB: Well, that’s another reason why I assert that automatic creation of iModels is better. With OpenRoads and DGN, it’s a great product — but while the product is called ‘Open’, the data is not. It’s open by interface but, in reality, there’s nothing we can do to make DGN files open, even if we wanted to. To publish the format of a DGN file, we would have to publish a bunch of code. It’s miserable, because even if we documented it all, it wouldn’t make sense, as it’s kind of defined internally to represent the data in memory that OpenRoads uses.
When people say files are bad, they mean that loose files, lots of files, are bad. One big file, like an iModel, is still a file and it’s a big file — like a gigabyte file — but they are in a database and that means they are as open as we can make them.
So another large difference between iModels and let’s say Revit RVT files is that I don’t send you my iModel, I just send you my changes. And these transactional changes are small, even if the database is big. I don’t even know what kind of change it would be that would end up having touched every object making a modification to every object.
Looking ahead
While our conversation mainly wandered around in the weeds of industry data structures, these are fundamental concepts when it comes to understanding how the AEC industry is likely to change over the next five to ten years.
Platforms being designed today cannot deliver productivity enhancing capabilities if they are based on old data schemas. As Keith Bentley pointed out, drawings are dumb.
For Bentley to help its customers transition to an iTwin outlook, iModels are fundamental to future direction, and it was fascinating to return to this topic. Somehow, this point has got somewhat lost in the deluge of messaging around iTwin and the wider digital twin focus.
The move to build in automated/parallel iModel creation perhaps indicates that previous innovative work at Bentley has failed to gain traction, in an industry that can be notoriously slow to adopt new technology.
If the success of the iTwin technology relies on the uptake and proliferation of iModels, things need to change. Over the next few years, iModel looks set to quietly replace DGN-centric workflows at the core of MicroStation, bringing new capabilities and features. Even customers that are not explicitly planning to deliver digital twins will nevertheless be ‘digital twin ready’.
Bentley executives are keen to point out that files will never disappear from the process — and this is a company that I have only ever seen change its core file format once. So I trust Bentley to deliver this transition without disruption to customers.
