 Good evening, all of you. Today, I and Ahmed are going to present our software that is Xcause on web. I'll give a brief info what Xcause is. The aim of our project was to port all the functionalities of Xcause to a browser-only version, because it can be available to user 24 hours, and he can access it via any machine which has internet connectivity. The next is overall system design. The user is provided with a geographical user interface, that is, web browser, through which he can drag and drop any block and make a diagram and pass it to server. The server will simulate it and give a PNG back to the user as a result of the simulation. Now, this is the flowchart. First of all, the server will start, then it will display the editor and the pallet with all the blocks. The user then can make a diagram, and the MX graph will create a row XML from the JSON which will be created by data structures of that particular block which he have dragged. Then, XSLT will convert the required that MX graph XML into Xcause, and it will send to the server. Now, the server will simulate diagram and display the result back to the browser. This is the graphical user interface, which we have created. You can see there are many blocks and links are created between ports of different blocks. So, this is the diagram which when simulated gives a PNG. These are the features of GUI. We can set block parameters. That is, for every block, there are certain parameters which can be set. Then there's a right click functionality of zoom in, zoom out, et cetera. Then there's color wheel and port constraints. For example, an explicit output port can only be connected to explicit input port, and a command port can only be connected to control port. If we connect otherwise, then it will show an error. Then there's tooltops, setup, and export Xcause. There's color wheel, if we set, choose a color, then it will display in the background, and see, you can see when we have tried to connect explicit output port with a control port, it shows error, that it cannot be connected. Then it's just converter, which... Good evening, all of you. Actually, we have used Python and Revex to convert the data structure which are in silo in JavaScript. So, as we can implement in the client side. So, we don't have to use the data structure in the server side. This is a state diagram which we have used for the converter. First of all, we check the state. If we are using silo, there are various data types in silo. We have silo double, silo string, and silo integer. So, this is a state diagram which depicts how we are converting the silo data structure in the equivalent JavaScript data structure. This is the workflow of our converter, and it extracts the function name, and then it extracts all the defined cases of the data structure, and it converts it into the equivalent JavaScript. There are various basic blocks which cannot be converted by the converter, which was specified by him, because these are the basic ones, and these are the building blocks of that blocks which he have converted using that converter. So, there are many data structures like Skycos links, Skycos blocks, and some other. These have been created by me, and you can see they are using, this is the above Sky file for that Skycos link, and the JavaScript function which we have made. As you can see, it uses Skylab double and all other such type of data types, which we have also implemented. Skylab double is used to store metrics of double type. You can also say that we could have used double, int, or something, but we have used Skylab, we have made our own data types just to make it more familiar to the Xcos that will be required at the end. There are functions which were not defined by Skylab. We have added these functions so that to make it more efficient and effective. Yeah, all this is JavaScript. And there are some internal operators as well, which we have re-implemented. There is, yeah, I have done a whole JavaScript, there were two 30 blocks out of which 100 has been implemented right now. For one block, there was 2,000 lines. Not for all blocks, but some had 100 lines, some had to 1,000 lines. I don't know, exactly. We have used Converter to convert the structure of... No, Convert is Convert. Yeah, so we have used the dependent approach and the... Okay, the basic blocks, right? There's combined on JS inside that. There are two 30 blocks. So now I will explain you about the accessibility. Actually, we have implemented the front end with the MX graph. So it wraps up the whole data in an XML format. But that format is not compatible with the X-Calls. So X-Calls has an accessibility which defines the rule that any block can contain this format of XML. So we made use of that accessibility to make the rules for transformation so that this data from the data by our GUI, according to the rules, will be converted in accordance to the X-Calls so that we can simulate it in the server. Now, this is the simulation. See, the user has created a diagram on the left side and if it clicks on simulation, he'll get this simulated diagram. There are various server components. For example, JavaServlet has been used at back-end to get the X-Calls file and to keep the image back. And NGNX has been used above it. There are some future work which have to be implemented. For example, we need a dynamic interaction. Right now, PNG has been passed by the server, but what we want is user can, for example, you have seen TK scale from X-Calls and X-Tops. So that functionality needs to be implemented. Moreover, we do not want a PNG back. We want X, Y coordinate back so that we can implement. We can ask us to make that. Okay. Have you documented the entire thing? Yes, we have made documentation. All soft copies are left with the corresponding procedure. Yes. Okay. I'll show the demo. There are various... Okay. Let next. Okay. Because demo is going to be the same as the X-Calls without the web. Correct? For example, if this is the diagram, then it will get simulated. Why? Okay. Thanks. Thank you.