On Requirements Analysis for Reactor Control and Protection Systems

Copyright © IFAC Safety and Reliability in Emerging Control Technologies, Daytona Beach, florida, USA, 1995

ON REQUIREMENTS ANALYSIS FOR REACTOR CONTROL AND PROTECTION SYSTEMS

P. A. Barrett, A. Saeed

Centre for Software Reliability Department of Computing Science, University of Newcastle Newcastle upon Tyne, NE] 7RU, UK

Abstract: Traditionally, high-levels of safety have been obtained and demonstrated for nuclear plants by tile judicious use of protection systems and engineered safety features. In iliis paper, we customise an approach for tile analysis of safety requirements to ilie specific needs of the nuclear industry by focusing on how fault-tolerance approaches can be integrated with traditional practices of tile nuclear industry. Keywords: nuclear power, requirements, software safety, fault tolerance, formal meiliods. 1 INTRODUCTION

Furtiler actions are also required to ensure ilie safe condition is not violated.

The safety record for nuclear plants compares favourably witil otiler industrial sectors; a primary factor for iliis is ilie existence of a clearly defined safe state (i.e. shut down), into which tile system can be taken in order to minimise risk (Koch, et al. 1994). This characteristic is exploited when developing a safety system - the main safety concems are identification of abnormal states in tile plant tilat could lead to hazards, and definition of corrective actions iliat enable ilie system to be shut down before ilie abnormal states can lead to a hazard. Experience in ilie construction and licensing of safety systems. has lead to established principles tilat are used to guide design (i.e. design rules) and assessment (i.e. assessment criteria) during system development:

Over ilie last decade tile use of computer-based systems in ilie nuclear industry has become more widespread and ilie level of criticality of tile roles performed by computers has increased. The key implications for nuclear plants have been discussed in detail by Parnas, et af. (1990). iliese include: problems of complexity, error sensitivity, difficulty of assessment and correlation of failures . Furilier, experience of Sizewell 'B' indicates iliat criteria for demonstration of safety should be known early in development. Experiences with safety-critical systems and ilie analysis of software-related errors have shown iliat mistakes made during ilie requirements phase can easily introduce faults which subsequently lead to accidents (LUlZ, 1993). Here we customise a general approach for requirements analysis (de Lemos, et al., 1995) for ilie specific needs of ilie nuclear industry, by providing support for incorporating ilie different design principles into tlle analfsis of requirements and enhancing traceability.

Separation of systems used to control a plant from those used to ensure safety (Lawrence. el a/., 1994) Diversity is the main means used to provide protection against common cause failures - diversit y can be incorporated at several levels in the design of a nuclear plant (Coxson. 1993). D~fence-in-depth,

tile provision of multiple echelons of defence to reduce risk (Lawrence. el al .. 1994).

The rest of iliis paper is organised as follows . In ilie next section, we overview an approach for ilie specification and verification of control and protection systems. In section 3, we present extracts of a case study. Section 4 provides illustrative

Fail-sqfe, failures must have a safe effect; this often means iliat failures are detected as they occur with ilie plant being moved to a safe condition (NIl 1988). 77

examples of the support provided for verification. Finally, section 5 presents concluding remarks and directions for future work.

between tllis approach and the practice of defining

abnormal staTes and corrective actions. The behavioural definition of an interactor is partitioned into four categories: standard, failure, exceptional and hazard. The first category represents nonnal states, me omer categories represent different kinds of abnonnal states which are classified in accordance to me scope of me corrective action. For failure behaviours corrective actions are defined within me scope of me interactor. For exceptional behaviours corrective actions are defined external to me interactor; me interactor is obliged to signal me appropriate exception. Hazards represent those states of me interactor mat constitute a system hazard, in mese cases corrective action is aimed at reducing the severity of me related accidents.

2. REQUIREMENTS ANALYSIS

2.1. Process Model The overall approach is to partition the analysis of requirements into phases each of which matches a domain of analysis. For nuclear power stations the initial decomposition partitions the analysis into the three major domains for process control: Plant, Controller and Operator. These domains are then further decomposed in accordance with the structure of the systems. The analysis conducted in each phase is based upon two interrelated aCUVlues: developmelll, for tlle production of models and specifications for tlle associated domain, and assessmelll for the verification and validation of me models and specifications. The results of the assesement are used to guide modification before proceeding to the next phase or provide input to the safety case.

A corrective action is specified as a safety strategy (a scheme to maintain safe behaviour), and defined as an action of me El A model. For corrective actions that are exceptions, two new fields are introduced into the declaration of an interactor: Raise used to declare all the exceptions tllat can be signalled by the interactor and Handle used to declare all the interactors mat signal an exception to me interactor. Also in me behavioural description, tlle category Event is introduced to specify me actions that are initiated by the handlers provided by me interactor in response to the receipt of an exception event.

2.2. Modelling Modelling tlle overall system (and its environment) into which the computing system will be embedded is considered to be an integral part of requirements analysis.

2.3. Traceability

Basic Aspects. The principal modelling abstraction used in the proposed approach is tlle illleractor (Duke, et af. 1993), an object-based concept that

To support traceability, during the different phases of analysis, the models and specifications obtained from the analysis must be recorded in fonnats that promote me essential relationships between mem o For me plant domain these include relationships between: the hazards, abnormal states and corrective actions. The essential relationships between me plant and controller domain are: tlle mappings between me plant states and me observed plant states; and the corrective actions of me plant and controller. The proposed approach lays a foundation for bom syntactic and semanTic traceability (Gotel, et al., 1993). Syntactic traceability is supported by adopting a naming convention. in which me name of interactors used to represent me controllers model of the plant are derived from the interactors of me plant - interactors related in such a way are referred to as a collection. Support for semantic traceability is provided by using a contract to fonnalise me relationship between interaclOrs in a collection.

supports representation of bOtll structural and behavioural aspects of a system. An interactor corresponds to a class in object-based tenninology and is described by a template. In order 10 specify the behavioural composition between a group of instances of interactors we employ a mechanism similar to a contract (Helm. et al .. 1990). An event/action model (E/A model) (de Lemos, et al., 1995) is used to describe the behaviour of an interactor. The El A model is based on the following primitive concepts. A state of a system is tllat infonnation which, together witll tlle system input. detennines the subsequent behaviour of tlle system. An event is a temporal marker of no duration which causes or marks a transition. An action is tlle basic unit of activity, which implies duration.

Customised Features . To support the design principles of defence-in-depth and fail-sC!fe , specific features are introduced into the approach. The fonnat of mese features is influenced by work on me specification of exception handling for software (Cristian, 1989). For tlle specification of a software function, me input space is partitioned into subsets representing nonnal or abnormal inputs; in the case of nonnal inputs the software function must provide its nonnal service and in the case of some abnormal inputs raise an exception. There is an analogy

2.4. Verification The verification of me specifications involves confinnation of two aspects: internal and external.

InTernal Consistency. The behavioural definition of an interactor can be subjected to two fonns of conformance check and a check can be made over the consistency of tile exception handling:

78

•

The second stage of me analysis adopts a bottom-up approach to adding detail to each interactor. For each interact or a detailed safety specification is prepared (taking into account, in me process, me specification of any interactors into which tlle interactor being speCified is decomposed). The fonn of an interactor is illustrated below (in me full version me fonnalism in me fields are complemented witll informal commentary), using me specification of me case study interactor Contra/Rods. In order to understand tlle specification, note tllat we assume mat me rods controlling tlle reactor are arranged into groups, wim tlle rods of each group moving in synchrony. Thus, Contra/Rods is composed of a number of instances of tlle interactor RodGroup. Reactor trips are handled at tlle Contra/Rods level, tllus tlle interactor defines a handler which responds to trip signals from otller interactors. Wimin tllis handler, furtller exceptions are raised to trip tlle steam turbines in me event of a reactor trip.

Exhaustive . It must be shown tllat tlle disjunction of all behaviours covers tlle state space defined from me declaration of the interactor's variables.

•

Exclusive . The standard class must be mutually exclusive witll tlle classes used to represent abnonnai states. For tlle abnormal states, eitller two classes are mutually exciusive or tlle associated corrective actions do not conflict

•

Raises and Handles. The relations between tlle interactors, derived from tlle Raises and Hand/es deciaration of a set of interactor specifications can be summarised by two matrices RaiseM and Hand/eM. The rows and columns of tlle two matrices are indexed by tlle interactors. For RaiseM, each row is a summary of me Raise declaration for me interactor. For Hand/eM, each row is a summary of me Hand/e deciaration for me interactor. For consistency tlle transpose of RaiseM must be equivalent to Hand/eM.

External Consistency. The key aspect for external consistency is to verify the controller safety strategies (corrective actions for tlle controller) against the plant safety strategies (corrective actions for the plant). This verificatjon must be conducted in the value domain and the time domain . For the value domain the verification is conducted in three stages. Firstly, it must be shown that when the behaviour of me plant would initiate the plant safety strategy the corresponding controller safety strategy will also he initiated. Secondly, it must be shown tllat during me execution of tlle controller safety strategy the invariant of tlle plant safety strategy will he respected. Thirdly, it must be shown that the termination of me controller safety strategy will ensure mat tlle plant safety strategy will tenninate

Interactor Contro/Rods Composed-of rodgroup{1 .. RG]

RodGroup

Constants Base I

RG

Variables Base B B

AlllnRange AII/nSkew

Handles From Interactor Core SteamGenerator E/ectrica/Genera tor Operator ReactorContainment Raises In Interactor Steam Turbine

3 CASE STUDY This section describes an application of tlle proposed approach, via examples drawn from a substantial case study based on a hypothetical PWR: only a flavour of it can, unfortunately, he incorporated here. For tlle case study, tlle system is considered to he the Nuclear Power Station . In the following we sketch me analysis of me plant and controller.

Event Trip Trip Trip Trip Trip Exception Trip

Behaviour Common: AII/nRange c:::> I7rgERG : rodgroup(rg)./nRange AlllnSkew c:::> I7rgERG: rodgroup(rg} ./nSkew Standard: AlllnRange

A

AII/nSkew

Failure:

3.1 Plant Ana/ysis

3rgeRG: {rodgroup(rg} .-./nSkew __

The plant analysis is undertaken in two sta!!es. Firstly, using a top-down approach , the system under consideration is decomposed into a hierarchical set of interactors representing the componeIlls of the system. A specification is prepared for each of tllese interactors showing, at a relatively high level. the interactors into which it is decomposed, any signals which it raises in, or handles from , other interactors, and its behaviour in tenns of nonnal conditions, failure states, tlle actions to be taken in response to failures which have been identified, and any states which are considered to constitute safety hazards.

rodgroup(rg}. FreezeGroup }

Exception: 3rgeRG: {rodgroup(rg} .-./nRange-+ Contro/Rods. Trip} ::, Trip __ 17 st EST: steamturbine(st}. Trip Event:

Trip __ TripReactor

Hazard:

3rgERG: rodgroup(rg}.PosExceedUmit

The meaning and usage of tlle various sections of me interactor specification is as follows:

79

Interactor. This names the interactor. In effect, this name becomes a type.

as tile sequential composluon of two actions TripRods and LockRods. An action is defined in terms of three predicates over the variables and constants of an interactor: start condition - defines when an action starts; invariant - defines behaviour during an action; and finish condition - defines when an action terminates. These conditions can be defined in the time or value domains, in the following we sketch tile definition of the start and invariant of TripRods in the value domain.

Composed-of. This is the set of interactors into which the interactor being specified is decomposed. ConstantsNariables. Constants and variables of the interactor used in the behavioural specification.

Raises. A list of the exceptions which may be raised in other interactors by instances of the interactor. Each exception is specified in terms of the interactor which provides the handler for the exception, and the exception name. Enclosing the exception in braces {} indicates that the exception is actually raised by a sub-interactor.

Invariant. During the action TripRods the rods can only move downwards. TripRods

=

IVV

VrgeRG:VrE R: rodgroup(rg).rod(r). VrodS O.

Handles. A list of the handlers provided by the interactor for dealing with exceptions raised by other interactors. Each handler is named, and the interactors which may invoke it are specified. The actions taken by the handler are specified in the Behaviour section of the interactor specification. Enclosing the handler in braces [} indicates that the exception is actually handled by a sub-interactor

Finish. The action Trip Rods is completed when all the rods are fully inserted. J..TripRods

=

v

I(VrgeRG:V rE R: rodgroup(rg).rod(r). Prod=O) .

k

Where Sp) is true at the instant the predicate Sp becomes true.

3.2 Controller Analysis

Behaviour is further sub-divided as follows:

This phase is partitioned into tilree sub phases: the plant inteiface analysis, the controlling system analysis and the operator intel!ace analysis. In this paper, we focus on the plant interface analysis which consists of developing a logical model of the actuators and sensors that are needed to observe and manipulate the behaviour of the plant. Modelling the plant interface in terms of logical, as opposed to physical, sensors and actuators has a number of benefits.

Common. A relationship which is a convenient abstraction for the other categories of behaviour. Standard. The conditions which specify the nonnal behaviour of the interactor. Failure. The conditions which specify that a failure of a type which can be dealt with within the interactor itself has occurred. Failure conditions may trigger actions aimed at recovering from , or compensating for. the failure condition . More precisely, when a failure condition becomes true the associated action or event is triggered. Exception. An exception condition is similar to a failure, except in that the interactor itself does not attempt to recover from the failure condition. Instead, it raises an exception in another interactor which takes the appropriate remedial actions. Event. An event is the raising of an exception from another interactor for handling within the inreractor being specified. Thus, event behaviour specifies the actions to be taken when an exception is raised: i.e. it specifies the behaviour of the exception handler.

•

A logical model provides a convenient abstraction that can be used to relate those aspects of the plant that must be observed or manipulated to the inputs and outputs of the controlling system.

•

A minimal (but sufficient) description of the interface is provided, enabling the designer of the controller to defer decisions on the physical architecture until a detailed analysis of the controlling system has been conducted.

In order to support traceability between the interactors of the controller and plant the following naming convention is adopted. For each interactor of tile plant tilat is to be observed and manipulated by the controller the suffix S&A is used. The formal relationship between a plant interactor and its corresponding controller interactor is recorded in a contract whose name is obtained by adding the suffix Interface. In order to illustrate the results of this phase. we present the interactor ControlRodsS&A and contract ControlRodslnterface.

Hazard . This section contains the specification of the conditions which result in the system being considered to be in a hazardous state.

Plant Safety Strategies. The next step in the analysis is to specify the safety strategies tilat are initiated in response to the failure and exception behaviours of the plant interactors. As an exmnple. we consider the safety strategy TripReactor, defined within the scope of ControlRods. This safety strategy is initiated in response to exceptions tilat can be raised in a number of interactors. The safety strategy is based on a scheme for "tripping" the reactor by fully inserting all the control rods . The safety strategy is modelled

In the definition of ControlRodsS&A, tile variables are used to model an actuator that can be used to release all tile rods. and logical sensors mat can be used ohserve tile hehaviour of tile rods . The interactor ControlRodsS&A is composed of a number of instances of the interactor 80

'<:Ire R: controlrods.rodgroup(rg).rod(r).Prod(t);1!() Actuator{T,) <=> vr e{T,-ORelease, T,] : ReleaseRods(t)=> tfrg€RG: '<:Ire R: rodgroup(rg) .rod(r).Prod(T,J=O

RodGroupS&A that is used to observe and manipulate the behaviour of a group of rods. Interactor ControlRodsS&A Composed-of rodgroupS&A[1 .. RG]

Standard: Positive /\ Negative /\ Actuator Failure: -,Positive /\ Negative [FM1} Positive /\ -,Negative [FM2}

RodGroupS&A

Constants Base RG

Variables

The meaning and usage of the various sections of the contract specification is: contract simply names the contract; participants is the set of interactors over which the contract will be defined; constants and variables are used in the behavioural specification; behaviour is the sub-division of sections as follows: common is a relationship used in the definition of the other classes of behaviour; standard, which are the conditions that specify nonnal, non-failure relationships between the participants of the contract and failure the conditions that specify tJle abnormal failure relationships between the participants of the contract.

Base

:s

ReleaseRods Rodslnserted AlllnRange AlllnSkew

B :3

11

Handles From Interactor CoreSens Steam GeneratorS ens ElectricalGeneratorSens OperatorConsole ReactorContainmentSens

Event Trip Trip Trip Trip Trip

Raises In Interactor Steam Turbine

Exception Trip

Behaviour Common: AlllnSkew ~ tfrg€RG: rodgroupS&A(rg).InSkew AlllnRange ~ tfrgERG: rodgroupS&A(rg).InRange Standard:

The relationships between tJle logical sensor of controlrodsS&A and the variables of controlrods are modelled by distinguishing two cases. The first case (described by the variable Positive) specifies that whenever tJle logical sensor indicates true then the rods are indeed inserted. The second ca.<;e (described by tJle variable Negative) specifies that whenever the logical sensor indicates false the rods have not remained inserted for the previous Dlnsert units of time. This model permits the identification of a number of failure modes, the example illustrates two: FM1 - the logical sensor incorrectly detects that tJle rods are inserted; FM2 - tJle insertion of rods is not detected after Dlnsert units of time. Further failure modes for the actuator are defined in the full specification.

AlllnRange " AlllnSkew

Failure: 3rgeRG: {rodgroupS&A(rg) .-,lnSkew __ rodgroupS&A(rg) .FreezeGroup} Exception: -,AlllnRange __ Trip Trip __ tf st EST: steamturbineS&A(st). Trip Event:

Trip __ TripReactor

The relationship between tJle variables of Contro/RodsS&A and the variables of Contro/Rods is defined in terms of a mechanism similar to a contract. The contract between Contro/Rods and ControlRodsS&A is given below.

Controller Sqfety Strategies. The next step is to refine the plant safety strategies in the context of the interactors and contracts of tJle plant interface. This is illustrate by of the safety strategy Trip Reactor, which (as for tJle plant) is specified as the sequential composition of actions TripRods and LockRods.

Contract ControlRodslnterface Participants controlrods: controlrodsS&A:

Invariant. During the action TripRods the actuator for releasing the rods remains set. TripRods == (ReleaseRods) .

Control Rods ControlRodsS&A

Constants

INV

Base Olnsert ORelease

Finish. The action TripRods completes when the operator is informed that tJle trip has completed. .l. TripRods == kRods/nserted).

R R

Variables Base Actuator Positive Negative

4. VERIFICA nON

!3

In this section. we briefly discuss the support provided by traceability and illustrate how the confonnallce checks presented in section 2.4 can be used to verify the specifications for the PWR.

Behaviour Common: Positive ~ controlrods.Rodslnserted => '<:I rg€RG : '<:Ire R: controlrods.rodgroup(rg).rod(r).Prod=:O Negative(T,J ~-.controlrods.Rodslnserted(T,) => 3t e{T,-Olnsert, T,]: tfrgERG :

81

The conformance checks for ControlRods are sketched below.

the

earlier draft from M. Prince. The authors would also like to thank the UK HSE Nuclear Safety Research Programme and the CEC ISAT project.

interactor

Exhaustive. There are only two variables AlllnRange

REFERENCES

and AlllnSkew all possible behaviours are covered by the behaviour classes.

Coxson, B.A. (1993). "Functional Diversity in the Sizewell B design: implications for the setting of operational safety goals". pp. 131-138.

Exclusive.

The standard behaviour class (AlllnRange I'AlllnSkew) excludes all the other behaviour classes. The failure behaviour and exception behaviour are not mutually exclusive, hence the corresponding corrective actions must be examined. In the model of the plant, the FreezeGroup action can be interrupted by the action initiated by Trip therefore the actions do not conflict.

Proceedings of the IMechE International COI~ference on Nuclear Power Plant Safety Towards International Standards: Harmonisation. London, UK. Cristian, F.

(1989). "Exception

Handling". in

Dependability of Resilient Computers, ed. T. Anderson. pp. 68-97 . BSP Professional Books. Oxford, UK.

Raises and Handles. The conformance check for these fields was conducted for the PWR. For example, in the row for ControlRods in HandlesM the exception Trip would be entered in the cells for Core, Steam Generator. ElectricalGenerator. Operator and Reactor Containment. These entries are confirmed to be equivalent with those in the column for ControlRods in RaiseM.

de Lemos, R., A. Saeed, T. Anderson. (1995) "Analysing Safety Requirements for ProcessControl Systems" . pp 42-53. IEEE Software. Duke. D., M. D. Harrison (1993). "Abstract Interaction O~iects" . pp 25-36. Computer

Graphics Forum VoI. 12(3). Gotel, O. C. Z., A. C. W. Finkelstein (1994). An Analysis of the Requirement'> Traceability Problem. pp. 94-100. Proceedings of ICRE, Colorado Springs, Colorado.

5. CONCLUDING REMARKS This paper has presented an approach that is specifically adapted for the requirements analysis of reactor control and protection systems. The benefits that follow from the approach were illustrated by extracts from an PWR case study. In the case of the notation, this served to show how interaclOrs can be used as a "template" supporting both elicitation and representation of abnormal states and their relations to corrective actions. For the method. the example illustrated how the requirements specifications can be organised to support traceability and verify particular aspects of the specifications . .

Helm, A.R., I.M. Holland, D. Gangopadhyay (1994). "Contracts: Specifying Behavioural Composition". pp. 169-180. Special Issue of

SIGPLAN NoticesObject oriented Programming Systems. Languages alld Applications. Ottawa, Canada. Koch, S., R. Reeves (1994). "Software Safety Applications in Commercial Nuclear Power Plants". pp. 63-74. Proceedings of SAFECOMP '94. Instrument Society of America. V. Maggioli (Ed.). Anaheim. California.

The full case study also highlighted some deficiencies in the approach . The notation used to express the behaviour of an interact or is rather cumbersome, this is to be addressed by providing a meta-notation that will provide high-level constructs suitable for the patterns of behaviour that are typically encountered. Anotller aspect is the representation of tlle overall specification. the interactors shown in Section 3 present the case study at a particular level of detail. It is, however, possible to present interactors in varying levels of detail and decomposition. Tool support to manage tlle different levels of details and tlle iterations of the process is being investigate, prototype tools for editing and consistency checks have been applied to aspects of the full case study.

Lawrence lD., W.L. Persons. G. Preckshot and 1. Gallagher (1994) . "Evaluating Software Safety For Systems in Nuclear Power Plants". pp. 197-

208. Proceedings of tile 9th Annual Conference on Computer Assurance (COMPASS '94). Gaithersburg, Maryland. Lutz, R. (1993). "Analyzing Software Requirements Errors in Safety-CriticaL Embedded Systems" . pp. 126-133 . Proceedings of the IEEE Symposium on Requirements Engineering . San Diego, Califomia. Nuclear Installations Inspectorate (1988). Safety

Assessment Principles for Nuclear Power Reactors. HMSO Books. Pamas D.L., G.J.K. Asmis, .T.D. Kendall (1990). "Reviewable Development of Safety Critical Software". Internario/1al COI\ference on Control & Instrumentation in Nuclear InSTallations. The Inslitution of Nuclear Engineers. Glasgow. UK.

ACKNOWLEDGEMENTS Our approach has benefited from interaction with R. de Lemos and tlle British Aerospace Dependable Computing Systems Centre. also comments on an 82