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
RCAMT-599
-
Populate methodology and confluence pages for top/down transition in case of existing child models
Finished
Goal | Traceability between parent model elements at the logical level and child model elements at the system level is established. |
---|---|
Requirements met by this process step | Not 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 | ContextThis 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 methodologyIt 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 team1 - 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:
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 team3 - 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 review | No 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) |
|
Uses outputs (Informed) | Engineers responsible for the model design and management |