HERA-B Slow Control

Semenov Yu. (semenov@ns.itep.ru) 10-06-97

General principles

The general structure of the Slow Control (SC) system is shown in figure 1. All subsystems should have their own SC-systems. The subsystem is a system which is responsible for some sub-detector or any other part of HERA-B (magnet, target, calorimeter, tracker, etc.; see "Proposal for HeraB Message Handler Interface", p.5). In the text below a subsystem and local SC are equivalent.

The concept of the system is a uniform handling of all commands, events, errors etc. for all nodes and subsystems. In subsystem there is a one or more independent processes. They may exchange each other and main RUN-control code with messages (requests, replays, data, etc.). Some messages are used to inform client of some event, others - to request or send data. In case when the same message must be accepted with several processes (e.g. SC-code and UI), they should subscribe this type of message at the process initialization time. Such messages are sent to the addressees one by one with acknowledgments, if necessary. All decisions are defined by the data got via messages. The messages are sent using UDP-datagrams (see description of RPM message system).

Figure 1

On the third level of the figure 1 and below there may be not a real sub-sub-systems but sub-processes. Every subsystem has its own Configuration D-base (CDB) and Status D-base (SDB). The CDB defines subsystem configuration for all types of runs (normal data taking HERA-B-run, calibration run and all test runs - V1...VN), it defines "unchangeable" parameters of the subsystems (thresholds, HV-values, gas mixtures, magnetic field, target positioning, addresses,...). The CDB is used at the subsystem setting up and contains also a section of Name/Address server. The structure of these d-bases is defined in description of the Table Based Data Base (herab/DAQ/soft.html docu.dvi, Thomas Kihm, 1995). Some details will be fixed later.

The SDB contains a current measured subsystem parameters (resources, like available disk space and number of free buffers are in this parameter list) and, if necessary, some prehistory of their changes, LogBook- and Error Logger sections. The D-base updating is realized using messages under the control of Local Slow Control code and Server DB. The changeability of these sections is different - the LogBook and Error Logger store data "for ever", but the Status data are updated periodically.

To change CDB data one must have an administrative priority. All changes must be put down into the local and central Log Book data base section. In reality CDB and SDB may be sections of one common D-base. The structure for the MAIN SC and for any subsystem (local SC) are similar (Fig.1). MAIN SC is a code in the main computer of Slow Control system. Any subsystem may include several subsystems (or processes) in turn (1.1 - 1,J, e.g.)

If the RUN-code, e.g. needs some particular information, it sends a request to the local Slow Control code. It provides RUN-control process a requested datum with response-message immediately or requests in turn the data from some subsystem Slow Control code.

The local CDB should have all necessary information to control subsystem in all regimes. The Local Slow Control code can request any data from the central and any other subsystem Local Slow Control code, but it can not change the data there. All CDB and SDB have primary and secondary versions (the latter must be installed on the other computer than primary). The switching from primary to the secondary D-base in case of failure must be invisible for application but be registered in electronic LogBook. This will increase the reliability of the whole system. The secondary D-base is a mirror of primary D-base and must be upgraded after any change of the primary one. The content of these d-base must be compared periodically. The interaction between hardware parameter control, SC-code, and D-bases is shown in fig. 2.

Figure 2. The interaction between Parameter control system, SC and D-bases

A writing data from SC-codes to SDB via SDB-server is carried out with help of DATA-messages, in which body besides particular data there are type of data and address.

The RUN control code starts by sending a <INIT-message> to all subsystems (Fig. 3). The RUN-control process changes its state and waits for READY-messages from all local SC. The subsystems check their status (interlocks, status switches, power supplies, temperatures, etc.), and if something wrong, an ALARM-message is sent to the RUN-control process. Every subsystem must send a READY- or NOT_READY-message in any case (this shows that it is alive). All messages from subsystems to the RUN-control code and vise-versa are transmitted via SC-codes. If there is no READY-message during predetermined time (time-out), the RUN-control process generates a TIME-OUT message to the Error Logger. <INIT-message> will be repeated once more for corresponding subsystem, at the same time the timer is started. After several (how many?) attempts the subsystem is nominated <dead>. The ALARM will be displayed at the main shift terminal (rpm_fdump) and STOP-RUN message sent to the TRIGGER-system. A displaying of such a messages is realized via sending a corresponding message to the process controlling the SC-terminal. If necessary some of the message types may be masked with a help of MASK_ALARM-message.

The <INIT-message> initiates running preparations in subsystems (control the gas system, starting of the switching on HV procedures (if they are not ON) and shifting voltages on Si-detectors etc.

If all subsystem parameters are O.K., subsystem sends <READY-message>. If there is no such a message during time-out time, the RUN-control process sends corresponding message to this particular subsystem and it must response with a NOT_READY-message, explaining the reason (sends a failure code). The alternative solution is a periodical sending STILL_ALIVE-messages from the RUN-control process to subsystem and receiving ALIVE-messages until subsystem sends READY-message. The message structure is defined in the file messdoc.dvi.

Until the subsystem provides a <READY-message> any further actions are blocked. (In reality most of the subsystems are switched on in advance and as a rule are ready to run). The RUN-process must wait, but an operator on shift may mask any source of ALARM-messages and start RUN without some READY signals (this will be fixed in LogBook D-base section).

The same happens at HERA-B run-time, when alarm-message comes. The RUN may be resumed only after corresponding <READY-message> or at masking the ALARM by the operator on shift. From time-to-time process-code can send a STILL_ALIVE-message to any process or subsystem to test its availability. At the same moment a timer is activated. An absence of a response during predetermined time will cause a Time-out-message to the process which sent a request. It must retransmit it also to the higher level process (or to MAIN SC) and to the Error Logger.

It is not a coincidence of messages but states, which are not changed since READY-message arrival till the and of RUN, coming NON_READY-message or ALARM.

Figure 3. RUN Control

Any procedure to be carried out needs a time. But for some reasons this time may vary in a wide range. For every procedure we fix a maximum time for carrying out, if this time is exceeded a time-out is happen. This can start a diagnostic procedure.

The time-out values may be calculated on the base of a round trip time (RTT) measurements or fixed at the system configuration. The round trip time is a time which passes from the sending request message till the response coming back. Every time process sends a request it activates a timer to measure RTT. RTT must be averaged for every type of requests (RTTm) . The Tout,i must be put into a corresponding SDB, it may be one more good diagnostics parameter. Any sharp variation of the Tout,i (more than double dispersion value) will be reported. The value Tout,i depends on the time. At the very beginning ("cold state") it is higher than at time when system is in "warmed" state (voltages are ON, all is already tested, etc.).

Tout,i =RTTm,i* a (a ~2, i - is a code of request message type).

In principal we may forget about individual RTT-values and take one time-out value for all subsystems (the biggest RTT). To control an availability of subsystems at this long waiting RUN-process will send STILL_ALIVE-messages periodically. The inpatient operator may activate special message (STATUS-request) to the "too slow" subsystem which requests the list of non-ready processes. Such an option should be provided by UI of MAIN SC.

The User Interface (UI) provides on the control terminal a scale of bars, corresponding to the all subsystems. The <READY-message> arrival changes the bar color from red to green (Fig. 4, the list of the subsystems see in the file messdoc.dvi). When all bars are green, the scale is removed from the screen, it may be restored in case of ALARM. If subsystem does not respond on STILL_ALIVE-request, the corresponding bar start blinking. A blinking stops at getting an answer or after masking it out by the operator on shift. The messages STILL_ALIVE must be sent and in running time, this will help to check all component accessibility (dead subsystem will never send an alarm message).

Figure 4

We need a standard for color codes. The experience of the H1-experiment shows that subsystems, have a quite different color signaling. As on the shift not all the subsystem experts are available, it makes problems.

Subsystems Configuration

The RUN-name (from menu) determines the whole system configuration (see Table 5). The procedure starts with a sending a CONFIGURE-message by SC-process to the local Slow Control code. It takes a configuration code (type of run) from the body of the configuration message and form a CONF-request to the SDB-server (see fig. 2). The latter reads corresponding configuration data from CDB (Data(c)) and sends this information to the SC-code in form of C-DATA-message (Data(b)). The SC-code readdress the message to the parameter hardware control and the data are put into the Buffer (Data(a)). As the procedure is finished the Local Slow Control code sends READY message to the Main SC-process.

The CONFIGURE-message may be sent even when subsystem is in READY-state, if we need to change working regime. But before doing so process must inform the MAIN SC about it by sending an ALARM-message with a reason code in the message body. There is a possibility to have several configurations for different RUNs. Every configuration has its own code, which is to put into a CONFIGURATION-message body. The configuration process has several stages:

For example, the HERA-B ECAL has the following sequence of startup:

After some delay (PM warming) the system can send a READY-message. For other subsystems the procedures of setting up are different, but all of them may use the same interaction with the CDB.


The correctness of the controlled parameters is checked locally in subsystems (SC). Any ALARM-messages are sent by subsystem SC-code only in case of real emergency. The subsystem SC-code must respond to Request-messages of MAIN-SC and send requested information (e.g. at the request of the person on shift). There is one central SC system, which will control some general parameters (atmospheric pressure, humidity, some low voltages for power supplies etc.). There are three levels of ALARM:

1. No ALARM at all (displayed data is in green color).

2. The parameter value is in dangerous range (displayed message is red).

3. The parameter value is absolutely intolerable (blinking red message) or some sub-sub-system is dead.

The figure 6 shows the meaning of MAX/MIN "dangerous" and "intolerable". A dangerous parameter value is not good, operator is forewarned about this, but we may run still.

All alarms-messages are displayed locally and retransmitted to the MAIN-SC and to the Error-logger. All ALARM-messages are to be acknowledged by the SC-code, as loosing of such messages is dangerous. The sender start a timer just after an alarm sending and in case of time-out retransmits the ALARM. The ALARM generation is interrupted with a acknowledge-message (is masked). The ALARM-message besides real current parameter value must contain a corresponding alarm-level thresholds (see Fig. 6). An alarm-message may be sent by subsystem, when it needs the calibration run. Such a message forces MAIN SC to stop main trigger system and to change run-type, sending a CONFIGURE-message. After the subsystem will sent the READY-message the calibration run may be started. When calibration is over, one more ALARM will be sent, the primary configuration restored by sending CONFIGURE-message and after the subsystem's READY, a date taking RUN will be resumed. Let us, e.g. consider again the HERA-B ECAL, it has a current control for PM-base groups. In case of overcurrent the group is switched off. The group of PM is without HV, this can not be cured immediately. All this developments are written in into ERROR-logger. What shall we do? Look at detector scheme, where the dead detector section is shown and make a hard decision to resume running (any such a decision is on a responsibility of the operative personal, not a computer code). This decision will be put down automatically into LogBook data-base.

Configuration Parameter Change

A procedure of changing any configuration parameter have several stages (see Fig. 5). At first the User Interface sends a request to the SC-code with a parameter identifier and its new value. The MD deliver it to the SDB to put down to the configuration D-base (SET-parameter message, see table 6). The message is copied by the SC-code and sent to the LogBook. The latter must respond with READY-message. The correctness of the procedure is checked with a control GET-reading of the value. After that STOP_RUN message is sent to the HERA-B trigger system. After a response READY is delivered, a message SET_HARD is sent to the corresponding subsystem Hardware Scanner. If necessary the SC-code may send preliminary a request to the Name/Address server. It contains a new configuration parameter value. The procedure is over when READY-message was accepted by the SC-code (sent by the hardware subsystem). The running is resumed with a RUN-message to the HERA-B trigger system. The last exchange SET_PAR/READY is putting down a record to the LogBook (must be checked with GET_PAR/READY exchange).

Figure 5. Diagram of configuration parameter change

The SC must have a stack buffer for the sent request needed READY acknowledgment. Sending such a message code starts a corresponding timer, which is stopped at getting READY or at time-out. There are two types of parameters: single, table. A single parameter is characterized with:

Table 1. List of subsystem parameters for CDB
Field name
Parameter name
String with length byte first
Parameter type (see docu.dvi p.2) (case 2 of more dimension tables ???)
Measurement period in seconds
Usually 10 - 3600 sec.
MIN-absolute (intolerable) (*)
MIN-dangerous (*)
Nominal value (*)
MAX-absolute (intolerable) (*)
MAX-dangerous (*)

The rows 1-3 comprise a record header. In a message one should present a real value and values from rows 4 - 7. Values in the cells marked with a * are parameter dependent.

The header for table-type parameters is shown in table 1a.

Table 1a. Table-type parameter header in CDB-record (status measurement conditions)
Field name
Table name
Table type
Measurement period in seconds
Number of records
Record length

Then follows list of records, e.g. as rows 4-8 in table 1.

Status data putting down

The status data are readout periodically according to the corresponding timer settings. The Hardware scanner, looks through the channels. When the time comes SC-code sends a request to the particular scanner to send a new set of data. This data is then sent to the D-Base Server. When the data is put to the data-bank SDB sends READY-message. The READY message should be resend to the Hardware scanner, permitting the buffer clear. A possible bottle-neck of the system is a throughput of the SDB. If it is busy, and there was no READY during predetermined time, the procedure must be repeated.

For SDB there are three types of parameters: single (magnetic field, atmospheric pressure etc.), table-parameters (HV, LV, and so on) and prehistory table-parameters (gas amplification, calibration drifts, temperature variation, etc.).

For a single parameter the record has a format: parameter name [A(32)]; parameter type [B]; time of measurement (seconds from 1.1.1970 00:00 GMT); parameter value, status code. For a table parameter type the record format looks as:

Table name A(32)

Table type UB

Measurement period in seconds UI

Parameter type UB

Number of records US

Parameter 1

Parameter 2


Parameter N

The parameter length in bytes is fixed by parameter type code

For prehistory table-parameters the record format:

Table name A(32)

Table type UB

Measurement period in seconds UI

Parameter type UB

Depth to the past (M) US

Number of records (N) US

Pointer to the next record US

V1,1, V1,2, ........, V1,M; V2,1, V2,2, ....., V2,M; ....., VN,1, VN,2, ....., VN,M.

Where Vi,j is a value of parameter i at measurement j. For index j (prehistory index) the buffer is cyclic. The pointer is an index for j, it shows where should me written the result of the next measurement. The type (length in bytes) of the Vi,j is defined by the parameter type code.

As the most part of parameters are changing slowly (or not changing at all) writing all this data may overflow the system with meaningless information. To minimize this data volume we may apply the technique used for the slow control on H1. The nominal value is updated to the measured value if the latter has significantly changed (see fig. 6). Monitoring of a slow control channel means a detection of a difference of the current measured value and the nominal value and comparison of the nominal value against the warning (dangerous) and absolute (alarm) limits.

|Xmeasured -Xnominal| > d (significant change condition)

If d =0, all changes are recorded. If d <0, all measurements are recorded (this may be done only for some tests, as the large amount of data will be recorded). When a significant change occurred without change of status one more record is added to the buffer. If the new measured value corresponds to a dangerous or alarm level an ALARM-message will be sent to the SC-code. There is a possibility to mask an ALARM for any measurement channel. The buffer is sent to the SDB in case of time-out, the buffer overflow, ALARM-condition or SC-code request (reasons of writing a record). Every record in this case has a header identifying the parameter, its type, time of measurement (seconds from 1.1.1970 00:00 GMT), a code of the reason of writing down (SC-request, buffer overflow or state change), number of subrecords in the record. The subrecords contain a channel number, state code and a measured value.

Figure 6.

The list of ALARM, which interrupt RUN automatically, will be fixed later by subsystem administrators. What should an operator on shift do, if the run was interrupted? It depends on the failure type. The computer can provide him with some hints, but the final decision is on his responsibility.

Log book

Any change of any parameter (even temporal) will be fixed automatically by the routine LogBook (electronic LogBook D-base). Any request from User Interface to DBS to make any change in CDB is copied by SC-code and send to the LogBook. The logbook structure requirements corresponds to the Table Based Data Base (herab/DAQ/soft.html docu.dvi).

User Interface


Table 2. Structure of the LogBook record (the record length is constant)
Data item
Date of changing
dd-mm-yy A(8)
Time of changing
hh:mm A(5)
Date of run start
dd-mm-yy A(8)
Time of run start
hh:mm A(5)
Type of run (see table 5)
BX-number (to fix correspondence for the future off-line data development)
Name of person on shift, who made the change of parameter
Parameter name
Value type (according to the "MIZZI Computer Software", p.2)
Old parameter value
New parameter value
(Some run parameters and what ever else?)

A double type for "old and new" parameter values will suit any parameter type and make all LogBook record equivalent by length.

Table 3. Error Logger record format
Field name
dd-mm-yy A(8)
hh:mm A(5)
Error type code
Error source name
Parameter name
Parameter type
Parameter value

Lengths of fields 8-10 are defined by parameter type field. The record format varies according to the error type code. A special precaution should be made against a mass error generation. This may overflow d-base.

Table 4. Error type codes
Error name
Level, Source name/Address
Source name/address
Sub-system is DEAD (no ALIVE-response)
Subsystem name
Packet delivery error
Source address, message type


The SC-code accepts messages from local codes (process) and from the Network. The network messages are tested for correctness and in case of mistakes, the correspondent record (sender address and message type) is sent to the Error logger. A special routine analyses these data periodically to find out "noisy" addresses. Then Local SC-codes analyses the type of message, check access privilege, if necessary (for this purposes one may use a special field, like "community"-field in SNMP-packets), and defines the address of the receiver. In this point the Local SC-codes can reference to the local address D-base. The name/address D-base (Name-server) contains object name, physical address of interfaces, its IP-address, processor number (for process) and for hardware objects "geographical" address (rack, crate, module etc.). In different contexts as an object may be used process, electronic module or control processor. The Name-server can convert name to address and vice versa. "Local" in this context supposes, that the object is in the same subsystem with control code.

Table 5. RUN type is determined by its name (from menu ?)
Data taking
Thresholds measurement
Pedestals measurement
Test (debugging)

Table 6. The list of SC-messages (CLASS=HBCOM_CLASS)
Message name Code Description
Initializes test and preparation procedures in subsystem (HV, thresholds, interlocks, etc.), from RUN-process to subsystem; rpm_send.
Starts subsystem clients (from MAIN SC; rpm_send). This message may be used before START_RUN, must be answered with READY (or NOT_READY).
Response to START_RUN, START_SC and CONFIGURE. Message from subsystem to RUN-process (rpm_reply)
Starts a run, sent from RUN-process to TRIGGER-system; rpm_send
Stops run. Message from RUN-process to TRIGGER-system.
From subsystem to RUN-process (carries the reason code);


Starts a configuration of a subsystem, sent by MAIN or local SC; (rpm_send). Subsystems must respond with READY or NOT_READY.
Subsystem sends to MAIN or local SC (name of parameter, its value, MIN/MAX-limits etc.); rpm_send.
Parameter value request (to CDB or SDB; rpm_stat)
An answer for GET-parameter request, returns the requested parameter values.
Request to change the parameter value (to CDB, needs access control and starts LogBook updating; rpm_ctl), must be answered with READY. The request is sent by User Interface.
Sent by SC-codes as an answer to the READY message after SET-parameter. The addressee is a hardware object. Must be acknowledged with READY
Message from a control process (analog of the NOT_READY message, sent by sub-process to the MAIN SC and Error logger)
Request from MAIN SC to subsystem to send a standard, report taken from the data of SDB, rpm_request. A request code and parameters are written in the message body. Possible parameters: subsystem name, parameter name etc.
An answer to a STATUS_REQ, is sent by D-base manager (SDB-server).
Request for some particular information from CDB, SDB, LogBook or Error-Logger to the SDB-server. Rpm_flood.
An answer to a REPORT_REQ, sent by D-base manager (SDB-server).
Masking some type of ALARM-messages for debugging purposes (needs access control and must be fixed in LogBook), sent by RUN-process to Local SC-codes; (rpm_send). May be used by the operator to continue RUN with dead sections of the detector. Must be acknowledged with a READY-message.
Request to test availability of process, subsystem etc. , must be acknowledged with ALIVE-message.
Reply to the request STILL_ALIVE
Fetches date from SC-codes to SDB-server. The data type and address is in the body of the message. Used for writing the data into the D-bases.
Request sent by SC-codes to the SDB-server. It must be answered with C_DATA-message, containing requesting data for the whole subsystem. If necessary several messages may be sent (?).
An answer of the SDB-server to the CONF-request of Local SC-code. Returns requested data from CDB.
An ALARM-acknowledgment (the sender is said, that message is not lost)
Request to the Name/Address Server to send the address of the named network object, is answered with a message ADDRESS
Date message from the Name/Address Server to the SC-codes, as a response to GET_ADR.
Request to the Name/Address Server to send name-code, is answered with NAME.
Reply to the request GET_NAME

The column code contains message-IDs. Many messages have a very simple structure, they are provided with only message-header and no body, e.g. READY, RUN, STOP_RUN, TIME-OUT, ALIVE. A READY must have a special message identifier which help to find correspondence between requests and replies (both have to have the same identifiers). The identifiers are generated arbitrarily, but they need not repeat (e.g. next may be equal previous+1). This is useful in case when a process sent e.g. START_RUN, START_SC and CONFIGURATION messages in sequence and needed to separate READY-responses.

There is a difference between NOT_READY and ALARM-messages. The NOT_READY comes as an answer for START_RUN, START_SC,...), but ALARM appears asynchronously or as a result of local scanning tests.

The UDP can not guarantee a data delivery, and a SET-parameter procedure must be checked with GET-parameter message. The acknowledge is needed and in a case of ALARM getting. Every time, when we need a reliable delivery, one must start a timer at sending a request or ALARM. At the time-out the procedure is to be repeated. So me need a reliable system of timers. No replay or acknowledgment must be acknowledged.

Restoration after failure

There are two types of possible failures:

In both cases if personal on duty is not sure of something, they may start corresponding diagnostics routing. The main results of the failure, any configuration changes and time of test routine running will be put down into the standard LogBook record.

Table 7. The structure of the Name/Address D-base record
Field name
Name of an object
Type of the object
Physical address of interface
Sub-processor ID
Process ID

* marks the cells for which a corresponding record field is available

Some messages carry only information on some event, the others are commands to fulfill some task or operation.

Table 8. STATUS-request codes (follow after subsystem-code)
Information type name Software


High voltage
Low voltage
Gas flow rate
Gas quality
Magnetic field

The format of STATUS-request message body looks like:

Subsystem_number, information_type_name.

General remarks


The messages to the SC-codes may come from any process in HERA-B installation.. The SC-codes accepts any message addressed it or any broadcast messages (multicast also) The real dispatcher response depends on a message code. The SC-codes can send messages itself. This can be done from an internal reason or because of time-out or as a consequence of external message. The SC-codes can address to any process in HERA-B or any hardware objects (e.g., START_RUNNING). It can send an multicasting-message (e.g., RESET, INIT etc.).

Name/address Server

The purpose of this routine is a process registration, translation of the object name (process, hardware system etc.) into a message containing a requested address information. A volume and structure of the data depends on a request parameter set. The data bank is stored on a disk, but the data fetched during the last N requests are put into a cash.

Error Logger

The routine is fixing any errors in the system (its type and total numbers, for some predetermined type of errors one must put the time of its occurrence). An error record is put into the D-base after a getting of an error message. The Data bank is stored on a disk with a backup copy on another physical disk. The backing up should be done regularly (at timer) if there are any changes. The routine should provide any data from Error Logger D-base (for the last hour, day, month, from-to, for an error code list, etc..


The routine fixes any changes introduced by an authorized operator from the main console into the HERA-B Configuration Data Base. The data bank is stored on a disk with a backup copy on another physical disk. It fetches a data on a request (according to a parameter list). It should provide a convenient access for the off-line data development routines (this should be fixed later).

DB-Server Interface

The code gets messages addressed it and carries out requested procedures (DB-upgrade, reporting, sending answer-messages) on the one of the HERA-B data bases (CDB, SDB, NDB (Name-server), LogBook, Error Logger). The type of procedure is defined by a request code and its parameters.

General requirements

Routines using some dynamic resources (e.g., memory buffers or disk memory) must be able to respond to the corresponding request and send a message containing a status information. In case of an overflow they have to send an ALARM-message to the SC-code.


List of Hardware SC-systems

Table 9. The list of subsystems with their ID (component.h + messdoc.dvi + "Protocols & Data Formats in HERA-B")
Subsystem number Subsystem name Sub-detector


DAQ Data Acquisition
SVD Silicon strips
ITR Inner tracker
HIPT High-Pt chambers
OTR Outer tracker
ECAL EM-calorimeter
MUON Muon tubes
MPIX Muon pixels
MPAD Muon pads
FLT 1st level trigger
SLT 2nd level trigger
FARM 3rd level trigger (Farm)
TARG Target

Figure 7. Packets encapsulation for rpm-messages

The message header contains fields: message length (excluding header), message type, destination address, source address, identifier and block identifier. The message type field has sub-field of message class (high order two bytes) and ID (for SC CLASS =HBCOM_CLASS=2). The message ID one may find in the table 6. The combination class/ID must be unique throughout HERA-B. For data representation the protocol XDR is used.

Table 10. List of rpm-message classes
Class name Class code

The data are taken from /hb/daq/Online_Library/pro/include.h. USER_CLASS serves for developing interfaces that haven't been assigned a value yet.

Address of ITEP Slow Control server is STORE.IN.RU/pub/herab

Abbreviation list (HERA-B)

ARP Address Resolution Protocol (STD-037, RFC-826)

BX Bunch crossing

CDB Configuration Data Base

CHAOT CHamber Analysis and On-line Tool

CORBA Common Object Request Broker Architecture

CRC Cycle Redundancy Check

DAQ Data Acquisition

DSP Digital Signal Processor

DTM Data Transfer Message

ECM Event Control Message

EDM Event Data Message system

EVB EVent Builder

FCS Fast Control System

FED Front End Driver

FLT First Level Trigger

GDS Gas Distribution System

GRR General eRRor

GUIF Graphical User Interface

HLT High Level Trigger

HVD High Voltage Distribution control

IDL Interface Definition Language

IP Internet Protocol (STD-05, RFC-791, -950, -919, -922, -1112)

MIB Management Information Base (STD-16,17, RFC-1155, -1212, -1213)

MDC Muon Detector Control system

MFM Means-End Model

MIB Management Information Base

MPI Message Passing Interface

OMA Object Management Architecture

PLC Programmable Logic Controller

PRC PRocess Control

PVM Parallel Virtual Machine

RPB Remote Procedure Buffer

RPI Remote Procedure Interface

RPM Remote Procedure Message

RTT Round Trip Time

SC Slow Control

SCM System Control Message

SCS Slow Control System

SDB Sorted Data Base; Status Data Base

SLB Second Level Buffer

SLT Second Level Trigger

SNMP Simple Network Management Protocol (STD-015, RFC-1157)


TACOS Target Control System

TCL Tool Command Language

TCP Transfer Control Protocol (STD-07, RFC-791, -950, -919, -922, -1112)

TLT Third Level Trigger

TRD Transition Radiation Detector

UDP User Defined Protocol (STD-06, RFC- 0768)

UI User Interface

XDR eXternal Data Representation (RFC-1832)

ZMP Zeus Message Passing