Article de référence | Réf : S7572 v1

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

Auteur(s) : Michel COMBACAU, Philippe ESTEBAN, Alexandre NKETSA

Date de publication : 10 mars 2005

Pour explorer cet article
Télécharger l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !

Sommaire

Présentation

Version en anglais En anglais

RÉSUMÉ

La modélisation par réseau de Pétri permet la représentation de systèmes à événements discrets présentant des évolutions brutales de leurs variables d’état, donc toute application à caractère distribué, le cas notamment des systèmes automatiques, systèmes de commande et protocoles de communication. L’utilisation de cet outil débute par la modélisation de la commande à réaliser avec analyse du modèle développé, la commande modélisée est ensuite exécutée. Cet article traite de la première étape.

Lire cet article issu d'une ressource documentaire complète, actualisée et validée par des comités scientifiques.

Lire l’article

Auteur(s)

  • Michel COMBACAU : Professeur, université Paul-Sabatier (Toulouse-III), Laboratoire d’analyse et d’architecture des systèmes (LAAS-CNRS)

  • Philippe ESTEBAN : Maître de conférences, université Paul-Sabatier (Toulouse-III), LAAS-CNRS

  • Alexandre NKETSA : Professeur, université Paul-Sabatier (Toulouse-III), LAAS-CNRS

INTRODUCTION

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 Commandes à réseaux de Petri- Mise en œuvre et application traitant de l’étape de « mise en œuvre ». Un exemple d’application y est également donné.

Cet article est réservé aux abonnés.
Il vous reste 95% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

DOI (Digital Object Identifier)

https://doi.org/10.51257/a-v1-s7572


Cet article fait partie de l’offre

Automatique et ingénierie système

(137 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Présentation
Version en anglais En anglais

2. Validation et vérification du modèle

Un réseau de Petri représentant la commande du procédé a été obtenu par l’étape d’analyse et modélisation. Il a été construit par composition de fonctions ou de comportements qui caractérisent le fonctionnement de parties du système à commander.

Le modèle ainsi obtenu est réputé complet et censé répondre au fonctionnement attendu. Toutefois, est-ce que ce modèle fournit une description correcte de ce qui est souhaité ? Est-ce que la composition d’éléments de base n’a pas introduit de perturbation croisée de ces éléments ?

Pour cela, il faut valider ce résultat, pour tenter de mettre en évidence des erreurs éventuelles de modélisation, et confirmer la conformité du modèle aux spécifications du cahier des charges par la vérification de toutes les contraintes de départ.

Le modèle à réseau de Petri présente la particularité de pouvoir être analysé : à sa représentation graphique est associée une représentation numérique sur laquelle il est possible de mener des opérations analytiques formelles.

Comme il représente le comportement du système de commande, il peut aussi être simulé, c’est-à-dire être parcouru sans pour autant être relié au procédé, à la seule fin de vérifier que les cheminements qu’il est possible de parcourir restent cohérents au regard du fonctionnement attendu.

Il faut toutefois garder présent à l’esprit que la modélisation graphique manuscrite est nécessairement traduite par une méthode ou une autre de mise en œuvre, et il est alors très facile d’oublier de décrire (ou d’ajouter) un arc, de se tromper dans une pondération ou une expression logique. En cela, les méthodes de validation peuvent aussi être trompeuses dans la mesure où un réseau à analyser doit être traduit dans le langage de l’outil de vérification.

La plus grande attention doit donc être portée à la matérialisation du réseau de Petri, aussi bien dans sa description lors de la mise en œuvre que pour son analyse afin que, dans ce contexte, les méthodes de validation et vérification puissent apporter tout leur intérêt pour conclure sur la bonne description du modèle.

2.1 Validation par analyse

La validation par analyse consiste à vérifier quelques indicateurs en appliquant...

Cet article est réservé aux abonnés.
Il vous reste 92% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Automatique et ingénierie système

(137 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS

Lecture en cours
Validation et vérification du modèle
Sommaire
Sommaire

Cet article est réservé aux abonnés.
Il vous reste 94% à découvrir.

Pour explorer cet article
Téléchargez l'extrait gratuit

Vous êtes déjà abonné ?Connectez-vous !


L'expertise technique et scientifique de référence

La plus importante ressource documentaire technique et scientifique en langue française, avec + de 1 200 auteurs et 100 conseillers scientifiques.
+ de 10 000 articles et 1 000 fiches pratiques opérationnelles, + de 800 articles nouveaux ou mis à jours chaque année.
De la conception au prototypage, jusqu'à l'industrialisation, la référence pour sécuriser le développement de vos projets industriels.

Cet article fait partie de l’offre

Automatique et ingénierie système

(137 articles en ce moment)

Cette offre vous donne accès à :

Une base complète d’articles

Actualisée et enrichie d’articles validés par nos comités scientifiques

Des services

Un ensemble d'outils exclusifs en complément des ressources

Un Parcours Pratique

Opérationnel et didactique, pour garantir l'acquisition des compétences transverses

Doc & Quiz

Des articles interactifs avec des quiz, pour une lecture constructive

ABONNEZ-VOUS