Legal information

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

  Draft

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. Operational analysis to system analysis 


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 ElementSystem Analysis ElementRemarks
Operational EntitySystem Actor
Operational ActorSystem Actor
Operational ActivityFunction or System Capability 
Operational InteractionFunctional Exchange
Operational CapabilitySystem Capability or System Mission


4. System analysis to logical architecture


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 ElementLogical Architecture ElementRemarks
System ActorLogical Actor
Function allocated to the systemFunction allocated to the logical system
Function allocated to actorsFunction allocated to logical actors
Component Exchange between the system and actorsComponent Exchange between the logical system and logical actors
Functional ExchangeFunctional Exchange
Physical Link between the system and actorsPhysical Link between the system and actors
System CapabilityCapability Realisation
Mode/State allocated to the systemMode/State allocated to the logical system
Mode/State allocated to the actorsMode/State allocated to the logical actors
Functional ChainLogical Functional Chain(only system functional chain description with risk control measures)


5. Logical architecture to physical architecture


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 ElementPhysical Architecture ElementRemarks
Logical ActorPhysical Actor
Logical Component

Function allocated to a logical component

Function allocated to logical actorsFunction allocated to physical actors
Functional ExchangeFunctional 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 actorsPhysical link between the system and actors
Capability RealizationPhysical Capability Realisation


6. Vertical transition between LA layer of parent model and SA layer of new child models


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 typeParent Model ElementPossible LayerChild Model ElementRemarks
Component/ ActorComponent selectedLA


SystemIt is the SoI of the child model
Sub-componentSystemThey are merged into the system
ComponentActor
ActorActor
FunctionFunction allocated to the selected componentFunction allocated to the system
Function allocated to a sub-component of the selected componentFunction allocated to the system
Function allocated to other componentsFunction allocated to actors
Function allocated to actorsFunction allocated to actors
Component ExchangeComponent Exchange between the Component selected and actorsComponent Exchange between the system and actors
Component Exchange between the Component selected and ComponentsComponent Exchange between the system and actors
Component Exchange between the Sub-component and Actors/ComponentsComponent 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/ComponentsComponent 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 ExchangeFunctional ExchangeIf functional exchanges are allocated to component exchanges, they keep this allocation
Capability realizationCapability 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 conceptsSA, LA
No direct link with the selected component → no transited
Data ObjectsData Objects used as type for transited Exchange Item ElementsData 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 ElementsExchange Item Elements used in transited Exchange ItemExchange 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 ItemExchange Item used in transited Functional ExchangeExchange 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
ScenarioElements created in a scenario involving the selected component (or elements allocated to the selected component)LA

Elements created in a scenario
Functional ChainElements 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.