Object-Oriented Modeling
- Use of standalone modules (EICEcubes) for building models (objects)
- EICEcube models are portable across the EICEbox platform (and shared between users)
- A model created by one EICEcube is referenced by models built by other EICEcubes
Example
A base model of a fluid is built in the standalone application PVTcube (an “EICEcube” module in the EICEbox platform), which is then used by models for pipes (with pipeCube – an EICEcube) and wells (wellCube); eventually all standalone modes built through the individual EICEcube modules are used in an overall model of the gathering network (netCube), which is subsequently used in supporting Digital Oilfield workflows.
This unique object-oriented model-building architecture offers several advantages both in the obvious efficiencies achievable from a modular approach to the development lifecycle, but also in limiting model duplication for the end user (and more so in a collaborative cloud-based environment supporting cross-disciplinary workflows).
Example Interface Layout
The design of an effective interface for engineering software requires an understanding of the workflows being supported by the application.
A typical engineering design application software tool requires static configurational data as well as dynamic case-specific operations data in the form of setpoints and related boundary conditions. When this design application is adapted for the operations environment, the setpoints may be automatically updated (e.g. through process automation).
The following figure illustrates EICE’s approach to the separation of static configuration parameters from operations-specific data for the input section to a well modeling solution supporting both design and operations applications
Model Input
The left hand side of the interface screen supports the static configuration (or “Definition”) of the model, whereas the right-hand Case Analysis section supports boundary and operating information, whether maintained manually for case analysis in a design workflow, or automatically updated with field data in an operations-driven workflow.
Similarly, the results from the analysis are summarized in an overview schematic, using distinct background shades to enable the user to differentiate between static information (dark) and model results, with relevant limit violations requiring attention highlighted.
Model Results
Units of Measure Management
- Every data category in the central data repository is associated with a unique Measurable Property (which may be zero when there is no associated conversion)
- Every Measurable Property defined has a unique Canonic Unit of Measure (Canonic UoM)
- A Measurable Property has one or more associated Units of Measure (UoM)
- A UoM has a UoM Multiplier (default = 1) and a UoM Adder (default =0) relating the value of the property in the Canonic UoM to the value in the actual UoM Value in Canonic UoM = Value in UoM x Multiplier + Adder
- A Unit Set is a set of Measurable Properties, each with a unique Unit of Measure selected from the defined UoM list associated with the Measurable Property
- Every database,application or interface is associated with a defined Unit Set
- Every interface that involves transfer of data incorporates a Unit Conversion service (separate for each direction)
A common requirement for engineering applications is a need for the solution to be deployed in multiple environments. Instead of the traditional approach of adapting specific solutions to separate workflows through duplication (along with the associated burden of maintenance), EICE employs an architectural strategy where the core application is built in a common environment, with flexible internal interfaces to supporting elements specific to individual workflows.
The following figure illustrates how EICE has developed the architectural flexibility for an engineering application for supporting workflows in both traditional design as well as in operations analysis, leveraging real-time data
In this example, the rigorous analysis for a downhole submersible pump sizing application for engineering design (inside the green box outline) is adapted for use within the same architectural environment for operations-driven digital oilfield workflows (red outline)