Cyriac LEON
Ingenieur étude et développement en automatisme et informatique industrielle
Ce schema nous montre l'evolution que devrait avoir les technologies d'automatisation.
Les points en vert sont les points sur lesquels nos solutions peuvent amener une évolution.
La simplification que la programmation que nous avons apporté va nous permettre d'améliorer la gestion des projets.
La première modification est la façon dont on voit un système contrôle/commande.
Pour le moment un objet est un programme que l'on écrit afin de pouvoir le réutiliser ensuite. Sur un système contrôle/commande les objets gèrent la partie contrôle du process qui correspond à la surveillance de la vie de l'objet en suivant les ordres donnés par la partie commande du process.
On créé des blocs objets différent à chaque fois que l'on utilise un nouvel objet. Par exemple pour un silo on va créér un bloc pour un
tapis, un élévateur ou un nettoyeur ou une pompe. Mais en fait :
Un tapis c’est :
- une entrée de validation de tension pour valider la marche
- une commande ou plusieurs commandes
- un retour de marche et un contrôleur de rotation pour valider la marche
- des informations à donner au cerveau (marche ok, en défaut…)
- des informations reçues du cerveau (demande de marche, arrêt …)
Et une pompe c’est :
- une validation alimentation en liquide pour valider la marche
- une commande pour la pompe et d’autres pour les vannes
- des capteurs de pression, un retour de marche, un capteur de température pour valider la marche de la pompe.
- des informations à donner au cerveau (marche ok, en défaut…)
- des informations reçues du cerveau (demande de marche, arrêt …)
Mais le programme n’a pas besoin de savoir que la sortie commande un tapis ou une pompe. Car :
Lorsque l’on programme n’importe quel objet on a :
- des entrées à valider pour sa mise en route
- une ou plusieurs sorties pour les commander
- des entrées que l’on surveille pour veiller au bon fonctionnement
- des informations à donner au cerveau (marche ok, en défaut…)
- des informations reçues du cerveau (demande de marche, arrêt …)
Les lignes bleues sont les lignes qui correspondent a la partie contrôle du process (surveillance de la vie de l'objet)
Les lignes noires sont les lignes qui correspondent à la partie commande du process.
Notre reseau permet à 0 ou X entrées de communiquer entre elles et avec le bloc objet
La partie commande d'un process est composé de deux parties.
- La partie IHM : qui permet la liaison entre l'homme et la machine. Cette partie doit être créée pour chaque application car elle contient la description de l'installation.
- La partie commande. Elle sert a donner les ordres de marche arrêt aux objets. Elle sert d'intermédiaire entre les objets.
Pour prendre un exemple nous allons prendre la gestion d'un silo à grains. Dans un silo il y a une règle prioritaire. Un objet n'a le droit d'être lance que si l'objet qui les suit est en route. Le bloc commande surveille la marche des objets et fait des tests selon les circuits en cours. Il faut écrire un programme pour chaque circuit. Avec notre solution vu que les objets peuvent communiquer entre eux l'objet va juste regarder si le suivant est en route afin de savoir si il doit démarrer. Le bloc commande a juste a signaler quel sont les objets utilisés par le circuit (qui est la partie IHM).
Grace à notre réseau nous pouvons maintenant intégrer une grosse partie de la commande dans les objets. Ainsi lors de l'ajout, la suppression ou la modification des objets la partie commande n'a besoin d'être modifiée uniquement pour la partie com avec l'IHM de l'installation.
Au niveau de l'analyse fonctionnelle d'une installation on ne va plus travailler au niveau des objets (tapis, elevateurs...) mais au niveau des Entrées Sorties (un retour de marche, un validation d'alimentation ...)
Cela va permettre d'effectuer un travail plus important pour la partie simulation et IHM. On va pouvoir tres simplement créer des simulateurs. Mais aussi developper l'aide a la maintennance et l'utilisation de tout les jours des installations.