Développement d'un logiciel d'expertise technique d'installation frigorifiques de chambre froides

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 E_m , 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

E_m - 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

? ? ?

M_C correspondant, soit ( )

M_C = F X

?

. Le fitness du vecteur X sera alors une mesure de la

différence entre les vecteurs

?

? ?

M S - M C

?

M_S et

.

M_C , nous avons pris pour cela la norme

V_i .

?

V

?

Cette norme étant définit pour un vecteur V de composantes V_i 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 (m³/s)

n Débit volumique air condenseur (m³/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 (m³/kg)

· Volume spécifique refoulement compresseur (m³/kg)

· Volume spécifique sortie condenseur (m³/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 S₁ de décision « Vrai » : si ì = S₁ , alors on décide que les prémisses sont

vraies, et que la conclusion de la règle est vérifiée ;

· Le seuil S₂ de décision « Faux » : si ì = S₂ , 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 = ì = S₁, 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 :

NType

NSType

Donnée

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.