Mettre en place des technologies de communication par bus de terrain, c’est bien mais encore faut-il être capable de paramétrer, de maintenir et de diagnostiquer une installation de la même façon quel que soit le bus de terrain installé ou l’équipement de terrain utilisé.
Ce rêve des utilisateurs est-il en passe de devenir un nouveau cauchemar ? Lorsque Siemens a annoncé sa volonté de se tourner vers EDDL, certains ont cru défaillir. Depuis, la tension est tombée d’un cran, apaisant quelque peu le milieu. C’est dans cet esprit serein, qui préfigure sûrement d’autres explosions, que nous allons tenter de présenter les protagonistes.
A ma droite vous avez les fervents partisans d’EDDL et à ma gauche ceux de FDT/DTM (si les emplacements vous posent problèmes vous les pouvez inverser, la problématique restera la même).
Mais le choix de droite et gauche a l’énorme avantage de n’être ni avant, ni après l’autre ou ni en-dessous, ni en-dessus. Car l’un des arguments des parties reste justement le positionnement des uns vis à vis des autres.
Votez à droite
A ma droite donc EDDL. A l’origine on trouve DDL, un langage basé sur le texte employé pour décrire des données dans un équipement de terrain et utilisé par des applications hôtes (PC, Pocket…) pour par exemple configurer, faire les synchronisations, surveiller ou diagnostiquer. Il en ressort un fichier DD, écrit en langage DDL qui décrit les données d’un équipement, mais il ne s’agit en aucune manière d’un code exécutable.
Les DDs permettent aux équipements de différents constructeurs de fonctionner avec une seule version de PC ou de Pocket. De même, l’application sur PC ou Pocket utilise le même DD. C’est l’une des caractéristiques des DDS d’être indépendants du système d’exploitation et du protocole de communication. Un nouveau DD ne perturbe pas les applications existantes, et les DDs supportent Hart, Profibus ou Fieldbus Foundation..
Apparu au début des années 90, DDL est utilisé par la grande majorité des instruments avec d’après Emerson plus de 14 millions d’équipements l’utilisant.
En parallèle, est apparue la standardisation IEC 61804 avec ses blocs de fonctions pour le Process Control. Cette normalisation a permis au trois langages que sont Hart, Fieldbus Foundation et Profibus d’avoir des DDL à 95% identiques. Et comme l’IEC 61804-2 était un sur-ensemble de spécifications des trois versions de DDL, elle a été appelée Electronic Device Description Langage, soit EDDL.
Dans le même temps, les descriptions ont évolué pour conduire au développement d’équipements et d’applications plus complexes, comme la signature de vanne, les courbes d’étalonnage de capteur, l’affichage, la gestion des données magasin… avec une extension aux interfaces utilisateurs et aux résultats de diagnostics.
Le projet de protocole approuvé en 2002 prévoyait d’utiliser l’IEC 61804-2 comme fondation et de protéger la base installée en ne changeant pas les DDs existants. Parmi les améliorations tenant compte des exigences pré-cités on notera une interface utilisateur améliorée avec une organisation des paramètres, un support de courbes et de graphiques pour visualiser des données complexes et les stockages persistants des données.
L’interface utilisateur est fonction du système hôte, le même équipement peut avoir différentes présentations sur des systèmes hôtes différents, du coup tous les équipements sur un système donné auront la même présentation.
Les défenseurs d’EDDL citent pour principal argument l’indépendance de l’OS du système hôte, l’indépendance vis à vis du protocole, et d’avoir un seul environnement pour la configuration, la synchronisation ou la gestion de n’importe quel équipement.
Avec une telle présentation, l’article devrait être fini. Mais vous avez oublié qu’il ne s’agissant que de la main droite. Voyons ce que contient la gauche.
2 schémas
Votez à gauche
A ma gauche les défenseurs de FDT/DTM. En tant qu’idée FDT a vu le jour il y a sept ans à la ZVEI (confédération générale industrielle d’électronique et d’électrotechnique). C’est l’abréviation de Field Device Tool, qui définit les interfaces et mécanismes qui permettent le déroulement du DTM (Device Type Manager). FDT n’est ni un protocole de communication ni un bus de terrain. Il accepte Profibus, Hart, Fieldbus Foundation et bientôt, avec l’arrivée de Rockwell Automation, DeviceNet, mais aussi Interbus.
Le système gère les interfaces entre l’applicatif FDT et le DTM spécifiques à chaque instrument. Par DTM on entend un pilote pour instrument (capteur, vanne…) ou objet de communication (passerelles, cartes…).
FDT/DTM se veut une solution d’intégration des appareils dans les outils Windows, pour l’exploitation dans son ensemble et pendant toutes les phases du cycle de vie d’une installation. Le concept peut être comparé à la mise en œuvre d’une imprimante dans un environnement Windows, le driver intégrant la configuration ainsi que les utilitaires et les fonctions de diagnostic.
Chaque fabricant développe pour son équipement un fichier descriptif (le DTM). Les DTM des équipements actifs dans le process sont appelées DeviceDTM, ceux qui n’ont qu’un rôle de communication s’appellent CommDTM. Il peut se contenter de fournir un paramétrage basique, mais peut aussi donner accès à des fonctions de diagnostic ou de maintenance sophistiquées. Il reste obligatoire de disposer d’une DeviceDTM pour chaque appareil, bien entendu si le fournisseur n’en livre pas, l’appareil pourra néanmoins être configuré, mais sur la base de profils standards.
Tout ce qui relève de l’instrument est du domaine de DeviceDTM, le FDT Frame n’est qu’un container qui active le DTM nécessaire, et la communication est du domaine du CommDTM, FDT Frame servant de routeur pour acheminer l’information. Pour fonctionner un atelier logiciel FDT doit comprendre au minimum un système FDT Frame, un CommDTM et un DeviceDTM.
La spécificité de FDT est de couvrir un ensemble large qui comprend certes les capteurs et vannes, mais également les entrées-sorties déportées, les variateurs, les passerelles de communications… le tout en utilisant les technologies Microsoft. Et c’est ici que les divergences apparaissent.
Si les DeviceDTM et CommDTM sont comparables aux pilotes utilisés par les périphériques, il n’y a aucune dépendance par rapport au hardware de l’ordinateur. A l’inverse les logiciels FDT et DTM sont des programmes qui auront besoin en cas de nouvel environnement d’être installés comme le sont les programmes applicatifs de bureautique. Il reste le risque, peu probable, mais qui sait, de voir un jour Microsoft laisser tomber la technologie Com, qui reste la base de toute la pyramide. Jusqu’ici, la société américaine consciente des effets pervers d’un tel choix à toujours proposé des stratégies de migration (Dos fonctionne toujours sous XP).
Un schéma
Ou votez au centre
Présenté aussi rapidement, les deux solutions semblent quelque peu identiques, et donc concurrentes, alors qu’en « bons princes » les spécialistes parlent plutôt de complémentarité.
Au début des années 2.000, les spécialistes s’attendaient à une coupure franche entre les partisans de EDDL et de FDT/DTM. D’un côté on retrouvait les partisans de Profibus et de l’autre ceux de Fieldbus Foundation, une séparation logique entre les deux principaux bus de terrain utilisés dans le process.
Manque de chance, après Emerson favorable à Fieldbus Foundation qui annonce en 2004 son choix de EDDL, c’est Siemens, « profibusien » par naissance, qui choisit également de concentrer ses efforts sur EDDL. Bien entendu, dans le cas d’EDDL on comprend le choix d’Emerson à l’origine de la technologie DDL et du protocole Hart de ne pas se lancer dans le FDT/DTM. Siemens pour sa part s’était engagé dès le début dans les développements de la technologie FDT/DTM. D’ailleurs ce dernier précise qu’il n’a rien contre la technologie FDT/DTM, mais que pour l’instant il souhaite rester avec la technologie DDL.
A l’inverse Endress+Hauser ou ABB continuent les développements de FDT/DTM. Le dernier en date à venir donner de la voix sur le sujet, c’est Rockwell qui annonce vouloir travailler sur une solution utilisant tout aussi bien EDDL et FDT/DTM et cela en partenariat avec Endress + Hauser. D’ailleurs, ce dernier dans un communiqué précurseur en Juin 2004, annonçait que la clé résidait dans la combinaison d’EDDL et de FDT « Nos fichiers DTM sont élaborés à partir des fichiers standards DD. Le processus de fabrication du DTM va ajouter aux fonctions habituelles proposées par le DD, toutes les fonctions de configuration et de diagnostic ».
Olivier Ledey de chez Omron rappelle que les spécifications et caractéristiques de FDT/DTM autorisent le paramétrage de n’importe quel réseau de terrain via un seul logiciel de paramétrage. Puisque les DTM sont des programmes, leurs fonctionnalités peuvent être étendues. « Omron a mis au point un DTM qui interprète les fichiers GSD propres au réseau de terrain Profibus. Un prototype déjà fonctionnel permet d’interpréter les fichiers EDS du réseau de terrain DeviceNet. Il est ainsi possible de configurer un réseau à partir du moment où le DTM est créé et ce, quel que soit le type d’information en provenance de l’équipement à paramétrer. Ainsi, les fichiers de type GSD, EDS ou EDDL, peuvent être traités à partir du moment où il est possible de créer un interpréteur DTM ». En fait, un seul outil logiciel de paramétrage pour tous les réseaux de terrains. Et Omron annonce supporter n’importe quel standard sur FDT/DTM.
De l’autre côté Emerson est moins consensuel dans ses communiqués. Il annonce que « la technologie DDL éprouvée surpasse la technologie FDT/DTM car elle colle bien aux besoins des utilisateurs finaux, comme la liberté de choix des équipements, la liberté des affichages… FDT/DTM manque encore de références ». De plus, « FDT exige d’effectuer une mise en œuvre à l’aide d’un système d’exploitation Windows et repose sur la technologie Com/Dcom qui ne permet pas l’échange de données en temps réel. Ces technologies ont été étendues pour répondre à cette exigence ». N’en jetez plus.
Pour sa part Anton S.Huber, vice-président A&D de Siemens, dans une interview à notre confrère CHEManager Magazine précise à la question quels sont les inconvénients de la technologie DTM ?, « qu’aujourd’hui les équipements de terrain se caractérisent par des durées de service importantes, et des technologies stables. Ils sont parfaitement intégrés au système de contrôle par le biais d’un fichier de description électronique, l’EDD (Electronic Device Description). Si les utilisateurs implémentent la technologie DTM dans le but d’intégrer leurs équipements de terrain existants, il semble honnête d’avertir ces personnes qu’ils vont connaître des désagréments. Les DTM sont des composants logiciels, semblables à des drivers, implémentés dans la partie software du système de contrôle.
Dans la pratique, les problèmes de compatibilités que cela occasionne ne peuvent être complètement évités. De plus, dans l’avenir l’intégration des équipements sera sans doute en partie définie par les technologies de Microsoft, qui possèdent un cycle d’innovation beaucoup plus court. Dans l’avenir, les utilisateurs vont avoir à payer, directement ou indirectement, pour les logiciels accompagnant leurs équipements. Ce coût reste aujourd’hui difficile à quantifier. En conséquence, les mises à niveaux et nouvelles versions de DTM vont générer des coûts additionnels tout au long du cycle de vie de l’appareil ».
Pour le responsable de Siemens, « EDDL est préparée pour l’avenir. En ce qui concerne les équipements de terrain, nous n’avons pas connaissance à ce jour de fonctions vitales qui ne peuvent être implémentées. Dans l’avenir proche DTM n’apportera pas de bénéfices substantiels suffisants, justifiant l’augmentation de la complexité induite par son utilisation ».
Notre confrère conclu son interview en demandant quelle est la stratégie de Siemens concernant DTM ?La réponse ne se fait pas attendre « Nous adhérons à la classification établie par Profibus International et recommandons l’utilisation de DTM uniquement dans le cas de systèmes d’entrées-sorties complexes. L’instrumentation de process n’appartient pas à cette catégorie ».
Fabien Hantzer, chef de marché systèmes et réseaux chez Endress+Hauser qui est membre fondateur du consortium FDT-JIG, reste quant à lui persuadé que, « FDT/DTM est aujourd’hui le seul moyen pour un client de tirer tout le parti de l’intelligence embarquée dans les instruments et équipements numériques sans perdre en liberté ». Et de préciser » c’est également l’opportunité pour des « petits » constructeurs de mettre sur le marché des matériels innovants sans investir dans le développement et la maintenance d’un outil de configuration et d’exploitation en propre. Il suffit de réaliser un seul DTM pour que l’équipement s’intègre de la même manière dans les différents outils FDT disponibles sur le marché ».
Et à la question liminaire de savoir quelle est sa position sur le débat EDDL-FDT/DTM, il répond » Assis en tailleur, dans la position dite du Lotus, serein et Zen ! ».
