Fishwick P.A. (editor) Handbook of Dynamic System Modeling

Подождите немного. Документ загружается.

14-2 Handbook of Dynamic System Modeling

process of the model. The XML-based RUBE framework deﬁnes a formal approach to capture physical

knowledge as well as the semantic information of the model and represent the information as separate

XML documents.

We developed two XML-based languages: the multimodeling exchange language (MXL) (Kim et al.,

2002; Kim and Fishwick, 2002a, 2002b; Fishwick et al., 2003; Fishwick, 2002; Damkjer, 2003) and the

dynamic exchange language (DXL) (Lee, 2005; Lee and Fishwick, 2002), for the RUBE framework. MXL

is an XML-based modeling language to support traditional heterogeneous model types such as FSM,

FBM, and Petri net (Fishwick, 1995). DXL is an XML-based functional block language to support low-

level simulation execution within the RUBE framework. We ﬁrst discuss two multimodeling concepts,

integrative multimodeling and general multimodeling as well as the overall structure of the XML-based

RUBE framework. In Section 14.2, the process for constructing a multimodel is presented. The concepts

and descriptions of MXL and DXL are explained in Sections 14.3 and 14.4. In Section 14.5, we demonstrate

how the methodology is applied to a real-world application using an example.

14.1.1 Integrative Multimodeling

A real-world system can be embodied as a certain model type within a 2D or 3D visualization environment.

It can be described by different perspectives depending on the modelers’ viewpoint since the real-world

system has the geometry or dynamics. Therefore, through the modeling process, the real world could be

expressed in diverse model types, such as a geometry model or a dynamic model. Ideally, we can explore

and execute these models within a uniﬁed 3D scene that integrates such models.

We present a novel method (i.e., integrative multimodeling) of visually merging two types of models

with the intention of allowing the user to more easily, and contextually, associate dynamic model and scene

model components. We need to deﬁne a formalized scene domain in which multiple model representations

can exist together and a certain model type can be transformed into other model types via user interactions,

by conceptualizing all objects, that the scene domain contains, and specifying properties (i.e., geometry and

dynamics) of objects and relationships between objects. We employ the concept of ontology to formalize

a certain scene domain. The purpose of integrative multimodeling is to provide a human–computer

interaction environment that allows users to change model types within the same environment. Therefore,

user interactions should be logically formalized and implemented to supportthe integrative multimodeling

environment. We formalize the user interaction as an interaction model and derive the interaction model

(Park and Fishwick, 2004a, 2004b; Park, 2005) based on ﬁrst-order logic (FOL) rules. The concepts of

ontology and the FOL rules along with the interaction model will be further discussed in Section 14.2.

14.1.2 General Multimodeling

In this section, we discuss a multimodel concept and two types of multimodels according to their model

types, such as homogeneous and heterogeneous multimodels.

14.1.2.1 Intralevel and Interlevel Couplings

General multimodels are simulation models that are composed of heterogeneous simulation models. Since

most simulation models like FSM and FBM represent only a part of the overall system behavior, they make

only a subset of a solution for analyzing the prediction and diagnosis of the real world. General multimodels

could, however, have a number of abstraction perspectives for a complex real-world system. Therefore,

they can more correctly represent and analyze a complex real-world system. Different component models

in a multimodel can deﬁne the activity at different stages of the simulation.

Figure 14.1 shows a general multimodel example having an abstraction hierarchy of heterogeneous

simulation models. Double dotted lines in this ﬁgure mean the relation of its components to compose

an upper-level model. This relation should ensure intralevel coupling. Intralevel coupling deﬁnes model

components coupled to one another in the same model (Cubert and Fishwick, 1998). In Figure 14.1, there

are two intralevel couplings. M

is composed of m

, m

, and m

. M

is composed of s

, s

, and s

.The

intralevel coupling in M

deﬁnes how the submodels of M

are formed to represent a model M

and the

intralevel coupling in M

deﬁnes how the submodels of M

are formed to represent a model M

Multimodeling 14-3

Level 1

Level 2

Level 3

Refinement

Abstraction

Connection

FIGURE 14.1 General multimodel structure.

(i)

FIGURE 14.2 Homogeneous reﬁnement: declarative →declarative.

In Figure 14.1, down-arrows mean reﬁning a model and up-arrows mean the abstraction of a model.

These two relations should ensure interlevel coupling. Interlevel coupling deﬁnes rules as to how model

components from one model can be reﬁned into models of different types (Cubert and Fishwick, 1998).

In Figure 14.1, there are two interlevel couplings. M

reﬁnes a model M

and M

reﬁnes m

. A model m

abstracts M

, and M

abstracts M

. To reﬁne m

into M

, we should ensure the intralevel coupling in M

when we change the submodel m

and M

14.1.2.2 Homogeneous and Heterogeneous Multimodels

In Figure 14.2, the FSM shows top-down homogeneous decompositions (i.e., intralevel coupling), since

the element of the upper model is deﬁned by the same type of models. State s

is decomposed into the

lower level of FSM. The predicates p

(i) and p

(i) involves external input variable i.

Figure 14.3 shows a two-level functional hierarchy, where function f is deﬁned in terms of a composition

of three other functions f

, f

, and f

Heterogeneous decomposition of models in intralevel coupling describes the semantics of a model using

different model’s semantics. Figure 14.4 shows FSM that contains the internal state transitions associated

with function f . The predicate p(i) tests input variable i. Any FSM should be deﬁned inside a functional

block (i.e., function f in Figure 14.4) to represent explicit external input and output semantics.

Figure 14.5 shows a state-to-state space mapping, which is not immediately apparent from the ﬁgure.

Speciﬁcally, most functional block models that represent some aspects of physical reality involve state

transitions, which means f

and f

contain internal state transitions. There is a transition with two possible

types of semantics coming out of state s in Figure 14.5. An external transition would be of the form p

(i) and

an internal transition would be based on a variable o that is a component of internal state space of f

and f

14-4 Handbook of Dynamic System Modeling

O 5 f (i

, i

)

O 5 f

), f

))

FIGURE 14.3 Homogeneous reﬁnement: functional →functional.

p(i)

FIGURE 14.4 Heterogeneous reﬁnement: functional →declarative.

(i)

(o)

FIGURE 14.5 Heterogeneous reﬁnement: declarative →functional.

14.1.3 RUBE Framework

The RUBE framework is an XML-based dynamic modeling and simulation framework permitting the

users to specify and execute a dynamic model, with an ability to customize a model presentation using 2D

or 3D visualization (Park and Fishwick, 2004a, 2004b; Park, 2005; Fishwick et al., 2003; Kim and Fishwick,

2002b). The purpose of RUBE is to facilitate a dynamic multimodel construction based on XML, and

visualize and execute the model within a 2D environment (Fishwick et al., 2003) or a 3D immersive

environment (Park and Fishwick, 2004a, 2004b; Park, 2005; Fishwick et al., 2003; Carey and Bell, 1997).

The overall process of the XML-based RUBE framework is shown in Figure 14.6.

We will proceed using the architecture depicted in Figure 14.6, referencing each section by number as it

appears in the ﬁgure. For each section, we will cover a description of that section.

A scene ﬁle contains 2D or 3D geometry objects that represent geometry and dynamic models. The RUBE

framework has 2D- (i.e., Sodipodi, 2006) and 3D-based (i.e., Blender, 2006; Roosendaal and Selleri, 2004;

Roosendaal and Wartmann, 2002) interfaces for representing 2D and 3D scenes, respectively. The scene

ﬁles represent the appearance of geometric objects in the model and do not have any information about

model behavior or dynamics. The scene could be represented either in standard 2D/3D XML documents

Multimodeling 14-5

Simulation code

…

SimPackJ/S

…

Simulation file

MXL file

Section 3

MXL-to-DXL

translator using

XSLT

DXL-to-Javascript

translator using

DOM

DXL file

Section 4

MXL file

Simulation file

Scene file

Section 2

2D & 3D

RUBE dynamic

modeling file

2D Interface

(Sodipodi)

3D Interface

(Blender)

2D & 3D

merge engine

Blender

game engine

FIGURE 14.6 The RUBE framework.

(i.e., scalar vector graphics (SVG) (Eisenberg, 2002) or extensible 3D (X3D, 2006) or in Blender. Therefore,

any 2D or 3D tools, which can generate SVG or X3D ﬁles, might be applied as a part of the RUBE

framework.

For model creation there are two stages: model translation and model simulation. For model translation,

a dynamic model is an actual model ﬁle that is represented in MXL. The MXL ﬁle describes the behavior

of the model and represents the model ﬁle that includes the speciﬁcation of a heterogeneous multimodel

in an abstract level such as FBM and FSM. The MXL-to-DXL translator in extensible stylesheet language

(XSL) (Kay, 2000) translates a model ﬁle written in MXL into a low-level functional speciﬁcation language

called DXL, which can be described with a homogeneous block diagrammatic presentation. For model

simulation, the DXL is translated into an executable programming code for the model simulation using the

DXL-to-simulation translator. The programming code either in JavaScript or in Python can be executed

based on SimpackJ/S or Simpack Python (Fishwick, 1992; Park and Fishwick, 2002), which provides the

underlying code foundation for libraries, classes, and objects for simulation.

For model merging we have two approaches: (1) using a 2D or 3D merge engine in XSL, we can merge

a scene ﬁle with an actual model execution ﬁle in JavaScript or (2) within the Blender environment, we

could naturally combine the 3D scene in Blender with simulation code in Python using Blender game

engine. Then, ﬁnally we could visualize and execute the geometry and dynamic models within a 2D or 3D

environment.

14.2 Scene Construction

14.2.1 Ontology

We need to formalize physical systems based on particular domain knowledge, since such formalism should

help to build multiple, cooperative simulation models of certain physical systems. We can describe a certain

target system using the concept of ontology. An ontology represents a formal conceptualization of a domain

by clearly specifying meaning of terms and their interrelationships among concepts used in a particular

domain (McGuinness, 2002; McGuinness and Harmelen, 2003; Berners-Lee et al., 2001). Ontologies

consist of three general elements: classes, properties, and the relationships between classes. Any concepts in

a target domain are represented as classes. Classes could be further generalized into speciﬁc categories using

“is-a-kind-of”relationship (i.e., generalization in uniﬁed modeling language (UML). Also,we can express a

structural relationship (i.e., association in UML) that speciﬁes mappings between objects (i.e., instances of

classes). Using “has-a”/“whole-part” relationship (i.e., aggregation in UML), structural dependency could

be described. In addition, certain constraints, such as multiplicity and multiple associations, are speciﬁed

14-6 Handbook of Dynamic System Modeling

along with the relationships between objects. We explain the conceptualization process by creating an

ontology for a sample domain: a boiling water domain. Figure 14.7 shows an example scene ontology for

boiling water (some concepts and relationships are not shown to avoid ontology complexity).

14.2.1.1 Classes and Relationships

Consider a pot of boiling water on a stovetop electric heating element. This domain contains a pot and

an electric stove with a temperature knob. Initially, the pot is ﬁlled to some predetermined level with

water. And this system has one input or control—the temperature knob. The knob is considered to be in

one of the two states: on or off. On the basis of the given domain knowledge, we could create four basic

classes, Pot, Electric Stove, Knob, and Water, as well as one abstract class called Scene. Because the overall

scene (i.e., boiling water scene) “is-a-kind-of” scene, we could add one more abstract class called Boiling

Water Scene as a subclass of the Scene class. And the electric stove “has a” knob. Therefore, aggregation

relationship could be created between the Electric Stove and Knob classes. In addition, we could make

aggregation relationships between the Boiling Water Scene class and Pot, Electric Stove, and Water classes,

since the scene contains the three classes. If we consider system dynamics approach (Fishwick, 1995),

which is a methodology for engineering simulation models, to examine the scene domain, we could derive

the following simple causal diagrams:

•

Knob_On  Water_Not_Cold

•

Knob_Off  Water_Cold.

The graphs show that “turning on/off the stove causes a change of water phase from cold/not cold to not

cold/cold.” (We assume that initially the water is in the cold phase.) Also, we could further generalize the

second nodes in the graphs. Hence, we could drive the following generalized causal graphs:

•

Knob_On  Water_Heating (=Water_Getting_Hotter)  Water_Boiling

•

Knob_Off  Water_Cooling (=Water_Getting_Colder)  Water_Cold.

By analyzing the causal graphs above, we could create a dependency relationship between Knob and Water

classes. Also, the Water class could be further generalized into “cold” water and “not cold” water based

on current water phase. Therefore, corresponding classes, such as Cold and Not cold, could be created as

subclasses of the Water class. Besides, more generalized water phases (i.e., heating, cooling, and boiling

phases) could be adopted as subclasses of the Not cold class. However, the following issue naturally arises:

How do we express the sudden change in temperature within the heating and cooling phases? In other

words, how do we naturally describe the continuous behaviors inside the phases? Therefore, we need

to deﬁne reasonable functions that could describe more speciﬁc dynamic behaviors inside the phases.

We could employ differential equations, since differential equations are the natural method of deﬁning

physical phenomena. Consider, for example, the heating phase. We could derive the following differential

equation using Newton’s law and the capacitance law:



=k(100 – T)

where T is the temperature (α ≤T ≤100, α is the ambient temperature) and k the thermal conductivity

of water (i.e., rate constant).

In this case, one integrator, one multiplication, one subtraction, and one constant-number generation

functions are needed. Therefore, corresponding functions are inserted into the Heating class as methods.

Likewise, proper functions for cooling phase could be inserted into the Cooling class.

We deﬁne Dynamic Model and Geometry Model classes, since we want a formalized scene domain in

which multiple model representations can exist together (i.e., integrative multimodeling) and a certain

model type can be transformed into another model type via user interactions (i.e., geometry model to

dynamic model and vice versa). In addition, Boiling Water Dynamic Model class is deﬁned as a subclass

of the Dynamic Model class. Similarly, Boiling Water Geometry Model class is deﬁned as a subclass of the

Geometry Model class. The Boiling Water Dynamic Model class could be composed of at least one dynamic

model, such as FSM or FBM. Therefore, we deﬁne FSM and FBM classes as subclasses of the Simulation

Multimodeling 14-7

Dynamic model

{abstract}

Simulation model

{abstract}

Transition

{abstract}

Sensor

{abstract}

Controller

{abstract}

State

{abstract}

Function

{abstract}

Trace

{abstract}

Mouse

sensor

Keyboard

sensor

Message

sensor

AND

controller

Python

controller

Expression

controller

Boiling water DM

The first-level

boiling water DM

The second-level

boiling water DM

The third-level

boiling water DM

FBM

FSM

Interaction

model

Actuator

{abstract}

Morphing

actuator

Message

actuator

Scene

{abstract}

Boiling water

scene

Boiling water GM

Handler

geometry

Water

geometry

Pot

geometry

has

Geometry model

{abstract}

3D geometry

{abstract}

Cube

Heating

has

Not cold

Cold

Water

Pot

Global handler

has

Cooling

Boiling

attribute: Has_function 

Instances of class Function

functions: Integrator,

Multiplier, Subtractor,

Constant generators.

attribute: Has_function 

Instances of Class Function

functions: Integrator,

Multiplier, Subtractor,

constant generators.

Sphere Arrow

FIGURE 14.7

An Example scene ontology for the boiling water.

14-8 Handbook of Dynamic System Modeling

Model class. Because each simulation model has its model elements (i.e., transitions and states for FSM;

traces and functions for FBM), we also deﬁne four classes such as Transition, State, Trace, and Function.

Likewise, Geometry class is created, since 2D/3D objects are needed for explicitly representing geometric

representations for a geometry model as well as a dynamic model in 2D or 3D space. Speciﬁc geometric

types, such as primitive objects (i.e., cube, sphere, and arrow) and nonprimitive objects (i.e., stove, water,

and pot), could be deﬁned as subclasses of the Geometry class. By conceptualizing the simulation model

type and 2D/3D geometry domains, we would provide syntactic and semantic mappings between objects

in the boiling water domain and objects in the simulation model type domain, and objects in the boiling

water domain and objects in the 2D/3D geometry domain.

To support the integrative multimodeling environment, we need to deﬁne additional classes, such

as Interaction Model, Scene Handler (i.e., 3D icons for supporting integrative multimodeling), Sensor,

Controller, and Actuator. We will cover these concepts in the following subsections.

14.2.1.2 Properties and Relationships

We assign two named properties (i.e., attributes), Geometry Model and Dynamic Model, to the Boiling Water

Scene class. In addition, we generate two association relationships, named“has a geometry model,” and“has

a dynamic model,” which connect to the Boiling Water Geometry Model and Boiling Water Dynamic Model

classes. Therefore, an object (i.e., an instance) of class Boiling Water Scene could have two attributes whose

values are objects of Boiling Water Geometry Model and Boiling Water Dynamic Model classes. Similarly,

two attributes, Geometry Object and Dynamic Model Element, are declared for the ﬁve fundamental classes

of the scene (i.e., Pot, Electric Stove, Knob, Water, and Scene Handler classes), since we assume that every

object in the scene has a corresponding geometric object for presentation as well as a dynamic model

element (i.e., state or function) for dynamics. Because Cold, Not Cold, Boiling, Cooling, and Heating

classes are subclasses of the Water class, these generalized classes can have their own attribute values that

are generated from Geometry, State, and Function classes. Therefore, we create association relationships,

named “has a geometry object,” and “has a dynamic model element,” between the water domain and the

geometry domain, and the water domain and the function/state domain. Because all classes in the water

domain are generated based on the water phases, state-based dynamic model type (i.e., FSM) could be the

reasonable choice to represent dynamics. Therefore, association relationships between the water domain

and the state domain are generated.

We create another association relationship named “uses” between class State/Function and class Geom-

etry, since 2D/3D objects are needed for explicitly representing geometric representations for a certain

dynamic model in 2D/3D space. An attribute, Interaction Model, is deﬁned inside Geometry class, since

we attempt to induce an overall scene interaction model by taking an individual interaction model for

each geometric object that the boiling water scene contains. In addition, we deﬁne three attributes, Sensor,

Controller, and Actuator, in class Interaction Model so that an interaction model for a certain object could

be inferred from its attribute values (i.e., sensor, controller, and actuator, which are components of an

interaction model) through ﬁrst-order logics. Likewise, the overall interaction model for the boiling water

scene could be generated from each object’s interaction model through ﬁrst-order logics. We will explain

the process for creating interaction models for the boiling water scene in next section. To represent relation-

ships above,we create four association relationships,“has a sensor,”“has a controller,”“has an actuator,” and

“has an interaction model,” between Interaction Model and Sensor classes, Interaction Model and Controller

classes, Interaction Model and Actuator classes, and Geometry and Interaction Model classes, respectively.

14.2.2 Interaction Model Creation

The purpose of integrative multimodeling is to provide a human–computer interaction environment that

allows users to change model types within the same environment. Therefore, user interactions should be

logically formalized and implemented to support the integrative multimodeling environment. We formal-

ize the user interaction as an interaction model and create the interaction model(s) through ﬁrst-order

logic rules. The interaction model consists of a sensor, a controller, and an actuator as model components

as well as links between components, since we will utilize Blender game logic bricks (Roosendaal and

Multimodeling 14-9

Wartmann, 2002), which have three logic components, sensors, controllers, and actuators, to execute the

interaction model.

First, we induce all interaction models for the main model components through logic rules. Then an

overall interaction model for a certain scene domain is generated from individual interaction models along

with logic rules. The following are general ﬁrst-order logic rules for creating interaction models used for

an individual object and an overall scene domain.

•

For an individual object

1. There exists an object

∃x Object(x)

2. There exists a sensor

∃x Sensor(x)

3. There exists a controller

∃x Controller(x)

4. There exists an actuator

∃x Actuator(x)

5. Every Object has an interaction model

∀x (Object(x)

 ∃ y (InteractionModel(y) ∧ hasInteractionModel(x,y)))

6. Every Interaction Model has a sensor

∀x (InteractionModel(x)

 ∃ y (Sensor(y) ∧ hasSensor(x,y)))

7. Every Interaction Model has a controller

∀x (InteractionModel(x)

 ∃ y (Controller(y) ∧ hasController(x,y)))

8. Every Interaction Model has an actuator

∀x (InteractionModel(x)

 ∃ y (Actuator(y) ∧ hasActuator(x,y)))

9. If Interaction Model has a sensor and a controller, it has a link that connects the sensor with the

controller

∃ x, y1, y2 (InteractionModel(x) ∧ Sensor(y1) ∧ Controller(y2) ∧ hasSensor(x,y1) ∧ hasCon-

troller(x, y2)



Link(y1, y2) ∧ hasLink(x, Link(y1,y2)))

10. If Interaction Model has a controller and an actuator, it has a link that connects the controller

with the actuator

∃ x, y1, y2 (InteractionModel(x) ∧ Controller(y1) ∧ Actuator(y2) ∧ hasController(x, y1) ∧

hasActuator(x,y2)



Link(y1, y2) ∧ hasLink(x, Link(y1,y2)))

•

For an overall scene domain

11. There exists a scene

∃x Scene(x)

12. The scene has an Interaction Model

∃x, y ((Scene(x)



(InteractionModel(y) ∧ hasInteractionModel(x,y))))

13. The Interaction Model includes all individual interaction models

∃x (InteractionModel(x)

 ∀ y (InteractionModel(y) ∧ includes(x, y)))

14. If there exists a “hasHandler” relationship between two objects and the objects have their

interaction models, then the interaction model has a link that connects the actuator of the

parent object with the sensor of the child object

∃w, x1, x2, y1, y2, z1, z2 (Object(x1) ∧ Object(x2) ∧ hasParent(x2, x1) ∧ hasInteractionModel(x1,

y1) ∧ hasInteractionModel(x2, y2) ∧ hasActuator(y1, z1) ∧ hasSensor(y2, z2)

 Link(z1, z2) ∧

hasLink(InteractionModel(w), Link(z1,z2)))

15. If two objects are conceptually mapped (i.e., geometry and dynamic model components for a

certain object), then the interaction model has a link that connects the actuator of the geometry

object with sensor of the dynamic object

∃ v, w, x1, x2, x3, y1, y2, z1, z2 (Object(w) ∧ hasDynamic(w, x1) ∧ hasGeometry(w, x2) ∧

uses(x1,x3) ∧ hasInteractionModel(x3, y1) ∧ hasInteractionModel(x2,y2) ∧ hasSensor(y1,z1) ∧

hasActuator(y2, z2)

 Link(z2,z1) ∧ hasLink(InteractionModel(v), Link(z2,z1)))

14-10 Handbook of Dynamic System Modeling

Interaction models for water’s geometry and dynamic

Sensor Controller Actuator

Interaction model for Handler’s geometry

Fade (Geometry

dynamic)

Fade (Dynamic

geometry)

FIGURE 14.8 The overall interaction model for the boiling water scene.

16. If two objects are conceptually mapped (i.e., geometry and dynamic model components for a

certain object), then the interaction model has a link that connects the sensor of the geometry

object with actuator of the dynamic object

∃ v, w, x1, x2, x3, y1, y2, z1, z2 (Object(w) ∧ hasDynamic(w, x1) ∧ hasGeometry(w, x2) ∧

uses(x1,x3) ∧ hasInteractionModel(x3, y1) ∧ hasInteractionModel(x2,y2) ∧ hasSensor(y2,z2) ∧

hasActuator(y1, z1)

 Link(z2,z1) ∧ hasLink(InteractionModel(v), Link(z2,z1))).

Based on these rules, we could induce an interaction model for the boiling water scene. First, we need

to deﬁne a user interaction scenario: (1) if an individual model object is touched, only the object is

transformed into other model type’s object (i.e., a geometry model object to a dynamic model object and

vice versa) and (2) if a handler (i.e., 3D icon) is touched, all model objects are transformed into other model

type’s objects (i.e., all geometry model objects to all dynamic model objects and vice versa). According to

the scenario, total three interaction models are needed: two for Water (i.e., geometry and dynamic objects)

and one for Handler (i.e., geometry object). Additional association relationships, such as “has a link” and

“has a hander,” are inserted in the scene domain so that we could represent a topological connectivity

between interaction model components and interaction models. Figure 14.8 shows the overall interaction

mode for the boiling water scene.

The Protégé Ontology Editor (2006) is employed to create an actual scene ontology as well as ﬁrst-

order logic rules. Web ontology language (OWL) (Lacy, 2005) and semantic Web rule language (SWRL)

(Horrocks et al., 2004) are utilized to construct an ontology and logic rules. To verify an ontology for

a certain scene domain, we use RACER (2006) reasoner along with Protégé. Based on the ontological

structures for the boiling water scene, we deﬁne all the classes and subclasses for the scene domain

and modeling knowledge along with all necessary relationships based on Figure 14.7. An interaction

model for the boiling water scene could be induced from the scene ontology using ﬁrst-order logic rules.

Therefore, using an inference engine such as Jess (2006), we could inference certain knowledge from

domain knowledge in OWL through inference processes. In Protégé, we use SWRL to describe ﬁrst-order

logic rules, since SWRL tab is provided to allow users to create user-deﬁned logic rules. There are a couple

of approaches for inference in Protégé:

1. Create ﬁrst-order logic in SWRL and then perform inference using a Jess rule engine.

2. Write and store logical constraints using ProtégéAxiomLanguage (PAL) and then perform inference

using PAL query statements.

We use the ﬁrst approach since SWRL includes a high-level abstract syntax for Horn-like rules. However,

the current version of Protégé does not provide inference capability for SWRL. Therefore, we manually

generate an interaction model for the boiling water scene based on logic rules at this time.

14.2.3 Blender Interface

We developed a Python-based interface, Blender Interface (Park and Fishwick, 2004a, 2004b; Park, 2005),

which can build 3D simulation models based on an ontology for a certain target domain. Blender Interface

consists of two components, Model Explorer and Simulation. Figure 14.9 depicts the overall environ-

ment in the Blender software. The environment consists of Blender 3D Window (Scene Editor), Blender

Multimodeling 14-11

FIGURE 14.9 Blender environment containing the game engine.

Interface, and Blender Logic Brick. Geometry and dynamic models for a certain system are composed

in the Scene Editor, while specifying the dynamic model types and styles for the system and generating

Python simulation code for the dynamic model in the Blender Interface. The Python code is inserted into

Blender Logic Brick to simulate the dynamic model. In addition, the interaction model, which could be

induced through inference processes,is implemented and executed in the Blender Logic Brick for providing

a human–computer interaction environment.

To use Blender Interface, RUBE must be installed. The RUBE has four folders: primitive, predeﬁned theme,

user-deﬁned theme, and rube_utility folders. The primitive and predeﬁned theme folders are given for users

to provide libraries containing dynamic model objects and the corresponding MXL (we will explain it in

detail in the next section) ﬁles and functions in Python. As the names imply, the primitive folder has primi-

tive blender objects, such as cube and sphere, with the corresponding MXL ﬁle and function for each model

type, such as FSM or FBM. The predeﬁned theme folder contains prefabricated, customized and personal-

ized blender objects, as well as MXL ﬁles and functions. If modelers want their own model representations,

they can create an object and store it into a proper model-type folder under the user-deﬁned theme.

Using Model Explorer, modelers are able to search model objects, which they want to import, within the

RUBE folders. From the given dynamic model components in Blender 3D Editor using Simulation (we will

explain it in detail in Section 14.5), we can generate an MXL ﬁle for the target system automatically, since

we provide library systems that contain Blender objects as well as the corresponding MXLs and functions

in a set of pairs.

14.3 Multimodeling Exchange Language (MXL)

14.3.1 Concepts of MXL

MXL is an XML-based dynamic modeling language used to represent traditional simulation model types

within the RUBE framework. For MXL, the functional elements for each model type are clearly identiﬁed,

and entry points of the functional elements are deﬁned as ports.

The functional elements are model components that behave as functions that naturally ﬁt as part of

the model description. Figure 14.10 shows the multimodel structure of MXL. Multimodeling is permitted

wherever the appropriate model component could be “extended” or “expanded” to another model whose

outermost deﬁnition is a function. These couplings achieve multimodeling by inserting one function

inside of another (interlevel coupling) or by connecting one function to another (intralevel coupling).