Soutenance mémoire
Historique de l’ingénierie système
L’IS trouve son origine au cours de la seconde guerre mondiale. Durant cette période de l’histoire se conjuguent une progression rapide des technologies et une demande forte de systèmes aptes à faire face aux enjeux majeurs militaires et politiques.
Ainsi, on peut situer les premiers efforts d’IS, ou de réflexions quant à l’approche et aux techniques aptes à satisfaire aux enjeux techniques et organisationnels que posent le développement, la production et le maintien en opération de systèmes complexes aux années 1940. Le terme ingénierie système apparait alors pour la première fois dans le cadre des travaux du laboratoire Bell et du projet Nike. Nike constitue à sa livraison, en 1953, le premier système de défense de l’espace aérien destiné à l’armée américaine. La vitesse et l’altitude de vol des avions, nouvellement équipés de moteur à réaction, rendaient les moyens de défenses inefficaces. L’enjeu d’un développement tel que celui du système Nike était alors d’intégrer un ensemble d’équipement complexe de détection, de commande et de guidage de missiles rapides.
L’enjeu majeur de l’effort d’ingénierie de ce système est de contrôler et maîtriser les propriétés et les caractéristiques locales du système complexe, en maîtrisant les effets induits par les interactions de chacun de ces constituants. Auparavant, plusieurs organisations avaient eu recours implicitement a une approche système, sans l’avoir définie clairement comme une activité en tant que telle. L’IS va, à partir des années 1950, concerner les grands systèmes impliquant de nouvelles technologies et des êtres humains, et jouant un rôle important face aux enjeux militaires ou de sécurité.
Dans le contexte historique de la guerre froide, le système de défense anti-aérien SAGEADS (Semi-Automatic Ground Environment – Air Defense System), initié et développé par le MIT entre les années 1955 et 1960, a modernisé le système de surveillance et de défense de l’espace aérien américain, et a fait évoluer l’IS par son approche d’intégration système à grande échelle. En particulier, le système reposait sur l’intégration des technologies RADAR et des capacités informatiques au sein d’un système complexe, réparti entre des éléments centraux informatiques et des unités de détection RADAR, utilisant le réseau téléphonique comme moyen de communication. L’ensemble du système devait, par ailleurs, respecter des contraintes temporelles fortes liées à sa mission de protection de l’espace aérien.
L’intégration de ces technologies récentes dans une approche système a, par ailleurs, contribué au développement du système de contrôle de trafic aérien civil, et à l’intégration au niveau national des dispositifs de commandement, de contrôle et de communication des systèmes militaires. Par la suite, deux grandes institutions américaines, l’USAF et le DoD ont tenté, dans les années 1960, de mieux maîtriser la complexité de leurs programmes militaires et d’exploration spatiale au travers de pratiques industrielles plus rationnelles et standardisées. Les invariants dans les activités à mener et les points communs dans les méthodes appliquées sur divers projets à grandes échelles les ont menées à définir des processus tels que le processus SIMILAR [Bah_05], à définir des normes et des standards et à capitaliser les bonnes pratiques.
Arthur Hall, alors ingénieur chez AT&T et acteur majeur du domaine de l’IS, publie en 1962 A methodology for engineering of systems [Hal_62], et pose les premières pierres des éléments actuels de l’IS :
– spécification des exigences au niveau système,
– gestion des interfaces,
– respect de jalons de développement,
– gestion du changement,
– techniques d’analyse de compromis et de prise de décisions.
Ces techniques se développent et sont adoptées progressivement dans les industries développant des grands systèmes. En 1969, le standard militaire Mil-Std 499 [MIL_69], constitue la première norme regroupant les bonnes pratiques de l’IS. La norme a alors pour objectif de permettre au gouvernement d’évaluer objectivement la compétence en IS de ses sous-traitants potentiels, et charge ces derniers d’améliorer leurs pratiques de l’IS et de la conduite de l’effort d’ingénierie tout au long d’un développement. En 1990, la National Council on Systems Engineering (NCOSE), premier organisme mondial d’ingénierie des systèmes, est créée à l’initiative d’un grand nombre d’entreprises américaines. Le NCOSE a alors pour mission d’améliorer et de fédérer l’utilisation et la diffusion, notamment par l’enseignement, des pratiques en ingénierie des systèmes : processus techniques, processus de management, méthodes et outils. La NCOSE est devenu officiellement une organisation internationale, l’INCOSE, en 1995. Elle est aujourd’hui l’organisation principale de la communauté de l’IS, devenue une discipline à part entière. Divers organismes nationaux, tels l’Association Française d’IS (AFIS), sont partenaires de l’INCOSE et permettent aux grandes entreprises industrielles de mener des réflexions et des travaux communs sur les différents aspects de l’IS. Conjointement aux travaux de l’INCOSE, l’institut des ingénieurs en électricité et électronique (IEEE), et l’Alliance des Industries de l’Electronique (EIA), un regroupement d’entreprises américaines dans le domaine des hautes technologies, ont défini des processus d’IS génériques sous la forme de normes. Ces normes modernisent, complètent et élargissent le périmètre d’application du standard MIL-499, bien qu’elles en reprennent aussi de nombreux éléments. Les grandes organisations telles que le département de la défense américaine (DoD), la NASA [NAS_95] ou le Centre National d’Etudes Spatiales (CNES) ont aussi développé leur propres standards d’IS.
Une date importante de l’histoire de l’IS est l’année 1994. Les Etats-Unis mènent alors une politique de réduction des dépenses de l’armée américaine, et des initiatives sont engagées afin de rationnaliser l’utilisation des standards militaires pour le développement, la production et le maintien en opération des matériels militaires [Perr_94]. Déconseillant l’usage de la plupart des standards militaires, alors trop contraignants, trop coûteux, et trop nombreux (plus de 30.000 standards sont alors en service), le secrétaire de la défense préconise l’utilisation systématique de la norme IEEE1220 [IEE_99] comme standard de référence d’IS, applicable, en particulier, pour guider l’activité d’acquisition du matériel ainsi que des standards industriels tels l’ISO9000. Cette décision marque un pas significatif dans l’adoption des techniques d’IS par de grandes institutions. L’ingénierie des systèmes est alors vue comme une discipline à part entière et incontournable dans le développement des grands systèmes et des systèmes complexes.
Ingénierie Système: problématique industrielle
L’IS est une discipline vaste et implique plusieurs domaines. Cette section précise le périmètre de l’IS tel qu’il est traité dans ce document. Le travail de cette thèse porte sur l’ingénierie des systèmes aéronautiques, en particulier sur le développement des équipements et systèmes comportant une partie mécanique, une partie électronique et une partie logicielle. La partie mécanique peut ou non comporter des éléments dynamiques et des actionneurs de nature électromécanique, pneumatiques, hydraulique ou basé sur toute autre technologie. Les parties électroniques et logicielle concernent principalement des éléments calculateurs, des moyens de communications et d’informations simples ou complexes.
Complexité liée aux processus
Le développement d’un produit est intrinsèquement un processus interdisciplinaire nécessitant l’implication de différents métiers. Dans ce contexte, l’ingénierie simultanée est mise en œuvre pour réduire le temps de développement et prendre en compte au plus tôt les activités et également les moyens à mettre en œuvre tout au long du développement du système (moyens logistiques, de production, de support client, etc.). Les contraintes de sécurité associées nécessitent que les processus employés pendant le développement se conforment au processus standard de développement des systèmes aéronautique ARP4754 [ARP_96], incluant des analyses et des évaluations de sécurité. Le développement des sous ensembles électroniques et logiciels doivent se conformer respectivement aux exigences de processus des DO254 [DO_00] et DO178B [DO_92]. De plus, les processus utilisés pour le développement au niveau système doivent se conformer aux exigences de processus du client. Ces exigences concernent, en particulier, la gestion des exigences, la gestion de configuration, le contrôle des évolutions des phases de spécification, de conception, d’intégration, de validation, de vérification et de qualification. Pour chacun de ces aspects, les moyens à mettre en œuvre et les résultats attendus peuvent faire l’objet d’exigences spécifiques. Le développement actuel est articulé autour d’un système documentaire qui structure les étapes et le déroulement des activités du développement. La maîtrise de la réalisation des processus de l’entreprise appliqués dans le cadre d’un projet spécifique est un facteur principal de réussite ou d’échec du projet.
|
Table des matières
CHAPITRE 1. INTRODUCTION GENERALE
CHAPITRE 2. PRESENTATION DE L’INGENIERIE SYSTEME
2.1. Historique de l’ingénierie système
2.2. Ingénierie Système: problématique industrielle
2.2.1. Complexité liée aux processus
2.2.2. Complexité liée au produit
2.2.3. Complexité liée à la performance système
2.2.4. Complexité liée au réseau d’acteurs projet
2.2.5. Complexité liée aux coûts et délais
2.2.6. Cohérence globale et décisions : problématique industrielle de l’ingénierie système
2.2.7. Questionnaire pratique
2.3. Système, conception système et IS
2.3.1. Systèmes
2.3.2. La conception système
2.3.3. L’ingénierie système
2.4. Principes généraux de l’ingénierie système
2.5. Processus et normes d’ingénierie système
2.5.1. Introduction : Processus et cycles de vie
2.5.2. Cycles de vie de l’ingénierie système
2.5.3. Définition d’un processus
2.5.4. Normes d’ingénierie système
2.5.5. La norme EIA 632
2.5.6. Les normes IEEE 1220 et ISO 15288
2.6. Conclusion
CHAPITRE 3. L’INGENIERIE SYSTEME BASEE SUR LES MODELES
3.1. Modèles pour l’ingénierie système
3.1.1. Différents rôles de modèles d’ingénierie systèmes
3.1.2. Modèle cognitifs
3.1.3. Modèle normatifs
3.1.4. Modèles prédictifs
3.2. SysML : un langage de modélisation unifié pour l’ingénierie système
3.2.1. SysML Pour la modélisation des exigences
3.2.2. SysML pour la modélisation de structures
3.2.3. SysML pour la modélisation du comportement
3.2.4. SysML pour la modélisation paramétrique
3.2.5. Faiblesses et améliorations attendues du langage SysML
3.3. Méthodes et outils d’IS basée sur les modèles
3.3.1. Evoluer vers les méthodes d’IS basées sur les modèles
3.3.2. Méthodologies d’ingénierie système basées sur les modèles
3.4. Problématique liée à l’interopérabilité des modèles
3.4.1. Travaux sur l’interopérabilité des modèles en IS
3.4.2. Modèle de données d’ingénierie système AFIS
3.5. Conclusion
CHAPITRE 4. METHODOLOGIE POUR L’INGENIERIE DE CONCEPTION CONJOINTE DE SYSTEMES AERONAUTIQUES (MICCSA)
4.1. Contexte et description de la méthodologie
4.1.1. Contexte de la méthodologie et points spécifiques
4.1.2. Structure et organisation
4.2. Modèle d’informations de la méthodologie
4.2.1. Description générale du modèle d’informations
4.2.2. Principaux éléments du modèle
4.2.3. Eléments support des activités d’Analyse et de V&V
4.3. Application des modèles dans la méthodologie
4.3.1. Organisation du modèle et points de vues
4.3.2. Propriétés des modèles
4.3.3. Ingénierie des modèles et vérification des propriétés
4.3.4. Ingénierie des modèles et application de patrons de modélisation
4.3.5. Constitution des vues d’ingénierie système
4.4. Instanciation du modèle d’ingénierie système
4.4.1. Processus d’ingénierie système
4.4.2. Evolution du modèle, référentiels et jalons de projets
4.4.3. Opérations d’ingénierie des modèles de la méthodologie
4.5. Conclusion
CHAPITRE 5. MODELES ET APPLICATION DE LA METHODOLOGIE MICCSA
5.1. Cas d’étude : système porte passagers
5.1.1. Exigences sources
5.1.2. Eléments principaux du système porte passagers
5.2. Profil SysML adapté à la méthodologie
5.2.1. Démarche de spécialisation de SysML à la méthodologie
5.2.2. Organisation du modèle du projet
5.2.3. Modélisation des exigences projet
5.2.4. Modélisation de l’architecture opérationnelle
5.2.5. Modélisation des architectures logique et physique
5.2.6. Modélisation pour les vues validation et comparaison d’architectures
5.3. Utilisation de VHDL-AMS
5.3.1. Mécanisme d’instanciation de composants
5.3.2. Spécificités du profil SysML pour la modélisation des systèmes conservatifs
5.4. Mise en œuvre de la méthodologie dans un environnement Eclipse
5.4.1. Vérification des propriétés sur les modèles
5.4.2. Transformation des modèles SysML
5.5. Conclusion
CHAPITRE 6. CONCLUSION GENERALE
