Simuladores de aerogeneradores

Nuevo paradigma para el diseño de simuladores. Aplicación al diseño de un Simulador/Entrenador para un aerogenerador
TECHWINDGRID09 Madrid, 20-21 Abril 2009 José San Leandro Ros
Director, Automated Computing Machinery SL, +34605876615 E-mail: Jose.sanleandro@acm-sl.com, www.acm-sl.com
Resumen – El desarrollo de un simulador incluye cuatro tipos de tareas: a) el diseño de alto nivel (divisióndel sistema a simular en subsistemas y escritura de sus especificaciones); b) el diseño de la interfaz de usuario (HMI); c) la programación propiamente dicha; d) las pruebas. Hemos desarrollado un Simulador para un aerogenerador, cuyo objetivo era poder generar cualquier posible condición (de ambiente, de posibles fallos, etc) que el Controlador del aerogenerador puede encontrarse. Nos enfrentamosa la decisión de elegir la plataforma de desarrollo de software, ya que sabíamos que las plataformas visuales basadas en flujos de datos, aunque muy completas y probadas, nos forzaría a depender fuertemente de la disponibilidad de expertos en cada uno de los campos involucrados (varias personas), situación que sabíamos era difícil que se diera. Esta comunicación muestra como solventamos elproblema, usando una aproximación diferente, que resulto tener un número de beneficios, básicamente: a) uso de programadores con conocimientos más comunes (Visual C, Visual Basic), y por tanto de menor coste; b) un método más económico de escribir las especificaciones; c) independencia de las pruebas de cada módulo; d) diferir la construcción programa final a la “conexión de los módulos”, hecho por losexpertos, sin compilación. Índice de términos – simulador, aerogenerador, control de proceso.

I.

INTRODUCCIÓN

Nos encontramos con el problema de construir un simulador para el aerogenerador BONUS (ahora SIEMENS WIND POWER) 1300, de paso de pala variable, y velocidad fija (dual). Teníamos experiencia en la construcción de otro similar para el BONUS 600, de pala fija. El primer reto fueencontrar/diseñar toda la instrumentación requerida para todas y cada uno de las señales que había que monitorizar o controlar. Acabamos diseñando un número de instrumentos, tales como un generador programable de red trifásica y emulador de carga eléctrica y un emulador de resistencia Pt100 de medida de temperatura. La segunda decisión importante fue seleccionar la plataforma de desarrollo de losprogramas. Una solución era usar una de las que son estandard de-facto del mercado. Pero sabíamos que esta aproximación nos obligaría a un ciclo muy largo de desarrollo, ya que cada decisión de cambio de las especificaciones tendría que implicar un proceso de compilación y, por tanto impli-

caría que los programadores tendrían que estar en estrecha colaboración con los expertos que especificabanlas funcionalidades del sistema. En esta aproximación los programadores deberían estar presentes para la creación de cualquier nueva versión del programa ejecutable final, para cualquier cambio que hubiera que hace, tanto si era importante (cambios en los subsistemas o en los algoritmos) o menor (pe, cambios de detalles en la interfaz de usuario). También sabíamos que el simulador, en su conjunto,era complejo de poner a punto, debido a que, en esa aproximación de desarrollo, era difícil reproducir las condiciones de prueba de cada subsistema, que solo se podrían controlar cuando todas las piezas estuvieran juntas. Comprobamos que cada subsistema del simulador podía ser descrito con un número de algoritmos (algunos complejos, como el cálculo de la energía del viento), y un número deparámetros. Con una plataforma de desarrollo visual de flujos de datos, los programadores crean módulos de software para los subsistemas. Estos módulos pueden ser comprobados de forma independiente y se usan en el programa final (ejecutable) via lincado. Este es un punto no deseable en el proceso de desarrollo, ya que es necesario que los programadores estén presentes continuamente, para pulir todos los...