|
Sommaire
Liste des abréviations iii
Dédicace iv
Remerciements v
Avant-propos vi
Résumé vii
Abstract viii
Introduction 1
CHAPITRE I. GENERALITES 2
I.1 Présentation de l'entreprise 2
I.2 Les chambres froides 2
I.2.1 Présentation 2
I.2.2 Exploitation 3
I.3 Principes de l'expertise technique 5
I.3.1 Les principales étapes 5
I.3.2 La phase de diagnostic 5
I.4 Quelques techniques d'intelligence artificielle 7
I.4.1 La logique floue 7
I.4.2 Les algorithmes génétiques 8
I.5 Le génie logiciel 10
I.5.1 Principes généraux du génie logiciel
10
I.5.2 Outils de développement client-serveur 11
I.5.3 La liaison dynamique sous Windows : les DLL 12
CHAPITRE II. ANALYSE DE CONCEPTION DU LOGICIEL 13
II.1 Analyse globale 13
II.1.1 Principe de l'expertise 13
II.1.2 Spécifications fonctionnelles 13
II.1.3 Architecture modulaire 14
II.2 Analyse détaillée du logiciel 15
II.2.1 Interface 15
II.2.2 Module d'édition des rapports 15
II.2.3 Module de calcul du bilan thermique 16
II.2.4 Module de diagnostic interne 18
II.2.5 Module de redimensionnement 23
II.2.6 Le système à base de règles floues
23
II.2.7 Module de données 26
II.2.8 Autres modules 31
CHAPITRE III. MATERIEL INFORMATIQUE ET IMPLEMENTATION 33
III.1 Plate-forme de développement 33
III.1.1 Les ressources matérielles 33
III.1.2 Les ressources logicielles 33
III.2 Implémentation sous MS Access XP 34
III.2.1 Présentation de MS Access XP 34
III.2.2 Tâches effectuées sous MS Access XP 34
III.3 Implémentation sous Visual Basic 6 34
III.3.1 Présentation de Visual Basic 6 34
III.3.2 Tâches effectuées sous Visual Basic 6 35
III.4 Implémentation sous Visual C++ 6 40
III.4.1 Présentation de Visual C++ 6 40
III.4.2 Tâches effectuées sous Visual C++ 6 41
CHAPITRE IV. TEST DU LOGICIEL 45
IV.1 Présentation de l'installation expertisée
45
IV.1.1 Caractéristiques constructives de la chambre 45
IV.1.2 Données actuelles d'exploitation 46
IV.1.3 Présentation des groupes frigorifiques 46
IV.1.4 Le mode de défaillance constaté 47
IV.2 Expertise par Fronix 47
IV.2.1 Bilan thermique 47
IV.2.2 Diagnostic interne 47
IV.2.3 Redimensionnement 49
IV.2.4 Prise des décisions 49
IV.3 Discussion 50
Conclusion 51
Bibliographie 52
Annexes 54
Annexe 1 : Implémentation des opérateurs
génétiques 55
Annexe 2 : Résultats du bilan thermique de la chambre
expertisée 57
Annexe 3 : Résultats de diagnostic d'un groupe
frigorifique du compartiment principal 58
Annexe 4 : Fonctions exportées par la DLL des fluides
frigorigènes 60
Annexe 5 : Quelques règles fournies avec la CCF
implémentée 61
Liste des abréviations
ADO : Active X Data Object
AFNOR : Association Française de Normalisation
AG : Algorithme Génétique
AGL : Atelier de Génie Logiciel
API : Application Programming Interface
BASIC : Beginners All purposes Symbolic Instructions Code
BD : Base de Données
CCF : Configuration de Circuit Fluidique COM : Component Object
Model
DLL : Dynamic Link Library
ENSAI : Ecole Nationale Supérieure des sciences
Agro-Industrielles FAT : File Allocation Table
FCC : Fluidic Circuit Configuration HTML : Hyper Text Markup
Language IA : Intelligence Artificielle
IAA : Industries Agricoles et Alimentaires L3G : Langage de
3ème Génération
L4G : Langage de 4ème Génération
MDI : Multiple Document Interface
MIP : Maintenance Industrielle et Productique
MS : MicroSoft
PC : Personal Computer
RAM : Random Access Memory SDI : Single Document Interface
SGBD : Système de Gestion des Bases de Données
SQL : Structured Querry Language
Dédicace
Je dédie ce mémoire à mes parents M. et Mme
TOBOU, pour toute l'affection et le réconfort qu'ils ont toujours su
porter à mon égard.
Remerciements
Je tiens ici à remercier tous ceux qui de près ou
de loin ont permis la réalisation de ce travail. Il s'agit de :
Toute ma famille pour leur soutien et leur amour immenses ;
Dr KUITCHE Alexis pour son encadrement minutieux tout au long de
ce travail ;
M. NGOUCHINGUE Sylvestre, DG de CONGELCAM, pour l'accueil
chaleureux qu'il nous a réservé dans son entreprise ;
Les techniciens et le personnel de CONGELCAM, pour toute
l'attention qu'ils ont toujours porté à notre égard.
Sans toute fois oublier tous mes camarades de classe pour leurs
conseils constructifs tout au long de ce travail.
Avant-propos
L'Ecole Nationale Supérieure des Sciences
Agro-Industrielles (ENSAI) est l'un des établissements de
l'Université de Ngaoundéré né de la réforme
universitaire de janvier 1993. Elle n'était constituée que de la
filière IAA (Industries Agricoles et Alimentaires) jusqu'en 2000, date
à laquelle fut créée la filière MIP (Maintenance
Industrielle et Productique). La formation dure trois ans, et afin de forger au
maximum les ingénieurs qu'elle forme aux contraintes de l'entreprise sur
les plans humain et technologique, un stage en milieu industriel est
prévu à chaque niveau d'étude. Un stage agent de
maîtrise I (de 4 à 6 semaines) au niveau I, un stage agent de
maîtrise II (de 6 à 8 semaines) au niveau II et un stage fin
d'études (de 4 à 5 mois) au niveau III.
Ce mémoire a été effectuer au terme d'un
stage fin d'études, effectué à CONGELCAM
(société camerounaise spécialisée dans
l'importation, la distribution et la vente des poissons et viandes) du 16 juin
au 20 octobre 2003, et sur le thème : « Développement d'un
logiciel d'expertise technique d'installations frigorifiques de chambres
froides ».
Résumé
Dans ce travail, nous avons développé un
logiciel d'expertise technique d'installations frigorifiques de chambres
froides. Ce logiciel est destiné à un usage
général, contrairement à ceux mis en oeuvre pour des
installations spécifiques, dans les systèmes de suivi
préventif ou ceux de télésurveillance.
La démarche d'expertise utilisée dans le
logiciel consiste en un redimensionnement de la chambre, un diagnostic interne
et une prise de décision finale. Le diagnostic interne est très
important, car il permet d'avoir accès à un état interne
des installations non accessible par de simples mesures. La prise de
décision pourra donc se faire à partir de cet état interne
et de l'état externe correspondant (obtenu à partir des mesures
prélevées), en comparant ces états aux états
nominaux proposés par le redimensionnement.
Pour être général, une modularité
accrue du logiciel s'est imposée. C'est pourquoi nous avons crée
des entités appelées « Configuration de Circuit Fluidique
» (CCF), chacune d'elle renfermant les données et procédures
nécessaires à la manipulation d'un type d'installation
frigorifique donné. Le diagnostic aussi est réalisé par un
module bien délimité. Au cours de ce travail, nous n'avons
conçu qu'une seule CCF, et le diagnostic a été mis en
oeuvre par un algorithme génétique. La prise de décision
finale est réalisée par un système à base de
règles floues, afin de se rapprocher le plus possible du langage humain
(vague et imprécis) dans l'énoncé des règles de
décision.
Nous avons appelé ce logiciel « Fronix ». Il
a été développé pour Windows, à l'aide de
Visual Basic 6 et de Visual C++ 6. Les bases de données utilisées
ont été implémentées dans MS Access XP.
Nous avons testé cette première version sur une
chambre froide de CONGELCAM, et les résultats sont encourageants. Il ne
reste donc plus qu'à concevoir des CCF plus fines pour avoir des
résultats encore plus précis. Une telle CCF est en cours de
développement, et la prochaine version de Fronix pourra être
commercialisée.
Abstract
In this work, we developed a software for technical expertise
of refrigerating installations of cold chambers. This software is intended for
a general use, contrary to those implemented for specific installations in the
preventive systems or the remote monitoring systems.
The steps of expertise used in the software consist of a
redimensioning of the chamber, an internal diagnosis and a final
decision-making. The internal diagnosis is very significant, because it makes
it possible to have gateway in an internal state of the installations whose is
no accessible by simple measurements. The decision-making could thus be done
using this internal state and also the external state corresponding (obtained
by taken measurements), by comparing these states with the nominal states
proposed by redimensioning.
To be general, an increased modularity of the program is
required. This is why we have created entities called "Fluidic Circuit
Configuration" (FCC), each one containing the data and procedures necessary for
the handling of a given type of refrigerating installation. The diagnosis also
is carried out by a well delimited module. During this work, we designed only
one FCC, and the diagnosis was implemented by a genetic algorithm. The final
decision-making is carried out by a fuzzy rules based system, in order to
approach as much as possible the human language (vague and imprecise) in the
statement of the rules of decision.
We called this software "Fronix". It was developed for
Windows, using Visual Basic 6 and Visual C++ 6. The data bases used were
implemented in MS Access XP.
We test this first version on a cold chamber of CONGELCAM, and
the results are encouraging. Now we have to design better FCC in order to have
more precise results. We are developing such a FCC and the next version of
Fronix could be marketed.
Introduction
CONGELCAM est le leader camerounais en matière
d'importation et de distribution de viandes et poissons, et a par
conséquent un important parc de chambres froides. La qualité des
produits conservés ne peut être assurée que par des
conditions de conservation adéquates (propreté, bonnes
température et humidité ambiante) et stables. C'est dans cette
optique que la maintenance des installations frigorifiques des chambres froides
est d'un grand enjeu. Pour cette maintenance, CONGELCAM dispose d'un personnel
technique qualifié et très expérimenté. Mais cela
n'est pas toujours suffisant, car certains modes complexes de
dégradation des installations ne peuvent être
appréhendés que par une analyse approfondie de ces installations,
tant sur le plan théorique qu'expérimental. C'est pourquoi
l'entreprise a décidé de se doter d'un outil informatique
d'expertise des installations frigorifiques de ses chambres froides.
Les logiciels disponibles actuellement pour de telles
expertises sont ceux exploitant les données de suivi d'installations,
issues des tournées de maintenance préventive ou de
systèmes de télésurveillance. Dans les deux cas, il s'agit
d'outils développés pour des installations spécifiques.
Pour des entreprises telles que CONGELCAM disposant d'un parc matériel
issu de constructeurs variés, le recourt à de tels logiciels
s'avère très vite coûteux.
C'est pourquoi au cours de notre stage à CONGELCAM, il
nous a été demandé de développer un logiciel
d'expertise adapté à toutes configurations d'installations
frigorifiques. Ce projet a été formulé sous le
thème : « Développement d'un logiciel d'expertise technique
d'installations frigorifiques de chambres froides ».
Bien que ce thème ait été formulé
pour CONGELCAM, le logiciel en question a été
développé pour un usage général, ce qui justifie la
démarche de conception « orientée consommateur » que
nous avons adopté afin de garantir la qualité de l'application.
Le présent mémoire expose les travaux de développement de
ce logiciel, que nous avons appelé « Fronix ».
Dans le premier chapitre, nous aborderons quelques
généralités. Il s'agira de présenter un peu plus
CONGELCAM, et aussi les principes techniques et théoriques qui nous ont
guidés dans ce travail.
Ensuite, nous parlerons de l'analyse de conception du
logiciel. Dans ce chapitre, une brève analyse fonctionnelle de
l'application permettra de ressortir sa structure modulaire. Ensuite, une fois
cette structure modulaire connue, nous ferrons une analyse
détaillée de chaque module. Pour un module donné, il
s'agira d'énoncer si nécessaire les problèmes de
conception, et les solutions adoptées.
Pour achever les phases de conception, nous parlerons ensuite
de l'implémentation proprement dite de l'application, et des ressources
utilisées pour y arriver.
Après l'implémentation, nous verrons les
résultats du test du logiciel effectué sur une chambre froide de
CONGELCAM.
A la fin, viendra une conclusion à cette
présentation. Elle indiquera entre autres les perspectives à
venir dans la suite de ces travaux.
CHAPITRE I. GENERALITES
I.1 Présentation de
l'entreprise
L'histoire de CONGELCAM débute en 1982, quand son
Directeur Général actuel, M. NGOUCHINGUE Sylvestre commence la
vente en détail de poissons congelés. Ses premiers
bénéfices sont réintroduits dans l'achat de
congélateurs, ce qui augmenta rapidement son chiffre d'affaire.
Les établissements CONGELCAM ne tarderont pas alors
à naître, avec la construction des premières chambres
froides. Le génie de M. NGOUCHINGUE pour les affaires étant
remarquable, ses activités ne cesseront de croître pour aboutir en
1994 à la création de la société CONGELCAM Sarl,
avec un capital de 2 milliards de francs CFA.
Aujourd'hui les activités de CONGELCAM consistent
essentiellement en l'importation, la distribution et la vente des produits de
la mer et de certaines viandes. Ainsi, l'entreprise dispose de plusieurs sites
d'entreposage de grande envergure à Douala, terminus des bateaux
d'importation. Des camions frigorifiques sont chargés d'acheminer les
produits ainsi stockés vers d'autres sites disséminés dans
les autres provinces (Centre, Ouest, Est, Sud, Nord-Ouest, Sud-Ouest). De
là, des camions plus légers pourront ravitailler les points de
vente. L'exceptionnelle capacité logistique actuelle de CONGELCAM permet
de réceptionner un bateau entier de produits pratiquement tous les 10
jours, faisant d'elle le leader national incontesté sur le marché
du poisson et de la volaille.
I.2 Les chambres froides I.2.1
Présentation
Une chambre froide est une enceinte destinée à
conserver des produits (agroalimentaires, pharmaceutiques, ...), à une
humidité relative et une température (généralement
inférieure à la température ambiante) fixées. Ses
façades, son plafond et son plancher sont thermiquement isolés.
La technologie d'isolation des façades et du plafond la plus
utilisée actuellement est celle des panneaux sandwiches, où une
couche compacte d'isolant (polyuréthane, polystyrène, ...) est
prise en sandwich entre deux plaques métalliques. Ces panneaux sont
préfabriqués, et permettent des constructions plus rapides, plus
efficaces et plus économiques que les technologies
précédentes (AUDIFFRET, 1984).
Les conditions climatiques internes requises sont
assurées par des installations frigorifiques, dont les
évaporateurs (organes de production de froid) sont situés dans
l'enceinte, et le reste de l'installation à l'extérieur. Pour les
plus grandes chambres, une ossature métallique vient renforcer
l'édifice en panneaux sandwiches. On parle alors souvent
d'entrepôt frigorifique.
I.2.2 Exploitation
I.2.2.1 L'installation frigorifique
Le circuit frigorifique est généralement celui
d'un cycle de réfrigération à compression mécanique
de vapeurs. Une configuration très souvent rencontrée sur les
entrepôts frigorifiques est la suivante :
Electrovanne liquide
Bouteille d'aspiration
Pressostats de régulation
Condenseur
Séparateur d'huile
Bouteille liquide
Voyant d'huile
Electrovanne d'huile
Filtre déshydrateur Voyant liquide
Compresseur
Vanne 3 voies d'aspiration
Evaporateur
Détendeur thermostatique
Figure I.1 : Exemple de schéma fluidique
d'installation frigorifique I.2.2.2 Le calcul d'une chambre froide
Le dimensionnement des éléments d'une chambre
froide a pour base le calcul des puissances frigorifiques à fournir par
les évaporateurs. Ces puissances s'obtiennent par un bilan thermique sur
la chambre. Pour une chambre classique, les charges à calculer sont :
· Charges par transmission à travers les parois Qtp
: il s'agit des gains de chaleur par échange thermique avec
l'environnement extérieur et le sol ;
· Charges par renouvellement d'air Qra : dans de
nombreuses chambres froides, il est prévu de renouveler plus ou moins
l'air ambiant par de l'air extérieur. Ce sont les gains thermiques
apportés par cet air extérieur qui sont pris en compte dans cette
rubrique ;
· Charges par ouverture des portes Qop : ce sont les
charges dues aux échanges de matière entre l'intérieur et
l'extérieur, suite à l'ouverture des portes ;
· Charges dues aux appareillages divers Qad : il s'agit
des charges engendrées par le fonctionnement d'appareils tels que les
luminaires, les moteurs d'évaporateurs, les chariots
élévateurs, ... ;
· Charges dues au personnel travaillant Qpt : elles
sont dues à la chaleur dégagée par les corps en
activité ;
· Charges dues au dégivrage Qdg : en fonction de
la température de la chambre, il est possible d'avoir une formation de
givre sur les évaporateurs. Dans ce cas, il est alors prévu une
procédure de dégivrage, destinée à fondre ce givre.
C'est la chaleur dégagée au cours du dégivrage qui est
prise en compte dans cette rubrique ;
· Charges dues aux denrées Qdr : ces charges sont
dues au fait que les denrées sont généralement introduites
à une température supérieure à celle d'entreposage.
Il faut donc les porter à bonne température. Aussi, les produits
végétaux dégagent une chaleur de respiration qu'il faut
compenser.
La charge totale est alors donnée par :
Qtot = Qtp + Qra + Qop + Qad
+ Qpt + Qdg + Qdr (1).
Comme une installation est conçue pour fonctionner
tf ( tf = 24 ) heures par jour,
cette
charge sera multipliée par 24 pour avoir la puissance
nette à installer. Une valeur courante tf
de tf est 16 heures (BREIDERT, 1998).
I.2.2.3 La maintenance des installations frigorifiques
D'après la norme AFNOR NF X60 010 (ZWINGELSTEIN,
1995), la maintenance se définie comme : « Toutes les
activités destinées à maintenir ou à
rétablir un bien dans un état ou des conditions données de
sûreté de fonctionnement, pour accomplir une fonction requise. Ces
activités sont une combinaison d'activités techniques,
administratives et de management. ». Il faut noter ici que toute la
science de la maintenance consiste à atteindre ces objectifs de
sûreté de fonctionnement à moindre coût.
En ce qui concerne les installations frigorifiques de
chambres froides, il s'agira de garantir un niveau suffisant de
disponibilité des installations, car ici les arrêts
prolongés coûtent cher (dégradation des denrées
stockées). Cet objectif est atteint en assurant une bonne
fiabilité (maintenance préventive bien mise en oeuvre) et une
bonne maintenabilité (bonne gestion des stocks de pièces de
rechange et bonne réactivité du service maintenance face aux
défaillances). Précisons ici que ces installations sont
très souvent sujettes à des défaillances par
dégradation, et qu'un état de fonctionnement
dégradé ici est assimilable à un arrêt, car les
conséquences sur la conservation des denrées sont à long
terme identiques.
La maintenance préventive des installations
frigorifiques est principalement conditionnelle. Elle consistera donc au suivit
des pressions, températures, intensités absorbées,
degré de contamination en humidité du circuit, degré de
dégradation de l'huile, état sensitif des organes (toucher,
odorat, vue, ...), etc. Tout l'art ici étant alors de savoir bien
analyser les informations ainsi collectées, afin de décider des
actions à entreprendre.
Dans ce cadre, une bonne expérience est requise. Quand
cette expérience devient insuffisante pour expliquer des modes de
dégradations compliqués, alors un expert en la matière
s'impose, à moins d'avoir recours à un système d'expertise
informatique.
I.3 Principes de l'expertise
technique
I.3.1 Les principales étapes
Il n'existe pas de procédure type d'expertise
technique d'unités industrielles, car la démarche d'une expertise
dépend de la précision et de la profondeur recherchées.
Mais de façon générale, on retrouvera les étapes
suivantes (MONCHY, 2000) :
· Renseignements préliminaires : ici, une
enquête de terrain permettra de rassembler tous les
éléments de connaissance utiles : conditions de fonctionnement,
caractéristiques techniques, ... ;
· Observations et examens : il s'agit d'effectuer des
observations visuelles ou instrumentales des zones accessibles ;
· Diagnostic : il s'agit de retrouver les causes à
l'origine des disfonctionnements constatés dans les deux
premières étapes ;
· Propositions et remèdes : ici des mesures
correctives et préventives sont énoncées pour une remise
à niveau du dispositif expertisé.
Le rôle d'un système informatique d'expertise est
donc de mettre en oeuvre ces étapes de la manière la plus
automatique possible.
I.3.2 La phase de diagnostic
Dans la démarche précédente, c'est la
phase de diagnostic qui est la plus délicate à automatiser. Il
s'agira là d'inverser une relation de cause à effet. En d'autres
termes, connaissant les effets (symptômes observés sur
l'équipement), il faudra retrouver les causes qui les ont crées.
Pour y parvenir il existe actuellement deux grandes familles de techniques de
diagnostic automatique (ZWINGELSTEIN, 1995).
I.3.2.1 Les méthodes de diagnostic interne
Ces méthodes supposent l'existence d'un modèle
physique ou expérimental de simulation de l'équipement à
diagnostiquer. Ce modèle de calcul décrit donc de façon
plus explicite la relation de cause à effet sous la forme :
? ?
E = F C (2)
( )
?
E est le vecteur des effets (observations
effectuées sur l'équipement), et (paramètres internes, non
accessibles par l'observation).
|
?
C celui des causes
|
|
?
Ayant observé sur l'équipement un vecteur
d'effets Em , le problème revient alors à
?
retrouver le(s) meilleur(s) vecteur(s) cause Copt
à l'origine des effets, en d'autres termes qui
? ?
minimise(nt) la fonction objectif
Em - F(C)
, où · est une norme définie dans l'espace
des
effets. La fonction F n'est très souvent pas
connue sous forme explicite, mais plutôt sous forme algorithmique. Dans
ce cas, la minimisation de la fonction objectif ne peut être faite que
par des méthodes non déterministes. Parmi ces méthodes,
les plus utilisées actuellement pour résoudre ce type de
problème sont :
· Les méthodes de Monte Carlo : la fonction
objectif est évaluée en un grand nombre de points pris
aléatoirement dans l'espace de recherche, et les solutions choisies
parmi ces points ;
· Le recuit simulé : à chaque
itération, on effectue un déplacement aléatoire à
partir du point en cours. Si le déplacement mène à une
valeur plus petite de la fonction, il est accepté. Sinon, il est
accepté avec une probabilité dépendant d'une «
température » T diminuant au fil du temps (d'où le nom de
recuit simulé) ;
· les algorithmes génétiques : un point de
l'espace de recherche est assimilé à un individu. Le principe est
alors de simuler l'évolution d'une population d'individus divers
auxquels on applique différents opérateurs
génétiques et que l'on soumet à chaque
génération à une sélection. Ces algorithmes sont de
plus en plus utilisés dans l'industrie, car ils sont
particulièrement adaptés aux problèmes d'optimisation
comportant de nombreux paramètres. Nous y reviendrons dans la suite.
I.3.2.2 Les méthodes de diagnostic externe
Ces techniques n'exigent pas un modèle de calcul pour
l'équipement. Par contre elles nécessitent une expertise humaine
ou une solide banque de données de retour d'expérience. Dans
cette catégorie, on peut citer :
· Méthode par reconnaissance des formes : ici, y
a d'abord une phase d'analyse où les données de retour
d'expérience sont regroupées en classes expérimentalement
ou à l'aide d'une technique de classification automatique (nuées
dynamiques, réseaux de neurones à apprentissage non
supervisé, ...). Les classes (ou formes) ainsi constituées
représentent des modes de fonctionnement de l'équipement.
Ensuite, un système de détection automatique est mis en oeuvre
à l'aide d'une technique de reconnaissance de formes (classification
floue, discrimination bayésienne, réseaux de neurones, ...).
Partant de symptômes observés sur l'équipement, ce
système de détection permettra de retrouver le mode de
fonctionnement correspondant.
· Méthodes utilisant des systèmes à
base de règles : les systèmes experts classiques sont à la
base de ces méthodes. Là, à partir d'une base de faits
(faits observés sur l'équipement) et d'une base de connaissances
(règles de
diagnostic), un moteur d'inférence pourra
inférer de nouveau faits, permettant ainsi de remonter aux causes des
effets observés. Ces méthodes peuvent aussi être mis en
oeuvre avec des systèmes intelligents plus évolués tels
que les réseaux bayésiens, les systèmes experts flous, et
même les agents intelligents, derniers nés des laboratoires de
recherche en intelligence artificielle.
I.4 Quelques techniques d'intelligence artificielle
I.4.1 La logique floue
La logique classique (booléenne) a pour base la
théorie des ensembles classiques. Dans cette dernière, tout
ensemble A est caractérisé par une fonction
caractéristique définie par :
1 si x A
?
?( )
x = (3).
0 si x A
?
Cette formulation très idéalisée ne permet
d'aborder qu'un nombre très restreint d'objets ou de
phénomènes du monde réel, qui est par essence
imprécis et incertain.
Les logiques multivalentes (trivalente, pentavalente, ...),
en introduisant d'autres niveaux entre 0 et 1 constituent une
amélioration à cette formulation de base, mais restent toujours
insuffisantes face à la grande complexité de notre monde. Les
deux énoncés suivants illustrent bien cette complexité qui
met en défaut ces logiques classiques :
E1 : Si la température augmente plus ou
moins, alors ouvrez légèrement les volets ;
E2 : Il pleuvra probablement aujourd'hui.
C'est pour traiter de tels énoncés vagues et
imprécis que L.A. Zadeh (à l'époque professeur à
l'Université de Californie Berkeley) a introduit en 1965 la
théorie des ensembles flous. Dans cette théorie, la fonction
caractéristique d'un ensemble, appelée fonction d'appartenance
peut prendre toutes les valeurs de l'intervalle [0, 1]. La logique floue est
une logique construite à partir de cette théorie des ensembles
flous.
En logique floue, on introduit la notion de variable
linguistique, dont les valeurs ne sont pas numériques, mais plutôt
symboliques. Ces variables sont donc une extension des variables binaires
classiques prenant les valeurs « Vrai » et « Faux ». Pour
définir une variable linguistique, il faut :
· Un univers U : par exemple, l'intervalle [0, 100] ;
· Une désignation valable sur cet univers : par
exemple « Température » ;
· Un ensemble de termes relatifs à cette
désignation : par exemples « Elevée », « Faible
», « Normale », ... .
Chaque terme ainsi définit est caractérisé
par un ensemble flou, donc par une fonction d'appartenance
ì(x) bien définie. On peut par exemple
définir les températures
« Normales » par la fonction ci-après :
ì(x)
18 23 28 T (°C)
Figure I.2 : Exemple de fonction d'appartenance
du terme « Température Normale »
L'accentuation des termes peut être
caractérisée par des modificateurs linguistiques, qui viennent en
fait modifier leurs fonctions d'appartenance ì(x) en
ìM (x) , rendant compte de la modification
apportée. Les modificateurs de base introduits par Zadeh sont :
· « Très » : 2
ì M ( x ) = [ ì
( x )] (4) ;
·
« Plus ou moins » : ìM (
x ) = ì(x) (5) ;
· « Non » : ìM ( x
) = 1 - ì(x) (6) .
Ceci dit, les énoncés E1 et E2
précédentes deviennent parfaitement manipulables en logique
floue.
I.4.2 Les algorithmes génétiques
C'est au début des années 1960 que John Holland
de l'Université du Michigan a commencé à
s'intéresser à ce qui allait devenir les algorithmes
génétiques. Ces algorithmes font partie du champ de
l'Intelligence Artificielle (IA). Il s'agit d'IA de bas niveau, inspirée
par « l'intelligence » de la nature. Ils sont basés sur le
concept de sélection naturelle élaboré par Charles Darwin.
Le vocabulaire employé est donc directement calqué sur celui de
la théorie de l'évolution et de la génétique. Un
tel algorithme est définit par :
· Des individus : ce sont des solutions potentielles du
problème ;
· Des gènes : un gène est un ensemble de
bits. Ils constituent le génotype des individus,
généralement exprimés sous forme binaire. Notre
problème étant multidimensionnel, un gène sera
représenté par une composante codée sous forme binaire
;
· Une fonction de codage, permettant de retrouver le
génotype de chaque individu ;
· Une fonction de décodage, permettant de retrouver
un individu (son phénotype) à partir de son génotype ;
· Une population : c'est un ensemble d'individus ;
· Une fonction de fitness: c'est la fonction positive
à optimiser. Elle mesure pour un individu donné son adaptation au
problème posé.
L'idée fondamentale est la suivante : le pool
génétique d'une population donnée contient potentiellement
la solution, ou plutôt une meilleure solution, à un
problème adaptatif donné. Cette solution n'est pas
exprimée, car la combinaison génétique sur laquelle elle
repose est dispersée chez plusieurs individus. Elle ne le sera que par
l'association de ces combinaisons génétiques au cours d'une
évolution tendant à améliorer les individus (les rendre
plus adaptés au problème posé).
Les étapes de l'algorithme consistent donc à
faire évoluer une population initiale, de façon à ce que
les individus soient de plus en plus adaptés au fil des
générations. Les étapes que nous nous avons suivit sont
les suivantes :
1. Genèse de la population : une population de
taille N est tirée au hasard, déjà codée sous forme
binaire.
2. Décodage et évaluation de la
population : chaque individu est décodé, et son fitness
évalué. Nous avons utilisé ici un codage binaire pur sur
16 bits, autorisant donc une représentation dont les valeurs
décimales correspondantes sont comprises entre 0 et 216-1.
Pour une variable X telle que Xmin < X < Xmax, nous avons utilisé
un codage linéaire où Xmin représente 0 et
Xmax représente 216-1.
3. Sélection - élimination : on met en
oeuvre une procédure de sélection, à l'issue de laquelle
seule une moitié de la population sera retenue pour la
génération suivante. Il existe de nombreuses procédures de
sélection, mais nous avons retenu ici la technique dite de «
sélection par tournoi avec élitisme ». Dans cette technique,
deux individus sont choisis au hasard par tirage avec remise, et combattent (on
compare leurs fonctions d'adaptation) pour accéder à la
génération intermédiaire. Le plus adapté l'emporte
avec une probabilité de sélection ps (0,5 <
ps < 1) fixée. Cette étape est
répétée jusqu'à ce que la génération
intermédiaire soit remplie (N/2 individus). Si l'individu le
plus adapté ne se retrouve pas dans cette génération
intermédiaire, alors il y est introduit en remplacement d'un autre pris
au hasard. Il est tout à fait possible que certains individus
participent à plusieurs tournois : s'ils gagnent plusieurs fois, ils
auront donc le droit d'être copiés plusieurs fois dans la
génération intermédiaire, ce qui favorisera la
pérennité de leurs gènes.
4. Croisement : une fois la génération
intermédiaire remplie, les individus sont répartis en couples
(soit N/4 couples). Dans chaque couple, les gènes des parents sont
copiés et recombinés de façon à former deux
descendants possédant des caractéristiques issues des deux
parents. On obtient ainsi les N/2 fils devant compléter la
génération intermédiaire pour obtenir une nouvelle
génération (N individus). Nous avons utilisé la technique
de croisement en deux points, où les deux points de croisement sont
choisis au hasard. Ce croisement s'effectue tel que présenté
à la figure I.3 qui suit.
Figure I.3 : Principe du croisement en deux
points
5. Mutation : une mutation est l'inversion d'un bit
dans le génotype d'un individu (Figure I.4). Les mutations jouent le
rôle de bruit et empêchent l'évolution de se figer. Elles
permettent d'assurer une recherche aussi bien globale que locale, selon le
poids et le nombre des bits mutés. De plus, elles garantissent
mathématiquement que l'optimum global peut être atteint. La
procédure de mutation consiste à muter chaque bit de chaque
individu avec une probabilité pm (généralement
comprise entre 0,001 et 0,1). Une probabilité de mutation
élevée en début d'évolution est souhaitable pour
une bonne exploration de l'espace de recherche. Mais elle doit en suite
diminuer afin de stabiliser l'évolution et faire converger l'algorithme.
C'est pourquoi les techniques d'auto adaptation des probabilités de
mutation sont très intéressantes. Celle que nous avons
utilisée associe à chaque gène d'un individu un autre
gène représentant sa probabilité de mutation. Ces
gènes des probabilités suivant aussi les mêmes
opérateurs de croisement et de mutation que ceux de l'individu.
Figure I.4 : Principe d'une mutation
6. Retour à l'étape 2. : jusqu'à ce
qu'un nombre de génération fixé soit atteint.
I.5 Le génie logiciel
I.5.1 Principes généraux du
génie logiciel
En informatique, les systèmes logiciels sont
contrairement aux apparences très complexes. C'est ce qui a conduit
à ce qu'on appelle souvent « crise du logiciel»
(«software crisis"). En effet :
· Le coût et les délais de
développement d'un logiciel sont très difficiles à
prévoir. On note souvent (STROHMEIER, 1996) des dépassements des
coûts et délais prévus de 70% et 50% respectivement ;
· La qualité du logiciel, difficile à
maîtriser, fait souvent défaut : insatisfaction des besoins de
l'utilisateur, consommation excessive de ressources matérielles, taux de
pannes élevé, ... ;
· La réutilisation de composants existant pour
confectionner de nouveaux systèmes n'est pas chose facile, pourtant
indispensable pour amortir les coûts de conception sur plusieurs
projets.
Dans ce contexte, le génie logiciel se défini
alors comme une science offrant des outils et démarches pour la
maîtrise des systèmes logiciels sur tout leur cycle de vie
(conception, exploitation et retrait de service). Comme toute science de
l'ingénieur, elle est aussi régie par un ensemble de principes et
de normes. C'est ainsi qu'on peut trouver dans la littérature :
· Des principes sur le management des projets de
développements informatiques ;
· Des principes sur le management et l'évaluation de
la qualité du logiciel ;
· Des principes sur la conception d'interfaces graphiques
;
· Et bien d'autres encore ... .
Ce sont les principes exposés dans (STROHMEIER, 1996) qui
nous ont guidés dans ce travail.
I.5.2 Outils de développement
client-serveur
Les outils de développement informatique se classent
selon les types d'applications. Pour les applications fonctionnant autour d'une
base de données, les outils de développement client-serveur sont
les plus appropriés. Il s'agit (GARDARIN, 2000) :
· Les outils d'interrogation de la base de
données, constitués principalement d'un médiateur assurant
la connexion entre la base de données (serveur) et l'application
(client). Et aussi d'un langage d'interrogation (généralement SQL
: Structured Query Language), permettant d'envoyer des requêtes à
la base de données ;
· Les langages de programmation permettant
d'écrire le code proprement dit de l'application. Les langages
utilisés actuellement sont ceux de quatrième
génération (L4G) et les ateliers de génie logiciel (AGL).
Les L4G offrent en général toutes les fonctionnalités des
langages de troisième génération (constructions
procédurales, programmation modulaire, ...) tels que PASCAL, ou FORTRAN.
En plus, elles sont conçues pour faciliter la conception d'interfaces
graphiques, et supportent le modèle objet facilitant ainsi la
réutilisation de composants. Visual Basic de Microsoft et Delphi de
Borland sont deux exemples de L4G. Les AGL sont plus élaborés, et
offrent en plus des fonctionnalités des L4G un référentiel
permettant de manager le
cycle de vie des applications. Visual Basic dans sa version
Entreprise et Designer/2000 d'oracle sont des exemples d'AGL.
~ Les langages de programmation dédiés à
des développements spécifiques. Selon les fonctionnalités
de l'application, il se peut que le L4G ou l'AGL utilisé ne soit pas
adapté pour certaines tâches. Dans ce cas, le module objet
correspondant sera écrit et compilé dans un autre langage, puis
relié au module principal par une technique de liaison
appropriée. Par exemple, Visual Basic est un langage peu
approprié pour des tâches de calcul importantes. Ces tâches
pourront donc très bien être écrites en C ou en FORTRAN,
puis compilées, et connectées ensuite au reste du programme
écrit en Visual Basic. Sous Windows, cette connexion peut être
faite en utilisant une technique de liaison dynamique, exposée au
paragraphe suivant.
I.5.3 La liaison dynamique sous Windows : les
DLL
Le problème ici est de savoir quand et comment le code
machine d'un programme en un langage donné sera lié à des
fonctions utiles situées dans une bibliothèque de routines.
Une première solution est la liaison statique (static
binding). Ici, le compilateur (ou plus précisément
l'éditeur de liens) assemble le programme compilé avec le code
objet de la bibliothèque de routines et les écrits dans un ficher
exécutable commun. Il se crée ainsi une paire indissociable. La
liaison statique fonctionne à merveille, mais présente cependant
quelques inconvénients. Premièrement, les fonctions
intégrées en provenance de la bibliothèque de routines ne
peuvent plus être modifiées ultérieurement. Si l'on
constate une erreur ou si l'on souhaite modifier ou étendre l'action
d'une fonction, il faut entièrement recréer le ficher
exécutable et le transmettre à l'utilisateur.
Deuxièmement, le même code des fonctions de routines est
intégré dans de nombreux programmes et sera ainsi chargé
plusieurs fois en mémoire si l'on lance simultanément plusieurs
programmes. On gaspille ainsi un précieux espace mémoire.
Une meilleure solution est la liaison dynamique (dynamic
binding). Ici, le code objet de la bibliothèque de routines n'est pas
intégré à la compilation, mais seulement à
l'exécution. La bibliothèque de routines est ainsi disponible
dans un fichier séparé, appelé bibliothèque de
liens dynamiques (Dynamic Link Library : DLL). Lors de l'exécution, le
programme accède à la DLL, ce qui lui permet d'appeler les
fonctions qu'elle contient par le biais d'un mécanisme
prédéfini.
En cas de modification de la bibliothèque de routines,
il n'est donc plus nécessaire de recompiler tout le programme, le
remplacement du fichier DLL est suffisant. Les fonctions issues de la DLL ne
sont plus chargées plusieurs fois, car plusieurs programmes peuvent se
référer simultanément à une instance de la DLL
présente en mémoire.
Le domaine d'application de cette technique s'étend
bien plus loin que les bibliothèques de routines du compilateur. Windows
lui même utilise le même principe en intégrant tout son
système d'interface de programmation (Application Programming Interface
: API) composé de plus d'un millier de fonctions, sous la forme de
nombreuses DLL.
CHAPITRE II. ANALYSE DE CONCEPTION DU
LOGICIEL
II.1 Analyse globale
II.1.1 Principe de l'expertise
En se basant sur les étapes générales
d'expertise d'unités industrielles présentées au
paragraphe I.3.1, nous avons retenu une démarche d'expertise
centrée sur les points suivants :
· Redimensionnement de la chambre à expertiser
à base des données d'exploitation
réelles, afin de
quantifier les performances exigées aux installations frigorifiques ;
· Diagnostic du dispositif, afin d'avoir des renseignements
sur l'état interne de chaque composant ;
· Prise des décisions à base des
résultats des phases précédentes.
De façon plus détaillée, les étapes
sont les suivantes :
· Etape 1 - Prise des données de
construction et d'exploitation de la chambre par l'utilisateur.
· Etape 2 - Calcul du bilan thermique par
le logiciel. Cette étape permet de fixer les objectifs à
atteindre par la remise à niveau de la chambre.
· Etape 3 - Prise connaissance des
installations frigorifiques. Ici, l'utilisateur relève sur les
installations tous les paramètres indispensables à l'expertise
(type du circuit fluidique, caractéristiques des éléments
du circuit, longueurs et diamètres des tuyauteries, ...).
· Etape 4 - Acquisition de mesures
(pressions, températures, ...) par l'utilisateur dans la chambre et sur
les installations frigorifiques.
· Etape 5 - Diagnostic des
installations sur la base des mesures. Ici, le logiciel mettra en oeuvre une
technique de diagnostic interne, pour estimer des paramètres internes
des installations, non accessibles par la mesure ;
· Etape 6 - Redimensionnement des
installations sur la base du bilan thermique. Ceci
permettra d'obtenir
l'état nominal exigé pour un bon fonctionnement de la chambre
;
· Etape 7 - Comparaison des
états actuel et nominal, et énoncé des actions de mise
à niveau. Cette étape est réalisée par le logiciel,
qui utilisera pour cela un système à base de règles.
II.1.2 Spécifications
fonctionnelles
Compte tenu de la démarche précédente, nous
pouvons déjà ressortir, ordonner et caractériser les
fonctions à réaliser par le logiciel.
La fonction principale du logiciel est de réaliser
l'expertise technique des installations frigorifiques d'une chambre froide.
Pour rester le plus général possible, cette expertise pourra
aussi être effectuée par des prestataires de services. Dans ce
cas, la tenue à jour des informations sur des clients est
indispensable.
Pour mener à bien sa fonction principale, le logiciel
doit assumer les fonctions internes suivantes :
· Offrir à l'utilisateur des écrans de saisit
des données ;
· Faire un bilan thermique ;
· Faire un diagnostic technique des installations
frigorifiques ;
· Enoncer des actions de remise à niveau ;
· Editer des rapports après chaque étape de
l'expertise ;
· Permettre à l'utilisateur de sauvegarder son
projet pour une future consultation ;
· Permettre à l'utilisateur d'effectuer des
opérations de mise à jour dans la base de données du
logiciel.
Il est aussi important d'analyser les fonctions d'estime,
concernant l'acceptation du logiciel par l'utilisateur. Celles sur lesquelles
nous focaliserons notre attention sont les suivantes :
· Etre facile à apprendre : cela suppose des
interfaces simples, agréables et pas trop différentes de celles
utilisées actuellement dans d'autres produits logiciels (la
réutilisation de connaissances antérieures facilite la vitesse
d'apprentissage de l'utilisateur) ;
· Etre évolutif : il faut éviter de faire
un logiciel pour des configurations d'installations figées.
L'application doit donc pouvoir inclure de nouvelles configurations
d'installations sans recompilation complète du code ;
· Etre ouvert : ici, l'ouverture concernera la
possibilité de continuer sur une machine un projet d'expertise
commencé sur une autre machine. Aussi, les rapports édités
doivent pouvoir être exportés vers des éditeurs de texte
courants comme MS Word ;
· Etre fiable : il s'agira ici d'avoir une
méthodologie rigoureuse de programmation, afin de réduire plus
tard les pannes imprévues. En plus nous mettrons largement en oeuvre des
procédures de gestion d'erreurs, afin d'éviter des erreurs
fatales (avec arrêt d'exécution) pendant l'utilisation.
II.1.3 Architecture modulaire
Pour mener à bien toutes ces fonctions, le logiciel devra
comporter les modules suivants :
· Interface : c'est la partie visible du logiciel ;
· Module d'édition de rapports ;
· Module de calcul de bilan thermique ;
· Module de diagnostic interne ;
· Module de redimensionnement ;
· Module d'implémentation du système
à base de règles servant à la prise de décision
finale ;
· Module de données : ce module renferme les
bases de données utiles au calcul du bilan thermique et au diagnostic
interne. Il contient aussi le système de sauvegarde des projets
d'expertise ;
· Module d'aide : il s'agit de l'aide en ligne du
logiciel ;
· Module d'installation : il s'agit des programmes
d'installation et de désinstallation du logiciel ;
II.2 Analyse détaillée du logiciel
II.2.1 Interface
L'interface est la partie la plus importante du logiciel. De sa
qualité, dépendent entre
autres :
· La facilité d'apprentissage de l'application ;
· L'efficacité d'utilisation du logiciel ;
· L'acceptation, donc la satisfaction de l'utilisateur.
A cet effet, puisque notre développement se fait sous
Windows, nous conserverons les conventions d'interfaces Windows. Dans ce cas,
l'interface peut être à document unique (SDI : Single Document
Interface) ou à document multiples (MDI : Multiple Document Interface).
Les MDI étant plus commodes et plus répandues, ce sont elles que
nous utiliserons. Nous aurons donc :
· Une barre de titre contenant l'icône de
l'application, son titre et le nom du document en cours d'utilisation;
· Une barre de menu respectant les règles Windows
(le premier menu est `Fichier', le dernier `Aide', ...) ;
· Une barre d'outils ;
· Une barre d'état ;
· Et bien d'autres éléments propres aux
interfaces Windows.
Toujours dans cette optique d'acceptation du logiciel, nous
l'avons appelé « Fronix ». Ce nom nous paraît ressortir
le fait qu'il `agit ici d'un logiciel de froid, intégrant des
fonctionnalités d'intelligence artificielle.
II.2.2 Module d'édition des rapports
Les documents à éditer par le logiciel sont de
divers types :
· Les rapports concluants chaque étape de
l'expertise : il s'agit du rapport de calcul du bilan thermique, le rapport de
diagnostic interne, le rapport de redimensionnement et le rapport final
d'expertise ;
· Les états des informations
présentent dans les bases de données : lors des opérations
de mise à jour sur les bases de données, l'utilisateur pourra
s'il le veut éditer des états ;
· Les documents donnants des informations diverses : il
s'agit des protocoles de prise de mesure et toute autre information que l'on
voudra fournir à l'utilisateur sous forme de document.
Compte tenu de toutes ces exigences en matière
d'édition de documents, nous avons jugé nécessaire
d'inclure dans le logiciel un éditeur de texte. Les
fonctionnalités de cet éditeur seront les suivantes :
· Génération des documents issus du logiciel
;
· Mise en forme et impression des documents
générés ;
· Enregistrement des documents dans un format compatible
avec MS Word, afin d'assurer l'ouverture vers ce logiciel très
répandu ;
· Ouverture pour consultation ou modification de documents
au format de l'éditeur.
II.2.3 Module de calcul du bilan
thermique
Le but de ce module est de fixer les objectifs à
atteindre par l'expertise. Il s'agira de refaire un bilan thermique de la
chambre, en fonction des données d'exploitation actuelles. Rappelons
à cet effet que les conditions d'exploitation pour lesquelles la chambre
avait été conçue à l'origine peuvent avoir
évoluées considérablement avec le temps. Plus
concrètement, ce bilan devra nous fournir pour chaque compartiment de la
chambre :
· La température de conservation à obtenir
;
· L'humidité relative à entretenir ;
· La production frigorifique à fournir par les
évaporateurs pour un temps de fonctionnement journalier des
installations donné.
Pour y parvenir, ce module doit permettre à l'utilisateur
d'entrer de façon conviviale les données nécessaires. Ce
sont :
a) Les paramètres
géométriques
· Hauteur de la chambre ;
· Dimensions et emplacement des façades verticales
;
· Dimensions du plafond et du plancher ;
· Dimensions et emplacement des ouvertures ;
· Caractéristiques de compartimentage de la
chambre.
b) Les paramètres de constitution des parois et du
plancher
· Epaisseur de chaque couche ;
· Matériaux de chaque couche ;
· Nature des ambiances en contact avec chacune des
faces de la paroi. Dans le cas du plancher, on précisera la
présence ou non d'un vide sanitaire en dessous.
c) Les données climatiques du lieu
· Température sèche ;
· Humidité relative ;
· Température du sol : cette donnée est
indispensable dans le cas où la chambre repose sur un terre-plein (pas
de vide sanitaire) ;
· La pression atmosphérique ;
· La latitude du lieu ;
· L'altitude du lieu.
d) Les paramètres d'exploitation de la chambre
· La température et l'humidité relative
exigées dans chaque compartiment ;
· Le flux de produit journalier sur chacune des portes ;
· Le débit journalier de renouvellement d'air, dans
le cas où l'air de certains compartiments est renouvelé ;
· La quantité de denrées entrées par
jour dans chaque compartiment ;
· La quantité moyenne de denrées
végétales (produisant de la chaleur par respiration)
stockée en permanence dans chaque compartiment ;
· La puissance et le temps de marche journalier des
machines opérant dans chaque compartiment ;
· Le nombre de personnes travaillants dans chaque
compartiment, et leur temps journalier de travail ;
· Données de répartition des
évaporateurs dans les compartiments ;
· Les caractéristiques des évaporateurs :
puissance des moto ventilateurs, temps de fonctionnement journalier, puissance
du dispositif de dégivrage, temps journalier de dégivrage ;
· Le temps journalier de fonctionnement des
installations frigorifiques souhaité.
Ces données acquises, le calcul du bilan ce fait par
des formules très simples. Néanmoins, certaines
corrélations issues de l'expérience sont indispensables pour
avoir par exemples : les coefficients d'échange de chaleur par
convection entre les parois et l'extérieur ou l'intérieur, les
charges dues aux ouvertures des portes, ... .
Les calculs effectués dans le logiciel sont basés
sur les formules et corrélations indiquées dans (BREIDERT,
1998).
A ce stade, il ressort déjà que la masse de
données à acquérir est importante, et qu'il convient donc
de prendre un soin particulier à la conception des interfaces de ce
module. C'est ainsi que nous avons conçu ici une interface unique assez
conviviale, permettant d'entrer tous ces paramètres. Cette interface est
présentée dans la figure III.1.
II.2.4 Module de diagnostic interne
Ce module devra fournir l'état de chacun des
composants d'une installation à partir des observations (mesures
prélevées) faites sur cette installation. Nous avons
déjà vu que formellement, cela revenait à inverser une
relation de cause à effet donnée sous la forme :
? ?
E = F C où
( )
|
?
E est le vecteur des effets (ici, les mesures
prélevées), et
|
?
C celui des causes
|
|
(ici, les paramètres internes non accessibles par la
mesure). Les mesures prélevées seront
par exemples des
pressions, des températures, ..., et les paramètres internes
des
coefficients d'échange thermique, des vitesses de circulation de
fluides, ... . Ayant donc
?
mesuré sur l'installation un vecteur d'effets
Em , le problème revient à retrouver le(s)
meilleur(s) vecteur(s) de paramètres internes
?
Copt à l'origine des effets, en d'autres
termes
? ?
qui minimise(nt) la fonction objectif
Em - F(C)
, où · est une norme définie dans l'espace
des effets. La fonction F n'étant connue que
sous forme algorithmique, il s'est avéré que seules les
méthodes non déterministes de minimisation étaient
utilisables. A cet effet, les algorithmes génétiques sont les
plus adaptés. Ils offrent en effet le meilleur compromis entre
exploration (capacité à balayer de l'espace de recherche) et
exploitation (capacité à exploiter les résultats
déjà obtenus), caractéristiques primordiales pour des
calculs comme le notre.
A la fin de l'évolution de l'algorithme
génétique, un paramètre d'homogénéisation
des fitness est mesuré sur la population. Ce paramètre est
compris entre 0 (dispersion totale) et 100 (parfaite
homogénéisation). Il représente en fait le pourcentage
d'individus dont les fitness diffèrent du fitness minimal de moins de
10%. Dans le cas où le fitness minimal est nul, alors le critère
devient une différence de moins de 0,0001 avec le fitness minimal.
II.2.4.1 L'architecture du module
Nous avons déjà souligné que le logiciel
devra s'adapter à plusieurs types d'installations frigorifiques. C'est
pourquoi nous avons définit la notion de Configuration de Circuit
Fluidique (CCF). Cette définition englobe :
· Une description physique de la configuration : circuit
fluidique, éléments pris en compte, technologies
utilisées, ... ;
· Une description mathématique : fonction de
cause à effet (mesures à prélever, variables internes
estimées, modèles de calcul utilisés, ...) et fonction de
redimensionnement (définie par des paramètres de
redimensionnement propres à la CCF) ;
· Un système d'unité propre à la CCF :
la possibilité de pouvoir utiliser le système
d'unité
de son choix ne sera incluse que dans les prochaines versions du logiciel ;
· Une base de données regroupant toutes les
informations utiles à l'utilisation de la configuration ;
· Un module objet renfermant les fonctions de cause
à effet et de redimensionnement.
L'architecture de ce module se décompose donc en
modules objets implémentant l'algorithme génétique et les
CCF (Configuration de Circuit Fluidique). Aussi, les modules objet des CCF ont
besoin dans leurs calculs des fonctions sur les fluides frigorigènes.
Nous avons utilisé pour cela la version 2.0 de la bibliothèque
fournie par SOLVAY FLUOR UND DERIVATE, un constructeur de fluides
frigorigènes allemand. Les fonctions implémentées dans
cette bibliothèque sont présentées dans l'annexe 4. En
résumé, cette architecture se présente de la façon
suivante :
BD de la BD de la BD de la
CCF N°1 CCF N°2 CCF N°n
CCF N°1
CCF N°2
CCF N°n
BD
principale
Application
principale
Fronix
Algorithme
génétique
Fonctions sur fluides
Figure II.1 : Architecture du module de
diagnostic interne
Lors du diagnostic, l'application principale
prélèvera les paramètres nécessaires dans la base
de données principale et celle de la CCF concernée, choisie par
l'utilisateur. Ces paramètres, associés aux mesures
prélevées seront ensuite transmis au module de l'algorithme
génétique. Ce dernier saura donc sur quel module objet de CCF se
connecter, et les arguments à transmettre pour évaluer la
fonction de fitness ou celle de redimensionnement.
Les modules objets dont il est question ici seront
implémentés sous forme de bibliothèques de liens
dynamiques (Dynamic Link Library : DLL) pour plus de flexibilité dans
leur utilisation.
II.2.4.2 La fonction de cause à effet
a) Notion de variable d'état
Le diagnostic a pour but de déterminer les grandeurs
internes d'une installation, non accessibles par la mesure. Pour une CCF
donnée, certaines de ces grandeurs peuvent être
corrélées. On désignera alors par variables d'état
les éléments de tout sous-ensemble de grandeurs internes
indépendantes, et vecteur d'état un vecteur ayant pour
composantes ces variables. La connaissance du vecteur d'état
étant suffisante pour estimer l'état complet du groupe
frigorifique, c'est ce vecteur qui est estimé par l'algorithme
génétique (les individus sont des potentiels vecteurs
d'état).
b) Les variables internes
Une fois les variables d'état obtenues, le reste des
grandeurs internes peut être obtenu. C'est ce reste que nous appellerons
variables internes.
c) Les mesures
C'est l'ensemble des mesures pouvant être
prélevées, pour une CCF donnée. Le principe de diagnostic,
tel que nous l'avons définit ici a pour but de retrouver les meilleurs
paramètres internes d'une CCF conduisant aux mesures qui ont
été prélevées. De là, il ressort que lors
d'une expertise, l'on n'est pas obligé de prélever toutes les
mesures prévues pour la CCF, mais plus on aura de mesures et plus
précis sera le diagnostic. Ceci offre une plus grande souplesse
d'utilisation du logiciel, car une installation n'a pas toujours tous les
points de mesures souhaitables. C'est pourquoi dans l'application, les mesures
pour une CCF donnée sont regroupées en deux classes :
· Les mesures obligatoires : ce sont celles devant
absolument être prélevées. Elles sont indispensables aux
calculs, et garantissent à elles seules un résultat acceptable
;
· Les mesures libres : celles-ci peuvent être
prélevées ou pas. Mais plus on en prendra, et plus précis
sera le diagnostic.
Quelque soit le nombre de mesures effectuées, le
diagnostic fournira quant à lui toutes les mesures possibles, car elles
sont indispensables à la prise de décision finale. Pour chacune
des mesures prélevées, l'utilisateur pourra éditer un
protocole expérimental lui indiquant les appareils à utiliser, un
mode opératoire et les précautions à prendre pour avoir
des valeurs précises.
d) Les paramètres de l'installation
Ce sont les données « statiques » d'un
groupe frigorifique, dont a besoin le module objet de la CCF pour ses calculs.
Ce sont par exemples : les diamètres des tuyauteries, les puissances des
moteurs, le fluide frigorigène utilisé, ... .
e) Expressions des fonctions de cause à effet et de
fitness
?
|
Les mesures prises sur site sont représentées par
le vecteur
|
MS . Les causes sont
|
?
les variables d'état représentées par le
vecteur d'étatX . Pour un vecteur d'état donné,
la
fonction de cause à effet permet d'obtenir un vecteur de mesures
calculées
? ? ?
MC correspondant, soit ( )
MC = F X
?
. Le fitness du vecteur X sera alors une mesure de
la
différence entre les vecteurs
?
? ?
M S - M C
?
MS et
.
MC , nous avons pris pour cela la norme
Vi .
?
V
?
Cette norme étant définit pour un vecteur V
de composantes Vi par :
i
4 3
6
2
5
7
8
1
9
10
11
f) L'espace de recherche
L'espace de recherche est un hyper rectangle de l'espace des
variables d'étatÐ ,
?
définit par = ? Ð
X / Xi min Xi Xi max ,
i . Avant chaque diagnostic, des valeurs par
= = ?
défaut des bornes Ximin et
Ximax sont proposées à l'utilisateur, qui peut les modifier
s'il le désire.
II.2.4.3 La configuration de circuit fluidique
implémentée
a) Présentation de la configuration
Dans cette première version du logiciel, nous n'avons
implémenté qu'une seule CCF, ne concernant que les chambres
froides négatives. Il s'agit d'un circuit fonctionnant selon un cycle
mono étagé à compression mécanique de vapeurs.
Cette CCF ne modélise pas la partie électrique. Le schéma
de ce cycle dans un diagramme LogP - H est présenté à la
figure suivante :
P
|
1-2 : Compresseur
2-3 : Ligne de refoulement 3-6 : Condenseur
6-7 : Ligne liquide
7-9 : Entrée évaporateur
9-11 : Evaporateur
11-1 : Ligne d'aspiration
|
H
Figure II.2 : Cycle frigorifique de la CCF
implémentée
b) Les mesures obligatoires de la configuration Les
mesures obligatoires ici sont :
· Température entrée air évaporateur
(°C)
· Température sortie air évaporateur
(°C)
· Température entrée air condenseur
(°C)
· Température sortie air condenseur (°C)
· Pression aspiration compresseur (bar)
· Pression refoulement compresseur (bar)
· Température aspiration compresseur (°C)
· Débit volumique air évaporateur
(m3/s)
n Débit volumique air condenseur (m3/s)
n Humidité relative compartiment (%)
c) Les mesures libres
Les mesures libres sont :
n Pression sortie évaporateur (bar)
n Pression entrée condenseur (bar)
n Pression sortie condenseur (bar)
n Température entrée évaporateur
(°C)
n Température sortie évaporateur (°C)
n Température entrée condenseur (°C)
n Température sortie condenseur (°C)
n Température refoulement compresseur (°C)
d) Les variables d'état
Les variables d'état ici sont :
n Rendement isentropique compresseur
n Efficacité évaporateur
n Surchauffe enthalpique évaporateur
n Surchauffe aspiration (°C)
n Efficacité condenseur
n Sous-refroidissement enthalpique condenseur
n Débit massique frigorigène (kg/s)
n Température évaporation (°C)
n Température condensation (°C)
n Pertes de charges ligne d'aspiration (bar)
n Pertes de charges ligne liquide (bar)
n Pertes de charges refoulement - entrée condenseur
(bar)
n Désurchauffe refoulement - entrée condenseur
(°C)
n Sous-refroidissement ligne liquide (°C)
e) Les variables internes
Les variables internes ici sont :
n Vitesse entrée tuyauterie aspiration (m/s)
n Vitesse sortie tuyauterie aspiration (m/s)
n Vitesse entrée tuyauterie vapeurs surchauffées
(m/s)
n Vitesse sortie tuyauterie vapeurs surchauffées (m/s)
n Vitesse entrée tuyauterie liquide (m/s)
n Vitesse sortie tuyauterie liquide (m/s)
n Production frigorifique (W)
n Chute de pression entrée évaporateur (bar)
n Surchauffe évaporateur (°C)
· Sous refroidissement condenseur (°C)
· Volume spécifique entrée compresseur
(m3/kg)
· Volume spécifique refoulement compresseur
(m3/kg)
· Volume spécifique sortie condenseur
(m3/kg)
f) Les paramètres « statiques »
Les paramètres requis ici sont :
· Numéro Evaporateur
· Diamètre tuyauterie aspiration (m)
· Diamètre tuyauterie de refoulement (m)
· Diamètre tuyauterie de liquide (m)
· Type refroidissement compresseur (aucun, veine d'air du
condenseur ou ventilateur de tête de culasse)
· Puissance maximale de compression (W)
Certains paramètres requièrent une valeur
numérique, mais d'autres comme le type de refroidissement du compresseur
requièrent une valeur à choisir dans une liste. Ce fait est pris
en compte dans la base de données de la CCF, et géré
ensuite par l'application.
II.2.5 Module de redimensionnement
Pour une CCF donnée, le redimensionnement consiste
à retrouver les valeurs nominales de toutes les grandeurs qui ont
été estimées par le module de diagnostic. Ce module se
base sur :
· Les résultats du bilan thermique :
température et humidité relative désirées dans la
chambre, conditions climatiques extérieures et puissance frigorifique
exigée aux installations ;
· Les grandeurs estimées par le diagnostic
interne : en effet, ces grandeurs peuvent cacher des corrélations qu'il
serait intéressant de disposer pour le redimensionnement. Par exemple,
pour une CCF qui ne recalcule pas les tuyauteries, on peut retrouver le
coefficient de perte de charges linéaires d'une tuyauterie à
partir des résultats du diagnostic ;
· Des paramètres types de conception : la
surchauffe dans l'évaporateur peut par exemple être fixée
à 5°C. Pendant l'expertise, des valeurs par défaut sont
proposées à l'utilisateur qui peut décider de les
modifier.
II.2.6 Le système à base de
règles floues
Après le diagnostic et le redimensionnement, ce module
est chargé de la prise de décision finale. Il est construit
autour d'un système à base de règles floues,
modélisant ainsi au mieux le raisonnement humain.
II.2.6.1 Le principe utilisé
Les variables linguistiques ici sont propres à chaque
CCF, et représentent toutes les grandeurs traitées par la CCF
(mesures, variables d'état et variables internes). Une règle est
de la forme :
SI « Prémisse N°1 » ET «
Prémisse N°2 » ET ... ET « P rémisse N°n
» ALORS « Conclusion »
ACTIONS « Liste d'actions »
OBSERVATIONS « Liste d'observations sur site »
a) Les prémisses
Une prémisse est une proposition floue dont la forme
générale est :
« Variable » + « Modificateur » + «
Adjectif »
· « Variable » est un nom de variable
traité par la CCF (mesure, variable d'état ou variable interne)
;
· « Modificateur » est un modificateur
linguistique. Nous avons utilisé « Aucun » (dans le cas
où il n'y a aucune modification), « Très » (tel que
définit par (4)) et « Plus ou moins » (tel que définit
par (5)) ;
· « Adjectif » représente un terme
linguistique, et peut valoir « Normal », « Faible » ou
« Elevé ».
b) La conclusion C'est l'énoncé de la
conclusion faisant suite aux prémisses.
c) Les actions Ce sont les actions de mise à
niveau à prendre quand les prémisses sont
vérifiées.
d) Les observations
Il s'agit des effets observables sur l'installation quand les
prémisses sont vérifiées. Elles permettent ainsi de
confirmer par soi même un résultat d'expertise.
II.2.6.2 L'évaluation des règles
L'inférence ici consiste en une simple
évaluation des règles. Un chaînage n'est en effet pas
nécessaire à cause du grand nombre de variables de
décision généré par l'algorithme
génétique. L'évaluation d'une règle n'est rien
d'autre que le calcul de la valeur de vérité de la conjonction
des prémisses de ladite règle.
a) Fonctions d'appartenance des termes linguistiques
A cette étape de l'expertise, on dispose pour chaque
variable de deux valeurs : une obtenue après diagnostic (VD) et l'autre
après redimensionnement (VR). Soit T% une tolérance fixée
entre 0 et 100%. Posons :
· B1 = T% x VR, avec B1 = 0,01 si VR=0 ;
· B2 = 1,5 x T% x VR, avec B2 = 0,015 si VR=0 ;
· B3 = 2 x T% x VR, avec B3 = 0,02 si VR=0.
Il nous a alors parut judicieux de définir les fonctions
d'appartenance des termes linguistiques comme suit :
P(VD)
1
Terme « Normal »
0
VR - B2 VR - B1 VR VR + B1 VR + B2
VD
Figure II.3 : Fonction d'appartenance du terme
« Normal »
P(VD)
VR - B3 VR - B1 VR VD
1
Terme « Faible »
0
Figure II.4 : Fonction d'appartenance du terme
«Faible »
P(VD)
1
Terme « Elevé »
0
VR
VR + B1 VR + B3 VD
Figure II.5 : Fonction d'appartenance du terme
«Elevé »
La tolérance T% est fixée par l'utilisateur pour
chacune des règles, mais la valeur par défaut est 10%. Ce
paramètre permet de moduler la forme des fonctions d'appartenance.
b) Evaluation
A l'aide des fonctions d'appartenance
précédentes et des transformations de modification données
par (4) et (5), on peut évaluer chacune des prémisses pour des
valeurs de VR et VD données. La valeur de vérité de la
conjonction des prémisses d'une règle sera obtenue à
partir d'une conjonction très utilisée en inférence floue.
Elle est définie comme suit :
Soient deux variables linguistiques X et Y, TX et TY deux
termes (éventuellement modifiés) s'y référant, de
fonctions d'appartenance respectives ìX (x)
et ìY (y) .
Alors la proposition floue « X est TX ET Y est TY »,
a pour fonction
d'appartenance ì( x , y ) =
Min[ì X ( x),
ìY (y)] .
Ainsi, si la prémisse N°i a pour valeur d'apparten
ance ìi , alors la valeur de vérité
associée à la règle est ( i )
ì = Min ì .
i
c) La prise de décision
Une fois la valeur de véritéì de
la conjonction des prémisses connue pour chaque
règle, il faut prendre des décisions. Pour cela,
nous avons définit deux seuils :
· Le seuil S1 de décision «
Vrai » : si ì = S1 , alors on
décide que les prémisses sont
vraies, et que la conclusion de la règle est
vérifiée ;
· Le seuil S2 de décision «
Faux » : si ì = S2 , alors on
décide que les prémisses ne
sont pas toutes vraies, et que la conclusion correspondante est
fausse.
Dans le cas où S 2 = ì =
S1, alors le système ne peut rien conclure. On
obtient ce
que nous avons appelé « conclusion
indécidable ». Dans ce cas, il est préférable que
l'utilisateur fasse un tour sur l'installation pour voir si l'observation
correspondante, proposée dans l'énoncée de la règle
s'est manifestée ou pas. Ce dernier pourra ensuite modifier les seuils
ou la tolérance de la règle en question pour affiner les
décisions futures.
II.2.6.3 L'éditeur de règles
Pour plus de flexibilité dans les décisions,
nous avons prévu un éditeur de règles dans l'application.
Pour une CCF donnée, cet éditeur pourra permettre à
l'utilisateur de réaliser les tâches d'ajout, de modification, de
suppression et d'édition d'états de règles. La figure
III.4 du chapitre suivant montre l'interface de cet éditeur. L'annexe 5
présente un extrait de l'état des règles de base fournies
avec la CCF actuellement disponible.
II.2.7 Module de données
Ce module comporte deux parties : les bases de données du
logiciel et le système de gestion des fichiers
générés.
II.2.7.1 Les bases de données
Dans Fronix, nous avons implémenté deux types de
base de données :
· Les bases de données attachées chacune
à une Configuration de Circuit Fluidique (CCF). C'est là que
l'application puise les informations nécessaires à la
manipulation de la CCF ;
· Une base de données principale. Elle renferme
les informations nécessaires à l'expertise, et ne concernant pas
directement une CCF.
a) Les bases de données des CCF
Selon l'architecture de l'application (Figure II.1) chaque
CCF est indépendante des autres, et a sa propre base de données.
Pour une CCF donnée, cette base de données est chargée de
gérer les informations suivantes :
· Les mesures traitées par la CCF : ces mesures sont
regroupées en mesures obligatoires et en mesures libres ;
· Les paramètres de groupes frigorifiques requis par
le module de calcul de la CCF ;
· Les paramètres utilisés par le module de
calcul de la CCF pour les redimensionnements. Une valeur par défaut est
spécifiée pour chacun de ces paramètres ;
· Les variables d'état utilisées par la
CCF : les bornes minimale et maximale sont spécifiées pour
chacune des variables, et servent comme bornes par défaut à
l'espace de recherche de l'algorithme génétique ;
· Les variables internes utilisées par la CCF
;
· Les règles floues d'expertise de groupes
frigorifiques ayant la CCF en question.
Ici, le modèle conceptuel a été fait
dans le formalisme entités-relations selon Merise (technique
française par excellence de conception de systèmes
d'information), et le modèle logique dans le formalisme relationnel. La
figure suivante montre les informations relatives aux prémisses et aux
règles floues dans le formalisme entités-relations. Par soucis
d'allègement, nous ne présentons pas le modèle conceptuel
en entier.
PREMISSES
Numéro
Numéro variable
Numéro modificateur Numéro adjectif
Libellé
REGLES
Numéro
Libellé conclusion
Libellé action
Libellé observation
Seuil de décision `'Vrai» Seuil de
décision `'Faux» Tolérance
1,1
Appartient à 1,n
Figure II.6 : Prémisses et
règles floues dans le formalisme entités-relations
Les attributs soulignés représentent les
identifiants uniques (clé d'identification). Les variables
d'inférence sont dans l'ordre : variables d'état, variables
internes et mesures. Elles sont numérotées dans cet ordre
à partir de 0. L'attribut « Numéro variable » de
l'entité PREMISSES est issu de cette numérotation.
Les numéros de modificateurs sont :
· 0 - Aucun
· 1 - Plus ou moins
· 2 - Très
Les numéros d'adjectifs sont :
· 0 - Normal
· 1 - Elevé
· 2 - Faible
Il est évident que l'attribut « Libellé
» de l'entité PREMISSES peut être obtenu à partir des
autres attributs, mais nous avons décidé de le garder. Dans le
cas contraire, la complexité du module de prise de décision
aurait été plus grande, et nous avons jugé qu'il valait
mieux ajouter cet attribut, quitte à augmenter très
légèrement l'espace mémoire nécessaire au stockage
des données.
La transcription dans le formalisme relationnel du
modèle précédent se résume en les deux tables
relationnelles suivantes, où les champs soulignés
représentent les clés primaires :
PREMISSES
Numéro
Numéro règle
Numéro variable
Numéro modificateur Numéro adjectif
Libellé
|
|
REGLES
Numéro
Libellé conclusion
Libellé action
Libellé observation
Seuil de décision `'Vrai» Seuil de
décision `'Faux» Tolérance
|
|
Figure II.7 : Prémisses et
règles floues dans le formalisme relationnel
b) La base de données principale
Elle renferme les informations relatives aux rubriques suivantes
:
· Les clients : l'utilisateur du logiciel est peut
être un prestataire de services en matière d'expertise de chambre
froides ;
· Les chambres froides : il s'agit des chambres froides des
clients ;
· Les matériaux : le logiciel a besoin d'une banque
de matériaux (avec leurs propriétés physiques) pour le
bilan thermique ;
· Les produits : l'application a besoin d'une banque de
produits pour le bilan thermique ;
· Les profils climatiques : les profils climatiques
utilisés dans les projets d'expertise sont explicités dans cette
base de données ;
· Les villes : chaque profil climatique appartient à
une et une seule ville ;
· Les pays : toute ville appartient à un pays unique
;
· Les CCF : chaque CCF disponible est
spécifiée dans la base de données principale. Cette
spécification inclut les paramètres par défaut de
l'algorithme génétique à utiliser avec la CCF.
Cette base de donnée a aussi été
conçue selon la démarche Merise. Le formalisme
entités-relations résultant a ensuite été traduit
dans le formalisme relationnel pour l'implémentation.
II.2.7.2 Le système de gestion des fichiers
générés
a) Le modèle conceptuel
Dans le cas des bases de données
précédentes, nous ne nous sommes pas intéressés
à l'implémentation physique des données. La raison est que
ces bases seront implémentées dans un Système de Gestion
de Bases de Données (SGBD), qui par essence permet la manipulation de
modèles logiques de données sans se soucier de la couche physique
(gestions des index, des pointeurs, ...) qui est totalement transparente.
Ici par contre, nous sommes directement concernés par
l'implémentation physique, car il s'agit d'enregistrer sur disque dur un
projet d'expertise achevé ou en cours. Cela ne peut se faire
efficacement qu'en considérant les possibilités offertes par le
langage de programmation d'implémentation, qui est Visual Basic 6 dans
notre cas. Les informations à enregistrer sont :
· Les options du projet : date de début, nom du
projeteur, nom du client, nom de la chambre, profil climatique utilisé
et commentaires sur le projet ;
· Les informations relatives au bilan thermique : il s'agit
des données concernant les façades, les ouvertures, les
compartiments et les évaporateurs ;
· Les informations relatives au diagnostic : il s'agit
des données sur les groupes frigorifiques et les données obtenues
par l'algorithme génétique (mesures, variables d'état et
variables internes).
Le modèle conceptuel a encore été fait
dans le formalisme entités-relations selon Merise. Pour
l'implémentation, ce modèle a en ensuite été
transcrit dans le formalisme enregistrements-ensembles (records-sets), en
tenant compte des possibilités de Visual Basic. La principale
caractéristique de Visual Basic exploitée ici est la gestion
dynamique de la mémoire. Ainsi, le nombre d'entités
(façades, ouvertures, groupes frigorifiques, ...) utilisable dans le
logiciel n'est limité que par l'espace d'adressage maximal allouable par
Windows lors de l'exécution de l'application. Les structures de
données utilisées par exemple pour gérer les informations
sur le diagnostic interne se présentent comme suit :
Public Type Grandeur 'Type de donnée des mesures et des
variables Nom As String * 100
Valeur As Double
Numéro As Long
End Type
Public Type Paramètre 'Type de donnée
paramètre sur un groupe Nom As String * 100
Type As Byte '0 si numérique, 1 sinon
ValeurNum As Double ValeurStr As Byte Numéro As Long
End Type
Public Type Groupe 'Type de donnée d'un groupe
frigorifique CodeCCF As String * 100
Refrig As String * 100 Valider As Boolean
ListeMesures() As Grandeur ListeParam() As Paramètre
ListeVarEtat() As Grandeur ListeVarInt() As Grandeur ListeMesCalc() As
Grandeur
End Type
'Déclaration du tableau dynamique destiné à
contenir les données sur les groupes frigorifiques 'et qui sera
écrit dans les fichiers *.fnx
Public MesGroupes() As Groupe
Figure II.8 : Structure des données pour
le diagnostic interne
Les enregistrements ici sont : « Grandeur
», « Paramètre » et « Groupe
». Il y a un seul ensemble d'enregistrements : «
MesGroupes() ». Toutes les variables ou membres de types dont la
définition se termine par « () » sont des tableaux
dynamiques. Comme l'enregistrement « Groupe » en compte
beaucoup (ListeMesures(), ListeParam(), ...), il est donc
impossible de prévoir la taille d'un enregistrement du tableau
MesGroupes(). Il en est de même pour beaucoup d'autres
enregistrements crées dans ce module.
b) L'implémentation physique
Dans Visual Basic, il y a trois principaux modes de
création de fichiers :
· Séquentiel : il s'agit généralement
de fichiers texte ;
· Aléatoire : il s'agit des fichiers
constitués d'une succession d'enregistrements de même type et de
même longueur ;
· Binaire : les données peuvent être de
n'importe quel type. Elles sont lues octet par octet. Ce mode est le plus
souple et le plus économique en terme d'espace, mais il implique la
connaissance de la signification exacte de chaque groupe d'octets dans le
fichier, afin de les interpréter convenablement.
A ce stade, il est évident que le mode binaire est le
plus indiqué pour nos structures de données (enregistrements de
tailles différentes et non prévisibles). Pour garder la
signification de chacune des informations écrites, nous avons
définis deux entiers non signés codés sur un octet
(variant entre 0 et 255) :
· NType : c'est un numéro identifiant un
enregistrement. Par l'exemple, pour l'enregistrement « Groupe
» NType = 9 ;
· NSType : c'est un numéro valide dans un
enregistrement, et identifiant un attribut donné. Par exemple, pour
l'attribut ListeMesures() de « Groupe » NSType =
4.
A chaque donnée écrite dans le fichier, nous
ajoutons donc un descripteur de deux octets (NType et NSType) devant permettre
de retrouver la signification de l'information lors de la lecture du fichier.
Le schéma suivant illustre ce principe :
Descripteur Information utile
Figure II.9 : Principe de codification des
données à enregistrer
II.2.8 Autres modules
II.2.8.1 Le Module d'aide
L'aide en ligne est un composant essentiel des applications
sous Windows. L'acceptation du logiciel par l'utilisateur en dépend
beaucoup. Il doit permettre une maîtrise rapide du logiciel, même
dès la première utilisation. Après analyse de nombreux
fichiers d'aide sous Windows, nous avons choisit de structurer le notre comme
suit :
· Présentation de Fronix
· Utilisation de Fronix
- Conventions de l'interface
- Editeur de texte intégré
- Commencer un projet
- Faire un bilan thermique
- Estimer l'état interne
- Lancer une expertise
- Menu des données
- Editeur de règles
· Informations supplémentaires
- L'architecture évolutive de Fronix - L'algorithme
génétique
- Les principes de la logique floue - Présentation de
l'auteur
II.2.8.2 Le Module d'installation
Il s'agit ici des programmes d'installation et de
désinstallation. Pour un maximum de flexibilité, ces programmes
peuvent être écrits par nous même, mais il existe un grand
nombre d'utilitaires permettant de générer des programmes
satisfaisants. Pour cette première version (qui est aussi une version
d'essai), nous n'avons prévu aucun mécanisme de gestion de
licences utilisateurs. En plus, aucune authentification du logiciel n'est
encore faite auprès de la base des registres du système
hôte. Le programme d'installation effectue donc les tâches
minimales suivantes :
· Installer les composants du logiciel sur la machine
hôte ;
· Installer les composants systèmes
nécessaires au fonctionnement sur la machine hôte ;
· Créer des raccourcis d'exécution du
logiciel à partir du bureau et du menu « Programmes » de la
machine hôte.
En plus du programme d'installation, un autre de
désinstallation accessible à partir du menu « Programmes
» devra permettre le retrait du programme de la machine hôte.
Enfin, comme on travaille sous Windows, un fichier de
commandes « Autorun.inf » placé dans la racine du CD ROM du
logiciel, permettra de lancer automatiquement le programme d'installation
dès la lecture dudit CD ROM. Les commandes réalisant cette action
sont :
[AutoRun] open=Fronix.exe
|
|
Figure II.10 : Commandes du fichier
Autorun.inf
« Fronix.exe » représente le programme
d'installation, lui aussi placé dans la racine du CD ROM.
CHAPITRE III. MATERIEL INFORMATIQUE
ET
IMPLEMENTATION
III.1 Plate-forme de
développement
La plate-forme de développement regroupe toutes les
ressources informatiques avec lesquelles l'application a été
développée. On peut les regrouper en ressources
matérielles et ressources logicielles.
III.1.1 Les ressources
matérielles
L'ordinateur utilisé est un PC. Ses principales
caractéristiques sont :
· Processeur : 735 Mhz, 32 bits, coprocesseur
arithmétique intégré ;
· RAM : 128 Mo ;
· Taille du disque dur : 20 Go ;
· Moniteur : 17»
III.1.2 Les ressources logicielles
· Le système d'exploitation : celui utilisé
est Windows XP Professionnel, travaillant avec le système de gestion de
fichiers FAT32 ;
· Les outils de développement : notre application
présente deux grandes exigences : une interface hyper conviviale et une
grande puissance de calcul. Pour développer rapidement et efficacement
nos interfaces, nous avons utilisé Visual Basic 6 Edition Entreprise qui
est très adapté pour cela. Par contre, ce langage n'est pas
approprié pour de lourds calculs. C'est pourquoi les modules de calcul
ont été implémentés sous Visual C++ 6 Edition
Entreprise ;
· Le Système de Gestion de Base de Données
(SGBD) : nous avons utilisé MS ACCESS XP, qui est un SGDB relationnel
;
· Utilitaires divers : pour la création de
fichiers d'aide, nous disposions de Help Workshop et HTML Help. Nous avons
utilisé ce dernier, car il donne de meilleurs résultats en terme
de convivialité. Pour le programme d'installation, nous avions le choix
entre l'utilitaire d'empaquetage fournit en support de Visual Basic, Inno Setup
Compiler et GkSetup version 1.93. Pour connaître rapidement les
composants systèmes à distribuer avec notre application, nous
avons utilisé l'utilitaire d'empaquetage. Mais c'est avec GkSetup qui
est plus souple d'emploi que nous avons généré le
programme d'installation proprement dit, sous forme de paquet auto extractible.
L'autre avantage de GkSetup est qu'il permet de générer
automatiquement un programme de désinstallation standard, devant retirer
le logiciel d'une machine donnée. Pour éviter toute complication,
ce programme de désinstallation de touche à aucun composant
système de la machine hôte.
III.2 Implémentation sous MS Access XP
III.2.1 Présentation de MS Access XP
MS Access est un Système de Gestion de Bases de
Données (SGBD) relationnel. Les SGBD sont nés au début des
années 60 lors du programme lunaire américain Apollo. Le
principal avantage d'un SGBD est la transparence de sa couche physique de
gestion des données. L'utilisateur ne se préoccupe donc que de la
signification logique des données, ce qui lui facilite amplement la
tâche.
III.2.2 Tâches effectuées sous MS Access
XP
Toutes les bases de données de l'application ont
été implémentées dans MS Access. Les contraintes
d'intégrité prises en compte ici sont :
· Les contraintes sur domaines de valeurs d'attributs :
elles contrôlent les valeurs entrées dans les tables. Il s'agit
des types de données, de la plage admissible et la possibilité ou
non d'avoir des valeurs NULL (inconnues) ;
· Les contraintes d'unicité de clés : elles
garantissent la non répétition de valeurs dans une clé
primaire de table ;
· Les contraintes référentielles : elles
agissent sur les tables liées (comme les tables de la figure II.7). Il
s'agit ici de savoir comment la suppression d'un enregistrement d'une des
tables influencera ses enregistrements liés dans l'autre table. Nous
n'avons effectué liaisons suivantes :
- Clients/Chambres, Profils climatiques/Villes et Villes/Pays
: ici, quand un enregistrement d'une table est supprimé de la base de
données, ses correspondants dans l'autre table ne sont pas
retirés automatiquement. C'est l'utilisateur qui, s'il le désire
pourra les supprimer ;
- Règles/Prémisses (Figure II.7) : ici, quand
une règle est supprimée, toutes ses prémisses le sont
aussi. Cette contrainte n'est pas gérée par MS Access, mais
plutôt par le code Visual Basic de l'éditeur de règles.
III.3 Implémentation sous Visual Basic 6
III.3.1 Présentation de Visual Basic 6
Visual Basic est un langage de 4ème
génération. Ses débuts remontent à plus de vingt
ans, avec le fameux BASIC (Beginners All purposes Symbolic Instructions Code)
de Bill Gates, qui était très populaire à cause de son
apprentissage facile. Avec l'ère des interfaces graphiques, Visual Basic
a conservé cette simplicité d'utilisation, qui fait de lui le
plus utilisé actuellement (KIRSTEIN, 1999) pour les
développements sous Windows.
La programmation sous Visual Basic est purement visuelle et
évènementielle. Elle permet de manipuler aisément
pratiquement tous les objets graphiques de Windows. En plus des
propriétés et des méthodes de la théorie classique
des objets, les objets graphiques ont des évènements auxquels ils
peuvent répondre (Click, Double click, Déplacement, ...). Il
s'agit d'objets COM (Component Object Model). COM est
modèle centré objet assurant l'interopérabilité au
niveau binaire entre des objets de technologie Microsoft (GARDARIN, 2000).
C'est par exemple à travers ce modèle que sous Windows Word et
Excel (deux composants COM) peuvent communiquer entre eux.
Les objets de base de la programmation sont les feuilles, sur
lesquelles peuvent être rajoutés d'autres objets COM (boutons de
commandes, libellés, ...), encore appelés « contrôles
». A chaque feuille, est associée un module de classe, où
sont définies les procédures (évènementielles ou
non) de manipulation de la feuille. Il existe deux types de feuilles :
· Les feuilles MDI (Multiple Documents Interface) : il
s'agit d'une zone de travail dans laquelle plusieurs feuilles filles peuvent
être affichées. On peut en mettre une seule par application ;
· Les feuilles standard : elles peuvent ou non
être considérées comme filles d'une MDI.
Il est aussi possible de créer des modules standard, non
liés à des feuilles.
III.3.2 Tâches effectuées sous Visual
Basic 6
Nous présentons ici quelques grandes lignes du
développement effectué sous Visual
Basic.
a) La feuille de bilan thermique
La feuille de bilan thermique est une fille de la MDI. Pour un
maximum de convivialité, les contrôles principaux utilisés
ici sont :
· Le contrôle TreeView : il permet d'afficher dans
une arborescence les éléments de la chambre froide
(façades, ouvertures, compartiments, évaporateur ...) ;
· Le contrôle PictureBox : il offre à
l'utilisateur une visualisation en temps réel de la chambre qu'il
décrit. Chaque fois qu'un élément graphique
(façade, ouverture et compartiment) est sélectionné dans
l'arborescence, se dernier prend une couleur particulière dans le
graphique, permettant ainsi de situer l'élément en question ;
· Des contrôles Frame : en les superposant, on
peut offrir de nombreuses fonctionnalités dans un espace restreint de la
feuille. C'est ainsi que les caractéristiques des éléments
de la chambre sont saisis dans une même zone, la configuration de cette
zone changeant automatiquement en fonction de l'élément en cours
d'utilisation ;
· Le contrôle ToolsBar : il offre à
l'utilisateur une barre d'outils renfermant des commandes utiles à la
réalisation du bilan thermique.
Pendant l'exécution, cette fenêtre est accessible
à partir du menu Exécution et se présente comme
suit :
Figure III.1 : Fenêtre principale de
calcul du bilan thermique
b) La feuille d'estimation de l'état interne
La feuille d'estimation de l'état interne (diagnostic)
est une fille de la MDI. Pour un maximum de convivialité, les
contrôles principaux utilisés ici sont :
· Le contrôle TreeView : il permet d'afficher dans
une arborescence les groupes frigorifiques de la chambre froide ;
· Le contrôle PictureBox : chaque Configuration de
Circuit Fluidique (CCF) a une image propre, qui est affichée dans ce
contrôle ;
· Le contrôle MSFlexGrid : il a l'apparence d'une
grille de données, et est utilisé pour afficher les mesures
à prendre sur un groupe frigorifique donné ;
· Le contrôle ToolsBar : il offre à
l'utilisateur une barre d'outils renfermant des commandes utiles à
l'estimation de l'état interne des groupes frigorifiques.
Pendant l'exécution, cette fenêtre est accessible
à partir du menu Exécution et se présente comme
suit :
Figure III.2 : Fenêtre principale du
diagnostic interne
c) L'éditeur de texte
L'éditeur de texte est construit autour du
contrôle RichTextBox, dont les propriétés et
méthodes offrent déjà pratiquement toutes les
fonctionnalités requises. Il est accessible à partir du menu
Edition et se présente comme suit :
Figure III.3 : Affichage de l'éditeur de
texte
d) L'éditeur de règles
Cet éditeur est accessible à partir du menu
Edition. Il permet à l'utilisateur d'ajouter, de modifier ou de
supprimer des règles de décision à la CCF de son choix. Il
se présente comme suit :
Figure III.4 : Affichage de l'éditeur de
règles
e) Les principes de connexion aux bases de données
Comme dans tout environnement Client-Serveur typique, la
connexion à une base de donnée demande un médiateur
compatible et un langage d'interrogation. Sous Windows, le médiateur le
plus utilisé pour accéder à des bases de données
Access locales est Microsoft Jet, et le langage d'interrogation est le SQL.
Mais quelque soit le médiateur utilisé, Visual Basic 6.0 propose
une interface de niveau application, composée d'un jeu d'objets (ADO :
Active X Data Objects) d'accès uniforme aux sources de données,
qu'il s'agisse de bases de données relationnelles ou non, les
systèmes de fichiers, de courrier électronique, les
données texte, ... . Les principaux objets ADO sont :
· Connection : il permet d'établir la connexion avec
le fournisseur de données ;
· Command : il définit les opérations
à éxécuter sur la source de données. Dans notre
cas, il s'agit de requêtes SQL ;
· RecordSet : il représente un jeu d'enregistrements
(résultat d'une requête), et offre des méthodes de
manipulation de ces enregistrements.
Le code suivant donne un exemple d'utilisation d'objets ADO pour
ouvrir la table MATERIAUX de la base de donnée principale :
'Chemin d'installation du logiciel sur le disque Public Const
strInstal$ = "
C:\FRONIX\"
'Chaîne de connexion à la base de données
principale
Public Const strConnec$ = "PROVIDER=Microsoft.Jet.OLEDB.4.0;Data
Source=" & strInstal & "SUPP0RT\Frxbd.mdb;"
'Déclaration des objets ADO
Dim WithEvents rsConst As Recordset Dim cnnADO As New
ADODB.Connection Dim cmdADO As New ADODB.Command
'Instancier le RecordSet
Set rsConst = New Recordset
'Etablir la connection cnnADO.ConnectionString = strConnec
cnnADO.Open
'Configurer la commande
cmdADO.ActiveConnection = cnnADO cmdADO.CommandText = "SELECT Nom
FROM MATERIAUX"
'Configurer et ouvrir le Recordset rsConst.CursorLocation =
adUseClient rsConst.CursorType = adOpenDynamic rsConst.LockType =
adLockReadOnly rsConst.Open cmdADO
Figure III.5 : Exemple de code de connexion
à la base de données
f) L'appel de procédures externes
Par procédures externes, nous entendons les fonctions
de l'interface de programmation de Windows (Windows API : Application
Programming Interface), l'API du compilateur de fichiers d'aide (HtmlHelp) et
les DLL de l'application. Sous Windows, il y a deux manières
d'accéder à une DLL lors de l'exécution d'une application
:
· La DLL peut être chargée automatiquement
lors du chargement en mémoire de l'application ou d'une portion de
l'application dont la portée contient la déclaration de la DLL.
On parle alors de liaison dynamique au chargement (load time dynamic linking).
C'est ce mode de liaison que nous avons utilisé pour la DLL de
l'algorithme génétique et les fonctions des l'API de Windows et
de HtmlHelp ;
· La DLL peut être chargée dans l'espace
d'adressage de l'application pendant l'exécution, au moment voulu. On
parle alors de liaison dynamique à l'exécution (run time dynamic
linking). Une fois chargée, la bibliothèque peut être
manipulée à partir de son handle. Les handles sont des
descripteurs utilisés par Windows pour identifier de façon unique
des objets ou des contextes de périphériques (liaisons entre
Windows et des périphériques de sortie). Le « run time
dynamic linking » est indispensable lorsque le nom de la DLL à
appeler ne sera connu que pendant l'exécution. C'est le cas en ce qui
nous concerne pour les DLL des CCF, car c'est l'utilisateur qui décide
avec quelle CCF travailler. Ce sont les fonctions LoadLibrary() et
FreeLibrary() de l'API de Windows qui permettent respectivement de
charger et de décharger une DLL pendant l'exécution. Après
avoir chargé la DLL dans l'espace
d'adressage de l'application, LoadLibrary() renvoie
le handle du module chargé. Après le chargement d'une DLL de CCF,
c'est ce handle qui est envoyé à la DLL de l'algorithme
génétique, qui saura alors où retrouver les points
d'entrée des fonctions dont il a besoin. La DLL des fluides
frigorigènes est aussi manipulée par ce même principe.
L'exemple de code suivant montre comment les fonctions
LoadLibrary() et FreeLibrary() sont déclarées
(load time dynamic linking), et utilisées pour charger puis
décharger la bibliothèque des fluides frigorigènes (run
time dynamic linking).
'Fonction de chargement de bibliothèque de l'API de
Windows
Public Declare Function LoadLibrary Lib "kernel32" Alias
"LoadLibraryA" _ (ByVal lpLibFileName As String) As Long
'Fonction de déchargement de bibliothèque de l'API
de Windows
Public Declare Function FreeLibrary Lib "kernel32" (ByVal
hLibModule As Long) As Long
'Handle de la dll des fluides Public RefDLL As Long
'Charger la bibliothèques des fluides
Dim strBuf$
strBuf = "
C:\FRONIX\BIBLIO\REF_CALC32.dll"
RefDLL = LoadLibrary(strBuf)
If RefDLL = 0 Then
Beep
MsgBox "Fronix n'arrive pas à charger le fichier
C:\FRONIX\BIBLIO\REF_CALC32.dll",
_ vbCritical
Exit Sub
End If
'Utilisation du pointeur RefDLL
'Décharger la bibliothèque des fluides
Dim lngBuf&
lngBuf = FreeLibrary(RefDLL)
If lngBuf = 0 Then
strBuf = "
C:\FRONIX\BIBLIO\REF_CALC32.dll"
Beep
MsgBox "Une erreur est survenue lors du déchargement du
fichier " & Chr(10) & _ "
C:\FRONIX\BIBLIO\REF_CALC32.DLL",
vbCritical
Exit Sub End If
|
|
Figure III.6 : Exemple de code de chargement de
DLL
III.4 Implémentation sous Visual C++
6
III.4.1 Présentation de Visual C++
6
Le langage C a été crée en 1972 dans les
laboratoires AT&T Bell par Denis Ritchie avec un objectif précis :
écrire un système d'exploitation (UNIX). Mais sa
simplicité d'expression et sa rapidité d'exécution l'ont
très vite fait adopter par une large communauté de programmeurs.
Toujours chez AT&T, Bjarne Stroustrup développa au début des
années 80 le C++, qui reprend le C en y apportant des évolutions.
L'amélioration la plus importante apportée par le C++ est la
possibilité de faire de la programmation orientée objet. Visual
C++
est le compilateur C++ de Microsoft, fournissant en plus des
facilités pour la programmation visuelle sous Windows.
III.4.2 Tâches effectuées sous Visual
C++ 6
Nous présentons ici quelques grandes lignes du
développement effectué sous Visual C++. Toutes les fonctions
présentées ici retournent un entier court (« short »)
valant 0 si le calcul s'est déroulé avec succès. Dans le
cas contraire, elles retournent un code d'erreur positif. Mais quand nous
parlerons de données retournées, il ne s'agira que de celles qui
sont indispensables à l'expertise, et transmises par adresse aux
fonctions correspondantes.
a) Les DLL de CCF
La DLL de chaque Configuration de Circuit Fluidique exporte les
fonctions suivantes :
· fnCCF1 : c'est la fonction d'adaptation
utilisée par l'algorithme génétique. Elle reçoit en
entrée les mesures prélevées sur un groupe frigorifique
donné, les paramètres de ce groupe, le fluide frigorigène
à utiliser, le handle de la bibliothèque des fluides
(chargée par le code de l'application principale écrit en Visual
Basic) et les variables d'état (individu transmis par l'algorithme
génétique, et dont on veut connaître le fitness). En
retour, cette fonction renvoie une valeur indiquant l'écart entre les
mesures prélevées et les mesures calculées à partir
des variables d'état entrées ;
· fnCCF2 : à la fin du diagnostic, quand
l'algorithme génétique a trouvé des variables
d'état acceptables, cette fonction permet d'avoir les grandeurs de
décision restantes (variables internes et toutes les mesures possibles,
qu'elles aient été prélevées ou pas) ;
· fnCCF3 : c'est la fonction de redimensionnement. Elle
reçoit en entrée toutes les grandeurs actuelles d'un groupe
frigorifique donné (paramètres, variables d'état,
variables internes et mesures calculées), les paramètres de
dimensionnement (surchauffes admissibles, efficacités types des
échangeurs, ...), le fluide frigorigène à utiliser et le
handle de la bibliothèque des fluides chargée. En retour, elle
fournit des valeurs nominales pour les grandeurs transmises et un rapport de
calcul.
Le code suivant montre les déclarations de ces
fonctions.
#define CCF_API __declspec(dllexport)
//Fitness de l'AG de détermination de l'état
actuel
CCF_API short fnCCF1(
LPSTR hRef, //Nom du fluide utilisé
HINSTANCE RefDLL, //Handle de la dll des fluide chargée
depuis Fronix
double *norme, //Norme de retour (fitness)
double *param, //Paramètres de la CCF
double *varetat, //Variables d'état
int *nmes, //Nombre de mesures prélevées
double *mesurem, //Mesures prises sur site
int *maskmes //Masque des mesures
);
//Fonction de retour des variables internes et des mesures
obtenues par simulation CCF_API short fnCCF2(
LPSTR hRef, //Nom du fluide utilisé
HINSTANCE RefDLL, //Handle de la dll des fluide chargée
depuis Fronix
double *param, //Paramètres de la CCF
double *varetat, //Variables d'état
double *varint, //Variables internes
double *mesurem, //Mesures prises sur site
double *mesurec //Mesures issues de la simulation
);
//Fonction de retour des variables type issues de la
reconception CCF_API short fnCCF3(
LPSTR hRef, //Nom du fluide utilisé
HINSTANCE RefDLL, //Handle de la dll des fluide chargée
depuis Fronix
double *varobj, //Variables objectif issues du bilan
thermique
double *param, //Paramètres de la CCF
double *paramre, //Paramètres de reconception de la
CCF
double *varetac, //Variables d'état actuelles
double *varinac, //Variables internes actuelles
double *mesac, //Mesures actuelles
double *varetre, //Variables d'état après
reconception (à retourner)
double *varinre, //Variables internes après reconception
(à retourner)
double *mesre, //Mesures après reconception (à
retourner)
LPSTR *rapport //Rapport de la reconception (à
retourner)
);
|
|
Figure III.7 : Déclaration des fonctions
des DLL de CCF
b) La DLL de l'algorithme génétique
Cette DLL exporte deux fonctions :
~ La fonction de diagnostic : c'est elle qui met en oeuvre le
diagnostic par algorithme génétique. Elle recoit les
paramètres de l'algorithme génétique, les mesures
prélevées, le fluide frigorigène à utiliser et les
handles de la DLL de la CCF à utiliser et celle des fluides
chargée. En sortie, cette fonction renvoie le fitness minimal de la
dernière génération, le paramètre
d'homogénéisation de cette génération, et toutes
les variables de décision nécessaire à la CCF (variables
d'état, variables internes et mesures) ;
~ La fonction de reconception : elle a une signature
identique à la fonction fnCCF3 précédemment
présentée, sauf qu'en plus ici le handle de la DLL de la CCF
concernée est aussi transmis en entrée.
Le code suivant montre les déclarations de ces fonctions
:
#define AG_API __declspec(dllexport)
AG_API short __stdcall AlgoGen(
int taille, //Taille de la population
int iter, //Nombre de génération à
simuler
double ps, //Probabilité de sélection après
tournoi
double pmin, //Probabilité de mutation minimale
double pmax, //Probabilité de mutation maximale
double *minve, //Bornes minimales des varialbles
d'état
double *maxve, //Bornes maximales des varialbles d'état
LPSTR hRef, //Nom du fluide utilisé
HINSTANCE RefDLL, //Handle de la dll des fluides,
chargée depuis Fronix
HINSTANCE hDLL, //Handle de la dll de la CCF, chargée
depuis Fronix
double *param, //Paramètres de la CCF
int nve, //Nombre de variables d'état
double *mesurec, //Mesures obtenues par simulation (à
retourner)
double *varint, //Variables internes (à retourner)
double *homo, //Paramètre
d'homogénéïté (à retourner)
double *opti, //Fitness minimal (à retourner)
int nmes, //Nombre de mesures prélévées
double *mesurem, //Mesures prises sur site
int *maskmes, //Masque des mesures
double *varetat //Vaiables d'état (à retourner)
);
AG_API short __stdcall Concep(
HINSTANCE hDLL, //Handle de la dll de la CCF, chargée
depuis Fronix
LPSTR hRef, //Nom du fluide utilisé
HINSTANCE RefDLL, //Handle de la dll des fluide chargée
depuis Fronix
double *varobj, //Variables objectif issues du bilan
thermique
double *param, //Paramètres de la CCF
double *paramre, //Paramètres de reconception de la
CCF
double *varetac, //Variables d'état actuelles
double *varinac, //Variables internes actuelles
double *mesac, //Mesures actuelles
double *varetre, //Variables d'état après
reconception (à retourner)
double *varinre, //Variables internes après reconception
(à retourner)
double *mesre, //Mesures après reconception (à
retourner)
LPSTR *rapport //Rapport de la reconception (à
retourner)
);
|
|
Figure III.8 : Déclaration des
fonctions de la DLL de l'algorithme génétique
Dans toutes ces fonctions de DLL, les tableaux sont transmis
par adresse pour gagner en temps (pas recopie inutile de variables en
mémoire). La convention d'appel (protocole de gestion du transfert
d'arguments) standard a été utilisée lorsque la
compatibilité avec Visual Basic était nécessaire. Dans ces
DLL, de nombreuses fonctions non exportées ont été
définies pour faciliter la programmation. Ces fonctions ont
été rendues les plus courtes possibles afin de les définir
comme « inline ». Les fonctions « inline » sont
expansées lors de la compilation dans le code, en leurs points d'appel.
Ce principe accélère l'exécution du code, car les
mécanismes d'appel de fonctions se trouvent supprimés. L'annexe 1
montre celles qui ont été définies pour l'algorithme
génétique.
Les fonctions de redimensionnement auraient pu être
implémentées et appelées directement à partir des
DLL de CCF. Nous ne l'avons pas fait à cause des limitations de Visual
Basic dans la manipulation de pointeurs sur fonctions. En effet, quand on a le
handle de la DLL d'une CCF (après chargement en « run time dynamic
linking »), la fonction GetProcAddress() de l'API de Windows
permet d'obtenir le pointeur vers une fonction donnée de la DLL. Les
appels de cette fonction se feront par la suite par l'intermédiaire de
ce pointeur. Si un appel incohérent est réalisé (erreur
dans le nombre ou les types
d'arguments), alors le compilateur ne s'en apercevra pas, et
les dégâts à l'exécution pourront être
néfastes : tentatives d'écriture dans des zones mémoires
non allouées à l'application (MICROSOFT, 2000). Ce n'est qu'avec
Visual C++ que nous avons trouvé une technique pour prévenir
cela. Elle consiste à définir un type de pointeur sur fonction
ayant un prototype donné (celui de la fonction à appeler). Lors
de appel de GetProcAddress() une conversion explicite vers ce type de
pointeur est réalisée. De cette façon, lors des appels de
la fonction le compilateur dispose de tous les renseignements pour un
contrôle strict des arguments transmis. Le même problème ne
se pose pas lors des appels de fonctions de la DLL de l'algorithme
génétique depuis Visual Basic, car cette DLL est chargée
en « load time dynamic linking ». Le code suivant montre comment ceci
est mis en oeuvre pour l'appel de la fonction de redimensionnement depuis la
DLL de l'algorithme génétique.
//Définition de synonyme de pointeur sur la fonction de
redimensionnement typedef short (*Fonct3)(
LPSTR, //Nom du fluide utilisé
HINSTANCE, //Handle de la dll des fluide chargée depuis
Fronix
double*, //Variables objectif issues du bilan thermique
double*, //Paramètres de la CCF
double*, //Paramètres de reconception de la CCF
double*, //Variables d'état actuelles
double*, //Variables internes actuelles
double*, //Mesures actuelles
double*, //Variables d'état après reconception
(à retourner)
double*, //Variables internes après reconception
(à retourner)
double*, //Mesures après reconception (à
retourner)
LPSTR* //Rapport de la reconception (à retourner)
);
// Déclaration du pointeur sur la fonction de
redimensionnement Fonct3 ReDim; //Fonction de redimensionnement de la CCF
//Extraction du pointeur sur la fonction de redimensionnement
//hDLL est le handle de la DLL de la CCF transmis en argument
à cette fonction ReDim = (Fonct3)GetProcAddress(hDLL,"fnCCF3");
if (!ReDim)
{
return 20;
// Le pointeur n'a pas pu être obtenu, on retourne un
code d'erreur
}
short erreur; //Variable de retour de la fonction ReDim
//Appel de la fonction de redimensionnement erreur = ReDim(
hRef, //Nom du fluide utilisé
RefDLL, //Handle de la dll des fluide chargée depuis
Fronix
varobj, //Variables objectif issues du bilan thermique
param, //Paramètres de la CCF
paramre, //Paramètres de reconception de la CCF
varetac, //Variables d'état actuelles
varinac, //Variables internes actuelles
mesac, //Mesures actuelles
varetre, //Variables d'état après reconception
(à retourner)
varinre, //Variables internes après reconception
(à retourner)
mesre, //Mesures après reconception (à
retourner)
rapport //Rapport de la reconception (à retourner)
);
if (erreur > 0)
{
return 30;
//La DLL de la CCF ne trouve pas de solution
réalisable
}
//Le calcul s'est déroulé avec succès
return 0;
|
|
Figure III.9 : Exemple de code de manipulation
de pointeurs sur fonctions en C++
CHAPITRE IV. TEST DU LOGICIEL
IV.1 Présentation de l'installation
expertisée
Nous avons testé Fronix sur une chambre froide de
CONGELCAM. C'est une chambre froide de 5000 tonnes, situé à
Bonabéri (quartier de Douala -Cameroun) et vieille d'un an.
IV.1.1 Caractéristiques constructives de la
chambre
Une vue de dessus de la chambre est présentée dans
la figure suivante :
25 m
6m
COMPARTIMENT PRINCIPAL
SAS
40 m
S
N
Figure IV.1 : Vue de dessus de la chambre
Les autres caractéristiques constructives sont :
· Hauteur : 8 m ;
· Hauteur d'une porte : 2,8 m ;
· Largeur d'une porte : 2,4 m ;
· Isolation des parois verticales et du plafond : panneaux
sandwich de 180 mm de mousse rigide de polyuréthane ;
· Isolation du sol : dalle en béton de 150 mm,
bitume d'étanchéité (communément appelé
« flinkote ») 15 mm, polystyrène expansé de 150 mm et
dalle en béton de 150 mm ;
· Evaporateurs : un dans le SAS et quatre dans le
compartiment principal ;
· Groupes frigorifiques : un groupe par
évaporateur ;
IV.1.2 Données actuelles d'exploitation
Ces données sont résumées dans le tableau
ci-après :
Tableau IV.1 : Données
d'exploitation de la chambre froide expertisée
RUBRIQUE
|
SAS
|
COMPARTIMENT
PRINCIPAL
|
Température désirée
|
-15 °C
|
-20 °C
|
Humidité relative désirée
|
85%
|
90%
|
Temps de marche des installations désiré
|
18 heures/jour
|
18 heures/jour
|
Puissance totale d'éclairage
|
720 W
|
2880 W
|
Durée journalière d'éclairage
|
12
|
12
|
Puissance du chariot élévateur
électrique
|
4500 W
|
4500 W
|
Durée journalière de fonctionnement du chariot
|
4 heures
|
7 heures
|
Puissance totale des ventilateurs d'évaporateurs
|
3000 W
|
12000 W
|
Durée de marche des ventilateurs
d'évaporateurs
|
21,25 heures/jour
|
21,25 heures/jour
|
Puissance totale de dégivrage
|
22320 W
|
89280 W
|
Durée journalière de dégivrage
|
3,75 heures
|
3,75 heures
|
Nombre journalier de travailleurs
|
3
|
10
|
Durée journalière de travail
|
12 heures
|
12 heures
|
Masse de poisson introduite par jour
|
23400 kg
|
93600 kg
|
Température d'introduction du poisson
|
-5 °C
|
-5 °C
|
Flux de produit sur porte extérieure
|
58,5 tonnes/jour
|
-
|
Temps d'ouverture par tonne sur porte extérieure
|
1,33 minutes/jour
|
-
|
Flux de produit sur porte intérieure
|
46,8 tonnes/jour
|
46,8 tonnes/jour
|
Temps d'ouverture par tonne sur porte intérieure
|
10 minutes/jour
|
10 minutes/jour
|
|
IV.1.3 Présentation des groupes frigorifiques
Les groupes frigorifiques sont identiques, de marque HK
REFRIGERATION. Chaque groupe comprend deux grandes parties : un groupe
condenseur (modèle JJ27813401) et un évaporateur (modèle
BAC 304 N6). Le fluide frigorigène utilisé est le R404A. Le
circuit fluidique de chacun des groupes est celui présenté sur la
figure I.1.
IV.1.4 Le mode de défaillance
constaté
Un groupe de cette installation présente une
défaillance intermittente non encore explicitée. Le mode de
défaillance correspondant est le suivant : le pressostat
différentiel d'huile arrête le groupe, sans qu'aucune anomalie ne
soit constatée sur les valeurs des pressions de fluide
frigorigène ou sur le système de lubrification. Après
plusieurs réarmements le groupe reprend une marche continue,
jusqu'à la prochaine réapparition de la défaillance
quelques mois plus tard.
IV.2 Expertise par Fronix
Ici, nous présentons l'expertise effectuée
à l'aide de Fronix sur ce groupe défaillant. IV.2.1
Bilan thermique
Les données constructives et d'exploitation
précédentes ont été rentrées dans le
logiciel. Le profil climatique utilisé est celui des conditions moyennes
du mois de Février 2002 dans la ville de Douala, dont les
caractéristiques sont :
Tableau IV.2 : Conditions extérieures
utilisées
Température sèche
|
28 °C
|
Humidité relative
|
78%
|
|
Source : Direction de la métrologie du ministère
des transports (Douala-Cameroun)
La température du sol est plus délicate
à obtenir. Mais pour une chambre dont le plancher a été
bien isolé (c'est le cas ici), des erreurs sur ce paramètre n'ont
pas une grande incidence sur les résultats. Nous l'avons fixé
à 15°C, valeur couramment utilisée dans (BREIDERT, 1998).
Les résultats de calcul du bilan thermique
édités par Fronix sont présentés dans l'annexe 2.
Les charges frigorifiques à fournir par les évaporateurs sont
:
· SAS : 38040 W ;
· Compartiment principal : 115248 W.
IV.2.2 Diagnostic interne
Les mesures et paramètres du groupe diagnostiqué
sont donnés dans le tableau suivant :
Tableau IV.3 : Données de diagnostic du
groupe expertisé
|
Parametres
|
Fluide frigorigène
|
R404A
|
|
Diamètre de la tuyauterie d'aspiration
|
0,066 m
|
|
Diamètre de la tuyauterie de refoulement
|
0,022 m
|
|
Diamètre de la tuyauterie liquide
|
0,022 m
|
|
Type de refroidissement du compresseur
|
Veine d'air du condenseur
|
|
Puissance maximale de compression
|
30000 W
|
|
Mesures realisees
|
Température entrée air évaporateur
|
-17 °C
|
|
Température sortie air évaporateur
|
-18,5 °C
|
|
Température entrée air condenseur
|
26 °C
|
|
Température sortie air condenseur
|
30 °C
|
|
Pression aspiration compresseur
|
2,5 bars
|
|
Pression refoulement compresseur
|
18 bars
|
|
Température aspiration compresseur
|
2 °C
|
|
Température refoulement compresseur
|
70 °C
|
|
Débit volumique air évaporateur
|
27000 m3/h
|
|
Débit volumique air condenseur
|
36000 m3/h
|
|
Humidité relative du compartiment
|
85%
|
Les calculs ont été faits avec la seule CCF
(Configuration de Circuit Fluidique) actuellement disponible. Un
problème majeur du diagnostic tel que nous l'avons conçu est de
pouvoir trouver les paramètres de l'algorithme génétique
conduisant à de bons résultats en un temps court. Pour cela, nous
avons réalisé des essais avec des paramètres
différents, en utilisant les bornes par défaut des variables
d'état. Les résultats sont présentés dans le
tableau suivant :
Tableau IV.4 : Résultats des essais de
diagnostic réalisés
|
N° de l'essai
|
|
1
|
2
|
3
|
4
|
5
|
6
|
|
Entrée
|
Probabilité de sélection
|
0,9
|
0,9
|
0,9
|
0,9
|
0,9
|
0,95
|
|
Probabilité de mutation min.
|
0,001
|
0,001
|
0,001
|
0,001
|
0,001
|
0
|
|
Probabilité de mutation max.
|
0,005
|
0,005
|
0,005
|
0,005
|
0,005
|
0,005
|
|
Taille de la population
|
20
|
40
|
20
|
40
|
20
|
20
|
|
Nombre de générations
|
100
|
100
|
200
|
200
|
400
|
400
|
|
Sortie
|
Paramètre d'homogénéité
|
10
|
7,5
|
55
|
27,5
|
35
|
5
|
|
Fitness minimal
|
1,76
|
1,41
|
1,05
|
1,13
|
0,92
|
2,92
|
|
Temps de calcul (minutes)
|
10,14
|
20,10
|
21,15
|
36,26
|
31,48
|
46,43
|
Des expériences précédentes ont
montrées que des probabilités de mutation inférieures
à 0,005 conduisaient à de bons résultats. Aussi, comme le
montre l'essai N°6, des probabilités de mutation trop faibles
empêchent une bonne exploration et les résultats sont mauvais. Le
tableau montre que de bons résultats peuvent être obtenus avec une
population de 20 individus. Ce nombre étant fixé, le fitness
diminue quand le nombre de générations augmente, mais le temps de
calcul croît, et il faut pouvoir trouver un bon compromis. Ici, c'est
l'essai N°5 qui a donné satisfaction. Le rapport de diagnostic
correspondant est présenté dans l'annexe 3.
IV.2.3 Redimensionnement
Les paramètres de redimensionnement utilisés sont
indiqués dans le tableau suivant. Tableau IV.5 :
Données de départ du redimensionnement
|
Efficacité évaporateur
|
0,7
|
|
Efficacité condenseur
|
0,7
|
|
Surchauffe évaporateur
|
5 °C
|
|
Sous refroidissement total
|
10 °C
|
|
Rendement effectif compresseur
|
0,7
|
|
Rendement isentropique compresseur non refroidit
|
0,7
|
|
Rendement isentropique compresseur refroidit par ventilateur de
tête de culasse
|
0,8
|
|
Rendement isentropique compresseur refroidit par veine d'air du
condenseur
|
0,8
|
|
Différence température condensation - air
extérieur
|
7°C
|
|
Débit air évaporateur (m3/h)
|
30000
|
|
Débit air condenseur (m3/h)
|
40000
|
Après redimensionnement la DLL de la CCF a sortit le
rapport suivant : « La vitesse à l'entrée de la tuyauterie
d'aspiration est trop faible (v < 6 m/s), il y a risque de non retour
d'huile. ».
IV.2.4 Prise des décisions
Il y a actuellement dix règles disponibles pour la CCF
implémentée. Elles ont toutes un seuil de décision «
Vrai » de 0,6 ; un seuil de décision « Faux » de 0,4 et
une tolérance de 10%. Après évaluation, toutes ces
règles ont eu la valeur de vérité « Faux ».
IV.3 Discussion
Après expertise, il apparaît que la
défaillance constatée est due non pas à de mauvaises
conditions d'utilisation ou un vieillissement d'organe, mais à une
mauvaise conception du tracé des tuyauteries, conduisant à des
vitesses insuffisantes pour un bon retour d'huile (tel qu'indiqué dans
le rapport de redimensionnement). Signalons à cet effet que même
si il y a un séparateur d'huile dans le circuit la séparation
n'est pas toujours parfaite, d'où le caractère intermittent de la
défaillance.
Les règles ont toutes été
évaluées « Faux ». Ceci montre que les
paramètres de fonctionnement du groupe ne sont pas trop loin de leurs
valeurs nominales. Cela se comprend dans la mesure où la chambre froide
n'a que un an, et offre actuellement entière satisfaction dans la
qualité des paramètres de conservation.
Ces résultats ont été obtenus avec une CCF
plutôt moyenne en terme de profondeur dans les modèles de calcul,
et sont pourtant acceptables.
Enfin, il faut quand même noter les temps de calculs
assez élevés requis pour le diagnostic. Cela est dû
à l'algorithme génétique, et c'est le prix à payer
pour profiter pleinement de sa puissance.
Conclusion
Tout au long de ce travail, nous avons développé
un logiciel destiné à l'expertise d'installations frigorifiques
de chambres froides, et adapté à plusieurs configurations. Cette
expertise ce fait en trois grandes étapes : un redimensionnement, un
diagnostic et la prise de décision. La particularité ici est que
lors du diagnostic, en plus des mesures prélevées sur les
installations, le logiciel utilisera un algorithme génétique afin
de retrouver les meilleurs paramètres internes (non accessibles par la
mesure) correspondants. La prise de décision finale s'en trouve ainsi
améliorée. Cette prise de décision a été
implémentée par un système à base de règles
floues, afin de rester le plus proche possible de l'expression humaine
(imprécise et indécise) dans l'énoncé et le
traitement des règles. La modularité du logiciel a
été accrue, offrant ainsi une plus grande flexibilité.
Pour cela, la notion de Configuration de Circuit Fluidique (CCF) a
été introduite, permettant la manipulation de types donnés
d'installations frigorifiques. Une CCF est composée d'une base de
données et d'une bibliothèque de liens dynamiques de fonctions
(DLL : Dynamic Link Library). De cette façon, l'on pourra plus tard
ajouter des CCF au logiciel sans recompilation du code.
Dans cette première version du logiciel, nous n'avons
implémenté qu'une seule CCF. L'application a été
testée sur une chambre froide de CONGELCAM et les résultats sont
encourageants. L'inconvénient majeur ici est le temps de calcul
relativement long nécessaire pour le diagnostic. C'est le prix à
payer pour un diagnostic acceptable.
Actuellement, nous travaillons sur le développement
d'une version commercialisable du logiciel. Ce travail est centré sur la
conception de CCF qui seront beaucoup plus complètes que celle
actuellement disponible.
Bibliographie
THERMIQUE, ENERGETIQUE ET MAINTENANCE
INDUSTRIELLE
AFNOR ; Maintenance Industrielle, Tome 1 : Méthodes et
Outils ; AFNOR ; 1996. AUDIFFRET J. P. ; Les panneaux sandwiches isolants pour
chambres froides ; Revue Générale du Froid ; Association
Française du Froid ; 1984.
BILLIARD F. ; Les capteurs nécessaires à
l'informatisation du froid ; Revue Générale du Froid ;
Association Française du Froid ; 1986.
BREIDERT H.-J. ; Calcul des chambres froides ; PYC livres ;
1998.
CHEVALIER E. ; La télésurveillance des
installations frigorifiques dans la grande
distribution ; Revue Générale du Froid ;
Association Française du Froid ; 1986. COUTURE L., CHAHINE Ch. et ZITOUN
R. ; Thermodynamique classique et propriétés de
la matière ; Dunod ; 1980.
ESTEBAN S. ; Phénomènes de transport et leur
résolution numérique ; Polytechnica ; 1998. GAC A., GAUTHERIN W.
; Le Froid dans les magasins de vente des Denrées périssables ;
PYC Editions ; 1987.
KUITCHE A. ; Cours de production froid et génie climatique
; ENSAI-MIP ; 2002. KUITCHE A. ; Cours de technologie et maintenance en froid
et climatisation ; ENSAI-MIP ; 2003.
LEMASSON G. ; Les machines transformatrices d'énergie.
Tome 2 ; Delagrave ; 1967. MARVILLET C. ; Echange thermique ; Publication de
l'Institut Français du Froid Industriel et du Génie Climatique ;
1992.
MONCHY F. ; Maintenance : méthodes et organisations ;
Dunod ; 2000.
MÜLLER C.F. ; Manuel technique du froid ; PYC édition
; 1983.
NKAMTCHOUM I. ; Dépannage en froid et climatisation ;
Editions NK ; 1988. OUZIAUX ; Mécanique des fluides appliquées ;
Dunod ; 1985.
RAPIN P. ; Formulaire du froid ; Dunod ; 1985.
TRANE ; Manuel de climatisation ; The TRANE Company ; 1983.
SACADURA J-F. ; Initiation aux transferts thermiques ; Lavoisier
; 1980.
ZWINGELSTEIN G. ; Diagnostic des défaillances :
théorie et pratique pour les systèmes industriels ; Hermès
; 1995.
INFORMATIQUE ET MATHEMATIQUES APPLIQUEES
CARNAHAN B. ; Applied numerical methods ; John Wisley ; 1969.
COHOON & DAVIDSON ; e-Text C++ Program Design ; McGraw-Hill
Higher Education ; 1999.
DELANNOY C. ; Programmer en langage C ; Eyrolles ; 2000.
DIDAY E. et Al ; Optimisation en classification automatique, Tome
1 ; Inria ; 1979. DION J. G., R. GAUDET R. ; Méthodes d'analyse
numérique ; Modulo ; 1996. FAURE R. ; Précis de recherche
opérationnelle ; Dunod ; 1979.
FRALA B. ; Indispensable pour C++ ; Marabout Informatique ;
1999.
GARDARIN G. ; Bases de données : les systèmes et
leurs langages ; Eyrolles ; 1998.
GARDARIN G., GARDARIN O. ; Le Client - Serveur ; Eyrolles ;
2000.
GOUPILLE P. A. ; Technologie des ordinateurs et des
réseaux ; Dunod ; 2000. HAYDEN M. ; Les Réseaux ; CampusPress ;
2001.
HERTZ J., KROGH A., PALMER R. G. ; Introduction to the theory of
neural computation ; Addison - Wesley ; 1991.
KANE C., SCHOENAUER M. ; Optimisation topologique des formes par
algorithmes génétiques ; Revue française de
mécanique n°4 ; 199 7.
KIRSTEIN M. ; Visual Basic 6 ; Micro Application ; 1999.
KRAKOWIAK S. ; Principes des systèmes d'exploitation des
ordinateurs ; Dunod informatique ; 1987.
LIPPMAN S. B. ; L'essentiel du C++ ; Addison - Wesley ; 1992.
MATHERON J. P. ; Comprendre Merise ; Eyrolles ; 2001.
MATHERON J. P. ; Exercices et cas pour comprendre Merise ;
Eyrolles ; 2001. MICROSOFT ; Online Microsoft Developper Network for Visual
Studio 6.0 ; Microsoft ; 2000. OVERLAND B. ; Visual Basic 6, Guide de reference
; O.E.M. ; 1999.
STROHMEIER A., BUCHS D. ; Génie logiciel : principes,
méthodes et techniques ; Presses Polytechniques et Universitaires
Romandes ; 1996.
TONG-TONG J.R. ; La logique floue ; Hermès ; 1995.
VAISER D. ; C++ facile ; Marabout Informatique ; 1999.
LIENS INTERNET
http://www.developpez.com (site
d'entraide des développeurs francophones) ; consulté en septembre
2003.
http://www.vbasic.org (site
dédié à Visual Basic) ; consulté en septembre 2003.
http://dominique.revuz.free.fr
(contient une présentation du mécanisme des DLL sous Windows) ;
consulté en août 2003.
http://www.coyotegulch.com/algorithm/index.html
(exposés sur plusieurs techniques d'intelligence artificielle, avec des
codes sources en C++ disponibles) ; consulté en juillet 2003.
http://www.eudil.fr/~vmagnin/coursag/index.html
(exposé sur les algorithmes génétiques) ; consulté
en juillet 2003.
http://rennard.org/alife/french/entree.html
(présentation des techniques de mathématiques
appliquées inspirées de la génétique
et la biologie cellulaire) ; consulté en juillet 2003.
http://www-eco.enst-bretagne.fr/~phan/complexe/AlgoGen00.html
(cours introductif aux
algorithmes génétiques) ; consulté en juin
2003.
http://www.unil.ch (cours sur plusieurs
techniques d'intelligence artificielle) ; consulté en juin 2003.
Annexes
Annexe 1 : Implémentation des
opérateurs génétiques 55
Annexe 2 : Résultats du bilan thermique
de la chambre expertisée 57
Annexe 3 : Résultats de diagnostic d'un
groupe frigorifique du compartiment principal 58
Annexe 4 : Fonctions exportées par la DLL
des fluides frigorigènes 60
Annexe 5 : Quelques règles fournies avec
la CCF implémentée 61
Annexe 1 : Implémentation des opérateurs
génétiques
Ce code a été testé sur le compilateur
Visual C++ de Microsoft.
// (c) août 2003 OUAMBO TOBOU Raoul. #include
<stdlib.h>
//Longueur en bits du type d'entier utilisé dans le codage
const size_t lng = sizeof(unsigned short)*8;
//Entier max du codage sur 16 bits const unsigned short gmax =
0xFFFF;
//Génère un nombre aléatoire compris entre 0
et 1
inline double Aleatoire(void)
{
return (double) rand()/RAND_MAX;
}
//Fonction de décodage
inline double Decode(unsigned short g, double Xmin, double DX)
{
return Xmin + DX*g;
}
// Sélection par tournoi avec une probabilité de
sélection p
// entre deux individus de fitness respectifs Fit1 et Fit2
inline short SelTournoi(double Fit1, double Fit2, double p)
{
short best;
best = (Fit1 < Fit2) ? 1 : 2;
return (Aleatoire() <= p) ? best : 3 - best;
}
//Croisement en 2 points de *parent1 et *parent2 et leurs
probabilités de mutation inline void Croise2(unsigned short *parent1,
unsigned short *parent2,
unsigned short *fils1, unsigned short *fils2,
unsigned short *proba01, unsigned short *proba02,
unsigned short *proba11, unsigned short *proba12)
{
unsigned short mask1, mask2;
size_t pos1, pos2;
//Postion de la 2ème cission du croisement pos2 = 2 +
(size_t) (Aleatoire() * (lng - 2)); if(pos2 == lng) pos2 = lng - 1;
//Postion de la 1ère cission du croisement
pos1 = 1 + (size_t) (Aleatoire() * (pos2 - 1)); if(pos1 == pos2)
pos1 = pos2 - 1;
// Construction des masques de croisement
mask2 = 0xFFFF;
mask2 <<= (lng - pos2 + pos1);
mask2 >>= (lng - pos2);
mask1 = ~mask2;
// Croisements des individus
*fils1 = (mask1 & *parent1) | (mask2 &
*parent2);
*fils2 = (mask2 & *parent1) | (mask1 & *parent2);
// Croisements des probabilités de mutation *proba11 =
(mask1 & *proba01) | (mask2 & *proba02); *proba12 = (mask2 &
*proba01) | (mask1 & *proba02);
}
//Mutation d'un individu et de sa probabilité de
mutation,
//avec une probabilité uniforme p
inline void Mute(unsigned short *ind1, unsigned short *ind2,
unsigned short *pro1, unsigned short *pro2, double p)
{
unsigned short masque, buf;
//Construction du masque de mutation masque = 0;
for(size_t i=0; i < lng; i++)
{
buf = (Aleatoire() <= p) ? 1 : 0; buf <<= i;
masque |= buf;
};
//Mutation bit par bit par l'opération XOR
*ind2 = *ind1 ^ masque; *pro2 = *pro1 ^ masque;
}
//Extrait l'individu N°num décodé
(varialbes d'état) //du tableau codé de la population
inline void Extrait(
unsigned short *popu, //Population
double *var, //Individu (un nvar-uplet de variables)
double *min, //Borne min des varialbles
double *pas, //Pas de discrétisation des intervalles de
variables
int num, //Numéro de l'individu dans la population
int nvar //Nombre de variables dans un individu
)
{
int j, prod;
prod = nvar * num;
for(j=0; j < nvar; j++)
{
};
}
var[j] = Decode(popu[prod + j], min[j], pas[j]);
Annexe 2 : Résultats du bilan
thermique de la chambre
expertisée
RAPPORT DU CALCUL DE BILAN THERMIQUE
Date d'édition du rapport : 29/12/2003 Nom du projeteur :
Ouambo
Date de début du projet : 18/10/2003 Client
concerné : Congelcam
Chambre froide : Bonabéri - Ancienne
Pays d'installation de la chambre : Cameroun Ville d'installation
de la chambre : Douala Profil climatique utilisé : Février
Charges du Compartiment 1
Volume du compartiment : 1920 m3
Température désirée dans le compartiment :
-15 °C Humidité relative désirée dans le
compartiment : 85 % Charges à travers les parois verticales : 2801,067 W
Charges à travers les ouvertures : 8853,183 W
Charges à travers le plafond : 1962,562 W
Charges à travers le plancher : 2420,563 W
Charges par renouvellement d'air : 0 W
Charges dues aux denrées entrantes : 4698,958 W Charges
dues à la respiration des denrées : 0 W Charges dues à
l'éclairage : 360 W
Charges dues aux appareillages : 750 W
Charges dues au personnel : 540 W
Charges dues aux moteurs d'évaporateurs : 2656,25 W
Charges dues au dégivrage : 3487,5 W
Puissance frigorifique intermédiaire : 28530,082 W Temps
de fonctionnement des installations : 18 heures
Puissance frigorifique à fournir par les
évaporateurs : 38040,11 W
Charges du Compartiment 2
Volume du compartiment : 8000 m3
Température désirée dans le compartiment :
-20 °C Humidité relative désirée dans le
compartiment : 90 % Charges à travers les parois verticales : 6134,105 W
Charges à travers les ouvertures : 2065,521 W
Charges à travers le plafond : 8998,358 W
Charges à travers le plancher : 11766,624 W
Charges par renouvellement d'air : 0 W
Charges dues aux denrées entrantes : 28193,75 W Charges
dues à la respiration des denrées : 0 W Charges dues à
l'éclairage : 1440 W
Charges dues aux appareillages : 1312,5 W
Charges dues au personnel : 1950 W
Charges dues aux moteurs d'évaporateurs : 10625 W Charges
dues au dégivrage : 13950 W
Puissance frigorifique intermédiaire : 86435,858 W Temps
de fonctionnement des installations : 18 heures
Puissance frigorifique à fournir par les
évaporateurs : 115247,81 W
Annexe 3 : Résultats de diagnostic
d'un groupe frigorifique du
compartiment principal
RESULTATS DE LA SIMULATION INTERNE DU GROUPE 1
Date d'édition du rapport : 28/12/2003 Nom du projeteur :
Ouambo
Date de début du projet : 18/10/2003 Client
concerné : Congelcam
Chambre froide : Bonabéri - Ancienne
Pays d'installation de la chambre : Cameroun Ville d'installation
de la chambre : Douala Profil climatique utilisé : Février
PARAMETRES D'ENTREE DE L'ALGORITHME GENETIQUE Probabilité
de sélection : 0,9
Probabilité minimale de mutation : 0,001
Probabilité maximale de mutation : 0,005 Taille de la population : 20
Nombre de génaration simulées : 400
PARAMETRES DE SORTIE DE L'ALGORITHME GENETIQUE Paramètre
d'homogénisation de la population finale : 35 Fitness minimal :
0,92486
Durée des calculs : 31,483 minutes
PARAMETRES DU GROUPE
Fluide frigorigène : R404A
Numéro Evaporateur = 2
Diamètre tuyauterie aspiration (m) = 0,066675
Diamètre tuyauterie de vapeurs surchauffées (m) =
0,022225
Diamètre tuyauterie de liquide (m) =
0,022225
Puissance maximale de compression (W) = 30000
MESURES REALISEES
Température entrée air évaporateur
(°C) (obligatoire) = -17 Température sortie air
évaporateur (°C) (obligatoire) = -18,5
Température entrée air condenseur (°C)
(obligatoire) = 26 Température sortie air condenseur
(°C) (obligatoire) = 30 Pression aspiration compresseur (bars)
(obligatoire) = 2,5 Pression refoulement compresseur (bars) (obligatoire) = 18
Température aspiration compresseur (°C) (obligatoire) =
2 Débit volumique air évaporateur (m3/s) (obligatoire) = 7,5
Débit volumique air condenseur (m3/s) (obligatoire) = 10 Humidité
relative compartiment (%) (obligatoire) = 85 Température refoulement
compresseur (°C) = 70
MESURES OBTENUES PAR CALCUL
Température entrée air évaporateur
(°C) (obligatoire) = -17 Température sortie air
évaporateur (°C) (obligatoire) = -18,49951
Température entrée air condenseur (°C)
(obligatoire) = 26 Température sortie air condenseur
(°C) (obligatoire) = 26,90332 Pression aspiration compresseur
(bars) (obligatoire) = 2,68275 Pression refoulement compresseur (bars)
(obligatoire) = 17,97653 Température aspiration compresseur
(°C) (obligatoire) = 1,58683 Débit volumique air
évaporateur (m3/s) (obligatoire) = 7,5
Débit volumique air condenseur (m3/s) (obligatoire) = 10
Humidité relative compartiment (%) (obligatoire) = 85 Pression
entrée évaporateur (bars) = 3,07802
Pression sortie évaporateur (bars) = 3,01253
Pression entrée condenseur (bars) = 15,92337 Pression
sortie condenseur (bars) = 16,06997 Température entrée
évaporateur (°C) = -20,13993 Température sortie
évaporateur (°C) = -20,13993 Température
entrée condenseur (°C) = 62,11033 Température
sortie condenseur (°C) = 21,82979 Température
refoulement compresseur (°C) = 70,08289
VARIABLES D'ETAT OBTENUES PAR CALCUL Rendement isentropique
compresseur = 0,98854 Efficacité évaporateur = 0,46396
Surchauffe enthalpique évaporateur = -0,011 Surchauffe
aspiration (°C) = 21,72676 Efficacité condenseur =
0,97547
Sous-refroidissement enthalpique condenseur = 0,15341
Débit massique frigorigène (kg/s) = 0,24307 Température
évaporation (°C) = -20,13993
Température condensation (°C) =
34,57298
Pertes de charges ligne d'aspiration (bar) = 0,32978 Pertes de
charges ligne liquide (bar) = 1,79072
Pertes de charges refoulement - entrée condenseur (bar) =
2,05316 Désurchauffe refoulement - entrée condenseur
(°C) = 7,97255 Sous-refroidissement ligne liquide
(°C) = 29,0358
VARIABLES INTERNES OBTENUS PAR CALCUL
Vitesse entrée tuyauterie aspiration (m/s) = 4,46199
Vitesse sortie tuyauterie aspiration (m/s) = 5,70555
Vitesse entrée tuyauterie vapeurs surchauffées
(m/s) = 8,10915 Vitesse sortie tuyauterie vapeurs surchauffées (m/s) =
9,03205 Vitesse entrée tuyauterie liquide (m/s) = 0,59127
Vitesse sortie tuyauterie liquide (m/s) = 0,53188
Production frigorifique (W) = 39451,10032
Chute de pression entrée évaporateur (bar) =
11,05463 Surchauffe évaporateur (°C) = 0
Sous-refroidissement condenseur (°C) =
12,74319
Volume spécifique entrée compresseur (m3/kg) =
0,08196 Volume spécifique refoulement compresseur (m3/kg) = 0,01294
Volume spécifique sortie condenseur (m3/kg) = 0,00094
Annexe 4 : Fonctions exportées par la
DLL des fluides
frigorigènes
Nous présentons ci-après un extrait de l'aide
accompagnant les versions 2.0 des bibliothèques de fonctions fournies
par la société SOLVAY FLUOR UND DERIVATE.
|
The functions of the following properties are implemented:
1. bubble and dew pressure: p' = f(T) und p» = f(T)
2. bubble and dew temperature: T' = f(p) und T» = f(p)
3. specific volume of the liquid phase: v' = f(T)
4. pressure, vapour phase: p = f(T, v)
5. specific volume vapour phase: v = f(p, T)
6. temperature vapour phase: T = f(p, v), T = f(p, h) und T =
f(p, s)
7. specific enthalpy liquid phase: h' = f(T)
8. specific enthalpy vapour phase: h = f(T, v) und h = f(T,
p)
9. specific entropy liquid phase: s' = f(T)
10. specific entropy vapour phase: s = f(T, v) und s = f(T,
p)
11. specific heat capacity liquid phase: c' = f(T)
12. specific heat capacity vapour phase (p=const.): cp = f(T, v)
und cp = f(T, p)
13. specific heat capacity vapour phase (v=const.): cv = f(T, v)
und cv = f(T, p)
14. adiabatic exponent, vapour phase: K = f(T, v) und K = f(T,
p)
15. velocity of sound, vapour phase: w = f(T, v) und w = f(T,
p)
16. thermal conductivity, liquid phase: X ` = f(T)
17. thermal conductivity, vapour phase: X = f(T, p)
18. dynamic viscosity, liquid phase: i ` = f(T)
19. dynamic viscosity, vapour phase: i = f(T, p)
20. surface tension: a = f(T)
21. characteristic data (molar mass, critical temperature,
critical pressure,...)
|
Annexe 5 : Quelques règles fournies avec la CCF
implémentée
REGLES D'EXPERTISE DE LA CONFIGURATION DE CIRCUIT FLUIDIQUE
CCF0001
Règle N° : 1
SI Température aspiration compresseur (°C)
(obligatoire) Très Elevé ET Surchauffe évaporateur
(°C) Très Elevé
ALORS Détendeur thermostatique mal réglé
ACTIONS A PRENDRE :
Examiner et régler le détendeur thermostatique
OBSERVATIONS DE CONFIRMATION :
Le toucher de la tuyauterie d'aspiration permet de constater
qu'il est plus chaud que d'habitude
PARAMETRES DE DECISION :
Seuil de décision 'Vrai' : 0,6 Seuil de décision
'Faux' : 0,4 Tolérance dans l'évaluation floue des
prémisses : 10
Règle N° : 2
SI Température aspiration compresseur (°C)
(obligatoire) Très Faible ET Volume spécifique entrée
compresseur (m3/kg) Très Faible
ALORS Trop de liquide dans la tuyauterie d'aspiration
ACTIONS A PRENDRE :
Régler le détendeur thermostatique
OBSERVATIONS DE CONFIRMATION : La tuyauterie d'aspiration
givre
PARAMETRES DE DECISION :
Seuil de décision 'Vrai' : 0,6 Seuil de décision
'Faux' : 0,4 Tolérance dans l'évaluation floue des
prémisses : 10
Règle N° : 3
SI Pression aspiration compresseur (bars) (obligatoire)
Très Faible ET Efficacité évaporateur Plus ou moins
Faible
ALORS Trop d'huile dans l'évaporateur
ACTIONS A PRENDRE :
Vider l'huile des évaporateurs
OBSERVATIONS DE CONFIRMATION :
La température dans la chambre est trop
élevée
PARAMETRES DE DECISION :
Seuil de décision 'Vrai' : 0,6 Seuil de décision
'Faux' : 0,4 Tolérance dans l'évaluation floue des
prémisses : 10
| 
