La conception collaborative multidisciplinaire de systèmes intégrés 

Ce chapitre décrit le contexte dans lequel les travaux présentés dans ce manuscrit ont été menés. Ces travaux portent sur la conception multidisciplinaire de systèmes intégrés. Cette thématique, très vaste, est précisée grâce à différentes définitions proposées dans ce chapitre. Ainsi, la conception de systèmes intégrés est définie grâce à différents types d’intégration pour le produit avant de caractériser la conception intégrée, les enjeux liés au travail collaboratif et la notion de multidisciplinarité. Enfin, une illustration de ces enjeux sur le cas des produits dits mécatroniques est proposée, basée sur les singularités de ces derniers.

La conception de systèmes intégrés 

Un nombre d’exigences toujours croissant 

Les produits industriels développés de nos jours sont de plus en complexes et ils doivent répondre à un nombre croissant d’exigences. Une exigence est définie par l’Association Française d’Ingénierie Système (AFIS1 ) et reprise par Badreau et Boulanger comme « quelque chose qui prescrit ce qu’un produit doit faire, avec quelles performances et sous quelles conditions, pour atteindre un but donné » (Badreau and Boulanger, 2014). Dans ce manuscrit, nous regroupons les exigences liées à un produit en trois catégories que nous intitulons « exigences intrinsèques », « exigences extrinsèques » et « exigences liées à la chaîne de valeur ». Ces différentes catégories sont proposées afin d’enrichir les définitions proposées par l’AFIS qui ne considèrent généralement que les exigences liées aux fonctions attendues du système, l’environnement extérieur au système étant considéré comme un ensemble de contraintes auquel il est nécessaire de prêter attention.

La première catégorie d’exigences fait référence aux qualités intrinsèques du produit. Les exigences rassemblées dans cette catégorie sont qualifiées d’«exigences fonctionnelles » par l’AFIS. Ainsi, l’ajout de nouvelles fonctionnalités à un produit, la réduction de son encombrement ou de son poids, l’augmentation de sa fiabilité se traduisent par un resserrement des niveaux d’exigences à prendre en considération lors de la conception du produit et des éventuels services associés.

La seconde catégorie d’exigences est liée à l’intégration du produit dans son environnement. En effet, le fait que les produits soient de plus en plus communiquant, qu’ils doivent s’inscrire dans une logique de développement durable, etc. induit également un grand nombre d’exigences à respecter. Une partie des exigences liées à cette catégorie correspond au terme « contrainte d’environnement» proposé par l’AFIS.

Enfin, une dernière catégorie d’exigences est liée à la chaîne de la valeur associée au produit, ou à une famille de produits. En effet, les différentes activités qui participent à la création de la valeur totale doivent être maîtrisées et les exigences ne doivent donc pas uniquement être associées aux phases d’élaboration du produit. Les coûts de maintenance en conditions opérationnelles, d’infrastructure pour assurer les services liés au produit, etc. sont autant d’exemples permettant de mieux comprendre les activités devant être prises en considération. Une partie des exigences liées à cette catégorie correspond au terme « exigence non fonctionnelle» proposé par l’AFIS.

Bien que les travaux décrits dans ce manuscrit se focalisent sur la conception de systèmes, la prise en considération de l’ensemble des phases du cycle de vie du produit est primordiale et l’ensemble des exigences de ces trois catégories peuvent se référer à l’une ou à plusieurs phases du cycle de vie.

Les différents types d’intégration dans le cadre de la conception de systèmes 

L’intégration relative au produit
Parmi les trois catégories d’exigences présentées ci-avant, les exigences dites intrinsèques ont une importance prédominante sur la conception du produit. Elles ont en effet un impact fort sur les intégrations dites fonctionnelle et spatiale. « Functional integration consists in incorporating as many functions as possible in a single product, either by combining many functions into one component or by dematerialization of certain functions by using information technology » (Warniez et al., 2012).

L’intégration relative aux activités d’ingénierie et aux disciplines
Les différents types d’intégration relative au produit présentés dans la section précédente sont également la source d’une complexité organisationnelle. Ils nécessitent un fort niveau de collaboration induisant une complexité organisationnelle provenant à la fois de la multitude d’acteurs, mais également de la diversité des domaines impliqués. Dans ce manuscrit, nous parlons d’intégration multidisciplinaire pour décrire ce type d’intégration.

La notion d’« integrated design », définie comme « the coordinated development effort in timing and substance of the various disciplines and organizational functions that span the life-cycle of new products and services » (Ettlie, 1997), correspond à cette coordination des contributions de chacun des domaines et de chacune des activités d’ingénierie. À l’origine, la notion d’intégration en conception faisait notamment référence à « l’aspect participatif des différents corps de métiers au moment de la conception » et au fait de « prendre en compte au plus tôt des besoins des hommes de métiers qui vont avoir à confectionner le produit, le maintenir ou le détruire » (Tichkiewitch, 1994). Les deux autres notions liées à l’intégration en conception également proposées par Tichkiewitch sont la prise en considération du cycle de vie du produit et des contraintes liées à l’environnement « social » et « physique » du produit.

La conception intégrée a donc, par l’aspect coordination des contributions, de nombreux points communs avec la notion d’ingénierie simultanée, qui est définie comme le « way of work where the various engineering activities in the product and production development process are integrated and performed as much as possible in parallel rather than in sequence» (Sohlenius, 1992).

Table des matières

STRUCTURE DE LA THÈSE 
CHAPITRE 1 La conception collaborative multidisciplinaire de systèmes intégrés 
1.1 Contexte
1.1.1 La conception de systèmes intégrés
1.1.1.1 Un nombre d’exigences toujours croissant
1.1.1.2 Les différents types d’intégration dans le cadre de la conception de systèmes ..
1.1.1.3 Les processus de développement de produit
1.1.2 La conception de systèmes intégrés : les systèmes mécatroniques
1.1.2.1 Une évolution des produits électromécaniques vers des systèmes mécatroniques
1.1.2.2 La conception intégrée appliquée à la mécatronique
1.1.2.3 Modèles de processus de développement spécialisés pour la mécatronique
1.1.3 Cadres généraux traitant de la conception collaborative multidisciplinaire de systèmes intégrés
1.1.3.1 Le Product Lifecycle Management
1.1.3.2 L’ingénierie système
1.1.3.3 La cybernétique et les Cyber–Physical Systems
1.1.3.4 L’Application Lifecycle Management
1.2 Synthèse de la mise en contexte, problématique et objectifs
1.2.1 Synthèse de la mise en contexte
1.2.2 Analyse critique et problématique
1.2.3 Objectifs
1.2.4 Origines des travaux
1.2.5 Hypothèse
1.2.6 La méthodologie
CHAPITRE 2 État de l’art 
2.1 Organisation de l’état de l’art
2.1.1 1er facteur de positionnement : le type de contribution
2.1.2 2ème facteur de positionnement : le niveau de gestion et de prise de décision
2.2 Positionnement et état de l’art associé
2.2.1 Les approches model
2.2.1.1 Core Product Model (CPM)
2.2.1.2 Produit, Processus et Organisation (PPO)
2.2.1.3 Intégration par les outils d’édition grâce aux standards
2.2.1.4 Synthèse des approches model
2.2.2 Les approches view
2.2.2.1 Environnements supports à l’ingénierie collaborative synchrone à distance
2.2.2.2 Synthèse des approches view
2.2.3 Les approches controller
2.2.3.1 Modèles de processus
2.2.3.2 Implémentations techniques des modèles de processus
2.2.3.3 Méthodes agiles
2.2.3.4 Synthèse des approches controller
2.2.4 Synthèse des approches model, view et controller pour la conception de systèmes et intérêt d’une approche hybride model / controller
2.2.4.1 Synthèse des approches model, view et controller pour la conception de systèmes
2.2.4.2 D’une approche model vers une approche hybride model/controller
2.3 Synthèse de l’état de l’art
CHAPITRE 3 Proposition
3.1 Collaborative Actions Framework
3.1.1 Descriptions
3.1.1.1 Action collaborative
3.1.1.2 Collaborative Actions Framework
3.1.2 Mise en œuvre & apports
3.1.2.1 Action collaborative
3.1.2.2 Collaborative Actions Framework
3.1.3 Synthèse : le Collaborative Actions Framework support des méthodes agiles
3.2 Workspaces
3.2.1 Description
3.2.1.1 Prérequis nécessaires au fonctionnement des workspaces
3.2.1.2 Principes de structuration pour des données multidisciplinaires
3.2.1.3 Organisation des workspaces et principes d’échanges
3.2.2 Le rôle des workspaces pour la mise en œuvre des principes des méthodes agiles
3.2.2.1 La traçabilité, ou le lien Produit/Organisation
3.2.2.2 La mise en commun permanente des travaux
3.2.2.3 L’intégration multidisciplinaire
3.2.2.4 La promotion et la collecte comme processus de validation
3.2.3 Synthèse : les workspaces supports des méthodes agiles
3.3 Branch & Merge
3.3.1 Gestion du changement et mécanismes de contrôle des versions : des logiques différentes entre les domaines HW et SW
3.3.2 Des outils essentiels pour supporter le branch & merge : le diff et le 3- way merge
3.3.2.1 L’origine du branch & merge : des modifications fréquentes pouvant être réalisées par des développeurs différents
3.3.2.2 Description des opérations de création de branche et de fusion de branches
3.3.2.3 Lien entre graphe de versions et intentions de conception
3.3.2.4 L’apport des outils de « diff » et de « merge »
3.3.3 Généralisation du branch & merge à l’ensemble des disciplines
3.3.3.1 Illustration du branch & merge appliqués au domaine de la mécanique
3.3.3.2 3-way merge de documents et modèles structurés: les perspectives pour des outils métier
3.3.4 Synthèse : le branch and merge support des méthodes agiles
3.4 Synthèse de la proposition
CHAPITRE 4 Mise en œuvre d’une méthode agile pour la conception collaborative multidisciplinaire : application à la mécatronique 
4.1 Un scénario mécatronique permettant d’illustrer les apports de chacun des concepts
4.1.1 Un produit mécatronique : le bras de robot
4.1.2 Un scénario regroupant une évolution du produit et une modification
4.1.3 Deux actions collaboratives pour ces deux projets
4.1.4 Une structure de WS basée sur ces demandes d’actions collaboratives
4.1.5 Déroulement temporel du scénario
4.1.6 Déroulement de l’action collaborative liée à l’opération de maintenance
4.1.7 Déroulement de l’action collaborative liée à l’évolution du système de freinage
4.1.8 Deux versions du bras de robot concurrentes
4.1.9 Une fusion des deux versions concurrentes grâce à un outil de fusion adapté
4.1.10 Des informations ajoutées successivement par les différents acteurs : le cas de l’action de maintenance
4.1.11 Synthèse concernant ce scénario
4.2 Un prototype basé sur JIRA et SVN
4.2.1 Présentation des deux solutions commerciales retenues
4.2.1.1 JIRA : le gestionnaire d’incidents
4.2.1.2 SVN : le gestionnaire de versions
4.2.2 Paramétrage des solutions et déroulement du scénario
4.2.3 Synthèse concernant le prototype
4.3 Synthèse relative à la mise en œuvre d’une méthode agile pour la conception collaborative multidisciplinaire
CHAPITRE 5 Conclusion

Télécharger le rapport complet