Préliminaires
Le but de ce document est d’expliquer les méthodes utilisées et les choix faits dans la programmation du processus de pasteurisation (programme API et supervision). Ce processus consiste en la transformation et le conditionnement des produits fluides (crème ou lait).
L’atelier est composé de plusieurs zones : standardisation, pasteurisation, maturation, petit conditionnement, grand conditionnement, recyclage et NEP. La NEP est pilotée par un automate Schneider TSX 57 Unity et le reste par un automate Schneider M580.
Ces méthodes de programmation sont basées sur le standard de programmation IMAP, comme l'utilisation des séquences avec des particularités spécifiques au site, telles que zones mémoires et standards client.
Ce document peut être utilisé, en partant du principe que les concepts de base de l’automatisme sont déjà acquis.
Il faut tenir compte que ce projet a des contraintes très importantes qui ont imposé certains choix de programmation :
- La plus importante : le projet consiste en l’augmentation de la capacité de production et de la sécurisation de la production. Le projet s’étale sur plusieurs années et il est découpé en plusieurs phases ; La difficulté réside dans le fait qu’il faut garder une compatibilité totale entre les fonctions avant et après modifications (chemins de circuits, surtout blocage et autorisations, synchronisations, recettes, paramètres, etc.) avec un temps d’arrêt réduit au minimum.
- La première phase du projet était la remise à plat (refonte du programme) suite à l’utilisation de l’ancien programme qui rendait les modifications et les dépannages quasi impossibles. L’ancien programme était un mix des grafcets et de conversions partielles des grafcets en grafcets sur des bits et des séquences IMAP avec une utilisation excessive des mémoires et des variables temporaires (jusqu’au 4-5 niveaux de copies des variables). Le programme était un programme revampé et la version initiale (en PL7) utilisait une logique combinatoire dérivé d’un fonctionnement manuel. Exemple : pour faire un transfert, il faut sélectionner, la source, la destination le chemin et après utiliser les mémoires pour activer les actionneurs – impossible de déterminer la cause d’un arrêt suite à un défaut.
- L’ancien programme traitait les fonctions d’une manière compacte. Dans la même section c’était gère le soutirage de tanks de standardisation, le Pasto, la destination et les pousses de fin. Cette façon de programmer n’est pas compatible avec le but final du projet. Le nouveau format découpe le transfert en plusieurs zones traitées comme des boites noires (échange d’informations amont/aval), qui permet l’insertions des éléments à n’importe quel endroit sans affecter la totalité de la gestion. (Ex. standardisation <-échange informations-> Pasto P04 devient standardisation <-échange informations-> manifold orientation Pasto <-échange informations-> Pasto P04)
- L’ancien programme n’était pas standardisé. (Ex. la programmation de la gestion des agitateurs, vidange, etc. n’était pas identique pour toutes les groupes des éléments). Cette standardisation de la programmation doit tenir compte d'éléments spécifiques à chaque fonction et il faut s’assurer que la réponse de l’api et identique ou meilleure après la reprogrammation qu’avant l’intervention.
- L’atelier est complexe avec une multitude d’éléments : environ 210 vannes, 45 entrées analogiques ; pour la phase finale, il faut rajouter environ 50 vannes et plus de 20 mesures. En plus les technologies utilisées sont différentes : cartes API, cartes STB, passerelles et modules et vannes ASi, éléments en IO-Link. Pendant les différentes phases, il aura un basculement des anciennes technologies vers les nouvelles (ex. mesures ana en STB/ASi vers IO-Link).
- Pendant la première phase (remise à plat du programme), le projet a évolué au fur et à mesure de l’avancement. Il a passé d’un programme standard IMAP vers un projet « prototype » « objets » et la supervision IHM a été transformé en projet PCVue prototype Architect Les blocs objets utilisés n’ont pas été testes ailleurs.
- Les plages d’adresses utilisées doivent permettre l’utilisation d’une supervision PCVue et des écrans IHM (fonctionnalités limitées), ainsi qu’une compatibilité avec les zones réservées pour la communication inter-APIs.
- Le facteur humain : même si le programme a été refait, la méthode de programmation, la façon d’interagir, l’ergonomie et les interfaces visuelles et surtout la réaction du système doivent se rapprocher au maximum de l’ancien projet ; Ce projet pourra servir comme modèle pour les autres supervisions présentes sur site (REP, Tour).
- Les collègues : vue la complexité du projet, le programme doit être conçu d’une manière claire, avec toutes les informations nécessaires dans le programme sous forme de commentaires et qui permet rapidement l’identifications des pannes en lisant le code (pour les astreintes).