An XML-based 3D model visualization and simulation framework for dynamic models

Transcription

1 An XML-based 3D model visualization and simulation framework for dynamic models T. Kim a and P. Fishwick b, U. of Florida Computer and Information Science and Engineering Department University of Florida, Gainesville, FL ABSTRACT Relatively recent advances in computer technology enable us to create three-dimensional (3D) dynamic models and simulate them within a 3D web environment. The use of such models is especially valuable when teaching simulation, and the concepts behind dynamic models, since the models are made more accessible to the students. Students tend to enjoy a construction process in which they are able to employ their own cultural and aesthetic forms. The challenge is to create a language that allows for a grammar for modeling, while simultaneously permitting arbitrary presentation styles. For further flexibility, we need an effective way to represent and simulate dynamic models that can be shared by modelers over the Internet. We present an Extensible Markup Language (XML)-based framework that will guide a modeler in creating personalized 3D models, visualizing its dynamic behaviors, and simulating the created models. A model author will use XML files to represent geometries and topology of a dynamic model. Model Fusion Engine, written in Extensible Stylesheet Language Transformation (XSLT), expedites the modeling process by automating the creation of dynamic models with the user-defined XML files. Modelers can also link simulation programs with a created model to analyze the characteristics of the model. The advantages of this system lie in the education of modeling and simulating dynamic models, and in the exploitation of visualizing the dynamic model behaviors. Keywords: Modeling, Simulation, XML, VRML, X3D, XSLT, rube Methodology, 3D, aesthetic programming 1. INTRODUCTION Simulation as the process of using a model to gain insight on the behavior of real world system requires a specific set of skill, such as modeling, programming, statistics, and heuristic methods. Among these, modeling is perhaps the least well defined and the most vital to the success of simulation. Recent advances in computer technology enable us to work in 3D web environment for modeling and simulating dynamic models, which specify how an object behaves over time. Especially, the advances in XML-related technology opened a new standard way to create an arbitrary semantic structure and share it with anyone on any other computing platform over the internet. Our primary research goal is to find the most effective way to represent both geometry and dynamic model information using XML, and then encode the fusion process of these XML files into a mediator in such a way that is scalable, easy to understand, and easily modifiable. An additional goal is to provide a simulation capability that can simulate the model, which is defined within the given XML files. We have constructed an XML-based software framework, called rube, which encompasses the modeling process of a real world system as well as the simulation process of the model. One of the major features of this modeling architecture, which distinguishes it from other 3D modeling architectures, is the separation of geometry from the dynamics as expressed by a typical model used within computer simulation. In rube, a 3D dynamic model representation is separated into two parts: the scene file, which contains 3D geometry objects, and the model file, which describes topology and behavior of the scene. The Model Fusion Engine, which is an XSLT-based mediation system for reordering and fusing XML documents representing the scene and model, blends scripts into the node structure of an XML document to create a dynamic 3D model in X3D. A system, being modeled, can also be simulated with input data using SimpackJS, which provides simulation capabilities, using Javascript, in rube. a twkim@cise.ufl.edu b fishwick@cise.ufl.edu

2 The rube architecture for modeling and simulation is introduced after we discuss some of the related technologies implemented inside the architecture. The modeling process, using the architecture and the Model Fusion Engine, is explained with representative examples. We also discuss simulation processes relating to how to link simulation software to the created model, while visualizing the simulation results. Section 2 discusses the background technologies related to this research. Section 3 addresses the overall rube architecture with two component files. Section 4 presents modeling and simulation examples using the architecture, and Section 5 concludes the article by discussing future research. 2.1 Modeling and Simulation 2. BACKGROUND Simulation is defined as using a model to develop conclusions that provide insights on the behavior of real world systems. Using a computer to imitate or simulate the operations of a real world process or facility requires that a set of assumptions taking the form of logical or mathematical relationships be developed and then shaped into a model 1. This model can then be manipulated to help the simulation analyst gain an understanding of the dynamics at work within the system. A system is defined to be a collection of entities, e.g., people or machines, that act and interact together toward the accomplishment of some logical end 2. In practice, what is meant by "the system" depends on the objectives of a particular study. At some point in the lives of most systems, there is a need to study them to try to gain some insight into the relationships among various components, or to predict performance under some new conditions being considered. For economic reasons, we usually build a model as a representation of the system and study it as a surrogate for the actual system. The vast majority of models built for such purposes are mathematical, representing a system in terms of logical and quantitative relationships that are then manipulated and changed to see how the model reacts, and thus how the system would react - if the mathematical model is a valid one. Once we have built a model, it must then be examined to see how it can be used to answer the questions of interest about the system it is supposed to represent. If the model is simple enough, it may be possible to work with its relationships and quantities to get an exact, analytical solution. Otherwise, the model must be studied by means of simulation, i.e., numerically exercising the model for the inputs in question to see how they affect the output measures of performance. Implicit in the foregoing definition of simulation is the need for a specific set of skills, such as modeling, computer programming, probability and statistics, and heuristic methods. Among these skills, the area of modeling is perhaps the least well defined of the set and the most vital to the success of simulation 3. Models may be thought of as containing only the essentials of the real world system and the ability to develop a good model is fundamental to the success of any simulation analysis. There is an art to conceptualizing a model. The modeler must understand the structure and operating rules of the system and be able to extract the essence of the system without including unnecessary detail. Good models tend to be easily understood, yet have sufficient detail to reflect realistically the important characteristics of the system 4. Computer simulation can be summarized and will be used in this research as the discipline of designing a model of an actual or theoretical physical system, executing the model on a digital computer, and analyzing the execution output 5. In order to conduct a successful modeling and simulation, we must be able to express the model in an efficient and effective form that can be shared by modelers and researchers. One of our research goals is to provide an effective way to represent a model in XML in a way that supports reuse, sharing of information and modular distribution of models over the web. 2.2 VRML VRML, which is an abbreviation for Virtual Reality Modeling Language, represents the standard 3D language for the web 6. To be precise, VRML is not a modeling language but an effective 3D file interchange format, a 3D analog to HTML. 3D objects and worlds are described in VRML files using a hierarchical scene graph, which is composed of entities called nodes. Nodes can contain other nodes and this scene graph structure makes it easy to create complex, hierarchical systems from subparts. VRML also defines an event or message-passing mechanism by which nodes in the scene graph can communicate with each other and Script nodes can be inserted between event generators and event receivers. Script nodes allow the world creator to define arbitrary behaviors, defined in any supported scripting languages, such as JavaScript. Even though VRML is not a full-fledged programming language, some of its features make it a useful tool for modeling dynamic systems in 3D environment. These features include the ability to create user prototype nodes that can be reused in various models and the ability to incorporate scripts inside these custom nodes, which enable objects to perform various functional behaviors. This addition of behavior information to 3D objects in VRML files and the fact that created worlds using VRML are freely accessible over the web make VRML a robust tool for our rube Methodology.

3 Since 1998, Fishwick 7 and his research team have developed a 3D modeling paradigm called rube. The key task was to derive a methodology for constructing various dynamic models 5 in a structured way, and to build a set of VRML prototypes to make it easy for modelers to choose common dynamic model types in their multimodels 8,9. During the past few years, VRML has been used to construct dynamic models by mapping familiar 2D icons to the corresponding 3D primitives. VRML served as a tool for the rube Methodology to create geometries and dynamic behaviors of objects in a model. Several dynamic model templates have been constructed in order to support the rube Methodology 10,11,12. These templates have been provided over the web as the building blocks for creating dynamic models which incorporate personal aesthetics of individual modelers. These simple examples of model templates serve as tutorial guidelines on building behavioral structures in VRML and on how more complex dynamic model buildings can be accomplished. 2.3 X3D Recently, we made a transition from VRML to X3D, which stands for "extensible 3D". X3D is structured completely in XML, which is the language of the web being promoted by the Web3D Consortium 13. Since XML has many benefits for model design, transitioning from VRML to X3D was natural and logical. The next-generation Extensible 3D (X3D) Graphics specification was designed and implemented by the X3D Task Group of the Web3D Consortium. They have expressed the geometry and behavior capabilities of the VRML 97 using the Extensible Markup Language (XML). The standardization of X3D specification is still an ongoing process and the following are the characteristics of the current X3D explained by the Web3D Consortium as of September : ½ X3D is componentized: allows lightweight core 3D runtime delivery engine. ½ X3D is extensible: allows components to be added to extend functionality. ½ X3D is profiled: standardized sets of extensions to meet specific application needs. ½ X3D is VRML backwards compatible: preserve VRML97 momentum and content. ½ X3D is XML integrated: the key to integration with next generation web standard. ½ X3D is broadcast/embedded application ready: not just the PC should be using 3D. In short, we can think of X3D as an XML version of VRML with several added functionalities. One of the shortcomings in working with the X3D is that currently no working X3D browser is available. Consequently, in order to work with an X3D file, it has to be translated into a VRML file using translators, such as NIST translator 15. In our proposed rube architecture, a model is decomposed into a scene file, which contains hierarchically grouped geometry that represents the 3D structure of a model to be constructed, and a model file, which contains topology and behavior of the model. Currently, a scene file is created in VRML and then translated into X3D to be processed by our proposed Model Fusion Engine. The output of the Fusion Engine is also an integrated X3D file, which needs to be translated back into a VRML file to be displayed in a VRML browser. 2.4 XML XML stands for "extensible Markup Language". It is a new markup language developed by the World Wide Web Consortium (W3C) 16 mainly to overcome limitations in HTML such as lack of separating the content from the information on how to represent it. In 1996, Jon Bosak of Sun Microsystems recruited a group of Standard Generalized Markup Language (SGML) experts and formed the XML Working Group. Working under the auspices of the W3C, they hammered out an initial version of XML 17. XML 1.0 became a W3C Recommendation in February XML is a simple, standard way to delimit text data. It has been described as "the ASCII of the Web". It is as if you could use your favorite programming language to create an arbitrary data structure, and then share it with anyone using any other language on any other computing platform. XML provides a way to define your own structure for documents and a way to keep the structure and presentation information separate. Unlike traditional methods of presenting data, which relied on extensive bodies of code, the presentation techniques for styling XML are data driven. MXL styling is accomplished through another document dedicated to the task called a style sheet. The styles and rules are applied to an XML document's data at the time of presentation. In short, XML is a powerful, elegant technique for thinking about, exchanging, and presenting data in a platform-independent manner 18. The features described above made XML an attractive tool for our research, and we have implemented components in the rube architecture using the XML-based technologies such as XML Schema and Extensible Stylesheet Language

4 Transformations (XSLT). Initially, we used a Document Type Definition (DTD) in order to define the rules of a model file, which contains a topology of a model, written in XML. These definitions capture the rules to extend the core rules of XML syntax and create a vocabulary to describe our model file. But DTD have some limitations. One problem with DTD is that it does not allow one to use namespaces, which is a source of names on which a document designer wishes to draw. By attributing the source, one can borrow from other sources and use partial vocabulary without ambiguity. Another shortcoming of DTD is that it does not support data types. Due to these reasons, we have used XML Schema to represent the necessary rules and syntax of our Model Exchange Language (MXL), the language which is used to define a model file containing the topology of a model and exchange the model file over the internet. Another powerful XML technique we have used in our rube architecture is the transformation. Transformations allow a programmer to map an XML document in one form into another based on a set of rules that are applied to the first document. Transformations are part of a styling language for XML called the Extensible Style Language (XSL). The transformation language we have used to create our Model Fusion Engine is called XSL Transformations (XSLT). 2.5 XSLT The Extensible Stylesheet Language (XSL) 19, which was developed as a part of the W3C Style Sheets Activity 20, enables us to transform documents written in XML. The XSL Transformations (XSLT) is designed for use as a part of XSL to describe how one document is transformed into another XML document. XSLT is described in the XSLT specifications as follows: "XSLT is a language for transforming XML documents into other XML documents" 21. The XSLT specification became a Recommendation on November The dominant feature of a typical XSLT stylesheet is that it consists of a sequence of template rules, each of which describes how a particular element type or other construct should be processed 22. It is this that makes XSLT a declarative language: you say what output should be produced when particular patterns occur in the input, as distinct from a procedural program where you have to say what tasks to perform in what order. XSLT also relies on the XML Path Language (XPath) specification 23, which became a recommendation on the same day as XSLT specification, as a way of selecting the area of the document to transform. XSLT is a language written in XML, which means that an XSLT style sheet for transforming an XML document is actually a well-formed XML document. One of the most common ways of making XSLT transformations happen is to use standalone XSLT processors such as SAXON 24, Xalan 25, and XT 26. We have developed the Model Fusion Engine with XML Spy 27, which is an Integrated Development Environment for XSLT. In order for our Model Fusion Engine, written in XSLT, to be able to transform a model file document, the document must first be converted into a structure or an internal model. This internal model is a tree. Formally, XSLT transformations accept a source tree as input, and produce a result tree as output 28. By implementing XML-based technologies discussed above, we have constructed an 3D XML-based software architecture, including a demonstrable graphical user interface and a Model Fusion Engine, which supports the fusing of two common types of information: geometry models and dynamic models. An important part of the fusion process is the integration of behavior, which is represented as blending scripts into the node structure of an XML document. The output of the fusion process is an integrated X3D file, which contains geometric scene information as well as the corresponding models and their behavior. 3.1 Structure of rube for Modeling 3. XML-BASED rube ARCHITECTURE The graphical user interface (GUI) and overall structure of the Model Fusion Engine are discussed in the following two subsections. The GUI is created with HTML, Perl and CGI scripts in order to automate the process of merging the two files: the scene file, which contains user-defined 3D geometry and the model file, which is the topology file defining the connectivity and behavior of the model type. Until a complete X3D browser becomes available, all the VRML files need to be translated into X3D files for the Model Fusion Engine. Also, the merged X3D file needs to be translated back into a VRML file to be displayed in the VRML browser rube GUI A simple user interface is provided on the web 29 as shown in Figure 1. There are two sections in the window: the lower part of the screen where a user can specify or upload user-defined scene and model files and the upper part of the window where newly created 3D dynamic model is displayed with a VRML browser such as Blaxxun Contact, Parallel Graphics' Cortona, or Cosmo Player.

5 This section displays newly created 3D dynamic model with a VRML browser. This section accepts user defined scene and model files. Figure 1. A Graphical User Interface When a user specifies scene and model files, the scene file, which is a VRML world either created or exported from other 3D software such as CosmoWorlds or 3D Studio Max, is translated into an X3D file using the NIST translator 15 and fed into to the Model Fusion Engine. The model file, which is a user-defined XML file containing topology and dynamic behavior of the model, is also fed into the Model Fusion Engine as an input. The Model Fusion Engine in the background merges two files and creates an X3D file, which represents the 3D dynamic model with the specified behavior. The final result is then translated into VRML file and displayed in a VRML browser as shown above XML rube Architecture with Model Fusion Engine The overall structure of the XML based rube architecture is shown in Figure 3. This architecture allows a model author to either create new 3D objects or reuse existing digital objects from warehouses as well as from dynamic model repositories on the web. Instead of generating objects automatically by the Model Fusion Engine, much of the freedom in defining and creating 3D objects has been given to the model author. Objects can be personalized and made culturally or aesthetically meaningful 12,30 as shown in Figure and Figure Both figures represent different metaphorical styles impressed upon the same XML file used in Figure 1. Figure 2-1. FSM with fluid pipe metaphor Figure 2-2. FSM with landscape architecture metaphor One of the major features of this modeling architecture, which distinguishes it from other 3D modeling architectures, is that it separates geometry from the inter-object semantic relations. Any scene file, which represents geometry and appearance, can be used along with any model file, which contains information about relations and behaviors of the model. Since there is no working X3D browser, a translator between VRML and X3D has been incorporated. This component will be removed as soon as a working version of an X3D browser appears. Another important feature is the existence of the Model Fusion Engine, which is an XML-based mediation system for reordering and fusing XML documents representing the scene and model as described above. The Model Fusion Engine handles the fusion process, where an important part of the fusion process is the integration of behavior, which is represented as blending scripts into the node structure of an XML document. The output of the fusion process is an integrated X3D file, which contains both geometry scene information as well as the corresponding models and their behavior.

6 The Model Fusion Engine is an XSLT-based fusion mediator, which supports the merging and restructuring of XMLbased information input files. XSLT is XML-based, meaning the XSLT processor is capable of analyzing an XML document and converting it into a node tree which can be efficiently manipulated and restructured using XSLT stylesheet. It accepts both scene and model files, analyzes each file and creates a new X3D file by merging and inserting scripts according to the specified behavior in the model file. Each behavior is modularized and used as a separate library. Currently, a Finite State Machine (FSM) is incorporated into the Model Fusion Engine and other model types, such as Functional Block Model (FBM) and Petri Net (P-Net) 5, are being developed. Digital Object Warehouse VRML 3D Modeler create reuse Model Author Dynamic Model Repository XML create Text Editors VRML specify VRML specify XML Scene File VRML Graphical User Interface XML Model File VRML VRML XML NIST Translator X3D X3D XML Model Type fsm Model Fusion Engine (XSLT) pulsate Behaviors Figure 3. XML-based rube architecture for Modeling 3.2 Component 1: Scene File A scene file contains nodes, which describe objects and their properties. It contains hierarchically grouped geometry that represents the 3D structure of a model to be constructed. A simplified example of a VRML scene file is shown in Figure 4-1, which contains three spheres and three arrows, each of which is composed of a cylinder and a cone. #VRML V2.0 utf8 DEF S1 Transform { translation geometry Sphere {} } DEF S2 Transform { translation geometry Sphere {} } DEF S3 Transform { translation geometry Sphere {} } DEF T12 Transform {translation rotation geometry Cylinder {radius height} geometry Cone {bottomradius height}} DEF T23 Transform {translation rotation geometry Cylinder {radius height } geometry Cone {bottomradius height}} DEF T32 Transform {translation rotation geometry Cylinder {radius height} geometry Cone {bottomradius height}} Figure 4-1. VRML scene file <?xml version="1.0" encoding="utf-8"?> <?xml-stylesheet href="x3dtovrml97.xsl?> <X3D> <Scene> <Transform DEF="S1" translation=""> <Sphere /> </Transform> <Transform DEF="S2" translation=""> <Sphere /> </Transform> <Transform DEF="S3" translation=""> <Sphere /> </Transform> < Transform DEF="T12" translation="" rotation=""> <Cylinder radius="" height=""/> <Cone height="" bottomradius=""/></transform> < Transform DEF="T23" translation="" rotation=""> <Cylinder radius="" height=""/> <Cone height="" bottomradius=""/></transform> < Transform DEF="T32" translation="" rotation=""> <Cylinder radius="" height=""/> <Cone height="" bottomradius=""/></transform> </Scene> </X3D> Figure 4-2. Translated scene file in X3D

7 The model author can create new objects with a 3D modeling program, such as 3D Studio Max, or reuse any 3D objects found on the web. When using 3D software, the model author should export the scene into a VRML file. Since the model generator works on XML files, the VRML scene file is automatically translated into an X3D file using the NIST translator during the model generating process shown in Figure 4-2. A translated scene file is fed into the Model Fusion Engine as an input along with a model file. A model file, which represents topology and relations, shown in Figure 5 is also fed into the Engine. In order for the Engine to merge the two files and generate a 3D dynamic model, each object in the scene file must be given a unique name that will correspond to the name of each object in the model file. This is an important step in merging two different files, which describe the same model in two different ways. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE MXL SYSTEM "mxl.xsd"> <MXL> <model type= FSM > <topology type= GRAPH > <node id= S1 type= STATE start= TRUE ></node> <node id= S2 type= STATE ></node> <node id= S3 type= STATE ></node> <edge id= T12 type= TRANSITION begin= S1 end= S2 ></edge> <edge id= T23 type= TRANSITION begin= S2 end= S3 ></edge> <edge id= T32 type= TRANSITION begin= S3 end= S2 ></edge> </topology> <behavior type="vibrate"> <axis id="x"></axis> </behavior> </model> <simulation type= FSM > <program name= fsmmain.js ></program> <simtime duration= 120 ></simtime> <inputdata type= RANDOMGENERATOR ></inputdata> </simulation> </MXL> Figure 6. Model file in MXL 3.3 Component 2: Model File A model file is composed of two sub-components: model and simulation elements as shown in Figure 5. model contains type of model being used as an attribute, topology, which defines the connectivity of the model type as a sub-element, and dynamic behavior, which describes the type of animation that signifies the current state as another sub-element. Currently, a graph grammar is used to represent the topology of the model, composed of node and edge elements. Each node and edge element has an attribute, id, to specify the names of states and transitions in an FSM. One of the nodes contains information, which labels the starting state. The edge element also has begin and end attributes denoting the start and the end state of each transition. The model author can assign unique names to each node and edge, but it is important that the names given here, such as S1, S2 and T12, are identical to the names assigned to each object in the scene file. The Model Fusion Engine uses these names to link each component and blends necessary script into each node. The MXL file contains the following key elements: ½ behavior, which is another sub-element of the model element, contains type of animation that will be executed in order to represent the current state in the 3D FSM model. Each behavior is defined as a separate module, and blended into the dynamic model by the Model Fusion Engine according to the specified behavior type. Currently, pulsate and vibrate behaviors are defined and implemented with the vibrate behavior being further sub-divided with each X, Y or Z-axis. With pulsate behavior, an object, which represents the current state, pulsates over time. Also, with vibrate behavior, an object vibrates along the axis, which user specified in the model file.

8 ½ simulation, along with the model element described above, comprises the whole MXL file. It contains information about simulating the real world system being modeled with input data provided by either random generator or separate input data file stored locally. simulation element has type attribute, which denotes the type of dynamic model being simulated and three sub-elements: program, simtime and inputdata element. ½ program specifies the name of the main program, which runs the modules, such as queuing.js, in SimPack 33, developed in simulation lab at the University of Florida, to simulate the model. SimPack is a collection of tools for computer simulation, originally developed in C and C++. Currently, it is converted into JavaScript and being implemented within the XML-based rube architecture. The purpose of SimPack is to provide users with a discrete event simulation library. simtime has an attribute, duration, which represents the elapsed time between start time and end time of the simulation in milliseconds. inputdata specifies the type of input data, which will be used in simulating the system. It can either be generated by the random generator or provided within a file containing input data. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE MXL SYSTEM "mxl.xsd"> <MXL> <model type= FSM > <topology type= GRAPH > <node id= S1 type= STATE start= TRUE ></node> <node id= S2 type= STATE ></node> <node id= S3 type= STATE ></node> <edge id= T12 type= TRANSITION begin= S1 end= S2 ></edge> <edge id= T23 type= TRANSITION begin= S2 end= S3 ></edge> <edge id= T32 type= TRANSITION begin= S3 end= S2 ></edge> </topology> <behavior type="vibrate"> <axis id="x"></axis> </behavior> </model> <simulation type= FSM > <program name= fsmmain.js ></program> <simtime duration= 120 ></simtime> <inputdata type= RANDOMGENERATOR ></inputdata> </simulation> </MXL> Figure 6. Model file in MXL The model file written in MXL captures all the information about the model, topology that defines the connectivity of the model type and their behavior, as well as information needed to run the simulation. It provides an effective way to represent both geometry and dynamic model information using XML. 3.4 Component 3: Model Fusion Engine The Model Fusion Engine plays central role in the 3D dynamic modeling process within rube. There are two processes in the Model Engine: the fusion and the blending processes. In the fusion process, two XML documents, scene and model files, are fused into another XML document. In the blending process, behaviors, described in script nodes, are blended into node structures of a newly created XML document. The fusion part of the Engine is an XSLT-based process, where XML documents are used as input and an XML file is produced as a final output. It first examines the model file, which contains topology and behavior of a system being modeled, and constructs a 3D dynamic model according to the specifications shown in Figure 5. The skeleton of the dynamic model is created by copying all geometry from the scene file that matches the names of each corresponding node and edge in the model file. The blending process adds JavaScript and ROUTE statements to the static skeleton of the 3D model and makes it a dynamic model, which performs a desired behavior. According to the behavior specified in the model file, corresponding script is appended to each object. The control script is also created to synchronize the behaviors of each object. The ROUTE

9 statements, which serve as the nerve system in which the control signals could flow, are also attached to the final 3D dynamic model. The Model Fusion Engine is developed with XML Spy version 4.0 from Altova 27, an Integrated Development Environment (IDE) for XML. It supports XML document editing and validation, W3C's XSD Recommendation, and XSLT. The XSD, XML Schema Definition language, is an XML-based grammar for describing the structure of XML document, such as the model file being used in our modeling process. XML Spy can validate the XML document against an XSD schema, such as MXL, Model Exchange Language created for the modeling process in the rube architecture. In order to support the simulation process of a model, the simulation capability, which is empowered by SimpackJS, is being added to the Model Fusion Engine. The SimpackJS is the JavaScript version of the SimPack written in C and C++. By providing modeling and simulation capabilities, the Model Fusion Engine supports the rube architecture to comprehend both processes. 4. MODELING AND SIMULATION EXAMPLES In this section, we present working examples for modeling and simulation. With the previous VRML prototypes, a modeler had to hand code all the components in 3D world to create a dynamic model. This modeling process can be expedited with the use of Model Fusion Engine. A modeler can link a user defined simulation software to the created model and run the simulation and visualize the result. 4.1 Modeling Example In this sub-section, several 3D dynamic FSM models are created using the Model Fusion Engine. A user can use any shape of geometry and define any number of geometries with inter-relations between each element in the model file. First, the scene file, saved as "scene.wrl", used in this example is shown in Figure 6-1. This file is created with Cosmo Worlds and saved as a VRML file. It contains only the geometries that will be used to represent each state and transition in the FSM model. For the demonstration purposes, all the possible transitions from one state to the other state have been created in a file. The model file, saved as "3s3t-FSM-Vibrate-X.xml", used to specify topology of the model is shown in Figure 6-2. <?xml version="1.0" encoding="utf-8"?> <MXL> <model type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"></node> <node id="s3" type="state"></node> <node id="s4" type="state"></node> <edge id="t13" type="transition" begin="s1" end="s3"/> <edge id="t34" type="transition" begin="s3" end="s4"/> <edge id="t43" type="transition" begin="s4" end="s3"/> </topology> <behavior type="vibrate"> <axis id="x"></axis> </behavior> </model> </MXL> Figure 6-1 Figure 6-2 By modifying the number of node and edge elements, a modeler can select which objects to include in the final FSM world to represent each state and transition. By defining suitable transition information, behaviors that represent the actual state changes are encoded by the Model Fusion Engine and visualized in the final FSM model. Some of the resulting FSM models with different variations described above are shown in Figure 7. Figure 7

10 In these examples, state changes are represented by vibrating the current state. Different behaviors, such as 'PULSATE', can be defined in the model file. Two examples with different behaviors are shown in Figure 8. Click figures to see the animation of each model. Figure 8 Objects can be personalized and made aesthetically meaningful to the modeler. The Model Fusion Engine was provided to the simulation class at the University of Florida for students to create their own dynamic models using the rube architecture. Two examples of FSM models created by the students are shown in Figure 9-1 and 9-2. Click figures to see the different behaviors to represent the current state. Other examples can be found at Simulation Example Figure 9-1 Figure 9-2 A modeler can simulate the created model with a user defined simulation program in the rube architecture. Overall Modeling and Simulation process is shown in Figure 10. In the Modeling process, the Model Fusion Engine creates a 3D dynamic model with two files provided by the modeler. In the Simulation process, a modeler creates a simulation program according to the simulation requirements and provide input data to be executed. It is linked with 3D dynamic model where the internal state of simulation is visualized with the result received from simulation program. Also, the modeler can visualize the simulation report with each status data produced from the simulation program. The program that visualizes the output of the simulation can be defined by the modeler and merged into the model. The simulation report can be displayed textually or graphically with the model. The report can be generated dynamically as shown in Figure 11-1.

11 Figure 10 A set of simulation programs written in Javascript, called SimPackJS, is provided with the rube architecture. Originally, the SimPack was written in C and C++ by Fishwick in The purpose of SimPack was to provide people with a starting point for simulating a system. It is translated into Javascript and being merged into the rube architecture as one of the simulation packages. A student can add additional programs in the created model to analyze the behavior of the dynamic system as shown in Figure Figure 11-1 Figure 11-2 As each example model of SimPackJS simulation program is created, it will be provided on the internet. With the modeling and simulation capabilities, rube architecture will serve as a repository of education framework for teaching and learning the behaviors of 3D dynamic models. 5. CONCLUSION AND FUTURE WORK Our goal is to create and implement a framework, based on XML technology, to define and fuse model information in a way that supports reuse, sharing, and distribution of models. We have formulated and presented XML-based software architecture, called rube. In our rube architecture, a 3D dynamic model has been effectively represented in two parts: scene and model files. By implementing the Model Fusion Engine, which is developed in XSLT for fusing XML documents, we have demonstrated the feasibility of encoding the fusion process into the mediator in such a way that is easy to understand and easily modifiable. To date, this method has been employed in both the Undergraduate and Graduate Computer Simulation classes (CAP 4800 and CAP 5805) with much success. While there is incurred overhead in creating 3D model structures, as compared with their 2D brethren, students find it more challenging and engaging to work in 3D. The inherent

12 assumption is that as 3D becomes faster, more predominant, and easier to employ, this will have dramatic effects on the way in which we model. Remaining tasks to our architecture and implementation include: 1) applying the results to other dynamic model types such as Functional Block Model (FBM) and Petri net (PETRI); 2) performing in-depth research on implementing multimodel concept; and 3) fully incorporating a simulation capability to provide the rube as an architecture that supports both modeling and simulation. ACKNOWLEDGMENTS We would like to thank the National Science Foundation under grant EIA and the Air Force Research Laboratory under grant F for their sponsorship of the rube methodology and the model fusion engine. We would also like to thank Andrea Goethals, Jinho Lee, and Minho Park for their work on the graphical user interface and SimPackJS. REFERENCES 1. R. McHaney, Computer Simulation, Academic Press, J. W. Schmidt and R. E. Taylor, Simulation and Analysis of Industrial Systems, Richard D. Irwin, Homewood, Ill., S. V. Hoover et R. F. Perry, Simulation : A Problem-Solving Approach, Addison-Wesley, A. Alan et. al, Simulation with Visual SLAM and AweSim, John Wiley & Sons, P. A. Fishwick, Simulation Model Design and Execution: Building Digital Worlds, Englewood Cliffs, Prentice-Hall, R. Carey and G. Bell, The Annotated VRML 2.0 Reference Manua, Addison-Wesley, P. A. Fishwick, On Web-Based Models and Repositories, Enabling Technology for Simulation Science within SPIE '01 AeroSense Conference, Orlando, P. A. Fishwick and B. P. Zeigler, A multimodel methodology for qualitative model engineering, ACM Transactions on Modeling and Computer Simulation, 2(1):52-81, K. Lee and P. A. Fishwick, Generation of multimodels and selection of the optimal model for real-time simulation, SPIE Aerosense Conference, pp , J. Hopkins, and P. A. Fishwick, A Three-Dimensional Human Agent Metaphor for Modeling and Simulation, in IEEE Trans, On Syst., Man and Cybern., in press, L. Dance and P. A. Fishwick, A Methodology for the 3D Modeling and Visualization of Concurrency Networks, Enabling Technology for Simulation Science within SPIE '01 AeroSense Conference, Orlando, T. Kim and P. A. Fishwick, Virtual Reality Modeling Language Templates for Dynamic Model Construction, Enabling Technology for Simulation Science within SPIE '01 AeroSense Conference, Orlando, X3D Graphics Working Group, Web3D Consortium FAQ, NIST translator, World Wide Web Consortium, B. DuCharme, XML the Annotated Specification, Prentice Hall, M. Didier, M. Birbeck, M. Kay, et al., Professional XML, Wrox Press, Extensible Stylesheet Language (XSL), W3C Style Sheets Activity, XSL Transformations (XSLT), M. Kay, XSLT Programmer's Reference, Wrox Press, XML Path Language, SAXON, Xalan, XT, XML Spy, S. Holzner, Inside XSLT, New Riders, July P. A. Fishwick, rube web page, P. A. Fishwick, Aesthetic Programming, Leonardo, MIT Press (to be published in 2002). 31. R. Donahue, N. Kohareswaran, P. A. Fishwick, Simpack: Getting Started with Simulation Programming in C and C++, Winter Simulation Conference, pages , Arlington, VA., 1992.