August 10, 2014 at 20:02Real-time mode in WebScada based on OPC UA and WebSocket technologies. Part two
Greetings to all habrozhitel! And thanks for your interest in the topic of implementing WebSCADA based on a synthesis of OPC UA and WebSocket technologies.
In a previous post, I began the description of creating a mini WebSCADA with the development of an OPCUA-WebSocket gateway that allows broadcasting signals from the OPC server to the browser and back using the WebSocket protocol. Anyone interested can be found here .
In this article I want to continue the description of work in this direction and present a web-application that works with a previously written gateway.
This development is more experimental in nature than practical. And it is unlikely that this software can be applied in any field without the necessary improvements. But I decided to approach the design of the web application thoroughly and using powerful frameworks both for the server side and for the client, so that later it would be easier to expand.
I used Yii for the server side , jQuery and Backbone on the client, and the Nighcharts library to draw control devices and graphsworking with graphics in svg format. By the way, I would like to note in favor of WebScada the fact that on the Internet you can find a huge number of ready-made libraries and frameworks working with graphics, which allows you to make a rather outstanding interface.
Also, I did not make an abstract test bench, but made an application, as it were, for monitoring distributed objects (for example, substations). Because, it is in distributed systems that WebScada can be most in demand.
An administrator part (backend) was created by means of which web-application settings are made, monitoring objects are created, user accounts are entered, objects are connected to nodes on the OPC server, objects are connected to users to differentiate access rights, etc. Further expanding the administrative part, it will be possible to adapt it to the needs of the sphere for which the system is planned to be used. This is still a dream, but the foundation is laid.
Accordingly, the front part of the interface was also created, on which visual elements are placed, and the process is monitored and controlled. In other words, the operator workstation is built in this part of the application. This part can hardly be called a frontend in the classical sense, since it also requires password access. The difference between the parts of the web application is that only super administrators have access to the backend, and AWP operators to the frontend.
And here is what I got:
Node Management Page
To start, we enter all the information about the controlled server nodes into the database of the web application (their ID and name) in order to further bind them to objects. To simplify the task, when connecting to the server, data about active nodes is broadcast in the application and displayed on the node management page. It remains only to save the received information in the database of the web application, give the nodes meaningful names and determine the way of displaying the data coming from the nodes.
Connection to the server (in the circled area, the nodes are currently active on the server)
After clicking the “synchronize” button, the nodes enter the database of the web application.
Nodes can be attached both to an already created object, and at the stage of its creation. The same nodes can be attached to different objects. This allows more flexible differentiation of access rights to monitoring data of certain nodes as part of various objects.
Editing an object
I will not dwell on creating and editing user accounts. Everything is pretty standard here and Yii provides all the necessary tools for this. I will give only a drawing.
User account management page
You can bind objects to the user profile to which he will have access to manage and monitor parameters.
Editing user account
Login page. Access to AWP.
After successfully completing the authorization procedure, the user opens a page with information on the objects that were tied to his account at the application setup stage. On this page visual elements will be displayed, displaying virtual devices for monitoring the transmitted parameters. Let me remind you that these visual elements are also assigned at the setup stage.
Parameter control panel We
connect to the previously written gateway using the WebSocket protocol and immediately start receiving data from the OPC UA server nodes in real time.
Viewing in a browser data transmitted by the OPC server in real time.
The beauty of the WebSocket protocol is that data can be transmitted on the server’s initiative through a pre-established long-lived connection. That is, in the browser it is now possible to receive subscription data for events on process control nodes as in the desktop SCADA system, but to do this from anywhere in the world and on any device with a browser that supports the WebSocket protocol. Creating this protocol has taken web applications to a new level, so why not use its features in WebScada.
Next, you will need to add the ability to write information to nodes and send control signals to the web application. I will do this when the need arises for such functionality. This is quite simple, because the ability to transfer data on the initiative of the browser (or rather the user) has always existed.
Thanks for attention.
In a previous post, I began the description of creating a mini WebSCADA with the development of an OPCUA-WebSocket gateway that allows broadcasting signals from the OPC server to the browser and back using the WebSocket protocol. Anyone interested can be found here .
In this article I want to continue the description of work in this direction and present a web-application that works with a previously written gateway.
This development is more experimental in nature than practical. And it is unlikely that this software can be applied in any field without the necessary improvements. But I decided to approach the design of the web application thoroughly and using powerful frameworks both for the server side and for the client, so that later it would be easier to expand.
I used Yii for the server side , jQuery and Backbone on the client, and the Nighcharts library to draw control devices and graphsworking with graphics in svg format. By the way, I would like to note in favor of WebScada the fact that on the Internet you can find a huge number of ready-made libraries and frameworks working with graphics, which allows you to make a rather outstanding interface.
Also, I did not make an abstract test bench, but made an application, as it were, for monitoring distributed objects (for example, substations). Because, it is in distributed systems that WebScada can be most in demand.
An administrator part (backend) was created by means of which web-application settings are made, monitoring objects are created, user accounts are entered, objects are connected to nodes on the OPC server, objects are connected to users to differentiate access rights, etc. Further expanding the administrative part, it will be possible to adapt it to the needs of the sphere for which the system is planned to be used. This is still a dream, but the foundation is laid.
Accordingly, the front part of the interface was also created, on which visual elements are placed, and the process is monitored and controlled. In other words, the operator workstation is built in this part of the application. This part can hardly be called a frontend in the classical sense, since it also requires password access. The difference between the parts of the web application is that only super administrators have access to the backend, and AWP operators to the frontend.
And here is what I got:
The administrative part.
Node Management Page
To start, we enter all the information about the controlled server nodes into the database of the web application (their ID and name) in order to further bind them to objects. To simplify the task, when connecting to the server, data about active nodes is broadcast in the application and displayed on the node management page. It remains only to save the received information in the database of the web application, give the nodes meaningful names and determine the way of displaying the data coming from the nodes.
Connection to the server (in the circled area, the nodes are currently active on the server)
After clicking the “synchronize” button, the nodes enter the database of the web application.
Nodes can be attached both to an already created object, and at the stage of its creation. The same nodes can be attached to different objects. This allows more flexible differentiation of access rights to monitoring data of certain nodes as part of various objects.
Editing an object
I will not dwell on creating and editing user accounts. Everything is pretty standard here and Yii provides all the necessary tools for this. I will give only a drawing.
User account management page
You can bind objects to the user profile to which he will have access to manage and monitor parameters.
Editing user account
AWP operator
Login page. Access to AWP.
After successfully completing the authorization procedure, the user opens a page with information on the objects that were tied to his account at the application setup stage. On this page visual elements will be displayed, displaying virtual devices for monitoring the transmitted parameters. Let me remind you that these visual elements are also assigned at the setup stage.
Parameter control panel We
connect to the previously written gateway using the WebSocket protocol and immediately start receiving data from the OPC UA server nodes in real time.
Viewing in a browser data transmitted by the OPC server in real time.
The beauty of the WebSocket protocol is that data can be transmitted on the server’s initiative through a pre-established long-lived connection. That is, in the browser it is now possible to receive subscription data for events on process control nodes as in the desktop SCADA system, but to do this from anywhere in the world and on any device with a browser that supports the WebSocket protocol. Creating this protocol has taken web applications to a new level, so why not use its features in WebScada.
Next, you will need to add the ability to write information to nodes and send control signals to the web application. I will do this when the need arises for such functionality. This is quite simple, because the ability to transfer data on the initiative of the browser (or rather the user) has always existed.
Thanks for attention.