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.136 Push back chosen physical architecture from child models to parent model

Page in draft, need to be reviewed and approved, feedback welcomed (smile)

Requirements met by this process step
  • Elsa Lamblin [X]  related to rcamt-160 : need to highlight dependency/impacted steps and deliverables about this push back and its inherent manual activities

RCAMT-160 - REQ: Define patterns, methodology and modelling rules for NFRs / ARCH Define the methodology for modelling non-functional attributes Paused

Inputs

for each child model:

  • AMOD-xx1 RCA child models
  • AMOD-xx2 non-RCA child models

Inputs required are the following : 

  • AMOD-093
  • AMOD-100
  • AMOD-143
  • AMOD-085
  • AMOD-140
  • AMOD-095 (tbc)
  • AMOD-096 (tbc)
OutputsAMOD-xxx DBS global Physical Architecture (tbc)
Methodology

Execute the scoped horizontal extraction from both child models (RCA and non-RCA) to the parent model DBS. 

It will consist mainly of a copy-paste of all physical elements from submodels to the root model. 

(warning) Caution: The traceability from DBS logical architecture to those physical elements will not be done at this step. 

It would be done : 

1) manually in the ARCH.169 and ARCH.168 steps, for short term

2) semi-automatically in middle/long term thanks to script developed later.

But manual check steps will be always executed after this phase.

(warning) Caution: After the transition, several physical elements will be redundant and need to be merged and cleaned (see detailed in ARCH.168 Consolidate the overall reference architecture)

Tools and non-human resources

Team for Capella

System-to-System Capella plugin

Cardinality

One child model for RCA project, one child model for non-RCA scope, for one root DBS model

Completion criteriaAll the physical architecture of both child models (RCA and non-RCA) has been imported into the root DBS model.
Design review

The Engineer should check if the scope is well imported to the root model from each submodel, which means : 

  • Physical actors, nodes physical components, physical links, and physical ports
  • Deployed behavior physical components, components exchanges, flow ports
  • Physical functions, functional exchanges
  • Physical functional chains 
  • Physical external actors, physical external actors exchanges
Step done by (Responsible)Engineer
Provides input to/assists (Contributes)Engineers responsible for each child models
Uses outputs (Informed)