Image map created by yEd

Administration
Astor's first goal is to know at a quick glance, if everything is OK in a control system,
and otherwise to be able to diagnose a problem and solve it.
The second goal is to configure the control system and its components.
The third goal is to have long term analysis on components (logs, statistics, usage,....).
It is relying on the starter devices.
To achieve complete device independence, it is necessary however to supplement
device classes with a possibility for configuring device dependencies at runtime.
The utility which does this in the TDSOM is the property database. Properties
are identified by an ascii string and the device name. TANGO attributes are also
configured using properties. This database is also used to store device network
addresses (CORBA IOR's), list of classes hosted by a device server process and
list of devices for each class in a device server process. The database ensure
the uniqueness of device name and of alias. TANGO uses MySQL as its database.
A high level object which contains the link to the database. It has methods for
all database commands e.g. get_device_property(), device_list(), info(), etc.
TANGO devices and database are implemented using the TANGO device server model.
To access them the user has the CORBA interface e.g. command_inout(),
write_attributes() etc. defined by the idl file. These methods are very
low-level and assume a good working knowledge of CORBA. In order to simplify
this access, high-level api in C++, Python and Java have been implemented which
hides all CORBA aspects of TANGO.
The TANGO Logging Service (TLS) gives the user the control over how much
information is actually generated and to where it goes. In practice, the
TLS allows to select both the logging level and targets of any device within
the control system.
A Tango Log Consumer device is nothing but a tango device supporting the
following tango command: void log (Tango::DevVarStringArray details)
One implementation of a log consumer associated to a graphical user interface is
available within Tango. It is a standalone java application called LogViewer
based on the publicly available chainsaw application from the log4j package.
JIVE is a standalone JAVA application designed to browse and edit the TANGO database.
Jive also offers advanced search/selection features.
In order to simplify device server process administration, a device of the
DServer class is automatically added to each device server process. Thus, every
device server process supports the same set of administration commands. The
implementation of this DServer class follows the device pattern and therefore,
its device behaves like any other devices. The device name is:
dserver/device server executable name/device server instance name
Clients access the database via TANGO commands requested on the database device.
Communication Layer (CORBA / ZMQ)
Fandango (previously called PyTango_utils) is a Python module created to simplify the configuration of big control systems;
implementing the behavior of Jive (configuration) and/or Astor (deployment) tools in methods that could be called from scripts using regexp and wildcards.
It has been later extended with methods commonly used in some of our python API's (archiving, CCDB, alarms, vacca) or generic devices (composers, simulators, facades).
configuration management tool for an ELI-ALPS equipment (equipment, beamdelivery, etc.).
The CSV files hold device names, hierarchy and attribute property values; which are
used for automatically registering devices in the Tango Database.
The Cabling and Controls DataBase (CCDB) is part of the ALBA control system. It has the following:
•Equipments, connectors and cable types
•Instances of equipments and cables (naming conventions)
•Documentation files
•Installation logs
•Source for automatic code generation and creation of
Tango devices
This device server is able to control Tango components (database, device
servers, clients...). It is able to start or stop and to report the status
of these components.