[FR] Guide de codage des programmes automates

Guide de codage des programmes automatesItris Automation Square20 janvier 2012 - Version 1.6.7http://www.automationsquare.com

Guide de codage des programmes automates2/20 20 janvier 2012 - Version 1.6.7

Contents1 Objectif de ce document 52 Structure de ce document 6 2.1 Classiﬁcation des r` gles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e 6 2.2 Pr´ sentation de chaque r` gle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e 63 R` gles de codage e 7 3.1 Nommage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ` 3.1.1 R` gles communes a tous les automates . . . . . . e . . . . . . . . . . . . . . . . . . . . . 7 3.2 Commentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 ` 3.2.1 R` gles communes a tous les automates . . . . . . e . . . . . . . . . . . . . . . . . . . . . 9 3.3 Ecriture du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ` 3.3.1 R` gles communes a tous les automates . . . . . . e . . . . . . . . . . . . . . . . . . . . . 10 e ` 3.3.2 R` gles sp´ ciﬁques a Schneider Electric Unity . . . e . . . . . . . . . . . . . . . . . . . . . 11 3.4 Structuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 ` 3.4.1 R` gles communes a tous les automates . . . . . . e . . . . . . . . . . . . . . . . . . . . . 11 3.5 Informations utiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 ` 3.5.1 Informations utiles communes a tous les automates . . . . . . . . . . . . . . . . . . . . . 13 3.6 Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.6.1 Options Unity des projets automates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Annexes 18 4.1 R´ sum´ des r` gles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . e e e 18 4.2 Historique du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3/20

Guide de codage des programmes automates4/20 20 janvier 2012 - Version 1.6.7

Chapter 1Objectif de ce documentCe document propose un style de codage pour la programmation des automates industriels, afin d’am´ liorer la elisibilit´ , la maintenabilit´ et la coh´ rence des programmes. Il d´ crit des r` gles simples permettant d’obtenir, d` s e e e e e eleur premi` re application, des r´ sultats probants sur la qualit´ du code automate. e e e e e e ` Toutes les r` gles pr´ sentes dans ce document sont v´ rifiables automatiquement a l’aide de l’outil PLC Checkeret ce pour les automates programm´ s avec les ateliers PL7-PRO et Unity PRO de Schneider Electric, STEP7 de eSiemens et RSLogix 5000 de Rockwell Automation. é e e` Ce document a et´ r´ dig´ a partir d’une analyse critique de nombreux r´ f´ rentiels d´ j` utilis´ s par les clients ee ea ed’Itris Automation Square dans des domaines d’activit´ vari´ s et poss´ dant des gammes d’automates diversifi´ es. e e e e ´ Íl s’inspire egalement de l’exp´ rience des equipes d’automaticiens d’Itris Automation Square. e 5/20

Chapter 2Structure de ce document2.1 Classification des r` gles eLes r` gles contenues dans ce document sont class´ es dans plusieurs cat´ gories : Nommage, Commentaire, Ecri- e e e ´ture, Structuration. Vient ensuite une partie appel´ e ”Informations utiles” qui propose egalement des pistes de e e `r´ flexion. Elles ne constituent pas a proprement parler des r` gles de codage, mais peuvent permettre l’am´ lioration e ede la qualit´ des programmes. Pour, finir des r` gles de v´ rifications des options du projet sont propos´ es pour e e e ecertains ateliers. ´ Chaque cat´ gorie est eventuellement subdivis´ e en deux parties : les r` gles qui peuvent s’appliquer ind´ pendamment e e e ede l’automate pour lequel le programme est d´ velopp´ et celles qui ne sont pertinentes que pour un automate par- e eticulier ou qui n´ cessitent d’ˆ tre d´ clin´ es afin d’ˆ tre effectivement applicables. e e e e e2.2 Pr´ sentation de chaque r` gle e eLes r` gles sont num´ rot´ es en accord avec leur impl´ mentation dans PLC Checker, l’outil de v´ rification automa- e e e e etique des r` gles de codage propos´ par Itris Automation Square. Pour chaque r` gle, on retrouve une structure e e eidentique compos´ e d’un titre de section qui r´ sume la r` gle, de la r` gle proprement dite et de commentaires e e e ejustifiant notamment la pr´ sence de la r` gle dans le document. Lorsque cela semblait n´ cessaire pour faciliter la e e e e e é e ecompr´ hension de la r` gle, un exemple de code a et´ r´ dig´ . ` Il est a noter que les explications compl´ mentaires et les exemples n’ont pas pour but de constituer une forma- e `tion exhaustive a l’aspect de la programmation auquel il est fait r´ f´ rence dans la r` gle. ee e 6/20

Chapter 3R` gles de codage e3.1 Nommage éLes el´ ments manipul´ s dans les ateliers automates portent des mn´ moniques. Ce sont par exemple, des variables, e edes routines (sections, sous-routines, FC. . . ), des blocs fonction (FB). L’objectif de cette section est de s’assurerque les mn´ moniques suivent des r` gles assurant la lisibilit´ , la maintenabilit´ et permettant une plus grande e e e e e e e e ép´ rennit´ du code. D’une mani` re g´ n´ rale, les el´ ments propres aux librairies des ateliers constructeurs sont eexclus des contrˆ les de nommage. Bien entendu, lorsque les ateliers le permettent, nous d´ conseillons de modifier o e éles noms des el´ ments propres aux librairies.3.1.1 ` R` gles communes a tous les automates e é ˆN.1 - Tous les el´ ments constituant le programme doivent etre nomm´ s e é ˆTous les el´ ments constituant le programme doivent etre nomm´ s (Programme, Modules, Variables, DFB, FB, OB, eSR). é Commentaire : Si tous les el´ ments du programme sont nomm´ s de facon significative, il est plus facile de lire e ¸et de comprendre le programme ; la maintenance en devient facilit´ e. Par ailleurs, ne pas utiliser de mn´ monique e e ` `revient a lier le code a une impl´ mentation mat´ rielle donn´ e, ce qui induit une perte d’´ volutivit´ . e e e e e éN.2 - Les noms des el´ ments du programme doivent avoir une taille minimum et maximum éLes noms des el´ ments du programme doivent comporter au moins 4 caract` res et au plus 30 caract` res. e e Commentaire : Un nombre minimum de caract` res assure un nommage plus significatif. Un maximum de ecaract` res permet : e e ` ` • sous Unity, PL7pro et Rockwell, d’´ viter les mn´ moniques tronqu´ s a l’affichage, a l’export, . . . e e • sous Step7, d’am´ liorer la lisibilit´ e e é `N.3 - Les mn´ moniques des el´ ments ne font pas r´ f´ rence a leur adresse physique e ee é `Les mn´ moniques des el´ ments ne doivent pas contenir une r´ f´ rence a leur adresse physique (par exemple, e ee”MW2”, ”FB4”. . . ). ` ˆ ` ´ Commentaire : La r´ f´ rence a l’adresse physique est susceptible de ne plus etre pertinente suite a une evolution ee `du code et donc de nuire a la lisibilit´ du code voire d’induire une confusion dangereuse. Il est notable que, du efait de l’´ volution des ateliers logiciels, la notion de couplage avec l’adresse physique n’est pas n´ cessairement e e e ee `pertinente pour certains automates pour lesquels les variables ne sont pas localis´ es. Une telle r´ f´ rence a l’adresse ˆphysique peut etre involontaire, elle n’en demeure pas moins interdite. 7/20

Guide de codage des programmes automates Exemple : Adresse Mn´ moniques e Commentaire Physique %MW23 Cde 23 ` Ne jamais lier le nommage de la variable a son adresse physiqueN.4 - Les mn´ moniques de mise au point ne doivent pas faire partie du programme final eLa mise au point ne doit pas faire partie du programme. Notamment, certains noms d’´ l´ ments (test, toto, titi, tata, eetutu, a effacer, todo,. . . ) sont interdits et les commentaires ne doivent pas contenir d’expressions laissant penserque le programme est encore en cours d’´ criture (a faire plus tard, a effacer, todo ) e é e ` ` Commentaire : Laisser des el´ ments li´ s a la mise au point dans le programme en production nuit a sa lisi-bilit´ et peut avoir pour cons´ quences un comportement diff´ rent de celui attendu. La liste d’´ l´ ments interdits est e e e eeévolutive.N.5 - Les caract` res sp´ ciaux sont interdits dans les noms des mn´ moniques e e eLes caract` res sp´ ciaux sont interdits dans les noms des mn´ moniques. Seuls les caract` res alphanum´ riques et le e e e e e”soulign´ ” (underscore ) sont autoris´ s. En particulier, l’espace et les accents sont interdits. e e e e ` Commentaire : Utiliser des caract` res sp´ ciaux dans les noms des mn´ moniques nuit a la portabilit´ du e ecode vers des versions post´ rieures potentielles des ateliers de d´ veloppement et/ou vers d’autres plateformes. Ils e e `nuisent aussi a la lisibilit´ dans un contexte international. Enfin, restreindre le jeu de caract` res autoris´ s permet e e ede s’assurer d’une meilleure distinction entre les noms des variables. Exemple :d´part := true; e# .... beaucoup plus loin dans le codedepart := false; e e e ` # Le fait d’autoriser le caract`re spćial ’´’ conduit a une confusionpossible entre les mn´moniques. eN.6 - Les mots clefs des langages de programmation ne doivent pas servir de mn´ moniques eLes mots clefs des langages de programmation (par exemple ”if”, ”then”, ”else”, ”while”, ”for”, ”repeat”, ”until”, ˆ”begin”, ”end”, ”do”, ”function”, ”procedure”, ”exit”, ”wait”, ”start”, ”stop”, ”return”,. . . ) ne peuvent pas etre e ´ l´ ments du programme. En revanche, les mn´ moniques peuvent contenir un mot cl´ duutilis´ s comme noms des e e e elangage. ` e ` Commentaire : Utiliser des mots clefs des langages comme noms des mn´ moniques nuit a la lisibilit´ , a la e e e `portabilit´ du programme et peut poser des probl` mes lors de la compilation du code. Il est a noter qu’un certainnombre d’ateliers interdisent d´ j` un tel nommage. ea Exemple :start := true; # Mauvais mn´monique, start est un mot-cl´ du langage e estart_moteur := true; # Correct mn´monique e8/20 20 janvier 2012 - Version 1.6.7

Guide de codage des programmes automates3.2 Commentaires a e Àu del` du nommage, il est important de suivre des r` gles quant a la bonne utilisation des commentaires. En effet,plus un commentaire est explicite et d´ taill´ , plus il facilitera la compr´ hension du code. D’une mani` re g´ n´ rale, e e e e e e éles el´ ments propres aux librairies des ateliers constructeurs sont exclus des contrˆ les de commentaires. o3.2.1 ` R` gles communes a tous les automates e é ˆC.1 - Tous les el´ ments constituant le programme doivent etre comment´ s e é ˆTous les el´ ments constituant le programme doivent etre comment´ s (Programme, Modules, Variables, DFB, FB, eOB). é Commentaire : Si tous les el´ ments du programme sont comment´ s de facon significative, le programme est e ¸ ` ` `plus facile a lire donc plus facile a comprendre et donc plus facile a maintenir.C.2 - Les commentaires doivent comporter un minimum de caract` res eLes commentaires doivent comporter un minimum de caract` res (7 pour les variables, 15 pour les codes) pour eéviter les commentaires non significatifs. Commentaire : Un nombre minimum de caract` res assure que les commentaires sont plus significatifs. e e ˆC.3 - Chaque r´ seau doit etre comment´ e e e ˆLorsqu’ils sont utilis´ s, les r´ seaux (aussi appel´ s rungs) doivent etre comment´ s. Cette r` gle est sp´ cifique a e e e e `certains langages de la norme IEC61131. Par ailleurs, la notion de rung n’est pas toujours pr´ sente dans les ateliers ede d´ veloppement des constructeurs d’automates. e Commentaire : Au del` du taux de commentaire global, il est important d’assurer une bonne r´ partition des a ecommentaires. Une telle r` gle est aussi un guide qui assure le respect d’une certaine coh´ rence dans le d´ coupage e e edu code.C.4 - Les commentaires ne contiennent pas le marqueur de d´ but de commentaire eLes commentaires ne doivent pas contenir le marqueur de d´ but de commentaire (par exemple, ”/ *”, ”( *”). e Commentaire : La pr´ sence d’un marqueur de d´ but de commentaire dans un commentaire est souvent le e e o `symptˆ me d’un oubli de marqueur de fin de commentaire, pouvant conduire a la non-ex´ cution d’une partie de ecode. Exemple:/* Un commentaire quelconque dont le marqueur de fin a ´t´ oubli´ e e eSection_critique_qu_il_faut_a_tout_prix_executer_mais_qui_se_retrouve_commentee();/* <-Ce marqueur de d´but de commentaire est en commentaire car le marqueur de fin du commentaire eprć´dent a ´t´ oubli´ */ e e e e e20 janvier 2012 - Version 1.6.7 9/20

Guide de codage des programmes automates3.3 Ecriture du code3.3.1 ` R` gles communes a tous les automates e ˆ É.1 - Toutes les variables doivent etre ecrites avant d’ˆ tre lues e e e ˆ Á l’exception des entr´ es et des variables syst` me, toutes les variables doivent etre ecrites avant d’ˆ tre lues durant eun cycle automate. e ´ Commentaire : Une variable lue avant d’ˆ tre ecrite a pour cons´ quence de rendre le code non-r´ actif : un e e `code efficace doit respecter un cycle lecture des entr´ es → traitement → mise a jour des sorties. Par ailleurs, il e ´ éfaut s’assurer que les variables qui ne sont jamais ecrites par le code ont bien et´ initialis´ es ou proviennent de el’ext´ rieur du programme. e Dans certain cas, il est justifi´ de ne pas respecter cette r` gle : e e é • pour les variables qui ont et´ initialis´ es dans la base de donn´ es, e e • pour les variables en provenance des communications, • pour les variables d’´ tat qui m´ morisent la valeur d’un cycle ant´ rieur. e e eExemple:if alarmeUrgente then traitementAlarme;end if;# ...alarmeUrgente := presenceDefaut AND ...;# Dans ce cas l`, l’appel de la routine de traitement d’alarme se fait lors du cycle suivant a# ce qui augmente le temps de r´ponse moyen. e# Ce retard est de l’ordre de grandeur d’un tour de cycle. e Ê.2 - Les param` tres des blocs fonctionnels utilisateur doivent etre utilis´ s correctement eCette r` gle se subdivise en sous-r` gles : e e ˆ ˆ ´ • E.2.a et b - Les entr´ es des blocs fonctionnels utilisateur doivent etre lues et ne pas etre ecrites. e ˆ ´ • E.2.c et d - Les entr´ es/sorties des blocs fonctionnels utilisateur doivent etre lues et ecrites. e ˆ ´ ´ • E.2.e - Les sorties des blocs fonctionnels utilisateur doivent etre ecrites avant leur eventuelle lecture.Commentaire : Des param` tres non-utilis´ s de facon correcte sont des symptˆ mes d’un code non-finalis´ ou d’un e e ¸ o e é `code qui contient encore des el´ ments inutiles a son bon fonctionnement. Sur certains automates, la mauvaiseutilisation des param` tres peut g´ n´ rer des effets de bords potentiellement dangereux tels qu’une corruption de e e edonn´ es. La v´ rification de l’utilisation des variables priv´ es des blocs fonctionnels utilisateur se fait par la r` gle e e e eS7.10/20 20 janvier 2012 - Version 1.6.7

Guide de codage des programmes automates3.3.2 ` R` gles sp´ cifiques a Schneider Electric Unity e e `É.U.1 - L’utilisation de fonctions des librairies obsol` tes d’Unity est a eviter e e ˆLes fonctions des librairies obsol` tes ne doivent pas etre utilis´ s dans le cadre de nouveaux projets. e Commentaire : Sous l’atelier Unity, certaines librairies sont obsol` tes et ont pour unique vocation d’assurer ela compatibilit´ ascendante avec des versions ant´ rieures des automates Schneider. L’utilisation des fonctions de e e ` ćes librairies est a eviter pour des probl` mes de portabilit´ futur. De plus, certaines d’entre elles peuvent rendre e ele code non-d´ terministe (ex: les d´ calages sur les entiers sign´ s: shl int, shlz int, shr int, shrz int, rol int, ror int, e e e. . . ).3.4 Structuration3.4.1 ` R` gles communes a tous les automates eS.1 - Les sauts en arri` re sont interdits eLes sauts en arri` re sont interdits. e Commentaire : L’utilisation d’un saut en arri` re fait courir le risque de d´ clencher une boucle infinie, ce qui e e ` e e e e `peut conduire a un arrˆ t de l’automate. Par ailleurs, de mani` re g´ n´ rale, l’utilisation de saut nuit a une bonne e `compr´ hension du code et donc a sa facilit´ de maintenance. e Exemple: Figure 3.1: Exemple de saut en arri` re provoquant une boucle infinie e ˆ ´S.2 - Une variable doit etre ecrite au sein d’une seule routine ˆ Úne variable doit etre ecrite au sein d’une seule routine. Commentaire : Le respect d’une structuration simple et claire facilite la compr´ hension du code et donc sa e ´maintenance. Par ailleurs, des elaborations multiples d’une variable peuvent avoir pour cons´ quence un comporte- ement du code erratique. ˆ ´S.3 - Une variable doit etre ecrite au sein d’une seule tˆ che a ˆ Úne variable doit etre ecrite au sein d’une seule tˆ che. a ´ ` Commentaire : Elaborer une variable depuis plusieurs tˆ ches conduit a un comportement non-d´ terministe a e `donc a un conflit d’acc` s potentiel. e20 janvier 2012 - Version 1.6.7 11/20

Guide de codage des programmes automates ˆ ´S.4 - Une sortie physique ne doit etre ecrite qu’une seule fois par cycle automate ˆ Úne sortie physique ne doit etre ecrite qu’une seule fois par tour de cycle automate. ` Commentaire : L’´ criture multiple d’une sortie peut conduire a des probl` mes de s´ curit´ de fonctionnement. e e e e ´ `Par ailleurs, un code dans lequel les sorties sont ecrites plusieurs fois est moins facile a comprendre et donc a` e ee ´maintenir. A noter que l’´ criture dans une boucle est consid´ r´ e comme une ecriture multiple et constitue doncune violation de cette r` gle. e Exemple:if condition_tres_complique then ma_sortie_critique := TRUE;end if;#.... beaucoup plus loin dans le codeif une_autre_condition tres complique then ma_sortie_critique := FALSE;end if;# Dans le cas o` cette sortie n’est pas commandé alors qu’elle le devrait, il est tr`s u e e# difficile d’identifier quelle affectation est exćuté. e e e e ˆS.5 - Les variables ne doivent pas en g´ n´ ral etre localis´ es e ˆLa localisation des variables doit etre strictement r´ serv´ e aux variables dont l’´ laboration ou la consommation e e esont ext´ rieures au programme : variables de communication, variables d’entr´ es-sorties, variables de configura- e e ˆtion de cartes sp´ ciales, variables de tests. En revanche toutes les variables internes du programme doivent etre enon localis´ es. e e e e ` Commentaire : Localiser une variable r´ duit les possibilit´ s d’´ volution a cause d’une organisation m´ moire e ´plus rigide. Cela r´ duit egalement la portabilit´ , puisque les possibilit´ s d’organisation m´ moire varient d’un au- e e e e `tomate a l’autre. Cela empˆ che la r´ -utilisabilit´ du code. En effet, dans le cadre d’une autre application, la zone e e e e ˆ e e `m´ moire choisie peut etre r´ serv´ e pour d’autres usages. Enfin, cela peut conduire a des erreurs d’organisation e e `m´ moire dans lesquelles plusieurs variables se trouvent localis´ es a la mˆ me case m´ moire. e eS.6 - Les instances de FB/DFB sont appel´ es une et une seule fois e ˆChaque instance de bloc fonctionnel doit etre appel´ une fois et une seule par tour de cycle automate. e Commentaire : Une instance de bloc fonctionnel poss` de ses propres variables qui permettent la sauvegarde e e e ´de l’´ tat de l’instance entre deux tours de cycle. Chaque ex´ cution de l’instance doit faire evoluer ces variables e `pour rendre compte du changement d’´ tat a ce tour de cycle. Une ex´ cution multiple pour la mˆ me instance de ce e ecode semble faire avancer les cycles plus vite que la r´ alit´ pour cette instance. En fonction du programme, cela e e ` `peut conduire a des erreurs difficiles a diagnostiquer. e ˆ e ` Enfin, une mˆ me instance peut etre appel´ e deux fois suite a un copier/coller pas finit, dans lequel les param` tres e éont et´ modifi´ s mais pas le nom de l’instance. eS.7 - Les variables d´ finies (hors r´ serves) sont utilis´ es e e e ˆ ´ ` é eLes variables d´ clar´ es doivent etre lues ou ecrites a l’exception des variables qui ont et´ d´ finies comme variables e ede r´ serve. e Commentaire : Les variables d´ clar´ es et non utilis´ es sont souvent le signe d’une base de donn´ es obsol` te e e e e e òu pas a jour qui rend le travail de la maintenance plus compliqu´ . e12/20 20 janvier 2012 - Version 1.6.7

Guide de codage des programmes automatesS.8 - Les variables ne se chevauchent pas u ˆDans le cas o` des variables doivent etre localis´ es, deux variables ne doivent pas utiliser la mˆ me localisation. e e ´ ` Commentaire : Les variables localis´ es qui se chevauchent sont equivalentes a un transfert implicite de valeur e èntre elles. Cela peut nuire a la lisibilit´ du code. C’est parfois un signe d’une mauvaise organisation m´ moire e e `qui peut rester invisible lors des tests et conduire a un comportement non d´ terministe du programme lors de el’exploitation.S.9 - Mesure de la complexit´ eLe code complexe cache des erreurs. Commentaire : Certaines parties de programmes sont plus complexes que d’autres. C’est particuli` rement evrai lorsque le flot d’ex´ cution s´ quentiel du programme est interrompu. Cette r` gle recherche certaines causes e e ed’interruption du flot que sont les boucles, les sauts arri` re et les niveaux d’imbrications d’instructions complexes e ´ etrop elev´ s.S.10 - Limitations dues aux SCADACertains logiciels de supervision ne supportent pas les tableaux de structure. Cette r` gle les identifie. e Commentaire : Certains logiciels SCADA ne supportent pas les tableaux de structures. Le d´ veloppeur doit e e e ˆ ´donc v´ rifier que les tableaux de structure ne sont pas utilis´ s pour etre echang´ s avec la supervision. e3.5 Informations utiles3.5.1 ` Informations utiles communes a tous les automatesI.1 - Taux de commentairesIl est recommand´ que le code contienne un pourcentage minimum de commentaires. e Commentaire : A titre indicatif, Itris Automation Square recommande un taux de 30% (nombre d’instructionscomment´ es/nombre total d’instructions). Un tel taux minimum de commentaires assure que le d´ veloppement a e eé e e èt´ r´ alis´ en ayant a l’esprit un souci de maintenabilit´ et de bonne compr´ hension par des intervenants post´ rieurs. e e eI.2 - Pr´ sence de code dans les commentaires e e e Íl est important de v´ rifier la pr´ sence eventuelle de code sous forme de commentaires. ` Commentaire : La pr´ sence de code dans des commentaires est souvent due a la mise en commentaire d’une epartie du code dans le cadre des phases de test et de debug. Le code de production ne doit pas contenir de tracesdes phases de mise au point.I.3 - Pr´ sence de code mort e ´ Íl faut evaluer la pr´ sence eventuelle de code mort dans le programme. e ` e e ˆ Commentaire : Le code mort nuit a la lisibilit´ et la maintenabilit´ du programme et peut etre le symptˆ me od’un probl` me fonctionnel. Attention, si PLC Checker d´ tecte les fonctions non-r´ f´ renc´ es et les parties de code e e ee eisol´ es derri` re un saut inconditionnel, aucune exhaustivit´ de d´ tection n’est cependant garantie (comme, par ex- e e e e e` eemple, pour le code mort li´ a l’´ valuation d’une expression).20 janvier 2012 - Version 1.6.7 13/20

Guide de codage des programmes automates éI.4 - Liste des el´ ments verrouill´ s e éLes el´ ments verrouill´ s ne sont pas analys´ s par PLC Checker, il convient donc de les identifier. e e Commentaire : Sur des applications o` la majeur partie du code est verrouill´ e, il est important de le savoir. u eI.5 - Nombre cyclomatique v(G) `Le nombre cyclomatique donne une information relative a la complexit´ d’une routine. Il est important que le enombre cyclomatique reste raisonnablement bas. Commentaire : Le nombre cyclomatique repr´ sente le nombre de chemins d’ex´ cution diff´ rents qui peuvent e e eˆ ´ eetre ex´ cut´ s dans une routine. Plus ce nombre est elev´ , plus il est difficile de valider le comportement correct de e ecette routine. Il est alors n´ cessaire de diviser celle-ci en d’autres sous-routines de nombre cyclomatique inf´ rieur e eau seuil.I.6 - Complexit´ essentielle ev(G) e e `La complexit´ essentielle donne une information relative a l’utilisation d’instructions non structur´ es. Il est impor- etant que la complexit´ essentielle reste raisonnablement bas. e Commentaire : La complexit´ essentielle repr´ sente le nombre d’instructions non structur´ e appartenant a e e e ` ´ eune routine. Plus ce nombre est elev´ , plus il est difficile de valider le comportement correct de cette routine. Laplupart du temps il est possible de remplacer des instructions non structur´ es par des instructions structur´ es. e eI.7 - Nombre de lignes de codeLe nombre de lignes de code d’une proc´ dure ou d’un bloc fonction est une m´ trique tr` s simple qu’il convient de e e egarder sous contrˆ le. o Commentaire : De tr` s grosses proc´ dures ou blocs fonctions ont de mauvaises propri´ t´ s de test, validation, e e eelisibilit´ et maintenance. eI.8 - Nombre d’´ tapes du Grafcet eIl s’agit du nombre d’´ tapes Grafcet pr´ sentes. e e Commentaire : Cette r` gle retourne le nombre d’´ tapes trouv´ dans un Grafcet de l’application. Ce nombre e e e ` epeut servir a d´ tecter des Grafcets plus complexes parmi tous les Grafcets d’une application.I.9 - Nombre de branches du GrafcetLe nombre est la somme du nombre de branches de chacune des divergences ET/OU trouv´ es dans un Grafcet edonn´ . e Commentaire : Cette r` gle calcule le nombre de branches d’un Grafcet. Ce nombre donne des informations e e e ´ `sur la complexit´ d’un Grafcet donn´ . Ce nombre est equivalent a la complexit´ cyclomatique (v(G)) calcul´ pour e eles langages de programmation imp´ ratifs. eI.10 - Ratio de code dupliqu´ sur l’application eCe nombre d´ tecte le pourcentage de code qui est dupliqu´ . e e Commentaire : R´ utiliser le code en le copiant/collant n’est pas une bonne pratique. La maintenance et e ˆ e `l’´ volution du programme deviennent plus difficiles car les modifications doivent etre appliqu´ es a plusieurs en- e ` ` edroits. De plus l’op´ ration manuelle consistant a copier/coller est souvent responsable d’erreurs difficiles a d´ tecter e: la phase de modification qui suit le copier/coller est parfois incompl` te. e14/20 20 janvier 2012 - Version 1.6.7

Guide de codage des programmes automates3.6 Options3.6.1 Options Unity des projets automatesO.U.1 - SFC : Le multi-jetons sur le Grafcet est interditSous l’atelier Unity, dans les options du projet, il faut d´ cocher la possibilit´ de faire tourner le Grafcet en mode e emulti-jetons. Commentaire : Le mode multi-jetons sous Unity n’a que pour vocation d’assurer la compatibilit´ ascendante e e âvec des versions ant´ rieures des automates Schneider. Il ne doit pas etre utilis´ dans le cadre de nouveaux projets ecar il peut rendre le code non-d´ terministe. e Exemple: Si le code Grafcet suivant est ex´ cut´ avec une condition A toujours vraie, apr` s plusieurs tours de e e e ćycles, toutes les etapes sont actives simultan´ ment. e Figure 3.2: Grafcet non d´ terministe en mode multi-jeton e Ó.U.2 - SFC : Non maintien des etapes pr´ c´ dentes actives pour SetSteps e e e ´Sous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ SetSteps : maintien des etapes pr´ c´ dentes e eactives ≫. Commentaire : Cette option est li´ e au mode multi-jetons - voir O.U.1. eO.U.3 - SFC : Pas de saut In/Out dans les divergences en ETSous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ Divergence en ET : autoriser saut In/Out e≫. Commentaire : Cette option est li´ e au mode multi-jetons - voir O.U.1. e20 janvier 2012 - Version 1.6.7 15/20

Guide de codage des programmes automates Ó.U.4 - SFC : Une seule evolution par divergence ´Sous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ Autoriser plusieurs evolutions par diver- egence ≫. Commentaire : Cette option est li´ e au mode multi-jetons - voir O.U.1. eO.U.5 - ST : Sauts et labels interditsSous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ Autoriser les sauts et les labels ≫. e e e e ` e ` Commentaire : De mani` re g´ n´ rale, l’utilisation de saut nuit a une bonne compr´ hension du code et donc asa facilit´ de maintenance. eO.U.6 - Pas de chiffre en d´ but d’identificateur eSous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ Chiffres en d´ but autoris´ s ≫. e e e e e e e e ` e ` Commentaire : De mani` re g´ n´ rale, l’utilisation de chiffres en d´ but de mn´ moniques nuit a la lisibilit´ et ala portabilit´ du programme. eO.U.7 - Jeu de caract` res standard pour les identificateurs eSous l’atelier Unity, dans les options du projet, il faut s´ lectionner le jeu de caract` res Standard (et pas Etendu ou e eUnicode) pour les identificateurs. e e e e ` e ` Commentaire : De mani` re g´ n´ rale, l’utilisation d’un jeu de caract` res non standard nuit a la lisibilit´ et a laportabilit´ du programme. e Exemple : Il peut, par exemple, etre difficile de faire la diff´ rence entre une variable ”d´ part ” et une autre ˆ e evariable ”depart ”O.U.8 - Les expressions ST sont interdites dans le FBD et le LDSous l’atelier Unity, dans les options du projet, il faut d´ cocher l’option ≪ Utilisation d’expressions ST ≫. e e e e ` Commentaire : De mani` re g´ n´ rale, l’utilisation d’expression ST dans les langages FBD et LD nuit a lalisibilit´ du programme. eO.U.9 - Les informations d’upload avec commentaires et tables d’animationSous l’atelier Unity, dans les options du projet, il faut : 1. cocher l’option ≪ Avec ≫ les informations d’upload, 2. cocher l’option ≪ Commentaires (variables et types) ≫ pour les informations d’upload, 3. cocher l’option ≪ Tables d’animation ≫ pour les informations d’uploadCommentaire : Dans la mesure o` la m´ moire automate le permet, le stockage des informations d’upload le plus u ecomplet possible permet de retrouver ces informations en cas de perte de la sauvegarde du programme, ce qui eàm´ liore la maintenabilit´ a long terme. e16/20 20 janvier 2012 - Version 1.6.7

Guide de codage des programmes automates e `O.U.10 - Les bobines en LD sont align´ es a droite e `Sous l’atelier Unity, dans les options du projet, il faut cocher l’option ≪ Bobines align´ es a droite ≫ pour l’´ diteur eLadder. Commentaire : L’alignement des bobines sur la droite de l’´ diteur permet une meilleur lisibilit´ du pro- e egramme.20 janvier 2012 - Version 1.6.7 17/20

Chapter 4Annexes4.1 R´ sum´ des r` gles e e eCette annexe r´ capitule toutes les r` gles et informations utiles mentionn´ es dans ce document. e e eR` gles de Nommage e é ˆ • N.1 - Non-sp´ cifique - Tous les el´ ments constituant le programme doivent etre nomm´ s e e é • N.2 - Non-sp´ cifique - Les noms des el´ ments du programme doivent avoir une taille minimum et maximum e e e é ee ` • N.3 - Non-sp´ cifique - Les mn´ moniques des el´ ments ne font pas r´ f´ rence a leur adresse physique • N.4 - Non-sp´ cifique - Les mn´ moniques de mise au point ne doivent pas faire partie du programme final e e • N.5 - Non-sp´ cifique - Les caract` res sp´ ciaux sont interdits dans les noms des mn´ moniques e e e e • N.6 - Non-sp´ cifique - Les mots clefs des langages de programmation ne doivent pas servir de mn´ moniques e eR` gles sur les Commentaires e é ˆ • C.1 - Non-sp´ cifique - Tous les el´ ments constituant le programme doivent etre comment´ s e e • C.2 - Non-sp´ cifique - Les commentaires doivent comporter un minimum de caract` res e e e e ˆ • C.3 - Non-sp´ cifique - Chaque r´ seau doit etre comment´ e • C.4 - Non-sp´ cifique - Les commentaires ne contiennent pas le marqueur de d´ but de commentaire e eR` gles d’Ecriture e e ˆ ´ • E.1 - Non-sp´ cifique - Toutes les variables doivent etre ecrites avant d’ˆ tre lues e ˆ ˆ • E.2.a, E.2.b - Non-sp´ cifique - Les entr´ es des blocs fonctionnels utilisateur doivent etre lues et ne pas etre e e ´ ecrites e e ˆ • E.2.c, E.2.d - Non-sp´ cifique - Les entr´ es/sorties des blocs fonctionnels utilisateur doivent etre lues et ´ ecrites ˆ ´ ´ • E.2.e - Non-sp´ cifique - Les sorties des blocs fonctionnels utilisateur doivent etre ecrites avant leur eventuelle e lecture `´ • E.U.1 - SE Unity - L’utilisation de fonctions des librairies obsol` tes d’Unity est a eviter e 18/20

Guide de codage des programmes automatesR` gles de Structuration e • S.1 - Non-sp´ cifique - Les sauts en arri` re sont interdits e e ˆ ´ • S.2 - Non-sp´ cifique - Une variable doit etre ecrite au sein d’une seule routine e e ˆ ´ • S.3 - Non-sp´ cifique - Une variable doit etre ecrite au sein d’une seule tˆ che a ˆ ´ • S.4 - Non-sp´ cifique - Une sortie physique ne doit etre ecrite qu’une seule fois par cycle automate e e e ˆ • S.5 - SE Unity - Les variables ne doivent pas en g´ n´ ral etre localis´ es e • S.6 - Non-sp´ cifique - Les instances de FB/DFB sont appel´ es une et une seule fois e e • S.7 - Non-sp´ cifique - Les variables d´ finies sont utilis´ es e e e • S.8 - Non-sp´ cifique - Les variables ne se chevauchent pas e • S.9 - Non-sp´ cifique - Mesure de la complexit´ e e • S.10 - Non-sp´ cifique - Limitations dues aux SCADA eInformations Utiles • I.1 - Non-sp´ cifique - Taux de commentaires e • I.2 - Non-sp´ cifique - Pr´ sence de code dans les commentaires e e • I.3 - Non-sp´ cifique - Pr´ sence de code mort e e • I.4 - Non-sp´ cifique - Pr´ sence d’´ l´ ments verrouill´ s e e ee e • I.5 - Non-sp´ cifique - Nombre cyclomatique v(G) e • I.6 - Non-sp´ cifique - Complexit´ essentielle ev(G) e e • I.7 - Non-sp´ cifique - Nombre de lignes de code e • I.8 - Non-sp´ cifique - Nombre d’´ tapes du Grafcet e e • I.9 - Non-sp´ cifique - Nombre de branches du Grafcet e • I.10 - Non-sp´ cifique - Ratio de code dupliqu´ sur l’application e eOptions • O.U.1 - SE Unity - SFC : Le multi-jetons sur le Grafcet est interdit ´ • O.U.2 - SE Unity - SFC : Non maintient des etapes pr´ c´ dentes actives pour SetSteps e e • O.U.3 - SE Unity - SFC : Pas de saut In/Out dans les divergences en ET ´ • O.U.4 - SE Unity - SFC : Une seule evolution par divergence • O.U.5 - SE Unity - ST : Sauts et labels interdits • O.U.6 - SE Unity - Pas de chiffre en d´ but d’identificateur e • O.U.7 - SE Unity - Jeu de caract` res standard pour les identificateurs e • O.U.8 - SE Unity - Les expressions ST sont interdites dans le FBD et le LD • O.U.9 - SE Unity - Les informations d’upload avec commentaires et tables d’animation e ` • O.U.10 - SE Unity - Les bobines en LD sont align´ es a droite20 janvier 2012 - Version 1.6.7 19/20

Guide de codage des programmes automates4.2 Historique du document Date Changements 9 juin 2009 Version initiale 26 octobre 2010 Ajout de la section sur les options 9 novembre Ajout les descriptions pour les r` gles S5, S6, S7, S8, S9, S10, I5, I6, I7, I8, I9, I10 e 2011 21 novembre Corrections texte dans Annexes et C4 2011 19 janvier 2012 Relecture et corrections (ortho, gramm) par Pauline20/20 20 janvier 2012 - Version 1.6.7

[FR] Guide de codage des programmes automates

by Itris Automation Square on Jan 20, 2012

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

[FR] Guide de codage des programmes automates — Document Transcript