 | This article has multiple issues. Please help improve it or discuss these issues on the talk page . (Learn how and when to remove these template messages)
|
ARCADIA (Architecture Analysis & Design Integrated Approach) is a system and software architecture engineering method based on architecture-centric and model-driven engineering activities.
In the development cycle of a system, former practices focused more on the definition of requirements, their allocation to each component of the system component and associated traceability. Current approaches rather focus on functional analysis, system design, justification of architectural choices, and verification steps. In addition, the design takes into account not only the functional point of view, but also other points of view, which affect the definition and breakdown of the system. For example, constraints relating to system integration, product line management, safety, performance and feasibility. Systems engineering is therefore not just about managing the system requirements, but is a complex design activity.
As an answer to this challenge, the ARCADIA method was created by Thales in 2007, placing architecture and collaboration at the center of systems engineering practices.
The vision for ARCADIA was to break the "walls" between different engineering specializations including architects, development teams, Specialists, IVVQ (Integration, Verification, Validation, and Qualification) Teams, Customer and external partners.
The ARCADIA method is about to be standardized as an AFNOR experimental norm. [1] It has been published on March 7, 2018.
The ARCADIA method applies to the design of complex and critical systems, and more generally architectures that are subject to multiple functional and non-functional constraints, including software, electronic, electrical architectures, and industrial processes. It defines a set of practices that guides needs analysis and design to meet an operational requirement. At the same time it is adaptable to the processes and constraints linked to various types of life cycles such as bottom-up approach, application reuse, incremental, iterative and partial development.
ARCADIA is a structured engineering method to identify and check the architecture of complex systems. It promotes collaborative work among all stakeholders during many of the engineering phases of the system. It allows iterations during the definition phase that help the architects to converge towards satisfaction of all identified needs.
Even if textual requirements are kept as a support for part of customer need capture, ARCADIA favors functional analysis as the major way to formalize the need and solution behavior. This includes operational, functional and non-functional aspects, along with resulting definition of the architecture, based on – and justified against – this functional analysis.
ARCADIA is based on the following general principles:
The ARCADIA method is tooled through Capella, a modeling tool that meets full-scale deployment constraints in an operational context. Capella is available free of charge from the engineering community under open source.
The ARCADIA method:
One of the difficulties frequently encountered in the development of complex systems comes from the superposition of several partially independent functional chains using shared resources (including but not limited to computing resources). The ARCADIA method and the underlying tools are used to identify functional chains, their overlapping scenarios and desired performance, along with their support by the architecture. Starting with the first level of system analysis, they ensure traceability throughout the process definition and check each proposed architectural design against expected performance and constraints.
The non-functional properties expected from the system solution are also formalized in 'viewpoints'. Each viewpoint captures constraints that the system should face or meet (feared events, security threats, latency expectations, product line or reuse constraints, power consumption or cost issues, and more). Then the architecture model is automatically analyzed to verify that it meets these constraints, thanks to dedicated expert rules (performance computation, resource consumption, safety or security barriers, etc.). This analysis can be done very early in the development cycle, detecting design issues as soon as possible ("early validation").
As a summary, the approach to characterization by views (or "viewpoints") cross-checks that the proposed architecture is capable of providing the required functions with the desired level of performance, security, dependability, mass, scalability, environments, mass, interfaces, etc. ensuring the consistency of engineering decisions, because all engineering stakeholders share the same engineering information, and can apply his/her own views and checks to them, so as to secure the common definition.
The first level views used to elaborate and share the architecture model are described below:
The first step focuses on analysing the customer needs and goals, expected missions and activities, far beyond System/SW requirements. This is expected to ensure good adequacy of System/SW definition with regards to its real operational use – and define IVVQ conditions. Outputs of this step consist mainly in an "operational architecture" describing and structuring this need, in terms of actors/users, their operational capabilities and activities, operational use scenarios giving dimensioning parameters, operational constraints including safety, security, lifecycle, etc.
The second step focuses now on the system/SW itself, in order to define how it can satisfy the former operational need, along with its expected behaviour and qualities: system/SW functions to be supported and related exchanges, non functional constraints (safety, security...), performances allocated to system boundary, role sharing and interactions between system and operators. It also checks for feasibility (including cost, schedule and technology readiness) of customer requirements, and if necessary gives means to renegotiate their contents. To do this, a first early system/SW architecture (architectural design model) is sketched, from system/SW functional need; then requirements are examined against this architecture in order to evaluate their cost and consistency. Outputs of this step mainly consist of system/SW functional Need description, interoperability and interaction with the users and external systems (functions, exchanges plus non-functional constraints), and system/SW requirements.
Note that these two steps, which constitute the first part of Architecture building, "specify" the further design, and therefore should be approved/validated with the customer.
The third step intends to identify the system/SW parts (hereafter called components), their contents, relationships and properties, excluding implementation or technical/technological issues. This constitutes the system/SW logical architecture. In order for this breakdown in components to be stable in further steps, all major [non-functional] constraints (safety, security, performance, IVV, Cost, non technical, etc.) are taken into account and compared to each other's so as to find the best compromise between them. This method is described as "Viewpoints-driven", viewpoints being the formalization of the way these constraints impact the system/SW architecture. Outputs of this step consist of the selected logical architecture: components and interfaces definition, including formalization of all viewpoints and the way they are taken into account in the components design. Since the architecture has to be validated against Need, links with requirements and operational scenarios are also produced.
The fourth step has the same intents as logical architecture building, except that it defines the "final" architecture of the system/SW at this level of engineering, ready to develop (by lower engineering levels). Therefore, it introduces rationalization, architectural patterns, new technical services and components, and makes the logical architecture evolve according to implementation, technical and technological constraints and choices (at this level of engineering). Note that the same "Viewpoints-driven" method as for logical architecture building is used for physical architecture definition. Outputs of this step consist of the selected physical architecture: components to be produced, including formalization of all viewpoints and the way they are taken into account in the components design. Links with requirements and operational scenarios are also produced.
The fifth and last step is a contribution to EPBS (End-Product Breakdown Structure) building, taking benefits from the former architectural work, to enforce components requirements definition, and prepare a secured IVVQ. All choices associated to the system/SW chosen architecture, and all hypothesis and constraints imposed to components and architecture to fit need and constraints, are summarized and checked here. Outputs from this step are mainly "component Integration contract" collected all necessary expected properties for each component to be developed.
The following figure shows a global view summarizing the recommended technical process, featuring the three elements of the engineering triptych, and their production activities all along the definition and design process.
 |  |
As part of the Clarity Project, a book on the ARCADIA method will be published. An introductory document is currently available for download on the Capella website. [2]
The ARCADIA method was presented at various events:
| Conference | Title | Date | Place |
|---|---|---|---|
| MODELS'16 | ARCADIA in a nutshell [3] | 02/10/2016 | Saint Malo |
| INCOSE International Symposium | Implementing the MBSE Cultural Change: Organization, Coaching and Lessons Learned [4] | 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 [5] | 14/07/2015 | Seattle |
| EclipseCon France | Systems Modeling with the ARCADIA method and the Capella tool [6] | 24/06/2015 | Toulouse |
| Model-Based System Engineering (MBSE) Symposium | The Challenges of Deploying MBSE Solutions [7] | 28/10/2014 | Canberra |
| Model-Based System Engineering (MBSE) Symposium | Arcadia and Capella in the Field [8] | 27/10/2014 | Canberra |
| EclipseCon France | Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering [9] | 19/06/2014 | Toulouse |
| MDD4DRES ENSTA Summer school | Feedbacks on System Engineering – ARCADIA, a model-based method for Architecture-centric Engineering [10] | 01/09/2014 | Aber Wrac'h |
| EclipseCon North America | Arcadia / Capella, a field-proven modeling solution for system and software architecture engineering [11] | 20/03/2015 | San Francisco |
| Complex Systems Design & Management (CSDM) | ARCADIA: Model-Based Collaboration for System, Software and Hardware Engineering [12] | 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 [13] | 10/06/2013 | Arcachon |
| MAST | Toward integrated multi-level engineering - Thales and DCNS advanced Practices [14] | 04/06/2013 | Gdańsk |
| CSDM | Modelling languages for Functional Analysis put to the test of real life [15] | 2012 | Paris |
| ICAS | Method and tools to secure and support collaborative architecting of constrained systems [16] | 2010 | Nice |
| CSDM | Model-driven Architecture building for constrained Systems [17] | 2010 | Paris |
| INCOSE;08 Symposium | Method & Tools for constrained System Architecting [18] | 2008 | Utrecht |
Systems engineering is an interdisciplinary field of engineering and engineering management that focuses on how to design, integrate, and manage complex systems over their life cycles. At its core, systems engineering utilizes systems thinking principles to organize this body of knowledge. The individual outcome of such efforts, an engineered system, can be defined as a combination of components that work in synergy to collectively perform a useful function.
Software architecture is the set of structures needed to reason about a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations.
A data model is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities. For instance, a data model may specify that the data element representing a car be composed of a number of other elements which, in turn, represent the color and size of the car and define its owner.
Software design is the process by which an agent creates a specification of a software artifact intended to accomplish goals, using a set of primitive components and subject to constraints. The term is sometimes used broadly to refer to "all the activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying" the software, or more specifically "the activity following requirements specification and before programming, as ... [in] a stylized software engineering process."
Software development is the process used to conceive, specify, design, program, document, test, and bug fix in order to create and maintain applications, frameworks, or other software components. Software development involves writing and maintaining the source code, but in a broader sense, it includes all processes from the conception of the desired software through the final manifestation, typically in a planned and structured process often overlapping with software engineering. Software development also includes research, new development, prototyping, modification, reuse, re-engineering, maintenance, or any other activities that result in software products.
A modeling language is any artificial language that can be used to express data, information or knowledge or systems in a structure that is defined by a consistent set of rules. The rules are used for interpretation of the meaning of components in the structure Programing language.
In systems engineering and software engineering, requirements analysis focuses on the tasks that determine the needs or conditions to meet the new or altered product or project, taking account of the possibly conflicting requirements of the various stakeholders, analyzing, documenting, validating and managing software or system requirements.
In product development and process optimization, a requirement is a singular documented physical or functional need that a particular design, product or process aims to satisfy. It is commonly used in a formal sense in engineering design, including for example in systems engineering, software engineering, or enterprise engineering. It is a broad concept that could speak to any necessary function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder. Requirements can come with different levels of specificity; for example, a requirement specification or requirement "spec" refers to an explicit, highly objective/clear requirement to be satisfied by a material, design, product, or service.
In software project management, software testing, and software engineering, verification and validation (V&V) is the process of checking that a software system meets specifications and requirements so that it fulfills its intended purpose. It may also be referred to as software quality control. It is normally the responsibility of software testers as part of the software development lifecycle. In simple terms, software verification is: "Assuming we should build X, does our software achieve its goals without any bugs or gaps?" On the other hand, software validation is: "Was X what we should have built? Does X meet the high-level requirements?"
Software prototyping is the activity of creating prototypes of software applications, i.e., incomplete versions of the software program being developed. It is an activity that can occur in software development and is comparable to prototyping as known from other fields, such as mechanical engineering or manufacturing.
Business process modeling (BPM) in business process management and systems engineering is the activity of representing processes of an enterprise, so that the current business processes may be analyzed, improved, and automated. BPM is typically performed by business analysts, who provide expertise in the modeling discipline; by subject matter experts, who have specialized knowledge of the processes being modeled; or more commonly by a team comprising both. Alternatively, the process model can be derived directly from events' logs using process mining tools.
The Department of Defense Architecture Framework (DoDAF) is an architecture framework for the United States Department of Defense (DoD) that provides visualization infrastructure for specific stakeholders concerns through viewpoints organized by various views. These views are artifacts for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through tabular, structural, behavioral, ontological, pictorial, temporal, graphical, probabilistic, or alternative conceptual means. The current release is DoDAF 2.02.
In software engineering and systems engineering, a functional requirement defines a function of a system or its component, where a function is described as a summary of behavior between inputs and outputs.
The systems architect is an information and communications technology professional. Systems architects define the architecture of a computerized system in order to fulfill certain requirements. Such definitions include: a breakdown of the system into components, the component interactions and interfaces, and the technologies and resources to be used in its design and implementation.
Integrated circuit design, or IC design, is a sub-field of electronics engineering, encompassing the particular logic and circuit design techniques required to design integrated circuits, or ICs. ICs consist of miniaturized electronic components built into an electrical network on a monolithic semiconductor substrate by photolithography.
A system architecture is the conceptual model that defines the structure, behavior, and more views of a system. An architecture description is a formal description and representation of a system, organized in a way that supports reasoning about the structures and behaviors of the system.
Enterprise modelling is the abstract representation, description and definition of the structure, processes, information and resources of an identifiable business, government body, or other large organization.
Enterprise systems engineering (ESE) is the discipline that applies systems engineering to the design of an enterprise. As a discipline, it includes a body of knowledge, principles, and processes tailored to the design of enterprise systems.
A view model or viewpoints framework in systems engineering, software engineering, and enterprise engineering is a framework which defines a coherent set of views to be used in the construction of a system architecture, software architecture, or enterprise architecture. A view is a representation of the whole system from the perspective of a related set of concerns.
Capella is an open-source solution for model-based systems engineering (MBSE). Hosted at polarsys.org, this solution provides a process and tooling for graphical modeling of systems, hardware or software architectures, in accordance with the principles and recommendations defined by the Arcadia method. Capella is an initiative of PolarSys, one of several Eclipse Foundation working groups.
