Pentacour

Atención: tocho de post que me sirve de terapia para canalizar las tensiones sufridas durante la última puesta en marcha.

Las clasificaciones dependen de lo que se quiera clasificar. Dicha esta perogrullada, una posible clasificación de los proyectos informáticos serían los que dependen únicamente de los informáticos y el cliente final, y por otro lado, los que dependen de los informáticos, profesionales de otras disciplinas y el cliente final.

En esta última clase, surgen problemas que hay que tener en cuenta, inexistentes si únicamente hay que tratar con el cliente final. Ejemplos del primer caso serían una web o un programa de gestión, en que como mucho, externamente se puede depender del ISP, pero que suelen ” hablar el mismo idioma”. Un ejemplo del segundo sería una automatización ( de un riego de cultivos, una planta, etc ). Aquí, a parte, pueden entrar en juego maquinistas, instaladores de componentes mecánicos, electricistas o electrónicos. El problema es que los informáticos piensan como informáticos, los electrónicos com tal, los electricistas, operarios, o montadores a su manera, etc. En términos informáticos, la API de intercamio de información entre estos gremios no está bien definida y puede llegar a requerir más atención nuestra de la estimada inicialmente. Y normalmente, la parte informática es la última en implementarse, con el consiguiente peligro de tener que absorber los posibles cambios o descoordinaciones en los pasos anteriores.

¿Cómo plantearse estos proyectos? Pues no tengo una lista de 10 reglas, ya que mi experiencia no es tan dilatada, pero según los casos que me he encontrado, dependerá básicamente de lo que se vaya a automatizar y de quién lleve el peso del proyecto. Por lo que he visto, contra más tierra haya, más problemas podemos tener. Es decir, si es por ejemplo una planta, seguramente el responsable de sistemas tenga claro lo que quiere y trabajará conjuntamente con los electrónicos para que controlen los procesos y con los informáticos para que recojan todos esos datos y los exploten (Scada). Pero si en el proyecto hay tierra, hay obras; y si hay obras, lógicamente el peso del proyecto lo lleven ingenieros de caminos, con jefes de obra, encargados y tal que, por lo que yo he visto, el tema de la automatización lo tienen más flojo, o al menos, están menos sensibilizados a la hora de por ejemplo, vigilar no cargarse un bus de comunicaciones con una máquina por hacer un agujero precipitadamente.

En estos proyectos, seguramente desde que se comienza la obra hasta que lleguemos nosotros a instalar el software pasen varios meses, con los consiguientes cambios que hayan podido haber durante el transcurso de ésta, algunos de los cuales podrían afectarnos directamente. Lo bueno sería identificar en nuestra aplicación cuáles son los elementos críticos que si sufriesen alguna modificación podrían tener un impacto grande sobre ella, y estar atentos durante el desarrollo de la obra por si se modificasen. Por ejemplo, en una automatización de riego de varios kilómetros, quizás hemos contado con montar 3 buses de comunicaciones y 3 puestos de control. Para ello nos han asegurado enganches eléctricos en ciertas zonas. Podría darse el caso de que uno de estos enganches se retrase mucho o que simplemente nos diga luego la compañía que ahí no puede ir: ¿nuestra aplicación es capaz de soportar un cambio de situación de los puestos de control? O hay que hacer un nuevo bus provisional porque antes de la puesta en marcha no se podrán unir dos tramos: ¿nuestra aplicación soporta el añadido de un nuevo bus? A ver, soportar lo debería soportar, pero ¿lo podemos reconfigurar fácilmente?Debemos actualizar un sistema viejo con comunicaciones por radio a uno con comunicaciones por cable. A última hora, por retrasos en las obras, vemos que no dará tiempo a actualizarlo todo antes de la puesta en marcha: ¿soporta nuestro sistema funcionar en modo mixto?

Otro punto es el intercamio de información entre la parte electrónica (autómatas, sensores, actuadores) y nosotros. Aunque informáticos y electrónicos son más afines, no hay que confiarse. Por ejemplo, en el control de algún proceso, si no lo hemos tenido que diseñar nosotros, únicamente nos deberán pasar las variables necesarias para actuar sobre él; fácil. El problema puede venir si nosotros tenemos que diseñar el algoritmo de control y no somos quienes programamos los autómatas. Se piensa un algoritmo y se le pasa a los programadores de autómatas. Pero éstos, al menos con los que yo he trabajado, suelen usar Grafcets para programarlos. De momento nunca hemos conseguido que el algoritmo haga lo que se pensó al 100%. ¿Qué suele suceder entonces? Que es la parte final, se va contrareloj, se testea y si el control funciona en líneas generales, ya está. Entonces, aún quedando pequeños detalles que en según qué circunstancias el control acaba haciendo “algo parecido” a lo pensado inicialmente, resulta difícil justificar un retraso en la entrega porque el algoritmo no actúe exactamente como se pensó, si está cumpliendo en un 95% su funcionalidad.

Como resumen, en proyectos de este tipo, mejor tener muy bien identificados los puntos críticos de nuestra aplicación y estar muy atentos a posibles cambios que les puedan afectar.

Este domingo hicimos una miniexcursión al pantano de Siurana (google maps), en Tarragona. Es un bonito embalse de algo más de 12 Hm3 situado entre la Sierra de Prades y el Montsant, en la comarca del Priorat. A parte de abastacer de agua a los pueblos de alrededor, su función principal es la de almacén para el pantano de Riudecanyes, que a su vez suministra agua a los pueblos cercanos a su red de riego, que va desde Riudecanyes hasta Reus. El paso de agua entre los dos pantanos se hace a través de un canal de 1′80 m aproximadamente que atraviesa las montañas hasta llegar al de Riudecanyes. Estas construcciones las llevaron a cabo la Comunitat de Regants del Pantà de Riudecanyes. El de Riudecanyes se comenzó en 1904. Algunos años después proyectaron el canal que desviaría parte del río Siurana hacia el de Riudecanyes. En la década de los 70, la Comunitat de Regants construyó el pantano de Siurana, que aprovecharía este mismo canal para pasar el agua.

En la Comunitat de Regants están realizando entre otras cosas, un archivo fotográfico donde se podrán ver una gran cantidad de imágenes del proceso de construcción de los dos pantanos y el canal. Cuando lo tengan terminado ya me haré eco de la noticia, porque al menos a mi, me encantan estas fotos en blanco y negro de principios del siglo pasado.

Nuestra excursión fue, dejando la presa a la espalda, bordeando el lado derecho del pantano hasta casi llegar al río. Desde aquí hay rutas que llevan hasta el pueblo de Siurana, pero para la baja forma en que estaba, y el peso de 14Kg que llevaba a mis espaldas, este tramo ya fue más que suficiente. Después nos acercamos (en coche) a Siurana desde donde hay unas maravillosas vistas, a parte de lo bonito que ya es el pueblo en si mismo.

En la excursión, tras solo poder grabar 1 minuto con la videocámara me di cuenta de que no la había cargado. Y como la cámara de fotos pide una jubilación a gritos, las únicas fotos para inmortalizar el momento y llevarnos unas imágenes representativas de la excursión tuvieron que ser con el móvil. Aquí dejo una de las mejores:

Qué bien me sienta hacer unos ejercicios que encontré hace algún tiempo. La base principal son estiramientos, control de la respiración y control del pensamiento (no pensar en nada). Al finalizarlos me encuentro muy ágil físicamente y bastante relajado mentalmente.

Si le ponemos la parte mística, le suelen llamar yoga. Pero es que no me la acabo de creer, no me convence. Así que me lo quedo pero sin la parte mística.

Dos personas, un informático que conozco muy bien y un electrónico compañero de fatigas en el trabajo. Están probando dos válvulas motorizadas en los tests previos a la puesta en marcha (sin ánimo de generalizar, solo para indicar los roles de cada uno):

inf: A ver,  quiero abrir la válvula 1 desde mi Scada y se mueve la 2. Y al abrir la 2 se mueve la 1. Parece que las tenemos al revés.

elec: Mmmmm, qué raro, no puede ser. Si este cableado lo hice yo personalmente.

inf: A ver, probémoslo otra vez… Mira, ¿ves? Abre la 2 y pulso la 1.

elec: Bueno, pues voy a mirar el programa de control del autómata a ver si se me ha pasado algo.

… minutos después …

elec: Pues no, está correcto.

info: A ver, voy a mirar mi Scada. Es raro que falle esto pero voy a mirarlo.

… minutos después …

info: Pues no, está correcto también. Auffff.

elec: Espera, vamos a ver físicamente la motorización de las válvulas, no se…

… vistazo a los actuadores de las válvulas …

info y elec: WTF!!!!! o PQC!!!!! (pero qué coñ…)

Un día antes, posible conversación entre dos intaladores de los motores de esas válvulas.

Jefe: Oye, me han dicho que un motor de estos no funciona del todo bien. No tengo recambios aquí. Como la 1 actuará antes, intercambia los motores.

Empleado: Vale jefe, pero de aquí salen unos cables hacia ese cuadro eléctrico. Mejor llamar a los electrónicos para que lo desconecten y lo tengan en cuenta.

Jefe: Anda anda, cámbialos y ya está. Y rápido, que son las 12:00 y me está empezando a entrar hambre.

Empleado: Ya, pero yo creo que les deberíamos avisar que lo hemos cambiado…

Jefe: Que nooo, que NO HACE FALTA. Eso ya lo sabrán estos ordenadores. Si no, ¿para qué sirven? Si hay que decirles todo! Anda, cámbialo ya y calla…