Cours de Systèmes Experts Et Temps Réel 2017-2018

Cours de Système Expert et Temps réel, L2 Génie Informatique
Première partie : Système expert

Chapitre 1 : Technologie des systèmes experts
1.1 Introduction
Les experts humains sont capables d‟effectuer un niveau élevé de raisonnement à cause
de leur grande expérience et connaissance sur leurs domaines d‟expertise. Un système expert
utilise la connaissance correspondante à un domaine spécifique afin de fournir une
performance comparable à l‟expert humain. En général, les concepteurs de systèmes experts
effectuent l‟acquisition de connaissance grâce à un ou plusieurs interviews avec l‟expert ou
les experts du domaine. Les humains qui enrichissent le système avec leurs connaissances ne
fournissent pas seulement leur connaissance théorique ou académique mais aussi des
heuristiques qu‟ils ont acquises grâce à l‟utilisation de leurs connaissances.
Contrairement à la modélisation cognitive, les systèmes experts n‟ont pas comme
finalité de s‟inspirer des théories du fonctionnement du cerveau humain mais ce sont des
programmes qui utilisent des stratégies heuristiques pour la résolution des problèmes
spécifiques.
Le raisonnement effectué par un système expert doit être objet à l‟inspection, et ceci en
fournissant d‟information sur l‟état de la résolution du problème et des explications sur les
choix et les décisions du système.
D‟un autre côté, la solution fournie par le système doit être évaluée par un expert
humain et ceci dans le but de modifier l‟information contenue dans la base de connaissances.
Le but de ce chapitre est de définir la technologie systèmes experts en présentant
l‟architecture d‟un système expert type ainsi que le processus de son élaboration.
1.2. Structure et fonctionnement d’un système expert

L‟architecture d‟un système expert typique est constituée de plusieurs modules qui
s‟interagissent (voir 1.1) :
- L‟interface utilisateur sert à simplifier la communication, elle peut utiliser la forme
question-réponse, le menu, le langage naturel etc.
- La base de connaissances contient les connaissances concernant la résolution du
problème. La base des connaissances contient tout ce que l‟on sait sur le domaine à
traiter: faits permanents, savoir-faire, expertise. Si l‟on a eu recours aux «
représentations logiques » pour exprimer les connaissances, elle rassemblera
l‟ensemble des « propositions » vraies et fausses connues. Si l‟on a préféré les «
réseaux sémantiques », elle sera constituée des réseaux indiquant le sens, la nature et
le contenu des liaisons entre objets, concepts... du domaine expertisé. S‟il s‟agit d‟un «
système à règles », elle emmagasinera les « règles de production » indiquant les
conditions qui permettent de tirer telle conclusion, etc.
- Le moteur d‟inférence ou interpréteur manipule la base de connaissances, à partir de la
question posée et des faits vérifiés, selon des modalités liées aux formes de
1
Batubenga Mwamba Nz. J.D.
représentation des connaissances adoptées et selon une ou plusieurs stratégies, qui va

le caractériser et ceci pour en dériver une nouvelle information. Si l‟on a affaire à un
système à règles, le moteur d‟inférence convoque l‟ensemble des règles dont les
prémisses contiennent au moins un des faits enregistrés par l‟utilisateur. Il peut alors
faire défiler les règles les unes après les autres dans l‟ordre de leur empilement et à
chaque fois demander les compléments d‟informations nécessaires jusqu‟à trouver la
bonne règle, celle qui donne une conclusion sûre et précise à partir des conditions
nécessaires et suffisantes qui ont été observées.
- La base de faits contient les données spécifiques liées à l‟application traitée. Elle peut
contenir aussi les solutions intermédiaires ou les conclusions partielles trouvées lors de
l‟inférence. La base de faits rassemble la question que pose l‟utilisateur, les
informations dont il dispose au départ, les données des vérifications que lui demande
d‟effectuer le système, les réponses partielles de ce dernier, jusqu‟à la réponse finale.
Il peut être nécessaire d‟introduire les faits dans la forme de représentation des
connaissances adoptée pour le S.E. utilisé, comme dans le cas des réseaux
sémantiques.
- Le module d‟explication permet au système expert d‟expliquer son raisonnement. Ce
module est adjoint au S.E. lorsque l‟on veut lui faire jouer un rôle d‟apprentissage. En
fait, il s‟agit le plus souvent de l‟explicitation du cheminement du S.E., c‟est-à-dire du
passage d‟une règle à une autre dans le cas d‟un système à règles et non de
l‟explication de chaque règle; explication difficile à donner parce qu‟il s‟agit souvent
de règles nées de l‟expérience, et non d‟une démonstration, ou bien parce qu‟elle serait
très longue à énoncer, surtout si l‟utilisateur est totalement ignorant du domaine.
- L‟éditeur permet l‟édition des connaissances dans la base. Ce module jouant le rôle
d‟acquisition, de modification et de mise à jour des connaissances permet un codage et
une intégration plus ou moins aisés des règles, réseaux, propositions, algorithmes...
nouveaux ou rectifiés.
F IG . 1.1 – Structure d‟un système expert

Il est très important de remarquer la séparation faite entre les connaissances et
l‟inférence.
- Cette séparation permet d‟utiliser un codage différent, cela nous permet par exemple
d‟utiliser le langage naturel pour représenter les connaissances (sous forme Si ...
Alors... par exemple).
2
- Cette séparation permet au programmeur de se focaliser au codage des connaissances

sans se soucier trop de la façon du codage du moteur d‟inférence.
- Cette séparation permet aussi de modifier les connaissances sans avoir un effet sur le
codage du moteur d‟inférence.
- Cette séparation permet également de pouvoir tester plusieurs types d‟inférence sur la
même base de connaissances.
1.3. Domaines d’application

Les systèmes experts ont été conçus pour résoudre certains types de problèmes comme
en médecine, en droit, en chimie, en éducation etc. Les catégories de problèmes abordés par
les systèmes experts sont :
- L‟interprétation ou la construction d‟une description abstraite à partir de données.
- La prédiction des conséquences à partir de situations données.
- Le diagnostic d‟une défaillance à partir d‟un ensemble d‟observations.
- La conception d‟une configuration de composants à partir d‟un ensemble de
contraintes.
- La planification d‟une séquence d‟actions pour l‟accomplissement d‟un ensemble de
buts à partir de certaines conditions de départ et en présence de certaines contraintes.
- La réparation d‟un dysfonctionnement.
- Le contrôle du comportement d‟un environnement complexe.
1.4. Problèmes adaptés aux systèmes experts

Les chercheurs ont défini un ensemble informel de critères pour déterminer si un
problème est adapté ou non à être résolu par la technologie système expert :
1. Le besoin d‟une solution doit justifier le coût et l‟effort de la construction d‟un système
expert.
2. L‟expertise humaine n‟est pas valable dans toutes les situations dont on a besoin.
3. Le problème peut être résolu en utilisant une technique de raisonnement symbolique.
4. Le domaine est bien structuré.
5. Le problème ne peut pas être résolu en utilisant des méthodes traditionnelles de calcul.
6. La coopération entre experts de domaine existe.
7. Le problème est de taille considérable.
1.5. Processus d’ingénierie de connaissance

Le minimum de personnes concernées par le développement d‟un système expert sont :
- l‟ingénieur de connaissance qui est un expert en langage IA. Son rôle est de trouver les
outils et les logiciels nécessaires pour l‟accomplissement du projet, d‟aider l‟expert du
domaine à expliciter sa connaissance et d‟implanter cette connaissance dans la base de
connaissances.
- L‟expert du domaine qui fournit les connaissances nécessaires liées au problème.
La disponibilité de l‟expert est bien évidemment une condition sine qua non. Elle n‟est
3
pas toujours acquise. Par définition, l‟expert est la personne particulièrement

compétente, souvent irremplaçable dans l‟activité quotidienne du service.
L‟acceptation de l‟expert est également une condition tout aussi évidente. Elle n‟est pas
toujours immédiate, et la proposition faite est parfois rejetée. La crainte de l‟expert
quant à son propre avenir n‟est pas étrangère aux hésitations ou aux refus enregistrés,
notamment lorsqu‟il est encore praticien.
La dernière condition, enfin, pour disposer d‟un expert est que ce dernier ait l‟aisance
suffisante pour exprimer, décrire, détailler sa façon de faire. Il s‟agit ici de la capacité à
réfléchir et à analyser sa pratique et surtout à en dégager les traits et les moments
essentiels.
Dans la phase d‟exploration et d‟expérimentation, l‟expert a en fait un rôle beaucoup
plus large celui de participer à la définition des objectifs ou tout au moins influer sur
eux. C‟est en fonction de la vision qu‟il a de l‟activité à expertiser qu‟il oriente l‟utilité
à donner au S.E.
- l‟utilisateur final dont le rôle est de spécifier l‟application et de déterminer les
contraintes de la conception.
En général, le travail commence par une interview entre l‟ingénieur de connaissance et
l‟expert du domaine. L‟ingénieur essaie de comprendre le domaine, d‟observer l‟expert
pendant son travail. Une fois l‟expert ait obtenu des informations complètes et précises sur le
domaine ainsi que sur la résolution du problème, il pourrait entamer la tâche de la conception
du système.
Il choisit la façon de la représentation des connaissances, Il détermine le type du
raisonnement et la stratégie utilisée (chaînage avant, arrière ou mixte, en profondeur ou en
largeur). Il conçoit de même l‟interface utilisateur. Le prototype obtenu doit être capable de
résoudre correctement un problème typique. Ce prototype doit être testé et affiné par
l‟ingénieur et l‟expert du domaine en même temps.
Le prototype peut être complété au fur et à mesure en ajoutant des nouveaux éléments
dans la base de connaissances. Souvent, à la fin de ce travail progressif, l‟ingénieur serait
amené à refaire une version plus propre qui réécrit la connaissance d‟une façon plus
sommaire.
Dans certains cas, l‟ingénieur de connaissance se limite à l‟extraction de connaissance
et la reproduction des modèles de base de connaissance et fait recours à un informaticien
(développeur) pour traduire l‟application en employant un outil de développement approprié
tel qu‟un langage de programmation.
Aujourd‟hui de nombreux outils sont disponibles sur le marché. Mais il convient de
distinguer d‟une part les systèmes-experts proprement dit, dits « sur mesure » ou bien encore
« à la carte », et d‟autre part les générateurs de systèmes-experts, et parmi ceux-ci les
systèmes-experts dédiés. Les premiers ont un moteur d‟inférence propre à chacun d‟eux, dont
les règles de traitement des connaissances sont issues de l‟expertise elle-même. Ils requièrent
un cogniticien, l‟extraction des connaissances et leur formalisation étant très différentes de
celles réalisées par l‟informaticien. Les seconds ont déjà un moteur d‟inférence, constitué par
un logiciel implantable directement sur un microordinateur.
4
Ils sont accompagnés d‟une méthode d‟écriture des règles permettant une mise en forme
immédiate des connaissances. Enfin, les « systèmes-experts dédiés » sont aussi des
générateurs, mais spécialisés à un domaine particulier : la maintenance, la documentation,
etc.
1.6. Acquisition de connaissance

Dans son rôle, l‟ingénieur de connaissance doit traduire l‟expertise informelle en un
langage formel adapté au mode du raisonnement du système. Plusieurs points doivent être
soulevés concernant l‟acquisition des connaissances :
1. La compétence humaine n‟est pas souvent accessible via la conscience. Avec
l‟expérience acquise, la compétence et la performance d‟un expert s‟installe et opère
dans l‟inconscient. Par conséquence, il est difficile aux experts d‟expliciter son savoir-
faire.
2. L‟expertise humaine prend souvent la forme du savoir comment plus que la forme du
savoir quoi.
3. L‟expertise humaine représente un modèle individuel ou un modèle de communauté.
Ces modèles sont soumis aux conventions et aux procédés sociaux.
4. L‟expertise change et peut subir des reformulations radicales.
A cause de la complexité et de l‟ambiguïté posées par le problème de l‟acquisition de
connaissances, l‟ingénieur de connaissances doit avoir un modèle conceptuel lui permettant
de faire la liaison entre l‟expertise humaine et le langage de programmation, ce modèle
constituera ce qu‟on appellera représentation de connaissances.
1.7. Les différentes sortes de système expert

Selon la complexité des variables et du langage d'évaluation, les systèmes experts sont
classés en 3 principaux types :
 Système Expert d’ordre 0 : Faits booléens sans variable.
Exemple : Si la voiture ne démarre pas et les phares ne s'allument pas alors il n'y a plus de
batterie.
Il s'agit ici d'une version primaire des systèmes experts qui n'est capable que d'évaluation
binaire. Ses capacités sont limitées mais ses performances sont en général excellentes.
 Système Expert d’ordre 0+ : Symboliques, Réels, Priorités.
Exemple : Si Age > 17 Alors statut = « Majeur ».
Ce type de systèmes experts assimile la notion de priorité qui permet de faire passer
certains tests ou évaluations avant d'autres, leurs importances étant plus grande. Il intègre
aussi l'arrivée de nombres réels et les évaluations symboliques (<, >, =, !=).
 Système Expert d’ordre 1 : Variables et Quantificateurs.
Exemple : Si Commutateur[M].status = libre alors Exec(PriseEnCharge, M).
A ce niveau de complexité, les systèmes experts savent gérer des variables (donc stocker
5
des informations pendant une évaluation) et peuvent utiliser des quantificateurs (évaluation
des connaissances incertaines) ou états (ex : libre, occupé, transféré, en attente...).
6
Chapitre 2. Systèmes à base de règles de productions

Les systèmes à base de règles de production "emmagasinent" la connaissance sous
forme de règles : SI ... ALORS ... afin d‟être le plus proche de la façon naturelle de la
représentation des connaissances. La partie entre le SI et le ALORS s‟appelle la partie
prémisses de la règle. Elle correspond à une conjonction d‟expressions qui doivent être
vérifiées pour que la règle se déclenche. La partie qui suit le ALORS s‟appelle la partie
conclusion. Elle correspond à une conjonction d‟actions.
En logique de propositions ou de premier ordre, les règles sont décrites via des clauses
contenant des propositions ou des prédicats. Rappelons-nous que PROLOG supporte bien ces
deux types de modélisation et applique la stratégie de raisonnement SLD pour résoudre un but
donné, nous allons voir dans la suite que cette stratégie constitue une inférence en chaînage
arrière.
2.1. Clause de Horn et SLD-résolution

En calcul propositionnel, une clause de Horn est une clause comportant au plus un
littéral positif (ex. proposition P). Les clauses de Horn forment un sous–ensemble des formes
normales disjonctives dans lesquelles un seul terme est positif.
De plus toute clause de Horn est de la forme
(qui peut aussi s'écrire sous la forme ).
Dans le cadre de la SLD-résolution, le littéral positif d'une clause définie est appelée la
tête, la conclusion ou le but de la clause. La disjonction des littéraux négatifs, s'ils existent, est
appelée le corps, les antécédents, ou les sous-buts. Par exemple, la clause de Horn :
¬ a ∨ ¬ b ∨ c est logiquement équivalente à (a ∧ b) → c
Dans chacun des cas, c est la conclusion, a et b sont les antécédents.
Le mécanisme de résolution
Étant donné un programme (un ensemble de clauses de Horn) et une requête (une
conjonction de littéraux positif dont on souhaite prouver qu'il est vrai d'après le programme),
la SLD-résolution fonctionne globalement comme d'autres formes de résolution, en tentant
d'unifier des clauses de Horn pour en créer de nouvelles, jusqu'à ce qu'une contradiction soit
atteinte, ou qu'aucune nouvelle unification ne puisse être faite.
Plus précisément, la SLD-résolution commence par construire la négation de la requête
(on obtient donc une clause de Horn négative, que nous appellerons la liste de buts), puis
unifie le premier élément de cette négation avec une clause du programme. La clause en
question est recherchée de manière déterministe, en recherchant la première clause du
programme dont la tête est la contrepartie positive de la première négation de la liste de buts.
Si une contradiction est trouvée, alors la négation de la requête est inconsistante avec le
programme, la requête termine donc avec succès. Si aucune unification ne peut être trouvée
pour le premier terme négatif de la liste de buts, alors la requête échoue. Si une unification
sans contradiction existe, alors la nouvelle liste de buts devient la conjonction de l'ancienne
7
avec la clause sélectionnée, et la SLD-résolution est relancée (de manière récursive) sur la
nouvelle liste de buts. Si une sous-requête échoue, alors l'unification de niveau supérieur dont
elle provient échoue, et l'algorithme cherche une autre unification (dans la suite du
programme) pour le premier terme de la liste de buts. Cette étape s'appelle le retour sur trace.
2.2. Exemple d’une modélisation par règle.

Prenons l‟exemple suivant :
1. SI X aime la musique classique et les maths ALORS il pourrait aimer Bach
2. Si X aime la musique classique et est de tempérament romantique ALORS il pourrait
aimer Schubert.
3. SI X est de tempérament romantique ALORS il pourrait aimer Cabrel.
4. SI X écrit des poèmes ALORS il est de tempérament romantique.
Nous pouvons modéliser ces quatre règles avec la logique de prédicats, en utilisant les
clauses de Horn :
; R1
peutAimer(X,bach)<- aime(X,musiqueC), aime(X, maths).
;R2
peutAimer(X,schubert)<- aime(X,musiqueC),romantique(X).
;R3
peutAimer(X,cabrel)<- romantique(X).
;R4
romantique(X) <- ecritPoeme(X).
Avec la notation en clauses de Horn, nous pouvons construire le modèle minimal de
Herbrand ainsi que la résolution SLD. Nous rappelons encore ces deux mécanismes via
l‟exemple, en vue de faire la comparaison avec le chaînage avant et arrière ultérieurement.
Supposons qu‟on ajoute aux programmes précédents les deux clauses suivantes :
aime(toto,muiqueC). ecritPoeme(toto).
La résolution SLD nous permet de calculer toutes les réponses à une question donnée, en
explorant toutes les dérivations possibles, l‟arbre obtenu s‟appelle l‟arbre de dérivation. Les
feuilles correspondent à des fins de chemins de parcours correspondant à un échec ou à un
succès. Dans le cas d‟un succès, la substitution correspondant à la composition des
substituions élémentaires trouvées est une solution calculée. Par exemple, une solution
possible à la question peutAimer(toto,Y) est la substitution θ = (Y, schubert).
Le modèle minimal d‟Herbrand nous rappelons que le modèle permet grâce à l‟opérateur
conséquence immédiate de retrouver le modèle minimal de Herbrand qui constitue l‟ensemble
des réponses correctes du programme. Par exemple, pour le programme précédent, nous
obtenons le modèle minimal de Herbrand IE suivant :
8
T 0 = {aime(toto,musiqueC), ecritPoeme(toto)}
T 1 = {aime(toto,musiqueC), ecritPoeme(toto), romantique(toto)}
IE = T 2 = {aime(toto,musiqueC), ecritPoeme(toto), romantique(toto), peutAimer(toto,
schubert), peutAimer(toto,Cabrel)}
2.3. Règles et moteur d’inférence
Dans un système à base de règles, les connaissances sont représentées par des règles. Le
moteur d‟inférence peut fonctionner en chaînage arrière ou avant. Le chaînage arrière signifie
que le raisonnement est guidé par le but tandis que le chaînage avant signifie que le
raisonnement est guidé par les données. Nous décrivons dans la suite ces deux mécanismes, et
nous les comparons. Notons bien que pour pouvoir décrire ces deux mécanismes nous
consultons au fur et à mesure la mémoire de travail qui nous guide pour le raisonnement
2.3.1. Le chaînage arrière : raisonnement guidé par le but

En chaînage arrière, le but est placé au début dans la mémoire de travail du système. Le
système cherche dans sa base de connaissances les règles dont la conclusion corresponde au
but posé. Une des règles est choisie selon une stratégie donnée. Ses prémisses sont empilées
dans la mémoire de travail et deviennent les sous-buts actuels à résoudre. Le système continue
à travailler de cette façon jusqu‟à ce que tous les sous buts placés en mémoire soient vérifiés.
Les sous-buts peuvent être résolus en posant des questions à l‟expert. Le principe de
base est donné par le modus tollens : si (A⇒B et ┐B) alors A
Nous donnons l‟algorithme permettant d‟effectuer le chaînage arrière :
entrée BC la base de connaissances, Mem pile de travail, θ la substitution actuelle.
sortie S un ensemble de substitution
variables locales R, un ensembles vide
– SI M em est vide ALORS RETOURNER (θ).
– elem ← FIRST(M em).
– POUR chaque règle p1 ∧ ... ∧ pn → C tel que
θi ⇐ UNIFY(C ,elem) FAIRE
– R ← ChaînageArrière(BC , SUBST(θi ,[p1 , ..pn ]),COMPOSE(θ,θi ))∪ R
Retourner l‟union de ChaînageArrière(BC,REST(Mem),θ) pour chaque θ ∈ R
UNIFY étant une fonction qui calcule l‟unificateur le plus général des deux termes et
SUBSET est une fonction qui retourne une liste de termes après lui avoir appliqué la fonction
θ. Notons bien que l‟algorithme Chaînage arrière est un algorithme récursif. Le premier appel
est : ChaînageArrière(BC ,[but],{}).
Supposons qu‟on aimerait bien répondre à la question peutAimer(toto, X).
Au premier appel la mémoire de travail M em contient [peutAimer(toto, X)], les
conclusions des règles R1 , R2 , R3 peuvent s‟unifier avec le but, θ vaut ², R est vide.
Au deuxième appel la mémoire de travail contient [aime(toto,musiqueC],
aime(toto,math)], θ vaut {(X,bach)}, cette règle échoue car aime(toto, math) n‟est pas dans la
9
base de fait. Par conséquent R reste inchangeable.

Au troisième appel, la mémoire de travail contient [aime(toto, musiqueC],
romantique(toto))], θ vaut {(X,shubert)}, aime(toto,musiqueC)] étant dans la base, le
système cherche à résoudre le but romantique(toto), R reste inchangeable car les prémisses
de la règle ne sont pas toutes explorées encore.
Au quatrième appel la mémoire de travail contient [ecritPoeme(toto))], la conclusion de la
règle R4 s‟unifie avec le but actuel et la branche aboutit à un succès et donc R = {(X,
schubert), (X 4, toto)}.
Au cinquième appel, la mémoire de travail M em contient[romantique(toto))] et θ vaut

{(X,cabrel)}, la branche aboutit à un succès et donc R = {(X, cabrel)}.
Fin du premier appel, on retourne l‟union des substitutions réussies :{(X, schubert), (X,
cabrel)}
Nous pouvons par ailleurs considérer la formulation suivante de ce même

algorithme présenté sous forme de deux fonctions :
Fonction chaînageArriere
Paramètres : in BR, in BF, in listeButs.
if estV ide(listeButs) then
res ← SUCCES
else
if demBut(premier(listeButs)) then
res ← chaînageArriere(suite(listeButs))
else
res ← ECHEC
end if
end if
retourner res
Fonction demBut
Paramètres : in BR, in BF, in but.
if but ∊ BF then
res ← SUCCES
else
regles ← BR; res ← ECHEC
while regles ≠∅ ; et res ≠ SUCCES do
10
r ← choix(regles); regles ← regles - {r}

if conclusion(r) = fait then
res ← chaînageArrière(BR, BF, premisse(r))
end if
end while
retourner ← res
end if
Notons bien que le système garde aussi la trace de son raisonnement sous forme d‟un
graphe de type et/ou (voir figure 2.1). Cela permet au système de savoir à n‟importe quel
moment le cheminement de l‟inférence malgré le changement du contenu de la mémoire de
travail. Autrement dit, à n‟importe quel moment le système est capable de récupérer :
– la décomposition en sous buts d‟un but donné.
– le but père d‟un but donné.
Nous verrons dans la suite que cela peut qualifier une telle inférence d‟une capacité de
transparence de raisonnement et d‟une capacité d‟explication.
Ce graphe contient deux types de nœuds à savoir les nœuds ou et les nœuds et. Les
nœuds ou correspondent aux règles ayant une conclusion qui peut s‟unifier avec le but
cherché, chacune de ces règles est le début d‟un chemin potentiel de résolution. Les nœuds et
correspondent aux prémices d‟une règle donnée qui tente de résoudre un but qui s‟est unifiée
avec sa conclusion. Ces prémisses deviendront à leurs tours des sous-buts à résoudre. Par
exemple, dans la figure 2.1), le nœud PeutAimer() est un nœud ou et le nœud R1 est un nœud
et.
F IG . 2.1 – Le graphe du raisonnement en chaînage arrière
11
Nous avons montré comment un système basé sur l‟inférence par chaînage arrière
peut réagir. Pour vérifier le succès ou l‟échec d‟un chemin de raisonnement, la base de
faits est consultée. Une extension de l‟algorithme peut être de donner la capacité au
système de poser des questions à l‟utilisateur quand une réponse positive ne soit pas
affirmée par l‟existence d‟un fait donné dans la base de faits. Nous montrons dans la
suite un scénario de questions-réponses, et ceci en se basant toujours sur l‟exemple cité
au dessus, contenant les quatre règles mais en supposant que la base de faits est vide au
début. Le but à résoudre étant toujours peutAimer(toto,X) :
Le système commence à explorer la première branche à gauche en profondeur
jusqu‟à l‟arrivée au sous but aime(toto,musiqueC) qui n‟est pas dans la base de faits et
qui ne s‟unifie pas avec aucune conclusion non plus. Au lieu de considérer cette branche
comme échec, le système pose la question à l‟utilisateur (Elle peut correspondre à une
information manquante dans la base de faits) vérifiant si toto aime la musique classique.
Supposons que la réponse est positive, alors le fait aime(toto,musiqueC) est ajouté à la
base de faits. Le système cherche maintenant à continuer la résolution du but
peutAimer(toto,bach), il pose donc la question aime(toto,maths). En supposant que la
réponse est non, le système passe à la vérification de la deuxième règle. La question
aime(toto,musiqueC) n‟est pas posée car le système connaît la réponse qui est codée
sous forme de fait. Le sous but suivant à vérifier est romantique(toto), donc la question
ecritpoeme(toto) est posée ; par conséquent, le système déduit que peutAimer(toto,
schubert) est vrai. Enfin, le système vérifie bien via le chemin de la règle R3 que toto
puisse aimer également cabrel sans poser des questions car il sait déjà que toto écrit des
poèmes. (Remarquer qu‟en cas de réponse négative à la question aime(toto, musiqueC),
le système ne pose pas la question aime(toto, maths).
Remarquer bien que de fait que le système garde le trace du raisonnement sous
forme du graphe et/ou permet d‟avoir une suite de questions qui ne paraît pas illogique
aux yeux de l‟utilisateur (Trois questions ont été posé à l‟utilisateur suite auxquelles, le
système a déduit que toto peut aimer schubert et cabrel. La suite des questions est la
suivante : est-ce que toto aime la musique classique ? est-ce que toto aime les maths ? et
est-ce que toto écrit des poèmes ?). De plus la séquence de questions est optimale dans le
sens ou le système ne pose pas des questions inutiles car son processus est toujours
guidé par la résolution du but père immédiat.
Explication et transparence du raisonnement : L‟utilisateur peut à n‟importe quel
moment poser deux types de questions : pourquoi et comment ? Par exemple quand le
système pose la question aime(toto,maths)à l‟utilisateur. L‟utilisateur peut demander des
justifications : Pourquoi poser cette question ? Puisque le système garde le trace de son
raisonnement sous forme du graphe et /ou, il sait que la question est le deuxième fils de
la règle numéro 1 donc il peut répondre : Puisqu‟il a été établi que aime(toto,musiqueC),
alors si aime(toto,maths), cela signifie que peutAimer(toto,bach).
L‟utilisateur peut ensuite poser la question Comment a-t-il été établi que toto est
romantique ? Le système peut se placer sur le nœud correspondant du graphe et présenter à
l‟utilisateur sa trace de raisonnement.
12
2.3.2. Le chaînage avant : raisonnement guidé par les données

En chaînage avant, le contenu de la mémoire correspond aux données qui peuvent
vérifier certaines prémisses des règles ; ces règles deviennent des règles candidates à être
utilisées dans le raisonnement. Dans la suite, le système prend en compte les règles candidates
selon un ordre donné et teste si le reste des prémisses sont vérifiées (en consultant la base de
faits ou bien en posant des questions à l‟utilisateur). Le principe de base est donné par le
modus ponens : si (A⇒B et A) alors B.
Nous présentons dans la suite l‟algorithme chaînage-avant :
entrée BC la base de connaissances, F un certain fait dans la base de faits
– Pour chaque règle p1 ∧ ... ∧ pn → C tel que θ ⇐ UNIFY(pi ,F ) FAIRE
– trouver-inférer (BF ,BC , [p1 , .., pi−1 , pi+1 , ..pn ]),C ,θ)
La procedure trouver-inférer est donnée par :
entrée BF la base de faits, BC la base de connaissances, prémisses, conclusion, θ
– SI prémisses=[ ] ALORS
– chaînage-avant(BC , SUBSET(θ,conclusion))
– SINON POUR chaque F1 dans la base de faits BF tel que θ2 ⇐ UNIFY(F1 ,SUBSET(θ,
FIRST(premises)))
FAIRE
– trouver-inférer (BF ,BC , REST(prémisses), conclusion, COMPOSE(θ,θ2 ))
Voyons comment le chaînage avant est effectué sur notre programme contenant les
quatre règles et les deux faits.
1. Le fait aime(toto,musiqueC) s‟unifie avec la première prémisse de la règle R1.
2. Le système cherche dans la base de faits un autre fait qui peut s‟unifier avec la
deuxième prémisse de R1. Echec.
3. Le fait aime(toto,musiqueC) s‟unifie avec la première prémisse de la règle R2.
4. Le système cherche dans la base de faits un autre fait qui peut s‟unifier avec la
deuxième prémisse de R2. Echec.
5. Le fait ecritPoeme(toto) s‟unifie avec la prémisse de la règle R4 et le fait résultant de la
conclusion romantique(toto) s‟ajoute à la base de faits.
6. Le fait romantique(toto) s‟unifie avec la deuxième prémisse de la règle R2 .
7. le système cherche à satisfaire la première prémisse de la même règle et réussit
avec le fait aime(toto, musiqueC)et donc le fait aime(toto,schubert) est inféré.
8. Le fait romantique(toto) s‟unifie avec la prémisse de la règle R3 et le fait
aime(toto,cabrel) est inféré.
13
Nous remarquons que le système a effectué trois parcours de la base de règles pour
arriver à inférer que toto puisse aimer schubert et cabrel.
Nous pouvons procéder de la même manière en supposant que la base de faits est vide
au début et que le système pose des questions à l‟utilisateur (Nous supposons que le système
stocke quelque part l‟information lui permettant de poser une question sur un fait donné.). Dans ce cas
l‟ordre de questions posées à l‟utilisateur est le suivant : aime(toto,musiqueC),
aime(toto,maths), ecritPoeme(toto).
Remarquer que si la règle R3 n‟existe pas et que si la réponse à la question
aime(toto,musiqueC) est négative, le système posera quand même la question
ecritPoeme(toto) ce qui n‟est pas le cas en chaînage arrière.
Une deuxième formulation de cet algorithme est :
Paramètres : in fait (le fait à démontrer)
if fait ∊ BF then
res ← SUCCES
else
reglesNonDéclenchées ← BR; reglesAConsidérer ← BR; res ← ECHEC
while reglesACconsidérer ≠ ∅ ; et res ≠ SUCCES do
r ← choisir(reglesAConsidérer); reglesAConsidérer ← reglesAConsidérer -{r}
if ∀ p ∊ premisse(r), p ∊ BF then
BF ← BF ∪ {conclusion(r)}
reglesNonDéclenchées ← ReglesNonDéclenchées - {r}
reglesAConsidérer ← reglesNonDéclenchées
if conclusion(r) = fait then
res ← SUCCES
end if
end if
end while
end if
renvoyer res
Un autre algorithme basé sur la représentation sous forme de graphe dirigé est proposé
dans la littérature (rete algorithm). Le principe est de coder dans la base de connaissances les
règles sous forme de graphe. Les prédicats sont codés par des cercles, les flèches représentent
le et logique entre les différentes prémisses. Les actions sont codées par des rectangles. Les
carrés représentent des contraintes sur les prémisses.
A un cycle donné, un ensemble de faits est injecté dans le graphe. Le résultat de cette
inférence serait présenté par des informations qui étiquettent les arcs du graphe. Au cycle
suivant, un ensemble de faits résultants seraient injectés dans le graphe, et ainsi de suite.
14
Par exemple considérons la base de connaissances suivante :

a(X),b(X),c(Y) => add d(X)
a(X),b(Y),d(X) => add e(X)
a(X),b(X),e(X) => delete a(X)
Et la base de faits suivante : {a(1), a(2), b(2), b(3), b(4), c(5)}.
Le graphe représentant l‟activation au premier cycle est donné par la figure 2.2.
FIG. 2.2 – Le graphe du raisonnement en chaînage avant

L‟avantage de cet algorithme par rapport à l‟algorithme d‟unification est sa capacité de
tester en même temps les prémisses communes des règles sans effectuer des unifications
plusieurs fois. De plus, il donne une représentation graphique de l‟ensemble des règles dans
la base de connaissances.
2.4. Petite comparaison

Nous remarquons que la capacité d‟explication et la transparence est plus développée en
chaînage arrière qu‟en chaînage avant parce que toutes les questions sont posées pour
répondre à des sous buts immédiats selon la trace de raisonnement représenté par le graphe
et/ou. Tandis qu‟en chaînage avant les questions sont posées selon l‟ordre de présentation des
règles dans la base de connaissances et peuvent parfois refléter une incohérence.
En fait, dans l‟exemple traité dans ce chapitre, nous avons constaté que l‟ordre de
questions posées à l‟utilisateur est le même. Par contre nous avons montré que le système peut
poser des questions inutiles en chaînage avant, ce qui n‟est pas le cas en chaînage arrière. Out
de même, le chaînage avant s‟arrête toujours bien qu‟il peut être très long et la mise en œuvre
de l‟algorithme de chaînage arrière est plus complexe et ne donne pas forcément la solution
optimale.
D‟un autre côté, si nous nous plaçons dans un cadre de modélisation en logique premier
ordre, nous remarquons que chaque chemin réussi de résolution en chaînage arrière
correspond à une réponse calculée par la résolution SLD. De même, le contenu de la base de
faits, après le chaînage avant, correspond bien au modèle minimale de Herbrand.
15
En vue de palier, lors du cheminement à travers la base de connaissance, aux

inconvénients des approches chaînage avant et chaînage arrière, on les combine parfois pour
obtenir un chaînage mixte. Dans ce type de stratégie la base de fait est composée à la fois des
faits établis et des buts à démontrer. Un exemple de chaînage mixte :
Fonction chaînageMixte
Paramètres : in BR, in BF, in but.
while but n‟est pas déduit, mais peut encore l‟être do
Saturer la base de faits par chaînage avant.
if but n‟est pas dans la base de faits then
Chercher une question pertinente à poser à l‟utilisateur
Poser la question à l‟utilisateur
Ajouter la réponse à la base de faits
end if
end while
2.5. Les stratégies de contrôle

En général, les systèmes effectuant les chaînages arrière ou avant appliquent une
stratégie de ré- solution de conflit bien définie. La plus part des systèmes choisissent la
première règle déclenchable à partir de l‟ordre défini par l‟utilisateur. Par exemple, en prolog,
la première règle dont la conclusion corresponde au but recherché est activée auparavant. La
coupure permet de limiter en effet l‟arbre de résolution mais ne change rien à l‟ordre des
règles.
En Clips, si l‟utilisateur ne définit pas de priorité, les règles activées par les mêmes faits,
sont égale- ment déclenchées d‟une façon aléatoire. Pourtant, il existe plusieurs stratégies de
résolution de conflit. Par exemple dans certains systèmes les règles les plus spécifiques (ayant
les plus de prémisses) sont choisies auparavant. Dans d‟autres, les facteurs de certitudes
affectés aux règles sont utilisés comme mesures de tri. Certains systèmes privilégient les
règles les plus utilisées en classant les règles selon leurs utilités. Dans d‟autres, les règles les
plus récentes sont prises en priorités.
Nous développons dans la suite quatre stratégies utilisées en chaînage avant et plus
particulièrement en CLips qui sont : en profondeur d‟abord, en largeur d‟abord, complexité,
simplicité.
La stratégie en profondeur d‟abord
La base de faits est considérée comme une pile, autrement dit chaque fois qu‟un
nouveau fait est inféré il est placé au sommet.
Revenons à notre exemple, le dernier fait inséré au premier cycle est ecritPoeme(toto),
ce fait dé- clenche la règle R4 et le fait romantique(toto) est ajouté à la base de fait. Ce fait
s‟unifie avec la deuxième prémisse de la règle R2, ainsi qu‟avec la prémisse de la règle R3.
La règle R2 étant à tester, le système cherche un fait qui peut s‟unifier avec la première
16
prémisse, et réussit avec aime(toto,musiqueC). Le fait aime(toto,shubert) est empilé dans la

base de faits, elle ne déclenche aucune règle. Maintenant, la règle R3 étant en attente de
déclenchement, elle est déclenchée et le fait aime(toto,cabrel) est empilé dans la base de faits.
La stratégie en largeur d‟abord
La base de faits est considérée comme une file, autrement dit chaque fois qu‟un
nouveau fait est inféré il est placé à la fin de la file.
La stratégie de simplicité
Tout d‟abord il faut savoir que les deux stratégies simplicité et complexité sont
orthogonales avec les stratégies en largeur et en profondeur. Autrement dit, on se place avant
dans un contexte donné (profondeur ou largeur) et on peut ensuite appliquer la stratégie
simplicité, complexité ou aucune ou bien vice versa, c'est-à-dire on se place avant dans un
contexte donné (simplicité ou complexité) et on peut ensuite appliquer la stratégie profondeur
ou largeur.
Une règle Rs est dite plus simple qu‟une règle Rc ssi la partie prémisse de la règle Rs a
moins d‟éléments que la règle Rc. Un élément peut correspondre à un prédicat mais aussi à un
test donné exprimé sous la forme d‟une contrainte sur les données ou les prédicats.
Le choix de la stratégie simplicité signifie que si un fait déclenche plusieurs règles en
même temps, la règle la plus simple est choisie avant indépendamment de son ordre. Par
exemple le fait romantique(toto) déclencherait la règle R3 avant la règle R2.
La stratégie de complexité
Il agit exactement à l‟inverse de la stratégie de simplicité.
17
Chapitre 3 : Le raisonnement incertain

Nous avons vu dans le chapitre précédent comment effectuer une inférence en utilisant
le chaînage avant ou arrière, et ceci à partir d‟une base de faits et d‟une base de
connaissances. Il se trouve que dans une grande majorité d‟applications réelles, l‟information
codée dans le système expert n‟est pas toujours certaine autrement dit elle peut avoir un degré
de véracité.
Un fait peut être incertain dans le sens où on n‟est pas sûr de sa valeur de vérité. Une
règle peut être incertaine dans le sens suivant : si les prémisses sont vrais on n‟est pas sur
d‟aboutir toujours à la conclusion.
Nous présentons dans ce chapitre deux grandes approches du traitement de l‟incertitude
dans les systèmes experts. La première catégorie comprend les approches statistiques comme
la théorie bayesienne, les facteurs de certitudes et la théorie de Dempster-Shafer. La deuxième
catégorie comprend les approches liées aux ensembles floues.
3.1. La théorie de Bayes

La théorie de Bayes est fondée sur le principe suivant : chaque hypothèse a une
probabilité à priori P (H). Cette probabilité est modifiée chaque fois qu‟on a une nouvelle
preuve E qui arrive. Donc la probabilité à posteriori de l‟hypothèse H devient :
Par conséquent, on a :
De plus, sachant que :
On peu écrire la formule suivante :
Avec
Exemple : Supposons que la probabilité qu‟un patient ait la grippe est à priori P(H).
Maintenant supposons qu‟on a la preuve E que ce patient ait de la fièvre. Nous cherchons à
calculer la probabilité à posteriori que ce patient ait la grippe sachant qu‟il a de la fièvre.
Nous devons calculer P (E) la probabilité d‟avoir la fièvre en général. Pour connaître P(E), on
cherche à estimer les probabilités d‟avoir la fièvre sachant qu‟on a la grippe P(E|H) et d‟avoir
la fièvre sachant qu‟on n‟a pas la grippe P(E|notH). Nous pouvons signaler deux
inconvénients liés à la théorie de Bayes :
18
1. Le calcul de P(E) n‟est pas toujours évident, sachant que si on ne connaît pas P(E|notH),
il faut arriver à connaître toutes les hypothèses qui peuvent influencer E : P(E|Hi). Dans
ce cas, on appliquera la formule :
2. Une contrainte forte qu‟exige cette approche est l‟indépendance des variables utilisées.
Souvent, dans les applications réelles, il existe une corrélation cachée entre les
différentes variables.
Dans la suite, nous fixerons un seuil supérieur M1 et un seuil inférieur M2 pour chaque
hypothèse Hi tels que M1 et M2 ne dépassent pas les limites théoriques que peut prendre la
probabilité à posteriori à savoir Pmax (Hi ) = P (H |E1 , .., En ) ,Pmin (Hi ) = P (H |notE1 , ..,
notEn ) respectivement, où E1, .., En sont toutes les preuves possibles qui peuvent supporter
l‟hypothèse H .
Remarquons bien que tant qu‟on a des réponses concernant certaine preuves, Pmax(Hi)
et Pmin(Hi) changent de valeurs car ils seront calculés en fonction des preuves non renseignées.
Si à un moment Pmin(Hi) devient supérieur à M1 alors l‟hypothèse Hi est confirmée, sans tester
les preuves qui restent. De même si Pmax(Hi) à un moment, devient inférieur à M2 alors
l‟hypothèse H est rejetée, sans tester les preuves qui restent.
Dans la suite, nous montrons comment intégrer cette approche dans un moteur
d‟inférence donné. Les preuves sont demandées à l‟utilisateur une par une et selon sa
réponse, une nouvelle probabilité à posteriori est associée à Hi , ainsi qu‟une nouvelles
Pmax (Hi ) et Pmin (Hi ) sont calculée en fonctions des preuves restantes. Nous pouvons
supposer que l‟utilisateur donne une réponse plus au moins subjective, avec une certitude
donnée. Pour cela, nous pouvons calculer la probabilité à posteriori de H après la réponse R
de l‟utilisateur par :
où P(E|R) est une mesure de la certitude que donne l‟utilisateur à la preuve E. De même,
P(notE|R) est une mesure de la certitude que donne l‟utilisateur à notE.
3.1.1. Le moteur d’inférence

Nous proposons une méthode qui permet de choisir la question à poser à l‟utilisateur
(Sideways Chaining). Cette méthode permet de choisir une question concernant une certaine
preuve. Nous associons à chaque preuve dans le système une valeur selon :
Ces valeurs ne sont pas inchangeables car ils modifient leurs valeurs selon la probabilité
à posteriori de l‟Hypothèse H. La preuve ayant la valeur maximale obtenue va constituer la
première question à poser à l‟utilisateur.
Nota : Selon la terminologie, les preuves correspondent aux faits ; les conclusions
19
correspondent aux hypothèses qu‟on essaie de déduire.

L‟algorithme
Nous présentons dans ce chapitre l‟algorithme nous permettant d‟activer l‟inférence qu‟on
appelle chaînage lateral.
1. Pour chaque hypothèse, affecter une probabilité à priori p(Hi ).
2. Pour chaque preuve calculer la valeur val(Ej ).
3. Trouver la preuve ayant la valeur maximale : Emax .
4. Interroger l‟utilisateur sur cette preuve en lui donnant un intervalle de confiance [-
5,+5], la ré- ponse étant R.
5. Étant donné R, recalculer P (Hi |R) pour toutes les hypothèses dépendantes de Emax .
6. Recalculer aussi les valeurs associées aux preuves différentes restantes.

7. Pour chaque hypothèse Recalculer le min et le max que peut avoir la probabilité à
posteriori de Hi .
8. Trouver l‟hypothèse ayant le minimum le plus élevé : Hmaxmin
9. Chercher une hypothèse dont Pmax (Hk ) dépasse la valeur trouvée dans l‟étape suivante.
10. En cas d‟existence de cette hypothèse, retourner à l‟étape 3 sinon arrêter et l‟hypothèse
Hmaxmin est confirmée.
3.2. Les facteurs de certitude

Le principe de la théorie des facteurs de certitude est d‟affecter à un fait donné ou à une
règle donnée un facteur de certitude. Ce facteur sera pris en compte dans l‟inférence
effectuée. La théorie est fondée sur certaines hypothèses :
1. La somme de la confiance associée à une hypothèse et celle associée à son inverse est égale à 1.
2. Les mesures de confiance correspondent à l‟évaluation informelle que donnent les humains à
l‟information.
Deux mesures doivent être affectées à une hypothèse donnée étant donnée une preuve :
la mesure de croyance M B(H |E) et la mesure de non-croyance M D(H |E). Le facteur de
certitude associé à cette même hypothèse étant donné la preuve E : est C F (H |E) = M B(H |E)
− M D(H |E).
Les mesures de croyance varient dans l‟intervalle [0,1] et par conséquence :
−1 ≤ C F(H |E) ≤ 1.
Nous pouvons associer un facteur de certitude à un fait donné ou à une règle donnée.
Nous donnons dans la suite les règles qui permettent la propagation des facteurs de certitudes
pendant l‟inférence. Supposons que nous associons aux deux faits F1 et F2 les mesures de
certitudes suivantes : C F (F1) et C F (F2). Supposons maintenant que nous avons les deux
règles suivantes :
R1 : SI P1 ET P2 ALORS C1
20
R2 : SI P1 OU P2 ALORS C2
En supposant que le fait F1 s‟unifie avec P1 et F2 avec P2, la certitude associée à la
partie prémisse de R1 est donnée par
C F (P 1ET P 2) = min (C F (F1 ), C F (F2 ))
de même, la certitude associée à la partir prémisse de R2 est donnée par
C F (P 1OU P 2) = max (C F (F1 ), C F (F2 ))
Maintenant, en supposant qu‟un facteur de certitude est associé à la règle R : C F (R),
nous calculons le facteur de certitude associé à la conclusion résultante par C F (C ) = C F (R)
∗ C F (P ), où CF(P) est le facteur de certitude associé à la partie prémisses de la règle R.
Considérons maintenant le cas où deux règles R1 et R2 (ou plus) aboutissent à la

même conclusion C. Nous appelons C FR1 (C ), le facteur de certitude calculé par la
première règle et C FR2 (C ), le facteur de certitude calculé par la deuxième règle ; dans ce cas
le facteur de certitude final est donné par :
C F (C ) = C FR1 (C ) + C FR2 (C ) − C FR1 (C ) ∗ C FR2 (C ) si les deux facteurs de
certitudes initiaux sont positives et par : C F (C ) = C FR1 (C ) + C FR2 (C ) + C FR1 (C ) ∗ C

FR2 (C ) si les deux facteurs de certitude sont négatifs et par :
Sinon
Remarquer bien que grâce à ces formules, les facteurs de certitude résultants sont
toujours dans l‟intervalle [-1,1].
Remarquer également que les affectations des facteurs de certitude aux règles et aux
faits sont subjectives et dépendent de l‟humain. Par contre les calculs qui permettent la
propagation de ces facteurs de certitude obéissent aux règles précédentes.
3.3. Les ensembles flous

Une donnée floue est une pièce d‟information qui peut prêter à une ambiguïté dans le
sens où elle correspond à un intervalle de données fixe dans un univers de discours. Par
exemple les concepts jeune, grand sont des concepts flous. Par exemple avoir un âge de 35
ans ne signifie pas qu‟on est jeune à 100% ni qu‟on n‟est pas jeune à 100%.
Mathématiquement parlant un ensemble flou A défini sur un univers de discours U est
caractérisé par la fonction d‟appartenance :
µA : U → [0, 1]
Par exemple, le terme flou jeune est caractérisé par :
{(25, 1.00), (30, 0.8), (35, 0.6), (40, 0.4), (45, 0.2), (50, 0.00)}
21
Les variables linguistiques

Une variable linguistique est décrite par l‟ensemble de termes flous qu‟elle pourrait
prendre. Par exemple la variable âge est décrite par l‟ensemble des termes flous : {jeune,
vieux}, chaque terme étant un ensemble flou. D‟un autre côté, nous appelons fait flou un fait
contenant le couple : {variable linguistique, valeur floue} (voir figures 3.1 et 3.2).
F IG . 3.1 – L‟ensemble flou (âge jeune)

Les ensembles flous sont munis de quatre opérations fondamentales :
L’intersection : Soient FA et FB deux ensembles flous définis sur le même univers de discours
U. L‟intersection des deux ensembles flous est un nouvel ensemble flou qui sera défini par
inter(FA , FB )(u) = min(µFB (u), µFA (u)) (voir figure 3.3)
L’union : Soient FA et FB deux ensembles flous définis sur le même univers de discours U.
L‟union des deux ensembles flous est un nouvel ensemble flou qui sera défini par union(FA ,
FB )(u) = max(µFB (u), µFA (u)) (voir figure 3.4)
Le complément : Soit FA un ensemble flou défini sur l‟univers de discours U. Le complément
de cet ensemble sera défini par complement(FA )(u) = 1 − µFA (u) (voir figure 3.5)
Le produit : Soient FA et FB deux ensembles flous définis sur les univers de discours U
et V. Le produit des deux ensembles flous est un nouvel ensemble flou qui sera défini sur
U ∗ V par produit(FA , FB )(u) = f (µFB (u), µFA (u)), f peut être la fonction min, max etc.
22
F IG . 3.2 – Les deux ensembles flous (âge jeune) & (âge vieux)
Règles de type CRISP-CRISP Les règles de type CRISP-CRISP sont des règles qui ne
contiennent pas de termes flous dans leurs parties prémisses ni dans leurs parties
conclusions. Par contre, elles peuvent avoir des facteurs de certitude. Les règles de
propagation de certitudes vues dans la section précédente sont applicables à ce type de règles.
Règles simples de type FUZZY-CRISP En général, les règles de type FUZZY-CRISP sont
des règles dont la partie prémisses contient un test sur un fait composé d‟une variable
linguistique avec une valeur floue. La conclusion ne contient pas de terme flou. Nous
définissons une règle simple de type FUZZY- CRISP comme étant une règle qui comporte un
seul test flou dans sa partie prémisses. Supposons que FA représente l‟ensemble flou du fait flou
A, et que FB représente un test sur la même variable linguistique contenue dans A dans une
règle donnée.
Nous calculons la similarité entre le fait et la règle selon :
S = P (FB |FA )
si N (FB |FA ) > 0.5 et par S = (N (FB |FA ) + 0.5) ∗ P (FB |FA ) sinon
N ,et P étant les mesures de nécessité et de possibilité respectivement calculées par (voir
figures 3.6 & 3.7) :
P (FB |FA ) = max(min(µFB (u), µFA (u))
Et
N (FB |FA ) = 1 − P (C OM P (FB )|FA )
F IG . 3.3 – Intersection de deux ensembles flous (âge jeune) & (âge vieux)
C OM P (FB ) étant le complément de FB et est décrit par
muC OM P (FB ) (u) = 1 − µFB (u)
Une fois l‟inférence est effectuée le facteur de certitude propagé à la conclusion : C F (C ) de

la règle sera multiplié par la mesure de similarité précédente.
23
Règles simples de type FUZZY-FUZZY En général, les règles de type FUZZY-FUZZY

sont des règles qui contiennent dans leurs parties premisses des tests sur des faits flous et
dans leurs parties conclusions des manipulations sur de faits floues . De même, une règle
simple de type FUZZY-FUZZY est une règle dont la partie prémisse est composée d‟un seul
test flou, et la partie conclusion contient une manipulation sur un seul fait flou. En fait, la
règle est vue comme une relation entre les deux faits (fait prémisse et fait conclusion).
Soit FA l‟ensemble flou représentant un fait existant dans la base de faits sur le quel est
effectué un test dans la partie prémisse de la règle R. Soit FC le fait dans la conclusion de
la règle floue R. La règle représente une relation floue R = FA ∗ FC . On peut par exemple,
représenter cette relation par la fonction d‟appartenance suivant :
µR (u, v) = min(µFA (u), µFC (v))

Soit maintenant FB le test sur la valeur de la variable linguistique contenu dans le fait FA
alors la fonction d‟appartenance µFC’ de la conclusion résultante C 0 sera donné par :
FIG. 3.4 – Union de deux ensembles flous (âge jeune) & (âge vieux)
En simplifiant, on retrouve (voir figure 3.8) :
Avec :
Les règles floues complexes

Nous distinguons deux cas :
- Il existe plusieurs faits flous dans la conclusion : Dans ce cas la règle SI A alors C1 et C2
et ..Cn est traitée exactement comme la séquence des règles SI A alors C1,SI A alors C2,.. SI A
alors Cn.
- Il existe plusieurs tests flous dans la partie prémisse : Si nous avons la règle Si B1 et B2
alors C B1 est un test sur le fait flou A1 , B2 est un test sur le fait flou A2 , alors les ensembles
flous FC 1 et FC 2 résultant de l‟application des deux règles : Si B1 alors C et Si B2 alors C
24
sont calculés. Le résultat global est :
Autrement dit :
Combinaison de résultats : Supposons que nous avons une règle de type FUZZY-FUZZY et
dont une partie de la conclusion : C1 concerne l‟ajout d‟un fait flou dans la base de faits.
Supposons qu‟avant le déclenchement de cette règle, il existe déjà dans la base de fait un fait
F1 qui porte sur la même variable linguistique que C1. Dans ce cas, le déclenchement de la
règle précédente implique l‟ajout du fait C2 dans la base de fait qui remplacera F1, et ceci
selon :
FIG. 3.5 – Le complément d‟un ensemble flou

Autrement dit :
µFC 2 (u) = max(µFC 1 (u), µFF 1 (u))
La notion de defuzzification
Dans certaines applications, comme les applications de contrôle il est nécessaire et intéressant
de représenter l‟ensemble flou par un seul point qui sera considéré comme le point le plus
représentatif de l‟ensemble. Nous appelons cette opération defuzzification. Une méthode est la
méthode du centre de gravité, elle est effectuée par le calcul du centre de gravité de tous les
points, en pondérant chaque point par son degré flou. Une deuxième méthode qui peut être
utilisée est la méthode du maximum, elle suppose que le point le plus représentatif est celui
ayant le degré flou maximal. Dans le cas de l‟existence de plusieurs points, la moyenne est
calculée. Noter bien que les définitions données ici correspondent bien à des ensembles flous
définis dans des univers de discours finis. Il est possible d‟étendre ces définitions bien sur les
univers infinis et ceci en utilisant la notion de l‟intégrale mathématique.
3.4. La théorie de Dempster-Shafer

La théorie de Dempster-Shafer est fondée sur la modélisation de l‟incertitude par un
intervalle de probabilités plutôt que par une simple probabilité numérique. Elle intègre deux
notions : la notion de l’incertitude et la notion de l’ignorance. La théorie de Dempster-Shafer
25
associe à une proposition don- née l‟intervalle : [Confiance, Plausibilité]. Cet intervalle est
compris entre 0 et 1. La plausibilité est définie par :
Cet intervalle permet de mesurer le niveau de confiance de certaines propositions, mais

également la quantité d‟informations disponibles. Supposons que nous ayons trois hypothèses
A, B et C. Si aucune information n‟est disponible on associe à chacune l‟intervalle [0,1].
Noter bien que cela est différente de l‟approche bayesienne qui aurait affecté à chaque
hypothèse la valeur 0.33.
FIG. 3.6 – La possibilité d‟avoir FB connaissant FA

Contrairement à la théorie des probabilités, qui affecte à l‟absence d‟une hypothèse H la
valeur : 1 − P (H), la théorie de Dempster-Shafer n‟oblige pas que la croyance en une
hypothèse soit assignée à l‟ignorance d‟une autre hypothèse. Elle demande que l‟assignation
soit effectuée uniquement au niveau des sous-ensembles de l‟environnement.
Exemple : Supposons que nous avons l‟environnement V = {A, B, C} ou A correspond à un
avion de ligne, B est un avion de bombardement et C est un avion de chasse. Un ingénieur
transmet un signal à un avion. Si c‟est un avion ami, ce dernier envoie son code
d‟identification, sinon, s‟il ne transmet rien il est considéré comme avion ennemi.
Supposons que l‟avion ne pouvant envoyer un signal de réponse indique un degré de
confiance de 0.7. L‟assignation de la confiance se fait alors sur le sous ensemble {B, C} de V:
m1({B, C }) = 0.7 m1 étant l‟observation d‟un seul capteur. Le reste de la confiance se trouve
au niveau de l‟environnement : m1(V) = 0.3 et non pas au niveau de l‟avion ami comme le
proposait la théorie des probabilités. Nous appelons cette nouvelle mesure la masse pour faire
la différence avec la probabilité.
Mathématiquement parlant, pour un environnement donné V la masse est une fonction :
m : P (V ) → [0, 1]
26
FIG. 3.7 – La possibilité d‟avoir le complément de FB connaissant FA

Dempster a proposé une formule de combinaison de différentes masses pour produire
une masse résultante représentant un certain consensus. Ce résultat tend à favoriser
l‟acceptation en incluant les masses se retrouvant dans les intersections :
Par exemple, si on suppose qu‟on dispose d‟un autre capteur pour la détection des
avions avec : m2 ({B}) = 0.9 et m2 (V ) = 0.1 nous avons :
mesure trouvée pour l‟avion bombardier ;
mesure trouvée l‟avion bombardier ou chasseur ;
mesure trouvée pour la totalité de l‟environnement.
A partir de ces trois résultats, nous pouvons donner l‟intervalle de confiance suivant :
[0.9, 1] à l‟élément B car la somme des confiances des trois sous ensembles est égale à 1 et les
trois sous ensembles incluent B.
D‟une manière générale la borne inférieure de l‟intervalle de confiance liée à un sous-
ensemble donné est calculée par
Par exemple la confiance affectée au sous ensemble.
27
FIG. 3.8 – Règle de type FUZZY-FUZZY : SI B Alors C, A étant un fait flou défini sur le même
domaine que B. C‟ serait le résultat de l‟activation de cette règle par A
De même la plausibilité associée à un sous ensemble donnée est :
X 0 étant le complément de X . Par exemple, pl({B, C }) = 1 − conf ({A} = 1 − m0 ({A}) = 1.
Par conséquent, l‟intervalle de confiance associée à {B, C } est I ({B, C }) = [0.97, 1].
Nous pouvons voir la plausibilité en X comme étant le degré avec lequel l‟évidence ne parvient
pas à réfuter X. Ainsi, nous définissons l’ignorance de X par igr(X ) = pl(X ) − conf (X ),
et le doute de X par : dbt(X ) = conf (X 0 ) = 1 − pl(X ).
Normalisation de la confiance
Supposons dans l‟exemple suivant, que nous ayons un troisième capteur avec les masses
suivantes : m3 ({A}) = 0.95 et m3 (V ) = 0.05. La combinaison des trois évidences nous donne
les résultats suivants :
m1 + m2 + m3 ({A}) = 0.0285
m1 + m2 + m3 ({B}) = 0.045
m1 + m2 + m3 ({B, C }) = 0.0015
m1 + m2 + m3 ({V }) = 0.0015
m1 + m2 + m3 ({φ}) = 0
Nous remarquons que la somme de toutes les masses est inférieure à 1. Pour résoudre ce
problème nous divisons chaque combinaison élémentaire par 1 – k. Avec :
Dans l‟exemple k = 0.855 + 0.0665 = 0.9215 ; et les nouveaux résultats sont :
28
m1 + m2 + m3 ({A}) = 0.363
m1 + m2 + m3 ({B}) = 0.573
m1 + m2 + m3 ({B, C }) = 0.045
m1 + m2 + m3 ({V }) = 0.019
Par conséquence, la confiance associée à {B} est conf ({B}) = 0.573 ; la plausibilité est
pl({B}) = 1 − conf ({A, C }) avec :
conf ({A, C }) = m1 + m2 + m3 ({A, C }) + m1 + m2 + m3 ({A}) + m1 + m2 +m3 ({C })
= 0 + 0.363 + 0 = 0.363
Et donc, l‟intervalle de confiance associé à B est I ({B}) = [0.573, 0.637].
Retenons bien que la formule générale de la règle de Dempster de combinaison est :
29
Chapitre 4. Représentation de connaissances

4.1. Les langages de représentation de connaissances
Quand on conçoit un système à base de connaissances, la première mission est de
déterminer les objets du domaine réel - porteurs de connaissances - et les relations entre ces
objets, et de les représenter en utilisant un langage formel.
Ce langage doit aussi supporter les inférences effectuées sur ces objets. Le résultat de
l‟inférence doit correspondre à une action ou à une observation sur le domaine.
Plusieurs questions liées au domaine, doivent se poser lors du choix d‟un langage de
représentation, par exemple : est-ce que le langage doit représenter des classes, de hiérarchie
entre classes, d‟exception, des relations de type cause - conséquence, de l‟incertitude, etc.
Il est nécessaire de distinguer entre les schémas de représentation et le moyen de
l‟implémentation. Les langages de programmation servent de moyens d‟implémentation. En
général, les schémas de représentation de connaissances sont plus spécifiques que le calcul
des prédicats ou des langages comme Prolog ou Clips. Prolog et Clips restent les langages de
programmation les plus adaptés pour l‟implémentation de ces schémas, mais il est toujours
possible d‟utiliser des langages plus conventionnels comme C, Java, C# etc.
Dans la littérature, plusieurs schémas de représentation de connaissances ont été
proposés et implémentés. Nous pouvons les classer en quatre catégories :
Les schémas de représentations logiques
La logique est utilisée pour représenter la base de connaissances. Les règles d‟inférence
appliquent cette connaissance aux éléments du problème. La logique du premier ordre (le
calcul des prédicats) est un exemple de cette catégorie. Prolog est un langage idéal pour
l‟implémentation de ces représentations.
Les schémas de représentations procédurales
Les connaissances sont représentées par un ensemble d‟instructions pour la résolution
d‟un problème. Par exemple dans les systèmes à base de connaissances chaque règle de la
forme si .. alors est une procédure qui permet de résoudre un sous but du problème.
Les schémas de représentations en réseaux sémantiques
Les réseaux sémantiques représentent les connaissances comme étant un graphe. Les
nœuds correspondent aux objets (concepts dans le domaine). Les arcs représentent les
relations ou les associations. On parle des réseaux sémantiques et de graphes conceptuels.
Les schémas de représentations en objets structurés
Ces schémas de représentation peuvent être considérés comme une extension des
réseaux sémantiques, en admettant que le nœud peut correspondre à une structure complexe
qui représente un objet encapsulant des attributs, des valeurs et encore des procédures pour
effectuer des tâches données. On parlera des Scripts, des Frames et des objets.
30
4.2. Aspects de la représentation de connaissances

Plusieurs questions doivent se poser par rapport à la représentation des connaissances
pour un domaine spécifique.
Que représenter exactement ?
Une fois les objets du monde sont déterminés, la vraie question est qu‟est ce qu‟il faut
représenter. Quelle relation doit-on mettre en avant ? Par exemple, en calcul de
prédicats on peut dire que la voiture est rouge : couleur(voiture, rouge). Mais comment
pourrait on dire que la voiture de X est plus rouge que celle de Y.
A quel niveau de granularité ? Par exemple, en calcul de prédicats et en réseaux
sémantiques, les objets sont représentés par des simples symboles. Par contre, La
représentation par objets structurés nous permet de définir des objets complexes en
encapsulant des attributs pour désigner un seul objet.
Comment peut-on faire la différence entre extension et intention ?
L‟extension d‟un concept est définie par l‟ensemble d‟objets. L‟intention signifie la
définition des structures décrivant un concept donné. Par exemple, le concept étudiant à
l‟UM est défini par extension par l‟ensemble Coco, Godé, Espoir, etc.. Ce même
concept peut être défini par intention par : Etudiant qui est inscrit en deuxième licence
génie informatique à l‟UM etc.. En fait, un système à base de connaissances contient
une représentation par intention tandis qu‟une base de données contient une
représentation par extension. Ces deux représentations doivent être liées en modélisant
la correspondance entre données dans la base de données et schémas de représentation
par intention dans la base de connaissances.
Comment représenter la méta-connaissance ?
La méta-connaissance correspond à la connaissance ayant comme objectif de traiter les
schémas de connaissances sur le domaine. Puisque les données traitées sont des
connaissances, on appelle ce type de connaissances méta-connaissance.
Comment organiser les connaissances en hiérarchie ?
Les représentations par objets structurés constituent un exemple de la hiérarchisation
des connaissances (voir plus loin).
4.3. Les réseaux sémantiques

4.3.1. Limitations de la représentation logique par rapport à l’expression
des humains
L‟utilisation de la logique pour formaliser le raisonnement humain qui s‟exprime en
utilisant un langage donné pose certains problèmes. Prenons par exemple la phrase « Si X est
un oiseau alors X est capable de voler ». En calcul de prédicat cette phrase est traduite par :
(oiseau(X ) → peutvoler(X ))
qui est logiquement équivalent à
31
(¬peutvoler(X )) → ¬oiseau(X ))
A partir de cela, supposons que X est le chat Félix, Félix ne peut pas voler et Félix n‟est
pas un oiseau ; donc la valeur de vérité de la deuxième formule est vraie. Par conséquent, on
en déduit que le fait que félix est un chat qui ne peut pas voler constitue une modèle pour
l‟hypothèse : tous les oiseaux volent ! !
De plus, le calcul des prédicats nous permet de formaliser des expressions qui n‟ont
aucun sens mais qui soient vrais quand même ! ! comme l‟expression :
(2 + 3 = 8) → couleur(ciel, vert)
Cette expression est vraie car 0 → 0 est vraie.
4.3.2. Théorie d’associations

La théorie d‟associations définit un sens d‟un objet en terme de réseau d‟association
avec d‟autres objets de la base de connaissances.
La figure 4.1 montre comment créer des associations entre les objets. En 1969, Collins
et Quillian ont modélisé le stockage et le traitement de l‟information chez l‟humain avec un
réseau sémantique. Ils ont mis en place plusieurs types d‟associations :
– les associations décrivant les caractéristiques ou les propriétés de l‟objet ou du concept.
Ces associations sont libellées avec : est, a
– les associations décrivant les actions que peut entamer l‟objet. Ces associations sont
libellées avec : peut,..
– Les associations décrivant l‟héritage libellées par est un.
– Les associations décrivant les exceptions libellées par n‟est pas, n‟a pas, ne peut pas.
L‟organisation de ce réseau a été inspirée des expériences psychologiques menées sur
les humains.
Par exemple, Collins et Quillian ont constaté que le temps de réaction à la question est
ce que le canary peut voler ? est plus long que celui de la question est ce que le canary peut
chanter ? L‟explication qu‟ils ont fournie est que : l‟information est toujours stockée dans le
niveau le plus abstrait. Citons un autre exemple concernant les expériences, le temps de
réaction qui correspond à la question est ce que l‟autruche respire ? est plus long que celui de
la question est ce que l‟autruche vole ? Une explication possible serait que les exceptions sont
toujours stockées dans le niveau le plus spécifique.
Le fait d‟utiliser l‟héritage présente plusieurs avantages :
32
F IG . 4.1 – Théorie d‟association : exemple

– réduction de la taille de la base de connaissances en " factorisant " les connaissances
communes.
– Maintenance et consistance de la base de connaissances surtout quand on ajoute des
nouvelles concepts ou objets.
4.3.3 Besoin de standardisation
Malgré le fait que les réseaux sémantiques sont plus riches en notions (l‟héritage, les
associations, les exceptions, etc.) que le calcul logique, il n‟est pas évident qu‟ils puissent
supporter la complexité de n‟importe quel domaine. La plus part des travaux qui ont suivi
ceux de Quillian ont focalisé sur la définition d‟un ensemble plus riche. L‟utilisation d‟un
formalisme inspiré par le langage naturel dans la mise en œuvre d‟un réseau sémantique a été
beaucoup utilisée et amenée à la réalisation de bases de connaissances plus générales et plus
consistantes qu‟avant. En 1973, Simmons a souligné l‟intérêt de la mise en œuvre des
relations standardisées en définissant une structure de cas des verbes en anglais. La structure
d‟un cas inclut des agents, des objets, des instruments, des lieux et du temps.
Il y a eu des travaux encore plus ambitieux et complexes comme le travail de Schank
sur la théorie de dépendances conceptuelles. Cette théorie est fondée sur quatre primitives de
conceptualisation : les actions symbolisées, les objets, les modificateurs d‟action et les
modificateurs d‟objets.
Les actions symbolisées par ACTs peuvent être de plusieurs types selon leurs
significations sémantiques, nous citons quelques exemples :
ATRANS transformer une relation ;
PTRANS transformer un lieu physique d‟un objet ;
PROPEL appliquer une force physique à un objet.
Les modifications apportées aux relations sont libellées par : passé(p), futur(f) et
conditionnelles (c) et ceci dans le but de leur associer un temps d‟action.
4.4. Les graphes conceptuels

Nous détaillons dans cette section, un cas particulier des réseaux sémantiques : les
33
graphes conceptuels. Les nœuds d‟un graphe représentent des concepts ou des relations entre
concepts. Les graphes conceptuels n‟utilisent pas des arcs libellés mais des nœuds
représentant les relations entre concepts. Par exemple dans la figure 4.2, les concepts chien et
noir sont représentés par des nœuds concepts et la couleur est représentée par un nœud
relation. Les concepts sont représentés par des rectangles et les relations par des ellipses. Les
nœuds concepts représentent des objets concrets comme voiture, télé- phone ou des objets
abstraits comme beauté. Les nœuds de relation indiquent une relation concernant un ou
plusieurs concepts. Une relation d‟arité n est représentée par un nœud de relations ayant n
arcs.
FIG. 4.2 – Les graphes conceptuels
4.5 Types, individus et noms

Dans un graphe conceptuel, chaque rectangle est libellé par un type qui indique le type
(ou la classe) d‟individus représentés par ce nœud. Les types sont organisés en hiérarchie. Par
exemple, le type chien est un sous type du type carnivore. Chaque rectangle est libellé par le
type de l‟individu et son nom (ou son identificateur) séparés par un : (voir figure 4.2). Chaque
individu possède un identificateur unique précédé par le symbole #. La différence entre les
identificateurs et les noms est que deux individus différents du même type peuvent avoir le
même nom mais jamais le même identificateur. D‟un autre côté, dans un graphe conceptuel
nous pouvons utiliser le symbole générique *, pour indiquer un concept générique. Par
convention, un nœud contenant le type chien est équivalent au nœud contenant chien :*X qui
indique le concept générique du chien sans indiquer un individu donné. Pour résumer, un
nœud concept peut contenir un concept individuel ou un concept générique.
4.5.1. Hiérarchie de types

La hiérarchie de types est un ordre partiel défini sur les types. Supposons que S et T
sont deux types. La relation T ≤ S indique que T est un sous-type de S et que S est un super-
type de T. Supposons que S, T et U sont trois types. Si T ≤ S et T ≤ U, alors T est un sous-
type commun de S et U. De même, si S ≤ V et U ≤ V, alors V est un super-type commun de

S et U. La hiérarchie de type forme un treillis.
Les types peuvent avoir plusieurs parents et plusieurs enfants. Chaque pair de types ont
un super-type commun minimal et un sous-type commun maximal. Dans le treillis, > indique
le type universel qui est supérieur à tous les types. Et ⊥ indique le sous type de tous les types.
4.5.2. Généralisation et spécialisation

La théorie des graphes conceptuels nous permet de former des nouveaux graphes à
partir des graphes existants, et ceci en généralisant ou spécialisant certains graphes. Quatre
opérations sont utilisées pour cette fin.
34
Copy : nous permet de créer un nouveau graphe g qui est la copie exacte de g1.
Join : nous permet de combiner deux graphes dans un seul graphe. S‟il existe un nœud
concept c1 dans S1 qui est identique à un nœud concept c2 dans S2 . Un nouveau graphe est
formé en supprimant c2 de S2 et en liant toutes les relations incidentes de c2 avec c1 .
Restrict : Le but de la restriction est d‟effectuer un changement sur un ou plusieurs nœud(s)
concept(s) pour pouvoir effectuer une opération de join ultérieurement. Par exemple, un
concept générique dans un graphe peut être remplacé par un concept spécifique du même
type. De même, la hiérarchie de type peut être utilisée pour nous permettre de remplacer un
type par un sous-type. Autrement dit, pour effectuer la restriction, nous utilisons deux types
d‟héritage :
– l‟héritage des propriétés des individus et ceci en spécialisant un concept généralisé
pour un type donné.
– l‟héritage des propriétés des sous-types et ceci en utilisant la hiérarchie de types.
Simplify : nous permet de supprimer une relation dans un graphe conceptuel dans le cas où
cette relation est dupliquée. La duplication d‟une relation dans un graphe est souvent le
résultat de l‟application de l‟opération join sur deux graphes.
Notons que Ces règles ne constituent en aucun cas des règles d‟inférence. Ils ne garantissent
en aucun cas que l‟obtention des graphes dérivés qui seront vrais. Par contre le maintien du sens
est garanti.
4.5.3. Nœuds propositionnels

Nous avons vu que nous pouvons utiliser les graphes pour définir les relations entre les
objets du monde. Nous pouvons aussi définir les relations entre les propositions. Exemple,
Thomas croit que Marie aime les pizzas. Les graphes conceptuels incluent un concept type qui
est le concept proposition qui définit des relations propositionnelles sur un ensemble de
graphes conceptuels (voir figure 4.3).
4.6. Graphes conceptuels et logique

En utilisant les graphes conceptuels, nous pouvons facilement représenter la conjonction
entre concepts. Exemple : le chien est grand et a faim. Mais nous n‟avons pas jusqu‟au là
établi une moyenne pour exprimer les relations de disjonction et de négation. Nous pouvons
implémenter une relation neg qui est une opération unaire agissant sur une proposition. En
utilisant donc, des négations et des conjonctions nous pouvons implémenter des disjonctions.
Par convention, les concepts génériques correspondent à des quantificateurs existentiels. Par
exemple, le graphe 4.2 (en éliminant la spécification toto) correspond à la formule :
∃X ∃Y (chien(X ) ∧ coleur(X, Y ) ∧ noir(Y ))
Il existe un algorithme nous permettant d‟extraire la formule en logique de prédicats

correspondante à un graphe conceptuel :
1. Attribuer à chaque concept générique une variable unique.
2. Attribuer une constante unique à chaque concept individuel. Cette constante peut être
le nom ou l‟identificateur.
3. Représenter chaque concept par un prédicat unaire ayant comme nom le type du nœud et
35
comme arguments les variables ou les constantes attribuées à ce nœud.

4. Représenter chaque relation entre concepts d‟arité n par un prédicat d‟arité n, qui a
également le même nom. Un argument du prédicat doit correspondre à la variable ou la
constante attribuée au concept lié à cette relation.
5. Prendre la conjonction des expressions atomiques obtenues. Les variables seront
quantifiées par des quantificateurs existentiels.
F IG . 4.3 – Les nœuds propositionnels
F IG . 4.4 – Les nœuds propositionnels : la négation

Par exemple le graphe conceptuel donné par la figure 4.2 donne lieu à l‟expression
logique :
∃X 1(dog(toto) ∧ color(toto, X 1) ∧ noir(X 1))
4.7. Les objets structurés

Dans les réseaux sémantiques, ou les graphes conceptuels, le niveau de granularité de la
connaissance est limité au nœud concept. Les objets structurés nous permettent, en fait de
représenter plus finement la connaissance
4.8. Les frames ou les schémas

La connaissance est représentée par des objets structurés contenant des fentes (slot).
Chaque fente est représentée par son nom et sa valeur. Chaque schéma individuel peut être vu
36
comme une structure de données (enregistrement en C). Les fentes peuvent contenir plusieurs
types d‟information :
1. l‟identification du schéma ;
2. les descripteurs du schéma ;
3. la relation avec les autres schémas par exemple le téléphone d‟hôtel est une
spécialisation du schéma téléphone ;
4. Les informations procédurales attachées à certaines fentes ;
5. Les informations par défauts représentées par des valeurs attribuées aux fentes par
exemple le nombre de pieds d‟une chaise est égale à 4 ;
Quand une instance d‟un schéma est créée, le système attribue des valeurs aux fentes (slot) en
utilisant les valeurs par défauts, en exécutant des procédures attachées, ou bien en demandant
à l‟utilisateur les informations complémentaires. Les schémas peuvent être vus comme des
réseaux sémantiques évolués. Ils permettent une organisation hiérarchique de la connaissance
plus élaborée qu‟en réseaux sémantiques. Les attachements procéduraux permettent de décrire
une certaine partie de la connaissance par des étapes d‟exécution.
37
Deuxième partie : Les systèmes experts et

le Temps réel
I. Informatique temps réel
Dans le processus de choix de moyens conduisant à l‟informatisation, il existe trois
types de solutions informatiques :
- Le traitement en temps réel,
- Le traitement en temps différé
- Le traitement en temps partagé.
Un traitement est dit en temps différé, lorsqu‟il y a un décalage entre la saisie des
informations et l‟obtention des résultats. En d‟autres termes, il y a désynchronisation dans le
temps entre les quatre opérations : saisie des données, transmission, traitement et restitution
des résultats.
Un traitement est dit en temps partagé lorsque plusieurs utilisateurs accèdent à un
ordinateur central d‟une manière simultanée. Chacun des utilisateurs pouvant travailler sur ses
propres programmes.
Un traitement est dit en temps réel, lorsque l‟événement qui a fourni l‟information
n‟étant pas encore terminé, il y a un feed back (une réponse). En d‟autres termes, il n‟y a pas
de décalage de temps entre les quatre opérations : saisie des données, transmission, traitement
et restitution des résultats.
Les systèmes temps réel ont depuis toujours occupé une importante place dans le
développement des systèmes informatiques. Ils recouvrent un spectre d‟applications très
étendues qui va du simple contrôle des systèmes de commande au contrôle du trafic aérien,
aux télécommunications, en passant par les systèmes de défense militaire, installations
nucléaires et bien d‟autres.
Les systèmes temps réel sont des systèmes de traitement dont la validité est
conditionnée non seulement par la correction des résultats, mais surtout par les dates
auxquelles ceux-ci sont produits. En effet, ces systèmes sont essentiellement caractérisés par
des contraintes de temps sur les actions à entreprendre, qu‟il faut respecter de manière plus ou
moins critique.
I.1. Définitions des systèmes de contrôle-commande

Un système de contrôle-commande est un système informatique en relation avec
l‟environnement physique réel externe par l‟intermédiaire de capteurs et/ou actionneurs,
contrairement aux systèmes informatiques scientifiques (gestion de base de données, CAO,
etc.) qui ont des entrées constituées de données fournies par des fichiers ou éventuellement un
opérateur.
Ainsi une définition générale d‟un système de contrôle-commande est donnée ci-
dessous (voir la figure ci-dessous) : «Un système de contrôle-commande reçoit des
informations sur l‟état du procédé externe, traite ces données et, en fonction du résultat,
38
évalue une décision qui agit sur cet environnement extérieur afin d‟assurer un état stable».
Il est important de noter que la notion de l‟état stable peut être différente selon les
applications ou procédés (il dépend du cahier des charges de l‟application, par exemple
maintien d‟une température de consigne, régime moteur, qualité de service…).
Un procédé est une entité physique dont on peut connaître l‟état par le biais de capteurs
et qu‟on peut commander par le biais d‟actionneurs. Un système de contrôle commande est le
« cerveau » du procédé. Son rôle est de recevoir des informations en provenance de
l‟environnement à l‟aide des capteurs, et de commander des changements d‟état du procédé
via des actionneurs.
Figure I.1. Interaction entre le procédé et le contrôleur

L‟interaction du système de contrôle-commande avec le procédé extérieur à piloter se
décompose en deux parties:
- observations par l‟intermédiaire de capteurs (sensors) qui permettent d‟obtenir des
informations sous la forme d‟«interruptions» (information tout ou rien), ou des «mesures»
(information continue) en provenance du procédé physique,
- actions réalisées par l‟intermédiaire d‟actionneurs (actuators) qui permettent d‟agir sur le
procédé physique sous la forme de «commandes» (modification d‟état physique du système),
ou simplement sous la forme d‟un «affichage» (diodes, afficheurs, écrans, etc.).
En qualifiant des systèmes de contrôle-commande avec des spécifications
particulières, on peut classifier les systèmes de contrôle-commande en différentes catégories :
- Le système temps réel ou réactifs : C‟est un système de contrôle-commande dans lequel
l‟exactitude des applications ne dépend pas seulement du résultat mais aussi du temps
auquel ce résultat est produit. Si les contraintes temporelles de l‟application ne sont pas
respectées, on parle de défaillance du système. Ces contraintes temporelles peuvent être de
deux types :
 Contraintes temporelles strictes ou dures : dans cette catégorie, le système se
compose de tâches à contraintes strictes. Chaque occurrence de ces tâches est associée à
une échéance que le système doit impérativement respecter. Une faute temporelle peut
avoir des conséquences catastrophiques (humaines, matérielles…),
 Contraintes temporelles relatives ou lâches : dans cette catégorie, le système se
compose de tâches ayant des échéances, comme dans le cas des systèmes à contraintes
strictes. Cependant, une violation d‟une contrainte temporelle est tolérable et a un
impact sur la qualité de service que l‟on cherche à minimiser.
- Le système de contrôle-commande embarqué (embedded real-time system): C‟est un
39
système, piloté par un logiciel, et qui est complètement intégré au système qu‟il contrôle
(donc, pas de l‟intervention humaine directe, pas de modification du programme ou des
paramètres du programme).
- Le système de contrôle-commande dédié (dedicated real-time system): c‟est un système
dont les architectures matérielles ou logicielles sont spécifiques à l‟application (noyau,
processeur, etc.).
- Le système de contrôle-commande distribué ou réparti (distributed real-time system):
c‟est un système dont l‟architecture matérielle est constituée de plusieurs processeurs reliés
entre eux par un bus ou un réseau.
Il est évident que ces différentes spécifications d‟un système de contrôle-commande
peuvent se combiner comme par exemple un système de contrôle-commande dédié, distribué
et à contraintes temporelles strictes (application pour un véhicule automobile).
I.2. Systèmes temps réels et systèmes experts

Le comportement d‟un système informatique est qualifié de « temps réel » s‟il est
assujetti à l‟évolution d‟un procédé qui lui est connecté et qu‟il doit piloter ou suivre en
réagissant à tous ses changements d‟états, tout en respectant les contraintes de temps
(temps de réponse à un stimuli, taux de perte d‟informations toléré en entrée) qui sont
imposées à ses interfaces avec cet environnement.
Un Système Temps Réel (STR) est donc composé de :
- d‟un environnement à contrôler (procédé)
- d‟un système de contrôle qui représente le système d‟exploitation au-dessus duquel
l‟application sera exécutée (contrôleur).
- de l‟application elle-même
L‟interaction entre ces trois composants se traduit par un échange d‟informations
entre l‟application et l‟environnement, selon des contraintes temporelles imposées par ce
dernier. Le système d‟exploitation permet de contrôler cette interaction.
Il existe un intérêt grandissant à l'heure actuelle pour les systèmes experts dits
«temps réel». A cela, on peut voir deux raisons :
- Tout d'abord un Système Expert est capable, dans des cas où il n'existe pas de solution
algorithmique satisfaisante, de résoudre un problème en un temps réaliste
(polynomial), notamment à l'aide d'heuristiques appropriées.
- Ensuite, les applications temps réel peuvent bénéficier de certaines caractéristiques des
Systèmes Experts, particulièrement intéressantes vis-à-vis des contraintes de temps,
comme la possibilité de faire progresser le travail déjà effectué sans le remettre en
cause dans sa globalité ou la capacité à estimer le sous-espace de recherche le plus
prometteur en fonction de l'état du système. Cependant, l'intégration d'un Système
Expert dans une application temps réel soulève bon nombre de difficultés.
Globalement, le Système Expert doit satisfaire trois exigences principales:
1) L'intégration dans l'environnement extérieur, c'est-à-dire avec les autres composants
40
logiciels de l'application temps réel;

2) Le fonctionnement en temps réel, qui recouvre des concepts comme le
fonctionnement en continu, la prise en compte de données asynchrones, la focalisation
d'attention, l'activation, etc...;
3) La prise en compte du temps dans le raisonnement, afin que le Système Expert puisse
déterminer la position relative d'événements dans le temps. Tous ces aspects doivent
être développés.
Remarque :
1. Du point de vue opérationnel, une application TR peut être décrite comme un
ensemble de tâches communicantes qui peuvent partager des ressources critiques.
Chaque tâche est généralement dédié à toute (ou à une partie d‟) une chaîne
d‟acquisitions, calcul/décision, commande. Chaque chaîne peut aussi avoir des
intersections et un rythme propre pouvant être périodique ou non.
2. Les contraintes sur les STR portent sur les tâches qui les composent. Généralement
une tâche temps réel est décrite par trois paramètres : une durée d‟exécution de la
tâche, la date au plus tôt à partir de laquelle la tâche peut être déclenchée et une
échéance (délai) à ne pas dépasser.
I.3. Typologie des systèmes temps réels

Il existe deux sortes de systèmes temps réels :
- Les STR statiques : ce sont des STR pour lesquels la séquence d‟exécution des tâches est
déterminé à l‟avance, c'est-à-dire les paramètres des tâches (temps d‟exécution,
ressources utilisées, communications, etc.) sont connus à priori. On qualifie ces systèmes
de rigide et de coûteux.
- Les STR dynamiques : Ce sont des STR qui permettent d‟ajuster et de recalculer les
paramètres durant l‟exécution. Ils permettent donc de prendre en compte de manière
efficace les imprévus qui peuvent surgir et entraînent une meilleure exploitation des
ressources. Les modèles dynamiques permettent également, dans le cas où des tâches
seront créées durant l‟exécution, de ne pas surcharger les processeurs avec toutes les
tâches, mais de créer ces tâches au fur et à mesure, ce qui implique une utilisation plus
optimale de la mémoire.
Comme exemples des STR dynamiques nous pouvons citer : les communications
multimédias, les systèmes de multi robots coopératifs ou autonomes, les bases de données
temps réels, les systèmes radars, etc.
I.4. Caractéristiques des systèmes de contrôle-commande (STR)

Les caractéristiques représentées dans cette section sont les principales
caractéristiques des systèmes de contrôle-commande. Certaines d‟entre elles peuvent être
aussi caractéristiques des autres systèmes (par exemple, systèmes transformationnels,
systèmes interactifs).
- Grande diversité des dispositifs d’entrées/sorties : les données à acquérir qui sont fournies
41
par les capteurs et les données à fournir aux actionneurs sont de types très variés
(continu, discret, tout ou rien ou analogique).
- Prise en compte des comportements concurrents : c‟est une caractéristique spécifique aux
systèmes de contrôle-commande, car l‟ensemble de ces données physiques qui arrivent
de l‟extérieur ne sont pas synchronisés au niveau de leurs évolutions.
- Respect des contraintes temporelles : c‟est une caractéristique requise pour tous les
systèmes de contrôle-commande temps réel. Par conséquent, le système informatique
possède non seulement une réactivité suffisante pour prendre en compte tous les
comportements concurrents et en réponse à ceux-ci, mais doit envoyer des commandes
en respectant des délais compatibles avec la dynamique du système.
- Sûreté de fonctionnement : la sûreté de fonctionnement est l‟évaluation du niveau de
confiance justifié qu‟on peut lui attribuer dans son bon fonctionnement. La sûreté
de fonctionnement regroupe les activités d‟évaluation de la fiabilité, de la
maintenabilité, de la disponibilité, et de la sécurité (FMDS). Les systèmes de type
contrôle-commande demandent un niveau important de sécurité pour raisons de coût
ou de vies humaines. Pour répondre à cette demande, il est nécessaire de mettre en
œuvre toutes les réponses de la sûreté de fonctionnement (développement sûrs, tests,
méthodes formelles, prévisibilité, déterminisme, continuité de service, tolérance aux
fautes, redondance, etc.).
Notons que les systèmes informatiques sont dits transformationnels lorsque les
données sont disponibles au lancement et les instants de production des résultats ne sont
pas contraints. Par exemple le calcul scientifique, la gestion des bases de données, etc. Ils
sont dits interactifs ou transactionnels ou outils bureautiques lorsque les résultats
dépendent de données produites par l‟environnement et les instants de production des
résultats respectent des valeurs statistiques.
I.5. Notion d’ordonnancement

Les STR sont conçus pour interagir avec l‟environnement extérieur en garantissant le
respect des contraintes pour que les réactions ou la capture de données arrivent à bon
escient. Le non respect de ces contraintes par les tâches, considéré comme une faute grave
du système, résulte le plus souvent de conflits survenus entre les tâches au moment de leur
exécution. Ces conflits sont de deux ordres : ils portent sur les processeurs et sur les
ressources. L‟ordonnancement est un mécanisme qui permet de résoudre ces conflits.
a) Conflits sur les processeurs : On parle de conflits sur les processeurs lorsque
plusieurs tâches réclament simultanément le processeur afin de respecter leurs contraintes.
Ces conflits peuvent être résolus par des mécanismes d’ordonnancement gérant l‟accès
au processeur. Ces mécanismes appelés ordonnanceurs, n‟ont qu‟une vision très générale
des tâches. En effet, ils ne considèrent pas les traitements qu‟elles effectuent mais utilisent
des paramètres définis à l‟avance sur les tâches tels que le temps d‟exécution, l‟échéance,
etc. L’ordonnancement des tâches sur un processeur consiste à déterminer une séquence
d‟exécutions des tâches sur le processeur qui garantisse leurs contraintes.
42
b) Conflits sur les autres ressources : On parle de conflits sur les autres ressources
lorsqu‟une tâche demande l‟accès à une ressource ou une donnée non partageable (unités
d‟entrées/sorties, fichiers, disques, etc.). Pour résoudre ces conflits, on utilise des mécanismes
de verrouillage. Toutefois, des mécanismes d‟ordonnancement de ces ressources avec des
considérations de temps doivent également être utilisés, afin d‟éviter que pour de raisons
d‟intégrité de ressources, certaines tâches tardent à y avoir accès, et voient ainsi leurs
contraintes temporelles violées.
I.6. Modélisation des systèmes temps réels

I.6.1. Les contraintes temporelles
Dans un STR, les contraintes temporelles portent sur essentiellement sur les dates de début et
de fin d‟exécution des tâches. Si nous supposons que le Système est décomposé en termes de
tâches Ti, i=1,..., n alors pour chaque tâche Ti, les contraintes temporelles sont modélisées par
les paramètres suivants :
- Ai : C‟est la date d‟arrivée de la tâche au processeur (ou date de la création de la tâche ou
éventuellement la date à laquelle une tâche transférée par un autre processeur est reçue). Il
est désormais possible d‟ordonnancer cette tâche. Ainsi, chaque fois qu‟une nouvelle tâche
arrive au processeur ou chaque fois qu‟une tâche est créée, l‟ordonnanceur (mécanisme
d‟ordonnancement), recherche un nouvel ordre qui prendra en compte la nouvelle tâche.
- Ri : C‟est la date à laquelle une tâche peut commencer son exécution. Certaines tâches sont
dépendantes les unes des autres, et ne peuvent donc commencer leurs exécutions que si les
tâches dont elles dépendent (les tâches qui les précèdent) ont terminé leurs exécutions.
Dans ce cas, elles sont liées par des relations de précédence (communication de résultat
d‟une tâche en fin d‟exécution) ou de causalité (estampillages des tâches). L’estampillage
des tâches consiste à attribuer un numéro d‟ordre aux tâches de sorte que durant
l‟exécution, cette numérotation soit respectée à travers le réseau. In convient de souligner
que souvent Ai et Ri sont confondues.
- Di : C‟est la date au plus tard à laquelle une tâche peut terminer son exécution. Elle est
aussi appelées échéance. Ce paramètre détermine énormément la performance du système.
Ainsi, on distingue les échéances strictes et les échéances relatives. Les échéances strictes
ne peuvent jamais être dépassées, sinon elles dégradent les performances du système. Les
échéances relatives peuvent être dépassées sans dégrader les performances du système.
- Ei : C‟est la durée d‟exécution de la tâche. Elle est déterminée par des simulations ou une
étude poussée du code source. Cependant, lorsque le code source est composé de boucles
ou de traitements conditionnels, il est difficile de déterminer d‟emblée Ei. Dans ce cas, on
détermine un temps d‟exécution dit « au pire des cas » qui reflète une borne supérieure Ei.
Notons que l‟on parle de pire des cas lorsqu‟on suppose que toutes les formes possibles du
code source de la tâche ont lieu c'est-à-dire le nombre d‟itérations maximum atteint pour
toutes les boucles. Dans les STR dynamiques, Ei ne peut être connue à l‟avance puisque la
tâche Ti est créée dynamiquement. Il est mis à jour au fur et à mesure de l‟exécution de la
tâche. On peut par exemple procéder à la déduction du temps restant (Erest i) à partir du
temps atteint ( Eatt i ), c'est-à-dire Ei = Eatt i + Erest i. Parmi les méthodes utilisées pour
43
approximer le temps d‟exécution d‟une tâche, nous pouvons citer : Prischner et Koza,
Kligerman et Stoyenko, Leinbaugh et yamini, etc.
- Pi : C‟est la période d‟une tâche. Une tâche est dite périodique de période Pi, lorsqu‟elle a
une occurrence toutes les Pi unités de temps.
D‟autres paramètres sont déterminés par le mécanisme d‟ordonnancement grâce aux
paramètres Ri, Ei et Di précédents. Il s‟agit :
- Si : C‟est la date à laquelle une tâche Ti accède à la ressource selon l‟algorithme
d‟ordonnancement déroulé.
- Ci : C‟est la date à laquelle une tâche Ti termine son exécution. Cette date ne correspond
pas forcément à Si + Ei. En effet, selon l‟algorithme d‟ordonnancement appliqué, une tâche
peut être interrompue ou retardée pour la prise pour la prise en compte d‟une tâche plus
urgente.
- TRi : C‟est le temps de réponse de la tâche Ti c'est-à-dire la période entre la date la plus
antérieure à laquelle une tâche peut commencer son exécution et la date postérieure à
laquelle elle termine son exécution. Il s‟exprime par la formule : TRi = Ci - Ri.
- TLi : C‟est le temps de latence d‟une tâche Ti c'est-à-dire la période pendant laquelle une
tâche peut être retardée sans que son exécution ne dépasse son échéance. Elle s‟exprime
par la formule : TLi = Di - Ri - Ei.
- Li : C‟est la laxité c'est-à-dire la date au plus tard à laquelle la tâche Ti peut commencer son
exécution. Elle s‟exprime par la formule : Li = Di - Ei. Par déduction, on obtient la formule:
TLi = Li - Ri. Le temps de latence n‟est pas constant. En effet, plus une tâche Ti est retardée
plus son temps de latence diminue.
- Ui : C‟est le taux d‟utilisation du processeur dédié à la tâche Ti. Il s‟exprime par la
formule:
. Le taux global d‟utilisation sera la somme de tous les Ui.
Pour les tâches périodiques, le taux d‟utilisation du processeur ou le pourcentage de
l‟activité du processeur dédié à la tâche Ti est donnée par :
, et la Charge processeur = taux d‟utilisation du processeur pour les tâches
périodiques est donnée par ∑ .

Lorsque U>m alors l‟application est non ordonnançable sur m processeurs.
N.B. : L‟ensemble de ces paramètres doit vérifier les contraintes suivantes :
Ai < Ri < Si < Ci - Ei < Di - Ei
Schématiquement, nous pouvons illustrés les contraintes temporelles d‟une tâche temps réel
de la manière suivante :
44
Figure I.2. : Les paramètres temporels d‟une tâche Ti
Remarque :
- Dans certains STR, l‟échéance est modélisée par une fonction à valeur dans le temps
(FVT) appelée « Time Value Fonction » (TVF). Chaque tâche Ti fournit au moment de sa
terminaison, une contribution qui est décrite par une fonction de coût Fi(t). La valeur de
cette fonction renseigne sur l‟utilité de la terminaison de la tâche à l‟instant t. F i(t) a la
valeur maximale si Ti termine avant Di, autrement la valeur de la fonction décroît vers 0,
où elle signifie qu‟une terminaison à cette date là est inacceptable. Quand la valeur de la
fonction décroit brusquement après son échéance, ceci indique une échéance stricte à ne
pas dépasser dans n‟importe quelle situation. Par contre, si la valeur de la fonction décroit
progressivement, cela indique une échéance relative qui peut éventuellement être dépassée
de peu.
- L‟ordonnancement est ramené, dans ce cas, à un problème d‟optimisation des tâches.
L‟ordonnancement est déterminé par une série d‟évaluations des valeurs des FVT selon la
position des tâches dans la séquence d‟ordonnancement.
I.6.2. Les caractéristiques des tâches

Une tâche est une entité élémentaire d‟exécution et de structuration de l‟application. Une
tâche est localisée dans le temps par une date de début et/ou une date de fin, dont la réalisation
nécessite une durée et une échéance (la date à laquelle la tâche doit avoir terminé son
exécution).
L‟ordonnancement des tâches consiste à déterminer une séquence d‟exécution des tâches sur
le processeur en respectant les contraintes de temps. Cependant certaines caractéristiques des
tâches que nous évoquons ci-après peuvent influencées cet ordonnancement. Il s‟agit de la
priorité utilisateur et la périodicité des tâches.
a) Notion de priorité utilisateur
Lorsque toutes les tâches n‟ont pas la même importance vis-à-vis de système, on parle alors
de priorité attribuée par l‟ordonnanceur pour distinguer les tâches entre elles en fonction de
45
leurs échéances. On distingue ainsi des tâches plus prioritaires par rapport aux tâches moins
prioritaires. C‟est l‟utilisateur qui définir les priorités.
Selon le système Spring, il existe trois types de tâches selon leurs priorités :
- Les tâches temps réel critiques : ce sont des tâches dont les échéances ou les contraintes
temporelles (qui sont connues à l‟avance) doivent être rigoureusement respectées pour
éviter la catastrophe. Elles ont la priorité la plus haute dans le système.
- Les tâches temps réel essentiel : Ce sont des tâches dont les contraintes son non sévères et
peuvent éventuellement être relâchées dans la mesure du possible. Dans certaines
applications, leur échéance est composée d‟une échéance stricte et d‟une échéance
relative. La première partie de l‟exécution d‟une telle tâche doit être rigoureusement
respectée, la seconde (qui peut consister en un affinement du résultat délivré par la
première partie) peut ne pas être terminée. Dans ce cas, le résultat ne sera pas très précis.
Les tâches essentielles peuvent être ordonnancées dynamiquement.
- Les tâches non essentielles : Ce sont des tâches qui peuvent ne pas avoir des contraintes
quant à la fin de leur exécution ou la date de leur déclenchement, elles ont donc la priorité
minimale. Elles seront exécutées une fois que toutes les tâches à contraintes seront servies et
selon leur ordre d‟arrivée ou selon un ordre décidé par l‟utilisateur.
b) Notion de périodicité
Lorsque les tâches temps réel n‟ont pas de priorité utilisateur, leurs priorités seront définies
par leurs échéances. Toutefois, la notion de périodicité que nous introduisons dans cette
section, révèle une autre distinction entre les tâches. Outre les priorités des tâches, le
mécanisme doit prendre en compte le fait que ces tâches peuvent être périodiques
apériodiques ou sporadiques.
- Les tâches périodiques : une tâche
i
Ti est dite périodique de période Pi si elle est exécutée
chaque Pi unités de temps. Une telle tâche a ses paramètres Ri et Di connus. Si Tin, la nème
exécution de la tâche Ti, alors la date au plus tôt Rin est donnée par le taux d‟inter-arrivée et
la date au plus tard Din est déterminée par l‟occurrence de la (n+1)ème exécution de T
(comme illustré dans la figure suivante).
Quand un système doit ordonnancer une tâche périodique, il doit garantir toutes les futures
occurrences de la tâche.
Figure I.3. : Tâches périodiques

N.B. Si : représente la date à laquelle une tâche accède à la ressource selon
l‟ordonnancement.
Une occurrence de tâche peut avoir son échéance inférieure ou égale à sa période. Cela
46
dépend du système.
- Les tâches apériodiques : ce sont des tâches dont l‟arrivée au processeur suit une loi
aléatoire (la loi de Poisson par exemple). Leurs paramètres temporelles sont donc inconnus
à l‟avance.
- Les tâches sporadiques : Les tâches apériodiques sont caractérisées par la moyenne des
temps d‟arrivée et un standard de déviation (écart type) par rapport au taux d‟arrivée.
Cependant, si les occurrences d‟une tâche apériodique sont au moins espacées de q unités
de temps, on caractérise cette tâche de tâche sporadique de période q.
Schématiquement :
Figure I.4 : Tâches périodiques, apériodiques et sporadiques

- Une tâche non préemptible ne peut être interrompues qu‟à des endroits spécifiques et à
la demande des la tâche elle-même, par exemple fin_de_tâche, attente_signal…
- Une tâche préemptible peut être interrompue à n‟importe quel instant et le processeur
affecté à une autre tâche.
- Les tâches indépendantes : ce sont des tâches qui ne sont définies que par leurs
paramètres temporels, on dit alors qu‟elles. En effet, certaines tâches doivent communiquer
avec les autres tâches, ou doivent être connectées vers l‟extérieur pour les entrées/sorties.
Par conséquent, elles peuvent être liées par un des types des relations suivant:
- Synchronisation : se traduit par une relation de précédence d‟exécution entre les tâches,
- Communication : se traduit par une relation de précédence comme la synchronisation
mais avec l‟échange de données entre les tâches,
- Partage de ressources : les ressources sont les moyens techniques nécessaires à
l‟exécution des tâches. Au niveau d‟un système, les tâches utilisent des ressources mises en
commun comme des zones de mémoire, des cartes d‟entrées/sorties, etc. Certaines des
ressources n‟autorisent que des accès en exclusion mutuelle, c‟est-à-dire pas plus d‟une
tâche peut y accéder à la fois, pour avoir un fonctionnement correct. Elles sont appelées
ressources critiques.
Remarques
- Les algorithmes d‟ordonnancement sont extrêmement dépendants du modèle de tâches.
Ainsi ils sont plus conçus pour des tâches périodiques ou apériodiques et les tâches
sporadiques sont converties en tâches périodiques.
- Les applications temps réel sont en majorité composées de tâches périodiques.
- Les sources de contraintes de temps sont souvent : le processus physique (lois de
47
commande), la qualité de service (qualité audio/vidéo), le choix d‟architecture, le choix de

conception, etc.
I.7. Exécutif ou noyau temps réel

Un noyau de système d‟exploitation (kernel) est la partie fondamentale de certains systèmes
d‟exploitation. Le rôle du noyau est de gérer les ressources matérielles et permet aux
différents composants, matériels et logiciels, de communiquer entre eux. Un noyau fournit des
mécanismes d‟abstraction du matériel («Gestion du matériel»), notamment de la mémoire
(«Gestionnaire de mémoire»), du (ou des) processeur(s) («Ordonnanceur»), et des échanges
d‟informations entre logiciels et périphériques matériels. Il autorise aussi diverses abstractions
logicielles et facilite la communication entre les processus.
- Ordonnanceur d‟un système d‟exploitation: n‟a de sens qu‟en système multitâche. Il gère
l‟ordre dans lequel les instructions des différentes tâches sont exécutées, est assisté par le
dispatcher qui est responsable de la sauvegarde et de la restauration du contexte des tâches
(commutation de contexte).
- Gestionnaire de mémoire: alloue de la mémoire à des processus lorsqu‟ils en ont besoin. Si
un processus tente d‟utiliser des zones de mémoire ne lui appartenant pas, il peut être
évincé automatiquement, c‟est-à-dire que le noyau lui-même peut prendre la décision de
suspendre ou détruire immédiatement le processus fautif.
- Gestion du matériel: se fait par l‟intermédiaire de pilotes de périphériques, qui sont
généralement inclus dans l‟espace noyau et communiquent avec l‟espace utilisateur via les
appels système (des fonctions fournies par le noyau, et utilisées par les programmes
s‟exécutant dans l‟espace utilisateur).
Exécutif ou noyau temps réel sont souvent assimilés, dans le sens où l‟exécutif est souvent vu
comme un noyau possédant des pilotes de périphériques ou des services supplémentaires (pile
réseau,…) par rapport à un noyau. Un noyau est généralement léger, et on parle d‟empreinte
mémoire d‟un noyau (occupation mémoire) pour caractériser son encombrement. Les noyaux
temps réel fournissent au moins deux types de modules, l‟un spécifique pour le temps réel
(gestion des tâches, communication, synchronisation, gestion du temps) et l‟autre plus
classique (librairies standard). Les applications temps réel font alors appel à la partie temps
réel du noyau.
Contrairement au système d‟exploitation classique (politiques d‟ordonnancement des activités
basées sur le partage équitable du processeur; gestion de temporisateurs ou de l‟horloge pas
assez fine; la concurrence de l‟application temps réel avec le système d‟exploitation toujours
actif…), les principales fonctions d‟un noyau temps réel peuvent être scindées en trois
groupes ci-dessous.
Donc, les tâches de même que les processus concourent à l‟obtention du ou des processeurs,
et peuvent communiquer ou se synchroniser. La différence est qu‟une tâche est caractérisée
par une pile et un pointeur d‟instruction, mais partage la mémoire avec les autres
tâches du même processus; tandis que la mémoire pour les processus est privée (il en résulte
que le passage par l‟exécutif pour la communication entre processus est plus lourd mais plus
sécurisé que pour les tâches):
48
- Gestion des entrées/sorties.

- Ordonnancement des tâches.
- Relations entre les tâches (synchronisation, communication, accès à une ressource
critique en exclusion mutuelle, gestion de temps…).
Figure I.5. : Architecture de l‟application : tâches et noyau temps

réel
Il est important de noter que les tâches sont les unités actives du système; le noyau temps réel
n‟est actif que lors de leur appel: donc, une tâche activée peut appeler le noyau temps réel
sous forme d‟une requête, les différentes requêtes sont servies par des modules du noyau
temps réel appelées primitives (partie temps réel du noyau). Ensuite le noyau temps réel
réactive une tâche de l‟application selon l‟algorithme d‟ordonnancement utilisé (partie
générique du noyau) (voir Figure I.5).
Une autre architecture souvent retenue est un noyau hybride qui s‟appuie sur la combinaison
d‟un noyau temps réel spécialisé, allouant du temps d‟exécution à un noyau de système
d‟exploitation non spécialisé. Cette technique permet d‟assurer le fonctionnement temps réel
des applications, tout en maintenant la compatibilité avec des environnements préexistants.
Nous trouvons une telle architecture dans RTLinux.
I.8. Gestion des tâches

Les noyaux temps réel gèrent les tâches suivant le même principe que les systèmes
d‟exploitation non spécialisés. Alors, au cours de la vie d‟une application, les tâches peuvent
atteindre les états suivants (voir Figure I.6.) :
- Tâche «inexistante» : la tâche n‟est pas créée,
- Tâche «passive» : la tâche est créée, et initialement elle doit être endormie (passive) pour
l‟attente de son réveil. De plus, une tâche peut devenir «passive» à partir de l‟état «élue»
pendant un certain temps ou jusqu‟à une certaine date, on parle de «suspension»,
- Tâche «prête» : la tâche attend d‟être élue. Dans cet état elle requiert un processeur
pour s‟exécuter,
- Tâche «élue» : lorsque le noyau le décide, une tâche en état «prête» alloue un processeur
afin d‟être exécutée. Cependant, de l‟état «élue», une tâche peut être préemptée par une
autre tâche. Dans ce cas, elle passe dans l‟état «prête» en attendant le processeur,
49
- Tâche «en attente» : de l‟état «exécutée», une tâche peut se mettre en attente d‟un message,
d‟un événement, ou de l‟accès à une ressource (on parle de «blocage»). Lorsque le
message, l‟événement (ou la ressource) est arrivé (ou libre), la tâche passe dans l‟état
«prête» pour requérir le processeur.
Figure I.6.: Graphe des états possibles d‟une tâche

A tout instant, une tâche peut être supprimée. Dans ce cas, elle passe dans l‟état «inexistante».
Etant donné que les tâches sont générées finement dans les noyaux temps réel, certains
noyaux distinguent la création et l‟initialisation d‟une tâche.
I.9. Outils de communication et de synchronisation

Cette section présente les concepts de base des outils de communication et de
synchronisation, permettant aux tâches d‟interagir. Effectivement, les exécutifs temps
réel ne proposent pas toujours tous les outils de communication et de synchronisation, et il
faut que dans certains cas le concepteur d‟une application les implémente lui-même en
utilisant ces concepts de base.
I.9. a. Sémaphore
Le sémaphore est un outil introduit par Dijkstra en 1965, donc l‟un de ses rôles est de protéger
une zone de programme dite critique lorsque le nombre de tâches qui accèdent simultanément
à une ressource critique est supérieur à un nombre limité d‟instances de cette ressource. En
effet, un sémaphore est une variable soit binaire (avec deux états possibles: libre et pris), soit
n-aire.
Dans le cas des sémaphores binaires, un sémaphore est caractérisé par une valeur booléenne et
une file d‟attente de tâches en attente du sémaphore (voir Figure I.7(a)). Tandis que dans le
cas des sémaphores n-aire, appelés «sémaphores à compte» ou «sémaphores compteur»,
un sémaphore est caractérisé par un nombre entier naturel (donc la valeur 0 indique que le
sémaphore est pris, et une valeur différente de zéro indique qu‟il y a un certain nombre
d‟instances libres), et une file d‟attente de tâches en attente du sémaphore (donc, chaque tâche
est couplée avec un nombre entier strictement positif indiquant le nombre d‟instances
requises) (voir Figure I.8(a)).
50
Figure I.7.: Caractérisation d‟un sémaphore binaire

(a) Sans protocole de gestion de ressource ou avec protocole à priorité hérité
(b) Avec protocole à priorité plafond
Figure I.8. : Caractérisation d‟un sémaphore compteur

(a) Sans protocole de gestion de ressource ou avec protocole à priorité hérité
(b) Avec protocole à priorité plafond
La file d‟attente peut être gérée, en fonction de l‟exécutif sous-jacent, soit de façon FIFO, soit
sous la forme de plusieurs files FIFO gérées par priorité des tâches désirant accéder au
sémaphore. Lorsque les sémaphores sont utilisés pour assurer l‟exclusion mutuelle, ou encore
pour permettre un accès de type lecteur/écrivain (soit un lecteur/un écrivain en cas de
sémaphore binaire, soit multiple lecteur/un écrivain en cas de sémaphore compteur), ces
sémaphores peuvent être couplés, selon les exécutifs, avec un protocole à priorité héritée ou
bien un protocole à priorité plafond afin d‟éviter le phénomène d‟inversion de priorité. Dans
le cas du protocole à priorité plafond, il est nécessaire de caractériser chaque type des
sémaphores par une «priorité plafond» (voir Figure I.7.(b), Figure I.8 (b)).
I.9. b. Moniteurs
Le moniteur est un outil utilisé pour synchroniser deux ou plusieurs tâches qui utilisent des
ressources partagées. En fait, l‟utilisation de la ressource ne peut avoir lieu qu‟à travers
le moniteur, et les primitives du moniteur permettant de manipuler cette ressource sont non
réentrantes. Le moniteur est strictement plus puissant que le sémaphore. Un moniteur est
constitué de:
- un ensemble de primitives permettant l‟interaction avec la ressource partagée,
- un verrou d‟exclusion mutuelle,
- des variables associées à la ressource.
En pratique, il existe deux types de moniteur, l‟un de moniteur classique et l‟autre de
moniteur à la Ada.
- Le moniteur classique, appelé «moniteur de Hoare»: est un mécanisme dans lequel la non
réentrance des primitives est couplée avec un «wait» et un «signal» permettant respectivement
de mettre en attente et de réveiller une tâche accédant au moniteur sous certaines conditions.
Ce type de moniteur peut être implémenté par exemple dans la norme POSIX 1003.1 à l‟aide
de variables conditionnelles. Lorsqu‟une tâche doit être mise en attente sur le moniteur tant
51
qu‟une condition n‟est pas réalisée, charge au programmeur d‟utiliser les outils «wait» et
«signal» pour implémenter les conditions (gardes) d‟accès.
- Le moniteur à la Ada (objet protégé): permet de mettre une garde (une barrière logique) à
l‟entrée de chaque primitive du moniteur, ce qui offre des traitements plus fins et plus
transparents des conditions d‟accès par rapport au moniteur de Hoare. Par exemple, dans le
cas où il y a plusieurs conditions de réveil, seule la tâche concernée est réveillée par le
changement d‟état du moniteur, contrairement au cas du moniteur de Hoare dans lequel toutes
les tâches en attente sur «wait» sont réveillées sur un «signal», puis doivent évaluer leur
condition afin de se remettre en attente ou de poursuivre leur exécution. De plus, le moniteur
à la Ada possède un mécanisme natif de l‟accès de type lecteur/écrivain, c‟est-à-dire
plusieurs tâches peuvent accéder au moniteur en lecture en même temps, mais une seule tâche
peut y accéder en écriture à la fois. En outre, le protocole à priorité plafond existe également
pour le moniteur à la Ada.
I.9. c. Signaux
Les signaux sont des événements (sans données) pouvant être envoyés à une ou plusieurs
tâches simultanément. Il y a deux types de signaux: les «signaux synchrones», internes à une
tâche ou un processus, et les «signaux asynchrones», provenant d‟autres tâches ou processus,
ou bien de source matérielle externe.
- Un signal synchrone est le résultat d‟un événement interne à une tâche. Il s‟agit lorsqu‟un
événement interne a lieu, qu‟une occurrence du signal synchrone associé ait lieu. Et ce signal
est traité immédiatement de façon synchrone à son occurrence par la tâche. Normalement, à
chaque signal synchrone est associée une action par défaut, qu‟une tâche peut effectuer
lorsqu‟elle reçoit un signal synchrone.
- Les signaux asynchrones sont des signaux provenant d‟une source externe à l‟adresse d‟une
tâche ou un processus (signaux privés), ou bien à plusieurs tâches et/ou plusieurs processus
(signaux publics). Lorsqu‟un signal privé est envoyé à un processus, la dernière tâche
(chronologiquement) à s‟être sensibilisé à l‟événement peut percevoir l‟événement. Lorsqu‟un
signal public est envoyé à un processus, toutes les tâches sensibilisées au signal peuvent le
percevoir. Alors dans les cas de signaux public, un répartiteur d‟occurrences
s‟occupera de prévenir chaque tâche sensibilisée qu‟un signal public est envoyé.
Si une tâche n‟est pas prête à recevoir un signal au moment où l‟occurrence de ce signal a
lieu, il existe trois possibilités dont les occurrences non prises en compte peuvent être gérées:
«signal fugace» (l‟occurrence non prise en compte est perdue, la tâche doit attendre l‟arrivée
de cette occurrence de nouveau); «signal mémorisé» (l‟occurrence non prise en compte est
mémorisée en mettant le «drapeau» à 1, par conséquent si une autre occurrence du même
événement a lieu d‟ici à sa prise en compte, elle est ignorée); «signal à compte» (les
occurrences non prises en compte immédiatement sont comptées pour utilisation ultérieure).
I.9. d. La boîte aux lettres
Une boîte aux lettres permet une communication asynchrone entre des tâches. Une boîte aux
lettres est constituée typiquement d‟une zone d‟échange tampon (buffer) dans laquelle une
tâche dite «émettrice» peut déposer des données, et d‟un mécanisme de gestion des données
52
(messages) stockées dans la boîte aux lettres.

- - La taille de la zone d‟échange est déterminée par le nombre de messages maximum
multiplié par la taille de chaque message.
- - Les données de la boîte aux lettres sont gérées généralement par une file de type FIFO
(i.e., premier déposé/premier retiré). Donc, une tâche dite «réceptrice» retire les données
dans l‟ordre d‟arrivée des données. En fonctions de l‟implémentation, les données de la
boîte aux lettres peuvent être gérées par niveau de priorité. Ainsi, la priorité de données
peut être déterminée d‟une façon soit orientée message (chaque message est muni d‟une
priorité qui influence l‟ordre dans lequel il va être lu), soit orientée tâche (la priorité du
message est liée à la priorité de la tâche « émettrice »). Il en résulte que la zone d‟échange
tampon possède plusieurs files d‟attente des messages à l‟ordre de priorité, et les messages
ayant la même priorité sont gérés dans la même file d‟attente des messages de type FIFO.
Il est important de noter que la communication par la boîte aux lettres est asynchrone, car la
tâche « émettrice » n‟a pas besoin d‟attendre que la tâche «réceptrice» soit à l‟écoute pour lui
envoyer des données.
- Si la tâche «réceptrice» désire recevoir des données au moment où la boîte est vide, elle est
mise en attente jusqu‟à ce que des données aient été déposées dans la boîte (on parle de
blocage en lecture).
- Lorsque la tâche «émettrice» désire déposer des données dans une boîte pleine (car la
taille de la zone d‟échange tampon est normalement bornée), en règle générale, cette tâche
elle-même, est mise en état «en attente» jusqu‟à ce que des données aient été retirées de la
boîte (on parle alors de blocage en écriture, ou de la boîte aux lettres sans écrasement, qui
dans ce cas ne fonctionne plus de façon asynchrone). Cependant, en fonction de
l‟implémentation choisie, le message le plus ancien de la boîte peut être écrasé par le nouveau,
en conséquence la tâche «émettrice» ne se bloque jamais en écriture (on parle de la boîte avec
écrasement).
La Figure suivante illustre une représentation récapitulative de la composition d‟une boîte aux
lettres (sans écrasement et avec écrasement).
Figure I.9 : Composition d‟une boîte aux lettres

I.9. e. Le rendez-vous
Le rendez-vous est une communication synchrone asymétrique des tâches avec passage de
données où une tâche dite «acceptante» attend un rendez-vous, et une tâche dite «appelante»
demande à effectuer un rendez-vous avec une tâche «acceptante». Lorsque un rendez-vous est
établi (donc, la tâche «acceptante» est sur une instruction de type «accept» et la tâche
«appelante» demande l‟obtention du rendez-vous), la tâche «acceptante» exécuté le code du
rendez-vous, tandis que la tâche «appelante» est bloquée jusqu‟à la fin du rendez-vous. Des
données peuvent alors être passées de la tâche «acceptante» à la tâche «appelante».
53
Le rendez-vous peut se ramener à l‟utilisation de deux boîtes aux lettres, nommées

respectivement «bal_demande_rdz» et «bal_fin_rdz» par exemple. Remarquez que dans cette
implémentation, la boîte aux lettres de demande de rendez-vous est nécessairement publique,
car toute tâche peut demander un rendez-vous, alors que la boîte aux lettres utilisée pour
signifier la fin du rendez- vous est spécifique à chaque tâche demandant le rendez-vous.
I.9. f. Le tableau noir
Le tableau noir est la forme la plus simple des outils de communication asynchrone. En effet,
un tableau noir est une zone de mémoire commune pouvant contenir un message où l‟écriture
d‟un message écrase le message précédent, et la lecture est non bloquante et non destructive
(c‟est-à-dire, une valeur déjà lue peut être relue plusieurs fois tant qu‟elle n‟a pas été écrasée
par une écriture).
Il est nécessaire d‟utiliser un mécanisme de protection pour garantir l‟exclusion mutuelle: un
accès à la donnée ne doit pas être interrompu par un autre accès. Cependant, il n‟est pas
gênant que plusieurs accès simultanés en lecture aient lieu. Nous voyons que le mécanisme de
protection d‟un tableau noir s‟apparente au problème du «lecteur/écrivain». La Figure
I.10 suivante représente un modèle de la communication par tableau noir.
Figure I.10 : Communication par tableau noir
I.10. Classification des algorithmes d’ordonnancement

L‟ordonnancement et l‟allocation sont des termes qui concernent des domaines étroitement
liés de sorte que l‟allocation des tâches est souvent confondue avec l‟ordonnancement des
tâches et on parle alors d‟ordonnancement local et d‟ordonnancement distribué (ou global).
Nous estimons que l‟appellation « ordonnancement local » exprime parfaitement le partage
d‟un processeur entre plusieurs tâches. Concernant l‟ordonnancement global ou distribué,
nous pensons que le terme allocation dynamique convient mieux, étant donné qu‟il s‟agit
d‟allouer les tâches refusées aux processeurs. Cela permet d‟éviter toute confusion.
I.10.1. Terminologie
- Ordonnancement de tâches : C‟est la détermination d‟un ordre d‟exécution des tâches selon
les critères spécifiés. Quand cet ordre est déterminé avant le début de l‟exécution, on parle
d‟un ordonnancement statique.
- Ordonnancement dynamique : Ordonnancement des tâches où la séquence déterminée au
préalable est mise à jour et réordonnée en fonction de nouvelles tâches.
- Allocation statique : placement d‟un ensemble de tâches sur un réseau de processeurs en
respectant et en optimisant certains critères ;
- Allocation dynamique : placement des tâches créées durant l‟exécution.
I.10.2. Mécanismes et algorithmes d’ordonnancement
54
- Mécanisme d’ordonnancement local de tâches : ensemble de modules nécessaires pour la

coordination de l‟ordonnancement des tâches sur un processeur. On l‟appelle aussi
ordonnanceur. Un bon mécanisme d‟ordonnancement doit assurer les fonctions suivantes :
- Vérification de la possibilité d‟exécuter une tâche sur le processeur sans violer ses
contraintes. Cela permet de répondre à la question suivante : « Etant donné un ensemble de
tâches dont on sait que les contraintes temporelles seront vérifiées, peut – on accepter une
nouvelle tâche ? » Par conséquent, une tâche peut être refusée localement lorsque
l‟ordonnanceur local ne peut garantir ses contraintes avec l‟ensemble des tâches
préalablement ordonnancées.
- Le calcul des priorités des tâches ainsi que leur ordre d‟exécution et leurs dates de début et
de fin d‟exécution. Plusieurs algorithmes existent déjà pour réaliser ce calcul.
- La mise à jour et l‟adaptation ( le re-calcul des priorités, le ré-ordonnancement) dans le cas
de l‟arrivée d‟une nouvelle tâche.
- Ordonnancement optimal : un algorithme d‟ordonnancement est dit optimal lorsque toute
configuration T de tâches qui est ordonnanceur par un algorithme donné, l‟est aussi par cet
algorithme. En d‟autres termes c‟est un algorithme qui permet de déterminer la meilleure
séquence d‟ordonnancement qui puisse exister (respect des échéances, le cas échéant,
minimisation es retards, minimisation du temps d‟utilisation des ressources notamment le
processeur).
- Ordonnancement préemptif : C‟est un algorithme qui permet d‟interrompre
l‟exécution de la tâche courante pour la prise en compte d‟une autre tâche plus prioritaire.
Cela signifie qu‟il fournit des mécanismes nécessaires pour gérer la préemption c'est-à-dire la
commutation du contexte : elle consiste à sauvegarder le contexte de la tâche en cours
d‟exécution (registres et zones mémoires) interrompue pour l‟exécution d‟une autre tâche.
Ce contexte sera restauré quand l‟exécution de la tâche sera reprise. Ainsi, une tâche qui ne
pouvant pas être exécutée en entier est tout de même accepté si son exécution peut être
partitionnée. Le temps de commutation doit être négligeable et doit être pris en compte lors du
calcul des dates de début d‟exécution par l‟ordonnanceur. Il existe deux façons d‟autoriser la
préemption : la première consiste à n‟autoriser la préemption ou l‟interruption de la tâche en
cours que si son exécution peut ultérieurement être reprise sur le même processeur et la
seconde envisage le cas échéant de faire migrer la tâche. La migration se fait lorsque le
processeur reçoit une tâche très prioritaire et qu‟il interrompe la tâche en cours car sa priorité
est moindre, sans pouvoir reprendre cette exécution par la suite. Il est déconseillé de recourir
à la migration. On préfère plutôt le transfert de tâches c‟est placer des tâches avant le début de
leur exécution. L‟ordonnancement préemptif est très recommandé pour toutes les applications
temps réel dynamiques.
- Mécanisme d’allocation statique des tâches : c‟est un algorithme qui permet de répartir un
ensemble de tâches entre les processeurs alloués à la machine en tenant compte des
contraintes temporelles.
- Mécanisme d’allocation dynamique des tâches : c‟est un algorithme qui entre en action
lorsqu‟une tâche est refusée localement. Il se charge de déterminer un processeur pour
exécuter la tâche. Il est doté des modules de politiques de recherche de processeurs pour la
tâche refusée et de politiques pour le maintien d‟un état de processeurs afin de choisir le plus
capable d‟assumer le respect des contraintes de la tâche.
55
I.11. Exemples de Systèmes Temps Réel

I.11.1. Système de commande par ordinateur
Un système de commande par ordinateur peut être schématisé de la manière suivante :
I.11. Système de commande par ordinateur

I.11.2. Les systèmes de contrôle numériques : Régulation ou Asservissement
I.12. Système de contrôle numérique

yk et rk sont des valeurs échantillonnées, avec k = 0, 1, 2, … à la fréquence T fixe qui dépend
du procédé et de la loi de contrôle. Par exemple, dans un contrôle de moteur d‟automobile on
échantillonne plus fréquemment l‟angle de rotation du vilebrequin toutes les 10-6 séc que la
température du moteur toutes les 10 secondes.
56
On appelle échantillonneur, un composant qui lit une valeur analogique à un instant donné,
puis la mémorise (dans une capacité) jusqu‟ à lecture. On échantillonne une valeur analogique
à une fréquence au moins double de la plus petite fréquence à mesurer.
I.11.3. Systèmes de contrôle, supervision et pilotage de systèmes
Ces systèmes recouvrent une gamme d‟applications très large et variée. Ils comprennent une
architecture hiérarchique à deux niveaux : le niveau bas qui constitue l‟interface physique et
le niveau haut qui constitue le guidage / planification (interfaces opérateurs), comme le
montre le schéma suivant :
I.13. Système de contrôle, supervision et pilotage de systèmes

Exemple : Pour le système de contrôle et de supervision de patients, le niveau bas consiste en
une interface pour le contrôle de la pression sanguine, du rythme respiratoire, taux de glucose,
etc. tandis que le niveau haut représente le système expert qui interagit avec le personnel
médical et sélectionne le tableau d‟états à lui afficher.
I.11.4. Autres exemples de STR
Il existe beaucoup d‟autres exemples de STR. Nous pouvons citer :
- Les systèmes de navigation aérienne où le procédé est l‟avion.
- Les systèmes de contrôle de procédés manufacturiers.
- Le traitement du signal pour filtrage digital dans l‟extraction des informations
pertinentes, pour vidéo/son dans la compression/décompression, pour le traitement radar.
- Les applications radar : le radar est un appareil qui émet et qui reçoit des ondes
électromagnétiques à une vitesse de 300 000 km/s. Il est utilisé pour localiser des objets
dans l‟espace et déterminer leur distance. Il comprend donc un émetteur pour envoyer des
ondes vers les obstacles, une antenne pour capter le signal écho, un récepteur et un
indicateur qui permet de visualiser le signal écho amplifié.
- Les bases de données temps réel : elles sont utilisées dans des domaines tels que les
cotations financières, la gestion de trajectoire de mobiles, les fichiers temps réel et la
gestion. Contrairement à une base de données de données conventionnelle qui contient des
données statiques, une base de données temps réel contient des données de nature
transitoire. Elles sont donc destinées à contenir des « objets images » qui représentent les
états d‟objets très dynamiques du monde réel. On parle ainsi de cohérence temporelle
57
absolue lorsque l‟âge maximum de toute donnée de l‟ensemble de données associées à un

objet image est inférieur à un seuil fixe, et de cohérence temporelle relative lorsque la
différence d‟âge entre les données de l‟ensemble de données associées à un objet image est
inférieure à un seuil fixe.
- Les applications multimédia : Ce sont des applications chargées de stocker, de
transmettre et d‟afficher des flux de données vidéo, audio, images ou graphiques dans des
contraintes temporelles fortes. Les applications multimédia ont donc des spécifications
temporelles fortes, particulièrement sur les applications inter-actives (TV en directe) ou
les compressions, transmission et compression des deux flux doivent respecter des
contraintes de :
- Délai de bout en bout ;
- Régularité des flux ;
- Synchronisation des flux.
I.12. Résumé sur les classes des systèmes temps réel

Nous résumons dans le tableau ci-après les différentes catégories des applications temps réel :
Classe Caractéristiques Exemple d‟illustration
STR purement cyclique Les tâchent s‟exécutent périodiquement Un contrôleur numérique
Les E/S sont scrutées périodiquement Les
demandes en ressources sont stables (varient
peu)
STR majoritairement Les tâches s‟exécutent périodiquement Avionique

cyclique Le système doit répondre à quelques E/S Contrôle de procédé
événements externes (commandes, récupération
d‟erreur, …)
STR asynchrone mais Les tâches sont non périodiques Les multimédia
partiellement prévisible Leur duré d‟exécution est très variable Les Traitements radar
ressources consommées sont variables Télécommunications
d‟une exécution à l‟autre, mais les variations Acquisition des données
sont bornées et on a des informations Traitement de flux de
statistiques sur les variations données (data flow)
STR asynchrone et Chargé de réagir à des événements Contrôleur très intelligent

imprévisible asynchrones
Déclenchement de tâches de haute
complexité.
Un système synchrone ou réactif est un système qui réagit instantanément à des stimulations
externes (le temps de la réaction est négligeable vis – à – vis du rythme de stimulation, par
exemple les jeux vidéo)
Un système cyclique est un système dont tout le comportement n‟est rythmé que par le temps
sur la base d‟une horloge.
Un système asynchrone est un système dont le comportement est un mélange des deux
précédents et dont le temps d‟exécution des tâches peut entraîner des délais dans la prise en
compte événements. Il est donc simulé par des événements externes asynchrones et des
horloges.
58
I.13. Eléments de spécification des systèmes temps réel

Les éléments suivants caractérisent la spécification des STR :
- Les événements et les architectures des STR ;
- Les spécifications des performances des STR ;
- La spécification de composabilité ;
- Les spécifications relatives à la sûreté de fonctionnement ;
- Les spécifications relatives aux tests et diagnostiques.
I.13.1. La spécification des événements
Les événements sont spécifiés par rapport à leurs lois d‟arrivée. On distingue ainsi :
- Les événements périodiques : Ils arrivent à intervalle constant. On y associe parfois la
notion de phase pour donner la position relative dans le temps par rapport à d‟autres
événements périodiques.
- Les événements irréguliers : ce sont des événements qui selon un cycle connu à l‟avance
et qui se reproduit cycliquement
- Les événements bornés : qui arrivent n‟importe quand mais avec un intervalle minimum
entre deux occurrences
- Les événements en rafale : qui arrivent par paquet imprévisible, mais avec une densité
maximum dans un intervalle.
- Les événements non bornés : ce sont des événements dont la loi d‟arrivée est décrite par
une loi de probabilité.
I.13.2. Prise en compte des événements
On parle de scrutation (polling) lorsque le système prend l‟initiative d‟activer la fonction qui
va lire une entrée à un instant qui est programmé pour vérifier si un événement a eu lieu. Cette
scrutation est faite souvent périodiquement.
On parle de sous interruption lorsque un signe hardware qui est associé à l‟arrivée de
l‟événement déclenche l‟activation de la fonction qui va lire la donnée d‟entrée.
I.13.3. Architectures des STR
L‟interaction d‟un STR avec le monde externe induit deux types d‟architectures :
Les systèmes séquencés par les événements ou systèmes asynchrones : ce sont des
systèmes qui sont activés par les événements externes. Ila attendent des sollicitations et
réagissent à celles-ci.
Les systèmes séquencés par le temps ou systèmes synchrones : ce sont des systèmes
dont la seule source d‟événement est l‟horloge. Ils sont programmés pour exécuter leurs
actions à des instants bien précis qui restent immuables dans un mode de fonctionnement
donné.
I.13.4. La spécification de performances
La performance d‟un système est la mesure de validité du résultat fourni relativement au
meilleur résultat possible dans les mêmes circonstances.
59
La spécification de performances d‟un STR est caractérisée par la latence et la gigue sur la
latence.
La latence, c‟est le délai global de bout en bout entre un changement d‟état dans un
environnement et la réaction correspondante en sortie du système. Ce délai prend en compte :
les délais de scrutation du système, les délais dus au système d‟exploitation, les délais des
calculs applicatifs de la réponse et les délais de transmission de messages (réponse).
La gigue sur la latence : elle décrit l‟incertitude sur la latence. Elle est souvent liée à la
concurrence qui va faire varier la charge du réseau (problème d‟accès) ou des nœuds de
calcul (ordonnancement). Elle doit être faible dans les applications de contrôle et en général
dans les applications rapides.
I.13.5. Spécification de composabilité
La composabilité est une propriété qui fait qu‟une caractéristique qui existe dans un
composant du système pris isolement se retrouve comme propriété inchangée dans le système
tout assemblé. On dit également que l‟assemblage des composants est dénué d‟effet de bord
ou d‟échelle.
I.13.6. Spécifications relatives à la sûreté de fonctionnement
La sûreté de fonctionnement d‟un système temps réel est rassurée par le délai de détection
des erreurs et la tolérance aux fautes.
Dans un STR critique on cherchera toujours à ce que le délai de détection des erreurs soit
minimum. Il doit être de l‟ordre de grandeur de la boucle de contrôle la plus courte, pour
pouvoir réagir assez vite et mettre le système dans un état sûr de fonctionnement (éviter les
divergences).
Une application critique doit avoir un comportement du type FO -> FS (Fail Operationnel - >
Fail Safe). En d‟autres termes, le système doit être à mesure de continuer à fonctionner tant
qu‟un certain nombre de défaillances n‟est pas atteint. Ensuite, lorsque la limite de capacité à
assumer une défaillance de plus est atteinte, le système doit s‟arrêter de façon sûre.
60
II. Programmation concurrente et programmation temps réel

Une application TR est être décrite comme un ensemble de tâches communicantes qui
peuvent partager des ressources critiques.
La concurrence est donc un des problèmes fréquemment posé dans les STR et dans de tels
systèmes, plusieurs activités dont chacune est représentée par une tâche indépendante, peuvent
s‟exécuter en parallèle. D‟une manière générale, le fonctionnement d‟une application TR
comprend les activités suivantes :
- L‟acquisition des données depuis l‟environnement à l‟aide des capteurs ;
- Le traitement des données et l‟élaboration des résultats des résultats au bout d‟un délai
limité (caractère tempe réel)
- L‟envoi des ordres de commande de l‟environnement à l‟aide d‟actionneurs ;
Ainsi, des tâches peuvent être chargées de l‟acquisition des données à différentes périodes,
d‟autres tâches peuvent être dédiées au calcul, et d‟autres à l‟application de commandes.
Lorsque ces activités se synchronisent et communiquent, le respect de l‟exclusion
mutuelle, de la synchronisation et de la communication est vraiment un point clé auquel il
convient de s‟adresser. L‟exclusion mutuelle consiste à garantir un aspect exclusif à une
donnée ou une ressource partagée par plusieurs tâches. La synchronisation permet de bloquer
une tâche tant qu‟une autre ne la réveille pas. La communication permet à des tâches
d‟échanger des données. D‟où les méthodes de conception de ces systèmes sont utilisées pour
faciliter l‟implémentation de tâches partageant des ressources communiquant et se
synchronisant : DARTS, SA, SD, etc.
II.1. Définitions
On appelle programmation concurrente les techniques et notations permettant :
- l'expression et la manipulation (construction, destruction, lancement, arrêt, ...) d'entité
concurrentes que l'on appelle tâches ou processus ;
- la mise en place de moyens de communication et de synchronisation entre ces entités ;
- l'abstraction de l'exécution réelle des processus ou tâches sur une architecture parallèle ou
non.
La programmation temps réel est assimilable à la programmation concurrente avec comme
particularité :
- Des mécanismes ou notations permettant d'accéder au temps réel (généralement une
horloge temps réel) ;
- Des mécanismes permettant de définir ou de modifier la priorité des processus et/ou de
définir et de modifier des échéances temporelles ;
- La suppression ou l‟adaptation de certains traits du langage utilisé afin d'alléger l'applicatif
et/ou de le rendre plus déterministe.
II.2. Intérêts de la programmation concurrente

- Optimisation de l'utilisation des ressources : C'est-à-dire la programmation concurrente
optimise l'utilisation du CPU sur une architecture mono-processeur par la prise en compte du
61
parallélisme entre calcul et entrées / sorties.
II.1. Programmation concurrente

Calquer le monde réel :
En effet, le monde réel est fait d'entités concurrentes qui interagissent. Par exemple :
- Un système de réservation de billets doit nécessairement prendre en compte le fait que les
agences effectuent les réservations en parallèle.
- Un système de guidage doit utiliser les informations fournis par plusieurs capteurs
simultanément et donner des ordres à plusieurs actionneurs.
La traduction d„un monde à base d'entités concurrentes à l'aide de techniques de
programmation séquentielle conduit à :
- Inclure dans le code la répartition de l'appel des différents composants du système ;
- Modifier le programme dès que l'on change d'architecture (nombre de processeur,
répartition de l'application) ;
- Modifier profondément le programme dès que l'on inclut une nouvelle activité.
II.3. Problèmes possibles

Les problèmes inhérents à la programmation concurrente sont :
Problèmes de sûreté : la synchronisation des processus ou tâches peut entraîner des problèmes
tels que l'interblocage ou la famine.
- Par exemple, le processus A attend le processus B, qui lui même attend le processus C qui
lui même attend le processus A : il y a un interblocage (ou étreinte fatale ou encore
deadlock)
- Autre exemple, le processus A et B forment une coalition pour empêcher C d'accéder à une
ressource (A et B se la passent) : il y a famine du processus C.
Ces problèmes sont inhérents à la concurrence
Problème de vivacité :
- Suite à une mauvaise entente, il est possible que deux processus n'arrivent jamais à se
synchroniser; ceci peut conduire à l'absence de respect d'un objectif fixé sans pour autant
qu'il y ait interblocage.
Par exemple, pour réparer un chauffe-eau électrique, le plombier peut exiger que
62
l'électricité soit au norme : il faut donc l'intervention préalable de l'électricien; l'électricien

peut lui exiger de ne faire les travaux que lorsque les problèmes de fuites d'eau seront
résolus : il faut au préalable l'intervention du plombier.
Les deux processus sont actifs (ils viennent régulièrement) mais ils ne font pas progresser
les choses : on est face à une activité non constructive et donc un problème de vivacité
Difficile reproductibilité des erreurs
- L'entrelacement des différents processus (chacun peut avancer à son rythme) va définir un
nombre de comportements possibles très important.
Si l'on a quatre processus indépendants, chacun ayant dix états différents, on obtient un
système complet ayant 10^4 = 10 000 états différents ;
Chaque exécution ne va pas nécessairement faire évoluer exactement de la même façon les
processus (leur évolution dépend généralement du monde extérieur qui est en perpétuel
changement).
- Ainsi, si une erreur survient il est très difficile de reproduire cette erreur afin de
comprendre son origine.
En conclusion
La concurrence introduit des problèmes spécifiques qui peuvent être difficile à analyser.
Cependant, elle simplifie énormément le travail du concepteur et du programmeur qui peut à la
fois calquer la réalité dans son programme tout en tirant partie de l'optimisation possible des
ressources. Il existe de plus des méthodes de test formel adaptées à l'analyse de systèmes
concurrents.
II.4. Généralités sur la manipulation de processus et de tâches

II.4.1. Terminologie
On dit qu‟un système est :
- Multi-tâches lorsque plusieurs entités concurrentes s'exécutent sur une machine mono
processeur.
- Parallèle lorsque plusieurs entités concurrentes s'exécutent sur plusieurs processeurs avec
une mémoire commune.
- Réparti lorsque plusieurs entités concurrentes s'exécutent sur des machines distinctes reliées
en réseau et ne partageant pas de mémoire commune.
On dit que deux processus ou tâches sont
- Indépendants, si l'évolution de l'un n'influe pas et ne dépend pas de l'autre ;
- En coopération, si chacun mène un travail distinct de l'autre mais avec un objectif commun
et la mise en place de synchronisation et de communication et qu'il n'y a pas compétition
sur l'accès à certaines ressources ;
- En compétition lorsqu'ils sont en coopération mais lorsque, de plus, ils sont en compétition
sur l'accès de certaines ressources.
Selon le niveau d'observation, deux processus peuvent être vus en coopération ou en
compétition.
63
II.4.2. Processus et tâches

Un processus possède son propre espace d'adressage : il s'exécute sur sa propre machine
virtuelle.
Le système d'exploitation (ou le "run-time" dans le cas d'un exécutif) met en place des
mécanismes de protection contre l'interférence inter-processus.
Le partage de mémoire est alors soit impossible soit doit se faire de manière explicite (i.e.
appel système).
Une tâche partage son espace d'adressage (sa machine virtuelle) avec d'autres tâches (dépend
du système et de la création des tâches).
Les mécanismes de protection limitant l'interférence interprocessus n'existent pas pour les
tâches : une tâche accède sans limite à sa machine virtuelle.
Le programmeur (et/ou le langage utilisé) doit mettre en place manuellement ces mécanismes
de contrôle.
II.4.3. Etats de base d’un processus
II.2. Etats de base d‟un processus

1. Etat d’initialisation
L'initialisation d'un processus (ou d'une tâche) consiste à construire un environnement
d'exécution.
Selon les constructions offertes par le langage ou le système, il est ou non possible de passer en
paramètres du processus ou de la tâche des valeurs lui permettant de s'initialiser.
2. Etat d’exécution
L'état "exécution" peut être décomposé en sous états : prêt/bloqué/exécution réelle.
Figure II.3. Etats d‟exécution des tâches
64
3. Etat de terminaison
Un processus ou une tâche peut terminer sous différentes conditions :
- fin normale des instructions
- suicide par l'exécution d'une instruction de terminaison
- avorté par l'action d'un autre processus/tâche
- fin sur erreur (exception ou signal non récupéré)
- lorsque son rôle n'est plus utile
- jamais
II.5. Ecriture et lancement (démarrage) des processus et de tâches

Quatre possibilités existent pour écrire les processus :
L'utilisation de co-routines
- Les co-routines sont des sous-programmes qui se passent le contrôle les unes aux autres
par une opération « resume Nom_Coroutine »
- L'exécution par A d'un « resume B » suspend l'activité de la co-routine A au profit de B qui
s'exécute alors jusqu'à l'exécution d'un « resume ». A reprendra son exécution au point où
elle l'avait laissé lorsqu‟une co-routine lui passera le contrôle avec un « resume A ».
- Les données locales à une co-routine sont persistantes d'un appel à l'autre.
- Chaque co-routine peut être vue comme un processus. Cependant, il n‟est pas nécessaire
d‟utiliser un véritable système concurrent : l'enchaînement des opérations est réalisé par les
co-routines elles même.
L'utilisation de primitive du type "fork & join »
- La primitive « fork » permet de créer un nouveau processus qui s'exécutera
concurremment avec son père.
- La primitive « join » est l'opération inverse et permet à un père d'attendre la terminaison de
ses fils.
- L'acceptation classique du fork (le fork d'Unix) est que le processus crée ne diffère de son
père que par la valeur du retour de cette primitive (0 pour le fils et l'identifiant système du
fils pour le père).
- Le join en Unix est implémenté par la primitive « wait » ou « waitpid ».
Exemple
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>
#define N
50 int
main(void)
{
pid_t tab_pid[N]; // pid des
fils int status, i;
for (i=0; i<N; i++){
65
if ( ! (tab_pid[i] = fork()) ){
// le code du fils; ici un simple affichage et un repos de une
seconde printf("hello\n");
sleep(1);
exit();
}
}
// seul le pere arrive ici car les fils ont termine par exit
// il attend cette
terminaison for (i=0; i<N;
i++){
waitpid( tab_pid[i], &status, 0);

}
return 0;
}
L'utilisation de blocs "cobegin" ou "parbegin »
- Le cobegin est une construction réalisant l'exécution concurrente d'un ensemble de
séquences d'instructions.
cobegin
Suite_D_Instructions_1
Suite_D_Instructions_2
...
Suite_D_Instructions
_N coend
- Le bloc termine quand toutes les séquences ont terminées
La déclaration explicite des processus avec lancement implicite ou explicite
Les co-routines :
- Certains langages offrent des constructions spécifiques pour la déclaration de tâches ou
de processus :
- En Ada : type Task
- En Java : classe thread
- L‟exécution d‟une tâche ou d‟un processus est soit faite automatiquement lors du
démarrage du programme (cas de Ada) ou faite explicitement par une instruction
particulière (cas de Java avec l‟appel de la méthode start() d‟une thread)
II.6. Conclusion
La programmation concurrente simplifie la conception des systèmes temps-réel qui sont par
nature des systèmes concurrents.
Elle peut cependant introduire certains problèmes spécifiques liés en grande partie à la
synchronisation des tâches.
Les langages, ou les systèmes d‟exploitation, offrent différents mécanismes pour la
représentation et l‟exécution des tâches ou processus.
66
III. Développement d’un système expert en temps réel

Le développement d‟une application selon le génie logiciel peut être découpé en plusieurs
activités (appelées aussi phases), lesquelles constituent le cycle de vie de l‟application. Les
systèmes experts temps réel n‟échappent pas à cette règle. Plusieurs méthodes ont été
proposées pour la maîtrise du processus de développement d‟un logiciel et prennent en compte
en plus des aspects techniques, l‟organisation et les aspects humains.
Le modèle en V est le modèle le plus complet du fait qu‟elle intègre les relations entre les
différentes activités, entre les différentes étapes et entre les étapes et les activités.
Les applications temps réel sont vues comme un ensemble de tâches communicantes et
partageant des ressources limitées. Par conséquent, le cycle de développement en W convient
mieux pour ces types d‟applications. En effet, un cycle en W est décrit par deux cycles en V
qui sa suivent :
- Le premier cycle en V (spécification, conception unitaire et détaillée, codage, tests
unitaires, test d‟intégration) a lieu généralement en liant l‟application temps réel à un
simulateur du procédé contrôlé.
- Le second cycle en V consistera à valider le partage du système, validé sur un
simulateur dans le premier cycle en V, sur un noyau temps réel physiquement
connecté au procédé connecté. Ainsi, le premier cycle verra ses premières phases
(spécification, conception et codage) réduites à l‟étude du partage du système sur le noyau
temps réel et à la connexion physique au procédé. Notons qu‟à la fin du cycle en W, il
est nécessaire dans le cadre des applications TR à contraintes strictes, de s‟assurer de la
correction temporelle du système (c‟est-à-dire la cohérence entre la dynamique du procédé
contrôlé et la vitesse d‟exécution des tâches). La validation temporelle de telles
applications s‟avère très indispensable et cruciale à un niveau très haut de sûreté de
fonctionnement.
III.1. Architecture des systèmes de contrôle-commande
Une application de contrôle-commande est constituée de deux composantes fondamentales. La
première composante est matérielle. Il s‟agit des interfaces permettant de piloter le procédé et
de recueillir des informations en provenance de ce dernier (i.e., des cartes
d‟entrée/sorties analogiques ou numériques,…). La deuxième composante est logicielle. Elle
assure le bon fonctionnement du procédé. C'est-à-dire que ce dernier puisse satisfaire toute sa
spécification sans aucune défaillance. Cette double composante implique une spécification et
un développement conjoints des parties matérielles et logicielles ainsi que des tests
d‟intégration lors de la mise en œuvre effective sur le procédé.
III.1.a. Architecture logicielle des systèmes de contrôle-commande
Un système informatique de contrôle-commande doit satisfaire a priori la cohérence entre des
changements de l‟environnement et des réactivités du système face à ces changements. A
cause du comportement concurrent des événements et des données externes, il est nécessaire
de décrire l‟environnement en tant qu‟un système fortement parallèle. Il en résulte qu‟une
architecture adaptée pour répondre à ce comportement parallèle du procédé externe est une
«architecture multitâche». Cette architecture permet de faciliter la conception de logiciel en
67
définissant les tâches comme «les entités d‟exécution et de structuration de l‟application»

[CG05]. En effet, dans cette architecture logicielle multitâche, nous pouvons découper cet
ensemble de tâches selon les groupes suivants :
- Tâches d’entrées/sorties : permettent d‟accéder aux données externes fournies par des
capteurs, ou de générer des commandes aux actionneurs par l‟intermédiaire de cartes
d‟entrées/sorties. Ces tâches peuvent être exécutées de façon régulière ou par interruption.
- Tâches de traitement : constituent le cœur de l‟application. Elles peuvent être
considérées comme des boîtes noires, exécutant des algorithmes issus par exemple du
traitement du signal, du traitement d‟images, ou de l‟automatique…
- Tâches de gestion de l’interface utilisateur : permettent de présenter l‟état du procédé ou de
sa gestion à l‟utilisateur. Donc, l‟utilisateur peut modifier les consignes données ou changer
les commandes.
- Tâches de communication : ces tâches sont destinées à gérer les messages envoyés ou reçus
à travers un ou plusieurs réseaux ou bus de terrain. Si ce type de tâches existe, l‟application
est dite distribuée ou répartie.
- Tâches de sauvegarde : permettent de stocker l‟état du système à des instants fixés afin de
pouvoir être utilisé a posteriori en cas de l‟analyse de son fonctionnement, ou de
reprise d‟exécution à une étape précédente.
Les tâches obtenues, qui constituent le système informatique de contrôle-commande, ne sont
pas des entités d‟exécution indépendantes. Certaines tâches dès leur activation communiquent
et/ou se synchronisent avec les autres tâches, ou sont connectées à l‟extérieur pour les
entrées/sorties. Ainsi, dans l‟architecture logicielle multitâche, il faut que le concepteur
adresse des problèmes des relations entre tâches, qui sont représentées typiquement par la
synchronisation, la communication, le partage de ressources (ces types de relations sont
décrits en détails aux paragraphes suivants de ce manuscrit), afin d‟assurer le comportement
concurrent des systèmes de contrôle-commande.
III.1.b. Architecture matérielle des systèmes de contrôle-commande
L‟aspect matériel a une très grande importance dans les applications de contrôle-commande.
Cette implication est liée d‟une part à la connexion directe avec le monde physique réel à
l‟aide d‟une grande diversité de systèmes d‟entrées/sorties, et d‟autre part au matériel
informatique parfois spécifique et développé pour une application donnée. En fait,
l‟architecture matérielle décrit l‟agencement de composants électroniques ainsi que leur
interaction. Elle est souvent grandement masquée aux utilisateurs par le biais du système
d‟exploitation, qui donne une abstraction unifiée de tous les composants physiques. Dans ces
matériels, nous pouvons trouver des processeurs du type microcontrôleur, des mémoires, des
horloges, des composants spécifiques (i.e., ASIC: Application Specific Integrated Circuit), des
alimentations…, disciplines qui débordent largement le contexte de ce manuscrit.
III.2. Cycle de développement d’un logiciel

Le génie logiciel est «l‟application pratique de la connaissance scientifique dans la conception
et l‟élaboration de programmes informatiques et de la documentation associée nécessaire pour
les développer, les mettre en œuvre et les maintenir». Le génie logiciel consiste à appliquer des
68
méthodologies, c‟est-à-dire à développer et à utiliser des méthodes et des outils dans le but de
produire des logiciels de qualité en respectant des contraintes de temps et de coût. En effet, on
cherche à développer des logiciels qui correspondent aux besoins des utilisateurs de ces
logiciels. Le cycle «problème-solution» en est un exemple. Dans ce cas, on est souvent en
quête de la solution. Mais il n‟existe pas de solution définitive parce que la solution proposée
peut être inadaptée (le problème a été mal compris) ou l‟application de cette solution peut
entraîner des nouveaux problèmes ou mettre à jour des problèmes déjà existants. Donc, le fait
de trouver une solution n‟implique pas la fin des problèmes.
Il existe des «critères» de qualité dont un développement peut être fait pour satisfaire tout ou
partie d‟un ensemble de ces critères.
- Exactitude : le plus important des critères de qualité. Exigence d‟un logiciel à être exempt
d‟erreur; à fournir des mêmes résultats dans les mêmes conditions normales d‟utilisation.
Notons que ce déterminisme et cette reproductibilité des résultats ne sont pas adaptés au
temps réel.
- Robustesse : Capacité d‟un logiciel à maintenir ses performances malgré des changements
dans les conditions de fonctionnement ou la présence d‟incertitudes liées à ses paramètres.
Il s‟agit du fait qu‟un logiciel doit bien réagir lorsque l‟on s‟écarte des conditions normales
d‟utilisation.
- Extensibilité : Possibilité pour un logiciel d‟utiliser tout ou certaines parties de ce logiciel
pour développer un autre logiciel répondant à d‟autres besoins, sans modification ou
avec des modifications mineures.
- Portabilité : Facilité avec laquelle on peut exploiter un logiciel dans différentes
implémentations. On distingue la portabilité de la compatibilité. Le terme compatibilité est
plutôt employé pour désigner la capacité d‟un ordinateur et du matériel associé à
communiquer entre eux et à échanger des données ou de deux ordinateurs à exécuter les
mêmes programmes.
- Efficience : Caractéristique d‟un logiciel dans laquelle il y a un gain de temps, de taille,…
pour satisfaire des besoins des utilisateurs. Ce critère est très important dans les applications
embarquées.
Le développement d‟un logiciel se fait suivant un cycle, appelé le cycle de vie d‟un logiciel. Le
cycle de développement du logiciel est un ensemble de phases permettant de transformer à
travers un logiciel les besoins en des processus de traitement automatique d‟information
en provenance de son utilisateur, de son environnement ou de lui-même pour répondre à ces
besoins.
La décomposition en phases de développement permet aussi de faciliter le suivi, la vérification
et la validation du projet par le concepteur et l‟utilisateur.
Il existe de nombreux modèles de cycle de vie: modèle en «Cascade», modèle en V, modèle en
«Spirale», modèle en W,… Malgré des différences de ces modèles, tous se composent des
différentes phases qui sont échelonnées dans le temps :
- Spécifications des besoins
- Conception préliminaire
69
- Conception détaillée
- Implémentation
- Tests unitaires et tests d‟intégration
- Validation
- Exploitation/Recette
Une phase se termine par la remise d‟un (ou plusieurs) document(s) validé(s) conjointement
par l‟utilisateur et le concepteur. Une phase est terminée lorsque la revue de cette phase est
faite. Et une phase ne peut commencer que lorsque la précédente est terminée.
III.2.1. Le cycle de vie en «Cascade»
Etant proposé par W. Royce, le modèle en «Cascade» est considéré comme le modèle
classique de développement d‟un logiciel. A l‟origine, le cycle de vie en «Cascade» n‟est pas
itératif. Il est vu comme un processus séquentiel comprenant les phases suivantes: la
Spécification, la Conception Préliminaire, la Conception Détaillée, l‟Implémentation, des Tests
unitaires et tests d‟intégration. Si une erreur se produit dans une de ces phases, elle va se
propager à des phases successives. Et des changements ne sont pris en compte qu‟à la fin de la
dernière phase. Ce qui pose un surcoût de développement et de validation d‟un logiciel.
Figure III.1.a : Modèle en Cascade affiné Figure III.1.b : Itérations dans la phase de Conception
Le modèle de vie en «Cascade» affiné est présenté sur la Figure III.1.a. Dans ce modèle,
chaque phase peut mener à la précédente ou la suivante mais rarement aux phases plus
éloignées dans la séquence. La vertu de ce modèle dans le développement est qu‟il existe une
liaison entre les phases après la phase de Spécification, ce qui permet de retourner au point
pour lequel une difficulté imprévue survient. Cependant, dans certains cas, une telle démarche
peut être risquée et échouer. Ainsi, si une erreur détectée dans la phase de Tests est liée à une
mauvaise Conception ou à une Spécification imprécise, un effort pour refaire le code dans la
phase d‟Implémentation peut ne pas remédier au problème. En effet, le développement peut
retourner de nouveau à l‟origine de la phase de Spécification (voir Figure III.1.b). Un autre
modèle en «Cascade» affiné est proposé dans d‟autres ouvrages: il permet de revenir depuis
une étape à l‟une quelconque des étapes précédentes. W. Boehm propose un modèle en
«Cascade» raffiné vers une étape “build it twice” en incorporant un prototype à chaque étape
pour le feed back.
70
III.2.2. Le cycle de vie en «V»

Le cycle de vie en «V» est une variation du modèle en «Cascade». Contrairement au cycle de
vie en «Cascade», le cycle de vie en «V» se focalise sur la vérification et la validation. Un
processus en «V» s‟accomplit en deux pentes : une pente descendante et une pente ascendante.
La pente descendante du «V» reprend les étapes progressives du modèle en «Cascade» à partir
de la Spécification jusqu‟à l‟Implémentation. La pente ascendante du «V» porte un ensemble
de tests qui permettent de vérifier et/ou de valider le système développé en faisant
correspondre chaque étape de tests ou de validation à une étape de l‟analyse et de la conception
(voir Figure III.2).
Figure III.2. : Modèle en V

- Les tests unitaires : permettent de vérifier que les composants indépendants du
système répondent chacun à leurs spécifications et fonctionnent correctement en tous.
- Les tests d‟intégration : sont des tests qui se déroulent suivant les tests unitaires servant à
vérifier que les composants réalisés indépendamment fonctionnent bien ensemble. Il s‟agit
de tester des relations d‟utilisation entre les composants, le fonctionnement de tâches qui
s‟appuient sur les composants, des mécanismes de communication et de synchronisation.
- La validation : permet de vérifier que le logiciel développé répond aux besoins exprimés
dans la phase de spécifications.
Le canevas du modèle en «V» améliore celui du modèle en «Cascade» avec une limitation des
retours aux étapes précédentes. Les phases de la partie montante doivent renvoyer des
informations sur les phases en vis-à-vis lorsque des défauts sont détectés afin d‟améliorer le
logiciel. Cependant les difficultés fondamentales du modèle linéaire que l‟on affronte dans le
modèle en «Cascade» existent encore. Parce que chaque phase est traitée complètement avant
que la suivante ne soit commencée, les tests de vérification et de validation ne sont renvoyés
qu‟en fin du processus d‟implémentation. Et parce que la plupart des erreurs sont relevées
pendant les spécifications, les retours coûtent chers.
III.2.3. Les autres cycles de développement d’un logiciel
Pour le modèle en «V» en particulier, le modèle linéaire en général s‟appuie sur des documents
complètement élaborés comme un critère de transition entre des étapes. Un tel modèle est bien
adapté pour des systèmes dont on pourrait obtenir la totalité des besoins au départ. Ce qui nous
permet d‟une part de préparer tardivement des phases de tests, d‟autre part de figer ces besoins
dans toutes les étapes successives. Pourtant, avec un modèle «dirigé par les documents»
[Boe88], plusieurs projets sont produits avec des spécifications détaillées de services qu‟ils ne
71
maîtrisent pas encore (i.e., l‟interface utilisateur et les opérations fournies). Par conséquence, il
y a de grandes chances que dans la conception et le développement de ces projets qui vont
suivre, une grande quantité de code soit inutilisable.
Pour des systèmes à risques, il est favorable d‟utiliser d„autres techniques de prototypage qui
permettent de valider tout ou une partie du cahier des charges et de prendre en considération le
«feed-back» entre le concepteur et l‟utilisateur. Parmi ces modèles, on retrouve :
- Le modèle en «Prototype Rapide» (Rapid Prototyping Model) qui focalise l‟objectif du
logiciel à la première étape du cycle de développement: une conception et un prototype
seront construits rapidement, ce qui permet de le vérifier avant la phase de spécification et
d‟exiger moins de boucles de «feed-back» par rapport au modèle en «Cascade».
- Le modèle Incrémentiel et Itératif (Incremental and Iterative Model) où le développement
est découpé en étapes quand le logiciel se divise en morceaux dont chacun correspond à un
ensemble de besoins. A chaque étape, on emploie un modèle de vie linéaire pour élaborer
un ou plusieurs morceaux du système simultanément. Puis ces morceaux sont intégrés et
testés ensemble.
- Le modèle en «Spirale» qui est dirigé par les risques, proposé par W. Boehm.
III.3. Le cycle de vie Logiciel/Matériel

En informatique industrielle, on parle d‟un système temps réel lorsque ce système informatique
contrôle un procédé physique à une vitesse adaptée à l‟évolution du procédé contrôlé. Ce
système doit réagir continuellement à des événements en provenance du procédé contrôlé avec
des contraintes temporelles dont le respect est aussi important que l‟exactitude du résultat.
Une réaction ne respectant pas son échéance pourrait causer une catastrophe humaine et
financière. Un tel système comporte deux parties fondamentales: le matériel et le logiciel. Le
matériel est la partie physique (le microprocesseur, la carte d‟acquisition, le convertisseur A/D
ou D/A, etc.) permettant de piloter le procédé et de recueillir des informations en provenance
de ce dernier. Le logiciel est un ensemble des éléments informatiques assurant le
fonctionnement du procédé contrôlé. Une part significative du développement d‟un système
temps réel consiste à décider des composants matériels et des composants logiciels du système,
ainsi que du choix de quelles parties peuvent être implémentées comme des logiciels
s‟exécutant sur des composants programmables et lesquelles peuvent être implémentées sur
des matériels spécifiques.
Il existe deux approches : l‟approche de développement «Matériel/Logiciel» traditionnelle et
l‟approche de développement «Matériel/Logiciel» en Co-design.
III.3.1. L’approche de développement «Logiciel/Matériel» traditionnelle
Dans cette approche, le développement d‟un système temps réel est divisé en deux parties, une
partie matérielle et une partie logicielle (voir Figure V.22). Les deux cycles en «V» dans la
Figure III.9 représentent les deux développements distincts de l‟architecture matérielle et de
l‟architecture logicielle. A partir de la conception préliminaire, le concepteur partitionne
le système en des composants matériels et des composants logiciels. Parce que la distinction
des composants matériel/logiciel à ce niveau n‟est pas claire. Le choix dépend de l‟expérience
du concepteur, du savoir-faire, du coût de production et de maintenance. Le choix du matériel
72
se déroule souvent a priori en fonction des expériences passées du concepteur. Puis, à la suite,
les architectures sont développées séparément dans leur propre cycle de vie en «V» avec des
phases séquentielles (la conception détaillée, l‟implémentation, des tests unitaires). Lorsque le
matériel et le logiciel satisfont chacun leur fonctionnement, on les intègre ensemble dans
la phase d‟intégration et la phase de validation afin de vérifier la communication entre ces
deux parts, et aussi le fonctionnement du système considéré (i.e., des tests d‟opération, des
évaluations des contraintes temporelles,…).
Figure III.3. : Modèle de développement « Matériel Logiciel » traditionnel

L‟approche développement «Matériel/Logiciel» traditionnelle est une approche très
répandue dans le monde des systèmes embarqués temps réel. En séparant un tel système en une
partie matérielle et une partie logicielle, l‟approche traditionnelle donne une vue claire de
l‟architecture opérationnelle d‟un système temps réel. Cependant, cette approche a quelques
inconvénients. Premièrement, la partition de matériel/logiciel a lieu aussitôt à partir de la
conception générale, ce qui ne permet pas une séparation évidente des composantes
matérielles/logicielles. Le choix de matériel a priori est empirique et dépend de l‟expérience du
concepteur. De plus, des impacts entre le matériel et le logiciel ne sont pas bien définis. Par
conséquent, des problèmes de matériel détectés tardivement dans la phase de l‟intégration
peuvent entraîner un nombre de modifications de logiciel. Cela va diminuer la qualité et
augmenter le coût de développement d‟un système.
Enfin, la validation des composantes logicielles sur des exécutifs réels n‟est pas aisée. Il faut
vérifier ces dernières sur les deux aspects, l‟aspect fonctionnel et l‟aspect temporel. Il existe de
nombreuses techniques qui permettent la vérification de l‟aspect fonctionnel des composantes
logicielles (i.e., des langages formels, des méthodes formelles,…). Mais, pour leurs aspect
temporel, des analyses de codes générés sur des exécutifs réels sont souvent longues et
coûteuses (humaines et matérielles). Donc, la lacune de l‟interaction entre le matériel et le
logiciel dans l‟approche traditionnelle peut causer des influences imprévues sur le temps
acquis pour le développement d‟un système au point de la livraison («time-to-market»).
73
Malgré ces inconvénients, l‟approche traditionnelle est encore très utilisée pour les
applications embarquées.
III.3.2. L’approche de développement «Logiciel/Matériel» en Co-design
«Matériel/Logiciel» en co-design signifie la rencontre des objectifs au niveau du système en
exploitant la synergie de matériel et de logiciel par leur conception concurrente. Contrairement
à l‟approche traditionnelle, l‟approche de développement «Matériel/Logiciel» en Co-design se
concentre sur la combinaison des perspectives de matériel et de logiciel dès les premières
phases de développement. Alors, un développement va commencer avec une notation abstraite
telle que chaque composante ou module est indépendant(e) de sa réalisation finale en
matérielle ou en logicielle. Puis, la séparation des composantes matérielles/logicielles peut être
effectuée de manière la plus appropriée. L‟intégration «Matériel/Logiciel» est ensuite
complétée par un ensemble des instructions permettant des tests et des co-simulations. Un
modèle typique de développement en Co-design est présenté sur la Figure III.4 ci-dessous.
Figure III.4. : Modèle de développement « Matériel Logiciel en co-design

L‟approche de développement en Co-design est une approche encore récente pour les systèmes
temps réel. Cette approche est bien adaptée à des applications dont la spécification peut
changer continuellement et dont le «Time-to-market» affecte fortement le succès (i.e.,
systèmes de communication, électroménager,…). L‟approche de développement en Co-design
se base sur la communication synchrone dirigée par les événements. Dans cette approche, la
description fonctionnelle du système est exprimée sous la forme de graphes orientés, appelés
des CFSMs (Machines à états finis en Co-design ou Co-design Finite State Machine en
anglais). Un CFSM interprète un ensemble d‟entrées en un ensemble de sorties avec un
nombre fini d„états internes. Mais, contrairement à un FSM traditionnel, un CFSM ne change
pas tous ses états exactement en même temps. La communication entre des CFSMs est réalisée
par des événements unidirectionnels, non zéro et sans bornes de temps (asynchrone
globalement). Il existe aussi des traductions qui permettent de convertir des spécifications en
provenance d‟un langage synchrone (i.e., ESTEREL, SIGNAL, HardwareC,…) en des
CFSMs. Les CFSMs sont supposés indépendant des choix matériels ou logiciels. Cela permet
74
un choix libre de l‟implémentation dans l‟étape de «Matériel/Logiciel Partition», tel que l‟on
transforme des CFSMs en un format de description du matériel dans lequel chaque transition
est implémentée par un circuit combinatoire verrouillant ses sorties afin d‟assurer leurs non
zéro retard de réaction; ou bien que l‟on transforme des CFSMs en une structure de logiciel
qui comporte des procédures et un système d‟exploitation simple exprimés sous la forme
d‟un s-graphe (une forme réduite de graphe flot de contrôle contenant les noeuds, nommés
«Begin», «End», «Call», «Test», Assign»). Un s-graphe peut être interprété en des codes pour
être exécutables par un microprocesseur. Des interfaces entre des composantes matérielles et
des composantes logicielles sont générées automatiquement grâce à des techniques de
mémoire partagée (pour des communications dans lesquelles l‟événement émis par le logiciel
est consommé par le matériel), de «scrutation» ou d‟«interruption», de communication directe
entre des matériels ou des logiciels par «bus» ou «drapeau» respectivement. Cela permet de
faciliter la vérification de l‟intégration des matériels/logiciels et la validation dans les étapes
suivantes. Les co-simulations s‟exécutent sur des matériels simulés (i.e., des ASICs,
Application Specific Integrated Circuit), ce qui permet de réduire le coût de production et
d‟augmenter la fiabilité, mais d‟élever également le coût et le temps de développement. Par
ailleurs, l‟implémentation des logiciels possède un temps de réponse pouvant être plus grand
que celui des matériels. Notamment, si le logiciel est basé sur un système d‟exploitation avec
le mécanisme de préemption, le temps de réaction d‟un logiciel ne peut être représenté
exactement par un modèle basé sur une hypothèse synchrone.
De nos jours, avec des outils de conception assistés par ordinateur (CAO), l‟introduction du
FPGA (Field-Programmable Gate Array), et des HDLs (Hardware Description Language), le
développement «Matériel/Logiciel» en Co-design devient un vaste domaine de recherche et
une clé de technologie pour des systèmes numériques pour le COSYMA
(COSYnthesis for eMbedded micro Achitectures), pour le Ptolemy, pour le POLIS, etc.
Bien que ces méthodes soient bien adaptées pour le développement d‟applications très
intégrées, il nécessite de la part du concepteur une maîtrise globale du système. Or il est assez
classique, notamment dans le monde automobile, et afin de réduire le coût et le «time-to-
market», d‟avoir un choix de matériels précis (1 ou 2 microcontrôleurs au choix, récupérant
des informations sur un réseau de terrain). Dans ce cas, les développements matériels peuvent
se réduire à la mise sur circuits de certaines fonctions ne pouvant être exécutées de façon
logicielle pour des problèmes de puissance de calcul. Dans ce cas, une approche traditionnelle
pourra réduire le temps de développement. Il convient cependant que l‟impact du matériel sur
le logiciel soit bien connu. De plus, il convient de pouvoir tester le logiciel indépendamment
du matériel. Dans ce cas, il est fréquent d‟appliquer un cycle de développement en «W».
III.3.3. Le cycle de développement en «W» dans l’approche traditionnelle
Le modèle en «W» (voir Figure III.5) est une extension du modèle en «V». Dans ce modèle, le
premier V correspond au cycle de vie en «V» classique sur simulateur logiciel (à développer),
le deuxième V étend le premier pour prendre en considération les propriétés du matériel dans
le développement d‟un logiciel.
75
Figure III.5. : Modèle en W

- La conception adaptée : consiste à prendre en compte les modifications dues à la prise en
compte du matériel (i.e., initialisation, alimentation, etc.).
- Le codage croisé : consiste à adapter le code exécutif spécifique, pilotes de périphérique
des composants logiciels conformes à une cible implémentée (i.e., norme POSIX,
VxWorks, OSEK/VDX, etc.).
- La validation sur cible : vérifie l‟intégration de matériel/logiciel pour voir si tout
s‟exécute bien sur la cible.
- La validation temporelle : vérifie l‟ordonnancement du modèle des tâches implémentées
sur la cible.
Le modèle en «W» permet une flexibilité du choix du matériel par rapport au modèle en «V»
classique. En facilitant des modifications de l‟architecture logicielle lorsqu‟il y a des
changements de l‟architecture matérielle, la lacune de l‟interaction entre le logiciel et le
matériel dans l‟approche traditionnelle (voir Figure III.3) peut être résolue. Par conséquent, on
peut diviser l‟architecture logicielle en deux parties, donc une part indépendante du matériel et
une part étant spécifique à une cible réelle (voir Figure III.6). A partir de la conception
préliminaire, on prend la première part (le premier V) pour développer le logiciel en des
composantes «pures». Ce sont des tâches, des modules, des outils de communication ou
synchronisation, des tests et des simulations vérifiant son aspect fonctionnel. Puis dans la part
suivante (le deuxième V), en associant des informations en provenance de l‟architecture
matérielle, on peut générer des codes des composantes logicielles qui s‟adaptent bien à une
cible. Cela nous permet de tester l‟intégration matériel/logiciel et la validation temporelle.
Alors, un changement de l‟architecture matérielle n‟entraîne que des modifications sur la
deuxième partie de l‟architecture logicielle.
76
Figure III.6 : Modèle en W dans l‟approche traditionnelle

Dans la suite, le cycle de vie en «W» sera utilisé comme un modèle de développement dans
lequel les différentes étapes sont échelonnées et les différentes méthodes sont employées pour
produire des logiciels de qualité en respectant les contraintes de temps et de coût.
III.3.4. «Time-to-market», un point clé à succès
«Time-to-market» est le temps séparant la mise en conception d‟un produit à sa mise sur le
marché. De nos jours, avec le développement très rapide de la technologie, ou bien
l‟augmentation de demandes de la part des utilisateurs, le «Time-to-market» devient un critère
de plus en plus important de réussite d‟un produit, notamment dans les domaines de haute
technologie, ou dans les domaines où leur environnement et leurs matériels d‟input changent
rapidement. Si une chaîne de fabrication d‟un produit ou un cycle de développement d‟un
logiciel nécessite plus de temps pour la mise en œuvre ou la mise à jour, ce produit/logiciel
peut être démodé à cause des nouvelles demandes en provenance des utilisateurs, ou à cause
d‟un ou de plusieurs concurrents.
Figure III.7. : « Time-to-market » et modèle en W dans l‟approche traditionnelle

Pour les systèmes temps réel, le choix d‟un cycle de développement adéquat influence
considérablement le «Time-to-market». Ainsi, si l‟on compare le cycle de développement
Matériel/Logiciel traditionnel avec le modèle de développement de logiciel en «W» (voir
Figure III.5), une modification dans la partie matérielle peut être mise à jour aisément par la
77
partie logicielle correspondante grâce à des phases dans le deuxième V du cycle de

développement en W (au lieu de toutes les phases de ce cycle). En conséquence, le «Time-to-
market» pour la mise à jour d‟un produit à cause de cette modification se voit réduit.
Autrement dit, ce cycle de développement peut s‟adapter aux changements des composants
matériels. En fait, il est difficile de dire quel est le meilleur cycle de vie pour le «Time-to-
market», car il faut relier cela aux domaines d‟applications, ou bien aux caractéristiques
spécifiques de chaque cycle. Donc, le choix d‟un cycle de vie convenable pour le
développement d‟un système devient une «tâche» vitale, il est souvent choisi en fonction des
expériences de concepteur.
III.4. Gestion du temps

Le temps informatique est compté par des horloges. Il existe deux types d‟horloges: le premier
type d‟horloge est le plus simple qui dépend de l‟alimentation électrique et génère une
interruption à chaque période de la tension dont la fréquence est souvent de 50 Hz ou 60 Hz (il
s‟agit d‟une horloge de faible résolution de l‟ordre de la milliseconde. La plupart des systèmes
d‟exploitation généralistes sont munies de ce type de l‟horloge); le deuxième type d‟horloge
est plus complexe et peut générer un signal périodique dont la fréquence correspond à la
fréquence d‟activation de l‟ordonnanceur et peut être maitrisée par un logiciel (il s‟agit des
horloges programmables de haute résolution de l‟ordre de la micro seconde que les exécutifs
temps réel utilisent).
En pratique, les systèmes d‟exploitation temps réel utilisent un ou plusieurs circuits
programmables spécialisés dans la gestion du temps. Ces circuits peuvent être programmés de
sorte à :
- déclencher périodiquement une interruption, ce type de programmation est utilisé
typiquement pour déclencher périodiquement l‟ordonnanceur,
- déclencher une interruption à une certaine date, ce type de programmation permet
typiquement à une tâche de se réveiller périodiquement, avec une résolution temporelle
importante (période),
- déclencher une interruption au bout d‟un certain temps, ce type de programmation
permet typiquement à une tâche de s‟endormir pendant un certain temps, ou bien de
surveiller la durée d‟un traitement par «chien de garde». Il est associé normalement à une
ou plusieurs actions, qui sont lancées immédiatement au cas où le traitement ou l‟attente
prendrait un temps plus élevé que prévu.
Pour terminer cette section, nous parlons des modèles de la gestion du temps sur lesquels les
exécutifs ou les systèmes d‟exploitation temps réel sont actuellement basés. Il est l‟un des deux
modèles suivants:
- Noyau dirigé par le temps : seule la notion de «tick» est utilisée pour gérer le temps.
Donc, le noyau prend à main à chaque «tick», et les tâches ou les processus ne peuvent être
réveillés que sur des «ticks».
- Noyau dirigé par les événements : les horloges programmables sont utilisées à leur
granularité pour réveiller une tâche ou un processus. Ce modèle permet non seulement
d‟obtenir le fonctionnement similaire au modèle dirigé par le temps, mais aussi d‟atteindre
78
une résolution d‟horloge de l‟ordre de la micro seconde avec un surcoût processeur moindre
par rapport au modèle dirigé par le temps.
III.6. Méthodes de développement d’un logiciel

Les méthodes : elles définissent le comment, c‟est-à-dire ce qu‟il faut faire pour produire un
logiciel. Chaque méthode a besoin d‟un langage pour la production d‟une spécification, et donc
à chaque méthode est attaché un langage propre.
Les outils : ils constituent le support pour les méthodes.
Les systèmes temps réel doivent produire des résultats corrects dans des intervalles de temps
spécifiés. Si un résultat est incorrect ou arrive trop tard, un tel système est voué à l‟échec. Kopetz
et al. dans [Kop91] ont élaborées des caractéristiques principales pour une méthode de
développement d‟un système temps réel, ce sont:
- Prévisibilité : la possibilité d‟une méthode de prévoir la performance de l‟architecture
matérielle, notamment l‟analyse de temps, pour assurer le respect des contraintes
temporelles.
- Testabilité : la possibilité d‟une méthode de vérifier l‟opération dynamique d‟un système
selon ses paramètres d‟entrée. Il s‟agit d‟indiquer à quelle fraction des scénarios du
système réel peuvent être couverts par des scénarios de test correspondant; de déterminer si
le système sous des tests s‟exécute correctement (par exemple, l‟ordre et le temps des
événements, l‟observation des actions et des sorties du système pendant le test, …); de
contrôler l‟exécution du système afin d‟assurer le déterminisme de réactions si le contexte
d‟un scénario est changé.
- Tolérance aux pannes : permet de réaliser la fiabilité requise d‟un service. Foncièrement, il
existe deux types d„applications temps réel: l‟un de «défaillance-arrêt» et l‟autre de
«défaillance-opérationnelle». Avec le deuxième, le système doit assurer une continuation de
l‟application dans toutes les situations opérationnelles, même s‟il y a des erreurs ou des
défaillances.
- Conception de système : la possibilité d‟une méthode de pourvoir des mécanismes qui
permettent les développements simultanés de matériel et de logiciel de manière succincte et
consistante.
- Décomposition systématique : une possibilité de faire décomposer graduellement un
système en des composantes qui sont faciles à comprendre et peuvent être traitées
relativement indépendamment.
- Evaluabilité : avant le test l‟évaluation sur un exécutif temps réel, il est désirable
d‟évaluer la conception du système considéré. Cette caractéristique permet au concepteur de
commencer une telle évaluation le plus tôt possible dans un cycle de développement d‟un
logiciel afin d‟éviter une révision coûteuse dans la phase de test.
Il existe plusieurs méthodes pour le développement d‟un logiciel, parmi elles on peut distinguer
deux types: les méthodes se basant sur des descriptions mathématiques formelles du sens d‟un
programme donné par un langage de programmation informatique de haut niveau permettant
d‟obtenir un programme pour un ordinateur (il s‟agit des «méthode formelles»); et les méthodes
se basant sur des descriptions semi-formelles du sens des conceptions fonctionnelles données par
des diagrammes, des notations graphiques maîtrisés par les clients, et facilitant les échanges entre
79
clients et concepteurs.
Les méthodes formelles permettent d‟obtenir une très forte assurance de l‟absence de «bogue»
dans les logiciels. Cependant, elles sont des méthodes «constructives» et «universelles» [Jack98].
Donc elles sont généralement coûteuses en ressources (humaines et matérielles) et actuellement
réservées aux logiciels les plus critiques.
Pour les approches semi-formelles, Shaw les a classifiées en quatre groupes principaux selon le
style de l‟architecture utilisé: l‟Architecture orientée objet (focalise la décomposition d‟un
système en des objets distincts, en encapsulant leurs états et leurs opérations.
Les objets interagissent par invocation des opérations des autres); l‟Architecture état-transition
(se concentre sur des états d‟un système et sur des événements qui provoquent des transitions
entre ces états); l‟Architecture asservissement (une forme spéciale de diagramme de flot de
données adaptée pour des systèmes embarqués où le procédé doit s‟adapter régulièrement afin de
compenser des perturbations en provenance de l‟extérieur); et l‟Architecture temps réel (se
concentre sur des système temps réel dans lesquels le respect des contraintes de temps doit être
satisfait). Les descriptions semi-formelles offrent des mécanismes de structuration et de
décomposition très riches tout en proposant une représentation intuitive et synthétique du
système à construire. Mais, il n‟existe pas d‟outils associés permettant d‟analyser, de
vérifier ou de simuler, de valider de telles spécifications.
Effectivement, aucune des méthodes existantes ne qualifie tous les aspects présentés au-dessus.
En s‟apercevant que chaque méthode possède certaines caractéristiques spécifiques pour certaine
domaine d‟application, s‟il existe une méthode qui peut regrouper les caractéristiques de chacune
des méthodes existantes, la nouvelle méthode peut être qualifiée d‟un nombre maximal des
critères, et surtout ce principe peut s‟appliquer à chercher une méthode convenable pour tous les
domaines de problème ou tous les environnements de développement à des développeurs. Saeki a
proposé un modèle pour construire une telle méthode, nommée «l‟ingénierie des méthodes» (voir
Figure III.8.). L‟idée principale de ce modèle est la suivante: en se basant sur la «réutilisation»
des «méthodes fragmentaires», appelées «méthode de base», les développeurs récupèrent
les méthodes fragmentaires convenables d‟abord, puis les adaptent, et les s‟intègrent à la
nouvelle méthode.
Figure III.8. : L‟ingénierie des méthodes

En effet, on peut voir la méthode OMT de Rumbaugh (Object Modeling Technique) comme
l‟intégration de quatre fragments: le Diagramme de Classe, le Diagramme de Séquence, le
Diagramme des états-transitions, et le Diagramme flots de données. SA-RT (Structured Analysis
For Real-Time Systems) est une méthode de spécification des systèmes temps réel construite par
incorporer les diagrammes états-transitions dans les diagrammes flots de données de la méthode
SA (Structured Analysis) afin d‟exprimer l‟aspect dynamique du système. En outre, le
80
développeur peut construire un diagramme de classes, et puis raffiner les détails en utilisant une
technique formelle telle que le langage B.
Les difficultés dans l‟emploi de cette approche résultent de la complexité des concepts que les
méthodes possèdent. Il en résulte que la consistance de l‟intégration des méthodes doit être
vérifiée.
81
Annexes
Etude de cas : système expert de diagnostic et traitement des
infections sexuellement transmissible
5.1. Introduction
Les infections sexuellement transmissibles (IST) et leurs complications sont parmi les causes
les plus fréquentes de mortalité dans le monde, et elles sont en tête des cinq premières
maladies qui amènent les adultes des pays en développement à consulter les services de santé.
Les IST sont un problème de santé publique important, non seulement en raison de la cavité
de leurs séquelles mais encore parce qu‟elles augmentent le risque de transmission du virus de
l‟immunodéfience humaine (VIH).
Ces infections touchent les gens de tous les milieux et tous les niveaux sociaux économiques,
un problème de diagnostic et de traitement approprier se pose du fait que les experts sont des
hommes rares et chers.
C‟est qui justifie la mise en place d‟un système expert d‟aide aux diagnostiques et thérapies
en cas des infections sexuellement transmissibles. Ce système à base de connaissances pourra
permettre aux utilisateurs, même non experts du domaine médical, d‟assurer les diagnostics et
la thérapie en cas des infections sexuellement transmissibles les plus courants.
5.2. Modélisation de la connaissance

La construction d‟un système expert pose un certain nombre des problèmes notamment dans
l‟acquisition et le traitement de connaissances extraites auprès de l‟expert, plusieurs modes
sont utilisés par le cogniticien pour acquérir la connaissance. On peut citer:
- La transmission des connaissances
- Le transfert de connaissances
- L‟acquisition automatique des connaissances
Dans notre travail pour extraire les connaissances nous avons joué le rôle du cogniticien
Formulation des règles
Plusieurs modèles de représentation de la connaissance sont utilisés en intelligence

artificielle : règles de production objet, frames, réseaux sémantiques etc. Dans ce travail nous
allons utiliser les règles de productions pour la représentation de la connaissance
Nous avons défini dans le cadre de notre application une base de règles de 48 règles dont nous
énonçons les quelques unes a titre illustratif :
Règle 1
Si Urétrite aiguë ("chaude pisse ") écoulement de pus à l‟extrémité de la verge
Si sensation de brûlure en urinant ou picotement du canal de la verge
Si pertes vaginales
Si picotements urinaires
82
Alors le patient souffre de (Blennorragie- Gonocoque)

Règle 2
Si Urétrite subaiguë : petit écoulement clair à l‟extrémité de la verge
Si pertes vaginales
Si douleurs de bas ventre ou pendants les rapports
Si saignements génitaux
Si petit écoulement par l‟extrémité de la verge
Si Testicules enflés et/ou douloureux
Si Saignement après les rapports sexuels
Alors le patient souffre de (Chlamydiose-Chlamydia thachomatis)
Règle 3
Si pertes vaginales
Si Urétrite subaiguë : petit écoulement clair à l‟extrémité de la verge
Si douleurs de bas ventre ou pendants les rapports
Si saignements génitaux
Alors le patient souffre de (Mycoplasma hominis-Infection à Mycoplasmes)
Règle 4
Si Infection à Mycoplasmes
Si Mycoplasma hominis
Si Chancre ou lésion: petite plaie des organes génitaux (ou de la bouche ou de l‟anus)
Si ganglions
Si Taches roses dans la peau
Alors le patient souffre de (Syphilis-Tréponème pallidum)
Règle 5
Si Plusieurs vésicules, fissures, plaies ressemblant à des aphtes
Alors le patient souffre de (Herpès génital- Herpès virus)
Règle 6
Si Lésions qui se présentent soit sous la forme de végétations vénériennes (crêtes de coq),
avec l‟aspect de verrues
83
Alors le patient souffre de (Condylomes génitaux- Papillomavirus)
Règle 7
Si Pertes vaginales avec brûlures et démangeaisons.
Alors le patient souffre de (Trichomonase -Trichomona vaginalis)
Règle 8
Si Testicules enflés et/ou douloureux
Si Saignement après les rapports sexuels Si douloureuses et sensibles au toucher Si lésions
cutanées
Si les ulcérations sont localisées sur les organes génitaux et dans la cavité buccale ganglions
Alors le patient souffre de (Chancre mou- Haemophilus ducreyi)
Règle 9
Si Pertes vaginales avec brûlures et démangeaisons.
Si rougeur du gland
Si démangeaisons ou petites plaies superficielles
Alors le patient souffre de (Candida albicans-Mycose génitale)
Règle 10
Si Saignement après les rapports sexuels
Si Douleur pelvienne (douleur en bas du nombril)
Alors le patient souffre de (MPI)
5.3. Modélisation du système expert

Plusieurs méthodes sont connues et pour la modélisation dans notre travail nous allons utiliser
méthode UML.
Présentation de l‟UML
UML (Unified Modeling Language ou langage unifié de modélisation) est un langage
graphique destiné à la modélisation de systèmes et de processus. UML est un langage basé sur
l‟approche par objets, celle qui a d‟abord conduit à la création des langages de programmation
comme Java, C++ ou Smalltalk.
UML est unifié car il provient de plusieurs notations qui l‟ont précédé. Aujourd‟hui, UML est
promu par l‟OMG (Object Management Group), un consortium de plus de 800 sociétés et
universités actives dans le domaine des technologies de l‟objet.
Diagrammes
A l‟aide de la modélisation UML, nous présentons ici seulement quelques diagrammes,
importants ci après.
84
Diagramme de classes
Figure 5.1. Diagramme de classe

Diagramme de séquence
Figure 5.2. Diagramme de séquence

85
Nota : Au delà de ces diagrammes, pour le besoin de l‟application, il ya lieu d‟ajouter

également les diagrammes d‟activité et de cas d‟utilisation.
5.4. Présentation de l’application
Nous proposons l‟implémentation de ce système expert dans le langage Visual basic 2008. Le
module moteur d‟inférence utilise le chaînage avant.
Nous avons les interfaces suivantes :
Interface d’accueil
Figure 5.3. Interface « Détermination des signes (Fait) »
Figure 5.4. Interface « visualisation image »
Figure 5.5. Interface «Malades trouvés »

86
Figure 5.6. Interface « sécurité d‟édition maladies et symptômes »
Figure 5.7. Interface « Edition maladie et symptôme
5.5. Code source

Nous proposons l‟implémentation de ce système expert dans le langage Visual basic 2008. Le
module moteur d‟inférence utilise le chaînage avant.
Imports ADODB Public Class Form1
Public cn As New ADODB.Connection
Public rs(5) As ADODB.Recordset
87
Dim trv As Integer

Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
MyBase.Load
Application.DoEvents()
cn = New ADODB.Connection cn.Open("DSN=SE_ROSE")
For i = 0 To 5
rs(i) = New ADODB.Recordset
Next i
rs(0).Open("select * from symptomes", cn, CursorTypeEnum.adOpenDynamic,
LockTypeEnum.adLockOptimistic)
rs(1).Open("select * from maladies", cn, CursorTypeEnum.adOpenDynamic,
rs(2).Open("select * from T_concerner", cn, CursorTypeEnum.adOpenDynamic,
rs(3).Open("select * from diagnostic", cn, CursorTypeEnum.adOpenDynamic,
rs(4).Open("select * from symptomes",cn, CursorTypeEnum.adOpenDynamic,
' **** changer la liste des syndromes ************************
rs(0).MoveFirst()
Do Until (rs(0).EOF = True) Application.DoEvents()
LstVSynd.Items.Add(rs(0).Fields(0).Value).SubItems.Add(rs(0).Fields(1).Value)
rs(0).MoveNext()
Loop
CboSex.Text = "Hommes"
End Sub
Private Sub LblSynd_LinkClicked(ByVal sender As System.Object, ByVal e As
System.Windows.Forms.LinkLabelLinkClickedEventArgs) Handles LblSynd.LinkClicked
Form2.BackgroundImage = Me.PicSynd.BackgroundImage
Form2.ShowDialog()
'Shell("c:\bb\inc.png", AppWinStyle.MaximizedFocus, True, 1)
End Sub
Private Sub LstVSynd_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles LstVSynd.SelectedIndexChanged
On Error GoTo err
'MsgBox(LstVSynd.Items(0).Text)
PicSynd.BackgroundImage = Drawing.Image.FromFile("C:\Rose SE\imagesSE\" &
LstVSynd.SelectedItems(0).Text & ".jpg")
LblSynd.Text = "Image 00" & LstVSynd.SelectedItems(0).Text
Exit Sub
err:
PicSynd.BackgroundImage = Drawing.Image.FromFile("C:\Rose SE\imagesSE\inc2.png")
LblSynd.Text = "Image inconnue" End Sub
88
Private Sub BtAj_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles

BtAj.Click
For i = 0 To LstVSynd.SelectedItems.Count - 1
LstV2.Items.Add(LstVSynd.SelectedItems(i).Text).SubItems.Add(LstVSynd.Selected
Items(i).SubItems(1).Text)
Next i
End Sub
Private Sub BtSuppr_Click(ByVal sender As System.Object, ByVal e AsSystem.EventArgs) Handles
BtSuppr.Click
If LstV2.SelectedItems.Count > 0 Then
LstV2.Items.Remove(LstV2.SelectedItems(0))
End If
End Sub
Private Sub BtEff_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtEff.Click
LstV2.Items.Clear()
PicV2.BackgroundImage = Drawing.Image.FromFile("C:\RoseSE\imagesSE\inc2.png")
lblV2.Text = "Image inconnue"
End Sub
Private Sub LstV2_SelectedIndexChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles LstV2.SelectedIndexChanged
On Error GoTo err
'MsgBox(LstVSynd.Items(0).Text)
PicV2.BackgroundImage = Drawing.Image.FromFile("C:\Rose SE\images SE\"
& LstV2.SelectedItems(0).Text & ".jpg")
lblV2.Text = "Image 00" & LstV2.SelectedItems(0).Text
Exit Sub
err:
PicV2.BackgroundImage = Drawing.Image.FromFile("C:\RoseSE\imageslblV2.Text = "Image
inconnue" End Sub
Private Sub lblV2_LinkClicked(ByVal sender As System.Object, ByVal e As
System.Windows.Forms.LinkLabelLinkClickedEventArgs) Handles lblV2.LinkClicked
Form2.BackgroundImage = Me.PicV2.BackgroundImage
Form2.ShowDialog()
End Sub
Private Sub BtDiag_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtDiag.Click
' On Error Resume Next
Form3.LstMal.Items.Clear()
rs(1).MoveFirst()
Do Until (rs(1).EOF = True)
TRV = 0
For i = 0 To LstV2.Items.Count - 1 rs(3) = New ADODB.Recordset
89
rs(3).Open("select * from diagnostic where symptome='" & LstV2.Items(i).SubItems(1).Text & "' and
maladie='" & rs(1).Fields(1).Value & "'", cn, ADODB.CursorTypeEnum.adOpenKeyset,
ADODB.LockTypeEnum.adLockOptimistic)
If rs(3).EOF = True Then
Exit For
Else
trv = trv + 1
'MsgBox(LstV2.Items(i).SubItems(1).Text)
' MsgBox("select * from diagnostic where symptome='" &LstV2.Items(i).SubItems(1).Text & "' and
maladie='" & rs(1).Fields(1).Value & "'")
End If
Next i
' MsgBox(trv)
If Val(trv) = LstV2.Items.Count Then
Form3.LstMal.Items.Add(Form3.LstMal.Items.Count + 1).SubItems.Add(rs(1).Fields(1).Value & " (" &
rs(1).Fields(2).Value & ")")
Form3.LstMal.Items(Form3.LstMal.Items.Count - 1).SubItems.Add(rs(1).Fields(3).Value)
Form3.txtSynd.Text = "les symptômes trouvés chez la malade ont : "
For i = 0 To LstV2.Items.Count - 1
Form3.txtSynd.Text = Form3.txtSynd.Text & LstV2.Items(i).SubItems(1).Text & ", "
Next i
End If
' ListBox1.Items.Add(rs(1).Fields(1).Value)
rs(1).MoveNext() Application.DoEvents()
Loop
Form3.ShowDialog()
End Sub
Private Sub BtActu_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtActu.Click
LstVSynd.Items.Clear()
' **** changer la liste des syndromes ************************
rs(0).MoveFirst()
Do Until (rs(0).EOF = True) Application.DoEvents()
LstVSynd.Items.Add(rs(0).Fields(0).Value).SubItems.Add(rs(0).Fields(1).Value)
rs(0).MoveNext()
Loop
End Sub
Private Sub CboSex_SelectedIndexChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles CboSex.SelectedIndexChanged rs(0) = New ADODB.Recordset
rs(0).Open("select * from symptomes", cn, CursorTypeEnum.adOpenDynamic,
End Sub
Private Sub BtPara_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
90
BtPara.Click
Form5.ShowDialog()
Form4.ShowDialog()
End Sub
End Class
Public Class Form3

Private Sub LstMal_SelectedIndexChanged(ByVal sender As System.Object, ByVal e
As System.EventArgs) Handles LstMal.SelectedIndexChanged
If LstMal.SelectedItems.Count > 0 Then
txtTrait.Text = LstMal.SelectedItems(0).SubItems(2).Text
End If
End Sub
Private Sub BtPrec_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtPrec.Click
Me.Close() Form1.Show()
End Sub
MyBase.Load
End Sub
End Class
Public Class Form4

MyBase.Load
lstMal.Items.Clear()
With Form1.rs(1)
.MoveFirst()
Do Until (.EOF = True)
lstMal.Items.Add(.Fields(1).Value)
.MoveNext() Application.DoEvents()
Loop
End With
End Sub
Private Sub BtAjMal_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtAjMal.Click
With Form1.rs(1)
.AddNew()
.Fields(1).Value = InputBox("Tapez la maladie à ajouter")
.Update() End With
End Sub
Private Sub lstMal_SelectedIndexChanged(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles lstMal.SelectedIndexChanged
On Error Resume Next
91
' MsgBox("charger") With Form1.rs(3)

.MoveFirst()
LstVMal.Items.Clear()
Do Until (.EOF = True)
If .Fields(0).Value = lstMal.SelectedItem Then
LstVMal.Items.Add(.Fields("Codesynd").Value).SubItems.Add(.Fields("symptome"). Value)
End If
.MoveNext()
End Sub
End Class
Public Class Form5

MyBase.Load
Me.Left = 0
Me.Top = 0
End Sub
Private Sub Form5_Shown(ByVal sender As Object, ByVal e As System.EventArgs) Handles
Me.Shown
Me.Width = My.Computer.Screen.Bounds.Width
Me.Height = My.Computer.Screen.Bounds.Height
Form6.ShowDialog()
End Sub
End Class
Public Class Form6

Private Sub BtQuit_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtQuit.Click
End
End Sub
Private Sub BtVal_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles
BtVal.Click
If UCase(TextBox1.Text) = UCase("MST") And TextBox2.Text = "se" Then
Me.Close()
Form5.Close()
Else
MsgBox("Nom d'utilisateur ou mot de passe incorrect")
TextBox1.Clear()
TextBox2.Clear()
TextBox1.Focus()
End If
End Sub
End Class
92

Cours de Systèmes Experts Et Temps Réel 2017-2018

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Cours de Systèmes Experts Et Temps Réel 2017-2018

Transféré par

Droits d'auteur :

Formats disponibles

Cours de Système Expert et Temps réel, L2 Génie Informatique

Première partie : Système expert

1.2. Structure et fonctionnement d’un système expert

représentation des connaissances adoptées et selon une ou plusieurs stratégies, qui va

F IG . 1.1 – Structure d‟un système expert

- Cette séparation permet au programmeur de se focaliser au codage des connaissances

1.3. Domaines d’application

1.4. Problèmes adaptés aux systèmes experts

1.5. Processus d’ingénierie de connaissance

pas toujours acquise. Par définition, l‟expert est la personne particulièrement

1.6. Acquisition de connaissance

1.7. Les différentes sortes de système expert

Chapitre 2. Systèmes à base de règles de productions

2.1. Clause de Horn et SLD-résolution

2.2. Exemple d’une modélisation par règle.

2.3.1. Le chaînage arrière : raisonnement guidé par le but

base de fait. Par conséquent R reste inchangeable.

Au cinquième appel, la mémoire de travail M em contient[romantique(toto))] et θ vaut

Nous pouvons par ailleurs considérer la formulation suivante de ce même

r ← choix(regles); regles ← regles - {r}

F IG . 2.1 – Le graphe du raisonnement en chaînage arrière

2.3.2. Le chaînage avant : raisonnement guidé par les données

– Pour chaque règle p1 ∧ ... ∧ pn → C tel que θ ⇐ UNIFY(pi ,F ) FAIRE

Par exemple considérons la base de connaissances suivante :

FIG. 2.2 – Le graphe du raisonnement en chaînage avant

2.4. Petite comparaison

En vue de palier, lors du cheminement à travers la base de connaissance, aux

2.5. Les stratégies de contrôle

prémisse, et réussit avec aime(toto,musiqueC). Le fait aime(toto,shubert) est empilé dans la

Chapitre 3 : Le raisonnement incertain

3.1. La théorie de Bayes

De plus, sachant que :

On peu écrire la formule suivante :

3.1.1. Le moteur d’inférence

correspondent aux hypothèses qu‟on essaie de déduire.

6. Recalculer aussi les valeurs associées aux preuves différentes restantes.

3.2. Les facteurs de certitude

Considérons maintenant le cas où deux règles R1 et R2 (ou plus) aboutissent à la

C F (C ) = C FR1 (C ) + C FR2 (C ) − C FR1 (C ) ∗ C FR2 (C ) si les deux facteurs de

certitudes initiaux sont positives et par : C F (C ) = C FR1 (C ) + C FR2 (C ) + C FR1 (C ) ∗ C

3.3. Les ensembles flous

Les variables linguistiques

F IG . 3.1 – L‟ensemble flou (âge jeune)

P (FB |FA ) = max(min(µFB (u), µFA (u))

N (FB |FA ) = 1 − P (C OM P (FB )|FA )

muC OM P (FB ) (u) = 1 − µFB (u)

Une fois l‟inférence est effectuée le facteur de certitude propagé à la conclusion : C F (C ) de

Règles simples de type FUZZY-FUZZY En général, les règles de type FUZZY-FUZZY

µR (u, v) = min(µFA (u), µFC (v))

Les règles floues complexes

sont calculés. Le résultat global est :

FIG. 3.5 – Le complément d‟un ensemble flou

3.4. La théorie de Dempster-Shafer

Cet intervalle permet de mesurer le niveau de confiance de certaines propositions, mais

FIG. 3.6 – La possibilité d‟avoir FB connaissant FA

FIG. 3.7 – La possibilité d‟avoir le complément de FB connaissant FA

mesure trouvée pour l‟avion bombardier ;

mesure trouvée l‟avion bombardier ou chasseur ;

mesure trouvée pour la totalité de l‟environnement.

Par exemple la confiance affectée au sous ensemble.

De même la plausibilité associée à un sous ensemble donnée est :

X 0 étant le complément de X . Par exemple, pl({B, C }) = 1 − conf ({A} = 1 − m0 ({A}) = 1.

et le doute de X par : dbt(X ) = conf (X 0 ) = 1 − pl(X ).