• Aucun résultat trouvé

Propositions - Contributions

3.7 Contributions à destination des industriels

La contribution présentée dans cette section va au-delà du cadre de la définition de la méthode de conception d’une plateforme de cosimulation. Elle met en avant des

Figure 3.24 – Extrait du Méta-mo dèle MOISE de l’espace de l’arc hitecte de sim ulation

ments importants pour l’industrialisation. Ces éléments permettent de prendre en compte l’environnement de cette plateforme tant pour les aspects techniques que pour les aspects administratifs, contractuels et de sécurité.

Ces sections ont vocation à lister de manière non exhaustive de potentiels problèmes sous forme de questions. Bien évidemment, il appartiendra aux futurs acteurs de trouver les réponses les plus adéquates, en fonction du sens qu’ils veulent donner à cette entreprise étendue et en fonction de leur culture d’entreprise respective.

3.7.1 Clauses de confidentialité

En premier lieu et suivant la pratique usuelle dans l’industrie, il est souhaitable de signer des clauses de confidentialités entre les partenaires initiateurs de cette entreprise étendue. Cela permettra plus aisément de traiter et contractualiser, en amont du projet, ces deux points essentiels : a) Quelles formes juridique et fonctionnelle l’entreprise étendue doit-elle prendre ? b) Comment gérer la propriété intellectuelle issue des travaux de l’entreprise étendue, ou connexe à ces travaux ?

Il est possible d’avoir une première piste de réflexion, en se basant sur le contenu du pa-ragraphe 2.5 qui liste des organisations de base pour l’entreprise étendue. Toutefois, choisir l’une de ces typologies, ou plus possiblement une composition de celles-ci implique une organisation fonctionnelle et juridique. Or, suivant l’organisation juridique choisie, celle-ci peut contraindre les droits sur la gestion et la répartition de la valeur ajoutée de la propriété intellectuelle, et donc la réponse à la deuxième question. Obtenir la cohérence d’ensemble : fonctionnelle et juridique, oblige certainement à un processus itératif de décisions collégiales entre partenaires, dans un esprit « gagnant-gagnant ».

3.7.2 La propriété intellectuelle, entreprise entrante/sortante

Les acteurs, fondateurs de l’entreprise étendue, comme les futures entreprises entrantes, peuvent apporter leurs savoir-faire sous forme documentaire, logicielle, matérielle, de bre-vet, ou encore de compétences. Ces apports initiaux souvent appelés « backgroung IP » doivent faire l’objet d’une mention explicite et d’une évaluation de leur valeur, pour déter-miner la contribution de chacun. Quels sont les critères à prendre en compte pour évaluer ces contributions ? Pour cette question, une des possibilités est de s’appuyer sur une struc-ture extérieure spécialisée dans la PI [Jea12].

Pour les brevets entrants, au sein de l’EE, un partenaire peut accorder une licence d’exploitation. Sur quelle durée, pour quel coût ? La licence d’exploitation est-elle

conta-minante ? Sa simple utilisation implique-t-elle que tout élément associé à l’objet de cette licence devient la propriété de son auteur ?

Pour une entreprise entrante en cours de projet, quelle part peut-elle prétendre sur la valorisation et l’exploitation de la PI produite, en fin de projet ? La même question se pose pour une entreprise sortante en cours de projet. D’après [Jea12], il existe des outils de type

workflow qui « permettent de gérer les étapes relatives à la PI en fonction des phases de

la collaboration ». C’est une aide possible pour répondre à cette question.

Que se passe-t-il si un partenaire quitte l’entreprise étendue en cours de projet (par exemple, cessation d’activité, ou bien renoncement) ? Que deviennent ses contributions et résultats, vis-à-vis des autres partenaires ? Dans le cadre de cette thèse, que deviennent les modèles de niveau système ? Idem pour les modèles de simulation de ce partenaire ? Plusieurs possibilités :

a) le modèle est un code binaire exécutable. Le partenaire reverse cet exécutable à l’entre-prise étendue, à quel coût ? En cas de défaut, faut-il prévoir une clause de maintenance, dès le début du projet ?

b) l’exécution du modèle fait appel à un logiciel développé en interne, chez ce partenaire. Doit-il fournir ce logiciel pour exécuter son modèle, au risque de devoir dévoiler une partie importante de son savoir-faire, et à quel coût ?

Comment se répartir les droits d’exploitation entre partenaires, sur une PI produite en marge de ce même projet, et sur quelle durée ?

Si des résultats ne peuvent faire l’objet d’une PI, peuvent-ils être diffusés à l’extérieur de cette entreprise étendue, sous quelles conditions ?

3.7.3 Exigences centrées sur les servitudes

Les servitudes d’une plateforme de simulation concernent aussi bien les besoins pour les personnes, comme pour les unités d’exécution. Par exemple, dans les locaux et pour les personnes, il faut prévoir, tant pour respecter la loi que pour le confort de celles-ci : une protection incendie, une aération, un éclairage suffisant, une régulation de température, des points d’eau, la téléphonie et toutes autres fonctions nécessaires à la préservation des personnes. Pour l’aspect matériel, les alimentations électriques, des points d’accès réseaux sont indispensables. Les moyens de protection contre les intrusions, suivant le contexte, sont à considérer.

3.8 Conclusion

Ce chapitre a précisé et défini deux grandes lignes pour faire de la simulation, un processus de vérification et validation des fonctionnalités d’un produit.

L’exécution d’une simulation en entreprise étendue s’appuie sur des plateformes de simulation, situées au sein de chaque entreprise. La proposition aborde la définition de cette plateforme de simulation sous l’angle de l’ingénierie système, basée modèle. De cette étude, il en découle une liste d’exigences, la définition d’acteurs et de leurs rôles, une architecture fonctionnelle et physique. Après factorisation des éléments de cette étude, il en ressort une l’architecture fonctionnelle, qui peut être considérée comme architecture de référence pour l’ensemble des plateformes de simulation de l’entreprise étendue. Avec un autre regard, il a été possible de créer un métamodèle qui agrège les concepts issus de l’analyse de la couche fonctionnelle et de la couche physique. Cette dernière abstraction sera utilisée dans la section suivante (section 3.4) lors l’instanciation de la méthode.

La deuxième grande ligne pour faire de la simulation a été de définir une méthode qui prenne en considération à la fois les acteurs, l’ingénierie système du produit comme point de départ pour arriver à la simulation sur la plateforme de cosimulation en entreprise étendue, tout en assurant la traçabilité des exigences. Cette méthode peut s’appliquer à chaque étape de la conception du produit (couches expression du besoin, fonctionnelle, ou encore, la couche physique). Elle est la « pierre angulaire » de cette intégration de la simulation, pour la vérification & validation, au plus tôt de la conception du produit. Elle s’appuie sur les abstractions de la plateforme de simulation, précédemment étudiées.

Le retour d’expérience précieux de l’équipe MOISE pour la simulation, avec la mise en place du point de vue Capella, permet d’avoir une souplesse quant à la sélection des éléments utiles à la simulation. Si la méthode développée dans cette proposition est cohé-rente, ce retour permet de prendre en compte les diversités de travail, d’expériences des architectes système pour le produit, en offrant la possibilité aux architectes système pour la simulation, de pouvoir ajuster au mieux, leur architecture de simulation.

Enfin, si certains éléments de réflexion, quant à la constitution d’une plateforme de simulation, n’entrent pas directement dans l’objet de cette thèse, il semble utile de les conserver comme possibles contributions pour les industriels. Cela concerne les clauses de confidentialités, la propriété intellectuelle et les exigences centrées sur les servitudes associées aux plateformes de simulation.

Le chapitre 4 suivant aborde la validation de la méthode proposée dans cette thèse, sur le cas concret développé par l’équipe MOISE : le drone AIDA. Plus spécifiquement, cette validation s’appuie sur les fonctionnalités associées au pilotage automatique de ce drone.

Chapitre 4