Moved to a new page: LIC projects, SimQL page
Stanford University, Computer Science Department
The intent of a SimQL is to be able to rapidly build applications that incorporate the results of simulations, as well as other, arbitrary software components, as databases, sensor systems, and computations as available from communities as operations research, planning scientists, etc. It is crucial to note that a SimQL is not a language for writing simulations, several adequate languages and paradigms, each with their strengths and domains exist today.
The two principal components of a SimQL are to be:
I observe that simulation is an area of great ferment with similar potential aa the dtabase area. At ARPA I solicited proposals for simulation access technology, but only one project was fundable. Nearly everyone wanted to write better simulations or devise better languages for writing simulations. The difficulty of composing software involving simulations is understood by many practitioners. However none of them have the time or resources to consider a long-range alternative to designing one-at-time software systems that tightly incorporate the needed simulations. There is an effort underway to share simulated objects, but that work is at a lower level of granularity than this SimQL proposal. SimQL will, however benefit from better infrastructure standards.
Having a SimQL, and simulations compliant with its interface, will enable reuse of simulations. Today all simulations as are built to operate on one specific stove-piped environment, and will not operate outside of it. To make extant simulations compliant wrapping techniques, as now ised for other legacy software will have to be used. Once reusability is established, it will become worthwhile for simulation builders to invest in evolution and improvement of their work. Simulations that provide reuse will be preferred by customers over costly efforts in building new simulations. A major economic benefit will ensue over the long term.
Simulation models will be of necessity more complex than database schemas, and one objective of the initial research effort is to see how little need be exposed to the user's application programs. As a basis for communication we can build on languages as KQML, which supports a multi-function (i.e., more than just SQL SELECT and UPDATE), multi-user and multi-resource system setting.
The effort to be made to move to SimQL is open-ended, since we are starting witha novel approach. Developing an initial understanding, and working out some simple examples are an initial thrust. If that phase is successful and promising it will be necessary to engage resources that can build industrial strengths prototypes, that would allow the concepts to be validated in realistic settings.
1: SimQL Title (ps) | 1 :not yet in (gif) Author: gio, Size: 12215, Date: 21Jun95.
2:Decision-making (ps) | 2 :not yet in (gif) Author: gio, Size: 13020, Date: 21Jun95.
3: Information Systems (ps) | 3 :not yet in (gif) Author: gio, Size: 15591, Date: 21Jun95.
4: Service Paradigm (ps) | 4 :not yet in (gif) Author: gio, Size: 53178, Date: 21Jun95.
5: Databases vs. Simulations (ps) | 5 :not yet in (gif) Author: gio, Size: 15293, Date: 21Jun95.
6: Getting to the Present (ps) | 6 :not yet in (gif) Author: gio, Size: 15166, Date: 21Jun95.
7: Uses of Simulation Results (ps) | 7 :not yet in (gif) Author: gio, Size: 14744, Date: 21Jun95.
8: Types of Simulation Services (ps) | 8 :not yet in (gif) Author: gio, Size: 14265, Date: 21Jun95.
9: Research Questions (ps) | 9 :not yet in (gif) Author: gio, Size: 12834, Date: 21Jun95.
Gio Wiederhold,