Les solutions de prototypage numérique pour les systèmes pneumatiques sont des environnements logiciels qui permettent aux ingénieurs de tester la logique de commande, le comportement pneumatique ou le fonctionnement d'une machine avant de s'appuyer sur la machine physique complète. Elles peuvent raccourcir un projet d'automatisation pneumatique, mais 73 % ne constitue pas une garantie universelle de réduction du temps de développement. Un article publié sur la mise en service virtuelle évoque une réduction potentielle de 73 % du temps réel de mise en service. Ce résultat concernait une phase de projet et une approche de modélisation particulières, et non toutes les machines pneumatiques ni l'intégralité du calendrier allant de la conception à la production (article du dépôt de l'université de Gand, consulté le 27/07/2026).
Choisissez la solution en fonction de la décision qu'elle doit permettre de prendre. Le test de séquences d'automate, la prédiction de la pression et du mouvement pneumatiques et le jumeau numérique opérationnel sont trois missions différentes. La meilleure plateforme est celle qui modélise le comportement requis, se connecte aux commandes réelles, rend ses hypothèses explicites et réussit un pilote représentatif confronté à des mesures matérielles.
Points clés
- Un gain annoncé de 73 % correspond à une réduction potentielle du temps réel de mise en service, et non à une garantie de réduction du temps total de développement.
- Il faut distinguer les exigences de mise en service virtuelle, de simulation dynamique pneumatique et de jumeau numérique opérationnel.
- Validez la pression, le débit, le mouvement, la temporisation, les E/S, les défauts et le comportement après redémarrage par rapport à des mesures physiques.
- Utilisez un pilote payant et des limites d'acceptation écrites avant de vous engager sur des licences, des bibliothèques de modèles ou des travaux d'intégration.
Que signifie réellement la réduction de 73 % ?
Le chiffre de 73 % est une référence de mise en service virtuelle limitée à un périmètre précis. L'article cité indique que des travaux antérieurs ont fait apparaître un potentiel de réduction de 73 % du temps réel de mise en service grâce à un modèle numérique 3D. Il n'affirme pas que la conception des produits pneumatiques, l'approvisionnement des composants, la fabrication, l'installation, la validation et le délai total du projet diminuent tous de cette même proportion.
Un cas industriel de Siemens montre pourquoi il faut définir la base de comparaison. Wipro PARI a rapporté une réduction de 70 % de la mise en service sur site, tandis que le même cas ne rapportait qu'une réduction de 5 à 10 % du délai de livraison et de 40 à 50 % des retouches (étude de cas Siemens sur Wipro PARI, consultée le 27/07/2026). Les dénominateurs ne sont pas les mêmes.
Définissez l'indicateur avant d'évaluer le logiciel :
| Indicateur | Événement de départ | Événement de fin | Preuves nécessaires |
|---|---|---|---|
| Temps de développement de l'automate | Première tâche du logiciel de commande | Code prêt pour le test formel | Relevés de temps et cas de test acceptés |
| Temps de mise en service virtuelle | Modèle exécutable disponible | Acceptation virtuelle terminée | Effort de construction du modèle et exécution des tests |
| Temps de mise en service sur site | Équipement installé disponible | Réception sur site terminée | Référence d'un projet comparable ou d'un pilote contrôlé |
| Délai total du projet | Exigences approuvées | Libération pour la production | Planning complet, y compris le travail avancé dans le calendrier |
| Retouches | Première conception publiée | Machine finale acceptée | Registre des modifications classées par cause mécanique, électrique, commande et pneumatique |
La mise en service virtuelle avance souvent le travail au lieu de le supprimer. La construction du modèle, le mappage des E/S, la rédaction des cas de test et la maintenance du modèle consomment du temps d'ingénierie. Le bilan économique doit comptabiliser ces heures. Sinon, une visite sur site plus courte peut masquer un effort total d'ingénierie inchangé ou plus long.
L'objectif le plus défendable n'est pas de « réduire le temps de développement de 73 % ». Il consiste à « déplacer un ensemble défini de défauts hors de la phase sur site, puis à mesurer l'évolution du temps sur site, du temps total d'ingénierie, des retouches et de la qualité de l'acceptation ». Cette formulation évite de présenter une amélioration locale comme une économie à l'échelle du projet.
Quelle mission de prototypage numérique la solution doit-elle assurer ?
Le prototypage numérique pour l'automatisation pneumatique couvre généralement trois missions : la mise en service virtuelle, la simulation dynamique du système ou le jumeau numérique opérationnel. La norme ISO 23247-2 fournit une architecture de référence pour les jumeaux numériques de fabrication, tandis que la norme FMI 3.0 définit trois interfaces de modèle : Model Exchange, Co-Simulation et Scheduled Execution (ISO 23247-2 ; FMI 3.0.2, consultées le 27/07/2026).
| Mission | Question principale | Comportement minimal du modèle | Connexion habituelle |
|---|---|---|---|
| Mise en service virtuelle | La logique de commande s'exécute-t-elle dans le bon ordre ? | États des actionneurs, capteurs, interverrouillages, temporisation, défauts, flux de matière | Automate simulé, automate réel, contrôleur de robot, IHM |
| Simulation dynamique pneumatique | La pression, le débit, la force et le mouvement respecteront-ils l'exigence ? | Volumes compressibles, débit des distributeurs, restrictions, frottement, charge, amortissement | Solveur physique, modèle de commande, fichiers de paramètres |
| Jumeau numérique opérationnel | L'état virtuel reste-t-il utile après la mise en service ? | Identité de l'actif, données en temps réel, historique de configuration, étalonnage, incertitude | API/SCADA, historien, OPC UA, registre des actifs |
N'achetez pas les trois simplement parce qu'un fournisseur emploie l'expression « jumeau numérique ». Un modèle de séquence peut représenter un vérin comme sorti ou rentré sans prédire son temps de course. Un modèle détaillé de gaz peut prédire la pression de chambre, mais être trop lent pour un HIL en temps réel. Un tableau de bord en direct peut synchroniser des variables sans contenir de physique prédictive.
Quels comportements pneumatiques le modèle doit-il représenter ?
La norme ISO 6358-1 définit des méthodes d'essai en régime permanent pour les composants pneumatiques utilisant des fluides compressibles. C'est important, car un modèle construit à partir des filetages des orifices et d'une pression d'alimentation nominale ne peut pas prédire le temps de course d'un vérin. Il lui faut des caractéristiques de débit exploitables, les limites de pression, les volumes raccordés, les données de charge et les conditions de fonctionnement du distributeur et de l'actionneur exacts (ISO 6358-1, consultée le 27/07/2026).
Choisissez la fidélité du modèle à partir de la décision à prendre :
| Décision requise | Comportement pneumatique à inclure | Preuves physiques |
|---|---|---|
| Séquence API et logique anticollision | États commandés des actionneurs, capteurs de fin de course, délais crédibles | Liste des E/S, spécification de séquence, plages de délais mesurées |
| Prédiction du temps de course | Volumes des chambres, débit d'alimentation et d'échappement du distributeur, volume des tubes, perte de pression, charge, frottement, amortisseurs | Données de débit du distributeur, dimensions du vérin, courbes de pression, trace de mouvement |
| Vérification de la force de serrage | Surface efficace du piston, pression dynamique minimale, direction de la charge, marge de frottement | Plan maîtrisé, mesure de pression, essai de force |
| Revue de synchronisation | Délai du distributeur, propagation de la pression, décollage, seuil du capteur, scrutation de l'API et mise à jour du réseau | Enregistrements corrélés dans le temps de la commande, de la pression, de la position et des capteurs |
| Étude des pertes d'énergie ou du redémarrage | État de sécurité du distributeur, pression piégée, fuites, charge gravitaire ou ressort, séquence de remise en pression | Circuit, analyse des risques, décroissance de pression, mouvement au redémarrage |
| Surveillance de la dérive en fonctionnement | Paramètres versionnés, qualité des capteurs, état d'étalonnage, environnement, modifications de maintenance | Données historisées, relevés d'étalonnage, journal des modifications |
Le guide sur la constance du temps de réponse des distributeurs explique pourquoi une seule valeur de catalogue ne constitue pas un modèle complet allant de la commande au mouvement. Le guide de dimensionnement d'un distributeur pour un temps de course donné décrit la demande de débit et les restrictions installées qu'un modèle dynamique doit reproduire.
Un modèle CAO fournit la géométrie, les propriétés de masse, les interfaces et les enveloppes de collision possibles. Il ne fournit pas de données validées sur les fuites, le frottement, l'amortissement, le débit, le délai de commutation ou le comportement des joints en fonction de la température. Utilisez la liste de contrôle pour examiner les modèles CAO de vérins pneumatiques avant de considérer la géométrie d'un fournisseur comme prête pour la simulation.
Utilisez la fidélité minimale capable de répondre à la question
Un modèle d'états peut suffire pour vérifier que l'API commande la sortie avant qu'une condition de protection soit valide. Il ne suffit pas pour approuver une exigence de temps de course de 300 ms. À l'inverse, un modèle détaillé d'écoulement tridimensionnel peut ajouter du calcul sans améliorer une décision de séquence à l'échelle de la machine.
Commencez par définir les grandeurs d'intérêt. Il peut s'agir du temps d'arrivée du vérin, de la pression maximale dans la chambre, de la force de serrage minimale, du temps de décroissance à l'échappement, du décalage de synchronisation ou du déplacement maximal au redémarrage. N'ajoutez ensuite des détails au modèle que lorsqu'ils modifient réellement l'une de ces décisions.
Faut-il utiliser le software-in-the-loop, le hardware-in-the-loop, ou les deux ?
Utilisez le SIL pour tester tôt le logiciel de commande et le HIL pour exposer la temporisation réelle du contrôleur, le comportement des E/S et les contraintes de communication. Un programme hybride passe généralement par les deux. La plante virtuelle doit s'exécuter assez rapidement pour la connexion choisie, mais le « temps réel » doit être défini par rapport à la tâche du contrôleur et à la temporisation exigée des événements, et non par rapport à une cible générique en millisecondes.
| Architecture | Matériel de commande réel | Meilleur usage | Limitation principale |
|---|---|---|---|
| Model-in-the-loop | Non | Développement du modèle et de l'algorithme | N'expose pas le comportement de la commande compilée ni du matériel |
| Software-in-the-loop | Non | Logique API, séquences d'états, tests de non-régression | La temporisation et les communications de l'émulateur peuvent différer de celles du matériel |
| Hardware-in-the-loop | Oui | Tâches de l'API réelle, E/S, réseau, IHM, tests de défaut et de redémarrage | Exige une exécution déterministe et une intégration électrique sûre |
| Corrélation sur banc physique | Système partiel | Identification des paramètres et validation du modèle | Ne couvre que la configuration et la plage testées |
| Validation de la machine complète | Oui | Acceptation finale et validation de la sécurité | Intervient plus tard et coûte plus cher à modifier |
Le SIL est généralement la première barrière économique. Il permet des tests automatisés et répétables avant que l'armoire de commande soit disponible. Le HIL devient pertinent lorsque la décision dépend du comportement réel de scrutation du contrôleur, des adaptateurs de communication, de la priorité des tâches, des interfaces du contrôleur de sécurité, des E/S physiques ou du firmware du fournisseur.
La mise à l'échelle du temps virtuel est utile pour les longues séquences et les tests de non-régression, mais elle ne peut pas prouver les performances en temps réel. En HIL, enregistrez le temps d'exécution réel, les échéances manquées, le pas de communication, la gigue et les dépassements du solveur. Si le modèle prend du retard, définissez si la plateforme ralentit le contrôleur, abandonne des mises à jour, extrapole les valeurs ou échoue au test.
Quelles interfaces et normes de données sont importantes ?
La norme FMI 3.0.2 définit Model Exchange, Co-Simulation et Scheduled Execution, tandis que les spécifications complémentaires OPC UA définissent des modèles d'information réutilisables pour l'interopérabilité propre à un domaine. Ces normes répondent à des problèmes différents : FMI conditionne des modèles exécutables et leurs interfaces ; OPC UA organise les informations et services machine que l'on peut découvrir (FMI ; OPC Foundation, consultées le 27/07/2026).
Vérifiez les six couches d'interface :
- Échange de géométrie : CAO native, STEP, JT, liaisons cinématiques, systèmes de coordonnées, identité de configuration et révision.
- Échange de modèle comportemental : version du FMU, type d'interface FMI pris en charge, responsabilité du solveur, unités des variables, événements et protection des paramètres.
- Connexion du contrôleur : API pris en charge, émulateurs, contrôleurs réels, restrictions des API de sécurité, comportement du temps de cycle et licences.
- Mappage des signaux : nommage, types de données, mise à l'échelle, unités, valeurs par défaut, état de qualité, signaux manquants et capacité de comparaison automatisée.
- Informations machine : modèle d'information OPC UA, alarmes, états, données historiques, sécurité et compatibilité avec les spécifications complémentaires.
- Export des preuves : définitions des tests, journaux, synchronisation temporelle, version du modèle, version du contrôleur, comparaison des résultats et piste d'audit.
Le Time-Sensitive Networking d'IEEE peut fournir un comportement réseau borné dans une architecture adaptée, mais il ne s'agit pas d'un protocole universel de mise en service virtuelle. Il ne remplace ni l'interface du modèle, ni la définition sémantique des signaux, ni l'adaptateur du contrôleur, ni le banc de test.
Demandez à chaque fournisseur de démontrer un export et une réimportation. Une diapositive affirmant la « prise en charge de FMI » ne suffit pas si le solveur pneumatique ne peut exporter que des paramètres statiques ou si l'outil récepteur modifie discrètement les unités, les événements, l'interpolation ou les hypothèses du solveur.
L'interopérabilité doit être testée par un aller-retour, et non cochée dans une liste. Exportez le sous-système vérin-distributeur sélectionné, importez-le dans l'environnement de cosimulation cible, modifiez un paramètre contrôlé, exécutez le même test et vérifiez que l'identité, les unités, les événements et les résultats numériques restent traçables.
Comment structurer la vérification et la validation du modèle pneumatique ?
Le NIST indique que la crédibilité d'un jumeau numérique exige une vérification, une validation et une quantification de l'incertitude pendant tout le cycle de vie. La norme ASME V&V 20 définit de même la validation comme la comparaison d'une variable de simulation spécifiée avec une expérience à un point de validation spécifié, en tenant compte de l'incertitude de la solution et des données (NIST ; ASME V&V 20, consultées le 27/07/2026).
Gardez quatre activités séparées :
- Vérification du code : le problème mathématique est-il correctement résolu par l'implémentation ?
- Vérification du calcul : le maillage, le pas de temps, la tolérance du solveur, les événements et la convergence numérique sont-ils adaptés à cette exécution ?
- Validation : le modèle concorde-t-il suffisamment avec les mesures physiques pour la décision visée ?
- Quantification de l'incertitude : quelle influence les incertitudes paramétriques, de mesure, numériques et de forme du modèle ont-elles sur la conclusion ?
Construisez une matrice de validation au lieu de publier un unique pourcentage global d'« exactitude » :
| Grandeur d'intérêt | Condition d'essai | Comparaison | Forme d'acceptation |
|---|---|---|---|
| Temps de course du vérin | Alimentation dynamique minimale, charge définie et commandes de débit | Temps d'arrivée simulé et mesuré | Erreur absolue ou relative maximale |
| Pression de chambre | Échelon de commande dans les deux directions | Courbes de pression corrélées dans le temps | Bande d'erreur et décalage temporel |
| Délai de décollage | Temps d'arrêt, température et charge définis | Délai entre la commande et le premier mouvement | Valeur maximale et répétabilité |
| Amortissement de fin de course | Vitesse, masse et réglage d'amortissement définis | Pic de pression et vitesse en fin de course | Limite du pic et du mouvement résiduel |
| Événement capteur | Position réelle du contacteur et entrée API | Position physique et horodatage de l'événement | Tolérance de position et de temps |
| Perte d'alimentation ou de pilotage | État initial et charge définis | Décroissance de pression et mouvement de l'actionneur | Pression résiduelle et déplacement maximaux |
La validation est liée à une configuration et à une plage de fonctionnement. Une concordance à une pression, une température, une charge ou dans une direction donnée ne prouve pas que le modèle est valable partout. Enregistrez l'enveloppe validée et signalez toute extrapolation en dehors de celle-ci.
Le guide des technologies de détection de position des vérins pneumatiques aide à définir les événements observables avec des capteurs de fin de course et ceux qui exigent une mesure continue de la position. La validation du modèle ne peut pas être plus précise que le système de mesure physique.
Quels tests de temporisation et de défaut un pilote de mise en service virtuelle doit-il réussir ?
Le projet Siemens Wipro PARI modélisait quatre robots, dix centres d'usinage, plus de 100 convoyeurs et appareils associés, ainsi que 17 variantes de produits. Une telle échelle exigeait un zonage, du HIL, l'intégration des robots et des tests explicites des interverrouillages de sécurité, et non une simple animation (étude de cas Siemens, consultée le 27/07/2026).
Pour une cellule pneumatique pilote, testez au minimum :
- la sortie et la rentrée normales depuis chaque état de départ valide ;
- la pression d'alimentation minimale et maximale crédible ;
- un distributeur lent, un capteur retardé, un capteur bloqué et un signal contradictoire ;
- une restriction de débit, un silencieux obstrué, une perte de pression et une perte de pression de pilotage ;
- la commande manuelle et le mode maintenance ;
- la perte de l'alimentation électrique et le redémarrage du contrôleur ;
- l'isolement de l'air principal, la décroissance de pression et la remise en pression ;
- une pièce rejetée, un mécanisme bloqué et un cycle interrompu ;
- le changement de produit et l'incompatibilité de recette ;
- la récupération après chaque défaut injecté sans contourner l'interverrouillage prévu.
Le guide des symboles de distributeurs ISO 1219 aide à aligner les états de ports simulés sur le circuit réel. L'étiquette « distributeur 5/2 » est incomplète si la position normale, le mode de rappel, la source de pilotage, le chemin d'écoulement et le comportement en cas de perte d'énergie ne correspondent pas aussi.
L'acceptation de la temporisation doit placer sur une même base de temps les commandes du contrôleur, l'état simulé du distributeur, la pression, la position de l'actionneur, l'état du capteur et le code défaut. Cette trace permet de distinguer un défaut de logique d'un délai du modèle, d'une restriction pneumatique, d'un seuil de capteur ou d'un problème de communication.
D'après notre expérience, le moyen le plus rapide de révéler les faiblesses d'un prototype virtuel consiste à lancer un cycle depuis un état anormal mais physiquement possible. Un modèle qui ne réussit que depuis sa position initiale privilégiée est utile pour une démonstration, pas pour une mise en service.
Comment traiter les affirmations relatives à la sécurité ?
La norme ISO 4414 traite les dangers significatifs des systèmes pneumatiques et s'applique à la conception, l'installation, le réglage, l'utilisation et la maintenance des systèmes. Les essais virtuels peuvent améliorer la couverture, mais ils ne remplacent pas la confirmation physique de la retenue de la charge, de l'énergie résiduelle, de la décroissance de pression, des performances d'arrêt, du protecteur ou de la fonction de sécurité complète de la machine (ISO 4414, consultée le 27/07/2026).
Gardez les usages liés à la sécurité dans une chaîne de preuves maîtrisée :
- Définissez la fonction de sécurité et l'état requis de la machine à partir de l'analyse des risques.
- Identifiez le contrôleur, le distributeur, l'actionneur, le dispositif de retenue, le capteur, le chemin d'échappement et le comportement de réinitialisation qui y contribuent.
- Utilisez le modèle virtuel pour exercer les séquences, les combinaisons et la couverture diagnostique.
- Signalez chaque comportement physique idéalisé ou non modélisé.
- Confirmez les données des composants et le comportement du circuit sur le matériel.
- Validez la fonction de sécurité installée selon le processus de sécurité des machines applicable.
Un distributeur virtuel à centre fermé peut montrer un mouvement nul du vérin parce que le modèle suppose une fuite nulle. Le distributeur et le vérin physiques peuvent dériver. Une commande d'échappement peut sembler supprimer instantanément la pression alors qu'un distributeur à réglage à l'échappement, un clapet piloté, un silencieux ou un tube long réel retient de l'énergie. Le modèle ne doit pas transformer une physique absente en affirmation de sécurité.
Comment mener un pilote payant avant l'achat ?
Un pilote utile contient une station pneumatique représentative, une décision d'ingénierie réelle et des limites écrites de réussite ou d'échec. Le programme du NIST consacré aux jumeaux numériques met l'accent sur les bancs d'essai, la validation, l'interopérabilité, l'incertitude quantifiée et les résultats traçables, plutôt que d'accepter l'étiquette « jumeau numérique » comme une preuve (Jumeaux numériques du NIST pour la fabrication avancée, consulté le 27/07/2026).
Suivez cette séquence de pilote :
- Figez le circuit maîtrisé, la liste des E/S, les révisions des composants, la plage de fonctionnement et les grandeurs d'intérêt.
- Enregistrez la référence du processus actuel : heures d'ingénierie, heures sur site, défauts, retouches et résultat de l'acceptation.
- Construisez le plus petit modèle capable de prendre en charge la décision choisie.
- Connectez l'API réel ou l'émulateur approuvé et importez le programme de commande de production.
- Exécutez les tests normaux, limites, de défaut, de perte d'alimentation et de redémarrage.
- Corrélez le modèle avec la pression, le mouvement et la temporisation des événements mesurés.
- Modifiez un distributeur, un vérin, un tube, un capteur ou un paramètre du contrôleur, puis recommencez.
- Exportez le modèle, les définitions de tests, les journaux et les résultats ; vérifiez ensuite qu'un autre ingénieur peut les reproduire.
- Mesurez l'effort de construction et de maintenance du modèle ainsi que le temps économisé.
- N'approuvez l'extension que lorsque toutes les barrières écrites sont franchies.
Que doit contenir la demande de devis du logiciel ?
Une demande de devis efficace sépare les capacités exigées des démonstrations facultatives. Spécifiez un modèle pilote, trois niveaux de preuves et une propriété clairement définie : le modèle doit répondre à la question d'ingénierie, reproduire l'interface de commande requise et exporter suffisamment de données pour un examen indépendant. N'évaluez pas une plateforme à la longueur de sa liste de fonctionnalités.
| Champ de la demande de devis | Réponse exigée du fournisseur |
|---|---|
| Usage prévu | Mise en service virtuelle, dynamique pneumatique, jumeau opérationnel ou combinaison définie |
| Périmètre pneumatique | Distributeurs, vérins, conduites, restrictions, fuites, frottement, amortissement, capteurs, charges |
| Périmètre du contrôleur | API pris en charge, émulateurs, matériel réel, robots, IHM, restrictions de sécurité |
| Comportement en temps réel | Pas pris en charge, gestion des dépassements, mise à l'échelle du temps, journalisation, synchronisation |
| Interopérabilité | Formats CAO, version et type d'interface FMI, modèle OPC UA, API, mappage des signaux |
| Validation | Indicateurs d'erreur propres à chaque grandeur, plage d'essai, incertitude, avertissement d'extrapolation |
| Tests de défaut | Conditions de capteur, distributeur, alimentation, pilotage, communication, alimentation électrique, redémarrage et blocage |
| Maîtrise de la configuration | Identité du modèle, révision du composant, source du paramètre, branches, historique d'audit |
| Gouvernance des données | Stockage, conservation, accès, chiffrement, protection de la propriété intellectuelle, fonctionnement hors ligne |
| Automatisation | Script des tests, exécution des non-régressions, rapports de comparaison, intégration CI |
| Modèle commercial | Licences de création, d'exécution, de HIL, de connecteur, de solveur, de cloud et d'assistance |
| Transfert | Formation, propriété du modèle, droits sur les bibliothèques réutilisables, export, délai d'assistance |
| Acceptation du pilote | Station nommée, calendrier, livrables, mesures, limites de réussite ou d'échec |
Demandez au fournisseur d'indiquer ce qui n'est pas modélisé. Les limites utiles comprennent une fuite nulle, des distributeurs idéaux, un frottement fixe, un échappement simplifié, des tubes rigides, l'absence de couplage thermique ou le comportement non pris en charge d'un contrôleur de sécurité. Les simplifications cachées sont plus dangereuses qu'un périmètre de modèle modeste et explicite.
La sélection finale doit consigner une décision pour chaque exigence de la demande de devis : réussi, réussi sous conditions, échoué ou non applicable. Notez la version exacte du logiciel, le solveur, le connecteur, le firmware de l'API, la bibliothèque de composants et la révision du modèle utilisés lors du pilote.
FAQ sur le prototypage numérique des systèmes pneumatiques
La mise en service virtuelle réduit-elle réellement le temps de développement de 73 % ?
Elle peut réduire fortement une phase de mise en service définie, mais 73 % n'est pas un résultat universel. Le chiffre publié concerne une réduction potentielle du temps réel de mise en service avec une approche particulière de mise en service virtuelle 3D. Établissez votre propre référence et comptabilisez séparément la construction du modèle, l'intégration, la rédaction des tests, le travail sur site, les retouches et le délai total.
Un modèle CAO 3D suffit-il pour une mise en service virtuelle pneumatique ?
Non. La CAO fournit la géométrie et une cinématique possible, mais le comportement pneumatique dépend aussi de la fonction et du débit du distributeur, des volumes des chambres et des tubes, des pertes de pression, de la charge, du frottement, de l'amortissement, des seuils des capteurs, des fuites et de la temporisation du contrôleur. Utilisez un modèle d'états pour les tests de logique ou un modèle dynamique validé lorsque la pression et le mouvement sont importants.
Quelle est la différence entre SIL et HIL ?
Le software-in-the-loop exécute le logiciel de commande ou un émulateur sans le matériel du contrôleur de production. Le hardware-in-the-loop relie la plante virtuelle au contrôleur réel et expose les tâches, les E/S, les communications, le firmware et la temporisation réels. La plupart des projets devraient commencer par le SIL, puis réserver le HIL aux risques dépendant du matériel.
Un jumeau numérique opérationnel peut-il rester automatiquement exact ?
Non. Un jumeau utile exige une identité maîtrisée du modèle et des actifs, des données fiables de capteurs, un étalonnage, une gouvernance des paramètres, une détection des modifications, des limites de validation et un rapport d'incertitude. Le remplacement d'un composant, des réglages modifiés, l'usure, la dérive d'un capteur, les révisions logicielles ou l'évolution des conditions de fonctionnement peuvent invalider les prédictions même si les variables en direct continuent de se mettre à jour.
Les essais virtuels peuvent-ils remplacer la validation physique de la sécurité pneumatique ?
Non. Les essais virtuels peuvent améliorer la couverture des défauts et détecter tôt les défauts de séquence, mais ils ne peuvent pas prouver les fuites réelles, la pression résiduelle, la retenue de la charge, les performances d'arrêt, le comportement à l'échappement, le protecteur ou l'intégrité de sécurité de la machine installée. Utilisez-les comme un niveau de la chaîne de preuves, suivi d'une validation matérielle et au niveau de la machine.
Sources et références techniques
Université de Gand et Flanders Make : Virtual Commissioning of Industrial Control Systems: A 3D Digital Model Approach, périmètre et contexte de la réduction potentielle annoncée de 73 % du temps réel de mise en service. Consulté le 27/07/2026.
Siemens Digital Industries Software : étude de cas de mise en service virtuelle de Wipro PARI, périmètre du projet et résultats rapportés séparément pour la mise en service sur site, le délai de livraison et les retouches. Consulté le 27/07/2026.
NIST : Jumeaux numériques pour la fabrication avancée, normes, bancs d'essai, interopérabilité, VVUQ et jumeaux numériques de fabrication fiables. Consulté le 27/07/2026.
NIST : Considérations de crédibilité pour les jumeaux numériques dans la fabrication, vérification, validation, quantification de l'incertitude et crédibilité sur le cycle de vie. Consulté le 27/07/2026.
ISO : ISO 23247-2:2021, architecture de référence des jumeaux numériques de fabrication. Consulté le 27/07/2026.
Modelica Association Project : spécification FMI 3.0.2, interfaces Model Exchange, Co-Simulation et Scheduled Execution. Consulté le 27/07/2026.
OPC Foundation : spécifications complémentaires OPC UA, modèles d'information propres aux domaines et interopérabilité OPC UA. Consulté le 27/07/2026.
ASME : V&V 20, comparaison de validation et incertitude pour la dynamique des fluides numérique et le transfert thermique. Consulté le 27/07/2026.
ISO : ISO 6358-1:2013, caractérisation du débit en régime permanent des composants pneumatiques utilisant des fluides compressibles. Consulté le 27/07/2026.
ISO : ISO 4414:2010, règles générales et exigences de sécurité pour les systèmes et composants pneumatiques. Consulté le 27/07/2026.