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)

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)

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).

Hackeando un Moeller Easy 512

publicado en: Klockner Moeller, Seguridad | 2

Situación: se necesita extraer el programa de un controlador Klockner Moeller Easy 512, pero está protegido por contraseña. La empresa canadiense que lo instaló cerró hace años y no hay otro modo de obtener el software. Personalmente no hubiese intentado hacer lo que a continuación voy a describir, porque leí en el manual que, al tercer intento fallido, el programa se borra (y se vuelve a conceder acceso). Pero no es así: quien me lo trae ha estado probando contraseñas al azar y sigue sin poder iniciar sesión. En cualquier caso, advierto: si alguien repite esto, posiblemente con un PLC con otra configuración, puede perder el programa.
Easy512
Ya en general, la seguridad en automática no ha sido nunca una cualidad destacable. Al contrario, los sistemas de control se han concebido tradicionalmente como cerrados y de acceso exclusivamente físico por personal de confianza. Es un error lamentable. Por todo el mundo hay repartida una cantidad apabullante de instalaciones desprotegidas. No quiero ser alarmista, pero se trata de una asignatura pendiente que no se debería postergar.
Retomemos el Klockner Moeller. El software de programación, EasySoft, lo primero que pide al establecer la conexión es la contraseña. Y ante fallo desconecta y no admite otra acción. Hasta aquí, poco que objetar, no hay que olvidar que hablamos de un PLC de baja gama. Lo que lo hace tan vulnerable es la limitación sobre la contraseña: cuatro caracteres numéricos. Es decir, que en pocos minutos va a caer ante un ataque de fuerza bruta.
Una opción interesante sería suplantar directamente a la aplicación (la comunicación se realiza por el puerto serie) y lanzarle intentos. Pero no disponía de mucho tiempo, así que me decanté por una alternativa que, por otra parte, puede repetirse en otros contextos, razón por la que me he animado a publicarla. Se trata de mandar pulsaciones de teclas directamente al desplegable que solicita la contraseña.
Para ello, me instalé el programa AutoHotkey. No sé si es bueno, es el primero que encontré buscando en Google. Lo que sí puedo decir es que tiene una sintaxis algo retorcida. Los script se crean con cualquier editor de texto, se graban con la extensión .ahk y están listos para ejecutar. Asigné la combinación CTRL+h para iniciar el envío de pulsaciones del teclado, y la tecla ESC para detenerlas. Manda, como he comentado, todas las contraseñas desde 0000 hasta 9999 acompañadas de dos pulsaciones de ENTER (una para el cuadro de diálogo de la contraseña y la segunda para aceptar el mensaje de error). El código es el siguiente:

^h:: ; La ejecución del scrip se inicia con CTRL+h

;=== Se prueban contraseñas desde 0000 hasta 9999
i=0
Loop, 10000
{
   v:=Format("{:04}",i)   ; Se le da formato de cuatro cifras

   Send, %v%{enter}{enter}   ; Se mandan las cuatro cifras seguidas de dos ENTER
   Sleep, 400 ; Pausa
   i++

   ;=== Para salir, pulsar la tecla ESC
   GetKeyState, state, Esc
   if state = D
   Exit
}

Es muy mejorable. Posiblemente se pueda reducir el tiempo de pausa, por ejemplo. Pero sirve con el Moeller. Basta intentar conectarse, pulsar CTRH+h cuando pide la contraseña, y dejarlo correr. Una vez que acierta, la conexión se mantiene. Se pulsa ESC para detener el envío de teclas y ya es posible guardar la copia del programa.

1 2 3 4