Choisir un automate programmable industriel (API) adapté à l’application envisagée représente une tâche importante pour celui qui en a la charge. La première difficulté est liée à l’importance du marché ; il y a en effet plus de 200 produits différents qui sont proposés par plus de 60 constructeurs. Le choix est difficile car a priori il n’existe pas de matériel idéal ; il n’y a pas non plus de mauvais produits. On y constate simplement une spécialisation plus ou moins marquée vis-à-vis des applications potentielles : soit vers le bas de gamme ou le haut de gamme, soit dans les fonctions à réaliser (booléen, séquentiel, régulation, contrôle, etc.).
Le marché est en pleine expansion : lorsqu’en 1981 le CETIM a entrepris de recenser les API, environ 110 ont été identifiés ; un an plus tard, ce nombre s’élevait à 180 et à l’automne 1983 il atteignait 210 ; il y a vraisemblablement 250 automates disponibles aujourd’hui. C’est aussi un produit qui évolue sur le plan des performances et qui bénéficie de l’explosion de la micro-électronique. On voit donc tout le danger de limiter son choix, par habitude, à quelques API ou fournisseurs ; c’est souvent renoncer à bénéficier de l’évolution de la technique.
LE FICHIER « PRODUITS »
Depuis 1981, le CETIM recense dans un fichier « produits » les caractéristiques des automates présents sur le marché.
Chacun est présenté de la même façon avec des caractéristiques identiques et homogènes. Ce fichier est implanté sur un micro-ordinateur, ce qui permet d’assurer une mise à jour permanente. Il est édité une fois par an. La troisième édition est en date du 1er janvier 1985. Il est toujours possible, en cours d’année, de consulter le recueil, qui est une réplique au jour le jour du fichier informatique, et d’obtenir une ou plusieurs copies de fiches du recueil.
Le fichier comprend trois parties :
— des fiches « automates » qui comportent 304 renseignements sur les principales caractéristiques techniques et économiques de chaque automate répertorié ;
— des fiches « consoles » (outil de programmation) qui contiennent 136 renseignements techniques, opérationnels et économiques sur les outils de programmation disponibles,
— des fiches « sociétés » qui regroupent 108 renseignements administratifs et commerciaux sur les fabricants et distributeurs d’API.
Avec 179 automates répertoriés, 109 consoles et 51 sociétés, ce sont plus de 70 000 informations qui donnent l'image du marché. Ce fichier est le premier élément qui va permettre de choisir un appareil avec le recensement complet du marché présenté d'une manière identique et qui est remis à jour en permanence. La connaissance de ses caractéristiques est indispensable pour effectuer un choix sans le risque d’oublier des produits inconnus, sans passer un temps précieux à la collecte des informations et sans avoir à interpréter les présentations et les valeurs d'une documentation différant d’un constructeur à un autre. Cependant, cette connaissance n'est pas suffisante pour mener à bien son choix, car il faut interpréter les caractéristiques, les classer, les comparer entre elles et aux données de son problème : c’est là qu’intervient CETIM-OCAPI.
OCAPI, UN OUTIL POUR LE CHOIX D'UN API
CETIM-OCAPI est plus qu'une méthode, c'est un véritable outil qui apporte tout ce qui est nécessaire pour conduire son choix :
- - un fichier « produits », image du marché,
- - un diagnostic qui permet de dégager les spécifications importantes de l’application envisagée,
- - un tri primaire qui sélectionne objectivement les produits susceptibles de convenir à l’application,
- - une optimisation du choix qui, par une évaluation des produits permet à l'utilisateur de sélectionner le mieux adapté, en lui laissant exprimer son point de vue tout en le guidant grâce au guide d’évaluation.
Le diagnostic
Le but de l’opération est d’aider à formaliser les spécifications de l'application en évitant de se laisser submerger par des exigences inutiles dans le cas d'utilisation d'un automate et en ne retenant que celles qui vont influer sur le choix du produit.
Le diagnostic consiste à décrire les tâches à remplir par l'automate.
Cela s'effectue à l'aide de quatre fiches de spécifications :
- — la fiche inventaire des liaisons entre le processus et l’automate définit avec qui (capteurs, actionneurs, etc.) l'automate va échanger des informations,
- — la fiche technologie des liaisons précise comment ces échanges d’informations s'opèrent,
- — la fiche traitement caractérise le traitement à effectuer sur les informations échangées,
- — la fiche environnement indique dans quelle sévérité d’environnement ces tâches doivent s’accomplir.
La fiche inventaire des liaisons
Cette fiche décompose les liaisons suivant les destinations et suivant la nature des informations véhiculées.
Destinations des liaisons
Un automate peut avoir des échanges d'informations avec trois sources. Il y a tout d’abord la machine ou le processus à piloter (PO, partie opérative), c'est la fonction principale, mais il y a aussi les liaisons avec l'opérateur et de plus en plus celles qui sont réalisées avec d'autres systèmes de commande (autre PC, partie commande).
Nature des informations
Avec ces trois sources, les informations peuvent être de trois natures différentes : tout ou rien (TOR) ; analogique (ANA), numérique (NUM). Pour chacune des destinations possibles et pour chacune des natures d'information, on inventorie le nombre de liaisons entrantes et sortantes en utilisant un vocabulaire proche de l'utilisateur. Ainsi pour les informations tout ou rien venant de la machine, on parlera de capteur ; venant de l’opérateur, d’afficheur ou commutateur, etc.
La fiche technologie des liaisons
Dans cette fiche est précisée la technologie des liaisons utilisées en définissant :
- - la nature des signaux qui véhiculent l'information (courant ou tension),
- — la gamme d’excursion des signaux,
- — le principe d’émission-réception des signaux (relais, statique, seuil, conversion, code, procédure, etc.),
- - les caractéristiques des signaux (nombre de bits, résolution, fréquence, vitesse, etc.).
La fiche traitement des informations
Le traitement à réaliser sur les informations reçues est caractérisé par deux aspects :
— l'aspect qualitatif qui est relatif à la complexité du traitement, — l'aspect quantitatif qui est relatif au volume du traitement.
On se limitera pour certains points à l'aspect qualitatif, l'aspect quantitatif allant souvent de pair ; par exemple, l'API qui offre la possibilité de calcul offre une taille mémoire en proportion.
La fiche environnement
Elle permet de juger des contraintes auxquelles l'API doit satisfaire.
Ce point est particulièrement bien traité dans la norme API-NFC 63-850 ; on ne fera donc que préciser si l'environnement est plus ou moins sévère que ne le prévoit celle-ci.
Le tri primaire
Il ne reste plus qu'à comparer les spécifications avec les caractéristiques des produits ; pour cela, il suffit de récapituler les premières sur une colonne en les codant dans certains cas ; le tri consiste alors à comparer cette colonne avec les secondes qui sont écrites dans le même ordre, suivant le même code.
Ce tri porte sur 63 caractéristiques ; il est, bien sûr, possible de le limiter à quelques-unes : par exemple, une application ne comportant que des E/S TOR, quelques temporisations et un traitement simple ne demandera un tri que sur 15 caractéristiques.
Les spécifications du diagnostic sont liées aux caractéristiques du produit par des critères qui précisent le choix.
L'optimisation du choix
Le tri primaire indique tous les API capables de répondre à la demande ; ils peuvent y satisfaire largement ou au contraire convenir tout juste. C'est pourquoi il est utile de compléter ce tri par une optimisation ; il n'est alors plus possible de procéder comme pour le tri primaire, car les caractéristiques qui sont à examiner doivent être considérées d'une manière subjective, l'utilisateur devant pouvoir exprimer ses habitudes et préférences.
L'optimisation consiste en une évaluation des produits sélectionnés, matérialisée par une notation et une pondération de chacune des caractéristiques évoquées, c'est-à-dire celles qui influent sur l'agrément de la conduite du projet d'automatisation ; elles sont évoquées dans l'ordre où elles interviennent, dans les phases de mise en œuvre de l'API, de l'exploitation, de la maintenance et enfin sur le plan économique. Si l'utilisateur est le seul juge de la note à attribuer et de la pondération à y affecter, il est conseillé dans ce but au moyen du guide d'évaluation dans lequel sont signalés les avantages et les inconvénients de chacune des options prises par les constructions d'API.
La notation que nous avons adoptée est limitée à six niveaux :
— deux niveaux positifs + et ++, — deux niveaux négatifs - et --, — un niveau nul 0 (éliminatoire) et un niveau indifférent *.
La pondération se situe à quatre niveaux :
— 1. indispensable, — 2. utile, — 3. optionnel, — 4. sans intérêt.
La sommation des notes et donc le classement des produits s'établit avec un certain nombre de règles :
— on additionne les notes séparément pour les pondérations 1, 2 et 3 (le n° 4 ne peut être pris en compte), — la note nulle est éliminatoire, — les notes positives n'annulent pas les notes négatives ; elles se totalisent séparément.
Comme pour le tri primaire, l'évaluation peut être poussée au niveau que l'on désire. L'utilisateur peut rester superficiel dans son évaluation ou souhaiter qu'elle soit faite de manière approfondie dans le sens horizontal ; de même il peut se limiter dans le plan vertical sur le ou les points qui lui paraissent les plus importants (figure 4).
Dans cette présentation de CETIM-OCAPI, il n'est pas envisageable de couvrir tous les domaines d'évaluation. Les quelques précisions qui suivent permettront de mieux comprendre la démarche.
Utilisation du guide d'évaluation dans le domaine de la mise en œuvre (aspect logiciel)
Dans le domaine de la mise en œuvre, on s'intéresse à l'aspect matériel, puis à l'aspect logiciel du produit ; dans ce dernier, la première chose que l'on examine c'est le langage de programmation.
Les différents langages de programmation
Les langages de programmation peuvent se classer en fonction de la façon de raisonner pour passer de l'analyse du cahier des charges à la programmation. De ce fait on distingue les familles suivantes :
Le langage relais ou « ladder » basé sur le raisonnement « schéma électrique ». Il est bien adapté aux utilisateurs électriciens de formation ou à ceux ayant déjà pratiqué des automatismes relais, pour des problèmes logiques séquentiels et combinatoires.
Le langage booléen basé sur la transcription du cahier des charges en équations booléennes ; il
demande de bien connaître ces fonctions ainsi que les différentes lois associées.
Le langage informatique : c'est une traduction du langage élémentaire, le basic principalement ; son utilisation nécessite de bien posséder les notions de programmation (déroulement d'instructions, sauts, boucles, etc.).
Le langage d’étape : c'est celui que l'on rencontre avec les séquenceurs programmables ; c’est le langage le plus proche de l'analyse pour les problèmes séquentiels ; il ne demande pas de formation ni d’expérience particulière. C’est dans cette voie que l'on assiste au plus grand développement.
L’expérience du programmeur est également à prendre en compte ; il n’aura aucune difficulté, en effet, pour s’adapter à un automate de la même famille de langage. Le choix doit tenir compte du fait que l'on puisse envisager une formation ou qu’au contraire une adaptation rapide soit souhaitée.
Il faut noter que certains produits offrent au choix plusieurs formes (familles) de langages. L'utilisateur peut, dans ce cas, choisir celui qui lui convient le mieux. Le choix sera souvent exclusif et devra se faire au début de l'application ; pour certains automates, on peut transformer un programme écrit dans un langage en un programme écrit dans un autre (booléen en relais et réciproquement). Commencent à apparaître des produits multilangages simultanés où l'on peut utiliser dans un même programme des langages différents.
Le tableau ci-dessous (extrait du guide d’évaluation) donne un classement de l'intérêt des langages en fonction du profil du programmeur, de son expérience, de l'éventualité d'une formation.
Utilisation du guide d’évaluation dans le domaine du bilan (aspect « documentation »)
Le bilan est le dernier point qui est évoqué dans le guide d’évaluation ; il s'agit d'une étude économique, avec l’évaluation d'un certain nombre de coûts directs et indirects mais aussi d’un bilan d’assistance consistant en une évaluation de la société « fournisseur » en termes d’assistance technique au client.
Si les autres rubriques du guide d’évaluation concernent le produit, c’est ici la société (constructeur, fournisseur) en relation avec l’utilisateur qui fait l'objet d’une évaluation. Elle peut, en effet, jouer un rôle non négligeable dans la réussite de l’opération d’automatisation.
Cette société est évaluée sur trois points :
— les documents qu’elle remet avec le produit,
— l'information et la formation qu’elle diffuse éventuellement,
— les diverses assistances qu’elle apporte.
CONCLUSION
L'utilisateur pourra trouver l’essentiel des caractéristiques sur les produits et les consoles ainsi que les services offerts par les sociétés dans le fichier produits API du CETIM.
CETIM-OCAPI est modulaire et comme cela a été expliqué, l'utilisateur pourra réaliser un choix grossier ou au contraire un choix précis.
Le produit CETIM-OCAPI comprend :
— le fichier produits API,
— le mode d'emploi, l'explication didactique de la méthode, le guide d'évaluation,
— les cahiers de CETIM-OCAPI : les fiches de saisies, la fiche de récapitulation, les tableaux de caractéristiques, les fiches d’évaluation.
Une version logicielle complète les cahiers de CETIM-OCAPI et le fichier produits. Elle réalisera le tri primaire et l'aide à l’évaluation.
L'actualisation du fichier est réalisée tous les ans. Les cahiers de CETIM-OCAPI suivent cette actualisation.
