Réflexion sur l'évolution des cadres d'architecture - 2ème Partie

Ali Koudri

Pour répondre aux problèmes posés dans la première partie, notre approche s'inscrit dans une démarche qui est à la fois "top-down" et "bottom-up" dans le sens où elle mélange des modèles à la fois prescriptifs et descriptifs. Dans cette approche, chaque partenaire apporte son système: avion, tour de contrôle, antenne météo, système de gestion de crise. Dans une démarche MBSE, on peut considérer que ces systèmes sont décrits par des modèles qui sont le résultat d'une démarche d'ingénierie qui part de l'analyse des exigences et aboutit à une architecture système.

Le système de systèmes (SoS) que les partenaires du projet tentent de concevoir est un système supervisé dans lequel les systèmes doivent collaborer pour satisfaire des objectifs partagés. Ceux-ci sont déterminés lors de l'analyse opérationnelle réalisée conjointement par les différents partenaires du projet. Ils sont représentés pour l'exemple par 5 capacités opérationnelles devant être implantées au travers de la collaboration des différents systèmes impliqués dans le SoS:

  • Améliorer la mobilité personnelle au sein des frontières européennes,
  • Assurer l'intégrité des personnes ou des systèmes,
  • Améliorer l'impact environnemental,
  • Assurer la continuité du service de mobilité,
  • Améliorer la gestion du trafic aérien.

La satisfaction de la première capacité opérationnelle peut être mesurée par l'amélioration du confort et de la qualité du service de transport fourni aux usagers; les métriques associées sont le temps d'attente moyen d'accès au service et la durée du transport pour se rendre au point désiré. La satisfaction de la seconde capacité concerne à la fois l'intégrité des usagers mais également celle de tout individu se trouvant sur le terrain opérationnel. L'intégrité des individus peut être corrompu de différentes manières, notamment par le biais de cyber-attaques. Sa satisfaction peut se mesurer par la diminution du nombre d'incidents, critiques ou non. Cela implique également une gestion de crise efficace en cas d'incident pour éviter que la situation n'empire. La troisième capacité opérationnelle est directement liée à l'efficience des systèmes de transports et celle de leur collaboration. Sa satisfaction peut se mesurer par la réduction de la consommation d'énergie (fossile ou autre) et celle des émissions de CO2 ou de particules fines. La satisfaction de la quatrième capacité opérationnelle nécessite de se prémunir en premier lieu d'actes malveillants pouvant cibler les avions ou les systèmes au sol, et d'anticiper d'éventuelles pannes. La satisfaction de cette capacité opérationnelle peut se mesurer par la diminution des coûts liés aux actes de malveillance ou à la panne d'un des systèmes. Enfin, la dernière capacité opérationnelle visée par notre exemple concerne la réduction des temps d'attente avant l'autorisation de décoller ou d'atterrir. C'est une capacité opérationnelle dont la satisfaction permettra de répondre en partie aux précédentes capacités opérationnelles.

Notre analyse est guidée par l'étude des scénarios d'usage. La question que nous nous posons au niveau opérationnelle est: comment est-ce que les systèmes impliqués dans le système de système collaborent pour satisfaire chacune de ces capacités opérationnelles ? Quelles données doivent-ils s'échanger et par quels moyens ? Quels comportements doivent ils adopter dans telle ou telle situation ? Il n'est peut être pas possible de répondre à toutes ces questions car il faudrait être en mesure de prévoir tous les cas de figures possibles et imaginables, difficile dans un monde ouvert. Une solution possible est d'introduire de l'apprentissage dans chacun des systèmes impliqués pour gérer les situations qui n'auront pas été anticipées dans les études amont. C'est un aspect que nous ne traitons pas dans cet article. La question qui nous importe ici est comment générer un ensemble de scénarios suffisamment représentatifs pour être sûr que le système de systèmes sera conçu est développé de manière sûre ? C'est de la qualité des scénarios que dépendront les bons choix d'architecture au niveau fonctionnel ou organique. L'approche que nous adoptons consiste à capturer dans un outil dédié (protégé) les connaissances significatifs que nous avons concernant les scénarios de mobilité: climat, état des pistes, comportement des usagers, etc. Toutes ces informations sont consignées dans une ontologie qui classifie les concepts opérationnels, et établit des relations et des contraintes entre eux. Cette dernière décrit par exemple toutes les conditions climatiques: beau temps, pluie, neige, vent violent ou brouillard. L'ontologie pouvant être exhaustive, il est nécessaire d'extraire un sous-ensemble pertinent pour les propriétés devant être démontrées, notamment celles liées à la sécurité des usagers. On peut s'appuyer pour cela sur toutes les données qu'il est possible de recueillir sur le terrain d'expérimentation: climat, accidentologie, placement des équipements, etc. De ce sous-ensemble, nous pouvons générer un feature-model de scénarios (en utilisant clafer). Associé à ce modèle, nous utilisons un outil de satisfaction de contraintes (choco-solver) pour générer l'ensemble des scénarios pouvant guider la suite du processus de conception. Aujourd'hui, et malgré les efforts pour réduire et contraindre au maximum la génération des scénarios, nous devons faire face à une explosion combinatoire importante (plusieurs millions de scénarios générés) que seuls des travaux plus théoriques pourront résoudre. Pour l'heure, nous pouvons faire le choix de classifier et de prioriser ces scénarios selon les objectifs de sûreté de fonctionnement et de cyber-sécurité.

Pour chacun des scénarios retenus, nous pouvons définir et raffiner les workflows des différentes parties prenantes du système de systèmes (BPMN + Maude pour la vérification), leurs interactions (stochastic colored petri nets - CPN Tools) et leurs modes et états (timed automata - UPPAAL). Un exemple de scénario généré est le suivant: L'avion est en approche et le ciel est couvert (cumulonimbus). Suite à l'exploitation d'une faille dans le réseau, des pirates ont pu envoyer de fausses informations météo aux pilotes, les obligeant ainsi à prendre des décisions pouvant avoir des conséquences dangereuses. L'analyse des différents scénarios va permettre d'identifier les fonctions importantes du système de systèmes, et de passer à une analyse plus fine, impliquant les concepts fonctionnels du système pour aboutir à une architecture fonctionnelle qui sera réalisée plus tard par une architecture organique.

Pour répondre aux problèmes posés par l'approche top-down, les partenaires doivent fournir dans l'espace collaboratif les informations juste nécessaires et pertinentes au moment opportun. Il s'agit là d'envoyer une information synthétique qui ne dévoilent rien de ses propriétés intellectuelles et dans la forme qui convient. Il faut de plus préciser que les données partagées sont des informations métier qui, exposées dans leur forme originale, ne pourraient être exploitées correctement par les autres parties. Il s'agit là d'un problème cognitif qui implique des problèmes de sémiotique (symboles) et sémantique (sens), et qui doivent être résolus dans le partage si on veut être sûr de prendre des décisions sur des hypothèses communes.

Il s'agit par exemple d'identifier les fonctions au niveau physique réalisées par chacun des systèmes, de manière à expliquer comment l'interaction des fonctions physiques permet de réaliser les fonctions attendues au niveau logique. Il faut également pouvoir préciser les caractéristiques extra-fonctionnelles associées à ces fonctions: performances, fiabilité, etc. Ces caractéristiques sont importantes pour pouvoir mener à bien les analyses au niveau système de systèmes et avoir ainsi des retours pertinents dans chacun des espaces partenaires, d'un point de vue prescriptif.

Lorsque les modèles prescriptifs issus de l'analyse ont été validés par l'ensemble des parties prenantes, et que les informations dimensionnantes du SoS ont été correctement caractérisées par des modèles descriptifs, l'étape suivante consiste à déterminer l'adéquation entre ce qui est attendu et ce qui est fourni (figure ci-dessous) dans une approche "meet-in-the-middle". C'est à ce moment que la création de valeur a lieu pour les partenaires du projet, car il s'agit de confronter ce qui est réalisable à ce qui est souhaitable. D'un point de vue plus fondamental, ce point de rencontre entre modèles prescriptifs et descriptifs dans cette recherche d'adéquation constitue une confrontation entre sciences formelles (top-down) et sciences expérimentales (bottom-up).


Figure 1 : Système de systèmes et démarche collaborative

Cette étape nécessite la validation de l'ensemble des décisions prises en commun par les différents partenaires. Cela passe par une exploration de l'espace d'architectures en un certain nombre d'itérations; les changements pouvant donner lieu à des remises en question en amont ou en aval. Cette mise en adéquation va permettre de mesurer la couverture des exigences du système de systèmes et d'identifier des problèmes de comportements émergents liés à la composition des systèmes, tant au niveau logique qu'au niveau organique.

La méthodologie exposée dans les sections précédentes n'est pas nouvelle. L'approche "meet-in-the-middle" est empruntée et adaptée d'une méthodologie pour la conception de systèmes embarquées (Platform Based Design). Les approches MBSE résolvent ce problème assez simplement un offrant un cadre de travail "unificateur" basé sur l'utilisation d'un formalisme unique (UML ou Capella) pour permettre aux différentes parties du processus de conception de collaborer au sein d'une même entreprise ou dans le cadre d'une entreprise étendue. C'est une solution informatique qui présente une certain avantage d'un point de vue technique, car elle permet de s'abstraire d'une certaine manière des environnements techniques employés par les différentes entreprises ou leurs services, et à peu de frais. Les principaux problèmes de cette approche sont 1) d'une part les coûts de réingénierie liés à toutes les hypothèses implicites qui ont lieu dans le partage d'information, et 2) d'autre part, le manque d'agilité dans la prise de décision dû à un problème de synchronisation entre les espaces technologiques qui empêche d'évaluer l'impact du moindre changement tant au niveau logique qu'organique, et ce pour l'ensemble des partenaires impliqués.

Le premier problème est essentiellement lié au fait que la démarche MBSE a l'inconvénient de son avantage; à savoir qu'elle peine à tenir compte des spécificités métiers, techniques ou culturels des entreprises impliquées dans une telle démarche, laissant de fait une certain nombre d'hypothèses implicites. Ces hypothèses sont pourtant cruciales dans la prise de décision globale. A ce niveau, les problèmes que nous avons identifiés sont essentiellement des problèmes d'alignement entre les partenaires, lié au fait qu'il raisonne dans des espaces de modélisation fermés et cloisonnés:

  • Alignement Ontologique Chaque partenaire amène une connaissance propre, formalisée ou non, avec de possibles recouvrements pouvant générer des contradictions ou des redites,
  • Alignement Linguistique Chaque partenaire exprime son apport par un ensemble de symboles graphiques ou textuels. Le partage de ces symboles sans leur sémantique peut amener à différentes interprétations et à des décisions mal justifiées,
  • Alignement Logique En supposant que la sémantique des symboles est bien partagée, la logique sous-jacente à l'assemblage des ces symboles n'est pas non plus nécessairement partagé, générant des inférences ou des conclusions différentes,
  • Alignement paradigmatique Enfin, en supposant que la sémantique des symboles et la logique de leur assemblage est bien partagé, l'évaluation de nouvelles hypothèses nécessitent de faire de nouveaux calculs. L'utilisation de paradigmes différents pour procéder à ces évaluation peut mener à différentes conclusions.

Le second problème tient du fait que la gestion des liens de traçabilité est aujourd'hui une activité essentiellement humaine. Encore une fois, le choix d'un cadre unificateur tel que suggéré par le MBSE peut faciliter cette tâche dans le sens où tous les artefacts d'ingénierie se trouvent représentés dans un même espace technologique. Mais cela ne reflète en rien les pratiques actuelles; en effet, les entreprises ont capitalisé à travers leurs expériences un certain nombre d'assets dans des espaces technologiques hétérogènes. Cela représente généralement une grosse quantité de données et l'effort qu'il faudrait consentir pour intégrer cette connaissance dans des espaces de modélisation unifiés ne se justifie pas franchement compte-tenu du faible retour sur investissement lié aux problèmes d'alignement que nous avons mentionné.

Les liens de traçabilité sont utilisés à la fois pour vérifier la couverture des exigences et expliquer les décisions qui sont prises globalement. Ainsi, une exigence peut être associée à un composant qui l’implante ou un test qui la vérifie. Si l’on considère que les liens de traçabilité ne relie que des artefacts en boîte noire avec une sémantique pragmatique (laissée dans la tête des experts qui les ont exprimés), l’utilité des liens de traçabilité sera limitée aux opérations liées au cycle de vie des artefacts (création, suppression, mise à jour, consultation) et servira difficilement à calculer son impact en termes de rework si nécessaire. Si en revanche on arrive à expliciter la sémantique des éléments mis en relation dans la traçabilité, en boîte grise ou en boîte blanche, on sera capable de mesurer plus finement l’impact d'un changement. Il s’agit en définitive de capturer des liens de traçabilité avec une sémantique plus fine tout en désillotant les espaces technologiques, hétérogènes par nature.

Si l’on s’en tient aux liens de traçabilité capturés par les experts durant les activités d’ingénierie, on risque fort de passer à côté de beaucoup de liens non exprimés. Même en supposant que ces experts ont une forte propension à collaborer efficacement entre eux, il reste beaucoup de facteurs qui vont limiter la capture des liens de traçabilité. Le premier facteur est technologique: comme nous l’avons mentionné, les silos technologiques ne facilitent pas la capture de liens de traçabilité entre artefacts d’ingénierie. Le second facteur est organisationnel: suivant la taille et la structure des projets de développement, l’échange d’information et la mise en relation entre artefacts d’ingénierie sera plus ou moins facilitée. Enfin, le troisième facteur est humain: les experts en tant qu’êtres humains sont faillibles; ils peuvent être débordés, oublier ou mal exécuter leur travail. Il est donc nécessaire de fournir à ces experts un cadre leur permettant de mieux gérer et comprendre l’impact de leurs activités sur les autres, au delà des silos technologiques, des organisations ou de leur condition. Un tel cadre permettra d’expliciter des liens qui ne sont pas exprimés, et ce au plus tôt dans le processus de conception du système.

La maintenance de ces liens est une tâche essentielle est nécessite la mise en œuvre de différents types d’activité de mise en cohérence et de résolution de conflits, en fonction de la nature du lien. Pour certains types de liens, la maintenance pourra être résolue de manière automatique; dans d’autres cas, plus sujets à recherche de compromis, il s’agira de faire intervenir les experts concernés. Étant donnée la volumétrie des artefacts et la fréquence de leurs modifications, les solutions proposées en réponse aux problématiques précédemment soulevées devront être dans la mesure du possible automatisées.