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:

Novedades 20150908

La robótica ha contribuido sustancialmente a la productividad de los países desarrollados. Lo confirma un estudio de la Universidad de Uppsala que analiza el periodo desde 1993 a 2007 sobre 17 países. Para poner cifras, el número de robots se incrementó un 150% al tiempo que caían los precios de los productos elaborados en varios casos hasta un 80%. Donde choca con otros análisis similares es en el efecto sobre la mano de obra, ya que el estudio encuentra aumento de desempleo u horas trabajadas, y sí de los salarios.
En muchos sectores la tendencia es la contratación de servicios, y con ello despreocuparse de instalaciones, mantenimiento, actualizaciones, etc. En esta línea, los SCADA en la nube están en auge. Pero a la hora de decantarse por un proveedor, la seguridad es crítica. Como comenta Patrick D. Howard, protocolos usuales (Modbus o DNP3) no proveen siquiera encriptación. En su artículo determina nueve puntos a tener en cuenta, a los que yo añadiría varios más: autenticación de servicios y usuarios, diferentes niveles de acceso, disponibilidad, uso de estándares…
Los controladores S7 de Siemens (300, 1200 y 1500) disponen de una librería para enviar datos que se almacenan como ficheros gracias a la aplicación TCP file server. Está también disponible el código de dicha aplicación, para quien necesite adaptaciones (se me ocurre, por ejemplo, escritura en base de datos). El recurso es muy interesante para quien desee generar informes en un sistema sin SCADA o que no pueda garantizar la conectividad continua.
El QoS (Quality of Service) es una medida de la calidad del tráfico de red, pero también hace referencia a un conjunto de técnicas que permiten priorizarlo de red en función de sus características (por protocolos, servicios, dispositivos, etc.). Nos permitirían, acudiendo a un ejemplo extremo, emplear una red de planta para la transmisión de vídeo, asignándole a éste un menor ancho de banda para no entorpecer la comunicación de otros dispositivos.
La web infoPLC tiene un repositorio bastante completo de documentación recopilada de distintos fabricantes. Va desde manuales a cursos pasando por soluciones breves a cuestiones comunes.
Y hablando de cursos, la Universidad Miguel Hernández ha compartido el temario de un curso de Automatización Industrial, muy adecuado para quien quiera iniciarse en la programación de los PLC.
Hace poco el País hacía una reflexión sobre la seguridad en el Internet de las cosas (IoT). Aunque no se puede generalizar a partir de 10 artículos, es cierto que en el mercado escasean productos con requisitos tan básicos como encriptación de las comunicaciones. Y ante un panorama previsto de 26.000.000.000 de objetos conectados en nuestro entorno cotidiano para dentro de 15 años, se trata de un problema serio.
Y a continuación, la muñeca Cayla.

Novedades 20150827

publicado en: Comunicaciones, PLC, Seguridad | 0

En un artículo dividido en dos partes (1 y 2), Jay Griffin describe los sistemas instrumentados de seguridad, que son los que deben llevar planta a situación segura bajo condiciones de riesgo, según se haya determinado en un estudio HAZOP. El texto describe los distintos niveles (desde el SIL 1, que asegura una disponibilidad del 90%, al nivel 4, del 99’99%), las aplicaciones, y cómo se lleva esta seguridad a lógica, entradas, salidas e interfaces.
La web Automation ha publicado una historia sobre los albores de los controladores lógicos programables (PLC). Por desgracia, aunque el contenido es abierto, no se dan facilidades para su lectura, que debe hacerse desde ordenador desde una interfaz engorrosa. La primera parte (página 19) describe los inicios en los 60, cuando se fraguan los ingredientes para la automatización (placas impresas, control numérico, ordenadores analógicos, terminales de vídeo). De ahí al papel de Modicon, Struthers-Dunn y por supuesto General Motors, donde los ingenieros de Hydra-Matic lograron sensibles incrementos de la productividad al reemplazar paneles de relés por controladores digitales. La segunda parte (página 18), centrada en los años 70, describe las compañías pioneras y la segunda generación de PLC.
¿Cómo implantar seguridad en lo sistemas de control? Idealmente con comunicaciones a través de VPN. Pero cuando no es posible (limitación de controladores, exigencia de tiempo real…), aún se pueden usar cortafuegos con inspección profunda de paquetes. Eric Byres, Erik Schweigert y Michael Thomas esbozan como emplearla para evitar ataques DoS o filtrar servicios, por ejemplo.
A propósito del eterno problema de las alarmas, Ian Nimmo y Stephen Maddox hacen un esfuerzo por racionalizarlas. Hay que partir de una correcta definición y priorización, pero también establecer unos valores adecuados, trabajar con operadores, plantear alarmas dinámicas, etc. Es interesante el análisis en función del tiempo de respuesta del usuario a la hora de definir límites no arbitrarios.
¿Qué diferencia un PC industrial de un PC? Tim Munro, de SEL, responde a esta pregunta definiendo las características de un equipo robusto: fiabilidad (refrigeración pasiva, discos sólidos), capacidad de servicio (fuentes redundantes, RAID) y disponibilidad. Es también interesante la introducción, que hace un repaso histórico desde el IBM 5534 hasta los hipervisores, pasando por esa época en la que nos pareció que el PLC quedaría destronado por el PC.

Consejos para programar secuencias (4)

publicado en: PLC, SFC | 0

Esta entrada es continuación de Consejos para programar secuencias (3)

  • El proceso no siempre avanza hacia adelante
    La serie no estaría completa sin mencionar el que a mi juicio es el más importante de los consejos. Emparenta con los primeros de la lista, aunque es más genérico. Y como en otros casos, nace de un problema común derivado de una mala concepción de los procesos. Tendemos a plantear el funcionamiento de las instalaciones en condiciones ideales, sin imperfecciones, sin fallas de equipos, en plena producción y sin cambios de condiciones que hagan rechazar los objetivos y reorientar las tareas. Esta visión idílica no se corresponde en absoluto con la realidad. En el día a día saltan los diferenciales, las válvulas fugan, se rompen los transmisores de señal, los finales de carrera se ensucian, hay cortes de tensión… Pero también la producción sale mal y es necesario anularla, o repetir una acción, o se ha agotado una materia prima y hace falta detener todo y reponerla. Incluso más grave, puede ser necesaria una parada de emergencia en caso de accidente. Y justo aquí es donde se distingue un buen técnico o ingeniero de uno mediocre. Una buena programación contempla todas las posibilidades, todos los saltos, y no sólo aquéllos que se definen para la consecución ideal de la secuencia.
    Sin ánimo de ser exhaustivo, quiero anotar los aspectos que considero necesario estudiar:

    • Como he mencionado, los equipos terminan por fallar, más pronto o más tarde. Para cada uno de los pasos habría que plantear el flujo de la secuencia ante fallo de cualquiera de los equipos involucrados. Es una tarea tediosa, pero obligatoria. Una solución que he planteado en el pasado ha sido distinguir entre equipos críticos y no críticos, siempre dentro de un contexto. Con críticos, me refiero a que su fallo puede ocasionar un percance. Tal puede ser, por ejemplo, un caudalímetro del que depende un lazo PID. Ante fallo de un elemento crítico se programa una salida ordenada de la secuencia. Si, en cambio, ésta puede mantenerse detenida en dicho paso a pesar del problema, prefiero dejar la decisión en manos del operario.
    • Ya que estamos, ¿qué libertad tiene el operario? Como mínimo debería poder detener la secuencia en todo instante y en condiciones seguras. Algunos sistemas usan bloques que permiten pausar, avanzar pasos, retroceder o efectuar saltos. Esto, dejado a la ligera, es potencialmente peligroso. Cada posible camino que se permita debería ir acompañado de un estudio de las consecuencias y acciones para evitar accidentes. Tampoco se puede atar de manos al personal de operación. En procesos por lotes, por ejemplo, es frecuente la necesidad de repetir un paso o un conjunto. Supongamos una reacción química que por las circunstancias (temperatura ambiente, calidad de los reactivos) no ha podido completarse. En este caso, como los puntos de chequeo suelen estar bien definidos, se puede incluir la posibilidad de retroceder en la propia secuencia. En otras circunstancias no es posible dar saltos atrás en el proceso, y la única alternativa es detenerlo. Si es así, lo ideal es habilitar dos tipos de parada: una de emergencia y otra ordenada (que puede coincidir con la descrita en el punto previo). Pausas y avances bien definidos serían un plus del desarrollo.
    • Un error simple, pero habitual: si de una secuencia dependen subsecuencias, hay que estudiar las evoluciones conjuntas. Es decir, hay que ver cómo se comportan las subsecuencias si se interrumple la principal, o si se avanza saltándose sus inicios. También merece consideración el sentido opuesto: qué hay que hacer con la secuencia principal si falla una de las hijas.
    • Cuando los equipos admiten más de una forma de control (manual/automático, local/remoto, interno/externo), nos enfrentamos a una complejidad añadida, ya que en cualquier momento un agente ajeno a la secuencia puede tomar el mando de algún equipo y operarlo de forma no prevista. Por supuesto, también la secuencia debería adaptarse a esta acción a priori no contemplada. Inicialmente puede parecer un obstáculo difícil de salvar, pero si se han seguido correctamente los pasos previos, en realidad el trabajo estaría hecho. No hay diferencia entre un equipo que no arranca por un fallo, por ejemplo, o porque el operador lo haya inhabilitado. Tampoco entre una condición que se satisface por las operaciones definidas en la secuencia o por causas ajenas.

Estas son mis recomendaciones para quienes se inicien en la programación de secuencias. En definitiva, se puede resumir lo más importante de su contenido en una regla de oro: programar a la defensiva. Es la única forma de obtener un resultado de calidad capaz de afrontar los contratiempos.

Novedades 20150810

Harry Forbes, analista de ARC, considera los beneficios que la incorporación de procesadores multinúcleo va a aportar a la automatización. El más importante, aunque no el único como da a entender el título, es la posibilidad de virtualización, tanto de controladores como de los propios dispositivos de campo. Otra posibilidad que me ha parecido muy interesante es correr simultáneamente un sistema operativo en tiempo real con otro “enriquecido” en funciones.

Para quien quiera profundizar en los protocolos existentes para redes de sensores inalámbricos, Mark Nixon, de Emerson, ha publicado una extensa comparativa entre dos de los más usados, WirelessHART y ISA100.11a. Resumiendo mucho, el primero se introduce como una extensión de HART, mientras que el segundo es más flexible, relegando buena parte de la configuración (e indefiniciones) al usuario final.

Me gusta el sistema de recetas de los S7-1200. En particular, la administración mediante páginas web servidas por el propio PLC, lo que permite, por ejemplo, gestionar y supervisar el proceso desde una tablet, bastante útil cuando se trabaja en campo.

El ingeniero de proceso Béla Lipták define cinco niveles de control en la automatización. Hay que aclarar que sólo se refiere a la regulación de magnitudes simples, lo que comúnmente denominamos -generalizando en exceso- un lazo. Los niveles serían, de menor a mayor sofisticación: control manual, con retroalimentación (un PID, por ejemplo), en cascada, anticipativo (con correcciones a la salida) y “dirigido/retrasado” (lead/lag, que prevé variaciones de carga).

Esta semana GE ha lanzado un servicio que puede dar mucho que hablar. Se trata de su propia nube, Predix, desarrollada específicamente para recoger datos generados por sistemas de control. La idea no es nueva (ya lo hacen los termostatos Nest, por ejemplo), pero el empuje que le puede dar GE va a forzar de seguro a otras compañías a invertir en estas tecnologías. Entre otras cosas, Predix promete mayor operatividad e interoperatividad, escalabilidad, y seguridad.

Cuando los valores de proceso no se reciben de periferia integrada, sino a través de comunicaciones, no siempre se dispone de tiempos de muestreo reducidos y constantes; en especial, cuando es vía inalámbrica. Los lazos PID tradicionales no se pueden usar en estas circunstancias. Un PID inteligente, como el PIDPlus, debe tener en cuenta estos tiempos extensos y variables, así como fallos de comunicación.

He descubierto el muy recomendable blog de Juan Carlos Martín Castillo: REEA (Revista de Electricidad, Electrónica y Automática). En él se se puede encontrar gran cantidad de recursos relacionados con sistemas de control. Pero me gustaría destacar la producción propia, en formato videoblog, consistente en tutoriales en los que de forma muy detallada expone casos prácticos, sin renunciar a profundizar en la teoría o herramientas aplica.

1 2 3 4