FAIR Accelerator Control System - General Glossary

glossary.jpg

Glossary Overview

This web intents to define and explain the most important and relevant technical terms of the FAIR accelerator control system.
The glossary is structured along the technical subsystems or major architectural building blocks of the control system.


Major Control System Building Blocks and Frameworks

  • FESA - Front-End System Architecture. FESA (originally developed by CERN) is a comprehensive framework whereby front-end software is to be designed, developed, deployed and maintained according to the Controls group standard. FESA models abstract device objects where equipment’s process variables (sensors and actuators) are represented as Properties. The specific equipment access is implemented in C++ by the developer and is linked by the toolchain to the device model to build a so called FESA class. FESA supports multiplexed operation by selecting beam specific data from multiplexed properties based on information provided by the FAIR timing system. More Information
  • LSA - (pronounced "Elsa") Setting generation and management system. LSA is a set of business logic and applications used for setting generation and management. It is a software product from CERN. It is highly database-driven (see LSA-DB) and has one data model for all accelerators. The LSA core is split in several modules (Optics, Settings, Trim, Gemeration, Exploitation, Client module) that provide services to handle settings, contexts, rules and trims. LSA is highly data driven, and relies on the data in the LSA-Database (LSA-DB). More information
  • CMW - Common Middleware. A set of software packages, frameworks and applications related to communication between Frontend tier (FECs) in form of the FESA Device Classes and the Services/Application tier, e.g. JAPC. Originally developed by CERN. More Information
  • GMT - General Machine Timing System. The GMT is a distributed event generation system based on the notion of time. Time synchronization is achieved by using White Rabbit (WR), a fully deterministic Ethernet-based field bus for clock transfer and synchronization. The key components of the GMT are a so-called Data Master (DM) that schedules actions by broadcasting messages, a WR network and Timing Receiver (TR) nodes executing machine relevant actions on time. As the GMT is based on the notion of time "time based system", it is fundamtentally different compared to centrally triggered systems like the existing GSI timing system, where events are directly sent from a "Pulszentrale". More Information on the GMT.
  • UNICOS - (UNified Industrial Control System) is a CERN-made framework to develop industrial control applications. It deals with the upper two layers of a classical control system. UNICOS implements a method to design and develop the control application which runs in commercial off-the-shelf products (SCADA system WinCCOA, PLCs).

Further Control System Subsystems

  • Diagnostic Logging System - System to receive and store diagnostic logging messages in the control system. The system focuses on system messages, not on accelerator measurement data. The system is implemented as a cluster of logstash servers. More information
  • Archiving System - Stores historical data gained and generated by the accelerator control system in a permanent location (Archive-DB). It allows storing data on a configurable base of resolution in time, triggered by timing events or on-change. Data may be either data gathered from devices, higher level data like computed physical properties or generated abstract data. The Archiving System includes functionality to query, filter, correlate and display historical data. The Archiving System provides control room applications to display, configure, and manage archived data. More Information (intern)
  • Alarm System - The Alarm System is a software system to enable operators to identify and locate conditions of hardware and software components which indicate malfunctioning or nearby malfunctioning (e.g. an overheated magnet), especially those error conditions which cannot be automatically resolved.
  • Post Mortem (PM) System - ...
  • Beam Transmission Monitoring System (BTM) - ...
  • Beam Interlock System - The Beam Interlock System (BIS) for FAIR is part of the machine protection system. It collects various hardware interlock signals from up to 60 distributed remote I/O stations through PROFINET to a central PLC CPU. Thus a bit-field is built and sent to the interlock processor (PC) via a simple Ethernet point-to-point connection. Additional software Interlock sources can be picked up by the Interlock Processor via UDP/IP protocol. Interlock logic is performed on the interlock processor which intefaces to the Data Master in order to forbid beam to be transported to certain part of the accelerator complex.
  • FBAS - Fast Beam Abort System for SIS-100 ...
  • Conditions Framework - Provide control system-wide condition values and texts. Software modules usually return a so called error code when an error has occured. Since the term error code is a bit misleading, a module may also return a success code if it has performed well (without error), the more general term condition is used. Conditions are system-wide unique to allow their context-free handling. See Condition Values and Texts - Requirements and Ideas and Condition Compiler.
  • B2B System - The Bunch to Bucket (B2B) transfer system has the task of transferring a bunches of particles stored in a source machine to (empty) buckets in a target machine. Typically, this is employed for transferring particles between ring machines. The B2B system is closely linked to the rf-systems and to the GMT.

Multiplexing and Indexing Terms

Since the following terms and concepts are fundamental to the control system and machine operation, more detailed description and explanations can be found here: Multiplexing and Data Indexing Concept

  • Pattern - Concept and identifier describing one schedule for the accelerator facility. A Pattern consists of several Beam Production Chains.
  • Beam Production Chain (BPC) - Concept and Identifier describing one beam from source to destination across the accelerator facility, spanning across several accelerators where necessary. Destination can be either a experiment at the end or also e.g. a storage ring. Source could be an ion source but if appropriate also again a storage ring.
  • Beam Process - One process describing an action within the accelerator, e.g. ramp, flattop, extraction, transfer, etc. Beam processes are executed as atomic operations within the control system; once started a Beam Process is always executed to its end.
  • Sequence - Concept and identifier to group Beam Processes sequentially that are logically executed together, e.g. one acceleration process of the upstream accelerator wihin a multiturn injection, used for data acquisition.
  • Multiplexing Context - Set of metadata that describes the context of the acquired data. The Multiplexing Context especially contains all relevant IDs and timestamps.
  • Selector - Set of indices provided to FESA Device classes for indexing device data (set values) and data requests (acquisition data). The selector is implemented as a string.
  • Virtual Accelerator (VAcc, VirtAcc) - Legacy concept of the old GSI control system; not to be used any more in the new FAIR control system. The concept is still available for backward compatibility in retrofitted machines and UNILAC. A Virtual Accelerator represents a type of cycle (or linac pulse). A Virtual Accelerator for a linac machine (e.g. UNILAC, p-Linac) can also be called "pulse"; a Virtual Accelerator for a synchrotron machine can be called a "Cycle". An adequate name for storage rings does not exist.

Structural Terms

  • Particle Transfer - A section of the facility that belongs together from an optics, settings and timing perspective. Beam Processes are defined per Particle Transfer.
  • Accelerator Zone - A section of the facility for which the same beam parameters (i.a. energy, momentum, rigidity) are valid. Devices are assigned to Accelerator Zones.

Application Layer

  • Application, App - User Program, Java based, usually with GUI (graphical user interface), implemented in the Main Control Room or local control rooms to set, operate, monitor, optimise the accelerator or the accelerator controls infrastructure. Applications run on Console computers.
  • Web Application - A web application or web app is a client-server software application in which the client (or user interface) runs in a web browser. (...)
  • Console - Dedicated computer system with graphical displays in the main control room or local control rooms for users/operators on which control Applications are executed. Console computers are connected to the Accelerator Network.

Middleware

  • CMW - see above More Information (CERN)
  • CMW Directory Server - Central component of CMW. CMW Directory Server have two key functions. First it keeps track of all started RDA Servers and acts as a kind of broker providing clients with the technical connection infromation about desired RDA Servers. Second it resolves particular Device names to RDA Servers where they are running on. To accomplish this task all CMW components are required to register (bind) themselves at the Server during initialization and startup. Using the FESA-DB the Directory Server also keeps track which devices are deployed on particular CWM Servers. JAPC framework uses this information to find the server for a partiucar device and determine which communication framework (JAPC-plugin) need to be used with this server (RDA2, RDA3, DevAcc etc.) More Information
  • RDA - Remote Device Access - a core part of CMW. Provides a communication framework developed to use in accelerator facilities (primarily at CERN). Design corresponds to the Accelerator Device Model. This represents the control system in form of multiple named Devices entities, which hold a set of particular Properties (aka Parameters). RDA provides functionality to perform basic operations on those parameters like set, get and subscribe to parameter values. It implements this model in a distributed environment with devices residing in front-end servers that can run anywhere in the controls network and provides a location-independent and reliable access to device parameters from control applications. The current version (RDA3) is using the ZeroMQ as underlying messaging layer, while older RDA2 version relied on CORBA. More Information (CERN)
  • RBAC - Role Based Access Control (...)
  • ZeroMQ (also spelled ØMQ, 0MQ or ZMQ) - a high-performance asynchronous messaging library, aimed to use in scalable distributed or concurrent applications. It provides a message queue, but unlike message-oriented middleware, a ZeroMQ system can run without a dedicated message broker. ZeroMQ is used as a messaging layer for RDA3. More Information
  • JAPC - Java API for Parameter Control. JAPC provides a transparent high level API to access Device parameter values. The main advantage of the API is its transparency to the user, since it hides the underlying layer implementation. More information
  • Device Access - Denotes the GSI control system, launched 1989 and since then continuously enhanced and modernized. Device Access denotes, in a closer sense, also the access interface to devices in the exisitng GSI control sytem. For further Information see page Device Access in the controls wiki.

Databases

  • FESA-DB - Database of the FESA system. Contains information about particular FESA classes, deployment units and devices.
  • LSA-DB: Database of the LSA system. Contains ...
  • ControlsDB - Control System Database. Contains ...
  • Controls Configuration Database (CCDB) - ...
  • ArchiveDB - Database of the Archiving System to stone acquisition data.
  • CDB - Component Database

Equipment Control Layer

  • Equipment - In the context of the accelerator control system, Equipment is the general term for all physical systems to be monitored and/or controlled by the control system. Examples: power converters, high voltage systems, all types of beam diagnostic systems, pumps, valves, motor drives, low level feedback systems, etc. All Equipment is physically connected (via a physical interface) to an appropriate Equipment Controller or Front-End Controller (FEC) and usually represented as a logical Device.
  • Front-End Controller (FEC) - Front-End Controllers are processor-based computer systems that communicate to higher levels of the control system via network and communication middleware. The FEC use a dedicated front-end software architecture package (FESA) to implement generic and equipment specific functions. The FEC represents the functionality of the equipment by abstraction in the FE software as a Device to higher levels of the control system.
  • Equipment Controller - same as Front-End Controller (see there).
  • Device - A Device is the elementary control unit in the control system. Most Devices are software abstractions of the hardware. A Device exposes a public interface made of Properties. A Device can be a representation of a physical system such as a power converter or purely virtual such as a grouping of hardware pieces. Devices are modeled by FESA Classes which define the property interface of all Devices belonging to a certain class or type.
  • FESA Classes - The equipment-type specific front-end software, developed with the FESA framework. A FESA class implements, for a specific type of equipment, access to the control interface of the equipment hardware, which means writing of set values and reading of acquisition data. Interaction with the equipment in general is synchronized by the machine timing system. The FESA class models the equipment hardware as Devices, providing device properties as interface for remote access. One FESA class can instanciate several devices and thus generally handles several independent pieces of equipment,
  • FESA - FESA (Front-End Software Architecture) is the framework to develop FESA classes. The FESA framework ensures a common set of Device Properties as well as a common layout of the FESA Classes. The FESA Framework provides all common mechanisms for remote access to properties, device instantiation and synchronization of Actions by the General Machine Timing system.
  • Device Property - The properties of a Device are the remote access points of a device. A property generally is used for exchange of data (get or set). Data is arranged as made of Value Items. A Property can be read (get), written (set) or monitored (subscribe/publish). Some properties are read-only.
  • Value Item - Data-item in a Device Property. Each Value-Item can be a scalar, a one- or two-dimensional array. Basic types, int and floats of several sizes as well as char, are supported. A Value Item is identified by its name.
  • SILECS - framework (formerly known as IEPLC), composed of a set of tools, scripts and a C++ library, to provide standardized communication interfaces to PLCs for control system integration. It automatically generates all resources needed on client and controller side to implement a common and generic Ethernet communication. The configuration tool allows the definition of the data to be exchanged and their instantiation on different controllers within the control system. The scripts generate the resources necessary to the communication while the library allows the application on the client side to send and receive data from/to the different controllers. More Information

Hardware Layer

  • SCU - Scalable Control Unit, a new generation of standard equipment controller (FEC) for the FAIR control system which provides a compact and flexible solution for controlling all types of accelerator equipment. Being a (19", 3 U) crate-mounted modular system, the SCU features the SCU-Bus on its backplane connection. Acting itself as a bus-master, a variety of electronic SCU Slave boards with different interfaces are available for connecting devices (ADC, DAC, digital interfaces with different levels, electro-optiv interfaces, DDS-boards for cavity control, ACU for digital power converter control). The SCU is connected to Gigabit Ethernet and the White Rabbit based timing network. Time-critical functions like real-time device control and the integrated FTRN (timing receiver) functionality providing high-presicion time-stamps and event execution are implemented in an powerful FPGA. Other software tasks, including relaxed real-time functions implemented as FESA classes, is done by a COTS (commercial of the shelf) standard ComExpress CPU module running Linux OS. More Information
  • SCU-Bus - Standard parallel communication bus on the SCU backplane (...) More Information
  • SCU Slave Boards - All types of electronic boards with SCU Bus Interface More Information
  • GSI DeviceBus - MIL-1553 fieldbus to interface legacy accelerator equipment More Information
  • FG - Function Generator ... More Information
  • CID - Component Identifier; every FAIR component has to be labelled with a unique number ... More Information

Timing System

  • GMT (General Machine Timing system) - see above
  • FECo (Forward Error Correction), one of the aspects required to achieve robustness with the GMT.
  • FTRN (FAIR Timing Receiver Node) - Timing Receiver. Available in different form factors such as PMC, PCIe, VME, AMC, Standalone and Rackmount. A timing receiver provides high-precision (sub ns) execution of actions. Actions can be of different types including digital output, writing data to the SCU bus (see above), timed generation of bursts, clocks or issuing IRQ to host bus systems.
  • TR (Timing Receiver) - same as FTRN plus the SCU.
  • White Rabbit (WR) - A clock and time distribution system with sub-nanosecond accuracy, based on Synchronous Gigabit Internet and IEEE-1588 PTP (Precision Time Protocol). More Information on Wikipedia
  • WR-PTP - White Rabbit Precision Time Protocol, an extension of the Precision Time Protocol (PTP) defined in IEEE-1588.
  • WR Network - A network based on White Rabbit enabled equipment. A key component are WR Switches, that allow propagation of clock and time from a grand master to all connected nodes.
  • WR Switch (WRS): Dedicated 18 Port Gigabit Ethernet Switch that support WR PTP.
  • Timing Master (TM) - Top level centre of the GMT. The Timing Master includes the Data Master, the Clock Master and the Management Master.
  • Data Master (DM) - Master real-time scheduler for the GSI/FAIR accelerators and beam-lines. The data master autonomously orchestrates the complete accelerator facility (excluding UNILAC) in a predefined schedule by sending out messages to synchronously trigger and synchronize real-time software, hardware and equipment actions. There is only one Data Master for the FAIR facility.
  • Clock Master (CM) - Grand Master of a WR Network.
  • Management Master (MM) - Provides management of the White Rabbit network.
  • SaftLib - Simplified API For Timing. This is the interface for programs on the host system towards a Timing Receiver. More Information
  • Timing Domain - Timing Domains are implemented by physically distinct timing networks, presently 4 domains exist: "Production", "User", "Timing (Test Facility)", "miniCS@Saclay"
  • Timing Group - Timing groups define where FTRN are located, see [[Timing.TimingSystemGroupsAndMachines][here].
  • Timing Event Number - Event Numbers are identifiers that indicate certain activities, see here.
  • Timing Message - A Timing Message includes an execution timestamp, an identifier and other fields, see here. Timing message are sent by the Data Master to all FTRNs in the network via broadcast.
  • PZ - German "Pulszentrale", real-time scheduler of the existing (non-FAIR) accelerator control system. Of the 3 PZ, those for SIS and ESR will be replaced by the FAIR Data Master while the one for UNILAC (UNI-PZ) will continue to be operated.
  • BuTiS - Bunch Timing System. Provides high precision clock signals and distributes them on the campus, developed and implemented for synchronisation of distributed RF systems. BuTiS is provided by the RF-department.
  • TAI epoch - Temps Atomique International (international atomic time), epoch used for PTP based systems. A TAI epoch includes the following features: The clock counter ("the time") increases strictly monotonically and that all seconds have the same length and leap seconds must not exist. Please note, that the White Rabbit clock of the GMT and the BuTiS clock must be phase-locked to each other.
  • TAI Time Scale - Time Scale is a property of PTP and must not be confused with epoch. The standard time scale used by PTP is TAI. Other arbitrary time scales may be used too, as long as TAI epoch (see above) is respected. The relationship between the PTP time scale and UTC is provided as a UTC offset in the PTP announce messages. To date (January 2018), White Rabbit PTP only supports the TAI timescale.
  • Back-Channel - Upstream traffic to DM with a high risk of jeopardizing the performance of the GMT and killing the Data Master. For internal use for GMT purposes only. There is no public interface. Must not be used except in rare cases such as B2B.

Industrial Control Systems

  • UNICOS - Universal Industrial Control System, developed by CERN, used at FAIR for slow controls purposes, the accelerator infrastructure system Vacuum Controls and Cryogenic Controls.
  • WinCC OA - WinCC Open Architecture - commercial SIEMENS SCADA system which UNICOS bases on. More Information (Siemens)
  • PLC - Progammable Logic Controller (German: SPS, Speicherprogrammierbare Steuerung)

Network(s)

  • Accelerator Network (AccNet) - Ethernet IP Network.
  • VLAN - Virtual LAN (local area network). VLAN abstracts the idea of the LAN; A VLAN might comprise a subset of the ports on a single switch or subsets of ports on multiple switches. By default, systems on one VLAN don't see the traffic associated with systems on other VLANs on the same network. VLANs allow the control system network adminstrators to partition the network to match the functional and security requirements of control system communication without having to run new cables or make major changes in the current network infrastructure.
  • Timing Network - see Timing System section: WR network
  • ProfiNet - ProfiNet (Process Field Net) is an open standard for Industrial Ethernet based on Industrial Ethernet for automation purposes. Profinet uses TCP/IP and IT standards, is real-time performance and allows integration of automation fieldbus systems. In the control system, ProfiNet is used for communication between PLCs and RemoteIO stations mainly (but not exclusively) of the Vacuum control system, Cryogenic control system, Interlock System, Personnel Safety System.

General Terms, Technologies

  • Hardware - Electronic hardware, interconnected electronic components.
  • FPGA - A Field-Programmable Gate Array (FPGA) is an integrated circuit designed to be configured by a customer or a designer after manufacturing – hence "field-programmable".
  • Gateware - Synthesized VHDL code for configuring FPGAs. This is fundamentally different to software or firmware.
  • (V)HDL - Hardware Description Language (HDL) is a specialized language used to program the structure, design and operation of electronic circuits, and most commonly, digital logic circuits.
  • Firmware - Firmware is a type of software for engineered systems, in particular embedded systems based on micro-controllers or small CPUs. The firmware provides low-level control programs. Firmware is held in non-volatile memory devices such as flash memory. Firmware can be updated.
  • Software - Computer software is any set of instructions that directs a CPU to perform specific operations. Computer software consists of computer programs, libraries and related non-executable data. Computer software is non-tangible, contrasted with computer hardware, which is the physical component of computers. In practice, the FAIR control system software is written in high-level programming languages like C++ and Java.
  • LM32 - The LatticeMico32 is a free 32-bit, RISC architecture softcore microprocessor widely used in the control system FPGA hardware (SCU, SCU slave boards, FTRN, etc.). More information about LM32 on Wikipedia.

Beam Instrumentation Subsystems

  • LASSIE - Large analogue Signal and Scaling Information Environment (...)
Topic revision: r58 - 25 Feb 2019, FredericAmeil
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback