A Simulation Access Language (SimQL)

Moved to a new page: LIC projects, SimQL page

Old Text

Gio Wiederhold < Gio@cs.stanford.edu >
Rushan Jiang (CSD, MS) Research assistant
James Chiu (CSD, MS) CS395 project, completed.

Stanford University, Computer Science Department

SimQL Research Sketch

We have intiated research towards the development of a "Simulation Access Language", say SimQL, as a major contribution to interoperation of software modules in manufacturing, acquisition, and planning systems.

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:

  1. A model schema, which exposes to the user externally available variables, parameters as well as potential results.
  2. A query language, that can be embedded in application codes, which invokes the simulation according to the schema, and returns results, and certainty parameters.
The concept of SimQL is based on an approach that has been successful in databases, where 20 years ago file-programming comprised the major effort in writing software. Many techniques mere devised, often ad hoc, but some with substantial effort and solid ideas to make valuable data sharable and accessible by more than one application. The adoption of the SQL language as enabled database systems to be built and continually improved, independent of the user applications, and eventually reach a level of performance that today file-programming is rare. Databases share with the applications a model, expressed in a schema or a view of the schema. The language provides an algebraic capability in the interface so that alternate execution sequences can be devised that produce equivalent results faster or better by some measure. Note that SQL is rarely used by end-users (it is to ugly), but is mainly an application program interface to which data management is delegated.

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.

Initial Tasks

Task 1: Review some simulation suites to assess what variables (independent, dependent) need to be exposed in an external schema.
Task 2: Sketch a schema language, taking concepts from SQL, ILU, IDL, and Ontolingua into account.
Task 3: Sketch a corresponding query language, taking concepts from SQL, CORBA, and KQML into account.
Task 4: Wrap some simulations, to make them and their exposable models accessible by a SimQL Remote Application Interface. Provide for access to a variety of 'to order', 'continuous', and 'databased' simulations.
Task 5 : Build a demonstration for the essential feature of a SimQL, linking it to at least two (wrapped) simulations.

SimQL Viewgraphs

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,
Stanford University, gio@cs.stanford.edu