Consejos para programar secuencias (1)

publicado en: PLC, SFC | 0

En esta serie de entradas me gustaría recopilar varios consejos relacionados con la programación de secuencias. Están orientados específicamente a la programación de autómatas, aunque no es una limitación, y aplican a cualquier proceso que se pretenda controlar siguiendo una serie de pasos.
En la literatura abundan manuales para aprender el lenguaje SFC. Quien quiera iniciarse, puede empezar, por ejemplo, con IEC 61131–3: Programming Industrial Automation Systems de John y Tiegelkamp. En la mayoría se describe cómo se crean secuencias, cómo se estructuran sus pasos, la diferencia entre secuencias únicas y paralelas, etc. Mi intención no es repetir este tipo de contenidos, sino apuntar lo que no figura en estos textos. Me refiero a conocimientos adquiridos por la experiencia, que suelen asimilarse tarde y a veces tras haber cometido un error. Para que el interesado sepa esquivarlos a tiempo, van estas recomendaciones:

  • Evitar las secuencias
    Parece un sinsentido, pero tiene su razón. Tendemos a concebir los procesos como listados de tareas, y esta visión no siempre responde a la realidad. A veces las actuaciones se derivan de la situación instantánea de la planta o el sistema, y no de su historia pasada. En dicho caso, embutir una secuencia es introducir una complejidad innecesaria y una posible fuente de errores.
    Pongamos un ejemplo sencillo: una bomba con una válvula en su impulsión, y vamos a pedir que ésta no abra con bomba parada para no descargar la tubería. Nuestra tendencia natural es concebir la actuación en una serie de pasos:

    1. Cuando se quiere aportar, arrancar bomba
    2. Cuando la bomba esté arrancada, abrir válvula
    3. Cuando se quiere dejar de aportar, cerrar válvula
    4. Cuando la válvula está cerrada, parar bomba

    evitar-las-secuencias-1
    Por supuesto, es legítimo plantear el funcionamiento con una secuencia semejante. Pero un programa correcto debería contemplar muchas más posibilidades. En particular, tiene que responder a las siguientes situaciones:

    • ¿Qué sucede si la bomba no arranca? La secuencia se quedaría detenida en el primer paso, sin posibilidad a priori de retroceder.
    • Si se da la posibilidad de salir de la secuencia en cualquier paso, el sistema quedará normalmente en un estado anómalo.
    • Si en el primer paso el operador decide no suministrar, la secuencia debe realizar todo su recorrido para poder terminar.

    Un programa correcto debería estudiar todas las posibles anomalías durante la evolución de la secuencia. Otra opción, más sencilla, sería resolverlo de la siguiente forma:
    evitar-las-secuencias-2
    El comportamiento es el correcto ante fallos, cambios de consigna sin haber completado acciones, etc. Es la ventaja de evitar una secuencia innecesaria.
    Por supuesto, hay circunstancias que las requieren de forma obligada; por ejemplo, las limpiezas in situ (cleaning in place) en las que un mismo equipo suele cumplir diferentes funciones según la fase del proceso. Una regla para discriminar ambas situaciones es preguntarse si, sin conocer la historia pasada del proceso, sólo con la información que procede de campo, es posible inferir las actuaciones siguientes. En tal caso, la secuencia es superflua.

  • Evitar aun más los biestables
    Este es un consejo general, pero más significativo cuando se programa en SFC. Un set o reset dentro de un paso es un fallo en potencia. Peor, de los que sobreviven a la puesta en marcha y lanzan su puñalada al cabo de meses o años. La razón es simple: supongamos que un motor se arranca en el paso tres y se para en el cinco. Llegará un día en que habrá que interrumpir la secuencia en el paso cuatro y el motor quedará en marcha, con todos los perjuicios que pueda ocasionar.
    evitar-biestables-1
    El porqué se suele desarrollar de esta forma responde al mismo motivo que el punto anterior. Tendemos a pensar así, a concebir el funcionamiento como una serie de acciones, y no como situaciones. La alternativa, simple, es sustituir biestables por contactos.
    evitar-biestables-2

Esta entrada continuará en Consejos para programar secuencias (2)

Novedades 20150726

Heather MacKenzie, de Hirschmann, se pregunta cómo será la automatización industrial en en futuro (1 y 2). Su visión pasa por la fabricación inteligente, el peso y estructura de las comunicaciones en el nuevo modelo, y los retos y posibilidades que conllevan.
La automatización de los procesos por lotes es más compleja que para los continuos. Greg McMillan hace un recuento de motivos, de entre los que quiero resaltar el primero: se pueden concebir como estar arrancando y parando perpétuamente.
Algo que aprendí en Cosentino fue la ventaja estratégica que proporciona una buena comunicación entre las redes de fábrica y de negocio, los dos niveles superiores del modelo CIM, que tradicionalmente se han mantenido aislados por un mal entendido concepto de seguridad. Edmunds, Voss y Whitehead plantean varios aspectos clave en esta integración: por supuesto la seguridad, pero también la movilidad que ofrece, el acceso remoto, la computación en la nube, el uso del vídeo o la gestión energética.
Hubertus Breuer, de Siemens, nos habla de la importancia de los datos, la más valiosa “materia bruta”. Para ello, presenta varios ejemplos de uso de la información digital: el metro de Riyadh, con trenes sin conductor que operan con intervalos de 90 segundos, los sensores de turbinas de gas o el software PLM, de gestión del ciclo de vida del producto.
InfoPLC ha publicado esta semana dos tutoriales eminentemente prácticos elaborados por José M. Hurtado, que imparte en el ciclo de Automatización y Robótica Industrial del I.E.S. Himilce. El primero, sobre redes Profibus. El segundo, para quien quiera formarse en la programación de Step 7.
Hablando de formación, la empresa chilena Arian ha elaborado unas breves notas técnicas con fines educativos sobre sensores de temperatura y lazos PID. Aviso: en España nos pueden resultar extraños algunos términos (termocuplas por termopares, por ejemplo).
Y para terminar, diez consejos de la NASA para escribir código crítico. Están los clásicos (control de flujo), los esperados (no usar memoria dinámica, ámbitos reducidos) y los llamativos (las funciones deben caber en una cara de papel y contener al menos dos aserciones).

El paradigma olvidado (3). Programación lógica

publicado en: Lenguajes | 0

Cuando se tratan los lenguajes de programación, se suelen clasificar en cuatro grandes paradigmas:

  • Programación imperativa o por procedimientos, en la que el código es una secuencia de intrucciones que van alterando variables o flujo. Lenguajes típicos serían C o Pascal.
  • Programación funcional, en la que el código se asemeja a funciones o sentencias matemáticas. Por ejemplo, así es Haskell o Lisp.
  • Programación lógica, para la que un programa está compuesto por reglas (predicados), que sirven para la resolución de un problema. Tal sucede con Prolog.
  • Programación orientada a objetos. Propiamente se trata de programación imperativa, pero sus características suelen hacer que se trate independientemente. Típicos son C++ o Java.

Hay que hacer el inciso de que un paradigma no es tanto una clasificación de lenguajes como un estilo de programación; así, se puede hacer programación funcional con Java, por ejemplo.
En entradas previas de esta serie he hablado de los lenguajes de los PLC y de los HMI. Se ha visto que la programación funcional e imperativa están bastante extendidas, y que incluso se puede encontrar algún ejemplo de orientación a objetos. Hay que añadir que es común ver controladores con sistemas operativos embebidos como Linux o Windows XP, lo que permite desarrollar para ellos aplicaciones en lenguajes de alto nivel. Pero no tengo conocimiento de ningún sistema de control que use programación lógica. En realidad, este paradigma ha sido siempre el menos empleado en otros ámbitos, acaso también el menos comprendido.
Una búsqueda rápida en Google Academics nos devuelve bastantes artículos, incluso antiguos, sobre lógica difusa en sistemas de control, o redes neuronales, y en general se realiza bastante investigación en la aplicación de nuevas herramientas para abordar los problemas que la automatización plantea. También se usa la programación lógica para el modelado de autómatas. Pero no abundan los sistemas expertos que, basándose en conjuntos de reglas, descubran el procedimiento adecuado que debe seguir el sistema de control para alcanzar su objetivo. He encontrado una patente publicada en el año 1991 o, más recientemente, una propuesta de generación automática de código basándose en una descripción funcional,o una aplicación en la que la actuación de equipos se resuelve a partir de una base de conocimiento (eso sí, desde fuera del sistema de control).

Autor: Richard D. Skeirik
Autor: Richard D. Skeirik

En todo caso, un lenguaje de controlador que aplicase el paradigma lógico no sería tan ajeno como para partir de cero, y podemos imaginar fácilmente su aspecto y características. Vamos a basarnos en Prolog y lo aplicaremos a un ejemplo sencillo: un depósito con una bomba de llenado y una válvula a la salida.
bombeo-deposito
Empecemos por codificar los comportamientos de los equipos. En Prolog, el signo :- debe leerse como una implicación de derecha a izquierda (⇐).

%% Órdenes (salidas digitales) y sus confirmaciones (entradas digitales)
válvula_abierta :- válvula_abrir
válvula_cerrada :- válvula_cerrar
bomba_marcha :- bomba_orden

Es decir, abrir la válvula implica recibir señal de válvula abierta, y así con los siguientes. Este simple fragmento ya debería permitir al programa realizar inferencias. Si, por ejemplo, se manda abrir la válvula y no se recibe el final de carrera transcurrido un tiempo, podemos detectar la anomalía y generar una alarma. Esta idea concreta no forma parte de Prolog, pero sería una funcionalidad interesante fácil de implementar.
Lo original de la programación lógica es que el programador no debe encargarse de definir secuencias o acciones; se extraen de forma automática de las reglas. Por ejemplo, para esta construcción se pueden establecer la siguiente lógica, que hace uso de las boyas de máximo y mínimo nivel y el requerimiento de suministro:

%% Funcionamiento de los equipos
nivel_alto :- bomba_marcha
not(nivel_bajo) :- bomba_marcha
suministro :- válvula_abierta
not(suministro) :- válvula_cerrada

Las dos primeras líneas nos dicen que con la bomba en marcha sube el nivel (se desactiva la boya de mínimo y se activa la de máximo). Las dos siguientes, que con válvula abierta se suministra agua. Con estas reglas, que constituyen el programa en Prolog, a partir de las entradas (suministro, nivel_alto y y nivel_bajo), se deducen los valores de las salidas (válvula_abrir, válvula_cerrar y válvula_orden). El cómo lo veremos en la siguiente entrada.

Enviar datos con Arduino vía Ethernet

publicado en: Arduino | 2

Con Arduino tenía una cuenta pendiente. Me ha llegado por fin la placa y he podido hacer unas pruebas. Para iniciarme con un enfoque útil, he pensado desarrollar un programa que envíe los datos a un servidor web. La idea no es original: me la comentó mi compañero Ginés, y hay un puñado de ejemplos en Internet. A pesar de ello, es un ejercicio interesante para comenzar, y quiero orientarlo a un objetivo más general. Por eso, voy a introducir algunos elementos innecesarios en este primer desarrollo, pero que cumplirán una función más adelante. Manos a la obra.
Material con el que parto:

  • Placa Arduino Mega 2560
  • Arduino Ethernet Shield W5100

Más, como es obvio, tensión de 9V, cable USB y Ethernet. También cuento con un PC con PHP instalado y configurado.

Arduino Mega 2560
Arduino Mega 2560

En primer lugar hay que incluir en el código las librerías necesarias e introducir cierta información acerca de la conexión Ethernet:

La dirección MAC es inventada. Podemos elegir los seis bytes que queramos, siempre que no coincidan con los de otra MAC en la red. Además, debería corresponder a una dirección localmente administrada. Estas direcciones se caracterizan por tener activo el segundo bit (que se envía; corresponde con el segundo menos significativo del byte más significativo). Es decir, el primer byte es de la forma 2+4n o 3+4n.
La primera IP que aparece corresponde a la del PC que actua como servidor; y la segunda, la que le asigno al Arduino, que debe estar disponible en la red.
No debo olvidarme de comentar las librerías incluidas. SPI y Ethernet se requieren para las funciones de red y se instalan con el software de Arduino. La primera que se ha colado, en cambio, corresponde a la librería ArduinoJSON, que desarrolla Benoît Blanchon. JSON va a servir para codificar y decodificar información en forma de texto. De momento sólo voy a trabajar con entradas y salidas, y las recogeré en un array de objetos:

Cada objeto del array representa un canal, al que damos un nombre (id), un tipo (de momento sólo entradas digitales, “di”), una dirección y un valor inicial. En principio parece mucho aparato para enviar dos bits, pero espero darle justificación en publicaciones sucesivas. Estas dos entradas quedarían representadas en JSON de la siguiente forma:

Terminemos la función setup, que ha quedado a medias. Falta inicializar la periferia y la interfaz Ethernet:

El ciclo del programa va a ejecutar una tarea sencilla: actualiza los valores de root y los envía al servidor web. Para lo primero sólo hay que repasar el array buscando aquellos elementos que sean de tipo di (entrada digital). Se consulta si la entrada con dicha dirección está activa, y se actualiza su valor:

Queda la segunda parte, que es el envío. Lo voy a hacer con el método GET, por simplicidad. Para ello, basta pedir una URL incluyendo en ella el parámetro que se desea mandar. Por ejemplo, para adjuntar la cadena JSON que hemos mostrado antes sólo tendríamos que pedir la página:

La petición se va a llevar a cabo periódicamente, cada dos segundos si no hay fallos. En primera instancia se realiza la conexión con el servidor y, una vez se esté conectado, se solicita la URL anterior:

Falta una parte, la otra mitad: qué hace el servidor con los datos. De momento, puesto que esto es un ejercicio, le vamos a dar una salida simple almacenándolos en un fichero sin ningún tratamiento previo. El código en PHP es el siguiente:

Listo. A los pocos segundos de descargar el programa a la placa Arduino tenemos un fichero data.txt que va engrosando ininterrumpidamente. Y alimentando cualquiera de las dos entradas, podemos comprobar cómo su valor queda registrado.

Novedades 20150716

Innovasic publicó recientemente un par de artículos (1 y 2) orientados a desmontar varios mitos acerca de Industrial Ethernet. Un buen diseño no tiene por qué ser indeterminista, ni prescindir de comunicación inalámbrica, ni aislarla de la red de gestión. Tampoco requiere puertos dedicados o cableado industrial, entre otros.
A propósito de Industrial Ethernet, ABI Research le estima un crecimiento de un 17%, hasta alcanzar los 90 millones de nodos hacia 2020. Esto hará que protocolos como Profinet o Ethernet/IP sobrepasen a los tradicionales buses de campo, de entre los cuales Modbus es el que mantiene una posición más estable.
En el artículo anterior se menciona el concepto de industria 4.0. Es un término acuñado para referirse a la remodelación de los procesos dotándolos de adaptabilidad y eficiencia gracias a las nuevas tecnologías, y hay quienes lo consideran la cuarta revolución industrial. La idea es aumentar la productividad mediante diseño de sistemas inteligentes, digitalizados y descentralizados, que permitan la elaboración JIT y la personalización del producto.
Dos artículos sobre automatización en el transporte. En el caso de los vuelos, según Béla Lipták, la cuestión no es si dirigen humanos o robots, puesto que hace tiempo que los pilotos automáticos controlan el grueso del trayecto, sino de las condiciones en que se puede prescindir del control humano. El segundo texto describe el estado del arte en el transporte por tierra, desde el uso de computación en la nube en logística con camiones, hasta las comunicaciones en el tren.
Se ha publicado una vulnerabilidad que afecta a los servidores OFS de Schneider de versión 3.5 e inferiores, por lo que se recomienda su actualización al SP6.
Esta semana he descubierto el blog de Juan Alberto García Barroso, un espacio donde publica de forma muy didáctica acerca de automatización e instrumentación industrial. Os recomiendo las dos últimas entradas (1 y 2), sobre señales analógicas.
Quiero invitaros a ver un vídeo de José Manuel Carvajal, un amigo que diseña y contruye sus propios drones. Con el último ha sobrevolado las minas abandonadas de Alquife, que durante un tiempo fueron la principal fuente de hierro de España.