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.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

GoalDefine 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 stepEnvironment-specific requirements
Inputs

List of standards relevant to environmental conditions for:

  • on-board railway equipment
  • track-side infrastructure
  • Data centres

Method for definition of location kinds and environmental space options

OutputsAMOD-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

  1. Identify the relevant international standards related to environmental conditions for railway and data centre equipment deployment and operation.
  2. Identify and model a taxonomy of candidate location kinds for the deployment of railway signalling, control, communication and computing equipment.
  3. Categorise all standards related to environmental conditions which are applicable to the candidate location kinds.
  4. Potentially extract additional requirements related to points within a standard that need to be further clarified, restricted e.g. completing issues left open in the standard.
  5. Allocate each of the identified Requirements out of the standards to one or more location kinds at the highest applicable level in the taxonomy. Allocation to a leaf location is also possible depending on the level of applicability.


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 reviewARCH.R.8 Subsystem review - consolidated
Step done by (Responsible)

COMP/CON architect

Provides input to/assists (Contributes)
  • COMP/CON Engineer
  • Subsystems architect
  • Lead System architect
Uses outputs (Informed)

None.