Midas system is based on a modular scheme that allows scalability and flexibility. Each component operation is handled by a sub-set of functions. but all the components are grouped in a single library (libmidas.a, libmidas.so(UNIX), midas.dll(NT)).
The overall C-code is about 80'000 lines long and makes up over 450 functions (version 1.9.0). But from a user point of view, only a subset of these routines are needed for most operations.
Each Midas component is briefly described below but throughout the documentation more detailed information will be given regarding each of their capabilities. All these components are available from the "off-the-shelf" package. Basic component such as the Buffer Manager, Online Database, Message System, Run Control are by default operational. Other features need to be enabled by the user simply by either starting an application or by activation of the component through the Online Database. A general picture of the Midas system is displayed below.
The main elements of the Midas package are listed below with a short description of its functionality.
A buffer is organized as a FIFO (First-In-First-Out) memory. Consumers can specify which type of events they want to receive from a buffer. For this purpose each event contains a MIDAS header with an event ID and other pertinent information.
Buffers can be accessed locally through the shared memory or remotely via the MIDAS server acting as an interface to that same shared memory.
A common problem in DAQ systems is the possible crash of a client, like a user analyzer. This can cause the whole system to hang up and may require a restart of the DAQ inducing a lost of time and eventually precious data. In order to address this problem, a special watchdog scheme has been implemented. Each client attached to the buffer manager signals its presence periodically by storing a time stamp in the shared memory. Every other client connected to the same buffer manager can then check if the other parties are still alive. If not, proper action is taken consisting in removing the dead client hooks from the system leaving the system in a working condition.
The main advantage of this concept is that all programs participating in an experiment have full access to these data without having to contact different computers. The possible disadvantage could be the extra load put on the particular host serving the ODB. As the access to such databased can be remote, the connection is performed through an RPC layer. Midas includes its own RPC which has been optimized for speed. big/little endian is taken care such that cross-platform is possible with the advantage that the RPC doesn't define a byte ordering but uses the transmitter type and convert to the require byte ordering only if needed by the receiver. Measurement shows that up to 50,000 accesses per second local connection and around 500 accesses per second remotely over the MIDAS server can be obtained (numbers from 1990).
The ODB is hierarchically structured, similar to a file system, with directories and sub-directories. The data is stored in pairs of a key/data, similar to the Windows NT registry. Keys can be dynamically created and deleted. The data associated with a key can be of several types such as: byte, words, double words, float, strings, etc. or arrays of any of those. A key can also be a directory or a symbolic link (like on Unix).
The Midas library provides a complete set of functions to manage and operate on these keys. Furthermore any ODB client can register a Hot Link between a local C-structure and any element of the ODB. Whenever a client (program) changes a value in this sub-tree, the C-structure automatically receives an update of the changed data. Additionally, a client can register a callback function which will be executed as soon as the hot-link's update has been received. For more information see ODB Structure.
This program is composed of a general framework which is experiment independent, and a set of template routines for the user to fill. This program will:
The frontend framework takes care of sending events to the buffer manager and optionally a copy to the ODB. A "Data cache" in the frontend and on the server side reduces the amount of network operations pushing the transfer speed closer to the physical limit of the network configuration.
The data collection in the frontend framework can be triggered by several mechanisms. Currently the frontend supports four different kind of event trigger:
Each of these types of trigger can be enabled/activated for a particular experiment state, Transition State or a combination of any of them. Examples such as "read scaler event only when running" or "read periodic event if the run state is not paused and on all transitions" are possible.
Dedicated header and library files for hardware access to CAMAC, VME, Fastbus, GPIB and RS232 are part of Midas distribution set. For more information see Frontend code.
Basic functionality of the logger includes:
The analyzer is structured into "stages", where each stage analyzes a subset of the event data. Low level stages can perform ADC and TDC calibration,while high level stages can calculate "physics" results. The same analyzer executable can be used to run online (receive events from the buffer manager) and off-line (read events from file). When running online, generated N-tuples/TTree are stored in a ring-buffer in shared memory. They can by analyzed with PAW without stopping the run. For ROOT please refer to the documentation ... Recently ROOT based analyzer is the unique type of analyzer supported with several implementation of that package (analzyer, ROME, Rootana).
When running off-line, the analyzer can read MIDAS binary files, analyze the events, add calculated data for each event and produce a HBOOK RZ output file which can be read in by PAW later. The analyzer framework also supports analyzer parameters. It automatically maps C-structures used in the analyzer to ODB records via Hot Link. To control the analyzer, only the values in the ODB have to be changed which get automatically propagated to the analyzer parameters. If analysis software has been already developed, Midas provides the functionality necessary to interface the analyzer code to the Midas data channel. Support for languages such as C, C++ is available (prior support for FORTRAN, PASCAL were available).
Three "Run State" define the state of Midas Stopped, Paused, Running. In order to change from one state to another, Midas provides four basic "Transition" function Tr_Start, Tr_pause, Tr_resume, Tr_Stop. During these transition periods, any Midas client register to receive notification of such message will be able to perform dedicated task in either synchronized or asynchronized mode within the overall run control of the experiment.
In Order to provide more flexibility to the transition sequence of all the midas clients connected to a given experiment, each transition function has a transition sequence number attached to it. This transition sequence is used to establish within a given transition the order of the invocation of the Midas clients (from the lower seq.# to the largest).
To control a device it is then enough to modify the demand values in the database. The modified value gets automatically propagated to the slow control system, which in turn uses specific device driver to apply he change to the particular hardware. Measured values from the hardware are periodically send back to the ODB to reflect the current status of the sub-system.
The Slow control system is organized in a Object Oriented way with 3 levels of calls such class, device and bus drivers. Each Class driver refers to a particular set of functionality of that class i.e. High-Voltage, Temperature, General I/O, Magnet etc. The implementation of the device specific is done in a second stage "Device Driver" while the actual hardware implementation is done in a third layer "Bus Driver". The current MIDAS distribution already has some device driver for general I/O and commercial High Voltage power supply system (see Supported hardware). The necessary code composing the hardware device driver is kept simple by only requiring a "set channel value" and "read channel value" for example. For the High Voltage class driver, a graphical user interface under Windows or Qt is already available. It can set, load and print high voltages for any devices of that class.
The activation of a recording is not controlled by the history function but by the actual equipment (see Frontend code). This permits a higher flexibility of the history system such as dynamic modification of the event structure without restarting the Midas logger. At any given time, data-over-time relation can be queried from the disk file through a Midas utility mhist task or displayed through the mhttpd task.
The history data extraction from the disk file is done using low level file function giving similar result as a standard database mechanism but with faster access time. Due to its simple use and good display quality, this section has been reworked to be able to handle larger number of parameters. This is one of the main 2.1.0 modification, see History system, ODB /History Tree.
The action triggered by the alarm is left to the user through the mean of a detached script. But basic alarm report is available such as:
Introduction - Top - Quick Start