Miquel Lahoz said:

Ultimately, the debate between using one or multiple tools should be purely commercial, because there will not be any difference in the data that will be generated. This is the true promise of the digital twin.

Not sure, but I think that your vision of a digital twin is a little too static. Even if the data incorporated into the DT is relatively static and does not change, there is still the cost and quality challenges that the information producers feeding into the DT will need to deal with. Don't forget that the productivity blockers engineers and designers face preceed DT's and will still be there after a DT is adopted. In many ways, DT's do not look very relevant to most daily workflows... currently.

To use your words, what does the Digital Twin promise the information producers, exactly? On the face of it, it promises to provide a smarter exchange format like the current i.dgn's or .ism does. imodel.js is the SDK for it and is open sourced to maximise adoption.

But, like IFC in the building sector, you do not work in this format. It is mainly for review and information storage for facilities management post design.

One potential 'promise' would be to enhance cross application interops. A good example of this is the structural discipline which has multiple analytical and design apps that need to speak to each other.

But looking at the slow progress of .ism's within the Bentley family, I think that the main problem is exposing and defining the dynamic behaviour of all the information that is converted into the ISM / Digital twin so that there can be bi-drectional translation. Takes a long time and probably means that the developers / domain experts will need to change the way they code from the outset.

Without this work, the information hosted by the DT will be relatively static and not very useful. You may say that the process of building a bridge app for the DT will the means of forcing the separate apps to 'expose and document' their info and this will lead to better interop... but this does not avoid the fact that this is a lot work. The result is that a lot of bridge apps only cover the basics and you are back to wishing everyone was on the same platform.

Indeed, there are several trade-offs around interoperability, and many pages have been filled with dilemmas such as flexibility vs. control, or standardisation vs. innovation.

For sure, it is a complex problem, which is the reason BIM never (yet?) realised the promise of true interoperability. There’s much focus on formats, but formats change all the time, or worse: they become stale and constrain future development. On the other hand, the issue with cross-application interoperability is the sheer number of 1-to-1 links that need to be updated and maintained (which, by simple combinatorics, grows at a factorial rate), unless some common ground is established.

Personally, I prefer to think of the digital twin as an open (and, yes, dynamic) modelling environment, where data rather than formats are at the centre; a truly CONNECTED data environment, flexible and accessible for many purposes from multiple applications (by Bentley or otherwise), locations, and disciplines, rather than a theoretical blueprint, rigid data structure, closed solution, or exchange format. I agree some level of data 'bridging' will still be necessary, but the objective is minimising the number of points where this needs to happen, and, when it does, making it as open and transparent as possible.

This is similar to the vision evoked by Bentley's open-source initiative, iModel.js. Coming from past experiences, I can understand how you’d think “how will it be different this time?”, but I believe we're getting closer to a (if not 'the') solution. Given that this is clearly a topic dear to you, I would also recommend keeping an eye for the announcements at Year in Infrastructure. I'd be curious as to whether, after watching them, you also think we're getting closer or rather the opposite.

Miquel Lahoz said:

I would also recommend keeping an eye for the announcements at Year in Infrastructure.

Can't wait..

OpenWindPower

... that was quick!

More details to come during YII.