Copyright DB Netz AG, licensed under CC-BY SA 3.0 DE (see full text in CC-BY-SA-3.0-DE)
ARCH.127 Define location kinds
RCAMT-589
-
Finalise ARCH.127 Define location kinds and including method documentation in Confluence
Finished
RCAMT-654
-
ARCH.12x Define Installation Space Envelop for Tenderable Element Deployment
Finished
Goal | Define a taxonomy of the location kinds where a subsystem might be partially or fully deployed and associate location kinds with the applicable standards. |
---|---|
Requirements met by this process step | Environment-specific requirements |
Inputs | List of standards relevant to environmental conditions for:
Method for definition of location kinds and environmental space options |
Outputs | AMOD-095 Location kind definitions |
Methodology | General information Standards are sources of constraints for the location kinds. It is therefore essential for a specification model that the applicable standards are identified and unambiguously referenced in the model e.g. including release date, revision number etc. A detailed, model-based representation of their content is however out of scope. Compliance to standards is to be evidenced by supplier product certifications, test protocols etc. Tasks
Note: Whole subsystems can not always deployed to location kinds, because some subsystem boundaries will enclose collections of objects that are mounted in different location kinds. The intention of defining location kinds was to develop a standard set of constraints that apply to each location kind, that can then be given to suppliers as a library of contextual info. For example, the localisation system might mount sensors on the axle-box, but we don't deploy the whole system to the axle-box location kind because it almost certainly will also have equipment mounted inside the car-body. The location kinds are used to tell the supplier "IF you want to mount part of your subsystem on the axle-box THEN that part must meet these constraints". |
Tools and non-human resources | Team for Capella |
Cardinality | Once with iterations permitted |
Completion criteria | All intended location kinds are defined |
Design review | ARCH.R.8 Subsystem review - consolidated |
Step done by (Responsible) | COMP/CON architect |
Provides input to/assists (Contributes) |
|
Uses outputs (Informed) | None. |