next up previous
Next: Calibration Up: Hardware Configuration Previous: Hardware Configuration

Naming Conventions

In OKS, and other OO databases, objects must have a unique identifier. In OKS this identifier is a string. We will need a convention for naming each object (of the same class) uniquely. In particular, modules in the same slot in different crates need different identifiers. So a scheme which combines crate and module identifiers is required.


Although we have a proposed labelling scheme [4], this is not particularly suitable for crates. So for the purposes of the database, the following is suggested instead.


Crate identifiers could use the two or three character subsystem string, with a single digit suffix for the crate number within the subsystem. Eg pp0 to pp7, cp0 to cp3, jep0 to jep1, rod0 for the ROD crate(s) and ttc for the TTC crate.


Module identifiers could then be of the form ccc-mmmnn, where ccc is the above crate identifier, mmm is the standard three character module number (maybe using cprod and pprod instead of crd and prd?) and nn is the logical number of that kind of module within the crate. Examples might be pp2-ppm11, pp3-pprod1, cp0-cpm5, jep1-jem15, cp3-cmm1, pp5-tcm, rod0-cprod4. Although these are rather long, some modules appear in more than one subsystem, so either the full subsystem name must appear, or the crates must be numbered eg tt 0-14 across subsystems which is not very memorable.


If subcomponents of modules are eventually entered into the configuration database (ie as opposed to HDMC parts files) then the above convention will need extending, presumably adding -sssnn for subcomponent type (sss) and number (nn).


next up previous
Next: Calibration Up: Hardware Configuration Previous: Hardware Configuration
M.P.J.Landon 2003-05-15