5. OpenBridge Modeler <> OpenRoads and RM/LEAP Bridge
OBM can already consume OpenRoads alignment information, and the analysis apps RM/LEAP can consume OBM info and ProSturctures can take OBM info.There seems to be tight integration between the apps OTB... without having to use ISM or i-models as halfway houses. It would be interesting to see how this was done and what lessons and tools can be re-used elsewhere.
6. Axsys/PlantWise and OpenPlant
Future opportunity. Axsys/PlantWise are powerful front end tools that are unfortunately not fully integrated into OpenPlant. It would be good to see how how the time/streaming information that Axsys handles can be dealt with. WaterGEM's and I suppose if Hevacomp / Aecosim Energy Simulator will be enhanced to deal with SCADA info, some streaming database SDK's will emerge?
The mid-level SDK would provide templates for information storage that have a common:-
- Taxomony for all those attributes to avoid duplication. Type safety? Steel sections should be 'easy' example. Electrical Equipment next with Siemens investment?
- Structuring schema. All those attributes will need to organised in a hierarchy / object oriented. Probably need to agree translation to relational format as well? Self documenting like Revits EStorage? Can ISM or i-model conversion API provide the basis?
- Set of patterns for accessing (including nested elements) and updating the information. Need to subscribe to a common 'dynamic update' traffic cop that would marshall updates between apps modifiying the same data, and provide failure/recovery/debugging tools. Ideally, this should be provided by dotNEt assemblies provided by all verticals.
- GUID system, so that if required, multiple apps can intelligently react to changes. Extension of the Design History / ISM/DesignSync stuff? I suppose SQLite will alrady do this.
- Patterns for commonly needed things like drawing production (look at how many separate Bentley apps have gone there own ways here. ABD, PS, Speedikon, OpenPlant, AutoPlant etc), report generation, quantification (ABD quantification is a bad joke, and Mstn is just as incomplete), model-based annotation (extract steel beam info and attach label or table in drawing/sheet model)
- Patterns for a selection of database storage storage strategies:
- Store on element in dgn. Schema definiton store centrally. This is the way ABD's DGS, Mstn's Items, Element Templates works.
- Store centrally and check out for editing. This is OpenPlant ModelServer's way of doing things.
- Store in SQLite database in dgn. WaterGEMS.
- Store in D++ FROBS KBE-based database. PlantWise.
- Store using Mstn's Rendering Materials system. Luxology node based graph?
- GeoJSON coming soon with Cesium?
- Store in separate database or excel sheets with MSlinks. Bentley DataManager?
- ??
- Patterns for locking information; managing propagation to/from datafields. Item Types has acknowledged that the ability to lock parameters or attributes would be useful. For D++, this would be normal practice, and has mechanisms for including user defined rules/checks/constraints.
- Patterns for geometric LOD. Maybe based on the new 'Common Modeling Environment' Parametric Content Modeler / Solids API.
- Patterns for LOD management: Lower LOD element automatically hidden by a present higher LOD element. Example: A low LOD steel beam generated in Aecosim will be automatically hidden by a higher LOD version generated in ProStructures. Display Rules? Element / Display Handlers?