Accueil > Cours > Cours > Automatique > Grafcet > G3 - Hierarchisation et structuration des grafcets

G3 - Hierarchisation et structuration des grafcets

mardi 24 août 2004, par papanicola robert

Structuration et hiérarchisation

1. Principe

Les Systèmes Automatisés de production sont de plus en plus complexes, afin de
simplifier l’étude, la mise en oeuvre et la maintenance du système, il est nécessaire de structurer la partie commande et la partie opérative.

L’objectif essentiel de la structuration est de permettre une approche progressive du fonctionnement d’un système automatisé, tant au niveau de l’analyse qu’au niveau de la représentation

Lire la suite dans le fichier flash ou pdf...

Portfolio

Vos commentaires

  • Le 7 avril 2005 à 11:44, par jean luc dechamps prof STS maintenance lycee maupassant fecamp En réponse à : > G3 - Hierarchisation et structuration des grafcets

    Bonjour, je suis enseignant en maintenance industrielle au niveau BTS, je souhaite réagir à cet article si celà peut vous apporter des informations ainsi que pour moi, mais je n’ai pas vu de fichier PDF ...
    En maintenance suite à un stage sureté de fonctionnement dans le nucléaire chez EDF j’utilise de plus en plus les schémas blocs et la notion de transmission d’énergies tant du point vue de la fonction principale que des des fonctions connexes, avez vous un avis à ce sujet ?

  • Le 26 avril 2005 à 10:58, par lodevo En réponse à : > G3 - Hierarchisation et structuration des grafcets

    bonjour
    pas de lien pour la suite et le fichier pdf !

  • Le 11 mai 2005 à 12:04, par EL JEBARI En réponse à : > G3 - Hierarchisation et structuration des grafcets

    bonjour pas de lien pour la suite et le fichier pdf !

  • Le 6 juillet 2005 à 11:15 En réponse à : > G3 - Hierarchisation et structuration des grafcets

    OU EST LE FICHIER .PDF ???

  • Le 23 août 2005 à 18:15, par Bernard Delmotte En réponse à : > G3 - Hierarchisation et structuration des grafcets

    Bonjour,

    Je pense qu’il y a une erreur dans les explications accompagnant l’exemple de "tâche" dans la section 2.C.1.

    Dans la dernière phrase il doit s’agir en fait de l’information "/appel de tache" qui évite que le cycle puisse recommencer.

    A noter que cette information n’est pas vraiment utile, puisque l’information "fin de tache" prise en compte dans la réceptivité de la transition de sortie de l’étape 22 aura pour conséquence que cette étape aura été désactivée - et donc que l’information "appel de tache" aura disparu - lorsque l’étape 30 de cette tâche sera réactivée, ce qui assure qu’il n’y aura pas de reprise du cycle défini par cette tâche.

    Il y a une erreur analogue à celle mentionnée ci-dessus dans les commentaires accompagnant l’exemple donné au 2.C.1.

    On peut faire la même remarque à propos de l’inutilité de la condition /appel de tache dans la réceptivité de la transition en sortie de l’étape 39 : une condition "toujours vrai" peut faire l’affaire.

    Si l’on veut on peut cependant également remplacer la condition "X22 + X24" figurant dans la transition de sortie de l’étape initiale de la tâche par des fronts montants sur l’activité des étapes 22 et 24.
    Ce qui se note Act(22) + Act(24) selon la norme.

    Cordialement.

  • Le 23 août 2005 à 18:27, par Bernard Delmotte En réponse à : > G3 - Hierarchisation et structuration des grafcets

    Bonjour,

    A propos de la notion de "macro-étape" présentée à la section C, on peut remarquer qu’au niveau de l’exécution du Grafcet, tout se passe comme si l’expansion était substituée à la macro-étape qu’elle détaille.

    Plus qu’un outil de conception, cette notion est une facilité de représentation à rapprocher des "renvois" qui permettent de dessiner un Grafcet complexe sur plusieurs pages.

    Cordialement.

  • Le 24 août 2005 à 10:21, par Bernard Delmotte En réponse à : > G3 - Hierarchisation et structuration des grafcets

    Ma remarque à propos de l’inutilité de la vérification de la disparition de l’information "appel de tache" dans la réceptivité de la transition de sortie de l’étape 39 de la tâche n’est peut-être pas vraiment pertinente (!)

    En effet, d’après les nouveautés de la norme, une action continue associée à une étape fugace ne doit pas être prise en compte : il faut alors bien s’assurer que l’activation de la dernière étape de la tâche est "contrôlée", par la prise en compte de la fin de tâche par le Grafcet appelant - et donc la disparition de l’information "appel de tache".

    Cependant - et "bizarrement" - une activité fugace de l’étape 39 semble suffisante pour que la condition "X39" puisse être perçue par le Grafcet appelant.

    Il semble que la norme ne distingue pas, parmi les actions continues, celles qui correspondent à des "ordres" à destination de la partie opérative - pour lesquels on comprend qu’une "activation fugace" ne doit pas être prise en compte, et les "actions internes" utilisées à des fins de synchronisation entre Grafcets, dont on ne voit pas pourquoi elles obéiraient à des règles différentes de celles régissant les informations de type "Xi" correspondant à l’activité - éventuellement "fugace" - des étapes.

    A propos des "ordres" à destination de la PO, on peut également remarquer qu’en pratique il est recommandé que ceux-ci ne soient pas positionnés directement dans les étapes du Grafcet, mais dans un "postérieur", de nature combinatoire, permettant une "unicité d’expression" ainsi que la prise en compte de conditions générales, du type sécurité ou mode de marche.