Understanding what is the MBSE Arcadia method

Contents:

Arcadia introduction

ARChitecture And Design Integrated Approach (Arcadia) is a structured engineering method for defining and verifying the architecture of complex systems.

It promotes collaborative work among all key players, often in large numbers, from the engineering (or definition) phase of the system and subsystems, until their Integration Verification and Validation (IVV). It provides a means to perform as early as the definition phase the iterations that will allow the architecture to converge toward the adequacy of all identified requirements. Arcadia supports for engineering and its mastery, based on a formalization of the analysis of needs with operational, functional, and non-functional characteristics (expected functions of the system, functional chains, etc.), then on the definition/justification of the architecture from this functional analysis.

One of the ambitions of the method is that all stakeholders in engineering should share (concerning previous common objectives) the same methodical approach, the same information, the same need, and product description in the form of a set of shared models, described by a common language. Apart from this descriptive use, the purpose of these models is that they are also prescriptive for the development and implementation of the system, as well as support for an analysis of the choice of architecture and the anticipated verification of its properties.

All information produced by engineering, describing requirement and solution, are grouped within a single model (or set of models) shared by the various actors involved. This model will be designated as an engineering model. Other models and bases of information also exist, such as requirements, study and simulation models dedicated to various specialties (safety, security, performance, 3D digital representation, etc.), and everything else in engineering data (configuration management, campaigns and test results, defects database, etc.), however, the link between all these models and information, and the entry point for each stakeholder, should be this engineering model.

Co-engineering between the different engineering levels (system, subsystem, mechanical design, electronics, software, etc.) is supported by a framework allowing for joint model development, and the models of the different levels and trades are deducted/validated/linked between each other.

These models are part of the technical “contract” between engineering and their coherence is the guarantor of contract satisfaction, all the more in that they also enable the subsystem verification and validation strategy.

Co-engineering with specialty engineering (security, operation safety, human factors, performance, cost, mass, scalability, environment, interfaces, logistics, etc.) is supported by a multi-perspective approach.

Each set of constraints associated with one of these specialties is formalized in a dedicated “perspective”, which first characterizes the expectations of the system as seen from this specialty (“requirements”, feared events, expected performance or behaviour, etc.). Each candidate solution architecture is then subject to the verification of “standards” concerning the perspective. These standards for the verification of the architecture are established so as to be able to verify at the earliest the proposed architecture, during the definition/design phase, through the analysis of the models that describe it. The benefit is to be able to make the best compromise integrating all these constraints emerge more quickly, but also to justify the choices that lead to it and its adequacy to requirements.

IVV activities take advantage of modelling, first by defining their strategy from the functional capabilities that the model defines and from their links with the architecture of the components to be integrated; then test campaigns, and their impact on system components, are defined on the basis of the functional chains and use case scenarios defined in the model. Finally, defaults analysis and localization, testing optimization, in particular for non-regressions, are also greatly facilitated by the use of models.

Arcadia method focuses on function-driven modelling as opposed to requirements-driven modelling usually employed in SysML. Because of a function-driven modelling approach, Arcadia focuses on modelling functions and their interfaces and linking functional requirements to the functions.

Arcadia defines different perspectives/layers that structure the implementation of an architecture as defined below:

Arcadia method layers overview

The Arcadia method applies or shows how to implement the framework. A framework is made up of one ontology and one or more viewpoints. By definition an ontology captures concepts and descriptions and relationships between the different ontology elements. These relationships are key to ensure traceability consistency.

Viewpoints uses elements and are defined based on one ontology. A viewpoint provides the template definition for one or more views. That is, viewpoints use a sub-set ontology element that fulfils a stakeholder expectation. For example, a stakeholder needs to visualise and define Operational Entities and Actors in a model, the operational entities viewpoint does include the Operational Entity and Operational Actor ontology elements.

Views forms part of the model and one or more views conform to a viewpoint.

Capella tool implements the Arcadia notation. The notation or Arcadia language contains a number of diagrams.

A diagram is the Capella tool mechanism to visualise a view.

In the Capella tool it can be seen in the project explorer two files: .aird and .melodymodeller. The first stores the model and Arcadia model elements relationships, the second stores the Capella diagram representations.

The figure below shows the scope split between Arcadia and Capella:

Scope split between Arcadia and Capella

As described in the previous section, the Operational Analysis (OA) layer is the Arcadia highest and most abstract layer. Traceability between model elements and consistency between views, is ensured by the Arcadia ontology definition.

The figure below, shows part of the rich Arcadia ontology. The ontology defines that Operational Capabilities can be traced and described by Operational Processes and/or Operational Scenarios. In turn, Operational Processes and Operational Scenarios involve (i.e., reference) Operational Activities. Operational Activities should be allocated to Operational Entities and Actors responsible to perform the Operational Activity. Each of the above model elements can be categorised under different categories: capability, capability description, functions or behaviour and structure.

Traceability is also observed between the different lower layers.

Hence, traceability can be done and followed from a top-down or bottom-up. This feature is quite relevant to justify an architecture and provide with rationale and understanding at all layers of an Architecture.

Arcadia ontology traceability

Arcadia as described in the section above, defines an ontology that promotes and supports consistency when defining a product or service architecture. Each Arcadia layer and model elements are linked to those of the previous and next layers (if defined) by justification links. This is a powerful feature as a model may capture from top what are the user needs, defined at the next layer what is system expected to, followed by the how the system will work and be built at the physical layer. Hence, the model provides the ability to navigate the different justification links and provide with the rationale inherent and capture in the model.

For example, by following justification links it is possible to:

  • Understand and verify what functions have been derived from layers above.
  • What structural elements (e.g., system components) host which functions.
  • How it is described a Capability, that is, what functions, interactions and models & states are involved. Capabilities helps the modeler to think what functions are needed and how they will interact, for example.
  • What are the interfaces between the different components and visually verify for any design flaws with the different stakeholders.

In most cases, these justification links connect elements of the same nature, as presented in the figure below.

Arcadia ontology traceability

Arcadia compliance with best practises

In the sections hereafter, it will described what is expected for each Arcadia layers, concepts, but also Arcadia compliance with the standard ISO/IEC/IEEE15288 (aka ISO15288).

Arcadia framework does provide concepts that covers and models part of the standard ISO15288 technical process, as shown in the image below:

The work resulting from the activities at needs (i.e., Operational and System Analysis) and solution (i.e., Logical and Physical architecture) modelling activities can be used as a reference for implementation and later for verification and validation.

Operational Analysis

“What system users must achieve”.

The Operational Analysis perspective analyses the issue of operational users, by identifying actors that have to interact with the system, their goals, activities, constraints, and the interaction conditions between them.

This perspective allows to model the required high-level operational capabilities and perform an operational needs analysis without even defining the system-of-interest, in fact the system is not even mentioned at this layer.

Operational analysis concepts

Hereafter, it will be described the main concepts:

Complying with Business or Mission analysis process

As stated in the ISO/IEC/IEEE 15288 [6.4.2.1]:

The purpose of the Business or Mission Analysis process is to define the business or mission problem or opportunity, characterise the solution space, and determine potential solution that could address a problem or take advantage of an opportunity.”

Arcadia framework and the Operational Analysis layer, provides the ability to capture business or mission analysis, in order to define the business, mission problem or opportunity to be characterised by a solution. This can be done by capturing how an organisation intends to operate to achieve enterprise mission and goals. In modelling terms, this represents capturing stakeholders, operational capabilities, activities and capturing operational scenarios from a business perspective for a future system.

Complying with Stakeholder needs and requirements definition process

As stated in the ISO/IEC/IEEE 15288 [6.4.2.1]:
The purpose of the Stakeholder Needs and Requirements Definition process is to define the stakeholder requirements for a system that can provide the capabilities needed by users and other stakeholder in a defined environment.”

The Operational Analysis layer also provides the ability to capture how the system is intended to be used by the stakeholders involved in the system lifecycle, this can be, operators, testing and maintenance, training and decommissioning as mentioned by the standard.

To define the stakeholder needs and requirements, it can be done by capturing how a stakeholders or group intends to interact with the system. In modelling terms, this represents capturing stakeholders, operational capabilities, activities and capturing operational scenarios from a stakeholder perspective for a future system, similarly to business analysis above, but from the perspective what operational capabilities are expected from the stakeholders interacting with the system during its lifecycle. Textual stakeholder requirements can be captured in the tool or imported from a requirements management tool and traced to operational analysis model elements.

System Analysis

“What the system must achieve for the users”.

The System Analysis perspective focuses on the system itself as a black box, in order to define how it can satisfy the former operational needs. This perspective builds an external functional analysis, which is constructed based on the operational analysis and textual input requirements and outlined with respect to them.

System analysis concepts

In the section below, it will be described the main System Needs Analysis concepts.

Complying with System requirements definition process

As stated in the ISO/IEC/IEEE 15288 [6.4.3.1]:
The purpose of the System Requirements Definition Process is to transform the stakeholder, user-oriented view of desired capabilities into a technical view of a solution that meets the operational needs of the user.

This process is to transform stakeholder requirements into system requirements. This activity can be supported by the model captured at operational analysis, providing a rationale, analysis of the stakeholder requirements. System requirements can then be formalised and traced to requirements with traceability links.

In Arcadia terms, system capabilities, functions, interactions within and with external entities, interfaces and traceability to operational analysis can be captured at System Analysis layer.

As a good practise and reminder, requirements should be captured at the same level as of the system, system requirements should be captured and traced to model elements at this Arcadia layer.

Logical Architecture

“How the system will work to meet expectations”.

The previous System Analysis consisted of functionally analysing the System seen as a “black box” to specify its expected behaviour, as well as exhaustively identifying important external exchanges with the Actors.

The principle of the Logical Architecture (LA), commonly called logical architecture, starts to “open the box” by implementing the big decisions of the solution, in terms of principles of construction, and ways to fulfil the expectations of stakeholders; it is then formalized by means of a decomposition into abstract structural elements called Logical Components, and principles of behaviour and interaction between one another, in response to the previous needs.

The definition of the LA consists mainly of a comparison between the needs expressed in previous perspectives, a functional analysis describing the system behaviour chosen to satisfy requirements, and a structural analysis intended to identify the Logical Components that will constitute the system, taking the chosen constraints and structuring principles into account.

The LA is therefore a first general vision, moderately detailed, somehow an abstraction, of what the architecture of the system will be.

Its definition is deliberately maintained at a quite coarse-grained level of detail, just enough to be able to make major decisions for guiding the design, nothing more.

In addition to the identification of the major “imposed” factors constraining the definition of the architecture, the major design decisions structuring it must also be defined and formalized.

Any design detail or accuracy that does not influence the construction or choice decisions of the LA is not justified and will be described later in the physical architecture.

The important rule to comply with is to force ourselves to exclude all technological considerations or implementation choices. This will be the very objective of the Physical Architecture to define the “true” concrete components, which will constitute the System.

Excluding all technological considerations as a design choice will not however prevent us from beginning to take the Non-Functional Constraints into account; Operating Safety, Performance, etc., requirements can thus lead us to group the Functions together in different Components.

Logical Architecture must be stable throughout the whole duration of the project. This will probably not be the case for Physical Architecture, especially if the System must have a long lifespan, due to the technological novelties that will occur and the new Physical Components that may cause large parts of the architecture to be called into question.

Logical architecture concepts

Complying with Architecture definition process

As stated in the ISO/IEC/IEEE 15288 [6.4.4.1]:
The purpose of Architecture Definition process is to generate system architectures alternatives, to select one or more alternatives that frame stakeholder concerns and meet system requirements, and to express this is a set of consistent views.

This process starts to unfold the solution that meets the system needs captured in previous layer. The intent and activities as this layer are to capture system architectures alternatives, principles, concepts, properties and characteristics for the system-of-interest. Concepts capture an architecture independent of any technology or solution, that is should be captured at the next layer, Arcadia Physical Architecture.

Physical Architecture

“How the system will be built”.

The Physical Architecture perspective defines the finalized architecture of the system, as it should be completed and integrated. It adds the functions required by the implementation and technical choices and reveals the behavioural components that perform these functions. These behavioural components are then implemented using host implementation components that offer them the necessary material resource.

Physical architecture concepts

Complying with Design definition process

As stated in the ISO/IEC/IEEE 15288 [6.4.5.1]:
The purpose of the Design Definition Process is to provide sufficient detailed data and information about the system and its elements to enable implementation consistent with the architectural entities as defined in the models and views of the system architecture.

Arcadia Physical Architecture provides the “Implement-to” level of the definition. This maps and is compliant with the design definition process, to provide sufficient detailed data and information about the system and its elements to enable implementation consistent with the architectural entities as defined in the models and views of the system architecture captured in the previous Logical Architecture.

At this level, real physical and implementation elements are captured. This provides and facilitates a better transition with the implementation layer and product to be developed and it is expected at this layer system architects to work with domain specific product owners.

Capella modelling tool

Capella is the tool been purposely built to provide the notation and diagrams needed to create models that exactly fit with Arcadia’s approach. Capella implements and supports the Arcadia metamodel, allowing the creation of requirement elements and linking them to the model element in any Capella diagram. Alternatively, requirements can be imported from an external requirements management database in ReqIF (Requirements Interchange Format) standard.

Below a diagram that shows Capella, Arcadia language and method implementation and compliance with standard ISO15288:

MBSE with Arcadia FREE mini-course

The MBSE with Arcadia FREE mini-course provides and interactive learning based on the content found within this webpage. Access to MBSE with Arcadia course is FREE.