DOC

EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH

By Tom Knight,2014-03-26 18:14
12 views 0
The document is based on the PVSSII and JCOP Framework (IT-CO) documentation [2],[3]. Framework operational panels ? these are panels that are standard

    EUROPEAN ORGANIZATION FOR NUCLEAR RESEARCH

    European Laboratory for Particle Physics

     Internal Note/DCS

    ALICE reference number

     ALICE-INT-2005-0XX version 1.0

    Institute reference number

     [-]

    Date of last change

     2005-03-02

    Guidelines and Conventions for

    ALICE PVSSII Control Software

    Authors:

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

    Abstract:

    This document gives the guidelines and conventions for developers and end users of the

    ALICE control software, using PVSSII. It covers the selected tools, naming and

    numbering conventions, project organization and guidelines for graphical user interfaces.

    ALICE-INT-2005-0XX v1.0

    02/03/2005 1 Introduction ............................................................................................... 3 1.1 Selected tools and standards ............................................................ 3 1.2 Organization ...................................................................................... 3 2 Naming and numbering guidelines ........................................................... 4 2.1 General naming and numbering conventions .................................... 4 3 Guidelines for PVSSII projects and Framework use ................................. 4 3.1 General .............................................................................................. 4

    3.1.1 PVSSII project name .................................................................. 5

    3.1.2 PVSSII system name and number .............................................. 5

    3.1.3 Use of the Framework ................................................................ 6

    3.1.4 OPC and DIM servers ................................................................ 6 3.2 Development ..................................................................................... 7

    3.2.1 DataPoints and DataPointTypes ................................................. 7

    3.2.2 Panels ........................................................................................ 8

    3.2.3 Path and subfolders .................................................................... 8

    3.2.4 Libraries and control scripts ........................................................ 8

    3.2.5 Project integration ....................................................................... 9 4 Finite State Machines ............................................................................. 10 4.1 Guidelines for the Finite State Machine use .................................... 10 5 Graphical User Interfaces ....................................................................... 10 5.1 General guidelines ........................................................................... 11 5.2 FSM Operational Panels .................................................................. 11 Appendix A..................................................................................................... 13 Appendix B..................................................................................................... 15 Appendix C .................................................................................................... 16

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    1 Introduction

    ALICE has the largest number of sub-detectors of the four LHC experiments. Therefore, to ensure homogeneity and in view of the integration, maintenance and exploitation of the control system, guidelines and procedures are established for building and organizing the control applications and their graphical user interfaces.

    The strategy of the ALICE Controls Coordination (ACC) is to use the JCOP Framework software tools (possibly extended with ALICE specific add-ons), wherever this is possible. For all cases not covered by this Framework, the control applications shall be developed according with the present document and the Framework guidelines. A more detailed description of the ALICE DCS architecture can be found in the Technical Design Report [1]. This document is aimed not only at the developer of control applications (likely

    to develop applications in PVSSII), but also at the end-user of the control

    system (that configures a control system using only the standard tools). All control applications should be developed and tested using the current ACC recommended version of PVSSII, Framework and operating system. The 1,2current recommended version can be found on the ALICE DCS web pages.

    Any existing application should be upgraded to run with the recommended versions and checked for compatibility with the guidelines in this document. The document is based on the PVSSII and JCOP Framework (IT-CO) documentation [2],[3]. It is in our common understanding that an ALICE DCS developer shall have followed the PVSSII and Framework training course [4]. 1.1 Selected tools and standards

    The following tools and standards have been selected and shall be used in the ALICE control system:

    ; Control applications shall run on PCs with the Windows operating system. The Linux

    operating system can be used in exceptional cases, only after consultation with the ACC. ; The selected SCADA (Supervisory Control and Data Acquisition) system is PVSSII. This

    tool is used by the four LHC experiments and several CERN services.

    ; Wherever possible, to develop the controls applications, the JCOP Framework (possibly

    with ALICE specific extensions) shall be used. This tool hides most of the complexity of

    PVSSII to the end-user.

    ; The controls hierarchy and Finite State Machine behaviour shall be implemented with the

    FSM toolkit integrated in PVSSII and available with the JCOP Framework (SMI++).

    Any deviation from the above standards shall be discussed with the ACC. 1.2 Organization

    In order to facilitate the coordination of the highly parallel and distributed development of the ALICE control system, some basic organizational rules apply:

     1 http://www.cern.ch/AliceDCS/ 2 Recommended version at writing of the document: PVSSII version 3.0.1 with all patches installed; Framework version 2.3.1; Windows XP, SP2 installed with firewall disabled.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    ; The ACC provides guidelines and support for all future development and integration. ; Every sub-detector shall nominate a person responsible for the control software

    (development and future maintenance) and communicate this to the ACC. By default this

    is the control contact person for the sub-detector.

    ; The sub-detector responsible shall ensure the portability and functionality of the control

    software and ensures that the applications adhere to the present guidelines. ; Sub-detector naming as well as all PVSSII systems names, number and domains must be

    documented and made available to the ACC team.

    ; The ACC will ensure the naming integrity between different sub-detector systems. ; Already assigned names and applied standards (e.g.: PVSSII, Framework, ACC naming)

    shall not be altered by sub-detectors.

    ; Any control application, prior to installation in the production environment, shall be

    validated on a reference set-up.

2 Naming and numbering guidelines

    2.1 General naming and numbering conventions

    The following general conventions for naming and numbering apply:

    34; interCapNotation shall be used for code development. 5; Abbreviations are considered as single words.

    ; Wherever sub-detector identification is needed, only the standard three-letter sub-

    detector code shall be used (defined in [5]).

    ; Wherever „geographical‟ identification is needed, the standard naming, numbering (and

    „numbering direction‟) and coordinate system shall be used (defined in [6]).

    ; Names shall be meaningful.

    ; Numbering starts at 0.

More detailed and specific conventions are given below.

    3 Guidelines for PVSSII projects and Framework use Any SCADA based control application, using the framework or not, has to be a PVSSII system in a PVSSII project. A general rule is to have one system per project.

    The next, general, section covers guidelines for both developers of control applications and users that only use standard tools such as the framework to configure their control system (end-users). The second, development, section covers guidelines for developers, developing their control application in PVSSII.

    3.1 General

    This section is aimed at both developer and end-user.

     3 The interCapNotation writes a name, 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 name starts with a small letter. 4 E.g. variable and routine names in scripts, filenames for scripts, panels etc. 5 hv (for high voltage) should be considered as a single word, thus (in interCapNotation) myHvChannel and not myHVChannel.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    3.1.1 PVSSII project name

    The PVSSII project name is the name of the project given at the creation time. It is strongly recommended to have the same name as the system name. The name should be meaningful.

    When defining a new project the language should be defined to be US English (en_US.iso88591).

    Every project should be created as distributed system [3] to ease future integration. It is strongly recommended to have one PVSSII project system per detector.

    The PVSS II project name should follow the following convention: where dc; is the Detector Code as defined in [5] and dcs is the

    abbreviation from Detector Control System

    Example: tpc_dcs, phs_dcs, sdd_dcs…

    3.1.2 PVSSII system name and number

    Principle and functionality:

    “Each system in a distributed system has to have a unique system name and a unique system number” (PVSSII help)

    The PVSSII system name is assigned at the project creation time, see Figure 1.

    Figure 1: Creation panel for a distributed system

    The following naming rules apply:

    ; The system name shall be in lowercase; underscore “_” shall be used to separate words.

    ; The system name shall start with the standard three-letter sub-detector code followed by

    the underscore character “_“.

    ; The system name should intuitively describe its function or the sub-system it controls

    wherever possible.

    ; System names must be documented by sub-detector groups and made available to ACC

    team prior its installation in the production environment.

    ; ACC will provide the PVSSII system number per sub-detector following a written request

    (see Appendix B) to alice.dcs@cern.ch.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    The detector must very carefully choose the system name. It can be changed later, using the PVSStoolsynctypes function (to be used with care as you

    might change the system name of other projects).

    3.1.3 Use of the Framework

    A control system using standard hardware can conveniently be set-up by using the framework. The Device Editor and Navigator (DEN) allow you to populate your control system with devices.

    3.1.4 OPC and DIM servers

    OPC servers

    The symbolic name for the OPC server should have a detector identification. When a symbolic name of the OPC server is given, a datapoint of type _OPCServer is created. To avoid creation of the datapoints with the same name the following naming scheme should be applied:

     where opcsn;OPC Server Name and dc; Detector Code. As

    tpc_opcwiener in the example in Figure 2.

    Figure 2: Creation of the OPC DP

DIM servers

    The similar naming rule as for OPC servers shall be followed: where dimsn;DIM Server Name and dc; Detector Code

OPC and Dim driver numbers

    Some PVSSII OPC and Simulator driver numbers are reserved by the Framework:

    CAEN PVSSopc num 6 PVSSsim num 6

    Wiener PVSSopc num 11 PVSSsim num 11

    ELMB PVSSopc num 7 PVSSsim num 7

    DIP PVSSopc num 13 PVSSsim num 13

    Iseg PVSSopc num 8 PVSSsim num 8

    Table 1: Reserved driver numbers

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    If there is a need to have another OPC client of the hardware mentioned before, running on the same PVSS system the ACC must be contacted first. The ACC team will assign a new number.

    For any new hardware integrated in the ALICE DCS control, the ACC team will assign the OPC and Dim driver numbers, following a written request. An electronic form will be soon available on the Alice DCS web page 3.2 Development

    This section is aimed at the developer that needs to add functionality that is not covered by the framework.

    Before starting important developments it is recommended to contact the ACC and discuss your requirements. Some of your requirements might already be covered in some way, or be under development. On the other hand your requirements might be of interest also to others and justify a coordinated approach.

    3.2.1 DataPoints and DataPointTypes

    Under no circumstances the DataPoint (DP) and DataPointType (DPT) names for PVSSII and Framework shall be changed.

    Any new hardware added in the ALICE Control System shall follow the framework and ALICE development guidelines. It is highly recommended to use the framework panels for adding a device (i.e. use of the panel fwDevice/fwDeviceCreate.pnl and related panels) [2],[3]. They should reflect exactly the hardware OPC items or DIM item names. They should not start with any of the reserved characters (ex: -; _; %; #; etc…).

    The general syntax is:

    [systemName:]dpName.[dpElement(s)]:config.[detail].attribute

     systemName: name of the PVSS system

     dpName: name of the data point

     dpElement: element name of the DP type

     config: attribute group

     detail: detail number of the attribute group

     attribute: real value of an attribute

    There are certain reserved characters and words in PVSSII and in the framework. To avoid confusion or worse, these should not be (re-)used for other purposes.

    DPT (Data Point Type) shall follow the following naming convention. where dc ; Detector Code, ss ; Sub-System Name as defined in

    Appendix A. DPT names should start with a capital letter, and always start with the prefix.

    Ex: , , etc…

    DP (Data Points) should begin with a small letter.

    InterCapNotation can be used, but not for PVSS system name.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    3.2.2 Panels

    Wherever possible, PVSSII and framework reference panels shall be used. If new panels are developed they shall adhere to the guidelines and must be well documented. Online help shall be made available for each panel in the standard format.

    3.2.3 Path and subfolders

    For new hardware integration the folder structure shall be the following (see for example Figure 3):

    .../newHardwareName/config

    Shall contain the specific hw config file: server name and driver number

    (OPC or DIM) and the specific control libraries.

    …/newHardwareName/dplist

    Shall contain the ascii file of datapoints and datapointtypes.

    It is recommended to save the DataPoint / DataPointTypes and the

    Driver type in separate files (e.g. newHardwareNameDPT.dpl and

    newHardwareNameDriver.dpl).

    …/newHardwareName/panels

    Shall have a subfolder having the name of the developed hardware (e.g.

    newHardwarename).

    …/newHardwareName/scripts

    Shall have the subfolder “libs”. In this subfolder the specific libraries will

    reside (e.g. newHardwareName.ctl); see also next section.

     Figure 3: Directory structure

    3.2.4 Libraries and control scripts

    Generally it is recommended to use as much as possible the Framework developed ones. All libraries and control scripts, hardware oriented or FSM control unit oriented, should have a meaningful names. InterCapNotation use is strongly recommended.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    They should be well documented either in the header of the library, or as a separate text file. Also it should keep the PVSSII folders structure of a project. 3.2.5 Project integration

    To ease the integration of projects developed independently in separate PVSSII systems into a single PVSSII system, the sub-detector responsible must make sure that all the points described in [3], chapter 7 (Guidelines for

    integration) are respected.

    In case the developer would like his application to be handled as a framework component (e.g. after having developed a new device) the solution will be the use of the Framework panel fwInstallation_DescCreator.pnl (see Figure 4).

     Figure 4: fwInstallation_DescCreator.pnl being used in the packing of

    newHardwareName project.

    ALICE-INT-2005-0XX v1.0

    02/03/2005

    4 Finite State Machines

    Finite State Machines (FSM) are considered to be the key tool to implement the operational behaviour of the detector control system. This is described in more detail in the TDR [1].

    For standard sub-systems, such as high voltage, low voltage, standard state diagrams are proposed and shall be used. In case they do not fit your requirements you should contact the ACC to see if your requirements can be incorporated in the standard.

    For other sub-systems and the overall sub-detector behaviour, guidelines or templates will be provided in a separate document.

    Any application with FSM behaviour shall be implemented using the FSM toolkit (based on SMI++) integrated in PVSSII and available with the JCOP Framework (fwFSM).

    4.1 Guidelines for the Finite State Machine use

    When developing finite state machines with the FSM toolkit, the following guidelines should be followed:

    ; States, actions, alarms shall follow the rules described in [4][7][8]. ; Names of states and actions shall in uppercase and words can be separated by and

    underscore “_” (e.g. GO_PHYSICS).

    ; All sub-detectors should provide written documentation that describes in detail the state

    diagram of their sub-detector, operation, action, and alarms….

    ; Partitioning will be performed using the FSM tools in conjunction with the ECS partitioning

    tools

5 Graphical User Interfaces

    Graphical User Interfaces (GUI), or “panels” in PVSSII terminology, are the

    only way for the user to interact with the control system. Different classes of panels can be identified:

    ; Operational panels these are panels to allow the operation of a sub-detector (or a

    collection of sub-detectors) or a sub-system by a non-detector expert. These are typically

    the panels a shifter would use to perform standard operations on the system. These

    panels are the ones that are expected to be available in the ALICE control room. The

    operation is performed through interaction (displaying states and giving commands) with

    the FSM. A non-expert operator is not expected to change individual parameters in the

    system.

    ; Framework operational panels these are panels that are standard provided with the

    framework to operate a device, whenever a device is added to the control system. These

    panels are expected to be available to sub-detector experts, as they allow access to

    individual parameters. The use of these panels will probably only limited, e.g. during

    commissioning or debugging.

    ; Sub-detector specific panels these are panels sub-detectors will develop for their

    specific use. These are dedicated panels for operations specific to their sub-detector, and

    expected to be used only by sub-detector experts. These panels might or might not have

    access to the FSMs.

    Clearly the access to each panel is controlled by an access mechanism, which is currently being designed.

Report this document

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