Tester en direct la salle de contrôle Werk Nord
Exemple de projet · Werk Nord
Un fabricant de boissons appelle : il veut savoir pourquoi ses lignes s’arrêtent et pouvoir retracer rapidement ses lots. Nous montrons étape par étape comment en naissent une salle de contrôle, un MES et une application mobile.
Étape 1 · Demande
Une usine de boissons avec cinq lignes de remplissage planifie sur papier et dans Excel. Pourquoi une ligne s’est arrêtée, personne ne le sait vraiment en fin de poste – et la traçabilité consiste à fouiller dans des classeurs.
Décision
Au lieu d’un long document de concept, nous construisons tôt un prototype cliquable de l’interface. Pour Werk Nord, il était prêt dès le premier jour du projet. Ainsi, le client et les ingénieurs parlent de la même image – et non de termes que chacun comprend différemment.
Résultat Vision cible sur une page et prototype cliquable de la mise en page
Étape 2 · Visite
Nous suivons le flux de matières : stock de matières premières, parc de cuves, siroperie, cinq lignes de remplissage, expédition. Chaque partie de l’installation, chaque variable et chaque rôle est consigné dans la liste.
Décision
Les quatre cuves de sirop fini n’ont pas de sorte attitrée. Le changement se fait via une cuve vide ; chaque ligne puise, via un nœud de vannes, dans une cuve au choix. Cela coûte des vannes, mais rend la planification nettement plus souple.
Résultat Cahier des charges avec 290 équipements de terrain, quatre recettes et cinq rôles
Étape 3 · Plan
Avant de programmer, on fixe l’architecture. Elle définit où les données naissent, où s’exécute la logique et qui a le droit de commander quoi.
Décision
Liaison automates, alarmes, modules MES et automatismes tournent sur un seul et unique backend. Les serveurs de la salle de contrôle ne font qu’afficher et y envoient les commandes pour vérification. Si la logique tournait deux fois, les quantités seraient comptabilisées en double.
Résultat Schéma d’architecture et spécification fonctionnelle : cinq passerelles, un modèle, un concept de conduite
Étape 4 · Ingénierie
Place aux interfaces – avec Ignition d’Inductive Automation et les modules MES de Sepasoft. Vues, variables et traductions sont générées par programme, pas à coups de clics.
Décision
Les règles de statut des ordres résident dans des procédures stockées de la base de données. L’interface se contente de lire et d’appeler ces procédures ; son utilisateur de base de données n’a le droit de rien modifier directement. Ainsi, aucune vue ne peut mettre un ordre dans un état non autorisé.
Résultat Environ 200 écrans dans 7 projets, 5 011 termes en 14 langues
Étape 5 · Test
Une simulation joue le rôle des automates de toutes les parties de l’installation via OPC UA, le standard indépendant des fabricants pour l’échange de données en automatisation. Nous testons ainsi avec 290 appareils avant qu’une installation réelle ne soit raccordée.
Décision
« Le calcul de l’OEE est lent », telle était la première hypothèse. Une mesure du temps d’exécution par étape a montré que 86 % du temps était consacré aux mouvements de matières. Nous n’optimisons que lorsqu’une mesure montre où le temps passe réellement.
Résultat Rapports de test avec valeurs mesurées ; 57 préparations sur 58 entièrement comptabilisées
Ces six constats se sont réellement produits lors de la construction de Werk Nord. Chacun est documenté, sa cause identifiée et sa solution vérifiée.
Constat
Un mélangeur a transféré 5 000 L d’eau à la cuve en tant que sirop de citron.
Cause
Une préparation interrompue avait laissé 2 600 L d’eau dans le mélangeur. La préparation suivante a démarré sans contrôle de niveau, et ce sont les valeurs de consigne qui ont été comptabilisées.
Solution
Une préparation ne démarre que sur un mélangeur libre et vide. Ce sont les quantités réelles mesurées qui sont comptabilisées, et non les valeurs de consigne.
Constat
À chaque changement d’ordre, le MES signalait « Error recording OEE values » – précisément à la seconde du changement.
Cause
La saisie OEE des modules MES de Sepasoft n’écrit qu’une ligne par seconde et par installation. Nous terminions l’ancien run et démarrions le nouveau dans le même appel.
Solution
Changement en deux temps : terminer l’ancien run, démarrer le nouveau au prochain cycle de 10 secondes. Chaque run obtient ainsi sa propre ligne.
Constat
82 préparations de sirop sur 391 en trois jours n’avaient pas de lot de sortie. C’est là que la traçabilité s’interrompait.
Cause
Un prélèvement ne pouvait pas être réparti sur plusieurs niveaux de lot. Notre solution de contournement « Blend Lot » comptabilisait mal : pour la cuve TK01, 50 271 L contre 24 213 L physiquement.
Solution
D’abord, réparation de la chaîne de comptabilisation : ensuite 57 préparations sur 58 complètes. Puis comparaison avec la documentation du fabricant : la fonction prévue Auto Lot Completion au lieu d’un développement maison, avec un seuil dimensionné sur le plus petit prélèvement.
Constat
Des lignes étaient à l’arrêt alors que des ordres étaient en attente. Premier soupçon : un bug logiciel.
Cause
La ligne Bag-in-Box remplit du sirop pur et absorbait 31 000 des 34 324 L de besoin en sirop. Quatre cuves de sirop ne suffisent pas pour ce mix d’ordres.
Solution
Aucun code « réparé », mais le goulot d’étranglement démontré. Le planning calcule en parallèle les niveaux des cuves par sorte et signale une pénurie de sirop sous forme d’alarme de planification.
Constat
L’historique des variables enregistrait 28,6 points de mesure par seconde, soit environ 235 Mo par jour.
Cause
Trop de données étaient enregistrées, et trop souvent. S’y ajoutait une amplification d’écriture de 437 copies de partition par heure.
Solution
Signaux sélectionnés, groupes de variables et bandes mortes définis (l’enregistrement ne se fait qu’à partir d’une variation minimale) : 2,05 points de mesure par seconde, environ 17 Mo par jour – sans perdre aucune courbe.
Constat
Sepasoft Batch Procedure et l’automate ne se comprenaient pas : les commandes et les numéros d’état ne correspondaient pas.
Cause
L’automate possède sa propre machine d’états. C’est exactement la situation que l’on rencontre sur les installations existantes.
Solution
Une passerelle traduit les commandes et les états au niveau du PLI (Phase Logic Interface, l’interface entre le pilotage batch et l’installation). Le premier vrai batch s’est déroulé jusqu’au bout dès la première nuit du projet.
Nous consignons aussi nos erreurs : notre diagnostic « Le moteur batch remet la quantité réelle à zéro » était faux – c’est notre propre passerelle qui écrivait le zéro. Cela figure ouvertement en addendum dans le rapport de test.
Étape 6 · Remise
Une installation n’est terminée que lorsque les personnes de l’usine la conduisent en toute sécurité. C’est pourquoi nous formons par rôle et restons joignables après le démarrage.
Décision
La connexion à la salle de contrôle est facultative. Sans connexion, on voit tout, mais on ne peut rien déclencher. Chaque commande nécessite un rôle, est vérifiée dans le backend et journalisée avec l’utilisateur. La salle de contrôle reste ainsi ouverte à tous ceux qui doivent être informés.
Résultat Rôles formés, documentation, scripts de configuration et un interlocuteur attitré
Résultat
En six étapes, un dossier de projet vide est devenu une usine que l’on peut conduire – simulée, mais avec tout ce dont un vrai projet a besoin.
Werk Nord montre notre façon de travailler : d’abord comprendre, puis planifier, puis construire – et mesurer chaque constat avant de le corriger. Six jours après le démarrage, nous avons présenté l’installation à Inductive Automation et à Sepasoft. Comme le modèle, les vues et les traductions sont générés par script, une deuxième usine est pour l’essentiel une copie avec d’autres données de base.
