A Distributed System for Data collection on a Blast Furnace

RO UN D- TAB LE DISCUSSION LOCAL APPLICATIONS OF DCCS

Copyright C IFAC Distribu ted Compute r Con trol Systems 1983 Sabi -Sabi , South Africa , 1983

A DISTRIBUTED SYSTEM FOR DATA COLLECTION ON A BLAST FURNACE P. G. Stephens* and D.

J. McDonald**

*Automation DepaTtment , South AfTican Iron and Steel COTpOTall'On Ltd, P, O , Box 2, Newcastle, South AfTica * *Datalogic (Pty) Ltd, P,O, Box 5482, W elt evreden Park , 1715, South Africa

AcknOl'il ed,]ef11ent The authors acknOliledse ~iitr thanks the pemission to publish this paper granted by the ~ana~e~ent of The South African Iron and Steel Corporation (ISC eR ) • Abstract This paper describes a data collection syste~ installed at the ~unber 5 81ast Furnace at Iscor's !!elolcastle I:orks. He paper revievls the operational and investigational requirer.ents leading up to the decision to install the data collection syster. on an existing plant v:hich already has a cor.puter system installed. The syster. architecture is describe c' . /\ pOlolerful r.ini-computer is the nucleus of the Cen tral System. Three r. icroprocessorbased scanner systems capture real-tine process data fro~ existin ,] transducer equipr:;ent, and transmit thi s data to the central syster.. T~IO I~icroprocessor-based data entry stations are located in laboratory facilities near the blast furnace. A "workstation" cor;;puter provides the resource required for in-depth studies of plant behaviour. The workstation, data entry statiens and scanners are all connectec to the central syste~J via a sin ~ le c.ulti-drep serial highl'lay. Softl'iare for the systen is based on the r.anufacturer's standard operating system and network control package. A standard cor.lr.:ercial database ma na sement systeT'l, with its associated enquiry package, is used to provice the historical database facility and many of the standard r.anagement re ports. Keywords Cistributed syster. s; precess data collection; process centrel; database; local net''io rks.

I nEODlICT! c::

historic~l

Tf'E EX I 5T [f iC SYSTEt

The ISC eR Newcastle Numhe r 5 81ast Furnace I"as cODmissi oned during Cecerlber 1976. The furnace has a hearth ~ianeter of 10. 8 metres and is conveyor-charged via a be ll-less to p of Paul Wurth design.

Existins Process Control Equipment The process control equipr;;ent installed on t he furnace and stock house is of mo dern design and utilises a FOX 2/30 cor.puter Syster. for everall Supervision, Control, Da ta collection and Logging. C escri~tions ef the Supervisory and Control aspect of the system are outside the scope of this paper; however, the Cata collection and Logsing system is of relevance so a brief de scri ption of eacr syster. follows.

In full production the furnace is capable of producing in excess of 104 oeo Tons of liquid iron per r.:onth during which period appoxir.ately 240 ODe Tons of Eurden r.1aterials are charged to the furnace fro m the stockhouse. 159

P.C. Stephens and D.J. McDonald

160

Data collection. Data is captured from the following plant areas +

Stock house (Weighing equipment, Coke moisture gauges etc.)

+

Blast furnace top (Weighing equipment, Material gate and chute)

+

General plant area (approximately 250 points of process variables, temperature, pressure and flow)

+

Control room (Operator entered process reports etc.)

Logging. Due to the limited amount of bulk storage available for data archiving, (approxi~ately 500 kS) the long tern storage of process data is limit~d to those values required for the production of averages and totals. Instantaneous values or sub-hourly averages a re either reduced to hard copy forr.; or discarded. The following types of reports are produced:+

Demand Reports (These are produced on operator request)

+

Event Driven Reports (These are autoniatically produced as tl:e result of a specific event, eg Furnace Charging)

+

Time Dependent Reports (These reports are produced on a scheduled basis - hourly, per-shift, daily etc. The data contained in this type of report consists of averages or totals.)

In general the data used to produce the various reports is discarded imr.~ediately upon the production of the hard copy or is limited to one backup copy in bulk memory (previous hour, previous shift, etc.)

as the ability to produce the required quantity of Iron (Tons/Day) at an acceptable quality (correct metallurgical properties and temperature) at the lowest cost. The reports outlined above provide the input data for this critical management objective. Under the existing system this data is manipulated manually using certain well established criteria, the results produced being interpreted by production management to provide the necessary remedial process adjustments. The procedures necessary to obtain the results required by management are slow and labour intensive and thus prone to error. In addition, investigations which involve time-related phenomena are difficult to conduct due to problems with the synchronisation of the various data items. Despite the difficulties outlined above much progress in the optimisation of the furnace operation has been possible. The current ~orld-wide recession within the steel market coupled with the rapidly increasing cost of raw materials has led to a more scientific approach to iron-making practice, this in turn has led to a rapid increase in the nureber of process variables used in the optimisation procedure (a total of 450 required in the case of Nu~ber 5 ~last Furnace) with the process variables being scanned at a much higher frequency. Fror.1 the above discussion it can be seen that a new approach to the problems associated with the collection, archiving and processing of data was necessary to provide solutions to the proble~s present in the existing system ~Ihile at the same time coping with the increased nu~ber of process variables. An additional requirement is to allow the on-line automatic generation of many of the management reports which are currently produced under the existing system. These require~ents led to the equipment configuration that fo~s the system described in this paper. THE NU! DATA COLLECTICN SYSTU:

Other reports. To co~plete the survey of the reports used in the ~anager.~nt of the furnace, mention ~ust be made of associated data, which because of Hardware and Software limitations present at the time of system comnissioning could not be incorporated into the FOX 2/30 system: +

Burden material analysis reports

+

Sinter Plant

infor~ation

After a careful analysis of all current and anticipated future requirements, the following parameters were established as being functionally important in the design of the new system:+

All data required for the generation of normal management reports to be available on-line on a fast access device.

+

Historical archivin9 of all the data collected by the syster;l shoul d be possible.

+

As investigations of a "research" nature would be undertaken from ti~e to to time,

Cptimisation of Furnace Production Optimum furnace production can be described

Data Collection on a Blast Furna ce

the syste~ must be capable of supporting this activity (if necessary do~m to the sensor level) without disruption of the normal data collection functions. +

A sufficient level of data protection must exist, to allow relatively unskilled users access to the process data, without cor.lpronising the validity of the data or the continued operation of the data collection system.

+

The system should be capable of expansion by at least 100% to meet future needs.

+

The syste~ must be capable of supporting the activities of several concurrent 'background' users.

+

+

As far as possible, the manufacturer's software ~ust be used in the implementation of the systeM, thus reducing the maintenance requirements and the costs involved in the provision of purpose written material. The hardware configuration, particularly in the scanner area, must require the ninimur level of maintenance and, if possible, utilise a relay-less type of multi p1exer.

From an examination of the above criteria together with a study of the plant geosraphy the following system characteristics became evi dent. +

The system should be distributed, thus cininising cabling and installation costs. This route is also seen as providing two other benifits, increased and a modular system through-put ex pansior. capability for future development needs.

+

That a Data Case approach should be used to solve the proble ~ s associated with data access an d archiving, this would al so pe m it tile use of a Query type report generator for the production of many of the ~a na s e~ent re ports, thus re ducin g software costs an d maintenance proD 1er.:s.

+

That a "workstation" equi~ped with t he necessary gra r hics ar: d plottin g capabilities be incorporated into the systerl to allo~1 the facil ities re quired for "research" and t o buffer users fro r. the ccntr0l system.

Proceeding fro ~ the outline of the bac kgroun d to the currer:t pr oject, we can su:::r..arise t he essential features of the nCh' system as follows:+

Process data ac quisition fror: sensors, includin s cer.version to en s ineerin s units, alarm checking and so on.

161

+

Analytical data entry, manual and automatic, from other computer based systems.

+

~istorical

+

Generation of management reports, scheduled and on demand.

+

Support for investigations into plant behaviour.

database management.

These features are distributed functionally and geographically across a network of seven cor:;puters. f~ ARDI.JARE

We'll look at the hardware arrangement fi rs t. ~!etwork

The network is topologically about as simple as it could be, consisting of a sin gle serial data link, arranged essentially in a straight line, daisy-chain fashion. Figure 1 shows this diagranr.;atically. In this figure we see the names of the seven computer system ncdes, as well as a rough indication of the distances involved. The central and workstation systems are in a computer room located near the main blast furnace control roo ~ , and adjacent to the existing FOX 2/30 computer. The control-roor. scanner is in a cable marshallin s and instrument rack roo ~ one floor down fr or t he central system. The two on-furnace scanners are housed in a room built directly on the furnace structure itself, at t he ~ ain operatin g level. Data entry station nur,1ber one is in the Coal and Cok e laboratory, and data entry station number two is in the Sinter plant control roar:. Distances are in netres. The link is physic ally a full duplex serial sync hronous li ne rvnnin g over twin twi sted pair lines at SE kil oba ud, usin g [, EC's DDC' P protocol. All the li ne interfaces are r:i croprocessor-based or!' type devi ces, wi th the data-link layer protocol ranagement (CDO:P ) handled by the interface, thus relievin s the individual node conputers of this t edious task. The interfaces used are C': ,Pll and Ct:Vll devic es ~Ii th inte s ral ~ odem s, and are tr a nsfor ~er cou pled to t~e li ne, which should eli r:: inate any ground conflict r ro bler::s. Sc anners The three scanners are al r::ost i dentical, differing only in the nur::ber of actual pr ocess I/O points ir.pler.ented. Each sc anner i s based aroun d the LSl11/23 processor with optior:al floatins point firr;ware chi p. 256 kilohytes of ~~ OS memor~'

P.G. Stephens and D.J. McDonald

162

+---------+ +-------------+ : Central : : system

: Graphics : : workstation :

:

+---------+ +-------------+ /\

I I I

50

/

I

800

5

sco

I I I I

/\

5

\/

\ 400

\/

\

/

\/

+---------+ +---------+ +---------+ +------------+ +------------+ : Scanner : Scanner Scanner Date entry Date entry no 1 : no :: no 3 nUTTlber 1 nunber 2 +---------+ +---------+ +---------+ +------------+ +------------+ I I I I

I I I I

I I

I I

I I I I

I I I I

I I I I

Figure 1 Neblork topology and line distances (metres)

+-----------+ : LSI 11/23 :

+-----------+

+------------+ +-------+ : 256 kB

nos :

: Or'W11 : ---->

+------------+ +-------+

~~ etvlOrk

I I

I I

<============================================================>

+------------------------+ I I

DL Vll-J

+------------------------+ +-----------+ +---------+ : TU5E Tape:

: Console:

+-----------+ +---------+

+---------+ : Crystal : clock

+-------+ : rRV11 :

+---------+

+-------+

+-------------------+

: Analogic fNDS5400 :

+-------------------+ Plant sensors

Fisure 2 Scanner subsyster. - hardware block diagram

I I I I

163

Data Collection on a Blast Furna ce

\lith 2 hour battery r.ackur, l1-port serial interface board, network interface, process I/O interface, and bootstrap card ~ake up the card co~plement. Process I/O interface ec;uipr:ent is the Anclosic 1\!!['S 5400 product, with the control reom scanner having mainly r:igh-level 0-1 e volt inruts from existing SPEC 2r~ sear, and the two on-furnace scanners havin ~ priMarily Type ~ thernocouple inputs, with a few contact inputs and a fell 4-20 mP. current loop inflL;ts. Figure 2 shows the arrangement. Each conputer has a dual TU5E tape cartri~se drive for local bootins of diagnostics, and provision for connecting a console ter~ inal, though no console is present during norMal operation. The scanners arc housed individually in sealed steel cabinets, the on-furnace scanners being fitted with closed cicuit heat exc~an r ers and pur~ed with air.

for online prograr. development. In the r:1ain control rOOr:1, two colour semi-sraphics units an d a 1:0 cps printer provide the operator interface to the system. t~etl'! ork interface is a r.:~P ll. Sinple asynd:ronous links are provided to the FOX 2/30 co~puter and an x- ray spectro g rapl ~ . Powe r Supply

A IS kVA cotor generator set supplies 50 Hz power to the central, wor~station, and scanner syster.;s.

S O FT\~ Ar : E

Software SUI;:r.ary Turning now to the software, we can start by listin g in rat~Er More ~etail the functions which are to be supported. +

Acc;uisition of process ~ata from sensors, including sensor validity checks (eg open therrocouple), conversion to engineering units, linearisation, filterins, alarm checking against several li~its and gatrering of statistics such as maximum, rini~uM, avera £e and so on.

+

ForMatting of three-ninute 'snap-shots' of the plant for storage in He historical database.

+

Perforrling of 'investigational scanning' of small subsets of t~e plant sensors, for special purpose investi gations

+

fI.cqu is it i on of chargi no da ta fro : the FOX 2/30 computer for storage in the historical database.

It. ;s expected that the rata entry syster.l nur.:bu one wi 11 have a s[;.all (1O-2 CI:byte) winchester disk added soon.

+

Acc;uisition of analysis data froe the Philips X-ray spectrograph for storage in the ~istorical database.

Craphics Work Station

+

Acr,uisition of analysis and operational data from personnel in three distinct geographical areas.

+

Provision of process displays, with real ti~e update, to operators in main control roof".

+

Production of corplex performance parareters, with rr,onitoring against alam levels and stora ge in historical database.

+

~ ; anagement

+

Production of regular ~anagem€nt rerorts of plant performance and production monthly, daily, shift etc.

~ata

Entry Stations

The two data entry stations are identical, and very si~ilar to the scanner systems. The Main differences here are +

Console VDU terr;:i na 1 perranent 1y installed

+

Syste~

is ~ounted in a small ca binet slung under a desk, much like the drawers on a standard office cesk

+

No process I/ C

+

~o

battery backup

This

syster (figure 3) is built around a 11/24. It includes 2SF kilobytes ~OS rer.:o ry, a 10.4 i.byte reMova ble cartridge disk, 180 cps console printer, vru terminal, TEKTr O~ IX 4C12 graphics VDU , and TE~TRO ~ I X 4662 plotter. ~;etvlCrk interface is a [;~ < Pll. pep

Central Systerc The nucleus of the central system (fig. 4) is a PlP 11/~4 ~itr: FPl1 floating point unit, fitted l'Ii th 512 kilobytes of ~:OS r:1er~ory with battery backup. Two 10.4 r:byte remova ble cartridge disks, two 160 ~byte (logically four 67 Mbyte) winchester disks and two half-inch reel-to-reel tape r.rives make up the bulk memory. The two winchester disks and two tape drives are intended to operate in a 'cold standby' node. f, 180 cps console printer and three VDU terminals are provided PCC-,~ ·

of 'archive' data, including automatic spooling to tape, deletion of outdated infornation from or.line database, and subsequent retrieval of archived data for investiQational purposes.

P.G. Stephens and D.J. McDonald

164

+---------+ +------+

+--------+ +-----------+ +-----------+

+---------+ +------+

+--------+ +-----------+ +-----------+

: LA120 : : console :

: TU58 : : tape :

: CIn01 : : Tektronix : : Tektronix : vdu : 4012 : : 4662 :

I

I

I

I

I I

I I

I

+-------------------+

+------------------------------------+

+-------------------+

+------------------------------------+

: 11/24 with KEF11

:

I I

DZ11

<============================================================> I I I I

I I I

,

+------------+

+--------+

+-------+

: 256 kB HOS :

: 10.4MB : : disk :

+-------+

:

MeMory

:

+--------+

+------------+

: Dt' Pll : --->

~~etwork

Figure 3 Graphics workstation block diagrar.

+------------+ +-----------+ +--------+ +--------+ +---------+ : 512 kB Mos : : 2x10.4 ~~ B : : 160 r'1B : : 160 r~B : : Crystal di sk s : : di sk : : di sk : : clock : memory :

+------------+ +-----------+ +--------+ +--------+ +---------+ I

,

I

,

"

<============================================================> ,, ,, , ,, I

I

,

I

I

I I

, , , +--------+ , +--------+ +------+ +------+ +-----------+ : POP 11/44 : : 45 i ps : , : 45 ips : : DZll : : DUI : : with FPll : , : tape : , : tape : +--- --+ +------+ ,, +--------- -+ ,, +--------+ : +--------+ ,, , ,, , , Spectro!)raph ,

,

I

I I

I

I

I

I

I

I

I

I

I

+------+

: +-------+

: +----------+

: TU58 : : tape :

\-: Ol":P11 :

\-: Colour: : graphics :

\ +--------+

+----------+

, +--------+

+-------+ ,

+------+

,,

I

/

~Jetwork

+---------+

\

,: C!T101 : : vdu's:

\

+----------+

: LA120 : : console :

: FOX 2/30 :

+----------+

+---------+

Figure 4 Central Syster. block

diagra~

Data Colle c ti on on a Bl a st Furn ace

+

Production of ad hoc reports on a once off basis with wide flexibility in selection of report contents.

+

Comprehensive support for detailed statistical analysis of plant behaviour modelling.

+

Support for on-line progra~ development with minimal impact on 'foreground' activities.

From these requirements, together with the geographical constraints, we drew up a data flow diagram, figure 2.5. This diasram concentrates on data entities, whic~ r.ay be items of hardware eg a printer, or a file or table in memory or on disk, and the directions of flow of data (the broad arrows) and control (the single lines). Interposed between the data entities are blocks representing coherent or closely re1atec processing steps. A block does not in general correspond to a task or progra~, though it may do so in a few cases. Rather, the 'inner' blocks are processing subsystems, with clearly defined interfaces and functions. Having said that, it is true t~at the structure of this data flow diagram does in practice tend to have an influence on the subsequent decomposition into tasks or programs. It is obviously very important that t~is data flow structure be carefully thought through, as it forns t~e foundation for the suhsequent refinement of the software design . As tilis workshop is all about distributed computer systems, it is appropriate to concentrate on those parts of the software which are i n some sense distributed. This will have to excuse what may seem at times to be 'glossing over' otherwise important parts of the software stucture. Operating System Software All the systems are based on CEC's RSXll V4. Systems with disks naturally use PSXll-r~, w~i1e those without disks use the stand-alone version, RSXll-S. tJetwork software is CECNET-ll, whic~ provides a rich set of task to task, task to remote file, and operator to remote file capabilities, both point to point and routed. Programming languages are Fortran 77 and POPll macro assembler. The OBMS used is TOTAL, by CINCOM Systems. TOTAL was chosen because it has adequate functionality, including a friendly query package, is a mature product on POPll, is acceptably priced and has local representation. The graphics workstation has, in addition to these, BASIC Plus 2, which is a powerful BASIC language compiler, and PLOT-lO, the Tektronix graphics support package.

165

Scanners Scanner software falls clearly into two parts, the routine data acquisistion and everytbins related to it, and the investigationa1 sca nning. The primary scan task itself is a table driven generalised scanner which has no specific application data such as ADC gains, point names and addresses and so on. It is linked to a system gloha1 area (RSX resident cor.~on) where all the tables are located. Para~eterisation of the task to a particular set of process points requires the production of 'point definition' statements in a text file in the general form = ; in a relatively free format fashion. These def i niti ons are translated, ass er.b1ed, and task-built to produce the scan tables. This approach means that all three scanner computers have software which is essentially identical except for the pOint definition tables. A1ann r.lessages are pri nted by sendi ng a data packet describing the message to a separate task, so that the scan task itself does not get tangled up in terminal I/O. In this particular project, the scan task and the alarm printin g task are in different cor.puters, t he data packets hein g sent across the network link. There are thus three scan tasks cara b1e of generating alarm messa ges, and one ala rm printing task in the central system. Process current values are held in a section of the system gl oba 1 area, I'/here they are accessible to the task responsible for the gathering of the three-minute 'snapshot' frames . This task picks up the current value, minimur. , ma x imu ~ , and avera ge for the preceding period, as t~ey have reen generated by the scan task, ccpies them to a buffer in a110cata b1e mer.ory (RSX create region) and clears t~e statistics counters. It then atter.pts to transmit this buffer to the central syste~. If the line is down for any reason, these buffers \,i11 accumu1 ate in memory until the line is up again, or until allocatab1e ri.er.~ ory is exhausted. If ri.emory is full, as determined by failure of the attempt to create a new buffer, the oldest buffer currently in meri.ory will be overwritten. ~hen the line does eventually recover , all queued buffers \~i11 be transmitted to the central system as fast as they can be accepted. The investigationa1 scannin g task is much simpler than the main process scanning task. It receives from the central system a table defining a number of point addresses, the number of readings to take on each, and the rate at which to take these readings . A grand total of 1000 readings on all points together has been identified as adequate for this function. The buffer containing the

166

P.G. Stephens and D.J. McDonald

+---------+ +--------+ +--------+ Furnace :<====>: DECnet :<=======>

+--------+

1

1

<====>:

+---------+ +--------+ . ·.....................................

1 1

Process Data Buffer

1 1

+----------+

+---------+ +--------+ : Furnace :<====>: DECnet :<=======>

11

DECnet

: Bottom: : -llS : : Scanner :<---->: FURBOT :<------->

-lIt1

CEllSYS

+---------+ ... .... +--------+ ·... .............. ........ .... . +---------+ +--------+ : Control: <====>: DECnet : <=======> +---------+ +--------+ ·............. ..... ..... ..... ........ .

1

1

Top: -lIS : Scanner :<---->: FUr-TOP :<------->

: Roor:: : : -lIS : : Scanner : <---->: COllRm~ : <------->

+----------+

11

<====>

11

11

11 11

<---->

11 11 11 11

+----------+ <====> <---->

+--------+

+--------------+ FOX 2/30

:=====================>

Conputer

1 1

:<--------------------+--------------+ . ...........................

Process Data Collect -ion & Display Subsys.

1

+--------------+ : X-Ray :=====================>

COrmls.

Subsys

<---->

4.0

: Spectrosraph : : (Phil ips) :

2.0

+--------------+ . ...........................

1 1 1 1 1

1 1

+------------+ +--------+ +--------+ : Coal-Coke :<====>: DECnet :<=======>:

1 I··· ...... .

: Laboratory : : -lIS : : : Data Entry :<---->: DATCCK :<------->:

+------------+ +--------+ . ........................................ +------------+

+--------+

0

Sinter :<====>: DECnet :<=======> Plant : : -lIS : Data Entry : <---->: DATSI:T : <------->

+------------+ +--------+ . ........................................

DECnet -llM CEI!SYS

<====> <---->

+------------+ ("SP +---+ : Data Entry :<=====> level : 1 : ------>: Subsys tel'1 loop) : +---+ : 5.0 :<-----> : +------------+ +--------+

Fi gure 5 (a) Overall Data Flow Diagram

+--------+

Data Collection on a Blast Furnace

167

+-----------+

<====>: <---->:

+-------+

Data Base Archiving subsystem

<====> <---->

Hag. : Tapes : ..

. . .............

1.0

+---+

<-----:

2 :

+---+

+-----------+

,===========================>:

1 1 1 1 1 1

1 1 1 1 1

Off-line Data 8ase

...............

<====>: Total :

and : <====>: Uti1. :

:

<---->:

1 1

On-line Data Base

1 1

1

1

1 1 1 1 1

...............

1 1 1 1 1

Graphics Workstation +--------+

: :

:<=======================>: :<----------------------->: DECnet

:

:

1 1

1 1

: :

1 1

: <======> : <------>

+-------+

: : +-------+

-ll~

: CD!SYS

<======>: <------> :

+--------+ 1 1

I

:

:<=======>: :<------->:

1 1 1 1

1

+--------+

1 1 1 1

+--------+ ...................... '" .

Query

+---+ : 2 :---------> +---+

1 1

DECnet : -llM : GRFWP.K :

<======>: +---+

:====>: 3

: Reports

+---+

............. +-------+

<=====================>: Colour and B &W · .. VDU screens

:<======================== : Operators

: •••••••••••••• :

:

COTi (mand

I

: ---->

: .............. :

+------+------+

1 +---+ 1 : 1 : <---+ +---+

+---+ : 3 : +---+

: <========================

............... +-----------+

1

1 1 1

1 1

1

2.0

'====>:

+-------------+

B &. 1/

... VDU screens

Users '

: ...•....•••• .• :

Scanner Process Data Base

· . . . . • •• . . . . • .• .

line: Interpreter :

: ----> : (MCR/DCl)

: .............. :

====>:

:

+------+------+

+---+

: 2

1 1

:<---+

+---------+

+---+

Fisure 5 (b) Overall Data Flow Qiagra~

Alar~

leg:

...............

1 1

Scanner

1

subsyster.

:====>: Support

...............

:

Conr;:and: ---->

: ............. :..

Keyboards

Process Data Collect -ion &. Display subsys.

...............

Picture Files

:

· . . . • .• • • • • • • •• • : line : ...•...••••••.•• : Interpreter: .•. Keyboards :---->: 3.0 :

·..

<===> :

+-------------+

Investig. Task O/P Fil es

1

1 1

+-----------+

P.G. Stephens and D.J. McDonald

168

results of the scan is dispatched back to the central system, where it is stored in a file for further processing by the requestor. A common network handling task is shared by both scanning systems. This has the benefit that the complexities of network line management are confined to one task, and the remaining tasks can use simple send data or pass region directives. Data Entry Systems The Data Entry systems are used for the entry, by operators and laboratory staff, of operational and analysis data for incorporation into the historical database, from where it is used in the production of management reports, and analysis of plant behaviour by users at the graphics work station. An interesting aspect of the data entry systems is that the facility is required at three geographical locations, two remote frorl the central system, and one at a terminal ~/hich is itself connected to the central system, while preserving a uniformity of operator interaction protocol. The data entry function itself involves presentin~ the operator with a menu of forms from which to choose. The menu, and the individual forms'contents, are stored in the central system main database, with the objective of ~akin9 sure that only one copy of the forms' definition exists in the system, to simplify r.1aintenance. Once a form has been selected, the form contents i.e. for"- title, column headings, item name, description, format of oata, validity check codes etc., are fetched from t~e central database, and the display put up. The operator will then key in his data. This will be subjected to the checks as defined, and appropriate interaction with the operator takes place for any incorrect or invalid data. So~e examples of the checks used are +

Numeric, possibly with range checks

+

Alphanumeric, possibly with a lirited vocabul ary

+

Consistent time data relative to otrer entries in t~e historical datarase

+

Correct sequence of entry of different operational reports

In some of these cases, the values against which c~ecks must be perforned will be in the central database, so these must be fetched to allow the check to be made. In a manner analogous to the case of the scanners, the ~rocessing aspects are separated fron the line handling aspects. This provides a convenient way of achieving

the requirement that identical facilities be available at remote nodes and local terminals, while at the same time not burdening the central system unnecessarily. Thus we have two tasks at the 'user' end - a forms handling task which interacts with the operator, and a line handling task. The two tasks are identical in central and remote nodes, the Network Services Protocol layer of OECNET providing the transparency required. This transparency is one of the tremendous benefits provided by the layered design approach of network packages such as OEC~JET • Graphics Work Station ~o detailed functional requirements exist yet for this subsystem. Generalised functions include the following:-

+

Local development of user application programs in any of the programming languages available on the system, viz Fortran, Basic and r.acro.

+

Access to the central database, fror.1 programs and interactively.

+

Comprehensive statistical manipulation subroutine library.

+

Ability to produce hardcopy graphical output by means of a plotter, with convenient development of graphics programs using a graphics CRT during the development phase.

These capabilities will be used to support modelling studies of furnace behaviour and performance, using data from the historical database, as well as the production of one-shot r.~anagerient reports on an ad-hoc basis. Central System It is difficult to decide just how much detail to present in the case of the central system. It would be easy, if perhaps rather tedious for author and reader, to present many tens of pages of descriptions of what happens in it, and while a tremendous amount of activity does take place there, much of that activity is fairly conventional and unremarkable in the context of distributed systems. It was deci ded therefore to confine ourselves to highlighting some of the r.ore interesting or important aspects, without going into much detail. The core of the central system is of course the historical database. It is a single database, with the data in it falling clearly into blo categories, viz time-related and non-time-related. Time-related data includes such things as the scanner three-minute data frames, charge data from the FOX 2/30, analysis data from the spectrograph anc operator entry, and

Data Collection on a Blast Furnace

operational data. Non-time-related data includes such things as process point descriptions, addresses, conversion constants, data entry format descriptors, and so on. Data fror. all categories is expected to take up some 80 ~~bytes of storage. Archiving of data to tape takes place autor:.atically at 04hOO every day. At that time, the previous day's data is spooled off to tape in a format which permits simple reloading back to disk for archival data extraction. After that, data older than 40 days is deleted from the online historical dztabase. It was pointed out earlier that the dual Winchester disks were used in a 'cold' standby mode, so that if one fails, the system can be restarted manually using the other disk. The 'spare' Hinchester is to be used in between times to support the archival data recovery function. A database structure identical to the online database will be kept on it, into which archive data can be loaded from tape, for extraction of long term historical data. A specific requirement of the system is very rapid response to requests for operator displays. The approach taken to achieve this is to store on disk a complete image of each display format, complete with live process data. These pictures will all be updated every time a scanner frame is received. This approach is only valid as long as the number of different displays remains small. One benefit of this approach is that it provides a convenient place to put the rather COl',p1ex deri ved vari ab 1e calculations, together with the monitoring of these against various limits. Also located in this subsystem will be the preprocessing required to support the longer term statistical calculations (daily, weekly etc), and the preprocessing required to augment the query package capabilities standard deviation calculation for example. Scanner support includes modules to do the follOlJi ng +

Receive the three-~inute frames and enter the data into the historical database, ant trigger the picture refresh module.

+

Receive the data packets describing alarm messages and translate and print them. Trigger the display susbsystem to updzte the diplayed alarm state.

+

Extract point descriptiverecords fror. the database and construct the tables required by the scan task.

+

Extract pOint descriptive records from the database and construct the tatles required by the investigational scan task. This function r.ust be particularly easy to drive so that relatively

169

lnexperienced personnel can use it. +

Transmit control tables to and receive data from investigational scan task.

+

r~aintain

synchronisation between the time of day as held in the central system and in the scanner systems

Support for the data entry systems i ncl udes the following +

Retrieval of forms definition records from the database

+

Retrieval of check limits and parameters from the database

+

Receiving of completed reports and storing in the database CONCLUSION

We have attempted in this paper to give an over-view of what we consider to be the more interesting aspects of this particular computer system in the context of distributed systems. Thank you for your attention.