EUROCOPTER SAS Groupe EADS

Chapurla

Description

Niveau: Supérieur
EUROCOPTER SAS Groupe EADS Marignane Ecole des Mines d'Alès Laboratoire de Génie Informatique et d'Ingénierie de Production LGI2P – Nîmes Proposition de sujet de thèse CIFRE – EUROCOPTER / LGI2P Titre Contribution à l'amélioration de l'outillage conceptuel, méthodologique et technique pour la formalisation et la vérification des exigences dans la démarche MBSE : application aux systèmes aéronautiques Domaine Le sujet de recherche proposé concerne l'Ingénierie Système (IS) et plus particulièrement le Model Based Systems Engineering (MBSE). Il s'intéresse aux processus d'ingénierie et d'analyse des exigences, de vérification et de validation. Le domaine d'application concerne l'ingénierie de systèmes aéronautiques. Mots-clés Ingénierie Système, ingénierie des exigences, MBSE, vérification, exigence, règles métier, sémantique, formalisation, propriété, model checking, theorem proving, graph analysis, système complexe, système aéronautique Contexte de la thèse Ce projet de recherche sera soutenu par une bourse de thèse de type CIFRE financée conjointement par la société EUROCOPTER (Groupe EADS) et l'ANRT. Il sera encadré par le LGI2P (Laboratoire de Génie Informatique et d'Ingénierie de Production, basé à Nîmes) de l'ENSMA (Ecole Nationale Supérieure des Mines d'Alès). Les travaux prévus s'inscrivent dans la suite logique des travaux entrepris au sein de l'équipe ISOE (Ingénierie de Systèmes complexes et d'Organisations Interopérables) du LGI2P.

• processus d'ingénierie et d'analyse des exigences, de vérification et de validation


• ingénierie des exigences


• résultante


• exigence


• outil


• lgi2p titre

Sujets

• École des Mines
• Eurocopter
• Resultante
• Exigence

Informations

• Publié par: profil-nechor-2012
• Nombre de lectures: 193
• Langue: Français

Extrait

EUROCOPTER SASEcole des Mines d’Alès Groupe EADSLaboratoire de Génie Informatique et Marignane d’Ingénieriede Production LGI2P – Nîmes Proposition de sujet de thèse CIFRE – EUROCOPTER / LGI2P Titre Contribution à l’amélioration de l’outillage conceptuel, méthodologique et technique pour la formalisation et la vérification des exigences dans la démarche MBSE : application aux systèmes aéronautiques Domaine Le sujet de recherche proposé concerne l’Ingénierie Système (IS) et plus particulièrement le Model Based Systems Engineering (MBSE). Il s’intéresse aux processus d’ingénierie et d’analyse des exigences, de vérification et de validation. Le domaine d’application concerne l’ingénierie de systèmes aéronautiques. Mots-clés Ingénierie Système, ingénierie des exigences, MBSE, vérification, exigence, règles métier, sémantique, formalisation, propriété, model checking, theorem proving, graph analysis, système complexe, système aéronautique Contexte de la thèse Ce projet de recherche sera soutenu par une bourse de thèse de type CIFRE financée conjointement par la société EUROCOPTER (Groupe EADS) et l’ANRT. Il sera encadré par le LGI2P (Laboratoire de Génie Informatique et d’Ingénierie de Production, basé à Nîmes) de l’ENSMA (Ecole Nationale Supérieure des Mines d’Alès). Les travaux prévus s’inscrivent dans la suite logique des travaux entrepris au sein de l’équipe ISOE (Ingénierie de Systèmes complexes et d’Organisations Interopérables) du LGI2P. Problématique de la thèse Pour Eurocopter, concepteur et producteur d’hélicoptères et de services, les parties prenantes d’un projet de conception d’un nouvel hélicoptère peuvent être décomposées classiquement en reprenant certains concepts de base de l’Ingénierie Système. Il s’agit de :  Clients (customer) souhaitant disposer d’un système hélicoptère clef en main et éventuellement de toute une série de services correspondants (aide au financement sous forme locative, maintenance, livraison, …)

1  Systèmes contributeurs (enabling systems) qui se décomposent en acteur internes à Eurocopter (équipes et départements chargés de la conception, de la production, …) et en acteurs externes à Eurocopter (fournisseurs de rang 1, 2 ou plus, sous-traitant). Parmi les acteurs internes, certains doivent assurer la relation client/Eurocopter. Ils sont ainsi appelés à jouer tout ou partie du rôle de Maître d’Ouvrage (MOA). D’autres assurent les rôles de Maitre d’Œuvre (MOE) en s’occupant de la conception et du développement puis de la production du futur hélicoptère. Acteurs internes et externes appartiennent généralement à des équipes différentes et sont de métiers différents. Systèmes à l’interface (interactive systems) qui vont devoir cohabiter et inter opérer  avec le futur système hélicoptère au cours de son cycle de vie. Ils doivent donc exprimer des attentes ou des contraintes vis-à-vis du système hélicoptère de sa conception jusqu’à son retrait de service voire sa réutilisation totale ou partielle. Chaque projet suppose alors évidemment un travail et des processus collaboratifs dans lesquels chacune de ces parties prenantes devra s’impliquer. Nous nous focalisons ici sur une vision plus ou moins standardisée des processus de l’Ingénierie Système (ISO 15288) ou de bonnes pratiques (ARG, …). Il s’agit des processus d’ingénierie des exigences (stakeholders’ needs and requirements design process), de vérification (verification process) et de validation (validation process) des architectures fonctionnelles et organiques résultantes du processus de conception des architectures (architectural design process). Dans ces processus, nous nous intéressons particulièrement aux tâches suivantes :  Le MOA doitsusciter, capter, décrire et valider les besoins du client et de toutes les parties prenantes (internes et externes de l’entreprise) concernées par le système hélicoptère. L’objectif est ici, soit de contribuer au maintien en conditions opérationnelles de ce système, soit de pouvoir s’interfacer avec lui tout au long de sa vie afin de lui permettre de remplir sa mission. Toutes les parties prenantes sont généralement représentées par des acteurs opérationnels exprimant des points de vue et des besoins voire des avis différents (besoins opérationnels, de performances, de sécurité, de sûreté, de compatibilité technique à un standard, de validation, …) en utilisant leur propre langage métier. Le MOA doit donc gérer plusieurs vocabulaires et leur sémantique respective. Il doit mettre en œuvre diverses approches pour capter (diagramme pieuvre, carte mentale, interview guidée, approche outillée graphiquement telle que KAOS, …) puis formuler (au moyen d’outils et de standards tels que SBVR, URN, BRL, CMU, …) en utilisant des langages tels que SysML qui est aujourd’hui fortement pressenti dans le milieu industriel. Chaque partie prenante doit donc pouvoir comprendre, s’assurer de la cohérence, de la pertinence et ainsi valider l’ensemble de ses besoins avec les besoins des autres parties prenantes. Le but est de former ce que l’on appelle dans la suite unréférentiel des besoins.  Le MOE doit ensuite, avec le MOA, traduire ces besoins sous forme d’exigences qui sont alors regroupées de manière cohérente dans unréférentiel d’exigences. Ce MOE utilise pour cela diverses méthodes (KAOS, CMU, référentiels standardisés d’exigences, PDC(A), approche REGAL, …) voire des outils de gestion d’exigences (tels que DOORS). L’objectif pour lui est de communiquer avec le MOA et de fixer le travail de conception et de développement dans lequel le MOE, et donc l’organisation qu’il représente (une

1 Les notes en Anglais et en italique sont empruntées à la norme ISO 15288 : Systems Engineering, version 2008

équipe, une entreprise, un sous-traitant ou plusieurs entreprises en réseau), doit s’engager. Un nouveau langage métier, différent des langages utilisés par les parties prenantes pour exprimer leurs besoins est alors nécessaire. Il est adapté à l’ingénierie des exigences et repose dans un premier temps sur les concepts de l’Ingénierie Système.  Le MOE dispose alors d’unréférentiel d’exigencesou moins formellement validé plus possédant ainsi une réelle valeur ajoutée (fiabilité, pertinence, complétude relative du modèle des exigences) pour les concepteurs. Le MOE, de fait maintenant considéré comme un possible architecte du système hélicoptère à concevoir, va maintenant chercher à guider et à valider la conception. Pour cela, chaque exigence doit être déclinée pour être compréhensible sans ambiguïté par chacun des acteurs métier de la conception lorsqu’il élabore des modèles (mécanique, hydraulique, ergonomique, de vol, de simulation, …). Chaque métier se voit alors doté d’un langage dédié pour l’expression des exigences. Ce langage existe déjà souvent et est connu. Il est lui-même une extension du langage métier de l’IS défini plus haut. Il est basé sur les concepts métier pertinents mais ne dispose pas nécessairement des liens sémantiques avec des concepts par exemple homonymes, synonymes, etc. d’autres domaines métier. Le but est donc ici de définir et de formaliser comment raffiner puis décliner chaque exigence du référentiel des exigences en exigences métiers en assurant la cohérence, la gestion et la traçabilité des éléments du référentiel des exigences pour tous les acteurs impliqués. Par gestion, on entend ici toutes les actions de diffusion, de propagation d’information et de décision qui font suite généralement à : · Toute modification du référentiel des exigences (ajout d’une nouvelle exigence, suppression, modification totale ou partielle des paramètres d’une exigence) · Toute remontée d’information des métiers vers le MOE (non faisabilité technique d’une exigence, remise en cause de tout ou partie d’une exigence, performance réellement atteinte sur une exigence, information de coût ou de pertinence, …) · Une mesure d’impact sur le référentiel d’exigence suite à la modification plus ou moins profonde d’une exigence · La détection de défauts ou d’erreurs dans le cadre de la politique de traçabilité des exigences.  En parallèle, MOA et MOE doivent, tout au long de ces tâches, vérifier et valider la bonne traduction des besoins métiers sous forme d’exigences compréhensibles, faisables, vérifiables, exprimées sans ambigüité, … utilisables alors par les acteurs métier dépendant du MOE (architectes systèmes de navigation, de propulsion, habitat, sécurité, …) pour concevoir et développer le produit hélicoptère souhaité. Il faut donc disposer de mécanismes permettant de vérifier que les modèles établis à tous les niveaux sont : Bien construits: on s’intéressera alors à la vérification d’exigences dites de · modélisation qui traduisent des règles, bonnes pratiques ou patterns de modélisation classiquement employés par l’entreprise. Respectent les attentes des parties prenanteson s’intéressera alors à la : · vérification des exigences du référentiel précédent (stakeholder’s requirements) que l’on baptisera alorsexigences système. Elles peuvent être fonctionnelles auquel cas la technique de vérification pourrait être une technique de preuve formelle de type model checking ou theorem proving. Elles peuvent être non fonctionnelles. La

vérification consistera alors à trouver des modes d’évaluation des critères retenus dans l’exigence (safety, security, interoperability, ergonomy, …) actuellement rassemblées sous le terme de «i-lities». Respectent les connaissances et règles métiers classiquementadmises mais · souvent volontairement ou involontairement omises du référentiel des exigences. On s’intéressera alors à la vérification d’exigences ditesaxiomatiques et métier. Objectif du travail de recherche L’objectif de ce travail de recherche est d’améliorer la boîte à outils conceptuelle, méthodologique et technique dont disposent les acteurs MOA et MOE pourspécifier et mettre en œuvre uneméthode de passage des besoins aux exigences (ingénierie des exigences) et d’analyse des exigences (vérification et validation).Le langage SysML pourrait être mis en avant durant cette étude comme préconisé dans le projet MASICES (Modélisation Avancée et Simulation pour l’Ingénierie Collaborative de Systèmes). L’objectif est ainsi de conférer à SysML une vision méthodologique et une sémantique plus formelle et outillée faisant défaut dans sa configuration actuelle. Dans l’absolu, définir une méthode signifie ici spécifier, formaliser, développer puis validerin situ: Les concepts de besoin, d’exigence et de transformation besoin/exigence,  Les modèles et les langages de modélisation d’un besoin et d’une exigence,   Les processus opératoires décrivant les étapes permettant de mener à bien une telle ingénierie,  Les outils supports. Appliquée dans le cadre d’Eurocopter, cette méthode vise à :  Pouvoir utiliser simultanément plusieurs langages métiers liés par des relations d’enrichissement conceptuels (sémantique), de conformité et de cohérence. Le but est de formaliser et de développer un système permettant de gérer ces langages et de lever certaines ambiguïtés sémantiques et syntaxiques dans l’expression des besoins des parties prenantes.  Assister la transformation duréférentiel des besoinsun enréférentiel d’exigences possédant les qualités de base de toute exigence (clarté, non ambiguïté, lisibilité, vérifiabilité, non redondance, …) et les qualités de base d’un tel référentiel (relative exhaustivité, cohérence et non contradiction, degré de détail adéquat au regard du système à réaliser, …). Cette transformation sera basée sur la transformation à la fois d’un modèle de besoin à un modèle d’exigence devant être développé et validé pour les besoins d’Eurocopter, la transformation des langages métiers dédiés à un langage formel de description d’exigence compréhensible par le MOE, et de langages métiers de conception.  S’assurer que les exigences ont bien été prises en compte à toutes les étapes de la conception architecturale par les MOE, qu’il s’agisse d’acteurs internes à Eurocopter ou externesi.e. desous-traitant ou de fournisseur de rang 1 à 3. Pour cela, il faut développer l’approche conceptuelle, méthodologique et les outils techniques permettant de vérifier ou d’évaluer les exigences, selon leur type, sur chacun des modèles d’architecture proposés. Il est proposé ici de développer un langage de

propriétés permettant de raffiner les exigences sous forme d’un ensemble de clauses prouvables au moyen d’outils de model checking, de theorem proving ou de simulation existant ou à créer, ou au moyen d’outil d’évaluation de critères de type «i-lities». Des outillages méthodologiques et techniques doivent compléter permettre de valider la démarche dans le cas de la conception d’un hélicoptère. Ces outillages devront être conçus de manière à être complètement interopérables conceptuellement et techniquement avec les outils servant à la modélisation système puis aux développements et aux réalisations (SysML au niveau système et d’autres langages métier plus spécifiques sont à prendre en compte). Activités et tâches Ce travail de recherche va donc se décomposer en tâches comme suit : Etude bibliographique: ingénierie des besoins et des exigences de systèmes  complexes, modélisation et analyse d’exigences, de propriétés, techniques formelles de preuve, approches formelles de spécification (Z, B, NIAM-ORM, …), approches de construction de règles sémantiques (standards SBVR, GRL, URN, …), bonnes pratiques (REGAL, …), de modèles des buts et des besoins (KAOS, UCM, …).  Développer un système support pour l’élaboration de langages de modélisation métier des besoins et des exigencesen s’inspirant des standards tels que SBVR et GRL. L’objectif est de définir des langages au vocabulaire limité mais suffisant, sémantiquement sans ambigüité, totalement interopérables sémantiquement parlant et possédant un pendant formel pour décrire et faire le lien entre les besoins d’une partie prenante exprimés dans son domaine et les exigences d’un MOE exprimés dans un autre domaine métier propre à Eurocopter. Un référentiel de besoins ‘génériques’ donc réutilisables en fonction du type de système hélicoptère pourrait être élaboré au cours de ce travail au titre d’outil méthodologique pour simplifier le travail du MOA.  Développer la méthodologie de formalisation et de vérification des exigences définies alors sous forme de propriétés. Il est proposé de s’appuyer ici sur le modèle et le langage des besoins et des exigences définis plus haut, la notion de référentiel d’exigences proposée dans les normes d’ingénierie système (ISO 15288, AERO, …), le modèle de propriété CREDI et le référentiel de propriétés développés au sein de l’équipe ISOE du LGI2P dans le cadre du langage LUSP (Langage Unifié de Spécification de Propriétés).  Vérification et validation: il est proposé de spécifier et développer informatiquement de manière à les rendre complémentaires et interopérables plusieurs techniques et outils de model checking, de theorem proving, de simulation et d’évaluation nécessaires pour s’assurer que les modèles respectent bien les exigences de modélisation et les exigences système. L’objectif est de donner la possibilité de passer rapidement de l’une à l’autre et de profiter ainsi pleinement de leurs complémentarités en termes de couverture de preuve et d’évaluation. Formaliser la démarche méthodologiquerésultante pour  · Analyser, capter et décrire progressivement et sans ambiguïté puis de vérifier/valider les besoins d’une partie prenante. Traduire ces besoins sous forme d’exigences prouvables ou évaluables. ·

Prouver et analyser ces exigences et assurer / argumenter les retours des résultats · de preuve / évaluation vers les acteurs chargés de la conception des architectures. Outiller globalement: un démonstrateur doit permettre de valider les résultats in situ  du projet de recherche sur un cas précis de conception chez Eurocopter.

Candidature Le (la) candidat(e) doit être issu(e) : ème ème  d'un Master II Recherche relevant de la 61section ou de la 27section, ou,  d’un diplôme d’ingénieur reconnu par l’Ecole Doctorale I2S de l’Université Montpellier II et permettant d’attester d’une expérience significative prouvée en recherche. Le (la) candidat(e), devra faire parvenirpar courrier électronique avant le 30 Juillet 2012à : -M. Jean-Marc Quiot,Eurocopter, ETZR, Responsable Mission system & Research (tél : [phone] [e-mail]) -M. Vincent CHAPURLAT,Professeur, responsable équipe ISOE(tél : [phone], [e-mail]) les pièces suivantes : Un CV détaillé.  Une lettre de motivation décrivant l’intérêt et les souhaits du candidat au regard du  domaine et du sujet proposés.  Une liste des expériences significatives permettant, en particulier, d’attester de l’expérience en recherche, de la richesse de références et de l’autonomie du candidat.  Une ou plusieurs lettres de recommandation sous plis cacheté des responsables du stage recherche ou de son équivalent.  La copie des diplômes et des attestations attestant du niveau de formation du (de la) candidat(e).  Les résultats et le classement dans les parties théoriques et pratiques du Master Recherche ou de son équivalent.  Le rapport de stage du Master Recherche ou de son équivalent.  Les coordonnées du ou des responsables de ce stage. Une entrevue entre le (la) candidat(e) et les parties prenantes de ce projet de recherche sera organisée très rapidement. Pour cela, le (la) candidat(e) devra :  Préparer et présenter durant 30 mn les travaux ayant fait l’objet du rapport de stage demandé. S’impliquer dans un ensemble d’exercices visant à tester ses capacités et compétences  en termes de rédaction, de formulation et d’argumentation des verrous scientifiques et/ou techniques relatifs au projet de recherche. Le travail de recherche devrait pouvoir débuter le plus rapidement possible.