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.

1. MBSE with Arcadia method
step-by-step
Physical Architecture
Author: Hélder Castro
Contact: helder.r.castro@gmail.com
LinkedIn: www.linkedin.com/in/heldersilvacastro

2. Contents
1. Introduction ....................................................................................................................................3
2. Physical Architecture (PA)...............................................................................................................3
2.1. Physical Architecture concepts...............................................................................................3
3. Physical Architecture artefacts and activities matrix......................................................................4
3.1. Capabilities Realization at Physical Architecture....................................................................4
3.2. Define Physical Functions .......................................................................................................5
3.3. Define Physical Functional Exchanges ....................................................................................6
3.4. Define Behavioural and Physical Nodes..................................................................................7
3.5. Allocate Functions to Behavioural Nodes and deploy Physical Nodes Components .............8
3.6. Describe Capability Realizations with Functional Chains and Scenarios ................................9
3.7. Physical Architecture traceability flow ...................................................................................9
Conclusion.............................................................................................................................................14
Bibliography ..........................................................................................................................................15
Figures
Figure 2.1: Physical Architecture main concepts....................................................................................4
Figure 3.1: [CRB] Physical Capability Realization Blank ..........................................................................5
Figure 3.2: [PFBD] Physical Functions Breakdown Diagram ...................................................................6
Figure 3.3: [PDFB] Logical Dataflow Blank..............................................................................................7
Figure 3.4: [PCBD] Physical Components Breakdown Diagram..............................................................7
Figure 3.5: [PAB] Physical Architecture Blank.........................................................................................8
Figure 3.6: Physical Functional Chain and Scenarios definition..............................................................9
Figure 3.7: Physical Architecture traceability flow ...............................................................................10
Table
Table 3.1: Physical Architecture activities and artefacts ........................................................................4

3. 3
1. Introduction
The previous Logical Architecture [1] 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.
2. 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.
2.1. Physical Architecture concepts
In the section below, it will be described the main Physical Architecture concepts.

4. 4
Figure 2.1: Physical Architecture main concepts
3. Physical Architecture artefacts and activities matrix
Below are captured the main activities to be performed when defining the high-level Logical
Architecture.
Let’s recall that the Capella tool automatically creates a Realization Link between each Logical element
(Function, Functional Exchange, Functional Chain) and the Source System element. Also recall that the
transitions are iterative and incremental and that noticed that a System Function is missing when
working on the Logical level, it must be absolutely added to the System level and apply the transition
again.
Step Matrix Diagram Output Step description
Step 1 PA1 CRB Capabilities Realization at Physical Architecture layer
Step 2
PA3
PFBD Define Physical Functions
Step 3 PDFB Define Physical Functional Exchanges
Step 4
PA4
PCBD Define behavioural and Physical Nodes
Step 5 PAB
Allocate Functions to Behavioural Nodes and deploy
Physical Nodes Components
Step 6 PA2
PFCD
FS
ES
Describe Capability Realizations with Functional
Chains and Scenarios
Table 3.1: Physical Architecture activities and artefacts
3.1. Capabilities Realization at Physical Architecture
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

5. 5
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.
Figure 3.1: [CRB] Physical Capability Realization Blank
3.2. 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.

6. 6
Figure 3.2: [PFBD] Physical Functions Breakdown Diagram
3.3. 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.

7. 7
Figure 3.3: [PDFB] Logical Dataflow Blank
3.4. 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.
Figure 3.4: [PCBD] Physical Components Breakdown Diagram

8. 8
3.5. 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.
Figure 3.5: [PAB] Physical Architecture Blank

9. 9
3.6. 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.
Figure 3.6: Physical Functional Chain and Scenarios definition
3.7. 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.

10. 10
Figure 3.7: Physical Architecture traceability flow

11. 14
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.

12. 15
Bibliography
[1] H. Castro, “MBSE with Arcadia method step-by-step: Physical Architecture,” 2023. [Online].
Available: https://www.linkedin.com/pulse/mbse-arcadia-method-step-by-step-logical-
architecture-helder-castro/.