HW
Hardware, single I/O device.

SW
Software

HW-DATASET
QQQ qua li ho chiamati HW-DATASET per differenziarli dai dataset proprio della CU
Set of HW attributes(DATASET-ATTRIB) controlled/filtered by CU. Each DATASET-ATTRIB is a couple (ATTRIB_NAME, ATTRIB_PROPERTIES_LIST)

The PROPERTY LIST is:

• DOMAIN (device_id) [string] (give by MDS)
• NAME (e.g. Volt) [string] (alphanumeric normalized name)
• DESCRIPTION (e.g. Mean Voltage over 4 tries) [string] (text with the description of the attribute)
• DATA_TYPE (type of data) [int32]
• DATA_FLOW (input, output, IO, macro) [int32]
• RANGE [DATA_TYPE array]
• TIMESTAMP (refreshed by the DS pushing client) [int64]
• TAG

PROPERTY_LIST

• DATATYPE
  

The coding of the DATATYPE in the PROPERTY_TABLE

DATATYPE has dimension of int32\\

Composition

A+B+C+D = 32bit\\
  * A = 3 bit (int32, int64,double, string, byte)
  * B = 1 bit (signed/unsigned)
  * C = 1 bit (array/nonarray)
  * D = 27 bit (service, not defined)

Control Unit Host (CUH)
A CUH is a piece of hardware (PC, FPGA, single-board computer, embedded controller, etc.) running one or more instances of CU.

Live Data Server (LDS)
High throughput SW develop to cache each DATASETs. It contains the most recent DATASET-ATTRIB for each CU, these data are joined with own HW-KEYVAL.

Hardware key value (HW-KEYVAL)
It is the unique identifier of HW in the databases.

History Data Sever (HDS)
No-SQL Database devote to store the HW data useful for CU. NO-SQL database are will be take advantages respect to the SQL ones, speeding up key insertion and fetching by means of their indexing features.

Live Data Push Rate (LDPR)
QQQ

History Data Push Rate (HDPR)
QQQ

ControlUnit (CU)
SW object that makes frontend from !CHAOS to the set of controlled HW. It defines (runtime and programmatically) each DATASET for each HW embedded in the HW control-list of CU.
It sets up each HW-DATASET to toward LDS and HDS. It can perform actions by means of RPC calls defined by CHAOS-RPC system. It can receive DATASET attribute values defined as "input".
The CU is the principal source of data for CHAOS. It’s role is controlling an accelerator hw components or a family thereof. It pushes data to LDS and HDS according to the LDPR and HDPR value. Every CU can manage more than an hardware. Each CU has its own dataset:

• CU_NAME
• CU_DESCRIPTION
• CU_CLASS
• CU_UUID (dynamically created at each boot for being differentiated between same class instances)

CSLib
QQQ controllare se la descrizione va bene !CHAOS framework realized for HW-DAQ developer to permit the transparent integration in !CHAOS. By means of its call, the developer creates a daemon that runs CU. The latter is developed by means of CSLib and HW calls.

CU actions (CUACT)
QQQ

CU informations (CUINFO)
CU informations are:

• Current IP of HW machine that contains the daemon in which runs one or more CU.
• Live status of the daemon (Heartbeat like)
• HW-DATASETs and set of permitted actions (semantic and syntax) of each CU controlled by the daemon in the CU-register phase
• Accepted substitution of DATASET attributes value. This is useful to reconfigure the CUs with last setup before a shutdown (as accidental as forced)

MetadaServer (MDS)
QQQ Esiste un metadata server database?
It's collects CUINFO, stores them on DB, manages CU communications, runs independently batch and maintenance actions of CU, LDS, HDS.

The batch and maintenance actions of CU, LDS, HDS performed by MDS are:

• purging of HDS data that get out of temporal validity
• running of scheduled actions/command

LIVE DATA (LD)
QQQ

HISTORY DATA (HSTD)
QQQ

Control GUI
It uses CUINFO collected in MDS to fetch necessary info to perform:

• the fetching of LD and HSTD for get values of DATASET-ATTRIB
• the CUACT execution
• the GUI display runtime generation. It will be done by dynamically generated GUI panel, using the fetched info to setup automatically I/o GUI controls.

CU Methods

• void WorkerCU::defineActionAndDataset(shared_ptr<CSDataWrapper>&) throw(ControlSystemException)
  

Call at each CU boot. It defines all DATASET and CUACT for each CU statically, by means BSON and API. QQQ Qua allora e' BSON, non JSON???
At the end of this call the entire description will be send to MDS via BSON, where it will refresh the existing one. The MDS gets the info regarding the CU controlled HW. It is possible to overhead this call via GUI.

Inside this method are placed the API calls to configure each DATASET-ATTRIB for each single HW:

• void WorkerCU::init(shared_ptr<CSDataWrapper>& newConfiguration) throw(ControlSystemException)
  CU init method - once at CU boot
• void WorkerCU::run() throw(ControlSystemException)
  Scheduled CU action method call - the scheduled period will be runtime adjusted. In case of negative value, this methos is a single shot one.
• void WorkerCU::stop() throw(ControlSystemException)
  Called at CU pausing. It differs from de-init method.
• void WorkerCU::deinit() throw(ControlSystemException)
  CU deinit method.
• void WorkerCU::setDatasetAttribute(shared_ptr<CSDataWrapper>&) throw (ControlSystemException)
  Called from GUI, this is CU method for setup DATASET-ATTRIB. Each of DATASET-ATTRIB will be filter by CSDATAWRAPPER.
• void WorkerCU::updateConfiguration(shared_ptr<CSDataWrapper>& newConfiguration) throw (ControlSystemException)
  Called when takes place a configuration, joined with the method AbstractControlUnit::updateConfiguration(newConfiguration). The latter will forward the configuration to the drivers and buffers controlled by AbstractControlUnit.

AbstractControlUnit
QQQ

CSDataWrapper (CSDATAWRAPPER)
QQQ