1 / 26

Ingénierie des Systèmes. Une illustration à travers le projet MIDCAS

Ingénierie des Systèmes. Une illustration à travers le projet MIDCAS. Julien Farjon - SAGEM 16 mai 2013. / 01 /. Sommaire. Sommaire. Introduction à l’ingénierie système Le projet MIDCAS Quelques exemples La filière ingénieur système chez SAGEM groupe SAFRAN.

brick
Télécharger la présentation

Ingénierie des Systèmes. Une illustration à travers le projet MIDCAS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Ingénierie des Systèmes. Une illustration à travers le projet MIDCAS Julien Farjon - SAGEM 16 mai 2013

  2. /01/ Sommaire Journées de l’UPSTI / 16 mai 2013 / DOD

  3. Sommaire • Introduction à l’ingénierie système • Le projet MIDCAS • Quelques exemples • La filière ingénieur système chez SAGEM groupe SAFRAN Journées de l’UPSTI / 16 mai 2013 / DOD

  4. Introduction à l’ingénierie système. /02/ Journées de l’UPSTI / 16 mai 2013 / DOD

  5. Introduction à l’ingénierie système complexité 1783 1903 1935 1974 2008 temps • Les origines de l’ingénierie système • Dans les années 60, principalement au sein du département de la défense américain, la NASA, afin de gérer les projets complexes: programme Apollo par exemple • Ces programmes se caractérisent par 2 axes de complexité: • Complexité technique, • Complexité organisationnelle. Journées de l’UPSTI / 16 mai 2013 / DOD

  6. Introduction à l’ingénierie système • C’est la gestion des exigences Pas uniquement • C’est du génie logiciel NON • C’est la même chose que le management de projet NON • C’est une méthode de résolution des problèmes complexes OUI • C’est la création technique architecturale d’ensemble pluridisciplinaires OUI • Tour d’horizon des idées reçues sur l’IS Journées de l’UPSTI / 16 mai 2013 / DOD

  7. Introduction à l’ingénierie système Ingénierie système : Démarche interdisciplinaire de transformation des besoins des clients (externe et interne), de ses exigences et de ses contraintes en constituants assemblés (intégrés) en un système, tout en assurant la justification, la validation et la vérification (V&V), la trace des choix et des compromis réalisés Quand la complexité d’intégration d’un système augmente, la capacité à gérer efficacement les interfaces produit & les interactions projet devient cruciale : ces nouveaux défis nécessitent donc d’utiliser de nouvelles méthodes Journées de l’UPSTI / 16 mai 2013 / DOD

  8. Introduction à l’ingénierie système • Une démarche pluridisciplinaire et structurée Besoin? Architecture du besoin Exigences Environnement? Architecture opérationnelle Sureté de Fonctionnement Fonction? Organisation/ optimisation? Architecture fonctionnelle Interface physique? Architecture organique / physique Optimisation? Conception? Process à réitérer si besoin Journées de l’UPSTI / 16 mai 2013 / DOD

  9. Introduction à l’ingénierie système France France Essais en vol Essais en vol Utilisation Réalisation Définition des besoins Spécification technique Définition détaillée Concept / architecture Maquette/conception produit • Couvre tous le cycle de vie d’un produit (exemple MIDCAS) Intégration Retrait Définition préliminaire Journées de l’UPSTI / 16 mai 2013 / DOD

  10. Introduction à l’ingénierie système: Méthodes et normes • Standards des organismes INCOSE ou AFIS • Créés à partir des années 90 • INCOSE: International Council on Systems Engineering • AFIS: Association Française d’Ingénierie Système • CESAMES: Centre d’Excellence sur l’Architecture, le Management et l’Economie des Systèmes. • IEEE 1220 • Définition du processus général Journées de l’UPSTI / 16 mai 2013 / DOD

  11. Introduction à l’ingénierie système: Méthodes et normes • Cycle en V – Cycle en spirale • Description des phases d’ingénierie • Validation / vérification • Validation: confirmation par des preuves tangibles que les exigences pour une utilisation spécifique ou une application prévue sont satisfaites • Vérification: confirmation par des preuves tangibles que les exigences spécifiées ont été satisfaites. Journées de l’UPSTI / 16 mai 2013 / DOD

  12. Le projet MIDCAS. /03/ Pour personnaliser le pied de page, rendez vous dans le menu « Insertion / Numéro de diapositive », personnalisez le pied de page et validez par « Appliquer partout » Journées de l’UPSTI / 16 mai 2013 / DOD

  13. Le projet MIDCAS • Contexte et enjeux • Les drones sont de plus en plus utilisés dans la Défense, et le seront demain dans le Civil. • L’un des défis majeurs est leur capacité à s’intégrer dans l’espace non ségrégué. • La fonction primordiale est l’évitement de collision avec un autre avion : le pilote, seul responsable sur un aéronef habité, ne peut pas exercer cette fonction depuis le sol dans le cas du drone. Drones "Détecter & Eviter" “Detect & Avoid" Aviation Habitée "Voir & Eviter" "See & Avoid" Journées de l’UPSTI / 16 mai 2013 / DOD

  14. Le projet MIDCAS • But du projet: définir un système d’évitement de collision (air-air) pour drone, ainsi que les bases du standard associé, permettant leur insertion dans l’espace aérien général, • Projet Européen • 50 M€ sous contrat EDA Cat B, • 5 Nations, 11 industries, • Leadership Suède, • Projet initié par la France (Industries et DGA) Journées de l’UPSTI / 16 mai 2013 / DOD

  15. Le projet MIDCAS • Projet articulé autour de 4 composantes: • L’étude de la fonction ‘générique’ du système d’évitement • Le support à la définition du standard de cette fonction • La validation de cette fonction par la simulation • La réalisation d’un démonstrateur Journées de l’UPSTI / 16 mai 2013 / DOD

  16. le projet MIDCAS • Justification de l’intérêt de l’approche système • Environnement complexe: Système de drone, autres utilisateurs de l’espace aérien, Contrôle aérien, système d’anticollision existant • Pluridisciplinaires: plusieurs technologies de capteurs, algorithme, Interfaces homme machine, contrôle du vol … Nécessaire d’avoir une compréhension globale et une démarche structurée Journées de l’UPSTI / 16 mai 2013 / DOD

  17. Quelques exemples. /04/ Journées de l’UPSTI / 16 mai 2013 / DOD

  18. Déclinaison des exigences: de l’identification du besoin aux spécifications détaillées • Déclinaison des exigences client: HLTR et CONOPS • CONOPS (Concept Of Operation):illustration des interactions avec l’environnement extérieur au système, définition du concept opérationnel. • Exigences de haut niveau : HLTR (High Level Technical Requirements). Exigences de haut niveau formulées par le client • HLTR • Exigences opérationnelles • Exigences fonctionnelles • Exigences de performance • Exigences de sécurité • Exigences de maintenance • Exigences d’interface • … Journées de l’UPSTI / 16 mai 2013 / DOD

  19. Déclinaison des exigences: de l’identification du besoin aux spécifications détaillées • Définition des exigences système • Analyse fonctionnelle  définition des fonctions & interactions • Avec l’environnement extérieur (analyse fonctionnelle externe) • Aux sous fonctions (analyse fonctionnelle interne) • Estimation des performances • Utilisation de simulations « préliminaires »: performances des sous systèmes • Allocation des performances aux sous systèmes Journées de l’UPSTI / 16 mai 2013 / DOD

  20. Déclinaison des exigences: de l’identification du besoin aux spécifications détaillées • Estimation des performances des sous systèmes. • Allocation performance de détection, manœuvrabilité: compromis complexité capteurs, performance de l’évitement. Allocation aux fonctions SENSE et AVOID • Simulations performances de vol • Estimation performances capteurs Journées de l’UPSTI / 16 mai 2013 / DOD

  21. Déclinaison des exigences: de l’identification du besoin aux spécifications détaillées • Estimation des performances des sous systèmes. • Pour la plateforme (RPAS): vitesse minimale, taux de virage, pente, précision centrale d’attitude et de navigation… • Pour la fonction de détection: Distance et probabilité de détection, taux de fausse alarme, précisions de mesures (distances, vitesses, angles..) • Pour la fonction évitement: algorithme, exigences guidage, filtrages des mesures… • Puis design des sous systèmes et composants. • Le processus précédent est reproduit autant de fois que nécessaire • Appel aux experts métiers: technologies capteurs et techniques de fusion par exemple • Fusion capteurs: filtrage de Kalman • Capteurs: infrarouge, électro-optique, radar, interrogateur de transpondeur Coordinates in meters Journées de l’UPSTI / 16 mai 2013 / DOD

  22. Déclinaison des exigences: définition des exigences de sécurité • Définition des objectifs de sécurité: Une des problématique est de définir le niveau de sécurité que doit apporter le dispositif d’évitement. • Exigence de haut niveau: ne pas dégrader le niveau de sécurité actuel de l’aviation pilotée • Prise en compte des différents participants à l’objectif de sécurité  définition exigence système évitement • Cet objectif va fixer les principales caractéristiques et performances attendues du système • Plusieurs approches sont proposées mais en final le niveau de sécurité, ainsi que ses déclinaisons aux composants du système, doivent être validés et acceptés par tous Journées de l’UPSTI / 16 mai 2013 / DOD

  23. Validation et vérification des exigences: les exigences de sécurité • La validité des simulations doit être garantie par l’utilisation de modèles certifiés : • De traffic aérien : Exemple European Encounter Model • De systèmes existants: TCAS • Mais aussi de sous-systèmes : capteurs, …, • On estime alors le risk ratio : rapport entre le niveau de sécurité obtenu en intégrant le nouveau dispositif et le niveau d’origine. Scenario database IR sensor fusion radar sensor avoid coop sensor intruder model TCAS intruder model RPAS model • Dans MIDCAS, la principale difficulté est la validation du niveau de sécurité spécifié au système • Le niveau de sécurité apporté par le nouveau dispositif ne peut être vérifié qu’en simulation compte tenu des faibles probabilités recherchées. Journées de l’UPSTI / 16 mai 2013 / DOD

  24. Validation et vérification des exigences : capteurs • Exemples: essais détection par capteur Infrarouge • Exploitation des résultats • Recalage des modèles • Au niveau système, les simulations et essais permettent de vérifier que les performances spécifiées aux sous ensembles permettent de satisfaire les exigences système, • Au niveau composant, les simulations et essais permettent de vérifier que le produit vérifie bien les specifications Journées de l’UPSTI / 16 mai 2013 / DOD

  25. La filière Ingénieur Système chez SAGEM / SAFRAN. /05/ Journées de l’UPSTI / 16 mai 2013 / DOD

  26. la filière ingénierie Système Une démarche au niveau du groupe SAFRAN (dont SAGEM est une filiale). • Les axes majeurs de progression dans la filière sont : • la connaissance du produit dans un contexte multi métiers, du système de plus haut niveau dans lequel il est intégré • la compétence ingénierie système Journées de l’UPSTI / 16 mai 2013 / DOD

More Related