Licitación de un Scada para la administración pública
Rubén Palomino
En la era de la Industria 4.0, la licitación de sistemas Scada o sistemas BMS se ha convertido en un elemento clave para implantar sistemas de supervisión y control en infraestructuras industriales y técnicas gestionadas por la administración pública.
Para poder licitar estos sistemas, los organismos públicos sacan a concurso estos trabajos en base a un proyecto técnico o un pliego de condiciones técnicas.
El problema estriba en los profesionales encargados de realizar dicho proyecto o pliego, que, por decirlo de alguna manera, no pertenecen al sector del control industrial.
Problemas más habituales a la hora de licitar un Scada
Enumeramos los problemas más habituales que suelen presentarse al interpretar dichos pliegos o proyectos técnicos, y así elaborar un presupuesto acorde con las necesidades reales de la instalación.
Muchas veces lo indicado en el proyecto no cumple con las necesidades o está anticuado o no sirve.
Esto ocurre con frecuencia en proyectos de sistemas Scada para administración pública, donde la definición técnica del sistema de supervisión no siempre está alineada con las necesidades reales de la instalación.
- CREER QUE UN PROGRAMA SE MIDE EN METROS LINEALES
- LOS CONTROLADORES NO SON LOS ADECUADOS POR COPIAR PLIEGOS ANTIGUOS
- SOLICITAR UN SCADA SIN DEFINIR PRIMERO LAS NECESIDADES DEL PROYECTO
- MEZCLAR LENGUAJES DE PROGRAMACIÓN QUE NO TIENEN RELACION ENTRE SI
Tratar el programa como metros lineales
Un error bastante habitual en los proyectos es tratar la partida de Scada como si se tratara de una medición tradicional de obra, por ejemplo metros lineales o unidades claramente cuantificables.
En ocasiones se tiende a pensar que cuantas más líneas de código o más programación se realice, mayor debería ser el coste del desarrollo.
Sin embargo, esto no es necesariamente cierto. Un buen programador, como norma general, suele utilizar menos líneas de programación que un programador medio, ya que aplica estructuras más eficientes y reutiliza bloques de código.
Además, en el desarrollo de software suele aplicarse la conocida regla del 80-20: aproximadamente el 20 % del tiempo se dedica a la programación inicial y el 80 % restante a depuración, pruebas y ajustes del sistema.
En el caso de la programación industrial esta proporción puede ser todavía más extrema, llegando en muchos casos a un 90-10. Esto se debe a que las pruebas del sistema no dependen únicamente del programador, sino también del trabajo de otros profesionales como mecánicos, electricistas o instrumentistas.
Por este motivo, el trabajo de programación en sistemas Scada se ve fuertemente condicionado por el avance del resto de disciplinas del proyecto.
Pongamos un ejemplo: En una instalación de bombeo, pensada inicialmente para trabajar con dos bombas. Durante los trabajos de instalación los técnicos se percatan de que el agua viene con demasiada arena y tienen que modificar el ciclo de limpieza de los filtros, ya que se colmatan muy rápido y no llega caudal de aspiración a las bombas. Dicha modificación se tiene que realizar cambiando el programa original.
De aplicar este criterio se premiaría al programador ineficiente y se penalizaría al buen programador.
Los controladores no son los adecuados, por copiar pliegos antiguos
Podríamos decir que este problema es general en todas las licitaciones.
Esto es así, porque los profesionales que redactan los proyectos no están actualizados en estas materias, como si lo están los profesionales de la automatización.
Un plc con más de 10 años de antigüedad no se puede utilizar como referencia para una instalación actual.
Actualmente, la mayoría de los protocolos utilizados en la industria trabajan sobre TCP/IP. Pero en las licitaciones todavía exigen que los controladores trabajen con protocolos obsoletos del tipo:
- módulos GSM 2G.
- conexiones RS232
- protocolos punto a punto
Como los PLCs son modelos obsoletos, la mayoría de los distribuidores han dejado de suministrar dichos controladores. Y conseguirlos se convierte en una verdadera aventura que no siempre termina bien, o son muy caros o simplemente ya no están en el mercado.
Por no hablar de la capacidad de memoria tanto para almacenar como para programar.
Por poner un ejemplo: Si un proyecto no define con claridad las necesidades de programación o simplemente que se quiere conseguir, puede darse el caso que materiales listados en el pliego sean difíciles de implementar en la instalación o simplemente inútiles.
Ante esta situación, el automatista puede encontrarse con un problema con dos posibles soluciones (y ninguna buena).
-
Ejecutar la obra con material antiguo: Esto implicaría programar controladores más antiguos que pueden no dar solución a las necesidades de la instalación y condenar una instalación nueva a envejecer antes de tiempo por instalar material con menor plazo para descatalogarse.
-
Ejecutar la obra como se debe, con el material moderno y adecuado. Pero se corre el riesgo de que al no ser el material exigido en la licitación ponga en riesgo la certificación posterior o el cobro del trabajo.
Hoy día la gestión de la mayoría de las instalaciones se realiza de forma remota, por lo que los sistemas de control deben estar preparados para comunicaciones modernas, mantenimiento remoto y ampliaciones futuras.
De aplicar este criterio en la industria estaríamos todavía con cuadros eléctricos funcionando con relés.
Solicitar un Scada sin definir primero las necesidades del proyecto
Uno de los errores más habituales en las licitaciones de sistemas Scada es solicitar la implantación del sistema sin definir previamente qué información se desea obtener de la instalación.
Al igual que los anteriores, este es un error recurrente dentro de las licitaciones que incorporan sistemas de Monitorización remota o sistemas Scada.
En lugar de definir qué variables o parámetros son necesarios monitorizar, registrar o supervisar, se centran en describir qué tipo de Scada es necesario. Pero esta descripción la realizan copiando las características técnicas que las marcas publican en sus catálogos.
Puede darse el caso de incorporar en un mismo pliego características incompatibles. Poniendo al automatista otra vez frente a la doble disyuntiva de incorporar lo que solicita el proyecto o que realmente es necesario.
Una forma correcta de hacerlo sería marcar las necesidades. Si se quiere implementar un sistema de alarmas, bastaría con indicar sistema de alarmas con gestión de avisos por email y sms, reconocimiento de las mismas por personal autorizado con registro de hora de inicio y fin
De esta forma el automatista sabe qué características debe tener el Scada para cumplir con el pliego, permitiendo configurar tanto el Scada como el hardware necesario. Se puede dar el caso de que el hardware definido en el pliego no cumpla con las exigencias de un sistema en red moderno, o que los dispositivos de red instalados sean incompatibles con protocolos antiguos y encontrar equipos compatibles sea una verdadera odisea.
Si ponemos un ejemplo más sencillo sería como pedir un ordenador con puerto LPT para impresoras, cuando ninguna impresora incorpora puerto LPT.
Mezclar lenguajes de programación que no tienen relación entre sí
En este apartado vamos a utilizar un texto copiado de una licitación real. El texto decía así.
Software de Supervisión Scada Abierto:
• Desarrollado en Microsoft .NET. • Arquitectura cliente - servidor con posibilidad de servidor redundante de alta disponibilidad. • 1 puesto servidor cliente. • Protocolos abiertos estándar para los gráficos (XAML) • MS SQL Server 2017. • Drivers y protocolos de comunicación integrados: BACnet, OPC v2.0 DA, OPC UA Server/Client, Modbus RTU, Modbus TCP, SNMP, M-bus, KNX/EIB, Dali y EnOcean. • Lenguajes IEC-61131-3 y/o en lenguajes de alto nivel C#. • Programación orientada a objetos. • HTML5
Por pedir que no quede, aquí se están mezclando muchas tecnologías, incluso algunas claramente obsoletas.
Si te dedicas a esto, este párrafo no necesita explicación, se entiende por sí solo.
A TENER EN CUENTA
Si te encuentras profesionalmente frente al trabajo de licitar sistemas Scada para la administración pública, es importante centrarse siempre en los objetivos reales de la instalación.
Puede que no vengan definidas las necesidades de conectividad, porque no se han definido o directamente porque no se tiene conocimiento en el momento de realizar el pliego cuales van a ser. En este caso define tu cuales serían las necesidades reales que necesitaría un Scada para cumplir con los objetivos.
Y si aún así sigues teniendo dudas, puedes solicitar nuestros servicios.
O si necesitas asesoramiento para redactar un pliego técnico o una licitación de sistemas Scada para administración pública o instalaciones industriales, podemos ayudarte a definir correctamente los requisitos técnicos.
Planteanos tus dudas en el siguiente formulario.
* Tus datos se usarán únicamente para responder a tu consulta. No se comparten con terceros.
Si no quieres hablar con nosotros pero te interesan estos temas, apúntate a nuestra newsletter.
Ya que mantenerte informado es más que una opción.
Es una obligación.
Para mantenerte informado mira aquí debajo.