/Net/www1/CERN_WWW/CERN/Divisions/ECP/PT/PINS/Cortex.html

The CORTEX Project

J.M.Le Goff, ECP/PT

Goals

The goal of Cortex is to design and build a system which allows control systems to share information, control and analysis functions; which presents a uniform human interface; which permits upgrades and additions without code modification; and which is sufficiently generic to allow its use by most of the existing or future control systems at CERN.

It is important to emphasize that Cortex does *not* attempt to do the direct *data acquisition* or *control* of devices - these are activities which are highly specific to the application, and are best done by commercial systems or user-written programs. It is the purpose of Cortex to *integrate* these application-specific pieces and *support* them by suppling commonly needed facilities such as display, analysis, diagnosis and archiving. Cortex is a *framework* for building a system - it provides the pieces, you put them together (see the Cortex facilities document).

Cortex does not exist today. Our priorities for development follow the needs at CERN as we understand them:

1. Information Sharing:
Sharing of individual sensor data, aggregate data (sum averages, gradients) and user-calculated values, standard-graphic based display for monitoring all parameters
2. Service Sharing:
Request actions of other detectors or services, publish operations which your controller will perform for others, analyse requests for undesirable effects before execution, standard method for issuing control commands
3. Configuration consistency & problem diagnosis:
User-specified display configuration, user-specified operators and authorizations, configuration consistency checking;
4. Other analysis:
On-line event analysis, what-if analysis, maintenance analysis
5. Data archiving & retrieval:
Record data values, view by date, time, type, event, device, controller or level; view different granularities of time, user-configurable; search for specific events or data values.

Architecture

Cortex has a hierarchical architecture based on the industry-standard Computer Integrated Manufacturing (CIM) model. A full system based on Cortex has four *levels*; each level consists of one or more *controllers*.

Cortex software typically only runs on levels 2, 3 and 4. A cortex controller consists of a run-time data base (called the *engine*) and one or more *components* which use it. The engine contains the descriptions of the devices and the services managed by the controller. The engine is responsible for the distribution of shared data, the routing of requests for shared services,maintenance of the decision hierarchy, and any other intra- and inter-controller communication.

The various components are :

Acquisition:
the acquisition component reads information from the sensors and feeds it to the engine; for instance, the acquisition component for the water system might read the temperatures in the cooling shield for the magnet and pass them to the engine for distribution to another component (e.g. analysis), or for distribution to other controllers (e.g. the magnet controller)
Control:
the control component accepts requests from the engine and translates them into actions for a given device. For example, the magnet controller may request that the water system control component increase the flow of water to the cooling shield,because the temperature in the shield is too high.
The acquisition and control components are typically programs provided by the user which read and control the devices for which the user is responsible.One program (e.g. a commercial system) may handle both functions.
Analysis:
analysis components make decisions or provide diagnosis. For instance, after receiving the water temperatures of the cooling shield, the magnet controller may invoke ananalysis component to decide if it is too hot.
Archiving:
archiving components record significant events (the event log) and optionally data values (data archiving).
Human Interface:
human interface components allow a human user to inspect the sensors in the system, and operate(send commands or request changes) controllable devices.
A controller need not have all components, and may have several components of one type (several analysis components, for example). The minimum controller contains no components, though this is an unlikely configuration. A reasonable minimum configuration would include acquisition, control, and event log components.

Information Sharing

Your program can send information about your service or detector, or your part of a service or detector, to other programs running on other machines and even other operating systems. Conversely, your program can also receive information from other programs. For example, the water system programs could make the cooling shield temperatures available to the magnet control programs, or the gas system can make leak information and flow rates available to the high-voltage system for the muon detector.

Service Sharing

Your program can make functions available to other programs, running on other machines and even other operating systems. For instance, the high voltage control system could make a shutdown function available to the gas system. The gas system would request this function if it detected a serious leak;or(more likely) both systems would make information and control functions available to a supervisor process which would integrate information from both and then take the appropriate actions. Either scenario is possible with Cortex.

Analysis Tools

Update analysis responds to events which cannot be changed or reversed: changes in temperature, fire, component failures, etc. It determines the consequences of the event, and then either recommends actions to theoperator or initiates actions itself. Update Analysis typically occurs in response to an Update message (hence the name) when the message modifies an operational status or changes the alarm level.

Request analysis is identical to Update analysis, except that it determines the consequence of a change beforethe change has occurred. Thus the requester of the change (or the analysis) canrefuse to act if the analysis detects a problem. For instance, if the magnet system operator wants to shutdown the magnet, a request analysis on that action will tell him if it will cause any problems with the other services and detectors in the experiment. Note that the result of the analysis willnot prevent him from shutting down the magnet. If there is urgent reason, he may proceed even if theirare undesirable consequences.

What-If analysis is similar to Request analysis, except that no action is taken. The requester of the analysis simply receives a confirmation that the intended request is allowed, or a explanation of why it is not allowed.

On-Line Diagnosis helps the operator analyse "what happened". Alarms may cause other alarms which may then trigger several more still . To make sense of a cascade of red lights, on-line diagnosis helps the operator to determine the root cause of a problem.

Off-Line Diagnosis is the same as on-line, except that the diagnosis occurs well after the fact, and it uses the archive data, not the on-line database. Typically the time period under examination is longer as well.

Maintenance analysis monitors events to detect problems (hopefully) before they occur. For instance, if it detects an abnormal number of failures of a disk drive, or frequent anomalous readings from a sensor, it would alert the operator to the fact and recommend diagnosis or replacement.

Consistency analysis tries to ensure that the experiment set-up is valid. It checks the data the user enters while configuring the system, validating individual entries (local consistency) and avoiding undesirable interdependencies between system entities (global consistency). This analysis is required while defining the equipment (devices), the set-up (desired parameters), and the control system (controllers and communication). This analysis is only able to check the static properties of the configuration, not to predict run-time conflicts.

Archiving & Retrieval

This section summarises the features of both, but otherwise only describes how to use the recording functions. For information on the retrieval functions, read "Cortex Archive User Manual" (in preparation) .

The Cortex archive facility allows you to:

The user may specify: The Archive facility:

Savings

Based on our surveys, we believe that the use of Cortex and commercial systems will cut the development time and manpower requirements for new control systems by about 50%.