Naming Convention


Background

EPICS will supply the base elements, as `channels', for most of the named elements in the Subsystems Slow Controls part of Online that come from VxWorks on VME processors. Component objects (`Proxies') will be built from these, implemented as Unix processes for Online Detector Control. Diagnostic tools will access EPICS elements directly using Channel Access; standard ODC tools will access the Proxies using a different name space.

EPICS will also provide the mechanism foraccessing monitor values from the Dataflow ROC and ROM processors to the (dynamic) Dataflow proxies.

The restrictions of Channel Access itself will constrain the naming of the base elements. The bulk of the electronically derived quantities and software-process (much of upstream Dataflow) derived quantities will first be accessed from EPICS as base elements. The names will therefore show up on schematics, wire-lists, and as VxWorks symbols. These in turn will be reported out from one or more project databases containing a great variety of other related information.

The Component names will be used to store the collected data into the Conditions database and to retrieve setpoints from the Configuration database. Thus these names will appear extensively in analysis, setup, and calibration software.

Constraints

Channel Access and EPICS possess a flat namespace and a discovery protocol that require all integrated components have channel names that:

Desirable Items

Proposal

Each name will have the form:

<sub>:<area>:<type>:<dev>_<quant>_<serial>

where:

<sub>
is the subsystem, one of {DRC, EMC, DCH, SVT, IFR} see below for current list These are intended to be detector subsystems and other independent, logical, geographic or administrative entities. The acronyms/abbreviations should be official.
<area>
is the geographic or logical division needed to further localize and subdivide. Examples are {Sec01, Top, End, ...}
<type>
is the type of element, one of {HV, LV, ROM, Water, Rack, ...} These are things which are naturally `collected' by specialists, both within and across subsystems. The acronyms/abbreviations are not official, but should be obvious to all, and uniform.
<dev>
is the `device' itself, taken loosely. Possible candidates are {PS, Valve, Pump, Fan, GLink, ...}. When sharing of code and templates across subsystems is anticipated, names should be uniform.
<quant>
is used to distinguish different quantities (attributes) referring to the same device, such as {I, V, P, T, ...}. Abbreviations should follow standard physics/engineering practice for current, voltage, pressure, temperature, ...
<serial>
is the serial number to simply enumerate repeated elements.

Typically a component name will be precisely "<sub>:<area>:<type>", including the many devices which comprise it. This portion of the name should be the most carefully chosen.

Examples:

DRC:Sec_11:HV:PS_I_99 ... Component is DRC:Sec_11:HV
EMC:End:Gas:Pump_P_88 ... Component is EMC:End:Gas
IR2:Bay_22:Rack:Fan_S_77

Miscellaneous

Abbreviations

These are required to be 3 characters long.
Detector Subsystem Slow Controls:
DRC	DIRC
EMC	Electromagnetic Calorimeter
DCH	Drift Chamber
SVT	Silicon Vertext Tracker
IFR	Instrumented Flux Return
Online:
ODC	Online Detector Control
ODF	Online Data Flow
OEP	Online Event Processing
OPR	Online Prompt Reconstruction
ORC	Online Run Control
Other:
CEN	Central
MAG	Magnet
CRY	Cryogenics
TRG	Trigger
FCS	Fast Control System
SFT	Safety
PEP	PEP-II
RAD	Radiation
HER	High Energy Ring
PIN	PIN Diodes
This document original produced by
Steve Lewis far babar.