Arcadia (ingénierie)

ARCADIA (ARCHITECTURE ANALYSIS & DESIGN INTEGRATED APPROACH) est une méthode d’ingénierie et de définition des architectures systèmes, logicielles, et matérielles, basée sur les modèles.

Méthode d’ingénierie et de définition des architectures systèmes, logicielles et matérielles.

Historique

Historiquement, dans le cycle de développement d'un système, l'accent était mis sur la définition des exigences, leur allocation à chaque composant du système et la traçabilité associée plutôt que sur l'analyse fonctionnelle, la conception du système, la justification des choix architecturaux et des étapes de vérification. De plus, cette conception doit prendre en compte non seulement le point de vue fonctionnel, mais aussi d'autres points de vue, qui influent largement sur le découpage et la définition du système (contraintes d'intégration ou liées à la gestion en ligne de produits, aux contraintes de sécurité, de performance, de faisabilité, etc.). L'ingénierie des systèmes ne se résume donc pas à la gestion des exigences du système, mais passe avant tout par une activité de conception avancée de celui-ci.

La méthode ARCADIA a été définie par Thales en 2007 en réponse à cette problématique en plaçant l'architecture et la collaboration au centre de l'ingénierie des systèmes.

Cette vision permet notamment de briser les silos entre les différentes ingénieries de spécialité (Architectes, Équipes de développement, Spécialistes, Équipes IVVQ, Client, Partenaires externes, etc.) et ainsi favoriser la collaboration entre ces dernières.

Depuis Septembre 2015, la méthode est en cours de standardisation auprès de l'AFNOR au travers du projet collaboratif français Clarity soutenu par BPI France.

Contexte d'application

La méthode ARCADIA s'applique à la conception des systèmes complexes et des systèmes critiques, et plus généralement d’architectures soumises à des contraintes fonctionnelles et non fonctionnelles multiples (y compris architectures logicielles, électroniques, électriques, processus industriels, etc.). Elle définit un ensemble de pratiques guidant l’analyse du besoin et la conception en vue de répondre à un besoin opérationnel et est conçue pour être adaptable aux processus et contraintes liées à de multiples cycles de vie : approche ascendante, réutilisation d'applicatifs, incrémentale, itérative, partielle, etc.

Objectifs et moyens d'action

ARCADIA est une méthode structurée d'ingénierie destinée à définir et à valider l’architecture de systèmes complexes. Elle favorise le travail collaboratif de tous les intervenants, souvent nombreux, de la phase d’ingénierie (ou de définition) du système. Elle permet d’effectuer dès la phase de définition les itérations qui vont permettre de faire converger l’architecture vers l’adéquation à l’ensemble des besoins identifiés.

Si les exigences textuelles sont toujours présentes et utilisées comme contribution principale à l’expression du besoin en entrée de l’ingénierie, ARCADIA se place comme support majeur de l'ingénierie et de sa maîtrise, reposant sur une formalisation de l’analyse du besoin de nature opérationnelle, fonctionnelle et non fonctionnelle (fonctions attendues du système, chaînes fonctionnelles...), puis de la définition/justification de l'architecture à partir de cette analyse fonctionnelle.

Les principes généraux d’ARCADIA sont les suivants:

• Tous les intervenants de l’ingénierie partagent la même méthode, les mêmes informations, la même description du besoin et du produit sous forme d’un modèle partagé ;
• Chaque ensemble de contraintes (par exemple : sécurité, performances, coût, masse,…) est formalisé dans un « point de vue » par rapport aux exigences duquel l’architecture proposée sera vérifiée ;
• Les règles de vérification anticipée de l’architecture sont établies de manière à pouvoir vérifier au plus tôt l’architecture proposée ;
• La co-ingénierie entre les différents niveaux d’ingénierie est soutenue par l’élaboration conjointe de modèles, et les modèles des différents niveaux et métiers sont déduits/validés/reliés les uns par rapport aux autres.

La méthode ARCADIA est outillée au travers de l’outil de modélisation Capella qui répond aux contraintes de déploiement en vraie grandeur dans un contexte opérationnel. Capella est mis gratuitement à disposition de la communauté ingénierie sous le mode Open Source.

Particularités de la méthode

• Elle couvre l’ensemble des activités structurantes de l’ingénierie, depuis la capture du besoin client opérationnel, jusqu’à l’intégration vérification validation (IVV) ;
• Elle prend en compte les niveaux d’ingénierie multiples et leur collaboration efficace (système, sous-système, logiciel, matériel, etc.) ;
• Elle intègre la co-ingénierie avec les ingénieries de spécialités (sécurité, sûreté, performances, interfaces, logistique…) et d’IVV ;
• Elle est basée sur l’utilisation de modèles, non seulement descriptifs, mais aussi susceptibles de valider la définition et les propriétés de l’architecture, et constituant le support majeur à la co-ingénierie des équipes concernées ;
• Elle a passé avec succès le test de l’applicabilité sur des projets en taille réelle et situation opérationnelle contrainte, puisque actuellement en déploiement sur plusieurs dizaines de grands projets dans plusieurs divisions et pays de Thales.

Approche méthodologique

Points de vue

Collaboration

L’une des difficultés fréquemment rencontrée dans le développement de systèmes complexes vient de la mise en œuvre simultanée (superposition) de plusieurs chaînes fonctionnelles partiellement indépendantes utilisant des ressources partagées (notamment mais pas seulement, des ressources de calcul). La méthode ARCADIA et les outils sous-jacents permettent d’identifier les chaînes fonctionnelles, leurs scénarios de superposition, et les performances recherchées, dès le premier niveau d’analyse du système ; ils en assurent la traçabilité tout au long du processus de définition, et vérifient, pour chaque conception proposée, que l’architecture de traitement de ces chaînes fonctionnelles est capable des objectifs de performances, y compris en situation de partage de ressources, et d’itérer si la vérification n’est pas satisfaisante.

Les propriétés non fonctionnelles attendues sont par ailleurs formalisées dans des 'points de vues' traduisant les contraintes associées, et analysant l'architecture solution selon ces contraintes et des règles de savoir-faire métier. Cette analyse peut se faire très tôt dans le cycle de développement, détectant les problèmes de conception au plus tôt ("early validation").

Plus généralement l’approche de caractérisation par points de vue (ou "viewpoints") transverses permet de vérifier que l’architecture proposée est capable d’assurer les fonctions requises avec le niveau de performance recherché, mais aussi qu’elle peut répondre aux autres exigences dites non-fonctionnelles (sécurité, sûreté de fonctionnement, masse, évolutivité, environnements, masse, interfaces, etc.), mais tout aussi impératives.

Enfin, pour garantir la cohérence des décisions d'ingénierie, tous les intervenants de l'ingénierie partagent les mêmes informations, la même description du besoin et du produit, sous la forme d'un ensemble de modèles partagés.

Présentation de la démarche et principaux concepts

Phase d'ingénierie	Concept	Définition
Analyse Opérationnelle	"ce que les utilisateurs du système doivent accomplir"	Analyse de la problématique des utilisateurs opérationnels en identifiant les acteurs devant interagir avec le système, leurs activités, et les échanges entre eux.
Analyse du Besoin Système	"ce que le système doit réaliser pour les utilisateurs"	Analyse Fonctionnelle externe pour identifier en réponse les fonctions du système nécessaires à ses utilisateurs (ex : "calculer l'itinéraire optimal", "détecter et localiser la menace"), sous contrainte des propriétés non fonctionnelles demandées.
Architecture Logique	"comment le système va fonctionner pour répondre aux attentes"	Analyse Fonctionnelle interne du système : quelles sont les sous-fonctions à réaliser et assembler pour réaliser les fonctions "utilisateur" identifiées lors de la phase précédente, identification des composants logiques réalisant ces sous-fonctions internes, en y intégrant les contraintes non fonctionnelles qu’on a choisi de traiter à ce niveau.
Architecture Physique	"comment le système va être construit"	Cette phase a le même objectif que l’architecture logique excepté qu’elle définit l’architecture finale du système, telle qu'elle doit être réalisée. Elle ajoute les fonctions requises par l’implémentation et les choix techniques, fait apparaître des composants comportementaux (ex : composants logiciel) qui réalisent ces fonctions. Ces composants comportementaux sont ensuite implémentés à l’aide de composants d’implémentation (ex : carte processeurs) qui offrent la ressource matérielle nécessaire.
"End-Product Breakdown Structure" (EPBS) et Contrats d'Intégration	"ce qui est attendu du fournisseur de chaque composant"	Cette phase déduit de l’architecture physique les conditions que devra remplir chaque composant pour satisfaire aux contraintes et choix de conception de l’architecture, réalisés dans les phases précédentes.

L’ensemble des éléments constitutifs de l’ingénierie et élaborés lors de l’application de la méthode sont formalisés, partagés et exploités par le biais de modèles à chaque niveau d’ingénierie ; pour chacun d’entre eux, les figures ci-dessous synthétisent son contenu en accord avec les phases décrites précédemment :

Phases d'ingénierie ARCADIA

Décomposition en phase d'ingénierie

ARCADIA vis-à-vis des Standards: xAF, SysML, AADL

Les concepts ARCADIA sont compatibles avec les langages d'architecture tels que DODAF / NAF Architecture Frameworks, UML2 et SysML, AADL etc.

Communication

Au travers du projet Clarity, un ouvrage dédié à la méthode est en cours de rédaction. Un document d'introduction est disponible en téléchargement sur le site web de Capella.

La méthode ARCADIA a été présentée lors de divers événements :

Conférence	Titre de la présentation	Date	Lieu
INCOSE International Symposium	Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned	14/07/2015	Seattle
INCOSE International Symposium	From initial investigations up to large-scale rollout of an MBSE method and its supporting workbench: the Thales experience	14/07/2015	Seattle
EclipseCon France	Systems Modeling with the ARCADIA method and the Capella tool	24/06/2015	Toulouse
Model-Based System Engineering (MBSE) Symposium	The Challenges of Deploying MBSE Solutions	28/10/2014	Canberra
Model-Based System Engineering (MBSE) Symposium	Arcadia and Capella on the Field: Real-World MBSE Use Cases	27/10/2014	Canberra
EclipseCon France	Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering	19/06/2014	Toulouse
MDD4DRES ENSTA Summer school	Feedbacks on System Engineering – ARCADIA, a model-based method for Architecture-centric Engineering	01/09/2014	Aber-Wrac'h
EclipseCon North America	Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering	20/03/2014	San Francisco
Complex Systems Design & Management (CSDM)	ARCADIA: Model-Based Collaboration for System, Software and Hardware Engineering	04/12/2013	Paris
Congrès Ingénierie grands programmes et systèmes complexes	La modélisation chez Thales : un support majeur à la collaboration des acteurs dans l’ingénierie des grands systèmes	10/06/2013	Arcachon
MAST	Toward integrated multi-level engineering - Thales and DCNS advanced Practices	04/06/2013	Gdańsk
CSDM	Modelling languages for Functional Analysis put to the test of real life	2012	Paris
ICAS	Method and tools to secure and support collaborative architecting of constrained systems	2010	Nice
CSDM	Model-driven Architecture building for constrained Systems	2010	Paris
INCOSE’08 Symposium	Method & Tools for constrained System Architecting	2008	Utrecht

Liens externes

• (en) Page web dédiée à la méthode
• (en) Forum officiel
• Thales, créateur de la méthode