DOC

EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH

By Lee Andrews,2014-03-26 15:11
9 views 0
The imposed naming convention does NOT apply to JCOP framework software. The naming used in framework ssd, ITS SSD, emc, EMCAL. tpc, TPC, tri, Trigger

EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH

    European Laboratory for Particle Physics

    Internal Note/DCS

    ALICE reference number

    ALICE-INT-2006-006

     EDMS Id 742954

    Version 1.3.2

    Date of last change

    2006-November-24

    The ALICE DCS Integration Guidelines

    Authors:

    A. Augustinus, P. Chochula, G. De Cataldo, L. Jirdén, P.Rosinsky,

    S.Kapusta, M. Boccioli, S. B. Sellitto

    Abstract:

    The purpose of this document is to provide guidelines for integrating the detector controls

    projects into the ALICE DCS.

    Contact: Peter.Chochula@cern.ch

    ............................................................................................................................... ......... 1

     1. Introduction.................................................................................................... 4

     2. Existing Rules and Guidelines....................................................................... 4

     3. Naming Conventions...................................................................................... 5

     3.1. Composing the ‘prefix” and the “ObjName”................................................ 6

     3.2. Naming of Datapoint names, Datapoint type names, ................................ 9

     3.3. OPC Servers, DIM servers, DIM Commands and Services....................... 9

     3.4. Naming of FSM objects............................................................................ 10

     3.5. Naming of Systems and Projects, panels and scripts.............................. 11

     3.6. Project paths, standard software directories............................................ 11

     3.7. The naming scheme for network-attached devices.................................. 11

     4. ALICE Nomenclature................................................................................... 13

     5. The numbering scheme............................................................................... 14

     6. Software versions........................................................................................ 15

     7. DCS Access Control.................................................................................... 15

     7.1. DCS Access Control implementation....................................................... 17

Update History

    V 1.3.2 2006-12-05

    Clarification on scope of DP and DPT naming addedAccess control chapter rewritten

    V 1.3.1 2006-10-26

    V 1.3 2006-10-26

    Chapter on access control extended, more clear guidelines added

    V 1.2 2006-08-23

    Example edited in FSM section

    Abbreviations for Siemens and Schneider correctedRemoved old markup

    V 1.1 2006-07-1

    Chapter on access control added

    V 1.0 2006-06-12

    Chapter 2 rewritten

    V 1.0 2006-06-07

    Naming convention merged with Integration guidelines and registered in EDMS

    Added example for DIM and OPC server nameAdded generic name for FSM hierarchy, states and commandNomenclature moved to separate chapter

    Numbering scheme moved to separate chapterAdded chapter on standard directories: 3.6 Added chapter on SW version

1.Introduction

    This document provides rules and guidelines for integration of detector-specific PVSSII projects with the ALICE DCS. It should be considered as a quick-start handbook for creating the PVSSII projects.

    Rules and conventions mentioned in this guideline are defined in a detailed way in the documents referenced below (see Chapter 2).. For convenience we picked-up some important topics and provided them in a 1condensed way. In case of questions, please contact the ALICE DCS team.

    2.Existing Rules and Guidelines

    The ALICE DCS adopts the rules and guidelines defined by CERN and JCOP wherever possible. Full up-to date list of reference documents is available at ALICE DCS web pages [1]. Please check these pages frequently as many documents are still evolving.

    Rules for project development are based on JCOP definitions which can be found in following documents:

    JCOP Framework Sub-project Guidelines and Conventions 7.1

    Naming and Look-and-Feel Conventions 7.1

    The ALICE DCS naming convention extends the JCOP definitions and provides ALICE-specific guidelines and it is explained in Chapter 3 of this document. The components used to create the DCS name must follow the ALICE conventions as defined in:

    Definition of the ALICE Coordinate System and basic rules for Sub-

    Detector Components numbering 7.1

    Naming and Numbering Convention for ALICE detector part

    identification - Generic Scheme 7.1

    As explained in Chapter 3 the sub-detector specific prefix plays key role in the ALICE DCS naming scheme. It assures uniqueness of the names within the ALICE DCS distributed system. The codes which shall be used for prefix are defined the document 7.1 and are collected for convenience in Table 1. The DCS-specific codes are listed in Table 2. If a definition of new code is needed, the proposal should be sent to the ACC team for approval.

    The configuration and control of the front-end and readout electronics (FERO) is an ALICE-specific problem and is not covered by JCOP 1 Send mail to alice.dcs@cern.ch. Please use this address whenever you need to contact the ACC team.

    developments. The FERO monitoring and control is implemented using the FrontEnd Device [FED] concept. A brief description of the FERO access in ALICE is given in following documents:

    FERO Configuration in Alice 7.1

    Control and Monitoring of the Front-End Electronics in ALICE 7.1

    FED Server API 7.1

    All DCS devices are configured from common DCS database. Data produced by the DCS is written to the DCS Archive. The interface to offline conditions database (OCDB) is implemented as the “shuttle” service, data to HLT is provided by the “pendolino” service. Basic principles of data flow in the ALICE DCS are described in:

    Alice DCS Databases 7.1

    The top-level user interface of the ALICE DCS is based on FSM tools. Detailed description of the sub-detector integration into the global ALICE DCS is described in:

    ALICE DCS FSM Guidelines 7.1

    The setup and operation of DCS computing facilities is the responsibility of the ACC. The DCS network is conforming to the CNIC rules:

    CNIC policy document: Design, Setup and Operation of the

    CERN Control System Environment 7.1

    This document explains the architectural details of the controls network and the rules for its use. It assumes that all users are familiar with CERN policies for using the computing facilities:

    CERN Computing Rules - Operational circular No 5 7.1

    Alice provides specific extension to these rules. In particular rules for installing the detector specific software and remote access to the controls system are explained in more detail in:

    DCS Computing Rules 7.1

    3.Naming Conventions

    A uniform naming convention should be used in detector projects. To avoid clashes with other software in the global DCS distributed system, all objects (system names, project names, datapoint names, etc.) must be unique. This will be achieved by using the detector specific prefix in each name. The detectors are responsible for assuring the naming homogeneity within their projects.

    The imposed naming convention does NOT apply to JCOP framework software. The naming used in framework tools shall not be modified.

    The naming convention applies to all DCS objects which should be named and shall be of the form:

    prefix_objName

    where “prefix” is a unique detector specific prefix assigned by the ACC based 2on the official ALICE naming convention [REF].

    The “ObjName” is a meaningful name describing the object following

    the rules described later in paragraph 3.1. The “ObjName” is assigned by detector groups.

    This naming convention is mandatory for system names, project

    names, OPC server names, DIM server names, DIM services, datapoint

    names and datapoint type names. It is strongly recommended for, script

    names, panel names etc.

    3.1.Composing the ‘prefix” and the “ObjName”

    The prefix is typically composed of three letter detector code. The exception is naming of FED targets [ref to FED API] where the server layer (FED or FEE) is specified in addition. The detector codes are defined in [REF], for convenience we are listing the commonly used codes in Table 1.

    To improve the readability, we use a code “agd” which stands for Alice Generic Detector in this document.

    The InterCap notation should be used to separate words within the 3ObjName, if this is composed of several words. Alternatively the underscore

    character “_” could be used to separate words within the ObjName. The InterCap notation remains the preferred one.

    In general all names used in ALICE DCS are written in small letters. For this purpose the prefix is treated as a single word, so the capitalization affects only its first character (example “Agd” but not “AGD”). If InterCap notation is used, the first letter of the composed word is written in lower case (Example: agd_seuRegisterSettings but not agd_SeuRegisterSettings). The only exception are the names used in the FSM, as described in paragraph 3.4.

    The name should be intuitive and should be chosen to best describe the named object. It could also describe the geographical location of the given object; in this case it will follow the detector-specific naming convention. 2 See also Table 1 3 The interCapNotation writes a ObjName, which is comprised of multiple words, as a single word in which the start of each new word is written with a capital letter and all the rest of the word in small letters.

    The sub-system names and abbreviations shown in Table 1 shall be

    used. Definition of new sub-system names in ALICE must be approved by the

    ACC.

    Table 1: Sub-detector and system codes used in ALICE

    CodeSub-detectorCodeSub-detector

    or systemor systemspdITS SPDmtrMuon triggersddITS SDDzdcZDC

    ssdITS SSDemcEMCAL

    tpcTPCtriTrigger

    trdTRDhltHLT

    tofTOFdaqCentral DAQphsPHOSdcsDCS

    cpvCPVfraFront absorberhmpHMPIDsaaSmall angle

    abs.

    fmdFMDsfrSpace framepmdPMDl3mL3 magnetv00V0dimDipole magnett00T0bmpBeam pipemchMuon trackerexhExperimental

    hall

    intIntegrationotrOther(not

    classif.)

    Table 2: Subsystem names used in ALICE DCS

    Sub-System nameAbbreviation

    Low Voltagelv

    High Voltagehv

    Very High Voltagevhv

    Crate Controlcra

    Environmentenv

    Coolingcoo

    Gasgas

    Front-end and ReadOut fero

    Electronics

    Calibrationcal

    Laserlas

    Alignmentaln

    Gas Purity (HMP)gap

    Radiator Transparency rat

    (HMP)

    Radiation Monitorram

    Rack Controlrco

    Parameters in the sub-systems should be named uniformly, following

    the definitions shown in Table 3. The name of the controlled or monitored

    parameter (voltage, current etc.) shall be followed by a suffix indicating the

    parameter use, as defined in Table 4.

    Table 3 Abbreviations for controlled or monitored parameters

    Physical quantityAbbreviation

    Voltagev

    Currenti

    Temperaturet

    Pressurep

    Flowf

    Humidityrh

    Table 4 Parameter name suffixes

    Parameter typeAbbreviation

    Monitored valuemon

    Setpoint valueset

    Trip valuetrip

    Error limit (Hi, errHi, errLo,

    Low, Boolean)err

    This leads to parameter names such as vMon or tMon for a monitored value,

    tErrHi for the upper error limit on a temperature reading etc.

    3.2.Naming of Datapoint names, Datapoint type

    names,

    Datapoints and Datapoint types are named according to the above

    described scheme:

    prefix_objName

    where “prefix” is composed of three letter detector code as defined in [REF].

    The “prefix: is written in small letters. The exceptions are the datapoint types (DPT), where the first letter of the prefix is capitalized.

    The “ObjName” is written in small letters. The exceptions are letters capitalized due to the InerCap notation.

    Examples:

    Datapoint Type: Agd_hvChannel or Spd_hv_channel

    Datapoint Name:agd_hvChannel or spd_hv_channel

    DP name with geographical information: agd_hvSect1Mod2

    3.3.OPC Servers, DIM servers, DIM Commands

    and Services

    Names of the DIM and OPC servers follow the same convention as defined in paragraph 3.2 and are written in a form

    prefix_objName

    where “prefix” is composed of three letter detector code and objName is a name describing the server functionality in an intuitive way. InterCap notation is used for writing the server name. It is recommended that the ObjName starts with “opc” or “dim” to determine the server type.

    Examples: agd_opcWiener, agd_dimFed

    The DIM commands and service names must be unique across the DCS. It is not possible to register a service or command which is already used by another server – if such situation appears, the DIM server will refuse to start. To avoid clashes, the DIM nameservers will be installed per detector and each DIM server will register its services and commands in the dedicated nameserver. If information produced by one DIM server is needed by another sub-detector, this will be transferred via datapoints linked to the corresponding DIM service. The commands can be issued only from the PVSS system belonging to the same detector as the DIM server.

    The naming of DIM commands and services follows the naming convention for datapoints. For commands, the prefix can be ommited. The services should always contain the detector name in the prefix. The name of the service should follow the InterCap notation or use underscore to separate the words.

    The FED Servers and FEE Servers are a special class of DIM servers used in ALICE. They follow the general naming scheme for DIM servers. The convention for describing the command targets is defined in the FED API document [Ref.]

    3.4.Naming of FSM objects

    The FSM states and commands are written in uppercase, the prefix is omitted.

    The detector hierarchy used in the definition of both FSM view and

    Logical view is described in upper case. The names given to detector components must be unique. For consistency, the name of each component

    has to be the same in the FSM view and in the Logical view. The name of the

    sub-detector hierarchical component must start with the three letter detector code, the rest of the name follows the detector naming scheme. The DCS sub-system name, as defined in Table 2, indicates the referenced domain.

    Because the InterCap notation cannot be used, underscore is used to separate the words in the names of FSM states, commands and hierarchy components and shall be of the form:

    PREFIX_HIERARCHY_COMPONENT

    COMMAND_NAME

    STATE_NAME

    Example (Detector Oriented Hierarchy):

    AGD_SIDEA_SECTOR3_MODULE1_LV

    AGD_SIDEA_SECTOR3_MODULE1_LV_CHANNEL5

    Example (device Oriented Hierarchy):

    AGD_LV_SIDEA_SECTOR3_MODULE1

    The FSM library also allows to associate a label to each hierarchy

    component name. The FSM control button may show up to 25 characters.

    Hence, it may be convenient to associate to the component also a more

    condensed name. This is possible using the label Error: Reference source not

    found.

    The list of FSM commands and states for the top-most layer of the FSM

    hierarchy, as agreed in ALICE, is available in [REF –GDC and Marco]

Report this document

For any questions or suggestions please email
cust-service@docsford.com