AU2006279464B2 - Modeling application development in the petroleum industry - Google Patents

Abstract

. A modeling framework (120 of fig. 1) configured to facilitate integration of complex software applications in the petroleum industry including: (a) a graphical modeling language including: (1) classes including a plurality of oil field asset components, connectors, and grammar defining allowed and necessary connections between asset components configured and adapted for making a plurality of graphical models compliant with the graphical modeling language, where the graphical models represent a plurality of oil field asset components and the connections between them and each model having a plurality of levels of detail; (2) the graphical modeling language configured and adapted for modeling the asset components of different oil fields having different numbers, types, and configurations of asset components; and (b) a model interpreter (150) for each plurality of software applications domains specific to the oil field for storing, analylzing, displaying, or manipulating oil field data associated with at least one of the oil field asset components, each model interpreter configured and adapted for passing information between the plurality of oil field asset components.

Description

WO 2007/022289 PCT/US2006/032014 5 MODELING METHODOLOGY FOR APPLICATION DEVELOPMENT IN THE PETROLEUM INDUSTRY This application claims the benefit under 35 USC 119 of Provisional 10 Application No. 60/708,643, filed August 15, 2005. 1. FIELD OF INVENTION The present invention relates to a modeling methodology for application 15 development in the petroleum industry. II. BACKGROUND OF THE INVENTION The development of applications for monitoring, control, simulation and 20 diagnosis in the petroleum industry involves a multitude of complex software tools. These tools have their own formalisms, semantics and use different abstractions to represent the system under development. They use different data formats to represent data in the software tools. Each application requires coupling of two or more different such complex software tools. Providing 25 efficient interaction between these complex software tools using different abstractions, formalisms, data formats, etc. becomes a mammoth task. Thus there is a need to provide a unified environment that allows capturing the desired application and provide a framework for interaction between the necessary software tools. This invention provides formal metamodels to 30 describe the individual formalisms in the desired unified environment. These metamodels, created preferably with a modeling development environment, e.g., the Generic Modeling Environment (GME), define the domain-specific modeling language for application development in the petroleum industry.

WO 2007/022289 PCT/US2006/032014 5 For the past few decades, there has been a constant effort to maximize the oil production using various complex simulation tools. There has been a need for providing an efficient decision support system, which requires proper interaction between these complex simulation tools. Integrated Asset 10 Modeling is the technique used to model different assets (physical: wells, blocks, etc.; non physical: control strategies, optimizers, etc.) to provide efficient management between the assets. The petroleum industry has recognized the opportunity for Integrated Asset Modeling to address multiple challenges. Integrated Asset Modeling is an "enabling technology" for 15 Integrated Asset Management (IAM). Integrated Asset Management presents an intensive operational environment involving continuous series of decisions based on multiple criteria including safety, environmental policy, component reliability, efficient capital, operating expenditures, and revenue. Asset management decisions require interactions 20 among multiple domain experts, each capable of running detailed technical analysis on highly specialized and often compute intensive applications. These technical analysis executed in parallel domains over extended periods can result in divergence of assumptions regarding boundary conditions between domains. A good example of this is pre-development facilities design 25 while reservoir modeling and performance forecasting evaluations progress. Alternatively, many established proxy (or reduced form engineering) models are incorporated to meet demands of rapid decision making in an operational environment or when data is limited or unavailable. The delivery of enriched information that results from this technical analysis into real time operational 30 domains is another challenge addressed by lAM. A consequence of these previous conditions is the additional demand for rapid delivery of relevant data to these applications at the desired frequency and/or density, synchronized in time over multiple sources. -2- WO 2007/022289 PCT/US2006/032014 5 Large volumes of data from multiple sources result from progressively improving new capabilities for well measurement, seismic data acquisition, and continuous data collection. The systems are used to monitor and control an asset component in the petroleum industry to gather and analyze data in real time. Integrated Asset Modeling ensures proper coordination between 10 data collection sources and data processing destinations. The asset management toolkit needs to be configurable and custom fit for purpose to handle a great diversity of needs over a large portfolio of assets that range from big to small, low cost - low volume to major capital-high volume, onshore-offshore, brownfield (mature) to greenfield (new 15 developments). It is also desired to implicitly couple technical compute applications to run as one distributed system while maintaining component ownership within the respective domains. A need for optimization of the asset that encompasses all system components and potentially involves multiple nested optimization loops and sequences of actions within a control strategy 20 also forms an important challenge addressed by IAM. The industry has made some progress towards more integrated approaches to managing and operating assets. Integrated operational workflow mapping to ensure efficient and aligned use of critical resources is often the first step. Top-down modeling using simplified models or proxies to support flexible 25 decision and uncertainty analysis systems has been applied. At a more fundamental modeling level, application developers have coupled reservoir, network, and process simulators to more accurately model physical interactions between system components with a view to system integrated optimization. The variety of possible combinations of simulation technologies 30 requires developing flexible coupling schemes, and patterns of interaction between software components. The tight integration of the software and its physical environment has profound impact on the software technology to be applied. Conventional software development techniques consist of a number of phases: (1) defining 35 what the system should do (system specification), (2) choosing a particular -3- 5 solution to meet the system specifications (design), (3) actually puffing together the pieces of the system (implementation and integration), and (4) evaluating the new system to see if it actually meets the specifications (testing). This invention seeks to overcome the above-described shortcomings of 10 known methods and systems. Ill. SUMMARY OF THE INVENTION The invention in one embodiment includes a modeling framework configured to facilitate integration of complex software applications in the petroleum 15 industry including: (a) a graphical modeling language including: (1) classes including a plurality of oil field asset components and connectors and a grammar defining the allowed and necessary connections between the asset components configured and adapted for making a plurality of graphical models compliant with the graphical modeling language where the graphical 20 models represent a plurality of oil field asset components and the connections between them and each model having a plurality of levels of detail; (2) the graphical modeling language configured and adapted for modeling the asset components of different oil fields having different numbers, types, and configurations of asset components; and (b) a model interpreter for each of a 25 plurality of software applications specific to the oil field domain for storing, analyzing, displaying, or manipulating oil field data associated with at least one of the oil field asset components, each model interpreter configured and adapted for passing information between the plurality of oil field asset components. 30 A method of modeling and integration of complex software applications in the petroleum industry including: Making at least one model of an oil field using a graphical modeling language including: classes including a plurality of oil field asset components and connectors and a grammar defining the allowed and necessary connections between the asset components configured and -4- 5 adapted for making a plurality of graphical models compliant with the graphical modeling language where the graphical models represent a plurality of oil field asset components and the connections between them and each model having a plurality of levels of detail; the graphical modeling language configured and adapted for modeling the asset components of different oil 10 fields having different numbers, types, and configurations of asset components; and making at least one model interpreter for each of a plurality of software applications domains specific to the oil field for storing, analyzing, displaying, or manipulating oil field data associated with at least one of the oil field asset components, each model Interpreter configured and adapted for 15 passing information between the plurality of oil field asset components. These. and other features and advantages of the present invention will be made more apparent through a consideration of the following detailed description of a preferred embodiment of the invention. In the course of this description, frequent reference will be made to the attached drawings. 20 IV. BRIEF DESCRIPTION OF THE DRAWINGS Embodiments of the present invention are illustrated with reference to the accompanying non-limiting drawings. FIG. 1 is a schematic model of the system architecture for one embodiment of the MIC-based framework for integrated asset 25 management aspect of the invention. FIG. 2 is an exemplary top-level schematic of the hierarchical approach for designing modeling paradigms depicting a metamodel of the physical and non-physical top-level components of a producing oil field. FIG. 3 is a schematic entity-relationship diagram of the physical and non 30 physical subcomponents of a producing oil field. FIG. 4 is a schematic diagram of an exemplary metamodel for data types for inputs and outputs of each processing component of a producing oil field using class diagram notation similar to UML. - 5- WO 2007/022289 PCT/US2006/032014 5 FIG. 5 is a schematic diagram of an exemplary metamodel of application models and data type models composed together. V. DETAILED DESCRIPTION OF THE INVENTION A. Overview 10 Instead of developing a new software from scratch for each application, the method and system of the invention utilizes a unified generic environment will help provide the required interaction between the existing software applications. These applications are based on existing simulation software. Development of the application consists of three major steps: (1) Capturing a 15 simulation scenario. (2) Constructing a software-based structural model to map the component tasks in the scenario to a software structure. This mapping is necessary because multiple simulators may exist for the same component task. (3) Determining intersoftware coordination mechanisms, such as interface wrapping and low-level communication within the 20 application. The invention is based on Model-Integrated Computing (MIC). MIC employs domain-specific models to represent applications being designed. The models specify the desired application functionality and available simulation tools. The modeling language capturing the application functionality is based on finite 25 state machine. Modeling has been widely used for software development. Many analysis and design techniques use models to describe the necessary class and inheritance relationships in the software. However, models created using these techniques are loosely coupled to the actual system development cycle. 30 The concept of MIC can be used to form a tightly coupled environment. The software is modeled along with the environment and integration constraints. In MIC, the key element to facilitate the design process is the model. -6- WO 2007/022289 PCT/US2006/032014 5 The generic modeling environment (GME) is one known modeling environment used in MIC. It is a configurable graphical tool suite supporting MIC. GME allows the designer to create domain- specific models. A metamodel (modeling paradigm) is a formal description of model construction semantics. Once the metamodel is specified by the user, it can be used to 10 configure GME itself to present a modeling environment specific to the problem domain. All other known or later developed modeling environments are contemplated for use with this invention. FIG. 1 is a schematic model of the system architecture for one embodiment of the MIC-based framework for integrated asset management aspect of the 15 invention. The framework, which is based on MIC, will be used to facilitate activities in the integrated asset management, such as data integration, simulation application development, etc. Multiple Simulators 140 and multiple Optimizers 142 are, optionally, existing petroleum industry domain-specific software applications. These can include, e.g., applications for optimizing oil 20 production from an oilfield, evaluating the heat distribution in an oilfield, or optimizing steaming of an oilfield. Control Strategies 165 may include, e.g., software-implemented control strategies such as available through known Supervisory Control and Data Acquisition ("SCADA") systems or other process control systems. 25 The MIC-based framework for Integrated Asset Management 100 has three components - Execution Environment 130, Modeling Environment 100, and Configurable Graphic User Interface (GUI) 110. For each Simulator 140 or Optimizer 142 or other existing software applications (not shown) intended to be modeled, there is a Model Interpreter 150, is operably connected to, and 30 serves as a link between, its respective software application and the modeling environment 120. Modeling environment 120 is in operably connected to a Configurable GUI 110. Both the Configurable GUI 110 and the Modeling Environment 120 are configured to receive User Input 112 via any known or future-developed input devices or mechanisms. Sensor Network 160 and 35 Historical Data 155 are operably connected to Databases 162 (only one shown). -7- WO 2007/022289 PCT/US2006/032014 5 B. Model Integrated Computing Models provide a more effective way to develop large, reliable, real-time software systems because they help manage complexity through abstractions and formal descriptions of the physical systems. Model-based software synthesis is a part of the larger discipline of knowledge-based software 10 engineering. It integrates artificial intelligence and software engineering by supporting specification methods, software synthesis, and analysis with application-specific knowledge formalized into models. MIC is a system software development approach that promotes the use of domain-specific models to represent relevant aspects of a system. The use of 15 domain-specific models have many benefits. For example, they help users specify systems using domain concepts. Domain specific modeling also allows users to specify systems at a higher level of abstraction. One of the most important characteristics of MIC is that it allows us to dynamically resynthesize a running system without changing anything but the relevant 20 components. MIC works well when software requirements and specifications are constantly changing. C. Modeling Methodology Modeling has been used to capture the system design, synthesize executable systems and perform analysis or drive simulation. Our models have been 25 designed to capture the various simulation scenarios possible in the petroleum industry. A simulation scenario can be defined as the interaction in terms of event flows and relative ordering of such flows. To model such a scenario, we need to capture both the building components and the interaction between them. 30 The building components include simulators, optimization tools, databases, etc. Since our target applications are based on existing software, we are not concerned with modeling the internal structures or implementation of the building software components. Instead we only capture their interfaces each -8- WO 2007/022289 PCT/US2006/032014 5 of which can be characterized with a set of input signals and a set of output signals. D. Modeling Component Interfaces GME can been used to create a prototype framework of an integrated petroleum asset management system, with intent to develop processing for 10 integrated forecasting, reliability estimation, and real time data flow mapping. We have used a hierarchical approach to model the sub-components, which provide the required abstraction of the interfaces provided by the basic building components. The hierarchical model, provides the user with different levels of abstraction, levels of integration and levels of visualization. The 15 topmost level provides a high level of abstraction and the models get more detailed as one goes to the lower levels. At the lowest level of integration the components are tightly coupled and provide explicit data exchange, whereas at the highest level the integration is limited to higher level components. Figure 2 shows the top level sub 20 components in this prototype application. It is an exemplary top-level schematic 200 of the hierarchical approach for designing modeling paradigms depicting a metamodel of the physical and non-physical top-level components of a producing oil field. The components can be classified into physical (block, well, pipe-network, separator, process, etc.) and non-physical (control 25 strategies, drilling schedule, reliability models, assumptions, etc.) entities. Reservoir Model 210 consists of Block Container Model 235, Fluid Region Container Model 250, Well Container Model 220, and Recovery Curve Container Model 212. Each component model in turn consists of other models. That is, Well Container Model 220 consists of a Well Model that is 30 represented by Well Model Proxy 215. The ModelProxy is employed because the definition of the Well Model is specified elsewhere. Similarly, Fluid Region Container Model 250 consists of Fluid Region Properties Model 245. Block Container Model 235 consists of Block Models that are represented by Block Model Proxy 230 and defined elsewhere in the metamodel specification. -9- WO 2007/022289 PCT/US2006/032014 5 Recovery Curve Container Model 212 consists of Recovery Curve models that are represented by Recovery Curve Model Proxy 240. A few of these entities are as described in the following sub-sections: E. Physical Sub-Component Models 0 Block: With information in the geological model and reservoir simulator, 10 a reservoir can be divided into several reservoir volume elements called the blocks in this framework. In our simple metamodel, each block is defined with the following parameters: Original Oil In Place (OOIP), primary decline curve, secondary decline curve, voidage target, among others. 15 9 Well: Wells provide the primary production-injection conduits to the reservoir. Our well model consists of various parameters and models to describe the physical structure and relationship with other operational components. The well model provides the information about where the well is physically located, which type of well (e.g., producer, water 20 injection well, or gas injection well) it is, etc. . Pipe network: A pipe network is a gathering system that collects all fluids from all the wells. * Separator: A separator is used to separate oil from gas and water. Our separator model is used to represent the operations and components 25 of a separator. * Process: After separation, the following processing actions are performed: product treatment, compressing gas to high pressure and sending it to the market. FIG. 3 is a schematic entity-relationship diagram 300 of the physical and non 30 physical subcomponents and of a producing oil field and associated connectors. Four connections are shown. First, in figure portion 310, depicting the connection of a Well Model represented by the Well Model -10- WO 2007/022289 PCT/US2006/032014 5 Proxy 325 to Gas Compressor Stage represented by the Gas Compressor Stage Model Proxy 315 via Gas Compressor Stage to Well Connection 320. Second, in figure portion 320, depicting the connection of a Well Model represented by the Well Model Proxy 325 to Separator System Model represented by Separator System Model Proxy 345 via Well to Separator 10 System Connection 355, and Separator System Model represented by Separator System Model Proxy 345 to Gas Compressor System Model represented by Gas Compressor System Model Proxy 340 via Separator System to Gas Compressor System Connection 320. Third, in figure portion 370, depicting the connection of Well Model represented by Well Model Proxy 15 325 to Water Injection Train Model represented by the Water Injection Train Model Proxy 375 via Injection Train to Well Connection 380. F. Non-Physical Sub-Component Models Non-physical components provide the required control for the proper management of the physical'components in the IAM system. These help us 20 provide certain assumptions, schedules, strategies, etc for efficient asset management. Some of the non-physical sub-components, which have been modeled are listed as below. " Assumption model: Assumption model maintains consistency of parallel modeling efforts and diverge assumptions regarding boundary 25 conditions between domains. . Drilling schedule: Drilling schedule model is a complement of the on stream date parameter in describing when a well will be active. * Real time data: Real-time data model consists of three aspects: real time production data, real-time access by an asset, and real-time 30 action. . Control strategy: The control strategy model provides both the heuristic operating rules and the optimization control for the system. - 11

-

WO 2007/022289 PCT/US2006/032014 5 * Reliability: Reliability models are used capture the reliability and availability of each component and its building components. Once the components have been modeled, the next step is to model the interactions between different components. G. Data Type Models 10 Data plays a key role in today's petroleum industry. Exploration and production geoscientists rely heavily on various data, such as maps, logs, seismic sections, well test reports, etc. Many issues related to data exist in petroleum industry. In a simulation application, data used by different software components may take different data format. Thus, feeding data from the 15 output of one software to the input of another is not feasible. Furthermore, even the same data stored in a database could be interpreted differently by various software. This invention is focused on modeling the data flowing among various software components as part of the overall modeling methodology for application development in the petroleum industry. The data 20 type models described in this section represents a lower level of abstraction than the application models. They are attached to the application models, more accurately describing the data to/from each component in an application. Data type models are used to capture the inputs and outputs of each 25 processing component in an application model. Each signal of a component is associated with a data type. This can be a simple built-in type such as a double, float, integer or character or an array of any one of these, or a user defined aggregate type. Aggregate types are explicitly modeled by combining single (and arrays of) built-in types. This signal typing is easily specified within 30 each component instance. The aggregate signal types include elements to allow for breaking signal into constituent parts or combining simple types into complex types. Merging several simple streams into a larger structure helps reduce higher level interconnection visual complexity if a logical grouping can be developed. The data type metamodel is shown by Figure 4. FIG. 4 is a 35 schematic diagram 600 of an exemplary metamodel for data types for inputs - 12- WO 2007/022289 PCT/US2006/032014 5 and outputs of each processing component of a producing oil field using UML class diagram notation. TypeBase Model class 610 has three subclasses, i.e., PrimitiveType Model class 615, Logical Model class 620, and CompoundType Model class 625. PrimitiveType Model class 615 has two subclass, i.e., Float Model class 630 10 and Int Model class 635. CompoundType Model class 625 has four subclasses, i.e., Union Model class 675, Struct Model class 680, LibraryType Model class 685, and TypeReference FCO class 645. TypeReference FCO class 645 has three subclasses, i.e., PITypeRef Reference 650, LTypeRef Reference class 655, and CTypeRef Reference class 670. Float Model class 15 630 has subclass PFTypeRef Reference class 640. Int Model class 635 has subclass PITypeRef Reference class 650. Logical Model class 620 has subclass LTypeRef Reference class 655. The relations of the data types are also modeled. For example, if a given type needs to be converted to another type with a conversion function, a model 20 capturing the conversion function has to be used between the two types. The application models and the data type models are composed together according to the metamodel in Figure 5. FIG. 5 is a schematic diagram 700 of an exemplary metamodel of application models and data type models composed together. Component Model Proxy 710 relates to TypeRefBase 25 FCO Proxy 740 and TypeConnection Connection 720 which connects TypeRefBase FCO Proxy 740 and Signal Atom Proxy 730. The proxies are representative of corresponding parts that are modeled in detail elsewhere in the metamodel description. The TypeConnection connection between component signals and the 30 TypeRefBase class is introduced. TypeRefBase FCO Proxy 740 represents a reference to data type models. TypeConnection Connection 720 assigns the referred type to the given port. -13- WO 2007/022289 PCT/US2006/032014 5 H. Exemplary Benefits The invention is a unified environment is created for developing a class of applications in petroleum engineering, which consist of various software components. The modeling paradigms reflect our current understanding of petroleum engineering domain. The hierarchical approach provides various 10 levels of abstraction, integration and visualization. By adding data type models to application models, two-level abstraction has been achieved. To improve the modeling paradigms with more levels and more capabilities, we will have more interactions with the domain experts. To provide the unified environment, our next step has been to consider a 15 simple use-case problem of forecasting the oil production, and implement the use-case in our GME based framework. This will work as the application, which uses the sub-component models to provide the abstraction of the interfaces of the components in the petroleum engineering domain. To facilitate the development of complex applications in petroleum industry, other 20 modeling paradigms than what we have defined will be explored. J. Other Implementations Other embodiments of the present invention and its individual components will become readily apparent to those skilled in the art from the foregoing detailed description. As will be realized, the invention is capable of other and different 25 embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the spirit and the scope of the present invention. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive. It is therefore not intended that the invention be limited except as indicated by the appended 30 claims. -14- C:\NRPorbr\DCC\KLL\3901199 . DOC-2M1/20Il Throughout this specification and the claims which follow, unless the context requires otherwise, the word "comprise", and variations such as "comprises" and "comprising", will be understood to imply the inclusion of a stated integer or step or group of integers or steps but not the exclusion of any other integer or step or 5 group of integers or steps. The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general 10 knowledge in the field of endeavour to which this specification relates. - 14A -

Claims (18)

1. A modeling framework configured to facilitate integration of complex software applications in the petroleum industry comprising: (a) a graphical modeling language comprising: 10 (1) classes comprising a plurality of oil field asset components and connectors and a grammar defining the allowed and necessary connections between the asset components configured and adapted for making a plurality of graphical models compliant with the graphical modeling language 15 where the graphical models represent a plurality of oil field asset components and the connections between them and each model having a plurality of levels of detail; (2) the graphical modeling language configured and adapted for modeling the asset components of different oil fields having 20 different numbers, types, and configurations of asset components; and (b) a model interpreter for each of a plurality of software applications domains specific to the oil field for storing, analyzing, displaying, or manipulating oil field data associated with at least one of the oil 25 field asset components, each model interpreter configured and adapted for passing information between the plurality of oil field asset components.

2. The modeling framework of claim 1, further comprising a graphical user 30 interface for dragging and dropping the oil field asset components for a given oil field onto a graphical user interface workspace and connecting them. - 15- WO 2007/022289 PCT/US2006/032014 5

3. The modeling framework of claim 1, wherein the asset components comprise physical and non-physical assets.

4. The modeling framework of claim 1, wherein the physical asset components comprise pumps, subterranean reservoirs, pipe network systems, well bores connecting the reservoirs to pipe network systems, 10 separators, processing systems for processing fluids produced from the subterranean reservoirs and heat and water injection systems.

5. The modeling framework of claim 1, wherein the non-physical asset components comprise reliability estimators, financial calculators, optimizers, uncertainty estimators, and control systems. 15

6. The modeling framework of claim 2, wherein the graphical user interface is part of a generic modeling environment.

7. The modeling framework of claim 1, further comprising utilizing a proxy generator to create a proxy for a model.

8. The modeling framework of claim 1, further comprising utilizing an 20 assumption manager to maintain assumptions consistently between the models.

9. A method of modeling and integration of complex software applications in the petroleum industry comprising: (a) Making at least one model of an oil field using a graphical modeling 25 language comprising: (1) classes comprising a plurality of oil field asset components and connectors and a grammar defining the allowed and necessary connections between the asset components configured and adapted for making a plurality of graphical 30 models compliant with the graphical modeling language where the graphical models represent a plurality of oil field -16- WO 2007/022289 PCT/US2006/032014 5 asset components and the connections between them and each model having a plurality of levels of detail; (2) the graphical modeling language configured and adapted for modeling the asset components of different oil fields having different numbers, types, and configurations of asset 10 components; and (b) making at least one model interpreter for each of a plurality of software applications domains specific to the oil field for storing, analyzing, displaying, or manipulating oil field data associated with at least one of the oil field asset components, each model 15 interpreter configured and adapted for passing information between the plurality of oil field asset components.

10. The method of claim 9, further comprising a graphical user interface for dragging and dropping the oil field asset components for a given oil field onto a graphical user interface workspace and connecting them. 20

11. The method of claim 9, wherein the asset components comprise physical and non-physical assets.

12. The method of claim 9, wherein the physical asset components comprise pumps, subterranean reservoirs, pipe network systems, well bores connecting the reservoirs to pipe network systems, separators, 25 processing systems for processing fluids produced from the subterranean reservoirs and heat and water injection systems.

13. The method of claim 10, wherein the non-physical asset components comprise reliability estimators, financial calculators, optimizers, uncertainty estimators, and control systems. 30

14. The method of claim 10, wherein the graphical user interface is part of a generic modeling environment. -17- C:\NRPonblDCCKLL\9()199_ DOC-2M19/20Il

15. The method of claim 9, further comprising utilizing a proxy generator to create a proxy for a model.

16. The method of claim 9, further comprising utilizing an assumption manager to maintain assumptions consistently between the models. 5

17. The modelling framework of claim 1, substantially as hereinbefore described.

18. The method of claim 9, substantially as hereinbefore described. -18-