One Configuration: Part 3 of 3 – Using iModels for Sharing Design Content Across Bentley Applications

In the previous Configuration Series blog, you saw how to include Bentley applications in your existing projects. That is fine for sharing standards across Bentley applications. However, what about sharing design content across applications? For example, in a project, a Civil Engineer creates a road design in OpenRoads Designer (ORD), an Architect designs a building in AECOSim Building Designer (ABD), and an Electrical Engineer is designing a power substation using Bentley Substation. The Civil Engineer wants the building to be placed on the roadside to check if it places at proper location and also check the substation location. The easiest way to do this is referencing the building and substation design files directly into the road design in ORD. This works seamlessly for simple cases, where you don’t want to use cross-application elements or element properties.

However, consider a scenario, where you use the unique properties of elements created in one application that are not applicable/supported or are only partially supported in another application. For example, when designing the building, the Architect creates a temporary fence wall alongside the building which will be demolished later. While placing this wall, he assigns Temporary Construction value to the Construction Phase property. Now, when this building is referenced in ORD, the Civil Engineer will see this wall element, which may run over the road design. If the referencing is done directly, the Construction Phase property isn’t read by ORD, and hence the Civil Engineer will find clashes between the road and the building.

On the other hand, if the Architect and Electrical Engineer publish an iModel out of their designs, all the element properties are saved in the iModel. When the Civil Engineer references these iModels into ORD, the Construction Phase property is seen with value Temporary Construction. The Civil Engineer can read this and if required, tag the wall element as Temporary and continue with his design.

There are many other advantages of using iModels in your workflows:

  • light weight, hence iModel files and referenced iModels load faster and navigation is easier
  • being read-only, iModels are secure and easy to share. Also, using iModels instead of actual DGNs prevents corruption of source data.
  • semantically rich data file that contains the related business information from the design applications
  • high fidelity graphic display
  • interoperable and read by Bentley applications as well as many non-Bentley applications
  • designed for information re-use, can be published into standard pdf and xml formats
  • useful for version control and iterative workflows

What we saw in our example is a one-time referencing. However, in the real-world, there are design changes at different stages of a project and you need to always have the updated content. In such cases, following workflow with iModels is suggested:

  1. Architect and Electrical publish their building and substation iModels respectively in the WorkSet’s OUT folder.
  2. The Civil Engineer references the iModels by relative path.
  3. When there are any changes to the building design, the Architect republishes with the same name. Same is the case with the Electrical Engineer.
  4. The Civil Engineer automatically gets the updated reference the next time he opens the roadway design.

Translated German Wiki article:
CONNECT Edition - Eine Konfiguration: Teil 3 von 3 - Verwenden von iModels zum Freigeben von Designinhalten in allen Bentley-Anwendungen