It will be necessary to send digital twins to customers for consumption/review in the same way drawings are sent to customers today.
Currently, deliverables management is an excellent workflow for sending files and documents to customers, and interacting with those documents. The iTwin team has also created a workflow to generate an iModel from an existing iModel.
These two features need to be brought together to create the digital future of infrastructure that we want. Sending your work to a customer in the format of a digital twin, that "just works' is the innovation we need to make model-based design, digital delivery, and more, mainstream in the industry.
|
Practical use of functionality?
Model Reviews, Bidding of Models, and use of models during construction and asset management are much more feasible if the engineer can send their work in the format of a digital twin as easily as they send their work in PDF format today. |
|
|
What is the impact of not doing this?
Without this feature, the adoption of 3D models, digital twins, and digital delivery in the transportation industry could be delayed significantly. This feature could be the "game changer" that accelerates the industry by several years. The lack of this feature could be the reason it takes several years longer. |
Adding my support for this idea. The current implementation of iModels does not match the implementation of documents. iModels should be treated no different than a drawing or report for the purpose of submissions and reviews. An iModel should be able to be "submitted" to the client.
We function as the client. Our current workaround to this is that we need to invite some members of the contractor organisation into our Infrastructure Cloud project so that we can collaborate on the model and comment back and forth. It makes it messy handling permissions, and adds risk of the contractor accessing something they shouldn't.
In summary, fix collaboration so that you can collaborate on a single iModel between two Infrastructure Cloud projects.
Further into this ( get inspire by mother nature mitosis)
The same we can share a work Area with a client, we should be able to share iModel with the client.
This way, the client can interacte with the data of the main project but from it's own project ( which is a satellite project of the main one).
Example: Client can raised issue visible from both side OR raise issue visible on his side only.
The same logic can be apply to PDF.
I undertand the need for transmission for contractual review and contractual reason.... But what if we bring the transmission intelligence into an issue/form?.... to which we can assisg a category (Contractual review).
It is a paradigm shift but that could make information exchange more fluid...
It is, seeing a project like a manufacturing assembly line, where documents and iModel travel on a coveyor belt. And at each station workers add value to the project.
The handover to client might be easier as well, we define cutoff criterias. When does criterias at meet, data will mitosis into the client space and the client will become the owner.
Imagine if we have mulitple parties involve the transfert of data will be much simplier and accurate. And along the project life we could reduce the duplication of information as mitosis could be better control.
In the example above. The shared work Area will be detach from the JV. Leaving two original copy of the same dataset. One in the JV space and one in the Client space.
A good use of block chain as if one side change somehting........ the block chain will be broken or Update OR...........