Legal information

Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)

Method for definition of logical components

RCAMT-678 - Extend ARCH for refinement of system interfaces at logical level Finished

1.1. 1.1. Overview

A logical component is a conceptual structural element (or part) of a system or subsystem. It does not exist in the reality and has no physical properties. Logical components are part of the solution design of a system and therefore provide an abstract solution to the system needs. Typically they are only focusing on the business logic. Furthermore they provide a modularisation and encapulsation of a set of functionality as services to other logical components. The set of logical components is designed and then arranged logically in the logical architecture of the system. However logical architectures do not consider technical constraints, physical realisation or implementation strategies which allows that multiple physical architectures based on one logical architecture can be defined.

1.2. 1.2. Characteristics

The purpose of a logical component is that it provides an aggregation of logical functions that together fulfil a very specific task. They are in general agnostic of how often they will be instantiated in a logical architecture of the system or subsystem and are not constrained by a specific technology or implementation (e.g. whether if it is realised by SW, HW or both in a subsystem which will host them). This includes also that they are independent of which location kind it will be deployed (inside the train, on the trains undercarriage, at the track, in data centre etc.) and do not have any physical properties or requirements (like space requirements, permitted temperature ranges, etc.). It is sometimes helpful to imagine the scope of a logical components when thinking what it could represent later (e.g. a piece software or hardware). Example: If a logical component is an abstract sensor this is an abstraction of a corresponding physical component for e.g. an optical sensor or contact sensor. 

The following definitions of a logical components are provided by ARCADIA:

Definition from the book "Model-based System and Architecture Engineering with the Arcadia Method, ISTE Press Ltd 2018"

Behavioural component: A behavioural component is a system component, responsible for carrying out some of the functions devolved to the system, by interacting with its other behavioural components and external actors. (p. 310)

Logical component: The system is broken down into principle components called logical components. The term “component” is understood here in the general sense, as a constituent of the system at this level; it can later be implemented as a subsystem (or several), equipment, one or more mechanical parts or assemblies, one or more electronic cards, a software program itself eventually distributed or even a human contributor. (p. 99) A logical component is a system component described at a conceptual level (in principle, abstract) in logical architecture. A logical component has all the properties of a behavioural component, except it is not hosted by a host component. (p. 312)

The logical level of the architecture is concerned with abstract partitioning of functionality and not with practical considerations such as the geographical location of a component, network bandwidth, power supply, packaging of hardware, etc. Each logical component represents a kind of a micro service necessary inside the system. The interfaces between logical components are only symbolic and do not expose behaviour for interfacing in the sense of physical interfaces and physical properties. Logical components need to be aggregated to physical layer subsystems to be able to fill these gaps. Logical components are then deployed and aggregated to physical layer subsystems.

1.3. 1.3. Definition of logical components

When functions are split at logical level for purpose of defining logical components, we can only do this on the basis of some logical or abstract splitting principle. This process step should be carried out together with ARCH.M.010 Method for definition of functionality. After all possible splitting principles have been identified, the set of candidate logical components can be thought of as an n-dimensional vector space where each dimension corresponds to one logical splitting principle. Based on the maximum set of splitting principles, these principles are grouped in a meaningful way, such that a manoeuvrable number of logical components are defined. These then produce several versions of logical architectures, i.e. the candidates of logical architectures. Potentially then there are hundreds of candidate logical components.

It is important to recognise that

  • not every single one of these candidates will actually be needed
  • there is not a 1:1 mapping between these logical components and subsystems; rather, one subsystem will host many logical components;
  • candidate logical components should only be created in the model where there exists at least one logical function with the corresponding values of splitting principle.
  • define a rationale for each logical component to justify why the logical component is needed

1.3.1. 1.3.1. Definition of candidates with two splitting principles

Then the set of candidate logical components is then a 2-dimensional vector space containing 10 possible combinations of values (that is, a 2 x 5 matrix):

The functions are then split up along the lines of the splitting principles and assign the functions to the appropriate logical component. If we find that there are no functions that meet a particular combination of splitting principles then we can conclude that the corresponding logical component is not needed in the system (or that there is missing a system function or a system function not split up correctly).

1.3.2. 1.3.2. Definition of candidates with three splitting principles

In this approach three splitting principles are taken under consideration:

  • Splitting principle 1: system function category (control, actuate, indicate, sense, observe, plant)
  • Splitting principle 2: operated object / abstract concepts (Point machine, Usage Restriction Area, Movement Permission)
  • Splitting principle 3: Abstraction layers (Plan implementation; Safety control; Object aggregation/abstraction; Device abstraction; Device control)

In total there are 6 x n x 5 (that is, 30n) possible combinations of values, where n is the number of operated objects defined.

Further details for the splitting principles are provided in Method for decomposition of functions.

1.3.3. 1.3.3. Definition of candidates with specific principles

There can be splitting principles for project-specific functions as shown below. In total there are 5 x 5 x n x 3 x 2 (that is, 150n) possible combinations of values, where n is the number of operated objects defined. Potentially then there are hundreds of candidate logical components. It is important to recognise that not every single one of these candidates will actually be needed and there is not a 1:1 mapping between these logical components and subsystems; rather, one subsystem will host many logical components. The logical components proposed are tabulated below with the corresponding splitting principle values alongside. Note that although there are five dimensions that in theory could yield huge numbers of combinations, in practice it quickly becomes clear that not all the possible combinations are used, and therefore the number of logical components is kept to a manageable level whilst providing a precise breakdown of the system on a logical level.

Note that at this point if there is only one function per logical component and this seems wrong it is allowed for other functions to be added to the logical components later. This is valid when the function shares the same set of splitting principle values. This means there should never be two or more logical components that have the same combination of splitting principle values; each logical component should have a unique combination of values.

DPS Plan ExecutorControlPlan executionPoint (as DPS)
DPS Driveability ControllerControlSafety controlPoint (as DPS)
Point State ControllerControlDevice abstractionPoint
Point Actuator ControllerControlDevice controlPoint
URA Plan ExecutorControlPlan executionURA
URA State ControllerControlSafety controlURA
Point Position ObserverObserveDevice controlPoint
DPS Driveability ObserverObserveDevice abstractionPoint (as DPS)
DPS Group Availability ControllerControlSafety controlPoint (as DPS group)

1.4. 1.4. Allocation of logical functions to logical components

1.4.1. 1.4.1. Top-down approach

After completion of the decomposition of the system functions there exist then a set of leaf-level logical functions. These logical functions can be allocated to different logical components. After completion of the definition of the logical components there then exist a set of defined logical components, which do not have allocated logical functions yet. The following steps are performed to allocate logical functions to logical components.

  1. Allocate logical functions to logical components

    • Get a logical component and allocate all leaf-level logical functions which are relevant for this logical component.
    • At the end of this activity, each leaf-level functions concerned with the achievement of the current realised capability should be allocated to one logical component.

    • Where there exists a design choice as to which logical component should do a particular function, two leaf-level functions should be created, and allocate it to the respective component. The design choice for a subsystem is then made by evaluating subsystem boundary options against architectural trade-off criteria.
    • Define a rationale to justify why a function is allocated to a logical component (only if it is otherwise not clear how you came to that decision).
  2. Identify superfluous logical components
    • Logical components without any allocated logical function shall obtain rationale why logical functions cannot be allocated.
    • Another iteration of decomposition of system functionality / definition of logical components is required in order to delete the superfluous logical component or to create missing logical functions for allocation
  3. Identify missing logical components
    • Logical functions that cannot be allocated to a logical component shall obtain a rationale that describes the logical function as an orphan function
    • Another iteration of decomposition of system functionality / definition of logical components is required in order to remove the superfluous logical function or to create a new logical component for allocation
  4. Identify duplicate logical functions
    • When there are different logical functions that describe the same functionality a merge of similar logical functions should be considered
  5. Logical component is consolidated when:
    • At least one logical function is allocated to it, which provides an unique functionality.
    • The allocated logical function realises at least one system function.
    • The logical component has a comprehensive description, which includes rationales for each decision made, further provides information and reasoning about dismissed but possible alternative logical components.

1.4.2. 1.4.2. Bottom-up approach

If there are existing already logical functions allocated to logical components. These allocations should be validated during the parallel activities in for decomposition of system functionality.

1.4.3. 1.4.3. Interfacing functions

On logical architecture, there is no need to break down interfacing functions according to system interface and the abstraction of its layers (application, session, etc.). This is done later in the subsystem (physical) layer. However the more abstract interfacing functions for externally constrained interfaces of the system must be already allocated to specific logical components. This allocation is a special case because it do not comply with the splitting principles. As for the system level, it is possible to have several interfaces with the same actor. In this situation, all interfacing functions of a system are allocated to the corresponding logical component of each interface