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.

Consejos para programar secuencias (3)

publicado en: PLC, SFC | 0

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

  • El lenguaje no es barrera
    Los PLC de gama baja no suelen contar con un entorno de desarrollo en SFC. Esto no debe ser un obstáculo para programar una secuencia. Veamos cómo se hace. Para ello nos vamos a basar en la siguiente secuencia. En ella, después del primer paso, se pueden seguir dos caminos alternativos: o bien se continúa por los pasos 2 y 3, o bien se lanzan dos procesos paralelos (las subsecuencias 4-5 y 6-7). En todo caso, se termina siempre en el paso 8.
    no-hay-barrera-1
    Si los puristas me perdonan, una secuencia es lo que en informática se denomina una máquina de estados o un autómata finito. Cada uno de los estados (pasos) puede representarse por un bit, que estará activo o desactivado. En la situación inicial todos los estados están desactivados. Cuando se cumple la condición C_0_1, entramos en el primer paso, lo cual se hace activando S_1 y desactivando INICIO:
    no-hay-barrera-2
    Para avanzar del paso 1 al 2 tiene que cumplirse la condición C_1_2. Se programa así:
    no-hay-barrera-3
    Pero también es posible, como se ha comentado, iniciar dos subsecuencias (pasos 4 y 6), si se cumple la condición C_1_4y6:
    no-hay-barrera-4
    Y de forma similar se va gestionando el flujo de la secuencia. Represento a continuación el paso 8, que puede parecer uno de los más complejos, al accederse de diferentes formas:
    no-hay-barrera-5
    Como se puede observar, este método nos permite construir cualquier secuencia con lenguajes disponibles en controladores de bajo nivel. Eso sí, hay que ser muy cuidadoso en la traducción, puesto que un error puede con facilidad hacer que su marcha se detenga, o activar simultáneamente dos pasos incompatibles. Además, el desarrollo y la depuración resultan muy engorrosos.
  • Índices
    Una alternativa a los bits antes comentados es emplear un registro en la memoria como índice del paso que se está siguiendo. Es decir, una cierta variable almacena los valores 1, 2, 3, 4…, y se incrementa conforme se avanza en la secuencia. En función de dicho valor, se realizan unas acciones u otras. Si se requieren subsecuencias, se emplean varios índices. Tienen el inconveniente de tener que recurrir a comparaciones para conocer el paso activo, y la ventaja de que evitan de forma natural extravíos en la evolución. Personalmente prefiero el uso de bits, pero debo reconocer que las razones son conceptuales, si no estéticas.

Esta entrada continúa en Consejos para programar secuencias (4)

Novedades 20150804

publicado en: Comunicaciones, Seguridad | 0

A la hora de determinar la sucesión correcta de alarmas o datos registrados, es vital mantener los equipos sincronizados de forma precisa. Esta necesidad es tanto más crítica en áreas con tiempos de respuesta muy reducidos, como por ejemplo la distribución eléctrica. Rob Henderson, de Maverick, describe los protocolos que cumplen esta función.
Una de las características ventajosas de Profibus es el diagnóstico de los elementos de comunicación. Tanto es así que el propio protocolo contempla para cualquier esclavo la detección de fallos del propio dispositivo o del canal. Carl Henning lo describe de forma clara en dos entradas (1 y 2).
Este mes de julio se han cumplido cinco años del descubrimiento del primer software malicioso de cierta relevancia en automática, Stuxnet. Como sabéis, consistió en un gusano diseñado con un alto grado de sofisticación. Se propagaba desde memorias USB a través de Windows y software de Siemens hasta autómatas que controlaban centrífugas, a las que aceleraban para producir fallo. Su destino era el sabotaje de plantas de enriquecimiento de uranio iranís, a varias de las cuales comprometieron.
El estándar IEC 61850 se usa utiliza en subestaciones eléctricas y, entre otras cosas, detalla las comunicaciones entre equipos, modelo y almacenamiento de datos, seguridades y comandos. Para ello define varios protocolos (MMS, GOOSE, SMV, servicios web), pero su flexibilidad acarrea también confusión, como se detalla en el siguiente artículo de K. Mahoney.

Consejos para programar secuencias (2)

publicado en: PLC, SFC | 0

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

  • A cada acción sigue su comprobación
    Si en un determinado paso se acciona una cinta transportadora, para avanzar al siguiente se debe recibir confirmación de marcha, o señal de una fotocélula al paso de un paquete. Si se arranca una bomba, debe de detectarse caudal, presión, llenarse un tanque, o cualquier otra cosa que dependa de dicho arranque. Las condiciones para el avance en la secuencia vienen directamente determinadas por las acciones que ésta realiza. Tanto es así que si no se realiza la comprobación es indicio de que dicho paso sobra; y si se incluye una condición adicional (no relacionada con la acción), lo que sobra es la condición.
    A veces no hay forma de detectar que la acción ha tenido efecto. En dichos casos es común introducir una temporización o exigir una confirmación del operador, que sigue siendo en el fondo una comprobación.
  • Discriminar secuencia y actuaciones
    Esto es una cuestión de orden, y supongo que cada uno tiene sus gustos al respecto. Personalmente prefiero mantener organizado de forma separada el código de las secuencias y el de funcionamiento de los equipos. Me resulta más claro tanto a la hora de hacer el seguimiento del proceso como al realizar modificaciones.
    El origen de este problema está en los propios entornos de programación, que no suelen representar de forma clara todos los elementos; y cuando lo permiten, el resultado es tan farragoso que se hace inmanejable. Para soslayar este inconveniente, lo mejor suele ser diseñar y programar por separado la secuencia, sus condiciones de avance, y las actuaciones. Estas últimas se agrupan equipo por equipo, junto con las protecciones y el resto de funcionamiento asociado. De este modo es fácil centrarse durante la puesta en marcha en el flujo general (la secuencia), en un problema concreto referido al avance (condición) o referido al equipo.
    discriminar-1
    discriminar-2

    Esta forma de estructurar el código es tanto más valiosa si se tiene en cuenta que en la práctica, durante la etapa de puesta en marcha o comisionado, es usual realizar bastantes modificaciones. Éstas darán lugar a reordenación de pasos, inclusión de nuevas ramas en la secuencia, cambio de condiciones, etc. Una organización compartimentada de la forma descrita permite alterar y rehacer el código con facilidad de acuerdo a los problemas que se van detectando.

Esta entrada continúa en Consejos para programar secuencias (3)

1 2 3 4 5 6