Safety Analysis for a Pipeline Control System

Co pyrig ht © IF .-\ C Cont rol in Trall sporta tion Syste ms. \'ie nna ..-\ us tr ia. I ~I Hti

SAFETY ANALYSIS FOR A PIPELINE CONTROL SYSTEM O. Nordland and G. Rabe Tecil lliscil",. L"bflwachlmgsl'neill Sorddeu Ischlalld e. F .. H amblog, FR G

Abstract. Computers and microprocessors are penetrating into safety relevant areas . The problem of proving their safety and reliability is becoming increasingly important, particularly for software. Various quality assurance methods for hard and software are outlined. Using a pipeline control system as an example, the practicability of such methods is shown. Keywords. Pipeline; control; software; computer testing; quality control. the proof that particular components, such as assembly units for example, fulfil the safety reqUirements can be given. The manufacturer can then produce exactly this kind of hardware and the user apply it without further testing.

INTRODUCTION The technical developments of the last few years have shown that process controlling computers and microprocessors are penetrating more deeply into areas with safety relevant requirements. Such systems, including their software, must be qualified in respect to these requirements.

Nowadays the functional tests of components and the whole system, as will be described below, are more widespread.

The safety proof must demonstrate that the safety relevant demands have been complied to. To this end, all safety relevant functions and operating conditions must be defined and demonstrated for the technical device being examined. For computers, the safety requirements will result from the requirements for the process or the total system.

Software There is a number of different procedures for demonstrating the safety of computers and microprocessors. They can be subdivided into procedures that accompany the development of the software and procedures that are applied after the software development has been completed . Figure 1 (see end of text) gives an overview of the possible demonstration procedures. The following procedures will be described in more detail: quality assurance via structured programming; - statistical methods; - human testing; - analyses .

Particularly in coastal regions, oil winning and transportation require a large amount of safety technology in order to comply with the requirements of labour and environmental safety. Using a pipeline control system as an example, the procedures that can be used for a safety proof will be shown .

Structured programming (Fig. 2)

To start with, we shall describe some of the examination procedures and the structure and function of the pipeline control system.

The development process for software should be done in the steps: - creation of a requirements' definition; - creation of a system specification; - coding and test. During the course of development it is possible to check if the rules o f structured programming have been adhered to at each step. The requirements ' definition is examined with respect to realisability, the system specification with respect to clarity, completeness, uniqueness and consistency . In addition , the correspondence of the system specification with the requirements ' definition is checked. The programme listings are examined with respect to clarity and formal structure and also

QUALITY ASSURANCE Hardware The principle demands made on hardware for safety relevant tasks concern: - failure behaviour (reliability); - time behaviour; behaviour under external influences. The possibilities of examining the properties of hardware during its production are very limited. Within the framework of prototype and aptitude tests

377

378

o.

:--;ordlalld alld (;. Rahe

compared with the requirements' definition and the system specification. Statistical methods (Fig. 3) Apart from the evaluation of operational experience particular mention should be made of the black-box test (also called input test). This test tries to find situations where the programme does not conform to the specification without using any knowledge of the programme structure. Test data are derived solely from the specification. In order to detect all errors using this method, every possible input combination would have to be considered. Since a complete test of all possible inputs is not possible for real systems, this method cannot guarantee the a programme is free of errors. Human testing (Fig. 4) This refers to examinations without the use of a computer. One-man and team methods can be distinguished. In the so called desk top test, the examiner reads the programme, examines it using an error list and/or manually simulates an error with test data. This is a purely subjective precedure which makes desk top testing less effective than the following two procedures. These procedures are team procedures which involve up to four testers working simultaneously on one programme. In a "Code Inspection", a team find errors by reading the code The necessary documents are listing and specification. The is examined using a check list errors.

tries to together. programme programme of known

In order to describe the actual function of the programme, the logical programme structure, the data flow and the processing algo rithms are derived from the machine code. By this means the correspondence between input and output data becomes evident. With this method, all the programme ' s reaction possibilities are determined or the necessary tests are specified in order to determine the reaction possibilities. Finally, the complete correspondence of the analysis results with the requirements ' definition is checked. A programme is only termed correct when it can react only in the way that was specified. REQUIREMENTS CLASSES Various, different requirements of safety and reliability can be made for a computer system. The various requirements can be compiled to five requirements classes as shown in fig. 6 . Class 1 with the strictest requirements, includes amongst others railway signal systems, class 3 gas and oil transportation systems (pipelines) and class 5 contains for example houshold appliances . The depth of examination inevitably increases with the safety relevance of a system and stretches from black box test to a programme analysis for the total system (Fig. 7). Due to its safety relevance, the crude oil transportation system described here is grouped in class 3. EXAMPLE OF A SAFETY PROOF

The "Walk-through " is a similar procedure to code inspection. The difference in the technique is that the team "simulates" the computer: test cases are prepared on paper that correspond to a representative set of inputs (and expected outputs) for the programme. The test cases are gone through during the sessions, whereby the state of the programme at each step is noted on paper . Programme analysis (Fig. 5) Programme analysis is one of the methods with the greatest examination depth. With this method, the requirements ' definition on the one hand is compared with the actually realised programme functions on the other hand . In order to achieve a comparison that is as consistent and error free as possible, it is necessary to have the requirements' definition and the programme structure in a transparent and formally similar representation. If the requirements ' definion exists in writing at all, it is usually in the form of a verbal description. In order to transform it into a formalised representation, computer aided specification tools are used. These tools force the use of a formal representation and allow this to be done with computer support.

The Pipeline Control System (Fig. 8) The purpose of the pipeline control system is to control and monitor the transportation of crude oil through two pipelines. For safety and availability reasons a redundant, spatially distributed process controlling computer system is used. An important component of the pipeline control system is a microprocessor controlled remote action system which transmits all measured values and commands. The pipeline control system must the following data volume: 82 analogue inputs; - 336 digital inputs; 16 analogue outputs; - 168 digital outputs.

process

As examples, the following tasks are performed: - collection of the above mentioned process variables; - representation of the process variables in overview and flow charts; - control of operational resources (e.g. pumps) by means of a function key board and colour display; - actualisation of operational and balance protocols .

379 The the

action system also pe~fo~ms coupling of the two compute~s, whe~eby one compute~ acts as main p~ocesso~ and the othe~ one "listens". Self tests cont~ol the components p~ocesso~, main data t~ack and pe~iphe~y and switch ove~ to the second compute~ when they detect an e~~o~. ~emote

Regui~ements

fo~

the

Pipeline

Cont~ol

System The basis fo~ the examination p~ocedu~es used by us is in the laws and ~egulations that the ope~ational licence was subject to. These laws and ~egulations a~e intended to gua~antee labou~ and envi~onmental p~otection. In pa~ticula~ situations this can only be ~eached by shutting the enti~e pipeline down.

all the functions input quantities defined ~esp. altered as is customa~y in black box testing. It was cheCked to see if the system pe~fo~ms acco~ding to its specification. When e~~o~s we~e encounte~ed in this phase the test sometimes ~eve~ted to a desk top analysis. Fo~

we~e

In one conc~ete case, during the test of the stationa~y p~essure monito~ing, spo~adic ala~ms occu~~ed which could not be explained by the given ope~ational conditions and the t~ansmitted data. The~efo~e, the test was supplemented by an examination of the p~og~amme listing and thus the p~ocessing done by the p~og~amme followed in detail. In this way a softwa~e e~~o~ could be dete~mined as the cause of the ala~ms.

The Examination CONCLUSION The examination of the pipeline cont~ol system was done in two pa~ts: a pu~ely compute~ specific examination and a systems enginee~ing examination. The compute~ examination aimed to show that the ha~dwa~e and pa~ticula~ pa~ts of the softwa~e fulfilled the ~equi~ements that we~e made not only fo~ safety, but also fo~ e~gonomic ~easons: - All dialogue functions we~e tested to see if ~idiculous ent~ies could lead to e~~o~s in the system. It was checked that all data that would be necessa~y fo~ a late~ evaluation we~e ente~ed into long te~m memo~y. This is pa~ticula~ly impo~tant fo~ a ~econst~uction of events afte~ a distu~bance.

The compute~'s behaviou~ when the ai~ conditioning system b~eaks down was checked. If the tempe~atu~e ~ose too high, the second compute~ must be switched in. - The most impo~tant point of these tests in ~espect to safety was the switching ove~ between the compute~s. By simulating ha~d and softwa~e e~~o~s, co~~ect switching ove~ was tested. All the

examinations desc~ibed so fa~ tests pe~fo~med di~ectly on the compute~ system
we~e

p~actical

In the systems enginee~ing tests it became evident that it was possible to simulate all the pe~missible and fo~bidden ope~ational coditions fo~ testing pu~poses using the p~inciple p~ocess va~iables p~essu~e, flux and temperatu~e. Fo~ this reason we chose a black box test to demonst~ate the co~rect behaviour of the system unde~ fo~bidden conditions. In this way, the following functions, amongst othe~s, we~e examined:

Put b~iefly it can be stated that both examination p~ocedu~es test applications and desk top analysis supplement each othe~ in a sensible way and lead to asse~tive ~esults with a ~easonable amount of effo~t. The the

expe~ience gained du~ing examinations we have perfo~med, pa~ticula~ly in the the examination of the pipeline cont~ol system, has ~evealed that the safety p~oof fo~ compute~ systems with safety ~elevant ~equi~ements can be given. The p~ocedures we have described make this p~oof possible. p~actical

The g~eate~ the safety ~elevance of a system, the g~eate~ must be the depth of examination. The total amount of effo~t and expense inc~ease with the examination depth. Thus economic aspects become inc~easingly impo~tant as the safety ~elevance of the system increases. Howeve~, they must not p~edominate! The amount of effort for a p~ogramme analysis is today between 50 and 100% of the effort fo~ development. In applications whe~e a p~og~amme analysis is ~ega~ded as being necessa~y, this is usually acceptable. In othe~ applications, where the safety ~elevance is not as high, the less expensive p~ocedu~es a~e adequate. For this ~eason we can state that safety analyses a~e possible with a ~easonable amount of effo~t which will diffe~ acco~ding to the application. FIGURES Fig. I: Safety and Reliability Fig. 2 : Structured

Delive~y

p~essu~e

p~essu~e

monito~ing

i.e. ope~ation of

P~oof

Compute~s

P~og~amming

monito~ing, du~ing

Fig. 3 : Statistical Methods

the pipeline. p~essu~e monito~ing, i.e. pressure monito~ing after the pipeline has been shut down. Any p~essu~e d~op could indicate a possible leakage in the pipeline. - Compa~ison of the quantities of delive~ed c~ude oil in o~de~ to detect leaks. Stationa~y

Fig. 4: Human Testing Fig. 5: Analyses Fig. 6:

Requi~ements

Classes

Fig. 7 : Examination Methods Fig. 8 : The Pipeline Control system

for

o. :-.io rd la nd

380

. - - - - - -- - -- - -- - - -

-

- - - --,

a nd G. Rabe

r - - - -.-

- -- -

Fig. 4: Human testing

Fig. 1: Safety and reliability proof for computers

Fig. 5 : Analyses

CL.U'

AlgOIR£"E'T'

CLAS'

C HARA C TERIsrICS

, .... \,I r ....... t be COr •••• n ' ctalntt,

.all,

Up to II'\I'tnlta11 IM'Irac otnlte
1 unrtlcocrn1s..s . d.&nIfarouI error In .. 11apll(lM error •••••• _nt .

Fig. 6: Requirements clas ses

Fig. 2: Structured programming

ftArI JT(CAL ..:ntoOI

PROCRAI" AIIAL"{S l (or .oH of tM ',It •• ' PROOR..t..-. AllA.LtSIS I for 1.,.artant .04,, 1. . ) MlITE - aoX- TCn' I POlllbl, blaca - boa - t .. t l •

CO~

Z.SPfrr IO.

tL.ACJ - eoX -lUT

Fig. 3 : Stat i stical methods

Fig. 7: Exami nati on methods

381

Safe" ;\Ilahsis for a l'ipelillc-Colllrol-S\'SICIll

OFF-SHORE OILFIELD

'"\ \ I-,

REFINERY

COMPUTERLINK

\

\

ON-SHORE OILFIELD

PROCESS-CONTROL-CENTRE - MAIN COMPUTER PROCESS-CONTROL-CENTRE - AUXILIARY COMPUTER MEASURING STATION VALVE PLATFORM

c:J

PUMP-STATION

Fig. 8: The pipeline control system

\ /