Consejos para programar secuencias (4)

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.

Facebooktwitterlinkedin