PPTP TSA 82892 SUM E INTEGRACION SCADA LLANURA MANCHEGA.pdf - Suministro e integración de nuevo scada…

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARTICULARES PARA LA CONTRATACIÓN DEL SUMINISTRO E INTEGRACIÓN DE NUEVO SCADA PARA LA EXPLOTACIÓN DE LA INFRAESTRUCTURA DE LA LLANURA MANCHEGA, EN EL MUNICIPIO DE SAELICES (CUENCA), A ADJUDICAR POR PROCEDIMIENTO ABIERTO Ref. TSA0082892 ## 1. OBJETO DEL PLIEGO El objeto del presente Pliego de Prescripciones Técnicas es definir las condiciones técnicas que habrán de cumplir quienes participen en el procedimiento de licitación para la contratación del suministro e integración de nuevo scada para la explotación de la infraestructura de la Llanura Manchega, en el municipio de Saelices (Cuenca). Este pliego, junto con el Pliego de Cláusulas Administrativas Particulares, rigen la adjudicación del contrato, su contenido y efectos, de acuerdo con lo establecido, asimismo, en la Ley 9/2017 de 8 de noviembre por la que se transponen al ordenamiento jurídico español las Directivas del Parlamento Europeo del Consejo 2014/23/UE y 2014/24/UE, de 26 de febrero de 2014 (En adelante LCSP). Dichas condiciones serán de aplicación a la totalidad del contrato y serán supervisadas y evaluadas por personal técnico de la Empresa de Transformación Agraria, SA Servicios Agrarios, S.A., S.M.E., M.P, (en lo sucesivo TRAGSA). La presentación de la proposición por el licitador supondrá la aceptación incondicionada de todas las cláusulas del presente pliego y del Pliego de Cláusulas Administrativas Particulares, sin salvedad o reserva alguna. ## 2. DESCRIPCIÓN OBJETO DEL CONTRATO ## 2.1 OBJETO DEL CONTRATO El contrato consistirá en el suministro e integración de nuevo scada en la Estación Tratamiento de Agua Potable, en el término municipal de Saelices en la provincia de Cuenca. ## 2.2 ALCANCE DEL PLIEGO El alcance del pliego se resume con el suministro de las siguientes unidades: - 1 Ud. Suministro de licencias, instalación y configuración en servidores - 1 Ud. Desarrollo de aplicación SCADA, con la funcionalidad indicada - 1 Ud. Suministro, instalación y configuración de 2 servidores para los nuevos SCADA, HPE Proliant DL380 Gen 11 o equivalente  ## 3. PRESCRIPCIONES TÉCNICAS DE LOS MATERIALES ## Suministro de licencias, instalación y configuración en servidores compuesto por: - Licencia de 2 servidores SCADA Atvise de 1500 CCD o equivalente, a instalar en cada uno de los servidores nuevos, con cliente fijo ilimitado, historiador, conexión de clientes simultáneos ilimitados y conexión de variables de PLC ilimitadas y licencia de redundancia Hot-Stanby. - Licencia de Gateway vNode o equivalente, compuesta por 2 servidores OPC UA redundantes, 2 licencias de redundancia de vías de comunicación de PLC a instalar en cada uno de los servidores nuevos y 4 licencias Modbus TCP client, 2 por servidor, para balanceo de carga. - Licencia de 2 clientes fijos Atvise ilimitado para control de Video-Wall, a instalar en cada uno de los 2 servidores nuevos. - Instalación y configuración de Atvise y vNode en servidores ## Desarrollo de aplicación SCADA, con la funcionalidad indicada, incluyendo: - Gestión de usuarios - Gestión de alarmas con notificación por Telegram. - Programación orientada a objetos. - Optimización de CCD. - Históricos. - Análisis de datos. - Cuadros de mando - Informes. - Mantenimiento planificado básico. No incluye desarrollo de mantenimiento básico ni de control de calidad ni cambios de funcionalidad en los PLC Suministro, instalación y configuración de 2 servidores para los nuevos SCADA, HPE Proliant DL380 Gen 11 o ## equivalente con: - CPU Intel Xeon-G 5416S, 2.Ghz, 16 cores o equivalente - 64GB RAM - 2x960GB SSD NVMe - 4x1Gb Ethernet - Rack 19' 2U - Fuente redundante (1+1) 1000W - Sistema operativo Debian 12 con interfaz gráfica ligera XFCE   - Monitor 27' 1920x1080 HDMI - Extensor de 30m de vídeo HDMI y USB con 4 puertos, con alimentación sólo en el lado transmisor. Incluyendo instalación de sistema operativo, configuración de servidor y hardening de equipo para securizarlo en oficina. Incluyendo instalación en centro de control de la ETAP, en armario rack, como de monitor y USB en sala de control, con pruebas de conexión a internet y a toda la red OT. 4. CONDICIONES PARTICULARES DEL SUMINISTRO El suministro del material se realizará en las instalaciones de la Estación de Tratamiento de Aguas Potable de Saelices, la cual se encuentra en la ctra CM310, KM 72. 16430, Saelices, (Cuenca) coordenadas: X:517.978, Y: 4.417.803, en los lugares ubicados para reactivos de la planta en cuestión. Se define y justifican todas las especificaciones técnicas a cumplir de SCADA ## Sistema SCADA Web Puro Los clientes deben tener acceso vía web al servidor directamente desde el navegador web, sin necesidad de instalar plugins ni software adicional. El sistema debe permitir el acceso desde cualquier dispositivo con navegador (PC, móvil y Tablet) a través de tecnología web pura (HTML5, SVG, Javascript). Esto evita problemas de instalar software en cada cliente, así como configurarlos, mantener su versión actualizada, evitar cambios en sistema operativo, pagar licencias por cada cliente, etc. El SCADA debe tener diseño responsive, para que el mismo diseño generado se adapte a la resolución de la pantalla del cliente, ya sea PC, Tablet o móvil. Esto implica gráficos vectoriales SVG. Todo el sistema debe estar basado en lenguajes estándar: HTML5, Javascript, SVG… Esta funcionalidad es indispensable. La implementación del nuevo SCADA se realizará poco a poco y es un sistema vivo, con posibilidad de cambios futuros. Cada nueva modificación en el servidor se verá inmediatamente en los clientes con sólo actualizar la sesión. Además, la propiedad podrá decidir tener nuevos clientes en cualquier momento. SCADA OPC UA cliente y servidor nativos e ingeniería orientada a objetos El SCADA debe ser cliente y servidor OPC UA nativo y soportar las especificaciones OPC UA DA, OPC UA HA, OPC UA Alarms & Conditions y OPC UA Methods, como cliente y como servidor. También deberá ser cliente OPC COM DA (clásico). Que sea un SCADA OPC UA significa que todas las comunicaciones internas del SCADA deben ser OPC UA, estandarizando al máximo la automatización de procesos. También tiene que tener ingeniería orientada a objetos por OPC UA, lo que significa interoperabilidad de datos incluso entre equipos de distintos fabricantes, ahorro en horas de desarrollo y facilidad de mantenimiento y ampliaciones del proyecto. Entre las ventajas beneficios de OPC UA se tienen: - Datos en tiempo real con PLC, SCADA y sistemas de cualquier fabricante cliente OPC UA.    - Intercambios de datos históricos de otros fabricantes: cliente y servidor OPC UA HA. Se pueden mostrar históricos de otros fabricantes directamente como históricos del SCADA, pero también históricos del SCADA en históricos de otros fabricantes. - Ingeniería de objetos verticales. ## Multiplataforma Además de los operarios localizados en la ETAP, es indispensable la existencia de usuarios con conexión web: - Operarios de la conducción que tienen que abarcar un área con distancias de cientos de km - Usuarios de planificación, supervisión o asistencia técnica que no está ubicados en la ETAP Los clientes, independientemente del sistema operativo elegido para el servidor, se pueden lanzar (sin instalación) en cualquier sistema con navegador web: Windows, Linux, MAC, Android, iOS… Esto implica que para el dispositivo cliente no haya prácticamente ninguna limitación. Puede ser PC, Tablet o móvil de cualquier fabricante y sistema operativo, simplemente tiene que tener un navegador web. El servidor se puede instalar tanto en Windows como el Linux. La opción de instalación en Linux es muy interesante por motivos de ciberseguridad . ## Redundancia hot-standby La redundancia hot-stanby es aquella en que la que los 2 servidores están encendidos y conectados entre ellos y con la red de PLC. Uno de ellos (el primario) actualiza los datos con el PLC y sirve los datos al otro (stand-by) de tal forma que ambos tienen la información actualizada y sincronizada. Es decir, los 2 servidores tendrán la misma información, tanto a nivel de datos de comunicación con PLC como alarmas e históricos. En caso de fallo del servidor primario, ya sea del servidor, del SCADA o de la comunicación con algún PLC, el servidor stand-by tomará el rol de primario, sin pérdida de datos ni de monitorización y control de la instalación. Esta gestión la realizan los servidores sin intervención del usuario. Esta es la forma más segura de redundancia, minimizando fallos y pérdidas de datos de control y faltas de continuidad de servicio. Los clientes se pueden conectar a cualquiera de los 2 servidores. Por tanto, también es redundante el telecontrol. ## Licenciamiento Se licenciará únicamente en el servidor. Los clientes y la herramienta de ingeniería no requerirán licencia. La licencia se adquiere una única vez, sin caducidad. Sólo habría que adquirir nuevas licencias es caso de querer hacer actualizaciones o ampliaciones. Como se desconoce el número de clientes simultáneos que se puede tener la licencia no puede ser por número de dispositivos clientes sino por CCD (número de variables visualizadas simultáneamente por todos los clientes conectados). El conteo de CCD sólo debe ser de variables visualizadas de comunicación con PLC o nodos del sistema SCADA. Las alarmas y datos históricos serán ilimitados.   En concreto se instalará una licencia de 1500 CCD, con clientes simultáneos ilimitados. La limitación de clientes puede venir por ancho de banda de conexión, pero no por el SCADA. Por ejemplo, puede haber 10 clientes visualizando 1500 CCD cada uno, o 3 visualizando 500, o 12 con 2 visualizando 500 y 10 visualizando 50 o cualquier combinación que no supere los 1500 CCD. Para tener el mayor número posible de conexiones simultáneas de clientes web, el desarrollo de la aplicación se debe hacer minimizando el número de variables de cada pantalla. Cada uno de los servidores contará con un cliente fijo de CCD ilimitadas que no cuenta para el cómputo de CCD de los clientes web. Para dotar de uso real al video-wall, este tendrá una licencia de cliente fijo ilimitado, licenciado en los servidores redundantes, que tampoco contará para el cómputo de CCD de los clientes web. Con esto se podría tener la funcionalidad de visualizar varias sesiones de cliente en el video-wall, cada una en una de las pantallas, consumiendo más de 1500 CCD, pudendo mostrar a la vez toda la funcionalidad más relevante y no consumir CCD de los clientes web. ## Escalabilidad El sistema debe ser escalable, de manera que las ampliaciones que puedan surgir debido a un aumento de necesidades se puedan integrar de forma rápida, sencilla y sin penalizaciones económicas (más allá del coste de la propia ampliación). Adicionalmente, el sistema debe ser capaz de crecer en número de nodos o servidores (arquitectura distribuida), intercambiándose toda la información entre ellos a través del estándar OPC UA. Esto permitirá la integración de los futuros ramales o de los núcleos cercanos. Solo se necesitaría ampliación de licencia en caso de que se quiera visualizar de manera simultánea más variables de PLC de las propuestas. ## Ingeniería 100% online La herramienta de ingeniería, con la que se hace el desarrollo de la aplicación SCADA, debe estar incluida en la licencia del servidor y ser 100% online. Esto permite el acceso, diseño, modificación, configuración y puesta en marcha de forma remota, evitando desplazamientos innecesarios, agilizando plazos de entrega y corrección de errores o implementación de modificaciones de forma más rápida y segura. Todos los cambios se podrán realizar sin detener la ejecución del servidor, es decir, permitiendo la explotación de la instalación. Esto es vital para realizar la implementación poco a poco del sistema. Para visualizar los cambios en cualquier cliente bastará con recargar la página web. ## Protocolos industriales El SCADA sólo necesita OPC UA para comunicarse con el Gateway OPC que comunica con los PLC mediante Modbus TCP. Pero pensando en la escalabilidad del sistema, el SCADA no tendrá esa limitación, soportando conectividad a través de los protocolos industriales más comunes (Modbus, Siemens, etc.) para poder comunicar con futuros PLC de diferentes fabricantes. Para esta conexión si será necesario la adquisición de la licencia correspondiente.  ## Seguridad y encriptación La conexión de clientes al servidor debe ser segura y con posibilidad de encriptación, como mínimo mediante TLS1.2 o TLS1.3, con intercambio de certificados digitales. Autenticación, auditoría y gestión de usuarios Todo usuario que pueda realizar alguna acción debe ser nominativo, y se tendrá un registro de eventos de usuarios (auditoría) para poder hacer un análisis para optimización de la explotación. La autenticación de usuarios se tiene que poder realizar al menos con formulario del SCADA y autenticación a través de la seguridad del navegador web. La auditoría de acciones de usuarios consiste en un histórico de eventos consultables desde el propio SCADA. La gestión de usuarios consiste en la creación de diferentes roles (a consensuar con la propiedad). Cada rol tendrá diferente funcionalidad, con diferentes permisos tanto de mando como de visualización, y cada usuario pertenecerá a alguno de esos roles. Para darse de alta un usuario tendrá que introducir nombre y contraseña, que deberá cumplir con políticas de seguridad a determinar (longitud de caracteres mínima, caducidad, etc.). El sistema deberá incluir auditoría mediante histórico que registre todos los eventos que hayan ocurrido: autenticaciones de usuarios, acciones realizadas por los usuarios, etc. de manera que ante alguna incidencia se pueda analizar que ha pasado en el sistema. La seguridad del sistema se basará en usuarios y contraseñas, que deberán cumplir con políticas a determinar (longitud de caracteres mínima, caducidad, etc.). Las comunicaciones podrán encriptarse, con intercambio de certificados digitales . Gestión de alarmas con notificación temprana de alarmas críticas El sistema es muy complejo (conducción principal, ramales de la conducción, ETAP, bombeo de núcleos cercanos), con posibilidad de ampliación (resto de ramales, núcleos cercanos) compuesto para varias decenas de puntos de control. Con un sistema tan grande y con tantas pantallas, una gestión adecuada de alarmas es indispensable para minimizar el tiempo de respuesta del operario y, sobretodo, una notificación temprana de alarmas críticas. La gestión de alarmas debe cumplir al menos con: - Diferentes niveles de gra vedad de alarmas: críticas, importantes, avisos… con diferente codificación de colores e iconos. Esta doble codificación minimiza el tiempo de respuesta. - Visualización gráfica indicando donde se produce la alarma. - Visualización gráfica de que el operario tiene que hacer una acción como rearme. - Congruencia entre alarmas SCADA, HMI y PLC (con rearme mediante pulsador), no pueden indicar estados distintos. - Visualización de existencia de alarmas críticas en todas las pantallas de SCADA.    - Filtrado de alarmas por instalación y equipos, con creación de páginas de alarmas activas e históricas por punto de control. - Notificación directa de alarmas críticas a operario para reducir el tiempo de actuación mediante envío de mensaje por Telegram y por email ## Scripting El SCADA debe incorporar un motor de scripting que permita programación tanto en el lado de los clientes (navegadores web) como en el lado del servidor. El lenguaje de programación debe ser Javascript, compatible con tecnologías web. Además, debe permitir programación de script en nodos y objetos, dotando al sistema de la mayor versatilidad y funcionalidad posible. ## Historiador No se va a implementar un simple SCADA, sino un SCADA con historiador, con base de datos interna que permita el desarrollo en el propio SCADA de aplicaciones de más alto nivel como cuadros de mando, mantenimiento o control de calidad básicos. Este historiador debe estar incluido en la licencia del SCADA. El historiador debe incorporar herramientas para su optimización: partición de archivos históricos, tiempo de almacenamiento de archivos, gestión de backups y purgado de archivos históricos antiguos… El historiador podrá guardar datos de bases de datos externas con estándar OPC UA HA y ser consultados como si fuesen datos internos. ## Gráficos Highchart El SCADA debe integrarse con Highchart, una de las librarías de gráficos más potentes y utilizadas en tecnología web. Esta funcionalidad eleva el valor del SCADA. Con Highchart se podrá diseñar pantallas de cuadros de mando con gráficos avanzados con datos tanto de tiempo real como históricos, permitiendo que los usuarios tengan pantallas gráficas interactivas donde poder controlar los parámetros más importantes de la instalación y pantallas de análisis de datos como, por ejemplo, análisis de calidad de agua de la ETAP. Entre los gráficos que se pueden mostrar, además de los típicos de líneas de tendencia que tiene todos los SCADA, son gráficos de barras, circulares, de tarta, histogramas, heatmap, dispersión… permitiendo mostrar indicador es de la instalación (KPI). ## Análisis de datos y visualización El SCADA debe tener herramientas para hacer análisis de datos y visualizarlos en tablas y cuadros de mando (dahsboard) dinámicos. Con las herramientas de scripting e historiador anteriormente descritas se podrá tratar los datos a analizar e historiarlos. Con highchart se podrá crear cuadros de mando dinámicos.  ## Motor de informes basado en plantillas Excel Los informes son muy importantes para una instalación tan grande. El programa más utilizado para visualizar datos es Excel. Así que el SCADA mostrará informes a partir de plantillas Excel, permitiendo construir cualquier tabla o gráfico en la misma y alimentarlos con datos del SCADA. ## Interoperabilidad e integración con bases de datos SQL Las bases de datos más utilizadas en todo el mundo son las bases de datos SQL. Por ese motivo el SCADA debe tener integración con dichas bases de datos. Esto permitirá desarrollar en el SCADA pantallas de consulta y escritura en bases de datos SQL para aplicaciones de más alto nivel. Pero para aumentar la interoperabilidad del sistema previendo ampliaciones e interconexiones futuras, el SCADA también debe tener las siguientes funcionalidades: - Integración de ficheros de texto. - Servidor y cliente REST API. - Publicador y suscriptor MQTT, con licencia adicional si se necesita ## Geolocalización El SCADA debe permitir el diseño de aplicaciones de geolocalización, tanto estáticas como dinámicas, con integración directa a las APIs de Google Maps o similares. Especialmente importante para la conducción, permitiendo mostrar un mapa de todos los puntos con la información más importante para que un operario pueda tener una visión rápida general del sistema. ## Inteligencia artificial Debe poder integrarse con agentes de inteligencia artificial para análisis de datos de cuadros de mandos . ## Soporte técnico nacional El proveedor del software deberá tener un departamento de soporte técnico dedicado en España. Adicionalmente, las licencias adquiridas deberán incluir el primer año de soporte técnico por defecto. Se defines y justifican todas las especificaciones técnicas a cumplir de GATEWAY OPC UA ## OPC UA servidor El Gateway debe ser OPC UA servidor para conexión segura y con la máxima funcionalidad con el SCADA. Al ser OPC UA Server tiene las siguientes funcionalidades y ventajas: - Estándar abierto y multiplataforma. Permite comunicación con diferentes fabricantes y software industrial, independiente del hardware o sistema operativo. - Cifrado de datos, autenticación de usuarios y control de acceso. - Comunicación no solo de valores, sino estructura, tipo y relaciones de datos, indispensable para programación orientada a objetos sin modificaciones en PLC.   - Integración con IoT y sistemas IT, no sólo con SCADA. Pero además tiene que ser redundante en la comunicación con PLC. Tiene que poder gestionar dos vías de comunicación redundantes ya que la conducción tiene dos redes. Primario por fibra óptica y secundaria por 4G. En este caso siempre habrá una red primaria, la fibra óptica. Red privada, dedicada y de alta velocidad. En caso de fallo de esta red tiene que conmutar a la secundaria. Y debe volver a la primaria cuando se restablezca ## Multiplataforma Instalable tanto en Windows como el Linux. La opción de instalación en Linux es muy interesante por motivos de ciberseguridad. Además de los operarios localizados en la ETAP, es indispensable la existencia de usuarios con conexión web ## Redundancia Indispensable redundancia entre servidores y entre vías de comunicación con PLC. Se instalarán 2 servidores SCADAS redundantes. Por tanto, en cada servidor debe haber un servidor de Gateway OPC UA redundante, uno primario y otro en stand-by. Si falla el primario, el otro toma el control automáticamente sin pérdida de servicio. Los datos y configuraciones de los dos servidores sincronizan para que la transición sea transparente. Al igual que con la redundancia del SCADA, tiene las siguientes ventajas: - Alta disponibilidad y aumento de continuidad de servicio. - Seguridad de datos: Evita pérdida de información crítica al estar duplicados en tiempo real. - Mantenimiento sin pérdida de producción: Se puede actualizar, reiniciar o modificar un servidor mientras el otro está en servicio. ## Arquitectura modular Debe tener arquitectura modular para sólo adquirir las licencias necesarias para la situación actual, pero también para poder escalar con la adquisición futura de módulos que se necesiten. Para la situación actual se deben adquirir, además del OPC UA server, los módulos de redundancia y los de cliente Modbus TCP para comunicación con PLC. Como el sistema tiene muchos PLC se podrán adquirir más de un módulo cliente Modbus TCP para balanceo de red y velocidad de adquisición. ## Licenciamiento Se licencia por módulo, pero cada módulo ni tiene limitaciones de número de tags. Especialmente importante para ser compatible con el licenciamiento de SCADA, que tampoco tiene límites de tags. ## Configuración remota y segura Herramienta de ingeniería debe ser remota al igual que la del SCADA. Todos los cambios se podrán realizar sin detener la ejecución del servidor, es decir, permitiendo la explotación de la instalación. Esto es vital para realizar la implementación poco a poco del sistema. : .   La conexión debe ser segura, mediante certificados TLS1.3 ## Funcionalidad Store&Fordward En la situación actual el Gateway OPC UA se instalará en el centro de control. Pero para futuras ampliaciones, como pueden ser los núcleos cercanos, la arquitectura debe permitir la instalación de un Gateway remoto que comunique con el central, sin pérdida de datos si falla la comunicación. Es decir, el Gateway remoto seguirá comunicando con sus PLC y, cuando la comunicación con el central se restablezca enviará todos esos datos con indicación de fecha al central, evitando pérdida de datos. ## Gestión de datos El Gateway OPC UA debe tener gestión de datos para simplificar la integración por objetos en el SCADA. Desde el propio Gateway se podrán procesar los datos, pudiendo enviar al SCADA datos crudos o procesados como cálculos. ## Soporte técnico nacional El proveedor del software deberá tener un departamento de soporte técnico dedicado en España. Adicionalmente, las licencias adquiridas deberán incluir el primer año de soporte técnico por defecto. ## SERVIDORES Tanto SCADA como Gateway OPC UA se instalará en dos servidores redundantes. El sistema es muy complejo, con muchos PLC, conexiones remotas, históricos, tratamiento de datos y scripting. Por tanto, el hardware del equipo tiene que ser suficientemente potente para gestionarlo todo con fluidez. La grabación en disco duro de datos debe ser muy rápida para la grabación y consulta de históricos. Por tanto, los discos serán NVMe. Por segmentación de redes, al menos tendrá 2 conexiones a Ethernet de 1Gb. El servidor se instalará en un cuadro de servidores con doble alimentación por SAI. Por tanto, será en f ormato rack de 19' con fuente de alimentación redundante. En cuanto al sistema operativo, debe ser servidor, para permitir múltiples tareas simultáneas y múltiples conexiones remotas. Para aumentar la seguridad será preferiblemente Linux en una versión estable y segura como Debian con una interfaz gráfica segura y ligera. Esto también evita licenciamiento de Windows Server y sus CAL. Con todo lo anterior las especificaciones mínimas del servidor serán: - CPU Intel Xeon de 16 núcleos y velocidad igual o superior a 2GHz. o equivalente - 64GB RAM - 2 discos SSD NVMe de 906GB - 2 conexiones Ethernet de 1Gb - Resolución de video de 1920x1080 - Formato en rack 19'   - Fuente de alimentación redundante - Sistema operativo servidor Linux Debian o equivalente - Monitor 27', FHD (1920x10 80), HDMI. - Extensor de 30m de vídeo HDMI y USB con 4 puertos, con alimentación sólo en el lado transmisor, para colocar monitor, teclado, ratón y puertos USB libre en los puestos de trabajo de la sala de control. ## SOLUCIÓN El software y equipamiento para conseguir la funcionalidad deseada es: ## SCADA Atvise o equivalente - 2 licencias servidor de 1500 CCD con 1 cliente fijo ilimitado en cada servidor. - 1 licencia de redundancia hot stand-by para convertir en redundantes a los 2 servidores. - 2 licencias de cliente fijo ilimitado para el video-wall. Son 2 licencias porque deben conectarse a los 2 servidores. ## Gateway OCP UA vNode o equivalente - 2 licencias OPC UA server para conectar con cada uno de los servidores SCADA. - 2 licencias de redundancia para conectar con las 2 redes redundantes de PLC de manera sincronizada. Cada licencia redundante con cada licencia OPC UA - licencias cliente Modbus TCP para conectar con los PLC balanceando la carga de cada conexión. Se instalan 2 licencia en cada servidor OPC UA. ## Servidor HP Proliant DL380 o equivalente - CPU Intel Xeon-G 5416S, 2.Ghz, 16 cores. - 64GB RAM - 2x960GB SSD NVMe - 4x1Gb Ethernet - Rack 19' 2U - Fuente redundante (1+1) 1000W - Sistema operativo Debian 12 con interfaz gráfica ligera XFCE - Monitor 27' 1920x1080 HDMI - Extensor de 30m de vídeo HDMI y USB con 4 puertos, con alimentación sólo en el lado transmisor . ## IMPLEMENTACIÓN Se definen todas las tareas de implementación del nuevo sistema, indicando requisitos, orden de ejecución, funcionalidad y objetivos .   ## Implementación poco a poco sin pérdida de servicio La implementación del nuevo SCADA se tiene que hacer en paralelo al funcionamiento actual. Los SCADA actuales (conducción y ETAP) seguirán operativos hasta que el nuevo esté completamente operativo. Por tanto, durante toda la implementación coexistirán los 2 sistemas y tienen que ser coherentes. Lo más importante durante toda la implementación es garantizar la continuidad de servicio de los SCADA existente. La instalación de nuevos equipos se debe hacer afectando lo mínimo posible la continuidad del servicio, provocando el menor número y tiempo de discontinuidad, incluso teniendo que hacerlo en los horarios que el servicio de explotación indique. ## Orden de implementación La implementación se hará en el siguiente orden, garantizando que tras cada paso el sistema queda operativo con los SCADA existentes y que los tiempos no operativos durante los cambios de cada paso sean los menores posibles y consensuados con la propiedad y servicio de explotación: 1. Adquisición de servidores SCADA. 2. Adquisición de licencias Atvise y vNode. 3. Instalación de todo el software de los servidores y configuraciones básicas en oficina técnica. 4. Instalación de nuevos equipos (servidores SCADA) en el centro de control de la ETAP, minimizando tiempo no operativo del SCADA existente. Muy importante la continuidad de servicio, pudiendo requerirse que los cambios se hagan en los horarios que menos interfieran con la explotación. 5. Modificación de configuraciones requeridas en equipos existentes, minimizando tiempo no operativo del SCADA existente. 6. Pruebas de funcionamiento de SCADA existente, para garantizar su correcto funcionamiento tras todos los cambios realizados. Es indispensable que el SCADA existente quede operativo. En caso de fallo del SCADA existente habrá que deshacer los cambios para dejarlo operativo lo antes posible y retomar las modificaciones cuando menos afecten a la explotación. 7. Pruebas de funcionamiento de nueva conexión de red con análisis de tráfico y seguridades. 8. Pruebas de conexión de nuevo SCADA a todos los PLC y conexión remota a SCADA 9. Desarrollo e implementación de nuevo SCADA de forma remota, evitando desplazamientos, implementándolo poco a poco, con la funcionalidad previamente consensuada con la propiedad y servicio de explotación, teniendo en cuenta las dependencias técnicas. Si cualquier actuación implica modificación de PLC se tendrá que hacer presencial y con puesta en marcha de PLC. En cuanto al desarrollo poco a poco de la aplicación SCADA, se consensuará orden de integración de puntos de control, teniendo en cuenta dependencias técnicas, en base a las necesidades de explotación. Un posible orden de implementación de puntos de control podría ser para dotar al sistema de la funcionalidad de la que ahora es carente: gestión de alarmas, informes, cuadros de mando, etc. Pero será consensuado con la propiedad.   ## Requisitos previos - Conexión de ETAP a internet por banda ancha con IP pública estática. - Conexión a internet vía dominio (con al menos 2 subdominios) para la gestión de certificados TLS1.2 o TLS1.3 para conexiones HTTPS seguras ## Modificación de PLC, HMI y puesta en marcha La explotación de la instalación actualmente presenta algunas deficiencias que no son del SCADA, sino de los automatismos. Con la implementación del nuevo SCADA también se corregirán dichas deficiencias modificando los PLC que se requieran. Toda modificación de PLC, por pequeña que sea, requerirá pruebas y puesta en marcha en local de los automatismos, para garantizar que la modificación no afecta al funcionamiento de la instalación. Si es necesario también requerirá modificaciones en los HMI. Las modificaciones de los PLC se integrarán en el nuevo SCADA, pero no en el existente a desaparecer. Pero hasta que no se tenga toda la funcionalidad en el nuevo no se quitará el existente. Por tanto, las modificaciones de los PLC no se harán hasta el final si afectan a la coherencia de explotación con el SCADA existente. ## INSTALACIÓN DE NUEVOS EQUIPOS Y MODIFICACIÓN DE RED ## Los equipos a instalar son: 2 servidores para servidor SCADA y Gateway OPC en rack de 19' en armario de servidores con monitores en la sala de control. Teclado y ratón en sala de control de para el video-wall . Los servidores se tienen que instalar en uno de los 2 armarios de rack situados tras el video-wall, con alimentación protegida por SAI online, para prevenir desconexiones por micro cortes o falta de calidad de la red de suministro. Los monitores, teclado y ratón se instalan en los puestos de mando de la sala de control. Por tanto, se requiere enviar vídeo y USB a unos 20 o 30m, siendo de especial importancia que no se pierda calidad vídeo, manteniendo una señal 1920x1080 en los monitores. Además, para dotar de funcionalidad al video-wall, también habrá que llevar una conexión de teclado y ratón vía USB del PC del video-wall, similar al caso de los servidores SCADA. Los equipos se tienen que conectar a la red LAN del centro de control con cables Ethernet al menos Cat5E. Además, el router de gestión de red se debe conectar al router DSL de la compañía suministradora de Internet. ## CONFIGURACIÓN DE REDES Hasta el final del desarrollo del SCADA nuevo, tiene que coexistir con los existentes. Hay que ver cómo afecta a la funcionalidad de la red redundante 4G de los PLC de la conducción la comunicación del SCADA existente y de vNode del nuevo SCADA. Esta red está gestionada por 5 router 4G con configuraciones VRRP, VPN L2L y S-NAT, gestionando de manera transparente para el SCADA el camino redundante.    Tras la finalización de la instalación de equipos y configuración de redes, tanto el SCADA existente de la conducción como el vNode del nuevo SCADA deben poder comunicar con los PLC por ambas redes. Habrá que provocar cortes de la red principal para probar esta funcionalidad. Si el SCADA existente pierde esta funcionalidad habrá que deshacer los cambios para dar continuidad de servicio y volver a estudiar la integración del SCAD nuevo. Por tanto, durante toda la implementación se tendrá la siguiente red esquemática :  ## VIDEO-WALL Actualmente, el video-wall no tiene funcionalidad real. Su uso actual es el de repetir las pantallas de los servidores de SCADA y de CCTV mediante red de video. Es decir, es un extensor de monitores. Con el nuevo sistema, el video-wall pasa a ser un cliente fijo ilimitado del SCADA, conectándose a los servidores mediante red LAN y pudiendo mostrar una información completamente distinta a lo que muestren los servidores. La idea es mostrar en el video-wall aquella información que haga que los operarios tengan una visión general de que todo el sistema está ok, con información de múltiples pantallas. Para dotar al video-wall de esta funcionalidad, se desmantela la red de video y la gestión de escenarios, salvo que la propiedad decida que quiere seguir usando una parte del video Wall para duplicar las imágenes del CCTV.  ## FUNCIONALIDAD SCADA Además de conseguir que conducción y ETAP se exploten como un único sistema, con SCADA redundante hot-standby y varios clientes web simultáneos, tendrá las siguientes funcionalidades para corregir deficiencias y mejorar la explotación del sistema: ## Alcance de la implementación del nuevo SCADA El nuevo SCADA tendrá al menos la misma funcionalidad del SCADA existente, con la corrección de deficiencias del sistema, corrección de deficiencias de automatismos y nuevas funcionalidades: - Gestión de ETAP y conducción como un mismo sistema. - SCADA redundante hot-standby. - Clientes web, con varias conexiones simultáneas. - Corrección de deficiencias de automatismos (requiere puesta en marcha local) e integración de nueva funcionalidad en SCADA. - Gestión de usuarios. - Gestión de alarmas con detección temprana. - Programación orientada a objetos. - Historiación. - Análisis de datos y cuadros de mando. - Informes. - Uso del video-wall. - Mantenimiento planificado básico. ## Gestión de usuarios Se definirán, consensuado con la propiedad, los diferentes roles de usuarios (operario, supervisor, análisis, mantenimiento, visualización, etc.) y que permisos tiene cada rol. Esto no será cerrado, sino modificable durante la implementación, pudiendo añadir o eliminar roles y cambiar los permisos de cada rol. Cada usuario del sistema pertenece a un rol. Será nominativo. Con nombre y contraseña. Lo más importante es diferenciar el acceso de los usuarios: local o remotos vía web. Son los mismos usuarios, pero hay que distinguir como acceden. - Acceso local: usuarios de la LAN, no acceden a los servidores por internet. Son los usuarios dados de alta en los servidores o en el video-wall.   - Acceso web: usuarios que acceden desde Internet. Todos menos los anteriores. En los servidores y video-wall los usuarios van a ir cambiando. Por tanto, el SCADA debe gestionar el alta y baja de los usuarios. Además, hay que gestionar la baja automática de usuarios para que tras cierto tiempo sin uso se quite el usuario y no llegue otro operario y haga alguna acción, incluso con permisos que no tenga. También puede ser necesario el alta de usuario si la configuración del sistema es tal que se requiera un usuario para la visualización de pantallas. En ese caso se hará un alta de usuario automática del usurario de visualización tras la baja automática de cualquier otro usuario. Para los usuarios por acceso web no se utilizará la funcionalidad de alta y baja de usuarios del SCADA, sino la del navegador web para aumentar la seguridad de la conexión. Al intentar conectar con el SCADA será el navegador del cliente el que muestre el diálogo de alta de usuario. Desde el SCADA no se podrá dar alta ni baja. Para dar de baja al usuario hay que salir del navegador. Esto es más seguro y como el dispositivo será de un usuario no habrá problemas de que un usuario acceda al sistema con otro usuario. En el caso de que la propiedad decida dotar de Tablet a los operarios, intercambiándola con cada turno, serán los operarios los que tengan que darse de baja antes de intercambiar la Tablet. Para poder analizar las acciones de los usuarios, habrá una pantalla de eventos de registro históricos de todas las acciones realizadas por los usuarios. Programación orientada a objetos Todo el SCADA se programará orientado a objetos. Es decir, todos los equipos electro mecánicos (bombas, válvulas, agitadores…) y toda la instrumentación serán objetos. Esto da coherencia a todo el sistema, haciendo que todos los equipos similares se traten de la misma forma. También facilita el despliegue de nuevos objetos futuros y reduce el tiempo de modificaciones o ampliaciones necesarias en un objeto. El objeto tendrá incrustado toda la funcionalidad necesaria, tanto visualización de estados, alarmas, mando y consignas en tiempo real como datos más avanzados como puedan ser mantenimiento, análisis de motivos de paradas o fallos. Todo objeto, visualmente constará de 2 partes: - Sinóptico para mostrar información gráfica más relevante, sin mando: Estados, con alarma, disponible o no, valores principales, estado que requieran actuación de operario (como mantenimiento pendiente) … - Pantalla con toda la información del objeto: Detalle de estados, alarmas y condiciones, lectura de valores, mando, parámetros y consignas de funcionamiento, mantenimiento, análisis de motivos de fallo o paradas… ## Distribución de pantallas Las pantallas de visualización irán de más genéricas a más detalladas, accediéndose desde la pantalla más genérica al siguiente nivel más detallado, según el siguiente esquema o equivalente: - Inicial de toda la instalación. - Genérica de conducción.   - o Genérica de ramal. - Punto de control: Cabecera o depósito - ❖ Objeto: Bomba, válvula… - Genérica de ETAP. - o Genérica de subsistema: Fango, obra de entrada… - Objeto: Agitador, decantador… En las pantallas genéricas se debe mostrar toda la información que un operario necesite para saber que todo está bien o tiene que acceder a un nivel más detallado para corregir anomalías. En las pantallas genéricas se pueden incrustar cuadros de mando para obtener esa información relevante. Además de estas pantallas de visualización habrá otras pantallas de gestión del conjunto como gestión de alarmas, cuadros de mando, gráficas de tendencia, planificadores y análisis de datos, etc. Todo se mostrará con escala de grises, excepto las alarmas (indicaciones de colores en siguiente punto), estados transitorios (celeste pálido), acciones que requieren acción del operario (azul) y colores de tuberías de reactivos (donde no se pueden usar los colores utilizados por las alarmas). Los únicos parpadeos permitidos serán las alarmas y las indicaciones que indiquen acción requerida por los operarios. Gestión de alarmas con notificación temprana de alarmas críticas Se definirán al menos 4 niveles de alarmas, de más a menos críticas, cada una de un color e icono distinta. La doble codificación ayuda a una más rápida identificación por parte del operario. De mayor a menor prioridad serán: Rojas, naranjas, amarillas y blancas. Salvo las alarmas, no habrá en todo el SCADA ninguna otra indicación que use los colores rojo, naranja o amarillo. Las alarmas se mostrarán en las pantallas de alarmas y en cada objeto. Habrá 2 tipos de pantallas de alarmas: Activas e histórico. Estas pantallas pueden ser para toda la instalación (opcional), para cada punto de control y para cada objeto (sólo activas). En ambas vendrá el texto de la alarma, el equipo, la prioridad y el estado, pudiéndose ordenar y filtrar por cada uno de ellos. En las páginas de alarmas activas se indicarán por colores para más rápida identificación. El rearme de alarmas del SCADA debe ser coherente con el del PLC. No puede haber una alarma que indique que un equipo no puede estar en marcha y que el equipo lo esté porque no se haya hecho el rearme de alarmas en el SCADA y sí en el PLC. Por tanto, el rearme de alarmas se hace en todos los elementos del sistema (PLC, HAMI, SCADA) se haga desde donde se haga. Se puede hacer el rearme desde el SCADA, desde el HMI local o desde los pulsadores locales de los cuadros eléctricos. Todos deben rearmar el PLC y si el PLC se rearma HMI y SCADA deben rearmarse. Para ello hay que programar en el SCADA el rearme de alarmas mediante botón tal que su pulsación rearme tanto la alarma del SCADA como la del PLC. También hay que configurar las alarmas de tal modo que el rearme del PLC rearme la del SCADA.    Las alarmas también se notificarán gráficamente en los sinópticos del objeto, indicando el color e icono de la alarma más crítica activa. SI alguna está sin reconocer el icono parpadeará para una más rápida identificación del operario. Se definirán las alarmas más críticas, pertenecientes a alarmas rojas, que requieran atención inmediata por parte del operario, y se enviarán por telegram y opcionalmente por email. ## Optimización de CCD de cada pantalla Teniendo en cuenta que la licencia es para 1500 CCD y puede haber hasta 30 clientes simultáneos, es muy importante la optimización del consumo de CCD de cada pantalla. ## Pantallas de sinópticos generales Habrá 3 sinópticos generales: Conducción, ETAP y uno con la información de todo el sistema (es decir conducción más ETAP). Para que tengan utilidad real, deben mostrar información relevante mínima: Alarma más crítica, lecturas más relevantes, estado de comunicaciones, lectura de parámetros críticos o cualquier otra visualización que requiera la propiedad. Dicha información se mostrará de la manera más gráfica posible, con mapa, vista general y/o cuadro de mando, incluso con geolocalización de la conducción. Los cuadros de mando generales pueden estar incrustados en los mapas o vista general o en pantallas sólo con los cuadros de mando. Ese nivel de detalle se decidirá durante la implementación. En los propios sinópticos estarán los botones de acceso a los puntos o zona de control del siguiente nivel de detalle. ## Pantallas de subsistemas generales En la conducción se separará por ramales, con la misma indicación que en el sinóptico general (mapa y cuadros de mando) más aumento de detalle con al menos indicación de tramos llenos de agua y depósitos en servicios con sus alarmas. En la ETAP será por subsistemas (obra de llegada, depósitos de agua tratada) con la misma indicación de la vista general más, al menos, información de equipos (objetos) de ese subsistema, indicación de estados de alimentación desde y hacia sistemas interrelacionados e indicación de que otros subsistemas tienen algún problema. Se indicarán con colores diferentes las tuberías de los distintos reactivos, pero sin usar rojo, naranja, amarillo ni ningún color tan parecido que haga que no destaquen las alarmas. En los propios sinópticos estarán los botones para ir a todas las pantallas que tengan conexión de flujo de agua o reactivos. Estas pantallas deben mostrar más información que los sinópticos generales, con el compromiso de mostrar toda la información relevante pero sin saturar de información. Se consensuará con la propiedad la información mostrada. ## Pantallas por puntos de control de la conducción Mostrarán los sinópticos de los objetos que lo componen.   Se mostrará información básica de si tiene alimentación de agua o no, de cómo están los puntos anterior y posterior y botones para ir a ellos. Se mostrará no sólo la información del punto, sino de los tramos de tubería anterior y posterior, indicando si está llena o no y hasta qué punto, según medida de presión y datos de perfil. ## Objetos Como ya se ha explicado el objeto constará de dos partes: sinóptico y pantalla de detalle que se accede desde el sinóptico. El sinóptico se mostrará en la pantalla del punto de control que lo contenga. Todos los sinópticos de los objetos tendrán las mismas normas de visualización para que el operario se acostumbre a ellas y rápidamente pueda ver el estado de los equipos. La visualización cumplirá con: - Colores del equipo: - o Blanco para marcha (o válvula abierta) - o Negro para parado (o válvula cerrada) - o Gris para válvulas paradas entre abierta e instrumentación que no tiene cambios de estados - o Azul celeste apagado para movimientos (en válvulas con flechas blanca y negra para abriendo y cerrando) - Iconos de estado - o Negro de local, remoto, manual, automático y no disponible - o Alarmas activas rojo, naranja, amarillo y blanco - o Requiere mantenimiento - o Instrumentación con medida simulada - Lecturas más relevantes en azul En el sinóptico no habrá mando del objeto para evitar acciones involuntarias. Siempre tendrá que accederse a la pantalla de detalle para realizar cualquier mando, ya sea marcha/paro o cambio de consigna La pantalla de detalle de cada objeto tendrá las siguientes pestañas, pudiendo algún objeto no tener alguna pestaña por no necesitarla: - Detalle de estados y todas las lecturas, como medidas de instrumentación, velocidad de variadores, horas de funcionamiento de equipos y número de arranques, etc. - Listado de todas las alarmas que puede tener, con indicación de alarmas activas y pulsador de rearme en aquellos objetos con rearme por objeto. - Listado de condiciones de enclavamiento, es decir listado de condiciones externas al objeto que impiden al accionamiento del mismo, para que el operario sepa porqué un objeto no puede ponerse en marcha - Mando, tanto marcha/paro como cualquier consigna (velocidad, alarmas alta o baja…)   - Mantenimiento, con 2 funcionalidades: Agenciar mantenimiento planificado y marcar como ejecutados los mantenimientos pendientes. - Análisis de fallos y paradas para dotar al operario de una herramienta que le permita avaluar los motivos y frecuencia de paro de un equipo. ## Alarmas de medida de agua y de reactivos Aparte de que las medidas de agua y reactivo puedan tener alarmas en el PLC de alto, bajo o desvío, en el SCADA se crearán alarmas de las más críticas para poder avisar al operario. Se debe avisar tanto de situaciones anómalas o erróneas como de situaciones previas que puedan llegar a anómalas para que el operario pueda actuar antes de que se dé dicha situación. Estas alarmas pueden ser alto, muy alto, bajo, muy bajo, absolutos y de desvío respecto a consigna de regulación. También de tendencia que indique en si no cambia en poco tiempo se tendrán una de las alarmas anteriores. Por ejemplo, en el cloro de salida de la ETAP, magnitud muy crítica, es indispensable tener las alarmas de desvío muy alto y muy bajo que indican que el operario debe hacer acción inmediata para corregir la situación. También las alarmas alto y bajo, porque el operario puede hacer algo que evite llegar a situación más crítica. Pero también es muy interesante estudiar la tendencia del cloro para saber si se va a llegar o no a situación crítica y poder avisar para tomar las medidas correspondientes ## Históricos y gráficos de tendencia Se van a historiar todas las medidas analógicas de la instalación (caudal, presión, nivel, concentración de reactivos…) para poder representar en gráficas de tendencia. Se crearán al menos todas las gráficas existentes actualmente y se formará a un operario a crear nuevas gráficas de tendencia y como se usan las mismas. Se estudiarán y definirán los tiempos de muestreo de cada una de esas variables, según su criticidad y velocidad de cambio. Se estudiará el tiempo total de historización, así como la partición de archivos históricos y su gestión. ## Análisis de datos Al menos se analizarán, a partir de datos históricos, caudal y volumen, energía, horas de funcionamiento de equipos críticos y parámetros críticos de calidad de agua. Para los contadores (volumen, energía, horas de funcionamiento) se crearán variables de conteo parcial para poder consultarse tanto valores puntuales como en tablas y en gráficas de barras. Al menos por semana, mes y año. ## Paneles de mando o dashboard Con un sistema tan complejo, las típicas pantallas HMI no son suficientes para tener una visión global de la instalación y saber que todo está bien. Por tanto, es necesario la creación de paneles de mando gráficos a definir en la puesta en marcha.  Al menos existirán: - General de la ETAP, con indicación de valores y rangos operativos de los principales reactivos, caudal de paso, sistemas en funcionamiento, etc. - Caudal y volumen - Energía - Parámetros críticos de calidad de agua Habrá cuadros de mando de tiempo real, para ayuda al proceso operativo, y de datos históricos, con rangos dinámicos, para análisis de datos. ## Informes con plantillas de Excel Se necesitan generar informes de los datos más importantes, tanto en tablas como en gráficos tipo cuadros de mando, generados en Excel y alimentados de datos de tiempo real e históricos. Al menos se harán los siguientes informes: - Volumen mensual o anual suministrado por cada depósito, tratado por la EATP, tomado del acueducto de trasvase y tomado desde embalse. - Parámetros de medidas de agua tratada por periodo de tiempo, tanto de ETAP como de cloro de la conducción. ## Video-wall El video-wall al convertirse en un cliente fijo del SCADA se usará como otro puesto de operación del centro de control, pero con 8 pantallas, pudiendo mostrar diferentes partes de la instalación, para que de un simple vistazo se tenga toda la información relevante. Por ejemplo, podría mostrarse mapa de la conducción, cuadro de mando general de la ETAP, gráfica de tendencias de variables más críticas, alarmas, etc… todo a la vez. ## Mantenimiento planificado básico Aprovechando que el SCADA es también historiador, con base de datos interna, y tiene gran capacidad de programación, se integrará un mantenimiento planificado básico. Se implementará una base de datos de los mantenimientos por objeto (equipos) y una planificación por equipo de mantenimientos a realizar. Será una planificación periódica preventiva. Se indicará mediante notificación gráfica y aviso por email o Telegram de que un equipo tiene mantenimiento pendiente. Cuando se ejecute el mantenimiento, se notificará en el mismo SCADA.   5. CONDICIONES GENERALES DEL SUMINISTRO Con carácter general, el suministro deberá adaptarse al horario de trabajo de TRAGSA, de lunes a jueves entre las 08:00 h y las 17:00 h y viernes de 8:00h a 14:00h. No obstante, y siempre que las necesidades de producción así lo requieran, se podrán realizar suministros fuera de esta jornada. Cada suministro deberá venir acompañado de una hoja de suministro que contenga la información necesaria para identificar inequívocamente dicho suministro, por lo que el ADJUDICATARIO deberá presentar al personal designado la hoja de suministro que contenga: - -Identificación del suministrador - -Número de serie de la hoja de suministro - -Identificación del peticionario - -Fecha y hora de entrega - -Definición de elementos suministrados (designación y cantidades) - -Identificación del lugar de suministro - -Identificación del vehículo que transporta los elementos El suministrador se obliga a que los materiales suministrados sean de las características técnicas, cantidad y calidad exigidas por TRAGSA y, en consecuencia: - El suministrador proporcionará a TRAGSA los Certificados de Calidad que deba tener el material suministrado, así como toda la documentación que acredite el cumplimiento de las medidas de aseguramiento de la calidad de los productos suministrados y de los controles a los que se han sometido. - En el caso de que los materiales suministrados no tuvieran Certificado de Calidad, se obliga a someterlos a los ensayos y pruebas que TRAGSA le exija en orden a asegurar su calidad. - En todo caso, el suministrador deberá someter los materiales suministrados a las pruebas de calidad y control que le sean ordenadas por TRAGSA, siendo el coste de dichas pruebas por cuenta del suministrador, si de las mismas se desprende que los materiales suministrados cumplen los requisitos de calidad exigidos. - Si del resultado de dichas pruebas resultasen deficiencias en los materiales deberá retirarlos y sustituirlos por otros de la calidad requerida, sin coste adicional para TRAGSA. Si los materiales suministrados van a ser utilizados o incorporados a una obra, y una vez entregados aparecieran deficiencias o vicios en los mismos el suministrador además de los gastos de sustitución, abonará aquellos otros que resultaran necesarios para realizarla, tales como derribos, transportes y nueva ejecución, todo ello sin perjuicio de la obligación de indemnizar los daños y perjuicios que, tanto a TRAGSA como a terceros, se le ocasionen.   ## 6. CONDICIONES MEDIOAMBIENTALES El adjudicatario declara conocer las obligaciones legislativas en materia medioambiental que pudieran resultar de aplicación de las actividades por él desarrolladas al amparo del presente contrato y se compromete a cumplir con todos los requisitos y exigencias legales que en materia de medio ambiente le sea de aplicación. El adjudicatario, de acuerdo a la normativa que le afecte en cuanto a la actividad a realizar, declara su intención de reducir a lo estrictamente necesario el consumo de materias primas que comprometan la sostenibilidad de los ecosistemas naturales de los cuales se obtienen. ## 7. OBLIGACIONES EN SEGURIDAD DE MATERIA LABORAL Los colaboradores estarán obligados a: - -Aplicar los principios de la acción preventiva que se recogen en el artículo 15 de la Ley de Prevención de Riesgos Laborales, en particular al desarrollar las tareas o actividades indicadas en el artículo 10 del REAL DECRETO 1627/1997, de 24 de octubre, por el que se establecen disposiciones mínimas de seguridad y de salud en las obras de construcción. - -Cumplir y hacer cumplir a su personal lo establecido en el Plan de Seguridad y Salud al que se refiere el artículo 7 del REAL DECRETO 1627/1997, de 24 de octubre. - -Cumplir la normativa en materia de prevención de riesgos laborales, teniendo en cuenta, en su caso, las obligaciones sobre coordinación de actividades empresariales previstas en el artículo 24 de la Ley de Prevención de Riesgos Laborales, así como cumplir las disposiciones mínimas establecidas en el anexo IV del REAL DECRETO 1627/1997, de 24 de octubre, durante la ejecución de la obra. - -Informar y proporcionar las instrucciones adecuadas a los trabajadores sobre todas las medidas que hayan de adoptarse en lo que se refiere a su seguridad y salud en la obra. - -Atender las indicaciones y cumplir las instrucciones del coordinador en materia de seguridad y de salud durante la ejecución de la obra o, en su caso, de la dirección facultativa. Los colaboradores serán responsables de la ejecución correcta de las medidas preventivas fijadas en el Plan de Seguridad y Salud en lo relativo a las obligaciones que les correspondan a ellos directamente o, en su caso, a los trabajadores autónomos por ellos contratados, incluso será por cuenta del colaborador el coste de las protecciones individuales y colectivas necesarias para la correcta ejecución de la obra. Además, responderán solidariamente de las consecuencias que se deriven del incumplimiento de las medidas previstas en el Plan, en los términos del apartado 2 del artículo 42 de la Ley de Prevención de Riesgos Laborales. Así como la obligatoriedad de la presencia en el centro de trabajo de los recursos preventivos, cualquiera que sea la modalidad de organización de dichos recursos. Se consideran recursos preventivos: - a) Uno o varios trabajadores designados de la empresa. - b) Uno o varios miembros del servicio de prevención propio de la empresa.    - c) Uno o varios miembros del o los servicios de prevención ajenos concertados por la empresa. Dichos recursos preventivos deberán tener como mínimo la formación correspondiente a las funciones del nivel básico (50 horas), así como la capacidad, los medios necesarios y ser suficientes en número para vigilar el cumplimiento de las actividades preventivas, debiendo permanecer en el centro de trabajo. En lo que respecta a los requisitos específicos en materia de Seguridad y Salud, el colaborador deberá observar una serie de requerimientos que, de forma documental, quedarán incorporados al contrato y formarán parte inseparable del mismo: - a) Certificado de modelo de gestión de la prevención asumido por el empresario (servicio de prevención propio o externo). - b) Designación de un responsable en temas de prevención de riesgos laborales ante TRAGSA. - c) Relación nominal del personal de la empresa colaboradora en obra, adjuntando a mes vencido una copia de los TCs. - d) Certificado de Aptitud Médica de los trabajadores. - e) Justificante de la entrega de la información a los trabajadores: se trata de un documento individualizado para cada uno de los trabajadores y deberá estar firmado por el propio trabajador. - f) Justificante de haber impartido formación a trabajadores en materia de prevención de riesgos laborales. Esta formación debe ser específica para el puesto de trabajo. El justificante es un documento que debe contener el temario recibido y estará firmado por los trabajadores y por la persona encargada de impartir dicha formación. - g) Justificante de entregas de equipos de protección individual, haciendo referencia de los mismos. - h) Justificante de aceptación y compromiso de cumplimiento del PSS (plan de seguridad y salud). - i) Relación de maquinaria que se emplea en la obra, junto con su estado de mantenimiento y declaración de adecuación al R.D. 1215/97(esto último en caso de maquinaria que esté fabricada con anterioridad al año 1995). - j) Seguro de vida y de invalidez permanente establecidos en convenio. Esta documentación puede quedar ampliada según las cláusulas a añadir en el contrato marco y deberá ser actualizada cuando se presenten cambios con relación a la situación inicial. Será causa inmediata de resolución del contrato el incumplimiento por parte del Colaborador de sus obligaciones en materia de seguridad y salud laboral para con el personal de él dependiente, así como la falta de adecuación a la normativa vigente de seguridad, de la maquinaria y equipos que intervengan en la actuación objeto del contrato. Toledo, marzo de 2026