Thanks for the update. I just had a look at Explore the Possibilities with Conceptual Plant Design which goes into the Plantwise SS6 new features. There is a section in the back end of the presentation, where the user is shown how to copy the Plantwise elements into a dgn file and DROP the pipes generated in Plantwise so that their centrelines can be used to MANUALLY re-create the pipes in OpenPlant. I hope that this kind of jerry-rigged low levels of interoperability will be corrected soon. There seems to be a pattern set over the years: 1. Distributed Dgn's: Or the old Design History. First step of the ladder. The problem was that only the geometry was tracked. The parametric and non-graphic info was not tracked very well or at all. No schemas so I suppose tracking non-graphic data and how that data is handled/constrained would be pretty problematic. 2. I-models: Each app writes an exporter to convert its internal data into ECFramework schemas that get attached to the i.dgn on export. Read-only which is helpful for information consumers like compliance checkers or programme monitors or estimators but NOT really very helpful for the producers of the information. 3. ISM: Each app writes a synchroniser plugin to write as read information from a centralised 'database'. Since the external app's tools are not available, the native app's tools would need to run when the incoming changes are synchronised from the ISM. Transaction management and mapping/healing settings stored with the ISM. You see demos of ISM where a wall or beam can be moved in a design or analysis or detailing app, and the changes re-enacted in the other apps on synchronisation. I guess that by providing schemas, common elements like the beam end points etc gets 'type-checked' before hand and optimises the translation process. Great, but there is still a lag or barrier. 4. Multi-disciplinary 'suite' apps: OpenPlant and ABD have multiple toolsets that can be loaded in the same session. When a structural member needs to be moved to make way for mech ducts or pipes or electrical trunking etc, the tools are available to handle the different schemas in the same session. No ISM etc required as the tools write to their own data attachments (ABD) or a centralised DB (OP). But there will still be lots of external apps to deal with... coming up the 'interoperability ladder'. 5. SMC: OpenPlant SS6 now includes some common Structural Modeling Components, which also includes a grid tool that is common to ProStructures and ABD. Maybe there will also be common piping, ducting and electrical modeling components soon? ProjectWise and Connect is about providing a Common Data Environment (CDE), Mstn CE Functional Components is supposed to provide a Common Modeling Environment. Some of the newer Bentley apps like OpenBridge Modeler seem to be able to incorporate schemas and modeling tools from other apps. In the case of OBM, the user has tools to modify the roadway alignment (OpenRoads?) and closely integrated with LEAP/RM analysis packages. Minecycle seems to incorporate ConstructSim and PowerCivils functionality. Maybe, some day all Bentley products will have the same level of interoperability as Catia has with its Workbenches . Instead of developing a structural or electrical tool without any thought about interoperability, the SDK should force the developer to develop the tool as a 'common component' from the start, to be portable and able to contribute as part of a CONNECT'd PowerPlatform.
↧