Systèmes d'aide à la conduite des procédés industriels

Mec. Ind. (2000) 1, 447–455 2000 Éditions scientifiques et médicales Elsevier SAS. Tous droits réservésS1296-2139(00)01056-3/FLA

Systèmes d’aide à la conduite des procédés industriels

François-Marie Lesaffre a, Claude Thirion a*, Laurent Baudouin b

a SACHEM, Pole Informatique Avancé d’USINOR-SI, Franceb Bull Méditerranée, France

(Reçu le 7 juillet 2000 ; accepté le 6 septembre 2000)

Résumé —Pour la réalisation de ses systèmes d’aide à la conduite intégrant le savoir-faire de ses meilleurs experts, USINOR a mis aupoint l’environnement de développement Process Works. Il est à la fois un langage permettant de déclarer les connaissances à l’œuvredans la conduite des procédés : modèles, perception, raisonnements, proposition d’actions, et à la fois un environnement couvrantles diverses étapes des cycles de vie des logiciels et de connaissances. Dix systèmes sont, à ce jour, en exploitation industrielle ouen développement avec Process Works. 2000 Éditions scientifiques et médicales Elsevier SAS

process control / knowledge management / framework / ingénierie de connaissance

Abstract —For the purpose of developing knowledge-based systems in its industrial processes, USINOR have set up the Process Worksenvironment. Process Works is, on one hand, a language for describing the process control knowledge: physical and empirical models,perception and pattern recognition, reasoning and recommending actions. On the other hand, it is a framework which supports thewhole life-cycle of knowledge as well as software development. Eight systems powered by Process Works are now in operation. 2000Éditions scientifiques et médicales Elsevier SAS

process control / knowledge management / framework / knowledge engineering

1. INTRODUCTION

Rendre la connaissance disponible au bon moment aubon endroit sous la bonne forme est une tâche crucialeque l’industrie occidentale entreprend — ou a entrepris— si l’on en juge par la vogue actuelle que connaît leKnowledge Management. USINOR n’a pas attendu lamédiatisation actuelle pour entreprendre ces actions decapitalisation opérationnelle et a lancé à la fin des an-nées 80, deux actions complémentaires : un schéma di-recteur des applications d’ingénierie de connaissances etle projet SACHEM [1] dont l’objectif opérationnel est dedisposer d’un système d’aide à la conduite pour les opé-rateurs des Hauts-Fourneaux du Groupe. Du succès del’opération dépendait la mise en œuvre du deuxième ob-jectif — plus stratégique — celui de constituer un pôlede compétence capable de mettre en œuvre, sur l’en-semble des procédés et des connaissances du Groupe,des systèmes opérationnels ayant la vocation de favoriser

* Correspondance et tirés à part :[email protected]

les avantages concurrentiels d’USINOR (aciers de hautequalité) autrement dit de créer de la valeur. Quand, en1996, les exploitants des hauts-fourneaux ont constatéune diminution des incidents process d’un facteur 3,l’heure était venue de réutiliser le savoir-faire, les mé-thodes et les outils développés dans le cadre de SACHEMpour les autres procédés (revêtement, coulée continuepar exemple). Cet ensemble a été baptisé Process Works(PW), comme un raccourci d’Intelligent Process ControlFramework qui dénote la fonction dévolue à cet environ-nement de développement.

2. QU’EST CE QU’UN SYSTÈME D’AIDEÀ LA CONDUITE EN MILIEUINDUSTRIEL?

2.1. Le besoin : aider l’opérateurdans la maîtrise des processus

Nous entendons par cela un système aidant l’opérateurde process à conduire au mieux le processus industriel (defabrication par exemple) dont il est en charge.

447

F.-M. Lesaffre et al.

Figure 1. Le système d’aide conçu comme un agent rationnel.

On observe d’une part que certains opérateurs sontplus efficaces que d’autres dans l’analyse process et dansla conduite (i.e. l’action) et, d’autre part, que le tempsaffecté à l’analyse en situation de conduite est à la foisréduit et fragmenté (8 % du temps par tranche maximumde 2 à 3 minutes dans le cas de la conduite du haut-fourneau). « Analyse process » est entendu ici commel’activité qui vise à comprendre le processus physiqueen cours et son évolution afin d’être en mesure d’agirpour atteindre les visées process (ou maintenir le proces-sus dans ses visées). Les visées représentent les buts del’organisation en charge du processus : elles concernentla production (tonnage, consommations), le produit (qua-lité) et le procédé lui-même (capabilités, sécurité, fiabi-lité).

Des deux observations faites, et si l’enjeu économiquele justifie, il devient intéressant de disposer d’un systèmedans lequel la connaissance des meilleurs opérateurs (quenous appelleronsexpertspar la suite) soit disponible24/24, 7 jours sur 7 pour l’opérateur en salle de contrôlede façon à ce que le temps réduit d’analyse soit consacré àdéterminer la meilleure action à mener dans une situationreconnue plutôt que de tenter — imparfaitement —de la reconnaître. Les enjeux relèvent de la maîtriseaccrue du procédé qui permet d’améliorer la régularitédu process [1].

Défini pour être le compagnon de l’opérateur, le sys-tème d’aide est conçu comme un agent rationnel [2]( figure 1).

Les données sont les mesures provenant du procédé.Les buts et stratégies de l’organisation en charge duprocédé sont transmises au système sous forme de visées(cf. supra). Ses sorties sont les informations produites àdestination de l’opérateur : alarmes et recommandationsd’actions. Son contenu, ce sont les connaissances quiy sont mises : meilleures elles seront, meilleur sera leservice.

2.2. Les propriétés attenduesdu système d’aide à la conduite

On examinera ici ce qu’est en droit d’attendre l’utili-sateur (et nous entendrons ici, à la fois l’opérateur et ledonneur d’ordre) du système qu’il met en œuvre.

La première des propriétés attendues relève duservicerendu : il faut que le système s’acquitte du rôle quilui est dévolu comme compagnon de l’opérateur. Cerôle est défini par trois éléments : les missions viséespar l’implantation du système, la distribution des tâchesintelligentes et la capacité que l’on a d’automatiser ounon certaines de ces tâches. La distribution des rôles etde l’initiative est appelée coopération [3].

La deuxième concerne laperformancedu système etdont nous prendrons l’acception « compétence en acte ».Les connaissances dont le système est doté doivent êtrecorrectes, opérationnelles et complètes (au sens où il nepeut se trouver dans unno man’s land). L’opérateur at-tend notamment qu’il soit capable de porter un jugementsur la qualité des données, autrement dit leur caractèrevalideou non pour les raisonnements.

Le donneur d’ordre y rajoutera une dimension d’en-treprise, lagénéricité, à savoir que les connaissances doi-vent être les mêmes quelle que soit la ligne de fabrica-tion visée dans un métier donné, de telle sorte à ce quel’investissement consenti soit mieux rentabilisé et main-tenu tout en ayant une meilleure garantie de robustessedes connaissances mises en œuvre.

Enfin, l’utilisateur est en droit de disposer d’un sys-tème fiable. Cela s’exprime par le taux de service(> 99 %) et par la capacité temps-réel du système, i.e. queles messages à destination de l’opérateur arrivent dans letemps compatible avec celui du processus.

Ces diverses exigences représentent le caractèreuti-lisable du système d’aide. C’est la condition nécessairepour qu’il soit effectivementutilisé et, finalement,utileautrement dit rentable.

2.3. Architecture

Le fonctionnement de base d’un système d’aide estde transformer (à l’aide de connaissances) beaucoup dedonnées pauvres en information en peu de données richesen information. La conception consiste donc à définirune succession de modules (figure 2) permettant cetteconcentration.

448


Figure 2. Architecture fonctionnelle.

On trouvera donc :

• un module d’acquisition (interface avec les BD pro-cess) ;

• un module de calcul dans lequel seront embarqués lesmodèles physiques existant (voir paragraphe 3.2.1) ;

• un module de perception dont le rôle est d’assurerla transformation numérique symbolique, en simulant laperception experte (reconnaissance de formes) ;

• un module de raisonnement qui consiste à agréger lesreconnaissances élémentaires pour produire les alarmeset les recommandations d’actions filtrées et adaptées àl’état courant du processus ;

• un module d’interface assurant l’interaction avecl’opérateur, conçu à partir de la métaphore du journal :la une, les pages intérieures et lewhat’s new(car l’opéra-teur n’est pas accroché à son écran).

La fonction d’invalidation des données et des signauxest distribuée dans ces différents modules. Elle est activeet présente dans toute la chaîne de production de l’in-formation avec, pour mission, de chercher à «prouver lefaux » : tant qu’on n’a pas trouvé de raison de ne pas uti-liser de telles données, elle est considérée comme exploi-table par les raisonnements. Cela s’accompagne nécessai-rement de facilités de raisonnement de substitution pourassurer le service.

3. L’ENVIRONNEMENT DEDÉVELOPPEMENT PROCESS WORKS

Le cycle de vie des connaissances est symbolisé dansla figure 3. L’objectif visé, nous l’avons vu, est de mettreen œuvre les connaissances expertes dans le système (oul’environnement) d’aide à la conduite.

Figure 3. Cycle de vie des connaissances : de la découverte àla mise en opération.

Pour ce faire, il est nécessaire de disposer d’un envi-ronnement de développement adapté. Notons la nécessitéde disposer d’un troisième environnement, pour l’expert,permettant la découverte de nouvelles connaissances (oul’amélioration des connaissances existantes). Les lacunesexistantes du système d’aide font partie, d’ailleurs, dessources orientant les travaux d’étude.

Process Works est l’environnement de développementqui supporte le cycle de vie des connaissances desprocess industriels (voirfigure 6).

3.1. Les propriétés attendues del’environnement de développement

La cible visée est unframework [4], c’est-à-direune semi-application réutilisable. Les intérêts sont mul-tiples [5] : technique, marketing, budgétaire, managérialet économique. Nous examinerons une des motivations,qui probablement les fédère toutes : celle de la producti-vité.

449


Figure 4. Exemple d’évolution du rapport coût métier/coûttotal avec PW.

Pour réaliser ceframework, nous avons extrait del’ensemble des codes SACHEM les parties réutilisables.Elles ont été localisées et rendues disponibles, dans unenvironnement logiciel intégré, pour le développement debases de connaissances de nouveaux métiers.

3.1.1. Assurer la productivité du cycle

On considère que les projets de développements neufsconsacrent environ 30 % de leur effort au métier et 70 %à l’informatique de base. L’objectif visé est d’inverser latendance voire d’arriver à ce que pour le développementd’un système d’aide, l’effort soit consacré à 80 % auxconnaissances métier.

Le gain attendu se trouve bien entenduin finedans lecoût total. Si l’on émet l’hypothèse que le coût métier estconstant, re-développer l’ensemble pour chaque systèmeaugmenterait les coûts globaux d’un facteur 2,3.

Examinons également le délai d’obtention du service :dans le cas étudié enfigure 4, la première version anécessité 9 mois de développement (mars à décembre1999) en réutilisant les codes mis au point pour leprojet SACHEM qui, lui, a nécessité environ 6 ans dedéveloppement.

Du point de vue de l’organisation en charge desréalisations, minimiser les délais requiert de parallélisersignificativement les développements ce qui milite, sibesoin en était, pour la réutilisation de composants dansun environnement de gestion logiciel approprié.

3.1.2. Disposer d’un modèle clair

Il est nécessaire de disposer d’un modèle de déve-loppement clair et pertinent. Celui de Process Works( figure 5) est basé d’une part sur la distinction des ni-veaux logiques de développement et d’autre part sur laséparation, habituelle en intelligence artificielle, des mé-canismes et des connaissances auquel nous avons rajoutéla dimension du paramétrage, essentielle dans la philoso-phieframework.

Figure 5. Le modèle de développement de Process Works.

Séparer les niveaux de développement.Le niveaucommun est celui de l’aide à la conduite. Il comportel’ensemble des concepts et des mécanismes permettantleur exécution. Dans le vocabulaire KADS [3], il proposelesstructures d’inférence. L’analyse générale de l’exper-tise du projet SACHEM a été menée, en 1991, dans uneperspective résolument abstraite et réutilisable afin de ga-rantir la robustesse des modèles. L’applicabilité à des pro-cédés autres que le haut-fourneau en est la conséquencelogique. Le contenu en est détaillé au paragraphe 3.2.2.

La réalisation d’une base de connaissance génériquemétier se fait au niveau intermédiaire. C’est là où l’ontrouve ledomaineet lastratégie(au sens KADS), voirecertainesstructures d’inférenceproprement métier.

Enfin l’instanciation sur une ligne de fabrication (unhaut-fourneau par exemple) se fait par paramétrage :configuration technologique, géométrique et instrumen-tale ; configuration de conduite (la manière d’utiliser lesystème d’aide) et le paramétrage expert applicable à laligne.

Distinguer les modes de programmation.On distin-guera classiquement les mécanismes d’interprétation etde contrôle des connaissances des bases de connaissanceselles-mêmes. On ne reviendra pas sur les avantages de cemode de programmation [6]. Nous avons rajouté la di-mension du paramétrage en tant que mode de program-mation — marque de fabrique duframework— qui a vo-cation à être le mode central du développement d’appli-cations sous Process Works (PW).

Synthèse. Le modèle de développement PW con-siste à associer à chacun des niveaux de développementdes modes de programmations adaptés (cf.figure 6).C’est ainsi que :

• les mécanismes ne peuvent être développés qu’auniveau « Aide à la Conduite ». Autrement dit, ils doivent

450


Figure 6. Production d’un système d’aide à la conduite avec Process Works.

êtreréutilisablespour des procédés autres que celui pourlequel il a été réalisé ;

• le niveau « Métier » comporte les bases de connais-sancesgénériquesdu métier considéré ;

• ces connaissances sont instanciées au niveau « Ligne »par paramétrage. L’interdiction faite de développer desconnaissances spécifiques à une ligne garantit la géné-ricité voulue pour les raisons développées dans le para-graphe 3.1.1.

3.2. Le langage de l’aide à la conduite

Process Works doit d’abord offrir, pour le dévelop-peur, un langage de développement permettant de réaliserdes systèmes d’aide à la conduite.

3.2.1. Les classifications desconnaissances utilisées

L’objet du langage est de permettre le développementet le paramétrage des connaissances d’aide à la conduite.On peut les examiner de plusieurs points de vue.

Figure 7. Les modèles heuristiques encapsulent les modèlesscientifiques.

Modèles scientifiques et modèles heuristiques.Lesprocédés sont déjà en grande partie conduits à l’aide demodèles physico-chimiques plus ou moins expérimen-taux. Ils conviennent assez bien pour les cas parfaits oustatiques mais prennent peu en considération la dyna-mique. Ce sont essentiellement des bilans (matière, éner-gie, chimie). Ils possèdent en outre, un domaine d’appli-cation ou de validité.

Ils sont mis en œuvre dans le système d’aide à laconduite en tant que connaissance associée avec leurconnaissanced’utilisation, i.e. les heuristiques expertes( figure 7).

451


TABLEAU I

Concept FonctionnalitésVariable − calcul (y.c. modèle)

− invalidation/susbstitution− synchronisation

Evénement − analyse de signal et reconnaissance de formes− adaptativité

Phénomène − raisonnement temporel− invalidation/incohérences− gravité contextuelle− comportement

Vue − métaphore du journal

De la perception jusqu’à l’action. La connaissanceexpert s’appuie d’abord sur laperceptionde formes si-gnificatives pour le process, de ruptures de comportementdans le signal. Ces formes élémentaires sont ensuite as-semblées pour produire un phénomène, c’est la phase deraisonnement. Il s’agit ensuite de porter unjugementsurla gravité de l’état ainsi détecté, qui peut inciter à conce-voir uneaction.

Raisonnement temporel.Le raisonnement est tem-porel dans le sens où il gère explicitement la notion detemps [7] et l’on trouvera donc des connaissances de typecausal ou de type prévision. Il comporte également unedimension temps-réel (cf. paragraphe 2.2).

3.2.2. Les concepts du langage

Ce sont les concepts de l’expertise de conduite quisont à l’œuvre dans chaque module du système d’aide(cf. figure 2). Pour chacun des concepts, le développeurpourra utiliser les fonctionnalités identifiées dans le ni-veau commun afin d’implanter les connaissances métier.Le tableau I synthétise les fonctionnalités essentiellesproposées pour chacun des quatre concepts de base.

• La variablereprésente les informations numériques duprocédé : données provenant des instruments, calculs in-ternes ou modèles externes. PW propose des fonction-nalités permettant desynchroniserdes variables apério-diques avec des variables périodiques ou entre elles. Parexemple, lorsqu’il faut établir un bilan matière avec desdonnées d’entrée (cycles de chargement) d’une périoded’environ 20 minutes et des données de sortie (coulées)d’une période d’environ 2 h 30. Par ailleurs la néces-sité d’appuyer les raisonnements sur des données utili-sables induit de disposer de fonctionnalités permettantd’invalider les variables et de leur substituer d’autresvariables si possible (constantes, valeurs de modèles,

dernière valeur, moyenne etc.). Dans certains cas, seulel’évolution de la variable est prise en compte, sa va-leur étant considérée invalide. Les mécanismes d’invali-dations sont nombreux : depuis l’invalidation d’une va-leur datée d’une variable jusqu’à l’invalidation de la va-riable elle-même par des moyens d’analyse de la variableelle-même ou de comparaison avec d’autres. Les tech-niques sont également variées : algorithmes métiers, mé-canismes généraux, réseaux neuronaux spécialisés [8].

• L’ événementest le lieu du passage numérique/symbo-lique. Il représente une rupture dans l’évolution du signal,rupture significative du point de vue expert. Les algo-rithmes intervenant dans cette transformation, basés gé-néralement sur l’analyse statistique, permettent de mettreen œuvre l’expertise de perception. Les événements sontassemblés ensuite pour représenter desphénomènes si-gnauxtels que par exemple « hausse brutale de laT ◦ pa-roi, débutt1, fin t2 », c’est-à-dire une information sym-bolique, datée, concernant un signal donné. Les algo-rithmes de traitement de signal savent reconnaître desphénomènes de niveau, de variation, de dérive, d’insta-bilité, d’ondulation, ainsi que des formes particulières.Ils intègrent les moyens de régler le curseur entre certi-tude et précocité de la détection. Par ailleurs, les aspectsquantitatifs de la perception pouvant évoluer au cours dutemps1, un mécanisme ad hoc a été inventé qui permetd’adapter la perception au contexte courant de marchedu procédé.

• Le phénomène, terme neutre pouvant à la fois re-présenter une anomalie process ou une amélioration estconstruit par assemblage de divers phénomènes signaux.C’est l’un des éléments de base de la communicationentre le système et l’opérateur (ex. « garnissage des pa-rois en cours ») (fonction de Détection). La décisionde le montrer à l’opérateur dépend du contexte courant(l’ état) de marche du procédé : on n’alarmera pas l’opé-rateur pour des questions relatives à l’optimisation dela consommation de combustible si la priorité du mo-ment est de mettre le procédé en fonctionnement correct.L’analyse de l’évolution des phénomènes et de leurs rela-tions temporelles et/ou causales permet de rendre comptedu comportement du procédé et de son évolution prévi-sible (fonction de Diagnostic). Dans certains cas, une par-tie des phénomènes ne sont plus détectables pour caused’incohérences entre des données process. L’opérateur en

1 Par exemple, en début de campagne, un haut-fourneau possède desréfractaires sur ses parois internes, qui sont amenés à disparaître au boutde quelques années. On imagine aisément l’évolution que subit le signalde température récupéré sur ces parois. Et pourtant, la détection desphénomènes doit s’adapter à ce nouveau contexte sans intervention demaintenance.

452


Figure 8. La vue de Conduite conçue comme la Une d’un journal.

est prévenu afin d’y remédier et, également, de connaîtrel’état instantané de la performance effective de son sys-tème de détection.

• La finalité du système d’aide est de proposer à l’opé-rateur desrecommandations d’actionsdont la vocationest de l’aider à agir sur le procédé (paragraphe 2.1).On a vu précédemment la notion d’état. Les différentsétats sont ordonnés (ex. hors allure, en allure, satisfai-sant, ajusté, optimisé). Les recommandations d’actionssont conçues pour répondre à deux objectifs : éviter dedescendre à l’état inférieur et tenter d’atteindre l’état pro-cess supérieur. Pratiquement elles visent à maintenir lesbilans de conduite (matière, thermique ou chimique) età combattre les perturbations (les phénomènes alarmantsou les comportements néfastes). Elle peuvent prendre uneforme quantifiée (valeur d’un actionneur) ou symbolique,on l’appelleraconseil d’action.

• Lesvues. La coopération homme–machine est conçueà l’aide de la métaphore générale dujournal. L’opérateura, sous les yeux, la une du journal (cf.figure 8). D’uncoup d’œil il connaît l’état de son process, et ce qui estnouveau (non connu) dans cet état. S’il le désire il peutaller « dans les pages intérieures » à l’aide d’un click,afin de connaître les détails relatifs à telle alarme outelle recommandation d’action. Cette vue intérieure, ditede justification, comporte les graphes des divers signauxconstitutifs de l’alarme ou de l’action à entreprendre, oule graphe causal expliquant l’origine du phénomène.

3.3. L’environnement logiciel ProcessWorks

Conçu pour le développeur/mainteneur de systèmesd’aide à la conduite, il est composé d’un ensemble intégréde langages et d’outils couvrant le cycle de vie dulogiciel.

Afin de supporter les développements parallèles etdistants, l’ensemble des outils et langages est accessibledepuis des espaces de travail personnalisés gérés sousatelier de gestion de version [9]. Celui-ci comporte parailleurs la gestion de faits techniques.

Les langages de base sont C, C++, Oracle etXFM/XRT pour l’IHM. Trois outils spécialisés ont étédéveloppés pour PW :

(1) Outil de réglage de la perception. Le challenge aconsisté à régler 2 à 3 algorithmes de perception par si-gnal pour plus de mille signaux (chaque algorithme né-cessitant de 5 à 20 paramètres). Un outil de producti-vité de réglage des paramètres d’algorithmes a été réalisé( figure 9). Il permet de définir un paramétrage pour unalgorithme, de l’appliquer sur un signal et d’en voir im-médiatement le résultat de façon à ce qu’interactivementl’expert et l’ingénieur de la connaissance puissent mettreau point les détections.

(2) Langage hybride pour les raisonnements. La com-binaison des événements sortis des algorithmes d’analysedu signal est basée sur des contraintes temporelles. L’al-

453


Figure 9. Process Works ENQUETr, outil interactif de réglage d’algorithmes de perception.

gorithme IxTeT [10] issu des travaux relatifs à la robo-tique mobile au LAAS a été implanté dans un langagehybride (objet+ règles de production) de façon à dispo-ser d’une représentation de connaissance de base riche etdéclarative. Une structure commune de typetoasterac-cueille les bases de connaissances développées en paral-lèle et se charge du contrôle interne au système à basesde connaissances.

(3) Outil de paramétrage. Il constitue le cœur dePW en ce sens que toute activité de codage comporte(cf. figure 5) du paramétrage. Il est actuellement com-posé, pour SACHEM, de 600 tables représentant environ30 000 paramètres. Il a fallu faire en sorte qu’il puisse,comme les pièces de code, être géré en version, c’est-à-dire intégré au logiciel de gestion de version.

3.4. Les systèmes réalisés avec ProcessWorks

A la fin 2000, 10 systèmes d’aide à la conduiteseront installés dans les usines d’USINOR (figure 10).6 SACHEM pour les hauts-fourneaux, 2 ACCEPTs pourles coulées continues et 2 dans le domaine des lignesde revêtement. D’autres sont actuellement en négociationdans et hors USINOR.

SACHEM [12] est capable de détecter environ 150phénomènes différents sur l’ensemble du procédé haut-fourneau (HF) et propose une recommandation d’actions

Figure 10. Le nombre de systèmes d’aide à la conduite baséssur Process Works installés et les prévisions.

dans le domaine du réglage thermique du HF. Il possède21 bases de connaissances et a nécessité jusqu’à 6 cogni-ticiens en parallèles et 13 experts. Le développement amis environ 6 ans : 1 an d’analyse et de spécifications gé-nérales, 1 an de spécifications détaillées, 2 ans de recueildétaillé de connaissances, de conception et de réalisationdes mécanismes de base, 2 ans de mise au point et d’ins-tallation. En octobre 1996, la première version (réduite à80 phénomènes et sans recommandations d’actions) a étéinstallée sur le HF1 de FOS. Depuis, le système a évoluéjusqu’à sa version actuelle — le diagnostic est en coursde réalisation — tout en étant installé sur 5 autres HFx.La généricité (paragraphe 2.2), contrainte initiale, a ainsiété démontrée puisque c’est le même code qui tourne surles 6 HFx.

L’enjeu initial était estimé à une économie de 6 FFpar tonne de fonte, les gains mesurés en 1998 étaientde l’ordre de 2 US $ par tonne (environ 11,5 millions

454


de tonnes par an sont actuellement contrôlées avecSACHEM).

En 1999 a débuté la réalisation du système ACCEPT,mis en service en avril 2000 dont la finalité est d’estimerla qualité du produit en sortie de coulée continue [13]à partir d’une analyse temps-réel du comportement duprocédé. Les enjeux sont comparables (en FF par tonne)à ceux de SACHEM.

En se dotant d’un framework de développement desystèmes d’aide à la conduite experte, USINOR s’estégalement construit un pôle de compétence en ingénieriedes connaissances : un outil ne peut être efficacementexploité sans des méthodes et des hommes pour lesmettre en œuvre.

Le pôle a pour vocation d’aider ses clients à créer dela valeur en s’appuyant sur le levier des connaissancesde l’entreprise, mises en opération et non simplementcapitalisées « sur étagère ». Le modèle de processus —général — sur lequel s’appuie ProcessWorks est ainsiutilisé avec succès dans d’autres domaines tel que lalogistique ou les processus immatériels telle que la veilletechnologique ou le CRM.

RÉFÉRENCES

[1] Dolenc N., Gobrecht A., Libralesso J.M., Helleisen M., LallierM., Steiler J.M., Lemuet D., Lesaffre F.M., Thirion C., TheSachem project : a computer assisted control system —

prospects and opportunities, development and initial results,in : Proceedings of the 6th International Conference on Man–Machine Interaction and Intelligent Systems in Business,Montpellier, France, May 28–30, 1997, pp. 255–259.

[2] Newell A., The knowledge level, Artificial Intelligence 18(1982) 87–127.

[3] Wielinga B.J., Schreiber A.Th., Breuker J.A., KADS : amodelling approach to knowledge engineering, KnowledgeAcquisition 4 (1992) 5–53.

[4] Johnson R., Foote B., Designing reusable classes, Journal ofObject-Oriented Programming, SIGS 1 (5) (June/July 1988)22–35.

[5] Hamu, Fayad, Achieving bottom-line improvements with en-terprise frameworks, Communications of the ACM 41 (8)(1999).

[6] Bonnet, Haton, Truong-Ngoc, Systèmes Experts, InterEdi-tions, 1986.

[7] Haton, Al., Le raisonnement en IA, InterEditions, 1991, ch. 5.[8] Le Goc M., Touzet C., Thirion C.-C., The Sachem expe-

rience on ANN application, in : Neurap’98, Fourth Interna-tional Conference on Neural Networks and their Applications,Marseille, France, 11–13 May 1998.

[9] Continuus, www.continuus.fr.[10] Ghallab M., Mounir-Alaoui A., Managing efficiently temporal

relations through indexed spanning trees, in : ProceedingsIJCAI, 1989.

[11] SACHEM, www.sachem.com.fr.

[12] Thirion C., Steiler J.-M., Lebonvallet J.-L., Metz B., Lao D.,Lachat J.-C., The Sachem experience with BF control, in :METEC Congress 99, Proceedings of the International Confe-rence on New Developments in Metallurgical Process Techno-logy, Düsseldorf, June 13–15, 1999, pp. 91–97.

[13] USINOR, description des procédés sidérurgiques,www.usinor.com.

455

Documents

Systèmes d'aide à la conduite des procédés industriels