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....