Naming and Code Conventions for ALICE DCS (1st thoughts)

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Need for coding convention is evident, most people will now start developments and will face this problem soon. In fact, this talk has been motivated by user requests System management requires a well defined naming strategy for application installation paths etc. Purpose of this talk is to stimulate discussion – please do not hesitate to interrupt and raise your questions

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Conventions to be discussed cover following topics: –Naming rules for PVSS developments –Rules for software installation, directories naming and standard paths

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Basic Rules DCS team does not intent to provide an exhaustive list of conventions. Motivation for proposed rules is to avoid clashes while integrating sub-detector systems Organization of sub-detector specific code remains the responsibility of sub-detector groups.

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Basic Rules Related to PVSS Projects PVSS standards are adopted –Please read embedded PVSS help for reference Proposed rules are based on : –JCOP framework sub-project guidelines and conventions (CERN-JCOP ) Only minor changes of this document (in prefix assignment) are needed for ALICE On following slides we will summarize some of the recommended rules and their adaptation for ALICE

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Reference Documents JCOP framework sub-project guidelines and conventions (CERN-JCOP ) – (Framework) Naming and Look-and-Feel conventions –htt://pvssjcopfw-training.web.cern.ch/pvssjcopfw- training/Handouts/JCOPFrameworkGuidelinesDraft6NamingandLook-and-FeelConventions.pdf Naming and Numbering Convention for the ALICE Detector Part Identification – Generic Scheme – ALICE-INT Definition of the ALICE Coordinate System and Basic Rules for Sub-detector Components Numbering ALICE-INT ALICE offline coding conventions - ->Code Development -> Coding rules PVSS embedded documentation (Help)

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, General Naming Conventions interCapNotation is used Start of each word in Composed names starts with capital letter. All names start with small letter (with exception of DPT names) Due to PVSS limitations, datapoint types were required to be unique while putting several PVSS systems together. The new PVSS version has overcome this limit, so the rules can be less restrictive –As a consequence, policy for assigning prefixes is “relaxed” and we can adopt a convenient scheme based on detector names

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, ALICE PVSS System Names and Domain Prefix Each domain has an allocated prefix. For general ALICE systems this has been set to : “ali_”. Sub-detectors use their own prefix (example: tpc_, spd_ …) Prefix is followed by the controlled sub-system name (lv, hv, fero …). If a system is in charge with several subsystems (e.g. joining lv and hv together), the sub-system name is skipped Full systemName must be meaningful, it is assigned by system responsible person and must be unique within the domain Example: spd_lvControl stands for a controls system responsible for low-voltage in pixel detector Note: sub-detector abbreviations are written in lower case (spd, tpc) – with exception of datapoint types Note: interCapNotation is valid also for sub-system abbreviations (e.g. Hv, Lv, Fero)

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Sub-detector and Sub-system Codes Sub-detector and group codes are defined in ALICE-INT DCS sub-system codes are defined as follows: Sub-systemCode Low-voltagelv High-voltagehv Coolingcooling Gasgas Front-end and readout electronics fero Detectors which implement additional systems (e.g. laser, calibration etc.) will provide their list and propose a convenient code. ALICE DCS team will assure, that the codes are homogenous across ALICE

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Datapoints and Datapoint Types The system name is used as a part of datapoint name: [systemName:]dpName.[dpElement]:config.[detail].attribute systemName is unique for each PVSS system and is essential for integration of several PVSS systems. It can be passed as a $-parameter to general panels Datapoint names start always with small letter (see next slide for an example), sub-detector code is used as a prefix Names of datapoint types always start with capital letter, both in prefix and name

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Example of Datapoint and Datapoint Types Naming Let’s illustrate the principle on two examples: Datapoint Type: Spd_HvChannelStatus Datapoint name: spd_hvChannelStatus Full datapoint name (including the system) spd_hvControlSystem:spd_hvChannelStatus

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Additional Conventions Additional naming conventions (like for information datapoints, panels, variables etc.) are based on CERN-JCOP and are following the rules explained in previous slides Conventions for naming of FED server commands and services are under discussion with groups involved in their implementation and will be made publicly available Please communicate your remarks/wishes to DCS team

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Rules for Software Installation There are three main reasons for standardizing the software paths: –Seamless installation procedures require well defined targets which must not differ between computers –If an expert is asked to debug a part of the software, he wants to find system components in standard paths –Moving projects between computers is simple task only if standard programs are installed in standard places For example, if framework software is installed in different place, one has to modify the project config file as well while moving the project to another system

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Standard Naming for File Paths We assume that each DCS computer will contain at least two disk partitions (could be on the same disk) Disk drive letters assigned to these partitions are “C:” and “D:”, while C: is reserved for boot partition. (in MS terminology boot partition stores the operating system, system partition is the one which is bootable…) Drive letter assignment for network disks will be defined later Note: use of external or removable media (USB disks, USB sticks) will be restricted on DCS network for security reasons

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Standard Directories for Windows Based Systems Operating system: C:\Windows PVSS C:\Programs\PVSS JCOP framework: C:\Programs\Framework Additional software (OPC servers, etc.) C:\Programs\productName Windows specific software : C:\Program Files\...

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, There will be one and only version of PVSS system as well as of JCOP framework software installed The person responsible for DCS computing will define and maintain the production version of PVSS and JCOP framework to be used in ALICE

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, PVSS Project Paths on Windows- based Systems PVSS project path D:\PVSS_Projects\ProjectName PVSS project-related backup path D:\PVSS_Backups\ProjectName –Note: the backup path will be revised after final release of ORACLE archiving

P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, Conclusions, what will happen next? The discussed list is far from being complete Please discuss it with your software designers and send your comments to the DCS team DCS team will collect the requirements and propose a definitive convention –This will be an extension of reference documents (see slide 6) We propose a time period of 3 weeks for your replies and additional period of 3 weeks for discussion before we freeze the definitions