Modèles d’architecture basés sur des applications de surveillance des machines

Tulip offre une grande flexibilité dans la manière dont vous structurez les applications autour des machines. Le modèle le plus adapté dépend de la maturité technique de votre équipe, de la standardisation de vos processus et de votre budget.

Modèle 1 : Applications machine modulaires (modèle 1:1)

Structure: une machine → une application → un poste → un terminal

Schéma d’architecture:

Cas d’utilisation

• Développeurs amateurs débutants créant leurs premières applications de surveillance de machines
• Déploiementsrapides de preuve de concept où la simplicité prime sur l’efficacité
• Processus manuels personnalisés par instance de machine (par exemple, la machine 1 nécessite des étapes d’inspection spécifiques qui ne s’appliquent pas à la machine 2)
• Développement axé sur les opérations, où les développeurs assument plusieurs rôles et disposent d’un temps limité

Pourquoi est-ce important ?

Ce modèle établit une correspondance physique 1:1 entre le logiciel et le matériel, éliminant ainsi toute abstraction. Les développeurs peuvent identifier une machine dans l’atelier et lui associer son application dédiée. Cette clarté réduit l’effort mental et rend le dépannage intuitif.

Exemple

Scénario: un fabricant de produits alimentaires et de boissons dispose de 3 lignes d’emballage. Chaque ligne présente des causes de temps d’arrêt, des configurations de pièces et des flux de travail des opérateurs qui lui sont propres.

Mise en œuvre

• Créer un type de machine : « Ligne de conditionnement »
• Créer 3 machines : « Ligne A », « Ligne B », « Ligne C »
• Développer 3 applications : « Terminal de la ligne A », « Terminal de la ligne B », « Terminal de la ligne C »
• Attribuer chaque application à un poste dédié équipé d’un terminal fixe

Avantages

• Une isolation claire des données empêche toute corruption des données entre les machines
• Personnalisation aisée des flux de travail par machine
• Dépannage simple (le problème se situe toujours au niveau d’une seule application autonome)

Limites

• Nécessite un terminal physique par machine (coût matériel)
• Les modifications globales de l’application nécessitent la mise à jour de 3 applications distinctes
• Non évolutif au-delà d’environ 10 machines

Modèle 2 : Affectation des machines à l’application de station

Structure: un type de machine → une application → plusieurs stations (machine affectée dynamiquement via le mappage des stations)

Schéma d'architecture:

Cas d’utilisation

• Processus standardisés sur des types de machines identiques
• Développeurs citoyens à temps plein à l’aise avec l’abstraction et la logique de déclenchement
• Besoind’une évolutivité horizontale (plus de 10 machines du même type)
• La maintenance centralisée des applications est une priorité

Fonctionnement

1. Attribuez chaque machine à un poste dans « Atelier > Machines » (onglet « Configuration »)
2. Dans l’application, utilisez les conditions de déclenchement « à ce poste » pour référencer dynamiquement la machine attribuée
3. Lorsque l'application s'exécute sur le poste 1, elle interagit avec la machine 1. Lorsqu'elle s'exécute sur le poste 2, elle interagit avec la machine 2

Exemple de déclencheur d’application

Quand: la machine de ce poste génère une sortie «Changement d’état »Si: Sortie de la machine / Changement d’état =Arrêt Alors: Créer un enregistrement dans la table « Historique des états ».

Exemple

Scénario: un équipementier automobile de premier rang dispose de 15 fraiseuses CNC identiques exécutant le même processus de production.

Mise en œuvre

• Créer un type de machine : « Fraiseuse CNC 5 axes »
• Créer 15 machines (CNC-001 à CNC-015)
• Développer une application: « Terminal opérateur CNC »
• Créer 15 postes de travail et attribuer une machine à chacun d'entre eux
• Déployer l'application unique sur les 15 postes

Avantages

• Une seule application à maintenir (les mises à jour globales se propagent instantanément)
• Réduction du temps de développement des applications pour les déploiements sur un parc de machines
• Utilisation d’une logique de déclenchement « sur ce poste » (référence dynamique intégrée à la machine)

Limites

• Nécessite toujours un terminal par station (coût matériel inchangé)
• Toutes les machines doivent être du même type et présenter des attributs identiques
• La logique personnalisée par machine nécessite des branchements conditionnels (complexité accrue)

Modèle 3 : application à variables de machine (terminal flottant)

Structure: une application → plusieurs types de machines → sélection des machines en fonction de variables → terminal partagé/flottant

Schéma d'architecture:

Cas d’utilisation

• Contraintes budgétaires: nombre limité de terminaux disponibles
• Modèle d’opérateur itinérant: un opérateur se déplace d’une machine à l’autre avec un iPad partagé
• Les machines ne nécessitent pas de surveillance continue: l’application ne doit fonctionner que pendant les opérations actives

Limitation critique : pas de mode « headless »

Ce modèle ne prend pas en charge la surveillance en arrière-plan ou sans interface utilisateur. Si l'application est fermée, aucune alerte ne peut être déclenchée par les machines. Ce modèle ne convient que pour :

• La saisie de données initiée par l'homme (l'opérateur consigne les défauts, le nombre de pièces)
• Les inspections ponctuelles des machines
• Les scénarios dans lesquels les machines ne génèrent pas de données lorsque l’application n’est pas en cours d’exécution

Fonctionnement

1. Créez une variable de machine dans l’application (par exemple, selectedMachine)
2. Ajoutez un widget de liste déroulante ou une fonction de lecture de code QR pour remplir la variable selectedMachine lors de l'exécution
3. Utilisez « selectedMachine » dans toutes les références de déclencheur

Exemple de déclencheur d’application

Quand: la variable machine « Selected Machine » renvoie {Attribute}Alors: enregistrer la dernière sortie de la machine dans une variable

Exemple

Scénario: un laboratoire pharmaceutique dispose de 5 instruments d’analyse qui ne fonctionnent que lors de tests programmés. Les techniciens utilisent un iPad partagé pour enregistrer les paramètres et les résultats des tests.

Mise en œuvre

• Créez 5 machines (HPLC-1, GC-MS-2, etc.)
• Développer une application : « Journal des équipements de laboratoire »
• Ajouter un menu déroulant : « Sélectionner un instrument » → remplit la variable selectedMachine
• Le technicien se déplace avec l’iPad d’un instrument à l’autre, sélectionne la machine active, puis enregistre les données

Avantages

• Coût matériel minimal (un seul terminal partagé)
• Sélection flexible de la machine lors de l'exécution
• Idéal pour les flux de travail ponctuels/intermittents

Limites

• Pas de mode « headless » : l’application doit être activement en cours d’exécution pour que toute logique puisse s’exécuter
• Pas de surveillance en arrière-plan lorsque l’application est fermée
• Gestion complexe des états (quelle machine est actuellement active ?)
• Ne convient pas au suivi de l'OEE 24 h/24 et 7 j/7

Arbre de décision pour le choix du modèle d'architecture

Utilisez cet arbre de décision pour choisir le modèle le mieux adapté à vos besoins :

Pour en savoir plus

• Surveillance des machines : architecture « headless » ou basée sur une application
• Variables

{{snippet.Avez-vous trouvé ce que vous cherchiez ?}}