Consider the following example,

At one time, during run section 3358, the table 
on FIX is:
Tag Value
------ -----
PETS01 23.0
PETS02 23.2
PETS03 22.3
PELV01 5.1
PELV02 5.0
CNET01 33.1


At another time, during run section 3400 it is:
PETS01 23.1
PETS02 23.3
PETS03 22.0
PELV01 5.1
PELV02 5.0
CNET01 30.0


At begin Run we have the list of values for 
settings that fire off warnings or cause trips 
that looks like:


Tag "SID" Value 
--- ----- ----- 
PETS01 1 50 
PETS01 2 30 
PETS01 3 20 
PETS01 4 10 
PETS02 1 50 
PETS02 2 30 
PETS02 3 20 
PETS02 4 10 
PETS03 1 50 
PETS03 2 30 
PETS03 3 20 
PETS03 4 10 
PELV01 6 6 
PELV01 7 5.5 
PELV01 8 5.0 
PELV01 9 4.5 
PELV02 6 6 
PELV02 7 5.5 
PELV02 8 5.0 
PELV02 9 4.5 
CNET01 1 50 
CNET01 2 30 
CNET01 3 20 
CNET01 4 10 



We put the tolerance at begin run into a table:

It is not an error to enter unchanged values. It is of course less
efficient but filtering can be added later.

This table is filtered

MCSSettingHistory
=================
HID RunSection Tag SID Value
--- --------- --- --- -----
1 3323 PETS01 1 50
2 3323 PETS01 2 30
3 3323 PETS01 3 20
4 3323 PETS01 4 10
5 3323 PETS02 1 50
6 3323 PETS02 2 30
7 3323 PETS02 3 20
8 3323 PETS02 4 10
9 3323 PETS03 1 50
10 3323 PETS03 2 30
11 3323 PETS03 3 20
12 3323 PETS03 4 10
13 3323 PELV01 6 6
14 3323 PELV01 7 5.5
15 3323 PELV01 8 5.0
16 3323 PELV01 9 4.5
17 3323 PELV02 6 6
18 3323 PELV02 7 5.5
19 3323 PELV02 8 5.0
20 3323 PELV02 9 4.5
21 3323 CNET01 1 50
22 3323 CNET01 2 30
23 3323 CNET01 3 20 
24 3323 CNET01 4 10 
25 3333 PETS03 4 8
26 3353 PETS01 3 21 
27 3353 PETS02 2 31 


MCSMeasHistory
==============
MHID RunSection Tag SID Value
---- --------- --- --- -----
1 3358 PETS01 23
2 3358 PETS02 23
3 3358 PETS03 22
4 3358 PELV01 5.1
5 3358 PELV02 5.0
6 3358 CNET01 33
7 3400 PETS03 22.0


MCSErrorHistory
===============
1 3400 CNET01 30.0

To make it easy to pick up the online information quickly
and keep track of when this was last done. So any needed
updates are made to this table

CurrentSettings
---------------
ModRunSec Sensor SID Value 
--------- ------ --- -----
3323 PETS01 1 50 
3323 PETS01 2 30 
3353 PETS01 3 21 
3323 PETS01 4 10 
3323 PETS02 1 50 
3353 PETS02 2 31 
3323 PETS02 3 20 
3323 PETS02 4 10 
3323 PETS03 1 50 
3323 PETS03 2 30 
3323 PETS03 3 20 
3333 PETS03 4 8 
3323 PELV01 6 6 
3323 PELV01 7 5.5 
3323 PELV01 8 5.0 
3323 PELV01 9 4.5 
3323 PELV02 6 6 
3323 PELV02 7 5.5 
3323 PELV02 8 5.0 
3323 PELV02 9 4.5 
3323 CNET01 1 50 
3323 CNET01 2 30 
3323 CNET01 3 20 
3323 CNET01 4 10 

CurrentMeas
===========
ModRunSec Sensor SID Value 
--------- ------ --- -----
3358 PETS01 23.0
3358 PETS02 23.2
3358 PETS03 22.3
3358 PELV01 5.1
3358 PELV02 5.0

CurrentErr
==========
ModRunSec Sensor SID Value 
--------- ------ --- -----
3400 CNET01 33.1



Admin Tables
------------

Used in triggers for validation:
DetList
===============
Det
---
PLUG
CENT

Used in triggers for validation:
DetPos
================
Pos
---
E
W
NE
NW
SE
SW

Used in triggers for validation:
Never modify or delete rows.

SensorCharList
=================
Sid Sensor SettingType LimitType Action Resol Gran ReportGran
--- ------ ----------- --------- ------ ----- ---- ----------
1 Temp Severe Hi Shutoff 1 .1 2
2 Temp Severe Lo Shutoff 1 .1 2
3 Temp Warning Hi Message 1 .1 2
4 Temp Warning Lo Message 1 .1 2
5 Temp Report Null Passive 1 .1 2
6 Volt Shutoff Hi Shutoff .1 .05 .3
7 Volt Shutoff Lo Shutoff .1 .05 .3
8 Volt Warning Hi Message .1 .05 .3
9 Volt Warning Lo Message .1 .05 .3
10 Volt Report Null Passive .1 .05 .3

SensorTag
==================
SensorSeq TAG Sensor Pos Det Location
--------- ------ ------ --- ---- --------
1 PETS01 Temp E PLUG 01
2 PETS02 Temp E PLUG 02
3 PETS03 Temp E PLUG 03
4 PELV01 Volt E PLUG 01
5 PELV02 Volt E PLUG 02
6 CNET01 Temp NE CENT 01


Associates a group of channels to a sensor. This can be done by table
or by algorithm.

LogicIDTable
------------
LogID SensorSeq
00000 1
00000 4
00001 1
00001 4
00002 1
00002 4
...
00000 2
00000 5


Now we can to access the data by

Mcs.Cent.Temp(LogicalID)
which returns a structure

value, settings






Hi all

I have put some words to the example for the slow controls design.

Please make comments and tell me where I forgot what we had decided upon.

Also, if there are mistakes in my example, let me know.

cheers

rick

Goals of the Slow Control Design Interface to Oracle

====================================================

1. Access from AC++

-------------------

One goal of the design for the Slow Controls interface to Oracle is to

be able to import the tables as they exist directly from FIX into

Oracle and use administrative tables entered by GUI to arrange the

information so that it can be accessed easily from AC++ using a

syntax like

Mcs centralTemp=Mcs.Cent.Temp(LogicalID)

where Mcs is a structure containing the current value and settings that

are used for various alarm levels.

2. Viewing from the Web with a minimalist viewer (ie. the Brandeis page)

------------------------------------------------------------------------

Another goal is to be able to get rapid viewing of the data in some

standard configurations. Thus, the sensors need to be specified in terms

of subdetector, location and sensor within that location so that pull

down menus can be made allowing plotting of the sensors.

3. Viewing with DBANA

---------------------

Finally, detailed studies and correlations with other parts of the

Oracle Database can be custom made by writing DBANA macros.

 

Requirements

============

1. Tables of values from FIX will be put into a Current and History

listings.

2. There will be three kinds of values.

a. Settings for alarms

b. Sensor readings

c. Sensor Alarms

Thus, given the first requirement one has the following tables

a. Current Alarms

b. History of Alarms

c. Current Sensor Readings

d. History of Sensor Readings

e. Current Settings

f. History of Settings

3. For each sensor, the following quantities will be defined in order

to describe the various error reporting levels.

a. SettingType

This is the severity of the setting to be specified.

Severities include Report, Warning, Severe, and ShutOff

b. LimitType

Specifies if this is a hi or low (ie upper or lower) value.

c. Action

What to do when this occurs. This includes Shutoff, Message and

Passive.

d. Resolution

This gives the one-sigma value for the resolution of the device

e. Granularity

This gives the bit-accuracy of the device and must be less than

or equal to the resolution.

f. Report Granularity

This value determines the threshold for making an entry in

the history and updating current tables. It must be greater than

or equal to the Resolution. Thus, if a temperature changes by

an amount that is not really considered important, no update

occurs in the Oracle tables.

4. The Sensor Readings, settings and alarms are reported at the

beginning of each run. The report Granularity is ignored for this

case. Thus, at any time, the readings can be reconstructed by

searching the history table for a single run.

 

5. The settings are also taken at end run so that comparisons can be

made. The report Granularity is ignored here as well. In

principle, these settings should not be modified during a run. If

they were, the data quality organization should be notified.

6. Modifications to alarms in FIXX shall be sent to the Oracle database

when the modification is made.

7. The smallest time interval between recording consecutive slow control

reports is a run section. This is also the unit of time.

8. The Report Granularity is used to filter the Alarms and the Report

values. It is not used to filter any change in the settings for

Alarms All changes are kept in a history log.

 

Example

-------

In order to illustrate the structure of the database and how it

functions, the following example has been worked out. Ignornace of how

the settings can be sent to Oracle leaves an ambiguity in the design,

but this can be modified once it is understood how that works.

The current values are known to be conveyed from FIXX by a tag and a value.

 

 

The output of FIX

=================

Consider the following example. The run begins at run section 3323.

A where the FIX table is sent during run section 3358 and during run

section 3400. During Run Section 3333 a modification is made to one of

the alarms and during Run Section 3353 a second modification is made.

The table

At one time, during run section 3358, the table

on FIX is

Tag Value

------ -----

PETS01 23.0

PETS02 23.2

PETS03 22.3

PELV01 5.1

PELV02 5.0

CNET01 33.1

 

At another time, during run section 3400 it is

PETS01 23.1

PETS02 23.3

PETS03 22.0

PELV01 5.1

PELV02 5.0

CNET01 30.0

 

The begin run starts at Run Section 3323. We have the list of values for

settings that fire off warnings or cause trips that looks like the

following table. (note that it is not clear what FIX uses for the

"SID", so one has been "made up"). The SID is listed in a set of tables

below that describes the sensor as described in Requirement 3.

 

Tag "SID" Value

--- ----- -----

PETS01 1 50

PETS01 2 30

PETS01 3 20

PETS01 4 10

PETS02 1 50

PETS02 2 30

PETS02 3 20

PETS02 4 10

PETS03 1 50

PETS03 2 30

PETS03 3 20

PETS03 4 10

PELV01 6 6

PELV01 7 5.5

PELV01 8 5.0

PELV01 9 4.5

PELV02 6 6

PELV02 7 5.5

PELV02 8 5.0

PELV02 9 4.5

CNET01 1 50

CNET01 2 30

CNET01 3 20

CNET01 4 10

 

We put the tolerance at begin run into a table. This table is filtered,

except at begin and end run. Hence the first time, all settings in the table

of settings sent from FIX are entered and have a run section 3323.

MCSSettingHistory

=================

HID RunSection Tag SID Value

--- --------- --- --- -----

1 3323 PETS01 1 50

2 3323 PETS01 2 30

3 3323 PETS01 3 20

4 3323 PETS01 4 10

5 3323 PETS02 1 50

6 3323 PETS02 2 30

7 3323 PETS02 3 20

8 3323 PETS02 4 10

9 3323 PETS03 1 50

10 3323 PETS03 2 30

11 3323 PETS03 3 20

12 3323 PETS03 4 10

13 3323 PELV01 6 6

14 3323 PELV01 7 5.5

15 3323 PELV01 8 5.0

16 3323 PELV01 9 4.5

17 3323 PELV02 6 6

18 3323 PELV02 7 5.5

19 3323 PELV02 8 5.0

20 3323 PELV02 9 4.5

21 3323 CNET01 1 50

22 3323 CNET01 2 30

23 3323 CNET01 3 20

24 3323 CNET01 4 10

25 3333 PETS03 4 8

26 3353 PETS01 3 21

27 3353 PETS02 2 31

 

The measurement history is modified according to the Report Granularity

for the sensor. The Administrative tables in the next section indicate

if an update is to be made. Note for example that no update of PETS01 was

made during run section 3400 because although the value changed from 23

to 23.1, this is below the Report Granularity. However, PETS03 changed from

22.3 to 22. It has a report Granularity of 0.3 so it was reported.

CENT01 is in error so it is not in the MCSMeasHistory table, but in the

ErrorHistory. It remains in error in run section 3400 and is reported

again because the change is greater than the report granularity of 2.

 

MCSMeasHistory

==============

MHID RunSection Tag Value

---- --------- --- -----

1 3358 PETS01 23

2 3358 PETS02 23

3 3358 PETS03 22

4 3358 PELV01 5.1

5 3358 PELV02 5.0

6 3400 PETS03 22.0

 

MCSErrorHistory

===============

1 3358 CNET01 33

2 3400 CNET01 30.0

To make it easy to pick up the online information quickly

and keep track of when this was last done. So any needed

updates are made to this table

CurrentSettings

---------------

ModRunSec Sensor SID Value

--------- ------ --- -----

3323 PETS01 1 50

3323 PETS01 2 30

3353 PETS01 3 21

3323 PETS01 4 10

3323 PETS02 1 50

3353 PETS02 2 31

3323 PETS02 3 20

3323 PETS02 4 10

3323 PETS03 1 50

3323 PETS03 2 30

3323 PETS03 3 20

3333 PETS03 4 8

3323 PELV01 6 6

3323 PELV01 7 5.5

3323 PELV01 8 5.0

3323 PELV01 9 4.5

3323 PELV02 6 6

3323 PELV02 7 5.5

3323 PELV02 8 5.0

3323 PELV02 9 4.5

3323 CNET01 1 50

3323 CNET01 2 30

3323 CNET01 3 20

3323 CNET01 4 10

CurrentMeas

===========

ModRunSec Sensor SID Value

--------- ------ --- -----

3358 PETS01 23.0

3358 PETS02 23.2

3358 PETS03 22.3

3358 PELV01 5.1

3358 PELV02 5.0

CurrentErr

==========

ModRunSec Sensor SID Value

--------- ------ --- -----

3400 CNET01 30.0

 

 

Admin Tables

------------

The admin tables are used to keep track of the kinds of sensors, the

various tags expected from oracle as well as some lists of valid entries

that can be used to check for typos or signal unknown entities. Hence a

list of all valid detectors and positions of detectors is kept.

The admin tables also provide a way to automate the minimalist display

program, allowing an interrogation of the database to yield the various

detectors, their positions and their locations within the positions. The

admin tables can then be used to translate this to a sensor tag and

hence allow the values to be fetched as a function of run section.

The tables are as follows

Used in triggers for validation of entries.

DetList

===============

Det

---

PLUG

CENT

Used in triggers for validation of entries

DetPos

================

Pos

---

E

W

NE

NW

SE

SW

The list of sensors is also given. There may be different kinds

of temperature sensors that get different resolution and granularity so

the sensor ID changes. If these values are modified, then a new sensor

id must be assigned so that data that were already taken under the old

conditions can be interpreted.

Used in triggers for validation

Never modify or delete rows.

SensorCharList

=================

Sid Sensor SettingType LimitType Action Resol Gran ReportGran

--- ------ ----------- --------- ------ ----- ---- ----------

1 Temp Severe Hi Shutoff 1 .1 2

2 Temp Severe Lo Shutoff 1 .1 2

3 Temp Warning Hi Message 1 .1 2

4 Temp Warning Lo Message 1 .1 2

5 Temp Report Null Passive 1 .1 2

6 Volt Shutoff Hi Shutoff .1 .05 .3

7 Volt Shutoff Lo Shutoff .1 .05 .3

8 Volt Warning Hi Message .1 .05 .3

9 Volt Warning Lo Message .1 .05 .3

10 Volt Report Null Passive .1 .05 .3

While a naming convention takes care of the information contained in the

sensor tag, it is also useful to keep an interpretative table that breaks

the fields down into the position, detector and location.

SensorTag

==================

SensorSeq TAG Sensor Pos Det Location

--------- ------ ------ --- ---- --------

1 PETS01 Temp E PLUG 01

2 PETS02 Temp E PLUG 02

3 PETS03 Temp E PLUG 03

4 PELV01 Volt E PLUG 01

5 PELV02 Volt E PLUG 02

6 CNET01 Temp NE CENT 01

 

Finally, the sensors need to be related to the logical ids in CDF4152.

This can be done by a mapping function or by a table that

associates a group of channels to a sensor. A table might look like

the following.

LogicIDTable

------------

LogID SensorSeq

00000 1

00000 4

00001 1

00001 4

00002 1

00002 4

...

00000 2

00000 5

 

Now we can to access the data by

Mcs.Cent.Temp(LogicalID)

which returns a structure

value, settings