Validation et vérification du modèle
Commandes à réseaux de Petri - Modélisation

Tous les automatismes logiques ont un comportement pouvant faire l’objet d’une modélisation par réseau de Petri. Cet outil est en effet orienté vers la représentation de systèmes à événements discrets dont les variables d’état évoluent brusquement d’une valeur à l’autre sans qu’il soit nécessaire de représenter les phénomènes transitoires. Entrent dans cette classe, les systèmes de commande comportant ou non des évolutions simultanées, les procédés ou systèmes commandés par modèles à événements discrets, les systèmes automatiques (commande et procédé). Le mode d’évolution asynchrone des réseaux de Petri en fait le modèle par excellence des applications réparties et bien sûr des protocoles de communication. Enfin, ils sont très utilisés pour l’évaluation de performance par simulation ou par calcul formel sur des extensions du modèle comportant des données statistiques ou stochastiques.

La capacité de description du modèle par réseau de Petri trouve ses limites lorsque des dates absolues apparaissent dans le cahier des charges. En effet, le temps n’est pas pris en compte explicitement par ce modèle. Il est donc difficile de représenter des applications contenant des recommandations telles que « à la date t, … ». En revanche, la prise en compte de durée est tout à fait possible grâce aux extensions temporelles du modèle de base. Il est donc tout à fait naturel d’envisager une représentation par réseau de Petri d’un cahier des charges contenant : « après une attente de 10 secondes, … ». La distinction n’est pas toujours immédiate mais découle d’une référence à un temps absolu (date) ou à un temps relatif (durée). Une autre limitation importante du modèle à réseau de Petri concerne la non-existence de mécanisme d’abstraction. Hormis l’utilisation du concept d’activité décrit dans cet article et qui n’est pas spécifique à ce modèle, aucun mécanisme d’agrégation n’est véritablement proposé par les réseaux de Petri.

Bien sûr, d’autres outils de modélisation peuvent être utilisés pour la modélisation à événements discrets. Par exemple, les automates à états finis permettent de capturer sans difficulté le comportement séquentiel d’une application. En revanche, dès que des évolutions simultanées doivent être représentées, surtout si elles doivent être synchronisées de temps à autre, la représentation par graphe d’état devient complexe (on parle d’explosion combinatoire du nombre d’états) et surtout le comportement global du modèle devient difficile à appréhender. Le Grafcet (graphe fonctionnel de commande étape transition, langage normalisé pour les API) peut être utilisé en lieu et place des réseaux de Petri. Il convient de savoir que le Grafcet, qui a été défini par un groupe de travail de l’Adepa dans les années 1980, est en fait un dérivé des réseaux de Petri binaires. Le Grafcet peut être préféré pour des questions de mise en œuvre. En revanche, il devient rapidement difficile à utiliser quand le besoin de comptage (de pièces, de messages, etc.) se fait sentir et l’on aura alors plutôt recours aux réseaux de Petri. Signalons enfin que la règle du Grafcet stipulant que « toutes les transitions franchissables sont franchies simultanément » introduite pour le rendre déterministe transforme, en cas d’erreur de modélisation, un choix en départ en parallèle. Ce problème n’existe pas avec les réseaux de Petri. Une extension des automates à états finis, les statecharts, constitue une alternative à la modélisation des systèmes à événements discrets. Ils intègrent l’abstraction, l’orthogonalité pour le parallélisme et la diffusion pour les communications. Le problème de la validation globale d’une application n’est toutefois pas résolu. À noter que les statecharts permettent de modéliser simplement les mécanismes de préemption sur un groupe d’états et comportent un mécanisme d’historique permettant de replacer le modèle dans le dernier état qui avait été atteint avant une préemption. Les statecharts sont à considérer pour des applications comportant ces mécanismes, mais il faut savoir que la mise en œuvre d’un statechart est un problème non résolu à l’heure actuelle.

En résumé, pour une application à caractère distribué, les réseaux de Petri, de par leur fonctionnement asynchrone, s’imposeront assez naturellement, sauf si les traitements de données constituent l’essentiel des opérations à modéliser. En effet, l’interaction avec des données est bien prise en compte par le modèle « réseau de Petri à objets », mais si la structure de contrôle est quasi inexistante, alors elle constituera plutôt une gêne qu’un avantage. Il faut s’orienter dans ces conditions vers des modèles basés sur les flux de données (SADT, SA-RT). Un critère important qui peut conduire au choix des réseaux de Petri est le besoin de pouvoir établir des preuves formelles de propriétés (vivacité ou atteignabilité par exemple) devant absolument être satisfaites par l’application. La représentation formelle est alors un support de la plus grande importance. La possibilité d’effectuer des simulations permet de mesurer avec des données statistiques ou stochastiques les performances que l’on peut espérer du système. Cela est particulièrement utile dans les phases de conception lorsque des choix d’architecture ou de principe doivent être faits. Enfin, la représentation graphique d’un modèle et les règles de fonctionnement simples qui en sont caractéristiques en font un outil privilégié dans le domaine de la didactique. N’importe qui, possédant un niveau scientifique de début d’études supérieures, peut rapidement comprendre le fonctionnement d’un modèle s’il lui est présenté de façon pragmatique. Cet outil peut donc devenir un élément essentiel de communication avec un client, un bureau d’études, etc.

L’utilisation de l’outil « réseaux de Petri » pour assurer la commande de systèmes à événements discrets se décline en fait en deux étapes principales : modélisation de la commande à réaliser et analyse du modèle développé, puis mise en œuvre effective de la commande modélisée. Ces deux étapes font chacune l’objet d’un article : ce premier article concerne l’étape « modélisation, analyse », le second traitant de l’étape de « mise en œuvre ». Un exemple d’application y est également donné.