Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.M.060 Method for the execution of automatic transition in capella
RCAMT-649
-
03_2022_02 execute automatic transition method/how to run automatic transition and the needed model elements
Finished
1. Summary
The capella tool uses model layers to separate concerns so that the engineering process can be carried out in stages. However, there is a fairly strict separation in the model between elements at each layer. Generally, it is not possible to use elements from one layer of the model in any other layer (exception for data modeling).
3.1. Context and transition types
In ARCH.911 Identify the system's contribution to the operational needs, the sets of potential elements that should be included at system level are identified (set of potentials system capabilities, set of potentials system actors, etc.). According to these analyses, some elements of the operational layer will be transited into the system layer and a link between them will be created.
Each operational level model element that shall be transferred as a corresponding element to system level may be transitioned automatically from operational level to system level in Capella.
3.1.1. Operational capabilities transition
For each considered operational capability: create capability or mission on system layer.
3.1.2. Operational entities/actors transition
For each considered entity/actor: create system actor on system layer.
3.1.3. Operational activities transition
For each considered activity: create function or capability on system layer.
Important note
All model elements, including system capabilities, system functions, and actor functions, which were either transferred or created in this process step, must be provided with appropriate traceability links to the operational level (either immediately or when it is available). This is done automatically in the case of transition (Realization Links), but must be done manually in the case of system level model elements created by means other than a transition. In such a case, ensure that each system level model element has a traceability link to its original operational level counterpart (it is called "Outgoing Generic Traces" in Capella).
3.2. Overview of the transition
Hint
The transferred or created system level model elements shall be allocated to the appropriate output viewpoints
3.3. Overall summary of necessary element transitions
Operational Analysis Element | System Analysis Element | Remarks |
---|---|---|
Operational Entity | System Actor | |
Operational Actor | System Actor | |
Operational Activity | Function or System Capability | |
Operational Interaction | Functional Exchange | |
Operational Capability | System Capability or System Mission |
4.1. Context and transition types
The "system needs" have been modelled in the system layer of Capella. To work on these needs and break them down for logical viewpoints, the first stage is to transit those needs at logical level. These will then be decomposed in later activities. During consolidation, the copies will be removed, and direct traceability will be established between decomposed logical architecture elements and the system analysis elements they realise.
4.1.1. System analysis capabilities transition
For each considered capability: create capability realisation on logical layer.
4.1.2. System actors transition
For each considered actor: create logical actor on logical layer.
4.1.3. Functional chain transition or system functions transition
For each considered functional chain: create functional chain (and functions) on logical layer. But for users who are more familiar with the "System Functions transition", it can be used in addition to the "Functional Chain transition" to check that all functions have been transited.
Not all model elements have to be decomposed. Some elements might not need to be further decomposed.
Important note
Where elements already exist at logical level (e.g. due to previous transitions), care must be taken to ensure that the element is to be overwritten. It may be the case that a certain transition (e.g. system functional chain) results in the transition of more than just the element under consideration (e.g. accompanying system functions). If an element already exists on logical level it may be more appropriate to create a trace from the logical element to the corresponding system element. Before carrying out automatic transition downwards, first check that there is nothing appropriate at logical level that can be directly traced (via the "Realised <element type>" property of a logical model element). Manual generic traces should be documented with their rationale (to explain why the trace is valid (necessary and sufficient). Wherever this is done, ensure that any associated property values of a higher-level element are brought down to the lower-level element.
4.2. Overview of the transition
4.3. Overall summary of necessary element transitions
System Analysis Element | Logical Architecture Element | Remarks |
---|---|---|
System Actor | Logical Actor | |
Function allocated to the system | Function allocated to the logical system | |
Function allocated to actors | Function allocated to logical actors | |
Component Exchange between the system and actors | Component Exchange between the logical system and logical actors | |
Functional Exchange | Functional Exchange | |
Physical Link between the system and actors | Physical Link between the system and actors | |
System Capability | Capability Realisation | |
Mode/State allocated to the system | Mode/State allocated to the logical system | |
Mode/State allocated to the actors | Mode/State allocated to the logical actors | |
Functional Chain | Logical Functional Chain | (only system functional chain description with risk control measures) |
5.1. Context and transition types
For the set of capabilities currently being considered, initiate the automatic transition of the logical capability realisations to physical capability realisations, including their inter-relationships.
5.1.1. Capability transition
For each considered capability: create capability on physical layer with pre and postcondition and link it to the physical system.
5.1.2. LC/LA to PC/PA transition
For each Logical Component (LC) and each Logical Actor (LA) including the allocated functions: creates Physical Components (PC) and Physical Actors (PA) as well as their parts (component ports and component exchanges).
Important note
Where elements already exist at physical level, it may be more appropriate to create a trace from the physical element to the corresponding logical element. Before carrying out automatic transition downwards, first check that there is nothing appropriate at physical level that can be directly traced (via the "Realised <element type>" property of a physical model element). Manual generic traces should be documented with their rationale (to explain why the trace is valid (necessary and sufficient). Wherever this is done, ensure that any associated property values of a higher-level element are brought down to the lower-level element.
5.2. Overview of the transition
Hint
After transition, several viewpoints should be created on physical level in order to cross-check the completeness of the transition: PAB (components), PAB (subsystems), PDFB, PFCD. If something is missing, the respective transition step needs to be repeated with the missing content
5.3. Overall summary of necessary element transitions
Logical Architecture Element | Physical Architecture Element | Remarks |
---|---|---|
Logical Actor | Physical Actor | |
Logical Component | ||
Function allocated to a logical component | ||
Function allocated to logical actors | Function allocated to physical actors | |
Functional Exchange | Functional Exchange | |
Component Exchange between logical components | ||
Component Exchange between a logical component and actors | ||
Delegation link between a logical component and actors | ||
Physical link between the system and actors | Physical link between the system and actors | |
Capability Realization | Physical Capability Realisation |
In the Parent Model, linked to
6.1. Context and transition types in the parent model
6.1.1. Context
This step is related to the system of systems approach whose overall methodology is described here: Method page for SoS Approach with more guidance and definition of terms. There are two distinct cases where a child model can be linked to a parent model. In this case, we need to create a new child model where the logical component selected as a constituent system will be the new system of interest.

6.1.2. System to SubSystem Transition (Vertical Transition LA level → SA level)
For the logical component under consideration, initiate the automatic vertical transition to a separated child model (see 1.3- "System-to-Subsystems" Capella plugin presentation & first tests). The logical component under consideration will be the system of interest of this child model. This transition will take into account all the inter and intra relationships with other elements:
- Allocation relationship: if a function or a logical component is allocated to the logical component under consideration, they will be transited;
- Involvement: if a capability, a functional chain or a scenario is involving the logical component under consideration, they will be transited;
- Interrelationship: if a logical component or a logical actor has a relationship with the logical component under consideration, they will be transited as external actors;
- Data information: if a data modeling element has a relationship with a functional exchange of a function allocated to the logical component under consideration, it will be transited.
Additional info
In case of modification of the parent model, it would be necessary to update the content of the child model. This transition step should be redone and the updated contents added to the child models.
Important note
The traceability between parent and child models is possible thanks to an automatic relationship between the SID of the child model elements and the ID of the parent model elements.
More information about traceability between models here: Method page for SoS Approach
6.2. Overview of the transition
Hint
If something is missing, the respective transition step needs to be repeated with the missing content.
6.3. Overall summary of necessary element transitions
Global type | Parent Model Element | Possible Layer | Child Model Element | Remarks |
---|---|---|---|---|
Component/ Actor | Component selected | LA | System | It is the SoI of the child model |
Sub-component | System | They are merged into the system | ||
Component | Actor | |||
Actor | Actor | |||
Function | Function allocated to the selected component | Function allocated to the system | ||
Function allocated to a sub-component of the selected component | Function allocated to the system | |||
Function allocated to other components | Function allocated to actors | |||
Function allocated to actors | Function allocated to actors | |||
Component Exchange | Component Exchange between the Component selected and actors | Component Exchange between the system and actors | ||
Component Exchange between the Component selected and Components | Component Exchange between the system and actors | |||
Component Exchange between the Sub-component and Actors/Components | Component Exchange between the system and actors | |||
Delegation between the Component selected and actors | No transited, loss of information from the exchange | |||
Delegation between the Sub-component and Actors/Components | Component Exchange between the system and actors | |||
Physical Link | No direct link with the selected component → no transited Physical links can only be between the system and the actors, not components (at logical level) | |||
Functional Exchange | Functional Exchange | If functional exchanges are allocated to component exchanges, they keep this allocation | ||
Capability realization | Capability which contains functional chains or scenario involving the selected component (or elements allocated to the selected component) | System Capability | Which will contains functional chains/scenario transited | |
Abstract concepts | SA, LA | No direct link with the selected component → no transited | ||
Data Objects | Data Objects used as type for transited Exchange Item Elements | Data Objects associated to the type of Exchange Item Elements | ||
Data Objects don't used as type for transited Exchange Item Elements | No direct link with the selected component → no transited | |||
Exchange Item Elements | Exchange Item Elements used in transited Exchange Item | Exchange Item Elements associated to Exchange Item | ||
Exchange Item Elements don't used in transited Exchange Item | No direct link with the selected component → no transited | |||
Exchange Item | Exchange Item used in transited Functional Exchange | Exchange Item associated to the functional exchange | ||
Exchange Item don't used in transited Functional Exchange | No direct link with the selected component → no transited | |||
Change Event | Not transited because it used ID property to constraint data elements. And the ID is specific to a model | |||
Scenario | Elements created in a scenario involving the selected component (or elements allocated to the selected component) | LA | Elements created in a scenario | |
Functional Chain | Elements created in a functional chain involving the selected component (or elements allocated to the selected component) | Elements created in a functional chain |
6.4. Actions in the child model
The other transition processes (OA-> SA, SA→LA, etc.) take place from the lower level and retrieve elements from the higher levels (e.g. the SA->LA transition takes place at the logical level and retrieves elements from the system level). But unlike these processes, the vertical transition between the parent and child models takes place at the top level: the process is performed at the logic layer to provide system layer elements on the child model.
This is why, in the child model, it must be checked that all necessary elements have been transitioned between models. After the transition, several viewpoints should be created on the system level of the child model in order to cross-check the completeness of the transition: SAB, SDFB, SFCD. Need also to check the traceability with the parent model.