Novedades 20151003

Microsiervos publicó recientemente una entrada dedicada a el PLC industrial basado en Arduino de nombre Industruino. El equipo se suma a una interesante serie de controladores similares que engrosa día a día, como el Controllino o los autómatas de Industrial Shields.
Según un estudio de Transparency Market Research, se espera un crecimiento en el mercado de la domótica de nada menos que un 26% anual (CAGR) hasta 2020. Este fuerte avance es debido a la necesidad de eficiencia en aplicaciones de iluminación, seguridad, entretenimiento y HVAC; y aunque el liderzago va de la mano de Estados Unidos y Canadá, regiones como Europa y Asia oriental están asimismo experimentando un fuerte crecimiento.
A estas alturas no hace falta incidir en las ventajas de Ethernet (no solo Industrial Ethernet) en las aplicaciones industriales: integración, estandarización en las capas bajas, etc. Ken Kao, de Advantech, destaca los aspectos que van a verse potenciados gracias a los avances recientes, desde la convergencia con el IoT o las mejoras en fiabilidad y diagnóstico hasta la reducción de precio de los switches gestionados.
Cuando en 2011 orienté mi TFM hacia el uso del lenguaje natural en sistemas de control, tenía claro que la penetración de estas tecnologías en el ámbito industrial iba a resultar costosa, por razones de seguridad, entre otras. La domótica no tiene unas exigencias tan estrictas. El pasado viernes, ABB presentó una versión mejorada de free@home, un sistema para controlar edificios inteligentes mediante comandos de voz. Por los pocos detalles que he visto, debe de utilizar una gramática libre de contexto; en sí, no es novedoso, pero supone un paso adelante en la dirección hacia la que debe evolucionar el sector.
Estos días descubrí Shodan en el siguiente artículo del Instituto Nacional de Ciberseguridad, que habla sobre amenazas en los sistemas de control industrial. Tras describir las consecuencias de un accidente de este tipo y presentar algunos ejemplos (la fuga en Union Carbide en 1985, que propiamente fue un error de programación, los vertidos de Maroochy en el 2000, Stuxnet, Dragonfly…), recoge unas breves buenas prácticas.
El Instituto Nacional de Ciberseguridad también ha publicado una presentación sobre Diagnóstico de Ciberseguridad en Entornos Industriales. En las primeras diapositivas describe en qué consiste una auditoría a este nivel, para después analizar las arquitecturas de red en industria, la detección de amenazas y los mecanismos de seguridad.
Para terminar, un vídeo breve para aclarar la relación entre Internet of Things (IoT), Industrial Internet of Things (IIoT) y la industria 4.0.

Shodan

publicado en: Seguridad | 0

En la red existen varias herramientas para la detección de vulnerabilidades en sistemas de control. Voy a dedicarle unas líneas a una de ellas, Shodan, un motor de búsqueda que registra puertos abiertos de direcciones públicas, y que puede usarse con dicho fin. Veamos primero un ejemplo básico de uso. La página nos muestra un campo de texto, donde podemos, por ejemplo, introducir un término como “IPCamera_Logo”, texto con el que se identifica el webserver de las cámaras Maygion. Shodan nos ofrece varias páginas de resultados:
Cámaras IP
Si vamos abriendo cada uno de los enlaces podemos comprobar con sorpresa que pocas piden siquiera identificación. Por lo que he visto, la mayoría son residenciales, y parece que sus propietarios las usan para vigilar la entrada de la casa, el garaje, etc.
Apuntemos más directamente a los sistemas de control industrial. Shodan permite usar ciertas etiquetas en las búsquedas, de modo que podemos filtrar los resultados por el puerto que está abierto o el país de origen, por ejemplo. Nos podemos centrar en un protocolo tan extendido como Modbus TCP, que suele emplear el puerto 502, y buscar vulnerabilidades en España, con la cadena “port:502 country:ES”:
Vulnerabilidades Modbus
Para comprobar las vulnerabilidades podemos usar un maestro Modbus, de los cuales existen varios gratuitos para evaluación. No daré información sobre la conexión que he elegido para la siguiente prueba, pero menciono que corresponde a un importante organismo (tampoco se trata necesariamente una vulnerabilidad, quizás existe una razón que desconozco por la cual esta conexión está accesible a todo el mundo). Podemos observar que se comparte cierta información, que tal vez también se pueda modificar.
Datos Modbus
De la misma forma se puede buscar puertos abiertos correspondientes a otros protocolos (44818 o 2222 para EtherNet/IP, 34962 para Profinet, 47808 para Bacnet/IP, etc.). Para quien quiera entretenerse, también puede utilizar el buscador chino ZoomEye, que usa una filosofía semejante a Shodan.

Novedades 20150920

Si alguna vez os habéis preguntado -como yo- el porqué de los 50Hz en Europa y 60Hz en América, entonces es que nos hemos quedado cortos. ¿Por qué no 25, 40, 53, 62’5, 66+2/3, 125, 130, 133+1/3 o 140Hz? Me ha divertido el artículo El origen de las frecuencias eléctricas ¿Por qué 50 y 60 Hz?, publicado por E. Aznar y J. Royo en el número 242 de Técnica Industrial (vía Nueva Tribuna)
¿Qué claves hay que atender a la hora de seleccionar un software SCADA? Wonderware, parte interesada, las resume así: comunicación con el hardware existente y futuro, funcionalidad, disponibilidad, soporte a largo plazo y seguridad. Quiero destacar una idea expresa de forma transversal: el usuario final suele incorrectamente concebir el sistema de control como una instalación completa y cerrada. Pero las instalaciones sufren modificaciones y ampliaciones, y las tecnologías evolucionan. Con dichos cambios, el SCADA debe adaptarse, como un elemento orgánico.
Siemens publica con frecuencia, en sus páginas de soporte, documentación, librerías y ejemplos que aportan valor adicional a los productos. Recientemente ha difundido dos recursos que me parecen de bastante interés. El primero es un manual que describe cómo acceder a bases de datos desde un S7-1500 y realizar las consultas habituales (selección, inserción, actualización y borrado). El segundo es un conjunto de librerías que dotan a WinCC de herramientas de uso común: calculadora, calendario, bloc de notas, chat, conversor de unidades, teclados y códigos QR.
Varios nos hemos preguntado en algún momento qué significa eso de smart city y por qué está armando tanto revuelo. Schneider Electric ha publicado un pequeño informe describiendo este nuevo concepto, la aplicación de las nuevas tecnologías de forma organizada para una gestión global del entorno urbano. Quien se quiera ahorrar la lectura completa, puede ir a la figura 5, donde desgrana los principales servicios que se pueden integrar.
Un motor paso a paso y un servo son constructivamente muy parecidos, y se usan con propósitos similares, pero sus características son muy diferentes. Danielle Collins describe los principios de funcionamiento y mecanismos de control de ambos. También de la misma autora, una descripción de los motores piezoeléctricos, que presentan algunas características notables en aplicaciones donde se requieran desplazamientos pequeños y limitados: gran torque, eficiencia y resolución mantenimiento casi nulo, etc.
Y para cerrar, un vídeo. Hay que admitir que ABB sabe vender sus productos. Con todos vosotros, YuMi, el robot que sabe hacer aviones de papel:

Librería Users.js (2). Identificación

publicado en: Diseño web | 0

Anteriormente he descrito cómo se construye un formulario de registro de usuarios. Comentaba que, terminado el envío, era tarea del servidor enviar un correo electrónico de confirmación, lo que permite asegurar que quien aporta los datos es efectivamente el dueño de la cuenta. Pero es necesario un paso adicional para completar este chequeo: el usuario debe proporcionar al servidor un código contenido en dicho correo que sirva como confirmación. Lo usual es generar una clave cuya devolución se pide, por lo general incluyéndola como una variable en una URL. El servidor la recibe mediante el método GET y completa la validación del usuario. Y en tal caso, lo adecuado es enviar un segundo correo para informar de ello. No se describen estos pasos en detalle, ya que el propósito de estas entradas es presentar la librería Users.js, que recoge el código en Javascript para la gestión de usuarios.
Terminado el registro, podemos continuar con la identificación. Para llevarla a cabo, es necesario que la página web contenga inicialmente dos campos: un identificador (que en nuestro caso es el alias que hemos introducido en el registro, pero bien podría valer el correo electrónico) y la contraseña. También se debe dar posibilidad a restaurar dicha contraseña en caso de olvido, y de registrarse en caso de no haberlo hecho antes. Para estos dos fines se incluyen los botones correspondientes.

Como en otras ocasiones, se ha reservado una etiqueta span para mostrar mensajes de error. El más importante es la advertencia de que nos hemos equivocado al introducir el nombre o la contraseña.

Hago notar que el contenido del formulario de identificación no se muestra inicialmente, sino que se ha mantenido oculto. La razón es que se pretende usar la misma página para el acceso inicial y el contenido una vez ya nos hemos identificado. Haciendo esto se evita que el navegador salte a una página nueva, con el consiguiente retraso en la recarga. Esto mejora la experiencia de usuario, pero nos enfrenta a un problema: cuando se muestra la página por primera vez, es necesario averiguar si el usuario se ha identificado o no previamente. Como esta información no la almacena el navegador, sino el servidor en una variable de sesión, debemos de gestionar desde Javascript una consulta inicial para conocer este valor. Esta tarea, y la actualización de la página que lleva asociada, la he llevado a la función refresh_user que se ve ha visto al final del código del evento de envío de datos identificativos.

La función refresh_user hace visible (parte else) el formulario de identificación caso de que no se haya iniciado sesión. Pero si ya lo ha hecho, lo que se visibiliza es la capa registered, donde se muestra todo lo que debe verse al estar ya dentro. Esto incluye varios elementos:

  • El nombre de usuario.
  • El botón para cerrar sesión.
  • El botón para modificar datos del perfil. No voy a entrar en detalles sobre esta parte, para no hacer farragosa la entrada pero, como puede observarse, aunque los campos estén ocultos, se han rellenado con el código previo.
  • Y todo lo demás, que no se muestra por ser específico de cada proyecto, pero que estaría recogido dentro de la capa registered.

Por último, y me dejo algunos aspectos como la modificación de datos o la restauración de contraseña, es importante incluir la desconexión, que como se ve en el código de arriba se hace desde el botón logout. Dicho cierre se realiza desde el servidor, liberando todas las variables de sesión que se hayan podido crear, de modo que el código Javascript sólo debe hacer la llamada correspondiente y refrescar la página:

Recursos asociados:
Librería User.js para gestión de usuarios
Ejemplo de uso de la librería User.js

Historia de OPC

publicado en: OPC | 0

El estándar OPC (inicialmente OLE for Proccess Control, pero renombrado Open Platform Communications) surgió a mediados de los años 90 como una tecnología para la comunicación del software SCADA y otros HMI con los dispositivos de control en el ámbito de la industria. Consiste en realidad en un conjunto de especificaciones que resuelven diferentes tareas imprescindibles en este ámbito, para lo cual hacen uso de tecnologías estándar del mercado. El principal acicate para su desarrollo fue la superación de las insuficiencias que presentaban los sistemas basados en DDE, en particular su escaso rendimiento y la incompatibilidad de las distintas extensiones que los fabricantes habían introducido para solventarlo.

Arquitectura OPC
Arquitectura OPC

OPC se basaba originalmente en la tecnología OLE/DCOM de Microsoft. Las especificaciones iniciales fueron desarrolladas por la OPC Task Force, una institución promovida por varias de las principales compañías del sector: Fisher-Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell y Siemens AG. En agosto de 1996 se liberó una primera versión de las especificaciones (OPC Specification Version 1.0), basadas en las tecnologías COM (Component Object Model), OLE (Object Linking and Embedding) y DCOM (Distributed Component Model). La primera definía un sistema de comunicación entre procesos y de creación dinámica de objetos de forma neutral; es decir, éstos podían ser utilizados posteriormente en entornos de desarrollos distintos al de creación original. La segunda, OLE, establecía mecanismos de mantenimiento y gestión de datos y archivos de forma que pudiesen tratarse por distintas aplicaciones. La última, DCOM permitía la creación de componentes distribuidos de software en diferentes sistemas intercomunicados.
Uno de sus mayores retos del estándar OPC ha sido adaptarse a un dominio en continuo cambio, para lo que se optó desde sus orígenes por una estrategia que permitiese enriquecerlo de forma constante por medio de adiciones básicas. Esto se vino llevando a cabo inicialmente mediante distintos documentos Data Access Specification, que recogían las incorporaciones a los mecanismos y funcionalidad de lectura y escritura de datos de proceso. Paralelamente, OPC se veía enriquecido por la adición de servicios de interés en el ámbito industrial. A la primera versión del protocolo, que pasó a denominarse OPC DA (Data Access) y establecía cómo debía realizarse el intercambio de datos de tiempo real entre servidores y clientes, se le incorporó en 1999 la posibilidad de gestionar el tráfico de alarmas y eventos entre servidores y clientes, OPC AE (Alarms and Events Specification), y en el año 2000 se le agregó una capacidad semejante de manejo de datos históricos, OPC HDA (Historical Data Access Specification). También en dicho año se definieron e implementaron políticas de seguridad, OPC S (Security Specification). Otras adiciones posteriores fueron las recogidas en la OPC Batch Specification, para la gestión de tareas, la OPC XML-DA Specification para servicios web a través de XML y SOAP, o la OPC DX Specification, que define la comunicación de servidor a servidor sin uso de clientes. La comunicación entre servidores, que requieren mensajes con tipos de datos más complejos, se efectúa gracias a OPC CD (Complex Data). Entre los últimos protocolos incorporados al estándar se encuentra OPC C (Commands), que dota a clientes y servidores de un conjunto de interfaces para indentificar, enviar y moonitorizar comandos de control.
Actualmente, el rápido crecimiento en el número de productos que incorporan OPC, así como sus capacidades, han hecho de éste el estándar industrial con más aceptación. La OPC Foundation es la organización encargada de crear y mantener las especificaciones de forma abierta.
Conforme DCOM fue reemplazándose por la tecnología .NET, que permitía un desarrollo ágil en redes y entornos Web, OPC debió adaptar sus interfaces a dicha plataforma. La última API liberada del OPC clásico, conocida formalmente como OPC Express Interface (Xi), se basa en el modelo .NET 4.0 WCF (Windows Communication Foundation). Provee de una envoltura a las interfaces clásicas, y permite un uso más seguro a través de redes por medio de mecanismos de autentificación, autorización y encriptación de datos. También simplifica el acceso a través de cortafuegos, al requerir sólo la apertura de dos puertos.
Desde el año 2006, la OPC Foundation, en conjunción con el MTConnect Institute, viene trabajando en una versión unificada de los estándares (OPC UA, o Unified Architecture), con miras a avanzar hacia una arquitectura orientada a servicios de tipo multiplataforma. Gracias a esto se elimina la tradicional dependencia de Microsoft Windows de los protocolos de control industrial. OPC UA se beneficia de las características que proporcionan el conjunto de estándares descrito, a las que se une la ventaja de ser portable a otros sistemas operativos. Para ello, OPC abandona definitivamente el modelo DCOM y se constituye en una arquitectura orientada a servicios (SOA, Service Oriented Architecture). Existen interfaces de programación (API) implementadas para C, C++, .NET, Java, NodeJS y Python. Otras ventajas que aporta son la seguridad revisada, el modelo de información, redundancia, buffering de datos o monitorización de los enlaces.

Arquitectura de OPC UA
Arquitectura de OPC UA