Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Executive Master of Engineering

GENERALISTE

Système des Systèmes

System of Systems –SoS
Chapitre 2 : L’architecture des systèmes des systèmes

Enseignant : Moncef HAMMADI – Maître de Conférences-HDR, ISAE-ISM-Supméca – Paris

Email : moncef.hammadi@isae-supmeca.fr

Page 14
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Chapitre 2 : L’architecture des systèmes des systèmes

2.1 Introduction
L’architecture de systèmes de systèmes concerne principalement l’architecture de systèmes créés
à partir d’autres systèmes autonomes. Il existe deux types de disciplines d’architectures qui sont
étroitement liées à l'architecture SoS. Premièrement, il existe une architecture système, qui concerne
principalement les personnes, les activités et les technologies, y compris la structure et le
comportement, qui constitue un système autonome au sein d’une entreprise. Alors qu'il va
normalement interagir avec d'autres systèmes autonomes de l'entreprise pour maximiser ses capacités,
ses fonctions principales ne doivent pas dépendre de ces systèmes. Ensuite, il y a l'architecture
entreprise, qui concerne principalement les ressources organisationnelles (personnes, informations,
capital et infrastructure physique) et les activités.
La figure 2.1 illustre le contexte SoS. Alors que l'architecte SoS doit prendre en compte les
caractéristiques des éléments-systèmes qui composent le SoS, la conception de ces systèmes n'est pas
son objectif principal. L'architecte SoS doit également prendre en compte le contexte d'entreprise plus
large du SoS, mais l'architecture entreprise reste la principale préoccupation de l'architecte
d'entreprise. En fait, il est souvent nécessaire que l'architecte SoS prenne en compte plusieurs
entreprises, car il n'est pas rare qu'un SoS dépasse les frontières de l'entreprise.

Figure 2.1 : Le contexte du SoS

Considérons un problème pratique lié au SoS, illustré par la figure 2.2, qui sera utilisé tout au long
de ce chapitre. Dans cet exemple, une société nord-américaine acquiert deux autres sociétés, l'une du

Page 15
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Pacifique et l'autre d'Amérique du Sud, pour former une société multinationale plus grande qui fournira
des services sans fil intégrés à des clients d'Amérique du Nord, d'Amérique du Sud et du Pacifique. Le
nouveau réseau sans fil transcontinental intégré (ITWN: Integrated Transcontinental Wireless
Network) nécessitera l’architecture d’une solution SoS composée de réseaux existants détenus et
exploités par les unités nouvellement formées.

Figure 2.2 : Réseau sans fil transcontinental intégré

Ci-dessous le problème SoS en quelques mots :
 Besoin :
o Créer un réseau transcontinental offrant des services sans fil intégrés à des clients
d'Amérique du Nord, d'Amérique du Sud et de la région du Pacifique.
o Utiliser les ressources existantes appartenant à la nouvelle entreprise.
 Ressources :
o Plusieurs réseaux sans fil en Amérique du Nord, tous connectés via le réseau optique
étendu appartenant à l'unité nord-américaine.
o Plusieurs réseaux sans fil dans la région du Pacifique, tous connectés via un système
de communication par satellite (SATCOM) appartenant à l'unité Pacific Rim.
o Plusieurs réseaux sans fil en Amérique du Sud, tous exploités en tant que réseaux
autonomes et indépendants par l'unité sud-américaine.
 Contraintes :
o Minimiser les modifications apportées aux réseaux existants.
o Continuer à fournir des services de transport optique en Amérique du Nord.
o Continuer à fournir des services SATCOM à l’aide du système SATCOM Pacific Rim.

Page 16
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Les différents réseaux du réseau nouvellement créé continueront de répondre à leurs besoins
essentiels. Le réseau optique nord-américain continuera à fournir des services de transport généraux
aux clients, en plus de la connexion aux réseaux sans fil régionaux ; et le système SATCOM de Pacific
Rim continuera à fournir des services SATCOM dans toute la région du Pacifique, en plus de la
connexion aux réseaux sans fil régionaux. La création du réseau ITWN nécessitera la création d'une
solution SoS offrant de nouvelles fonctionnalités créées à partir de l'intégration de réseaux existants,
tout en continuant de répondre aux besoins essentiels des réseaux autonomes.
Cet exemple SoS met en évidence de nombreux défis uniques liés à l’architecture des solutions
SoS - et ils sont nombreux -, mais certaines idées de base s’appliquent à tous les types de problèmes
de conception d’architecture. Après avoir discuté de ces idées de base (processus de conception
d'architecture et principes d'architecture s'appliquant de la même manière à l'architecture de tous les
types de systèmes), nous aborderons des considérations spéciales et des facteurs de succès critiques
pour l'architecture de solutions SoS.
2.2 Principes et pratiques d'architecture
La conception d’une architecture commence par la reconnaissance d’un besoin, l’énoncé du
problème et la formulation d’une stratégie de solution. Il continue avec la synthèse de solutions et
l'analyse d'alternatives. Il se termine par un modèle d'architecture, un modèle du système à construire.
Bien que le processus soit assez simple, il est compliqué par le fait que la conception ne découle pas
logiquement des besoins. Le design est une entreprise vraiment humaine. Bien que toutes les
conceptions soient finalement dictées par les besoins et tendent à s'appuyer sur les solutions
précédentes, la conception implique un compromis et il n'existe pas de recette simple pour faire les
compromis nécessaires. Cependant, il existe un processus bien défini pour l'architecture des systèmes
et un ensemble de principes consacrés pour la navigation dans l'espace des solutions.
2.2.1 Le processus de conception de l'architecture SoS
Le processus de conception de l’architecture de base SoS, illustré à la figure 2.3, commence par
l’analyse des besoins, procède à la synthèse de la solution et se termine à l’évaluation de la solution
pour répondre aux besoins exprimés.
Le processus de conception de l'architecture comprend les éléments suivants :
 Analyse - analyse des besoins
 Synthèse - synthèse de solutions
 Évaluation - évaluation des solutions
Analyse des besoins :
Parfois, les besoins sont bien compris et même clairement communiqués par le biais d'exigences.
Mais il est rare que tous les besoins soient compris, et encore moins documentés sous forme

Page 17
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

d'exigences concises. Que les besoins soient communiqués de manière concise et complète via des
exigences ou communiqués à l'aide de simples déclarations de besoins ou de descriptions de concept
opérationnel, il appartient néanmoins à l'architecte de bien comprendre les besoins.

Figure 2.3 : Le processus de conception de l'architecture SoS

Si les besoins ont été minutieusement examinés, les exigences les plus contradictoires et les plus
infaisables supprimées et communiquées de manière concise, l'analyse des besoins est certainement
plus facile et prend moins de temps que ce ne serait autrement le cas. De plus, il n’est pas rare que les
besoins exprimés soient fondés sur la perception ou les croyances populaires. Bien que les besoins
simplement perçus ne puissent être ignorés, le concepteur doit pouvoir les séparer des besoins réels.
L'étape d'analyse est critique et son omission entraîne généralement un risque pour les étapes restantes.
Bien que la compréhension des besoins soit d’une importance capitale, la compréhension des
contraintes de la solution ne peut être négligée. Il est impossible de produire un design efficace sans
tenir pleinement compte de l'espace de contrainte. Dans certains cas, les contraintes peuvent influencer
la conception autant que les besoins. Cela est particulièrement vrai pour le SoS, où les solutions
reposent largement sur les systèmes et infrastructures existants. Bien que ces ressources fournissent
une base riche pour la construction de nouvelles solutions, elles limitent également la solution de
manière significative.
Synthèse des solutions :
La prochaine étape du processus de conception de l'architecture est la synthèse de la conception.
Cette étape du processus est en grande partie une étape de transformation, au cours de laquelle les
besoins et les contraintes sont transformés en solutions. Alors que les étapes avant et après sont avant
tout des étapes analytiques, la synthèse est plus créative. C'est là que le concepteur met le stylo sur du

Page 18
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

papier et que l'invention se produit. La synthèse est le lieu où tous les besoins concurrents et les
contraintes vexantes sont fusionnés en une solution. Il n'y a pas de recette pour cette partie ; c'est une
entreprise vraiment humaine.
Evaluation des solutions :
La dernière étape du processus de conception est l'évaluation. Tout d’abord, il s’agit de
l’évaluation des variantes de conception résultant de la synthèse de la conception. La simulation
numérique reste une méthode efficace d’évaluation des différentes variantes de solutions. Il s’agit tout
d’abord d’identifier plusieurs alternatives de conception et de les évaluer par rapport à un ensemble de
critères. L’évaluation de plusieurs alternatives est considérée comme une pierre angulaire du processus
de conception d’une architecture SoS.
Cependant, l’évaluation des solutions de remplacement n’est pas le seul aspect de l’évaluation de
la conception ; il y a aussi d'autres préoccupations. Parmi les préoccupations les plus importantes, les
deux qui tendent à éclipser toutes les autres sont le coût et la capacité. Il n’est pas surprenant que les
coûts et les capacités tendent à orienter la sélection et l’affinement de la conception finale. En fait,
c’est ce problème économique fondamental de maximisation des capacités tout en minimisant les coûts
qui sont à la base de beaucoup d’innovations.
En plus de leur capacité à séparer les alternatives et à permettre la sélection en aval d'une seule
«meilleure» alternative, les évaluations des coûts et des performances sont également susceptibles
d'optimiser la conception. L’évaluation est l’étape de la conception de l’architecture au cours de
laquelle des améliorations critiques sont apportées. Les conceptions sont simplifiées pour éliminer la
complexité inutile, réduire les coûts, réduire les risques et améliorer la fiabilité. Des solutions de
remplacement moins coûteuses pour les solutions de composants sont explorées et évaluées ; et surtout,
les performances sont optimisées.
2.2.2 Principes de conception d'architecture SoS
Au-delà des étapes de base de la conception d'architecture décrites dans la section précédente, un
ensemble de principes directeurs est nécessaire. Ces principes constituent la base des quatre principes
de conception d’architecture discutés ici, principes qui doivent être pris en compte dans l’architecture
de tous les SoS.
Les quatre principes sont :
 Les besoins sont souvent en concurrence.
 Les besoins changent avec le temps.
 La disponibilité des ressources limite l'espace de la solution.
 Un compromis de conception est nécessaire.

Page 19
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Les besoins sont souvent en concurrence :

Le problème avec les besoins est qu’ils ont tendance à être concurrentiels. En d’autres termes,
l’ensemble des besoins appelle généralement des solutions qui se font concurrence. Dans un véhicule
à moteur, par exemple, le besoin d'efficacité énergétique et de puissance (deux besoins légitimes) tend
à se faire concurrence. Le concepteur doit faire face à ces besoins concurrents de manière à trouver le
juste équilibre entre efficacité énergétique et réactivité. Pour atteindre cet équilibre, il faut sacrifier la
satisfaction optimale d'un besoin afin de satisfaire certains besoins concurrents à un degré acceptable.
Les besoins changent avec le temps :
La viabilité d'une solution ne peut être évaluée sans prendre en compte les circonstances qui en
font la nécessité. Considérez le problème des personnes qui communiquent rapidement, sur de longues
distances. Ce besoin a été satisfait au XIXe siècle avec le télégraphe. Si le télégraphe était une très
bonne solution à ce problème au XIXe siècle, il serait tout à fait insuffisant aujourd’hui : le besoin a
changé. Bien que le besoin fondamental en matière de communication à distance existe encore de nos
jours, il est devenu beaucoup plus complexe, en grande partie à cause de l'évolution de la technologie
et des attentes des utilisateurs.
Il faut du temps pour concevoir et construire des systèmes. L'analyse, la synthèse et l'évaluation
prennent du temps ; la mise en œuvre, les tests et le déploiement prennent du temps ; et il faut du temps
pour que les solutions prennent forme. De plus, c’est la nécessité qui importe vraiment, et non pas au
moment de la conception, ni même au moment de la mise en service du système, mais bien au-delà de
la nécessité présente au plus fort du cycle de vie du système. Et il n'est pas rare que des systèmes
fonctionnent pendant des décennies avant que des ressources adéquates soient disponibles pour les
remplacer. Lorsqu'un besoin clair est présent en même temps que les ressources disponibles, les
circonstances sont propices à une solution potentielle. Et lorsque ces circonstances persistent pendant
une durée suffisante, ce qui est suffisant pour que la conception et la mise en œuvre se déroulent
correctement, il est alors possible de résoudre un problème. Les besoins des utilisateurs sont à la fois
un ami nécessaire et un adversaire non motivé en matière d'architecture de systèmes.
La disponibilité des ressources limite l'espace de la solution :
La conception, la mise en œuvre, l'exploitation et la maintenance de tous les systèmes dépendent
de la disponibilité des ressources. La première et sans doute la ressource la plus critique est l’argent.
Construire des systèmes complexes n'est pas bon marché. Sans investissement en capital, il est
impossible de réunir des équipes pour effectuer des activités d'analyse, de synthèse et d'évaluation, se
procurer les composants technologiques nécessaires, intégrer et tester le système, le mettre en service
et le maintenir tout au long de son cycle de vie.

Page 20
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Mais l'argent ne suffit pas. Les personnes possèdent une autre ressource essentielle - les
connaissances et les compétences - sans laquelle il est impossible de concevoir, mettre en œuvre, tester,
déployer et exploiter des systèmes complexes. Et il n'est pas toujours possible d'acheter les
connaissances et compétences requises. Envisager le développement précoce de ponts suspendus à
longue portée. Ces ponts et l’argent nécessaire pour les construire bien avant leur construction étaient
certes nécessaires, mais les connaissances et compétences requises faisaient défaut, et l’absence de
cette ressource essentielle constituait un obstacle à leur conception et à leur construction.
La disponibilité des technologies nécessaires est également une ressource essentielle. Les
systèmes centrés sur le réseau - les systèmes distribués connectés via des réseaux de communication -
ne seraient pas possibles sans plates-formes informatiques à haut débit, réseaux de communication à
large bande passante et à faible temps de latence, et capacité omniprésente dans les deux cas. Un cas
particulier de ressources technologiques - la disponibilité des systèmes et infrastructures existants - est
particulièrement pertinent pour l'architecture SoS.
Un compromis de conception est nécessaire :
Le principe final - la nécessité d'un compromis de conception - est un résultat inévitable des trois
premiers principes. La conception dépend des besoins - qui ont tendance à être concurrentiels et
évoluent avec le temps - et est limitée par la disponibilité des ressources. Un compromis est nécessaire
pour créer une solution qui établit un équilibre entre les besoins concurrents. Un compromis est
nécessaire pour créer une solution robuste face à l'évolution des besoins ; et un compromis est
nécessaire pour faire face aux contraintes de ressources. C'est un dilemme et il n'y a pas de solution de
facilité. La nécessité d'un compromis est inévitable.
Une décision cruciale liée au compromis de conception est la mesure dans laquelle les contraintes
de ressources permettront de gérer la solution avant de tenter de modifier l’espace de contrainte.
Parfois, la dépendance vis-à-vis des technologies existantes impose des contraintes excessives à
l’espace de la solution. Dans de tels cas, il est souvent nécessaire d’investir dans une initiative de
développement technologique pour déplacer l’espace de contrainte des ressources.
Un problème connexe est la nécessité d'équilibrer l'analyse et la synthèse descendantes avec une
analyse et une synthèse ascendantes. Il est important de procéder à une analyse descendante pour
s'assurer que les problèmes les plus importants sont traités de manière adéquate et que leur conception
ne repose pas sur des solutions ponctuelles. Ignorer l'analyse ascendante présente toutefois un danger.
Plus l'espace des ressources technologiques est restreint, plus il est important de procéder à une analyse
et à une synthèse approfondies de bas en haut. Et comme l’architecture SoS dépend énormément de

Page 21
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

l’utilisation des systèmes et de l’infrastructure existants, il est essentiel d’accorder une attention
suffisante à l’analyse ascendante.
Prenons l'exemple d'ITWN discuté plus tôt. Les réseaux régionaux doivent tous être connectés.
Une analyse des solutions de rechange a montré que l’approche la plus rentable serait de louer des
services de transport optique à un grand transporteur optique international. Mais cela ne répondrait pas
au besoin des entreprises de tirer parti de l’investissement dans le système SATCOM existant. Ainsi,
la décision de l’architecture SoS d’utiliser la surcapacité dans le système SATCOM, illustrée à la figure
2.4, a finalement été un compromis de conception pour répondre à un besoin commercial.

Figure 2.4 : Connectivité physique du réseau sans fil Transcontinental

Le principe de compromis, qui pousse l'architecte à créer une solution SoS complète intégrant tous
les pilotes, les besoins et les contraintes de la conception, fait les compromis nécessaires pour trouver
un juste équilibre entre des besoins concurrents, et fait les compromis de conception nécessaires pour
faire face aux contraintes. En fin de compte, puisque tous les modèles sont le résultat de compromis,
il n’existe vraiment aucun modèle parfait, mais seulement ceux qui sont moins défectueux que
d’autres.
2.3 Les considérations sur l'architecture SoS

Alors que le processus de conception d'architecture et les principes de conception d'architecture

s'appliquent à l'architecture de système à tous les niveaux, l'architecture de solutions SoS nécessite
certaines considérations spéciales. Les considérations suivantes sont à prendre en considération :
 Autonomie

Page 22
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

 Complexité
 La diversité
 Stratégie d'intégration
 Architecture de données
 Protection du système
2.3.1 Autonomie
Les éléments SoS sont eux-mêmes des systèmes autonomes. Ils ont leurs propres parties prenantes
et leur propre mission dans leurs entreprises respectives ; ils ont leurs propres processus opérationnels,
organisations de gestion et budgets de fonctionnement ; ce sont des systèmes autonomes et ils doivent
conserver cette autonomie même après l'intégration de SoS. En termes simples, l’intégration de SoS
ne peut pas faire quelque chose qui compromet l’intégrité des systèmes qui composent le SoS.
L’autonomie des systèmes doit être préservée à deux niveaux : l’autonomie technique et l’autonomie
opérationnelle.
L'autonomie technique est liée aux plates-formes, interfaces et infrastructures des systèmes
existants. L'intégrité des interfaces externes doit être préservée, car elles pourraient être essentielles à
la mission principale du système. Ces interfaces externes peuvent en réalité avoir peu à voir avec la
solution SoS. Néanmoins, ils doivent être préservés. L'intégrité des plates-formes système doit
également être préservée. Il n'est pas rare qu'une solution SoS paraisse saine, mais une évaluation
ultérieure révèle la nécessité de procéder à des mises à niveau majeures non planifiées des plates-
formes existantes. Une telle situation risque de constituer une charge excessive pour le maintien du
système existant et de mettre en péril sa mission première.
Il y a aussi des considérations d'infrastructure. Il est assez courant qu'une solution SoS nécessite
d'importantes améliorations imprévues de l'infrastructure, ce qui affectera certainement les budgets
d'investissement pour l'exploitation et la maintenance des systèmes existants. Il est souvent nécessaire
de perturber l’autonomie technique des systèmes lorsqu’ils font partie d’un système plus vaste, mais
il est important que les modifications soient planifiées et que l’autonomie technique soit rétablie.
L'autonomie opérationnelle est liée aux organisations et aux processus métiers. Les organisations
au sein de l'entreprise sont structurées pour exploiter et maintenir des systèmes. Ces organisations ont
des processus opérationnels pour exploiter et maintenir leurs systèmes organiques. Il existe également
des relations organisationnelles avec d'autres entreprises, liées aux systèmes de chacune de ces
entreprises. Les organisations, les relations organisationnelles et les processus métiers sont au cœur de
l'architecture opérationnelle d'une entreprise. Il est important de préserver l’autonomie opérationnelle
des systèmes lorsqu’ils font partie d’un plus grand réseau de services. A l'instar de l'autonomie

Page 23
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

technique, il est souvent nécessaire de perturber l'autonomie opérationnelle de systèmes individuels

dans le SoS mais il est essentiel que l'autonomie opérationnelle soit rétablie.
2.3.2 Complexité
L'utilisation de systèmes existants pour créer des solutions SoS introduit des complexités
inévitables, à la fois en termes de contraintes et de conséquences. Les systèmes et infrastructures
existants constituent un bon point de départ, car ils sont déjà en place, mais ils limitent également la
solution. Ces contraintes ne sont généralement pas simples et sont rarement bien documentées. Il existe
souvent des éléments en place pour prendre en charge les systèmes existants qui ont peu de valeur du
point de vue des systèmes de systèmes. Malheureusement, ils ajoutent de la complexité à la solution
SoS. C'est une sorte de taxe d'utilisation des systèmes et infrastructures existants.
Un autre aspect de la complexité du SoS est la spécialisation naturelle et l'optimisation des
systèmes pour qu'ils remplissent leurs fonctions principales. Les lois fondamentales de l'économie
conduisent à des systèmes qui se spécialisent pour résoudre leur problème spécifique de la manière la
plus rentable. Bien que la spécialisation et l'optimisation conviennent aux systèmes autonomes, elles
aboutissent à différentes solutions souvent incompatibles. La gestion des incompatibilités nécessite
généralement l’introduction de «ponts» dans la solution SoS, ce qui ajoute encore de la complexité.
Enfin, il y a le problème des partitions d'architecture fonctionnelle floue, les lacunes et les
chevauchements dans les responsabilités fonctionnelles. La nécessité de préserver l'autonomie
technique signifie souvent que plusieurs systèmes dans un SoS remplissent des fonctions similaires,
voire identiques, et le font souvent de manière très différente.
2.3.3 Diversité
Les systèmes qui composent un SoS sont divers. Bien que cela soit souvent utile du point de vue
de la robustesse (réduction des faiblesses du mode commun), cela crée également des défis pour
l’architecte SoS. Le premier défi est la diversité des besoins. Chaque système d'un SoS est
probablement motivé par un certain ensemble de besoins, qui ont tendance à évoluer avec le temps.
Au fur et à mesure que les circonstances qui ont motivé le besoin primaire évoluent, l'analyse de
rentabilisation du système lui-même évolue. L'évolution des besoins des parties prenantes pour les
systèmes au sein d'un système de systèmes entraînera probablement différentes voies d'évolution. Les
besoins divergents des systèmes au sein d'un SoS peuvent littéralement ‘déchirer’ la solution SoS.
Le deuxième défi est la diversité environnementale. Étant donné que chaque système d'un SoS est
susceptible d'être géré séparément, avec des contraintes budgétaires, des environnements politiques et
des dirigeants distincts, ils sont chacun soumis à un ensemble de forces différentes qui façonnent leur
évolution. À l'instar des besoins divergents, les environnements divergents peuvent également être une
source de grande pression pour toute solution SoS.

Page 24
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

2.3.4 Stratégie d'intégration

Normalement, lorsqu'un système est architecturé, il est partitionné en différentes entités, chacune
ayant un ensemble de responsabilités de base au sein du système et conçues pour être intégrées de
manière à former le système global. Ce n'est pas typiquement vrai pour un SoS. Le SoS est composé
de systèmes autonomes qui n'ont pas été principalement conçus en tant que composants d'un système
plus grand. Au-delà des interfaces externes connues, il est peu probable qu'elles aient été conçues avec
l'intégration externe en tête.
La création du SoS doit répondre à trois problèmes d’intégration de base. Le premier et le plus
évident est l'intégration physique. Il est peu probable que tous les systèmes dotés de SoS utilisent des
protocoles d'interface compatibles. Alors que la demande croissante de solutions SoS a entraîné (au
moins en partie) une diminution de la diversité des protocoles et une normalisation accrue, il reste
nécessaire de disposer de protocoles différents. Les systèmes évoluent indépendamment, avec leur
propre ensemble de pilotes d'optimisation et de spécialisation. Le résultat naturel est l'utilisation de
différents protocoles, dont beaucoup ne sont pas standard. Ce problème d'intégration physique doit
être résolu.
Le deuxième problème est l'intégration fonctionnelle. Étant donné que les systèmes existants
servent de blocs de construction pour le SoS, les fonctions exécutées par les différents systèmes du
SoS doivent être intégrées et ‘déconflictifiées’. Les partitions fonctionnelles floues sont le résultat de
plusieurs systèmes remplissant des fonctions similaires ou identiques. Étant donné que les systèmes
au sein du SoS doivent préserver leur autonomie technique, une isolation fonctionnelle (ou
amortissement) est souvent requise. L'isolation fonctionnelle consiste à isoler les fonctions d'un
système du SoS à être exécutées par un autre système dans le même SoS. L'amortissement fonctionnel
implique la mise en sourdine de certains aspects des fonctions du système pour permettre aux systèmes
de bien fonctionner ensemble.
Le troisième problème est l'intégration sémantique. L'intégration sémantique concerne la manière
dont les signaux ou les données sont interprétés par différents systèmes. Par exemple, supposons qu'un
SoS se compose de trois systèmes différents qui se fournissent mutuellement leur statut. Chacun d’eux
est susceptible de définir son statut en fonction de ses propres besoins.
Il existe deux stratégies de solution de base pour l’intégration de systèmes dans le SoS, des
stratégies qui traitent des aspects d’intégration physique, fonctionnelle et sémantique. La première
stratégie - et probablement la plus courante - est le pontage (‘bridging’) du SoS, qui consiste à
introduire un nouveau système chargé de gérer les aspects d'intégration physique, fonctionnelle et
sémantique. La deuxième stratégie est la refactorisation (‘refactoring’) de SoS, qui consiste à modifier

Page 25
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

les systèmes existants de manière à rendre inutile la transition. Il existe de bonnes raisons d’adopter
chacune de ces stratégies, mais en définitive, l’architecte du SoS doit décider laquelle sera utilisée.
La figure 2.5 illustre le pontage de SoS et la figure 2.6 illustre le refactoring de SoS. L'approche
de pontage, basée sur la combinaison de deux modèles de conception bien documentés (l'adaptateur et
le pont), présente l'avantage de minimiser la modification des systèmes existants, la plupart des
exigences d'intégration physique, fonctionnelle et sémantique étant satisfaites par le pont SoS. Mais la
transition ajoute de la complexité à la solution et peut être lourde du point de vue des opérations et du
maintien en puissance. L’approche de refactoring minimise généralement la complexité des systèmes
d’activité, facilite leur utilisation et augmente la durabilité, mais est généralement plus onéreuse à court
terme et perturbe davantage les systèmes existants.

Figure 2.5 Le bridging du SoS Figure 2.6 Le refactoring du SoS

La plupart des architectures SoS, du moins au début, utilisent la transition. Il offre une approche
de faible risque pour l’intégration de systèmes et a tendance à être moins coûteux à court terme. Mais
étant donné que le résultat est souvent plus complexe et moins exploitable / durable, il est nécessaire
d’évaluer les avantages de l’utilisation d’une stratégie de refactoring, soit initialement, soit à un
moment quelconque après la mise en service de la stratégie de sécurité initiale.

Considérons l'application du bridging dans l'exemple ITWN. Alors que l'Amérique du Nord et
l'Amérique du Sud utilisent des protocoles sans fil compatibles, le Pacific Rim utilise un protocole
sans fil différent et nécessitera l'utilisation de ponts (communément appelés passerelles dans la
communauté des télécommunications) pour permettre l'intégration des différents réseaux.
2.3.5 Architecture de données
La plupart des solutions SoS ont deux besoins en termes d'architecture de données. Premièrement,
il est nécessaire d’assurer la cohérence et la sémantique des données. Ensuite, il est nécessaire de

Page 26
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

prendre en charge le besoin de stockage persistant de données partagées, c'est-à-dire les informations
dont plusieurs systèmes ont besoin dans le système de distribution, même si elles appartiennent à un
seul système au sein du système de distribution.
Une base de données unique pour l’ensemble du SoS peut sembler être une bonne approche (moins
complexe, moins risqué en termes d’intégrité des données et plus économique à créer et à gérer), mais
présente deux inconvénients importants, ce qui limite son utilité pratique pour le SoS. Premièrement,
une base de données centrale ne préserverait pas l’autonomie des systèmes existants. Deuxièmement,
il est souvent difficile de respecter les niveaux de performances et de disponibilité requis dans un
environnement SoS.
Trois autres stratégies de stockage de données sont apparues pour le SoS, des modèles qui
préservent l'autonomie du système et facilitent la gestion des exigences de performance et de
disponibilité. La première stratégie, qui à première vue ne semble pas du tout être une stratégie, est le
modèle de données non coordonnées (illustré à la figure 2.7). Le modèle de données non coordonnées
n'est en fait pas une mauvaise approche. Bien que cela nécessite l'échange de données partagées via
des interfaces système-à-système traditionnelles et que chaque système traite les problèmes de
structure de données et sémantiques à sa manière, il s'agit d'une stratégie simple et économique. Ses
principaux inconvénients sont le risque de problèmes de structure et de sémantique des données, ainsi
que le volume potentiellement élevé de données dupliquées échangées via les interfaces. Néanmoins,
il s'agit d'une stratégie pratique pour les problèmes de SoS dans lesquels il est prévu que le volume de
données partagées sera faible, avec un risque faible de structure de données et de problèmes
sémantiques.

Figure 2.7 : Modèle de données non coordonnées

La deuxième stratégie - le modèle de données coordonnées - atténue un aspect clé du modèle de
données non coordonnées, le problème sémantique. Le modèle de données coordonnées (voir Figure
2.8) implique un accord coordonné sur le format et la sémantique des données. Ceci est le modèle
utilisé pour la plupart des SoS dans lesquels on prévoit un faible volume de données partagées. Il

Page 27
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

présente la simplicité du modèle de données non coordonnées mais ajoute des accords documentés sur
la structure et la sémantique des données. Il n'est pas rare de commencer avec le modèle de données
non coordonnées et de passer au modèle de données coordonnées au fur et à mesure de l'apparition de
problèmes de structure de données et de problèmes sémantiques.

Figure 2.8 : Modèle de données coordonnées

La troisième stratégie - le modèle de données fédérées - est l'approche la plus sophistiquée pour
le SoS et s'applique mieux lorsque le volume de données partagées est élevé et que le risque de structure
de données et de problèmes sémantiques est élevé. Le modèle de données fédérées (illustré à la figure
2.9) est la seule stratégie parmi les trois qui possède une base de données SoS distinct en dehors des
systèmes existants. Le référentiel de données SoS contient des données partagées utilisées par les
systèmes au sein de SoS. Les données partagées appartiennent généralement à un SoS de gestion de la
sécurité et sont enregistrées dans le référentiel de données de ce système dans un format convenu. Il
n'est pas rare que le système propriétaire des données partagées ait son propre format interne et
enregistre le format convenu dans la base de données SoS. À titre de mise en garde, bien qu'il soit
tentant de publier TOUTES les données SoS dans le référentiel de données d'entreprise, cela représente
une charge inutile pour le référentiel de données SoS et peut souvent conduire à une solution trop
coûteuse et souvent ingérable.

Figure 2.9 : Modèle de données fédérées

Page 28
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

2.3.6 Protection du SoS

La protection des systèmes au sein du SoS est une considération importante. Permettre aux
systèmes d'interagir les uns avec les autres, tout en empêchant l'accès non autorisé aux données du
système et à d'autres ressources, n'est pas une mince tâche. La sécurisation des systèmes implique la
réalisation de quatre objectifs de sécurité clés :
 Confidentialité - prévention des accès non autorisés
 Authentification - fournissant un moyen d'identifier les utilisateurs autorisés
 Intégrité - restreindre la modification non autorisée de ressources
 Non répudiation - garantir l'identité des consommateurs et des fournisseurs de ressources
Mais la sécurité n'est qu'un aspect de la protection. Un autre aspect de la protection est la
perturbation involontaire par d'autres systèmes au sein du système de surveillance. Prenons le cas où
un système du SoS fournit une fonction clé dans le SoS, une fonction accessible par d’autres systèmes
au sein du SoS. Il est possible pour les systèmes utilisant cette fonction de surcharger le système qui
fournit la fonction. Il est également possible qu’une défaillance d’un système du SoS se répercute sur
d’autres systèmes du SoS.
L'isolation du système est une technique couramment utilisée pour la protection contre les
perturbations involontaires. L'isolation consiste à introduire une couche de séparation entre les sous-
systèmes internes d'un système et les systèmes externes avec lesquels il interagit.
2.4 Facteurs de succès critiques dans l’architecture des solutions SoS
Plusieurs facteurs sont essentiels à la réussite de l’architecture des solutions SoS. Ces facteurs
peuvent faire la différence entre une solution réussie et une solution infructueuse. Les facteurs abordés
ici s’appliquent à l’architecture système traditionnelle et à l’architecture SoS, mais sont
particulièrement importants pour l’architecture SOS. Bien qu’il ne s’agisse nullement d’une liste
exhaustive, ces facteurs constituent une liste de choses à ne pas négliger. Ils incluent :
 Conception robuste
 Alignement d'architecture
 Gouvernance de l'architecture
 Description de l'architecture
2.4.1 Conception robuste
Un système robuste est un système dans lequel le système remplit ses fonctions dans toutes les
conditions environnementales. Il existe trois aspects importants de la robustesse de l’architecture pour
les SoS, qui sont directement liés au fait que les systèmes au sein d’un SoS sont divers et doivent
conserver leur autonomie.

Page 29
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

Le premier aspect de la robustesse - la robustesse des analyses de rentabilisation - est lié au fait
que les besoins évoluent avec le temps. Au fur et à mesure que les besoins de systèmes individuels
évoluent, leur rôle dans le SoS peut être affecté. Par conséquent, il est important que le bon
fonctionnement du SoS ne soit pas trop sensible aux modifications de l'analyse de rentabilisation de
chaque système au sein de SoS. Par exemple, prenons l'exemple ITWN, dans lequel le système
SATCOM fait partie intégrante de l'architecture. Alors que le système SATCOM touche à sa fin de
vie, il n’est pas impensable que le système SATCOM soit abandonné et remplacé par des services de
transport loués. Une conception robuste serait insensible aux modifications du mécanisme de transport.
Le deuxième aspect de la robustesse - la robustesse de la planification - est lié à la capacité d'un
système au sein d'un système de systèmes à fournir la capacité nécessaire à temps. Il n’est pas rare que
les améliorations du système soient retardées pour des problèmes techniques ou financiers. Si
l'amélioration prévue de l'un des systèmes au sein du SoS est une capacité critique pour le SoS, la
conception n'est pas très robuste. Une conception plus robuste du point de vue robustesse de la
planification, consisterait à adopter une approche d’urgence pour répondre au besoin essentiel du SoS.
Le troisième aspect de la robustesse - la robustesse technologique - est lié à l'environnement
technologique. Prenons le cas où la solution SoS est basée sur une standardisation du protocole de
communication au sein du SoS. Dans cet exemple, une analyse des solutions de rechange aurait pu
indiquer qu'un protocole de communication particulier était le meilleur. Cependant, avec le temps, un
meilleur protocole est apparu et les systèmes du SoS ont commencé à migrer vers le nouveau protocole.
Une conception robuste supposerait qu’il existerait au sein du SoS une variété de protocoles différents
que les systèmes du SoS devraient prendre en charge.
2.4.2 Alignement d'architecture
S'il est nécessaire que les systèmes au sein du SoS conservent leur autonomie, il est pratiquement
impossible de créer ou d'améliorer une solution SoS sans interruption. L’architecte des systèmes de
traitement doit supposer qu’une perturbation va se produire et planifier un réalignement pour rétablir
la résonance de l’architecture. Il faut prendre en compte trois aspects importants de l’alignement de
l’architecture. Le premier aspect - alignement organisationnel - implique de réaligner les organisations
pour qu'elles fonctionnent dans le contexte du SoS. Le deuxième aspect, l'alignement des processus
métier, implique la mise à jour des processus et procédures métiers pour qu'ils fonctionnent dans le
contexte SoS. Le troisième aspect - l'alignement technologique - implique l'alignement des aspects
technologiques.
Prenons l'exemple ITWN dans lequel les trois systèmes sont nécessaires. Chacun de ces systèmes
possède des organisations pour la fourniture de services et la gestion de réseau, mais aucun n'a été

Page 30
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

conçu pour interagir avec d'autres organisations. Chacune de ces organisations devra apporter des
modifications internes pour s'adapter à l'architecture SoS. De plus, étant donné que chaque système
dispose de processus et de procédures métiers pour la fourniture d'un service (et qu'aucun de ces
processus ou procédures n'interagit avec d'autres organisations), les processus et procédures devront
être réalignés pour fonctionner efficacement dans un contexte SoS. Enfin, chaque système pourrait
avoir une signification fondamentalement différente pour le terme service de communication - non
seulement une différence sémantique, mais également une différence substantielle en termes de mise
en œuvre technique. Ces différences techniques devront être abordées.
2.4.3 Gouvernance de l'architecture
S'il est important que les systèmes au sein d'un sous-système maintiennent leur autonomie, il n'est
toutefois pas pratique de permettre des modifications non coordonnées. Lorsqu'un système devient
partie intégrante d'un SoS, il devient partie intégrante d'une fédération de systèmes plus grande et cette
fédération doit avoir des règles que tous les membres de la fédération acceptent d'honorer. Ces règles
constituent la base de la gouvernance de l'architecture. Sans gouvernance, maintenir le bon
fonctionnement d'un SoS est presque impossible.
Il existe deux aspects de la gouvernance d’architecture pertinents pour les systèmes d’intérêt. Le
premier aspect - la gouvernance des rôles et des responsabilités - est lié à la résolution du problème de
la partition floue. Étant donné que les systèmes individuels doivent évoluer avec le temps, leur rôle au
sein du SoS pourrait devoir être réexaminé. La mise en place de mécanismes de gestion des rôles et
des responsabilités permet le changement, mais pas de manière non coordonnée.
Le deuxième aspect de la gouvernance de l'architecture, la gouvernance des interfaces, concerne
les détails des interfaces SoS. Dans le cas de SoS, ceux-ci peuvent également devenir flous. Prenons
l'exemple dans lequel un système de SoS publie des données partagées. Tout système du SoS peut
extraire les données partagées. Lorsqu'une décision est prise de changer la structure ou la sémantique
des données partagées (même de la manière la plus infime), il est important que le changement soit
coordonné avec tous les utilisateurs des données. Les personnes concernées incluent non seulement
les utilisateurs actuels des données, mais également ceux qui sont en train d'apporter des modifications
à leurs systèmes internes pour pouvoir utiliser les données à l'avenir.
2.4.4 Description de l'architecture
Les systèmes devenant de plus en plus complexes, il devient de plus en plus important de
représenter l'architecture à l'aide d'un modèle bien défini. Le modèle d'architecture fournit un moyen
d'effectuer une analyse de la structure et du comportement du système et fournit également une feuille
de route pour ceux qui implémentent l'architecture. De plus, à mesure que le nombre de personnes
impliquées dans l'analyse, la synthèse, l'évaluation, la mise en œuvre et le fonctionnement du système

Page 31
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

augmente, la description de l'architecture à l'aide d'un ensemble bien défini de modèles et de

sémantique devient très importante.
Les descriptions d'architecture sont nécessairement élaborées à partir de plusieurs points de vue :
aucun point de vue unique de l'architecture ne rend correctement compte des aspects les plus saillants
de l'architecture d'un système. (La description de l'architecture des systèmes complexes est devenue
très similaire aux dessins à vues multiples utilisés dans l'architecture des bâtiments.)
L'utilisation d'un Framework d'architecture présente clairement des avantages. Les frameworks
d'architecture fournissent une feuille de route pour décrire l'architecture d'un système. Ils constituent
en quelque sorte une liste de contrôle de toutes les préoccupations à prendre en compte lors de la
conception de l'architecture de SoS. Ils fournissent également un riche ensemble de sémantiques pour
la représentation de l'architecture, ainsi que des métadonnées pour la description de l'architecture elle-
même.
Mais il y a aussi des dangers. Les cadres d'architecture sont conçus pour être complets. En
conséquence, ils spécifient un ensemble complet de vues. En réalité, peu de descriptions d'architecture
doivent capturer tout ce qui est spécifié dans un framework : une adaptation est presque toujours
nécessaire. Ne pas adapter le framework de manière adéquate peut entraîner une spécification
excessive et une trop longue période de description de l'architecture, trop peu consacrée aux aspects
les plus importants de la conception. Un autre danger des cadres d’architecture est qu’ils peuvent
conduire à un faux sentiment d’adéquation ; le résultat est une solution bien décrite mais mal conçue.

2.5 Framework d’architecture système

Nous terminons ce chapitre par une discussion de certains frameworks d’architecture spécifiques.
Chacun de ces cadres a été conçu pour répondre à un besoin spécifique. Si certains d'entre eux sont
plus adaptés à l'architecture SoS que d'autres, ils peuvent tous être utilisés. Les cadres sont énumérés
ci-dessous :
 Le framework de Zachman
 Le framework d'architecture du département de la Défense (DoDAF)
 Le framework d'architecture du ministère de la défense (MoDAF)
 Le framework fédéral d'architecture d'entreprise (FEA)
 Le framework unifié rationnel (RUP)
 Le framework d'architecture de groupe ouvert (TOGAF)
Un sujet étroitement lié aux frameworks d'architecture est les langages de modélisation. Le
langage de modélisation unifié (UML ™) est un langage de modélisation général créé pour représenter
les systèmes à prépondérance logicielle. Bien qu'il ait été utilisé pour représenter des systèmes

Page 32
Executive Master of Engineering - GENERALISTE Module: Système des Systèmes

généraux, il convient mieux à la modélisation d'architectures logicielles. L’extension d’UML pour

mieux représenter les problèmes du système a conduit à la création de SysML™. La création de SysML
est bien plus qu’une simple adaptation d’UML ; c'est un langage de modélisation beaucoup plus
complet pour décrire les systèmes. Bien que ni UML ni SysML ne soient des structures d'architecture,
ils spécifient tous les deux un langage de modélisation pouvant être utilisé dans les structures
d'architecture pour créer des produits ou des modèles de vue spécifiques.

Page 33