club offreurs
(Version imprimable du 15/09/2006 12:03)
Partis de quelques écrans graphiques au début des années 80, les logiciels de supervision sont aujourd’hui indissociables du développement de « l’informatique industrielle » dans les unités de production. Pour mieux le comprendre, il n’est pas inutile de faire un bref historique de leur évolution.
A l’origine, on n’attendait des logiciels de supervision le remplacement des grands synoptiques muraux remplis de LED clignotantes, style films de science-fiction des années soixante-dix, par quelque chose de plus facile à mettre en place et à faire évoluer, d’où le nom de « supervision ». Surtout rien de plus ! Dans l’industrie, les automates programmables venaient à peine de conquérir leurs lettres de noblesse face aux armoires à relais, il n’était pas question de faire confiance à des PC peu fiables pour piloter une usine.
Malgré la fascinante séduction du graphisme, qui a accompagné la pénétration de Windows dans l’industrie, d’autres fonctionnalités sont venues compléter utilement la simple visualisation. Ce furent d’abord les journaux d’alarmes, imprimés en fil de l’eau puis progressivement stockés sur le PC sous forme électronique, avec le développement de fonctions de plus en plus sophistiquées de sévérité et d’acquittement. Puis l’enregistrement de mesures, avec les courbes de tendances, dont les fonctions d’exploitation (multi-échelles, zoom, exploitation d’archives, ..) ont peu à peu sonné le glas des enregistreurs papier. Puis la prédominance incontestée de l’automate dans la conduite du procédé a reculé d’un cran avec les recettes ou fiches de consignes : le paramétrage du procédé, sinon son exécution, avait été confié au PC ! Aujourd’hui, dans les systèmes batch de type S88, le programme sur PC orchestre toutes les grandes étapes du procédé, laissant à l’automate l’exécution des phases élémentaires. Il faut dire que l’informatique industrielle est aujourd’hui beaucoup plus fiable, et que des systèmes évolués de redondance (hardware ou software), ont augmenté considérablement son taux de disponibilité.
Soumis à une forte compétition, les éditeurs de logiciels de supervision ne se sont pas arrêtés là. La course aux fonctionnalités « connexes » à la supervision a commencé, avec le développement de fonctions « d’aide à la maintenance », comme le comptage des temps d’arrêts, de marche, l’établissement de diagramme de Pareto, et de fonctionnalités dites de SPC (Statistic Process Control). Ces fonctions mises à disposition des utilisateurs ont stimulé leur imagination. Ceux-ci ont réclamé des bilans de production, des indicateurs de performance…etc. Dépassés par les événements, la plupart des éditeurs de logiciels ont jeté l’éponge : ils ont mis à disposition du développeur d’application un langage puissant, souvent de type Visual Basic, pour qu’il programme ses propres fonctions.
De là à utiliser ce langage pour le développement des fonctionnalités de MES, il n’y a qu’un pas. Alors pourquoi ne pas le franchir ?
Tout d’abord on peut se poser une question : pourquoi les éditeurs de logiciels de supervision n’ont-ils pas utilisé ce même langage pour développer leur superviseur ? Raison historique dira-t-on ? C’est peu probable. Les éditeurs qui abordent aujourd’hui des projets de grande ampleur choisissent Java ou C++, très rarement un langage de type VB. Ce dernier langage est plus adapté à ce que l’on nomme la « glue », souvent nécessaire pour lier entres elles des fonctions déjà réalisées ou en adapter la présentation à l’écran. Est-ce ainsi que le MES, sur lequel va reposer l’efficacité l’outil de production, doit être considéré ?
Ainsi vu comme une « excroissance » de l’outil de supervision, le MES ne pourra mettre en place sa structure propre. Les travaux de la S95 montrent clairement que le MES repose sur un modèle de données, comment le mettre en place et le faire évoluer avec une méthode de développement qui n’a pas été conçue dans ce but. Le risque est un compromis constant avec les fonctions effectivement disponibles dans le superviseur et une programmation peu structurée, difficile à maintenir.
Mais le principal paradoxe de cette démarche est que l’on se trouve entraîné dans un véritable développement informatique, car les fonctions MES ne sont pas partie intégrante du superviseur. En définitive, le seul apport du logiciel de supervision est l’IHM et l’accès aux données de terrain, tout le MES reste à faire. La problématique est celle d’un développement spécifique de MES , sans en avoir les outils adéquats.