| Produkt(e): | MicroStation | ||
| Version(en): | 10.11.00.36 | ||
| Umgebung: | N\A | ||
| Produktbereich: | Konfiguration | ||
| Produktunterbereich: | Arbeitsbereiche |
Diese Wiki ist eine deutsche Übersetzung des folgenden englischsprachigen Blogs:
https://communities.bentley.com/products/microstation/b/microstation_blog/posts/configuration-blog-series-using-imodels-for-sharing-design-content-across-bentley-applications
In der vorherigen Wiki zur Konfiguration Serie haben Sie gesehen, wie Sie Bentley-Anwendungen in Ihre vorhandenen Projekte integrieren können. Das ist gut für die gemeinsame Nutzung von Standards in Bentley-Anwendungen. Wie sieht es jedoch mit der gemeinsamen Nutzung von Design-Inhalten in Anwendungen aus? In einem Projekt erstellt beispielsweise ein Bauingenieur einen Straßendesign in OpenRoads Designer (ORD), ein Architekt entwirft ein Gebäude in AECOSim Building Designer (ABD), und ein Elektroingenieur plant eine Umspannstation mit Bentley Substation. Der Bauingenieur möchte, dass das Gebäude am Straßenrand platziert wird, um zu überprüfen, ob es sich an einem geeigneten Ort befindet, und auch den Standort der Unterstation zu überprüfen. Der einfachste Weg, dies zu tun, besteht darin, die Konstruktionsdateien für Gebäude und Umspannwerke direkt in den Straßendesign in ORD zu referenzieren. Dies funktioniert nahtlos in einfachen Fällen, in denen Sie keine anwendungsübergreifenden Elemente oder Elementeigenschaften verwenden möchten.
Stellen Sie sich jedoch ein Szenario vor, in dem Sie die eindeutigen Eigenschaften von Elementen verwenden, die in einer Anwendung erstellt wurden und die nicht oder nur teilweise in einer anderen Anwendung unterstützt werden. Bei der Planung des Gebäudes erstellt der Architekt beispielsweise eine temporäre Zaunwand neben dem Gebäude, die später abgerissen wird. Beim Platzieren dieser Wand weist er der Eigenschaft Bauphase einen temporären Bauwert zu. Wenn nun dieses Gebäude in ORD referenziert wird, sieht der Bauingenieur dieses Wandelement, das über das Straßendesign laufen kann. Wenn die Referenzierung direkt durchgeführt wird, wird die Eigenschaft Bauphase nicht von ORD gelesen, und der Bauingenieur kann Konflikte zwischen der Straße und dem Gebäude feststellen.
Wenn der Architekt und der Elektroingenieur dagegen ein iModel aus ihren Entwürfen heraus veröffentlichen, werden alle Elementeigenschaften im iModel gespeichert. Wenn der Bauingenieur diese iModels in ORD referenziert, wird die Eigenschaft Bauphase mit dem Wert Temporäre Konstruktion angezeigt. Der Bauingenieur kann dies lesen und bei Bedarf das Wandelement als temporär kennzeichnen und mit seinem Entwurf fortfahren.
Stellen Sie sich jedoch ein Szenario vor, in dem Sie die eindeutigen Eigenschaften von Elementen verwenden, die in einer Anwendung erstellt wurden und die nicht oder nur teilweise in einer anderen Anwendung unterstützt werden. Bei der Planung des Gebäudes erstellt der Architekt beispielsweise eine temporäre Zaunwand neben dem Gebäude, die später abgerissen wird. Beim Platzieren dieser Wand weist er der Eigenschaft Bauphase einen temporären Bauwert zu. Wenn nun dieses Gebäude in ORD referenziert wird, sieht der Bauingenieur dieses Wandelement, das über das Straßendesign laufen kann. Wenn die Referenzierung direkt durchgeführt wird, wird die Eigenschaft Bauphase nicht von ORD gelesen, und der Bauingenieur kann Konflikte zwischen der Straße und dem Gebäude feststellen.
Wenn der Architekt und der Elektroingenieur dagegen ein iModel aus ihren Entwürfen heraus veröffentlichen, werden alle Elementeigenschaften im iModel gespeichert. Wenn der Bauingenieur diese iModels in ORD referenziert, wird die Eigenschaft Bauphase mit dem Wert Temporäre Konstruktion angezeigt. Der Bauingenieur kann dies lesen und bei Bedarf das Wandelement als temporär kennzeichnen und mit seinem Entwurf fortfahren.
Die Verwendung von iModels in Ihren Workflows bietet viele weitere Vorteile:
-
Geringes Gewicht, daher werden iModel-Dateien und referenzierte iModels schneller geladen und die Navigation wird einfacher Da iModels schreibgeschützt sind, sind sie sicher und einfach zu teilen. Durch die Verwendung von iModels anstelle von tatsächlichen DGNs wird die Beschädigung von Quelldaten verhindert.
-
Semantisch reichhaltige Datendatei, die die zugehörigen Geschäftsinformationen aus den Designanwendungen enthält High-Fidelity-Grafikdisplay
-
Interoperabel und kann von Bentley-Anwendungen sowie von vielen Nicht-Bentley-Anwendungen gelesen werden für die Wiederverwendung von Informationen konzipiert und kann in den Standardformaten pdf und xml veröffentlicht werden
-
Nützlich für Versionskontrolle und iterative Workflows
Was wir in unserem Beispiel gesehen haben, ist eine einmalige Referenzierung. In der Praxis gibt es jedoch Designänderungen in verschiedenen Phasen eines Projekts, und Sie müssen immer über den aktualisierten Inhalt verfügen. In solchen Fällen wird folgender Workflow mit iModels vorgeschlagen:
-
Architekt und Elektrik veröffentlichen ihre Gebäude- und Unterstations-iModels jeweils im OUT-Ordner des WorkSet.
-
Der Bauingenieur referenziert die iModels anhand des relativen Pfads.
-
Wenn Änderungen am Gebäudeentwurf vorgenommen werden, wird der Architekt mit demselben Namen erneut veröffentlicht. Gleiches gilt für den Elektroingenieur.
-
Der Bauingenieur erhält automatisch die aktualisierte Referenz, wenn er das nächste Mal das Straßendesign öffnet.
Sehen Sie hierzu auch
X
Anderssprachige Quellen
