Logical Architecture modelling steps and concepts and FREE mini-course

Contents:

Arcadia Logical Architecture FREE mini-course

The previous System Analysis layer 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 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.

Let’s recall that Capella 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.

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

Main activities:

  • Define high-level architectural drivers and build the component-based system structuring.
  • Define the behavioural principles.
  • Trade-off analysis and select best compromise architecture.

Logical Architecture artefacts and activities matrix

As mentioned in previous sections, the methodological activities presented in table below are derived from a reasoned choice and some steps and diagrams can be optional and defined in any order.

Logical Architecture step-by-step method and diagrams

Capabilities Realization at Logical Architecture

One of the first activities to perform when moving to the Logical Architecture is to carry on the work performed at the System level. Hence, transitions of the System Capabilities can be performed by Capella from the Activity Explorer. Create the diagram Contextual Realization Blank (CRB) and verify that all Logical 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 System Capabilities – Perform an Automated transition of the System Analysis Capabilities.

[CRB] Logical Capability Realization Blank

Define Logical Architecture Functions

When System Capabilities are transitioned, System Functions should also be transitioned and refined in new Logical Functions, refined functions can be grouped under related functionality (e.g., monitor or control functions group).

When modelling activities are performed in the model it is quite often for a modeler to add new functions in other diagrams, for example, Logical Architecture Blank (LAB) diagram. As a good modelling practice the Logical Functions Breakdown Diagram (LFBD) should be revisited and organized and defined functions involvement, if needed.

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

Activities:

  • Refine System Functions in new Logical Functions.
  • Identify containments (hierarchy) for new Logical Functions.
  • Verify the LFBD diagram is still correct and consistent when new functions are added during the logical architecture design.

Modelling tips:

  • Transition System Functions in new Logical Functions.
  • In the LFBD, change the transitioned system functions background to white, it will help to identify which functions were captured at system layer and transitioned to the logical layer.

In the figure below it can be seen that one System Function can be refined into several Logical Functions and new functions can be grouped (i.e., involved) in different functions grouping.

White functions refer to System Functions transitioned.

[LFBD] Logical Functions Breakdown Diagram

Define 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 Logical Component.

When a System Function is refined in new Logical child Functions, Functional Ports belonging to the System Functions should be delegated.

Create Logical Dataflow Blank (LDFB) that describes a Capability Realization with functions involved or an LDFB that involves all the Logical Functions. The creation of LDFB approach depends on the modeler and stakeholder needs. For example, a stakeholder needs to focus and analyse a specific aspect of the functions and remove from the diagram all other functions for simplicity.

Activities:

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

Modelling tips:

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

[LDFB] Logical Dataflow Blank

Define logical components

Logical structure can now be defined by identifying structural elements called Logical Components by forcing ourselves to exclude all technological consideration or implementation choice. As described in a section above, Logical Architecture is the first layer of the solution and should capture high-level architectural aspects excluding any technological aspects. Technological considerations will be considered at the Physical Architecture layer.

Decompose the System into Logical Components and identify parent – child components hierarchy relationship.

As a good modelling approach revisit the Logical Component Breakdown Diagram (LCBD) and ensure this diagram is still correct and consist of. That is, during modelling activities new Logical Components can be created in different diagrams (e.g., LAB diagram) and new Logical Components involvement may need to be verified for consistency.

Arcadia rule:

  • The notion of Subsystem does not exist in Arcadia. In System Analysis, it can only have a single model element called System. If the modeller wants to model Subsystems, there is the need to be on an internal: Logical or Physical Architecture level. If then there is the need to be able to then consider each Subsystem as a full member System with its own System Analysis, Logical then Physical Architecture, it must model each Subsystem in a specific Capella model. The ideal being to maintain coherency between the external Exchanges of the different Subsystems in the “global” model of the encompassing System; this is exactly what it can be achieved with the System to Subsystem Transition add-on.

Activities:

  • Identify and define logical components.
  • Identify logical components hierarchy (i.e., containments).

Modelling tips:

  • Logical components implement functions that work together to achieve a common goal within a component.
  • The important rule to comply with is to force ourselves to exclude all technological considerations or implementation choices.
  • The functional analysis performed at this stage should not be regarded as a simple refinement of the SA, but as the result of the system design in terms of its behaviours in response to this need.
  • Revisit the (LCBD) diagram to ensure correctness.

[LCBD] Logical Components Breakdown Diagram

Allocate Logical Functions to Logical Components

When logical functions and components have been identified and captured, functions can be allocated to the relevant component. To allocate functions to components a Logical Architecture Blank (LAB) diagram can be created and perform the task. As a reminder Arcadia and the approach described in this document do not impose any sequence of activities, hence, it can be created this diagram before others described above.

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

The LAB diagram allows to create Logical Component exchange between Logical Components that implements Functional Exchanges. That is, Logical Components is the means Logical Functions do have to communicate with other Logical Components.

Different LAB diagrams can be produced that reflect a stakeholder needs and expectations, focused in one aspect of the System-of-Interest (SoI) architecture or showing part of the Logical Architecture by showing only components exchanges by applying filters provided by the Capella tool.

Activities:

  • Allocate Logical Functions to Logical Components.
  • Define Components Exchange.
  • Allocate Function Ports to Component Exchange

Modelling tips:

  • Logical Function Ports of the same non-functional type (e.g., Electrical Power) should be allocated to the same Logical Component Port.
  • When components exchanges are defined, it can apply the filter: “Hide functions” to show in the diagram components exchanges only.

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

[LAB] Logical Architecture Blank

Describe Capability Realizations with Functional Chains and Scenarios

A Capability Realization can be described by Functional Chain and scenarios.

Functional Chains and scenarios that describe a Capability Realization can be identified and defined following a similar approach to the definition of System Functional Chains and scenarios at System layer.

Activities:

  • Identify functions involved in a functional chain that describes 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 Logical Functions were refined at logical architecture and Functional Chains might have turned as invalid.

Logical Functional Chain and Scenarios definition

Logical Architecture traceability flow

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

  • A Logical Capability Realization can be described by Functional/Entity Scenarios and/or Functional Chains.
  • A Functional/Entity Scenario and Functional Chains involve Logical Functions.
  • Logical Functions are allocated to Logical 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.

Logical Architecture model elements traceability and diagrams relationship