Some formatting was lost in conversion to HTML.
However, little support has been given to the users of simulation results. Often the effort spent writing simulations is not adequately justified by the level of effectiveness and efficiency at which the simulation results are used. For example, the U.S. Department of Defense highlighted one of the many shortcomings in its ability to effectively and efficiently use models and simulations: "Significant effort is devoted to developing 'stand alone' models with no intent to reuse--costly duplication". In an attempt to enhance the way people access and reuse simulation results, we in this document propose an initial specification for SimQL, a simulation access and query language.
It is extremely important to point out that SimQL is not a language for writing simulations. Rather, it gives simulation users a better mechanism to access and query simulation results, and provides with value-added services through applications that reuse (through interpolating and extrapolating) and integrate simulation results.
However, this document mostly defines SimQL at the language level by specifying its syntactic and semantic fundamentals. The "SimQL Overview" section describes the components of SimQL, and the environment in which it operates. The "SimQL Syntax and Semantics" section describes the lexical convention of SimQL and gives the SimQL string syntax in BNF. "SimQL Schema Language" and "SimQL Access and Query Language" describe in detail the modeling and querying mechanisms of respectively. The "Simulator Interfaces" section describes how concepts of CORBA and IDL can be used in SimQL to interact with other existing simulators through a set of wrappers. Finally, the "Appendix" section includes features that could be added to SimQL in the future.
However, SimQL schema is different from SQL schema in many ways. Unlike SQL schema, which includes all of the information about objects that an implementation requires, SimQL schema only privides the information about interfaces to simulators. SimQL schema also has IN, OUT, and INOUT data types, which will be discussed in detail in "SimQL Schema Language".
A SimQL model is the most fundamental representation of a simulation through which a user accesses simulation results. For example, for a weather simulation, we could have two SimQL models, (time, location, temparature) and (time, location, precipitation), both of which belong to the schema that represents the simulation. A SimQL model analogous to a view in SQL in the sense that it gives an abstraction of (part of) the simulation but it does not actually exist.
The aforementioned structure can be best pictured in Figure 1.
The SimQL environment also has SimQL agents. A SimQL agent can be thought of as the execution of an application program, which includes one or more SimQL operations. The SimQL agent starts execution under the control of another SimQL environment component, SimQL client. The SimQL agent first causes the SimQL client to establish a SimQL connection with a SimQL server, which in turn carries out the SimQL operations(queries) requested by the SimQL agent.
Based on the SimQL schema defined by the SimQL agent and the qureies submitted, the SimQL server has to access and possibly integrate corresponding simulation results generated by some simulators through some Simulator Interfaces. A Simulator Interface can be thought of as an ORB(Object Request Broker) that will find a proper wrapper for the SimQL server's request. If such a wrapper does indeed exist, the Simulator Interface passes the SimQL server's request along with its parameters to the wrapper, which in turn massages them and passes them to the corresponding simulator. The simulator carries out the desired simulation and generates the simulationm results. The results are passed back from the simulator through the wrapper, the Simulator Interface, processed and possibly integrated by the SimQL server to SimQL results, which are then returned to the SimQL agent. The process is illustrated in Figure 2.
To Summarize, a SimQL Management System includes:
| Symbol | Meaning |
|---|---|
| ::= | Is defined to be |
| | | Alternatively |
| <text> | Non-terminal |
| "text" | Literal |
| * | The preceding syntactic unit can be repeated zero or more times |
| + | The preceding syntactic unit can be repeated one or more times |
| {} | The enclosed syntactic units are grouped as a single syntactic unit |
| [] | The enclosed syntactic unit is optional-may occur zero or one time |
The following are all identifiers in the foregoing sense:
Reserved keywords(tentative):
ABS ADD ALL ALTER AND ANY AS ASC ASSERTION AT AUTHORIZATION AVG
BEGIN BETWEEN BIT_LENGTH BY
CATALOG CERTAINTY CHAR CHAR_LENGTH CHECK COLUMN CONNECT CONSTRAINT
CONSTRAINTS COUNT CREATE CROSS CURRENT CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER
DATE DAY DEFAULT DELETE DISCONNECT DISTINCT DOMAIN DOUBLE DROP
END EXEC EXISTS
FALSE FLOAT FOR FOREIGN FROM
GROUP
HAVING HOUR
IN INSERT INT INTERSECT INTERVAL INTO IS
JOIN
KEY
LEFT LIKE LOWER
MAX MIN MINUTE MODEL MODULE MONTH
NATURAL NEXT NOT NULL
OF ON OR OUT OUTER
POSITION PRIMARY PROCEDURE
REAL REGISTER RIGHT ROW
SCHEMA SECOND SELECT SESSION SESSION_USER SET SIMQL SIMULATE SIMULATOR
SMALLINT SUBSTRING SUM SYSTEM_USER
TABLE TIME TIMESTAMP TO TRIM TRUE
UNION UNIQUE UNKNOWN UPDATE UPPER USER
VALUE VALUES VARCHAR VIEW
WHERE
YEAR
3.2.6 to 3.2.11 categorize and introduce the reserved keywords.
| BIT(n) | --fixed length string of exactly n bits (n>0). Bit strings are enclosed in single quotes and preceded by the letter B(binary) or X(hexadecimal) e.g.: B'0101' X'Ab1C' |
| CHAR(n) | --fixed length string of exactly n characters. Character strings are enclosed in single quotes. |
| DATE | --date in the form of day/month/year |
| DOMAIN | --same as in SQL |
| DOUBLE | --double precision floating point data type |
| FLOAT(p) | --floating point data type with p digits precision Floating point numbers(DOUBLE, FLOAT, REAL) in SimQL can use the E notation as well. |
| INT | --signed integer |
| NULL | --represent null value (used in the same contexts as NULL in SQL) |
| REAL | --single precision floating point data type |
| SMALLINT | --short signed integer |
| TIME | --time in the form of hour:minute:second |
| UNKNOWN | --same as in SQL |
| VARBIT(n) | --varying length string of up to n bits |
| VARCHAR(n) | --varying length string of up to n characters |
| Arithmetic operators: | + - * / ** |
| string concatenation: | || |
| ABS() | --returns the absolute value of a number |
| ASC() | --returns the ASCII value of a character |
| BIT_LENGTH() | --returns the length of a bit string |
| CHAR_LENGTH() | --returns the length of a character string |
| time: | CURRENT_DATE CURRENT_TIME CURRENT_TIMESTAMP CURRENT_USER |
| DAY() | --returns the "day" part of a DATE value |
| HOUR() | --returns the "hour" part of a TIME value |
| LOWER() | --convert a character string to lower case |
| MINUTE() | --returns the "minute" part of a TIME value |
| MONTH() | --returns the "month" part of a DATE value |
| POSITION() | --same as in SQL |
| SECOND() | --returns the "second" part of a TIME value |
| SESSION_USER | --returns the SimQL-session authorization ID |
| SUBSTRING() | --same as in SQL |
| SYSTEM_USER | --returns the ID of the operating system user |
| TRIM() | --same as in SQL |
| UPPER() | --convert a character string to upper case |
| YEAR() | --returns the "year" part of a DATE value |
CATALOG CREATE
DROP
MODEL
SCHEMA
ADD ALTER
DELETE
DROP
INSERT
SELECT SIMULATE
TABLE
UPDATE
VIEW
REGISTER
Syntax for SQL is not repeated here.
However, SimQL models also differ from views of SQL in many ways. Insertion and deletion are not supported for models because there aren't any "base tables" underneath models. Querying a model means finding out the IN/OUT/INOUT elements or the method of the model. Updating a model means adding/deleting/altering model elements or changing a model method, a privilege restricted to the wrapper writers. We have not included specific model querying and updating mechanisms in our current SimQL specification.
The general syntax of CREATE MODEL is:
model-definition
model ::= [ schema. ] identifier
model-element-commalist ::= model-element{"," model-element}*
model-element ::= model-element-attribute data-type identifier
model-element-attribute ::= "IN" | "OUT" | "INOUT"
method ::= [simulator.] identifier
method-parameter-commalist ::= identifier{"," identifier}*
Here "model" is the name of the new model. Model element attributes "IN", "OUT", "INOUT" mean input to simulation, output from simulation, input/output to/from simulation, respectively.
An "OUT" element will hold the output value from the simulation as well as a CERTAINTY value upon returning from an access to a simulation. A CERTAINTY value is a floating point number between 0 and 1, representing the probability of the occurrence of such output.
Methods are declared when simulators are registered. Simulators are actually interfaces to simulation wrappers. Methods and simulators will be discussed in detail in "Simulator Interfaces".
Some examples of CREATE MODEL would be:
CREATE MODEL temperature(IN DATE date, IN VARCHAR(20) city, OUT INT temperature) AS weather_forecast.temperature(date, city, temperature);
After accessing "temperature" model using SIMULATE, the "OUT" variable temprature will hold something like "65 CERTAINTY 0.90".
Here "weather_forecast" is a registered simulator (interface) with at least one method "temperature" declared. The model element attributes and types are checked against those of the method parameters. All the "IN"/"INOUT" model elements must match all the "IN"/"INOUT" method parameters in order for CREATE MODEL to succeed. However, it is not necessary to supply all the "OUT" model elements. For example, if the temperature method is declared as:
METHOD temperature(IN DATE date, IN VARCHAR(20) city, OUT INT low,
OUT INT high);
(low and high could be the lower and upper temperatures, respectively.)
Then both the following CREATE MODEL's are fine. In the first model, the "low" output from the simulator is simply ignored.
CREATE MODEL temperature(IN DATE date, IN VARCHAR(20) city, OUT INT high) AS weather_forecast.temperature(date, city, NULL, high);
CREATE MODEL temperature(IN DATE date, IN VARCHAR(20) city, OUT INT low, OUT INT high) AS weather_forecast.temperature(date, city, low, high);
To delete a SimQL model, use DROP MODEL.
For example,
Dropping the model does not affect the underlying method or simulator at all.
This could be achieved through:
Implementing specific model querying and updating mechanisms is part of our future work.
In this section, we describe the SimQL access and query language features.
simulate-exp
simulate-item ::= model-element-ref[ AS identifier ]
parameter-exp ::= parameter-assignment[ AND parameter-assignment]
parameter-assignment ::= method-parameter "=" scalar-exp
The HAVING clause can be used to specify the conditions under which the simulation is to be carried out. For example, if the simulator has an attribute which tells us how long it has been idle, we can choose to simulate only when the idle time is longer than say, 1 msec. If the condition in the HAVING clause is not met, an error message will be returned.
An example of using SIMULATE follows.
Assume we have declared
when we registered simulator weather_forecast, and we did
CREATE MODEL temperature(IN DATE date, IN VARCHAR(20) city, OUT INT
low, OUT INT high) AS weather_forecast.temp(date, city, low, high);
CREATE MODEL precipitation(IN DATE date, IN VARCHAR(20) city, OUT INT
precipitation) AS weather_forecast.prec(date, city, precipitation);
We use
to simulate the low and high temparatures and precipitation in San Francisco on Jan. 1, 1997 only if the simulator has been idle for at least 6 hours.
To repeatedly trigger a simulation, we can use the FOR ... NEXT statement, which has the following syntax:
The FOR...NEXT is similar to the "for" in C and C++. The identifier declared in the FOR clause has the scope of the FOR...NEXT loop and can be used just like any other identifiers in the loop.
For example, if we want to simulate the weather_forecast 1000 times, we can use
to enclose the SIMULATE clause.
Specifically, we use CREATE TABLE (VIEW) in SQL to create the base tables (views), SIMULATE in SimQL to get simulation results back, and SELECT in SQL to query and integrate the databases of simulation results.
A user can use the SQL subset and SimQL to build a simulation result base table, populate it with simulation results from SIMULATE, and query it.
FOR (INT i = 1, i <= 1000, i = i + 1)
INSERT INTO WeatherInfo(date, city, low, high, prec)
SIMULATE low, high, precipitation
FROM temparature, precipitation
WHERE date = 1/1/97 AND city = 'San Francisco'
HAVING idletime >= 06:00:00;
NEXT;
SELECT AVG(low), AVG(high), SUM(precipitation)
FROM WeatherInfo;
The various table JOIN operations in SQL can also be used in conjunction with SimQL to achieve effective and efficient use of stored simulation results.
After writing/updating a wrapper for any simulator, the SimQL wrapper builder needs to register the wrapper/simulater so that the ORB will remember it and route a request to the proper wrapper. This is achieved in SimQL by using REGISTER SIMULATOR.
The general syntax for REGISTER SIMULATOR is:
simulator-element
::= {ATTRIBUTE data-type identifier} |
{METHOD method (method-parameter-dcl-semicolonlist)}
method-parameter-dcl
::= method-parameter-attribute data-type identifier
method-parameter-attribute ::= "IN" | "OUT" | "INOUT"
An example would be:
REGISTER SIMULATOR weather_forecast (
ATTRIBUTE TIME idletime;
METHOD temp(IN DATE date, IN VARCHAR(20) city, OUT INT low, OUT INT
high);
METHOD prec(IN DATE date, IN VARCHAR(20) city, OUT INT precipitation);
);
Imagine a trucking company wants to ship some goods from city A to city B through a most optimal route, which is defined to have minimal amount of rainfall(delay) and minimal amount of shipping cost. The company has two simulators (and corresponding wrappers), one of which forecasts the weather condition along a route given the source, the destination, and the route; the other estimates the shipping cost given the source, the destination, and the route.
The wrapper writer has written this code in SimQL:
REGISTER SIMULATOR weather_forecast (
ATTRIBUTE TIME idletime;
METHOD prec(IN VARCHAR(20) source, IN VARCHAR(20) dest, IN INT
route_num, OUT INT prec);
);
REGISTER SIMULATOR shipping (
ATTRIBUTE TIME idletime;
METHOD shipping_cost(IN VARCHAR(20) source, IN VARCHAR(20) dest, IN
INT route_num, OUT INT cost);
);
CREATE MODEL precipitation(IN VARCHAR(20) source, IN VARCHAR(20) dest,
IN INT route_num, OUT INT prec)
AS weather_forecast.prec(source, dest, route_num, prec);
CREATE MODEL shipping_cost(IN VARCHAR(20) source, IN VARCHAR(20) dest,
IN INT route_num, OUT INT cost)
AS shipping.shipping_cost(source, dest, route_num, cost);
The manager of the trucking company can find the optimal route by using:
CREATE TABLE PrecipitationInfo (
VARCHAR(20) source,
VARCHAR(20) dest,
INT route_num,
INT prec,
);
CREATE TABLE CostInfo (
VARCHAR(20) source,
VARCHAR(20) dest,
INT route_num,
INT cost,
);
FOR (INT i = 1, i <= MAXROUTE, i = i + 1)
INSERT INTO PrecipitationInfo(source, dest, route_num, prec)
SIMULATE source, dest, route_num, prec
FROM precipitation
WHERE source = 'A' AND dest = 'B' AND route_num = i
HAVING idletime >= 06:00:00;
INSERT INTO CostInfo(source, dest, route_num, cost)
SIMULATE source, dest, route_num, cost
FROM shipping_cost
WHERE source = 'A' AND dest = 'B' AND route_num = i
HAVING idletime >=R 06:00:00;
NEXT;
SELECT route_num
FROM PrecipitationInfo NATRUAL JOIN CostInfo
WHERE prec = MIN(prec) AND cost = MIN(cost)
The shipping-cost simulator has been changed by the wrapper writer to
REGISTER SIMULATOR shipping (
ATTRIBUTE TIME idletime;
METHOD shipping_cost(IN VARCHAR(20) source, IN VARCHAR(20) dest, IN
INT route_num, IN INT prec, OUT INT cost);
);
and the corresponding SimQL model is
CREATE MODEL shipping_cost(IN VARCHAR(20) source, IN VARCHAR(20) dest, IN INT route_num, IN INT prec, OUT INT cost) AS shipping.shipping_cost(source, dest, route_num, prec, cost);
One way to trigger the simulators and query the results would be:
SELECT route_num
FROM ShippingInfo
WHERE prec = MIN(prec) AND cost = MIN(cost)
Without SimQL, the task of choosing the optimal route based on the simulation results from two different simulators would be daunting.
