NISSR
Parties prenantes
L’utilisateur principal de CACDA est un concepteur dans l’industrie manufacturière. A l’heure où la majorité des grands groupes adoptent les modèles CAO comme l’une des références pour la définition de leurs pièces [166], nous considérons que le concepteur travaille exclusivement sur un système CAO tel que 3DEXPERIENCE, SolidWorks, Creo et autres. Le concepteur maîtrise son logiciel de modélisation, nous considérons donc qu’il ne rencontre pas d’obstacle technique à modéliser précisément la géométrie qu’il souhaite. C’est un concepteur généraliste qui n’a pas en mémoire l’ensemble des règles de conception applicables. Cette situation est fréquente dans l’industrie, les règles de conception sont nombreuses et difficilement accessibles. Les manuels de conception les regroupant peuvent être qualifiés de Big Data, dans le sens qu’ils représentent un volume de texte trop important pour être maîtrisé efficacement par un être humain [167]. De plus, un concepteur peut être amené à travailler simultanément sur plusieurs projets. Les projets d’envergure menés par de grands groupes, comme la conception d’un nouvel avion chez Airbus, font quasi-systématiquement appel à des entreprises de service telles que Capgemini, afin d’absorber la charge temporaire de conception. Ces ingénieurs doivent alors maîtriser en peu de temps les règles de conception applicables dans le domaine de leur client. Les jeunes ingénieurs n’ayant pas encore acquis d’expertise dans un domaine particulier font aussi parti des utilisateurs cibles de CACDA.
Les ingénieurs spécialisés en systèmes d’information sont responsables des bases de connaissances de l’entreprise et de leur utilisation pour la conception. Ils sont en général affectés au développement d’outils de gestion des connaissances ou à la gestion des données dans le système PLM des entreprises. Un ingénieur en système d’information est donc la personne la plus appropriée pour superviser la modélisation des règles de conception et le bon fonctionnement du graphe de connaissances. Les règles de conception étant en constante évolution, un travail de maintenance des connaissances qui se concrétise par le maintien de la cohérence du graphe est nécessaire.
Analyse des services de l’environnement de conception intelligent
Dans cette partie, nous réalisons l’analyse fonctionnelle du service principal de CACDA présenté dans la section 2.1.1. Le schéma fonctionnel de CACDA (Figure 20) est divisé en trois services qui permettent à l’assistant d’accompagner les concepteurs dans leurs usages des règles de conception.
capturer et modéliser les règles et le contexte de conception
Comme évoqué lors de la revue de l’état de l’art, la construction d’un graphe de connaissances structuré est nécessaire à l’utilisation des technologies de raisonnement sur les données. Le premier service de notre assistant consiste donc à capturer les informations nécessaires à la construction de ce graphe et à les structurer dans celui-ci. Le graphe de connaissances doit permettre d’accéder à des règles de conception à partir d’éléments contextuels.
Ainsi, en entrées, cette fonction considère un ensemble de règles de conception en vigueur dans l’entreprise. Ces règles peuvent être issues de la documentation structurée ou non de l’entreprise. CACDA est capable de traiter des règles de conception en langage naturel. La formalisation des connaissances tacites des différents experts intervenant dans le processus de conception est donc facilitée. Les règles issues de connaissances d’experts sont donc également considérées en entrée de cette fonction. Ce service structure également les données contextuelles spécifiques au domaine, c’est-à-dire celles qui n‘évolueront pas lors du processus de conception. Par exemple, les dictionnaires d’acronymes en vigueur dans l’entreprise ou les spécialités des différents concepteurs de l’entreprise.
L’écriture du graphe de connaissances est réalisée selon un modèle de données adapté au fonctionnement des services suivants. La construction de ce modèle est détaillée dans la partie 2.2. Cette étape est supervisée par un ingénieur spécialiste des systèmes d’information qui s’assure de la qualité du graphe final. Il peut aussi intervenir directement sur le graphe pour améliorer les performances de l’assistant ou suite à des dysfonctionnements.
Service 2 : permettre au concepteur d’accéder aux règles applicables à son contexte de conception
Une fois le graphe de connaissances complété, l’assistant doit permettre son exploration afin que le concepteur puisse identifier les règles applicables à son contexte de conception. Ce service considère donc, en entrée, un graphe de connaissances et fournit en sortie une liste de règles correspondant au contexte de conception. Les règles de cette liste sont alors recommandées au concepteur. Il existe différentes possibilités pour recueillir le besoin du concepteur afin de lui recommander les règles appropriées :
Le concepteur doit avoir la possibilité d’exprimer directement son besoin sous forme de requêtes en langage naturel. La requête de l’utilisateur est alors analysée par l’assistant et utilisée comme point de départ à une recommandation. L’assistant proposera alors au concepteur une liste de règles de conception dont l’énoncé sera sémantiquement proche des mots clés ou de la phrase saisie par le concepteur. Cette approche est la plus basique et est indispensable à tout système réalisant des recommandations.
La recherche par requête peut s’avérer insuffisante pour retrouver les règles appropriées au besoin du concepteur. En effet, celui ou celle-ci n’a pas nécessairement une idée précise des règles recherchées. L’assistant doit donc permettre au concepteur d’explorer l’ensemble des règles de conception en utilisant des techniques d’extension de requêtes telles que la sélection dynamique de facettes de recherche [168], [169], laquelle permet à l’utilisateur d’orienter les résultats d’une requête. Dans notre cas, ces facettes correspondent à des éléments contextuels et permettent au concepteur de mieux décrire son contexte de conception. On parlera donc de filtres contextuels. Des propositions de synonymes aux mots utilisés par le concepteur dans sa requête sont un exemple de filtres contextuels possibles.
L’assistant doit donc mettre à jour, d’une part, la liste de filtres proposés à l’utilisateur en fonction de sa recherche et, d’autre part, adapter les règles de conception recommandées en fonction des filtres sélectionnés.
La dernière méthode d’accès aux règles de conception est la plus adaptée à un assistant cognitif ubiquitaire. Il s’agit de la recommandation autonome par le système de règles de conception en fonction de la dynamique du contexte de conception et de l’activité du concepteur. Contrairement aux deux méthodes précédentes, elle ne nécessite pas d’action de la part de l’utilisateur qui peut donc rester concentré sur son activité de conception.
L’assistant doit donc raisonner sur la dynamique du contexte et l’activité de l’utilisateur afin de déterminer à quel moment la recommandation doit être faite ainsi que la liste de règles à recommander.
Service 3 : guider le concepteur dans l’application des règles de conception
Une fois que le système a filtré un ensemble de règles susceptibles de correspondre au besoin du concepteur, celui ou celle-ci doit sélectionner les règles qui seront effectivement appliquées à son modèle CAO. Ces règles sont alors enregistrées comme devant être respectées sur cette pièce.
Pour faciliter le respect de ces règles, l’assistant communique avec l’environnement de CAO en utilisant l’API de celui-ci. Plusieurs approches sont alors possibles pour faciliter le respect de ces règles par le concepteur. Les règles formelles peuvent être reliées aux paramètres correspondants du modèle CAO, afin de vérifier ou d’imposer leur respect. Les informations nécessaires au respect des règles non formelles peuvent être communiquées au concepteur sous forme d’annotations du modèle, permettant de relier la règle avec l’élément géométrique concerné. Ces annotations peuvent ensuite être intégrer au modèle dans le système PLM de l’entreprise afin de mieux transmettre la démarche de conception et de faciliter la validation et la réutilisabilité du modèle [87], [170]. La Figure 21 donne un exemple d’annotations possibles pour une règle de fraisage. La règle donne une formule pour le rayon des coins de poches en fraisage. Cette formule dépendant du diamètre de fraise choisi, l’environnement de conception présente alors au concepteur un tableau des différents diamètres standards de fraises dans son entreprise.
L’objectif final de l’assistant est de permettre au concepteur de limiter le nombre d’erreurs de conception dans son modèle et de justifier les choix de design pouvant être en contradiction avec certaines règles. Ainsi, ce service considère, en entrée, une liste de règles de conception sélectionnées par le concepteur et en sortie, le modèle CAO d’une pièce dépourvu d’erreur de conception.
C’est durant ce suivi de l’activité du concepteur que l’assistant peut construire un contexte dynamique en capturant les interactions entre le concepteur et le système de CAO. La capture de ces informations déclenche la mise à jour du graphe de connaissances et initie une recommandation automatique de règles de conception. On introduit alors une boucle de rétroaction entre les services 2 et 3.
Construction du modèle de données
Comme démontré lors de l’analyse de l’état de l’art, la construction d’un modèle de données orienté graphe adapté aux services de l’assistant et au type de données traitées joue un rôle essentiel. Dans notre cas, le modèle de données doit modéliser les règles de conception et le contexte de conception. La structure de ces données doit permettre au système de rendre le service 2 défini précédemment, c’est-à-dire de recommander des règles de conception applicables au contexte de conception. Ce contexte peut être exprimé par des requêtes de l’utilisateur, mais peut aussi être déduite de l’activité du concepteur. Dans cette partie, nous développerons donc la méthode de construction de ce modèle
Méthode de construction
Le modèle de données doit permettre de sélectionner des règles de conception en fonction du contexte de conception. Il est donc nécessaire de structurer les règles de conception dans le modèle. L’approche la plus directe consiste à partir des fonctionnalités attendues du logiciel et d’en déduire des structures de données adaptées. Ces structures peuvent ensuite être appelées par des requêtes permettant de répondre à ces fonctions. Dans notre cas, nous pouvons réaliser cette opération en quatre étapes :
1) La première étape est d’identifier une ou plusieurs questions auxquelles l’assistant doit permettre de répondre.
2) La deuxième étape consiste à identifier les nœuds et relations impliquées dans cette question.
3) La question peut ensuite être exprimée sous forme de graphe en formant un pattern continu entre les différents nœuds et relations identifiées.
4) Le pattern est finalement transformé en une requête qui peut être traduite dans un langage formel pour identifier la réponse à la question posée.
Télécharger le document complet
