OOPM is the new name for what used to be termed "MOOSE". OOPM/MOOSE (Multimodeling Object-Oriented Simulation Environment) represents an implementation for a simulation system that is under construction, and based on an extension to object oriented design. MOOSE is the next generation of SimPack which was initiated in 1990 for providing a general purpose toolkit of C and C++ libraries for discrete-event and continuous simulation.
The purpose of MOOSE is to allow analysts to simulate physical processes by building multimodels. A multimodel is a heterogeneous hierarchy of models where a model component at one level of "abstraction" is sub-refined into a model, possibly of a different type, at the next lower level. There are two aspects of MOOSE: the underlying research that is ongoing to make MOOSE possible, and details of the implementation. We will address both of these issues.
The structure of the implementation is as follows:
The GUI allows users to both construct visually- oriented models, as well as view the output from these models in the 2D color scenario window. In many ways, MOOSE will appear similar to commercial simulation packages, such as SES Workbench, when it is complete. Multi-level, graphical object-oriented model building will be facilitated. The new aspects of MOOSE, over previously done work, are: (1) support for abstraction and multimodeling; and (2) support for planning using simulation. The software is also very portable and freely available to other researchers for further extension. This philosophy is built upon our previous SimPack software started in 1990. SimPack currently has 160 users worldwide and is documented in the PIs home page (see below title). The first aspect, multimodeling, allows users to construct multi-level models where each level represents an abstraction level for the system being designed or modeled. Multimodeling affords two types of abstraction: (1) structural and (2) behavioral. The structural abstraction is a byproduct of the hierarchical design process performed using the GUI and the use of the BLOCKS language to ensure that all system components are coupled correctly (interlevel and intralevel). The behavioral abstraction allows a user to remove lower levels of abstraction through system identification procedures (using a linear systems and neural network approaches).
We are using the Tk/Tcl toolkit for our GUI development work. Tk/Tcl permits sophisticated GUIs to be developed on top of BLOCKS and C++. Three Tk/Tcl Windows are planned. Each window will have control icons (buttons with an icon instead of text). This means each window can accept input and produce output in that window.
Window 1: Modeling Window
The steps needed to construct a model are found in a methodology called object oriented physical modeling. The first step is to create a conceptual model composed of generalization and aggregation hierarchies. The next step is to fill in attributes and methods for each class, and then to create objects from classes. We have enhanced the existing object oriented programming methodology to handle physical situations by making the definitions of "attribute" and "method" more general. Attributes are defined as either variables or static models. A sample static model is a constructive geometry (CSG) model for the physical object. Methods can be code or dynamic models. Dynamic models are of three primitive types: declarative, functional or constraint.
The components in the dynamic models will have a flexible icon-based structure. For example, when the analyst constructs a finite state machine, they can use a circle icon for the state or a raster image. The conceptual model is stored in a "topology file."
In the modeling window, one can perform multiple simulations since one models not only the physical system, but also the process of modeling. That is, the analyst is modeled as an object, with his own attributes and methods. An example method is one which initiates simulations to analyze output for future runs.
Window 2: Scenario Window
This represents the output of the simulation. What object behaviors should be displayed and how should the objects be represented? There should be a base map and overlay maps. Also, it should be possible to view graphs of one variable versus another (such as state vs. time). Graphs could just end up being pop-up windows which come up over the scenario window (but which can be moved around). Icons can move around over the maps (and overlays).
Simulation-Based Planning Scenario Window(Click for larger image)
The BLOCKS modeling language provides an assembly language for the different types of models supported in MOOSE. The primary types of initially supported models are: 1) FSA, 2) functional, 3) Petri net and 4) Equational. In many ways, the BLOCKS language resembles a modeling language for digital circuits. All supported model types are translated into BLOCKS models and then simulated using the SimPack toolkit.
SimPack is a collection of C++ programs and libraries to support simulation. Currently, SimPack supports individual model types by allow the user access to libraries for event scheduling, queuing, and equation solving. Also, we are adding tools for experimental design and analysis to SimPack, which supports the simulation-based planning and decision making.
The following freely available software is used to create MOOSE:
