Novedades 20151021

publicado en: Energía, PLC, SCADA | 0

Schneider Electric agrupó parte de la formación gratuita que ofrece bajo un centro online que ha dado en llamar la Energy University. Es posible acreditarse de dos de ellos (esto ya no es gratuito): el de Data Center Associate y el de Professional Energy Manager. He estado echándole un vistazo al segundo. Lo componen cerca de un centenar de unidades, que tardan en completarse aproximadamente una hora cada una. Se extiende en domótica, sistemas de aire comprimido, HVAC, ilumación, motores, vapor, etc. Y por supuesto, en medidas de energía y eficiencia.
He tenido que migrar varias veces HMI, por diversas razones (obsolescencia, integración, rediseño, ampliación de funcionalidad, e incluso estética). En general son procesos sencillos, pero costosos. ¡A veces más que el desarrollo original, por carecer de documentación! Por esta razón, a los siguientes consejos de Fabio Terezinho, añadiría otro: aportar valor a la nueva aplicación que justifique estos costes aparentemente elevados.
Matthew Wells hacía recientemente una serie de reflexiones sobre la modernización de los SCADA, o HMI en general. El artículo habla de cómo afrontar la obsolescencia, de las nuevas tecnologías, la conveniencia de adoptar estándares, Industrial Ethernet, o los beneficios de afrontar el cambio. En último término, ofrece unos consejos a la hora de elegir un nuevo sistema.
Control Design está publicando fragmentos de una entrevista a Dick Morley, el que es considerado por muchos el inventor del PLC. Os invito a ver tres de ellos, en los que relata el nacimiento de los controladores industriales y las diferencias entre éstos y los PC o las PAC.
http://www.controldesign.com/articles/2015/the-father-of-the-plc-explains-its-birth/
http://www.controlglobal.com/industrynews/2015/plc-creator-explains-the-difference-between-pc-based-control-and-plcs/?utm_content=21432800
http://www.controlglobal.com/industrynews/2015/plc-creator-explains-the-difference-between-plcs-and-pacs/?utm_content=21432825

Librería Manager.js (2). Uso

publicado en: Diseño web | 0

manager-ejemploEn la entrada previa presenté la librería Manager.js, que he desarrollado para la creación de ciertas aplicaciones web sencillas. El requisito necesario, como comentaba, era que la información que maneja tenga una estructura jerárquica, relacionándose las tablas entre sí, y en último término con la del usuario que se ha registrado. Este requisito se cumple con bastante frecuencia, y con esta librería la programación en el lado del cliente puede hacerse muy ágil. Para describir la API escogí un ejemplo: una página web en la que los usuarios pueden gestionar proyectos, cada uno de ellos compuesto por uno o varios controladores, a los que se le puede introducir una configuración dando de alta señales. En la imagen de la derecha se muestra un caso posible, con un controlador que registra una temperatura.
La aplicación, para gestionar la información, debe replicar su estructura a tres niveles. El primero es la base de datos, donde se han de crear las tablas y relaciones correspondientes. En nuestro caso, sería una tabla user para gestionar los usuarios, cosa que hacíamos con la librería User.js, que comenté en su momento; y las tablas project, controller y channel. Cada una de ellas posee un campo (user_id, project_id, controller_id) que enlaza con la clave principal de la tabla previa.
En dicha entrada también vimos cómo se introduciría la configuración necesaria para instanciar la representación de las tablas de la base de datos. Se hacía proporcionando al constructor de Manager información acerca del nombre de la tabla, su denominación en la web, información sobre su contenido y representación, y por último, su relación con la tabla padre. El código necesario era el siguiente:

En realidad, hecho esto, hay poco más que programar, puesto que la definición de las tablas contiene el grueso de la información que se necesita para determinar el comportamiento en la página web. Veámoslo.
Lo primero que tendríamos que desarrollar es el código HTML para el navegador. Habría que construir los formularios correspondientes para introducir o editar la información, botones para enviarla, borrar elementos, cancelar la edición, etc. Ésta es una labor tediosa, que los entornos de programación como Django o Ruby on Rails agilizan enormemente con el uso de plantillas. Por supuesto, para nuestra aplicación sería posible el recorrido largo, y llevar a cabo un desarrollo personalizado del código, pero la librería proporciona una alternativa extremadamente rápida. El método form() genera el código HTML correspondiente a cada tabla. Podemos crear el contenido de nuestra página tan solo con estas líneas:

Las capas project, controller y channel sirven para posicionar dicho contenido dentro de la página. Con esto, ya tendríamos los elementos que se muestran en la imagen superior. Ahora es necesario asociarles eventos. Manager trabaja con los siguientes:

  • populate(): Pide al servidor las claves principales y descripciones de cada elemento de la tabla, para rellenar los desplegables.
  • change(): Cuando se selecciona un registro en un desplegable, este método actualiza las descendientes.
  • edit(): Pide un registro de la tabla, para mostrarlo o editarlo.
  • destroy(): Elimina un elemento.
  • create(): Muestra el formulario para crear un nuevo registro.
  • close(): Cierra el formulario sin hacer modificaciones.
  • submit(): Envía los datos tanto para la creación como para la edición de un registro.

Los métodos populate(), change, edit(), destroy() y submit() actúan contra el servidor. No voy a detallar aquí la comunicación, que dejo para una documentación más formal, pero baste decir que Manager.js trabaja de forma similar lo hacía la librería User.js. Es decir, se hacen llamadas asíncronas a una URL en cuyos parámetros se especifica la acción a realizar y los datos necesarios, y con la respuesta se actualiza la página.
Para animar la página, sería necesario asociar al botón project_create el método create(), a project_collection el método change(), etc. Nuevamente podemos hacerlo paso a paso, o optar por una vía rápida. El método events() asocia de una tacada todos los eventos necesarios, con lo cual nuestro código quedaría así:

Por último, es necesario un pequeño empujoncito para que todo eche a andar. Se trata tan solo de poblar las tablas hijas de la de gestión de usuarios en el momento en que éste se identifica:

Esto es todo. Código minimalista para un desarrollo rápido y sin florituras. Se puede embellecer con CSS o programar por separado lo que la librería no contempla (como crear máscaras para los campos de texto), pero eso es un capítulo aparte.
Recursos asociados:
Librería Manager.js para gestión de información con estructura de árbol
Ejemplo de uso de la librería Manager.js

Librería Manager.js (1). Instanciación

publicado en: Diseño web | 0

En aplicaciones de servicios es enormemente corriente una estructura particular de base de datos en la que las tablas se relacionan de forma jerárquica. Por ejemplo, una organización que trabaja con proyectos, que se subdividen en tareas. O un deportista, que ejercita rutinas, que contienen series agrupadas por días. Podría seguir describiendo casos que, si no se amoldan exactamente a esta forma de organizar la información, sí lo hacen en su parte troncal. Cuando se quiere afrontar una aplicación de este tipo con arquitectura cliente-servidor, es preciso manejar esta estructura jerárquica al menos en tres ámbitos: la base de datos, el código en el lado del servidor y el código en el lado del cliente. Si lo que se pretende es desarrollar una aplicación web, existen muchos entornos de desarrollo que permiten agilizar la tarea, como Django, Ruby on Rails, Symfony… He usado y probado varios y, si bien son prácticos y ahorran mucho tiempo, tenía la espina de construir algo aún más ágil para estos casos sencillos en los que se trabaja con tablas enlazadas en forma de árbol. Algo con la inmediatez de Django, pero que permita trabajar directamente sobre el código final y sin riesgo de echar a perder la información almacenada por alterar una tabla. En cualquier caso, es un ejercicio modesto para aplicaciones sencillas, sin la ambición de acercarse a las capacidades de los entornos de desarrollo existentes. A aquellos lectores que desconozcan el tema, antes de seguir les recomiendo leer una breve introducción a la programación web.

Hecha la introducción, voy a replantear la situación que deseamos afrontar. Se quiere construir una aplicación web que gestione información estructurada en tablas que se enlazan en árbol. La tabla raíz contiene el usuario que se ha identificado, y que se va a gestionar en el lado del cliente con la librería Users.js, que ya comenté anteriormente. El resto de tablas tendrán un campo que indexará a la clave principal de la tabla de usuarios, o de otra. En el navegador se representan los datos de estas tablas, según se vayan seleccionando los valores de las claves principales. No tiene por qué poder accederse necesariamente a todas (en particular, queda excluida la tabla de usuarios por motivos de seguridad), ni a todos los datos. La gestión de la información, mediada por el código en el lado del servidor, va a ser sencilla: consulta, inserción, borrado, modificación… Por supuesto, se debe vigilar la seguridad (un usuario no puede ver o alterar los datos de otro, por ejemplo). Este tipo de aplicaciones básicas, como decía, son muy comunes, y es sencillo crear librerías genéricas para acometer su desarrollo. En esta entrada voy a describir la librería Manager.js, que va a simplificar la programación en el lado del cliente. Lo ideal es disponer de una librería similar en el servidor, e incluso mantener relacionadas las estructuras que manejan ambas con las de la propia base de datos.
A diferencia de la descripción pormenorizada que hice de Users.js, en este caso me voy a ceñir al API. En Manager.js, cada tabla de la base de datos (menos la de usuarios) viene representada por una instancia de la clase. Los parámetros del constructor van a contener tanto información de dicha tabla como de su relación con las otras y su modo de representación:

El parámetro tabla recoge el nombre de la tabla (real o traducido por el servidor, si se quiere), y nombre es el texto con el cual se va a identificar en la página web. Le sigue un array con los campos de información que la tabla va a contener; más adelante me detendré en su formato, puesto que almacena información adicional relativa a la representación. Por último, padre es el objeto que representa a la tabla a la que se indexa. Si fuese una de las tablas inmediatamente descendientes de la raíz (la tabla de usuarios), este último parámetro es nulo. Por ejemplo, vamos a imaginar que desde nuestra aplicación se gestionan proyectos. La construcción de la instancia asociada de Manager se haría tal como sigue:

Es decir, los proyectos se van a almacenar en la tabla de nombre project, cada una de sus filas es un “Proyecto”, no contienen información adicional y no dependen sino del usuario que los crea. Obviamente, esta simplicidad oculta varios sobreentendidos. El primero es que la tabla project (todas nuestras tablas en realidad) debe contener los tres siguientes campos:

  • id: es la clave principal; debe ser un valor entero con autoincremento.
  • descriptor: es la descripción de cada elemento; en nuestra tabla de proyectos, será el nombre que el usuario da al proyecto; si fuese una tabla con recetas, por ejemplo, sería el título de cada receta.
  • [tablapadre]_id, donde [tablapadre] es el nombre de la tabla enlazada. Así, en la tabla project este campo se llama user_id, puesto que un usuario puede tener varios proyectos. Su contenido es, como es fácil adivinar, las claves principales del campo indexado.

Vamos a crear otra tabla que dependa de ésta. Imaginemos que nuestros proyectos son instalaciones que poseen varios controladores. Creamos por tanto una segunda tabla llamada controller. Sus campos van a ser los mínimos obligatorios: id, descriptor y project_id. Y el manejador de esta tabla se instancia en Javascript con el siguiente código:

Con lo dicho, es posible representar la jerarquía de tablas que comentaba al principio. Sin embargo, para darle riqueza a nuestra construcción, es preciso poder almacenar información adicional. Me dejé antes por describir el tercer parámetro del constructor, que va a tener información de los campos adicionales de las tablas, además de su representación. Dicho parámetro es un array de arrays. El primer nivel hace referencia a cada campo, y el segundo contiene lo siguiente:

  1. El nombre del campo en la tabla.
  2. El nombre del campo tal y como se representa en el navegador.
  3. Un objeto con información sobre su representación. Por defecto, la edición se hará mediante un campo de texto. Si el objeto contiene un elemento class, se usará una entrada de otro tipo:
    • Si class vale “checkbox”, se muestra una casilla de selección.
    • Si class es “select”, se usa un desplegable; los valores a elegir serán los contenidos en el elemento values, que debe guardar un objeto con parejas valor/representación.

Por ejemplo, si queremos guardar por cada controlador su IP (o dominio) y su MAC, haríamos la siguiente instanciación:

Como no se ha especificado un elemento class, tanto la dirección como la MAC se van a introducir y editar mediante un cuadro de texto.
Vamos a hacer algo más compleja nuestra base de datos, y a cada controlador le asociaremos una serie de señales, en la tabla channel. Estas señales podrán ser de entrada/salida o de memoria, y queremos que se elija un tipo u otro mediante un desplegable. El objeto que describe esta representación será entonces el siguiente:

Es decir, indicamos mediante “select” que queremos usar un desplegable, y sus valores posibles serán “E/S” o “Memoria”, que se almacenarán en la base de datos como “F” y “M” respectivamente. También vamos a crear campos para almacenar información adicional de la señal, como si se historiza o no (campo checkbox):

Esta entrada continúa en Librería Manager.js (2). Uso.
Recursos asociados:
Librería Manager.js para gestión de información con estructura de árbol
Ejemplo de uso de la librería Manager.js

Novedades 20151012

publicado en: HMI, Seguridad, Siemens | 0

Los centros de control se están transformando. Poco a poco, en relativo silencio. Ya en su día vimos cómo desaparecían los pupitres de mando en favor de un pequeño PC, y los sinópticos de pared por pantallas planas. Ahora se están introduciendo elementos táctiles o móviles como tablets o smartphones, interfaces mucho más extensas, entornos más intuitivos y amigables. Y añadiría una mayor integración con el resto del software, que facilita las tareas del personal de operación.
Siemens ha publicado una ampliación de las librerías del TIA Portal (S7-1200 y S7-1500) con funciones adicionales de uso general. Éstas incluyen álgebra matricial, generación de números aleatorios, ampliación de contadores, pulsos, etc.
Danielle Collins publicaba recientemente en Motion Control Tips un artículo sobre encoders. Por el sistema de funcionamiento se pueden clasificar en ópticos o magnéticos; y según la conexión al PLC se distingue entre absolutos (su salida es una palabra) o incrementales (un pulso o dos para determinar el sentido).
Bartman y Carson, de Schweitzer, en un artículo reciente, aportan varios consejos para asegurar los sistemas SCADA, agrupados en dos categorías: técnicas de mitigación (IPSec, encriptación fuerte, contraseñas seguras, etc.) y detección de intrusiones.
¿Cómo compartir información de forma segura entre el sistema de control y el resto de la empresa? Estableciendo una zona desmilitarizada (DMZ); es decir, utilizando cortafuegos, VPN, proxys inversos, etc. para restringir el tráfico entre ambas redes. Cisco ha publicado unos principios de diseño de este tipo de arquitectura.
Hace tiempo que las redes inalámbricas entraron en los sistemas de control industrial. Estas redes tienen requisitos de seguridad adicionales, puesto que ni siquiera existe protección en el acceso al medio físico. Entre otras cosas, WPA2, VLAN, PMF, cortafuegos…

KNX (1)

publicado en: Domótica, KNX | 1

Uno de los protocolos más extendidos en domótica es el KNX. Aunque como tal su estándar se publicó en 2001, hay que hacer notar que ya tenía una década de recorrido bajo el nombre de EIB (European Installation Bus) o Instabus. Su origen hay que buscarlo por tanto hace 25 años, cuando quince compañías europeas, entre ellas Siemens, acordaron unas especificaciones comunes para las instalaciones domóticas. EIB utilizó desde sus inicios un par trenzado (TP1, de Twisted Pair) como medio de transporte. La configuración de los dispositivos se hacía mediante una herramienta independiente, ETS (EIB Tool Software). Con los años se decidió la convergencia con otros dos buses empleados en domótica, a saber: EHS (European Home Systems), que aprovecha las instalaciones eléctricas preexistentes (PLC, power line communication), y BatiBUS. De dicha unificación surgió KNX, si bien el estándar se ha ido ampliando con comunicaciones inalámbricas (KNX RF) y Ethernet (KNX IP). Durante estos años también se normalizó como EN 50090 e ISO/IEC 14543. Su administración está gestionada por la Asociación KNX.

Logo KNX
Logo KNX

KNX cubre los aspectos que se pueden esperar en un sistema domótico: iluminación, HVAC, persianas, control de accesos, audio y vídeo, etc. Por ello tiene que manejar datos con muy distinto significado o función. Al mismo tiempo, se trata de un sistema no propietario, y desde el principio se quiso desligar de cualquier plataforma o arquitectura de procesador, de modo que cada fabricante lo implementa de acuerdo a criterios propios. Y ello debe hacerse de modo que los equipos de distintas marcas puedan interactuar adecuadamente, sin requerir una configuración compleja. Otra característica de KNX es su arquitectura completamente descentralizada. Cada dispositivo habla con sus compañeros, situados incluso en otra subred, sin un maestro que gestione las comunicaciones. Lo que da lugar, como iremos viendo, a colisiones que es necesario salvar. Todas estas cuestiones obligan a una cierta vigilancia de la implementación del estándar, no sólo de las comunicaciones, sino también en cuanto al uso de tipos de datos estandarizados. El etiquetado KNX supone pues una conformidad con estos requerimientos.
Vamos a comenzar describiendo el modelo de KNX en relación con las capas OSI. En la figura inferior pueden observarse las distintas implementaciones de la capa física, que puede utilizar bien un bus de par trenzado (TP1), la red de alimentación eléctrica (PL110), comunicaciones inalámbricas (RF) o una red Ethernet (IP). Independientemente del medio, el enlace se establece mediante el direccionamiento propio de KNX, basado en la topología original de bus que se describirá más adelante. En lo que toca a la capa de aplicación, hay que distinguir el funcionamiento usual, de un sistema ya implantado, de la comunicación con las herramientas de configuración. En el segundo caso, existen varias formas de parametrizar los equipos, que se pueden agrupar en modo sistema y modo fácil. También en este nivel encontraríamos equipos de integración como supervisores, pasarelas, etc.

Modelo KNX
Modelo KNX

Para desgranar los detalles del estándar, voy a centrarme de momento en las especificaciones para par trenzado y relegaremos las variantes (PL100, FR, IP). La razón principal es que de ella, como he comentado, hereda la topología lógica de KNX, y por tanto el direccionamiento de los dispositivos se concibe con esta perspectiva. Una instalación de KNX está formada en general por un bus troncal que enlaza varios buses principales, que a su vez unen mediante acopladores buses secundarios. Un bus secundario podría típicamente cubrir una planta de un edificio, mientras que el primario recorrería la vertical; el bus troncal uniría varios edificios cercanos. Pero insisto, es sólo una posibilidad, y en último término debe entenderse que ésta es la topología lógica y no tiene por qué corresponderse con la física (imaginar por ejemplo una comunicación por radiofrecuencia).
El direccionamiento de cada elemento en esta red se realiza mediante dos bytes, que hacen referencia a un bus y al dispositivo dentro de dicho bus. El primer byte se puede dividir por otra parte en dos mitades: la primera indica el área dentro del dominio (es decir, el bus principal), y la segunda, el bus secundario. Por tanto, una instalación puede tener 16 áreas, cada una de ellas con 16 buses secundarios, y dentro de cada uno de ellos 256 dispositivos, con lo que se pueden direccionar 65536 dispositivos. En realidad habría que aclarar que para el bus troncal se reserva el número 0 (y el término área no sería por tanto adecuado), y lo mismo sucede con los buses principales; es una cuestión de terminología, y no afecta a lo expuesto. Cuando se habla de KNX sobre TP1, hay que hacer notar que por cuestiones de alimentación no se admiten segmentos de bus con más de 64 elementos; el inconveniente se soslaya introduciendo fuentes adicionales.

Topología KNX
Topología KNX

Esta entrada continúa en KNX (2).