Tout est possible. Le choix ne dépend que de
critères économiques, le Grafcet n'imposant aucune solution. Nous
allons traiter les cas les plus courants :
- En cas de réalisation unitaire, comportant de nombreuses
entrées / sorties, nécessitant des modifications de temps en
temps (par exemple partie de ligne de production automatique), on choisira un
automate programmable (API), programmé directement en Grafcet à
l'aide d'un console de programmation (actuellement on utilise un PC, ce qui
permet de saisir et simuler l'automatisme au calme, avant le test in situ).
Cette solution semble assez chère dans l'absolu, mais reste
économique relativement au prix des parties opératives mises en
oeuvre. C'est de plus la solution qui minimise le prix des modifications (tant
que la partie opérative n'a pas à être fortement
modifiée).
- En cas de réalisation en petite série, de matériels
qui devront être personnalisés pour chaque client (par exemple
machine à emballer), on choisira comme précédemment un
automate, programmable en Grafcet à l'aide d'une console (ou même
par une connexion réseau). Ceci permet une production de
matériels uniformes (ou en tous cas moins variables), la
personnalisation se fera uniquement sur la console. On pourra vendre le produit
avec l'automate seul (sans la console, qui vaut en général
très cher), assorti d'un service après-vente pour les
modifications ou évolutions.
- En cas de réalisation unitaire d'un petit automatisme (par exemple
un transfert de pièces à l'aide d'un tapis et quelques
vérins), on choisira un automate d'entrée de gamme, programmable
uniquement dans un langage simple (ET, OU , mémoires...) La
programmation sera aisée (voir mon document sur la programmation d'un Grafcet) mais la
modification sera souvent plus simple en réécrivant
complètement le nouveau programme.
- Si l'on produit en série un système automatique, avec un
fonctionnement prédéfini et figé mais pas trop
compliqué (machine à laver par exemple), la solution la plus
économique est le câblage : une carte électronique avec une
bascule par étape, les seuls éléments coûteux sont
les interfaces (donc le prix dépendra surtout du nombre d'entrées
- sorties). Si un fabriquant de machines à laver me lit, qu'il
m'explique pourquoi ils continuent à utiliser des programmateurs
mécaniques qui sont plus chers et plus fragiles. (j'ai écrit cette phrase en 1997. Ah si tout le monde m'écoutait !)
- Pour un système avec un fonctionnement complexe, où la
rapidité est nécessaire, ou bien s'il nécessite
également un peu de calcul numérique, on choisira une carte avec
un micro-contrôleur (ou microprocesseur si les besoins sont plus
importants), assorti d'une interface comme dans le cas précédent.
La programmation est aisée (voir mon document sur la programmation d'un Grafcet), une fois que
l'on connaît bien le matériel. Le coût du matériel
est dérisoire (trois euros pour un
micro-contrôleur tel que le ST62 avec un peu de RAM, de ROM, une vingtaine
d'entrées - sorties ToR et un port analogique), par contre le
matériel de développement revient très cher, son
acquisition n'est envisageable que si l'on prévoit de créer un
certain nombre de systèmes (sinon on se rabattra sur le câblage ou
l'API, ou la sous-traitance).
- Dans les cas où le système est incompatible avec
l'électronique (champs magnétiques, parasites, ambiance
humide...), on peut utiliser une partie commande dans la même
énergie que celle de la partie opérative : pneumatique ou
électrique. Dans ce cas une seule solution est possible, le
câblage. On utilisera la même méthode que pour le
câblage électronique, il suffit de savoir réaliser les
fonctions combinatoires (ET, OU...) et un bistable équivalent à
une bascule (distributeur bistable, relais auto-alimenté...). Un
séquenceur est une telle bascule prévue pour représenter
une étape, avec un brochage facilitant le chaînage
d'étapes. Ce n'est presque jamais la solution la plus économique.
Reste à parler de l'évolution actuelle des API. Dans un premier temps, il faut noter que désormais les automates sont tous dotés de fonctionnalités de dialogue entre eux (réseau de terrain). Cette évolution nécessite de prendre en compte l'automatisation de l'unité de production dans sa globalité. Pour que ce soit vraiment efficace, il ne faudrait plus programmer chaque API séparément, mais utiliser une démarche différente : démarche de projet, analyse descendante (SADT), approche arborescente... Les logiciels proposés par les fabriquants n'évoluent pas bien vite (mais les clients me semblent encore plus rétissants āagrave; l'évolution).
Une fois le réseau disponible, il ne coûte pas beaucoup plus pour récupérer (sur un ordinateur) les données de production. C'est la "supervision". Ceci permet en premier lieu de surveiller la production, mais aussi d'obtenir tous les chiffres nécessaires pour analyser la production, et même d'intégrer directement les données dans la gestion de production (ERP).
Dernière évolution envisageable, puisque maintenant l'ordinateur peut dialoguer avec les automates, est de le faire participer à l'automatisation. Le PC est parfaitement capable de prendre en charge des calculs complexes, permettant de diminuer la puissance des automates (et donc le prix). Par exemple, au lieu d'utiliser des matériels très chers pour gérer les asservissements, on peut déléguer le calcul à un PC et les E/S à un API moyenne gamme muni d'E/S numériques.
Patrick TRAU,ULP - IPST,Août
97