A Dynamic Exchange Language layer for RUBE

Size: px

Start display at page:

Download "A Dynamic Exchange Language layer for RUBE"

Derrick Malone
5 years ago
Views:

1 A Dynamic Exchange Language layer for RUBE Jinho Lee a and Paul Fishwick a a Department of Computer and Information Science Engineering, University of Florida Gainesville, Florida, USA ABSTRACT There exist various model types to represent dynamic systems but they aren t generally reused for new modeling methods. The DXL (Dynamic exchange Language) represents system using a simple block diagram defined by XML (extensible Markup Language), where each block has codes for either JavaScript or Java. The DXL were designed for being parsed from various existing models represented by MXL (Multimodel exchange Language), and plays a role of basic unit layer for simulating and modeling in the rube. Models denoted by this DXL are produced to actual simulation codes used in rube through a translator using DOM (Document Object Model). These simulation codes use a SimpackJ/S toolkit as a target library for simulation. Keywords: rube, XML, XSLT, MXL, DXL,, functional modeling, modeling, simulation 1. INTRODUCTION DXL and MXL are modeling languages used for representing models in the rube architecture 6, 7. DXL is a modeling language representing a system using a simple block diagram, which is encoded in XML for web-based modeling and simulation. A MXL is an XML-based modeling language defined for representing a dynamic model such as FSM (Finite State Machine) and FBM (Functional Block Model). MXL models can be easily translated into a simple block diagram of DXL through XSLT 13 (Extensible Stylesheet Language Transformation) because both MXL and DXL are XML 11 dialects. XML, a standard of data representation in web environments, provides applicability and compatibility to other web-based modeling languages, especially in XML-based modeling languages. A simulation target code, a JavaScript or Java code having popularity in a web environment, could provide language-based supports for a web-based simulation. In a previous version of rube, MXL models such as FSM and FBM were directly translated into code based on X3D. It was inconvenient to make translation codes individually producing the 3D modeling code from each MXL model. DXL is designed for supporting the function that becomes basic units of a SimPackJ/S simulation code. Functional blocks of DXL are simple and small sized functions. A model for system consists of these simple blocks and is simulated by an event-based scheduling method, which regards these simple blocks as units of the simulation. Likewise an assembly language plays a role of a target code for other programming languages, the compactness of DXL helps to play a role of a target model for other model types. DXL provides independence between various model types and their simulation codes referencing a SimPackJ/S toolkit 8. So, modelers can concentrate on modeling in the human-model interface of rube architecture. There are other models that are based on functional model networks such as Modelica 9, Simulink 10, and MoML 3. Modelica is an object-oriented language for modeling engineering system of industry. It supports a low-level assembly block similar to a Simple block in DXL. Simulink is a commercial system offering a functional based modeling. Modelica and Simulink are good toolkits but don t support an XML-based encoding. In the other hand, MoML is an XML-based block model and supports multimodeling for PtolemyII 4, but doesn t provide generalized system dynamics. First, we will define the conceptual and structural features of DXL in section 2. And then, in section 3, we will describe the relation between DXL and SimPackJ/S. 2. THE CONCEPTUAL AND STRUCTURAL FEATURES OF DXL A DXL model has a conceptual feature that contributes to dynamic modeling for system with other components in rube architecture. Also, it has a structural feature that is deeply related to the structure of a simulation code. The conceptual feature represents relations to other rube components, especially MXL and a SimPackJ/S toolkit. As the structural

2 feature, a DXL model is composed of five varieties of elements such as DXL, block, connect, port, and definition elements. 2.1 Concept A simple XML schema for a web-based modeling and simulation defines DXL. It is compatible to other rube components such as MXL and X3D, which are also defined by XML for easiness of translation and usability of a XML toolkit, XSLT. DXL plays a 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 2. In rube architecture, XML toolkits like XSLT and DOM 5 (Document Object Model) are used. Models represented by DXL are produced from MXL models by using XSLT and produce actual simulation codes by using DOM like in Figure 1. Simulation MXL DXL SimPackJ/S Code XSLT DOM Figure 1: The role of DXL in rube architecture DXL used in rube architecture has the following features. Web-based simulation: DXL is denoted by XML, which provides a standard notation for syntax of web-based documents or data. Because XML is designed for a web-based dialect, our DXL can be easily applied to other web technologies and be compatible to other web-based modeling languages. In addition, output simulation codes for which are JavaScript or Java can provide certainly language specific supports for a web-based simulation resulting from features of JavaScript and Java used generally in a current web world. Semi-automated generator for simulation code: DXL models are translated into actual simulation codes for JavaScript or Java through a translator using DOM. This translator is a semi-automated code generator required to be input by users for each simple block. Because a DXL model is composed of simple blocks, a DXL block diagram for system might be complex. This semi-automated code generator can supplement the complication of DXL consisting of simple blocks. Model assembly layer: An assembly language in programming languages becomes a target code from the point of view of their compilers and is translated into a machine code to execute the program. Likewise DXL becomes a target model through XSLT and is translated into a specific programming language (in our rube architecture, JavaScript or Java) to simulate the model. This role of DXL supporting independence between various model types defined by MXL and actual simulation codes denoted by JavaScript or Java help modelers to concentrate on modeling except for simulation in the human-model interface of rube architecture. input port output port block connect Figure 2: A basic DXL diagram and its elements A conceptual role of DXL in rube architecture is described in Figure 2. Basic elements of DXL are block, connect, and port. Block elements that are basic units in DXL are connected by each connect element through input and output ports. Input and output ports can be located in a block element and each port is connected to the corresponding output and input port of other block for its data flow, which a connect element controls.

3 2.2 Structure Figure 3 describes the structure of DXL using a simple XML Schema 12, which provides a means for defining the structure, content and semantics of XML documents. Element block has port and definition element as subelements. Element connect has port element as a sub-element. And port element has id, type, source, and target attributes. <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="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 name="definition"> </xsd:sequence> </xsd:complextype> <xsd:element name="connect"> <xsd:complextype> <xsd:sequence> <xsd:element name="port"> <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:sequence> </xsd:complextype> </xsd:complextype> </xsd:schema> Figure 3: An XML schema for DXL DXL Element A DXL element represents an individual DXL model parsed from MXL using XSLT. The name of a DXL model is referenced by attribute id in the DXL element. <DXL id= simple model > </DXL> Block Element A DXL element is composed of block elements that are basic components. These block elements become not only simple elements of a DXL element but also basic units of actual simulation codes used in an event-based scheduling mentioned later. An attribute of block element, id, should be unique for connecting blocks using these identifiers. In the following example, a DXL element, simple model, has three block elements such as B1, B2, and B3. <DXL id= simple model > <block id= B1 > <block id= B2 >

4 <block id= B3 > </DXL> Connect Element An element connect connects a source port and a target port that are declared using an attribute source and target. It plays a role of a similar channel to a communication path and could have types and queues for implementing a queuing model. An attribute source and target have string values in a source port and a target port of this connect element. Generally, an output port of source block becomes a source port of connect element. And an input port of a target block becomes a target port of a connect element. In Figure 4, an attribute source of a connect element, TR1, is B1.OP1 that is an output port of its source block, B1, and an attribute target of TR2 is B2.OP1 that is an input port of its target block, B2. Figure 4 describes TR1 connect element that connects block B1 with B2, and TR2 connect element that connects block B2 with B3. <connect id="tr1"> <port id="tr1.op1" type="input" source="b1.op1"> <port id="tr1.ip1" type="output" target="b2.ip1"> </connect> <connect id="tr2"> <port id="tr2.op1" type="input" source="b2.op1"> <port id="tr2.ip1" type="output" target="b3.ip1"> </connect> TR1 TR1 B1 B2 B3 Figure 4: A diagram for connect elements Port Element An element port is included in a block or connect element that is a component of a DXL element. It has four attributes such as id, type, source, and target attributes. An attribute id represents its port name and an attribute type has INPUT or OUTPUT as string values, that means that these ports play a role of input or output in the block. The following example is a DXL code for input and output ports of a block B2 in Figure 5. B2.IP1, input port of block B2, is connected starting from B1.OP1, output port of block B1. <block id="b2"> <port id="b2.ip1" type="input" source="b1.op1"> <port id="b2.op1" type="output" target="b3.ip1"> B1 B2 B3 Figure 5: A diagram for a simple port element Blocks having multiple input and output ports are described in Figure 6. In the Figure 6, a block B3 has total four ports that are two input and two output ports. Two input ports of the block B3 are sourced from output ports of a block B1 and B2. Two output ports of the block B3 are connected to input ports of a block B4 and B5. Multiple sources to input ports of a block means an aggregation of data and controls to the block. On the other hand, multiple targets from output ports of a block means a distribution of data and controls from the block.

5 <block id="b3"> <port id="b3.ip1" type="input" source="b1.op1"> <port id="b3.ip2" type="input" source="b2.op1"> <port id="b3.op1" type="output" target="b4.ip1"> <port id="b3.op2" type="output" target="b5.ip1"> B1 B4 B3 B2 B4 Figure 6: A diagram for multiple port elements Definition Element In a definition element, JavaScript codes are specified using their filename. Each JavaScript code is composed of functions. A called function is referenced by an attribute func. In this example, the JavaScript file containing functions is assigned as a string value in its attribute id. In Figure 7, each block B1, B2, and B3 have a B1.js, B2.js, and B3.js file. <block id="b1"> <port id="b1.op1" type="output" target="b2.ip1"> <definition id="b1.js" func="test1"></definition> <block id="b2"> <port id="b2.ip1" type="input" source="b1.op1"> <port id="b2.op1" type="output" target="b3.ip1"> <definition id="b2.js" func="test2"></definition> <block id="b3"> <port id="b3.ip1" type="input" source="b2.op1"> <definition id="b2.js" func="test3"></definition> B1 B2 B3 B1.js B2.js B3.js Figure 7: A diagram for a definition element 3. THE RELATION BETWEEN DXL AND SIMPACKJ/S 3.1 Event-based scheduling An event scheduling is defined as the following, Event scheduling is defined as executing code that contains an event loop where events are posted and then checked according to minimum time. 1 An output translated from DXL using DOM is structurally a simulation code using an event-based scheduling method. The simulation program has a single event loop for scheduling DXL blocks on a future event list according to their event times. After executing a block, target blocks outgoing from that block are yielded as new events. Those events are scheduled on a future event list.

6 Future Event List next_event Schedule new events Block 1 Block 2 Block 3 Block n Yields new New event New event Figure 8: An event scheduling on which simulation codes are based An event scheduling on which simulation code is based is described in Figure8. An event having the smallest time on the future event list is executed. Each event is a block having a JavaScript code in a definition element of a DXL model. Calling next_event method provided by a SimPackJ/S toolkit can get the events having the earliest time. According to each event, the corresponding function, which is a block of a DXL model, is called. After the function is called, the output blocks of the block of the function become new events. A translator using DOM can see the output blocks by finding blocks having input ports connected to output ports of the block. The output blocks can be scheduled by calling schedule method provided by a SimPackJ/s toolkit. 3.2 Event-based scheduling code produced by a translator using DOM Figure 9 is a content of a DXL file for Figure 7 and parts of a simulation code for JavaScript translated from it. The left side of Figure 9 is a DXL code having a block B1, B2, and B3. A B1 block is a function gen_func that generates a random number every delay time. A B2 block is a function mult_func that multiplies an input value and returns the result. A B3 block is a function sub_func that minus an input value and returns the result. Each block has a function name to be called in a func attribute in a definition element. The right side of Figure9 is a simulation code for JavaScript produced from the DXL file of the left side of Figure 9 through a translator using DOM. In the right side of the figure, the function names are called in a switch statement in an update function, which is called in a while statement of a main function. After simple block functions are called, a schedule method is called to schedule new events like the right side of the figure. The for loop is needed to produce new events because a block can produce not only one new event but also multiple new events. 4. CONCLUSIONS We designed DXL to serve as an assembly layer for MXL, since translating MXL directly into executable code turned out to be somewhat complex. DXL is compact, having only blocks and simple connections, with ports for interfacing blocks. Thus, DXL plays a role similar to bytecode for Java, or assembly languages for compiled languages. The use of SimPackJ/S provides our code, based on DOM, with a flexible API for achieving discrete event operations such as scheduling and future event list updating. Modeling a complex system is required to incorporate various model methods providing its characteristic view of each model type. One solution for modeling a complex system is a multimodeling. We don t have multimodeling in a current DXL but plans to support multimodeling in a future DXL. Also, we will support processing of an XML data stream in a future DXL. In other words, each block can operate on an XML input stream and produce an XML output.

7 This means a model itself can be processed as a parameter of blocks in DXL. Such a parameterization of a model becomes an important factor in dynamic modification of the model. So, this modifiability at run time may provide more realistic system dynamics because it supports a more efficient method to represent dynamic behavior of system like a self-modified system. <?xml version="1.0" encoding="utf-8"?> <DXL xsi:schemalocation="dxl.xsd"> <block id="b1"> <port id="b1.op1" type="output" target="b2.ip1"> <definition id="b1.js" func="gen_func"> </definition> <block id="b2"> <port id="b2.ip1" type="input" source="b1.op1"> <port id="b2.op1" type="output" target="b3.ip1"> <definition id="b2.js" func="mult_func"> </definition> 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]; <block id="b3"> <port id="b3.ip1" type="input" source="b2.op1"> <definition id="b3.js" func="sub_func"> </definition> <connect id="tr1"> <port id="tr1.op1" type="input" source="b1.op1"> <port id="tr1.ip1" type="output" target="b2.ip1"> </connect> <connect id="tr2"> <port id="tr2.op1" type="input" source="b2.op1"> <port id="tr2.ip1" type="output" target="b3.ip1"> </connect> </DXL> 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); Figure 9: A DXL file and the corresponding output simulation code ACKNOWLEDGEMENT We would like to thank the National Science Foundation under grant EIA and the Air Force Research Laboratory under grant F for their sponsorship of the rube methodology and the DXL. We would also like to thank Taewoo Kim, and Minho Park for their work on the model fusion engine and SimPackJS. REFERENCES 1. P.A. Fishwick, Simulation Model Design and Execution: Building Digital Worlds, Prentice-Hall, P.A. Fishwick, Simpack: Getting Started with Simulation Programming in C and C++, In 1992 Winter Simulation Conference, pages , Arlington, VA, December E. A. Lee and S. Neuendorffer, MoML A Modeling Markup Language in XML, Technical Memorandum ERL/UCB M 00/12, March E. A. Lee, Overview of the Ptolemy Project, Technical Memorandum UCB/ERL M01/11, University of California, Berkeley, March 6, DOM (Document Object Model), 6. T. Kim and P. A. Fishwick, An XML-Based 3D Model Visualization and Simulation Framework for Dynamic Models, SPIE, (Orlando, FL), April T. Kim and P. A. Fishwick, A 3D XML-Based Customized Framework for Dynamic Models, 2002 Web3D Conference, Tempe, AZ, February M. Park and P. A. Fishwick, SimPackJ/S: A Web-Oriented Toolkit for Discrete Event Simulation, SPIE, (Orlando, FL), April 2002.

8 9. M. Tiller, Introduction to Physical Modeling with Modelica, Kluwer Academic, Simulink, XML (Extensible Markup Language), XML Schema, XSLT (Extensible Stylesheet Language Transformations),

RUBE: A CUSTOMIZED 2D AND 3D MODELING FRAMEWORK FOR SIMULATION. Paul Fishwick Jinho Lee Minho Park Hyunju Shim

Proceedings of the 2003 Winter Simulation Conference S. Chick, P. J. Sánchez, D. Ferrin, and D. J. Morrice, eds. RUBE: A CUSTOMIZED 2D AND 3D MODELING FRAMEWORK FOR SIMULATION Paul Fishwick Jinho Lee Minho