Online design of Matlab/Simulink and SciLab/Xcos block schemes

Transcription

1 Online design of Matlab/Simulink and SciLab/Xcos block schemes Zoltán Janík and Katarína Ţáková Institute of Control and Industrial Informatics FEI STU Bratislava, Slovakia Abstract The paper presents a new tool that supports building of online simulation schemes for online laboratories. The structure of schemes is compatible with Matlab /Simulink or SciLab/Xcos environment. The paper is also dedicated to the comparison of both considered environments and to the pointing out differences and similarities of their use. Keywords-computer aided engineering, control design, online services, student experiments I. INTRODUCTION Online laboratories (see e.g. [3], [6], [11], [12], [14], [15]) are slowly going to be a part of Engineering studies. In comparison with hands-on laboratories they try to offer students better interactivity with experiments. Of course, they cannot substitute the real contact of student with the device at the university but they can offer the same results from measurements and online experiments. Enabling change of parameters or even of the whole control structure improves the understanding of presented topics. There are several ways how online experiments can be designed and built. One of them uses background support of standard numerical software that enables to solve all numerical calculations needed for running experiments. In [3] and [5] we presented the web based tool that enables to build block schemes for later use in online experiments. We devoted our attention to two background software environments proprietary product Matlab that is widely used at technical universities and SciLab that represents its free and open source alternative. Both products include user interfaces (Simulink for Matlab and Xcos for SciLab) that allow building a control structure in a graphical way by simple drag and drop method. The small comparison of basic facts about both environments is introduced in Table I. We do not compare a functionality of software because the calculations that we usually need to accomplish within our online experiments can be done in both products. Following two sections describe structure of ascii files that contain information about the block scheme composition both in Matlab/Simulink and SciLab/Xcos environment. Next sections are devoted to the description of front-end, back-end and configuration of the developed online tool whereby the special attention is given to the differences between both solutions. II. MATLAB AND SIMULINK A. Introduction to Matlab and Simulink Matlab is an interactive environment for performing computationally intensive tasks faster than with traditional programming languages. It was first released in 1984 by MathWorks, Inc. The latest version 2011a was released in April MathWorks offers also an environment for modeling and simulation of dynamic and embedded systems named Simulink. Price for commercial license for Simulink is 3150 USD. However, it requires at least Simulink Fixed Point component (1000 USD) and Matlab (2100 USD). Basic price of student license (Matlab + Simulink ) starts at 99 USD. B. Structure of MDL file Schemes created in Simulink are stored in plain text files with.mdl extension. MDLs are easy-to-read for human. The structure of file consists of key-value pairs, while the key is a name of an attribute and the value may be single string or numeric value, vector, matrix or a composite value with one or more nested key-value pairs. TABLE I. COMPARISON OF MATLAB /SIMULINK AND SCILAB/XCOS Matlab / Simulink SciLab / Xcos License Proprietary GPL compatible Latest version R2011a Latest version release Standard price Available in OS April 2011 July USD (Matlab ) 4150USD (Simulink ) 99USD (Matlab + Simulink for students) Windows, Linux, Mac Free Windows, Linux, Mac Scheme format JSON-like plain text Valid XML Page 241

2 Model { Name "Template" Version 7.0 MdlSubVersion 0 GraphicalInterface { NumRootInports 0 NumRootOutports 0 ParameterArgumentNames "" ComputedModelVersion "1.2" NumModelReferences 0 NumTestPointedSignals 0 SavedCharacterEncoding "windows-1250" SaveDefaultBlockParams on Created "Sun Jul 28 23:59: " Creator "Z2" LastModifiedBy "Z2" LastModifiedDate "Mon Jul 29 15:37: " Figure 1. Example of MDL file structure The attribute name is always a single word without spaces followed by one or more spaces and/or tabs (to achieve aligned columns see Fig.1). As mentioned earlier in this section, attribute value may be present in these forms: numeric any integer or float number boolean possible values: on, off string zero or more characters enclosed in quotes vector or matrix standard Matlab notation (e.g. [1, 2, 3] or [1, 2, 3; 4, 5, 6]) composite key-value pairs enclosed in curly brackets The whole structure of MDL files resembles the JSON 1 format (compare Fig.2 and Fig.3) introduced by Douglas Crockford in 2002 and standardized by RFC 4627 in July The JSON is widely used by web applications as a lightweight standard for data exchange. While in valid JSON, each attribute name must be wrapped in double quotes followed by a colon; there are no quotes, nor colon in the MDL format. In addition, attribute/name pairs in MDL are not commaseparated as they are in JSON. Simulink s MDL files have one feature that is missing in JSON, which is ability to use matrices written in the same format as in Matlab. JSON contains only arrays that are similar to Matlab s vectors. More information about JSON is available on official website [1]. An MDL file contains a plenty of data but we are not interested in all of them. For our needs we take into consideration only the name of a scheme, time and date of creation and last modification of the scheme and authors (these parts are marked with bold font in Fig.1). Except of mentioned metadata, an MDL file contains 2 important parts that describe the whole scheme. The first one, labeled as BlockParameterDefaults, contains a list of block types that appears in the scheme with a list of parameters used as default values for each block type. These values are taken into account if the block in a scheme lacks specification of certain parameter value. System { Name "Template" Location [480, 93, 1016, 386] Block { BlockType Constant Name "Constant" Position [140, 174, 210, 196] ShowName off Value "1" OutDataType "sfix(16)" OutScaling "2^0" Block { Figure 2. Constant block in MDL format "System": { "Name": "Template", "Location": [480, 93, 1016, 386], "Block": {, "BlockType": "Constant", "Name": "Constant", "Position": [140, 174, 210, 196], "ShowName": false, "Value": "1", "OutDataType": "sfix(16)", "OutScaling": "2^0" "Block": { Figure 3. Example of valid JSON structure The second and the most important part of an MDL file is labeled as System. This part contains complete list of blocks and connections that appear in the scheme. Names of blocks are used as a unique identifier. List of parameters (bold in Fig.2) is specified directly inside Block attribute after specification of block type, name, location and other similar properties. It contains only parameters with values other than default. A connection is specified with the name of source and destination block and number of source and destination port. The shape depends on coordinates of points that the connection passes through. Coordinates are relative to the exact location of source port and they are noted as a matrix near Points keyword. In case of more complex connections with nodes, the Branch keywords define multiple destination blocks. For an example of such connection, see Fig.4 and Fig.5. Figure 4. Sample branched connection 1 JavaScript Object Notation Page 242

3 Line { Labels [2, 0] SrcBlock "Integrator" SrcPort 1 Points [65, 0; 0, 55; 25, 0] Branch { DstBlock "Derivative" DstPort 1 Branch { Points [0, 190] DstBlock "Saturation" DstPort 1 Figure 5. Branched connection in MDL format from Integrator block to both Derivative and Saturation III. SCILAB AND XCOS A. Introduction to SciLab and Xcos SciLab is free software for numerical computation distributed under GPL-compatible license. It was created in 1990 by INRIA (National Institute for Research in Computer Science and Control in France) and ENPC (École nationale des ponts et chaussées). Nowadays, SciLab is being developed by Digiteo Foundation. Graphical editor to design hybrid dynamical systems models - Xcos (previously SciCos) is distributed together with SciLab. Xcos environment enables running simulations of complex continuous and discrete systems. The whole software package is free of charge and it comes also with source codes. B. Structure of Xcos file Xcos schemes are saved as a valid XML document with.xcos extension. This format is stricter than plain text and it is less prone to errors and ambiguities. Xcos files contain far less metadata than MDL files. There is no information about author or time of modification of the scheme. The dominant part of an Xcos file is description of the block scheme. Compared to Simulink, there is no need to distinguish between string, numeric or boolean data types, because in XML, they are always noted in the same form (e.g. strings are not enclosed inside quotes, the same as numeric values). In addition, there is no need to define vectors, arrays or composite attribute values, because they are represented with nested XML tags. Each element in a scheme (block, connection) has its own unique identifier that consists of 3 hexadecimal numbers separated by colons (attribute id see Fig.6). Blocks are specified mostly inside BasicBlock or ConstBlock parent tags. However, one can also meet blocks with more complex names e.g. org.scilab.modules.xcos.block.io.explicitinblock for Input block. Block parameters are stored inside the parent tags, but the structure may vary depending on each block type. In Fig.6 it is possible to see an example of a constant block. It is to note that Xcos stores some values in multiple locations. The number of locations depends on the block type. In this block, the constant value is defined at 2 locations marked with bold font (attribute value= 1 ). <XcosDiagram background="-1" modified="1" title="template"> <mxgraphmodel as="model"> <root> <ConstBlock blocktype="d" id=" d5:12c53c4cc03:-7fdc" interfacefunctionname="const_m" parent=" d5:12c53c4cc03:-8000" simulationfunctionname="cstblk4" simulationfunctiontype="c_or_fortran" style="mirror=false;rotation=0;const_m;flip=false;" value="1"> <ScilabString as="exprs" height="1" width="1"> <data column="0" line="0" value="1"/> </ScilabString> <ScilabDouble as="realparameters" height="0" width="0"/> </ConstBlock> Figure 6. Constant block in Xcos format A connection between two blocks is specified inside ExplicitLink tag that contains a list of points (their coordinates) defining the connection s shape (inside mxgeometry tag bold text in Fig.7). Coordinates are relative to top left corner of the document. ExplicitLink contains also the source (output) and the destination (input) port of two connected blocks. A branched connection similar to one in Fig.4 is split into 3 simple connections: from integrator to node (split block see the black filled circle in Fig.4) and from node to both derivative and saturation as demonstrated in Fig.7. IV. FRONT-END The front-end of the application is demonstrated in Fig 8. Our aim was to prepare a design that would be familiar for users using Matlab /Simulink or SciLab/Xcos environment. The web editor is based on XHTML, CSS 2 and JavaScript language. These technologies were selected in order to ensure the widest availability of this tool. The only requirement on client s side is compatible web browser (Internet Explorer 8+, Mozilla Firefox 2+, Safari 3+, Opera 9+, Google Chrome). For more detailed information, refer to [3]. V. BACK-END The back-end and front-end part of the application communicate through AJAX 3 requests that enable data exchange without reloading the whole web page with the editor. Back-end server is used for running scripts written in PHP language that perform tasks such as import and export to MDL, Xcos or raw scheme format stored as an XML document. In fact, the Xcos file has the same structure as standard XML file (see Fig.6). This format makes handling of Xcos files very simple. On the other hand, MDL files use nonstandard format that requires additional pre-processing. The advantage is that MDL files have plain text format very similar to JSON and therefore this task is quite easy to be achieved. 2 Cascading Style Sheets 3 Asynchronous JavaScript and XML Page 243

4 <!-- Integrator to split block --> <ExplicitLink id="-142ebf92:13127d3897a:-7fd2" style="explicitlink;elbow=horizontal"> <mxgeometry as="geometry" height="80.0" width="80.0"> <Array as="points" scilabclass="arraylist"> <mxpoint x="65.0" y="0.0"/> <mxpoint x="65.0" y="55.0"/> </Array> </mxgeometry> <ExplicitOutputPort as="source" id="-142ebf92:13127d3897a:-7fe8" parent="-142ebf92:13127d3897a:-7fe7" > </ExplicitOutputPort> <ExplicitInputPort as="target" id="-142ebf92:13127d3897a:-7fd6" parent="-142ebf92:13127d3897a:-7ff0" > </ExplicitInputPort> </ExplicitLink> <!-- Split block to Derivative --> <ExplicitLink id="-142ebf92:13127d3897a:-7fd1"> <ExplicitOutputPort as="source" id="-142ebf92:13127d3897a:-7fd5" parent="-142ebf92:13127d3897a:-7ff0" > </ExplicitOutputPort> <ExplicitInputPort as="target" id="-142ebf92:13127d3897a:-7fe1" parent="-142ebf92:13127d3897a:-7fdf" > </ExplicitInputPort> </ExplicitLink> <!-- Split block to Saturation --> <ExplicitLink id="-142ebf92:13127d3897a:-7fd0" style="explicitlink;edgestyle=elbowedgestyle;elbow=horizontal"> <mxgeometry as="geometry" height="80.0" width="80.0"> <Array as="points" scilabclass="arraylist"> <mxpoint x="90.0" y="245.0"/> </Array> </mxgeometry> <ExplicitOutputPort as="source" id="-142ebf92:13127d3897a:-7fd4" parent="-142ebf92:13127d3897a:-7ff0" > </ExplicitOutputPort> <ExplicitInputPort as="target" id="-142ebf92:13127d3897a:-7fe5" parent="-142ebf92:13127d3897a:-7fe3" > </ExplicitInputPort> </ExplicitLink> Figure 7. Replacement of branched connection in Xcos format Figure 8. Web editor interface The web editor provides independent format to store block schemes built by the user. The structure of this format is very compact because it contains only the most necessary information about the scheme, i.e. blocks, connections between blocks and their parameters. Compared to the other two formats (MDL, Xcos), this raw scheme format omits information about software-specific metadata such as simulation parameters, graphical information of document (e.g. paper size, margins, etc.) and any other data that are not directly related to the scheme. An example of this scheme format can be seen in Fig.9. Unfortunately, MDL and Xcos formats are not compatible with each other, thus it is not possible to convert MDL files to Xcos and vice versa in a quite easy and comfortable way. Neither the presented online editor in its current stage of development can help in this direction. This is caused mainly because of different number and types of parameters for corresponding blocks in Simulink and in Xcos (e.g. integrator block in Simulink has far more parameters than in Xcos). The conversion between these two formats would require additional mapping to define matched parameters. In addition, some parameter values would get lost during conversion if they were not present in target scheme format. However, one-way import from MDL format is still available directly in SciLab s Xcos environment. A. Export The export process is done in four basic steps. First, the scheme in web editor is sent to back-end server. The editor and back-end communicate via AJAX requests using JSON as data exchange format. This procedure is the same for both Xcos and MDL formats. <scheme> <blocks> <block id="b_0"> <type>constant</type> <name>constant</name> <position x="140" y="174"/> <version>0</version> <attributes> <attribute id="showname">off</attribute> <attribute id="value">1</attribute> <attribute id="outdatatype">sfix(16)</attribute> <attribute id="outscaling">2^0</attribute> </attributes> </block> <block id="b_1"> <type>display</type> <name>display</name> <position x="140" y="232"/> <version>0</version> <attributes> <attribute id="format">short</attribute> <attribute id="decimation">1</attribute> <attribute id="floating">off</attribute> </attributes> </block> </blocks> <connections> <connection id="c_0"> <sourceblock>b_0</sourceblock> <sourceport>e</sourceport> <destinationblock>b_1</destinationblock> <destinationport>w</destinationport> </connection> </connections> </scheme> Figure 9. Example of internal XML scheme format Page 244

5 1) Blocks and Attributes In the second phase, the back-end export script transforms the scheme into Xcos or Simulink format. For Xcos, this step includes generation of standard Xcos file header, listing of each block used in scheme together with relevant group of attributes, input and output ports. Block parameters are defined in the configuration file (see Section VI) and actual values are taken from the exported scheme. When the blocks are processed, the connections between blocks are specified and the scheme is finalized with Xcos file footer. Transformation into MDL format is slightly different. This format uses additional metadata compared to Xcos. Specifically, it is author s and editor s name, time and date of creation and last modification of a scheme. Another difference between Xcos and MDL is that MDL file contains list of blocks and set of their default parameter values (labeled BlockParameterDefaults). Thereinafter in MDL file, there is also a listing of each block used in the scheme. Parameters of blocks with default values do not necessarily appear again in this list because they have been already specified in the BlockParameterDefaults part of the MDL file. 2) Connections The third step includes generation of connections. In Xcos, connections with nodes are split into partial connections where the source or the destination block may be represented by a node as well as by a standard block. Similar treatment of complex connections is also used in the web editor, thus there is no need to perform extra processing of connections. However, connections in MDL files are handled in a different way compared to the web editor or Xcos. While in Xcos (and also in the presented web editor), nodes are regarded as a special kind of block in the scheme, there are no such blocks in MDL. Instead of that, MDL uses a structure of branched connections to describe connections with nodes. Therefore such connections need to be converted into the structure where the source and destination blocks are always standard blocks. The conversion is processed by recursive function that looks for paths from output block to each connected input block. In the last step, the transformed scheme is saved into a file and it is offered to user to download afterwards or to use it within an online experiment. B. Import The import process realizes the same steps as the export but in reverse order. Firstly, user has to upload an MDL or Xcos file containing the scheme that is going to be imported. When importing an Xcos file, the import script parses the whole file and stores it as XML object. In case of MDL file there is a custom function that reads the whole file and it transforms plain text information into a structure suitable for further work with MDL data. 1) Blocks and Attributes Loaded content (either from MDL or Xcos) is scanned for list of blocks and their attributes. Since the web editor is still under development, it can happen that some blocks not yet implemented in the editor may occur in the imported scheme. In case of blocks or attributes that are not present in web editor s configuration file, the warning message is shown. These unknown blocks will not appear in the imported scheme. Processing of unknown attributes is skipped but the parent block will still appear in the scheme. Blocks are followed by a list of connections between blocks that are also being processed. In comparison to Xcos files, import of MDL files contains one additional step. Just before loading list of blocks, the default values of each block s parameters are loaded from the file. They are used when value of some block parameters is missing (in case of MDL, blocks do not necessarily have all of their parameters listed). 2) Connections Loading connections from Xcos files is very simple due to the fact that they have similar structure to web editor s connections structure. Thus they are only read one after another and they require no additional processing. Connections in MDL file need more attention because of different representation of complex (branched) connections. These differences have been described in Section V Export. During the import of an MDL file, each branched connection has to be converted to simple connections using node blocks. After successful import, the data are sent to the web editor and the imported scheme appears in the editor s canvas. VI. CONFIGURATION FILE The key parts of the application are common configuration files used by the front-end part of the application as well as by the back-end scripts one file is for Simulink and other one for Xcos. The configuration is stored in XML format. Data contained in the configuration files are used for visualization in web editor s interface (i.e. images of blocks, positions of input and output ports, etc.) as well as for correct function of import and export scripts. The configuration XML files for Simulink and Xcos contain every information about attributes that are used for displaying blocks in the editor: image file name, dimensions, input and output ports. The configuration file for Xcos contains additional attribute block class name (e.g. BasicBlock, ConstBlock or other used as XML tag that encapsulates block attributes in Xcos document). In both configuration files (both for Xcos and Simulink as well) each block contains a group of attributes (constant block in Fig. 10 has a single attribute ConstantValue). The attribute definition contains its displayed name, input type (used in web editor s attributes window), default value and optional list of possible values (only for dropdown and radio button data types). In addition, block parameter values in Xcos are stored in complex structures inside tags representing current block (e.g. <ConstBlock> </ConstBlock>; see description of Xcos file structure in Section III and Fig. 6). The locations of these values are defined in the configuration file inside location tag as an XPath address. XPath is used to navigate through elements and attributes in an XML document. In case of MDL files, the attributes are simply listed one after another, thus the location specification is not necessary. Page 245

6 Figure 11. Part of DTD for configuration file (Xcos version) Figure 10. Part of configuration file (Constant block/xcos version) However, compared to Xcos, MDL configuration file contains one extra tag called datatype. As the name implies, this field specifies whether the attribute value is stored as a number, a string or a logical value. Data type attribute is not used directly by Matlab, but it is used to determine the correct notation of values in MDL files (e.g. strings enclosed in quotes, logical values represented as on or off, etc.) during import or export. The application is easily extendable by the application administrator. It is not necessary to edit source codes of the application. New blocks can be easily added by modifying the configuration XML file. Currently, the web editor includes the most common blocks used in block schemes. The set of included blocks is being extended simultaneously with further development of the web editor. Since the well-formed and error-free configuration files are very important for correct function of the whole application, the DTD 4 documents for configuration XML files are also provided to prevent errors after modifications. Due to slightly different structure of configuration files for Simulink and Xcos, both of them require the separate DTD document. VII. CONCLUSION Trying to compare formats used in both Xcos and Simulink environment it is necessary to say that both formats have their pros and cons. On the one hand, Xcos files use valid XML format that makes processing of files really simple. The structure of connections in Xcos is also very handy regarding the fact that they do not require additional transformation during the export and import phase. Such additional transformation is needed using Simulink plain text format. On the other hand, MDL files have clearer notation of block parameters and their corresponding values. In Xcos, they are hidden inside immense code and they are often stored redundantly in more than one location inside Xcos file. During the development of introduced online application we tried to take into account all advantages of both formats and to create a new format that is used by web editor as its native scheme format. Block schemes prepared by the application can be used for control of dynamical systems within virtual and remote laboratories. Since we used wide spread technologies the presented solution can be combined with the most of solutions that enable to use Matlab and SciLab via Internet. ACKNOWLEDGMENT The work has been partially supported by the Slovak Grant Agency, Grant KEGA No. 3/7245/09 and Grant VEGA No. 1/0656/09. This support is very gratefully acknowledged. 4 Document Type Definition defines legal document structure (list of elements and attributes) Page 246

7 REFERENCES [1] D. Crockford (2002). Introducing JSON, [2] Digiteo ( ). SciLab website, [3] I. Gustavsson, K. Nilsson, J. Zackrisson, L. Hakansson, J. G. Zubía, G. R. Alves, U. Hernandez, R. J. Costa, T. Lago, I. Claesson (2011). The VISIR Open Lab Platform an architecture of a federation of remote laboratories, 8th Int. Conference on Remote Engineering and Virtual Instrumentation (REV'11), Brasov, Romania, [4] Z. Janík, K. Ţáková (2011). Online Design of Matlab/Simulink Block Schemes, In: International Journal of Emerging Technologies in Learning. Vol. 6, Special Issue 1, pp ISSN [5] Z. Janík, K. Ţáková (2011). Online Design of SciLab/Xcos Block Schemes, 18th Int.Conference on Process Control, Tatranská Lomnica [6] J. Liguš, I. Zolotová, P. Karch and J. Ligušová (2010). Information and Control System of Traverse and its Integration into Cybernetic Centre. Electronics and Electrical Engineering, No. 6, pp ISSN [7] The MathWorks, Inc. ( ). MathWorks store, [8] The MathWorks, Inc. ( ). MATLAB The Language Of Technical Computing,, [9] Refsnes Data ( ). JavaScript and HTML DOM Reference, [10] J. Resig and the jquery Team (2010). jquery Documentation, [11] M.T. Restivo, J. Mendes, A.M. Lopes, C.M. Silva and F. Chouzal (2009). A Remote Lab in Engineering Measurement, IEEE Trans. on Industrial Electronics, Vol. 56, No.12, pp [12] F. Schauer, M. Oţvoldová and F. Lustig (2008). Real Remote Physics Experiments across Internet Inherent Part of Integrated E-Learning, In: Int. Journal of Online Engineering (ijoe), 4, No 2. [13] Chr. Schmid. (2003). Internet - basiertes Lernen, Automatisierungstechnik, 51, No. 11, pp [14] M. Šimunek, P., Bisták and M. Huba (2005). Virtual Laboratory for Control of Real Systems, Conference Proceedings ICETA. Košice. [15] K. Ţáková and M. Sedlák (2006). Remote Control of Experiments via Matlab, In: Int. Journal of Online Engineering (ijoe), 2, No. 3. Page 247