Contact
The best way to reach the entire Möbius team is to email staff@mobius.illinois.edu. We also have a Möbius users mailing list, which is a great way to get help from the Möbius team and the large Möbius community.
Project Support
The Möbius project is one of the major research projects of the Performability Engineering Research Group (PERFORM) in the Coordinated Science Laboratory at the University of Illinois Urbana-Champaign. Research on Möbius has been supported by Motorola as part of the Motorola Center for High-Availability System Validation, by the National Science Foundation under grants 9975019 ("An Integrated Framework for Performance Engineering and Resource-Aware Compilation") and INT-0233490 ("US-Germany Cooperative Research: Analysis of Multi-Paradigm Moebius Models using Kronecker-Based Techniques"), and by DARPA grant DABT63-96-C-0069 on "Quality-Based Reliable Computing." Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.
People
|
|
|
|
|
|
Möbius Architecture
The Möbius frameworkprovides a very general way to specify a model in a particular formalism. We define a formalism as a language for expressing a model within the Möbius framework, frequently using only a subset of the options available within the framework.
We define models within the Möbius framework using a few basic concepts. A model is a collection of state variables, actions, and reward variables expressed in some formalism. Briefly, state variables hold the state information of the model. Actions change the state of the model over time. Reward variables are ways of measuring something of interest about the model.
Although the basic elements of a model are very general and powerful, formalisms need not make use of all the generality. In fact, it may be useful to restrict the generality in order to exploit some property for efficiency. The purpose of some formalisms is to expose these properties easily, and to take advantage of them for efficient solution. Möbius was designed with this in mind.
In order to improve the reusability of modles already built, it is useful to classify models as follows. The most basic category is that of "atomic models." An atomic model is a self-contained (but not necessarily complete) model that is expressed in a single formalism. Several models may be structurally joined together to form a single larger model, which is called a composed model. A composed model is itself a model, and may itself be a component of a larger composed model. A model that is more loosely connected by sharing of solutions is called a connected model.
Möbius Architecture
Möbius Tool
The first step in implementing the Möbius framework was to define the AFI that is at the core of the tool. We have implemented the AFI as a set of C++ base classes from which all models must be derived. In doing so, we defined the functional interfaces as pure virtual methods. This requires that any formalism implementor define the operation of all the methods in the functional interface. In the same fashion, we constructed C++ base classes for other Möbius framework components, including actions, state variables, and reward variables.
The Möbius tool architecture (see figure above) is separated into two different logical layers: model specification and model execution. All model specification in our tool is done through Java graphical user interfaces, and all model execution is done exclusively in C++. We decided to implement the executable models in C++ for performance reasons. Every formalism has a separate editor for specifying a particular piece of the model. Editors produce compilable C++ code as output so that the final executable model is specified entirely within C++. The C++ files produced by the editor are compiled, and the tool links the object code with formalism libraries and solver-specific libraries.