Remerciez-le!

Remerciez @Admin pour avoir partagé cet document gratuitement, de la manière la plus simple, en partageant sur les réseaux sociaux.

1 POUR UN BON USAGE DU GRAFCET 1. HISTORIQUE-METHODOLOGIE 1.1. HISTORIQUE Les a

1 POUR UN BON USAGE DU GRAFCET 1. HISTORIQUE-METHODOLOGIE 1.1. HISTORIQUE Les années 70 connaissent une explosion des besoins industriels dans le domaine de l’Automatique. La flexibilité et l’évolutivité (concepts devenus courants depuis) des Systèmes Automatisés de Production (SAP) sont déjà des priorités dans tous les domaines de la production. Les armoires électriques câblées, les méthodes dépassées et inapplicables en milieu industriel (comme les méthodes d’Huffman), les solutions empiriques utilisées sur le terrain pénalisent fortement la rentabilité des sites de production. Au même moment, un être étrange et mystérieux fait son apparition sur le marché (même si son existence est plus ancienne) : le microprocesseur. Il rend possible la réalisation d’Automatismes programmés (certains SNCC sont nés dans les années 60 avec des fortunes ou infortunes diverses) et ouvre des perspectives immenses. Forts de leurs expériences malheureuses dans les automatismes câblés, les industriels souhaitent mettre au point et utiliser une méthode « universelle et conviviale » de SPECIFICATION des SAP. En 1975, une commission présidée par Michel Blanchard (composée de chercheurs et d’industriels) est créée au sein de l’AFCET, En 1977, un premier texte scientifique est rendu public ; il parle du « GRAPHE de l’AFCET » qui sera communément appelé « GRAFCET ». Cet outil graphique doit permettre de faciliter l’écriture et la compréhension des cahiers des charges fonctionnels des SAP. Il s’agit donc dès 1977, et cela a été confirmé à chaque congrès scientifique ou réunion de cette commission de l’AFCET qui va devenir le « Groupe GRAFCET », d’un outil de SPECIFICATION. Dès 1978, alors que l’outil GRAFCET n’est qu’un embryon (plein d’avenir, certes mais un embryon tout de même), l’inspection générale STI décide d’inscrire le GRAFCET dans les programmes d’enseignement des classes de Lycées Techniques et de BTS (MAI notamment). Le corps enseignant ne connaît évidemment pas le GRAFCET, et une vaste campagne de formation est lancée dans les Etablissements scolaires ; cette campagne est relayée, accompagnée, voire précédée par la société Télémécanique, très impliquée dans le « groupe GRAFCET » et qui a développé des API programmables en langage « GRAFCET ». Cet abus de langage, argument essentiellement commercial a eu des conséquences très importantes et durables (puisqu’on peut en constater les effets aujourd’hui encore). De nombreux collègues ont appris le « GRAFCET » à travers les logiciels de programmation Télémécanique, c’est à dire à travers ce qui n’était pas, ne pouvait pas être du GRAFCET. Ainsi sont-ils nombreux (et comment leur jeter la pierre ?) à confondre SPECIFICATION et REALISATION ; ne trouve-t-on pas dans le dernier référentiel du BTS CIRA des scories de cette période lorsque l’on lit « Implanter un grafcet dans un API ne possédant pas le langage grafcet » ? Cette phrase prouve la confusion qui règne dans les esprits à ce sujet et la nécessité urgente d’une sérieuse mise au point. En 1982, grâce au travail acharné de certains membres de l’ADEPA (dont Paul BRARD de la société Télémécanique), le GRAFCET est normalisé en France, c’est la parution de la norme NF C03-190. En 1988, le GRAFCET est normalisé par la CEI/IEC 848 Le groupe GRAFCET se réunit régulièrement et continue à approfondir le GRAFCET, il publie en 1993 un document UTE C03-191 dans lequel apparaissent notamment le forçage, la macro-étape, les transitions et étapes sources ou puits…On y trouve également les notions d’actions mémorisées S (Set pour mise à1) et R (Reset pour mise à 0). Ce document n’est pas une norme, simplement un fascicule de documentation. En 1993, la norme IEC 1131-3 permet de valider cinq langages de programmation d’API dont le SFC (inspiré du GRAFCET) que certains constructeurs appellent encore abusivement grafcet. Notons que dans sa nouvelle gamme de logiciels « Afinity », la société SCHNEIDER rentre dans le rang et donne le nom « SFC » à son langage de programmation graphique rejoignant ainsi le groupe EMERSON, le groupe ROCKWELL et bien d’autres.. Une grande majorité d’entreprises, après l’avoir boudé ou ignoré pendant quelques années, se tournant actuellement vers cet outil très performant qu’est le langage « SFC » inspiré du GRAFCET, constituant un prolongement logique et cohérent d’un cahier des charges rédigé à l’aide du GRAFCET. L’AFCET disparaît et le groupe GRAFCET intègre le club EEA ; le groupe GRAFCET devient groupe COSED (Commande des Systèmes à Evénements Discrets). 2 En 2002, la norme IEC 60848 est très largement modifiée, sa traduction française est publiée en septembre de la même année sous la référence NF EN 60848. 1.2. METHODOLOGIE 1.2.1. LE SYSTEME AUTOMATISE DE PRODUCTION (SAP) Il semble inconcevable de rédiger un cahier des charges, encore moins un programme API si l’on n’a pas conscience du fonctionnement et de la structure d’un SAP : Figure 1 : SAP Un système automatisé de production n’existe que pour la VALEUR AJOUTEE apportée à la matière d’œuvre. Il est essentiellement constitué de trois parties : • Le procédé qui permet l’action sur la matière d’œuvre (on y trouve tous les actionneurs comme les moteurs, et les effecteurs comme les pompes..) • La chaîne d’énergie qui permet d’alimenter les actionneurs • La chaîne d’information qui permet de s’informer de l’état du système, de lui envoyer les ordres nécessaires et de communiquer avec d’autres systèmes. Le travail de l’automaticien, dans la phase de conception se déroule en deux étapes distinctes : • SPECIFIER le comportement de la chaîne d’information (souvent appelée partie commande) afin de répondre au cahier des charges imposé par le fonctionnement du procédé. • REALISER une partie commande répondant au cahier des charges rédigé précédemment Le résultat obtenu sera d’autant plus performant que la méthode de travail sera rigoureuse ; l’une des règles de conduite les plus importantes, et pourtant trop souvent négligée, consiste à rédiger le cahier des charges sans imposer à priori une solution technique. 1.2.2. LA SPECIFICATION ET LES POINTS DE VUE la spécification du comportement du SAP peut prendre des formes différentes selon les points de vue que se donne le spécificateur. On en distingue généralement trois, deux d’entre eux étant particulièrement utiles. • Le point de vue système, qui permet une SPECIFICATION FONCTIONNELLE du SAP. A cette étape de la conception, aucune solution technologique n’est connue du spécificateur qui va créer un GRAFCET de SPECIFICATION FONCTIONNELLE ou d’un POINT DE VUE SYSTEME. 3 Figure 2 : Spécification fonctionnelle • Le point de vue partie commande, qui permet une SPECIFICATION OPERATIONNELLE du SAP. A cette étape de la conception, les choix technologiques de la chaîne d’énergie sont faits, il reste à définir la chaîne d’information ou partie commande : Figure 3 : spécification opérationnelle Il s’agit donc ici de dire quels ordres la partie commande doit envoyer au système en fonction des informations qu’elle est capable de traiter ; même si à ce moment là, l’automaticien sait que sa partie commande sera réalisée à partir d’un modèle particulier d’API, avec un logiciel particulier , sa spécification doit rester totalement indépendante des solutions qu’il peut entrevoir. Il est en train de rédiger un cahier des charges pour le programmeur, le câbleur, l’informaticien qui va éventuellement installer un réseau de terrain. Il doit être précis et rigoureux mais bien se garder d’imposer une solution à celui qui va réaliser, en un mot : LA SPECIFICATION OPERATIONNELLE CONSISTE A DIRE CE QUE LA PARTIE COMMANDE DOIT FAIRE MAIS PAS COMMENT ELLE DOIT LE FAIRE . 2. LE GRAFCET ET LA NORME NF EN 60848 Le GRAFCET est devenu un outil indispensable à la spécification des SAP, aussi bien dans la phase de spécification fonctionnelle que dans la phase de spécification opérationnelle. La qualité de la spécification dépend 4 fortement de sa lisibilité, il est donc essentiel de respecter des règles comprises et admises par tous : celles qui sont définies par une norme. 2.1. LE CONTEXTE D’UTILISATION Décembre 1988, 11 ans après sa création, le Grafcet fait l’objet d’une norme internationale éditée par la Commission Électrotechnique Internationale : la CEI/IEC 60848 qui définit « l’établissement des diagrammes fonctionnels pour systèmes de commande ». La norme CEI 60848 annule et remplace la norme NF C03-190, elle s’applique à la description du fonctionnement des systèmes de commande définis par la norme CEI 50. La norme CEI 60848 a fait l’objet d’une révision en 2002 qui définit le « langage de spécification GRAFCET pour diagrammes fonctionnels en séquence ». Un système de commande est un système qui établit une loi de causalité entre une entrée et une sortie ; « l’entrée commande la sortie ». Cette définition, surtout utilisée dans le domaine des systèmes continus, peut s’appliquer à tout système automatisé de production ; elle présente un avantage considérable sur le contenu de la norme NF C03-190. La frontière et les entrées/sorties de chaque système ou sous-système sont déterminées de manière précise. • La norme CEI/IEC 60848 conserve le graphisme et les règles d’évolutions définis par la C03-190. • Elle définit une représentation détaillée des actions associées au grafcet. • Elle redéfinit les conditions de transition (ou réceptivités) et supprime la notion de « temporisation » définie par la uploads/Industriel/ usage-du-grafcet-1-3.pdf