Application des bonnes pratiques pour la création de grands modèles Simulink

À mesure que les systèmes augmentent en taille et en complexité, les équipes d’ingénierie sont confrontées à un ensemble de défis entièrement nouveaux qui n’existent pas à des échelles plus petites.

Presque toujours, une augmentation significative de l’échelle nécessite un changement d’approche, non seulement en termes de portée, mais également de nature. Ce principe s'applique également aux modèles Simulink^® lorsque vous travaillez avec l’approche Model-Based Design. Lorsque les bonnes pratiques ne sont pas suivies, une multitude de problèmes commencent à apparaître lors de la transition de simples modèles de preuve de concept vers des modèles à grande échelle avec des centaines de milliers de blocs, notamment des problèmes d’architecture de modèles médiocre, de gestion des données, d'interfaces, de gestion de fichiers et de performances de simulation. Les éléments de base de ces grands modèles peuvent être de petite taille, souvent développés par des individus, des équipes et même des départements différents. Lorsque la normalisation est mise en place et que les bonnes pratiques sont suivies, ces modèles peuvent être facilement développés à grande échelle.

Cet article décrit un ensemble de bonnes pratiques pour gérer les défis couramment rencontrés lors de l'utilisation de modèles volumineux et complexes dans Simulink. Étant donné que ce sujet lui-même est assez vaste, l’objectif ici n’est pas de fournir des conseils détaillés et prescriptifs, mais plutôt de présenter les bases de chaque bonne pratique ainsi que des liens vers des ressources supplémentaires qui peuvent être explorées pour une compréhension plus approfondie de la manière dont elles peuvent être appliquées.

Utiliser la référence de modèle pour la modularisation du modèle

Lorsque nous travaillons avec des clients, il n’est pas rare de voir de grands modèles dépourvus de modularité significative. Les équipes commencent avec un modèle simple pour tester des idées ; au fil du temps, de nouveaux éléments ou fonctionnalités sont ajoutés, et tout le travail est effectué dans un seul fichier de modèle monolithique qui devient rapidement difficile à manier.

Dans Simulink, il existe plusieurs façons de décomposer en module de grands modèles, et la meilleure approche dépendra du cas d'utilisation spécifique considéré. Par exemple, une équipe qui souhaite simplement organiser visuellement un groupe de blocs ou de composants peut opter pour un sous-système virtuel intégré au modèle. Pour une équipe différente qui souhaite créer des utilitaires largement utilisés qui changent rarement, un sous-système lié (ou bibliothèque) est une meilleure option. Si l’objectif est de développer ou de simuler un composant en tant que modèle autonome, alors la référence de modèle est la meilleure approche.

La référence de modèle est également la clé de la modularisation des modèles à grande échelle. L’une des raisons est que la référence de modèle dans Simulink permet aux équipes de développer des composants en parallèle en tant que modèles indépendants. Chaque composant est entièrement fonctionnel et simulable, ainsi qu'enregistré dans son propre fichier SLX afin que chaque équipe puisse travailler de manière indépendante sans interférer avec le travail d'une autre équipe, ce qui est pratiquement impossible à faire lorsque le design entier est capturé dans un seul fichier. Tout aussi important, ces modèles de référence indépendants peuvent être placés à l’intérieur de modèles plus grands pour une intégration facile (Figure 1). Cette architecture peut réduire les temps de compilation en utilisant des instances mises en cache de modèles de référence et des compilations incrémentielles. Cela permet également l'utilisation de accelerator et rapid accelerator modes, qui sont abordés plus en détail ci-dessous dans la section sur les performances.

Améliorer la gestion des données grâce aux dictionnaires de données

Reprenons le même scénario qui a conduit à des problèmes de modularisation : une équipe commence avec un modèle simple comme première preuve de concept, puis continue de développer au fil du temps. Pour un modèle simple, de nombreux ingénieurs stockeront des variables, des paramètres et d’autres données dans l’espace de travail de base. Cette approche fonctionne bien pour les workflows informels, le réglage rapide des paramètres, le prototypage rapide, les projets à développeur unique ou les cas d’utilisation qui nécessitent une visibilité universelle des paramètres. Cependant, à mesure que la portée et la complexité des modèles augmentent, le recours à l’espace de travail de base pour la gestion des données présente certains inconvénients. Par exemple, étant donné que l'espace de travail de base est effacé chaque fois qu'un ingénieur ferme sa session, il doit être enregistré manuellement dans du code (.m) MATLAB^® ou dans un fichier MATLAB (.mat).

Les dictionnaires de données sont mieux adaptés que l'espace de travail de base pour la gestion des données sur des projets impliquant de grands modèles, un développement distribué ou des données limitées. Il y a plusieurs raisons à cela (voir Figure 2). Premièrement, la persistance des données. Les données sont enregistrées dans un format de fichier spécifique dans des fichiers de dictionnaire de données (.sldd), permettant aux équipes de définir, de gérer et de mettre à jour les données séparément du modèle et de l'espace de travail de base. Deuxièmement, les équipes peuvent partitionner les données en plusieurs dictionnaires pour améliorer encore l’organisation des données. Troisièmement, les dictionnaires de données fonctionnent bien dans les workflows de suivi des modifications, dans lesquels les équipes peuvent voir quelles modifications ont été apportées, quand elles ont été apportées et qui les a apportées, et même revenir aux versions antérieures si nécessaire.

Il est important de noter ici que le choix entre l’utilisation de l’espace de travail de base et des dictionnaires de données ne s’effectue pas en tout ou rien. Les deux approches peuvent coexister, de sorte qu’une équipe peut migrer progressivement de l’espace de travail de base vers un ou plusieurs dictionnaires de données au fil du temps.

Simplifier les interfaces avec les bus

Lors de la connexion de sous-systèmes dans un modèle hiérarchique à composants, il peut sembler au premier abord que l'approche la plus simple consiste à utiliser une ligne de signal distincte pour chaque élément transmis d'un composant à un autre. Bien sûr, cela fonctionne pour des interfaces simples, mais cette approche peut rapidement aboutir à des modèles plus complexes, encombrés et plus difficiles à gérer que nécessaire.

Dans Simulink, les bus peuvent simplifier les interfaces et réduire l'encombrement en représentant un ensemble de signaux (ou d'éléments) avec une seule ligne, un peu comme plusieurs fils regroupés ensemble. L’intérêt de ceci est facile à voir avec un exemple simple. Considérez un composant de détection de défaut pour identifier les conditions anormales dans un système de batterie. Le composant dispose de 11 entrées différentes, notamment la tension maximale et minimale de la cellule, la température maximale et minimale de la cellule, les états du contacteur, la tension et le courant du pack et les limites de courant. Bien qu'il soit certainement possible de créer le composant avec 11 ports d'entrée individuels, il est plus propre de séparer les entrées en groupes logiques et d'utiliser un bus pour chaque groupe. Par exemple, étant donné que les signaux de tension et de température de cellule proviennent tous du même composant et sont tous liés, il est logique de les regrouper dans un seul bus à quatre éléments (Figure 3). Il s’agit clairement d’un exemple relativement trivial, mais il illustre comment les bus peuvent être utilisés pour simplifier non seulement les interfaces des composants mais, plus largement, les modèles complexes.

Améliorer la gestion des fichiers avec les projets

L’un des effets secondaires du suivi des bonnes pratiques décrites jusqu’à présent est une augmentation du nombre de fichiers à gérer. Lorsque l'ensemble du design repose sur un modèle unique, l'ensemble des fichiers qu'une équipe doit gérer est relativement petit, mais il peut rapidement croître lorsque la modularisation et les dictionnaires de données sont activement utilisés. Sans stratégie de gestion de fichiers, cette prolifération de fichiers peut devenir problématique.

Lorsqu'elles travaillent dans Simulink, les équipes peuvent utiliser des projets pour aider à automatiser les activités de gestion de fichiers, afin qu’elles aient plus de temps à consacrer à la modélisation, à la simulation et à d'autres activités à forte valeur ajoutée. Par exemple, lors de la configuration d’un projet, l'équipe spécifiera les dossiers dans le chemin du projet. Ces dossiers sont ajoutés au chemin de recherche lorsque le projet est ouvert (et supprimés lorsque le projet est fermé), garantissant ainsi que tous les utilisateurs du projet ont accès aux fichiers qu'ils contiennent. L'équipe peut également spécifier les fichiers de démarrage qui automatisent la configuration de l'environnement pour votre projet et arrêtent les fichiers qui nettoient l'environnement en annulant les étapes de configuration, par exemple. De plus, les projets peuvent être configurés pour ouvrir les fichiers fréquemment utilisés au lancement et créer des raccourcis pour les tâches fréquemment utilisées.

Les projets peuvent également aider les équipes à éviter les erreurs courantes. Par exemple, avec une hiérarchie de modèles complexe, il n’est pas rare que deux fichiers de modèles portant le même nom existent dans des répertoires différents. Lors de l'utilisation d'un projet, un ingénieur verra un avertissement lorsque de tels fichiers « masqués » sont détectés. De plus, les ingénieurs sont invités à enregistrer toutes les modifications non enregistrées lors de la fermeture d'un projet, ce qui permet d'éviter toute perte de travail.

Enfin, les projets aident à rationaliser la Gestion de version, avec des opérations courantes telles que l'actualisation, la validation, l'envoi, l'extraction, la récupération et d'autres opérations courantes accessibles directement depuis l'interface utilisateur (Figure 4).

Optimiser les performances de simulation

Les bonnes pratiques que nous avons abordées jusqu’à présent se sont principalement concentrées sur la structure des grands modèles et sur leurs données et fichiers associés. Lors de conversations avec les clients qui ont mis en œuvre ces bonnes pratiques, on nous demande souvent comment améliorer les performances de simulation : « Maintenant que nous avons une meilleure façon de compiler de grands modèles, comment pouvons-nous les faire simuler plus rapidement ? »

Plusieurs outils sont disponibles pour améliorer les performances de simulation. Dans un premier temps, nous vous recommandons Performance Advisor, qui exécute une série de vérifications pour identifier les paramètres de configuration susceptibles de ralentir les simulations. Ensuite, pour tout modèle qui inclut le code MATLAB d'initialisation (dans un rappel, par exemple), c'est une bonne idée d'exécuter MATLAB Profiler App pour identifier où MATLAB passe le plus de temps. Simulink Profiler évalue le temps d’exécution du modèle et identifie les problèmes qui peuvent contribuer à de mauvaises performances de simulation. Enfin, pour les équipes utilisant un solveur à pas variable, nous recommandons d'exécuter Solver Profiler, qui analyse le comportement du solveur, identifie les problèmes potentiels (tels que les réinitialisations du solveur ou des pas de temps exceptionnellement petits) et fournit des recommandations pour les résoudre. Des conseils sur chacun de ces outils, y compris comment et quand les utiliser, sont disponibles dans le guide Troubleshoot and Speed Up Simulation Performance (voir tableau).

Les équipes qui ont décomposé en modules leur grand modèle peuvent accélérer les simulations en utilisant accelerator mode ou rapid accelerator mode, qui remplacent le code interprété normalement utilisé dans les simulations Simulink par du code généré. Lors de l'initialisation du modèle, Simulink vérifie dans un cache tous les composants pour lesquels du code a déjà été généré. Ce processus de compilation incrémentielle réduit considérablement le temps d'initialisation des grands modèles comportant de nombreux composants, car seuls les composants qui ont changé depuis la dernière simulation devront être reconstruits (et ajoutés au cache).

Une autre façon de réduire le temps d’initialisation, en particulier lors de la simulation itérative d’un modèle, consiste en un redémarrage rapide. Lorsqu'une équipe effectue plusieurs simulations sans apporter de modifications structurelles au modèle, un redémarrage rapide peut accélérer le processus en effectuant les simulations sans compiler le modèle et en mettant fin à la simulation à chaque fois. Dans ce cas, lors de la première simulation, le modèle est compilé et initialisé, puis un instantané du point de fonctionnement du modèle est capturé pour chaque simulation ultérieure (Figure 5).

En conclusion, alors que les équipes d’ingénierie naviguent dans les complexités de la mise à l’échelle des modèles Simulink, le respect des bonnes pratiques devient essentiel. Cet article a décrit les stratégies essentielles pour la décomposition en modules des modèles, la gestion des données et l’optimisation des performances, en soulignant l’importance d’une approche structurée du développement des modèles. En exploitant des outils tels que Performance Advisor, MATLAB Profiler et Solver Profiler, les équipes peuvent améliorer les performances de simulation et améliorer la productivité. Ces pratiques garantissent que les modèles à grande échelle restent gérables, efficaces et adaptables. Alors que le paysage de l’approche Model-Based Design continue d’évoluer, ces lignes directrices aideront les équipes à créer des modèles robustes qui répondent aux exigences de défis d’ingénierie de plus en plus complexes. Pour une exploration plus approfondie, les lecteurs sont encouragés à utiliser les ressources complémentaires et les opportunités de formation mentionnées tout au long de cet article.

Le contenu de cet article est basé sur une conférence intitulée « Best Practices for Building Large Models from Components to Complex Systems » (Bonnes pratiques pour la création de grands modèles, depuis les composants jusqu'aux systèmes complexes) (voir « En savoir plus » pour cette conférence, ainsi que d'autres webinaires et formations), que nous avons présentée lors de la conférence MathWorks Automotive. Comme nous l’avons souligné au début, il s’agit d’un sujet vaste qui ne peut être traité de manière exhaustive dans un seul article ou une seule conférence.