Posicionamos su web SEO / SEM
Cartif ha apostado por LabVIEW como entorno de desarrollo para el conjunto de la siguiente aplicación de diagnóstico

Diagnóstico en línea de múltiples aerogeneradores con acceso centralizado a señales y resultados

Roberto Arnanz y Aníbal Reñones. Fundación Cartif. Ingenieros I+D08/04/2013
Ante el reto de desarrollar una red de diagnóstico de aerogeneradores que permita el seguimiento de su estado de forma automática y centralizada, la Fundación Cartif propone como solución utilizar LabVIEW, por la facilidad de integrar las diferentes necesidades del sistema: captura de datos, gestión de base de datos, acceso web a aplicaciones, interfaces de usuario...

Introducción

El área de Diagnóstico Industrial y Mantenimiento Predictivo de Cartif tiene una amplia experiencia en el desarrollo de sistemas de diagnóstico en entorno industrial. Estos sistemas requieren la captura de señales de diversa naturaleza (vibración, eléctricas, digitales de alta y baja frecuencia...) y alta capacidad de almacenamiento debido a que en muchos casos se ejecutan en continuo para el 100% de la producción.

foto

En el caso de los aerogeneradores los requisitos de captura, diagnóstico y almacenamiento de datos a nivel de prestaciones y diseño del sistema son similares a los de cualquier aplicación de máquina rotativa. La peculiaridad radica en que el parque eólico dispone de múltiples máquinas a diagnosticar por lo que la cantidad de datos y diagnósticos se incrementa de manera notable dificultando su tratamiento centralizado.

La solución desarrollada por Cartif en colaboración con Iberdrola Renovables utiliza equipos autónomos de diagnóstico ubicados en cada máquina, una base de datos PostgreSQL distribuida, un servidor por parque y un servidor central. El acceso a los datos podrá ser descentralizado al estar adaptado el interfaz de usuario para su uso a través de un explorador web. El Web Server de LabVIEW permite desarrollar aplicaciones de usuario como si fueran a ser usadas de forma local y posteriormente publicarlas via web. Por tanto LabVIEW puede ser utilizado como herramienta única de desarrollo integrando la captura de datos, el procesamiento de señales y el diseño de interfaces independientemente de dónde se instalen cada una de estas funciones, el tipo de comunicación entre ellas y cómo vayan a ser utilizadas por el usuario final.

La captura de datos

Las necesidades de diagnóstico requieren la captura de múltiples señales del aerogenerador. En el primero prototipo se han instalado 8 acelerómetros ICP, 5 acelerómetros capacitivos, 3 pinzas de corriente, 3 sensores de tensión y 2 sensores inductivos para la medición de la velocidad. La diversidad en el tipo de señales ha orientado la elección del sistema de captura hacia los equipos modulares de National Instruments. En concreto hacia el sistema CompactDAQ, en el que se han instalado módulos de adquisición de acelerómetros (NI 9233), de señales analógicas (NI 9205) y digitales (NI 9423 y NI 9474).

Entre los principales requisitos que cumple la captura de datos cabe destacar los siguientes:

• Captura de la señal de velocidad de forma sincronizada junto al resto de señales utilizadas para los análisis, ya que el sistema objeto de estudio funciona a velocidad variable.

• Captura de datos en continuo durante periodos largos de tiempo, ya que las frecuencias que caracterizan los elementos asociados al eje lento son muy bajas.

• En el periodo de captura de datos la velocidad de giro no debe tener grandes variaciones para facilitar el análisis

Para cumplir con el tercer requisito, los datos sólo son almacenados de forma definitiva cuando el porcentaje de variación de la velocidad durante el tiempo requerido de captura no supera un determinado umbral. El método es equivalente a la utilización de un trigger software donde los datos almacenados corresponden al tiempo de pretrigger y la condición del trigger viene dada por un cálculo que determina la máxima variación de velocidad en los datos pasados.

La tasa de transferencia en continuo alcanzada con el sistema es de 25 kHz para 8 canales analógicos además de las señales de los encoder. Esto permite un almacenamiento continuo en disco y por tanto capturar señales con esta frecuencia tiempos tan largos como se desee.

La aplicación de diagnóstico

Dado que la dinámica de los fallos que a estudiar es relativamente lenta, el sistema realiza una captura de datos por rondas y posteriormente un procesado de los datos obtenidos. En cada una de las rondas se realizan distintas capturas (canales y frecuencias) en función de los diagnósticos programados. Todos los resultados son almacenados en la base de datos local y sólo los más significativos o las alarmas son enviados a una base de datos central.

foto
Figura 1: Estructura de la aplicación de diagnóstico.

La figura 1, muestra los módulos que componen la aplicación. El módulo Supervisor es el encargado de leer las configuraciones de la base de datos y en función de ellas ordena la ejecución de las capturas en los instantes programados y posteriormente los procesamientos y diagnósticos cuando existen datos disponibles. El módulo de Interfaz de usuario permite acceder a las señales capturadas, a los resultados de los diagnósticos y realizar sencillas funciones de análisis como la visualización FFT de alguna o varias de las capturas, pudiendo compararlas entre ellas. Cualquier usuario podrá conectarse a este interfaz vía web, sin necesidad de descargar los datos capturados.

El diseño modular permite fácilmente la modificación de los algoritmos de procesamiento en tiempo de ejecución e incluso añadir nuevos sin necesidad de recompilar la aplicación entera. En este caso los algoritmos se encuentran en una librería dll que se puede modificar en cualquier momento en que no se esté ejecutando un procesamiento en el sistema.

La red de diagnóstico

La figura 2 muestra un ejemplo de aplicación del sistema desarrollado permitiendo la supervisión centralizada de múltiples parques y máquinas geográficamente dispersos. El sistema incorpora los mecanismos de gestión para mantener actualizadas cada una de las bases de datos, de forma que aunque se pierda la comunicación en alguno de los puntos, todas las máquinas siguen realizando de forma autónoma los diagnósticos programados.

foto
Figura 2: Estructura global de la red de diagnóstico.

El usuario final de la aplicación puede disponer de toda la información de diagnóstico generada en las distintas máquinas de manera rápida y flexible. Para ello se ha diseñado una interfaz de usuario tipo SCADA ubicado en el servidor central y accesible mediante cualquier explorador web. En el momento en que el usuario quiera acceder a las señales capturadas o analizar alguna de ellas, lo hará de manera transparente conectándose al interfaz situado en la máquina en lugar de al situado en el servidor central. Este método se basa en el uso de aplicaciones LabVIEW a través de un servidor Apache.

La comunicación entre los diferentes elementos de la red en las pruebas realizadas se realiza creando una red inalámbrica de diagnóstico independiente del resto de las comunicaciones del parque.

Conclusión

Cartif ha apostado por LabVIEW como entorno de desarrollo para el conjunto de la presente aplicación de diagnóstico. Esto ha permitido la integración de módulos desde la etapa de investigación/desarrollo a la de aplicación final fácilmente y sin coste adicional. Esta concepción modular facilita el proceso de desarrollo software al diseñarse los módulos (captura, procesamiento y diagnóstico) de manera independiente y posteriormente poder llegar a ejecutarlos en equipos distintos (o en los sistemas multinúcleo en distinto microprocesador) en función de los requisitos de los cálculos y las prestaciones de los equipos utilizados. El sistema ha sido implantado en parques eólicos gestionados por Iberdrola Renovables, cuya colaboración ha sido esencial para el desarrollo del proyecto.