Pourquoi la génération automatique de code est plus efficace que le développement manuel d'un micrologiciel de conversion

Principaux enseignements

• La génération automatique de code élimine les allers-retours entre la conception des commandes et le micrologiciel, ce qui réduit le retard accumulé en matière de révision et garantit la cohérence entre la mise en œuvre et le modèle.
• Le code de contrôleur généré fonctionne de manière optimale lorsque le modèle tient déjà compte des temporisations fixes, des limites numériques, de l'ordre de protection et des contraintes du processeur.
• Le firmware manuel reste indispensable pour la configuration des périphériques et les services système, tandis que la boucle de contrôle elle-même tire le meilleur parti de la génération et du prototypage basés sur des modèles.

La génération automatique de code s'avère plus efficace que le micrologiciel de conversion écrit à la main lorsque les lois de commande évoluent constamment et que la synchronisation doit rester précise.

Les équipes chargées des convertisseurs de puissance ont rarement des difficultés à écrire du code en C. Elles ont plutôt du mal à réajuster les boucles de courant, à mettre à jour la logique de protection et à maintenir l’alignement des temps d’échantillonnage après chaque modification de conception. Les ventes de voitures électriques ont atteint près de 14 millions d’unités en 2023, et environ 18 % de toutes les voitures vendues étaient électriques. Une telle ampleur met davantage de pression sur le code des convertisseurs et de la commande des moteurs, et le travail manuel sur le micrologiciel devient l’étape la plus lente. Il est préférable que le modèle de contrôle devienne la source de référence et que le code du contrôleur soit généré à partir de ce modèle. Cette approche convient particulièrement aux laboratoires de développement de convertisseurs et aux laboratoires d’enseignement, où les algorithmes évoluent constamment et où le travail de développement de micrologiciels de bas niveau constitue un frein.

La génération automatique de code permet de convertir des modèles de contrôle en logiciel embarqué

La génération automatique de code transforme un modèle de contrôle en code C qui préserve la structure du modèle, la synchronisation et le flux de données. Vous élaborez la loi de contrôle à l'aide de blocs ou d'équations, vous définissez les temps d'échantillonnage, puis vous générez les fichiers source pour la cible. Cela permet de garantir que l'implémentation reste fidèle à la conception validée. Cela réduit également le délai entre la simulation et l'exécution.

Un contrôleur de courant pour un onduleur triphasé en est un exemple typique. Vous pouvez modéliser les conversions de coordonnées de Clarke et de Park, les boucles proportionnelles-intégrales, la saturation et le calcul du rapport de modulation par largeur d'impulsion, puis générer du code pour la phase d'interruption. Chaque chemin de signal reste visible avant le déploiement. Dans le cas d'un micrologiciel développé manuellement, cette même logique est souvent répartie entre différents fichiers, macros et branches d'interruption.

Le gain ne réside pas dans une qualité de code « magique » obtenue d'une simple pression sur un bouton.

« Le gain provient de la suppression du travail de conversion entre la conception des commandes et la mise en œuvre du micrologiciel. »

Chaque fois que vous réajustez les gains, que vous ajoutez un circuit de pré-commande ou que vous insérez un circuit anti-windup, le modèle et le code restent synchronisés. Cette synchronisation est plus importante que la simple vitesse de frappe, car dans les projets de conversion, la majeure partie du temps est consacrée aux révisions, et non à la mise en œuvre initiale.

Le développement du firmware évolue : on passe de la saisie de code à la définition des comportements

La charge de travail principale passe de la programmation manuelle à la définition d'un comportement de contrôle précis dans le modèle. Vous continuez à choisir les vitesses, les types numériques, les mises à l'échelle et les interfaces. Vous ne passez plus des heures à écrire du code de planificateur standard et à mettre en place des connexions de signaux répétitives. Vos efforts se concentrent désormais sur l'intention de contrôle, où les erreurs ont un coût plus élevé.

Un contrôleur en pont complet à déphasage illustre bien ce décalage. Le code écrit manuellement vous oblige à connecter les lectures du convertisseur analogique-numérique, à normaliser les mesures, à planifier le bloc de compensation, à limiter les sorties et à veiller à la cohérence de la logique de phase après chaque modification effectuée lors d'une interruption. Le code généré nécessite toujours une configuration, mais la loi de compensation reste regroupée dans un seul modèle. Cela vous permet de disposer d'un point unique pour examiner le comportement lors d'une revue de conception.

Les équipes de contrôle sous-estiment souvent la part de travail administratif que représente la gestion manuelle du firmware. Copier des valeurs de gain, renommer des variables et reformuler des équations en arithmétique entière n’apportent aucune information utile pour le contrôle. Ces étapes créent également des divergences invisibles entre la simulation et l’exécution embarquée. La génération automatique de code élimine une grande partie de ce travail administratif, ce qui évite de perdre du temps lors de la validation à cause d’erreurs dues à des fautes de transcription.

Embedded Coder est adapté aux cibles de commande de moteurs telles que le C2000

Les petits processeurs de commande, tels que le C2000, se prêtent bien à la génération de code, car ils nécessitent des tâches à pas fixe, des interruptions prévisibles et des temporisations d'entrée/sortie explicites. Un générateur adapté adapte les fréquences du modèle à ce schéma d'exécution. Il vous reste toutefois à vérifier l'utilisation de la mémoire et la synchronisation des périphériques. La logique du contrôleur est transmise au processeur sous une forme que la cible peut exécuter.

Un contrôleur de moteur à champ orienté en est une bonne illustration. Le modèle peut intégrer la reconstruction du courant, l'estimation de la vitesse, les régulateurs proportionnels-intégraux, les termes de découplage et la modulation vectorielle dans l'espace, tandis que la configuration des périphériques reste en dehors de la loi de commande. Le code généré couvre la tâche de commande récurrente. Le code écrit manuellement peut ensuite intégrer autour de celle-ci l'échantillonnage analogique, la synchronisation de la modulation de largeur d'impulsion, les déclenchements en cas de défaut et les interfaces de communication.

C'est précisément cette distinction qui explique pourquoi le contrôle basé sur un modèle fonctionne bien sur ces appareils. Le processeur excelle dans l'exécution déterministe des boucles, mais il pénalise les réécritures constantes lorsque l'algorithme est encore en cours d'évolution. Le code de contrôleur généré fournit des fonctions lisibles associées à des blocs de modèle, ce qui facilite la révision du code, l'étalonnage et le débogage en laboratoire. Cela correspond bien davantage à l'esprit de la génération de code Simulink qu'une réécriture complète du micrologiciel après chaque réajustement.

Le micrologiciel du convertisseur manuel ralentit lorsque les boucles de régulation sont en mouvement constant

Les firmwares de convertisseur écrits à la main ralentissent le développement, car chaque modification des commandes nécessite une deuxième étape de conversion, des équations vers le code. Cette étape supplémentaire engendre une dette de révision, des travaux de retest et un risque lié aux délais. Les problèmes de qualité logicielle ont coûté au moins 2 410 milliards de dollars aux États-Unis en 2022. Les équipes chargées des convertisseurs subissent chaque semaine une version à plus petite échelle de ce gaspillage.

Un programme de pont double actif commence souvent par une méthode de modulation, puis intègre une logique de démarrage progressif, une compensation du temps mort et une limitation de courant une fois les résultats des essais au banc obtenus. Chaque modification du micrologiciel a une incidence sur la mise à l'échelle, la synchronisation des interruptions et les interactions en cas de défaut. L'ingénieur en contrôle et l'ingénieur en micrologiciel peuvent s'accorder sur les calculs mathématiques tout en divergeant sur les détails de mise en œuvre. Cet écart s'accentue à chaque modification de la structure de la boucle.

Le code manuel reste une bonne solution lorsque l'algorithme est stable et que l'équipe connaît parfaitement le dispositif. Les problèmes apparaissent plus tôt que ne le prévoient la plupart des équipes, car les projets de conversion restent rarement stables tout au long du premier cycle de test. Le tableau ci-dessous présente les domaines vers lesquels les efforts se concentrent généralement une fois que les révisions commencent. Il montre pourquoi le goulot d'étranglement réside dans la conversion et les nouveaux tests plutôt que dans le calcul lui-même.

Le code de contrôleur généré dépend d'une conception de modèle déterministe et épurée

La qualité du code généré dépend entièrement de la structure du modèle, du respect des contraintes temporelles et des choix numériques qui le sous-tendent. Un modèle clair, à pas fixe, produira un logiciel de contrôle lisible. Un modèle bâclé produira plus rapidement un logiciel confus. Le modèle doit refléter la réalité du système embarqué avant que la génération de code ne commence.

Un modèle de convertisseur prêt pour la génération de code présente quelques caractéristiques visibles. Les débits sont explicites. Les états sont réinitialisés de manière contrôlée. Les limites des signaux sont fixées au niveau où la saturation matérielle se produira. Les choix numériques correspondent à la cible.

• Chaque tâche de contrôle utilise un temps d'échantillonnage fixe qui correspond à une interruption réelle.
• Chaque réinitialisation d'état est visible et associée à une condition de fonctionnement définie.
• La mise à l'échelle des capteurs et les limites des actionneurs apparaissent dans le modèle, et pas seulement dans le code d'encapsulation.
• Les types de données tiennent compte des limites du processeur avant le début du traitement temporel.
• Les séquences de protection s'exécutent dans un ordre connu qui correspond au cycle de commande.

Ces règles peuvent sembler banales, mais elles permettent d'éviter les pires mauvaises surprises. Un modèle comportant des transitions de fréquence cachées ou reposant sur des hypothèses de virgule flottante se compilera, mais échouera en cas de pression due aux interruptions sur un petit processeur. Une structure claire facilite également la révision des fichiers générés avec des collègues spécialisés dans le micrologiciel. Vous ne demandez pas au générateur de résoudre un problème de modélisation qui relève toujours de la responsabilité de l'ingénieur.

Le prototypage des commandes permet de vérifier la synchronisation avant de passer au développement du micrologiciel de bas niveau

Le prototypage de contrôle vous permet de tester la synchronisation d'exécution, le comportement des entrées/sorties et la réponse en boucle fermée avant de vous engager dans les détails de bas niveau du micrologiciel. Cette étape permet de mettre en évidence les délais non respectés, les problèmes d'évolutivité et les faiblesses de la logique de protection alors que l'algorithme est encore facile à modifier. Elle fait de la synchronisation une variable de conception plutôt qu'une surprise de dernière minute.

Une configuration de laboratoire associant un contrôleur basé sur un modèle à un prototype de contrôle C2000 permet d’en démontrer rapidement l’intérêt. OPAL-RT s’appuie sur ce principe pour permettre aux ingénieurs et aux étudiants d’itérer les algorithmes des convertisseurs et des moteurs sur un modèle d’installation en fonctionnement, plutôt que de coder manuellement chaque révision dans le micrologiciel. Les limites de courant, les gains des observateurs et les mises à jour de la modulation de largeur d’impulsion peuvent être vérifiés en cas de défauts et de variations brusques. Le travail reste ainsi axé sur la qualité du contrôle et la synchronisation de l’exécution.

Cette étape est importante car la simulation à elle seule ne permet pas de mettre en évidence tous les problèmes. La gigue d'interruption, la quantification, l'alignement de l'échantillonnage analogique et l'ordre de saturation semblent souvent inoffensifs sur un modèle de bureau.

« Le prototypage permet de mettre en évidence ces aspects avant que l'équipe ne les enfouisse dans du code périphérique. »

Vous arrivez à la phase finale du développement du micrologiciel avec moins d'inconnues et une loi de commande qui a déjà prouvé qu'elle pouvait s'exécuter dans les délais.

La génération de code échoue lorsque les modèles ne tiennent pas compte des contraintes matérielles

Dans la pratique, la génération de code échoue lorsque le modèle repose sur des hypothèses mathématiques idéales et des ressources matérielles illimitées. Les petits processeurs de contrôle sont soumis à des contraintes de temps strictes, à une résolution finie et à des règles relatives aux périphériques que le modèle doit respecter. Le code généré ne peut pas sauver une conception de contrôle qui dépasse la fenêtre d'interruption. Il ne fera que rendre cette incompatibilité visible plus tôt.

Une boucle numérique de correction du facteur de puissance peut sembler stable avec une double précision et un temps de retard nul au niveau des capteurs, puis présenter un comportement anormal dès lors qu’elle fonctionne avec des valeurs analogiques quantifiées et un échantillon de courant retardé. Le code généré n’est pas en cause ici. Le modèle n’a pas pris en compte l’interface avec l’installation ni les limites du processeur. Des problèmes similaires apparaissent lorsqu’un modèle utilise une logique à pas variable qui n’a pas sa place dans un calendrier d’interruptions fixe.

C'est en faisant preuve de rigueur que vous éviterez ce piège. Intégrez dans le modèle le filtrage des capteurs, le délai de conversion et la saturation des actionneurs. Choisissez dès le début des types de données adaptés au processeur, puis surveillez le temps d'exécution après chaque modification des fonctionnalités. Les équipes qui y parviennent considèrent la génération de code comme une méthode de mise en œuvre, et non comme un substitut au jugement technique en matière de conception embarquée.

Le code manuel permet toujours de gérer les périphériques dans le cadre des boucles de régulation

Le code manuel a toujours sa place dans les parties périphériques d'un contrôleur de convertisseur, notamment pour la mise en service de la carte, les piles de communication, les protections personnalisées et la configuration des périphériques spécifiques à l'appareil. C'est la boucle de contrôle elle-même qui tire le plus grand bénéfice de la génération automatique. Cette distinction permet d'apporter de la clarté là où le comportement change fréquemment et de recourir au réglage manuel lorsque les détails matériels sont fixes.

Une pile de micrologiciels pratique se présente souvent ainsi. Le code généré gère la boucle de courant ou de tension, tandis que le code écrit manuellement prend en charge la séquence de démarrage, la journalisation des défauts, les messages de bus et le stockage non volatile des paramètres. Cette répartition reflète la manière dont les projets de convertisseurs évoluent concrètement en laboratoire. Les équations de commande changent chaque semaine pendant la mise au point, tandis que les services périphériques se stabilisent plus tôt et récompensent un travail manuel minutieux.

C’est pourquoi la génération automatique de code est préférable à un micrologiciel de conversion écrit à la main pour la plupart des tâches de contrôle. L’avantage ne réside pas dans la réduction de la taille des fichiers source, mais dans une meilleure cohérence entre le modèle auquel vous faites confiance, la synchronisation que vous vérifiez et le code que vous déployez. OPAL-RT répond parfaitement à ces critères, car il prend en charge l’étape au cours de laquelle les équipes de contrôle valident l’exécution sur le matériel avant que le développement du micrologiciel de bas niveau ne verrouille la conception.