Modern systems are subjected to increasingly higher constraints regarding safety, security, performance, environment, human factors, etc. Each of these constraints are under the responsibility of different stakeholders which deeply influences the systems architectural design and development process. They are to be integrated and reconciled.
Architecture is a powerful tool to analyse operational needs, to structure and to break down the system, software, or hardware function in order to:
Arcadia is a model-based engineering method for systems, hardware and software architectural design. It has been developed by Thales between 2005 and 2010 through an iterative process involving operational architects from all the Thales business domains.
Arcadia promotes a viewpoint-driven approach (as described in ISO/IEC 42010) and emphasizes a clear distinction between need and solution.
Steps and activities of the method have been defined with a few Golden Rules:
The first step focuses on analysing the customer needs and goals, expected missions and activities, far beyond system requirements. This analysis aims at ensuring adequate system definition with regard to its real operational use and IVVQ conditions.
Outputs of this engineering phase mainly consist of an “operational architecture” which describes and structures the need in terms of actors/users, their operational capabilities and activities (including operational use scenarios with dimensioning parameters, and operational constraints such as safety, security, lifecycle, etc.).
The second step focuses on the system itself, in order to define how it can satisfy the former operational need, along with its expected behaviour and qualities. The following elements are created during this step: Functions to be supported and related exchanges, non-functional constraints (safety, security, etc.), performance allocated to system boundary, role sharing and interactions between system and operators, etc.
The main goal at this stage is to check the feasibility of customer requirements (cost, schedule, technology readiness, etc.) and if necessary, to provide means to renegotiate their content. The functional need analysis can be completed by an initial system architectural design model in order to examine requirements against this architecture and evaluate their cost and consistency.
Outputs of this engineering phase mainly consist of system functional need descriptions (functions, functional chains, scenarios), interoperability and interaction with the users and external systems (functions, exchanges plus non-functional constraints), and system requirements.
Note that these two phases, which constitute the first part of architecture building, "specify" the subsequent design, and therefore should be approved/validated with the Customer.
This third step aims at building a coarse-grained component breakdown of the system which is unlikely to be challenged later in the development process. Starting from previous functional and non-functional analysis refined results (functions, interfaces, data flows, behaviours…), build one or several decompositions of the system into logical components. These logical components will later tend to be the basic decomposition for development/sub-contracting, integration, reuse, product and configuration management item definitions (but other criteria will be taken into account to define the boundaries for these items)
The building process has to take into account architectural drivers and priorities, viewpoints and associated design rules, etc. For te component breakdown to be stable in further engineering phases, all major (non-functional) constraints (safety, security, performance, IVV, cost, non-technical, Etc.) are taken into account and compared to each other so as to find the best trade-off. This method is described as "viewpoint-driven", where viewpoints formalise the way these constraints impact the system architecture.
Outputs of this engineering phase consist of the selected logical architecture which is described by components and justified interfaces definition, scenarios, modes and states, formalisation of all viewpoints and the way they are taken into account in the components design.
Since the architecture has to be validated against the need analysis, links with requirements and operational scenarios are also to be produced.
The fourth step has the same intent as the logical architecture building, except that it defines the “final” architecture of the system at this level of engineering. Once this is done the model is considered ready to develop (by "lower" engineering levels). Therefore, it introduces rationalisation, architectural patterns, new technical services and components, and makes the logical architecture evolve according to implementation, technical and technological constraints and choices. The same viewpoint-driven approach as for logical architecture building is used.
Outputs of this engineering phase consist of the selected physical architecture which includes components to be produced, formalisation 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 an EPBS (End-Product Breakdown Structure), taking benefits from the former architectural work, to formalise the component requirements definition and prepare a secured IVVQ.
All previous hypotheses and imposed constraints associated to the system architecture and components are summarised and checked here.
Outputs from this engineering phase are mainly component integration contracts collecting all necessary expected properties for each component to be developed.
The physical architecture is the preferred place for co-engineering between systems, software, and hardware stakeholders.
Arcadia can be applied in a recursive way at each level of system breakdown, so that a subsystem of the current system of interest becomes the system at the next level of interest, until single discipline subsystems or procurement items or COTS are identified.
The physical architecture at a given level of interest defines the components to be developed at the level above, according to the corresponding component integration contract. Level "n" need analysis is restricted to each component scope, in order to define its IVVQ context.
Beyond the transverse, common architectural design work, each organization, in the field of its own business, constraints and know-how, should tailor the method steps by adapting them to their own domains, products and programs. This includes:
The recommended method described in this document takes best benefit from a top-down approach:
Yet many constraints which need to be taken into account arise from the industrial context:
This is the reason why Arcadia can be applied according to several lifecycles and work sharing schemes. Great care has been taken in the method, language and the Capella workbench to not impose one single engineering path (e.g. top-down) but to be adaptable to many lifecycles: Incremental, iterative, top-down, bottom-up, middle-out, Etc.. The method is inherently iterative.
Examples of iterations or non-linear courses are: