THE INSTITUTION OF NUCLEAR ENGINEERS 3:2 International Conference on CONTROL & INSTRUMENTATION IN NUCLEAR INSTALLATIONS 8th - 10th MAY 1990 Glasgow, United Kingdom AUTOMATED TESTING & BUILDING OF THE AUTO CONTROL SOFTWARE FOR TORNESS NPS W.J.HILL, N.M.MITSON Digital Applications International Limited Alpha House Rowlandsway Wythenshawe Manchester M22 5RG Preprint supplied by SCOTTISH NUCLEAR LINITED whose assistance is gratefully acknowledged.ABSTRACT The paper describes the structural design of the auto control applications software for Torness NPS and shows how this design allows fully automated bottom-up testing to be performed using software test harnesses. The paper then goes on to describe a hardware and software facility developed for the automated generation (‘building’) of software systems for the Torness NPS auto control ‘supersystem' . Because of the complexity of the software and of the development environment, the off-site testing and building of such systems usually requires a considerable amount of expertise. The authors describe how this expertise has been automated, with the benefits this provides in terms of quality assurance, improvement in production time and the freeing of skilled manpower for other work. WJ Hill and N M Mitson 2INTRODUCTION Torness NPS, situated near Dunbar, East Lothian, is a twin unit AGR station. Each reactor is rated at 660 MWe. Unit 1 has been supplying electricity to the national grid since May 1988 and Unit 2 since February 1989. The South of Scotland Electricity Board is the licenced operator. Heysham II is the sister station to Torness. The functional specification for the auto control systems at the two stations is very similar, but the computer hardware, operating system software and applications software source language are different. Torness NPS probably has the most complex computer configuration of any nuclear power station built. The auto control ‘supersystem’ consists of, per reactor, ten input multiplexing computers (‘muxes’), eleven control computers ('CCs’) and a dual online/standby supervisory computer (‘CS’). Each of these computers is a node in the hierarchical control supersystem shown schematically in Figure 1. The data processing supersystem is outside the scope of this paper. WJ Hill and N M Mitson 3THE AUTO CONTROL SUPERSYSTEM The muxes and CCs do not have any disc storage capacity - all software and operational data is held in volatile random access memory (RAM). © The mux and CC software is therefore downloaded from CS (via a CC in the case of @ mux). There is battery backup on the muxes and CCs in the event of a power failure. cc02 to CC1l and CS are multiprocessor machines, i.e. they each contain more than one processor. Several programs run concurrently by time-slicing on one processor. Programs can also run on separate processors in parallel. There are analogue and digital inputs to the control supersystem but all outputs are digital, being either the usual on/off type (‘contact outputs’) or drivable for a precise length of time specified by the control software (‘timed outputs’). Most control room pushbuttons and thumbwheels are connected to the muxes, but a few are connected directly to CS for the amendment of control trims in the CCs. The muxes and CCO1, which does not have a mux, together have approximately 1600 analogue inputs and 1100 digital inputs; the CCs together have approximately 640 digital outputs. To give some idea of the processing power of the control supersystem, the computer specifications are shown in Table 1. Wd Hill and N M Mitson 4There are no terminal or printer operator interfaces to a mux or CC, which are simply connected directly to a higher machine in the hierarchy via a serial communications link (HDLC). CS has hard copy consoles, alphanumeric vDUs, colour graphics VDUs and a thumbwheel inputs: panel to allow auto control trims to be adjusted in the CCs, the values being transmitted to the CCs along the serial links. — In addition to the inputs panel, system software enables operators to inspect variables or modify contro] constants in the CCs from CS. CS is also used to process and report alarms and event messages generated throughout the contro! supersystem. The auto control applications software is divided into several programs, each using separately coded and tested ‘modules’ (procedures ‘included’ at compile time) and libraries. Table 2 gives the number of applications programs and modules in each CC and their memory occupancy in order to give some idea of the size of the control software. These figures exclude the operating system, special-to-project system software and ‘database’ (area of RAM defined to hold operational data: input/output values, global variables and constants). WJ Hill and NM Mitson 5THE SOFTWARE ENVIRONMENT Figure 2 shows the layered structure of the software in each computer. From the kernel outwards, these are: - operating system software (0SC245), | - special-to-project system software (Torness PMS), - database resident in RAM, - the user's applications software. The system software was supplied by Ferranti Computer Systems Limited (FCSL), comprising their multitasking operating system OSC245, a version of their Process Management System (PMS) modified for Torness NPS and their network communications software FNET. Digital Applications International (DAI) Limited produced the CC applications software to NNC Limited’s detailed functional specification and drawings. ‘The applications software for cs and for alarm processing, trim insertion and Central Control Room operator interface was produced by NNC Limited. All applications software was written in CORAL WJ Hill and N M Mitson 6THE CC APPLICATIONS SOFTWARE The CC applications software contains the control algorithms. This software does not deal directly with plant input/output: it uses a RAM-based ‘database’ from which to read information deposited there by the PMS analogue and digital scanning software. Applications software controls the plant via the database, the PMS output driver software reading values from the database. This is shown schematically in Figure 3. Variables are also passed from one applications program to another via the database, rather than by using inter-program messages. The functional specification for the auto control software is in terms that a control engineer can understand, i.e. the variables have simple, meaningful names. For example, the flag that is used to indicate whether regulating rod 21 is in ‘computer control’ mode is C(1,21), while the 72 temperature for gas channel 4 associated with this rod is 72(1,21,4). ‘The system software designer, who had to set out to produce a general purpose tool (i.e. PMS), could know nothing of this and had to design a system that uses a consistent and well defined naming convention for database variables. The defined name is referred to as a ‘database identifier’ (which corresponds to the term ‘database tag’ used in other process control systems). WJ Hill and N M Mitson 7The PMS format for database identifiers in the Torness system is: node.plant area.numeric identifier-1000’s.numeric identifier-units For example, the two variables given above for CC02 on Reactor 1 have been allocated database identifiers of CC02.51.65.375 and CCO2.A1.51.856, which are meaningless to a control engineer. Woo Hill and N M Mitson 8LINKAGE BETWEEN APPLICATIONS SOFTWARE AND DATABASE Thus the two apparent options when coding the CC applications software were: translate the control engineer's representation to the PMS format and hardcode them, or provide some mechanism for automatically linking the two different representations. The first option was not practical for three reasons. Firstly, the precise database identifiers were not then finalised. Secondly, changes to database identifiers which had nothing to do with auto control functionality would still necessitate modifying the applications software - clearly undesirable. Thirdly, as there are several tens of thousands of data points, manual translation was never a serious proposition - the necessary cross reference file would have presented enormous change control problems The authors and their colleagues therefore designed an automatic means of linking the CC applications software to the database. This is shown in Figure 4. The scheme involves the declaration of each program’s variables in a Program Identifier List (PIL), this being a source file of a predefined format (not CORAL) separate from the CORAL source code of the program itself. Each program has its own PIL, this being written by the software engineer when he/she writes the program. A utility program was written to generate CORAL data declarations in a defined format from the PIL so that the program could be compiled. Yore importantly, when the source files containing the database WJ Hill and N M Mitson 9