Safety and Computer Control

8/13/2019 Safety and Computer Control

1/11


2/11

IChemE SYMPOSIUM SERIES No 115Alarms, Tri ps and I nt er locks

It i s perhaps useful , in the context of computer co nt ro l , to discusswhat is meant by these in ter re lat ed terms:

* Alarm: an ind ica tion tha t some abnormal condit ion or event hasoccurr ed. Alarms are normally tri gger ed by the changein st at us of di sc re te input signa ls or by the value ofanalogue input signals going beyond some pre-definedlimit .The syntax of an alarm is i f ( st at us ) then (di sp la y)

* Tri p: an act ion tha t is taken due to an alarm being i n i t i a t ed .The ac tion taken is determined by logic and re al ise d bysoftware, which may be ei the r configurabl e (e .g. logi cblocks) and/or procedural (e.g. sequence coding).The syntax of a t r i p is i f (alarm) then (act ion )

* Interlock:anaction thatisprevented until certain conditionsaresatisfied. Again,the logic is realised by meansofsoftware. Theconditions testedmay ofcourse includealarms.The syntaxof aninterlockis if(status)and (status)then (action)"

Standard Alarm FunctionsThe principal functions offered by most proprietary systems forhandling alarmsare asfollows:* configurable alarm settings(e.g. hihi/hi/lo/lolo)* reserved display areas (banner lines)* integrationofalarms with faceplate displays* interface with graphics displays* use ofcolour coding/flashing* annunciation/acknowledgement ofalarms* comprehensive alarm lists* alarms includedinevent logs/recordsThus, forexam ple, assuming appropriate alarm settings for a signalhave been entered in to thedatabas e, oncethealarm isinitiated,itshould automatically findits waythroughto thereserved display area,toall the relevant faceplate and graphics di splays, onto the alarmlistandintotheeventlog.Alarm lists typically providefor:* groupingofalarmsinuser defined areas* priority levelsto beassignedtoalarms* listingofalarmsinchronological order* identificationofalarmbybothtag no. andname* timeanddate stampingofalarms* observationofcurrent statusofalarms* multi-pa ge listingofalarms


3/11

IChemE SY MP OS IU M SERIESNo.115There is of course much more to an integrated safety environment thanjust being able to handle/displ ay/log a lar ms. In the context of batchprocess control this is inextricably linked to the system's sequencingcapability.Structured Batch Control LanguageIt is perhaps also useful to revie w what is meant by a structured batchcontrol language . The most common type is a high-level language with aprocess orientated instruction set of mnem onic and argument form. Itprovides a framework within which applications software may bedeveloped. This framework has a hierarchial structure as shown inFigure 1, and discussed in detail in Ref 2. An important point toappreciate is that the provision of such a framework as standard andproven is fundamental to the flexible development of reliable andeconomical applications software.Two terms in particular are worth further expla nation: sequence andrecipe.Sequences contain generic informati on, and are not specific to anyparticular grade of product. They consist of a number of functionallyrelated processing operations and stages which have to be executed inorder during the course of a bat ch. Each stage consists of a number ofevents and actio ns. Sequence development consists of a pragmaticprocess of alignment of appropriate instructions against these eventsand actions. Sequence progression is determined by logic in accordancewith the status of the plant and time, subject to any softwareconstraint s.

Recipes contain specific information and are used in conjunction withsequences to enable production of batches of particular grades ofproduct. There are essentially four attributes to recip es:* Formul ation, that is which reagents are involved, where they are to

come from and in what or der , and the quantity of each requi red.* Operating cond itio ns, that is set points and ramp rates for control

loops, set tings/limits for a lar ms, tri ps, et c, conditional testdata, time delay s, and so on.

* Status information, that is flag settings for loop and sequencestatus, plant availability, operator access, etc, andinitialisation of digital outputs;

* Recovery opt ion s, that is, criteria for handling the progression ofabnormal batches, for example branch forward/backward within asequence, jump into shutdown sequ ence, hold, advance in man ual ,etc

The use of a structural batch control language is the key toapplications diagnostics which, together with the standard alarmfunctions, enable a truly integrated safety environm ent.

337


4/11

IChemE SY MP OS IU M SERIESNo.115Applications DiagnosticsThis section is reproduced from Ref 3. At their lowest lev el,application diagnostics are embedded within the main control sequencesand are simply used to activate alarms. More complex self-diagnosticsare usually in the form of dedicated sequen ces, or su b-sequ ences, thatrun in parallel to the main control sequence , and typically initiaterecovery opti ons. These are well illustrated by considera tion of abatch reactor.For exam ple, during the charging stag e, having sent out a signal toclose the drain valv e, the sequence would wait a few seconds to allowfor the dynamics of the va lv e, and then check the input signalgenerated by an associated proximity switch, the pair of discreteinput/output signa ls being treated as an entity. If they were notconsistent, an alarm would be initiated, otherwise sequence flow wouldprogress to opening the vent and feed valv es etc. Subsequently thesequence would monitor the level or weight of both the feed tank andthe reactor. These of course should correspond. If they were notwithin limits an alarm would be generated.For exothermic reactions, it is usually during the initial stages thatthe reactor is most unstable and control needs to be tightes t. Anysignificant increase in batch temperature would almost certainlyactivate an alarm, if not trip a shut-down seque nce. How ever , towardsthe end of the batc h, once the exotherm is spent , the batch temperaturemay well be raised deliberately, say to drive the reaction tocomplet ion. That same alarm would be activated. If this were Cohappen repeate dly, it would become a nuisance and in due course wouldbe ignored, which is inherently dan ger ous . In these circumstances itis appropriate for some embedded diagno stics to override the alarm,dependent on the stage of the batch.Another related hazard arises from the continued addition of reagentsto the reactor whe n, for some reas on, the reaction goes too slowly oreven fai ls. This can result in an exotherm beyond the capacity of thecooling system whe n the reaction does eventually get goin g. Adiagnostics sequence can be used to calculate, in real-time, a dynamicheat balance across the reactor, taking into account the potential heatevolved from the weight of reagents added and, if necessary, closingthe feed valves. This is inherently far safer than relying solely on ahigh temperature trip.On a large integrated batch plant, in an emergency situation, manyalarms and trips will occur quickly and it is unreasonable to expectthe operator to be able to interpret the significance of them al l. Aparallel diagn ostics sequence can be used to filter them, on a prioritybasis, and to focus the operator's attention on the mos t significantones. In partic ular, the sequence can logically analyse certaincombinations or patterns of alarms and automatically initiate recoveryoptions or shut-down.Applications diagnostics, as in the above examples, are practical andcan be realised using the existing functional capability of computercontrol system s. The potential for such diagnostics is often not fullyappreciated - they offer scope for substantial improvements in plantsafety, for relatively little in additional costs.

338


5/11

IChemE SYMPOSIUM SERIES No 115I n t h e c o n t e x t o f b a t c h p r o c e s s c o n t r o l , and a l s o f o r t h e s t a r t - u p ands h ut -d o w n o f c o n t i n u o u s p l a n t , a p p l i c a t i o n s d i a g n o s t i c s a r e p e r h a p s t h em o st s i g n i f i c a n t c o n t r i b u t i o n t o s a f e t y t h a t c o m p u te r c o n t r o l c a n m a k e.Exper t Sys t emsT h e r e i s m uch e n t h u s i a s m a b o u t t h e p o t e n t i a l f o r e x p e r t s y s t e m s an dt h e r e a r e v a r i o u s r e a l - t i m e a r t i f i c i a l i n t e l l i g e n c e e n v ir o n m e n tsa v a i l a b l e , e . g . MUSE, G 2 , e t c . I n t h e c o n t e x t o f p r o c e s s c o n t r o l ,e f f o r t s h a v e m o s t l y b e en d i r e c t e d t o w a r d s a l ar m h a n d l i n g , f a u l td i a g n o s i s an d p r o d u c t q u a l i t y , Re f 7 .I n e s s e n c e , t h e e x p e r t s y st em s i t s a l o n g s i d e t h e p r o p r i e t a r y c o n t r o ls y s te m a nd h a s a c c e s s to i t s r e a l - t i m e d a t a b a s e . The c o n t r o l s y s te mf u n c t i o n s a s n o r m a l , t h e e x p e r t s y s te m o p e r a t i n g i n an o n - l i n e a d v i s o r yr o l e .The ex pe r i e nc e ga ined i n t he RESCU p ro j e c t , f o r exam ple , i s o fi n t e r e s t . T h i s c o n c e r n e d t h e d e v e l o p m e n t o f a n e x p e r t s y s te m f o r a ne x i s t i n g b a t c h p oly m er p l a n t . D e s p i t e c o n s i d e r a b l e de v el op m e nt c o s t s ,t h e o p e r a t o r s a r e n o t ( y e t ) r e l y i n g o n t h e s y s t e m s r e c o m m e n d a t i o n s ,Ref 8.The use o f ex pe r t sys t em s i s i n i t s i n f a nc y and i s somewhat ana logo ust o t h e e a r l y a t t e m p t s a t c o m p u t e r c o n t r o l . T h e r e i s a l o t o f s c o p e f o rs p e c t a c u l a r f a i l u r e P r a gm a t is m w i l l l e a d t o e x p e r t s y s te m s b e i n ga p p l i e d t o s m a l l an d w e l l - d e f i n e d t a s k s , i n w h ic h e x p e r i e n c e an dco nf id en ce can be ga in ed , and where some payback can be i d e n t i f i e d .I t w i l l b e a l o n g t i m e b e f o r e t h e c h e m i c a l i n d u s t r y , w i t h i t s p r o p e rs e n s i t i v i t y t o s a f e t y an d e n v i r o n m e n t a l i s s u e s , h a s t h e c o n f i d e n c e t oc l o s e t h e l o o p a ro u n d a r e a l - t i m e e x p e r t s y st em in e a r n e s t .

S o f t w a re b a s e d c o n t r o l an d s a f e t y s y s t e m s a r e c r i t i c a l l y d e p e n d e n t o nt h e i r s u p p o r t i n g h a r d w a r e . T h e re a r e t h r e e a s p e c t s t o t h i s o fi n t e r e s t : r e l i a b i l i t y , w hich i s d i s c u s s e d i n d e t a i l e d i n Ref 3 ,a r c h i t e c t u r e , a n d p r o t e c t i o n .A r c h i t e c t u r eA v e r y o b v i o u s t e c h n o l o g y - d r i v e n t r e n d h a s b e e n to w a r d s s y s t e m s w i t hd i s t r i b u t e d a r c h i t e c t u r e . H igh s pe ed and r o b u s t s e r i a l c o m m u n ic a ti on sl i n k s - r e f e r r e d t o a s d a t a h ig h w a y s - h a v e e n a b l e d p r o c e s s o r p ow er t ob e t a r g e t e d v e r y e f f e c t i v e l y . Fo r e x a m p le , r em o t e i n p u t / o u t p u t ( i / o )s i g n a l p r o c e s s i n g , l o c a l c o n t r o l u n i t s and i n t e l l i g e n t o p e r a t o r c o n t r o ls t a t i o n s , a r e a l l c o m m o n p l a c e n o w .

339


6/11


7/11

icnemES Y M P O S I U MSERIESNo.115Fundamental to choosing a system, developing the applications softwar e,and testing it are the functional specifi catio ns. These provide thebasis for all aspects of quality assurance, in particular of theapplications sof twar e, and are discussed in detail in Ref 11 . Thereare several stages:1 User requiremen ts specifi cation. At this stage the users

requirements are defined in sufficient detail to enable thesuppliers to tender for the work. The user should specify theproblem and leave the suppliers to work out the solut ions.

2. Detailed functional specificat ion. At this stage the chosensupplier and the user together sort out precisely what the systemis required to do in all circums tance s. This involvesconsideration of the safety requ irem ents. For batch systems thisincludes developing sequence flow dia gram s, or equiva lent. Thesupplier and user must reach agreement on what functions are to beprovided to meet the users requ irem ents , and what resources willbe required.

3 . Software specificat ion. At this stage the supplier specifies thedetailed design of the applications software: this will consist ofdatabase tables to be operated upon by re-entrant routines,procedural coding to be interpreted in a real-time multi-tas kingenvir onmen t, etc . The supplier then develops the applicationssoftware to that design and tests it against the detailedfunctional specification.

4. Acceptan ce testing. At this stag e, an agreed series of tests arecarried out to demonstra te to the user that all the requirementsof the detailed functional spec ification have bee n satisfied.

The amount of effort and commitm ent, from all pa rtie s, necessary todevelop the specification and to produce the documentation inconformance with acceptable quality assurance criteria should not beunder-es timated. Neither should the costSequence Flow DiagramsIn essenc e, these are a graphical representati on of the process eventsand control act ion s, and of the logic interrelating them, organised insuch a way as to depict the sequence progres sion. Various alternativerepresentations are discussed in detail in Ref 12 , but SFDs are themost common.They are developed from a detailed analysis of process opera tion s, asoutlined in Ref 2.Analysis occurs at two levels. At an overall lev el, operations arebroken down into units and sta ges , either on a process or item basi s,and seque ntia l, parallel and common operations are identified. Anexample of an SFD at this overall level is shown in Figure 2.These operations are then broken down at a detailed level into discreteevents and actions.


8/11

IChemE SYMPOSIUM SERIES No 115Note in pa rt ic ul ar tha t:* agreement must be reached on how every opera tion i s to be car ri ed

out . This leads to a fu ll er understanding of the pro ces s/ plant andoften re su l t s in di re ct improvement/savings in i t s e l f ;

* some 60-80% of the SFDs, and hence of the applications software ,wil l be devoted to handling safet y funct ions , i . e . alarms, t r i p s ,int er loc ks , di agnos ti cs , et c, and to recovery options for handlingabnormal conditions.

* the S F D s m u s t be b o t h c o r r e c t and c o m p l e t e w i t h r e g a r d t o d e t a i ls i n c e the i n t e g r i t y of the s y s t e m i s i n v o l v e d .HAZOPThe positionofHAZOP studiesin thesoftware cycleis as indicatedinFigure3. An important point to appreciate is that it isthedocumentation,e.g. theSFDs alongsidethe P & IDs, whichissubjecttothe HAZOP studies,and not thesoftware itselfIn general,if there has been a change in the detailed functionalspecification, dependingon thenatureandscopeof thechange,itwillbe necessarytocarryoutfurther HAZOP studies before implementingtheappropriate software changes. However, mistakes in the softwarerevealed during commissioningcan be correc ted, without further HAZOPconsiderations, provided the functional specification has not beenchanged.Software ChangeOneof theprincipal advantages ofcomputer control is the increasedflexibility thatitoffers,see Ref 1.However, increased flexibilitycan be somethingof a liability. Thusitis easy tomodify sequences, reconfigure loops,and even try outcompletely new strategies. All that is required, in theory, is todevelop appropriate software usinganon-line editor,and to activateit. In particular, the implementation can be made quickly comparedwiththepantomime that would be involved inmaking the same changeswith an equivalent hard-wired system. This flexibility can leadtoreal improvementsinplant perfor mance, reliabil ity,andsafety.Butit iseasytolose trackofwhat changes have been mad e, especiallyif they have been made regularlyor bymore thanoneperson. Als o,itis easytomake mist ake s. Without carefulandsystematic developmentof software cha nge s, coupled with thorough checkingandtesting, faultscanbeintroduced thatdo notimmediately manifest themselves. Unlesscare is taken in regulating software chang es, its integrity isjeopardised. Current thinking is that access to software mustbehighly restricted and, in particu lar, that software changes mustbetreated just as seriously as changes to the plant. They ust esubject to the same rigorous management procedure and safetyassessment.


9/11

IChemE SYM POS IUM SERIES No 115

T he p r o c e d u r e i s d i s c u s s e d m o r e f u l l y a nd a s p e c i m e n m o d i f i c a t i o nc o n t r o l fo rm p r e s e n t e d i n R ef 6 .

CONCLUSIONI n s u m m a ry c o m p u t e r c o n t r o l h a s a g r e a t d e a l t o c o n t r i b u t e t o p l a n ts a f e t y e s p e c i a l l y f o r b a t c h p r o c e s s e s . H o w e ve r i t i s c r i t i c a l l yd e p e n d e n t u po n g oo d p r o j e c t e n g i n e e r i n g w h i c h t o a l a r g e e x t e n t i sd e t e r m i n e d b y t h e q u a l i t y o f t h e s p e c i f i c a t i o n s a nd t h e d o c u m e n t a t i o n .T h e s e a r e v e r y m uc h a f u n c t i o n o f t i m e a nd e f f o r t a n d e x p e r i e n c e .

REMEMBER: s a f e c o n t r o l i s n o t c h e a pc h e a p c o n t r o l i s n o t s a f e .

REFERENCES1 . L o v e J . B a t c h P r o c e s s C o n t r o l C h e m ic a l E n g i n e e r 4 3 7 p p 3 4 - 3 5

J u n e 1 9 8 7 .2 . L o v e J . S t r a t e g i e s f o r B a tc h C o n t r o l C h e m i ca l E n g i n e e r 4 4 0 p p

2 9 - 3 1 S e p t e m b e r 1 9 8 7 .3 . L o v e J . C o n f i d e n c e i n C o n t r o l C h e m ic a l E n g i n e e r 4 4 3 p p 3 6 - 3 8

D e c e m b e r 1 9 8 7 .4 . L o v e J . T r e n d s a nd I s s u e s i n B a t c h C o n t r o l C h e m i c a l E n g i n e e r

4 4 7 p p 2 4 - 2 6 A p r i l 1 9 8 8 .5 . L o v e J . H o r s e s f o r C o u r s e s b e f o r e C a r t s IE E C o l l o q u i u m L o n d o n

D e c e m b e r 1 9 8 6 .6 . L o v e J . U s e r G u id e t o P l a n t C o m m i s s i o n i n g C h a p t . 6 . I . C h e m . E .t o b e p u b l i s h e d .7 . S h o r t e r D . IK BS i n t h e P r o c e s s I n d u s t r i e s I . M e c h . E . S e m i n a r

M a n c h e s t e r S e p t e m b e r 1 9 8 8 .8 . L e i t c h R . RESCU R e t r o s p e c t i v e R e v i e w H e r i o t - W a t t U n i v e r s i t y

M a y 1 9 8 7 .9 . B e n s o n R . P r o c e s s S y s te m s E n g i n e e r i n g : P a s t P r e s e n t a n d f u t u r e

I . C h e m . E . C o n f e r e n c e S y d n e y A u g u s t 1 9 8 8 .1 0 . P r og r am m a b le E l e c t r o n i c S y s t e m s i n S a f e t y R e l a t e d A p p l i c a t i o n s

H S E 1 9 8 7 .1 1 . G u i d e l i n e s f o r t h e D o c u m e n t a t i o n o f S o f t w a r e i n I n d u s t r i a l

C o m p u te r S y s t e m s I E E 1 9 8 5 .1 2 . M a L l a b a n d S . T he S p e c i f i c a t i o n o f B a t c h P r o c e s s C o n t r o l S ch e m es

b y t h e u s e o f F lo w C h a r t s I . C h e m . E . C o n f e r e n c e L e e d s S e p t e m b e r1 9 8 8 .

343


10/11

IChemE SYMPOSIUM SERIES No. 115

Batch master

\

Recipes

\ S.Sequences\

Stepsl\Subsequences

Scheduling

Parallel operations

Instructions

Sequence structure

Commonoperations

Process stages

Discrete events/actions

AlignmentFigure :F r a m e wo r kforappl ica t ions sof tware

ci f icai ion -*-

HAZOP

Develop Software

Test Software

I ns ; a 11 a t o n

S S i O R S i .

. :. . :.

Figure 3344


11/11

IChemE SYMPOSIUM SERIES No 115rs

345

Documents

Safety and Computer Control