Limites des spécifications de problèmes dans les systèmes de calcul formel

Le chapitre précédent a mis en lumière deux choix de conception contestables dans des outils de spécification de modèles, intégrés à un système de calcul formel : l’utilisation d’une formulation transformée de l’équation originale dans femLego, et le mélange des spécifications dans SciNapse. Ces choix sont le fait des concepteurs des boîtes à outils respectives.

A l’inverse, certaines limites dans la spécification de modèles de systèmes industriels complexes ne résultent pas de mauvais choix de conception, mais sont structurellement liées à leur réalisation au sein de systèmes de calcul formel. Les systèmes industriels complexes sont le plus souvent des systèmes hybrides, composites, et multi-physiques. Leur spécification s’accommode donc bien, voire requiert, trois fonctionnalités :

1. un formalisme de représentation de modèles discontinus ; 2. des primitives de couplage de modèles ;

3. des bibliothèques de modèles préétablis et réutilisables.

Les points suivants analysent la faiblesse ou l’absence de réponses des systèmes de calcul formel à ces trois besoins.

1.2.2.3.1.Absence d’un formalisme de représentation de modèles discontinus

Comme le note (Faure, Davenport, & Naciri 2000), si « la force principale du calcul formel est l’obtention de familles d’expressions en un seul calcul [… dans lesquelles certains symboles] font office de paramètres », dans les systèmes de calcul formel courants aucune détection d’incohérence liée à des valeurs particulières des paramètres n’est effectuée. De plus, aucun domaine de variation particulier n’étant assigné à un symbole, et l’évaluation de chaque expression produisant une expression unique le calcul symbolique, tel qu’il est habituellement mis en œuvre, n’est en rien une réponse à la représentation des modèles discontinus. (Faure, Davenport, & Naciri 2000) introduit des expressions multi-valuées particulières, appelées expressions conditionnelles, qui semblent être une avancée par rapport à la structure de contrôle conditionnelle If telle qu’elle est traitée dans Mathematica. Dans une expression conditionnelle, chaque « valeur potentielle est associée à une condition sur des paramètres ». La syntaxe de telles expressions conditionnelles est la suivante :

Calcul formel préprocesseur pour le calcul numérique

Indépendamment de son objectif initial -éviter l’incohérence de certains calculs dans lesquels interviennent des paramètres- cette introduction de la notion de fonction par morceaux semble intéressante pour représenter des modèles discontinus. Si elle permet d’envisager sérieusement la représentation d’événements de temps entraînant des changements de modèles, elle est hélas incapable de prendre en compte des événements d’état car « il est supposé que seuls des paramètres apparaissent dans les conditions ». De ce point de vue, la construction syntaxique When[région, équations] introduite dans SciNapse est supérieure. En effet une région, ou domaine spatio-temporel, y est définie par une condition logique portant sur l’ensemble des symboles, variables ou paramètres, du modèle. Les discontinuités spatiales et temporelles du modèle sont donc décrites dans un formalisme unique et élégant. Mais cette formulation n’est en aucun cas un modèle du comportement hybride du système, manipulable en tant que tel à des fins d’analyse de fonctionnement, de contrôle, etc. Aucun des systèmes de calcul formel largement diffusé ne propose de formalisme discret, que ce soit un formalisme de machines à états, ou un formalisme de type réseau de Petri, et à notre connaissance la littérature ne relate pas d’expérience de couplage entre un simulateur de systèmes discrets et un système de calcul formel.

1.2.2.3.2.Absence de primitives de couplage de modèles

L’approche usuelle en modélisation de systèmes (continus) est la construction d’un modèle complet à partir de modèles élémentaires des différentes parties du système à représenter. Le processus de composition de modèles peut prendre diverses formes. La plus courante est la mise en relation de deux modèles par l’identification de symboles propres à chacun de ces modèles. La sémantique de cette identification est claire : les valeurs numériques des symboles associés deux à deux sont égales. L’environnement de modélisation et de simulation MATLAB/SIMULINK est construit sur ce principe. Il en est de même du langage de modélisation Modelica (Fritzson & Engelson 1998). En pratique, la construction du modèle complet s’appuie sur une interface graphique permettant de choisir des modèles élémentaires, représentés par icônes spécifiques, et de les relier par des arcs symbolisant les connexions. La simplicité et la généralité du concept font que ce type d’interface d’accès aux modèles et à leurs relations est intégrée à bon nombre de systèmes de simulation numérique. Son absence des systèmes de calcul formel actuels peut laisser penser que ces produits ne visent pas la modélisation et la simulation de modèles complexes. L’unique solution de composition de modèles disponible dans les systèmes de calcul formel est la concaténation des listes d’équations des différents modèles dans une liste unique. Cela est illustré dans (Alfradique & Castier 2005) où un bilan enthalpique, un bilan massique, une équation d’équilibre entre phases et une équation

d’équilibre chimique sont concaténés afin de constituer l’ensemble des équations d’un étage de la colonne à distiller réactive. Ce modèle est ensuite concaténé au modèle dérivé pour constituer un modèle complet d’un étage, intégrant les sensibilités analytiques. Concaténer ainsi des équations ou des modèles impose que les éléments combinés suivent une nomenclature unique, à moins bien sûr d’effectuer des remplacements préalables de certains symboles par les symboles de la nomenclature. Ce respect d’une nomenclature unique assure une cohérence entre les différents éléments du modèle spécifié. S’il est souhaitable dans le cadre de la modélisation par une seule et même personne, il est illusoire et contre-productif dans le cas d’un modèle complexe dont chaque élément est spécifié par une ou plusieurs personnes. Dans ce cas l’assemblage de modèles repose le plus souvent sur deux principes complémentaires :

1. chaque modèle d’un système particulier est vu comme une instance nommée d’un modèle générique représentant tous les systèmes régis par des lois identiques ;

2. des paires de symboles intervenant chacun dans un modèle distinct sont identifiées comme représentant la même grandeur.

La programmation orientée objet trouve naturellement sa place dans l’application informatique du principe 1 : une classe est le modèle informatique structurel de tous les systèmes régis par des lois identiques, tandis qu’un objet est le modèle structurel et comportemental d’un système particulier. Le langage à objets Modelica met en œuvre ce principe en proposant de regrouper dans une classe les équations caractéristiques d’un système, les attributs de la classe étant notamment les symboles intervenant dans ces équations.

Le principe 2 est le plus souvent appliqué en introduisant dans le langage de spécification du problème la possibilité de connecter entre elles des grandeurs issues de modèles distincts. Les équations de connexion proposées par Modelica peuvent être vues comme une généralisation de l’identification de paires de symboles : deux symboles peuvent bien sûr être considérées comme identiques mais, outre l’égalité, d’autres lois de connexion (lois de Kirchoff) peuvent être établies entre plusieurs symboles suivant la nature physique de la grandeur qu’ils représentent (Mattsson, Elmqvist, & Otter 1998).

1.2.2.3.3.Absence de bibliothèques de modèles préétablis et réutilisables Un dernier obstacle à la spécification de systèmes industriels complexes à l’aide de systèmes de calcul formel est l’impossibilité de constituer des bibliothèques de modèles à échanger et à réutiliser. Les systèmes de calcul formel les plus utilisés se sont enrichis de boîtes à outils, couvrant les traitements spécifiques à certaines branches des mathématiques ou des sciences physiques. Mathematica propose notamment des compléments dédiés au contrôle, au traitement d’images ou à l’analyse de données expérimentales. De même, Maple peut intégrer

Calcul formel préprocesseur pour le calcul numérique

des boîtes à outils relatives à la géométrie différentielle, à la résistance des matériaux, ou à la logique floue. Toutefois, la capitalisation de modèles dans ces environnements est restée embryonnaire. Une première raison, et à notre avis la plus importante, découle du point précédent : l’impossibilité de combiner des modèles au travers d’une interface graphique freine la réutilisation des modèles. (Barker & Zhuang 1997) supputaient que « l’application [du calcul formel] à l’ingénierie du contrôle avait été assez limitée, sans doute car les premiers logiciels n’étaient pas particulièrement conviviaux ». Leur article relate l’interfaçage des environnements

SIMULINK et Mathematica, aboutissant à un environnement dans lequel « les modèles sont

construits au moyen d’une interface graphique compréhensible et bien développée, familière à l’ingénieur de contrôle, et les résultats analytiques obtenus avec Mathematica peuvent être comparés directement avec les résultats de simulation obtenus avec SIMULINK ». Les autres raisons de l’absence de capitalisation sur les modèles dans les systèmes de calcul formel sont à rechercher dans les faiblesses de ceux-ci par rapport aux langages et aux environnements de modélisation récents. Les concepteurs du langage de modélisation Modelica (Elmqvist, Mattsson, & Otter 1999) insistent sur le fait que « la réutilisation de modèles est un point clé pour prendre en charge la complexité ». « Le but de Modelica est de servir de format standard de sorte que les modèles provenant de différents domaines puissent être échangés entre les outils et entre les utilisateurs ». Pour atteindre cet objectif de réutilisation des modèles, plusieurs moyens sont mis en œuvre, techniques d’une part et organisationnels d’autre part. L’effort de conception du langage est guidé par deux concepts : la conception et la programmation orientées objet, et la modélisation acausale. La puissance de ces concepts, alliée aux technologies éprouvées issues de langages de modélisation existants, justifie pour les auteurs « une nouvelle tentative d’introduire l’interopérabilité et l’ouverture dans le monde des systèmes de modélisation et de simulation ». Outre les équations différentielles ordinaires ou les équations algébro-différentielles caractérisant des systèmes continus, Modelica prend en charge plusieurs formalismes ouvrant la porte à la simulation de systèmes hybrides complexes : les « bond graphs », les machines à états finis, les réseaux de Petri, etc. Du point de vue organisationnel, une démarche de standardisation, avec la constitution d’un groupe d’experts délivrant une première spécification du langage, et l’existence d’une association à but non lucratif chargée du cycle de vie de ce dernier, démontrent une volonté de promouvoir le langage, les outils de simulation le mettant en œuvre et les bibliothèques de modèles. Une bibliothèque des éléments de modélisation les plus couramment utilisés, Modelica Standard Library, est maintenue par l’association afin de favoriser l’échange de modèles construits sur une base commune. A l’opposé des plates-formes comme Modelica, les systèmes de calcul formel pâtissent de trois lacunes, obstacles à la constitution et à l’échange de bibliothèques de modèles :

1. l’absence de formalismes variés, notamment pour spécifier les systèmes discrets ;

2. l’absence d’éléments structurants au dessus de la notion d’expression mathématique, alors que les langages de modélisation orientés objet structurent les équations spécifiques d’un élément de modélisation dans une classe, et classifient les modèles via les notions d’héritage et de composition des classes ;

3. l’absence d’interopérabilité avec les langages de modélisation largement utilisés comme

VHDL-AMS, Verilog-AMS, MAST ou Modelica.

1.2.2.4.Des systèmes inadaptés à la spécification de modèles hybrides