AECL-7056

Atomic Energy of L'Energie Atomique Canada Limited du Canada Limitee

DISTRIBUTED SYSTEMS FOR PLANTS

Systemes Distribues pour les Centrales Nucleaires

IAEA SPECIALISTS' MEETING. International Working Group on Nuclear Power Plant Control and Instrumentation

REUNION DES SPECIALISTS DE L'AIEA. Groupe International de Travail sur la Commande et ('Instrumentation des Centrales Nucleaires

Chalk River Nuclear Laboratories Laboratoires nucle'aires de Chalk River

Chalk River, Ontario

July 1980 Juillet PROCEEDINGS OF THE SPECIALISTS' MEETING

on

DISTRIBUTED SYSTEMS FOR NUCLEAR POWER PLANTS

Convened by the IAEA Working Group on Nuclear Power Plant Control and Instrumentation

14-16 May 1980 at

Chalk River Nuclear Laboratories Chalk River, Ontario CANADA

Chairman: G. Yan

Atomic Energy of Canada Limited Research Company Chalk River Nuclear Laboratories Chalk River, Ontario July 1980

AECL-7056 TABLE OF CONTENTS

Page

LIST OF PARTICIPANTS iv

PHOTOGRAPHS viii

ACKNOWLEDGMENTS xii

Welcoming Address on behalf of AECL E. Critoph Vice-President and General Manager CRNL

Welcoming Address on behalf of IAEA G. Sitnikov Scientific Secretary IWG/NPPCI Opening remarks A. Pearson Chairman IWG/NPPCI

SESSION 1 - Properties of Distributed Systems

REQUIREMENTS AND CONCEPTS FOR A NUCLEAR PLANT SURVEIL- LANCE AND DIAGNOSTIC SYSTEM (NPSDS) Paul J. Nicholson and D. Lanning

A DISTRIBUTED ARCHITECTURE IN THE CONTROL OF THE PWR 1300 MW NUCLEAR PLANTS OF ELECTRICITE DE FRANCE 20 G. Guesr'ier, P. Peinturier and G. Varaldi

THE DESIGN OF A REAL-TIME SOFTWARE SYSTEM FOR THE DIS- TRIBUTED CONTROL OF PLANT 32 G.C. Maples

DISTRIBUTED CONTROL AND DATA PROCESSING SYSTEM WITH A CENTRALIZED DATABASE FOR A BWR POWER PLANT 43 K. Fujii, T. Neda, A. Kawamura, K. Monta and K. Satoh

PROWAY - AN INTERNATIONAL STANDARD DATA HIGHWAY 65 R. Warren Gellie

A WESTINGHOUSE DESIGNED MICROPROCESSOR BASED DISTRIBUTED PROTECTION AND CONTROL SYSTEM 101 J. Bruno and J.B. Reid 11

Paqe DATA MANAGEMENT PROBLEMS WITH A DISTRIBUTED COMPUTER NETWORK ON NUCLEAR POWER STATIONS 119 I. Davis

THE USE OF DISTRIBUTED MICROPROCESSORS FOR SODIUM PRE- HEATING SYSTEM 129 K. Fujii, T. Satou, M. Satou and H. Okano

DISTRIBUTED SYSTEMS DESIGN USING SEPARABLE COMMUNICA- TIONS 141 A.C. Capel and G. Yan

THE IMPACT OF DATA HIGHWAY ARCHITECTURES ON CONTROL AND INSTRUMENTATION SYSTEM DESIGN 156

G.A. Hepburn, T. McNeil and R.A. Olmstead

SESSION 2 - Requirements and Design Considerations - I THE DESIGN, DEVELOPMENT AND COMMISSIONING OF TWO DISTRIBUTED COMPUTER BASED BOILER CONTROL SYSTEMS 168 J.R. Johnstone, D. Collier and S.T. Pringle

CONDENSATE CLEAN UP CONTROL SYSTEM WITH DISTRIBUTED DDC 180 Y. Yoshioka, T. Tazima, O. Nakamura and S. Kobayashi

THE NORTHEAST UTILITIES GENERIC PLANT COMPUTER SYSTEM 192 K.J. Spitzner

DESIGN CONCEPTS AND EXPERIENCE IN THE APPLICATION OF DISTRIBUTED COMPUTING TO THE CONTROL OF LARGE CEGB POWER PLANT 198 J. Wallace

LEAK DETECTION SYSTEM WITH DISTRIBUTED MICROPROCESSOR IN THE PRIMARY CONTAINMENT VESSEL 214 K. Inohara, K. Yoshioka and T. Tomizawa

DISTRIBUTED TERMINAL SUPPORT IN A DATA ACQUISITION SYSTEM FOR NUCLEAR RESEARCH REACTORS 226 R.R. Shah, A.C. Capel and C.F. Pensom Ill

Page SESSION 3 - Tours

SESSION 4 - Requirements and Design Considerations - II

DISTRIBUTED SYSTEMS IN THE HEAVY WATER PLANT ENVIRON- MENT 240 G.E. Kean, J.V. Galpin and J.C. McCardle

CANDU CONTROL FUNCTIONS HIERARCHY FOR IMPLEMENTATION IN DISTRIBUTED SYSTEMS 265 Pierre Mercier

ON DISTRIBUTED ARCHITECTURE FOR PROTECTION SYSTEMS 282 P. Jover

THE OPERATOR'S ROLE AND SAFETY FUNCTIONS 290 W.R. Corcoran, D.J. Finnicum, F.R. Hubbard, III, C.R. Musick and P.F. Walzer

FAIL-SAFE DESIGN CRITERIA FOR COMPUTER-BASED REACTOR PROTECTION SYSTEMS 306 A.B. Keats

AN INTELLIGENT SAFETY SYSTEM CONCEPT FOR FUTURE CANDU REACTORS 318 H.W. Hinds IV

LIST OF PARTICIPANTS

CANADA CANADA (continued)

AMUNDS, L.O. (Vern) GELLIE, Dr. Warren R. AECL Research Company National Research Council of Canada Chalk Fiver Nuclear Laboratories Division of Mechanical Engineering CHALK RIVER, Ontario Building M-3, Montreal Raad KOJ 1JO OTTAWA, Ontario K1A OR6 BAYOUMI, Prof. M. Department of Electrical Eng. HEPBURN, G.A. Queen1s University AECL Engineering Cbmpany KINGSTON, Ontario Sheridan Park Research Cbmmunity K7L 3N6 MISSISSAUGA, Ontario L5K 1B2 CAPEL, A.C. (Tony) AECL Research Company HINDS, H.W. (Tony) Chalk River Nuclear laboratories AECL Research Company CHALK RIVER, Ontario Chalk River Nuclear laboratories KOJ 1JO CHALK RIVER, Ontario KOJ 1JO CHANDRA, Murari Atomic Energy Control Board ICHIYEN, Norman P.O. Box 1046 AECL Engineering Company OTTAWA, Ontario Sheridan Park Research Community KIP 5S9 MISSISSAUGA, Ontario L5K 1B2 CHOU, Q.B. (Jordan) Ontario Hydro KLOCK, R.J. (Ron) 700 University Avenue H7 AECL Research Cbmpany TORONTO, Ontario Chalk River Nuclear laboratories M5G 1X6 CHALK RIVER, Ontario KOJ 1JO DOWNIE, Colin Atomic Energy Control Board MAGAGNA, Dr. Lino P.O. Box 1046 Ontario Hydro OTTAWA, Ontario 700 University Avenue H7 KIP 5S9 TORONTO, Ontario M5G 1X6 EL-ZORKANY, Prof. H.I. Department of Systems Engineering & MARTIN, David J Computing Science Atomic Energy Cbntrol Board Carleton University P.O. Box 1046 OTTAWA, Ontario OTTAWA., Ontario K1S 5B6 KIP 5S9

FIEGUTH, Werner McCARDLE, Jim C. AECL Engineering Cbmpany AECL Chemical Cbmpany Sheridan Park Research Community P.O. Box 3504 MISSISSAUGA, Ontario OTTAWA, Ontario L5K 1B2 KLY 4G1 V

CANADA (continued) CANADA (continued)

McNeil, Tim YAN, Dr. George AECL Engineering Company AECL Research Company Sheridan Park Research Corrmunity Chalk River Nuclear Laboratories MISSISSAUGA, Ontario CHALK RIVER, Ontario L5K 1B2 KOJ 1JO

MERCIER, Pierre FRANCE Hydro-Quebec Centrale Nucleaire Gentilly-1 AMIEL, Andre GENTILLY, Quebec GOX 1GO SINTRA 74-76 Av. Gabriel-Peri OLMSTEAD, Roy 92230 Gennevilliers AECL Engineering Company France Sheridan Park Research Community MISSISSAUGA, Ontario ANGLARET, Philippe L5K 1B2 CGEE Alsthcm 13 rue Antonin Raynaud PEARSON, Dr. Al 92309 LevaJlois Ferret AECL Research Company France Chalk River Nuclear Laboratories CHALK RIVER BECKERS, G. Ontario, KOJ 1J0 Sofinel/Tour Fiat 1 Place Coupole PENSOM, Croaribe F 92084 PARIS AECL Research Company La Defense Chalk River Nuclear Laboratories CHALK RIVER FURET, Jacques Ontario, KOJ 1J0 Ministere de L1 Industrie Service Central de Surete SHAH, Ramnik R des Installations Nuclaaires AECL Research Company 99 rue de Grenelle Chalk River Nuclear Laboratories . PARIS 75700 CHALK RIVER France Ontario, KOJ 1J0 GUESNIER, Guy SNEDDEN, M.D. (Don) Electricite de France AECL Research Company Tour E.D.F.-G.D.F. Chalk River Nuclear Laboratories Cedex N° 8 CHALK RIVER 92080 PARIS Ontario, KOJ 1J0 La Defense

TAWA, Roger H JACQUOT, Jean Paul Hydro-Quebec Electricite de France 855 est Rue Ste. Catherine Research and Development Centre MONTREAL, P.Q. 6 Quai Vfetier H2L 4P5 CHATOU, 78 France WATKINS, Len M AECL Research Company JOVER, Pierre Chalk River Nuclear Laboratories Commissariat a l'Energie Atcmique CHALK RIVER S.E.S/S.A.I. Ontario, KOJ 1JO Centre d1 etudes Nuc-leaires de Saclay 91190 GIF-sur-YVETTE France VI

IAEA U.K

SITNIKOV, G ENTWISTLE, Adrian G. Scientific Secretary Central Electricity Generating Board IWG-NPPCI Europa House IAEA. Bird Hall Lane Kamtner Ring 11 Cheadle Heath P.O. Box 590 A-1011 STOCKPOKT, England VIENNA, Austria HAMILTON, James South of England Electricity Board ITALY Cathcart House Spean Street PALAMIDESSI, Alvaro GLASGOW G44 4BE CNEN-CRV Scotland Via Arcoveggio 56/23° 40129 Bologna JOHNSTONE, Leslie Ross Italy Central Electricity Generating Board North Eastern Region Scientific Services Deparbnent JAPAN Beckwith Knowle Otley Road SATO, Nobuhide HARROGATE, HG3 IPS Nippon Atomic Industry Group Co., Ltd England 4-1 TJkishima-cho Kawasaki-ku KEATS, A. Brian KAWASAKI-SHI Atomic Energy Establishment Japan WINFRITH, Dorchester DORSET, DT2 SDH SATOU, Takahisa England Nippon Atomic Industry Group Go., Ltd 4-1 Ukishima-cho MAPLES, Graham C. Kawasaki-ku Central Electricity Research Laboratories KAWASAKI-SHI LEATHERHEAD, Surrey Japan England

YOSHIOKA, Katumi WALLACE, John N. Toshiba Electric Gorp Central Electricity Generating Board Instrument & Automation Division South Western Region 1 Toshiba-cho Bridgewater Road Fuchu, TOKYO 182 Bedminster Down Japan BRISTOL, England

SWEDEN WILLIAMS, David R, Central Electricity Generating Board LUNDBERG, David Laud House (Roan L509) Swedish State Power Board 20 Newgate Street Vattenfall/Ver LONDON, E.C.I A YAX S-16287 VALLINGBY England Sweden WILSON, Ian 8ERGGREN, Jonas Head Swedish State Power Board Instrument Systems and Techniques Group Vattenfall/Ver UKAEA S-16287 VALLINGBY Roan 121, Building B41 Sweden DORCHESTER, Dorset, England DTI 8DH Vll

U.S.A. U.S.A. (continued)

DEYST, Dr. John SMITH, John C.S. Draper Laboratory, Inc. Meetinghouse Electric Corp 555 Technology Square P.O. Box 355 CAMBRIDGE, Mass. 02139 PITTSBURGH, Pa. 15230

KANAZAWA, Dr. Richard SPITZNER, Klaus J. Electrical Power Research Institute Generation Process Computer Section P.O. Box 10412 Northeast Utilities PALO ALTO, CA 94303 P.O. Box 270 HARTFORD, Connecticut 06101 KISNER, Roger Oak Ridge National Laboratory WEST GERMANY P.O. Box X-3500, M/S 10 OAK RIDGE, TN 37830 GMEINER, Lothar Institut Fuer Datenverarbeitung MADDEN, Dr. Paul In Der Technik C.S. Draper Laboratory, Inc. Kernforschungszentrum 555 Technology Square Karlsruhe, GFMBH CAMBRIDGE, Mass 02139 Postfach 3640, West Germany

MUSICK, Charles R. (Ron) HAMMERSCHMIDT, Werner System Engineer Brown Boveri & Cie AG C-E Power Systems Abt. GK/TE2 Combustion Engineering, Inc Postfach 351 1000 Prospect Hill Road D-6800 Mannheim 1 WINDSOR, Connecticut 06095 Deutschland

NICHOLSON, Paul J. HOTTMAN, Detlef President Interatan Nicholson Nuclear Science & Engineering Internationale Atonreaktorbau Box 74, MIT Branch P.O. GmbH CAMBRIDGE, Mass. 02139 Friedrich-Ebert-Strabe 5060 Bergisch Gladback 1 PAFFRATH, A. Wayne West Germany Sangamo-Weston, Kennedy Drive KREBS, Dr. Wolf-Dieter ARCHBALD, Pa. 18403 Kraftwerk Union AG Resident Engineer at C-E REID, J. Brian 100 Prospect Hill Road Manager, Integrated Protection Systems WINDSOR, Ct 06095 Westinghouse Electric Corp P.O. Box 355 SCHULZ, Dr. G. PITTSBURGH, Pa 15230, U.S.A. Siemens AG Abteilung E STE 23 ROBERTS, Robert Siemensallee Babcock & Wilcox D7500 Karlsruhe Research Centre West Germany P.O. Box 1260 LYNCHBURG, Virginia WILHELM, Herbert USA 24505 Brown Boveri & Cie AG Abt. GK/TE2 SIDES, William Postfach 351 Oak Ridge National Laboratory D-6800 Mannheim 1 P.O. Box X-3500, M/S 10 Deutschland OAK RIDGE, TN 37830 VI11

E. Critoph G. Sitnikov

A. Pearson G. Yan IX

A view of the Meeting

Tony Capel explaining the operation of INTRAN A description of the REDNET data acquisition system by Croombe Pensom

A tour of the Dynamic Analysis Laboratory with Rudy Lepp as guide IAEA SPECIALISTS' MEETING on

DISTRIBUTED SYSTEMS FOR NUCLEAR POWER PLANT Chalk River Nuclear Laboratories, Chalk River, Ontario

14-16 May 1980

1. Sitnikov, G. 17. Palamidessi, Alvaro 33. anith, John 49. Musick, Ron 2. Spitzner, Klaus, J. 18. Keats, Brian 34. Magagna, Lino 50. Madden, Paul 3. Pearson, Al 19. Gmeiner, Lothar 35. Lundberg, David 51. Williams, David 4. Yan, George 20. Hottman, Detlef 36. Hamilton, James 52. Johnstone, Leslie 5. Yoshioka, Katumi 21. Furet, Jacques 37. Paffrath, A. Wayne 53. Guesnier, Guy 6. Reid, J. Brian 22. Chandra, Murari 38. Roberts, Robert 54. Miiel, Andre 7. Shah, Ramnik 23. Jacquot, Jean Paul 39. Entwistle, Adrian 55. Olmstead, Roy 8. Satou, Takahisa 24. Bayoumi, M 40. Maples, Graham 56. Anglaret, Philippe 9. Tawa, Roger 25. Sato, Nobuhide 41. Hinds, Tony 57. Hepburn, Al 10. Wilson, Ian 26. Wilhelm, Herbert 42. Jover, Pierre 58. McNeil, Tim 11. Capel, Tony 27. Krebs, Wolf-Dieter 43. Ichiyen, Norman 59. Wallace, John 12. Watkins, Len 28. El-Zorkany, H.I. 44. Fieguth, Werner 60. West, Rod 13. Penscm, Croaribe 29. Klock, Ron 45. Berggren, Jonas 61. Hammerschmidt, Werner 14. Mercier, Pierre 30. Sides, William 46. Amunds, Vern 62. SchuLz, G. 15. Martin, David 31. Chou, Jordan 47. Kanazawa, Richard 16. Nicholson, Paul 32. Kisner, Roger 48. Deyst, John

Xll

ACKNOWLEDGMENTS

Many people worked hard to make this conference a success. In particular, Mrs. Yvonne Rawlingson did an excellent job of handling the administrative duties and associated details; Rod W.est took care of the slides and audio equipment during the meeting; Don Snedden orchestrated an entertaining program for the evening of the banquet; Vern Amunds organized an interesting list of activities for the Open Evening; Len Watkins organized the tours; and Mrs. Kathy Amunds helped with the Ladies' Program. I should like to thank them all for their efforts and co-operation.

G. Yan - 1 -

IAEA SPECIALISTS' MEETING DISTRIBUTED SYSTEMS FOR NUCLEAR POWER PLANTS (CRNL, '80 May 14-16)

WELCOMING AVVRESS ON BEHALF OF AECL

!E. CKltoph)

Good morning, ladies and gentlemen!

I have the pleasure this morning of welcoming you to Chalk River Nuclear Laboratories (CRNL).

For our part, we are rather proud of the Laboratories, and enjoy showing them off to visitors. More important, visits such as yours are essential if we are to keep in close touch with the outside world, since, as you have no doubt noticed, we are rather isolated geographically.

I hope that during your brief stay you will have an oppor- tunity' to sample some of the attractions of this beautiful part of the country. Unfortunately, at this time of year, you may have to compete with members of our abundant insect population, also intent on enjoying the great outdoors.

Let me explain very briefly where CRNL fits into the general scheme of things.

The Laboratories were started in 1945 under the National Research Council. The large NRX research reactor facility started operation in 1947 and provided an initial focus for the various laboratory activities. CRNL quickly established a reputation in basic nuclear physics research, and fundamental underlying research has been one of the important foundations of our work ever since.

In 1952 a Crown Corporation, Atomic Energy of Canada Limited (AECL), was established, with Chalk River laboratories as its main component — the other being Commercial Products in Ottawa. AECL was given the mission of developing nuclear energy for the benefit of Canadians. This mission was vigorously pursued and, over the next decade or so, CRNL in collaboration with Ontario Hydro and Canadian General Electric developed the CANDU concept and saw it successfully demonstrated in NPD (a 25 MWe demonstration reactor just 15 miles up the river). Subsequently, the design of commercial CANDU reactors was made the responsibility of another arm of AECL in Toronto formed for that purpose. However, CRNL has remained heavily involved in the power reactor program with prime responsibility for the R & D necessary to support the CANDU system. - 2 -

Now AECL has five major arms: the Research Company (CRNL and WNRE), the Engineering Company (power reactor design), the Radio- chemical Company (isotope sales, etc.), the Chemical Company (D2O production), and the International Company (CANDU foreign marketing); but CRNL is still the biggest single site. Many graduates from CRNL play key roles in these organizations as well as in other sectors of the Canadian nuclear industry.

Over the years there have been major additions to the facilities and programs at CRNL. I will not take the time to mention these now but hope you will take the opportunity while here of finding out more about those that particularly interest you.

I would like to use this occasion to acknowledge the very useful role played by the IAEA in the dissemination of technology. We at CRNL have a great deal of sympathy with their objectives in this area. It is, therefore, a particular pleasure to host this IAEA specialist meeting.

The subject of the meeting — "Distributed Systems for Nuclear Power Plants" — is also very appropriate. CRNL has had, for many years, a vital interest in computers for reactor control and has been a strong advocate of this application of computers. Even those of us not expert in the field realize that the latest trend towards distributed archi- tectures could have very important ramifications and we are anxious to keep up-to-date on latest developments in this field.

I know you have a very full program so I'll let you get on with it. Welcome to CRNL, and thank you for coming.

****** - 3 -

Welcoming Address to the Specialists' Meeting on DISTRIBUTED SYSTEMS FOR NUCLEAR POWER PLANTS (G. Sitnikov)

Dear Chairman, (Ladies), Gentlemen, On behalf of the International Atomic Energy Agency let me welcome you to this Specialists' Meeting on "Distributed Systems for Nuclear Power Plants".

I highly appreciate your enthusiasm and readiness to assist the Agency in particular in such a very important subject as Control and Instrumentation for Nuclear Power Plants. This meeting is sponsored and organized within the framework of the Agency' s International Working Group on Nuclear Power Plant Control and Instrumentation in cooperation with the Chalk River Nuclear Laboratories of Atomic Energy of Canada Limited.

The Agency appreciates very much the opportunity of holding this meeting here in Chalk River, where, in Laboratories nearby, promising experiments and projects are being carried out having objectives to investigate and demonstrate advanced electronic systems to make easier and more safe the operation and control of future nuclear power plants. On behalf of the Agency I would like to express gratitude to the Government of Canada for the invitation to host the meeting.

It gives me a special pleasure to express the highest appreciation to the Chairman of the Meeting, Dr. Yan, and to the Chairman of the International Working Group, Dr. Pearson, and to their other colleagues for their very hard and very useful organizational and preparatory work.

This meeting is one of the very important in the row of meetings organized within the framework of the IWG NPPCI since it is devoted to the problem of application of computers for control systems of Nuclear Power Plants. The solution of this problem depends a great deal on the develop- ment of new reliable hardware and software, as well as new types of communication systems. I would not like here to go too deeply into the technical aspects. Still at the beginning of the meeting it could be interesting to make a short survey of the develop- ment of computerized control systems. In their history they passed already three stages of development or so to say generations. - 4 -

1. Information systems which are computerized systems assigned for centralized collection, storage and retrieval of source data from detecting elements and capable to carry out some simple treatment procedures in order to present some "post-factum" pictures in NPP performance.

2. Advisory systems which are computerized systems assigned to carry out the same task as above and providing current analysis of NPP performance, in order to predict a process development and generate some advice to an operator in accordance with some possible predetermined schemes of a process.

3. Control and monitoring systems which are capable not only to generate some advice to an operator but at the same time carry out real operator's function sending control commands and monitoring their implementation. Such systems must be capable to develop some correlation functions describing a real process based on information collected due to operations.

The reliability of such centralized systems appeared to be lower in general than the reliability of reactors themselves and their main technological equipment. To improve it, it was necessary to duplicate some vital parts of computerized systems. Moreover such systems demanded and demand till now usage of the most modern and very expensive computers.

If we take a look at the programme of the meeting we could come to the conclusion that we are standing now at the edge of a new generation of control systems for Nuclear Power Plants, and what is very interesting, not only with pressurized, boiling water and pressure tube type reactors, but with LMFBR1s (for example, the paper of K. Fujii, T. Satou, M. Satou and H. Okano from Japan). Those new control systems are distributed systems. They really open a new era of computerization of Nuclear Power Plant since they have essential advantages. They unload the central computer(s) for more sophisticated and delicate analysis of current processes leaving for peripheral microprocessors' maintenance of all units. They distribute in such a way responsibility between central and peripheral processors into a hierarchical system tremendously increasing that system's reliability. They make it possible to free the operator from routine non- intellectual work. Even such systems with their promising advantages have some definite limitations in usage and even raise some problems which were the reasons for all of you to come here. Their solution could be assisted through international cooperation. That is the reason why our IWG NPPCI devotes so much attention to it. I call attention to only two of 5 -

the most important problems from my point of view:

1. Accumulation and use of experience of abnormal situation at NPP. 2. Operator-computerized system communication. Operation of existing control systems is based on statisti- cal and formalized presentation of processes in the reactor and other equipment. In other words they use experience accumulated during all history of exploitation of NPP. Modern distributed systems are mostly self-educating systems but they could be educated only through experience based on sufficient amount of data.

Still, computerized systems cannot totally replace the operator for the control of a NPP in abnormal situation. We should accumulate information about development of processes in such cases, maybe simulate similar ones and only then we could order the system control of NPP in analogous situations. Experience obtained due to the TMI-2 accident gave us for example a lot of information to think over.

We have, however, had too few incidents and accidents which have provided information. We certainly need more and closer international cooperation to pool information. When a new model of an aircraft is designed, the first specimen is usually destroyed on earth. We cannot afford to destroy any pilot NPP. The only way to get the information we need is through modeling processes and international accumulation of information on all abnormal situations.

It may appear strange but with the implementation of distributed systems the role of operator of NPP is further enhanced. In spite of freeing him from some control functions, the main function belongs to him that is the function to be ready to meet any dangerous abnormality of NPP operation and to make a decision. So in f~e process of communications "Operator-computerized system" we need not only a well trained but well educated operator and the higher complexity increases the demands on his education. I would very much appreciate if you did not limit the discussion to technical aspects but also consider possible international cooperation in the above field. In conclusion I wish you a successful and pro- ductive meeting and express the hope that it will contribute to implementation of computerized control systems of the fourth generation in practice. - 6 -

IAEA SPECIALISTS' MEETING ON DISTRIBUTED SYSTEMS FOR NUCLEAR POWER PLANTS (CRNL, 1980 May 14-16)

OPENING REMARKS BY CHAIRMAN, IWG/NPPCI

(A.

Good morning.'

This is your third and final welcome to the Chalk River Nuclear Laboratories and to this the 22nd Specialists' Meeting to be held under the auspices of the IAEA International Working Group on Nuclear Power Plant Control & Instrumentation, a group it has been my privilege to preside over for the past five years. This is the 2nd Specialists' Meetings to be held in Canada, the 1st on In-Core Instrumentation and Failed Fuel Detection took place in Toronto exactly six years ago.

These meetings have left behind an impressive legacy of information dealing currently and in detail with that very important aspect of nuclear power generation, control and instrumentation. I trust that this meeting will contribute its fair share.

The topic to be discussed in the next three days has had an interesting history. As far back as 1962 when the mini computers began to appear, attention was being turned to the use of digital processors tailored to suit particular require- ments and I recall that at a conference in Sandefjord, Norway, in 1968 during a panel discussion, the idea was raised that perhaps nuclear power plant control and instrumentation could be better implemented by stand-alone mini digital computers linked in some undefined way to a supervisor.

The idea built up slowly as one watched the ever-growing use of computer networks and distributed computing capabilities around the world, but the last few years has seen an almost exponential increase in interest in the application of distri- buted systems in the nuclear industry.

This increased interest, it seems to me, has not been fired so much by the real needs of the nuclear industry as by the rapidity with which electronic technology is moving. We are being pushed by a technology that currently passes through several generations of development during the time it takes us to design and bring a nuclear power plant into production. « "7 "•

Despite the success of existing designs and the pres- sure to stick to them, the rate at which new components become available and others drop from the suppliers' shelves, require that we give attention to system architectures that are more tolerant of this situation.

A distributed data base, containing both on-line and archival information, made available to all systems of a nuclear power plant by means of a highly reliable communications medium, could form the basis for such an architecture. It could not only solve this problem of rapid component evolution but also provide for complete and comprehensive plant control and surveillance.

Perhaps during the next three days we may see some of the ways that this new and exciting approach can be made a reality.

I will now turn the proceedings over to Dr. George Yan who will be your Chairman throughout the meeting. - 8 -

SESSION 1 - PROPERTIES OF DISTRIBUTED SYSTEMS - 9 -

REQUIREMENTS AND CONCEPTS FOR A NUCLEAR PLANT SURVEILLANCE AND DIAGNOSTICS SYSTEM (NPSDS)

P. J. Nicholson and D. D. Lanning

ABSTRACT

An advanced plant surveillance and diagnostic system has been postulated for the purpose of aiding operator response to un- anticipated plane upsets. The plant operator is described as an information processor that needs plant status information represented by symbolic outputs. These will be compatible with modern visual processing techniques, such as CRTs. Preferred methods of estimating the state-of-the-plant and verifying measurements require on-line real-time models which are simple dynamical relationships based on energy and mass conservation laws. Implementation of on-line state estimation techniques using such models probably requires a distributed microcomputer system whose features are described.

1. INTRODUCTION

Control of U.S. nuclear power plants should evolve away from the traditional use of standard sensors that transmit by "hard wired" systems to control room readouts. In these traditional control rooms the reactor operator must mentally validate each sensor reading, quickly check the multireadouts in order to determine and then execute the proper control action or sequence of actions. Although by training and experience the operators have been able to operate the nuclear plants safely and successfully for hundreds of reactor operating years, the demand on the operator's capability is substantial. In this regard, it has been recognized for several years that more advanced technology is available that could improve the operator's capability to analyze sensor data and organize information for easier prediction of proper control actions. In fact, certain standardized automatic actions of the safety system have always been part of nuclear plant control systems due to requirements for control action in a short time relative to a human decision and response time. However, advanced control technology hag not been accepted by the nuclear industry for a variety of reasons, e.g., standardization, long time span from initial design to actual con- struction (ten years or more), concern for safety and reliability of advanced systems. In the aftermath of Three Mile Island's Unit 2 accident, it is widely agreed that more advanced technology and methods should be incorporated into display systems, including some backfitting into present operating plants. It is the author's opinion that these new designs must be based on certain criteria if safety and operability are to be successfully enhanced. These criteria are listed below: (1) A new plant wide data acquisition and surveillance system design needs to be defined and adopted as a reference for the nuclear industry. This system, designed to meet licensing requirements, should employ redundant distributed microcomputers with modular software, multiplexing, and a highly reliable central computer to supply data to interactive video control room displays, such as CRTs. - 10 -

(2) The distributed system should collact ail data which characterize plant status and reduce the data base to a small set of meaningful plant 'state' parameters, which are then displayed. To assure the credibility of displayed information all measurements used in status parameter calculation require two levels of validation: inter-comparison of similar measurements and cross comparison of diverse measurements,

(3) Both measurement validation and estimation of unmeasured state parameters require the use of simple on line dynamic plant process models which have been previously verified and validated, They should include sensor response characteristics and be capable of execution in real time.

(4) The system should alert the plant operator to the onset of a disturbance and indicate the general area of the plant where a fault exists. As a later capability it could guide his responses by identifying correct procedures and predicting consequences of contemplated control actions. The above four considerations have been incorporated into the conceptual design of a Nuclear Plant Surveillance and Diagnostics System (NPSDS) as described in this paper. The concept incorporates advanced but well-founded principles, as well as proven technologies that have been utilized in control systems outside of the nuclear industry.

2. CONCEPT DESCRIPTION

2.1 Design Concept for Nuclear Plant Surveillance & Diagnostic System (NPSDS) The proposed Nuclear Plant Surveillance Diagnostic System (NPSDS), depicted in Figure 1, is conceived as an addition to existing or planned nuclear units. However, the dedicated display may be a candidate for incorporation into advanced control room designs. The purpose cf NPSDS is to acquire and process plant data and present validated and prioritized information regarding plant status to the operator, It is specifically focused toward development of a plant "state vector", a reduced set of parameters which characterize the plant's safety and operability. This information will be of use to plant operators and supervisory personnel in monitoring operations, in achieving a consistent picture of plant status, and in detecting and guiding responses to disturbances. To accomplish these purposes the NPSDS first acquires all relevant plant data, both directly from sensors throughout the primary and secondary sides of the plant and, as appropriate, from other plant systems such as the process computer. This initial data acqusition and first level signal processing is carried out within the redundant distributed microcomputers as described in Section 3.3. Thus the acquired data base is digitally filtered and validated at the first level by inter-comparisons of redundant measurements where these are available. The most recent samples are then smoothed, averaged and stored for subsequent trending analysis and comparison to limits established by the stored on line plant model. Data is then available on demand or by cue to operators via interactive video displays (CRTs, TV) at one or more locations. Both the state in- formation and the plant data base will be structured in a hierarchical manner for display convenience. It is expected that the plant state vector will include inferred plant para- meters. NPSDS develops this information using "state estimation" procedures which employ simple dynamic on-line models of the plant processes in combination with the stored data base. The deductive on-line models serve the additional purpose of data integration and second level measurement validation by allowing cross- comparison of diverse process measurements. Comparison of the validated measure- - 13. -

WFSDS CONCEPT

-| OtntRATOR I

BALANCE Of/IANT

SEMI DUPLEX REACTOR CONTROLS TIME DIV. MUX POLLING PROTOCOL M. Mbps/link INPUT/OUTPUT CONTROL

STORAGE I DISPLAY I SYSTEM CENTRAL i GEN. | TEST t - PIIOTECTION SIGNALS COMPUTER C - CONTROL SIGNALS (FAULT TOLERANT) U - microcomputer

OPERATOR/ SUPERVISORY OISPLAY

Figure 1. NPSDS Concept. merits to model predicted parameters allows discrepancies to be interpreted as plant upsets. To provide the required data acquisition, processing, storage and display capability, as well as to carry out state estimation functions , the NPSDS will require a new powerful, flexible and reliable computer system. For this purpose a distributed LSI microcomputer system is postulated which will provide the re- quisite computational capabilities and memory capacity. NPSDS can be implemented largely with current commercially available technology. Due to the low cost of the LSI*devices, designs of this type have very attractive performance vs. cost attributes and are in wide use in the chemical industry and office equipment fields. Section 3.3 discusses this aspect in further detail.See also Ref [1].

2.2 Performance Advantages NPSDS has the potential to provide the operator with a powerful new tool both for monitoring normal operation, for anticipating and forestalling disturbances, and controlling and limiting their effects. These may arise from external causes, such as loss of load, or from internal plant malfunctions such as equipment failure or other error (operator, maintenance, etc.) or from combinations of these faults, typical examples from recent mishaps can be cited to show how the systems on line proce3s modeling and estimation capabilities, as described subsequently, could aid * Large Scale Integrated - 12 -

in avoiding disturbances. In these cases NPSDS could have provided: (1) Confirmation of pressure relief valve closure by monitoring fluid losses in the primary circuit. (2) Indications of core margins to saturation by automatic steam table look-up, using available core temperature and pressure data. (3) Confirmation of auxiliary feed system operability, after initiation, by comparing relevant flows, pump motor power, and discharge/suction pressures and by checking primary to secondary heat transfer rates. These examples indicate that NPSDS, when fully and convincingly demon- strated and employed could favorably affect plant safety and availability. Reaching that objective requires resolution of several critical issues dis- cussed helow.

3-0 Critical design J.3sues in System Inpiementation Enhancement of operator capabilities and plant performance clearly rests on a workable, coherent and self consistent design approach. Three elements must be brought together in a harmonious whole; state estimation methodology, the under- lying plant modeling, and implementation of the distributed system design to achieve the desired safety grade reliability. These critical issues are now discussed. Further research and development needs are presented in the concluding section.

3.1 Plant State Vector Estimation The NPSDS integrates the plant data bast' by means of the on line models and state estimation techniques to derive a minimum set of parameters which character- ize the state of the plant. When correctly chosen, this minimum set, or "state vector", will alleviate operator information overload and also indicate j>!-.«riti systems exhibiting abnormal performance.

INITIAL CONDITION X0 CONTROL SIGNAL urn REACTOR OR PLANT

GAIN MATRIX RESIDUAL € 6: MEASUREMENT VECTOR STATE VECTOR A. Y(T) X(TJ MODEL

MEASUREMENT MATRIX Figure 2. Conventional state estimation. - 13 -

The parameter set of immediate interest to U.S. light water reactor plants is the safety state vector, as described in NTJREG-0585[2] and elsewhere [3]. It may consist of 30 to 40 parameters of safety significance, such as margins to saturation, primary coolant inventory, gross fuel integrity, primary to secondary heat flow, etc. It is apparent that some elements of this set are either directly measureable or can be obtained by applying correlations to available measurements. Current reactor protection systems perform this latter function now to obtain DNBR or maximum linear heat rate., Still other elements are not directly measureable but must be estimated by recourse to validated process models. In the first case (directly measurable elements) a digital filter is used to find the best fit to a time sequential set of measurements. This procedure typically involves averaging of redundant measurements and smoothing, with recent samples weighted more heavily. In this first level processing raw sensor data is reduced and individual sensors can be checked for reasonableness. Random errors in measurement are not serious and even a bad sensor can be quickly detected. Digital filtering of this type, readily achieved with microcomputers, plays an important role in the treatment of redundant process sensor data from the plant and is a necessary first stage in conditioning raw data used in overall plant state estimation. In the second case (indirectly derived elements) the mathematical structure of the process model must be known or hypothesized from the physics of the process. The model is then validated or 'identified' by comparison of model outputs to measurements and by adjustment of model parameters to obtain the best match. In a conventional Kalman filter implementation of this procedure, illustrated in Figure 2, differences between model and measurement are fed back through a "gain matrix" to correct the model outputs until the weighted sum squared of the residuals is minimized. The model output, the state vector, contains the additional missing variables that were to be estimated. For the present purpose the Kalman filter implementation is to be limited to the calibration phase where the model is identified or validated against sensors that have been separately checked. During normal plant operations correct sensor functioning cannot be assumed but must be verified as a step in the overall calculation of the state vector. A reliable estimation procedure which is not strongly sensor dependent is probably achievable if careful attention is paid to the modeling component. What is needed is a model that can first be largely verified and validated prior to on- line use. Such a technique, namely deductive modeling, exists and is the basis for the NPSDS estimator. In the application of deductive modeling to safety state vector estimation, the mathematical form of the process model is defined from first principles, such as mass and energy conservation laws. Model validation, the process of picking model constants and matching the model to plant measurements, is initiated by application of design data and steady state calibration. As a final step the plant transient data would be used to refine the initial model. Once a match is achieved the model is said to be validated or identified; thereafter, with periodic re- calibratiou, the model can run free of the plant and be used to cross-check measurements of key parameters. The result, then, is an estimator with the general form shown in Figure 3. Current research by the authors will determine whether both sensor checks and state vector estimates can be achieved at the microcomputer level or whether assistance from the supervisory computer is required. In estimating a typical state vector element, such as primary coolant inven- tory, with this technique, several steps may be needed. The measured data must first be digitally filtered to provide the estimator with the best input data. The missing state parameters can then ba estimated from an overall fit of a total plant model to a wide spectrum of measurements. As part of this procedure the desired - 14 -

STATE ESTIMATION CONCEPTUAL SOLUTION

CONTROL VECTOR U(T) REACTOR X(T) OR PLANT •^^ • I * J

I * *

MODEL EQUATIONS CONSISTENCY ECULT CHECK

S^ RESIDUAL* r CALIBRATION V. T j STATE VECTOR PLANT X(T) MODEL c

ASSUMPTIONS: MODSL VALID COMPUTER OK MEASUREMENT MATRIX

Figure 3 - 15 -

parameter, encompassed by a local process model (mass balau.-.e), will be specifically matched to detailed local measurements. The objective will be to tie the estimated parameters to as many measurements as possible, without making the result dependent on any single measurement. If the scheme proves to be successful, then the deviation of measurements from the model can be interpreted a plant disturbance, and the method would appear to be a global apporach toward disturbance detection. To be unambiguous the method must eliminate apparent causes of anomalous behavior arising from either sensor malfunctions or model infidelity. Individual sensor failures will, in general, be detected during the data validation at each subsystem. However the estimation process breaks down if too many sensors give bad data. Therefore sufficient re- dundancy and good maintenance of sensors is required to make the scheme work — these are good practices in any event.

3.2 Plant Models The foregoing discussion argued the need for prior verification of models which could then be well matched to the process (validated). Successful models are probably attainable if the norms that were developed for the Croroby plant model[4], among others, are followed. The nonlinear deductive models proposed for the NPSDS concept adhere to these norms but go further in applying then to an on-line estimator with real-time capability. As discussed earlier, the mathematical form for the deductive models are taken from basic physics relationships. In this case, the relationships are mass and energy conservation laws applied to each of the set of control volumes which together comprise the plant. The control volumes used for initial scoping are il- lustrated in Figure 4 for the primary system of a generalized PWR plant and encom- pass the state variables of interest. This formulation is analogous to that used in some of the safety transient codes such as RELAP/RETRAN[5], and enables che latter codes to be used to verify the accuracy of the proposed real time code. The plant model so chosen contains 200- 300 first order differential equations which can probably be computed in real time by virtue of the enhanced processing power of the distributed system^ This estimate is for a model that lumps together the characteristics of some elements of the bal- ance of plant, such as condensate and drain pumps, and is consistent with other sin- pie plant modelsJ6]. Its initial development appears to be feasible within reason- able time and resource constraints. The required software will be modest, allowing one to think of sof/tware packages that are each reliable, amenable to checking, and which can meet NRC licensing criteria. A further requirement of the model is that it be capable of execution either as one combined model at the plant level or as a number of mutually consistent submodels at the subsystem level. A convenient way of accomplishing this objective is to represent the input/output characteristics of each control volume in the frequency domain using transfer function representation. The constants for these expressions would be suitably chosen from stored tables to assure that any linearity requirements are met in the operating region. The rules for multipying transfer functions together then allow model combinations to suit the needs for data and sensor intercomparison. This ability to decompose the model is also motivated by a desire to incorporate its various parts into the distributed microcomputers and to utilize their combined processing power for real time estimation. This is a task that would probably exceed the capability of a single central processor, based on comparison to recent experience with a 31 equation dynamic model used in the LOFT control system [7], - 16 -

NUCLEAR PLANT CONTROL VOLUMES

RELIEF STEAM VALVE GENf.HATOR

PECO WATER

PRIMARY COOLANT PUMP

VOLUME CONTROL TANK

Figure 4. Nuclear plant control volumes.

1>. 3 Computer Technology Needs Successful implementation of the computer based real time Nuclear Plant Diagnostic System (NPSDS) clearly requires application of several important technologies, which derive from a proven experience base in other applications (chemical industry, experimental nuclear research, aerospace, and fossil plants). These are: 1) A highly flexible and reliable computer system architecture, including distributed state of the art LSI microcomputers, and a multiplexed data acquisition network. 2) Software design and development disciplines to improve software reliability. 3) A very reliable central computer to supervise and test the system and provide data to control room displays. This computer could be configured along the lines of the CSDL fault tolerant multiprocessor[1]. These major technology items will now be summarized, based on preliminary work to date.

3.3.1 Computer System Overview The computer system proposed for the NPSDS is currently visualized as a simply connected array of LSI microcomputers although other interconnect schemes - 17 -

are under study. The exact number of computers in the array is undetermined but 10-20 are anticipated in an initial system. They are identical, interchangeable, and all have the same interface with the interconnecting data highway. The actual devices are also unspecified but one has a good selection of commercially available processors to choose from. For example, the IEEE Survey identified about a dozen different models. Some of these, like the Honeywell TDC 2000 now widely used in the chemical industry, already come as a system with their own interconnect. For various reasons, including the eventual requirements for resolution with both polarities, the likely requirements for directly addressable distributed memory and the desire for compatibility with the S100 bus, the focus of the NPSDS will be on the 16 bit microprocessor as a standard. In our system the microcomputers do not have any peripherals—those are all in the control room or the computer room. Our device is a stand alone units de- dicated to one limited set of functions consisting of data acquisition, digital filtering, averaging, smoothing, and estimation of one or more state variables. Its interface to the plant is via the sensors on the input side and the data high- way on the other. The LSI microcomputer is well suited to this task as it is small, can be well shielded against pernicious plant environments (EMI), and draws very small amounts of power. This last feature enables it to depend on backup battery supplies which can see it through plant electrical supply interruptions. They are also extremely reliable, having a mean time to failure of 10 to 100 times better than conventional computers, for an average life comparable to the plant life. Two fold redundancy for any function should give an acceptably good performance in a safety related application. At a few hundred dollars each, two dozen of them in the plant means that the important cost factors are not in computational hardware, but are in software, peripherals and maintenance. The interface to the plant is conventional for sampling process sensors at about 1 sample/sec. Analog multiplex switching (via FET's) gates the signal samples into an 8-12 bit A/D which is under processor control. The digital samples are stored in local scratchpads preparatory to local averaging, smoothing and use in estimation algorithms after which they are returned to local storage. Each pro- cessor handles typically 25-50 signal channels in this way so that 5-10 seconds worth of data is held at any one time in a small RAM, enough to do a good digital filtering job. The stored programs are contained in read only memories (ROM's) and may not therefore be altered except at the plant under controlled conditions. Care must be taken to protect the contents against unintended changes in state from external influences. In addition a self test routine is carried out under control from the central computer. The next significant component of our system is the interconnect technology which links processors to the central computer. Again a number of options exist. For this purpose we visualize the interconnection as a self clocking asynchronous serial time division multiplexed bit stream controlled by a polling protocol supervised by the central unit. This bit stream can be sent over long lengths via a number of independently paths at rates in excess of 1 Mbps. These links can be either electrical or optical. Typical formats for baseband electrical data trans- mission use a Manchester biphase coded waveform with invalid header for synchroni- zation and redundant bits to detect transmission errors. Systems with this scheme have been demonstrated in a number of aerospace applications. A class IE qualified system now available commerically handles bit rates of 0.5 Mbps and uses carrier modulation to achieve electrical noise immunity. For various reasons, including bandwidth,electrical isolation, and superior EMI protection, the authors look favorably on optical multiplexed systems, provided the cost of terminals can be brought down. We particularly approve of this scheme - 18 -

since it allows information transfer from protection systems to control room con- soles via the microcomputer, without violating any NRC IEEE separation standard.

3.3.2 Software The bottom line of the design is the software package; its complexity, develop- ment cost, integrity and perhaps its licensability. How good can a stored program be made to be, knowing that, prior to verification and validation, error rates are on the order of 1-2 errors per hundred lines of code? Several features of NPSDS contribute toward reliable software. First, the total program is Feparated functionally and physically inco modules that are dedicated to their particular task. Computations take place in parallel and chances for interprogram interaction are minimized. Second, the independent program modules lend themselves to on-line testing. One imagiras closed loop tests, injection of pilot tones, built in tests. In addition it is contemplated that each microprocessor module be dual redundant and that both can operate in parallel and check the other's results. This doesn't eliminate software coding errors, which are assumed to be common mode, but it can take care of another type of nuisance—pick up of erroneous bits through power supply droop, EMI effects, etc. To eliminate errors occuring from program changes, the program is stored in read only memory that can be altered only under controlled conditions away from the plant. In addition to these advantages which are inherent in the NPSDS design, it is assumed that the precepts for reliable software development will be followed. These include formal procedures for specification, development and testing, with the emphasis on detection of errors prior to operational use. To achieve this result a fairly substantial test cycle is required, including perhaps two independent software packages, and separate teams to code them. These pre- cautions should catch ordinary coding mistakes but will not correct errors or deficiencies in the initial specification of the software package. One is then left with the option of dual specification and coding efforts,and the test prog- ram would play these against each other. Some automation of this process is needed, employing techniques like the CSDL DART process and other tools such as RXVP and SADAT. After all of the above is done, what is expected in the way of residual errors? The indication from the NCSS experience was that about 85% of the 2.5% initial error could have been found. If this figure is representative, then a residual error rate on the order of 0.4% is possible, with a further possibility that this could be reduced to 0.1% For the on-line NPSDS program containing an estimated 1-2000 lines of instruction, there are then 1-4 errors remaining. This sounds excessive and it is hard to imagine that one cannot do better with the advantages just mentioned. The software verification issue then is somewhat unresolved in that methods appear to be at hand to deal with it may not be entirely satisfactory. It should be tried to show what really can be done. 4. CONCLUSIONS

4.1 Overall Concept A concept has been described which appears to satisfy an operator need for better and more concise information about plant status and safety. While much work remains to be done to reduce this approach to practice, the main elements of the approach rest on well-founded principles and experience. The next major step therefore involves synthesis of these suggested methods and technologies in a system which can be evaluated at the laboratory level and tested in a live plant environment. While some technical issues, such as software qualification, are to be settled, - 19

the main uncertainty to be resolved concerns the man/machine interface. This design must include not only human factors considerations but, most importantly, the informational input from machine to man. Resolution of these issues requires a realistic real simulation and plant environment. Reduction of the concept to an operational configuration must also draw upon the experience previously gained by those who have used this advanced technology.

5. REFERENCES

1. P.J. Nicholson, J.B. DeWolf, et al., Conceptual Design Studies of Control and Instrumentation Systems for Ignition Experiments, Charles Stark Draper Laboratory Report R-1139, March 1978.

2. U.S. Nuclear Regulatory Commission, TMI Lessons Learned, Final Report, NUREG-0585.

3. E. Zabroski, "TMI Lessons Learned, The Nuclear Industry Perspective", IEEE/NRC Working Conference on Advanced Electrotechnology Applications to Nuclear Power Plants, Shoreham Americana Hotel, Washington, D.C, January 1980.

4. Lester Fink, "Evolution of a Successful Modeling Program", Proc. of the Seminar on Boiler Modeling, MITRE Corporation, November 6-7, 1974 (D. Berkowitz, ed.).

5. K.V. Moore, et al., RETRAN: A Program for One-Dimensional Transient Thermal-Hydraulic Analysis of Complex Fluid Flow Systems, EPRI CCM-5, Volumes 1-4, December 1978.

6. T.W. Kerlin, "Dynamic Testing in Nuclear Reactors for Model Verification", Proc. of the Seminar on Boiler Modeling, Mitre Corporation, November 6-7, 1974 (D. Berkowitz, ed.).

7. J. Louis Tyhee, "Low Order Model of the Loss-of-Fluid Test (LOFT) Reactor Plant for Use in Kalman Filter-Based Optimal Estimators", Fourth Power Plant Dynamics, Control and Testing Symposium, Gatlinburg, Tennessee, March 1980.

8. IEEE selected reprints, Microprocessors and Minicomputers, 2nd Edition, IEEE Catalog, No. THP662-0.

9. E.F. Miller, "Survey of Software Verification and Validation Technology", IEEE /NRC Working Conference on Advanced Electrotechnology Applications to Nuclear Power Plants, Shoreham Americana Hotel, Washington, D.C. Jan. 1980.

The Authors: Paul J. Nicholson is President of Nicholson Nuclear Science and Engineering (NNSE), a consulting firm that serves the nuclear industry. Address: 255 North Rd. (77), Chelmsford, Mass. 01824.

David D. Lanning is Professor of Nuclear Engineering at MIT, Cambridge, Mass. - 20 -

A DISTRIBUTED ARCHITECTURE IN THE CONTROL OF THE

PWR 1300 MW NUCLEAR PLANTS OF ELECTRICITE DE FRANCE

G GUESNIER EDF

P PEINTURIER CGEE Alsthorn

G VARALDI EDF

Presented by P. ANGLARET CGEE ALSTHOM - 21 -

FREAMBOLE

Since 1974, EDF has developed the control and instrumentation technology in its nuclear power plants. Technological improvements in microelectronics led to the development by CGEE ALSTHOM of automation equipment, so called CONTROBLOC, meeting the following objectives :

. introduction of automation at a high security and availa- bility level, . progressive implementation in design offices and on sites by operators not specialized in electronics or data processing,

. great flexibility permitting the configuration of various systems,

. survivability to first failure,

. capability of self diagnosis.

Characterized by a modular, programmed and multiplexed structure with distributed software, the CONTROBLOC equipment is under commissioning in the first 1300 MW nuclear plant.

The following sections give an introduction to the main characteristics of the equipment, peculiar to 1300 MW power plants (this layout includes approximately 100 cabinets distributed over 7 rooms ; these cabinets exchange data through multiplexed links) and descriptions of working methods adopted by the design offices ; problems met during development as well as operating conditions in the first months.

I - MAIN CHARACTERISTICS OF CONTROBLOC EQUIPMENT (See Ref. I)

The prime objective among those selected by EDF and CGEE ALSTHOM during CONTROBLOC development was the pro- duction of equipment capable of supplying safe and highly reliable automation ; this equipment being operative 24 hours out of 24.

The equipment was also required to have a modular structure permitting progressive implementation on site and decentralization of the equipment as well as a reduced failure capacity. - 22 -

Finally, the equipment had to adapt easily to the functional developments of controlled processes and to be implemented by operators not specialized in electronic or data processing.

The basic structure of the CONTROBLOC is a cabinet permitting : - Through up to 256 input/output commonalized modules, acquiring data concerning position of reversing switch or controlling (relay) or indicating (lamps) units whose consumption is less than 3 W under 24 V.d.c.

- Solving logic equations of users programmes stored into maximum 16 REPROM memories of 32 Koctets total capacity, in approximately 50 ms.

- Formulating 384 and 127 different internal variables and time delays, with a time delay range from 1/10th of a second to 42 minutes. This basic structure can be completed by modules allowing : - Transmission of maximum 500 data to a centralized computer with time recording upon data status switching.

- Collection or distribution of maximum 1000 data with other cabinets through 11 multiplexed links.

For safety and availability purposes, each CONTROBLOC cabinet can be equipped with a dual structure ; the interface block including the 256 input/output modules is unique. In this case, the electronic block is fitted with two redundant structures having access to the interface block. An order shall be transmitted only if requested by the 2 redundant structures (operation in 2/2 mode), should a failure occur in one of the 2 redundant structures, this structure shall automatically be switched off uhile the CONTROBLOC operation continues in 1/2 mode with the remaining structure.

Each redundant structure of the electronic blocks is equipped with a set of processors actuating the following fonctional units (See Fig. I) :

- Interface control unit (UC) managing the interface modules. - 23 -

- Processing unit consisting of : . Processing logic unit (ULT) implementing programmes stored in REPROM memories of programme unit (UP).

. Management logic unit (ULG) controlling REPROM memories configuration, undertaking detection and identification of defects and implementing starting programmes of a cabinet.

- Internal functions control unit (UI) managing and implementing internal variables and time delays.

- Inter-cabinet exchange control unit (UE) undertaking uni-or-bi-directional multiplexed exchanges with other cabinets or with demultiplexing equipment through the connection unit (UB). Each inter-cabinet exchange control unit can transmit or receive maximum 1000 data.

- Unit controlling exchanges with contralized plant computer (TCI) ; this unit transmits status switches time recorded within 50 ms to the centralized plant computer.

A supervising unit, common to the two structures, localizes defects and manages the various modes of operation in connection with the management logic units.

A CONTROBLOC cabinet is IE qualified.

II - CONTROBLOC LAYOUT IN 1300 MW NUCLEAR POWER PLANTS

A 1300 MW PWR nuclear plant is equipped with approximately 1000 remote controlled actuators, 2000 logic sensors and position reports, 600 control devices, 3000 alarms, 600 signals and has to deal with almost 6000 data to be transmitted to the plant computer (TCI) (See Ref. 2).

To implement alarms automation an processing function, it has been decided to retain the complete redundant structure of a CONTROBLOC cabinet and the layout presented in figure 2. This layout can be broken down into 3 assemblies :

a) Automation cabinets - These cabinets receive logic data from the installation or the control room ; they prepare orders for actuators, alarms data and plant computer. - 24 -

Data and functionally dependant control devices are grouped on a same cabinet to reduce wire by wire or multiplexed connections between cabinets.

There are 101 cabinets, 72 are located in the elec- trical building of the nuclear plant ; 51 in the channel A electrical room process automations concerning train A *, safety systems as well as systems installed in turbine-generator building and in reactor building ; 21 in the train B electrical room process automations concerning train B safety systems.

13 cabinets are located in the nuclear auxiliaries building and process automations of nuclear waste systems. 3 cabinets are located in the pumping station and process the automations of non-safety auxiliary systems set up in this station. 2 cabinets are located in each diesel building and process local automations of diesels. Finally, 7 cabinets are installed in the demineralized water production station on site and 2 cabinets are in the auxiliary boilers building on site.

All systems managed by these CONTROBLOC cabinets are controlled and supervised from a main centralized control room, except those located in the nuclear auxiliaries building and in the demineralized production station ; the latter are controlled locally and supervised from the main control room.

The general rule retained for all automation cabinets is that every control, order, data from the plant is sent to these cabinets through wire by wire connections. Multiplexed links between cabinets are used to convey data acquired or prepared in a particular cabinet and used in one or several other cabinets. As far as alarms and signals are concerned, alarms requiring immediate action from the operator are indicated by lights connected wire by wire to the cabinet preparing these alarms ; remaining alarms are transmitted by multiplexed links to the alarm centralizing cabinet (See Chap. II.C) and presented on a display CRT. Indicating messages are transmitted through multiplexed links to demultiplexers installed in the main control room and monitoring LEDs.

The safety functions of the Reactor Protection Syst are not realised by CONTROBLOC but by a specific electronic system,the SPIN (Digital Integrated Prot System) [Ref.IIIj. - 25 - b) Common data cabinet

- A number of data concerning either status conditions of the nuclear plant or controls (shedding, acknowledgment ot alarm horn or alarm lights) shall be supplied to a large number or automation cabinets. These data are acquired or prepared by 3 cabinets designated common data cabinets and transmitted through multiplexed links to all automation cabinets which receive 3 times the same data each. The cabinet using data process these data in 2/3 mode. Triple transmission of common data has been retained to avoid the loss of a cabinet or a multiplexed link. c) Alarm management units

- As previously mentioned (See Chapter II.a), the alarms requesting operator immediate action are indicated by lights connected wire by wire to the automation cabinets while other are displayed on CRT displays.

- 7 polychrome CRT have been installed in the main control room, 6 display all alarms included in tne plant ; an alarm is displayed on the CRT located in the control board area where the sytem control alarms relative to this alarm has been installed. The 7th CRT, used' only as an alternative, displays alarms of safety B train systems.

- To switch a alarm transmitted by a given automation cabinet to a given CRT, a set of two CONTROBLOC cabinets are available, one train A cabinet including 2 electronic blocks and one train B cabinet with 1 electronic block with handling capacity of multiplexed links double that of automation cabinets (2000 data per electronic block instead of 1000).

- Each electronic block gets information over 7 links each of the approximately 35 cabinets to which it is linked ; the block forwards the status switches it receives either to one of the CRT with which it is linked or to the electronic block managing the CRT on which status switches ghall be displayed.

Each CRT has a 500 alarms capacity, 23 warnings can be displayed simultaneously, 24 more can be stored and displayed at operator's request. (Whenever more than 4'/ alarms are displayed simultaneously, the first alarms are lost). 26 -

III - ORGANIZ.VTION OF DESIGN OFFICES

A nuclear power plane is split down into functional assemblies of various importance, designated elementary systems,to which are associated functionally linked actuators and, therefore, a number of control devices and sensors. Operating studies are undertaken, elementary system by elementary system ; the operation of these systems is described in logic diagrams. The selection of CONTROBLOC cabinets ensuring logic automation of such elementary system is made while taking a number of parameters into account :

- Volume of elementary system in wire by wire inputs/outputs on the CONTROBLOC cabinet (the number of wire by wire inputs/outputs is decisive considering the large logic processing capacities of REPROM memories and multiplexed links).

- Functional relations between elementary systems (the intent is to group, in a same cabinet, all systems with a high functional link to reduce intercabinet connections).

- Implementation period on site (to avoid delivering a large number of CONTROBLOC cabinets, to achieve early- system implementation, the intent is to use a group of sub-systems each consisting of a limited number of cabinets altogether forming a master system). More than 2 years elapse between implementation of first and last systems.

- Distribution of designs between several design offices. (The EDF PWR plants are studied by several EDF design offices, each assigned a part of the nuclear plant, the nuclear boiler manufacturer shall also design its own control-instrumentation system). Distribution of elementary systems in cabinets is such that most systems designed by a particular office are processed in CONTROBLOC cabinets distinct from those studied in other offices.

From logic diagrams functionally describing automation in an elementary system, the design office sets up a logic operation drawing showing in detail the automation to be implemented in the CONTROBLOC cabinet, identifying inputs and outputs, logic statuses, internal variables and time delays, describing logic sequences. - 27 -

This logic drawing is translated into logic equations and using these equations, a programming console enables to lead the REPROM memories installed in the cabinets. Data processing equipments being presently developped should soon permit determining REPROM memories from logic drawings.

The design office provides two types of management

-• Management of input/output data of each CONTROBLOC cabinet : wire by wire inputs/outputs to actuators or alarm lights, data to centralizing computer, alarm indications to CRT, multiplexed links between cabinets :

. the time being,this management is partly provided by data processing equipment and in a large part, manually.

- Management of REPROM memories loaded with logic equations :

. a CONTROBLOC cabinet contains several REPROM memories ; to facilitate management and considering memories capacities, only logic equations calculated in an elementary system shall be loaded in a REPROM memory.

The design office thus manages REPROM memories of a cabinet with respect to the degree of loading of this cabinet, the degree of validity of the programmes loaded in the REPROM memory (programmes validated or not by tests, REPROM memory forwarded to site, operational elementary system ...) and with respect to the various modifications likely to be introduced at the different stages of implemen- tation.

This management is ensured with data processing equipment.

To limit the number of modifications on site, the design offices have adopted simulation equipments consisting of CONTROBLOC cabinets and permitting checking step by step logic equations loaded in REPROM memories.

IV - FIRST EVALUATION OF DEVELOPMENT

The CONTROBLOC technical prescriptions were defined in 1975. A first model proving the suitability of the logical operator was manufactured in 1976 and in 1978 a prototype cabinet was installed in a thermal power plant. 1978 was mainly dedicated to solving industrialization problems (suppliers, size of electronic cards, structure of interface block and of electronic cards, connections) and "the prototype was largely reworked. - 28 -

A second prototype was installed in the thermal power plant at the beginning of 1979 and since was operated satisfactorily. The final industrial equipment was drawn up in mid. 1979 and the first cabinets were delivered on the nuclear site in September 1373.

Software studies applied to the starting, time delay and internal variables, multiplexed links and defects localization software and to the programming consoles were undertaken in parallel with hardware studies.

Development would be accelerated if EDF had established more definite technical prescriptions and if the manufacturer had had more sophisticated tools to help the conception.

V - EXPERIENCE ACCUMULATED IN THE FIRST MONTHS OF OPERATION Approximately ten elementary systems are in operation on the site today, 20 cabinets are operational (including common data cabinets and a alarm management unit). Systematical tests having been performed by the manufacturer, the possibility to experiment with the equipment for more than 1 year in the design office and the early delivery of several cabinets on the site enabled to identify a number of problems in various fields (operation within limit conditions, software deficiencies, mechanical behaviour in an industrial environment) that were solved progressively. The delivery and commissioning of an increasing number of cabinets on site when necessary adaptations of software remain and minor modifications of hardware cannot be excluded are extremely imposing factors.

This situation enables to implement the equipment in effective operation conditions with every restraint inherent to installation on site (connections, tests, supplies ...) and to point out problems it is preferable to solve before plant equipment is too advanced.

VI - CONCLUSIONS In the control structure describe before, the automation and data processing equipment have been decentra- lized and located closer to the equipment to be controlled. Due to their programmed structure, the use of CONTROBLOC cabinets enables to reduce the volume of the links between control room and automation cabinets or between automation cabinets thenselves through a large application of multiplexed links. In the retained structure, however, multiplexed links were not used to send data from sensors to automation cabinets and to transmit orders from control room but mainly to transmit alarms anJ indicating messages.

Studies have been undertaken in which largest scope are given to multiplexed links, particulary in control room automation cabinet links. It shall be necessary to wait for the implementation of the first 1300 MW plants to further these studies. - 27 -

This logic drawing is translated into logic |uations and using these equations, a programming console ^ to lead the REPROM memories installed in the cabi: DaTHLprocessing equipments being presently developped shj sooHlfeermit determining REPROM memories from logic drav

The design office provides two types of Sgement

ManagemeTBW of input/output data of each CONTROJ^PE cabinet wire by wabe inputs/outputs to actuators or aJ^rrn lights, data to ce»».alizing computer, alarm indicaj^^s to CRT, multiplexed^fccks between cabinets m A, . the time bei^B^this management is parijBFprovided by data processirtBjj^quipment and in a idBW part, manually. - Management of REPRdMfcjemories loadeajB^tn logic equations : a CONTROBLOC cabinet^ ntains j(Beral REPROM memories to facilitate managem and a«Eidering memories capacities, only is calculated in an elementary system shall [ded in a REPROM memory.

The design off J^B^hi^kinanages REPROM memories of a cabinet with respect^^^ the^fcgree of loading of this cabinet, the degree of ij^KFdtty of^Kie programmes loaded in the REPROM memory (jB^^jramines vaSfiated or not by tests, REPROM memory forwaraM^o site, operational elementary system ...) and witl^HSspect to the va^tpus modifications likely to be introjJHBed at the differenffl^gtages of implemen- tation.

Th^ftWanagement is ensured with processing equipment.

_ limit the number of modifications the desi^H^offices have adopted simulation equipments rJ of CONTROBLOC cabinets and permitting CITT ina step J^JJstep logic equations loaded in REPROM memori

EVALUATION OF DEVELOPMENT

The CONTROBLOC technical prescriptions were defined in 1975. A first model proving the suitability of the logical operator was manufactured in 1976 and in 1978 a prototype cabinet was installed in a thermal power plant. 1978 was mainly dedicated to solving industrialization problems (suppliers, size of electronic cards, structure of interface block and of electronic cards, connections) and the prototype was largely reworked. - 28 -

second prototype was installed in the thermal power plant it the beginning of 1979 and since was operated satisfactori] final industrial equipment was drawn up in mid. 1979 and t!lkrfirst cabinets were delivered on the nuclear site in KL 1073. Software studies applied to the starting, t delay'^•j^ internal variables, multiplexed links and dei localizlHJKm software and to the programming consoles^ were undel^fcaken in parallel with hardware studies.

^yeiopment would be accelerated if EjFhad established i^^^ definite technical prescriptio^ rnd if the manufactur^^^had had more sophisticated ^ help the conception -1

V - EXPERIENCE ACCUMULA1 IN THE FIRST MONTHS OPERATION Approximate ten elemental iysteras are in operation on the site to!! 20 cabin« rare operational (including common data inets and I larm management unit). Systematical te^fc ha^Kq been performed by the manufacturer, the possibilitjBkyflR'periment with the equipment for more than 1 year in the d^mWn office and the early delivery of several cabinets^Bfcbe site enabled to identify a number of problems in varj^Ps ifclds (operation within limit conditions, software def icjjPrcies^fcpechanical behaviour in an industrial environment) ^«jKat wereTkplved progressively. The delivery and commissionJ^^of an incsB^ing number of cabinets on site when necessary^Haptations of^BLftware remain and minor modifications cji8!iardware cannot^fc^excluded are extremely imposing a This^Wtuation enables to impl^BJnt the equipment in effective opJPtion conditions with everyJpMstraint inherent to ir^^pllation on site (connections _^^ supplies . . .)JjKd to point out problems it is "^Okferable to solve befors^^^ant equipment is too advanced. VI - CONCLUSJ In the control structure describe before, ^ and data processing equipment have been d^ and located closer to the equipment to be control^] 'to their programmed structure, the use of CONTROBLOC Sinets enables to reduce the volume of the links between FBntrol room and automation cabinets or between automation rcabinets thenselves through a large application of multiplexed links. In the retained structure, however, multiplexed links were not used to send data from sensors to automation cabinets and to transmit orders from control room but mainly to transmit alarms and indicating messages. Studies have been undertaken in which largest scope are given to multiplexed links, particulary in control room automation cabinet links. It shall be necessary to wait for the implementation of the first 1300 MW plants to further these studies. - 29 -

REFERENCES

I - IAEA International symposium on nuclear power plant control and instrumentation. CANNES (France) 24-28 April 1978.

"Electronic system of power station control with modules and distributed software based on CONTROBLOC elements". P. PEINTURIER D.A. MAYRARGUE. G. GUESNIER. G. VARALDI.

II - IAEA Working group on nuclear power plant control and instrumen- tation. Specialists meeting on procedures and systems for assisting an operator during normal situation. MUNICH 5,7 December 1979.

"Data processing and data display in Electricity de France PWR 1300 MW nuclear power plant". G. GUESNIER. C. HERMANT.

Ill - IAEA Working group on nuclear power plant control and instrumen- tation. Specialists meeting on distributed systems for nuclear power plants. Chalk River. 14-16 May 1980. "On distributed architecture for protection systems". P. JOVER. - 30 -

CONTROBLOC CABINET STRUCTURE

Process interface n"3 64 inputs/outputs

Process interface n'4

—I —' — -H —\ —\ 8 main boards I | I I 8 elementary modules on each main board ( input or output ) I II

UC To plant computer U C Coupling t Coupling Unit Unit UR UR

512 data _^ exchange Fault \ I control unit Ul display/ Ul 384 internal data \ internal 127 programmed (Common to many

UE I UE

•*• Informations exchange unit Maintenance panel

1 of 256 data output 11 Multiplexed links 3 of 96 data input 7 of 48 data output/input

Process interface n* 1 64 inputs / outputs

Process interface n*2 64 inputs/ouputs

FIGURE A FIGURE: 2 CONTROBLOC CABINETS ARRANGEMENT IN A PWR 1300 MW PLANT

Main control room

( CRT ^ fan / CRT \ CRT / C R T \ /CRT \ V n1 ) \ n 2 ) jn-3 J n"4 \_n_b_J \ n 6 j

6 Links 3 links

Common 3 Links Alarm Plant Alarm Common data cabinet computer cabinet data cabinets 1 1 cabinets 3 Uink 3 3 Links 69 Links 32 Links T> llink 6 Links 8 links 12 Links 3 Links c '6 /$ * 55 Links 25 Links 3 Links

Automation cabinets ULS ULS Automation cabinets 35 55 \ 4 Links/ B 25 CD T^I—t—i—-t "4 Links 1 1 i ._. Reactor pro ection system \ .5! JATP UATP UATP UATP \ Rjnk I Link T n" 1 n'2 n-3 n4 I Rink Uink Rink 4 7^ 1Linl< 2Ltnks Control room Control room 2 Links / 1 4 2 Links f f6 Links Rink Hink 10

Diesel train Pumping Auxiliary Demineralised Nuclear auxiliary building Diesel train A station boilers water Building train A train B B i

FIGURE :2 - 32 -

THE DESIGN OF A REAL-TIME SOFTWARE SYSTEM FOR

THE DISTRIBUTED CONTROL OF POWER STATION PLANT

- by -

G.C. Maples

Summary

Computers are being increasingly used for the control of generating plant, and the advent of low cost mini/micro computers having an installed price comparable with conventional equipment has resulted ii«. a significant trend tovzards distributed computing. As this application of computers widens the problems of resourcing several individual ^rojeLts over their life cycle can become formidable.

In particular, the provision of reliable and effective software it a crucial task, since it has a considerable impact on resourcing due to the high costs associated with its design and development, and equally important, its subsequent amendment and support. This paper indicates the factors viiich are considered relevant to containing the resource requirements associated with software, and outlines the benefits of adopting a standard machine independent software system which enables engineers rather than computer specialists to develop programs for specific projects.

The design objectives which have led to the current development within the C.E.G.B. of CUTLASS (Computer Users Technical Languages and Applications Software System) are then considered. CUTLASS is intended to be a standard software system applicable to the majority of future on-line computing projects in the area of generation, and is appropriate to stand alone schemes or distributed schemes having a host/target configuration. The CUTLASS system software provides the necessary environment in which to develop, test, and run the applications software, the latter being created by the user by means of a set of engineer- orientated languages.

The paper describes the various facilities within CUTLASS, i.e. those considered essential to meet the requirements of future process; control applications. In particular, the paper concentrates on the system software relating to the executive functions, and the organisation of global data and communications within distributed systems. The salient features of the engineer-orientated language sets are also discussed. - 33 -

1. INTRODUCTION

The complexity of modern generating plant both conventional and nuclear together with the increasingly severe operational requirements relating to safety and efficiency necessitate continuing improvements in the control and instrumentation (C & I) systems. To this end the C.a.G.B. in common with other utilities is making an ever greater use of digital computers for C & I applications.

Further, the trends in computer technology offer the possibility of utilizing computers in a more widespread and effective mariner. In particular, the advent of low cost micro/mini computers having an installed price comparable with conventional equipment enables the hierarchic structure associated with many C & I schemes to be implemented as a distributed network of computer-based control centres, with each centre carrying out a specific task within the overall scheme. This approach enables the scheme to be partitioned such that each control centre has a high degree of autonomy, which implies that the performance of one centre has only a limited effect on the remainder. It follows that:-

(i) the commissioning and/or modification of a centre can be carried out independently of the rest of the system;

(ii) the scheme is readily extended by incorporating additional centres;

(iii) the need for standby facilities is often eliminated L-\ncc in many cases failure of an individual centre, and the subsequent requirement for manual intervention, do«s not impose an intolerable burden on the operator;

(iv) where availability is of paramount importance the redundancy of the network can be utilized in that the duty of a failed centre can be taken over by a second centre;

(v) the scheme can be segregated into easily understood sub- systems.

However, past experience has shown that the potential ber.ejiiu.-; of such computer-based systems are not always realized and that the resourct:s required to support major projects "ver their life cycle are greater thai, anticipated. This has been due in part to a lack of discipline in the specification and design of systems aggravated by the ambiguities which inevitably arise between engineers and specialist computer staff, Also, past installations have used a wide variety of software languages and equipntct.t types, and this represents a poor utilization of scarce speciaiist computing and system design expertise since effort expended on one project is net in general transferable to another.

In the above context the method adopted for providing adequate soft- ware for future projects is seen as a key factor in ensuring that the potential advantages of computer-based schemes are fully realized and that the associated resource requirements are contained. This is particularly important in the case of microprocessor based systems where the manufacturer provides only - 34 -

limited software support. This paper describes the approach being adopted by the C.E.G.B. to help mitigate the problems of software provision for future C & I schemes associated with new plant, and, equally significant, the retrospective equipping of existing plant.

2. DESIGN CRITERIA

Clearly the method adopted for the provision of software has a sig- nificant impact on the resourcing of on-line computing projects. This is due to the high cost, particularly in terms of scarce expertise of specifying, developing and engineering software as well as the equally important influence of software design on the effort required for the subsequent maintenance and amendment. There is thus an incentive to adopt standard software suitable for a range of applications, since development effort can be utilized across a number of projects and the long-term support provided on a common basis.

To this end the C.E.G.B. is currently developing CUTLASS (Computer Users Technical Languages and Applications Software System) which is intended to provide a standard software environment and user-orientated languages for process control applications, initially on generating plant, and with possible application to transmission plant in the longer term. CUTLASS is appropriate to both stand-alone and distributed computer systems, the latter being assumed to have a host/target configuration.

The common design approach throughout the CUTLASS development may be summarized as:-

(i) to achieve a shift of resources for project applications from the scarce computer specialists to available engineering staff. It is intended that computing staff will be responsible for the design and support of the CUTLASS system but that engineering staff will utilize the user-orientated language sets in CUTLASS to create the applications software for individual projects;

(ii) to achieve as great a degree of machine independence as practicable by the adoption and support of high level languages over a selected range of machine architectures; specifically a single dialect of CORAL 66 for the system software and the CUTLASS user-orientated languages for applications software;

(iii) to optimize the effectiveness of the available computing specialists. Together with high-level languages the important distinction between 'host' (development) and 'target' (final implementation) hardware configurations has evolved with emphasis being placed on maximizing the development done in the efficient environment of the 'host' machine;

(iv) to achieve sufficient flexibility to permit easy modification or extension of systems so as to meet changing operational requirements or technological advances; - 35 -

(v) to ensure that the effect of software failure is minimized not only in respect of plant safety and availability, but also in terms of the maintenance burden imposed on operating staff.

The above criteria are not always considered in sufficient detail at the onset of software design even though they have a significant effect on life-cycle costs. Further, the potential benefits of adopting a standard software system such as CUTLASS will largely be mitigated if there is no agreed definition of the user requirements for major areas of application. Failure to agree such definitions leads to ambiguities of interpretation which can result in costly software modifications. A process of consultation is therefore being carried out within the C.E.G.B. to establish the user require- ments in respect of the control of generating plant, and to coordinate these where subjective differences arise.

3. CUTLASS DESIGN CONCEPTS

CUTLASS consists of a framework of system software together with a number of user-orientated language sets. The former provides the necessary environment in which to develop, test and run the applications software created by the user by means of the language sets. The system software includes translator/editor facilities, an executive for allocating resources to tasks within a machine, diagnostic programs, and software for organizing database and communications functions in both stand alone and distributed systems. The translator/editor will generally be run on a large host machine during develop- ment although target applications systems can have a host machine as part of their configuration.

In developing CUTLASS the following concepts have been adopted so as to meet the design criteria outlined above:-

3.1 Ease of Use

As well as a general purpose user-orientated language having for example, arithmetic and boolean statements, it is intended to provide language sets appropriate to differing areas of control, such as D.D.C., sequence control, display etc.

Each language statement relates to a sub-routine and its associated parameters, each sub-routine being designed to carry out a specific function commonly encountered in a particular area of control as defined by the user requirements. Thus the sub-routine functions are synonymous with familiar engineering concepts.

The applications software for implementing 3. given task can thus be readily specified by the user as a set of language statements which effectively define an assembly of sub-routines each having a known function, and their associated interconnections. At the same time every effort has been made to provide a range of interactive diagnostic and commissioning aids to facilitate the testing and development of the applications software. - 36 -

3.2 Machine Independence

To help achieve machine independence the CUTLASS system software and applications sub-routines are written in CORAL 66. However, this does not completely solve the problems of portability. Although a substantially standard syntax is available the implementation of that syntax on a specific machine architecture or by a particular compiler introduces a number of machine- dependent features. To help reduce these problems a specific dialect of CORAL 66 has been adopted and an effort made to separate and minimize the machine-dependent aspects cf the CUTLASS system.

Although CORAL 66 is less efficient in the use of both memory and processor power than assembler-based systems the relevance of this is rapidly diminishing due to decreasing memory costs and the trend towards distributed convputing which renders the loss of efficiency less significant.

3.3 Flexibility

The requirement for flexibility has been met by adopting a structured approach to the software design. Each software function (e.g. communications, data handling, etc.) is designed on a modular basis with well defined inter- faces. These modules can then be configured within the standard software framework to provide the relevant facilities for any given C & I scheme.

This modular approach provides for a natural segregation of the software into functional blocks related to the different activities within a typical on-line computer scheme. Further, this approach has enabled the CUTLASS system to be developed as a collaborative project within the C.E.G.B., individual modules being produced by experts in different departments.

3.4 Reliability and Security

The attainment of reliability in software is far more dependent on rigorous specification and good structural design than it is on the elimination of simple errors in the program code. For example, a modular structure assists in containing and diagnosing errors, while user-orientated languages help assure that the applications software more accurately reflects the user requirements.

However, in addition to the above factors specific facilities have been incorporated in CUTLASS in the interests of reliability and security, namely:- (i) an ordered method whereby data can be accessed by the various schemes in a given computer, or over the network as a whole. The data handling is largely independent of the hardware or network configuration and provides protection against unauthorized access;

(ii) a concept of privileged and non-privileged users, defined in terms of a security code, whose ability to alter soft- ware, particularly system software, is restricted on the basis of their security rating;

(iii) formal procedures for diagnosing and containing errors in both the executive and the run-time software associated with the applications sub-routines; - 37 -

(iv) application sub-routines designed to take account of plant safety in that, for example, an output drive routine would have inbuilt rate protection. Where appropriate the sub-routines are also designed to simplify the control system design effort by incorporating the necessary features to handle the complexities of initialization, bumpless auto/manual transfer etc.

While it is recognized that there is no way of preventing the user from making errors in control strategy the facilities outlined above should significantly reduce the consequent effect on plant.

4. CUTLASS APPLICATIONS PROGRAMS

4.1 General Concepts

The user-orientated languages consist of a general purpose language sub-set and special purpose languate sub-sets, it being intended that the latter should be provided for:-

regulating control (DDC)

sequence control

data logging and display

alarm analysis

condition monitoring

performance calculations

CUTLASS utilizes a translator/editor to convert the user-orientated language statements into object code which consists essentially of addresses indicating entry points of the relevant applications sub-routines and their associated data. Run time execution begins by entering the first sub-routine specified. Having accessed the appropriate data and carried out its particular function the sub-routine causes an entry to be made to the next sub-routine and so on. In this way object code, execution is carried out efficiently and without the need for a separate run time interpreter.

This method was chosen rather than a true compiler because it enables a number of desirable features to be achieved more easily. For example, the object code is machine-independent, it can be directly edited or translated back into its original source form, and permits testing and monitoring procedures to be easily incorporated. Although a scheme generated by s com- piler is generally faster in execution, the speed penalty involved is not very significant since the linking overhead is normally small compared with the execution times of the applications sub-routines.

The translator/editor combines the functions of source editing, syntatic and semantic checking, as well as the generation of object code. - 38 -

The program source is stored as a text file on backing store, and when entered the translator/editor reads the source and creates a temporary copy of the source file. Editing proceeds by merging edit commands from the user with the temporary source file to create an alternative copy of the temporary file.

This serialized editing technique allows the program to be fully checked as the lines are read in, appropriate messages being provided to indicate various syntactic and semantic errors. When editing is complete the user can:-

(i) generate a new copy of the source file from the latest temporary file;

(ii) output a listing of the object code;

(iii) load the object code over the communications network into a target machine.

The structured nature of CUTLASS requires that the user partitions the applications software into schemes and tasks. A scheme, which may consist of one or more tasks, forms a single indivisible unit for the purpose of trans- lating and editing. Tasks within a scheme can communicate via common data declared at the head of the scheme. This data is inaccessible from any other scheme.

A task is the smallest program element, written as a set of languaf* instructions, which can be run by the executive in its own right. Tasks can contain their own local data, declared at the head of a task, and inaccessible by any other task. The scheme and task boundaries are assigned by the user, and will normally relate to some natural segregation of the required control strategy.

Tasks can communicate with tasks in other schemes via global data which is created by a separate utility. There is no restriction on whether the communicating schemes are in the same or different computers. CUTLASS users are required to log in to the system in order to use certain utilities, in particular, the translator/editor and the utility for creating and deleting global data. The user name is checked against a list of known users held in the target machine and is converted to a user number which is stored with any scheme he creates.

Selected users can be given a privileged classification which allows them to use various software options needing extra care, but does not allow them to break ownership rules. One user can be nominated as the 'system manager' and as such has the ability to break ownership rules such as altering the owner number attached to schemes, files etc., and change the allocation of privilege to particular users.

4.2 Error Handling

CUTLASS includes error handling arrangements designed to contain various hardware and software failures. For example, error tracking is provided whareby recognizable errors such as invalid input data, or a communications failure in a distributed system, causes the associated numeric or logical data - 39 -

to be flagged 'bad1. Any subsequent CUTLASS instruction which utilizes this 'bad' data will in turn flag its output 'bad' so that 'bad' data propagates in an ordered manner across task and scheme boundaries.

The user can test the state of data items at any stage and hence invoke corrective actioa. Alternatively, if no corrective action is taken, CUTLASS output instructions receiving 'bad' data automatically respond in a safe way. Thus a valve drive instruction in the DDC language sub-set will freeze the valve in its current position and apply any necessary inhibits to the control algorithms.

In cases where a task is affected more severely the user has the option to specify an error trap label to be entered for particular types of error. These include array bound errors, LOOP count 'bad', IF condition 'bad', etc. The action taken by CUTLASS on detection of these differing types of task error is determined by internal flag words set up when the system is generated. The options ara:-

(i) errors trapped by the user as described above, the task being aborted if no trap entry is specified;

(ii) as (i) but the task continues if no trap entry is specified;

(iii) errors simply set a flag in an associated task status work which can be subsequently tested by the user.

5. TARGET MACHINE CONFIGURATION

Typically a target machine will contain the object code and applications sub-routines appropriate to its particular control functions together with a set of system software. The latter will now be described in greater detail.

5.1 Executive

The executive (TOPSY-2) is essentially a modular kernal of procedures to create, manipulate and delete a set of resources in the computer. These resources are 'named', and can be programs, devices, semaphores or memory partitions. Whenever a resource is created a 'control block' is allocated from a pool of available memory, the control block space being returned to the pool when the resource is deleted.

TOPSY-2 is capable of running a number of independent programs. To do this, TOPSY-2 maintains information describing the current status of each of the programs in the machine. When appropriate a scheduler algorithm selects a program to run and transfers control to that program. Various causes (e.g. a natural dropout or suspension of the program), subsequently relinquish control to TOPSY-2 in such a way that the program will only be resumed as the result of selected stimuli. - 40 -

Peripheral devices need to be shared between contending programs and this is organized by the executive. Programs requiring to perform I/O transfers must do so through requests to TOPSY-2, which will forward the request to the appropriate device driver. TOPSY-2 also provides for a program to temporarily acquire the exclusive use of a device for an uninter- rupted series of transfers such as the printing of a list of data that is not interspersed with random messages from other programs.

Where two or more programs require access to certain shared resources, but where concurrent access could lead to destructive interference, (e.g. shared sub-routines) TOPSY-2 provides 'semaphore' facilities to ensure that only one such program at a time can access the shared resources. Other contending programs are forced to wait until the current program has finished using the resource.

To facilitate memory management TOPSY-2 has the capability of maintaining a record of used and unused memory space within the computer, and of allocating/de-allocating memory partitions as required. TOPSY-2 alrso has the ability to maintain a hardware driven clock facility, and co perform scheduling actions on the basis of elapsed time intervals. This is important in a real-time environment where programs/devices are to be run at regular intervals or pause for specified periods.

The programs which share the computer cannot be assumed to work perfectly, so TOPSY-2 contains provision to handle errors which may be detected at run-time. Error 'containment' prevents a program from running wild after a situation occurs which is inconsistent with correct program behaviour, and tidies-up any resources used by the program. Error 'reporting' is a mechanism that allows the error to be notified to a supervisory program or a human operator. TOPSY-2 provides facilities whereby either TOPSY-2 or a program may initiate the containment and/or reporting process when an error is detected.

Since the executive is modular it can be configured down to a set of procedures appropriate to a given application. It is also being extended to accommodate machines having memory-mapped architectures.

5.2 Communications Software

The communications software organizes the message transfer between computers in a distributed network. It assumes the use of standard asynchronous serial link hardware and will accommodate a variety of store and forward network topologies (e.g. radial, ring, or fully connected). While this type of network imposes additional transmission delays, since intermediate nodes are involved, it can be made tolerant to failure since messages can be re-routed along alternative links, while the practicable data rates are suitable for many control applications.

The software to implement this type of network is structured into three levels, these being:-

(i) The link level. This level is concerned with the exchange of 'link frames' (encoded forms of the actual message) via the serial interface hardware. This level is implemented as one or more drivers attached to the TOPSY-2 executive - 41 -

and utilizes a C.E.G.B. software based protocol GENNET. GENNET is designed to provide adequate error detection and correction without incurring excessive software overheads and to allow for full duplex transmission and data trans- parency. Messages are encoded as a series of 8 bit bytes, the message frame consisting of two header bytes and four tail bytes. The latter include two check bytes; the first represents a horizontal parity check on the message data while the second gives the length of the message data. Each successive message is transmitted with an alternative toggle (contained in the second header byte) so that if the same header is received more than once subsequent messages are accepted but the data discarded. This allows for loss or failure of an acknowledgement which would otherwise cause messages to be duplicated. To minimize the delay in responding to a message during full duplex transmission the acknowledge sequence can be 'stuffed' into a reverse message.

(ii) The network level - this level is responsible for the store and foward operations on messages received from the links and is implemented as a task under TOPSY-2. To achieve this each computer contains a routing table and every message sent through the network has a destination number. When a message is received the routing table is consulted and the best link selected for forwarding the message. The link level software in any computer sets up its routing table dynamically by exchanging special messages with its nearest neighbours. This allows the communications to adopt automatically to link failures or changes in network topology and enables computers to be removed or added while the system is on-line.

(iii) Applications interface level - all messages exchanged between the applications tasks pass through a standard applications interface implemented as a task-to-task driver under TOPSY-2. The interface provides for message transfer between tasks in the same computer or between tasks and the network level. It carries out validity checks on application task requests and separates incoming messages into channels. There is an error channel for mis-routed messages.

Since the communications software is modular the various levels could be replaced to meet changing requirements. For example, the link level could be replaced by a hardware implemented protocol such as HDLC.

5.3 Global Data Handling

The data manager provides a method for exchanging global data between schemes in the same or different computers and is essentially distributed in nature. Where a number of schemes in different computers require to access the same data item, there is a 'master' copy of the item in one computer, and 'slave' copies in each of the other computers involved. The 'slave' copies are updated automatically at either specified intervals or when a master copy changes. These methods are seen as preferable to an 'on demand' approach when dealing with real time situations. - 42 -

This method of global data organization relies on the definition of machine-independent messages to interrogate and update the data. Each computer contains a directory of the names and types of all global data that it holds which enables the necessary data connections for the remote update messages between computers to be established automatically. Once established the update messages use direct addressing to reduce overheads. It follows that schemes can be designed as separate modules without explicit reference to the distributed nature of the system.

Provision has been made to minimize the effects of accidental _changes, and global data items are therefore created by a carefully controlled process distinct from scheme creation. A scheme will not translate successfully if it refers to a global item which does not exist in the computer for which it is being translated. In general only one scheme may write to a given data item, effectively becoming its 'owner' though any number of schemes may read the item. This check is applied at scheme installation time, and this simplifies the maintenance of system integrity, in particular when inserting or removing schemes. A record is kept of the number of schems accessing an item of data so that the item (and hence the scheme updating it) may only be deleted when no scheme remains that uses the data. In the event of loss of communications between computers, or failure of a scheme owing 'master' data all the relevant 'slave' items in the other computers are automatically flagged 'bad'.

6. CONCLUSIONS

The rapidly increasing use of distributed computer systems for on-line control projects emphasizes the need to contain the resource require- ments associated with the development and long-term support of such projects. The adoption of standard portable software appropriate to a range of applications, and designed for use by engineers rather than computer specialists, is considered a significant factor in reducing these resource requirements and has led to the design of the CUTLASS software system described in this paper.

7. ACKNOWLEDGEMENTS

The author wishes to acknowledge the contribution of the members of Central Electricity Generating Board concerned with the development of CUTLASS and the formulation of the software policies outlined in this paper. The paper is published by permission of the Central Electricity Generating Board. - 43 -

DISTRIBUTED CONTROL AND DATA PROCESSING SYSTEM WITH A CENTRALIZED DATABASE FOR A BWR POWER PLANT

K. Fujii * T. Neda * A. Kawamura ** K. Monta *** K. Satoh ***

* Atomic Power Generation Control Systems Designing Section, Fuchu Works, Toshiba Corp.

** Control and Electrical Engineering Section Nuclear Energy Group, Toshiba Corp.

*** Nuclear Engineering Dept.. NAIG Nuclear Research Labo., NAIG Co., Ltd. - 44 -

ABSTRACT

Recent digital technics based on remarkable changes of

electronics and computer technologies have realized a

very wide scale of computer application to a BWR Power

Plant control and instrumentation. Multifarious compu-

ters, from micro to mega, are introduced separately.

And to get better control and instrumentation system

performance, hierarchical computer complex system archi-

tecture has been developed.

This paper addresses the hierachical computer complex

system architecture which enables more efficient intro-

duction of computer systems to a Nuclear Power Plant.

Distributed control and processing systems which are the

components of the hierarchical computer complex, are des-

cribed in some detail, and database for the hierarchical

computer complex is also discussed.

The hierarchical computer complex system had been developed and now under detail design stage for actual power plant application. - 45 -

INTRODUCTION

The number of nuclear power generating units and the

capacity of generating units are steadily increasing;

in consequence, the efficiency of the control, operation

and safety of plants urgently needs to be improved.

Under such circumstances, owing to the recent progress of

process computer hardware and software technics, the

process computer systems introduced in to power plants

and becoming increasingly multifarious.

Form the point of view of elevating the level and

efficiency of plant operation, the tasks to be accomplished

in plants by computers have been readjusted and systema-

tized. - 46 -

HIERARCHAL COMPUTER COMPLEX (HCC) CONFIGURATION

The HCC is an overall computerized control and instrumen-

tation concept and is based on a systematic analysis of

the information concerning BWR power station operation

and management. Information and its processing system

have been classified into two categories from a functional

view point, and three levels dependent on scope. The

total system has been designed on the basis that control

and processing should be distributed in order to minimize

the chance of total system fail. On the other hand infor-

mation should be centralized to allow manual intervention.

Category 1 is supervisory and control of the plant

operation.

Category 2 is data processing and management.

Three levels of the HCC are

(1) Level 1 for power station overall information manage-

ment involving plueal generating units.

This level is called a site database.

(2) Level 2 for information processing, supervisory and

control of the generating unit.

This level is called a-unit level.

(3) Level 3 for local control and data processing which

is based on distributed system technique. This level

is called a local level. - 47 -

Relationship between above categories and levels is shown in Figure 1.

Computer systems in BWR based on the HCC concept are shown in Figure 2. The major components of the HCC are database computers, data communication Networks and specific computers in each level. .

Level 1 c Site information management

Unit operation Unit data Level 2 Supervisory and Processing and control Management 0 Local data Level 3 Local Control processing

Category 1 Category 2

Figure 1 Relationship between categories and levels Utility Center Comp.

Li-<•/<•;! 1 Site Data /situ Level' Base Comp. IComp.

Unit Data Level 2 Base Comp. /Unit \ I Subsystem) Plant Podia Rad Waste Radio Active Personnel \Comp. / Dosimetry Diagnosis Comp. Sys Comp. Sys Management I Comp. Comp. Sys Management Comp. Sys 03

Shipping I! Plant Data PLR RAD Waste Process Radia- Level 3 TLD Automation I Treatment Control Control tion Monitor /Unit LocaP ( Control ISI Area Radiation Whole Body \Comp. Automation Control Monitor Counter

CRD Exchange; Rx. Press Dust Radiation Automation Control Monitor

Re-; fiii-liny Platform Automation

Figure 2 Computer System in BWR - 49 -

Two major data highway loops are provided in the HCC, viz.

site loop and unit loop. The unit data highway loop

interconnects level 2 computers and transmits data from the operating plant to the unit database computer. The site data highway loop interconnects unit database computers and

transmits data from unit database computers to the site database computer. Configuration of the HCC is shown in

Figure 3.

Utility Center Computer

( Site Data Base\ Other site database computers I Computer )

Site data highway loop

Other unit database computer /'" Unit Database

Unit data highway loop

Unit level computers unit Process Computer

Local controllers, local processors

Figure 3 Configuration of Hiororchical Computer Complex - 50 -

The Level-1 Function

The Level-1 computer system is interconnected to each Unit database computer in Level-2 through a communication line. This computer system accumulates the unit data sent from the Level-2 computer systems, so that the. Station database (Site database) is formed. The major items of the Site database are as follows.

(1) Operating data commonly used by each unit. (2) Plant operating historical records over a long period. (3) Personnel dosimetry monitoring data. (4) Radiation .lonitoring data. (5) Fuel istopic data. (6) Maintenance management data. (7) Site environmental data. (8) Spare parts stock data. (9) Nucleus material library.

The Level-1 computer system performs the following func- tions.

(1) Plant operation management. (2) Security Management. (3) Maintenance Management. (4) Communication with head office. - 51 -

Plant operation management

The control rod patterns are usually exchanged every few

months to attain the ^esired fuel exposure distribution.

A reactor simulation program makes a prediction of the

long-term fuel exposure, and reactivity change rate, which

provides the plant manager with the capability of planning

the changes in the control rod pattern. The Level-1 com-

puter system can offer past, present and future operating

data in order to maintain optimum operations.

Security management

In order to reduce the personal dose, it is necessary to

monitor the personnel dosimetry throughout the working

hours and work area. Personnel dosimetry monitoring is

a slow laborious, routine task, the computer assists in

such a routine task by acquiring several types of person-

nel dose data via the Level-2 computer system, and

storing them in the Site database. The dose data can

then be printed out and/or displayed for each person

individuallly, on request.

On the other hand, the Level-1 computer system records and monitors area radiation, process radiation, process discharges and environmental conditions in many locations, both inside and outside the BWR Power Station. This radiation monitoring data is verified tc maintain the environmental conditions in their correct range. - 52 -

Maintenance management

Routine maintenance is conducted in accordance with the specified procedures, to reduce the possibility of error disturbance to the components. It is essential that the component and system maintenance records are properly maintained, to facilitate the scheduling and completion of all the necessary maintenance. The computer performs the schedule reporting of the necessary maintenance and testing, and spare parts stock management, in support of the routine maintenance.

Nonroutine maintenance is scheduled as necessary during periodic shutdowns of the unit. Some examples are, refueling (;exchanging the fuel assembly), control rod replacement, control :.:tfad;C'drive mechanism removal and replacement. The c£>inpU:|fer xaemQri2:;es the component his- tories and lists all necessary ^replacements of the compo- nents.

Communication with the Head Office

The Level-1 computer system can communicate with the Head

Office through a communication line such as a telephone line. Economic load dispatching can ba achieved by receiving the load schedule, from the Head Office to the

Station, via a communication line. The Level-1 computer system can perform load calculation and dispatch the unit schedules. - 53 -

The Level-2 Functions

The Level-2 system, (computer complex), consists of the following;

(1) Unit database computer system.

(2) PODIA (Plant Operation by Displayed Information and

Automation) system.

(3) R/w (Radioactive Waste Treatment) supervisory compu-

ter system.

(4) RPDM (Radiation and Personnel Dosimetry Monitoring)

system.

Unit database computer system

The Unit database computer system gathers the unit opera- tion real time data from the other Level-2 computer systems, then handles and transmits it to the Level-1 computer system. The unit database is a part of the Site database, which is especially concerned with the respective unit operation data.

This system controls the communications between the Level-

2 systems when accessing the unit database.

PODIA system

The main objectives of the PODIA system are to provide an effective aid for the monitoring, control and operation of the unit. The PODIA system performs an important role in unit operations. The main interface between the Opera- - 54 -

tor and the Plant is a computerized and miniaturized PODIA console (Advanced Operator Plant Interface), located in the central control room. The unit operating data including the status, value and alarms, is displayed on color CRTs in graphic display formats. In the PODIA sys- tem, the hardware display devices (i.e. meters, indicators, recorders, etc.) on a conventional operating berchboard are replaced by color CRT graphic displays.

Switches and control devices are fully miniatuarized, and their number reduced by computerized automation. Therefore, the PODIA console is much more compact in contrast to the conventional operating benchboard, (about one third)

R/W supervisory system

The objectives of this system are to monitor the liquid and solid waste treatment system components.

In this system, hardware mimic display panels are replaced by the full color CRT graphic displays, so that this sys- tem console is more compact in size than a conventional

R/W operating board. The computer system conducts the detailed historical data logging and liquid waste mass balance calculations. - 55 -

RPDM system

The major functions of the RPDM system are the monitoring

and recording of the process radiation, area radiation and

liquid and gaseous radiation. Another function of the

RPDM system is the personnel dosimetry monitoring, which relieves the staff in charge of radiation protection, of the burden of laborious and time-consuming routine work.

Level-3 Function

Local control and data processing computers based on the distributed system technique have been widely introduced into BWR Power Plant.

Examples of the Level-3 are;

(1) Digital controllers for power control.

(2) Programmable logic sequence controllers for Rad/

Waste control.

(3) Refueling platform automation.

(4) Control rod drive mechanism exchange automation.

(5) Dosimeter reader controller.

(6) Pre-processing of the signals for plant diagnosis

system.

(7) Reactor power program controller.

Digital Controllers for BWR Power Plant control

Digital Controllers, one of the typical application exam- ple of a distributed control system, which utilizes 16 bits - 56 - micro-processors has been developed to control BWR major control systems, such as primary recirculation control system, reactor pressure control system and feed water control system.

In general, digital controllers consisting of micro- processors have numerous advantages in comperison with analog controllers.

These are;

a. Separation of function and hardware

b. Easiness to standardize and modularize hardware

c. Flexibility to change, add or delete

d. Capability of complex arithmetic and logical

functions

e. High reliability and mairltainability

TOSHIBA has developed micro-processor application study and applied it to the primary recirculation control system, reactor pressure control system and feed water control system.

Figure-4 shows the system configuration of digital controllers for the power control system.

The digital controller consists primarily of CPU (Central Processor Unit), memory, and process I/O interface. - 57 -

Hardware specification

CPU Execution time 2.1 ys Instruction word 16 bits/32 bits I/O transfer rate 38 Kbytes/sec Micro program control

Memory Magnetic core 16 bits + 1 parity Cycle time 800 nsec

Capacity 32 Kbytes

Process I/O High Speed Analog Sign + 11 bits Interface Input

Normal Sample Mode 20 % 25 us

High Speed Analog Sign + 11 bits Output

Speed 10 JJS

Digital Input/Output

The system performance is demonstrated utilizing the hybrid

computer. (Simulation Test)

System performance is demonstrated as follows:

a. Basic control performance b. Demonstration of the capability to improve and

evolve for example

Reactor water level setdown function on turbine

trip or reactor scram

Recirculation pump runback for a feedwater

pump trip Turbine Inlet Pressure

-O

Generator in Power oo

Reactor Water Level

,evel 2 Computer Figure 4 Digital Controller for Power Control System - 59 -

It is confirmad through the simulation test that the control performance of the conventional analog controller can be realized by the digital controller and that the digital controller, has the capability to add, improve, and evolve plant control function satisfactorily.

Sequence Controller

Process control functions in nuclear power plant are becoming more and more complicated in order to attain safe and reliable system conditions.

These complicated control functions cause an increase in the number of components, such as relays, contactors and wiring.

Therefore, the availability and reliability of these control circuits is decreasing in proportion to the increase in the number of components.

TOSHIBA has developed a compact, highly reliable sequence controller for application in a nuclear power plant.

Sequence controller logics are stored into the memory and controlled by the control program.

Control processor is 16 or 12 bits LSI.

An actual application in a nuclear power plant is in the radio active waste system.

The reason why radio active waste system application is selected is that this system is a more complicated func- tion and the system scale is very wide. - 60 -

By application of the sequence controllers to a radio- active waste system, the total control panel length is reduced to almost one-second of the conventional control panel.

The sequence controller also has a data processing function in order to transmit process data to an upper level supervisory process computer. - 61 -

COMMUNICATION NETWORK AND DATABASE

• To achieve optimum system performance 2 merits and de-

merits of the distributed and/or centralized system have

been studied. Major components of the distributed system,

viz. database, communication method and processing modules,

had the key to system performance, therefore they have to

be selected for optimum performance. Computer systems in

each level described above, are examples of processing

modules.

A communication network is essential to the distributed

system to attain the centralized supervisory information

system. To reduce the plant operator's burden, information

of the plant operation has to be gathered and prepared

ready for use. Performance of the communication network

is shown in Table 1 as an example.

A nuclear power plant involves a very large scale and

complicated process, therefore database of plant operation

and management is utilrzed not only for

No. of station 64

Communication Speed 10 Mega bps

Connection Duplicated Loops

Distance between station 4 kilo meters

Maximum loops length 100 kilo meters

Table 1: Performance of Communication Line - 62 - daily plant operation, but also security control and plant maintenance.

A nuclear power plant is so complicated and data is so interrelated that a centralised database system have been adopted rather than a distributed database. Capacity of the database is more than 300 Mega Bytes. - 63 -

CONCLUSION

.Computer based, totally integrated digital control and moni-

toring systems have been developed, and distributed systems

are introduced as a local level. It is expected that this

trend towards the digitalization of control and instrumen-

tation will become more common.

Then, problem to determine a reasonable devision between

hardwired and softwored systems will need to be studied.

Micro-processors have realized the distributed system but

emergence of high performance mini computers, called super-

mini, provided a chance to introduce a site specific infor-

mation management computer within reasonable cost. Hence,

it is necessary to study a total system involving both

distributed and centralized systems.

Further study will be made to include a remote multiplex-

ing system which will be classified below level 3, say to

level 4, to improve reliability, availability and main-

tainability of a nuclear power plant. - 64 -

REFERENCE

. (1) M. Raneda et al.

"The New Integrated Hierarchical Computer Complex in

a BWR Plant"

Paper, IFAC Symposium on Computer Applications in a

Large Scale Power Systems, New Delhi Aug. 1979.

(2) H. Kawahara et al.

"On-line Process Computer Application for Operator's

Aid in TOSHIBA BWR"

Paper, IAEA Specialists' Meeting on Procedures and

Systems for Assisting an Operator During Normal and

Anomalous Nuclear Power Plant Operation Situations,

Mumich Dec. 1979.

(3) R. Aoki et al.

"BWR Centralized Monitor and Control Systems, PODIA

TM Development"

Toshiba Review Int'1 Ed. No. 107 Jan. - Feb. 1977.

(4) K. Makino et al.

"Reactor Management System"

Paper, Enlarged Halden -Program Group Meeting, Loen

June 1978. - 65 -

'PROWAY' - A STANDARD FOR

DISTRIBUTED CONTROL SYSTEMS

R.W. Gellie

Control Systems & Human Engineering Laboratory

National Research Council of Canada

ABSTRACT

The availability of cheap and powerful microcomputer and data communications equipment has led to a major revision of instrumentation and control systems. Intelligent dsvices can now be used and distributed about the Control system in a systematic r-nd economic manner. Thes« sub-units are linked by a communications system to provide a total system capable of meeting the required plant objectives. PROWAY, an international standard process data highway for interconnecting processing units in distributed industrial process control systems, is currently being developed. This paper describes the salient features and current status of the PROWAY effort. '

INTRODUCTION

Industry is facing shifts in the economic climate with increased emphasis in such areas as energy management, pollution control, and conservation of natural resources. Future in- dustrial prociss control systems must reflect these changing demands by offering better control, reduced production costs, and more complete and accurate operating data upon which to base management decisions. - 66 -

Improved performance and economies are already being

realized through exploitation of the developments in semi-conductor

technology. Control system components and subsystems are being

redesigned to take advantage of microelectronics. The new

generation of local instrumentation and control 'functions, con-

taining inbedded intelligence through microprocessor-based

computers, not only offer improved performance but have enable^

a much wider spectrum of potential applications.

Other developments especially in electronic data processing

(EDP) and telecommunications, are also helping to shape future

process control systems. The availability of inexpensive and

powerful microcomputers together with data communications

equipment has made local and extended computer networks a

viable and attractive approach in the data processing environ- ment .

Under the influence of these developments the traditional

approach to process control system design is being revised.

Intelligent devices and subsystems can now be used and distri- buted within a complete control system in a systematic and economic manner to achieve improved system performance.

DISTRIBUTED CONTROL

This distributed architecture returns the control functions to the remote points where they can be most conveniently per-

formed and managed. Such process control systems are reminiscent of the original manually operated plants in which instruments,

transducers and controllers were mounted directly on production

units distributed throughout the plant. At the same time - 67 -

distributed digital control incorporates many of the hardware

and software concepts of the classical centralized computer

control systems while avoiding the risks of depending on a

single computer.

In essence the new distributed approach embodies the best

features of distributed analog control and centralized digital

control to provide improvements in system performance and cost.

Distributed control offers many advantages to the system

designer. Hardware and software complexity are reduced by

partitioning whereby the system is subdivided into relatively

small subunits which are capable of concurrent processing.

Interference between subunits is minimized because they are

functionally independent. Maintenance and fault diagnosis of

software and hardware are greatly simplified. The inherent modu-

larity of hardware and software permits economies of scale in

instrumentation, control and communications.

The key to the successful exploitation of distributed process

control is the rationalization of these concepts into an inte-

grated approach to system design.

Traditionally, specialist suppliers have been identified

with transducers, actuators and instruments. It is equally

true with computers, microprocessors, and communications equip- ment that no one vendor may have the expertise or products to meet the requirements in all fields. Similarly software

functions such as operating systems, real-time languages, data- base management and networks are regarded as specialist activities.

It therefore requires the detailied identification and - 68 -

specification of software and hardware modules and their

interfaces to permit coordination and integration of the

components into a viable system.

However, it is not sufficient to ensure cornpatibility of

system components. The system must be capable of meeting

performance objectives and must be optimised for the appli-

cation and the operating environment.

PROCESS PLANT •

In a typical industrial plant processing units are gruuptd into local areas where a specific part of the process is performed. In each such area materials and energy are converted into intermediate or final product by local unit operations such as heating, cooling, mixing or chemical reactions. Each of these local process units may require monitoring or corrective control.

Throughout the plant there may be many local areas or control rooms each physically located near the processing units. The activities in each of these local areas must be coordinated and kept working to achieve overall plant production objectives. The product from one area may be the raw feed stock for another area. Several local areas may share common services such as steam, water, etc. Coordination of the plant requires that there be good access to process status information from these areas.

The plant may be operating according to corporate production schedules. It is necessary that management in- formation be made available if timely and economic operation of the plants is to be achieved. - 69 -

The typical industrial plant can be divided into a

hierarchy as shown in Figure 1. At each level there is a flow

of status information from lower levels and a flow of control

commands to lower levels. Superimposed on this'control

hierarchy is a topology determined by the physical location and

constructional layout of the plant. The topology determines

the transmission distance between levels. The nature of the

functions performed at each level determines the response time,

integrity and security requirements of the control and information

signals.

Local Area (Direct Control)

Control of the local process plant is via communication with sensors and actuators over short distance. Real-time process response requirements are determined by the plant dynamics and can be fast. This is the most time-critical level,-any failure here requires immediate action, typically within minutes or even seconds. Duplicated functions and standby units are frequently used in sensitive areas. Dedicated control units or units capable of autonomous operation are an obvious choice to ensure that the real-time response require- ments can be met. With the advent of cheap microprocessor computing power the operational area can now be under the control of several dedicated control computers. These intelligent units not only execute the detailed control tasks but also perform data collection and reduction in support of the information requirements of the higher levels of control. - 70 -

Plant Level (Supervision)

This level is concerned with the interactions between

operating areas. The control function here is one of coordin-

ation and supervision of the various operating areas to achieve

an intergrated production facility. The process response requirements are still real-time and time critical but, since the inter-area control is supervisory rather than direct, the requirements are less demanding than at the operating level.

In the traditional centralized computer control system a single large computer was located at this level. This computer connected directly to actuators and sensors through individual dedicated lines radiating from it. Because this computer performed the local area control functions it was often hard pressed to satisfy multiple interleaved real-time demands from the various local plant areas.

When the intelligent units in the local areas perform the detailed control tasks, the computational load and communication requirements at the plant level are greatly reduced.

Corporate Level (Management)

Management decisions require a total picture of the multiplant operation but this plant data is not required in real-time. Production targets may for example be set on a daily basis. In this case it would be sufficient that the data base accessed by management be refreshed within this period. Similarly, a failure of the communication systems for less that this period would not interfere with the up- dating of plant production targets. - 71 -

Communication Requirements

The communication and response time requirements vary considerably between the levels of the control hierarchy. In a centralized computer system all communication is handled by this single processor which must satisfy the time-critical needs of all the process units as we'll as transfer information to the management level over considerable distances. All communication is between levels.

In a distributed processing system intelligence is added at the lower levels where response times must be fast, data rates high and communications availability and integrity are most important. Not only does this unburden the higher levels but it localizes the time-critical communication so that the transmission distances can be kept short. Information transfers can now occur between units at the same level so further reducing the data flow between levels.

It is apparent that the communication and response time requirements vary considerably between the levels of the control hierarchy. Communication within a control room or a local area of a fast plant may involve information rates of

100,000 baud transmitted over 200 metres. Plant dynamics may require resonse times measured in seconds. On the other hand management level communication is not time-critical and might be typified by an information transmission rate of 20 kbaud over a distance of several kilometres.

A hierarchy requires a structured communication systems with each level of communication optimized for the distances, data rates and traffic patterns demanded by the appreciation environment. - 72 -

STANDARDIZATION IN COMMUNICATIONS

It has been widely recognized that a standard communications

system, capable of supporting the requirements of distributed

process control as discussed above would enable .the system

designer to construct truly integrated systems.

In April 1975 at a meeting of Subcommittee SC65A (System

Considerations) of Technical Committee TC65 (Industrial Process

Measurement and Control) of the International Electrotechnical

Commission (IEC), working group WG6 was established and charged with developing "PROV.7AY:a Process Data Highway".

The communication system proposed b" IEC SC6 5A is an asynchronous or half duplex message mode serial line. The functional requirements of such a system have been defined and are incorporated in a draft proposal for the PROWAY System, which provides a specification for functional and operational requirements. '

The functional requirements document has been published and is freely available. The following requirements are intended to convey some "feel" for the PROWAY proposal:

(i) PROWAY is not intended to provide either an optimized

. interface for high-speed standard computer peripherals,

or efficient sharing of mass storage ;r periperals

between processors,

(ii) PROWAY is to be capable of supporting centralized

intelligence, distributed intelligence, and hierarchial

intelligence.

(iii) PROWAY is to be optimized for bit serial data over a

single shared communication link;a complete system

may i :mtain several independent links forming a network. - 73 -

(iv) PROWAY is to be capable of supporting transmission of

event-oriented data in real time. Also it is to be

capable of supporting direct data interchange between

any two stations without involving store and forward

at a third station.

(v) PROWAY allows one originator to deliver frames con-

currently to several destinations. Each destination

is able to independently acknowledge that frame,

(vi) PROWAY is to be capable of maintaining correct frame

sequencing and integrity of transmitted data while

operating in an electrically noisy environment,

(vii) The rate of undetected frame errors should be less

than one error per 1,000 years of operation, provided

that the data circuit bit error rate is less than

10 and the frame length is less than 100 bits,

(viii) No single failure of any part of any device should

cause failure of the entire process control system, or

of any functions except those in which the failed

device is directly involved,

(ix) The process control system should be capable of

tolerating changes of configurations without loss of

communication function, failure of any one transmission

line, or failure of any one station.

(x) PROWAY should respond to unsolicited requests within a

time period appropriate to the application (typically

2 ms.). - 74 -

The PROWAY specification is not intended to restrict the

technology of construction or the architecture used in a

particular application. It couldj for example, encompass a

twisted pair wire telecommunications link at one extreme or an

optical fibre communications system at the other. It does, hc-wever, provide guidelines on safety, integrity and system availability, which would apply equally to each type of system.

A PROWAY station is seen as having five logical levels of protocol as shown in Figure 2. Each protocol layer is an indepen- dent and logically complete specification. The final PROWAY proposal will include detailed specification of each of the protocols and interfaces (the network protocol is not included within the scope of the PROWAY standard). The Highway Interface and Path Interface are logical entities only, but the Coupler

Interface and Line Interface will be described fully with electrical and mechanical specifications.

Current activity within the PROWAY effort is focussed on two basic aspects of the communication system? the path or link protocol, and the mechanisms for link control and link access.

Path Protocol

The- function of the path protocol is to perform the con- version from an error prone, serial physical circuit to a relatively error free logical link. The Path Unit serializes and deserial- izes frames, generates and checks error detection codes, ensures data transparency, and performs sequence control.

A number of path'protocols are in common usage for inter- computer communication. The most widely used are BISYNC, DDCMP,

SDLC, ADCCP and I1DLC. HDLC is an international .standard protocol - 75 -

defined by the International Standards Organization (ISO).

It is of particular importance because it is specified within

the International Telegraph and Telephone Consultative Com-

mittee (CCITT) recommendation X25 which is a powerful network

access protocol designed for the long distance, packet

switching networks (such as DATAPAC in Canada). X25 will

almost certainly be implemented by common carriers world-wide

to provide an international communications network.

HDLC contains a frame-level link protocol which has

already been implemented in LSI hardware by many semi-conductor manufacturers. One VLSI chip (Western Digital WD2501,WD2511) which also includes many of the communications control functions has been announced with sample quantities available early 1980.

IEC SC65A WG6 has already passed a resolution to implement as many features of HDLC as possible in the PROWAY system. This will not only give economies in production, but will also allow compatibility between the process control networks and the EDP system within a company. It will also allow the process control community to use or adapt the peripherals, mass storage devices and test gear developed for the HDLC-orientated

EDP market.

However, HDLC was developed for single master long distance communication and there are several aspects of the protocol which do not meet the PROV7AY functional requirements.

The specific areas of concern are:

(i) Asynchronous worst case responre time to Demanders.

(ii) Direct, peer-to-peer data exchange,

(iii) Undetected error rate. - 76 -

(iv) Broadcast messages with separate acknowledgements.

Cooperation with ISO is currently being solicited to determine the minimum enhancements of the present HDLC

standards that are needed to meet the PROWAY functional re- quirements. It is important that these enhancements be agreed upon and accepted as part of the ISO specifications as soon as possible ais to ensure that the next generation of VLSI chips don't include or .omit features which will result in their being incompatible with PROW/AY.

Figure 3 shows a typical implementation of a PROWAY station using microprocessors and "HDLC" chips, etc.

Link Control and Link Access

The PROWAY proposals describes a process control system including up to 100 stations (intelligent units) of which at least two could be "manager units" responsible for data high- way management; at least another two could act as "supervisor units" responsible for supervision of highway operation; and at least a further eight could be "demander units" capable of making unsolicted requests for permission to use the data highv.vy. A typical i istallation might consist of 31 stations, of which four are likely to be demander units.

PROWAY defines a multi-master system; at any given time control of the link will be localized, but the location of this control will vary with time. Mastership, or the right to allocate link access, c::n be transferred -in many different ways. The PROV7A.Y Vtorking Group is currently conri daring a.'icl evaluating alternative transfer mechanisms. - 77 -

The requirement that there can be direct information

exchange between any two stations without necessarily involving

store and forward in a third station and that the conununication

system must be able to handle unsolicited demands implies that,

at any given time,, several stations may be candidates for link

access. The method proposed for allocating link access and

the mechanism selected to transfer masteship are clearly inter-

dependent.

The path protocol and mastership/link access mechanism

are seen as key areas of the communication system. Once these

aspects are resolved it is expected that, it should not take

long to develop the complete PROWAY specification . A draft proposal of the complete PROWAY specification should be avail- able in late 1981.

CONCLUSIONS

Distribution of the control functions among intelligent devices located close to the process uni permits an architecture more compatible with plant topology. r : communications system which supports this distributed proce ing can""be designed to match the control structure of the p-L.^nt. Distributed process control systems would seem to be a more natural approach than the traditional centralized computer systems. The PROWAY standard should enable the design of integrated distributed process control systems to be optimized for the application environment and capable of raeeting production and cost objectives. INCREASING CC^PCFATE DISTANCE

PLANTS

I

00

XT \ INCREASING FASTER PPCC^SS L INTEGRITY, RESPONSE UX.TS oh }AV/AILAEILITY TIME

FIGURE 1:_OPERATIONAL LEVELS AND COMMUNICATION CHARACTERISTICS APPLN. UNIT APPLN. UNIT APPLN. UNIT —

NETWORK IN"1'ERFACE & FRAME

NETWORK UNIT ! NETWORK SERVICES: BUFFER, SOURCE/SINK CHECK S PROTOCOL , NETWORK MANAGEMENT: PACKET SWITCH DIRECTOR* HIGHWAY INTERFACE a FRAME

HIGHWAY UNIT ERROR RECOVERY, LINE ACCESS, MANAGER fi p' n [ SUPERVISOR, (DEMANDER), INITIATOR, RESPONDF.R, °_ (LISTENER)

PATH INTERFACE a FRAME

PATH UNIT ' ADDRESS RECOGNIZE, ERROR CODE, I a PROTOCOL J SERIALIZE COUPLER INTERFACE a FRAME f LINE COUPLER SIGNAL CONDITION. SYNCHRONIZE a PROTOCOL LINE INTERFACE a FRAME Y TRANSMISSION LINE

FIGURE 2: SIMPLIFIED PROWAY STRUCTURE r 1 t X-0 A I

1 APPLICATION UNIT .? I i APPLICATION UNIT ft 2 C< j I/O j ! UART j SINGLE-3CARD MICRO-CCV.PJTF.R j ' ! I i APPLICATION PROGRAM PROM ! ;

CC'JPLER-

00 o ; PAR~ cjr ' .VEITV.-CRK 3 '•;GL E-BOARD MICRO - 00^ '.PUT ER COMMON ' A\D RAM \LTWC.V. FROIC COL FROM ! HIGH'.VAV i r.OLC Hi GHV, AY PROTOCOL PROV, CH'P -NETWORK,HiGH'/VAY AND I 1 PATH UNIT 1 CO'JPLER INTERFACE LI NE ! LINE CCL'PLER STATION DRIVER I 7" -I"1 — L'.\'E INTERFACE J TRA\SV!;SSiCN LIKE F

FIGURF 2: EXAMPLE OF AN IMPLJ^FXTATION OF A PROWAY STATION - 81 -

Not for reproduction 65A(Secretariat)l8 Original: English March 1979

INTERNATIONAL 3LECTR0TECHHTCAL COICHSSION

TECHNICAL COI&ITTTEE Ifo. 65: INDUSTRIAL-FROCEGS MEASPKCJIEKT AND COBTROL " SUB-COfftHTTES 65A: SYSTEM CONSIDERATIONS

Draft - Process, data highway (proway) for distributed process control systems Part 2: Functional requireEents

This document has been prepared by VG 6 of SC 65A in accordance vjith the decision taken during the meeting of SC 65A held in Koscov in April 1975. It is submitted to National Connittees for comnents. This document nay be also of interest to the experts of other technical comnittees especially TC 45,

* Part 1: General and Fart 3: Glossary will te circulated shortly. Other Part3 in this Series are in preparation. - 82 -

Introduction ......

1. Scope •

2. Application environment 2.1 Optimum characteristics 2.2 Economy versus technical factor..

3. Device typea 3.1 Communications between devices ...... «'..... 3.2 Interface linitations ,

4. System structure A.I Control system structure.. 4.2 Data highway structure 4.3 Coapatability with other systems ^ ,

5. Maintenance and service features 5.1 Testing and fault diagnosis 5.2 State transitions ......

6* Protocols ..,. 6.1 General description cf protocols 6.2 The role of each protocol 6*3 Protocol functions 6.4 Line coupler and protocol 6.5 Path unit and protocol 6.6 Highway unit and protocol ,...... 6.7 Network unit end protocol...... 0 6.8 Application protocols

7. Safety ...„ 7.1 Fault potential ....,,. ;..... 7.2 Optional versions

8. Data transfer integrity...... 8.1 Use in electrically noisy anvironmente...... 8.2 Error detection algorithms 8.3 Residual error mode.. 8.4 Undetected frame errors 8.5 Low bit error rate i......

9.' System availability ..,...... '...... ,». 9.1 Restrictions on failures..,, 9.2 Tolerance to changes of configuration 9.3 Redundancy ...,.....,...... »...... ,..,,.,....«...... ••...., 9.4 Internal status and error reporting 9.5 Automatic recovery 9.6 Control of stations

ZZ2843v 65A(Secretariat)l8 - 83 -

Clause 10. Performance criteria lOy 1 Communication efficiency ...... ,*.. IO\2 Response tine'...... FIGt l£S 1. Simplified PROWAY structure and terms 2* • Allocation of communication functions, within a PROWAY station. 3a. Relationships between PROWAY stations 3b. Composition of data circuits, data paths and data highways ... 4* Example of an implementation of a PROWAY station

INTRODUCTION The characteristics! which differentiates process control systems from other on-line real-tine computer networks is that the control ayotea output causes material or energy to'nave. Devices comprising a distributed process control system should be able to coMiunicate uaaaibigously over a shared process data highway (FR03AY). the data highway should ba suitable for serial transmission over a single, shared electrical transnisssion line but the use of alternative trensaission cadia and modes (such as fibre optics and parallel transmission respectively) vny ba included.

1. SCOPE This docusiant describes fuuctioc^l requirements of e. system for communication between devices that comprise a distributed process control system. XftOWAY communication protocols and interfaces complying t/ith this Gtandard vrill ensbie devices ocnufactured by different organisations to ba used in the case control system. • ' • - 84 -

2. APPLICATION ENVIRONMENT

2.1 Optimum characteristics

The characteristics of the data highway should b2 such that they provide optimum conditions for use in control systems U3ed in die prccdiEg industries and shall be applicable to both continuous and discrete processes. A process data highway is characterised by the following:

a) Event driven cotsmunlcation which al!i>'T3 real time response to events.

b).Very high availability.-

c) Very high data integrity.

d) Proper opsratioa in the presence of electromagnetic interference and differences in earth potential and

e) Dedicated intra-plant transmission lines.

2.2 EcbnoEi'c versus technical factors

To achieve broad applicability it is essential that process data highways should be economical to use in control systems under the following conditions:

a) With low or high information transfer rate requirements.

b) Within a control 'room ?.nd/or while exposed to the plant environment and

c) In geographically snail or large process plants.

2.2.1 The ecor.oaic and technical factors may need to bs reconciled in order to achieve a balance batwaen transmission line length and data signalling rate.

2.2.1.1 A data highway contained entirely within a local area (such as a control rooa5 gsnecally requires:

a) A transmission line length of 200 a and

b) An information transfer rate of 100,000 bits/sec.

2.2.1.2 A data highway which traverses a large plant generally requires:

a) A transmission line length of 2000 m and

b) An information transfer rate of 30,000 bits/sec.

NOTE - While the requirements given in 2.2.1.1 and 2.2.1.2 are typical, there are classes of control systens with both substantially higher and substantially lower requirements. - 85 -

3. DEVICE TYPES

3.1 Communications between devices

Communications shall be provided between devices of the following types:

a)-Input, output and control devices. Examples of these are as follows:

1) Analog inputs - with and without special signal conditioning*

2) Digital inputs - with and without change of state notification.

3} Analog output.

4) Digital output.

5) Scanning and analytical instrument interfaces.

6) Combinations of the above.

7) Combinations of the above including process monitoring, alarm and/or control algorithms.

b) Man/machine interface and product identification devices. Examples of these are as follows:

1) Process operator consoles.

2) Alarm displays and annunciators.

3)' Video terminals.

4) Teleprinters.

5) Keyboards and keypads.

6) Character, line and special displays.

7) Label readers.

8) Sin5le card -aaders - mark sense and punched.

9) Badge and magnetic stripe readers.

10) Dedicated card punches.

11) Label, ticket and special forts printers.

12) Combinations of the above.

13) Combinations of the above including process monitoring, alarm and/or control algorithms. - 86 -

c) Service, suuport and maintenance

d) Superi^ory coivputera a) b) esid c) which control and interrogate the devicee described i;i 3.1. Theoa computers nay be required to exchange large blocks of dzt?. ciid/ci" prosrair^fs \r±th Che other devices on an infrequent basis... .

e) Combinations of e.ay or all of the above.

A process data highway is not intended to provide an optimized interface for ".ligh-speed computer peripherals, such as ziass Emories, line printers, unit record equip*n.?nt cr graphics terninals. It is also not intended for efficient sharing of V~KS storage cr peripherals between processors.

Ho devicse cr V'vr.j of devices are r.pecifically excluded from exchanging data over a process

4.1 Coatrol JY.°tf.a sirv.turs

L frocasa data hish?.v.y rb.clJ be capable of supporting control systems with ".eiZcrtflissi intolii.^nnce, distributed intelligence, hierarchical Intelligence aad cozbinr.tion." thereof.

4.7. feta hi",li^.';_ rtru'vzitre

TI.c data hich,.-.ny chcll be CApabic of supporting transmission of event oriented data in real Mrs. It shall alec ba capable of supporting direct data interchr.iigo 'o2f.\:sep. c.ny ^;o c-tatious without ir.volvir.g store and forward at a third etation.

4.2.1

Other vcrcions ex the cat.i highway nay be required v,hich allow reconfiguration of the control sy-trti v^J.le the procoos is operating.. Such changes may be allowed tc disturb the c::chanp,a of frades if limited to a transient effect, provided that the Hat.v. hiclway is ab.le to def.ect such disturbances and that it can recover full o^eratioti within r. titr.e appropriate to the application, ples of confif,i.'':Atlon dMr-ga.'j which avy be needed are follows;

a) Extendjup, shortening or rerouting transmission, linos and

b) Connc:ct.tr3 or disconnecting, stations froa the transmission line. - 87 -

4.2.2 Station capability of the data highway. The data highway shall allow one originator to deliver frames concurrently to several destinations. Each destination should ba able to independently acknowledge that frame.

A data highway shall ba capable of supporting:

a) up.to 100 stations;

b) at least 8 demander stations;

c) at -least 2 supervisor stations;

d) at least 2 manager stations.

NOTE - A typical data highway may wall support a total of 31 stations, four of which are likely to be de.mander stations.

4.3 Compatibility with other systems

The data highway should be designed to facilitate implementation of certain data circuits using conmou carrier facilities.

5. MAINTENANCE ME) SERVICE FEATURES

5.1 Testing and fault diagnosis

While on-line testing and fsult diagnosis nGe<* n°t be Integral functions of the data highway nevertheless the data highway shall.be capable of cupporting such features which include:

a) traffic nonitoring and

b) loop back tests.

5.2 State transitions

Any station shall bs able to perform transitions from one state to another without generating bit errors between other stations. Examples of such transitions are a3 follows:

a) On-line/off-line.

b) Power-on/povrer-off.

c) Ready/not ready.

d) BuGy/not buey.

•e) Local/remote. - 88 -

6. PROTOCOLS

6.1 Caueral description of protocols

A dictributed process control 3ystea consists of a number of stations that contain explication units. The stations communicate over a process data network (or tigh\.E.y).

Tha logical structure of the data network is defined by several levels (or layers) of ccmauaicntion protocols. Each protocol co-operates with its level of equal rank in other stations supported by the data highway. Each protocol is •interfaced1 vith the protocols above and below it. These relationships are shown in figures i and 3.

Each protocol is logically complete and is independent of the protocols below it.'This, ir.plies that new transmission technologies can be implemented by replacing only the lower level protocols.

Each protocol defines the logical location of the functions required to implement it. The protocols do not necessarily imply physical locations within a station. (Sae figure A.)

6.2 The role of each protocol

The structure of the comiEunication functions within a process control system are shown in figures 1 and 2 and the role of each protocol is as follows:

a) The line protocol is implenented by the line couplers. They convert betv;cca line. ?.nd coupler frames vhich pass across the line and coupler interfaces, respectively.

b) The path protocol is implemented by the path units. They convert between coupler and path frames which pass across the coupler and path interfaces, respectively.

c) The highway protocol is impleisented by the highway units. They convert betvsr.n. paf-h and highway fraices which pass across the path and highway interfaces, respectively.

d) The p-atwo-fc. protocol is implemented by the network units. They convert betveen highway end network franes which pass across the highway and n*2t;*-ork interfaces, respectively.

e) The application protocols are implemented by the application units and co'uplsrs. These protocols provide rules for interpreting information in the network (or highway) frames.

f) TUP. application units perform process control or other user defined functions.

NOTE - While this standard relates principally to one data highway including its transmission line(s), line couplers, path units and highway units, the network units, application couplers, and application units ai.:- described in 7.2 only to clarify their influence on the data highway.

65A(Secretariat) 18 - 89 -

6.3 Protocol functions "

Each protocol shall be capable of carrying out the following functions:

a) Transfer data with high integrity by checking for errors and using appropriate recovery procedures.

b) Notify the next higher unit of errors which it cannot correct.

c) Support communication of arbitrary data within the information field of the frame passed to it from the next higher protocol level.

d) Be logically complete: every possible transaction sequence must be predictable in its outcome and must exit to an acceptable state. Logical completeness may be demonscrated by a transitiou state analysis.

e) Be transparent to transmission line lengths and data signalling rates. This requ:?rement does not apply to- the line protocol or line couplers.

£) Support changes to. the number of Btations connected to the data highway.

g) Support changes to the status and mode of stations connected to the data • highway.

b) Support monitoring and recording or communication performance.

6.4 Line coupler and protocol

The purpose of the line coupler is to convert frames from their internal representation within a station to signals compatible with the transmission line, according to the line protocol. In order to perform this function the line coupler should:

a) Convert signals levels and or formats.

b) Provide galvanic isolation between the station and the transmission line.

c) Monitor signal quality.

d) Generate and detect frame synchronization signals.

e) Add and remove frame delimiters.

f)- Detect transmission line busy, idle, and incomplete states,

g) Synchronize initiator, respondcr and listener(s). - 90 -

6.5 Path unit and protocol

The purpose.of the path unit is to convert frames from their parallel to their serial representations and implement an error code according to the path protocol. In order that the path unit performs these functions it shall be capable of:

a) Serializing and deserializing frames.

b) Adding and removing frame synchronization patterns.

c) Detecting frame synchronization errors.

d) Detecting frame size errors.

e) Recognizing frames addressed to a designated station.

f) Preventing the station from transmitting without pause for an excessive time.

g) Generating and monitoring an error detecting or error correcting code that guarantee high data integrity. The error code shall encompass the complete path frane, possibly excluding synchronization patterns.

vh) Handling highway frames of widely dlfferenc lengths efficiently..

NOTE - Information fields in highway frames typically range from 2 to 1024 bytes of 3 bits each. -

i) Performing switchover to a redundant transmission line when appropriate.

6.6 Highway unit and protocol

The purpose of the highvzay units is to supervise and manage operation of a data highway, including error recovery and control of line access, according to the highway protocol. The highway functions are organized into ranks which ara .given below:

Manager (highest rank) Supervisor Demander Initiator Responder Listener (lowest rank) . •

A station shall contain the function of at least one of the .above ranks. A station is identified by the highest rank function that it contains. A station normally contains all lower rank functions, but that is not a necessary requirement. - 91 -

A station which Is currently performing t.ie funct. lone of a rank should be described as active. Fee example, a station which performs the initiator functions should be knova as the active in.itif.tor. There can be one or more active listeners or daniandera on a data highway, but only one station may be actively performing any other functiou.

A station which desires to ba activated at a rank should be described as a candidate. For example, a station chicn is prepared to transmit a frame and has not yet been granted active initiator status should be known as a candidate initiator.

6. I Functions conraon to all ranks

The functions that all ranks &hall perform are as follows:

a) 24aintain the same time sequence of frames at the destination as at the originator.

b).Support extendable addressing and control structures.

c) Notify the next higher rank of errors which it cannot correct".

6.6.2 Listener functions

The listener functions shall eccept correct frames of Interest to the designated station.

6.6.3 Easponder functions

The responder functions phall accept correct frames containing the designated station's addrcas(e9) and respond as appropriate and also inxoria the initiator of accepted frames immediately.

6.6.4 Initiator functions

The initiator functiono shall carry out each of the following tasks:

a) Respond to the active supervisor's poll with a request for access to the data highway.

b) Transmit frames to listeners*

c) Select transaction responder by transmitting frames containing the responder's address.

d) Detect absence of frame acceptance by the respondcr and initiate recovery procedures which, where feasible, shall be automatic and should not delay other transactions unduly. - 92 -

6.6.5 Demander functions

The demander functions shall transfer an unsolicited request through the data highway. This request is primarily used by a candidate initiator. The request may be transmitted over dedicated lines or by generating special states on the data circuit. If the deiaand function is used routinely, it shall not corrupt frames on the data highway. A process control system may exist without demanders if its real time response.requirements are satisfied otherwise.

6.6.6 Supervisor functions

The supervisor functions ehall parfora the following tasks:

a) Control Una access by establishing the active initiator for each transaction.

b) Arbitrate contention among active deraanders and/or candidate initiatore within a tine period appropriate to the application.

NOTE - In a typical application, the access time of an active denander normally should be less than 2 EG, SO long as the frane transmission time does not. exceed 1.5 TUB and aJ.30 the access tine of a candidate initiator should normally be iesc than 20 ns, so long as the frame transmission time doe6 not exceed 5 ns.

6) Monitor initiator activity to detect and deal with errors.

d) Limit transaction tiraes and numbers as required to keep any initiator from overloading the data highway.

e) Ensure 'continuity of- data highway operation when the active initiator fails.

f) Monitor performance of the data path iu use.

g) Activate an alternate data path where available and appropriate. For example v;hen unrecoverable errors occur on the data path in use or when the transmission line in use ic severed or disturbed. - 93 -

6.. 6. 7 Additional supervisor functions

The supervisor functions given in 7.6 may be supplemented by the following:

a) Transmitting global frames which are addressed .to all stations.

b) Activating and deactivating functions of lower rank within other stations,

c) Initializing and setting modes in other stations.

d) Determining the status and mode of other stations.

6.6.8 Manager functions

A station with a manager function should conitor performance of the data highway (possibly including all stations) and record this information. The managei functions shall perform the following tasks:

a) Assign control of the data highway by establishing the active supervisor.

b) Arbritrate contention among candidate supervisors within a time appropriate to the application.

HOTE - In a typical application the access tice of a candidate supervisor should be less than 1 s.

c) Ensure continuity of data highway operation when the active supervisor fails.

6.7 Network unit and protocol

The natwork unit i&iy provide data highway interface services to the application units in any station. The purpose of tha network units of stations that contain director functions is to direct the oparation of a data network consisting of multiple data highways. Data highway interface services provided by network units cay be responsible for the following:

a) Converting originator and destination logical identifications into station addresses.

b) Arbitrating between the data highway's maximum allowed frame size and the TTiCesage size required by the application un\ts. Examples are rejecting or buffering cessagee which exceed the maximum frus© size.

c) Maintaining the same sequence of massages at the originator and destination.

d) Performing source to sink error checks on messages which the nser declares are critical, for example a check before operate mechanic-, for control actions, and a verification that specified actions have take;, place. - 94 -

6.7.2 Director functions

A station that containe a director function will monitor performance of, and maintain statistics on, the entire process data network. The director functions shall perform the following tasks:

a) Assign management of the data highway by establishing its active manager.

b) Arbitrate contention between candidate managers of a data highway within a time appropriate to the application.

c) Ensure continuity of data highway operation when active manager fails.

d) Select alternate data highways between devices as appropriate.

e) Perform route selection and store and forward transmission between devices as appropriate.

6.8 Application protocols

The application protocols cefine the rules w.ich ensure c.onsistant interpretation of the application dependent information contained in network (cr highway) frarac:s. Examples of application dependent information are as follows:

Subaddrecsp.G within the device. Device control and status signals. Data forMats. Character codes.

7. SAFETY

^* * Fault potential

All devices used in the data highway shall be capable 6'f withstanding the application oi: an allowable fault potential appropriate to the application. Application of this potential to the device's connection to the transmission line shall not damage the devd.ee or cause it to become hazardous to personnel or other devices.

NOTE - This fault potential is typically the power mains voltage in the areo traversed by the transmission l.ine(s). l/hen the allowable fault potential is that generated by' a lightning strike Co an arbitrary point near the trantn.iission l.fne(s), all devices used in the data highway shall be capoble of withstanding the application of such a fault potential.

KOTE - For example: A pulse of 2.5 kv peak with a 1 us rise time and 50 us decay time. Test procedures are defined in IEC Publication 255-4. - 95 -

7.2 Optional version?

When intrinsic safety certification Is demanded the design of the data highway shall ba capable of modification to neet ths requirements.

8. DATA TRANSFER INTEGRITY

8*1 USG in electrically noisy environments '

The data highway shall be capable of maintaining correct frame sequencing and integrity of transmitted data while it is operating in an electrically noisy environment.

8.2 Error1'' detection algorithms

The data highway shall include error detection algorithms that check the complete coupler frame.

8.3 Residual error rati

The data highway shall achieve a residual error rate and information transfer rate appropriate tc the application when expo sad to a typic.il induct rial environment. The relationship bctwaen resideal error rate, information transfer rate and data circuit signal to noise ratio Ray be expressed by graphs or tables.

8.4 Undetected fraiaa errors

The rate of undetected frame errors should be less than one 1 error p°r 1000 years of data highway operation, provided that the data circuit bit error rate iG less than 10-6 and tha frame .length is less than 100 bits. This corresponds to a residual error rate of 3 >; 10-15 assuming 100 % utilization of a data signalling rate of 1,000,000 bits par second.

8.5 -Low bit error rate

The data circuit chall achieve an acceptably low bit error rate in the presence of a common mode potential appropriate to the application.

NOTE 1 - When the data circuit's trancnicnion line is entirely contained in a protected are?-,, this common lsode potential is typically less than 10 V peak-to-peak at frequencies less than 400 Hz.

NOTE 2 - When the transmission line is exposed to the plant environment, this conation mode potential is typically less than 50 V peak-to-paak at frequencies less than 400 Hz. - 96 -

9. SYSTEM AVAILABILITY

9.1 Restrictions on failures

No single failure of any part of any device used within or connected to the data highway shall cause failure of the entire process control system, or of any function except; those in \frich the failed device is directly involved.

9• 2 Tolerance to changes-of conf i;;uration

The process control system shall be capable of tolerating changes of configuration, without .loss of coEmunicati'on function, failure of any one transmission line, or failure of any one station.

9.3 Redundancy

The data highly shsl-\ provide sufficient redundancy in a proceus control system with centra.lir.ru, distributed and/or hierarchiai intelligence to achieve high control system availability.

9. A In tern J.I status anc! error reporting

The data highway shall h-svc: an internal status and error reporting capability.

9.5 Automatic recovery

The data highway shall b2 capable of automatic recovery from common failures.

^'^ Control of rt-tion"

The data hiphvay shell ensure that loading, starting, stopping, reloading, and resetting any svration i:3 properly carried out.

10. PSRF&2!-iA,VOT CRI1S1MA

10.1 Conr-unicat ion efficiency

The highway and path prolocclr, shall nvake efficient use of the data signalling rate.ar.d of ths transmission linrj b.indv;idth.

10.2 Resrcr.frg ti;?s

Th'?. data hif.hwr.y should be. cfti'fble of enabling any station, to obtain or provide data within tisis linits imposed by tlie type of massage 6SA tSccr*t*rl«t)

CUXMWT SCOPE or PKCWVY TERMS.' SC6SVW56 ISO nrrs (niCTIOKAW, Pt •» II LA TED srroRTS STA.M9ARJS

APPLICATIOH PROTOCOLS - BATA IW7EPFKETATI0JI

I

PROTOCOL

TC 66 pirssiCAjt, lr : PATH I ADDRESS pyrc--?':zE| I UNIT 1 I E*.'«S COS I PROTOCOL I I-TOTC-COL J SEIMM,]^ j CC1TT I ISO CCITT ifir PKTSICAL If X.27 PHVSICAl If

&OGICAX, ITsT PHY.MCAi IF

SPEC rcR s vrpt TWUISK1SSI0N LINE ELECTRICAL CABLE

F1C3.T-E 1 - Simplified - 98 -

APPLICATION rimCTIUriS USING J\PI*LH UN'LH APPLICATION rnrrxxoLS UKIT 1 tUH;T 7

| Arpl.KATIG!

destination Identification.

- ULIOWED JK Ui 5T..T1CWE

1 OIKCCmt contention u

•vltcti HLr

niciivsir WIT t rre>i*>=oL

rUMCTiOfiS Oi' Mi, 1VANKS

tKtcndtbl? aidr«cc *.i>(! control sttuctur* notify higher rt^-k ol citori

*sm£^n control o' ni^Uu^y by matfijliahln? tt/S *rbitr*t« contention ^nong C/S, C/i *cc««* < 3

oontiol Klv'^^y otilir.ivion ty *.»t*bil»:.lrig /s'l *rbitrct.« ccrtlcntion iwny A/D *cc«a» X 2 Transit £at» wiih hloJi integrity C/I *tcc»i < JO KS ( * 1 exjrtr pmr )W^ yra) tiror cinclte 4 xacovaxy po3c«dt:r«i licit trwiractJon cin-ac t Notify hlfhj>r unit of dptl viLh ftllure cf A/I UtrOL.-ovdi.islo 41IDC3 Camuhicat*: arbitrary <]*t«, (act!v^tit/^cjictivdtfi lower rtnVt) (ijiitUIif* C ft rodac Li ctittr «t*lJon*> Tro*•parent to Jin? length (dttcrrilne atvttua & tooiJ* of otltec 11*( Jonc) _-rd to A/5 poll wltli )iti« *rccx« riiqj^H Support nonltorlrt? I IH1TU.TOP.

r>g fr.r-c* 1 of X .t>jte. I accept corioct fii.cv:o with fet&Ljon ad^rvat (optional function) •• n A " /.CtlVR C - Candid* t* acctprxc corivc: t tr+.Mc

V COUVLEK LnttrUc* ft fit»*i path fr*M * »r*or coda *

V I liti interface ft (CJ-MI coupler (rsv« * •ynct.ttmltwt* X TkANS»U»&10K LILT 1AHT Of STATlOKt

MCUAE_a - AllocALlon of ccwMinJcatlnn funrUont Mltliin 7*«?ar«rtro [vACi.loi.fcJ i».)tilj«j«i*).Lt - t«ctioo n«vo

65Ak(Socretariat)l8 - 99 -

STATION 1 STATION 7 STATlUN H

Al'H.ICATIOH AWt.lfATIOH I AT ft I CAT It Hi j APPLICATION I Al i Ll< AT |O!l AIM'LH'AYIUX WIT ;*• FAjlUL-OL ' OMIT

IMPLICATION COUPLER APPLICATION COUPLER lCATtOU COUPLtA _J HETWOftJt, UNIT HtTWUKK UH1T

KICtfXAY. UNIT HIUMWAY UKIT

i

LIKE COIVLER LIME COb'PIXR J7OCT.1, *'i

TKAHSHISStCiisstc:: I LIKLIKIE

STATION 1 STATIOH 2 STATION H

APPLICATION WIT UK:T

»n.,c«,«w«.:,

UltiT

DATA ICGHiW PROi'AY o o

7\\0S:<, HIGHWAY AND PATH UNIT

FIGURE 4 - Exairpie of an ir;-.pieir.oata*;xcr. of a ?SC entrai Off ici of rhe -ISC 1, :--.e de Varczbé EL2C/ea 1.3.79 £5A(Secr3tarie.t)lS - 101 -

A WESTINGHOUSE DESIGNED DISTRIBUTED MICROPROCESSOR BASED PROTECTION AND CONTROL SYSTEM

J. BRUNO J. B. REID

Westinghouse Electric Corporation Nuclear Energy Systems P.O. Box 355 Pittsburgh, Pennsylvania 15230 - 102 -

INTRODUCTION For approximately the last five years, Westinghouse has been involved in the design and licensing of a distributed microprocessor based system for the protection and control of a pressurized water reactor nuclear steam supply system. A "top-down" design methodology was used, in which the system global perforrrince objectives were first specified, followed by increasingly more detailed design specifications which utlimately decomposed the system into its basic hardware and software elements. The design process and design decisions were influenced by the recognition that the final product would have to be verified to ensure its capability to perform the safety-related functions of a class IE protection system.

FIELD FIELD SENSORS* SENSORS

INTEGRATED INTEGRATED PROTECTION CONTROL CABINETS PLANT CABINETS COMPUTER SYSTEM

•+• DISPLAYS INTEGRATED INTEGRATED CONTROL LOGIC CONTROL SWITCHES CABINETS LOGIC CABINETS

MAIN CONTROL BOARD ACTUATED ACTUATED DEVICES DEVICES

SAFETY NON-SAFETY RELATED RELATED

* SOME SENSOR SIGNALS SHARED BETWEEN CONTROL AND PROTECTION

Figure 1 Plant Integrated Control Center 4411A - 103 -

The verification process mirrored the design process except that it was "bottom-up" and thus started with the basic elements and worked upwards through the system in increasingly complex blocks. It is our intention in this paper to concentrate on a number of areas which are of interest in a distributed system. Some are unique to distributed systems, while others are considerations in any control and protection system. Two systems will be discussed. The first, the Integrated Protection System (IPS) is primarily responsible for processing signals from field mounted sensors to provide for reactor trips (scrams) and the initiation of the Engineered Safety Features (ESF). The Integrated Control System (ICS) which is organized in a parallel manner, processes other sensor signals and generates the necessary analog and on-off signals to maintain the plant parameters within specified limits. Since the IPS in general represents a more limiting case, the majority of the points discussed will make reference to the IPS, however, in most cases the same factors are a consideration for the ICS.

CHANNEL SET I CHANNEL SET CHANNEL SET I

SENSOR SfNSOl SENSOR INPUTS INPUTS INTEGRATED '"'"", MTECM.iD 111 PROTECTION H " ' 1 CABINET irl 1 PROTECTION INTEGRATED INTEGRATED ' CABINET A-.O PROTECTION PROTECTION CABINET CA6INET

CALC CAIC

S S VOTING o VOTING o LOGIC tOGIC r:.) - PAM L - PAM -»*• P AM • CONT CONT -fc- CONT IJT

MM nil LEGEND A-*O ANALOG TO DIGITAL CONVERSION SYSTEM CALC CALCULA noNS INTERPOSING INTERPOSING ISOL ISOL AT ING DEVICE PAM POST ACC IDf NT MONITORING SYSTEM INTEGRATED LOGIC CONT INTEGRA rEO CONTROL SYSTEM LOGIC ILC INTEGRA CARINCT ED LOGIC CARINE1 ESF ENGlNEEl ED SAFETY FEATURES nT REATOH TFIP MC« MAIN CONTROL MlAflD

\ \ \

ACTUATIONS

Hgure 2 Integrated Protection System Basic Architecture

4411A - 104 -

SYSTEM STRUCTURE Figure 1 shows the overall structure of the IPS and ICS in relation to each other and to the control room. This collection of equipment is called the Plant Integrated Control Center (PICC). The IPS is composed of two major sub-blocks, the Integrated Protection Cabinets (IPC) and the Integrated Logic Cabinets (ILC). Similarly the ICS is composed of the Integrated Control Cabinets (ICC) and the Integrated Control Logic Cabinets (ICLC).

Finer details of the IPS are shown in Figure 2 in which the four way separation among the four IPC's and the two way separation between the two sets of ILC's is evident. Each IPC processes one of four redundant process signals to generate a channel trip. The channel trip in each IPC is combined with channel trip statuses from similar channels in the other three IPC's in a two-out-of-four (2/4) voting matrix within each IPC. The result of this vote provides outputs to the reactor trip breakers or to the system level ESF actuation circuits in the ILC's.

SENSOR INPUTS TUT

AUTOMATIC SIGNAL CONDITIONING TESTER A D CONVERSION

ANALOG DIGITAL PROCESSING PROCESSING

ANALOG DIGITAL COMPARATORS COMPARATORS

1 DATA IPC TRIP LOGIC S LINK DATA MODULE 0 RECEIVER LINK TRANS. L A T POWER ESF 1 118V AC SUPPLIES LOGIC O N START AUTO TEST r/:isc. COMMUNICATIONS MODULE MC8 BLOCKS ' INTERFACES MAN R.T •

LEGEND: ESF ENGINEERED SAFETY FEATURE MC8. MAIN CONTROL BOARD R.T. REACTOR TRIP PAMS PORT ACCIDENT MONITORING SYSTEM ILC INTEGRATED LOGIC CABINET IPC INTEGRATED PROTECTION CABINET

Figure 3 Functional Groupings Within the Integrated Protection Cabinet

4411A - 105 -

Channel trip information is communicated among the IPC's and ILC's by serial data links running at 19.2 kilobaud. Where isolation is required to avoid interaction between redundant circuits, the transmission medium is a fiber optic cable, otherwise, a twisted shielded copper pair is used. The internal details of an IPC are identified in Figure 3, which shows the major functional blocks. Note, in particular, that both analog and digital signal processing is used. A resident tester is provided which, automatically (on command), checks the system from the input A/D converters to the outputs of the IPC.

SENSORS

1 00 Ui SIGNAL COND. IPC AUTO AUTO TEST TEST MODULE Q. INTERFACE o o o ill LSLSLLI DNB/KW/FT ANALOG COMM. MODULE FUNCTIONAL MODULE CARDS i

-} FROM IPCHJO.JSL TRIP LOGIC MODULE TOIPCH.IE1E

FROM ILC TORT LEGEND: BREAKERS SM - SHARED MEMORY 1 - ISOLATED OUTPUT

Figure 4 Integrated Protection Cabinet Block Diagram

4411A - 106 -

In Figure 4, the organization of the IPS is shown in a way that more clearly displays its distributed nature. The signal processing blocks are shown feeding into either the trip logic computer or to the ILC via data links from the ESF module. The communications module collects information from the other modules through shared memories and formats it for transmission to the control system, computer system and control board. Each module, except the analog module is organized around a microcomputer with appropriate I/O. Each microcomputer runs asynchronously with respect to the others. The ILC, as shown in Figure 5, consists of the three cabinets per train which include a microcomputer based system level logic and multiplexing systems, and a hard-wired interposing logic for individual actuated devices. Critical portions are made internally redundant to mitigate the effects of an internal failure on to plant availability. Power interface devices, typically solid state switches, convert from low level signals to signals capable of operating contactors and switchgear.

PROM IPCs

in IV TO IPC I I I

DATA LINK DATA LINK TRANSMITTER RECEIVERS

MCB SYSTEM AUTOMATIC SYSTEM LEVEL TESTER LEVEL LOGIC LOGIC 3-

INTERPOSING INTERPOSING MCB MC8 c LOGIC LOGIC 3 INTkRPOSING LOGIC (NON-REDUNDANT)

POWER POWER INTERFACE INTERFACE

' POWER INTERFACE INON REDUNDANT) ittti.tUA.tti SWITCH- MOTOR AIR GEAR CONTROL OPERATED CENTERS VALVES LEGEND: MCB. MAIN CONTROL BOARD IPC INTEGRATED PROTECTION CABINET

Figure 5 Functional Groupings Within the Integrated Logic Cabinet 4411A - 107 -

SYSTEMS PARTITIONING STRATEGIES Initial design constraints established that the IPS design would contain four redundant sets of microprocessor based equipment for the IPC and two redundant sets for the ILC. Immediately, however, the second design question of how to handle the various functions required in the IPC was raised. A hardware designer strives to make each printed circuit card in the system as efficient as possible. The software designer strives to reduce the number of processors by operating each one near its limit. The thrust of this effort was to configure a series system. All incoming signals would be digitized and processed by one microprocessor which would provide all appropriate signal scaling, range checking, limit setting, and so forth. The results from this operation were then passed on to a second microprocessor which would perform all arithmetic operations, and so on. In such a system, a failure of any microprocessor caused the entire channel set to fail. Upon reassessment a design with greater fault tolerance was adopted. The approach partitioned the total system into three function groupings as shown in Figure 6. Each of these functional groups were supported by a sensor and signal conditioning subsystem. This subsystem provided individual A/D converters for each incoming analog signal and processes each incoming contact closure in a parallel, hardwired configuration. This minimized the possibility that a single failure in this subsystem would cause the entire channel set to lose its incoming signals.

In some eases, as in the trip logic module, multi-microprocessors are used to further reduce the reliance of large portions of the system on one processor. This distributed system was designed to function in an asynchronous mode and furthermore, is designed to avoid the use of interrupts. Since each microprocessor is operating asynchronously and a single failure of one processor must not affect any other, the processors must have access to the same information but yet be functionally isolated. This was achieved by using two-ported memory arrays which allow two different processors to reach into the memory location to read or write, but prevent one processor from reaching the other through the memory location. This isolation capability of the two-ported memory allows one processor to continue operating while an adjacent one is inoperable. Common Mode Failures (CMF) cannot be dealt with by redundancy alone since all like elements are presumed to fail. Instead, they can be addressed by a combination of intensive testing of the smallest system building blocks to minimize the effects of a CMF and by providing functional diversity. The system can be thought of as providing three echelons or levels of defense> as shown in Figure 6. The first echelon is the Control subsystem, which keeps the plant operating within its normal limits. This is backed up by the Reactor Trip subsystem, which shuts down the reactor if the plant operation goes outside acceptable limits with the Engineered Safety Features (ESF) providing the ultimate backup. The partitioning of the IPS supports these three echelons of defense. The Communications module (Figure 4) plus the ICS represent the Control Subsystem echelon. The remainder of the IPC with the exception of the ESF module represent the Reactor Trip Subsystem echelon. The ESF module plus the ILC's provide the ESF subsystem echelon.

4411A - 108 -

CONTROL

(1) (2)

ENGINEERED SAFETY REACTOR TRIP FEATURES

Figure 6 Interconnecting Paths Among the Three Echelons of Defense

While parts of all three echelons are located in the IPC, they are physically self contained with the functions being performed by separt.+e hardware for each echelon. Interfaces between the echelons are designed to minimize the likelihood of failures propagating between the various echelons. This form of partitioning is supportive of the requirements of NUREG 0493 (Reference 12). COMMUNICATIONS TECHNIQUES

The design of the IPS and the ICS had imposed on it one severe design constraint. Regardless of the nature of the new system and the communications medium or method used between its various parts, it must also communicate with existing plant instrumentation and actuating devices. Thus, a large number of parallel wired inputs and outputs were to he handled by this new system.

4411A - 109 -

The initial evaluation indicated that to provide enough space in the IPC's and ILC to interface with these plant components would double or triple the size of the enclosures required for the microprocessor hardware itself. Initially, multiplexing was evaluated to replace the large quantity of parallel inputs. However, two major concerns became apparent. Multiplexing only part of the plant signals did not appear economically or techically justifiable. Most actuating devices are supplied by the customer/AE making coordination of the design effort very difficult. Several key factors evolved from the evaluation which were factored into the design. Congestion in the cable spreading rooms could be reduced substantially by collecting the sensor and actuator signals together and routing multiconductor cables into the IPC's and ILC's. The large quantity of signals routed between the various protection system cabinets and between these cabinets and non-protection equipment could be multiplexed. Fiber optics was a viable communications medium. Once the evaluation was complete, certain design decisions were made. These decisions resulted in a number of different external communications methods being used for the data links shown in Figure 1. Hardwired inputs have been collected into field termination cabinets located throughout the plant and cabled into the appropriate cabinet using multi conductor cables. Even if the quantity of field termination cabinets varies, the impact on the cable spreading area, near the control room complex, is minimized. In fact, it will be possible to make some design changes without affecting the plant wiring. External multiplexing has been employed extensively in the IPS design. Multiplexing is employed in the following areas. between each IPC and the other three redundant IPC's between each IPC and each ILC between each IPC and the plant computer/display system between each ILC and the main control board These areas were chosen because they could further reduce cable spreading area volume, simplify separation requirements, and reduce the quantity of isolators required. The data links identified in the first three categories above require isolation. Fiber optic cables became a logical ehoise for this application because of its inherent immunity to electrical interference and its ability to prevent the propogation of an electrical fault back into the protection system. Physical isolation was achieved by using the fiber optic cable as the Interconnecting medium between cabinets. This placed the data link transmitter and receiver in different, physically separate cabinets. 4411A - 110 -

Multiplexing in a nuclear power plant protection system posed some new concerns which were addressed in the design. Loss of a single data link was considered a credible failure, but this could not be allowed to make the system inoperative. Redundant data links are employed to eliminate this probability. Furthermore, the protocol for these data links include error detection codes which allow the receiver to determine that it is receiving good data. These communication techniques have provided a large reduction in the cabling congestion in and around the cable spreading area of the control room complex. In addition to the external data links, several memory buses are employed for internal communications between the distributed microprocessors. SOFTWARE DESIGN CONCEPTS It was recognized at the outset that the design of a distributed processing protection system would pose special problems with respect to the need to design and verify the software. A study was commissioned with personnel from the Westinghouse Research Division (Ref. 1) playing a key role to identify and specify concepts and procedures to ensure that the software for the IPS would be designed and documented in a manner which would lend itself to the level of verification appropriate to a safety related system. The design rules developed were aimed at three areas of concern: 1) a proper documentation and review process, 2) development of code that is relatively easy to verify and 3) constraints on the interconnections among the microcomputers in the system to minimize and simplify interaction. Documentation was addressed from two aspects. Specific rules were identified regarding the scope and contents of each document. This ensured that the steps in the design process were capable of being reviewed and followed by independent observers. Procedures were then implemented which identified specific points in the process where independent reviews of the documentation would take place. A key document in the process is called the Software Performance Specification (SPS). The SPS is written by the programmer prior to coding and serves to document his understanding of the system requirements to be implemented by the code. The SPS is reviewed and approved by the group which originated the system requirements thus providing a check to determine that the requirements have been correctly interpreted by the programmer. The software rules are those 'associated with the concept of structured programming. Their intent is to improve the readability and reliability of the program and are typified by: "Avoidance of GO TO statements" and "single entry/single exit for sub-routines". An addition to the so called style guidelines, a high level programming language (WEMAP) was developed for microcomputer applications (Ref. 2). This language supports structured programming and to a large extent enforces the structured programming rules, for example no GO TO statement is provided. Interconnectors among microprocessors in a distributed system can have a major impact on the overall quality of the system performance. This is especially evident where the interconnections must be interfaced through software. The architecture

4411A - Ill -

of the IPS was designed with this eonside* ition in mind. As a result, efforts were made to minimize the number of interfaces between microcomputers and to keep the remaining ones as simple as possible. As can be seen from Figure 4, the most important interfaces, those between each functional microcomputer and the Trip Logic Computer (TLC), occur through parallel contact closures. While this approach is not very elegant, it produces an interface which is simple, easily controlled and tested, and which provides a high degree of fault isolation. None of the software executes on an interrupt basis. Each microcomputer is operated in a continuously looping program whose execution rate is compatible with the system time response. Inputs and outputs are sampled once each cycle. This simplifies the code by avoiding the necessity for providing the interrupt support software and avoids a whole class of verification problems associated with determining that the program returns to the correct point after servicing an interrupt. The other interface of interest, shown on Figure 4, is the shared memory. A shared memory is a two port memory card that operates under a very rigid protocol which allows two microprocessors to access memory on the card without communicating directly with one another. The shared memory thus acts as a "software isolator" by rigidly limiting the degree of permissible interaction between the two microcomputers. As such, the influence of the failure of one microcomputer will be limited to the inability to place data into or retrieve data from the shared memory and not in any other way affect the operation of the other microcomputer. RELIABILITY AND MAINTAINABILITY The architecture of the IPS reflects concerns related to the attainment of reasonable reliability and maintenance goals. The reliability goal selected was per demand for reactor trip and was chosen to be equal to the calculated reliability of the system it replaces. The maintainability goal was based on experience with systems of a similar size and was specified to be less than two card failures per month. These goals are, in themselves, contradictory since the redundancy needed to meet the reliability goal works against the need to minimize the quantity of hardware which favorably impacts maintainability. The architecture of the IPS was evaluated during its design phases and significant changes were made in response to unfavorable predictions. The architecture pictured in Figure 4 was originally conceived with a number of bases communicating partial trip information across the various functional modules under the control of microcomputer based data handlers. Shared memories allowed for the transfer of data while keeping the microcomputers operating independently and asynchronously. Each functional module performed its own two our of four (2/4) voting logic. The need for reliability mandated a minimum of four buses, three to distribute partial trip information from the other channel sets and one to collect information for transmission to the other three channel sets. When the design was evaluated for maintainability, it was determined that the quantity of "overhead" cards required to support the communications function was so large. This placed an unrealistic mean time between failures (MTBF) on the cards needed to meet the maintainability goals. The final design, shown in Figure 4, dealt with this problem by restructuring the blocks so that the voting logic is localized to only one module, the Trip Logic Computer (TLC). The other functional modules input to the TLC by simple contact

4411A - 112 -

closures to provide one of the voted inputs. The TLC serves as the terminal of data links between one IPC and the other three. Such an arrangement significantly reduces the quantity of cards required in the system and brought the maintainability goal within the realm of possibiility. It can be seen from Figure 4, however, that solving one problem raised another. All trip signals now pass through one module thus making its proper operation critical to the attainment of the reliability goals. The solution to this problem was to design the TLC around two microcomputers operating in a quasi-redundant manner and with each checking on the proper operation of the other. One microcomputeris setup to receive the partial trip inputs from the channels in its host cabinet and those inputs with one out of three of the equivalent channel trips from the other three cabinets to effect a reactor trip signal. The second microcomputer examines the partial trip statuses of only the three incoming channels in the other cabinets and performs a two out of three vote to generate a reactor trip signal. The combination of the logic performed by both microprocessors can be shown to be equivalent to classical 2/4 logic, however, due to the partitioning of the functions a failure of either microcomputer will only disable part of the TLC. This approach, plus the cross checking and immediate reporting of a failed input permitted the achievement of the reliability goal. To further enhance reliability and to minimize plant upsets and their effect on availability, due to loss of power, each cabinet is designed to accept two sources of AC power which energize redundant DC power supplies. The DC power from each supply is distributed to each card through on-card auctioneering diodes. If the AC power sources are selected to be independent of each other in response to reasonable failure modes, the cabinet is ensured a continuing source of power. It should be noted that both sources of AC power must be derived utlimately from the same source of Class IE power to preserve the required separation. COMMERCIAL COMPONENT AVAILABILITY One of the basic ground rules during the design of the IPS and ICS was to utilize commercially available components. It was further determined that, wherever possible, the standard utility/process line of circuit boards would be used. This strategy was based on two premises. One, the use of "popular" commercial components permits the selection of devices which are "second sourced" thus minimizing the risks associated with being tied to one supplier. In addition, the use of components that are widely used provides a more reliability data base and enhances the likelihood that they will be available over a long period of time. Secondly, by using printed circuit cards that are shared by other product lines, one gains the advantages of borad production base. These include economies of scale, an increased familiarity of design, manufacturing and test personnel with the characteristics of the equipment and the ability to have the equipment checked out in non-nuclear applications. Only in cases where there is no fossil utility or process application have circuit cards been designed specifically for the nuclear systems. These are primarily in the area of special cards used to interface with nuclear instrumentation detectors.

4411A - 113 -

The microprocessor selected is an example of the selection of popular components. After evaluating many models, the 8080A type was selected. It is second-sourced by a number of vendors. Because of its wide usage, a complete set of support chips was available. The processor and its support chips are expected to be available for many years. Even the most widely used components can be expected to become obsolete or prohibitively expensive over the years. The use of a carded approach allows flexibility to deal with this problem since it permits the selected redesign of certain cards in the system in response to the unavailability of particular parts and also to make selective localized improvements within the usual constraints of form, fit and function. There are inevitable tradeoffs to be made concerning the use of commercially available components and their incorporation into a carded system. Typically, vendor quality control for commercial products is less stringent than for military products. This must be countered by a strengthened program within the system manufacturer's operation for vendor qualification and incoming inspection. There are some times when a circuit board of a universal type contains unused functions. These functions may contribute to the unreliability of the card yet offer nothing directly in return. The consideration here is the increased likelihood of spare parts availability and the benefits of having a large history of usage which reduces the likelihood of undetected design flaws. EMI AND RFI SUSCEPT ABILITY In earlier designs, the major concern in this area was electromagnetic interference (EMI) from electrical wiring and equipment permanently installed in the plant. However, with the increased use of radio communications on plant sites and telemetry for offsite communications, the concern has been broadened to include Radio Frequency Interference (RFI) as well. The latter is much more difficult to design against because of the portable transmitters used. For example the transmitters could be used: adjacent to equipment cabinets with all doors open, adjacent to equipment cabinets with some doors open. near congested areas of low level signals affecting several circuits simultaneously. near individual transducers both inside the plant and at remote locations on the site. near display devices affecting -«ly the readouts, near computer and data processing equipment. It was apparent early in the design that immunity to both EMI and RFI must be an established goal. However, no good standards or criteria exist for the installation and operation of installed equipment, that would assure a consistent design approach.

4411A - 114 -

For example, how close to solid state electronic cabinets or its signal wiring may a 480 VAC bus operation several 600 hp motors be routed? Is it permissible for plant personnel to operate a walkie-talkie inside the electronic equipment room? The control room? In the IPS and ICS certain specific efforts were made to design for EMI and RFI conditions. The total quantity of wires entering the cabinets was reduced by using multiconductor cables and multiplexing where appropriate. Fiber optics were also used in selected applications further reducing the susceptability to these noise sources. All low level signal cabling has been shielded and care has been exercised to assure a consistent logical grounding approach to avoid ground loops and other common grounding problems. Coupling fiber optics to electronics is an area of severe sensitivity to RFI. In the initial design of the equipment for this application, it was determined that if a certain walkie-talkie were within six inches of the card edge that the data link communication was disturbed. The circuitry and packaging of the optic receiver was redesigned to eliminate the problem. The IPS prototype will be subjected to several tests to confirm that EMI and RFI susceptability has been reduced to an acceptably small level. However, until industry wide standards have been developed and accepted by all parties, manufacturers, utilities, licensing agencies, and constructors the question of how small is small will remain. LICENSING ISSUES In the development of any new class IE product, licensing issues are bound to arise. This is to be expected since any departure from the previously accepted way of accomplishing a safety related function must be closely scrutinized by the regulators to ensure that the new design meets the appropriate criteria. In the case of the IPS, many things are being done differently from previous designs and in recognition of this, a series of information meetings were held with members of the U.S. Nuclear Regulatory Commission (NRC) to review the new areas of provide necessary background information and design criteria. In most cases, the design differences were easily reconcilable within the framework of existing regulatory criteria. Several areas did develop, however, which strained the interpretation of the criteria or were not adequately covered by existing criteria. Those latter areas required considerable mutual effort between Westinghouse and the NRC to obtain resolution. These issues were verification and validation (V<5cV) of software and common mode failures.

The V&V of software was of particular concern to the NRC. The use of software based protection equipment had very little precedent and the criteria by which the adequacy of a V&V program could be judged were in a formative stage. The NRC utilized the experience of the aerospace and avionics industry to form the basis for the development of criteria for the evlaluation of software V&V programs. These criteria were applied to the IPS software V&V program developed by Westinghouse (Ref. 1) and it was established that the IPS program was substantially in agreement with the criteria. Minor differences were subsequently resolved to the satisfaction of all.

4411A - 115 -

Common mode failures (CMF) are particularly difficult to deal with in a methodical manner since the identification and treatment of a particular CMF mechanism merely removes one CMF from consideration and an unknown quantity of them still remain. Fortunately, sound engineering judgement and prudent design principles go a long way towards producing a system in which the residual threat of CMF can be considered to be acceptably low. The difficulty of showing that this is so lies in the lack of a systematic methodology by which the design can be evaluated and conclusions drawn. This problem was addressed during the licensing phase of the IPS in a joint NRC/Westinghouse effort. The outcome of this activity was a document NUREG-0493, in which guidelines for the systematic evaluation of a design for its susceptability to CMF's are provided (Section 3). NUREG-0493 also states that the architecture of the IPS "is not in conflict with the guidelines" and on that basis, a recommendation for a preliminary design approval was given. Certain additional work was specified to be done prior to the final design approval. This work is primarily analysis and testing to demonstrate that the IPS conforms to the guidelines of Section 3 and is currently under way. APPLICABILITY The IPS system, a digital microprocessor system, has inherent design features not available in todays protection systems. These additional features, such as two level 2/4 voting logic and real time calculations of DNB and KW/ft., provide a much more powerful system. The system has the capability, if installed in operating plants, to make available additional operating margin. To fully achieve this, however, means of modifying or replacing many existing plant components such as reactor trip switchgear, quantity of protection system sensors, ESF actuation devices, and most of the main control room complex must be available. Such a total package is the plant integrated control center (PICC). Most operating plants do not have the space for such a major redesign effort and even if they did, could not justify the plant downtime or the cost of such a major change. The technology developed and proven for the IPS, however, does have many potential applications in both the NSSS and BOP areas. The following is a list of such applications. Core Limit Calculation Provide directions continuous indication of flux distribution and core limits on a CRT display Multiplexing Provide proven multiplexing hardware/software, and where required fiber optics, for plantwide communications. Stand-Alone Systems Provide basic building blocks for plant upgrades and additional imposed requirements (such as TMI). The basic system, as shown in Figure 2, is a four train reactor trip systm with a two train ESF actuation system. This design is expandable by simply adding a third ILC to a three train ESF actuation system and likewise to a four train system.

4411A - 116 -

The concepts and the resulting design configuration, though applied to the NSSS initially, are equally applicable to the balance of plant systems and to other non-nuclear plant applications where a high degree of reliability and availability are necessary with commercially available equipment.

4411A - 117 -

REFERENCES 1. D. M. Edison, E. Sternheim: "Software Design and Verification for Nuclear Protection Systems," IAEA/NPPCI Conference on Software Reliability for Computerized Control and Safety Systems Nuclear Power Plants; Pittsburgh, Pa., July, 1977.

2. A. J. Gibbons, D. F. Furgenson: "High Level Software Generation for Reliability;" ibid 3. J. M. Gallagher, Jr., G. M. Lilly, "System Architecture for Microprocessor Based Protection System," IAEA/NPPCI Specialists' Meeting on the Use of Computers for Protection System and Automatic control, Nuremberg, Germany, May, 1976. 4. J. M. Gallagher, Jr., E. J. Madera, J. B. Reid, "Design of Internal Architecture for Westinghouse Microprocessor Based Protection System," IEA International Symposium on Nuclear Power Plant Control and Instrumentation, Cannes, France, April, 1978. 5. J. M. Gallagher, Jr., G. Lecocq, C Plennevaux, "Microprocessor Based Integrated Protection System," International Meeting on Nuclear Power Reactor Safety, Brussels, Belgium, October, 1978.

6. E. J. Madera, D. M. Rao, G. W. Remley, "A Microprocessor Based Integrated Protection System for Nuclear Power Plants," ISA Power Symposium, ATlanta, Georgia, May 1979. 7. J. Sutherland, "Distributed Control Systems' part of the Solution or Part of the Problem?", ISA National Conference, October, 1977. 8. J. A. Donnelly, B. N. Lenderking, J. A. Neuner, J. F. Sutherland, "Secure Data Transmission in Nuclear Power Plants by Serial and Optical Techniques," IAEA/NPPCI Specialists' Meeting on Design of Electronic Equipment to Achieve Electromagnetic Compatability, Winfrith, Dorset, U.K., February, 1978.

9« B. M. Cook, "Use of Fault Tree Analysis in the Design of the Westinghouse Microprocessor Based Reactor Trip Logic System," American Nuclear Society Topical Meeting, Probabilistic Analysis of Nuclear Reactor Safety, Los Angeles, California, May 1978.' 10. J. Bruno, B. M. Cook, D. N. Katz, J. B. Reid, "Microprocessor in Nuclear Power Plant Protection System," IEEE PES Meeting, New York, N;Y., February, 1980.

11. J. Bruno, J. B. Reid, "Fiber Optics: Use in Nuclear Power Plant Control and Protection Systems," IEEE PES Meeting, New York, N.Y., February, 1980. 12. Nuclear Regulatory Commission (NRC), "A Defense-in-Depth and Diversity Assessment of the RESAR-414 Integrated Protection System," March, 1979.

4411A - 118 -

BIBOGRAPHY John Bruno was born in Johnstown, PA, on August 4, 1940. He received the BS and MS degrees in electrical engineering from the University of Pittsburgh in 1967 and 1968, respectively.

In 1968 he joined Westinghouse Electric Corp., in Pittsburgh, PA, as a control system designer for nuclear power plant control and protection systems. He is currently a senior engineer responsible for various aspects of the integrated protection system design- He is a registered Professional Engineer in Pennsylvania. J. Brian Reid was born in Hamilton, Ontario, on September 20, 1940. He received the B. A. Sc. degree from the University of Waterloo, Waterloo, Ontaria, in 1965, in Engineering Physics.

In 1965, he joined Westinghouse Canada and in 1968, transferred to Westinghouse Electric Corp. in Pittsburgh, Pa. He is presently the Manager of a group responsible for the specification and system design aspects of nuclear power plant protection and control systems.

Mr. Reid is a member of the Instrument Society of America.

4411A - 119 -

DATA MANAGEMENT PROBLEMS WITH A DISTRIBUTED COMPUTER NETWORK ON NUCLEAR POWER STATIONS

BY I DAVIS, C.E.G.B., SOUTH WESTERN REGION, BRISTOL, ENGLAND

1. Introduction In the South Western Region of the Central Electricity Generating Board, there are 4 nuclear power stations, all providing base load generation of about 2400MW. The latest of these to be commissioned was Hinkley Point 'B' Power Station, which has 2 AGR reactors and 2 x 660 MW generating units. Along with many other stations designed at the same time in the 1960's, the majority of plant monitoring was committed to a process control computer (GEC M2140) which also handled some of the loop controls.

It is generally accepted that sometime during the lifetime of the plant the central computing system will need to be replaced. The date for this replacement has not been determined and reference in this paper to Hinkley Point 'B1 is to provide an example of general data management problems.

The objective of the paper is to identify a mechanism whereby data can be classified for allocation to a computer within a distributed network, and show that this is compatible with the proposed approach for replacing a centralised system with a distributed one.

It is of prime importance to ensure that the data within the computer system is assigned a level of resilience appropriate to its use. In a move to a distributed network the total resilience of the system increases, but any individual function might be less reliable. High reliability of the computer system in a centralised approach is usually obtained through a 'hot' standby computer which provides a broad based approach to maintaining performance in the event of component failure (Fig. 1).

The 'hct' standby approach is complex and practically difficult when distributed computers are used and indeed invalidates the prime reason for adopting a distributed approach.

2. Advantages of a Distributed Computing Approach The CEGB has for some time now preferred a distributed computer approach to plant monitoring and control, and there are now commissioned control systems on at least 3 mcjor generating units. The approach has yet to be fully implemented for plant monitoring. Before a distributed computer system is installed on a nuclear power plant, the CEGB will have to show that the whole system and the critical components in it are adequately resilient. In practical terms this will mean proving any new method is as resilient and reliable as the existing centralised approach. There are 4 major reasons why the distributed computing approach is considered to be a better option to a centralised one. These are:- - 120

2.1 Resilience Within a distributed computer environment the required degree of resilience can be obtained by considering each function separately and tailoring the computer support to the specific need. Thus duplication or even triplication of functions are only supplied where necessary. Other less critical areas have no immediate functional support and the rest of the system take account of localised failure.

2.2 Modularity Because each element in a distributed network can be given a small, well defined task, it is strategically easy to re-generate, or replace any particular function. This feature is naturally only made available by a well designed system. In the event of a need to replace a specific control loop or monicoring function, the computer can be considered as an extension of the plant I/O and replaced or modified without affecting the rest of the system. However the system design requires an explicit data management structure to permit such modifications.

2.3 Extensions Any monitor or control element can be attached to the system at a later date without the fear of degrading the performance of the existing functions. The new elements can be added by engineers with only a limited knowledge of the rest of the system. This is obviously very valuable when considering refurbishment in tt^.at once the basic system has been designed and implemented, it can "grow" to eventually replace all the residual functions of an existing mechanical or computer based system.

24. Cost The actual costs of a distributed computer system is probably greater than a centralised one when considering just the purchase price of the hardware. However over the lifetime of the computer system the degree of maintenance work and lack of specialist environment for the distributed equipment is likely to more than compensate for the difference in cost. The major advantage of the distributed approach in terms of costs are the specialist manpower savings that accrue from using a high level engineer orientated with a language (CUTLASS) and allowing piecemeal development with a pre-defined data management structure.

It can be seen that the single factor that has most effect on the benefits to be gained from distributed computing is the design of the "data-base", in that it must be simple enough to be used by engineers and well structured to provide the degree of flexibility and redundancy required. This is particularly true in the case of Nuclear Power Plant. - 121 -

Data Classification

The location of data within the distributed network should be determined by identifying the most appropriate degree of resilience that the data must have. For the sake of this paper, and the identification of a pragmatic approach, resilience is redefined to be directly related to the mean time to restore a specific function. This is because modern equipment ic extremely reliable and the mean time to fail can be measured in months to years. Thus a highly resilient function would be one where the mean time to recovery was very short.

For simplicity 3 levels of resilience are considered here to be appropriate for a distributed computer network on power plant.

3.1 High resilience:- defined as where the mean time to recovery is less than 1 hour. Here the resilience can only be achieved by automatic means whereby either duplication of function io provided or manual switching to an alternative approach. On conventional plant this approach is typified by control systems that might freeze and then switch to manual with an alarm indication.

Particular areas in nuclear power plant which fall into this category are the BCD monitor, the shut down sequence equipment and rod control.

3.2 Medium Resilience:- defined as when the mean time to recovery is less than 1 day. In this category partial failure may limit strategic information and plant flexibility, but would not put the plant in jeopardy. It is essential to have the ability to recover from this situation by facilities on site using shift staff. Typical examples of this are vibration monitorinn on the reactor or turboalternator, strategic history information and seme incident recording.

3.3 Low Resilience:- defined as when the mean time to recovery is greater than 1 day. Here repair can be left to day staff or the manufacturers maintenance teams. Plant performance is not affected by such items although the degree of functional "back-up" might be. Items here would usually include equipment and functions that are generally more complex, for example, failures within the communications network which are not significant because of its re- routing ability. Data items that come into this category are long term history information and performance monitoring which are required as part of the off line data coJlac'.ing facilities. Generally this would not be operational information but related to the long term plant integrety. Typical examples are the deposition rate monitor for graphite on the fuel elements, and life fraction calcul&tions on the boiler tubes.

Having defined the 3 broad classifications it is necessary to allocate the degree of resilience required for every data item in the particular system. This does not only include primary data measured from the plant, but also secondary derived data which usually requires the bulk of data storage. This process can be simplified by categorising the data into the following major classifications. - 122 -

(i) Loop control and bafety requiring high resilience (ii) Operating strategy, History and Incident records broadly requiring medium resilience (iii) Monitored and Statutory information generally requiring low resilience.

These are shown in Fig 2.

The main reasons for classifying the data into the categories is that high resilience is costly and complicated and therefore should only be made available when absolutely necessary. The classifications also map very conveniently onto a hierarchical Network and simplify the "data-base" requirements.

Network Organisation

This paper deals with a theoretical approach to the management of data in a distributed computer network. The prime reason for this study is to determine a strategy for the computer replacement at locations such as Hinkley Point 'B' when the existing equipment becomes too restrictive or unmaintainable. This is unlikely to happen over the next 5 years and therefore assumptions are made about the availability of hardware. In particular it is assumec that in this timescale intelligent message handling networks will be available which automatically provide routing redundancy with mii.ltiple ports to the processing nodes. Therefore no account is taken of the resilience of the network except it could be repaired on the timescales defined for low resilience systems (greater than one day). Structures such as this are already available with some main frame manufacturer's terminal systems. It is only a matter of time before they are available in the process control mini computer market.

With this assumption the normal concept of a hierarchy is not relevant, but is retained to assist the design of the "data-base". The normal linking hierarchy is replaced by a resilience hierarchy, with plant I/O accessing the hierarchy at all levels. Fig 3 illustrates the proposed type of hierarchy which is basically 3 dimensional in that some of the high resilience functions are provided by cross linked duplicate or triplicate processors.

Unfortunately there is one plant area that causes difficulty in this approach and has to be considered separately. That is the provision of on-line displays to the control room. The problem is that Ihe display processors only hold background and format data locally and access the specifically required live data from the processing centre assigned with that data. Thus although it is obvious that the display processors are given the category of 'high-resilience' and their functions will probably be triplicated, the data storage requirements fall more into the 'medium resilience' field. For this reason the displays and associated processors are not included in the hierarchy but located in another plane as in Fig 4.

It is worth noting that the backing store requirements are broadly compatible with the resilience levels in that the highly resilient level generally requires no backing store (except for displays), the medium level - 123 -

would usually rely solely on solid state forms of backing store whilst the low resilient level would use both solid state backing store and removable data storage such as mag. tape and discs.

Replacement of a Centralised Computer

There are a number of very sicjnificRit factors which cause difficulty when replacing an existing central computer system with a distributed network. These problems are anticipated at Hinkley Point 'B' and must be solved and proven at another location where the criticality of the computer performance is not as great. Within the South Western Region of the CEGB there are 2 power stations with ageing computer systems that could be used as a trial site.

These problems are itemised below:

5.1 Complete Change Over

The obvious approach to replacing the csntralised computer is to remove the existing computer and replace it with a distributed network. However this is considered too risky and violates some of the advantages of a distributed approach. The computer room at Hinkley Point has very little spare space for more computer equipment even though the replacement system would not take as much space as the original machine. The "parasitic replacement" approach is favoured whereby complete functions are removed from the central machine and implemented on other equipment. An example that has already occurred for other reasons is the 400 KV network alarm monitoring system. The display system is another good example in that it would benefit from being upgraded to use modern colour graphics displays. Replacing this function on modern minicomputers would save considerable space in the computer room which could then be used to introduce more components of the distributed network.

5.2 Shared Input

Some of the older scanners in service on station monitoring systems are difficult to couple in parallel with new scanners. For example the traditional scanners in use at Hinkley Point Power Station test the condition of the thermocouples by injecting 50 volt spikes which complicates the concept of shared inputs. Where absolutely necessary, this can be overcome by front end signal conditioning, but this tends to be expensive and not fully successful. The more appropriate method during the transition period is to scan the data with the new or old equipment and transfer the data between processors.

5.3 Time to Replace

The time taken to develop the original software for the Hinkley Point 'B' central computer system was about 60 man years. To replace the complete function with a distributed network could require about 20 man years of effort not including the essential engineering works. This degree of effort would be better managed if the 'parasitic1 approach to replacement was followed whereby complete transfer of the - 124 -

computing function could occur over 2 to 3 years and only require a limited outage time. Using this approach the original computer system eventually does no more than route messages in the same way as the network organiser.

6. Implementation Strategy

The strategy to adopt therefore is a piecemeal approach where specific functions are taken from the central computer system and implemented on the distributed network. It is suggested that the first major function to be replaced should be the display system as this usually is the one most in need of being updated and in the particular case where space in the computer room is extremely limited, this should release enough space to start implementing the network and other parts of the system including the upgraded displays. The next major area is the 'Category I1 instrumentation and the control systems which can be treated in isolation and implemented with redundant processors to obtain the required level of resilience. Once this stage has been completed and the new distributed network commissioned, the rest of the conversion exercise can proceed relatively simply.

Table 1 lists the broad plant areas at Hinkiey Point together with the numbers of analogue and digital inputs on the existing central computer system and the probable numbers of minicomputers used to replace the existing functions. The total number of inputs are about 6000 and would be handled with over 50 minicomputers. It can be seen that the number of medium and low resilient computers is small compared with the high resilient ones although the latter are larger and more complex.

The most interesting factor in this approach to the replacement of the centralised computer with a distributed network is that with the use of a high level engineer orientated language (CUTLAS5) with built in data protection, the majority of the work can be done by engineers with a close understanding of the plant. It is only at the higher levels of the hierarchy and the basic design of the network and 'data base1 that the skills of computing specialists are needed to implement the applications routines. Similarly any alterations or additions can be done by station engineers with only a limited degree of outside assistance.

7. Conclusions

By approaching the design of a distributed computer network from the requirements of the data in the system, a simple pragmatic approach can be used to determine the required system resilience. The network architecture can thus be built up which is extremely flexible and able to accommodate extensions in the future. The essential feature of this approach is that the resultant architecture is simple to understand and therefore can be used by non computer specialists who understand the exact plant characteristics. With the help of an appropriate software system (CUTLASS) these same people can implement the applications routines in a secure environment. - 125 -

This approach is particularly relevant when considering the replacement of a centralised computer system with a distributed one. Once the overall strategy has been defined the parasitic approach to piecemeal replacement of function within the old system can be managed easily and eventually leads to a fully distributed system with the desired characteristics.

The proposals in this paper are only theoretical, but the debate of how to replace the centralised computer systems with distributed network on nuclear plant in the CEGB has started. Such an approach will not be used on nuclear plant for a few years. Prior to this, the approach will be studied theoretically and probably on conventional plant. It is hoped that these proposals will generate some discussion which can beneficially affect the approach prior to actual implementation on Nuclear Plant.

Acknowledgements The author would like to thank the Station Manager and staff of Hinkley Point Power Station, in particular Mr C Green, for their ass tance in the preparation of this paper. This paper has been produced by permission of the South Western Region of the Central Electricity Generating Board.

ID/VL C0M03IDVLJUN 18 March 1980 - 126 -

1 PLANT AREA I INPUTS NO OF PROCESSORS | I (SYSTEM) [ Analoque I Diqital

I C W Systems [ 101 280 1 2 i I Turbovisory ! 317 229 1 2 I Alternator 131 282 2 I I Feed Heat 1 117 231 3 | I Boiler Feed Pumps 75 132 4 I I Boilers I 216 218 4 | I Circulators 142 275 4 I I Reactor 866 454 4 I I Pressure Vessel 360 83 2 I I Decay Heat 7 55 1 | I Safety Systems 201 0 4 I I Health Physics 0 17 1 | I Gas Turbines 20 57 2 I I Supplies 96 308 4 I I 400 KV 0 172 2 I I Others 250 228 1 I 2899 3021 1 I TOTAL 1 1 | 5920

Level 2 (History etc.) 4 I I Level 3 (Monitor etc.) , 5 | I Displays 4 I 1 54 |

Table 1 Existing number of data inputs on the unitised central computer system at Hinkley Point 'B' Power Station and approximate number of minicomputers required to replace it. - 127 -

• R3

i V \ \ \ y t \ / C 1 I C3

\ \ \ \ C2 \

FIG.1. CENTRALISED COMPUTER 5VSTEM WHFRE PLANT(R)AND PERIPHEPALS(D) ARE SWITCHABLE TO A REDUNDANT PROCESSOR(C)

HIGH RESILIENCE

DATA STORAGE

MEDIUM

LOW SHOUT LONG MCANTIMC TO • RLI'Alil CONTROL STRATEGIC CONDITION DATA SAFETY HISTORY MONI TOR r c FIG. 2 THF RE I. • nrTWFFN OATA TVPr 5j Rr .lt.lFNCE_AN^D_OTHER HELA711U liii'iN A iit:,inl'iiij"ft:o"tJi.Tvvonn - 128 -

Condition monttoiii. "\ etc.

p- L History/ A 'Strategy N T J jContro!/ |Saf«ty

PLANT AREA

PLANT AREA

FIG. 3 HIERARCHICAL NETWORK OF PROCESSORS WITH DUPLICATION OF FUNCTION AT THE LOWER LEVEL (NB. THE DATA HIGHWAYS ARE NOT HIERARCHICAL)

OISPLAV DISPLAYS PROCESSES t PICTURE FILES

FIG./. DISPLAY FUNCTION IN THE HIFRAHCHICALJjITTWOrjK. - 129 -

The Use of Distributed Micro Processors for Sodium Pre-Hoatinq System

K. FUJ1I, Fuchu Works, Toshiba Corp.

T. SATOU, Kuchu Works, Toshiba Corp.

M. SATOU, Advanced Reactor Kn<| i ncci i n<| Department, Toshiba f'orp.

II. OKANC, Nm.-le.H' Ktui i rn -i • i i n<| L.iboi .11 nrv , "I"« »r ;l 1 i i »<_* i'nip. - 130 -

Abstract

This article deals with a hierarchy/distributed control system for sodium system in Liquid Metal Cooled Fast Breeder Reactor (LMFBR). The control system consists of mini-computers, a computerized control panel and distributed front-end control units with micro-computer. In this system, the concentration of the plant operation information and the dis- tribution of the control function are aimed to improve the man-machine communication to increase the system availability. The preheating control device with micro-computer dealing with several thousands temperature con- trol points and the preheating system to maintain piping and component above the sodium melting temperature, had been developed and tested at actual sodium test facilities, and the result is satisfactory for system requirement to apply to the actual prototype LMFBR.

1. Introduction The trend toward ever larger and more sophisticated nuclear plants has accentuated the requirement for their safe and efficient operation, and this has stimulated extensive studies in the utilization of digital computers and micro computers for nuclear power plant control and moni- toring. For a sodium-cooled Fast Breeder Reactor (FBR) which contains additional systems and components compared with Light Water Reactor (LWR), operation procedure and control system are accordingly more complicated. Considering this situation, we had been developed, for the first step in 1976, centralized full automation system composed of duplex-computer for sodium test facilities in our laboratory, which has several thousands control points. Furthermore, for the second step, authors have been designed more advanced and more reliable control system with operating experience of the automation system to apply to the actual prototype FBR. Combined structure of a hierarchy computer complex and a distributed control subsystem are aimed in our study to improve the performance, man-machine communication, reliability and construction and/or arrangement flexi- bility. And this concept will agree with the technical trend, to con- centrate the plant operation information and to distribute the control function. Improvement of a microprocessor and/or micro computer, which has high-performance and high-reliability at the front-end controller, can be contributed to solve problems related to control that would be encountered in future, in the FBR operations. The preheating system using micro computer had been developed to apply mainly FBR, and had been tested at the actual sodium test facil- ities .

2. Aspect of the prototype FBR plant control systems The first prototype FBR in Japan will be composed of the major systems such as Reactor, Primary Cooling System, Intermediate Heat Exchanger (IHX), Secondary Cooling System, Auxiliary Cooling System (ACS), Steam Generator, Turbine-Generator, Electrical Equipment and Auxiliaries. The plant control system will provide overall control and coordination of the above systems for all operation period. TMI accident typically requires to the control and instrumentation system more efficiency and surely surveilance to assimiliate a vast quantity of plant information. In addition, as the operation of the FBR is highly dependent on rapid and accurate monitoring of nuclear and - 131 -

thermal processes, the utilization of computers is becoming standard which results improved operation performance. Furthermore, advanced electronic control panel and multiplexing technology to reduce cable quantities and to increase performance are being considered. The functional configuration of computer systems for the typical prototype FBR is shown in Figure-1, and its functional description, ex- cept offsite computers, is briefly shown in Table-1 . Site computers are allocated by respective functions and each block computer is design- ed with reliable duplex or multi system.

3. Automation System for Cooling System 3.1 Centralized Full Automation System Centralized full automation system mainly composed of duplex system with process computer T0SBAC-40C was developed in 1976 for sodium test facilities in our laboratory. Components included in these facilities are: 10 tanks, 6 electro-magnetic pumps, 13 heat exchan- gers, 4 cold traps, 5 plugging indicators, 120 sodium valves, 60 argon valves and 800 electrical heaters. The test facilities are devided into four loops and these can be ooerated independently. The automation system are consisted of TOSBAC-40C duplex system, interactive computerized operator console, interface between com- puter and plant actuators, system interlock and safety protection system. The automatic operation system was developed aiming: (1) fully automated simultaneous operation of four test loops by means of digital computer directly, (2) computerized operator console with improved man-machine communication for the numerous plant input/ output signals, (3) ultimate safety protection measures to be provided by separate hardware independently of the computer system, whose function would thereby be dispensed of consideration for pro- tection and plant/computer interfaces to assure high reliability and safety. Computer system assures fully automated normal opera- tion of the four sodium test loops, including start up, steady state run and shut down. Excluded from this automatic system are the functions of inspection and testing, as well as the maintenance operation before start up and after shut down. Particular effort was applied to automation of the start up and shut down operations, which call for the manipulation of more than 100 valves and compo- nents in appropriate procedure, and the supervision and control of 800 temperature control points. The basic sequences of operation are largely common to all of the four loops; (1) start up preparation, (2) argon gas exchange, (3) preheat, (4) sodium charge, (5) steady state run, (6) heat down, (7) drain, (8) plug check, (9) reset operation. Direct digital control (DDC) items for this system are as follows: (1) temperature ON/OFF control for 550 loops, (2) temperature PID control for 250 loops, (3) air flow cooling control for 20 loops, (4) sodium flow control with multivariable control method for 13 loops, (5) opera- tion of sodium valve for 120 pts, (6) operation of argon valve for 60 pts, (7) operation of damper for 20 pts, (8) other components operation for 100 pts. Computer hardware system is shown in Figure 2. The sequence control program using plant table method like a COPOS R^ (Computerized Optimum - 132 -

Plant Operation System), man-machine communication program for interactive computerized operator console equipped with colour cathode-ray tube (CRT) display device like a PODIA® (Plant Opera- tion by Displayed Information and Automation), DDC programs and others, have been developed for assuring automatic plant control. Three years operating experience of this full automation system have gained fully satisfactorily compared with conventional manual control system. Especially, the control performance by DDC, one man operation, supervisory function and man-machine communication have been greatly improved. Through these experiences, the require- ments of remaining free manual operation if required, on line main- tenance function of the system and more reliable system have been newly recognized to be necessary,

3.2 Distributed Control System Actual cooling system in the FBR is similar to the test facilities in our laboratory, with respect to basic components and its opera- tion procedure. Nevertheless it is important but troublesome job to control the system, the operator should operate cooling system, such as cooling system complex and additional components compared with LWR, during plant starts up or shuts down. In addition, con- trol panel size reduction, high reliable device and cable quantities reduction are serious problem to accomplish the prototype FBR in Japan. Because of this situation, we have designed more advanced and relia- ble control system than the automation system described above. Figure-3 presents newly developed control system and Table-2 shows functions allocated to each control unit. Concept of the newly developed control syscem is aimed to acquire the following functions: (1) man-machine communication and sur- veillance function should be further improved through computerized control panel, (2) actuators should be controlled by distributed front-end controllers separated from centralized computer, not only automate fully the cooling system by one man but also can be operated freely as the conventional manual operation system, (3) online main- tenance partially avoiding the system failure should be improved, (A) system diagnostic function should be further improved. Process computer TOSBAC-7 having high performance and high reliable than TOSBAC-40, had been newly developed. Already, programmable logic controller (PLC) TOSMAP (Toshiba Micro- processor Aided Power Controller) had been developed and improved to the actual power plant. TOSDIC (Toshiba Direct Digital Controller) had been also developed and improved to the actual industries widely. These TOSMAP and TOSDIC can be linked between process computer TOSBAC- 7. Therefore, this control system can be composed of a hierarchy and distributed complex system to make sure the concentration of plant information and distribution of control functions. Though several tens kinds of temperature control device have bee.i frequently availed in industries, there are not suitable preheating control device for FBR, which controls a numerous quantity of temperature control points more than several thousands. Considering these situations, preheating system especially for FBR have been developed. - 133 -

4. Distributed Preheating System 4.1 General Generally, the design of distributed control system defines the in- vestigation of system optimization with respect to concentration and distribution. If the distribution of devices proceeds ultimately, it will greatly increase cost, space, complexity of maintenance and communication between computer, like that of the conventional con- trol devices. On the other hand, lack of distribution will occur same problem on the full automation system described above. Therefore, moderate distribution level depending on its system scale will be expressed by the following equations.

f (wn) = ni : parameter relating to system requirements wi : weight coeff. of ni m : scale variable

4.2 System Requirements 1. With similar equation described above, our centralized automa- tion function would be gained; improved man-machine communication with computerized control panel, centralized data processing and monitoring, control performance such as rate of change control depending on operating procedure and balanced temperature distri- bution. 2. Direct digital control should be done with front-end controller, to continue control and monitor when the computer released. 3. Front-end controller should be allocated to each suitable block to keep the system availability without backing-up system. 4. Manual operation would be selected freely and partially if ope- rator required. 5. Optimization of cost performance ratio 6. Reducing total space 7. Reducing cable quantities 8. Having system and self diagnostic function 9. Keeping suitable information-transmission ratio between computer and front-end controllers 10. To have a long life without failure and any trouble 11. Maintenanceability 12. Modulated system for expansion and modification 13. Simplified system

4.3 Function and System Allocations Function and their system allocations are basically defined as shown in Table-3. - 134 -

4.4 Preheating Control Device Preheating control device as a front-end controller have been devided into a control unit, a relay unit and a power switch unit with electric leakage to ground detection and breaking feature (ELB). Figure-4 shows a conceptual architecture of this device. Normally a set of three modules such as a control unit, a relay unit and a ELB unit, is used to control heaters, but it is possible to use only a control unit to monitor the temperature points. Prototype FBR will have about three thousands heaters and about two thousands monitoring inputs.

4.5 Architecture of Preheating Control Device Optimum solution with respect to distribution found out with con- sidering investigation of equation (1) and under the technical res- triction. 256 points are maximum quantities to be processed for each control unit, and its should be divided by 16 groups x 16 points/ group at maximum. A ELB unit contains 16 ELBs and each ELB turn on or off 16 SSRs and the numbers of SSR corresponds to the numbers of heaters. A relay unit contains 128 SSRs as a standard board size. A control unit has a micro computer with process input and output, control panel, power supply and transmission module, but the reference block terminals to compensate the thermo-couple cold point are ex- cluded. The reference block would be equipped to a respective place locally and multi wire cable would be installed for the reduction of cable quantities and expensive thermo-couple compensating wire. Specification of micro computer CPU : Memory : RAM, ROM, N-RAM, total 8 kW Process input Analogue : 256 T/C + off set point Digital : 16 ELB status+SSR status (option) Process output Digital (TTL) : 256 points for alarm indicators 256 points for SSR Digital (Power type) : 256 points for EMR (option) parallel input/output: 1 set for thyristor control (option) Interface for operator console Transmission module : 1 set Photo-1 shows the prototype preheating control device developed in 1978, and the device was demonstrated in actual sodium test loop in Oarai Engineering Center of Power Reactor and Nuclear Fuel Develop- ment Corporation (PNC), in 1979. In the device shown in photo-1, transmission module is not included but a reference block is included in a control unit.

5. Conclusion As a result of the experimental study of the possibility of ef- ficiently operating and controlling the sodium cooling system, a hier- archy and distributed computer complex system can be contributed - 135 -

significantly to solve the problems related to control system that would be encountered in the actual prototype FBR oneration. Particularly, the preheating de-'ice newly developed was demonstrated in actual sodium test loop which installed in PNC Oarai Engineering Center, without any trouble. In considering future technology n~ospect related to control system, materials and devices using in the system may be changed by rapid pro- gress of electronics along with performance and reliability, and also the concept and architecture of the control system discussed aVove would be improved more and more frequently and realistically. Acknowledgement The authors wish to thank members in Oarai-Engineering Center of PNC for their suggestions, giving opportunity and support throughout this study. - 136 -

REFERENCES

(1) (',. Yan, et, al, "Distributed Computer Control System in Future Nuclear Plants" IAEA-SM-226/100.

(2) M. Olino, et, al, "Development of Computer Control System for Sodium Loops" NUCLEX 73, Basel, Switzerland.

(3) S. Takamatsi:, et, al, "Computer Control System for Sodium Test Loops" Journal of Nuclear Science and Technology Vol. 15. No. 3 (Aug. 1978)

(4) H. Otaka, et, al, "BWR Centralized Monitor and Control System, PODIA Development" Toshiba Review No. 107 (1977). - 137 -

§• O U ,arge scale Training Business Simulator Computer

Main Display Computer Computer

Ift-core Primary Secondary Fuel Management Diagnostic Cooling Sys Cooling Sys Handlinq Computer Computer Computer Computer Computer

See. Detail Fig. 3

Figure-1- Total Ccwcut«*r System - 138 -

TO MAIN COMPUTER Computerized Control Panel for Cooling System

Control Panel

Cooling Safety System Computer System

TOSWAY

TOSMAP TOSMAP TOSDIC

Preheating Controller Programmable Logic Controller Digital Process Controller

Figure-3. Distributed Automation System for FBR Coaling System

Main computer

Computerized control panel

display inf. CRTs Computer for Annunciators cooling Operator con- sole switches system operated inf. etc.

i I i References scan & alarm condition information

ELB unit Control unit Micro computer with Process I/O

Console panel Control Alarm indicator Solid State Relays signal Thyristers Transraision Electric Magnetic module Relays

Scan, alarm, control, man- activate heaters On/off the power detection machine communication with of current leakage to ground console panel diagnostic, transmision testing from Temperature heaters sensors

Figure-4. Conceptual architecture of preheating control device - 139 -

Table-1. Functions of computer

Hain Computer In-core Primary Secondary Fuel + Diagnostic Cooling Sys. Cooling Sys. Handling Display Computer Computer Computer Computer Computer Computer

1. Core performance Following 1. Scan, log 1. Full auto- 1. Automatic X. Personal Functions calculation diagnostic and mnniftor mation c control for Radioactive a. BOP Performance Man-machine Fuel Exposure 1. Failed 2. Sodium communica- Handling calculation Fuel Detec- leak monitor tion Machine and 2. Radioactive J. Operation guide tion Rotating Exposure Bulk & Local 3. Operation (See detail Plug Evaluation Scan, Log fi guide and Table-2) 2. Noise Record supervisory 2. Prevent 3. Weather Analysis 5. Data Gathering of Primary J mi sopera- 3. Fluctuation cooling Sys. tion 4. Monitoring Method operation Post 3. Control & 4. Sodium Imaging of 5. Radioactive Boiling Under Haste Detection Sodium Disposal 1. Centratized 5. Reactivily Viewer 6. In/Out the Display with Diagnostic 4. Hanaqe the Control COT Loose 6. Fuel Region arts Inspection 2. Alarm data Analysis Display

Table-2. Function Allocation of Cooling System

Computerized Program- Digital Supervisory Preheating Hardwired Control mable Process Computer Controller Logic Control Others Naaw Panel Controller Controller

TOSBAC-7 TO SUP TOSOIC

1. Start up/ Includesr 1. Preheat- 1. Sequence 1. Process 1. Safety Subsystem Functions shut down ing control control & system automation automation 1. Colour Control indication CRTs with 2. Automa- 2. Interface e.g. 2. Maintain the keyboard 2. Automa- tion 2. Automa- relays computerized and tion sequence tion Plugging * control Lightpen preheat- control process Sodium panel ing control Pururity 2. Operator System

collection for from front-end- automation 3. Scan, Alarm check and monitor cont. £ logging recording 3. Annuncia- tors 4. Information transmision between 4. System supervisory computer monitoring 4. TOSDIC

5. Information 5. Minimixn - 5. Diagnostic transmision Control between SWs front-end Recorder* 6. Han-machine communication for controllers Indicators manual operation. and main Control- computer lers

6. System diagnostic Table-3. Functions and syateM allocation* of preheating ayateM

Device Function! Computer (+ panel) Pront-*nd control liir

1. Scan NO YES

2. Alarm ¥ea, totally and visually Yas, aach point and with horn alnpla

3. Control NO Ve>, aat point ON/OFF or PID control

4. Supervisory control Full automation Followed by conputar Rate of change control with aach Mininization of refaranca temperature deviation

5. Logging YES Option

6. Protection NO Yaa, raaat tha power supply heatars

7, Manual operation Approval Approval

Salf a* Dla^nOICXCM OT QQV1GG syuzetn * sei r

9. Test the control loop Option NO

10. Data transmision YES res

Between aain computer VIS HO

Photo-1; Preheating Control Device

(Left to right; • control unit, a r«l*y unit and a ELB unit) - 141 -

DISTRIBUTED SYSTEMS DESIGN USING

SEPARABLE COMMUNICATIONS

by

A.C. Capel and G. Yan

ABSTRACT

One of the promises of distributed systems is the ability to design each process function largely independently of the others, and in many cases locate the resulting hard- ware in close proximity to the application. The communications architecture for such systems should be approached in the same way, using separable communications facilities to meet indiv- idual sets of requirements while at the same time reducing the interactions between functions. Where complete physical sep- aration is not feasible and hardware resource sharing is req- uired, the protocols should be designed emphasizing the logical separation of communication paths. This paper discusses the different types of communications for process control applic- ations and the parameters which need to be characterized in designing separable communications for distributed systems. - 142 -

DISTRIBUTED SYSTEMS DESIGN USING SEPARABLE COMMUNICATIONS

by

A. C. Capel and G. Yan

1. DISTRIBUTED ARCHITECTURES FOR PROCESS CONTROL

To achieve an acceptable balance between cost and performance in designing distributed systems, architectures must be selected to match the specific requirements of each application. Although no practical design methodology is yet available to help designers to better understand distributed system properties and to guide them in generating more accurate specifications, a generalized design sequence was formulated to illustrate the application of established design methods in three major design areas: processing clusters, data communications, and databases [1].

In the data communications area, a wealth of information is already available [2,3]. Much of this work is focussed on the business data processing market where resource sharing and remote human interactive services [4,5] must be supported over large physical distances, using facilities based on existing plant. Other work, directed towards the sharing of in-house computing, storage and terminal equipment, has led to highly- multiplexed localized single bus networks [6,7,8]. In contrast, the process control requirements, such as those found in a nuclear power plant, generally encompass a spectrum of communication needs which will call for a range of solutions.

One of the promises of distributed systems is the ability to design each process function largely inde- pendently of others, and in many cases locate the resulting hardware in close proximity to the applica- tion. Consequently, effective communications must be provided since functions now communicate over larger physical distances and between many generically dis- similar machines. Rather than following the trend - 143 -

of using single highly multiplexed buses, it is proposed that separable communications would best meet the requirements of process control applica- tions.

2. SEPARABILITY AS A DESIGN OBJECTIVE

A distributed system can be envisaged as a complex assembly of hardware/software elements overlayed by an interconnected assembly of data acquisition, proces- sing, and control functions. Each of these functions, while performing the individual actions of, for example, pressure control, temperature control, operator input, should be designed in a manner which reduces inter- actions between each other due to implementation details.

To simplify the design tasks, the general approach taken is to subdivide the total information transport system into subsystems, each carefully matched to a particular set of requirements. A full understanding of the re- quirements is essential so that the partitioning of the total job can be carried out efficiently. This partitioning is similar to that done for the compon- ents of the distributed system itself. Figure 1 illus- trates this analogy of equating centralized processing with highly multiplexed communications, and distributed processing with separable communications. The rationale is simple. Instead of simply looking at the cost savings of shared hardware, which is the major attraction for both centralized processing and highly multiplexed com- munications, one should now consider the better matching of requirements with the available electrotechnologies which would lead to distributed architectures and separ- able communications.

While some functions with stringent requirements will use separate communications hardware, clearly the cost and mechanical constraints of today will require some sharing of common equipment. The first task is to identify user groups which have conflicting requirements or those for which the sharing of common facilities is not desirable nor economically attractive. Within each sharing user group, designs which make one user logically independent of the others should be adopted. In this manner certain performance parameters, e.g. throughput, can be guaranteed to be independent of the state of other users. - 144 -

/ \ INTERNAL COMMUNICATIONS p CENTRAL PROCESSING p

HIGHLY MULTIPLEXED COMMUNICATIONS DISTRIBUTED PROCESSING SEPARABLE COMMUNICATIONS DISTRIBUTED PROCESSING

FIGURE I: COMPARISON OF PROCESSING AND COMMUNICATION ARCHITECTURES

USERS USERS USERS

'. /

USER PROTOCOLS I USER \ I/PROTOCOI.S1

| I PACKET LAYER PACKET LAYER

FRAME LAYER 1 FRAME LAYER

ACCESS

PHYSICAL ACCESS '" PHYSICAL ACCESS | PHYSICAL \ I (/ ACCESS ^ f \ / \ > COMMUNICATIONS COMMUNICATIONS COMMUNICATIONS MEDIUM MEDIUM MEDIUM

A) PHYSICALLY SEPARABLE B) CCITT X.25 C) INTRAN

FIGURE 2: SEPARABLE PROTOCOLS - 145 -

2.1 Physical Separability

Physical separability pertains to the use of totally distinct hardware for different communication func- tions. Unique requirements call for separate sub- systems and the extent of this is limited by the cost and physical complexity of the resulting design. In REDNET [9] , a unique requirement for a broadcast time base for all processing elements led to the provision of a time-of-day subsystem which uses separate hard- ware. On the other hand, a number of multipoint-to- multipoint subsystems each providing identical but separate inter-function communications are overly costly and complex, and the best approach may be a single multiplexed subsystem. This option was selected for terminals and some inter-process com- munications in REDNET [10].

Clearly a balance must be struck between the current cost savings of shared hardware, with attendant increases in interaction between functions, and the advantages of physically separate facilities,

2.2 Protocol Separability

Even when communications hardware is to be shared, the design of protocols can be carried out in a manner which emphasizes the separability of support to individual users. Since it is the protocols which permit resource sharing in the first place, it is in the design of protocols that separability must be entrenched. This aspect of protocol design is one not generally considered in the available literature.

Currently the "layered" approach to protocol design is favoured [11] and three examples are shown diagram- matically in Figure 2. Each one is designed to inter- face a number of users to information transport equip- ment. Every layer of each protocol operates as inde- pendently as possible of the other layers, while progressively insulating the user from the specific considerations of the hardware transmission media. Clearly, for shared media, separability of individual user traffic becomes progressively less obvious at the "lower" layers. - 146 -

Figure 2 (a) shows how physically separate media promote the use of completely separable protocols/ although care must be taken when using common proces- sing hardware and software. Separate hardware does one no good for example, if a poorly controlled shared buffer pool is used.

The CCITT X.25 [12] protocol of Figure 2(b) combines logical channels at the Packet Layer so that they may be subjected to common controls at the Frame Layer. For X.25, data flow and error control procedures are available at both layers, although their use at the Frame Layer without adequate protection at the Packet Layer, will allow logical channel data flows to poten- tially interfere with one another.

Figure 2 (c) represents the internal INTRAN structure used for the REDNET terminal support subsystem [10]. Since this subsystem uses a multi-access media, an extra Protocol Layer is added to control media access. Additionally some units have access to a second physical channel (for high data rate transmissions), and so a split in the data flow is made at the lower layers to route the data appropriately. (The second channel utilizes a different media access protocol more suited to large data transmissions.)

The INTRAN design attempts to minimize user inter- dependence. All flow control procedures reside at the Packet Layer, with none provided at the Frame Layer where potential common blocking might occur. Similarly since ARQ* error control procedures are used, and since these procedures may also cause blocking, error detection only is provided at the Frame Layer with recovery provided at the Packet Layer only.

Similar measures are taken at the Media Access Layer but in addition, this layer must take into account the operation of other units attached to the multi-access media. INTRAN uses a primary channel access technique which guarantees a minimum level of service irrespective of other loads. Additional capacity is available depending upon total load. The optional second channel uses a different access mechanism which is more efficient in channel usage but provides no access guarantees beyond strictly statistical ones.

*ARQ: Automatic request for retransmission requires retransmission of erroneously sent data; as opposed to FEC - forward error control - procedures which include error correction codes within the initial transmission. - 147 -

For communications systems which use store and forward or inter-linking intermediaries, layers of protocol will exist between users other than those shown in Figure 2. Considerations similar to those already discussed should be applied in these eases.

3. COMMUNICATION TYPES Before a separable communications facility can be designed, it is necessary to identify the different communication types to be supported, which can be grouped into: machine-to-machine, man-to-machine, and man-to-man communications. Although important in practice, man-to-man communications will not be dealt with further.

3.1 Machine-to-Machine Communications

Five examples are analyzed and summarized in Figure 3 to delineate a set of parameters needed to character- ize the communication types. For specific designs, the identification of communication types is derived directly from the requirements. 3.1.1 Inter-Process Communications (IPC)

Refers to the interchange of short, concise coordina- tion messages between functions (or tasks). Large data transfers are specifically excluded and relat- ively low throughout requirements are expected. These interchanges are subject to very critical constraints in terms of the control of transmission delays since task semaphoring schemes (using IPC) are very sensi- tive to execution delays. Uniform transaction arrival rates can be expected leading to an even loading on the communications facility.

For distributed systems where some functions may execute in more than one physical machine, addressing by function would be an asset. 3.1.2 File Transport Refers to all interactions between processors and/ or storage devices involving the movement of large amounts of data. These data can be characterized in terms of the length of time for which they remain valid. Thus, rapidly changing data must often be transported with correspondingly short delay times while slowly changing data can tolerate longer delay times. 148 -

0J rH - PHYSICAL 0 *O O tJ (D O ENVIRONMENT •4-1 O

TOPOLOGY CL ft

c £ q o 0 o • H •H •H >1 -P ADDRESSING a s •0 U •° 8 3 3c

c C -r-1 H -H •H •0 3 o O S Cu -H 4J ERROR CONTROL o -JJ c (H •H 1 s1 0 *J 4J 1 PM C c i 1 -H 0 0 s 4J 4J 1 f aaH 4J •U | V c q DATA FLOW CONTROL r^ P 3 o o (buffering) S B. 0, i 1 I i Bi p. 2 a o LOAD RANGE

THROUGHPUT - .. e o

A id -u TO i u i e TRANSMISSION u -u c -H s iH 4J U 4J O O O -P DELAY J= -H O -H Si 0) 0) O

DATA FORMAT o w UNIT OF DATA 3^ g*

a. o

FILE m TERMINALS TRANSPORT 1 MACHINE-MACHINE MAN-MACHINE - 149 -

In Figure 3 a more detailed characterization has been made with the extremes represented by "batch-like" and "real-time" descriptors. Real-time data are moved to real-time functions which rely on short trans- mission delays. Batch-like data can be subjected to transmission delays since the functions using these data are subjected to execution delays due to queuing and other factors.

Batch-like data will also require extra data flow control procedures since batch functions are less likely to be ready to accept the data at the instant of arrival. Loading of the communication subsystem will be more even since the higher tolerance on trans- mission delays will allow longer averaging periods fnd thus lower peak loads.

Sensor and Actuator Communications

Involve the transfer of information between real-world interfaces and control functions. Traditionally, these devices use special purpose interface and communication subsystems. In a distributed system, where such data may be moved to many physical locations, such communica- tions must be considered to be an integral part of the total information system.

It is difficult to identify communications requirements for sensors and actuators without a knowledge of their functional partitioning. For example, a undirectional broadcast-style subsystem could be provided if sensor calibration functions are partitioned away from the sensor. If sensors are capable of responding to specific commands, bi-directional communication is required.

Generally, devices to be served are geographically- distributed, oftentimes have highly periodic data throughput requirements, and require predictable (and possibly short) transmission delays. These require- ments can be judged in more detail based on tha control algorithms in use.

In many cases the physical environment of sensors and actuators vary widely. Thus the communications subsystem must be suitable, in terns of cost, wiring technique, etc. for the range of such environments. - 150 -

3.2 Man-to-Machine Communications

Communications with man encompasses a wholly different range of constraints, both in the area of timing and presentation of data, and in the area of variability of input. A demand for a display, for example, may occur at any time and the required system response speed is based on difficult-to-determine psychological factors. Man communications also precludes the use of complicated protocols to control data flow and errors.

3.2.1 Status Reporting

Status reporting is likely to be implemented as a "read-only" function. Specific reports may be elicited by operator demand or general information may be presented by "broadcast" displays. Displays may originate from one database or may be made up from information obtained from several different sites. These sites may be direct outputs from sensors, functions, controllers, and databases. Combining data into a single display could be dene dynamically according to total system state or operator enquiry and may be a local function of an "intelligent'1 display unit.

3.2.2 Command Control Communications Control operations are typically "read-write" functions accessible by selected personnel which allow them to change plant operating parameters. Status and command control functions may be combined in one device, although additional security would be required and personnel access procedures become complicated.

The command control sequence is: select the function, pass any security control information (key) to the function and make a secure transmission of the new parameter settings. While a variety of conventional techniques can be used to secure the operator inter- face to the control facility, security within the communications facility is essential.

3.2.3 "Direct" Man Communications "Direct" communications between man and the equipment pertains to functions which require minimal intelligence at the man/machine interface. Such automatic functions 151 -

as: door lock switch sensing and (possible) activation, personnel presence sensors, alarm annunciation are included. Typical data flows for such applications have high priority, are bursty, but have low average data rate requirements.

4. CHARACTERIZATION OF COMMUNICATION REQUIREMENTS

4.1 Data Format and Units of Data

Many communication parameters are defined assuming a specific data format and are based on the minimum quantity of this data that must be transferred at any one time. Terms such as bits, bytes, words, records, blocks, and files may be used to describe the users1 data format. The concept of a "unit of data" is helpful to describe that quantity of data which, when passed through the communications system, is sufficient to initiate significant processing at a receiver. A unit of data might range from a binary indicator of a contact closure state to a whole file which describes a matrix of temperature readings. One can envisage that a communications scheme for the scan- ning of sensors (individual small units of data) would be different than that for large file transfers.

4.2 Transmission Delay

An event or condition at one location is reported to another via a communications system which introduces a transmission delay. Delays between sensor inputs and calculated control outputs are very important parameters in control system design. Some control algorithms can be constructed to compensate for known delays, but in general one would like to have delays which are as small and as predictable as possible. Interprocess communications is very susceptible to transmission delays. A function in one place re- questing a service of another is often subjected to time coordination problems. In some cases trans- mission delays can have an excessive impact on task semaphores.

The delay will be the sum of several factors including propagation delay, service and waiting times, and delays introduced by error control procedures. The latter two can be significant for process control applications. When sharing common hardware, access to the equipment must be made prior to transmission and this will affect the waiting time. ARQ error control procedures may require several attempts before transmission is successfully completed. - 152 -

4.3 Throughput and Load Range

The communications throughput requirements are deter- mined by the amount and speed of the data to be transported. In a shared facility, the delay imposed on a transfer will vary due to loading and the throughput available to each user must be speci- fied in terms of the varying load to be expected. During certain system states, variations can be large: trip, shut-down, start-up, etc. Occasional large instantaneous (worst case) loads can also be imposed even during normal operation if periodic data transport is unsynchronized.

When discussing loading, users must estimate the loads which they expect to impose (and when) on the communications equipment. Thvi communications designer must clearly indicate guaranteed and average performance in the light of all user loads. In many cases, guaranteed performance levels will be an important factor in determining whether sharing of the communications subsystem is feasible.

4.4 Error Control

While every communication channel is susceptible to errors, the specification of error rates must be made in context since unrealistic demands often lead to inefficiencies which do not meet real overall per- formance goals. Sensors and human operators, for example, often have a high error (failure) rate for which processing functions make due allowance. Communications between process and actuator on the other hand are more stringent and require consider- ably more attention. Various error control tech- niques are well-known and they must be selected with a knowledge of the requirements of the data being transported. For example, forward error correcting codes allow the receiver to correct all known errors without further interaction with the data source. Unfortu- nately, error correcting codes require greater data transmission overheads than simpler error detection- only codes. Automatic repeat request (ARQ) proced- ures, which use error detection-only codes, require that the sender maintain copies of all unacknowledged messages until they have been received correctly. - 153 -

4.5 Flow Control Flow control procedures are used to co-ordinate the transmission and reception of data. Flow control is not always required, e.g. periodically produced sensor scanning for which the receiving process needs only the "latest" value. Other situations, (e.g. terminal displays for operations staff), cannot guarantee that data source, data transmission media, and data sink can be made available at the same time. Flow controls may be required to limit loading during critical times, and may also be integrated with error control procedures.

4.6 Topology Considering the flow of data, four basic topologies can be described. A multipoint-to-multipoint con- figuration allows a number of data sources to commun- icate with data sinks with interconnection patterns changing dynamically. A point-to-multipoint link has a single data source which broadcasts to a number of sinks. Multipoint-to-point configurations have the opposite topology, e.g. sensors scanned from a single point. The point-to-point configuration permits two devices to communicate with one another only.

It is clear that vastly different error control procedures, protocols, etc. are applied to the different topologies. A broadcast topology can be made very secure for example, simply by ensuring that receivers cannot transmit, although FEC rather than ARQ error control would be required. 4.7 Addressing

If functions are permitted to change their physical addresses dynamically, then procedures must be provided to allow the communications system to locate them. A relocated function must tell the system its current address and these interactions if dynamic, can become very complex.

4.8 Physical Environment It is evident that the basic components of communica- tion subsystems serving each type of user must be appropriate for the physical environment. For example. - 154 -

sensors and actuators must be connected to communications equipment appropriate to local conditions. Requirements placed on computer-to-computer equipment are likely to be less stringent.

5. CONCLUSIONS

A uniform approach using separability as a design objective is effective in developing communications facilities for real-time process control applications. Parameters, characterizing the different types of communications, have been discussed and these can be used as criteria in selecting the communications sub- systems for specific applications. The use of separable communications is consistent with the functional partitioning strategy for system archit- ectures and is another step towards realizing the advantages of distributed systems.

REFERENCES

1. L'ARCHEVEQUE, J.V.R., YAK, G., "On the Selection of Architectures for Distributed Computer Systems in Real-time Applications", IEEE Transactions on Nuclear Science, NS-24, pg 454-459,- February 1977. 2. GREEN, P.E., LUCKY, R.W., "Computer Communications", IEEE Reprint Series, 1974.

3. FALK, G., McQUILLAN, J.M., "Alternatives for Data Network Architectures", IEEE Computer pg 22-29, November 1977. 4. GREEN, W., POOCH, V.W., "A Review of Classification Schemes for Computer Communication Networks", IEEE Computer pg 12-21, November 1977. 5. SCHWARTZ, M., BOORSTYN, R.R., PICKHOLTZ, R.L., "Terminal-Oriented Computer-Communication Networks", Proceedings IEEE, Vol. 16, n 11, pg 1408-1423, November 1972. 6. F.ARBER, D.J., et ai, "The Distributed Computing System", IEEE Compcon 73 Digest, pg 31-34, 1973. - 155 -

7. METCALFE, R.M., BOGGS, D.R., "Ethernet Distributed Packet Switching for Local Computer Networks", Communications ACM, Vol. 19 n 7, pg 395-404, July 1976.

8. WATSON, R.W., "Network Architecture Design for Back-end Storage Networks", IEEE Computer pg 32-48, February 198 0. 9. YAN, G., L'ARCHEVEQUE, J.V.R., WATKINS, L.M., "Distributed Computer Control Systems in Future Nuclear Power Plants", Nuclear Power Plant Control and Instrumentation Vol. II, International Atomic Energy Agency, Vienna, 1978.

10. SHAH, R.R., CAPEL, A.C., PENSOM, C.F.,"Distributed Terminal Support in a Data Acquisition System for Nuclear Research Reactors", IJ\'G/NPPCI Specialists1 Meeting on Distributed Systems for Nuclear Power Plants, International Atomic Energy Agency, May 12, 1980.

11. WftLDEN, D.C., "The Evolution of Host-to-Host Protocol Technology", IEEE Computer pg 29-38, September 1979.

12. "Provisional Recommendations X.3, X.25, X.28 and X.29 on Packet-Switched Data Transmission Services", Inter- national Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1978. - 156 -

THE IMPACT OP DATA HIGHWAY ARCHITECTURES ON CONTROL AND INSTRUMENTATION DESIGN

T. McNeil A. Hepburn R. Olmstead

A.E.C.L. Engineering Company

INTRODUCTION

Digital computers have been successfully used in control functions in all CANDU stations since the first commercial demonstration plant. In each successive station design, the computer systems have been enhanced and expanded in their scope of application. For example, at Pickering, computers performed direct digital control of reactor regulation, boiler pressure control, and fuelling machine operation. Later, at Bruce, more control functions were added to the computer such as moderator temperature and boiler level control.

The excellent performance of computers in these past designs, provides a basis for expansion of the computer's responsibilites in a new design currently under study. In this new computer system, we intend to add the diverse interlock logic used by individual subsystems in the nuclear steam plant. In current designs this logic is implemented by relays through the extensive use of modern distributed control techniques.

The benefits to the operating company will include more flexibility in making additions or alterations to the plant control and instrumentation during the life of the plant. More systematic fault detection, correction, and maintenance will also be possible.

However, the main reason to implement a distributed control system is the advantages it offers in the design and engineering of control/instrumentation systems.

By implementing more logic in software, we intend to improve design flexibility and most important, to reduce the impact of late design alterations upon the overall construction schedule. The extensive use of data highways, replacing trunk cabling should reduce the installation and commissioning effort, as well.

In implementing such a system, we have to recognize it will hsve a large impact on the way things get done in the engineering group. Obviously, the control engineer will be implementing his logic in software rather than with relays. This gives him many more degrees of freedom, and perhaps restricts him in other ways. - 157 -

He will have to become familiar with processor loading, memory size requirements, data communications throughputs, instead of cable tray loadings, number of contacts available, and number of spare wires in a trunk.

Any system proposed should address the entire problem, and not just the remote multiplexing of sensor data. We should give special attention to the needs of the designers and project managers to ensure that the system will be an effective tool for them.

In this paper we briefly describe the engineering design process as it exists today, and identify some of the problems in this area. We will then look at a new control system architecture and some mechanized tools which become possible with this new approach to aid the design team, project management, and the field commissioning crew.

DESIGN PRACTICE

At the beginning of a project, size estimates are made of the common resources used by all control and instrumentation systems, such as, service power, trunk cabling, number of relays, number of computer inputs and outputs.

Engineering of each individual system in the plant is initiated from a process flow diagram supplied by a process design engineer. The instrumentation engineer reviews this document, and prepares a preliminary design sketch, indicating types of transducers, actuators and indicators, along with preliminary operating procedures. After achieving consensus with the process design engineer, detailed design commences. This includes ordering the instruments, initiating mechanical drafting, (i.e. panels mounting brackets etc.), and initiating electrical drafting of wiring and relay logic. Assignment of trunk wires, relay numbers, and computer inputs and outputs occur at this phase. This electrical drafting activity is most heavily affected by our new computer architecture.

?or example, one significant electrical drafting task to be replaced is the routing of connections through trunks. This is an especially onerous task. Consider the routing of wire 4118 of a ladder diagram for head tank valve control in the deuteration/dedeuteration system. (Figure 1).

Wire 4118 starts at terminal 11 of relay RL35. From here, it is connected to terminal 79 in panel PL262, and from there goes by trunk cabling to the Control Distribution Frame (CDF) terminal DF53H-79. A cross connection is made to terminal DF59H-76 which in turn is connected to terminal 176 on panel 161 and hence on to terminal 8 of level switch 91#3. This is the routing of one wire in the plant. 322-PVS CONTROL

4103

:= HS-62 =1HS-62 •±. HS-62 ~ HS-62 4117 4121 4124 4127

! LS-91 #? ; LS-91 #3 ^Z LS-91 #2 jtLS-91 ^ LS-91 #1 jtLS-9LS-911 ^I Z^Z RL-4 =: RL-21 #2 #1

LS-91 #3 LS-81 #2 LS-91 #1

v LEVEL < 224 mm LEVEL 163 mm LEVEL 104 mm HS-83 00 CLOSE I ilRL-2 3222-TK1 SEE 4130

11 . RF [~RL-35| 21 EN. TO OPEN PV5 4104

FIGUP^J 1: Typical Relay Ladder Diagram - 159 -

In total, the entire nuclear steam plant control and instrumentation wiring encompasses:

4,000 cables 200,000 terminations 10,000 cross connections

The design effort in routing these wires is in excess of 50,000 man-hours and consumes more than $200,000 of computer wiring management data processing services.

Changes to the wiring after design, are inevitable due to evolving regulatory requirements, process problems encountered during commissioning, and improvements made later upon gaining experience with operating the unit. These changes are expensive and prone to error.

Aside from the difficult management problems involved in keeping track of all this wire, there are other concerns in control and instrumentation engineering. For example, the time span between the day process and instrument engineers decide how to control the system, to commissioning and testing of the system can be three to four years. As a result, there is insufficient feedback in terms of the results of a given design. This is an open loop design procesi.

In summary, current control and instrumentation designs generate massive amounts of information, created and managed manually for the most part. The corresponding equipment and wiring represent a large fabrication and commissioning effort as well.

Therefore, our objectives in designing a new system are:

1) to reduce the impact of late control and instrumentation design changes upon overall construction schedules

2) to reduce the engineering effort required to design the control and instrumentation systems

3) to reduce the control and instrumentation installation and commissioning costs and time.

4) Maintain the levels of redundancy, reliability, availability of the existing design. - 160 -

AN INTEGRATED DESIGN APPROACH

To meet these requirements, we are proposing the extensive use of computers in the design area as well as in plant control. The design computers are coupled to the plant control computers to form an "INTEGRATED SYSTEM" which provides a p> /erful tool for design, testing and commissioning the system. This DESIGN/CONTROL system consists of three interconnected segments (figure 2):

1. Process Control Design Centre 2. Simulator 3. Unit Control Computer System

The process control design centre maintains information pertaining to all control and instrumentation systems. It is used by engineers to record their design decisions. For example, the designer assigns computer addresses and calibration coefficients associated with each instrument. He prepares the logic programs defining the interactions between a system's inputs' and outputs. This data base becomes the source of information for creating the on-line control data base.

One of the decisions instrumentation engineers make in design is the selection of .nstruments, indicators and actuators. Typically each engineer maintains a list of instruments identified by an internal specification or part number. At some point in time, instrument purchase requistions must be filled out against this list and issued to the procurement section. The resources of a design computer system could be i.iost helpful here.

Using a computer based process control design centre, instrumentation engineers may enter their requirements into a common data base which is accessed by the procurement section. Purchasing agents then add order information such as purchase order number, manufacturer, supplier, delivery data, etc. This purchasing information is available to the designers and project management through their respective terminals.

With the adven1 of software logic replacing relay panels, and data highways replacing trunk cabling, much of the control and instrumentation design information, by necessity, is in machine readable form. In other words, during the design phase of a project the design information being collected is assembled into a computer data base. Why not take advantage of this technology to permit project management to access this information on-line to monitor design progress. Note, this is not a radical departvre from current practice, but rather a mechanizaton of a manual process. It is an integral part of our solution to reduce engineering effort and gain advantage in maintaining schedules. - 161 -

INTEGRATED DESIGN/CONTROL SYSTEM

DESIGN CENTRE

UNIT CONTROL SYSTEM

FIGURE 2 - 162 -

SIMULATOR SYSTEM

As mentioned previously, one of the problems with the current engineering process is the fact designs seldom are tested until commissioning time.

To permit testing as part of the design process, or at least before commissioning, we propose a simulation facility connected to the Design Centre. At a minimum, this simulator should provide easy to use static testing tools.

UNIT COMPUTER SYSTEM

In CANDU generating stations, each generating unit is monitored and controlled by its own unit control computer system. The existing unit computer systems support:

1) Alarm Annunciation 2) Data Logging 3) Turbine Run-up and Fuel Handling 4) Control of Major Reactor and Boiler Systems

Of course, our new system continues to support these functions.

We present a model system configuration (see figures 3 and 4) for purposes of highlighting design issues such as system availability, modes of failures, and fault tolerance and correction.

The new system architecture is essentially based upon the existing CANDU concept of independent dual systems operating in a MASTER and HOT STANDBY configuration. The configuration has been expanded beyond the dual processors to a multi-processor configuration, however, to support the larger responsibilities given to it. Extensive use is made of modern data highway and high speed local computer communications technologies to reduce the number of interconnections required and improve system flexibility.

In present day nuclear stations, instrumentation and control functions are assigned to independent channels. These channels are geographically separated and independently powered to reduce the possibility of common mode failures.

A significant feature of this new approach is the use of dual redundant data highways for each channel. - 163 -

These highways support high speed, full duplex communications, system time distribution, and potentially voice circuits for maintenance purposes.

Field controllers are located at geographically strategic locations on the control channel highways A, B, and C.

These field controllers implement hands^ioch and interlock logic, (previously performed by relays) actuator control and confirmation of output commands, simple PID regulating loops (previously implemented by analog controllers). They also interface the computers to sensors (RTD's, pressure transducers, etc) and perform alarm checking.

Economic constraints define a minimum acceptable size for these controllers. Hence, a controller may support many individual systems. Alternately, elements of a given system may be widely dispersed geographically, (e.g. handswitches in the control room, valves containment) hence individual system may require multiple controllers. For these reasons the controllers must be able to communicate amongst themselves as well as with the control computers.

Alarm annunciation is also a critical function for unit operation and is supported by dual computers similiar to the control functions, (see figure 4) As in the current design, the operator interface (e.g. CRT's, keyboards, etc) are connected to both computers.

Special attention must be paid to the maintenance of the computers and data highways, especially in light of the increased amount of hardware. Special tools to aid in fault detection and correction in both hardware and software are required. Therefore, an overall system supervisor function is supported by the maintenance/monitor computer. It scans all inputs, outputs and communications channel traffic and maintains a separate data base of this information. It is capable of generating alarms in the event of detected faults or when processing loads on a given computer, or the traffic on a given communications link exceeds preset thresholds.

The maintenance function provides software generation facilities (editor, compiler, etc). It also permits down loading of programs, data, and diagnostics from the Design Office (note the link to the Design Centre, figure 4). - 164 - UNIT CONTROL SYSTEM

CONTROL CONTROL X COMPUTER X COMPUTER Y CONTROL BUS

CHANNEL DATA HIGHWAYS

-D- -D-

-O- -D- -a-

ALARM ANNUNCIATION COMPUTERS VBUS

WBUS

MONITOR/MAINTENANCE & UTILITY PROCESSORS JLV TTv

W

COMMUNICATION LINK TO SIMULATOR

FIGURE 3 - 165 -

UNIT CONTROL SYSTEM

w PERIPHERAL PERIPHERAL BUS ALARM/ANNUN. ALAFWJANNUN. COMPUTER COMPUTER BUS V W

DATA BASE

ALARM CRT'S ANNUNCIATION WINDOWS

COLOUR GRAPHIC DISPLAYS

FUEL HANDLING CONSOLE TURBINE RUN-UP CONSOLE

I FUTURE MISCELLANEOUS i _ _ I CONSOLES | I

IX UTILITY COMPUTER IX MONITOR/MAINTENANCE COMPUTER

COMMUNICATION LINK TO DESIGN CENTRE FIGURE 4 - 166 -

FUTURE WORK

In conclusion, our proposed approach for the future computer system raises a number of implementation questions and challenges.

In specifying the Design Centre an in-depth analysis of current paperwork and design procedures is required. Coupled with this is a definition of an acceptable programming language to be used by the process control engineers.

Simulation of the unit is a large, and challenging task on its own.

In firming up our unit control configuration, we need to evaluate possible failure modes, and fault correction techniques. We need to quantify the capacity requirements of the field controllers and central computers.

The safety considerations associated with assigning many systems to one controller requires careful attention. There is an excellent opportunity here for research into "intelligent transducers" which could reduce the minimum economic size of the individual controllers and increase system diversity.

Solid-state controllers, capable of withstanding a LOCA, are very attractive since their application can reduce the cost of contai jnent penetrations considerably.

Identification and selection of the data highway and local computer networks communications technologies is key to the system. For on them, depends the success achieved in constructing a flexible system capable of accommodating new technologies in computers and peripherals throughout the life of the plant. - 167 -

SESSION 2 - REQUIREMENTS AND DESIGN CONSIDERATIONS - I - 168 -

THE DESIGN, DEVELOPMENT AND COMMISSIONING OF TWO DISTRIBUTED COMPUTER BASED BOILER CONTROL SYSTEMS

By

D. COLLIER, L.R. JOHNSTONE, S.T. PRINGLE, R.W. WALKER

INDEX

1. INTRODUCTION

2. SYSTEM DESIGN

3. CONTROL COMPUTERS

3.1 Memory

3.2 Actuator Drives

3.2.1 Stepper Motor Drives

3.2.2 Solenoid Operated Actuators

3.3 Auto/Manual Philosophy

3.4 Watchdog

4. MANAGEMENT COMPUTER ROLE

5. COMMUNICATION

6. SOFTWARE

7. REFURBISHMENT OF COMPUTER SYSTEMS

The work reported was carried out in the N.E. Region Scientific Services Department of the CEGB and the paper is published by permission of the Director General, N.E. Region, CEGB. - 169 -

1. INTRODUCTION

The CEGB N.E. Region has recently commissioned two major boiler control schemes using distributed computer control system.

Both systems have considerable development potential to allow modifications to meet changing operational requirements. The reason for this work being the increase in the amount of nuclear base load, the concentration of load regulation in large 500 MW units, and obsolescence of station ccntrol equipment.

The distributed approach to control was chosen in both instances so as to achieve high control system availability and as a method of easing the commiss ioning programmes.

Both systems may be compared by reference to the following table:-

TABLE 1

SKELTON GRANGE THORPE MARSH POWER STATION POWER STATION Unit Size 120MW 550MW Mo. or Controltlorinrs 5 Interface Equip. GEC MEDIA GEC MEDIA Comp type LSI 11 (Kratos Package) DEC PDP11/03 Supervisory Computer PDP11/34 PDP11/34 Control Distribution Computer 1 Feedwater Control k Mill control & Master Pressure 2 Steam temperature 5 Mill control 5 Draught Plant-Mill Feedwater controls Master Pressure () Steam temperatures D Master Pressure (Oil) Draught Plant Commissioning Over b months period Installation & Commissioning Period with Unit at load during 12 week outage & 2 weeks after outage. Other Points Display via VT30 system Connected to large logging & to operator display system (11/34) and Includes fault finding also to Alarm micro(6800) programs.

The experience gained with these two projects has reinforced the view that distributed computer systems show advantages over centralised single computers especially if software is designed for the distributed system. - 170 -

The inherent flexibility has allowed very rapid commissioning. At Thorpe Marsh the majority of computer systems were installed, hardware tested and commissioned against simple models during an outage for routine overhaul of 12 weeks duration. Upon unit start up computer control was immediately available and within two weeks all loops had been optimised for normal operation at a number of generated loads.

In the first 18 months of operation at Skelton Grange one computer and 2 interface card failures have occurred but the operators have had no problem in maintaining satisfactory manual control tor the time taken to replace the parts. The failure rate is in line with our experience and calculations of predicted oehaviuui. of the systems.

Most of the following paper is concerned with practical points gained from our experience and not with the overall philosophy of distributed control and to which we are committed. These advantages are reported elsewhere (1,2).

2. SYSTEM DESIGN

Both systems are of the star form with the management computer at the centre and the control computers connected by serial links to the centre (see fig.l).

The reasons for choosing this form of system stem from the design criteria established, coupled with the communication technology commercially available at the time of equipment purchase.

2.1 Design Criteria

The basic design problems of distributed systems are to determine how to distribute the system functions among the various computers, how to determine the number of computers, and to define the intercommunication loading between computers.

The basic criteria relating to the system are:-

2.1.1 Each computer controls an area of plant such that in the event of a computer failure the operator can maintain load on manual control without penalty other than the potential risk of operator maloperat ion.

2.1.2 Rach computer shall be capable of stand alone independent operation in the event of a communications failure or failure of the management computer.

Consideration was given to the plant control areas and decomposition of the control of these areas into the different compi:tere. A number of potential options of numbers of cotuput ers and distribution oi function were evaluated in the light of the two basic criteria and an option chosen. The distribution chosen for both systems is indicated in Table 1.

At this stage little reference was made to computer capabilities because previous DDC experience indicated that this was not a - 171 -

problem as the processing power of an LS111 with 32K words of memory was considered to be in excess of a minimum requirement even using the specialised high level language DDACS.

3. CONTROL COMPUTERS

The block diagram of a Skelton Grange target computer system is shown in Fig.l. Both distributed systems have essentially the same target computer systems there are however detail differences.

3.1 Memory

Both systems use MOS volatile memory and in order to preserve programs in the event of power supplies failure both systems use battery back up systems. The Thorpe Marsh system uses on-board battery back up and static RAM. Whereas the Skelton Grange System uses a separate battery supply unit for the dynamic RAM.

Both systems operate satisfactorily but the Skelton Grange system is more complex in that batteries are trickle charged, it has an automatic routine test of batteries by connection of a resistive load and monitoring of the voltage decay to determine the battery condition.

The onboard batteries are a cheaper solution. Due to the inherent high reliability of the batteries and the extremely low current drain when supporting the static CMOS memory (0.3 mA max.)a small amount of deterioration of the cells can be tolerated. Thus a policy of total cell replacement as a normal maintenance procedure after three years is sufficient to guarantee the availability of the memory at a level consistent with required reliability of the total system.

3.2 Actuator Drives

At Skelton Grange, all actuators use stepper motors, at Thorpe Marsh a further form of actuator drive is used, this is the solenoid operated actuator.

2.3.1 Stepper M^tor Drives

It is a CEGB standard requirement that in theevent of a failure of control equipment, that all valves and dampers freeze (there are some particular exceptions to this rule). The general method adopted to achieve this for pneumatic valve and damper drives is by the use of a stepper motor to act as a position reference with memory for the valve positioner.

Experience on power plant to date has shown that the stepper motor type used is very reliable and because they are lightly loaded consistent resolution of 1 step is normal. Typically valvas and dampers are arranged to have 2000 steps from end to end thus a resolution of 0.05% is achieved.

These steppers are driven at a fixed rate of 200 steps per second giving valve traverse times of 10 sec. - 172 -

3.2.2 Solenoid Operated Actuators

At Thorpe Marsh considerable thought has been given to the design of actuators for hydraulically operated dampers. Hydraulic actuators are expensive as they contain compTex internal valves and feedback mechanisms. Recently we have examined the use of a cheap robust hydraulic power rams operated by solenoid valves under computer control. The feedback being taken as position from the final element, such as damper spindle.

This technique then uses the computer to close the loop and maintain position control.

This technique works very well under most circumstances bur it can cause computer loading problems due to the high duty required to service these position controllers. Also when manual control is used the feedback mechanism does not exist so that drift could occur especially in asymmetrically loaded dampers with leaky solenoid valves. This problem has now been largely overcome by the inclusion of additional hydraulic components.

The obvious technique to overcome these problems is to use a separate micro computer with each actuator to maintain position control so that n.inu-^l inputs just alter input set point and so that the control computers are less heavily loaded. This is a development at present being actively pursued.

To minimise this undesirable behaviour at Thorpe Marsh a rigorous maintenance schedule to minimise leakage is at present carried out, along with definition of the normal operating condition as auto control and that manual control is only used during abnormal conditions.

3.3 Auto/Manual Philosophy

The two schemes differ in the way the computer systems interact with the operators desk. At Ske" m Grange the operator must request auto control, if the computer sy n accepts this request (ie plant is within control, range) then « computer pulls in a relay and controls tne stepper drive outputs. the computer then assesses whilst in Auto that a pjant constraint as been reached then the control action is inhibited the AUTO lamp is t hed and a message passed to the management computer for display. If a detectable plant failu:.v- occurs and no alternative control action is possible then the computer scheme trips the loop to MANUAL control.

Thus it may be stated that the MANUAL mode is the fall back condition and control cannot proceed from MANUAL to AUTO without operator selection. - 173 -

At Thorpe Marsh however to,AUTO mode is the normal condition and the transition from AUTO to MANUAL requires operator selection. If the control regime reaches a plant constraint or detectable failure occurs then control actions are frozen and the MANUAL lamp is flashed i.e. computer requesting MANUAL.

This second strategy was decided upon as confidence in the Skelton Grarge system developed and the techniques for failure detection were refined. The computer system is considered as a fully integrated part of the plant. There has also been a progression from set point inputs being via analogue potentiometers mounted on the desk at Skelton Grange to set points in general being entered via a Keyboard at Thorpe Marsh. More frequently changed set points such as st<=>am pressure are still by potentiometers and mounted on the desk. Entry via a Keyboard obviously saves costs on analogue inputs, outputs and reduces the size of desk layout.

The use of the computer to flash lamps on the desk is part of meeting the basic criteria in allowing stand alone operation. Normally the same signal is passed up to the management machine where it is displayed on a VDU as a plain language message. Loss of communication on the management computer means that the lamp flashing indicates constraint or failure condition which the operator must interpret from back panel meters and knowledge of the plant as the display system will no longer be functional.

3.4 Watchog

The Watchdogs in both system are identical and are designed to provide a fail safe response in the event of hardware and software failures.

The Watchdog is reset every 20ms by a signal of alternating l's and O's on

all data lines f' It will only respond if the reset signal is detected withir a window centred on 20ms and being 2ms wide.

The software provides support for the Watchdog and it is run at the fastest loop rate available ie.50Hz and as such it has high priority. Failure to reset the Watchdog causes the card to trip. It is wired to relays which in general isolate all digital outputs under a trip condition.

The clock signals for stepper motor drives are generated on the Watchdog card and loss of Watchdog reset also removes the clock signals and so freezes the stepper output drive.

This feature of synchronising the hardware and a software to the line frequency 50 Hz guarantee resolution to 1 step of the valve drive systems.

4. MANAGEMENT COMPUTER

The management computers have a number of roles which were defined at an early stage and are the same for each system.

These roles may be listed:- - 174 -

4.1 To support all peripheral device necessary for system operation. This helps ensure security of control computer by limiting access via the management computer.

4.2 To provide intercommunication between peripheral devices and plant control computers in order to allow the building, modifLcation and tuning of control schemes.

4.3 To hold master library copies of control schemes for use in the event of failure of MOS memory supplies and for documentary record purposes.

4.4 To monitor the behaviour of control computers and control schemer.. This allows access to plant limits, failure of hardware, status and alarms from control schemes within the management computer.

4.5 To process and output the. prime or derived signals to hard copy printers, to semigraphics VDU for operator display, and to store data on disk for record purposes.

4.6 To provide diagnostic aid programs to assist station engineers determine the location of faults.

4.7 To support supervisory control by sending set points or other variables to control computers.

4.8 To support the new CEGB standard realtime software system CUTLASS.

After due consideration of those requirements the management computers were specified as follows:—

DEC PDP 11/34 with 64 k v/ords core and 6^ k words MOS memory and floating point processor.

1 1.25 M byte removable cartridge disk 1 2.25 M byte fixed cartridge disk 1 Watchdog 1 Programmable real time clock 1 Clock/calendar module (battery backed) 1 Seraigraphics colour display driver 1 180 cps printer 1 30 cps printer and keyboard 2 VDU 1 Serial line to each target LSI 11

COMMUNICATION

In designing the communications systems there appears to be two distinct criteria which are basically unrelated which help define the connunications rate of links between computers.

It is important to note that the following discussion relates to an early stage in the projects before the CUTLASS software system was available. - 175 -

The original software produces alarm signals from the control computers that are two 10 bit characters which a rate of 2.4 k baud is equivalent to 120 alarm messages per second i.e. approximately 85ms per message.

5.1 The maximum acceptable response time from the initiation of alarm state to operator display anywhere in the system.

Closer examination of disk access time and overheads due to the DEC RSX executive indicate that this may be 0.7 sec. per alarm thus the communication links themselves could operate at 2.4 k baud and give a response time of 1 alarm per second.

5.2 The acceptable time taken to reload programs into the plant control computers in the event of memory corruptions due to power fail was defined at Skelton Grange as being 1 minute per computer.

So with a 28 k work memory of 16 bit words with 10 bits/byte then 9.6 k baud will reload in approximately 56 seconds.

So this second requirement appears to be more onerous and so a serial line of 9.6 k baud was chosen.

6. SOFTWARE

Over the past few years the N.E. Region of the CEGB has developed a high level engineer oriented language DDACS MCS for real time online control.

This software system is dependent on DEC computers (it is written in PAL) and was designed to be used in small stand alone installations.

Considerable experience has been gained in its use for control of power station plant.

Its main design feature being:-

a) Provision of all common modulating control functions as building blocks.

b) Provision for selectable control strategies.

c) Provision for inter control loop rjmmunication.

d) Bumpless transfers.

e) Automatic loop starting s( -ncing for time cascade systems.

f) Watchdog support.

g) Built in error checuing and fail safe response for input/output failures.

h) Automatic initialisation of inactive blocks when caused to run on branching in program. - 176 -

However a re-examination of the CEGB requirements for the whole range of online real time computing needs for th'fe next fifteen years or so, caused the definition cf a software system CUTLASS (Computer Users Technical Language And Software System) that is machine independent by being written in CORAL 66 and which is designed at the outset to accommodate distributed and hierarchical computer systems. The last objectives are achieved by the data structure (GLOBAL, COMMON, LOCAL) and a true communication package. In other respects CUTLASS has improved versions of the DDACS facilities.

At the time of writing (February 1980) the control programs at Skelton Grange are being converted to CUTLASS for the first on site trial (3).

An illustrative example in CUTLASS programs is included in FIG.2.

7. REFURBISHMENT OF AGR COMPUTER CONTROL SYSTEMS

In the long term the existing monolithic computer systems used at Hartlepool and Heysham AGR stations will require replacement due to obsolescence and thus maintainability of display equipment memory and backing store components.

It is important to realise these stations use DDC for all of the main control functions of the reactor and the boiler. Auto is the normal operational state and the manual control is not available.

Because of this essential role of the computer system refurbishment presents problems in commissioning, testing and gaining confidence in the new system. The use of a distributed system has advantages in the ability to commission independently the separate parts of the system without the problems of program interaction.

It is likely that the basic stragegy of refurbishment will be that individual functions will be implemented on separate computers running in parallel with the existing system but without control outputs connected. A test program will exercise the programs and a period of operation making comparisons between existing and replacement systems will occur to confirm the system operation.

The considerations relating to standby provision must be defined in detail but general principles have been considered:—

a) Increasing the number of computers within a distributed system is only valid to the point where the control function cannot be further decomposed. Thus further distribution places essential reliance upon intercommunication.

b) If however redundant information exists it is appropriate to have multiple functions contributing to a global data base such that failure of function only degrades the number of readings of a parameter available rather than basic control performance degradation.

Consequently as the multiple plant inputs are routed via different analogue scanners each one could be serviced by its own separate computer and whose output is a contribution to the global data base. - 177 -

c) The equivalent principle for output actions says that if more than one actuator affects a controlled plant variable the provision of a control computer per actuator can provide resilient control.

d) The application of the previous principles reduces the requirement of standby provision to a few areas where very high integrity is required. In the cases where standby is necessary the recomnended method is to use an identical computer system with cross linked watchdog interrupting their outputs.

The programs run continuously so the system is immediately available to take over control as required.

The likelihood of simultaneous software bugs occurring is low as the data to each program will be slightly different and timing difference will occur. Also the use of well tested and used software systems should also give confidence in the software reliability.

8. CONCLUSIONS Experience at two power stations of distributed boiler control system confirms that such systems have advantages over centralized computer control systems.

The advantages observed so far stem from ease of conmissioning, flexibility in modification of software, security and overall system reliability.

Experience has also shown that high level software system (such as CUTLASS) designed for use on distributed computer systems also contribute significantly to the advantages.

The design of distributed systems raises a number of interesting technical points which require solutions optimised to the architecture.

There is now every confidence in the philosophy of distributed computer control for power station application and guidelines are being developed to assist in the application ac new stations and refurbishment at conventional and nuclear plant.

9. REFERENCES

1. Johnstone, Marsland & Pringle, "A distributed control system of a 120MW Boiler" IEE Conf. Proc. No.153 1977. 2. Johnstone & Marsland "Distributed Computer Control for Power Station Plant". Electronics & Power 24, P373-378.

3. Brown & Walker "COMPASS - An Engineer Orientated Computer On-line Multipurpose Application Software System" IEE Conf. Proc. "trends in On-line Computer Control SYS1'1 1979. The name COMPASS has been changed to CUTLASS for copyright reasons. - 178 -

FIXED DISC 2.5M Byte

DISC PROGRA WATCH 123 x SERIAL •A WORD REMOVABLE UNIT -DOG I/O STOKE UNIT CARTRIDGE cn I Ut-IIBUS DISC

&-VYAY SERIAL |VT3O I 1 VDU uwn &SOO BAUD T±

SUB- SVSTEM FEEDWATftK SUB- SUB- SOB- SUB- SYSTEM SYSTEM SYSTEM SYSTEM 2SK LSI-ll SERIAL PS. WORDS PBO- NO 2 3 A, 5 STOGE MONITOR CËSSOR. USIIT TEMPER- AIR PRESSURE PE6SSURE - kTLJtie o/aus CCOAL) COlO 19 M "29 M 3OA.I 15*.! o/su 401 S3OI 2t Ol iGOl UNI- IÊDO 35OO 25 DO ISDO BUS 4S 7S as 35 UMIBUS

UNI-/ /MtDI^

MEDIA HIGHWAY

WATCH AVlt.LOâ ANALOG DIGITAL DIGITAL STSPPING -DOS INPUT OOTPUT INPUT OUTPUT M0TO9 ORIVC 8-o

SKELTOW GRAWGE FIG. SYSTEM BLOCK DIAGRAM CEGB CUTLfiSi ICHEME: ".HTEMPCOri TH."( : ftTTEMF 01 04 r PI : K RTTEMF PUM EVEPV c'500 M;EC: f \ 01 05 PEAL LDCflll oj 06 LOGIC COM: DECLARATIONS COMCONS 0107 PERL 0108 LOGIC VDt • T HDt • rnat • Toot

010? :TftPT

CtOOAt I.I 1 1 ij LOM::=HILIM OP LOI-ILIM DP 'Lai.iLIMlT 'I 0111 CDflSTPHIH COM: CONSTRAINT fill£ rOMCON" :=CDti:

HtViBV ZWOmS COMMON COMMON 0115 LDI:MD:=HH CONTHQLLER 0114 ftNDUT HETEP ££.

T 0115 EPPc::=T R-MIl | PP£•t •T I . Til. T AUNIVIHV *40-"S 01 le 'i'£ •" = IMC P11'. E P] 1 GlOBAl COMMON : 01 17 VOl : = ''•. p: o. ? ; • DP • v'p- n. C^-. o 11 s TRDt : = • Tfl'-O. ?:? . DP • TR-: U. Oil' • oi r? TDQI : = • Til -ii. ?ti • DP • TD 0. Oii'' PERMIT 01 cU TOD/ : = • TO 0. •?S • DP • TD- Ii. ij :• . AUTO nii'l pfl:=VDf TRDt TRDt RHI TDDt HMI TDDt ijl££ DI GOUT INPUT PR :LDT 44.1 J CLERP-I ET.CLERF

01 £ 3 ENDTFO

Figure 2. Part of Superheater Temperature Control Using CUTLASS DDC Language - 180 -

Condensate Clean Up Control System with Distributed DDC

by K. Yoshioka," T. Tazicia,* 0. Nakamura* S. Kobayashi,**

* TOShlbA CORPORATION, TOKYO, JAPAI! ** WA;;KDA UNIVERSITY, TOKYO, JAPAN

AI-S TRACT

In the operation of Condensate Clean Up System ii, bV,'R plants, regeneration intervals of the derr:inorali::er are not e'jua] and there i: no base to determine the interval which in usually decided by onera- tor's experience. Regeneration of resin is, t!v-refore , sometir.es performed too early remaining much capacity of resin unused.

r In order to improve such operation mode, follov,im . approach was mace (1) to equalize the operating tine difference of sequential two demineralizers (t]-to, t?~tl, ..., in Fie. 2) which is called as operating1 intervals in this pape^. (2) to control initial flov: for newly connected demin.'ralizer nrs now cne ha? IKSS flow, resulting higher flov: which makes further un- balance in flow between new and old lemineralizers in parallel operation

The economic and efficient operation of this system, along with the reduction of radioactive resins, and safety supervisory function, can be achieved by the distributed DDC with microprocessor' in the direc- tion of above approaches.

1. INTRODUCTION

The current Condensate Clean Up System in BWR plants consists of multi- dercineralizers as shown In Fig. 1. The system is not control- led in the flows of demi- neralizers and their oper- ating intervals are decided by operator's experience. Unequal flows i-s resulted as new demineralizer has ru r higher flow than the old ReactorQ.*rt** Feed water ones. Heater If their operating inter- vals are very short, the Condensaie Clean Up System operator regenerates the demineralizer by manual F p. 1 Condensate Clean Up System control in order to continue its operation, so they are regenerated with remained capacity. - 181 -

In addition, its system is usually operated with one si.are of demineralizer for regeneration to decide the termination at. which the first demineralizer should be switched to spare for regenera- tion and for this purpose, and the operator' calculates the Ion exchange quantity [difined as the product of conductivity difference (}jd5/cm) between inlet and outlet of the dernintrali v.<>r and flow (ton)J by himself which is considered to be troublesome and exhausting work for the operator. The current operating condition of demi- neralizers (8 normally in operation, 1 stand- Normal End Point by) is shown in Pig. 2. The each operating interval of them, (tl- tO, t2-tl,..., t8-t7), is not equal. As each Intervals is not controlled, the effect of Increase or 13 decrease in their flows and inlet conductivities that is, the distribu- tion of their ion ex- change quantities cannot to tt te £3 t* ts "" -*• Time be equalized by this Pig. 2 Time VS Ion Exchange Quantity operation mode. Therefore, except the random average disturbance, operating intervals of demineralizers are not equal. If any inter- val of two sequential demineralizes was very short, the latter demineralizer should reach the end point before the former has finished off its regeneration. In such a case, conductivity of clean up water returned to the reactor becomes higher which will give unfavorable effect to the plant operation. In order to avoid such condition, it is best that each of their Intervals at the end point should be controlled to be equal. Then, the system will be safety operated with higher end point ty making use of their remained capacities within the limit of its outlet conductivity than the current operation mode. The ion exchange quantity, ?T(t), is defined as

< M(t) = yLQ [Di(T) - D»(T)] X Q( T )dt (1) where, t time to time beginning to connect with Condensate Clean Up System

Dj( Z ) Inlet conductivity of demineralizers Do( 7 ) outlet conductivity of demineralizers Q(t) flow of demineralizers - 182 -

In case that the ion density of th>-water at t.he inlet of dcrp.inera- lizer is increased, it Is difficult, tc decide whether Its effect is due to the increase of flow or :• !'.]•• *. c uicuiu t i vi ty . ] f, is not easy, therefore, to prove the ef ra< :.zcv of the flow (Control on the equalizing operating Then, the cone -pi. shown in Fig. 3 has been adopted instead of '.>|t-ration :nede shown m Fig. 2. The liner,, a, b, ... h, show the integral flows of 8 demineralizers. End point_ Here, they should be depended on Inlet normally rep;eneratc?d at Conductivity t.he end point, Q(t)=Qm. If Dj_(t) is increased stepwise, the end point.. Qm, depended on the inlet conductivity, should fc? changed to the line (1) and (2) as shown in Fig. 3- The gradient of lines, a, b, ..., h, shows the flows of demlnera- to tt tz ti fi ts "" —"• Time lizer.,. Pig. 3 Tine vs Deminerali :•.«.'i'' s rlov: In this concept, we can express the two process variation, the con- ductivity {f* 15/cm) and integral flow (ton), separated. Therefore, the following analysis can be made in sample manner. ?.. SYSTEM ANALYSIS Even In the case that the Inlet conductivity of demineralizer? was Increase, their outlet conductivities are practically constant. From equation (1) M = (Di-Do)Q = [Di-Do(M)]Q dM = -QPo(M) + F dt where, F = Qz • Q xKT Actual Characteristic By the numerical analy- Calculation by E$.(2) sis of the equation (2), M(t), Characteristics of Time vs Ion Exchange Quantity in Fig. '4 are obtained. f 5.0 We can consider that the actual characteristics are nearly equivalent to 3J« the straight line. So, we can set the assumption as follows. 20 4.0 60 80 WO 120 140 —* Time [Hour ) Fig. Characteristics of Time vn Ion Exchange Quantity - 183 -

THE OUTLET CONDUCTIVITY IS CONSTANT IN CHARACTERISTICS OF ION EXCHANGE QUANTITY

Under this assumption, as the right side of equation (?) is constant, Characteristics of Ion Exchange Quantity respect of time is the straight line in the domain which the regeneration is possible, except the large scale leakage of sea water. Therefore, Time vs Ion Exchange Quantity is equivalent to Time vs Integral flow. Considering above correlation of Time vs Integral Flow, control of the flow of tiie demineralizers is the most appropriate for efficient opera- tion of the system. Concept for this operation is that: (1) for the demineralizer closer to the end point of its capacity should have a maximum possible flow. (2) for the demineralizer which has much capacity remained should have a lower initial flow to give wider flow control range. So we adopt the control approaches as follows. I) Minimize initial flow for newly connected demineralizer ii) Maximize the flow of other demineralizers This operating intervals for all demineralizers.

General Theory Nomenclatures used in this paper are as follows 1 2 3 4. 5 6 7 8

M: Life of a deminera- lizer (constant) a: initial flow b: Maximum flow T: Operating interval of demineralizers i: Operating interval number of deminera- lizer K: Number for a group of 8 demineralizers. N0.(K-/) NO. (K+l) Group

General Analysis Configulation

For the characteristics of first demineralizer in the group K, we obtain

IT 8 aT* + b( T.) = M (3) 1 1 = 2 For the characteristics of the second one, 8 x aT2 + b(i=3Ti + TlT^ ) = M from equation (3) and k+1 _ a (5) l b (1 - f) - 184 -

The some procedure will be applied for other derainerali^ers and similar seven equations will be obtained as follovs.

Tk+1 = a Tk _ a, k L2 b 2 b; 3 (6) Tk+1 _ a k n a.) T ^8 " b ^8 U " bJ l By defining X^ = T^ - T^ from equation ('j) and (6)

yk+l _ a Yk n a, J x1 _ _ X;L + (i - F) x

Yk+1 _ a Yk , X7 " b X7 a X8 IT LT If L' T1 1 and Also, by defining X = (X,, Xo_. •••, ^K- ^.V expressing a/b following time invariant discrete equation is obtained.

oC 1—P 0 o.

= Ax ( /

g(l-g), U-gT 0 -0

The constant operating interval of 8 demineralizers on steady state is equivalent to the condition that X^ converge to zero. If the eigenvalue is shown by A , following relation may be obtained.

(8) - 185 -

Therefore, the characteristic equation of A is obtained as

( A - g)8 - A (1-g)8 = 0 -(9) For example: from equation (a) for g=0,5, the eigenvalues, A , are 0.45 ± 0.47J 0.85 ± 0.37J (10 ) 1 0.16 + 0.26j 0.12 For simplicity, we consider the example of 3 demineralizers instead of obtaining the initial value for \ =1 in equation (7)«

k+1 g 1-g ° \ k X 0 g 1-g XK (11) g(l-g) (1-g)2 g / Her6 x 1° = 0 (12)' Their eigenvalues are A =1, j |(3g-l) - d-g) \ 4g-l j| where g <. 1. Therefore, | A ] < 1 on g

,-1 Pn P/2 P 13 2I ?2Z P23 det P V P3/ P 32 Pi3 We transfer the initial value satisfying equation >( ] 2) to Z by z°=p-ix°.

is obtained. It is clear that initial value for eigenvalue, A=l, is usually zero. - 186 -

Therefore, it will 12 assumed that THIS CONTROL SYSTEM IS OPARATED TO EQUALIZE THEIR OPERATING INTERVALS.

COMPUTER SIMULATION RESULTS The result of system analysis shows that the uncontrolled operating intervals are gradually averaged by controlling the demineralizer's flow. Then, in order to prove the analysis results of 8 demin^-ra- lizers, the following computer simulations were tried on the above- mentioned control approach. Simulation [1] ... Time vs Ion Exchange for random disturbance. <8)Input conditions (1) Normal inlet conductivity: 0.12 ^/cm (2) Change value of inlet conductivity: + 0.06, -0.03 " (3) Change mode of inlet conductivity: random mode (4) Outlet conductivity: 0.07 ^/cm (5) Ratio of the control flow (g=|): O.B67 (a

©Result -• We cannot of find which cause on flow or inlet conductivity is there in Fig. 6.

— \..' 1 ZS- . - £.- 1 " r _ . I . "JX-. -

Fig. 6 Time vs Ion Exchange Quantity for Random Disturbance

Simulation [2] ... Time vs Integral Flow for random disturbance ®Input conditions are the same as Simulation [1]. ^p , We can express the cause on flow as the gradient of their "* characteristics and the cause on inlet conductivity as their end point in Fig. 7. - 187 -

M* -=_-=J - -!-•—• .-i—_/• J-'J-\J 4=- U ->. f -'• 'ill - J" I. 3JJ "I Fig. 7 Time vs Integral Plow for Random Disturbance

Simulation [3] . . All equal controlled flow on each deminera- lizer. ©Input conditions (1) Normal inlet conductivity: 0.12 fV/cm (2) Change value of inlet conductivity: none (3) Change mode of inlet conductivity: none W) Outlet conductivity: 0.07 M&/cm (5) Ratio of controlled flow (g=a/b): 1 All equal flow

©Result • Its previous distribution in operating intervals is not averaged in Fig. 8.

I I " "H- •• -I- •-!•' •• 17 Z7 Ip ZT ~J' ~J ~J " J~ ~ J J,J J J J J J J ~JD O~ J Fig. 8 Time vs Integral Flow in case of All Equal Controlled Flow Simulation [4] ®Input conditions The same as Simulation [3] except ratio of control flow (5) Ratio of control flow (g=a/b): 0.867 (a

~7 J 71

Fig. 9 Time vs Integral Flow in such flow as a

Process Computer System: Provide informa- tion processing and high-level £30 CRT for an entire Loop Station Console system. Complete with CRT display DDC Station intended for a Mini operator one-man control Console system. Multiplex: is provided for hltiplex an overall pro- Flow 4 duction system. Control Access Station (DDAS): Process A data transmiss- Computer ion unit for con- centrated manage- t t Process Vo Station *• ment of the TOSDIC System. Sequence Control DDC Station (DDCS) with the built-in Note; microprocessor up to 8 ]oops can be OMultiplex: controlled. 200m max length Process I/O Station (PIOS): 2)MinioperaUr Process noncontrol Console : option variables. 3) * Sign : includes Loop Station (DDLS Capable of microprocessor. effecting the same operation Pig. 10 Condensate Clean Up Control System and monitoring Configulation with Distributed DDC as those by con- ventional analog controller. Notation 1: Manual operation 2: Instrumentation control panel level 3: Local console-concentrated level (Medium-scaled instrumentation) 4: Computer hierarachy control level (Overall instrumentation control system) - 190 -

5. CONCLUSION The features of the control system discussed in this paper are as follows: 1. More Economical Operation for Condensate Clean Up System As the end point for regeneration can be extended by the control method described in this paper, average operating intervals for demineralizers will be longer than the current uncontrolled system. If the maximum flow of demineralisers were designed to handle excess flow due to the flow decrease for newly connected deir.ineralizer, number of operating demineralizer could be reduced or could have more operating capacity than current system.

2. Decrease of Radioactive Waste The regenerative operation will be decreased on the same reason as above. The consumption of acid and alkaline for regeneration is also decreased as compared with the current operation mode. In addition, this radioactive waste is ordinarily send to the R/W equipments, so it is easily controlled.

3. Improve Operability of the System Operators obtain the ion exchange quantities by calculating from the flow and conductivity difference between the inlet and outlet of demineralizer in the current system, but their quantities will be directly indicated by the distributed microprocessor in the improved system. In addition the operators can remotely super- vise the operating conditions by multiplex transmission and watch concentrately informations combined together with other technical informations by a CRT display unit.

4. Safe Supervisory Function Advantage of digital processing is fully utilized by distributed microprocessor system "TOSDIC" for various safety control steps which formerly were not practically obtainable from analog instrumentation. The added safely management includes a func- tional check by validity of sensors, upper/lower alarm limits, rate of change alarm and deviation alarm. - 191 -

REFERENCE:

1) L.I. Rozonoer: "L.S. Pontryagin Maximum Principle in the Theory of Optimum Systems I" Automation & Remote Control vol.20, pp.1291 - 1293 from 1288/1302

2) . ii ii" vol.20, pp.1407 - 1^09 from 1405/1421

3) Reference Manual of TOSHIBA DIGITAL INSTRUMENTATION AND CONTROL SYSTEM - 192 -

THE NORTHEAST UTILITIES GENERIC PLANT COMPUTER SYSTEM

K. J. Spltzner Mortheast Utilities Service Company Hartford, Connecticut

ABSTRACT computer configuration was necessary to achieve system objectives. A variety of computer manufacturer's equipment monitors plant systems in Northeast Utilities' (NU) nu- Redundancy was not a requirement initially, but clear and fossil power plants. The hardware configura- since most of the multiple components needed to achieve tion and the application software in each of these sys- redundancy were already present, and it was thought tems are essentially one of a kind. Over the next few that this capability may be required in the future, it years these computer systems will be replaced by the NU was built in from the start. The concept is one of Generic S>.*tem, whose prototype is under development pairing computers for load-sharing redundancy. Over now for Millstone III, an 1150 Hwe Pressurized Hater the years, a changing regulatory climate, and more re- Reactor plant being constructed in Waterford, Connecti- cently the effects of Three Mile Island, have bom out cut. Tliis paper discusses the Millstone III computer the wisdom of this decision. system design, concentrating on the special problems inherent in a distributed system configuration such as System Highlights this. Some of the features of the system are: INTRODUCTION 1200 analog inputs, all scanned in 3 seconds. 3456 digital inputs, all scanned in 4 milli- The Generic Approach to plant computers evolved seconds. from a need to standardize because of economic and time Redundancy. No single failure of e computer, constraints. NU was simultaneously faced with develop- a communications link, a disk, a bulk core ing a new plant computer system for Millstone III and unit, or a color-graphics subsystem prevents the replacements of aging computer systems in three nu- the operator from obtaining plant data. clear and two fossil power plants. The need for a new System data base on bulk core shared by host approach resulted in the Generic System concept which computers, for high speed access. is distinguished by two characteristics: Communications capability to off-site IBM 370/ 3033 at the headquarters Engineering Computer Standardized hardware configuration. Center, and with other dedicated microproces- A highly modular configuration was developed sor and minicomputer systems in the plant. allowing the tailoring of a system to a spec- Man-machine interface incorporating color- ific plant's needs by simply removing modules graphics hardware. from, or adding modules to, the basic design. Magnetic tape units for the saving of all plant A benefit of this approach is a reduction in events for later analysis. maintenance expenses through equipment com- monality. These features will be discussed in more detail in Standardized scan, log and alarm software. appropriate sections of this paper. A major portion of the application software, collectively called the scan, log and alarm Satellite Computers and Process Equipment software, is very similar from plant to plant. Designing this software with transportability The satellite system consists of the following in mind can result in significant cost and hardware: time savings. 6 Modular Computer Systems, Inc. (Modcomp) 11/26, 16-bit computers with 64K words of The Millstone III computer system, the first Gen- core memory and hardware floating point. eric System, is presently undergoing software develop- 18 Modcomp 1725 Wide Range Analog Input Subsys- ment at NU headquarters in Berlin, Connecticut. tems. 6 Modcomp 1199 Input/Output (I/O) Interfaces SYSTEM HARDWARE for digital I/O and analog outputs. 6 5213 I/O Bus Switches. Why Distributed? 12 4701 Interval Timers. The Millstone III Plant Computer System configur- Analog and digital inputs are evenly distributed ation is shown in the attached figure. The distributed- over the six satellite computers which allows the scan- hierarchical design has not changed significantly since ning software to be exactly alike in all satellites. early 1975. At that time NU had limited experience with The remaining process I/O equipment, because of limited a distributed system for Millstone II, where a front end quantities, is connected to specific satellites as computer to an IBM 1800 was used exclusively for digital shown in the attached figure. Controllers for each of input (DI) scanning of 2300 points in 8 milliseconds. the six sets of process I/O hardware are. connected to Millstone III requires the scanning of all 3500 digital I/O bus switches which can be switched manually, or Inputs in 4 milliseconds. All 1200 analog inputs (AI) under program control, to either of two satellite com- will be scanned every 3 seconds, and engineering units puters. The satellites, therefore, operate In pairs, conversion and limit checking will be performed by the normally sharing the process I/O burden. In case of a front end computers. The power of the host computers computer failure, redundancy is achieved through the is reserved for data base management, control of system remaining computer of a pair, which is designed to per- resources and number crunching. Clearly, a distributed form double duty. - 193 -

Network Communications computer data base. Modem for remote terminal access. Communication between satellite and host comput- ers is performed over 12 high speed serial coax links. SYSTEM OPERATION Data transmission is synchronous at word transfer rates of up to 125Khz. Remote fill capability allows satel- The Operating System software supplied with the lite program loading to be initiated at the host com- system by Modcomp consists of MAX III/MAXNET III for puters. Satellite console initiated fill is also sup- the satellite computers and MAX IV/MAXNET IV for the ported. The same type of link is also used for host host computers. MAXNET is a superset of the MAX oper- to host communications. ating systems adding network communications capability to the basic software. Host Computers Several custom software ^emencs listed below The host system consists of the following hard- were also included. ware: Special IBM HASP workstation terminal emulator. 2 Modcomp Classic 7870 32-bit computers with Special communications handler to support a 256K words of error correcting MOS memory, dial-up modem for remote terminal access. high speed 64-bit parallel floating point Special I/O handler to support the Aydin color processor, and 3 I/O busses. graphics system. 2 Modcomu Memory Plus (M+) bulk core storage units, 256K words each, dual-ported. All application software described in subsequent sec- 2 Ampex 88 M-byte disc drives. tions was written by NU. 2 GE Terminet 30 Console typers. 4 4903 and 2 4905 Peripheral Controller Inter- Data acquisition and a limited amount of data pro- faces. cessing are performed at the satellite level. Period- 2 4906 and 4 5215 Peripheral Controller ically this data is shipped via Modcomp network soft- Switches. ware through Host B to M+., the location of the system 2 4701 Interval Timers. high speed data base. Further data analysis is sub- 1 4821 Communications Link. sequently performed in Host A where all tasks requir- 2 5198 IEEE-488 I/O Subsystems for system ing data base access reside. Host level peripherals timing. are normally in the AUTO mode, and by software switched 1 Chronolog Clock to establish system time. to Host A. Host B, in addition to acting as the satel- lite data concentrator, controls and synchronizes the Overall system control is handled at the host complete system. computer level, including system timing. Digital Input in the Satellite Computers Man-Machine Interface Every 4 milliseconds Host Computer B simultaneous- Two Aydin 5215 Display Generators driving six ly interrupts all six satellites and a DI scan is in- color Cathode Ray Tubes (CRT), four keyboards and four itiated. A satellite collects the status information GE Terminet 340 line printers make up the man-machine on its process 1/0 group, compares this with the prev- interface. Three of the CRT's, with 25-inch screens, ious scan's data, and starts building a buffer which are mounted in the main control board of the control ultimately holds change in state information of 250 room. A switchable keyboard, also on the control scans covering a period of 1 second. The buffer con- board, can address any of these CRT's. In addition, tains the following information: the operator has available to him an operator's con- sole consisting of a 19-inch color CRT, and a dedica- Buffer size. ted keyboard with trackball cursor control. The re- Time of day in hours, minutes, seconds and actor engineer's and the shift supervisor's consoles milliseconds. are similar to the operator's console. Either display A header containing counts of attempts and generator can be connected manually, or under program failures in shipping this buffer to the host. control, to either host computer. The four hard-copy Time stamp V"'t information indicating during devices, 300 lpm line printers, are used as log, which of ci.e 250 scans changes in state oc- alarm, trend and special reports printers. curred. This is used later to speed up sor- ting of the data from six satellites in host Peripheral Equipment computers. Actual status of all inputs during the 250th The remaining system peripherals, connected to scan. the hosts through peripheral switches, consist of the Change in state data consisting of the scan following: number, the satellite number, and the number 1 Card reader, 300 cpm. of changes in state this scan, followed by 1 Data link to the headquarters Engineering the point numbers, and actual status informa- Computer Center IBM 370/3033. A software tion on these points. package is used to emulate the functions Change in state data as above for subsequent of an IBM HASP workstation remote job scans. entry terminal. 1 Line printer, 600 lpm. At the end of the 1-second period, this buffer is 2 WANGCO, 9 track, 45 ips, 1600 bpi magnetic shipped to Host Computer B, which acts as the DI data tape drives used to make save-tapes of sys- concentrator, via Modcomp network software. While it tem software and for storage of plant his- is being shipped, a second buffer is starting Co be torical data. filled with change in state information of the next 5 ADDS interactive CRT terminals are presently second. This double buffering continues, with one used for program development. When the buffer used for even second scans, and the other for plant is operational two will be installed odd second scans. In the health physics and chemistry labora- tories for inforaatiou .access to. the plane Two other DI features are a slow scan and the - 194 -

filtering of oscillating points. The slow scan allows table is then constructed consisting of the voltage the scanning of designated inputs at 100 milliseconds values, the engineering units values, and the alarm rather than 4 milliseconds. As many points as desired flag table and is shipped through Host B to M+ every can be dynamically entered into this slow scan group. three seconds.

The filtering of oscillating inputs is invoked An additional feature of AI is an Open Circuit when there are more than n successive changes in Detection (OCD) scheme seleetable for any input, but state during a one second reporting interval, where n usually applied only to low source impedance inputs. is a user entered number initially set to 5. A flag Three points per satellite, one from each analog con- is then set in the nth change in state entry and any troller, can be checked during every 3 second scan. additional ones are ignored for the remaining scans of If a bad input is detected, the point is taken out of that second. A new counting interval starts with the scan and a warning message is issued to the plant oper- following second. ator.

Digital Input in the Host Computers Analog Input in the Host Computers

Every second the satellites send DI data through A task in Host A updates the voltage and engi- Host B to six dedicated M+ partitions. Kach partition neering units values in the data base and, based or is further divided into an area for even scan data informat ion in the alarm flag tables, performs the and an area for odd scan data, thus providing double final limit check. Alarm messages are sent to the buffering. Host A then performs all remaining DI data alarm CRT, the alarm printer and output to a K+ buffer. processing, consisting of the saving of all changes Similar to DI, the M+ buffer is copied to disk when in state at a 4 millisecond resolution, and the re- full, and ultimacely to magnetic tape for historical porting of changes in state at a one second resolution. storage and later analysis.

As the result of an interrupt from Host B, a Man-Machine Interface task, is activated in Host A to sort, in time sequence, all 4 millisecond change in state information out of Plant operator/reactor engineer interface opera- the si?: partitions. Since it is historical data, tion can be divided into three areas. First, 55 key- possibly voluminous, to be saved for later analysis, board function keys are available to activate, abort, an efficient means must be employed to get the infor- or resume application tasks. Most are dedicated to mation op. to the final storage media which is magnetic the demand execution of various performance, test, re- tape. For that purpose the stored data is first ac- port, or display programs. cumulated in a 128 word global common table. When this table is full, it is transferred to a double Second, an Interface language was written for the buffered M+ partition which has the capacity to hold manipulation and displaying of certain data base para- 46 of these data tables. When this partition is full, meters or groups of parameters. It includes changing data is in turn written to both disks, again employ- limits, substituting values, deleting/restoring to ing double buffering. These disk areas, 21,000 sec- scan, building trend groups, or displaying graphic tors long, are then dumped to tapo on demand or when pictures, to name a few. full. Data analysis is in an off-line mode with the operator having to enter a window consisting of date, Third, a special software package was developed start time and end time for which he wants the infor- for the on—line building or modifying of color-graphic mation to be listed. displays. This "picture compiler" allows the construc- tion of a static background picture and the addition The sorting task also saves the actual status of of dynamic components to this background. Frequently all inputs, as determined by the 250th scan of each used dynamic symbols, like valves and pumps, for in- second, in global common. This data is then compared stance, can be selected from a shape library. to the past second's data and any changes in state are reported to the operator. The one second resolu- System Tiroe Synchronization tion was chosen to eliminate nuisance printouts due to noisy inputs. The Chronolog Clock supplies time of day informa- tion in BCD format to each host computer as read in The treatment of oscillating DI points at the through the host I/O subsystems. Further, the clock host level consists of keeping track of flags set by issues 1 millisecond interrupts to each host which es- the satellites. If a point is flagged for more than tablishes the basic system timing. During normal oper- three consecutive 1-second scan periods, it is auto- ation Host B acts as the synchronizer and uses digital matically removed from scan and the plant operator is output, by means of its 1/0 subsystem, to control and notified. synchronize all six satellite computers. Every <4 mil- liseconds the satellites are interrupted to start a Analog Input in the Satellite Computers DI scan, and each second, time of day information is broadcast to the satellites. Analog Input scanning, performed every three seconds, is controlled by scan tables consisting of FAILOVER one word entries per input point, specifying the gain setting, automatic gain ranging or not, and the point A significant portion of application software is number, and must be in compressed format. If a point necessary to detect and recover from device failures. is added or deleted from scan, the selection word The major components considered in the failure scheme must be inserted or deleted in the appropriate spot are the host computers, disks, M+, satellite computers and the scan table expanded or compressed. and communications links.

After all raw analog values have been obtained, Central to host level failover is a special part- the processing begins with the conversion to voltage ition on each M+ unit (primary and secondary), vhich and engineering units values. Alarm limit checking, contains counters for host to host failover and flags based on engineering units, is also performed and for each FORTRAN accessible random access file. For alarm violations are flagged. An analog trans . :ion failover purposes, each host writes its information - 195 -

to a dedicated sector on the partition. Data in both M+ Failure sectors is continually being updated. Again, a number of different failure modes exist. During normal operation any task writing to the They are: data base executes in Host A. Also, all peripherals are normally switched to the AUTO mode and software- 1. DI raw data shipment connected to Host A. Host B acts as the satellite Host B is the recipient of the raw Dl data data concentrator and controls system time synchroni- sent by the satellite. The clocking task, zation . alsc running in Host B, determines which M+ partitions can expect raw data and informs Host Failure Host A accordingly. Host A does all further analysis of this data. This host, which had Every second, while each host updates its counters set the first word in each partition to a -1 and flags in the special M+ partition, it also tries after the last successful shipment, tests if reading the other host's sector to check if it is this checkword has been overlaid by new data. If the read can be performed, but no new data doing the same. is present, the secondary partition is simi- Case A. larly tried. A failure in this operation is followed by a test of Host B's status. A If a host is able to road the primary parti- positive test indicates that Host B is able tion, but finds it has not been updated, it to take over the data base functions and Host also reads the secondary partition. If this A subsequently stops its timer, killing it- has not been updated either, the checking self. If Most B cannot take over, a message process is repeated twice more. Subsequent is written to the operator and Host A must failures indicate Chat the other host is dead, try to keep going. its load will be shifted to the still active In case the read of the checkword cannot be host, and the plant operator will be notified. performed frjm either partition, Host B's status is checked and action is taken as ex- If a host is not able to read the other host's plained above. primary or secondary partitions directly, it will attempt the read across the host to host link and 2. AI Data Shipment through the other host. The following three variations This operation is basically the same as the exist in this case: DI data shipment detailed above.

Case B. 3. SPECREAD/SPECURITE SPECREAD and SPECWRITE are user routines con- If the other host's partition can be read trolling all FORTRAN access of tH- data files. over the link and if this data is being up- A device online check is always performed on dated, then the other host must be alive, the addressed partition first, and if offline, but the testing host cannot read M+. The the secondary partition is checked. If the testing host subsequeitly kills itself by secondary is offline also, the host stops its stopping its timer controlling task execu- timers killing itself when the other host is tions, thus halting any further updating alive, but it tries to continue operating if o'f its partition. This creates a Case A the other host is found to be dead. situation and failover will proceed accord- ingly. SPECWRITE always writes to both the primary and secondary partition. For each FORTRAN" Case c. file written to, a bit is set or reset in the special M+ partition reserved for failover If the other host's partition can be read status information depending on the success over the link but the data is not being up- or failure of the operation. If neither par- dated, the read Is repeated twice. No action tition can be written to, the condition is is taken as the result of further unsuccess- similar to the device offline condition above ful tests, because the other host must be and action is taken accordingly. hurting, but a message is output to the opera- tor. SPECREAD initially checks if the last write operation to the partition addressed was suc- Case D. cessful, and then tries to perform the read operation. If either is negative, both oper- If the other host's partition cannot be read ations are repeated on the secondary parti- over the link, the other host is assumed to tion. A failure indicates again an offline be dead. The testing host must therefore keep type condition and the above scenario is re- itself alive. A message is written to the op- peated. erator in this case. 4. Tasks on M+ Disk Failure If a task cannot be loaded from the primary M+ load module file, global assignments are The two disks contain the same data files and load changed to the partition name of the secondary module files, but each one can only be addressed by its Mt- unit and the operation is repeated. A respective host. For a critical function, therefore, failure in this operation again reverts back a disk failure is treated like a host failure and ap- to a condition similar to the device offline propriate action is taken as explained above. For non- state. critical functions the user must decide how Co proceed, and in most cases only a message is issued to the oper- ator. - 196 -

E at ellite Failure

Normal frontend operation has each satellite scanning its own process equipment and all bus switches in the AUTO (programmable) mode. Each satellite of a pair is interrupted by its partner once a second, and during the resulting execution of an interrupt handler, a counter is set to 4. Tasks in each satellite then decrement this counter by one every second. If the count goes to zero, the other satellite is considered to be dead. The good satellite subsequently switches the other's process equipment to itself if possible, doubling its load. AI will continue to be scanned in 3 seconds, DI, however, will degrade to an effective 8 millisecond scan by the satellite alternating the scanning of its process equipment with that of the bad satellite every 4 milliseconds.

if the bus switch of the suspect computer is in the manual mode, no action can be taken, but a message is written to the operator.

Communications Link Failure

Satellites can be booted and tasks can be loaded from either host computer across the redundant links. A link failure will therefore not prevent satellite startup.

Shipping of the DI and A! data normally occurs to Host B. If this is not successful, the data is sent across the second link to Host A.

Time Synchronization Failure

During normal operation a task in Host B controls system timing and synchronizes all satellites based on ciironolog clock information. This task also contin- ually monitors the operation of the clock, the 4701 interval timer which acts as the back-up timer, and the host I/O subsystem. In case of a clock failure, the back-up timer is utilized. If the I/O subsystem fails, the redundant subsystem will take over, and if Host B fails, Host A will continue the system timing function.

CONCLUSION

Anticipated regulatory changes brought on by Throe Mile Island will have far reaching effects on future plant computer designs. Redundancy, greater computing power, communications capability and ease of system expansion will constitute some of the design objectives. The Generic System, developed for Mill- stone III and the replacement of existing plant compu- ters, provides the foundation for meeting these, future requirements. - 197 -

PROCESS I/O

tOO OTS S7i PTS (O PT1 300 I 5?» PT5 4t PTS

r ! DiQir»L &MALOO AHALOg 0>Sl *L • ULSt INPUTS SUiSrSTEM SUBStSTEM SUBSVSTCU SUBSrjTin sutsrjrty

SATELLITE COMPUTE* * 4 ~AI AND OX HANDLING CAPABILITY

cownw. ANO TO SATELLITES SSSJS

SECTION 1 INPUTS ItOO DIGITAL INPUTS MM anAt_O0 OUTPUT 10 OHITAL OUTPUT Ji PULSE MPUTB 4S

NMTKMT imUTB KMCE Cl

MODEM —FOR REMOTE RMIHAL »CCE»J MILLSTONE POINT UNITES COMPUTER SYSTEM C0NF6URATI0N - 198 -

DESIGN CONCEPTS WO EXPERIENCE IN THE APPLICATION OF DISTRIBUTED COMPUTING TD THE CONTROL OF LARGE CF,GB POWER PLANT

By 3 N Wallace, CECB, 5outh Western Region, Bristol, England.

1- INTRODUCTION

With the ever increasing price of fossil fuels it become obvious durinq the 197O's that Dembroke Power Station (4 x 500MW oil fired) and Power Station (4 x 50DMW coal fired) were going to operate flexibly with many units two-shifting frequently. The region was also expecting to refurbish nuclear plant in the 1980'a. Baaed on previous experience with mini-computers, the region initiated a research/development proqramme aimed at refitting Pembroke and Didcot using distributed computer techniques that were also broadly applicable to nuclear pJant* Major schemes haws now been implemented at Pembroke and Didcot for plant condition iRonitoring, control and display. At the tine of writing all computers on two units at each station are now functional with a third unit currently being set to work.

This paper aims to outline the generic technical aspects of these schemes, describe the implementation strateqy adopted and develop some thoughts on • . nuclear power plant applications.

2. THE DISTRIBUTED COMPUTER CONTRDt/HOWlTnaiNC/DlSPLAY SYSTEMS AT PEMBROKE ASP

2.1 S1 stem Keguirements

In examining the various solutions available for a new control/monitciring/dlapley systems at Pembroke and Didcot) a number of ba3ic requirements were identified. These included:

Performance The need For a system capable of hiqh control performance to ensure minimum plant damage end environmental problems whilst meeting the new demanding operating regimes.

Flexibility The need for a system that could cope with a variety of problems, encompass new developments as they arose and allowed further system expansion in the future.

Integrity and Reliability Important requirements were that there should be no sinqle coint failures, that the system should be designed around a fail safe philosophy and that a3 hardware failed the system oerformance should oeqrade gently.

Hardware ft general requirement was that the hardware purchased should be commercially availaDle. The amount of special purpose hardware wa3 therefore to be minimised.

Ease of Commissioning The system had to be caoable of 'jeing developed and commissioned on a piecemeal basis since the 500MW units were fully operational. Vo specific planned outage time was available since thi3 would have considerably increased total scheme noat.

Ease of Hainfrenance/Traininq The system was required to be fully maintainable by station staff with limited training or specialist skills. Spares holding and availability were also crucial considerations.

Project Timescales/Cost Project timescale and coat are inextricably linked. A svstem capable of rapid installation, development, commissioning and refinement vas therefore needed, Timescale was also important because of the rapidly approaching need to 2 shift the units without incurring plant damage.

Parallel Experimental Development In view of the project tfmescales and complexity of the performance problems there was a requirement thet The system should permit small scale experimental -work to be incorporated directly into the main scheme.

South Western Region viewed the above from a background of experience on Power Stations with stand alone mini- computer systems. It was clear that a distributed computer based control/display svstem supporting a high level, engineer orientated software system was the only feasible solution. The system described in subsequent sections is a direct conseauence of this conclusion.

2.2 pygtem Design

The eventual design for each boiler/turbine unit at Pembroke called for five interconnected computers' arranged in derarchical fashion {Fig.l(a)) whilst at Didcot (Fig.Kb)) a ring structure was adopted. In the liqht of the system requirements identified above the following key technical discussions were made:

Hardware Modularity All computers were tD identical in fora in orc!er to minimise maintenance, trainina end spares problems. Function or" each computer was to be determined by software olu3 the plant input/outDut connections.

functional Distribution It «83 known *.hat T>e fewer loops per computer the smaller the effect of failure. However, economics prevailed to the extent .hat each plant area was allocated one computer. In addition, at Pembroke a fourth computer was allocated the dual functions of primcry control displays and unit supervisory control. Since all plant area computers displayed th-:.ir data via the unit supervisor it was felt that a bock uc display computer should also be incorporated. Hbvinq no control function to perfoiTt it was thus also aoie to act as system host and plant condition monitor. - 199 -

Incremental Actuator "rives An incremental system usino stepper rotors drivinq Z/° or F/H convectors mas selected because of the natural freeze on fail characteristics. To avoid plant area computer processor overloat individual steoper motor drive carets were incoroorated. These >erc 1 bit viicroorocessor based and provided with niuitol I/O posts and 2 dedicated ADC's. Individually cowered 'ran the secure 51V r>C battery supplv they were desiqned to give moderate performance, sinale looo Dock- 'jp control in the event of plant area comouter failure. This ensured that 2 shiftinq without extreme nlnnt transients was nuaranteed.

iTommunicot ions In any distributed svotem an inter orocessor communications cvstem is a necessity. Serial data transfer at up to °.6K baud rhut in practice 4.8K baud) wes selected because of its fail safe charocteristics. insensitivity to cable run lenaths and capability for ruture expansion. Rosic data communication was hBsed at Pembroke on a ooint to ooint arrangement with the unit supervisor at the data centre collector/distributor. However a serial bus linking all computers to the plant monitor ho3t provided a back uo data transfer path for display purposes. Thia serial bu3 was also desiqned to carry all hosted software loading and oroqramme amendment activities. The flidcot system was constructed on a rina basis because or" the hioher monitorinq/ display requirements.

nisolav qnd Command A ma.ior innovation in the scheme was 'he intention to orovide operators with a much improved dai.3 disDiay via the twin coluur VDU's a**J a wide range of command facilities via multiplexed pushbuttons mountea in modular 72mm DIN qrid plaques. These pushbuttons were designed to assert ooto isolated diqital inputs and their function was to be determined by application software within each computer. As a matter of policy all desk modules were purely passive, includinq the computer/standby manual actuator drive plaque3. Potentially hiqh reliability and flexibility were key factors in this decision.

Software Previous experience with a variety of software systems/approaches led h.o the conclusion that the use of a simple, efficient, high lovef, multi task software system containing a range of 'uncrashable' general purpose statements was an optimum method of develooina integrated control, monitoring and display systems. An enhanced nultiprocessor version of existing software was therefore develooed and used by a variety of engineers to test the equipment and subsequently set it to wort.-.

The svstem design outlined above resulted in the functional hierarchy oortrayed in Fig.2(a).

.3 T-"ical °lant Area Computer 5v3tem

Inalonue plant data is obtained throuoh a 64 channel scanner «ith a 2HH channel/second caoabilitv. [n practice, a lower scon rate is employed, with the ADC integrating over a full nains evele ?o live good supply freauencv noise rejection. Solid state incut selectors are used throughout the control c&mouters whilst reeos are used for low level 3iqnals with variable common mode signal level. 50V dc statu3 sionais are sensed ana controlled by the comouter using opto isolated status inputs and reed relay isolated output cards.

°lant area comouter required to orovide displays have a solid state display interface and 32K ,'or 64K! solid date backing store for storina disolav aeneretion programmes and data.

Control outouts to plant actuators go through a high integrity outDut interface -hich is described in more detail in 5ection 2.4.

2.A Typical Intelligent Actuator ^rive Card

The only oiece of hardware that was not commercially available was the actuator drive card shown in Fia.'Ka). Each is individually powered from the secure 50V dc supply and is desiqned to drive a two pnase stepper motor using series resistors and 5tlV de supply. Opto isolation is used throuqhout to ensure non-interaction with other cards and signals. Two phase stepper motors were incorporated into the E/M 3nd F/p converters in order that a totally passive standby manual driive could be implemented. Whenever the card watchdog drops out 'bringing a rla3hing supply to the 5M plague 'computer fail' button) or the 'computer fail' button is depressed the changeover relav isolates the steoper motor from the card and incorporates a ohasino caoacitor across the stepper motor. The standby manual piaoues raise/lower buttons then merely apply 2&AC to one stepner motoo ohasi and the motor rotates in the appropriate direction.

The card was originally conceived as a device ""or minimising ISI-ll CP" utilisation whencirivir.g multiple 'up to 14) stepper motors. However, merely by adding the two floating ADC's and opto isolated lioitai I/O an intelligent backup controller was obtained with minimal increase in cost/complexitv. The cards operate fixed programmes blasted into PROM and operate in one of two modes:

1- Normal: Oata handshake with LSI-11 defines the number of pulses requested and I/n status, "enuests for too nany pulses dre totally ignored for security reasons. Watchdog reset onlv when the LSI-H calls the card ,md hence *ero pulse requests must be made to keeo the watchdoq set. 'Tyoical rtropout time is 2 seconds). Havinq received a pulse request the microprocessor nenerates the anoronriate steopsr waveforms at a rixed freauency of 200 stena/cecond. during the narnal lata handshake the steoper card sends .analog and digital input values back to the LSI-11 where they are checked against values scanned by the LSI-11. This Gives an important increase in system security by allowing earlv failure detection/correction rather than waiting until back up auto is selected.

2. °.ack uo: If a backup orogramme exists then failure to communicate with the L?I-ll t- :.ults in the fixed back uo control algorithm operating using the two ADC's for .measurements. This programme then has the responsibility for keepino'the watchdog set. For safety, transfer hack to L"51-11 control is not sossihle until standbv manual has "irst been selected. In some cases two cards/actuatcrs aff»ct a common process variable. Intercard communications usino the opto isolated digital I/n tracts resolve this conflict. - 200 -

A problem arose in creatinq e fail safe drive for the shunt wound 240V dc speeder gear nator controlling governor valve lift. This could not be changed and so a special interface was developed. This upratea the normal stepper rnotor sauare wave drive and drives a 50Hz AC transformer. The resulting square wave is rectified end applied to the motor armature, giving o floating dc drive which disappears when the stepper card stops pulsing.

2.5" Svstem Software

If engineers are to successfully apply computers to their many varied problems ot a minimal cost it is essential that they should be provided with system software which enables them to write their own application software. After surveying the available software in the early 1970's it was apparent that to obtain suitable system software it would have to be produced in house. This approach has proved very successful with a large number of installations covering a range of real-time applications in power stations, transmission sub3totion3 and the laboratory all using common (configurable) system software with application software written by enqineers rather than programmers.

To achieve adequate performance- and enqineer acceptability the following design reauirements here adopted and met;

1. Real Time flulti-task Executive

The system had to incorporate a real time executive to allow the overall work for each machine to be broken down into a number of discrete tasks of differing priority. The main function of the executive is to stimulate tasks when time'or external events demand they should run, and to queue conflicting requests from several tasks for a single resource (e.g. the c.p.u. or a hardware device).

2. Simple High Level General Purpose Language

The system had to incorporate a high level language tD enable engineers to write programmes with minimal difficulty. High level languages are for more acceptable to non-specialists and their great benefit is that they greatly reduce the number of coding errors and also constrain the damage which can be produced by such errors.

The language had to be simple for two reasons:

(a) to make it acceptable to people with no formal computer training.

(b) so that it could be implemented in small process control machines with only a limited proaramminq resource.

A general purpose language we3 required as the range of work to be covered precluded the use of special languages with the resources available.

3. Time Efficient

Experience with manufacturers languages (particularly BASIC) revealed that great cere was required to get sufficient throughput. The languaqe had to incorporate inteqer end logical variable type3 for efficient orocessing and real variables for applications demanding greater precision. The programme source is translated into a threaded polish object code which is exacuted with reasonable efficiency yet does not demand a sophisticated compiler.

A. Space and Co3t Efficient

The software was designed to run on the low cost end of the POP11 ranqe which meant it had to run in not more that 28k memory and could not be dependent on expensive backing store. This constraint is of course less important row than it was eight years ago when the work started.

5. Table Oriver Compiler

To allow Language extensions to meet the demands of different applications and to give the necessary configurability for each application, a table driver compiler with a free syntax was adopted.

6. Multiprocessor Support

The system had to support multiprocessor configurations as these were vital for reasons outlined elsewhere in this paper.

7. Line-by-line Translation

The language comDilation is handled one line at a time as eoch line is entered, with only a small mrnber of whole programme checks at the end. This enables the machine to report syntax errors etc. back to the engineer 03 early as possible which is highly desirable when inexperienced people are learning to programme the system.

B. Wide Ranqe of Utilities

A wide range of overlaynble utilities '/ere provided which allow the user not only to perform essential functions 3i.,ch as proqramme compilation, saving and restoring programme on backing store etc., but also givpg other useful facilities such as the ability to determine the status of running jobs and examine the contents of programme varinble in running jobs. These facilities are heavily utilised during debugging and commissioning. - 201 -

2.6 Communicntions

As described in Section 2.2 all data tranafer hetween processors is achieved U3inq serial links running at 4.8K hour). Thi.T baud rate is also selected for the link to the analogue scanner since in both cases the data transfer failure rate is much reduced (to neglible proportions). The actual amount of data transferred from point to point is not large, the following figures being typical:

. Control data ID words every 3 seconds

. Primary display data 100 wordD every 2 seconds

. Fast display data 5 words every 0.5 seconds.

The use of integers, bit orientated status and alarm data and selection of qlobal data for displayserve to minimise the serial link baud rote reguirement3.

Data transfer is controlled by application level software calling system software routines. The standard CEC3 protocol GENNET was found to give unacceptable performance with even modest levels of electrical noisa and a modified protocol was thus developed. A handshaking procedure is employed to ensure accurate data transfer with the transmitter making up to five attmepts to transfer each byte before flaqging a communications error. This is particularly important in the Pembroke configuration where the unit supervisor is extremely busy processing five asynchronous serial lines in addition to sophisticated control calculation and data display- Each epplication job dedicated to transmitting/receiving data has additional handshaking/watchdog facilities inbuilt to ensure that data being displayed is not frozen due to loss of the data link. In addition, data for control purposes is further checked with amplitude and rate limits relevant to the particular epplication. High integrity is thus assured.

2.7 Applications Software The applications software is written in a hiqh level lanauaae by enaineers and occupies some 8-12K of memory. The total computer function is subdivided into a number of small jota each of which performs a functionally distinct task. Each job consists of a series of simple (crash proof) statements operating on local and global variables, the latter being heavily used for inter-job co

Typically each plant area computer contains 10-15 control loops implemented using some 25-30 separate jobs. Inteoer variables are employed in most, cases since this gives maximum speed, minimum space utilisation and data transfer overheads and allows bit as well as word manipulation. Particularly in the alarm and interlock field bit -nanioulation has proved highly space and time efficient and significantly reduces interprocessor data rates without resort to compression techniques. Real variables are employed in specialised applications such as square roots, Kalman filter covariance matrices etc.

Each engineer tailors his application software to the particular application needs. However, typically any complete system would contain the job illustrated in Table 1. Experience has shown that subdivision of job by function rather than 'loop' is more efficient, safer, easier to comprehend,commission, and manage- and makes best use of the job priority structure.

Within the system there are naturally a nunber of cascaded looos and,at the higher levels of cotimisation and unit supervisory control,closely coupled multivarioble control algorithms. However, as a matter of policy each process variable or control input ha3 a single loop identity and all loops conform to the same status format. This format consists of eight separate conditions:

CA - Computer auto: Plant area or unit supervisor computer evaluates the control action required. Loop set poinc derived either from another loop or by computer manual raise/lower commands fran the operator.

CM - Computer manual, auto not available: same as CM but software interlocks prevent selection of CA.

TR - Tracking: Loop output is adjusted to track a variables measured value when that variable is not under computer auto control and bumpless transfer is required.

SA - Standby auto: An individual actuator drive card requl_te3 a single actuator usinn two plant measurements. Modest performance provided on critical control loops when the plant area computer has failed or communications have been lost. Transfer back to ncrmal computer manual/auto is achieved by prior selection of standby manual to ensure that the operator is aware of the status chanqe.

D?] - Desk manual: When a loop is in standby auto its set point can be adjusted by simultaneous operation of the normal desk 'loop' pushbutton and a raise/lower pushbutton. This deliberately contrasts with the normal seguential operation required under computer manual operation.

5M - Standby manual: Direct raise/lower drive of an actuator using the standby manual plaaue.

SH - Standby manual with computer not available: Same 83 normal stBndby manual but software interlocks prevent selection of computer drive of the actuator. - 202 -

2.3 Digital Concroi Techniques

A vide variety of digital control techniques are enployed in the system. For fasc sub loops digital controller based on analog 3 term controllers are typically employed. However, full use is made of the general purpose language to optimise each of these controllers for the particular application in question. For example, different kinds of rate and amplitude limits are employed and digital compensators (for time delay ecc.) are also required in certain conditions. Specific techniques are also employed Co cope with steady operation close to or at limits and. initial transients as loops are brought into play.

Optimisation and supervisory loops employ techniques which are essentially digital in nature. Such loops aim to manipulate set points of sub loops with a view to minimising a quadratic performance index of the general form.

(a) J, - q, x~(k)

(b) J = Z_, q x^(k) + q, XjCk) * q3 xhk) * ... q x~

- k

Where a simple process model can be obtained (e.g. load/pressure/superheater temperature,! che cype (b) performance index is employed since che feedback control gains can be calculated independently from a matrix riccati equation. Plant state estimates are obtained from a real time, parameter Adaptive Kaloan filter which also provides significant smoothing of noisy (pressure) measurements and a dynamic estiizane of plant disturbances. Research work is continuing on the application oc such techniques both at Pembroke and Didcot since initial plant trials have been encouraging.

2.9. Plant Data acquisition and Concroi Actuation

The acquisition of reliable, plant data is crucially important to the performance and integrity of any computer based control system. Thus solid state (racher than dry reed relay) input selectors are utilised for all concroi computers. All control signals are supplied from new, dedicated transducers/ current loop transmitters and each signal is scanned only by one computer. Signal sharing is accomplished by digital data transfer using the serial links in order to maximise system integrity. Since each stored signal, is directly controlled in one plant area computer all other computers utilising the data for scheduling etc. are designed to fail safe in the event of (rare) data link failure. Degraded performance is accepted.

Validity checking of raw scanned data is regarded as vital. Experience has shown that real plant measurements are capable of the most obscure and unexpected faults. Thus as a minimum, cate and amplitude checks are applied. Experiments are currently being condt. :ced using model prediction errors (Kaloan filtering) with a view to further improve signal failure detection capability. The particular checks applied and action taken when data is detected as being invalid (bad) are application dependent. However, table 3 gives an indication of the kind of checks currently involved.

Checking of control outputs to actuators is also employed (Cable 3). For example, if an actuator drive card fails to respond correctly then the drive card scatus is indicated as failed and the loop tripped off computer- Actuator measured position is also compared with the computers prediction based on .iccuraulated pulses. If a discrepancy of more than 5-8Z arises che loop is again tripped off automatically. Since che measured position almost invariably comes from a potentiometer, cLacfcing of response to individual pulse increments has proved fruitless. - 203 -

2.10 Marrnr. and Interlocks

* wide variety of alarms and software interlocks ooerate within each conauter. These ^re application soeciFic nut tvpically include:

'. Calculation of both advisory and mandatory operatinq limits.

. Auaihlp warning to ooerators of serious alarm candtions such 93 a looo trip to computer manual.

Control of IOOD status in the face of lonicol constraint", such es had innut -1ata, actuator failure or unavailability of other loops, actuators etc.

. Control of Looo set points, limits and actuator positions under specific plant ooeratinq conditions 3uch as trios noa start uos<.

*s a matter of policy all Looos are tripped to computer manual when the qonrooriate prime control variable measurement or actuator is labelled as havinn failed ?bed). However, with auxiliarv data auch as that used for control looo oarnmeter ^chedulinq/-he interlock 3ystem often sets a safe default value in the aonrooriate frozen neasurenent, thus avoiding a looo trip hut incurrinq degraded control oerfornance.

Visa ds a matter of oolicy, auto cannot be reenqaaed until the 'bad' status of Drime control measurements or actuator haa been specificially reset by the operator from the aesk- In some cases the measurement must lie within a specified ranne before the 'reset* instruction is accented but in others this is not only not appropriate but inadvisable. Tor safety reasons no loop ever self selects auto, even when *had data1 ''laps are cleared. Similarly, in some cases the selection of auto on the outer loop of a cascaded pair automatically selects auto on the inner loop whilst interlocks prevent this haopenina in other cases.

"reet care is taken with toe alarm and interlock system in order to maximise both system inteqrity and 'auto' looo status availability.

2.11 ^isolav md Command System

'he unit aerator is provided with a modular iesk to enable him to closely xonitor and suoervise oiant behaviour in 3 fashion not previously attainaDle. At "Udcot the desk Tiodificationa *ere incorporated directly into the normal "esk whilst 3t Pembroke a comoact extension *vis initially ?een addec. ria.3b illustrates this dssk extension 'based on a ~2mm DVi grid) *hich in a lenath of only AfV enccmoosses *"ive najor areas 3f control conoustion. temoerature, "eea. burners and ijnit suoervision/load) olus 'lisolav selection ror boch 1'0iI'3.

Ul joeratpr oo.Tmunication with the computer is oiaital, each aushhutton asserting dioital status inouts in the apprcoriate oiant area computer wnilst acceptance and status is indicated to :he operator by digital reed reiavs liqnting pushbutton lamps. The oushhuttona ire laid out in nlant areas radially r'rom the central •sunervisorv control and oisolav racilities. The individual actuator "tendbv nanual olaaues ure arranaen 3t the ^ack since ^.hey are intended for use only in the event of comourer -"ailure.

*11 normal xierations reouire a seouence of cush buttons 'tynieallv two or three'1 to be pressed to select ann implement 3 "unction. This nultiolexinq of buttons ensures a hioh standard of safetv and yet nakes for a very comoact, °asy to use. ^vstem. "or example, there is normally onlv one VM - raise/lower plaaue, each additional looo reouirinq the addition of only one extra pushbutton. Additional non-standard or unexoected ^unctions can readily be iricoroorated at any itaoe of the development since the function is determined solely bv applications software and the label •attach to the oushbuttpn.

The central supervisory area provides additipnal operator facilities. cor -xamole a combined raise/lower njmber oad :G orovided •so that 1ata can be entered numerically, or using incninq or continuous raise/lower technioues. [noortant system oarameters can be cnanaeo from the desk but only on insertion of a

. Too section - Permanent selected alarm summerv.

- :'entrc section - °riniary data dnd alarm rormats

. lottom -jection - Hiqh -5Deed interactive disolav for individual looos.

7he interactive ^rea updates every '1.5 -jeconds and self updates whenever sn operator selects a looo anvwhere in the system. This provides ^"ine raise/iower resolution and raoid interrogation caoabilitv independently of the ~iain disnlav format. °rimarv disolav formats update typically every 2.H seconds and are selected bv cnosina 01 u r =eoui;ntiai lv olant area, type 'data, alarm; and numher 'I- . owt*verf anain or raoid interroaation durino transients/incidents-»kev cpntrol formats are available bv sinolt? pushriutton renuest. The alarm summary classifies ill alarm conditions into one of four :ateqories &nn "lisplavs these .is in table 1.

Extensive use is nade of simple, cleerlv understood lisplavs usina dounli: size characters, colour ;ortinot revprsR video ind flashina ?ffect,s. ; common standarq has ^een estahlisned ann adopted For all lisolav *brnats •.ithin the system. The -^ain features or' this are •summarised in taole 2,

The second olant Tonitor VOil-provides -1 comnrehensive net of trends, ^istooram etc- laain, careful ^toice -w* colour afvi -liaplav nattern readily communicates information to onerators without recourse to detailed Tornat jnaivsis. \t ^idcot, hack >JP control lisnlavs are -ivailahle on the second vnn

3. IMPLEMENTATION EXPERIENCE

3. I. Projec t Scracegy

Previous experience had shown Chat in dealing with complex problems of Che kind presented by Pembroke and Didcot that CECB engineers were best qualified to write the applications software. A previous scheme had therefore been attempted on this basis with the commercial manufacturer supplying fully cesteu hardware and system software. However, both proved co have technical problems and much manpower was wasted in persuading the manufacturer to correct faults. Severe problems were encountered with the cocc:i»rcial confidentiality aspects of che system software. With this background. South West Region therefore adopted the following project strategy :

1. Control system strategy design and development - CECB

2. System software development - CEGB

3. Application software - CEGB

4. Engineering details - CEGB

5. Hardware commissioning - CEGB

6. Hardware design and supply - CONTRACTOR

7. Demonstrations of hardware performance - CONTRACTOR

This has proved to be a successful method of implementing a major refurbishnenx requiring significant technical developments and innovation for their success. The interface with che contractor is well defined, the aost difficult area being diagnosis of hardware/system software faults. There is scope for contractors blaming hardware faults on Che system software which is strictly not his responsibility. However, in practice, given ready access to the system software, the problems encountered appear to be fewer than those occurring under turnkey arrangements. Furthermore, this approach allows CEGB staff to accrue detailed knowledge of hardware characteristics thac would otherwise be difficult to obtain. This is extremely useful in assessing equipment capability, integrity and longer tera maintenance/training requirements.

The systems for Pembroke and Didcot were therefore ordered in the second half of !977 on an equipment only basis. Separate contracts were awarded for the computer equipment and the unit desk codifications in order to make best use of specific contractors expertise. >bst or the hardware was scill at che design/prococype stage and almost no reLevant application software existed. However, in parallel with che rain contractors, an experimental system employing prototype equipment was installed on one unit. The inherent flexibility of a computer based system running a high level language allowed rapid development and proving of applications software and provided useful sice based experience with key pieces of commercial hardware.

3.2. System Testing and Installation

Before commissioning of the equipment commenced boch computer hardware and system software were subjected co rigorous testing procedures. These consisted of :

Factory

>bdule development/testing using contractors own diagnostic software.

System integration testing using contractors own diagnostic software.

Module testing using CEGB system software and special purpose application software.

System integration testing using CEGB system software and special purpose application software.

Partial system testing using CEG3 software under harsh enviromcental conditions.

Site

System integration testing using contractors own diagnostic software.

Partial system testing (of experimental equipment) using CEGB system software and real application software.

System integration testing using CEG3 system software and special purpose application, software. - 205 -

The most important point3 to note are firstly that much tine was saved by factory testing prior to shipment to site ond secondly that complete hardware system testing with the final software system revealed a ho3t of hardware flnw3 and module interactions previously undetected by the contractors own diaqnostic3. Indeed it wag 3Dme oix months after the contractor first declared the system ready for shipment that it passed the system tester written by CEXS staff. The whole testinq procedure was repeated at site where further problems were detected and corrected.

The actual installation of the computer and desk equipment was simplified by the use of flying leads throughout. Stntion stoff were then able to install cabling, recks, marshalling cubicles, auxiliary power supplies, instrumentation and modified actuator head3 whilst awaiting delivery of desk modules and computer equi, '~nt. Final installation was then merely a case of terminating flying leads in accordance with a predefined schedule. Some detailed problems arose but generally the approach was successful and can be recommended.

3.3 Commissioning Procedures

Commissioning of the new system represented a major task since:

1. It had to be carried out with the minimum interference to high merit flexible plant.

2. Trc csferring an actuator to computer control irrevocably put the existing controls out of service.

3. Testing had to cover both equipment and computer software.

Cxtensive documentation was produced to cover both individual hardware item3 and complete system functional checks. The latter covered all alarms and interlock conditions as well as modulating control performance. Acceptance of each individual test carried out was dependent not only on correct behaviour of the appropriate plant area computer but also the associated communications and display system software in the display computers.

In order to avoid prejudicing plant output or safety, loops were commissioned in a planned sequence with two or three week gaps allowed for evaluation purposes. Applications software wa3 generally tested using plant simulation but critical looos software was also verified on the experimental system (which could be switched out of service if required) prior to final commissioning.

Development of the system continues after initial commissioning in ordar to incorporate operational experience and optimise performance. Where minor changes occur, these are directly incorporated and documented to the appronriate standard. However, where significant changes occur, the complete set of system functional checks is repeated. Only in this way can 3ysttm integrity be maintained. The procedure is tedious but experience has shown it to be worthwhile.

3. A System Maintenance and Management

The development of new software and control strategies is the responsibility of specialist regional staff. However, at all times, station staff are responsible for hardware maintenance and maintenance/nnnagenant of commissioned software.

Hardware maintenance is covered by shift staff up to a specific point and thereafter it is classified 83 an area call for more skilled day 3taff. Qn interesting result of the comorehensive I/O data checking, alarms and interlocks incorporated into the application software is that the system provides a hiqh degree of self diagnostic fault finding. Interrogation of the appropriate plant area alarm formats usually leads maintenance staff to the cause of the problem.

Cards within the plant area computer are tested using special purDOse diaqnostic software whilst the intelligent actuator drive cards are tested using a special test box. This allows rapid testing of every facility on the enrd and it is a concept that could usefully be extended. 4 selection of spare cards is maintained running in a hot spares rack. This is mobile and can be located next to a plant area computer to assist fault finding.

Software maintenance procedures are an important part of system maintenance. Maintenance is required to incorporate changes brought about by operational experience, the development of a new control strategy, reque3ts for additional desk or display facilities or changes in system software. The software system is deliberately designed to allow such changes to be readily incorporated. However, unless the associated documentation is submitted to the Station staff responsible for software manaqement/maintenance the chanqes are not formally recorded or accepted. Only by rigorous adherence to this rule can software integrity be maintained.

3.5 Traininn

Whilst Regional staff had accumulated several years experience with small real time computer systems, the majority of Station staff involved in the Pembroke and Oidcot schemes had no previous direct experience of this kind of work. In addition, unit operators were faced with a new unit desk, new layout and operational procedures. This posed a major challenge to those regional/national staff involved in the schemes inceDtion to demonstrate that non specialist staff could be successfully trained to operate and maintain the new systems. - 206 -

The atntegy adopted con be suimiarised as follows:

1. The installation of a experimental prototype sy3tem embracing all key features of the system. This familiarised mainter^nce and ooerations staff with the new concepts but allowed then to instantly re- select the original control system if problems arose.

2. The Station maintenance staff were involved in equipment testing at the contractors factory and were totally responsible for testing and maintenance of equipment as it arrived on 3ite. Naturally, expert guidance and advice was given thus providing 'on the job' training.

3. Key operations staff were involved in system development, testing and commissioning. They were then responsible for training specific shift operator foremen who in turn trained all other unit operators. Simulation techniques were employed to assist with the training which was almost exclusively carried out on the installed eouipment.

The strategy has been successful and Station staff are now fully competent in the maintenance and operation of the computer based systems.

3.6 Financial

The cost of the schemes at Pembroke at Oidcot can be assessed on the basis of expenditure of equipment and contractors labour, together with CEG8 manpower effort. The following is an approximate breakdown of the expenditure and manpower consumed.

Cost (S) Manpower (%)

Actuator modifications 5.8 Commissioning 8.0

New transmitters/instrumentation 6.6 Installation 13.3

Installation 13.2 System software (shared between projects) 10.6

Desk 9.1 Control system development 3D.8

Computer equipment 65.3 Engineering and design 37.3 "100.0 mo. n

It is often difficult to assign financial benefits to improved control/display systems. However indications nre that costs will be recovered in three to five years due to:

. Reduced plant damage

. Improved efficiency

However, there are many other less tangible but important benefits accruing from the approach outlined in this paper including:

. Improved environmental performance

. Improved plant flexibility

. Improved equipment reliability end easier maintenance.

• Adaptability to future unforseen events

. Imoroved system integrity

. Increased operator awareness of plant conditions, and control system status/behaviour. b. DISTRIBUTED COMPUTER CONTROL/DISPLAY SYSTEMS FOR NUCLEAR PLANT

4.1 Nuclear Plnnt Characteristics and Requirements

Many of the system requirements, design concents and dinitBl techniques described in this paper are relevant in the context of Nuclear Plant Control. However, there are substantial differences which must be considered in the application of distributed computer control to the latter. These include:

. Increased numbers of plant input signals.

. Increased numbers of important control Ioops/actuator3.

. Increased requirement for high reliability systems with predictable, fail safe characteristics. - 207 -

.. Increased requirement for failure diaqnostic capability.

. Increased requirement for plant condition monitoring, intelligent data analysis and effective corrmunication with operations otaff.

. Increased need for methods of system teatinq ond evaluation.

. Increased need for digitul control techniques capable of rapidly adaptinq to unexpected situations arid optimising plant performance in response to particular sets of operational constraints.

Whilst the basic approach outlined in this paper is believed to be correct, the author believes that further developments are needed to cope with the additional requirements and constraints outlined above. Principally, these involve:

1. Higher levels of functional distribution

2. Development of distributed hardware structures

3. Consolidation of the integrated control, display and commend system concepts-

4. Development of improved digital techniques for failure detection, control and system testing.

5- Software. a.2 Future Developments

Based on che expecience of cte Pembroke and Didcot Projects, consideration in South West Reqion is currently beinq given to the future application of distributed computing concepts to Nuclear plant. The following appear to be important areas of development:

Functional Distribution

In the recent past, the plant area computer concept wa3 the only economic solution available. However, on nuclear plant, the loss of 10-20 reactor control loops due to computer failure is not likely to be acceptable. One can, of course, introduce redundancy but this inevitnbley introduces complexity. The alternative is to increase the level of functional distribution to the point where loss of one or more computers does notreprssent a safety hazard or en operational constraint. Despite its many specific limitations, the intelligent actuator drive card developed for Pembroke and Didcot offers simplicity, minimal loop interaction under failure conditions and easy maintenance/test procedures. It is thus felt that for nuclear plant the present plant area computer with its multiplexed scanner and actuator drive system should be replaced by a series of smaller systems containing simplified non-multiplexed E/0. Thus a sinqle system conteinina perhaps 30 cards would be replace by ten systems of 3 cards or even 30 sinqle cards. F.ach of these small systems would still be capable of running a hiqh level ianguaqe such as the CEGB standard CUTLASS in order to achieve the high performance standards required. With steadily reducing semi-conductor memory costs such a hic/i level of distribution is likely to be economic, particularly if the distributed hard-ware structure described below is also adopted.

Distributed Hardware Structure

In implementing a hiohly distributed computer system two critical hardware areas are plant input/output interfacing and inter-processor communications. The author believes that multiplexed eneloQue scanners for plant data input could be replaced by digital instrumentation and digital transmitters. These could be interfaced to the computer via standard opto isolated digital input/outout parts which are readily available on almost every manufacturers system. Figure 4(a) illustrates schematically auch a digital transmitter suitable for direct connection to thermocouple signals. The data is supplied serially in response to computer requesta thus simplifying hardware design and makinq maximum use of the computer. Since many such modules can be driven in parallel the baud rate need be very low (e.g. 300 baud) thus eliminating the need for complicated line driving, ^t auch low data rates the c.p.u overhead in the computer is not likely to be a problem. High common mode and noise rejection capability is inherent in the design. Since there are many thermocouple signals on a nuclear station the transmitter module could be produced in volume to a defined specification. In such a case, cost per channel is believed to be comparable with multiplexed scanners but with the significant advantage that there is minimal interaction between one channel and another.

The use of low speed serial digital transnisDion using oDto isolators could be extended to intelligent actuator drive systems. Such devices are under development elsewhere in the CHIfl with the result that a distributed hardware structure with an all digital computer/plant interface could thus be proposed. The syst*jn would thus take the General form suggested in Fig.4b. Plant interfacing (tD a defined standard) is almost exclusively achieved through standard isoleted digital parts the only exceptions beinq the serial ports for hosting and intemrocessor communications.

For interprocesaar communications, it is suggested that a high speed (e.g. H.25M baud) serial bus based on fibre optic technology could provide a highly reliable, secure solution. Cheap LED based transmitter/receiver pairs are now available as are multiple pc *" star couplers. Thus serial bus configurations based on both star and ring structures are now possible. V is most appropriate is a matter for development.

Resides offering technical odvantoges, it is beli interface could be helpfull in construe*1— ~c — specified at the usual early stage but „ the non-trivial problem of equipment bee

Display and Command Systems

The provision of radically improved disolny and command facilifcies on the PenbroL-e and Didcot unit desks has been beneficial. The unit operators have a much improved appreciation of plant conditions and consequences of their actions. Such fnctora are important in the context of nuclear plant operation and is expected that further development work will continue. Mew technologies such 09 touch sensitive \DU screens will undoubtedly suggest alternative strategies for unit desk layout and interaction with the computer system. Experimental work both on simulated and real power plant will probably be necessary to evaluate the various eroonomic and safety factors involved. - 208 -

Oiqitnl Techniques

There is considerable potential for exploiting the powerful fncilitirn now offerer) by low rr-j-r-t r.n~.put .;>r nno S^i-h level, real tir** software systems. Evidence ta date indicotrs tlmt the npplicttion rcndrjm c-t innt: o> n:d control theory using small scale plant models can moke a significant contribution to:

. Methods of measurement iind actuator failure detection.

. Oato .smoothing and nnalysis.

. Reduction in actuator wear and maintenance requirements.

. Robust, adaptive control algorithms requiring little or no specification or tuning.

. Supervisory techniques for real time optimisation of total plant performance.

The ubove, in conjunction with the capability to rapidly devnlop nppJicntion r.oftv.nre tnUort-1 to IXJJVL- •:?••<:±fie problems,should Dignificantly improve control system integrity ond parfornnnco on nude or pJont.

Software

Software performance and reliability will always be n limiting foe Kir on any ennuter tvrsed cnntrol or rtirpLtiy system. In a nuclear environment, demonstration and tea ting of software rnl inhi lity ri'twiim nn :ntiortnnr ;M-,;J active area of research. Thu3 proceduren for software modification need oir*;ful attonticn. ^xri'fi'i(?nrp f-n'* •;>hown that interactive, high level software provides the engineer with a rapid r^chud of ^ndifyim mvjlicaticn software. Indeed minor changes can often beneficially be made on-line whr.-n oiierotinq on cunvcntinnal plant.

In a nuclear environment it is difficult to see how such a net hod of working could t>e accept RR1 . fhpre *i 1 ] thi;;i be n nef?d for methods cf approved automatic verification of software changes. Some safety features can, of course, be inbuilt to the system software but many checks are highly application snecif ic. H.p veri^icri* : cm procedures will need to be reasonably time efficient if soine of the benefits of engineers tiling hitf-* lrveJ software systems are not to be lost.

CflNCLUSIONS

This paper hns described the cteaiqn concepts behind the Pembroke end Didcot distributed computer control and .Jisplriy systems. fmolementation experience has also been reported as havincj sr^e prop03a La on further devel cprp-nt:-, for nuclear plant application. Judged by the initial renuircments described in Section 2.1 th*» pmjcctn lire a 5UCC*-:KI. High sttmdords of inteqrity and performance hove been achieved on canvcntionnl plant- It is therefore expectrH Ik-jt the distributed computer approach will be increasingly apnlied to nuclear plant.

The design and imple;menl'ation of the systems described in this paper has been the rn3u 11 of join" station, r*jtnonn ana* national stoff co-operotion in which the author hna been priveleged to takt» part.

This paner has been produced by permission 01 zhc Director ConcraL of SuuLh West Ru^ior. ->i cne Centr.ii EK'cinci ;v C£r.er3cine Board.

AG0105JNW. - 209 -

TABLE 1 TYPICAL CONTROL JOB STRUCTURE

Analogue scan/validity check tone per scan race) Digital scan Analogue data scaling Analogue da'.:a smooching Control action calculation (I per loop typically) Control loop parameter adoption and . _hedi»ling Actuator drive Desk command handling and Lamp driving Interprocessor communications for control Interprocessor coanunicacions for general display Intcrprocessor communications for high speed display Software uatchdog Hardware uatchdog Alarm and limit calculations Software interlocks System error logging/printing General interactive programmes for debugging

TABLE 2 VDtf COLOUR CODING

TEXT FOREGROUND BACKGROUND BLINK MEANING COLOUR COLOUR

Alarm summary - plane limit \ BLACK BLACK SO nsasurement ^ RED RED YES New alarra - format not selected actuator i computer }

Portrait background CREEN BLACK SO Other colours used for mimics Foreground data YELLOW BLACK SO Normal valid data BLACK. YELLOW so Plant limit alarm BLACK YELLOW YES Urgenc plant limit alarm RED BLACK NO 'Bad' data BLACK RED NO Data not being updated

Loop status CA BLUE BLACK NO Cairouter auto CM YELLOW BLACK NO Computer manual CM BLACK YELLOW NO Computer manual - auto unavailable TR CREEN BLACK SO Tracking SA RED BLACK NO Standby atico DM RED BLACK NO Desk manual SM GREEN BLACK NO Standby nanual SM BLACK GREEN NO Standby manual - computer not available

TABLE 3 - MEASUREMENT AND ACTUATOR FAILURE CRITERIA

TEST RESULT

Rate or change exceeded 'Bad' measurement Rate ox change exceeded Ignore — use model estimate Race of change exceeded 'N' times in 'J' samples 'Bad' ueasurement Above max.operating limit 'Bad' oeasu: Below min,operating limit 'Bad' measu: •ertent Model prediction error variance above max,limit Alarm condi >bdel prediction error variance below min.limit Alarm cor.di ion (signal frozen?) ! SingLe scanner error Ignore - u nodel estimate or last scan I Consequent scanner errors 'Bad' measui ecsenc f Scanner input overload Fre e ze ac I st valid measurement or signal' i

Actuator drive card responds incorrectly 'Bad' actuator Actuator drive card responds incorrectly Ignore Actuator drive card responds incorrectly 'Bad' actuator 'M' ciaes in 'J1 calls ' Actuator 'ADC' measurements discrepancy j Alarm condition Measured and computed actuator position discrepancy j 'Bad' actuator - 210 -

Figure is Pembroke Distributed System

DISPLAY OS DISPLAV ON UNIT DESK UNIT DESK

BACKINC PLANT MONITOR STORE UNIT SUPERVISOR t SYSTEM HOST 4 LOAD CONTROL COMPUTER FLOPPY COMPUTER BACKING DISC STORE T I .-J COMMUNICATION LINKS

I.I COMBUSTION BURNER FEED TEMPERATURE CONTROL MANAGEMENT CONTROL CONTROL UJD OPTIMISATION COMPUTER COMPUTER COMPUTER COMPUTER

SACK IT COMMUNICATION LISX

Figure Jb Didcot Distributed System

DISPLAY DISPLAY ON ON UNIT DESK UNIT DESK

m •• ••••« a^ IM

FEED I COMBUSTION I CONTROL I CONTROL OWuTER :======! COMPUTEP. I

PLANT ms'ITOR & SYSTEM HOST COMMUNICATION L1HKS VUSl MONITOR II TERMINAL COMPUTER

BACKING BACKING STORE STORE

STEAM TEMPERA- UNIT SUPERVISOR TURE CONTROL 1 !.OAD COSTP-OL COMPUTER COMPUTER J - 211 -

UU1LJ1

AUXILIARY DATA » FLANT MO:: [TDK rLA.".7 co.'.'DZT ro.. :J)*::TO:: ANd DAIA ANALYEIS/RHCORDa.

,

SUPERVISORY CONTROL DATA - UNIT SLPLKVISOK SLTEXVISOliV AUTO/MANUAL l

PLANT AREA PRIMARY CONTROL DATA • COMPUTER COMPUT™. AITO.':HMAL

INTELLIGENT 5INO.E LOOP PLAXT DATA ACTL'ATOR DRIV1 SIAXD3V ALTC CAM

TO STEPP-K MTOR FigurE 2b Typical Pliant firea

"LAST SIGNALS •

LSI-! I 6- CHANNEL .MICRO- ANALOGUE PROCESSOR H SERIAL I m 28k X 16 BIT DATA MEMORY WITH INTERCHANGE BATTERY BACK-C MODULE (DIM)

32k K 16 BIT OPTO-ISOLATED __ 50V D.C BACKING STATUS INPUT _- STATUS SICNAiS MEMORY | CARD 32 BITS — e.f FROM DESK

WATCHDOO RELAY ISOLATED _^i.g 50V D.C TO DEIECT STATUS O'JTPLT _» STATUS SI" ALS COMPL1ER FALLIJTIE MODULI 32 BITS — TO DESK LAMP?

I SOLID STATE I DAIA I COLO'JR DISPLAY [ INTERCHANGE j INTERFACE ! MODULI (DIM- j (YTV-3OH | PARALLEL DATA LINE TO COLOUR >iONITOR 0:: DESK DATA CONTROL OUTPUT INTERCHWCE INTERFACE — TO PLANT «ODO.E '.DIM' (STEPPER HOTOr.

DATA Z3C7EXC1LANGE MDOU.E IDIS:1 - 212 -

tyua uiBGiatiLjdii i i_ii sue uuiu

MULTIPLE FLOATING DC/DC CONVERTOR ABC ~L fLAST DATA BATTER* 30V DC FLOATING ADC

BATIE10. 50V DC OPTO-ISOLATED C/O TO ACTUATOR STEPPER DRIVE RELAY

I \K avTT" STAND 5HSCq- ACTCATOR POSITION I oVE PROM DESK PLAQU1UE L PROCESS VARIABLE

:ARD ADR. OPTO ISOLATED nDECODE 3 BIT DICIS I^tTER-CAED COMHIWICATIOSS OPTO ISOLATED 8 BIT DIGOUT

OPTO ISOLATED I/O

DIM DATA BUS

Figure 3b PesnbrD^e integrated Corfrdi/Oispiay - 213 -

DC /DC OS AC DC

REMOTE DIGITAL TRANSMITTER

STANDARD OPTC-ISOLATED DIGITAL INPOT POETS SHIFT DIGITAL BUFFER 12 BIT REGISTER AMP ADC LOGIC CURRENT LOOP STAKDARH OPTO- ISOLATED DIGITAL OUTPUT POP.TS

Figure Qb Highly Distributed System modules

ANALOG PLANT DATA

Di:::iL DIGITAL rj a DESK P/B LED LAMPS PLANT STATUS INFORMATION

11 OPTO D1GIN/OUI PAIRS OPTO DICOLT OPTO ISOLATED D1GINS

nLL MICROPROCESSOR CPU/RAM/ROM/WATCHDOG DIGITAL ICTEPJACE I I I [ OPTO DICIS/DIGOUT PUES FIBRE OPTIC CUP.REXT LOO- I OPTO DIGOIT SERIAL HOST SERIAL PORT

!

AfTUATOP. ACTUATO.". HICil Si'iED HICil SPtiD ALAK.MS WITH WITH S;nlAL EL'S SERIAL BUS INTERLOCKS DIGITAL DIGITAL INTERFACE INTERFACE COXTmi DATA DISPLAV DATA - 214 -

Leak Detection System with Distributed

Microprocessor in the Primary Containment Vessel

By K. Inohara, K. Yoshioka, T. Tomizawa

TOSHIBA CORPORATION, TOKYO, JAPAN

ABSTRACT

Responding to the demand for greater improvements of the safety monitoring system, less public radiation exposure, and increase of plant availability,measuring and control systems in nuclear power plants have undergone many improvements. Leak detection systems are also required to give earlier warning, additional accuracy, and continuous monitoring function.

This paper describes the drywell sump leakage detection system utilizing a distributed microprocessor, which is a success- ful application owing to its versatile function and ease of installation. The microprocessor performs various functions such as a rate of level change computation, conversion to leakage flow rate, initiation of alarrr, and sump pump control.

This system has already been applied to three operating BWR plants that demonstrate its efficiency. - 215 -

1. INTRODUCTION

In response to the public interest for safety and increasing plant availability in nuclear power stations, leak detection systems are required to have a more rapid monitoring function plus additional sensitivity and accuracy. These requirements have hastened the improvement.

The drywell floor drain sump, which collects unidentified leakage flow from the reactor coolant pressure bundary, is one of the important leak detection points. For the conventional detec- tion method, two mechanical level switches were used and were set up at Ki-Lo limit point respectivily. When a primary coolant leakage occures, the floor drain fills. The rising level of coolant in the sump operates the low level switch that starts a preset timer. If leakage into the sump increase by more than one gpm, the timer will fail to run out before the coolant level reaches the high level switch and an excessive leakage alarm is given.

The disadvantages of this method are the detection time delay due to the switching interval and the poor reliability of mecha- nically operated switches. When reviewing these problems, par- ticulary at the operating plants, the need for extra capabilities is apparent with regard to the leakage monitoring function and reliability. Furthermore, an important factor which applies to the operating plants is the need to select easy-to-replace hardware, - 216 -

In order to meet the above-mentioned requirement the course to take, has been to combine a continuous, non-contacting level detector with a compact data processor which flexibility, high accuracy, and is similar to standard analog instruments in both appearance and handling.

At first, the process to replace the old design began by using a part of a plant process computer, but it was not necessarily a good approach in case of the operating plants with a view to need spare memory space and stand-alone characteristics.

Consequently, on the new system, an ultrasonic level meter and a distributed microprocessor system have been used. An ultrasonic level monitor non-contactingly detects the sump level and transmits a continuous signal to the microprocessor system, where leakage flow calculation from level change is performed.

Features of the new system are as follows.

• EXPANDED DETECTION FUNCTION — Rate of sump level change may be monitored corresponding to the amount of leakage.

• IMPROVED PERFORMANCE — Distributed microprocessor system "TOSDIC" (Toshiba Digital Instrument & Control Systems) has advantages of both man-machine communication inter- faces similar to an analog controller, and enhanced accuracy as a digital machine. - 217 -

SIMPLIFIED MAINTENANCE WORKS — Ultrasonic level monitor contribues to reduction of the maintenance man-power in the drywell area due to its self- calibration facility. With on-line self-diagnosis by TOSDIC, safety monitoring functions have been improved considerably.

2. DETECTION METHOD

The purpose of this system is to monitor unidentified reactor coolant leakage by means of detecting level change of the floor drain sump for liquid collection. Sources of the leak, responsible for increasing the sump level are considered to be composed of the following three factors. (See Pig. 1)

Unidentified reactor 1) Liquid phase cooldnt leakage source coolant leakage ~ Normal moisture Vapor phase in at moshere (= x) 1 Liquid Dryivell air phase coolers (X) 2) Vapor phase flo* J+Z coolant leakage © Subtraction -^leakage Condensated output (= y), which rate of change condenses into level computation water in the

air coolers. floor drain sump.

F"ig. 1 Schematic Diagram of Detection Method - 218 -

3) Air Cooler background condensates under normal condition (= z)

Although the background contributions vary with time, it is necessary to separate the basic leakage from air coolers from unidentified leakages, for the purpose of providing more prompt and quantiative information to the operators.

As regards this point, the microprocessor is designed to subtract the air cooler condensates flow from the total leakage flow.

3. SYSTEM CONFIGURATION

This system is composed of an ultrasonic level monitor and a distributed microprocessor system. (See Fig. 2).

Level recorder Buttery unit Signal \ resister unit __ 5 TOSDIC TOSDIC "1 201 ofer r. 22/ ! Conde-\ UITtd sonic nsated\ level detector

DDLS DDCS ' Floor drain sump , Reset Buzzer unit to Rod waste Level Hi-Hi. kr$e leakage. System -ANN dbnormarities. Fig. 2 Schematic Diagram of the System - 219 -

The ultrasonic level sensor is installed above the floor drain sump, non-contacting to drain water. Its output signal is convert- ed to 4~ 20mA DC current and is transmitted to the analog input of DDLS (Direct Digital Loop Station). DDLS serves as an interfa"- of the microprocessor system "TOSDIC". Output of the air cooler condensated water flowmeter, and contacts of the sump pump operat- ing state are also connected with DDLS. These process datas are received from DDLS through the analog bus and subjects to DDCS (Direct Digital Control Station).

The A/D converted analog data is controlled and calculated about the leakage flow. The results are returned to DDLS through the digital bus. The digital output of DDLS initiates abnormal leakage alarm to the annunciator, and controls the sump pump action. The following two units are auxiliary to the microprocessor system. One is the power failure protection unit for DDCS's battery back-up and the other is the buzzer unit for warning of abnormalities of DDLS, DDCS, and sensors.

HARDWARE COMPONENTS •

1) Ultrasonic level monitor The Toshiba ultrasonic level meter has been specially developed to meet the requirements of nuclear power stations. This sensor provides the following benefits, as illustrated in Pig. 3'- - 220 -

(1) Easy-to-remove sensor

The ultrasonic transducer may be easily removed from the sensor assembly by one handed operation.

Tig. 3 View of Ultrasonic Level Sensor

This feature contributes to reduce radiation exposure during maintenance work in the dry well.

(2) Radiation & corrosion resistant sensor (3) Dry calibration facility with test pulse By means of this option, operator is able to check the instrument on-line, and calibrate, remote from the dry well.

2) The distributed microprocessor system "TOSDIC" This system consists of loop station (DDLS) and control station (DDCS) as a basic configuration. DDLS is designed to operate independently for an individual loop and associated man-machine function, identical to those of conventional analog controllers as shown in Pig. 4. - 221 -

Read write adarpss- -hip select

Fig. 4 Eig. 6 Block Diagram of DDLS Pig. 5 View of DDLS and DDCS View of DDCS

DDCS is designed to receive analog signals transmitted from DDLS and to offer A/D conversion. The converted signals are con- trolled and calculated in accordance with a pre-programmed control algorizm and the results are returned to DDLS. Since a control signal is used for transmission send-back collation method system (in addition to a parity checking system for each transmission) is employed to ensure highly reliable data transmission. The front panel layout of DDCS is shown in Fig. 5 and its block diagram is shown in Fig. 6. The latter consists of a microprocessor, the TLCS-12A combined with individual elements based on bus construction. - 222 -

5. FUNCTION

Fig. 7 shows a function block diagram of the system, which is able to provide two calculation procedures of detection, corresponding to the amount of leakage flow.

Cooler conde- nsdted voter AUX-1 Sensor Smoothing flow 1 check Rate of level chdnae every one minute Flpgr_dr$iri _ Sensor sump level PV check Smoothing Sump DI-1 Pump °%FF Rdie of level chan$e every DO-0 A ^control Hi Sump /Lo several Ten minutes DO-t alarm Conversion Leak To ilou/raTe To DO-2 alarm Tor Cooler To recorder**-' MV drain water compensation DDLS DDC5 Alarm set point (Digital value)

Fig. 7 Fucntion Digram of the Microprocessor System

The signal of the floor drain sump level is scanned every few hundred milli-seconds of sampling interval, and checked for the rejection of abnormal signals. Next, a rate of level change is checked every one minute in order to detect a sudden doolant - 223 - leakage. Under steady conditions, the level change is calculated after few ten minutes interval for the detection of slow leakages. Its timing chart is indicated at Fig. 8. 30~60min. Counter tmin Count* •300 mS Counter / 2 30 31 32 Time (min) One minute eel culation period

Reset when no- rmal. Renewed every Zmin. 30-60 o tuculdtion period. Leakage flow ou- ^ tput (its hold un- 30—&Qm'in. calculation period. /til next)

Initiate an 5- "larm output if abnormal- Fig. 8 Timing Chart of Calculation

The result of the calculation is converted into the leakage flow rate and, after subtracting the cooler condensates, this flow rate is compared with the alarm set value of unidentified leakage flcv: (i.e.; One gallon per minute leakage increase in one hour has been recommended by N.R.C. Regulatory Guide 1-^5)

When the leakage exceeds the alarm limit, an Annunciator is energised through the digital output of DDLS.

The relationship between computed leakage output, and the sumr level, is schematically illustrated in ?ig. 9. There is a further function whereby two position OM/OFF control of the sump pump provides Kj-Lo limit alarm outputs. - 224 -

Wan-Fall SFAN

Samp level Checked every one minute for Odrvpt level change.

0 30 60 IZO 180 ZiO 300 360 390 Time(min-) Leakage flow (yj) Mated Calucjlated an alarm every Two minuts Alarm set point The background lea- kage (Air cooler conden- weter)

Time Figure 8 <(/\) Change of sump level. Schematic of ,„>„.. . recording chart \\u) Rate of level change(leakage flow)

Fie Schematic of (A) Change of sump level Recording Chart .!B) Fate of level change (leakage flow)

6. CONCLUSION

By use of the distributed microprocessor system, leak detection by the drywell floor drain sump has been greatly improved and provides the following added advantages.

Earlier warning: The detection re.soonse time is shorter than with other conventional units. Improved monitoring functions: Continuous leakage rnon. oring function and two way detection - 225 -

method, corresponding to the amount of leakage, improve the monitoring function. Ease of maintenance: Man-power saving for maintenance work and reduction of radiation exposure have been markedly improved by calibra- tion free sensor and self-diagnosis function of microprocessor. Suitable for existing installations:

This system is so compactly designed that it is more appropriate for operating plants than a large scale process computer.

This system has been successfully employed at Tepco, Pukushina nuclear power plants for about two years. Fig. 10 shows a view of the microprocessor-aided leak detection system in operation.

[Reference]

K. Inohara et. al., "Improvement of leak detection system in a drywell area with microprocessor. [B50, 1979 Fall Meeting of the Atomic

Energy Society of Japan] Fig. 10 View of DDLS and DDCS (in operation) - 226 -

DISTRIBUTED TERMINAL SUPPORT IN A DATA ACQUISITION SYSTEM FOR NUCLEAR RESEARCH REACTORS

by

R.R. Shah, A.C. Capel and C.F. Pensom

ABSTRACT

A comprehensive and flexible terminal support facility is being designed to provide the necessary interactive man- machine interface for REDNET, a distributed data acquisition system for nuclear research reactors. Host processors and a large number of terminals are linked via three physically independent but interconnected terminal support subsystems, which use in-house developed equipment based on cable TV technology. The CCITT X-25 protocol is supported, and virtual circuits are used for communications between terminals and software functions in host processors. This paper presents the requirements and conceptual design of the major terminal support components. - 227 -

DISTRIBUTED TERMINAL SUPPORT IN A DATA ACQUISITION SYSTEM FOR NUCLEAR RESEARCH REACTORS

R.R. Shah, A.C. Capel and C.F. Pensom

1. INTRODUCTION The REDNET distributed multi-processor system is being developed at Chalk River Nuclear Laboratories (CRNL) to replace obsolescent data acquisition equipment in use at the NRX and NRU research reactors [1]. The REDNET system incorporates advanced system concepts to provide enhanced capabilities for operators, experimenters and system personnel. These new technologies are being investigated with a view to their potential application in the CANDU power reactor program. A system requirement is the availability of effective interactive man-machine interfaces to provide facilities for: direct interaction with experimenters, continuous monitoring of experiments, - on-line data manipulations, examination of historical data, program development and debugging, and jargon-free communication. Terminals are distributed around the site at locations best suited to serve the user community. Moreover, changes are expected in the number of terminals and their locations to reflect the evolving experimental and opera- tional needs, and these changes are to be accomplished with a minimum disturbance to the system operation-

2. TERMINAL SUPPORT DESIGN CRITERIA The REDNET user community consists of two groups: system personnel, and experimenters and operators. System personnel, who are expected to be fully conversant with the overall system operation, are to access each REDNET function at a terminal by specifying the name of the desired function, without having to identify the host processor. Since the function may be available in a number of REDNET host processors, the terminal support facility is to allocate the host that is currently ready to provide the function.

A system user should also be able to access a function in a specific host processor, and to establish a communications link with another terminal by giving the remote terminal's identity. -- 228 -

Experimenters and operators, on the other hand, need access to only a limited number of well-defined system functions, and they must be able to call up these functions with simple procedures based on menu techniques and function keys .

Furthermore, a user in this group should, with a simple action, be able to force any terminal to revert from its current state to a standard "home" state, where the terminal displays the basic user's menu and awaits requests via the terminal's function keys.

In addition to the user considerations, the terminal support facility should also permit software functions in host processors to establish communications links and carry out data exchange with remote terminals and functions.

3. TERMINAL SUPPORT IMPLEMENTATION

Host processors and terminals will be linked together via three physically independent but logically interconnected Terminal Support Subsystems to provide separable communications [2], as shown in Figure 1.

BUILDING B'UILOIN-G COW'P'IITIRC BUILD INS BOO 375 CENTER 200 REON£T SYSTEM MANAGEMENT CDC BG00/ CLUSTER CYBER 173 PROCESSOR CQMPU'TiER COMPLEX

.TO OTHER BUILDINGS GLOBAL SUBSYSTEM

INTER-CHflNNEL INTER-CHANNEL COMMUNICATOR COMMUNICATOR

NRX NRU BUILDING BUILDING

REONET REAL-TIME CLUSTER PROCESSORS

• NRXA REMOTE (N«U PHASE STILL PROCESS TO BE DCFINED) 1/0 HI STATIONS <— NRXB

NRX SUBSYSTEMJ NRU SUBSYSTEM

FIGURE 1: REDNET Terminal Support Facility - 229 ~

In the current phase of the REDNET project, only the NRX and Global Subsystems are being implemented. The NRU Subsystem will be installed later.

The NRX Subsystem links together two MODCOMP IV/35 host processors and about ten terminal devices, and is located entirely within the NRX research reactor building. The Global Subsystem extends around the site to link together host processors (including the CDC computer complex) and terminal devices in other buildings. The two subsystems operate independently but terminals and processors on one are able to communicate with those on the other via the Inter-Channel Communicator.

The key feature of the REDNET terminal support facility is the use of virtual circuits for communications (see Figure 2). Once a virtual circuit has been established between, for example, a terminal and a software function, data exchange can be carried out between the two as if there were a physical link between them.

MENU SUPPOKT PACKA6C

INTER-FUNCTl'GHHI COMMUNICATOR REDNET H'QST PROCESSOR

MENU SUPTOKT PACKACC

INTER-FUNCTION COMMUNICATOR TERMINAL REDNET HOST PROCESSOR SUPPORT SUBSYSTEMS

FIGURE 2: Communications in REDNET Terminal Support Facility - 230 -

TIIP jiioni.noring and control of both the virtual circuits and the d'*':a flow in them are provided by the Terminal Pr.pnort Subsystems, Inter-Function Communicators and Menu Support Packages. 4. TERMINA.L SUPPORT SUBSYSTEMS Each Terminal Support Subsystem (TSS) provides dynamically assignable interconnections for all communica- tions between terminals and host processor functions in the REDNST system. 4 .1 Physj ca.1 Description ftach subsystem uses a CATV-type coaxial cable co distribute data, with terminals and host processors accessing the subsystem facilities via modems. Cables may be extended when necessary to cover other areas, and modems may be connected or disconnected at any time, even during system operation.

The computer modems use the CC1TT X.2 5 protocol [3] for communications with the REDNET host processors, while each terminal modern supports a local protocol matched to the attached terninal type. Each local protocol is translated into an internal TSS protocol used for transactions between modems. This internal protocol supports virtual circuits dynamically established between terminals and/or X.2 5 logical channels.

Modems have access to a common RF channel which consists o." a transmit carrier frequency in the 5 to 115 MHz band operated as an "up-link", and a receive carrier frequency in the 160 to 260 ME.?, band operated as a "down- link" . The translation from "up-lirk" to "down-.1 ink" carrier frequency is carried out by a remodulator at one end of the cable run. The modem RF components support a 50 kBaud data rate with a bandwidth (including guard bands) of 200 kHz. Based on previous experience with similar RF components [4], error rates ever the ceble of less than one in 10^ bits aro expected. To avoid common-mode failures, dual redundant remodulators.. line amplifiers and other active components are used. The communications channel is shared by each. modem using a CRNL-developed time division multiplex method. Each m.)dfin he.s access to a guaranteed minimum data trans- port capacity. A higher capacity is also available to the - 231 -

modem on a "burst" basis, and is shared by all modems on a subsystem. For modems that have much higher data transport requirements (e.g. modems for processors and line printers), a second RF channel is available. Instantaneous access to this channel is not guaranteed but the channel utilization is more efficient.

In addition to the modems, each subsystem includes the following hardware: i. a Diagnostic/Test Monitor for performance monitor- ing and fault diagnosis, ii. a pair of Arbiters for maintaining a dual redun- dant functional-to-physical address list necessary for the TSS addressing feature, arbitrating the "burst" requests and performing some subsystem housekeeping functions, and iii. an Inter-Channel Communicator for controlling the coupling of virtual circuits between subsystems. 4 .2 Operating Features 4.2.1 Virtual Circuits All transactions in the subsystems take place over virtual circuits (VCs) (see Figure 2). Each end of a VC is "attached" to a terminal or an X.2 5 logical channel. A VC is dynamically established from a terminal by entering a connect command: #CN name, data where # is a prefix to indicate to the terminal modem that the following text string is to be inter- preted as a command; CN is the connect command mnemonic; name is the desired function or terminal name; or is a concatenation of host processor and function names if the function on a specific host is required; and data are optional data for the function. Alternatively, a VC is established from a pro- cessor with an X.2 5 "call request" packet. A-Jinor •--. 'JC has been established, the terminal or sorcwcire function at each end of the VC is supplied by the TSS with type codes to identify remote terminal type or X.2 5 logical channel. The type codes permit software functions to make use of any special terminal features (e.g. graphics and color) that may be available.

The VC is deallocated either from the terminal by the release command:

#RL or from the processor with an X.25 "clear request" packet. Data transfers over established VCs take place in full duplex with a choice of transmission modes in each direction. Modes supported are: character by character, line by line and block by block. Permanent VCs, established at system generation time, are available for the TSS and the host processors to monitor the performance of each other.

4.2.2 Addressiny The TSS addressing capability enables a function to be accessed either in any suitable host processor (as chosen by the T33}, or in a particular processor (as directed in the "connect" command) . In the first case, only the function name needs to be supplied when establishing a VC, while in the latter case, a concatenation of the processor and function names is needed.

Within the TSS, addressing is a distributed function resident partially in each modem and partially within the Arbiters. Each modem has a short list of commonly used functions or terminals with their physical addresses, and has access to a larger master list in each Arbiter. In the unlikely event that both Arbiters fail, the modems can con- tinue to provide the addressing service using the local lists• If a function is supported in several host pro- cessors, the function will have more than one physical address in the address lists. When establishing a VC, if the host identity is not supplied, the TSS will automatically request a connection to the function in different hosts in sequence until successful. The Arbiters maintain up-to-date master address lists by interacting at regular intervals with the host processors on each subsystem over permanent, virtual circuits. - 233 -

4.2.3 Terminal Modem Features Since terminals with different capabilities are used in the REDNET system, the terminal modems facilitate keyboard entry by providing the following minimum local features where necessary:

i. echo of characters as they are typed in, and ii. text editing functions such as character delete, line delete and horizontal tabulation. The terminal modems also provide a macro-like facility whereby a single character input from the terminal can be expanded into a command string which is then pro- cessed normally by the TSS. In the REDNET system, this feature will be used to force a terminal into the "home" state (see Section 2.1). 5. INTER-FUNCTION COMMUNICATOR The Inter-Function Communicator (IFC) is a group of programs in each REDNET host processor that enables several software functions within the host to communicate with the Terminal Support Subsystem. It employs the X.2 5 protocol for all interactions with the subsystem, and, in effect, extends the X.25 logical channels from the TSS virtual circuits to the software functions in the host (see Figure 2).

5.1 IFC Services

A number of IFC services are available to both the software functions within the processor and the TSS. Software functions invoke the services by submitting i/o requests to the IFC through the executive services of the operating system, while the transactions with the TSS are carried out by exchanging X.2 5 packets containing directives or data. 5.1.1. Connect Service A connect service request from a software function is used for establishing a communications link with a named terminal device or another function in a host processor. The IFC reserves a logical channel, and a "call request" packet is forwarded on that channel to the TSS for final resolution. The logical channel is actually allocated for transactions only after the TSS returns a "call connected" packet.

An "incoming call" packet from the TSS represents an attempt to establish a communications link with a soft- ware function, and specifies the logical channel to be used. -- 234

If ~;K? .inrli ",nto i 'inaction is available in the host processor, it. is p.ctivatei and the logical channel is allocated for transactions with the function. The function in. either case is given the logical channel "allegiance", which means that only this function can receive data on that channel. 5.1.2 Disconnect Service A disconnect service request on a logical channel from a software function forces the IFC to deallocate the chanael and forward a "clear request" packet to the TSS. The latter then returns a "clear confirmation" packet to the IFC when the logical channel has been freed and the remote terminal or function has been notified.

If the "clear indication" packet is received from the TSS, the IFC deallocates the specified logical channel and aborts the activation of the software function associated with that channel.

5.1.3 Transfer/Accept Allegiance Transfer allegiance is a service provided by the IFC to enable a function that currently has a logical channel allegianr.e {and henca the right to receive data on that logical channel) to transfer it to another function in the processor. This special service is available only for software functions and has been provided to satisfy require- ments for the experimenter and operator level terminal support in the REDNET system (see Section 6).

Actual transfer of allegiance only takes place after the recipient function has submitted an accept allegiance request to the IFC.

5.1.4 Send/Receive Data A send data service request from a software function causes the IFC to assemble the supplied data into X.2 5 data packets, and pass them to the TSS on the specified logical channel for transmission to the remote function or terminal. The receive data service request from software function causes the IFC to monitor the specified logical channel for data packets arriving from the TSS, provided that the function has the logical channel allegiance. When data are received on that channel they are transferred to the function. - 235 -

If data packets are received by the IFC on a logical channel currently in use prior to a receive data service request, the data packets are saved until the correct function makes a request to receive the data.

5.2 Software Structure The IFC consists of three modules: Doorman, Modem Receiver Task and Modem Transmitter Symbiont (see Figure 3). r~ •

MODEM ! RECEIVER —tm- TASK CX.25 FRAME LEVEL) DOORMAN TO i 1 (X.25 PfSCKET TO COMPUTER LEVEL) FUNCTIONS MODEM MODEM TRANSMITTER SYMBIONT — (X.25 FRAME LEVEL)

INTER-FUNCTION COMMUNICATOR

FIGURE 3: Structure of Inter-Function Communicator

5.2.1 Doorman The Doorman, the main control and monitoring module of the IFC, is a symbiont* that interfaces the software functions in the processor to the TSS. Its activities are:

i. monitoring and control of logical channels and their utilization; ii. receipt and processing of service requests from software functions for establishing communications links and for data exchange with remote terminals and functions via the TSS;

*A symbiont is a special privileged task that processes i/o requests directed to it by the executive services of the operating system, and operates as an intelligent device handler. -- 236

iix. acceptance and processing of X.2 5 packets on each logical channel from the TSS (via the Modem Receiver Task), and transmission of data to the appropriate functions;

iv. assembly of dar.a from software functions into X.25 packer .-and transmission of the packets to the TSS (via the Modem Transmitter Symbiont); v. performance of software function activations and deactivations as necessary; and vi,. maintenance of address lists in Arbiters on request from the TSS.

Most of the X.2 5 packet level (Level 3) services are performed by the Doorman. The packet REJECT service, which is designated as optional in the X.2 5 recommendation, is not implemented since it involves the overhead and added complexity of maintaining a queue of unacknowledged packets for each operating logical channel.

5.2.2 Modem Receiver Task The Modern receiver Task (MRT) constantly monitors th^ host processor1G X.25 link level (Level 2) interface with the TSS, and awaits frames from the TSS.

In addition to the link level supervisory and control services, the MRT ensures that information frames are received in correct sequence, and passes to the Doorman the X.2 5 packets contained in the information field of the valid franes. If errors are detected in the frame sequence, retransmission of frames is requested from the TSS. The [IRT also monitors the acknowledgement of the frames received by the TSS. If it detects that TSS is not receiving frames in correct sequence, or if a retransmit request is received from the TSS, the Modem Transmitter Symbiont is asked to retransmit the necessary frames. 5.2.3 Modem Transmitter Symbiont The Modem 'Jransmitter Symbiont (MTS) operates on requests from the Doorman and MRT modules to transmit frames to the TSS. It assumes that the frames are received in the X.2 5 link level format. The MTS supplies the frame sequence numbers and maintains a queue of unacknowledged frames which are retransmitted if and when indicated by the MRT. - 237 -

6. MENU SUPPORT PACKAGE The Menu Support Package in the host processor is designed to provide the experimenters and operators with a man-machine interface enabling simplified access to system functions. This package is activated whet, a user forces a terminal to revert to the standard "home" state by pressing the designated function key (see Section 2.1). Upon activa- tion, the basic menu is displayed on the terminal screen, following which the package awaits further input from the terminal keyboard. If a user enters a function request by keying in parameters and pressing a function key, the text string is transmitted by the TSS to the Menu Support Package, which decodes it and activates the necessary software function. The allegiance of the logical channel on which the trans- actions are occurring is transferred to the function so that the latter can carry out interactive dialog with the user, if necessary. After the function has completed direct inter- action with the user, the logical channel allegiance is transferred back to the Menu Support Package, which then resumes monitoring terminal input for further function requests. 7. CURRENT STATUS Prototypes of the TSS modems have been built and are undergoing extensive testing. The terminal modem software and the TSS internal protocol are operating, and further refinements in addressing and failure recovery functions are being implemented. The X.2 5 software for the computer modem is being designed.

The preliminary design of the IFC and the Menu Support Package is complete, and detailed design of these modules is in progress. - 238 -

8. REFERENCES

1. YAN, G., L'ARCHEVEQUE, J.V.R. and WATKINS, L.M., "Distributed Computer Control Systems in Future Nuclear Power Plants", Nuclear Power Plant Control and Instrumentation, Vol. II, International Atomic Energy Agency, Vienna, 1978.

2. CAPEL, A.C and YAN, G. , "Distributed Systems Design Using Separable Communications", IWG/NPPCI Specialists' Meeting on Distribute^ Systems for Nuclear Power Plants, International Atomic Energy Agency, May 14-16, 1980. 3. "Provisional Recommendations X.3, X.25, X.28 and X.29 on Packet-Switched Data Transmission Services", Inter- national Telegraph and Telephone Consultative Committee (CCITT), Geneva, 1978. 4. CAPEL, A.C., YAN, G., "An Experimental Distributed System Development Facility", IEEE Trans, on Nuclear Science NS-2 4, No. 1, pg. 395-400, February 1977. - 239 -

SESSION 4 - REQUIREMENTS AND DESIGN CONSIDERATIONS - II - 240 -

DISTRIBUTED SYSTEMS IN THE HEAVY WATER PLANT ENVIRONMENT

by O.V. Galpin, G.E. Kean, and J.C. McCardle

ABSTRACT

This paper describes the data acquisition system on the Atomic Energy of Canada Limited, Glace Bay heavy water plant. After four years of successful operation and frequent changes during this period in response to changing requirements the availability of the system has stabilized at 99.5%. The plant support group carry out all hardware and sofware maintenance. Based on the experience with this system consideration is being given to a computer control system for the plant. A distributed control system structure appears to be well suited to the heavy water plant requirements. - 241 -

1.0 INTRODUCTION The data acquisition system installed on the Glace Bay Heavy Water Plant (GBHWP) has been in operation now for four years. This paper gives a brief description of the system and some details on its performance over the past two years. A more detailed description of the system is given in Reference 1.

Both the Glace Bay and Port Hawkesbury heavy water plants are considering implementing some form of computer control. The requirements of the control system are outlined. A distributed computer system architecture appears to provide a good match for the control and reliability requirements of a heavy water plant.

2".O DESCRIPTION OF THE GLACE BAY HEAVY WATER PLANT The process used by the Glace Bay Plant is the hydrogen sulphide-water dual temperature exchange or, as it is more commonly known, the Girdler-Sulfide (GS) process.

In principle, the process is fairly simple. As shown in Figure 1, water is fed to the top of a column that contains a large number of trays "and has a cold zone at about 30°C and a hot zone at about 130°C. Hydrogen sulphide gas (H2S) is circulated countercurrently to the water flow. The trays serve to facilitate good gas-liquid contact. In the cold zone d^utbrium tends to concentrate in tha water and in the f^ot zone the deuterium tends to concentrate in the gas. As a result, deuterium atoms migrate from gas to liquid in the cold zone and from liquid to gas in the hot zone. Since the gas and liquid flows are countercurrent, the net transport of deuterium is to the center region of the column. In this region the deuterium concentration in the water is typically 4 or 5 times greater than in the inlet water. In the effluent - 242 -

water the deuterium concentration is about 80% of the concentration in the inlet water.

This concentration process is repeated by taking a side stream of enriched liquid or gas from the region of maximum enrichment and feeding it to another, similar column or second stage of enrichment where the concentrating mechanism is repeated.. After three stages of enrichment, the heavy water concentration is 10-20% (Fig. 2). This water is then processed in a vacuum distillation finishing unit to give reactor grade heavy water which is typically 99.75% deuterium.

The tower systems or enriching units are connected by a liquid feed and return flow. Each tower system is designed so that it can be operated while isolated from the other units. In this mode deuterium concentrations build up to a saturation level, in the first stages after about 8 hours of operation. This design feature allows the plant to achieve a better availability by minimizing the restart time after a failure in a connected unit.

The remainder of this paper describes the computer data acquisition system, called HEWAC, installed at the Glace Bay plant. The following topics will be covered in order, the system description, its role in overall process control of the plant, a description of the computer to computer communications, and the svstem performance and staffing to date. Finally the basic requirements of a heavy water plant control system are described.

3.0 SYSTEM DESCRIPTION

3.1 Hardware

The hardware layout of the HEWAC system is shown in - 243 -

Figure 3. The system hardware is comprised of the fol1owi ng:

a) Master computer -'Varian 620/L-100 with 32K core memory, analog and digital I/O circuitry, 1M word fixed head disc memory, and 2 nine-track magnetic tape drives. This equipment is located in the computer room in the control building.

b) Remote Computers - Varian 620/L-100 with 4k core memory, and analog and digital input circuitry. This equipment is located in a small computer cubicle, at the 17 meter level on the pipe rack, in both North & South pi ants.

c) Operator's Station - includes a push button function panel, an operator's terminal (keyboard and CRT display), 2 graphical display monitors, an alarm display, and a line printer. This equipment is located in the main control room.

d) System Maintenance Station - includes a terminal (keyboard and CRT display), a paper tape reader and punch, a graphical display monitor, a plotter, and a line printer. This equipment is located in the computer room with the Master computer.

e) Engineering Station - consists of a terminal (keyboard and CRT display) with a built-in thermal printer for hard-copy capability, and a graphical display monitor. This equipment is located in the Technical Department offices. - 244 -

f) Lab Station - consists of an ASR-33 Teletype located in the Chemistry Lab and is used to run the Mass Spectrometer Analysis programs. These programs will be described later.

g) L/G Recorders - The computer calculates the liquid to gas flow ratios (L/G) every 5 seconds and outputs the values via the Analog Output System to the L/G Recorders mounted on the main control panels. The production of each to;ver system is very sensitive to changes in the L/G ratio.

3. 2 System Functions

The three primary users of the system are the control room operators, process engineers, and pient management. Although originally intended to supplement the information available to the operators from a standard analog control panel the computer is now the primary tool for monitoring the plant process conditions. There are no direct control functions in the computer so that a failure of the computer does not cause a shutdown of the plant.

The process engineers access the on-line data base through a terminal in the Technical Department office to optimize the plant control, analyze upsets, and study long term trends. Management information is supplied through a daily production and inventory report.

A brief description of the most important system functions follows:

a) Input Scanning - There are approximately 600 analog and 600 contact digital inputs to the - 245 -

system. Master computer analog inputs are scanned at a 5 second interval and all remote analog inputs at ;< 10 second i.nterval. Aproximately 400 of the digital inputs are scanned every 10 milliseconds, the remaining 200 are scanned every 1 second. b) Al arr.i Reporting - Alarms are generated whenever a digital input changes state, or whenever an analog input or calculated variable exceeds its specified limits (i.e. high or low instrument limit, high or low process limit, or rate of change limit). The alarm message contains the time, alarm state, point I.D. and description. It provides a chronological list of events which is very valuable for analyzing plant upsets. c) Real Time Data Presentation - This function provides the operator with access to current values of analog inputs, calculated variables and manually entered deuterium concentrations. The operator may select to have the information printed or displayed in alphanumeric tabular form, superimposed and updated every 5 seconds on a process schematic, or plotted graphically. d) Historical Data Presentation - Data are accumulated and averaged for several different time periods and saved in historical files (e.g. ten-minute averages, sixty-minute averages). This data can be displayed on a numerical printout or on a graphical plot. e) Calcuiati ons - Analog inputs and manually entered deuterium concentrations are used to calculate several different parameters and production - 246 -

figures. These calculations are of great interest to operations personnel since it provides an indication of the current state of the plant. f) Report Generation - There are 20 reports printed daily including the production and inventory report and more detailed reports summarizing the performance of each tower system. g) Deuterium Analysis Entry - One of the more interesting recent developments on HEWAC concerns the entry of laboratory analysis of deuterium samples. The performance of each tower system is monitored by taking process samples from the mid-point and bottom of each hot and cold tower in the process. The deuterium concentration of each sample is determined by analysis on a mass spectrometer. A complete set of approximately 35 samples is taken twice daily. Based on the sample analysis, adjustments are made to the Liquid and gas flow rates of the extraction units to achieve maximum production.

The normal procedure at the plant had been to process a complete set of samples in the lab and then enter the results into the computer system from a terminal. There is a considerable amount of calculation to be done while processing the samples. Each sample is bracketed by standards and the results of each sample must be corrected for drift in the mass spectrometer. This procedure led to frequent error either in processing the samples or in entering the results.

To overcome the problem the mass spectrometers have been connected to the computer system. An - 247 -

analog output signal from each of the two mass spectrometers is connected to the analog input system of the master computer and a hard copy terminal has been located near the mass spectrometers. When the laboratory technician begins the sample analysis an interactive program is initiated on the terminal. The technician enters the sample identification for each sample and when the computer detects that the mass spectrometer output has stabilized the calibration calculations are performed and the results output on the terminal for verification by the technician before being stored in the one line data base.

This development has speeded up the processing of the samples and greatly reduced the frequency of errors in entering deuterium concentrations.

4.0 OVERVIEW OF PLANT PROCESS CONTROL

The role of HEWAC in the overall control of the Glace Bay plant is illustrated in Fig. 4 The plant Technical Department is responsible for specifying the process conditions in the plant. A terminal in the Technical Department provides access to the current state of the plant and a 24 hour history from the on-line data base. The piant-HEWAC-Technical Department loop provides the information for the daily control of the plant.

HEWAC records the value of all analog inputs (600) on magnetic tape every minute and summary information such as alarm messages and lab data every hour. The tapes are then sent to the Chalk River Nuclear Laboratories (CRNL) Computing Centre where they are stored. Both the Technical Department at Glace Bay and the Chemical Engineering Branch at CRNL use this data archive to a) study long term trends, - 248 -

b) analyze problems and incidents, and c) verify computer plant, simulation programs. This work by both groups provides for the long term optimization and understanding of the plant operation.

5.0 MASTER/REMOTE COMMUNICATIONS

A large number of the input sensors are located on or close to the main exchange towers. The average distance of these sensors from the computer room is about 300 meters. There is, therefore a considerable saving in cabling if these inputs are multiplexed close to the sensors. It was for this reason the two remote multiplexors were installed, one in the North Plant and one in the South Plant, both located 17 meters above ground level.

The remote multiplexers are located in environmentally controlled cubicles. These cubicles are equipped with heaters and air conditioners and are maintained at slightly positive pressure with plant instrument air supply purge in order to prevent the ingress of the corrosive and toxic hydrogen sulfide gas.

Data are transmitted between the remote computers and the Master Computer over serial data links at 4800 bits/sec. (Fig. 5). There is also a data link between the two remote computers so that if the direct link between a remote and the Master fails, data may be transmitted from that remote to the Master via the other remote computer.

The Master computer initiates all communications on the data links. It monitors the operation of the data links and issues alarm messages if an abnormal situation exists. If the direct link to a remote is not operating, an indirect request for the data will be initiated via the other remote. The data links are serviced on a character by character basis initiated by an interrupt. - 249 -

The remote computers decode the data request and respond by transmitting the data to the computer which made the request. All data link communications are accompanied by a checksum word. This word is compared to a checksum generated by the receiving computer to detect any errors in transmission.

The Master computer updates all analog data values every 10 seconds and all digital data every second. In addition to scanning inputs and responding to requests to transmit data to the Master computer, the remote computers do additional processing of the analog input signals. Each analog input value sent to the Master computer is an average of 16 readings of the input signal taken by the remote computer and corrected for offset.

6.0 SYSTEM PERFORMANCE AND STAFFING

The specification for the HEWAC system was released for tender in December 1972 and the contract awarded in March 1973. All of the software including the basic executive, device drivers, and data base was custom designed for the system and programmed in assembler language. Figure 6 shows the total person-years of effort by the supplier, our consultant, and AECL required to bring the system to an operational state by the end of 1975.

The system support staff of 3 people has been constant for the past three years. About one half a person-year from this group is required to support other computer equipment at the plant.

About 50» of the current support effort on HEWAC goes into new developments and enhancements of the system, the remainder be required to maintain the system. - 250 -

The availability of HEWAC for the past 27 months is shown in Figure 7. The average availability for the period shown was 99.5%. Fig. 8 gives the breakdown of the 0.5% unavailability over this period. Planned down time accounts for 25% of the unavailability. Most of the planned down time is for installing and testing new software. The remaining 75% unplanned down time is made up of 40% caused by software, 20% hardware, and 15% uni denti fi ed.

The plant support group is responsible for all hardware and software maintenance. A complete set of spare parts including a spare CPU, disk, and printed circuit boards, is maintained on site. Most of the integrated circuit chips (IC's) in the system are also stocked. Faulty circuit boards are repaired on site.

There have been no major hardware reliability problems. The fixed head disk unit has operated trouble free for six years. Failures of the air conditioners in the remote cubicles have resulted in several circuit board failures on the remote computers due to overheating.

As mentioned above the operating system was custom designed for this application. Although this may seem to be an inefficient approach, so far it has worked out well for this system. It has forced the support group to know the operating system as well as they know the applications programs. There is no hesitation to modifying the operating system to meet new requirements and there is no dependance on outside support. To the best of our knowledge, there are no operating systems available in 1973 that could equal the performance achieved on HEWAC. The extra cost if any of this flexibility and independance is a slightly larger software support group. - 251 -

There are two important contributing factors to our satisfaction with the custom designed software. The first is the early and extensive involvement of the eventual support group in the design and development of the system as indicated in Fig. 6. The second factor has been a relatively stable support group.

7.0 CONTROL SYSTEM REQUIREMENTS

Although the basic GS process is the same, the Glace Bay plant uses a flow sheet that is quite different from other Canadian heavy water plants. Process control at Glace Bay is considerably more difficult because of the larger number of tower systems and more importantly a greater sensitivity to process conditions (Reference 2). Since start up in 1976 the plant operation has matured and the technical staff has developed the experience and confidence to the point where computer control is now being investigated.

The Port Hawkesbury heavy water plant the technical staff is also investigasting some type of computer control but for a different reason. At Port Hawkesbury part of their data acquisition system and the analog panel instrumentation are both obsolete. Thus there is an opportunity to replace both with a new computer control system.

The basic requirements of the control system at both plants are the same. The requirements although needing considerably more detailed definition, are briefly outlined be!ow:

Reliability

A control system failure which would result in all systems snutt-; ng down would mean 2-3 days of lost production with a - 252 -

value the order of $0.5M. This would rule out any type of single computer system.

Retrofit Capability

Again because of the value of lost production to the operating plants, the new control system must be implemented with the minimum downtime and disruption to the plant.

Control Values

Each tower system has 11 or more control valves. The control system must perform normall process control functions, including a feed forward loop, to maintain the specified setpoints.

Heat Recovery Loops

An important feature of the GS process is the large amount of energy transfer required to economically maintain the 100OC temperature differential between the cold and hot tower sections. Energy is transferred between recirculating liquid flows from the hot and cold sections in large heat exchanger banks. Excess heat is removed from the cold tower by cooling water and heat is added to the hot tower with steam.

There is considerable scope for using sophisticated heat optimization routines to conserve energy. At Glace Bay besides the steam and cooling water flows there are four independent reel rculating flows which must be controlled. - 253 -

Steam A11ocati on

At full production steam is a limiting resource. When tower systems are out of seryice the available steam must be allocated in the most efficient manner, Conversly if there is a reduction in the steam supply, cutbacks must be taken in the most efficient manner.

Minimize Upsets

The controll system should respond to process upsets or equipment failures so as to minimize the effect on connected systems.

L/G Ratio

The production of each enriching tower is very sensitive to the liquid to gas (L/G) flow ratio in each tower. The L/G ratios are adjusted based on deuterium sample analysis in each tower. There is a large degree of interaction between the towers in response to changes in L/G ratios. The interaction, sensitivity, and requirement for lab analysis make L/G controll the most difficult control function in a heavy water plant.

A distributed control system as illustrated in Fig 9 is being considered for Glace Bay. Each enriching unit would have its own processor with memory, process I/O, and operator station. All of the processors and HEWAC would be connected on a communications channel.

The individual processors would have the inputs, outputs, and programs required to operate the 11 control valves to maintain the specified setpoints independent of the other processors in the system. Overall plant control functions - 254 -

such as heat recovery loop optimization, steam allocation, and L/G ratio control would be done by HEWAC si:^ce it at eady contains all process variables and lab data. Changes to the process conditions would be accomplished by HEWAC updating setpoints in the individual processors.

The traffic on the communications channel would include status information for each processor, setpoint communication, and plant status information so that the control system can respond to minimize the effect of major process upsets and failures of plant equipment.

One of the attractive features of the distributed system to the operating heavy water plant is the ability to develope and test control strategies on a single system without a major cost or commitment. In summary the distributed architecture satisfies the requirements outlined above very we! 1.

8.0 CONCLUSION

The HEWAC data acquisition system at the Glace Bay plant has played a 'av role in providing the information required by the process control engineers to bring the plant to mature production. It has also been a valuable tool for the plant operators in monitoring the process and in identifying the causes of plant trips and upsets.

A support group of three people are responsible for all software and hardware maintenance. Familiarity with the custom designed software has allowed the support group to respond to changing demands on the system. Despite frequent changes to the software the system availability has averaged 99.5%. The remote multiplexors were a relatively novel feature v/hen they were installed. - 255 -

Although located in a very hostile environment the remote multiplexors have performed very well.

Sufficient understanding and experience with the control characteristics of the plant has been developed to *. -insider defining a computer control strategy- A computer control system appears to be justified on the basis of better process control and optimizing energy consumption. A distributed system architecture best meets the heavy water plant requirements.

9.0 REFERENCES

Y.H. Bajwa, J.C. McCdrdle, "Application of a Computerized Data Acquisition and Presentation System to a Heavy Water Plant" presented at the Canadian Electrical Association Spring Meeting, Toronto, Ontario, March 22-24 1976.

K.J. Bradley, C.J. Lettington, "Development of a Control Strategy for the Glace Bay Heavy Water Plant" presented at the Canadian Conference on Automatic Control, University of New Brunswick, September 24th and 25th, 1973.

ACKNOWLEDMENTS

The authors would like to express their thanks to Mr. D.A. Odedra and Dr. D, Bhattacharyya of the Glace Bay Heavy Water Plant and Dr. D.E. Minns and Mr. L.J. McCormick for their contributions to this paper. PRODUCTION OF HEAVY WATER (D2O) GLACE BAY PLANT

COLD SECTION OF EXCHANGE TOWER EXCHANGE TOWER

AT LOW TEMPERATURES, WATER FLOWS ACROSS GAS BUBBLES UP (TRAYS NOT SHOWN) DEUTERIUM MIGRATES PERFORATED TRAYS THROUGH WATER FROM HYDROGEN SULPHIDE GAS TO WATER 71 \l,^

TOWER WALL FEED :•"(." I••:]""! 1). WATER I >• »A \ '••, y i &5;SS IV / L-*—.-—•>—f-r—'_j—?_• " ?, COLD SECTION (87°F/30°C) HYDROGEN DEUTERIUM FROM GAS SULPHIDE GAS ENRICHES FEED WATER WATER GAS BUBBLE ENRICHED WATER WATER ENRICHED IN DEUTERIUM TO NEXT TOWER DEUTERIUM EXCHANGE to / (PROCESS IS REPEATED) HOT SECTION OF EXCHANGE TOWER

• ol^Z^lllTs^' GAS ENRICHED ,N DEUTER-UM DEPLETED WATER FROM WATER TO RETURN FROM HYDROGEN SUIPIIIDE GAS NEXT TOWER

HOT SECTION (279°F/137°C) DEUTERIUM FROM WATER ENRICHES HYDROGEN SULPHIDE GAS

=\ DEPLETED WATER WAIER

GA5 RUBHIE DEUTERIUM EXCHANGE OCCURS AS OEU1ERIUM FXCIIANGE GAS BUBBLES THROUGH WATER

Pi gure 1. - 257 -

Figure 2. DEUTERIUM PRODUCTION AT G.EHWP

1st flags Ictstsoe Ut «Uoe booster lower booster tower booster tower booster tower

400 pprn 050 4O0 pom DjO 400 ppm D2O 400 ppm D20

200 240 140

comb 1st* 2nd stage

SOOO pom D20 SOOO ppm D20

3rd tug*

15 percent DjO

t2B0

distillabon unit t pnsduc* bnshing 99.73 Dercsnt D,0

| t2B0 ' |kgio«y; 00

^7h r r&?T

EQUIPMENT LAVOUT Figure 3 - 259 -

PLAIMT PROCESS CONTROL

CRNL Computing Centre

Simulation Programs

Chemical Engineering Branch

GLACE BAY CHALK RIVER HEAVY WATER PLANT NUCLEAR LABORATORIES

Figure 4 - 260 -

MASTER-REMOTE COMMUNICATIONS

INTER NORTH IREMOTEI SOUTH I COMPUTER I mamma I COMPUTER | DATA LINK

All data links 4800 baud NORTH SOUTH DATA LINK DATA LINK

MASTER I COMPUTER I

Figure 5 - 261 -

HEWAC DEVELOPMENT EFFORT

System Supplier (12 person-yrs) V/.

•—Consultant (6person-yrs) »;*J PERSON- YEARS AECL 7 person-yrs to end __ zzzzx / of 75 H

• - - » tin.!

72 73 M 75 j 75 77 78 7S •^System Operations! YEARS

Figure 6 - 262 -

HEWAC AVAILABILITY

100

CQ 2 AVERAGE^ 99.5%

98- » 1978 1979 1980 TIME

Figure 7 - 263 -

HEWAC UJMAVAILABILITY-

0.5-

Unavailability Unplanned (75%) Software 40%

Planned 25%

- (1978 JAN to 1980 MARCH)

Figure 8 - 264 -

DISTRIBUTED CONTROL FOR GLACE BAY PLANT

2100 2200 2300 1100 1200 1300 1400 36O0

! ! i i

ho |LQ

HEWAC

—— Process Signals •—• Communications Link HH Processor with Memory O Operator Station & Process I/O

Figure 9 - 265 -

LA HIERARCHIE DES FONCTIONS ESSENTIELLES DE CONTROLE DU REACTEUR CANDU DANS UN SYSTEME DISTRIBUE

par: Pierre Mercier Hydro-Québec

RESUME

Dans les centrales nucléaires de type CANDU les fonctions de régula- tion sont programmées dans deux miniordinateurs centralisés et redon- dants et les fonctions de sûreté (protection) sont confiées à des sys- tèmes analogiques conventionnels. Cet arrangement est le fruit de normes, de considérations économiques et techniques qui sont maintenant modifiées par l'apparition des microordinateurs, le progtè des moyens de communication digitale et le développement des modèles mathématiques des procédés .

A partir des systèmes de régulation et de sGretë installés â Gentilly-2, on analyse les diverses tendances qui affecteront l'implantation des fonctions essentielles de contrôle dans un système distribué. On in- siste surtout sur les caractéristiques que le logiciel des systèmes d'avenir devra incorporer afin de respecter les exigences particu- lièrement importantes pour l'exploitant des centrales nucléaires.

Control funct- •.- in CANDU nuclear generating stations are programmed within two cent ali.ztd and redundant minicomputers while safety func- tions are cohered by conventionel analog systems. This stt-up is a product of standards, economic and technical considerations which are now being modified *-" the maturing of microprocessors, the progress in digital communications and the development of mathematical process mode Is .

Starting from the control and safety systems installed in Gentilly-2, this paper analyses the various trends that will affect the implemen- tation of essential control functions within a distributed system. In particular, it emphasises the characteristics of future software systems that must be built-in in order to comply with important ope- rational requirements of nuclear generating stations

Communication presentee au "IWG/NPPCI Specialists' meeting on distri- buted systems for nuclear power plants" tenu à Chalk River, Ontario du 14 au 16 mai 1980. - 266 -

1.0 INTRODUCTION Le Canada est un des pionniers dans le domaine de la régula- tion par ordinateur des centrales nucléaires. Le système de Gentilly-2 (réf.4), CANDU-600MWe, est un des plus récents et est basé sur deux mini-ordinateurs redondants. Ce type de système a fait ses preuves à Gentilly-1, à Pickering et Bruce et sera probablement installé dans les centrales de la prochai- ne génération.

Cependant les progrès dans la technologie des ordinateurs et certains problêmes de croissance, associés au système centralisé actuel ont provoqué au Canada un examen de la situation (reflO) et les laboratoires travaillent déjà à la mise au point d'un système distribué expérimental (réf.3). Cet effort n'est pas que canadien; en effet, dans plusieurs pays (ref 1 et 11) on éturiie, propose et installe des systèmes basés sur plusieurs ordinateurs de types différents.

Prenant comme point de départ les systèmes de Gentilly-2, cette communication traite de 1 ' adaptabi1ité des fonctions essentielles de contrôle (régulation et sûreté) à un système distribué. L'accent est placé sur le logiciel plutôt que sur 1'équipement .

2.0 DESCRIPTION DES FONCTIONS ESSENTIELLES Les fonctions essentielles de contrôle des CANDU sa retrouvent principalement dans: a) le système de régulation b) les systèmes de sûreté ou de protection Pour chacun, une brève description ainsi que 1'enumeration des principes de conception situera le lecteur.

2 .1 Le système de régulation II est maintenant connu que la régulation des principaux procédés des CANDU est confiée à un système centralisé de deux ordinateurs redondants (réf. 2 et 4). La figure 1 en présente les principales fonctions ainsi que les liens qu'elles ont entre elles; le tableau 1 énumêre, quelques caractéristiques des principaux programmes ou se retrouvent ces fonctions (réf. 5,6,7,8) .

Associés et inséparables de ces fonctions de régulation on retrouve dans les ordinateurs de G-2 tous les programmes d'interface homme-machine, l'exécutif et les programmes servant à la commande et â la surveillance des machines à combustible. Tous ces programmes forment un volumineux ensemble d'environ 800 000 mots de 16 bits qui se répartit de la façon indiquée à la figure 2. - 267 -

2.2 Les systèmes de protection A Gentilly-2 les fonctions proprement dites de sQreté sont remplies par: 1) les deux systèmes d'arrêt d'urgence du réacteur (SAU ifl et SAU #2) 2) le système de refroidissement d'urgence du coeur. (ECC: emergency core cooling system) 3) le confinement (containment) 4) les systèmes de support de sûreté: alimentation électrique d'urgence (EPS) et eau d'urgence (EWS)

Les systèmes doivent être indépendants, fiables, fré- quemment testés et le plus simple possible. En plus, ils sont le reflet des principes canadiens (réf. 12) en matière de sQreté. Ceux-ci exigent notamment que la régulation et protection soient conceptuellement, fonc- tionnellement et géographiquement séparés et qu'en particulier, il y ait deux systèmes d'arrêt d'urgence du réacteur, complètement indépendants.

Dans ce qui suit nous nous intéressons aux SAU et c'est pourquoi leurs principales caractéristiques sont données au tableau 2 .

3.0 LES TENDANCES DE L'AVENIR Les contraintes dont doit tenir compte le concepteur des fonc- tions de contrôle deviennent plus difficiles et sont, souvent contradictoires. D'un côté on cherche à optimiser les équipe- ments des centrales afin de réduire les coûts, de l'autre on spécifie dos conditions de sûreté de plus en plus exigeantes

Fort heureusement les moyens mis à notre disposition évoluent et rendent possible la construction d'équipements plus perfor- mants et plus sûrs. Ces moyens sont les microprocesseurs et les modèles mathématiques de plus en plus exacts des phénomè- nes physiques des procédés. Les paragraphes qui suivent, ex- pliquent comment ces moyens sont pleinement utilisés dans un système distribué des fonctions essentielles de contrôle.

3 .1 L'avenir en régulation

3.1.1 Système centralisé actuel Le système actuel est très apprécié de l'exploi- tant et ses performances à Pickering et à Bruce ont démontré sa très grande fiabilité. Cependant il éprouve des problêmes de croissance propres aux systèmes centralisés.

En ce qui regarde les fonctions essentielles deux problêmes doivent être mentionnés. Premièrement les algorithmes sont de plus en plus complexes car - 268 -

le concepteur veut que son programme puisse faire face au plus grands nombres de situations possibles et veui y intégrer l'information des modèles mathé- matiques pour optimiser le fonctionnement (ie pro- gramme FLLT et CCA). Deuxièmement les fonctions essentielles sont loin deceuxquis'oceupent de 1'équipement. En effet, le personnel spécialisé requis pour programmer et gérer l'ensemble comple- xe des programmes d'ordinateur constitue un inter- médiaire supplémentaire entre l'équipement et l'al- gorithme de contrôle.

Un système distribué pourra améliorer cette situa- tion, si sa conception respecte certaines caracté- ristiques que nous allons maintenant examiner.

3.1.2 Caractéristiques d'un système distribué idéal

1) Définir les fonctions essentielles (FF.) en insistant sur l'indépendance fonctionnelle et la simplification. Ce genre de travail fut ef- fectué pour le CANDU 600 MWe (réf. S). On y constate que, bien qu'actuellement centralisées géographiquement les principales fonctions de régulations de G2 sont fonetionne1lement isolées. De plus, le nombre et la taille des FE sont fai- bles si on prend soin de les définir selon des critères reliés à la nature du procédé à régula- riser et des conséquences de la défaillance d'une fonction sur la marche de la centrale. Le tableau 3 résume la réf. 9. Ainsi, dans un système dis- tribué les FF rudimentaires seraient confiées à un équipement très fiable et beaucoup plus petit que celui actuellement employé. Pour les autres fouctions les caractéristiques de l'équipement dépendront des besoins.

2) Utilisation accrue des fonctions d'optimisation (F0) basées sui les modèles mathématiques des procédés. En effet ces modèles gagnent en pré- cision et il est de plus en plus profitable de les utiliser en régulation pour améliorer le rendement. Un système distribué devrait facili- ter l'emploi des FO puisqu'il sera possible de choisir des calculateurs appropriés diffé- rents de ceux des FE. Cette séparation entre les FO et les FF, implique aussi des communica- tions ordinateur-ordinateur. Ces liens ne doivent toutefois pas rendre le fonetionnment de la FF. "trop dépendant" de la FO. En tout temps, la FE devra pouvoir s'isoler de la FO et maintenir la centrale en marche dans un état - 269 -

ne nécessitant pas la FO (ie puissance rédui te).

3) Un interface homme-machine (IHM) distribué. L'IFM de Geiitilly-2 est déjà d'une taille imposante (voir figure 2) et il devient im- portant de hiérarchiser ce qui est présenté à l'opérateur. Ceci passera par la définition d'un interface réduit (mais suffisamment) associé aux fonctions essentielles qui sera complété par un système plus sophistiqué, utile mais non essentiel. L'interface réduit sera donc indépendant de l'interface sophisti- qué .

4) Emploi accru de programme test La nécessité de vérifier les performances des algorithmes de régulation de G-2 a justifié le développement de programmes de vérification statique et dynamique hors-ligne. Ces program- mes s'avèrent utiles et il est souhaitable que tout le logiciel en profite. Ces programmes sont volumineux (3 à 5 fois la taille du pro- gramme vérifié) et il est utopique dans un système centralisé de les exécuter en ligne. Dans un système distribué, un ordinateur puis- sant effecturait tous les tests détaillés de tous les programmes pendant que chaque micro ne ferait que quelques tests sur ses programmes.

La régulation par ordinateur siutile au CANDU prendra un nouvel essor si les fonctions essen- tielles sont isolées et confiées â de petits or- dinateurs très fiables. En effet, la régula- tion de base sera beaucoup plus simple et l'on pourra profiter d'algoritmes plus complexes mais non essentiels au fonctionnement.

3.2 L'avenir des systèmes de sOreté Les fonctions de sûreté sont essentielles. Jusqu'à tout récemment elles étaient des plus simples et consistaient en des systèmes passifs ou en quelques boucles de déclen- chement rudimentaires.

Cependant ces temps sont révolus et déjà Gentilly-2 est touché par un accroissement rapide du nombre de systèmes, du nombre grandissant de boucles et d'une logique plus complexe causée par le conditionnement des paramètres. En conséquence, il est sérieusement question d'introduire dss micros dans les chaînes de protection des deux systè- mes d'arrêt d'urgence. - 270 -

3.2.1 Tendances des fonctions de sOreté L'on peut maintenant dégager certaines tendances qui favoriseront l'usage des ordinateurs en sfl- r e t ê ••

1) Les systèmes de sûreté deviendront plus comple- xe s • J'ai mentionné plus tôt le conflit que doit ré- soudre le concepteur entre une centrale plus performante et des marges de sûreté exigeante. La solution vient en partie d'une meilleure connaissance mathématique des phénomènes phy- siques (modèle) et des relations de cause à effet des divers paramètres. Puisque la liste des incidents et accidents contre lesquels on doit se protéger s'allonge, il en résultera des systèmes comportant plusieurs mesures dont cer- taines serviront à en conditionner d'autres.

2) Tests automatisés. Afin de s'assurer de la fia- bilité des systèmes de sûreté, l'exploitant doit procéder â des vérifications périodiques de l'équipement. Avec le nombre croissant des tests, il devient nécessaire de les automatiser pour libérer l'opérateur. Encore ici la tech- nologie digitale offre d'énormes possibilités.

3) L'interface homme-machine des systèmes de sûre- té a un urgent besoin d'ordinateur. Ce besoin est criant lorsque l'on compare le panneau du SRR à celui du SAU #1 (voir photo figure 3 et 4) Grâce â l'ordinateur et à l'écran cathodique on parvient à présenter de bien meilleure façon une information beaucoup plus volumineuse.

4) Communication régulation-sûre té. Au Canada tout lien régulation-sûreté est banni. Cette sépara- tion commence au niveau des capteurs et se conti- nue jusqu'aux actionneurs (voir figure 5). Cette situation pourrait changer avantageusement grâce au couplage optique. A Gentilly-2 le système de régulation est beau- coup mieux équipé que les systèmes d'arrêt pour détecter des défaillances de l'instrumentation et pour prévenir l'opérateur. Ceci est non seu- lement dû à l'emploi d'ordinateurs mais aussi au fait que la régulation possède beaucoup plus de capteurs (5000 vs 100) et connait bien l'état de la centrale. Comment alors faire profiter la sûreté de ces avantages sans courir le risque de couplages ou de grossir (compliquer) la logi- que de la sûreté pour analyser l'instrumentation? - 271 -

Soulignons ici que dans d'autres pays on s'en- gage dans la voie de systèmes de sûreté comple- xes et reliés à la régulation (ref 1 et 11). Chose certaine un minimum de risques et beau- coup d'avantages résulterait de l'accepta- tion d'un lien uni-directionnel comme celui pré- senté à Ta figure 6~. ï~ï s 'agit simplement, aux systèmes de sQretë de transmettre tous leurs signaux à la régulation par lien optique. Dans un tel arrangement la régulation ne peut affec- ter la sûreté et celle-ci bénéficie d'un système, aussi puissant que désiré, de surveillance des capteurs.

CONCLUSION Le système de l'avenir prend forme lorsqu'on regroupe les di- vers points discutés plus haut. Ce système est schématisé â la figure 7 et ses caractéristiques touchant les fonctions essentielles de sûreté et de régulation sont: 1) Système décentralisé comportant plusieurs ordinateurs reliés par une voie de communication. 2) Lien optique uni-directionnel entre la régulation et la sûreté 3) Les fonctions essentielles sont programmées dans de petits ordinateurs très fiables et autonomes. 4) Les autres fonctions bénéficieront alors d'équipements mieux adaptés à leur tâche et pourront être programmées en langage de haut niveau. Un tel système n'est pas encore à point. Cependant, il cons- titue un objectif valable pour les chercheurs et les concepteurs de centrales nucléaires. Ses inconvénients comme ses avantages peuvent se discuter selon divers points de vue dont le plus im- portant gravite autour de la fiabilité. Dans cette communication, on s'intérasse surtout aux fonctions essentielles de contrôle. De ce point de vue un système distri- bué l'emporte sur le système centralisé parce qu'il permet avant tout de simplifier et d'isoler au maximum les fonctions essen- tielles tout en permettant l'emploi de fonctions d'optimisation aussi complexes que désirées, mais non essentielles. Cette ca- ractéristique de simplifier et d'isoler l'essentiel du contrôle prend toute sa valeur dans de l'exploitation des centrales nu- cléaires.

REMERCIEMENT L'auteur remercie Messieurs R. Tawa, M. Doyon , J.P. Dietrich et D. Rancourt pour leurs avis dans la préparation de ce texte. PRESSURISSEUR

ALTERNATEUR

I to

TURBINE .DEMARRAGE .PUISSANCE

h CONSIGNE f CONSIGNE MODE REACTEUR PRIORITAIRE MODE TURBINE PWQH1TAIRE

Figure 1: PRINCIPAUX PROGRAMMES DE REGULATION DE GENTILLY-2 - 273 -

REGULATION ESPACE EXECUTIF. DES DE PROCEDES TRAVAIL

COMMANOE ET SURVEILLANCE OU RECHA6EMENT COMBUSTIBLE.

SURVEILLANCE ET

INTERFACE HOMME - MACHINE

TOTAL! 780,000 mols de 16 bits.

FIGURE %

GUANTITE RELATIVE DE MEM0IF1E OCCUPEE PAR LES PROGRAMMES D'ORDINATEUR A GENTILLY-2

WV rt\oi SO - 274 -

•apaq QQQQQ

FIGURE 3 : Panneau du systeme d'arret d'urgence no.l du reacteur de Gentilly-2* - 275 -

FIGURE 4 : Panneau du systeme de regulation du reacteur de Gentilly-2. - 276 -

CENTRALE

IOOEA i IOOEA | 3000 EN 2000 EA 1 1

1 LOGIQUE LDGIQUE ORDINATEUR 1 CABLEE CABLEE REGULATION/SURVEILLANCE |

1 \ # J BARRES INJECTIOI\ ACTIONNEURS

SAU#I SAU**2 _ _ _ _ J J Figure 5' \ SYSTEMES ACTUELS

CENTRALE CAPTEURSJ\ | CAPTEURS | CAPTEURS 1 MICROS

T 1 L_ < MICROS + MIMIS MICROS 1 U/V f, 1 •ie. BARRES INJECTION ACTIONNEURS

i 1 Figure 6: SYSTEMES ENVISAGES

LEGENDEI if- INTERFACE HOMME MACHINE •AV. COUPLAGE OPTIQUE

Pl"\ OPTIMISATION ALARME AFFICHAGE ENTRETIEN DONNEES

i i .

t t t i i f FONCTION FONCTION t. I ESSENTIELLE ESSENTIELLE REGULATION SYSTEME L SAU. 1 SAU. 2 L DE * ! SÛRETÉ TRANSFERT. 1 ! 1

! ! \ I TT Ï -ATIO N ce ÉG U • SYSTÈME D1/HRRET • ECC K • PUISSANCE DU REACTEUR • MACH. A COMBUSTIBLE. D'URGENCE • EPS 1 • PRESS. DU CALOPORTEUR • SERVICES • EWS I • PRESS. ET NIVEAU DU 6.Y. • • CONFINEMENT 1 • FRÉQUENCE DE LA TURBINE.

INTERFACE HOMME MACHINE LOCAL.

FIGURET '.SYSTÈME DE CONTRÔLE IDEAL TABLEAU 1 : ENTREE SORTIE DES PROGRAMMES

PROGRAMME ENTREE SORTIE

NOM (SYMBOLE) DIMEN- (2) LOGI- LOGI- SION EA EN SA SN MESSAGE CEL CEL Régulation de la puissance du réacteur (SRR) 12 K 140 88 27 15 65 21 ,3)7 Recul rapide de puissance (RRP) 1 K 50 14 0 0 10 1 i ©

Carte de Flux (FLU) 32 K 102 28 150 15 110

Régulation de la température du modérateur (RTM) 3 K 17 14 0 3 10 0 51

Régulation de la pression et inventaire du caloporteur(CCA) 10 K 95 11 4 11 17 0 216 I Régulation de la pression des générateurs de vapeur (RPG) 7 K 61 33 11 8 18 2 136 ro Régulation du niveau des générateurs de vapeur (RNG) 7 K 88 61 4 12 20 0 263 co I Régulation de la puissance de la centrale (RPC) 6 K 25 11 4 0 20 1 120 |

Surveillance du turbo-alternateur (STA) 6 K 55 47 4 0 0 1 112

Montée en vitesse de la turbine (MVT) 10 K 22 91 4 0 18 1 192

NOTE:(T) II y a plus d'entrée type logiciel que de sortie puisqu'on y inclut les actions de l'opérateur (T) Plusieurs EA sont répétés d'un programme â l'autre. Ainsi les 28 détecteurs de flux sont lus par SRR, RRP, CCA, RPG et RNG. (T) SRR passe â FLU 16 variable "logiciel"et FLU lui en retourne 16. (£) Les messages de RRP sont traités par SRR. EA: entrée analogique, EN: entrée numérique SA: sortie analogique, SN: sortie numérique TABLEAU 2

CARACTERISTIQUES DES SYSTEMES D'ARRET D'URGENCE DE GENTILLY-2

PARAMETRES SAU § 1 SAU it 2 CAPTEUR CONDI. CAPTEUR CONDI.

1 HAUT FLUX LOCAL 2x34 $ * 2x23 *

2 TAUX LOG (FLUX) 3 CI 3 CI

3 HAUTE PRESSION CALOPORTEUR 6 P * 6 P *

4 BASSE PRESSION CALOPORTEUR 6 P * 6 P * NJ 5 BAS DEBIT CALOPORTEUR. DEBITMF.TRE 6 F * - -

.AP - - 6AP *

6 BAS NIVEAU PRESSURISSEUR 3 L * 3 L *

7 BAS NIVEAU GV 6 L * 6 L *

8 BASSE PRESSION D'EAU D'ALIMENTATION 6 P * 6 P *

9 HAUTE PRESSION ENCEINTE 3 P 3 P

10 MANUEL

NOTES: '• detecteurs de flux en-pile CI: chambre d ' ionisation hors-pile *: declenchement conditionne (puissance, # de pompe, seuil variable) - 280 -

TABLEAU 3

CLASSEMENT DES PRINCIPALES FONCTIONS DE REGULATION DE

GENTILLY-2

FONCTIONS DE REGULATION CRITERES

FONCTIONS ESSENTIELLES (2)

i) puissance du réacteur . procédé rapide 2) pression du primaire . si bris, arrêt 3) pression de la vapeur au GV . ensemble suffisant 4 ) niveau des GV pour maintenir la 5) délestage au condenseur centrale â puissance 6) fréquence du turbo-alternateur cons tante 7) Recul Rapide (STEPBACK)

AUTRES FONCTIONS (î) 8) réserve de réactivité . procédé lent 9) délestage à l'atmosphère . si bris, réglage 10) inventaire du primaire manuel possible 11) température du modérateur

12) retrait des barres d'arrêt 13) calibration des mesures de puissance . procédé très lent 14) cartographie du flux . fonction non périodique 15) mode de fonctionnement de la centrale . si bris, baisse de 16) démarrage de la turbine puissance 17) surveillance de la centrale

NOTES: 1) Seules sont classées les fonctions programmées dans l'ordinateur de Gentilly-2. 2) Chacune possède un interface homme-machine minimum. - 281 -

REFERENCES

, , Proceedings of the IAFA/NPPCI Specialist's Meeting on Use of Computers for Protection Systems and Auto- matic Control , Mlinchen, 11-13 may 197(T

2 A. Pearson, Digital Computer Control in Canadian Nuclear Power Plants Experience to Date and Future Outlook, AECL - 5916,1977.

3 G. Yan, J. L'Archeveque, L.M.Watkins, Distributed Computer Control Systems in Future Nuclear Power Plants, IAEA- SM-226/100, april 1978.

4 R.E. Askwell, R.A. Olmstead, N. Yanofsky, 60QMWe Generating sta- tion Digital Control Computer System; Design Descrip- tion-xx-66400-1, rev 0, June 77.

5 P. Mercier, Aper;us des fondements et regies du contrSle de la puissance du reacteur CANDU 600 MWe, ETN-KI-78-01, j anvier 79.

6 P. Mercier, ContrSle des principaux precedes du caloporteur pri- maire et du generateur de vapeur pour la centrale CANDU-PHW-600 MWe, ETN-RI-78-03, avril 1978.

7 M. Doyon, ContrSle global de la puissance de la centrale Gentilly- 2_, Description Generale 66550-1, fevrier 1979.

8 M. Doyon, ContrSle par ordinateur des procedes de la centrale Gentilly-2, Description Generale 66550-2, fevrier 1979.

9 P. Mercier, P. richer, Les fonctions essentielles de regulation d'une centrale nucleaire CANDU-PMW-6Q0 MWe, communica- tion donnee au congres de 1'Association Nucleaire Canadienne, juin 1978.

10 Record of Station Control Computer Seminar, Ontario Hydro Design and Development Division, april 17-18, 1978, Orangeville, Ontario.

11 J. Bruno, B.M. Cook, D.N. Katz, J.B. Reid, Microprocessors in Nuclear Plant Protection System, IEEE, A 80 102-4, 1980. 12 , Gentilly-2 600 MWe Nuclear Power Station Safety Report, sept. 79. - 282 -

SYSTEMES DISTRIBUES POUR LA PROTECTION DES CENTRALES NUCLEAIRES

P. JOVER Centre d'Etudes Nucléaires de Saclay 9119Ô - Gif-sur-Yvette (FRANCE)

1. - INTRODUCTION Les avantages des systèmes de commande distribués sont présentés généralement de la façon suivante :

- amélioration de l'exploitation, - réduction des coûts, - adaptation au changement de technologie.

Ces avantages sont évidemment très intéressants pour les systèmes de commande des centrales nucléaires. Il y a quelques années,EPRI (Electric Power Research Institute) a montré que le multiplexage des signaux est techniquement possible, qu'il permet de satisfaire les spécifications de disponibilité et qu'il permet de réduire les coûts (1). Depuis, beaucoup de systèmes de commande distribués sont proposés par les constructeurs. Cette note donne quelques commentaires sur l'application du concept de distribution aux systèmes de protection - que faut-il distribuer ? - et. se termine par une brève description d'un système de protection basé sur les microprocesseurs pour les centrales pressurisées en cours de construction en FRANCE.

2. - SYSTEMES DISTRIBUES Un système de commande distribué comprend un certain nombre de sta- tions qui contiennent des unités d'application : ces stations communiquent entre elles à travers un réseau de transmission (Fig. 1). Le concept de distribution implique principalement (a) l'introduction de stations à proximité des capteurs et des actionneurs dans la zone processus (distri- bution géographique), (b) la détermination des fonctions à confier à ces stations (distribution fonctionnelle). Puisqu'une erreur de transmission dans le réseau de transmission peut avoir de sérieuses conséquences, il - 283 -

faut des spécifications sévères pour obtenir une très grande intégrité des données transmises et Line très grande disponibilité du réseau. On doit noter, à ce sujet, qu'un groupe de travail de la Commission Electrotech- nique Internationale (CEI/CT 65) a été mis en place pour définir une norme pour les communications à haut niveau entre stations dans les sys- tèmes de commande distribués (PROWAY = a process data highway). Le premier projet de ce groupe traite des spécifications fonctionnelles (structure du système, protocoles, intégrité des données, disponibilité, etc.). Puisque ce travail doit constituer une norme, les concepteurs devront, plus tard, en tenir compte. Dans le cas de l'application aux centrales nucléaires, il faut considérer d'autres aspects : - les équipements pour le contrôle et la commande sont divisés en deux groupes : équipements importants pour la sûreté, pour lesquels il y a des spécifications particulières, et. les autres équipements. - beaucoup d'équipements et de composants concernant le contrôle et la commande sont placés à l'intérieur de l'enceinte de confinement et peuvent être soumis à des conditions d'environnement accidentelles (température, humidité, pression et radiations). Ces deux points sont développés dans le chapitre suivant. 3. - SYSTBE DE PROTECTION' 5.1. - Sgêçifiçations_partiçulières

On rappelle que le système de protection a pour but de déclen- cher des actions automatiques dans le système d'actionneurs de sûreté. Après le déclenchement d'une action, la séquence prévue doit se poursuivre jusqu'à ce que la tâche de sûreté soit accomplie.

Les exigences fonctionnelles des systèmes de protection dépen- dent du type de réacteur nucléaire. Ces exigences concernent les para- mètres importants pour la sûreté : les diagrammes logiques ou les algo- rithmes pour les fonctions de protection, le nombre et l'emplacement des capteurs et des actionneurs, les objectifs de temps de réponse et de précision. D'autre part, le système de protection doit suivre la régle- mentation en matière de sûreté, en ce qui concerne le critère de défail- lance unique (une défaillance unique ne doit pas empêcher une action de protection), et en ce qui concerne les bases de conception : indépendance et diversité, redondance, intervention de l'opérateur dans l'action de protection, essais périodiques, et qualification des équipements. Enfin, le nouveau concept de défense en profondeur peut conduire à subdiviser le système de protection en sous-systèmes indépendants. - 284 -

3,2. - Svstème_de_groteçtion_distribué

En vue d'examiner ce qui doit être distribué, on doit considé- rer d'abord quelques points qui concernent la possibilité de distribution géographique : - introduction de stations dans la zone processus L'installation de stations intelligentes dans l'enceinte de confinement est intéressante pour économiser les câbles et les pénétra- tions. Mais, il faut considérer le regroupement des capteurs et des actionneurs- Dans l'application aux PWR, par exemple, une grande partie des capteurs du système de protection est située à l'intérieur de l'enceinte, alors qu'une grande partie des actionneurs de sûreté est placée à l'extérieur de cette même enceinte ; pour beaucoup de tâches de protection, les actionneurs placés à l'extérieur de l'enceinte sont com- mandés par des paramètres mesurés à l'aide de capteurs placés à l'inté- rieur de cette même enceinte : il faut donc prévoir des liaisons sûres entre l'intérieur et l'extérieur par l'intermédiaire des stations, et le meilleur moyen pour faire ces liaisons n'est pas évident. En ce qui concerne les équipements à l'intérieur de l'enceinte, la qualification pour les conditions d'environnement accidentelles (classe 1 E) et la maintenance sont des problèmes supplémentaires. - communications entre stations redondantes De façon à respecter le critère de défaillance unique pendant le fonctionnement normal et pendant les essais, il faut installer trois ou quatre stations indépendantes pour déclencher une action de protection. L'effet de filtrage pour les déclenchements intempestifs est généralement obtenu par un traitement des signaux logiques avant décision : ce qui demande des transferts de données rapides et sûrs entre stations redon- dantes, et conduit à des communications deux-à-deux pour éviter les "embouteillages" dans la ligne de transmission. - intervention de l'opérateur dans l'action de protection En plus du déclenchement automatique de l'action de protection, des commandes manuelles de secours doivent être prévues pour l'arrêt rapide du réacteur et pour ls déclenchement des autres actions de sûreté. La réglementation précise que les possibilités de commande manuelle doivent être prévues en salle de conduite pour commander aussi directement que possible les' actionneurs : ceci conduit à installer des liaisons câblées entre la salle de commande et les dispositifs actionneurs.

En conclusion, on remarquera la difficulté de trouver un bon emplace- ment pour les stations, l'emplacement optimal n'est peut-être pas à l'intérieur de l'enceinte, mais à l'extérieur, les liaisons entre capteurs et stations pouvant être faites par des liaisons série, et les liaisons entre stations et cellules de commande d'actionneurs en fil-à-fil (Fig--)- - 285 -

Un autre aspect de l'architecture distribuée concerne la distri- bution fonctionnelle : c'est le cas des systèmes décrits au chapitre suivant. 4. - SYSTEMES DE PROTECTION BASES SUR LES MICROPROCESSEURS Un pas vers les systèmes ^vecarchitecture distribuée a été fait en FRANCE et dans d'autres pays, avec les systèmes de protection basés sur les microprocesseurs en cours de développement pour les applications PWR (2) (5). Ces systèmes utilisent largement les possibilités offertes par les microprocesseurs et les transmissions multiplexers, mais les équipements électroniques sont montés dans des armoires disposées à l'ex- térieur de l'enceinte étanche : on n'économise donc pas de câbles ou de pénétrations pour relier les capteurs aux microprocesseurs.

Le SPIN (Système de Protection Intégré Numérique) est un système de protection basé sur l'utilisation des microprocesseurs : il est développé par FRAMVTOî-E et MERLIN-GERIN en association avec le CE.A., pour les centrales nucléaires PWR, 1300 MMs, 4-Boucles.

Les caractéristiques principales de ce système sont : - distribution des fonctions de protection dans des unités fonction- nelles, - liaisons fil-à-fil entre capteurs et unités fonctionnelles, - cornu nications entre unités redondantes au moyen de liaisons série, - communications entre chaque unité redondante et le système de traitement d'informations centralisé au moyen de liaisons série, - liaisons fil-à-fil entre unités fonctionnelles et système d'action- neurs de sûreté. Le SPIN est un système quadri-redondant (Fig. 3). Il comprend : - quatre unités de traitement redondantes, reliées aux quatre groupes redondants de capteurs, - deux unités logiques redondantes reliées aux deux groupes d'action- neurs de sauvegarde. Ces deux unités logiques redondantes sont commandées par les signaux logiques créés dans les quatre unités de traitement. Il y a deux niveaux de redondance : - redondance au niveau des déclenchements partiels (logique 2/4 avec possibilité d'inhibition), - redondance au niveau de la commande des actionneurs (logique 2/2 pour chaque groupe d'actionneurs de sauvegarde). - 286 -

Sept unités fonctionnelles dans chaque unité de traitement redondan- te sont prévues pour l'acquisition des mesures en provenance des capteurs, les traitements et le vote en 2/4 avec inhibition- Une unité fonctionnelle communique avec les trois unités fonctionnelles homologues des trois autres unités de traitement redondantes, par l'intermédiaire de mémoires- tampon et de transmissions série. Une bonne séparation physique et élec- trique est obtenue par l'utilisation de fibres optiques. Il y a quatre unités spécialisées pour les transmissions série (une pour l'émission, et trois pour la réception), dans chaque unité redondante. Deux unités de transmission série supplêmentairessont prévues pour les liaisons avec la salle de commande centralisée.

L'ensemble du système utilise cinquante-deux microprocesseurs (MDTOROLA 6800).

5. - CONCLUSION Le concept de distribution pour les systèmes de protection n'est pas encore largement développé, à cause des difficultés dues aux spécifica- tions particulières de ces systèmes. Cependant, l'utilisation de nouvelles technologies, telles que les microprocesseurs et les composants pour les transmissions série, conduit à des nouvelles architectures proches de celles des systèmes distribués.

REFERENCES (1) A.B. LONG, Assessment of new instrumentation and control technologies Remote multiplexing a case study, IAEA-SM-226/76, CANNES (France), 24-28 Avril 1978. (2) J.M. GALLAGHER, et al., Design of internal architecture for Westinghouse microprocessor based integrated protection system, IAEA-SM-226/112, CANNES (France), 24-28 avril 1978.

(3) J.L. SAVORNIN, et al., Système de Protection Intégré Numérique. IAEA-SM-226/93, CANNES (France), 24-28 avril 1978. 7.one "Processus" Zono "Salle de conduite" Li^ne iie transmission

Coupleur lif.ne Coupleur ligne Coupleur li.gne

Station (K) Station (K+1) Station (N) I

CO

Couplours Coupleurs Coupleurs I Appli cation Application Application • o O Ecran Capteur Actionne;ur Capteur Actionneur r Clavier

l.-jj^. 1 : Systcme dc conminiidc distrilnio. iftne de trarif.mi ni.ion

to oo oo

jMultiplexeur

Captour

Batiment Reacteur Batiment des Auxiliaire

r[ifjj__2 : Systemo do protocf.ion distribu« Station '?. Station Gtation Station 3 — .1 Centrale — 1 -z — 1 — 2. •i •

Salle tie conduiti 00

Station A Station B

new •SS9DBRR39 ssra 0 O O O Capteur 1 Capteur 2 Capteur 3 Capi.our k Actionncur Actionneiir "Train A" "Train B"

VJ&. \ : S I' I N - 290 -

THE OPERATOR'S ROLE AND SAFETY FUNCTIONS by W.R. Corcoran, D.J. Finnicum, F.R. Hubbard, III, C.R. Musick and P.F. Walzer

ABSTRACT

A nuclear power plant can be thought of as a singls system with two major subsystems: equipment and people. Both play important roles in the nuclear safety. Whereas, in the past, the role of equipment had been emphasized in nuclear safety, the accident at Three Mile Island (TMI) and its subsequent investigations point out the vital role of the operator. This paper outlines the operator's roles in nuclear safety and suggests how the concept of safety functions can be used to reduce economic losses and increase safety margins. - 291 -

THE OPERATOR'S ROLE AND SAFETY FUNCTIONS

INTRODUCTION "safety functions." Safety functions are a group of actions iha! prevent core melt or minimize radiation TMI demonstrated that nuclear plants are conserva- releases to the general public. They can be used to provide tively designed and operated such that there is only a a hierarchy of practical plant protection that an operator small probability of an event seriously affecting public should use. This paper focuses on the pressurized water hcalth and safety. The TMI plant was pushed beyond its reactor as provided by Combustion Engineering, but design basis, yet very little radiation was released to the is applicable, with formal changes, to other designs general public. However, TMI also emphasized that the and types. emotional strain and financial losses of the people living "An accident identical to that at Three Mile Island is in the area around the plant, the electrical power con- not going to happen again." said the Rogovin investi- sumer, and the utility owners and managers can be severe. 12 1 gators. ' The next serious threat to safety will be different Much investigation"" " and reflection has been done since from the TM I sequence. To concentrate design, manage- TMI to improve equipment and operator performance, ment and operations improvements on the specific thus making such events even less likely in the future. sequence at TMI is therefore unwise. The concepts put During the course of the Three Mile Island (TMI) forward in this paper are intended to help the operator event and subsequent investigations, frequent reference avoid serious consequences from the next unexpected was made to the operator's "mindset" during the acci- threat. dent.'" The inference was that the operator's training and experience had not prepared him to fully recognize THE OPERATOR'S ROLE IN NUCLEAR SAFETY the situation that was unfolding in front of him."':i His The plant safety evaluation uses four inputs in pre- "mindset" caused him to ignore or reject certain infor- dicting the results of an event (Figure 1): the event mation that was essential for him to analyze the situation initiator, the plant design, the initial plant conditions properly and take timely correct action. and set up, and the operator actions. Ifany of these inputs The designer's "mindset" of the operator's role in plant are not as assumed in the evaluation, confidence that safety was also reviewed, designers make assumptions the consequences will be as predicted is reduced. of the operator's role, both during normal plant opera- Based on the safety evaluation, the operator* has tion and during plant accidents. This information must three roles in assuring that the consequences of an event be eonveyd to the operator in a practical form. The will be no worse than the predicted acceptable results. method us d to accomplish this has been through the These three operator roles (Figure 2) are to: plant op.rating and emergency procedures guidelines 1. keep the plant set up so that it will respond properly and the safety analysis report including the technical to disturbances. specifications. However, over the years, the number and 2. operate the plant so as to minimize the likelihood si/e of these procedures have become very large and and severity of event initiators and disturbances, difficult (or an operator to use. Moreover, the safety and analysis report was never primarily intended for that 3. assist in accomplishing safety functions during the purpose and the technical specifications are seldom event. considered to be an operational aid. Proper execution of these three roles will keep the con- The intent of this paper is to outline the operator's sequences of design basis events within bounds and will role in nuclear safety and to introduce the concept of tend to reduce the consequences of events that have not been evaluated.

) •In this context, the term operator means primarily ihe personnel in direct \ command of the plant, hut also includes all members of ihc utililv learn (hat \ contnhule to effective operation. OPfRATOR INITIAL PLANT ACTION k- CONDITIONS ANf'SETUP 1 1

LANT SAFfcIV EVALUATION

I II II 1

PWtDICltD ACCEPTABLE RESULTS

Fig. J: Operator's role during an event as assumed in the safety evaluation process Fig. 2: The operator'* ro/es in nuclear safety - 292 -

Plant Set i'/i present will have difficulty in operating and maintaining In keeping the plant set up to respond properly to the plant and in responding to adverse events. A second adverse events, the operator must treat the plant as a concern is the locations of the operators and their activi- complete system consisting of equipment and people. ties.- If the people assigned to the station are not property Therefore, proper plant set up involves both equipment positioned, or are involved in activities that distract them functionability and personnel readiness. from plant operation., they are not ready. The state of In keeping the plant equipment set up. the operator mind and body of each operator is the third concern, is guided by the equipment functionability considered as his ability to respond to adverse events will be reduced in the "Limiting Conditions for Operation" and "Sur- if he is, for example, tired, sick, on medication, dis- veillance Requirements" in the technical specifications traught or has used alcohol. This should be specifically as shown in Table I. ANS Standard 58.4 provides addressed in shift turnover procedures. The final con- guidance for determining the minimum characteristics sideration is his degree of training, specifically, the of a proper plant set up. Although the use of the existing adequacy of his initial training and the- frequency of technical specifications has not led to any adverse con- his retraining. The Institute for Nuclear I'ower Opera- sequences, there is room fora great deal of improvement. tions (1NPO) is expected to establish programs dealing Implementation of ANS Standard 58.4 in developing with these issues."" technical specifications would increase the level of Fewer, Milder y.vents assurance that the plant equipment is set up properly. Personnel readiness likewise has four considerations, The operator's second role is to minimize the frequencv the first of which is the number of people available. If and severity of adverse events.* To fulfill this role. 'he there aie not enough operators on hand, those that are operator must have a good understanding of the plant and its capabilities, know the operating slate of the plant, know the planned changes in the operating state, be TABLE I aware of plant activities that may affect the operating EQUIPMENT FUNCTIONABILITY CONSIDERATIONS stale of the plant, and always be prepared for an un- planned event. 1. Status of Applies to equipment and component equipment operability. Take, for example, maintenance, a plant activity that Examples: A. Number of ECCS pumps could affect the plant operating slate. The operator operable should ensure that redundant equipment is operating, B. Ability of rods to insert that backup systems and equipment are ready and into the core within a properly lined -ip and that the plant operating state is specified time C. Number of diesel generators consistent with the equipment available to mitigate operable possible disturbances. In particular, if maintenance were planned on the feedwater system, it n;ay be possible to 2. Operating state Applies to system or component actions of equipment or describes the position or running schedule this maintenance to correspond with other condition of equipment. activities that require operation at a lower power where Examples: A. Valve position one pump is adequate. That way the system could tolerate B. Control rod position the loss of one pump. The objective is to maintain plant C. Setpoints of the reactor safety margins by avoiding unnecessary challenges to protection and engineered plant protection systems. Also, the operator should be safety features actuation prepared for the possible loss of the remaining pump systems by verifying the operability of the auxiliary feedwater 3. Values of process Applies to flows, temperatures, system and being ready to take the appropriate corrective parameters pressures, etc. actions if required. Examples: A. Reactor coolant specific activity Appendix 1 proposes four categories of practical B. ECCS tank contents guidelines that an operator could use in incident preven- C. Thermal and hydraulic tion. However, such suggestions could bt counter- condition of the reactor productive if translated into hard and fast rules or coolant or primary coolant applied without thinking. The operator must always 4. Condition of Applies to the preservation of evaluate the situation at hand when applying any rules. equipment and quality An example of this is the instruction to plant operators structures Examples: A. Integrity of fission product not to Jet the reactor coolant system "go solid." The barriers purpose for this instruction is to prevent possible over- B. Existence/growth of flaws stress of the reactor coolant system piping. At TMI. the in components C. Monitoring of radiation damage • By emphasising the operator's role in preventing initialing e\cnls. we do not minimize the role of ha'dware. Reference 7 isa recent study highlighting potential (Derived from Table 1 of ANS Standard 58.4, Reference 5) advances in this area. - 293 -

operators followed this instruction by turning off the The relationship between these classes is shown on safety injection pumps based on the high level indica- Figure 3. The arrows signify that the vita! auxilaries tion in the prcssurizer. This was done without consider- are necessary to support the other safety functions. The ing the reactor coolant system temperature and pressure plus signs indicate that ic is necessary to prevent core indications or asking how the system could be solid when melt, maintain containment integrity and control in- the pressure was low enough for the safety injection direct radioactive releases in order to limit the release .system to be actuated. The operators apparently followed of radioactivity to the general pub'ic. In all safety func- a rule without evaluating the situation at hand ami they tions, the word control means accomplishment of the got into trouble. safety function such that core melt is prevented or radioactive releases are kept within acceptable limits. Accomplishment of Safety Functions Control involves manual or automatic actuation of Assisting installed equipment in the accomplishment equipment, or the natural passive capabilities built into of safety functions is the operator's third role. He needs the plant. For example, the preferred method of reac- to monitor the plant to verify that the safety functions tivity control is insertion of the control rods followed are accomplished. In addition, he has to actuate those by boration if the shutdown is necessary. However, in systems that are not fully automated and intervene where the hypothetical case where the control rods do not the automatically actuated systems are not operating insert, reactivity control can still be achieved through as intended. There are three prerequisites to the fulfill- negative moderator reactivity feedback (natural feed- ment of this role: back) followed by boron injection (personnel and 1) information that identifies the plant state, equipment action).181 The systems listed in the vital 2) procedures that cover the situations encountered auxiliaries and indirect radioactive release classes are during events, and not exhaustive, and are provided only as an indication 3) comprehensive training to use the information and of what systems should be considered. procedures to best aovantage in responding to The anti-core melt class contains five safety functions: events. Reactivity control, reactor coolant system (RCS) inven- Application of the concept of safety functions can be tory control, RCS pressure control, core heat removal, used to make significant improvements in each item and RCS heat removal. The purpose of the first anti-core above. melt safety function, reactivity control, is to shut the reactor down and keep it shut down, thereby reducing SAFETY FUNCTIONS The operator needs a systematic approach to mitigat- ing the consequences of an event. The concept of "safety TABLED function" introduces that systematic approach and SAFETY FUNCTIONS presents a hierarchy of protection. If the operator can quickly identify the initiating event from the symptoms Safety Function Purpose and correct the problem from his event procedures, carrying out the safety functions is implicit. If the opera- Reactivity Control Shut reactor down to reduce heat production tor has difficulty for any reason, the systematic safety Reactor Coolant System Maintain a coolant medium around function approach allows accomplishing the overall task Inventory Control core of mitigating consequences. A safety function is defined Reactor Coolant System Maintain the coolant in the proper as a group of actions that prevent core melt or minimize Pressure Control state radiation releases to the general public. Actions may Core Heat Removal result from automatic or manual actuation of a system Transfer heat from core to a coolant (reactor protection system generates a trip, operator Reactor Coolant System Transfer heat from the core coolant aligns the shutdown cooling system), from passive system Heat Removal performance (safely injection tanks feed water to the Containment isolation Close openings in containment to reactoi coolant system), or from natural feedback in- prevent radiation releases herent in the plant design (control of reactivity by voiding Containment Temp- Keep from damaging containment erature and Pressure and equipment in the reactor). Control There are ten safety functions needed to mitigate Combustible Gas Remove and redistribute hydrogen events and contain stored radioactivity (Table II). These Control to prevent explosion inside con- safety functions may be divided into four classes: tainment Maintenance of Vital Maintain operability of systems 1) Anti-core melt safety functions Auxiliaries needed to support safety systems 2) Containment integrity safety functions Indirect Radioactivity Contain miscellaneous stored radio- 3) Indirect radioactive release safety functions Release Control activity to protect public and avoid 4) Maintenance of the vital auxiliaries needed to distracting operators from protec- support the other safety functions tion of larger sources - 294 -

the amount of heat generated in the core. Reactivity is can be kept within bounds by action of the primary safety controlled in the short term by insertion of the control valves. In the event that RCS inventory and (or pressure rods and/or through the natural feedback mechanism becomes inappropriately low due to an opening in the of voiding in the reactor coolant, in the long term, reac- reactor coolant pressure boundary or excessive cooling tivity is controlled by the addition of borated water to the of the reactor coolant system from excess steam flow. reactor coolant system. Borated water can be added to RCS inventory is maintained by injection of borated the reactor coolant system using the charging and boric water by the safety injection system or the safety injection acid addition portions of the chemical and volume control tanks. Figures 5 and 6 are schematics of the PWR show- system, the high and low pressure safety injection system ing the execution of these two safety functions. and /or the safety injection tanks. Figure 4 shows some The purpose of fourth anti-core melt safety function, of the systems that can be used to accomplish this function. core heat removal, is to remove the heat generated in The purpose of the second and third anti-core melt the core by radioactive decay and transfer i! to a point safety functions, reactor coolant system (RCS) pressure where it can be removed from the RCS to prevent the and inventory control, is to keep the core covered with fuel from melting. This is accomplished by passing a an effective coolant medium. RCS pressure control can coolant medium through the core to a heat removal involve either pressure maintenance or pressure limita- point Normally, the reactor coolant pumps are used tion. Likewise. RCS inventory control can involve cither to provide forced reactor coolant flow through the reactor inventory maintenance or inventory limitation. Under core to the steam generators. In the absence of forced normal circumstances, RCS pressure and inventory reactor coolant flow, the core can still be cooled by a control is maintained automatically by the pressurizer natural circulation induced by a temperature differential pressure and ievel control systems in conjunction with from the steam generators to the core. (This implies that the reactor coolant system pressure boundary. These the steam generators must be available to act as a heat systems use the pressurizer spray valves and the letdown sink). If natural circulation cannot be established, heat system to control pressure and inventory respectively, can be removed from the core by boiling and movement and they use the pressurizer heaters and charging system of the steam so a point such that it can be discharged to maintain pressure and inventory respectively. If the through a break in the reactor coolant system piping. pressure and level control systems are unable to limit (See Figure 7) RCS pressure and inventory, the pressure and inventory The final anti-core melt safety functions is RCS heat

ANTI-CORE MELT ANTI-RADIOACTIVITY RELEASE

• REACT |V!TY CONTROL CONTAINMENT INTEGRITY • INDIRECT • RCS INVENTORY CONTROL RADIOACTIVE RELEASE CONTROL • RCS PRESSURE CONTROL • ISOLATION FUEL POOL COOLING • PRESSURE/TEMPERATURE WASTE PROCESSING • CORE HEAT REMOVAL CONTROL SPRAY CHEMICAL ADDITION • RCS HEAT REMOVAL • COMBUSTIBLE GAS CONTROL

MAINTENANCE OF VITAL AUXILIARIES

ULTIMATE HEAT SINK ELECTRIC POWER COMPONENT COOLING WATER INSTRUMENT AIR HABITABILITY

Fig. 3: Classes of safety functions - 295 -

Systems to accomplish anti-core meli safely functions

Fig. 4: Reactivity Control i 4-

fig. 5: RCS Pressure Control Fig. 8: RCS Heof Removal

removal. The purpose of this safety function is to transfer heat from the core coolant to another heat sink. If this is not done, core heat removal will not be possible. RCS heat removal is normally accomplished by transferring heat from the reactor coolant to the secondary system in the steam generator. The secondary system water is supplied by the main feedwater system or the auxiliary feedwater system. Reactor coolant heat can be trans- ferred to the component coiling water via the shut- down cooling heat exchanger, provided that the reactor coolant system pressure is less than the shutdown cool- ing system pressure interlock setpoint. If no other heat sink is available, reactor coolant system heat removal can also be accomplished by discharging the hot reactor coolant directly into the containment through a pressure boundary opening of a primary relief valve. (See Figure 8) Fig. 6; RCS Inventory Control The foregoing discussion of the five anti-core melt - 296 -

Systems *o accomplish containment integrity safety functions

I"" |=»C: "

Fig. 9: Isolation g. 70." Pressure/Temperature Control safety functions illustrates that each safety function can be accomplished by a multiplicity of systems, and, in addition, many of the systems support more than one safety function. Under some circumstances, the execu- tion of one safety function causes another safety function to be accomplished. Particular methods of accomplish- ing one safety function sometimes facilitate and some- times prevent a particular method of accomplishing another safety function. This interaction, or snyergy among the safety functions in an important feature of this concept. The containment inlegrity safely function class con- tains three safety functions: containment isolation, containment pressure and temperature control and combustible gas control. The primary objective of these safety functions is to preve.it major radioactive release by maintaining the integrity of the containment structure. Accomplishing the first safety function, containment isolation, assists in maintaining containment integrity by ensuring that all normal containment penetrations are closed off. Containment Isolation system is accom- Fig. 71: Combustible Gas Control plished by sensors for measuring containment pressure, electronic equipment to generate and transmit an isola- tion signal when the containment pressure exceeds a temperatures within prescribed limits. Containment setpoint, and a set of valves for isolating each contain- pressure and temperature are controlled using the con- ment penetration. (These valves are generally part of tainment spray system and the containment cooling other systems also.) Each containment penetration is system. (See Figure 10) provided with two isolation valves, one inside contain- Likewise, combustible gas control, the third contain- ment and one outside containment. (See Figure 9) ment integrity safety function, is needed to prevent The purpose of the second containment integrity containment overstress caused by explosion of hydrogen safety function, containment temperature and pressure gas inside containment. The hydrogen would evolve control is to prevent overstress of the containment from metal-water reaction in the event of failure of one structure and damage to other equipment from a hostile or more of the anti-core melt safety functions. Hydrogen environment by keeping containment pressure and gas is removed from the containment atmosphere by - 297 -

the hydrogen recombiners. The containment spray dence are those functions for appropriately maintaining system and the fan coolers can also help in combustible a core cooling medium. To achieve this, actions must be gas control by redistributing the hydrogen gas through- accomplished to maintain an adequate reactor coolant out containment, thus preventing the formation of system inventory and an appropriate reactor coolant flammable pockets of hydrogen gas. (See Figure 11) system pressure. Finally, if core heat removal is not The third safety function class, indirect radioactive carried out, then reactor coolant system heat removal release control, contains only one safety function; control is irrelevant. Not only should the operator keep this of indirect radioactivity leleases. The purpose of this hierarchy in mind, but he should also recognize the need safety function is to prevent radioactive releases from for the vital auxiliaries to carry out these safety functions. sources outside containment. These sources include the spent fuel pool and the radioactive wastestorage facilities Multiple Success Paths (gaseous, solid and liquid, including radioactive coolant). Nuclear power plants are designed so that there are two The systems used to control releases from these sources or more ways that can be potentially used to accomplish include the radiation monitoring system, the spent fuel safety functions. That is, for each safety function there pool cooling system and the waste management and are several possible success paths. Table 3 lists those processing systems. systems and subsystems in the plant which are typical The fourth safety function class, maintenance of vital of those in success paths which accomplish the anti-core auxiliaries, likewise includes only one safety function; melt safety functions. The success paths shown here are maintenance of the vital auxiliaries. The systems used some of the possible success paths which apply to various to accomplish the nine safety functions discussed above events. In general, the effectiveness of a particular success are all supported by various auxiliary systems. These path for accomplishing a safely function depends upon auxiliary systems provide such services as instrument what systems are operable in the plant and on whether air needed for opening and closing valves, electric power or not the process variables are within the design range for running pump motors and operating instruments, of the particular system or subsystem that will be used. and an ultimate heat sink to which RCS and core heat !n other words, the method of accomplishing a safety can be transferred. Vital auxiliaries must be maintained function depends on the plant state at the time the func- in order to successfully accomplish the other safety tion is to be executed. This is the state that exists at the functions. time of an event, as affected by the event, and by operator Each anti-core melt safety function has priority relative and system actions. to the others as shown in Figure 12. In general, reactivity To accomplish the safety functions, the operator does control is the foremost function because the amount of not need to know what event has occurred. He does, heat that must be removed from the core is determined however, need to know what safety functions must be by how well this function is accomplished. Next in prece- accomplished, what success paths are possible and the conditions of the plant. This information defines the state of the process variables and the state of the plant

REACTIVITY equipment. The plant state can be correlated to the CONTROL appropriateness and availability of the various success paths for a given safety function. Table 4 describes the state for three possible core heat removal success paths and Table 5 identifies some of the systems needed to accomplish the anti-core melt safety functions for three

RCS events: turbine trip, small reactor coolant system pipe PRESSURE CONTROL break and large reactor coolant system pipe break. Both tables demonstrate the dependence of the method of accomplishing a safety function upon the conditions which exist at the time the function is to be executed. To reword, the means of mitigating an event depend on the plant siate produced by the event. MAINTENANCE OF VITAL CORE HEAT REMOVAL AUXILIARIES Combustion Engineering currently uses Sequence of Events Diagrams'9' to represent the success paths avail- able to mitigate an event. Sequence of Event Diagrams are intended to illustrate the possible ways to accomplish each safety function challenged duringa particularevent. Figure 13 shows a portion of a typical Sequence of Events RCS HEAT REMOVAL Diagram. These diagrams present the success paths with the appropriate system actions. Both automatic and fig. 12: Hierarchy of anti-core melt safety functions manually actuated system actions are shown. Sequence - 298 -

TABLE III TYPICAL SUCCESS PATHS FOR THE ANTI-CORE MELT SAFETY FUNCTIONS

ANTI-CORE MELT POSSIBLE SAFETY FUNCTIONS SUCCESS PATHS ASSOCIATED EQUIPMENT* Reactivity Control Control Element Drive Mechanism Control System, Control Element Assemblies, Motor Generator Sets. Chemical and Volume Control System (charging and letdown), Refueling Water Tank Reactor Protection System, Reactor Trip Switchgear, Control Element Assemblies. Chemical and Volume Control System, Boric Acid Makeup Tank Reactor Protection System. Reactor Trip Switchgear Control Element Assemblies, Engineered Safety Features Actuation System, Safety Iniection System Refuelinp. Water Tank Voiding, Engineered Safety Features Actuation System. Safety Iniec- tion Systems, Refueling Water Tank.

Reactor Coolant System Pressunzer Pressure Control System. Pressunzer Spray Valves. Pressure Control Pressunzer Heaters. Reaclor Coolant Pumps. Primary Safety Valves, Auxiliary Spray Valves, Chemical and Volume Control System. Refueling Water Tank.

Reactor Coolant System Pressunzer Level Control System. Chemical and Volume Control Inventory Control System — (Letdown and Charging) Engineered Safety Features Actuation System, Safety Injection Sys- tem, Refueling Water Tank.

Core Heat Removal Reactor Coolant Pumps. Steam Generators. Shutdown Cooling System. Steam Generators (and RCS heat removal),Isubcooled natural circu- lation], Shutdown Cooling System Steam Generators (and RCS heat removal), [reflux heat transfer natural circulation]. Shutdown Cooling System.

Reactor Coolant System Main Feedwaler System, Turbine Generator Control System. Con- Heat Removal denser, Steam Bypass Control System, Turbine Bypass Valves. Shut- down Cooling Heat Exchanger (component cooling water side). Main Feedwatei System, (runback). Turbine Generator Control System. Auxiliary Feedwater System. Steam Bypass Control System. Turbine Bypass Valves, Condenser, Shutdown Cooling Heat Exchanger (com- ponent cooling water side). Main Feedwater System (runback), Turbine Generator Control System, Auxiliary Feedwater System, Atmospheric Steam Dump halves, Shut- down Cooling Heat Exchanger (component cooling water side). •Vital Auxiliaries are omitted from the list.

TABLE IV CORE HEAT REMOVAL SUCCESS PATHS FOR VARIOUS PLANT STATES

SAFETY SUCCESS PATH EXAMPLES OF INITIAL PLANT STATE FOR WHICH SUCCESS FUNCTION FROM TABLE 2 PATH APPLIES IMMEDIATELY FOLLOWING EVENT INITIATION Core Heat 1 o Reactor Coolant System Intact Removal o Power Available to Reactor Coolant Pumps o Reactor Coolant Pumps Intact o Reactor Coolant System Subcooled o Reactor Coolant Pump Auxiliary Systems Functional

Core Heat 2 o Reacior Coolant System Intact Removal o Reactor Coolant Subcooled o Steam Generator Intact

Core Heat 3 c Reactor Coolant System Intact Removal o Reactor Coolant Saturated o Steam Generator Intact - 299 -

TABLE V TYPICAL SYSTEMS USED TO ACCOMPLISH ANTI-CORE MELT SAFETY FUNCTIONS FOR THREE EVENTS

EVENT Safety Turbine Trip Small RCS pipe break with loss of Large RCS pipe break with loss of Function off-site power as a result of turbine off-site power as a result of turbine trip. trip. Reactivity Control Element Assemblies, Control Element Assemblies, (Voids), Safety Injection System, Control Chemical Volume and Control Sys- Safety Injection System, Refueling Refueling Water Tank tem, Boric Acid Makeup Tank Water Tank RCS Pressure Pressurizer heaters, Pressurizer Safety Injection System, Refueling Control sprays Safety Injection System, Refueling Water Tank, Safety Injection Tanks, RCS Inventory Chemical and Volume Control Water Tank, Containment Sump Containment Sump Control System (charging, letdown) Core Heat Reactor Coolant Pumps, Steam Natural circulation, Steam Genera- (Boiling) Removal Generators, Shutdown Cooling tors, Shutdown Cooling System System RCS Heat Main Feedwater System, Turbine Auxiliary Feedwater System, At- (Break) Removal Bypass System, Condenser, Tur- mospheric Steam Dump System, bine Generator Control System Shutdown Cooling System, Turbine (trip) Generator Control System (trip) Vital Non-Emergency AC Power, Instru- Diesel Generators, Component Diesel Generators, Emergency DC Auxiliaries ment Air. Component Cooling Cooling Water, Nuclear Service Power Water, Non-Emergency DC Power Water, Emergency DC Power

-» TO OTHER SAFETY FUNCTIONS

PRESSURIZER AUXILIARY SPRAY fPRESSURIZER\ SPRAY VAIVES SPRAY TO CONTROL VALVES PRESSURE PRESSURE INCREASE HIGH TRAIN A TRAIN B TRAIN A TRAIN B

I —I

CHARGING PUMPS /PRESSURIZES PRESSURIZER HEATERS (CHEMICAL AND VOLUME .^INCREASE HEAT TO CONTROL PRESSURE CONTROL SYSTEM) PRESSURE DECREASE \ LOW ^PRESSURIZER PROPORTWNAl BACKUP PUMP A PUMP 8 PUMP C LEVEL TO INCREASE PRESSURE

POWER OPERATED RELIEF VALVES OPEN TO LIMIT PRESSURE INCREASE TRAIN A TRAIN B

RCS PRESSURE CONTROL

Fig. 13: Sample section of sequence of evenfs diagram - 300 -

of Events Analysis is currently required by the NRC state and therefore determine the safety functions in requirements for Safety Analysis Reports,'"" and Com- jeopardy.) bustion Engineering has used Sequence of Events Anal- Currently, an operator responds to an event by fol- yses as a design review tool for San Onofre Units 2 & 3. lowing one of the event specific emergency procedures Forked River. St. Lucie Unit 2 and for our System 80IM of which there are N. If none of the event specific pro- Standard Safety Analysis Report.'"• '2| '" In performing cedures apply, he resorts to an unwritten (N+l)" (pro- this work, it has been found that this type of technique nounced "N plus first") procedure. Simply stated, he is essential for the understanding of how the operator does what he thinks he should to mitigate the event. The and plant systems work together to mitigate the conse- safety function concept and making the procedures plant quences of events. state dependent can be used to improve the N current emergency procedures as suggested in Reference 16. In Use of the Safety Function Concept to Assist the Operator addition, these approaches can be used to develop a The safety function concept, which incorporates the documented version of the (N+l)" procedure. principles of safety function hierarchy and multiple Assuming the use of the safety function concept. success paths dependent on the plant state, can help Figure 15 summarizes operator actions during an event. the operator fulfill his role of assisting the plant systems Using the safety function concept, the individual pro- to mitigate the consequences of an event. In order to cedures can be standardized. A typical procedure would assist in accomplishing the safety functions he needs identify, for a given set of plant symptoms, what safety the following: functions must be accomplished, what automatic systems 1) Sufficient and intelligible information about the are available to accomplish them, which backup systems plant state must be actuated if the automatic systems fail, and what 2) Comprehensive procedures prescribing preferred the expected plant response is. Likewise, the safety func- and alternate success paths for each safety function tion concept can be used to handle, in a single procedure, 3) Adequate training in the concept and execution of events which produce similar plant states. ; safety functions The operator's actions during an event depend on the safety functions which need to be accon.olished and the The rectangles in Figure 14 define the judgments needed success paths which can be used. The operator deter- to be made during an event. The information needed mines this by the symptoms, not by knoving what includes the plant state produced by the event which specific event is taking place. For the situation where leads to identification of the safety functions in jeopardy, either none of the previously developed procedures and to identification of systems available to accomplish apply or the plant did not respond as expected, the the safety functions. It is necessary to consider these (N+l)" procedure would provide the operator with both information needs in the design of the control room 4 a set of guidelines to identify the safety functions in displays." '"{Note: The operator does not need to know jeopardy and the success paths available, and a checklist the initiating event as long as he can determine the plant for assuring that all safety functions are accomplished. All N+l procedures should reflect the safety function concept. The main benefit of this approach is that guid- PLANT INITIATING PROCESS EVENT ance will be provided for all eventualities. CONDITIONS In addition to the safety function concept, the emer- gency procedures should incorporate some common SAFETY FUNCTIONS IN JEOPARDV sense priorities for the operator. Establishing operator priorities, such as those in Table 6, suggested by Dr. E. L. Zebroski of NSAC, helps the operator avoid overlooking SUCCESS PATH SUCCESS PATH NOt BEING AVAILABILITY important tasks because of his attention to less impor- EXECUTED THREATENED tant ones. In structuring operator training, the safety function concept is meaningful because it contributes to a more comprehensive awareness of how the plant functions HOW TO RESTORE AVAILABILITY PRINCIPAL OF ALTERNATE as a unit and how the various systems work together SUCCESS PATH SUCCESS PATHS

TABLE VI OPERATOR PREVENTION PRIORITIES

HOW TO SELECT PREVENT MAJOR RADIATION RELEASE/CORE MELT ALTERNATE SUCCESS PATH PREVENT MAJOR EQUIPMENT DAMAGE PREVENT MINOR EQUIPMENT DAMAGE Fig. 14: Operator information needs during crisis PREVENT ADMINISTRATIVE VIOLATIONS - 301 -

because it is complete and understandable. The safety function concept is beneficial in the review of past experience. At Combustion Engineering, the Availability Date Program is the activity which collects experience data from operating plants. The importance of occurrences is evaluated with respect to its effects on safety (unction maintenance. A hierarchy of importance is assigned to effects such as: 1) loss of a safety function whether or not that safety function was needed to mitigate an event, 2) unavailability of either a preferred or alternate success paths, 3) actual challenge to an alternate success path, 4) multiple failures within safety function success paths, 5) loss of redundancy or reduced redundancy within a success path. The impact on safety functions are then used to deter- mine the appropriate corrective actions. Combustion Engineering is currently working with NSAC in their Significant Event Evaluation Program. The above methodology is being applied to the generic evaluation of Licensee Event Reports.

SUMMARY \1 ! ' U The operator's three roles in nuclear plant safety Fig. 15: Operator action during an event are to: 1) Set up the plant to respond properly to adverse to accomplish each safety function. Not only will this events. awareness help the operator mitigate the consequences 2) Operate the plant so as to minimize the frequency of an event, but it will help him set up and operate the and severity of adverse events. plant in such a manner that the frequency and severity 3) Assist in mitigating the consequences of adverse of the initiating events will be reduced. events. The primary considerations for plant set up are equip- Other Safety Function Uses ment functionability and personnel readiness. The pri- In addition to the described applications, the safety mary considerations for incident prevention are equip- function concept can be productively applied elsewhere. ment, actions, attitudes, and management. The primary' In particular, this concept is useful in the design of considerations for event mitigation are information, nuclear plant systems and sub-systems, for providing procedures, and training. The operator, with his current meaningful and complete information in the event of level of training, can fulfill his first two roles by follow- an emergency, and for the evaluation of past experience. ing the technical specifications, the operating procedures, In addition to the sequence of events analysis, fault and a set of common sense guidelines. In mitigating an tree analysis is an analytic technique based on the safety event, the operator can use the concept of safety func- function concept used at Combustion Engineering. The tions to be better able to fulfill his third role. top element of the fault tree is a threat to a specific safety A safety function is defined as something that must be function. Each minimum cut set of the fault tree defines accomplished to prevent core melt or to minimize radia- the component and subsystem failures as well as per- tion releases. Safety functions can be divided into four sonnel errors which must occur to threaten the safety major classes: function. 1) Anti-core melt safety functions If an emergency should occur, the safety function 2) Anti-radioactivity release safety functions concept can be used for describing the status of the plant 3) Indirect radioactive release control safety functions throughout the event. This is an appropriate format for 4) Maintenance of vital auxiliaries the plant operators, shift supervisor, technical advisors, There are ten safety functions. Safety functions should emergency response personnel, and the general public. be viewed as having a certain priority, i.e., some safety In fact, effective media notifications could be based on functions should have precedence over others in the a description of the initiating event and the condition operator's mind. This does not mean that any safety of each of the safety functions. This approach is credible functions are unimportant. All safety functions are im- - 302 -

safety function concept is being used in operator train- ing, to structure emergency procedures, to design nuclear REUULATOHY PUBLIC SAFETY plant systems, and to evaluate past operating experi- UTILITY MANAGEMENT. ences. It can be used to develop a procedure for unfore- seen situations, to design better control room displays, and to format media information about an event.

ACKNOWLEDGEMENT

TECHNICAL The general content of this paper has been presented SUPPORT EXPERIENCE CENTER EVALUATION orally to a wide cross section of the nuclear industry over the past six months. Specifically, presentations have been made to operators of several operating nuclear power plants. The Committee on Power Design. Con- SAFETY FUNCTIONS struction and Operation and The Post-TMI Policy Committee of the Atomic Industrial Forum, the latter's Subcommittee on Safety Criteria. Nuclear Safety Anal- ysis Center personnel, the Smart Instrumentation Panel PROCEDURES Working Group of the January 15-17. 1980 NRC/IEEE OPERATOR ROLES Working Conference on Advanced Electrotechnology Applications to Nuclear Power Plants, and several groups of Combustion Engineering personnel. Many constructive comments have been received from a wide CONTROL ROOM variety of sources throughout this process. The authors INFORMATION acknowledge and appreciate this input. Fig. 76: Central role ol safety functions In addition, the authors would like to acknowledge W. E. Abbott, F. Bevilacqua, J. C. Braun, C. Ferguson, W. J. Gill, J. Gorski, R. M. Hartranft, .1. J. Herbst, portant. Not does it mean that maintenance of one safety A. C. Klein, S. M. Metzler. J. P. Pasquenza, M. F. function will inherently carry out an arbitrary other Reisinger, F. J. Safryn, C. F. Sears, E.I. Trapp, and R. S. safety function. All safety functions must be carried out. Turk for their suggestions during the review of this paper. There are several possible success paths for accomplish- We would also like to thank Mr. S. E. Morrey for his ing each safety function. The availability or appropriate- work in preparing the graphics for this paper. Dr. C. L. ness of a given success path for mitigating an event Kling was particularly helpful in the early formulation depends on the existing plant conditions. of these concepts. The support and encouragement of Figure 16 shows the central position of the safety Mr. Ruble A. Thomas of Southern Company Services function concept in many areas. This concept is already and Drs. Robert J. Breen and Edward L. Zebroski of being applied in several of these areas. For example, the NSAC were important to this work. - 303 -

REFERENCES

1. "Report of the President's Commission on the Acci- 9. FORTNEV, R. A.; SNEDKKER, J. T.; HOWARD, J. E.; dent at Three Mile Island, "John G. Kemeny, Chair- LARSON, W. W.; "Safety Function and Protection man, Washington, D.C., October 1979. Sequence Analysis," presented at The American Nuclear Society Winter Meeting; November, 1973. 2. "Three Mile Island. A Report to the Commissioners and to the Public," Nuclear Regulatory Commission 10. U.S. Nuclear Regulatory Commission, "Standard Special Inquiry Group, Mitchell Rogovin, Director, !'•rmat and Content of Safety Analysis Reports January 1980. tor Nuclear Power Plants," Regulatory Guide 1.70, Rev. 02. 3. U.S. Nuclear ReguValory Commission, "TM(-2 Lessons Learned Task Force Status Report and 11. "Analysis for San Onofre Nuclear Generating Sta- Short-Term Recommendations," USNRC Report tions2 & J."S-SEA-05GA, November, /977, Com- NUREG-0578, July 1979. bustion Engineering, Inc. 4. U.S. Nuclear Regulatory Commission, "TMI-2 12. St. Lucie-U nit 2 Final Safety Analysis Report, Chap- Lessons Learned Task Force Final Report," USNRC ter 15, to be published. Report NUREG-0585, October 1979. 13. CESSAR-F, Combustion Engineering System 80 5. American Nuclear Society, "Criteria for Technical Standard PWR Nuclear Steam Supply System Specifications for Nuclear Power Plants," ANSI/ Safety Analysis Report; Chapter 15, STN50-470F, ANS-58.4-1979, January 1979. December 1979. 6. J. MAFFRE, "INPO Management Team Set, Work 14. American Nuclear Society, "Functional Require- Starts on Initial Goals," Nuclear Industry, 27 (1): 12, ments for Accident Monitoring in a Nuclear Power January 1980. Generating Station," ANS-4.5. Draft 4; November 1979. 7. "Component Failures at Pressurized Water Reac- tors, Final Report," Combustion Engineering, Inc., 15. U.S. Nuclear Regulatory Commission, "Instrumen- REISINGER, M. F., Program Manager, Sandia Con- tation for Light- Water-Cooled Nuclear Power Plants tract No. 13-6442, to be published. to Access Plant and Environs Conditions During and Following an Accident," Draft Regulatory 8. Combustion Engineering, Inc.; "A TWS Early Guide 1.97, Rev. 02. December 1979. Verification, Response to NRC Letter of February 15, 1979, for Combustion Engineering NSSS's," 16. HUBBARD. III., F.R.; JAQUITH, R. E.; O'NEILL, R. P.; CENPD-263; November, 1979; Section 2.2. Preparation of Comprehensive Emergency Proce- dure Guidelines," to be presented at the 1980 ANS Topical Meeting on Thermal Reactor Safety; April 1980. - 304 -

APPENDIX 1 OPERATOR GUIDELINES FOR INCIDENT PREVENTION

GUIDELINES FOR THE FOUR INDIVIDUAL PREVENTION CATEGORIES CATEGORY GUIDELINES Equipment I. Know It Avoid distractions that interfere with Operate within your established the operatic, of the plant guidelines Use hearing, seeing, and feeling- Be aware of all plant limitations have "the picture" Be aware of changes in background 2. Be Suspicious noise Expect things to go wrong 2. Take Care of It Consider the consequences before Minimize Cycling taking any actions that could Correct all potential safety and fire affect plant operations hazards If the expected doesn't occur, be 3. Check It suspicious, stop, and investigate Check motors and controllers for When in doubt, ask questions excessive heat during tours Use common sense, procedures may Be aware of all maintenance in not always fit the given situation progress and anticipate what Read records back to your last shift could go wrong on duty Be aware of safety system availability Evaluate readings by comparing primary and backup indications 4. Believe It Confirm indications by inference Believe your indications from diverse indications Don't override interlocks Don't count on luck Don't turn off actuated safety systems Back up your buddy, check on him without confirming they are not If you don't know what action to take, needed hands off, step back, and reevaluate the situation Actions 1. Procedures Don't buy a pig in a poke—know what you are taking over Follow the procedures Don't take short cuts 4. Have Foresight Use only authorized procedures Know what is going to happen on Observe safety precautions your shift Follow emergency procedures Prepare for the shift plans: people/ Don't actuate interlocks deliberately hardware/ procedures/ adverse weather 2. Operating Bands Carefully plan abnormal or infrequent Monitor all indicators frequently evolutions Investigate all out of specification Know your immediate actions for conditions fault situations Make frequent tours of accessible spaces Review plant chemistry to determine 5. Be Formal trends Use concise communications at all times 3. Changes and Adjustments Give orders clearly and Anticipate and react to the effects of unambiguously transients on plant chemistry Anticipate effects of all adjustments Use standard phraseology follow up Insist on feedback — of order — of its execution Formally change the shift Attitudes 1. Be Alert 6. Encourage Safe Practices Be physically ready Acknowledge information reported Be aware of the board Thank people for asking questions - 305 -

CATEGORY GUIDELINES Management 1. Report All Out of Spec Conditions and Reasons, if Known Never accept alarms or equipment problems as normal events Look for trends when reviewing log 2. Keep Your Supervisors/Manap-rs Informed 3. Record all Changes to Plant/Equip- ment Operating Conditions 4. Maintain Proper Plant Chemistry 5. Before Assuming the Shift Ensure You Know the Status of Your Equipment Fully 6. Don't Let the Abnormal Become the Normal 7. Keep Junk Out of the Control Room (Animal, Vegetable, or Mineral) - 306 -

Fail-Safe Design Criteria for Computer-Eased Reactor Protection Systems

by

A B KEATS - UKAEA, Winfrith

SUMMARY

The increasing size and complexity of nuclear power plants is accompanied by an increase in the quantity and complexity of the instrumentation required for their control and protection. This trend provides a strong incentive for using on line computers rather than individual dedicated instruments as the basis of the control and protection systems. In many industrial control and instrumentation applications, on-line computers, using multiplexed sampled data are already well established, but their application to nuclear reactor protection systems requires special measures to satisfy the very high reliability which is demanded in the interests of safety and availability.' Some existing codes of practice, relating to segregation of replicated subsystems, continue to be applicable and will exert a strong influence upon the way in which the computer system is configured. Their application leads to division of the computer functions into two distinct parts. The first function is the implementation of trip algorithms, ie the equivalent of the function of the 'trip units' in a conventional instrumentation scheme. The first computer is therefore referred to as the Trip Algorithm Computer (TAC) which may incidentally, also control the multiplexer. The second function is voting, on each group of inputs, of the status (healthy or tripped) yielded by the trip algorithm computers. This function, equivalent to the protection system logic, is performed by the. Vote Algorithm Computer (VAC). Whilst the configuration and partitioning of the computer-based protection system tend to be dictated by existing codes of practice, the conceptual disparaties between traditional hardwired reactor-protection systems and those employing computers give rise to a need for some new criteria. An important objective of these criteria is to eliminate, or at least to minimise, the need for a failure-mode-ar.d-effeet- analysis (FMEA) of the computer software. This demands some well-defined, but simple constraints upon the way in which data are stored in the computers but the objective is achieved almost entirely by "hardware" properties of the system. The first of these is che systematic use of hardwired test inputs which cause excursions of the trip algorithms into the tripped state in a uniquely ordered but easily recognisable sequence. The second is the use of hardwired "pattern recognition logic" which generates a dynamic "healthy" stimulus for the shutdown actuators only in response to the unique sequence generated by the hardwired input signal pattern. It therefore detects abnormal states of any of the system inputs, or software errors, wiring errors and hardware failures. This hardwired logic is conceptually simple, is fail-safe, and is amenable to simple FMEA. The adoption of the proposed design criteria ensure not only failure-to-safety .a the hardware but the elimination, or at least minimisation, of the dependence on the correct functioning of the computer software for the safety of tho system. - 307 -

Fail-Sate Design Criteria for Computer-Based Reactor Protection Systems

by

A B KEATS

1. Introduction

The increasing si?.e and complexity of nuclear power plants is accompanied by an increase in the quantity and com; loxity of the instrumentation required for their control and protection. This trend provides a strong incentive for using on-line computers rather than individual dedicated instruments as the basis of the control and protection systems. The potential advantages are four-fold. Firstly, the computer is capable of implementing more complex signal-processing algorithms. Secondly, because the time-shared computer hardware replaces many dedicated signal- processing instruments, less equipment will be used and therefore a lower failure rate can be expected. Thirdly, because less equipment will be required, the cost will be lower. Fourthly, a cost and reliability advantage may also be expected from the use of remote data-sampling and multiplexing which reduces the number of wires and connectors required between the planf measurement transducers and tha centralised computer hardware. In many industrial control and instrumentation applications, on-line computers using multiplexed sampled-data are already well established, but their application to nuclear reactor protection systems requires special measures to satisfy the very high reliability which is demanded in the interests of safety and availability.

In conventional protection systems employing analogue trip units and hardwired logic, design criteria for satisfying performance requirements (speed, accuracy, spurious trip rate etc) are well established and the failure modes are well understood. The availability (spurious trip rate) and safety requirements (fractional dead-time) are satisfied by the use of redundancy; common-mode failures are avoided by segregation and diversity. Codes of practice already exist in this field (References I, 2 and 3) and techniques for ensuring that practically all failures result in safe action (failure-to-safety) are well proven and are applied on a ro'jtine basis. Protection systems employing digital computers can also be designed to satisfy given performance requirements, but their failure modes are far more complex than in hardwired analogue and logic systems and, as demonstrated below, potentially unsafe conditions can occur unless adequate precautions are taken. Some of the requirements can be met by the above codes of practice, but some new techniques are required because of the conceptual disparities between hardwired and computer-based systems. The design criteria proposed in this paper are an extrapolation of the fail-safe mode of operation used in the UK in hardwired reactor-protection systems (References 4 and 5). Thit -s achieved by making the "operational" condition of the reactor dependent upon an "energetic" state of the protection system components. In the shutdown state, the system components relax to a less-energetic state. As most component failures cause relaxation to a less-energetic state, the more probable (preferred) mode of failure is to the shutdown (safe) state. This objective cin be achieved in a computer-based system by exploiting the inherently dynamic (ie, energetic) property of Lhe data-sampling and multiplexing processes. - 308 -

An important objective of the proposed design criteria is to eliminate, or at least to minimise, the need for a failure-mode-and-effeet-analysis (FMEA) of the computer software. This demands some well-defined but simple constraints upon the way in which dato are stored in the computers but the objective is achieved almost entirely by "hardware" properties of the system. The first of these is the systematic use of hardwired test inputs which cause transient excursions into the tripped state in a uniquely ordered but easily recognisable sequence. The second is the use of hardwired"pattern recognition logic" which generates a dynamic "healthy" stimulus for che shutdown actuators only in response to the unique sequence formi.: by the hardwired input signal pattern. It therefore detects abnormal static of any of the system inputs, or software errors, wiring errors and hardware failures. This hardwired logic is conceptually simple, is fail-safe, and is amenably to simple FMEA.

Whilst these techniques eliminate the safety-related connotations of software errors by ensuring that such errors lead to a safe state, the overall system availability can nevertheless be enhanced by some of the well-disciplined methods of software production which have been evolved in wider fields oi applications of fault-tolerar.t computing (Reference 6).

2. The Computer-Based Protection System Configuration

Replication (or redundancy) coupled with majority voting, is necessary in computer- based protection systems for the same reasons as it is necessary in conventional hardwired protection systems, ie to achieve a specified overall system availability and fractional deadtime. The degree of redundancy will depend upon the expected system failure rates and repair times. Some existing codes of practice, relating to segregation of replicated subsystems, continue to be applicable and will exert a strong influence upon the way in which the computer system is configured. Their application leads to division of the computer functions into two distinct parts shown in Figure 1. The first function is the implementation of trip algorithms, ie the equivalent of the function of the 'trip units' to a conventional instrumentation scheme. The first computer is therefore referred to as the Trip Algorithm Computer (TAC) which may incidentally, also control the multiplexer. The second function is voting, on each group of inputs, of the status (healthy or tripped) yielded by the trip algorithm computers. This function, equivalent to the protection system logic, is performed by the Vote Algorithm Computer (VAC). This configuration and the modus operandi which fellow are relevant to any type of digital computer. However, in most protection system applications, the TACs and VACs will be microprocessors dedicated to those specific tasks with their programs securely stored in read-only-memories (ROMs) and with strict control maintained over access to them.

To maintain segregation of the replicated safety channels up to the stage where they are combined by majority voting, each channel of a group monitoring any one reactor parameter, eg neutron flux, muse be sampled by a separate multiplexer and processed by a separate trip algorithm computer. It follows from this that the degree of replication provided for the multiplexers must be at least the same as that provided for the sensors. Furthermore there must be at least one TAC to process the output of each multiplexer. A minimum redundant configuration of multiplexers and TACs is shown in Figure I for triple redundancy of the measurement sensors. This ensures that a failure of a single multiplexer or TAC affects only one measurement of any one parameter and does not constitute a common-mode failure. - 309 -

Transmission of the status (healthy or tripped) outputs of the TACs to the Vote Algorithm Computer (VACs) must be via unidirectional, electrically isolated paths in order to prevent the possibility of £ failure within a VAC being propagated to all the TACs and becoming a common-mode failure. This electrical isolation can be achieved by using optical coupler units or preferably, fibre optic cables.

As pointed out above, redundancy of hardware is normally essential to satisfy the reliability requirements. The degree of redundancy of the VACs is not necessarily the same as that provided for (.he earlier parts of the system. Figure 1 shows triple redundancy of the VACs by way of example although clearly higher degrees of redundancy may be required to satisfy given reliability criteria. The form of the final voting logic (=guard lino voting) will in turn be influenced by the number and arrangement of the shutdown actuators. The final voting may, for example be implemented on contactors which precede the shutdown mechanisms or on multiple inputs to the shutdown actuators themselves.

3. Potential Failure Modes Peculiar to Multiplexed Computer~Based Systems

The fundamental difference between a traditional reactor protection system, comprising individual dedicated trip instruments combined by hardwired logic, and one using computers, is that the latter operates on sampled data using a common central processing unit (the CPU) in a time-sharing mode. This means that instead of each of the measurement transducers being continuously connected to a dedicated signal processing instrument, they are connected sequentially to the common processor by a multiplexer which samples each of them in turn. The time- division-multiplexed sampltd-data is normally converted to digital form by an analogue-to-digital converter (ADC) before passing into the common processor. The common processor normally contains a store in which the current value of each input is memorised during the time interval between consecutive sampling instants. Multiplexed sampled-data systems of this type are widely used in process plant data acquisition and control systems. There are however certain potential modes of failure of the data acquisition hardware which, in the context of reactor protection systems must be rendered "safe" and self revealing. They are:-

(1) Failure of one or more of the multiplexer address bits to change state (ie stuck-at-1 or stuck-at-0 faults) which causes the multiplexer to repeatedly sample a limited subset of the full input address range.

(2) Complete stoppage of the multiplexer which causes the memory to retain the last set of values stored prior to the fault.

(3) Limited or complete failure of any part of the common, time-shared signal path (including the ADC) between the multiplexer and the processor, to accurately convey the sampled data (eg one or more data bits out of the ADC "stuck-at-l" or "stuck-at-0").

4. Methods of Protection Against Failures

4.1 The Use of Test Inputs to the Multiplexer

The first of the failure modes referred to in 3 above is made self-revealing by the introduction of "test inputs" to the multiplexer. The signals applied to the test inputs are chosen to be readily distinguishable from the signals originating from plant measurement transducers. The order in which the test inputs are interleaved between the plant signals is chosen so that a unique but easily recognisable pattern is generated (Figure 3) only when the multiplexer scans its full address range. The pattern cannot then be reproduced by repeated scanning - 310 -

of a subset of the full address range. A preferred arrangement of the order of the test inputs is shown in Figure 2 for a 128-input multiplexer. This particular arrangement is chosen so that it is subsequently recognisable by simple logical shifting and comparison functions (see Paragraph 4.4 l-elow). The properties of the test inputs (magnitude, rate of change, power spectral density, etc) are chosen to cause excursions of the trip algorithms into the tripped state. Differing properties may be ascribed to any or all of the test inputs so that all trip algorithms are exercised on every scan of the multiplexer inputs.

The response of the trip algorithms to the test and transducer signal inputs yields a sequential pattern of "status" bits in which a 1 represents the healthy status (not tripped) and a 0 represents the tripped status. Under noriuil conditions, the trip algorithms will yield a I status from transducer signal inputs and a 0 status from the test inputs (figure 3). The unique status bit pattern thus generated is dictated by the order in which the test inputs are physically wired into the multiplexer.

The excursions caused by the test inputs, also provide a continuous dynamic check of the common signal path from the multiplexer through the ADC and into the processor, including the telemetry link where provided. The test input signal may be sufficiently accurately defined to provide a continuous calibration check of the ADC and any common amplification provided.

4.2 Polarity Reversal on Alternate Multiplexer Scans

In addition to ensuring that the input multiplexer is sampling all of the inputs, it is also necessary to check that Uie input data are being refreshed on each cycle of the multiplexer. It would otherwise be possible for the multiplexer to stop, leaving the last set of input data retained in the memory and the processor repeatedly reusing this obsolete data. This mode of failure may be prevented in one of two ways. The preferred solution is to force some property, such as polarity, of the input data to change on consecutive cycles of the multiplexer, A polarity reversing switch, following the multiplexer, which changes state on completion of every cycle of the multiplexer, causes the polarity of the input data stored in the processor's memory to reverse each time it is refreshed. The programs whi^h process these data must be written to expect this regular polarity reversal and if it fails to occur, due to a failure of the multiplexer to refresh the memory, an incorrect status bit pattern will be generated and recognised. A further advantage of this technique is that it augments the continuous dynamic checking of the common data path which is provided by the test inputs. (A simpler but less comprehensive implementation of this principle is to reverse the polarity of the test inputs only on each multiplexer cycle.)

The use of polarity reversal to protect against the repeated re-use of obsolete data may also be applicable at later stages in the system.

4.3 Restriction of the Computer's Memory Capacity

An alternative to polarity reversal on alternate multiplexer scans, to ensure that the input data are being continuously refreshed, is to limit the capacity of the memory area available for storage of the input data to less than that required to store a complete set of values of all the inputs. This would ensure that on each complete scan of inputs, data acquired early in the scan were overwritten by those acquired later. Therefore, if the multiplexer stopped, it would be impossible to reproduce the complete sequence of data, with the test signals in their correct order, simply by repeated use of the stored subset of input data. - 311 -

4.4 Hardwired Pattern Recognition Logic

The dynamically generated status word sequence is used throughout the subsequent functions of the TACs and VACs to represent the "healthy" state. It is ultimately used at the outputs of the VACs to generate a dynamic operational stimulus for the plant shutdown actuators. Recognition of the correct status pattern at the computer output is implemented in hardwired logic so that the overall self-monitoring and fail—safe properties are not dependent upon correct operation of computer software. The pattern recognition logic will remove the operational stimulus from the plant actuator, if it fails to recognise the correct pattern due to (a) deviation of any one of the system inputs beyond the prescribed limits or (b) a hardware fault, or (c) a software error or (d) a wiring error.

Pattern recognition logic suitable for the particular sequence of status words described above comprises a shift register and a comparator as shown in Figure 4. To initialise the logic elements, the first word, formed from the first 8 inputs to the multiplexer is loaded into the shift register at the same time as the corresponding status word is generated by the computer. Thereafter, the "reference pattern" held in the shift register, is shifted by one place each time a new status word is generated by the computer. The reference and output patterns should, therefore, shift in synchronism. To maintain fully dynamic operation and continuous monitoring of the comparator itself, the pattern m.ttch is tested before and after shifting the reference pattern, ie twice for each new status word generated by the computer. The output of the comparator should, therefore, be 0 before shifting (indicating a mismatch) and 1 after shifting (indicating a correct match). The alternating 1 and 0 outputs of the comparator provides the dynamic stimulus, after amplification, for the plant shutdown actuators. The shifting of the reference pattern is made conditional upon recognition of the correct match. The logic, therefore, becomes 'latched' if a mismatch is detected until manually reset.

A slight variation of this simple logical process is required to completely match the pattern generated by the arrangement of test inputs shown in Figure 2 for a 128-way multiplexer. It requires reversal of the direction of shifting the reference pattern to correspond with the reversal of the order of the test inputs over the two halves of the multiplexer.

5. Conclusions

5.1 The conceptual disparities between a traditional reactor protection system based on conventional instrumentation combined with hardwired logic and one based on the use of computers, give rise to some new design criteria and special requirements for their modus operandi. Some existing codes of practice for reactor protection systems are shown to be applicable to computer-based systems and strongly influence the computer configuration. However, additional failure modes, peculiar to computer-based systems have been identified and techniques to overcome them are put forward as design criteria. These should ensure not only failure-to-saiety in the hardware, but the elimination, or at least minimisation, of the dependence upon the correct functioning of the computer software tor the safety of the system.

5.2 The proposed modus operandi have evolved from the well-established practice, in reactor protection systems, of requiring the sysv.w.1. components to maintain an energetic (or stimulated) state to enable them to sustain reactor operational conditions. The shutdown or tripped condition is achieved by relaxation to a less energetic (or de-energised) state. This results in a preferred mode of failure to the safe (ie less energetic) state. An example of this practice is the use of relays which are energised - 312 -

to maintain operational conditions and de-energised to initiate a reactor trip or shutdown. In some later UK reactor protection sysn.ins, relays have been replaced by solid state logic devices such as Laddie or Ltmiconductor logic elements. In these devices operational conditions are maintained by a dynamic or alternating state (eg of magnetic flux) and the- shutdown state by a static condition; Che dynamic condition being the more "energetic". Again, most failures result in relaxation to the static or Jess energetic condition giving a preferred mode of failure to the safe state. This fail- safe design criterion can be met in a computer-based reactor protection system by utilising the inherently dynamic property of the data sampling and multiplexing processes. The property is exploited by interleaving test inputs between the plant-sensor signals, which continuously exercise the common multiplexed data channel. The parameters of the test input signals are chosen to cause excursions of the trip algorithms into the tripped state. The unique order in which these excursions occur is detected dynamically by hardwired pattern-recognition-logic at the computer output. The reactor operational condition is maintained by continuous recognition of the dynamic status pattern. The pattern recognition logic will remove the operational stimulus if it fails to recognise the unique pattern due to (a) a deviation of any one of the plant-sensor inputs beyond the prescribed limits or (b) a hardware fault or (c) a software error, or (d) a wiring error. The computer itself has no knowledge of the unique operational status pattern; it can be generated only in response to correct operation of the input multiplexer and correct implementation of the trip algorithm. This results in a highly fail-safe diagnostic computer—based reactor-protection system.

REFERENCES

1. CEGB Specification US 76/10. "Instruments and Control Equipment General Technical Requirements".

2. CEGB Specification for Reactor Safety Systems, AGR Design Safety Requirements Annex VII.

3. IEEE Standards 279 - (1971).

4. A B KEATS. "Safety Circuits Based on Contemporary LSI Techniques". IAEA/NPPCI Specialists' Meeting, Cologne, 15-16 October 1973.

5. A B KEATS. "A Fail-Safe Computer-Based Reactor Protection System". IAEA/NPPCI Specialists' Meeting, Munich, 11-13 May 1976.

6. Proceedings of the 9th Annual International Symposium on Fault Tolerant Computing, (FTCS-9), Madison U3, 20-22 June 1979. TRIP PARAMETER MULTIPLEXERS TRIP ALGORITHM VOTE ALGORITHM ANA100UE- SENSORS iMUX) COMPUTERS COMPUTERS TO - DIGITAL (TAC) (VAC) CONVERTERS ( ADC) t PATTERN RECOGNITION \ • LOGIC MUX AOC TAC \ , (PRL) A / A A /

\ MUX TAC ADC TO I -SHUTDOWN B a a ACTUATORS to I-1 / U> PARAMETERS I

MUX c

FIG. 1. COMPUTER-BASED REACTOR-PROTECTION SYSTEM - 314 -

TEST INPUTS (OCTAL ADDRESSES! • 000 002 00S

TO AOC

| 107 no 1 > 1 HI • 1 1U- 11 1 -•FROM " ' t ADDRESSING 117 LOGIC

177

FIG 2. MULTIPLEXER INPUT WIRING PATTERN m o m z

o o m o z CO

TEST INCUT

tf* — m o —• TEST INPUT -J x m o — T£ST INPUT O SO o —i cJ O

o TEST INPUT 1 O1 •—

\

n ro c

ci J> ""

- gie - NEW STATUS BYTE FROM VAC STATUS BYTE FROM VAC

DELAY MONOSTABIE 110 110 11 5 SHIFT PULSE

TO SHUTQOWN ACTUATORS

OYNAMIC OUTPUT PR.?. « (NUMBER OF INPUTS) x (SAMPLING FREQUENCY )

128 x SO 800 Hi (TYPICALLY)

FIG. 4. PATTERN RECOGNITION LOGIC - 317 -

STATUS OF FIRST GROUP OF 8 INPUTS 1 1 0 1 1 0 1 1

STATUS OF SECOND CROUP OF 8 INPUTS 1 0 1 1 0 1 1 1

STATUS OF 'HiRD GROUP OF 8 INPUTS 0 1 1 0 1 1 1 1

ETC 1 1 0 1 1 1 1 0

1 0 1 1 t 1 0 1

0 1 1 1 1 0 1 1

1 1 1 1 0 1 1 0

1 1 1 0 1 1 0 1 16 BYTE BLOCK REPRESENTS S STATUS OF COMPLETE SET 1 1 0 1 1 0 1 1 OF I2B INPUTS

1 1 1 0 1 1 0 1

1 1 1 1 0 1 1 0

0 1 1 1 1 0 1 1

1 0 1 1 1 1 0 1

1 1 0 1 1 J 1 0

0 1 1 0 1 1 1

1 0 1 1 0 1 1 1

1 1 0 1 1 0 1 1 *-— BEGINNING OF NEXT BLOCK

FIG. 5. FORMAT OF STATUS DATA AFTER IMPLEMENTATION OF TRIP ALGORITHMS - 318 -

AN INTELLIGENT SAFETY SYSTEM CONCEPT FOR FUTURE CANDU REACTORS H.W. Hinds* ABSTRACT A review of the current Regional Over- Subscripts power Trip (ROPT) system employed on the Bruce NGS-A reactors confirmed the belief i force (or detector) index that future reactors should have an improved ROPT system. We are developing such an j channel index "intelligent" safety system. It uses more of k bundle index the available information on reactor status and employs modern computer technology. Fast, M using mapping (vanadium) triplicated safety computers compute maps of detectors fuel channel power, based on readings from . max maximum prompt-responding flux detectors. The coeffi- cients for this calculation are downloaded "> using safety (platinum) periodically from a fourth supervisor detectors computer. These coefficients are based on a detailed 3-D flux shape derived from physics 1. INTRODUCTION data and other plant information. A demon- stration of one of three safety channels of 1.1 Historical Background such a system is planned. Due to economic incentives, the design NOMENCLATURE fuel ratings of CANDU* reactors have increased over the years. The current limit Symbol Description Units is based on the rating at which centre-line fuel melting occurs; the consequences of this a coefficients dim'less event are somewhat speculative and considered undesirable. The regional overpower trip C,C flux mapping matrices (ROPT) systems in Bruce NGS-A and subsequent D diffusion coefficient m reactors are designed to prevent fuel melting. E,E~ channel power mapping matrices Under CANDU operating conditions, melting f "deflection", modifying function dim'less can occur only after a breakdown in heat transfer to the two-phase coolant, i.e. after F "force" dim'less dryout. To compute the thermal power required H flux-to-power conversion factor Wn~2Tn2-s to melt fuel in a given channel, the follow- ing thermohydraulic parameters and corre- P channel power W lations are required: Q dynamic error margin function dim'less - axial heat flux profile r distance (normalized) dim'less - dryout correlation (point values) x,y,z spatial co-ordinates (normalized) dim'less - coolant flow, inlet temperature, pressure £^ macroscopic cross section m~' - post-dryout heat transfer. V" = absorption Using nominal conditions for the above, the designers of Bruce NGS-A computed the channel power at which centre-line melting number of neutrons per fission dim'less occurs and obtained a channel power limit, after applying suitable error margins. flux n-m-^s-1 flux distribution from diffusion nem-2's~l The "measured" maximum channel power in code a Bruce reactor is inferred from a set of "readings" from platinum self-powered flux Superscripts detectors. The relationships between maximum channel powers and detector readings were « measured established during the design studies. The designers chose a large set of flux shapes by mapped, estimated using the considering various combinations of reacti- mapping scheme vity control device positions; some shapes also included dynamic xenon effects. For each shape, they calculated the detector average readings and maximum channel power. The designers then found a set of trip settings which ensured that, for every shape consi- *Atomic Energy of Canada Limited dered, the reactor would trip before the maxi- Research Company mum channel power exceeded the pre-determined Chalk River Nuclear Laboratories limit. They performed all the above calcula- Chalk River, Ontario tions using an equilibrium-fuelled reactor. KOJ 1J0 *CANada Deuterium Uranium - 319 -

For actual reactors, having fuels of varying committed) that uses the best information burnups, the operators add a channel power available on the status of the reactor and peaking factor (CPPF) to the detector cali- decides, taking all this information into brations to account for the channel-to- account, whether to trip. In other words, channe.1 ripple. the trip will be a computed parameter and not simply a one-for-one comparison of readings This design process yielded a system that against fixed trip settings. We consiucj. was relatively simple to implement: in opera- mainly the problem of fuel melting by over- tion, each detector output is compared to its power. Thus trips based exclusively on pro- trip setting* to decide whether to trip or cess quantities (e.g. boiler level) are not. Conventional analog/relay hardware is assumed to be retained as before, without any used to execute the trip logic. change in their algorithms. There are two ROPT systems at Bruce The information that is available con- NGS-.A, corresponding to the two shutdown sists of: sysrwns, SDS1 and SDS2. Each system is tri- plicated in the conventional manner to ensure - outputs from self-powered safety reliability, and each safety channel contains detectors of the platinum or Inconel approximately 13 detectors for SDS1 and 6 type detectors for SDS2. Future reactors, e.g. - outputs from self-powered mapping Bruce NGS-B will have slightly more detectors detectors of the vanadium type per safety channel. - outputs from self-powered control detectors of the platinum or Inconel Detector calibration is the main weakness type of the Bruce ROPT concept. When the reactor - positions (levels) of zone control is in the nominal** condition, the detectors elements should read bulk thermal power times the - positions of adjuster rods CPPF. Thus each detector reading, which is - positions of mechanical control actually representative of the flux over a absorbers short length, is also equivalent to the power - fuel burnup in the potentially hottest channel in the - bulk thermal power reactor. As the relationship between flux at - instrumented fuel channel powers (flow, one point and channel power somewhere else is temperature, quality) continually changing due to burnup and refuel- - inlet header temperatures ling, the calibration of detectors varies con- - outlet header pressures, and tinuously. Poor or out-of-date calibration - pressure drops from inlet to outlet could result in potentially unsafe operation headers. and/or unnecessary reactor trips and is also a nuisance for the operating staff as rscali- This paper outlines the mathematical bration must be carried out frequently and algorithms for processing the information in manually. a logical manner, and a distributed computer architecture applicable to power plants and Analog/relay hardware is used in the capable of implementing the algorithms with Bruce NGS-A safety system. Since high- sufficient speed. For the future, it is our quality relays are becoming increasingly dif- intention to assemble a single channel of ficult to obtain, they should be phased out such a computer system as a realistic demon- of future safety system designs. Meanwhile, stration, and demonstrate and evaluate its computers are becoming more reliable as well effectiveness under many simulated reactor as less expensive; they also offer a very high conditions. This demonstration will provide degree of flexibility. This increased flexi- a testing ground for both the algorithms and bility is very important if the algorithms the reliability of new hardware components. used to decide whether to trip become more complex, i.e. if the safety system is more 2. ALGORITHMS "intelligent". 2.1 Flux Mapping One of the operator's main worries is a small margin-to-trip. A more intelligent The procedure of flux mapping can be safety system could alleviate this problem by stated generally as follows. A mathematical obtaining a more accurate "measurement" of form for the flux is assumed having M free the maximum channel power and hence allowing parameters, and the flux is measured at N a reduction in the error margin required. locations. If N = M, then the equations can be solved exactly; if N > M, they can be 1.2 The Intelligent Safety System Project solved to minimize the errors between the mapped and measured fluxes in a least- The basic objective of this project is to squares sense; if N < M, they can be solved develop an Intelligent Safety System for fu- to minimize the deviations of the free para- ture CANDU reactors (beyond those currently meters in a least-squares sense. Examples of these three cases are: the bent-plate scheme * In Bruce NGS-A, some trip settings are ad- II], modal scheme [£], and finite-difference justed automatically as functions of booster scheme [3], respectively. Philosophically, operation. there are implications of which information is being believed, as shown in Table X. It **Nominal refers to the normal steady-state is our contention that the measurement must operating condition with zone levels near be believed in preference to the Mathematical 40% full and boosters and control absorbevs form. out. - 320 -

TABLE 1

PHILOSOPHY OF MAPPING SCHEMFS

N = number of detectors M = number of free parar-'-*ters

•I'd .tion r.xsif'-.-V? Detector P^idings Mathematical Form

N = M Bent-Plate Scheme believed believed

N >• M Modal Scheme not believed believed

N < M Finiue-jiiierence believec not believed Scheme (excessive parameters included)

The above three schemes are "f orm- justi.ii'ation tor the form chosen* except that detprministiu"; they depend solely on the it provides J. smooth 3-D interpolant with con- matrematical forms chosen. There is a fourth tinuous low-order derivatives. me_hod whirh is dependent on an a priori knowledge of a set of answers. In this Knowing the fluxes If at the detector scheme, a relationship between the inputs and locations, we can solve equation (2) for the the results is assumed, with a number of free deflections £ at the detectors and then parameters; typically one might choose a equations (3) and (5) for the F values. Sub- matrix (linear) relationship. The free para- stituting back, we can find the fluxes meters that give the "best" answers are then everywhere. In matrix notation, this can be found; of course, the number of known shown to yield answers must equal or exceed the number of free parameters. "Best" will typically mean = Cf (7) with least-squares error; or in the case of r a s.i ety s-'stem, it may have a uni-polar The thermal power of a given fuel channel is (conservative; .^plication. The ROPT scheme the vpighted sum of the fluxes along that currently employed may be put in this latter channel, category. P. = n£ H.. (8) We have chosen a mapping scheme of the first type: it is form-deterministic, N = M, and the mapped flux will pass through the where n is initially assumed to be unity and measured points. An initial estimate of the the flux-to-powor conversion factor H is flux shape is obtained using a 3-D diffusion burnup dependent. Combining equations (7) and equation, for example, (8) gives, in matrix notation.

V-DVIJJ - (I) P = Ef (9) where the reactor physics parameters D,X)a Thus equation (7) can be used to find the and v2lf are obtained using the knowledge of flux at any desired location in the core while burnup and the device positions. This calcu- equation (9) maps the measured deflections into lation is not perfect, and the actual flux is the channel powers. Equations (7) and (9) given by the calculated shape times a modi- could have Leen written in terms of measured fying function fluxes^instead of measured deflections, i.e. $ - C'<|> and P = E'$, and the choice is really * = fij> (2) dependent on programming convenience. A form is now assumed for this function These equations ar^ general and occur irrespective of the actual mapping scheme f = ir[ In r| + aQ + ayy + used; the mapped fluxes and channel powers are linear combinations of the measured fluxes. (3) 2 (y-yi) + (z-zi) (4) 2.2 Overall Scheme The above outlines the basic mapping scheme proposed. However, in our case, some additional features are incorporated. The total scheme is shown schematically in and the mapped flux is given by £i|i. Figure 1. With the reacto^ at significant These equations were originally developed as a 2-D interpolant [1); we have made them *In 2-D, this form is the equation for the 3-dimensional. There is no physical deflection of a plate subjected to transverse forces. - 321 -

MfiPPif.0 JLTtClOHi. 3-D fUll DEVICE POS*1|QMS D. I

SlIMt muics OlfFUJIW mmit PIIMUU REFUELLING INFORMQTlON H C001 C1U.

2-D

ENUD CHPNNEL POKERS

ROPT UNO PPOCE5S IRlPS

ROM TuQ C1HER SD' ETT •.HGNNUd

"~~~| ?, I xaoid—» ^-*- SOFETtOETECTORS

ONE OF THHEC SflfETr (HIGH SPEED REQUIRED)

PROCESS INFORMATION

FIGURE 1 PROPOSED «LGOR1TH« FOR THE IK1ELLIGEH1 S»FETY SUSIE*

power, the calculation is begun by accessing normalization constant may be thought of as the sampled reactivity device positions and a correction for systematic errors in the obtaining any new refuelling information. absolute detector calibration, the value of From this information, plus the stored burnup H, and/or the ratio of flux in the moderator data, physics parameters are computed and a to that in the fuel. theoretical flux distribution, ifi, is obtained, via a diffusion code such as CHEBY [4]. The As the mapping detectors are more accu- sampled outputs of the mapping detectors* are rate than the safety detectors, the sensiti- accessed and compared to this flux distri- vities of the safety detectors are adjusted bution, a rationality check is performed, and to force any significant deviations are resolved.

The mapping scheme outlined above is then used to produce the mapped flux distri- Again, filtering and a rationality check are bution ()>M, using the mapping detector fluxes and equation (7). A mapped power distri- required. In simple terms, we are cali- brating the platinum safety detectors against bution, PM, is then obtained using equation (8) . the more accurate vanadium mapping detectors.

Redundant power information is also The flux shape JM is then used as the available from the instrumented fuel channels reference flux (replacing vf»J in a second and the bulk thermal power measurement. A application of the mapping scheme using the rationality check is performed and irrational safety detectors. With this reference shape measurements can be dealt with manually. and the safety detector sensitivities, the This information is used to obtain a better detector outputs of each safety channel can value for the constant n which was previously be converted to deflections Equation (9) assumed to be unity; a weighted least-squares can then be applied to give a power map Ps approach is assumed. Filters to match based on the safety detector outputs. dynamic responses and a rationality check on the value of n are also required. This An additional feature of our scheme is the dynamic error margin. After a series of studies, we found that the error in the maxi- •Platinum or Inconel detectors, although rela- mum channel power can be correlated to a tively prompt responding, are not considered measurable parameter to be as accurate at steady state as vana- dium detectors. Thus only the accurate vanadium detectors are included here. > Q (11) - 322 -

P —• P max max (12)

1 - k h (13)

and Q is a negative, simple, piecewise linear function. From this relationship, we obtain

max - 1+Q (14)

Thus the right hand side of equation (14) provides a conservative estimate of the maxi- PROCESS IHEORHflTION mum channel power. Alternatively, the factor (1+Q) can be applied to the power limit as shown in Figure 1.

It should be noted that if the zeference flux shape is the same as that measured using the safety detectors, then fj = f. As Q(0) 2; 0/ there is little or no penalty SGFnr COMPUTERS associated with this procedure. However, if the measured and reference flux shapes differ FIGURE 2: SCHEMATIC OF INTELLIGENT S«FETT STS1EU significantly, penalties against "measured" maximum channel powers up to 10-15% may be required. The fast task must perform a complete flu>: mapping calculation which is equivalent The channel power limit is computed as a to a matrix-vector multiply. This matrix function of process variables, a tilt para- consists typically of 4 80x20 elements. The meter, and dynamic error margin. Comparison reaction time of the safety system to the with the mapped channel powers yields a local worst accident must be less than 100 ms, and ROPT trip signal. Local process trips are thus we are aiming for a fast task with a obtained from suitable algorithms. By inter- cycle time of ^50 ms. To achieve such a comparing the local trip signals from the speed, an array processor is required as part three safety computers (see the next section), of each safety computer. a two-out-of-three functional coincidence can be determined, and a safety channel trip In cc/itrast, we do not recommend that initiated. A final two-out-of-three ex- the slow task be triplicated, as the sen- computer vote is required to activate the sors, computers, etc., become too expensive. shutdown system. The alternative is to manually verify that the slow task is functioning correctly before permitting the data trar.sfer to the fast 3. HARDWARE task, and manually checking for correct data transfer. A long series of calculations was de- scribed in the previous section. To produce The slow or supervisor computer will results rapidly, it is necessary to partition also perform a number of monitoring functions this series into at least two tasks: a fast not shown in Figure 1. For example, it will task that produces a yes/no trip vote and a periodically (say every 5 minutes) monitor slow task that produces the parameters for the outputs from the safety computers and the fast task. The fast task is indicated compare them to similar values calculated below the dotted line in Figure 1; the upper from mapping detectors and instrumented fuel portion is the slow task. channels. This intercomparison of redundant data will lead to rapid diagnosis of failed The hardware is similarly partitioned, instruments and/or wilZ indicate that the as shown in Figure 2. To obtain the reli- reference shape is becoming out-of-date. ability required for reactor safety, tripli- cated circuits are usually employed. The same philosophy is applied here; the safety The interconnections from the supervisor computer with its sensors, etc., is tripli- computer to the safety computers and among cated. The safety channel trip decisions of the, safety computers must be fail-safe. these computers are dealt with via conven- Suitable design techniques will ensure that tional two-out-of-three ex-computer voting this criterion is met. Watchdog timers (not logic. shown) are also required to ensure that the safety computers are actually operating. We plan to assemble a demonstration of such a system, consisting of 3 interconnected - 323 -

computers, An attempt has been made to deal in a better way than in the past with redundant - a supervisor computer, information. The guiding principle is that - a single safety computer with its if all the information agrees, then reactor . array processor, analog inputs, and power is allowed to approach the safety watchdog timer, and limit fairly closely. However, as disagree- - a computer to simulate the reactor. ment increases, a penalty (the dynamic error margin) is applied which lowers the maximum The first two will be assembled and programmed permissible fuel channel power. In this in as realistic a manner as possible, so that way, either better calibration of instru- they could be used directly in a power ments or a more accurate and up-to-date station. The computer for the reactor simu- calculation will lead to a system having a lation will consist of the Hybrid Computer larger margin-to-trip. System (Digital Equipment Corp. PDP-11/55 and two Applied Dynamics AD/5 analog computers) Also, the system is designed to approach presently operational in the Dynamic Analysis an optimum in any steady-state situation. Laboratory of the Reactor Control Branch. In other words, the dynamic error margin will be a minimum and the margin-to-trip a This demonstration will provide a maximum immediately after downloading of a testing ground for the proposed algorithms as new matrix from the supervisor computer to well as the hardware. The use of computers the safety computers. If the reactor is in in safety systems is a new concept for CANDU steady state, this condition will persist. reactors and their application to this role Subsequent manoeuvres however will cause must be demonstrated. Array processors are some departure in the reactor flux shape from relatively new devices with which we are not the shape stored in the safety computers. yet familiar. This demonstration will pro- This will increase the uncertainty in the vide valuable experience with their use, computed fuel channel powers and result in a capabilities and reliability. The inter- reduction of the permissible power. connection of computers is becoming wide- spread, and new concepts in data transmission, 6. REFERENCES e.g. INTRAN [5], will be examined by means of this demonstration. [11 W.E. Gabler and H.D. Fulcher, "Babcock & Wilcox On-Line Computer Advancements in 4. PROGRESS TO DATE Calculating Uninstrumented Assembly Powers", Presented at ANS-CNA Joint The mapping scheme outlined above has Meeting, Toronto, Ontario, 1976 June been examined, and accuracies of 3.5% rms are 13-18, pp. 4,5,6,7. Also BSW report achievable in computer studies with ^20 TP-649. detectors. A large number of flux shapes has been examined, and a suitable dynamic margin [2] A.M. Lopez, J.R. Enselmoz and G. Kugler, curve has been obtained. "Early Operating Experience with the Bruce NGS-A Flux Mapping System", paper The scheme calls for the solution of a in unpublished Atomic Energy of Canada static diffusion code to provide the refer- report WNRE—308, 1978 April. ence shape for the £lux mapping procedure. The code CHEBY [4] which solves the dif- [3] F.N. McDonnell, private communication. fusion equation in 2 energy groups has been converted to run on a PDP-11/55 computer. [4] M.H.M. Roshd, "The Physics of CANDU This exercise shows that it is feasible to Reactor Design", Presented at the ANS run a large diffusion code on a mini-computer. Conference, Toronto, Ontario, Although running times are considerably 1976 June 14-18, p. 5. Also available slower than on a CDC CYBER 170/6600 system, as AECL-5803. convergence is achievable in 1-2 hours. Most of this time is spent in transferring data [5] A. Capel and G. Yan, "Distributed and overlays between the computer memory and Systems Design Using Separable disk. We believe that the present generation Communications", Paper to be presented of mini-computers with large virtual address at the IAEA Specialists' Meeting on capability or memory management could produce Distributed Systems for Nuclear Power results in a much shorter time. Plants, Chalk River, Ontario, 1980 May 14-16. 5. CONCLUSIONS An outline has been presented for the design of an Intelligent Safety System for the regional overpower protection of a reactor core. This system breaks with tradition in that it uses a computed value as a trip parameter. The computation is relatively complex as it implicitly contains a full 3-D neutron diffusion calculation blended with a flux mapping procedure. Another new concept . is the use not only of computers but also of array processors as essential major elements of the safety system. We have maintained 'the traditional two-out-of-three arrangement of hardware redundancy. ISSN 0067 - 0367 ISSN 0067 - 0367

To identify individual documents in the series Pour identifier les rapports individuels faisant we have assigned an AECL- number to each. partie de cette s6rie nous avons assign^ un num6ro AECL- a chacun.

Please refer to the AECL- number when re- Veuillez faire mention du nume'ro AECL- si questing additional copies of this document vous demandez d'autres exemplaires de ce rapport

from au

Scientific Document Distribution Office Service de Distribution des Documents Officiels Atomic Energy of Canada Limited L'Energie Atomique du Canada LimitSe Chalk River, Ontario, Canada Chalk River, Ontario, Canada KOJ 1J0 KOJ 1J0

Price $15.00 per copy Prix $15.00 par exemplaire

1941-80