Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "Naming and Code Conventions for ALICE DCS (1st thoughts)"— Presentation transcript:

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

2 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 2 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

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

4 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 4 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.

5 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 5 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-2000-008) 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

6 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 6 Reference Documents JCOP framework sub-project guidelines and conventions (CERN-JCOP-2000-008) –http://itcobe.web.cern.ch/itcobe/Projects/Framework/Documentation/guidelinesDocument.pdf (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-2003-039 Definition of the ALICE Coordinate System and Basic Rules for Sub-detector Components Numbering ALICE-INT-2003-038 ALICE offline coding conventions - http://aliweb.cern.ch/offline/ ->Code Development -> Coding rules PVSS embedded documentation (Help)

7 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 7 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

8 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 8 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)

9 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 9 Sub-detector and Sub-system Codes Sub-detector and group codes are defined in ALICE-INT-2003-039 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

10 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 10 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

11 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 11 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

12 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 12 Additional Conventions Additional naming conventions (like for information datapoints, panels, variables etc.) are based on CERN-JCOP-2000-008 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

13 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 13 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

14 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 14 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

15 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 15 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\...

16 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 16 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

17 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 17 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

18 P. Chochula, 11 th DCS Workshop, Geneva, Sept 20, 2004 18 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


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

Similar presentations


Ads by Google