1 / 16

Guidelines for ALICE PVSS II Control Software Naming and Numbering Conventions

This document outlines the guidelines and conventions for naming and numbering in the ALICE PVSS II control software. It specifies standards for graphical user interfaces (GUIs), operational controls, and subsystem identification, including the use of interCap Notation and underscores. Mandatory requirements for control software development, validation in the DCS lab, and responsibilities of sub-detector teams are detailed. Additionally, it discusses integration with hardware, naming standards for data points, server names, and panel designs, ensuring consistency and clarity across the project.

limei
Télécharger la présentation

Guidelines for ALICE PVSS II Control Software Naming and Numbering Conventions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Guidelines and conventions for ALICE PVSSII control software Graphical User Interface Naming and Numbering conventions Project organization Alice DCS workshop, Utrecht S.Popescu

  2. Selected tools and standards- news (1) • Control applications  run on Windows XP Operating System • Linux Operating System  approval from the ACC team is mandatory. • PVSS II shall be use as the SCADA system • Framework tools shall be used for any development of control applications • Finite State Machineshall be used for the full control hierarchy in Alice • Sub-detector operation (states, actions, transitions..)  performed via the FSM mechanism • Except TPC and HMPID no reaction from detector side  so good agreements with these rules Alice DCS workshop, Utrecht S.Popescu

  3. Who is doing what? - updates • ACC team will ensure the support for all future tools developments (Fw, PVSS.. ) (alice.dcs@cern.ch) • Every sub-detector shall nominate a person responsible or the control software (development and maintenance) and communicate this to the ACC team – no answer • Sub-detector responsible must ensure that the control software follow the guidelines, its integration and functionality - no answer • Any control software prior to the final installation shall be validated in the DCS lab with a reference system, therefore a time schedule is need it from the sub-detector responsible - no answer Alice DCS workshop, Utrecht S.Popescu

  4. General naming rules • Two standards are valid: • interCapNotation • name splitting using underscore. • Abbreviations are considered as single words. • Sub-detector identification  mandatory the standard three-letter sub-detector code shall be used (as defined in Appendix C of the document). • Numbering starts at 0. Alice DCS workshop, Utrecht S.Popescu

  5. Codes for other systems or objects: Sub-detector codes: Alice DCS workshop, Utrecht S.Popescu

  6. Guidelines and conventions – 1 • PVSS project name • project in US English language(PVSSen_US.iso88591) • every project shall be created as distributed system • naming convention for the detector top level* <dc_dcs> Ex: tpc_dcs, phs_dcs, sdd_dcs dc  Detector Code dcs abbreviation  Detector Control System *It is recommended to have one PVSSII project per detector i.e. with small number of channels (hv, lv, cooling, fero) • PVSS System name and number • Names shall be in lowercase, underscore “_” shall be used to separate words. • Naming convention is <dc_..> ex: tpc_dcs, phs_dcs • should intuitively describe its function and be documented by sub-detector responsible • PVSSII system number per sub-detector is assigned by ACC team following a written request. • electronic form available on the Alice DCS web page Alice DCS workshop, Utrecht S.Popescu

  7. Guidelines and conventions – 2 • OPC and DIM servers • The same naming formula • <dc_opcsn>  where opcsn = opc server name, • <dc_dimsn>  where dimsn = dim server name, Ex: tpc_opcwiener tpc_dimfero • OPC driver numbers • Framework PVSS OPC + Simulator driver numbers are reserved • CAEN 6, Wiener 11, Iseg 8and 9, ELMB 7, • For any new hardware integrated in the ALICE DCS control , the OPC and Dim driver numbers will be assigned by the ACC team, following a written request. • DIM driver numbers • will follow the same policy as OPC Alice DCS workshop, Utrecht S.Popescu

  8. Guidelines and Conventions - 3 • Panels • Look and feel • Will be displayed on screens with at least resolution of 1024 x 768 pixels. • Font to be used is: “Arial regular 10”; the background colour to be used is: “_3DFace” (more conventions in the FW guidelines) • Naming of sub-systems and parameters shall be as the ones listed (see Appendix A of the document). • Child panels shall be cascaded and have a close button at the bottom right corner. • ALICE logo shall appear at the top left corner. • help button located at the top right corner, and give access to the online help. • online help shall be provided in the standard format • Naming convention • Same as the general convention , <dc_..> followed by a meaningful abbreviation: ex: tpc_TrendingSectorA.pnl Alice DCS workshop, Utrecht S.Popescu

  9. Guidelines and Conventions – 4 • Panels • Path and subfolders • For new hardware integration the folder structure shall be ..newHardwareName/config – contains the config file ..newHardwareName/dplist -- contains dpfileDataPoint / DataPointTypes ex: newHardwareDP.dpl, newHardwareNameDPT.dpl ..newHardwareName/panels – contains the corresponding panels ..newHardwareName/scripts Alice DCS workshop, Utrecht S.Popescu

  10. Guidelines and Conventions – 5 • Development • DataPointsTypes and DataPoints Naming scheme • PVSS II and Framework DP and DPT shall not be changed • For new hardware added the DP should be exactly the OPC or DIM items names from the Space Name Server • The prefix (detector code) is mandatory . For DPT first letter must be upper case for DP should be smaller case • The general naming scheme could be <dc_ss...>, where ss  is the Sub-System name Example:Tpc_hv_anode forDPT, tpc_hvAnodeSect1forDP • If detector need to split the name “underscore” as separation shall be used . Ex: tpc_hv_anode Alice DCS workshop, Utrecht S.Popescu

  11. Guidelines and Conventions – 6 • Development • Libraries and control scripts • Wherever applicable is recommended to use the Framework ones • Must have meaningful name • interCapNotation use is strongly recommended • Must be documented in the header file or as a separate text file in English. • Any upgrades or bug fixes made must contain the developer name, date and a short description of the change(s). Alice DCS workshop, Utrecht S.Popescu

  12. Guidelines and Conventions – 7 • Development • FSM objects • States, actions, alarms shall follow the rules defined by PVSS, Framework and Giacinto’s presentation. • Naming convention for: states and actions is uppercase • words can be separated by and underscore “_” (e.g. GO_PHYSICS). • All sub-detectors must provide written documentation on state diagram of their sub-detector, operation, action, alarms…. • Partitioning will be performed using the FSM tools in conjunction with the ECS partitioning tools Alice DCS workshop, Utrecht S.Popescu

  13. Guidelines and Conventions – 7 • FSM operational panels • FSM toolkit shall be used  a default layout is provided fwUi.pnl • Two zone –control zone and monitoring zone • Control zone must contain all the CU need it for operation • Monitoring zone can be used as the detector wants • It is recommended to fill this zone with complementary information for the operator ex: state diagram of the CU, some crucial parameters • ACC will soon provide some standard widgets Alice DCS workshop, Utrecht S.Popescu

  14. Still under development!! Disregard the inconsistencies, it is shown as a working principle!! Alice DCS workshop, Utrecht S.Popescu

  15. Conclusions • The document can be found http://alicedcs.web.cern.ch/AliceDCS/Documents/ “Guidelines and conventions for ALICE PVSSII control software “ • Still to come… • ACC will come soon with a proposed architecture for the FSM hierarchy (tests are undergoing SP and AA) • Alarms messages and alarm handling is still to be defined, • A first proposal exist from IT-CO • Alice DCS widgets are still under discussion by the ACC team • Strongly recommended to contact us if you are having doubts or missing information Alice DCS workshop, Utrecht S.Popescu

  16. Alice DCS workshop, Utrecht S.Popescu

More Related