En la entrada previa mostré cómo se configuraba una red de controladores en UWS, y concluía con el arranque del servidor web. Quedó pendiente cómo desarrollar la interfaz del SCADA. Aunque al acometer la parte gráfica no es necesario comprender bien cómo funciona el propio servidor, resulta conveniente para conocer sus posibilidades. Cuando lo instanciamos se le pasan tres parámetros: una tupla con la interfaz y puerto de escucha, el manejador y el ensemble:
|
1 |
UWServer(("",80),WebServer,ensemble).serve_forever() |
Hecho esto, una hebra se encargará de atender las peticiones HTTP que lleguen por dicho puerto con el método GET. En román paladino, cuando escribamos la dirección del servidor en un navegador recibiremos una respuesta, en función de la URL que se esté demandando. El formato de una petición sería como sigue:
|
1 |
http://servidor:puerto/recurso |
Respecto a la dirección del servidor no creo que haya lugar a dudas. Si hemos arrancado el UWServer con la línea antedicha y queremos acceder al SCADA desde el propio equipo, escribiríamos en el navegador http://127.0.0.1:80 (o http://localhost:80, o simplemente http://localhost). La parte interesante está en la cadena recurso. Tenemos tres alternativas:
- Lectura de un valor. Para conocer un valor de un controlador, el recurso debe adoptar la forma ?r:[plc]:[memoria]:[elemento]. Por ejemplo, si en la situación descrita en la entrada previa queremos conocer la entrada analógica 2 (la tercera, ya que empezamos a contar por 0), la URL que debemos escribir sería http://localhost:8080/?r:plc1:registers:2. El navegador nos devuelve directamente su valor en HTTP. Sencillo, ¿no?
- Escritura de un valor. De la misma forma, podríamos modificar un valor en uno de los controladores. La cadena de recurso en este caso sería ?w:[plc]:[memoria]:[elemento]:[valor]. En la misma situación anterior, si quisiésemos escribir un 50 en el primer registro de retención (dirección 0), lo haríamos pidiendo desde el navegador http://localhost:8080/?w:plc1:holdings:0:50. Podemos ver cómo en el controlador, dicho registro se pone en 50.
- En cualquier otro caso, se nos devolverá, como un servidor web al uso, el fichero localizado en la ruta relativa, que por defecto es www. Por ejemplo, podemos crear una página de bienvenida index.html, situarla dentro de www, y verla con http://localhost:8080/index.html (o de forma más simple, http://localhost:8080).
No necesitamos nada más para elaborar la interfaz. Con esto es suficiente para crear una página web, y un poco de Javascript nos debería permitir el refresco de la representación y el envío de las escrituras. Se puede objetar que el código que habría que elaborar es engorroso, pero aquí es donde entra en juego la magia de jQuery Ajax. En el ejemplo que hemos dado, he incluido el fichero j.js, que permite olvidarse de toda esta tarea (en realidad, de todo lo que he explicado hasta el momento). Su uso es simple, y sólo hay que hacer dos cosas:
- En la página que desarrollemos hay que incluir una referencia a jQuery y a j.js:
12<script src="jquery.js"></script><script src="j.js"></script> - A cada elemento dinámico hay que agregarle el atributo data-dir, cuyo valor será la dirección del dato que se desea representar. La sintaxis es la misma antes descrita ([plc]:[memoria]:[elemento]). Es decir, para mostrar el estado de la bobina número 1, el código HTML sería el siguiente:
Si además nos interesa poder modificarlo, la etiqueta adecuada es sin duda un input:1<div data-dir="plc1:coils:1"/>
1<input data-dir="plc1:coils:1"/>
Con estos atributos data-dir, podemos desentendernos de la programación asociada a la página. El código en j.js hace lo necesario. Por un lado asocia a las etiquetas susceptibles de ser modificadas (input de tipo checkbox y text) los eventos correspondientes, de modo que ante un cambio envíen la escritura al servidor. Por otro, se lanza un temporizador para refrescar periódicamente los valores, tanto de las etiquetas anteriores como de los div, que no se pueden modificar. El tiempo de refresco, que es de 1000ms por defecto, se puede determinar mediante el siguiente elemento oculto HTML:
|
1 |
<input type="hidden" id="period" value="1000"> |
Por supuesto, todo lo descrito hasta aquí es muy mejorable. Así a bote pronto se me ocurren las siguientes líneas de desarrollo para las próximas versiones de UWS:
- Utilizar los websockets de HTML5 para el refresco de la página, en vez de solicitar periódicamente los datos, mediante un modelo de suscripción. Con esto se gana agilidad y se disminuye el tráfico de red.
- Añadir nuevas funcionalidades a j.js, como alterar la visibilidad de elementos, dimensiones, etc. Mediante atributos adicionales, también se puede agregar transformaciones sobre valores, como inversión o escalado.
- Introducir en el ensemble un diccionario, para referenciar los datos mediante nombres simbólicos. Lo ideal sería cargar dichos nombres desde fichero o base de datos, en lugar de picarlos en Python.
- Agregar nuevos protocolos de comunicación con controladores. También otras formas de conectividad con el ensemble.
- Por último, un SCADA no puede estar completo sin alarmas e históricos.
Esta entrada continúa en Proyecto UWS (4).
Recursos asociados:
SCADA UWS (versión 1.0) y código de ejemplo.
