Glossary

Glossary#

SSH#

The Secure Shell Protocol, is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and remote command-line execution.

See also

https://en.wikipedia.org/wiki/Secure_Shell

Target#

Here, the target refers to the machine you want to monitor.

Host#

Here, the host refers to the monitoring machine, i.e. the IOC machine hosting SSH Monitor.

SSH shell instruction#

A SSH shell instruction, in the context of SSH Monitor, refers to a directive meant to be executed in a terminal (remotly on a target, or locally on the host), through SSH.

E.g. in $ ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes "uname -a", the SSH shell instruction is uname -a.

SSH options and arguments#

SSH options and arguments, in the context of SSH Monitor, refers to the ssh executable and associated parameters that comes before the SSH shell instruction.

E.g. in $ ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes "uname -a", the SSH options and arguments is ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes.

Note

Note that you can specify a different SSH executable, e.g. /usr/bin/alt-ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes, or e.g. /path/to/your/ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes.

SSH command#

A SSH command (or command-line), in the context of SSH Monitor, refers to the combination of the SSH options and arguments and the SSH shell instruction.

E.g. in $ ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes "uname -a", the SSH command is ssh target-sshmonitor-user@192.168.2.3 -o BatchMode=yes "uname -a".

EPICS#

Experimental Physics and Industrial Control System. EPICS is a set of software tools and applications which provide a software infrastructure for use in building distributed control systems to operate devices such as Particle Accelerators, Large Experiments and major Telescopes. Such distributed control systems typically comprise tens or even hundreds of computers, networked together to allow communication between them and to provide control and feedback of the various parts of the device from a central control room, or even remotely over the internet.

See also

https://epics-controls.org/about-epics/

Top#

An EPICS Top refers to the root of a directory (the “top” of the directory) - and its associated structure (i.e. sub-directories architecture) - where you can actually perform EPICS-specific development. You can find a lot of Top examples in the EPICS modules, e.g.: the autosave (v5.7.1) Top. Each Top can be maintained separately, one Top can “import” another one, and different Top can depend on different releases of external software (e.g. a Top can depend on EPICS v3.14.12 and on autosave v5.0.0, while another Top can depend on EPICS v7.0.6 and on autosave v5.7.1).

See also

appdevguide/EPICSBuildFacility.html

App#

An EPICS App refers to a directory inside a Top (the name of that directory has to be suffixed with App), where you can effectively implement the logic of your EPICS application. For example: the asApp directory inside the autosave (v5.7.1) Top.

See also

appdevguide/gettingStarted.html

IOC#

Input/Output Controller. This is the I/O server component of EPICS. Almost any computing platform that can support EPICS basic components (like databases and network communication) and can be used as an IOC. One example is a regular desktop computer, other examples are systems based on real-time operating systems (like vxWorks or RTEMS) and running on dedicated modular computing platforms (like MicroTCA, VME or CompactPCI). EPICS IOC can also run on low-cost hardware (like RaspberryPi or similar).

The “IOC” term is kind of ambiguous, because it is sometimes used to refer to the hardware machine on which the I/O server is running, while sometimes it is used to refer to the its associated software.

In this documentation, if not stated otherwise, the “IOC” term will refer to the hardware machine on which the I/O server is running.

See also

guides/EPICS_Intro.html

IOC program#

An IOC program is just the development result of your EPICS Top + App(s), running on the IOC machine. Not to confused with SoftIOC, which is undefined/unclear and may have a different meaning.

This is not an official EPICS term, but it’s a convenient one for disambiguating the IOC term.

See also

https://epics.anl.gov/tech-talk/2012/msg02138.php

IOC machine#

An IOC machine is the hardware on which runs an IOC program.

This is not an official EPICS term, but it’s a convenient one for disambiguating the IOC term.

Record#

EPICS-based control system contains one or more IOC programs. Each IOC program loads one or more databases. A database is a collection of records of various types. A Record is an object with:

  • A unique name.

  • A behavior defined by its type.

  • Controllable properties (fields).

  • Optional associated hardware I/O (device support).

  • Links to other records.

There are several different types of records available. For example:

  • The “analog input” and “analog output” (ai and ao) types, are used to store an analog value, and are typically used for things like temperatures, pressure, flow rates, etc.

  • The “binary input” and “binary output” (bi and bo) types, are used to store a boolean value, and are generally used for commands and statuses to and from equipment, i.e. for values like On/Off, Open/Closed and so on.

  • The “calc” and “calcout” records can access other records and perform a calculation based on their values. E.g. calculate the efficiency of a motor by a function of the current and voltage input and output, and converting to a percentage for the operator to read.

Each record comprises a number of properties called fields: fields can have different functions, typically they are used to configure how the record operates, or to store data items.

See also

Field#

A field is a record attribute/property. Fields can have different functions, typically they are used to configure how the record operates, or used to store data items. Different record types can have different fields, some fields are common to all record types, others are specific to some types of record.

See also

PV#

A Process Variable (PV) is an “instantiated”/”implemented” record. I.e. once the IOC program is started, each previously defined record will have an associated PV running. A Record is just a blueprint for a PV.

This variable is the addressable unit of data accessible through the EPICS communication protocols (Channel Access and PV Access).

See also

Macro#

A macro is a string substitution mechanism, that will allow some EPICS “configuration” files to be loaded after some strings have been replaced by others. E.g. MY-MACRO-NAME=toto, will replace every ${MY-MACRO-NAME} by toto in any associated “configuration” file. This is very useful e.g. when loading the same “configuration” file multiple times but with some intended implementations differences.

See also

appdevguide/databaseDefinition.html

Comment-macro#

A comment-macro is a particular way of using macros that allow to comment/uncomment parts of the associated “configuration” files. This is very handy, e.g. in order to set/unset some records or some fields when loading a “configuration” file.

See also

https://epics.anl.gov/tech-talk/2019/msg01291.php

.db#

A DataBase file (.db) (or record instance file) is an EPICS “configuration” file containing only record instances/implementations definitions. This file is like a list of records, which will details their associated types, names and fields.

See also

.template#

A Template file (.template) is just like a .db file, but also including macro(s) support.

See also

.dbd file#

A DataBase Definition file is an EPICS “configuration” file containing any sort of definitions except for record instances/implementations (like found in the .db and .template files), because record instances/implementations are fundamentally different from the other definitions.

A file containing record instances should never contain any of the other definitions and vice-versa.

The definitions covered by a .dbd file include “Menus”, “Record Types”, “Devices”, “Drivers”, “Registrars”, “Variables”, “Functions”, “Breakpoint Tables”, “Record Instances”…

See also

appdevguide/databaseDefinition.html

.substitutions#

A .substitutions file is an EPICS “configuration” file that allows to load one or more .template files, multiple times.

The syntax of a .substitutions file is covered in this documentation and the format of a .substitutions file is covered in this documentation.

See also

appdevguide/databaseDefinition.html

.cmd#

A .cmd file is an EPICS executable file that starts with a Shebang instructing the program loader to run the associated IOC program, passing the content of the .cmd file as the first argument.

The .cmd file is mostly used to run the IOC program after loading all the associated EPICS “configuration” files (e.g. .dbd, .db, .template, .substitutions, etc).

See also

appdevguide/gettingStarted.html

IOC Shell#

The content of a .cmd file is a script written with a dedicated EPICS script langage called “IOC Shell” (or iocsh).

See also

CA#

Channel Access (CA) is the default communication protocol used between EPICS servers (i.e. IOCs) and EPICS clients (i.e. HMI monitoring tools, archiving softwares, alarms systems, etc). It is mostly used to share PVs information across a network. CA will use UDP to initiate a client-server communication, and then use TCP for the rest of the communication.

See also

PVA#

PV Access (PVA) is the “new” communication protocol used between EPICS servers (i.e. IOC machines) and EPICS clients (i.e. HMI monitoring tools, archiving softwares, alarms systems, etc).

It is mostly used to share PVs information across a network, like CA. But it also encompasses a structured data encoding referred to as PV Data.

See also

Contents