A th sis ubmitt d to th School of Graduate Studies

Single-Platform Stimulate d Simulators (SPSS)

by

© or y White

B.Eng., M morial Univ rsity of Newfoundlan l, Canada (2000)

A th sis ubmitt d to th School of Graduate Studies

in partial fulfi llment of the requirem nts for the degree of

Mast r of Engineering

Faculty of Engin ring and Appli d ien e

M morial Univ r ity of Newfoundland

Single-Platform Stimulated Simulators (SPSS) by

Corey White

Abstract

Simulating a process control system during t he design phase is a key step in en suring the system is designed correctly and meets the cl esigu specificatious. There are several methods that are commonly used in industry to simulate process cont rol systems, each

selected based on the level of d etail of t he s imula tion a nd the cost . Ma ny Engineering firms will choose a simulatio n method based on cost rathe r t ha n level of deta il b ecause cost has a higher priority.

This th esis will look at some of the ways industry currently simulates process

control systems and will compare th em on Cost, Fidelity (level of detail of the sim-

ulation), Implementation and Conversion. As well, an a lternate simulatio n method

will b e presented t h at will strike a b a lance b etween cost and fi delity.

A cknowle d gem e nts

I would like to thank my Supervisor, Dr. Siu O 'Young for his guidance and

support throughout this project. I would like to thank Mr. Terry Carter and ABB for their technical as istance on the DCS portion of this project. I would like to thank Schneider Electric f or their techni cal support on t he PLC portion of this project.

Finally, I would like to thank SEA Systems Limited and the atural Sci nces and

Eng ineering Research Council ( SERC) for th eir financial support of t his project.

Contents

Abstract

Acknowledgement

Contents

List of Figure

1 Introduction

1.1 Probl m Statemen t

1.2 Ana lysi of Typical Simul ation M ethod

2 Curre nt Industrial P ractic 2.1 Softwar to Software . 2 .2 Hardwar to Software . 2.3 Ha rdware to Ha rdwar e

3 A Framework for SPSS 3 .1 o nt.ro l Sy:->t.em Defini tion 3.2 Simulation Options

4 PLC Simulation 4.1 P lan L Mod l . 4.2 ontrol qui pmen t

111

11

Ill

v

1 1 3

5 5

10

1 4 14 17

21

22

25

4.3 Graphical Display . 2

4.4 System Timing 30

5 DCS Simulation 37

5.1 Terra Nova Simulator . 37

5.2 Hibernia Simulator 40

5.3 Simulator F lexibility 43

6 Real Life Example 55

6.1 Process Description 55

6.2 Plant Model 57

7 Conclusions 62

7.1 Simulation Method Comparison 62

7.2 Future Work . . . . . . . . . 66

List of R e ferences 68

List of Figures

1-1 Graphic Representation of Simulation Method 2-1 Proc s Simulation Ph as

2-2 Life y le Simulation 2-3 HY YS Screen Shot 2-4 FiL f or Purpose Simulation

3-1 Graphi c Representation of Sy tern 1\ ·ansfer Function

2 6 7

12 15 3-2 Simulation Matrix . . . . . . . . . . 17

3-3 All n-Bradley PLC 5 ProgramS an . 19

4-1 Diagram of Three Tank P ro e 22

4-2 Simulink od . . . . . . . . . 24

4-3 Graph of Water Level vs Time . 25

4-4 Concept Simulation Logic . . . 27

4-5 Factory Link Screen for Simulation 29

4-6 Graph of Water Level vs Time For One PLC Simulation 31

4-7 Typi al Control I etwork . . 32

4- PL Simulation Equipm nt 33

4-9 Graph of Water Level vs Tim For Two PLC SimulaLion 35 4- 10 ombined Results of All Thr - Simulations . . . . . . . . 36 5-1 SimulaLor Layout Using ABB Universal Simulation Module [1] 3

v

5-2 Terra ova P U Layout . . . 5-3 Terra ova Simulation Logic . 5-4 Blo k Diag ram Layout for Simulator

5-5 Logic R quired to Read PL M mory Regist rs 5-6 Logi U d to Extract Bits From GPI Data 5-7 Logi That ses GPI Data . . . . . . . . . . 5-8 Function ode Logic to Inpu t Digital Values 5-9 T ie Back Logic for Simulation

5-10 Typical Iufinet Layout .. . . 5- 11 Plant and Control Logic PCUs . 5-12 DCS Logi for Tank 1

5-13 imulation Control Logi 5-14 D S imulation Results 6-1 Hotw 11 Tank P&ID . . . 6-2 Hotwell Tank Level Trend

6-3 Simulat d Hotwell Tank Level Tr nd

39 41 42 42 44 45 4

49 50 51 52 53

54 56 5

60

Chapt e r 1 Introduction

Many industrie , ·u c h as oil and gas and pow r generation , demand control system with a high d gr of afety and reliability. To meet this demand many compani s u simulation to thoroughly test and debug their process control quipment b fore plant commissioning. There are many ways top rform thes simulations. Methods involv- ing everything from simple tie- back logic to pow rful third party s ftware p ackages h ave been impl m nt din industry. Each method has it 's b nefits and di advantages for the u er in t rms of cost and simulation re ults.

1.1 Problem Statement

The Instrum ntation Control and Automation (INCA) research gr up at Memorial niversity is looking into the curT nL method of simulation and inv tigatin g alt r- natives to the e m thod s. The simulator Lh y are trying to develop will s rve t hre main functions . The first and most important function i s to enab le control ngineers and oth r interested parties to thoroug hly test and d bug th ir onLrol eq uipm nt, i.e. software, programmable logic onLrollers (PLCs) and communi ation n tworks, withou t u ·ing a ny process equipment. Thi simulation will be performed prior to th install ation of th system . Secondly, the simulator will provid a mean s by whi h

1

the syst m o perator can b e tra ined on how L o u e t he sy t m an d how to deal with problems that a n occur durin g the op eration of t he plan t. The t hird function will be to provide p er onn l with a means to "r create" a faul t thaL o curr d within the process to d termine ex actly what cau ed th fault.

CONTROLLER PROCESS

SOFT'.'•~RE

~ SOFTI'I>.RE

0 0

B ^SPSS

Hl.ll

PLC'OCS ~

lnST~LLED

SYSTEI.I

Figure 1-1: Graphic Representat ion of Simulatio n Methods

The propo d m thod assum e LhaL th e th eoretical analysi of t he control sy - t em has b en omplet d and t haL th haracteristics of the indi vidual compon nL.

that mak up th proc ss are understood . In order to achieve the a b ove men tion d

functions, all of the variables, su ch as ommunication loop delays and logic exec uti n

time, n eed to b included in the imulat ion . T his will b ring th imulation as clo

to the real proces as possible.

1.2 Analysis of Typical Simulation M et hods

Th r are typically t hr e ways in which con trol syst ms an be simulated: Software - Software, Hard w ar - Software, H ardware - Hard ware. A control yst ms d ev lop r can choose any method and us it exclusively during the design proce s or they may wish to progress to the different modes of simulation as the d esign pro cess evolves.

Figure 1-1 is a graphical representation of th se simulation methods and how they relate.

In Chapter 2 t hese simulat ion methods will be discus ed with examples of how they are u sed in industry today. These methods will be evaluated on the following criteria:

• Cost

• Fidelity

• Implementation

• Conversion

The cost analysis will look at what equipment (computers, control quipm nt, soft- ware), real estate a nd human resources ar required to implement Lhe simulation.

The analysis will not provide an exact value for the cost of each method rather it will rate each method relative to the others . For xample, simulation A may get a rate of

$1 because it only r quires one computer where as simulation B may get a value of

$5 because it requires thre comp u ters, seven controllers aud a large office.

T il e fi uclit. y au a.ly~ in will look a.t. l10w rca.liiltic the ~imul atiou i~ . It. wi ll look R.t

how clos ly the simulation matches the real process and assign a p rc ntage to it.

A simulation th at can provide process trends that m atch the t rends from the r al process will get a value of 100%. Simulations Lhat just trigger t he inputs ind ividually will get a value of 5%.

3

- - - ----~---~

The implementation analysis will look at th e level of difficulty in setting up t he simulation. Each simulation method will be given a rating of on e to ten , on e b eing easy and ten being difficult. For example, a simulation t hat takes one person a couple of ho urs to set up will be given a score of one a nd a simulatiou t hat takes five people three weeks to set up will be given a score of ten .

The conversion an alys is will look at t he level of difficul ty in converting the control logic from the simulat ion environment to t he plant control system. An easy con ver- sion , e.g. transferring t he logic d irectly from th e simulation to the con trol equipm nt , will get a value of one. A d ifficult conversion, e.g. having to rewrite the logic fr om scratch in the control equipment , will get a value of ten.

C hapters 4, 5 and 6 will p rovid e an alternate meth od of simulation referred to as Single-Plat form Stimulated Simulat ion (SPSS). F inally, Chapter 7 will summar ize t he simulation an alysis and provide som e options for indus try.

The main focus of this thesis is process con trol simulation methods currently b eing

used in industry. Therefore the backgro und information came from co mpany web sites

and m arketing materials and from my experience from working in the automaLion

industry for the past five years.

Chapter 2

Current Industrial Practice

2.1 Softwar e to Softwa re

The fir ' t imulation method mentioned in hapter 1 is Software to Software simu- lation . With this m th od, both the ontrol logic and the proccs are modelled in P C bas d softwar packages. T here are numerous softwar packages on the market that do Lhis type of simulation . Some package like Hyprot ch 's Hysys and Kongs- berg Simrad ' ASSETT are ab le to simulate both the pro es and th control logi . The e programs are pecifically d signed to imulate eng ineering processe , such as petrochemi al pro esses. As a r sult of th is very detailed math maLi al equation are used to model equi pment and p hysical prop rt ies, such as ch emi al reactions, result- ing in high ly reali ti simulations. Oth r packages like All n Bradley's Emu late and Modico n's Con pt provide a simulatio n of L h ir PLC 's that logi an b loaded int . Inputs can th n be manually trigger d to simulate proces changes. This provide a very qui k and asy way to check the logic for errors.

The Software to Software simulation method is strictly a P bas d m thod mean- ing that t h only apital requ irem nts arc a PC and the simulation software. T hi makes this m thod very useful during a ll stages of development for a proj ct b ecause th e softw ar can be resident on the d ign engineer's comp uter and b accessible at

5

all times_ Th re are six main phase th at make up the life of an ngin ering proc ss:

1. Design 2. Construction 3. Commi sioning 4. Start-up 5. Op ration

6. Maint nan / pgrad es

Within thi lij: cycle there are several k"y points at whi h an engine ring firm may want to run a proce simulation . The point are shown in Figur 2-1 [2]. Many im-

Process Design Pnase

Figure 2-1: Pro css Simulation Phase

Post Start-l.l) Maintenance and Tralnng

ulation oftwar developers, uch as Kongsberg Simrad have designed their softwar packages with the goal in mind that o ne simulation packag can b u ed for ev ry stage of the project life cycle, thu s reducing osts during plant start-up and commi - sioning a nd during the plant 's operatio nal life [ 2]. F igure 2-2 [3] is a marketing image from Kong berg showing that ASSETT i a Life Cycle simulator.

Since the Software to Software method i P C based, it i abl to take advantage

of the computational power of PC . Even the most basi P can olv ompl x

mathematical equations t hat are virtually impossible to olv any other way. Thi

means that pro ess with compl x m at hematical models, such as thre phase p iping

and reactors, can be simulated on a P making t he overall simulation much more

realistic.

Malee It Right First nme

Figur 2-2: Lif Cycle Simulation

There are several ad vantages to using the Software to Software method:

1. It i economical. Compared to o ther methods of simulation, thi method is eco- nomical because t he only capital requirem nts are the oftwar and a com pu ter.

2. No specialized equipm nt required. Since thi is a P C based simulation method, there is no p ecialized equipmen t, such as contro l equi pm n t requir d to run the simulat ion.

3 . Easy to set up. Again, sine this is a P C based simulation , t h only s t up that i required is installing the software an d creating the plant mod el. In some comm rcially available software packages creating t he plant mod 1 is as impl as connecting together pip es and tanks a nd valves. This can b s en in t h HYSYS screen sh ot in Figure 2-3

The lisad vantages to this meth od of imulat ion are:

7

Figure 2-3: HYSYS Screen Shot

1. T here ar some system perfo rmance characteristics that ar difficult to mod el.

For exampl , communi cation loop timings and logic ex cu tion tim and priority are h ard to model because they d ep nd on the type of control quipmen t u ed, siz of logic and communi ·ation netw rk config uration.

2. Tim on suming to convert con trol logic. Any logic develop d for the simulation cannot be dire t ly loaded into the control equipment. It first has to be con- vert d to th language that the equipm nt under tands. Sin this language i propri tary, th re are n o oftware con v rsion too ls avai lable that con vert logi from the simulation software in to the control manufacturer's oftware. T his means all logic will have to be reatcd from scratch in t he c n troller software, which is v ry time consuming and i open to errors.

2.2 Hardware to Software

The second method listed is t he Hardwar to Software method. With this m ethod ,

the control logic is executed in the control equipmen t, such as a PLC or DCS , and

the process is mod lled in a PC based oftware program, similar to the type use I in

the previou method . As with th pr v1 ou method , the oftware provides a highly accurate math matical mod el of the proc ss. Input Output data is passed b etwe n the PC and the control equipment via a custom communication n Lwork.

The advantages of the Hard wa r to Softwar method are:

1. Thi m ethod is more realistic becau e it uses the sam Lyp of equipme nt L haL will b u d to control the actua l proc . This allow the chara teri tics u h a communi ation loop delays and logic xecution L im to b in orporated inLo the s imulation .

2. All control logic created for the imulation is already in Lhe language that th control quipment understands . There f ore no logic conv rsion i r q uired.

3. Easy to s L up. Since the same o fLware used to model Lh planL in th Softwar to Softwar method is used in thi method, th e ease of set up would b th e same.

The m thod a l o has some disadvantages:

1. Dep eudiug on the equipment being used , there may be som significant real staL e required to house the simulation.

2. Establis hiug communication b twe n these two items can be a difficult. and cos Lly process b ecause ty pically onLrol networks are lo eel, propri tary net- works. Th y require special equipment or programming L o allow devices, oLher than those used to control the proces , to acce s the n Lwork.

Incorp orating the control equipm ent into the simulation mak t hi meth od id a!

for operator training. It allows the imulator to be et up like t h a Lual plant control room and allow Lhe op rators to not only g t familiar with th op raLor console , buL with all Lhe ontrol quipment a nd h ow it all interacts. Thi method is a l o us ful for post s tartup logic and HMI updat es for 'yste ms, su ch as offsh ore oil a nd gas platforms where having someone on site for upda L s i a very costly pro ce . This simulation

9

method a llows upda te to be fully tested on s hore a nd then se nt to quali fied persou nel on s ite to load .

T he H ardware to Software simu lation method was t he method used by th ~ rra Nova Allia nc to train operators f or the Terr a ova Float ing Produ L ion, Storag a nd Offioading (FPSO ) v ssel.

2.3 Hardware to Hardware

The final s imu latiou met hod mentioned abov' is the Hard war to Ha rd. ware method.

With this method both the plan t model a nd the control logi ar executed in control equipmen t. Two of L he way this type of s imulatio n is b ing don in indu try a r :

• lave controll r contains a d iscr L s t of data, such as sequ nee of even ts data or I/ 0 data from a similar pro c .·, th at triggers the input i n the control logic.

Resulting ou tput determin e next se t of inputs .

• Input r place I in th log ic with s witch blocks (for digital inpu ts) an d con tant block (for a n alog inpu ts). Th witch blocks are then manua lly turn ed on and off to s imulate cha ugiug digital iuputs aud the value iu t h constant blocks ar "

ha ng d to simulate changing an alog inputs .

Thi~ mC't.hod i~ a low fidelity Himulat. ion method bccauHC' the data set. H SC'O t.o t rigger the in puts i eli cret . T his m ans th at Lhe accuracy of the simulation d epends on th sample rat of t he data. For exampl d ata that i sampled every millisecon d w uld provide a more accurate imulation t ha n data sampled every s ond b a use t here is a greater cha nc of d t cting transient and pikes with the high er ample rat a n I h aving L ran ients and spikes in the imulaL ion provides gr ater inf rmaLion on system p erf o rma nce.

Engineers and t echnicia ns at B ailey SEA (Nfl.d .) Limited and EA S st ms Lim-

ited usc both types of Ha rdware to Ha rdwar imulation to s imulate logic and HMI

updates for the Hibern ia offshore oil platform and the Terra ova FPSO. They use the slave controller method to simulate the Fire and Gas (FGS) Em rgency Shut Down (ESD) control systems for Hibernia and they u the seco nd type, typically referred to as the "Tie Back" method , for all other system updates.

The main use f or the Hardware to Hardware simulation method is during control logi and operator in t rface d velopment and upgrading . Since all t he input values have to be changed manually in the tie back method, it is too time consuming and inefficient to use this type of simulation for op rator training. Also, by manually changing th input values one at a time, you only observe how a small section of th control system reacts to input changes and yo u are unab le to see how Lhe sysLem acts as a whole to input changes. For example, a steam flow control valve f r a boiler is b eing simulated to determine PID tuning value . A constan t block is us d to simulate the steam flow and is manually adjusted to simulate changes in flow rate and allow tuning values to b e determined. This process assum es a constant steam flow. However, in reality steam flow is never const ant a nd changes in steam flow cause changes in pre s ure upstream of th valve. Since the steam boiler is a control process as well, changes in outlet pressure and flow will cause the cont roller to adj ust coml>u::;tiou and water flow to bring t!J pre~~ure ami flow back to the setpoint .. These adjustments cause fluct uations in steam flow which affect the flow contro l valve.

By tuning the valve l>~ed ou constaut flow the valve may not re~poml proper!. to fluct uations caused by the boiler co ntrol syst m.

As can be seen in the above d i scussion and in the example in Chapter 5, ea h simulation method is best suited for on particular type of simulation. For example the Software to Software method is ideal for hi gh level process d sig n and optimization simulations bu t is overkill for basic logic update testing. These types of simulation are considered "Fit For Purpos " simulations meaning a simulation method is ch osen based on what the simulation is to achi ve. Figure 2-4 illust rates this idea. If the main purpose of t he simulation is operator training, the designer may want to ch oo e

11

Level 1

,---~

I+ I - I I I I

}-e~~l_2

___ _ __ __ ____ ___ ______ __ _ __ _ ____ _ _______________ ___

i .1.~1_3 ________ _____ _

I ^{Level 4} I

Volvo Tank

L ___ _ ___ _ _ ________ J

I I I I I I I

I L _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ j

Figure 2-4: Fit for Purpose Simulation

y

Levels 1 or 2 where the proces and control are ass umed to be id al and the o utpu t is t he r feren e, or setpoint, multiplied by a constant. If the simulation was to b u d for logic update testing, then Level 3, where a non-ideal controll er is controlling an ideal process, would b e more applicable. Finally, if the purpose of the simulation i to a nalyze t he process to d etermine a r as for optimization, then Lev 1 4 simulation could b e used. Here, all process equipm nt, tanks, valv s, pip es, are mod lled in th simulation to provid th most realistic simulation possible.

To add another option to t h above list of simulation methods, this thesis proposes

to u the control equipmen t to simulate both the process and the control logi .

This method would b e called Single-Platform Stimulat d Simulation and would fall

between the Hardwar to Software and Hardware to Hardware methods It would

implement t he mathem atical model of the plant within the con trol quipment , similar

to t h models used in th Software to Software methods. The id a of this method i to

provide a more realistic simulat ion like in the software to software method while saving

the user the cost of purch asing a third party software package and communications

link. As well, as with the ha rdware to hardware method, this meLhod would save significant e ngineering time because a ll th logic for the simulation is created in the same programming environm nt that will be used for th actua l plant.

13

Chapter 3

A Framework for SPSS

In the previous cha pter the difFerent met hods used to simulate a con trol system were discus eel . This cha pter will discuss how a pla nL model is developed and some of Lhe opti ons available to simulate th mod l.

3.1 Control System Definition

Any d vice or group of d evices that manipulate one or more variables of a sy Lem to achieve a des ired result is called a co ntrol system [4. p.4]. More specifically, if these devices monitor th e act ual r esult and ma nipulate t he variables based on Lhe diff reuce b tween the actua l a nd de ired resu lts, they form a C losed Loop Control System. Feedback is the pro cess of monitoring the actua l result and comparing it to the desir d result [4, p.IO]. One example of a clos d loop antral system would be driving in a car. The desired result would b car position d in the middle of Lhe road. The driver visually monitors t he curren t position of the car beLwe n th lines on th ro ad a nd , b ased on the curren t position and where he / h e want the car to be, adjusts th steering wheel to cha ng t he car 's position [4, p.5].

The object or objects being cantrall d is g nera lly referred to as th pla n t. The

desired result is called the setpoint. The means by which resul ts are monitored are

called sen or . The devices t hat monitor and manipulate syst em variables a re r [ rred to as controllers. Th devices u ed to manipulate varia bles are called act uators [5, p.2]. In the ex ample of the driv r ab ove, th e car is t he plan t, L h dri ver i th control! r, the driver yes ar the ensors, t he position of the car in Lhe middl of th road is th e s t p oint a nd the drivers arms ar th e actuators. One control syst m , or loop in an industri al b oiler maintains th e level of water in t he tank. The s nsor is a level tran smitter which convert the level to an electrical signal (inp ut). This ignal is then r ead by the cont roller which is typically a Distribu t d Control y tern (D ) or a Prog rammable Logic Cont roller (PLC). The cont roller will sub tract t h e set point from th e 1 vel and apply a control algori t hm, s uch as pro port ion al int gral derivativ (PID), to the value to generate the act u ator adjustment value (ou tpu t) . The actu ator is a valv on th e water supply sid e. The ou tput value will eit her increa e or decrease the valve opening to adjust t he fl ow of water to t he t ank and keep th " lev 1 constant . Figure 3-1 is a typical graphical r presentation o f a closed loop con trol ystem .

SP ' ^{£.... G: G• c}

c~

H

Figure 3-1: Graphic R epresen tation of System Transfer FuncLion

A control system is design ed on two levels: abstract and physical. The purpo of the abstract level d sign is to ob tain an ap propriate ontrol straL gy and en ur the system will p erform as out lin d in the sp ecifications. T h p urpos of t he physical level design is to ob tain the a ppropriate hardware and software required to impl m nt t he control strategy [5, pp .4 ,5].

15

In order to implem ent the a bstract l evel design , a mod el of the plant must b e de velop d. One way to develop this model would b e through fundamental principles.

With this met hod , key components of the plant ar e identified and m athematical equations that d escribe t hes compon en ts a re written , along with the equations t hat link the components together [5, p.6]. For example, t he level of a liquid in a tank with an inlet pip e and an outlet pipe connected to the bottom is described by th e following equations:

h1(t) = ~ j ^{qnetdt + h1 (0)}

qnet = qin - q1 2

Where: h(t) = level in tank at timet h 1 = level in tank 1

h ₂ = level in tank 2 qin = flow rate into tank

q 0 ut = flow ra te out of the tank

q 12 = flow r ate between ta.uk:>, iu t his case between ta.uk 1 and ta.uk 2 A = Cross sectional area of tank

c, ( = valve codficieut p = density of wat er

g = gravi ta.tiona.l accelera tion

Another way to dev lop the pla nt model is to look at the plant as a. black box. With

this method, the mod el starts o ut as a. simple first order transfer funct ion and , based

on observations of the inputs and outputs of a. similar process, adjustments a r m ade

to the transfer fun ction to match the observations [5 , p.6].

3.2 Simulation Options

W ith th e mathematical model of th e p lant and control logic determined, there ar a numbe r of options th at can b e u sed to test a nd analyze th per formanc of the control system. Figure 3-2 lists the differ en t op t ions that can be used. They are based on wheth r the p lant and controlle r ar e ana lytical, simulation or r eal.

Controller Plant

Analytical Simulation Real 1 "Text-book" 2 3

Design/ana lysis

Analytical Bode Plot, Root H ysis/Si mu link SPSS Locus, State-

Space

4 5 6

Simulation H ysis/Si mul ink H ys is /Si mu link Stimu lated Simu lation

7 8 9

Real N/A N/A Online

Figure 3-2: Simulation Matrix

Box 1 represen ts th e "text book" a na lysis of the control system , wh r both the plant a nd the controller are an aly tical. The model for this ana lysis is us ua lly th system Lransfer function. Variables such ass nsor noise, a t uator nois p ump ou tpuL, etc. a r e assumed to be some constan t value to make the an alysis simp] r. Exampl of typical "text book " methods to an a lyze these tr a nsfer functions ar b ode ploLs a nd root locus for s ingle-input , single-outpu t ystems, com monly known as classical design a nd state-space models for multi-variabl systems [5, p.231].

17

The "text book" an alysis is usually done during the design phase of a proj ect.

Engineers, using computer programs such as Matlab and Simulink, would be able to generate graphs of the system transfer function and determine the p erformanc characteristics. Al o, by varying parameter uch as the loop gain or sensor nois , th system response can b e observed. This can lead to a et of p erforman ce characteri ti s that can gu ide the design of the physical con trol system.

The system analysis for Boxes 2 and 4 in Figure 3-2 has one component analyLical and one component simulation. Th equations for the analytical componen t would be similar to the analytical equations used in the "text book" method. The simul ation component would b e a collection of the m athematical equations that describ ca h piece of the component being simulated. For example, a plant containing a pipe that feeds liquid to a tank through a control valve is the compon nt b ing simulated. Th model would consist of the result of th e mathem atical equation that describes th flow rate of the liquid through the pipe . modified by the equation for the couLrol valve, b eing used in the equation describing Lhe level in th tank.

Simulations that are done to study and optimize the process fall into b ox 4. As dis- cus ed in Section 2.1 , programs lik Hy is, ASSETT and D-Spice a re used to gen rate detailed mathem atical representations of the plant by connecting together graphical representations of th equipment used in the process. The program then solves th mathem atical equatiou::> to generate vrocess parameter::> ::>uch a::> flows pres::>ure::> aml levels which are ch ecked by system design rs to ensure th pro cess is functio ning withiu the ::;pecificatious. At this stage the control equipmeuL characLerist ics are uoL critical to the analysis so simple co ntrol equations are used.

Simulations p rform d during the design pha e of new control equipmen t or during

control logic design would fall into box 2. Here the controller is simulated a nd th

plant is analytical. Control equipment manufactur rs such as Modicon and Ro ckwell

Automation provide a controller simulation program as part of their logi development

software packages. Th se simulation programs execute th e control logic th e am

way and at th same rate as th real ontrollers do. They also all ow L he user Lo change inpuL , obs rv outputs and moniLor program execuLion. Th se con troll r simulation programs can also b e modified by control equipment manufacturers to test new controll r architectures.

Simulat ion that would fall into box 5 ar similar to tho L h at fall into box 4. The main diHerence is that t h particular operating ch aracteristic of the contr I equipmenL are Laken into account. Most con tro l equipmen t h av a tri t way in whi h to exec ute logic. First the co ntroller CPU will execute t he logi fr m start to finish then it will take care of data manag menL , s uch as reading inputs, wriLing ouLpuL da ta and co mmunicating with other on trollers on a communi ation neLwork. This process occur con tinuously while Lhe conLroller is running. The Lim it tak s for a controll r to compl te one cycle through L h logic and data m anag ment is called Lh processor an tim . Fig ure 3-3 illust rate how an Allen-Bradley PLC 5 performs this proce. · [6]. This scan time is d epend anL o n th e amounL of ont rol logic a nd the

J . .

b

[II~

110

• f.ll£1

• F1Lh11 K

L'O luli

TJh~

• oa.a ... ^r n:1~1J'!fC

:r

F igure 3-3: All n-Bradley PLC 5 Program Scan

19

amount of data that t he controller has to manage. If th e scan time is known or can be estimated, time delays can be added into the controller simulation to delay wh n data gets transferred to t he plant model or when certain sections of logic get executed .

Box 6 simulations h ave the real control equipment connected to a PC runnin g the same simulation software that is used in simulations covered by box 4 and box 5.

These simulations would come under the Hardware to Software simulat ion method discussed in Section 2.2.

Single-platform stimulated simulation fall s into box 3. Here analytical models of the plan t, similar to th ose used in the 'text book" analysis, are load ed into control equipment similar to t h e equipment being used in the real plant. Depending on the configuration of the control system, several controllers can be networked together with some controllers sharing the plant model and other controllers sharing the control logic. This allows for real con troller scan t imes and communication loop delays to part of the simulation .

The following three ch apters will develop SPSS simulations. In Chapter 4 will

define a plan t model to be simulated and it will show how the model is used in an

SPSS simulation in a PLC. Chapter 5 will show how this same simulation can be done

in a DCS . Finally, Ch apter 6 will show the simula tion of a typical pulp and paper

mill pro cess.

Chapter 4

PLC Simulation

Ov r th past numb r of year , Lh omputing power of th programmable logi controller has made ignifi cant advancements. \Vhen the fir t PLC was develop •d in the late 1960 s, early 1970 s it contained 1 kilobyte of m mory [7]. Today a n Alle n Brad! y PLC a n can be p ur h as d with m gabytes of memory a nd a math co processor for p ~rforming fioatin g-poiut calculations [8]. T he P LC has gone from co ntai ning small ladder logic progra ms t hat turn motors on and off a nd open a nd close valves to la rge fun tion block bas d p rograms t hat control ompl x, a £ ty criL ical systems s uch a oil and gas proce s ing [9].

In Cha pter 2, it was discussed that the most eflect ive 'imu latiou m ethod was to use a third party softwar package that contained a math matical model of the plant. Since most PLC a nd D CS programming environment · contain all the funcLion blocks r equired to build mathematica l models, the idea for this r a rch project wa to d evelop a ingle-Platform Stimulat d Simulator (SPSS) u ing tandard indusLrial control q uipm nt. T he hop e for thi project is that thi method will make th simulations •asier to develop a nd more fi ~xible because th r n o need for the us r to learn a thi rd programming lang uage a nd it m ay be easier to modify the plant model to provide a more realistic simulation. For example, this m thod may make it easier to in corporate multipl e controll r into the simulation to bring the t iming

21

characteri ti s of the imulation clo er to th Liming characteri ti of Lhe real syst m.

Figure 4-1: Diagram of Three Tank Proc ss

4 .1 Plant Mode l

The firsL stage of the proj ect was to determine a ·imple process L o simulate aud the equat ions required to simulate it . To make Lh modelling part of the imulation eas- ier , a proc ss that consisted of t hree t anks containing water was reaL cd. The water is able to flow from tank 1, through tank 2, to tank 3 via piping th at connects each of the tanks aL th bottom. A con trail r monitors the lev 1 in tank 2. Once t h e 1 vel drops b elow a set point, the control! r opens a control valv allowing water to flow into tank 1. Once Lhe level in tank 2 go s above t he set level th on troller loses Lh con trol valv allowing the level in Lank 2 to drop. A diagram f Lhi sy L em is show n in Figur 4-1. This process can b e d s ribed by the following equation :

Tank 1:

Qnet = Qin - Q12

Tank 2:

Qnet = ^{Q12 - Q23}

Q23 = Cv J pgh2 - pgh3 Tank 3:

Where: h (L) = level in tank

Q i n = flow rate into tank

Qout = fl ow rate out of th tank

q ₁₂ = flow rate between tanks , i11 t his case between tauk 1 a11d tank 2 A = ro s sectional area of tank

Cv = valve coefficient = 55 p = d n si ty of water = 1000 g = gravitational ace 1 ration

23

Each tank was et to be lm high wiLh a ra dius of 25cm. The pip joining the tan ks w e re set Lo b 25cm long with a radius of 1.27cm. This pipe radius m eanL that th valve coefficient . Cv, for the manual valves between the Lan ks was 55. The tank cross sectional ar a (1r-r2) was 0.1963495 m 2. This process was conLrolled uch that when the water l v l in tank 2 fell b low 0.45m, the controll r would pen the source co ntrol valve, a llowing water to flow into t h system and bring t h wat r I vels back up. On e Lhe wat r 1 vel in tank 2 ro above 0.55 m the controller would lose the source control valve allowing th e water l vel to drop.

To e nsure th r s uits from th PL simulation a re corr cL, the simulatio n was run in Simulink. T h code for this simulation is shown in Figur 4-2. This simulation provided a graphical plot of the ch ange in tan k heigh t with respe t to time (Figur 4-3)

Ready I HJO%

F igure 4-2: Sirnulink Code

that was used as a omparison for th simul ator that was cr aLed during thi proj ect.

If the r ults from the imulator cr aL d for this project match d th imulink r sults then it will b assumed that the new simulator is correct as well.

ag

ae ··· ... . _.

.. ^- ... -:- . _. ... :. . _. . ..

. -- r . -- - - -.. -

... .

... ; ···;····-···

. .

Q2 •••

.

. . . . .

.

. . . . . .

·· : ··· ---

... !'' ...

...

... .

01 ...

... .... ... ; ... ; ... ; .... .

100 200 ~ 400 500 I50J 1'IXI 800 900 1000

Figure 4-3: Graph of Water Level v Time

4.2 Control Equipment

Once a ref rene t of results was e Lablished , the plant mod l was r cr ated in the PLC programming nvironm nt. Th control equipment t hat was u d for this part of the project was a Modicon Momentum PLC , Concept programm ing sofLwar and Factory Link operator interface softwar . All of this equipment was purchas d from Schneider El tric. T he reason this syst m was chosen was becau of it om pact size and Concept was based on the IEC 1131 standard for PLC programming. IEC 1131 is an intern ational standard that specifi e ' five different languages f r programming

25

PLCs. Th e la nguages a re Ladd r Diagr am , Function Block Diagr a m Structur d Text, Sequ nLi al Function Cha r t a nd ln tru tion List [10]. Thi imulation uses Lhe Function Block Diagram langu ag becau e Lo th e user , this la nguag i very similar to Simulink and D-SPICE, wher m at hemaLi a l equations ar gen r a L ed by connecting the appropriat fun ct ions toget her. A' we ll , many DCS systems, su h as ABB Infi 90 system, u function block ba d la nguages. sing a la nguage that i common to a number of v ndors means th e simulaLion i not limited to on vendor.

Figure 4-4 s how the simulation logic th at was created iu on ept . As t his fig- ure show , the logic was spli t up into six sections, with each L ion r epresenting a compon nL of the system , s uch as a L a nk. The reason for creaL ing t h logic in thi fashion was to how th at compon nL function block can be cr at d to repres nt a part icular pi c of equ ipmen t . The blocks would mask th a tual logic r qu ired to mod el th e piece of equipment, so th at the simulation logic r esembles a process a nd instrumentation drawing instead of a omplex ma thematical mod I. Thi also mak s the ConcepL simulation more like the commercially avail able imulatio n softwar e.

An iniLi al simulation was run u ing the 16-bit PLC simulator Lhat w as included with Concept. This was a very us ful first step b ecause it show d how the vari abl · values cha ng d during the simulation. A well, it provided a m a ns Lo ensur thaL the cod e wa writt n correctly a nd t hat it did not con tain a ny rror . Wh n the tank simulaLion was initia lly cr eated sev ral funct ion blocks w r I lac d in the wrong order. Wh n this code was run in th - simulaLor , an error m es ag was dis played a nd some of th vari able values were show n as AN (n ot a real number). Thes two piec of information uggested that th error was due to attempting to Lak Lh squa r root of a negative numl>er in t he calcul at io n of the flow rate b ·t . w ·e u t he tauks.

After t his rror was carr cted , L he imulation ran with no rror . While th

simul a tio n was running , it was observ d L hat t he variabl values w re cha nging as

expect d. Upon initia l startup the ource control va lve was open a nd Lhe level values

we re incr easing. When the Level2 variabl (water level in ta nk 2) r ached 0.55 , the

>-rj

cfq'

c

CD

~

~

0 0 ::l

(")

tQ

CD

"0

--.1

(/)

§' c

~

c;·

::l 0 r 03.

lrlilln_Level1 0 Flow1 Are.r 1.0 . 0.0 0.5

:ro~nk 1 ( 1)

INTEGRATOR1

y

a ..

. .4.3(2) .

Net_Flow1 low1

Flow12

. .

- [ j X

: I f'1pe 1 2 l!lliJ f3

·Level1 '·Levet2

Wln_lnel2 0 Floool2 Are•

1.0 0.0 . 0.5

T •nk_2 ( 1) INTEGRATOR1

loool2

Min_Level3 0 FloW) Are•

1.0 0.0 . 0.5

•v•

lM.:>=I

I

.

Vlve_Cmnd3 0.0 flow_Out3

I 1 1 STEP2 PV SP t.fAN_AUTO PARA

OUT

DEV

evel3

. , . c

IPC~N~tFI!l!!!d

IN1 ·

. .

low3

'·"

I

I

• I

source cont rol valve closed and the water lev ls dropped until Level2 reach ed 0 .45 when the control valve opened again and t he levels started to increas .

4.3 Graphical Display

Although using the 16-bit PLC simulator was useful in proving th at th e Con ep t code was correct and tha t the variable values changed as exp ected , i.e. increased to 0.55 a nd t hen dropp ed to 0.45, th ere was no indication of how closely th simulation matched th e Simulink results. Con cept does n ot provide a way to plot variable values on a graph. As well there was n o way to te t the operator interface. To mak t he simulation a li ttle more realistic and more useful to th user, t he imulation was downloaded and run on a PLC and Fact ory Link was used to display the re ul t . Figure 4-5 is a creen shot of the Factory Link application created for t his proj ct.

Fact ory Link was configured to read th e water levels fro m registers wi thin t he P LC , read th controller stat e (on or off ), read t he state of t he tank 3 ou tlet valve ( ope11 or closed ). The water levels were displayed in th ree different ways. F irst th e ch ang ing levels were displayed in the form of t he animation of water levels rising a nd falling in t anks. Secondly, t h e ch anging levels were indicated on the bar graphs below the tanks. Thirdly, each level was plotted on a trend ch art on an other s reen. T h controller state was indicated by a digital light n ear t he source con trol valve. W h n the cont roller was on , the light was green and when the con troller was off t h light was red. The tank 3 valve p osition was indicated in a simil ar fashion using the m anual valve graphic on the o utlet of tank 3. Additionally, th e source con L rol valve could b turned on and off by clicking t he control valve g raphic on the Factory Link screen .

T he Factory Link application wo rked exactly as exp ected. All values w re d is-

played as exp ected and t he configured alarms worked properly. However th e level

t rend did not plot t he level values as expected . It was h oped th at t he t r nd would

produce a plo t of water level versus time, for each tank, similar to t he Simulink plots.

• APPUCA TION 1!!1~ EJ

Overview Area1 Area2 Area3 Trendlvl Shutdown System I _!j

Infinite Source

~ ...

()q (:::::

..,

(1)

..,..

c.n

~

0 ..,

'<

tv ~ =:l

CD

(f) ( j

....,

(1)

10

(1)

=:l

0' ..,

(f)

s·

(:::::

p;

M-

o ·

=:l

0 0 0

Level1: 0 .705735 Level2: 0.473551 Level 3: 0.266747

This did not occur . Although the level trend did plot the changing water level , the scale was not big enough to provide an overall picture of how th e system was per- forming. As well there wasn 't an easy way to print the trend r suits. Since Factory Link automatically generates a file containing a ll the values used in a trend , it was decided tha t t hi s fi le would be imported into Microsoft Excel and the values would b e p lotted t h re. Thi plot is shown in Figur 4-6.

A close comparison of th Simulink results and the Factory Link res ult sh ows t hat the two imulations match very closely. Exce pt for a difierence in scale' , th two simulations are identical. This lead s to the conclusion that i t is possible to u e Concept to create both the simulation and the control and have the code run within a PLC.

4.4 System Timing

One of the most important issues in any control system is timing. Most industrial processes today h ave a centrally located controller communicating with numerous remote input/output racks located throughout t h plant. Figure 4-7 is an example of such a PLC n twork used at a Pulp and P aper mill [ 11]. In this p articular setup, each major component of the p aper making process h as it' own controller communicating with several remote I/ 0 racks as well as the DCS system. To tart and t op motors, commands com e from the operator interface through the DCS to the PL . The tart command is a pulse from zero to one and the top is a pulse from one to zero. The PLCs interpret t hese pulses and turn the appropriate ou tpu ts, in the I/ 0 racks, on and off. T he question for logic d signers is how long sh ould these pulse b . If the puls is too s hort, t he PLC would not see it or would not h ave time to nergize the o utput.

If it i too long it m ay interf r with m rgency stop logic in th PLC. Being abl

to simulate the entire system with communication tim d lays will provide engin e rs

with the ability to determine the appropriate pulse lengths prior to commissioning.

-.; > ..

...J ..><

c ..

1-

g:

Ol 0 0 Ol

....

"'

N

...

"'

M

a;

... ~

"'

~

""

~ ....

Ol

""

"'

""

""

Ol M

""

0

10 a;

"'

N

"'

"'

M N

"'

... ~

"'

""

...

""

~ ....

~

~

~

c;;

N N

~

::l

N

...

0 N

~

~

....

"'

"'

~

g

... ';;'

~

Figure 4-6: Graph of Water Level vs Time For One PLC Simulation

31

!~I ..

I : ! ^I

•b

^I

/ :

..:c _... I

0

~ I

~

_z: ~ I

c c

:E 0

I

~

'J:l

u

VJ

u ·a

~ ^:I e e 0

u

~

I

~

~~ ^{~ Q.,}

Figure 4-7: Typical Control etwork

W ith several thousand motors in a plant , this would save significant commissioniug time. As well, it also gives d esigners more confiden ce that the system will work as d esigned .

In order to incorporate t hese issues into simulations using PLCs, th e control logic and plant mo del can be split up b tween s veral con trollers connect d to a comm on communication network. One con troller would contain th control logic while th oth- ers would contain the plant model, for exampl one controller for every field I/ 0 rack.

This ensures that the control logic will execute at th e same rate as it will when con- trolling t he live plant (no plan t model logic to execute) and it allow communication network characteristics to be part of the simulation .

The above men tioned t hree tank example was split between two Mom n tum P LCs to test thi idea. Data was passed back and forth b etween the PLCs via a Modbus Plus network. Figure 4-8 is a pi cture of the PLC setup used for this simulation .

Figure 4-8: PLC Simulation Equipment

Figure 4-9 shows t he water level vs tim tr nd for the simulation. This trend h as the same basic shape as the on e PLC simulation trend , h owever the time span is longer and the maximum level of Tank 1 is n ot as high as in the one PLC simulat ion.

33

In the one PLC simulation the level reached 0. 1129 meters whereas in th two PLC simulation it only reached 0.79931 meter . The increased time pan is a result of Lh time delay in troduced by the communi cation network, it took longer for the operator interface to read the same number of p oiuts from the plant model PLC . The diHereu c ~

in tank levels is a result of the control logic executing faster th an in th e one PLC

simulation. Since the control logic PLC only had three fun ction blocks to xe u te,

as opposed to eighteen in the one PL simulation , it was able to react to Lank level

c h an ges faster. Figure 4-10 combines all thre imulation res ults.

("')

..,

Ol

..,

N Ol

,._

Ol

"'

"'

"'

"' :;

"'

("')

00

"'

"'

,._ ,._

.., ,._

"'

N

,._

c; ,._

("')

,._

"'

"' ...,

"'

(0

"' ..,

(0 ..,

("') ("')

..,

"'

0

..,

~ ,._ ,._

... ~

"' ..., ...,

;;:;

...

("')

"'

("')

"'

"'

("')

,._

("') ("')

"'

0 ("')

00

..,

..,

,._

Ol Ol

"'

:;

M

..,

"' .., ,._

Ol N

Figure 4-9: Graph of Water Level vs Time For Two PLC Simulation

35

oq" ~

~

>-!

(1)

..,.

I f-'

0

0 0

u s

s·

0..

~

w en o:> E.. _.,..,..

en 0 _,

~

r-3 ::r

>-!

(1) (1)

en a ·

~

~

C"t"

a· t:l en

Simulink SiiTIUalion

§:

r .... (s)

PLC Simulation

0.90000 , - - - ,

0.80000

0.70000

0.60000

§: 0.50000

~ ~ 0.40000

0 30000

0.20000

0.10000

1 28 55 82 109136 163 190 217 244 271 298 325 352 379 406 433 460 487 5H 5" 568 595 622 649 676 703 730 757 784 811 838 865 892 919 946

- - Levell (One PLC) - -Level 1 (Two PLCs)

· •· • · · Level 2 (One PLC) - . - Level 2 (Two PLCs)

- ··--Level3 (One PLC)

- -Leve13 (Two PLCs)

Chapter 5

DCS Simulation

5.1 Terra Nova Simulator

As mention d in Chapter 2, the Terra Nova Allia nce u ed t he Hardwar -Software meth od to simulate t heir Floating Production , Storage and Offioading (FPSO) vessel.

Developed by Fabcon Canada b eLw en SepLember of 1998 a nd Fe bruary of 2000, this simulator h as four ma in compone nts:

• Op raLor Interface Stations (OIS ) and Engineering WorksLaLion (EWS)

• Pro es antral nits (P C

• The simulation compu ter

The OIS, EWS and PCUs are part of th e ABB INFI90 Di tribuLed antral System (D CS). The simulation computer i a stand a rd Pe ntium based P running specialized simulation sofLwar , to be discu ed later. The simulation omput r communicates with the P s via thernet an d Univer al Simulation Mod ules ( SM). The SM i specialized add-on to the INFI90 D S that acts as a bridge b Lw en th Eth rn L based simulaLion n twork and t h Controlway, as shown in Figur 5- l. During sim- ulation, the USM redirects the inpuL/ou tpuL data from th I/ 0 modules in the DCS to the simulation oftware.

37

UP TO &4 REAl 110 MODULES

{

with SIMULATION

copet>Wity

SIMULATION COMPliTER(S)

Figure 5-l: Simulator Layou t Using ABB Universal Simulatio n Modules [1]

Physically, these modules are located in the PCUs next to t he process controllers.

Typi cally, t here is one USM p er process con troller. F igure 5-2 sh ows h ow the modules are laid out in each of the PCUs used for this simulator. The simulation PC runs a software package called Dyn amic Simulator for Process Instrumen tation and Control Engineering (D-SPICE) . D-SPICE was developed by Fan toft Process Technologies AS, parent company of Fabcon Canada, for the purpose of simulat ing process systems, such as oil and gas production [12, p.2]. Models are created in t his software by simply connecting together co mponen t function blocks, shown in Figure 5-3. The components themselves are modelled by mathematical equation s written in C/C++.

This cod e is hidd en from the user, however, D-SPICE does allow for the u ser to create

his or h er own function blocks [12, p.4] .

T"l·PCS

~4PSII

I

s s ^L.4 s s

v v 0 v v

I s lA. ^{1-l s s}

1-l 1-l L.4 u ^L.4 u

I ^p r s ^r s

s ^{L.4 p L.4 p L.4}

1-l 1-l L.4 u L.4 u

I ^p r s ^r s

s ^{L.4 p L.4 p L.4}

1-l 1-l L.4 u

I ^p r s

s ^{L.4 p L.4}

\

UniYers;d Sinwlztion M.adi.W:s

1-l 1-l u ^L.4 u

I ^p s ^r s

s ^{L.4 L.4 p L.4}

Cantrulkrs

I I I I

c c c c

L L L L

I "lH4U01 I

Figure 5-2: Terra Nova PCU Layo ut

39

Ther are ertain system s such as t h rmodynamic system , who mathematical models are compl x and require large a mounts of comput ational power. Simulating thes syst m u in g their mathem atical m del s would slow down th simulation to the poiut of making it unusable. Iu D-SPI E simplified version of these systems are modelled using look- up tables and regr sion . The data r quir d for the e mod ls is usually generated by dedicated oftware, such as Peng-Robinson for th rmodynamic systems and i specific to the particul r 'ystem being model! d [12, p.4].

5.2 Hibernia Simulator

Chapt r 2 also meution a Hardware to Hardware ' imulation that Bailey SEA (Nftd .) Ltd. and SEA Sy tern Ltd. use to test Hibernia's Fire a nd Gas (FGS) Em rgen y Shut Down (ESD) control system. T he control y tern containing the logic to be tested is an ABB I FI 90 DCS, similar to the one used for th Terra Nova simulator mentioned above. The slave controller i a Triconix PLC. I/ 0 data is passed back and forth betw n the systems via th lNFI 90's General Purpo Interface (GPI).

The GPI is a component of the ABB D S that allows the D S to communicat with a variety of PLC brands. The so ftware is designed such that the GPI can b reconfigured to communicate with a vari •ty f different PLC brands. Figure 5-4 shows the layout for this syst m.

The PLC h as two seri al ports. On port i onnected to the GPI and t he other is connected to imulation comput er. The im ulat ion operates as follows:

• The omputer f eeds input value to the PLC

• Based on th e values and the s quen e of events logic, t h PL write appro- pri ate data to it 's memory registers

• These registers ar then read by th DCS and dealt with ac ordingly, i.e. alarms

are triggered, equipment is turn ed on or off, etc.

.. 8

~

@ ^{<1> (/) (/)}

-it ^<1>

:I:I

--- - - - - -- - >

·!

^{ir~ c 0} 8

"!i ^·v; "<!'

X

^c J

d' ,.- ~~ ^C'O

:::E

a.

· i ^{i w X} _~

....

-~® ^~

i ^I "'

::E)

. · I

~

_{~ --0{·-} ^~§

'ill

. R !

"'

- i _<lii

' !

Figure 5-3: Terra Nova Simulation Logic

41

DC'S

PLC'

Simnbtion (' ompnter

Figure 5-4: Blo k Diagr am Layout for Simu la t r

• PL r gis ters are updated wi th outp ut d ata

• Output da ta is ent to comp ut r t d tcrmine next set of data

) ^{REGISTER 31086}

BAS 0Q

) ^{REGISTER 31 08 7} ) ^{REGISTER 31088} ) ^{REGISTER 31089}

< igur 5-5: Logic Requir d t Read PLC Memor R gi Ler

F igure 5-5 show part of the l gi r quir d to access xt -rna l data via t he GPI.

The BASROQ function block (fun Lion od 137) is t he blo k th a t read th data

from the PLC and makes it availabl to re L f the control log i . The oval on the

righ t ha nd id of Figure 5-5 are cro r f rene blocks th at link this piece of logic to