chapitre2

Approche système pour la conception innovante des portes d’avions
Chapitre 1. Introduction Générale

Afin de consolider sa position de leader mondial de fabricant de portes d’avions
commerciaux, la société LATECOERE a engagé en 2006 un programme d’étude et
technologie devant déboucher sur un démonstrateur de portes innovantes destinées aux avions
de futures générations. La porte nouvelle génération devra intégrer des évolutions
technologiques dans sa structure et ses équipements au sein d’une architecture optimisée.
Souhaitant s’appuyer sur les méthodologies et outils de pointe dans le domaine de la

conception et la simulation des systèmes, LATECOERE a engagé une collaboration
recherche-industrie avec le LAAS dans un projet commun de recherche. Ce projet de
recherche consiste à développer et valider une méthodologie nouvelle de conception d’un
système porte permettant de garantir le respect des exigences du client et des autorités de
certification avec un produit performant et compétitif.
Le contexte des travaux de recherche, objets de ce mémoire, est ainsi celui de la

démarche de Conception Système. Dans nombre d’entreprises, les objectifs de productivité et
de réduction des délais ont incité les chercheurs et ingénieurs à faire émerger des démarches
descendantes de conception qui s’appuient sur des représentations virtuelles du système avant
de décider de son intégration matérielle. Sur cette base, le LAAS et la Société LATECOERE
ont établit une collaboration sous forme d'un projet afin de lever certains verrous
technologiques que pose cette démarche globalement descendante. La stratégie de
collaboration entre l'entreprise et le laboratoire concerne la conception système, depuis
l'écriture des spécifications jusqu'à une représentation virtuelle du produit: prototypage virtuel
dont les composantes sont des représentations de la réalité physique, matérielle et logicielle.
Le travail de cette thèse concerne la démarche conceptuelle comportant les étapes suivantes:
a) L'écriture des spécifications conformément au standard des métiers et aux exigences

des méthodes et outils.
b) L'élaboration de plusieurs architectures systèmes et leur modélisation logique haut

niveau
c) La validation et la vérification de la modélisation par rapport aux spécifications.
d) Le choix des architectures systèmes répondant au mieux, à la fois, aux exigences

réglementaires/clients et aux technologies des composants du système.
Le cadre méthodologique est celui de l'Ingénierie Système, des processus afférents et

des exigences et normes spécifiques aux systèmes avioniques en général et au système à
concevoir en particulier (GRESS, ABD 200, EIA632).
9
Ainsi les objectifs de ces travaux s’inscrivent dans une démarche globalement
descendante de conception qui s’appuie sur des représentations virtuelles du système avant de
décider de son intégration matérielle. Sur cette base, une première ambition de modélisation
est d’aboutir à plusieurs représentations virtuelles et complètes du système, placées dans son
environnement d’utilisation. Sur la base des connaissances et des pratiques actuelles, ces
représentations virtuelles sont réalisées par le couplage de modèles nombreux et hétérogènes.
Cette approche fait appel à la modélisation multi-niveaux pour exprimer, dans un même
domaine disciplinaire, la hiérarchie des modèles possibles entre la modélisation physique, la
modélisation comportementale et la modélisation système. Elle fait également appel à la
modélisation multi-modèles pour exprimer le caractère pluridisciplinaire des systèmes,
impliquant d’élaborer des modèles hétérogènes complémentaires qui sont ensuite associés
dans la simulation globale.
Un objectif fort de nos travaux de recherche est de déterminer les solutions d’architecture
système répondant aux différentes exigences élaborées en début du projet, démarche dite top-
down. Le cadre et le contexte industriels exigent également que soient considérées les
solutions technologiques de types composants systèmes, solutions émanant de travaux
antérieurs ou parallèles, et donc de démarches de type bottom-up, afin d’établir plusieurs
architectures et d’opérer des choix circonstanciés.
Il n’existe pas une méthodologie universellement reconnue répondant à une telle

problématique. Il existe des méthodologies plus ou moins dédiées. Celles-ci s'appuient
essentiellement sur un cahier des charges ad-hoc et considèrent rarement un cahier des
charges à construire. Les premières exigences de l’approche à développer consistaient ainsi à
dégager de l'expertise de l'entreprise et de ses métiers autour du système à concevoir :
a) des spécifications qui expriment les besoins fonctionnels et les exigences

fonctionnelles et non fonctionnelles,
b) une approche regroupant méthode, modèles et outils pour assurer, ce qu'il est
convenu d'appeler en Ingénierie Système (IS), l'Ingénierie des Exigences ( IE -
maîtrise des évolutions, de la volatilité, des incohérences, … des besoins et des
exigences),
c) une modélisation du système à concevoir dans un cadre MDA (Model Driven

Architecture),
d) un prototypage virtuel du système permettant, en association avec l’évaluation

formelle des modèles, une première évaluation des performances des
architectures étudiées ; le tout permettant d’effectuer certains choix
relativement tôt dans le cycle de vie du système.
Un autre objectif fort du projet était qu’il débouche sur une plateforme de conception
système qui permettrait aux ingénieurs de l'entreprise de procéder à des tests systèmes et
d'évaluer les approches, les méthodes et les outils. Cette plateforme serait le siège de
recommandations opérationnelles : spécifications, évaluation de performances,
dimensionnement, test par simulation et co-simulation, définition du domaine de validité,
mise en place de procédures de tolérance (analyse de sensibilité, allocation de tolérances,
etc.). L’approche à étudier devait se fonder sur les propriétés permettant d'exploiter les liens
10
qui peuvent être instaurés dans une modélisation multi-niveaux. Pour le système à concevoir,
une telle modélisation s'étend depuis les matériaux jusqu'au système lui-même ainsi que
depuis les spécifications jusqu'au prototypage virtuel.
Concernant les spécifications, un verrou technologique à lever concernait l'élicitation et la

modélisation des exigences. Leur catégorisation en termes d'exigences fonctionnelles et
d'exigences non fonctionnelles (principalement de sécurité) permet une modélisation dès les
premières phases du cycle de vie du système. Le point de départ du sujet est donc le cahier
des charges où se retrouvent toutes les spécifications, contraintes et exigences. Le travail de
thèse consistait d’abord à tirer du cahier des charges les éléments d’une formalisation en
fonction de la dite catégorisation.
A priori, le support envisagé pour la représentation du système et de ses abstractions était,

entre autres, le langage SysML en cours de standardisation. Les aspects V&V (Validation et
Vérification) allaient imposer rapidement l'extension de ce langage vers des notations
formelles. SysML étant un langage et non une méthode, cette extension, support ou profil
devait également être définie et adaptée à la construction d’une démarche de description pas à
pas conduisant à une formalisation en des éléments du langage. Cette formalisation pouvait
être directe ou se faire par couplage au sein d'une plateforme du laboratoire en cours de
développement ; l’intérêt de la plate-forme réside dans la facilité des couplages des outils de
simulation tels que Matlab-simulink, VHDL-AMS, systemsC ou autres.
Une autre approche consiste à envisager la plateforme autour d'Eclipse en intégrant les
produits du marché s'appuyant sur SysML et l’EIA632 comme démarche d’intégration.
L'approche envisagée serait exploitée et orientée suivant deux objectifs essentiels:
- la traçabilité pré et post ; la frontière se situe entre les phases d’élaboration des
exigences jusqu’à leur adoption et à partir de leur adoption jusqu’à leur mise en
œuvre; la traçabilité au plus haut niveau concerne, elle, toute la partie gestion des
exigences,
- la vérification, pour laquelle sont envisagées des méthodes nouvelles: vérification de

cohérence des différents points de vue le plus tôt possible dès le début de la
formalisation.
La suite de la démarche se focaliserait sur l’implémentation de processus de vérifications

fondés sur la simulation et la co-simulation. Elle bénéficierait largement de l'expertise et des
outils de la communauté, du laboratoire et de l'entreprise afin de:
- proposer une architecture système, basée MDA, faite de composants réutilisables pour
modéliser des objets physiques comportant du matériel et du logiciel. Ce
partitionnement doit répondre à des critères fonctionnels et non fonctionnels qu’il
convient de définir et de mettre en œuvre. Cette architecture contribuerait ainsi au
couplage des méta-modèles, des simulateurs et des outils existants.
- spécifier des composants dans la perspective d’un appel d’offre du maître d’ouvrage à
destination de ses fournisseurs. Les outils de représentation généraux et de vérification
associés continueront à jouer un rôle d’arbitres de cette étape.
11
Enfin, ce travail devait s’inscrire à chaque étape d'un processus de référence global et
intégrer des outils et des méthodes de vérification créés à partir d’approches formelles et de
simulations partielles et globales.
Ce sont tous ces objectifs que nous avons tenté d’atteindre pendant cette thèse dont les
travaux sont décrits dans ce mémoire. Ainsi, la méthodologie que nous avons définie, est
destinée à proposer au groupe LATECOERE un moyen de progresser dans son aptitude à
développer des systèmes aéronautiques répondant aux attentes de ses clients, et de manière
optimale face aux contraintes industrielles du domaine de l’aéronautique et spécifiques à
l’entreprise. Elle propose, en particulier, une méthode adaptée au type de produit
spécifique à cette entreprise, dont la particularité et de mêler étroitement des éléments
de structure aux éléments plus traditionnellement associés au domaine système :
composants, calculateurs et cartes électroniques embarquant du logiciel. Enfin, la mise
en place d’une telle méthodologie doit permettre de rendre son activité plus profitable,
d’accroitre les compétences du groupe en tant qu’acteur majeur de l’industrie aéronautique et
de gagner de nouveaux marchés.
L’approche Ingénierie Système (IS) peut être vue comme un moyen de maitriser la
complexité tout en assurant les objectifs fixés. Elle permet, par un ensemble de bonnes
pratiques et de contraintes déclinées sur les processus et les méthodes, de rendre plus efficace
et plus sûr le développement d’un système complexe ainsi que sa maîtrise tout au long de sa
vie opérationnelle.
Le travail réalisé au cours de cette thèse vise donc essentiellement à proposer à

LATECOERE une approche de l’IS innovante pour la société et conforme aux bonnes
pratiques accumulées dans le domaine. Le sens de l’innovation doit être vu en relation avec
les méthodes employées, à adapter au contexte de l’entreprise, et leur mise en œuvre sur des
outils logiciels. Ainsi l’approche propose un usage intensif de la modélisation et utilise la
rigueur apportée par le respect des formalismes de modélisation pour guider et assister le
développement d’un système complexe. De ce fait, le travail présenté se situe au carrefour
de l’IS et de l’Ingénierie Dirigée par les Modèles (IDM).
Pour cela, ce mémoire de thèse est organisé autour de cinq chapitres. Après la
problématique et les objectifs énoncés dans cette introduction générale, le chapitre II présente
le domaine de l’IS en général mais également avec les attentes LATECOERE en filigrane. Il
retrace rapidement l’historique de cette discipline, sa naissance et les principales étapes qui
ont marqué sont évolution. L’approche d’IS sera également justifiée en précisant quels en sont
les enjeux techniques, au niveau des industries en général, puis au niveau de la société
LATECOERE en particulier. Les définitions principales du domaine sont ensuite énoncées et
discutées. Les descriptions de ces définitions amènent à aborder les principes généraux et les
bonnes pratiques classiques du domaine de l’IS avant de présenter et de comparer les
principaux standards d’IS actuellement en usage.
Le chapitre III poursuit l’étude en se focalisant tout d’abord sur les principaux langages de
modélisation utilisables dans le domaine de l’IS. En particulier, le langage SysML, utilisé
dans ces travaux, est détaillé. Ensuite, les principales méthodes d’IS basées sur les modèles
utilisées aujourd’hui sont décrites et comparées entre elles. Les limitations inhérentes à ces
méthodes sont présentées et des axes d’amélioration identifiés. Ce chapitre constitue donc une
introduction et un état de l’art technique pour aborder le chapitre suivant entièrement axé sur
le travail demandé.
12
Le chapitre IV présente la méthodologie pour l’IS proposée à LATECOERE. Cette

méthodologie basée sur les modèles s’appuie sur plusieurs concepts de départs qui seront
explicités. Ensuite, elle est présentée selon deux perspectives. Tout d’abord, le modèle
d’information ou métamodèle autour duquel elle s’articule sera décrit. Ensuite, l’instanciation
des éléments de ce modèle d’information est formalisée par la définition de processus
d’ingénierie système adaptés aux systèmes aéronautiques fabriqués par LATECOERE et
conformes aux standard EIA-632. Un ensemble de méthodes orientées modèles utilisant des
patrons de modélisation est également présenté comme partie prenante de la méthodologie.
Pour des facilités d’écriture et de présentation nous avons adopté l’acronyme MICCSA
(Méthodologie pour l’Ingénierie de Conception Conjointe de Systèmes de l’Aéronautique).
Le chapitre V propose une mise en œuvre de la méthodologie MICCSA au niveau des

outils (Eclipse, OAW, VHDL-AMS). Elle est illustrée à travers d’un cas d’étude qui est le
système porte passager. Cet exemple sera tout d’abord introduit afin de démontrer sa
représentativité et de mieux comprendre ses caractéristiques. Ensuite, les modèles mis en
place grâce à l’application de la méthodologie sont présentés. Viendront également dans ce
chapitre les outils utilisés pour la mise en œuvre de la méthodologie ainsi que les résultats
produits par ces derniers. Cette mise en œuvre a nécessité, en particulier, des transformations
de modèles SysML vers VHDL-AMS pour des besoins de simulation. La validation formelle
s’appuie, quant à elle, sur le langage de contraintes OCL et de manière classique sur les
modèles formels de type STD (State transition Diagrams).
Les objectifs étant ambitieux, la dernière partie de ce mémoire effectuera, dans un chapitre
conclusion, un bilan du travail effectué, une évaluation des objectifs atteints par rapport aux
objectifs fixés initialement et ouvrira les perspectives raisonnables, au sens atteignables, à
court terme et à plus long terme.
13
14
Chapitre 2. Présentation de l’ingénierie système

Ce chapitre est une introduction à l’IS. Il présente la problématique générale du
développement d’un système complexe. Un historique rapide permet de comprendre l’origine
de l’IS, d’abord vue comme un ensemble de techniques et de bonnes pratiques peu
formalisées, puis comme une véritable discipline soutenue par des organisations nationales et
internationales, des normes, et des méthodes.
Les enjeux actuels de l’IS appliquée au développement des systèmes et équipements

aéronautiques sont présentés, avant de présenter les différents aspects de l’IS par le biais de sa
définition par les organismes et les standards reconnus dans le domaine.
Enfin, un certain nombre de définitions sont retenues comme référence pour la suite de ce
rapport, et les principes généraux et les normes actuelles de l’IS seront présentées.
2.1. 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é.
15
Dans le contexte historique de la guerre froide, le système de défense anti-aérien SAGE-

ADS (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
16
(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.
2.2. 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.
Cette section précise, dans un premier temps, les enjeux de l’IS dans ce contexte en les
déclinant sur différents aspects, puis identifie la problématique de la thèse du point de vue
industriel au regard de chacun de ces aspects.
17
L’enjeu de l’IS revient à la maîtrise des complexités inhérentes au projet et au produit,

plus précisément, différentes sources de complexité, décrites ci-dessous, peuvent être
identifiées.
2.2.1. 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.
2.2.2. Complexité liée au produit
Il s’agît de la maîtrise de l’architecture, des interfaces et des constituants du produit. La

maîtrise des interfaces externes (les interfaces en contact avec l’environnement du système) et
internes est capitale pour la réussite du projet.
La spécification, l’analyse et le développement des interfaces jouent un rôle prépondérant

dans la maîtrise des effets indésirables produits par l’interaction entre les constituants du
système, entre constituants et environnement opérationnel, et également dans la capacité du
produit à évoluer et à être maintenu.
Maîtriser la complexité du produit revient donc en grande partie à définir une architecture
dont les interactions entre sous-ensembles sont telles que :
- les effets émergents permettent de réaliser les fonctions attendues au niveau

système,
- les effets émergents indésirables sont identifiés, évités, confinés ou compensés.
18
L’interface externe avec l’opérateur doit respecter des contraintes spécifiques pour
l’ergonomie et la sécurité d’utilisation.
Le choix des constituants et de leur organisation doit être fait en cohérence avec les
capacités de l’entreprise et les décisions concernant les activités sous-traitées. La réutilisation
de solutions doit être envisagée à chaque étape du développement. Ce choix a un impact
important sur la planification et la conduite des activités d’intégration, de validation, de
vérification et de qualification. Par ailleurs, la configuration du système doit être suivie et
maîtrisée dès la définition d’une solution de conception détaillée et ce, jusqu’à la fabrication.
Les écarts par rapport aux exigences initiales et les performances du produit doivent être
mesurés et communiqués.
2.2.3. Complexité liée à la performance système
Les multiples exigences de performances formulées sur le produit sont très souvent
contradictoires et nécessitent, dans toutes les phases de conception, des activités de
comparaison de solutions et de recherche de compromis.
La prédiction des performances du produit au plus tôt dans les phases de conception,
lorsque le produit n’existe pas encore physiquement, joue un rôle prépondérant pour éviter
des itérations dans le développement. Associé à la complexité intrinsèque du produit, elle est
une source de complexité supplémentaire qui influence l’adéquation du système au besoin
initial.
2.2.4. Complexité liée au réseau d’acteurs projet
Cette source de complexité peut être déclinée selon deux aspects : tout d’abord, un réseau
d’acteurs internes à l’entreprise. Quelque soit le type de projet et de produit, plusieurs métiers
et plusieurs compétences sont impliquées dans son développement. Une communication
efficace entre chacun des acteurs joue un rôle prépondérant pour le bon déroulement du
projet. Cet aspect collaboratif doit permettre de réaliser des analyses justes et les bons
arbitrages tout au long du projet, et en particulier lors des phases préliminaires de définition
d’architecture, conditionnant la réussite du projet.
Généralement, un projet implique au moins deux acteurs : le(s) client(s) (avionneurs ou

compagnies aérienne), et l’entreprise elle-même. Celle-ci peut également décider de sous-
traiter une partie de ses activités (conception de sous-ensemble, essais de qualification…),
produisant ainsi de nouvelles interfaces et de nouveaux besoins de communication entre les
acteurs du projet. L’efficacité de la communication entre ces acteurs et la maîtrise des aspects
contractuels des éléments transmis entre les acteurs du projet joue un rôle clé dans la réussite
du projet et la satisfaction des objectifs de l’entreprise.
2.2.5. Complexité liée aux coûts et délais
Le développement d’un système aéronautique se déroule dans un programme avion, à

partir duquel des contraintes fortes de coûts et de délais sont associées et contractualisées
entre le client et l’entreprise, puis entre l’entreprise et ses sous-traitants. Ainsi, chaque source
de complexité peut avoir un impact important sur les coûts et délais de développement, ainsi
que sur le coût global du système.
19
2.2.6. Cohérence globale et décisions : problématique industrielle de

l’ingénierie système
Chaque source de complexité présentée ci-dessus peut être vue comme un un facteur de
probabilité de réussite ou d’échec du projet, par rapport aux objectifs de l’entreprise. Dans la
conduite du projet, et particulièrement dans ses phases les plus amonts, chacun des ces aspects
doit être pris en compte (au regard des informations disponibles ou anticipées). Les moyens et
les activités associées doivent être planifiés, les risques associés identifiés et quantifiés et
maîtrisés tout au long du développement.
La maîtrise de ces aspects constitue l’objectif principal de l’IS dans notre travail de thèse.
Le problème peut être reformulé sous la forme de la question suivante :
Comment traduire le besoin opérationnel du demandeur du système en objectifs

techniques sur chacun des aspects, et comment s’assurer que ces objectifs techniques
pourront être atteints en respectant les objectifs et les contraintes propres de l’entreprise ?
2.2.7. Questionnaire pratique
Dans l’objectif de préciser la problématique d’IS de la thèse sur la base des pratiques de
l’entreprise LATECOERE, un questionnaire a été conçu et soumis aux principaux métiers de
l’entreprise.
Cette démarche a permis d’identifier certaines difficultés pour l’entreprise à pratiquer de

la bonne IS. En particulier, les pratiques de gestion des exigences par les différents métiers
ont été analysées pour remonter aux difficultés liées à la pratique de l’IS tel qu’elle est
réalisée actuellement. Une synthèse des éléments résultants de cette démarche est présentée
dans l’annexe A.
2.3. Système, conception système et IS
Ce paragraphe présente une brève description de trois notions qui seront utilisées tout au
long de ce document. Il s’agit d’une analyse rapide l’activité de conception, des notions de
système et d’IS, accompagnée d’un ensemble de définitions servant de référence.
2.3.1. Systèmes
Charles S. Wasson [Was_06] définit un système comme un ensemble intégré d’éléments

interopérables, dont les capacités sont spécifiées et bornées, et fonctionnant en synergie pour
réaliser une tache à valeur ajoutée, afin de satisfaire les besoins opérationnels d’un
utilisateur dans un environnement opérationnel particulier, et avec un résultat et une
probabilité de succès spécifiée.
Cette définition permet d’aborder les points principaux qui caractérisent un système :
Un ensemble intégré d’éléments : un système peut être perçu comme un ensemble de
constituants interfacés entre eux. Ces constituants peuvent être des dispositifs de natures
20
technologiques différentes (dispositifs électroniques, mécaniques, hydauliques, etc.) mais

aussi des moyens humains, des installations, des services et des procédés.
fonctionnant en synergie : Sur ce point, Brian W. Mar [Mar_97] rappelle plusieurs propriétés
permettant de faire apparaitre la caractéristique d’émergence liée aux interactions entre les
constituants d’un système. Ce principe est communément résumé ainsi : le système pris dans
sa globalité est plus que la simple somme de ses constituants. D’un autre côté, le système pris
dans son ensemble détermine la nature de ses constituants.
pour réaliser une tâche à valeur ajoutée : Le système existe car il réalise une ou plusieurs
tâches ou services qui apportent une valeur aux yeux de son utilisateur ou de celui qui le
possède.
dans un environnement opérationnel : La notion d’environnement est également centrale dans

la définition d’un système, car elle sous-tend qu’un système possède une frontière le séparant
de l’extérieur et qu’il interagit avec celui-ci d’une manière connue et maîtrisée. Une partie de
cette interaction constitue les services ou la mission qui sont attendus du système.
L’environnement opérationnel est l’environnement dans lequel le système est plongé lorsqu’il
rend ces services.
D’autre définitions, plus concises, ont été intégrées dans les normes d’ingénierie système
et/ou reconnu par les organismes du domaine. Ainsi, pour l’INCOSE, un système est un
ensemble intégré d’éléments qui accomplissent un objectif défini [INC_04]. La définition qui
sera retenue dans ce travail, très similaire, est celle qui est retenue par l’AFIS et l’ISO :
Un système est un ensemble d’éléments en interaction, organisés pour atteindre un ou

plusieurs résultats déclarés [Source : AFIS, ISO 15288]
Dans le domaine de l’industrie aéronautique civile, la notion de système a une définition

particulière liée à la décomposition du produit avion en sous-ensembles. Un système désigne
alors un ensemble de constituants réalisant une, ou participant à plusieurs, fonction(s) de
niveau avion. Les fonctions de niveau avion sont elle-même identifiées selon un découpage
commun dans l’ATA-100 (Air Transport Association, Spec. 100).
Dans ce contexte, le terme système est donc associé à un certain niveau hiérarchique dans la
décomposition structurelle d’un avion en ses constituants. Ensuite, un système peut être
décomposé en sous-ensembles ou en équipements, désignant ainsi des éléments qui
participent avec d’autres équipements et sous-ensembles à une ou plusieurs fonctions de
niveau avion. La définition retenue pour un système dans le domaine aéronautique est donc la
suivante :
Dans le contexte aéronautique, un système est une combinaison d’éléments interconnectés

pour implémenter une fonction ou un groupe de fonctions de niveau avion. [Source : ARP
4754]
Afin de rester cohérent, le terme de système sera employé dans sa définition la plus
générique. Lorsqu’il sera utilisé dans sa définition propre à l’aéronautique, le système sera
alors appelé explicitement système aéronautique.
21
L’IS s’appuie par ailleurs sur la conception système. La section suivante présente les
grandes lignes qui constituent l’activité de conception.
2.3.2. La conception système
La conception d’un système est une activité complexe. Elle consiste à mener
conjointement des activités afin de parvenir à une solution satisfaisant un besoin formulé et un
ensemble de contraintes.
Les activités regroupées sous le terme de conception sont multiples. Nous pouvons en
citer quelques unes :
- collecte, structuration et traitement de données techniques,

- décomposition de problème global en problème locaux plus simples,
- établissement et accroissement de la connaissance autour d’un problème
spécifique,
- recherche de solutions par analyse intuitive et créative,
- prise de décision sur la décomposition d’éléments ou sur des éléments de solution,
- application et ajustement de schémas de résolutions génériques à un problème
spécifique,
- optimisation de paramètres liés entre eux, etc.
Toutes ces tâches sont menées conjointement, pour parvenir à une solution satisfaisante.
Celle-ci fait appel à la fois a des caractéristique génériques d’ordonnancement, de maîtrise des
incertitudes et des risques, et à des compétences techniques liées au(x) domaine(s).
Des travaux de recherche permettent d’adopter une approche de conception adaptée à un

problématique spécifique ou au développement d’un système particulier. M. Sautreuil a par
exemple proposé une approche [Sau_09] permettant une conception optimisée des organes de
génération électrique du réseau électrique avion. L’approche qui est proposée dans ces
travaux tient compte de la complexité liée au développement conjoint des organes de
génération, de servitudes, et d’un réseau complexe d’interconnexions et de contrôle, puis de
l’intégration de ces éléments. Pour cela, la notion de robustesse d’un composant système a été
utilisée comme un moyen de mieux maîtriser la capacité d’un équipement à être intégré dans
son environnement final. Cette notion a été déclinée au niveau technique par un indicateur lié
aux lois de commande du système étudié.
Une fois les activités ci-dessus ramenées à une problématique générale et aux enjeux de
maîtrise des complexités abordées au paragraphe 1.2, l’existence du domaine de l’IS, comme
contribution à répondre à cette problématique, apparaît clairement justifié.
2.3.3. L’ingénierie système
Il existe une grande variété de définitions de l’IS. Cette variété est probablement liée à la
diversité des contextes dans lesquels peuvent être appliquées les approches d’IS : contexte
culturel, technique, organisationnel, …
22
Il existe, cependant, des constantes dans ces définitions. Cette section propose plusieurs
définitions, puis tente d’apporter une interprétation synthétique de celles-ci et définit enfin
celle qui sert de référence pour ce travail.
Pour l’INCOSE, l’IS est simplement une approche et un ensemble de moyens pour
assurer la réalisation satisfaisante d’un système [INC_04].
La NASA adopte une définition pragmatique et insiste sur les phases de cycle de vie et sur
les bonnes pratiques caractéristiques de l’IS : L’ingénierie système est une approche robuste
pour la conception, la fabrication et l’exploitation d’un système. En termes simples,
l’approche consiste en l’identification et la quantification des buts du système, la création
d’alternatives de conception, la réalisation de compromis lors de la conception, la sélection,
de l’implémentation, l’intégration et la vérification et validation des meilleurs concepts par
rapport aux buts fixés [NAS_95].
Nous pouvons trouver également des définitions plus personnelles telles que de D.
Hitchins, président de l’INCOSE en 2007 l’annonce : l’IS est l’art et la science de créer des
systèmes efficaces, utilisant le système dans son intégralité et dans l’intégralité de la vie
opérationnelle du système ; ou l’art et la science de créer une solution optimale à un
problème complexe.
Cette définition désigne l’activité d’IS comme un art et une science soulignant ainsi la
difficulté liée à la multitude des arbitrages et à la valeur ajoutée irremplaçable apportée par
l’humain dans la recherche d’une solution optimale.
Jean-Pierre Meinadier définit l’IS comme la recherche d’un équilibre entre savoir, savoir-
faire et créativité. Il parle ainsi du travail de l’ingénieur système : le technicien maîtrise sa
technique; l’ingénieur possède l’art de concevoir des produits pour un marché en adaptant
des techniques existantes; l’ingénieur système exerce l’art de concevoir des systèmes mettant
en jeu un grand nombre de métiers, dont il ne peut maîtriser tous les génies.
L’ingénieur système est l’ingénieur généraliste qui maintient une vision globale. La
méthode employée est celle d’une approche collaborative. Sur un système de grande
dimension, une équipe de scientifiques et d’ingénieurs, de généralistes et de spécialistes,
exercent un effort collectif pour définir une solution et la réaliser physiquement. Cette
technique a été appelée approche système ou méthode de développement par équipes
[Goo_57].
La méthode d’ingénierie système part du principe que chaque système est un tout même
s’il est constitué de structures et de sous-fonctions nombreuses et spécialisées. De plus, l’IS
défend l’idée selon laquelle chaque système possède un certain nombre d’objectifs et que
l’équilibre existant entre ces objectifs peut différer largement d’un système à l’autre.
L’approche système cherche à optimiser les fonctions globales du système selon les objectifs
pondérés afin d’obtenir la meilleure compatibilité entre ses éléments [Ches_65].
Pour sa part, l’AFIS décrit l’IS comme :

- un processus coopératif et interdisciplinaire de résolution de problème,
- s’appuyant sur les connaissances, méthodes et techniques issues de la science et de
l’expérience,
23
- mis en œuvre pour définir, faire évoluer et vérifier la définition d’un système
(ensemble organisé de matériels, logiciels, compétences humaines et processus en
interaction),
- apportant une solution à un besoin opérationnel identifié conformément à des
critères d’efficacité mesurables,
- qui satisfasse aux attentes et contraintes de l’ensemble de ses parties prenantes et
soit acceptable pour l’environnement,
- en cherchant à équilibrer et optimiser sous tous les aspects l’économie globale de
la solution sur l'ensemble du cycle de vie du système.
Pour disposer d’une définition unique tout au long de la thèse, nous retiendrons la
définition suivante :
L’Ingénierie Système (ou ingénierie de systèmes) est une démarche méthodologique

générale qui englobe l’ensemble des activités adéquates pour concevoir, faire évoluer et
vérifier un système apportant une solution économique et performante aux besoins d’un
client tout en satisfaisant l’ensemble des parties prenantes. [Source : AFIS]
Selon la définition de l’AFIS, l’IS est donc une démarche méthodologique. Celle-ci
s’appuie sur des principes généraux, établis notamment par le retour sur l’expérience
accumulée dans chaque domaine industriel et sur la mise en pratique de ces principes par
l’utilisation cohérente de processus, de méthodes, et d’outils.
2.4. Principes généraux de l’ingénierie système
Au-delà des définitions présentées précédemment et selon les concepts fondamentaux

reliés à la notion de système, notre travail de thèse s’appuie sur les principes de base de
l’ingénierie système qui suivent. Ces principes seront mis en pratique par les éléments de la
méthodologie MICCSA qui sera présentée aux chapitres 3 et 4.
Formuler le problème avant de chercher une solution. S’assurer que le problème est
formulé de manière complète et correcte, au bon niveau d’abstraction et de détail, constitue un
préalable indispensable à la recherche des solutions. Il s’agit d’une condition nécessaire à une
exploration efficace des solutions possibles. Ce principe peut souvent être décliné
simplement : définir le quoi avant le comment, spécifier avant de concevoir, ou encore faire
précéder les descriptions boîte noire avant les descriptions boîte blanche.
Privilégier la recherche des solutions par la définition d’alternatives de solutions, puis

la sélection d’une alternative. Cela garantit que l’exploration d’un minimum de solutions a
été réalisée avant d’en sélectionner une. Toutefois, le fait de définir des alternatives ne
garantit pas qu’une de ces alternatives soit optimale.
Privilégier une démarche de conception descendante (Top-down). Dans la succession

des descriptions virtuelles du système, représentatives de solutions intermédiaires en terme de
complétude de niveau d’abstraction et de niveau de détail, les descriptions de haut niveau
doivent être définies et figées préalablement aux solutions de bas niveau. Ainsi, commencer à
haut niveau d’abstraction permet de faciliter l’analyse et l’exploration du problème et des
solutions.
24
Un autre principe consiste à diminuer la complexité inhérente au système, tant dans la

formulation du problème que dans celle de la solution, en identifiant puis en exprimant
séparément les préoccupations de chaque acteur du projet.
Assurer la cohérence entre chaque vues du système tout au long de son cycle de vie.
Concrètement, cela implique de définir des référentiels et des points de vues permettant de
maintenir la cohérence entre chaque représentation.
Adapter les niveaux d’abstraction parmi les différentes vues du système. Cela consiste
à assurer l’interopérabilité des méthodes et des outils (entre les disciplines à un niveau
d’abstraction égal et entre les niveaux d’abstraction).
Faire entrer la prise en compte des propriétés émergentes du système dans le processus de
conception. De l’intégration des composants, et de leur interaction, naissent des phénomènes
qu’il est essentiel d’identifier et de maîtriser. Lorsque l’architecture du système est
considérée, il s’agit alors de maîtriser les interfaces fonctionnelles et physiques du système.
Diminuer la complexité du problème global en procédant par étapes, dans lesquelles

l’ensemble des données projet (exigences et définition du système) sont dans un état cohérent
et peuvent être considérées comme un référentiel fixe.
Vérifier la complétude et la justesse des solutions intermédiaires au plus tôt et à

chacune de ces étapes, dès les phases amont d’analyse des exigences initiales afin de réduire
et maîtriser l’incertitude.
Dans la suite de ce travail, nous présentons une description générale des processus
développés en IS ainsi qu’une présentation des principales méthodes et outils associés. Les
méthodes et outils basées sur l’utilisation de modèles seront ensuite décrits plus en détail dans
le chapitre 2.
2.5. Processus et normes d’ingénierie système
La définition de cycle de vie et des processus structure les activités de l’IS. Ce sont des
éléments invariants, qui permettent de s’assurer que la démarche est conduite de manière
cohérente. Ce paragraphe présente une description des principaux cycles de vie applicables à
l’IS et définit ce qu’est un processus.
2.5.1. Introduction : Processus et cycles de vie
Processus et cycle de vie fournissent un moyen de structuration différent des activités de

développement d’un système. Un cycle de vie peut être défini comme une organisation dans
le temps des états dans lequel le système (ou sa représentation virtuelle) doit se trouver au
cours du développement du système. Cette organisation permet de découper le développement
en phases distinctes.
25
Un processus fournit une abstraction des transformations du système au cours de son

développement et de la consommation de ressources pour lesquelles les acteurs et les
responsables sont définis mais non organisés dans le temps.
Les deux descriptions peuvent donc être considérées comme indépendantes ou

orthogonales. L’AFIS propose une description de la relation existant entre processus et cycle
de vie ou les phases de développement du système [AFIS] : les processus constituent une
vision opératoire du métier d’IS, complémentaire à la vision séquentielle fournie par le cycle
de vie. Par exemple les activités du processus d’intégration ne se limitent pas à la phase
d'intégration. Elles commencent pendant la phase de conception avec la définition du plan et
des moyens d’intégration et sont reprises pendant la phase d’exploitation lors des opérations
de maintenance évolutive.
Les cycles de vie peuvent être considérés comme des ancêtres des processus de
développement, mais aussi comme l’agencement des processus en séquences organisées et
délimitées par des jalons.
2.5.2. Cycles de vie de l’ingénierie système
Historiquement, les cycles de vie sont particulièrement appliqués dans le développement

de logiciels. De nouveaux cycles de vie sont apparus et ont suivis l’évolution continues des
approches et des paradigmes du développement logiciel (approche fonctionnelle, méthodes
objets, développement par aspects, méthodes agiles, …).
Les cycles de vie de développement logiciel sont pour une grande partie à l’origine de leur
utilisation dans le domaine de l’IS. Trois familles de cycles de vie se sont ainsi dégagées de
cette évolution : le cycle en cascade, le cycle en V et le cycle en spirale. Ces trois modèles
sont largement connus et sont présentés figure 2.1. Nous les décrivons brièvement ci-dessous.
Dans le cycle en cascade, les activités sont réalisées de manière séquentielle, chaque
activité étant susceptible d’occasionner un retour sur une activité précédente.
Le cycle en V est devenu le cycle de développement standard de l’IS. Le cycle est séparé
en deux branches. Dans la branche descendante sont réalisés la spécification et la conception
du système, les exigences spécifiées sont validées au regard du niveau précédent et les
activités de vérification et de validation système sont anticipées et planifiées en termes
d’attendus. Une fois la phase de réalisation des composants élémentaires réalisée, la branche
de droite du cycle constitue l’intégration, la vérification et la validation du système au regard
du besoin initial.
Le cycle de développement en spirale reprend les différentes étapes du cycle en V, mais

permet que le cycle complet soit répétés autant de fois que nécessaire, chaque itération
apportant une plus grande complétude et une meilleure robustesse des solutions apportées.
26
Figure 2.1: Modèles des principaux cycles de vie, [Est 07]
Autour de ces modèles se sont développées des variantes pour répondre à des spécificités d’un
domaine technique, à des contraintes d’organisations ou à des outils particuliers.
2.5.3. Définition d’un processus
Selon la définition de l’AFIS, un processus est un ensemble d’activités qui transforment

un ensemble d’éléments d’entrée en éléments de sortie. Un processus précise donc le résultat
attendu ainsi que les ressources disponibles et les contraintes appliquées à cette
transformation. Par contre, un processus ne précise en rien comment cette transformation est
réalisée et ne fournit qu’une vision opératoire et non séquentielle. Il constitue la partie
invariante de l’enchaînement des activités d’un projet à un autre. Selon le niveau de détail, ces
processus peuvent être appliqués indifféremment d’un domaine technique à un autre.
27
Par ailleurs, de ce modèle générique de processus, l’AFIS distingue quatre groupes de

processus à réaliser au cours d’un projet :
- Les processus techniques structurent les activités techniques autour du produit à

concevoir et permettent de transformer, dans le contexte spécifique au projet, le
besoin du client en solution, et de veiller à son utilisation opérationnelle. Les
processus techniques peuvent être organisés selon un cycle de vie en V, en spirale,
ou autre.
- Les processus de management permettent la gestion des activités techniques dans

le contexte spécifique au projet.
- Les processus de gestion des relations contractuelles entre maître d’ouvrage et

maître d’œuvre dans le contexte spécifique au projet.
- Les processus d’entreprise qui permettent de gérer de manière transversale aux

projets, les domaines communs qui font appel à l’IS au sein de l’entreprise.
Par la définition de processus articulés entre eux, les normes d’IS visent à :
- la maîtrise de la complexité inhérente au projet et au produit,

- la maîtrise des risques sur les projets et les produits,
- la maîtrise des coûts, des délais, et la gestion des incertitudes,
- la communication transdisciplinaire et la réalisation de compromis globaux
optimisés,
- l’amélioration globale de l’adéquation du système au besoin des parties prenantes.
Ces objectifs sont communs aux trois principales normes actuelles de l’IS : l’IEEE 1220
[IEE_98], l’EIA 632 [EIA_98], et l’ISO 15288 [ISO_08]. Celles-ci couvrent différemment les
groupes de processus présentés précédemment, et avec un niveau de détail assez différent :
- description des méthodes à appliquer pour réaliser ces processus (cas de

l’IEEE1220),
- recommandations générales et pratiques recommandées (cas de l’EIA632),
- spécification des résultats attendus (cas de l’ISO15288).
Ces normes adoptent donc des niveaux de détails différents dans la description de ces
processus (axe vertical des ellipses, voir figure 1.2). En contrepartie, le niveau de couverture
du cycle de vie du système produit est inversement lié au niveau de détail, comme le reflète la
dimension verticale des ellipses correspondant à chaque norme de la figure 2.2.
28
Figure 2.2: Scope et niveau de détail des principales normes de l’IS [AFIS]
Dans cette partie, les normes ISO 15288 et IEEE 1220 seront présentées de manière
générale. La norme EIA 632 sera présentée de manière plus détaillée car ses processus
structurent la méthodologie MICCSA, objet des chapitres 3&4.
2.5.4. Normes d’ingénierie système
Cette section présente les principales normes d’IS en application aujourd’hui. Ces
principales normes sont comparables, de par leur contenu technique, leur couverture des
différents aspects d’IS traités, le type de système auxquelles elles sont destinées. Elles
décrivent des processus généraux, indépendants du domaine technique d’application et du
niveau de complexité du (des) système(s) étudié(s).
La mise en œuvre, partielle ou complète, des processus décrits dans ces normes est
conditionnée par de multiples contraintes, dont les suivantes :
- L’adaptation aux lois nationales et internationales en vigueur,

- L’adaptation à la politique et aux objectifs propres de l’entreprise : la culture et
l’expérience guident la définition et l’évolution des processus internes, puis le
choix de ses méthodes et outils à mettre en œuvre.
- Le domaine de l’entreprise : il peut imposer des standards d’IS spécifiques qui
spécialisent, partiellement ou intégralement, les processus de l’EIA 632 (exemple
ECSS-E10 pour le domaine spatial).
- Les exigences processus imposés par les clients (c.à.d. les normes et standards de
l’avionneur).
- Les domaines techniques (métiers) des produits : ces processus et méthodes sont à
mettre en œuvre et à interfacer aux processus et méthodes métiers relatifs aux
solutions implémentées : électroniques (DO-254), logicielles (DO-178).
29
Tandis que la norme IEEE 1220 s’adresse en priorité au système produit matériel (la
notion de système dans l’IEEE 1220 étant peu formalisée au moment de sa création), les
normes EIA 632 et ISO 15288 adoptent une définition du système avec un sens plus large.
Pour ces deux normes, un système peut ainsi être constitué de produits matériels, logiciels,
de services, de personnes, de techniques, d’installations, de procédures, ou d’un ensemble
composé de ceux-ci, et peut être commercial ou non, simple ou complexe, innovant ou
préexistant.
Les concepts et les techniques présentées dans chacune de ces normes sont souvent
comparables, parfois équivalent. Au-delà du rapprochement entre normes d’ingénierie et
normes d’ingénierie logicielle, un effort d’harmonisation est en cours, principalement entre
les normes IEEE 1220 et ISO 15288.
Par ailleurs, un modèle de maturité, EIA 731, permet aujourd’hui d’évaluer la conformité
d’un ensemble de processus implémentés aux processus de référence prescrits dans l’EIA 632.
La figure 2.3 retrace l’évolution des différentes normes de l’IS.
Figure 2.3. : Evolution des principales normes de l’IS
2.5.5. La norme EIA 632
La norme EIA 632 est utilisée comme une référence pour la méthodologie présentée dans
ce document. Ce paragraphe inclut une description générale de cette norme d’IS et en présente
les principaux aspects / concepts.
2.5.5.1.Présentation générale
En Juin 1994, une première version provisoire de la norme pour l’ingénierie des systèmes
EIA 632 a été développée conjointement par l’EIA et l’INCOSE. Cette version provisoire,
l’EINIS 632 Interim Standard, était destinée autant aux entreprises privées qu’aux organismes
nationaux ainsi qu’à leurs sous-traitants.
30
En 1995, l’EIA soutenu par l’INCOSE établit un groupe de travail pour définir un
standard officiel de la norme EIA 632. La norme provision a alors été retravaillée dans le sens
d’un plus haut niveau d’abstraction afin de la rendre plus générique et applicable à divers
domaines industriels et technologiques. Une version préliminaire a été diffusée en 1998. Elle
a été depuis lors à l’origine de la norme l’EIA 731, permettant le déploiement des processus
de l’EIA 632 au sein d’une organisation.
La norme EIA 632 est applicable à tout type de système. Ses processus sont applicables
pour chaque phase du cycle de développement d’un système comme le montre la figure 2.4.
Figure 2.4. : Domaines couverts par la norme EIA632
Son niveau de généricité, les concepts et les processus qu’elle décrit la rendent bien
adaptées à notre application.
2.5.5.2.Principaux concepts de la norme EIA 632
Notion de système pour l’EIA 632
L’EIA 632 définit un système comme l’agrégation d’un ensemble de produits, un produit
étant lui-même défini comme tout ensemble constitué de composants (matériels et/ou
logiciels) de données, de services, de personnes, de fournitures, d’installation technique, de
techniques spécifiques et de documentation.
De plus, la définition distingue, à l’intérieur du même concept de système, deux types de

produits (voir figure 2.5) :
- Les produits finaux sont livrés au client, et réalisent les fonctions opérationnelles
du système.
- Les produits contributeurs constituent l’ensemble des produits qui ne réalisent pas
les fonctions opérationnelles du système, mais qui permettent, au cours d’une ou
plusieurs phases du cycle de vie du système, de réaliser celui-ci.
31
Cette distinction permet d’éviter que l’effort technique ne soit trop centré sur le produit
final, au détriment des moyens à mettre en œuvre autour de ce produit final.
Figure 2.5. : Le concept de système dans la norme EIA 632.
Les produits contributeurs incluent les processus d’IS associés par exemple au
développement, aux tests, à la production, au déploiement, au support et au retrait de service
des produits finaux (voir figure 2.6). Produits finaux et contributeurs permettent au système
de réaliser son objectif.
Notion de bloc de construction de l’EIA 632 ou Building block
L’ensemble de la norme s’appuie sur le concept de building block, ou bloc de

construction comme élément de base. Un bloc de construction, tel que représenté sur la
figure 1.7, peut être associé à tout système ainsi qu’à ses produits constituants, finaux ou
contributeurs. Un bloc de construction, associé à un produit, peut par conséquent être
considéré lui-même comme un système possédant ses propres produits finaux et contributeurs
(figure 1.8).
Le bloc de construction possède un rôle central dans la norme EIA 632. Il constitue la
brique élémentaire permettant de structurer l’organisation du système, de contrôler le flot des
exigences produit et processus associées, de définir et d’utiliser des représentations du
système adaptées aux niveaux d’abstraction et de détails.
La norme EIA632 utilise donc le bloc de construction comme un cadre conceptuel,

manipulé par l’ensemble de ses processus. Il permet d’organiser les principaux apports de la
norme en termes d’ingénierie des exigences, de définition des solutions, d’activités
d’intégration, de validation et de vérification.
Le système peut alors être vu comme une succession de niveaux de blocs de construction.
Les solutions définies dans les blocs de niveaux supérieurs, décrits par un ensemble
d’exigences spécifiées, sont allouées comme exigences d’entrée aux blocs du niveau inférieur.
Finalement, la décomposition d’un bloc s’arrête lorsque celui-ci peut être réalisé par un
composant sur étagère, être fabriqué ou être transmis en tant qu’élément spécifié à un sous-
traitant.
32
Figure 2.6. : Niveaux de définition des blocs de construction
Bien que cela ne soit pas explicité dans la norme, celle-ci prescrit ainsi une démarche de
conception globalement descendante, partant des exigences du système global, pour obtenir
par la décomposition en blocs de construction, les spécifications (ou exigences spécifiées) des
blocs de constructions élémentaires.
Tous les blocs possèdent une structure descriptive fixe, représentée graphiquement sur la
figure 1.7. Les données techniques en entrée d’un bloc sont les exigences allouées depuis le
niveau supérieur, et les exigences additionnelles. Celles-ci correspondent aux exigences
provenant d’autres parties prenantes (normes applicables au niveau de détail et au domaine
concerné par le building block) telles que les exigences clients affectées au bloc. Ces
exigences des différentes parties prenantes constituent, ensemble, le problème qui doit être
résolu dans le périmètre du building block.
L’analyse de ces différentes sources d’exigences permet la définition puis la validation

d’un ensemble d’exigences, établies comme les exigences techniques du système. Cet
ensemble d’exigences constitue un référentiel à partir duquel la recherche, la comparaison et
la définition de solutions techniques sont rendues possibles.
La norme préconise, en particulier, l’usage et la distinction de deux types de solutions

techniques :
- Des solutions logiques, tout d’abord, qui représentent une abstraction des solutions
proposées, indépendantes des technologies choisies. Les exigences techniques
systèmes doivent autant que possible être allouées aux solutions logiques.
- Des solutions physiques, ensuite, décrivant les solutions techniques envisagées.
Les solutions envisagées constituent, un fois sélectionnées, une solution de
conception intermédiaire qui servira de base à la vérification.
A partir des solutions logiques et physiques, un ensemble validé d’exigences dérivées

techniques est défini. Ces exigences sont liées aux choix de conception associés aux solutions
logiques et physiques. Lorsqu’elles sont dérivées des solutions logiques, elles sont utilisées
33
comme aide pour définir et/ou contraindre les solutions physiques. Ces exigences doivent être
affectées aux solutions logiques et physiques au même titre que les exigences techniques
systèmes du bloc.
Enfin, une solution physique de conception est choisie. A partir des solutions logiques et
physiques correspondantes, des exigences sont spécifiées, puis affectées aux blocs de
construction du niveau suivant.
Figure 2.7. : Aspects internes du Building block ou bloc de construction de l’EIA 632
Une fois les spécifications des blocs de constructions élémentaires obtenues, l’intégration
et la vérification se fait de manière ascendante, niveau par niveau en vérifiant chaque bloc de
construction assemblé.
2.5.5.3. Processus de la norme EIA 632
L’EIA 632 est organisée autour de 13 processus, rassemblés en 5 groupes, représentés sur
la figure 1.8.
Les différents types de processus présentés au paragraphe 1.5.3 sont présents dans la
norme dans laquelle :
- les Processus techniques génériques sont assurés par les processus de conception
système, de réalisation produit et d’évaluation technique,
- le processus générique de management est le processus de management technique,
- le processus générique de gestion des relations contractuelles correspond au
processus d’acquisition et de fourniture.
La norme EIA 632 décrit, par l’intermédiaire d’un ensemble d’exigences sur ces
processus, comment ceux-ci doivent être appliqués sur chaque bloc de construction
constituant le système. Ces exigences précisent quelles sont les tâches à accomplir, quels
résultats doivent être fournis et préconisent, à titre indicatif, les méthodes permettant de
réaliser ces tâches.
34
Figure 2.8. : Processus de la norme EIA 632
2.5.5.4. Les processus de conception système
Les processus de conception système constituent le nœud central de la norme. Ils

permettent de transformer les exigences contractuelles de l’acquéreur et des autres parties
prenantes en un produit spécifié qui satisfait ces exigences.
Dans cet objectif, deux processus sont réalisés itérativement : le processus de définition
des exigences et le processus de définition des solutions. Ceux-ci sont répétés à chaque niveau
de conception durant la démarche descendante tant que les blocs de constructions considérés
doivent être décomposés.
Le processus de définition des exigences vise à capturer ou identifier les exigences de

l’acquéreur et des autres parties prenantes et à les convertir en exigences techniques système
valides.
35
Le processus de définition de la solution permet, quant à lui, l’obtention d’une solution

de conception qui répond aux exigences techniques système, c’est-à-dire la solution obtenue
par l’application du processus de définition des exigences. Les solutions logiques et physiques
induisent à leur tour des exigences techniques dérivées.
2.5.6. Les normes IEEE 1220 et ISO 15288

2.5.6.1.Norme IEEE 1220
La norme IEEE 1220 décrit des processus techniques destinés à la conception des
systèmes-produits. Elle est donc, de part le type de système visé et son champ d’application,
beaucoup plus restrictive que la norme EIA632 précédemment décrite. Basée sur le standard
militaire MIL STD 499B, la première version de l’IEEE1220 a été diffusée en 1994.
Dans cette norme, le développement du système est séparé en trois niveaux. Tout d’abord,
le niveau d’analyse, de définition et de validation des exigences. Ensuite, vient une phase
d’analyse, de définition et de validation des fonctions. Enfin, le troisième niveau concerne la
définition d’une architecture physique issue de l’activité de synthèse.
La norme est construite autour de 8 processus organisés selon la figure 2.9. Les processus
d’analyses des exigences et d’analyse fonctionnelle permettent de définir une architecture
système validée, allouée sur des composants physiques, avant l’étape de synthèse permettant
d’obtenir l’architecture physique à construire.
Un processus spécifique d’analyse système permet une évaluation des solutions

envisagées (alternatives) et la résolution de conflits ou la définition de compromis à chaque
niveau d’abstraction : exigences, fonctions et solutions physiques. Ce processus permet de
systématiser la technique employée pour la prise des décisions de conception.
Enfin, un processus de maîtrise est dédié au contrôle des activités d’IS décrites dans les
autres processus.
Par ailleurs, des activités de validation et de vérification permettent de définir, niveau par
niveau, un référentiel d’exigences, d’architecture fonctionnelle et physique, vérifié du projet.
La norme suit, par conséquent, une démarche descendante et n’explicite pas les activités
d’analyse système dans le cas de système partiellement ou intégralement préexistants.
36
Figure 2.9. : Les processus de l'IEEE 1220 (selon l’AFIS)
2.5.6.2.Norme ISO15288
La norme ISO 15288 a été développée depuis 1990 en reprenant la structure de la norme
ISO/CEI 12207 – AFNOR Z 67- 150 destinée au développement de logiciel (source AFIS,
voir figure 1.10). Elle définit un standard applicable au développement de systèmes de nature
et de taille quelconque et sans a priori sur le partitionnement entre logiciel et matériel. Elle est
donc proche de l’EIA 632 dans sa définition du système, comme étant composé du système-
produit final accompagné de l’ensemble de ses produits contributeurs (y compris les
processus associés). Le standard prescrit les cinq types de processus principaux identifiés
précédemment et couvre l’intégralité du cycle de vie du système.
Elle complète les processus s’appliquant aux projets par des processus dits d’entreprise,
qui ont pour objectif de déployer au mieux le potentiel de l’IS au sein de l’entreprise, en
gérant les domaines communs au profit des projets d’IS.
37
Figure 2.10. : Les processus de l'ISO 15288 (selon l’AFIS)
2.6. Conclusion
Ce premier chapitre a tout d’abord permis d’établir les définitions fondamentales et

nécessaires à la suite de ce document. Il a également permis de justifier l’existence de l’IS en
tant que discipline, à la fois comme une réponse au besoin général de maîtrise de la
complexité inhérente au développement des systèmes, mais également pour répondre à un
besoin plus spécifique de l’entreprise LATECOERE, par l’intermédiaire d’une étude pratique
au sein de métiers techniques de l’entreprise.
L’étude des principales normes existantes dans le domaine a enfin permis d’aborder et de
poser les thèmes fondamentaux de la thèse que sont les processus techniques, et les pratiques
générales liés au développement et à la gestion des exigences, des spécification et des
représentations de solutions techniques.
Les normes d’IS présentés dans ce chapitre permettent de guider l’entreprise dans la
définition de ses processus et dans l’instanciation de ceux-ci au cours de ses projets.
Toutefois, elles ne spécifient pas comment les processus peuvent être réalisés, c.à.d. les
méthodes et outils qu’il est nécessaire de mettre en œuvre pour mener à bien les processus. Le
chapitre suivant propose de répondre à cette limite et restreint le domaine d’étude à une
certaine catégorie de méthodes, appelées méthodes d’IS basées sur les modèles.
38

chapitre2

Transféré par

Droits d'auteur :

Formats disponibles

chapitre2

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

chapitre2

Transféré par

Droits d'auteur :

Formats disponibles

Approche système pour la conception innovante des portes d’avions

Chapitre 1. Introduction Générale

Souhaitant s’appuyer sur les méthodologies et outils de pointe dans le domaine de la

Le contexte des travaux de recherche, objets de ce mémoire, est ainsi celui de la

a) L'écriture des spécifications conformément au standard des métiers et aux exigences

b) L'élaboration de plusieurs architectures systèmes et leur modélisation logique haut

c) La validation et la vérification de la modélisation par rapport aux spécifications.

d) Le choix des architectures systèmes répondant au mieux, à la fois, aux exigences

Le cadre méthodologique est celui de l'Ingénierie Système, des processus afférents et

Il n’existe pas une méthodologie universellement reconnue répondant à une telle

a) des spécifications qui expriment les besoins fonctionnels et les exigences

c) une modélisation du système à concevoir dans un cadre MDA (Model Driven

d) un prototypage virtuel du système permettant, en association avec l’évaluation

Concernant les spécifications, un verrou technologique à lever concernait l'élicitation et la

A priori, le support envisagé pour la représentation du système et de ses abstractions était,

- la vérification, pour laquelle sont envisagées des méthodes nouvelles: vérification de

La suite de la démarche se focaliserait sur l’implémentation de processus de vérifications

Le travail réalisé au cours de cette thèse vise donc essentiellement à proposer à

Le chapitre IV présente la méthodologie pour l’IS proposée à LATECOERE. Cette

Le chapitre V propose une mise en œuvre de la méthodologie MICCSA au niveau des

Chapitre 2. Présentation de l’ingénierie système

Les enjeux actuels de l’IS appliquée au développement des systèmes et équipements

2.1. Historique de l’ingénierie système

L’enjeu majeur de l’effort d’ingénierie de ce système est de contrôler et maîtriser les

Dans le contexte historique de la guerre froide, le système de défense anti-aérien SAGE-

- spécification des exigences au niveau système,

Ces techniques se développent et sont adoptées progressivement dans les industries

En 1990, la National Council on Systems Engineering (NCOSE), premier organisme

La NCOSE est devenu officiellement une organisation internationale, l’INCOSE, en 1995.

(AFIS), sont partenaires de l’INCOSE et permettent aux grandes entreprises industrielles de

Conjointement aux travaux de l’INCOSE, l’institut des ingénieurs en électricité et

2.2. Ingénierie Système: problématique industrielle

Les parties électroniques et logicielle concernent principalement des éléments

L’enjeu de l’IS revient à la maîtrise des complexités inhérentes au projet et au produit,

2.2.1. Complexité liée aux processus

Le développement d’un produit est intrinsèquement un processus interdisciplinaire

De plus, les processus utilisés pour le développement au niveau système doivent se

2.2.2. Complexité liée au produit

Il s’agît de la maîtrise de l’architecture, des interfaces et des constituants du produit. La

La spécification, l’analyse et le développement des interfaces jouent un rôle prépondérant

- les effets émergents permettent de réaliser les fonctions attendues au niveau

2.2.3. Complexité liée à la performance système

2.2.4. Complexité liée au réseau d’acteurs projet

Généralement, un projet implique au moins deux acteurs : le(s) client(s) (avionneurs ou

2.2.5. Complexité liée aux coûts et délais

Le développement d’un système aéronautique se déroule dans un programme avion, à

2.2.6. Cohérence globale et décisions : problématique industrielle de

Comment traduire le besoin opérationnel du demandeur du système en objectifs

2.2.7. Questionnaire pratique

Cette démarche a permis d’identifier certaines difficultés pour l’entreprise à pratiquer de

2.3. Système, conception système et IS

Charles S. Wasson [Was_06] définit un système comme un ensemble intégré d’éléments

technologiques différentes (dispositifs électroniques, mécaniques, hydauliques, etc.) mais

dans un environnement opérationnel : La notion d’environnement est également centrale dans

Un système est un ensemble d’éléments en interaction, organisés pour atteindre un ou

Dans le domaine de l’industrie aéronautique civile, la notion de système a une définition

Dans le contexte aéronautique, un système est une combinaison d’éléments interconnectés

2.3.2. La conception système

- collecte, structuration et traitement de données techniques,

Des travaux de recherche permettent d’adopter une approche de conception adaptée à un