Vestas développe un software de contrôle pour les parcs éoliens avec l'approche Model-Based Design et l'intégration continue

Avant d'adopter l'approche Model-Based Design pour le design des contrôles des systèmes physiques, les ingénieurs de Vestas utilisaient une approche conventionnelle dans laquelle les spécifications papier et les documents de design développés par les ingénieurs en énergie étaient confiés à des ingénieurs logiciels, qui écrivaient à la main le code pour les composants ou les fonctionnalités individuels. Les ingénieurs en énergie effectuaient des simulations avec le software PSCAD, mais ces simulations étaient axées sur la puissance électrique plutôt que sur le contrôle logiciel. Les simulations n'incorporaient pas le code de contrôle, ce qui signifie qu'il y avait peu de garanties que les simulations PSCAD reflètent correctement les performances du système une fois le software incorporé et déployé. Vestas souhaitait éliminer les risques d'erreur humaine liés au codage manuel, tout en s'assurant que ses simulations de systèmes électriques correspondent au software de contrôle.

De plus, Vestas souhaitait que ses équipes d'ingénieurs, réparties dans cinq pays d'Europe et d'Asie, puissent travailler ensemble sur les mêmes projets et, dans certains cas, sur les mêmes modèles. Cette équipe dispersée géographiquement devait appliquer un contrôle de version aux modèles, gérer des fusions fréquentes et automatiser des tests basés sur des simulations. Pour répondre à ces exigences, Vestas a décidé d'utiliser l'intégration continue avec Jenkins™ et d'intégrer les principes de l'intégration continue dans un workflow d'ingénierie basé sur la modélisation, les simulations et la génération de code.

Après avoir obtenu le soutien de la direction générale, les ingénieurs en systèmes électriques de Vestas ont mis en place un nouveau workflow pour le design des commandes des centrales électriques, qui combine l'intégration continue et l'approche Model-Based Design avec MATLAB^® et Simulink^®.

Lorsqu'une modification du code du réseau électrique est proposée ou qu'un client demande une nouvelle fonctionnalité ou un nouveau composant, les ingénieurs de Vestas créent un ensemble de spécifications formelles. Sur la base des spécifications, un groupe développe des cas de test avec Simulink et Simulink Test™ qui seront utilisés pour vérifier la nouvelle fonctionnalité, tandis qu'un second groupe conçoit la nouvelle fonctionnalité dans Simulink et Stateflow^®.

Afin de créer un modèle de système pour les simulations en boucle fermée, les ingénieurs de ce deuxième groupe combinent le modèle de contrôle avec un modèle Simulink qui capture l'impédance et les caractéristiques dynamiques du réseau électrique au point de connexion avec le système physique. En utilisant la fonction S de Simulink, ils intègrent un modèle d'éolienne développé dans un outil propriétaire et packagé sous forme de DLL par un autre groupe de Vestas.

Après avoir réalisé des simulations en boucle fermée avec ce modèle de système et procédé à des vérifications de conformité avec les normes de modélisation basées sur les directives du MathWorks Automotive Advisory Board (MAAB), les ingénieurs vérifient le modèle de contrôle dans un référentiel Git. L'enregistrement du modèle déclenche un job Jenkins qui exécute les cas de test développés précédemment avec Simulink Test. Cet enregistrement déclenche aussi des tests supplémentaires basés sur les simulations et créés par les ingénieurs en énergie, ainsi qu'une autre série de vérifications de conformité aux directives de modélisation.

Si le modèle de contrôle passe tous les tests et vérifications, Jenkins appelle Embedded Coder^{® 1} pour générer le code C++ à partir du modèle. Le code C++ généré est compilé dans un DLL, qui est ensuite utilisé dans PSCAD pour exécuter des simulations du système physique complet et de son software de contrôle.

Vestas utilise ces simulations pour démontrer aux opérateurs de systèmes de transport comment le système physique se comportera s'il est connecté au réseau dans des conditions normales et en présence de chutes de tension, d'oscillations ou autres perturbations. Enfin, le code généré est testé sur le système de contrôle industriel cible avant d'être déployé en production.

• Génération d'un code fiable et sans problème. « Si nos systèmes de contrôle ne fonctionnent pas comme ils le devraient, nous nous exposons à des sanctions », déclare M. Nielsen. « Avec Simulink et Embedded Coder, nous avons rapidement compris que nous pouvions faire confiance au code que nous générions. À vrai dire, nous n'avons jamais trouvé le moindre problème avec le code généré. »
• Automatisation du workflow d'intégration continue multisite. « Nous avons des dizaines d'ingénieurs dans le monde entier qui travaillent en parallèle sur le même modèle, avec de nombreuses fusions », explique M. Nielsen. « L'utilisation conjointe de l'approche Model-Based Design et de l'intégration continue nous a permis de raccourcir les itérations et d'automatiser les processus de test. »
• Verrouillage hardware évité. « Auparavant, nous développions des contrôleurs en écrivant un texte structuré personnalisé pour une plateforme PLC, ce qui nous liait étroitement à cette plateforme », explique M. Nielsen. « Désormais, nous générons un code C++ portable à partir de nos modèles Simulink, ce qui nous donne la flexibilité nécessaire pour utiliser d'autres plateformes de contrôle industriel. »

¹ Une licence d'accès client peut être nécessaire pour utiliser Embedded Coder sur Jenkins ou d'autres machines d'intégration continue.