MBSE with Arcadia method step-by-step: System Analysis

System Analysis step-by-step

The Operational Analysis described is the previous article, MBSE with Arcadia method step-by-step: Operational Analysis, involves defining and creating a domain model, independently of the future system to be realized. The principle is to create a level of abstraction from the system under study in order to focus on the needs of the different stakeholders.

The System Analysis level, on the other hand, is where the System-of-Interest (SoI) to be defined emerges. The following questions for the system definition needs to be answered:

• What must the system do?
• What are the external interfaces to the system?

In order to answer the first question, the expected behaviour is modelled as Functions.

Textual requirements if captured at Operational Analysis level, should be derived, and formalized at this level.

Below is listed the main activities expected for the System Analysis layer.

Main activities:

• Formalize and consolidate requirements.
• Identify system boundaries, external interfaces, and actors.
• Perform a functional and non-functional analysis.
• Identify functions of system and actors.
• Identify interfaces of the system (i.e., component ports).
• Identify information used in function and exchanges (classes data model can be defined).
• Perform a capability trade-off analysis.
• Identify system and actors’ capabilities.
• Identify and define functional chains and behavioural scenarios.
• Define System Modes and States.

System Analysis (SA)

“What the system must achieve for the users”.

This 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.

System Analysis artefacts and activities matrix

Below it is captured an arbitrary, but reasoned step-by-step choice in terms of activities and diagrams realization:

Define Context System Actors

One of the first diagrams that can be produced when realising the System Analysis (SA), is the Context System Actors [CSA], this diagram captures the System-of-Interest (SoI) and the actors, that is, all the Operational Entities and Actors previously identified and captured at Operational Analysis (OA) should be transitioned to SA; System Actors will be contextually created from Operational Entities and Actors defined at Operational Analysis.

This diagram is synchronised and automatically updated by the Capella tool with new actors. For example, new System Actors are identified and added during the System Architecture Blank [SAB] diagram elaboration.

Activities:

• Identify and capture new System Actors (e.g., operators, other external systems).

Capella Modelling tips:

• Perform a transition of the Operational Entities and Actors.

Define Missions and System Capabilities

Follow the capture of the Context System Actors diagram, the next diagram that can be produced is the Missions and System Capabilities (MCB). To produce this diagram, it is recommended to transition the Operational Capabilities (OC), from the OA. When done the transition OC can be decomposed further in Capabilities (C).

During the System Missions and Capabilities capture, asking the following questions may help to elaborate Missions and Capabilities:

• Mission: What is the purpose of the System?
• Capabilities: What service(s) shall the System provide?

Activities:

• Identify and define System Missions (i.e., system goals) and new System Capabilities for each System Capability.
• Identify involved Actors against each Capability.

Capella Modelling tips:

• Perform a transition of the Operational Capabilities and translate Operational Capabilities into System Capabilities.

Define System Functions

The Operational Activities identified during the Operational Analysis (OA) can be transitioned and refined into System Functions. The System Functions can then be allocated to a System Actor and/or lo a System Component.

It is important to note that the emergence of the functions is not merely a simple refinement of operational activities: the object is a different analysis, in which, for example, several operational activities can result in the same system function, and system needs functions may appear without necessarily corresponding to an operational activity (self-tests or reconfigurations, for example). Operational Activities refined and identified new System Functions can be allocated to System Actors and/or System Component. More details will be provided in the chapter System Functions allocation.

Recall that only needs-related considerations should be included in this perspective dedicated to the expression of the system needs as required by users or clients, excluding any choice of design or refinements not requested by the client, in order to preserve the largest flexibility possible of design further on. Therefore, certain choices delegated to the provider are not addressed here but will have to be considered in the perspectives dedicated to the solution.

Activities:

• Analyse and decompose Operational Activities to new System Functions and/or System Actors.
• Identify high-level System Functions containment relationship.

Capella Modelling tips:

• Transition Operational Activities and refine Operational Activities in new System Functions.
• Define a root function where all functions will be decomposed from.
• Good practice involves manually changing the colour of the parent functions transitioned from Operational Analysis to white.

Define Functional Exchanges

When functions are captured, functions interactions be defined, in a form of System Functional Exchanges.

Arcadia rule:

• As soon as a function is broken down into sub-functions, there is the need to work on the assignment of Functional Exchanges to the sub-functions of the parent Function. Only leaf Functions (those that are not broken down) can have input/output Ports.

Activities:

• Identify and define System Functional Exchanges.

Capella Modelling tips:

• Work on the assignment of Functional Exchanges to the sub-functions of the parent Function

Remember that the Functions in light blue are those that have been allocated to Actors.

Allocate System Functions to System Component and Actors

When System Functions are identified, captured, and refined there will be the need to ask whether each Operational Activity will be realized by the system in its entirety, partially, or not at all. The result at the System Analysis level can be formalized as follows:

• Entirely: the activity becomes a function of the same name, allocated to the system.
• Partially: the activity must be broken down into several functions, some of which are allocated to the system and others to at least one actor.
• Not at all: the activity becomes a function of the same name, allocated to an actor.

Arcadia rule:

• At every level of Arcadia, a Functional Exchange between two Functions allocated to two Behavioural Components must be allocated to a single Component Exchange between these two Components. This Component Exchange references all the Functional Exchanges that it implements. In general, a Component Exchange is made up of a synthesis of several Functional Exchanges that it implements and gathers together. The direction of the Component Exchange is purely conventional, but the general rule is that the direction of the Exchange is from the provider toward the user of the main data exchanged.
• Arcadia demands that Functional Exchanges be unidirectional. A Function Port is either an input or an output, and this property cannot be modified in Capella. On the other hand, a Component Exchange can be uni- or bi-directional. In fact, it is the Component Ports whose direction property can be edited: in, out, in out.
• A Function can only be allocated once. Similarly, a Functional Exchange can only be allocated to one Component Exchange.

Activities:

• Allocate functions to System Component and Actors.
• Allocate Function Ports to Component Ports.

Capella Modelling tips:

• Only leaf functions can have input/outputs ports.
• Traceability flow and consistency between different model elements is done via Arcadia ontology elements. Traceability can be verified in the Capella “semantic browser”.

Describe System Capabilities with Functional Chains

Functional data flow refers to all the dependencies that exist between Functions. A Functional Chain represents a set path in this global data flow. It is particularly useful for describing the expected behaviour of the system in each context, and therefore for piloting verification/validation tests. Functional Chains are also often used to express non-functional constraints in functional paths, such as latency, criticality, confidentiality, redundancy, etc.

System Functional Chains Description [SFCD] diagram is needed when a Functional Chain is already created and needs to be updated, e.g., new System Functions were captured and Functional Exchanges defined making the Functional Chain invalid (no continuity), hence, there is the need to update the chain with the new updates.

The SFCD diagram is always synchronized with the current state of the chain’s definition in the model. The model elements present in the diagram are not themselves Functions and Functional Exchanges, but rather references to these elements, called Functional Chain Involvement.

Activities:

• Define Functional Chains, by identifying what functions are involved in a functional path.

Capella Modelling tips:

• Transition Operational Processes from Operational Analysis, if defined.
• Invalid Functional Chains can be updated with the System Functional Chains Description diagram.

Describe System Capability with Functional Scenarios

As described in the Arcadia method section, a scenario describes the behaviour of the System in a context for a particular Capability.

Functional Scenarios [FS] describe a sequence in time of the interactions and lifelines are Functions.

Activities:

• Define the functions involved that describe a System Capability.
• Define the ordered sequence in time of the interactions.
• Consider including Modes & States and fragments to enrich the scenario.

Capella Modelling tips:

• Capella automatically creates a Capability the first time a Scenario is created unless a Capabilities already exist. In this case, Capella asks to choose one Capability to attach the new Scenario.
• Functional Scenarios can be created from a Capella transition of the Functional Chain.

Describe System Capability with Entity Scenarios

Similarly, to Functional Scenarios, Exchange Scenarios can be defined and where Exchange Scenarios lifelines are Components/Actors, and sequence messages are Functional or Component Exchanges.

Activities:

• Create Entity Scenarios (ES) that describe a System Capability.

Modelling tips:

• Consider including Functions, Modes & States, and fragments to enrich the scenario.
• Entity Scenarios can be transitioned, if created, from a Capella transition of a Functional Scenario.

Describe Capability Realizations with Functional Chains and Scenarios

System Capabilities can be described by Functional Chains and Scenarios as described above. Capella does provide automated transitions that facilitates the creation of the different scenarios as described above and captured again below:

• When a functional chain is defined, a Functional Chain can be transitioned and created a Functional Scenario.
• When a Functional Scenario is created, it can be transitioned and created an Entity Scenario.

System Analysis traceability flow

Similarly, to Operational Analysis, it is captured in the figure below the model elements and diagrams traceability and relationship:

• A Mission is exploited by System Capabilities.
• A System Capability should be described by Functional/Entity Scenarios and/or Functional Chains.
• A Functional/Entity Scenario and Functional Chains involve System Functions.
• System Functions are allocated to System Component and Actors.

Again, the presented flow of diagrams shows a reasoned step-by-step choice in terms of activities and diagrams. Arcadia and this guide do not impose any order on the diagram’s elaboration, both are flexible and can be elaborated in any sequence. It is the modeler choice and project needs that may drive the architecture design.

Conclusion:

The above Arcadia System Analysis guided step-by-step method, describes a reasoned step-by-step choice in terms of activities and diagrams. It can be seen in several of its diagrams traceability that is provided and inherent in the model. System Analysis defines the needs for the System-of-Interest (SoI), what it must do for the actors (i.e., external entities to the system), and identify and define interfaces.

It was provided some Capella tool modelling tips that should be followed to promote correctness of the model and some transitions that help and accelerate the modelling effort.

Further reading:

Part 1: MBSE with Arcadia method step-by-step: Operational Analysis

Part 3: MBSE with Arcadia method step-by-step: Logical Architecture

Part 4: MBSE with Arcadia method step-by-step: Physical Architecture

PDF file

FREE PDF file that includes this article can be found in the Part 1.

#MBSE #systemarchitecture #Arcadia #digitaltwin #architecture #engineering