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

Physical Architecture step-by-step

The previous Logical Architecture layer started by “opening the black box” in order to identify the structural elements called Logical Components, as well as their properties and relations. The important rule followed is to ensure that it was excluded all technological considerations or implementation choices on this level. This is exactly the objective of the Physical Architecture in defining the “real” concrete components that comprise the system. To start the Physical level based on the Logical level, Capella proposes transitions similar to those that we used when we went from the Operational Analysis to the System Analysis, then from the System Analysis to the Logical Architecture. Thus, it can be created as many Physical Functions as Logical Functions, by also keeping the Functional Exchanges and Functional Chains.

Main activities performed at Physical Architecture:

• Define final architecture and functions breakdown.
• Deploy behavioural components.
• Consider reuse of existing model elements.

Physical Architecture (PA)

“How the system will be built”.

This 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 artefacts and activities matrix

Below are captured the main activities to be performed when defining the high-level Physical Architecture.

Let’s recall that the Capella tool automatically creates a Realization Link between each Physical element (e.g., Function, Functional Exchange, Functional Chain) and the Source Logical element. Also recall that the transitions are iterative and incremental and that noticed, for example, that if a Logical Function is missing when working on the Physical level, it must be absolutely added to the Logical level and apply the transition again

Capabilities Realization at Physical Architecture layer

One of the first activities to perform when moving to the Physical Architecture is to carry on the work performed at the Logical Architecture level. Hence, transitions of the Logical Capabilities Realization can be performed by Capella from the Activity Explorer. Create the diagram Contextual Realization Blank (CRB) and verify that all Physical Actors are involved in at least one Capability Realization.

Activities:

• Verify that all actors are involved with at least one Capability Realization.

Modelling tips:

• Transition Logical Capabilities Realization.

Define Physical Functions

When Logical Functions are transitioned it can be further refined in new Physical Functions; refined functions can be grouped under related functionality (e.g., monitor or control functions group).

Let’s recall when modelling activities are performed in the model it is quite often for a modeler to add new functions in other diagrams, for example, Physical Architecture Blank (LAB) diagram. As a good modelling practice the Physical Functions Breakdown Diagram (PFBD) should be revisited and organised and defined functions involvement, if needed.

As mentioned at Logical Architecture, it is a good practice to change the colour of the transitioned Logical Functions from green to white in the (PFBD). This can help the modeler to visually identify what functions are related to the Logical Architecture layer and considered to be further refined.

Activities:

• Refine, where needed, Logical Functions in Physical Functions.
• Identify containments (hierarchy).

Modelling tips:

• Transition of Logical Functions.
• Similar approach applied in the LFBD to the PFBD, change the transitioned logical functions background to white, it will help to identify which functions were captured at logical layer and transitioned to the physical layer.
• Update this diagram when new functions added during the logical architecture design.

Define Physical Functional Exchanges

When functions have been identified, functional exchanges can be defined between “leaf” functions. Remember, that only leaf functions should have Functional Exchanges and later allocated to a Behavioural Physical Component.

Recall when a Logical Function is refined in new Physical child Functions, Functional Ports belonging to the Logical Functions should be delegated.

Activities:

• Identify Functional Exchanges between Physical Functions.
• Diagrams can be created and focused in one aspect of the behaviour, for example to describe a capability realization.

Modelling tips:

• Logical functions can be refined in more detail at physical layer. Do not forget to delegate (i.e., move) function ports from a transitioned system function to the correspondent physical decomposed child function.

Define Behavioural and Physical Nodes

As described before in the Arcadia method section there are two types of Physical Components in Arcadia:

• Node Physical Components, which may contain other Node Components.
• Behaviour Physical Components, which will be deployed on the Node Physical Components.

A Behaviour Physical Component is a component of the System, responsible for performing some of the Functions assigned to the system, by interacting with other Behaviour Components and with that of the external Actors. A Node Physical Component is a component that hosts a certain number of Behaviour Components, by providing them with the resources required for them to operate and interact with their environment. A Behaviour Component is hosted by one single Node Physical Component.

At logical layer it was strongly advised to exclude all technological consideration or implementation choice. At Physical Architecture layer, technological considerations should be considered.

Refine the Logical Components into Behavioural Physical Components and identify parent – child components hierarchy relationship, in addition identify and capture Node Physical Components.

As a good modelling approach revisit the Physical Component Breakdown Diagram (PCBD) and ensure this diagram is still correct and consistent. That is, during modelling activities new Behavioural and Node Physical Components can be created in different diagrams (e.g., PAB diagram) and new components involvement may need to be verified for consistency.

Activities:

• Identify and define Behavioural Physical Nodes
• Identify and define Node Physical Component.

Modelling tips:

• Transition of Logical Components.
• Revisit the (LCBD) diagram to ensure correctness.

Allocate Functions to Behavioural Nodes and deploy Physical Nodes Components

When Physical Functions and components have been identified and captured, functions can be allocated to the relevant Behavioural Physical Component. To allocate functions to Behavioural Physical Components a Physical Architecture Blank (PAB) diagram can be created and perform the task.

During the elaboration of this diagram, new physical functions can be identified and captured as this diagram provides functions allocated to Behavioural Physical Component, hence, functions are now captured in context. Hence, the verification process described above still applies when new functions and components are captured in a PAB diagram.

The PAB diagram allows to create Behavioural Physical Component exchange between Behavioural Components that implements Functional Exchanges.

The Physical Architecture Blank (PAB) diagram also allows to define Physical Link and Physical Path. Physical Links provides the means to transport Component Exchanges and connect different Node Physical Components. The

Activities:

• Allocate Physical Functions to Behavioural Nodes Components.
• Define Behavioural Physical Components Exchange.
• Deploy Behavioural Physical Components in Physical Nodes Components.
• Allocate Functional Ports to Behavioural Physical Component Port.
• Behavioural Physical Component Ports to Node Physical Component Port.
• Define Physical Path.

Modelling tips:

• As a good approach re-visit the diagrams that capture functions (PFBD) and components (PCBD) breakdown and verify if diagrams are still correct and consistent.

Describe Capability Realizations with Functional Chains and Scenarios

Similarly, Logical Architecture, a Capability Realization can be described by Functional Chains and scenarios.

Activities:

• Identify functions involved in a functional chain that describes a Capability Realization.
• Create Functional and Entity Scenarios that describe a Capability Realization.

Modelling tips:

• When a Functional Chain is created, it can be transitioned and created a Functional Scenario.
• A Functional Scenario can then be transitioned and created an Entity Scenario.
• Transitioned functional chains might need to be “reconstructed” as the Physical Functions were decomposed at Physical Architecture and Functional Chains might have turned as invalid.

Physical Architecture traceability flow

Similarly, to Logical Architecture, in the figure below the model elements traceability and diagrams relationship is captured:

• A Physical Capability Realization can be described by Functional Chain and/or Functional/Entity Scenarios.
• A Functional/Entity Scenario and Functional Chains involve Physical Functions.
• Physical Functions are allocated to Behavioural Component and Actors.
• Behavioural Component are deployed in Physical Nodes.

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 Physical Architecture 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.

As described, the principle of the Physical Architecture 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.

It was provided in this article and in the previous articles that forms the Arcadia method, activities and expected artefacts as outcome of each of them. 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.

References and further reading of the previous articles can be found below.

Further reading:

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

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

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

PDF file

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

#mbse #arcadia #capella #systemarchitecture #digitaltwin #engineering