Partie II : Approche proposée
Chapitre 5 : Maquette de faisabilité d’ADAST
5.3. Outils logiciels utilisés
Les principaux outils logiciels utilisés sont énumérés ci-après :
- L’environnement de développement Netbeans1 dans sa version 7.2. Il s’agit d’une plateforme complète de développement d’applications Java ;
- Une trentaine de bibliothèques destinées à l’interfaçage avec l’ontologie tel que protege.jar, owlsyntax.jar, etc. Ces bibliothèques sont indispensables pour faire fonctionner et mettre en œuvre tout le travail ;
- Framework Jena2 pour la manipulation des contenus RDF, OWL etc. ;
- L’éditeur d’ontologies Protégé (v3.4 et v4.3) avec des différents plugins comme OwlViz, OntoGraph etc. Le recours à une version antérieure (v 3.4) était dans le but d’utiliser certains built-ins et des bibliothèques disponibles seulement dans cette version de Protégé ;
- D’autres outils issus de la fouille de données ont été également sollicités. Le schéma 1 Netbeans : https://fr.netbeans.org/
décrivant le processus d’enchainement de ces différents outils et leur articulation avec la maquette ADAST est présenté dans la figure 5.1.
Figure 5.1. Articulation entre les différents outils utilisés et la maquette ADAST.
Dans cette articulation, nous trouvons les outils suivants :
- L’outil Context Explorer1 pour la génération des treillis de concepts à travers l’ACF. Il s’agit d’un outil Java riche de fonctionnalités et qui permet également l’induction de règles de type (Prémisseà Conclusion) ;
- D’autres outils de fouille de données comme Sipina2, Tanagra3 et Weka4 pour la production des règles d’association et de classification. Ces trois outils sont assez riches et implémentent la majorité des algorithmes de fouilles de données connus.
1 ContextExplorer : http ://conexp.sourceforge.net/ 2 Sipina : eric.univ-lyon2.fr/~ricco/sipina.html 3 Tanagra : http://eric.univ-lyon2.fr/~ricco/tanagra/fr/tanagra.html 4 Weka : www.cs.waikato.ac.nz/ml/weka/
Acquisition de
connaissances
Maquette ADAST
Aide à la décision pour l’analyse de la sécurité Context Explorer Analyse des conceptsformels
Base de connaissances
Analyse de la sécurité Décideur • Cogniticien • Ingénieur de connaissances • Développeur de SBC SIPINA+Weka Classification d’accidents Tanagra Génération des règlesd’association Protégé Edition de l’ontologie • Expert de l’analyse de la sécurité
• Constructeur (système de transport) • Responsable de collectivité publique
Ces outils logiciels que nous venons de mentionner, font partie de la phase d’acquisition de connaissances sous le contrôle et la supervision de l’ingénieur de connaissance. Cette phase constitue de processus hors ligne qui est mis à contribution par la maquette ADAST. Vient juste après l’interaction et l’inférence entre la maquette de faisabilité d’ADAST et la base de connaissances pour conclure tout le processus d’aide à la décision.
Architecture en couches
L’architecture en couche de la maquette de faisabilité d’ADAST est composée de trois couches (Figure 5.2) :
Figure 5.2. Architecture en couches de la maquette d’aide à la décision.
- Couche de présentation : Cette couche permet d’établir le lien et d’assurer
l’interfaçage avec les différents types d’utilisateurs (expert, utilisateur, etc.). A cet effet, l’accès à toutes les fonctionnalités de la maquette est réservé uniquement à l’expert quant à l’utilisateur, il pourra uniquement visualiser et consulter les connaissances capitalisées. Cette couche permet donc, l’instanciation des modules applicatifs fournis par la couche application ;
Couche de présentation de données
Session utilisateur
expert Session utilisateur simple
Module d’acquisition Module d’aide à la décision
Couche application
Classes Java + Ontologie
Base ontologique Base de connaissances Base de cas Base de règles - R. Association - R. Classification - R. Adaptation Ontologie de domaine Ontologie noyau
- Couche applicative : Cette couche regroupe les deux modules principaux de la démarche d’aide à la décision proposée :
o Le module d’acquisition des cas : Ce module permet l’interfaçage avec la base ontologique pour fournir le vocabulaire nécessaire pour l’acquisition et la capitalisation des cas sources ;
o Le module d’aide à la décision : Ce module permet l’interfaçage avec la base de connaissances entière du système et les utilisateurs à travers les différents écrans dédiés aux phases de raisonnement à partir de cas. Il permet aussi le paramétrage du raisonnement.
- Couche de persistance : C’est la couche d’accès aux données. Elle fournit les objets nécessaires pour l’interfaçage avec la base ontologique, la base de cas et les différentes bases de règles.
La structure de la base de connaissances
La base de connaissances dans le cadre de notre maquette d’aide à la décision actuelle est structurée selon trois bases distinctes :
- Une base ontologique relative à l’ontologie de domaine ;
- Une base de cas qui collecte un ensemble de classes de cas. Chaque classe regroupe un nombre de cas (Accidents historiques) représentés en ayant recours à l’ontologie de domaine ;
- Une base de règles qui regroupe trois sous bases relatives aux différents types de règles exploitées par le module de raisonnement.
5.3.2.1. Base ontologique
La modélisation ontologique d’une situation d’insécurité (un scénario d’accident) est jugée comme une étape importante dans notre approche. Le but de cette étape est de mettre en évidence toutes les caractéristiques pouvant décrire le scénario d’accident ainsi que les relations sémantiques qui peuvent y exister. Cette étape prépare à l’intégration du raisonnement ontologique au sein du RàPC.
La base ontologique comme nous l’avons déjà vu dans notre approche ADAST (section 4.4.), comprend une ontologie noyau décrivant les principales classes d’un scénario d’accident et l’ontologie de domaine. Celle-ci servira comme référentiel pour l’acquisition des cas sources et notamment les cas cibles (pour lesquels nous cherchons des solutions). L’ontologie est alors représentée par un document XML, un aperçu présenté ci-après :
<?xml version="1.0"?> <rdf:RDF … <owl:ObjectProperty rdf:ID="a_cause_interaction"> <rdfs:domain rdf:resource="#Cas"/> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Interactions"/> <owl:Class rdf:about="#Homme_système"/> <owl:Class rdf:about="#Homme_environnement"/>
<owl:Class rdf:about="#Système_environnement"/> </owl:unionOf> </owl:Class> </rdfs:range> </owl:ObjectProperty> <owl:ObjectProperty rdf:ID="a_solution"> <rdfs:range> <owl:Class> <owl:unionOf rdf:parseType="Collection"> <owl:Class rdf:about="#Solution"/> <owl:Class rdf:about="#Mesures_correctives"/> <owl:Class rdf:about="#Mesures_préventives"/> … 5.3.2.2. Base de règles
La base de règles représente en effet une partie de la base de connaissances exploitée par le processus de raisonnement. Elle est répertoriée en trois sous bases :
- La sous base de règles d’association :
Comme convenu dans notre approche, les règles générées sont issues de l’application de l’algorithme Apriori sur l’échantillon d’apprentissage dont nous disposons. Chaque règle est alors structurée en une suite de trois lignes du fichier, précédée d’un signe « @ » et comprend une conjonction d’attributs séparés par des « ; ».
Les trois paramètres (le lift, le support et la confidence) que nous avons déjà mentionnés (voir section 4.6.1) sont présents dans la dernière ligne de chaque règle. Un algorithme d’un moteur d’inférence est intégré dans la maquette va procéder en chainage avant pour faire apparaître les règles d’association en relation avec les descripteurs saisis dans le cas cible. Ces règles d’association vont permettre à l’utilisateur de la maquette de bien ajuster/compléter sa description initiale du cas cible à traiter. Un aperçu de quelques règles est présenté ci-après :
Exemples de règles d’association ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @R_A "Ligne=OUI" "Communication__redondance=NON" ; "contrôle_E/S=NON" 1,35 57,35 97,50 @R_A "Suivi_des_trains=OUI" "Station=NON" ; "Gestion_des_alarmes=NON" 1,25 32,35 100,00 @R_A "Terminus=OUI" "Sécurité_Quai-voie=NON" ;"contrôle_E/S=NON" 1,23 38,23 92,85
- La sous base de règles de classification
Les règles de classifications sont générées en appliquant la méthode d’arbre de décision à travers l’algorithme C4.5 sur l’échantillon d’apprentissage dont nous disposons (voir
section 4.6.2). Chaque règle là aussi, occupe trois lignes, précédée d’un signe « @ » et comprend une conjonction d’attributs séparés par des espaces. La dernière ligne comporte la valeur de la probabilité associée à la règle.
Un aperçu de quelques règles est présenté ci-après :
Exemple de règles de classification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @R_C Commutation_redondance CL1_Commutation_de_redondance 0.8 @R_C Controle_E-S CL7_Controle_Entree_Sortie 0.8 @R_C Ligne Localisation_des_trains CL3_Localisation_des_trains 1.0
- La sous base de règles d’adaptation
Les règles d’adaptation sont issues de notre démarche d’acquisition de connaissances d’adaptation qui s’est basée sur l’analyse des concepts formels (voir section 4.6.3.2).
Chaque règle occupe de la même manière trois lignes, précédée d’un signe « @ ». Pour chaque cas, les instances séparés par des espaces représentent les attributs substituables avec ceux du cas cible. Les instances non précédés par de # peuvent enrichir la description du cas cible, elles présentent des instances clés.
Exemple de règles d’adaptation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@CASE_47
"Gestion_conduite_automatique" "Contrôle_entrée_sortie" "Suivi_trains" "PR14" "PR15" "PR36"
@CAS_46 #ED
"Gestion_conduite_automatique" "Contrôle_entrée_sortie" "Suivi_trains" #CS
"PR15" "PR36" #ZA
"Limite_troncon" 5.3.2.3. Base de cas
La base de cas regroupe quant à elle, l’ensemble des cas sources. Pour élaborer la base de cas, nous avons eu recours à l’échantillon d’apprentissage (Hadj-Mabrouk H. et Bied-Charreton D., 1993), (Hadj-Mabrouk H., 1994, 1998) (Mejri L., 1995), (Mejri L. et al., 2009). Cet échantillon est relatif à un dossier technique comprenant soixante-dix scénarios d’accidents issus du terrain réel, dont 64 sont relatifs exclusivement au risque de collision.
En effet, la sûreté de fonctionnement des systèmes de transport automatisés requiert la prise en compte de tous les accidents potentiels (collision, déraillement, etc.) auxquels peuvent être associés de nombreux scénarios. Dans le cadre d'une étude de faisabilité, cet échantillon s’est limité à un seul accident potentiel : la collision. Les scénarios acquis sont modélisés et représentés initialement selon une fiche descriptive (voir Annexe 1). Ils ont été répertoriés en 12 classes (11 classes du risque de collision et une classe relative à tout autre type de risque).
La désignation Ci correspond au cas d’accident numéro i dans la base de cas, i varie de 1 à 70 tandis que CLi correspond à la classe d’appartenance numéro i (Tableau 5.1).
Cas d’accidents Identification de la classe C1, C8, C29, C30, C47 CL1 : Commutation de redondance C4, C5, C6, C21, C22, C23, C34, C66 CL2 : Séquence d'initialisation C3, C7, C17, C19, C25, C38, C45, C53,
C63, C65 CL3 : Localisation des trains
C9, C10, C20, C24, C50, C64 CL4 : Gestion du freinage d'urgence C13, C14, C15, C32, C33, C35, C40 CL5 : Accostage
C2, C12, C16, C18, C55 CL6 : Gestion de sens de marche C11, C31, C36, C37, C39, C44, C46, C48 CL7 : Contrôle d'Entrée / Sortie C26, C41, C42, C54 CL8 : Suivi de l'ordre des trains C27, C28, C43, C49, C51, C60 CL9 : Conduite manuelle
C52, C67 CL10 : Contrôle / Commande des aiguilles
C68, C69, C70 CL11 : Contrôle de vitesse
C46, C48, C56, C57, C58, C59, C61, C62 CL12 : Autre risque
Tableau 5.1. Distribution des cas selon la classe d’appartenance (Hadj-Mabrouk H, 1994)
Nous avons repris cet échantillon d’apprentissage et nous avons harmonisé la représentation de tous les concepts figurants dans les scénarios selon les modèles de connaissances que nous avons développées dans notre approche ADAST (voir chapitre 4, section 4.4).
La figure 5.3 montre alors le « Mapping » entre les anciens paramètres descriptifs utilisés et les nouveaux descripteurs issus de l’emploi de l’ontologie :
Figure 5.3. Mapping entre les anciens et les nouveaux paramètres descriptifs.
La figure 5.4 présente quant à elle un aperçu de la représentation du cas source « Cas_01 » en langage Owl (Ontology Web Langage).
Architecture fonctionnelle de la maquette basée sur ADAST
L’architecture de la maquette de faisabilité comprend deux modules principaux : le module d’acquisition des cas et le module de raisonnement. Ces deux modules sont en interaction avec d’autres composants faisant le rôle d’interface avec la base de connaissances et l’ontologie de domaine. Il est a signalé que les deux modules, d’acquisition de cas et d’aide à la décision, illustrent les traitements faites en-ligne.
La figure 5.5 présente l’architecture fonctionnelle de la maquette proposée. Les principaux composants de l’architecture fonctionnelle sont les suivants :
Figure 5.5. Architecture fonctionnelle de la maquette d’aide à la décision.
- Jena : C’est un Framework écrit en Java fournissant un environnement qui facilite le développement d’applications pour le web sémantique. Jena manipule des ontologies sous différents formats tel que RDFS et OWL. Jena permet aussi le raisonnement sur l’ontologie à travers des moteurs d’inférence. Dans notre application, Jena est utilisée :
Ontologie Owl-pprj Interface Base de cas Owl/pprj Module d’acquisition de cas Connecteur d’ontologie Jena Règles d’association Règles de classification Règles d’adaptation Module d’aide à la décision Flux de données Ressources Entrée Sortie Cas cible Classe + Cas similaires + Solution + Apprentissage
o Par le connecteur d’ontologie lors de la récupération des cas :
« plugins/edu.stanford.smi.protegex.owl/jena.jar »
owlModel = (OWLModel) ProtegeOWL.createJenaOWLModelFromURI(uri);
o Pour récupérer des informations sur les concepts et les instances de l’ontologie lors du calcul de similarité et notamment les différentes opérations relatives à la gestion de l’ontologie.
- Règles d’association : Ces règles d’association vont permettre à l’utilisateur expert de bien ajuster/compléter la description initiale introduite du cas cible à traiter ;
- Règles de classification : Ces règles servent à la détection de la classe d’appartenance d’un nouveau cas cible. Elles se présentent comme des ressources pour l’ontologie ;
- Règles d’adaptation : Ces règles se trouvent dans des fichiers externes. Le module de raisonnement les utilise pour appliquer les substitutions ou l’enrichissement convenable permettant la proposition d’une solution possible au cas cible ;
- Base de cas : La base de cas regroupe l’ensemble de cas représentés en ayant recours à l’ontologie de domaine ;
- Ontologie : L’ontologie est le formalisme de base pour la description des cas sources.
- Connecteur d’ontologie : Il assure la connexion à l’ontologie pour pouvoir manipuler les connaissances emmagasinées dedans.
String uri = "file:///c:/0accident.owl";
owlModel = (OWLModel) ProtegeOWL.createJenaOWLModelFromURI(uri);