Les phénomènes environnementaux et les systèmes d’origine humaine (processus industriel, véhicule, robot) nécessitent d’être étudiés et analysés afin d’en comprendre le fonctionnement précis pour à la fois en tirer le plein potentiel mais aussi pour pouvoir anticiper les problèmes qui peuvent émerger du fonctionnement et, si possible, les résoudre. Pour cela les ingénieurs doivent développer des modèles mathématiques à partir de leurs connaissances sur les systèmes. Ces modèles doivent ensuite être transformés en artefacts informatiques utilisés notamment pour simuler ces systèmes, étape indispensable pour leur compréhension et également pour valider les modèles.
Les langages de modélisation permettent de faciliter la traduction des modèles mathéma- tiques en entités informatiques permettant leur exploitation. Or de plus en plus de systèmes sont hétérogènes. Ils peuvent comprendre des composants provenant de domaines très divers (par exemple les systèmes cyber-physiques qui comprennent entre autres des composants élec- troniques, mécaniques, des processus chimiques ou des réseaux). Les modèles de ces systèmes sont en outre développés dans des disciplines mathématiques différentes qui ont chacune leur propre paradigme de représentation. Enfin, l’évolution des connaissances théoriques nécessite souvent que les modèles soient enrichis ou corrigés. De fait la modularité est devenue une préoccupation importante lors de la modélisation d’un système surtout lorsque celui-ci est hétérogène.
Si la conception de contrôleurs n’est pas la préoccupation première de ces approches, les mécanismes qu’elles proposent s’avèrent pertinents pour notre problématique.
2.3.1
Simulink
Ainsi un premier effort de standardisation, CSSL, apparut en 1967. Il propose une métho- dologie qui consistait à décrire des systèmes sous forme de blocs d’entrées/sorties. L’outil le plus répandu basé sur cette approche est Simulink [Kar06].
2.3. Modélisation de systèmes et modularité
Simulink propose de décrire un système, un contrôleur ou une combinaison des deux sous forme d’un diagramme constitué de blocs d’entrées/sorties reliés par des liens. Les données échangées entre les blocs peuvent être des nombres, des vecteurs ou des matrices. Simulink permet également de s’assurer de la cohérence des dimensions au niveau des connexions entre blocs. Qui plus est, il est possible de simuler des systèmes en temps continu ou en temps discret (notamment en utilisant des blocs pour représenter les bloqueurs d’ordre 0). La grande variété des blocs disponibles permet de décrire des systèmes dans une large gamme de domaines ap- plicatifs. Enfin, des blocs permettent de décrire des sous-systèmes (des diagrammes encapsulés dans un bloc) afin de mieux structurer la description d’un système.
Néanmoins, l’approche proposée par Simulink présente un certain nombre de limitations. La principale est le manque d’expressivité de l’interface des blocs. En effet, Simulink ne permet d’exprimer que des données numériques. Il n’est ainsi pas possible d’attacher un type ou une unité aux données. Cela rend les blocs très génériques et la lecture des diagrammes plus complexe. Une autre limitation, exprimée dans [EM97], est rattachée à l’utilisation de blocs d’entrées/sorties. Ce mécanisme n’est pas réellement adapté à la représentation de certains éléments (notamment des composants matériels) dont la modélisation est en conséquence difficile.
2.3.2
Modelica
Pour répondre à la problématique de description modulaire de systèmes hétérogènes, le développement d’une nouvelle approche commença en 1996. Elle aboutit au langage Modelica [EM97]. Ce langage repose sur le paradigme objet afin de bénéficier de ses apports notamment en termes de modularité et d’évolutivité. L’encapsulation offerte par le paradigme objet permet de faire cohabiter ensemble des paradigmes de représentation divers (équations différentielles, équations aux différences, automates à état fini ou encore réseaux de Petri) tout en autorisant leur manipulation de manière homogène [EMO98].
Modelica est un langage fortement orienté vers la réutilisation des composants et permet à la fois une composition hiérarchique de divers composants et une forte utilisation des méca- nismes d’héritage. Il existe divers types de classes. La classe model sert à définir les composants ainsi que leurs assemblages. L’Exemple de Code 2.1 présente le système de contrôle moteur présenté dans la Figure 2.13 décrit dans le langage Modelica [EMO98].
Exemple de Code 2.1 – Représentation Modelica d’un système de contrôle moteur
1 model MotorDrive 2 Motor motor;
3 PI controller;
4 Gearbox gearbox(n=100); 5 Shaft J1(J=10);
6 Tachometer w1;
7 equation
8 connect (controller.out, motor.in);
9 connect (motor.flange, gearbox.a);
10 connect (gearbox.b, J1.a);
11 connect (J1.b, w1.a);
12 connect (w1.w, controller.in);
13 end MotorDrive;
Figure2.13 – Un système de contrôle moteur (figure tirée de [EMO98, Figure 1])
La première partie du modèle, lignes 2 à 6, sert à indiquer les composants du système. La seconde partie décrit le comportement du système. Ici, vu qu’il s’agit de la description d’un système, il ne contient que la description des connexions entre ses composants. Il est également à noter, comme observé lignes 4 et 5, que lors de la déclaration d’un composant, il est possible de valuer certains de ses paramètres.
Les composants eux-mêmes sont définis via un model comme l’illustre l’Exemple de Code 2.2 tiré de [EMO98].
Exemple de Code 2.2 – Représentation Modelica d’un arbre de transmission
1 model Shaft 2 extends TwoFLange; 3 parameter Inertia J=1; 4 AngularVelocity w; 5 equation 6 a.r = b.r; 7 der(a.r) = w; 8 J*der(w) = a.t + b.t; 9 end Shaft;
2.3. Modélisation de systèmes et modularité
Dans la première partie du model, les paramètres sont définis (ici l’inertie du moteur) ainsi que les grandeurs internes au composant. Son comportement interne est décrit après le mot clé equation (lignes 6 à 8). Enfin le mot clé extends sert à indiquer que le composant dérive d’un autre composant. L’héritage est au centre du concept de réutilisation dans Modelica. En effet, il permet de définir les propriétés communes à différents composants similaires pour que le concepteur du composant puisse se concentrer sur le comportement spécifique de celui- ci. Ainsi, dans ce cas, l’arbre hérite du composant T woF lange. Effectivement, un arbre de transmission a deux brides. Le composant de base est défini à l’Exemple de Code 2.3.
Exemple de Code 2.3 – Représentation Modelica d’un composant fait de deux brides
1 partial model TwoFlange 2 Flange a, b;
3 end TwoFlange;
Un composant qui sert à définir un modèle "abstrait" (équivalent aux classes abstraites proposées par exemple dans le langage C++) est défini par le mot clé partial model. Dans ce cas là, aucune équation interne n’est définie mais il est évidemment possible de le faire. Pour définir les classes servant à connecter deux composants ensemble, comme une Flange définie précédemment, cela est réalisé avec le mot clé connector tel que montré dans l’Exemple de Code 2.4.
Exemple de Code 2.4 – Représentation Modelica d’une bride
1 connector Flange 2 Angle r; 3 flow Torque t; 4 end Flange;
Cette classe définit les données internes au connecteur. Le mot clé flow sert à indiquer qu’au niveau du connecteur la somme des couples induits par différents composants doit être nulle. Les calculs et les vérifications découlant de cette hypothèse sont directement effectués par Modelica.
La gestion des types est également assurée via des classes. Les classes de type doivent hériter de classes prédéfinies représentant les types informatiques de base (entiers, réels par exemple) et redéfinissent certaines de leurs propriétés comme illustré par l’Exemple de Code 2.5.
Exemple de Code 2.5 – Représentation Modelica du type Angle
1 type Angle = Real(quantity = "Angle", unit = "rad", displayUnit = "deg");
Le paramètre quantity sert à spécifier la grandeur physique représentée par le type, unit l’unité utilisée dans les échanges d’information et displayUnit l’unité à afficher si différente de celle utilisée dans les connexions. D’autres paramètres que ceux-ci sont également utilisables [Mod00]. Des grandeurs physiques identiques mais exprimées dans des unités différentes ne peuvent pas être connectées ensemble.
Il est également possible de définir des classes block dans lesquelles les différents connecteurs sont orientés entre entrées et sorties. La partie équation d’une classe peut également être remplacée par une partie algorithme qui permet de décrire des comportements plus complexes. Les équations supportent également la description de comportements en temps discret ou d’opérations logiques à l’aide d’opérateurs dédiés. Des comportements hybrides peuvent être décrits à l’aide de l’opérateur when. Plus de détails sur les très nombreux opérateurs et classes offerts par la langage Modelica sont disponibles dans [Mod00].
Enfin, même si la conception de contrôleurs n’était pas un objectif originel du langage Mo- delica, plusieurs librairies ont été développées afin de permettre leur description et leur analyse telles que [BL12] ou [BOT09]. Cette dernière propose des représentations de systèmes très va- riées en temps continu ou discret. Elle propose également plusieurs contrôleurs de structure souvent simple (Proportionnel-Intégral-Dérivé, PID, par exemple). Elle comprend également des outils permettant l’analyse des systèmes ou l’aide à la conception des contrôleurs tels que le tracé de la réponse à différent signaux (réponse impulsionnelle ou à l’échelon notamment), la détermination des pôles d’un système ou encore des outils d’aide à la conception de Filtres de Kalman. Néanmoins, elle est limitée aux systèmes linéaires.
Modelica n’étant pas conçu pour la description de contrôleur, il présente certaines limi- tations dans notre contexte applicatif. Principalement, Modelica ne peut pas faire porter sur les objets de contraintes, notamment temporelles, relatives à leur implémentation. En outre, certains composants logiciels tels que des drivers ne sont pas simples à exprimer dans Modelica où les différents composants doivent avoir une équation ou un algorithme constitutif.