LA PRODUCTIQUE
Introduction
Dans ce premier chapitre, après un rapide historique, nous allons présenter le concept général de productique et plus particulièrement tel qu'il est défini à l'Aérospatiale.
Nous verrons alors plus particulièrement comment il est mis en uvre à travers les concepts de filière technologique, de cycle de vie d'un produit et de technologie de groupe. En nous plaçant dans le cadre général de l'approche systémique, nous présenterons un nouveau cadre d'analyse et de modélisation des processus industriels basée sur le modèle CIM-OSA (Computer Integrated Manufacture - Open System Architecture).
En utilisant comme grille d'analyse ce modèle CIM-OSA, nous ferons une étude comparative des deux filières qui nous intéressent : la filière des matériaux composites et celle du dessin animé. Cette étude suivant les quatre grandes vues du modèle CIM-OSA, nous permettra de montrer les nombreuses similitudes dans le cycle de vie des produits (vue fonction), et d'introduire les notions de modèle complet (vue information), de banque de composants (vue ressource) et finalement d'architecture générale (vue organisation).
La mise en place d'une architecture générale au sein d'un système productique nécessite l'intégration de nombreux logiciels et systèmes. Plusieurs techniques sont alors envisageables pour réaliser cette intégration. On peut alors distinguer généralement trois niveaux d'intégration [Gielingh et al 91] :
- partage d'informations dans une base de données
- utilisation d'interfaces procédurales
Nous passerons en revue ces différentes techniques, et nous verrons, à partir d'exemples concrets, comment elles peuvent être utilisées.
La productique
Historique
Années 70 et 80 : systèmes assistés par ordinateur.
Avec le début de l'introduction de l'informatique dans les entreprises, on a tout d'abord cherché à faire des optimisations locales pour un métier donné. C'est l'apparition de la Conception Assistée par Ordinateur (C.A.O.) dans les bureaux d'études, l'utilisation de machines à commande numérique et de programme de Fabrication Assistée par Ordinateur (F.A.O.) dans les usines, ou les premiers systèmes de scan-gouache informatique dans les studios de production de dessins animés. Cette informatisation de la production reste néanmoins limitée à certains secteurs de l'entreprise, et on constate un manque de cohérence d'ensemble le long des chaînes d'informations.
Années 90 : concept de CIM (Computer Integrated Manufacturing).
Ce manque de cohérence dans les chaînes d'informations de l'entreprise a amené une prise de conscience du besoin fondamental d'intégration des systèmes informatiques tout au long de la chaîne de production, depuis les phases de conception jusqu'à la fabrication. On a alors mis en avant le concept de CIM (Computer Integrated Manufacturing), que l'on traduit mieux en français par le terme de productique.
Modèle général
Le fonctionnement d'un processus industriel est généralement modélisé en utilisant une approche systémique [Pierreval 90]. Dans cette approche, il est classique d'aborder l'étude des systèmes de production suivant une décomposition en trois composantes principales ( See Les trois composantes du système de production. ).
Les trois composantes du système de production.
Le système physique : ce système, aussi appelé système opérant, agit directement sur les produits en effectuant des opérations de transformation, de contrôle, de manutention et de stockage.
Le système de décision : ce système, appelé aussi système de conduite ou de pilotage a pour rôle de modifier l'évolution du système physique.
Le système d'information : il a pour objet d'assurer la collecte, le stockage, le traitement et la transmission des informations du système de production ainsi que de son environnement. Il sert de support de liaison entre le système physique et le système de décision.
Une des caractéristiques importantes du système de décision est sa nature fortement hiérarchisée en différents niveaux de centres de décisions ( See Organisation du système de production. ).
Organisation du système de production.
Les centres de décisions reçoivent un cadre de décision (des informations, contraintes et objectifs) d'un niveau supérieur, et définissent des cadres de décision pour les centres de décision de même niveau ou de niveau inférieur.
Cette hiérarchie de centres de décision se caractérise également par les différents horizons temporels pris en compte par chacun d'eux, et leur période de prise de décision.
Le modèle CIM-OSA
Le projet CIM-OSA (Computer Integrated Manufacture - Open System Architecture) propose une architecture de système de productique, en définissant une méthodologie d'intervention ainsi que l'infrastructure intégrante associée. Ce modèle est en cours de développement par le consortium AMICE (European Computer Integrated Manufacturing Architecture) regroupant 21 compagnies Européennes parmi lesquelles figure l'Aérospatiale.
L'approche adoptée par CIM-OSA repose sur un cadre de modélisation basé sur trois grands principes : le principe d'instanciation, le principe de dérivation et le principe de génération suivant quatre vues (fonctions, informations, ressources, organisation).
Ce modèle général consistant lui même en un ensemble de sous modèles est organisé suivant trois dimensions et communément appelé "cube CIM-OSA" ( See Le cadre de la modélisation CIM-OSA. ).
Le cadre de la modélisation CIM-OSA.
Ce cube fait bien apparaître les trois principes de modélisation orthogonaux :
- l' instantiation permet de construire un modèle adapté à une entreprise particulière à partir de modèles partiels, eux-même exprimés en terme de modèles génériques de base.
- la dérivation qui part des besoins de l'entreprise, en tire des spécifications de conception, et enfin décrit l'implantation.
- la génération qui propose de modéliser l'entreprise suivant quatre vues complémentaires (fonctions, informations, ressources, organisation).
Les niveaux de généricité
Ces niveaux sont au nombre de trois et représentent les différents niveaux de détail sous lesquels une entreprise peut être modélisé :
générique : ce niveau représente des modèles de composants productiques applicables à tout type d'entreprise.
partiel : ce niveau représente des modèles de composants productiques applicables à un segment particulier d'entreprise ou d'atelier (exemple: ateliers de traitement thermique).
particulier : ce niveau représente des modèles de composants productiques spécialement adaptés à une entreprise ou un atelier précis.
Cette décomposition fait apparaître deux notions : la notion de typologie et la notion de composant productique . Ces deux aspects jouent un rôle important pour la définition de standard en productique. La standardisation est la composante essentielle permettant d'assurer l'ouverture et la modularité des systèmes informatiques industriels. La standardisation des composants productiques doit se faire aussi bien au niveau des fonctionnalités que des interfaces de communication et d'interconnexion. Le but visé est de pouvoir construire un système par instanciation, affinage et adaptation de composants standards pré-définis (building blocks).
Les niveaux d'expression des spécifications
La spécification et le développement d'un système informatique industriel doivent suivre des étapes précises. Ces étapes doivent assurer que la solution envisagée répond aux objectifs et besoins de l'entreprise mais aussi aux standards. Dans cette optique, CIM-OSA définit trois niveaux de modèles d'expression des spécifications :
le modèle d'expression des besoins: consiste en une description de l'entreprise en termes de besoins dans un langage utilisateur. Cette modélisation de type cahier des charges fonctionnel, précise les objectifs et contraintes de l'utilisateur. Ce modèle, bien qu'utilisant un langage utilisateur, est exploitable par les constructeurs de composants productiques.
Le modèle de spécification fonctionnelle: il reprend le modèle précédent et l'exprime de manière plus détaillée en prenant en compte l'existant technologique. Ce modèle constitue une couche isolante entre le modèle d'expression des besoins et le modèle d'implémentation. Il définit les spécifications de développement du modèle d'implémentation.
Le modèle d'implémentation: il contient la description complète des composants productiques sélectionnés (développés ou achetés), leur organisation et les informations qui leur sont relatives dont la mise en uvre constitue le système CIM de l'entreprise.
Cette structuration en trois niveaux est très proche de celle classiquement utilisée en informatique, et notamment dans le domaine des bases de données, où l'on parle alors de modèle externe ou logique, modèle conceptuel et modèle physique.
Les vues du modèle
Une entreprise est composée d'un ensemble d'éléments. Un modèle la représentant, doit prendre en compte la nature différente de ces éléments. CIM-OSA identifie quatre vues d'une entreprise:
la vue information: : elle définit l'ensemble des objets qui sont échangés et manipulés dans l'entreprise. Cette modélisation isole la représentation de point de vue utilisateur de ces objets (qui doit avoir un format adapté) de la représentation interne de ces objets (qui doit être un schéma neutre).
la vue ressource: : une entreprise comporte des ressources (machines et hommes) qu'il est nécessaire d'identifier et de représenter. Ces ressources participent aux processus de l'entreprise mais n'entrent pas dans leurs résultats.
la vue fonction : elle précise l'ensemble des activités de l'entreprise ainsi que leurs séquences. Le comportement et la structure de contrôle sont décrits dans ce modèle.
la vue organisation : elle définit l'organisation des différents éléments de l'entreprise. Elle identifie les responsabilités.
Nous reprendrons plus loin ce modèle CIM-OSA, et plus particulièrement cette vision suivant quatre vues pour comparer la filière des pièces composites à l'Aérospatiale, et la filière de fabrication de films d'animations.
Les filières technologiques
Appliquer le concept de CIM à l'ensemble des activités d'une entreprise dans sa globalité reste encore un objectif lointain. Une façon plus réaliste et pragmatique d'aborder le problème est de tenter l'intégration dans des cas simples regroupant des éléments de mêmes caractéristiques, posant des problèmes similaires, débouchant ainsi sur la notion de filière technologique.
Définitions
Dans le Larousse, on trouve pour filière la définition suivante.
Ensemble d'activités relatives à un produit de base (ex filière bois).
Une filière peut également être liés à une technologie et donc à un ensemble de procédés de fabrications. Une filière sera donc plus complètement caractérisée par un couple (produit de base, technologie de fabrication). On aura donc la définition suivante.
Système permettant de répondre à une demande client par un produit fini, à l'aide de familles de solutions technologiques maîtrisées.
Le cadre de référence de tous les projets productique sera alors une matrice dite matrice Activité/Technologie faisant référence, pour chaque filière, au cycle de vie d'un produit.
Matrice activité/technologie
Par exemple, la division avions de l'Aérospatiale a défini 7 grandes filières ou métiers pour la conception et la fabrication des pièces mécaniques et des outillages associés.
- Bâtis d'assemblages : les outillages utilisés pour assembler les différents tronçons d'un avion.
- Assemblage automatisé : ensemble des outils et opérations permettant l'automatisation de l'assemblage des pièces élémentaires d'un avion (panneaux, portes, ...).
- Pièces en forme : les pièces spécifiques de forme complexe utilisées notamment pour la jonction entre la voilure et le fuselage.
- Pièces 2D, 2D1/2 : pièces plates ou quasi plates (elles représentent 70% des pièces élémentaires d'un avion).
- Pièces massives : ce sont les pièces de structure (mât-réacteur, ferrures...).
- Pièces composites : les pièces réalisées à partir de matériaux composites.
- Tuyauteries : éléments permettant le flux des commandes hydrauliques, du carburant, du conditionnement d'air...
Matrice activité/technologie.
Cette matrice définit deux axes orthogonaux de mise en uvre de ces projets : un axe d'intégration vertical des différentes activités pour chaque filière, et un axe horizontal visant à développer des outils et une architecture commune à l'ensemble des filières ( See Matrice activité/technologie. ). Cette notion de matrice activité/technologie trouve alors tout naturellement son prolongement dans l'utilisation de la technologie de groupe.
La technologie de groupe
La technologie de groupe (group technology) est une approche de la fabrication qui vise à optimiser l'efficacité de la production en groupant des problèmes ou tâches similaires [Hyer & Wemmerlöv 87]. L'essence de la technologie de groupe est de capitaliser les similitudes dans les tâches récurrentes, et cela de trois façons complémentaires.
· En effectuant des activités similaires ensembles et donc en évitant les pertes de temps dues à des transferts entre activités différentes.
· En standardisant au maximum les activités similaires, permettant ainsi de se focaliser sur les différences, tout en évitant une duplication inutile d'effort sur les points semblables.
· En organisant de manière efficace le stockage et la recherche d'informations sur des problèmes similaires, diminuant le temps de recherche d'information, et éliminant le besoin de résoudre répétitivement et inutilement les mêmes problèmes.
La T.G.A.O. (Technologie de Groupe Assistée par Ordinateur) est essentiellement basée sur un processus de classification et de codage. Le but recherché est de grouper les pièces similaires. Pour cela il est nécessaire de déterminer les propriétés essentielles qui peuvent les différencier. On va considérer les pièces comme une population d'individus sur laquelle on va chercher à trouver des partitions permettant de répartir celles-ci en famille ( See Le principe de la T.G.A.O. ).
Le principe de la T.G.A.O.
On va donc employer des procédures de codification et de classement pour effectuer ces regroupements ( See Les étapes de la T.G.A.O. ).
Les étapes de la T.G.A.O.
En général, la codification s'appuie sur une distinction entre les caractéristiques de conception des pièces et celles de fabrication.
· Pour la conception, on pendra en compte des paramètres tels que : la morphologie, l'état de surface, les tolérances, etc.
· Pour la fabrication, on sélectionnera des paramètres tels que : les gammes, la taille des lots de fabrication, les outillages, etc.
Cycle de vie d'un produit
Quelle que soit la filière considérée, on trouve en général les mêmes briques de base, correspondant à différentes étapes du cycle de vie d'un produit ( See Vue d'ensemble d'une filière. ).
On y retrouve les différents niveaux de pilotage hiérarchisé, les différentes phases constituant la partie "productive" de la filière depuis l'idée du produit (sa spécification) jusqu'à sa mort éventuelle, ainsi que les différentes ressources intervenant dans ce cycle de vie.
Vue d'ensemble d'une filière.
Comme nous l'avons vu en abordant l'approche CIM-OSA de la productique, l'étude d'une filière technologique peut se faire suivant plusieurs points de vue complémentaire (les quatre vues : fonctions, informations, ressources, organisation). Nous allons aborder ici plus particulièrement les points de vue fonction, centré sur les activités, information (le modèle complet) et le point de vue ressources en mettant en avant la notion de base de données techniques.
Etude des deux filières technologiques
Afin de mieux illustrer la généralité de la démarche CIM-OSA, nous allons comparer les deux filière technologiques que sont la fabrication de pièces composites dans l'industrie aéronautique et la production de dessins animés dans l'industrie cinématographique. Nous allons voir que ces deux processus sont en fait très semblables, car ils relèvent tous les deux d'un processus industriel très précis.
Vue fonction
L'analyse en terme d'activités nous permet dans les deux cas d'identifier le même type d'étapes dans le cycle de vie du produit.
Spécification
Elle permet de déterminer les interfaces et les performances attendues du produit.
Conception
C'est généralement une série d'étapes avec appel à variantes qui permet de disposer d'un modèle assez précis d'un objet et les grandes lignes de son processus d'industrialisation. La démarche de conception est en général itérative.
Définition
Suivant le mode d'approvisionnement retenu, (réalisation interne, sous-traitance complète, achat) le résultat de la conception sera optimisé en tenant compte ou non de l'outil de production. La définition est associée au dossier d'industrialisation qui en est l'outil de lecture.
Préparation
Son rôle est d'interpréter la définition du produit pour alimenter ou renseigner les différents secteurs de la production.
Fabrication
Le système de pilotage transmet les ordres et les dossiers de fabrication, collecte les résultats. Suivant le degré d'intelligence des moyens, les ordres seront plus ou moins détaillés (pilotage par tâches ou pas à pas). Les phases de fabrication et d'assemblage s'accompagnent à chacune de leurs étapes de différentes phases de contrôles.
Assemblage
Essai et mise à disposition
Cette dernière étape est celle où se fait l'interface entre le fournisseur et le client. Elle doit assurer que le produit est bien conforme aux spécifications (essais) et qu'il pourra être transporté sans dommage (conditionnement). Pour certains produits complexes, on doit assurer la mise en uvre effective chez le client (installation, formation).
Vue information : notion de modèle complet
L'intégration verticale par filière utilise des logiciels et des machines qui permettent une réactivité maximale à condition qu'on conçoive du premier coup des pièces qui respectent les contraintes de l'aval et notamment de la production. La définition d'une pièce comporte déjà des éléments non seulement géométriques mais aussi technologiques. Dans le futur, les informations nécessaires aux systèmes informatiques de l'aval constitueront un modèle de la pièce, dit modèle complet, par opposition aux modèles encore incomplets d'aujourd'hui. Un des obstacles majeurs à une parfaite intégration réside aujourd'hui dans le caractère incomplet des représentations C.A.O. des pièces.
La solution à ce problème réside dans la recherche d'une représentation complète (par comparaison aux représentations actuelles essentiellement géométriques, parfois enrichies de notions morphologiques) des pièces, dans laquelle toute application trouverait les concepts dont elle a besoin. Cette représentation peut consister en plusieurs définitions ou modèles cohérents :
- réunion de l'ensemble des informations contenues dans l'ensemble des vues
- ensemble des informations strictement nécessaires pour réaliser une pièce
Nous aborderons plus précisément cet aspect représentation dans la Partie III consacrée à l'approche objet et à la représentation des connaissances.
Vue ressource
Le cycle de vie d'un produit fait naturellement appel à de nombreuses ressources : matériaux, ressources humaines, moyens de production, informations. Une activité annexe mais essentielle de la filière sera donc de gérer l'ensemble de ces ressources qui forment dans leur ensemble le véritable patrimoine de l'entreprise.
Si la notion de gestion des ressources humaines ou des moyens de production est bien identifiée, il nous semble très important ici de mettre l'accent sur la gestion des informations liées au produit et à son cycle de vie et que l'on désigne généralement sous le terme de gestion des données techniques.
Types de données
Parmi l'ensemble des données techniques intervenant dans la définition d'un produit, il est important de faire une différence entre deux grands types de données.
Les données propres à un produit (données internes)
Ce sont les données réellement propres à la définition interne d'un produit, par exemple :
Les données utilisées et partagées par plusieurs produits (données externes)
Ce peut être des données associées à des éléments définis de façon externe et participant à la réalisation du produit, par exemple :
|
- référence des matériaux utilisés |
- référence des nuanciers utilisés |
Ce peut également être des données communes partagées par plusieurs produits, correspondant soit à une notion de sous-ensemble, soit d'éléments réutilisés pour obtenir une diminution des coûts, par exemple :
|
réutilisation de décors ou d'animations entre plusieurs plans |
Banque (ou bibliothèque) de composants
L'ensemble des données associées aux éléments externes au produit devra faire l'objet d'une gestion et d'un stockage particulier. On voit donc apparaître la notion de banque (ou bibliothèque) de composants.
On peut alors distinguer deux grands types de banque de composants, suivant la façon dont on en utilise les données : par référence ou par copie.
Banque par copie
Réutilisées par copie, on modifie la copie sans toucher à l'original. Ces éléments peuvent être supprimés, mais non modifiés. Il est nécessaire de s'assurer qu'une réutilisation d'une banque s'effectue bien à partir de la même entité originelle. En conséquence une banque modifiée ne peut être sauvée sous le même nom : il s'agit d'une nouvelle entrée en banque.
Banque par référence
Réutilisées par référence directe. On ne peut détruire les éléments que s'ils ne sont pas référencés. Pour la modification, trois cas peuvent alors se présenter :
(1) On n'a pas le droit de modifier l'élément référencé
(2) On peut créer une nouvelle version de l'élément référencé
Vue organisation
Nous avons vu précédemment qu'un système productique pouvait être caractérisé par un double flux parallèle : un flux de matière dans le système physique et un flux d'information dans le système de décision (possédant lui même une structure hiérarchique), la liaison entre ceux-ci étant assurée par le système d'information.
Il est alors important de décrire le système productique en termes d'organisation globale. Comment s'effectue le pilotage du système, comment sont organisés le système physique, le système de décision et le système d'information, comment les informations circulent entre ces différents systèmes.
La vue organisation permet de faire la synthèse des 3 vues précédentes en faisant le lien entre les activités (vue fonction), la définition des données utilisées (la vue information) et l'ensemble des ressources (vue ressources). Elle permet notamment d'identifier la répartition des ressources et des informations entre les différents postes de travail. En effet, par la structure et l'organisation même de la production, des tâches précises et bien identifiables sont assignées à chacun, avec différents niveaux de responsabilité. Cette organisation se répercute également sur le plan des documents qu'il est nécessaire d'utiliser pour une tâche donnée.
Elle doit déboucher sur la définition d'une architecture générale du système productique, mettant en correspondance les postes de travail, les activités et les ressources, et spécifiant clairement les rôles et responsabilités de chacun.
Les différentes architectures
Dans le chapitre précédant, nous avons vu que la notion d'intégrations des systèmes occupe une place centrale dans la démarche productique, sans toutefois expliciter les moyens de cette intégration. Nous allons donc maintenant aborder ce problème en présentant les différentes architectures permettant de faire cette intégration. Cette étude se fera chaque fois en présentant des exemples d'utilisation de ces différentes architectures au sein de projets menés à l'Aérospatiale.
Nous terminerons en montrant que quelle que soit l'architecture choisie, elle doit faire appel à des capacités de stockage et de partage d'information qui relèvent de la technologie des bases de données, introduisant ainsi la notion de base de données technique ou base de données d'ingénierie.
Intégration par échanges de fichiers
Le moyen le plus simple de faire l'intégration entre les différents modules d'un système de productique est de communiquer par échanges de fichiers. Les fichiers informatiques se substituent alors progressivement à leurs homologues papiers : plans, gammes, fiches techniques, etc. Les sorties produites par un programme ou module sous forme de fichier peuvent facilement devenir des entrées pour un autre module par l'intermédiaire de ce même fichier. On obtient alors ce que l'on appelle une chaîne de traitements, chaque traitement utilisant les données du précédant, les échanges de données se faisant par le biais de fichiers intermédiaires.
Le partage de fichiers est le moyen d'intégration le plus couramment utilisé car il présente l'avantage d'une grande simplicité et d'une bonne robustesse.
· Il ne demande pas de moyens informatiques complexes (bases de données, réseaux).
· Il s'accommode bien d'une architecture hétérogène car, grâce à l'existence d'utilitaires de transfert de fichiers, il en général toujours possible (mais pas toujours simple), d'échanger des données entre programmes ou machines différentes.
· Il permet une bonne maîtrise et une bonne robustesse des échanges car il est possible de contrôler les fichiers intermédiaires produits.
· Il ne remet pas réellement en cause les structures existantes car on substitue simplement les documents papiers par leurs homologues informatiques : les fichiers.
Le partage de fichier présente néanmoins un certain nombre d'inconvénients.
· L'intégration reste peu efficace car la majorité des opérations de transfert et de stockage doivent souvent être faites manuellement. On perd donc un temps précieux pour ce type d'opérations, qui ne sont pas en elles mêmes génératrices de plus values.
· Le volume des données et donc le grand nombre de fichiers peut rendre leur gestion complexe. Il peut notamment devenir très difficile de retrouver des données dans cette masse.
· Le manque général de concertation sur les formats de fichiers conduit en général une multiplication de ceux-ci et donc au développement de nombreux pré- et post-processeurs jouant le rôle de filtre, lors d'un échange de fichier entre applications.
· On assiste souvent à une multiplication anarchique des fichiers intermédiaires qui viennent encombrer et paralyser le système par leur volume.
· Ce mode d'intégration ne permet pas une bonne synchronisation entre applications et donc ne permet pas de les piloter de façon automatique.
Format des données
Chaque application a en général sa propre façon de stocker l'information, et donc son propre format de fichier. Ce format est bien sur le plus souvent incompatible avec les formats des fichiers d'autres applications. Même avec un même programme fonctionnant sur le même type de machine, il peut encore y avoir des problèmes dus au fait qu'il peut y avoir au sein de l'entreprise, plusieurs versions de cet applicatif, ces versions ayant des formats de fichier incompatibles.
La communication entre différents systèmes doit alors se faire par l'intermédiaire d'interprètes, chargés d'assurer la transformation entre les différents types et format de fichiers. Afin de diminuer le nombre des interprètes nécessaires, il est intéressant de pouvoir définir un langage neutre commun, qui puisse servir de passerelle entre les différentes applications.
Dans le domaine de la C.F.A.O. le besoin, partagé par la plupart des entreprises, d'échanger des informations entre systèmes différents, ayant chacun leur propre représentation, a donné naissance, à partir d'un projet lacé initialement par l'aérospatiale en 1983, à la définition d'un format neutre de fichiers. Ce format, appelé Standard d'Echange et de Transfert (SET), a donné naissance à une norme française : la norme Z68-300 [Afnor Z68-300 90].
La définition du langage SET permet de répondre à deux objectifs complémentaires ( See Utilisation du format SET. ):
- Echanger des données entre systèmes de CFAO différents
- Archiver des données homogènes et cohérentes pour une utilisation à moyen ou à long terme.
Utilisation du format SET.
Pour atteindre ces deux objectifs, on dispose alors des moyens suivants :
- Un langage neutre, le Standard d'Echange et de Transfert SET, destiné à traduire sous une forme standard les informations utilisées par tout système de CFAO et garantissant l'indépendance et la pérennité de ces données face à l'hétérogénéité des systèmes et à leur évolution dans le temps.
- Un certain nombre de logiciels appelés interfaces, capables d'assurer la traduction entre les bases de données des différents systèmes de CFAO et le langage neutre SET. Ces interfaces sont en général intégrées à chaque système de CFAO.
Il est néanmoins important de comprendre que lors d'échanges de données entre applications, il est en général impossible de communiquer l'intégralité des informations du fait des particularités propres à chaque système. En effet, même si un langage neutre tel que le SET couvre l'intégralité du domaine des données entre deux systèmes A et B, le domaine possible d'échange ne peut couvrir que les notions communes à ces deux systèmes ( See Domaine d'échange entre applications. ).
Domaine d'échange entre applications.
Ce besoin de définir un langage neutre d'échange de données entre systèmes de CFAO a donné naissance au niveau de l'Organisation International de Standardisation (ISO) au projet de norme PDES/STEP pour (Product Data Exchange Specification / STtandard for the Exchange of Product model) [STEP/PDES 91].
Le problème principal que présente cette approche, est qu'elle ne gère pas ou très mal la prise en compte de l'aspect concurrence de l'intégration. En effet, un fichier d'échange n'est en fait que la copie des données d'une application. Cette copie sera alors utilisée par un autre module qui la retransformera dans son propre format interne. A ce stade, il existe donc deux copies des données, chacune étant susceptible d'être mise à jour indépendamment de l'autre. On risque alors, soit d'écraser une de copie par une autre, soit, encore plus grave voir se multiplier des copies légèrement différentes de la même donnée et donc introduisant des incohérences dans le système. Une loi bien connue des informaticiens dit d'ailleurs que s'il existe deux copies identiques d'un même fichier, au moins une des deux est différente !
Ce problème de maintien global de la cohérence des données dans le système peut être résolu en centralisant les données dans une base de données commune, qui assurera qu'il n'existe qu'une seule copie "officielle" des données pour l'ensemble du système. Nous allons donc maintenant aborder plus en détail cette solution.
Intégration par utilisation d'une base de données
Un des moyens d'assurer la cohérence et l'intégrité des données dans un système de productique est de réunir toutes ces données dans une même base de données commune. Cette base de données contiendra l'ensemble des données devant être partagées entre les différentes applications du système, dont il est nécessaire d'assurer la cohérence. Chaque application continuera néanmoins à gérer elle-même les données qui lui sont propres, éventuellement dans une base de données locale. Un ensemble de procédures permettra de passer de ces données locales aux données globales de la base. Les données de la base globale seront toujours considérées comme étant les seules données valides et "officielles" au niveau du système productique dans son ensemble.
Cette approche résoud une partie des problèmes précédents.
· L'intégration est très bonne, efficace et la majorité des opérations de transfert et de stockage peuvent être automatisées.
· La mise en commun des données partagées dans une même base de données permet de résoudre théoriquement tous les problèmes de cohérence et d'utilisation concurrente des données puisque toutes les applications travaillent alors sur les même données. Dans la pratique, nous verrons que le contrôle des accès concurrents sur des données complexes reste un problème difficile, qui n'est pas résolu de manière complètement satisfaisante.
Cette approche est néanmoins plus difficile à mettre en uvre que la précédente.
· Elle nécessite des moyens informatiques complexes et bien intégrés : système de gestion de bases de données, interconnexion des machines par un même réseau.
· Elle demande une architecture informatique relativement homogène permettant à toutes les machines d'accéder à la base de données.
· Elle demande un gros travail d'analyse en vue d'identifier et de représenter l'ensemble des données devant être partagées entre les différentes applications. Cela nécessite de définir totalement l'ensemble de ces informations et de les modéliser (notion de modèle complet). Ce modèle peut alors avoir une taille importante ce qui en limite vite la compréhension.
· Le passage obligé par la base de données impose généralement d'apporter des modifications importantes aux structures et procédures existantes ce qui peut être très coûteux.
Enfin, cette approche ne permet pas de résoudre totalement les problèmes de synchronisation entre applications. En effet, si par exemple une application A dépend des données produites par une application B mais ne trouve pas ces données dans la base, elle ne peut pas continuer son calcul, car elle n'a aucun moyen d'obtenir directement ces données de l'application B.
A ce problème, il existe alors deux grands types de réponses.
Une première solution consiste à développer un logiciel spécifique qui aura pour rôle de coordonner et de piloter l'ensemble des applications du système productique. Cette solution est difficile à réaliser en raison de la complexité du système à piloter. Elle est surtout beaucoup trop rigide, car tout changement dans la configuration du système nécessitera immanquablement des modifications dans ce module de pilotage.
La seconde solution, et en fait la seule vraiment viable, est de non seulement définir les données utilisées par les différents modules du système, mais également de définir les différentes fonctionnalités offertes par ces modules. Tout comme les données, ces fonctionnalités seront alors accessibles par le biais d'interfaces procédurales, permettant ainsi de réaliser des communications entre applications. C'est cette solution que nous allons maintenant aborder.
Intégration par communications inter-applications
Une véritable intégration de tous les éléments du système productique consiste donc à considérer chaque application ou module faisant partie du système comme une entité autonome, possédant ses propres données et capable d'effectuer un certain nombre d'opérations sur ces données. La définition d'un certain nombre de ces données et opérations est alors rendue publique afin que d'autres applications puissent y faire appel. Les échanges entre applications se feront alors à l'aide de protocoles de communication réseaux de type messagerie ou appel de procédure à distance (Remote Procedure Call).
Intégration par communication entre applications.
C'est ce type d'approche que l'on trouve dans les travaux du CAM*I visant à définir une interface applicative générale pour les logiciels de CFAO. Cette interface appelée AIS pour Application Interface Spécification se veut une interface applicative virtuelle, rendant les applications indépendantes du système de CFAO sous-jacent [AIS 90]. Les développements d'AIS sont intimement liés aux développements de STEP/PDES, et utilisent le même formalisme objet basé sur le langage EXPRESS.
On retrouve également ce type d'approche dans un certain nombre de projets alliant l'utilisation conjointe d'un système expert et de logiciel de CFAO ou de code de calcul numérique pour résoudre des problèmes de conception.
Le projet ANAXAGORE
Ce projet [Trousse 89] est basé sur la coopération entre un outil de CAO et un modeleur virtuel (XCAD) pour l'aide à la conception de satellites. Le modèle permet de représenter des objets, qu'il est ensuite possible de visualiser en faisant coopérer XCAD avec un outil graphique de CAO.
Le projet EXPORT
Export est un système expert d'aide à la conception d'avant-ports réalisé au STCPMVN (Service Technique Central des Ports Maritimes et des Voies Navigables) [Monceyron 91]. Ce système s'applique tout particulièrement aux phases de faisabilité et d'avant projet sommaire d'implantation et de conception d'ouvrages portuaires. Dans ce domaine, le processus de conception fait traditionnellement intervenir un grand nombre d'experts devant intégrer et concilier des techniques diverses et des préoccupations souvent contradictoires.
Le système réalisé utilise conjointement des outils d'intelligence artificielle (le générateur de systèmes experts SMECI) et des techniques numériques plus classiques tels que code de calculs d'agitation intra-portuaire, ou code de calcul de transport de sédiments.
Le projet ARCHIX
Ce projet développé à la Régie Renault vise à fournir une aide à la conception de véhicules en phase d'avant projet [Thoraval et al 90], [Thoraval 91]. A partir d'éléments du cahier des charges (performances et dimensions du véhicule) et des caractéristiques techniques des organes mécaniques à employer, le système détermine l'assemblage de ces organes pour former le train avant du véhicule. Le projet est architecturé autour d'un générateur de systèmes experts SMECI, pilotant le logiciel de CAO EUCLID-IS. Celui-ci est essentiellement utilisé comme une ressource de calcul, chargé de déterminer les différentes positions possibles de l'ensemble du train avant, et par là même le débattement possible de celui-ci selon les différentes variantes étudiées. Le système Expert sélectionne certains paramètres de la géométrie du train et lance l'exécution du module de calcul d'EUCLID-IS. En fonction des résultats retournés, le système peut éventuellement réviser ses choix. Archix reproduit ainsi la démarche de conception qui procède par raffinements successifs et qui peut remettre en cause certains objectifs pris au cours de l'étude.
Utilisation de communication inter-applications à l'Aérospatiale
Pour étudier ce type d'architecture et en montrer la validité, nous avons été conduits à réaliser deux maquettes mettant en uvre des communications entre applications dans un environnement productique. Elles ont toutes deux utilisé une architecture informatique de type client/serveur. Dans ce type de système, une application (le client) fait appel à une ressource extérieure (le serveur), en lui envoyant des requêtes de haut niveau, via une interface de communication.
Une première maquette a permis de montrer la faisabilité d'une communication entre un logiciel de C.F.A.O. (en l'occurrence le logiciel CADDS4X de Computer Vision) et une base de données relationnelle (ORACLE d'Oracle Corporation), le tout en environnement hétérogène (CADDS4X sur Sun sous Unix et ORACLE sur VAX sous VMS) [Gaillard 90].
Les deux machines étant à même de communiquer par le protocole réseau TCP/IP cette maquette a été réalisée en utilisant le produit SQL*Net d'ORACLE [Oracle 89b]. Cette librairie permet en effet à une application cliente d'avoir accès aux données stockées sur un serveur de base de données ORACLE [Oracle 90].
Une seconde maquette a permis de réaliser une interface entre ce même logiciel CADDS4X, et une application fonctionnant dans un environnement Common LISP permettant ainsi de simuler les possibilités de pilotage d'un modeleur par un système expert [Gaillard 91]. Cette maquette a été réalisée en utilisant deux outils "standards" de l'UNIX de SUN.
Le premier outil offert par le système UNIX permet à un processus, d'appeler une procédure d'un autre processus, celui-ci pouvant être sur une machine différente. Ce service est désigné par le nom de RPC (pour Remote Procedure Call).
Les données pouvant ne pas être représentées en mémoire de la même façon entre 2 machines différentes (par exemple l'ordre des bits pour un entier sur SUN et sur VAX n'est pas le même), il est donc nécessaire de définir et d'utiliser un format de représentation externe neutre de données lorsque l'on veut échanger ces données par réseau. Ce format neutre est implanté par une librairie de fonctions : la librairie XDR (pour External Data Representation) [Sun 90].
Le prototype de serveur géométrique réalisé a été utilisé avec succès dans l'application de gestion des outils montés. Sa réalisation a néanmoins permi de soulever un certain nombre de problèmes qui ne sont à l'heure actuelle pas pris en compte par les protocoles de communication inter-process de type RPC. Ces problèmes concernent notamment la résistance aux pannes, et le maintient de la cohérence des données face à ces pannes.
Fonctionnement normal
Après connexion au serveur, le client fait un appel RPC, et le serveur lui renvoit le résultat de cet appel. Le client sait alors que sa requête a bien été exécutée au niveau du serveur.
Fonctionnement en cas de panne
Après connexion au serveur, le client fait un appel RPC, mais pour des raisons diverses (panne serveur, ou réseau) il ne reçoit pas de réponse à cet appel. En fait, plusieurs cas ont pu se présenter :
1) le serveur n'a pas reçu la requête
2) le serveur et tombé en panne durant l'exécution de la requête
3) le serveur a exécuté la requête, mais le client n'a pas reçu la réponse (problème réseau)
Le client ne recevant pas de réponse, il va en général tenter de se reconnecter au serveur, et de refaire le l'appel fautif. Le problème est que le client n'a aucune façon simple de savoir si la commande précédente a été ou non exécutée au niveau du serveur. Si la commande est un affichage, il n'est pas grave de le refaire. Par contre, si c'était une mise à jour d'une base de données, on risque de faire celle-ci deux fois, et donc de se retrouver avec des données incohérentes, ce qui est inacceptable.
Un certain nombre de propositions [Panzieri & Shrivastava 88], [Herlihy & McKendry 89] ont été faites pour résoudre tout ou partie de ces problèmes, mais aucun de ces protocoles n'a été implanté de façon industrielle. Cela nous amène tous naturellement à nous tourner vers les travaux existant dans le domaine des systèmes distribués.
Les systèmes distribués
Définitions
Un système informatique est dit réparti ou distribué lorsqu'il est constitué d'un ensemble de systèmes autonomes ou sites reliés par un réseau de communication. Chaque site possède ses propres ressources lui permettant d'exécuter des processus locaux.
Une application est dite repartie lorsque les processus participant à sa réalisation sont localisés sur plusieurs sites.
Un ensemble de processus peut participer à la réalisation d'une application ou d'une tâche commune. Ces processus peuvent être sur un même site ou sur plusieurs sites. C'est dans ce cadre, où les processus participants à une application peuvent être localisés sur un site quelconque, que l'on pourra parler d'application répartie. En l'absence de mémoire commune, le seul mécanisme qui leur permettra alors de coopérer est la communication par messages. Dans la plupart des cas, ne possédant ni organe de contrôle unique (horloge unique), ni de mémoire commune, de tels systèmes ou applications réparties sont caractérisés par l'absence d'un état global perceptible.
Un état global est défini par la connaissance de la réunion des états locaux (états des processus locaux) et de l'état des communications (les messages entre processus).
La répartition est une caractéristique inévitable pour de nombreux systèmes informatiques.
· Elle peut être rendue nécessaire par des contraintes géographiques qui rendent impossible de réaliser l'application comme une application centralisée unique du fait des temps de communication sur grandes distances, par des contraintes de capacité de traitement liées à la taille du système centralisé équivalent qui serait nécessaire, ou à des contraintes de disponibilité. C'est le cas des systèmes de bases de données réparties classiques (systèmes bancaires, systèmes de réservations ...).
· Elle peut être liée à un besoin d'ouverture naturelle des systèmes vers le monde extérieur dans l'objectif de communiquer, d'échanger des documents ou d'utiliser des services fournis par certains sites.
· Elle peut également être liée à l'évolution des applications qui peut nécessiter d'ajouter de nouveaux sites. Un site utilisera alors les services fournis par d'autres (émergence du modèle client serveur). Les applications industrielles sont assez représentatives des ces évolutions nombreuses et parfois disparates où il est pourtant nécessaire de faire communiquer des chaînes déjà automatisées avec de nouveaux îlots de production. C'est ce qui a par exemple motivé General Motors à normaliser une pile de protocoles d'échanges d'informations de type capteur actionneur appelé MAP (Manufacturing Automation Protocol). Dans le même état d'esprit, Boeing a normalisé un ensemble de protocoles pour les échanges en bureautique appelé TOP (Technical and Office Protocols).
Dans un autre domaine, les futurs systèmes d'exploitation tendent à être, non pas des systèmes centralisés, mais des systèmes constitués d'objets communiquant ou acteurs se déléguant des tâches. Ces objets ou acteurs peuvent alors migrer d'un site à un autre. Dans ce domaine, on peut citer les noyaux de systèmes tels que Chorus [Rozier et all 88], ou Nexus [Tripathi 89], qui tendent à cacher la localisation des processus.
Les différents modes de communication
Le mode point à point
A l'heure actuelle, les aspects bien maîtrisés et normalisés de la communication par messages sont l'échange point à point en environnement hétérogène et un certain niveau de fiabilité de ces échanges. Les modèles ISO, en définissant des normes de services et de protocoles, visent à résoudre le problème d'interconnexion de machines hétérogènes. Ils fournissent également les premiers éléments permettant de fiabiliser les échanges : la couche session par la définition de points de reprise, la couche application avec un module CCR (Commitment Concurrency and Redondancy) correspondant à un mécanisme de validation à deux phases (Two Phase Commit).
Le mode multipoint
Les besoins en échange de messages des systèmes ou applications distribuées sont très variés. On voit apparaître de nouveaux types de communication. En plus du classique mode point à point, il peut être nécessaire de disposer d'un mode multipoint. Dans ce mode, un processus émetteur peut envoyer un message à destination de plusieurs processus, éventuellement localisé sur des machines différentes. On parle aussi de diffusion d'un message vers un ensemble de processus. Le mode point à point peut alors être vu comme un cas particulier de ce mode multipoint.
Les protocoles normalisés et implantés concernent pour l'instant peu ce mode de communication. Bien que la plupart des réseaux sous-jacents offrent des possibilités de diffusion ou même d'émission multipoint, les protocoles et interfaces de services les prennent peu en compte. Parmi les réseaux locaux qui supportent naturellement la diffusion, on peut citer notamment Ethernet qui offre un adressage multipoint appelé "multicast".
Les besoins en terme de répartition poussent la communication par message à évoluer de plus en plus vers le mode multipoint, et il faudra donc à l'avenir considérer ce mode d'échange comme base pour la réalisation d'applications réparties.
Ordre des échanges
Les protocoles actuellement normalisés ne se préoccupent que du respect de l'ordre d'émission des messages sur une connexion point à point. Ce souci se retrouve à tous les niveaux du modèle OSI (Open Systems Interconnexion), aussi bien au niveau de la couche liaison avec un séquencement des trames émises, qu'au niveau de la couche application, en considérant un échange de bout en bout, où l'on souhaite respecter l'ordre d'émission des messages.
Avec l'émergence d'applications réellement réparties au sens ou une tâche peut être composée de plusieurs processus s'exécutant sur des machines différentes, ce respect de l'ordre local d'émission n'est alors plus suffisant. Si l'on souhaite que les applications aient le moins possible à se soucier de la répartition des traitements, il faut que les communications respectent d'autres types d'ordre qu'un simple ordre local.
En effet, des problèmes particuliers apparaissent lorsqu'on répartit les traitements, problèmes qui n'existent pas, ou sont implicitement résolus par le matériel en environnement centralisé.
L'exemple suivant, issu de la mise en uvre d'une application industrielle répartie dans un atelier, donne une idée des difficultés rencontrées.
Un processus P1 est chargé de contrôler une machine outil. Un second processus P2 pilote un robot manipulateur effectuant le chargement/déchargement de la machine outil.
Un processus superviseur SU, pour des raisons de sûreté de fonctionnement ou de cohérence, est chargé de vérifier que l'état des différents actionneurs est un état global cohérent.
Exemple d'incohérence dans une communication.
P1 envoie son état E1 (fin d'usinage) au superviseur SU et à P2. En retour, P2 envoie le nouvel état E2 (demande de déchargement) à P1 et à SU. Si ce système est construit sur un outil de communication de type MAP/MMS ne respectant que les ordres d'émission locaux, on peut alors se trouver dans l'état incohérent suivant : le superviseur SU peut recevoir l'état E2 (demande de déchargement) avant l'état E1 (fin d'usinage). Il détecte donc à son niveau un état incohérent alors que tout s'est en fait bien passé ( See Exemple d'incohérence dans une communication. ).
Il apparaît donc que le seul respect de l'ordre local d'émission sur une connexion point à point est insuffisant pour développer une application de ce type sans se préoccuper de la répartition.
Il existe deux types d'ordre supérieur à l'ordre local d'émission appelé respectivement ordre total et ordre causal dont le respect permet de pallier à ces difficultés dues à la répartition. Des protocoles permettant d'implanter des communications multipoint causalement et totalement ordonnées permettrait des résoudre ces problèmes applicatifs.
Tolérance aux pannes
Si une application dispose de communications causalement et totalement ordonnées, les seuls problèmes qui peuvent intervenir sont les pannes de processus, de sites ou de réseau.
Les systèmes informatiques utilisés dans les systèmes productiques comprennent couramment plusieurs calculateurs reliés entre eux par un réseau de communication. Ces systèmes ont été mis en place pour améliorer la circulation de l'information.
Ce dernier objectif ne doit pas induire une diminution du taux de disponibilité ce qui suppose l'existence de mécanismes assurant la résistance aux pannes.
Les mécanismes de résistance aux pannes ne sont pas triviaux dans les systèmes distribués. En effet, le contrôle des applications distribuées sur ces calculateurs est plus délicat que celui des applications centralisées. Les pannes des différents composants (réseau, processeurs, processus qui participent à l'application) introduisent un comportement asynchrone non-déterministe difficile à gérer.
Ces difficultés peuvent être résolues si le service de communication détecte les pannes de processus et avertissent les membres de la conversation qu'un participant est tombé en panne. Dans ce cas, il est souhaitable de disposer d'un service de communication qui détecte les pannes de processus et avertisse tous les membres de la conversation qu'un des participants est tombé en panne. Un tel service devra s'assurer que le processus déclaré en panne ne reçoit plus de messages. Il est également souhaitable qu'avant et après la détection de la panne, les messages soient fournis en respectant l'ordre causal et total pour que tous les processus restant en conversation gardent la même vue cohérente des échanges.
Pour résoudre ce type de problèmes, il existe des solutions originales à base de diffusion [Florin & Toinard 92]. Par exemple, dans le cas d'une application tolérant les pannes de plusieurs sites redondants, les actions à exécuter sont diffusées vers tous les sites redondants. Seul le processus primaire actif réalise l'opération souhaitée. Les processus secondaires passifs se contentent d'enregistrer l'opération afin de l'exécuter en cas de panne du primaire.
Les bases de données techniques
Quelle que soit la technique d'intégration choisie, et quelle que soit l'architecture, le volume et la complexité des données techniques à gérer et manipuler au sein d'un système productique font qu'il existe un besoin fondamental de gestion et de stockage de ces données : c'est le rôle de ce qu'on appelle les bases de données techniques. Une base de données techniques est le moyen de rassembler, de façon cohérente toutes les données techniques de l'entreprise qui doivent être partagées.
Comme nous l'avons vu, la gestion des données techniques passe tout d'abord par la définition d'un modèle de ces données (notion de modèle complet). C'est ce problème de la représentation des données techniques que nous allons aborder dans le Chapitre III consacrée à l'approche objet et à la représentation des connaissances.
Cette gestion des données techniques nécessite également la mise en place d'un outil pour être à même de gérer l'ensemble des données associées au modèle complet. Cet outil est alors désigné sous le terme de système de gestion de base de données techniques. Dans le Chapitre IV nous allons présenter un nouveau type d'outil permettant la gestion de ces données techniques : les bases de données orientées objets.