Modern systems are subject to increasingly higherconstraints regarding expected behavior and services, safety, security, performance, environment,human factors, etc. All these constraints are under theresponsibility of different stakeholders, which need to be reconciled during the solutionarchitectural design and development process.
Architecture as prime engineering driver
Architecture definition is a major part of engineeringactivities, and notably includes analyzing operational needs,structuring and decomposing the system, software, or hardwareassets in order to
- Provide significant information for decision-makers andmanagers
- Ease the mastering of need, complexity, design anddevelopment
- Structure engineering in a well-defined, justified,technical frame
- Guide designers and developers to respect the productdefinition drivers.
Arcadia, a model-based engineering method
Arcadia is a model-based engineering method for systems,hardware and software architectural design. It has been developedby Thales between 2005 and 2010 through an iterative processinvolving operational architects from all the Thales businessdomains. Since 2018, Arcadia is registered as Z67-140 standard by AFNOR, the French national organization for standardization.
Arcadia promotes a viewpoint-driven approach (as described inISO/IEC 42010) and emphasizes a clear distinction between need andsolution.
Perspectives and activities of the method have been defined in order to comply with afew Golden Rules:
- Besides requirement engineering, drive an operational and functional/nonfunctionalneed analysis, describing final user expectations, usageconditions, and realistic integration, verification and validation conditions
- Consider engineering through three mandatory interrelatedactivities, at the same level of importance:
- Need analysis and modelling
- Architecture building and validation
- Requirements engineering
- Check requirements against an architectural designmodel (early architecture) for robustness and feasibility
- Structure the system/hardware/software and build a logicalarchitecture, by searching for the best compromise betweendesign drivers, (non-functional) constraints and viewpoints. Eachviewpoint deals with a specific concern such as functionalconsistency, interfaces, performances, real time, safety,security, integration, reuse, cost, risk, schedule, and the easeof adaptation (e.g. to changing requirements)
- Secure development and IVVQ through a physicalarchitecture which deals with technical and development issues,favoring separation of concerns, efficient and safe componentinteraction (e.g. layered architecture, generic behavior andinteraction patterns, component model, etc.)
Noticeable features of Arcadia
- Models supporting enterprise-wide collaboration andco-engineering
- An Eclipse Capella™ model is built for each Arcadia engineeringphase. All of these models are articulated through modeltransformation, and related by justification links; they areprocessed as a whole for impact analysis, notably in case ofrequired evolutions.
- Collaboration with engineering specialties is supportedby modelled engineering viewpoints to formalize constraints andto evaluate architecture adequacy with each of them
- Collaboration with customer and subsystems engineeringrelies on co-engineered models (e.g. physical architecture),automatic initialization of need model for sub-systems, andimpact analysis means between requirements and models ofdifferent engineering levels.
- Integration, verification, validation and qualification(IVVQ) are driven by user capabilities, functional chains andscenarios in the model, rather than by textual requirements
- Elaboration of product line variabilities andconfigurations is optimized and assisted based on operationalmarket segmentation, commercial portfolio contents andarchitecture constraints/adaptations to product policy, alldescribed in the model.
- Tailored for architectural design
- A domain-specific language (DSL) was preferred in orderto ease appropriation by all stakeholders, usually not familiarwith general-purpose, generic languages such as UML or SysML.
- Dealing with complexity and size
- Abstraction levels are in the DNA of Arcadia. Capellaadvanced mechanisms have been developed to mask and confinecomplexity, deal with model maintenance, large-scale modelling,model evolution and reuse.
- Field-proven in real industrial situations
- Arcadia is currently applied in various domains and organizations, in many countries, on very large or small projects, bythousands of users. A continuous challenging, improvement andadaptation of both the method and its supporting workbench hasfavored a very fast dissemination.
- Open to domain-specific added value
- Adapted to several lifecycles and work sharing schemes
Next paragraphs give a first description of major arcadia perspectives, for a given engineering level (system, sub-system, software or hardware part…).
Definition of the Problem - Customer Operational NeedAnalysis
The first perspective focuses on analyzing the customer needs and goals,expected missions and activities, far beyond system requirements.This analysis aims at ensuring adequate system definitionwith 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 needin terms of actors/users, their operational capabilities andactivities (including operational use scenarios with dimensioningparameters, and operational constraints such as safety, security,lifecycle, etc.).
Watch the video below, illustrating this architecture level with a commented example: the level-crossing traffic control.
Formalization of system requirements - System Need Analysis
The second perspective focuses on the system itself, in order todefine how it can satisfy the former operational need, alongwith its expected behavior and qualities. The following elementsare created during this step: Functions (or services) to be supported and relatedexchanges, non-functional constraints (safety, security, etc.);performance allocated to system boundary; role sharing andinteractions between system and operators; scenarios of usage, etc.
The main goal at this stage is to check the feasibility ofcustomer 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 systemarchitectural design model in order to examine requirements againstthis architecture and evaluate their cost and consistency.
Outputs of this engineering phase mainly consist of systemfunctional need descriptions (functions, functional chains,scenarios), interoperability and interaction with the users andexternal systems (functions, exchanges plus non-functionalconstraints), and system requirements.
Note that these two phases, which constitute the first part ofarchitecture building, "specify" the subsequent design, andtherefore should be approved/validated with the Customer.
Watch the video below, illustrating this architecture level with a commented example: the level-crossing traffic control.
Definition of solution architecture - LogicalArchitecture (Notional Solution)
This third perspective aims at building acoarse-grained component breakdown of the system carryingmost important engineering decisions, and which is unlikely to bechallenged later in the development process. Starting from previousfunctional and non-functional need analysis, a first definition ofthe solution expected behavior is performed (using functions,interfaces, data flows, behaviors…). In order to embed thesefunctions, one or several decompositions of the system into logicalcomponents are to be built, each function being allocated to onecomponent. These logical components will later tend to be the basicdecomposition for development/sub-contracting, integration, reuse,product and configuration management item definitions (but othercriteria will be taken into account to define the boundaries forthese items)
The building process has to take into account architecturaldrivers and priorities, viewpoints and associated design rules,etc. For the component breakdown to be stable in further engineeringphases, all major (non-functional) constraints (safety, security,performance, IVV, cost, non-technical, Etc.) are taken into accountand compared to each other so as to find the best trade-off. Thismethod is described as "viewpoint-driven", where viewpointsformalize the way these constraints impact the system architecture.
Outputs of this engineering phase consist of the selectedlogical architecture which is described by a functionaldescription, components and justified interfaces definition,scenarios, modes and states, along with the formalization of allviewpoints and the way they are taken into account in thecomponents design.
Since the architecture has to be validated against the needanalysis, links with requirements and operational scenarios arealso to be produced.
Watch the video below, illustrating this architecture level with a commented example: the level-crossing traffic control.
Definition of solution architecture - Physical Architecture
The fourth perspective has the same intent as the logical architecturebuilding, except that it defines the “final” architecture of thesystem at this level of engineering. Once this is done the model isconsidered ready to develop (by "lower" engineering levels).Therefore, it introduces further details and design decisions,rationalization, architectural patterns, new technical services andbehavioral components, and makes the logical architecture visionevolve according to implementation, technical and technologicalconstraints and choices. It notably introduces resource componentsthat will embed former behavioral components. The sameviewpoint-driven approach as for logical architecture building isused.
Outputs of this engineering phase consist of the selectedphysical architecture which includes components to be produced,formalization of all viewpoints and the way they are taken intoaccount in the components design. Links with requirements andoperational scenarios are also produced.
Watch the video below, illustrating this architecture level with a commented example: the level-crossing traffic control.
Building Strategy - Contracts forDevelopment and IVVQ
The fifth and last perspective is a contribution to an EPBS(End-Product Breakdown Structure), and models describingspecification of each sub-system, hardware or software component;it takes benefits from the former architectural work, to formalizethe component requirements definition and prepare a secured IVVQ.
All previous hypotheses and imposed constraints associated tothe system architecture and components are summarized and checkedhere.
Outputs from this engineering phase are mainly new models describing componentintegration contracts, collecting all necessary expected propertiesfor each component to be developed.
Co-Engineering, Sub-Contracting and Multi-Level Engineering
The physical architecture is the preferred place for co-engineeringbetween systems, software, and hardware stakeholders.
Arcadia can be applied in a recursive way at each level ofsystem breakdown, so that a subsystem of the current system ofinterest becomes the system at the next level of interest, untilsingle discipline subsystems or procurement items or COTS areidentified.
The physical architecture at a given level of interestdefines 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 andneighborhood, in order to define its IVVQ context while preservingIntellectual Property constraints.
Adaptation of Arcadia to Dedicated Domains, Contexts, Etc.
Beyond the transverse, common architectural design work, eachorganization, in the field of its own business, constraints andknow-how, should tailor the method steps by adapting them totheir own domains, products and programs. This includes:
- Definition of a reference architecture (includingarchitecture drivers) for each key product and software element
- Definition of appropriate viewpoints adapted to thedomain, product and architecture
- Definition of complementary dedicated engineering rules
- Selection of relevant architectural patterns for thedomain, product, and technologies considered
- Setting up of models, based on the reference architectureand viewpoints, and basis for simulation, early validation,automation of the design process (key for productivity gains)
- Definition of adjustment rules for each of its contexts
- Dissemination in the engineering teams (training,coaching)...
Adaptation to different Lifecycles
The recommended method described in this document takes bestbenefit from a top-down approach:
- Starting from operational and system need to define and validaterequirements
- Building a "technology neutral" logical architecturedealing with non-functional constraints
- Then specifying technical functions and services of aphysical architecture to implement it in the best way
Yet many constraints which need to be taken into accountarise from the industrial context:
- Technical or technological limits
- Available technology, COTS
- Existing legacy to be reused
- Product policy imposing the use of given hardware boards,software components...
- Industrial constraints such as available skills, thenecessity to sub-contract, and export control...
This is the reason why Arcadia can be applied according to severallifecycles and work sharing schemes. Great care has been taken inthe method, the language and the Capella workbench to not impose onesingle engineering path (e.g. top-down) but to be adaptable to manylifecycles: Incremental, iterative, top-down, bottom-up,middle-out, Etc.. The method is inherently iterative.
Examples of iterations or non-linear courses are:
- Need analysis starting from requirements, due to a lack ofoperational knowledge (a kind of reverse engineering ofoperational need)
- Requirements analysis anticipating logical or evenphysical architecture, to check for feasibility bydefining/confronting to an early architecture
- Logical architecture anticipating (part of) physicalarchitecture, e.g. to check for performance issues
- Physical architecture adapting to subcontractingconstraints, or built from assembling reusable, existingcomponents
- Components contract definition iterating on physicalarchitecture to secure integration and refine contract parameters
