Table of Contents

Comprendre le DODAF : la Fondation pour les diagrammes OV et SV

Le Cadre d'architecture du Département de la défense (DODAF) fournit une méthodologie structurée pour la conception, l'évaluation et la communication de systèmes complexes dans les secteurs de la défense et de l'aérospatiale. Établie pour s'assurer que les descriptions d'architecture sont cohérentes, réutilisables et alignées avec les besoins des intervenants, DODAF est organisée en six points de vue : All Viewpoint (AV), Capability Viewpoint (CV), Operational Viewpoint (OV), Project Viewpoint (PV), Systems Viewpoint (SV) et Standards Viewpoint (StdV).

La vue opérationnelle (OV) décrit les concepts opérationnels, les activités, les tâches et les flux d'information nécessaires pour accomplir les missions. Elle se concentre sur ce qui doit être fait, par qui et avec quelles informations. La vue système (SV) documente à son tour les systèmes physiques et logiques, leurs interfaces et les échanges qui soutiennent les activités opérationnelles. La vision critique pour les architectes est que la SV doit remonter directement à la VO; chaque fonction système devrait exister pour satisfaire au moins une activité opérationnelle.

L'élaboration de diagrammes OV et SV permet aux intervenants de comprendre correctement les dépendances, de cerner les lacunes en matière de capacités, d'évaluer les solutions de rechange et d'éclairer les décisions d'acquisition.

La vue opérationnelle (OV) en profondeur

Le DODAF définit sept produits OV standard, chacun servant un but distinct. Bien que chaque projet n'exige pas tous les produits, une architecture mature comprend généralement au moins OV‐1, OV‐2, OV‐5 et OV‐6.

OV‐1: Concept opérationnel de haut niveau Graphique

Le OV‐1 est une représentation picturale du concept opérationnel. Il montre les principaux nœuds opérationnels (p. ex., quartier général, plateformes de capteurs, centres de commandement), leur arrangement géographique ou logique et les échanges d'information de haut niveau.Les principaux intervenants – décideurs supérieurs et commanditaires non techniques – utilisent OV‐1 pour saisir rapidement la portée de la mission et les rôles des entités participantes.

OV-2: Description du flux de ressources opérationnelles

OV‐2 ajoute des flux d'information détaillés entre les nœuds opérationnels. Il identifie les ressources spécifiques (information, matériel, personnel) qui traversent les interfaces. Pour chaque flux, l'architecte documente les nœuds producteur et consommateur, la fréquence et la nature de la ressource (p. ex. données de capteur, commandes logistiques, rapports de situation). Ce produit devient la base des diagrammes SV‐1 et SV‐2, assurant que les interfaces système mettent en œuvre exactement les échanges opérationnels requis.

OV‐3: Matrice de flux de ressources opérationnelles

OV‐3 est une représentation tabulaire des informations contenues dans OV‐2. Elle énumère chaque flux de ressources ligne par ligne, en précisant la source, la destination, le format des données, les attributs de qualité et la classification de sécurité.

OV‐4: Tableau des relations organisationnelles

OV‐4 représente la structure de commandement, les relations et les lignes d'autorité entre les nœuds opérationnels. Il répond : qui est responsable, qui relève de qui, et quels mécanismes de coordination existent ? Le graphique peut être hiérarchique (décomposition organisationnelle) ou plus dynamique (relations de liaison, équipes organisées par tâches).

OV‐5a et OV‐5b: Modèles d'activités opérationnelles

OV‐5a (Operational Activity Decomposition Tree) décompose la mission de haut niveau en activités de niveau inférieur. OV‐5b (Operational Activity Model) montre la séquence, les entrées/sorties et les interprètes de chaque activité. Ensemble, ils décrivent le comportement fonctionnel de l'opération.

OV‐6a, OV‐6b, OV‐6c: Règles opérationnelles, transitions d'État et modèles de course d'événements

OV‐6a documente les règles d'exploitation et les contraintes opérationnelles (p. ex., - -Si l'aéronef approche à moins de 10 milles marins, lancez un avertissement - OV‐6b (Description de la transition d'État) modélise les états possibles des nœuds opérationnels et permet des transitions. OV‐6c (Description de l'événement-trace) utilise des diagrammes de séquence pour montrer les échanges ordonnés par ordre de temps entre les nœuds.

La vue des systèmes (SV) en profondeur

Le système de visionnement comprend au moins dix produits, de SV‐1 à SV‐10c. Le système de visionnement doit démontrer comment les systèmes réalisent les activités opérationnelles et les flux de ressources définis dans le VO.

SV‐1: Description de l'interface système

Le SV‐1 est l'épine dorsale structurelle de l'architecture du système. Il représente les systèmes (matériel, logiciels, bases de données) comme des nœuds et montre les interfaces logiques et physiques entre eux. Chaque interface est marquée avec les ressources qui l'y traversent, ce qui devrait correspondre aux flux de ressources documentés dans OV‐2.

SV‐2: Description du flux de ressources des systèmes

SV‐2 ajoute des détails supplémentaires à chaque interface présentée dans SV‐1. Il spécifie les piles de protocole, les types de liaison de données, la bande passante et les attributs de qualité de service. Par exemple, une interface entre un système de contrôle au sol et un UAV peut être décrite comme -Link 16, 1 Mbps, cryptée, avec une latence maximale de 200 ms. Ce produit se nourrit directement dans les études de l'ingénierie des systèmes et les évaluations d'interopérabilité.

SV‐3: Matrice des systèmes

SV‐3 est une matrice qui montre quelles paires de systèmes ont des interfaces, et en option la nature de ces interfaces (p. ex., bidirectionnel, unidirectionnel, radiofréquence, filaire). La matrice aide les architectes à identifier rapidement les lacunes d'interface ou les couplages excessifs.

SV‐4: Description de la fonctionnalité des systèmes

Contrairement à OV-5 qui se concentre sur les activités opérationnelles, SV-4 se concentre sur ce que fait le système : par exemple, -comprimer la solution de lutte contre l'incendie, -comprimer le capteur de manioeuvre, -maintain link. Les fonctions de SV-4 doivent pouvoir être traçables aux activités de OV-5 via SV-5.

SV‐5: Activité opérationnelle aux systèmes Fonction de la matrice de traçabilité

Le SV‐5 est l'un des produits les plus essentiels pour assurer la cohérence. Il permet de cartographier chaque activité opérationnelle dans OV‐5a à une ou plusieurs fonctions système dans le SV‐4. Un SV‐5 complet garantit que chaque besoin opérationnel est satisfait par certaines capacités système.

SV‐6: Matrice de flux de ressources des systèmes

SV‐6 est la contrepartie des OV‐3 orientée vers les systèmes. Elle énumère tous les flux de ressources entre les systèmes, en les reliant aux interfaces définies dans SV‐1. Maintenir la cohérence : chaque flux en OV‐3 automatisé devrait avoir un flux correspondant dans SV‐6.

SV‐7: matrice des mesures des systèmes

SV‐7 documente les paramètres de performance tels que le débit, la fiabilité, la latence, la vitesse de traitement et la capacité.Ces mesures sont liées aux fonctions du système et permettent des compromis quantitatifs. Par exemple, une fonction radar peut avoir une plage de détection de -500 km à 90 % de probabilité.

SV‐10a, SV‐10b, SV‐10c: Règles de systèmes, transitions d'état et modèles de trac événementiel

Ces produits sont en miroir OV‐6 mais au niveau du système. SV‐10a définit les règles ou contraintes d'exploitation au niveau du système. SV‐10b modélise les machines d'état pour chaque système ou fonction. SV‐10c utilise des diagrammes de séquence pour illustrer les échanges de messages dans le temps entre les interfaces du système.

Une méthodologie étape par étape pour l'élaboration de diagrammes OV et SV

La méthode suivante combine la décomposition descendante avec le raffinement des intervenants. Elle est conçue pour produire des diagrammes cohérents et validés qui appuient l'analyse et la communication.

Étape 1: Définir le but et la portée

Avant de dessiner un diagramme, répondez à trois questions : Quelle est la mission ou le problème que l'architecture aborde? Quelle est l'utilisation prévue de l'architecture (p. ex., support d'acquisition, analyse des lacunes, évaluation de l'interopérabilité)? Quelles sont les limites – organisationnelles, géographiques, temporelles? Définissez-les dans la description de l'architecture (AV‐1).

Étape 2 : Identifier les intervenants et leurs préoccupations

Les intervenants comprennent les commandants opérationnels, les ingénieurs de systèmes, les gestionnaires de programmes et les responsables des acquisitions. Chacun d'eux a des préoccupations particulières : les commandants doivent voir leur souplesse opérationnelle; les ingénieurs doivent définir des interfaces détaillées; les gestionnaires veulent des répercussions sur les risques et les coûts.

Étape 3: Construire le concept opérationnel de haut niveau (OV‐1)

Créez le graphique OV‐1 à l'aide d'un simple outil de dessin ou d'un environnement basé sur le modèle. Placez les nœuds opérationnels primaires (p. ex., Force opérationnelle interarmées, Navire de surface, Véhicule aérien sans pilote, Satellite) et montrez les échanges d'information de haut niveau. Ajoutez une description textuelle qui saisit le scénario opérationnel.

Étape 4: Modéliser les activités opérationnelles et les flux de ressources (OV‐2, OV‐5a/b)

Utiliser le OV‐1 comme squelette, décomposer chaque nœud opérationnel dans ses activités en utilisant une décomposition fonctionnelle (OV‐5a). Pour chaque activité, déterminer les entrées et sorties. Ensuite ajouter les flux de ressources entre les nœuds dans OV‐2. Par exemple, si l'activité -Formuler la réponse - dans un noeud produit un --Réponse Plan, ce plan doit s'écouler vers un autre noeud. Documenter chaque flux caractéristiques (fréquence, volume de données, sécurité). Valider ces flux avec des experts en la matière.

Étape 5 : Définir les relations organisationnelles (OV‐4)

Ajoutez l'autorité et les lignes de rapport entre les nœuds. Cela peut être simple (hiérarchie) ou complexe (partenaires de coalition avec commande partagée). OV‐4 aide à identifier les nœuds autorisés à demander ou à recevoir les ressources — informations souvent critiques pour les règles de contrôle d'accès dans SV‐10a.

Étape 6 : Établir des modèles comportementaux (OV‐6)

Pour les threads opérationnels critiques, créez des diagrammes d'état (OV-6b) et des diagrammes de séquence (OV-6c). Par exemple, un état --pas prêt à passer à --déjà prêt à partir d'un message d'autorisation. Le diagramme de séquence peut afficher les messages exacts entre les nœuds au fil du temps, y compris les conditions et exceptions.

Étape 7: Élaborer des descriptions de l'interface de systèmes (SV‐1)

Maintenant, passez au domaine système. Identifier les systèmes qui implémentent les nœuds opérationnels. Pour chaque nœud opérationnel, listez les systèmes ou les composants système (p. ex., suite logicielle C2, radio, serveur). Dessinez les systèmes comme des nœuds dans SV‐1 et connectez-les avec des interfaces qui correspondent aux flux de ressources opérationnelles dans OV‐2. Étiquetez chaque interface avec ses systèmes d'implémentation et les ressources qu'elle transporte. À cette étape, vous pouvez découvrir qu'un flux opérationnel unique doit être réparti entre plusieurs interfaces système (p. ex., voix et données envoyées sur des liens séparés).

Étape 8: Functionnalité et traçabilité des systèmes détaillés (SV‐4, SV‐5)

Par exemple, le système --Ground Control Station peut inclure des fonctions telles que --Télémétrie réceptionnelle, --Mise à jour de la base de données de suivi et --Transmettre des commandes SV‐5. Ensuite, créez la matrice SV‐5 en reliant chaque fonction SV‐4 à une ou plusieurs activités OV‐5. Cette étape est celle où les lacunes en matière de traçabilité deviennent évidentes. Si une activité opérationnelle requise n'a pas de fonction système de soutien, vous devez soit ajouter une fonction, soit faire valoir que l'activité est manuelle.

Étape 9 : Flux et dynamique des systèmes modèles de ressources (SV‐2, SV‐10)

Affiner chaque interface en SV‐1 avec des attributs techniques détaillés en SV‐2 (protocole, sécurité, performance). Ensuite, développer des modèles d'état et de séquence au niveau du système (SV‐10b/c) qui reflètent les comportements opérationnels d'OV‐6. Par exemple, le même diagramme de séquence d'OV‐6c devrait maintenant être étendu au niveau du système, en montrant les noms de messages, les formats de données et les exigences de chronométrage.

Étape 10 : Valider, affiner et gérer la configuration

Organiser des séances d'examen avec les intervenants originaux et d'autres experts en la matière.Promenez-vous dans les produits OV et SV afin de commencer par OV‐1, et confirmez que chaque élément OV est abordé dans le SV, et que la solution SV est réalisable et conforme aux normes (StdV). Utilisez cette rétroaction pour mettre à jour les diagrammes, puis basez l'architecture. Une fois la référence établie, mettez en œuvre le contrôle de version à l'aide d'un système de configuration basé sur le modèle.

Meilleures pratiques et pièges communs

Meilleures pratiques

  • Utilisez un outil basé sur des modèles. Des outils comme Cameo Systems Modeler, MagicDraw ou Sparx Enterprise Architect avec des profils UPDM/UAF font en sorte que la production de rapports automatisés (y compris les matrices) et facilitent la traçabilité des produits OV et SV.
  • Maintenir une notation standard. Le profil unifié pour le DoDAF/MODAF (UPDM) ou le Cadre d'architecture unifié (CAU) fournit des stéréotypes et des types de diagrammes standard, ce qui améliore la communication entre les équipes et réduit les erreurs d'interprétation.
  • Démarrer avec le besoin opérationnel Même les ingénieurs expérimentés du système devraient résister à sauter directement sur les diagrammes SV sans une fondation OV solide. OV‐5 et OV‐2 sont les points de départ les plus précieux.
  • Gardez les diagrammes utiles et non complets. Il est préférable d'avoir un ensemble bien organisé de cinq produits OV qui sont examinés et précis que de générer les 30 produits standard avec une qualité minimale.
  • Hypothèses et décisions de documents Chaque diagramme devrait être accompagné d'un récit expliquant pourquoi un certain flux existe, pourquoi une fonction est attribuée à un système particulier et quelles hypothèses ont été faites au sujet de l'environnement opérationnel.

Pièges fréquents

  • Ignorer la cohérence de vision croisée. Le problème le plus fréquent dans les architectures DODAF est les fonctions ou les flux orphelins. Une fonction système en SV‐4 qui n'a aucune activité opérationnelle mère en OV‐5 est un gaspillage, tandis qu'une activité opérationnelle sans fonction tracée indique une conception du système incomplète.
  • Surcomplication des OV‐1 Certaines équipes essaient de mettre trop de détails dans le graphique de concept de haut niveau, ce qui le rend illisible. Gardez OV‐1 à une page; utilisez OV‐2 et OV‐5 pour les détails.
  • Mesures de rendement neglectives (SV‐7). De nombreux projets définissent des interfaces et des fonctions mais ne fixent jamais de mesures. Sans SV‐7, il est impossible d'évaluer si le système répondra aux exigences opérationnelles.
  • Les diagrammes de création en isolation. Si l'équipe OV et l'équipe SV ne se synchronisent pas régulièrement, le SV dérivera de la réalité opérationnelle.
  • Utiliser le mauvais niveau de granularité. Une décomposition trop grossière manque des détails clés; une décomposition trop fine rend l'architecture difficile. Une bonne règle du pouce: chaque activité ou fonction devrait représenter un comportement unique et cohérent qui peut être assigné à un seul noeud ou système exécutant.

Outils et techniques pour le développement de diagrammes DODAF

Bien qu'il soit possible de créer des diagrammes DODAF avec des outils de dessin génériques (p. ex. Microsoft Visio), la complexité de la traçabilité et des renvois croisés rend fortement recommandés les outils fondés sur des modèles.

  • Dassault Systèmes Cameo Systems Modeler (anciennement MagicDraw) – largement utilisé dans les programmes de défense, prend en charge l'UPDM/UAF, fournit la génération de matrice automatisée (SV‐3, SV‐5, OV‐3) et peut générer des rapports d'architecture basés sur le Web.
  • Sparx Systems Enterprise Architect – offre un complément UAF mature, supporte la modélisation basée sur le profil, et a un point de coût plus bas adapté aux équipes plus petites.
  • IBM Engineering Rhapsody – forte en ingénierie de systèmes avec le support SysML et peut être configurée pour les points de vue DODAF.

Lors du choix d'un outil, évaluez sa capacité à faire respecter la traçabilité, générer des matrices SV‐5, gérer le contrôle de version et exporter vers des formats standard (p. ex. HTML, XMI, PDF). Indépendamment de l'outil, la technique clé consiste à définir le méta-modèle tôt : quels sont les types de nœuds, flux et fonctions que vous utiliserez; quelles relations (attribution, trace, interface) sont permises; quels attributs seront capturés.

Pour les équipes qui viennent d'entrer au DODAF, envisagez de commencer par un projet pilote utilisant uniquement OV‐1, OV‐2, OV‐5, SV‐1 et SV‐5. Maîtrisez ces projets avant d'ajouter des modèles comportementaux et dynamiques.

Conclusion

En suivant une méthodologie structurée – de la définition de la portée et de la construction de modèles opérationnels, en passant par les fonctions de traçage et la validation auprès des intervenants – les architectures produisent des diagrammes précis, complets et exploitables. L'effort investi pour créer des produits OV et SV de haute qualité rapporte des dividendes lors de l'acquisition, de l'intégration et de la gestion du cycle de vie du système. Les décideurs acquièrent une compréhension claire de la façon dont les systèmes soutiennent la mission, et les ingénieurs ont une spécification précise pour guider le développement.

Pour plus de détails, voir le site officiel du Cadre d'architecture DoD, la spécification du Cadre d'architecture unifié et les SEI=s orientations sur le développement de l'architecture DODAF.