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.113 Trace elements between parent model and an already existing child model

  Draft

RCAMT-599 - Populate methodology and confluence pages for top/down transition in case of existing child models Finished

GoalTraceability between parent model elements at the logical level and child model elements at the system level is established.
Requirements met by this process stepNot defined
Inputs

All relevant model elements on the logical level of the parent model

All relevant model elements on the system level of the child model

01-Method page for System of Systems approach

Test - AMOD-150 Agreed baseline of dependencies between models

Outputs

AMOD-149 Record of elements between models

Test - AMOD-150 Agreed baseline of dependencies between models (updated if necessary)

Methodology

Context

This step is related to the system of systems approach whose overall methodology is described here: 01-Method page for System of Systems 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 consider that a part of the parent system (a logical component) is already developed in another model and is the system of interest in the system layer of this model. In order to manage the relationship between the systems and between the models, we need to ensure traceability between model elements.

Overview of the methodology

It is mainly a communication step of already existing information between two models. The model development teams will communicate through a common document called AMOD-149 Record of elements between models, which will be completed during different stages. The figure shows the key stages for each team and the interactions with the document. Each step of the process will be described in detail below.

Actions carried out by the parent model team

1 - At the logical layer of the parent model, identify which logical component is already involved as the system of interest of an existing child model. Concomitantly check the registration of the child model in Test - AMOD-150 Agreed baseline of dependencies between models, if it is not registered, the file must be updated.

2 - Inform the child model owner that there is a need to trace the system elements of its model to the logical elements of the parent model.

4 - Collect information from AMOD-149 Record of elements between models to check correspondence with relevant model elements of the logical architecture. Thanks to the Capstan rules it is easy to identify the type of the element in the array:

    • The nomenclature is almost unique
    • The pattern for the element’s description provides information on the nature of the element

For each child model element, express the mapping with a parent model element by filling in the "ID/SID", "name" and "description" columns of the parent side in AMOD-149. Notify the child model owner when the information is ready to be used.

Guidance: use the mass editing view of Capella and show only the "ID", "name" and "description" columns, then export the information in the corresponding columns.

Actions carried out by the child model team

3 - At the system layer of the child model, gather all the elements that need to be traced (check the 01-Method page for System of Systems approach to find the list of required trace types). For each child model element, fulfil information corresponding to the "name" and "description" columns of the child side in AMOD-149. Be careful, for the identification of flows (functional exchanges, component exchanges) there is a need to add more context: fulfil manually the upstream and downstream of each flow. Notify the parent model owner when the information is ready to be used.

Guidance: use the mass editing view of Capella and show only the name and description columns, then export the information in the corresponding columns.

5 - After the reception of the information, the SID property of each system element should be fulfilled with the information expressed in the ID columns of the parent side in AMOD-149.

Guidance: use the mass editing view of Capella and show only the "SID" and "name" columns of the system elements. Then, fulfil directly the empty cell of the SID property with the information from the ID columns of the parent side.



Note 1: it can appear some issues with the mapping (e.g. a relevant parent model element can have no corresponding child model element, the child model element can have no relevant parent model element, etc.). In this case, the child model owner and the parent model owner should have a concrete meeting to discuss these issues.

Note 2: to perform this activity, the logical architecture of the parent model should be finalised and the system analysis of the existing child model should be finalised too

Tools and non-human resources

Confluence-based templates & scripts for presenting AMOD-149

Team for Capella

Cardinality

At least once per logical component considered as a constituent system and linked to an already existing child model.

More if there is a modification of the logical component involved in the parent model.

Completion criteria

Each system-level element from the child model possesses a SID property in relation to the ID of a logical-level element from the parent model.

Design reviewNo design review checks this since it is an intermediate step, but the work should be coordinated and checked by the cross-cutting engineer especially to check if the scope is well derived for each child model
Step done by (Responsible)

Cross-cutting engineer/Lead system architect

Provides input to/assists (Contributes)
  • Engineer
  • Cross-cutting engineer
  • Subsystem Architect
Uses outputs (Informed)

Engineers responsible for the model design and management