A 3D XML-BASED MODELING AND SIMULATION FRAMEWORK FOR DYNAMIC MODELS

Transcription

1 A 3D XML-BASED MODELING AND SIMULATION FRAMEWORK FOR DYNAMIC MODELS By TAEWOO KIM A DISSERTATION PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY UNIVERSITY OF FLORIDA 2002

2 Copyright 2002 by Taewoo Kim

3 To my parents, my wife Mee-Kyoung, and our children Shin-Young and Soh-Young

4 ACKNOWLEDGMENTS I would like to express my deepest gratitude to my advisor, Dr. Paul A. Fishwick, who gave me inspiration and guidance throughout my Ph.D. studies at the University of Florida. I would also like to give my sincere appreciation to my Ph.D. committee members, Dr. Manuel E. Bermudez, Dr. Paul W. Chun, Dr. Douglas D. Dankel, and Dr. Abdelsalam A. Helal, for their precious time and advice for my research. I appreciate all the colleagues in our research group for sharing valuable ideas. I would like to thank Dr. Robert Cubert, John Hopkins, and Linda Dance for their kind help when I tried to settle down in our lab. Special thanks go to Andrea Goethals, Minho Park, and Jinho Lee for their help and companionship. Also, I am grateful to the National Science Foundation, the Air Force Research Laboratory, and the Republic of Korea Army for their financial support for my studies in the United States. I owe great love to my parents, who prayed and encouraged me throughout my studies, and my wife, Mee-Kyoung, my son, Shin-Young and my daughter, Soh-Young, who shared all the wonderful and difficult moments with me here in Gainesville. They are the reason for my existence and I give my deepest love to our God and pray that He will always be with us all and continue to lead our lives. iv

5 TABLE OF CONTENTS page ACKNOWLEDGMENTS... iv LIST OF FIGURES... viii ABSTRACT... xi CHAPTER 1 INTRODUCTION Challenges Contribution to Knowledge Organization of the Dissertation BACKGROUND Modeling and Simulation Dynamic Models Virtual Reality Modeling Language (VRML) Extensible 3D (X3D) Extensible Markup Language (XML) Extensible Stylesheet Language Transformation (XSLT) RELATED WORKS Modeling and Simulation High Level Architecture (HLA) Unified Modeling Language (UML) Mathematical Markup Language (MathML) CellML Modeling Markup Language (MoML) Modelica Web-Ready HiMASS Previous Research Multimodeling Object-Oriented Physical Multimodeling (OOPM) Aesthetic Computing Web-Based Modeling and Simulation v

6 4 XML-BASED RUBE FRAMEWORK Overview Modeling in rube Model Representation Component 1: Scene File Component 2: Model File Model Creation Component 1: Model Fusion Engine Component 2: Graphical User Interface (GUI) Simulation in rube Implemented Simulation Methods Event-Based Scheduling Time-Advanced Mechanism Created Simulation Tools MXL to DXL Translation Engine DXL to JavaScript Translation Engine MODELING: MXL AND MODEL FUSION ENGINE Overview Model Representation in MXL MXL Schema Simple Model Representation Multimodel Representation Model Creation with Model Fusion Engine Model Object Fusion Process XML Document Handling Name Correspondence Model Behavior Blending Process Inserting Behaviors Creating ROUTE statements SIMULATION: HIERARCHICAL STRUCTURE Overview MXL to DXL Translation DXL Schema Translation Process DXL to JavaScript Translation SimPackJ/S Library Translation Process CONCLUSION Summary of Results Future Challenges vi

7 APPENDIX A MXL, DXL SCHEMA...87 MXL SCHEMA (TOP-DOWN) MXL SCHEMA (BOTTOM-UP) DXL SCHEMA B MODELS IN MXL...90 FSM FBM MULTIMODEL C TRANSLATION EXAMPLES: MXL TO DXL, DXL TO JAVASCRIPT FUNCTION FBM STATE FSM MULTIMODEL D SOURCE CODES: MODEL FUSION ENGINE, TRANSLATION ENGINE MODEL FUSION ENGINE MXL TO DXL MODEL TRANSLATION ENGINE E DYNAMIC MODEL EXAMPLES FSM FBM LIST OF REFERENCES BIOGRAPHICAL SKETCH vii

8 LIST OF FIGURES Figure page 2-1. Ways to Study a System Declarative Model Functional Model A rube Architecture for Modeling A rube Architecture for Simulation Semantic Network for the Models Deterministic System D FSM D FSM A Light Bulb A Processing Plant D-FSM for Light bulb Scene.wrl Fluid Pipe Metaphor [Ryan Dnahue] Architecture Metaphor [Koharesvaran Nandhini] A Model File in MXL Graphical User Interface A Diagram for Event Scheduling F2TR FBM in MXL D Diagram for 3F2TR FBM in MXL...47 viii

9 F2TR FBM in DXL D Diagram for 3F2TR FBM in DXL Translated 3F2TR FBM in JavaScript Segment of MXL Schema An FBM with Three Functions and Two Traces in MXL D Diagram for 3F2TR FBM in MXL MXL Schema Model File for FSM with 3 States and 3 Transitions Multimodel File for 3S3T FSM inside the 3F2TR FBM in 2D Diagram Multimodel File for 3S3T FSM inside the 3F2TR FBM in MXL XSLT Code for accessing another XML Document A Fusion Segment of ModelEngine.xsl File <xsl:template> Element XSLT Code for <Transform> Element Created <Transform> Element XSLT Code for <xsl:variable> Element Copied <Transform> Element <behavior> Element Inserting Behavior Created <Script> Element XSLT Code for Blending Behaviors XSLT Code for Blending Behaviors XSLT Code for Blending Behaviors Created <ROUTE> Element Overall Structure of rube Framework for Model Simulation...68 ix

10 6-2. The role of DXL in rube architecture A basic DXL diagram and its elements Segment of DXL Schema An FBM with Three Functions and Two Traces in DXL D Diagram for 3F2TR FBM in DXL An MXL Example of 3F2TR FBM in MXL A Segment of MXL to DXL Translation Engine A Translated FBM in DXL file Tested DXL Files in 2D Block Diagrams D Diagram for a Multimodel in MXL D Diagram for a Multimodel in DXL A Multimodel With FBM and FSM in MXL Multimodel with FBM and FSM in DXL User Defined JavaScript Files for Each Block A Segment of Created JavaScript File for an FBM Output of simulation...82 x

11 Abstract of Dissertation Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Doctor of Philosophy A 3D XML-BASED MODELING AND SIMULATION FRAMEWORK FOR DYNAMIC MODELS By Taewoo Kim May, 2002 Chair: Paul A. Fishwick Department: Computer and Information Science and Engineering Simulation as the process of using a model to gain insight on the behavior of a real world system requires a specific set of skills, 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. Advances in computer technology enable us to work in a 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 data structure and share it with anyone on any other computing platform over the Internet. My primary research goal is to find the most effective way to represent both geometry and dynamic model information using XML. An additional goal is to provide a simulation capability that can simulate the model, which is defined and created with the given XML files. xi

12 We have constructed an XML-based rube framework, a modeling and simulation (M&S) environment, which encompasses the modeling process of a real world system as well as the simulation process of the model. For model representation, a 3D dynamic model has been separated into two parts: a scene file, which contains 3D geometry objects, and a model file, which describes the topology and behavior of the model. Multimodel exchange Language (MXL) has been created with XML Schema to represent the model file which describes a heterogeneous multimodel in an abstract level. For model creation, a Model Fusion Engine has been created, which is an XSLTbased mediation system for reordering and fusing two XML documents: a scene file and a model file. It also blends scripts into the node structure of an XML document to create a dynamic 3D model in X3D. For model simulation, a Model Translation Engine has been created. It translates a model file written in MXL into an assembly level modeling language called Dynamics exchange Language (DXL), which can be described with homogeneous simple block diagrams. It is translated into executable JavaScript codes for the model simulation. A system being modeled can be simulated with input data using SimpackJ/S, which provides simulation capabilities in the rube framework. xii

13 CHAPTER 1 INTRODUCTION As technology advances, the magnitude of data and information that must be catalogued, sorted, presented, and fused grows rapidly. Within the context of the infosphere such as Battle Infosphere [1,2], one of the key problems is fusion, not only of data but also of model information. The infosphere is often presented as a vast, crossconnected mass of information emanating from sensors, weapons, and military units. The task of integrating such a mass of information effectively is a key research problem in many other areas. Our task is to leverage Extensible Markup Language (XML) technology to help solve the model fusion problem, where models of different sorts must be inter-connected. Three types of models, information, dynamic and geometric, are common in most applications. We have designed the existing rube research framework to fuse geometry and dynamic model information. 1.1 Challenges As the Web becomes a ubiquitous tool and environment for sharing information, the need for a standard dynamic model specification language for the web increases. It should enable us to separate the content of models from its presentation and thus facilitate the sharing of dynamic models over the Internet. The objectives of this research are: to create and implement a methodology, based on XML technology [3-5]; to define a model in an effective way; and to fuse defined 1

14 2 model information together in a way that supports reuse, sharing of information, and modular distribution of models. This research will address the following two main issues: 1) What is the most effective way to represent both geometry and dynamic model information using XML?; and 2) How do we encode the fusion process into the mediator in such a way that is scalable, easy to understand, and easily modifiable? We investigate the applicability of XSLT [4] and stylesheets as the internal processor for this fusion step. 1.2 Contribution to Knowledge Separation of Geometry from Semantic Relations of a Model One of the major contributions of XML-based rube modeling architecture [6-8], 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. The model file written in MXL captures all the information about the model: the topology that defines the connectivity of the model type and its behavior. This provides an effective way to represent both geometry and dynamic model information using XML Provide an Efficient Representation for Dynamic Model Types in XML Much of the work has been done in representing dynamic model types [9] in VRML [10-12]. Since the future of VRML is X3D [9] and since X3D is in XML, it is natural to focus on XML as the basis for model translation and integration. We have developed a model specification language, called Multimodel exchange Language (MXL), which is an XML-based representation that enables web-based modeling and simulation [13,14].

15 M&S Environment Which Incorporates Aesthetics and Personalization XML-based rube architecture provides an environment where model authors can maximize their own aesthetic creativity in creating a model. Each object can be crafted to the extent that the model author is fully satisfied with its aesthetic appearance. Furthermore, the model author can personalize the process of simulating the created model Provide Web-based M&S Environment XML-based rube architecture provides a web-based modeling and simulation framework [7,13], where model authors can simulate a dynamic model as well as define and create it on the Internet. Simulation is achieved by translating a model file described in section 1.2.1, which contains heterogeneous dynamic model types, into homogeneous block diagram, which is translated into JavaScript codes for the execution. 1.3 Organization of the Dissertation Technologies related to this research are addressed in Chapter 2. In Chapter 3, some of the related works in the modeling and simulation area and our previous research efforts are discussed. In Chapter 4, the XML-based rube architecture is presented focused on model representation, model creation, and model execution. In Chapter 5, the modeling part of rube, focusing on the implementation of the Model Fusion Engine, is discussed in detail. Chapter 6 addresses the simulation part of rube as the hierarchical structure of model simulation from high-level abstraction to the implementation level. Conclusion and future challenges are discussed in Chapter 7.

16 CHAPTER 2 BACKGROUND 2.1 Modeling and Simulation Simulation is the use of a model to derive conclusions that provide insight on the behavior of any real world systems. Computer simulation uses the same concept but requires that the model be created through programming on a computer. 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 shaped into a model [15]. This model can then be manipulated to help the simulation analyst gain an understanding of the dynamics at work in the system. A system is defined as a collection of entities, e.g., people or machines that act and interact together toward the accomplishment of some logical end [16]. 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 arises a need to study them in order to gain some insight into the relationships among various components, or to predict performance under some new conditions being considered. Different ways in which a system might be studied are shown in Figure 2-1 [17]. For economical and other 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. 4

17 5 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 obtain 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. System Experiment with the actual system Experiment with a model of the System Physical Model Mathematical Model Analytical Solution Simulation Figure 2-1. Ways to Study a System 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 and the most vital to the success of simulation [18]. 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 in

18 6 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 [19]. 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 [9]. 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 objects 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 Internet. 2.2 Dynamic Models Before we discuss specific modeling methods and start modeling dynamic behaviors of an object, let us overview a unifying formalism that serves to represent a wide variety of system models. A deterministic system <T, U, Y, Q,,, > within classical systems theory is defined as follows [9]: T is the time set. For continuous systems, T = R (reals), and for discrete time systems, T = Z (integers). U is the input set containing the possible values of the input to the system. Y is the output set. Q is the state set. is the set of admissible (or acceptable) input functions. This contains a set of input functions to use during system operation. Often, due to physical limitations, is a subset of the set of all possible input functions (T U).

19 7 is the transition function. It is defined as : Q x T x T x Q. is the output function, : Q Y. A pair consists of a time and a state (t, s), where s Q is called an event. Events are points in event space just as states are points in state space. Event space is defined as T x Q. State and Event are critical aspects of any system and by focusing on one or the other, we form two different sorts of models: declarative models that focus on the concept of state, and functional models that focus on the concept of event. In declarative modeling, as shown in Figure 2-2, in 2D diagram, we build models that focus on state representations and state-to-state transitions. In functional modeling as shown in Figure 2-3, we focus on the system as a coupled network of functions each of which takes inputs and produces outputs. U S1/Y1 U1 Y U Y1 Y2 f1 f2 S3/Y3 U3 U2 S2/Y2 f3 Y3 Figure 2-2. Declarative Model Figure 2-3. Functional Model The declarative modeling approach suggests that we look at the world through a sequence of changes in state and it is very good for modeling problem domains where the problem decomposes into discrete temporal phases. Finite State Automata (FSA) permit us to model systems with a minimum of components. An FSA is a system with states and transitions. A state, depicted as a circle, represents the current condition of a system for some length of time, and transitions, depicted as arrows, enable the system

20 8 to move from one state to another during the simulation. The basic definition of system <T, U, Y, Q,,, > provides the semantics for declarative models as described above for the deterministic system. Functional models map very easily into the OO paradigm since a function is represented as a method located within an object, and it is often used to model continuous systems and discrete event systems composed of coupled functional blocks. These functional models are also useful when the problem is given in terms of distinct physical objects which are connected in a directed order or the problem involves a material flow throughout the system. Function-based models contain a transfer function which relates input to output. The functions, along with inputs and outputs, are often depicted in a block form, especially when a block is the iconic representation of physical device being modeled. 2.3 Virtual Reality Modeling Language (VRML) VRML, which is an abbreviation for Virtual Reality Modeling Language, represents the standard 3D language for the web [20]. 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. Also, VRML 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

21 9 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 a 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 Internet make VRML a robust tool for our rube Methodology. Since 1998, Fishwick [21] and his research team have developed a 3D modeling paradigm called rube [6-8,10-12]. The key task was to derive a methodology for constructing various dynamic models [8] 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 [22,23]. 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-12]. These templates have been provided through the Internet as the building blocks for creating dynamic models which incorporate personal aesthetics of individual modelers. These simple examples of model templates serve as

22 10 tutorial guidelines on building behavioral structures in VRML and on how more complex dynamic model buildings can be accomplished. 2.4 Extensible 3D(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 [24]. 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 2001 [25]: 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 standards. 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

23 11 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 [26]. In our proposed rube framework, 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.5 Extensible Markup Language (XML) XML stands for "extensible Markup Language." It is a new markup language developed by the World Wide Web Consortium (W3C) [27] 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 [28]. 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 one could use one s 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 one s 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

24 12 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 [29]. 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 Transformations (XSLT). Initially, we have 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 has 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 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

25 13 Language (XSL). The transformation language we have used to create our Model Fusion Engine is called XSL Transformations (XSLT). 2.6 Extensible Stylesheet Language Transformation (XSLT) The Extensible Stylesheet Language (XSL) [30], which was developed as a part of the W3C Style Sheets Activity [31], 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" [4]. The XSLT specification became a recommendation in 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 [32]. 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 [33], which became a recommendation on the same day as the 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 stand-alone XSLT processors such as SAXON [34], Xalan [35], and XT [36]. We have developed the Model Fusion Engine with XML Spy [37], which is an Integrated

26 14 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 [38]. By implementing XML-based technologies discussed above, we have constructed 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.

27 CHAPTER 3 RELATED WORKS This chapter discusses related research work in the Modeling and Simulation (M&S) domain as well as previous and recent research efforts for our rube project. Many works, including the High Level Architecture (HLA) by the Department of Defense (DoD), have been done to provide frameworks and tools that enables us to define, create, and simulate models while sharing them among the users. Our previous researches, such as Object-Oriented Physical Multimodeling (OOPM), are introduced along with recent research efforts made by members of the Simulation Group in the Computer and Information Science and Engineering (CISE) Department at University of Florida are described in the second part of this chapter High Level Architecture (HLA) 3.1 Modeling and Simulation HLA for M&S was created by DoD in order to establish a technical framework which facilitates the interoperability of all types of models and simulations among each other and with Command, Control, Communications, Computers, and Intelligence, Surveillance and Reconnaissance (C4ISR) systems. It provides significant benefits to the modeling and simulation community in terms of increased software reusability, reduction in overall development and maintenance costs, and the ability to link live players and operational systems with simulations [39]. HLA vision is to construct M&S environments through affordable, reusable components interoperating through an open systems architecture [40]. While there has 15

28 16 been much attention paid to M&S as it relates to specific application areas, little has been done to address those broad technology areas that enhance, and in some cases, revolutionize the way we configure, execute and analyze the results of simulations. HLA for M&S research objectives include: Ensuring HLA compliance of legacy models/simulations; Development of HLA-compliant visualizers; Design and implementation of Simulation Object Models (SOMs)/Federation Object Models (FOMs). In order to achieve the M&S research objectives, modeling methodology research objectives of HLA include the following: Evaluation, exploitation and development of techniques to reduce the complexity of existing high-resolution models and simulations. Assessment of alternative approaches to solving the problem of Mixed Resolution Modeling. Investigation of new and emerging simulation paradigms as they relate to providing accurate, real-time decision support. The Collaboration, Simulation and Visualization promote the development of the processes and tools necessary to enable dominant battle space awareness and information superiority. Activities include infrastructure support for collaborative decision making, warfare assessment, and battlefield data fusion. Military mission planning and execution requires the ability to spontaneously extract and merge information from multiple data sources. Events, activities and movements must be correlated and analyzed as they occur in time and space, to determine the location, identity and status of individual objects. Specific technologies are required to refine, direct and manage the information fusion capabilities. The ability to communicate by moving raw and processed information throughout a global communications grid is fundamental to Command & Control.

29 17 Inherent in this capability is the idea of universal information availability across different transmission media with different characteristics. The rube framework has much in common with HLA in a sense that both try to develop data standards to support common representations of data across models and simulations. The former has a Multimodel exchange Language (MXL) while the latter provides an Object Model Template (OMT) for defining models. Data standards are being developed to support common representations of data across models and simulations. HLA OMT has several Data Interchange Formats (DIFs), to allow models and simulations to communicate. The primary difference between rube and HLA is the representation of model semantics. HLA provides the Modeling and Simulation Resource Repository (MSRR), which supports model reuse, and the runtime infrastructure (RTI), which supports execution of a federation of simulations. HLA Federation Development and Execution Process (FEDEP) is based on a waterfall model for analysis and design which was essentially a database which did not really capture the model semantics. Whereas in rube, the semantics of a model is described in a model file written in MXL, an abstract highlevel language Unified Modeling Language (UML) The Unified Modeling Language (UML) [41-43] was developed jointly by Grady Booch, Ivar Jacobson, and Jim Rumbaugh at Rational Software Corporation, with contributions from other leading methodologists, software vendors, and many users. Based on extensive use of the Booch, OMT, and Jacobson methods, UML is the evolution of these and other approaches to business process, object, and component modeling. UML provides the application modeling language for the following:

30 18 Business process modeling with use cases. Class and object modeling. Component modeling. Distribution and deployment modeling. UML uses several 2D diagrams, such as State Diagrams, Sequence Diagrams, and Activity Diagrams, to capture and present multiple views of a system, which we call it a model. For example, the State Diagram presents the states an object can be in along with the transitions betweeen the state, the Sequence Diagrams shows how objects communicate with one another over time, and the Activity Diagram provides a simplified look at what happens during an operation or a process. UML models dynamics through one type of model contrasted with the heterogeneity and multimodeling which are central to rube. UML does not concern itself with simulation nor with automatic correct transformation from model to simulation program. Though UML is not intended to model continuous systems such as those found in engineering and physics, it is a very useful tool for exchanging models across many different domains. We view UML as a model represetation framework which uses 2D diagrams to model a system but has limited capabilities in modeling the dynamics of the system Mathematical Markup Language (MathML) There have been many attempts to incorporate XML-based technology in several domains, such as MathML and CellML. These works have been dedicated to each specific application domain and no similar work has been done in Modeling and Simulation area.

31 19 MathML [44] is intended to facilitate the use and re-use of mathematical and scientific content on the Web and for applications such as computer algebra systems, print typesetting, and voice synthesis. MathML can be used to encode both the presentation of mathematical notation for high-quality visual display, and mathematical content, for applications where the semantics plays more of a key role such as scientific software or voice synthesis. MathML is cast as an application of XML [45]. As such, with adequate style sheet support, it will ultimately be possible for browsers to natively render mathematical expressions. For the immediate future, several vendors offer applets and plug-ins which can render MathML in place in a browser. Currently, MathML is used to represent logical statements or traditional mathematical expressions but few efforts have been made in executing those expressions to get a result by translating it into other programming languages, such as JavaScript. We view MathML as another representation of core model content. Our rube project envisions sharing and executing model contents among different domains and this research provides a framework for such tasks. By using MXL as a model interchange language, rube can serve as a tool to bridge the gap between two different domains CellML CellML language [46] is an XML-based markup language being developed by Physiome Sciences Inc. in conjunction with the Bioengineering Research Group at the University of Auckland's Department of Engineering Science and affiliated research groups. The purpose of CellML is to store and exchange computer-based biological models. CellML allows scientists to share models even if they are using different model-

32 20 building software. It also enables them to reuse components from one model in another, thus accelerating model building. CellML includes information about model structure (how the parts of a model are organizationally related to one another), mathematics (equations describing the underlying biological processes) and metadata (additional information about the model that allows scientists to search for specific models or model components in a database or other repository). CellML includes mathematics and metadata by leveraging existing languages, including MathML and RDF. In the future, CellML may also use other existing languages, such as MXL, to specify data and define simulation and rendering information Modeling Markup Language (MoML) MoML is an XML modeling markup language. It is intended for specifying interconnections of parameterized, hierarchical components. MoML is extensible in that components and their interconnections can be decorated with data specified in some other language. The key observation in the design of MoML is that the most important decision for such a language is the abstract syntax supported by the language, not the concrete syntax [47]. MoML tool has been constructed using Ptolemy II [48]. A model is given as a clustered graph, an abstract syntax for netlists, state transition diagrams, block diagrams, etc. and MoML uses a set of XML elements that specify a clustered graph as a model definition. Clusters are entities that can contain a topology which is entities and realtions. In MoML, a topology is a collection of entities, ports, and relations. Entities contain ports and relations connect the ports.

33 21 MoML is an XML-based block model for PtolemyII similar to the DXL for our rube framework. It is XML-based which means it is integrated in a web environment. It is also a functional block model and supports multimodeling concept. The main differences are as follows: MoML focuses on an embedded system whereas rube provides generalized system dynamics; mainly, MoML supports 2D and partially, 3D (Java 3D), whereas rube fully supports 3D (X3D), the block diagram of MoMl is a general functional block where each block is more complex than the simple block of DXL in rube; MoML supports Java language for simulation, whereas rube supports Java and JavaScript for simulation; Ptolemy uses its own standalone tools and only MoML is implemented in XML, whereas in rube, everything is fully XML-based Modelica Modelica is an object-oriented language for modeling of large, complex and heterogeneous physical systems [49]. General equations are used for modeling of the physical phenomena. Modelica supports both high level modeling by composition diagrams and detailed library component modeling by equations. The topology of the system is specified by a composite model in terms of components and connections between the components. In order to support hierarchical modeling, a component model may be a composite model. Perhaps Modelica has more common features with rube framework than other modeling languages described previously in this chapter in the sense that it supports hierarchical modeling and has the ability to represent the topology in a high-level abstraction as well as detailed model execution by using equations for modeling of the physical phenomena. But the major difference is that Modelica is not an XML-based language, which means unless it becomes the standard language for modeling and

34 22 simulation, the ability to reuse and exchange models will be restricted by the language itself. Modelica is suited for multi-domain modeling, for example for modeling of mechatronics including cars, aircraft and industrial robots which typically consist of mechanical, electrical and hydraulic subsystems as well as control systems, whereas rube framework is trying to serve as a general M&S environment that can encompass both abstract concepts as well as physical phenomena Web-Ready HiMASS The Hierarchical Modeling and Simulation System (HiMASS)-x is an XMLcentered suite of software application that allows for cross-platform, distributed modeling and execution of hierarchical, componentized, and reusable simulation [50]. A previous prototype was called HiMASS-j which was completely implemented in Java [51]. HiMASS-x has two sub-applications called HiMASS Modeler, which is a graphical user interface, and HiMASS Engine, which provides implementation of simulation algorithms for the Hierarchical Control Flow Graph (HCFG) Model paradigm [52]. In an HCFG Model, the model Components and their interconnections are specified via a Hierarchical Interconnection Graph (HIG). A HIG allows a modeler to specify model Components hierarchically by coupling the existing model Components to form new model Components. HiMASS and rube have similar concept of partitioning models into hierarchical subcomponents. For model execution, HiMASS generate Java source code whereas rube generates JavaScript code for model simulation. Both support the Experimental Frame (EF) concept [53]. The main difference between the two would be the use of XML in each M&S framework. In HiMASS, HCFG model specifications contain arbitrary code to specify the behavior of edge conditions and event routines. In rube, only the file name,

35 23 which contains each function for node and edge, is specified in a model specification file. We view HiMASS as a comrade in arms with rube to achieve a new paradigm of modeling and simulation in XML environment. 3.2 Previous Research This section reviews some of the previous and recent works conducted by the Simulation Group in Computer and Information Science and Engineering Department at the University of Florida Multimodeling In 1991, Fishwick [55] initiated research on multimodeling, which is the process of engineering a model by combining different model types to form an abstraction network or hierarchy. Multimodeling, in a nutshell, endows the simulationist with the capability to blend different model types together to form hybrid models. When we begin to understand a physical system by creating a model, we often find that the model is too limited: the model will answer only a very limited set of questions about system behavior. It is necessary, then, to create many models and link them together, thereby maintaining a multi-level view of a system while permitting an analyst to observe system output at several abstraction levels. The multimodel approach uses SimPack [56] tools depending on the model types present in the abstraction hierarchy. SimPack is a collection of C and C++ libraries and executable programs for computer simulation. In this collection, several different simulation algorithms are supported including discrete event simulation, continuous simulation and multimodel simulation. The purpose of the SimPack toolkit is to provide the user with a set of utilities that illustrates the basics of building a working simulation from a model description.

36 24 Fishwick provided a set of C and C++ tools that accommodates a direct translation from graph-based modeling approaches into callable routines: the user is not forced to think in terms of a single overall language for all simulation applications. Instead, most systems contain model components whose types are different. The perceived need to have an all in one simulation language does not match most real world problems where a set of well-tested model types has developed naturally. The SimPack emphasis on diversity in modeling makes it a natural candidate in which to construct multimodels. Our current research is closely related to the multimodeling concept which permits one to create large, structured models with many levels of abstraction. The SimPack has been converted to the SimPack J/S to support an XML-based rube framework which enables the modeling and simulation of 3D dynamic models in the web environment Object-Oriented Physical Multimodeling (OOPM) In 1996, Fishwick [57] introduced the Object-Oriented Physical Multimodeling (OOPM) concept where the word multimodeling used in OOPM refers to heterogeneous behavior multimodels described above in section OOPM represents an expansion of object oriented design as found in Booch s notation and Rumbaugh s OMT notation. OOPM focuses on an architecture and representation for digital object reuse, supporting facile correct combination of digital objects represented as heterogeneous multimodels [58]. The research goal in OOPM was to design an object oriented methodology for physical modeling including both dynamic models and geometric models. Most existing OO designs are meant to apply to software in general, but the OOPM specifically

37 25 addresses the design of physical objects and their scenarios. Multimodel Object Oriented Simulation Environment (MOOSE) and the SimPack Simulation Toolkit form the implementation of OOPM. MOOSE is an application framework for modeling and simulation based on OOPM. OOPM extends object oriented program design with visualization and a definition of system modeling that reinforces the relation of model to program. OOPM is a natural mechanism for modeling large-scale systems, and provides output visualization. Distributed Model Repository (DMR) facilitates collaborative and distributed model definitions and model reuse. Translator converts model definition to a simulation program in C++, then compiles and links this simulation program, adding runtime support, and creating an executable which runs under control of Scenario to provide output visualization using VRML. Heterogeneous multimodeling is the basis for geometry and especially dynamic behavior models, including Finite State Machine (FSM), Functional Block Model (FBM), Equation Constraint model (EQN), Rule-based Model (RBM), and System Dynamics (SD) models. Underlying multimodeling is Block as fundamental object and every model is built from blocks. We consider the OOPM as the predecessor of our XML-based rube framework where one can model and simulate dynamic model types based on the definition of the model. But the primary differences are the model representation and the tools used to implement the modeling and simulation environment. In rube framework, model contents are separated from model presentation. Also in rube, heterogeneous model types are

38 26 translated into homogeneous block language, called DXL, during the model simulation process Aesthetic Computing The study of aesthetic models [59] in the representation of computer programs represents a small potential when compared with the more encompassing subject area of computer science. Models are used frequently in most sub-areas: databases, machine organization and architecture, data and program structures, and artificial intelligence. These areas will all benefit from direct artistic influence. The same approach to aestheticism can be applied to other art forms, such as storytelling and theater. Stories can be mapped onto model structures and serve to entertain as well as to educate and remind us about the target system. Our implementation on models for aesthetic computing promotes a more enjoyable modeling process. Only recently have computer scientists been able to economically create 2D and 3D graphical user interfaces. Even now, there are too few tools as compared with text editors. Two-dimensional graphics, while popular and accessible, is still somewhat of a struggle as compared with text. Some toolkits exist such as Java Swing and Tcl/Tk, but more are needed. Economy, therefore, drives programmers and computer science in general toward text for model representation. The VRML standard, bringing along with it easier methods for representing and sharing 3D, is barely three years old. Economy, however, is not the only hurdle to jump. As programming was originally born out of mathematical representation, programmers tend to be culturally minimalist in matters of representation. The new economy of 3D, including game console capabilities and prices, is bound to alter this culture, but it may take considerable time.

39 Web-Based Modeling and Simulation The integration of the web with the field of simulation should provide lots of ideas for how simulation is to change. With the web being the driver of much of today s software technologies, simulationists need to study how we can embed simulation documents in browsers and how new distributed web-based simulations are to be designed. Our recent research on the web-based modeling and simulation is to promote the publication and standardization of digital objects stored on the web to enable model and object reuse. A digital object is an electronic representation of a physical object, including models of the object. There remain many challenges and issues regarding the representation and utilization of these objects, since it is not clear, for example, who will create certain objects, who will maintain the objects, and what level of abstraction will be used in each object. The methodology, OOPM, defines a formal approach to constructing both natural and artificial systems using an extension of the classical object-oriented framework as defined software engineering and programming language design. The extension is one where class attributes and methods can take on models as values. The end result of OOPM design is a model repository, which is integrated with the web and made available to others on the Internet so that models can be constructed in a plug and play fashion. The World Wide Web represents a fertile area in which to perform computer simulation research. It only makes common sense to imagine that by combining the web with computer simulation, that the simulation community can achieve an integration that will have a key impact on future simulation research. We focus on the distributed model repositories since there has been less research in this area than in the more mature field of

40 28 distributed simulation. Also, the concept of model repository lends itself to the study of how to organize model information. Since the web is also concerned with how to organize information effectively, this appears to be a reasonable way to blend the web with simulation. The web defines a networked hypermedia approach to storing information. Search engines exist to help a user browse or perform a topical search. In simulation, information is generally focused on physical objects. These physical objects, whether they are humans, milling machines or a container of fluid, have attributes and exhibit behaviors. If we are to permit a situation where physical object information is as freely available as hypermedia to remote users on today s web, then we need to 1) formalize this information, 2) provide a way to integrate to today s web-based information, and 3) effective mechanisms for searching and browsing models. Current research focuses on the XML-based technologies to achieve these goals. The XML-based rube framework defines a formal approach to capture physical knowledge as well as the semantic information of the model and represent the information as separate XML documents. Our purpose is to allow users a way to represent and to create dynamic models with these XML document. Just as the web search engines currently index text and multimedia objects, we envision that search engines can be built to index models by their functions, semantic information or some other characteristic.

41 CHAPTER 4 XML-BASED RUBE FRAMEWORK In this Chapter, we first discuss the overall structure of the XML-based rube framework with an example. Following sub-sections focuses on model representation, model creation, and model simulation. XML-based rube framework encompasses modeling as well as simulation of a dynamic model. After presenting an overview of rube framework, modeling in rube will be discussed in Section 4.2 which includes model representation and model creation. Simulation methods used in rube and the translation tools created for model simulation are discussed in Section Overview A simplified overall structure of the XML-based rube framework is shown in Figure 4-1 along with a figure showing the sub-components of the Model Fusion Engine. Model representation is achieved by decomposing a dynamic model into a scene file in X3D and a model file written in MXL. A final 3D dynamic model is created by the Model Fusion Engine, written in XSLT and DOM to support our rube framework. Figure 4-1. An Overall Structure of XML-based rube Framework 29

42 30 Model simulation is done by translating a model file written in MXL, which contains abstract level heterogeneous semantic information of a multimodel, into an assembly level modeling language, called DXL, and finally translate it into executable JavaScript codes for execution. An overall structure of the XML-based rube framework for modeling is shown in Figure 4-2, from a modeler's point of view, along with pointers to the sub-sections covering that part. This view depicts the components for model representation and model creation. It includes a scene file and a model file for the model representation, and the Model Fusion Engine and a graphical user interface (GUI) for the model creation. Digital Object Warehouse VRML create 3D Modeler reuse Model Author Dynamic Model Repository XML create Text Editor VRML scene VRML model XML Scene File (Sec ) VRML Graphical User Interface (Sec ) XML Model File (Sec ) VRML VRML XML NIST Translator X3D X3D XML Model Fusion Engine (Sec ) Figure 4-2. A rube Architecture for Modeling 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 a model file, which contains information about relations and behaviors of the model. Since there is no working X3D browser, NIST translator has been used to

43 31 translate files between VRML and X3D. 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 supports the merging and restructuring of XML-based input documents representing the scene and the model as described above. The Model Fusion Engine also handles the fusion process that includes 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 geometry scene information as well as the corresponding models and their behavior. The Model Fusion Engine is an XSLT-based fusion mediator. XSLT is XMLbased, 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 relation and behavior specified in the model file. Currently, a Finite State Machine (FSM) and Functional Block Model (FBM) are defined in MXL and incorporated into the Model Fusion Engine. Other model types, such as Petri Net (P-Net) [5], are being developed. 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. The graphical user interface (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

44 32 connectivity and behavior of the model type. A model author specifies scene and model file using the GUI, which translate the two files and activate the Model Fusion Engine to create a 3D dynamic model. Another view of the XML-based rube framework is shown in Figure 4-3. This view depicts the components for model execution. It focuses on the translation and auto code generation from the conceptual model in MXL to the executable code in JavaScript. Scene File (Sec. 4.2) MXL (Sec. 4.2) MXL to DXL Translator (Sec. 4.3) DXL (Sec. 6.2) SimPackJ/S (Sec. 6.3) DXL to J/S Translator (Sec. 4.3) Javascript (Sec. 4.3) Model Fusion Engine (XSLT) (Sec. 4.3, 4.4) Figure 4-3. A rube Architecture for Simulation A model file written in MXL, which contains heterogeneous dynamic model types, is translated into DXL, which is homogeneous assembly level block diagram language. Executable JavaScript codes are produced by combining the file in DXL with the SimPack J/S libraries. These executable codes are fed into the Model Fusion Engine and final 3D dynamic model is created in X3D file.

45 Modeling in rube Model Representation When we model a real world object, we can use different model types depending on the purposes. For example, when we want to model a light bulb, we can use a scale model to show what it looks like or use a dynamic model, such as a Finite State Machine (FSM), to represent its dynamic behavior. The FSM can be represented in many ways according to the style and preference of a modeler as shown in Figure 4-4. Figure 4-4. Semantic Network for the Models In order to model the dynamic behavior, in this case the state changes, of the real world light bulb, we need to define the possible states and use a tool that can represent the model. We will define three states. Starting state is 'off-unplugged' and when plugged, the next state becomes 'off-plugged'. When chain is pulled, the state becomes 'onplugged' and the current state toggles between the last two states as chain is pulled again.

46 34 Some of us are well-trained to use a set of symbols to define such a deterministic system and can use a set of symbols depicted in Figure 4-5 to represent the semantics of declarative models as discussed in section 2.2. <T, U, Y, Q,,, > Figure 4-5. Deterministic System Others may want to represent the same content by using 2D diagrams, which contain circles and arcs as shown in Figure 4-6. The Unified Modeling Language (UML) is an example of 2D diagram-based modeling tool that is widely used to model real world systems as discussed in section S1 S3 S2 Figure D FSM Recent advances in computer technologies enable us to use 3D objects to represent the same content in a virtual reality environment and share it over the Internet [10-12]. A modeler can use primitive solid objects or other objects, such as tanks and architectures that are more intuitive and aesthetically pleasing to the modeler as shown in Figure 4-7.

47 35 Figure D FSM Even though the same dynamic model can be represented in many different ways, the topology of the model never changes. We want to capture this core content of a dynamic model as well as the appearance and represent it in a way that the modelers can share them more effectively over the Internet Component 1: Scene File A Scene file contains information regarding the appearance of the system that defines how the system should look. Scene files can be obtained from the Digital Object Warehouse as depicted in Figure 4-2 or can be created from scratch by using a 3D authoring tool such as Cosmo Worlds or 3D Studio MAX. The first scene file, a light bulb, is shown in Figure 4-8. This scene file is used to represent the scale model of the real world light bulb. The light bulb is connected to a plug that supplies power, and a chain that turns the light on and off.

48 36 Figure 4-8. A Light Bulb The second scene file is shown in Figure 4-9. Even though somewhat more minimal in structure, we can give a meaning to each object and this is meant to be a fluid processing plant with red tanks and green pipes. on plugged off unplugged pull chain pull chain apply power off plugged Figure 4-9. A Processing Plant Figure D-FSM for Light bulb The modeling operation is one where one object is said to capture the essence of another. For our purposes, we use the processing plant to model the dynamics of the light bulb. We achieve this mapping by stating that the plant plays the role of an FSM with three states and three transitions. A 2D diagram of the FSM is depicted in Figure We use the Virtual Reality Modeling Language (VRML) and the Extensible 3D (X3D) file format to represent a scene file. A scene file contains nodes, which describe objects and their properties. It contains hierarchically grouped geometry that represents

49 37 the 3D structure of a model to be constructed. The source code of a VRML scene file, scene.wrl (capturing the role playing semantics of Figure 4-9), is shown in Figure #VRML V2.0 utf8 DEF S1 Transform { translation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Sphere {} } } DEF S2 Transform { translation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Sphere {} } } DEF S3 Transform { translation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Sphere {} } } DEF T12 Transform { children [ Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cylinder { radius 0.25 height 1 } } } Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cone { bottomradius 0.45 height 1 } } } ] } DEF T23 Transform { children [ Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cylinder { radius 0.25 height 1 } } } Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cone { bottomradius 0.45 height 1 } } } ] } DEF T32 Transform { children [ Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cone { bottomradius 0.45 height 1 } } } Transform { translation rotation children Shape { appearance Appearance { material Material { diffusecolor } } geometry Cylinder { radius 0.25 height 1 } } } ] } Figure Scene.wrl 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 and use it as a scene file. Since the Model Fusion Engine works on XML files, the model author should export the scene into a VRML file. The VRML scene file is automatically translated into an X3D file using the NIST translator during the model generating process. 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 as shown in Figure 4-

50 38 14, 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, such as S1, S2, and T12, that will correspond to the id attribute value of each element in the model file. Naming is important when merging two different files, which describe the same model in two different ways. The Model Fusion Engine will copy each node in the scene file according to the same names specified in the model file. This architecture allows a model author to either create new 3D objects or reuse existing digital objects from "model 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 [8,42] as shown in Figure 4-12 [43] and Figure 4-13 [44]. Both figures represent different metaphorical styles impressed upon the same scene file used in Figure 4-9. Figure Fluid Pipe Metaphor [Ryan Donahue]

51 39 Figure Architecture Metaphor [Koharesvaran Nandhini] Component 2: Model File A model file is written in Multimodel exchange Language (MXL), which defines the topology and behavior of the model type. The model file is composed of two subcomponents: model and simulation element as shown in Figure <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <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="pulsate"> </behavior> </model> <simulation type= FSM > <program name= fsmmain.js ></program> <simtime duration= 120 ></simtime> <inputdata type= RANDOMGENERATOR ></inputdata> </simulation> </MXL> Figure A Model File in MXL

52 40 Model contains topology and behavior as sub-elements. topology defines the connectivity of the model and behavior describes the type of animation that signifies the current state. 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. edge also has begin and end attributes denoting the start and the end state of each transition. Each node and edge element can contain a script element, which defines the name of JavaScript file and the function to be executed. The model author can assign unique names to each node and edge, but it is important that the names given here, such as S1 and S2, 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. 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 further sub-divided into X, Y and 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 the user specified in the model file.

53 41 simulation, along with the model element described above, comprises the whole MXL file. rube supports the Experimental Frame concept [53] for the specification of a model s experimental conditions, including information about simulating the real world system being modeled with input data provided by either random generator or predefined input data set stored locally. simulation 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 [37], 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. simtime defines the duration of the simulation and inputdata specifies the input source to be used for the simulation. 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. 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.

54 Model Creation The Model Fusion Engine creates a final 3D dynamic model with two XML input files, the scene and model files described in section and There are two important processes in the model creation process, model fusion and behavior blending processes which are described in detail with example codes written in XSLT Component 1: Model Fusion Engine The Model Fusion Engine plays a central role in the 3D dynamic model creation process within rube. It is written in XSLT, which is a language that used to transform XML documents into other XML documents. It consists of a sequence of template rules, each of which describes how a particular element type or other construct should be processed. The Model Fusion Engine also employs the XML Path Language (XPath) as a way of selecting the area of the document to transform. The Model Fusion Engine is developed in XML Spy [33], which is an Integrated Development Environment for XSLT. In order for our Model Fusion Engine 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, the Engine accepts a source tree as input, and produces a result tree as output. The Engine uses a model file as the base file to work with and accesses a scene file and other JavaScript files as it creates the skeleton of the model from the scene file and adds necessary functions to those objects in the model to be executed. There are two processes in the Model Engine: the fusion and the blending processes. In the fusion process, two XML documents are fused into another XML document. In the blending process, behavior is blended into node structures of a newly created XML document as a script node.

55 Component 2: Graphical User Interface (GUI) Since there is no available X3D browser, all the created scene files in VRML must be translated into X3D files in order to be processed by the Model Fusion Engine. To expedite the model creation process, a simple user interface is created and provided on the web [45] as shown in Figure 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 the newly created 3D dynamic model is displayed with a VRML browser such as Blaxxun Contact, Parallel Graphics' Cortona, or Cosmo Player. This section displays newly created 3D dynamic model with a VRML browser. This section accepts user-defined scene and model files. Figure Graphical User Interface

56 44 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 [21] and fed into 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 a VRML file and displayed in a VRML browser as shown above. 4.3 Simulation in rube In this section, the model simulation part in the rube framework is discussed. Implemented simulation methods and created simulation tools for model execution are briefly described. In order to provide simulation capabilities, a collection of tools for computer simulation, called SimPack, was created by Fishwick [22] in Originally, SimPack was developed in C and C++ and now, it is converted into JavaScript, which is called SimPack J/S, and is being implemented within the XML-based rube architecture. Simulation methods implemented in SimPack J/S includes event-based scheduling. Modeling Languages, such as MXL and DXL, are created to represent a model in different abstract levels. In order to simulate a model in rube framework, a model file which is defined in MXL must be translated into DXL and then into JavaScript codes to be executed in a web browser.

57 45 Also, two translation engines are created that translate a model file written in MXL into DXL and DXL into JavaScript codes to be executed on the Web Implemented Simulation Methods The purpose of SimPack is to provide modelers with a discrete event simulation library and simulation methods implemented in SimPack J/S are event-based scheduling and time-advanced mechanism Event-Based Scheduling An event scheduling is defined as "executing code that contains an event loop where events are posted and then checked according to minimum time" [9]. An event scheduling implemented in SimPack J/S can be depicted as Figure 4-16 [60]. Future Event List next_event Schedule new events Block 1 Block 2 Block 3 Block n Yields new New event New event Figure A Diagram for Event Scheduling All the events are scheduled into the Future Event List (FEL) with the schedule() function and executed as an event which has the smallest time on the FEL becomes next event by the next_event() function provided in SimPack J/S toolkit. The event-based scheduling is also implemented when a DXL file is translated into JavaScript codes for execution.

58 Time-Advanced Mechanism Due to the dynamic nature of discrete-event simulation models, we must keep track of the current value of simulated time as the simulation proceeds, and we also need a mechanism to advance simulated time from one value to another. The variable in a simulation model that gives the current value of simulated time is called the simulation clock. There are two principal approaches for advancing the simulation clock: next-event time advance and fixed-increment time advance. In rube framework, the next-event time advance approach is implemented. With this approach, the simulation clock is initialized to zero and the times of occurrence of future events are determined. The simulation clock is then advanced to the time of occurrence of the most imminent of these future events, at which point the state of the system is updated to account for the fact that an event has occurred, and the values of the times of occurrence in the FEL is also updated. Then the simulation clock is advanced to the time of the most imminent event. This process of advancing the simulation clock from one event time to another is continued until eventually some pre-specified stopping condition is satisfied. Since all state changes occur only at event times for a discrete-event simulation model, periods of inactivity are skipped over by jumping the clock from event time to event time Created Simulation Tools In order to provide the model simulation capability within the rube framework, two translators were created along with SimPack J/S. These translators translate a model file written in MXL to DXL and DXL to JavaScript codes to be executed on the Web.

59 MXL to DXL Translation Engine Recently, DXL was created to represent a heterogeneous multimodel, defined in MXL, with a homogeneous assembly level block diagram modeling language. The MXL to DXL Translation Engine is written in XSLT and it translates a model file written in MXL, shown in Figure 4-17, by converting all the elements in MXL, such as model, node, and edge, into a block element in DXL. An equivalent 2D diagram for FBM with 3 functions and 2 traces is depicted in Figure <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> Figure F2TR FBM in MXL FBM F1 TR12 F2 TR23 F3 Figure D Diagram for 3F2TR FBM in MXL

60 48 The above MXL example is translated into DXL as shown in Figure 4-19 and Figure 4-20, respectively by the MXL to DXL Translator Engine. <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> </block> <block id="f3"> <port id="f3.ip1" type="input" source="f2.op1" data_type="integer"/> <definition id="f3.js" func="sub_func"/> </block> <connect id="tr12"> <port id="tr12.op1" type="input" source="f1.op1" data_type="integer"/> <port id="tr12.ip1" type="output" source="f2.ip1" data_type="integer"/> </connect> <connect id="tr23"> <port id="tr23.op1" type="input" source="f2.op1" data_type="integer"/> <port id="tr23.ip1" type="output" source="f3.ip1" data_type="integer"/> </connect> </DXL> Figure F2TR FBM in DXL Figure D Diagram for 3F2TR FBM in DXL

61 49 This translation capability of MXL to DXL translator enables a modeler to represent the heterogeneous multimodel with homogeneous language which can be depicted as a simple block diagram that can be easily converted into an executable JavaScript code through DXL to JavaScript Translation Engine DXL to JavaScript Translation Engine The converted DXL file is then translated into executable JavaScript file through the DXL to JavaScript Translation Engine developed using DOM. The translator autogenerates event-based scheduling JavaScript code as shown in Figure This auto code generation tool makes rube a handy tool for a modeler, enabling one to define one's own simulation programs for each element in a model and execute it within rube framework. <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation="dxl.xsd"> <block id="b1"> <port id="b1.op1" type="output" target="b2.ip1"> </port> <definition id="b1.js" func="gen_func"> </definition> </block> <block id="b2"> <port id="b2.ip1" type="input" source="b1.op1"> </port> <port id="b2.op1" type="output" target="b3.ip1"> </port> <definition id="b2.js" func="mult_func"> </definition> </block> function main() { while (sim_time() < end_time) { next_event(event,block_token); if (sim_time()!= last_time) { last_time = sim_time(); } update_block(event,block_token); } } function update_block(event,block_token) { var i,j; block_num = block_token.attr[0]; </DXL> <block id="b3"> <port id="b3.ip1" type="input" source="b2.op1"> </port> <definition id="b3.js" func="sub_func"> </definition> </block> <connect id="tr1"> <port id="tr1.op1" type="input" source="b1.op1"> </port> <port id="tr1.ip1" type="output" target="b2.ip1"> </port> </connect> <connect id="tr2"> <port id="tr2.op1" type="input" source="b2.op1"> </port> <port id="tr2.ip1" type="output" target="b3.ip1"> </port> </connect> j++) } switch (event.value) { case 0: gen_func(block_token); break; case 1: mult_func(block_token); break; case 2: sub_func(block_token); break; } for(i=0;i<output_num[block_num];i++) { block_token.attr[0] = out[block_num][i]; for(j=0; j<input_num[out[block_num][i]]; { block_token.attr[j+1] = value[in1[out[block_num][i]][j]]; } schedule(block_type[out[block_num][i]], delay[out[block_num][i]],block_token); } Figure Translated 3F2TR FBM in JavaScript

62 CHAPTER 5 MODELING: MXL AND MODEL FUSION ENGINE The features described in the section 2.5 made XML an attractive tool for our research, and the components in the rube architecture have been implemented using the XML-based technologies such as XML Schema and Extensible Stylesheet Language Transformations (XSLT). In this Chapter, the implementation of MXL, as a model representation language, and Model Fusion Engine, as a model creation tool, are described in detail with examples. 5.1 Overview Initially, a Document Type Definition (DTD) has been used 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 has 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. For these reasons, we have used XML Schema to represent the necessary rules and syntax of our Multimodel exchange Language (MXL), the language which is used to define a model file containing the topology of a single model or a heterogeneous multimodel in an abstract level and exchange the model file over the internet. 50

63 51 Another powerful XML technique we have used in our rube architecture is 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) described in section Model Representation in MXL MXL is created in order to support a modeler to represent topology and behavior of a multimodel within the framework. An MXL file, which is an XML document written in MXL, represents a single dynamic model type or a multimodel that consists of heterogeneous sub-models. It contains model and simulation elements of the model type. Following are the definitions of each component in MXL: - model element defines topology and behavior of a model. It contains topology and behavior as sub-elements and type attribute, the value of which can be MULTIMODEL, FSM, FBM, and other dynamic model types. - topology element defines objects and the connectivity of each object in the model. It contains node and edge elements. - node element is either an internal node or a leaf node containing script element. It contains id and type as attributes and script or sub-model as sub-element. - edge element defines the connectivity among each nodes. It contains id, type, begin, end, and data_type as attributes and script as subelement. - script element defines the JavaScript function to be executed. It contains id and func attributes.. id attribute describes the name of JavaScript file which contains the function.. func attribute has the name of user defined function which will be executed. - behavior element defines the type of animation that signifies the current node. It contains type attribute which defines the type of animation.

64 52 - simulation element defines the information needed to execute the simulation. It contains simtime and inputdata as sub-elements. - simtime element defines the total simulation time for model execution. It contains duration attribute which defines the simulation time in miliseconds. - inputdata element defines the source of input data for the simulation. It contains type attribute which defines the type of input data. In order to support MXL, which enables a modeler to define a multimodel that contains heterogeneous sub models, an MXL Schema was created and a part of the Schema is shown in Figure 5-1. Detailed description is discussed in Section 5.2. <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en"> Multimodel exchange Language(MXL) schema for rube architecture. Copyright 2001 University of Florida. All rights reserved. </xsd:documentation> <xsd:appinfo> Provides Modeling and Simulation Framework for 3D Dynamic Models. </xsd:appinfo> </xsd:annotation> <xsd:element name="mxl" type="mxltype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="mxltype"> <xsd:sequence> <xsd:element name="model" type="modeltype"/> <xsd:element name="simulation" type="simulationtype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="modeltype"> <xsd:sequence> <xsd:element name="topology" type="topologytype"/> <xsd:element name="behavior" type="behaviortype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype>... </xsd:schema> Figure 5-1. Segment of MXL Schema An example of a model file, written in MXL, which defines an FBM with three functions and two traces is shown in Figure 5-2.

65 53 <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> <behavior type="vibrate"> <axis id="x"/> </behavior> </model> <simulation type="fbm"> <program name="fbm3f2tr.js"/> <simtime duration="120"/> <inputdata type="randomgenerator"/> </simulation> </MXL> Figure 5-2. An FBM with Three Functions and Two Traces in MXL An abstract diagram for the FBM with Three Functions and Two Traces (3F2TR) in MXL shown above can be depicted in 2D diagram as shown in Figure 5-3. FBM F1 TR12 F2 TR23 F3 Figure D Diagram for 3F2TR FBM in MXL

66 MXL Schema Most XML developers are familiar with using Document Type Definitions (DTDs) a schema that defines the content model of an XML document to enforce the structure of XML documents. However, DTD has several shortcomings. First, it is not an XML document, so XML parsers do not process it easily. DTD does not support data typing, so all content is treated as strings. This lack of support for data types means that an additional workload must be placed on applications handling the XML document to verify the content of the XML document. Finally, a DTD does not allow element names to be reused on the same document. For all of these reasons, DTD is slowly losing ground to the Microsoft Extensible Data Reduced (XDR) schema language, Document Content Description (DCD), and XML Schema Definition (XSD) language. An ideal XML Schema implementation should support data types, use XML syntax, be able to be processed by XML processors, and support elements of global and local scope (for example, the use of identical element names). The World Wide Web Consortium (W3C)'s XSD has been formally approved as a Recommendation. To document a schema, the <!-- and --> pair can be used, since an XSD document is an XML document. However, applications processing the XML schema might not be able to access the comment, because an XML parser can choose to ignore the comments in an XML document. In that case, the comment is not accessible for further processing. To document the MXL schema, the <xsd:annotation> element has been used. The <xsd:annotation> element contains two child elements: <xsd:appinfo>, which is for the XML parsers to process the comments, and <xsd:documentation>, which allows you to add in comments for human consumption. A segment of MXL Schema for the MXL in top-down fashion is shown in Figure. 5-4.

67 55 <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en"> Multimodel exchange Language(MXL) schema for rube architecture. Copyright 2001 University of Florida. All rights reserved. </xsd:documentation> <xsd:appinfo> Provides Modeling and Simulation Framework for 3D Dynamic Models. </xsd:appinfo> </xsd:annotation> <xsd:element name="mxl" type="mxltype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="mxltype"> <xsd:sequence> <xsd:element name="model" type="modeltype"/> <xsd:element name="simulation" type="simulationtype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="modeltype"> <xsd:sequence> <xsd:element name="topology" type="topologytype"/> <xsd:element name="behavior" type="behaviortype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="topologytype"> <xsd:sequence> <xsd:element name="node" type="nodetype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="edge" type="edgetype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="nodetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="start" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="edgetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="begin" type="xsd:string"/> <xsd:attribute name="end" type="xsd:string"/> </xsd:complextype>... </xsd:schema> Figure 5-4. MXL Schema

68 Simple Model Representation With the given XML Schema for the Multimodeling Exchange Language, a model file is used to represent the topology of a 3D dynamic model. For example, a model file for the Finite State Machine (FSM) with three states and three transitions shown in Figure 5-3 can be represented in MXL file as shown in Figure 5-5. <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <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="pulsate"> </behavior> </model> <simulation type= FSM > <program name= fsmmain.js ></program> <simtime duration= 120 ></simtime> <inputdata type= RANDOMGENERATOR ></inputdata> </simulation> </MXL> Figure 5-5. Model File for FSM with 3 States and 3 Transitions A detailed description of each element in the model file is discussed in section Multimodel Representation A multimodel, which contains heterogeneous model types, can be represented in MXL since a node element in the model file can contain another sub-model inside. A multimodel example of three function FBM containing a three-state FSM inside the second function written in MXL, which can be described in a 2D diagram as shown in Figure 5-6, can also be depicted in Figure 5-7.

69 57 FBM F2 FSM F1 TR12 S3 S1 T23 T32 T12 S2 TR23 F3 Figure 5-6. Multimodel File for 3S3T FSM inside the 3F2TR FBM in 2D Diagram <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <model id="fsm3s3t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> </model> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> Figure 5-7. Multimodel File for 3S3T FSM inside the 3F2TR FBM in MXL

70 Model Creation with Model Fusion Engine In this section, the model creation process is described focusing on the model object generation and model behavior generation. Segments of the Model Fusion Engine are provided with description along with the final result created by the Engine. The fusion process of the Engine is an XSLT-based process, where the two XML documents, scene.xml and model.xml, are used as input and an XML file, called fsm.xml, 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 model specification. The skeleton of the dynamic model is created by copying all the geometries from the scene file that matches the names of each corresponding node and edge in the model file Model Object Fusion Process In order for the Model Fusion Engine to create a 3D dynamic model with the given model file, it analyzes the content in the model file and work with another XML file, scene file, which contains geometry of the model. Since the Model Fusion Engine is developed in XSLT, some of the methods are discussed in the following subsections. First, the XML Document Handling mechanism will be discussed with a sample XSLT code. Then, the name correspondence, an important method which allows the Model Fusion Engine to work with different XML documents to copy the corresponding elements from other XML documents, will be discussed XML Document Handling There can be multiple input documents and the stylesheet can use the document () function to load secondary input documents, based on URI references held in the source

71 59 document or the stylesheet. Each input document is processed as a tree in its own right, in exactly the same way as the principal input document. The stylesheet can consist of multiple documents. There are two directives that can be used in the stylesheet, <xsl:include> and <xsl:import>, to load additional stylesheet modules and use them as extensions of the first. Splitting a stylesheet in this way allows modularity: in a complex environment different aspects of processing can be described in component stylesheets that can be incorporated into several different parent stylesheets. Several XSLT implementations also allow a single run of the XSLT processor to produce multiple output documents. This allows a single source document to be split into several output files: for example, the input might contain the text of an entire book, while the output contains one HTML file for each chapter, all connected using suitable hyperlinks. However, this capability is not present in the current version of the XSLT standard, and it is provided in different ways in different products. In the above FSM example, when the Model Fusion Engine detects each node element in the model file, it save the value of the id attribute in the curr_state variable and opens the scene.xml file which contains the objects in X3D format with the function, document( scene.xml ), as shown in Figure 5-8. <!-- *** Copy the Geometry contents of STATE (S#) from the Scene File *** --> <xsl:variable name="curr_state" select="./@id"></xsl:variable> <!--************* Element copied from the Scene File **************--> </xsl:text> <xsl:copy-of select="document('scene.xml')//* [@DEF=$curr_state]"/> <!--*********************************************************--> </xsl:text> Figure 5-8. XSLT Code for accessing another XML Document

72 60 This process creates a skeleton of the 3D dynamic model, which defines the appearance of the model in X3D. Later, the Model Fusion Engine will add the scripts and the ROUTE elements, which act as the nerve system, to these elements to form a complete working dynamic model Name Correspondence In order for the Model Fusion Engine to locate the corresponding element in the scene.xml file, it searches all the elements to match an element whose attribute value is the same as the value stored in the curr_state variable. In the model file, each node element is selected and the value of id attribute is stored in the curr_state variable with the following statements: <xsl:for-each select="//node"> <xsl:variable name="curr_state" select="./@id"></xsl:variable> Each element in the scene.xml file as shown in the Figure 5-4 is searched and the element with the matching value in the DEF attribute, such as S1, S2, and S3, is located and copied onto the final output file with the following statement: <xsl:copy-of select="document('scene.xml')//* [@DEF=$curr_state]"/> A segment of code, which copies all the nodes, is shown in Figure 5-9.

73 61 <xsl:template match="x3d"> <xsl:for-each select="node"> <Transform DEF="STATE_</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">" </xsl:text> <xsl:text disable-output-escaping="yes"> translation="0 0 0" scale="1 1 1"></xsl:text> <xsl:text disable-output-escaping="yes"> <children></xsl:text> <xsl:variable name="curr_state" select="./@id"></xsl:variable> <xsl:copy-of select="document('fsmgeometry.xml')//transform [@DEF=$curr_state]"/> Figure 5-9. A Fusion Segment of ModelEngine.xsl File With the following two lines shown in Figure 5-10, each node element in the model.xml file is accessed and processed by the Model Fusion Engine. <xsl:template> element enables a modeler to specify how transformation should work. Each <xsl:template> element is set up to match one node or a number of nodes in the source document, and to specify exactly how that node should be transformed. <xsl:template match="x3d"> <xsl:for-each select="node"> Figure <xsl:template> Element XSLT codes shown in Figure 5-11 are used in order to add a Transform element and a children element in the fsm.xml file as shown in Figure 5-12, which will contain geometry and script elements.

74 62 <xsl: text disable-output-escaping="yes"> <Transform DEF="STATE_</xsl:text><xsl:value-of <xsl: text disable-output-escaping="yes">"</xsl:text> <xsl: text disable-output-escaping="yes"> translation=" 0 0 0" scale="1 1 1"></xsl:text> <xsl: text disable-output-escaping="yes"> <children></xsl:text> Figure XSLT Code for <Transform> Element <Transform DEF="STATE_S1" translation="0 0 0" scale="1 1 1"> <children> Figure Created <Transform> Element With the following two elements as shown in Figure 5-13, the value of id attribute, e.g., "S1", "S2", etc., is stored in the curr_state variable and the geometry node in the scene.xml file, which has the same name value in the attribute DEF, is copied to the fsm.xml file: <xsl:variable name="curr_state" select="./@id"></xsl:variable> <xsl:copy-of select="document('scene.xml')//transform[@def=$curr_state]"/> Figure XSLT Code for <xsl:variable> Element Each selected Transform element is located and copied from the scene.xml file to fsm.xml file as shown in Figure 5-14.

75 63 <Transform DEF="S1" translation=" " center="0 0 0" rotation=" " scale="1 1 1" scaleorientation=" " bboxcenter="0 0 0" bboxsize=" "> <Shape> <Appearance> <Material diffusecolor=" " ambientintensity="0.2" emissivecolor="0 0 0" shininess="0.2" specularcolor="0 0 0" transparency="0"/></appearance> <Sphere radius="1"/> </Shape> </Transform> Figure Copied <Transform> Element In order to find the specified objects in the scene.xml file, the Model Fusion Engine uses name correspondence between the scene and model file Model Behavior Blending Process While all the matching objects in the scene.xml file are being copied onto the output file, the Model Fusion Engine inserts necessary script codes to the object so that it can perform the behavior specified in the model.xml file as shown in Figure <behavior type="vibrate"> <axis id="x"></axis> </behavior> Figure <behavior> Element The value of the attribute type defines the type of behavior when the state becomes active. Currently, the Model Fusion Engine handles two different behaviors, such as PULSATE and VIBRATE. The VIBRATE behavior is further divided into three sub-behaviors with each axis X, Y, and Z.

76 Inserting Behaviors The blending process adds JavaScript codes 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 in the fsm.xml file. The control script is also created to synchronize the behaviors of each object. The ROUTE 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 inserts necessary JavaScript code to the copied element in the output file with the user defined behavior, e.g., PULSATE, in the model file as shown in Figure <xsl:variable name="curr_behavior" select="//behavior/@type"></xsl:variable> <xsl:if test="$curr_behavior='pulsate'"> <Script xml:space="preserve" DEF="STATE_</xsl:text> <xsl:value-of select="./@id"/> <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">"></xsl:text> <![CDATA[ </xsl:text> function currstate(value) { </xsl:text> name = value;</xsl:text> } </xsl:text> Figure Inserting Behavior With the code denoted in the Figure 5-16, a Script element, which contains JavaScript functions, is added to the Transform element with the same id value, e.g., "S1", in the fsm.xml file as shown in Figure 5-17:

77 65 <Script xml:space="preserve" DEF="STATE_S1_VIBRATE"> <![CDATA[ javascript: function currstate(value) { name = value; } Figure Created <Script> Element Since the value of type attribute of behavior element in the model.xml file is "VIBRATE", the name of the Script element is defined as "STATE_S1_VIBRATE" and it is used in the ROUTE element to pass an event as shown in Figure <xsl:if test="$curr_behavior='vibrate'"> <xsl:for-each select="//node"> <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="state_</xsl:text> <xsl:value-of select="./@id"/> <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">"fromfield="newscale" </xsl:text> <xsl:text disable-output-escaping="yes">tonode="</xsl:text> <xsl:value-of select="./@id"/> <xsl:text disable-output-escaping="yes">"tofield="translation"/> </xsl:text> </xsl:for-each> </xsl:if> Figure XSLT Code for Blending Behaviors With the specified XSLT codes, the Model Fusion Engine creates the rest of the behavior in JavaScript as shown in Figure 5-19.

78 66 function currtime(value) { if (name =='S1'){ if (up) { t0 = t ; t1 = t ; t2 = t ; newscale[0] = t0; newscale[1] = t1; newscale[2] = t2; }... } } else { } if ((t0 > 1.2) (t0 < 0.8)) { up =!up; } newscale[0] = 1; newscale[1] = 1; newscale[2] = 1; Figure XSLT Code for Blending Behaviors Creating ROUTE statements The blending process adds JavaScripts 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 in the fsm.xml file. The control script is also created to synchronize the behaviors of each object. The ROUTE statements, which serve as the nerve system in which the control signals could flow, are also attached to the final 3D dynamic model. A segment of code, which blends script and ROUTE elements to the fsm.xml file, is shown in Figure 5-20.

79 67 <xsl:if test="$curr_behavior='vibrate'"> <Script xml:space="preserve" DEF="STATE_</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">"></xsl:text> <![CDATA[ </xsl:text> javascript: </xsl:text> function currstate(value) {</xsl:text> name = value;</xsl:text> } </xsl:text> Figure Figure XSLT Code for Blending Behaviors For each id, following ROUTE element is added to fsm.xml file as shown in <ROUTE fromnode="state_s1_vibrate" fromfield="newscale" tonode="s1" tofield="translation"/> Figure Created <ROUTE> Element Other functions and control Script element are also added to the fsm.xml file to produce a final dynamic 3D FSM model in X3D.

80 CHAPTER 6 SIMULATION: HIERARCHICAL STRUCTURE Recently, within the rube framework, we have formulated a Dynamics Exchange Language, called DXL. The MXL, DXL and JavaScript form a hierarchical structure of dynamic model representation and simulation in rube. Overall structure and translation processes between each representation are discussed in the following subsections. 6.1 Overview A simplified overall structure of the rube framework for model simulation is shown in Figure 6-1, which includes a scene file in X3D, a model file in MXL, a DXL file, and a Script file. DXL and Script codes, along with translators and SimPack J/S, are hidden from a modeler and can be represented as the Model Fusion Engine. Figure 6-1. Overall Structure of rube Framework for Model Simulation First, we will take a look at the MXL to DXL translation process followed by DXL to JavaScript translation process. 68

81 MXL to DXL Translation The definition and structure of MXL have been discussed in previous chapters. The definitions of DXL and the translation between MXL and DXL are discussed in the following subsections DXL Schema DXL is created in order to represent a multimodel, which has heterogeneous sub model types, within homogeneous block diagrams. A multimodel defined in MXL is translated into DXL through translator engine. Detailed process is discussed in Section DXL is compatible with other rube components such as MXL and X3D, which are also defined by XML for ease of translation and usability of a XML toolkit, XSLT. DXL plays the role of an assembly layer relating MXL to a simulation code referencing a SimPackJ/S toolkit, which is a JavaScript and Java version for SimPack. In rube architecture, XML toolkits like XSLT and DOM (Document Object Model) are used. Models represented by DXL are translated from MXL models by using XSLT and translated into actual simulation codes by using DOM as shown in Figure 6-2 [60]. Simulation MXL DXL SimPackJ/S Code XSLT DOM Figure 6-2. The role of DXL in rube architecture

82 70 A DXL file, which can be represented as a Block Network, is a directed graph of Blocks, Ports, and Connections. Following are the definitions of each component in DXL: - A Block has any number of Ports, a set of variables, a definition and a presentation. All variables are part of the DXL tree, and are referenced using the DOM API. - A Block's definition is a URL which is one of:. a Java or JavaScript function,. a DXL file representing another Block network, or. a MathML model of difference or differential equations. - A Block's presentation is an X3D URL, which specifies how the block is to be visualized. - A Port is a kind of Block that specifies the interface for a host block. There are input and output ports. - Connections occur between two Ports, and are directional. - The inset of block B is the set of blocks pointed to input ports for B. The outset of block B is the set of blocks pointed from output ports of B. A basic DXL diagram and its elements, which includes block, connect, and port, are shown in Figure 6-3. input port output port block connect Figure 6-3. A basic DXL diagram and its elements

83 71 In order to support DXL, which describes a multimodel in homogeneous form that contains simple block elements, a DXL Schema was created as shown in Figure 6-4. A detailed description is provided in Section <xsd:schema xmlns:xsd=" elementformdefault="qualified"> <xsd:element name="dxl"> <xsd:annotation> <xsd:documentation>comment describing your root element</xsd:documentation> </xsd:annotation> <xsd:complextype> <xsd:element name="block"> <xsd:complextype> <xsd:sequence> <xsd:element name="port"> <xsd:attribute name="id" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/> <xsd:attribute name="source" type="xsd:string" use="optional"/> <xsd:attribute name="target" type="xsd:string" use="optional"/> </xsd:element> <xsd:element name="definition"> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element> Figure 6-2. Segment of DXL Schema </xsd:sequence> </xsd:complextype> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element>... </xsd:schema> Figure 6-4. Segment of DXL Schema An example of FBM with three functions and two traces in DXL, which is translated from MXL, is shown in Figure 6-5. The DXL file is translated into a final JavaScript code which can be loaded and executed from an existing Internet browser. An abstract diagram for the FBM with three functions and two traces (3F2TR) in DXL shown in Figure 6-5 can be depicted as Figure 6-6.

84 72 <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> </block> <block id="f3"> <port id="f3.ip1" type="input" source="f2.op1" data_type="integer"/> <definition id="f3.js" func="sub_func"/> </block> <connect id="tr12"> <port id="tr12.op1" type="input" source="f1.op1" data_type="integer"/> <port id="tr12.ip1" type="output" source="f2.ip1" data_type="integer"/> </connect> <connect id="tr23"> <port id="tr23.op1" type="input" source="f2.op1" data_type="integer"/> <port id="tr23.ip1" type="output" source="f3.ip1" data_type="integer"/> </connect> </DXL> Figure 6-5. An FBM with Three Functions and Two Traces in DXL FBM F1.IP1 F2.IP1 F3.IP1 F1 TR12 F2 TR23 F3 F1.OP1 F2.OP1 F3.OP1 Figure D Diagram for 3F2TR FBM in DXL

85 Translation Process Since all the JavaScript codes will be defined within each function, i.e., in each definition, only the variables of interest should be specified in a block. All the elements in MXL, such as model, node, and edge, will become a block element in DXL. In order to translate an example model file, an FBM with three functions and two traces, written in MXL as shown in Figure 6-7, a Translation Engine was created in XSLT and a segment of the engine is shown in Figure 6-8. <?xml version="1.0" encoding="utf-8"?> <MXL> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> Figure 6-7. An MXL Example of 3F2TR FBM in MXL A model file written in MXL may contain a single model type or several heterogeneous model types to form a multimodel. The Translation Engine extracts the core elements and the relation between each element and generates homogeneous elements in DXL codes with the following guidelines. With a given MXL file as an input document, the Translation Engine selects all the node and edge elements in the model file and processes them sequentially. For each selected node and edge, the relation or the connectivity with other elements is checked with the information provided in the attribute values of edge elements. Each of the block

86 74 and connect elements are created in DXL file. Each block element is created with necessary port sub-elements for a connection and connect element which links each block in DXL. <!-- *** Create States and Transition Elements *** --> <xsl:template match="mxl"> <!-- *** Process if the Model Type is FSM *** --> <xsl:if test="./model/@type='fsm'"> <!-- *** Create each BLOCKs *** --> <xsl:for-each select="//node"> <xsl:variable name="curr_node_id" select="./@id"></xsl:variable> <xsl:variable name="curr_start" select="./@start"></xsl:variable> <!-- *** If the value of start attribute is 'TRUE', then create <block id="in"> *** --> <xsl:if test="$curr_start='true'"> <xsl:variable name="curr_start_node_id" select="./@id"></xsl:variable> <block id="in"></xsl:text> <port id="in.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="./@id"/>... Figure 6-8. A Segment of MXL to DXL Translation Engine With these guidelines, an MXL file is translated into DXL file through the Model Translation Engine written in XSLT. A sample MXL file shown in Figure 6-7 is translated into a DXL file as shown in Figure 6-9. <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> </block> <block id="f3"> <port id="f3.ip1" type="input" source="f2.op1" data_type="integer"/> <definition id="f3.js" func="sub_func"/> </block> <connect id="tr12"> <port id="tr12.op1" type="input" source="f1.op1" data_type="integer"/> <port id="tr12.ip1" type="output" source="f2.ip1" data_type="integer"/> </connect> <connect id="tr23"> <port id="tr23.op1" type="input" source="f2.op1" data_type="integer"/> <port id="tr23.ip1" type="output" source="f3.ip1" data_type="integer"/> </connect> </DXL> Figure 6-9. A Translated FBM in DXL file

87 75 Other possible basic FBM models, which can be constructed with a block diagram, have been tested and translated with MXL to DXL translator to test the extensibility of the translator, including the diagrams shown in Figure Figure Tested DXL Files in 2D Block Diagrams Homogeneous model types, such as FSM and FBM, have been represented with MXL and translated into DXL. All the other possible models in FSM have been tested for the extensibility of the translator. Also, the multimodel, which consists of these basic model types, has been tested and a translation example of that multimodel, which consists of FBM and FSM, is depicted in Figure 6-11 through Figure 6-14.

88 76 Figure 6-11 depicts an abstract level 2D diagram for a multimodel, which composed of FBM with three functions and FSM with three states inside the second function of the FBM. FBM F2 FSM F1 TR12 S3 S1 T23 T32 T12 S2 TR23 F3 Figure D Diagram for a Multimodel in MXL When it is translated into DXL, a conceptual 2D diagram for the DXL file can be depicted as shown in Figure 6-12 with homogeneous blocks, ports, and connects. IN.IP1 IN IN.OP1 IN.IP1 IN.OP1 F2 F1.IP1 F1 F3.IP1 F3 F1.OP1 F3.OP1 TR12 TR23 OUT.IP1 OUT.OP1 OUT.IP1 OUT OUT.OP1 Figure D Diagram for a Multimodel in DXL The multimodel represented in MXL is shown in Figure 6-13, where an FSM is contained inside the node element whose id attribute value is "F2."

89 77 <?xml version="1.0" encoding="utf-8"?> <MXL> <model id="fbm3f2t " type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> </topology> </model> </MXL> <node id="f2" type="function"> <model id="fsm3s3t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> </model> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> Figure A Multimodel With FBM and FSM in MXL This translation process of creating a homogeneous model from heterogeneous model types supports the DXL to JavaScript translation process by providing a simple set of elements for the translator to work with. A segment of the DXL file being translated from an MXL file is shown in Figure 6-14 with the same port elements distinguished by its id attribute values.

90 78 <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="fbm_3f2t_in"> <port id="fbm_3f2t_in.op1" type="output" target="s1.ip1" data_type="integer"></port> <definition id="fbm_3f2t_in.js" func="fbm_3f2t_in_func"></definition> </block> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> <port id="f2.ip1" type="output" target="fsm3s3t_in.ip1" data_type="integer"/> <port id="f2.op1" type="input" source="fsm3s3t_out.op1" data_type="integer"/> <block id="fsm3s3t_in"> <port id="fsm3s3t_in.op1" type="output" target="s1.ip1" data_type="integer"></port> <definition id="fsm3s3t_in.js" func="fsm3s3t_in_func"></definition> </block> <block id="s1"> <port id="s1.ip1" type="input" source="in.op1" data_type="integer"></port> <port id="s1.op1" type="output" target="t12.ip1" data_type="integer"></port> <port id="s1.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <definition id="s1.js" func="s1_func"></definition> </block> <block id="s2"> <port id="s2.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="s2.op1" type="output" target="t23.ip1" data_type="integer"></port> <port id="s2.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <port id="s2.ip1" type="input" source="t32.op1" data_type="integer"></port> <definition id="s2.js" func="s2_func"></definition> </block> <block id="s3"> <port id="s3.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="s3.op1" type="output" target="t32.ip1" data_type="integer"></port> <port id="s3.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <definition id="s3.js" func="s3_func"></definition> </block> <block id="t12"> <port id="t12.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="t12.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t12.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <definition id="t12.js" func="t12_func"></definition> </block> <block id="t23"> <port id="t23.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="t23.op1" type="output" target="s3.ip1" data_type="integer"></port> <port id="t23.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <definition id="t23.js" func="t23_func"></definition> </block> <block id="t32"> <port id="t32.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="t32.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t32.op2" type="output" target="fsm3s3t_out.ip1" data_type="integer"></port> <definition id="t32.js" func="t32_func"></definition> </block> Figure Multimodel with FBM and FSM in DXL

91 DXL to JavaScript Translation For translation from DXL to executable JavaScript codes, we use another translation engine developed by Jinho Lee of CISE, University of Florida. It takes a DXL document as an input and produces a SimPackJ/S which can simulate the defined model initially written in MXL. A brief look at the SimPackJ/S and the translation process will be discussed in the following sub sections SimPackJ/S Library SimPack J/S is a set of simulation programs written in JavaScript. Originally, the SimPack was written in C and C++ by Fishwick in 1992 [56]. The purpose of SimPack was to provide people with a starting point for simulating a system. It was translated into JavaScript and then merged into the rube architecture as one of the simulation packages. SimPack was converted to SimPack J/S to provide existing SimPack users with the new version of SimPack to extend their simulation areas, help future new users who want to simulate a system in a web-based environment, and create an XML-based rube architecture using MXL and DXL. SimPack J/S provides necessary functions, such as schedule() and next_event(), for final JavaScript codes translated from DXL files. These libraries enable the eventbased scheduling and model simulation within rube framework. SimPack has been translated into Java as well as JavaScript. SimPackJ/S includes the following models: Declarative Models: Finite State Automaton, Markov, and Petri nets Functional Models: Block, Cpudisk, Logic, Network, Qnet, and Queuing library. Constraint Model: Differential Equation

92 Translation Process The translation between DXL and SimPackJ/S requires JavaScript files that will be processed when each block is scheduled and processed as a new event. User defined JavaScript files for each block are shown in Figure B1.js function gen_func(block_token) { value[block_num] = value[block_num]+1; schedule(gen,delay[block_num],block_token); } B2.js function mult_func(block_token) { value[block_num] = block_token.attr[1] * 2; } B3.js function sub_func(block_token) { value[block_num] = block_token.attr[1] - 1; } B4.js function add_func(block_token) { value[block_num] = block_token.attr[1] + 10; } Figure User Defined JavaScript Files for Each Block With a JavaScript file name defined as the value of id attribute in definition sub element inside each block element and a function name defined as the value of attribute func, described in the translated DXL example file shown in Figure 6-9, the translator generates an executable JavaScript file that is blended with the library codes from the SimPack J/S. A translated executable JavaScript code for the DXL file shown in Figure 6-9 with each of the JavaScript functions shown in Figure 6-15 is shown in Figure 6-16.

93 81 <?xml version="1.0" encoding="utf-8"?> <script language="javascript" SRC="queuing.js"> </script> <script language="javascript">... var last_time,delta_time; var delay = new Array(NUM_BLOCKS); var num_blocks,block_num; var event = new INT();... function main() { var i; var block_name = new Array("F1", "F2", "F3"); }... init_simpack(heap); read_network(); for (i=0;i<num_blocks;i++) { value[i] = 0.0; if (block_type[i] == GEN) { block_token.attr[0] = i; schedule(gen,0.0,block_token); } } last_time = 0.0; while (sim_time() < end_time) { next_event(event,block_token); if (sim_time()!= last_time) { document.writeln("event value : " + event.value); document.writeln(" Sim Time : " + sim_time()); } print(" Last Time : " + last_time); for(i=0;i<num_blocks;i++) print("block Output: " + block_name[i] + " = " + value[i]); print("================================================"); last_time = sim_time(); } update_block(event,block_token); Figure A Segment of Created JavaScript File for an FBM The final step in executing the translated JavaScript file is through opening the file with an existing Internet browser, such as Internet Explorer. A simulation output of translated JavaScript is shown in Figure A modeler can define any function and assign it to an element in a model file written in MXL. This freedom of defining a function as a separate file and using it within an MXL file allows a modeler to define, create, and execute a model more easily and in more personalized ways.

94 82 Event value : 0 Sim Time : 1 Last Time : 0 Block Output: B1 = 1 Block Output: B2 = 0 Block Output: B3 = 0 ================================================ Event value : 0 Sim Time : 2 Last Time : 1 Block Output: B1 = 2 Block Output: B2 = 2 Block Output: B3 = 0 ================================================ Event value : 1 Sim Time : 3 Last Time : 2 Block Output: B1 = 3 Block Output: B2 = 4 Block Output: B3 = 1 ================================================ Event value : 2 Sim Time : 4 Last Time : 3 Block Output: B1 = 4 Block Output: B2 = 6 Block Output: B3 = 3 ================================================ Event value : 0 Sim Time : 5 Last Time : 4 Block Output: B1 = 5 Block Output: B2 = 8 Block Output: B3 = 5 ================================================ Figure 6-17 Output of simulation

95 CHAPTER 7 CONCLUSION In this chapter, results of the research are summarized and the contribution to knowledge is assessed along with some of the future challenges regarding the XMLbased 3D rube framework. 7.1 Summary of Results Our goal is to create a web-based Modeling and Simulation environment that enables modelers to define, create and execute customized or personalized dynamic models, such as a Finite State Machine (FSM), a Functional Block Model (FBM), or a heterogeneous multimodel which is composed of these homogeneous dynamic models. We have built a framework, called rube, to achieve that goal. To support the model representation that separates the model content from its appearance, the MXL interchange language has been created using XML Schema. To support the model creation, the Model Fusion Engine has been created which semi-automates the process. For the model execution, a set of translation tools, MXL to DXL and DXL to JavaScript Translation Engines, were built in XSLT and DOM. The first translation engine translates a heterogeneous multimodel defined in MXL into homogeneous blocks in DXL and the second translation engine produces executable JavaScript codes that simulate the model defined in an MXL file. To date, we have only achieved some of our goals for rube, since we have defined the FSM, the FBM, and the multimodel in MXL but no others. We also need to create a 83

96 84 core set of alternate model types, and allow these model types to be defined in a hierarchy of heterogeneous models. The contributions of this research in the field of Modeling and Simulation can be summarized as follows: Provide a Web-based Modeling and Simulation (M&S) Environment. Much of our previous work has been done in representing dynamic model types in VRML and providing it on the Internet as a repository of building blocks for modeling and simulation. Since the future of VRML is X3D and since X3D is in XML, it is natural to focus on XML as the basis for model definition, translation and integration. The XML-based rube framework we have created also provides an environment where model authors can maximize their own aesthetic creativity in creating a model. Each object can be crafted to the extent that the model author is fully satisfied with its aesthetic appearance. Furthermore, the model author can personalize the process of simulating the created model. In order to achieve modeling and simulation on the Internet, we have used the most current XML-based technologies available on the web today, to develop tools to support the model representation, the model creation, and the model execution processes. Model Representation: Separation of Model Contents from its Presentation. XML-based rube modeling architecture provides a methodology that enables a modeler to define a model in a way that separates the core contents of the model from its presentation in MXL. This allows the modelers to share the topology of a dynamic model freely over the Internet and present the model in a way that is more pleasing and meaningful to the model authors.

97 85 The model file written in MXL captures all the information about the model: topology that defines the connectivity of the model type and its behavior. This provides an effective way to represent both geometry and dynamic model information using XML. Model Creation: Demonstrate encoding of the fusion process by creating Model Fusion Engine. Another important contribution is the development 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, which consists of object generation and behavior blending processes. The fusion process is where the integration of semantic information with its presentation information is achieved. Behavior blending process is represented as inserting scripts, which defines the behavior of a model component, into the node structure of an XML to create a 3D dynamic model. Model Execution: Model Translation from Abstract to Executable Models. A translator is created to transform an abstract level model, represented in MXL which can be thought of as a high-level modeling language, into an assembly level modeling language, called DXL, and then translate it into an executable JavaScript codes for the model execution. A simulation library, SimPack J/S, has been used in the model creation phase. By incorporating the SimPack J/S, it has been shown that existing simulation packages can be used as a part of the rube framework. Within the rube framework, a modeler can define a desired function for each model component as a separate file and associate these files in the MXL files to be translated and executed.

98 Future Challenges To date, a part of this framework has been employed in both 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 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 in our architecture and implementation include: 1) applying the results to other dynamic model types such as Petri net (PETRI) and System Dynamics; 2) performing in-depth research on extending the multimodel concept; and 3) fully incorporating a simulation capability to provide the rube as an architecture that supports both modeling and simulation.

99 APPENDIX A MXL, DXL SCHEMA MXL SCHEMA (TOP-DOWN) <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en"> Multimodel exchange Language(MXL) schema for rube architecture. Copyright 2001 University of Florida. All rights reserved. </xsd:documentation> <xsd:element name="mxl" type="mxltype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="mxltype"> <xsd:sequence> <xsd:element name="model" type="modeltype"/> <xsd:element name="simulation" type="simulationtype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="modeltype"> <xsd:sequence> <xsd:element name="topology" type="topologytype"/> <xsd:element name="behavior" type="behaviortype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="topologytype"> <xsd:sequence> <xsd:element name="node" type="nodetype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="edge" type="edgetype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="nodetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="start" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="edgetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="begin" type="xsd:string"/> <xsd:attribute name="end" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="behaviortype"> <xsd:sequence> <xsd:element name="axis" type="axistype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="axistype"> <xsd:attribute name="id" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="simulationtype"> <xsd:sequence> <xsd:element name="program" type="programtype"/> <xsd:element name="simtime" type="simtimetype"/> <xsd:element name="inputdata" type="inputdatatype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="programtype"> <xsd:attribute name="name" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="simtimetype"> <xsd:attribute name="duration" type="xsd:float"/> </xsd:complextype> <xsd:complextype name="inputdatatype"> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> </xsd:schema> 87

100 88 MXL SCHEMA (BOTTOM-UP) <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" <xsd:annotation> <xsd:documentation xml:lang="en"> Multimodel exchange Language(MXL) schema for rube architecture. Copyright 2001 University of Florida. All rights reserved. </xsd:documentation> <xsd:element name="mxl" type="mxltype"/> <xsd:element name="comment" type="xsd:string"/> <xsd:complextype name="mxltype"> <xsd:sequence> <xsd:element name="model" type="modeltype"/> <xsd:element name="simulation" type="simulationtype"/> </xsd:sequence> </xsd:complextype> <xsd:complextype name="modeltype"> <xsd:sequence> <xsd:element name="topology" type="topologytype"/> <xsd:element name="behavior" type="behaviortype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="topologytype"> <xsd:sequence> <xsd:element name="node" type="nodetype" minoccurs="0" maxoccurs="unbounded"/> <xsd:element name="edge" type="edgetype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="nodetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="start" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="edgetype"> <xsd:attribute name="id" type="xsd:string"/> <xsd:attribute name="type" type="xsd:string"/> <xsd:attribute name="begin" type="xsd:string"/> <xsd:attribute name="end" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="behaviortype"> <xsd:sequence> <xsd:element name="axis" type="axistype" minoccurs="0" maxoccurs="unbounded"/> </xsd:sequence> <xsd:attribute name="id" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="axistype"> <xsd:attribute name="id" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="simulationtype"> <xsd:sequence> <xsd:element name="program" type="programtype"/> <xsd:element name="simtime" type="simtimetype"/> <xsd:element name="inputdata" type="inputdatatype"/> </xsd:sequence> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="programtype"> <xsd:attribute name="name" type="xsd:string"/> </xsd:complextype> <xsd:complextype name="simtimetype"> <xsd:attribute name="duration" type="xsd:float"/> </xsd:complextype> <xsd:complextype name="inputdatatype"> <xsd:attribute name="type" type="xsd:string"/> </xsd:complextype> </xsd:schema>

101 89 DXL SCHEMA <?xml version="1.0" encoding="utf-8"?> <xsd:schema xmlns:xsd=" elementformdefault="qualified"> <xsd:element name="dxl"> <xsd:annotation> <xsd:documentation>comment describing your root element</xsd:documentation> </xsd:annotation> <xsd:complextype> <xsd:element name="block"> <xsd:complextype> <xsd:sequence> <xsd:element name="port"> <xsd:attribute name="id" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/> <xsd:attribute name="source" type="xsd:string" use="optional"/> <xsd:attribute name="target" type="xsd:string" use="optional"/> </xsd:element> <xsd:element name="definition"> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element> </xsd:sequence> </xsd:complextype> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element> <xsd:element name="connect"> <xsd:complextype> <xsd:sequence> <xsd:element name="port"> <xsd:attribute name="id" type="xsd:string" use="required"/> <xsd:attribute name="type" type="xsd:string" use="required"/> <xsd:attribute name="source" type="xsd:string" use="optional"/> <xsd:attribute name="target" type="xsd:string" use="optional"/> </xsd:element> </xsd:sequence> </xsd:complextype> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element> </xsd:complextype> <xsd:attribute name="id" type="xsd:string" use="required"/> </xsd:element> </xsd:schema>

102 APPENDIX B MODELS IN MXL FSM FSM S1 T12 T21 S2 2 State FSM in 2D Diagram <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model id="fsm2s2t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t21" type="transition" begin="s2" end="s1" data_type="integer"> <script id="t21.js" func="t21_func"/> </edge> </topology> <behavior type="vibrate"> <axis id="x"/> </behavior> </model> <simulation type="fsm"> <program name="fsm2s2t.js"/> <simtime duration="120"/> <inputdata type="randomgenerator"/> </simulation> </MXL> 2 State FSM in MXL 90

103 91 FSM S1 T12 S3 T32 T23 S2 3 State FSM in 2D Diagram <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model id="fsm2s2t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> <behavior type="vibrate"> <axis id="x"/> </behavior> </model> <simulation type="fsm"> <program name="fsm3s3t.js"/> <simtime duration="120"/> <inputdata type="randomgenerator"/> </simulation> </MXL> 3 State FSM in MXL

104 92 FBM FBM F1 TR12 F2 TR23 F3 3 Function FBM in 2D Diagram <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> 3 Function FBM in MXL

105 93 MULTIMODEL FBM F2 FSM F1 TR12 S3 S1 T23 T32 T12 S2 TR23 F3 Multimodel (FBM-FSM) in 2D Diagram <?xml version="1.0" encoding="utf-8"?> <MXL> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <model id="fsm3s3t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> </model> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> Multimodel (FBM-FSM) in MXL

106 APPENDIX C TRANSLATION EXAMPLES: MXL TO DXL, DXL TO JAVASCRIPT 3 FUNCTION FBM <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL> 3 Function FBM in MXL <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> </block> <block id="f3"> <port id="f3.ip1" type="input" source="f2.op1" data_type="integer"/> <definition id="f3.js" func="sub_func"/> </block> <connect id="tr12"> <port id="tr12.op1" type="input" source="f1.op1" data_type="integer"/> <port id="tr12.ip1" type="output" source="f2.ip1" data_type="integer"/> </connect> <connect id="tr23"> <port id="tr23.op1" type="input" source="f2.op1" data_type="integer"/> <port id="tr23.ip1" type="output" source="f3.ip1" data_type="integer"/> </connect> </DXL> Translated 3 Function FBM in DXL 94

107 95 Translated Executable 3 Function FBM in Javascript <script language="javascript" SRC="queuing.js"> </script> <script language="javascript"> var NUM_BLOCKS = 10; var NUM_TYPES = 6; var MAX_INPUTS = 5; var MAX_OUTPUTS = 5; var MAX_PARAMS = 5; var GEN = 0; var last_time,delta_time; var delay = new Array(NUM_BLOCKS); var num_blocks,block_num; var event = new INT(); var in1 = new Array(NUM_BLOCKS); var out = new Array(NUM_BLOCKS); var param= new Array(NUM_BLOCKS); for(var k=0; k<num_blocks; k++) { in1[k] = new Array(MAX_INPUTS); out[k] = new Array(MAX_OUTPUTS); param[k] = new Array(MAX_PARAMS); } var block_type = new Array(NUM_BLOCKS); var input_num = new Array(NUM_BLOCKS); var output_num = new Array(NUM_BLOCKS); var end_time; var value = new Array(NUM_BLOCKS); var block_token = new TOKEN(); function print(obj) { document.writeln(obj + "<BR>"); } function main() { var i; var block_name = new Array("F1", "F2", "F3"); } init_simpack(heap); read_network(); for (i=0;i<num_blocks;i++) { value[i] = 0.0; if (block_type[i] == GEN) { block_token.attr[0] = i; schedule(gen,0.0,block_token); } } last_time = 0.0; while (sim_time() < end_time) { next_event(event,block_token); if (sim_time()!= last_time) { document.writeln("event value : } " + event.value); document.writeln(" Sim Time : " + sim_time()); print(" Last Time : " + last_time); for(i=0;i<num_blocks;i++) print("block Output: " + block_name[i] + " = " + value[i]); print("================================================"); last_time = sim_time(); } update_block(event,block_token);

108 96 function update_block(event,block_token) { var i,j; block_num = block_token.attr[0]; switch (event.value) { case 0: gen_func(block_token); break; case 1: mult_func(block_token); break; case 2: sub_func(block_token); break; } for(i=0;i<output_num[block_num];i++) { block_token.attr[0] = out[block_num][i]; for(j=0; j<input_num[out[block_num][i]]; j++) { block_token.attr[j+1] = value[in1[out[block_num][i]][j]]; } schedule(block_type[out[block_num][i]], delay[out[block_num][i]],block_token); } } function gen_func(block_token) { value[block_num] = value[block_num]+1; schedule(gen,delay[block_num],block_token); } function mult_func(block_token) { value[block_num] = block_token.attr[1] * 2; } function sub_func(block_token) { value[block_num] = block_token.attr[1] - 1; } function read_network() { var i,j,block_num; num_blocks = 3; end_time = 14.0; block_type[0] = 0; block_type[1] = 1; block_type[2] = 2; delay[0] = 1; delay[1] = 1; delay[2] = 1; input_num[0] = 0; input_num[1] = 1; input_num[2] = 1; output_num[0] = 1; output_num[1] = 1; output_num[2] = 0; in1[1][0] = 0; in1[2][0] = 1; out[0][0] = 1; out[1][0] = 2; } </script> <script language="javascript"> main(); </script> Executable 3 Function FBM in Javascript - FBM-3F2T.htm

109 97 Execution Result of 3 Function FBM - FBM-3F2T.html

110 98 3 STATE FSM <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model id="fsm2s2t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> <behavior type="vibrate"> <axis id="x"/> </behavior> </model> <simulation type="fsm"> <program name="fsm3s3t.js"/> <simtime duration="120"/> <inputdata type="randomgenerator"/> </simulation> </MXL> 3 State FSM in MXL

111 99 Translated 3 State FSM in DXL <?xml version="1.0" encoding="utf-8"?> <DXL xmlns:xsi=" xsi:nonamespaceschemalocation="dxl.xsd"> <block id="in"> <port id="in.op1" type="output" target="s1.ip1" data_type="integer"></port> <definition id="in.js" func="in_func"></definition> </block> <block id="s1"> <port id="s1.ip1" type="input" source="in.op1" data_type="integer"></port> <port id="s1.op1" type="output" target="t12.ip1" data_type="integer"></port> <port id="s1.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="s1.js" func="s1_func"></definition> </block> <block id="s2"> <port id="s2.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="s2.op1" type="output" target="t23.ip1" data_type="integer"></port> <port id="s2.op2" type="output" target="out.ip1" data_type="integer"></port> <port id="s2.ip1" type="input" source="t32.op1" data_type="integer"></port> <definition id="s2.js" func="s2_func"></definition> </block> <block id="s3"> <port id="s3.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="s3.op1" type="output" target="t32.ip1" data_type="integer"></port> <port id="s3.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="s3.js" func="s3_func"></definition> </block> <block id="t12"> <port id="t12.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="t12.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t12.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t12.js" func="t12_func"></definition> </block> <block id="t23"> <port id="t23.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="t23.op1" type="output" target="s3.ip1" data_type="integer"></port> <port id="t23.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t23.js" func="t23_func"></definition> </block> <block id="t32"> <port id="t32.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="t32.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t32.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t32.js" func="t32_func"></definition> </block> <block id="out"> <port id="out.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t32.op1" data_type="integer"></port> <definition id="out.js" func="out_func"></definition> </block>

112 100 <connect id="c_in_s1"> <port id="c_in_s1.ip1" type="input" source="in.op1" data_type="integer"></port> <port id="c_in_s1.op1" type="output" target="s1.ip1" data_type="integer"></port> </connect> <connect id="c_s1_t12"> <port id="c_s1_t12.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="c_s1_t12.op1" type="output" target="t12.ip1" data_type="integer"></port> </connect> <connect id="c_t12_s2"> <port id="c_t12_s2.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="c_t12_s2.op1" type="output" target="s2.ip1" data_type="integer"></port> </connect> <connect id="c_s2_t23"> <port id="c_s2_t23.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="c_s2_t23.op1" type="output" target="t23.ip1" data_type="integer"></port> </connect> <connect id="c_t32_s2"> <port id="c_t32_s2.ip1" type="input" source="t32.op1" data_type="integer"></port> <port id="c_t32_s2.op1" type="output" target="s2.ip1" data_type="integer"></port> </connect> <connect id="c_t23_s3"> <port id="c_t23_s3.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="c_t23_s3.op1" type="output" target="s3.ip1" data_type="integer"></port> </connect> <connect id="c_s3_t32"> <port id="c_s3_t32.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="c_s3_t32.op1" type="output" target="t32.ip1" data_type="integer"></port> </connect> <connect id="c_s1_out"> <port id="c_s1_out.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="c_s1_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_s2_out"> <port id="c_s2_out.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="c_s2_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_s3_out"> <port id="c_s3_out.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="c_s3_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t12_out"> <port id="c_t12_out.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="c_t12_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t23_out"> <port id="c_t23_out.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="c_t23_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t32_out"> <port id="c_t32_out.ip1" type="input" source="t32.op1" data_type="integer"></port> <port id="c_t32_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> </DXL>

113 101 Translated 3 State FSM in Javascript <script language="javascript" SRC="queuing.js"> </script> <script language="javascript"> var NUM_BLOCKS = 10; var NUM_TYPES = 6; var MAX_INPUTS = 5; var MAX_OUTPUTS = 5; var MAX_PARAMS = 5; var GEN = 0; var last_time,delta_time; var delay = new Array(NUM_BLOCKS); var num_blocks,block_num=4; var event = new INT(); var in1 = new Array(NUM_BLOCKS); var out = new Array(NUM_BLOCKS); var param= new Array(NUM_BLOCKS); for(var k=0; k<num_blocks; k++) { in1[k] = new Array(MAX_INPUTS); out[k] = new Array(MAX_OUTPUTS); param[k] = new Array(MAX_PARAMS); } var block_type = new Array(NUM_BLOCKS); var input_num = new Array(NUM_BLOCKS); var output_num = new Array(NUM_BLOCKS); var end_time; var value = new Array(NUM_BLOCKS); var flag = false; var block_token = new TOKEN(); var current_state; var in_q = new Array(1, 1, 0, 0, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1); var current_in = 0; function print(obj) { document.writeln(obj + "<BR>"); } function main() { var i; var block_name = new Array("F1", "TR1", "TR2", "TR3", "S1", "S2", "S3"); init_simpack(heap); read_network(); for (i=0;i<num_blocks;i++) { value[i] = 0.0; if (block_type[i] == 4) { block_token.attr[0] = i; schedule(4,0.0,block_token); // block_token.attr[1] = in_q[current_in++]; } } last_time = 0.0; while (sim_time() < end_time) { next_event(event,block_token); if (sim_time()!= last_time) { document.writeln("event value : " + event.value); document.writeln(" Sim Time : " + sim_time()); print(" Last Time : " + last_time); print("current input : " + in_q[current_in]); print("current state : " + current_state); print("block number : " + block_num);

114 102 } } print("================================================"); last_time = sim_time(); } update_block(event,block_token); function update_block(event,block_token) { var i,j; block_num = block_token.attr[0]; switch (event.value) { case 0: gen_func(block_token); break; case 1: tr1_func(block_token); break; case 2: tr2_func(block_token); break; case 3: tr3_func(block_token); break; case 4: s1_func(block_token); break; case 5: s2_func(block_token); break; case 6: s3_func(block_token); break; } for(i=0;i<output_num[block_num];i++) { if(value[block_num] == 1) { block_token.attr[0] = out[block_num][i]; for(j=0; j<input_num[out[block_num][i]]; j++) { block_token.attr[j+1] = value[in1[out[block_num][i]][j]]; } if(value[block_num] == 1) schedule(block_type[out[block_num][i]], delay[out[block_num][i]],block_token); } else if(value[block_num] == 0) { schedule(block_type[block_num], delay[block_num],block_token); } } } function gen_func(block_token) { value[block_num] = value[block_num]+1; schedule(gen,delay[block_num],block_token); } function tr1_func(block_token) { if(block_token.attr[1]==1) { value[block_num] = in_q[++current_in]; } else { value[block_num] = -1; } } function tr2_func(block_token) { if(block_token.attr[1]==1) { value[block_num] = in_q[++current_in]; }

115 103 } else { } value[block_num] = -1; function tr3_func(block_token) { if(block_token.attr[1]==1) { value[block_num] = in_q[++current_in]; } else { value[block_num] = -1; } } function s1_func(block_token) { current_state = "s1"; value[block_num] = 1; } function s2_func(block_token) { current_state = "s2"; value[block_num] = block_token.attr[1]; } function s3_func(block_token) { current_state = "s3"; value[block_num] = block_token.attr[1]; } function read_network() { var i,j,block_num; num_blocks = 7; end_time = 14.0; block_type[0] = 0; block_type[1] = 1; block_type[2] = 2; block_type[3] = 3; block_type[4] = 4; block_type[5] = 5; block_type[6] = 6; delay[0] = 1; delay[1] = 1; delay[2] = 1; delay[3] = 1; delay[4] = 1; delay[5] = 1; delay[6] = 1; input_num[0] = 0; input_num[1] = 1; input_num[2] = 1; input_num[3] = 1; input_num[4] = 0; input_num[5] = 2; input_num[6] = 1; output_num[0] = 0; output_num[1] = 1; output_num[2] = 1; output_num[3] = 1; output_num[4] = 1; output_num[5] = 1; output_num[6] = 1; in1[1][0] = 4; in1[2][0] = 5; in1[3][0] = 6; in1[4][0] = 0; in1[5][0] = 1; in1[6][0] = 2; out[1][0] = 5;

116 104 out[2][0] = 6; out[3][0] = 5; out[4][0] = 1; out[5][0] = 2; out[6][0] = 3; } </script> <script language="javascript"> main(); </script> Execution Result of 3 State FSM - FSM-3S2T.html

117 105 MULTIMODEL Multimodel with 3 Function FBM and 3 State FSM in MXL <?xml version="1.0" encoding="utf-8"?> <MXL xmlns:xsi=" xsi:nonamespaceschemalocation="mxl.xsd"> <model type="fbm"> <topology type="graph"> <node id="f1" type="function"> <script id="f1.js" func="gen_func"/> </node> <node id="f2" type="function"> <model id="fsm3s3t" type="fsm"> <topology type="graph"> <node id="s1" type="state" start="true"> <script id="s1.js" func="s1_func"/> </node> <node id="s2" type="state"> <script id="s2.js" func="s2_func"/> </node> <node id="s3" type="state"> <script id="s3.js" func="s3_func"/> </node> <edge id="t12" type="transition" begin="s1" end="s2" data_type="integer"> <script id="t12.js" func="t12_func"/> </edge> <edge id="t23" type="transition" begin="s2" end="s3" data_type="integer"> <script id="t23.js" func="t23_func"/> </edge> <edge id="t32" type="transition" begin="s3" end="s2" data_type="integer"> <script id="t32.js" func="t32_func"/> </edge> </topology> </model> <script id="f2.js" func="mult_func"/> </node> <node id="f3" type="function"> <script id="f3.js" func="sub_func"/> </node> <edge id="tr12" type="trace" begin="f1" end="f2" data_type="integer"> <script id="tr12.js"/> </edge> <edge id="tr23" type="trace" begin="f2" end="f3" data_type="integer"> <script id="tr23.js"/> </edge> </topology> </model> </MXL>

118 106 Translated Multimodel with 3 Function FBM and 3 State FSM in DXL <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation='"dxl.xsd"'> <block id="f1"> <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"/> <definition id="f1.js" func="gen_func"/> </block> <block id="f2"> <port id="f2.ip1" type="input" source="f1.op1" data_type="integer"/> <port id="f2.op1" type="output" target="f3.ip1" data_type="integer"/> <definition id="f2.js" func="mult_func"/> <block id="in"> <port id="in.op1" type="output" target="s1.ip1" data_type="integer"></port> <definition id="in.js" func="in_func"></definition> </block> <block id="s1"> <port id="s1.ip1" type="input" source="in.op1" data_type="integer"></port> <port id="s1.op1" type="output" target="t12.ip1" data_type="integer"></port> <port id="s1.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="s1.js" func="s1_func"></definition> </block> <block id="s2"> <port id="s2.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="s2.op1" type="output" target="t23.ip1" data_type="integer"></port> <port id="s2.op2" type="output" target="out.ip1" data_type="integer"></port> <port id="s2.ip1" type="input" source="t32.op1" data_type="integer"></port> <definition id="s2.js" func="s2_func"></definition> </block> <block id="s3"> <port id="s3.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="s3.op1" type="output" target="t32.ip1" data_type="integer"></port> <port id="s3.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="s3.js" func="s3_func"></definition> </block> <block id="t12"> <port id="t12.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="t12.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t12.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t12.js" func="t12_func"></definition> </block> <block id="t23"> <port id="t23.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="t23.op1" type="output" target="s3.ip1" data_type="integer"></port> <port id="t23.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t23.js" func="t23_func"></definition> </block> <block id="t32"> <port id="t32.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="t32.op1" type="output" target="s2.ip1" data_type="integer"></port> <port id="t32.op2" type="output" target="out.ip1" data_type="integer"></port> <definition id="t32.js" func="t32_func"></definition> </block> <block id="out"> <port id="out.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="out.ip1" type="input" source="t32.op1" data_type="integer"></port> <definition id="out.js" func="out_func"></definition> </block>

119 107 <connect id="c_in_s1"> <port id="c_in_s1.ip1" type="input" source="in.op1" data_type="integer"></port> <port id="c_in_s1.op1" type="output" target="s1.ip1" data_type="integer"></port> </connect> <connect id="c_s1_t12"> <port id="c_s1_t12.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="c_s1_t12.op1" type="output" target="t12.ip1" data_type="integer"></port> </connect> <connect id="c_t12_s2"> <port id="c_t12_s2.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="c_t12_s2.op1" type="output" target="s2.ip1" data_type="integer"></port> </connect> <connect id="c_s2_t23"> <port id="c_s2_t23.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="c_s2_t23.op1" type="output" target="t23.ip1" data_type="integer"></port> </connect> <connect id="c_t32_s2"> <port id="c_t32_s2.ip1" type="input" source="t32.op1" data_type="integer"></port> <port id="c_t32_s2.op1" type="output" target="s2.ip1" data_type="integer"></port> </connect> <connect id="c_t23_s3"> <port id="c_t23_s3.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="c_t23_s3.op1" type="output" target="s3.ip1" data_type="integer"></port> </connect> <connect id="c_s3_t32"> <port id="c_s3_t32.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="c_s3_t32.op1" type="output" target="t32.ip1" data_type="integer"></port> </connect> <connect id="c_s1_out"> <port id="c_s1_out.ip1" type="input" source="s1.op1" data_type="integer"></port> <port id="c_s1_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_s2_out"> <port id="c_s2_out.ip1" type="input" source="s2.op1" data_type="integer"></port> <port id="c_s2_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_s3_out"> <port id="c_s3_out.ip1" type="input" source="s3.op1" data_type="integer"></port> <port id="c_s3_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t12_out"> <port id="c_t12_out.ip1" type="input" source="t12.op1" data_type="integer"></port> <port id="c_t12_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t23_out"> <port id="c_t23_out.ip1" type="input" source="t23.op1" data_type="integer"></port> <port id="c_t23_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> <connect id="c_t32_out"> <port id="c_t32_out.ip1" type="input" source="t32.op1" data_type="integer"></port> <port id="c_t32_out.op1" type="output" target="out.ip1" data_type="integer"></port> </connect> </block> <block id="f3"> <port id="f3.ip1" type="input" source="f2.op1" data_type="integer"/> <definition id="f3.js" func="sub_func"/> </block> <connect id="tr12"> <port id="tr12.op1" type="input" source="f1.op1" data_type="integer"/> <port id="tr12.ip1" type="output" source="f2.ip1" data_type="integer"/> </connect> <connect id="tr23"> <port id="tr23.op1" type="input" source="f2.op1" data_type="integer"/> <port id="tr23.ip1" type="output" source="f3.ip1" data_type="integer"/> </connect> </DXL>

120 APPENDIX D SOURCE CODES: MODEL FUSION ENGINE, TRANSLATION ENGINE MODEL FUSION ENGINE <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/> <xsl:template match="/"> <!-- *** <X3D> *** --> <X3D></xsl:text> <!-- *** <Scene> *** --> <Scene></xsl:text> <!-- *** Define 'TouchSensor' and 'TimeSensor' *** --> <!-- *** <TouchSensor DEF="Touch" enabled="true"/> *** --> <TouchSensor DEF="Touch" enabled="true"/></xsl:text> <!-- *** <TimeSensor DEF="TS" loop="true" enabled="true" cycleinterval="1.0"/> *** --> <TimeSensor DEF="TS" loop="true" enabled="true" cycleinterval="1.0"/></xsl:text> <!-- *** ####### *** --> <xsl:apply-templates/> <!-- *** </Scene> *** --> </Scene></xsl:text> <!-- *** </X3D> *** --> </X3D></xsl:text> </xsl:template> <!-- *** Create States and Transition Elements *** --> <xsl:template match="mxl"> <!-- *** Create each STATEs with Behaviors *** --> <xsl:for-each select="//node"> <!-- *** <Transform DEF="STATE_S1" translation="0 0 0" scale="1 1 1"/> *** --> <Transform DEF="STATE_</xsl:text><xsl:value-of select="./@id"/> <xsl:text disable-output-escaping="yes">" </xsl:text> <xsl:text disable-output-escaping="yes"> translation="0 0 0" scale="1 1 1"></xsl:text> 108

121 109 <!-- *** <children> *** --> <children> </xsl:text> <!-- *** Copy the Geometry contents of STATE (S#) from the Scene File *** --> <xsl:variable name="curr_state" <!--********************* Element copied from the Scene File *********************--> </xsl:text> <xsl:copy-of select="document('scene.xml')//* <!--*************************************************************************************--> </xsl:text> <!-- *** Create Transform element for the Name of the STATE with Billboard with Translation Value *** --> <!-- *** <Transform translation=" "/> *** --> <Transform translation="</xsl:text> <xsl:value-of select="document('scene.xml')//* <xsl:text disable-output-escaping="yes">"></xsl:text> <!-- *** <children> *** --> <children></xsl:text> <!-- *** <Billboard> *** --> <Billboard></xsl:text> <!-- *** <children> *** --> <children></xsl:text> <!-- *** <Transform > *** --> <Transform translation="-1 1 0"></xsl:text> <!-- *** <children> *** --> <children></xsl:text> <!-- *** <Shape> *** --> <Shape></xsl:text> <!-- *** <geometry> *** --> <geometry></xsl:text> <!-- *** <Text = "S#"> *** --> <Text string = "</xsl:text><xsl:value-of select="./@id"/> <xsl:text disable-output-escaping="yes">"></xsl:text> <!-- *** </Text> *** --> </Text></xsl:text> <!-- *** </geometry> *** --> </geometry></xsl:text> <!-- *** </Shape> *** --> </Shape></xsl:text> <!-- *** </children> *** --> </children></xsl:text> <!-- *** </Transform> *** --> </Transform></xsl:text> <!-- *** </children> *** --> </children></xsl:text> <!-- *** </Billboard> *** --> </Billboard></xsl:text>

122 110 <!-- *** </children> *** --> </children></xsl:text> <!-- *** </Transform> *** --> </Transform></xsl:text> <!-- *** Create the Script Element for the Behavior of the STATE *** --> <!-- *** Later, it will be replaced or inserted with Behavior Libraries from external files. *** --> <xsl:variable name="curr_behavior" <!-- ################# CODE FOR BEHAVIOR: PULSATE ################### --> <xsl:if test="$curr_behavior='pulsate'"> <Script xml:space="preserve" DEF="STATE_</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">"></xsl:text> <![CDATA[ </xsl:text> javascript: </xsl:text> function currstate(value) { </xsl:text> name = value;</xsl:text> } </xsl:text> function currtime(value) { </xsl:text> if (name =='</xsl:text> <xsl:value-of select="./@id"/> '){</xsl:text> if (up) {</xsl:text> t0 = t ;</xsl:text> t1 = t ;</xsl:text> t2 = t ;</xsl:text> newscale[0] = t0;</xsl:text> newscale[1] = t1;</xsl:text> newscale[2] = t2;</xsl:text> } </xsl:text> else {</xsl:text> t0 = t ;</xsl:text> t1 = t ;</xsl:text> t2 = t ;</xsl:text> newscale[0] = t0;</xsl:text>

123 111 newscale[1] = t1;</xsl:text> newscale[2] = t2;</xsl:text> } </xsl:text> if ((t0 > 1.2) (t0 < 0.8)) { </xsl:text> up =!up;</xsl:text> } </xsl:text> } </xsl:text> else {</xsl:text> newscale[0] = 1;</xsl:text> newscale[1] = 1;</xsl:text> newscale[2] = 1;</xsl:text> } </xsl:text> } </xsl:text> ]]> </xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="currtime"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" vrml97hint="eventin"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="currstate"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" vrml97hint="eventin"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="name"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" value="</xsl:text> <xsl:value-of select="./@id"/> " </xsl:text> <xsl:text disable-output-escaping="yes"> vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="up"</xsl:text> <xsl:text disable-output-escaping="yes"> type="boolean" value="true" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t0"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="0.8" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="0.8" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t2"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="0.8" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="newscale"</xsl:text>

124 112 <xsl:text disable-output-escaping="yes"> type="sfvec3f" vrml97hint="eventout"/></xsl:text> </Script></xsl:text> </xsl:if> <!-- ##################################################################### --> <!-- ################# CODE FOR BEHAVIOR: VIBRATE ################### --> <xsl:if test="$curr_behavior='vibrate'"> <Script xml:space="preserve" DEF="STATE_</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">"></xsl:text> <![CDATA[ </xsl:text> javascript: </xsl:text> function currstate(value) { </xsl:text> name = value;</xsl:text> } </xsl:text> function currtime(value) { </xsl:text> if (name =='</xsl:text> <xsl:value-of select="./@id"/> '){</xsl:text> if (up) {</xsl:text> <!-- ############ VIBRATE according to X-axis or Y-axis ########### --> <xsl:variable name="curr_axis" select="//behavior/axis/@id"></xsl:variable> <xsl:if test="$curr_axis='x'"> newscale[0] = t0;</xsl:text> newscale[1] = t ;</xsl:text> newscale[2] = t2;</xsl:text> </xsl:if> <xsl:if test="$curr_axis='y'"> newscale[0] = t ;</xsl:text> newscale[1] = t1;</xsl:text> newscale[2] = t2;</xsl:text> </xsl:if> } </xsl:text> else {</xsl:text>

125 113 <xsl:if test="$curr_axis='x'"> newscale[0] = t0;</xsl:text> newscale[1] = t1-0.1;</xsl:text> newscale[2] = t2;</xsl:text> </xsl:if> <xsl:if test="$curr_axis='y'"> newscale[0] = t0-0.1;</xsl:text> newscale[1] = t1;</xsl:text> newscale[2] = t2;</xsl:text> </xsl:if> <!-- ######################################################### --> } </xsl:text> up =!up;</xsl:text> } </xsl:text> else {</xsl:text> newscale[0] = t0;</xsl:text> newscale[1] = t1;</xsl:text> newscale[2] = t2;</xsl:text> } </xsl:text> } </xsl:text> ]]> </xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="currtime"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" vrml97hint="eventin"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="currstate"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" vrml97hint="eventin"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="name"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" value="</xsl:text> <xsl:value-of select="./@id"/> "</xsl:text> <xsl:text disable-output-escaping="yes"> vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="up"</xsl:text> <xsl:text disable-output-escaping="yes"> type="boolean" value="true" vrml97hint="field"/></xsl:text> <!-- Get the translation value and separate it into three part translation[0], translation[1], translation[2],--> <xsl:variable name="tmp_string" select="document('scene.xml')//* [@DEF=$curr_state]/@translation"/> <xsl:variable name="first_translation_value" select="substring-before($tmp_string, ' ')"></xsl:variable> <xsl:variable name="rest_translation_value" select="substring-after($tmp_string, ' ')"></xsl:variable> <xsl:variable name="second_translation_value" select="substring-before($rest_translation_value, ' ')"></xsl:variable> <xsl:variable name="rest1_translation_value" select="substring-after($rest_translation_value, ' ')"></xsl:variable>

126 114 <xsl:variable name="third_translation_value" select="$rest1_translation_value"></xsl:variable> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t0"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="</xsl:text> <xsl:value-of select="$first_translation_value"/> <xsl:text disable-output-escaping="yes">" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="</xsl:text> <xsl:value-of select="$second_translation_value"/> <xsl:text disable-output-escaping="yes">" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="t2"</xsl:text> <xsl:text disable-output-escaping="yes"> type="float" value="</xsl:text> <xsl:value-of select="$third_translation_value"/> <xsl:text disable-output-escaping="yes">" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="newscale"</xsl:text> <xsl:text disable-output-escaping="yes"> type="sfvec3f" vrml97hint="eventout"/></xsl:text> </Script></xsl:text> </xsl:if> <!-- ##################################################################### --> <!-- *** </children> *** --> </children></xsl:text> <!-- *** </Transform> *** --> </Transform> </xsl:text> </xsl:for-each> <!-- *** Copy the Geometry contents of TRANSITION (T##) from the Geometry File *** --> <xsl:for-each select="//edge"> <!--*********************** Element copied from the Scene File *************************--> </xsl:text> <xsl:variable name="curr_trans" <xsl:copy-of <!--*******************************************************************************************--> </xsl:text> </xsl:for-each> <!-- *** Create Control Script *** --> <Script xml:space="preserve" DEF="Cont"></xsl:text> <![CDATA[</xsl:text>

127 115 javascript:</xsl:text> function initialize() { </xsl:text> activatedstate = '</xsl:text> <xsl:value-of select="//node[@start='true']/@id"/> ';</xsl:text> currstate = '</xsl:text> <xsl:value-of select="//node[@start='true']/@id"/> ';</xsl:text> } </xsl:text> function touched(value, ts) { </xsl:text> <xsl:for-each select="//edge"> <xsl:if test="position()=1"> if (currstate=='</xsl:text> </xsl:if> <xsl:if test="position()!=1"> else if (currstate=='</xsl:text> </xsl:if> <xsl:value-of select="./@begin"/> ') { activatedstate = '</xsl:text> <xsl:value-of select="./@end"/> '; currstate = '</xsl:text> <xsl:value-of select="./@end"/> '; </xsl:text> } </xsl:text> </xsl:for-each> } </xsl:text> ]]></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="touched"</xsl:text> <xsl:text disable-output-escaping="yes"> type="time" vrml97hint="eventin"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="currstate"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" value="</xsl:text> <xsl:value-of select="//node[@start='true']/@id"/> <xsl:text disable-output-escaping="yes">" vrml97hint="field"/></xsl:text> <xsl:text disable-output-escaping="yes"> <field xml:space="preserve" name="activatedstate"</xsl:text> <xsl:text disable-output-escaping="yes"> type="string" vrml97hint="eventout"/> </xsl:text> </Script></xsl:text>

128 116 <!-- *** Create ROUTEs *** --> <xsl:variable name="curr_behavior" <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="touch"</xsl:text> <xsl:text disable-output-escaping="yes"> fromfield="touchtime"</xsl:text> <xsl:text disable-output-escaping="yes"> tonode="cont" tofield="touched"/></xsl:text> <xsl:for-each select="//node"> <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="ts"</xsl:text> <xsl:text disable-output-escaping="yes"> fromfield="fraction_changed"</xsl:text> <xsl:text disable-output-escaping="yes"> tonode="state_</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">" tofield="currtime"/></xsl:text> </xsl:for-each> <!-- ################# CODE FOR BEHAVIOR: PULSATE ################### --> <xsl:if test="$curr_behavior='pulsate'"> <xsl:for-each select="//node"> <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="state_</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">" fromfield="newscale"</xsl:text> <xsl:text disable-output-escaping="yes"> tonode="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">" tofield="scale"/></xsl:text> </xsl:for-each> </xsl:if> <!-- ##################################################################### --> <!-- ################# CODE FOR BEHAVIOR: VIBRATE ################### --> <xsl:if test="$curr_behavior='vibrate'"> <xsl:for-each select="//node"> <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="state_</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">" fromfield="newscale"</xsl:text> <xsl:text disable-output-escaping="yes"> tonode="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">" tofield="translation"/></xsl:text> </xsl:for-each> </xsl:if> <!-- ##################################################################### --> <xsl:for-each select="//node"> <xsl:text disable-output-escaping="yes"> <ROUTE fromnode="cont"</xsl:text> <xsl:text disable-output-escaping="yes"> fromfield="activatedstate"</xsl:text> <xsl:text disable-output-escaping="yes"> tonode="state_</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">_</xsl:text><xsl:value-of select="$curr_behavior"/> <xsl:text disable-output-escaping="yes">" tofield="currstate"/></xsl:text> </xsl:for-each> </xsl:template> </xsl:stylesheet>

129 117 MXL TO DXL MODEL TRANSLATION ENGINE <?xml version="1.0" encoding="utf-8"?> <xsl:stylesheet version="1.0" xmlns:xsl=" <xsl:output method="xml" version="1.0" encoding="utf-8" indent="yes"/> <xsl:template match="/"> <!-- *** <DXL xsi:schemalocation='"dxl.xsd"'> *** --> <!DOCTYPE DXL SYSTEM '"dxl.xsd"'></xsl:text> <DXL></xsl:text> <!-- *** ####### *** --> <xsl:apply-templates/> <!-- *** </DXL> *** --> </DXL></xsl:text> </xsl:template> <!-- *** Create States and Transition Elements *** --> <xsl:template match="mxl"> <!-- *** Process if the Model Type is FSM *** --> <xsl:if <!-- *** Create each BLOCKs *** --> <xsl:for-each select="//node"> <xsl:variable name="curr_node_id" <xsl:variable name="curr_start" <!-- *** If the value of start attribute is 'TRUE', then create <block id="in"> *** --> <xsl:if test="$curr_start='true'"> <xsl:variable name="curr_start_node_id" <block id="in"></xsl:text> <port id="in.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:for-each select="//edge"> <xsl:variable name="icurr_begin" <xsl:variable name="icurr_end" <xsl:variable name="icurr_data_type" <xsl:if test="$curr_node_id=$icurr_begin"> <!-- *** <port id="in.op1" type="output" target="s1.ip1" data_type="integer"></port> *** --> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$icurr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> </xsl:for-each> <definition id="in.js"</xsl:text> func="in_func"></xsl:text> </definition></xsl:text> </block></xsl:text> </xsl:if>

130 118 <!-- *** <block id="s1"> *** --> <block id="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">"></xsl:text> <xsl:for-each select="//edge"> <xsl:variable name="curr_edge_id" <xsl:variable name="curr_begin" <xsl:variable name="curr_end" <xsl:variable name="curr_data_type" <xsl:if test="$curr_node_id=$curr_begin"> <!-- *** <port id="s1.op1" type="output" target="t12.ip1" data_type="integer"></port> *** --> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.op2"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> <xsl:if test="$curr_node_id=$curr_end"> <!-- *** <port id="s1.ip1" type="input" source="t21.op1" data_type="integer"></port> *** --> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <xsl:if test="$curr_start='true'"> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/>.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="in.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> </xsl:if> </xsl:for-each> <definition id="</xsl:text><xsl:value-of "</xsl:text>

131 119 func="</xsl:text> <xsl:value-of "></xsl:text> </definition></xsl:text> </block></xsl:text> </xsl:for-each> <xsl:for-each select="//edge"> <!-- *** <block id="t12"> *** --> <xsl:variable name="curr_edge_id" <xsl:variable name="curr_begin" <xsl:variable name="curr_end" <xsl:variable name="curr_data_type" <block id="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">"></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_begin"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_end"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op2"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <definition id="</xsl:text><xsl:value-of "</xsl:text> func="</xsl:text> <xsl:value-of "></xsl:text> </definition></xsl:text> </block></xsl:text> </xsl:for-each>

132 120 <!-- *** Create <Block id="out"> *** --> <block id="out"></xsl:text> <xsl:for-each select="//node"> <xsl:variable name="curr_node_id" <port id="out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:for-each> <xsl:for-each select="//edge"> <port id="out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:for-each> <definition id="out.js"</xsl:text> func="out_func"></xsl:text> </definition></xsl:text> </block></xsl:text> <!-- *** Create each <connect>s *** --> <xsl:for-each select="//node"> <xsl:variable name="curr_node_id" <!-- *** If the value of start attribute is 'TRUE', then create <connect id="c_in_s1"> *** --> <xsl:if <xsl:variable name="curr_start_node_id" <connect id="c_in_</xsl:text> <xsl:value-of select="$curr_node_id"/> "></xsl:text> <port id="c_in_</xsl:text> <xsl:value-of select="$curr_node_id"/>.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="in.op1"</xsl:text> <xsl:for-each select="//edge"> <xsl:variable name="icurr_begin" <xsl:variable name="icurr_end" <xsl:variable name="icurr_data_type" <xsl:if test="$curr_node_id=$icurr_begin"> <!-- *** <port id="in.op1" type="output" target="s1.ip1" data_type="integer"></port> *** --> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$icurr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> </xsl:for-each>

133 121 <port id="c_in_</xsl:text> <xsl:value-of select="$curr_node_id"/>.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_node_id"/>.ip1"</xsl:text> <xsl:for-each select="//edge"> <xsl:variable name="icurr_begin" <xsl:variable name="icurr_end" <xsl:variable name="icurr_data_type" <xsl:if test="$curr_node_id=$icurr_begin"> <!-- *** <port id="in.op1" type="output" target="s1.ip1" data_type="integer"></port> *** --> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$icurr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> </xsl:for-each> </connect></xsl:text> </xsl:if> <!-- *** <connect id="c_s1_t12"> *** --> <xsl:for-each select="//edge"> <xsl:variable name="curr_edge_id" <xsl:variable name="curr_begin" <xsl:variable name="curr_end" <xsl:variable name="curr_data_type" <xsl:if test="$curr_node_id=$curr_begin"> <!-- *** <connect id="c_s1_t12"> *** --> <!-- *** <port id="c_s1_t12.ip1" type="input" source="s1.op1" data_type="integer"></port> *** --> <!-- *** <port id="c_s1_t12.op1" type="output" target="t12.ip1" data_type="integer"></port> *** --> <connect id="c_</xsl:text> <xsl:value-of select="$curr_node_id"/> _</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></xsl:text> <port id="c_</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="c_</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text>

134 122 <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </connect></xsl:text> </xsl:if> <xsl:if test="$curr_node_id=$curr_end"> <!-- *** <connect id="c_t21_s1"> *** --> <!-- *** <port id="c_t21_s1.ip1" type="input" source="t21.op1" data_type="integer"></port> *** --> <!-- *** <port id="c_t21_s1.op1" type="output" target="s1.ip1" data_type="integer"></port> *** --> <connect id="c_</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">_</xsl:text> <xsl:value-of select="$curr_node_id"/> "></xsl:text> <port id="c_</xsl:text> <xsl:value-of select="$curr_edge_id"/> _</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="c_</xsl:text> <xsl:value-of select="$curr_edge_id"/> _</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </connect></xsl:text> </xsl:if> </xsl:for-each> </xsl:for-each> <!-- *** Create <connect id="c_s1_out"> *** --> <xsl:for-each select="//node"> <connect id="c_</xsl:text> <xsl:value-of _OUT"></xsl:text> <port id="c_</xsl:text> <xsl:value-of

135 123 _OUT.IP1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="c_</xsl:text> <xsl:value-of _OUT.OP1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:text disable-output-escaping="yes">out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> </connect></xsl:text> </xsl:for-each> <xsl:for-each select="//edge"> <connect id="c_</xsl:text> <xsl:value-of _OUT"></xsl:text> <port id="c_</xsl:text> <xsl:value-of _OUT.IP1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="c_</xsl:text> <xsl:value-of _OUT.OP1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:text disable-output-escaping="yes">out.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of <xsl:text disable-output-escaping="yes">"></port></xsl:text> </connect></xsl:text> </xsl:for-each> </xsl:if> <!-- *** End of Process if the Model Type is FSM *** -->

136 124 <!-- *** Process if the Model Type is FBM *** --> <xsl:if <!-- *** Create each BLOCKs *** --> <xsl:for-each select="//node"> <!-- *** <block id="f1"> *** --> <xsl:variable name="curr_node_id" <block id="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">"></xsl:text> <xsl:for-each select="//edge"> <xsl:variable name="curr_begin" <xsl:variable name="curr_end" <xsl:variable name="curr_data_type" <xsl:if test="$curr_node_id=$curr_begin"> <!-- *** <port id="f1.op1" type="output" target="f2.ip1" data_type="integer"></port> *** --> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> target="</xsl:text> <xsl:value-of select="$curr_end"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> <xsl:if test="$curr_node_id=$curr_end"> <!-- *** <port id="f2.ip1" type="input" target="f1.op1" data_type="integer"></port> *** --> <port id="</xsl:text> <xsl:value-of select="$curr_node_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_begin"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </xsl:if> </xsl:for-each> <definition id="</xsl:text><xsl:value-of "</xsl:text> func="</xsl:text> <xsl:value-of "></xsl:text> </definition></xsl:text> </block></xsl:text> </xsl:for-each>

137 125 <xsl:for-each select="//edge"> <!-- *** <block id="tr12"> *** --> <xsl:variable name="curr_edge_id" <xsl:variable name="curr_begin" <xsl:variable name="curr_end" <xsl:variable name="curr_data_type" <connect id="</xsl:text><xsl:value-of <xsl:text disable-output-escaping="yes">"></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="input"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_begin"/> <xsl:text disable-output-escaping="yes">.op1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> <port id="</xsl:text> <xsl:value-of select="$curr_edge_id"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> type="output"</xsl:text> <xsl:text disable-output-escaping="yes"> source="</xsl:text> <xsl:value-of select="$curr_end"/> <xsl:text disable-output-escaping="yes">.ip1"</xsl:text> <xsl:text disable-output-escaping="yes"> data_type="</xsl:text> <xsl:value-of select="$curr_data_type"/> <xsl:text disable-output-escaping="yes">"></port></xsl:text> </connect></xsl:text> </xsl:for-each> </xsl:if> <!-- *** End of Process if the Model Type is FBM *** --> </xsl:template> </xsl:stylesheet>

138 APPENDIX E DYNAMIC MODEL EXAMPLES FSM Five state FMS created by Noa et al. Five groups of objects, including the MCP (Master Control Program), the I/O tower, and two towers from "Tron", represent each state of an elevator. Each object has its own animation to represent the current state. A transition from one state to another state is represented by a moving solar sailor 126

139 127 FBM The FBM example created by Park et al. It models and simulates a mathematical equation, the spiral of Cornu, using a functional block model. As time changes, x and y values are generated by integrating the cosine and sine values. These generated x and y values are fed into the next block, the 3D Virtual Plotter, where the actual 3D graph is drawn by the moving arm. Also, generated x and y values are drawn on the black board.