Tour d’horizon des ontologies liées à l’automobile

Afin d’obtenir une RTO adaptée à nos besoins de RI, nous avons commencé par analyser les ontologies automobiles déjà disponibles dans la littérature, dont nous avons pu mal- heureusement constater la rareté. Nous supposons que ce phénomène est lié au fait que les modèles de connaissances automobiles sont généralement développés pour tout ou partie grâce à des investissements de la part des constructeurs automobiles. Dans ce contexte, toute ontologie du domaine revêt sans nul doute un intérêt stratégique qui la rend trop sensible pour être divulguée.

A travers MARIA (Model for Automotive Repair Information Applications), les travaux de [Bryan et Wright, 2005] s’intéressent à la modélisation de connaissances liées à la tâche de diagnostic automobile. Ces recherches, conduites dans le cadre du projet MYCAREVENT5_, cherchent à mettre en place un ensemble minimal de concepts nécessaires pour représenter une session de diagnostic sur lesquels peuvent s’appuyer différents projets pour construire leur propre ontologie adaptée à leurs besoins applicatifs. Comme on peut le voir sur la fi- gure 5.3, MARIA se limite dans sa portée à modéliser des informations pour la réparation d’un véhicule, et ne se préoccupe pas des modèles physiques sous-jacents : le modèle repré- sente les caractéristiques statiques des objets du domaine, pas leur comportement.

Si l’on revient aux besoins spécifiques à notre projet, les concepts modélisés par MA- RIA qui pourraient nous être utiles sont au nombre de 3 : comme chaque fiche de la base de recherche comporte à la fois le(s) problème(s) constaté(s) (i.e. symptômes) sur un type (i.e. applicabilité) de véhicule donné et la manière de les résoudre (i.e. réparation), il nous est inutile de modéliser dans la RTO les tests (et donc par extension leurs résultats) per- mettant de diagnostiquer une panne donnée. De même, nous n’aurons pas besoin de repré- senter l’applicabilité d’un véhicule car la sélection des fiches applicables à une certaine si- 4_{Comme son contenu devrait être à terme exprimé dans un formalisme spécifique, le champ d’applicabilité}

n’a pas été inclus dans le décompte.

Figure 5.3 —Représentation simplifiée du modèle conceptuel MARIA

tuation6_{sera faite par un module spécifique préalable au moteur de recherche sémantique.} Dans l’implémentation possible des symptômes proposée par [Bryan et Wright, 2005], les auteurs séparent les symptômes selon qu’ils proviennent d’une observation physique ou de codes défauts (Diagnostic Troubleshooting Code) signalés par les calculateurs électro- niques. Comme ces codes défauts sont présents sous forme d’identifiants dans les fiches de la base d’expériences étudiée, nous préférons ne pas les modéliser dans notre RTO et les traiter plus directement avec un module spécifique. Plus bas encore dans la hiérarchie des symptômes proposée, nous remarquons que ceux-ci sont différenciés selon un critère relatif au sous-système dans lequel ils apparaissent : problèmes de démarrage, de freinage, de direction . . . Un découpage de la sorte ne nous semble pas convenable car il mêle des informations liées au problème constaté (e.g. absence de fonctionnement totale, partielle, vibrations, bruits) et d’autres relatives à la fonctionnalité touchée sur le véhicule (e.g. mo- torisation, climatisation, freinage). Ceci aboutit à des duplications de concepts superflues dans la hiérarchie des symptômes : absence de fonctionnement de la motorisation, absence de fonctionnement de la climatisation . . . Nous avons donc ici un premier indice quant au besoin de considérer dans notre RTO le symptôme comme un concept défini par (au moins) deux concepts primitifs qui seraient de typeProblèmeetFonctionnalité.

Une seconde approche de modélisation est abordée avec Samovar (Système d’Analyse et de MOdélisation des Validations des Automobiles Renault) dans [Golebiowska, 2002]. L’on- tologie décrite sert de base à une aide au processus de validation d’un véhicule. En effet, le cycle de développement d’un produit automobile peut être décomposé en plusieurs sous- cycles itératifs enchaînant conception, implémentation et validation, ponctués par la pro- duction de versions successives de maquettes et/ou prototypes. L’étape de validation per- met de s’assurer de la conformité du produit vis-à-vis du cahier des charges. Golebiowska envisage d’apporter une aide aux concepteurs et techniciens de Renault en utilisant l’onto- logie comme un moyen d’accès simplifié aux nombreux documents relatifs aux problèmes antérieurs de validation. Comme on peut le constater, son objectif applicatif s’avère très 6_{Il n’est pas pertinent de retourner une fiche-incident aux symptômes totalement similaires à ceux exprimés}

par le garagiste si le véhicule en panne ne correspond pas à l’applicabilité mentionnée dans la fiche : rien n’assure que la réparation associée fonctionne dans les deux cas.

proche du nôtre. L’auteur met d’ailleurs en place un mode d’accès aux documents de sa base de recherche par l’utilisation conjointe de son modèle des validations automobiles et du moteur de recherche sémantique Corese (que nous avons décrit en 2.2.2.3). Après avoir construit un modèle de la tâche de validation, Golebiowska isole quatre composantes prin- cipales de l’ontologie :

– une pièce correspond à un composant physique du système étudié, et peut connaître un certain nombre de problèmes dont elle peut être à l’origine (elle peut aussi être la cause d’un problème sur une autre pièce) ;

– un problème, dans un contexte de validation, décrit un écart entre les comportements attendu et constaté pour un composant donné ;

– une prestation représente un service rendu au client ;

– un projet est défini par le protocole de test suivi, le groupe de personnes intervenant dans le cycle de développement du produit, la sous-partie de la chaîne de montage concernée par la réalisation de la maquette et/ou du prototype et la configuration (i.e. les caractéristiques propres) du prototype.

Nous constatons que nous nous trouvons dans une situation de modélisation comparable mais pas identique à celle de Samovar. En effet, s’il semble acquis que les deux approches doivent modéliser des problèmes, ceux-ci ne sont pas situés au même niveau de granula- rité : dans le cas des validations, Golebiowska cherche à représenter tout comportement non nominal des pièces constitutives du produit testé ; dans nos travaux, nous souhaitons pou- voir modéliser les symptômes de pannes observables pour une prestation de véhicule (si aucun écart au comportement nominal des prestations n’est constaté, le client n’a que peu de raisons d’amener son véhicule au garage). Les problèmes tels que nous devons les mo- déliser ne peuvent donc être ni identiques ni découpés selon les mêmes critères que ceux de Samovar. De plus, comme les prestations jouent pour nous le même rôle central que les pièces chez Golebiowska, notre sous-ontologie des prestations a de fortes chances d’être bien plus importante que celle des pièces. A cet égard, la taxonomie des prestations utilisée pour Samovar ne nous satisfait pas : elle est construite sur un seul niveau et suit le décou- page organisationnel des équipes de production chez Renault. Dans notre cas, modéliser les prestations selon un tel critère de différenciation aboutirait à la création de prestations au comportement difficilement évaluable par de simples observations : un automobiliste aurait du mal à formuler un jugement de satisfaction sur une prestation d’aérodynamisme ou de dépollution du moteur (car il ne perçoit que vaguement à quoi correspond un comporte- ment nominal pour ces fonctionnalités). Enfin, comme nous n’avons qu’un besoin secon- daire des pièces (ce qui nous intéresse lorsqu’une pièce est mentionnée, c’est la prestation qu’elle contribue à réaliser), il semble raisonnable que la sous-ontologie correspondante ne soit pas aussi détaillée que celle pour Samovar (qui comporte plus de 800 concepts uni- quement pour le sous-système du poste de conduite, dont celui de vis ou d’écrou). Nous retiendrons toutefois l’idée d’associer un composant avec ses sous-composants à l’aide de relations méronymiques (i.e. partie_de). En effet, dans le cadre d’un raisonnement de

diagnostic, cette propriété permet, à partir d’un composant suspect, de connaître une liste plus précise des composants à tester (jusqu’à isoler le(s) composant fautif(s)).